From sip-admin@lists.bell-labs.com Fri Dec 1 04:03:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03600 for ; Fri, 1 Dec 2000 04:03:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D20A443C4; Fri, 1 Dec 2000 03:03:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by lists.bell-labs.com (Postfix) with ESMTP id 1655A44357 for ; Fri, 1 Dec 2000 03:02:16 -0500 (EST) Received: from m2hub.wipro.com (m2hub.wipro.com [164.164.27.50]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with ESMTP id OAA03655 for ; Fri, 1 Dec 2000 14:39:03 GMT Received: from m2vwall2.wipro.com ([164.164.27.52]) by m2hub.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA1A6A for ; Fri, 1 Dec 2000 14:28:54 +0530 Received: from wslexch.wipsys.soft.net ([192.219.223.59]) by kmglmail.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA6CF8 for ; Fri, 1 Dec 2000 14:31:54 +0530 Received: by wslexch.mail.wipro.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 14:33:35 +0530 Message-ID: <53BA505BEC72D21194400000E216A24403C28A5F@wslexch.mail.wipro.com> From: Vaidyanathan Anantharaman To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Call Disposition header Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 14:33:34 +0530 Hi, I had seen a "call disposition" header for SIP being mentioned in some SIP documents. But I dont' find this being discussed in RFC2543bis or any SIP drafts. Is it described in some draft which I may have overlooked or is it not being used anymore? If such a draft is avlble, could somebody please point me to that? Thanks very much. -Vaidi Wipro Technologies Bangalore, India _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 04:39:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA23019 for ; Fri, 1 Dec 2000 04:39:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3EB5C4442E; Fri, 1 Dec 2000 03:39:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 894B144357 for ; Fri, 1 Dec 2000 03:38:56 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 1 Dec 2000 09:38:48 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id KAA20902; Fri, 1 Dec 2000 10:37:12 +0100 (BST) From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" , Cc: "Jonathan Rosenberg" Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements Message-ID: <000201c05b7a$4817c930$4e34c3c1@ubiquity.co.uk> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 09:37:11 -0000 Content-Transfer-Encoding: 7bit > > I don't think that proxies should start second-guessing UAS. > > I would say that the simplest thing is just to say that when the > > UA is building the Route header list, it should append the > > Contact, if present; failing that, the From. > > > > Really old UAs might lose, but they were always going to do > > that, anyway[0]. > > > What about in the other direction? The UAC will need to add a > Record-Route for the _original_ Request-URI - which may in fact > be entirely unhelpful. I'm not following you here. I was suggesting that the UA -- i.e., UAC and UAS -- append the From header if the Contact header is not present. Actually, if I say that the calling UA can append the original Request-URI instead of the From, then isn't this identical to what you're saying, except the UAs are doing it instead of the proxies? > If the proxy were to add the extra > Record-Route I think that is much safer as it knows what its > own behaviour will be when it receives the request.. Indeed. However, I think it's slightly dangerous for a proxy to think that it knows better than a UA. > I guess, I was also trying to stick with the existing RFC2543 > and bis UA behaviour (minus route mangling). Ie, the UA doesn't > add an extra Route-Header for the original From or Request-URI > - its only added if there is a Contact (which I think is a good > thing !!). > > I think we can do better than saying RFC2543 doesn't work. It's not the case that it doesn't work. It's just there's a failure case where the From is not directly routable. If I use a SIP address that is basically my email address, and my domain has SIP SRV records, there's a good chance that I'm going to be found. (Admittedly I'm less worried about the failure case because 2543 doesn't work in the reverse direction; therefore I feel there are bigger problems.) > - If a proxy inserts Record-Route header into a request > without neither a Contact nor Record-Route header, then the > Proxy MAY add a second Record-Route header to the end of the > R-R list using the From URL address with the source address > as an maddr parameter. > > - If a proxy receives a response to a request in which it > added a Record-Route header AND the response does not contain > a COntact header AND no new headers have been added by other > proxies (ie proxy is final Record-Route'd proxy), then the > proxy MAY add another preceeding Record-Route header to the > start of the response's R-R list using the request's > request-URI with the request's forward address as an maddr > parameter. This is a funky algorithm, but I wouldn't recommend it as default proxy behaviour. Is this a case of intelligence at the edges, simplicity in the core? I feel that it is. That said, I don't have much difficultly imagining some sort of RFC2543 <-> RFC3000 [0] fix-up proxy that mediates between older / newer implementations, and I would see this algorithm being used there. (It would also be possible for it to perhaps enable RFC2543 UAs to be able to issue requests in the reverse direction? I'll have to think about this some more.) If no proxies Record-Route, and the called UA wishes to re-INVITE, and it has no Contact, what does it do? It uses the From. Thus appending the From seems to be consistent behaviour to me (I imagine code would degenerate quite easily). > This should cover the majority of RFC2543 scenarios without > too much fuss for the proxy or UA - I think it is better than > trying to embed using r-r parameters as this just gets messya nd > brittle. As I said before, I think it is better that the > proxy does this as it understand that it will use the added > Record-Route. If the UA tries this, it has little chance of > success. A UA has never (if I remember correctly) added extra > R-R headers if there is no Contact (and shouldn't matter even > if it did). Oh no, they shouldn't be Record-Route headers, just the normal Route headers that a UA always builds in these scenarios. Cheers, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 04:59:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA03647 for ; Fri, 1 Dec 2000 04:59:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A4FE44442; Fri, 1 Dec 2000 03:59:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 6324E44440 for ; Fri, 1 Dec 2000 03:58:08 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 01:57:46 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 01:57:45 -0800 > > What about in the other direction? The UAC will need to add a > > Record-Route for the _original_ Request-URI - which may in fact > > be entirely unhelpful. > > I'm not following you here. I was suggesting that the UA -- > i.e., UAC and UAS -- append the From header if the Contact > header is not present. > > Actually, if I say that the calling UA can append the original > Request-URI instead of the From, then isn't this identical to > what you're saying, except the UAs are doing it instead of the > proxies? Hi Jo, I would say that the UA thinking it knows better than the proxies (how to route) is as great an evil. :) My point is the request-uri that the UAC sends, may quite likely be different to the request-uri that the last record-route proxy sees, eg UA sends with a request-uri of angel@ua.com; a proxy changes this to angel@plane6.hell.com. The last proxy sees this URI not the initial one. Thus if the UAC adds it Request-URI to the last ROute entry then its going to really confuse things. That's worse than putting nothing - at least if the proxy stores call route state then it can succeed - if the UA adds an incorrect Route then the proxy has no choice but to blindly follow the (incorrect) Route header !! Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 05:14:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA12002 for ; Fri, 1 Dec 2000 05:14:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6555B443ED; Fri, 1 Dec 2000 04:14:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id E905F44357 for ; Fri, 1 Dec 2000 04:13:30 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 1 Dec 2000 10:13:23 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id LAA02387; Fri, 1 Dec 2000 11:11:58 +0100 (BST) From: "Jo Hornsby" To: "Fairlie-Cuninghame, Robert" , Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements Message-ID: <000301c05b7f$2410f840$4e34c3c1@ubiquity.co.uk> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 10:11:59 -0000 Content-Transfer-Encoding: 7bit Robert wrote: > I would say that the UA thinking it knows better than the proxies > (how to route) is as great an evil. :) You may have a point... > My point is the request-uri that the UAC sends, may quite likely be > different to the request-uri that the last record-route proxy sees, eg > > UA sends with a request-uri of angel@ua.com; a proxy changes this to > angel@plane6.hell.com. The last proxy sees this URI not the initial one. > Thus if the UAC adds it Request-URI to the last ROute entry then its going > to really confuse things. True. However, I have great faith in optimistic routing. How did the angel@ua.com map to angel@plane6.hell.com in the first place? Simple scenario: ua.com runs SRV, and angel had registered as being at plane6.hell.com. Therefore, that Request-URI would still work. That's the beauty of SIP. &:) > That's worse than putting nothing - at least if the proxy stores call route state then it can succeed - if the UA adds an > incorrect Route then the proxy has no choice but to blindly follow the > (incorrect) Route header !! The cases where I can see the proxy doing better than the UA is: * There is some sort of temporal based routing * The initial routing is obscure (i.e., not literally SRV based) But it is fair to say that the proxy will "win" in these cases. Still, I'm not convinced; but also I'm not that passionate. Either way is a reasonable solution (with the proxy-does-the-work being slightly more robust), so whatever the concensus is, eh? (Although it does look like everybody else has given up, so we might have to toss a coin... (:&) Cheers, - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 05:18:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA14345 for ; Fri, 1 Dec 2000 05:18:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8643044449; Fri, 1 Dec 2000 04:18:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id AAFE444357 for ; Fri, 1 Dec 2000 04:17:47 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 1 Dec 2000 10:17:40 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA03351; Fri, 1 Dec 2000 11:16:14 +0100 (BST) Message-ID: <3A277A6D.76E66081@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: David Oran Cc: "'Jonathan Rosenberg'" , sip@lists.bell-labs.com Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... References: <000301c05b11$e355da40$04d245ab@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 10:16:13 +0000 Content-Transfer-Encoding: 7bit David Oran wrote: > > Hmmm, I would simplify by going the OTHER direction and allowing SDP in any leg of an INVITE transaction. The meaning would be coupled with the state the transaction is in. This allows for 3-way negotiation of SDP, and allows very simple rules: the SDP you operate on, and reply to is the one you received in the last Request (INVITE or PRACK). Or indeed ACK. Is late SDP in ACK for 3pcc really that difficult to support? Some people certainly do it already and I plan on testing for this at the upcoming bakeoff. Mandating UAs to support it looks like a more attractive approach to robust and widespread support for 3pcc than 'strongly recommending' restrictions on what SDP changes you can do on a reINVITE. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net > The simple call scenarios don't get any more complicated: you use the most recent SDP sent, otherwise the most recent one you received. > > That gives much more flexibility and eliminates the special case rules as well. > > Is the liquid sloshing out of the pot yet? > > Dave. > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > > Sent: Thursday, November 30, 2000 3:06 AM > > To: 'sip@lists.bell-labs.com' > > Subject: [SIP] as if there wasn't enough traffic on this darn list... > > > > > > So, figuring we didn't all have enough email on the sip list > > to read (I am personally hopelessly behind), let me stir > > things around some more with another proposal for something > > to ditch from the spec. > > > > Right now, you can carry SDP in the INV/200/ACK exchange in > > two ways. You can send nothing in the INVITE, followed by SDP > > in the 200, and then SDP in ACK (and fortunately I don't know > > anyone who actively does this). Or, you can send SDP in > > INVITE, SDP in 200, and nothing in ACK. I also think there > > are several confused implementations that likely send it in > > all three. > > > > Add to this the unfortunate PRACK mess, which also has been > > used to send SDP in order to support the manyfolks resource > > work when used with 3pcc, but which is yet unimplemented. > > > > It all adds up to a messy confusion. Its not clear what it > > means to send SDP in all these places, and how it works. > > > > So, my proposal is that we simplify. We only allow SDP in > > INVITE and then provisionals/200 OK. No SDP in ACK. No SDP in > > PRACK. (sounds like a Dr. Seuss rhyme, doesn't it?) > > > > The latest 3pcc draft no longer recommends using the > > SDP-in-ACK, since it has problems. Given that there don't > > seem to be useful applications of it any longer, and given > > that, to my knowledge, it is not sent by anyone (at least not > > in any commercially shipping boxes, I hope), I'd like to yank it. > > > > There is a consequence, and that is dealing with the > > manyfolks requirement for sending an updated SDP to deal with > > manyfolks+3pcc. My proposal for that is to use a re-invite, > > rahter than PRACK, to carry the updated SDP. This does mean > > that we need to allow, in SIP, a re-INVITE to arrive while an > > initial INVITE is in progress. Allowing this would also > > address some of the concerns raised in previous threads about > > handling requirements for changes in early media. > > > > I don't think its hard to deal with the re-INVITE while > > INVITE-is-active case. The simplest solution is to reject the > > first INVITE and continue processing with the second one, > > using the new SDP and all. > > > > Anyway, before getting into those details, what does the > > group think about dropping the SDP-in-ACK and SDP-in-PRACK stuff? > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-> labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 05:35:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA24269 for ; Fri, 1 Dec 2000 05:35:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C5B0C44440; Fri, 1 Dec 2000 04:35:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id D540D443CE for ; Fri, 1 Dec 2000 04:34:48 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eB1AYc428943; Fri, 1 Dec 2000 11:34:38 +0100 (MET) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.132]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id MAA19953; Fri, 1 Dec 2000 12:30:22 +0200 (EET) Message-ID: <3A277DAC.7272A729@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: Jonathan Rosenberg , "'Gethin Liddell'" , Sip Mail List Subject: Re: [SIP] 3PCC and the re-invite response References: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 12:30:04 +0200 Content-Transfer-Encoding: 7bit Hello, The ACK is used to stop 200 OK retransmissions. Thus, if it takes some time for your UAC to get the SDP to be sent in the ACK, the 200 OK will be retransmitted a number of times although we have already received it. I do not think it is a good idea to overload a method with two different functions: stop 200 OK retransmissions and send the SDP. We have to take into consideration that in 3PCC scenarios the controller will have to issue another request in order to obtain the SDP that had to be sent in the ACK. Since this takes time I do not find appropriate to mess with the retransmission timers for 200 responses. Best regards, Gonzalo Brett Tate wrote: > > BroadSoft uses the re-INVITE without SDP and ACK > with SDP to avoid the possibility of both sides getting > into the mentioned SDP change loop. > > This is why BroadSoft would like to keep the use of > ACK with SDP at least with regard to re-INVITEs. > > This is also why it would be nice for rfc2543 to mention > that an INVITE without SDP can be used as a request > to pull the receiver off of hold. This has been discussed > at the backoff and on the news group, but is currently > not explicitly mentioned in rfc2543. > > ----- Original Message ----- > From: Jonathan Rosenberg > To: 'Gethin Liddell' ; Sip Mail List > > Sent: Thursday, November 30, 2000 11:23 AM > Subject: RE: [SIP] 3PCC and the re-invite response > > > This is a recognized problem. Note the following section in the document: > > > > In addition, note that in Figure 1, the controller sends a re-INVITE > > to A with the SDP from B. The response to this re-INVITE is a 200 OK > > that contains "SDP A". If the SDP returned in the re-INVITE response > > were not the same, the controller would need to initiate a re-INVITE > > to B with that new SDP. This means that a UA which returns a > > > > > > > > Rosenberg/Peterson/Schulzrinne/Camarillo [Page 12] > > > > Internet Draft 3pcc November 22, 2000 > > > > > > different SDP (for example, by changing the ports) in the response to > > every re-INVITE will trigger an infinite re-INVITE loop from the > > controller to each controller entity. As such, it is STRONGLY > > RECOMMENDED that if a re-INVITE does not require a UAS to modify the > > formulation of the SDP description for a specific stream in the > > response, the SDP description of that stream in the response MUST be > > the same. In other words, if a UA was in a session with a single > > stream, using codec A, and it received a re-INVITE modifying the port > > to send to, the re-INVITE response MUST be the same as it was to the > > initial request. However, if the re-INVITE forces the UAS to change > > codecs, it is acceptable in that case to use a different port in the > > SDP in the response. > > > > > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > > -----Original Message----- > > > From: Gethin Liddell [mailto:gethin@ubiquity.net] > > > Sent: Thursday, November 30, 2000 7:19 AM > > > To: Sip Mail List > > > Subject: [SIP] 3PCC and the re-invite response > > > > > > > > > > > > people, > > > > > > i'm slightly concerened (maybe un-justifably) about the re-invite > > > working of the 3PCC draft. > > > > > > my concern is that it is possible (is it not?) for the user agent > > > receiving the re-invite to change its SDP settings in its response as > > > follows: > > > > > > A Controller B > > > | INV held SDP | | > > > |<------------------| | > > > | | | > > > | 200 SDP A1 | | > > > |-----------------> | INV SDP A1 | > > > | ACK |----------------->| > > > |<----------------- | | > > > | | 200 SDP B1 | > > > | |<-----------------| > > > | | | > > > | | ACK | > > > | INV SDP B1 |----------------->| > > > |<------------------| | > > > | 200 OK SDP A2 | | > > > |------------------>| | > > > | ACK | | > > > |<------------------| | > > > | | > > > | BROKEN RTP | > > > | | > > > | | > > > | | > > > > > > NOTE: A has returned different SDP in its two different 200 > > > OK messages. > > > > > > Why might it do this? It might not but it is possible is it not. > > > > > > perhaps we should mandate that an agent can only change its SDP for a > > > session in an INVITE not in a response (after the initial > > > INVITE/RESPONSE exchange of course) > > > > > > what do we think? > > > > > > -- > > > Gethin Liddell > > > Ubiquity Software Corporation > > > > > > http://www.ubiquity.net > > > mailto:gethin@ubiquity.net > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 06:03:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA09590 for ; Fri, 1 Dec 2000 06:03:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9111444A8; Fri, 1 Dec 2000 05:03:30 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30]) by lists.bell-labs.com (Postfix) with ESMTP id D055244484 for ; Fri, 1 Dec 2000 05:01:57 -0500 (EST) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Fri, 1 Dec 2000 14:00:02 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 13:02:53 +0200 Message-ID: From: Itamar Gilad To: "'Jonathan Rosenberg'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] as if there wasn't enough traffic on this darn list... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 13:02:52 +0200 I agree with Vijay that INVITE within INVITE is going to make things much more complicated. I believe the method INVITE is overloaded enough as it is with re-INVITE. Adding another use for it is going to make things worse. The fundamental problem with the manyfolks draft in my opinion is that it breaks these key principles that otherwise could keep SIP much simpler: 1) a call-leg is established in a three-way handshake. 2) call-leg state is affected by one and only one transaction at a time (in other words: there are no transactions within transactions). I'm not saying we need to reject the manyfolks draft just because it doesn't fit SIP's basic scheme. I'm saying that under the assumption that QoS capabilities negotiation needs to be completed within the scope of INVITE-to-ACK (BTW, is everybody in agreement that this is necessary ?), PRACK-COMET within INVITE is a better solution than INVITE within INVITE. Itamar > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Thu, November 30, 2000 10:06 AM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] as if there wasn't enough traffic on this darn list... > > > So, figuring we didn't all have enough email on the sip list > to read (I am > personally hopelessly behind), let me stir things around some > more with > another proposal for something to ditch from the spec. > > Right now, you can carry SDP in the INV/200/ACK exchange in > two ways. You > can send nothing in the INVITE, followed by SDP in the 200, > and then SDP in > ACK (and fortunately I don't know anyone who actively does > this). Or, you > can send SDP in INVITE, SDP in 200, and nothing in ACK. I > also think there > are several confused implementations that likely send it in > all three. > > Add to this the unfortunate PRACK mess, which also has been > used to send SDP > in order to support the manyfolks resource work when used > with 3pcc, but > which is yet unimplemented. > > It all adds up to a messy confusion. Its not clear what it > means to send SDP > in all these places, and how it works. > > So, my proposal is that we simplify. We only allow SDP in > INVITE and then > provisionals/200 OK. No SDP in ACK. No SDP in PRACK. (sounds > like a Dr. > Seuss rhyme, doesn't it?) > > The latest 3pcc draft no longer recommends using the > SDP-in-ACK, since it > has problems. Given that there don't seem to be useful > applications of it > any longer, and given that, to my knowledge, it is not sent > by anyone (at > least not in any commercially shipping boxes, I hope), I'd > like to yank it. > > There is a consequence, and that is dealing with the > manyfolks requirement > for sending an updated SDP to deal with manyfolks+3pcc. My > proposal for that > is to use a re-invite, rahter than PRACK, to carry the > updated SDP. This > does mean that we need to allow, in SIP, a re-INVITE to > arrive while an > initial INVITE is in progress. Allowing this would also > address some of the > concerns raised in previous threads about handling > requirements for changes > in early media. > > I don't think its hard to deal with the re-INVITE while > INVITE-is-active > case. The simplest solution is to reject the first INVITE and continue > processing with the second one, using the new SDP and all. > > Anyway, before getting into those details, what does the > group think about > dropping the SDP-in-ACK and SDP-in-PRACK stuff? > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From extest-admin@lists.bell-labs.com Fri Dec 1 06:33:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA26200 for ; Fri, 1 Dec 2000 06:33:36 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3EA5A444BF for ; Fri, 1 Dec 2000 05:07:12 -0500 (EST) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: sip-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: extest-admin@lists.bell-labs.com Errors-To: extest-admin@lists.bell-labs.com X-BeenThere: extest@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20001201100712.3EA5A444BF@lists.bell-labs.com> Date: Fri, 1 Dec 2000 05:07:12 -0500 (EST) This is a reminder, sent out once a month, about your lists.bell-labs.com mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, sip-request@lists.bell-labs.com) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@lists.bell-labs.com. Thanks! Passwords for sip-archive@lists.ietf.org: List Password // URL ---- -------- sip@lists.bell-labs.com TDGd http://lists.bell-labs.com/mailman/options/sip/sip-archive%40lists.ietf.org From sip-admin@lists.bell-labs.com Fri Dec 1 06:52:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA06559 for ; Fri, 1 Dec 2000 06:52:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 217CA443CE; Fri, 1 Dec 2000 05:52:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id A95BC44357 for ; Fri, 1 Dec 2000 05:51:15 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 1 Dec 2000 11:51:07 UT Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id MAA02527; Fri, 1 Dec 2000 12:49:36 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Gonzalo Camarillo , Brett Tate Subject: Re: [SIP] 3PCC and the re-invite response X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: Jonathan Rosenberg , Sip Mail List References: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> <3A277DAC.7272A729@lmf.ericsson.se> In-Reply-To: <3A277DAC.7272A729@lmf.ericsson.se> MIME-Version: 1.0 Message-Id: <00120111510301.22777@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 11:00:18 +0000 Content-Transfer-Encoding: 8bit On Fri, 01 Dec 2000, Gonzalo Camarillo wrote: > Hello, > > The ACK is used to stop 200 OK retransmissions. Thus, if it takes some > time for your UAC to get the SDP to be sent in the ACK, the 200 OK will > be retransmitted a number of times although we have already received it. Keep in mind though that the late ACK scenario is only going to be used in certain circumstances. During normal call setup, the standard INVITE SDP, ACK no SDP will be used. When someone does something a bit special, such as 3PCC, then people are more inclined to accept little anomolies, such as no audio for the first second. > > I do not think it is a good idea to overload a method with two different > functions: stop 200 OK retransmissions and send the SDP. why? it does not really add any major coding effort to a SIP UA. > We have to take into consideration that in 3PCC scenarios the controller > will have to issue another request in order to obtain the SDP that had > to be sent in the ACK. Since this takes time I do not find appropriate > to mess with the retransmission timers for 200 responses. sorry, don't understand what you're getting at here. we are not messing with any retranmssion timers. I actually think that the best solution for 3PCC is an amalgamation of the late ACK and re-invite proposals: A Controller B | INV held SDP | | |<------------------| | | | | | 200 SDP A1 | | |-----------------> | | | | | | ACK | | |<------------------| | | | | | | INV NO SDP | | |----------------->| (1) | | | | | 200 SDP B | | |<-----------------| | INV SDP B | | |<------------------| | | | | | 200 SDP A2 | | |-----------------> | | | | | | | ACK SDP A2 | | ACK |----------------->| |<------------------| | | | | | | RTP | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | | | | | | | | | | | | | | | | | | | | | | | | | my only query is who do we late ack at (1), agent A or agent B. Only question is what will agent A do with a re-invite that has no SDP? -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 07:25:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25097 for ; Fri, 1 Dec 2000 07:25:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 912F244435; Fri, 1 Dec 2000 06:25:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 899C444357 for ; Fri, 1 Dec 2000 06:24:53 -0500 (EST) Received: from dynamicsoft.com (ip101.honxr1.ras.tele.dk [195.249.119.101]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id HAA12512; Fri, 1 Dec 2000 07:27:11 -0500 (EST) Message-ID: <3A2798BB.402E583F@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: David Oran Cc: "'Jonathan Rosenberg'" , sip@lists.bell-labs.com Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... References: <000301c05b11$e355da40$04d245ab@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 13:25:31 +0100 Content-Transfer-Encoding: 7bit I don't think it's that simple. For many changes the two parties involved in a call need to agree that the change should happen. When a UA does a re-INVITE with updated SDP it effectively proposes new media settings. If for whatever reason the UAS can't or won't honour those settings it can reject the INVITE. If media settings are updated in an ACK there's no way for the UAS to tell the UAC that it doesn't have enough bandwidth or it doesn't support any of those codecs etc. So at a minimum there should be a number of restrictions on what a UA can do with SDP in an ACK. Maybe the same restrictions that now apply for SDP in responses to INVITE, e.g. you can't suddenly add a media stream in an ACK. So generally allowing SDP in ACK could work for some operations. I don't think it's worth the confusion, though. Better simply to say that ACK is for stopping INVITE retransmissions only. If you want to modify media settings do a re-INVITE. Anders David Oran wrote: > > Hmmm, I would simplify by going the OTHER direction and allowing SDP in any leg of an INVITE transaction. The meaning would be coupled with the state the transaction is in. This allows for 3-way negotiation of SDP, and allows very simple rules: the SDP you operate on, and reply to is the one you received in the last Request (INVITE or PRACK). > > The simple call scenarios don't get any more complicated: you use the most recent SDP sent, otherwise the most recent one you received. > > That gives much more flexibility and eliminates the special case rules as well. > > Is the liquid sloshing out of the pot yet? > > Dave. > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > > Sent: Thursday, November 30, 2000 3:06 AM > > To: 'sip@lists.bell-labs.com' > > Subject: [SIP] as if there wasn't enough traffic on this darn list... > > > > > > So, figuring we didn't all have enough email on the sip list > > to read (I am personally hopelessly behind), let me stir > > things around some more with another proposal for something > > to ditch from the spec. > > > > Right now, you can carry SDP in the INV/200/ACK exchange in > > two ways. You can send nothing in the INVITE, followed by SDP > > in the 200, and then SDP in ACK (and fortunately I don't know > > anyone who actively does this). Or, you can send SDP in > > INVITE, SDP in 200, and nothing in ACK. I also think there > > are several confused implementations that likely send it in > > all three. > > > > Add to this the unfortunate PRACK mess, which also has been > > used to send SDP in order to support the manyfolks resource > > work when used with 3pcc, but which is yet unimplemented. > > > > It all adds up to a messy confusion. Its not clear what it > > means to send SDP in all these places, and how it works. > > > > So, my proposal is that we simplify. We only allow SDP in > > INVITE and then provisionals/200 OK. No SDP in ACK. No SDP in > > PRACK. (sounds like a Dr. Seuss rhyme, doesn't it?) > > > > The latest 3pcc draft no longer recommends using the > > SDP-in-ACK, since it has problems. Given that there don't > > seem to be useful applications of it any longer, and given > > that, to my knowledge, it is not sent by anyone (at least not > > in any commercially shipping boxes, I hope), I'd like to yank it. > > > > There is a consequence, and that is dealing with the > > manyfolks requirement for sending an updated SDP to deal with > > manyfolks+3pcc. My proposal for that is to use a re-invite, > > rahter than PRACK, to carry the updated SDP. This does mean > > that we need to allow, in SIP, a re-INVITE to arrive while an > > initial INVITE is in progress. Allowing this would also > > address some of the concerns raised in previous threads about > > handling requirements for changes in early media. > > > > I don't think its hard to deal with the re-INVITE while > > INVITE-is-active case. The simplest solution is to reject the > > first INVITE and continue processing with the second one, > > using the new SDP and all. > > > > Anyway, before getting into those details, what does the > > group think about dropping the SDP-in-ACK and SDP-in-PRACK stuff? > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-> labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 07:27:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA26673 for ; Fri, 1 Dec 2000 07:27:41 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A5E9144450; Fri, 1 Dec 2000 06:26:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4C70544357 for ; Fri, 1 Dec 2000 06:25:02 -0500 (EST) Received: from dynamicsoft.com (ip101.honxr1.ras.tele.dk [195.249.119.101]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id HAA12517; Fri, 1 Dec 2000 07:27:14 -0500 (EST) Message-ID: <3A2798BF.D1ABAD1A@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: Jonathan Rosenberg , "'Gethin Liddell'" , Sip Mail List References: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 13:25:35 +0100 Content-Transfer-Encoding: 7bit Brett Tate wrote: > > BroadSoft uses the re-INVITE without SDP and ACK > with SDP to avoid the possibility of both sides getting > into the mentioned SDP change loop. > > This is why BroadSoft would like to keep the use of > ACK with SDP at least with regard to re-INVITEs. > > This is also why it would be nice for rfc2543 to mention > that an INVITE without SDP can be used as a request > to pull the receiver off of hold. This has been discussed > at the backoff and on the news group, but is currently > not explicitly mentioned in rfc2543. I don't remember ever having heard of such usage and it doesn't sound like a good idea. IMHO it's illogical and inconsistent with how SDP is used with SIP today: if you want to modify media in any way send updated SDP. Anders _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 07:42:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA04794 for ; Fri, 1 Dec 2000 07:42:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BCC6644456; Fri, 1 Dec 2000 06:41:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 6C6394444F for ; Fri, 1 Dec 2000 06:40:37 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eB1CeR413256; Fri, 1 Dec 2000 13:40:27 +0100 (MET) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.132]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id OAA28367; Fri, 1 Dec 2000 14:40:25 +0200 (EET) Message-ID: <3A279C26.FE53784A@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: Brett Tate , Jonathan Rosenberg , Sip Mail List Subject: Re: [SIP] 3PCC and the re-invite response References: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> <3A277DAC.7272A729@lmf.ericsson.se> <00120111510301.22777@gethin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 14:40:06 +0200 Content-Transfer-Encoding: 7bit Hello, Gethin Liddell wrote: > > On Fri, 01 Dec 2000, Gonzalo Camarillo wrote: > > Hello, > > > > The ACK is used to stop 200 OK retransmissions. Thus, if it takes some > > time for your UAC to get the SDP to be sent in the ACK, the 200 OK will > > be retransmitted a number of times although we have already received it. > > Keep in mind though that the late ACK scenario is only going to be used > in certain circumstances. During normal call setup, the standard > INVITE SDP, ACK no SDP will be used. When someone does something a bit > special, such as 3PCC, then people are more inclined to accept little > anomolies, such as no audio for the first second. I am not talking about service behavior (the user waiting for a couple of seconds). I am talking about a UAC retransmitting a 200 OK because an ACK has not been received. The UAC thinks that the 200 OK responses that it is sending are getting lost in the network but what it is really happening is that the UAC that should return an ACK is doing something in order to gather a proper SDP to piggyback it in the ACK. If we send the ACK as soon as the 200 OK arrives the UAS will stop retransmitting. Then, the UAC can take as long as it wants to gather the SDP and then re-INVITE. I would accept to send the SDP in the ACK if the UAC, upon reception of the 200 OK, it is ready to send the ACK with the SDP. In that case I do not have a problem with ACKs carrying SDPs. > > > > > I do not think it is a good idea to overload a method with two different > > functions: stop 200 OK retransmissions and send the SDP. > > why? it does not really add any major coding effort to a SIP UA. It is not about coding effort. It is about "streching" a retransmission timer because the SDP is not ready to be sent. > > We have to take into consideration that in 3PCC scenarios the controller > > will have to issue another request in order to obtain the SDP that had > > to be sent in the ACK. Since this takes time I do not find appropriate > > to mess with the retransmission timers for 200 responses. > > sorry, don't understand what you're getting at here. we are not messing > with any retranmssion timers. See my comments above. > > I actually think that the best solution for 3PCC is an amalgamation of > the late ACK and re-invite proposals: > > A Controller B > | INV held SDP | | > |<------------------| | > | | | > | 200 SDP A1 | | > |-----------------> | | > | | | > | ACK | | > |<------------------| | > | | | > | | INV NO SDP | > | |----------------->| (1) > | | | > | | 200 SDP B | > | |<-----------------| In this moment the UAS will begin retransmitting the 200 OK until the ACK arrives > | INV SDP B | | > |<------------------| | > | | | > | 200 SDP A2 | | > |-----------------> | | > | | | > | | ACK SDP A2 | > | ACK |----------------->| At this point the UAS will stop retransmitting the 200 OK... In the previous message exchange (INVITE SDP B and 200 SDP A2) takes long, the UAS will have to retransmit the 200 OK a number of times. Let's keep in mind that retransmissions are used to ensure reliable delivery of SIP messages. In this scenario the 200 OK was already delivered but the UAS had to keep on retransmitting... I do not like that... Regards, Gonzalo > |<------------------| | > | | | > | | RTP | > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > | | | > | | | > | | | > | | | > | | | > | | | > | | | > | | | > > my only query is who do we late ack at (1), agent A or agent B. > > Only question is what will agent A do with a re-invite that has no SDP? > > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 08:02:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA15810 for ; Fri, 1 Dec 2000 08:02:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C25DA4444F; Fri, 1 Dec 2000 07:02:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id CA0CE4444A for ; Fri, 1 Dec 2000 07:01:44 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 1 Dec 2000 13:01:37 UT Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id OAA24616; Fri, 1 Dec 2000 14:00:08 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Gonzalo Camarillo Subject: Re: [SIP] 3PCC and the re-invite response X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: Sip Mail List References: <00120111510301.22777@gethin> <3A279C26.FE53784A@lmf.ericsson.se> In-Reply-To: <3A279C26.FE53784A@lmf.ericsson.se> MIME-Version: 1.0 Message-Id: <00120113013502.22777@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 12:51:21 +0000 Content-Transfer-Encoding: 8bit My appologies Gonzalo, i missed the point you were making. IMO, your point is valid and an issue for the original 3PCC draft. However, with the "re-invite & late ack" proposal, the 200 response of the re-invite should come fairly quickly as there is no need to wait for a user to answer a phone. Would this not be enough to avoid the re-transmission problem you pointed out? On Fri, 01 Dec 2000, Gonzalo Camarillo wrote: > Hello, > > Gethin Liddell wrote: > > > > On Fri, 01 Dec 2000, Gonzalo Camarillo wrote: > > > Hello, > > > > > > The ACK is used to stop 200 OK retransmissions. Thus, if it takes some > > > time for your UAC to get the SDP to be sent in the ACK, the 200 OK will > > > be retransmitted a number of times although we have already received it. > > > > Keep in mind though that the late ACK scenario is only going to be used > > in certain circumstances. During normal call setup, the standard > > INVITE SDP, ACK no SDP will be used. When someone does something a bit > > special, such as 3PCC, then people are more inclined to accept little > > anomolies, such as no audio for the first second. > > I am not talking about service behavior (the user waiting for a couple > of seconds). I am talking about a UAC retransmitting a 200 OK because an > ACK has not been received. The UAC thinks that the 200 OK responses that > it is sending are getting lost in the network but what it is really > happening is that the UAC that should return an ACK is doing something > in order to gather a proper SDP to piggyback it in the ACK. > > If we send the ACK as soon as the 200 OK arrives the UAS will stop > retransmitting. Then, the UAC can take as long as it wants to gather the > SDP and then re-INVITE. > > I would accept to send the SDP in the ACK if the UAC, upon reception of > the 200 OK, it is ready to send the ACK with the SDP. In that case I do > not have a problem with ACKs carrying SDPs. > > > > > > > > > I do not think it is a good idea to overload a method with two different > > > functions: stop 200 OK retransmissions and send the SDP. > > > > why? it does not really add any major coding effort to a SIP UA. > > It is not about coding effort. It is about "streching" a retransmission > timer because the SDP is not ready to be sent. > > > > > We have to take into consideration that in 3PCC scenarios the controller > > > will have to issue another request in order to obtain the SDP that had > > > to be sent in the ACK. Since this takes time I do not find appropriate > > > to mess with the retransmission timers for 200 responses. > > > > sorry, don't understand what you're getting at here. we are not messing > > with any retranmssion timers. > > See my comments above. > > > > > I actually think that the best solution for 3PCC is an amalgamation of > > the late ACK and re-invite proposals: > > > > A Controller B > > | INV held SDP | | > > |<------------------| | > > | | | > > | 200 SDP A1 | | > > |-----------------> | | > > | | | > > | ACK | | > > |<------------------| | > > | | | > > | | INV NO SDP | > > | |----------------->| (1) > > | | | > > | | 200 SDP B | > > | |<-----------------| > > In this moment the UAS will begin retransmitting the 200 OK until the > ACK arrives > > > | INV SDP B | | > > |<------------------| | > > | | | > > | 200 SDP A2 | | > > |-----------------> | | > > | | | > > | | ACK SDP A2 | > > | ACK |----------------->| > > At this point the UAS will stop retransmitting the 200 OK... In the > previous message exchange (INVITE SDP B and 200 SDP A2) takes long, the > UAS will have to retransmit the 200 OK a number of times. > > Let's keep in mind that retransmissions are used to ensure reliable > delivery of SIP messages. In this scenario the 200 OK was already > delivered but the UAS had to keep on retransmitting... I do not like > that... > > Regards, > > Gonzalo > > > > > |<------------------| | > > | | | > > | | RTP | > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > | | | > > | | | > > | | | > > | | | > > | | | > > | | | > > | | | > > | | | > > > > my only query is who do we late ack at (1), agent A or agent B. > > > > Only question is what will agent A do with a re-invite that has no SDP? > > > > -- > > Gethin Liddell > > Ubiquity Software Corporation > > > > http://www.ubiquity.net > > mailto:gethin@ubiquity.net > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 09:03:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13940 for ; Fri, 1 Dec 2000 09:03:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2889B44444; Fri, 1 Dec 2000 08:03:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id F21B044357 for ; Fri, 1 Dec 2000 08:02:47 -0500 (EST) Received: from cisco.com (blanc.cisco.com [161.44.3.203]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id JAA13763; Fri, 1 Dec 2000 09:02:14 -0500 (EST) Message-ID: <3A27AF74.25CEBA71@cisco.com> From: Bryan Byerly X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.5.1 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'sip@lists.bell-labs.com'" , byerly@cisco.com Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 09:02:28 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > So, figuring we didn't all have enough email on the sip list to read (I am > personally hopelessly behind), let me stir things around some more with > another proposal for something to ditch from the spec. > > Right now, you can carry SDP in the INV/200/ACK exchange in two ways. You > can send nothing in the INVITE, followed by SDP in the 200, and then SDP in > ACK (and fortunately I don't know anyone who actively does this). I am specifically aware of a commerical implementation that actively does this. > Or, you > can send SDP in INVITE, SDP in 200, and nothing in ACK. I also think there > are several confused implementations that likely send it in all three. > > Add to this the unfortunate PRACK mess, which also has been used to send SDP > in order to support the manyfolks resource work when used with 3pcc, but > which is yet unimplemented. I am specifically aware of two separate commerical implementations of assured QoS using the manyfolks draft (and thus SDPs in PRACK). I see no reason to place an unwarrented restriction on which messages SDP can and cannot be sent in. Please elaborate on what specific problems you've identified w/r/t SDP in ACK. > It all adds up to a messy confusion. Its not clear what it means to send SDP > in all these places, and how it works. So, let's clarify what the SDP does mean. > So, my proposal is that we simplify. We only allow SDP in INVITE and then > provisionals/200 OK. No SDP in ACK. No SDP in PRACK. (sounds like a Dr. > Seuss rhyme, doesn't it?) > > The latest 3pcc draft no longer recommends using the SDP-in-ACK, since it > has problems. Given that there don't seem to be useful applications of it > any longer, and given that, to my knowledge, it is not sent by anyone (at > least not in any commercially shipping boxes, I hope), I'd like to yank it. > > There is a consequence, and that is dealing with the manyfolks requirement > for sending an updated SDP to deal with manyfolks+3pcc. My proposal for that > is to use a re-invite, rahter than PRACK, to carry the updated SDP. This > does mean that we need to allow, in SIP, a re-INVITE to arrive while an > initial INVITE is in progress. Allowing this would also address some of the > concerns raised in previous threads about handling requirements for changes > in early media. This sounds like the original two-stage DCS proposal. Why don't the same original criticisms apply now? > I don't think its hard to deal with the re-INVITE while INVITE-is-active > case. The simplest solution is to reject the first INVITE and continue > processing with the second one, using the new SDP and all. > Anyway, before getting into those details, what does the group think about > dropping the SDP-in-ACK and SDP-in-PRACK stuff? I think it's an unwarrented limitation. I really don't understand what problem you're trying to solve. If the spec is unclear, then additional clarification is in order. thanks, Bryan > > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 09:18:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18382 for ; Fri, 1 Dec 2000 09:18:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9805744460; Fri, 1 Dec 2000 08:18:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 22E4F44357 for ; Fri, 1 Dec 2000 08:17:13 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id JAA57229; Fri, 1 Dec 2000 09:17:02 -0500 (EST) Message-ID: <0b0e01c05ba1$a962a350$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Anders Kristensen" Cc: "Jonathan Rosenberg" , "'Gethin Liddell'" , "Sip Mail List" References: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> <3A2798BF.D1ABAD1A@dynamicsoft.com> Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 09:19:05 -0500 Content-Transfer-Encoding: 7bit > > BroadSoft uses the re-INVITE without SDP and ACK > > with SDP to avoid the possibility of both sides getting > > into the mentioned SDP change loop. > > > > This is why BroadSoft would like to keep the use of > > ACK with SDP at least with regard to re-INVITEs. > > > > This is also why it would be nice for rfc2543 to mention > > that an INVITE without SDP can be used as a request > > to pull the receiver off of hold. This has been discussed > > at the backoff and on the news group, but is currently > > not explicitly mentioned in rfc2543. > > I don't remember ever having heard of such usage and it doesn't sound > like a good idea. IMHO it's illogical and inconsistent with how SDP is > used with SIP today: if you want to modify media in any way send updated > SDP. > http://lists.bell-labs.com/pipermail/sip/2000q2/001125.html is a thread where this was discussed. This was also discussed in the advanced media scenarios at the last bakeoff. Let me reiterate why people agreed in previous discussions. It works similar to the first INVITE without SDP. The sender is requesting to establish some type of session. The receiver would pass back sessions descriptions which the receiver wishes to allow to be established. The sender would pass back the agreed upon session description. After being put on hold, an INVITE without SDP works similar to when the session has not been established. If the receiver is NOT the one that requested the hold, the receiver should pass back the SDP to allow the call to be pulled off hold (along with any desire for session changes). If the receiver wishes not to be pulled off of hold, the receiver passes back hold media and is basically now responsible for pulling the original sender off of hold. Henning: Please add to rfc2543 that an INVITE without can be used to request a session to pull off of hold. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 09:30:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18755 for ; Fri, 1 Dec 2000 09:30:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EA5CC44464; Fri, 1 Dec 2000 08:30:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60]) by lists.bell-labs.com (Postfix) with ESMTP id 5954A44464 for ; Fri, 1 Dec 2000 08:29:52 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Fri, 1 Dec 2000 14:29:37 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id OAA27172; Fri, 1 Dec 2000 14:29:35 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 802569A8.004F8EEB ; Fri, 1 Dec 2000 14:28:59 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Bryan Byerly Cc: Jonathan Rosenberg , "'sip@lists.bell-labs.com'" , byerly@cisco.com Message-ID: <802569A8.004F6BDC.00@marconicomms.com> Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 14:27:36 +0000 Bryan writes: "So, lets clarfy what the SDP does mean" This is the crucial point. Jonathans's proposal changes the method in which the SDP is received, it does not change the context. If there is confusion surrounding the various contexts in which an SDP can be received, then a discussion is required to clarify this. Only then can a decision be made on what is the best method(s) to deliver SDPs. Until then, if its not broken, don't fix it. Bryan Byerly on 01/12/2000 14:02:28 To: Jonathan Rosenberg cc: "'sip@lists.bell-labs.com'" , byerly@cisco.com(bcc: Keith Robinson/MAIN/MC1) Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... Jonathan Rosenberg wrote: > So, figuring we didn't all have enough email on the sip list to read (I am > personally hopelessly behind), let me stir things around some more with > another proposal for something to ditch from the spec. > > Right now, you can carry SDP in the INV/200/ACK exchange in two ways. You > can send nothing in the INVITE, followed by SDP in the 200, and then SDP in > ACK (and fortunately I don't know anyone who actively does this). I am specifically aware of a commerical implementation that actively does this. > Or, you > can send SDP in INVITE, SDP in 200, and nothing in ACK. I also think there > are several confused implementations that likely send it in all three. > > Add to this the unfortunate PRACK mess, which also has been used to send SDP > in order to support the manyfolks resource work when used with 3pcc, but > which is yet unimplemented. I am specifically aware of two separate commerical implementations of assured QoS using the manyfolks draft (and thus SDPs in PRACK). I see no reason to place an unwarrented restriction on which messages SDP can and cannot be sent in. Please elaborate on what specific problems you've identified w/r/t SDP in ACK. > It all adds up to a messy confusion. Its not clear what it means to send SDP > in all these places, and how it works. So, let's clarify what the SDP does mean. > So, my proposal is that we simplify. We only allow SDP in INVITE and then > provisionals/200 OK. No SDP in ACK. No SDP in PRACK. (sounds like a Dr. > Seuss rhyme, doesn't it?) > > The latest 3pcc draft no longer recommends using the SDP-in-ACK, since it > has problems. Given that there don't seem to be useful applications of it > any longer, and given that, to my knowledge, it is not sent by anyone (at > least not in any commercially shipping boxes, I hope), I'd like to yank it. > > There is a consequence, and that is dealing with the manyfolks requirement > for sending an updated SDP to deal with manyfolks+3pcc. My proposal for that > is to use a re-invite, rahter than PRACK, to carry the updated SDP. This > does mean that we need to allow, in SIP, a re-INVITE to arrive while an > initial INVITE is in progress. Allowing this would also address some of the > concerns raised in previous threads about handling requirements for changes > in early media. This sounds like the original two-stage DCS proposal. Why don't the same original criticisms apply now? > I don't think its hard to deal with the re-INVITE while INVITE-is-active > case. The simplest solution is to reject the first INVITE and continue > processing with the second one, using the new SDP and all. > Anyway, before getting into those details, what does the group think about > dropping the SDP-in-ACK and SDP-in-PRACK stuff? I think it's an unwarrented limitation. I really don't understand what problem you're trying to solve. If the spec is unclear, then additional clarification is in order. thanks, Bryan > > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 09:44:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19202 for ; Fri, 1 Dec 2000 09:44:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D3654446A; Fri, 1 Dec 2000 08:44:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 6FC8844468 for ; Fri, 1 Dec 2000 08:43:30 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id JAA60308; Fri, 1 Dec 2000 09:43:21 -0500 (EST) Message-ID: <0b3e01c05ba5$56da6a60$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Gethin Liddell" Cc: "Sip Mail List" References: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> <3A277DAC.7272A729@lmf.ericsson.se> <00120111510301.22777@gethin> Subject: Re: [SIP] 3PCC and the re-invite response 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 09:45:24 -0500 Content-Transfer-Encoding: 7bit > I actually think that the best solution for 3PCC is an amalgamation of > the late ACK and re-invite proposals: > > A Controller B > | INV held SDP | | > |<------------------| | > | | | > | 200 SDP A1 | | > |-----------------> | | > | | | > | ACK | | > |<------------------| | > | | | > | | INV NO SDP | > | |----------------->| (1) > | | | > | | 200 SDP B | > | |<-----------------| > | INV SDP B | | > |<------------------| | > | | | > | 200 SDP A2 | | > |-----------------> | | > | | | > | | ACK SDP A2 | > | ACK |----------------->| > |<------------------| | > | | | > | | RTP | > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > | | | > | | | > | | | > | | | > | | | > | | | > | | | > | | | > > my only query is who do we late ack at (1), agent A or agent B. It would be best to send it first to the party that the 3pcc is controlling since it should definitely support it, and it is the one trying to pull the other party off of hold. In the above scenario, I am assuming that B put party A on hold (the picture isn't complete). Thus the INVITE without SDP should be sent to B first. > > Only question is what will agent A do with a re-invite that has no SDP? > Assuming no 3pcc, any INVITE without SDP should be a request to establish a session. If party A put B on hold. An INVITE without SDP from B is a request basically indicating to please pull me off of hold. However since A started the hold, it is of course fine for A to pass back a hold SDP again. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 09:57:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19604 for ; Fri, 1 Dec 2000 09:57:49 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFFA244474; Fri, 1 Dec 2000 08:52:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id 5001844472 for ; Fri, 1 Dec 2000 08:51:39 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id HAA03889 for ; Fri, 1 Dec 2000 07:51:31 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA18727 for ; Fri, 1 Dec 2000 07:51:30 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Fri, 1 Dec 2000 08:51:30 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8735@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Session progress MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 08:51:28 -0600 Hello there? Looks like either my question below was too basic/stupid or you guys are still thinking about the answer ? I will appreciate any response Thanks Uri -----Original Message----- From: Baniel Uri-CUB001 [mailto:Uri_Baniel-CUB001@email.mot.com] Sent: Monday, November 27, 2000 1:42 PM To: 'sip@lists.bell-labs.com' Subject: [SIP] Session progress Hi 1) Bis 4.2.1 says: "A UAC MUST be prepared to receive media data according to the session description as soon as it sends an INVITE (or re-INVITE) " 2) According the 183 draft that there must be first a two way path established (or at least the UAC should get first the UAS RTP information) before the UAC is able to get Alerting/call treatment RTP packets. I guess (2) overrides (1) (and is even included in 1 now) My question is: Why is the need to have the two way path established for being able to convey the RTP information from the UAS to the UAC? Thanks Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 10:02:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19716 for ; Fri, 1 Dec 2000 10:02:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4F43B4447D; Fri, 1 Dec 2000 08:55:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 607FE4447C for ; Fri, 1 Dec 2000 08:54:28 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id JAA61636; Fri, 1 Dec 2000 09:54:20 -0500 (EST) Message-ID: <0b4601c05ba6$df8b9720$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Anders Kristensen" Cc: References: <000301c05b11$e355da40$04d245ab@cisco.com> <3A2798BB.402E583F@dynamicsoft.com> Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 09:56:23 -0500 Content-Transfer-Encoding: 7bit > I don't think it's that simple. > > For many changes the two parties involved in a call need to agree that > the change should happen. > > When a UA does a re-INVITE with updated SDP it effectively proposes new > media settings. If for whatever reason the UAS can't or won't honour > those settings it can reject the INVITE. If media settings are updated > in an ACK there's no way for the UAS to tell the UAC that it doesn't > have enough bandwidth or it doesn't support any of those codecs etc. Correct. An INVITE without SDP is a request for the receiver to propose the new media settings. If the receiver did not put the call on hold, the receiver most likely would not desire to remain on hold. > > So at a minimum there should be a number of restrictions on what a UA > can do with SDP in an ACK. Maybe the same restrictions that now apply > for SDP in responses to INVITE, e.g. you can't suddenly add a media > stream in an ACK. I agree. > > So generally allowing SDP in ACK could work for some operations. I don't > think it's worth the confusion, though. Better simply to say that ACK is > for stopping INVITE retransmissions only. If you want to modify media > settings do a re-INVITE. For 3pcc a re-INVITE loop would potentially get established if both sides keep changing ports with every re-INVITE (and particularly when the same port is not used before and after hold). This is why SDP in ACK for re-INVITEs is important for 3pcc. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 10:10:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19962 for ; Fri, 1 Dec 2000 10:10:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0E8DE44473; Fri, 1 Dec 2000 09:02:10 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 81CB844473 for ; Fri, 1 Dec 2000 09:01:01 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Dec 1 09:58:14 EST 2000 Received: by lists.bell-labs.com (Postfix) id CC62344380; Fri, 1 Dec 2000 09:45:54 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id A69684437D for ; Fri, 1 Dec 2000 09:45:54 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA07950; Fri, 1 Dec 2000 09:45:45 -0500 (EST) Message-ID: <3A27B99C.344B3D42@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Anders Kristensen Cc: Brett Tate , Jonathan Rosenberg , "'Gethin Liddell'" , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> <3A2798BF.D1ABAD1A@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 09:45:48 -0500 Content-Transfer-Encoding: 7bit > > This is also why it would be nice for rfc2543 to mention > > that an INVITE without SDP can be used as a request > > to pull the receiver off of hold. This has been discussed > > at the backoff and on the news group, but is currently > > not explicitly mentioned in rfc2543. > > I don't remember ever having heard of such usage and it doesn't sound > like a good idea. IMHO it's illogical and inconsistent with how SDP is > used with SIP today: if you want to modify media in any way send updated > SDP. This was discussed and declared a bug, not a feature, a while ago. Implying specific meaning to 'no SDP' is the road to special-case bellhead madness. In particular, since the functionality is already available without this approach. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 10:14:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20103 for ; Fri, 1 Dec 2000 10:14:32 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0570044486; Fri, 1 Dec 2000 09:06:13 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id C20B444485 for ; Fri, 1 Dec 2000 09:04:59 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Dec 1 10:02:04 EST 2000 Received: by lists.bell-labs.com (Postfix) id 388E644384; Fri, 1 Dec 2000 09:49:45 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id 125AB4437D for ; Fri, 1 Dec 2000 09:49:45 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id JAA08238; Fri, 1 Dec 2000 09:49:44 -0500 (EST) Message-ID: <3A27BA8B.66BA322D@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: Anders Kristensen , Jonathan Rosenberg , "'Gethin Liddell'" , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> <3A2798BF.D1ABAD1A@dynamicsoft.com> <0b0e01c05ba1$a962a350$4301a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 09:49:47 -0500 Content-Transfer-Encoding: 7bit > Henning: > > Please add to rfc2543 that an INVITE without > can be used to request a session to pull off of > hold. > No. Terrible idea. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 10:20:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20376 for ; Fri, 1 Dec 2000 10:20:50 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 478334448A; Fri, 1 Dec 2000 09:07:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B5A1F44485 for ; Fri, 1 Dec 2000 09:06:04 -0500 (EST) Received: from dynamicsoft.com (ip119.honxr3.ras.tele.dk [195.215.228.119]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA13769; Fri, 1 Dec 2000 10:08:17 -0500 (EST) Message-ID: <3A27BE7D.C5369CA4@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: Jonathan Rosenberg , "'Gethin Liddell'" , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> <3A2798BF.D1ABAD1A@dynamicsoft.com> <0b0e01c05ba1$a962a350$4301a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 16:06:37 +0100 Content-Transfer-Encoding: 7bit Brett Tate wrote: > > > > BroadSoft uses the re-INVITE without SDP and ACK > > > with SDP to avoid the possibility of both sides getting > > > into the mentioned SDP change loop. > > > > > > This is why BroadSoft would like to keep the use of > > > ACK with SDP at least with regard to re-INVITEs. > > > > > > This is also why it would be nice for rfc2543 to mention > > > that an INVITE without SDP can be used as a request > > > to pull the receiver off of hold. This has been discussed > > > at the backoff and on the news group, but is currently > > > not explicitly mentioned in rfc2543. > > > > I don't remember ever having heard of such usage and it doesn't sound > > like a good idea. IMHO it's illogical and inconsistent with how SDP is > > used with SIP today: if you want to modify media in any way send updated > > SDP. > > > > http://lists.bell-labs.com/pipermail/sip/2000q2/001125.html > > is a thread where this was discussed. Ah, I see. It's the ACK with SDP that takes the call off hold, not the INVITE without. That makes much more sense although I'm still sceptical of the whole notion of modifying media in ACKs as it denies the receiver the option of rejecting the changes... Anders > > This was also discussed in the advanced media > scenarios at the last bakeoff. > > Let me reiterate why people agreed in previous > discussions. > > It works similar to the first INVITE without SDP. > The sender is requesting to establish some type > of session. The receiver would pass back > sessions descriptions which the receiver wishes > to allow to be established. The sender would > pass back the agreed upon session description. > > After being put on hold, an INVITE without SDP > works similar to when the session has not been > established. If the receiver is NOT the one that > requested the hold, the receiver should pass > back the SDP to allow the call to be pulled off > hold (along with any desire for session changes). > If the receiver wishes not to be pulled off > of hold, the receiver passes back hold media > and is basically now responsible for pulling the > original sender off of hold. > > Henning: > > Please add to rfc2543 that an INVITE without > can be used to request a session to pull off of > hold. -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 10:24:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20494 for ; Fri, 1 Dec 2000 10:24:27 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CE50D4448F; Fri, 1 Dec 2000 09:07:24 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 42BC444485 for ; Fri, 1 Dec 2000 09:06:10 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 1 Dec 2000 15:06:02 UT Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA15572; Fri, 1 Dec 2000 16:04:38 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: "Brett Tate" Subject: Re: [SIP] 3PCC and the re-invite response X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: "Sip Mail List" References: <00120111510301.22777@gethin> <0b3e01c05ba5$56da6a60$4301a8c0@broadsoft.com> In-Reply-To: <0b3e01c05ba5$56da6a60$4301a8c0@broadsoft.com> MIME-Version: 1.0 Message-Id: <00120115060300.23207@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 14:57:51 +0000 Content-Transfer-Encoding: 8bit On Fri, 01 Dec 2000, Brett Tate wrote: > > I actually think that the best solution for 3PCC is an amalgamation of > > the late ACK and re-invite proposals: > > > > A Controller B > > | INV held SDP | | time t = 0 > > |<------------------| | > > | | | > > | 200 SDP A1 | | > > |-----------------> | | > > | | | > > | ACK | | > > |<------------------| | > > | | | > > | | INV NO SDP | > > | |----------------->| (1) > > | | | > > | | 200 SDP B | > > | |<-----------------| > > | INV SDP B | | > > |<------------------| | > > | | | > > | 200 SDP A2 | | > > |-----------------> | | > > | | | > > | | ACK SDP A2 | > > | ACK |----------------->| > > |<------------------| | > > | | | > > | | RTP | > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > | | | > > | | | > > | | | > > | | | > > | | | > > | | | > > | | | > > | | | > > > > my only query is who do we late ack at (1), agent A or agent B. > > It would be best to send it first to the party that the 3pcc > is controlling since it should definitely support it, and it > is the one trying to pull the other party off of hold. In the > above scenario, I am assuming that B put party A on > hold (the picture isn't complete). Thus the INVITE > without SDP should be sent to B first. the picture is actually the call flow that will occur at the initiation of a 3PCC session. so `b' has not put `a' on hold, the contoller has put `a' on hold whilst it tries to contact b'. once it has contacted `b', it is able to quickly bring `a' into the RTP session because there is no user intervention. if we were to initiate the late ACK scenario to 'a' at (1) then as Gonzalo pointed out, `a' may be waiting around a long time for an ACK to appear because we would have to wait for the user to answer the phone. > > > > Only question is what will agent A do with a re-invite that has no SDP? > > > > Assuming no 3pcc, any INVITE without SDP should > be a request to establish a session. If party A put B > on hold. An INVITE without SDP from B is a request > basically indicating to please pull me off of hold. > However since A started the hold, it is of course fine > for A to pass back a hold SDP again. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 10:29:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20647 for ; Fri, 1 Dec 2000 10:29:27 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D84EF44496; Fri, 1 Dec 2000 09:13:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id CF20444496 for ; Fri, 1 Dec 2000 09:12:52 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 1 Dec 2000 15:12:45 UT Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA17431; Fri, 1 Dec 2000 16:11:21 +0100 (BST) From: Gethin Liddell Organization: Ubiquity Software Corp. To: Anders Kristensen Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain Cc: Jonathan Rosenberg , Sip Mail List , Brett Tate References: <0b0e01c05ba1$a962a350$4301a8c0@broadsoft.com> <3A27BE7D.C5369CA4@dynamicsoft.com> In-Reply-To: <3A27BE7D.C5369CA4@dynamicsoft.com> MIME-Version: 1.0 Message-Id: <00120115124602.23207@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 15:11:07 +0000 Content-Transfer-Encoding: 8bit On Fri, 01 Dec 2000, Anders Kristensen wrote: > > Ah, I see. It's the ACK with SDP that takes the call off hold, not the > INVITE without. That makes much more sense although I'm still sceptical > of the whole notion of modifying media in ACKs as it denies the receiver > the option of rejecting the changes... but if the media in the ACK is a subset of the media in the response (as you suggested) then there is no problem. no? -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 10:33:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20918 for ; Fri, 1 Dec 2000 10:33:42 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A9CC844485; Fri, 1 Dec 2000 09:15:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9BBA14449A for ; Fri, 1 Dec 2000 09:13:13 -0500 (EST) Received: from dynamicsoft.com (ip119.honxr3.ras.tele.dk [195.215.228.119]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA13869; Fri, 1 Dec 2000 10:15:33 -0500 (EST) Message-ID: <3A27C032.7088E88C@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: sip@lists.bell-labs.com Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... References: <000301c05b11$e355da40$04d245ab@cisco.com> <3A2798BB.402E583F@dynamicsoft.com> <0b4601c05ba6$df8b9720$4301a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 16:13:54 +0100 Content-Transfer-Encoding: 7bit Brett Tate wrote: > > > So generally allowing SDP in ACK could work for some operations. I don't > > think it's worth the confusion, though. Better simply to say that ACK is > > for stopping INVITE retransmissions only. If you want to modify media > > settings do a re-INVITE. > > For 3pcc a re-INVITE loop would potentially > get established if both sides keep changing > ports with every re-INVITE (and particularly > when the same port is not used before and > after hold). This is why SDP in ACK for > re-INVITEs is important for 3pcc. Yes, but why would the UA keep changing ports (or anything else in the SDP)? There are many ways SIP UAs can misbehave. This is just another way of misbehaving. For example, is this much different from the fact that a 3pcc controller can't keep either UA from re-inviting over and over again for no good reason? -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 10:35:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA20993 for ; Fri, 1 Dec 2000 10:35:39 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 31FA0444A0; Fri, 1 Dec 2000 09:18:11 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 6FF57444A4 for ; Fri, 1 Dec 2000 09:17:00 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Dec 1 10:14:05 EST 2000 Received: by lists.bell-labs.com (Postfix) id 2A57A44380; Fri, 1 Dec 2000 10:01:46 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id 046414437D for ; Fri, 1 Dec 2000 10:01:46 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA09398; Fri, 1 Dec 2000 10:01:44 -0500 (EST) Message-ID: <3A27BD5B.78EBCB71@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Session progress References: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8735@il27exm02.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 10:01:47 -0500 Content-Transfer-Encoding: 7bit The 183 draft is no longer operative, with the intent of - either folding it into the main spec, as is largely the case now, or - deciding that early media is undesirable and should be abolished. I suppose this bigger question should be discussed at the IETF meeting. Baniel Uri-CUB001 wrote: > > Hello there? > > Looks like either my question below was too basic/stupid or you guys are > still thinking about the answer ? > I will appreciate any response > > Thanks > > Uri > > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri_Baniel-CUB001@email.mot.com] > Sent: Monday, November 27, 2000 1:42 PM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] Session progress > > Hi > > 1) Bis 4.2.1 says: > > "A UAC MUST be prepared to receive media data according to the session > description as soon as it sends an INVITE (or re-INVITE) " > > 2) According the 183 draft that there must be first a two way path > established (or at least the UAC should get first the UAS RTP information) > before the UAC is able to get Alerting/call treatment RTP packets. > > I guess (2) overrides (1) (and is even included in 1 now) > > My question is: Why is the need to have the two way path established for > being able to convey the RTP information from the UAS to the UAC? > > Thanks > Uri > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 11:06:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01095 for ; Fri, 1 Dec 2000 11:06:59 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D07244475; Fri, 1 Dec 2000 10:03:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 1B6F44444D for ; Fri, 1 Dec 2000 10:02:47 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id LAA70061; Fri, 1 Dec 2000 11:02:35 -0500 (EST) Message-ID: <0bcd01c05bb0$686b7b60$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Anders Kristensen" Cc: References: <000301c05b11$e355da40$04d245ab@cisco.com> <3A2798BB.402E583F@dynamicsoft.com> <0b4601c05ba6$df8b9720$4301a8c0@broadsoft.com> <3A27C032.7088E88C@dynamicsoft.com> Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 11:04:38 -0500 Content-Transfer-Encoding: 7bit > > > So generally allowing SDP in ACK could work for some operations. I don't > > > think it's worth the confusion, though. Better simply to say that ACK is > > > for stopping INVITE retransmissions only. If you want to modify media > > > settings do a re-INVITE. > > > > For 3pcc a re-INVITE loop would potentially > > get established if both sides keep changing > > ports with every re-INVITE (and particularly > > when the same port is not used before and > > after hold). This is why SDP in ACK for > > re-INVITEs is important for 3pcc. > > Yes, but why would the UA keep changing ports (or anything else in the > SDP)? There are many ways SIP UAs can misbehave. This is just another > way of misbehaving. For example, is this much different from the fact > that a 3pcc controller can't keep either UA from re-inviting over and > over again for no good reason? That is just it, according to the rfc2543, this is not misbehaving. Changing port and/or connection address is even part of the new advance media scenarios for the upcoming bakeoff. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 11:16:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA04875 for ; Fri, 1 Dec 2000 11:16:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 727A144480; Fri, 1 Dec 2000 10:14:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A915D44461 for ; Fri, 1 Dec 2000 10:13:52 -0500 (EST) Received: from dynamicsoft.com (ip226.honxr4.ras.tele.dk [195.215.92.226]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA14978; Fri, 1 Dec 2000 11:16:10 -0500 (EST) Message-ID: <3A27CE65.FF38E32F@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: Jonathan Rosenberg , Sip Mail List , Brett Tate Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <0b0e01c05ba1$a962a350$4301a8c0@broadsoft.com> <3A27BE7D.C5369CA4@dynamicsoft.com> <00120115124602.23207@gethin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 17:14:29 +0100 Content-Transfer-Encoding: 7bit Gethin Liddell wrote: > > On Fri, 01 Dec 2000, Anders Kristensen wrote: > > > > Ah, I see. It's the ACK with SDP that takes the call off hold, not the > > INVITE without. That makes much more sense although I'm still sceptical > > of the whole notion of modifying media in ACKs as it denies the receiver > > the option of rejecting the changes... > > but if the media in the ACK is a subset of the media in the response > (as you suggested) then there is no problem. no? No, I guess usually there wouldn't be a problem. Although, what if the UAC sent a b= modifier in the ACK SDP which increases the bandwidth of a sendonly stream to something the UAS can't handle? This isn't really different from doing the same thing in a 200 to INVITE, I know, and only goes to show that the model of updating media settings in SIP is a little, shall we say, eccentric at times. Decoupling the reliability mechanism that ACKs really are from INVITEs seem like a jolly good step in the right direction to me. [I like that word "jolly" :)] Anders _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 11:22:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06794 for ; Fri, 1 Dec 2000 11:22:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD34E444C2; Fri, 1 Dec 2000 10:18:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1D935444C1 for ; Fri, 1 Dec 2000 10:17:20 -0500 (EST) Received: from dynamicsoft.com (ip226.honxr4.ras.tele.dk [195.215.92.226]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA15047; Fri, 1 Dec 2000 11:19:35 -0500 (EST) Message-ID: <3A27CF33.C777D7B0@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.73 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: sip@lists.bell-labs.com Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... References: <000301c05b11$e355da40$04d245ab@cisco.com> <3A2798BB.402E583F@dynamicsoft.com> <0b4601c05ba6$df8b9720$4301a8c0@broadsoft.com> <3A27C032.7088E88C@dynamicsoft.com> <0bcd01c05bb0$686b7b60$4301a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 17:17:55 +0100 Content-Transfer-Encoding: 7bit Brett Tate wrote: > > > > > So generally allowing SDP in ACK could work for some operations. I > don't > > > > think it's worth the confusion, though. Better simply to say that ACK > is > > > > for stopping INVITE retransmissions only. If you want to modify media > > > > settings do a re-INVITE. > > > > > > For 3pcc a re-INVITE loop would potentially > > > get established if both sides keep changing > > > ports with every re-INVITE (and particularly > > > when the same port is not used before and > > > after hold). This is why SDP in ACK for > > > re-INVITEs is important for 3pcc. > > > > Yes, but why would the UA keep changing ports (or anything else in the > > SDP)? There are many ways SIP UAs can misbehave. This is just another > > way of misbehaving. For example, is this much different from the fact > > that a 3pcc controller can't keep either UA from re-inviting over and > > over again for no good reason? > > That is just it, according to the rfc2543, this > is not misbehaving. Changing port > and/or connection address is even > part of the new advance media scenarios > for the upcoming bakeoff. Well, that's my point. The point of view of rfc 2543 and the 3pcc controller are not the same here. Both behaviours are legal according to rfc 2543 and both are Bad according to the 3pcc controller. -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 11:38:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA11187 for ; Fri, 1 Dec 2000 11:38:17 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 634E4443BB; Fri, 1 Dec 2000 10:38:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8449E44357 for ; Fri, 1 Dec 2000 10:37:37 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA15520; Fri, 1 Dec 2000 11:39:54 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 11:35:26 -0500 Message-ID: From: Jonathan Rosenberg To: "'Jiri Kuthan'" , "Rosen, Brian" Cc: Jonathan Rosenberg , "'Howard Hart'" , "Henning G. Schulzrinne" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 11:35:25 -0500 Thats great; I'm glad we are getting SIP ALG support in firewalls. But, that doesn't help me deal with the huge numbers of EXISTING firewalls and NATs that are not SIP aware, which will not be upgraded tomorrow. I want to emphasize that this draft proposes an interim solution ONLY, until the time comes when ALGs can be embedded, or proxies are used to control, these firewalls and NATs. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Jiri Kuthan [mailto:kuthan@fokus.gmd.de] > Sent: Thursday, November 30, 2000 12:46 PM > To: Rosen, Brian > Cc: 'Jonathan Rosenberg'; 'Howard Hart'; Henning G. Schulzrinne; > 'sip@lists.bell-labs.com' > Subject: Re: [SIP] FW: I-D ACTION:draft-rosenberg-sip-entfw-00.txt > > > "Rosen, Brian" wrote: > > > > There are a couple of mitigating factors. > > > > One is that the big firewall vendors are starting to > > commit to supporting SIP. No names, sorry, NDA issues! > > For example, Cisco claims to have SIP support in their > latest PIX firewalls 5.2: > http://www.cisco.com/univercd/cc/td/doc/product/iaabu/pix/pix_ > v52/pixrn521.htm#xtocid2350933 > > FYI: The "in parallel with the regular firewall" topic > will be discussed at the MidCom BOF > > Jiri > > -- > Jiri Kuthan http://www.fokus.gmd.de/usr/kuthan > tel:+49-30-34637271 > Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 11:52:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15641 for ; Fri, 1 Dec 2000 11:52:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0E37D44357; Fri, 1 Dec 2000 10:52:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1B1DF44354 for ; Fri, 1 Dec 2000 10:51:43 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA15823 for ; Fri, 1 Dec 2000 11:54:04 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 11:49:36 -0500 Message-ID: From: Jonathan Rosenberg To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Preparing for the next meeting Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 11:49:30 -0500 Folks, One thing has been clear - the amount of open issues on the list is large, and growing. As Dean has indicated, we will be spending real, substantial time on these issues during the meeting. As we've done in past meetings, I need people to help me collect the open issues that still need to be resolved. To that end, I request volunteers to do the following: 1. comb the mails in the archives over a one week period 2. identify issues discussed that did not reach resolution 3. for each issue, put together two PPT slides that quickly state the issue, state proposals made (if any). Send me these slides with a pointer to the first mail on the subject in the archives. Obviously issues span multiple weeks; thats OK. I'll just get multiple slide sets for the same issues that will help give additional perspectives. So, first step is volunteers. We need a lot. We need to comb the archives since the last meeting. We didn't even address all the issues from two meetings ago till the last, but at least I have slides on those issues and can reuse ones discussing still-open issues. I will also post the list of issues to the mailing list (not an invitation for discussion), to get people prepared thinking about solutions. The criteria for volunteering is that you be reasonably clueful on SIP. If you'd like to volunteer, please send me a note stating that. I'll assign you a slot for a week. If you finish that and want another week to look at, you can ask again (only once the first set of slides is handed to me) and you'll get another if available. Slides are due back to me by next Friday. All PPT slides should be without any kind of company logos or design templates or anything. Blank, vanilla, PPT. I'll add an acknowledgement slide at the end of the compiled set listing those who contributed. So, start volunteering! -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 11:54:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16409 for ; Fri, 1 Dec 2000 11:54:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7AF80443F5; Fri, 1 Dec 2000 10:52:28 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 6883444354 for ; Fri, 1 Dec 2000 10:51:55 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eB1GkQZ07851; Fri, 1 Dec 2000 10:51:05 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id eB1Gjv114798; Fri, 1 Dec 2000 10:45:59 -0600 (CST) Received: from ericsson.com (pc050190.exu.ericsson.se [138.85.50.190]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA03285; Fri, 1 Dec 2000 10:45:56 -0600 (CST) Message-ID: <3A27731B.1796F2E4@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Dean Willis Cc: "IETF SIP (E-mail)" Subject: Re: [SIP] Single Line Extension work References: <01d201c05b06$3a2be320$ea036e3f@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 10:44:59 +0100 Content-Transfer-Encoding: 7bit I would leave this call up to Billy since he was one of the most active participants and the team leader. From my perspective, I would prefer to focus on getting SIP finalized before working on this. Cheers! sean Dean Willis wrote: > A while back we had a vigorous discussion going on how to implement the > PBX/Centrex "single line extension" service or get behavior similar to US > residentil "party lines". > > I don't believe I've seen any discussion on this topic for a long time. > Anybody still working on it, or can we declare the effort dead for now? > > -- > Dean > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 13:16:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08304 for ; Fri, 1 Dec 2000 13:16:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BA3104434A; Fri, 1 Dec 2000 12:16:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 9C65844337 for ; Fri, 1 Dec 2000 12:15:16 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id NAA85728; Fri, 1 Dec 2000 13:15:06 -0500 (EST) Message-ID: <0c2a01c05bc2$ebe74840$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Henning Schulzrinne" Cc: "Jonathan Rosenberg" , "'Gethin Liddell'" , "Sip Mail List" References: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> <3A2798BF.D1ABAD1A@dynamicsoft.com> <0b0e01c05ba1$a962a350$4301a8c0@broadsoft.com> <3A27BA8B.66BA322D@cs.columbia.edu> Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 13:17:10 -0500 Content-Transfer-Encoding: 7bit Henning: Thanks for the response. The following is text from what I thought was the decision June 23. The thread was "[SIP] Hold & then re-INVITE without media". http://lists.bell-labs.com/pipermail/sip/2000q2/001125.html +++++++++++++++++++++++++++++ "Brett Tate wrote: > > I think you already answered my question, but maybe this > will provide some clarity. > > For the following question, assume A originally > sent the INVITE containing an SDP > with connection address 0.0.0.0 to B; B replied with 200; > A replied with an ACK. Can an INVITE without SDP > indicate to B that A is no longer "holding B" and will > provide the complete SDP in the ACK? > > A --------------- Invite (no SDP) ----------------------------> B > <-- 200 (SDP with connection address not 0.0.0.0) --- > --- Ack (SDP with connection address not 0.0.0.0) --> This should work. This behavior (no SDP in INVITE, but SDP in ACK) is allowed, actually. Its main use is for the first INVITE, for interop with H.323v1 amongst other things. However, if you can do something in a first INVITE, it is allowed in a re-INVITE, so there you go. -Jonathan R." ++++++++++++++++++++++++++ During the Advanced Media Testing at the last bakeoff, the topic was again raised because some products supported it, and others did not. With Robert Sparks organizing the Advanced Media Testing, it was reiterated by Robert Sparks and myself and dissussed with those present that a re-INVITE without SDP indicates a request to communicate just as an INVITE without SDP would mean prior to a call being established or held. It was documented again August 16, "[SIP] Bakeoff #5 Advanced Scenarios: Media Changes summary for one group" http://lists.bell-labs.com/pipermail/sip/2000q3/002168.html The following is a snippit. ++++++++++++++++++++++++++++ "It was decided that session hold and retrieval did not need to be tested. However the importance of an INVITE without SDP to pull a held party off of hold was reiterated for its use by third party call controllers." ++++++++++++++++++++++++++++ For reference, the following text is from September 4, rfc2543bis-02 section 4.2.1: +++++++++++++++++++++++ "The INVITE method indicates that the user or service is being invited to participate in a session. The message body MAY contain a description of the session to which the callee is being invited. For two-party calls, the caller indicates the type of media it is able to receive and possibly the media it is willing to send as well as their parameters such as network destination. A success response MUST indicate in its message body which media the callee wishes to receive and MAY indicate the media the callee is going to send. The caller MAY choose to omit the request body (i.e., not send a session description) or send a session description that does not list any media type. This indicates that the caller does not know its desired media characteristics until the call has been accepted. In this case, the UAS SHOULD still return a session description in its informational (1xx) or success (2xx) response, containing those media streams and codecs it supports." ++++++++++++++++++++++++ The above text implies an INVITE without SDP indicates a request for any session description that the receiver wishes to allow, and the sender will provide SDP in the ACK. This should translate into having the same meaning in a re-INVITE case. If the receiver is not the one that put the call on hold, the receiver then should not really want to keep the call on hold. Thus it would pass back SDP to allow the call to go non-hold (along with any other media changes it might want to allow). If for some strange reason the receiver wants to keep the call on hold, a hold SDP can be returned in 200 response. And thus it would now be responsible to pull the call off of hold. Henning: What does a re-INVITE without SDP mean? Why would a re-INVITE without SDP have a different meaning from an INVITE without SDP? Just wondering, when was this discussed and agreed upon since I thought the news group and working group agreed upon the opposite? Thanks for a response. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 13:22:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA09759 for ; Fri, 1 Dec 2000 13:22:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 766FF44420; Fri, 1 Dec 2000 12:22:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 557024441C for ; Fri, 1 Dec 2000 12:21:01 -0500 (EST) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA29986; Fri, 1 Dec 2000 10:20:53 -0800 (PST) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ABK03919; Fri, 1 Dec 2000 12:20:48 -0600 (CST) Message-ID: <3A27EC37.8465F804@cisco.com> From: Henry Chen X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: alan.johnston@wcom.com, sip@lists.bell-labs.com, stlevy@cisco.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Attended Transfer Call Flow:draft-ietf-sip-service-examples-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 12:21:44 -0600 Content-Transfer-Encoding: 7bit Hi Alan: In the call flow of Attended Transfer in draft-ietf-sip-service-examples-00.txt, INVITE (F9) and INVITE (F16) have same Call-ID header and same To header, but the From headers are different. I need to confirm that: - Is INVITE (F16) a legal Re-Invite and Shall User C accept it? - If it is legal, what should User C do? Ring (as a new call) or just establishes a new media stream and change the display of calling party (as a same call)? Thanks, Henry _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 13:38:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15196 for ; Fri, 1 Dec 2000 13:38:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D9BD744410; Fri, 1 Dec 2000 12:38:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 276674440D for ; Fri, 1 Dec 2000 12:37:37 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 1 Dec 2000 12:37:18 -0600 (CST) From: Billy Biggs To: Dean Willis Cc: SIP List Subject: Re: [SIP] Single Line Extension work Message-ID: <20001201123718.A32000@div8.net> References: <01d201c05b06$3a2be320$ea036e3f@dynamicsoft.com> <3A27731B.1796F2E4@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A27731B.1796F2E4@ericsson.com>; from sean.olson@ericsson.com on Fri, Dec 01, 2000 at 10:44:59AM +0100 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 12:37:18 -0600 > A while back we had a vigorous discussion going on how to implement > the PBX/Centrex "single line extension" service or get behavior > similar to US residentil "party lines". > > I don't believe I've seen any discussion on this topic for a long > time. Anybody still working on it, or can we declare the effort dead > for now? Jonathan and Henning's draft on multi-party conferencing models is an important step forward in discussing conferencing services such as single line extension. The continuing work on presence extensions and event subscriptions also helps. But until the puzzle fits together a little more, the single line extension work is quite fluffy. Hopefully this will change in the next few months. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 13:57:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21093 for ; Fri, 1 Dec 2000 13:57:47 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9DA9544438; Fri, 1 Dec 2000 12:51:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 46032443EB for ; Fri, 1 Dec 2000 12:50:00 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 1 Dec 2000 12:49:35 -0600 (CST) From: Billy Biggs To: Henry Chen Cc: alan.johnston@wcom.com, sip@lists.bell-labs.com, stlevy@cisco.com Subject: Re: [SIP] Attended Transfer Call Flow:draft-ietf-sip-service-examples-00.txt Message-ID: <20001201124935.A32143@div8.net> References: <3A27EC37.8465F804@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A27EC37.8465F804@cisco.com>; from hjlechen@cisco.com on Fri, Dec 01, 2000 at 12:21:44PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 12:49:35 -0600 Henry Chen (hjlechen@cisco.com): > In the call flow of Attended Transfer in > draft-ietf-sip-service-examples-00.txt, INVITE (F9) and INVITE (F16) > have same Call-ID header and same To header, but the From headers are > different. > > I need to confirm that: > - Is INVITE (F16) a legal Re-Invite and Shall User C accept it? > - If it is legal, what should User C do? > Ring (as a new call) or just establishes a new media stream and > change the display of calling party (as a same call)? This call flow has two glaring errors: 1. The UA made two calls with the same Call-ID, but did not add a From tag. 2. The UA which received the REFER made a new call using the same Call-ID as the call leg the REFER was received on. Ouch. It is now generally accepted that the call-id should not be used to infer that an incoming call should replace or have any association with an ongoing call. Doing so leads to problems in some forking situations, and is a general overloading of the meaning. For a cleaner method of signalling attended transfer where you don't want the target's phone to ring, please see (and comment on) our replaces draft (draft-biggs-sip-replaces-00.txt): http://www.sip-happens.com/replaces/ -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 14:39:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA03890 for ; Fri, 1 Dec 2000 14:39:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB16044402; Fri, 1 Dec 2000 13:39:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1FCC944354 for ; Fri, 1 Dec 2000 13:38:51 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA18076; Fri, 1 Dec 2000 14:41:11 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 14:36:43 -0500 Message-ID: From: Jonathan Rosenberg To: Anders Kristensen , Brett Tate Cc: sip@lists.bell-labs.com Subject: RE: [SIP] as if there wasn't enough traffic on this darn list... MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 14:36:39 -0500 OK, obviously there is much to be said here. Neil writes: >Or indeed ACK. Is late SDP in ACK for 3pcc really that >difficult to support? Some people certainly do it already and I >plan on testing for this at the upcoming bakeoff. First off, let me motivate the change in the 3pcc spec. The problem is that the controller has to delay sending an ACK to one of the UAs (say UA A) until it comples an INVITE transaction with the other (say UA B) (or at least until it gets the 200 OK). Now, the problem is that while this INVITE transaction is pending with B, A is going to be retransmitting the 200 OK. If it does not receive an ACK within 32 seconds, it gives up and the call is terminated. However, the INVITE transaction pending with B may take more than 32 seconds to complete. As such, the setup may fail. So, the problem is twofold (1) the setup failure when the second INVITE takes too long to terminate, and (2) the excessive 200 OK retransmissions that serve no purpose. Its all because ACK is serving two roles; to complete the transaction, and to carry SDP. Now, a separate issue is my, er, well received proposal to eliminate SDP from ACK. Brian writes: >> Right now, you can carry SDP in the INV/200/ACK exchange in two ways. You >> can send nothing in the INVITE, followed by SDP in the 200, and then SDP in >> ACK (and fortunately I don't know anyone who actively does this). > >I am specifically aware of a commerical implementation that actively does this. OK. Removal of things can only happen if they were not commercially implemented. It was my hope that none of the SIP-H.323 converters were really deployed yet, and that furthermore, we wouldn't see much v1 traffic. If thats not the case, the proposal is dead. Re: the PRACK proposal, I'll buy into the argument that overlapping initial INVITEs is even more horrible to deal with then the various SDP cases, so I'll back off on that too. Dave Oran writes: >Hmmm, I would simplify by going the OTHER direction and allowing SDP in any leg of an >INVITE transaction. The meaning would be coupled with the state the transaction is in. This >allows for 3-way negotiation of SDP, and allows very simple rules: the SDP you operate on, >and reply to is the one you received in the last Request (INVITE or PRACK). > >The simple call scenarios don't get any more complicated: you use the most recent SDP sent, >otherwise the most recent one you received. > >That gives much more flexibility and eliminates the special case rules as well. I guess what I want is some kind of simple model, along the lines that Dave is proposing. The model needs to work across INVITE, ACK, multiple provisionals, and 200 responses. I.e., how would we handle something like this | INV SDP1 | | -----------------------> | | | | 183 SDP2 | | <----------------------- | | PRACK SDP3 | | -----------------------> | | | | 200 PRACK SDP4 | | <----------------------- | | | | 200 INVITE SDP5 | | <----------------------- | | | | ACK SDP6 | | -----------------------> | | | | | UAC UAS Now, there are *6* SDPs here. WHat happens if there is some message reordering; for example, if the 200 PRACK arrives after the 200 OK (assuming we allow SDP in PRACK responses; I don't recall discussing it. The idea is to show that this is all complex to handle in the general case). For a general mechanism like Dave is proposing, there needs to be a well-defined ordering amongst which SDP are used to determine "the most recent". Anders has pointed out some issues as well: >When a UA does a re-INVITE with updated SDP it effectively proposes new >media settings. If for whatever reason the UAS can't or won't honour >those settings it can reject the INVITE. If media settings are updated >in an ACK there's no way for the UAS to tell the UAC that it doesn't >have enough bandwidth or it doesn't support any of those codecs etc. In more general terms, which of the SDP to use in the definition of the session depends not only on ordering, but on the messages themselves. Now, this is not unsolvable, but will take some work to sort out. Robert had suggested another use to the SDP-everywhere counter-approach: >eg >INVITE has SDP with m=audio 12150 RTP/AVP 0 2 4 8 >200 OK selects m=audio 12150 RTP/AVP 0 2 but caller's UA doesn't support >multiple codecs or wants to use ony one vocoder, so send >ACK re-selecting m=audio 12150 RTP/AVP 0 We must also consider backwards compatibility. I don't know how existing UAs would react to this kind of flow. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] > Sent: Friday, December 01, 2000 11:18 AM > To: Brett Tate > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] as if there wasn't enough traffic on this darn > list... > > > > > Brett Tate wrote: > > > > > > > So generally allowing SDP in ACK could work for some > operations. I > > don't > > > > > think it's worth the confusion, though. Better simply > to say that ACK > > is > > > > > for stopping INVITE retransmissions only. If you want > to modify media > > > > > settings do a re-INVITE. > > > > > > > > For 3pcc a re-INVITE loop would potentially > > > > get established if both sides keep changing > > > > ports with every re-INVITE (and particularly > > > > when the same port is not used before and > > > > after hold). This is why SDP in ACK for > > > > re-INVITEs is important for 3pcc. > > > > > > Yes, but why would the UA keep changing ports (or > anything else in the > > > SDP)? There are many ways SIP UAs can misbehave. This is > just another > > > way of misbehaving. For example, is this much different > from the fact > > > that a 3pcc controller can't keep either UA from > re-inviting over and > > > over again for no good reason? > > > > That is just it, according to the rfc2543, this > > is not misbehaving. Changing port > > and/or connection address is even > > part of the new advance media scenarios > > for the upcoming bakeoff. > > Well, that's my point. The point of view of rfc 2543 and the 3pcc > controller are not the same here. Both behaviours are legal > according to > rfc 2543 and both are Bad according to the 3pcc controller. > > -- > Anders Kristensen > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 14:54:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA06375 for ; Fri, 1 Dec 2000 14:54:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0AAE54442A; Fri, 1 Dec 2000 13:54:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 52B1C443E1 for ; Fri, 1 Dec 2000 13:53:53 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA18258; Fri, 1 Dec 2000 14:56:11 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 14:51:44 -0500 Message-ID: From: Jonathan Rosenberg To: "'Brett Tate'" , Henning Schulzrinne Cc: Jonathan Rosenberg , "'Gethin Liddell'" , Sip Mail List Subject: RE: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invi te response] MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 14:51:39 -0500 My perception of what was agreed to was not "an INVITE without SDP takes a party off of hold", but rather, "a re-INVITE can have no SDP in the INVITE request", for the reason, as I stated, that a normal INVITE can have no SDP in it. Whether the implied semantics of re-INVITE with no SDP is "taking someone off hold", is worth discussing. Anyway, if we had some general model of the sort where "the last SDP you received is the active one from the other participant", as Dave has suggested, then the semantics would, in fact, translate to taking the party off hold. However, as Anders has correctly pointed out, its not the absence of SDP in INVITE that does this (since the "previous" SDP still is one with a held media stream), but rather the updated SDP in ACK. In this case, the statement you should make is "SDP in an ACK, following a re-INVITE with no SDP, following reinvite transaction that put a call on hold, takes the party off hold". A mouthful, to be sure, but thats what you are really saying. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Friday, December 01, 2000 1:17 PM > To: Henning Schulzrinne > Cc: Jonathan Rosenberg; 'Gethin Liddell'; Sip Mail List > Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the > re-invite response] > > > Henning: Thanks for the response. > > The following is text from what I thought was the > decision June 23. The thread was > "[SIP] Hold & then re-INVITE without media". > http://lists.bell-labs.com/pipermail/sip/2000q2/001125.html > > +++++++++++++++++++++++++++++ > "Brett Tate wrote: > > > > I think you already answered my question, but maybe this > > will provide some clarity. > > > > For the following question, assume A originally > > sent the INVITE containing an SDP > > with connection address 0.0.0.0 to B; B replied with 200; > > A replied with an ACK. Can an INVITE without SDP > > indicate to B that A is no longer "holding B" and will > > provide the complete SDP in the ACK? > > > > A --------------- Invite (no SDP) ----------------------------> B > > <-- 200 (SDP with connection address not 0.0.0.0) --- > > --- Ack (SDP with connection address not 0.0.0.0) --> > > This should work. This behavior (no SDP in INVITE, but SDP in ACK) is > allowed, actually. Its main use is for the first INVITE, for interop > with H.323v1 amongst other things. However, if you can do > something in a > first INVITE, it is allowed in a re-INVITE, so there you go. > > -Jonathan R." > ++++++++++++++++++++++++++ > > > During the Advanced Media Testing at the last > bakeoff, the topic was again raised because > some products supported it, and others did not. > With Robert Sparks organizing the Advanced > Media Testing, it was reiterated by Robert Sparks > and myself and dissussed with those present that > a re-INVITE without SDP indicates a request to > communicate just as an INVITE without SDP > would mean prior to a call being established or held. > > It was documented again August 16, "[SIP] Bakeoff > #5 Advanced Scenarios: Media Changes > summary for one group" > http://lists.bell-labs.com/pipermail/sip/2000q3/002168.html > The following is a snippit. > ++++++++++++++++++++++++++++ > "It was decided that session hold and retrieval did > not need to be tested. However the importance of an > INVITE without SDP to pull a held party off of hold > was reiterated for its use by third party call controllers." > ++++++++++++++++++++++++++++ > > > For reference, the following text is from > September 4, rfc2543bis-02 section 4.2.1: > +++++++++++++++++++++++ > "The INVITE method indicates that the user or > service is being invited to participate in a session. > The message body MAY contain a description of > the session to which the callee is being invited. > For two-party calls, the caller indicates the type > of media it is able to receive and possibly the > media it is willing to send as well as their > parameters such as network destination. A > success response MUST indicate in its message > body which media the callee wishes to receive > and MAY indicate the media the callee is going > to send. > > The caller MAY choose to omit the request > body (i.e., not send a session description) or > send a session description that does not list > any media type. This indicates that the caller > does not know its desired media characteristics > until the call has been accepted. In this case, the > UAS SHOULD still return a session description > in its informational (1xx) or success (2xx) > response, containing those media streams and > codecs it supports." > ++++++++++++++++++++++++ > > The above text implies an INVITE without > SDP indicates a request for any session > description that the receiver wishes to allow, > and the sender will provide SDP in the ACK. > This should translate into having the same > meaning in a re-INVITE case. If the receiver > is not the one that put the call on hold, the > receiver then should not really want to keep > the call on hold. Thus it would pass back SDP > to allow the call to go non-hold (along with any > other media changes it might want to allow). > If for some strange reason the receiver wants > to keep the call on hold, a hold SDP can be > returned in 200 response. And thus it would > now be responsible to pull the call off of hold. > > Henning: > > What does a re-INVITE without SDP mean? > Why would a re-INVITE without SDP have > a different meaning from an INVITE without > SDP? Just wondering, when was this > discussed and agreed upon since I thought > the news group and working group agreed > upon the opposite? > > Thanks for a response. > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 15:08:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09229 for ; Fri, 1 Dec 2000 15:08:43 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6609E44454; Fri, 1 Dec 2000 14:02:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 2B01944453 for ; Fri, 1 Dec 2000 14:01:22 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA18406; Fri, 1 Dec 2000 15:03:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 14:59:14 -0500 Message-ID: From: Jonathan Rosenberg To: "'Baniel Uri-CUB001'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Session progress MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 14:59:12 -0500 > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Monday, November 27, 2000 2:42 PM > To: 'sip@lists.bell-labs.com' > Subject: [SIP] Session progress > > > Hi > > 1) Bis 4.2.1 says: > > "A UAC MUST be prepared to receive media data according to > the session description as soon as it sends an INVITE (or re-INVITE) " > > 2) According the 183 draft that there must be first a two way > path established (or at least the UAC should get first the > UAS RTP information) before the UAC is able to get > Alerting/call treatment RTP packets. > > I guess (2) overrides (1) (and is even included in 1 now) > > My question is: Why is the need to have the two way path > established for being able to convey the RTP information from > the UAS to the UAC? The reason the 183 draft discussed this approach, I believe, was to deal with security. Since the 183 could be authenticated, and could also be used for security preconditions, the INV/183 exchange was needed to ensure that I was gettign media only from the party that sent me the 183. If I open up my RTP ports upon sending the INVITE, and the INVITE is in the clear, anyone can send me audio and I'll happily play it out. This, however, deserves more attention and is worth discussing at IETF, as Henning has pointed out. I've already put in on the list of issues. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 15:23:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12324 for ; Fri, 1 Dec 2000 15:23:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3D5FF44465; Fri, 1 Dec 2000 14:14:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7670544463 for ; Fri, 1 Dec 2000 14:13:34 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA18617; Fri, 1 Dec 2000 15:15:52 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 15:11:24 -0500 Message-ID: From: Jonathan Rosenberg To: "'Gethin Liddell'" , Brett Tate Cc: Sip Mail List Subject: RE: [SIP] 3PCC and the re-invite response MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 15:11:17 -0500 > -----Original Message----- > From: Gethin Liddell [mailto:gethin@ubiquity.net] > Sent: Friday, December 01, 2000 9:58 AM > To: Brett Tate > Cc: Sip Mail List > Subject: Re: [SIP] 3PCC and the re-invite response > > > On Fri, 01 Dec 2000, Brett Tate wrote: > > > I actually think that the best solution for 3PCC is an > amalgamation of > > > the late ACK and re-invite proposals: > > > > > > A Controller B > > > | INV held SDP | | time t = 0 > > > |<------------------| | > > > | | | > > > | 200 SDP A1 | | > > > |-----------------> | | > > > | | | > > > | ACK | | > > > |<------------------| | > > > | | | > > > | | INV NO SDP | > > > | |----------------->| (1) > > > | | | > > > | | 200 SDP B | > > > | |<-----------------| > > > | INV SDP B | | > > > |<------------------| | > > > | | | > > > | 200 SDP A2 | | > > > |-----------------> | | > > > | | | > > > | | ACK SDP A2 | > > > | ACK |----------------->| > > > |<------------------| | > > > | | | > > > | | RTP | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > | | | > > > | | | > > > | | | > > > | | | > > > | | | > > > | | | > > > | | | > > > | | | > > > > > > my only query is who do we late ack at (1), agent A or agent B. > > > > It would be best to send it first to the party that the 3pcc > > is controlling since it should definitely support it, and it > > is the one trying to pull the other party off of hold. In the > > above scenario, I am assuming that B put party A on > > hold (the picture isn't complete). Thus the INVITE > > without SDP should be sent to B first. > > the picture is actually the call flow that will occur at the > initiation > of a 3PCC session. so `b' has not put `a' on hold, the contoller has > put `a' on hold whilst it tries to contact b'. once it has contacted > `b', it is able to quickly bring `a' into the RTP session > because there > is no user intervention. Right. This actually seems like a reasonable compromise. There can still be delays if the re-INVITE triggers some kind of UI interaction to approve it, but that is less likely, and in any case, the user is already there, so the response should come quickly. > > if we were to initiate the late ACK scenario to 'a' at (1) then as > Gonzalo pointed out, `a' may be waiting around a long time for an ACK > to appear because we would have to wait for the user to answer the > phone. This bit I just don't follow. Point (1) in the call flow above is not an ACK, but an INVITE to B while A is on hold; there is no late ACK here at all. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 15:34:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15772 for ; Fri, 1 Dec 2000 15:34:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A7EDE4444C; Fri, 1 Dec 2000 14:22:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id ED23B443D4 for ; Fri, 1 Dec 2000 14:21:45 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA18702; Fri, 1 Dec 2000 15:23:53 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 15:19:25 -0500 Message-ID: From: Jonathan Rosenberg To: "'Vaidyanathan Anantharaman'" , sip@lists.bell-labs.com Subject: RE: [SIP] Call Disposition header MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 15:19:17 -0500 There is a Request-Disposition header defined in: http://www.cs.columbia.edu/~jdrosen/papers/draft-ietf-sip-callerprefs-03.txt and a Content-Disposition now defined in the bis draft. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Vaidyanathan Anantharaman [mailto:vaidy.raman@wipro.com] > Sent: Friday, December 01, 2000 4:04 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Call Disposition header > > > Hi, > > I had seen a "call disposition" header for SIP being > mentioned in some SIP > documents. But I dont' find this being discussed in > RFC2543bis or any SIP > drafts. > > Is it described in some draft which I may have overlooked or > is it not being > used anymore? If such a draft is avlble, could somebody > please point me to > that? > > Thanks very much. > -Vaidi > Wipro Technologies > Bangalore, India > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 15:47:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA17993 for ; Fri, 1 Dec 2000 15:47:42 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 70A3A44481; Fri, 1 Dec 2000 14:30:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 297FF4446D for ; Fri, 1 Dec 2000 14:29:14 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA18766; Fri, 1 Dec 2000 15:31:13 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 15:26:45 -0500 Message-ID: From: Jonathan Rosenberg To: "'Kim, DongSung'" , sip@lists.bell-labs.com Subject: RE: [SIP] Processing BYE request at Proxy MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="KS_C_5601-1987" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 15:26:42 -0500 > -----Original Message----- > From: Kim, DongSung [mailto:kimdongsung@lgcit.com] > Sent: Wednesday, November 29, 2000 8:23 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Processing BYE request at Proxy > > > I have questions about BYE request.. My questions are two > > > I am a Proxy. > And I have received INVITE request from client and forked that to > downstream.(now there is server and client call state in my proxy) > And then I have receive BYE request which has the same > call-leg with previous INVITE request but has lower CSeq than > previous INVITE request. > > If I were UAS, I could reply 400(bad request). > But I am proxy, So What Can I do in this case?(According to > SPEC, Proxy cannot generate final response to BYE request) > > Of course, this situation is exceptional, But one of possible > situation. Proxies are transactional devices. They forward requests, and forward responses. Each transaction is independent. A proxy can, through means at its own disposal, reconstruct call state by observing messages. But, it is not the job of the proxy to try to emulate the responses the UA would send. So, to directly answer the question, the proxy will proxy the BYE request as normal. The request is rejected by the UA. The response is forwarded by the proxy. > > > I am a proxy. > And I have received INVITE request from client and forked > that to down stream.. > And then I have received none-200 final responses from all > branches.... so I have forwarded lowest numbered final > response to upstream. > But before I receive ACK for final response from upstream, I > receive BYE request which has same call leg with previous > INVITE request and has higher CSeq than previous INVITE request. > According to SPEC, Proxy cannot generate final response to > BYE request.. So there is no way but to simply forking BYE > request to downstream. I think this generates unnecessary > network traffic. > I think If proxy could generated final response to BYE > request without forking BYE request to downstream in this > special case, there would be network bandwidth savings > without malfunction. > I want your opinion about this issue No. Proxies do not respond to requests in this way. Normally, if the UA hangs up before a final response, it sends CANCEL. If it did send BYE, that BYE is forwarded according to normal proxy handling. If there is a Route header, its used. If not, its forked. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 15:57:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA20322 for ; Fri, 1 Dec 2000 15:57:48 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5647C44452; Fri, 1 Dec 2000 14:33:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id CE25844452 for ; Fri, 1 Dec 2000 14:32:54 -0500 (EST) Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id PAA07482; Fri, 1 Dec 2000 15:31:47 -0500 (EST) Message-ID: <3A280AC4.1F998630@cisco.com> From: Manoj Bhatia Organization: Cisco Systems, RTP, NC, USA. X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Anders Kristensen , Brett Tate , sip@lists.bell-labs.com Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... References: Content-Type: multipart/alternative; boundary="------------0AF48E0792DD313967580D88" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 15:32:04 -0500 --------------0AF48E0792DD313967580D88 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I wonder why there is an assumption that the 3pcc -00 draft has not been implemented so far. At the fifth bakeoff , there were at least 4-5 working implementations on this and the 6th bakeoff would have more. Further in the call flow below, the fact that a PRACK can change SDP from the initial INVITE defeats all the QoS reservation that manyfolks draft proposes. So, making rules that 1) A change in SDP can only be introduced via re-INVITEs is a safe assumption to have. 2) SDP in PRACK not allowed; ( rules need to be clarified under the context of 'manyfolks' draft and not under '3pcc' or SIP in general.) would help a bit. As per Robert's proposal to a two-way handshake on codec negotiation , we are almost close to H.323/H.245 now ! Surely, it would cause hiccups to SIP-UAs today but may eventually solve the negotiation issues later. Making some strict rules now combining 3pcc and 'manyfolks' drafts on PRACK especially would help. thanks -manoj Jonathan Rosenberg wrote: > OK, obviously there is much to be said here. > > Neil writes: > >Or indeed ACK. Is late SDP in ACK for 3pcc really that > >difficult to support? Some people certainly do it already and I > >plan on testing for this at the upcoming bakeoff. > > First off, let me motivate the change in the 3pcc spec. The problem is that > the controller has to delay sending an ACK to one of the UAs (say UA A) > until it comples an INVITE transaction with the other (say UA B) (or at > least until it gets the 200 OK). Now, the problem is that while this INVITE > transaction is pending with B, A is going to be retransmitting the 200 OK. > If it does not receive an ACK within 32 seconds, it gives up and the call is > terminated. However, the INVITE transaction pending with B may take more > than 32 seconds to complete. As such, the setup may fail. So, the problem is > twofold (1) the setup failure when the second INVITE takes too long to > terminate, and (2) the excessive 200 OK retransmissions that serve no > purpose. Its all because ACK is serving two roles; to complete the > transaction, and to carry SDP. > > Now, a separate issue is my, er, well received proposal to eliminate SDP > from ACK. > > Brian writes: > >> Right now, you can carry SDP in the INV/200/ACK exchange in two ways. You > >> can send nothing in the INVITE, followed by SDP in the 200, and then SDP > in > >> ACK (and fortunately I don't know anyone who actively does this). > > > >I am specifically aware of a commerical implementation that actively does > this. > > OK. Removal of things can only happen if they were not commercially > implemented. It was my hope that none of the SIP-H.323 converters were > really deployed yet, and that furthermore, we wouldn't see much v1 traffic. > If thats not the case, the proposal is dead. > > Re: the PRACK proposal, I'll buy into the argument that overlapping initial > INVITEs is even more horrible to deal with then the various SDP cases, so > I'll back off on that too. > > Dave Oran writes: > >Hmmm, I would simplify by going the OTHER direction and allowing SDP in any > leg of an > >INVITE transaction. The meaning would be coupled with the state the > transaction is in. This > >allows for 3-way negotiation of SDP, and allows very simple rules: the SDP > you operate on, > >and reply to is the one you received in the last Request (INVITE or PRACK). > > > >The simple call scenarios don't get any more complicated: you use the most > recent SDP sent, > >otherwise the most recent one you received. > > > >That gives much more flexibility and eliminates the special case rules as > well. > > I guess what I want is some kind of simple model, along the lines that Dave > is proposing. The model needs to work across INVITE, ACK, multiple > provisionals, and 200 responses. I.e., how would we handle something like > this > > | INV SDP1 | > | -----------------------> | > | | > | 183 SDP2 | > | <----------------------- | > | PRACK SDP3 | > | -----------------------> | > | | > | 200 PRACK SDP4 | > | <----------------------- | > | | > | 200 INVITE SDP5 | > | <----------------------- | > | | > | ACK SDP6 | > | -----------------------> | > | | > | | > > UAC UAS > > Now, there are *6* SDPs here. WHat happens if there is some message > reordering; for example, if the 200 PRACK arrives after the 200 OK (assuming > we allow SDP in PRACK responses; I don't recall discussing it. The idea is > to show that this is all complex to handle in the general case). > > For a general mechanism like Dave is proposing, there needs to be a > well-defined ordering amongst which SDP are used to determine "the most > recent". Anders has pointed out some issues as well: > > >When a UA does a re-INVITE with updated SDP it effectively proposes new > >media settings. If for whatever reason the UAS can't or won't honour > >those settings it can reject the INVITE. If media settings are updated > >in an ACK there's no way for the UAS to tell the UAC that it doesn't > >have enough bandwidth or it doesn't support any of those codecs etc. > > In more general terms, which of the SDP to use in the definition of the > session depends not only on ordering, but on the messages themselves. > > Now, this is not unsolvable, but will take some work to sort out. > > Robert had suggested another use to the SDP-everywhere counter-approach: > > >eg > >INVITE has SDP with m=audio 12150 RTP/AVP 0 2 4 8 > >200 OK selects m=audio 12150 RTP/AVP 0 2 but caller's UA doesn't support > >multiple codecs or wants to use ony one vocoder, so send > >ACK re-selecting m=audio 12150 RTP/AVP 0 > > We must also consider backwards compatibility. I don't know how existing UAs > would react to this kind of flow. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Anders Kristensen [mailto:akristensen@dynamicsoft.com] > > Sent: Friday, December 01, 2000 11:18 AM > > To: Brett Tate > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] as if there wasn't enough traffic on this darn > > list... > > > > > > > > > > Brett Tate wrote: > > > > > > > > > So generally allowing SDP in ACK could work for some > > operations. I > > > don't > > > > > > think it's worth the confusion, though. Better simply > > to say that ACK > > > is > > > > > > for stopping INVITE retransmissions only. If you want > > to modify media > > > > > > settings do a re-INVITE. > > > > > > > > > > For 3pcc a re-INVITE loop would potentially > > > > > get established if both sides keep changing > > > > > ports with every re-INVITE (and particularly > > > > > when the same port is not used before and > > > > > after hold). This is why SDP in ACK for > > > > > re-INVITEs is important for 3pcc. > > > > > > > > Yes, but why would the UA keep changing ports (or > > anything else in the > > > > SDP)? There are many ways SIP UAs can misbehave. This is > > just another > > > > way of misbehaving. For example, is this much different > > from the fact > > > > that a 3pcc controller can't keep either UA from > > re-inviting over and > > > > over again for no good reason? > > > > > > That is just it, according to the rfc2543, this > > > is not misbehaving. Changing port > > > and/or connection address is even > > > part of the new advance media scenarios > > > for the upcoming bakeoff. > > > > Well, that's my point. The point of view of rfc 2543 and the 3pcc > > controller are not the same here. Both behaviours are legal > > according to > > rfc 2543 and both are Bad according to the 3pcc controller. > > > > -- > > Anders Kristensen > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Manoj Bhatia | | | manojb@cisco.com | :|: :|: 7025 Kit Creek Road, RTP, NC - 27709 | :|||||: :|||||: Ph: 919-392-3873 Fax:919-392-6801 | C i s c o S y s t e m s --------------0AF48E0792DD313967580D88 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit I wonder why there is an assumption that the 3pcc -00 draft has not been
implemented so far. At the fifth bakeoff , there
were  at least 4-5 working implementations on this and the 6th bakeoff
would have more.

Further in the call flow below, the fact that a PRACK can change SDP from the initial
INVITE defeats all the QoS reservation that manyfolks draft proposes.

So,  making rules that
1) A  change in SDP can only be introduced via re-INVITEs is a safe assumption to have.
2) SDP in PRACK not allowed; ( rules need to be clarified under the context of 'manyfolks' draft
and not under '3pcc' or SIP in general.) would help a bit.

As per Robert's proposal to a two-way handshake on codec negotiation , we are almost
close to H.323/H.245 now !
Surely, it would cause hiccups to SIP-UAs today but may eventually solve the
negotiation issues later.

Making some strict rules now combining 3pcc and 'manyfolks' drafts on PRACK
especially would help.

thanks
-manoj
 
 

Jonathan Rosenberg wrote:

OK, obviously there is much to be said here.

Neil writes:
>Or indeed ACK. Is late SDP in ACK for 3pcc really that
>difficult to support? Some people certainly do it already and I
>plan on testing for this at the upcoming bakeoff.

First off, let me motivate the change in the 3pcc spec. The problem is that
the controller has to delay sending an ACK to one of the UAs (say UA A)
until it comples an INVITE transaction with the other (say UA B) (or at
least until it gets the 200 OK). Now, the problem is that while this INVITE
transaction is pending with B, A is going to be retransmitting the 200 OK.
If it does not receive an ACK within 32 seconds, it gives up and the call is
terminated. However, the INVITE transaction pending with B may take more
than 32 seconds to complete. As such, the setup may fail. So, the problem is
twofold (1) the setup failure when the second INVITE takes too long to
terminate, and (2) the excessive 200 OK retransmissions that serve no
purpose. Its all because ACK is serving two roles; to complete the
transaction, and to carry SDP.

Now, a separate issue is my, er, well received proposal to eliminate SDP
from ACK.

Brian writes:
>> Right now, you can carry SDP in the INV/200/ACK exchange in two ways. You
>> can send nothing in the INVITE, followed by SDP in the 200, and then SDP
in
>> ACK (and fortunately I don't know anyone who actively does this).
>
>I am specifically aware of a commerical implementation that actively does
this.

OK. Removal of things can only happen if they were not commercially
implemented. It was my hope that none of the SIP-H.323 converters were
really deployed yet, and that furthermore, we wouldn't see much v1 traffic.
If thats not the case, the proposal is dead.

Re: the PRACK proposal, I'll buy into the argument that overlapping initial
INVITEs is even more horrible to deal with then the various SDP cases, so
I'll back off on that too.

Dave Oran writes:
>Hmmm, I would simplify by going the OTHER direction and allowing SDP in any
leg of an
>INVITE transaction. The meaning would be coupled with the state the
transaction is in. This
>allows for 3-way negotiation of SDP, and allows very simple rules: the SDP
you operate on,
>and reply to is the one you received in the last Request (INVITE or PRACK).
>
>The simple call scenarios don't get any more complicated: you use the most
recent SDP sent,
>otherwise the most recent one you received.
>
>That gives much more flexibility and eliminates the special case rules as
well.

I guess what I want is some kind of simple model, along the lines that Dave
is proposing. The model needs to work across INVITE, ACK, multiple
provisionals, and 200 responses. I.e., how would we handle something like
this

            |  INV SDP1                |
            | -----------------------> |
            |                          |
            |  183 SDP2                |
            | <----------------------- |
            |  PRACK SDP3              |
            | -----------------------> |
            |                          |
            |  200 PRACK SDP4          |
            | <----------------------- |
            |                          |
            |  200 INVITE SDP5         |
            | <----------------------- |
            |                          |
            |  ACK SDP6                |
            | -----------------------> |
            |                          |
            |                          |

           UAC                        UAS

Now, there are *6* SDPs here. WHat happens if there is some message
reordering; for example, if the 200 PRACK arrives after the 200 OK (assuming
we allow SDP in PRACK responses; I don't recall discussing it. The idea is
to show that this is all complex to handle in the general case).

For a general mechanism like Dave is proposing, there needs to be a
well-defined ordering amongst which SDP are used to determine "the most
recent". Anders has pointed out some issues as well:

>When a UA does a re-INVITE with updated SDP it effectively proposes new
>media settings. If for whatever reason the UAS can't or won't honour
>those settings it can reject the INVITE. If media settings are updated
>in an ACK there's no way for the UAS to tell the UAC that it doesn't
>have enough bandwidth or it doesn't support any of those codecs etc.

In more general terms, which of the SDP to use in the definition of the
session depends not only on ordering, but on the messages themselves.

Now, this is not unsolvable, but will take some work to sort out.

Robert had suggested another use to the SDP-everywhere counter-approach:

>eg
>INVITE has SDP with m=audio 12150 RTP/AVP 0 2 4 8
>200 OK selects m=audio 12150 RTP/AVP 0 2 but caller's UA doesn't support
>multiple codecs or wants to use ony one vocoder, so send
>ACK re-selecting m=audio 12150 RTP/AVP 0

We must also consider backwards compatibility. I don't know how existing UAs
would react to this kind of flow.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Anders Kristensen [mailto:akristensen@dynamicsoft.com]
> Sent: Friday, December 01, 2000 11:18 AM
> To: Brett Tate
> Cc: sip@lists.bell-labs.com
> Subject: Re: [SIP] as if there wasn't enough traffic on this darn
> list...
>
>
>
>
> Brett Tate wrote:
> >
> > > > > So generally allowing SDP in ACK could work for some
> operations. I
> > don't
> > > > > think it's worth the confusion, though. Better simply
> to say that ACK
> > is
> > > > > for stopping INVITE retransmissions only. If you want
> to modify media
> > > > > settings do a re-INVITE.
> > > >
> > > > For 3pcc a re-INVITE loop would potentially
> > > > get established if both sides keep changing
> > > > ports with every re-INVITE (and particularly
> > > > when the same port is not used before and
> > > > after hold).  This is why SDP in ACK for
> > > > re-INVITEs is important for 3pcc.
> > >
> > > Yes, but why would the UA keep changing ports (or
> anything else in the
> > > SDP)? There are many ways SIP UAs can misbehave. This is
> just another
> > > way of misbehaving. For example, is this much different
> from the fact
> > > that a 3pcc controller can't keep either UA from
> re-inviting over and
> > > over again for no good reason?
> >
> > That is just it, according to the rfc2543, this
> > is not misbehaving.  Changing port
> > and/or connection address is even
> > part of the new advance media scenarios
> > for the upcoming bakeoff.
>
> Well, that's my point. The point of view of rfc 2543 and the 3pcc
> controller are not the same here. Both behaviours are legal
> according to
> rfc 2543 and both are Bad according to the 3pcc controller.
>
> --
> Anders Kristensen
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Manoj Bhatia                           |        |         |
manojb@cisco.com                       |       :|:       :|:
7025 Kit Creek Road, RTP, NC - 27709   |     :|||||:   :|||||:
Ph: 919-392-3873  Fax:919-392-6801     |  C i s c o S y s t e m s
  --------------0AF48E0792DD313967580D88-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 16:03:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21763 for ; Fri, 1 Dec 2000 16:03:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0CD794448E; Fri, 1 Dec 2000 14:34:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9AF144448B for ; Fri, 1 Dec 2000 14:33:37 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA18826; Fri, 1 Dec 2000 15:35:53 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 15:31:25 -0500 Message-ID: From: Igor Slepchin To: "'Brett Tate'" , Jonathan Rosenberg , "'Gethin Liddell'" , Sip Mail List Subject: RE: [SIP] 3PCC and the re-invite response MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 15:31:15 -0500 I don't see how re-INVITE with no SDP helps to solve the SDP exchange loop problem (or nearly any other problem). The UA is equally likely (or, rather, unlikely) to randomly change media ports in 200OK response to the re-INVITE with or without the media. In fact, re-INVITE with no media only exacerbates the problem since the 3pcc now cannot send the ACK until the media is renegotiated with the other party. INVITEs with no media were introduced as a hack to provide interoperability with H.323v1 so instead of hacking the hack I'd rather require that UA not change media ports on a whim (i.e., never change the port on an "m=" line unless you also change the codec or IP address). I think it's a reasonable requirement and suspect that no sane existing UA would do this anyway. So the general question is what are the situations when ACK with SDP is required? If none are found, I'd suggest that the spec be more specific about the fact this mechanism should only be used for h.323v1 interoperability and nothing else (given the fact that it's too late to just strike it out). --- Igor Slepchin > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Thursday, November 30, 2000 1:41 PM > To: Jonathan Rosenberg; 'Gethin Liddell'; Sip Mail List > Subject: Re: [SIP] 3PCC and the re-invite response > > > BroadSoft uses the re-INVITE without SDP and ACK > with SDP to avoid the possibility of both sides getting > into the mentioned SDP change loop. > > This is why BroadSoft would like to keep the use of > ACK with SDP at least with regard to re-INVITEs. > > This is also why it would be nice for rfc2543 to mention > that an INVITE without SDP can be used as a request > to pull the receiver off of hold. This has been discussed > at the backoff and on the news group, but is currently > not explicitly mentioned in rfc2543. > > ----- Original Message ----- > From: Jonathan Rosenberg > To: 'Gethin Liddell' ; Sip Mail List > > Sent: Thursday, November 30, 2000 11:23 AM > Subject: RE: [SIP] 3PCC and the re-invite response > > > > This is a recognized problem. Note the following section in > the document: > > > > In addition, note that in Figure 1, the controller sends > a re-INVITE > > to A with the SDP from B. The response to this re-INVITE > is a 200 OK > > that contains "SDP A". If the SDP returned in the > re-INVITE response > > were not the same, the controller would need to initiate > a re-INVITE > > to B with that new SDP. This means that a UA which returns a > > > > > > > > Rosenberg/Peterson/Schulzrinne/Camarillo > [Page 12] > > > > Internet Draft 3pcc > November 22, 2000 > > > > > > different SDP (for example, by changing the ports) in > the response to > > every re-INVITE will trigger an infinite re-INVITE loop from the > > controller to each controller entity. As such, it is STRONGLY > > RECOMMENDED that if a re-INVITE does not require a UAS > to modify the > > formulation of the SDP description for a specific stream in the > > response, the SDP description of that stream in the > response MUST be > > the same. In other words, if a UA was in a session with a single > > stream, using codec A, and it received a re-INVITE > modifying the port > > to send to, the re-INVITE response MUST be the same as > it was to the > > initial request. However, if the re-INVITE forces the > UAS to change > > codecs, it is acceptable in that case to use a different > port in the > > SDP in the response. > > > > > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > > -----Original Message----- > > > From: Gethin Liddell [mailto:gethin@ubiquity.net] > > > Sent: Thursday, November 30, 2000 7:19 AM > > > To: Sip Mail List > > > Subject: [SIP] 3PCC and the re-invite response > > > > > > > > > > > > people, > > > > > > i'm slightly concerened (maybe un-justifably) about the re-invite > > > working of the 3PCC draft. > > > > > > my concern is that it is possible (is it not?) for the user agent > > > receiving the re-invite to change its SDP settings in its > response as > > > follows: > > > > > > A Controller B > > > | INV held SDP | | > > > |<------------------| | > > > | | | > > > | 200 SDP A1 | | > > > |-----------------> | INV SDP A1 | > > > | ACK |----------------->| > > > |<----------------- | | > > > | | 200 SDP B1 | > > > | |<-----------------| > > > | | | > > > | | ACK | > > > | INV SDP B1 |----------------->| > > > |<------------------| | > > > | 200 OK SDP A2 | | > > > |------------------>| | > > > | ACK | | > > > |<------------------| | > > > | | > > > | BROKEN RTP | > > > | | > > > | | > > > | | > > > > > > NOTE: A has returned different SDP in its two different 200 > > > OK messages. > > > > > > Why might it do this? It might not but it is possible is it not. > > > > > > perhaps we should mandate that an agent can only change > its SDP for a > > > session in an INVITE not in a response (after the initial > > > INVITE/RESPONSE exchange of course) > > > > > > what do we think? > > > > > > -- > > > Gethin Liddell > > > Ubiquity Software Corporation > > > > > > http://www.ubiquity.net > > > mailto:gethin@ubiquity.net > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 16:09:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23042 for ; Fri, 1 Dec 2000 16:09:27 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3010444495; Fri, 1 Dec 2000 14:35:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 852794448B for ; Fri, 1 Dec 2000 14:34:08 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA18843; Fri, 1 Dec 2000 15:36:23 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 15:31:55 -0500 Message-ID: From: Igor Slepchin To: "'Billy Biggs'" , "Henning G. Schulzrinne" Cc: SIP List Subject: RE: [SIP] Re: My comments on bis-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 15:31:46 -0500 > > > 2. In 4.2.5, it is noted that CANCEL requests cannot have Route > > > headers. Why not? Are you assuming that CANCEL is only useful > > > for an initial request? This breaks since we need to > be able to > > > CANCEL a pending REFER or other extension method which doesn't > > > complete quickly, for example. > > > > Removed. > > I think I was wrong on this one. CANCEL is of hop-by-hop > significance > within a transaction and doesn't use the Route. Stateful proxies > instead remember and the UA sends the CANCEL just to the > first entry in > the Route. A proxy might be stateless and still record-route. Route actually does make sense in a CANCEL in this scenario. --- Igor Slepchin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 16:15:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA24572 for ; Fri, 1 Dec 2000 16:15:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2D47B444A5; Fri, 1 Dec 2000 14:37:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id E2E61444A4 for ; Fri, 1 Dec 2000 14:36:14 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id PAA02953; Fri, 1 Dec 2000 15:36:05 -0500 (EST) Message-ID: <0cd401c05bd6$9de8e9f0$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Gethin Liddell" Cc: "Sip Mail List" References: <00120111510301.22777@gethin> <0b3e01c05ba5$56da6a60$4301a8c0@broadsoft.com> <00120115060300.23207@gethin> Subject: Re: [SIP] 3PCC and the re-invite response 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 15:38:09 -0500 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: Gethin Liddell To: Brett Tate Cc: Sip Mail List Sent: Friday, December 01, 2000 9:57 AM Subject: Re: [SIP] 3PCC and the re-invite response > On Fri, 01 Dec 2000, Brett Tate wrote: > > > I actually think that the best solution for 3PCC is an amalgamation of > > > the late ACK and re-invite proposals: > > > > > > A Controller B > > > | INV held SDP | | time t = 0 > > > |<------------------| | > > > | | | > > > | 200 SDP A1 | | > > > |-----------------> | | > > > | | | > > > | ACK | | > > > |<------------------| | > > > | | | > > > | | INV NO SDP | > > > | |----------------->| (1) > > > | | | > > > | | 200 SDP B | > > > | |<-----------------| > > > | INV SDP B | | > > > |<------------------| | > > > | | | > > > | 200 SDP A2 | | > > > |-----------------> | | > > > | | | > > > | | ACK SDP A2 | > > > | ACK |----------------->| > > > |<------------------| | > > > | | | > > > | | RTP | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > | | | > > > | | | > > > | | | > > > | | | > > > | | | > > > | | | > > > | | | > > > | | | > > > > > > my only query is who do we late ack at (1), agent A or agent B. > > > > It would be best to send it first to the party that the 3pcc > > is controlling since it should definitely support it, and it > > is the one trying to pull the other party off of hold. In the > > above scenario, I am assuming that B put party A on > > hold (the picture isn't complete). Thus the INVITE > > without SDP should be sent to B first. > > the picture is actually the call flow that will occur at the initiation > of a 3PCC session. so `b' has not put `a' on hold, the contoller has > put `a' on hold whilst it tries to contact b'. once it has contacted > `b', it is able to quickly bring `a' into the RTP session because there > is no user intervention. Thanks for the clarification. I thought you were trying to use the 3pcc to pull a subscriber off hold. I will start by suggesting the use of REFER to get "A" into the picture (forgive me if the transfer spec no longer allows for this). Otherwise I'd transfer "A" back to controller at step 4, and use the INVITE's SDP when bringing "B" into the call. This also allows "A" to hear/see the progressing/failure concerning "B". Otherwise you can do things as you have captured in the flow. > > if we were to initiate the late ACK scenario to 'a' at (1) then as > Gonzalo pointed out, `a' may be waiting around a long time for an ACK > to appear because we would have to wait for the user to answer the > phone. > > > > > > > Only question is what will agent A do with a re-invite that has no SDP? > > > > > > > Assuming no 3pcc, any INVITE without SDP should > > be a request to establish a session. If party A put B > > on hold. An INVITE without SDP from B is a request > > basically indicating to please pull me off of hold. > > However since A started the hold, it is of course fine > > for A to pass back a hold SDP again. > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 16:24:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26082 for ; Fri, 1 Dec 2000 16:24:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C981C444B4; Fri, 1 Dec 2000 15:08:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 258A2444B2 for ; Fri, 1 Dec 2000 15:07:27 -0500 (EST) Received: from dynamicsoft.com ([212.120.151.25]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA19491; Fri, 1 Dec 2000 16:09:10 -0500 (EST) Message-ID: <3A2812C0.2C4E0E46@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bryan Thale Cc: jainsip@sun.com, sip@lists.bell-labs.com References: <3A26EA0B.BADCD544@dynamicsoft.com> <3A26FB82.8201F239@labs.mot.com> <3A270071.AD24CCC3@dynamicsoft.com> <3A2703ED.3C294813@labs.mot.com> <3A2782AF.A2E9D3B8@dynamicsoft.com> <3A27DF50.3C319B86@labs.mot.com> <3A27E7B6.6C740DFE@dynamicsoft.com> <3A27FEAD.ED3374C4@labs.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Re: [Fwd: [Fwd: Munged JainSipApi0_6.jar file?]] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 21:06:08 +0000 Content-Transfer-Encoding: 7bit Hi Bryan, Comments below... Chris Bryan Thale wrote: > > I don't know how much use the 0.6 code would be to you - I am writing the > > reference implementation for 0.7 and I was hoping I could just move the > > method implementations from the 0.6 classes into the reference > > implementation - but as it turns out it's easier to start from scratch! > > OK. I've never seen many opportunities for re-use in actual practice either! > :-) > > > PS - the reason I moved them together is that each token constant could be > > called say "ACCEPT_ENCODING" rather than just "token" - mind you it's really > > "Header.ACCEPT_ENCODING" instead of "AcceptHeader.token" > > > Difference of opinion on style I guess. I prefer not to put anything in a > super class (or super interface in this case) that ties it to its subclasses. > I always seem to regret those reverse dependencies when I use them. OK - I guess if I step back and look at this, I have to say I shouldn't have moved the header names to the base interface - every header has a name, but only Accept-Encoding headers have a name of "Accept-Encoding", so I guess it logically belongs to the sub-interface. I would want to change it from "token" to something more meaningful though - "name" being the most obvious. What do you think? > > > On a similar topic, what do you envision as the purpose for the integer header > type codes? The reason is to allow an application to treat (particularly experimental) headers correctly - e.g. an implementation that knows an Call-Info is a general header can tell the application this, and this overrides the default behaviour of treating it as an entity header. This could work going down from the application to the implementation too. I don't know how useful this actually is - but I figured someone would probably want this functionality sooner rather than later. It sounds like you think this should be dropped? > > > Bryan. > > -- > Bryan Thale > Motorola Labs, Networking and Infrastructure Research > mailto:thale@labs.mot.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 16:26:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA26577 for ; Fri, 1 Dec 2000 16:26:31 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 12AFF444BC; Fri, 1 Dec 2000 15:17:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 6AA4C444BB for ; Fri, 1 Dec 2000 15:16:24 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id QAA07759; Fri, 1 Dec 2000 16:16:15 -0500 (EST) Message-ID: <0d2a01c05bdc$3ac47460$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Igor Slepchin" , "Sip Mail List" References: Subject: Re: [SIP] 3PCC and the re-invite response 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 16:18:19 -0500 Content-Transfer-Encoding: 7bit > I don't see how re-INVITE with no SDP helps to solve the SDP exchange loop > problem (or nearly any other problem). The UA is equally likely (or, rather, > unlikely) to randomly change media ports in 200OK response to the re-INVITE > with or without the media. In fact, re-INVITE with no media only exacerbates > the problem since the 3pcc now cannot send the ACK until the media is > renegotiated with the other party. My post was to solve the SDP exchange loop problem of using 3pcc to pull the subscribers off of hold. The following solves the SDP exchange loop problem during call setup. I will start by suggesting the use of REFER to get "A" into the picture during call setup (forgive me if the transfer spec no longer allows for this). Otherwise I'd transfer "A" back to the controller after a held session between "A" and controller are established. This allows A's INVITE SDP to be used to INVITE "B". This allows "A" to hear/see the progressing/failure concerning "B". This also solves the SDP exchange loop problem during call setup. Otherwise, the flow in the following post works. http://lists.bell-labs.com/pipermail/sip/2000q4/004391.html _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 16:56:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01493 for ; Fri, 1 Dec 2000 16:56:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A485144406; Fri, 1 Dec 2000 15:56:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 01012443D7 for ; Fri, 1 Dec 2000 15:55:25 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA20257; Fri, 1 Dec 2000 16:57:45 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 16:53:17 -0500 Message-ID: From: Igor Slepchin To: "'Brett Tate'" , Igor Slepchin , Sip Mail List Subject: RE: [SIP] 3PCC and the re-invite response MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 16:53:12 -0500 > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > > My post was to solve the SDP exchange loop > problem of using 3pcc to pull the subscribers > off of hold. > > Otherwise, the flow in the following post works. > http://lists.bell-labs.com/pipermail/sip/2000q4/004391.html > What I'm saying is that I don't see this as a problem with 3pcc at all. Given Figure 1 in http://search.ietf.org/internet-drafts/draft-rosenberg-sip-3pcc-01.txt, why would A change the media in 200OK to the second INVITE? Instead of inventing workarounds for eccentric UAs, it would be much easier to define what a "sane" UA can and cannot do (e.g., it cannot change SDP just because it received a re-INVITE, there should be another valid reason for the change). --- Igor Slepchin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 17:15:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA05903 for ; Fri, 1 Dec 2000 17:15:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DEF444433; Fri, 1 Dec 2000 16:15:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from thumper.research.telcordia.com (thumper.research.telcordia.com [128.96.41.1]) by lists.bell-labs.com (Postfix) with ESMTP id CF713443F9 for ; Fri, 1 Dec 2000 16:14:55 -0500 (EST) Received: from mailee.research.telcordia.com (mailee [192.4.7.23]) by thumper.research.telcordia.com (8.10.1/8.10.1) with ESMTP id eB1MEla17048 for ; Fri, 1 Dec 2000 17:14:47 -0500 (EST) Received: from smoyer-lap.research.telcordia.com (mmc-11-as5200-d24.cc.telcordia.com [128.96.11.24]) by mailee.research.telcordia.com (8.9.3/8.9.3) with ESMTP id RAA09325 for ; Fri, 1 Dec 2000 17:14:42 -0500 (EST) Message-Id: <4.3.2.7.2.20001201133019.060f57b0@mailee.research.telcordia.com> X-Sender: stanm@mailee.research.telcordia.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: sip@lists.bell-labs.com From: Stan Moyer Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [SIP] FYI... "Bar BoF" on SIP for Networked Appliances at IETF 49 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 15:15:08 -0500 Folks, The area of SIP Networked Appliances has received much attention in recent months. Some of the issues have been highlighted in recent Internet Drafts and these are available (with a FAQ) at the Networked Appliances web page at: http://www.argreenhouse.com/iapp/ To enable further open discussion on this topic at IETF 49, there will be an informal BoF at lunchtime on Tuesday (Dec. 12). If you are interested in attending, please reply to Simon Tsang (stsang@research.telcordia.com) or me (stanm@research.telcordia.com) . We can plan to meet at noon in the terminal room (or some other likely meeting place) and I will make reservations at a nearby restaurant for the group (which is why your RSVP is necessary). I hope to hear from you soon and to see you at the BoF. Thanks, Stan Stan Moyer Director, Internet Services Infrastructure Research ; Telcordia Technologies, MCC-1A238R, 445 South Street, Morristown, NJ 07960-6438 voice: +1 973 829 4923; fax: +1 973 829 5889 http://www.argreenhouse.com/bios/stanm/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 17:18:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA06933 for ; Fri, 1 Dec 2000 17:18:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ED6504444A; Fri, 1 Dec 2000 16:18:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id E924A4443A for ; Fri, 1 Dec 2000 16:17:12 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G4W00G01TW5E1@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 1 Dec 2000 22:16:54 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G4W00DE8TW5KL@firewall.mcit.com>; Fri, 01 Dec 2000 22:16:53 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0G4W00401TMWXE@dgismtp03.wcomnet.com>; Fri, 01 Dec 2000 22:14:13 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G4W00401TL1KP@dgismtp03.wcomnet.com>; Fri, 01 Dec 2000 22:10:31 +0000 (GMT) Received: from hsinnreich ([166.44.58.157]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G4W000PUTK2G4@dgismtp03.wcomnet.com>; Fri, 01 Dec 2000 22:09:41 +0000 (GMT) From: Henry Sinnreich In-reply-to: To: sip@lists.bell-labs.com Cc: gageb@nortelnetworks.com, nhamer@nortelnetworks.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [SIP] RE: draft-hamer-sip-session-auth-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 16:12:54 -0600 Content-Transfer-Encoding: 7bit There may not be enough time in the SIP WG, but SIP and session authorization is now the subject of several draft and needs to be discussed at least on the list. For the IETF, Internet-wide compatibility is of higher priority, since private IP networks and ISP networks have some latitude to customize their internal network design, such a illustrated in the draft: http://ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-00.txt This leads to top priority for the notions of: 1 - Interdomain, no matter how the domains are designed internally, 2 - Clearinghouses as trust brokers between domains. Clearinghouses are widely used at present for VoIP. Getting now to the intradomain aspects, I would like to discuss the model in Discussing the references, on page 9: >there are a number of issues with this model: > The same policy server makes decisions related to both service > authorization and resource utilisation. This is only possible if > the service provider and access provider are one and the same > business entity and if the network is simple enough to warrant > deployment of a single policy server. The service provider and access provider DO NOT NEED to be the same, since policy can be outsourced between business partners. See http://ietf.org/internet-drafts/draft-gross-sipaq-00.txt and http://ietf.org/internet-drafts/draft-gross-cops-sip-00.txt A second theme of the draft-hamer-sip-session-auth-00.txt is also: > The end host is connected to a known point in the network that > defines the edge router and policy server for that host. This is > only possible in a network with fixed hosts and fixed routers > where the administrative burden of defining these associations > make this a feasible undertaking. This is also arguable, since: 1 - SIP clients have to authenticate themselves to the SIP proxies that control service inside the domain, so they are known, 2 - SIP proxies, policy servers and edge routers are the crown jewels of the ISP, similar to the IN in telephony and well known and monitored network elements. Their security associations are not only administered by hand, but also with great care. Also, why modifications to three protocols? >- Resource reservation protocol >- Policy management protocol (Which: COPS or DIAMETER?) >- Session management protocol (I suppose SDP is meant by this?) The references above and the preceding work contains a large number of scenarios and call flows, showing that existing protocols do the job without any modifications. As for SIP, please see: http://ietf.org/internet-drafts/draft-johnston-sip-osp-token-01.txt Finally some nits regarding terminology: I don't know what BEARER is in the IETF context. The ITU BEARER is very different from IETF TRANSPORT and NETWORK and imply very different design philosophies. Mixing these terms can lead to utter confusion. SESSION MANAGER: SIP does only session setup, as its name implies. The IETF Multimedia Conferencing Architecture and other MMUSIC work makes it clear that they don't believe in managing sessions. (There is always an exception that confirms the rule: SIP 3rd party call control) >Session management protocol? See the above. >Bearer Control Domain. Suggest we avoid loose definitions of domains. A domain is a domain is a domain in the DNS sense. Voila! Plenty of items to discuss. If there is no time in the SIP WG we may have to try and meet at the bar. Henry Henry Sinnreich WorldCom 400 International Parkway, Dept. 1489, 2A313 Richardson, Texas, 75081 -----Original Message----- From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] Sent: Friday, December 01, 2000 10:32 AM To: Stephen Thomas; Alan Johnston; Theodore Havinis; Steve Donovan at DynamicSoft; Gerhard Gross; Diana Rawlins Subject: RE: Conference call: draft-hamer-sip-session-auth-00.txt Importance: High I will be able to attend only for 30 minutes 3:00-3:300 CST due to a conflict with another meeting. Really sorry, but was not under my control. >DATE: 12/1 >TIME: 3:00 CST - 5:00 CST >BRIDGE: V857-4113 / 4195 >TOLLFREE: 888-810-3146 / 4195 Henry -----Original Message----- From: Stephen Thomas [mailto:stephen.thomas@transnexus.com] Sent: Tuesday, November 28, 2000 2:27 PM To: Henry Sinnreich; Alan Johnston; Theodore Havinis; Steve Donovan at DynamicSoft; Gerhard Gross; Diana Rawlins Subject: Re: Conference call: draft-hamer-sip-session-auth-00.txt I'll be there (virtually speaking). Stephen At 09:01 AM 2000-11-28 -0600, Henry Sinnreich wrote: >Dear Friends, > >The draft raises some issues with >regard to our own work on SIP-QoS-OSP and APS. I have reserved a >conference bridge for Friday afternoon to discuss the subject, in case you >are interested. >DATE: 12/1 >TIME: 3:00 CST - 5:00 CST >BRIDGE: V857-4113 / 4195 >TOLLFREE: 888-810-3146 / 4195 > >Please confirm your attendance. > >Henry _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 17:21:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA07916 for ; Fri, 1 Dec 2000 17:20:59 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1482D4445A; Fri, 1 Dec 2000 16:19:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id 30D414443A for ; Fri, 1 Dec 2000 16:18:01 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G4W00G01TXPX9@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 1 Dec 2000 22:17:49 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G4W00CK2TXPZH@firewall.mcit.com>; Fri, 01 Dec 2000 22:17:49 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0G4W00501TQPQ2@dgismtp03.wcomnet.com>; Fri, 01 Dec 2000 22:15:09 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G4W00501TN82T@dgismtp03.wcomnet.com>; Fri, 01 Dec 2000 22:11:49 +0000 (GMT) Received: from hsinnreich ([166.44.58.157]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G4W00ML9TMUP6@dgismtp03.wcomnet.com>; Fri, 01 Dec 2000 22:11:20 +0000 (GMT) From: Henry Sinnreich In-reply-to: To: sip@lists.bell-labs.com Cc: gageb@nortelnetworks.com, nhamer@nortelnetworks.com Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Subject: [SIP] RE: draft-hamer-sip-session-auth-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 16:14:34 -0600 Content-Transfer-Encoding: 7bit There may not be enough time in the SIP WG, but SIP and session authorization is now the subject of several draft and needs to be discussed at least on the list. For the IETF, Internet-wide compatibility is of higher priority, since private IP networks and ISP networks have some latitude to customize their internal network design, such a illustrated in the draft: http://ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-00.txt This leads to top priority for the notions of: 1 - Interdomain, no matter how the domains are designed internally, 2 - Clearinghouses as trust brokers between domains. Clearinghouses are widely used at present for VoIP. Getting now to the intradomain aspects, I would like to discuss the model in Discussing the references, on page 9: >there are a number of issues with this model: > The same policy server makes decisions related to both service > authorization and resource utilisation. This is only possible if > the service provider and access provider are one and the same > business entity and if the network is simple enough to warrant > deployment of a single policy server. The service provider and access provider DO NOT NEED to be the same, since policy can be outsourced between business partners. See http://ietf.org/internet-drafts/draft-gross-sipaq-00.txt and http://ietf.org/internet-drafts/draft-gross-cops-sip-00.txt A second theme of the draft-hamer-sip-session-auth-00.txt is also: > The end host is connected to a known point in the network that > defines the edge router and policy server for that host. This is > only possible in a network with fixed hosts and fixed routers > where the administrative burden of defining these associations > make this a feasible undertaking. This is also arguable, since: 1 - SIP clients have to authenticate themselves to the SIP proxies that control service inside the domain, so they are known, 2 - SIP proxies, policy servers and edge routers are the crown jewels of the ISP, similar to the IN in telephony and well known and monitored network elements. Their security associations are not only administered by hand, but also with great care. Also, why modifications to three protocols? >- Resource reservation protocol >- Policy management protocol (Which: COPS or DIAMETER?) >- Session management protocol (I suppose SDP is meant by this?) The references above and the preceding work contains a large number of scenarios and call flows, showing that existing protocols do the job without any modifications. As for SIP, please see: http://ietf.org/internet-drafts/draft-johnston-sip-osp-token-01.txt Finally some nits regarding terminology: I don't know what BEARER is in the IETF context. The ITU BEARER is very different from IETF TRANSPORT and NETWORK and imply very different design philosophies. Mixing these terms can lead to utter confusion. SESSION MANAGER: SIP does only session setup, as its name implies. The IETF Multimedia Conferencing Architecture and other MMUSIC work makes it clear that they don't believe in managing sessions. (There is always an exception that confirms the rule: SIP 3rd party call control) >Session management protocol? See the above. >Bearer Control Domain. Suggest we avoid loose definitions of domains. A domain is a domain is a domain in the DNS sense. Voila! Plenty of items to discuss. If there is no time in the SIP WG we may have to try and meet at the bar. Henry Henry Sinnreich WorldCom 400 International Parkway, Dept. 1489, 2A313 Richardson, Texas, 75081 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 17:36:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA12553 for ; Fri, 1 Dec 2000 17:36:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EA29A4440B; Fri, 1 Dec 2000 16:36:09 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 855164440B for ; Fri, 1 Dec 2000 16:35:03 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Dec 1 17:33:47 EST 2000 Received: by lists.bell-labs.com (Postfix) id 80E5D44380; Fri, 1 Dec 2000 17:21:30 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id 5AB244437D for ; Fri, 1 Dec 2000 17:21:30 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA22890; Fri, 1 Dec 2000 17:21:29 -0500 (EST) Message-ID: <3A28246C.9F4DE475@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Brett Tate'" , "'Gethin Liddell'" , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 17:21:32 -0500 Content-Transfer-Encoding: 7bit I think it's easiest if an INVITE without SDP simply means "no change". I.e., it has no influence on any media stream. If you didn't have a media stream before, you don't have one afterwards. If you had some before, they stay as is. I'm not clear why you would want to need or use this for removing somebody from sending no media, since a re-INVITE with the old, pre-hold media does this just fine. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 17:50:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16469 for ; Fri, 1 Dec 2000 17:50:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA4FB4444B; Fri, 1 Dec 2000 16:50:11 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 218C844437 for ; Fri, 1 Dec 2000 16:49:06 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Dec 1 17:47:37 EST 2000 Received: by lists.bell-labs.com (Postfix) id D48CA44380; Fri, 1 Dec 2000 17:35:20 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id AE58C4437D for ; Fri, 1 Dec 2000 17:35:20 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA24270; Fri, 1 Dec 2000 17:35:15 -0500 (EST) Message-ID: <3A2827A7.E17012F4@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Dean Willis , SIP List Subject: Re: [SIP] Single Line Extension work References: <01d201c05b06$3a2be320$ea036e3f@dynamicsoft.com> <3A27731B.1796F2E4@ericsson.com> <20001201123718.A32000@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 17:35:19 -0500 Content-Transfer-Encoding: 7bit The behavior that motivated this was the ability to call brady@families-r-us.com and get connected to everyone. Effectively, this can be solved by a back-to-back UA/conferencing server with a conference called 'brady' that makes outgoing calls to the members of the family. (This server would have to CANCEL the other calls as soon as the first one answers. Family members could dial into brady@families-r-us.com to get connected to the on-going call.) Thus, is this more than just an implementation issue? Would it be sufficient to document this case in the conferencing draft? Billy Biggs wrote: > > > A while back we had a vigorous discussion going on how to implement > > the PBX/Centrex "single line extension" service or get behavior > > similar to US residentil "party lines". > > > > I don't believe I've seen any discussion on this topic for a long > > time. Anybody still working on it, or can we declare the effort dead > > for now? > > Jonathan and Henning's draft on multi-party conferencing models is an > important step forward in discussing conferencing services such as > single line extension. The continuing work on presence extensions and > event subscriptions also helps. > > But until the puzzle fits together a little more, the single line > extension work is quite fluffy. Hopefully this will change in the next > few months. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 17:52:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17375 for ; Fri, 1 Dec 2000 17:52:42 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 14A054447C; Fri, 1 Dec 2000 16:52:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id CC40D44455 for ; Fri, 1 Dec 2000 16:51:35 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id EAA26752; Sat, 2 Dec 2000 04:56:57 -0600 Message-ID: <008e01c05be8$f6151150$a6036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" , MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0061_01C05BB4.C18BA810" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Agenda, SIP WG, IETF 48. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 16:35:46 -0600 This is a multi-part message in MIME format. ------=_NextPart_000_0061_01C05BB4.C18BA810 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Here is the official agenda for the SIP WG meetings at IETF 49, subjec = of course to change in order to correct glaring errors on my part. Online version available at = http://www.softarmor.com/sipwg/meets/IETF49/agenda.html Agenda, SIP WG IETF 48 -------------------------------------------------------------------------= ------- Monday December 10, 1300-1500 Contact Draft Priority Duration Start=20 Stan Moyer Appliance BOF Announcement 2 1300=20 Dean Willis Agenda Bash 1 8 1302=20 Jonathan Rosenberg Open Issues 1 80 1310=20 Chairs Working Group Planning 1 30 1430=20 Tuesday, December 11, 0900-1130 Discussion of Chartered or Approved Work Items:=20 (Guidelines: Changes, Issues, Next Steps) Requestor Draft Priority = Duration Start=20 Chairs Aganda Bash and Business 5 0900=20 Jonathan Rosenberg draft-ietf-sip-callerprefs-03.txt 1 5 0905=20 Jonathan Rosenberg draft-ietf-sip-session-timer-02.txt 1 5 0910=20 Jonathan Rosenberg draft-rosenberg-sip-3pcc-01.txt 1 5 0915=20 Robert Sparks draft-ietf-sip-cc-transfer-02.txt 1 10 0920=20 Joon Maeng draft-agrawal-sip-h323-interworking-reqs-00.txt 2 10 = 0930=20 Bill Marshall draft-ietf-sip-call-auth-00.txt 2 10 0940=20 Bill Marshall draft-ietf-sip-state-00.txt 2 10 0950=20 Bill Marshall draft-ietf-sip-privacy-00.txt 2 10 1000=20 Bill Marshall draft-ietf-sip-manyfolks-resource-00.txt 2 10 1010=20 Alan Johnston draft-ietf-sip-call-flows-02.txt 2 10 1020=20 Alan Johnston draft-ietf-sip-service-examples-00.txt 2 10 1030=20 John Petersen draft-vemuri-sip-t-context-01.txt 2 10 1040=20 Discussion of Non-Cartered or WG Approved Items :=20 (Guidelines -- Three slides max. State Problem, Propose Solution, Next = steps) Arnoud Van Wijk draft-gearhart-sip-deaf-req-00.txt 3 2 1050=20 L. N. Hamer draft-hamer-sip-session-auth-00.txt 3 2 1052=20 Jonathan Lennox draft-lennox-sip-cgi-04.txt 3 2 1054=20 Jonathan Lennox draft-lennox-sip-reg-payload-01.txt 3 2 1056=20 Gerhard Gross draft-gross-cops-sip-00.txt 3 2 1058=20 Gerhard Gross draft-gross-sipaq-00.txt 3 2 1100=20 Adam Roach draft-roach-sip-subscribe-notify-02.txt 3 2 1102=20 Jonathan Rosenberg draft-rosenberg-sip-entfw-00.txt 3 2 1104=20 Jonathan Rosenberg draft-rosenberg-sip-app-components-00.txt 3 2 = 1106=20 Stephen Thomas draft-johnston-sip-osp-token-01.txt 3 2 1108=20 Bryan Byerly draft-levy-sip-diversion-01.txt 3 2 1110=20 Bryan Byerly draft-byerly-sip-radius-00.txt 3 2 1112=20 Bryan Byerly draft-byerly-sip-hide-route-00.txt 3 2 1114=20 Rohan Mahy draft-mahy-sip-189-00.txt 3 2 1116=20 Billy Biggs draft-biggs-sip-replaces-00.txt 3 2 1118=20 Jonathan Rosenberg draft-rosenberg-sip-conferencing-models-00.txt = 3 2 1120=20 Matt Holdredge draft-calhoun-sip-aaa-reqs-01.txt 3 2 1122=20 chairs discussion 3 6 1124=20 ------=_NextPart_000_0061_01C05BB4.C18BA810 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Here is the official agenda for the SIP WG meetings at IETF 49, = subjec of=20 course to change in order to correct glaring errors on my part.
Online version available at http://w= ww.softarmor.com/sipwg/meets/IETF49/agenda.html
 
Agenda, SIP WG IETF 48

Monday December 10, 1300-1500

Contact Draft Priority Duration Start
Stan Moyer Appliance BOF Announcement   2 1300
Dean Willis Agenda Bash 1 8 1302
Jonathan Rosenberg Open Issues 1 80 1310
Chairs Working Group Planning 1 30 1430

 

Tuesday, December 11, 0900-1130

Discussion of Chartered or Approved Work Items: 
(Guidelines: = Changes, Issues, Next Steps)=20
Requestor Draft Priority Duration Start
Chairs Aganda Bash and Business 5 0900
Jonathan Rosenberg draft-ietf-sip-callerprefs-03.txt 1 5 0905
Jonathan Rosenberg draft-ietf-sip-session-timer-02.txt 1 5 0910
Jonathan Rosenberg draft-rosenberg-sip-3pcc-01.txt 1 5 0915
Robert Sparks draft-ietf-sip-cc-transfer-02.txt 1 10 0920
Joon Maeng draft-agrawal-sip-h323-interworking-reqs-00.txt= 2 10 0930
Bill Marshall draft-ietf-sip-call-auth-00.txt=20 2 10 0940
Bill Marshall draft-ietf-sip-state-00.txt 2 10 0950
Bill Marshall draft-ietf-sip-privacy-00.txt=20 2 10 1000
Bill Marshall draft-ietf-sip-manyfolks-resource-00.txt 2 10 1010
Alan Johnston draft-ietf-sip-call-flows-02.txt 2 10 1020
Alan Johnston draft-ietf-sip-service-examples-00.txt 2 10 1030
John Petersen draft-vemuri-sip-t-context-01.txt 2 10 1040

Discussion of Non-Cartered or WG Approved Items = : 
(Guidelines --=20 Three slides max. State Problem, Propose Solution, Next steps)=20
Arnoud Van Wijk draft-gearhart-sip-deaf-req-00.txt 3 2 1050
L. N. Hamer draft-hamer-sip-session-auth-00.txt 3 2 1052
 Jonathan Lennox draft-lennox-sip-cgi-04.txt 3 2 1054
Jonathan Lennox draft-lennox-sip-reg-payload-01.txt 3 2 1056
Gerhard Gross draft-gross-cops-sip-00.txt   3 2 1058
Gerhard Gross d= raft-gross-sipaq-00.txt 3 2 1100
Adam Roach draft-roach-sip-subscribe-notify-02.txt 3 2 1102
Jonathan Rosenberg draft-rosenberg-sip-entfw-00.txt 3 2 1104
Jonathan Rosenberg draft-rosenberg-sip-app-components-00.txt 3 2 1106
Stephen Thomas draft-johnston-sip-osp-token-01.txt 3 2 1108
Bryan Byerly draft-levy-sip-diversion-01.txt 3 2 1110
Bryan Byerly draft-byerly-sip-radius-00.txt 3 2 1112
Bryan Byerly draft-byerly-sip-hide-route-00.txt 3 2 1114
Rohan Mahy = draft-mahy-sip-189-00.txt 3 2 1116
Billy Biggs draft-biggs-sip-replaces-00.txt 3 2 1118
Jonathan Rosenberg draft-rosenberg-sip-conferencing-models-00.txt 3 2 1120
Matt Holdredge draft-calhoun-sip-aaa-reqs-01.txt 3 2 1122
chairs discussion 3 6 1124

= ------=_NextPart_000_0061_01C05BB4.C18BA810-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 17:57:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA19020 for ; Fri, 1 Dec 2000 17:57:38 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C00A044490; Fri, 1 Dec 2000 16:52:30 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 0556B44483 for ; Fri, 1 Dec 2000 16:51:36 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id EAA26755; Sat, 2 Dec 2000 04:56:58 -0600 Message-ID: <008f01c05be8$f693de40$a6036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" Cc: "Brian Rosen (E-mail)" , "Joerg Ott (E-mail)" 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] THE NEW MEETING RULES: Or, Agenda Issues for SIP WG at IETF 49 and Presentations Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 16:47:57 -0600 Content-Transfer-Encoding: 7bit I have sent under separate cover (and posted to http://www.softarmor.com/sipwg/meets/IETF49/agenda.html) the agenda for our upcoming meeting. Brian, Joerg and I have taken some fairly radical measures to control "presentation proliferation". The first slot (2 hr) is devoted to discussion of major protocol issues and working group business. The second slot (2.5 hr) is devoted to discussion of drafts. There simply isn't enough time to present every draft in depth, so I broke the material into two categories. The first category (priority 1 and 2) includes all material which I believe to be directly supporting chartered work or work we have agreed to support in other meetings. I'll ask the leaders of these discussions to limit themselves to ten minutes per draft (except for those who told me they coudl be quicker). I believe most of the "status updates" can be significantly shorter than ten minutes, and I hope we can use some of this time to address the discussions that invariably arise on a few of the drafts. The second category (priority 3) includes all the really cool stuff that we need to think about but that is either new or hasn't been approved as a WG effort. I'll ask the leaders of these discussions to use an entirely new procedure: 1) Limit to a max of three slides each. Introduce the problem being addressed, the approach used (or any changes since the last presentation of this work), and make a recommendation for future work (publish as info, adopt as WG effort, send to Maui on vacation, etc.) 2) Send all slides to me by 5:00 PM on Monday, December 10. I will assemble them into one massive presentation so that we do not lose time switching PCs. 3) All discussion leaders will address the room from floor mikes if possible. This will relieve congestion from around the podium and speed up transitions. 4) Questions from the floor will be strictly limited. I will be ruthless. I might even raise my voice if needed ;-). -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 18:09:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA22713 for ; Fri, 1 Dec 2000 18:09:11 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2D4AF44469; Fri, 1 Dec 2000 17:09:14 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from dirty.research.bell-labs.com (dirty.research.bell-labs.com [204.178.16.6]) by lists.bell-labs.com (Postfix) with SMTP id 5333F4449D for ; Fri, 1 Dec 2000 17:08:10 -0500 (EST) Received: from starling.research.bell-labs.com ([135.104.26.187]) by dirty; Fri Dec 1 18:07:39 EST 2000 Received: from lists.bell-labs.com (sunny.research.bell-labs.com [135.104.27.211]) by starling.research.bell-labs.com (8.9.1/8.9.1) with ESMTP id SAA18995 for ; Fri, 1 Dec 2000 18:02:37 -0500 (EST) Received: by lists.bell-labs.com (Postfix) id 15B7644380; Fri, 1 Dec 2000 17:57:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id DBC584437D for ; Fri, 1 Dec 2000 17:57:12 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id RAA26493 for ; Fri, 1 Dec 2000 17:57:12 -0500 (EST) Message-ID: <3A282CCC.FAE25BF@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------DA3760F1CD9CBBDAC6613939" Subject: [SIP] [Fwd: Application for port-number (5061)] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 17:57:16 -0500 This is a multi-part message in MIME format. --------------DA3760F1CD9CBBDAC6613939 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit I didn't ask for the UDP port, but maybe TLS will be redesigned to run over UDP one of these days and it's otherwise harmless... --------------DA3760F1CD9CBBDAC6613939 Content-Type: message/rfc822 Content-Disposition: inline Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by opus.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA29024 for ; Fri, 1 Dec 2000 17:40:42 -0500 (EST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA26601 for ; Fri, 1 Dec 2000 17:40:41 -0500 (EST) Received: from icann1 (icann1.isi.edu [128.9.160.34]) by boreas.isi.edu (8.9.3/8.9.3) with SMTP id OAA02300 for ; Fri, 1 Dec 2000 14:40:40 -0800 (PST) Reply-To: From: "IANA" To: Subject: RE: Application for port-number (5061) Date: Fri, 1 Dec 2000 14:46:52 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 In-Reply-To: <200011191535.HAA04737@smo-www-01.icann.org> Importance: Normal X-Mozilla-Status2: 00000000 Content-Transfer-Encoding: 7bit Dear Henning, We have assigned the following user port number with you as the point of contact: sip-tls 5061/tcp SIP-TLS sip-tls 5061/udp SIP-TLS # Henning Schulzrinne Please notify the IANA if there is a change in contact information. Thank you, Michelle Schipper IANA Administrator *************************************************************** Internet Assigned Numbers Authority (IANA) 4676 Admiralty Way, Suite 330 Marina del Rey, California 90292 Voice: (310) 823-9358 x12 FAX: (310) 823-8649 email: iana@iana.org *************************************************************** --------------DA3760F1CD9CBBDAC6613939-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 18:20:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25958 for ; Fri, 1 Dec 2000 18:20:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A88FD44472; Fri, 1 Dec 2000 17:20:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 9975E44432 for ; Thu, 30 Nov 2000 16:50:30 -0500 (EST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA00218; Thu, 30 Nov 2000 14:50:22 -0800 (PST) Received: from cisco.com (vvs-lab-nat-171-69-180-242.cisco.com [171.69.180.242]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ACE17810 (AUTH vzubarev); Thu, 30 Nov 2000 14:50:21 -0800 (PST) Message-ID: <3A26D9A0.7247546E@cisco.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... References: Content-Type: multipart/alternative; boundary="------------D35D2E95F61B59D3A6E72E7D" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 14:50:08 -0800 --------------D35D2E95F61B59D3A6E72E7D Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit There have been already applications implemented using this scheme: INVITE (no SDP), 200 OK (SDP), ACK (SDP), including SIP/H323 gateways and SIP UAs (supporting this features). This is very important for SIP/H323 gateways, which use this feature, especially for the calls orignated on H.323 side. In this case INVITE withoud SDP and ACK with SDP is the best way to do it. Since there are lot of H.323 endpoints on the market, which do not support FastConnect, INVITE without SDP is a good sulution for it. So it's reasonable to keep this feature. It could be something like multipart SDP in SIP msg - it's not prohibited, but at the same time it's not the thing which is encouraged to do as well. So SIP UAs would still support existing implementations of SIP/H.323 gateways, while new ones would be encouraged to use re-INVITEs, instead of no SDP in INVITE. Thank you. Jonathan Rosenberg wrote: > So, figuring we didn't all have enough email on the sip list to read (I am > personally hopelessly behind), let me stir things around some more with > another proposal for something to ditch from the spec. > > Right now, you can carry SDP in the INV/200/ACK exchange in two ways. You > can send nothing in the INVITE, followed by SDP in the 200, and then SDP in > ACK (and fortunately I don't know anyone who actively does this). Or, you > can send SDP in INVITE, SDP in 200, and nothing in ACK. I also think there > are several confused implementations that likely send it in all three. > > Add to this the unfortunate PRACK mess, which also has been used to send SDP > in order to support the manyfolks resource work when used with 3pcc, but > which is yet unimplemented. > > It all adds up to a messy confusion. Its not clear what it means to send SDP > in all these places, and how it works. > > So, my proposal is that we simplify. We only allow SDP in INVITE and then > provisionals/200 OK. No SDP in ACK. No SDP in PRACK. (sounds like a Dr. > Seuss rhyme, doesn't it?) > > The latest 3pcc draft no longer recommends using the SDP-in-ACK, since it > has problems. Given that there don't seem to be useful applications of it > any longer, and given that, to my knowledge, it is not sent by anyone (at > least not in any commercially shipping boxes, I hope), I'd like to yank it. > > There is a consequence, and that is dealing with the manyfolks requirement > for sending an updated SDP to deal with manyfolks+3pcc. My proposal for that > is to use a re-invite, rahter than PRACK, to carry the updated SDP. This > does mean that we need to allow, in SIP, a re-INVITE to arrive while an > initial INVITE is in progress. Allowing this would also address some of the > concerns raised in previous threads about handling requirements for changes > in early media. > > I don't think its hard to deal with the re-INVITE while INVITE-is-active > case. The simplest solution is to reject the first INVITE and continue > processing with the second one, using the new SDP and all. > > Anyway, before getting into those details, what does the group think about > dropping the SDP-in-ACK and SDP-in-PRACK stuff? > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Vladislav Zubarev mailto:vzubarev@cisco.com Software Engineer http://www.cisco.com Cisco Systems, Inc. http://www.vovida.org --------------D35D2E95F61B59D3A6E72E7D Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit There have been already applications implemented using this scheme:
INVITE (no SDP), 200 OK (SDP), ACK (SDP), including SIP/H323
gateways and SIP UAs (supporting this features).

This is very important for SIP/H323 gateways, which use this
feature, especially for the calls orignated on H.323 side. In this case
INVITE withoud SDP and ACK with SDP is the best way to do it.
Since there are lot of H.323 endpoints on the market, which do not
support FastConnect, INVITE without SDP is a good sulution for
it.

So it's reasonable to keep this feature. It could be something like
multipart SDP in SIP msg - it's not prohibited, but at the
same time it's not the thing which is encouraged to do as well.
So SIP UAs would still support existing implementations of SIP/H.323
gateways, while new ones would be encouraged to use re-INVITEs,
instead of no SDP in INVITE.

Thank you.

Jonathan Rosenberg wrote:

So, figuring we didn't all have enough email on the sip list to read (I am
personally hopelessly behind), let me stir things around some more with
another proposal for something to ditch from the spec.

Right now, you can carry SDP in the INV/200/ACK exchange in two ways. You
can send nothing in the INVITE, followed by SDP in the 200, and then SDP in
ACK (and fortunately I don't know anyone who actively does this). Or, you
can send SDP in INVITE, SDP in 200, and nothing in ACK. I also think there
are several confused implementations that likely send it in all three.

Add to this the unfortunate PRACK mess, which also has been used to send SDP
in order to support the manyfolks resource work when used with 3pcc, but
which is yet unimplemented.

It all adds up to a messy confusion. Its not clear what it means to send SDP
in all these places, and how it works.

So, my proposal is that we simplify. We only allow SDP in INVITE and then
provisionals/200 OK. No SDP in ACK. No SDP in PRACK. (sounds like a Dr.
Seuss rhyme, doesn't it?)

The latest 3pcc draft no longer recommends using the SDP-in-ACK, since it
has problems. Given that there don't seem to be useful applications of it
any longer, and given that, to my knowledge, it is not sent by anyone (at
least not in any commercially shipping boxes, I hope), I'd like to yank it.

There is a consequence, and that is dealing with the manyfolks requirement
for sending an updated SDP to deal with manyfolks+3pcc. My proposal for that
is to use a re-invite, rahter than PRACK, to carry the updated SDP. This
does mean that we need to allow, in SIP, a re-INVITE to arrive while an
initial INVITE is in progress. Allowing this would also address some of the
concerns raised in previous threads about handling requirements for changes
in early media.

I don't think its hard to deal with the re-INVITE while INVITE-is-active
case. The simplest solution is to reject the first INVITE and continue
processing with the second one, using the new SDP and all.

Anyway, before getting into those details, what does the group think about
dropping the SDP-in-ACK and SDP-in-PRACK stuff?

-Jonathan R.

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Vladislav Zubarev        mailto:vzubarev@cisco.com
Software Engineer        http://www.cisco.com
Cisco Systems, Inc.      http://www.vovida.org
  --------------D35D2E95F61B59D3A6E72E7D-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 18:22:56 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27158 for ; Fri, 1 Dec 2000 18:22:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 87CD34449B; Fri, 1 Dec 2000 17:20:34 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 6BE8E44357 for ; Thu, 30 Nov 2000 16:56:42 -0500 (EST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id OAA08540; Thu, 30 Nov 2000 14:56:25 -0800 (PST) Received: from cisco.com (vvs-lab-nat-171-69-180-242.cisco.com [171.69.180.242]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ACE17949 (AUTH vzubarev); Thu, 30 Nov 2000 14:55:53 -0800 (PST) Message-ID: <3A26DAE8.F3085FB7@cisco.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: Gethin Liddell Cc: Sip Mail List Subject: Re: [SIP] 3PCC and the re-invite response References: <00113012320203.20477@gethin> Content-Type: multipart/alternative; boundary="------------449EF58735B4D5AD8C0BA8FE" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 14:55:36 -0800 --------------449EF58735B4D5AD8C0BA8FE Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Completely agree with this point. I think it's dangerous to do it this way, since SDP (at least according to existing standard) could easily be changed in 200 OK, which would result in a crash of a controller or another set of re-INVITE, 200 OK, ACK !!! Gethin Liddell wrote: > people, > > i'm slightly concerened (maybe un-justifably) about the re-invite > working of the 3PCC draft. > > my concern is that it is possible (is it not?) for the user agent > receiving the re-invite to change its SDP settings in its response as > follows: > > A Controller B > | INV held SDP | | > |<------------------| | > | | | > | 200 SDP A1 | | > |-----------------> | INV SDP A1 | > | ACK |----------------->| > |<----------------- | | > | | 200 SDP B1 | > | |<-----------------| > | | | > | | ACK | > | INV SDP B1 |----------------->| > |<------------------| | > | 200 OK SDP A2 | | > |------------------>| | > | ACK | | > |<------------------| | > | | > | BROKEN RTP | > | | > | | > | | > > NOTE: A has returned different SDP in its two different 200 OK messages. > > Why might it do this? It might not but it is possible is it not. > > perhaps we should mandate that an agent can only change its SDP for a > session in an INVITE not in a response (after the initial > INVITE/RESPONSE exchange of course) > > what do we think? > > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Vladislav Zubarev mailto:vzubarev@cisco.com Software Engineer http://www.cisco.com Cisco Systems, Inc. http://www.vovida.org --------------449EF58735B4D5AD8C0BA8FE Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Completely agree with this point. I think it's dangerous to do it this way, since
SDP (at least according to existing standard) could easily be changed in 200 OK, which
would result in a crash of a controller or another set of re-INVITE, 200 OK, ACK !!!

Gethin Liddell wrote:

people,

i'm slightly concerened (maybe un-justifably) about the re-invite
working of the 3PCC draft.

my concern is that it is possible (is it not?) for the user agent
receiving the re-invite to change its SDP settings in its response as
follows:

 A                Controller            B
 |  INV held SDP     |                  |
 |<------------------|                  |
 |                   |                  |
 |  200 SDP A1       |                  |
 |-----------------> |  INV SDP A1      |
 |  ACK              |----------------->|
 |<----------------- |                  |
 |                   |  200 SDP B1      |
 |                   |<-----------------|
 |                   |                  |
 |                   |  ACK             |
 |  INV SDP B1       |----------------->|
 |<------------------|                  |
 |  200 OK SDP A2    |                  |
 |------------------>|                  |
 |  ACK              |                  |
 |<------------------|                  |
 |                                      |
 |               BROKEN RTP             |
 |                                      |
 |                                      |
 |                                      |

NOTE: A has returned different SDP in its two different 200 OK messages.

Why might it do this?  It might not but it is possible is it not.

perhaps we should mandate that an agent can only change its SDP for a
session in an INVITE not in a response (after the initial
INVITE/RESPONSE exchange of course)

what do we think?

--
Gethin Liddell
Ubiquity Software Corporation

http://www.ubiquity.net
mailto:gethin@ubiquity.net

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Vladislav Zubarev        mailto:vzubarev@cisco.com
Software Engineer        http://www.cisco.com
Cisco Systems, Inc.      http://www.vovida.org
  --------------449EF58735B4D5AD8C0BA8FE-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 18:26:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA28422 for ; Fri, 1 Dec 2000 18:26:48 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E0553444AD; Fri, 1 Dec 2000 17:20:53 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id EFF0E44357 for ; Thu, 30 Nov 2000 17:02:17 -0500 (EST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA09317; Thu, 30 Nov 2000 15:02:10 -0800 (PST) Received: from cisco.com (vvs-lab-nat-171-69-180-242.cisco.com [171.69.180.242]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ACE18113 (AUTH vzubarev); Thu, 30 Nov 2000 15:02:09 -0800 (PST) Message-ID: <3A26DC64.8B24427C@cisco.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Gethin Liddell'" , Sip Mail List Subject: Re: [SIP] 3PCC and the re-invite response References: Content-Type: multipart/alternative; boundary="------------6798305BF0A82E7EE1F2F4C2" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 15:01:56 -0800 --------------6798305BF0A82E7EE1F2F4C2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Looks like sticking to this re-INVITE approach is gonna be more complicated and probably messier rather than supporting INVITE no SDP, ACK with SDP, at least for SIP/H.323 gateways. Jonathan Rosenberg wrote: > This is a recognized problem. Note the following section in the document: > > In addition, note that in Figure 1, the controller sends a re-INVITE > to A with the SDP from B. The response to this re-INVITE is a 200 OK > that contains "SDP A". If the SDP returned in the re-INVITE response > were not the same, the controller would need to initiate a re-INVITE > to B with that new SDP. This means that a UA which returns a > > Rosenberg/Peterson/Schulzrinne/Camarillo [Page 12] > > Internet Draft 3pcc November 22, 2000 > > different SDP (for example, by changing the ports) in the response to > every re-INVITE will trigger an infinite re-INVITE loop from the > controller to each controller entity. As such, it is STRONGLY > RECOMMENDED that if a re-INVITE does not require a UAS to modify the > formulation of the SDP description for a specific stream in the > response, the SDP description of that stream in the response MUST be > the same. In other words, if a UA was in a session with a single > stream, using codec A, and it received a re-INVITE modifying the port > to send to, the re-INVITE response MUST be the same as it was to the > initial request. However, if the re-INVITE forces the UAS to change > codecs, it is acceptable in that case to use a different port in the > SDP in the response. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Gethin Liddell [mailto:gethin@ubiquity.net] > > Sent: Thursday, November 30, 2000 7:19 AM > > To: Sip Mail List > > Subject: [SIP] 3PCC and the re-invite response > > > > > > > > people, > > > > i'm slightly concerened (maybe un-justifably) about the re-invite > > working of the 3PCC draft. > > > > my concern is that it is possible (is it not?) for the user agent > > receiving the re-invite to change its SDP settings in its response as > > follows: > > > > A Controller B > > | INV held SDP | | > > |<------------------| | > > | | | > > | 200 SDP A1 | | > > |-----------------> | INV SDP A1 | > > | ACK |----------------->| > > |<----------------- | | > > | | 200 SDP B1 | > > | |<-----------------| > > | | | > > | | ACK | > > | INV SDP B1 |----------------->| > > |<------------------| | > > | 200 OK SDP A2 | | > > |------------------>| | > > | ACK | | > > |<------------------| | > > | | > > | BROKEN RTP | > > | | > > | | > > | | > > > > NOTE: A has returned different SDP in its two different 200 > > OK messages. > > > > Why might it do this? It might not but it is possible is it not. > > > > perhaps we should mandate that an agent can only change its SDP for a > > session in an INVITE not in a response (after the initial > > INVITE/RESPONSE exchange of course) > > > > what do we think? > > > > -- > > Gethin Liddell > > Ubiquity Software Corporation > > > > http://www.ubiquity.net > > mailto:gethin@ubiquity.net > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Vladislav Zubarev mailto:vzubarev@cisco.com Software Engineer http://www.cisco.com Cisco Systems, Inc. http://www.vovida.org --------------6798305BF0A82E7EE1F2F4C2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Looks like sticking to this re-INVITE approach is gonna be more complicated
and probably messier rather than supporting INVITE no SDP, ACK with SDP,
at least for SIP/H.323 gateways.

Jonathan Rosenberg wrote:

This is a recognized problem. Note the following section in the document:

   In addition, note that in Figure 1, the controller sends a re-INVITE
   to A with the SDP from B. The response to this re-INVITE is a 200 OK
   that contains "SDP A". If the SDP returned in the re-INVITE response
   were not the same, the controller would need to initiate a re-INVITE
   to B with that new SDP. This means that a UA which returns a

Rosenberg/Peterson/Schulzrinne/Camarillo                     [Page 12]

Internet Draft                    3pcc                 November 22, 2000

   different SDP (for example, by changing the ports) in the response to
   every re-INVITE will trigger an infinite re-INVITE loop from the
   controller to each controller entity. As such, it is STRONGLY
   RECOMMENDED that if a re-INVITE does not require a UAS to modify the
   formulation of the SDP description for a specific stream in the
   response, the SDP description of that stream in the response MUST be
   the same. In other words, if a UA was in a session with a single
   stream, using codec A, and it received a re-INVITE modifying the port
   to send to, the re-INVITE response MUST be the same as it was to the
   initial request. However, if the re-INVITE forces the UAS to change
   codecs, it is acceptable in that case to use a different port in the
   SDP in the response.

-Jonathan R.
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
jdrosen@dynamicsoft.com                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com
 

> -----Original Message-----
> From: Gethin Liddell [mailto:gethin@ubiquity.net]
> Sent: Thursday, November 30, 2000 7:19 AM
> To: Sip Mail List
> Subject: [SIP] 3PCC and the re-invite response
>
>
>
> people,
>
> i'm slightly concerened (maybe un-justifably) about the re-invite
> working of the 3PCC draft.
>
> my concern is that it is possible (is it not?) for the user agent
> receiving the re-invite to change its SDP settings in its response as
> follows:
>
>  A                Controller            B
>  |  INV held SDP     |                  |
>  |<------------------|                  |
>  |                   |                  |
>  |  200 SDP A1       |                  |
>  |-----------------> |  INV SDP A1      |
>  |  ACK              |----------------->|
>  |<----------------- |                  |
>  |                   |  200 SDP B1      |
>  |                   |<-----------------|
>  |                   |                  |
>  |                   |  ACK             |
>  |  INV SDP B1       |----------------->|
>  |<------------------|                  |
>  |  200 OK SDP A2    |                  |
>  |------------------>|                  |
>  |  ACK              |                  |
>  |<------------------|                  |
>  |                                      |
>  |               BROKEN RTP             |
>  |                                      |
>  |                                      |
>  |                                      |
>
> NOTE: A has returned different SDP in its two different 200
> OK messages.
>
> Why might it do this?  It might not but it is possible is it not.
>
> perhaps we should mandate that an agent can only change its SDP for a
> session in an INVITE not in a response (after the initial
> INVITE/RESPONSE exchange of course)
>
> what do we think?
>
> --
> Gethin Liddell
> Ubiquity Software Corporation
>
> http://www.ubiquity.net
> mailto:gethin@ubiquity.net
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Vladislav Zubarev        mailto:vzubarev@cisco.com
Software Engineer        http://www.cisco.com
Cisco Systems, Inc.      http://www.vovida.org
  --------------6798305BF0A82E7EE1F2F4C2-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 18:32:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA29970 for ; Fri, 1 Dec 2000 18:32:23 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 69AA3444B9; Fri, 1 Dec 2000 17:21:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 721B344357 for ; Thu, 30 Nov 2000 17:29:52 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA10081 for ; Thu, 30 Nov 2000 18:32:13 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 30 Nov 2000 18:27:47 -0500 Message-ID: From: Dean Willis To: "IETF SIP (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP IETF 49 Agenda Requests Last Call, Going Once, Twice . . . Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 30 Nov 2000 18:27:40 -0500 The (believed final) list of requested agenda slots is available from: http://www.softarmor.com/sipwg/meets/IETF49/requests.html If you made a request, please verify that it was recorded correctly. I will be publishing the agenda shortly. Thanks, -- Dean Willis _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 18:34:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA00678 for ; Fri, 1 Dec 2000 18:34:58 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F28ED444C3; Fri, 1 Dec 2000 17:21:24 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 4054F4445D for ; Fri, 1 Dec 2000 05:33:46 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26183; Fri, 1 Dec 2000 06:33:35 -0500 (EST) Message-Id: <200012011133.GAA26183@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-ietf-sip-guidelines-01.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 06:33:35 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : Guidelines for Authors of SIP Extensions Author(s) : J. Rosenberg, H. Schulzrinne Filename : draft-ietf-sip-guidelines-01.txt Pages : 16 Date : 30-Nov-00 The Session Initiation Protocol (SIP) is a flexible, yet simple tool for establishing interactive connections across the Internet. Part of this flexibility is the ease with which it can be extended. In order to facilitate effective and interoperable extensions to SIP, some guidelines need to be followed when developing SIP extensions. This document outlines a set of such guidelines for authors of SIP extensions. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-guidelines-01.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-guidelines-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-guidelines-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130115340.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-guidelines-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-guidelines-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115340.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 18:37:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA01367 for ; Fri, 1 Dec 2000 18:37:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 24632444C8; Fri, 1 Dec 2000 17:21:40 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id DF2C14445D for ; Fri, 1 Dec 2000 05:33:49 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26260; Fri, 1 Dec 2000 06:33:40 -0500 (EST) Message-Id: <200012011133.GAA26260@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-ietf-sip-callerprefs-03.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 06:33:39 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Caller Preferences and Callee Capabilities Author(s) : H. Schulzrinne, J. Rosenberg Filename : draft-ietf-sip-callerprefs-03.txt Pages : 28 Date : 30-Nov-00 This document describes a set of extensions to SIP which allow a caller to express preferences about request handling in servers. These preferences include the ability to select which URIs a call gets proxied or redirected to, and to specify certain request handling directives in proxies and redirect servers. It does so by defining three new request headers, Accept-Contact, Reject-Contact and Request-Disposition, which specify the callers preferences. The extension also defines new parameters for the Contact header. These extra parameters are present in the Contact header in REGISTER requests, and are used to associated attributes with particular addresses. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-callerprefs-03.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-callerprefs-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-callerprefs-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130115350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-callerprefs-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-callerprefs-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115350.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 18:41:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA02301 for ; Fri, 1 Dec 2000 18:41:43 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AFEDF444D5; Fri, 1 Dec 2000 17:22:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by lists.bell-labs.com (Postfix) with ESMTP id BE04144468 for ; Fri, 1 Dec 2000 09:10:40 -0500 (EST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA19548; Fri, 1 Dec 2000 07:10:31 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA10762; Fri, 1 Dec 2000 07:10:31 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14887.48999.121988.658471@thomasm-u1.cisco.com> To: Bryan Byerly Cc: Jonathan Rosenberg , "'sip@lists.bell-labs.com'" Subject: Re: [SIP] as if there wasn't enough traffic on this darn list... In-Reply-To: <3A27AF74.25CEBA71@cisco.com> References: <3A27AF74.25CEBA71@cisco.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 07:10:31 -0800 (PST) Content-Transfer-Encoding: 7bit Bryan Byerly writes: > Jonathan Rosenberg wrote: > Please elaborate on what specific problems you've identified w/r/t SDP in ACK. > > > It all adds up to a messy confusion. Its not clear what it means to send SDP > > in all these places, and how it works. > > So, let's clarify what the SDP does mean. If I understand this correctly -- and I may not -- it seems to me that the problem has more to do with mid transaction collisions between participants in a call and as such, it's not just SDP, but any other headers which could cause an unstable state, SDP being the most obvious. This can be because either the two UA's collide, or whether one of them just changes its mind mid-transaction. If I'm correct, it seems that the what Jonathan's recommending is, in effect, a way mitigating the collision problem by a strict state machine on where the SDP announcement can be seen so that they cannot collide. However, I'm suspicious that taking that tact may create a solution which is incomplete, draconian or both. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 18:44:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03054 for ; Fri, 1 Dec 2000 18:44:39 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C4D24444DA; Fri, 1 Dec 2000 17:22:25 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 8405F44337 for ; Fri, 1 Dec 2000 11:56:34 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eB1HuHZ20738; Fri, 1 Dec 2000 11:56:24 -0600 (CST) Received: from SMTP (eamrcnt747.exu.ericsson.se [138.85.133.37]) by mr4u3.ericy.com (8.10.2/8.10.2) with SMTP id eB1HuG108098; Fri, 1 Dec 2000 11:56:17 -0600 (CST) Received: from eamrcnt740.exu.ericsson.se ([138.85.133.41]) by 138.85.133.38 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 01 Dec 2000 17:56:16 0000 (GMT) Received: by eamrcnt740.exu.ericsson.se with Internet Mail Service (5.5.2651.58) id ; Fri, 1 Dec 2000 11:56:14 -0600 Message-ID: <125911DC0503D4119E2400508B0CCD2F017CEB6D@eamrcnt718.exu.ericsson.se> From: "Mattias Hartikainen (EUS)" To: "'Baniel Uri-CUB001'" , "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Session progress MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05BBF.FC2024A0" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 11:56:09 -0600 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_01C05BBF.FC2024A0 Content-Type: text/plain; charset="iso-8859-1" Hi, It's my interpretation that the 183 draft takes a telephony perspective. It's not strictly necessary to have the two way path in order to receive media (e.g. in-band information) from the callee. A one way path is enough for that. However, until you have established the two way path you effectively don't know whether you ever will be able to establish it, and from a telephony perspective that is not acceptable (I believe the draft elaborates on why). Cheers, Mattias Hartikainen -----Original Message----- From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] Sent: Friday, December 01, 2000 8:51 AM To: 'sip@lists.bell-labs.com' Subject: RE: [SIP] Session progress Hello there? Looks like either my question below was too basic/stupid or you guys are still thinking about the answer ? I will appreciate any response Thanks Uri -----Original Message----- From: Baniel Uri-CUB001 [mailto:Uri_Baniel-CUB001@email.mot.com] Sent: Monday, November 27, 2000 1:42 PM To: 'sip@lists.bell-labs.com' Subject: [SIP] Session progress Hi 1) Bis 4.2.1 says: "A UAC MUST be prepared to receive media data according to the session description as soon as it sends an INVITE (or re-INVITE) " 2) According the 183 draft that there must be first a two way path established (or at least the UAC should get first the UAS RTP information) before the UAC is able to get Alerting/call treatment RTP packets. I guess (2) overrides (1) (and is even included in 1 now) My question is: Why is the need to have the two way path established for being able to convey the RTP information from the UAS to the UAC? Thanks Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C05BBF.FC2024A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Session progress

Hi,

It's my interpretation that the 183 draft takes a = telephony
perspective.

It's not strictly necessary to have the two way path = in order to
receive media (e.g. in-band information) from the = callee. A one
way path is enough for that.

However, until you have established the two way path = you
effectively don't know whether you ever will be able = to
establish it, and from a telephony perspective that = is not
acceptable (I believe the draft elaborates on why). =

Cheers,
Mattias Hartikainen

-----Original Message-----
From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com]
Sent: Friday, December 01, 2000 8:51 AM
To: 'sip@lists.bell-labs.com'
Subject: RE: [SIP] Session progress


Hello there?

Looks like either my question below was too = basic/stupid or you guys are
still thinking about the answer ?
I will appreciate any response

Thanks

Uri

-----Original Message-----
From: Baniel Uri-CUB001 [mailto:Uri_Baniel-CUB001= @email.mot.com]
Sent: Monday, November 27, 2000 1:42 PM
To: 'sip@lists.bell-labs.com'
Subject: [SIP] Session progress


Hi

1) Bis 4.2.1 says:

"A UAC MUST be prepared to receive media data = according to the session
description as soon as it sends an INVITE (or = re-INVITE) "

2) According the 183 draft that there must be first a = two way path
established (or at least the UAC should get first = the UAS RTP information)
before the UAC is able to get Alerting/call = treatment RTP packets.

I guess (2) overrides (1) (and is even included in 1 = now)

My question is: Why is the need to have the two way = path established for
being able to convey the RTP information from the = UAS to the UAC?

Thanks
Uri








_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C05BBF.FC2024A0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 18:50:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04479 for ; Fri, 1 Dec 2000 18:50:41 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9532644483; Fri, 1 Dec 2000 17:33:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 264DD4444D for ; Fri, 1 Dec 2000 17:26:52 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id SAA21906; Fri, 1 Dec 2000 18:26:44 -0500 (EST) Message-ID: <0da901c05bee$749c5380$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Igor Slepchin" , "Sip Mail List" References: Subject: Re: [SIP] 3PCC and the re-invite response 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 18:28:48 -0500 Content-Transfer-Encoding: 7bit > > What I'm saying is that I don't see this as a problem with 3pcc at all. > Given Figure 1 in > http://search.ietf.org/internet-drafts/draft-rosenberg-sip-3pcc-01.txt, why > would A change the media in 200OK to the second INVITE? Instead of inventing > workarounds for eccentric UAs, it would be much easier to define what a > "sane" UA can and cannot do (e.g., it cannot change SDP just because it > received a re-INVITE, there should be another valid reason for the change). > The main reason during call setup is because codecs and other stuff may not have been fully negotiated. Another reason is because many current UA's respond to hold SDP with hold SDP. Thus both sides would be passing hold SDP with 0.0.0.0 as connection addresses, and the call would not get established. After a call has been established, the SDP-change-loop can occur if one of the sides chooses not to use the SDP information that it used prior to the hold. Many current implementation tend to use a different port when coming off hold, thus the race condition tends to occur often. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 18:52:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04998 for ; Fri, 1 Dec 2000 18:52:47 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 31357444D0; Fri, 1 Dec 2000 17:21:55 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 0F5334445D for ; Fri, 1 Dec 2000 05:33:56 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26318; Fri, 1 Dec 2000 06:33:46 -0500 (EST) Message-Id: <200012011133.GAA26318@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-ietf-sip-rfc2543bis-02.txt,.ps Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 06:33:45 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP: Session Initiation Protocol Author(s) : M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg Filename : draft-ietf-sip-rfc2543bis-02.txt,.ps Pages : 171 Date : 30-Nov-00 The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying and terminating sessions with one or more participants. These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-rfc2543bis-02.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-rfc2543bis-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-rfc2543bis-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001130115400.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-rfc2543bis-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-rfc2543bis-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001130115400.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 19:00:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA06844 for ; Fri, 1 Dec 2000 19:00:24 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5F145444F1; Fri, 1 Dec 2000 17:33:27 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 184D5444CC for ; Fri, 1 Dec 2000 17:23:42 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id SAA21629; Fri, 1 Dec 2000 18:23:30 -0500 (EST) Message-ID: <0da801c05bee$012e4ed0$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Henning Schulzrinne" Cc: "Sip Mail List" References: <3A28246C.9F4DE475@cs.columbia.edu> Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 18:25:34 -0500 Content-Transfer-Encoding: 7bit > I think it's easiest if an INVITE without SDP simply means "no change". > I.e., it has no influence on any media stream. If you didn't have a > media stream before, you don't have one afterwards. If you had some > before, they stay as is. I'm not clear why you would want to need or use > this for removing somebody from sending no media, since a re-INVITE with > the old, pre-hold media does this just fine. > > Thanks for the response. Yes, if the UA uses the same SDP before and after hold, then there is no problem. However you get into the fun persisting SDP over restart issue to allow the session to be re-established; and many UA's do not use the same port before and after hold. BroadSoft uses INVITE without SDP to avoid the SDP-change-loop when acting as a 3pcc to pull the subscribers off of hold. This has been successfully tested with other vendors. We can also transfer off of hold, but it seems to be unnecessary message overhead when using re-INVITE-without-SDP to mean the same as INVITE-without-SDP works better and was thought to have been previously agreed upon. If a re-INVITE without SDP does not mean the same thing as an INVITE without SDP, please explicitly state how they differ within section 4.2.1 or elsewhere in rfc2543. Without using a re-INVITE without SDP, what is suggested for A to query if B is willing to change codecs or add other streams to an existing call without having to try and fail? Thanks. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 19:22:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA11873 for ; Fri, 1 Dec 2000 19:22:25 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0F0FC44354; Fri, 1 Dec 2000 18:22:10 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id A258544337 for ; Fri, 1 Dec 2000 18:21:02 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Dec 1 19:19:33 EST 2000 Received: by lists.bell-labs.com (Postfix) id C092544380; Fri, 1 Dec 2000 19:07:16 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from bronx.dnrc.bell-labs.com (bronx.dnrc.bell-labs.com [135.180.160.8]) by lists.bell-labs.com (Postfix) with ESMTP id 9A5E64437D for ; Fri, 1 Dec 2000 19:07:16 -0500 (EST) Received: from cs.columbia.edu (ume [135.180.240.103]) by bronx.dnrc.bell-labs.com (8.9.3/8.9.3) with ESMTP id TAA01481; Fri, 1 Dec 2000 19:07:16 -0500 (EST) Message-ID: <3A283D37.D255508D@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.61 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A28246C.9F4DE475@cs.columbia.edu> <0da801c05bee$012e4ed0$4301a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 19:07:19 -0500 Content-Transfer-Encoding: 7bit > Yes, if the UA uses the same SDP before and after > hold, then there is no problem. However you > get into the fun persisting SDP over restart issue to > allow the session to be re-established; and many UA's > do not use the same port before and after hold. > > BroadSoft uses INVITE without SDP to avoid the > SDP-change-loop when acting as a 3pcc to > pull the subscribers off of hold. This has been > successfully tested with other vendors. We need to find a much better way of doing this. This is definitely broken. > > We can also transfer off of hold, but it seems to be > unnecessary message overhead when using > re-INVITE-without-SDP to mean the same as > INVITE-without-SDP works better and was > thought to have been previously agreed upon. > > If a re-INVITE without SDP does not mean the > same thing as an INVITE without SDP, please > explicitly state how they differ within > section 4.2.1 or elsewhere in rfc2543. They do not differ according to what I stated. If you invite initially, the other side had no media, so "no SDP" still means no media. Generally, I don't like "no SDP" as it breaks, as you point out, the idempotency of requests. I would much prefer treating changes as media additions and deletions, i.e., start with SDP with zero m lines and send new SDP with media (m lines) later once you know the details. That seems much cleaner. For a regular (no 3pcc) call, what's the problem with just sending the new ports when you want to allow media again? > > Without using a re-INVITE without SDP, what > is suggested for A to query if B is willing to > change codecs or add other streams to an > existing call without having to try and fail? OPTIONS is exactly meant for querying for capabilities. I have no idea what semantics "no SDP" should have in querying. > > Thanks. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 19:28:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13263 for ; Fri, 1 Dec 2000 19:28:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8C3CA44409; Fri, 1 Dec 2000 18:25:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id D2B23443F9 for ; Fri, 1 Dec 2000 18:24:27 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id TAA26052; Fri, 1 Dec 2000 19:24:19 -0500 (EST) Message-ID: <0de401c05bf6$80799cf0$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Jonathan Rosenberg" Cc: "Sip Mail List" References: Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 19:26:24 -0500 Content-Transfer-Encoding: 7bit > My perception of what was agreed to was not "an INVITE without SDP takes a > party off of hold", but rather, "a re-INVITE can have no SDP in the INVITE > request", for the reason, as I stated, that a normal INVITE can have no SDP > in it. Whether the implied semantics of re-INVITE with no SDP is "taking > someone off hold", is worth discussing. Thanks for the response. Can someone add this topic to the discussion list for the IETF? > > Anyway, if we had some general model of the sort where "the last SDP you > received is the active one from the other participant", as Dave has > suggested, then the semantics would, in fact, translate to taking the party > off hold. However, as Anders has correctly pointed out, its not the absence > of SDP in INVITE that does this (since the "previous" SDP still is one with > a held media stream), but rather the updated SDP in ACK. In this case, the > statement you should make is "SDP in an ACK, following a re-INVITE with no > SDP, following reinvite transaction that put a call on hold, takes the party > off hold". A mouthful, to be sure, but thats what you are really saying. > > -Jonathan R. > Thanks for the clarification. The main reason that I say that the INVITE without SDP instead of ACK with SDP is used as a request to pull off hold is because many SIP devices respond to a hold SDP with a hold SDP. At the bakeoff, those same products tended to continue to responded with hold SDP to an INVITE-without-SDP even though they were not the UA that originally requested the hold. This is fine, if that SIP UA intends to now be responsible to pull the session off hold. For those UA's that respond to hold SDP with non-hold SDP, the INVITE without SDP has tended to work; thus they might work with call setup of the 3pcc-01 draft. However the 3pcc would have to include all possible codecs in the original INVITE-to-hold of figure 1 to avoid restricting the two parties to a particular codec based upon Figure 1's flow. Using REFER to get "A" to trigger an INVITE or using a transfer after the original hold to "A" would allow "A" to populate the SDP however it wishes, and it would allow "A" to hear/see provisional and failure responses. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 20:54:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA01143 for ; Fri, 1 Dec 2000 20:54:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6DB4844345; Fri, 1 Dec 2000 19:54:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lists.bell-labs.com (Postfix) with ESMTP id 60BEB44337 for ; Fri, 1 Dec 2000 19:53:47 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id SAA27079; Fri, 1 Dec 2000 18:53:37 -0700 (MST)] Received: [from grumpy.rsch.comm.mot.com (grumpy.rsch.comm.mot.com [145.1.80.93]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id SAA29945; Fri, 1 Dec 2000 18:53:37 -0700 (MST)] Received: from labs.mot.com (localhost [127.0.0.1]) by grumpy.rsch.comm.mot.com (8.9.3+Sun/8.8.8) with ESMTP id TAA28273; Fri, 1 Dec 2000 19:54:05 -0600 (CST) Message-ID: <3A28563D.8B4DD10E@labs.mot.com> From: Bryan Thale Organization: Motorola Labs, Networking & Infrastructure Research X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: jainsip@sun.com, sip@lists.bell-labs.com, Ross Lillie References: <3A26EA0B.BADCD544@dynamicsoft.com> <3A26FB82.8201F239@labs.mot.com> <3A270071.AD24CCC3@dynamicsoft.com> <3A2703ED.3C294813@labs.mot.com> <3A2782AF.A2E9D3B8@dynamicsoft.com> <3A27DF50.3C319B86@labs.mot.com> <3A27E7B6.6C740DFE@dynamicsoft.com> <3A27FEAD.ED3374C4@labs.mot.com> <3A2812C0.2C4E0E46@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] [JAIN SIP] Header names and type codes Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 19:54:05 -0600 Content-Transfer-Encoding: 7bit Chris, > > Difference of opinion on style I guess. I prefer not to put anything in a > > super class (or super interface in this case) that ties it to its subclasses. > > I always seem to regret those reverse dependencies when I use them. > > OK - I guess if I step back and look at this, I have to say I shouldn't have moved > the header names to the base interface - every header has a name, but only > Accept-Encoding headers have a name of "Accept-Encoding", so I guess it logically > belongs to the sub-interface. I would want to change it from "token" to something > more meaningful though - "name" being the most obvious. What do you think? > That seems like the cleaner approach, keep each sub-interface self-contained and keep the super-interface generic. "name" makes excellent sense as the field name. > > On a similar topic, what do you envision as the purpose for the integer header > > type codes? > > The reason is to allow an application to treat (particularly experimental) headers > correctly - e.g. an implementation that knows an Call-Info is a general header can > tell the application this, and this overrides the default behaviour of treating it > as an entity header. This could work going down from the application to the > implementation too. I don't know how useful this actually is - but I figured > someone would probably want this functionality sooner rather than later. It sounds > like you think this should be dropped? > The integer type code, yes, unless someone has a specific need for it that can't be solved otherwise. The class/interface hierarchy should be able to differentiate between the different header types. The instanceof operator would be more reliable since it doesn't rely on a programmer-assigned integer which, if incorrect, could cause type mismatches at run-time. So, if a stack or application implementation knows about Call-Info headers it would have an interface hierarchy such as: interface Header; interface RequestHeader extends Header; // Empty Interface interface ResponseHeader extends Header; // Empty Interface interface CallInfoHeader extends RequestHeader, ResponseHeader, etc... Even if the recipient of such a header did not grok the meaning of a Call-Info header, polymorphism should allow it to correctly handle it as best it can given it doesn't know the specifics of the sub-interface. That is, the basic Header methods would all work OK which is all anyone who doesn't have knowledge of the specific Call-Info interface would need. And, the type system will allow the recipient to recognize it as a general/request/response header. I don't think a GeneralHeader interface tag is necessary since a "general header" is simply a header that can be both a "request header" and a "response header" and the multiple inheritance of interfaces solves that problem nicely. If Call-Info headers were unknown, they could be represented using a minimal UnrecognizedHeader interface such as: interface EntityHeader extends Header; // Empty Interface interface UnrecognizedHeader extends EntityHeader; BTW, the UnrecognizedHeader interface is the only one that would need to provide the setName() method. That would clean up the Header interface and avoid the problem of having an interface with a method this is unusable the vast majority of the time. How does that approach strike you? Bryan. -- Bryan Thale Motorola Labs, Networking and Infrastructure Research mailto:thale@labs.mot.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 21:03:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA02806 for ; Fri, 1 Dec 2000 21:03:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 42E8B443D7; Fri, 1 Dec 2000 20:03:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E311B44374 for ; Fri, 1 Dec 2000 20:02:48 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA21964; Fri, 1 Dec 2000 21:05:10 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 21:00:41 -0500 Message-ID: From: Igor Slepchin To: "'Brett Tate'" , Igor Slepchin , Sip Mail List Subject: RE: [SIP] 3PCC and the re-invite response MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 21:00:37 -0500 > Another reason is because > many current UA's respond to hold SDP with > hold SDP. Thus both sides would be passing > hold SDP with 0.0.0.0 as connection addresses, > and the call would not get established. If that's the case, scenario in Figure 1 of the 3pcc draft will not work no matter how much we try to fix it. In particular, that would mean that http://lists.bell-labs.com/pipermail/sip/2000q4/004391.html won't work as well, since both A and B would keep returning "on hold" SDP to the 3pcc forever. Hence, automatically putting other party on hold just because you were put on hold sounds like very wrong behavior. Just as you say in another email, some phones return on hold media even for INVITEs with no SDP, which plainly cannot be fixed. So isn't it better to fix the UAs instead of creating workarounds that don't always work anyway? > The main reason during call setup is because > codecs and other stuff may not have been > fully negotiated. <..> > After a call has been established, the > SDP-change-loop can occur if one of the sides > chooses not to use the SDP information that it > used prior to the hold. The loop will only happen if an implementation is constantly changing its SDP on _every_ re-Invite. Such implementation is clearly broken. Otherwise, all you need in the worst case is an extra re-Invite from 3pcc to B. > Many current > implementation tend to use a different port when > coming off hold, thus the race condition tends > to occur often. I think that this behavior should be specifically discouraged; there is little reason to change ports after going "off hold". And even if a UA does change ports, this will only result in one extra re-INVITE from 3pcc, not a loop. That said, I do agree that your solution works. However, I don't think that it gives you many advantages over standard INVITE with SDP approach and it seems like an unnecessary exception from SIP media negotiation model. Thank you, Igor Slepchin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 22:17:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14678 for ; Fri, 1 Dec 2000 22:17:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C281744374; Fri, 1 Dec 2000 21:17:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 28A6444337 for ; Fri, 1 Dec 2000 21:16:52 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 19:16:28 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , sip@lists.bell-labs.com Cc: "'Jonathan Rosenberg'" Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 19:16:28 -0800 > > > My point is the request-uri that the UAC sends, may quite likely be > > different to the request-uri that the last record-route > proxy sees, eg > > > > UA sends with a request-uri of angel@ua.com; a proxy changes this to > > angel@plane6.hell.com. The last proxy sees this URI not the > initial one. > > Thus if the UAC adds it Request-URI to the last ROute entry > then its going > > to really confuse things. > > True. However, I have great faith in optimistic routing. How did > the angel@ua.com map to angel@plane6.hell.com in the first place? > Simple scenario: ua.com runs SRV, and angel had registered as being > at plane6.hell.com. Therefore, that Request-URI would still work. Call forwarding, roaming, alias addresses (eg helpdesk@company.com is forwarded to actual employee SIP url), domain changing (eg sip:bruce@company.com to sip:bruce@sd.company.com); proxies mapping tel's to ascii SIP URL's, ect etct etc. > > That's worse than putting nothing - at least if the proxy > stores call > route state then it can succeed - if the UA adds an > > incorrect Route then the proxy has no choice but to blindly > follow the > > (incorrect) Route header !! > > The cases where I can see the proxy doing better than the UA is: > * There is some sort of temporal based routing > * The initial routing is obscure (i.e., not literally SRV based) > But it is fair to say that the proxy will "win" in these cases. See above. > Still, I'm not convinced; but also I'm not that passionate. > Either way is a reasonable solution (with the proxy-does-the-work > being slightly more robust), so whatever the concensus is, eh? > (Although it does look like everybody else has given up, so we > might have to toss a coin... (:&) As I see it, adding the extra Record-ROute header in the no Contact case is simply an easy way for the LAST proxy to store call state on how it will forward a request to the UA (in the absence of the UA providing this info in a Contact). [A lot simpler, in my mind, than trying to embed and retrieve URL's and addresses in Record-Route URL parameters.] Unrelated to the above, Jonathan, you had an opinion of whether it was a MUST or MAY that - user name in Record-Route MUST/MAY be non-zero. - Record-Route MUST/MAY be different in each direction (ie proxy MUST/MAY locate and change R-R in response). Are you still sticking to your guns on this or ambivalent. [invariantness verse operational complexity] I originally liked the idea but I'm hard pushed to see that it really makes things less brittle _in practice_ and so I am inclined to just leave it up to the proxy. Anyone have any other problems with what has been propsed (reposted below)? Jo, if we want people to comment we should just propose actual bis text changes - it worked last time. :) Proposal: -Record-Route headers must be SIP URL's. -The address in the SIP URL must be the UDP reachable address of the proxy inserting the route. -The username and any parameters added to the URL to the header are implementation defined. -The Record-Route should use angle brackets. Ie, Record-Route: ;zzzzz=zzzzz where y are the implementation defined Record-Route URL parameters and zzzz are the implementation defined Record-Route header parameters. xxxxx, yyyyy & zzzzz may be empty (ie no restrictions) -If multiple Record-Routes are added for the same request (ie, spiral route), then each Record-Route added MUST be different so that they can be distinguished. -In the response to a Record-Route'd request, a proxy MAY change any Record-Route header that the it originally generated. -A UAS must copy the Record-Route unchanged into the Route header; a UAC must copy the Record-Route unchanged into the Route header, reversing the order. A Route header is added if a Contact is added (as before). -If a proxy inserts the first Record-Route header into a request without a Contact header, then the Proxy MAY add a second Record-Route header below the normal R-R header which contains the From URL address with the source address as an maddr parameter. -If in a received final response which does not contain a Contact header, a proxy finds that it has generated the first Record-Route header in the list, then the proxy MAY add another Record-Route header to the top of the R-R list which contains the original request's request-URI with the request's forward address as an maddr parameter. What about the 401 Unauthortized responses (and another one) where it can be expected that another INVITE with the same Call-Id will be issued? The bis recommends that they can also contain Record-Routes. Are we keeping this? Should we make it more general (for the proxy) that any final response can contain the Record-Route headers but UA's should only generate R-R's when the stated property is met. Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 22:52:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23015 for ; Fri, 1 Dec 2000 22:52:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB54544349; Fri, 1 Dec 2000 21:52:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id D06A844337 for ; Fri, 1 Dec 2000 21:51:12 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Fri, 1 Dec 2000 19:50:49 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , sip@lists.bell-labs.com Cc: "'Jonathan Rosenberg'" Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 1 Dec 2000 19:50:49 -0800 > > Unrelated to the above, Jonathan, you had an opinion of > whether it was a > MUST or MAY that > - user name in Record-Route MUST/MAY be non-zero. > - Record-Route MUST/MAY be different in each direction (ie > proxy MUST/MAY > locate and change R-R in response). > > Are you still sticking to your guns on this or ambivalent. > [invariantness > verse operational complexity] > Perhaps you can think of it as a conditional invariant: The request-uri always refers to the final destination unless the message contains a Route header in which case the request-uri refers to the next Record-Routed proxy. Cheers, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 1 23:30:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27699 for ; Fri, 1 Dec 2000 23:30:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 410164437F; Fri, 1 Dec 2000 22:30:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id 778BE44337 for ; Fri, 1 Dec 2000 22:29:48 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G4X00G01B554L@firewall.mcit.com> for sip@lists.bell-labs.com; Sat, 2 Dec 2000 04:29:30 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([166.38.62.39]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G4X008G0B55J6@firewall.mcit.com>; Sat, 02 Dec 2000 04:29:29 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) id <0G4X00601AXS5K@pmismtp04.wcomnet.com>; Sat, 02 Dec 2000 04:25:04 +0000 (GMT) Received: from pmismtp04.wcomnet.com by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G4X00601AXQ5B@pmismtp04.wcomnet.com>; Sat, 02 Dec 2000 04:25:04 +0000 (GMT) Received: from wcom.com ([166.44.59.182]) by pmismtp04.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G4X0024SAXJXH@pmismtp04.wcomnet.com>; Sat, 02 Dec 2000 04:24:58 +0000 (GMT) From: Alan Johnston To: Jonathan Rosenberg , Peter Mataga , Henning Schulzrinne Cc: SIP List Message-id: <3A287B7B.F9A7B768@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en Subject: [SIP] Questions on draft-rosenberg-sip-app-components-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 01 Dec 2000 22:33:00 -0600 Content-Transfer-Encoding: 7bit Jonathan/Peter/Henning, A couple of questions about some of the examples in your excellent and informative draft. (If I could only get some of the MEGACO proponents in my organization to read and understand it...) 1. On page 16, section 5.4, referring to Figure 3, you say: "The next step for the AS is to get a stream of DTMF digits to flow from the caller to the media server. To do this, it sends a re-INVITE to the caller (11). This re-INVITE contains the same SDP as the response (6) from the called party, but with the addition of a new media line. This media line is audio, and contains a single codec, the RTP payload format for DTMF and tones [8]. The connection address and port are from the SDP returned from the media server. This tells the caller to send an additional media stream to the media server, using only the DTMF codec. " I'm not sure I understand what the SDP in the re-INVITE should look like. Lets say the SDP in the 200 OK (6) from the Callee contained: c=IN IP4 100.101.102.103 m=audio 5004 RTP/AVP 0 Lets say the SDP in the 200 OK (3) from the Media Server contained: c=IN IP4 200.201.202.203 m=audio 53000 RTP/AVP 96 (Not sure about this line, but it would indicate port 53000 and the DTMF encoding) The text says that media line from (3) is added to the SDP from (6), but what about the connection line which has a different IP address? I'm not sure that the SDP of c=IN IP4 200.201.202.203 m=audio 5004 RTP/AVP 0 m=audio 53000 RTP/AVP 96 would have the desired effect. Normally, wouldn't this SDP say to send media to ports 5004 and 53000 at 200.201.202.203 (since the actual intent is to send the PCMU to port 5004 at 100.101.102.103)? Or, would this SDP look completely different? 2. In Figure 5, the IVR call flow shows the Callee sending IVR commands to the IVR Server after the receipt of the 183 Session Progress, but before any 200 OK. I think this could be useful, but I'm wondering if User Agents that support Early Media like this would actually send RTP packets prior to getting a 200 OK. For example, if a Gateway to the PSTN sends a 183 Session Progress, it may not include the a=sendonly attribute, but any RTP packets prior to call completion in the PSTN would be simply dropped. 3. In Figure 9, the Web Enabled Message Drops call flow, I am trying to decide if the first message should be a HTTP POST or a GET as it is shown. Your description indicates that a single click activates the service - the trigger is simply that the particular URL has been accessed. I understand that each mailbox for each user would have a URL. My question is how the Web Caller's SIP URL is sent to the Controller, since the Controller initiates the INVITE (3). Would it be somehow imbedded as a parameter in the URL? Or, should the message be a POST, in which case the Web Caller would type in their SIP URL, click the submit button, and the combination of the URL and the form data would give the controller enough information to setup the call. Finally, one perhaps dumb question relating to this example. If the SIP User Agent and the HTTP Client were on the same machine, couldn't the Web Caller just click on a link containing a SIP URL (instead of a HTTP URL) of the desired mailbox which would cause the caller's SIP User Agent to simply place the call? Again, thanks for detailing this very useful method of decomposition. Alan Johnston _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 2 06:27:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29679 for ; Sat, 2 Dec 2000 06:27:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 395FA44339; Sat, 2 Dec 2000 05:27:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8F57344337 for ; Sat, 2 Dec 2000 05:26:57 -0500 (EST) Received: from dynamicsoft.com ([212.120.151.92]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id GAA22584; Sat, 2 Dec 2000 06:29:10 -0500 (EST) Message-ID: <3A28DC50.D393E5C9@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bryan Thale Cc: jainsip@sun.com, sip@lists.bell-labs.com, Ross Lillie Subject: Re: [SIP] [JAIN SIP] Header names and type codes References: <3A26EA0B.BADCD544@dynamicsoft.com> <3A26FB82.8201F239@labs.mot.com> <3A270071.AD24CCC3@dynamicsoft.com> <3A2703ED.3C294813@labs.mot.com> <3A2782AF.A2E9D3B8@dynamicsoft.com> <3A27DF50.3C319B86@labs.mot.com> <3A27E7B6.6C740DFE@dynamicsoft.com> <3A27FEAD.ED3374C4@labs.mot.com> <3A2812C0.2C4E0E46@dynamicsoft.com> <3A28563D.8B4DD10E@labs.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 02 Dec 2000 11:26:08 +0000 Content-Transfer-Encoding: 7bit Bryan > > > On a similar topic, what do you envision as the purpose for the integer header > > > type codes? > > > > The reason is to allow an application to treat (particularly experimental) headers > > correctly - e.g. an implementation that knows an Call-Info is a general header can > > tell the application this, and this overrides the default behaviour of treating it > > as an entity header. This could work going down from the application to the > > implementation too. I don't know how useful this actually is - but I figured > > someone would probably want this functionality sooner rather than later. It sounds > > like you think this should be dropped? > > > > The integer type code, yes, unless someone has a specific need for it > that can't be solved otherwise. The class/interface hierarchy should be > able to differentiate between the different header types. The > instanceof operator would be more reliable since it doesn't rely on a > programmer-assigned integer which, if incorrect, could cause type > mismatches at run-time. So, if a stack or application implementation > knows about Call-Info headers it would have an interface hierarchy such > as: > > interface Header; > interface RequestHeader extends Header; // Empty Interface > interface ResponseHeader extends Header; // Empty Interface > interface CallInfoHeader extends RequestHeader, ResponseHeader, etc... > The original API class hierarchy originally had this layer of GeneralHeader, RequestHeader, ResponseHeader and EntityHeader - but it was suggested that this added unnecessary complexity to the API - thus the header type attribute was born. I personally preferred the extra layer and would love to see it replace the header type attribute. In fact, now that the hierarchy is defined in terms of interfaces rather than classes, there is a very strong case for adding this layer again. Does anyone have any objections to this? > > Even if the recipient of such a header did not grok the meaning of a > Call-Info header, polymorphism should allow it to correctly handle it as > best it can given it doesn't know the specifics of the sub-interface. > That is, the basic Header methods would all work OK which is all anyone > who doesn't have knowledge of the specific Call-Info interface would > need. And, the type system will allow the recipient to recognize it as > a general/request/response header. > > I don't think a GeneralHeader interface tag is necessary since a > "general header" is simply a header that can be both a "request header" > and a "response header" and the multiple inheritance of interfaces > solves that problem nicely. I think a GeneralHeader interface would be useful to indicate to an application that it should copy a received unrecognised header into a response. > > > If Call-Info headers were unknown, they could be represented using a > minimal UnrecognizedHeader interface such as: > > interface EntityHeader extends Header; // Empty Interface > interface UnrecognizedHeader extends EntityHeader; The interfaces for different header types would imply the existence of UnrecognizedEntityHeader, UnrecognizedRequestHeader, UnrecognizedResponseHeader and UnrecognizedGeneralHeader rather than just UnrecognizedHeader. We would also need a createUnrecognizedEntityHeader, createUnrecognizedRequestHeader, createUnrecognizedResponseHeader and createUnrecognizedGeneralHeader methods on the JainSipHeaderFactory. Is this acceptable? Would it be preferable to just remove the setName (and setMethod) method from the Header interface, and only have the name parameter in the factory's createHeader method? If not, I would suggest that the setName method should not be any header interfaces - the name should be fixed upon creation of the object. > > > BTW, the UnrecognizedHeader interface is the only one that would need to > provide the setName() method. That would clean up the Header interface > and avoid the problem of having an interface with a method this is > unusable the vast majority of the time. > > How does that approach strike you? > > Bryan. > > -- > Bryan Thale > Motorola Labs, Networking and Infrastructure Research > mailto:thale@labs.mot.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 2 08:28:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA29974 for ; Sat, 2 Dec 2000 08:28:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CFE1044339; Sat, 2 Dec 2000 07:28:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3FC5D44337 for ; Sat, 2 Dec 2000 07:27:17 -0500 (EST) Received: from dynamicsoft.com (ip204.honxr4.ras.tele.dk [195.215.92.204]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id IAA22684; Sat, 2 Dec 2000 08:29:25 -0500 (EST) Message-ID: <3A28F8D4.14DBD13@dynamicsoft.com> From: Anders Kristensen Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: Jonathan Rosenberg , "'Gethin Liddell'" , Sip Mail List Subject: Re: [SIP] 3PCC and the re-invite response References: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 02 Dec 2000 14:27:48 +0100 Content-Transfer-Encoding: 7bit Brett Tate wrote: > > BroadSoft uses the re-INVITE without SDP and ACK > with SDP to avoid the possibility of both sides getting > into the mentioned SDP change loop. Technically speaking, I don't see how this solves anything. The UAS can change SDP in its 200 response to a re-INVITE regardless of whether the re-INVITE contained SDP or not. Thus having the 3pcc controller shift SDP from the re-INVITE to the ACK changes nothing. The potential for looping still exist. I think the solution has to be to limit what SDP changes can be made in 200 responses and ACKs. Anders > > This is why BroadSoft would like to keep the use of > ACK with SDP at least with regard to re-INVITEs. > > This is also why it would be nice for rfc2543 to mention > that an INVITE without SDP can be used as a request > to pull the receiver off of hold. This has been discussed > at the backoff and on the news group, but is currently > not explicitly mentioned in rfc2543. > > ----- Original Message ----- > From: Jonathan Rosenberg > To: 'Gethin Liddell' ; Sip Mail List > > Sent: Thursday, November 30, 2000 11:23 AM > Subject: RE: [SIP] 3PCC and the re-invite response > > > This is a recognized problem. Note the following section in the document: > > > > In addition, note that in Figure 1, the controller sends a re-INVITE > > to A with the SDP from B. The response to this re-INVITE is a 200 OK > > that contains "SDP A". If the SDP returned in the re-INVITE response > > were not the same, the controller would need to initiate a re-INVITE > > to B with that new SDP. This means that a UA which returns a > > > > > > > > Rosenberg/Peterson/Schulzrinne/Camarillo [Page 12] > > > > Internet Draft 3pcc November 22, 2000 > > > > > > different SDP (for example, by changing the ports) in the response to > > every re-INVITE will trigger an infinite re-INVITE loop from the > > controller to each controller entity. As such, it is STRONGLY > > RECOMMENDED that if a re-INVITE does not require a UAS to modify the > > formulation of the SDP description for a specific stream in the > > response, the SDP description of that stream in the response MUST be > > the same. In other words, if a UA was in a session with a single > > stream, using codec A, and it received a re-INVITE modifying the port > > to send to, the re-INVITE response MUST be the same as it was to the > > initial request. However, if the re-INVITE forces the UAS to change > > codecs, it is acceptable in that case to use a different port in the > > SDP in the response. > > > > > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > > -----Original Message----- > > > From: Gethin Liddell [mailto:gethin@ubiquity.net] > > > Sent: Thursday, November 30, 2000 7:19 AM > > > To: Sip Mail List > > > Subject: [SIP] 3PCC and the re-invite response > > > > > > > > > > > > people, > > > > > > i'm slightly concerened (maybe un-justifably) about the re-invite > > > working of the 3PCC draft. > > > > > > my concern is that it is possible (is it not?) for the user agent > > > receiving the re-invite to change its SDP settings in its response as > > > follows: > > > > > > A Controller B > > > | INV held SDP | | > > > |<------------------| | > > > | | | > > > | 200 SDP A1 | | > > > |-----------------> | INV SDP A1 | > > > | ACK |----------------->| > > > |<----------------- | | > > > | | 200 SDP B1 | > > > | |<-----------------| > > > | | | > > > | | ACK | > > > | INV SDP B1 |----------------->| > > > |<------------------| | > > > | 200 OK SDP A2 | | > > > |------------------>| | > > > | ACK | | > > > |<------------------| | > > > | | > > > | BROKEN RTP | > > > | | > > > | | > > > | | > > > > > > NOTE: A has returned different SDP in its two different 200 > > > OK messages. > > > > > > Why might it do this? It might not but it is possible is it not. > > > > > > perhaps we should mandate that an agent can only change its SDP for a > > > session in an INVITE not in a response (after the initial > > > INVITE/RESPONSE exchange of course) > > > > > > what do we think? > > > > > > -- > > > Gethin Liddell > > > Ubiquity Software Corporation > > > > > > http://www.ubiquity.net > > > mailto:gethin@ubiquity.net > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 2 14:38:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA29081 for ; Sat, 2 Dec 2000 14:38:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 87B4044338; Sat, 2 Dec 2000 13:38:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A2AEC44337 for ; Sat, 2 Dec 2000 13:37:51 -0500 (EST) Received: from dynamicsoft.com (userac13.ie.uudial.com [212.120.133.212]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA23081; Sat, 2 Dec 2000 14:39:56 -0500 (EST) Message-ID: <3A294F52.2F44994@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bryan Thale Cc: jainsip@sun.com, sip@lists.bell-labs.com, Ross Lillie Subject: Re: [SIP] [JAIN SIP] Header names and type codes References: <3A26EA0B.BADCD544@dynamicsoft.com> <3A26FB82.8201F239@labs.mot.com> <3A270071.AD24CCC3@dynamicsoft.com> <3A2703ED.3C294813@labs.mot.com> <3A2782AF.A2E9D3B8@dynamicsoft.com> <3A27DF50.3C319B86@labs.mot.com> <3A27E7B6.6C740DFE@dynamicsoft.com> <3A27FEAD.ED3374C4@labs.mot.com> <3A2812C0.2C4E0E46@dynamicsoft.com> <3A28563D.8B4DD10E@labs.mot.com> Content-Type: multipart/alternative; boundary="------------DBD885AEED2C2727804D0BFB" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 02 Dec 2000 19:36:50 +0000 --------------DBD885AEED2C2727804D0BFB Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bryan, Actually we could move both the getName() and setName() methods of header to UnrecognizedHeader - the application can use instanceof rather than getName() with the same advantages associated with the header type interfaces - the getName() method would only ever be invoked if(receivedHeader instanceof UnrecognizedHeader). [Of course if the application wants the actual text of the header name it can just use XXXHeader.name]. What do you think? So now things are looking like (with createMethods only for the bottom four of the hierarchy in JainSipHeaderFactory) Header | +---UnrecognizedHeader(getName(), setName()) | | | +-----------------------------------+ | | +---GeneralHeader | | | | | +---UnrecognizedGeneralHeader-------+ | | +---RequestHeader | | | | | +---UnrecognizedRequestHeader-------+ | | +---ResponseHeader | | | | | +---UnrecognizedResponseHeader------+ | | +---EntityHeader | | | +---UnrecognizedEntityHeader--------+ How does this look? Chris Bryan Thale wrote: > Chris, > > > > Difference of opinion on style I guess. I prefer not to put anything in a > > > super class (or super interface in this case) that ties it to its subclasses. > > > I always seem to regret those reverse dependencies when I use them. > > > > OK - I guess if I step back and look at this, I have to say I shouldn't have moved > > the header names to the base interface - every header has a name, but only > > Accept-Encoding headers have a name of "Accept-Encoding", so I guess it logically > > belongs to the sub-interface. I would want to change it from "token" to something > > more meaningful though - "name" being the most obvious. What do you think? > > > > That seems like the cleaner approach, keep each sub-interface > self-contained and keep the super-interface generic. "name" makes > excellent sense as the field name. > > > > On a similar topic, what do you envision as the purpose for the integer header > > > type codes? > > > > The reason is to allow an application to treat (particularly experimental) headers > > correctly - e.g. an implementation that knows an Call-Info is a general header can > > tell the application this, and this overrides the default behaviour of treating it > > as an entity header. This could work going down from the application to the > > implementation too. I don't know how useful this actually is - but I figured > > someone would probably want this functionality sooner rather than later. It sounds > > like you think this should be dropped? > > > > The integer type code, yes, unless someone has a specific need for it > that can't be solved otherwise. The class/interface hierarchy should be > able to differentiate between the different header types. The > instanceof operator would be more reliable since it doesn't rely on a > programmer-assigned integer which, if incorrect, could cause type > mismatches at run-time. So, if a stack or application implementation > knows about Call-Info headers it would have an interface hierarchy such > as: > > interface Header; > interface RequestHeader extends Header; // Empty Interface > interface ResponseHeader extends Header; // Empty Interface > interface CallInfoHeader extends RequestHeader, ResponseHeader, etc... > > Even if the recipient of such a header did not grok the meaning of a > Call-Info header, polymorphism should allow it to correctly handle it as > best it can given it doesn't know the specifics of the sub-interface. > That is, the basic Header methods would all work OK which is all anyone > who doesn't have knowledge of the specific Call-Info interface would > need. And, the type system will allow the recipient to recognize it as > a general/request/response header. > > I don't think a GeneralHeader interface tag is necessary since a > "general header" is simply a header that can be both a "request header" > and a "response header" and the multiple inheritance of interfaces > solves that problem nicely. > > If Call-Info headers were unknown, they could be represented using a > minimal UnrecognizedHeader interface such as: > > interface EntityHeader extends Header; // Empty Interface > interface UnrecognizedHeader extends EntityHeader; > > BTW, the UnrecognizedHeader interface is the only one that would need to > provide the setName() method. That would clean up the Header interface > and avoid the problem of having an interface with a method this is > unusable the vast majority of the time. > > How does that approach strike you? > > Bryan. > > -- > Bryan Thale > Motorola Labs, Networking and Infrastructure Research > mailto:thale@labs.mot.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------DBD885AEED2C2727804D0BFB Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bryan,

Actually we could move both the getName() and setName() methods of header to UnrecognizedHeader - the application can use instanceof rather than getName() with the same advantages associated with the header type interfaces - the getName() method would only ever be invoked if(receivedHeader instanceof UnrecognizedHeader). [Of course if the application wants the actual text of the header name it can just use XXXHeader.name]. What do you think?

So now things are looking like (with createMethods only for the bottom four of the hierarchy in JainSipHeaderFactory)

Header
   |
   +---UnrecognizedHeader(getName(), setName())
   |         |
   |         +-----------------------------------+
   |                                             |
   +---GeneralHeader                             |
   |         |                                   |
   |         +---UnrecognizedGeneralHeader-------+
   |                                             |
   +---RequestHeader                             |
   |         |                                   |
   |         +---UnrecognizedRequestHeader-------+
   |                                             |
   +---ResponseHeader                            |
   |         |                                   |
   |         +---UnrecognizedResponseHeader------+
   |                                             |
   +---EntityHeader                              |
             |                                   |
             +---UnrecognizedEntityHeader--------+

How does this look?

Chris
 

Bryan Thale wrote:

Chris,

> > Difference of opinion on style I guess.  I prefer not to put anything in a
> > super class (or super interface in this case) that ties it to its subclasses.
> > I always seem to regret those reverse dependencies when I use them.
>
> OK - I guess if I step back and look at this, I have to say I shouldn't have moved
> the header names to the base interface - every header has a name, but only
> Accept-Encoding headers have a name of "Accept-Encoding", so I guess it logically
> belongs to the sub-interface. I would want to change it from "token" to something
> more meaningful though - "name" being the most obvious. What do you think?
>

That seems like the cleaner approach, keep each sub-interface
self-contained and keep the super-interface generic.  "name" makes
excellent sense as the field name.

> > On a similar topic, what do you envision as the purpose for the integer header
> > type codes?
>
> The reason is to allow an application to treat (particularly experimental) headers
> correctly - e.g. an implementation that knows an Call-Info is a general header can
> tell the application this, and this overrides the default behaviour of treating it
> as an entity header. This could work going down from the application to the
> implementation too. I don't know how useful this actually is - but I figured
> someone would probably want this functionality sooner rather than later. It sounds
> like you think this should be dropped?
>

The integer type code, yes, unless someone has a specific need for it
that can't be solved otherwise.  The class/interface hierarchy should be
able to differentiate between the different header types.  The
instanceof operator would be more reliable since it doesn't rely on a
programmer-assigned integer which, if incorrect, could cause type
mismatches at run-time.  So, if a stack or application implementation
knows about Call-Info headers it would have an interface hierarchy such
as:

interface Header;
interface RequestHeader extends Header;  // Empty Interface
interface ResponseHeader extends Header;  // Empty Interface
interface CallInfoHeader extends RequestHeader, ResponseHeader, etc...

Even if the recipient of such a header did not grok the meaning of a
Call-Info header, polymorphism should allow it to correctly handle it as
best it can given it doesn't know the specifics of the sub-interface.
That is, the basic Header methods would all work OK which is all anyone
who doesn't have knowledge of the specific Call-Info interface would
need.  And, the type system will allow the recipient to recognize it as
a general/request/response header.

I don't think a GeneralHeader interface tag is necessary since a
"general header" is simply a header that can be both a "request header"
and a "response header" and the multiple inheritance of interfaces
solves that problem nicely.

If Call-Info headers were unknown, they could be represented using a
minimal UnrecognizedHeader interface such as:

interface EntityHeader extends Header;   // Empty Interface
interface UnrecognizedHeader extends EntityHeader;

BTW, the UnrecognizedHeader interface is the only one that would need to
provide the setName() method.  That would clean up the Header interface
and avoid the problem of having an interface with a method this is
unusable the vast majority of the time.

How does that approach strike you?

Bryan.

--
Bryan Thale
Motorola Labs, Networking and Infrastructure Research
mailto:thale@labs.mot.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

--------------DBD885AEED2C2727804D0BFB-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 2 18:00:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA21154 for ; Sat, 2 Dec 2000 18:00:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D375A44338; Sat, 2 Dec 2000 17:00:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 515DB44337 for ; Sat, 2 Dec 2000 16:59:29 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id RAA08305; Sat, 2 Dec 2000 17:59:20 -0500 (EST) Message-ID: <0ea701c05cb3$ccc444d0$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Henning Schulzrinne" Cc: "Sip Mail List" References: <3A28246C.9F4DE475@cs.columbia.edu> <0da801c05bee$012e4ed0$4301a8c0@broadsoft.com> <3A283D37.D255508D@cs.columbia.edu> Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 2 Dec 2000 18:01:26 -0500 Content-Transfer-Encoding: 7bit > > Yes, if the UA uses the same SDP before and after > > hold, then there is no problem. However you > > get into the fun persisting SDP over restart issue to > > allow the session to be re-established; and many UA's > > do not use the same port before and after hold. > > > > BroadSoft uses INVITE without SDP to avoid the > > SDP-change-loop when acting as a 3pcc to > > pull the subscribers off of hold. This has been > > successfully tested with other vendors. > > We need to find a much better way of doing this. This is definitely > broken. Thanks for the response. I agree that it is broken if two vendors are interpreting differently what the re-INVITE without SDP means. However I have attempted to get it cleared up in the news group and at bakeoffs. I thought that the news group and the advanced SIP media companies were in agreement. I just now found out that we all were not. > > > > > We can also transfer off of hold, but it seems to be > > unnecessary message overhead when using > > re-INVITE-without-SDP to mean the same as > > INVITE-without-SDP works better and was > > thought to have been previously agreed upon. > > > > If a re-INVITE without SDP does not mean the > > same thing as an INVITE without SDP, please > > explicitly state how they differ within > > section 4.2.1 or elsewhere in rfc2543. > > They do not differ according to what I stated. If you invite initially, > the other side had no media, so "no SDP" still means no media. Let me restate what September rfc2543-02 section 4.2.1 says concerning would the receiver of an INVITE without SDP. "The INVITE method indicates that the user or service is being invited to participate in a session. The message body MAY contain a description of the session to which the callee is being invited. For two-party calls, the caller indicates the type of media it is able to receive and possibly the media it is willing to send as well as their parameters such as network destination. A success response MUST indicate in its message body which media the callee wishes to receive and MAY indicate the media the callee is going to send." "The caller MAY choose to omit the request body (i.e., not send a session description) or send a session description that does not list any media type. This indicates that the caller does not know its desired media characteristics until the call has been accepted. In this case, the UAS SHOULD still return a session description in its informational (1xx) or success (2xx) response, containing those media streams and codecs it supports." The above indicates that an INVITE without SDP incates a request to commicate and the receiver indicates the media types, characteristics, and locations for communition before the caller does. Notice that a full SDP (all codecs, eccetera) is supplied in a 200 response just as if it sent the INVITE. To me (and at least previously other major SIP players) a re-INVITE-without-SDP and INVITE-without-SDP had the same meaning and indicate a request to communicate. The no-hold-SDP in ACK would show that the sender no longer has the receiver on HOLD, and receiver can send media accorging to the ACK's SDP. > > Generally, I don't like "no SDP" as it breaks, as you point out, the > idempotency of requests. I would much prefer treating changes as media > additions and deletions, i.e., start with SDP with zero m lines and send > new SDP with media (m lines) later once you know the details. That seems > much cleaner. This is fine, but I assume that more vendors support no SDP than partial SDP since partial SDP violates rfc2327. But of course, I could be wrong. :) When I first posted "[SIP] Hold & then re-INVITE without media" in June, I thought that some might argue for partial SDP instead of no SDP. However, no one did. What is the benefit of controller supplying partial SDP over no SDP since both UA's should be able to pass completely new SDP's when coming off of hold? > > For a regular (no 3pcc) call, what's the problem with just sending the > new ports when you want to allow media again? Nothing, except that hold currently is defined as changing the connection address to 0.0.0.0 instead changing the port to 0. If you are asking what is wrong with using a different port before/after hold, nothing excluding 3pcc. That is why I did not want a special request for 3pcc. Instead, I just wanted to explicitly mention the re-INVITE-without-SDP and ACK-with-non-hold-SDP should be expected by those UA's that pass back hold-SDP after receiving hold-SDP. Based upon Jonathan's quote "if you can do something in a first INVITE, it is allowed in a re-INVITE", I did not feel any changes actually needed to be made to the specification. I only ask for it as a means to highlight what I thought Rosenberg, Sparks, news group, others, and myself had already agreed that rfc2543bis section 4.2.1 allowed. > > > > > Without using a re-INVITE without SDP, what > > is suggested for A to query if B is willing to > > change codecs or add other streams to an > > existing call without having to try and fail? > > OPTIONS is exactly meant for querying for capabilities. I have no idea > what semantics "no SDP" should have in querying. According to Section 4.2.1, INVITE-without-SDP basically means the same thing as OPTIONS but corresponds to this particular session and works with fewer messages. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 2 18:39:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25518 for ; Sat, 2 Dec 2000 18:39:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A885944338; Sat, 2 Dec 2000 17:39:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 12E3844337 for ; Sat, 2 Dec 2000 17:38:20 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id SAA10728; Sat, 2 Dec 2000 18:38:11 -0500 (EST) Message-ID: <0ec901c05cb9$3a287910$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Anders Kristensen" Cc: "Sip Mail List" References: <069201c05afd$055f95f0$4301a8c0@broadsoft.com> <3A28F8D4.14DBD13@dynamicsoft.com> Subject: Re: [SIP] 3PCC and the re-invite response 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 2 Dec 2000 18:40:17 -0500 Content-Transfer-Encoding: 7bit > > BroadSoft uses the re-INVITE without SDP and ACK > > with SDP to avoid the possibility of both sides getting > > into the mentioned SDP change loop. > > Technically speaking, I don't see how this solves anything. The UAS can > change SDP in its 200 response to a re-INVITE regardless of whether the > re-INVITE contained SDP or not. Thus having the 3pcc controller shift > SDP from the re-INVITE to the ACK changes nothing. The potential for > looping still exist. Please read more within the thread; Gethin provided a flow using INVITE without SDP that works. I'd prefer getting A's SDP by using a no-call REFER or hold-then-transfer to "B" through controller as means for call setup to allow "A" to hear/see ringing/failure when INVITE "B". > > I think the solution has to be to limit what SDP changes can be made in > 200 responses and ACKs. > I agree that limiting what SDP changes can occur through the course of the session would simplify matters. However it would also greatly reduce the capabilities/services that are already being provided by some controllers and other smart SIP entities. SDP in PRACKs and SDP changes during session timer extending 200 responses, produce some interesting challenges for 3pcc, but they can be resolved by extra messaging, coding, and potentially more detailed specification. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 2 19:50:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA03408 for ; Sat, 2 Dec 2000 19:50:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8321744338; Sat, 2 Dec 2000 18:50:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id 6F42C44337 for ; Sat, 2 Dec 2000 18:49:15 -0500 (EST) Received: from tate ([64.241.199.106]) by broadsoft.com (8.8.8) id TAA14702; Sat, 2 Dec 2000 19:49:07 -0500 (EST) Message-ID: <0ef901c05cc3$22cb49a0$4301a8c0@broadsoft.com> From: "Brett Tate" To: "Sip Mail List" References: Subject: Re: [SIP] 3PCC and the re-invite response 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 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 2 Dec 2000 19:51:13 -0500 Content-Transfer-Encoding: 7bit > > Another reason is because > > many current UA's respond to hold SDP with > > hold SDP. Thus both sides would be passing > > hold SDP with 0.0.0.0 as connection addresses, > > and the call would not get established. > > If that's the case, scenario in Figure 1 of the 3pcc draft will not work no > matter how much we try to fix it. In particular, that would mean that > http://lists.bell-labs.com/pipermail/sip/2000q4/004391.html won't work as > well, since both A and B would keep returning "on hold" SDP to the 3pcc > forever. Hence, automatically putting other party on hold just because you > were put on hold sounds like very wrong behavior. Just as you say in another > email, some phones return on hold media even for INVITEs with no SDP, which > plainly cannot be fixed. So isn't it better to fix the UAs instead of > creating workarounds that don't always work anyway? Gethin's flow works for 3pcc call setup. However a no-call REFER (if still valid) or hold-then-transfer A to B through controller also works and allows A to hear/see the call progress/fail. The hold part that I assume I referred to deals with re-INVITE-without-SDP and ACK-with-SDP to indicate that the sender no longer has the receiver on hold. This is currently being discussed in thread "[SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response]". > > > The main reason during call setup is because > > codecs and other stuff may not have been > > fully negotiated. > <..> > > After a call has been established, the > > SDP-change-loop can occur if one of the sides > > chooses not to use the SDP information that it > > used prior to the hold. > > The loop will only happen if an implementation is constantly changing its > SDP on _every_ re-Invite. Such implementation is clearly broken. Otherwise, > all you need in the worst case is an extra re-Invite from 3pcc to B. Changing ports on every re-INVITE is not "broken" since rfc2543 allows it, and it is a test for advance SIP media. However I too would hate to constantly receive a new SDP in 200 response to a session timer extending INVITE. But I assume at this point, all rfc2543 can do is "strongly discourage port hopping SDP's for no other reason besides changing ports". > > > Many current > > implementation tend to use a different port when > > coming off hold, thus the race condition tends > > to occur often. > > I think that this behavior should be specifically discouraged; there is > little reason to change ports after going "off hold". And even if a UA does > change ports, this will only result in one extra re-INVITE from 3pcc, not a > loop. > > That said, I do agree that your solution works. However, I don't think that > it gives you many advantages over standard INVITE with SDP approach and it > seems like an unnecessary exception from SIP media negotiation model. I'm all for discouraging ports changing when coming off hold. But lets discuss the INVITE without SDP stuff in thread "[SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response]". Thanks for the response. Maybe one of the 3pcc authors can organize a bof at the IETF meeting if there is enough interest in this stuff. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 07:45:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05640 for ; Sun, 3 Dec 2000 07:45:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB9D144338; Sun, 3 Dec 2000 06:45:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from motgate.mot.com (unknown [129.188.136.100]) by lists.bell-labs.com (Postfix) with ESMTP id E3E2E44337 for ; Sun, 3 Dec 2000 06:44:34 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id FAA16424 for ; Sun, 3 Dec 2000 05:44:26 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id FAA05411 for ; Sun, 3 Dec 2000 05:44:25 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Sun, 3 Dec 2000 06:44:25 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8754@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Subject: [SIP] A MIP style of registration Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Dec 2000 06:44:23 -0600 Hello there Say I am a SIP Mobile phone traveling to an unknown destination. I am provisioned with the addressing information of my "home" Registrar. Once I have arrived at the foreign network (SIP domain) I discover my local SIP registrar. Is it possible then to perform a MIP type of registration, i.e. SIP registration with my local registrar, asking it to register on my behalf with my home registrar (by supplying my SIP URL as the alias/phone and its own address as 'care of address") ? Thanks Uri P.S. Jonathan, IF it is not currently supported THEN please do not take it as an advice for a change/addition... _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 10:20:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA25701 for ; Sun, 3 Dec 2000 10:20:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 885474434E; Sun, 3 Dec 2000 09:20:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 38ABC44337 for ; Sun, 3 Dec 2000 09:19:41 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA25043; Sun, 3 Dec 2000 10:19:32 -0500 (EST) Message-ID: <3A2A6484.95B44359@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Brett Tate Cc: Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A28246C.9F4DE475@cs.columbia.edu> <0da801c05bee$012e4ed0$4301a8c0@broadsoft.com> <3A283D37.D255508D@cs.columbia.edu> <0ea701c05cb3$ccc444d0$4301a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 03 Dec 2000 10:19:32 -0500 Content-Transfer-Encoding: 7bit I believe that the simple set of rules should be - always send SDP in INVITE and 200 - if you don't know the media yet, don't include m lines. That is perfectly legal according to RFC 2327: "Zero or more media descriptions (see below)" - Use the normal "0.0.0.0 means hold" (I had mis-spoken about ports) - if you want to find out what the other side can do, but without changing things, use OPTIONS (this is needed anyway, since you need to find the whole set; no-SDP doesn't cover this) This is much closer to the spirit of soft-state and always-send-full-state that underlies other Internet protocols. Clearly, the spec needs to spell this out more explicitly. This is also much simpler since it integrates hold and normal media changes/additions into one mechanism, rather than two. Whether we need to address what end system should do if senders don't conform is a separate issue. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 11:12:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07076 for ; Sun, 3 Dec 2000 11:12:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 159F544357; Sun, 3 Dec 2000 10:12:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp02.wcom.com (dgesmtp02.wcom.com [199.249.16.17]) by lists.bell-labs.com (Postfix) with ESMTP id 31AEB44337 for ; Sun, 3 Dec 2000 10:11:06 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42261) id <0G50003012A9YO@firewall.mcit.com> for sip@lists.bell-labs.com; Sun, 3 Dec 2000 16:10:57 +0000 (GMT) Received: from pmismtp02.wcomnet.com ([166.38.62.37]) by firewall.mcit.com (PMDF V5.2-33 #42261) with ESMTP id <0G500030Z2A9QS@firewall.mcit.com>; Sun, 03 Dec 2000 16:10:57 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) id <0G5000G012A91A@pmismtp02.wcomnet.com>; Sun, 03 Dec 2000 16:10:57 +0000 (GMT) Received: from pmismtp02.wcomnet.com by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G5000G012A815@pmismtp02.wcomnet.com>; Sun, 03 Dec 2000 16:10:56 +0000 (GMT) Received: from hsinnreich ([166.44.57.175]) by pmismtp02.wcomnet.com (PMDF V5.2-33 #42259) with SMTP id <0G50008FT29W9Q@pmismtp02.wcomnet.com>; Sun, 03 Dec 2000 16:10:45 +0000 (GMT) From: Henry Sinnreich Subject: RE: [SIP] 3PCC and the re-invite response In-reply-to: <0ef901c05cc3$22cb49a0$4301a8c0@broadsoft.com> To: Brett Tate , Sip Mail List Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 03 Dec 2000 10:11:22 -0600 Content-Transfer-Encoding: 7bit >Maybe one of the >3pcc authors can organize a bof at the >IETF meeting if there is enough interest >in this stuff. Yes, I believe there is interest, since 3pcc is a fundamental feature, used in other drafts, such as Henry -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Brett Tate Sent: Saturday, December 02, 2000 6:51 PM To: Sip Mail List Subject: Re: [SIP] 3PCC and the re-invite response > > Another reason is because > > many current UA's respond to hold SDP with > > hold SDP. Thus both sides would be passing > > hold SDP with 0.0.0.0 as connection addresses, > > and the call would not get established. > > If that's the case, scenario in Figure 1 of the 3pcc draft will not work no > matter how much we try to fix it. In particular, that would mean that > http://lists.bell-labs.com/pipermail/sip/2000q4/004391.html won't work as > well, since both A and B would keep returning "on hold" SDP to the 3pcc > forever. Hence, automatically putting other party on hold just because you > were put on hold sounds like very wrong behavior. Just as you say in another > email, some phones return on hold media even for INVITEs with no SDP, which > plainly cannot be fixed. So isn't it better to fix the UAs instead of > creating workarounds that don't always work anyway? Gethin's flow works for 3pcc call setup. However a no-call REFER (if still valid) or hold-then-transfer A to B through controller also works and allows A to hear/see the call progress/fail. The hold part that I assume I referred to deals with re-INVITE-without-SDP and ACK-with-SDP to indicate that the sender no longer has the receiver on hold. This is currently being discussed in thread "[SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response]". > > > The main reason during call setup is because > > codecs and other stuff may not have been > > fully negotiated. > <..> > > After a call has been established, the > > SDP-change-loop can occur if one of the sides > > chooses not to use the SDP information that it > > used prior to the hold. > > The loop will only happen if an implementation is constantly changing its > SDP on _every_ re-Invite. Such implementation is clearly broken. Otherwise, > all you need in the worst case is an extra re-Invite from 3pcc to B. Changing ports on every re-INVITE is not "broken" since rfc2543 allows it, and it is a test for advance SIP media. However I too would hate to constantly receive a new SDP in 200 response to a session timer extending INVITE. But I assume at this point, all rfc2543 can do is "strongly discourage port hopping SDP's for no other reason besides changing ports". > > > Many current > > implementation tend to use a different port when > > coming off hold, thus the race condition tends > > to occur often. > > I think that this behavior should be specifically discouraged; there is > little reason to change ports after going "off hold". And even if a UA does > change ports, this will only result in one extra re-INVITE from 3pcc, not a > loop. > > That said, I do agree that your solution works. However, I don't think that > it gives you many advantages over standard INVITE with SDP approach and it > seems like an unnecessary exception from SIP media negotiation model. I'm all for discouraging ports changing when coming off hold. But lets discuss the INVITE without SDP stuff in thread "[SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response]". Thanks for the response. Maybe one of the 3pcc authors can organize a bof at the IETF meeting if there is enough interest in this stuff. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 11:38:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13903 for ; Sun, 3 Dec 2000 11:38:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 79F9C4435B; Sun, 3 Dec 2000 10:38:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5108B44337 for ; Sun, 3 Dec 2000 10:37:39 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA00527; Sun, 3 Dec 2000 11:39:39 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Dec 2000 11:35:08 -0500 Message-ID: From: Jonathan Rosenberg To: "'Jo Hornsby'" , "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Dec 2000 11:35:07 -0500 > -----Original Message----- > From: Jo Hornsby [mailto:jhornsby@ubiquity.net] > Sent: Friday, December 01, 2000 5:12 AM > To: Fairlie-Cuninghame, Robert; sip@lists.bell-labs.com > Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements > > Still, I'm not convinced; but also I'm not that passionate. > Either way is a reasonable solution (with the proxy-does-the-work > being slightly more robust), so whatever the concensus is, eh? > (Although it does look like everybody else has given up, so we > might have to toss a coin... (:&) Well, not given up, by I have a job besides reading and answering mail on the sip ml, and keeping up these days on a daily basis is a full time job. That said, this enormous thread has run all over the place. I think there is a fair amount of agreement, with just a little bit of disagreement. My perception of the consensus is: 1. the current bis mechanism of having the UA mangle the record-route is gone. 2. in the forward direction, the proxy inserts a URL which must route to itself. I further believe that the consensus is that this should be a SIP URL. I'll say a bit more on that in a moment. 3. UAS copies RR in its entirety into response. 4. proxy MAY modify the RR in the response 5. UAC build the route as described in rfc2543, UAS builds the route by putting the Contact on the end of the RR set. 6. The RR inserted is largely at the discretion of the proxy, subject to (2). There was some debate about whether the RR URL could be a SIP URL. I think it should be - primarily because it simplifies operation, is backwards compatible, and guaranteed to interoperate. Since no other URL type is guaranteed to be supported, inserting anything but a SIP URL may result in an interop problem. In any case, the primary purpose of the URL in the RR (and indeed, the URL in Contact header in INVITE and 200 OK as well) is identifying a specific entity at a specific next hop server. Its purpose is therefore to represent an address more than a name, and a SIP URL is ideal here. Now, the issues of contention remain: 1. should modification of the URL in the RR in the response be MAY or SHOULD or MUST 2. Robert's proposed Contact/RR mangling to deal with UAs that don't insert Contact Regarding 1: I think there are lots of advantages to being able to insert a different URL into the response; the transport can be different on each side, for example, which cannot be done if only a single URL is inserted. It also allows for stateless determination of call direction in a proxy. It allows for services to be applied to a request which can operate independently of whether its an initial (thus without Route, using the R-URI alone to identify the target) or subsequent (in which case the Request URI, From/To and possibly other headers are needed) request. It also works in proxies which don't actually pop the top Route and use it, but rather do something and then forward the request to a specific next hop (this can be used to break a single proxy into a number of smaller ones that appear as a single proxy to the outside). But, all of that points to MAY, not SHOULD. However, I would argue that, in practice, proxy users will find increasing numbers of use cases where the request URI needs to be something meaningful. Specifically, any time a proxy actually wants to apply any kind of processing on the request beyond pop-the-top-route-and-forward. As a result, this feature is likely to be a MUST in practice. The only argument I can make for the SHOULD requirement in the spec is that it makes the protocol less brittle; correct operation no longer depends on Route processing being done correctly at every single proxy. So, I'm willing to compromise here, and keep this a MAY in the spec, so long as the functionality is described, along with some of the cases where it will find useful application. Regarding 2: This seems a very orthogonal issue. I don't really like it, because I don't think it will be needed in practice, and it makes assumptions about processing at previous hops. Specifically, it assumes that the non-existence of the Contact header implies an older client, and it assumes that the To/From field won't successfully get a call routed properly. I can imagine a SIP security proxy that removes all internal Via/Contact/RR headers, and inserts a single RR header pointing to itself. The next hop proxy might then insert a Contact header, making things very confusing. I also don't think it will be needed in practice, since making Contact mandatory was one of the first things we added to bis. I think that most UA devices do insert Contact these days. In any case, I hate to litter a spec with hacks designed to support features that are only potentially useful during a transition period (which may already be over). -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 12:14:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23801 for ; Sun, 3 Dec 2000 12:14:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C79234435F; Sun, 3 Dec 2000 11:14:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 2D3D644337 for ; Sun, 3 Dec 2000 11:13:32 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA29252; Sun, 3 Dec 2000 12:13:06 -0500 (EST) Message-ID: <3A2A7F22.D223F928@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Jo Hornsby'" , "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Subject: Re: [SIP] RECORD-ROUTE/ROUTE requirements References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 03 Dec 2000 12:13:06 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > 1. the current bis mechanism of having the UA mangle the record-route is > gone. Are you talking about the UAS creating routes in the callee-to-caller direction or what other mangling? > 2. in the forward direction, the proxy inserts a URL which must route to > itself. I further believe that the consensus is that this should be a SIP > URL. I'll say a bit more on that in a moment. > 3. UAS copies RR in its entirety into response. > 4. proxy MAY modify the RR in the response > 5. UAC build the route as described in rfc2543, UAS builds the route by > putting the Contact on the end of the RR set. Let's see if I got this right. Let's assume the following example: alice@from calls bob@yahoo, who is really bob@acme, which translates to bob@sales.acme, which becomes bob@pc.sales.acme All entities (yahoo, acme, and sales.acme) RR. Thus, we have on the forward direction when the request reaches bob, the 200 OK becomes: Contact: sip:bob@pc.sales.acme Record-Route: sip:bob@sales.acme, sip:bob@acme, sip:bob@yahoo Alice now sends subsequent requests as Route: sip:bob@yahoo, sip:bob@acme, sip:bob@sales.acme, sip:bob@pc.sales.acme Contact: alice@from If Bob wants to send requests to Alice, are we still at the old mechanism or is the assumption that Bob inserts Route: sip:bob@sales.acme, sip:bob@acme, sip:bob@yahoo and leaves it up to the proxy to figure out that this request is going in the reverse direction? (It only matters for yahoo in this example.) > 6. The RR inserted is largely at the discretion of the proxy, subject to > (2). Thus, the requirement for maddr insertion disappears, presumably. > > There was some debate about whether the RR URL could be a SIP URL. I think > it should be - primarily because it simplifies operation, is backwards > compatible, and guaranteed to interoperate. Since no other URL type is > guaranteed to be supported, inserting anything but a SIP URL may result in > an interop problem. In any case, the primary purpose of the URL in the RR > (and indeed, the URL in Contact header in INVITE and 200 OK as well) is > identifying a specific entity at a specific next hop server. Its purpose is > therefore to represent an address more than a name, and a SIP URL is ideal > here. To elaborate: all other URL types, say, H.323 or tel, are by definition meant to route to any number of destinations. By definition, this determination should be made when first routing the request. RR is meant to make sure that requests get back to the same place, to update state, for example. Thus, using non-SIP URLs directly contradicts this goal. It is also far from clear why this is useful, given that all other URLs can be translated into a unique token at the proxy that originally received the non-SIP URL. > > Now, the issues of contention remain: > > 1. should modification of the URL in the RR in the response be MAY or SHOULD > or MUST I assume you mean that the Record-Route in the 200 is mangled by the original proxy that stuck it there in the first place? > 2. Robert's proposed Contact/RR mangling to deal with UAs that don't insert > Contact > > Regarding 1: > > I think there are lots of advantages to being able to insert a different URL > into the response; the transport can be different on each side, for example, > which cannot be done if only a single URL is inserted. It also allows for > stateless determination of call direction in a proxy. It allows for services > to be applied to a request which can operate independently of whether its an > initial (thus without Route, using the R-URI alone to identify the target) > or subsequent (in which case the Request URI, From/To and possibly other > headers are needed) request. It also works in proxies which don't actually > pop the top Route and use it, but rather do something and then forward the > request to a specific next hop (this can be used to break a single proxy > into a number of smaller ones that appear as a single proxy to the outside). > But, all of that points to MAY, not SHOULD. > > However, I would argue that, in practice, proxy users will find increasing > numbers of use cases where the request URI needs to be something meaningful. > Specifically, any time a proxy actually wants to apply any kind of > processing on the request beyond pop-the-top-route-and-forward. As a result, > this feature is likely to be a MUST in practice. > > The only argument I can make for the SHOULD requirement in the spec is that > it makes the protocol less brittle; correct operation no longer depends on > Route processing being done correctly at every single proxy. > > So, I'm willing to compromise here, and keep this a MAY in the spec, so long > as the functionality is described, along with some of the cases where it > will find useful application. SHOULD is, in any event, a weasle answer, since nobody else can rely on this behavior. > > Regarding 2: > > This seems a very orthogonal issue. I don't really like it, because I don't > think it will be needed in practice, and it makes assumptions about > processing at previous hops. Specifically, it assumes that the non-existence > of the Contact header implies an older client, and it assumes that the > To/From field won't successfully get a call routed properly. I can imagine a > SIP security proxy that removes all internal Via/Contact/RR headers, and > inserts a single RR header pointing to itself. The next hop proxy might then > insert a Contact header, making things very confusing. > > I also don't think it will be needed in practice, since making Contact > mandatory was one of the first things we added to bis. I think that most UA > devices do insert Contact these days. In any case, I hate to litter a spec > with hacks designed to support features that are only potentially useful > during a transition period (which may already be over). -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 12:56:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07549 for ; Sun, 3 Dec 2000 12:56:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1C92244366; Sun, 3 Dec 2000 11:56:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8C80A44337 for ; Sun, 3 Dec 2000 11:55:31 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA00667; Sun, 3 Dec 2000 12:57:46 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Dec 2000 12:53:14 -0500 Message-ID: From: Jonathan Rosenberg To: "'Henning Schulzrinne'" , Billy Biggs Cc: Dean Willis , SIP List Subject: RE: [SIP] Single Line Extension work MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Dec 2000 12:53:13 -0500 This would work fine assuming that people were happy with a conferencing server being present. I think the motivation was to try to solve it in a more distributed way. That, however, will have to wait until the fully distributed multiparty conferencing work is done. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Henning Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, December 01, 2000 5:35 PM > To: Billy Biggs > Cc: Dean Willis; SIP List > Subject: Re: [SIP] Single Line Extension work > > > The behavior that motivated this was the ability to call > brady@families-r-us.com and get connected to everyone. > Effectively, this > can be solved by a back-to-back UA/conferencing server with a > conference > called 'brady' that makes outgoing calls to the members of the family. > (This server would have to CANCEL the other calls as soon as the first > one answers. Family members could dial into brady@families-r-us.com to > get connected to the on-going call.) Thus, is this more than just an > implementation issue? Would it be sufficient to document this case in > the conferencing draft? > > Billy Biggs wrote: > > > > > A while back we had a vigorous discussion going on how to > implement > > > the PBX/Centrex "single line extension" service or get behavior > > > similar to US residentil "party lines". > > > > > > I don't believe I've seen any discussion on this topic for a long > > > time. Anybody still working on it, or can we declare the > effort dead > > > for now? > > > > Jonathan and Henning's draft on multi-party conferencing > models is an > > important step forward in discussing conferencing services such as > > single line extension. The continuing work on presence > extensions and > > event subscriptions also helps. > > > > But until the puzzle fits together a little more, the single line > > extension work is quite fluffy. Hopefully this will change > in the next > > few months. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 13:08:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10159 for ; Sun, 3 Dec 2000 13:08:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EA5AB4436F; Sun, 3 Dec 2000 12:08:09 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E73CB4436B for ; Sun, 3 Dec 2000 12:07:06 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA00704; Sun, 3 Dec 2000 13:09:26 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Dec 2000 13:04:54 -0500 Message-ID: From: Jonathan Rosenberg To: "'Henning G. Schulzrinne'" , Jonathan Rosenberg Cc: "'Jo Hornsby'" , "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Dec 2000 13:04:53 -0500 > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, December 03, 2000 12:13 PM > To: Jonathan Rosenberg > Cc: 'Jo Hornsby'; Fairlie-Cuninghame, Robert; sip@lists.bell-labs.com > Subject: Re: [SIP] RECORD-ROUTE/ROUTE requirements > > > Jonathan Rosenberg wrote: > > > > > 1. the current bis mechanism of having the UA mangle the > record-route is > > gone. > > Are you talking about the UAS creating routes in the callee-to-caller > direction or what other mangling? The one about the UAS constructing the Route in the reverse direction (callee to caller) based on combining the RR with the Contact/From. > > > 2. in the forward direction, the proxy inserts a URL which > must route to > > itself. I further believe that the consensus is that this > should be a SIP > > URL. I'll say a bit more on that in a moment. > > 3. UAS copies RR in its entirety into response. > > 4. proxy MAY modify the RR in the response > > 5. UAC build the route as described in rfc2543, UAS builds > the route by > > putting the Contact on the end of the RR set. > > Let's see if I got this right. Let's assume the following example: > > alice@from calls bob@yahoo, who is really bob@acme, which > translates to > bob@sales.acme, which becomes bob@pc.sales.acme > > All entities (yahoo, acme, and sales.acme) RR. Thus, we have on the > forward direction when the request reaches bob, the 200 OK becomes: > > Contact: sip:bob@pc.sales.acme > Record-Route: sip:bob@sales.acme, > sip:bob@acme, > sip:bob@yahoo > Nearly; these URLs probably don't meet the requirement of causing the request to be routed to the server that inserted them, so an maddr would be needed. > Alice now sends subsequent requests as > > Route: sip:bob@yahoo, sip:bob@acme, sip:bob@sales.acme, > sip:bob@pc.sales.acme > Contact: alice@from Yes. > > If Bob wants to send requests to Alice, are we still at the old > mechanism or is the assumption that Bob inserts > > Route: sip:bob@sales.acme, sip:bob@acme, sip:bob@yahoo Nearly; it would also incldue the Contact from the request, so: Route: sip:bob@sales.acme, sip:bob@acme, sip:bob@yahoo, sip:alice@alices-contact.com > > and leaves it up to the proxy to figure out that this request is going > in the reverse direction? (It only matters for yahoo in this example.) If the proxy needs to have requests with different URIs in each direction, then it would modify the URL in the RR in the response. If it doesn't do that, then yes, it would need to rely on To/From to determine direction. However, as long as the proxies aren't doing anything besides forwarding the requests, the next Route header indicates where the request should go to, so determining direction won't be needed. > > > > 6. The RR inserted is largely at the discretion of the > proxy, subject to > > (2). > > Thus, the requirement for maddr insertion disappears, presumably. IFF the request URI routes to that server specifically. The incoming request URI in the original request probably does not have that property. > > > > > There was some debate about whether the RR URL could be a > SIP URL. I think > > it should be - primarily because it simplifies operation, > is backwards > > compatible, and guaranteed to interoperate. Since no other > URL type is > > guaranteed to be supported, inserting anything but a SIP > URL may result in > > an interop problem. In any case, the primary purpose of the > URL in the RR > > (and indeed, the URL in Contact header in INVITE and 200 OK > as well) is > > identifying a specific entity at a specific next hop > server. Its purpose is > > therefore to represent an address more than a name, and a > SIP URL is ideal > > here. > > To elaborate: all other URL types, say, H.323 or tel, are by > definition > meant to route to any number of destinations. By definition, this > determination should be made when first routing the request. > RR is meant > to make sure that requests get back to the same place, to > update state, > for example. Thus, using non-SIP URLs directly contradicts > this goal. It > is also far from clear why this is useful, given that all > other URLs can > be translated into a unique token at the proxy that > originally received > the non-SIP URL. Yes. > > > > > Now, the issues of contention remain: > > > > 1. should modification of the URL in the RR in the response > be MAY or SHOULD > > or MUST > > I assume you mean that the Record-Route in the 200 is mangled by the > original proxy that stuck it there in the first place? Yes. Performing this allows the URIs in each direction for subsequent request to be different, and even be resolvable on their own to the appropriate party. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 13:39:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20587 for ; Sun, 3 Dec 2000 13:39:47 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 965164439B; Sun, 3 Dec 2000 12:38:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 34C024439A for ; Sun, 3 Dec 2000 12:37:16 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eB3IawZ07308; Sun, 3 Dec 2000 12:36:58 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id eB3IawK06557; Sun, 3 Dec 2000 12:36:58 -0600 (CST) Received: from ericsson.com (pc050190.exu.ericsson.se [138.85.50.190]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id MAA14518; Sun, 3 Dec 2000 12:36:57 -0600 (CST) Message-ID: <3A2A2FD0.22BC22F0@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , "'Jo Hornsby'" , "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Subject: Re: [SIP] RECORD-ROUTE/ROUTE requirements References: <3A2A7F22.D223F928@cs.columbia.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 03 Dec 2000 12:34:41 +0100 Content-Transfer-Encoding: 7bit Just my two cents worth on the use of non-SIP URLs in the RR. (I think I was the only person arguing for this :) "Henning G. Schulzrinne" wrote: > Jonathan Rosenberg wrote: > > > > There was some debate about whether the RR URL could be a SIP URL. I think > > it should be - primarily because it simplifies operation, is backwards > > compatible, and guaranteed to interoperate. Since no other URL type is > > guaranteed to be supported, inserting anything but a SIP URL may result in > > an interop problem. In any case, the primary purpose of the URL in the RR > > (and indeed, the URL in Contact header in INVITE and 200 OK as well) is > > identifying a specific entity at a specific next hop server. Its purpose is > > therefore to represent an address more than a name, and a SIP URL is ideal > > here. > > To elaborate: all other URL types, say, H.323 or tel, are by definition > meant to route to any number of destinations. By definition, this > determination should be made when first routing the request. RR is meant > to make sure that requests get back to the same place, to update state, > for example. Thus, using non-SIP URLs directly contradicts this goal. It > is also far from clear why this is useful, given that all other URLs can > be translated into a unique token at the proxy that originally received > the non-SIP URL. Please correct me if I am wrong, but one of the goals of the RR was to carry state/context information in the RR itself(?) I have no problem with one component of the RR being a SIP URL which uniquely routes to the given proxy (in the appropriate direction). What I wanted was a way to preserve the Request-URI from the original request in the RR. As suggested, this can be saved in the proxy and referenced by a unique token. But I believe there was a desire for RR to work for "stateless" proxies as well. If this is not a requirement, then I'm happy with the solution as is. If this is a requirement, then we need a way to carry this state or Request-URI in the RR. On a slightly related note, can I assume that the SIP URL in the RR will be inserted as is in future requests, including any (possibly unknown) parameters? And how will maddr and transport be handled? thanks /sean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 13:55:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA25436 for ; Sun, 3 Dec 2000 13:55:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4836F4437B; Sun, 3 Dec 2000 12:55:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 3330844379 for ; Sun, 3 Dec 2000 12:54:31 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA03040; Sun, 3 Dec 2000 13:54:19 -0500 (EST) Message-ID: <3A2A96DB.33118AF8@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: Jonathan Rosenberg , "'Jo Hornsby'" , "Fairlie-Cuninghame, Robert" , sip@lists.bell-labs.com Subject: Re: [SIP] RECORD-ROUTE/ROUTE requirements References: <3A2A7F22.D223F928@cs.columbia.edu> <3A2A2FD0.22BC22F0@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 03 Dec 2000 13:54:19 -0500 Content-Transfer-Encoding: 7bit Sean Olson wrote: > > Please correct me if I am wrong, but one of the goals of the RR was > to carry state/context information in the RR itself(?) I have no problem > with one component of the RR being a SIP URL which uniquely routes to the > given proxy (in the appropriate direction). What I wanted was a way to preserve > the Request-URI from the original request in the RR. As suggested, this can > be saved in the proxy and referenced by a unique token. But I believe there > was a desire for RR to work for "stateless" proxies as well. If this is not > a requirement, then I'm happy with the solution as is. If this is a requirement, > then we need a way to carry this state or Request-URI in the RR. I think that the URL should be copied as-is, including all parameters, known or otherwise. I believe that's what the current draft says, at least implicitly. The only question is whether items marked as "not allowed" in a request-URI should still be copied. While I wouldn't call the protocol police on somebody who didn't "sanitize" the request URI, I don't think it would be a good idea to rely on that. The only two parameters not allowed in Request-URIs are method and headers. Since any Record-Route element is copied to Route, I'd assume that something like Record-Route: ;original-url="tel:12345" would be carried along. However, as, I believe, has been discussed previously, this will not be visible to the receiving party since the Route entry will have been stripped upstream. If you want to encapsulate state, you have to stick it into the request-URI, as in Record-Route: or use some other appropriate (State) mechanisms. To avoid escaping nightmares and since the user part is strictly a local matter, it may be simplest to just take the state tokens you need, put them in a base-64 encoded string and use that as the user part, as in YWxpY2U7dGVsPTEyMzQ1@proxy.com for alice;tel=12345 I'm not recommending this except as an implementation hack in case all else fails. At some point, I'd rather have people do this then increase the amount of base-protocol complexity and interoperability cases to be tested. > > On a slightly related note, can I assume that the SIP URL in the RR will be > inserted as is in future requests, including any (possibly unknown) parameters? > And how will maddr and transport be handled? > > thanks > /sean > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 14:17:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA02616 for ; Sun, 3 Dec 2000 14:17:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 66B8544379; Sun, 3 Dec 2000 13:17:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f118.law9.hotmail.com [64.4.9.118]) by lists.bell-labs.com (Postfix) with ESMTP id 9158444337 for ; Sun, 3 Dec 2000 11:46:45 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 3 Dec 2000 09:46:34 -0800 Received: from 63.36.207.135 by lw9fd.law9.hotmail.msn.com with HTTP; Sun, 03 Dec 2000 17:46:34 GMT X-Originating-IP: [63.36.207.135] From: "Gethin Liddell" To: jdrosen@dynamicsoft.com, brett@broadsoft.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] 3PCC and the re-invite response Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 03 Dec 2000 17:46:34.0582 (UTC) FILETIME=[FA614760:01C05D50] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 03 Dec 2000 17:46:34 -0000 > > On Fri, 01 Dec 2000, Brett Tate wrote: > > > > I actually think that the best solution for 3PCC is an > > amalgamation of > > > > the late ACK and re-invite proposals: > > > > > > > > A Controller B > > > > | INV held SDP | | time t = 0 > > > > |<------------------| | > > > > | | | > > > > | 200 SDP A1 | | > > > > |-----------------> | | > > > > | | | > > > > | ACK | | > > > > |<------------------| | > > > > | | | > > > > | | INV NO SDP | > > > > | |----------------->| (1) > > > > | | | > > > > | | 200 SDP B | > > > > | |<-----------------| > > > > | INV SDP B | | > > > > |<------------------| | > > > > | | | > > > > | 200 SDP A2 | | > > > > |-----------------> | | > > > > | | | > > > > | | ACK SDP A2 | > > > > | ACK |----------------->| (2) > > > > |<------------------| | > > > > | | | > > > > | | RTP | > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > | | | > > > > | | | > > > > | | | > > > > | | | > > > > | | | > > > > | | | > > > > | | | > > > > | | | > > > > > > > > my only query is who do we late ack at (1), agent A or agent B. > > > > > > It would be best to send it first to the party that the 3pcc > > > is controlling since it should definitely support it, and it > > > is the one trying to pull the other party off of hold. In the > > > above scenario, I am assuming that B put party A on > > > hold (the picture isn't complete). Thus the INVITE > > > without SDP should be sent to B first. > > > > the picture is actually the call flow that will occur at the > > initiation > > of a 3PCC session. so `b' has not put `a' on hold, the contoller has > > put `a' on hold whilst it tries to contact b'. once it has contacted > > `b', it is able to quickly bring `a' into the RTP session > > because there > > is no user intervention. > >Right. This actually seems like a reasonable compromise. There can still be >delays if the re-INVITE triggers some kind of UI interaction to approve it, >but that is less likely, and in any case, the user is already there, so the >response should come quickly. > > > > > if we were to initiate the late ACK scenario to 'a' at (1) then as > > Gonzalo pointed out, `a' may be waiting around a long time for an ACK > > to appear because we would have to wait for the user to answer the > > phone. > >This bit I just don't follow. Point (1) in the call flow above is not an >ACK, but an INVITE to B while A is on hold; there is no late ACK here at >all. sorry, i meant the late ack that is sent later for the invite. i have re-labelled the ack i was refering to as (2)and i'm refering to the scenario where all the arrows from point (1) are in the opposite direction (clear as mud?) _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 16:37:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13597 for ; Sun, 3 Dec 2000 16:37:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DE49044337; Sun, 3 Dec 2000 15:37:22 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 68A4144336 for ; Sun, 3 Dec 2000 15:36:29 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id QAA09919; Sun, 3 Dec 2000 16:36:19 -0500 (EST) Message-ID: <3A2ABCD3.9BC0540F@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: SIP List Subject: Re: [SIP] Re: My comments on bis-02 References: <20001030224808.B31229@div8.net> <3A1EE097.7ACDFF65@cs.columbia.edu> <20001127002952.D24967@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 03 Dec 2000 16:36:19 -0500 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > The text currently is: > > "If no protocol is specified, the client tries UDP (if UDP is > supported). If the attempt fails, or the client doesn't support UDP > but supports other protocols, it tries those protocols in some > unspecified order." > > This implies that clients do not need to support UDP. I thought UDP > was a requirement, but it looks like it's only a SHOULD for clients. > MUST is only used in the section on a minimal implementation. Removed qualifier. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 17:40:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA04416 for ; Sun, 3 Dec 2000 17:40:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C6F564437E; Sun, 3 Dec 2000 16:40:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id C4C1644336 for ; Sun, 3 Dec 2000 16:39:40 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA12185; Sun, 3 Dec 2000 17:39:30 -0500 (EST) Message-ID: <3A2ACBA2.A227BB12@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "=?iso-8859-1?Q?=27G=E9rard?= GONNET'" , "'sip@lists.bell-labs.com'" , "'lsteffan@atos-group.com'" , "'SEVESTRE Thibaut'" Subject: Re: [SIP] SIP syntax in 2543-bis-01 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 03 Dec 2000 17:39:30 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > >The syntax in the draft 2543bis-01, page 18, resulting from a > modification of the >former release, can produce some ambiguous > interpretation. > >This concern the element, described as : > >. > >(was described in the former release as , > notice that the > element is not optional). > > Hmm. Not sure why that happened; I can see no good reason for just having a > password. Henning? > Fixed by moving the bracket, in accordance with similar URLs in RFC 1738. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 19:48:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA09858 for ; Sun, 3 Dec 2000 19:48:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C3A54443A1; Sun, 3 Dec 2000 18:48:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lists.bell-labs.com (Postfix) with ESMTP id ACD7544336 for ; Sun, 3 Dec 2000 18:47:00 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate2.mot.com (motgate2 2.1) with ESMTP id RAA22198 for ; Sun, 3 Dec 2000 17:40:06 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id RAA23894 for ; Sun, 3 Dec 2000 17:40:06 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Sun, 3 Dec 2000 18:40:06 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8759@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Subject: [SIP] Allow header field Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Dec 2000 18:39:56 -0600 Bis section 4.2.1 says: "The initial INVITE from the UAC SHOULD contain the Allow and Supported header fields" According to section 6.10 and table 4 looks like this is a response header field? Sorry if someone has already asked this and I have missed it... Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 21:07:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA03274 for ; Sun, 3 Dec 2000 21:07:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CF84944337; Sun, 3 Dec 2000 20:07:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out2.bellatlantic.net (smtp-out2.bellatlantic.net [199.45.39.157]) by lists.bell-labs.com (Postfix) with ESMTP id 1452444336 for ; Sun, 3 Dec 2000 20:06:41 -0500 (EST) Received: from cs.columbia.edu (adsl-151-198-20-48.nnj.adsl.bellatlantic.net [151.198.20.48]) by smtp-out2.bellatlantic.net (8.9.1/8.9.1) with ESMTP id VAA25798; Sun, 3 Dec 2000 21:06:21 -0500 (EST) Message-ID: <3A2AFC36.482319ED@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] Allow header field References: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8759@il27exm02.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 03 Dec 2000 21:06:46 -0500 Content-Transfer-Encoding: 7bit Are you looking at bis-02? Allow R o o o o o o Supported g - o o o o o 6.10 Allow The Allow header field lists the set of methods Thus, I'm afraid I have no idea what your message might be referring to. Baniel Uri-CUB001 wrote: > > Bis section 4.2.1 says: > > "The initial INVITE from the UAC SHOULD contain the Allow and Supported > header fields" > > According to section 6.10 and table 4 looks like this is a response header > field? > > Sorry if someone has already asked this and I have missed it... > > Uri > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 22:32:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA21887 for ; Sun, 3 Dec 2000 22:32:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB86A44337; Sun, 3 Dec 2000 21:32:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 5EDAA44336 for ; Sun, 3 Dec 2000 21:31:31 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Sun, 3 Dec 2000 19:31:04 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'Jo Hornsby'" , sip@lists.bell-labs.com Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Dec 2000 19:31:01 -0800 Hi Jonathan, I think we all appreciate how busy you (and Henning) are. We are all very thankful that you are both so active on the list. > Regarding 2: > > This seems a very orthogonal issue. I don't really like it, > because I don't > think it will be needed in practice, and it makes assumptions about > processing at previous hops. Specifically, it assumes that > the non-existence > of the Contact header implies an older client, and it assumes that the > To/From field won't successfully get a call routed properly. > I can imagine a > SIP security proxy that removes all internal Via/Contact/RR > headers, and > inserts a single RR header pointing to itself. The next hop > proxy might then > insert a Contact header, making things very confusing. I would have thought that this is a good example FOR my suggestion. Only the first and last proxy will have to remember how to route the call (by storing state locally or adding an extra Record-Route). The two end proxies will be unaffected by any of this bbehaviour - they will be the only proxy using the information they add, - they will only remember routing information if they discover they will have not have route headers or Contacts later. - the extra Record-Route is taken directly from and to) the UA and _not_ interpolated end-to-end. Ie, the first proxy builds an extra Reocrd-Route directly from the initial From+source address that it sees, the last proxy would build a Record-Route from the forward request-URI+forward address that it used. In a security conscious environment, it is more likely that the something funky might be done to the From or request-uri from end to end. My suggestion does not make end-to-end assumptions but rather stores the information as seen by the affected proxy. As for not being able to route To/From URL's, I thought this was your suggestion for global tel URL's, that is, place global tel URL's in the domain namespace (since they are not really owned by anyone). Consider a routing proxy that contains the tel url routing information and another SIP gateway that just routes local numbers to the PSTN. So this could be the Record-Routed INVITE sent to the gateway (after the proxy does it's routing): INVITE sip:5551234@sandiego-pstn-gateway.company.com;user=phone SIP/2.0 To: +18585551234@comapny.com;user=phone From: +14083333333@company.com;user=phone Routing to the To/From URL's won't work in this case (as in many situations I contend). > > I also don't think it will be needed in practice, since making Contact > mandatory was one of the first things we added to bis. I > think that most UA > devices do insert Contact these days. In any case, I hate to > litter a spec > with hacks designed to support features that are only > potentially useful > during a transition period (which may already be over). > Currently, I beleive we have only made the Contact mandatory in the INVITE and OPTIONS 2xx response. In fact the Contact is disallowed in the 4xx,5xx,6xx response (except 485) [0], however I think it would be a good idea to allow Record-Routes in any non-3xx final responses. Eg 401. So we've got a couple of options: However, the UAS can't specify a - Record-Routes only allowed in 2xx responses and all Record-Routable methods MUST include a Contact in the request, or - if a UAS copies the Record-Route into a non-3xx final response, then it MUST also add a Contact. This really allows Contact in any final response. All Record-Routable methods MUST include a Contact in the request, or - Make it a MUST that the proxy is able to "remember" the routing action in the absense of a Contact (either by storing state or adding an extra Record-Route) so that any proxy can always handle a Record-Route without a Contact. - something else. By the way, the bis suggests that 484 Address Incomplete responses may use Record-Route. This doesn't make sense to me as there is no way that the UAC can convey the new request-URI to the UAS. Am I missing something? Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- [0] Section 6.14 [Contact] disagrees with Table 5. 6.14 says that Contact may carry error-informations. I believe this is now in Error-Info and should be removed from 6.14 - the Contact is already very overloaded. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 3 23:24:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27608 for ; Sun, 3 Dec 2000 23:24:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34B0F44343; Sun, 3 Dec 2000 22:24:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 72DC444336 for ; Sun, 3 Dec 2000 22:23:55 -0500 (EST) Received: from CINQUECENTO (c500355-b.plano1.tx.home.com [24.19.72.215]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id XAA01596; Sun, 3 Dec 2000 23:26:05 -0500 (EST) From: "Robert Sparks" To: "Jonathan Rosenberg" , "'Alexandre Charest'" , Subject: RE: [SIP] Multi-proxy authentication deadlock Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-reply-to: Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 3 Dec 2000 22:21:38 -0600 Content-Transfer-Encoding: 8bit I can't construct deadlock now either. I think the case being discussed that lead to the comment was: UA P1 P2 | req | | |---------->| | | 407 | | |<----------| | | | | |req(c1) | | |---------->|req | | |------------>| | |407 | |407 |<------------| |<----------| | | | | |req(c1,c2) | | |---------->| | |407 | | |<----------| | Where P1 rejected credentials c1 the second time around because it expired the challenge after receiving them the first time. This doesn't result in deadlock however, as the last 407 will either be reissuing the same challenge with a new nonce (stale=true), or a new challenge altogether, and when the corresponding credentials, c1', are provided, the flow will continue: |req(c1',c2)| | |---------->|req(c2) | | |------------>|req | | |-------> So, the statement could be removed, or changed to note that a proxy that expires a challenge after the first successful response increases the number of submissions it takes to get a request to its intended destination significiantly. The worst case is having all n proxies in the path of a request challenge and expire the challenge after the first successful response. That scenario requires submitting the request 2^n times to get it to its intended final destination. RjS > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > Sent: Wednesday, November 22, 2000 4:10 PM > To: 'Alexandre Charest'; sip@lists.bell-labs.com > Subject: RE: [SIP] Multi-proxy authentication deadlock > > > Hmm; I could not create the case either. The case that I thought > would cause > a deadlock does not, in fact. > > Robert? > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Alexandre Charest [mailto:acharest@mediatrix.com] > > Sent: Wednesday, November 22, 2000 8:21 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Multi-proxy authentication deadlock > > > > > > In (expired) ID draft-sparks-sip-multiproxy-auth-00: > > > > "A UAC should be prepared to terminate the deadlock situation > > caused by a > > proxy in the chain that expires a challenge after its first successful > > response." > > Can somebody give an example of call flow resulting in such a > > deadlock? I > > tried many scenarios and I can't figure out what is meant. > > Thanks. > > > > Alexandre Charest > > Software Designer > > Mediatrix Telecom Inc. (www.mediatrix.com) > > tél:(819) 829-8749 #275 > > fax: (819) 829-5100 > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 01:31:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23111 for ; Mon, 4 Dec 2000 01:31:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A4C4744337; Mon, 4 Dec 2000 00:31:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8ACAA44336 for ; Mon, 4 Dec 2000 00:30:17 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA01877; Mon, 4 Dec 2000 01:32:27 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 01:27:54 -0500 Message-ID: From: Jonathan Rosenberg To: "'Fairlie-Cuninghame, Robert'" , Jonathan Rosenberg , "'Jo Hornsby'" , sip@lists.bell-labs.com Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 01:27:46 -0500 > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Sunday, December 03, 2000 10:31 PM > To: 'Jonathan Rosenberg'; 'Jo Hornsby'; sip@lists.bell-labs.com > Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements > > > This seems a very orthogonal issue. I don't really like it, > > because I don't > > think it will be needed in practice, and it makes assumptions about > > processing at previous hops. Specifically, it assumes that > > the non-existence > > of the Contact header implies an older client, and it > assumes that the > > To/From field won't successfully get a call routed properly. > > I can imagine a > > SIP security proxy that removes all internal Via/Contact/RR > > headers, and > > inserts a single RR header pointing to itself. The next hop > > proxy might then > > insert a Contact header, making things very confusing. > > > I would have thought that this is a good example FOR my > suggestion. Only the > first and last proxy will have to remember how to route the > call (by storing > state locally or adding an extra Record-Route). The two end > proxies will be > unaffected by any of this bbehaviour > - they will be the only proxy using the information they add, > - they will only remember routing information if they > discover they will > have not have route headers or Contacts later. > - the extra Record-Route is taken directly from and to) the > UA and _not_ > interpolated end-to-end. Ie, the first proxy builds an extra > Reocrd-Route > directly from the initial From+source address that it sees, > the last proxy > would build a Record-Route from the forward > request-URI+forward address that > it used. I just can't follow what you are saying. My point is simple. You are making assumptions about the meaning of a missing Contact. I gave an example where the Contact was missing for a good reason. Insertion of it by another proxy may confuse the proxy that gets a record-route back in a response that does not have the form it expected (i.e., extra entry corresponding to the inserted Contact). > > I also don't think it will be needed in practice, since > making Contact > > mandatory was one of the first things we added to bis. I > > think that most UA > > devices do insert Contact these days. In any case, I hate to > > litter a spec > > with hacks designed to support features that are only > > potentially useful > > during a transition period (which may already be over). > > > Currently, I beleive we have only made the Contact mandatory > in the INVITE > and OPTIONS 2xx response. In fact the Contact is disallowed in the > 4xx,5xx,6xx response (except 485) [0], however I think it > would be a good > idea to allow Record-Routes in any non-3xx final responses. > Eg 401. So we've > got a couple of options: I don't see how your point addresses what I was saying. My point was that this whole discussion is likely moot, since it is my suspicion that Contact is inserted by most UAs already. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 02:02:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA07916 for ; Mon, 4 Dec 2000 02:02:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE8154433B; Mon, 4 Dec 2000 01:02:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 405F844337 for ; Mon, 4 Dec 2000 01:01:15 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 4 Dec 2000 01:00:51 -0600 (CST) From: Billy Biggs To: "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , Jo Hornsby , "Fairlie-Cuninghame, Robert" , SIP List Subject: Re: [SIP] RECORD-ROUTE/ROUTE requirements Message-ID: <20001204010051.A1389@div8.net> References: <3A2A7F22.D223F928@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A2A7F22.D223F928@cs.columbia.edu>; from hgs@cs.columbia.edu on Sun, Dec 03, 2000 at 12:13:06PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 01:00:51 -0600 Henning G. Schulzrinne (hgs@cs.columbia.edu): > Let's see if I got this right. Let's assume the following example: > > alice@from calls bob@yahoo, who is really bob@acme, which translates > to bob@sales.acme, which becomes bob@pc.sales.acme > > All entities (yahoo, acme, and sales.acme) RR. Thus, we have on the > forward direction when the request reaches bob, the 200 OK becomes: > > Contact: sip:bob@pc.sales.acme > Record-Route: sip:bob@sales.acme, > sip:bob@acme, > sip:bob@yahoo In my perfect SIP world, the 200 OK response is: Contact: sip:bob@pc.sales.acme Record-Route: sip:sales.acme, sip:acme, sip:yahoo Alice now sends subsequent requests as: Route: sip:yahoo, sip:acme, sip:sales.acme, sip:bob@pc.sales.acme Contact: alice@alices-contact And Bob's requests look like: Route: sip:sales.acme, sip:acme, sip:yahoo, sip:alice@alices-contact Contact: sip:bob@pc.sales.acme Proxies insert an address which represents that proxy, irrelevant of the original request-URI (most proxies won't need to remember it). All call state information is in the To/From/Call-ID (leg identification + request direction). Special state keys can also be placed in the username or as helpful parameters. Why should the spec specify any behavior besides placing an address which maps back to the correct proxy? I'm also not for anything stronger than MAY regarding changing the Record-Route in the response on the way back, specifically because I see proxies using an RR address of 'sip:proxy'. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 03:03:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03689 for ; Mon, 4 Dec 2000 03:03:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92BC044337; Mon, 4 Dec 2000 02:03:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id EB2D444336 for ; Mon, 4 Dec 2000 02:02:08 -0500 (EST) Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eB481x410111; Mon, 4 Dec 2000 09:01:59 +0100 (MET) Received: from lmf.ericsson.se (E005004B57CE1.lmf.ericsson.se [131.160.30.132]) by fogerty.lmf.ericsson.se (8.9.3+Sun/8.9.3) with ESMTP id KAA12910; Mon, 4 Dec 2000 10:01:58 +0200 (EET) Message-ID: <3A2B4F74.EBAD3EF2@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: Sip Mail List Subject: Re: [SIP] 3PCC and the re-invite response References: <00120111510301.22777@gethin> <3A279C26.FE53784A@lmf.ericsson.se> <00120113013502.22777@gethin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 04 Dec 2000 10:01:56 +0200 Content-Transfer-Encoding: 7bit Hello, I do not like to send the SDP in the ACK because the 200 OK gets retransmitted a number of times. However, as folk have pointed out, sometimes it does not take that long for the controller to receive the new SDP to be sent in the ACK. Thus, we could copy the delayed acknowledgments from TCP. The UAC can delay the ACK up to a certain amount of time (in TCP it is usually 200 ms). If when this timer expires the UAC cannot send the ACK with SDP it will send an ACK without SDP and re-INVITE when it is ready to send the new SDP. I think this would be an acceptable way of combining delayed ACKs with the re-INVITE method. However, in my opinion, applications would use the re-INVITE method most of the times. Regards, Gonzalo Gethin Liddell wrote: > > My appologies Gonzalo, i missed the point you were making. > > IMO, your point is valid and an issue for the original 3PCC draft. > > However, with the "re-invite & late ack" proposal, the 200 response of > the re-invite should come fairly quickly as there is no need to wait > for a user to answer a phone. > > Would this not be enough to avoid the re-transmission problem you > pointed out? > > On Fri, 01 Dec 2000, Gonzalo Camarillo wrote: > > Hello, > > > > Gethin Liddell wrote: > > > > > > On Fri, 01 Dec 2000, Gonzalo Camarillo wrote: > > > > Hello, > > > > > > > > The ACK is used to stop 200 OK retransmissions. Thus, if it takes some > > > > time for your UAC to get the SDP to be sent in the ACK, the 200 OK will > > > > be retransmitted a number of times although we have already received it. > > > > > > Keep in mind though that the late ACK scenario is only going to be used > > > in certain circumstances. During normal call setup, the standard > > > INVITE SDP, ACK no SDP will be used. When someone does something a bit > > > special, such as 3PCC, then people are more inclined to accept little > > > anomolies, such as no audio for the first second. > > > > I am not talking about service behavior (the user waiting for a couple > > of seconds). I am talking about a UAC retransmitting a 200 OK because an > > ACK has not been received. The UAC thinks that the 200 OK responses that > > it is sending are getting lost in the network but what it is really > > happening is that the UAC that should return an ACK is doing something > > in order to gather a proper SDP to piggyback it in the ACK. > > > > If we send the ACK as soon as the 200 OK arrives the UAS will stop > > retransmitting. Then, the UAC can take as long as it wants to gather the > > SDP and then re-INVITE. > > > > I would accept to send the SDP in the ACK if the UAC, upon reception of > > the 200 OK, it is ready to send the ACK with the SDP. In that case I do > > not have a problem with ACKs carrying SDPs. > > > > > > > > > > > > > I do not think it is a good idea to overload a method with two different > > > > functions: stop 200 OK retransmissions and send the SDP. > > > > > > why? it does not really add any major coding effort to a SIP UA. > > > > It is not about coding effort. It is about "streching" a retransmission > > timer because the SDP is not ready to be sent. > > > > > > > > We have to take into consideration that in 3PCC scenarios the controller > > > > will have to issue another request in order to obtain the SDP that had > > > > to be sent in the ACK. Since this takes time I do not find appropriate > > > > to mess with the retransmission timers for 200 responses. > > > > > > sorry, don't understand what you're getting at here. we are not messing > > > with any retranmssion timers. > > > > See my comments above. > > > > > > > > I actually think that the best solution for 3PCC is an amalgamation of > > > the late ACK and re-invite proposals: > > > > > > A Controller B > > > | INV held SDP | | > > > |<------------------| | > > > | | | > > > | 200 SDP A1 | | > > > |-----------------> | | > > > | | | > > > | ACK | | > > > |<------------------| | > > > | | | > > > | | INV NO SDP | > > > | |----------------->| (1) > > > | | | > > > | | 200 SDP B | > > > | |<-----------------| > > > > In this moment the UAS will begin retransmitting the 200 OK until the > > ACK arrives > > > > > | INV SDP B | | > > > |<------------------| | > > > | | | > > > | 200 SDP A2 | | > > > |-----------------> | | > > > | | | > > > | | ACK SDP A2 | > > > | ACK |----------------->| > > > > At this point the UAS will stop retransmitting the 200 OK... In the > > previous message exchange (INVITE SDP B and 200 SDP A2) takes long, the > > UAS will have to retransmit the 200 OK a number of times. > > > > Let's keep in mind that retransmissions are used to ensure reliable > > delivery of SIP messages. In this scenario the 200 OK was already > > delivered but the UAS had to keep on retransmitting... I do not like > > that... > > > > Regards, > > > > Gonzalo > > > > > > > > > |<------------------| | > > > | | | > > > | | RTP | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > | | | > > > | | | > > > | | | > > > | | | > > > | | | > > > | | | > > > | | | > > > | | | > > > > > > my only query is who do we late ack at (1), agent A or agent B. > > > > > > Only question is what will agent A do with a re-invite that has no SDP? > > > > > > -- > > > Gethin Liddell > > > Ubiquity Software Corporation > > > > > > http://www.ubiquity.net > > > mailto:gethin@ubiquity.net > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > -- > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > Telecom R&D Fax : +358 9 299 30 52 > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > Finland http://www.hut.fi/~gonzalo > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 03:19:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08835 for ; Mon, 4 Dec 2000 03:19:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C0D734433E; Mon, 4 Dec 2000 02:19:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 6607644336 for ; Mon, 4 Dec 2000 02:18:34 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 00:18:08 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'Jo Hornsby'" , sip@lists.bell-labs.com Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 00:18:04 -0800 > > I just can't follow what you are saying. > > My point is simple. You are making assumptions about the meaning of a > missing Contact. I gave an example where the Contact was > missing for a good > reason. Insertion of it by another proxy may confuse the > proxy that gets a > record-route back in a response that does not have the form > it expected > (i.e., extra entry corresponding to the inserted Contact). Hi Jonathan, Ok firstly, I am not advocating a proxy inserts a Contact. I agree this is a bad idea - that is not my suggestion. I was merely suggesting a method whereby the proxy can stateless remember where to send a request when there is no COntact when the proxy is the first or last proxy. If the proxy doesn't remember the state information: Then Contact field MUST always be present when Record-Route is used or you must be able to route to the To and From. I don't understand your position: on one hand it seems you are saying the Contact is mandatory and on the other hand you are saying you should be able to work without a Contact. So should a call succeed if the UA doesn't add a Contact or if a proxy strips it? Under what conditions? This assumes that the From URL (reverse direction) and To URL (forward direction) are directly routable ? I can live with the former assumption (From); the latter in my mind is unacceptable[To is routable by last proxy without causing loops]. I believe there may be advantages to allowing the forward direction to work without a Contact in the final response (see below). Options for storing the required information (statelessly): - Embed request-uri and source addresses to Record-Route. - Edge proxies add extra Record-Route with forwarding information (as previously suggested - no r-uri quoting needed). Ok, you don't like the latter suggestion so how about the former? To get around the complexity of quoting the r-uri, the proxy could code the r-uri to base64 as was suggested by Henning. Actually I think I like that idea better than my original R-R adding suggestion. > > Currently, I beleive we have only made the Contact mandatory > > in the INVITE > > and OPTIONS 2xx response. In fact the Contact is disallowed in the > > 4xx,5xx,6xx response (except 485) [0], however I think it > > would be a good > > idea to allow Record-Routes in any non-3xx final responses. > > Eg 401. So we've > > got a couple of options: > > I don't see how your point addresses what I was saying. > > My point was that this whole discussion is likely moot, since it is my > suspicion that Contact is inserted by most UAs already. My point is: Should Record-Routing be allowed for non-2xx response? (yes, I believe) However, Contacts are not allowed for 4xx,5xx,6xx responses so what are we going to do ? Simply mandating Contact's on error responses adds requirements to how the UA forms the Contact (to statelessly reproduce request-URI) and/or how a UA correlates failed requests with successful requests. Not a good idea in my mind. Why not three kill birds with one stone and make the Record-Route work flawlessly if the _response_ doesn't have a Contact and "best-effort" if the request doesn't have a Contact. So my suggestion is now: -If a proxy receives a response AND the first Record-Route header was generated by the proxy AND the reponse does not contain a Contact, then the proxy MUST be able to reproduce the forward routing action for subsequent forward requests. Eg, by either embedding information into the Record-Route URL or storing the information locally. [Base-64 encoding of r-uri recommended in R-R URL.] -If a proxy recieves a request without any Route headers AND the request is known to be a previously Record-Routed call-leg request travelling in the _reverse_ direction, then the proxy SHOULD forward the request to the From URL (unless more detailed information is known). -If a proxy embeds forwarding information into a Record-Route URL (eg, due to the absence of a Contact in the response) then the MUST the proxy must be able to determine the direction of a received call-leg request from the Record-Route URL (so requests aren't forwarded in the wrong direction). [Proxy can simply & statelessly achieve this by always embedding directional and request-uri information in the Record-Route header of requests (response can then be left untouched).] As you say, the point becomes moot if you decide that Contacts are 100% mandatory in all final responses but I think that deserves some thought first. Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 03:27:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA11378 for ; Mon, 4 Dec 2000 03:27:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 948B544348; Mon, 4 Dec 2000 02:27:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from blr.vsnl.net.in (blr.vsnl.net.in [202.54.12.6]) by lists.bell-labs.com (Postfix) with ESMTP id 49CCF44346 for ; Mon, 4 Dec 2000 02:26:15 -0500 (EST) Received: from cipl1 (PPP-177-211.bng.vsnl.net.in [203.197.177.211]) by blr.vsnl.net.in (Postfix) with ESMTP id 11CC55E326 for ; Mon, 4 Dec 2000 13:48:44 +0530 (IST) Received: from 192.9.200.5 by cipl1 ([192.9.200.139] running VPOP3) with SMTP for ; Mon, 4 Dec 2000 12:59:12 +0530 Received: from vijeth ([192.9.200.102]) by icosys.cosystems.com (5.x/SMI-SVR4)id AA23679; Mon, 4 Dec 2000 12:56:25 +0530 Message-Id: <000e01c05dc3$586083e0$66c809c0@vijeth> From: vijeth@cosystems.com To: References: 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 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 X-Server: VPOP3 V1.3.0b - Registered to: CoSystems, Inc Subject: [SIP] Ports a UAS should listen to Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 12:55:14 +0530 Content-Transfer-Encoding: 7bit Hi, If a user agent A knows the IP addr of user agent B, he can directly send the INVITE request to B bypassing SIP proxies. Now this requires the UA B to be polling on some port to listen to such requests. Is there any standard port for this like 5060 or should it be previously known be A via e-mail or other means. regards, Vijeth _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 03:59:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA21684 for ; Mon, 4 Dec 2000 03:59:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 41BE744337; Mon, 4 Dec 2000 02:59:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id EA58244336 for ; Mon, 4 Dec 2000 02:58:30 -0500 (EST) Received: from hsssun01.hss.hns.com (hsssun01 [139.85.229.20]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eB48xmH03431; Mon, 4 Dec 2000 14:29:48 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eB4975k02773; Mon, 4 Dec 2000 14:37:10 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652569AB.0031811C ; Mon, 4 Dec 2000 14:30:43 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: vijeth@cosystems.com Cc: sip@lists.bell-labs.com Message-ID: <652569AB.00317F35.00@sampark.hss.hns.com> Subject: Re: [SIP] Ports a UAS should listen to Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 14:30:37 +0530 http://www.cs.columbia.edu/sip/assignments.html Port number for TCP and UDP 5060 Port number for TLS-over-TCP 5061 Multicast address for REGISTER sip.mcast.net (224.0.1.75) Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems vijeth@cosystems.com on 12/04/2000 12:55:14 PM To: sip@lists.bell-labs.com cc: Subject: [SIP] Ports a UAS should listen to Hi, If a user agent A knows the IP addr of user agent B, he can directly send the INVITE request to B bypassing SIP proxies. Now this requires the UA B to be polling on some port to listen to such requests. Is there any standard port for this like 5060 or should it be previously known be A via e-mail or other means. regards, Vijeth _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 04:42:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA07189 for ; Mon, 4 Dec 2000 04:42:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 72C9F44342; Mon, 4 Dec 2000 03:42:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from blr.vsnl.net.in (blr.vsnl.net.in [202.54.12.6]) by lists.bell-labs.com (Postfix) with ESMTP id 5C43E44341 for ; Mon, 4 Dec 2000 03:41:00 -0500 (EST) Received: from cipl1 (PPP-177-211.bng.vsnl.net.in [203.197.177.211]) by blr.vsnl.net.in (Postfix) with ESMTP id 0BA0A5E401 for ; Mon, 4 Dec 2000 15:05:11 +0530 (IST) Received: from 192.9.200.5 by cipl1 ([192.9.200.139] running VPOP3) with SMTP for ; Mon, 4 Dec 2000 14:13:41 +0530 Received: from vijeth ([192.9.200.102]) by icosys.cosystems.com (5.x/SMI-SVR4)id AA24737; Mon, 4 Dec 2000 14:10:55 +0530 Message-Id: <003d01c05dcd$c0607680$66c809c0@vijeth> From: vijeth@cosystems.com To: Mime-Version: 1.0 Content-Type: multipart/alternative;boundary="----=_NextPart_000_003A_01C05DFB.D9E657E0" X-Priority: 3 X-Msmail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2615.200 X-Mimeole: Produced By Microsoft MimeOLE V5.00.2615.200 X-Server: VPOP3 V1.3.0b - Registered to: CoSystems, Inc Subject: [SIP] Locating Sip server Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 14:09:43 +0530 This is a multi-part message in MIME format. ------=_NextPart_000_003A_01C05DFB.D9E657E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, This is with reference to the sec 1.4.2 of the sip rfc ( modified = ). There are two ways that a UA can reach a sip server. One way is to = do =3D a DNS query. The other way is to use the server address in the Request = =3D URI.=3D20 My understanding is that in the latter case one would have aquired a = =3D login and passwd=3D20 ( probably through e-mail )from the sip server before putting the = server =3D address in the Request URI. But in the case where the client has to do a query , what does the =3D client do after it gets the address of the sip server? Without a = logging =3D in to the server can the client send register messages? =20 regards, vijeth ------=_NextPart_000_003A_01C05DFB.D9E657E0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
     This is = with=20 reference to the sec 1.4.2 of the sip rfc ( modified = ).
   =20 There are two ways that a UA can reach a sip server. One way is to do=20 =3D
 a DNS query. The other way is to use the server address in = the=20 Request =3D
 URI.=3D20
 My understanding is that in the = latter case=20 one would have aquired a =3D
 login and passwd=3D20
 ( = probably=20 through e-mail )from the sip server before putting the server = =3D
 address=20 in the Request URI.
But in the case where the client has to do a = query , what=20 does the =3D
 client do after it gets the address of the sip = server?=20 Without a logging =3D
 in to the server can the client send = register=20 messages?
 
regards,
  =20 vijeth
------=_NextPart_000_003A_01C05DFB.D9E657E0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 10:57:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29740 for ; Mon, 4 Dec 2000 10:57:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5BF0E44339; Mon, 4 Dec 2000 09:57:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id BDF1544336 for ; Mon, 4 Dec 2000 09:56:15 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 63F314CE05 for ; Mon, 4 Dec 2000 10:56:07 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id KAA18228 for ; Mon, 4 Dec 2000 10:56:06 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id KAA93816 for sip@lists.bell-labs.com; Mon, 4 Dec 2000 10:55:49 -0500 (EST) Message-Id: <200012041555.KAA93816@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: Re: [SIP] Manyfolks draft question Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 10:55:49 -0500 (EST) Ameet, The first round-trip negotiates the level of QoS to be established for the session. The UAC proposes something with the a=qos lines in the SDP, and the UAS responds with its capabilities. The UAS may reduce the preconditions requested by the UAC. Section 4.2 of the I-D gives details of the allowed couplings between UAS and UAC in Tables 1 and 2. In the particular case you are asking, the UAS receiving the INVITE without the ability to do QoS would respond without a "a=qos" line in the SDP, effectively meaning "none". Then there is no COMET in either direction, and the session proceeds as Best Effort. Bill Marshall wtm@research.att.com -----original message----- From: Ameet Kher To: sip@lists.bell-labs.com Subject: [SIP] Manyfolks draft question Date: Tue, 28 Nov 2000 12:11:28 -0500 Hi All, Need a clarification on the latest version of Manyfolks draft. What should happen if the UAS receiving an Invite with confirm tag does not have the ability to do QoS. Should a Comet be sent out by the UAS in this case ? The call has proceeded as Best effort and the 183 sent out by the UAS had no "a" line in its SDP body. Thanks Ameet _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 11:07:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03428 for ; Mon, 4 Dec 2000 11:07:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C8F744341; Mon, 4 Dec 2000 10:07:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by lists.bell-labs.com (Postfix) with ESMTP id C4B9C44336 for ; Mon, 4 Dec 2000 10:06:42 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 1F7574CE0F; Mon, 4 Dec 2000 11:06:33 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA18625; Mon, 4 Dec 2000 11:06:32 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id LAA68824; Mon, 4 Dec 2000 11:06:32 -0500 (EST) Message-Id: <200012041606.LAA68824@fish-ha.research.att.com> Subject: Re: [SIP] Possible REFER problem? To: Billy_Biggs@3com.com Cc: sip@lists.bell-labs.com Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 11:06:32 -0500 (EST) in some nasty cases the UAC/UAS may supply an invalid Contact: header in order to confuse/corrupt the 3-way call. You might want to consider using the Remote-Party-ID value instead, as it is verified by the provider of the service and contains an authenticated identity of the remote endpoint. See draft-ietf-sip-privacy-00. If there is no intervening service provider, or no Remote-Party-ID header, Contact is probably the best that can be done. Bill Marshall wtm@research.att.com -----original message----- Billy Biggs wrote: Our situation is as follows: A / \ B C A is in a 3-way call with B and C and wishes to be excused. If C called A, then A has no 'well-known URI' for C. The best address is the Contact. The From is not useful because it may be an unknown URI scheme, or C might be a 3pcc server, or the URI may be stale (or fork)... In our implementation, we use the Contact exclusively. I expect other implementations will also generalize transfer with consultation by instead implementing call handoff, and act similarily. If we REFER B to C and it fails, maybe we'll instead REFER C to B. If some server really needs to be in the signalling path, it should do 3pcc, or mangle the Contact, or act as a transparent SIP proxy... Jonathan discussed why using the Contact is dangerous: > The answer is that URIs most definitely have a context; a place from > which they can be usefully used. In a perfect world with no NATs, > firewalls, or devices that want to know whats going on within the > network, it would work dandy. But thats not reality. The classic > example is an ACD application, where help@helpdesk.com can be routed > to a variety of agents (agent32@host32.helpdesk.com). Sophisticated > software tracks the call status of the various agents, how much volume > they get, etc. Incoming calls MUST come in through this helpdesk proxy > to work. The proxy always record routes. In fact, to enforce this, > the proxy has access to a hosts file with the host32.helpdesk.com > address mapped to an IP address. Outside of this proxy, that hostname > is unroutable. So, if A called B, and then A called C, and C was one > of these operators, the URI returned by C > (agent32@host32.helpdesk.com) will definitely not be useful for B to > use directly. With an ACD application, in order to enforce all calls through the server, the server must perform 3pcc and only SIPly expose itself, or have all of the clients collude with the server and redirect all incoming direct-dialed calls. I don't think a Record-Route'ing proxy with some unroutable client addresses is clean, and I think it is reasonable to have attended transfer fail in these scenarios. If the Contact address is not generally routable (firewalls and NATs), then it should be mangled if the user wishes attended transfer to work, or have calls go through some helper 3pcc box. I see this as the only reasonable solution. > Perhaps these cases are so extreme its not worth worrying about. I > wouldn't be surprised if they don't work in the PSTN either. The PSTN has no concept of a REFER, which is where all this breaks down. Again, the 3-way call: A / \ B C A cannot excuse itself from the call in the PSTN. It can only keep the bridge active. This is acceptable because A is a PBX or similar server. There is no concept of signalling a transfer over the PSTN where the transferred party makes a new call. > So, despite its complexity, I feel compelled to recommend that > Robert's hybrid approach be described in the REFER specification as > the preferred way to do transfer out of consultation, along with a > nice long explanation of why it needs to be so. I'm not sure about the > order though. I suspect that (2) will work in far more cases than (1) > will. I welcome better ideas if anyone has any... It might be better to remove transfer out of consultation from the REFER draft, and maybe do a new draft on attended transfer, discussing these options and also introducing the replaces header from draft-biggs-sip-replaces-00. I really want to be able to have A silently excuse itself from the conference. This will help with many services, including moving transparently to a conference bridge, call park with server, ... -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 11:24:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08366 for ; Mon, 4 Dec 2000 11:24:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4020244340; Mon, 4 Dec 2000 10:24:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp01.wcom.com (pmesmtp01.wcom.com [199.249.20.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0AA6144339 for ; Mon, 4 Dec 2000 10:23:09 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42256) id <0G5100401XDDBP@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 4 Dec 2000 16:20:01 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42256) with ESMTP id <0G51002DCXDCLF@firewall.mcit.com>; Mon, 04 Dec 2000 16:20:00 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0G5100L01X6VOU@pmismtp03.wcomnet.com>; Mon, 04 Dec 2000 16:16:07 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5100L01X69JE@pmismtp03.wcomnet.com>; Mon, 04 Dec 2000 16:16:06 +0000 (GMT) Received: from wcom.com ([166.44.60.182]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5100K9QX627M@pmismtp03.wcomnet.com>; Mon, 04 Dec 2000 16:15:42 +0000 (GMT) From: Alan Johnston Subject: Re: [SIP] Attended Transfer CallFlow:draft-ietf-sip-service-examples-00.txt To: Billy Biggs Cc: Henry Chen , sip@lists.bell-labs.com, stlevy@cisco.com Message-id: <3A2BC3E8.E31849F3@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <3A27EC37.8465F804@cisco.com> <20001201124935.A32143@div8.net> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 04 Dec 2000 10:18:48 -0600 Content-Transfer-Encoding: 7bit See my comments below. Alan Johnston Billy Biggs wrote: > Henry Chen (hjlechen@cisco.com): > > > In the call flow of Attended Transfer in > > draft-ietf-sip-service-examples-00.txt, INVITE (F9) and INVITE (F16) > > have same Call-ID header and same To header, but the From headers are > > different. > I have corrected the error in reusing the Call-ID. > > > > I need to confirm that: > > - Is INVITE (F16) a legal Re-Invite and Shall User C accept it? > > - If it is legal, what should User C do? > > Ring (as a new call) or just establishes a new media stream and > > change the display of calling party (as a same call)? > This flow shows that B and C exchange media ("talk") prior to the REFER being sent by B to A. The INVITE (F16) is answered immediately since C is expecting the call. (Since the corrected flow has a different Call-ID, this is not a reINVITE but a new INVITE.) The two media streams (B to C and A to C) are separate. > > This call flow has two glaring errors: > > 1. The UA made two calls with the same Call-ID, but did not add a From > tag. > > 2. The UA which received the REFER made a new call using the same > Call-ID as the call leg the REFER was received on. Ouch. > The reuse of the Call-ID has been fixed - I'll scan the rest of the flows for this type of error. > > It is now generally accepted that the call-id should not be used to > infer that an incoming call should replace or have any association with > an ongoing call. Doing so leads to problems in some forking situations, > and is a general overloading of the meaning. > > For a cleaner method of signalling attended transfer where you don't > want the target's phone to ring, please see (and comment on) our > replaces draft (draft-biggs-sip-replaces-00.txt): > > http://www.sip-happens.com/replaces/ > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 11:44:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16603 for ; Mon, 4 Dec 2000 11:44:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BA39144339; Mon, 4 Dec 2000 10:44:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 6209544336 for ; Mon, 4 Dec 2000 10:43:48 -0500 (EST) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id IAA29732; Mon, 4 Dec 2000 08:43:39 -0800 (PST) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ABL01232; Mon, 4 Dec 2000 10:43:36 -0600 (CST) Message-ID: <3A2BC9F0.C0737422@cisco.com> From: Henry Chen X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Alan Johnston Cc: Billy Biggs , sip@lists.bell-labs.com, stlevy@cisco.com Subject: Re: [SIP] Attended TransferCallFlow:draft-ietf-sip-service-examples-00.txt References: <3A27EC37.8465F804@cisco.com> <20001201124935.A32143@div8.net> <3A2BC3E8.E31849F3@wcom.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 04 Dec 2000 10:44:32 -0600 Content-Transfer-Encoding: 7bit Alan Johnston wrote: > See my comments below. > > Alan Johnston > > Billy Biggs wrote: > > > Henry Chen (hjlechen@cisco.com): > > > > > In the call flow of Attended Transfer in > > > draft-ietf-sip-service-examples-00.txt, INVITE (F9) and INVITE (F16) > > > have same Call-ID header and same To header, but the From headers are > > > different. > > > > I have corrected the error in reusing the Call-ID. > > > > > > > I need to confirm that: > > > - Is INVITE (F16) a legal Re-Invite and Shall User C accept it? > > > - If it is legal, what should User C do? > > > Ring (as a new call) or just establishes a new media stream and > > > change the display of calling party (as a same call)? > > > > This flow shows that B and C exchange media ("talk") prior to the REFER > being sent by B to A. The INVITE (F16) is answered immediately since C is > expecting the call. (Since the corrected flow has a different Call-ID, this > is not a reINVITE but a new INVITE.) The two media streams (B to C and A to > C) are separate. > If INVITE (F16) is a new call, C will get ring again during the transfer. I think that the same Call-ID in F16 is legal (a new call leg) and provides a way for C to establish a media stream for a new call leg (A-C) in the same call without additional ring. The media stream from the call leg B-C will be dropped by the BYE (F22). So the same Call-ID in F16 is better. Thanks, Henry > > > > > This call flow has two glaring errors: > > > > 1. The UA made two calls with the same Call-ID, but did not add a From > > tag. > > > > 2. The UA which received the REFER made a new call using the same > > Call-ID as the call leg the REFER was received on. Ouch. > > > > The reuse of the Call-ID has been fixed - I'll scan the rest of the flows > for this type of error. > > > > > It is now generally accepted that the call-id should not be used to > > infer that an incoming call should replace or have any association with > > an ongoing call. Doing so leads to problems in some forking situations, > > and is a general overloading of the meaning. > > > > For a cleaner method of signalling attended transfer where you don't > > want the target's phone to ring, please see (and comment on) our > > replaces draft (draft-biggs-sip-replaces-00.txt): > > > > http://www.sip-happens.com/replaces/ > > > > -- > > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 12:05:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24954 for ; Mon, 4 Dec 2000 12:05:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 22F084434D; Mon, 4 Dec 2000 11:05:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 8854A4433D for ; Mon, 4 Dec 2000 11:04:05 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 4 Dec 2000 11:03:51 -0600 (CST) From: Billy Biggs To: Henry Chen Cc: Alan Johnston , SIP List , stlevy@cisco.com Subject: Re: [SIP] Attended TransferCallFlow:draft-ietf-sip-service-examples-00.txt Message-ID: <20001204110350.A2156@div8.net> References: <3A27EC37.8465F804@cisco.com> <20001201124935.A32143@div8.net> <3A2BC3E8.E31849F3@wcom.com> <3A2BC9F0.C0737422@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A2BC9F0.C0737422@cisco.com>; from hjlechen@cisco.com on Mon, Dec 04, 2000 at 10:44:32AM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 11:03:51 -0600 Henry Chen (hjlechen@cisco.com): > If INVITE (F16) is a new call, C will get ring again during the > transfer. Yes. Please see our replaces draft for one solution to this problem. Overloading the call-id is not a good idea. > I think that the same Call-ID in F16 is legal (a new call leg) and > provides a way for C to establish a media stream for a new call leg > (A-C) in the same call without additional ring. The media stream from > the call leg B-C will be dropped by the BYE (F22). So the same > Call-ID in F16 is better. I mentioned the problems with this before: >>> It is now generally accepted that the call-id should not be used >>> to infer that an incoming call should replace or have any >>> association with an ongoing call. Doing so leads to problems in >>> some forking situations, and is a general overloading of the >>> meaning. >>> >>> For a cleaner method of signalling attended transfer where you >>> don't want the target's phone to ring, please see (and comment on) >>> our replaces draft (draft-biggs-sip-replaces-00.txt): >>> >>> http://www.sip-happens.com/replaces/ -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 12:58:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA13237 for ; Mon, 4 Dec 2000 12:58:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3288B44338; Mon, 4 Dec 2000 11:58:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id DF9E244336 for ; Mon, 4 Dec 2000 11:57:19 -0500 (EST) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA05649; Mon, 4 Dec 2000 09:57:11 -0800 (PST) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ABL01922; Mon, 4 Dec 2000 11:57:08 -0600 (CST) Message-ID: <3A2BDB2B.BA8C916F@cisco.com> From: Henry Chen X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Alan Johnston , SIP List , stlevy@cisco.com Subject: Re: [SIP] Attended TransferCallFlow:draft-ietf-sip-service-examples-00.txt References: <3A27EC37.8465F804@cisco.com> <20001201124935.A32143@div8.net> <3A2BC3E8.E31849F3@wcom.com> <3A2BC9F0.C0737422@cisco.com> <20001204110350.A2156@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 04 Dec 2000 11:58:04 -0600 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > Henry Chen (hjlechen@cisco.com): > > > If INVITE (F16) is a new call, C will get ring again during the > > transfer. > > Yes. Please see our replaces draft for one solution to this problem. > Overloading the call-id is not a good idea. Is this a perfect case for same call with different call legs and is acceptable? > > > > I think that the same Call-ID in F16 is legal (a new call leg) and > > provides a way for C to establish a media stream for a new call leg > > (A-C) in the same call without additional ring. The media stream from > > the call leg B-C will be dropped by the BYE (F22). So the same > > Call-ID in F16 is better. > > I mentioned the problems with this before: > > >>> It is now generally accepted that the call-id should not be used > >>> to infer that an incoming call should replace or have any > >>> association with an ongoing call. Doing so leads to problems in > >>> some forking situations, and is a general overloading of the > >>> meaning. Could you give a call scenario for the forking situation which leads to problems? Thanks, Henry > > >>> > >>> For a cleaner method of signalling attended transfer where you > >>> don't want the target's phone to ring, please see (and comment on) > >>> our replaces draft (draft-biggs-sip-replaces-00.txt): > >>> > >>> http://www.sip-happens.com/replaces/ > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 13:14:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17357 for ; Mon, 4 Dec 2000 13:14:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F1DC544342; Mon, 4 Dec 2000 12:14:10 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id B566844342 for ; Mon, 4 Dec 2000 12:13:02 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Mon Dec 4 13:10:56 EST 2000 Received: by lists.bell-labs.com (Postfix) id 149D344380; Mon, 4 Dec 2000 12:58:39 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from co7040exch001p.wins.lucent.com (co7040exch001p.milehi.lucent.com [135.39.1.40]) by lists.bell-labs.com (Postfix) with ESMTP id C7BC94437D for ; Mon, 4 Dec 2000 12:58:38 -0500 (EST) Received: by co7040exch001p.milehi.lucent.com with Internet Mail Service (5.5.2650.21) id ; Mon, 4 Dec 2000 10:58:38 -0700 Message-ID: <0096D8500C92D211BAEB0008C7F4906C0305AD2E@co7040exch002u.milehi.lucent.com> From: "Lewis, Royce C (Royce)" To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [SIP] Bell Labs/Lucent reps please conctat me Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 10:58:27 -0700 Will the Bell Labs/Lucent reps to the SIP bake-offs, committees, and activities please contact me? ------------------------------------------------------------- <<...OLE_Obj...>> Royce C. Lewis Sr. Systems Engineer Lucent Technologies, Inc. 8742 Lucent Blvd. Highlands Ranch, CO 80129 Work - 720.482.4505 Wireless - 303.888.6457 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 13:57:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28339 for ; Mon, 4 Dec 2000 13:57:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 147B144345; Mon, 4 Dec 2000 12:57:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id 8F23E44336 for ; Mon, 4 Dec 2000 12:56:18 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G5200C014JMK5@firewall.mcit.com> for sip@lists.bell-labs.com; Mon, 4 Dec 2000 18:54:58 +0000 (GMT) Received: from pmismtp01.wcomnet.com ([166.38.62.36]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G5200B974JM7O@firewall.mcit.com>; Mon, 04 Dec 2000 18:54:58 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) id <0G5200M014JMNX@pmismtp01.wcomnet.com>; Mon, 04 Dec 2000 18:54:58 +0000 (GMT) Received: from pmismtp01.wcomnet.com by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5200M014JCKA@pmismtp01.wcomnet.com>; Mon, 04 Dec 2000 18:54:58 +0000 (GMT) Received: from wcom.com ([166.46.17.125]) by pmismtp01.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G5200JHE4J8L2@pmismtp01.wcomnet.com>; Mon, 04 Dec 2000 18:54:46 +0000 (GMT) From: Alan Johnston Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 To: Billy Biggs Cc: Robert Sparks , Jonathan Rosenberg , SIP List Message-id: <3A2BE821.733CDFD5@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: <20001130100343.A30059@div8.net> <20001130104711.A30137@div8.net> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 04 Dec 2000 12:53:22 -0600 Content-Transfer-Encoding: 7bit I'm still trying to understand the implementation issues here. See my comments below. Alan Johnston Billy Biggs wrote: > Robert Sparks (rsparks@dynamicsoft.com): > > >>>> So far, the only service I've halted seems to be Music-On-Hold, > >>>> which requires that the far end have some crazy logic to send a BYE > >>>> based on a REFER anyways. I'm sure there will be other services > >>>> that this device won't be able to handle, but I'm not worried yet. > >>> > >>> What crazy logic? Building the request based on the method parameter > >>> and possibly header parameter in the URL? > >> > >> I assume you want the BYE to be associated with the music call. > >> Otherwise, that BYE would be sent with a new From tag and no To tag > >> (a new call leg), and would not end the old call. > > > > Hence To: and From: headers in the URL. > > How can the referrer know what tag the far-end UA used? As well, > using the supplied to/from is another security no-no. I don't understand this. If I send you a REFER to a URL which you complete, then I send a REFER with the same URL but with method=BYE, then I am requesting that you disconnect whatever session(s) you established as a result of my original REFER. If your referred INVITE was somehow forked (stereo Music On Hold?) and resulted in two sessions, then the BYE would refer to both sessions. Tags don't come into the picture. Kind of like tags and CANCEL requests - when I send a CANCEL, it means cancel all pending requests - I don't need to know the tags. > REFER should not be a control protocol. It does not supply enough > information to properly orchestrate these operations. If you need this > sort of functionality, let's keep it seperate, like PHONECTL. > You seem to be treating REFER like an automatic redirection response, which it is not. Your phone should never automatically process a REFER request without confirmation from the user. Even your web browser alerts you if you get a HTTP redirect. The user will know if a REFER is imminent when the other party on the call says something like "I'm going to try to transfer you" or "I'm putting you on hold, you can have music if you want". If a REFER arrives out of the blue, the one party says to the other "What's up - are you trying to transfer me?" before they confirm their acceptance. > > >> Aside from that matching, there are also security implications of > >> being able to tell a UA to send any SIP request, especially a BYE. I > >> don't want a remote UA to tell me to hang up a call. So if some > >> service requires this, then we have to do some logic to see if the > >> user previously asked us to make a call such that we would allow them > >> to send a BYE for it. Ugh. > > > > So your UA has a policy to always 503 sip: BYE URLs. > > Right now we treat everything as an INVITE, but the plan would be to > send a 403. > > >> So, our security is simple: > >> > >> - Remote UA must have a call active to us (no out-of-call REFERs). > >> - We will only allow REFERs which ask us to INVITE. > >> - We will only allow being REFERed once (REFER is at the cost of > >> the old session). > >> > >> More priviledges are available through something stronger > >> (PHONECTL), which requires authentication. > > > > You could require that your REFERs be SIP authenticated. > > Which would be the same as PHONECTL. The remote UA needs to know the > phone's password to to do remote phone control operations. > > It doesn't seem reasonable for me to tell my phone's password to > everyone who wants to play me music-on-hold. It's not reasonable, since REFER is a request, not a command. The user can reject the REFER and just get silence instead. Or, the user can accept the request and get the music. If the music is not to the user's taste, they can disconnect. This call flow gives the user the choice of music or not. > > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 15:17:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19146 for ; Mon, 4 Dec 2000 15:17:17 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DFA3B4433F; Mon, 4 Dec 2000 14:17:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id C373044336 for ; Mon, 4 Dec 2000 14:16:31 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 4 Dec 2000 14:16:22 -0600 (CST) From: Billy Biggs To: Alan Johnston Cc: Robert Sparks , Jonathan Rosenberg , SIP List Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 Message-ID: <20001204141622.A2342@div8.net> References: <20001130100343.A30059@div8.net> <20001130104711.A30137@div8.net> <3A2BE821.733CDFD5@wcom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A2BE821.733CDFD5@wcom.com>; from alan.johnston@wcom.com on Mon, Dec 04, 2000 at 12:53:22PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 14:16:22 -0600 I'm really glad you've made these comments. They help to raise awareness of these issues. Alan Johnston (alan.johnston@wcom.com): > I don't understand this. If I send you a REFER to a URL which you > complete, then I send a REFER with the same URL but with method=BYE, > then I am requesting that you disconnect whatever session(s) you > established as a result of my original REFER. You're saying that the device has to match the BYE with the old call. This is definitely special (and difficult) logic for handling of a method=BYE REFER. > If your referred INVITE was somehow forked (stereo Music On Hold?) and > resulted in two sessions, then the BYE would refer to both sessions. > Tags don't come into the picture. Kind of like tags and CANCEL > requests - when I send a CANCEL, it means cancel all pending requests > - I don't need to know the tags. REFER Refer-To: farend@host.com spawns -> INVITE farend@host.com To: farend@host.com From: me@localhost;tag=54321 Call-ID: 12345@host.com Then later I get: REFER Refer-To: farend@host.com;method=BYE spawns -> BYE farend@host.com To: farend@host.com From: farend@host.com;tag=73625 Call-ID: 83738@host.com This BYE has a new from tag and a new call-id, so it gets ignored by the far end. In order to ensure we match, the REFERs MUST include both the Call-ID and From (with a tag). Ouch. My implementation does not want to trust either of those to a remote UA, especially not the From. > You seem to be treating REFER like an automatic redirection response, > which it is not. Is for me. How else can you coordinate a smooth (instant) handoff of a 3-way call (hangup and the two remote parties are connected), or build a SIP-POTS line converter, or otherwise build a phone without the luxury of a 19" monitor? I suspect that other implementations will be similar. > Your phone should never automatically process a REFER request without > confirmation from the user. Even your web browser alerts you if you > get a HTTP redirect. What crazy web browser do you use? -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 15:45:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24450 for ; Mon, 4 Dec 2000 15:45:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A780A4433C; Mon, 4 Dec 2000 14:45:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 5D3AF44336 for ; Mon, 4 Dec 2000 14:44:02 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id MAA20968; Mon, 4 Dec 2000 12:43:53 -0800 (PST) Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126]) by imop.cisco.com (Mirapoint) with SMTP id AAC12805; Mon, 4 Dec 2000 12:43:42 -0800 (PST) Message-Id: <4.1.20001204121608.00928f00@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Billy Biggs , Jonathan Rosenberg From: Rohan Mahy Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 Cc: Alan Johnston , Robert Sparks , SIP List In-Reply-To: <20001130001436.A29311@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 04 Dec 2000 12:28:52 -0800 At 10:14 PM 11/29/00 , Billy Biggs wrote: >Jonathan Rosenberg (jdrosen@dynamicsoft.com): > >>> The REFER transaction itself does not affect the old session. >>> However, to keep our phone UI simple, we disconnect the old call. >>> Users can't understand it otherwise. >> >> You are most definitely confusing a primitive operation (REFER), with >> a specific service, which is transfer. > > Understandably we need some primitive. I think we agree this >primitive is "initiate a session with the Refer-To address". > > Due to the design constraints of our device, we cannot keep around >both calls. I suspect that a PSTN gateway would be in a similar >situation, since there is no way for the POTS phone to be able to >indicate this. When the new session is active, we disconnect the old. You really can't keep state for a held call and an active call at the same time? I find that a little hard to believe. I know of at least one PSTN gateway that can do that ;-). > Yes, we are unable to use services which require the old call to stay >active. It's a constraint. But our implementation is completely >reasonable and we do follow the spec. > > > So far, the only service I've halted seems to be Music-On-Hold, which >requires that the far end have some crazy logic to send a BYE based on a >REFER anyways. I'm sure there will be other services that this device >won't be able to handle, but I'm not worried yet. Crazy logic? When you want to take the user off-hold you tell them to stop listening to music. That seems pretty logical to me. Attended transfers and Call Waiting need you to manage two sessions too. This is a pretty basic feature for an IP phone. > I suspect that other SIP devices which try to act like phones will >behave similarily, which is why I suggested to change the music call >flow to be more interoperability-friendly. what other IP phone implementations are you thinking of? >> [...] Putting a Require header in to specify each service for which >> REFER might be used is a bad thing. Its the same as writing a formal >> protocol spec for each specific service. Our aim here was to build >> primitive operation which could be used to build many services, >> without every party knowing the service. Just the invoker needs to >> know how to map the services into protocol primitives. > > Yes, but there are two actors here. The sender of the REFER (who >knows the service it wants to provide) and the receiver of the REFER >(who doesn't). At least in this example, if we knew that the sender >really needed the call to stay up after the REFER completes, then we >could at least reject the REFER. i think that is a very slippery slope. i won't go there. thanks, -rohan >-- >Billy Biggs, 3Com Email: Billy_Biggs@3com.com >http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 15:46:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA24807 for ; Mon, 4 Dec 2000 15:46:43 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B90E24434F; Mon, 4 Dec 2000 14:45:34 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 17D9B44336 for ; Mon, 4 Dec 2000 14:44:49 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 4 Dec 2000 14:44:37 -0600 (CST) From: Billy Biggs To: Henry Chen Cc: Alan Johnston , SIP List , stlevy@cisco.com Subject: Re: [SIP] Attended TransferCallFlow:draft-ietf-sip-service-examples-00.txt Message-ID: <20001204144437.B2342@div8.net> References: <3A27EC37.8465F804@cisco.com> <20001201124935.A32143@div8.net> <3A2BC3E8.E31849F3@wcom.com> <3A2BC9F0.C0737422@cisco.com> <20001204110350.A2156@div8.net> <3A2BDB2B.BA8C916F@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <3A2BDB2B.BA8C916F@cisco.com>; from hjlechen@cisco.com on Mon, Dec 04, 2000 at 11:58:04AM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 14:44:37 -0600 Henry Chen (hjlechen@cisco.com): >>> If INVITE (F16) is a new call, C will get ring again during the >>> transfer. >> >> Yes. Please see our replaces draft for one solution to this >> problem. Overloading the call-id is not a good idea. > > Is this a perfect case for same call with different call legs and is > acceptable? Huh? >> It is now generally accepted that the call-id should not be used to >> infer that an incoming call should replace or have any association >> with an ongoing call. Doing so leads to problems in some forking >> situations, and is a general overloading of the meaning. > > Could you give a call scenario for the forking situation which leads > to problems? Sure. 1. A single INVITE may complete at multiple remote parties (multiple 200 OK responses). The UA may choose to keep around all of these calls. When a new call with the same call-id comes in, which of these multiple calls is it associated with? 2. A UA receives a call and answers it, then later receives a retransmission of the original INVITE from a different proxy (request merging). I want to protect this UA from mistaking this as a replacement call for the answered one. 3. A broken UA may make multiple calls within the same Call-ID. I want to protect against mis-associating these calls. 4. Most (all) commercially available SIP UAs don't give larger scope to the call-id. As well, there is no way to tell if a UA will give it any significance. Cleaner to seperate replacement or association as new headers. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 16:05:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA29573 for ; Mon, 4 Dec 2000 16:05:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 30F034434E; Mon, 4 Dec 2000 15:05:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 449DC4434B for ; Mon, 4 Dec 2000 15:04:07 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 4 Dec 2000 15:03:57 -0600 (CST) From: Billy Biggs To: Alan Johnston Cc: Robert Sparks , Jonathan Rosenberg , SIP List Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 Message-ID: <20001204150357.A2443@div8.net> References: <20001130100343.A30059@div8.net> <20001130104711.A30137@div8.net> <3A2BE821.733CDFD5@wcom.com> <20001204141622.A2342@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <20001204141622.A2342@div8.net>; from Billy_Biggs@3com.com on Mon, Dec 04, 2000 at 02:16:22PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 15:03:57 -0600 To add to my own email: Billy Biggs wrote: > REFER Refer-To: farend@host.com > > spawns -> INVITE farend@host.com > To: farend@host.com > From: me@localhost;tag=54321 > Call-ID: 12345@host.com > > Then later I get: > > REFER Refer-To: farend@host.com;method=BYE > > spawns -> BYE farend@host.com > To: farend@host.com > From: farend@host.com;tag=73625 > Call-ID: 83738@host.com > > This BYE has a new from tag and a new call-id, so it gets ignored by > the far end. > > In order to ensure we match, the REFERs MUST include both the > Call-ID and From (with a tag). Ouch. My implementation does not > want to trust either of those to a remote UA, especially not the > From. Even with specifying a Call-ID and From header for each REFER, I'm also assuming: 1. The remote UA will match the BYE to the ongoing call, even though it does not have a To-tag (this is mentioned in the spec, but I wouldn't count on all UAs supporting it). 2. That you don't care about the Record-Route'ing proxies in the middle of the call which care very much about receiving that BYE. I'm sure that 2 is unacceptable to some people on this list. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 16:25:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA04304 for ; Mon, 4 Dec 2000 16:25:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 299B94434B; Mon, 4 Dec 2000 15:25:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id A6CBC44346 for ; Mon, 4 Dec 2000 15:24:56 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id OAA07227; Mon, 4 Dec 2000 14:24:45 -0700 (MST)] Received: [from grumpy.rsch.comm.mot.com (grumpy.rsch.comm.mot.com [145.1.80.93]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id OAA12344; Mon, 4 Dec 2000 14:24:45 -0700 (MST)] Received: from labs.mot.com (localhost [127.0.0.1]) by grumpy.rsch.comm.mot.com (8.9.3+Sun/8.8.8) with ESMTP id PAA01888; Mon, 4 Dec 2000 15:25:13 -0600 (CST) Message-ID: <3A2C0BB9.7E7E0E3C@labs.mot.com> From: Bryan Thale Organization: Motorola Labs, Networking & Infrastructure Research X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: jainsip@sun.com, sip@lists.bell-labs.com, Ross Lillie Subject: Re: [SIP] [JAIN SIP] Header names and type codes References: <3A26EA0B.BADCD544@dynamicsoft.com> <3A26FB82.8201F239@labs.mot.com> <3A270071.AD24CCC3@dynamicsoft.com> <3A2703ED.3C294813@labs.mot.com> <3A2782AF.A2E9D3B8@dynamicsoft.com> <3A27DF50.3C319B86@labs.mot.com> <3A27E7B6.6C740DFE@dynamicsoft.com> <3A27FEAD.ED3374C4@labs.mot.com> <3A2812C0.2C4E0E46@dynamicsoft.com> <3A28563D.8B4DD10E@labs.mot.com> <3A294F52.2F44994@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 04 Dec 2000 15:25:13 -0600 Content-Transfer-Encoding: 7bit Chris, > > I don't think a GeneralHeader interface tag is necessary since a > > "general header" is simply a header that can be both a "request header" > > and a "response header" and the multiple inheritance of interfaces > > solves that problem nicely. > > I think a GeneralHeader interface would be useful to indicate to an application > that it should copy a received unrecognised header into a response. > Two points, first, if the header is unrecognized, it is not possible to determine that it is a general header. The header is unrecognized; it could be anything and SIP mandates that such headers be treated as entity headers not general headers. Second, general headerness, if you will, can be determined by simply testing instanceof ResponseHeader and/or instanceof RequestHeader Only general headers will be instances of both RequestHeader and ResponseHeader, so they can be adequately detected without a special GeneralHeader type. By eliminating the redundant GeneralHeader tag, we can simplify the API by allowing general headers to be processed along with the other request or response headers as appropriate without introducing a special case into the logic. > > interface EntityHeader extends Header; // Empty Interface > > interface UnrecognizedHeader extends EntityHeader; > > The interfaces for different header types would imply the existence of > UnrecognizedEntityHeader, UnrecognizedRequestHeader, UnrecognizedResponseHeader > and UnrecognizedGeneralHeader rather than just UnrecognizedHeader. We would > also need a createUnrecognizedEntityHeader, createUnrecognizedRequestHeader, > createUnrecognizedResponseHeader and createUnrecognizedGeneralHeader methods on > the JainSipHeaderFactory > I don't follow. If the header is unrecognized, how can we make any judgments about it being a request, response, general, or entity header? > Would it be preferable to just remove the setName (and setMethod) method from the > Header interface, and only have the name parameter in the factory's createHeader > method? If not, I would suggest that the setName method should not be any header > interfaces - the name should be fixed upon creation of the object. > By setMethod, do you mean setType? I think setType should be done away with entirely and setName moved to the UnrecognizedHeader interface. The names of the headers should be statically defined for all the recognized headers that have defined interfaces in the API. The exception being the UnrecognizedHeader. In that case, the name of the header must be determined from the actual message header received over the wire. Since it can represent any new or experimental header, we cannot possibly know its name in advance and thus must set the name in the object we create to represent it. > Actually we could move both the getName() and setName() methods of header to UnrecognizedHeader - the > application can use instanceof rather than getName() with the same advantages associated with the header > type interfaces - the getName() method would only ever be invoked if(receivedHeader instanceof > UnrecognizedHeader). [Of course if the application wants the actual text of the header name it can just use > XXXHeader.name]. What do you think? > I think getName is still an important method to have in the Header interface. Headers have two basic properties, a name and a value. It is just as valuable to have a sub-type independent way of retrieving a header's name as it is to retrieve its value. In most cases, getName will simply return the static XXXHeader.name value, but UnrecognizedHeaders would return the "dynamically" set name of the header. This is an important property because it allows a collection of various header types to be processed as a collection of generic Header objects without requiring explicit knowledge of the various sub-types of Header. For example: void printHeaders( Header[] hdrs ) { for (i=0; i So now things are looking like (with createMethods only for the bottom four of the hierarchy in > JainSipHeaderFactory) > > Header > | > +---UnrecognizedHeader(getName(), setName()) > | | > | +-----------------------------------+ > | | > +---GeneralHeader | > | | | > | +---UnrecognizedGeneralHeader-------+ > | | > +---RequestHeader | > | | | > | +---UnrecognizedRequestHeader-------+ > | | > +---ResponseHeader | > | | | > | +---UnrecognizedResponseHeader------+ > | | > +---EntityHeader | > | | > +---UnrecognizedEntityHeader--------+ > > How does this look? > I don't see the need for the UnrecognizedXxxHeader interfaces. If a SIP stack received a header it didn't recognize, how would it choose which UnrecognizedXxxHeader to create? On the other hand, why would an application ever create an UnrecognizedXxxHeader? Since it is creating the header, it *must* know what it is. Take, for example, an application that wanted to add a new experimental general header, one that the SIP stack it was using didn't support. Wouldn't that application define a class like public class XdashMyHeader implements RequestHeader, ResponseHeader, etc., instantiate it, and then simply pass that object into the addHeader method of the message under construction? While it is true that the SIP Stack won't know exactly what the header represents, it can still do everything it needs to do through the generic Header interface and the type system. Bryan. -- Bryan Thale Motorola Labs, Networking and Infrastructure Research mailto:thale@labs.mot.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 16:45:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10510 for ; Mon, 4 Dec 2000 16:45:25 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 129244435C; Mon, 4 Dec 2000 15:45:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id F032444336 for ; Mon, 4 Dec 2000 15:44:33 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id PAA30144; Mon, 04 Dec 2000 15:45:50 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Mon, 4 Dec 2000 15:42:34 -0600 Message-ID: From: "Culpepper, Bert" To: Alan Johnston Cc: SIP List Subject: RE: [SIP] Questions on draft-rosenberg-sip-app-components-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 15:42:29 -0600 If I may, I'll take a shot at 1. > -----Original Message----- > From: Alan Johnston [mailto:alan.johnston@wcom.com] > Sent: Friday, December 01, 2000 11:33 PM > To: Jonathan Rosenberg; Peter Mataga; Henning Schulzrinne > Cc: SIP List > Subject: [SIP] Questions on draft-rosenberg-sip-app-components-00.txt > > > Jonathan/Peter/Henning, > > A couple of questions about some of the examples in your excellent and > informative draft. (If I could only get some of the MEGACO proponents > in > my organization to read and understand it...) > > 1. On page 16, section 5.4, referring to Figure 3, you say: > > "The next step for the AS is to get a > stream of DTMF digits to flow from the caller to the media server. > To > > do this, it sends a re-INVITE to the caller (11). This re-INVITE > contains the same SDP as the response (6) from the called party, > but > with the addition of a new media line. This media line is audio, > and > contains a single codec, the RTP payload format for DTMF and tones > [8]. The connection address and port are from the SDP returned from > the media server. This tells the caller to send an additional media > stream to the media server, using only the DTMF codec. " > > I'm not sure I understand what the SDP in the re-INVITE should look > like. Lets say the SDP in the 200 OK (6) from the Callee contained: > > c=IN IP4 100.101.102.103 > m=audio 5004 RTP/AVP 0 > > Lets say the SDP in the 200 OK (3) from the Media Server contained: > > c=IN IP4 200.201.202.203 > m=audio 53000 RTP/AVP 96 (Not sure about this line, but it would > indicate port 53000 and the DTMF encoding) > > The text says that media line from (3) is added to the SDP from (6), > but > what about the connection line which has a different IP address? I'm > not sure that the SDP of > > c=IN IP4 200.201.202.203 > m=audio 5004 RTP/AVP 0 > m=audio 53000 RTP/AVP 96 > > would have the desired effect. Normally, wouldn't this SDP say to > send > media to ports 5004 and 53000 at 200.201.202.203 (since the actual > intent is to send the PCMU to port 5004 at 100.101.102.103)? Or, > would > this SDP look completely different? I believe the authors leave it to the reader to decide how to build the SDP component to specify the desired media destinations. Using your example a complete media description will be as follows. (The c= line in the session desc. (not shown) will have the callee's IP address, the a= line below shows the event format specified in RFC 2833). m=audio 5004 RTP/AVP 0 m=audio 53000 RTP/AVP 96 c=IN IP4 200.201.202.203 a=rtpmap:96 telephone-event The above indicates a different destination for the second media stream according to RFC 2327 (SDP). > 2. In Figure 5, the IVR call flow shows the Callee sending IVR > commands > to the IVR Server after the receipt of the 183 Session Progress, but > before any 200 OK. I think this could be useful, but I'm wondering if > User Agents that support Early Media like this would actually send RTP > packets prior to getting a 200 OK. For example, if a Gateway to the > PSTN sends a 183 Session Progress, it may not include the a=sendonly > attribute, but any RTP packets prior to call completion in the PSTN > would be simply dropped. > > 3. In Figure 9, the Web Enabled Message Drops call flow, I am trying > to > decide if the first message should be a HTTP POST or a GET as it is > shown. Your description indicates that a single click activates the > service - the trigger is simply that the particular URL has been > accessed. I understand that each mailbox for each user would have a > URL. My question is how the Web Caller's SIP URL is sent to the > Controller, since the Controller initiates the INVITE (3). Would it > be > somehow imbedded as a parameter in the URL? Or, should the message be > a > POST, in which case the Web Caller would type in their SIP URL, click > the submit button, and the combination of the URL and the form data > would give the controller enough information to setup the call. > Finally, one perhaps dumb question relating to this example. If the > SIP > User Agent and the HTTP Client were on the same machine, couldn't the > Web Caller just click on a link containing a SIP URL (instead of a > HTTP > URL) of the desired mailbox which would cause the caller's SIP User > Agent to simply place the call? > > Again, thanks for detailing this very useful method of decomposition. > > Alan Johnston > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 18:24:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA15038 for ; Mon, 4 Dec 2000 18:24:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EDD2E4433D; Mon, 4 Dec 2000 17:24:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dnsmx2pya.telcordia.com (dnsmx2pya.telcordia.com [128.96.20.32]) by lists.bell-labs.com (Postfix) with ESMTP id 906E744336; Mon, 4 Dec 2000 15:40:36 -0500 (EST) Received: from notes949.cc.telcordia.com (notes949a.cc.telcordia.com [128.96.246.8]) by dnsmx2pya.telcordia.com (8.9.3/8.9.3) with SMTP id QAA10004; Mon, 4 Dec 2000 16:33:41 -0500 (EST) Received: by notes949.cc.telcordia.com(Lotus SMTP MTA v4.6.4 (830.2 3-23-1999)) id 852569AB.00766D58 ; Mon, 4 Dec 2000 16:33:32 -0500 X-Lotus-FromDomain: TELCORDIA From: "Petros N. Mouchtaris" To: megaco@standards.nortelnetworks.com, iptel@lists.bell-labs.com, sip@lists.bell-labs.com Message-ID: <852569AB.00766C99.00@notes949.cc.telcordia.com> Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=1wj55wbMuTLaPmr8Vlgwmlg8x6MSQcPhFaLr2uYDP8KJkX3qiio0mrEY" Content-Disposition: inline Subject: [SIP] call for papers: VoIP conference Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 16:31:46 -0500 --0__=1wj55wbMuTLaPmr8Vlgwmlg8x6MSQcPhFaLr2uYDP8KJkX3qiio0mrEY Content-type: text/plain; charset=us-ascii Content-Disposition: inline Attached is a call for papers for a VoIP conference that is part of SPIE's Symposium on the convergance of IT and communications (ITCOM 2001). Feel free to send me an e-mail if you have any questions. Petros (See attached file: IT201.pdf) --0__=1wj55wbMuTLaPmr8Vlgwmlg8x6MSQcPhFaLr2uYDP8KJkX3qiio0mrEY Content-type: application/pdf; name="IT201.pdf" Content-Disposition: attachment; filename="IT201.pdf" Content-Description: Adobe Portable Document Content-Transfer-Encoding: base64 JVBERi0xLjMNJeLjz9MNCjQyIDAgb2JqDTw8IA0vTGluZWFyaXplZCAxIA0vTyA0NCANL0ggWyAx Mjc0IDM2MSBdIA0vTCA3NzUwNiANL0UgMTYzMDUgDS9OIDIgDS9UIDc2NTQ4IA0+PiANZW5kb2Jq DSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICB4cmVmDTQyIDQyIA0wMDAwMDAwMDE2IDAwMDAwIG4NCjAwMDAwMDExODcgMDAwMDAgbg0KMDAw MDAwMTYzNSAwMDAwMCBuDQowMDAwMDAxODQyIDAwMDAwIG4NCjAwMDAwMDIwNTkgMDAwMDAgbg0K MDAwMDAwMzE0NCAwMDAwMCBuDQowMDAwMDAzMzQzIDAwMDAwIG4NCjAwMDAwMDM1NTIgMDAwMDAg bg0KMDAwMDAwNDY0MSAwMDAwMCBuDQowMDAwMDA0NjYyIDAwMDAwIG4NCjAwMDAwMDUyODMgMDAw MDAgbg0KMDAwMDAwNTMwNCAwMDAwMCBuDQowMDAwMDA1OTE4IDAwMDAwIG4NCjAwMDAwMDY2MDgg MDAwMDAgbg0KMDAwMDAwNjgyNiAwMDAwMCBuDQowMDAwMDA2ODQ3IDAwMDAwIG4NCjAwMDAwMDc0 MjcgMDAwMDAgbg0KMDAwMDAwODUyMCAwMDAwMCBuDQowMDAwMDA4NzI5IDAwMDAwIG4NCjAwMDAw MDg3NTAgMDAwMDAgbg0KMDAwMDAwOTQxNyAwMDAwMCBuDQowMDAwMDA5NDgyIDAwMDAwIG4NCjAw MDAwMDk4MDIgMDAwMDAgbg0KMDAwMDAxMDQ4MiAwMDAwMCBuDQowMDAwMDEwNjg3IDAwMDAwIG4N CjAwMDAwMTEzNjggMDAwMDAgbg0KMDAwMDAxMTU2OSAwMDAwMCBuDQowMDAwMDExNzk4IDAwMDAw IG4NCjAwMDAwMTE5ODIgMDAwMDAgbg0KMDAwMDAxMjY2MyAwMDAwMCBuDQowMDAwMDEyODY5IDAw MDAwIG4NCjAwMDAwMTI4OTAgMDAwMDAgbg0KMDAwMDAxMzUzMCAwMDAwMCBuDQowMDAwMDEzNTUx IDAwMDAwIG4NCjAwMDAwMTQyMTcgMDAwMDAgbg0KMDAwMDAxNDIzOCAwMDAwMCBuDQowMDAwMDE0 Nzg5IDAwMDAwIG4NCjAwMDAwMTQ4MTAgMDAwMDAgbg0KMDAwMDAxNTM2MiAwMDAwMCBuDQowMDAw MDE1NTAxIDAwMDAwIG4NCjAwMDAwMDEyNzQgMDAwMDAgbg0KMDAwMDAwMTYxNCAwMDAwMCBuDQp0 cmFpbGVyDTw8DS9TaXplIDg0DS9JbmZvIDQxIDAgUiANL1Jvb3QgNDMgMCBSIA0vUHJldiA3NjUz OCANL0lEWzxiZDFmNzYyODY4ZTAwYTQ3NTljN2FkY2VjODE1ZjYzZT48YmQxZjc2Mjg2OGUwMGE0 NzU5YzdhZGNlYzgxNWY2M2U+XQ0+Pg1zdGFydHhyZWYNMA0lJUVPRg0gICAgIA00MyAwIG9iag08 PCANL1R5cGUgL0NhdGFsb2cgDS9QYWdlcyAzMCAwIFIgDS9KVCA0MCAwIFIgDS9QYWdlTGFiZWxz IDI5IDAgUiANPj4gDWVuZG9iag04MiAwIG9iag08PCAvUyAxMTYgL0wgMjY1IC9GaWx0ZXIgL0Zs YXRlRGVjb2RlIC9MZW5ndGggODMgMCBSID4+IA1zdHJlYW0NCkiJYmBgYGZgYPnFwMbAIKPAwMuA ALxAMTYGFgaOHoYnOxgY/AwYUIDurHMsIgo/9zb3e055N//M1tVeBYvXFL/Pff3NgYFBydgFBBqA 6hgFgUBICQSUjS1AJgEBCwND5EUgrQbEdmARUQZ+xhJmAUUHbgXxRm4GBqYIBgZOF5EXPAEMDN2H JBj2MDBwSTAmCG0IStBj9GLYwriAqUdkAfcEBoZZBxiYWhkYODwYGBQN+A7MY1jV8J05hKmHI4D3 gsGbiQ2Tu54y71TYwtYhdED9+CSGNqHFTFpMDTwaTAfEFsg7IPlIhoFR9SuQZgJib4AAAwCegzwD DWVuZHN0cmVhbQ1lbmRvYmoNODMgMCBvYmoNMjQ4IA1lbmRvYmoNNDQgMCBvYmoNPDwgDS9UeXBl IC9QYWdlIA0vUGFyZW50IDMwIDAgUiANL1Jlc291cmNlcyA0NSAwIFIgDS9Db250ZW50cyBbIDUx IDAgUiA1MyAwIFIgNTcgMCBSIDYxIDAgUiA3MyAwIFIgNzUgMCBSIDc3IDAgUiA3OSAwIFIgXSAN L01lZGlhQm94IFsgMCAwIDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90 YXRlIDAgDT4+IA1lbmRvYmoNNDUgMCBvYmoNPDwgDS9Qcm9jU2V0IFsgL1BERiAvVGV4dCAvSW1h Z2VCIF0gDS9Gb250IDw8IC9GMiA0OSAwIFIgL0YzIDQ2IDAgUiAvRjQgNTQgMCBSIC9GNSA1OCAw IFIgL0Y2IDY5IDAgUiAvRjcgNzAgMCBSIA0vRjggNjQgMCBSIC9GOSA2NiAwIFIgPj4gDS9YT2Jq ZWN0IDw8IC9JbTEgODEgMCBSID4+IA0vRXh0R1N0YXRlIDw8IC9HUzEgODAgMCBSID4+IA0+PiAN ZW5kb2JqDTQ2IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RD aGFyIDMyIA0vTGFzdENoYXIgMjU1IA0vV2lkdGhzIFsgMjc4IDI3OCAzNTUgNTU2IDU1NiA4ODkg NjY3IDE5MSAzMzMgMzMzIDM4OSA1ODQgMjc4IDMzMyAyNzggMjc4IDU1NiANNTU2IDU1NiA1NTYg NTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCA1ODQgNTg0IDU4NCA1NTYgMTAxNSANNjY3 IDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDcyMiAyNzggNTAwIDY2NyA1NTYgODMzIDcyMiA3Nzgg NjY3IA03NzggNzIyIDY2NyA2MTEgNzIyIDY2NyA5NDQgNjY3IDY2NyA2MTEgMjc4IDI3OCAyNzgg NDY5IDU1NiAzMzMgDTU1NiA1NTYgNTAwIDU1NiA1NTYgMjc4IDU1NiA1NTYgMjIyIDIyMiA1MDAg MjIyIDgzMyA1NTYgNTU2IDU1NiANNTU2IDMzMyA1MDAgMjc4IDU1NiA1MDAgNzIyIDUwMCA1MDAg NTAwIDMzNCAyNjAgMzM0IDU4NCAzNTAgMCAzNTAgDTIyMiA1NTYgMzMzIDEwMDAgNTU2IDU1NiAz MzMgMTAwMCA2NjcgMzMzIDEwMDAgMzUwIDYxMSAzNTAgMzUwIDIyMiANMjIyIDMzMyAzMzMgMzUw IDU1NiAxMDAwIDMzMyAxMDAwIDUwMCAzMzMgOTQ0IDM1MCA1MDAgNjY3IDI3OCAzMzMgDTU1NiA1 NTYgNTU2IDU1NiAyNjAgNTU2IDMzMyA3MzcgMzcwIDU1NiA1ODQgMzMzIDczNyAzMzMgNDAwIDU4 NCANMzMzIDMzMyAzMzMgNTU2IDUzNyAyNzggMzMzIDMzMyAzNjUgNTU2IDgzNCA4MzQgODM0IDYx MSA2NjcgNjY3IA02NjcgNjY3IDY2NyA2NjcgMTAwMCA3MjIgNjY3IDY2NyA2NjcgNjY3IDI3OCAy NzggMjc4IDI3OCA3MjIgNzIyIA03NzggNzc4IDc3OCA3NzggNzc4IDU4NCA3NzggNzIyIDcyMiA3 MjIgNzIyIDY2NyA2NjcgNjExIDU1NiA1NTYgDTU1NiA1NTYgNTU2IDU1NiA4ODkgNTAwIDU1NiA1 NTYgNTU2IDU1NiAyNzggMjc4IDI3OCAyNzggNTU2IDU1NiANNTU2IDU1NiA1NTYgNTU2IDU1NiA1 ODQgNjExIDU1NiA1NTYgNTU2IDU1NiA1MDAgNTU2IDUwMCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lF bmNvZGluZyANL0Jhc2VGb250IC9IZWx2ZXRpY2EgDS9Gb250RGVzY3JpcHRvciA0NyAwIFIgDT4+ IA1lbmRvYmoNNDcgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA3MTgg DS9DYXBIZWlnaHQgNzE4IA0vRGVzY2VudCAtMjA3IA0vRmxhZ3MgMzIgDS9Gb250QkJveCBbIC0x NjYgLTIyNSAxMDAwIDkzMSBdIA0vRm9udE5hbWUgL0hlbHZldGljYSANL0l0YWxpY0FuZ2xlIDAg DS9TdGVtViA4OCANL1hIZWlnaHQgNTIzIA0+PiANZW5kb2JqDTQ4IDAgb2JqDTw8IA0vVHlwZSAv Rm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgNzE4IA0vQ2FwSGVpZ2h0IDcxOCANL0Rlc2NlbnQgLTIw NyANL0ZsYWdzIDI2MjE3NiANL0ZvbnRCQm94IFsgLTE3MCAtMjI4IDEwMDMgOTYyIF0gDS9Gb250 TmFtZSAvSGVsdmV0aWNhLUJvbGQgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMTQwIA0vWEhlaWdo dCA1MzIgDT4+IA1lbmRvYmoNNDkgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlw ZTEgDS9GaXJzdENoYXIgMzIgDS9MYXN0Q2hhciAyNTUgDS9XaWR0aHMgWyAyNzggMzMzIDQ3NCA1 NTYgNTU2IDg4OSA3MjIgMjM4IDMzMyAzMzMgMzg5IDU4NCAyNzggMzMzIDI3OCAyNzggNTU2IA01 NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiAzMzMgMzMzIDU4NCA1ODQgNTg0IDYx MSA5NzUgDTcyMiA3MjIgNzIyIDcyMiA2NjcgNjExIDc3OCA3MjIgMjc4IDU1NiA3MjIgNjExIDgz MyA3MjIgNzc4IDY2NyANNzc4IDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyA2NjcgNjExIDMz MyAyNzggMzMzIDU4NCA1NTYgMzMzIA01NTYgNjExIDU1NiA2MTEgNTU2IDMzMyA2MTEgNjExIDI3 OCAyNzggNTU2IDI3OCA4ODkgNjExIDYxMSA2MTEgDTYxMSAzODkgNTU2IDMzMyA2MTEgNTU2IDc3 OCA1NTYgNTU2IDUwMCAzODkgMjgwIDM4OSA1ODQgMzUwIDAgMzUwIA0yNzggNTU2IDUwMCAxMDAw IDU1NiA1NTYgMzMzIDEwMDAgNjY3IDMzMyAxMDAwIDM1MCA2MTEgMzUwIDM1MCAyNzggDTI3OCA1 MDAgNTAwIDM1MCA1NTYgMTAwMCAzMzMgMTAwMCA1NTYgMzMzIDk0NCAzNTAgNTAwIDY2NyAyNzgg MzMzIA01NTYgNTU2IDU1NiA1NTYgMjgwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0IDMzMyA3Mzcg MzMzIDQwMCA1ODQgDTMzMyAzMzMgMzMzIDYxMSA1NTYgMjc4IDMzMyAzMzMgMzY1IDU1NiA4MzQg ODM0IDgzNCA2MTEgNzIyIDcyMiANNzIyIDcyMiA3MjIgNzIyIDEwMDAgNzIyIDY2NyA2NjcgNjY3 IDY2NyAyNzggMjc4IDI3OCAyNzggNzIyIDcyMiANNzc4IDc3OCA3NzggNzc4IDc3OCA1ODQgNzc4 IDcyMiA3MjIgNzIyIDcyMiA2NjcgNjY3IDYxMSA1NTYgNTU2IA01NTYgNTU2IDU1NiA1NTYgODg5 IDU1NiA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCAyNzggMjc4IDYxMSA2MTEgDTYxMSA2MTEgNjEx IDYxMSA2MTEgNTg0IDYxMSA2MTEgNjExIDYxMSA2MTEgNTU2IDYxMSA1NTYgXSANL0VuY29kaW5n IC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvSGVsdmV0aWNhLUJvbGQgDS9Gb250RGVzY3Jp cHRvciA0OCAwIFIgDT4+IA1lbmRvYmoNNTAgMCBvYmoNNTQzIA1lbmRvYmoNNTEgMCBvYmoNPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA1MCAwIFIgPj4gDXN0cmVhbQ0KSIlUU02PmzAQ vfMr5mhLi4P55lptWqWXbhVu1R7Y4AASsSmbtNpf0r/b8YyJskKCmTdvhvc8sPt21DC8R78jXas0 hwQvjrJCNRUUtSqyRMPpEu0OFw3PLvoZfWmj3dcUNLTnSCcqqbmNoqJSZQNlqRrf1l6iBIYIK0ma QXuKYh+WBbR/o1/i+HKQpSrE/l87YpAKAwxYyq5m5aC7TgQ7ygImY42PmQpw5NKJeeb6IdNUlQLO jK/wgwoLz2XWqQvNe5440H16EGDM+pgO8rX9js4zdl5txinISpU0kOcqLdg3OtUaC+xU1ioTL3Q/ yLRUWuwpiWWcqUq0owGpq61m0Zy4ygZD48PVdpxNznYzMXmi89WTjFl5js6J9iFxGbUg4lnGFcbE xHNYwiAkhz5/kmIG1mOHyXrbdoDpnevQm3565AZhPXBAk6Hr/8g4zTDv7CYIh4QZjxJtUBCEbaNh NYFsujVgI432Ljrb09M8CCR8Wea7uO2MaE9FrvJGF7if9pk/wDR8gDqtKl6LpTdmAhyJaTDw5xM0 ZaKbnzCDZXQedXbDCZ0uMsfVdShoIMBr5H5nZhOoPl39kmvu99LiTRuKafImvSss779Ik7NCbyn3 H0GCr8KR+FOK0brZDZM/Lp8CMGlk0upuwwgTYxvlIgu/MsMoCg6FJ8rB9LcwuwsMZ2FZ3bB23PmZ 7o0utzc6+M9Ngafk638BBgC/Ugr4DWVuZHN0cmVhbQ1lbmRvYmoNNTIgMCBvYmoNNTM2IA1lbmRv YmoNNTMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA1MiAwIFIgPj4gDXN0 cmVhbQ0KSIl8k8lu2zAQhu96ijmSB7HkcJF0TN0UcIAiBkL0EvcguLSjwpYCO06R1+ihz9vh4sQJ jMIHc7Zvfg5H/qa69pWCASprhOzAWdFasKhE20KthWlhH6r1KSqFbS5ElWxjGJURqgGKQt3YSyHd 2VQaUzJXYvT/p1IZKboLlSQFNlSfhCHlth1YgecApYUmqO6EtK+AlJPin3316asBBZ5ynbAOJP3y SbuIbai30uB3laReUkgpDfhVVccj+X9X92zuZ7ffOOl3jGRIxX/4G+Lqwm2ERLqZBP8lAdQbwEQA m/XbLaynPSz6x7A/QD/+hKtxnI7jKuzC+MT9L8JhxiEK2SaZ+dQ50WloaIi2kSoKTWSFsclJb1T5 fRpWAW6fwx7mC1iSPV8sOfiwehin7bR54UoJzSgy9yjVkpdr2HINJYiUxpNOeTzOYRlP6orlZkqV 0dwt5rx2NJjrPxwN4Q9QHCOnPM2eshWytSeLjX1xDtPYb+HuZRe9j9NhOKYTTFzR0xMh/YGPwpE9 ZDMU74zT21v2PveZ18hC6rIJNF2Y1rnVB1XFO52pSq37d6IHjjFpfJvhEPLrzabda81xHFb9h4rD +xUxhj659mxFbHsaJK11nmR6l1m8hmG0bagJVN6oPtXTp6EsYqTkJXCnJXCYKSj/ooGr44bXRGrZ kVMPdkjyMG8vFG0ua2tFZ50t0gj3T4ABAHQ48MINZW5kc3RyZWFtDWVuZG9iag01NCAwIG9iag08 PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFy IDE4MSANL1dpZHRocyBbIDI3OCAzMzMgNDc0IDU1NiA1NTYgODg5IDcyMiAyMzggMzMzIDMzMyAz ODkgNTg0IDI3OCAzMzMgMjc4IDI3OCA1NTYgDTU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1 NTYgNTU2IDMzMyAzMzMgNTg0IDU4NCA1ODQgNjExIDk3NSANNzIyIDcyMiA3MjIgNzIyIDY2NyA2 MTEgNzc4IDcyMiAyNzggNTU2IDcyMiA2MTEgODMzIDcyMiA3NzggNjY3IA03NzggNzIyIDY2NyA2 MTEgNzIyIDY2NyA5NDQgNjY3IDY2NyA2MTEgMzMzIDI3OCAzMzMgNTg0IDU1NiAzMzMgDTU1NiA2 MTEgNTU2IDYxMSA1NTYgMzMzIDYxMSA2MTEgMjc4IDI3OCA1NTYgMjc4IDg4OSA2MTEgNjExIDYx MSANNjExIDM4OSA1NTYgMzMzIDYxMSA1NTYgNzc4IDU1NiA1NTYgNTAwIDM4OSAyODAgMzg5IDU4 NCAwIDAgMCAwIA0wIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDU1NiANNTU2IDAgMCAwIDAgMCA3MzcgMCAwIDAgMCAwIDAgMCA1ODQg MCAwIDAgNjExIF0gDS9FbmNvZGluZyAvV2luQW5zaUVuY29kaW5nIA0vQmFzZUZvbnQgL0hlbHZl dGljYS1Cb2xkT2JsaXF1ZSANL0ZvbnREZXNjcmlwdG9yIDU1IDAgUiANPj4gDWVuZG9iag01NSAw IG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0vQXNjZW50IDcxOCANL0NhcEhlaWdodCA3 MTggDS9EZXNjZW50IC0yMDcgDS9GbGFncyAyNjIyNDAgDS9Gb250QkJveCBbIC0xNzQgLTIyOCAx MTE0IDk2MiBdIA0vRm9udE5hbWUgL0hlbHZldGljYS1Cb2xkT2JsaXF1ZSANL0l0YWxpY0FuZ2xl IC0xMiANL1N0ZW1WIDE0MCANL1hIZWlnaHQgNTMyIA0+PiANZW5kb2JqDTU2IDAgb2JqDTUwMiAN ZW5kb2JqDTU3IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggNTYgMCBSID4+ IA1zdHJlYW0NCkiJjJNNj9MwEIbFNb9iTsiRGuOPxB+7p1XLIgErVhBOLAeTuq2hTaSkuyv+PXbt ZNvAgdOMv+Z95s0kI1A/Z+hVXv/M3txyoFBvMoKF4OBPVllBMCGMQ91kIRM6XP+GYNntuz4vBObI rDu/bJ9yhQWy7THsauS6FpbTyqa7APn3+r1XElGJclwqTaMWOan8D48YeSRLPCt7AuBJSaBFXkjM zkDFCfTrl5tEIBMB84UJ+MAFJhoEY1hUUB/OcXx7G9vbtrGw3BnXX0U8FUtIXLFIhyAe6JGbVeng 3h77boC77rHZHU3vhsVFCYXpeBNqu2+6fu2Mz5pd6/m3zg7xeoIuaIU1g4LhcjKFVMkUGbJgyn3f bXtz8BYcDu54tPYqtT6JVvov5+cd8NTaSWKcA6FllLjdW1+73cJNu/YuV1giG4PJC+3DkBeUvOy2 fsl9XFySaFypMxk5yfBx3NzQdNfj8CQ4js/ZyumRiI9WznftnYYP5ofbm80vMyzmBqh/TZVkqQJ8 qt/C50Au0Ou8KH1YwQN611vb2If8Om7NqDSm5QsWnSxTo2V+Ah7b6A58dO2MqeAa+2EvKA5/3fht WagSUqlVLDNNSU4pVuhiVuZGaazYWaOEhmreIPPk1nDXrH4PZo4hMeFzc8NjFdLnPwIMABOT/1YN ZW5kc3RyZWFtDWVuZG9iag01OCAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBl MSANL0ZpcnN0Q2hhciAzMiANL0xhc3RDaGFyIDI1NSANL1dpZHRocyBbIDI3OCAyNzggMzU1IDU1 NiA1NTYgODg5IDY2NyAxOTEgMzMzIDMzMyAzODkgNTg0IDI3OCAzMzMgMjc4IDI3OCA1NTYgDTU1 NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDU1NiA1NTYgNTU2IDI3OCAyNzggNTg0IDU4NCA1ODQgNTU2 IDEwMTUgDTY2NyA2NjcgNzIyIDcyMiA2NjcgNjExIDc3OCA3MjIgMjc4IDUwMCA2NjcgNTU2IDgz MyA3MjIgNzc4IDY2NyANNzc4IDcyMiA2NjcgNjExIDcyMiA2NjcgOTQ0IDY2NyA2NjcgNjExIDI3 OCAyNzggMjc4IDQ2OSA1NTYgMzMzIA01NTYgNTU2IDUwMCA1NTYgNTU2IDI3OCA1NTYgNTU2IDIy MiAyMjIgNTAwIDIyMiA4MzMgNTU2IDU1NiA1NTYgDTU1NiAzMzMgNTAwIDI3OCA1NTYgNTAwIDcy MiA1MDAgNTAwIDUwMCAzMzQgMjYwIDMzNCA1ODQgMzUwIDAgMzUwIA0yMjIgNTU2IDMzMyAxMDAw IDU1NiA1NTYgMzMzIDEwMDAgNjY3IDMzMyAxMDAwIDM1MCA2MTEgMzUwIDM1MCAyMjIgDTIyMiAz MzMgMzMzIDM1MCA1NTYgMTAwMCAzMzMgMTAwMCA1MDAgMzMzIDk0NCAzNTAgNTAwIDY2NyAyNzgg MzMzIA01NTYgNTU2IDU1NiA1NTYgMjYwIDU1NiAzMzMgNzM3IDM3MCA1NTYgNTg0IDMzMyA3Mzcg MzMzIDQwMCA1ODQgDTMzMyAzMzMgMzMzIDU1NiA1MzcgMjc4IDMzMyAzMzMgMzY1IDU1NiA4MzQg ODM0IDgzNCA2MTEgNjY3IDY2NyANNjY3IDY2NyA2NjcgNjY3IDEwMDAgNzIyIDY2NyA2NjcgNjY3 IDY2NyAyNzggMjc4IDI3OCAyNzggNzIyIDcyMiANNzc4IDc3OCA3NzggNzc4IDc3OCA1ODQgNzc4 IDcyMiA3MjIgNzIyIDcyMiA2NjcgNjY3IDYxMSA1NTYgNTU2IA01NTYgNTU2IDU1NiA1NTYgODg5 IDUwMCA1NTYgNTU2IDU1NiA1NTYgMjc4IDI3OCAyNzggMjc4IDU1NiA1NTYgDTU1NiA1NTYgNTU2 IDU1NiA1NTYgNTg0IDYxMSA1NTYgNTU2IDU1NiA1NTYgNTAwIDU1NiA1MDAgXSANL0VuY29kaW5n IC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9udCAvSGVsdmV0aWNhLU9ibGlxdWUgDS9Gb250RGVz Y3JpcHRvciA1OSAwIFIgDT4+IA1lbmRvYmoNNTkgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3Jp cHRvciANL0FzY2VudCA3MTggDS9DYXBIZWlnaHQgNzE4IA0vRGVzY2VudCAtMjA3IA0vRmxhZ3Mg OTYgDS9Gb250QkJveCBbIC0xNzAgLTIyNSAxMTE2IDkzMSBdIA0vRm9udE5hbWUgL0hlbHZldGlj YS1PYmxpcXVlIA0vSXRhbGljQW5nbGUgLTEyIA0vU3RlbVYgODggDS9YSGVpZ2h0IDUyMyANPj4g DWVuZG9iag02MCAwIG9iag01ODkgDWVuZG9iag02MSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURl Y29kZSAvTGVuZ3RoIDYwIDAgUiA+PiANc3RyZWFtDQpIiVxSwW7bMAy95yt4lIdakxLXTrDjhgEd MKBbjfbQ7qDJdK3WlgpJTta/H2U7aZuDLVIiHx8fubpncOd833x1wxfI/tQ/Vp+/70BC3a4uuZQg oP62ElwIUUKtVzmZu2QeVvfsBkOnGm+yvOQFg5+uU/ZiwdjOGBVfv0HI4gSRzAQBVHeP2SXl+6yg f5idcy4FL8sZKJ/IbI5I1a6aka4xehcyKXiVqIy6i8qbcMZnSxkLoYQgUi6DrH56KyW4XELYb/VE LabXvFhzajuXfL2ZnmrVv6gGL+bUBX3Dq4Ulgxp77XxjFFm6s653jwbDhDWF5Wu+rk4NkdKJDpdF slI/dYegnd2jf0SrEVwLxrbOD1kuN1wyFY2zoGxDUcMwWqOnm6ldkYjKatG9WBBjymTvyECnAqi+ dwdsIFK9MUx1GhUVWIwH558DtFm+ZY5yJY0oodefliFsF84yWamCa1v0xj6mKawZ7J0h4oniMPbR DJjUCOj3dB043HVo4TbFfIQ9bUm5WxbNkQpZyUualBTs6no6Htitu7p+yCbnQJ20xodIItEeNKPG WRj02lCLr3Q/BVKbx2qCF1ux7OFgmtwa6jnJYiIkvEH5Z4yEk1SyBID/XnDedRvM/h2OKI84qo/o LU2CnkkEYhwdRK8ak4ajeojY40vnLM5CkKxrwtPI4deoehNfaQAf5Dhtxu64GTezglnFd2wial0E AhJMZXlFqzE7enY8jY8Os6xNXE7y06GJkglhRPiLWqX50+cDHNCfTYW2Sf8XYABqBCTkDWVuZHN0 cmVhbQ1lbmRvYmoNNjIgMCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0RpZmZlcmVuY2VzIFsg MSAvRzQgXSANPj4gDWVuZG9iag02MyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu Z3RoIDIyOSAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCkiJYmRgYWJgZGRUcHV1c3V00Q4P 0AupLMhPL0osyMhMDq7MTcrPKTawNAKpsfwhw/RDlvmHKMtvSR7m+TwsP+R4xLp/V8qwrPl5mFVu AeP/7m4IycP+PVngexr/90zB7u9rhRhYGBmZTTwT3U18E5OL8nNTUzIT493y80og9qQWxZvoGcaH B8RjWo1DEIcjGRgYWRgY2xmYgPbZd/P91P5x9vsTUfeSoJg4udjYwBL3Hs+u4EUxOzlidhUfOid1 dtHRnTvldu46uuhcz8WuIyU74zh2xi4KcpfqZucDCDAARdRnOAplbmRzdHJlYW0NZW5kb2JqDTY0 IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDMyIA0v TGFzdENoYXIgMTgxIA0vV2lkdGhzIFsgMjUwIDMzMyA0MDggNTAwIDUwMCA4MzMgNzc4IDE4MCAz MzMgMzMzIDUwMCA1NjQgMjUwIDMzMyAyNTAgMjc4IDUwMCANNTAwIDUwMCA1MDAgNTAwIDUwMCA1 MDAgNTAwIDUwMCA1MDAgMjc4IDI3OCA1NjQgNTY0IDU2NCA0NDQgOTIxIA03MjIgNjY3IDY2NyA3 MjIgNjExIDU1NiA3MjIgNzIyIDMzMyAzODkgNzIyIDYxMSA4ODkgNzIyIDcyMiA1NTYgDTcyMiA2 NjcgNTU2IDYxMSA3MjIgNzIyIDk0NCA3MjIgNzIyIDYxMSAzMzMgMjc4IDMzMyA0NjkgNTAwIDMz MyANNDQ0IDUwMCA0NDQgNTAwIDQ0NCAzMzMgNTAwIDUwMCAyNzggMjc4IDUwMCAyNzggNzc4IDUw MCA1MDAgNTAwIA01MDAgMzMzIDM4OSAyNzggNTAwIDUwMCA3MjIgNTAwIDUwMCA0NDQgNDgwIDIw MCA0ODAgNTQxIDAgMCAwIDAgDTAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgNTAwIA01MDAgMCAwIDAgMCAwIDc2MCAwIDAgMCAwIDAg MCAwIDU2NCAwIDAgMCA1MDAgXSANL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcgDS9CYXNlRm9u dCAvVGltZXMtUm9tYW4gDS9Gb250RGVzY3JpcHRvciA2NyAwIFIgDT4+IA1lbmRvYmoNNjUgMCBv YmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA2OTkgDS9DYXBIZWlnaHQgNjc2 IA0vRGVzY2VudCAtMjA1IA0vRmxhZ3MgMjYyMTc4IA0vRm9udEJCb3ggWyAtMTY4IC0yMTggMTAw MCA5MzUgXSANL0ZvbnROYW1lIC9UaW1lcy1Cb2xkIA0vSXRhbGljQW5nbGUgMCANL1N0ZW1WIDEz OSANL1hIZWlnaHQgNDYxIA0+PiANZW5kb2JqDTY2IDAgb2JqDTw8IA0vVHlwZSAvRm9udCANL1N1 YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDMyIA0vTGFzdENoYXIgMTgxIA0vV2lkdGhzIFsgMjUw IDMzMyA1NTUgNTAwIDUwMCAxMDAwIDgzMyAyNzggMzMzIDMzMyA1MDAgNTcwIDI1MCAzMzMgMjUw IDI3OCANNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDMzMyAzMzMgNTcw IDU3MCA1NzAgNTAwIA05MzAgNzIyIDY2NyA3MjIgNzIyIDY2NyA2MTEgNzc4IDc3OCAzODkgNTAw IDc3OCA2NjcgOTQ0IDcyMiA3NzggDTYxMSA3NzggNzIyIDU1NiA2NjcgNzIyIDcyMiAxMDAwIDcy MiA3MjIgNjY3IDMzMyAyNzggMzMzIDU4MSA1MDAgDTMzMyA1MDAgNTU2IDQ0NCA1NTYgNDQ0IDMz MyA1MDAgNTU2IDI3OCAzMzMgNTU2IDI3OCA4MzMgNTU2IDUwMCANNTU2IDU1NiA0NDQgMzg5IDMz MyA1NTYgNTAwIDcyMiA1MDAgNTAwIDQ0NCAzOTQgMjIwIDM5NCA1MjAgMCAwIA0wIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgDTAg NTAwIDUwMCAwIDAgMCAwIDAgNzQ3IDAgMCAwIDAgMCAwIDAgNTcwIDAgMCAwIDU1NiBdIA0vRW5j b2RpbmcgL1dpbkFuc2lFbmNvZGluZyANL0Jhc2VGb250IC9UaW1lcy1Cb2xkIA0vRm9udERlc2Ny aXB0b3IgNjUgMCBSIA0+PiANZW5kb2JqDTY3IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0 b3IgDS9Bc2NlbnQgNjk5IA0vQ2FwSGVpZ2h0IDY2MiANL0Rlc2NlbnQgLTIxNyANL0ZsYWdzIDM0 IA0vRm9udEJCb3ggWyAtMTY4IC0yMTggMTAwMCA4OTggXSANL0ZvbnROYW1lIC9UaW1lcy1Sb21h biANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViA4NCANL1hIZWlnaHQgNDUwIA0+PiANZW5kb2JqDTY4 IDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgMCANL0NhcEhlaWdodCAw IA0vRGVzY2VudCAwIA0vRmxhZ3MgNCANL0ZvbnRCQm94IFsgMCAtMjI5IDExOTYgODE1IF0gDS9G b250TmFtZSAvRUVGRUFEK1dQLlR5cG9ncmFwaGljU3ltYm9sczA5MiANL0l0YWxpY0FuZ2xlIDAg DS9TdGVtViAwIA0vQ2hhclNldCAoL0c0KQ0vRm9udEZpbGUzIDYzIDAgUiANPj4gDWVuZG9iag02 OSAwIG9iag08PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAxIA0v TGFzdENoYXIgMSANL1dpZHRocyBbIDY2MyBdIA0vRW5jb2RpbmcgNjIgMCBSIA0vQmFzZUZvbnQg L0VFRkVBRCtXUC5UeXBvZ3JhcGhpY1N5bWJvbHMwOTIgDS9Gb250RGVzY3JpcHRvciA2OCAwIFIg DT4+IA1lbmRvYmoNNzAgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9G aXJzdENoYXIgMzIgDS9MYXN0Q2hhciAxODEgDS9XaWR0aHMgWyAyNTAgMzMzIDQyMCA1MDAgNTAw IDgzMyA3NzggMjE0IDMzMyAzMzMgNTAwIDY3NSAyNTAgMzMzIDI1MCAyNzggNTAwIA01MDAgNTAw IDUwMCA1MDAgNTAwIDUwMCA1MDAgNTAwIDUwMCAzMzMgMzMzIDY3NSA2NzUgNjc1IDUwMCA5MjAg DTYxMSA2MTEgNjY3IDcyMiA2MTEgNjExIDcyMiA3MjIgMzMzIDQ0NCA2NjcgNTU2IDgzMyA2Njcg NzIyIDYxMSANNzIyIDYxMSA1MDAgNTU2IDcyMiA2MTEgODMzIDYxMSA1NTYgNTU2IDM4OSAyNzgg Mzg5IDQyMiA1MDAgMzMzIA01MDAgNTAwIDQ0NCA1MDAgNDQ0IDI3OCA1MDAgNTAwIDI3OCAyNzgg NDQ0IDI3OCA3MjIgNTAwIDUwMCA1MDAgDTUwMCAzODkgMzg5IDI3OCA1MDAgNDQ0IDY2NyA0NDQg NDQ0IDM4OSA0MDAgMjc1IDQwMCA1NDEgMCAwIDAgMCANMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAg MCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCAwIDAgMCA1MDAgDTUwMCAwIDAgMCAwIDAg NzYwIDAgMCAwIDAgMCAwIDAgNjc1IDAgMCAwIDUwMCBdIA0vRW5jb2RpbmcgL1dpbkFuc2lFbmNv ZGluZyANL0Jhc2VGb250IC9UaW1lcy1JdGFsaWMgDS9Gb250RGVzY3JpcHRvciA3MSAwIFIgDT4+ IA1lbmRvYmoNNzEgMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2VudCA2OTkg DS9DYXBIZWlnaHQgNjUzIA0vRGVzY2VudCAtMjA1IA0vRmxhZ3MgOTggDS9Gb250QkJveCBbIC0x NjkgLTIxNyAxMDEwIDg4MyBdIA0vRm9udE5hbWUgL1RpbWVzLUl0YWxpYyANL0l0YWxpY0FuZ2xl IC0xNS41IA0vU3RlbVYgNzYgDS9YSGVpZ2h0IDQ0MSANPj4gDWVuZG9iag03MiAwIG9iag01NjIg DWVuZG9iag03MyAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDcyIDAgUiA+ PiANc3RyZWFtDQpIiWxTsbKbMBDs/RVXQsbWgHl52GVm0iSTIgWTJvMKGc6gRJYcSTbh73MngR1m XqUTSLt3u6vNrhBFfaygGTc/s1FprUyf715FnUGwkO/KIgtWo5MB007bEf7cpFZhghO28uYR7BnC gMC/WusD7fO35uum+bBh+KI4QtNuElOZmPi4R3dXLQpobCenLWjpeiIhjlY6p9B5GFUYQBKw6SE4 2amgrAFl1vA1wxeirrhidHs+o+NBykJUGQyqHx49z6wepEPq1njVpbMzZJHAio8JqsOrttOFRt9n SMJkJmkSPyRFaPof9st3AZ+0t9tYwyA9dU1SqOAfuqy7PsxEJVdMJa9XlDo/CgJelL262CsL7PJd LQ6ZZHcOWcfUtEZFpIaAGq+DNQ9Z/f9s1XGfOAZ5x7xmhs5Z4utolRcZVCu1ngR8i0qju6TR/K0l JL+a8yGUKF+X1jk4QFKhmdta2ptvGhgHJM9dUsdgGK377aGVhka0d/JgJU65XxLzepgpViZK08W7 JwRSqYOzdbCYTnkZCY/8dXJ6P4qcRK4YF/+2pCFdewQjDDIwurGBCSIucZymZwTJplVcGCp7WrDM JyBvftHf3V5UL9B8Xue1qpe8NvQaeksuxoekSBcb9atT2mg9s/l1TCAtbt6ZFoFO00M9xcmD7aPK sTmiLUVZP2n38+ixYlqHHqVr6YLfAppeGeRHx+KSqs7nL3W0MHnPS3QvYDsYq22v0G/zt38CDAAQ 7kH1DWVuZHN0cmVhbQ1lbmRvYmoNNzQgMCBvYmoNNTg4IA1lbmRvYmoNNzUgMCBvYmoNPDwgL0Zp bHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3NCAwIFIgPj4gDXN0cmVhbQ0KSIl0U8Fu2zAMxa75 CqIne6hdO47jZLdu3YAOGLChxi7DDooiR9xkKZPkpPn7UpabtMN2CR8j8/GJfGo/z9q3s6zIi6Is oeUzQquAjrMfyRG9BAad4YMDo0GaI3BmLQrrCGhIs7JIDP2WeZl0aba6BJFmDQUbMxCPHD3qHXw3 91/Tn+3Ythgbhl6JE/aAXDgAL5mHvTUH3AqQuJPwZ2AK/QlMB9Nn4A0MhF2etr9m8yqf1zBf5HUD 7V28TFEH7gCX6zreppVIqo3uhBWaOCjbM+sDrZcC7tsPpu/h4dTvjcOhB6a3o9ACMrreC+p1nFO9 Digwf3yUuEF/DUeJXMZ5iXFigZhaHoTdjT1N93z3SFVFqmoVUKBC3RnbM49UTAKouO8HjTz+4wWX 2iizQ+FyaKU4T5LIqomsqZdNJHNhB01ySrMlhT6sokmm26W0uWNa51WCSo2ZZ2lD6W8B+1igYgEL s4pQxwPwMZUxFbCZABsimM6nKnJERWF4Zn01gUUUXVYBBdF3Iozr5r0Z1FbYtJznywSYFaF6kbAY roPzKAZ3MueznuxC5hrtch7S6R8+44bsuzUWmHKGPKyU2MLVAyqkNcEXM2jPUOdXEIxFm5/n1eKy +erZVNV6GvHt4KWh1xAGSCLHiPqAnmjHoRpww6ZHD2zjvGXcO8Doi84oZY4k+2+XvZAbLGCFYoHO mz1y9y4Iu/m0BHqj3UuFyZt4sppOcnJBMR6EJwe3lktSxf1ghXvFkY2fnrv/n+fb5R0+TO+QPn0S YACr0S4YDWVuZHN0cmVhbQ1lbmRvYmoNNzYgMCBvYmoNNDczIA1lbmRvYmoNNzcgMCBvYmoNPDwg L0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3NiAwIFIgPj4gDXN0cmVhbQ0KSImkU02P2jAQ Va/8ijnG1eK1Q/hIb0gIiapaoSXqpduDY4bg1tjIMcvy7+uPpdrLtiq9jGcy0Xtvxs+D++UEODS7 wZDRyRSGnPIpNItB8YE0Pwb3y1nupiZLjUfUSrRKK3+5g0fsQ4ZGhlyYLSzFSXtorEYnjMSM8a8M X+1qDRt0z0pin2D7XMB8vepvwgz/McZKaGRKJ/UMmvPgW6Y62DxOoiJDzgplPHZOeGUNnJXfh+BQ Y9+DQX+27mdPvjef35XBIg+LDH8RxK+C6rrOglaB2UUGZTrCGa0LsDtIMpOQ9aZ5AGWkPm0VmYa2 IXWIXYqwIrz8/c2nPhI+CodORY6KDEvKiw6NT2O8rx7g4Trv2603H/9wexvVGaGDfDg66620uoed dWmG2/ww325d2H2EjDdkTocWXaqOgULIPf4vQ9qvfUYHQsp4zR7l3lhtOxWwnwqkHYWXxebLHUjR anwit/Es8Kjt5RAWD/hyDEOEl/Nq8egua/pwCmdwmxHKjMAryqoAwSBnfFZFKl5XdDqKJjq8NXjM qlG205yUNR0XLamK3jshPSxOCAvh8ROZFQEBlti6k3AXMqpoVUAZTJlMwWhVj9NQbBxfy9Wywafy lwADAEZHFYkNZW5kc3RyZWFtDWVuZG9iag03OCAwIG9iag00NzQgDWVuZG9iag03OSAwIG9iag08 PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVuZ3RoIDc4IDAgUiA+PiANc3RyZWFtDQpIiWxTW2/a MBR+9684j/ZDPN9iJ3srJNU2rV0FYdI07SGkps2UQsVl1f79jh2DOkARsXMu/i7HEMGFyKF5Iz/p Hcuk4ZK2LBM8p+vDrtv2r3uoDh6qdu8/Msc1BVXAWeVfpjV3mBFCsl/NF/LhNgcJzYpIyYUBgc+4 k9JyhTlbcFEKLHkhWWCgcNuRsLNuJPOwZZlFiE3n/WO/ftrBZhUiCLMf1+cAbmi/g26zTjmfuvy6 8/DGsiIUDAMsPbwelkO/e/aP0K7x96fth3Y5eGj3Z8d6eEmH+BRCeJ50qVGX41aWFjIUZXMFTUVE FBC404Y1v0nBiyIKjxslLC8dyNxyrd/pznVoo59qCD3nbikludP/dUUYenMFQZVclVcQbHJWSjM6 O5k3OD6cA50xge8bphwu0/hxTEGK3lcQlV9QK/NzuHcO3F3y08LwXF/hZ0781MgvIht6v5hPZ5+R jkQaD5EXhWpRQ5UKxlA9HwlmjjsndBiJVkaHkcTzTXk8X7jTNVcaL/ICBZc0mpHjJYZJDaePCCxw 9NNj5OsPJjWiwreUmYzt9ex7XV21SDsdFRsU7i4s4sGiuiHa4j8BHC5Ym+syeJVpbmHrySplbYEW lpfZfwIMAES80PYNZW5kc3RyZWFtDWVuZG9iag04MCAwIG9iag08PCANL1R5cGUgL0V4dEdTdGF0 ZSANL1NBIGZhbHNlIA0vU00gMC4wMiANL09QIGZhbHNlIA0vb3AgZmFsc2UgDS9PUE0gMSANL0JH MiAvRGVmYXVsdCANL1VDUjIgL0RlZmF1bHQgDS9UUjIgL0RlZmF1bHQgDT4+IA1lbmRvYmoNODEg MCBvYmoNPDwgL1R5cGUgL1hPYmplY3QgL1N1YnR5cGUgL0ltYWdlIC9XaWR0aCAxNTIgL0hlaWdo dCAxNTIgL0JpdHNQZXJDb21wb25lbnQgMSANL0NvbG9yU3BhY2UgL0RldmljZUdyYXkgL0xlbmd0 aCA0MzkgL0ZpbHRlciAvQ0NJVFRGYXhEZWNvZGUgL0RlY29kZVBhcm1zIDw8IC9LIC0xIC9Db2x1 bW5zIDE1MiA+PiA+PiANc3RyZWFtDQr5MgaZVQV5BQK5KgPciwHh5EgPDZBA4IHBEFdBDY4cEQ21 YTIFwYIgYsgg2ocKGEDTBwkwQ3BWEgcKMOEyTB4dSXAvDhQRBp1DqCDYdFRCBt8MIJhkNOO2gg2F 4YaCDYQXDBpBsILsNJsJdhoIg4gjtsEFww0r2wS2w0vbCC7JA17ZGRwzpr3BBdipwJ2K7W+12q9r hr9hLa/a7X9d/2thr9r1/X/yEm16Ja/ktbWq/7+v/9pf+3+fDH5mGP4X8E2tL////+//39f/fX/9 f//v7//+vv6nQUfNAYa1h/BygLYX/h8F/76/9rUhn+F17w84DfOBsX/+lh/+C2H/4Lg//rf/rd/6 r////+//1v/1u/9V//71/1tkdXzqKt/9/v/pb/67t/6W4+Kq79Lv/tv0l3+rf0vfqrb9Lt+krv12 36S2/SVt+ltutJdtNJK2xFdsMIJYbSVsMJbYYSWwwkrDBhLbBkM1OrkQGyuUglWhe5JermcCDq6B gnXRDpA0rYRDPWKsQZOGnbhXq63q3V6vV0r1eFb71eFDpXq9Xq8KHq3V0FD1eFD1eFeoeFDEK1DC j+ACACAKZW5kc3RyZWFtDWVuZG9iag0xIDAgb2JqDTw8IA0vVHlwZSAvUGFnZSANL1BhcmVudCAz MCAwIFIgDS9SZXNvdXJjZXMgMiAwIFIgDS9Db250ZW50cyAzIDAgUiANL01lZGlhQm94IFsgMCAw IDYxMiA3OTIgXSANL0Nyb3BCb3ggWyAwIDAgNjEyIDc5MiBdIA0vUm90YXRlIDAgDT4+IA1lbmRv YmoNMiAwIG9iag08PCANL1Byb2NTZXQgWyAvUERGIC9UZXh0IF0gDS9Gb250IDw8IC9GMiA0OSAw IFIgL0YzIDQ2IDAgUiAvRjUgNTggMCBSIC9GNiA2OSAwIFIgL0YxMCA0IDAgUiAvRjExIDUgMCBS IA0vRjEyIDYgMCBSIC9GMTMgNyAwIFIgL0YxNCA4IDAgUiAvRjE1IDkgMCBSID4+IA0vRXh0R1N0 YXRlIDw8IC9HUzEgODAgMCBSID4+IA0+PiANZW5kb2JqDTMgMCBvYmoNPDwgL0xlbmd0aCA2Nzcz IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlID4+IA1zdHJlYW0NCkiJlFf9U9vMEZ6Q2LKxxwJj4yTQ9Jp+ zKkTK7o7fea3ACZxS4AB87aZ0B+EEUFvwWZsk7f5N/oXd/fuJMuEJHQYLOlOe/fc7rPPrhzyefn1 u2NGPk+XGUnJshC2F5BAcJsz4tihS7oes92QTJLli8VZT3h2xElXviWnPT+0g59Z+yHDy7fWgtm+ B8auzURm7NmC3zPricgO/IWtA8f2o59Y+0GEl2+ttwbLr3cFYWRwsRwRB/4i4ro2BxPG4OLAzPWy YzuOSwbDZYcMflumzLYGv4IdV3YMlpOm8sYL5YZFa7Ts4hoOR/tP9Phk60N/YDFGifw9sByb0zfW vwZ/y1EwDv5jdxeC3YnanDlqd7DE3Qc7y/TR0uMnpbKxAI7bkesH6gUJQchzwB0LFBjywer6dgAg PHqy/X7w1mKe7dMji9uC9o8lqNxHXYATki5M+dmKBcfwO46xfbWxOryf7cz9uRusbgCb9QekB/u6 AGP7PdF3WxZ4gB4PjrKZARkckIP9noTUGyyzCA4fgcdDOwJ8EQYdtvLz0Ga+5A7EHcgD7ztM+VJC YjyDJLjy7fbB/m7vqLe/3cOTdBk4JgT3dSEI+UHE/MSf6MH+ntX1AN3HDJUigBeEyEfuSkLeByoU tg+5BMzkrECULL7ibnil58I5l0IF4JdxOkzIgRXYHv1iRfCbTEj/kJzCTP/w1EKGCTukiYWHoMPL 0fhq/PmrRNt1AaoQGE+P3xNP8XOie55ve+J+mr+1OIcodpHcx5LoR3Jou0D9vqS+vN3DNxntLTJu MSsBLXrt25x0HwA1t1Uo2RwwywEzO6InCEQgKAee3qungyOy1z/WY/39d/ejZG5kR8EdmILnOzHN s1N6M0lHw/QmviLx7exyPCEX6WQ6O7UU78ARruIdQ/5l1GMSKN2F1+OrzHKKJnPiwRFC5N93iceA 1cg8Dtog5gIn/DlKnaBvyC6CArSf0y94ckGTEVBqFF8nMJiO0lkaX03JaDxTfPJt15WgBbAKQH+i 8XCY3Mzis6vk1HpF9mK52kV8nV59xQU51cu9Im8vLtKrNJ6l49Er0CQuYDJG33sUxkef5Q6Dvyqs 0RxrpLDG5+eTZDp9hbRyIUSJYtNVcnM5HsHyu/F/cM2IvrIwxiQenZPedZyCF5WlrY6AogX54Ebq BHdo5v2cZm4INlFBZRwZ/k/08Kh33NuXDAoV1UKqn/oH+/fzSS/pR1ALCqES8+MLdfz+6DwdxrOE oFvp+HZCbibJRTJJRqAOF8CXlwdWSCdAt0M4bDKaSUe/JOOJ3NgpRu1eNtCXh+PpDLSlaG+/BIaM YNGbq3iYXMMwSadkenv2azKckdkYnaVD5s6TgGt9GF7GQK//WgJVi5yn0+Ekkas+JBL+AyLBQZsC 5yEpv6WSPMvvIz28rZ+Jvvb+OfhhnKByhlEepblYMy3Wb29uJmPJw5Cm1xAulQVweqjx5DcLahij Y6WYk/OHUTL4uSNEJGzXy3ApL3yif+99BNmFzf+RKdzO8Y9OJ0IOTV6hI/o2onsp5HdMrjHXQK9p qvL3+vaajC9A4b4oNyZS9Mm/k6/qWR7co+OHHjl8wJF9ONJ36tLWUb+3S7b6B+9UPTq08PjvP35H 0r0I8rm4YN4DqNi6maSTXNNf36gkAdnSIp0JO2SZX5T1/5so3+cJlADodqEh8qEX9rJeWPDQ9vy8 GZ5Pc9+zoYkoNMM88mTv+mNz4fjYcN9nDvKPyzv4EeDKbgzN/ewrwMOyIxwP6xOaw7ybN+qyE8+a WuhYHB1SeQemwLsAiqsbFXol3YNVqqdQWGt1+PXwv94wDQt7ssaKuq7iPM4011rtJt6o8ZXGmrpZ gl9B1zvq6alybMN81ll73jHbncXVHsGvS031EixRazXzHdVCnfa62dhoPK935nu1zE29eqNWq5r1 trTCeRk8Bu0iKjxQA0ggSU9x8ne1Fw15pmptoS/sssAOXCENwtCZcynIuQShVFw6m84sUEI6gV8X airWxaEaIju3CdmJ1UMiZ97oNNDJFdrQiETzFrRQGHxXf0FADd5NzibQgwp6G6vrV0vgVwX03g5b TCwQSZARv7Dkt5ih/qN349EtFAUJOwXnefRGQnwodvjoC8Ii9nnW+loLCLTUH2IJ1lsA6+XaAi2N Fhe4Y5CSoAaB4+i2tzs/QbF1OpyMh1YX+EqT5BxkYKoeUAZnl2n2pF8Zj1Sl1gaQ4EiUFDq8s4Tc 3J5dZQaXyblsXOIv6hnaF2ytSAzF9jIh19jqc9gRhcde9AWWd4gjwI3w02GnkEHQhQC1INDynHhl LsMc9iNgY143vFymGNeRf9+DjzUOraYqoCEWUPmJKCsojm9nA9mL+zvkQ3Z7crx91LcY6Dw9zN/b OemRHf1GNtg7Jh9O8rXJVo/MN9IL5BvtfcQPWGDegZrIkPWOfuntqFy7E1MXtAikvXDauWt0pYHG O6ODk9cauPOxw4DfAIUTLOmjpcdPSuVyyaiUq6UnSpdQnryGWS1V8MaUv1Vjpboqb2rmalmNVMzq 6pJ812hKG6PaNNdKctZsttT7aol2tma5LjcxyqWlJy0VRs6B3KgjbuBLHVlVr/OmWdaba2MclNpo NqvrZkmNNqtGc7UGqAFESUmroSFUV4zmE4mi81T7JRNsrpzCCRQJSAxfBNqXqvLm+YF3yJzfN6pr RivTZasLDqRSnY1atTACvbqgRt1sb1Q3O0ZrY8MAFW6CUK80NjYapG4+/0MW0kILoDDwEKrnQiMe FYrG0wYouA/ZsqkudakvTXXJ5mQQYMfVdrvzQg01W3quLZuYjs4yf7Fp0AiwRnqFggW1Y9FtNlfq lDfa2JityvSvWrDZemPN6obQIkkkLf3QMTovX3Tazc6m0WwYMh7tajanWi4je3yOaENaV+VPDaqC tdJR5QkrUz7zrLMh88ilOJ71FS7HBOG+wI9bDtXY/c63pX7RgxrPCp7nnjpZq92G6tfY1AAQmkur 5ibEEQMe0DLEerPzogM/ZhM8r94wLOwFacWCxoT+ER88+uhPZSDCGupgSBsQC1hIL7KODKmv3QHv uXYAF8Gx7/gBdvfORwPXUUFfvVAVuyG3jYAz0KdShT2kRjasn1tWF7lkWozW/ywfkNDQQ1Nd+DFy vCPPCJTTxh0jy1BQjmaznq+uV5i3Mup9vUsboob8xam/3Dm562Ffxh1otvzFo3+Pt9ABuvfylt/H W/VBoaXPqFQrKGL8camGF0k8o6JGGmZ55fFqSaIsNVaatUpdzq+uqfX9rLmxpYIJVzfJD8bQKtdq csO23nEdL+sqjzslqV2NtlFZr1fKS41S+enCC6VnlbpZWgL1lu9pueVG23wuLTfw53F5XW6xVEc8 jlRarnDSdnmpruY6qKZ8afXO+v9jvUqWG0eOaBBgAVCgAgQXgGSLaqm1NdAS1cRKYMb2eNrhi68e n0b/4d93boWFouQ5zIUs1JrLy8yXnd9R/TgGuHvWBYlFhsrBfnRQ0TXRzPIi1mMsOb782zd4jx6x HC0mvfBIREtt4J7YdWIyfEVXu1NWC8cBKr/1bFv1Z3E+wgurmH2Cl5iH4t4ipGGOUijPUnrmBSqY +rETeKH/Z7lxtwg0RUekAwMasW0Oj5IYTngxY7PwtK20oyK7cxqAEY6QPaYgZqdjHFM5y6OZuOit G2U36xzamoAymhxA48/S+cohWV1L0GUAFDk+YciaDrWjGfIWqj1yT4e8cGF7wWwUdG90Zfk2JmTJ tUZV7ZEoqHwfq7ktCmfFeY3/mIPj2GZoW1qQyCgEPHobj/EH756A0qi8mHJy8RDAyu7zDIueW+rz tdoB+u23zr25vv5yWoUbYHDSJpB4j2MVoNB3G4ZaqFuDNBY76iLjfdEHusYkeCTKWsbsd/cPt+qR crwKPG3cBlUvKyCdnwHqVmBRfcWHbz6z6go1VexSiWPWTm2322UQk5WXjnvxybM2zidPA9I+nVjm DK1qwRrD2p41XB/vVp+xUmXMQI7JEutai7UbWEPydb3V6xshS8au46rTQGUaXixGfk0cDnjgYV0Q q5l3MXtNv4WESE9TrG+65Mq25hxsM6qHGUUCRHQtWRhoOOsW7DuAAVU0KmlUjm1N8TABdjiCx94c HbhmqMFJien8T6Jekhu2DIJFl6lWb9VRK8K2B5dgej+tEFz3PD3IauBxliMnOfrqtDxxc/FS1exn GhXQQAFZrssTGmcI6oRkRAZyRNqVHpJoYThNGMi0sRqTGJdq3PAYcH064J6C4qVkzNHAiJID5TaM BCQpWJAd2DItoEXAy0Pk7gXwLdAhcejXTfGloN/DE2RNmrt7TZ6AkrWQtEogWc9X8Fcke1jLofUr Et51i+SqTZ5XaYacn/d+h6VMTu8Q8mXCp2X3wbCw4pgh/6rz6iU73mRZ+5I3Jwx0pHIJEdaMVR54 8fcEE37ANgw51DA3C3A8Nuc+a16qshRIQnAZTBOPzZEzQneRYqdAV2H/k2Or1a9CoPCKgm1F0kNz HvJfv5XP0mwoh4DWoLEyOS1HH/u2Kt2XsLpAKPvKdqJzt83VYFZ9f9pnpBzn8yznAoa4lPZinNcA DS2AM0OOjikOnNMmmOfAcQ0S5hwWHB9ea4CyCwglGcAT+cuhaPrejF8ItB/a1txhPfzQlZHyQ7Xw l9OpEpjnPpnS91DPOrFX/jJauvPlAuqyv56rJWUxf7qxbR4ZASoJSejGmmPxDsueWA5GMFL8luKj ampMocDbD80pxTc6jVFW5YjDFo8eIe+awDKK+naKbYX2VxvFiMqh62oBx0NE4QGxvbbJ3vM5/28h /H0erlcuD4iSfzoJ97EzuT6NGNUB9Wkz0OIsuciKdsQvJEUpQB8cw2BEPV5TCEoM0Rwjpk52D3uz w1Aq3AiwmA3mZW4RcAum3cE+9Ct0ciptGkCr7DDAbjjn89bBKUq/4D8+hO0jtLyZfP6xB2WpkP++ iqct6ClXAUcWLSAzlVCa0xqUfngwsyRHqU2GqoojgaiCpHG8KZqX5sMEVUAma3A7Oq7PyYeSTV9h TwFV/yhRjASgSazIIbI+79Ki3FJCF1vclPBo+eGjRzBrNXqUHS6loMYnmwTTiTFahakkWfLCQ34/ eQIQYNJ+TWDQsnWyGsR8Hiyg2BmiBDMfnsRLHB4yD8E9Fede9m7Fq26KKY3KMqXiWHenRB4kHTiD rRkVPw4tKAx1WQ9xPrQnbKb7Akw1TSJ/Hj7fJpxm0fH7poGqh3Mb/pg6ocsjFqAUZNUDZJWMrAKR tebNmH6PyUzUgok7DplwcSTVyGQlbNujBRXGFS7bZMIK5aJ/KzXBxbf4oXma7udJo0Rkh/N+q4Mp jmUhMchIyF4HRXDj2LazlSoDDlOSVqQpgdReNdSWNJBGjUVzoqrJv//z41///Mdv40xSAvFp6yH7 y8YkCWlvNUo14h93kiLttSAAywQlxy/HdV8h63zbcPV6QkUL2TMHQH3lQ56IbbpHCMAmLxAJndzn G8iTtJeJWYAX5jsuOQ+AxjzZQ9V2OQqrLh5xpNj0EX6VicN5hJfAUQ3MYS8xlWXmGYAnhg0CYCHb DJRwTm4DMuJ0pXoM6ly6hdekuQVylSClIkJVJ8/t7dMVhdCOEUd8K8FtMMd7fhJOloF6Daj3jBO8 9ES4ynevsiSXduAx70L0YlVAMrBKkao0z5P95OohRclv79Tu+aB4YQL5uUny/PszL/LsDsOllIt4 YfI8giipaEb/xdbo/iFFlnDLpGet7peTpfrZKdWX67X6mYqCLVhugcBmUg38tXrcKfWXv97c/A0r WJtAR3etvt/tzHtw98yL4+6s2s3nSHyYYwXsFfnLKCLhyetraA31TN3p5f9/HR//pXsSICgRthcM Dv1LeqPKH+F1GMUA1592f1eORcEfOfEUyS2aqwLf3XLJMyQQYPX51+tPv/5gW8CGLz9+/KJQyyNn ZuKLpphjKTdDKqh9OaVimugeoU2eN0Y2qIBM9fCuOBW+mhNXdpnTdt86lZqfUQYswcpTGtekwNLY zPRZ8BK3WTiQ1qaEQtkMWptSCtodPF0l1ENd0m0aH2dNUyxasUxAc8V7g7RKRlsjQucVSdFyKe1e zYEnHAd1tA9MSOAZKL3CWIbbLyjrL4k/ZYn+vIAeCmvk7mJtRikWwpVwFwjDKllzdavLxAd7lKRG ZU6iSut+jAQhWXQPRItLGCI3v5I9gWkd12bTFh4pk/Xu8YRMQlGvm2GKNi1TesRi9chZmIoKlxZX VqQ/4Y/IsTa0SKCKuhK05+sR8fkJLf89uXTs0OdLWuwZt/yWhx0qTSwGi3G4sL1gxj3OYBnYy2AX RAcPUP+NFnlpxshLH76gvtIQxWuZpLZC867mQHtyKwwiF2hJQFNuaNH/oMhyuj7UVHmgsnnBV6gT 5YGIRUbEAj6Y38GAZIY34asitaj2F0iN4L8GLPD3KTcIZN0YAO9Cyor/Oj0Y8jFuyeBEWYNkh0Ev S82QcqDXoIQFQEL/2Wh6QJL5xtsmwewEKzXQzqI4A5YlCUJs0LAg+nSEAGnvcjS9MSPN7868QDom aDjeQUvs2F6EJAc6KUCyF8gQPOt0s2Rebfwuk5SWXCOBnJkNPsuz+EWDE6HN6xqi2niKEyI5xZUp 7UUedS+WDror6XvefZ48SCJGM8vDt3L7LZQG9gXpfD+0PD2l7KwVAdWlBLFUL8hZI0fYMW3wHEuB fXAcx6RS5HXYnqsF32PbyzFdO5triyPwm6JrWKR1hXLSQq4m1rS6dIOle0dWXqxhtKRUtp4tVgsN WbYF8GJ2PEXTSXotasidRd+kiNsfrEC7YYQ6cQxuOEtgpMPXhDS2aWwsDsN7JzAggC+2AQloaWMh vu3DnON1LHvezdAp7hPkyVDPHHfgQAwRygVfPQ2BQQiRvx3lBHjLiC0i9+K+Iyo5nCXL3kiWGckY jO9lgzx/yY4mfN/JBpgxBskgEyCfyQV7c925aDWuIJG/hR6LjpNqlFUNAKuPAJi3QIX6Ys/dKyTa yYXjkNQW5+xJoGZuOB/TqFOQQT0qs0ENNzCTxBVIkGYFmrLLCn3om7RgyRS3md2JIZxkih0a2lpm Ss7bvLgJbfs1HdmkWyPvehrqW0p3XFK/sTUFgDd1NTTo+e24VEqh+KhOADX6H+PVtqO4EUQVg42J rTY22EwGMrM7MFojLSwY2wxSEmmU7B/kbff/v2Pr2m4bouyT3dXV96pT55z/JzAIrbvAqIXT3S0S l0u/SJyUUTh7ABTDJqEf704Sr+Eynlo0TsUGoiyYTRNtdWeBset0RRO5xAMUD0JpLyO/lxZ25R0d NNeSy0V1S626nARTytVoTpUACsFix3kfWcCVB8LfdKxuQ/rAVieR2dBLkVStVCHtAIom28rplAWD uYM7lX0+e+2opLgKjLjQYIGS3IxmJvYzG+9IGmdZFMZxF2ACK/z3Asf2phhYasnGvtzihz99ZJvV GFTS88e5vwBZAqGToKq9RUYnKo68RymOgzzgDRj5QY+6YDrhAh9W/1OH3HSPI30Ow55AEn3Kiryr j54f34dJkCRNLxuGyTCKEWP26tjdfQ//KDV6WFQdjoOJIaZ6Ffh4aJ3EOYus+gykjKroHhVKtvwo lJ5gCevrL+jwhhzyAvWYzBimIGGBMPabU07hrDAoDE7qvGazWTLE4XLSk5jMriNzZNkyWUt3Vizh pxH/BsEvIi3yVmqHfjNSSRfkfNB/BT5Aaz7u9m/dcrprnT8Sw56PCHNV7hGZNB5afQc3wiq5vieS QKUlJSi64BCxwbK9P1c4IRzD/ueFuIAkBDjg0bY3ks7fHX9DYdbNkDBbP9GR8c2w56x3gAZ1oI62 fBLNihfTMDcs7u5NFp8Cj7jqIx7Lg4W946AcnwV76Rr7wrRmYbpvr/gmif6hGK1KWpLaAJRVaRKM Lbr9UkdTI8mt429mJQ+Lu2vKaDlUmqB1r/8pH4Bjv5VbAivCVaO2AnCH1dFF1FEtUN2KOmrlOi+d OqKRLtaSIfSorNQ9r9CTgiHbc8JIaqFFk5SFG9QVXJM4NbC08CHMrTWFs3NVIfaWWRAy1oW5mzvV 6+fN9mWxtO1FEAmwFl2ZaiRkPDHxUeyYLVPLmVkOTMnYhLm5Gx1amdcZcGwqLTEOJ6a7oLuMRJ8Q 2R24geWVqdfEU1h1nKkjMKSLcn6Fu3Moa6dVX+WFbosG4vymd+Uy0KnpvPp2EuTyYg1es/kZmVOd Wvg4xLA+891sMOUw6K8oLxGFIHFy/FaQQGjmrEQ4w39xwayAzyeUSCfMFfR/RICGYZBizJ7EWWan aXQJ8jHYaHVqmfNLb85hlg0IbwWRUF/vEN41yRZmrqJWEY+B2aZqywMrb4zW/M5PM8sOz3OhbSkz fWY0s5xNZhwVgQlnkQ6h7mko4UA1WXoe9PXmHaclZJjEYR4WymO46gvjToKOJlTMYTzLEKTOM8np 9lFhkmj4UWfBJObOMCTqKuLoRqRxe4phpn3rziNLRrJKx+9M4OyGrxcom7oge+mcxdOENQiHwIuT pXR6gbcKYsIVu0wTZYymSVgMheKG6+/29UV7HnQmkhs08DYRBRRpXtiZRMHlCsDP2+N/d3W1Nbdb 4o5QQS0XkBtJKMyEk6e3OGgsXe/zN0hkyIVb+bFKAFQRgThg/OWugQlH3oLuvJ9E9aGqeQqULXtB KSc/wJInQSi4hk1i7PDtbvVvI/QElmsHDP1b+U8wY9gcmXZO9/6GIhTpriiAB7k7aqaBFBF56liH yL5OEjAkzJAS048RwTZLGTfFvKYixYk9F9sRPahmhSPjW4GnBdQutmIXKm6jAe+45fcsP1DTDlUb G6Bi7EwYu6a7uEA9dAjzyY6d6B8JEfrLA0+AKu4BFkWKaj7tCsWuQ6bCJnSyDaUG/1cIupSfTlCz F7VWHAtGrV28xPdLL5UXJUGogYa5cUZeDEyxoJo3DybTryBBfC5yI//p/fnx/a/377unD388z3WN 0+FYgejVMCN5VZLI+Prvrz8GAMiGRcsKZW5kc3RyZWFtDWVuZG9iag00IDAgb2JqDTw8IA0vVHlw ZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDEgDS9MYXN0Q2hhciA0NyANL1dp ZHRocyBbIDQwMCA2OTMgNDY3IDQ2NyA0MDAgMjY3IDI1MyA1MTQgNTUwIDU1MCA4NDQgMjg0IDQx MyA1MjMgNTUwIDMwMyA2NjEgDTMxMiAzMzkgNDc3IDQ2OCA1NTAgNDY4IDY3OSA0NTggNTQyIDI1 NyA1NTAgNDY4IDU1MCA2NjAgNzEwIDI2MCANNTA3IDYxMyA3MDcgNDY3IDI2NyA3MDAgOTEyIDc5 NyA3NTkgODYxIDg0MCA1MzMgMjgwIDYxMSBdIA0vRW5jb2RpbmcgMjIgMCBSIA0vQmFzZUZvbnQg L0VFRkZCRCtHYXJhbW9uZC5Cb2xkMDc1IA0vRm9udERlc2NyaXB0b3IgMTAgMCBSIA0+PiANZW5k b2JqDTUgMCBvYmoNPDwgDS9UeXBlIC9Gb250IA0vU3VidHlwZSAvVHlwZTEgDS9GaXJzdENoYXIg MSANL0xhc3RDaGFyIDI0IA0vV2lkdGhzIFsgNzI2IDY2NyA2NjcgMTAwMCAzMzMgNjA3IDY2NyA2 NjcgMzMzIDY2NyAzMzMgNjA3IDQ0MCA2NjcgNjY3IDM5MyANNjY3IDQ0MCA2NjcgMzMzIDY2NyAz OTMgMzkzIDMzMyBdIA0vRW5jb2RpbmcgMjMgMCBSIA0vQmFzZUZvbnQgL0VFRkZJRCtBcmlhbC5C bGFjazA4NCANL0ZvbnREZXNjcmlwdG9yIDEyIDAgUiANPj4gDWVuZG9iag02IDAgb2JqDTw8IA0v VHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDEgDS9MYXN0Q2hhciA2OSAN L1dpZHRocyBbIDc4NyA1MDcgMjI3IDQxNCAyNTMgNTA3IDMzMyAyMjcgNDUzIDQwMCA3NzMgMjkz IDQxNCAzNjAgNTA3IDQ5MyA1MDcgDTUwNyAyMTMgNjQwIDQxNCA1MDcgMjEzIDMyMCA2NjcgNTA3 IDQ2NyA2ODAgNzczIDQ2NyA0NjcgNDY3IDQ2NyANNjUzIDQ4MCA1NjAgMzYwIDg4MCA0NjcgNjEz IDMwNyA0OTMgNjIwIDc3MiA1NzAgNjU4IDcwOSA3NzIgMjE1IA04MzUgOTEyIDQ1NiAyOTEgMjkx IDIyOCA3NTkgNjg0IDU1NyA2MjAgNDY4IDQ2OCA0NjggNDY4IDY5NiA0NjggDTQ2OCAxNzMgMzMz IDIxMyBdIA0vRW5jb2RpbmcgMjQgMCBSIA0vQmFzZUZvbnQgL0VFRkZNQytHYXJhbW9uZDA3NSAN L0ZvbnREZXNjcmlwdG9yIDE0IDAgUiANPj4gDWVuZG9iag03IDAgb2JqDTw8IA0vVHlwZSAvRm9u dCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDEgDS9MYXN0Q2hhciAxIA0vV2lkdGhzIFsg NjgwIF0gDS9FbmNvZGluZyAyNSAwIFIgDS9CYXNlRm9udCAvRUVGRlBHK1dQLlR5cG9ncmFwaGlj U3ltYm9sc2IwNzUgDS9Gb250RGVzY3JpcHRvciAxNiAwIFIgDT4+IA1lbmRvYmoNOCAwIG9iag08 PCANL1R5cGUgL0ZvbnQgDS9TdWJ0eXBlIC9UeXBlMSANL0ZpcnN0Q2hhciAxIA0vTGFzdENoYXIg MjggDS9XaWR0aHMgWyA1MzMgMzA3IDM2MCAyNjcgMjkzIDQwMCAyMjcgNDI3IDMyMCAyOTMgMjUz IDIxMyA1MDcgMzIwIDY5MyA4ODYgMjE1IA00MDUgNDA1IDI1MyAzNDIgMjE1IDQwNSA0MTggNTMy IDIxNSA2ODAgNjI2IF0gDS9FbmNvZGluZyAyNiAwIFIgDS9CYXNlRm9udCAvRUVGR0NLK0dhcmFt b25kLkl0YWxpYzA3NSANL0ZvbnREZXNjcmlwdG9yIDE4IDAgUiANPj4gDWVuZG9iag05IDAgb2Jq DTw8IA0vVHlwZSAvRm9udCANL1N1YnR5cGUgL1R5cGUxIA0vRmlyc3RDaGFyIDEgDS9MYXN0Q2hh ciAxNyANL1dpZHRocyBbIDUxOSA1NTcgMjY2IDQ2OCAyNTMgNDY4IDYxMSAzNDQgNDY3IDU1NiAy NzggNTQ0IDQxMSAzMDAgNTExIDQwMCA3MTEgDV0gDS9FbmNvZGluZyAyNyAwIFIgDS9CYXNlRm9u dCAvRUVGR0ZPK0dhcmFtb25kLkJvbGRpMDc5IA0vRm9udERlc2NyaXB0b3IgMjAgMCBSIA0+PiAN ZW5kb2JqDTEwIDAgb2JqDTw8IA0vVHlwZSAvRm9udERlc2NyaXB0b3IgDS9Bc2NlbnQgMCANL0Nh cEhlaWdodCAwIA0vRGVzY2VudCAwIA0vRmxhZ3MgNCANL0ZvbnRCQm94IFsgLTE0NiAtMjU0IDEw MTQgOTA5IF0gDS9Gb250TmFtZSAvRUVGRkJEK0dhcmFtb25kLkJvbGQwNzUgDS9JdGFsaWNBbmds ZSAwIA0vU3RlbVYgMCANL0NoYXJTZXQgKC9HNTUvRzg4L0c4MC9HNzIvRzg5L0c1Ni9HMTUvRzgx L0c3My9HNDAvRzQ4L0c5MC9HODIvRzQ5L0c3NC9HNDEvRzkxL0c4M1wNL0cxNy9HNzUvRzUwL0c5 Mi9HNTEvRzc2L0c0My9HNjgvRzEwL0c2MC9HMTkvRzg1L0c0NC9HOTMvRzMvRzY5L0czNi9HMjAv XA1HODYvRzUzL0c3OC9HNzAvRzI5L0cyMS9HNTQvRzg3L0c3OS9HMzgvRzcxKQ0vRm9udEZpbGUz IDExIDAgUiANPj4gDWVuZG9iag0xMSAwIG9iag08PCAvRmlsdGVyIC9GbGF0ZURlY29kZSAvTGVu Z3RoIDEyNzk4IC9TdWJ0eXBlIC9UeXBlMUMgPj4gDXN0cmVhbQ0KSIlkVGtQE1kazRXodCkiPmCk wWYWHcUXJpCQxN11GRTb8bnO6oCgvCGGZwKE8EiAQAh0OuHRJCGJeQAhCQQjolFAGKV0VBgfOLqz Uzs17m7Nn1mrLGu35kfHbXZnw1TN/tk/t+4996vzfXXOuRcwQtcwAABbMzKOHk0/shcrqCmorK4q Tkqvrihm8bird+mB42sCJ0ICW0LppPCQf4aHBk6GR9MLK7Y4eFsc82gYOsQ41q78iSD+twlnUu8i A5EbAtUb++O4tzcxkgEIZa5dH7k5OiYuPuGjxL1JbA7v4G/TDh/95OSZT89n5eQWFJWKKqprpA3N LUpVl0bn8n2OcbkYn4/xWRgvGeMLMG4qxg4ibIyXgnFYGIePCVgYPxnjCDAeB+OwMQEb46dgbB7G 42JcFiZIxrjB4lSMk4Kl8jE2C0tlYWwBxudiHA4mSMGCsABLScWSgzSpGDcF4/ExHgtLFmDJbIzL wfhBpmBBEGSfqq6qrmsUl+Ttz/tForxViX45/J9uDBAZwljL2MDYyNi8ZhtjB2MnIxHsBawQbshv GEfg02HnYQbwgGGgA2bgBF5wHUyCceAHfcAIHMAF+oEeXAE2cBVMgS6gBSNgCIyBa+AW0IBeYAAW YAc+cBPgoAcMABMYBRPgBugGBCDBILACN4MVdJYRymAyDjHuAgb4+5pHIVdD08LSIMDsgn9axwmH 1/s37I5M2MjdNLl5YcuP0fs+eLL1PRKJLMbt2rYdzf0w6VeKhBPbZ3Zk7kzZVZ+4b7dmT/Ne477j +6VJpQe+Yxcm+1Jk//FGrDgjViqp795nRwmgA4F1YW0zndO3kRsW35gXHXP7rvi1tzWTijExPF5l vlyMVKpy5WdRzsr6sIiV7tf0ZJSur6enp7dXayZHDHNWv8c7Cft8lgkfYlVfUQ6iSkO15eJwzkiF Q26Hm60drglkKsg9FuS+ab6jfai5J5nOgWezh88cRgpUhfJcVJHXWFInlolFZTmXlaqS+k9EcHdb B66MbevoIdvjO8nWIYUPJpjB/tRVyhU1jU+1eKtXx6sUITntQpkULSorbsyJzROaPFXxYrf8+gzi 7neZnajBOmQbd5rJoT63bpWBff/9lqhXfQ/I26jj7dAr6+z4su++f9rvn5245xwf9JP3dIv4ovRh /uO8hYzZRHgucZjeSCcidFjrdvFeVH667lxldlWWRCRrLBMJxYVNcENheYck9sin/ebS+BJz6ahw SjRZNid+KH5Q/6DlC7j5Zcf3/0AIJoXTMVH07v5EQxZq+Mxe7K4dE3tbvTof7iaHrU6L3WXxWX2G ++Q38CAV3ve3+wgVw6QSmE/US8qHqPKBwt/kaRppsNcapHppn1QnwataK2ora6S5iuOw4oSKDqFZ yBFmBnFBHOwWQcsC2+PC4qN6cScxrYN90DJUSzR3dBHKJiUhPIvQe5j7mf8+wDzHlPbLB1Sooc3V 6e+ydk+o51Rwr5JoVyNKor5LjBZAFfnEWVEtoZCfIRLalERHbCNUCVVDWZCqhaiPtWjMg6TWNIS4 +sbIiYE5/ZjBYICN+j6zFcGf6V6FUXuYN5i9hP2albhiIQnXHeQ+00+4DAOE0YCMMp8zvcxBwuYc Itw+JKf0D8ITok51heKcVDassKtMX0/Nj7kc02OzN+/Oj9jdExMzP7v4r5BomgHV1RMKaQvRGZsB NULNMqJWWkyck8gJdex2iD4IHV+E3lHhX/91/s7nc199+wMV+vRPt547F2Hn48GFWWROdUvuRxU3 a8ZLnKUjhcZcXR5e3CasE9VKxE3lkkx5ljoLFkBuwuVAnrqezn+JfvuGWjNH7dBR6/A3ouVj8AvM x0sMRrhEIUKbsmT5YpFEeDiNhmmIz03YRW+iw2AqBKJO6igG/hC/TtrMMbZBq/fKfI+BtOpd8JeQ CepVadXdiEKj6JKj3U3dkk5hd2nrx00f/px2A7XhfUGUrd9hdKJGp83utIyaRwc82inNhMJTDXsq TaJiJLdFVF2LiiWlLTlatUZN4D3Ftjpjx0CzscXa7oDbHWq7bTV/8SvlUfO4v8FbCttkerEIudxV 096GNlXLZBI5rGys6bocK6wweSTxEpfC50c8/S7TMGpyOOxum4kc6nH9/H6oxw2aqCWmSTfU6yXn 9V69YcBImuyWcepS4M5Wqu19rEvjJJzamAVooIH63cqhGweupXhTY8ZT3RkjmaYy6wXnSaPQnuvM NFfqm/q7B1sdKjfuVntU3la4t16r6EDUhEqjQrPPE2d+f564+FkJURtLH4JyILvWoXWgVKjLR9rJ 3r4Ysr9Xb0BIjUFtRAt/FFAlYSsRkFxYyb9ER8MtxSpJK9LY16JXoRbFuPKWmsSd6ptdsLaWkKsQ FaHqVqFFe7R9dFJ8UXcYnnNJkx8MdqAw8CSKSsbf4B7dqHar7LHkZdlfyl9Llupn6F0rO7dGUG/j QpfiwpAofZ3ttCsRNl4kL2QjbOjUu+MvsZljt9NGBNqdGkH+CR7Mo5n5NIfOR+hwkmvJRkcE3mPX Mj1Fk+Uz9Y/KFuXPtK80Xw0/v7M88+TF4g/OnomeKR0uVos7JZo2Vb4iHe6obLlYVH5Welge05zO UtGM2IOHSGt6fLr5lCvzWtr8mYX8RwVflD+pX4brl9u++R6hCp5Rh6hoCkFXF+rXz6lc7WvNn9V/ VL3qeNG6pFg1MPDR69V/4Tp+lXDr7uKPiWWdE18i3uqoXTj1AUGt1cFUxn85LtfYKK4rjqtqdu6U NE3UAN2dpbvK4wMQpFgl0FKJChKIozQiIPFSUkyh1MZgjNde7669u7Mz+5idO2fu7Gtmd9a7Xntt 7DgGYnAM1DxEcaEY0sQqSGkNdVokgiqhplK/TKJL1Y7zYe5II83VOf9z7u/8LzOFb0j34myZz4YC HN2HDiEJpCTXhmWchGjGlSyJA9GxX/3VGRrznWyd6M0E1eOZJA5CC9mG34TXyQa8Cd4iLAlAI32a o1sQdaFqugImsZbiR+RadkY7mS8XyzmjYtTz5dLF2oOC6jzPaNtgX/sbsC8YgIgYgPZDB6G9l+ve hdIFqZ6YiN6KnYlVk0akGMjxmb1aA3kBb4SdhA1CLL0eGndyNIg6jFA16RnrfZC0XiKP8f38Z9Vp fWr49OTF6bNz4w/ZgQpRTa+SL0HZjUM4qoipNucxuiNKWQf+dSt0tqwEuo4+Rd1A125cBZR1H2To 0wuMQeraqexsfsoYrrBVODFuQG2MG0dfP4MsB7Je+3Z9DhHI45InlY1nYxqbTBBN8Lbmj2aPZEQc IxGNvWcfo4OPln+Cymo9O54fz36ojxerJWf2hDo2zuWQlUBfIdlaqVlbBetf8Xybvrvg4ntyepfX X3Zcs5zoPraWgPUqmcd/gweE7WeuMAPMFGM1Mlgvguk2i0BK3ky3FlJDLN2GupVIKu7xp3uUmBpT RBIvpEmyGhs7fsc/FSwHzV35tYSuSDu3y01yayohi3I0zaZ75UAXR59H9GW0mTSFOSmbw5p7jrEQ M6J8rF0tnNHqmYJeKRTNXDVfzn2sfUIUAypqUcmDprKK3gdDbomucxzGx2S/R/M7SALea+ASYCvh iaZFJW4jK6J251LF1EBiJHo1fDJktPet1unP1G6lXW6TWftpbeY0Oqduz7XogisbH0icTlQU57Bc T1dTg5JTC6tCiouDKNs0swcTXc5EG4H+4EgbHHUr7/sg7f5NB6hRr9393xyYX15TR8gpj/W9eoVU sgOGS7d0x5cwd9EeRiNwx3LYBX2AHqIL6IxyMTnj0RQ9bXqktEqS3lQStJS3U/NlO7RIxhnm1azo NRUjx2VVI2N6zFxNGyJ1XAWd3Mc3YJKwuL8fqu7+PiCmt46vwhekD5ehQk7gWroisoS34+YEHJN5 D32t3SEmkqLANaMw2o9aUQKJNqg4uhTx9kSWIBbmQRA5AbqUFo9U68Om23pRcdxlrM3Y+gUZwsNk OOcahJlHHJm2v6TvYE3SUnlXoLi/760aKwjZvOglI+qgZv9cAI2wj5lbeBZukTIuQcE++z9kTFwE w4bCCajb4Q8MKyPudvAFuW3RQ2JQCqWCiVBcDjjDCPtI1BEGUeJ86Cj0KotxrkaYLnUcIe82cPRF RL+P/NDRxpUlUy7h29GL/Eme3Yh8UUi2t8CBPeuALtnzJqx3JwTI8d5TMFTh7vR/bjoKhpYrerUZ 7Z/WjzjloUOdgPNXuS4f0dq9T/YyCSZBHFi2J4U7rESAV9kORhEiOOxWNzqiKAi8xNF5+x3q4XTJ 4rpyUhZniEuX8+mszGrhRdFFLNii+0MQ5u0tbHVTbrqCOdIEO9wBxhcG6dA7sM79rZdaWH4blTND 2XFj2jhdGiqzZi0/Nslh6xliRRwzyHLBXJ6z3OgPyGLReZSVjXTV0156T38zG8ExEAm7YF1CZ3Hd 1ngKfwYPbfSO2zBko5BIxmxvxXUIR8WWZEuiLdmVZOUg9rVxx0gX6fVgyuKfvMvRuq3sjwnd7ziE kiROEp4L4mTqtJJP1+WJNGsDOCJwKRAU3hO3GS3ZpQtGQU4lICrugw1u+kvm8G7Y2nQMoos5fXPr 8nJtfr5wpTI44urrK57LzbGWhaz/ohqYee7f0k2h4hGrBypbKj1aVBOzLLadnsmdQqPjKpnwWn9i CthYzOAyY7YUAqp8qvHMz881mD6ntZZ+qcXzfI53FX0lvxHQ/aVu02f6in4jpFeM/sLgB7MjfxyZ +d2jm9bLf7F2m2O16Q9uj832faRl2FzG1KpqQbExpk3gc3DJTuTuDTjnvjAMJOvF+YKiu4ltQ2VO Pu5IQELktgvvR5p72c4IHw5yUURnURvQFyjZDlt+ykNC4no0IZ/25FLXe6zvHGUjIKZ7IBzheprg jS2N8M4rr0KDEAPenZkf1Sf0C7rrZGZQL5isYYcwOwgDtT/DV9YyzvofugwTdY4OPPkiGYmH+E5X 7+G4PynspM83r/a/LYUSAd7H7mB2WmvCk76bh/7u8k/3TPIfpgy7HwrCsFPDGUXz0FXW5w3WHseT NkSvoz1GcyXg6fef6bnOnxecG9FvD0LT/h3weuTtxcmzWKv1Cyue+nSZtOBYYEaZs6Oglr1Kbgg+ chfTOciRHK7Badvj14BkvItVKZHHr8xvuNl4q9HqoImvn32yhh1ebMxP4fdTk3Bp5hpcmf4HXO3j pqRRwfDw5TZjr96idei9JXYBjapWs+KwYkzVBlWZqBucEbE31Ss3xTqTSaUlEIrJMisJ6RifJIv2 +/iBVbBpVwCCtlP4D+qE3jhHn0V77atFO0Rkbjddieh3redo0JLpWmszZa1lm+5tvbvttouusVY6 niyxGdHVxf2f5DINbuI843hpK+1OmybpFLfWyrMmE9J2aJlmoGEKaQcbPHFDgGAw4GBjbMuXsC1L lnVY923tvvuuVqcleZFl5EO+bYGFD4w5jHEwlHZIIFx12w/N0KZpO5lmYbYfuna/7Med2Wf/z/P7 /fcj/I+QEvDhIYzSQSt0US6fnbGm7Jddj4WtFTSPoHfn1hMi7QEA+U35P36fIOX5hFwvnHe3FdLm /BgRj/lhVxJjYZyKCLGhY2SP9CoxTIcjaNgfSE1h8D9gNYUtIZB73MmdET3wXnOM4kTME7HHDCkd 2x6zBOTB0tiGJ6199XJXzh+714b/gqdujSxlF6cXFmdWLt7O3EnfSdxlPwk9hRxOcK8o/3ny36VP im7uQB/yr0wJZXEzxpd9wL/Lb+bzcH6LUAPee5/vkJaeoIOn8uuZs0Fl+KO4IuRiii4enT4zU3Wp bqFp2TjUsaRdQy1XnCufCLL+cveL3+WUkMdNlarTCrlCc7a2pPWw8QBqLHa+ux37kK6mNTi0Cy7R 4S8LNATb079Mnozoko3D8szZpD5tzFgyxoxrEj4g7nWvTKyOLCxnnqGZp+zXnARb9D5wPhfgQdKd cXevRM19q2Jt/82i5R3pLdSG4dcLafs051OEMxBfQdGU4IIrYA3OC/cqAp8RH3suOm6bLmumFFPN Q2cGS9GBY7GyCoz/bsO2wkJ8X8EvGngRrCfq/PKwPCjvbu5BO1lycBLzslFBt2JCOsPwJjHPTo2h Vy/23fsHds9+QzODa6fb0s1sTbI8XAbLiQanTrADr8PrCv5Xk+utpSpFwsqbDdiv1j2S34moYTNs wLkDbSKfnjK7MatQoAy4Qbi02npQcuwAKNj9a1Bg1YFWKSnwNuyD/hh2J3EpnImPJiX+BEywDAiE e0D6AsZNIJzwtdvAsyjmTTi6rV32sDag9B8P1QUNgY0s5H4xl8P6+5hxZgwOBQciqC9KhYMYHQIj tzCSc1DcZtGXyBLyGbj/e4x7C/yNzOLHoqIyOWQM+TMIFRqlh+AAlMSJITArjLJ/nbyLYu418UPB 4NYgJyW+bnxShD7el9nzNlakPniqFC8/WlC1VRkyRQxRw1BVSs4quT38udzZwsHquDVmGbBOm8bN fTbWjvod6x3SDTpJL94q1pEnKFGNWKMEzdK3xG41kHWYgE3asNo6r5u09UtaPi77VyH3RstdzaRV eHdToFIwNauWbJFqQHsbxusRki9lzUl7v1syZ82YRs2omjR47bjNAbxSGSni8d2UymQFTikvEdfW A7m0SkwIyufHfHSQjuAAeXH85U9zhr29IEZx3yAfJGez6Ez2/NJ9LOu5YM3gtox5yNDT3teUrOtu DZ1mDkEFoSK1XlSHCM6wC+HFiBxUn8JakFf9L5/niV7PCbQxDUwFGt5PH63FzKSl0yxA7j3GBls+ b7rdNCY5ceNgeh9VTJbqZDJUJtOeKsHKEqcnK/Gpiicy7tXGactl3bJquXW2dbjlUnVaxtaj3bWB ilLsA+th9RHc2qRtblXqtE1t1aoq5RnDaStqPX3EXSStKPFHD+Tz3xs9G2gPOkISgur0ExE0ggTA 7J+yYCiBZZDncLigpypkkiQbe5UpXUo7ZByzjlkm3BeocTITmGaz8bH+vgm0fzx6IYtd1s3VzODt fYUT/Pdn+Ndn3rlQPl4xXjfXegtVLpuXljBuU+b5Z4/wRw85JMNto0bJefeqPeNaNK/qN6L4HU6c J1Ll3BEzNp+HIpONMU3YGSRmwBN4WXgKxpkQc6iYU4q5RfGNQIgJsqEBCU3DEB1DM+IAERLwgJ4E Rdsxajt5QqQDxk473kF0ABM0DOiy2hu669YRT8AVsgVstJEugvwPoIFQEwoSbSY1Rox/E+HvIPxf ER5HTjKNfjXe5Up6hgm/t9897+x1JTxxL8qoodGLuQRKO3CzsJW/PQbKy3cB/jV9Cfh5nRrYpQEg BOY84kdi51LRyfDt7mw8xaJMF82mMN8axeVxR7AXP0G4TeQ9TwpnBG3z4Z20B7qgjiqGPAoPElVO jVmhrjxc8jODwmp2wfaEmXXFe2fSn09xW7omg4MMuzEy/2Let5/mPEIiguJG4QgxJtDyz8QCiAuM WFwA81eyICPNpNYN3YLAEpELaSIbQD11ltQ4rRbUbfXKitpBh0XQ8m0IvcfLF0f4Lnpv96HBcsn5 2nTrpP664prpClwlbgavnhsNpuPp3nSypyeU6JvongiOodGs/w9/53YB7jAnw64hZMY1YInrE9ou NYW+I7Y/eijmDolXiFvgOuz15vrbodGFOYn12ak6FaSCqnCqPB4vard7bEYT6NDqgaJGBfTr2mop A2XlGF+L8G94tjsqcHu5rcGgUlc31FbKKxuPqop1qL74N/a3pVt3RgcL8wsGSifr5+pm226ZHqL2 ec/9L7AXJqG2eu7aWNySqI4UMUZSqCT/J8FyTZ4oNydJX4L3IRoWJ4goCEA0Ig4TA+CSwIJVMAev EVfAAgwSfuGkBYhcn51yezGy3Ow0ePReSY3D5NF2thEST6e1vvfMTPG9HZJzzaySVTPOROvwKZ/b 54GegN3vZFwRY8BOe6O6iDHk+JLDc0cuTq9ceeJjcp9yW0XsuVA8jNEkQ4RxB+P0OWmUsEBanW+h LLQF2mgbdNFEkEwSGZSrFPuFchOG6IKYFZ8nBoX/HdkAD7ofMXuO2mUWjVnSrKo+dnIn/0O+Incv /82P9rbXuewey/9ILrPYNo4zjgNFxR0USNsXtdIyWAUOivTBaYskLYwkdVvXd+w6cWpbsiVLFkWJ IiXeXN7La3ntLqnVLsnV8pLIJUWRoiSSkmnZlhQrshUfNZI0ruseRoG0aNGHPhQNwLp0ga5SDAYD DDCDmW/+8/t/XxADKuh1SAdZSKsVbqchf3QqGJUmArOhxfA935KfFcUdjPp9fjFxFwtZX9iDvCR5 RXJU8rLkoAR3kqiUmDCSDulJqiNBJhiGjCfh1oEVJsJEp+nuCpll/0X+ulEj86yo/quWzeHbiFXA koFYe6C12/W91v7QlKk0stWNJTAWm/ZHlOwvZkCUnCJohBIHGqZJMTkWIfv1o/95tXWoU3Aw/ik/ 5e+mAvZj6IDO2K3XqVxy6cg4V9D0qPP6puGe+uzw8Dkt0J4/iR2UHj7PV5Q9qoq1sQXnpoWYgMSF VD4n5PPLxY0yEyly63Ot2BddkQJVLMF/89w3LCPOWWNinBonVPgkpnGiVszitfvU+FBAFbAGgl6n BdN6tC4L7g2OWSc9JgoE2DCXhlfZ5WQFEVZXGjdXNxrXSs30TvaT+FNqm7juqZsbpvkJXgaSw8yh fXC4/VMRNB1KaJI2MV6EdcWDnFgFMBGaXrzZlWU62k9a4U6Z47Lh4kSfUqEyqwCmxyeVsDKuT5uR LDrryVOrRJWbz9crc4XpDGCykVufw2WiGqruRav+4lefdD4tztG38p+vdjclBBcjGCmFkpgfJobp 5y90tL8DZeeK+bLARLOxhWSZz8cz9CJTiuaph8Qt75ptzdLQrozW5eVe4QRIXWZ7z8DDgQGsD8H6 0EuT/ahCrRxRypWDul4LcE6c9b8l/fmb8zvf7zHM2EWYuiwO1G506N02Pw5kkhSZSu91+DE0D8XI bAl+5oQehTdE2Ikip4NToYiSP10Ej6HWZ8/vdrbfhtpn6HYHo0BY+ZxqWbeiqWGNyEK4PF3iS1wu yaeFXKqQKGXW4g16GTA3IvUSfMdzx7iLoLcnr8kWZKUhfkB0WqV3xDpi1dkxbO+Pv/7sdy17J4ez QTqc9HHemNt2avD8sctg8NgPjS9LT7zDL5zsOVW6UJNvqpdNTcc2cH7gu96Am/Gt9A6S3ancam41 N7ZXH5Yfln+TfEq1OojfW66NgXV5bkwBy30aqxmxoXr3BKUnDKwpi2YsZce6a8GZtyZtMyZGT71L nFP3vwf63zUc/C7cfqG8//YR5M7hB4pHVI0o08V4is4l5wVmik9lC5niTIaJfckm/lmps5qvpCuJ crwZ+5ABO5JHxKf6h5eis13hD6f+0vFX366tiHh5K2OMAIOZZhw9jyGOTkayFMjW4nPbPdX435ey 09xUlOomaJqgpbSd8gRgB2SFzOTFt+DzkBq6CO2DzkAacvh9N+nzw3JIHIIu0mmFz0EohJI6pYJU ad2k2wf/DNJRGhXMecuB9TAfmgknwuD/O3pDWNCB6HCNXxN6zX3aMWoFbisWwHGc9ErjIlPrZJ6D PX4Md/iGNDLrqBe4x64E+qUHjqeX+noO3ezbVX8KNJ84n/wJbu271/pG65v/FDXduvPfS528COUY lSfyTCEltvzCIpgjeQZuTYRa38bXEXzXdF1RHasMpS9QGkLj17l0bpPNhhqVFgUmA/b3PBcuwu2v CT9YP42sn/pI8cj7pSz+/O9yZ2Yn2ZiZq+00ms3q1XItV01c45aZInWP2AzUvQ33orNgq2sXtHld TpNR8QrAy9kh6gJ4SaImTlKv0KOUjnJSQWKcPEmBAxI36cHhYfoKM4iwg5wsrUyNz00KRkFfsBU9 22jXBrFIpegKMx/LcQI3P1tdKFjy9pTr7NkzV04Zge70UdePpb1DdEzVIy7PKoqKwkRFV9fXLA1s Ddg+8F2twrv0Nruxl4He3O5cwqtYFXGVzQVdVp/RxjTUCDFmUY5NyK19gVOgNSThiTQlRNMhTnwC 0TEiieje3Z8ffPytjyCWzjKlRDmRYqPTgGEiiSScgx6QKyxNxmZgDuKhGNQ6BrUGoFnIS9hJMwXO S0JEgMQpkCZTM3CGTjE8kiGWyA0q8njmkfBx/uPK9srVYqlrfWVNqKXqfJPdojaJNV/VWbXnLJwR zBimUSuscxuMZsSA6j1qCiXMtJlzMvaMuWQuOtKumGvaGbWI81af3WG3uVFcA/yTobM/gsP7ItqO tKQlkTAES3IUYDxTeAi2QFooQPoIN+IP4oR4Oo/kkMRNePYO6pX4CS+JUaAXwkncKyO1GNzeD7W/ Ar0GvcOMJlwiWBvO3YDoniE2CMRayx2CPYQniCEnJMFR8oS0T9IvJ3XOi+QbUjF091sbbbhzv/DO gqoKVFXb8hpcEd0li6RTv91svfiHI7W+urYGxq/bbtwQ3aGZ2kBqv9rYvLf0oPrH1D9Efq+ESwE+ kMMr7hVHV9W4YBLQ+4ktvpaeZwU6S/FEwh93g5h7Si+DxwJ6D4Z4nB7cJYrMHTXHBpLymCYKUv2x yzK4D+vXDCLqwdGxS4bj8uOW49QVYpKyR42RCWaY61OMa1Aj8LoCTifsmMYSHiThyviKQRCeFsMn XQqsEzsUQ+SoehRwMTLC9LReDX+hv9sL7l4onz4Ey9wy0yhikk9MjhrkxnPoYQuwHPmJ903pG2+z qSM9R9K/LMnqQF1ylKvwIl8qFZCS8Nn/SC732KauO4630uxzpW10lRYpOa6u0bqWCYlWG+toV7oN NsaoVlGgtNDwCsaELM7DcRwbx+/4de+5L9/re6/fsXEcx04cQ9KExCWkSajKoC1CRQgm7Y+p0lZt f6zb/jDoMm0n6n/nr3uPzvmdz/fzrbWIWTxirYuP9rctULO56hWi2kh9/Cf4te/uYIO0zppznUyY HqUHY5bQoH3ITAybvcfegk62hz9OsjbBKbpVq+JQvaon4y8GC8FCtMDiL67+t7/ta/lBaWOOaExk SxMwGUuGkmQo6Uk6kk7FLg/xRLznJH/IoD3L6LSn93iHzUbz0MVeE7TLI4URsjgy67rmI/zX1sI3 DJkJhp024vu8/8c2mbvEzYlZRhEEiYhLbGkO3gX3wZ/x2F8HGdD6H6iA1jPUg3CNjGXGkj7FnxiU T8vEJFCZdAE+yKW5FJ/kO+q4Ca2WE3wiLgrNSHvsyVc3mzdmVgodq/lVeY1ZpZeDV5yXndXhwmCh P90jnSfEAe7Yr+ABsFk4zCDEYlM0SJF8pBbJRZKUTBM8dr4IDOHRDfjgsD7oRAPvnkLdwxZkGriA ThtCYcSGjSWQBDwrMgqZimeEPJtnM1yWJ1iVlbBMtbbrWgL4InY9MEmOlS8Wh3LWzB8kM3uG6gqc cZwduWDrtxLafrAN7em0IGcEHmctnIvkgkJQjBCxYp5OGdK0SmMtZEeRPwrxy6L85Da9uQf14cOm dzJRKZKNlDqSmCznWm88962NNmwphSJZKFSUOnOFrvpKdmLCptj6oT06EhghgyPui3bfiHckYmf6 6UHVWiaGJry1BkRA2/6c9kYbdoLvJvO8IoiJDlHkc1UogzhKjudRJiOjS9NwGSyC1osgR+UjBTIk eSWH6Ij3CO8LWCfusJ+kr5cb6SvV+UXitv519EPte/BJB844mwNmxsqhRjgVU6MSRRwA9KgXJ1TA gxiH8fevIO0pSx/q73fg+oaHY3n98zZZkDiFk1mJ5blpPs8JPKGwl6rw0StgY3MPDfApulYTkJKF Ptkn+oQAZxXOi4SK5ITM4KpXEe5lW8/U6mJNnlSJK0/26cPIYXajQTPUtgFtK6hmP53/x636+OXy B/VCIZWVkgEaF0rGSvciM0ekkCrLbH4SPtRTYhbVDLUpxE4ZqVIdXTVcxWvFSMlZumjAtxOIQQ/l ijnJ1wKnQhditmjHsfM/2a89+2LWmXFlPRO29i/2tnZqr/5tR3psKrDo62CtyEPDIApQPjJkR2aH E7m057Ut6AWc2rICc/jUsd5ni4itGNXNdskHsp6sO6v5W/X2E8M6rQ8Ekc+NtSGcTIRFQ0wej1UM lCQi0dADbJvQpUJkKKZ7uxN1O90I0wjZDEf0u/RD+kN6GamqiNQU3Ayl7P31NkVNiRlhhs+Lgkxg MaqvwdYM+By0OjFSwDz4iJoPTZIudVTEoKYDrF8gCnROiTOSAq/yV5Vmvpm/nC8VJpl2Oi4hxcBp blb78S4rGvHAMHCCJwcBtmAbsHDOuJ8Ug2o4Tyux8Vg1SuDM8QbxWfgoL/mmvvskesfQq+87iQ4a Dq7rtzz+5cM7bfiVcSI7w0zGx1VCYFhehAzPfsy2niLWwN/BP0ERVMJFX4r0p3rT7+XwLKpsik/z N9RmvlGuZCqVyTliY1T/C9ANXODWylp9IbuYvSatMR/RK76V4Wu2D8wzRz9sztenC0W1plxW5hKN eJ35ir7Xv3aYWD80uXs71HaBC+jw63A3cPNe3keWA4VwNpai1IgcZV2slwkSLhBzetFYZBQNWnvQ 2R/tRocMkQyVViCTSnBVbLYdsshLrETwaaaxASOthq4ZnQvVyFAtWHLnfLmLaZtql4fjQ6yZMgdM ThN2f4uJ7mtnte9Tz+u24fg8xVnjIVLxlIJz0ZK3nce/DsEwNYbhMKS/oHfpu7owol5mdLT9HDpi cLO6z0CWqXALHIGFlOONoshJIuRVprIA6ZaJWdP9J/ZZEBvttHOyr2AZ75bPsO9Qnd6zQ6bBYVvI SQRRmIJ+EPiGh9pVoO3Ay7EAFEbzkUxUpTvKmJ4qBpWHGYvCAOUNu0g6GEKRkAXv4AV959v0PsMg o0tQWIxIgUmwKfKbEEiJSUHlqkIujlOAFxJsghDwxprwL+Au+DegbuvmY/XwJEklQrJPGVUHk+YU vl6JwbWXIaSSmFwwzqrFRCLOMzwv8aIgiQkxnyxeKjeI69q39RgzYRhCbspK3miu1JfGP7m0kVxj btPr7qalaal1p3FRPCe+pn0HaveBi/GyY6Q4nPNXmCbdLvo4vwf6kZfykNrvmKO07oxe26Lv1SeQ KCZZ3LGkPB+vGuUEKySMKh8XGJEQFLYwA9fRIl0jmRaha20NfunEEbxiKr3LnqdMwS5nl6Nr4LQZ j8ub4LeA0V6lrTpNx7+V8JCSp+a/ESZYN7NJfMoTcZK0cxR5vSNowLBN//6v0Q6DiCSZx1DefL0T jx89trctnp4+XjhKFI4o752AL3n3DBwhz/708Fv7TITpNz93vGz4wc7Sh3uNe5vH1i03ib6brgd/ hUvScqpJppfG5yca5XplqjaxVFsqLaWWU+viLaa1lW493fVwFxaAJ8va47b4z4RO1iefSJ7L9Sbt ReeUe2p0NjjPrlALmZnaTK20krpDyIvCvX/B1hbHl6ZV0rRytHyAOfZ/ksv+t2n0gOMbWx1v44dp U6XUObmbpu2Xu006aXDiRZrYCwLdwcFxlN7RA0ppKel7mvfEcew4TuzHT+I4dhzntUnTNEmbtlDo ENBCtwH3CpNuAu2k0063SdNp0rTTpLnI98Mc7h+wH9nf5/v9fPjB4JVJ+8TsIPEGPRI7yBnf64Bw 6atA90OLKqWTycTTRWtLLSoJs7pL4soWtvOCZSdg4dpMLZgntNHCic51/iC9pW7kWvJGabuF3nMi e03wZEjsT3WzduRt9YH0ofCYf+i9O5pkxbgUW56pzeZcy/3Vt7UBVB1OnT+NHYq85n0b956ZeOtc /7n+gZF+N+ru7wufsr05lJBmTe4/lz9fQ8OdpDueIysLnBcwY48lBkgvRlmcQhDSOGSS0RQjxpNx MZ6LZ2OquWdf6xgFQ4RZYiHejweQKw5A2IwXEDsyBse4rrOI3wPcroC5eCTs2tn97HA3pKBJ0NKo 7FBC5amKd55ZI5ajDbjELcmtfNPUrdIihGLKDLQqpqGEtu5r7z3C9N3j/zn2N3zwweuNg3CA6yNO TqETYL+BYca4eeqgq5MJ479/vdUtSbKYSdalWna+jIoa3P4nph/g9C7mPq6wckTGScknO6UwjGa4 PHrXcjO5XlhZXK3XF4tNWUtnJAX9GOnUGm2uFO0AHoIGUwNY/Va5lSlKUjG/WJ8v1NINYYVvhhac 6MJMdnocs9OTLgfudkyTV0zAGFPtVZ/ml0iB4a3hKBkKe9DAaGR0FJu2nAHGd4zXMOhP+ZWAGs4y ajzLVrhWvBkvsVIMlSIJmsRojmbD+B7EOIycHwIjtgASGwfHbZzMyyZimSWgdnrEGPhCX+le4Aum m3xtKGrY2j5SGcqEKpMVV8WfC1fIVniOrsTm4Tq3oi020MW6ZvLzXKxI5nEy78qN5v3SoHq4eDg/ aErRmDqVn6nMVrw1ooH6r9LtJraV3si18fzyXKNenyu2CtcK67nfp28JH/H32c3IJn2DaPtFf2pY OoWmTyTtNBbl2RiLuzkfb7YiTwoBGJUjGlWeuD+2YV+wV0eyg8I5foSYmEbdbnLajs1mnEUXXpm5 6rtP/sP9oee6992JjSu1S2htKHO+H9s3deREH953cs+M0WUjRpLSq73T0C4NqxR0KkMlBkZFToon 2RazjVKfRTdLz9f9xafP2t1Pl7eXlpaXl9furT1BNxEv8PiGwbQXO97xNwqr8kluCbyf6EnyC+CW gIo+SJBYkAtEfeb5/SAssHwYBAT0DOJDBr76DbJX6E948KRL8qj+HJWPl4QinxXSZn1rarkkwlRK SucDWUIJJUNW5+jY9EUv6hm6QA3YTpyt3BjuHbnhfWTm8bRF/2jSchQhEfNCpVIJIbfQOfOTZ+91 S4IIxQSqt5FKvOt3lp9auD6TJ0y/sPw2+aZ0CVfHis5qYD7QYNrCMl+HZamcqqoLxXq+kJVkE+fK 6TKqlywLoFrC8mCeX8TrfF7Erln4Kqn4JJfY049wPBS5XlNB0xLM5LAiLCQ0QbfFrav8TeFeQjho 5X/WZfzAYlL6fstpyzDwsJgvERIZXKSS8aTwCbTKfBd0QpIzB7gDXPa4kyO4o/5fuw5MTEMrr++N MGQ4EOo5fvrM6Hk/6rvwDn3WduotdX6w92JlvOFZJWr0evQuqvKP9e9jJnKBrTa2Dda4Mi5xmXgW j0DKtJHhlEOiJDQu8KIEgSiZdFjofKofEc8ed1cQfRB5l9e7ha4qIhJCOIrRfCjmx0kuYKbvctQd pVk0ysZiLBaSiVwAF2nZpV1O+RRHwb5pfGN139xJbUSZkYJ39F1b+o//oB+qbGTXYOOSeDlhhyiJ BGCXwqkqpiVUUcZXkl2fIXeQBt8CLQH9BOElGag2IQQoBosAmqfwI953gg6CDkeZOBejrdOvXDC+ +bphM75tVK3EKDXLkKSTdtN+dB8yc9Pxx8lHBqY/to59OvL3wS/YTEyKJfq0ySyloBKQeRUXVKhA pbMcOy95nz3sLiI5hBerYN12fQ0IK718bQ3ctt1qACHTy8sZkLdBLyDCGMWH42GcYgkuyI0xLibE xjiOjUdkt+LLEF8abuvyr5pv1C5qY7JbpD/Qd93+39KX5/5l9a17rrpXwzCUDIizKafkkdG/WO7w bVAUmvxN8EBA+eYK2LBtLABB7t3ch0Q4P+fgZuKzrJtde6V2RvFlnVb9uwZ5bf+1z5t/Lm6IxZ7y 7UzTXLnmI21rGUtHlVAGjwlOeTA3mXAnqY5AKWZ3ieazxSa4a9tuASHdW+PXwKZQ4YtAE9BBk/kJ zo0f8wz5g+FYLBZlaeNF49/WmVMXfnLM+EXEE/WzFPpLxDi080PfVVaJZiNaDx00dhtJ30XfaHCq JzBJTIXG0UvIMcT4uf65cWDnW1SZ1iipJ6AG0m7RC814p4Q80HgFFbIg+9wRIvVPu9tSQ5nXCqIm KWlVWqhcb+tH9VetkvmvRlYPf9zjqE0uzlb9pR5GPnv7ypK30MMm/PJ4Do3TokT2xvOcqmAFqCVS eBKKMJFQORkkINpANOQessW9D55AVN+FCH5AMliID5gM6aKCDMWgUQsjsDCG6y8Ze/WX9Ze7FEXM pDDREkpNpUzn40pcqYTVChaVmwN1eJNbAQ2Y4bIgD+e5XOclJeT6LOLh/l9x2fw0Dcdh/ERXL16U pLRJpxdj4KQQYjQo4YIxXBQD+JIA8jYmIHPAWGnXdmvX/frrRmm7941tgAgEQnhJjCIejPgWDDEm eiH8DXoqUA52f8KT7/fz5PlM2nOKF5iwX+5ihzhKDIs+amC0sfFha1+Peddqxf7c2Gmf9eeo0tRr GrVRohm81xFgIFvfAnvEKThODCFPn8EhgolW5EHWliibw6JW0ItG0kYjZchxKS4agkZlPEVef7HY uUPZBkgVbjc9eeT3ogwl0DzOqpwmkhqXEvNSyt7NGkgHMRaGpACkJnGOhr4RF+xva4Ntgx5IEQWY TeJrjvO1kyd7lfPq7HRa0WUDxpU9eQduKOgHxHQiM6IajkWAW54AAirxgiwSTIQFgowCIRQJEnxE CkdElYrR08Hdq9hWzVbddsNn6xymavM/3poXPplXlo/UIho1FEPHZ+SklCXpBKfxsWB0Qh1Un+sY yFdoQJvG1WhSyZKFdNT+z0P7dnPyJvyorMsLMKegUT+0dSQMw3KIZIMBkQZjIZ8wGaaDXEiU2NHx B676JusxZt06q7Ec1py3Y7jL7ariGIajBJTzDEuDRIRSVLfTo42lfSU0kBFyOXw9s7a8QuaWCkaS WFmbGtp00rMZIU4k9ZmU5vxmOjaOcu+te8e1WLN5s91E+w/8r5hsUBXUMsNoiIvprBMUQUkqlWvk 2vG7k5eV7q6o0uGsk+8LI0y31zUw2jnah7UgRiyt5sj0Wulg6V981VjU59EiAvSkXSuxQIzl8Ylp RuPJpB39+CdSRqYcuFz/dRbS1kx5r1tV1RZx2brk92Lu3lWwBX6pf9NV27EFNZHIaCvbO79thOJq HN1Hgg0VshdQLM4AKkKR0oTsk7woC3lZIM/uINYh6I9WfHWkcom8nrKJozGz2uze3X/zfeNLlZ3k 1Lp4ulL5H2TpoqAKZW5kc3RyZWFtDWVuZG9iag0xMiAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNj cmlwdG9yIA0vQXNjZW50IDAgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgMCANL0ZsYWdzIDQgDS9G b250QkJveCBbIC0xOTAgLTIyNyAxMDEzIDkxNyBdIA0vRm9udE5hbWUgL0VFRkZJRCtBcmlhbC5C bGFjazA4NCANL0l0YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0vQ2hhclNldCAoL0c4OC9HODAvRzcy L0c4MS9HMTUvRzczL0c4Mi9HNzQvRzgzL0cxNy9HNzUvRzkyL0c3Ni9HNjgvRzg1L0cxMS9HNjkv RzMvXA1HODYvRzEyL0c1NC9HODcvRzc5L0c3MSkNL0ZvbnRGaWxlMyAxMyAwIFIgDT4+IA1lbmRv YmoNMTMgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCAyNzE4IC9TdWJ0eXBl IC9UeXBlMUMgPj4gDXN0cmVhbQ0KSImUlHtUE+kZxjNcJp9iQbuGIwOdsCirKLgmgQDiFkVxolYs igSRGC4GiUIAuRvUFddqYqKLgmC4hYvhrmAACYLcxKoI6kp3F1tdr+3qOWv3bNVv9Bu3nbAet6f/ 9cw/3+U9v/O8z/fMi3HsbDgYhjmHhq5evWbVohW7lXHJi0OS4xJ2LQnwtd6spEU2tK8t/ZEdKpph C51m2NF+M5wZglG4AcKNu9meNHIkBQf+ffToh8UMLiydCc86we9mnXBz2PhbjiuG2XGn/2bmR84u bnwPzwWLFgt8xYHLgkNCJYnp+6mAACpgCeUvpAIElMCP8hdRAULK35cKEFECf8rfjwpkt2JKzJb5 UQIBJQ6k2BIxJRBSfmwVWxJI+QvWp6pSM/PSFHIf+VQX8qku5BsVO7KS43b/19H/9MjBpttyHDAn ziyOmLMKo+w32G22jWGPS7FTmAE7in2JlWFFWAlWiWkwHXYMK8ROYhXYEUyL6bHjWDF2GivHDmMn OC6skxw7Ds7ZymnjPOD8iF20qbJdaGu2W2NXY59m32//N/t/4nvx69xw7iRwAU+nBU47NO32uyZH d0cDne9mf5MHD+MiJF2LJAnIHyiRuxp5IQGBrt5DN6Af+ppEh3FEwHXeMDACeoEIuCANCmAAAZc1 QN9h6E2OQJ/voS90hkHgKNfRAG9boegI/hRJR5HEzEJbkHv5e+hSdAP5s1B4BIcs9DkMHGShQ3BB /XtoKvQNZ6Hh0OdT6IveQ92hIy3k0UL0E46cMzyjV5Bbl/utQQ6bRDB8zkR7b7upvb7dYDnWD5CU FuIf6hn2s+7frJ+g83h0gqk4tCyyTunS+cerqkndiNZiaG4EzQ2Gsx1E296zqiYyzRTcgGY2IFkX mnvZ71sg/kr+PQTERM3tC+PkhbHx/ifnH7dBxyq4WAc3aqFn0ovQH1ddQbYVyItJSJ9TMJ7Tm9Kc 3BhviNDHaZT7s7NBVub+tGQi48ucojyyKMuivquGMjn0lD+KfSS/FmFeB86vrVr5GbEo3S8yiJQG hYR5J4AEH+SQi+a6omMopPuHhXyvZxHQcT9caLWCLnoj5THCXsNN41B9l4vpvLntUtP5ykvlYyXj JbdPfKODjtoXB7/e+5f862m9sWeTTfKqCGDcVBQZTTAqrvT49sJUsjClNKk6FjDuuLq2oOqQ4XDp n6oPNUml0iRpDlCFBu3zdkVO3qYr6/jrRnbdeUTcrRm3DJA9lx60w5km6NXwQ/WFkgslPeW9RtBV 0JxXQeZW7CyK0W/QyA8k52Tl5aryY1mp8DaS8qSZEXmb8oN3R2WyXuRkHEhPJZKK06qzSGN2w+dm fafGfOpcXZvxTIOhBRhaT3YNEre4jtDRzf6C9fky8M62blN/VX/FcPFVHXTWvtr6cDF44NOB3NAK AjnkeSQISYUgUrI6DsRKgrP9XUPXltaH8WOrojsirwLEZ2azJC796c8+vI/Lg1tlZEt0R2a/vkdj rmnuAa0WwyS0JZ7l39llIZMtimqZPlIjz1DKwM6tuSu9CdZuN7u/WrW4vV3D8CCfKw2LjpfngNTw tftWuqK5yHYA2v6eHwxtFNAVigkY2gVdv3tO3n/2+iJ01o1qhw/05/XndKeZEwGdQQu5jFXJ8z13 ki6SOy3y2s16mUaRlSIDyTJ1sAfxSVlIs4xsjjFnWvT9ms6a1h7QYimffDUlxH4GvY73rhsvDCuX 16W2xfVmjejbNWeLWqqrS4w1tS20aOucMARClvpFg2gxcspCYlfER1ileRk/yCy5Jn0Moh6m/gQd CLh0ELq9fEm+/Bf07IfrdXCRFjpkPpI9jhmTWHxBt7AG4YgkZFxGCKW8g+PZfcqmnY2xbKbXa6Ky FNuyUtTxX0QAmsDZEXLv7QgPSpEFSd8ZGeEbI5oPLXB+N24+binqJ4svVnScaTU1tp3pqe6tuHnq H7oJ7esC6K6OQoVzthTGH0vRJ2rSDu0pyN+/b88X2eDIXk36dmu7b16wXJr3sx6P4Ur2rVWFkalh iqiYHTGKDakhe4A6JPAgG1IlWtA8toy/bDT+MbQp0VXUEbQgukhpyKjc75LbcK6gy3Wos6yxnm9q PD04SUAhNyEmXrk9L0wpyV+hR+4ahF8XwVkg7GEynA4XEDDADGfdfULeffiyG87W3dfe3Du4eyCt L94SDqAHl8GZkzxxWVhTAtkc35HTp+/VdFS1doGWjvLRB8T9PaNJ3WRSd1x1lH6LJiE7JQGo4vIl Uyn6EOhafGh4sGPwzFDt9dIJHbTRPkq6RoFRqnEucifefcZOq6fc8c97MhrIDJOyLFa3TavIUSUC 1Xa1xItgDIzQGmd2vH0yxRMhIyOCRpwh7GjRzyOM6O0I/uulNbMidomzIX4OHaf8REvwy6PDlsum 4fpbp+/qHmhvqftUfSkdsqbwG+N/vjhQN1h34/SkDgLt35NGKTAW2vwxmke882NE9Ftub8G5nDoy 7ZyyMl4XrVXkpiQB1Q71xmCCGZgS3n2k+VAlefBMvjG7IsuQXpyik2m35yYngZQd6g1BBGNhhG9H rGb8ImU5fvnmcN9I00jjrbJ7Omj/f3thhU3QjTwoHmL/PpvXJMRewvmDMEwHlVro+wfIQU7giWcn mok8CRQUyQ4NzjzSHXHQoi0owhUFo991PvHgo9mv1sB5cBX7ULToGG9+5fK2GLItuidzSD+i6a5p 6wHnLJXfvCae5d7Z0Usm9myrjdCHa2IyEmNAYnRuiNcvD8yIeG72t+jZyJ07cLm3s6v6Sv3Y6a90 0EMLbSK+RTZgEtm2swp8if8EWwKk/ftIYvsbNi4eLDUhXvsWG05TlJ1XH1edXqdhsQj8ivwyB/gv +kQVKZ5CrF0erVy3dL+NuImzoaq4CKu3mtj3ARrtfNRpuh5ruWOjXI1ZiWBzal0IaVt6PiQaiwcO 9wT3DvrFFfgV+0QGstayv7Oosqa+m8WMyYrOeNRn+xX7txhanWOWboxVimB0bGAIYUt1+wv7Phr7 /Pwy+sUHDvhZvPe5Ffgyu5lUn2WjdhmkdKyAtI25ibCYo6MIn5qUoqcaqIWhfZ4egpRZmiyd+yCi K6JUoFShXq5mvwhmvXjFzhrRoMizvx60vsOy0aTTpOuZ9wuM9xSK6IDId8d2vmyyYrNgrVWmRfwz chiCqHyidppvnWiWYo1iiW2CeHwIeXiAeHUacJd2pH4eo3zEf+OC9xp68HbLb8xwvWOvWQiuV5tU UBpLeU9mUh5nUU9bPGoIaTwge/sdG/tU+x2kwjkfOMJY2XTzCIsHDvcE+PYcBbcV/Br3b/u5+2/8 KAdZj2uTfR6acaJ/rI2qibeUwp+p+50YdiUrgjEbJT+XpVofW6VosnLCCHTAf+T3Dhr4Evsm97n3 JvdPB/gz918FDhwE2xb8F/c/BlNDU1lRbghsUkV+ORv7AjSrz0sfTc5r8/ciGvlA+DL85wdHmFqh cB6kbqt9to24ibGdqrEIqbCZ0O8a+Jz4Mv7FBw74WfrFBPg3Bvd3/V/3ZflfBfgYBvw1HPuEXPsY WjJXXhlJRfsAa/smG1Evk5r7Dx9r96gFdcbOgtQbvLOXpKkfqqOjt6DL/E/6xxgOHAVVFPmqFQSE VrsKZW5kc3RyZWFtDWVuZG9iag0xNCAwIG9iag08PCANL1R5cGUgL0ZvbnREZXNjcmlwdG9yIA0v QXNjZW50IDAgDS9DYXBIZWlnaHQgMCANL0Rlc2NlbnQgMCANL0ZsYWdzIDQgDS9Gb250QkJveCBb IC0xMzMgLTI1NiAxMDE0IDkwNyBdIA0vRm9udE5hbWUgL0VFRkZNQytHYXJhbW9uZDA3NSANL0l0 YWxpY0FuZ2xlIDAgDS9TdGVtViAwIA0vQ2hhclNldCAoL0cyNi9HODgvRzUxL0c3Ni9HMzkvRzI3 L0c4OS9HMTUvRzc3L0c0MC9HMy9HMjgvRzkwL0c1My9HMTYvRzc4L0c0MS9HMjkvXA1HOTEvRzU0 L0cxNy9HNzkvRzQyL0czMC9HOTIvRzU1L0cxOC9HODAvRzQzL0c2OC9HNTYvRzgxL0cxOS9HNDQv RzY5L0c1Ny9cDUcyMC9HODIvRzQ1L0c3MC9HNTgvRzIxL0c4My9HNzEvRzU5L0cyMi9HODQvRzQ3 L0cxMC9HNzIvRzM1L0c2MC9HMjMvRzg1L1wNRzQ4L0cxMS9HNzMvRzM2L0cyNC9HODYvRzQ5L0cx Mi9HNzQvRzM3L0cyNS9HODcvRzUwL0c3NS9HMzgpDS9Gb250RmlsZTMgMTUgMCBSIA0+PiANZW5k b2JqDTE1IDAgb2JqDTw8IC9GaWx0ZXIgL0ZsYXRlRGVjb2RlIC9MZW5ndGggMTg0MDUgL1N1YnR5 cGUgL1R5cGUxQyA+PiANc3RyZWFtDQpIiUyTe1RT2RXGc4Aktw5VRxsLF7yg1epoFfIiCb4RPY4j OLhQeQwGAogChkcM8lYgBG7CTUIwQiDkhUAIDxWQh4oCDgKKQy0uV+tjWnVVOk6r1ldgLjNtmLWm q/+dc9bev/19e58NKG4uFADA0l27du8O2bkexmXGnUgTJ/jzuPPPQTOxLjNxrjMMN3Kju+u/3d1m RO7LyMY5szey3Ju+g4qZKXuKi/6jVP7v4E6f2bZ4Zv+imYefVnrve7GEsgcAN/qCXy9euszT22fF qjXrNvizAwSbtwXt2vNFaFj44aiY2Pijx1PTMqXZeYVFsjIFoak6pzeYrI221o5L3b1XBgZv3hqf mHz59kfICoB8PuQyIS8AsgWQxYN8AWRyIY8HOf6QDVl8KPCHXDZkBkAeH3KYkCWAAibkciCTB3kC yGFBtj8UsCCXC5l8yPeHHDYMcCKdYCZkOgM4MEAAuTzI8od8FuQ42U4gH7KYkM+GPCfKWZYF+RzI 4UGmP+Q5gVwY4A9ZbMjnQg4fMp3q2JAdAFkcyA+AHKdAFuRxINvJ5EI+D3KdWVzI5oekidNO5qQn CjcIf+m68EBikjQ1LvOX+/9PgwLorpQFLosW/W6BnxuXHuxBAZWgF1wHXwMV0IE6YAHNoBVcBN3g KhgCo6AMVAAtqAFG0A8GwS1wByiBBlSDetAAbKAd9IABcBOMAxycBbXADBqBHVwAXeAKOA9aQAfo BH3gBhgBt4ECqME5YABW0ATawCVwGVwDw2AMlAMCVAE9MFF2Oz8RxY1Cp2yl3AJBzqD3LhtddrkC 18tu56lJtIN0O1Lzq+wFlZ+kf/LMPXfh5kU3Pw1YsnLpAUbwsuHfzqEe6Auvd97fY6O+GSsyVnat Wrv6s99nrrm2dnI9ZwNtY5Kfxl/FXM5azvqBs5x7m7eEN8PvDwwJfLv52la3reZttu23d1wKOrtT Gmzd1Qy37Lmzd/FPrIVz6xfOTTr8ZkcZhxw91MKHsiEb2l1lqzdjBqNF10TY8IYiYzZizKo6KUbT SkJz/LAI8jJVRFtIfjvz2psazKjMqsrR5ZUW5eSIM2JjUxJOJof5xW1JC03flxWUF4jk8kvWky7o Fu2OmmCsZmfDttbN7YG9gcO8RlHb0Y5kbenZQkOePt8jK+pAR2TPkWHP7f8I+3vc87hnaU/zniJZ jqVnpkfQF+f+aX2DWV53vhl+e2Fi8MG9x71X+i5esyFKulOHcC6RYTXW1dfU9HVe6LVdGf+u6751 wD5pfVD3BKl7XPV8Gn1XMp3zEMv5i/hx/POEv8bdF47JdHFXtj023fAYThqI7Ts8xbvJ7Pfr22Bn 1fARC8moXheCBhb5n1yLSdckrP5yZZwgVLAp8HhSfGpUhtxQUl9onK89V/CEdDAIm05VpT6n8vxb 20i7rR2xtevtTahBZsjVY3n6dN1RbWKlpPK0RlZRpC2oRkr1ZTV61K61VOuxJout2k4M4v1Zl44i nQnGr8JQUYFQHIOJo4VHw8SIOOxwgdBr3uX1ZzOfM/S0R7jDi6C+ol2nXcUv4NZyZDs9Hj+mzCQk uEQpIVLwbKWMQGJpp/F8ZS4hwMPUKZV4s4eOqFWZsZ8VO8D3DKvObDZhJqNVd55oxC1FhlzEmF0l zUTFJZLsXCw7WypL98qQak3ZPtmGooZm1Jk5e8ubWsH4lvZjlPdsPFVAm430ptVTF7b84DkLGFC+ vygCy/XL2JqyPzU0MUIoSk0+Lk06jRQcSyxN9PoixNQT5hN2OWJK+AY58krqQBze6Hv96/P/wppf tj/oHe4d7Onsabjc0F89UDGlmEy7e/CbA4MBnSQNadqkJymkl1MBKWhnOJilH86MYDnT6ROiSwkX Y4zhhBAX5YvEotT0mLwQRLK6kPQj41FSZCJXdQmwrsBR0cOKIcVVQ2dHd0fzbcNLxDBd9cHhjiru OrXPnlw2F08jlCo1qlFrVCpM4+xTo7Zb21rVoEe0erVzUOP0yoo2YgwzE68cO9EKR6HC4UM1VNz+ iJJ/IN344XmEHJcTMi0i15RXalGNqlKtwXSVlrp2i5awGLs7Joav9thbW+wGo0aD6HXKCq2PQVFd ppYjzh+Rcwwt+WkxlUWXKqVZUjy/GM1U51XKMHVpdalJ/sd8j+KWOrnKSytTyUtRRfF8v6nL1pKe SnKLF3lCvk61tZwqO02o8n1q7HUtJtv4xLOnDtpHh6/Dd9rh2vsE6Xtk+fMUekfydVQ/Ft0b0hBM xOKiIlF2wqlkSWZa3qlTCRnhSEphcW65V5lMjsuIcqcb+bybsqpzaEvdQMufMPu9/uHx7rHOe+ZH FR8Uz5Lv7UWmPm/fzEZ3SIKid2DR20lAupFB5LrwyIQkySmJJCY6ePs7+Xf4E6IeNytNaqTbMm/b 4Vteh9dqa/WehhprZ9M3SA1NjauUagJRlShLFSheXC7Fk8ojPPHk8hh56PyGtTgCf0hhiGs73/bf H+zzHOwas05V3FUM5nWdQMYibeFhaFRuZNJXWFLkvoPM/U2Exyg+UjCUOZzWm9B2CGk9WPdlKEr+ 5oivHwvz9yOROHKl14pNtfYIn/TaAnMTWq2t1lVjOp1eW0uY8fNFzVmTh0Yzr1U8VEy2j0wio5O2 p+/Rp1n3RDcx0XBE014iBo+WRAizOz0aGxosJtPEjf5B+xDScEHXakf787tS27HU1gRDlHPzdh4M JSnzFtpmOd5uHxlDtCzlmXKU9KXLycUa0pdKUujkZ/QMZdIR1EibpE3gNwiq6r8klntQU/kVx1vl 8Vt3XLVdarihF3bR3XWKdS3d1bK7raAuLeMLBBVQBIwJjxAIhJAHhLyTe5Mb8uBCQsibRyDEQBRB 5FGxPldlu6jo6upoO2PtON3dacff7v66nUb988yZ85tzzu873/NpNEgVmMwg0Qtxlk5I6o2HKQYr QUGIDQ0dYIMBvYk2YVq9Vq9m7iDiW5sNVE3qHcP5E0HDYP+Eoa+zy+Duxxq0QlJqVJMKg9KUR7GN CkpFCMlq3XorY38C21IqV9ri7aSdthi7ezGPPzw1cxMegj7G9PXxc6GTI9HQxMhUaDI8ERqPtb/+ x4kkmJEIVybCa4n7d36Uvh6lIIB+++mvmmuHLT6zk4JRHcNHBo3RjlfTVqXEyZJyVfv1RykuUW3g mIBIThl1qdlkJaEhgY4gSYJJyFToNSlqGHYEuwcsg9ZR0xkqRPgJu/6qYFIyKInyQw0BXl+Nr9yz DziPWsvKsIPqktYKvK1MzBHyhLxabjm3ora0aZ8ESPezVC1MtM7OslTRXGcyr0fYo3ACrUXf7cRo W7fdjjvsLquH6iS69Z3a24UMV4tXGpCZ9bTeToxq3LoOykH0mUP2cNewbyAYDPaNuieBd4KeOY/9 s/7e/s/wgiu5oSyqmqjVcGU8mbC1XSbTMDRaNaGnZCYGTdA2E2XtxkzDHeEIFjaFzEO4aSre5KP6 ApgJbrA8pvvMnTYzTQHCYjXQzA4SvmGc10SJfir5EnHWGrG7+u3dL9ImG0kzTTLFYc22eI1Wrpbg L5caeiEhi8wk75ADhU6jVjD5ymPiIp5Mxa7bVVwvrOawDh3YztolKGwuFO5oydQ26I/o9xAcxpa+ rLNZ+HTMB7+gokSkOxQI+fvHPH8B7nl64T72vOXesTm8cra0P5+SEG2GVgpoElSE0qy0O21eW8DW Z3WaLJSZCGrnVUNtjFC7X+6UD/MHuH6OXeRgeQqMGnO97aDuPYZsT2ulTChicY8frRQI6iQcGWgp LlLlM9M2RR9uS81+wIIr4YfYI8eDwfv4wN3ozbmFyPjU2Utzl2bOn5oL3ox80b/oeCkhuCIl7puk e6bnFEwxAvLyInGHOa0PET3UUyPDn9ChobR6TKERSepwTRs3Jx+t5edWf1CZjlaj7xh1W0UFirrm jQxlnU4kx9pNUrMIV6il2iamQm6mFammqH3We8Pms5/x/NW94LnaOw8T4XXGyOPQ/eBSt9/mMncB h9/qdWGyBEUCSjLFE7o2UsAUEBKDjAJoY8LhhDwTmxBolcpkRbu2gawAMl27VoVr9BpCR2kIRYfc AnoM9k7MOEzOx0/F7ocbp8wmm4V+Od93a76PT8obKRto9Nb210eaJ4FgQj45jX0Zvnn9Bn7j2v3w MyNcRj6qv1oIrhUM536ClSmOtXBwEbu+5jivUVjetJv3pGSe65KN8oY5/eWg/0hX8QEsvSpz26f4 9uyNtSiRiV7bFLyyM3Xn5ao7T7CznVOu07hnfOBEdGTYOz9wNxzrA2Y+SpodHBt2h0FkxnlhAZtR TAijuChSP1DtrO5l2yqNu8iDgmMVoLJMWLQHY5lr6Cac5juFXpFTMsq/WNWp9qpGFLTOofWoYw+i 5WlJpfzq5hYpr05QK2UDKUtRnIdt7z0wxMLP/Wmh5iF1l7jmPzsNZicDV5awL5uuHprGiye3nkGJ p195R1FKnD1p5kCk2FsCgjk9WzdhaZKM2iy89kPWjiN7y3aXlBaziit3V2VzQW3O7tZipipBbdVZ aKzTaDWZ8Q5TJ2U3gb6TjqELqfdOXBo/Ob249Oe/hf8FIs+cMA6uwr6W32+8hjdfrZ4sH6oYqOg5 ZjxIHm1kl4KSnfz30JvYOn/WZAEerjgjPG/0kQ6DzQhsCVbSQnToQaeiQ6PF2lVtaolWRCaL9UKi icoiciJ5iyBvsfYJjMPgstGnt5fwW7f/Hv23cZI8pQ7Lw7Jx/hznJS2K4S++P57k7nK5XbjHGaD7 Y3jdp/BKgU9EtwgxnlzAF+FSqUBVY+SRzbaWXiDuVQbCMfb5cUWcr8vjdeN+V4AeNA6QAYVHCtxi WtiE1SsEQikuFjVp6pi1fJtXnCr2KL1e7BXtiWNo/wLiXTGIb+lsbsIalC8QTywSKBuoRkLQKfaA V4znp/29Htzd66MD1IvfzPnf50n/ObU4NhYC0ZhIxjC7trutC6fb28wy5sdEfIvI3CtJlTiUsTs6 0O3zevGhwAl7mJolTrUON4AhrrM8HytqP1J/HG9gV3IKq+uEB5o/bqg7wXjjh+yUeMkP+5LS/pvO QhmN7yoPJ6tKtGwexrcJ7FLc0eJSeakZ4lLfwuznsxe/moaJYBomBOAKuAaDoB4uL/wWL/z690vv zL97Di0fQCsplEGg9AqUnIXWbklHKz5BG8Ef0CYWykS/w9D7YfTWDbQGX0A/e5oBV+WBPLgKruXC NCbcDjMn/wHTUuFbT+BPYcpdmAvmEvai3BjRrIsVLwNoGdqM/liEypix8J2xWyglFaXcfvv5NvhL kA1TWHAj/AiD28fhlq/gr/EHMCNmJq/DDY/hhodw8wT8iIJpBFzNg8vz4bK9Dz+4gOLARRQfRK+j 1Rj6OR+tKUQr8SK0Kvc3WwpBwZZM/mZmCZv28VP5XtnwOBa2zHZ/hr+PfrItJ58NWPlF4mJmWYV7 gpPKGZdcvIU9G4JxV+Aa/DJc9eCbb+8szS8MXTSeJiOyYGOQ762i/89x2cc2cd5xXN3w+aS1oGpz 5ZzRuRVjjI6tjEob4zWgVqGUhUYEEl4DIeQFqPPmJI7jxD7f5XzPPffuXGzn1Y6xkziYJG6IgRIS UhiQMCiD0jAN6FbWirVaJ+2Pozom7aie/396nke/78vnwGkNtWpvDJr0x/sse9m9jqJdW/+wQ3+p SMfQY8td6/6IHQpXDNTiMUeibdAIiEzX2WHjXDg3f34+Pdc3h2a0Rf1f38cmvaP1Q7gz4eiq4l7s 8rOK+n6LKnbwCofGEYkNwk5uWkwJqhJXo7Ge06M3M//Kaq/GrkbSYqRnrGeyK/utFrZ2Z0affqKt 6Er3XIzOdYnWUTBUkMjvfz8nUtlblHhPW/X8N9aHel1W/9ngxnB1TuTDiEs1qq9hMAxKxboDQdtp KsaoABVpjoFYALIMwBs9kKjaCdfYliP6EoQioZ+kIGVrQCgKCpRd5mVewYMKLyj2/yimZJ8oh+1i J6cGsU5y2D2DE6d9I0SKTFV+l69trRHruUZePwGs25EGtg5UA7KJbgm0v6UnrOVvuAr8GCn4JC/e TfcyA0CzeK0dxgVZjIbtDIPXOKG7uADm2U7WQ77NDlobYJVxPZ/N44J8nV0yczwvyYY0n1U+e2S5 Rz8EX/GXwXl+XKDjVJyIl2o/rr9OR9ZoDVZ/D0N6jlcX5JQsP76+qdBfQ9YS9b462s34AMEQtF9i rIu1bxNLF81asuZOIcgrwlPJ+kD5R/AbGc1cg/xDu4aAh+S05/O6K8fG9qOZ4l6jL6/Yuk5fsR1v a1tovFk9VZVzqTJz+NR+tL9MNeDzFwfX/HYzvnqj/qohHSPrViL6KtrE6DkboBGADVBw2rvMhteK Mm7EmdSh/D1yMaTKnUqwQ+hC1bhwS/sRFoRhths/C04Fse/M2iagrQxor+FA22M6ZS6Qi6VDAlrd wMvNduMbcp43Wkb8o8zoC518k5qaQ6dvxK/fwBJMkhjG/UlPwhlvGKjurgrv6v1A3ckVskXUfh/a Agma5JodGN8IXc0Yo79setcc1HGT26z5/5druS3MhrOJgWC8Nzk0PBhNd4+j3ePBsQyWoEd8E7gv 03SmNlU7dDRRFC3qL+jYweuLQR7TwhiDve1YuTnX/Hszp78tviVVy47e2pRrxHmFeMz/sPmWpYvA 0kV/tai7hT3FWCtsZd24n6EgbaATZVTumoWD17ZPbv9o/cCvuH3sYaqKyHfucRwsP3jsaMmJ4uN7 6na4tqDuXGJrLqavjOmvZFfh51b+KW+hDC1dWHAt2C4gs9K40qtMhya6RqIjvanBVDqVTmb6P+6U rAIQWDmAugERwGr1Ra5N3jIi4GXcwJi4nNRfsy3bIEeK7cWRwlh+Kn9oT+bgpQNT5XM1C2j1fc+j r7HHoc9i83hsPj1//tbHN2dn5rJzk3eGF6Kz6gPl3/w98Kn/pmfePdka9b546/fLEmnLgJoMpqRz wmk11of2jgT/qf0c094081+B27y2hNHmTCP0gC+Mu7uORPK6HJKBr0q7yIRAX7egGtpD7yJjXIJN wmEuZ46dgze5PnYQprmn7J/hBPc3doG867nX8pnj89KLNVOHp3Zd+mAsP7ENTeSFt6zFNrZtcWzF P8w99n7x7r2FRUeKaosd652vN6P+kg1AN+XuhPubm2BDgIG07fmbCAiaAM8KMiZ0mZ55z1pmmi+T s/xfwG31dvR237XB6cz0aPZs+kL6XCwbzqCxSx13n2CPXF+UfYnXXj1w5b3ZbbMbJlYnVsd/GX6d e4ctJCvaGIpmGAZlmhlPmx8SBCZshjtLMN1h1hdkfVu4Ag+Xj5+8WvvDbqxO9lkUwbAaIcJH+aRw W5yQelRUDYl9SeyuWQuZgbaE1zppLWv6lM74VNwbKu/YIVQbTaJJQP20qHC8KEh2ReI50a6yKoxw E8wEmOTvC1btXYR9cgdetE2PQK7HzvaMw+s2bRnXy3whBGmREtr5QA4BPQE3zrhebEieuEs6hNMB 0I77DBwkBCpExLxpb8o1XpdtSXq7CZmUXcJJngYn4W4BbW2FvMeun6FM9Ugl62xvJ1Gfq33fOozg 1or627i+3CwHOljD83sQVu2BUVs6EIcqHwQKlET0zhOO116yp6WoIqmq2nFGuCzOqKmIKgOFVQDK GyJhMMObgR93ws364kpYXloKGwBGAZKhcIqmAcWjJNLa400S4y3X3Rl3j7vbESwzwIjywAabk62C JRy6E1nLFoIaBq0w60Vm/RWz/rKZy5VKFSLkTlBjPHoDAVI/HLeNs1k4w2kW9kvpbHiyczSWHE6m Rm9N/jc0FOoK8TKQGTngfMd7KNBEFtN7wT60nm70tuENiH4GmPRXEX3mRaZ4DJXrP1kDC2wEBXnG HuBYUcI4xbRYOzEtW1LmiMFJI3JaGpDCSlhUg8EQKieF6QfY94qZ135qitO9RCfuV6uDJcoRsVYi JbRdoEUZcoKCqYZ3qwbnqFGYsiURFSThpIBqdkT7CNE+QZJIFgmzaiDIoJJPoBgMlPP670wkJBk/ TrSTgDCQg+YDEiMzYSYKEkTadZ7s9YRcalk4L/hrvgQcZctAGeOEBIduQk6ytXQjhbaRZGsT1mrm K2DFMQzofaZqvl5w4kl2WjBp25B7YEoaDPcp4bDaLQjBoc7L4SfWsFGwZc6Ie9DJoP/nuMxjo7ju ON4iZmeaSlSVgK5nyWzSKncQJAEKJMi00BrE6QaBwRRjp+UyYK+N1/aud72zc72ZN/N2jh3vrr1e r70sEIO5T2MCOHEENE0krpSkUdJEatKESD1UXqOhUh/9ZzTSaPQ0v/l+P9/vL9WOQjvYwsNXo2IC 8EZFl578c+T9tosVYm/S5c0oWqR7M4x6Iq2oQU5XBYPhfR1qHAjETrwqqeyv6KSxq5oc/jmVQN0o zvXGSwIJA3BYHE4yBdERJBKsCtA4AIg0ahbDmZvWw3Xb6uCmQIdFTfnu6RmUf8bk69MGvZ9T6Q2o McKuk+sevP7Jr8crll9dcPB53XtMmxVd1vxi3cJfVD3FVD250/ux9xQ7J1tZXsaVq46uGq0eXTu+ 8UbD2d1j7RMxRjhyUf1D4OwFlHsreNk9ni8X9w/kB3sOPoq2t+6y+EfircgA11XcmJ2fbkD+vSql yNCQgtFeCqaIb7kR466OaSLXA6fhROAf4EuDUguDsBRQzZSmBwwVQkjULj/qCkpY7TKYlb6wGhHi MUYSQIhwJUC/ANaKrZwSEaIxvjvWHG+Ivt6yPlorMZ1z5kkLAt5073u9I/OC848subDq2uqJrdeb bzC//6L9q69ZTA9j3zVMcdfxpPt/xYFbX4/iqWU83yBF4KvkzcitzomO0+H/k/0H5ekleihbdg7Y o+iQnbWypuOmsky6YBZLrHqb+oDWPqaG9VPGJQ6NwQMmi/P0aeO8McbpF+HIADsOh4HLAUe2RFNC rWiruccIozhiCCAcx4JOhu3LQt0JfuP7QLsN7+jHtbfJlUFJmFRYXhMUwInkrwqB2cl1fDTOROPC TrLEGj9DP+XQKwhcAJ+CipLSC5GBXzD836o4Z1FHCo9qHHpgPPgXe199Ry5wwBWtpMnIv7XdOcGu mI7iQZBRcgNsGfU/aqcf+m5qN+EtfVT7ED7QmbDSCeLc7sQ2qU4NgValAzBdCaG9JWlIIqu3wC6Z 9SbTS2lttu69Bry5VKOxUV/GeT+ht5i77E4ulUyLafBZ1H+WLwuOzDhSSpRZJUEpPiIFafFrcP6K zbAp9Bs4J2CppokM0yWr1Yhz3jpmlHsKA0w2bfWXWfw0nToDhywyx88UPInTHGCJqc7Uy5o3T2wE LVpUj2qNcANiNmzWjS1BdV8YRgN7tAhUyAMeSDIjiyDRxVbRcXUN8CZxrbAzzs5Ga+wQh6JWMq1Y 8kFpVDjMD/F9khX3ixpQOBlImihLUAiIMd0IB3fWw5rGJhiqr4IzO2MwHiDa8Ko/GZiWM7JGDn1p XsnkCkw2b36OX2H/TePJNCABdke9R/2NJqF0hTJc2JtnT6sX5EucagNXcdvc7ekacxPaa4s2oxjA ybMf+3Da9772BcSTdIaHgiJx3aANNCor+TfEuJyUCflFMQZa1T2yV+E3H26hvOW0Vq3+roNdhDam 2jnUZkddwU3kpKIywpdAXj8J9isEQroIgcoCWq2ug82ByF5oNAS9xwm7O32dPnWAmuIp3tSH3DQ7 lzGtwJGRyO4TQUu0AFJN2d+d75X7A/vLTr4U3J8vlrPDxXO9l9yrTM84eu8ei+cSeH+fuq1iWsQv ceJ/phq4xsgrvVKuQiEMT9i82ZUKo0rT36pGDd5kVFMzbbaHVvP96lDgHDhLGs4AqT5H9JKWhwTy +CWfNliC5UA3cQHgVigNoFOOiHExKTKyALq7WOVJI0QZMdjWyDbQIdgeYdFeGFFIbHaBVo6HJAAy JJy85ZT3GF3VPbPZ+yEXeXnHq5uW1C6p3bQ5xDTXruxeGHhjl51vDpKZ9akDxmCmMJh7ZHsslaf3 oX7Uz13uGXNGbebwgJN1gpZlDo+zDk5peLGO91ETNK6An4JjHFJdhTQ7K2Z2o4SxwZ2VZ1zoWiZ0 smxWK8Iy+aLnfH8BJYI55MK+wEm1CE3jHvJf0U6oRZWJKjEQ4SSwHaxSV4NtgCd244VQPRuHYW03 V017K+hVNPI+At4wtYoOo4SlcH1gDN4zmD/68CKTOvcmcgeCBWt46NzJ8mBxf66cQpZj92T68keL V5jLPjkktkrtoWfbFyZXq1G1W0t6D3v83jVvOVwbaYcdgWd9U74rlw9NK2SP9YzZzKmSadlkK0yZ uuUOOe+hBzYOunhtFvNMGi818eTzbJnegpaYzziM7ALHZhGyUIbLkJwm72g9MK8f1s7Acb1fG4Zn yH0eIr1Hy8AsQgISDXBmph8f/S+NH/fe/Tuuvocrx/HzFcg1XTNtuXbW7LOyQ++cut9/PDvivnkG TyrdsPt7SFl29LSWhVl9BFxV7xjMqHrSOIQYI06inhUg2fq4eHub1BRYL++Uu+SYxItEM0l5D6jV 6/zaFuo55M0zvVbOW0t7U+ha1IQEzuSzQkEaib+duMMzJm8IApk9WSG5Ot+OBojqg6i+xQDe1Lmw vjVKuKAo0JSDBdrW0xm2aB20j5mn0ocyfTnGHkJjf2JxDT1gnHqX1SfgN9jP/hN+BMa5ROu+mu2V 0W1+TfZmet+u89il3ty9lU3L29ZV8E1iWIozTb5K3DgLtzyBO5/A7Yvxi1vvinukBbw3g+G9RZK3 wqtl15jLnF8SrzvRPp5J5E/I1wNldUgtaowZ1XlSHUlqCJx3whduhP/juFyD2rjuKJ64lrRpnenU Exq0oitPMmnapK0Tt+krGJMYm9bmYWxiMOAXNmCZpwDxElq06LVXu3d3tdIiyRLiIUuWRXjGIGww D9kE/Eix44xD2sZ106RJO8lM3U5m7dlkpos/3A937rf//Z9zfuewoYoq08Qel5S0jckUMP+p86Ys N3VA/iCO5p1uykOf10f0Aw281WXjreIpqS01rpsqmjg+qlOPVq1mPdgi2iRvarg+Xj1aBQOpjs/I GR7llsDniklVxHnPKmqxXnLUuoA55h3TU+j75CThwxwuvVAiIEQ7ZJu0DR0U69Da7ZzHroVuxi3v KhNkgzLNhQapqOZcmKL7tW87L1HX5fyLyF+L9CodRQqb2Ui2aFpBG2gn9YTJZpWbZzthNMrSvuKW tihOqFzSWwpGUkNJ8TLaTJWR2VgN2Rz5/V+lH4ladU28ZRD3v/ZV6ukRwyAhEB4Lb3dl/eVnD6Sn xO/XxI/M575fOdkUWX8xedv9Dl2q9Awr7XRJjRgvrSnq6Aa2GRuyXLMsWZYItZVjSFYDKhV2wkLZ rARlzs2gfpGzHxzS4E6F3UIxZi0YjQRmXQn2vKtPUPuYHpdbQNwJ9r1/oBPUBw7xCUxUy8kQU4hP 2z+wheVQ7u7BBUPgtHDSVcE2cmb2MXS88fGjZ1NuuVd6k1hwIbo0duOdGzMLi5PJC2sTX46s9n3i /R+8A1aJ1bZbLSuNSd2iLnkwuXuiOFYcKkSimd4d6ejW7syOAqwjv66gvLC2rLAo40BxeU51RhPS lPk7Yptm2+tC3y5tdn/B2dJ4aaxs+tC7pUuVf9LfQRpvmz66j1KqR3nfPpuyvMIFr2uvB65GZ8Zm x8enorPRmYGV4F2k9677ww/RL0xf1P0La71VtVJypTSZP5V9Pju2I7CdznHmmvNa8w0l9SdqT56u Oqwr0OXr93bsQjp2WnIOovnuPcEsLPhGOCd+MP7W2OHp8kT55dOLrYghudy9sh6son4oTfFEip+H NKMNO8epOTrqDMmxEHCepy7KVrpDeREuwCX4NbhvvNawUjNzdDgPGd4bzMtHn9dt2/kmtjvz5Qpp E9SBBmjgDKzeXefvYqw8yTOQpRlWAB5SsA3g5+zD9Jxz1ncphlw8NzwRXkDCcz1XltCkOalfxJrm qqfKh5uDOn+Zv8x7ylUPXweltk4zgqughChaVK2gvlLaQv36NFqg+qZSZaFMoANztoHOLlTH6NlO LGi9RKwZEet4yMloeAfnZABilRHdQZop3NpG1e47Suk00m7wHFTIV50mqhLTwmHOzzO8mufZUIyh /QMo9FKh6Bolbhe94ncp8WlxMxpUzVji7T6soT8rKD0VROSclpsWhAzDY+sT/PLmfMq/hUVXDy/Q boHvRTyqM8wS8wBjItS5GErK7C3+EIg2KL5B37FP4wE1fqa2p8hdxNfLlIrYGVLGMYZ2QQHjuQAz wLLAQwWZAPTRPoh8rBT7GfEl59ddyy3qFcNs1eghZKSotzAXlTZlvSq9kIsZ8FZZrgOH4vsu7BF/ INWlJjPHjvQb+1sjplhXDL/cfZtAcIqQRSP7LLlVepKSNmssXRRj1JZ9UvjVHnGD9KIYSm2JtAdx Hne1sc008oqyTgmancfzUOlvKpxu51owHnebfTafZYR4F38HT+UJ2oyj9g6csu4/QTV1yQitkVKU 0jNKex1VpGnlnH6Fh+tx++QZif99tCElBM5QbjgPlrlV3ww/7o/1xUKRWGgC6ZsQLkyik50z1fNY 83j50IFIYWS3L132q7ZGUK0Bp5z1RpST8kGGogj+gUlfH/rVR8tpG2+kcKWw0Y6SryjKHU2kBeuy E8AM25nUlgdVa8UzJTO54Z10pjNPX1qKlJY07c9Bi0NHh09iI8c+OyC+sFN88sDakanqhO7tioFj yMBRoaQIzW7bU1mAVeSVHMmpQ+pyf4s/p/nlr4S+32hLe2oFsxsheLvXj3JQoP1Y4CP3zSQK47K7 uhiWX++hMm6yDs7OWCDBvzb25q09SPbqWs19zcKMZzChTQwOD4cTSGTKOzmNLrbNl89ilYn0Bel7 y9KmpYxpXezA5LGLDXNIyziRWEA/Hf/z3RvY3Rv/GRI3w9tguXsOHzONt07oH1PTvYm0jZaUKVHL BKEgrzArcz0De4C3y2vwtgldPInYXT3Ap+lRTpIiARTiiFLepVchD+QUguoZaxQIUFYny7kQpic0 2qf1+AW3V+6JHO/kNYwJdnWj4BTMULSAfeSPsW7K5nBgMqgDO1w/JO9gyKA1hl9vv2SI4cE2r97d yOdyP4HbQQFVAZEaoG9FPd9iinpQQu7CoISBdEUj1+ExY+6uMDFufa8jQQwCH+kFHoC0Si+q0vdR 5RrpJaW0QVnbRlk1JgbyLMewao72sn1MDI7wY95x4azg9fMcJ8AgwseY5c9RMVv1EFXdUwFx5Dgo pP4I1T8F+6wthM5wqGDvzzsqTB0maIGp9LpuOW5AGMf8Fz1DdHB9kA8HH15L2/gohTXRhB21ySxr w4xW3EnQpFPmG7kbWCho09aBZoeRIAgb4ejulr6TynxjUEi7XdIG73Gs52ioKtIQqbvQvGBcbJ23 XIaiAvz9zPLQciyRiFxFIknfPVGBQuqsYw6LqtywL47CGNXrQjvFKPlPa9IWUFsDFp9Z0AdKAlkB hPSBM71yWQzDs7Ibn6OidMIZpljZjbcq405QnI6X4cYutbGzW/9/jsv8uYnzjONNx7vethCmEGdW K2aVTJujTGlKWyh0MgGmUCccNYYEfNQYg/GR2MKyZFmXV1rtavXuvVp5JVmS5QuDOIyNSW0w2Byp SQkeCB1KSOlM2pCZDEnbX9rhJV0604W/4Nl59n0+3++nmfDK++Q3yYRZh7xeqryMmGVgNbOXpLcE 9/iauhs73j3obGmrdm/3Yd3bdzDb7Svf0tP7HBuHKop7J+rG2yYCk5hnhvrT18RNa31HZatpwx+V nuKO0jkyZtBaj4S9je4TXBrViz0VCUXSVI1MKIbVDbER9CMJga+iUFSQZx85XctLvi7TDYS/dFmc s59Ee/m0mFKx6U9FCX7bIQwPioN2frAgDthVTuUkADw4iNJcUMIY1C84+QbQAA6xIQZjrC3ThCvV NFxDwlfMry6aJbPm4gvmkvPmEpsW0iIafROuwsc/Hfv7qS9vwS24IikZbRi7AV8/AZ+ZIZLAoFMk Y4SSvkRMdmn1iU1pnEvGk0lCTsEbGvJvdFwYimeATOMx/kmBYwKWFth3RJuYEE3RQW/QaWb/V4qv M3dVmi+3vNT+S5xjYrwVKCJn3wCrfgt/UmNxc/qbn+Oe2eDxcCpqNObKBz0yJQMJA3FFBw7rcf33 Wx3LS/5ZZpQa+qj2e/kBj19CR1Dhi0ti3m5ZYlwgODEGALmC43hWiPI2PipwPMEpMZUltSeGQ98w f4PDlY8XF2rT7XrENlA/UlnckOo4XHl6tcKqTII+PjN1fx4unX5QXDAmYgXcXA8fd80FpnrGbO4F 33jYCCdb9Erdo+BABtYPlGRVUVRsMCtKScc1ATmBXkHPS8gc+gB9UlAtIcyhhtDLKwDT4rIlshwf tz6RjfjBIXsT28WxcYzlAMcRoWObPzS/Tz4wa4vzk1/Owudsw3OpySNEikuHMySre7V21Rrr1xCt VJRUVSd1K+VUBTPOi3+z30TPCrckBOjWTLvOyXHRmgRYngSxHt5rrwo3hQ75AqGQt6dzvbkVD+6n 2iIBQEX9YX/TG3jS2+csNELUVHGdyraNVo9WDdTmG7LncVlbgKtGZoYuDl22fQZ3wSXwr5nx3nF9 wqbkEFUXNY3Q40m6l6QT76YqsxjHyRrrUAQtQSRKi/2irDvu8sgX6B30mCBHEU7kAEvu7XYGwyzN MFGWYemwO3CA57p21JtI1Ed30R3xCEfRvkAjHnbWmourzGWVZpnN/K55oc4sQfgexmIZFxVl2kGP eKfbb62DGzbCl7ZCLNyNt73ZuGbvDzaZq/C2cnedz41tQ821j0jTDhfM78FZNs8U2IItbnB9IMsW fOfa7kQs1B7SOzSfRmlPCQbEEuUikjupaOcd1xLjWlLNSP3JwczkZHGscNJIjRbPXHgIkXv/mLv3 Ilz6Q7h0BVy2Ai6t+MR9lE00GeUpzO1XFcoBrDQwCDmDzBRlyXAcQRdQuA49Cab4K3KeH5JHlZyl glbJETLxHMBUy39ihBCmYi52f9x2gHXG/GyACcdYFgMUT8cJVuF0QBabZ7fd/imsMgX8/dnp62fv QgTar/5ZzWJ6Rk5liAyXsY6VNvyGM1Fhdb+wgsU4VYk5uFTcsA42A3cpCNyK/ovLxpT95qKGhi5X iI7ZfP6m/e9s271lz1vV5XSo2/1eq8/ldXs6lZh1GKAviMP5x8sWVs1UFF22fmaQG+IxMHwW3LBr 3RIVJQSqlUfooKx4HA07xc32V2RzM4+AAx4xZmctwaCtfQi9vRbwkkqGvCHB5zNI2tAMzQESnKVv HVM7P/nFw9X/qbjdfCbK7KveuPIF8/mdm6IURnmjforwZnpGaXKA+SP9MILJQfFpukT5GOnkEeqA KJc7zEVrxZqD+8QGO99FWVyhaVGOPMHGo19ZJH1Ydhbttwr5B9J94bY4b8G/FM0JOT7DYzojx1iC KnVRSBitFNokjxAAAdYWtVYPCEZjDIa0KrgFh6yr4Bp2jv3u1O7TFX2urCfnhWvMMJ5KZwv9o/A1 2ILDcpjM5ZIpybDJkqgmCINLUgmyy6jR1ycwjhWVqLWIuGGoom4Qly3c70Lhj1FNyIojEtiDA6tX 0na3AOKsSMs2io3E6firq9f87NerNq2sWFu9IdRJdUcj/s5wEESxmIs7WEuYNYr5Hb2VVH1aROf7 6Y+jcBGNBUvDQoSlSLMXNd/gEfNFlAqJctAhJHk9ochJg0gomsUu+Fw/fi4z0qvoRkJLWyluiPfh OuJDYYLLkiATGnGPmzZYh5td8F7z9HvH2vM2Sm3XanTAMyKl8BfxZ1/45hJ8pixBSxZsaaYn0E16 27p8LgqLhrqA0157MHvc4+jJ0yfYWRNdjR/obO/xshjd2ghq7a2u5GC3wztAj44R08U/XLlOfrBw 99JXUx8fOVPIGZg8KB4+Snwevuo+SbqPNefq5Vp+r29/s8ftq+/ZBnwWMLo7vB4mIFFCjxI2ME4F Wi+R7Z88fY08fXXm3Pzx+eJsdkqe56e5Il0Mj/oGOocO9TmVdkwNSLtfI4C5FjEXlQZEKtrFh1jC rfvSYbIvlGXz8ig/kM6PpDO4mlQVw3pL5txHZdrn8vUJIi+O8mNkna+6s6qlqrWxsa0e87aEnR2E M+XOB8i8b4g5Ig/zh/Xj+cnC+yempp+w5cjykr+UJUoTalrJk3dS9/KfHca0XvH/JJd9bBPnHceF in2Ptj9Qq3mDx+w8KlViLdvUvbSoRYx0E2WhXRpeHIeQhHh5wcQkpk5sc7F9ceKcfT4/Z+ecy+Wc ix1j4hwObl7wCG5IgNCskKWkKGyF5Z+qontD69q/DnTZtIv21/Pn83vR76vPB/EmlkRBBqoZjP4F 2qOBHYUCXXB9TDeY48Q5053+gsZn9+iPuxdcE97Lzrz9ki1rG7aB3EHhaC3cF6oKtOPuX7cfO9to t9a3HHGA9qMV/nJj5XE+U2WyZNqEIHLQzZ119cCh/z2zuAKVlzD6AVLO0EX0b90XWAHrZ+QFuKS5 1da+le6UJ2fNvpvRSn7q2qmWGb6JPLx08y64+YeLf1W2QWVL25cV9/H3Pi0r/AwdpqvIOtf7Xp8v HAAhkj6g/gCq+2M/jDtwoTZ9Jk/Mtc56r0U3u9/3LK/sNaAKi6XaZvHs8Jyo7D1ofOvQyHSlqXK6 9nbrGrDfJz5dg39K359exWc+WZhfKaxMrEv/Qn+n1/xz50COEN1O6Ap6fQHcT3qozuiZyGnJOulM d4ou3s11xJ2okj5xznoCmH/leHUXVHW5VxfL8VuHllvX0AJd4q5IM0MleeHaZjnPOp+NGsawbzDF jN0IFvxJ3Cc2Sm9LINSL2G7TAKbhcgI+GVhPrebAor6Wqa6CG9uwjTJMdWM1rEPLYrFL7pvVzIoX maTRh4U1BAnjnpCLcofV7/9uO+X2RkjjlxhJeYLOXlCz6+XOnxrNx6XJI6bjhVPX7Sugbdl7bxUu 8bdTi3hqMVu6NDWakbOT2amMPJxJfCzOJFLoMf2gd4kAwZRIJYwMRv1njyFWin6l7IHK89QjsoAH Ljsm6vINcnXyOPolfbjV/A4wl7f/SN0G1efkn39Uji+Vr7V+jq7T17hisiheHBLE/6/j8tNhw8aL +gP6NtrOtCJAOUM+CpJYALNgdaIl+1s8+85kTckObHNL3lXjlMxyF0wZLp+cyd6/uT3eogsy4RBs szU56jvrnbVETTegOlsiFuPJ2sRorak8V1VqWgFNK+5HT2COm+TncH52dD53a7SQkXPZYl57xFlp PnEbLdM3uqc6FltnGsdqQK5aqG/S8nhjPmeY0xforxnlTQRyyVh/v2lIjCdFmO2TfQXcN+Eea085 JDvfjA7Q79pOHgItVZ6aU1BrTs0+feHZtEH5MbWueRlAHoYMQpLxhgm8i/YyBAI2/X7azNgRICK+ IBWlKPU55jcuqKYwK2fjnfgAIfpGgkJQ7pujQHAyGxKMbiagOZuftiMrsqAdZaxOpfVn9JGMjucQ y5puDhYGk8Mcu3neAHHMzJ+hcopWXg8rz2u/OhkbCtAexoFocXsiNhDncVbmkgum0VgyPsADNo6S WcijkWgO5z6JXWUl4Wp6dvxabrYwM1PIX7gsfTA0zRe5kjatUmCcAGkfTxCQCHr9Adzn81KuqDPi iDtEs2QXglqgkFE/stFnyLZOh9PT1tsKgjaqTAUN0Sbb5oiQUtxn6Iu1CyelYxO2Cz4J+JK9qTQc jg/xAj4sXkpeE0tDU+J4sifmT3hEsPtu9RfKVvg4//DOCn73zvrEEzRLz/RNkpnuPFF0AE9uOMAa BUqgRU17BZkpGUu5TQCUaCHChwBPxohOGKA15NXEt5cmkYdujdXx9QNtcc0MI6EgHTDmK0VzLaz2 nbBX420Wa6PlnMVh8R3TyLmbOY+O0GbvyTbQQZBeEnYJ/gskfqdJ+ZZH2R/+LLxEFomiZ6I9fRqM NvHNTdBC1DTX4y11x1recgBH2Wu+V4wvviFkK01Hs9acMw+cMinLMCvmc1P4+PTtmc+LY4KUSGxi YMPTzwzlCbNkxaWGrD3vyrvlQD56O1LKTM2B6Vlp7Z/wH561xgW8eb7m4jFUQdc6z9YA+0mi7GVt tsR/f2KoXXrQ8di4vDyYXjYtj34oy1NAnh6aLMA0NRpI44HRriQhEkPOwbMJV9web4wBTt1yKP6+ sbzSWWs2NTW5G6phTcZ6tRnXlnUnZ7gvXOH5QcCxLJ+C9zDl25phLiIF061j6Cudsof5WyiPh2Vq JDjoG7JKh1MgjsWi/QIc1DxkgAWJAaTt4lFySSpIYF4fdTMVu2FEfSGqvkGp9TofIpEfL34ofyCN FMYnM1PStDSTKKK/0H88PX8QyA1iZRmkX9JVYqHduvBrdI0PupETteO3yOmAHExTOyIOndqtJ1uY 91pcGqJ36EOIZmOaBgxy6Xg+vja8nY9zGvWwSfZxTNnLPtweexRc9S0GC+dle9Y+ahOsUXvkbI/d 5/J3uNodDrvHSZ4HwS7KeRaiMnq/rg/VoTdx+m1UpouSqC8Ele+0cOFESIzsiPXownQoFMYJrwZQ ZXr1db26TR/UNMFv4jCWjbP85hw3rMrenVufGEYT0rCEJ8VUIo2ydKpXIoDkGfAQ0N3jIQic8Hh6 nKiT9nBe7SyGe9M5bavqlo2vDUXsujiWYGM5QU7L4/mL2XyqAHiOQXGTqGdtTIcfhhgv7cTNmFrA IuoN3TmWGOjF+UCuuxSQAxlKDIFYkKEY2Ef3UWG8/TRTV9HIuHsqmV3uTsZlDFMM0iAxSsdYGOfi Aoez05y4aspGRa5/EIh8PJ2HqMQo31Ps8Ao9Rol4ON6TIAa9CRtvFjajfaNe+e7OrR8ZUokRcRiX /kdy1fg2cd5hTe2d33XtprVLl5y78ybEtIlNXYsW1KlMrGhDZTBKoRRIQ8A4SQ2ulzQhdowdx875 7t779mufL/6IPzBxTCDNB6YQvKYhbQelmdIOuiFYlqqrtkr7Yqqmgx2T9qb7C9730fP8no/hXLIg lYRCNDMAsqF4fx/VPeTvD9CDA/2xXrkPBuIBjHJ4KD+KUa557O7PG25+XBjNjunVplQ1MaWcA+ia cnWBSotFeIrG1UE2t0LzAX5BGGeKEX0AL40WDXCx1ZYvz/x57L03ar9t0odTGT0blxrxFoRIUKy7 jXFLlq3HfJT1cOwHwefpgV3dz3fs7na5nPsOHepoDDIxlU2wehMGcOqtR4VKXI7LitSk5WR13DEu jSBkgKSu1Fco+c734HVCkcs1Ss6JpTGKM58lzCdsk+yJsEFHUk79pzrQbaqsJahz6rQ2nsip542l EpggA0IEUs02p016mrAesFl7MEcs8RNbRAwFKYM8CcvJ8si/by7OV6qgUjFKOQrxRjRL9+u9iR4E YlFVGXIMyhFlSIWJRvyCpNOfwU/E32HLuzArXrQP2VhhVYdcJCj02V1hT+hYcL+z5UBLa5enu9fn 93gb8aBiNFbhVQZF4oPpQM63uGF22/hBPWgEjeP1rSfdiC0GKuFJvPxyGRw8SkzE1ZqxveTG+giQ VpUcxNFrZxhRHnIoUNUofOqKgjNoEaPVNYA0Jak59CFc5OjAWOuvN/+19R3PRFAPJX3aL2XgIqFX 2P449STalcJJF8xHK3yFy+N5qXFqTIqCQ52it/VF8YUjr4p9Az3iEfvnp4Pr66cNFVtRLWllNInm jKUCmCPdop+/96ZoLX9rq3gUUk+rTi1GJ0LlSI2rsaM84gDiJZajYkKME2iI5R3lO8UtdovCw4SM wKjMKICHKjY2WVUcmFWtlnw9XsZeEVdVQxoBall83wSUGcbC4wiTt0nml4gSn2NSNKMH9C6jPd1l hBKfl7pvVzINaZTTiio4Paolco4M0tNqAcSL8g2TwobBrkRqdAD1oK44YPwq6nLUbLP6VG6sVCnO 1ObeAwivMSTq+E9Ig6odNhN+2e+nlt6+Uls4OZ0+l7ggvwXPR874J3zjnZX9ly/OT14s1gt1vS5f h5d76y3g4t7y5sepDTb5CWgFCS/qS4dpxJeYKWZ0KBNTBaBxMi5OQ5BhWTpKWvfJRNgnSl6H4N4H t9l3kcxx2GtXoaJRKt5oCbqAxrQJNKGUUolhkDSU+b9Q5j7BJNkJmqn3zRwdP1JxZvdKHULnYHv/ y32dXZ2doNtmNdtY62uE9aj0jBqgFb82kGKwDTGzHOCLOajbdVZleYrhIAPpALlHJqx5cgMkNCGu UBJKKxV0NtmEnQMVdUyNJiGASarWKc18SDBp4obtj8fffaVGe2acxRapTTgQbutp62k/4nEBn+AP UZp1m9ioHUQROhHOMxXuQqwaHWYA+v+rIgd5esMu0ePtgj323TzxMml9lSMwapnSMsSXF8oNGSWn FrWacgKhJEjGlXyVkieIlJgrUdCcJabZ0dAw7cu6UjtToGabM2ZyuFVWz9QqlxZgo/SK6I9QO2xy MKkkNF1vmh6bKddGarnJ9HiyoJSUsjwPZ4PTXVOeUbfuAroz/mOLpKx1tpgY6uuF3V1Ui+xVIrQy mBwymCuRyYg+CBhbTGBYhvaT1jdIqwm2CK3iIaUpliFEVVMQnUej2mkVFDOSihxI0uO6DpIZJW1Q iqjDLC2Mw99D8xFwyaYuEx8df/foBO05fXDkBckpuAYP97v6OjztHcANvb2UavkI6yHpGbmHVkNS TOYQo/MZLsvm2AJupMVhHtnT3CqHcKBxDWkdUQh+v0ccsHeT0CAkWZOTq4m3fGdtw3m9np+j829W Z6dqZ2u1U+dPXKl8OPyxbD4MPzu08kPwUXNtrfUg9c2D69Y/RTc/ad3nsuz2pzYWLmxy7D7VWnct gsNXfddXcDrcee7e2oZf1Y3qrGO2MnmhchWMXRm+tkLNRa74rtF9HxydPzDVNrE3v0M+CNvCbb4D xzqcnh3Asz3YbH0BG39l3fw2euvCb7w3Vy2lci/boAlaXJGw1G/nc8jQk0aTosuGQd2G5i7WnKI5 8z/EAvtaLEdziNUYFNA7jT0pVGu8NTFfxUdbqFTL07rWqOKQiXPAJfREKOk79fF6eS7XNJeZTyzI /4DLHUubwNKmM9+1ALXe/yPXFrp98569W9zAveVnwS32nc/qpU2OsDyoRDSwB7Y6KasVWYTRQ6OB QvQ14R1uhs2zOp9g1ChYQ36ftNaTlp00i4/dLzWEhQhDWVnFWqt46NRzOefJY6D99cuBG/Y/vF9d vORYuFJZ+RdlPuj9285r9M4PNk6uw2R3Rt0hd8BzzOtdda2Vu3+6e7nhJCl3QqtTtt4mdosd0E/D Lvkw3KZaJLS+LltfIcJiH+yiozAWowJoQA/RKq9BBSI2xac4g0/BBAR8dpg37IhVYjwlMERgUGTt 1izpPACFlxwQQU2hcGjJcfrTkTd0TTG05OpY0Se1W+Yj1D/FT4RlepDxDXnCwNm8yb/Nvntn+vQv HNvHW2bdi8B9NbD0IWV+sXb71gp9a/nvZ8375Tl4Objoqb86ES7JOkwqCA2j7Gj+HMZlvfjfjoZa upL5H8nlH9rGecbxrUTnl0K7DeZNOm2njf1gZA0hbRrSbqSh6Uhp0oUsKaT5USdOHMexbEtVZEuy fp306u7eO713pzudfliSLVmWospWbauO7eAsP7yFMZIyRiBhZZRtlIyxMhgdXLLbH3uT/nPcf8/L 832ez/P9GkXNPG83vwMfhq8ykTXPR+c65+ZPlI/gbWjf6WOvgoG3AntepN8qHm4cY5pHu2c2L24O XQ9tPIkX6uJTR2Px7W/xho1QSDOYO7l/FDSsqormULU0MQHmoGQ+J3QYYYGbSeQSGb82qE3gkBrT 5BX7/fqN2Xp1qdH+sL5RQ3bZgw9tp1HUxmMO0vXV9kqnW6vZjWxW17S1xnyhipuozn5pCP0+2g/D EZYJBQMpX5oVA/KI4c4GVBaHUESAqVDIP+rpA4FBdniMAO9n2OqTfTiMOYcMNc7gQOLeFS7vzAkZ KZNuCRU+x4HMUwByKAUFxgJUH3WQ+j51hLLeoJ63Dpu7TbG3/uZ0fy7U6G+PdiaAv7OcWHEuLU91 Fl3NeqHdoddDK+e7zODim52tna3tQx/6l8F4h129Rq8Wu40OM9dZbKxNr5dX9CWizrrQFbrcQqqZ 0gbko8p+edge4VmJxWCc8t8eutq3+F7nVLkP96ELUY8XeDyRi/30UN5T8zF1703PXzx/Hf3d2Ae+ tqfunroASgOZITd9InzGfZYZOTswdioKgn39qQHnrj16dZ8LyoKBykCRDHGKiT/kbk3TmkKEYrT0 FK7jp0r+ybz539neBpKtr4jW9wjFJAU7ymgeb6hgvi3hpquIpqU5DJSQFId0DIU5Ysgp6wVurxBC Ni7ATzyB4w7eatv25k6U/Uz5/XpsPl0W2+paoYQr+VodZCmNbIYiAFnAxHvAnrGR4UsDMRC9cIJ7 23lmUK96XGMzwXqiBWCTu/M5uWlRZG6xrfaUpRmxSuq9TCUpiCAWZMBjUdZoVc6oKqPKpWwzP52p Fev1em2mUW4ZhXyrtJpv6TW19HSZm48Xev9MdVAT29D9NVRxpoO2H4s/5bczR5CboOLryh7NzWSG K95mqBlYSC7hDbRmrNRWq4tzHywAZU4iGn+B76W7DK5K0xXatHF3WdLPYn9+v+HHIZlVAK8Kqkpj 3VYpY1xymTt52+0WxooL6ZqkOpW9ttQPBOub1lYavaJYjC2iqVB2ZrkpRGTQqSyqi10EWIk0J9mz 07dv/J2J8USACwtAmEGGRt/rwZJepBOQ5WLw2MCR0cOXQPDseaL0/iNzm++5+q77H5q9qpSv0nIb zxbJfSuhJpMVDUNJF2o0eXnZoA0phwxG3LQ1e4yUweaYPmNUjcggGlO0uKtJjP7jhS330V1pE3dR SyrjIsqQcQDmFoov5UXdSRwYkgUARS4lMCyMoRg+njidHIoDgeMFRLNKLBNhMKdAmf2XxdrXrK+u bl/eN3e1fm3m5uyN+U9XTFu+lV8xrgOclfQsneFzSYNJGOGsPwP4kUz+Vy6BS6s8CYkSOeF0JZfG mssEKCtOp1uKA/3nDppxqsKXz0AcSWyjJGrClJRyvgOHEpFkMj55YeJAfCQ6EOg7Zn3DDgMwyI5b W60v7O9SsJAqJSqvmy/ZrTce7Rj6ZHwNao6Uerq4pw6EDNJUOtvz/KMDHjIyjxzIhnRVVJwyL4kS Hee4mMgch24YgyDGQjaSwIT8Mpv1lc/Xj67uum0B82sWb//YBDfNZ1b+vd/cbeeKcCbeJiavzKmc EtCHjeHcuAZVoPZgEg80ppzO4ywGv6HM56hl8kEG0iRNcZQpJJMfpxCwcYmw6HOehsNxHwuI/pCj Q+qENs7Iyex4ftgE1pK9s6t5qDxy+Vr379dM5/Ra/betj0G1qy+26SJXeJrBvMY5wyeHMjEZILI/ Ci2T8hozRX1C1kIms+Jsig2pnp4Ra1JDBhuUoMoIOzGSRBJ1yFwKzAj0wgAbinndwyes3f973R7u 9/xy4BXS4IjACizhpwB4geQKZ2QirXhdoflz/zxgvhjcCK2Gln5oTey3mKHjgI+wEnTCpKREXNbB R4z1mvkZO83miRBxdUJ1ayAakRXWlVYl4kVAWlI10UX2WLv8+GIvuWgGXeox5BzOYbBIbaJFqYDX 0Zq0jluoLGUwmKUyYcymaIhSAmSi4hk4xkehgxMEQvmYHikHmQdbbxya8959sHKtVAOlGb1SoPNc PmowcX1UP6kDISfks3S60sAaypMtcLRQU7qMS6guLZKqTSldca1TRkqGCdKaJ2XYVJyfFAfhUPRC 6P2Qz+8btbZZB+3mT6zX/vDSlXenwo7SZCleYitsIzmfAlEpCemklBSSTPyQZD0D3eiwUwwGpUnS Okn2u9I3bLqeVgxXQ53W8zmQIbQz6NzArVc/Z96+7x1znx8+5ZgYjYzH4+DSWHx8kk6R9Moxeqqa 7MDZVIk3RCBHJZajU6QMyxw/KZ083Ie83iBZFBiV8KRLLCBDJ2DIynlckB1X5O7UfKPTePCZ+az5 gvVtc4fdcpgvCzLxLqqDVcNqSPXKQTmuPqHqz9XHrd5iXsKGa4O6iz/l/0jGaHlevOyUCaMRjbgI N8G7BUc/HGUDETFsJ0RQY4wSV2NqdOrYwrbr1neXftTZ2f5Feam8Uf3938yYffrXheu5W0Ct/j/t ABL/jJyZGpOIlIGVHoKSepNxlFyVcZKIjgiHjYiSlRqOjZCMkY8IyAbOBu8GygabBomQk4uWG5GI j4aHGoSHiIWJHniKZYJtf3Z9GYGBgXqCcIh/h32EfoiAiH6EeoR2hHeBc39uGImG+zn8VPsP++WE eYF1gHIZdFd7cIaGd3B6en2AWHQYh4CBi38bbnWSmX0ffpiEnqUaoZWfoJ4ekY2RjpGPmY4YgcWx hpgbmZKVk5KVq72nwaHJCKPIlbalGqGEq3y2HvsG97h7rlv3Dz33ZRmHmIWXgpVJqBh2kQWBjISQ khqQlQUO+qIU+jIV3WEUHQplbmRzdHJlYW0NZW5kb2JqDTE2IDAgb2JqDTw8IA0vVHlwZSAvRm9u dERlc2NyaXB0b3IgDS9Bc2NlbnQgMCANL0NhcEhlaWdodCAwIA0vRGVzY2VudCAwIA0vRmxhZ3Mg NCANL0ZvbnRCQm94IFsgMCAtMjI3IDExODcgODEzIF0gDS9Gb250TmFtZSAvRUVGRlBHK1dQLlR5 cG9ncmFwaGljU3ltYm9sc2IwNzUgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMCANL0NoYXJTZXQg KC9HNCkNL0ZvbnRGaWxlMyAxNyAwIFIgDT4+IA1lbmRvYmoNMTcgMCBvYmoNPDwgL0ZpbHRlciAv RmxhdGVEZWNvZGUgL0xlbmd0aCAyMzAgL1N1YnR5cGUgL1R5cGUxQyA+PiANc3RyZWFtDQpIiWJk YGFiYGRkVHR1dXMLcNcOD9ALqSzITy9KLMjITA6uzE3KzylOMjA3BSmy/CHD9EOW+Ycoy29JHub5 PCw/5HjEun+Xy7As/nmQVW4B4//ubgjJw/49VeB7Bv/3bMHu7+uFGFgYGZlNPJPcTXwTk4vyc1NT MhPj3fLzSiAWpRbFm+gZxocHxGPajUMQlysZGBhZGBjbGZiAFtp38/20+XHl+wNR95KgmDi5mJjg Ercez66gxTE7OWJ3Fh05J3V28ZGdu+R27jqy6HzPha6jJTtjOXbGLgpyl+pm5wMIMAAq9GgiCmVu ZHN0cmVhbQ1lbmRvYmoNMTggMCBvYmoNPDwgDS9UeXBlIC9Gb250RGVzY3JpcHRvciANL0FzY2Vu dCAwIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IDAgDS9GbGFncyA2OCANL0ZvbnRCQm94IFsgLTIx MyAtMjU2IDEwMTQgOTA3IF0gDS9Gb250TmFtZSAvRUVGR0NLK0dhcmFtb25kLkl0YWxpYzA3NSAN L0l0YWxpY0FuZ2xlIC0xMiANL1N0ZW1WIDAgDS9DaGFyU2V0ICgvRzcyL0c4OS9HODEvRzE1L0c3 My9HNDAvRzkwL0c4Mi9HNzQvRzU4L0c4My9HNTAvRzc1L0c1MS9HNzYvRzY4L0c4NS9HNDRcDS9H My9HNjkvRzg2L0c1My9HNzAvRzI5L0c1NC9HODcvRzc5L0c3MSkNL0ZvbnRGaWxlMyAxOSAwIFIg DT4+IA1lbmRvYmoNMTkgMCBvYmoNPDwgL0ZpbHRlciAvRmxhdGVEZWNvZGUgL0xlbmd0aCA3Njgx IC9TdWJ0eXBlIC9UeXBlMUMgPj4gDXN0cmVhbQ0KSIlsU31QE+kZzwJZthbw69CwwY2tY3X0tKBg oJ698wNXUPRQvJPzEEUR8TAQAiHEhLBh2exms5vNhs0XIQRCQoTLQTTnx2HV02P0pvasvR5jb+bG OXsz17/aaf+4xVk6bWzn+lf/eJ553+ed3/u+v+f3/ABZVoYMAAC4omI/uvfgZvRMx5lLbZpzWys7 z7S2nC1Sl746rVhQZyyUZS7kZ1lyMqStOZl/z8laKM9ZtVi5GC6E1hRm75YjYdkBK/Yvmv7fIidb nFomPly6IFvuKlT9foVMBQBZ2Utyl61cVVCo+vn6jZu3Fpeoy994c0/FgYOHa2o1ehJVb0PLytGy YrS4FFVvR0uK0PIitGwbqi5BS8vQsu1oaRGqLkVLi1H1DnRHulKKlpSg29EdadAOtHQ7qi5Ct5Wj pSVomRpVl6Pq4uo2TVtnT3tTw5aGH7k1/Jfbj9v/Q1kG5GbKlsrWyDbKXpdtA0qBX8n2QUdkNRnH M+oAGeAH7EAIcAA+gAcGgSAwAnCABwgAw8AYYANowAm4AQEYBSiABVyAFxgCwgAJMLI16VbLsmSg 7KhsLiOWeSrrPfnz7BjkX/JDTl1uXV7u0v3Lfrn89MqfvVaRX5b/7er1q+8VmOH3lbnK54WfIr9Y vJmnyVsrDWZ9fvWjMWFwKhqdGIpDwzF3dAz29Q5pxpCzk/p4FJ70XYlMIsPDIWHMEbWPWUJdUPyi 70IjXKOtevct5N3du49sOoPFFXlrRe/Ls/kfeqOhMBIKjQtxZoKK9IX1ULhT6NTBGkyr70b0eq21 1dFu73R3hyDDMBaJw3S2VPnP1fkTnsjIK2DEO+GI2yNY2ACFu4WuTrgFa9MbEL1Bh11SdnQIIb1K P9L3H1zey0Wx+3E+yzOC0z8j7o2IK71/eiT+ReHkuSn+4ZS4S8GPc9POWxBH84OwMCBgPILxTdwh 7jCn8LNBZwgRc0FxI/icenmckVNBH+VXCnYvPeSgeqyNpmr8HNZq0UFdBqfLrBr4aGDUB9ujVMAF s6QbH0L0rJExMRCO0axZ1UtZ6D4G6gBbwSrwLbAW7AGbQVM6dOBm0mgz23upAtyGkZcJu5EwWLt1 0nJFt7TEpjHtxI4RrQUY3Uf1I4nvOV58XSW+zf+VE9gYF/b4gn5f9O70i09dCryxp6JtPWkmemyd pBFvtzSnL8bsuK2dMBJ9kNFAM0YV5ZQ7GF6AWQ8zOgWniAmzD+n1avh65hT1Dnl4oH7ggK2EqbQp DHY5ZTRTmNJm76ctDuwY3oR3m4/1n8Zba6VbCnv6OySMs7iTQPyYD/dSfjJCJRg3NURHGJeNp52M uIVXJB3ycTBpv85+Mgj5AywbUn0z+FX8t7Oziav34/NQBKQ8AiUo8Zb2tSelSojau56WCpXSBvA0 KK0Ai8BNoNQO1oE7mBJKfjX7e+5zjzw4zvKTqrTAP8SS+WFulBvh73PT7qCfZ3iXy8t7Qk9i4msp cWdC3DcpHvpMvKbg5uSswAge2Ed4+lyIkW/mjjOQFewAMcrMGHmH3xlgQ5AIgWI1KJaBf6wFKYuO blGesF9Mk+/vt1pw00CPVvpJg9QmLVm8qdBIa007jTDpsDEkErROEXftV/AJ2wjJNClIiqBxpQ4k Ne9RFUrpTU5eD5JmWtuppbXKZHowvxXXLHyd/8T3dOIrJPaHxLMbXw+N337w/M+x2MPEdzdmgrOe BxwUDDmco6oIE3IEGHENJf608h/SKujZxhmpQNoFH7GgujcQ3a7mPe8fqEdrqw8frz5a1Yh2Qjq0 wrJfuePXozf2qSpuHp1rmIeO/O2SmCeuS3tCTC5+kD/WFbocHAhak5b7pgA+QkfZFKOYD9wZigY/ jqQSydk7j64/TTxLzEd/5/sMisx7nj6G5/AHlx8gvffNSWxYd1M7rYlrYi2Rc8GmQONgg6PCjhqr LlRdOFZfX1Nfc2p7owRCjRLUtW4LvD5YNPkWEmycqr97AkprtpCK3c7nGY7hmS/YW1xMCDt97kEv 6xyM+G45Y6EXCXEDd4W/5p51Cq6PPV86BD7l/xKKiCvYa/JJscD3YgZ22jmbkLaqkdOxEGmlnb2q OrCLkptAnOpjejmI54J8FKGEq/QXyicPaOaWapa6Tz9iIlSQFpjH1EPLvW7W5qJc9qdnFclL4zqP OdI+fNF/Hgo08eeb4Xa7HjchuhJMa+4waAv6zZdNXcZ+zIrjxPnWU9p3ujvMrf0tVBXWbMMYK2Vk 2vl6rpU38hCfzTJudgixhRP2WaUQoNlR1W/4pDA2dHcsNTGVSExGU8OfQEMJ/vo9ONk3051C9MnO K22RjtGLoXP+Jv9xVwWjo3SklujT9b16xJA2sal4kVDUSi6igdCQxgKbgdTbukmdzUhYILKdMlhg jLcKBOLBx4hpapqM2PwDkIXGbTCWTiRiPEdXK6UT4OFD9H7l7fQA6uau5weDHO9XCdQoOzl4NR0j Ad7JsQzLON3zQXHT9MJyRVjc6RUz78ABNszFEO47uUB6rV4EE8wek3sPe8plSveft/E87GA41oMM OtxpXSHq5g16VjkboxlBJd4FU+DcbRxLqVLmaf1k+5XWsQ+8zZDnvEujh1FddV0NcvLtnTVS5tHg pW8khbhBMvl1oy3x+vjJWEvUOG74EJshQwMRIkYSjQpdC9245xjdpJTWgQdBDMQJmlD2c4QQ/DfH 1RrbtnVGgcKyOOzH0AzeJDqlMaQ/uhUJ2rRD92hWr1nrLejivJDGkl/xI47jVJZs6y1RokRRpChS IilK1MN6S7Flyw9FdmQ7djLn0TQ1mrRJgwbJhm0Ftg7FNgwdRgdMgMm999/9dc493znf94EMEwpy dJqeD2zUhU5SiSCa0y31fITyQ1cP/0s6Jq4ouhwq7OSOYORYQCcVFCbpiK+3HnMEQoA4hVEYNO2c xRbwRW8ZL+EAbSddWP0L3YQLIox2EmlGLCSlaxkaIs+++R6pVveQg4ij/ox7SMrdQrEkw4Ihf726 IVK+rd/dMN3kscgcZ9HTHSBKYgQOmaTX3BKAveMdV1rkSXQKX6QmiTK9Fi7T89HF1FSkmCzmFxcz uQCXuhCbiSwC0XJwZgq8oV/vqkDdi62Te6h24pSnz/Gtl+BNsdCUIhK+BBHcf6FtVT2nrziqBFBp XMaXgrXoJaGUSKbzudx87jLA1zVcANO+hDcGYTmkZFuwz5uW9Zf3ir0KW9myYvoQQPP47EXwSmQ1 tQxlqqX56ky1tJAuRWrhFXaV+or4yvj1INGHDSMaR49j0K41EibSFgCmXVXbGoTmTBltWjs5HB70 H/Qdn+g9DfR164/+BuwNDoQGIW5g9ld/kICpo2l19EwQiYxOqoG0itcgYNBAGfXgy+da205Ab+2X vjskvdS8b59Q2tvCynmysBAhq59GyERup6fvbvhG7N/dIDWtZuWzRI6MUzmPYr5RfBW9jnN4zJvG lX5MhpFe3AsNebT4hN/kht2oB7F4DITWK31HgUnP+00yDanC26A9co8EyA7KUanXIzXIXAQCg7lU PMEL2QvpXDob5mKTycJs5dqtR18K9cNHgap8ZvuHMuZW4P6fwbQ37gpDFmEsMhiCKReNBIklBV9H VaGA9cY09SEh+7hR3EUwVJAI+lhcOSxHMFvdvSrniNOGAHbYPdoLnsNeQaQfQ9gbeKcT1MlzxWw+ mUmnP3kkNohQNBpPT04B9x6WVwWQJgJYoJ57MGfixjmF20HRcAtMWekJxhdR0HXzCRBP3KZk4ieN Bp8VQyA3hvpwv8YziuhgnX3cPG7oUPV2n+2TEtLnigmt2Qg7YZPTBiOY1KKASRtugWySTeY7R+it IM8xdeTi6+LvFZFQOj8zx7HZQmVtMpFIprJCKBzhBPHv26BC/IH40lwlO8XFlQwTEPwJN20PGoI2 Gq5fjw+mJ3jg4mP5xcZKI/GXm+RMM9bRbug3G+zK82MHfiHtkl6Q/vMUUpzp7j8tGSROQqWEzNXo dpD25qyciMsoKsCD/nDgo4D4XERsVSzJ/fMe1GrWjSkJL+K0mM0m44ReN9S//0XpRekNDEWcVhh4 X2jktmW8+FgQv5HRi1SGBy/Jr8qJGBZ3x/EgGnQF3fUBbdw/4TP5bcEdPz3JPKGaGDaIUzZ+nsuF hCwdo0KUQAjuCEwPKFDCi6OQz4M5UJPboGiT3h392fghQ6fSoDarrCprh20INuEehZfGWRwq1JWL Z2sbhVkuyrIMHwyxLgZlPZYPNIOnO/tVgyMjRsCum0D1zbCDZj0tKOPlIiBHTzJFKH5JmGJjjMBn +FkmHptJrsJ2q9GkP3Hw0O9a263WgbFDGr1Lg50jAJ2ZYlwtFs4uIGnAI2D5GXCJX09ch8p/K9+d Xb3xxY1b12vXV66UV7O385uxGpUgooTgE3ABE7x12k/9z042TdLRoMCH6GJqdeHLv65vhKP1ib8y vc7zk+XijcIDBb9E5zgw5UlaUxASMgd1lI4YxwzuHn3/6OBIR6f6SNe73QeH243dgK4NVn0AjrIm HoZCcAyNUywhUEn628jq3d3wrMkUHmXP+gFzI11IEhXyJqUUiBr5kCJgw3unJfmbkl2BjppPag5I cum/CvFH4vE//XNtU4gq50uldFGoLwNsksoTaWdyAiici5wZAF/Xv9K9F+rZe/inB95Svf9r9U96 AN2JHni4eUDDJyd2doLCNDjPLQnr0FXxiHhq+x/Zz7NbyU0ln6RTcZDHwnCsHtpS627phaY0kWEz 0ZX8Wm3zzuZW5UpqbvnT+c8K94H0Fb62DMaxKCxAzoiFMVFWwujRO/q06s5jba9Jzx09oOvRdRtO WY8D1iPIoBk0MlbBCQn1X0hSO/yJ7a+ffK/JzaIcynsDWAwpuHNoDGNRtl6OO43fqtWoj6tfVUnf BzqkXbo9PwdHmAkGgVikjrHO+UJ0ulgtVy9Xt4B4hKK4lmSj127WDHepD3Z19ukAbV+/42zzeT2f sbQYio7aFrgR3co9hPJfLD5Yu3f5s8qV0kypVMnXctPRKa5AFYkCnBoHMtqw5jyoxyxOJ4Q4HJid chMIZWd3MIu5J2NP4Kb/iXeZMJMNzSgp2s8EwXiVyUdAFg8hHGThz0f6wkZGwVwQ5cSD0EJKGW0M ERwZorx63O7FAFR+QCJflu5ZjiF96LiyvjoNOUak5qe/VAT4PP3x7X+LzysjaAgNetr3tb3degLo OzFg1jajLpJGWnCaYGgwGVnJ3Idy92IbbNliGdcODx5++7ft73QBw6puW1+z3sKl7S2mIlK9Bm5F 7xTvQYnq1LXFu5U7yzfWNlbXa3NLuVq2Ei7vcPakHYIzbo6N7xjg8LO2pjwxFZ0r3l65eXvzj5sP K48zj4D/c1z2sU0cZhjfV9htVdGmLZJ9rs5MrB1dt7WMUkpXKihjiKhFhEBJE+XLiWMcGyfB8dfZ 5/PZZ/vOzvnOZ5/PH8fFju2LcexAEqckS5eFtFkRY6W0UqGbUNHUjW3apEnTejDzxy78e9JJd8/z Ps/7ewufpVYFMI8X4ALkzns4RPFnDDPCRrvBrB9wjJo6ew/0vTJy1NEB2NvRfgtoZicyLigDXwjk H5u9LkdludXV7mvvAHuTRsEKZZzZgEhlSI5KxPMpkU8LuXQ2L5SEIl/haoC4jeT4aEbjPNxz5PVj QH9vt6NTc86SnbVqLQ335m3wIrOYWoG4K9w8fzG/XLhSvPKZ3KJaW5upMmxRKGan+SJXZopUnax4 imNAycIbdOBQQG83QK5h+6jNs69DheHj/kGfDjmDtGHKV+Y2WqfCleTihWn2ojgnZZJKvZfFaSVk EsCVY1IVFEJpLANhvI9Vdg3pwqxOg36oXfcLc5uzCzNu/Wjz6807j77aygp8jNVIRXhE1Ca8LBrz A7AgBHIaqZatzmnn6pU16UPpRvnjqTt/l/+nYvNMkZFuyLRKuJ5ZScxgZCCKK/QYDkTdGo8hSnVo qQuTCsgpdRXNUICs3la5X/vz3OfF1dpqY2320vzFK+UCJzFzVIOsoyUbULbyVhsIhzwopkwxEvRQ LhKOK85xmIAXiQzOK7ljMNo7iUZ8YYyAUYfTeh6xwmbnEADrHCftrzsO+noIuBxT/YVgFJtyMXVA ITcQIVHCCzX3bDM1t7/SvEM4Q96wX40Z8POE+3CTVZl3mw6Z2kfadW919xmNBuugB/BZz4YGNaf0 ySmb1iGiBVKiypwo8luCfSmbOlo7GyOSZwog6DDLgQk6GU9ALJtLlVIzqSVpsxFgnaKloq+rsHRA xMsAXgyVZsAFdoFbgMSNwkppoTxfrpamxUyBL/ONTD0uKb7XfLP2gqeMS1RKUS0XA7IcRTFakmWj nIa2R304iJM4TkBY2B8NUR5ynDYmEAqNYTRQ7Od6usFd53a/uRc6/tKRzv2wHjvntjoBPBDCfKBN sFat0ILjknPWc994a3BFB/xmuNh9HBzBLfB5CB4dtw5PWN2D3tMIgJzqDHVqXjhGJ3Tag9mT4kBB N22sjNZRMThFTlGVbFkqLlflJzblrruKIPL3Zam1Qhd5cYpjs9L0cmEpu8hdBop/4j/cAOt4yZOH ENHFTSgRtKE2q2187IT5OcD8E/hQJ2hhrRkHlLYLqEhuxXnHo3ut82d/PfEBwhEpMhHmiXxICgOR xqWopNl8LyGuazfE+lQ2D/A8IxTAuuuSfh4am+6o7p0fFsxpa6bL0zb+6rDObnZMwHYXghEEDhNu 0kNZOKvgeNyJ1x787KlvfNnKlOVv5m4lCpSaJVPRNBVyqsbbTjZfDox7h9ydasuz5hdNB0YOWPZZ fs6l0xdy5b/K4O371377Tm0pt0DNKjGdtgBFC9/XDh5wvaD/IXT2B3373m7rOjYwYHABrrMjAYvG 6mBSqNaVwwQRZJkEl4CS8TSTU7iEUzgjEUqhOTfn58Jx5Uk2K1aWNlbkr63KLwFL8vem/nETrIdK WBryp71xWGl1P4GGTM5h89DAUN8bL+9tPukym4/1PtPz9LlfwkN+R8CLhYFQACXdGrePiuPaIBNK cGCMySVnoE/kXzFsLBnj1PLsw3cX5W+18NN0jgOZCE0wUJgOTHpj47SNmUhuabRvS6Jaaz4xJYiQ IOSThclCRPRnESAHx2EXOBqw2R0QhthCZspBwiySBpBMUCwpnN/zqK81gmAkrhmxT8Au7zmLeWTM +Cai2rh97XcfLd9cWivMKxzDh+JBgPXRGAYanB36VyECQ61OvW7PwP7ug8gobHGaAna/J4ABdj02 5gHxWJgmoJiSbJpKkKlYOlnkKmJdqkuVWvEy8M42u9EyNNQ/3Ndr6rIq75gU9e1wjMO0WHLrxFy7 /K9P5Z2QvFd+X6jyJTavjnEUGwcpkiU4BR+273gw+FTLd1rp8ufkjegSpV72bTM91xIaP/528wmo ubP5b+vRgR+daGrUZ1+caHMOwA61vddndoIxV8t0JTU9q12rLDcaqwDPUZOsNh0Z142aLTZ1r85s dQWGxofdBhRQVCMmNGiAige1IZaIc2BlXYb+K0eg+sf1e/V/Xpf3r8rfrn0y+1HpRm4TmGSiDANy yprmIB83lupPP57fPz747sNjrTGSCdNQhApPEpSR7Dj9WvMrOKlcTxRB4lGMypbL9bpCG/P1BWlh Zn6qnuVpbpJTOppmoqwm7WURFMSifjIIRfxhFEcc7R6dz3Gi+bQKMSIGryHOxNkY+8EX1+/dvHvz 7vtXr1SqYpWTqAIpBHkUyCAMAoNe0kdgUHgMM3j63D26Z482d/246VaF0ZYg5acD0ByzfvXWfxYj KrvB1Nd7xqgbMunsgNc+ERpVyHmSxbU4G2ITYE24Wr0NyaB8a11WZyQ2T/GKP1E+A8bJ+NZ8xoI0 PolFfEFvsNfc3Xn6yGs7Ow+N9R1utrQ1t51qtgRgZWngQARGo34N5onGbFpSudxokKG5eB7KNS7d 35R3FK5uXTx/a9kutz/sevD71ubunqb2+S1/n3z+p+27NG/1X2iYtCOL8PUvwPcyfyjegUqf1q43 1rkUl04Jc8uNy8r6uviusEqtkAuOqh6o6bJv7FGG/pHv0Zn/d1y+sU2cdxxn0ZKetKmVtnpyztJ5 0jSpW9uNdpkqRiOY2g0aKlhaE7oSDKYkaYhx4r9n+3IXn30++2zfxb7znc///8XGsR1KTEwISSiY Ukq3CMFQNWDS1KnriqZJezNdouuLnXn9PG+e3/P7fr+fr2qKtSUwKIEU/NVINVRJVevXbmw+2ZA0 wKbUX5Z2PQQrZBHNQHMpND6r/NmkfUx/eFD3kxNyPzAh9zh/dRDsBnLzW1xVZZeiK7EinYkozsAI SpMRmFiUjvF8PMfX/i2J6uSSeDHR5srcAl8B4mW2K+XuTe6fyiHDLTy4ImnFltgW2scxg2cC8yve gQYsKEoQNEn55rFYSFTzMYHnoUbp8YL0XLP+KNNh60JbrIl5gOPCEV4b4pPhvEZ0xTAfSGK9ZAD1 maGAm3R7YbfeM01iQK1I03EtlUhTBU2072KohbeQjunSWEUPVEYTI38AR73H3ccg17Hpox++N/Hu ab1+Qj9+2jqOA6bXj2FmDeygY3atjTVzJsE8clJ+5rD8xpwieB8C+F0khoM0Lnh7iVw+WNIUqUIo oxQ0xbKoKKYOhgKBIERb4AiK+0KExkrJh5jes5YQBWtphzMCa8ajfZEozdJdS9v5ZqdP9eetq/eq D4Dz98U7HbBBfuS5AAWyniyStuUdSUdiUjwZ0ykKQZwhi8Yg/3hC3mXav0f2qwlHEA4iAOWhFLuy sojog0rumu8C3aQabF0sxS8v3tnsavOx9GjHroKdDhi2BwjjqaODZyh1ZqmxtvbJ2o3WcjNfTJTj VSZDJJQeAbBe2oeDaBgP4BDxweyI9S3rAbsOHhuRn1UHnIKY/ah2q1/qkQyPpefXr11cWlEWr0qV 8bITyLk5uxU85zM7ndCc20lYFVxC5728P+4vhS55Up44GkFDc34MNxqHfzEg7x6QX9HJ37EfcRx2 nULtAE64SasGRhjWp/WyJCeAwnw6loMW765JP/qTNHxPmlLHMkySZqMpdZSMoyL0lIp7pXdVDapy Lj+cMPIOwc/PiWQ6Ug/VxGoNKOb4+ipYx9etW5Dxa/eDDvhFYWvlDrRya2vxK3qZWsRLTqAEC1Yz CCt15SnokVhkOmRJWRv2OpJThsLgtFtBVQxH3QDq9DusoPftxGDjxQs/T+0PjgBjng/tExA8NmnU 2wDryRNzxzU6Q6I6rZ2pzjZXwGIsJ6QgPpmMZZ5ivGn7uzs51Tt9M5GhUO9cH61kL196Qt0MZ2mx LBT4bGGp0C5ssiKXiqWzVD5coHNUOpyhI7Nqj/HI23IP5J8lMcKTpfgwQwPZvhr15XyvLezygGZy ijIo2wKjYUIzRbqCZFB+49shtctg3KeXe4BuYgWgRChPFYRKqf/2RufWx3dFX9wfJw7+ZnRkxmI2 T5gNFsO0ZdYbBPyzKOXWIBjD+bR+lhTSYD693ngIrf5XenH7B7mNdDvR6u+6/0vSe9uXVVNUr69v +T83Hm193qw1UjU6T6V9KaQbzw4zOBU0+U0QYXSNzgy9LMPq6SFknMDQM2ps3GfFQT/jZbwQR3az 9NO6+q+31tv5Smvl8s2NB5VmbllcAxQyX1wEm8RN5G/QIl/JFaF0KsOl6SyVxdMIkHVxViP4a8sv j78AnX1Tt3ffwG9f3XtgzyhgOWPwnNBgylo5tW7Rm8yAZa6RXIG+kN78XNrbkXYDfCN6vgiKVMIf h0iWZAgapRCPy3ZWf+6d6QPdP9telk5tf6OyiZlPK5uNK/2NdrPUoCtUwZO2ARkrd3oYHJodNA1A pld18rOD8ksXhdXyRuv+tdudq7eL1fPt+ieNTrbFloDEZXZ1FcwFU4QIBWP+KKEwlC/YBWIPgsEn XlCb86XNwqV8vb/aKlTSQoZPRhP0gvJGEQFK07z+MHjINTAu90ET8jPvy7uO/FT64XWp56t/Sc8B f/l66X/S98D5cJFagwpcQSxBShsUinSZyhEpL5CeY1EYPOT+3dQ+aGrw6Gv7dh9968CRPcfen9xz Uv6+DsDGHGRQE1RQANPyiksxEM3EOD712T+uPlZg4F6hw1/SvfLHg/oPhg797Peyaj8wOXwKmdEQ AZoJaIOKC8bAeISj4xBDi5WFjfW/L90tXF95Uv8y9xBIXY+tXQDzwaRPVIZMMF4aVxSFIZjTZjAd 7A555/7z21dU/weN6Gt4CmVuZHN0cmVhbQ1lbmRvYmoNMjAgMCBvYmoNPDwgDS9UeXBlIC9Gb250 RGVzY3JpcHRvciANL0FzY2VudCAwIA0vQ2FwSGVpZ2h0IDAgDS9EZXNjZW50IDAgDS9GbGFncyA0 IA0vRm9udEJCb3ggWyAtMTUyIC0yNTEgMTIzMSA5MTIgXSANL0ZvbnROYW1lIC9FRUZHRk8rR2Fy YW1vbmQuQm9sZGkwNzkgDS9JdGFsaWNBbmdsZSAwIA0vU3RlbVYgMCANL0NoYXJTZXQgKC9HNzIv RzgxL0c3My9HNDAvRzgyL0c3NC9HOTIvRzUxL0c3Ni9HODUvRzQ0L0czL0c4Ni9HNzAvRzU0L0c3 OS9HNzEpDS9Gb250RmlsZTMgMjEgMCBSIA0+PiANZW5kb2JqDTIxIDAgb2JqDTw8IC9GaWx0ZXIg L0ZsYXRlRGVjb2RlIC9MZW5ndGggNDcwMCAvU3VidHlwZSAvVHlwZTFDID4+IA1zdHJlYW0NCkiJ ZJRtUBN3HscTIbD1+Yk2ayi5a29O69OggGjb6dSKRtRqRaggWlQgECCEABLYkGSzu9nsbnY3T5uH DZEoQUAgNBEEEfSEY9DxoY5t7Xijd3Xam7ne3M1NO53ecrd27uKL3pt79f89vPn8PvOdv1SSukgi lUrBvXv3qfYd2aQ603xGq2us2vqBrqFKk52/6+Xyg4XNixa2pCysTRW3Lk35YWnqwtalr4r3XgQy X/lDZvohWdYFyX7E+h+H43/F0nShfaXgWCGMrGIz1xxfLVkrlaamL162cs2rYKbyjd+s37glO+fg sSpV/nbVzm2q/BxVbrZq53ZVfq5q13ZVXnKyQ7UzT5Wbq8pR7dyhys9W5eWq8nep8rd9qGvUtXY0 VVdsqfiFteIl6y/N/x8gkaxK2bA5Z8c+1f7CA4eOHC0q+fikROqRUlK3lJX6pJw0ILVLSSktdUr9 UkLqkLqkXikjWZ0UI1kkkUmHF7lTJlPvy7C0F+kvXilcsmbJj0svLltYPrSif+X86ozlL8aWL7y+ 0JYpW5txhRgiLhE30dv2h3SUusv8wy1scgqvs8ISRjhAy8eoefwr1GNytKNte8WzcvgMiRM2EgOT L2VxQCwYpCJEX5bxc3s/fBmKgZ1sG61nAdzAODXKI2whW0C/Te0mD1AY1FpYKaYVi+/IT4trwgRP BWhQWEJ9Q99033LGPDzHe7tC4Qt+vm968jnAp82lQYfNp2Bda4HxFGpADHgnbsUN1kZLFVyJalEI a5UXpDE+poeNcbfpBB4m/BYO8sBsOZtHb6DeI0oIm8EOE4T+7bb9xtL3xXo52uSEeKSn8xkmKOm/ Us88D0PT3PWeayN3xufvzv0RuBimmaCSI30OnsHaMZPNatTKfyseLRLTZGSFxtGsUK+nOTFHKcoY MZMV85h3yfWEuAQHzqSJK/DoI57pYxJu8EvPzcAgHwoHotyg0+eOeAcCg3Jh1cKyUSH1hpCXEFJj wkqGpV10ACTdiMvEAjYry8LKGk+tU8MCFhPNQsrBp7LlIvG1OyP6Oc/2uoY4cNo34o8GI+fDA4FE Qlgsfyq0h2duCK/1PmTc4FVBfnEmJqTxEzLazfhC61oDZ71HnIDJ4mBRZd+3wgg8QlygOBocpe6x 33pu0INMkCFMdiuBEWabCYW0sAZRo2pEi+pRaweshxsQLdZqh4BKUdaQaziyTeySl4uKQrHcVEVh JEahYML6qW2QcCczMESQbTiEmwnEbrWZAArBHTZFG2Em7QxOoozFCaAVTu49pbiHrSGPE3tx0PZJ I2VSONKXC0cXajNTH2VEnwgW40+MbDTtKpkkdN9MEgbo59QdfBS9Y5o4N6Dr10bOeku4Y0QZ9Em1 uHjf5rf2bNrz6xoxlQHUZI2r3lfv1fEtEbbb0+ePAUSYdwQVQcrv4Og5aiY0NfxgdOr+4Hc99zy/ Q8eRMWhAH6rtPuUrocupaqzJjFhtCI4B4tYX9cYq+DRlxc0YBOp2nRZfKxa3YecQLaIGhWMtBEQk zwRJGDNbIchuJhHGQFYzRa5i10FmN7OTfAd/FwEIs4HSKZxhlmcDjNPlc/GfReTX/WOheCQY5s67 wqyb8bA+V8TXHxz9izAs/7vwSHZd2Bh9xq9jw0QX6sd8Rk7vKuU0HsgDJD0ZM1N/zkwVMlpsGrgi y1Rg+rhTTZpsZgSGCfleJ8zIvkHmO4az6m6V9qnoQqoIKq0tq9WchspNFe6z0apo5WfVgkQTN40b pvRTTTFdRHvpNH+WUQNMJXrSUNx2sO7Dio9aNQ3aqqbmc5Utpc2ljWWGchiwnDiMFyhOlXj4j5Ti opiOa/diHEjRpNu/zhlgXaHJ6HOQH/dddkcCCfl3tOd9d4XTBHprQrqw4XxbtOMyPGQewUfpODXm mQpNhyZ6E59eifUmglfDU9i1hnHDpUMxUTIBiJLxgoQ6VhNrm0TnsDnnbHgm/uPDP3//+IfHwsq4 sIEZJq/h88gIOtk5a3ip5Ff/3id0Z2A+j51V8IgXcaOVqoNFO04AJ3ZsbH1Dsf9wsL9IeayvKt46 DcWQq+wt9qZn3B/vuto3HZ+Nz9y4NX/j9tTDxJOBJ/3PQl/TQjr1uH24FoipfTVmDaxub2o26Nt0 1nq6iTrnhbqhMDJITQCXkR4Tn2XyGzx65hB5sEl1XFVStrshWy3KHDnxA4nCufondIIacfb7Is6+ YOyCz3WeH4gC/T2REMe95P5qoedfwYzRi/FQLBDzTnJzHmA27TF5p3n6hL9XfuHB6D9HhZSuL5FB kAibvMkPtaXD5TUru6Z4NsxEaDAy5uHvKuPeny72sEHWSYMU63a4FEbKSuBZNiMO2QxQmf5dsKME 0XaU1b957rBVZzxjKAYJC4USNrNaTsAkQtgJ2G6ydbQXy1ED1mZtstSBcI21AW1KBtxqR/W75Zge 0cINPrTPNknyZJDkKMDiwCgii8JsqNWiQ+vtDcQWS0HnKQNgOWfCEYUNdbBWpcvPcgwTmuAGaB62 mbB29HjjyY5KBIArK4hyRf5hfrhSWTRZN2u7jz/wfdH7dFJY972QJmT/LannTz+/lcETQcpL91BR 54Cv3zsYGol4u50hxvOFoB4V1nATgTnsWvOQfrC6q5RupLQ2rRXQwk3GlvZkfOuaazUl+hPGCrWY Yt91qajv6FTdI+yl9zeFyMJQRmK270qk+/czs/+luNxj27rKAI6AmguM/YXhuqnqClSEEBVDHevo 1q7rEO26jkLXNm3IY2lcZ2njV+JXbN9rX18/7r2+D1/fh68fsR07fiSOYydOmpeTNF1K1q5QKGMP JARiCGkgBGiTXHY7iRudP4/06Tvf953f+Z3FzepWZTlXj6+J82yRuoe3wnVkFilDGVfFnLdIFsnE GahBgNajfe4r8hdo0ICfZg6yespCuikAxwYjpzp+pAr5MBQLeRV2hnSYjhpijbFhyZJ2ZG05Tx7d dIIbeJ0aZ2vRaa4kVoT6+GIx60hAAvzc6Re6TxoB40vH4ec7OgeiwrD2Kj80bi6aJu1T8BwAz6KN hb1Ui10Uqpnb+c1CSznEo49uqqU6U8dqWBUuWzO2rIUfpvrwbucVXddV3SXzmbaTAJN4jirSQC5J UqwWj/GR+C5qH1/cZtTp7QRT4pqipinkuSgrsDEFTrE8WPiVVFe6xlAcLTEiyEg0f6t94n77ApP1 4WMRK605q8JCFO3XsuloghZjaSElSVm8Se+wU+/P/WH14dqD1nZrqV4Gt+vrxYXkYmKF3yDXiTl/ yVNypRz0KGMhrH4HanKOGmwGm8lrVsjpirmTAMohWf8MOh3I+oVADGZcyoYdtbsdLqfVZfIMW8/d OHxN/jyIGLJE+6sMSwh4nNBE/XQACwecysuOh8KBIKIJBAOEnwRQ1XGVj0AiARJAVEQQwaEO5xUi hAdwv8Y7gI4E4Svyd8E3DhiesZ4N6nmfRnLMwjshEeNxDsNduKINOBpCAjDwkiqI6+mfsBcZ8DIx gBsIAHNfwA7tFnOzjctfVz+bvzLpqDor2Iw4L5ZT+Vx6IvHhSvsH716auzEPN6DVyGpyLbEwuVJd u/vrBxvv14D3Zv6W/i95k6hhZUwK5wIV7wwElqwT9rT9Lt+KNxMlNk+nyQTBBxkf4w2ZPQO+a5AF gjwQFPCRGIEwLhHQZ68LJprsDvRBA+4uQ3dfb39v59AvRo/qToz9lOwjDKSHtpEGVhc/fb3LPOwA IBiBg3AYImHez3uTgSIGYFGO4Dpq2Cpxh+SJAtmkRUV+YlT7afzjkdVfLneKPxt5ER4YvTaoH7p2 9UaPrXfkrP3YGOA89hz6447Dx7n0y9pX0n0V07yjEp4WavGZ/NRMsTb5wVT7icbuqH7j0UH1CrE0 vtJcbtR3Jv/U+CT+jqvhnh3KXCaDhJMw4m+geqtON6C7ccn2StCBDEKdQNiKOygPZWYdvIfzJLwZ NItkwxOkElA+99lV9cfiX4oPFpdKpTJfYhNkAlMWKnkSUHKMs7IAO/w6c75DfpLeI3/uuGekR9tr Hh509wWs9Khki1srziUYgJbWQ7c70gWSrmp3r4X/0Xv7vlhXK6iems5XJ2rxWbJJTMFpa3qEMfsU C4KtY1aXzeo0w2bIErBSw7hFcpUBVwmbiTeVxB4v7pM71dn77a8kMnQixgkagReyQpWJg3Q0muQm +Gwsw6RZMVYUGul1MLX6ZvsIn2FydEGD8UjMxbliw2wXk30TfEi/ndwpLiRala0F4Deq0SODB3rk b8oHH38fRE0BS9Ce8U+jN4PpcALjMMdF0IVBEZRCcHfEQZ+hnyJlQMnuOjFMDGN23EvtYu9xKt9S Z/hcbJJeoyscJ2RTmfr47X+2Z5W35rftvnfbrmRzT2aLa5b3jkk21kR5cIiCo3SSFimBpmmWEW7T d6R7+fuZ9fxcvkKCBMtFhI4XZU+n/EPjEb8paFdmKwSGnPL3Hv+8S/4OOooYCHvUr0HYZLDQIYVL 2DwGuDEvFtyPoxgS8B1nwH7qNeplUk+Bevw8diIEnFTFV/Y8+cHOtjrDjkdT0XnFe1lWYjguKgqi OJVarfwVnPxd7ZPcvcQCXyMrGooLCT4RjpviA8lECxSEXdxxFU5qaRelsiCyQJSlWE4bj4oxkStK M4X5+i0GVIw2DO9CW4MHQy509Perb9U2sw8m7kob1Nv4urs+DDRuZAZ1e6l++9F++Wvyl+Q/gqEx HKZQNpgKlbFlBGSQiC+E4AimeKD8WhI8h+/pVcn7fHuGVDRHs7G9UT4qRdOAWKDZea0gUlFJm6Z5 lonxQnyCn8nelha5arP9ZbDV1uY+DNYDa8ZCJ6XH+/3dYz2OTuMFPeoGnWdHT12WD/stCv3cr9Kw JgqVPetuAFaKGN5P+ANen9uBjUWUduFWysh+iwIv4sfwgxgQjcQYfj/JKKAe3x2CyKf//t+IutKf 6qI7mQuootDGp3Qnuy+deuaFc0d0wMCzT48d6vj287nWee355aEt3w5yR3in8vfUYn65slxZqc3P 1RrVRrlR2J6+NdFKrkvb7D2qfQD/x0DrqBL/s0Pyv9T2I74upR49lI41xKypsTxUcM2gTaqFryZv VpcqC63ZB5OLlYfV/yy2nxD+bN0EbGs9xTPUZbwb6jP1G3X91y/Y9Ybjr8vAbsryp9tbapFNRhNs g21IDeV3mNuqfrTdPjrbVklv0TwmBAQ45oiZecBHBmPSXqGxwW4kWxVNa7JZqUylE5IoCA9pEFec XamYH0OCKGoJOoMQhqJGd+/S8lQ1neajhXSjWE5NcRVqFi/BaRuQtkTNXgNyfcxkHDVZDPAQZVKu /GgRluCYjwQCKk/Q5XU4jEM2xRRDZhC6rJeBV+XTuDPiYiDh/yWXz0/TcBjGDyr26oGE0WRLTDQm hqN6kng0EoiJoiQQQKJbJgMcDsa60bVrv+23W3+uW7uuhZFtOKab/M40C0RR9CCJZ4Px5NGzVevB qv/B+z5P3uf9PESe1qAOlmE9XYcWKwMJZEi3jaYYiiKQng7nZm44PZaegB6sA3KB9HUo5oWc2whl Mato/3YP2wP2VmdZNHnVRQ1FyaioQho3tPsq4TFmjDkrUUiWiBpZIlfYKr+b3tU317arlbrWyJYy S4wJjFhxylqU/YV+Cxkw/RquzGoREytjJaICa8yG2MjVrL2VndVG9emzenO1aq0XW0sto6W2BOQD 95p9Sb1IreNPMASjA8SgN3mLnmQpBEAAWG8MxDlXcvfHEgLMQYMtJd9Gd2ZXw+WgPiaMcuPJifB0 dP5RMkRH5Ig1jxTDTeyA+Bw9jDax/al6UPPrD+AoNhy+OtTXO4Tcudbz2DmJLvrFbL9vVpyUgzrF z+WDFiNCiXNTXa7l973WsbYnWf9Jzvj5qrPClwRTUDk3i4T3dJvbFJD9Dvu8KgKJFaEHD1EYpBFI UhyNwriLaahre4ZESYZiGAZxD5rqti4oPflLhV6P6ZzOKu2jr/YZz3f73LsvWklRJZXPIaIs6WZ3 Mu/WCzElzbvDTatdvHFKkAVZ7nbjMZ8tICsGL6i+T+CAK3Nb0qHq2RBrginCKINDgDAQsLQXd9E8 zoWpCFhg8RRF03BhZuJ23xXH6wx2OW9+n3XGHfPe3bHxkYAnlogRCzRChCaZAApjgvzQN6dEi3gZ mJwpLRnPa83tBmI2K/kCWl+Lh9Z88aJO66imZws53zf7xNFxoz3y42IXbl9O2KfiH+kGu0xngUzK CQUBpKySPqnAFwXzr5y/2p1/AAYdmfkKZW5kc3RyZWFtDWVuZG9iag0yMiAwIG9iag08PCANL1R5 cGUgL0VuY29kaW5nIA0vRGlmZmVyZW5jZXMgWyAxIC9HNDQgL0c1NSAvRzIxIC9HMTkgL0cyMCAv RzE1IC9HMyAvRzU0IC9HODggL0c2OSAvRzgwIC9HNzYgL0c4NiANL0c4MiAvRzgxIC9HNzMgL0cz NiAvRzg3IC9HODUgL0c2OCAvRzcwIC9HNzUgL0c3MiAvRzM4IC9HODkgL0c3NCANL0c3OSAvRzcx IC9HOTIgL0c4MyAvRzYwIC9HOTAgL0cyOSAvRzkxIC9HNTEgL0c0MCAvRzkzIC9HMTcgL0c1MyAN L0c0OCAvRzUwIC9HNTYgL0c0MyAvRzQ5IC9HNzggL0cxMCAvRzQxIF0gDT4+IA1lbmRvYmoNMjMg MCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0RpZmZlcmVuY2VzIFsgMSAvRzU0IC9HODggL0c2 OSAvRzgwIC9HNzYgL0c4NiAvRzgyIC9HODEgL0czIC9HODMgL0c3OSAvRzkyIC9HODcgDS9HNzUg L0c3MiAvRzczIC9HNjggL0c4NSAvRzc0IC9HMTUgL0c3MSAvRzExIC9HMTIgL0cxNyBdIA0+PiAN ZW5kb2JqDTI0IDAgb2JqDTw8IA0vVHlwZSAvRW5jb2RpbmcgDS9EaWZmZXJlbmNlcyBbIDEgL0c1 MCAvRzgxIC9HNzkgL0c5MiAvRzMgL0c4MiAvRzg1IC9HNzYgL0c3NCAvRzY4IC9HODAgL0c4NyAv RzcyIA0vRzg2IC9HNzUgL0c4OCAvRzcxIC9HNjkgL0cxNyAvRzM4IC9HNzAgL0c4MyAvRzE1IC9H NzMgL0c5MCAvRzE4IA0vRzg5IC9HMzYgL0c0MiAvRzIyIC9HMTkgL0cyMSAvRzIwIC9HNDAgL0c1 NCAvRzUxIC9HNDQgL0c1OCAvRzc4IA0vRzU1IC9HMTYgL0c4NCAvRzUzIC9HNDkgL0c0NyAvRzYw IC9HNTYgL0czOSAvRzI5IC9HNDggL0czNSAvRzkxIA0vRzExIC9HMTIgL0c3NyAvRzQzIC9HNTcg L0c0MSAvRzM3IC9HMjggL0cyNyAvRzI2IC9HMjQgL0c1OSAvRzI1IA0vRzIzIC9HMTAgL0c0NSAv RzMwIF0gDT4+IA1lbmRvYmoNMjUgMCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0RpZmZlcmVu Y2VzIFsgMSAvRzQgXSANPj4gDWVuZG9iag0yNiAwIG9iag08PCANL1R5cGUgL0VuY29kaW5nIA0v RGlmZmVyZW5jZXMgWyAxIC9HNTEgL0c4NSAvRzgyIC9HNzAgL0c3MiAvRzcxIC9HNzYgL0c4MSAv Rzc0IC9HODYgL0czIC9HNzMgL0c1NCANL0c0NCAvRzQwIC9HNTggL0c3OSAvRzY5IC9HNjggL0c4 NyAvRzg5IC9HMTUgL0c4MyAvRzc1IC9HOTAgL0cyOSANL0c1MCAvRzUzIF0gDT4+IA1lbmRvYmoN MjcgMCBvYmoNPDwgDS9UeXBlIC9FbmNvZGluZyANL0RpZmZlcmVuY2VzIFsgMSAvRzgyIC9HODEg L0c3OSAvRzkyIC9HMyAvRzcyIC9HNTEgL0c4NSAvRzcwIC9HNzEgL0c3NiAvRzc0IC9HODYgDS9H NzMgL0c1NCAvRzQ0IC9HNDAgXSANPj4gDWVuZG9iag0yOCAwIG9iag08PCANL1MgL0QgDT4+IA1l bmRvYmoNMjkgMCBvYmoNPDwgDS9OdW1zIFsgMCAyOCAwIFIgXSANPj4gDWVuZG9iag0zMCAwIG9i ag08PCANL1R5cGUgL1BhZ2VzIA0vS2lkcyBbIDQ0IDAgUiAxIDAgUiBdIA0vQ291bnQgMiANPj4g DWVuZG9iag0zMSAwIG9iag08PCANL0R0IChEOjIwMDAxMTI5MTU0NjM4KQ0vSlRNIChEaXN0aWxs ZXIpDT4+IA1lbmRvYmoNMzIgMCBvYmoNL1RoaXMgDWVuZG9iag0zMyAwIG9iag08PCANL0NQIChE aXN0aWxsZXIpDS9GaSAzMiAwIFIgDT4+IA1lbmRvYmoNMzQgMCBvYmoNPDwgDS9QbyB0cnVlIA0v UiBbIDYwMCA2MDAgXSANPj4gDWVuZG9iag0zNSAwIG9iag08PCANL0pURiAwIA0vTUIgWyAwIDAg NjEyIDc5MiBdIA0vUiAzNCAwIFIgDS9XIFsgMCAxIF0gDT4+IA1lbmRvYmoNMzYgMCBvYmoNPDwg DS9GaSBbIDMzIDAgUiBdIA0vUCBbIDM1IDAgUiBdIA0+PiANZW5kb2JqDTM3IDAgb2JqDTw8IA0v RG0gWyA2MTIgNzkyIDYxMiA3OTIgXSANPj4gDWVuZG9iag0zOCAwIG9iag08PCANL01lIDM3IDAg UiANPj4gDWVuZG9iag0zOSAwIG9iag08PCANL0QgWyAzNiAwIFIgXSANL01TIDM4IDAgUiANL1R5 cGUgL0pvYlRpY2tldENvbnRlbnRzIA0+PiANZW5kb2JqDTQwIDAgb2JqDTw8IA0vQSBbIDMxIDAg UiBdIA0vQ24gWyAzOSAwIFIgXSANL1YgMS4xMDAwMSANPj4gDWVuZG9iag00MSAwIG9iag08PCAN L0NyZWF0aW9uRGF0ZSAoRDoyMDAwMTEyOTE1NDYzOCkNL1Byb2R1Y2VyIChBY3JvYmF0IERpc3Rp bGxlciA0LjA1IGZvciBXaW5kb3dzKQ0vQ3JlYXRvciAoV2luZG93cyBOVCA0LjApDS9UaXRsZSAo SDpcXFRQXFxJVDAxXFwuLi5cXElUMjAxIFNDLndwICAgICAgIFtQRlAjMTEwMjQ3NTQ1Nl0pDS9N b2REYXRlIChEOjIwMDAxMTI5MTU0NjM4LTA4JzAwJykNPj4gDWVuZG9iag14cmVmDTAgNDIgDTAw MDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAxNjE1NCAwMDAwMCBuDQowMDAwMDE2MzA1IDAwMDAwIG4N CjAwMDAwMTY1MDcgMDAwMDAgbg0KMDAwMDAyMzM1NCAwMDAwMCBuDQowMDAwMDIzNzE2IDAwMDAw IG4NCjAwMDAwMjM5ODQgMDAwMDAgbg0KMDAwMDAyNDQzMSAwMDAwMCBuDQowMDAwMDI0NjE1IDAw MDAwIG4NCjAwMDAwMjQ5MDIgMDAwMDAgbg0KMDAwMDAyNTE0NCAwMDAwMCBuDQowMDAwMDI1NTU2 IDAwMDAwIG4NCjAwMDAwMzg0NDcgMDAwMDAgbg0KMDAwMDAzODc2MyAwMDAwMCBuDQowMDAwMDQx NTczIDAwMDAwIG4NCjAwMDAwNDIwNzAgMDAwMDAgbg0KMDAwMDA2MDU2OCAwMDAwMCBuDQowMDAw MDYwNzk4IDAwMDAwIG4NCjAwMDAwNjExMTkgMDAwMDAgbg0KMDAwMDA2MTQ1OCAwMDAwMCBuDQow MDAwMDY5MjMxIDAwMDAwIG4NCjAwMDAwNjk1MjAgMDAwMDAgbg0KMDAwMDA3NDMxMiAwMDAwMCBu DQowMDAwMDc0NjEwIDAwMDAwIG4NCjAwMDAwNzQ3OTEgMDAwMDAgbg0KMDAwMDA3NTIwMSAwMDAw MCBuDQowMDAwMDc1MjY2IDAwMDAwIG4NCjAwMDAwNzU0NjggMDAwMDAgbg0KMDAwMDA3NTYxNCAw MDAwMCBuDQowMDAwMDc1NjQ1IDAwMDAwIG4NCjAwMDAwNzU2ODkgMDAwMDAgbg0KMDAwMDA3NTc2 MSAwMDAwMCBuDQowMDAwMDc1ODI1IDAwMDAwIG4NCjAwMDAwNzU4NDggMDAwMDAgbg0KMDAwMDA3 NTkwMCAwMDAwMCBuDQowMDAwMDc1OTUwIDAwMDAwIG4NCjAwMDAwNzYwMjYgMDAwMDAgbg0KMDAw MDA3NjA4MSAwMDAwMCBuDQowMDAwMDc2MTMwIDAwMDAwIG4NCjAwMDAwNzYxNjYgMDAwMDAgbg0K MDAwMDA3NjI0MyAwMDAwMCBuDQowMDAwMDc2MzEwIDAwMDAwIG4NCnRyYWlsZXINPDwNL1NpemUg NDINL0lEWzxiZDFmNzYyODY4ZTAwYTQ3NTljN2FkY2VjODE1ZjYzZT48YmQxZjc2Mjg2OGUwMGE0 NzU5YzdhZGNlYzgxNWY2M2U+XQ0+Pg1zdGFydHhyZWYNMTczDSUlRU9GDQ== --0__=1wj55wbMuTLaPmr8Vlgwmlg8x6MSQcPhFaLr2uYDP8KJkX3qiio0mrEY-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 18:26:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA16138 for ; Mon, 4 Dec 2000 18:26:25 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 31BC24434B; Mon, 4 Dec 2000 17:24:34 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (oe32.law9.hotmail.com [64.4.8.89]) by lists.bell-labs.com (Postfix) with ESMTP id 3E86144344 for ; Mon, 4 Dec 2000 16:28:57 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Mon, 4 Dec 2000 14:28:48 -0800 X-Originating-IP: [63.36.205.201] From: "Gethin Liddell" To: "Gonzalo Camarillo" Cc: "Sip Mail List" References: <00120111510301.22777@gethin> <3A279C26.FE53784A@lmf.ericsson.se> <00120113013502.22777@gethin> <3A2B4F74.EBAD3EF2@lmf.ericsson.se> Subject: Re: [SIP] 3PCC and the re-invite response 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: X-OriginalArrivalTime: 04 Dec 2000 22:28:48.0408 (UTC) FILETIME=[9223D180:01C05E41] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 22:25:31 -0000 Content-Transfer-Encoding: 7bit Hi Gonzalo, > Hello, > > I do not like to send the SDP in the ACK because the 200 OK gets > retransmitted a number of times. However, as folk have pointed out, > sometimes it does not take that long for the controller to receive the > new SDP to be sent in the ACK. > > Thus, we could copy the delayed acknowledgments from TCP. > > The UAC can delay the ACK up to a certain amount of time (in TCP it is > usually 200 ms). If when this timer expires the UAC cannot send the ACK > with SDP it will send an ACK without SDP and re-INVITE when it is ready > to send the new SDP. Hmmm, in the proposed 3pcc combination of late ack and re-invite, the late ack is going to the new called party (agent b). Therefore, if the late ack and the original invite did not contain any SDP then agent b would have been invited to a session that had no SDP at all. IMO this is not a very nice thing to do to the agent. I think that if you are actually worried about the delay b4 the ack arrives, then it should not be a problem because agent a will respond with a 200 pretty quickly. if it doesn't, then agent b should behave as it would for any call that it does not receive an ACK for and time out after some period of time. As the 2 user-agents do not know they are in a call then we should utilize their default time outs and leave it up to them rather than try to add it in to the controller. > I think this would be an acceptable way of combining delayed ACKs with > the re-INVITE method. > > However, in my opinion, applications would use the re-INVITE method most > of the times. but the re-invite method is broken. that is why we have had this discussion, we are not trying to change it just for the sake of it. > > Regards, > > Gonzalo > > Gethin Liddell wrote: > > > > My appologies Gonzalo, i missed the point you were making. > > > > IMO, your point is valid and an issue for the original 3PCC draft. > > > > However, with the "re-invite & late ack" proposal, the 200 response of > > the re-invite should come fairly quickly as there is no need to wait > > for a user to answer a phone. > > > > Would this not be enough to avoid the re-transmission problem you > > pointed out? > > > > On Fri, 01 Dec 2000, Gonzalo Camarillo wrote: > > > Hello, > > > > > > Gethin Liddell wrote: > > > > > > > > On Fri, 01 Dec 2000, Gonzalo Camarillo wrote: > > > > > Hello, > > > > > > > > > > The ACK is used to stop 200 OK retransmissions. Thus, if it takes some > > > > > time for your UAC to get the SDP to be sent in the ACK, the 200 OK will > > > > > be retransmitted a number of times although we have already received it. > > > > > > > > Keep in mind though that the late ACK scenario is only going to be used > > > > in certain circumstances. During normal call setup, the standard > > > > INVITE SDP, ACK no SDP will be used. When someone does something a bit > > > > special, such as 3PCC, then people are more inclined to accept little > > > > anomolies, such as no audio for the first second. > > > > > > I am not talking about service behavior (the user waiting for a couple > > > of seconds). I am talking about a UAC retransmitting a 200 OK because an > > > ACK has not been received. The UAC thinks that the 200 OK responses that > > > it is sending are getting lost in the network but what it is really > > > happening is that the UAC that should return an ACK is doing something > > > in order to gather a proper SDP to piggyback it in the ACK. > > > > > > If we send the ACK as soon as the 200 OK arrives the UAS will stop > > > retransmitting. Then, the UAC can take as long as it wants to gather the > > > SDP and then re-INVITE. > > > > > > I would accept to send the SDP in the ACK if the UAC, upon reception of > > > the 200 OK, it is ready to send the ACK with the SDP. In that case I do > > > not have a problem with ACKs carrying SDPs. > > > > > > > > > > > > > > > > > I do not think it is a good idea to overload a method with two different > > > > > functions: stop 200 OK retransmissions and send the SDP. > > > > > > > > why? it does not really add any major coding effort to a SIP UA. > > > > > > It is not about coding effort. It is about "streching" a retransmission > > > timer because the SDP is not ready to be sent. > > > > > > > > > > > We have to take into consideration that in 3PCC scenarios the controller > > > > > will have to issue another request in order to obtain the SDP that had > > > > > to be sent in the ACK. Since this takes time I do not find appropriate > > > > > to mess with the retransmission timers for 200 responses. > > > > > > > > sorry, don't understand what you're getting at here. we are not messing > > > > with any retranmssion timers. > > > > > > See my comments above. > > > > > > > > > > > I actually think that the best solution for 3PCC is an amalgamation of > > > > the late ACK and re-invite proposals: > > > > > > > > A Controller B > > > > | INV held SDP | | > > > > |<------------------| | > > > > | | | > > > > | 200 SDP A1 | | > > > > |-----------------> | | > > > > | | | > > > > | ACK | | > > > > |<------------------| | > > > > | | | > > > > | | INV NO SDP | > > > > | |----------------->| (1) > > > > | | | > > > > | | 200 SDP B | > > > > | |<-----------------| > > > > > > In this moment the UAS will begin retransmitting the 200 OK until the > > > ACK arrives > > > > > > > | INV SDP B | | > > > > |<------------------| | > > > > | | | > > > > | 200 SDP A2 | | > > > > |-----------------> | | > > > > | | | > > > > | | ACK SDP A2 | > > > > | ACK |----------------->| > > > > > > At this point the UAS will stop retransmitting the 200 OK... In the > > > previous message exchange (INVITE SDP B and 200 SDP A2) takes long, the > > > UAS will have to retransmit the 200 OK a number of times. > > > > > > Let's keep in mind that retransmissions are used to ensure reliable > > > delivery of SIP messages. In this scenario the 200 OK was already > > > delivered but the UAS had to keep on retransmitting... I do not like > > > that... > > > > > > Regards, > > > > > > Gonzalo > > > > > > > > > > > > > |<------------------| | > > > > | | | > > > > | | RTP | > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > | | | > > > > | | | > > > > | | | > > > > | | | > > > > | | | > > > > | | | > > > > | | | > > > > | | | > > > > > > > > my only query is who do we late ack at (1), agent A or agent B. > > > > > > > > Only question is what will agent A do with a re-invite that has no SDP? > > > > > > > > -- > > > > Gethin Liddell > > > > Ubiquity Software Corporation > > > > > > > > http://www.ubiquity.net > > > > mailto:gethin@ubiquity.net > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > -- > > > Gonzalo Camarillo Phone : +358 9 299 33 71 > > > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > > > Telecom R&D Fax : +358 9 299 30 52 > > > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > > > Finland http://www.hut.fi/~gonzalo > > -- > > Gethin Liddell > > Ubiquity Software Corporation > > > > http://www.ubiquity.net > > mailto:gethin@ubiquity.net > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 18:31:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18164 for ; Mon, 4 Dec 2000 18:31:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ECA3D4435F; Mon, 4 Dec 2000 17:31:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 4DEBF44336 for ; Mon, 4 Dec 2000 17:30:57 -0500 (EST) Received: from driftwood.cisco.com (driftwood.cisco.com [171.71.157.40]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA23795; Mon, 4 Dec 2000 15:30:53 -0800 (PST) Received: from cisco.com ([171.71.159.231]) by driftwood.cisco.com (Mirapoint) with ESMTP id ABL05162; Mon, 4 Dec 2000 17:30:45 -0600 (CST) Message-ID: <3A2C295C.FA185E12@cisco.com> From: Henry Chen X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Alan Johnston , SIP List , stlevy@cisco.com Subject: Re: [SIP] Attended TransferCallFlow:draft-ietf-sip-service-examples-00.txt References: <3A27EC37.8465F804@cisco.com> <20001201124935.A32143@div8.net> <3A2BC3E8.E31849F3@wcom.com> <3A2BC9F0.C0737422@cisco.com> <20001204110350.A2156@div8.net> <3A2BDB2B.BA8C916F@cisco.com> <20001204144437.B2342@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 04 Dec 2000 17:31:41 -0600 Content-Transfer-Encoding: 7bit Please check following comments and questions. Thanks, Henry Billy Biggs wrote: > Henry Chen (hjlechen@cisco.com): > > >>> If INVITE (F16) is a new call, C will get ring again during the > >>> transfer. > >> > >> Yes. Please see our replaces draft for one solution to this > >> problem. Overloading the call-id is not a good idea. > > > > Is this a perfect case for same call with different call legs and is > > acceptable? > > Huh? > > >> It is now generally accepted that the call-id should not be used to > >> infer that an incoming call should replace or have any association > >> with an ongoing call. Doing so leads to problems in some forking > >> situations, and is a general overloading of the meaning. > > > > Could you give a call scenario for the forking situation which leads > > to problems? > > Sure. > > 1. A single INVITE may complete at multiple remote parties (multiple > 200 OK responses). The UA may choose to keep around all of these > calls. When a new call with the same call-id comes in, which of > these multiple calls is it associated with? > Same situation for the replacement also. Some one need to decide which call is to be replaced. > > 2. A UA receives a call and answers it, then later receives a > retransmission of the original INVITE from a different proxy > (request merging). I want to protect this UA from mistaking this > as a replacement call for the answered one. This can be done by comparing CSeq and Call-leg. > > > 3. A broken UA may make multiple calls within the same Call-ID. I > want to protect against mis-associating these calls. > This is a very rare case and may also be detected by comparing CSeq. Right? > > 4. Most (all) commercially available SIP UAs don't give larger scope > to the call-id. As well, there is no way to tell if a UA will give > it any significance. Cleaner to seperate replacement or > association as new headers. What is the acceptance of "Replacement"? > > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 19:06:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27422 for ; Mon, 4 Dec 2000 19:06:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 09E1044355; Mon, 4 Dec 2000 18:06:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 460EE44341 for ; Mon, 4 Dec 2000 17:49:03 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id FAA06627 for ; Tue, 5 Dec 2000 05:54:30 -0600 Message-ID: <008701c05e4c$799ea760$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Proposed Bar BOF, Fully Distributed Multiparty Conferencing Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 17:42:19 -0600 Content-Transfer-Encoding: 7bit I'd like to propose a bar-BOF, location TBD, at IETF49, Wednesday 13Dec00 at 2200 (after the plenary) to discuss fully-distributed multiparty conferencing. We'll then develop a new protocol for fully-distributed multiparty partying . . . Please respond if interested, so I can get a rough head count. Facilities can be scarce. -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 19:07:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA27760 for ; Mon, 4 Dec 2000 19:07:35 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A9C4044367; Mon, 4 Dec 2000 18:06:30 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id F044044341 for ; Mon, 4 Dec 2000 17:49:12 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id FAA06624 for ; Tue, 5 Dec 2000 05:54:29 -0600 Message-ID: <008601c05e4c$797a0860$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Proposed Bar-BOF on SIP Security, Thursday 14, 2000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 4 Dec 2000 17:38:06 -0600 Content-Transfer-Encoding: 7bit I would like to propose a bar-BOF -- location TBD -- for the SIP Security Task Foce on Thursday night at 2000. -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 4 19:14:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA29654 for ; Mon, 4 Dec 2000 19:14:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C8674436C; Mon, 4 Dec 2000 18:14:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id BC1D944366 for ; Mon, 4 Dec 2000 18:13:42 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA24366; Mon, 4 Dec 2000 16:13:40 -0800 (PST) Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126]) by imop.cisco.com (Mirapoint) with SMTP id AAC16218; Mon, 4 Dec 2000 16:13:11 -0800 (PST) Message-Id: <4.1.20001204154347.00cb2b40@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Billy Biggs From: Rohan Mahy Subject: Re: [SIP] REFER for Remote Device Control Cc: SIP List In-Reply-To: <20001129104702.A28481@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 04 Dec 2000 16:15:16 -0800 At 08:47 AM 11/29/00 , Billy Biggs wrote: > The sip-peer-3pcc draft discusses providing PHONECTL functionality >using REFER. > > To send a BYE on a specific call leg, the draft uses a Refer-To URI >of: > > To indicate a request to REGISTER as a specific user, the draft >uses: > > I strongly believe that this sort of behavior is outside the scope of >REFER. The meaning of the request is hidden in an obfuscated URI, which >cannot provide enough information to identify which call-leg is being >referenced. [1] Why? The meaning doesn't seem hidden to me, the method is clearly labeled. REFER is just a way for A to refer/tell B to request something from C. Can you provide an example of a real situation where the Request-URI, To, From, and Call-ID aren't sufficient to identify the call? > I am rewriting the PHONECTL draft, splitting the commands into new >methods. For example, LOGIN (ask the UA to REGISTER) and HANGUP (ask >the UA to leave a session). This keeps the intent clear, and helps the >UA maintain a seperate authentication model for these device control >extensions. why can't you just look in the URL? web browsers will have to do this anyway. why delay the inevitable? the separate method thing seems cumbersome and a bit ITUish. thanks, -rohan > I hope to have a draft ready this week, but would be willing to set up >a mailing list or something if there was interest in this work. > > >[1] The original INVITE may have resulted in two calls being setup, and > no mechanism of determining the tags used is available. As well, > you cannot specify which tags to use in a URI. > >-- >Billy Biggs, 3Com Email: Billy_Biggs@3com.com >http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 01:51:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22560 for ; Tue, 5 Dec 2000 01:51:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E088244338; Tue, 5 Dec 2000 00:51:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sumo.vocaltec.co.il (sumo.vocaltec.co.il [199.203.72.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0DE1744336 for ; Tue, 5 Dec 2000 00:50:01 -0500 (EST) Received: from ilnimo.vocaltec.co.il (ilnimo.vocaltec.co.il [194.90.71.135]) by sumo.vocaltec.co.il (8.9.3/8.9.3) with ESMTP id IAA14980 for ; Tue, 5 Dec 2000 08:50:55 +0200 (IST) From: Joshua_Fox@vocaltec.com To: sip@lists.bell-labs.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: X-MIMETrack: Serialize by Router on ILNimo/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March 2000) at 12/05/2000 08:49:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [SIP] Sip-to-XML mapping Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 08:49:15 +0200 In the everything-is-a-nail department, XML has become the most popular hammer nowadays, and I have fielded questions from my colleagues about SIP and XML. 1. Why isn't SIP sent in XML but rather in a line-oriented syntax? 2. What about SIP-to-XML mappings? I have some answers to the questions. 1. The line-oriented syntax allows and exisiting HTTP/SMTP parsers can be easily applied to SIP in UAs, servers, and SIP-aware firewalls. Given that SIP is a protocol requiring coupling on the protocol level between components, the added metainformation of XML is not needed. Given that text-based SIP is already a "higher-level" protocol (to human readers) than binary protocols like H.323, it would be ill-advised to take that to an extreme with XML metainformation, reducing efficiency. SIP was invented well before XML became popular and people started recoding every text-based (or even binary) data transmission into XML. 2. A SIP-to-XML mapping would have the advantage of being parseably transmittable over protocols that use XML, including firewall-penetrating ones. As various types of different routing and firewall software become XML-aware, SIP transmissions would be handled more flexibly. When this occurs, such software may be able to convert line-based SIP transmissions to XML at run-time for more sophisticated processing. Still, the "name:value" line-based format provides enought metainformation for easy processing, so that there is little advantage to XML. I should clarify that in my opinion, SIP does NOT need to be sent in XML, and only limited processing tasks would benefit by SIP-to-XML conversion, which can be accomplished ad-hoc. Still, the comparison between line-based and tag-based formats highlights some interesting questions about the benefits of different syntaxes. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 04:50:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA16993 for ; Tue, 5 Dec 2000 04:50:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 614D14433A; Tue, 5 Dec 2000 03:50:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web10304.mail.yahoo.com (web10304.mail.yahoo.com [216.136.130.82]) by lists.bell-labs.com (Postfix) with SMTP id 8A1A544336 for ; Tue, 5 Dec 2000 03:49:57 -0500 (EST) Message-ID: <20001205094948.88241.qmail@web10304.mail.yahoo.com> Received: from [203.197.179.249] by web10304.mail.yahoo.com; Tue, 05 Dec 2000 01:49:48 PST From: james jack To: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] Consultation Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 01:49:48 -0800 (PST) Dear All: How are you! I have one question to consult with, On page 66 of RFC2543 bis02 , which says "411 Length Required The server refuses to accept the request without a defined Content-Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message-body in the request message." But On page 45, which says"If a server receives a UDP request without Content-Length,itMUST assume that the request encompasses the remainder of the packet." What's more, On table 4(page 36),which describes the "Content-Length" must be appeared in request. Now I am confused with RFC2543bis02, If a server receive an INVITE request without Content-Length over UDP, what should happen? Will 411 response code send out? Best regards! Yours:James __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 05:03:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA19814 for ; Tue, 5 Dec 2000 05:03:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3DDD24434D; Tue, 5 Dec 2000 04:03:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web10307.mail.yahoo.com (web10307.mail.yahoo.com [216.136.130.85]) by lists.bell-labs.com (Postfix) with SMTP id 152164434B for ; Tue, 5 Dec 2000 04:02:52 -0500 (EST) Message-ID: <20001205100243.72187.qmail@web10307.mail.yahoo.com> Received: from [203.197.179.249] by web10307.mail.yahoo.com; Tue, 05 Dec 2000 02:02:43 PST From: james jack To: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] Consultation Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 02:02:43 -0800 (PST) Dear All: I have one SIP question to Consult. On RFC2543bis02 and draft-ietf-sip-call-flows-01.txt, If one send one following REGISTER request to Registrar,what would happen? Support this REGISTER is the first REGISTER request for this user. REGISTER sip:there.com SIP/2.0 Via: SIP/2.0/UDP there.com:5060 From: LittleGuy To: LittleGuy Call-ID: 123456789@here.com CSeq: 1 REGISTER Contact: LittleGuy Authorization:Digest username="UserB", realm="MCI WorldCom SIP", nonce="1cec4341ae6cbe5a359ea9c8e88df84f", opaque="", uri="sip:ss2.wcom.com", response="71ba27c64bd01de719686aa4590d5824" Content-Length: 0 For this REGISTER request, the Name-addr in Contact header is the same as that of To header,Since To header is the alias address, Contact header is the practical address for one user. So if one INVITE request send to the Server whose domain is the same as that of Registrar, then if the Request_uri of INVITE request is "UserB@there.com", If the Server look up into the directory,the contact information is no use to help find the next hop, at this time, what should the Proxy/Redirect server do? I think If the content of contact is the same as that of To header in REGISTER request, then this request is no use. Could anyone give me some advice and suggestion? Best Regards! Yours: james __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 08:52:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA21683 for ; Tue, 5 Dec 2000 08:52:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EC7E044338; Tue, 5 Dec 2000 07:52:10 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id E12EF44336 for ; Tue, 5 Dec 2000 07:51:05 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Dec 5 08:48:36 EST 2000 Received: by lists.bell-labs.com (Postfix) id 81AAA44380; Tue, 5 Dec 2000 08:36:21 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 0CA194437D for ; Tue, 5 Dec 2000 08:36:20 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id HAA19020; Tue, 5 Dec 2000 07:36:02 -0600 Cc: SIP@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id HAA19012; Tue, 5 Dec 2000 07:36:00 -0600 Message-ID: <3A2CEF3B.F51D4287@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: james jack Original-CC: SIP@lists.bell-labs.com Subject: Re: [SIP] Consultation References: <20001205094948.88241.qmail@web10304.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 07:35:55 -0600 Content-Transfer-Encoding: 7bit James: There was some discussion (and maybe a consensus) on this topic on the mailing list. You may want to search the archives (http://www.bell-labs.com/mailing-lists/sip/) for the resolution. Even though I *think* I recall the resolution, I don't trust my memory enough to write down what it was. james jack wrote: > > Dear All: > How are you! > I have one question to consult with, On page 66 of > RFC2543 bis02 , which says > "411 Length Required > The server refuses to accept the request without a > defined Content-Length. The client MAY repeat the > request if it adds a valid Content-Length header field > containing the length of the message-body in the > request message." > But On page 45, which says"If a server receives > a UDP request without Content-Length,itMUST assume > that the request encompasses the remainder of > the packet." > What's more, On table 4(page 36),which describes > the "Content-Length" must be appeared in request. > Now I am confused with RFC2543bis02, If a server > receive an INVITE request without Content-Length over > UDP, what should happen? Will 411 response code send > out? > Best regards! - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 09:08:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25102 for ; Tue, 5 Dec 2000 09:08:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9FF8744348; Tue, 5 Dec 2000 08:08:11 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 95E7F4434A for ; Tue, 5 Dec 2000 08:07:05 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Dec 5 09:05:05 EST 2000 Received: by lists.bell-labs.com (Postfix) id A878D44380; Tue, 5 Dec 2000 08:52:50 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 5F2D74437D for ; Tue, 5 Dec 2000 08:52:50 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id HAA22613; Tue, 5 Dec 2000 07:52:48 -0600 Cc: SIP@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id HAA22606; Tue, 5 Dec 2000 07:52:47 -0600 Message-ID: <3A2CF329.47A8074B@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: james jack Original-CC: SIP@lists.bell-labs.com Subject: Re: [SIP] Consultation References: <20001205100243.72187.qmail@web10307.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 07:52:42 -0600 Content-Transfer-Encoding: 7bit james jack wrote: > > Dear All: > I have one SIP question to Consult. > On RFC2543bis02 and > draft-ietf-sip-call-flows-01.txt, > If one send one following REGISTER request to > Registrar,what would happen? Support this REGISTER > is the first REGISTER request for this user. > REGISTER sip:there.com SIP/2.0 > Via: SIP/2.0/UDP there.com:5060 > From: LittleGuy > To: LittleGuy > Call-ID: 123456789@here.com > CSeq: 1 REGISTER > Contact: LittleGuy > Authorization:Digest username="UserB", realm="MCI > WorldCom SIP", > nonce="1cec4341ae6cbe5a359ea9c8e88df84f", opaque="", > uri="sip:ss2.wcom.com", > response="71ba27c64bd01de719686aa4590d5824" > Content-Length: 0 > > For this REGISTER request, the Name-addr in Contact > header is the same as that of To header,Since To > header is the alias address, Contact header is the > practical address for one user. Typically, Contact addresses contain a specific location ("user@host") as opposed to a generic identifier ("user@domain") (see the Nov bis, Section 4.2.6, page 30). It would appear to me that a well behaved UA, when it is registering itself in its own domain, will include a specific location in the REGISTER as opposed to a generic identifier. > So if one INVITE request send to the Server whose domain is the same > as that of Registrar, then if the Request_uri of > INVITE request is "UserB@there.com", If the Server > look up into the directory,the contact information is > no use to help find the next hop, at this time, what > should the Proxy/Redirect server do? > I think If the content of contact is the same > as that of To header in REGISTER request, then this > request is no use. > Could anyone give me some advice and suggestion? Well, the proxy could try to route the request based on the Request URI. It may very well find (by querying DNS SRV records, say) that *it* is the next hop server -- it can declare a loop at that point in time and send back the appropriate 4xx response. Another option is to have the registrar reject REGISTER requests from its own domain if they do not include a specific location. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 10:11:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA11180 for ; Tue, 5 Dec 2000 10:11:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A8E34434C; Tue, 5 Dec 2000 09:11:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id E7FC844355 for ; Tue, 5 Dec 2000 09:10:04 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA08390; Tue, 5 Dec 2000 10:09:55 -0500 (EST) Message-ID: <3A2D0543.F6305499@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Joshua_Fox@vocaltec.com Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Sip-to-XML mapping References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 10:09:55 -0500 Content-Transfer-Encoding: 7bit Yes, this is almost a FAQ. Short, snippy answers: 1) It's too late to worry about it - any gains in changing the syntax would be far outweighed by the delay, cost and confusion. 2) I have a hard time picturing a firewall that would somehow parse XML and let random XML pass through, if it worries about content. After all, if you construct an XML DTD for file management, you really wouldn't want delete *.* to pass through. 3) It appears likely that SDPng will indeed use XML, if only to appease the XML fanatics. This is probably the part that a firewall needs to parse for the most part. 4) XML parsers appear to be significantly more complex than basic SIP parsers, judging from what's available. It may well be possible to write a simple XML parser, so this may be an interesting academic exercise. Joshua_Fox@vocaltec.com wrote: > > In the everything-is-a-nail department, XML has become the most popular > hammer nowadays, and I have fielded questions from my colleagues about SIP > and XML. > > 1. Why isn't SIP sent in XML but rather in a line-oriented syntax? > 2. What about SIP-to-XML mappings? > > I have some answers to the questions. > 1. The line-oriented syntax allows and exisiting HTTP/SMTP parsers can be > easily applied to SIP in UAs, servers, and SIP-aware firewalls. Given that > SIP is a protocol requiring coupling on the protocol level between > components, the added metainformation of XML is not needed. Given that > text-based SIP is already a "higher-level" protocol (to human readers) > than binary protocols like H.323, it would be ill-advised to take that to > an extreme with XML metainformation, reducing efficiency. SIP was invented > well before XML became popular and people started recoding every text-based > (or even binary) data transmission into XML. > > 2. A SIP-to-XML mapping would have the advantage of being parseably > transmittable over protocols that use XML, including firewall-penetrating > ones. As various types of different routing and firewall software become > XML-aware, SIP transmissions would be handled more flexibly. When this > occurs, such software may be able to convert line-based SIP transmissions > to XML at run-time for more sophisticated processing. Still, the > "name:value" line-based format provides enought metainformation for easy > processing, so that there is little advantage to XML. > > I should clarify that in my opinion, SIP does NOT need to be sent in XML, > and only limited processing tasks would benefit by SIP-to-XML conversion, > which can be accomplished ad-hoc. Still, the comparison between line-based > and tag-based formats highlights some interesting questions about the > benefits of different syntaxes. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 11:10:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA27039 for ; Tue, 5 Dec 2000 11:10:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3850C44338; Tue, 5 Dec 2000 10:10:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id AFFF844336 for ; Tue, 5 Dec 2000 10:09:26 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA25996; Tue, 5 Dec 2000 08:09:23 -0800 (PST) Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126]) by imop.cisco.com (Mirapoint) with SMTP id AAC22192; Tue, 5 Dec 2000 08:08:44 -0800 (PST) Message-Id: <4.1.20001205075406.00cffe40@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Billy Biggs , Alan Johnston From: Rohan Mahy Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 Cc: Robert Sparks , Jonathan Rosenberg , SIP List In-Reply-To: <20001204150357.A2443@div8.net> References: <20001204141622.A2342@div8.net> <20001130100343.A30059@div8.net> <20001130104711.A30137@div8.net> <3A2BE821.733CDFD5@wcom.com> <20001204141622.A2342@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 08:04:21 -0800 Hi, For REFERs that deal with existing calls, there must be some way to match against the existing calls/transactions. Billy is assuming that you need to explicitly state the From (with tag), Call-ID, and possibly the To. I always assumed that you would use the To, From, and/or Call-ID in the Refer-To URL to match against existing calls/transactions in the most common cases, and that you would be more specific for the corner cases. We need to nail down these semantics more tightly. thanks, -rohan At 01:03 PM 12/4/00 , Billy Biggs wrote: > To add to my own email: > >Billy Biggs wrote: > >> REFER Refer-To: farend@host.com >> >> spawns -> INVITE farend@host.com >> To: farend@host.com >> From: me@localhost;tag=54321 >> Call-ID: 12345@host.com >> >> Then later I get: >> >> REFER Refer-To: farend@host.com;method=BYE >> >> spawns -> BYE farend@host.com >> To: farend@host.com >> From: farend@host.com;tag=73625 >> Call-ID: 83738@host.com >> >> This BYE has a new from tag and a new call-id, so it gets ignored by >> the far end. >> >> In order to ensure we match, the REFERs MUST include both the >> Call-ID and From (with a tag). Ouch. My implementation does not >> want to trust either of those to a remote UA, especially not the >> From. > > Even with specifying a Call-ID and From header for each REFER, I'm >also assuming: > > 1. The remote UA will match the BYE to the ongoing call, even though > it does not have a To-tag (this is mentioned in the spec, but I > wouldn't count on all UAs supporting it). > > 2. That you don't care about the Record-Route'ing proxies in the > middle of the call which care very much about receiving that BYE. > > I'm sure that 2 is unacceptable to some people on this list. >-- >Billy Biggs, 3Com Email: Billy_Biggs@3com.com >http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 11:15:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA28272 for ; Tue, 5 Dec 2000 11:15:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB5824435C; Tue, 5 Dec 2000 10:15:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 3730644359 for ; Tue, 5 Dec 2000 10:14:33 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id WAA08437; Tue, 5 Dec 2000 22:19:48 -0600 Message-ID: <003b01c05ed6$201a7130$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "Dean Willis" , "IETF SIP (E-mail)" References: <008701c05e4c$799ea760$ea036e3f@dynamicsoft.com> 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Requested Change:Proposed Bar BOF, Fully Distributed Multiparty Conferencing Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 10:11:53 -0600 Content-Transfer-Encoding: 7bit I have received a request for a change of the FDMC-SIP Bar BOF. One of our esteemed colleagues must leave the event Wednesday afternoon. Would you gentlepersons be amenable to gathering at 2200 on Monday instead? -- Dean ----- Original Message ----- From: "Dean Willis" To: "IETF SIP (E-mail)" Sent: Monday, December 04, 2000 5:42 PM Subject: [SIP] Proposed Bar BOF, Fully Distributed Multiparty Conferencing > > I'd like to propose a bar-BOF, location TBD, at IETF49, Wednesday 13Dec00 at > 2200 (after the plenary) to discuss fully-distributed multiparty > conferencing. We'll then develop a new protocol for fully-distributed > multiparty partying . . . > > Please respond if interested, so I can get a rough head count. Facilities > can be scarce. > > -- > Dean > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 12:12:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14580 for ; Tue, 5 Dec 2000 12:12:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1FCDF44338; Tue, 5 Dec 2000 11:12:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from pmesmtp02.wcom.com (pmesmtp02.wcom.com [199.249.20.2]) by lists.bell-labs.com (Postfix) with ESMTP id 1E4FB44336 for ; Tue, 5 Dec 2000 11:11:35 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-32 #42257) id <0G5300J01UDRBG@firewall.mcit.com> for sip@lists.bell-labs.com; Tue, 5 Dec 2000 17:10:39 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-32 #42257) with ESMTP id <0G5300FPGUDQER@firewall.mcit.com>; Tue, 05 Dec 2000 17:10:38 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0G5300401U3XQD@pmismtp03.wcomnet.com>; Tue, 05 Dec 2000 17:06:43 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5300401U2XLG@pmismtp03.wcomnet.com>; Tue, 05 Dec 2000 17:05:18 +0000 (GMT) Received: from wcom.com ([166.33.132.83]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with ESMTP id <0G53004ABU2J4W@pmismtp03.wcomnet.com>; Tue, 05 Dec 2000 17:03:55 +0000 (GMT) From: Alan Johnston Subject: Re: [SIP] Questions on draft-rosenberg-sip-app-components-00.txt To: "Culpepper, Bert" Cc: SIP List Message-id: <3A2D21FE.7FA56231@wcom.com> MIME-version: 1.0 X-Mailer: Mozilla 4.7 [en] (Win98; U) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit X-Accept-Language: en References: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 11:12:30 -0600 Content-Transfer-Encoding: 7bit Thanks very much, Bert! I never noticed that capability in RFC 2327. Alan. "Culpepper, Bert" wrote: > If I may, I'll take a shot at 1. > > > -----Original Message----- > > From: Alan Johnston [mailto:alan.johnston@wcom.com] > > Sent: Friday, December 01, 2000 11:33 PM > > To: Jonathan Rosenberg; Peter Mataga; Henning Schulzrinne > > Cc: SIP List > > Subject: [SIP] Questions on draft-rosenberg-sip-app-components-00.txt > > > > > > Jonathan/Peter/Henning, > > > > A couple of questions about some of the examples in your excellent and > > informative draft. (If I could only get some of the MEGACO proponents > > in > > my organization to read and understand it...) > > > > 1. On page 16, section 5.4, referring to Figure 3, you say: > > > > "The next step for the AS is to get a > > stream of DTMF digits to flow from the caller to the media server. > > To > > > > do this, it sends a re-INVITE to the caller (11). This re-INVITE > > contains the same SDP as the response (6) from the called party, > > but > > with the addition of a new media line. This media line is audio, > > and > > contains a single codec, the RTP payload format for DTMF and tones > > [8]. The connection address and port are from the SDP returned from > > the media server. This tells the caller to send an additional media > > stream to the media server, using only the DTMF codec. " > > > > I'm not sure I understand what the SDP in the re-INVITE should look > > like. Lets say the SDP in the 200 OK (6) from the Callee contained: > > > > c=IN IP4 100.101.102.103 > > m=audio 5004 RTP/AVP 0 > > > > Lets say the SDP in the 200 OK (3) from the Media Server contained: > > > > c=IN IP4 200.201.202.203 > > m=audio 53000 RTP/AVP 96 (Not sure about this line, but it would > > indicate port 53000 and the DTMF encoding) > > > > The text says that media line from (3) is added to the SDP from (6), > > but > > what about the connection line which has a different IP address? I'm > > not sure that the SDP of > > > > c=IN IP4 200.201.202.203 > > m=audio 5004 RTP/AVP 0 > > m=audio 53000 RTP/AVP 96 > > > > would have the desired effect. Normally, wouldn't this SDP say to > > send > > media to ports 5004 and 53000 at 200.201.202.203 (since the actual > > intent is to send the PCMU to port 5004 at 100.101.102.103)? Or, > > would > > this SDP look completely different? > > I believe the authors leave it to the reader to decide how to build the > SDP component to specify the desired media destinations. Using > your example a complete media description will be as follows. (The > c= line in the session desc. (not shown) will have the callee's IP > address, the a= line below shows the event format specified in > RFC 2833). > > m=audio 5004 RTP/AVP 0 > m=audio 53000 RTP/AVP 96 > c=IN IP4 200.201.202.203 > a=rtpmap:96 telephone-event > > The above indicates a different destination for the second media > stream according to RFC 2327 (SDP). > > > 2. In Figure 5, the IVR call flow shows the Callee sending IVR > > commands > > to the IVR Server after the receipt of the 183 Session Progress, but > > before any 200 OK. I think this could be useful, but I'm wondering if > > User Agents that support Early Media like this would actually send RTP > > packets prior to getting a 200 OK. For example, if a Gateway to the > > PSTN sends a 183 Session Progress, it may not include the a=sendonly > > attribute, but any RTP packets prior to call completion in the PSTN > > would be simply dropped. > > > > 3. In Figure 9, the Web Enabled Message Drops call flow, I am trying > > to > > decide if the first message should be a HTTP POST or a GET as it is > > shown. Your description indicates that a single click activates the > > service - the trigger is simply that the particular URL has been > > accessed. I understand that each mailbox for each user would have a > > URL. My question is how the Web Caller's SIP URL is sent to the > > Controller, since the Controller initiates the INVITE (3). Would it > > be > > somehow imbedded as a parameter in the URL? Or, should the message be > > a > > POST, in which case the Web Caller would type in their SIP URL, click > > the submit button, and the combination of the URL and the form data > > would give the controller enough information to setup the call. > > Finally, one perhaps dumb question relating to this example. If the > > SIP > > User Agent and the HTTP Client were on the same machine, couldn't the > > Web Caller just click on a link containing a SIP URL (instead of a > > HTTP > > URL) of the desired mailbox which would cause the caller's SIP User > > Agent to simply place the call? > > > > Again, thanks for detailing this very useful method of decomposition. > > > > Alan Johnston > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 13:15:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA27828 for ; Tue, 5 Dec 2000 13:15:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AE42244365; Tue, 5 Dec 2000 12:15:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3CEAA44359 for ; Tue, 5 Dec 2000 12:14:10 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA20372; Tue, 5 Dec 2000 13:16:30 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 13:11:54 -0500 Message-ID: From: Jonathan Rosenberg To: "Henning G. Schulzrinne" , Billy Biggs , sip@lists.bell-labs.com Subject: RE: [SIP] Re: My comments on bis-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 13:11:52 -0500 > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Friday, November 24, 2000 4:42 PM > To: Billy Biggs; sip@lists.bell-labs.com > Subject: [SIP] Re: My comments on bis-02 > > > 5. Due to the proliferation of the Also header in BYE > requests, I would > > suggest that it be added to the bis draft, with its meaning > > restricted to use with the BYE method. > > Tentatively added. Hold on a sec.... BYE/Also is in a draft that has expired a long time ago. I thought we revisited this and came up with the REFER mechanism. Also, AFAIK, has been discarded, along with its usage in BYE. I don't know what proliferation you are talking about. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 13:17:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28334 for ; Tue, 5 Dec 2000 13:17:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A47344373; Tue, 5 Dec 2000 12:15:29 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5648644365 for ; Tue, 5 Dec 2000 12:14:10 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA20361; Tue, 5 Dec 2000 13:16:30 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 13:11:54 -0500 Message-ID: From: Jonathan Rosenberg To: Igor Slepchin , "'Billy Biggs'" , "Henning G. Schulzrinne" Cc: SIP List Subject: CANCEL and Record-Route; was: RE: [SIP] Re: My comments on bis-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 13:11:51 -0500 > -----Original Message----- > From: Igor Slepchin [mailto:ISlepchin@dynamicsoft.com] > Sent: Friday, December 01, 2000 3:32 PM > To: 'Billy Biggs'; Henning G. Schulzrinne > Cc: SIP List > Subject: RE: [SIP] Re: My comments on bis-02 > > > > > > 2. In 4.2.5, it is noted that CANCEL requests cannot have Route > > > > headers. Why not? Are you assuming that CANCEL is > only useful > > > > for an initial request? This breaks since we need to > > be able to > > > > CANCEL a pending REFER or other extension method > which doesn't > > > > complete quickly, for example. > > > > > > Removed. > > > > I think I was wrong on this one. CANCEL is of hop-by-hop > > significance > > within a transaction and doesn't use the Route. Stateful proxies > > instead remember and the UA sends the CANCEL just to the > > first entry in > > the Route. > > A proxy might be stateless and still record-route. Route > actually does make > sense in a CANCEL in this scenario. I think this is far more complex than it first seems. CANCELs are hop by hop. So, lets say we have UAs A and B, and proxies P1, P2, and P3. P2 is stateless: A ---- P1 ----- P2 ------ P3 ------ B now, if we allow record-routing for CANCEL, that record-routing would only be for the CANCEL initiated by P1, proxied by P2 (which inserts RR), and terminated by P3. So, its P1 that needs to insert Route into CANCEL. Where does this route come from? From the RR in the final response to INVITE? If the request has been responded to already, CANCEL is meaningless anyway. Assuming we used that RR anyway, what portions of it are needed? The whole thing? Just the piece starting at P2? How does P1 even know whether P2 record-routed? Adding RR to CANCEL seems a big, big departure from what we have been doing until now. I'd much rather not do this. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 13:21:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29530 for ; Tue, 5 Dec 2000 13:21:39 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2222C44377; Tue, 5 Dec 2000 12:15:45 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E1A7E44366 for ; Tue, 5 Dec 2000 12:14:10 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA20364; Tue, 5 Dec 2000 13:16:30 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 13:11:55 -0500 Message-ID: From: Jonathan Rosenberg To: Billy Biggs , Alan Johnston Cc: Robert Sparks , Jonathan Rosenberg , SIP List Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 13:11:49 -0500 Billy raises some very important issues. These are some of the things that motivated a thread on the list many months back (on the road now and can't dig up the reference), where we discussed adding control functionality to SIP, and how this was insufficient for a full blown control and monitoring protocol like megaco. As Billy rightly observes, sending a refer for a sip URL with a BYE method makes a lot of assumptions about how its processed in the recipient. It is assuming that the UA matches the BYE with an existing call leg, it assumes tags are handled, it assumes the UA is willing to accept REFERs with BYE, and so on, as he has pointed out. The simple fact is, SIP is a poor control protocol. If people want a real protocol that can adequately remote control a phone, thats a totally separate thing, with different primitives and communication requirements and security implications. I believe SIP is entirely inadequate for such a job. REFER was a sort-of-compromise; it introduced a little bit of control into SIP. It was enough to do a bunch of simple things (call transfer specifically), and as such its a nice primitive for building services. But, I believe it is inadequate for a complete control protocol. Thus, I share Billy's concerns about using it to hang up existing calls, among other things. We should probably add text to REFER that is explicit about the requirements (and non-requirements) for processing REFER at the recipient. Flame away. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 13:27:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA01074 for ; Tue, 5 Dec 2000 13:27:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DD78644380; Tue, 5 Dec 2000 12:15:59 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5EC4344359 for ; Tue, 5 Dec 2000 12:14:14 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA20365; Tue, 5 Dec 2000 13:16:30 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 13:11:54 -0500 Message-ID: From: Jonathan Rosenberg To: Brett Tate , Sip Mail List Subject: RE: [SIP] 3PCC and the re-invite response MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 13:11:47 -0500 > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com] > Sent: Saturday, December 02, 2000 7:51 PM > To: Sip Mail List > Subject: Re: [SIP] 3PCC and the re-invite response > > > > > Another reason is because > > > many current UA's respond to hold SDP with > > > hold SDP. Thus both sides would be passing > > > hold SDP with 0.0.0.0 as connection addresses, > > > and the call would not get established. > > > > If that's the case, scenario in Figure 1 of the 3pcc draft > will not work > no > > matter how much we try to fix it. In particular, that would > mean that > > http://lists.bell-labs.com/pipermail/sip/2000q4/004391.html > won't work as > > well, since both A and B would keep returning "on hold" SDP > to the 3pcc > > forever. Hence, automatically putting other party on hold > just because you > > were put on hold sounds like very wrong behavior. Just as you say in > another > > email, some phones return on hold media even for INVITEs > with no SDP, > which > > plainly cannot be fixed. So isn't it better to fix the UAs > instead of > > creating workarounds that don't always work anyway? > > Gethin's flow works for 3pcc call setup. However > a no-call REFER (if still valid) or hold-then-transfer > A to B through controller also works and allows > A to hear/see the call progress/fail. Brett, you have made this comment in several emails so far (in fact, several through what appears to be copy-paste). I cannot follow what you are proposing here. Can you please send a call flow? Brett wrote previously: >Another reason is because >many current UA's respond to hold SDP with >hold SDP. Thus both sides would be passing >hold SDP with 0.0.0.0 as connection addresses, >and the call would not get established. This is bad. The whole reason we made "hold" be equal to 0.0.0.0 connection address was that the service was done as a side effect; no special processing is needed. The INVITE+hold stuff will all work if UAs do not treat a connection address of 0.0.0.0 differently from anything else; SDP processing should proceed normally. The only difference is that you can't send to 0.0.0.0, so even if you tried, no packets are sent and call hold is thusly accomplished. Standardizing on using 0.0.0.0 (instead of allowing any other non-routable address) has the benefit that UIs that wish to indicate call hold can do so. However, it seems that the benefit of this has been lost on implementors, now resulting in a problem with some of the call flows. I will add some text to bis explaining this issue. I think this thread, and several others, all relate to one central problem: we need a general way of describing SDP processing in UAs; how to determine what the "current" set of SDP is, and how one creates a response to an offered SDP. With a general algorithm in place for that, these problems would go away. > Thanks for the response. Maybe one of the > 3pcc authors can organize a bof at the > IETF meeting if there is enough interest > in this stuff. I hope to cover some of these issues at the meeting. Although 3pcc is not a chartered item, I believe there is sufficient interest (and already implementations) for us to move it forward as an informational item. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 13:30:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA02046 for ; Tue, 5 Dec 2000 13:30:52 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 63D1544388; Tue, 5 Dec 2000 12:16:15 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C438444359 for ; Tue, 5 Dec 2000 12:14:18 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA20380; Tue, 5 Dec 2000 13:16:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 13:12:05 -0500 Message-ID: From: Jonathan Rosenberg To: "Henning G. Schulzrinne" , Brett Tate Cc: Sip Mail List Subject: RE: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invi te response] MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 13:11:54 -0500 Hmm. The problem is that we allow INVITE with no SDP, and it appears this is used quite a bit (note the massive flames to my suggestion to remove it). Since we allow it in an initial INVITE, we need to allow it in a re-INVITE. So, the question becomes, what is its meaning? I think the initial thinking was that re-INVITE with no SDP means "no change" in SDP. However, this breaks the idempotency of SIP, and is probably a bad thing. The other alternative is that no SDP means no media. This is consistent with its usage in initial INVITE today with H.323v1 gateways, an makes it idemopotent for re-INVITEs. We can signal a "no-change" in SDP by including the SDP we included in the previous message, with the same version ID and all. If the last message had no SDP, meaning no media, then you would still continue to signal no-change, and thus no media, with no SDP. No m lines is something that has caused a lot of confusion. In the beginning of section 6, the m line is not listed as optional (no star). The text slightly above says there can be zero or more media descriptions. I believe what this means is that if a media description is present, there must be an m line, but media descriptions need not be present. However, I think many folks assume there will be an m line. Thus, the INVITE with media-on-hold made sure there was an m line, but had the same effect as if there was none. -Jonathan R. > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Sunday, December 03, 2000 10:20 AM > To: Brett Tate > Cc: Sip Mail List > Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the > re-invite response] > > > I believe that the simple set of rules should be > > - always send SDP in INVITE and 200 > > - if you don't know the media yet, don't include m lines. That is > perfectly legal according to RFC 2327: > > "Zero or more media descriptions (see below)" > > - Use the normal "0.0.0.0 means hold" (I had mis-spoken about ports) > > - if you want to find out what the other side can do, but without > changing things, use OPTIONS (this is needed anyway, since you need to > find the whole set; no-SDP doesn't cover this) > > This is much closer to the spirit of soft-state and > always-send-full-state that underlies other Internet > protocols. Clearly, > the spec needs to spell this out more explicitly. This is also much > simpler since it integrates hold and normal media > changes/additions into > one mechanism, rather than two. > > Whether we need to address what end system should do if senders don't > conform is a separate issue. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 13:34:28 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03406 for ; Tue, 5 Dec 2000 13:34:28 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3C85B44391; Tue, 5 Dec 2000 12:16:30 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4EF0744359 for ; Tue, 5 Dec 2000 12:14:23 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id NAA20367; Tue, 5 Dec 2000 13:16:30 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 13:11:54 -0500 Message-ID: From: Jonathan Rosenberg To: "Fairlie-Cuninghame, Robert" , "'Jonathan Rosenberg'" , "'Jo Hornsby'" , sip@lists.bell-labs.com Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 13:11:44 -0500 > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Monday, December 04, 2000 3:18 AM > To: 'Jonathan Rosenberg'; 'Jo Hornsby'; sip@lists.bell-labs.com > Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements > > > > > > I just can't follow what you are saying. > > > > My point is simple. You are making assumptions about the > meaning of a > > missing Contact. I gave an example where the Contact was > > missing for a good > > reason. Insertion of it by another proxy may confuse the > > proxy that gets a > > record-route back in a response that does not have the form > > it expected > > (i.e., extra entry corresponding to the inserted Contact). > > Hi Jonathan, > > Ok firstly, I am not advocating a proxy inserts a Contact. I > agree this is a > bad idea - that is not my suggestion. I was merely suggesting a method > whereby the proxy can stateless remember where to send a > request when there > is no COntact when the proxy is the first or last proxy. > > If the proxy doesn't remember the state information: > Then Contact field MUST always be present when Record-Route > is used or you > must be able to route to the To and From. I don't understand > your position: > on one hand it seems you are saying the Contact is mandatory > and on the > other hand you are saying you should be able to work without > a Contact. My apologies for a confused response. I wrote this when I was way too tired. The To/From have nothing to do with it, and we do need to worry about the case of UAs that don't insert Contact. Lets start again. OK, so here's what happens when A calls B and neither inserts a Contact. On a re-INVITE from A to B, the request ultimately arrives at the proxy right before B. Now, since the request has no Route header at all, the proxy doesn't know the difference between this and a regular initial INVITE. So, it does the normal thing. It looks at the request URI, and uses that to determine where to forward the address. Now, if the request URI had the property that it is translated to the same next hop server (the UAS, in this case), as the initial INVITE, things work fine. The same is true in the case of a re-INVITE from B to A; if the request URI there causes a translation to A, things work fine. Now, if record-routing had the property that I have been advocating all along in this thread (the URI inserted into the request maps to caller, and the URI placed into the response maps to the called party), we wouldn't need to worry about special case handling of the missing contact scenario. But, if you insist on Record-routing with things like sip:myproxy.com, then you are going to NEED to do something weird, like inserting extra record-routes or contacts or something like that, for this all to work with UAs that don't insert Contacts. Otherwise, the proxy gets a request with request URI of sip:proxy.com, and then what? So, proxy implementors have a choice when record-routing. Use the approach I have been advocating, which is not so hard and works universally, and is also the most robust, or, insert weirdo things into the RR in the request, change nothing in a response, and then implement special case handling for the cases where the UAS and/or UAC don't support Contact. So, as you say, I'd rather kill many birds with one stone, and have a single mechanism that handles all the cases we need to worry about. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 13:38:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA05186 for ; Tue, 5 Dec 2000 13:38:49 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 680B744398; Tue, 5 Dec 2000 12:26:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 29DD144397 for ; Tue, 5 Dec 2000 12:25:32 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA20003; Tue, 5 Dec 2000 13:25:22 -0500 (EST) Message-ID: <3A2D3312.CD68AECB@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 13:25:22 -0500 Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Hmm. > > The problem is that we allow INVITE with no SDP, and it appears this is used > quite a bit (note the massive flames to my suggestion to remove it). Since I thought the flames were about disallowing SDP in ACKs, not about "no SDP". Obviously, ACK doesn't have SDP most of the time. > we allow it in an initial INVITE, we need to allow it in a re-INVITE. So, > the question becomes, what is its meaning? > > I think the initial thinking was that re-INVITE with no SDP means "no > change" in SDP. However, this breaks the idempotency of SIP, and is probably > a bad thing. The other alternative is that no SDP means no media. This is > consistent with its usage in initial INVITE today with H.323v1 gateways, an > makes it idemopotent for re-INVITEs. We can signal a "no-change" in SDP by > including the SDP we included in the previous message, with the same version > ID and all. If the last message had no SDP, meaning no media, then you would > still continue to signal no-change, and thus no media, with no SDP. The problem is that while this definition is consistent with the initial INVITE (and subsequent ones), it doesn't quite work for ACK. At the very least, I would like to strongly discourage 'no SDP' in INVITE and 200, as it avoids these issues. > > No m lines is something that has caused a lot of confusion. In the beginning > of section 6, the m line is not listed as optional (no star). The text > slightly above says there can be zero or more media descriptions. I believe > what this means is that if a media description is present, there must be an > m line, but media descriptions need not be present. However, I think many > folks assume there will be an m line. Thus, the INVITE with media-on-hold > made sure there was an m line, but had the same effect as if there was none. > The text below seems pretty clear: An announcement consists of a session-level section followed by zero or more media-level sections. The session-level part starts with a `v=' line and continues to the first media-level section. The media description starts with an `m=' line and continues to the next media description or end of the whole session description. In general, session-level values are the default for all media unless overridden by an equivalent media-level value. Later on pg. 7 (below a=*) Zero or more media descriptions (see below) Media description m= ... Thus, the whole thing (m and following) lines is optional. Within a media section, obviously m= cannot optional (there wouldn't be one then). Thus, I don't see the problem. Not allowing zero of an enumeration is generally a very bad idea. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 15:32:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13291 for ; Tue, 5 Dec 2000 15:32:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D7FED44364; Tue, 5 Dec 2000 14:32:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 3850244336 for ; Tue, 5 Dec 2000 14:30:59 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id CAA09216 for ; Wed, 6 Dec 2000 02:36:26 -0600 Message-ID: <006d01c05ef9$f7bed400$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Please Help! Call for Volunteers -- List Issues Report Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 14:23:10 -0600 Content-Transfer-Encoding: 7bit HELP! I've been looking at trying to sort out open issues on this list for the next meeting, and it is way beyond my meager brain capacity. I'd like to solicit volunteers to perform the following: 1) Volunteer for one or more weeks to review. Copy me and the list on your selection (avoids dupes) 2) Go through the archives. Note all new threads/issues FIRST appearing during the week. 3) For each thread or issue, capture the basic point of each. 4) Follow each thread forward through its conclusion (may be several weeks of discussion. 5) Report on the conclusion of the thread or issue and any following actions needed. 6) Send me a report of all threads thusly identified and documented. Example Report (ok, this one is trivial): 12/5/2000 Thread: Bar BOFS -- Dean Willis invited people to attend bar BOFS for fully distributed multiparty conferencing and security at IETF 49. Many people leapt at the opportunity to attend one of these historic events. Followon -- Dean to find big party rooms and report at WG meeting on Monday. The list archives, should your email record be incomplete, can be found at: http://lists.bell-labs.com/pipermail/sip/ And the sign-up sheet and accumulated reports for volunteers can be found at: http://www.softarmor.com/sipwg/meets/IETF49/listissues.htm Thanks, -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 15:51:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15807 for ; Tue, 5 Dec 2000 15:51:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6548F44376; Tue, 5 Dec 2000 14:51:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5E10E44373 for ; Tue, 5 Dec 2000 14:50:21 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA22516; Tue, 5 Dec 2000 15:52:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 15:48:07 -0500 Message-ID: From: Igor Slepchin To: Jonathan Rosenberg , Igor Slepchin , "'Billy Biggs'" , "Henning G. Schulzrinne" Cc: SIP List Subject: RE: CANCEL and Record-Route; was: RE: [SIP] Re: My comments on bi s-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 15:48:00 -0500 > > A proxy might be stateless and still record-route. Route > > actually does make > > sense in a CANCEL in this scenario. > > I think this is far more complex than it first seems. > <...> > A ---- P1 ----- P2 ------ P3 ------ B > terminated by P3. So, its P1 that needs to insert Route into > CANCEL. Where > does this route come from? From the RR in the final response > to INVITE? No, certainly not. It is taken from the request being CANCELed. This is only useful (and only needed) for consecutive signaling, e.g., for reINVITEs. In you scenario, stateful P1 would copy Route header from reINVITE to CANCEL for that reINVITE. Stateless P2 would then receive a CANCEL with the same Route as the reINVITE being CANCELed. This will ensure that CANCEL goes to precisely the same place as the request. > Adding RR to CANCEL seems a big, big departure from what we > have been doing > until now. I'd much rather not do this. This sounds more like an optimization to me. It eliminates the (somewhat unlikely) chance that a sateless proxy would route CANCEL differently from the request being CANCELed (due to some time-based logic, for example). I'm not sure why this is a huge departure from what we have now but I don't think that this change is critically needed either. --- Igor Slepchin _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 16:07:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17774 for ; Tue, 5 Dec 2000 16:07:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A919344373; Tue, 5 Dec 2000 15:07:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 02D0F44336 for ; Tue, 5 Dec 2000 15:06:56 -0500 (EST) Received: from SUPERBEE ([63.110.3.240]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id QAA22724; Tue, 5 Dec 2000 16:09:17 -0500 (EST) From: "Ben Campbell" To: "'Dean Willis'" , "'IETF SIP (E-mail)'" Subject: RE: [SIP] Please Help! Call for Volunteers -- List Issues Report Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3B507@DYN-TX-EXCH-001.dynamicsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3B379@DYN-TX-EXCH-001.dynamicsoft.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 15:04:36 -0600 Content-Transfer-Encoding: 7bit I volunteer for the week of September 3-9 Ben Campbell > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Dean Willis > Sent: Tuesday, December 05, 2000 2:23 PM > To: IETF SIP (E-mail) > Subject: [SIP] Please Help! Call for Volunteers -- List Issues Report > > > HELP! I've been looking at trying to sort out open issues on > this list for > the next meeting, and it is way beyond my meager brain capacity. > > I'd like to solicit volunteers to perform the following: > > 1) Volunteer for one or more weeks to review. Copy me and the > list on your > selection (avoids dupes) > 2) Go through the archives. Note all new threads/issues FIRST > appearing > during the week. > 3) For each thread or issue, capture the basic point of each. > 4) Follow each thread forward through its conclusion (may be > several weeks > of discussion. > 5) Report on the conclusion of the thread or issue and any > following actions > needed. > 6) Send me a report of all threads thusly identified and documented. > > Example Report (ok, this one is trivial): > > 12/5/2000 Thread: Bar BOFS -- Dean Willis invited people to > attend bar BOFS > for fully distributed multiparty conferencing and security at > IETF 49. Many > people leapt at the opportunity to attend one of these > historic events. > Followon -- Dean to find big party rooms and report at WG > meeting on Monday. > > > The list archives, should your email record be incomplete, > can be found at: > > http://lists.bell-labs.com/pipermail/sip/ > > And the sign-up sheet and accumulated reports for volunteers > can be found > at: > > http://www.softarmor.com/sipwg/meets/IETF49/listissues.htm > > Thanks, > > -- > Dean > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 16:37:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21407 for ; Tue, 5 Dec 2000 16:37:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 96BDA4438A; Tue, 5 Dec 2000 15:37:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 083D944373 for ; Tue, 5 Dec 2000 14:50:33 -0500 (EST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id MAA06445; Tue, 5 Dec 2000 12:50:26 -0800 (PST) Received: from cisco.com (vvs-lab-nat-171-69-180-242.cisco.com [171.69.180.242]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ACU01530 (AUTH vzubarev); Tue, 5 Dec 2000 12:50:22 -0800 (PST) Message-ID: <3A2D54FA.87099FD5@cisco.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A2D3312.CD68AECB@cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------6BD13F9CCC78BF2EF8211B98" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 12:50:02 -0800 --------------6BD13F9CCC78BF2EF8211B98 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit What difference does it make whether we send an INVITE with no SDP at all or an SDP with no lines ? I guess the purpose of SDP for the most part is to advertise the codecs party supports and RTP ports (and of course connection address as well). So if we do not send SDP in INVITE or send SDP with no media lines, then in both cases we should advertise our codecs and RTP ports later - either in ACK or in re-INVITE. What's the point then to send SDP with no m lines ? And I guess the understanding of section 6 by most people was exactly as no SDP in INVITE (not as SDP without m lines). I completely agree with Jonathan in the meaning of re-INVITE with no SDP as no media and indication of "no change " by including the same SDP as last one we sent. Thanks. "Henning G. Schulzrinne" wrote: > Jonathan Rosenberg wrote: > > > > Hmm. > > > > The problem is that we allow INVITE with no SDP, and it appears this is used > > quite a bit (note the massive flames to my suggestion to remove it). Since > > I thought the flames were about disallowing SDP in ACKs, not about "no > SDP". Obviously, ACK doesn't have SDP most of the time. > > > we allow it in an initial INVITE, we need to allow it in a re-INVITE. So, > > the question becomes, what is its meaning? > > > > > I think the initial thinking was that re-INVITE with no SDP means "no > > change" in SDP. However, this breaks the idempotency of SIP, and is probably > > a bad thing. The other alternative is that no SDP means no media. This is > > consistent with its usage in initial INVITE today with H.323v1 gateways, an > > makes it idemopotent for re-INVITEs. We can signal a "no-change" in SDP by > > including the SDP we included in the previous message, with the same version > > ID and all. If the last message had no SDP, meaning no media, then you would > > still continue to signal no-change, and thus no media, with no SDP. > > The problem is that while this definition is consistent with the initial > INVITE (and subsequent ones), it doesn't quite work for ACK. At the very > least, I would like to strongly discourage 'no SDP' in INVITE and 200, > as it avoids these issues. > > > > > No m lines is something that has caused a lot of confusion. In the beginning > > of section 6, the m line is not listed as optional (no star). The text > > slightly above says there can be zero or more media descriptions. I believe > > what this means is that if a media description is present, there must be an > > m line, but media descriptions need not be present. However, I think many > > folks assume there will be an m line. Thus, the INVITE with media-on-hold > > made sure there was an m line, but had the same effect as if there was none. > > > > The text below seems pretty clear: > > An announcement consists of a session-level section followed by zero > or more media-level sections. The session-level part starts with a > `v=' line and continues to the first media-level section. The media > description starts with an `m=' line and continues to the next media > description or end of the whole session description. In general, > session-level values are the default for all media unless overridden > by an equivalent media-level value. > > Later on pg. 7 (below a=*) > Zero or more media descriptions (see below) > > Media description > m= ... > > Thus, the whole thing (m and following) lines is optional. Within a > media section, obviously m= cannot optional (there wouldn't be one > then). > > Thus, I don't see the problem. Not allowing zero of an enumeration is > generally a very bad idea. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Vladislav Zubarev mailto:vzubarev@cisco.com Software Engineer http://www.cisco.com Cisco Systems, Inc. http://www.vovida.org --------------6BD13F9CCC78BF2EF8211B98 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit What difference does it make whether we send an INVITE with no SDP at all or
an SDP with no lines ?
I guess the purpose of SDP for the most part is to advertise the codecs party
supports and RTP ports (and of course connection address as well).
So if we do not send SDP in INVITE or send SDP with no media lines, then in both
cases we should advertise our codecs and RTP ports later - either in ACK or in re-INVITE.

What's the point then to send SDP with no m lines ?
And I guess the understanding of section 6 by most people was exactly as
no SDP in INVITE (not as SDP without m lines).

I completely agree with Jonathan in the meaning of re-INVITE with no SDP
as no media and indication of "no change " by including the same SDP as last
one we sent.

Thanks.

"Henning G. Schulzrinne" wrote:

Jonathan Rosenberg wrote:
>
> Hmm.
>
> The problem is that we allow INVITE with no SDP, and it appears this is used
> quite a bit (note the massive flames to my suggestion to remove it). Since

I thought the flames were about disallowing SDP in ACKs, not about "no
SDP". Obviously, ACK doesn't have SDP most of the time.

> we allow it in an initial INVITE, we need to allow it in a re-INVITE. So,
> the question becomes, what is its meaning?

>
> I think the initial thinking was that re-INVITE with no SDP means "no
> change" in SDP. However, this breaks the idempotency of SIP, and is probably
> a bad thing. The other alternative is that no SDP means no media. This is
> consistent with its usage in initial INVITE today with H.323v1 gateways, an
> makes it idemopotent for re-INVITEs. We can signal a "no-change" in SDP by
> including the SDP we included in the previous message, with the same version
> ID and all. If the last message had no SDP, meaning no media, then you would
> still continue to signal no-change, and thus no media, with no SDP.

The problem is that while this definition is consistent with the initial
INVITE (and subsequent ones), it doesn't quite work for ACK. At the very
least, I would like to strongly discourage 'no SDP' in INVITE and 200,
as it avoids these issues.

>
> No m lines is something that has caused a lot of confusion. In the beginning
> of section 6, the m line is not listed as optional (no star). The text
> slightly above says there can be zero or more media descriptions. I believe
> what this means is that if a media description is present, there must be an
> m line, but media descriptions need not be present. However, I think many
> folks assume there will be an m line. Thus, the INVITE with media-on-hold
> made sure there was an m line, but had the same effect as if there was none.
>

The text below seems pretty clear:

   An announcement consists of a session-level section followed by zero
   or more media-level sections.  The session-level part starts with a
   `v=' line and continues to the first media-level section.  The media
   description starts with an `m=' line and continues to the next media
   description or end of the whole session description.  In general,
   session-level values are the default for all media unless overridden
   by an equivalent media-level value.

Later on pg. 7 (below a=*)
   Zero or more media descriptions (see below)

   Media description
   m= ...

Thus, the whole thing (m and following) lines is optional. Within a
media section, obviously m= cannot optional (there wouldn't be one
then).

Thus, I don't see the problem. Not allowing zero of an enumeration is
generally a very bad idea.
--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Vladislav Zubarev        mailto:vzubarev@cisco.com
Software Engineer        http://www.cisco.com
Cisco Systems, Inc.      http://www.vovida.org
  --------------6BD13F9CCC78BF2EF8211B98-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 16:51:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23188 for ; Tue, 5 Dec 2000 16:51:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3511C443A2; Tue, 5 Dec 2000 15:51:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from asi-02.alliancesystems.com (unknown [208.35.9.135]) by lists.bell-labs.com (Postfix) with ESMTP id 705D444336 for ; Tue, 5 Dec 2000 15:50:13 -0500 (EST) Received: by ASI-02 with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 15:50:13 -0600 Message-ID: <7D67443E77A1D4119DD400D0B788416102944D@ASI-02> From: Don Mounday To: SIP@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP and H.450 features Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 15:50:07 -0600 Is there any activity with regard to developing the equalivance of the H.450.7 message waiting supplementary features in SIP? I assume that this would be implemented using the the proposed INFO method but this implies standardization of the INFO message contents. Or has this already been solved? Don _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 16:53:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA23480 for ; Tue, 5 Dec 2000 16:53:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7ACD6443A6; Tue, 5 Dec 2000 15:52:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 0F4AC44336 for ; Tue, 5 Dec 2000 15:51:45 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eB5LpQL16425; Tue, 5 Dec 2000 15:51:28 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id eB5LpQX25655; Tue, 5 Dec 2000 15:51:26 -0600 (CST) Received: from ericsson.com (pc050190.exu.ericsson.se [138.85.50.190]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id PAA28042; Tue, 5 Dec 2000 15:51:25 -0600 (CST) Message-ID: <3A2CFF98.CAFF5DD5@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Zubarev Cc: "Henning G. Schulzrinne" , Jonathan Rosenberg , Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A2D3312.CD68AECB@cs.columbia.edu> <3A2D54FA.87099FD5@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 15:45:44 +0100 Content-Transfer-Encoding: 7bit Then why make the differentiation between the procedure for a re-INVITE and the initial INVITE. If we accept that a re-INVITE with no SDP means no media, then an initial INVITE with no SDP should take on the same meaning. IMO, this is easier to implement because of the consistency. /sean -- Sean Olson Vladislav Zubarev wrote: > What difference does it make whether we send an INVITE with no SDP at > all or > an SDP with no lines ? > I guess the purpose of SDP for the most part is to advertise the > codecs party > supports and RTP ports (and of course connection address as well). > So if we do not send SDP in INVITE or send SDP with no media lines, > then in both > cases we should advertise our codecs and RTP ports later - either in > ACK or in re-INVITE. > > What's the point then to send SDP with no m lines ? > And I guess the understanding of section 6 by most people was exactly > as > no SDP in INVITE (not as SDP without m lines). > > I completely agree with Jonathan in the meaning of re-INVITE with no > SDP > as no media and indication of "no change " by including the same SDP > as last > one we sent. > > Thanks. > > "Henning G. Schulzrinne" wrote: > >> Jonathan Rosenberg wrote: >> > >> > Hmm. >> > >> > The problem is that we allow INVITE with no SDP, and it appears >> this is used >> > quite a bit (note the massive flames to my suggestion to remove >> it). Since >> >> I thought the flames were about disallowing SDP in ACKs, not about >> "no >> SDP". Obviously, ACK doesn't have SDP most of the time. >> >> > we allow it in an initial INVITE, we need to allow it in a >> re-INVITE. So, >> > the question becomes, what is its meaning? >> >> > >> > I think the initial thinking was that re-INVITE with no SDP means >> "no >> > change" in SDP. However, this breaks the idempotency of SIP, and >> is probably >> > a bad thing. The other alternative is that no SDP means no media. >> This is >> > consistent with its usage in initial INVITE today with H.323v1 >> gateways, an >> > makes it idemopotent for re-INVITEs. We can signal a "no-change" >> in SDP by >> > including the SDP we included in the previous message, with the >> same version >> > ID and all. If the last message had no SDP, meaning no media, then >> you would >> > still continue to signal no-change, and thus no media, with no >> SDP. >> >> The problem is that while this definition is consistent with the >> initial >> INVITE (and subsequent ones), it doesn't quite work for ACK. At the >> very >> least, I would like to strongly discourage 'no SDP' in INVITE and >> 200, >> as it avoids these issues. >> >> > >> > No m lines is something that has caused a lot of confusion. In the >> beginning >> > of section 6, the m line is not listed as optional (no star). The >> text >> > slightly above says there can be zero or more media descriptions. >> I believe >> > what this means is that if a media description is present, there >> must be an >> > m line, but media descriptions need not be present. However, I >> think many >> > folks assume there will be an m line. Thus, the INVITE with >> media-on-hold >> > made sure there was an m line, but had the same effect as if there >> was none. >> > >> >> The text below seems pretty clear: >> >> An announcement consists of a session-level section followed by >> zero >> or more media-level sections. The session-level part starts with >> a >> `v=' line and continues to the first media-level section. The >> media >> description starts with an `m=' line and continues to the next >> media >> description or end of the whole session description. In general, >> >> session-level values are the default for all media unless >> overridden >> by an equivalent media-level value. >> >> Later on pg. 7 (below a=*) >> Zero or more media descriptions (see below) >> >> Media description >> m= ... >> >> Thus, the whole thing (m and following) lines is optional. Within a >> media section, obviously m= cannot optional (there wouldn't be one >> then). >> >> Thus, I don't see the problem. Not allowing zero of an enumeration >> is >> generally a very bad idea. >> -- >> Henning Schulzrinne http://www.cs.columbia.edu/~hgs >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Vladislav Zubarev mailto:vzubarev@cisco.com > Software Engineer http://www.cisco.com > Cisco Systems, Inc. http://www.vovida.org > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 17:08:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA25267 for ; Tue, 5 Dec 2000 17:08:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1C7C6443AC; Tue, 5 Dec 2000 16:08:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 67CB0443A1 for ; Tue, 5 Dec 2000 16:07:46 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA23770; Tue, 5 Dec 2000 17:10:08 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 17:05:32 -0500 Message-ID: From: Brian Bascom To: "'Dean Willis'" , "IETF SIP (E-mail)" Subject: RE: [SIP] Please Help! Call for Volunteers -- List Issues Report MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 17:05:23 -0500 I'll take November 19-25. --- Brian Bascom dynamicsoft -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Tuesday, December 05, 2000 2:23 PM To: IETF SIP (E-mail) Subject: [SIP] Please Help! Call for Volunteers -- List Issues Report HELP! I've been looking at trying to sort out open issues on this list for the next meeting, and it is way beyond my meager brain capacity. I'd like to solicit volunteers to perform the following: 1) Volunteer for one or more weeks to review. Copy me and the list on your selection (avoids dupes) 2) Go through the archives. Note all new threads/issues FIRST appearing during the week. 3) For each thread or issue, capture the basic point of each. 4) Follow each thread forward through its conclusion (may be several weeks of discussion. 5) Report on the conclusion of the thread or issue and any following actions needed. 6) Send me a report of all threads thusly identified and documented. Example Report (ok, this one is trivial): 12/5/2000 Thread: Bar BOFS -- Dean Willis invited people to attend bar BOFS for fully distributed multiparty conferencing and security at IETF 49. Many people leapt at the opportunity to attend one of these historic events. Followon -- Dean to find big party rooms and report at WG meeting on Monday. The list archives, should your email record be incomplete, can be found at: http://lists.bell-labs.com/pipermail/sip/ And the sign-up sheet and accumulated reports for volunteers can be found at: http://www.softarmor.com/sipwg/meets/IETF49/listissues.htm Thanks, -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 17:28:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29165 for ; Tue, 5 Dec 2000 17:28:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AB3A94434D; Tue, 5 Dec 2000 16:28:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id F175544349 for ; Tue, 5 Dec 2000 16:27:48 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id QAA09932; Tue, 05 Dec 2000 16:29:28 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Tue, 5 Dec 2000 16:26:18 -0600 Message-ID: From: "Culpepper, Bert" To: Don Mounday Cc: SIP List Subject: RE: [SIP] SIP and H.450 features MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 16:26:17 -0600 see http://www.ietf.org/internet-drafts/draft-mahy-sip-message-waiting-00.txt. (the link may wrap due to my email service.) This I-D defines contents for message waiting status but uses SUBSCRIBE & NOTIFY methods. These seem to be the preferred methods and not INFO. Bert > -----Original Message----- > From: Don Mounday [mailto:don.mounday@alliancesystems.com] > Sent: Tuesday, December 05, 2000 4:50 PM > To: SIP@lists.bell-labs.com > Subject: [SIP] SIP and H.450 features > > > > Is there any activity with regard to developing the equalivance of the > H.450.7 message waiting supplementary features in SIP? I assume that > this > would be implemented using the the proposed INFO method but this > implies > standardization of the INFO message contents. Or has this already been > solved? > > > Don > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 17:35:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA00691 for ; Tue, 5 Dec 2000 17:35:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 01ED44439C; Tue, 5 Dec 2000 16:35:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by lists.bell-labs.com (Postfix) with ESMTP id C042B44336 for ; Tue, 5 Dec 2000 16:34:42 -0500 (EST) Received: from zcard00m.ca.nortel.com by zcars04e.ca.nortel.com; Tue, 5 Dec 2000 17:33:28 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00m.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YGTLGGVZ; Tue, 5 Dec 2000 17:33:26 -0500 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YFZBDYJ6; Tue, 5 Dec 2000 17:33:26 -0500 Message-ID: <3A2D6D7C.826FBCB9@americasm01.nt.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Henning G. Schulzrinne" Cc: Jonathan Rosenberg , Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A2D3312.CD68AECB@cs.columbia.edu> Content-Type: multipart/alternative; boundary="------------3811D6A59B8199C7BD83D69E" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 17:34:36 -0500 --------------3811D6A59B8199C7BD83D69E Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit As per a previous discussion on this list, I favour the sematics that says no SDP means "no change". I may be misunderstanding something, but it's hard to imagine a more idempotent operation than one which does nothing. There seem to be three proposals I've seen so far which attach some meaning to no SDP content: 1. 3pcc - Controller uses an INVITE with no SDP to "entice" a UA to provide sufficient media content information so that a call can be set up to another UA independent of the controller. In fact, it appears that the UA has to offer a media description of every kind it can support so the the controller can pick one it likes. IMO, it'd be a rare case where the controller didn't have some idea of what kind of media session it wanted to establish. It does not have the other media endpoint yet, so it can put the media on hold until it does receive it. (A previous thread on the list seemed to establish that a UA responds to media-on-hold with a valid media description of what it's prepared to receive.) The controller also doesn't know what codecs the other UA can support; if this is important, it should use OPTIONS to find out (bis-4.2.3) . Once the INVITE response has been received from the second UA has been received, the full media path can be extablished. Whether this happens in the ACK or a subsequent INVITE is debatable; I'd prefer the re-INVITE to keep it clean, but it's a much lower priority nit than attaching semantics to no SDP. 2. H.323 gateways - I'm not up on H.323 gateway thinking so not quite sure what the issue is here. Does it reduce to the same issue as 3pcc? Or is it just an ACK vs. reINVITE discussion? 3. Implied off-hold - Unless I missed something, there seems to be consensus that this isn't a good idea given that there's already a recommended way to do this - a non 0.0.0.0 connection address. Any others? It's hard (and getting harder all the time) to imagine a use of SIP that doesn't include SDP, but I believe the original intent was to separate media description from control, so SIP could be used to control sessions of any kind. Defining semantics for the absence of something (SDP bodies) makes this somewhat difficult. (However, this is not an excuse for not specifying the UA SDP processing algorithm, as suggested in an earlier posting to this thread - this is a very good idea.) Rick Workman Nortel Networks "Henning G. Schulzrinne" wrote: > Jonathan Rosenberg wrote: > > > > Hmm. > > > > The problem is that we allow INVITE with no SDP, and it appears this is used > > quite a bit (note the massive flames to my suggestion to remove it). Since > > I thought the flames were about disallowing SDP in ACKs, not about "no > SDP". Obviously, ACK doesn't have SDP most of the time. > > > we allow it in an initial INVITE, we need to allow it in a re-INVITE. So, > > the question becomes, what is its meaning? > > > > > I think the initial thinking was that re-INVITE with no SDP means "no > > change" in SDP. However, this breaks the idempotency of SIP, and is probably > > a bad thing. The other alternative is that no SDP means no media. This is > > consistent with its usage in initial INVITE today with H.323v1 gateways, an > > makes it idemopotent for re-INVITEs. We can signal a "no-change" in SDP by > > including the SDP we included in the previous message, with the same version > > ID and all. If the last message had no SDP, meaning no media, then you would > > still continue to signal no-change, and thus no media, with no SDP. > > The problem is that while this definition is consistent with the initial > INVITE (and subsequent ones), it doesn't quite work for ACK. At the very > least, I would like to strongly discourage 'no SDP' in INVITE and 200, > as it avoids these issues. > > > > > No m lines is something that has caused a lot of confusion. In the beginning > > of section 6, the m line is not listed as optional (no star). The text > > slightly above says there can be zero or more media descriptions. I believe > > what this means is that if a media description is present, there must be an > > m line, but media descriptions need not be present. However, I think many > > folks assume there will be an m line. Thus, the INVITE with media-on-hold > > made sure there was an m line, but had the same effect as if there was none. > > > > The text below seems pretty clear: > > An announcement consists of a session-level section followed by zero > or more media-level sections. The session-level part starts with a > `v=' line and continues to the first media-level section. The media > description starts with an `m=' line and continues to the next media > description or end of the whole session description. In general, > session-level values are the default for all media unless overridden > by an equivalent media-level value. > > Later on pg. 7 (below a=*) > Zero or more media descriptions (see below) > > Media description > m= ... > > Thus, the whole thing (m and following) lines is optional. Within a > media section, obviously m= cannot optional (there wouldn't be one > then). > > Thus, I don't see the problem. Not allowing zero of an enumeration is > generally a very bad idea. > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------3811D6A59B8199C7BD83D69E Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  
As per a previous discussion on this list, I favour the sematics that says no SDP means "no change". I may be misunderstanding something, but it's hard to imagine a more idempotent operation than one which does nothing. There seem to be three proposals I've seen so far which attach some meaning to no SDP content:

1. 3pcc - Controller uses an INVITE with no SDP to "entice" a UA to provide sufficient media content information so that a call can be set up to another UA independent of the controller. In fact, it appears that the UA has to offer a media description of every kind it can support so the the controller can pick one it likes. IMO, it'd be a rare case where the controller didn't have some idea of what kind of media session it wanted to establish. It does not have the other media endpoint yet, so it can put the media on hold until it does receive it. (A previous thread on the list seemed to establish that a UA responds to media-on-hold with a valid media description of what it's prepared to receive.) The controller also doesn't know what codecs the other UA can support; if this is important, it should use OPTIONS to find out (bis-4.2.3) . Once the INVITE response has been received from the second UA has been received, the full media path can be extablished. Whether this happens in the ACK or a subsequent INVITE is debatable; I'd prefer the re-INVITE to keep it clean, but it's a much lower priority nit than attaching semantics to no SDP.

2. H.323 gateways - I'm not up on H.323 gateway thinking so not quite sure what the issue is here. Does it reduce to the same issue as 3pcc? Or is it just an ACK vs. reINVITE discussion?

3. Implied off-hold - Unless I missed something, there seems to be consensus that this isn't a good idea given that there's already a recommended way to do this - a non 0.0.0.0 connection address.

Any others?

It's hard (and getting harder all the time) to imagine a use of SIP that doesn't include SDP, but I believe the original intent was to separate media description from control, so SIP could be used to control sessions of any kind. Defining semantics for the absence of something (SDP bodies) makes this somewhat difficult. (However, this is not an excuse for not specifying the UA SDP processing algorithm, as suggested in an earlier posting to this thread - this is a very good idea.)

Rick Workman
Nortel Networks
 
 

"Henning G. Schulzrinne" wrote:

Jonathan Rosenberg wrote:
>
> Hmm.
>
> The problem is that we allow INVITE with no SDP, and it appears this is used
> quite a bit (note the massive flames to my suggestion to remove it). Since

I thought the flames were about disallowing SDP in ACKs, not about "no
SDP". Obviously, ACK doesn't have SDP most of the time.

> we allow it in an initial INVITE, we need to allow it in a re-INVITE. So,
> the question becomes, what is its meaning?

>
> I think the initial thinking was that re-INVITE with no SDP means "no
> change" in SDP. However, this breaks the idempotency of SIP, and is probably
> a bad thing. The other alternative is that no SDP means no media. This is
> consistent with its usage in initial INVITE today with H.323v1 gateways, an
> makes it idemopotent for re-INVITEs. We can signal a "no-change" in SDP by
> including the SDP we included in the previous message, with the same version
> ID and all. If the last message had no SDP, meaning no media, then you would
> still continue to signal no-change, and thus no media, with no SDP.

The problem is that while this definition is consistent with the initial
INVITE (and subsequent ones), it doesn't quite work for ACK. At the very
least, I would like to strongly discourage 'no SDP' in INVITE and 200,
as it avoids these issues.

>
> No m lines is something that has caused a lot of confusion. In the beginning
> of section 6, the m line is not listed as optional (no star). The text
> slightly above says there can be zero or more media descriptions. I believe
> what this means is that if a media description is present, there must be an
> m line, but media descriptions need not be present. However, I think many
> folks assume there will be an m line. Thus, the INVITE with media-on-hold
> made sure there was an m line, but had the same effect as if there was none.
>

The text below seems pretty clear:

   An announcement consists of a session-level section followed by zero
   or more media-level sections.  The session-level part starts with a
   `v=' line and continues to the first media-level section.  The media
   description starts with an `m=' line and continues to the next media
   description or end of the whole session description.  In general,
   session-level values are the default for all media unless overridden
   by an equivalent media-level value.

Later on pg. 7 (below a=*)
   Zero or more media descriptions (see below)

   Media description
   m= ...

Thus, the whole thing (m and following) lines is optional. Within a
media section, obviously m= cannot optional (there wouldn't be one
then).

Thus, I don't see the problem. Not allowing zero of an enumeration is
generally a very bad idea.
--
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

--------------3811D6A59B8199C7BD83D69E-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 17:46:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03081 for ; Tue, 5 Dec 2000 17:46:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE70D44341; Tue, 5 Dec 2000 16:46:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 7051F44336 for ; Tue, 5 Dec 2000 16:45:26 -0500 (EST) Received: from mr5.exu.ericsson.se (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eB5MjBL19313; Tue, 5 Dec 2000 16:45:11 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se (8.10.2/8.10.2) with ESMTP id eB5MgWQ03660; Tue, 5 Dec 2000 16:42:32 -0600 (CST) Received: from ericsson.com (pc050190.exu.ericsson.se [138.85.50.190]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id QAA00632; Tue, 5 Dec 2000 16:45:10 -0600 (CST) Message-ID: <3A2D0C2F.DC0B0F53@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rick Workman Cc: "Henning G. Schulzrinne" , Jonathan Rosenberg , Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A2D3312.CD68AECB@cs.columbia.edu> <3A2D6D7C.826FBCB9@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 16:39:28 +0100 Content-Transfer-Encoding: 7bit How can a request which differs in something as vital as the session description (SDP) be considered idempotent? If you don't want to indicate a change, then don't change the request. Whatever semantics you associate with no SDP should be consistently applied across INVITEs and re-INVITEs. Or perhaps I don't understand your comments(?) /sean -- Sean Olson Rick Workman wrote: > As per a previous discussion on this list, I favour the sematics that > says no SDP means "no change". I may be misunderstanding something, > but it's hard to imagine a more idempotent operation than one which > does nothing. There seem to be three proposals I've seen so far which > attach some meaning to no SDP content: _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 20:27:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA02666 for ; Tue, 5 Dec 2000 20:27:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A623944339; Tue, 5 Dec 2000 19:27:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 2862144336 for ; Tue, 5 Dec 2000 17:21:20 -0500 (EST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id PAA00831; Tue, 5 Dec 2000 15:21:11 -0800 (PST) Received: from cisco.com (vvs-lab-nat-171-69-180-242.cisco.com [171.69.180.242]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ACU05622 (AUTH vzubarev); Tue, 5 Dec 2000 15:21:09 -0800 (PST) Message-ID: <3A2D7852.37CE0D2B@cisco.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: Sean Olson Cc: "Henning G. Schulzrinne" , Jonathan Rosenberg , Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A2D3312.CD68AECB@cs.columbia.edu> <3A2D54FA.87099FD5@cisco.com> <3A2CFF98.CAFF5DD5@ericsson.com> Content-Type: multipart/alternative; boundary="------------A4731986810B269DCFDBFA25" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 15:20:50 -0800 --------------A4731986810B269DCFDBFA25 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Completely agree - in my opinion both INVITE and re-INVITE should have the same meaning in relation to SDP: no SDP - no media at all, no change in SDP compared to the previous one - no change in media. Looks simple and consistent. Sean Olson wrote: > Then why make the differentiation between the procedure for a re-INVITE > and the initial INVITE. If we accept that a re-INVITE with no SDP means > no media, then an initial INVITE with no SDP should take on the same > meaning. IMO, this is easier to implement because of the consistency. > > /sean > -- > Sean Olson > > Vladislav Zubarev wrote: > > > What difference does it make whether we send an INVITE with no SDP at > > all or > > an SDP with no lines ? > > I guess the purpose of SDP for the most part is to advertise the > > codecs party > > supports and RTP ports (and of course connection address as well). > > So if we do not send SDP in INVITE or send SDP with no media lines, > > then in both > > cases we should advertise our codecs and RTP ports later - either in > > ACK or in re-INVITE. > > > > What's the point then to send SDP with no m lines ? > > And I guess the understanding of section 6 by most people was exactly > > as > > no SDP in INVITE (not as SDP without m lines). > > > > I completely agree with Jonathan in the meaning of re-INVITE with no > > SDP > > as no media and indication of "no change " by including the same SDP > > as last > > one we sent. > > > > Thanks. > > > > "Henning G. Schulzrinne" wrote: > > > >> Jonathan Rosenberg wrote: > >> > > >> > Hmm. > >> > > >> > The problem is that we allow INVITE with no SDP, and it appears > >> this is used > >> > quite a bit (note the massive flames to my suggestion to remove > >> it). Since > >> > >> I thought the flames were about disallowing SDP in ACKs, not about > >> "no > >> SDP". Obviously, ACK doesn't have SDP most of the time. > >> > >> > we allow it in an initial INVITE, we need to allow it in a > >> re-INVITE. So, > >> > the question becomes, what is its meaning? > >> > >> > > >> > I think the initial thinking was that re-INVITE with no SDP means > >> "no > >> > change" in SDP. However, this breaks the idempotency of SIP, and > >> is probably > >> > a bad thing. The other alternative is that no SDP means no media. > >> This is > >> > consistent with its usage in initial INVITE today with H.323v1 > >> gateways, an > >> > makes it idemopotent for re-INVITEs. We can signal a "no-change" > >> in SDP by > >> > including the SDP we included in the previous message, with the > >> same version > >> > ID and all. If the last message had no SDP, meaning no media, then > >> you would > >> > still continue to signal no-change, and thus no media, with no > >> SDP. > >> > >> The problem is that while this definition is consistent with the > >> initial > >> INVITE (and subsequent ones), it doesn't quite work for ACK. At the > >> very > >> least, I would like to strongly discourage 'no SDP' in INVITE and > >> 200, > >> as it avoids these issues. > >> > >> > > >> > No m lines is something that has caused a lot of confusion. In the > >> beginning > >> > of section 6, the m line is not listed as optional (no star). The > >> text > >> > slightly above says there can be zero or more media descriptions. > >> I believe > >> > what this means is that if a media description is present, there > >> must be an > >> > m line, but media descriptions need not be present. However, I > >> think many > >> > folks assume there will be an m line. Thus, the INVITE with > >> media-on-hold > >> > made sure there was an m line, but had the same effect as if there > >> was none. > >> > > >> > >> The text below seems pretty clear: > >> > >> An announcement consists of a session-level section followed by > >> zero > >> or more media-level sections. The session-level part starts with > >> a > >> `v=' line and continues to the first media-level section. The > >> media > >> description starts with an `m=' line and continues to the next > >> media > >> description or end of the whole session description. In general, > >> > >> session-level values are the default for all media unless > >> overridden > >> by an equivalent media-level value. > >> > >> Later on pg. 7 (below a=*) > >> Zero or more media descriptions (see below) > >> > >> Media description > >> m= ... > >> > >> Thus, the whole thing (m and following) lines is optional. Within a > >> media section, obviously m= cannot optional (there wouldn't be one > >> then). > >> > >> Thus, I don't see the problem. Not allowing zero of an enumeration > >> is > >> generally a very bad idea. > >> -- > >> Henning Schulzrinne http://www.cs.columbia.edu/~hgs > >> > >> _______________________________________________ > >> SIP mailing list > >> SIP@lists.bell-labs.com > >> http://lists.bell-labs.com/mailman/listinfo/sip > > > > -- > > Vladislav Zubarev mailto:vzubarev@cisco.com > > Software Engineer http://www.cisco.com > > Cisco Systems, Inc. http://www.vovida.org > > > > -- Vladislav Zubarev mailto:vzubarev@cisco.com Software Engineer http://www.cisco.com Cisco Systems, Inc. http://www.vovida.org --------------A4731986810B269DCFDBFA25 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Completely agree - in my opinion both INVITE and re-INVITE should have the
same meaning in relation to SDP: no SDP - no media at all, no change in SDP compared to the
previous one - no change in media. Looks simple and consistent.
 

Sean Olson wrote:

Then why make the differentiation between the procedure for a re-INVITE
and the initial INVITE. If we accept that a re-INVITE with no SDP means
no media, then an initial INVITE with no SDP should take on the same
meaning. IMO, this is easier to implement because of the consistency.

/sean
--
Sean Olson <sean.olson@ericsson.com>

Vladislav Zubarev wrote:

> What difference does it make whether we send an INVITE with no SDP at
> all or
> an SDP with no lines ?
> I guess the purpose of SDP for the most part is to advertise the
> codecs party
> supports and RTP ports (and of course connection address as well).
> So if we do not send SDP in INVITE or send SDP with no media lines,
> then in both
> cases we should advertise our codecs and RTP ports later - either in
> ACK or in re-INVITE.
>
> What's the point then to send SDP with no m lines ?
> And I guess the understanding of section 6 by most people was exactly
> as
> no SDP in INVITE (not as SDP without m lines).
>
> I completely agree with Jonathan in the meaning of re-INVITE with no
> SDP
> as no media and indication of "no change " by including the same SDP
> as last
> one we sent.
>
> Thanks.
>
> "Henning G. Schulzrinne" wrote:
>
>> Jonathan Rosenberg wrote:
>> >
>> > Hmm.
>> >
>> > The problem is that we allow INVITE with no SDP, and it appears
>> this is used
>> > quite a bit (note the massive flames to my suggestion to remove
>> it). Since
>>
>> I thought the flames were about disallowing SDP in ACKs, not about
>> "no
>> SDP". Obviously, ACK doesn't have SDP most of the time.
>>
>> > we allow it in an initial INVITE, we need to allow it in a
>> re-INVITE. So,
>> > the question becomes, what is its meaning?
>>
>> >
>> > I think the initial thinking was that re-INVITE with no SDP means
>> "no
>> > change" in SDP. However, this breaks the idempotency of SIP, and
>> is probably
>> > a bad thing. The other alternative is that no SDP means no media.
>> This is
>> > consistent with its usage in initial INVITE today with H.323v1
>> gateways, an
>> > makes it idemopotent for re-INVITEs. We can signal a "no-change"
>> in SDP by
>> > including the SDP we included in the previous message, with the
>> same version
>> > ID and all. If the last message had no SDP, meaning no media, then
>> you would
>> > still continue to signal no-change, and thus no media, with no
>> SDP.
>>
>> The problem is that while this definition is consistent with the
>> initial
>> INVITE (and subsequent ones), it doesn't quite work for ACK. At the
>> very
>> least, I would like to strongly discourage 'no SDP' in INVITE and
>> 200,
>> as it avoids these issues.
>>
>> >
>> > No m lines is something that has caused a lot of confusion. In the
>> beginning
>> > of section 6, the m line is not listed as optional (no star). The
>> text
>> > slightly above says there can be zero or more media descriptions.
>> I believe
>> > what this means is that if a media description is present, there
>> must be an
>> > m line, but media descriptions need not be present. However, I
>> think many
>> > folks assume there will be an m line. Thus, the INVITE with
>> media-on-hold
>> > made sure there was an m line, but had the same effect as if there
>> was none.
>> >
>>
>> The text below seems pretty clear:
>>
>>    An announcement consists of a session-level section followed by
>> zero
>>    or more media-level sections.  The session-level part starts with
>> a
>>    `v=' line and continues to the first media-level section.  The
>> media
>>    description starts with an `m=' line and continues to the next
>> media
>>    description or end of the whole session description.  In general,
>>
>>    session-level values are the default for all media unless
>> overridden
>>    by an equivalent media-level value.
>>
>> Later on pg. 7 (below a=*)
>>    Zero or more media descriptions (see below)
>>
>>    Media description
>>    m= ...
>>
>> Thus, the whole thing (m and following) lines is optional. Within a
>> media section, obviously m= cannot optional (there wouldn't be one
>> then).
>>
>> Thus, I don't see the problem. Not allowing zero of an enumeration
>> is
>> generally a very bad idea.
>> --
>> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>>
>> _______________________________________________
>> SIP mailing list
>> SIP@lists.bell-labs.com
>> http://lists.bell-labs.com/mailman/listinfo/sip
>
> --
> Vladislav Zubarev        mailto:vzubarev@cisco.com
> Software Engineer        http://www.cisco.com
> Cisco Systems, Inc.      http://www.vovida.org
>
>

-- 
Vladislav Zubarev        mailto:vzubarev@cisco.com
Software Engineer        http://www.cisco.com
Cisco Systems, Inc.      http://www.vovida.org
  --------------A4731986810B269DCFDBFA25-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 20:37:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03890 for ; Tue, 5 Dec 2000 20:37:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 66A064434C; Tue, 5 Dec 2000 19:37:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 81A6744349 for ; Tue, 5 Dec 2000 19:36:09 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 17:35:40 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'Jo Hornsby'" , sip@lists.bell-labs.com Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 17:35:39 -0800 > So, proxy implementors have a choice when record-routing. Use > the approach I > have been advocating, which is not so hard and works > universally, and is > also the most robust, or, insert weirdo things into the RR in > the request, > change nothing in a response, and then implement special case > handling for > the cases where the UAS and/or UAC don't support Contact. > > So, as you say, I'd rather kill many birds with one stone, > and have a single > mechanism that handles all the cases we need to worry about. Ok great we agree. So the requirement on the funcionality is that: a proxy MUST be able to reproduce the forward direction routing action (ie forward request-uri and transport details) in the absence of Route headers on subsequent callleg requests. This may be accomplished using either stored local callleg state or information embedded into the Record-Route URL (and retrieved in the Request-URI). For requests in the reverse direction, Route-less requests may be forwarded to the From URL at the original source address (if this is known). Request-URI information embedded into the Record-Route URL SHOULD NOT be inserted without first encoding teh URL into base64 format or someother encoding scheme. Straight quoting of a Request-URI does not allow unambigous reconstruction. A proxy SHOULD also be able to determine the direction of a received request from the Record-Route (when received as Request-URI). The suggested method for achieving this behaviour statelessly is for the proxy to insert a Record-Route header in the request which indicates the reverse direction, eg Record-Route: and when the response is received, the proxy changes its Record-Route header to the forward direction and adds forwarding information, eg Record-Route: For robustness, this SHOULD be done even if there are preceeding Record-Route headers in the header list (other proxies may remove themselves from the Route lists at a later time). If multiple Record-Route headers are added to a single call-leg request (eg spiral routes) then they MUST be distinguishable, eg Record-Route: What do people think? It's readable, fairly simple and robust. Just placing encoded data in the user part isn't very readable. eg sip:78786AB88CedjjH7656ehkkiKJDS@myproxy.com does tell you anything about what the porxy is trying to do (eg, direction). Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 21:40:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18650 for ; Tue, 5 Dec 2000 21:40:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C3E944338; Tue, 5 Dec 2000 20:39:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 0CB4444336 for ; Tue, 5 Dec 2000 20:38:00 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA18672; Tue, 5 Dec 2000 21:37:50 -0500 (EST) Message-ID: <3A2DA67E.2905A10@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Zubarev Cc: Jonathan Rosenberg , Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A2D3312.CD68AECB@cs.columbia.edu> <3A2D54FA.87099FD5@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 21:37:50 -0500 Content-Transfer-Encoding: 7bit Vladislav Zubarev wrote: > > What difference does it make whether we send an INVITE with no SDP at > all or > an SDP with no lines ? > I guess the purpose of SDP for the most part is to advertise the > codecs party > supports and RTP ports (and of course connection address as well). > So if we do not send SDP in INVITE or send SDP with no media lines, > then in both > cases we should advertise our codecs and RTP ports later - either in > ACK or in re-INVITE. > Indeed. If we can agree on "no SDP - no media" (sounds like a good placard to wave...), we would not need SDP without m lines, although systems should be able to handle this as being equivalent. I would prefer a single way of saying "no media", but it's probably too late for that. > What's the point then to send SDP with no m lines ? > And I guess the understanding of section 6 by most people was exactly > as > no SDP in INVITE (not as SDP without m lines). > > I completely agree with Jonathan in the meaning of re-INVITE with no > SDP > as no media and indication of "no change " by including the same SDP > as last > one we sent. Also, this is trivial to detect at the receiver, without doing a byte-by-byte comparison, as the version number in the o= line will be the same. > -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 22:17:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA22769 for ; Tue, 5 Dec 2000 22:17:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 23DE644360; Tue, 5 Dec 2000 21:17:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id E8E3544336 for ; Tue, 5 Dec 2000 20:11:04 -0500 (EST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id SAA16601; Tue, 5 Dec 2000 18:10:58 -0800 (PST) Received: from cisco.com (vvs-lab-nat-171-69-180-242.cisco.com [171.69.180.242]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id ACV03802 (AUTH vzubarev); Tue, 5 Dec 2000 18:10:55 -0800 (PST) Message-ID: <3A2DA01B.15653C68@cisco.com> From: Vladislav Zubarev X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en, ru MIME-Version: 1.0 To: Sean Olson , "Henning G. Schulzrinne" , Jonathan Rosenberg , Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A2D3312.CD68AECB@cs.columbia.edu> <3A2D54FA.87099FD5@cisco.com> <3A2CFF98.CAFF5DD5@ericsson.com> <3A2D7852.37CE0D2B@cisco.com> Content-Type: multipart/alternative; boundary="------------84B8AFEB4B41F1D49BF1EFE5" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 05 Dec 2000 18:10:36 -0800 --------------84B8AFEB4B41F1D49BF1EFE5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry, with this approach - we have to differentiate between initial INVITE and re-INVITE: no SDP in initial INVITE - we'll send SDP in ACK no SDP in re-INVITE - no media. Vladislav Zubarev wrote: > Completely agree - in my opinion both INVITE and re-INVITE should have > the > same meaning in relation to SDP: no SDP - no media at all, no change > in SDP compared to the > previous one - no change in media. Looks simple and consistent. > > > Sean Olson wrote: > >> Then why make the differentiation between the procedure for a >> re-INVITE >> and the initial INVITE. If we accept that a re-INVITE with no SDP >> means >> no media, then an initial INVITE with no SDP should take on the same >> >> meaning. IMO, this is easier to implement because of the >> consistency. >> >> /sean >> -- >> Sean Olson >> >> Vladislav Zubarev wrote: >> >> > What difference does it make whether we send an INVITE with no SDP >> at >> > all or >> > an SDP with no lines ? >> > I guess the purpose of SDP for the most part is to advertise the >> > codecs party >> > supports and RTP ports (and of course connection address as well). >> >> > So if we do not send SDP in INVITE or send SDP with no media >> lines, >> > then in both >> > cases we should advertise our codecs and RTP ports later - either >> in >> > ACK or in re-INVITE. >> > >> > What's the point then to send SDP with no m lines ? >> > And I guess the understanding of section 6 by most people was >> exactly >> > as >> > no SDP in INVITE (not as SDP without m lines). >> > >> > I completely agree with Jonathan in the meaning of re-INVITE with >> no >> > SDP >> > as no media and indication of "no change " by including the same >> SDP >> > as last >> > one we sent. >> > >> > Thanks. >> > >> > "Henning G. Schulzrinne" wrote: >> > >> >> Jonathan Rosenberg wrote: >> >> > >> >> > Hmm. >> >> > >> >> > The problem is that we allow INVITE with no SDP, and it appears >> >> >> this is used >> >> > quite a bit (note the massive flames to my suggestion to remove >> >> >> it). Since >> >> >> >> I thought the flames were about disallowing SDP in ACKs, not >> about >> >> "no >> >> SDP". Obviously, ACK doesn't have SDP most of the time. >> >> >> >> > we allow it in an initial INVITE, we need to allow it in a >> >> re-INVITE. So, >> >> > the question becomes, what is its meaning? >> >> >> >> > >> >> > I think the initial thinking was that re-INVITE with no SDP >> means >> >> "no >> >> > change" in SDP. However, this breaks the idempotency of SIP, >> and >> >> is probably >> >> > a bad thing. The other alternative is that no SDP means no >> media. >> >> This is >> >> > consistent with its usage in initial INVITE today with H.323v1 >> >> gateways, an >> >> > makes it idemopotent for re-INVITEs. We can signal a >> "no-change" >> >> in SDP by >> >> > including the SDP we included in the previous message, with the >> >> >> same version >> >> > ID and all. If the last message had no SDP, meaning no media, >> then >> >> you would >> >> > still continue to signal no-change, and thus no media, with no >> >> SDP. >> >> >> >> The problem is that while this definition is consistent with the >> >> initial >> >> INVITE (and subsequent ones), it doesn't quite work for ACK. At >> the >> >> very >> >> least, I would like to strongly discourage 'no SDP' in INVITE and >> >> >> 200, >> >> as it avoids these issues. >> >> >> >> > >> >> > No m lines is something that has caused a lot of confusion. In >> the >> >> beginning >> >> > of section 6, the m line is not listed as optional (no star). >> The >> >> text >> >> > slightly above says there can be zero or more media >> descriptions. >> >> I believe >> >> > what this means is that if a media description is present, >> there >> >> must be an >> >> > m line, but media descriptions need not be present. However, I >> >> think many >> >> > folks assume there will be an m line. Thus, the INVITE with >> >> media-on-hold >> >> > made sure there was an m line, but had the same effect as if >> there >> >> was none. >> >> > >> >> >> >> The text below seems pretty clear: >> >> >> >> An announcement consists of a session-level section followed >> by >> >> zero >> >> or more media-level sections. The session-level part starts >> with >> >> a >> >> `v=' line and continues to the first media-level section. The >> >> >> media >> >> description starts with an `m=' line and continues to the next >> >> >> media >> >> description or end of the whole session description. In >> general, >> >> >> >> session-level values are the default for all media unless >> >> overridden >> >> by an equivalent media-level value. >> >> >> >> Later on pg. 7 (below a=*) >> >> Zero or more media descriptions (see below) >> >> >> >> Media description >> >> m= ... >> >> >> >> Thus, the whole thing (m and following) lines is optional. Within >> a >> >> media section, obviously m= cannot optional (there wouldn't be >> one >> >> then). >> >> >> >> Thus, I don't see the problem. Not allowing zero of an >> enumeration >> >> is >> >> generally a very bad idea. >> >> -- >> >> Henning Schulzrinne http://www.cs.columbia.edu/~hgs >> >> >> >> _______________________________________________ >> >> SIP mailing list >> >> SIP@lists.bell-labs.com >> >> http://lists.bell-labs.com/mailman/listinfo/sip >> > >> > -- >> > Vladislav Zubarev mailto:vzubarev@cisco.com >> > Software Engineer http://www.cisco.com >> > Cisco Systems, Inc. http://www.vovida.org >> > >> > > > -- > Vladislav Zubarev mailto:vzubarev@cisco.com > Software Engineer http://www.cisco.com > Cisco Systems, Inc. http://www.vovida.org > > -- Vladislav Zubarev mailto:vzubarev@cisco.com Software Engineer http://www.cisco.com Cisco Systems, Inc. http://www.vovida.org --------------84B8AFEB4B41F1D49BF1EFE5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Sorry, with this approach - we have to differentiate between initial
INVITE and re-INVITE:
no SDP in initial INVITE - we'll send SDP in ACK
no SDP in re-INVITE - no media.

Vladislav Zubarev wrote:

Completely agree - in my opinion both INVITE and re-INVITE should have the
same meaning in relation to SDP: no SDP - no media at all, no change in SDP compared to the
previous one - no change in media. Looks simple and consistent.
 

Sean Olson wrote:

Then why make the differentiation between the procedure for a re-INVITE
and the initial INVITE. If we accept that a re-INVITE with no SDP means
no media, then an initial INVITE with no SDP should take on the same
meaning. IMO, this is easier to implement because of the consistency.

/sean
--
Sean Olson <sean.olson@ericsson.com>

Vladislav Zubarev wrote:

> What difference does it make whether we send an INVITE with no SDP at
> all or
> an SDP with no lines ?
> I guess the purpose of SDP for the most part is to advertise the
> codecs party
> supports and RTP ports (and of course connection address as well).
> So if we do not send SDP in INVITE or send SDP with no media lines,
> then in both
> cases we should advertise our codecs and RTP ports later - either in
> ACK or in re-INVITE.
>
> What's the point then to send SDP with no m lines ?
> And I guess the understanding of section 6 by most people was exactly
> as
> no SDP in INVITE (not as SDP without m lines).
>
> I completely agree with Jonathan in the meaning of re-INVITE with no
> SDP
> as no media and indication of "no change " by including the same SDP
> as last
> one we sent.
>
> Thanks.
>
> "Henning G. Schulzrinne" wrote:
>
>> Jonathan Rosenberg wrote:
>> >
>> > Hmm.
>> >
>> > The problem is that we allow INVITE with no SDP, and it appears
>> this is used
>> > quite a bit (note the massive flames to my suggestion to remove
>> it). Since
>>
>> I thought the flames were about disallowing SDP in ACKs, not about
>> "no
>> SDP". Obviously, ACK doesn't have SDP most of the time.
>>
>> > we allow it in an initial INVITE, we need to allow it in a
>> re-INVITE. So,
>> > the question becomes, what is its meaning?
>>
>> >
>> > I think the initial thinking was that re-INVITE with no SDP means
>> "no
>> > change" in SDP. However, this breaks the idempotency of SIP, and
>> is probably
>> > a bad thing. The other alternative is that no SDP means no media.
>> This is
>> > consistent with its usage in initial INVITE today with H.323v1
>> gateways, an
>> > makes it idemopotent for re-INVITEs. We can signal a "no-change"
>> in SDP by
>> > including the SDP we included in the previous message, with the
>> same version
>> > ID and all. If the last message had no SDP, meaning no media, then
>> you would
>> > still continue to signal no-change, and thus no media, with no
>> SDP.
>>
>> The problem is that while this definition is consistent with the
>> initial
>> INVITE (and subsequent ones), it doesn't quite work for ACK. At the
>> very
>> least, I would like to strongly discourage 'no SDP' in INVITE and
>> 200,
>> as it avoids these issues.
>>
>> >
>> > No m lines is something that has caused a lot of confusion. In the
>> beginning
>> > of section 6, the m line is not listed as optional (no star). The
>> text
>> > slightly above says there can be zero or more media descriptions.
>> I believe
>> > what this means is that if a media description is present, there
>> must be an
>> > m line, but media descriptions need not be present. However, I
>> think many
>> > folks assume there will be an m line. Thus, the INVITE with
>> media-on-hold
>> > made sure there was an m line, but had the same effect as if there
>> was none.
>> >
>>
>> The text below seems pretty clear:
>>
>>    An announcement consists of a session-level section followed by
>> zero
>>    or more media-level sections.  The session-level part starts with
>> a
>>    `v=' line and continues to the first media-level section.  The
>> media
>>    description starts with an `m=' line and continues to the next
>> media
>>    description or end of the whole session description.  In general,
>>
>>    session-level values are the default for all media unless
>> overridden
>>    by an equivalent media-level value.
>>
>> Later on pg. 7 (below a=*)
>>    Zero or more media descriptions (see below)
>>
>>    Media description
>>    m= ...
>>
>> Thus, the whole thing (m and following) lines is optional. Within a
>> media section, obviously m= cannot optional (there wouldn't be one
>> then).
>>
>> Thus, I don't see the problem. Not allowing zero of an enumeration
>> is
>> generally a very bad idea.
>> --
>> Henning Schulzrinne   http://www.cs.columbia.edu/~hgs
>>
>> _______________________________________________
>> SIP mailing list
>> SIP@lists.bell-labs.com
>> http://lists.bell-labs.com/mailman/listinfo/sip
>
> --
> Vladislav Zubarev        mailto:vzubarev@cisco.com
> Software Engineer        http://www.cisco.com
> Cisco Systems, Inc.      http://www.vovida.org
>
>

-- 
Vladislav Zubarev        mailto:vzubarev@cisco.com
Software Engineer        http://www.cisco.com
Cisco Systems, Inc.      http://www.vovida.org
 
-- 
Vladislav Zubarev        mailto:vzubarev@cisco.com
Software Engineer        http://www.cisco.com
Cisco Systems, Inc.      http://www.vovida.org
  --------------84B8AFEB4B41F1D49BF1EFE5-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 5 23:41:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA08806 for ; Tue, 5 Dec 2000 23:41:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 08F9444359; Tue, 5 Dec 2000 22:41:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 6933944336 for ; Tue, 5 Dec 2000 22:40:06 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 20:39:37 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'Jo Hornsby'" , sip@lists.bell-labs.com Subject: RE: [SIP] RECORD-ROUTE/ROUTE requirements MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 20:39:36 -0800 > > So, proxy implementors have a choice when record-routing. Use > > the approach I > > have been advocating, which is not so hard and works > > universally, and is > > also the most robust, or, insert weirdo things into the RR in > > the request, > > change nothing in a response, and then implement special case > > handling for > > the cases where the UAS and/or UAC don't support Contact. > > > > So, as you say, I'd rather kill many birds with one stone, > > and have a single > > mechanism that handles all the cases we need to worry about. > > Ok great we agree. > > So the requirement on the funcionality is that: a proxy MUST > be able to > reproduce the forward direction routing action (ie forward > request-uri and > transport details) in the absence of Route headers on > subsequent callleg > requests. This may be accomplished using either stored local > callleg state > or information embedded into the Record-Route URL (and > retrieved in the > Request-URI). For requests in the reverse direction, > Route-less requests may > be forwarded to the From URL at the original source address > (if this is > known). Or alternatively (for the lazy stateless record-routing proxy), you could simply include the From URL and the request forwarding information in the request's Record-Route header. Record-Route: <1@myproxy.com; rr-from=43237du8d8d8Eud63f8Fd63;rr-faddr=123.43.78.122; rr-uri=784ff76v8f8f83dfgFd2sDfd799;rr-raddr=54.23.1.42> This means the proxy can always determine the direction (from matching the From) and how to forward a call leg request AND it doesn't require the proxy to examine or mess with the Record-Route headers in the response (at the cost of a lot of bandwidth). [Of course this is all up to the proxy how to achieve the required behaviour ..... but just to prove its possible to statelessly not mess with the response.] Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 00:22:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA18614 for ; Wed, 6 Dec 2000 00:22:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B30DD44359; Tue, 5 Dec 2000 23:22:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 7033344336 for ; Tue, 5 Dec 2000 23:21:08 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 5 Dec 2000 21:20:39 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "Henning G. Schulzrinne" , Billy Biggs , sip@lists.bell-labs.com Subject: RE: [SIP] Re: My comments on bis-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 5 Dec 2000 21:20:37 -0800 > > > 5. Due to the proliferation of the Also header in BYE > > requests, I would > > > suggest that it be added to the bis draft, with its meaning > > > restricted to use with the BYE method. > > > > Tentatively added. > > Hold on a sec.... BYE/Also is in a draft that has expired a > long time ago. I > thought we revisited this and came up with the REFER > mechanism. Also, AFAIK, > has been discarded, along with its usage in BYE. I don't know what > proliferation you are talking about. Jonathan, It is such a simple yet useful mechanism (that I beleive quite a few implementations support), isn't it reasonable to leave it in the bis draft even though it does overlap (or is a subset of) the functionality of the ful blown REFER. I know you want to keep SIP trimmed to the bare essentials but I think this is a high gain verse low complexity addition. [Whereeas AFAIK doesn't fit this criteria in my mind - it deserves the full REFER implementation.] Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 01:19:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA13011 for ; Wed, 6 Dec 2000 01:19:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7425844338; Wed, 6 Dec 2000 00:19:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id 6921744336 for ; Wed, 6 Dec 2000 00:18:31 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eB66JnB12912 for ; Wed, 6 Dec 2000 11:49:49 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eB65mgk11387 for ; Wed, 6 Dec 2000 11:19:08 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652569AD.001F54C7 ; Wed, 6 Dec 2000 11:12:13 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: sip@lists.bell-labs.com Message-ID: <652569AD.001F5418.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: [SIP] query on forking. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 6 Dec 2000 11:12:10 +0530 Hi, assume I want to set up a chat with a group called "all-boys". My proxy server knows who all are in "all-boys" , I dont. so I send a message: MESSAGE sip:all-boys@hss.hns.com and the server forks this to sip:boy1@hss.hns.com sip:boy2@hss.hns.com Typically, if say boy1 returned OK and boy2 some 4xx message, the forking proxy would only send me the 200 OK. (best response) However I want to receive both success and failure. That is, I want to know if boy2 returned fail . This may be necessary when I am sending a group request to people and my intent is not a "reach first" but a "reach all". If I know boy2 failed, I might use another means to send him the same message. Note that I do not want to broadcast or multicast. so my question is: is there any way to use a forking service here and have it return all responses and not only the "best" responses ? I noticed the recurse tag in caller and callee preferences - but that only seems to take care of either replying recursively to 300 class messages or sending them back to the caller. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 05:57:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04570 for ; Wed, 6 Dec 2000 05:57:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 121C244338; Wed, 6 Dec 2000 04:57:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60]) by lists.bell-labs.com (Postfix) with ESMTP id 9FBDE44336 for ; Wed, 6 Dec 2000 04:56:12 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 6 Dec 2000 10:56:02 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id KAA00273; Wed, 6 Dec 2000 10:55:56 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569AD.003C0968 ; Wed, 6 Dec 2000 10:55:45 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Sean Olson Cc: Rick Workman , "Henning G. Schulzrinne" , Jonathan Rosenberg , Brett Tate , Sip Mail List Message-ID: <802569AD.003C06B4.00@marconicomms.com> Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re -invite response] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 6 Dec 2000 10:55:33 +0000 An initial invite without an SDP does mean no change; there was no media before the request, there is no media after the request; therefore a re-INVITE with no SDP should mean no change. As the intent of SIP is to control sessions of any kind by seperating session control from media control there are two logical processing entities addressed by a SIP message; the session control entity and the media control entity. The session control entity is addressed by the SIP methods and headers, the media control entity is addressed by the message body if present.; if the message body is not present then this latter entity cannot be addressed and therefore no change can be effected. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 08:18:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03980 for ; Wed, 6 Dec 2000 08:18:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 589DB4434A; Wed, 6 Dec 2000 07:18:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by lists.bell-labs.com (Postfix) with ESMTP id EEF9744336 for ; Wed, 6 Dec 2000 07:17:45 -0500 (EST) Received: from oleane (dyn-1-1-091.Vin.dialup.oleane.fr [195.25.4.91]) by smtp4.cluster.oleane.net with SMTP id eB6DHZi92799 for ; Wed, 6 Dec 2000 14:17:35 +0100 (CET) Message-ID: <008a01c05f87$381fb680$8001a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0087_01C05F8F.993C45C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] IP.Net call for papers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 6 Dec 2000 14:19:52 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_0087_01C05F8F.993C45C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable =20 The dead line for the IP.Net call for papers has been postponed to = December 22nd. Get more details at: http://www.upperside.fr/baipnet.htm Due to the success of the exhibition part, the event will take place = from 19 to 22 June at the Sofitel Hotel in Paris. ------=_NextPart_000_0087_01C05F8F.993C45C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
 =20
The dead line for the IP.Net call = for papers has=20 been postponed to December 22nd.
Get more details at:
http://www.upperside.fr/baip= net.htm
Due to the success of the exhibition = part, the=20 event will take place from 19 to 22 June at the Sofitel Hotel in=20 Paris.
 
 
------=_NextPart_000_0087_01C05F8F.993C45C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 09:03:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13991 for ; Wed, 6 Dec 2000 09:03:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 040614435C; Wed, 6 Dec 2000 08:03:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1162B44336 for ; Wed, 6 Dec 2000 08:02:18 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id IAA17673; Wed, 6 Dec 2000 08:58:15 -0500 (EST) Message-ID: <3A2E45F8.CDA3E4EF@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: Sean Olson , Rick Workman , Jonathan Rosenberg , Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <802569AD.003C06B4.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 06 Dec 2000 08:58:16 -0500 Content-Transfer-Encoding: 7bit The "no SDP - no change" model has the advantage that it works for ACK (where there usually is no SDP) and various 1xx responses, in addition to INVITE and re-INVITE. Even in this model, sending an INVITE or 200-INVITE without SDP is probably a bad idea since it prevents stateless recovery from earlier failures. The "no SDP - no media" model is probably closer to what people are implementing right now, but only holds for INVITE and re-INVITE. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 09:12:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA16019 for ; Wed, 6 Dec 2000 09:12:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 37FC644363; Wed, 6 Dec 2000 08:12:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E758144336 for ; Wed, 6 Dec 2000 08:11:58 -0500 (EST) Received: from dynamicsoft.com (ip106.honxr1.ras.tele.dk [195.249.119.106]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA27768; Wed, 6 Dec 2000 09:14:11 -0500 (EST) Message-ID: <3A2E4956.EC73098C@dynamicsoft.com> From: Anders Kristensen X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vladislav Zubarev Cc: "Henning G. Schulzrinne" , Jonathan Rosenberg , Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A2D3312.CD68AECB@cs.columbia.edu> <3A2D54FA.87099FD5@cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 06 Dec 2000 15:12:38 +0100 Content-Transfer-Encoding: 7bit Vladislav Zubarev wrote: > > What difference does it make whether we send an INVITE with no SDP at > all or > an SDP with no lines ? In initial INVITE: No SDP the other guy should propose a set of media streams SDP but no m= lines a session is being set up in which there is initially no media streams. This can be changed with re-INVITEs, but the callee CANNOT add m= lines to the response. In re-INVITE: No SDP well, that's what the argument is about SDP but no m= lines ordinary re-INVITE (legal only when no streams have been set up) I can see how no SDP in initial INVITE can be said to mean "no change", it's more of a stretch to say it means "put on hold" (or "take off hold" as ironically it was at the beginning of this thread). > I guess the purpose of SDP for the most part is to advertise the > codecs party > supports and RTP ports (and of course connection address as well). > So if we do not send SDP in INVITE or send SDP with no media lines, > then in both > cases we should advertise our codecs and RTP ports later - either in > ACK or in re-INVITE. > > What's the point then to send SDP with no m lines ? Maybe there's an intent to set up media streams later. Maybe two endpoints just want to establish a signaling relationship early so that they know they're there. Maybe to test signaling without worrying about media. Doesn't really matter - it's a simple generalization of how SIP uses SDP and should be allowed. -- Anders Kristensen _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 09:22:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18188 for ; Wed, 6 Dec 2000 09:22:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0D0DD4436C; Wed, 6 Dec 2000 08:22:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id F23D344336 for ; Wed, 6 Dec 2000 08:21:03 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id JAA18745 for ; Wed, 6 Dec 2000 09:20:55 -0500 (EST) Received: (from hgs@localhost) by bart.cs.columbia.edu (8.9.3/8.9.3) id JAA08098; Wed, 6 Dec 2000 09:20:54 -0500 (EST) From: Henning Schulzrinne Message-Id: <200012061420.JAA08098@bart.cs.columbia.edu> To: sip@lists.bell-labs.com List: sip@lists.bell-labs.com Subject: [SIP] CFP IPtel'2001 Workshop: Extended deadline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 6 Dec 2000 09:20:54 -0500 (EST) Call for Papers 2nd IP Telephony Workshop April 2-3, 2001 - Columbia University, New York City http://www.fokus.gmd.de/events/iptel2001/ Objectives ---------- Internet telephony is rapidly evolving from research to design and deployment. The objectives of the IP Telephony Workshop are to bring together researchers, developers, vendors and service providers active in this area and stimulate discussion on innovation, research, implementation, deployment experiences and future directions. Scope & Topics -------------- Original technical articles related to IP telephony are solicited. Only papers with significant technical content, not "white papers" or tutorials, will be considered for publication: - Research papers (unique ideas, novel algorithms, architectures, measurements, theoretical and/or analytical contributions) - Surveys, state-of-the-art studies, technology comparisons - Implementation and deployment reports - Standardization reports Particular areas of interest include, but are not limited to, the following: - Integration with Internet services (e.g., web, instant messaging, games) - Added-value services (e.g., call centers, conferencing) - Mobility and 3rd generation wireless - Authentication, authorization, accounting, charging, settlement - QoS support - Security (e.g., privacy, authentication, certification authorities, firewall traversal) - Call signaling & processing - Feature creation - Supporting services (e.g., call routing, lookup services) - Audio & video encoding and transmission - Management and provisioning - Interworking with the PSTN - Design and deployment considerations (e.g., performance, scalability, reliability) Important Dates --------------- Full paper due February 10th, 2001 Notification of acceptance March 15th, 2001 Final version due March 25th, 2001 Program published and March 15th, 2001 registration opens Workshop April 2nd-3rd, 2001 iptel2001 Organizing Committee ------------------------------ Program Chair H. Schulzrinne Columbia University Program Committee M. Arango Sun Microsystems F. Baker Cisco W. Bauerfeld T-Nova G. Bond AT&T Research S. Bradner Harvard University G. Carle GMD FOKUS J. Crowcroft UCL C. Huitema Microsoft G. S. Kuo National Central University, Taiwan J. Kuthan GMD Fokus T. Magedanz IKV++ GmbH W. Marshall AT&T Research D. Medhi University of Missouri-Kansas City D. Oran Cisco J. Ott University of Bremen T. La Porta Bell Labs B. Rosen Marconi J. Rosenberg dynamicsoft H. Sinnreich MCI WorldCom R. Steinmetz Technical University of Darmstadt H. St’ttgen NEC CCRLE W. Wimmreuter Siemens L. Wolf University of Karlsruhe A. Wolisz Technical University of Berlin M. Zitterbart Technical University of Braunschweig Submission Instructions ----------------------- Authors are invited to submit full papers written in English before November 27th, 2000. The submissions will be reviewed, and accepted papers will be included in the program. Notifications of acceptance will be sent out on January 12th, 2000. Deadline for submission of camera-ready copies is January 31st, 2001. Authors of accepted papers will need to sign a Copyright Transfer Form and submit a Netbib entry. Papers must be submitted electronically using the Web site at http://www.cs.columbia.edu/iptel Submissions must be in PDF or Postscript; any other documents cannot be accepted. Postscript papers must use only standard PostScript fonts: Times Roman, Courier, Symbol, and Helvetica. Papers must be formatted according to the IEEE Transactions format except for the font size, which MUST be 11pt. Templates are available at the Web site http://www.fokus.gmd.de/events/iptel2001/cfp/ Because of the size limitation on the final manuscript, and to ensure that the reviewed paper and the final version have a similar size, papers with more than 11 pages cannot be reviewed. Submissions must include: title, authors, affiliation, abstract, list of keywords, and contact information. One of the authors of each accepted paper must present the paper at iptel'2001. Contact Address --------------- Please, send all your inquiries regarding iptel2001 to iptel2001@egroups.com. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 09:34:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA20894 for ; Wed, 6 Dec 2000 09:34:30 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 51A4F44377; Wed, 6 Dec 2000 08:34:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 7C6AC44365 for ; Wed, 6 Dec 2000 08:33:13 -0500 (EST) Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 6 Dec 2000 09:32:47 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YHZ38R72; Wed, 6 Dec 2000 09:32:49 -0500 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YFZBDYTC; Wed, 6 Dec 2000 09:32:47 -0500 Message-ID: <3A2E4E5A.1222D498@americasm01.nt.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: "Henning G. Schulzrinne" , Jonathan Rosenberg , Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A2D3312.CD68AECB@cs.columbia.edu> <3A2D6D7C.826FBCB9@americasm01.nt.com> <3A2D0C2F.DC0B0F53@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 06 Dec 2000 09:34:02 -0500 Content-Transfer-Encoding: 7bit Not sure I understand your point. An idempotent operation can be applied more than once with no subsequent effect after the first application.. The semantics I'm supporting is no SDP means no change to the media state. For the first INVITE, there's no media prior to the transaction, so there's no change. A re-INVITE with no SDP and prior media results in no change - prior media doesn't go away. Feels consistent to me. Rick Sean Olson wrote: > How can a request which differs in something as vital as the session > description (SDP) > be considered idempotent? If you don't want to indicate a change, then > don't change > the request. Whatever semantics you associate with no SDP should be > consistently > applied across INVITEs and re-INVITEs. Or perhaps I don't understand > your > comments(?) > > /sean > -- > Sean Olson > > Rick Workman wrote: > > > As per a previous discussion on this list, I favour the sematics that > > says no SDP means "no change". I may be misunderstanding something, > > but it's hard to imagine a more idempotent operation than one which > > does nothing. There seem to be three proposals I've seen so far which > > attach some meaning to no SDP content: _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 09:45:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22778 for ; Wed, 6 Dec 2000 09:45:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CEDEA44377; Wed, 6 Dec 2000 08:45:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from nw173.netaddress.usa.net (nw173.netaddress.usa.net [204.68.24.73]) by lists.bell-labs.com (Postfix) with SMTP id 0033344369 for ; Wed, 6 Dec 2000 08:44:00 -0500 (EST) Received: (qmail 2251 invoked by uid 60001); 6 Dec 2000 14:43:52 -0000 Message-ID: <20001206144352.2250.qmail@nw173.netaddress.usa.net> Received: from 204.68.24.73 by nw173 for [192.245.102.12] via web-mailer(34FM.0700.4.03) on Wed Dec 6 14:43:52 GMT 2000 From: lakshmi udaykumar To: SIP@lists.bell-labs.com X-Mailer: USANET web-mailer (34FM.0700.4.03) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Subject: [SIP] using lex and yacc for sip parser Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 6 Dec 00 07:43:52 MST Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA22778 Hi friends, i am using lex and yacc for sip parser. Is it necessary to divide everything like alphabets, digits into individual characters, since we may have to use sinlge characters and in lex tokens always matches with the longest match not the least. According to syntax given in rfc2543, space is not specified as they have given in the examples b/w tokens. I want to know wether to follow only syntax or to see examples to give space for better identification. Hope i will get early reply. Thanks lakshmi ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 10:12:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26926 for ; Wed, 6 Dec 2000 10:12:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0A0B644346; Wed, 6 Dec 2000 09:12:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis28.marconicomms.com (cvis28.marconicomms.com [195.99.244.60]) by lists.bell-labs.com (Postfix) with ESMTP id DC24544336 for ; Wed, 6 Dec 2000 09:11:52 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis28.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 6 Dec 2000 15:11:42 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id PAA02345; Wed, 6 Dec 2000 15:11:31 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569AD.00535A0D ; Wed, 6 Dec 2000 15:10:25 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: "Henning G. Schulzrinne" Cc: Sean Olson , Rick Workman , Jonathan Rosenberg , Brett Tate , Sip Mail List Message-ID: <802569AD.00535729.00@marconicomms.com> Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re -invite response] Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 6 Dec 2000 15:10:11 +0000 The extrapolation of the argument leads to the behaviour defined in section B.4 and B.6 of rfc2543bis-02 whereby the caller sends an SDP with no media lines and null connection addresses (0.0.0.0) if it doesn't yet have sufficient information to supply a 'full' description. As previously mentioned, no media lines is acceptable as per rfc2327 and the connection address of 0.0.0.0 should have no special meaning to the receiver of the SDP message . I prefer this model because it leads to cleaner implementations where new media control protocols can be adopted without having to unknit existing media control functions from session control functions. Obviously, the adoption of this model may lead to a period of special case handling for backwards compatibility but , IMO, the gain of future proofing implementations outweighs this penalty. It seems that the text in rfc2543bis-02 sect. 4.2.1 allowing a caller to send either no SDP or an SDP contaning no m lines to mean the same thing has caused the confusion; perhaps the paragraph in B.4 (which does not suggest sending no SDP) should be put here instead. Regards, K. Robinson "Henning G. Schulzrinne" on 06/12/2000 13:58:16 To: Keith Robinson/MAIN/MC1@MCMAIN cc: Sean Olson , Rick Workman , Jonathan Rosenberg , Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] The "no SDP - no change" model has the advantage that it works for ACK (where there usually is no SDP) and various 1xx responses, in addition to INVITE and re-INVITE. Even in this model, sending an INVITE or 200-INVITE without SDP is probably a bad idea since it prevents stateless recovery from earlier failures. The "no SDP - no media" model is probably closer to what people are implementing right now, but only holds for INVITE and re-INVITE. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 10:16:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27409 for ; Wed, 6 Dec 2000 10:16:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 646394436C; Wed, 6 Dec 2000 09:16:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 99BB144346 for ; Wed, 6 Dec 2000 09:15:02 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eB6FDqL10219; Wed, 6 Dec 2000 09:14:14 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id eB6FDpQ29344; Wed, 6 Dec 2000 09:13:51 -0600 (CST) Received: from ericsson.com (pc050190.exu.ericsson.se [138.85.50.190]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA02305; Wed, 6 Dec 2000 09:13:51 -0600 (CST) Message-ID: <3A2DF3E4.8FA134EC@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Rick Workman Cc: "Henning G. Schulzrinne" , Jonathan Rosenberg , Brett Tate , Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A2D3312.CD68AECB@cs.columbia.edu> <3A2D6D7C.826FBCB9@americasm01.nt.com> <3A2D0C2F.DC0B0F53@ericsson.com> <3A2E4E5A.1222D498@americasm01.nt.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 06 Dec 2000 09:08:04 +0100 Content-Transfer-Encoding: 7bit An idempotent operation is one in which *identical* requests can be applied successively with no subsequent effects. If you send an initial INVITE with SDP, then a re-INVITE with no SDP, these are not idempotent. This was my point. Of course, sending an INVITE with no SDP, followed by another INVITE with no SDP is consistent. /sean Rick Workman wrote: > Not sure I understand your point. An idempotent operation can be applied > more than once with no subsequent effect after the first application.. The > semantics I'm supporting is no SDP means no change to the media state. > > For the first INVITE, there's no media prior to the transaction, so there's > no change. A re-INVITE with no SDP and prior media results in no change - > prior media doesn't go away. Feels consistent to me. > > Rick > > Sean Olson wrote: > > > How can a request which differs in something as vital as the session > > description (SDP) > > be considered idempotent? If you don't want to indicate a change, then > > don't change > > the request. Whatever semantics you associate with no SDP should be > > consistently > > applied across INVITEs and re-INVITEs. Or perhaps I don't understand > > your > > comments(?) > > > > /sean > > -- > > Sean Olson > > > > Rick Workman wrote: > > > > > As per a previous discussion on this list, I favour the sematics that > > > says no SDP means "no change". I may be misunderstanding something, > > > but it's hard to imagine a more idempotent operation than one which > > > does nothing. There seem to be three proposals I've seen so far which > > > attach some meaning to no SDP content: > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 10:23:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28276 for ; Wed, 6 Dec 2000 10:23:21 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 94018443A1; Wed, 6 Dec 2000 09:20:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251]) by lists.bell-labs.com (Postfix) with ESMTP id AA1E14439D for ; Wed, 6 Dec 2000 09:19:48 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id KAA00440; Wed, 6 Dec 2000 10:14:32 -0500 (EST) Message-ID: <3A2E590B.7087831C@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: lakshmi udaykumar Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] using lex and yacc for sip parser References: <20001206144352.2250.qmail@nw173.netaddress.usa.net> Content-Type: multipart/alternative; boundary="------------5601F41A323E1FB62A228B20" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 06 Dec 2000 10:19:39 -0500 --------------5601F41A323E1FB62A228B20 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Dont use lex and yacc. Use antlr. lex and yacc were designed for programming languages with a consistent set of tokens. lakshmi udaykumar wrote: > Hi friends, > > i am using lex and yacc for sip parser. > Is it necessary to divide everything like > alphabets, digits into individual characters, > since we may have to use sinlge characters and > in lex tokens always matches with the longest match > not the least. > > According to syntax given in rfc2543, space is not > specified as they have given in the examples b/w > tokens. I want to know wether to follow only syntax > or to see examples to give space for better identification. > > Hope i will get early reply. > Thanks > lakshmi > > ____________________________________________________________________ > Get free email and a permanent address at http://www.netaddress.com/?N=1 > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------5601F41A323E1FB62A228B20 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dont use lex  and yacc. Use antlr. lex and yacc were designed for programming languages with a consistent set of tokens.

lakshmi udaykumar wrote:

Hi friends,

i am using lex and yacc for sip parser.
Is it necessary to divide everything like
alphabets, digits into individual characters,
since we may have to use sinlge characters and
in lex tokens always matches with the longest match
not the least.

According to syntax given in rfc2543, space is not
specified as they have given in the examples b/w
tokens. I want to know wether to follow only syntax
or to see examples to give space for better identification.

Hope i will get early reply.
Thanks
lakshmi

____________________________________________________________________
Get free email and a permanent address at http://www.netaddress.com/?N=1

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------5601F41A323E1FB62A228B20-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 10:39:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01551 for ; Wed, 6 Dec 2000 10:39:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E4CB4435D; Wed, 6 Dec 2000 09:39:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 716C544363 for ; Wed, 6 Dec 2000 09:38:03 -0500 (EST) Received: from zcard00n.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 6 Dec 2000 10:37:41 -0500 Received: from zmerd00d.ca.nortel.com ([47.128.128.104]) by zcard00n.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YHZ380CL; Wed, 6 Dec 2000 10:37:30 -0500 Received: from americasm01.nt.com (rworkman-2.ca.nortel.com [47.155.69.160]) by zmerd00d.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id YFZBDYYT; Wed, 6 Dec 2000 10:37:29 -0500 Message-ID: <3A2E5D83.119936E6@americasm01.nt.com> X-Sybari-Space: 00000000 00000000 00000000 From: "Rick Workman" Organization: Nortel Networks X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Sean Olson Cc: Sip Mail List Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] References: <3A2D3312.CD68AECB@cs.columbia.edu> <3A2D6D7C.826FBCB9@americasm01.nt.com> <3A2D0C2F.DC0B0F53@ericsson.com> <3A2E4E5A.1222D498@americasm01.nt.com> <3A2DF3E4.8FA134EC@ericsson.com> Content-Type: multipart/alternative; boundary="------------8C02ABE3F5A39D3E0B854CE5" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 06 Dec 2000 10:38:43 -0500 --------------8C02ABE3F5A39D3E0B854CE5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sean Olson wrote: > An idempotent operation is one in which *identical* requests > can be applied successively with no subsequent effects. > > If you send an initial INVITE with SDP, then a re-INVITE with > no SDP, these are not idempotent. This was my point. > But I don't consider these identical requests - one has SDP and the other doesn't. > > Of course, sending an INVITE with no SDP, followed by > another INVITE with no SDP is consistent. > > /sean > > Rick Workman wrote: > > > Not sure I understand your point. An idempotent operation can be applied > > more than once with no subsequent effect after the first application.. The > > semantics I'm supporting is no SDP means no change to the media state. > > > > For the first INVITE, there's no media prior to the transaction, so there's > > no change. A re-INVITE with no SDP and prior media results in no change - > > prior media doesn't go away. Feels consistent to me. > > > > Rick > > > > Sean Olson wrote: > > > > > How can a request which differs in something as vital as the session > > > description (SDP) > > > be considered idempotent? If you don't want to indicate a change, then > > > don't change > > > the request. Whatever semantics you associate with no SDP should be > > > consistently > > > applied across INVITEs and re-INVITEs. Or perhaps I don't understand > > > your > > > comments(?) > > > > > > /sean > > > -- > > > Sean Olson > > > > > > Rick Workman wrote: > > > > > > > As per a previous discussion on this list, I favour the sematics that > > > > says no SDP means "no change". I may be misunderstanding something, > > > > but it's hard to imagine a more idempotent operation than one which > > > > does nothing. There seem to be three proposals I've seen so far which > > > > attach some meaning to no SDP content: > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip --------------8C02ABE3F5A39D3E0B854CE5 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit  

Sean Olson wrote:

An idempotent operation is one in which *identical* requests
can be applied successively with no subsequent effects.

If you send an initial INVITE with SDP, then a re-INVITE with
no SDP, these are not idempotent.  This was my point.
 

But I don't consider these identical requests - one has SDP and the other doesn't.
 
Of course, sending an INVITE with no SDP, followed by
another INVITE with no SDP is consistent.

/sean

Rick Workman wrote:

> Not sure I understand your point. An idempotent operation can be applied
> more than once with no subsequent effect after the first application.. The
> semantics I'm supporting is no SDP means no change to the media state.
>
> For the first INVITE, there's no media prior to the transaction, so there's
> no change. A re-INVITE with no SDP and prior media results in no change -
> prior media doesn't go away. Feels consistent to me.
>
> Rick
>
> Sean Olson wrote:
>
> > How can a request which differs in something as vital as the session
> > description (SDP)
> > be considered idempotent? If you don't want to indicate a change, then
> > don't change
> > the request. Whatever semantics you associate with no SDP should be
> > consistently
> > applied across INVITEs and re-INVITEs. Or perhaps I don't understand
> > your
> > comments(?)
> >
> > /sean
> > --
> > Sean Olson <sean.olson@ericsson.com>
> >
> > Rick Workman wrote:
> >
> > > As per a previous discussion on this list, I favour the sematics that
> > > says no SDP means "no change". I may be misunderstanding something,
> > > but it's hard to imagine a more idempotent operation than one which
> > > does nothing. There seem to be three proposals I've seen so far which
> > > attach some meaning to no SDP content:
>
> _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip

--------------8C02ABE3F5A39D3E0B854CE5-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 10:42:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02328 for ; Wed, 6 Dec 2000 10:42:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 73C824436C; Wed, 6 Dec 2000 09:39:27 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 1AB7F44369 for ; Wed, 6 Dec 2000 09:38:04 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Wed, 6 Dec 2000 10:37:19 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Wed, 6 Dec 2000 10:37:21 -0500 Message-ID: <13E2EF604DE5D111B2E50000F80824E80517BA7E@zwdld001.ca.nortel.com> From: "Louis-Nicolas Hamer" To: SIP@lists.bell-labs.com Cc: "'Henry.Sinnreich@wcom.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C05F9A.6867A880" X-Orig: Subject: [SIP] RE: draft-hamer-sip-session-auth-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 6 Dec 2000 10:37:14 -0500 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_01C05F9A.6867A880 Content-Type: text/plain; charset="iso-8859-1" Henry, Thanks for your comments. Please see my response after [LNH]. Cheers, Louis-Nicolas Hamer > > >-----Original Message----- >From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com] >Sent: December 1, 2000 5:13 PM >Subject: RE: draft-hamer-sip-session-auth-00.txt > > >There may not be enough time in the SIP WG, but SIP and session >authorization is now the subject of several draft and needs to be >discussed at least on the list. > >For the IETF, Internet-wide compatibility is of higher priority, >since private IP networks and ISP networks have some latitude to >customize their internal network design, such a illustrated in the >draft: >http://ietf.org/internet-drafts/draft-ietf-sip-manyfolks-resource-00.txt > >This leads to top priority for the notions of: > >1 - Interdomain, no matter how the domains are designed internally, >2 - Clearinghouses as trust brokers between domains. > Clearinghouses are widely used at present for VoIP. > >Getting now to the intradomain aspects, I would like to discuss the >model in Discussing the >references, on page 9: >>there are a number of issues with this model: > >> The same policy server makes decisions related to both service >> authorization and resource utilisation. This is only possible if >> the service provider and access provider are one and the same >> business entity and if the network is simple enough to warrant >> deployment of a single policy server. > >The service provider and access provider DO NOT NEED to be the same, >since policy can be outsourced between business partners. See >http://ietf.org/internet-drafts/draft-gross-sipaq-00.txt and >http://ietf.org/internet-drafts/draft-gross-cops-sip-00.txt > [LNH] Fair enough. We will reference this scenario by inserting the phrase "[This is only possible if] ... or if the service provider and access provider outsource policy decisions to a common, trusted third party [ref]." > >A second theme of the draft-hamer-sip-session-auth-00.txt is also: > >> The end host is connected to a known point in the network that >> defines the edge router and policy server for that host. This is >> only possible in a network with fixed hosts and fixed routers >> where the administrative burden of defining these associations >> make this a feasible undertaking. > >This is also arguable, since: > >1 - SIP clients have to authenticate themselves to the SIP proxies > that control service inside the domain, so they are known, >2 - SIP proxies, policy servers and edge routers are the crown > jewels of the ISP, similar to the IN in telephony and well > known and monitored network elements. Their security > associations are not only administered by hand, > but also with great care. > [LNH] The issue we were highlighting here is, in particular, the mobile (wireless) environment although we believe similar problems may arise in fixed networks with complex topologies. Although security associations may be tightly controlled as you indicated, there is still the issue of determining which entities are involved at the time the session is being set-up. Let's take a relatively simple scenario. The mobile client discovers (or is assigned to) a SIP proxy at time t=0. The mobile then roams through the network and initiates a session at time t=T. The edge router serving the mobile at time t=T may be different from the edge router serving the mobile at time t=0. Therefore, although the SIP signalling packets may still find their way back to the assigned proxy, the proxy has no way of knowing which edge router is currently serving the mobile. In the associated model, we assume that the security associations between network elements do, in fact, exist a priori but that some mechanism is required to allow the elements involved in the session to discover each other. > >Also, why modifications to three protocols? >>- Resource reservation protocol >>- Policy management protocol > (Which: COPS or DIAMETER?) >>- Session management protocol > (I suppose SDP is meant by this?) > [LNH] The ticket is being reflected through the client. The media authorisation is granted by the proxy and signalled to the client via the session management protocol (SIP/SDP). This authorisation is presented by the client to the edge router when it reserves resources (e.g. via RSVP) in order to acquire the QoS required for the media stream. The ticket is passed by the edge router to its policy decision point (e.g. via COPS) to be used by the PDP for admission control. We believe that the framework we describe for media authorisation is generic enough to be applied to various session/call management protocols (e.g. SIP, H.323) in conjunction with various resource reservation protocols (e.g. RSVP, YESSIR) and policy management protocols (e.g. COPS, ?DIAMETER?). Our intent is to define extensions for SIP/SDP, RSVP and COPS-RSVP to support the ticket concept; we invite other interested parties to define extensions for any other protocols of interest to them. > >The references above and the preceding work contains a large number >of scenarios and call flows, showing that existing protocols do the >job without any modifications. As for SIP, please see: >http://ietf.org/internet-drafts/draft-johnston-sip-osp-token-01.txt > [LNH] We believe we have already described scenarios in our draft that cannot be realised by the token as currently defined. Arguably, the intent of the token and the intent of the ticket are somewhat different -- your token solves an inter-domain accounting issue and our ticket solves an intra- and inter-domain resource authorisation issue. There may be opportunities to combine the token and ticket into a single entity; we welcome having those discussions with you. > >Finally some nits regarding terminology: > >I don't know what BEARER is in the IETF context. The ITU BEARER is >very different from IETF TRANSPORT and NETWORK and imply very >different design philosophies. Mixing these terms can lead to utter >confusion. > [LNH] TRANSPORT and NETWORK also have connotations associated with them. We are attempting to distinguish between packet flows used to carry session control messages and packet flows used to carry the media streams themselves. If you don't like CONTROL and BEARER, we'd be happy to adopt any other terminology you might suggest to convey the same distinctions. > >SESSION MANAGER: SIP does only session setup, as its name implies. >The IETF Multimedia Conferencing Architecture confarch-03> and other MMUSIC work makes it clear that they don't >believe in managing sessions. (There is always an exception that >confirms the rule: SIP 3rd party call control) > >>Session management protocol? See the above. > [LNH] As we indicated above, we have defined a framework for media authorisation that is generic. While SESSION MANAGER may not be part of the SIP lexicon, it has (in our experience) been used in other environments. Again, if you find the terminology confusing or offensive, we'd be happy to adopt any other terminology you might suggest while retaining the generic nature of the framework. > >>Bearer Control Domain. >Suggest we avoid loose definitions of domains. A domain is a domain >is a domain in the DNS sense. > [LNH] The term was not used loosely since the non-associated model is aimed at co-ordinating actions across domain boundaries. However, if you find the terminology confusing in the other models, we'd be happy to adopt any other terminology you might suggest while retaining the framework goal of defining a solution for the non-associated model. > >Voila! Plenty of items to discuss. If there is no time in the SIP WG >we may have to try and meet at the bar. > [LNH] Thank you for the comments. I look forward to a night at the bar with you :-) _________________________________________________ Louis-Nicolas Hamer Phone: (613) 768-3409 Wireless IP Architect Fax: (613) 763-2686 Wireless Technology Labs ESN: 398-3409 Nortel Networks nhamer@nortelnetworks.com _________________________________________________ ------_=_NextPart_001_01C05F9A.6867A880 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: draft-hamer-sip-session-auth-00.txt

Henry,

Thanks for your comments. Please = see my response after [LNH].

Cheers,
Louis-Nicolas Hamer

>
>
>-----Original = Message-----
>From: Henry Sinnreich [mailto:Henry.Sinnreich@wcom.com= ]
>Sent: December 1, 2000 5:13 = PM
>Subject: RE: = draft-hamer-sip-session-auth-00.txt
>
>
>There may not be enough = time in the SIP WG, but SIP and session
>authorization is now the = subject of several draft and needs to be
>discussed at least on the = list.
>
>For the IETF, Internet-wide = compatibility is of higher priority,
>since private IP networks = and ISP networks have some latitude to
>customize their internal = network design, such a illustrated in the
>draft:
>http://ietf.org/internet-drafts/draft-ietf-sip-manyfol= ks-resource-00.txt
>
>This leads to top priority = for the notions of:
>
>1 - Interdomain, no matter = how the domains are designed internally,
>2 - Clearinghouses as trust = brokers between domains.
>    = Clearinghouses are widely used at present for VoIP.
>
>Getting now to the = intradomain aspects, I would like to discuss the
>model in = <draft-hamer-sip-session-auth-00.txt> Discussing the
>references, on page = 9:
>>there are a number of = issues with this model:
>
>> The same policy server = makes decisions related to both service
>> authorization and = resource utilisation. This is only possible if
>> the service provider = and access provider are one and the same
>> business entity and if = the network is simple enough to warrant
>> deployment of a single = policy server.
>
>The service provider and = access provider DO NOT NEED to be the same,
>since policy can be = outsourced between business partners. See
>http://ietf.org/internet-drafts/draft-gross-sipaq-00.t= xt and
>http://ietf.org/internet-drafts/draft-gross-cops-sip-0= 0.txt
>
[LNH] Fair enough. We will = reference this scenario by inserting the phrase "[This is only = possible if] ... or if the service provider and access provider = outsource policy decisions to a common, trusted third party = [ref]."

>
>A second theme of the = draft-hamer-sip-session-auth-00.txt is also:
>
>> The end host is = connected to a known point in the network that
>> defines the edge = router and policy server for that host. This is
>> only possible in a = network with fixed hosts and fixed routers
>> where the = administrative burden of defining these associations
>> make this a feasible = undertaking.
>
>This is also arguable, = since:
>
>1 - SIP clients have to = authenticate themselves to the SIP proxies
>    that = control service inside the domain, so they are known,
>2 - SIP proxies, policy = servers and edge routers are the crown
>    jewels = of the ISP, similar to the IN in telephony and well
>    known = and monitored network elements. Their security
>    = associations are not only administered by hand,
>    but also = with great care.
>
[LNH] The issue we were = highlighting here is, in particular, the mobile (wireless) environment = although we believe similar problems may arise in fixed networks with = complex topologies. Although security associations may be tightly = controlled as you indicated, there is still the issue of determining = which entities are involved at the time the session is being = set-up.

Let's take a relatively simple = scenario. The mobile client discovers (or is assigned to) a SIP proxy = at time t=3D0. The mobile then roams through the network and initiates = a session at time t=3DT. The edge router serving the mobile at time = t=3DT may be different from the edge router serving the mobile at time = t=3D0. Therefore, although the SIP signalling packets may still find = their way back to the assigned proxy, the proxy has no way of knowing = which edge router is currently serving the mobile.

In the associated model, we = assume that the security associations between network elements do, in = fact, exist a priori but that some mechanism is required to allow the = elements involved in the session to discover each other.

>
>Also, why modifications to = three protocols?
>>-  Resource = reservation protocol
>>-  Policy = management protocol
>    (Which: = COPS or DIAMETER?)
>>-  Session = management protocol
>    (I = suppose SDP is meant by this?)
>
[LNH] The ticket is being = reflected through the client. The media authorisation is granted by the = proxy and signalled to the client via the session management protocol = (SIP/SDP). This authorisation is presented by the client to the edge = router when it reserves resources (e.g. via RSVP) in order to acquire = the QoS required for the media stream. The ticket is passed by the edge = router to its policy decision point (e.g. via COPS) to be used by the = PDP for admission control.

We believe that the framework we = describe for media authorisation is generic enough to be applied to = various session/call management protocols (e.g. SIP, H.323) in = conjunction with various resource reservation protocols (e.g. RSVP, = YESSIR) and policy management protocols (e.g. COPS, = ?DIAMETER?).

Our intent is to define = extensions for SIP/SDP, RSVP and COPS-RSVP to support the ticket = concept; we invite other interested parties to define extensions for = any other protocols of interest to them.

>
>The references above and = the preceding work contains a large number
>of scenarios and call = flows, showing that existing protocols do the
>job without any = modifications. As for SIP, please see:
>http://ietf.org/internet-drafts/draft-johnston-sip-osp= -token-01.txt
>
[LNH] We believe we have = already described scenarios in our draft that cannot be realised by the = token as currently defined. Arguably, the intent of the token and the = intent of the ticket are somewhat different -- your token solves an = inter-domain accounting issue and our ticket solves an intra- and = inter-domain resource authorisation issue. There may be opportunities = to combine the token and ticket into a single entity; we welcome having = those discussions with you.

>
>Finally some nits regarding = terminology:
>
>I don't know what BEARER is = in the IETF context. The ITU BEARER is
>very different from IETF = TRANSPORT and NETWORK and imply very
>different design = philosophies. Mixing these terms can lead to utter
>confusion.
>
[LNH] TRANSPORT and NETWORK = also have connotations associated with them. We are attempting to = distinguish between packet flows used to carry session control messages = and packet flows used to carry the media streams themselves. If you = don't like CONTROL and BEARER, we'd be happy to adopt any other = terminology you might suggest to convey the same = distinctions.

>
>SESSION MANAGER: SIP does = only session setup, as its name implies.
>The IETF Multimedia = Conferencing Architecture <draft-ietf-mmusic-
>confarch-03> and other = MMUSIC work makes it clear that they don't
>believe in managing = sessions. (There is always an exception that
>confirms the rule: SIP 3rd = party call control)
>
>>Session management = protocol? See the above.
>
[LNH] As we indicated above, we = have defined a framework for media authorisation that is generic. While = SESSION MANAGER may not be part of the SIP lexicon, it has (in our = experience) been used in other environments. Again, if you find the = terminology confusing or offensive, we'd be happy to adopt any other = terminology you might suggest while retaining the generic nature of the = framework.

>
>>Bearer Control = Domain.
>Suggest we avoid loose = definitions of domains. A domain is a domain
>is a domain in the DNS = sense.
>
[LNH] The term was not used = loosely since the non-associated model is aimed at co-ordinating = actions across domain boundaries.

However, if you find the = terminology confusing in the other models, we'd be happy to adopt any = other terminology you might suggest while retaining the framework goal = of defining a solution for the non-associated model.

>
>Voila! Plenty of items to = discuss. If there is no time in the SIP WG
>we may have to try and meet = at the bar.
>
[LNH] Thank you for the = comments. I look forward to a night at the bar with you :-)




_________________________________________________
Louis-Nicolas = Hamer       Phone: (613) = 768-3409  
Wireless IP = Architect     Fax:   (613) = 763-2686
Wireless Technology Labs  = ESN:   398-3409
Nortel = Networks          &nbs= p;           &nbs= p;           &nbs= p; 

nhamer@nortelnetworks.com
_________________________________________________


------_=_NextPart_001_01C05F9A.6867A880-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 10:49:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA03953 for ; Wed, 6 Dec 2000 10:49:42 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF1FA443A8; Wed, 6 Dec 2000 09:40:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from gorilla.mchh.siemens.de (gorilla.mchh.siemens.de [194.138.158.18]) by lists.bell-labs.com (Postfix) with ESMTP id 00BD34435D for ; Wed, 6 Dec 2000 09:39:41 -0500 (EST) Received: from blues.mchh.siemens.de (mail3.mchh.siemens.de [194.138.158.227] (may be forged)) by gorilla.mchh.siemens.de (8.9.3/8.9.3) with ESMTP id QAA10861; Wed, 6 Dec 2000 16:38:59 +0100 (MET) Received: from mchh247e.demchh201e.icn.siemens.de ([139.21.200.57]) by blues.mchh.siemens.de (8.9.1/8.9.1) with ESMTP id QAA13411; Wed, 6 Dec 2000 16:39:22 +0100 (MET) Received: by MCHH247E with Internet Mail Service (5.5.2650.21) id ; Wed, 6 Dec 2000 16:39:21 +0100 Message-ID: <15A0F4D7BF4DD411BD4C0008C71E2F280D72C6@MCHH233E> From: Tan Ya-Ching To: "'Fairlie-Cuninghame, Robert'" , "'Jonathan Rosenberg'" , "Henning G. Schulzrinne" , Billy Biggs , sip@lists.bell-labs.com Subject: RE: [SIP] Re: My comments on bis-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 6 Dec 2000 16:38:48 +0100 If you add the Also header to the bis draft, you would also have to add the Requested-By header for the INVITE as a result of the BYE with Also. The REFER draft has introduced the Referred-By header for the same purpose. So should it be the Requested-By (as in the expired draft-ietf-mmusic-sip-cc-01), or the Referred-By header ? Ya-Ching > -----Original Message----- > From: Fairlie-Cuninghame, Robert [SMTP:rfairlie@nuera.com] > Sent: Wednesday, December 06, 2000 6:21 AM > To: 'Jonathan Rosenberg'; Henning G. Schulzrinne; Billy Biggs; sip@lists.bell-labs.com > Subject: RE: [SIP] Re: My comments on bis-02 > > > > > 5. Due to the proliferation of the Also header in BYE > > > requests, I would > > > > suggest that it be added to the bis draft, with its meaning > > > > restricted to use with the BYE method. > > > > > > Tentatively added. > > > > Hold on a sec.... BYE/Also is in a draft that has expired a > > long time ago. I > > thought we revisited this and came up with the REFER > > mechanism. Also, AFAIK, > > has been discarded, along with its usage in BYE. I don't know what > > proliferation you are talking about. > > Jonathan, > > It is such a simple yet useful mechanism (that I beleive quite a few > implementations support), isn't it reasonable to leave it in the bis draft > even though it does overlap (or is a subset of) the functionality of the ful > blown REFER. > > I know you want to keep SIP trimmed to the bare essentials but I think this > is a high gain verse low complexity addition. [Whereeas AFAIK doesn't fit > this criteria in my mind - it deserves the full REFER implementation.] > > Robert. > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 11:28:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA13744 for ; Wed, 6 Dec 2000 11:28:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E62904439A; Wed, 6 Dec 2000 10:28:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 460F744336 for ; Wed, 6 Dec 2000 10:27:38 -0500 (EST) Received: from dynamicsoft.com (1Cust172.tnt6.san-jose.ca.da.uu.net [63.36.207.172]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA29813; Wed, 6 Dec 2000 11:29:47 -0500 (EST) Message-ID: <3A2E68CB.FAD0F1E5@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bryan Thale Cc: jainsip@sun.com, sip@lists.bell-labs.com, Ross Lillie Subject: Re: [SIP] [JAIN SIP] Header names and type codes References: <3A26EA0B.BADCD544@dynamicsoft.com> <3A26FB82.8201F239@labs.mot.com> <3A270071.AD24CCC3@dynamicsoft.com> <3A2703ED.3C294813@labs.mot.com> <3A2782AF.A2E9D3B8@dynamicsoft.com> <3A27DF50.3C319B86@labs.mot.com> <3A27E7B6.6C740DFE@dynamicsoft.com> <3A27FEAD.ED3374C4@labs.mot.com> <3A2812C0.2C4E0E46@dynamicsoft.com> <3A28563D.8B4DD10E@labs.mot.com> <3A294F52.2F44994@dynamicsoft.com> <3A2C0BB9.7E7E0E3C@labs.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 06 Dec 2000 16:26:52 +0000 Content-Transfer-Encoding: 7bit Bryan, I think I should point out that UnrecognizedHeader is a misnomer - it should be UndefinedHeader. An application or an implementation may or may not recognize a header that is not defined in the API. Also an application uses the header and message classes provided by an implementation, it does not use its own, and is not allowed mix implementations. It creates these header and message objects through a factory. So if an implementation recognizes an undefined header - it can specify which type of header it is, which may be useful for the application (which may not recognise the undefined header). The same applies for an application passing an undefined header down to an implementation. We are simply providing the standard means to represent undefined headers. Implementing the GeneralHeader interface can be replaced by implementing both the ResponseHeader and RequestHeader interface. But if we are using a type attribute we need to define a general header type. I think we may have to stick to the type attribute rather than using header type interfaces, because an application does not use its own header classes - implying the need for an undefined header interface for each header type. Also there is significant overhead in using the instanceof operator rather than switching on the header type. I admit the interface approach is a more OO way to go - but it has been criticized as being inefficient. Regards, Chris Bryan Thale wrote: > Chris, > > > > I don't think a GeneralHeader interface tag is necessary since a > > > "general header" is simply a header that can be both a "request header" > > > and a "response header" and the multiple inheritance of interfaces > > > solves that problem nicely. > > > > I think a GeneralHeader interface would be useful to indicate to an application > > that it should copy a received unrecognised header into a response. > > > > Two points, first, if the header is unrecognized, it is not possible to > determine that it is a general header. The header is unrecognized; it > could be anything and SIP mandates that such headers be treated as > entity headers not general headers. > > Second, general headerness, if you will, can be determined by simply > testing instanceof ResponseHeader and/or instanceof RequestHeader Only > general headers will be instances of both RequestHeader and > ResponseHeader, so they can be adequately detected without a special > GeneralHeader type. By eliminating the redundant GeneralHeader tag, we > can simplify the API by allowing general headers to be processed along > with the other request or response headers as appropriate without > introducing a special case into the logic. > > > > interface EntityHeader extends Header; // Empty Interface > > > interface UnrecognizedHeader extends EntityHeader; > > > > The interfaces for different header types would imply the existence of > > UnrecognizedEntityHeader, UnrecognizedRequestHeader, UnrecognizedResponseHeader > > and UnrecognizedGeneralHeader rather than just UnrecognizedHeader. We would > > also need a createUnrecognizedEntityHeader, createUnrecognizedRequestHeader, > > createUnrecognizedResponseHeader and createUnrecognizedGeneralHeader methods on > > the JainSipHeaderFactory > > > > I don't follow. If the header is unrecognized, how can we make any > judgments about it being a request, response, general, or entity header? > > > Would it be preferable to just remove the setName (and setMethod) method from the > > Header interface, and only have the name parameter in the factory's createHeader > > method? If not, I would suggest that the setName method should not be any header > > interfaces - the name should be fixed upon creation of the object. > > > > By setMethod, do you mean setType? > > I think setType should be done away with entirely and setName moved to > the UnrecognizedHeader interface. The names of the headers should be > statically defined for all the recognized headers that have defined > interfaces in the API. The exception being the UnrecognizedHeader. In > that case, the name of the header must be determined from the actual > message header received over the wire. Since it can represent any new > or experimental header, we cannot possibly know its name in advance and > thus must set the name in the object we create to represent it. > > > Actually we could move both the getName() and setName() methods of header to UnrecognizedHeader - the > > application can use instanceof rather than getName() with the same advantages associated with the header > > type interfaces - the getName() method would only ever be invoked if(receivedHeader instanceof > > UnrecognizedHeader). [Of course if the application wants the actual text of the header name it can just use > > XXXHeader.name]. What do you think? > > > > I think getName is still an important method to have in the Header > interface. Headers have two basic properties, a name and a value. It > is just as valuable to have a sub-type independent way of retrieving a > header's name as it is to retrieve its value. In most cases, getName > will simply return the static XXXHeader.name value, but > UnrecognizedHeaders would return the "dynamically" set name of the > header. This is an important property because it allows a collection of > various header types to be processed as a collection of generic Header > objects without requiring explicit knowledge of the various sub-types of > Header. For example: > > void printHeaders( Header[] hdrs ) > { > for (i=0; i { > System.out.println( hdrs[i].getName() + ": " + > hdrs[i].getValue() ); > } > } > > Such a routine could handle any and all headers, recognized or > otherwise, and won't be impacted by the definition of new headers. I > realize that this particular example could be accomplished by invoking > the toString method, but my purpose is to illustrate that it might be > desirable to have access to a header's name as well as its value in a > generic manner. > > > So now things are looking like (with createMethods only for the bottom four of the hierarchy in > > JainSipHeaderFactory) > > > > Header > > | > > +---UnrecognizedHeader(getName(), setName()) > > | | > > | +-----------------------------------+ > > | | > > +---GeneralHeader | > > | | | > > | +---UnrecognizedGeneralHeader-------+ > > | | > > +---RequestHeader | > > | | | > > | +---UnrecognizedRequestHeader-------+ > > | | > > +---ResponseHeader | > > | | | > > | +---UnrecognizedResponseHeader------+ > > | | > > +---EntityHeader | > > | | > > +---UnrecognizedEntityHeader--------+ > > > > How does this look? > > > > I don't see the need for the UnrecognizedXxxHeader interfaces. If a SIP > stack received a header it didn't recognize, how would it choose which > UnrecognizedXxxHeader to create? On the other hand, why would an > application ever create an UnrecognizedXxxHeader? Since it is creating > the header, it *must* know what it is. > > Take, for example, an application that wanted to add a new experimental > general header, one that the SIP stack it was using didn't support. > Wouldn't that application define a class like > > public class XdashMyHeader implements RequestHeader, ResponseHeader, > etc., > > instantiate it, and then simply pass that object into the addHeader > method of the message under construction? While it is true that the SIP > Stack won't know exactly what the header represents, it can still do > everything it needs to do through the generic Header interface and the > type system. > > Bryan. > > -- > Bryan Thale > Motorola Labs, Networking and Infrastructure Research > mailto:thale@labs.mot.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 11:39:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA16308 for ; Wed, 6 Dec 2000 11:39:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA6A1443B4; Wed, 6 Dec 2000 10:39:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by lists.bell-labs.com (Postfix) with ESMTP id 5D536443B3 for ; Wed, 6 Dec 2000 10:38:51 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 6 Dec 2000 16:40:25 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id QAA11496; Wed, 6 Dec 2000 16:38:36 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569AD.005B6844 ; Wed, 6 Dec 2000 16:38:24 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: "Rick Workman" Cc: Sean Olson , Sip Mail List Message-ID: <802569AD.005B6629.00@marconicomms.com> Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re -invite response] Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=GxWSjuoHXtzSZRAK7bOKe9FKISBcAIbFrE05FRVIL1zv9yC32N9G7SUp" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 6 Dec 2000 16:38:13 +0000 --0__=GxWSjuoHXtzSZRAK7bOKe9FKISBcAIbFrE05FRVIL1zv9yC32N9G7SUp Content-type: text/plain; charset=us-ascii Content-Disposition: inline > An idempotent operation is one in which *identical* requests > can be applied successively with no subsequent effects. > > If you send an initial INVITE with SDP, then a re-INVITE with > no SDP, these are not idempotent. This was my point. > >>But I don't consider these identical requests - one has SDP and the other >>doesn't. Moreover, an INVITE and any subsequent re-INVITES can never be considered identical as at least the CSEQ value will be different in each. So, it seems that the argument relates to the idempotence in relation to the control of the media and the semantics of receiving no SDP in an INVITE. If we choose the model of no SDP - no change then an INVITE with SDP followed by a re-INVITE with no SDP, in the context of the media, leads to idempotent behaviour; if we choose no SDP - no media then an INVITE with no SDP followed by a re-INVITE with no SDP, in the context of media, leads to idempotent behaviour. whichever model we choose we can define idempotent behaviour for it, so the debate is which model to choose. As previously stated, IMO the no SDP - no change model will lead to cleaner implementations. "Rick Workman" on 06/12/2000 15:38:43 To: Sean Olson cc: Sip Mail List (bcc: Keith Robinson/MAIN/MC1) Subject: Re: [SIP] Re: No SDP => take off hold? [WAS: 3PCC and the re-invite response] Sean Olson wrote: > An idempotent operation is one in which *identical* requests > can be applied successively with no subsequent effects. > > If you send an initial INVITE with SDP, then a re-INVITE with > no SDP, these are not idempotent. This was my point. > But I don't consider these identical requests - one has SDP and the other doesn't. > > Of course, sending an INVITE with no SDP, followed by > another INVITE with no SDP is consistent. > > /sean > > Rick Workman wrote: > > > Not sure I understand your point. An idempotent operation can be applied > > more than once with no subsequent effect after the first application.. The > > semantics I'm supporting is no SDP means no change to the media state. > > > > For the first INVITE, there's no media prior to the transaction, so there's > > no change. A re-INVITE with no SDP and prior media results in no change - > > prior media doesn't go away. Feels consistent to me. > > > > Rick > > > > Sean Olson wrote: > > > > > How can a request which differs in something as vital as the session > > > description (SDP) > > > be considered idempotent? If you don't want to indicate a change, then > > > don't change > > > the request. Whatever semantics you associate with no SDP should be > > > consistently > > > applied across INVITEs and re-INVITEs. Or perhaps I don't understand > > > your > > > comments(?) > > > > > > /sean > > > -- > > > Sean Olson > > > > > > Rick Workman wrote: > > > > > > > As per a previous discussion on this list, I favour the sematics that > > > > says no SDP means "no change". I may be misunderstanding something, > > > > but it's hard to imagine a more idempotent operation than one which > > > > does nothing. There seem to be three proposals I've seen so far which > > > > attach some meaning to no SDP content: > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip --0__=GxWSjuoHXtzSZRAK7bOKe9FKISBcAIbFrE05FRVIL1zv9yC32N9G7SUp Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KJm5ic3A7DQo8cD48dHQ+U2VhbiBPbHNvbiB3cm90ZTo8L3R0Pg0KPGJs b2NrcXVvdGUgVFlQRT1DSVRFPjx0dD5BbiBpZGVtcG90ZW50IG9wZXJhdGlvbiBpcyBvbmUgaW4g d2hpY2ggKmlkZW50aWNhbCoNCnJlcXVlc3RzPC90dD4NCjxicj48dHQ+Y2FuIGJlIGFwcGxpZWQg c3VjY2Vzc2l2ZWx5IHdpdGggbm8gc3Vic2VxdWVudCBlZmZlY3RzLjwvdHQ+DQo8cD48dHQ+SWYg eW91IHNlbmQgYW4gaW5pdGlhbCBJTlZJVEUgd2l0aCBTRFAsIHRoZW4gYSByZS1JTlZJVEUgd2l0 aDwvdHQ+DQo8YnI+PHR0Pm5vIFNEUCwgdGhlc2UgYXJlIG5vdCBpZGVtcG90ZW50LiZuYnNwOyBU aGlzIHdhcyBteSBwb2ludC48L3R0Pg0KPGJyPiZuYnNwOzwvYmxvY2txdW90ZT4NCjx0dD5CdXQg SSBkb24ndCBjb25zaWRlciB0aGVzZSBpZGVudGljYWwgcmVxdWVzdHMgLSBvbmUgaGFzIFNEUCBh bmQgdGhlDQpvdGhlciBkb2Vzbid0LjwvdHQ+DQo8YmxvY2txdW90ZSBUWVBFPUNJVEU+Jm5ic3A7 DQo8YnI+PHR0Pk9mIGNvdXJzZSwgc2VuZGluZyBhbiBJTlZJVEUgd2l0aCBubyBTRFAsIGZvbGxv d2VkIGJ5PC90dD4NCjxicj48dHQ+YW5vdGhlciBJTlZJVEUgd2l0aCBubyBTRFAgaXMgY29uc2lz dGVudC48L3R0Pg0KPHA+PHR0Pi9zZWFuPC90dD4NCjxwPjx0dD5SaWNrIFdvcmttYW4gd3JvdGU6 PC90dD4NCjxwPjx0dD4+IE5vdCBzdXJlIEkgdW5kZXJzdGFuZCB5b3VyIHBvaW50LiBBbiBpZGVt cG90ZW50IG9wZXJhdGlvbiBjYW4NCmJlIGFwcGxpZWQ8L3R0Pg0KPGJyPjx0dD4+IG1vcmUgdGhh biBvbmNlIHdpdGggbm8gc3Vic2VxdWVudCBlZmZlY3QgYWZ0ZXIgdGhlIGZpcnN0IGFwcGxpY2F0 aW9uLi4NClRoZTwvdHQ+DQo8YnI+PHR0Pj4gc2VtYW50aWNzIEknbSBzdXBwb3J0aW5nIGlzIG5v IFNEUCBtZWFucyBubyBjaGFuZ2UgdG8gdGhlIG1lZGlhDQpzdGF0ZS48L3R0Pg0KPGJyPjx0dD4+ PC90dD4NCjxicj48dHQ+PiBGb3IgdGhlIGZpcnN0IElOVklURSwgdGhlcmUncyBubyBtZWRpYSBw cmlvciB0byB0aGUgdHJhbnNhY3Rpb24sDQpzbyB0aGVyZSdzPC90dD4NCjxicj48dHQ+PiBubyBj aGFuZ2UuIEEgcmUtSU5WSVRFIHdpdGggbm8gU0RQIGFuZCBwcmlvciBtZWRpYSByZXN1bHRzIGlu DQpubyBjaGFuZ2UgLTwvdHQ+DQo8YnI+PHR0Pj4gcHJpb3IgbWVkaWEgZG9lc24ndCBnbyBhd2F5 LiBGZWVscyBjb25zaXN0ZW50IHRvIG1lLjwvdHQ+DQo8YnI+PHR0Pj48L3R0Pg0KPGJyPjx0dD4+ IFJpY2s8L3R0Pg0KPGJyPjx0dD4+PC90dD4NCjxicj48dHQ+PiBTZWFuIE9sc29uIHdyb3RlOjwv dHQ+DQo8YnI+PHR0Pj48L3R0Pg0KPGJyPjx0dD4+ID4gSG93IGNhbiBhIHJlcXVlc3Qgd2hpY2gg ZGlmZmVycyBpbiBzb21ldGhpbmcgYXMgdml0YWwgYXMgdGhlDQpzZXNzaW9uPC90dD4NCjxicj48 dHQ+PiA+IGRlc2NyaXB0aW9uIChTRFApPC90dD4NCjxicj48dHQ+PiA+IGJlIGNvbnNpZGVyZWQg aWRlbXBvdGVudD8gSWYgeW91IGRvbid0IHdhbnQgdG8gaW5kaWNhdGUgYSBjaGFuZ2UsDQp0aGVu PC90dD4NCjxicj48dHQ+PiA+IGRvbid0IGNoYW5nZTwvdHQ+DQo8YnI+PHR0Pj4gPiB0aGUgcmVx dWVzdC4gV2hhdGV2ZXIgc2VtYW50aWNzIHlvdSBhc3NvY2lhdGUgd2l0aCBubyBTRFAgc2hvdWxk DQpiZTwvdHQ+DQo8YnI+PHR0Pj4gPiBjb25zaXN0ZW50bHk8L3R0Pg0KPGJyPjx0dD4+ID4gYXBw bGllZCBhY3Jvc3MgSU5WSVRFcyBhbmQgcmUtSU5WSVRFcy4gT3IgcGVyaGFwcyBJIGRvbid0IHVu ZGVyc3RhbmQ8L3R0Pg0KPGJyPjx0dD4+ID4geW91cjwvdHQ+DQo8YnI+PHR0Pj4gPiBjb21tZW50 cyg/KTwvdHQ+DQo8YnI+PHR0Pj4gPjwvdHQ+DQo8YnI+PHR0Pj4gPiAvc2VhbjwvdHQ+DQo8YnI+ PHR0Pj4gPiAtLTwvdHQ+DQo8YnI+PHR0Pj4gPiBTZWFuIE9sc29uICZsdDtzZWFuLm9sc29uQGVy aWNzc29uLmNvbT48L3R0Pg0KPGJyPjx0dD4+ID48L3R0Pg0KPGJyPjx0dD4+ID4gUmljayBXb3Jr bWFuIHdyb3RlOjwvdHQ+DQo8YnI+PHR0Pj4gPjwvdHQ+DQo8YnI+PHR0Pj4gPiA+IEFzIHBlciBh IHByZXZpb3VzIGRpc2N1c3Npb24gb24gdGhpcyBsaXN0LCBJIGZhdm91ciB0aGUgc2VtYXRpY3MN CnRoYXQ8L3R0Pg0KPGJyPjx0dD4+ID4gPiBzYXlzIG5vIFNEUCBtZWFucyAibm8gY2hhbmdlIi4g SSBtYXkgYmUgbWlzdW5kZXJzdGFuZGluZw0Kc29tZXRoaW5nLDwvdHQ+DQo8YnI+PHR0Pj4gPiA+ IGJ1dCBpdCdzIGhhcmQgdG8gaW1hZ2luZSBhIG1vcmUgaWRlbXBvdGVudCBvcGVyYXRpb24gdGhh bg0Kb25lIHdoaWNoPC90dD4NCjxicj48dHQ+PiA+ID4gZG9lcyBub3RoaW5nLiBUaGVyZSBzZWVt IHRvIGJlIHRocmVlIHByb3Bvc2FscyBJJ3ZlIHNlZW4NCnNvIGZhciB3aGljaDwvdHQ+DQo8YnI+ PHR0Pj4gPiA+IGF0dGFjaCBzb21lIG1lYW5pbmcgdG8gbm8gU0RQIGNvbnRlbnQ6PC90dD4NCjxi cj48dHQ+PjwvdHQ+DQo8YnI+PHR0Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX188L3R0Pg0KPGJyPjx0dD4+IFNJUCBtYWlsaW5nIGxpc3Q8L3R0Pg0KPGJy Pjx0dD4+IFNJUEBsaXN0cy5iZWxsLWxhYnMuY29tPC90dD4NCjxicj48dHQ+PiA8YSBocmVmPSJo dHRwOi8vbGlzdHMuYmVsbC1sYWJzLmNvbS9tYWlsbWFuL2xpc3RpbmZvL3NpcCI+aHR0cDovL2xp c3RzLmJlbGwtbGFicy5jb20vbWFpbG1hbi9saXN0aW5mby9zaXA8L2E+PC90dD48L2Jsb2NrcXVv dGU+DQo8L2h0bWw+DQoNCg== --0__=GxWSjuoHXtzSZRAK7bOKe9FKISBcAIbFrE05FRVIL1zv9yC32N9G7SUp-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 16:44:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA01897 for ; Wed, 6 Dec 2000 16:44:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 506F944339; Wed, 6 Dec 2000 15:44:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 93C4544338 for ; Wed, 6 Dec 2000 15:43:40 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA20685; Wed, 6 Dec 2000 13:43:38 -0800 (PST) Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126]) by imop.cisco.com (Mirapoint) with SMTP id AAC40290; Wed, 6 Dec 2000 13:43:17 -0800 (PST) Message-Id: <4.1.20001206124522.00d01160@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Jonathan Rosenberg , Billy Biggs , Alan Johnston From: Rohan Mahy Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00 Cc: Robert Sparks , Jonathan Rosenberg , SIP List In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 06 Dec 2000 13:45:25 -0800 At 10:11 AM 12/5/00 , Jonathan Rosenberg wrote: >Billy raises some very important issues. These are some of the things that >motivated a thread on the list many months back (on the road now and can't >dig up the reference), where we discussed adding control functionality to >SIP, and how this was insufficient for a full blown control and monitoring >protocol like megaco. We need to keep the distinction between MEGACO-style control, and what we need. 1) SIP uses requests, which the UAS can decline. 2) SIP abstracts away the user interface of the UA away from the verbs/methods used to do useful things. We need to request that call legs move around to include certain users. we *don't* need to be notified when someone presses "hookflash"; and we *don't* need to tell the UA exactly how to write something on a display (that may not even exist). >As Billy rightly observes, sending a refer for a sip URL with a BYE method >makes a lot of assumptions about how its processed in the recipient. It is >assuming that the UA matches the BYE with an existing call leg, it assumes >tags are handled, yes, the examples make a lot of assumpions. i don't think it is really such a big deal to codify this kind of behavior in some IETF document. then we can stop making assumptions about the semantics, and then we can make a lot of cool things work. the problem that i think is more significant is the retransmission problem that motivated Billy's REFERDONE method. >it assumes the UA is willing to accept REFERs with BYE, actually the UAC just _requests_ a REFER w/ BYE; the UAS is free to decline that request. >The simple fact is, SIP is a poor control protocol. If people want a real >protocol that can adequately remote control a phone, thats a totally >separate thing, with different primitives and communication requirements and >security implications. I believe SIP is entirely inadequate for such a job. I disagree. whatever this set of "control request" primitives is, it needs to follow the same path as the SIP signalling, and it needs to interact with the SIP security and policy rules, etc. etc. It seems logical that these primitives are indeed SIP messages. PHONECTL (while a reasonable stab at its problem set) currently assumes shared secrets between the controller and the phone (won't work for a Guest phone in my lobby), will need separate firewall treatment, and can't easily particpate in the mobile roaming aspects of SIP which are so nice. I believe that REFER with some additional semantic definition, is adequate for this job. >REFER was a sort-of-compromise; it introduced a little bit of control into >SIP. It was enough to do a bunch of simple things (call transfer >specifically), and as such its a nice primitive for building services. But, >I believe it is inadequate for a complete control protocol. Thus, I share >Billy's concerns about using it to hang up existing calls, among other >things. We've been pussy-footing around the nut of the call control problem for over a year now. If we ever want to get better-than-PSTN call-control services in a SIP environment, we need to define powerful, generic primitives now. >We should probably add text to REFER that is explicit about the requirements >(and non-requirements) for processing REFER at the recipient. > >Flame away. likewise ;-) thanks, -rohan >-Jonathan R. > >--- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 6 17:54:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA24422 for ; Wed, 6 Dec 2000 17:54:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7297144338; Wed, 6 Dec 2000 16:54:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 285D444336 for ; Wed, 6 Dec 2000 16:53:46 -0500 (EST) Received: from SUPERBEE (dsl081-162-189-sea1.dsl-isp.net [64.81.162.189]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id RAA05411; Wed, 6 Dec 2000 17:55:56 -0500 (EST) From: "Ben Campbell" To: "'Dean Willis'" , "'IETF SIP (E-mail)'" Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3B511@DYN-TX-EXCH-001.dynamicsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3010819@DYN-TX-EXCH-001.dynamicsoft.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Thread summary: 9/3-9/9 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 6 Dec 2000 16:51:07 -0600 Content-Transfer-Encoding: 7bit SIP list threads starting from 9/3 to 9/9. IPTelephony.com-Repeated spam 9/3/2000 Thread: SIP chat - Farhan asserts that MESSAGE does a good job, and asks how it evolves into multiway chats. Henning had recommended a mail list type approach, but there are issues with who hosts the list. Farhan recommends a fully-meshed peer to peer approach is appropriate for the typical message size and group sizes involved. He has an experimental system under test, but they don't have a good way to communicate the group list to new users as they join. 9/4/2000 Thread: A Question about Request-URI - Bodgey Lin Shaoh asks for clarification of the idea that the domain part of a request-URI might not match that of the receiving server. His questions are answered, but discussion reveals that the spec needs clarification on the flexibility of routing policies. Henning proposes an introductory paragraph to help clarify. Compiler's note: I did not find any messages committing whether or not said paragraph actually made into the spec. 9/4/2000 Thread: Tag in provisional response - Benny Prijono notes that bis-01 does not mandate servers to add tags to provisional responses for initial invite requests, and proposes that is should do so. Discussion indicates that any mandate stronger than SHOULD would not be backwards compatible with 2543, and that if a client cares which server a provisional response came from, the only solution is reliable provisional responses. 9/4/2000 Thread: Possible Refer Problem - Eric Tremblay notes that there is a dilemma when executing consultation transfer - should the refer-to contain the original URL used to call the transfer target (probably a proxy) or the actual contact used to finally reach the transfer target. The former could cause the transferred call to fork to a completely different location, the second bypasses domain policies implemented by the proxy. After some discussion, Jonathan suggests this could be handled using the caller preferences extension (accept-contact). The thread ended there, then was revived by Eric on 10/25 illustrating a potential failure of the accept-contact approach. Robert suggested a two phase approach, with an invite using the well known URL, then if that failed a second using accept-contact. Jonathan suggested adding that to the REFERS draft. Billy Biggs argued for the use of the actual contact instead of the well known URL. Compiler's note: The thread appears to end with no consensus--unless this has been resolved in future threads it may be an open issue that warrants discussion. 9/4/2000 Thread: REFER Referred-By syntax is broken - Henning mentions that the referred-by syntax violates sip extension rules. Compiler's note: I found no responses to his message. Could be an open issue. 9/5/2000 Thread: Revised minutes of SIP working group, meeting 48 - Dean posts revised minutes, stating they will stand unless further amendments are requested. The thread ends there, so if further amendments were requested, it didn't make it to the list. 9/6/2000 Thread: IM Questions - Bobby Sardana asks several questions about IM over SIP. Discussion evolves into a multiparty message discussion (see previous) and a discussion over merits of an explicit IM session vs. stateless IM. Compiler's note: I could not determine a consensus in the thread, but would suggest this is an item for the SIMPLE wg, should one actually exist. 9/6/2000 Thread: Two Keystroke Encoding - Skip Cave questions which encoding schemes to use for keystroke encoding. Discussion evolves into a stimulus vs. functional application protocol discussion. Jonathan suggests use of HTTP. Compiler's note: Thread ends without obvious consensus. 9/6/2000 Thread: Commentaries, FAQ on rfc2543 - Farhan proposes compilation of a FAQ and a "SIP Implementers Guide" to help newbies get started, and to cut down on repeated questions on the list. Henning points out that there are several papers serving this purpose that are linked to at http://www.cs.columbia.edu/sip . 9/6/2000 Thread: Receiving unrecognized To tags - Cliff Harris asks what should the proper behavior be if a UA received a request with an unknown Call ID and unknown To tag. He suggests that section 7 and 11 imply a rejection with 481, but section 10 implies a new call leg should be created. Also, should a UA that always uses the same To tag reject any request with a To tag that does not match? He also questioned the interaction of this with forking. Compiler's note: I found no direct responses to his questions. 9/6/2000 Thread: tel URL v. SIP URL - John Peterson notes that the "np-queried" parameter has been removed from the SIP URL, since a mechanism is now available in the tel URL to support local number portability, and asks if this means that in the long run SIP URLs are not the preferred method of carrying phone numbers, specially LRNs. He suggests that there might be some services that need to host-based routing, even after np-queries have occurred, and might be hindered by the stripping of host information if the requestURIs are converted to tel URLs. Discussion concludes that np-queried parameter can be included in user part of a SIP URL, since that can user the full BNF from the telephone-subscriber part of the tel URL. Also, Sean Olson commented that a tel URL can be used for hop to hop routing, where each element makes local policy decisions about where to route the next hop. 9/7/2000 Thread: Addressing devices without user identities - Henning reminds us that devices should not insert a dummy user section into a SIP URL. If the destination does not support the idea of users, then the user portion should just be left out. (ex sip:128.1.2.3, not sip:anybody@128.1.2.3) 9/7/2000 Thread: Speaking Opportunities - Claire Tranah solicits speakers for a SIP Implementations and Deployments conference in Lisbon on Dec 6-7. 9/7/2000 Thread:REGISTER method questions - M. Ranganathan asks questions about CSeq usage, contact replacement, and the meaning of "action value" in REGISTER. Answer send by Hisham Khartabil and clarified by Jonathan Rosenberg. 9/8/2000 Thread: Stateless Proxy - Albee Vimal asks questions about a stateless proxy querying a registrar and getting no contacts back for which proxy is the correct action. Discussion evolved into a discussion on proper roles for a stateless proxy, and proper handling of route/record-route. Henning proposed a paragraph to clarify, but there still seems to be confusion. Compiler's note: this may be an open item. 9/8/2000 Thread: REGISTER in call flow draft - Simon Barber asks for examples to be added to the call flow draft to illustrate registers being forwarded to both by multicast and forwarded to the home address (domain portion of the From tag.) that he asserts is specified in rfc2543bis-01. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 07:14:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05808 for ; Thu, 7 Dec 2000 07:14:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C398944349; Thu, 7 Dec 2000 06:14:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailserver2.sylantro.com (smtp2.sylantro.com [38.185.174.4]) by lists.bell-labs.com (Postfix) with SMTP id 484C64433F for ; Thu, 7 Dec 2000 06:13:56 -0500 (EST) Received: from 172.16.128.12 by mailserver2.sylantro.com with ESMTP ( WorldSecure Server SMTP Relay(WSS) v4.3); Thu, 07 Dec 00 04:11:16 -0800 X-Server-Uuid: 59490da2-986c-11d3-91ca-00104b9c3900 Received: by mailserver.sylantro.com with Internet Mail Service ( 5.5.2650.21) id ; Thu, 7 Dec 2000 04:13:37 -0800 Message-ID: <79FEAA5FABA7D411BF580001023D1BBD11605F@mailserver.sylantro.com> From: "Venkatesh Venkataramanan" To: "'Rohan Mahy '" , "'Jonathan Rosenberg '" , "'Billy Biggs '" , "'Alan Johnston '" Cc: "'Robert Sparks '" , "'Jonathan Rosenberg '" , "'SIP List '" Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) X-WSS-ID: 1631A1EE1821-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 04:13:28 -0800 Content-Transfer-Encoding: 7bit -----Original Message----- From: Rohan Mahy To: Jonathan Rosenberg; Billy Biggs; Alan Johnston Cc: Robert Sparks; Jonathan Rosenberg; SIP List Sent: 12/6/00 1:45 PM Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00 At 10:11 AM 12/5/00 , Jonathan Rosenberg wrote: >Billy raises some very important issues. These are some of the things that >motivated a thread on the list many months back (on the road now and can't >dig up the reference), where we discussed adding control functionality to >SIP, and how this was insufficient for a full blown control and monitoring >protocol like megaco. We need to keep the distinction between MEGACO-style control, and what we need. 1) SIP uses requests, which the UAS can decline. 2) SIP abstracts away the user interface of the UA away from the verbs/methods used to do useful things. We need to request that call legs move around to include certain users. we *don't* need to be notified when someone presses "hookflash"; and we *don't* need to tell the UA exactly how to write something on a display (that may not even exist). This following thought occurred to me reading the comment made above ("display may not even exist")..... Does this mean to say that one cannot support simple features like call transfer, or even providing music on hold just because I happen to have a phone that does not support a display? As I understand, a REFER has to be approved of by the end user, and in the absence of a display, I can't think of other mechanisms to use to obtain such approval(unless some auto-approval mechanisms are already present which I must admit I am not aware of)... Just a thought... any clarifications to provide some inputs here would be greatly helpful. >As Billy rightly observes, sending a refer for a sip URL with a BYE method >makes a lot of assumptions about how its processed in the recipient. It is >assuming that the UA matches the BYE with an existing call leg, it assumes >tags are handled, yes, the examples make a lot of assumpions. i don't think it is really such a big deal to codify this kind of behavior in some IETF document. then we can stop making assumptions about the semantics, and then we can make a lot of cool things work. the problem that i think is more significant is the retransmission problem that motivated Billy's REFERDONE method. >it assumes the UA is willing to accept REFERs with BYE, actually the UAC just _requests_ a REFER w/ BYE; the UAS is free to decline that request. >The simple fact is, SIP is a poor control protocol. If people want a real >protocol that can adequately remote control a phone, thats a totally >separate thing, with different primitives and communication requirements and >security implications. I believe SIP is entirely inadequate for such a job. I disagree. whatever this set of "control request" primitives is, it needs to follow the same path as the SIP signalling, and it needs to interact with the SIP security and policy rules, etc. etc. It seems logical that these primitives are indeed SIP messages. PHONECTL (while a reasonable stab at its problem set) currently assumes shared secrets between the controller and the phone (won't work for a Guest phone in my lobby), will need separate firewall treatment, and can't easily particpate in the mobile roaming aspects of SIP which are so nice. I believe that REFER with some additional semantic definition, is adequate for this job. >REFER was a sort-of-compromise; it introduced a little bit of control into >SIP. It was enough to do a bunch of simple things (call transfer >specifically), and as such its a nice primitive for building services. But, >I believe it is inadequate for a complete control protocol. Thus, I share >Billy's concerns about using it to hang up existing calls, among other >things. We've been pussy-footing around the nut of the call control problem for over a year now. If we ever want to get better-than-PSTN call-control services in a SIP environment, we need to define powerful, generic primitives now. >We should probably add text to REFER that is explicit about the requirements >(and non-requirements) for processing REFER at the recipient. > >Flame away. likewise ;-) thanks, -rohan >-Jonathan R. > >--- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 08:08:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14323 for ; Thu, 7 Dec 2000 08:08:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2BE2F44346; Thu, 7 Dec 2000 07:08:16 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id 9C9F94433F for ; Thu, 7 Dec 2000 04:31:53 -0500 (EST) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id QAA29797 for ; Thu, 7 Dec 2000 16:11:00 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA117; Thu, 7 Dec 2000 15:52:06 +0530 Message-ID: <04c901c06039$89bc5f40$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: "Billy Biggs" , "Alan Johnston" Cc: "Robert Sparks" , "SIP List" References: <20001129110944.B28481@div8.net> Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 16:06:19 +0530 Content-Transfer-Encoding: 7bit I request a small clarification in this regard. Seems to me that this call flow assumes that the far end UA being put on Hold necessarily has atleast two call appearance buttons if this call flow has to succeed. Is this understanding of mine correct? If so, using Refer to place calls on hold wouldn't work for single line telephones that spoke SIP. ----- Original Message ----- From: "Billy Biggs" To: "Alan Johnston" Cc: "Robert Sparks" ; "SIP List" Sent: Wednesday, November 29, 2000 10:39 PM Subject: [SIP] Music on Hold in ietf-sip-service-examples-00 > In sip-service-examples-00, you discuss performing music on hold using > REFER. A shortened call flow is below: > > On hold: > > User A User B Music Server > | | | > | REFER Refer-To: sip:music@server.com > |<-------------| | > | INVITE/200 OK/ACK | > |<--------------------------->| > | 200 OK | | > |------------->| | > | | | > > Off hold: > > | | | > | REFER Refer-To: music@server.com;method=BYE > |<-------------| | > | BYE/200 OK | | > |<--------------------------->| > | 200 OK | | > |------------->| | > | | | > > I have two problems with this method: > > 1. In our implementation, User A will hang up the call to User B after > the REFER completes successfully. This is to protect ourselves > (User B will also send a BYE), however, I can imagine most > implementations will be similar. > > 2. As mentioned in my previous email on remote device control using > REFER, the URI music@server.com;method=BYE is insufficient to > indicate to the UA which call should be disconnected. It's also > overloading REFER and obfuscating its meaning. > > There are more appropriate ways to implement music on hold. One is to > have User B call up the music server itself and swap the SDP (3pcc). > Another is to have User A call up the music on hold server when it > receives on-hold SDP. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 08:09:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA14500 for ; Thu, 7 Dec 2000 08:09:39 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A80444365; Thu, 7 Dec 2000 07:08:41 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange.satyam.net.in (unknown [202.144.12.32]) by lists.bell-labs.com (Postfix) with ESMTP id 5177244339 for ; Thu, 7 Dec 2000 04:51:26 -0500 (EST) Received: from hqbng01ex01.mindtree.com ([202.144.95.250]) by exchange.satyam.net.in (8.9.3/8.9.3) with ESMTP id QAA06403 for ; Thu, 7 Dec 2000 16:19:56 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.4417.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Message-ID: Thread-Topic: Sip thru TCP Thread-Index: AcBgOvXanJQvxPEoQ3aM9jHUJPxOmA== From: "Mayank Sharma" To: Subject: [SIP] Sip thru TCP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 16:16:31 +0530 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA14500 hi please excuse me if this question seems naive. When you (proxy server) are sending request's downstream through TCP, you keep the connection alive untill the transaction is completed. You keep listening on that connection all the while. So do we have to spawn a dedicated thread to listen to that connection ? in this case then the number of threads spawned will be enormous. Or we can go on polling each connection but still the overhead persists. Anyway out? Mayank _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 09:46:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27142 for ; Thu, 7 Dec 2000 09:46:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF06344338; Thu, 7 Dec 2000 08:46:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtp1.gtsgroup.com (smtp1.gtsgroup.com [195.158.230.16]) by lists.bell-labs.com (Postfix) with SMTP id 899B944336 for ; Thu, 7 Dec 2000 08:41:35 -0500 (EST) Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 15:41:12 +0100 Message-ID: From: "Agboh, Charles" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] third-party registration Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 15:41:12 +0100 Hi, What are the possible applications of third-party registration as defined in SIP? Regards, charles ------------8-)----------- Charles Agboh GTS Network services IP Engineering RFC822: charles.agboh@gts.com Tel: +32 (0) 2 658 4243 mobile: +32 495 58 52 67 Fax: +32(0) 2 658 5118 http://www.gtsgroup.com Quan Yin Method _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 10:53:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06500 for ; Thu, 7 Dec 2000 10:53:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 69B4D44338; Thu, 7 Dec 2000 09:53:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 2E4C044336 for ; Thu, 7 Dec 2000 09:52:43 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id VAA13884 for ; Thu, 7 Dec 2000 21:58:02 -0600 Message-ID: <008501c06065$6543a7f0$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] List of SIP Drafts Posted on Web Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 09:41:44 -0600 Content-Transfer-Encoding: 7bit In attempt to get our organization in-order, Brian Rosen has assembled a list of SIP drqfts and categorized them according to whether they appear to be part of a chartered effort. I'd like feedback on: 1) Completeness 2) Level of interest in the work associated with each draft The list-in-progress can be retrieved from: http://www.softarmor.com/sipwg/meets/IETF49/sipdrafts.html -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 10:55:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06769 for ; Thu, 7 Dec 2000 10:55:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F22974439C; Thu, 7 Dec 2000 09:53:29 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id C244944336 for ; Thu, 7 Dec 2000 09:52:44 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA26366; Thu, 7 Dec 2000 10:52:35 -0500 (EST) Message-ID: <3A2FB243.81D9DCA6@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Agboh, Charles" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] third-party registration References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 07 Dec 2000 10:52:35 -0500 Content-Transfer-Encoding: 7bit "Agboh, Charles" wrote: > > Hi, > > What are the possible applications of third-party registration as defined in > SIP? > Two have been mentioned: - secretary mode, where the secretary registers the current location (e.g., tel:) for his boss; - voicemail, where the voicemail system registers itself as a branch location (that's one mode we've used). -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 12:16:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA24860 for ; Thu, 7 Dec 2000 12:16:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE77A44338; Thu, 7 Dec 2000 11:16:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 94D9A44336 for ; Thu, 7 Dec 2000 11:15:06 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA08784; Thu, 7 Dec 2000 09:15:03 -0800 (PST) Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126]) by imop.cisco.com (Mirapoint) with SMTP id AAC49643; Thu, 7 Dec 2000 09:14:37 -0800 (PST) Message-Id: <4.1.20001207090123.02099300@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: "Venkatesh Venkataramanan" , "Billy Biggs" , "Alan Johnston" From: Rohan Mahy Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 Cc: "Robert Sparks" , "SIP List" In-Reply-To: <04c901c06039$89bc5f40$0c47a8c0@wipro.com> References: <20001129110944.B28481@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 07 Dec 2000 09:07:38 -0800 what's a line in SIP? ;-) seriously, you don't need *any* line buttons. You need to be able to associate zero or one active media flows and zero to inactive media flows with the same media terminating resource (speaker and microphone for audio). optionally a SIP UA that can support media selection and mixing should be able to support active media flows if they all use compatible media and codecs. thanks, -rohan At 02:36 AM 12/7/00 , Venkatesh Venkataramanan wrote: >I request a small clarification in this regard. Seems to me that this call >flow assumes that the far end UA being put on Hold necessarily has atleast >two call appearance buttons if this call flow has to succeed. Is this >understanding of mine correct? If so, using Refer to place calls on hold >wouldn't work for single line telephones that spoke SIP. >----- Original Message ----- >From: "Billy Biggs" >To: "Alan Johnston" >Cc: "Robert Sparks" ; "SIP List" > >Sent: Wednesday, November 29, 2000 10:39 PM >Subject: [SIP] Music on Hold in ietf-sip-service-examples-00 > > >> In sip-service-examples-00, you discuss performing music on hold using >> REFER. A shortened call flow is below: >> >> On hold: >> >> User A User B Music Server >> | | | >> | REFER Refer-To: sip:music@server.com >> |<-------------| | >> | INVITE/200 OK/ACK | >> |<--------------------------->| >> | 200 OK | | >> |------------->| | >> | | | >> >> Off hold: >> >> | | | >> | REFER Refer-To: music@server.com;method=BYE >> |<-------------| | >> | BYE/200 OK | | >> |<--------------------------->| >> | 200 OK | | >> |------------->| | >> | | | >> >> I have two problems with this method: >> >> 1. In our implementation, User A will hang up the call to User B after >> the REFER completes successfully. This is to protect ourselves >> (User B will also send a BYE), however, I can imagine most >> implementations will be similar. >> >> 2. As mentioned in my previous email on remote device control using >> REFER, the URI music@server.com;method=BYE is insufficient to >> indicate to the UA which call should be disconnected. It's also >> overloading REFER and obfuscating its meaning. >> >> There are more appropriate ways to implement music on hold. One is to >> have User B call up the music server itself and swap the SDP (3pcc). >> Another is to have User A call up the music on hold server when it >> receives on-hold SDP. >> >> -- >> Billy Biggs, 3Com Email: Billy_Biggs@3com.com >> http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip >> >> > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 12:17:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25322 for ; Thu, 7 Dec 2000 12:17:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 004C244360; Thu, 7 Dec 2000 11:16:32 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id C194C44336 for ; Thu, 7 Dec 2000 11:15:07 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id JAA11702; Thu, 7 Dec 2000 09:14:58 -0800 (PST) Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126]) by imop.cisco.com (Mirapoint) with SMTP id AAC49642; Thu, 7 Dec 2000 09:14:35 -0800 (PST) Message-Id: <4.1.20001207085831.02019b70@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: "Venkatesh Venkataramanan" , "'Jonathan Rosenberg '" , "'Billy Biggs '" , "'Alan Johnston '" From: Rohan Mahy Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00 Cc: "'Robert Sparks '" , "'Jonathan Rosenberg '" , "'SIP List '" In-Reply-To: <79FEAA5FABA7D411BF580001023D1BBD11605F@mailserver.sylantro .com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 07 Dec 2000 09:00:48 -0800 At 04:13 AM 12/7/00 , Venkatesh Venkataramanan wrote: > > >At 10:11 AM 12/5/00 , Jonathan Rosenberg wrote: >>Billy raises some very important issues. These are some of the things >that >>motivated a thread on the list many months back (on the road now and >can't >>dig up the reference), where we discussed adding control functionality >to >>SIP, and how this was insufficient for a full blown control and >monitoring >>protocol like megaco. > >We need to keep the distinction between MEGACO-style control, and what >we >need. >1) SIP uses requests, which the UAS can decline. >2) SIP abstracts away the user interface of the UA away from the >verbs/methods used to do useful things. > >We need to request that call legs move around to include certain users. >we >*don't* need to be notified when someone presses "hookflash"; and we >*don't* need to tell the UA exactly how to write something on a display >(that may not even exist). > VV said: >This following thought occurred to me reading the comment made above >("display may not even exist")..... >Does this mean to say that one cannot support simple features like call >transfer, or even providing music on hold just because I happen to have a >phone that does not support a display? As I understand, a REFER has to be >approved of by the end user, and in the absence of a display, I can't think >of other mechanisms to use to obtain such approval(unless some auto-approval >mechanisms are already present which I must admit I am not aware of)... Just >a thought... any clarifications to provide some inputs here would be greatly >helpful. A SIP UA could use an auto-approval or pre-approval technique, or could play a wav file requesting authorization, or, or... SIP allows for this type of abstraction. MEGACO does not. that's all. thanks, -rohan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 12:29:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA28189 for ; Thu, 7 Dec 2000 12:29:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 917EF44399; Thu, 7 Dec 2000 11:29:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 3B48C44392 for ; Thu, 7 Dec 2000 11:28:18 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id XAA14161 for ; Thu, 7 Dec 2000 23:33:47 -0600 Message-ID: <00fb01c06072$c5896cf0$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Come on, people! You can DO this! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 11:25:50 -0600 Content-Transfer-Encoding: 7bit So far, only four people have volunteered to summarize a week's worth of threads on our list. And two of them work for dynamicsoft. The list of dates is posted at: http://www.softarmor.com/sipwg/meets/IETF49/listissues.htm and I will post summaries there as they are received. How about some help? The mailing list archive is available to all at: http://lists.bell-labs.com/pipermail/sip/ Thanks -- Dean Willis _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 13:29:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA07576 for ; Thu, 7 Dec 2000 13:29:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 61F4544373; Thu, 7 Dec 2000 12:29:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04e.ca.nortel.com (h56s242a129n47.user.nortelnetworks.com [47.129.242.56]) by lists.bell-labs.com (Postfix) with ESMTP id D9C1C44336 for ; Thu, 7 Dec 2000 12:28:15 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04e.ca.nortel.com; Thu, 7 Dec 2000 13:27:26 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 7 Dec 2000 13:27:27 -0500 Message-ID: <28560036253BD41191A10000F8BCBD1103129654@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Dean Willis , "IETF SIP (E-mail)" Subject: RE: [SIP] Come on, people! You can DO this! MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0607B.57D47840" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 13:27:23 -0500 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_01C0607B.57D47840 Content-Type: text/plain; charset="iso-8859-1" OK, I'll pick up the rest of September (10th onwards). > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, December 07, 2000 12:26 PM > To: IETF SIP (E-mail) > Subject: [SIP] Come on, people! You can DO this! > > > So far, only four people have volunteered to summarize a > week's worth of > threads on our list. And two of them work for dynamicsoft. > > The list of dates is posted at: > > http://www.softarmor.com/sipwg/meets/IETF49/listissues.htm > > and I will post summaries there as they are received. > > How about some help? > > The mailing list archive is available to all at: > http://lists.bell-labs.com/pipermail/sip/ > > Thanks > > -- > Dean Willis > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > ------_=_NextPart_001_01C0607B.57D47840 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Come on, people! You can DO this!

OK, I'll pick up the rest of September (10th = onwards).

> -----Original Message-----
> From: Dean Willis [mailto:dean.willis@softarmor.c= om]
> Sent: Thursday, December 07, 2000 12:26 = PM
> To: IETF SIP (E-mail)
> Subject: [SIP] Come on, people! You can DO = this!
>
>
> So far, only four people have volunteered to = summarize a
> week's worth of
> threads on our list. And two of them work for = dynamicsoft.
>
> The list of dates is posted at:
>
> http://www.softarmor.com/sipwg/meets/IETF49/listissues= .htm
>
> and I will post summaries there as they are = received.
>
> How about some help?
>
> The mailing list archive is available to all = at:
> http://lists.bell-labs.com/pipermail/sip/
>
> Thanks
>
> --
> Dean Willis
>
>
>
> = _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

------_=_NextPart_001_01C0607B.57D47840-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 14:24:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18708 for ; Thu, 7 Dec 2000 14:24:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8C63644371; Thu, 7 Dec 2000 13:24:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id C0DDA44336 for ; Thu, 7 Dec 2000 13:23:12 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id BAA14457; Fri, 8 Dec 2000 01:28:21 -0600 Message-ID: <012301c06082$c6ce2eb0$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "Tom-PT Taylor" , "IETF SIP (E-mail)" References: <28560036253BD41191A10000F8BCBD1103129654@zcard00g.ca.nortel.com> Subject: Re: [SIP] Come on, people! You can DO this! MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0111_01C06050.380892B0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 13:18:41 -0600 This is a multi-part message in MIME format. ------=_NextPart_000_0111_01C06050.380892B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Come on, people! You can DO this!Tom is indeed a hero -- = again. -- Dean ----- Original Message -----=20 From: Tom-PT Taylor=20 To: Dean Willis ; IETF SIP (E-mail)=20 Sent: Thursday, December 07, 2000 12:27 PM Subject: RE: [SIP] Come on, people! You can DO this! OK, I'll pick up the rest of September (10th onwards).=20 > -----Original Message-----=20 > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Thursday, December 07, 2000 12:26 PM=20 > To: IETF SIP (E-mail)=20 > Subject: [SIP] Come on, people! You can DO this!=20 >=20 >=20 > So far, only four people have volunteered to summarize a=20 > week's worth of=20 > threads on our list. And two of them work for dynamicsoft.=20 >=20 > The list of dates is posted at:=20 >=20 > http://www.softarmor.com/sipwg/meets/IETF49/listissues.htm=20 >=20 > and I will post summaries there as they are received.=20 >=20 > How about some help?=20 >=20 > The mailing list archive is available to all at:=20 > http://lists.bell-labs.com/pipermail/sip/=20 >=20 > Thanks=20 >=20 > --=20 > Dean Willis=20 >=20 >=20 >=20 > _______________________________________________=20 > SIP mailing list=20 > SIP@lists.bell-labs.com=20 > http://lists.bell-labs.com/mailman/listinfo/sip=20 >=20 ------=_NextPart_000_0111_01C06050.380892B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Come on, people! You can DO this!
Tom is indeed a hero -- = again.
 
--
Dean
----- Original Message -----
From:=20 Tom-PT Taylor
To: Dean Willis ; IETF SIP=20 (E-mail)
Sent: Thursday, December 07, = 2000 12:27=20 PM
Subject: RE: [SIP] Come on, = people! You=20 can DO this!

OK, I'll pick up the rest of September (10th = onwards).=20

> -----Original Message-----
>=20 From: Dean Willis [mailto:dean.willis@softarmor.co= m]=20
> Sent: Thursday, December 07, 2000 12:26 = PM=20
> To: IETF SIP (E-mail)
>=20 Subject: [SIP] Come on, people! You can DO this!
>=20
>
> So far, = only four=20 people have volunteered to summarize a
> = week's=20 worth of
> threads on our list. And two = of them=20 work for dynamicsoft.
>
> The list of dates is posted at:
>=20
> http:= //www.softarmor.com/sipwg/meets/IETF49/listissues.htm=20
>
> and I will post = summaries=20 there as they are received.
> =
> How about some help?
> =
> The mailing list archive is available to all at: =
> http://lists.bell-labs= .com/pipermail/sip/=20
>
> Thanks =
>
> --
> Dean=20 Willis
>
>=20
>
>=20 _______________________________________________
>=20 SIP mailing list
> = SIP@lists.bell-labs.com=20
> http://lists.bel= l-labs.com/mailman/listinfo/sip=20
>

------=_NextPart_000_0111_01C06050.380892B0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 15:07:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA25995 for ; Thu, 7 Dec 2000 15:07:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 755A144349; Thu, 7 Dec 2000 14:07:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id B8C8B44336 for ; Thu, 7 Dec 2000 14:06:46 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id CAA14633; Fri, 8 Dec 2000 02:11:55 -0600 Message-ID: <018501c06088$dcc85870$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "Culpepper, Bert" Cc: "IETF SIP (E-mail)" References: Subject: Re: [SIP] Come on, people! You can DO this! 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 14:04:02 -0600 Content-Transfer-Encoding: 7bit Thanks, Bert! And there's plenty of open weeks for the rest of you people who can make a contribution . . . -- Dean ----- Original Message ----- From: "Culpepper, Bert" To: "Dean Willis" Sent: Thursday, December 07, 2000 1:47 PM Subject: RE: [SIP] Come on, people! You can DO this! > I'll give the week of Aug 12-19th a shot. > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, December 07, 2000 12:26 PM > To: IETF SIP (E-mail) > Subject: [SIP] Come on, people! You can DO this! > > > So far, only four people have volunteered to summarize a week's worth > of > threads on our list. And two of them work for dynamicsoft. > > The list of dates is posted at: > > http://www.softarmor.com/sipwg/meets/IETF49/listissues.htm > > and I will post summaries there as they are received. > > How about some help? > > The mailing list archive is available to all at: > http://lists.bell-labs.com/pipermail/sip/ > > Thanks > > -- > Dean Willis > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 15:09:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA26346 for ; Thu, 7 Dec 2000 15:09:24 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 064C64436C; Thu, 7 Dec 2000 14:07:30 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id DDD9A44336 for ; Thu, 7 Dec 2000 14:06:49 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA12220; Thu, 7 Dec 2000 15:09:04 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 15:04:24 -0500 Message-ID: From: Igor Slepchin To: "'Mayank Sharma'" , sip@lists.bell-labs.com Subject: RE: [SIP] Sip thru TCP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 15:04:24 -0500 See http://www.cs.columbia.edu/~hgs/sip/faq/cache/93.html To answer your question more directly: that's up to you. I'd suggest that you refer to some network programming book (Stevens' ones are an obvious choice) before making a decision. --- Igor Slepchin > -----Original Message----- > From: Mayank Sharma [mailto:mayanks@mindtree.com] > Sent: Thursday, December 07, 2000 5:47 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Sip thru TCP > > > hi > please excuse me if this question seems naive. > When you (proxy server) are sending request's downstream through > TCP, you keep the connection alive untill the transaction is > completed. > You keep listening on that connection all the while. So do we have to > spawn a dedicated thread to listen to that connection ? in this case > then the number of threads spawned will be enormous. Or we can go on > polling each connection but still the overhead persists. > Anyway out? Use select() (if you are coding in C, that is). _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 16:13:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA06820 for ; Thu, 7 Dec 2000 16:13:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C31E744339; Thu, 7 Dec 2000 15:13:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from austinit00.austin.polycom.com (austinit00.austin.polycom.com [216.54.148.225]) by lists.bell-labs.com (Postfix) with ESMTP id D750544336 for ; Thu, 7 Dec 2000 13:21:44 -0500 (EST) Received: by austinit00.austin.polycom.com with Internet Mail Service (5.5.2653.19) id ; Thu, 7 Dec 2000 13:00:44 -0600 Message-ID: <38C2271BB6BDD411902B00A024D3D2ED2C095E@austinit00.austin.polycom.com> From: "Narayanan, Balaji" To: "'Dean Willis'" , "IETF SIP (E-mail)" Subject: RE: [SIP] Come on, people! You can DO this! MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 13:00:41 -0600 I will do Nov 26 - Dec 2 Balaji -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, December 07, 2000 11:26 AM To: IETF SIP (E-mail) Subject: [SIP] Come on, people! You can DO this! So far, only four people have volunteered to summarize a week's worth of threads on our list. And two of them work for dynamicsoft. The list of dates is posted at: http://www.softarmor.com/sipwg/meets/IETF49/listissues.htm and I will post summaries there as they are received. How about some help? The mailing list archive is available to all at: http://lists.bell-labs.com/pipermail/sip/ Thanks -- Dean Willis _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 16:31:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA10782 for ; Thu, 7 Dec 2000 16:31:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 919ED44361; Thu, 7 Dec 2000 15:31:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3C04144354 for ; Thu, 7 Dec 2000 15:30:10 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA13159; Thu, 7 Dec 2000 16:32:31 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 7 Dec 2000 16:27:52 -0500 Message-ID: From: Igor Slepchin To: "'Dean Willis'" , "IETF SIP (E-mail)" Subject: RE: [SIP] Come on, people! You can DO this! MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 16:27:51 -0500 I'll take Oct 1 - 7. --- Igor Slepchin > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, December 07, 2000 12:26 PM > To: IETF SIP (E-mail) > Subject: [SIP] Come on, people! You can DO this! > > > So far, only four people have volunteered to summarize a > week's worth of > threads on our list. And two of them work for dynamicsoft. > > The list of dates is posted at: > > http://www.softarmor.com/sipwg/meets/IETF49/listissues.htm > > and I will post summaries there as they are received. > > How about some help? > > The mailing list archive is available to all at: > http://lists.bell-labs.com/pipermail/sip/ > > Thanks > > -- > Dean Willis > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 20:12:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20014 for ; Thu, 7 Dec 2000 20:12:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6304B44338; Thu, 7 Dec 2000 19:12:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 3B59A44336 for ; Thu, 7 Dec 2000 19:11:05 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Thu, 7 Dec 2000 20:10:43 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 7 Dec 2000 20:10:45 -0500 Message-ID: <28560036253BD41191A10000F8BCBD1103129C54@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: "IETF SIP (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C060B3.B07D5470" X-Orig: Subject: [SIP] SIP List Thread Summary, 10-16 September Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 7 Dec 2000 20:10:44 -0500 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_01C060B3.B07D5470 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Phew! One week down, two to go! 9/11/2000 Thread: Keep-Alive mechanism : REGISTER. Jacqueline = Blanchard asked how a UA can indicate to its proxy that it is still alive. = Jonathan agreed with her that Sending a periodic REGISTER is the appropriate mechanism. No action. 9/11/2000 Thread: How to compare hosts for equality? M. Raganathan = noted that in some headers either a host name or a host address can be = presented. Where the name is used, DNS lookup can give multiple addresses, making = it hard for a server to determine a match. He wondered if it was up to = the client to be consistent in its use of name or address to make it easier = for the server. Gethin Liddell pointed him to section 2.1 on SIP URL comparison. No action. 9/11/2000 Thread: A doubt on registeration ? Pathangi Janardhanan = noted that the bis draft says that if registration information changes during = the course of processing of an invitation, the new information should be = used. He wondered how a proxy receives the new information. Jo Hornsby = confirmed that it would be through an implementation-dependent interface, and = noted that the interface to the Location Server is not well defined in any = event. No action. 9/11/2000 Thread: Content Length Question. Bobby Sardana wanted to = know the reference for the grammar of Content-Length, and particularly what the = three dots imply (i.e. "Content-Length: ..."). Peter Kjellerstedt surmised Bobby's syntax was taken from an example in 2543bis, and the dots stand = for normal content (i.e. the correct character count for the body) which = would be placed here in practice. Gethin Liddell confirmed this view. No = action. 9/12/2000 Thread: SIP syntax in 2543-bis-01. G=E9rard GONNET noted = that new ABNF for in 2543bis allows a production like , which ddin't seem right. He proposed adjustments to the ABNF to ensure that if password = is present, it is preceded by or . Jonathan concurred that the existing grammar seemed wrong, and Henning announced = a fix by moving the optionality bracket to make it like similar URLs in = RFC 1738. The fix does NOT appear in 2543bis-02. ACTION: Henning. 9/12/2000 Thread: DNS SRV records in stateless mode. =20 - Igor Slepchin suggested that the use of DNS SRV records in stateless = mode has some potential problems. The standard algorithm in section 1.4.2 = and RFC 2782 could cause retransmissions to go to different places -- an = awkward but not fatal possibility. He suggested a "first-success" algorithm, = where hosts are slected in decreasing order of priority until one succeeds. = He noted that a UDP record will always terminate the search, since ICMP = errors cannot be detected in stateless mode. Another possibility is to use = only A records in stateless mode, but this also has problems. =20 - James Undery suggested that the real issue is not transport, but = choosing amongst hosts of equal priority. Doing this randomly causes misrouting = at the SIP level, while doing it deterministically breaks the intent of = SRV. He feels the RFC should be less positive in general about how the proxy = does routing, since the proxy may have better information to act upon. =20 - Gethin Liddell pointed out that a stateless proxy can only use UDP, = and that sending retransmissions to different hosts could have nasty = effects like double-billing of the subscriber. He proposed a procedure where = the proxy begins with SRV, moves on to an A record, then does nothing, = noting that there was recent discussion on returning final responses in = stateless mode.=20 - Igor Slepchin noted in response to James Undery that the proxy is = free to choose its own routing methods, but if it chooses SRV it is reasonable = to say that it SHOULD use the recommended algorithm. He also suggested a compromise whereby the selection between equal-priority servers be deterministic for a given proxy, but random across different proxies, = so as to preserve some of the load-balancing effects of the SRV record.=20 - Henning reaffirmed that random selection amongst the highest-priority servers should be used, and this was particularly important to provide failover handling. It is possible in some implementations to detect = UDP failures and/or to ensure that retransmissions go to the same host as = the original message. Additionally, the receiving domain has to accept the consequences of listing multiple hosts at the same priority. He felt = that Igor's suggested compromise was unworkable. - Jonathan stated that strict randomization makes load balancing = through use of multiple SRV records too expensive. The implication is forced = back-end state sharing even in normal operation, not just for failover. He = thought it reasonable to define the SRV contract as applicable to an entire transaction, and proposed that the random selector be based on a hash = of those elements making up the transaction identifier. - Henning wasn't sure the consequences of pure randomization were as rigorous as Jonathan implied. He suggested if the compromise approach = is taken, a random selector based on a hash of the Call-Id would be = suitable. However, he was concerned that downstream proxies relying on proper = upstream behaviour might be vulnerable in the event of misbehaviour. - Jonathan said his concern wasn't billing, but the extra messaging and confusion that would result from retransmissions taking different = routes. He suggested that his transaction identifer hash would come closer than = a Call-Id hash to achieving the load balancing intended by SRV, achieves = the desired effect of preventing unintended forks, and is therefore = preferable. - Henning announced new text on SRV usage added to section 1.4.2. This = text allows route selection at either at the call or the transaction level. Jonathan agreed with it, with a minor adjustment. This text now = appears in 2543bis-02. - Brian Stucker expressed concerns that the hash used by some implementations could provide inadequate randomization. Moreover, if = the proxy detects failure and rechooses the downstream server, but the originator also reoriginates the message, the stateless proxy may = blindly apply the selection algorithm and thus offer the reoriginated message = to the failed server again. He suggested implementation notes to alleviate = these two concerns. - Howard Hart worried that Brian's second procedural fix would mess up = load balancing. Brian couldn't see that, and suggested that his fix was consistent with the procedure given in RFC 2782. No further action. 9/12/2000 Thread: Handle'n of NOT A KNOWN SIP Header Messages. Krishan = Veer wanted confirmation of how a proxy should handle messages containing = unknown header types but otherwise valid grammar. He understood that they = should be forwarded, but wondered whether there were any restrictions to that = rule. Kevin Summers clarified the question, then cited the relevant text in section 6 of 2534bis. 9/13/2000 Thread: SIP meetings. Joshua Fox wanted to know where to = find out about upcoming meetings on SIP. Neal Deason gave a few home pages he = could check out for meeting announcements. No action. 9/13/2000 Thread: Sip Call Control Transfer. Amit Choksi had some = questions on the grammar of the URL in the Refer-To and Referred-By headers. No response was posted to the list. The cc-transfer-02 draft says that Referred-By must contain a SIP URL, but says nothing about the Refer-To header. ACTION: Robert Sparks. 9/14/2000 Thread: A warning to implementors. Jonathan Rosenberg = expressed his concern that implementors not impose arbitrary limits on the length = of specific SIP fields, saying that those who do so are non-compliant to = RFC 2543. Eric Burger suggested this was inconsistent with the need to = respect MTU size limits, and proposed a limit of 1000 characters in any one = header. He noted that the Response-Key: or Authorization: fields are potential problem areas. Jonathan said some messages are already exceeding MTU = size, and implementations should not reject them just because of that. He understood the value of fixed memory allocations for embedded = applications, but the problem remains how to specify a large enough header length. = Length problems actually come in fields like Via and Record-Route because = data gets stacked there. Henning backed up Jonathan and noted that = allocating large fixed-length areas leads to wasted space in normal operation and vulnerability to attacks. Arjun Roychowdhury agreed that storage = allocation should be dynamic, although it would be reasonable to pose limits on = total output message length. Cliff Harris noted a content-length example of = 3495 in 2543bis. Arjun clarified that the 4000 byte figure in his note was = just an example, and the actual limit is very implementation specific. No action. 9/14/2000 Thread: creation of the SIP WG. Tin DAO TRUNG asked when the = SIP WG was created. Jonathan gave a full answer. No action. 9/14/2000 Thread: Outbound call routing. - Simon Barber triggered a lengthy thread by asking whether a = registration server could respond to a registration request by forcing all future outbound requests to be routed through a specific proxy. He cited a = call logging application. - Jonathan said his proposal was not possible, and that similar requirements for mobile services had come up with the proposal to add a Route header to the request. This is a hack, not necessarily = interoperable, since the Route header in this case is not derived from a previous Record-Route. - Simon pointed out that his problem was user mobility, not client mobility, and the routing needed to be tied to the registration rather = than the call leg. Jonathan agreed with the requirement and stated it as = the need to be able to work through one's normal registrar/proxy while = moving about. This collides with the insistence of some domains that = messaging pass through their dedicated proxy server. - Subsequent discussion covered a lot of ground, but resolved itself = into two themes. The first had to do with the mechanism which might be used = to force requests through the home outbound proxy, no matter which domain = the user was visiting. The proposed solution was to include a Route header = in an initial request. Jonathan eventually viewed this as a consensus proposal. The header should appear on its own, not as a parameter = appended to the Request-URI -- otherwise it would be ignored by existing = proxies. The UAC inserts the home outbound server in the route just before the = final destination. Jo Hornsby noted a problem where signalling had to end up = at a UA on a specific port, but Jonathan suggested a solution taking account = of the fact that a new procedure was being defined in any event. - The other theme was how the client in the visited domain acquires = the user's preferences and the address of the home outbound proxy that it = is to insert into the Route header. Simon and Arnoud van Wijk appeared to = agree on a double registration procedure to retrieve the user preferences on = top of the local domain settings. At one point in the thread there was = talk of a new "sipoutbound" SRV record if the home outbound proxy would be the = same for all users in a domain. - Summing up, it appears that the basic question of mechanism has been resolved. ACTION: someone to formulate suitable text and Henning to = add it to 2543bis. There may be practical issues of client implementation to = allow roaming users to use the mechanism. =20 9/14/2000 Thread: SIP-related VON (and IPTS) presentations. Henning = asked people to send him URLs to such presentations so he could add them to = his web page. 9/14/2000 Thread: Via header and case sensitivity. Itamar Gilad = questioned the validity of one of the torture test cases. He also asked what = default behaviour for header comparison is, now that text on the subject has = been removed from 2543bis. Henning replied that Itamar's point was correct = and he had fixed the example. He cited new text on case sensitivity in = section 6.5 of 2543bis-02. Itamar observed that he had misunderstood the new = text because it used the word "parameter". No further action? 9/14/2000 Thread: INVITE with new SDP /higher CSeq. Eshwara Prasad = wanted to know how the UAC learns that a request it sent with higher CSeq and = new SDP was successful. Jonathan indicated that the new INVITE would = follow the normal request/response/ACK sequence, so the UAC would know from the = nature of the response. No action. 9/15/2000 Thread: Question on IMPP. Anuraj Ennai asked what would = happen to the proposed SIP extensions for IMPP, now that they may not be adopted = by the IMPP group. He saw a benefit to retaining the framework and = extensions in SIP. Christian Huitema noted that SIP is one of three proposals now before the IMPP WG, but that WG is currently preparing a common = reference document rather than selecting a specific protocol. A good way to = further the chances of SIP would be to embed SUBSCRIBE/NOTIFY in products and demonstrate interoperability. Bobby Sardana expressed strong support = for SIP, and mentioned that they had implemented a SIP-based stack for this function in just 6000 bytes. No action. 9/15/2000 Thread: SIP message transport on TCP. Aseem Agarwal asked = whether there was any application-level framing mechanism (cf RFC 1006) for SIP messages in a TCP stream. Henning said the framing is as given 2543 = and is almost the same as that used by HTTP servers. 9/16/2000 Thread: a question on 183. Pathangi N Janardhanan asked why = SDP is needed in the 183 Early Media response, given that the early media = will be one-way toward the caller and the caller's SDP has been passed in = the INVITE. Jonathan responded that the SDP in the 183 confirms what the = caller sent, provides an RTCP port for feedback, and indicates whether the = early media will be one-way. No action. Tom Taylor +1 613 736 0961 taylor@nortelnetworks.com=20 ------_=_NextPart_001_01C060B3.B07D5470 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP List Thread Summary, 10-16 September

Phew!  One week down, two to go!

9/11/2000 Thread: Keep-Alive mechanism : = REGISTER.  Jacqueline Blanchard asked how a UA can indicate to its = proxy that it is still alive.  Jonathan agreed with her that = Sending a periodic REGISTER is the appropriate mechanism.  No = action.

9/11/2000 Thread: How to compare hosts for = equality?  M. Raganathan noted that in some headers either a host = name or a host address can be presented.  Where the name is used, = DNS lookup can give multiple addresses, making it hard for a server to = determine a match.  He wondered if it was up to the client to be = consistent in its use of name or address to make it easier for the = server.  Gethin Liddell pointed him to section 2.1 on SIP URL = comparison.  No action.

9/11/2000 Thread: A doubt on registeration ?  = Pathangi Janardhanan noted that the bis draft says that if registration = information changes during the course of processing of an invitation, = the new information should be used.  He wondered how a proxy = receives the new information.  Jo Hornsby confirmed that it would = be through an implementation-dependent interface, and noted that the = interface to the Location Server is not well defined in any = event.  No action.

9/11/2000 Thread: Content Length Question.  = Bobby Sardana wanted to know the reference for the grammar of = Content-Length, and particularly what the three dots imply (i.e. = "Content-Length: ...").  Peter Kjellerstedt surmised = Bobby's syntax was taken from an example in 2543bis, and the dots stand = for normal content (i.e. the correct character count for the body) = which would be placed here in practice.  Gethin Liddell confirmed = this view.  No action.

9/12/2000 Thread: SIP syntax in 2543-bis-01.  = G=E9rard GONNET noted that new ABNF for <userinfo> in 2543bis = allows a production like <sip::a_password@hostport url-parameters = [headers]>, which ddin't seem right.  He proposed adjustments = to the ABNF to ensure that if password is present, it is preceded by = <user> or <telephone-subscriber>.  Jonathan concurred = that the existing grammar seemed wrong, and Henning announced a fix by = moving the optionality bracket to make it like similar URLs in RFC = 1738.  The fix does NOT appear in 2543bis-02.  ACTION: = Henning.

9/12/2000 Thread: DNS SRV records in stateless = mode. 
- Igor Slepchin suggested that the use of  DNS = SRV records in stateless mode has some potential problems.  The = standard algorithm in section 1.4.2 and RFC 2782 could cause = retransmissions to go to different places -- an awkward but not fatal = possibility.  He suggested a "first-success" algorithm, = where hosts are slected in decreasing order of priority until one = succeeds.  He noted that a UDP record will always terminate the = search, since ICMP errors cannot be detected in stateless mode.  = Another possibility is to use only A records in stateless mode, but = this also has problems. 

- James Undery suggested that the real issue is not = transport, but choosing amongst hosts of equal priority.  Doing = this randomly causes misrouting at the SIP level, while doing it = deterministically breaks the intent of SRV.  He feels the RFC = should be less positive in general about how the proxy does routing, = since the proxy may have better information to act upon.  =

- Gethin Liddell pointed out that a stateless proxy = can only use UDP, and that sending retransmissions to different hosts = could have nasty effects like double-billing of the subscriber.  = He proposed a procedure where the proxy begins with SRV, moves on to an = A record, then does nothing, noting that there was recent discussion on = returning final responses in stateless mode.

- Igor Slepchin noted in response to James Undery = that the proxy is free to choose its own routing methods, but if it = chooses SRV it is reasonable to say that it SHOULD use the recommended = algorithm.  He also suggested a compromise whereby the selection = between equal-priority servers be deterministic for a given proxy, but = random across different proxies, so as to preserve some of the = load-balancing effects of the SRV record.

- Henning reaffirmed that random selection amongst = the highest-priority servers should be used, and this was particularly = important to provide failover handling.  It is possible in some = implementations to detect UDP failures and/or to ensure that = retransmissions go to the same host as the original message.  = Additionally, the receiving domain has to accept the consequences of = listing multiple hosts at the same priority.  He felt that Igor's = suggested compromise was unworkable.

- Jonathan stated that strict randomization makes = load balancing through use of multiple SRV records too expensive.  = The implication is forced back-end state sharing even in normal = operation, not just for failover.  He thought it reasonable to = define the SRV contract as applicable to an entire transaction, and = proposed that the random selector be based on a hash of those elements = making up the transaction identifier.

- Henning wasn't sure the consequences of pure = randomization were as rigorous as Jonathan implied.  He suggested = if the compromise approach is taken, a random selector based on a hash = of the Call-Id would be suitable.  However, he was concerned that = downstream proxies relying on proper upstream behaviour might be = vulnerable in the event of misbehaviour.

- Jonathan said his concern wasn't billing, but the = extra messaging and confusion that would result from retransmissions = taking different routes.  He suggested that his transaction = identifer hash would come closer than a Call-Id hash to achieving the = load balancing intended by SRV, achieves the desired effect of = preventing unintended forks, and is therefore preferable.

- Henning announced new text on SRV usage added to = section 1.4.2.  This text allows route selection at either at the = call or the transaction level.  Jonathan agreed with it, with a = minor adjustment.  This text now appears in 2543bis-02.

- Brian Stucker expressed concerns that the hash used = by some implementations could provide inadequate randomization.  = Moreover, if the proxy detects failure and rechooses the downstream = server, but the originator also reoriginates the message, the stateless = proxy may blindly apply the selection algorithm and thus offer the = reoriginated message to the failed server again.  He suggested = implementation notes to alleviate these two concerns.

- Howard Hart worried that Brian's second procedural = fix would mess up load balancing.  Brian couldn't see that, and = suggested that his fix was consistent with the procedure given in RFC = 2782.

No further action.

9/12/2000 Thread: Handle'n of NOT A KNOWN SIP Header = Messages.  Krishan Veer wanted confirmation of how a proxy should = handle messages containing unknown header types but otherwise valid = grammar.  He understood that they should be forwarded, but = wondered whether there were any restrictions to that rule.  Kevin = Summers clarified the question, then cited the relevant text in section = 6 of 2534bis.

9/13/2000 Thread: SIP meetings.  Joshua Fox = wanted to know where to find out about upcoming meetings on SIP.  = Neal Deason gave a few home pages he could check out for meeting = announcements.  No action.

9/13/2000 Thread: Sip Call Control Transfer.  = Amit Choksi had some questions on the grammar of the URL in the = Refer-To and Referred-By headers.  No response was posted to the = list.  The cc-transfer-02 draft says that Referred-By must contain = a SIP URL, but says nothing about the Refer-To header.  ACTION: = Robert Sparks.

9/14/2000 Thread: A warning to implementors.  = Jonathan Rosenberg expressed his concern that implementors not impose = arbitrary limits on the length of specific SIP fields, saying that = those who do so are non-compliant to RFC 2543.  Eric Burger = suggested this was inconsistent with the need to respect MTU size = limits, and proposed a limit of 1000 characters in any one = header.  He noted that the Response-Key: or Authorization: fields = are potential problem areas.  Jonathan said some messages are = already exceeding MTU size, and implementations should not reject them = just because of that.  He understood the value of fixed memory = allocations for embedded applications, but the problem remains how to = specify a large enough header length.  Length problems actually = come in  fields like Via and Record-Route because data gets = stacked there.  Henning backed up Jonathan and noted that = allocating large fixed-length areas leads to wasted space in normal = operation and vulnerability to attacks.  Arjun Roychowdhury agreed = that storage allocation should be dynamic, although it would be = reasonable to pose limits on total output message length.  Cliff = Harris noted a content-length example of 3495 in 2543bis.  Arjun = clarified that the 4000 byte figure in his note was just an example, = and the actual limit is very implementation specific.  No = action.

9/14/2000 Thread: creation of the SIP WG.  Tin = DAO TRUNG asked when the SIP WG was created.  Jonathan gave a full = answer.  No action.

9/14/2000 Thread: Outbound call routing.
-  Simon Barber triggered a lengthy thread by = asking whether a registration server could respond to a registration = request by forcing all future outbound requests to be routed through a = specific proxy.  He cited a call logging application.

-  Jonathan said his proposal was not possible, = and that similar requirements for mobile services had come up with the = proposal to add a Route header to the request.  This is a hack, = not necessarily interoperable, since the Route header in this case is = not derived from a previous Record-Route.

-  Simon pointed out that his problem was user = mobility, not client mobility, and the routing needed to be tied to the = registration rather than the call leg.  Jonathan agreed with the = requirement and stated it as the need to be able to work through one's = normal registrar/proxy while moving about.  This collides with the = insistence of some domains that messaging pass through their dedicated = proxy server.

-  Subsequent discussion covered a lot of = ground, but resolved itself into two themes.  The first had to do = with the mechanism which might be used to force requests through the = home outbound proxy, no matter which domain the user was = visiting.  The proposed solution was to include a Route header in = an initial request.  Jonathan eventually viewed this as a = consensus proposal.  The header should appear on its own, not as a = parameter appended to the Request-URI -- otherwise it would be ignored = by existing proxies.  The UAC inserts the home outbound server in = the route just before the final destination. Jo Hornsby noted a problem = where signalling had to end up at a UA on a specific port, but Jonathan = suggested a solution taking account of the fact that a new procedure = was being defined in any event.

-  The other theme was how the client in the = visited domain acquires the user's preferences and the address of the = home outbound proxy that it is to insert into the Route header.  = Simon and Arnoud van Wijk appeared to agree on a double registration = procedure to retrieve the user preferences on top of the local domain = settings.  At one point in the thread there was talk of a new = "sipoutbound" SRV record if the home outbound proxy would be = the same for all users in a domain.

-  Summing up, it appears that the basic = question of mechanism has been resolved.  ACTION: someone to = formulate suitable text and Henning to add it to 2543bis.  There = may be practical issues of client implementation to allow roaming users = to use the mechanism.

 
9/14/2000 Thread: SIP-related VON (and IPTS) = presentations.  Henning asked people to send him URLs to such = presentations so he could add them to his web page.

9/14/2000 Thread: Via header and case = sensitivity.  Itamar Gilad questioned the validity of one of the = torture test cases.  He also asked what default behaviour for = header comparison is, now that text on the subject has been removed = from 2543bis.  Henning replied that Itamar's point was correct and = he had fixed the example.  He cited new text on case sensitivity = in section 6.5 of 2543bis-02.  Itamar observed that he had = misunderstood the new text because it used the word = "parameter".  No further action?

9/14/2000 Thread: INVITE with new SDP /higher = CSeq.  Eshwara Prasad wanted to know how the UAC learns that a = request it sent with higher CSeq and new SDP was successful.  = Jonathan indicated that the new INVITE would follow the normal = request/response/ACK sequence, so the UAC would know from the nature of = the response.  No action.

9/15/2000 Thread: Question on IMPP.  Anuraj = Ennai asked what would happen to the proposed SIP extensions for IMPP, = now that they may not be adopted by the IMPP group.  He saw a = benefit to retaining the framework and extensions in SIP.  = Christian Huitema noted that SIP is one of three proposals now before = the IMPP WG, but that WG is currently preparing a common reference = document rather than selecting a specific protocol.  A good way to = further the chances of SIP would be to embed SUBSCRIBE/NOTIFY in = products and demonstrate interoperability.  Bobby Sardana = expressed strong support for SIP, and mentioned that they had = implemented a SIP-based stack for this function in just 6000 = bytes.  No action.

9/15/2000 Thread: SIP message transport on TCP.  = Aseem Agarwal asked whether there was any application-level framing = mechanism (cf RFC 1006) for SIP messages in a TCP stream.  Henning = said the framing is as given 2543 and is almost the same as that used = by HTTP servers.

9/16/2000 Thread: a question on 183.  Pathangi N = Janardhanan asked why SDP is needed in the 183 Early Media response, = given that the early media will be one-way toward the caller and the = caller's SDP has been passed in the INVITE.  Jonathan responded = that the SDP in the 183 confirms what the caller sent, provides an RTCP = port for feedback, and indicates whether the early media will be = one-way.  No action.


Tom Taylor
+1 613 736 0961
taylor@nortelnetworks.com

------_=_NextPart_001_01C060B3.B07D5470-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 7 23:02:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01737 for ; Thu, 7 Dec 2000 23:02:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1533A44338; Thu, 7 Dec 2000 22:02:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id 50E9D44336 for ; Thu, 7 Dec 2000 22:01:44 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G5800G01DUMJ4@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 8 Dec 2000 04:01:35 +0000 (GMT) Received: from pmismtp03.wcomnet.com ([166.38.62.38]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G5800E6JDUM7U@firewall.mcit.com>; Fri, 08 Dec 2000 04:01:34 +0000 (GMT) Received: from CONVERSION-DAEMON by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) id <0G5800G01DUMEP@pmismtp03.wcomnet.com>; Fri, 08 Dec 2000 04:01:34 +0000 (GMT) Received: from pmismtp03.wcomnet.com by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G5800G01DULEN@pmismtp03.wcomnet.com>; Fri, 08 Dec 2000 04:01:33 +0000 (GMT) Received: from hsinnreich ([166.46.18.233]) by pmismtp03.wcomnet.com (PMDF V5.2-33 #42258) with SMTP id <0G58007H8DU4YI@pmismtp03.wcomnet.com>; Fri, 08 Dec 2000 04:01:18 +0000 (GMT) From: Henry Sinnreich Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00 In-reply-to: <4.1.20001206124522.00d01160@imop.cisco.com> To: Rohan Mahy , Jonathan Rosenberg , Billy Biggs , Alan Johnston Cc: Robert Sparks , Jonathan Rosenberg , SIP List Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 07 Dec 2000 22:01:59 -0600 Content-Transfer-Encoding: 7bit >full blown control and monitoring >protocol like megaco. Agree here completely with Rohan Mahy >*don't* need to be notified when someone presses "hook flash"; and we >*don't* need to tell the UA exactly how to write something on a display and propose we face the facts why device control protocols are a poor engineering option: Device control protocols can be found in proprietary IP PBX designs and also in various proposed standards, such as MEGACO and H.248. Device control protocols are master-slave protocols where every detail of the device operation is controlled from a central server. In this model, every event, such as a hook flash has to be reported to the central controller and every action of the device has to be controlled, such as how to display a number, or a message. How does the controller know if the device has a display at all? The answer is, it does not know, unless it has been pre-configured with a so-called "package" that is written for that particular device, such as for example for specific phone model that may or may not have a display with certain capabilities. In the case of Media Gateways, "packages" have to be written and provisioned depending on the particular circuit switch network signaling of the Media gateway, such as channel associated signaling (CAS), Q.931, SS7 in its various flavors, etc. This is in stark contrast to the Internet model, where the same protocol is used, without caring if at the other end is a palmtop computer or a powerful server farm in a data center. For example when using FTP, e-mail or browsers, no consideration has to be given how the remote IP device is configured. Where different capabilities, such as codecs for voice and video have to be coordinated for real time communications, a capability negotiation takes place. Device control protocols have no notion of capability negotiation. >Flame away. likewise ;-) Henry -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Rohan Mahy Sent: Wednesday, December 06, 2000 3:45 PM To: Jonathan Rosenberg; Billy Biggs; Alan Johnston Cc: Robert Sparks; Jonathan Rosenberg; SIP List Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00 At 10:11 AM 12/5/00 , Jonathan Rosenberg wrote: >Billy raises some very important issues. These are some of the things that >motivated a thread on the list many months back (on the road now and can't >dig up the reference), where we discussed adding control functionality to >SIP, and how this was insufficient for a full blown control and monitoring >protocol like megaco. We need to keep the distinction between MEGACO-style control, and what we need. 1) SIP uses requests, which the UAS can decline. 2) SIP abstracts away the user interface of the UA away from the verbs/methods used to do useful things. We need to request that call legs move around to include certain users. we *don't* need to be notified when someone presses "hookflash"; and we *don't* need to tell the UA exactly how to write something on a display (that may not even exist). >As Billy rightly observes, sending a refer for a sip URL with a BYE method >makes a lot of assumptions about how its processed in the recipient. It is >assuming that the UA matches the BYE with an existing call leg, it assumes >tags are handled, yes, the examples make a lot of assumpions. i don't think it is really such a big deal to codify this kind of behavior in some IETF document. then we can stop making assumptions about the semantics, and then we can make a lot of cool things work. the problem that i think is more significant is the retransmission problem that motivated Billy's REFERDONE method. >it assumes the UA is willing to accept REFERs with BYE, actually the UAC just _requests_ a REFER w/ BYE; the UAS is free to decline that request. >The simple fact is, SIP is a poor control protocol. If people want a real >protocol that can adequately remote control a phone, thats a totally >separate thing, with different primitives and communication requirements and >security implications. I believe SIP is entirely inadequate for such a job. I disagree. whatever this set of "control request" primitives is, it needs to follow the same path as the SIP signalling, and it needs to interact with the SIP security and policy rules, etc. etc. It seems logical that these primitives are indeed SIP messages. PHONECTL (while a reasonable stab at its problem set) currently assumes shared secrets between the controller and the phone (won't work for a Guest phone in my lobby), will need separate firewall treatment, and can't easily particpate in the mobile roaming aspects of SIP which are so nice. I believe that REFER with some additional semantic definition, is adequate for this job. >REFER was a sort-of-compromise; it introduced a little bit of control into >SIP. It was enough to do a bunch of simple things (call transfer >specifically), and as such its a nice primitive for building services. But, >I believe it is inadequate for a complete control protocol. Thus, I share >Billy's concerns about using it to hang up existing calls, among other >things. We've been pussy-footing around the nut of the call control problem for over a year now. If we ever want to get better-than-PSTN call-control services in a SIP environment, we need to define powerful, generic primitives now. >We should probably add text to REFER that is explicit about the requirements >(and non-requirements) for processing REFER at the recipient. > >Flame away. likewise ;-) thanks, -rohan >-Jonathan R. > >--- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 >http://www.dynamicsoft.com > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 8 09:37:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22194 for ; Fri, 8 Dec 2000 09:37:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1FD4344338; Fri, 8 Dec 2000 08:37:16 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id 8B21944336 for ; Thu, 7 Dec 2000 21:23:29 -0500 (EST) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id JAA29719 for ; Fri, 8 Dec 2000 09:02:38 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA4C2A; Fri, 8 Dec 2000 08:43:43 +0530 Message-ID: <053b01c060c6$de22fd40$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: "Billy Biggs" , "Alan Johnston" , "Rohan Mahy" Cc: "Robert Sparks" , "SIP List" References: <20001129110944.B28481@div8.net> <4.1.20001207090123.02099300@imop.cisco.com> Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 8 Dec 2000 08:58:00 +0530 Content-Transfer-Encoding: 7bit That's a very interesting concept ;-).... What is a "line" in a digital phone ;-)? What you have essentially described is the functionality of a multi line digital phone and "buttons" or "lines" are just a means provided to the end user to easily identify a particular "media flow" so that he/she can toggle between calls ;-), identify when all "lines" or "media sessions" that can be supported by an UA has reached its limit and provide coverage on busy treatment and so on! and what 'providing music on hold' or 'transfer' means using this call flow with SIP is that you are using an 'additional media session' or "line" which in turn reduces the number of incoming calls which could otherwise be handled by the UA by 1 ;-)... ----- Original Message ----- From: "Rohan Mahy" To: "Venkatesh Venkataramanan" ; "Billy Biggs" ; "Alan Johnston" Cc: "Robert Sparks" ; "SIP List" Sent: Thursday, December 07, 2000 10:37 PM Subject: Re: [SIP] Music on Hold in ietf-sip-service-examples-00 > what's a line in SIP? ;-) > > seriously, you don't need *any* line buttons. You need to be able to > associate zero or one active media flows and zero to inactive media > flows with the same media terminating resource (speaker and microphone for > audio). optionally a SIP UA that can support media selection and mixing > should be able to support active media flows if they all use compatible > media and codecs. > > thanks, > -rohan > > At 02:36 AM 12/7/00 , Venkatesh Venkataramanan wrote: > >I request a small clarification in this regard. Seems to me that this call > >flow assumes that the far end UA being put on Hold necessarily has atleast > >two call appearance buttons if this call flow has to succeed. Is this > >understanding of mine correct? If so, using Refer to place calls on hold > >wouldn't work for single line telephones that spoke SIP. > >----- Original Message ----- > >From: "Billy Biggs" > >To: "Alan Johnston" > >Cc: "Robert Sparks" ; "SIP List" > > > >Sent: Wednesday, November 29, 2000 10:39 PM > >Subject: [SIP] Music on Hold in ietf-sip-service-examples-00 > > > > > >> In sip-service-examples-00, you discuss performing music on hold using > >> REFER. A shortened call flow is below: > >> > >> On hold: > >> > >> User A User B Music Server > >> | | | > >> | REFER Refer-To: sip:music@server.com > >> |<-------------| | > >> | INVITE/200 OK/ACK | > >> |<--------------------------->| > >> | 200 OK | | > >> |------------->| | > >> | | | > >> > >> Off hold: > >> > >> | | | > >> | REFER Refer-To: music@server.com;method=BYE > >> |<-------------| | > >> | BYE/200 OK | | > >> |<--------------------------->| > >> | 200 OK | | > >> |------------->| | > >> | | | > >> > >> I have two problems with this method: > >> > >> 1. In our implementation, User A will hang up the call to User B after > >> the REFER completes successfully. This is to protect ourselves > >> (User B will also send a BYE), however, I can imagine most > >> implementations will be similar. > >> > >> 2. As mentioned in my previous email on remote device control using > >> REFER, the URI music@server.com;method=BYE is insufficient to > >> indicate to the UA which call should be disconnected. It's also > >> overloading REFER and obfuscating its meaning. > >> > >> There are more appropriate ways to implement music on hold. One is to > >> have User B call up the music server itself and swap the SDP (3pcc). > >> Another is to have User A call up the music on hold server when it > >> receives on-hold SDP. > >> > >> -- > >> Billy Biggs, 3Com Email: Billy_Biggs@3com.com > >> http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > >> > >> _______________________________________________ > >> SIP mailing list > >> SIP@lists.bell-labs.com > >> http://lists.bell-labs.com/mailman/listinfo/sip > >> > >> > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 8 11:59:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14779 for ; Fri, 8 Dec 2000 11:59:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8183644339; Fri, 8 Dec 2000 10:59:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 3EDD144336 for ; Fri, 8 Dec 2000 10:58:55 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id IAA04121; Fri, 8 Dec 2000 08:58:52 -0800 (PST) Received: from sony-laptop (rmahy-dsl5.cisco.com [10.19.53.126]) by imop.cisco.com (Mirapoint) with SMTP id AAC62527; Fri, 8 Dec 2000 08:58:13 -0800 (PST) Message-Id: <4.1.20001208090025.00cd9820@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: "Dean Willis" , "IETF SIP (E-mail)" From: Rohan Mahy Subject: Re: [SIP] Come on, people! You can DO this! In-Reply-To: <00fb01c06072$c5896cf0$ea036e3f@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 08 Dec 2000 09:00:41 -0800 I'll take Nov 12 - 18. -r At 09:25 AM 12/7/00 , Dean Willis wrote: >So far, only four people have volunteered to summarize a week's worth of >threads on our list. And two of them work for dynamicsoft. > >The list of dates is posted at: > >http://www.softarmor.com/sipwg/meets/IETF49/listissues.htm > >and I will post summaries there as they are received. > >How about some help? > >The mailing list archive is available to all at: >http://lists.bell-labs.com/pipermail/sip/ > >Thanks > >-- >Dean Willis > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 8 15:14:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07558 for ; Fri, 8 Dec 2000 15:14:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E2D54436B; Fri, 8 Dec 2000 14:14:19 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 2C59944336 for ; Fri, 8 Dec 2000 14:13:57 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id CAA17358 for ; Sat, 9 Dec 2000 02:19:17 -0600 Message-ID: <00e101c06153$0d02c8c0$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" References: 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 5.50.4133.2400 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Closing WG Last Call on draft-ietf-isup-mime-06.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 8 Dec 2000 14:11:15 -0600 Content-Transfer-Encoding: 7bit The Nov 23 WG last call on draft-isup-mime-06.txt has elapsed. I believe the only comments were: 1) Would be nice to have a "changes since last draft" section, and 2) reference to RFC2183 for Content-Disposition. If there are no other comments, I'll ask the authors to add the reference and then I will send the draft up to the IESG for further consideration. -- Dean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 8 15:18:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08809 for ; Fri, 8 Dec 2000 15:18:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 71CEE44394; Fri, 8 Dec 2000 14:18:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ivigate.intervoice.com (ivigate.intervoice.com [208.200.21.196]) by lists.bell-labs.com (Postfix) with ESMTP id C223F44393 for ; Fri, 8 Dec 2000 14:17:24 -0500 (EST) Received: from itmail-ict1.wichita.brite.com (itmail-ict1.wichita.brite.com [151.214.5.174]) by ivigate.intervoice.com (Build 98 8.9.3/NT-8.9.3) with ESMTP id OAA12133; Fri, 08 Dec 2000 14:16:33 -0600 Received: by itmail-ict1-imc.wichita.brite.com with Internet Mail Service (5.5.2448.0) id ; Fri, 8 Dec 2000 14:13:17 -0600 Message-ID: From: "Culpepper, Bert" To: Dean Willis , "IETF SIP (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] List thread summary 8/12-8/19 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 8 Dec 2000 14:13:10 -0600 8/14/00 Thread: Call Flow I-D Final Review -- Alan announces draft-ietf-sip-call-flows-01.txt is ready for final review, asks for volunteers. No other response found on the list. 8/14/00 Thread: Encoding scheme for SIP concealed hosts -- Nilesh Trivedi asks about an algorithm for encoding an encrypted host that fits the 'token' syntax. Also asks about a proxy's parser handling of the encrypted host when it doesn't support the specific character set used. Nilesh later states that base64 encoding may not fit token syntax due to its use of '/' and '=', again asks for comments. No response or further posts. 8/15/00 Thread: SIP Servlet Delivery and SIP Root Servlet drafts vailable -- Michael O'Doherty announces the availability of two drafts dealing with SIP Servlet Delivery and SIP Root Servlet. Asks for comments. No response or further posts. 8/15/00 Thread: Question on 'version' parameter in draft-ietf-sip-isup-mime -03.txt -- Kevin Summers suggest adding a list/table of ISUP version numbers. He states version numbers are mandatory and suggests implementers should not decide these values without some recommendations. Asks for comments. Jon Peterson replies that IANA registration will be used for ISUP version and associated with a published standard. He states that due to the potentially large number of version numbers, that no table be added to the MIME draft itself. Appears closed. 8/15/00 Thread: Question on unknown methods -- Deepak_Pant asks whether unknown method support is only required for active calls or also for callIDs of non-existent calls as well. Jonathan replies a server can reject any request with 405 whether known or unknown. He also states that an implementation should support new methods inside and outside of a call if it makes sense. Appears closed. 8/15/00 Thread: Multiple To/From lines and Bcc -- Simon Barber asks whether multiple To/From line are allowed. Also asks about an equivalent for Bcc:. Jonathan replies that the BNF is explicit in that From and To specify single name-addr or addr-spec. Brian Bidulock points out that the BNF for general-header indicates From can occur multiple times. Laurent Steffan writes that the draft later states multiple headers are not allowed unless the field-value is defined as a comma separated list. Not the case for From/To. Brian indicates his satisfaction. 8/16/00 Thread: Telephone-subscriber registration -- Robert Fairlie-Cuninghame asks about the existence of a standard method to register a range of telephone-subscribers. Suggests using a wildcard character in a tel URL. Hisham Khartabil recommends looking at draft-rs-trip-gw-00.txt. rafi later asks what a response would look like not all subscribers are successfully registered. Jonathan replies that wildcards are not valid and suggests not worrying about error conditions for non-existent features. Robert thanks Hisham. Closed. 8/16/00 Thread: Registrations not sharing the same Action -- Neil Deason asks if there a real need for the restriction that all active registrations MUST share the same Action. Jonathon replies that this was considered and the conclusion was that specialized call processing logic is better handled through CPL or something similar. Appears closed. 8/16/00 Thread: Operating a SIP Client behind a Firewall -- Harleen Gill asks about the existence of a recommendation for keeping a timed connection alive between a client behind a firewall and a server outside of the firewall. PAscal Dor recommends reading draft-ietf-sip-session-timer-02.txt. Jiri Kuthan later asks the meaning of the questions and describes two packet flow cases: Signaling and Media. He points to draft-rosenberg-sip-firewalls-00.txt. 8/16/00 Thread: Media & Signaling inter-dependencies, issue with 183 ? -- Robert Jean-Hughes asks in the presence of early media how a caller can tell a callee to send media according to a new SDP. Also, how a callee sending remote ringback be put on hold. He suggests a re-INVITE prior to INVITE transaction completing, also use of 183 both ways. Jonathan responds that the issue is a good one, he mentions three possibilities and suggests revisiting this. Robert Fairlie-Cuninghame seems to indicate clarification is needed. Arnoud van Wijk agrees that the issue should be looked at and also recommends living with the fact that sessions can't be modified until the session setup completes. More and more discussion... Conclusion: punt and live with 183 and SDP in provisional responses. 8/16/00 Thread: RE: [IPTEL] URL to support Number Portability was: draft-yu-tel-url-00.txt] -- James Yu asks SIP list for opinions on draft-yu-tel-url-00.txt. No responses or further posts. 8/16/00 Thread: Bakeoff #5 Advanced Scenarios: Media Changes summary for one group -- Brett Tate summarizes results of SIP bakeoff #5 advanced media switching. No further posts. Closed. 8/17/00 Thread: a query on SOCKS -- rahul pande asks about availability of open source for SOCKS v5. Jiri Kuthan make reference to http://www.socks.nec.com/ but expresses doubt in it being of help. Closed. 8/17/00 Thread: SDP: `s' & `t' lines -- manu@sasi.com states that in many examples in section 8.1 and later of draft-ietf-sip-call-flows-00.txt do not include 's' & 't' lines. Mentions that SDP RFC requires the lines and asks if the draft is in error. Jonathan replies that the call flows draft should be fixed. Closed. 8/17/00 Thread: whitespace in SIP & SDP -- manu@sasi.com asks about the use of whitespace in SIP & SDP grammars. He points out a conflict between an example and the BNF in rfc 2327 (SDP). He points our a similar contradiction in the SIP rfc and the torture tests. He asks if a parser should be lenient or strict. Arjun Roychowdhury replies that SIP is lenient with LWS. Laurent Steffan agrees on leniency. Discussion moves to white space in wrapped lines and quoted strings. Discussion later moves to escaping CR and LF, perl, ... 8/17/00 Thread: Instant Messaging.... -- rahul pande asks whether MESSAGE method (reviewer's correction, was "header")is needed since "m=text tcp plain" with other a= attributes is proposed for tcp. Arjun responds and questions whether m= line solves instant messaging and goes on to argue that MESSAGE is appropriate for instant messaging, refers to impp drafts. Jonathan replies that the above might apply to text over RTP and references http://www.cs.columbia.edu/~jdrosen/papers/sipimpp_sip2k.ppt. Appears closed. 8/17/00 Thread: another general query (SIP+) -- Christopher Downey asks about pointer to information on SIP+. Neal Deason provides a little history and makes reference to http://www.cs.columbia.edu/~hgs/sip and draft-vemuri-sip-t-context-00.txt. Closed. 8/17/00 Thread: ipv4 addresses in SDP -- manu@sasi.com asks about the correctness of decimal-uchar = ("1" 2*(DIGIT)) in RFC 2327 (SDP). He/she interprets it to mean '1' followed by at least three digits. James Undery indicates that his/her interpretation is wrong. Arjun writes that it indicates '1' followed by at least 2 more digits and this intention may be wrong. Jonathan recommends that complete production be examined (not just one of 5 rules), which results in a correct address. manu asserts the third production allows invalid addresses. Jonathan agrees and recommend changing the rule to ("1" 2DIGIT) in the draft version (SDP?). Topic belongs in confctrl@isi.edu. Appears closed. 8/17/00: Thread: UAS & UAC with different port numbers? -- Damian Farias asks about using the same port (5060) for both a UAC and UAS. Jonathan points out that UACs can use whatever port they like for responses, something different from 5060 can be supplied by a UAC for responses in the outgoing request. Closed. 8/17/00 Thread: Legal loop detection-Hash calculation -- Deepak_Pant asks why From and To are needed in a hash calculation. Jonathan responds that To, Form, CallID, and CSeq results in the branch-ID of the request being a complete transaction identifier. Also states that the hash calculation is an implementation decision. Closed. 8/18/00 Thread: A query on SIP call flow -- rahul pande asks how a callee replies (to reject) to a request for a unicast session where a media session is specified as recvonly by the caller. Hisham Khartabil recommends 403 or 415 response. rahul asks how to reject one media stream not the call itself. The response is for the caller to indicate its capabilities in its response. Response is submitted describing the use of port 0 in media descriptions. rahul indicates port 0 can be used in sendonly media descriptions. Jonathan writes that text in appendix B.2 can lead to confusion and recommends a change that use or port 0 mean one thing only - refusal of the media stream. Appears closed. 8/18/00 Thread: Simplify SIP -- Bertil Engelholm proposes several ways to simplify SIP. Reviewer punts here. My apologies, this topic generated a SIGNIFICANT amount of opinions. Conclusion: SIP stays as specified. 8/18/00 Thread: HTTP and SIP URLs -- Vishwa Kumbalimutt asks about the correct syntax for HTTP URLs in a SIP URL parameter. Reviewer found no responses or further posts. -Bert _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 9 02:17:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA15892 for ; Sat, 9 Dec 2000 02:17:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8E8BA44338; Sat, 9 Dec 2000 01:17:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 6C16844336 for ; Sat, 9 Dec 2000 01:16:18 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA25128 for ; Sat, 9 Dec 2000 02:18:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sat, 9 Dec 2000 02:13:59 -0500 Message-ID: From: Igor Slepchin To: "'sip@lists.bell-labs.com'" Cc: Dean Willis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="koi8-r" Subject: [SIP] List Thread Summary 10/1-10/7 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 9 Dec 2000 02:13:52 -0500 This excludes threads where no new SIP-related issues where brought up. 10/1/00 None 10/2/00 Thread: Provisional responses in other direction Q. UAS may send ISUP bodies in 1xx and 200 responses. What if the UAC wants to send additional ISUP before final response is received? A. Gonzalo Camarillo: use INFO. Cliff.Harris@nokia.com: this has been discussed before: caller may not have enough data to send INFO (no tag, or Route). See http://lists.bell-labs.com/pipermail/sip/2000q2/000006.html for previous discussion. Thread: Second branch parameter Q.Section 6.46, August bis talks about branch ID consisting of two parts but doesn't say what the delimiter is. Also, two parts a SHOULD, not a MUST A. "second branch parameter" is by definition part of the whole branch parameter, thus you just use the whole branch parameter to distinguish. Just update the wording to avoid confusion. 10/3/00 Thread: Error in Via received BNF? Q. The Sept 4th bis, Section 6.46.2, says that, "...If and only if the source address and port differ from the sent-by address, the proxy also includes the source port in the received parameter." But the BNF for received tag has no port. A. The description is incorrect, only the address is checked. The text is updated. Thread: SIP ISUP MIME draft Q. Any comments on the draft-ietf-sip-isup-mime-04.txt? A few questions came up: Q. Can Content-Encoding be used with ISUP payload? A. No, it's in binary Q. Is Content-Disposition a mandatory field? It's optional but there should be default. No default is currently specified. "session" is not appropriate. New Content-Disposition of "signal" is proposed and accepted. Thread: centralized vs. decentralized architectures The name notwithstanding, the question was about assigning ad-hoc addresses to downloadable SIP phones. Joshua_Fox wanted to solve the problem by anonimizing the caller. JR response that it doesn't make much since "network elements that provide service to this payphone would authenticate it" 10/4/00 Thread: Registering non-SIP URIs section 6.14 has one paragraph about 'REGISTER requests': "Other [non-SIP] URI schemes have no expiration times." Would be nice to move it to 4.2.6, where REGISTER request is described. The changed was made to a later version of bis. Q. Why is the default expiration interval 1hr? A. No reason, it's fairly arbitrary Thread: ipv4 addresses in sip bnf Q. Why IPv4address BNF in SIP is different from the one in RFC2327 (SDP)? A. Because it's inherited from HTTP. 10/5/00 None 10/6/00 Thread: New draft on SIP registration Comments on the new submitted draft: Q. The draft talks about using Authentication-Info but 2543bis says that this header is not used in SIP. A. We may want to allow Authentication-Info; besides, we need a mechanism to protect at least some parts of the header via Digest. 10/7/00 None _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 9 13:48:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA06747 for ; Sat, 9 Dec 2000 13:48:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CDB9A44337; Sat, 9 Dec 2000 12:48:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 2597744336 for ; Sat, 9 Dec 2000 12:47:02 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA23091 for ; Sat, 9 Dec 2000 13:46:53 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id NAA19873 for ; Sat, 9 Dec 2000 13:46:51 -0500 (EST) Message-ID: <3A32A93C.629B42AC@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Configuration management for SIP phones Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 09 Dec 2000 13:50:52 -0800 Content-Transfer-Encoding: 7bit Following up on my talk at the SIP bake-off: I'd like to propose an informal discussion list on how to configure SIP UAs. Currently, there seem to be a large number of different mechanisms, such as tftp, http and proprietary protocols (I don't think DHCP is used), each with a different file format. This makes it rather difficult to deploy multi-vendor SIP-based enterprise phone systems, throwing us back to the bad old days of proprietary PBXs, being forced to buy all phones from a single vendor. The goal of this effort would be to arrive at a small set (hopefully of cardinality one) of mechanisms for configuring light-weight end systems. (This does not mean that a system could not also support other mechanisms.) If there's sufficient interest and convergence, some form of IETF standards-track or informational document may arise. Since the SIP list is plenty busy and since this is likely of interest only to a small group of people, I created a new mailing list, sip-config@egroups.com. Please subscribe if you're interested in this topic and wish to contribute. Thanks. Henning _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 9 15:58:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA28473 for ; Sat, 9 Dec 2000 15:58:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C47244337; Sat, 9 Dec 2000 14:58:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 48C1544336 for ; Sat, 9 Dec 2000 14:57:51 -0500 (EST) Received: from pn31.warszawa.cvx.ppp.tpnet.pl ([213.76.109.31]:1539 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Sat, 9 Dec 2000 21:57:35 +0100 Message-ID: <3A329CDE.6F884E97@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: SIP discussion list Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Subject: [SIP] Detecting of retransmission in the first INVITE case Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 09 Dec 2000 21:58:06 +0100 Content-Transfer-Encoding: 7bit Hello, Section 11.5 of RFC2543bis-2 says: "If the Call-ID exists, the request is for an existing call. If the To, From, Call-ID, and CSeq values exactly match (including tags) those of any requests received previously, the request is a retransmission." I am not sure whether this statament applies when we processing the first INVITE. The first INVITE does not include a tag. The tag is added when response to this is created. According to 11.2: "The UAS stores the values of the To and From field, including any tags. These become the local and remote addresses of the call leg, respectively." So, when we want to detect retransmission it will not be easy possible, because UAS' To header has already tag, but retransmission of the INVITE still does not include To's tag. Could you correct my thinking or the spec. ? Thanks in advance, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 9 17:16:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15611 for ; Sat, 9 Dec 2000 17:16:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 77A0C44337; Sat, 9 Dec 2000 16:16:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5A98144336 for ; Sat, 9 Dec 2000 16:15:32 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA26349; Sat, 9 Dec 2000 17:17:45 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sat, 9 Dec 2000 17:13:02 -0500 Message-ID: From: Jonathan Rosenberg To: "'archow@hss.hns.com'" , sip@lists.bell-labs.com Subject: RE: [SIP] query on forking. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 9 Dec 2000 17:12:59 -0500 Reach all is not supported through the existing forking mechanism. You will need to do something like fully-distributed multiparty conferencing, TBD. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: archow@hss.hns.com [mailto:archow@hss.hns.com] > Sent: Wednesday, December 06, 2000 12:42 AM > To: sip@lists.bell-labs.com > Subject: [SIP] query on forking. > > > > > Hi, > assume I want to set up a chat with a group called "all-boys". > My proxy server knows who all are in "all-boys" , I dont. > so I send a message: > > MESSAGE sip:all-boys@hss.hns.com > > > and the server forks this to > > sip:boy1@hss.hns.com > sip:boy2@hss.hns.com > > Typically, if say boy1 returned OK and boy2 some 4xx message, > the forking > proxy would only send > me the 200 OK. (best response) > > However I want to receive both success and failure. That is, > I want to > know if boy2 returned fail . > This may be necessary when I am sending a group request to > people and my > intent is not a "reach first" but > a "reach all". If I know boy2 failed, I might use another > means to send him > the same message. > Note that I do not want to broadcast or multicast. > > so my question is: is there any way to use a forking service > here and have > it return all responses and not > only the "best" responses ? > > I noticed the recurse tag in caller and callee preferences - > but that only > seems to take care of either replying recursively to 300 > class messages or sending them back to the caller. > > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 9 17:20:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16504 for ; Sat, 9 Dec 2000 17:20:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5589344337; Sat, 9 Dec 2000 16:20:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B911444336 for ; Sat, 9 Dec 2000 16:19:41 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA26370; Sat, 9 Dec 2000 17:21:35 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sat, 9 Dec 2000 17:16:52 -0500 Message-ID: From: Jonathan Rosenberg To: "'Fairlie-Cuninghame, Robert'" , Jonathan Rosenberg , "Henning G. Schulzrinne" , Billy Biggs , sip@lists.bell-labs.com Subject: RE: [SIP] Re: My comments on bis-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 9 Dec 2000 17:16:43 -0500 > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Wednesday, December 06, 2000 12:21 AM > To: 'Jonathan Rosenberg'; Henning G. Schulzrinne; Billy Biggs; > sip@lists.bell-labs.com > Subject: RE: [SIP] Re: My comments on bis-02 > > > > > > 5. Due to the proliferation of the Also header in BYE > > > requests, I would > > > > suggest that it be added to the bis draft, with its meaning > > > > restricted to use with the BYE method. > > > > > > Tentatively added. > > > > Hold on a sec.... BYE/Also is in a draft that has expired a > > long time ago. I > > thought we revisited this and came up with the REFER > > mechanism. Also, AFAIK, > > has been discarded, along with its usage in BYE. I don't know what > > proliferation you are talking about. > > Jonathan, > > It is such a simple yet useful mechanism (that I beleive quite a few > implementations support), isn't it reasonable to leave it in > the bis draft > even though it does overlap (or is a subset of) the > functionality of the ful > blown REFER. I think it is confusing and will ultimately lead to interoperability problems. I am sorry that there are implementations that choose to ship products based on -00 drafts that are experimental in nature. The BYE/Also mechanism has issues, and we have resolved these in the REFER draft. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 9 18:04:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA26001 for ; Sat, 9 Dec 2000 18:04:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6ECB844337; Sat, 9 Dec 2000 17:04:18 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8046B44336 for ; Sat, 9 Dec 2000 17:03:30 -0500 (EST) Received: from CINQUECENTO ([208.54.71.28]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id SAA26462; Sat, 9 Dec 2000 18:05:53 -0500 (EST) From: "Robert Sparks" To: "Billy Biggs" , "SIP List" Subject: RE: [SIP] Replaces Header Draft Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <20001117160526.B31680@div8.net> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 9 Dec 2000 17:01:33 -0600 Content-Transfer-Encoding: 7bit Billy, Rick - Why not allow all of the call-leg identifiers on the Replaces header (the full To: From: and Call-ID: headers, perhaps formatted the way you would format header parameters to a URL.)? Was providing the tags only an optimization? Further, why not _require_ all of that information? When would you want to use this header without specifying the To: and From: parts of the call leg identifier? RjS _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 9 21:01:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA06237 for ; Sat, 9 Dec 2000 21:01:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D3CC344337; Sat, 9 Dec 2000 20:01:20 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id 6EE4544336 for ; Sat, 9 Dec 2000 20:00:24 -0500 (EST) Received: from cisco.com (rtp-dial-3-8.cisco.com [10.83.98.8]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id UAA25889; Sat, 9 Dec 2000 20:58:24 -0500 (EST) Message-ID: <3A32E497.8A1D64D3@cisco.com> From: "Bryan J. Byerly" Reply-To: byerly@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.06 [en]C-compaq (Win98; I) MIME-Version: 1.0 To: dwillis@dynamicsoft.com, dean.willis@softarmor.com, sip@lists.bell-labs.com, bjbyerly@hotmail.com Cc: brian.rosen@marconi.com, jo@tzi.uni-bremen.de, byerly@cisco.com, bbyerly@ibm.net, bjbyerly@eos.ncsu.edu Content-Type: multipart/mixed; boundary="------------C01569BE03E8D00BE28611F5" Subject: [SIP] Slides for SIP Diversion, SIP CHAP-Password, SIP Record-Route/Route Hiding ID presentations at 49th IETF Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 09 Dec 2000 21:04:07 -0500 This is a multi-part message in MIME format. --------------C01569BE03E8D00BE28611F5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Dean, Attached are the Powerpoint slides for the SIP Diversion, SIP CHAP-Password, and SIP Record-Route/Route Hiding I-D presentations for the 49th IETF. Please include these slides into the mega-presenation for Tuesday's SIP WG meeting. thanks for your help, Bryan Bryan J. Byerly byerly@cisco.com --------------C01569BE03E8D00BE28611F5 Content-Type: application/ppt; name="SipDiversion.ppt" Content-Disposition: inline; filename="SipDiversion.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAhAAAAAAA AAAAEAAAiwAAAAEAAAD+////AAAAAIIAAACDAAAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////8Qbh7wBw0AAA8Ye9AfA9+h7neS6NeZ0IER7sQX yb8oYT6I38Mr+A4s/4lQTkcNChoKAAAADUlIRFIAAAGQAAAAMAgDAAAACArcpAAAAANzQklU BQUFGCbeQwAAAGBQTFRFwMDA9+fe997O/+/W/7UY97Uh/70Y57Uh/84598Yp3q0Y/++1/9ZK /9Y5984x3rUh//fW/+d7/95a/95S/++l/++c/+dr/++U/+dj//e9///nAAAAAAAAAAAAAAAA AAAA4EtW2gAAAAF0Uk5TAEDm2GYAAAABYktHRP+lB/LFAAAMGElEQVR4nO2aiYKiSBKG3VnJ QyFtQAH7/R90448jMzmqprq7uqd21wC5RIX4Mk45nV7ykpe85CUveckni/unL+C/Vz5Pde5T v+0lvyzumMb/AaPz+TO+xcXtARnjnetkP7538od/5X+Fh95IdTt/4M7kJ4Ys+zOmvp/yJAt+ vSW//5o/T0KodlI6OmXF4OfG2lapQ5u6rmuHDpK6dtSpteUwFiDLJBKmIJJUImZapFB2ky7o oEkb2i9nIF13vF2J3EV1ILJ/cBUQVwfMM/msjzit5/Xa9wuN3/khB+79tAwdKYw4iLQ6Mwtl QiBM0akJNPus5pSJKA87kAHtgHw1n0WDkSh0PGFXDtKtrc4SIqmLp85cOJg43IxzPJhJU/Tq quG7Gfv3anvi5VDLONJh4jGMKwGDDrrrRELHSi6K19EfRM0pQhqeYpNsSgQNU8R2jAYHB6Jz 7oswgT10basgcKe0EbBJHiDBYREDeiulbsTZYMcTRirup1O1BNqCb8GblT7JodDYv4s8WGYI vDqpflnM7wiPcVlwFN8iw7erJe8FD5V7TE18U3AS1A0AyQcfwCMwgxolTfEjPNwuQv5sDvGO LNAJCW3CK4hL6Eao3V5tyy8sx641HB2AkKcng8kuoAsYyKTj1fAeZAFfP/fTgz1+PzMP+vFh 0V/dyMi/AwZtKDSEQRQcWMMEfNxOxgOjv/F0Ai3wBhPi7caLEA0cdP+8hTygEaAYhAiRmcxJ d2NoMxChoWvejy1808i7HHRh/+xHppGUjNE+boWByO8QDqCYsAXntObQ6jXQz5UAXAY8FjQ7 2YRmo/OsZFY53nCRMeWTBJHHrq+/ho0LND2DimYtG0WpR/6tMHhwTrJUC1nUhZOiJWsRFwLN 8HEasR3UyiMXxqD2RBxo5EZEEPIFMAH6KBvFMGZVa+4jU6oTociunB26iR6MUb38zgs1gsIW 0TuesWAGUL3nr/Bx92E76MvnG1lbyM8Tu192w0ylMIldrKjF48z7h+SuLIRKBWRQr69HaKcD EObUtaxnQAgaLXC9bBpsS1149JMB0VOFRxtqJBqNA/NQGBu1p81ag3RsYrYMGfACgwOF80nZ ZtDHcaVRT6fGxvbjXHNq7FMS7cM48oW3Lfw5JYEGQKQCgtuljSG9VRf8PZCpEs3iiYZuLOpQ lkoGzEOBJrmPeBahQZjCPFMAWeiNYFMJRMSrTS6mEF2wjCgPSefSyijUSA406oE16GJddXCw 9klnvG63G157ufACywv7qzoxaCx31pyYfCgyjX4y7bHbrbU5zwc6/iHhiLEsxmInyxrIwK9h 2fAozp+1DpVTQbEgSIdMQXMA5cIWEteewRxWiqsRypvkGzSeB4nwFYayeaP8ybe0rOTmbzd/ 05VtvS055LCB5a9n+/GD9yj2kTnTMcoAJ6n6hwH5I9JGKJVzxwdqqfv9b/Qvcr1eKfHk7GaZ 3mShNrMyjbpOGDRrajMOyblEbRRCFovOo8boNmdlbEVh46nFbRkbXhpfsTxYGi/F5MJexBiJ C02keA/VYy0ceGYsbA6CqwjjatREzs25gXCSUEWgRP5NUnv+NXQKdGS2VnIty9xTqkQJPnL8 DwGhs5FtSv5vvmrZTMZk46mWAmRQIhlJie/87eEwi91Kt3oZMthWy4kuZgFgXi+r/kYzpiCQ eI9Q4EAgS6EpeBjNjdY6s6ws6ECcbxwFpMbRq7GysobCtiM8xiH3EEYtoySDFDbLR4A8yUK4 HkOjoiZyYCBCSrPhOpQUzzVo4C5Y2r6FZcNnyZW+SaMYT8w8StXD8YhtAkzgrpBHSGIwWF3T MpQgYffG5gFScF/tjZkIChw5Fj5BXrd4uVz8ZS3+QogopXbIrBt2aI2LTjbqsKPW3aCDg0sc JLdXHWf9s87q2PN8kr+aS1r1ntNiHIeRfdXmyDofUUk+Zs7a6KS2rVzae1ZSF/5d9m4tg2i5 IuR3wq6sYWMyDLAR34qSt1K3V/Jmzgyw4en4ZSf+IkbjwMIhC6O8NxoWI9JkJGw9q0QASdJS xWMeyajTBAraFtywKEp+L4ZMWioWy1hyBNE0uHJaGh6YNZMaco2e50MkQRTfWgNgqD52KPhZ 6D3VuvfrtV+h8UE0JV1IAUMMGj7q8T00pRqEwDCL8Tejw1I1AmLuG2fg4lYNyKLBvye9k+5Z M9fncxLroHj+fGL9mPs3UawjSLaKVQQZa9PIquTBDrMarSocy+nWPNlN4+61l839FqV71ra6 HR3/QXpVWVccipu6H69cIq+o9OCuYzqze3JYqAgQoCg0VjiyZeSrk37nKgGkvJNg9NK+m2l1 Jwan79//9f0biwLpV55oFSOqzLYNw1qKxtraPDpzPiGwliVAjO2Rdjkk2kdDLuGPXUx1o1ZT hpJmlY7j9iMKhIyAEiZKkBpdlQawbeE92RZdO3FP8E5cdMqESCK9gAKkNChDqq8/30+7Ml6V B793+v6NeTy/TW+BMGuoaw3SW6hC+ApIHcsBY+g64ZmJsNUeAMkfDJbPdtu72WqXFZ7fzz3f ckSIQO2hqYSVbblSoZGJWCEoC9Y9Q/EKA5teVtHljqbMyZdr88EGy0EMqyw6C1Ug7LEk5d1z mAqQKXfBmUe7aBantCzREnISTDSsaOo35kPmr+TNzLIyKwverNJxQKuCKrHIma8sSg0Cx9wF btqEjktxeP6G1hj8OgfbEHswm6iAMCejVMwFPBpp+MJv8Y53CN7MwiZuk+F99m/nRhrJHPvP 3q+V/yaa8hcs0Xhe+V8JbX0fSS/FyBqUoBA0VpYszGPY/jldh40cKmQeq7gxGLASlSyNZgAl /WXLZwNhAl4GfxD1c6YpCJq8+jkBAzDhlWVUnO06d5YdSXv5LdT1YkNOWvdS5jvmBQvS3n7i CC/RrvCqMl/Uh2Ir03TQOelzxrtJeAkAGi5DATBLjTlvgYxj9a1V5M6gCgflNMhRPaUVyzjw YrRq1DkAxK9o/wgIU7icaXU+ny9nWWCbFjSJzp0XvZewbm7VuyR8mFl++9hI9jUiBXf4sevq KIV8PniVLJmW/Cd3bwt9eiPjmCscD3QBHsgj+jXmJdc1aAIPY44eFvY+InxfxEDGmWzARD5k E/EtBGIMZ55kBQgX46FLAkLeq3HZREr5UWdZ9eiRjTo2at9HgucBkB+Q7SMyqPev9408pMUm yR07R65I9CO5IbAYEC3rtBsS1lde7mxHzDMOL36rpsGQGv7n3I4bB/lPPebIgVEM1Zcz0L46 e6NxMSq6cy4Gkwk1uWSvpR49GylAKM8cfwnIG7IBcn9UCI+wghVcnl6zDCnNHeqqnltZ9E6b u4lrHPDGFQcpP4JSsAVnupas6RMOkclEJUVaZRyE52xyqa1it1W/K/7LxR2SPZ0VEb2h38Hj hGcVBMbHzv+L7aYfcEGPwNneYNXMqohfuPWiQOi0YbR6BW3cxqyotgw2Dn4SKGDRqFcLeMwk sWNTJsPCn01wV+etbNVe7KNeXypDKXIIRv1ZJiKjLf0yj23nUvfJbV0/SiPL9f7QB05ApEdv 1BLhR29PPSCFsNC0cFkj9zOqeTUCpMTTKJ1YbosEBaI/OOMxgXFY8FXSMxcgsBF/pmsA7rRT cOWyVoZSO7F6IgfoNIbDK0l3MU2ljlIodLPxNzyowiKB5MOny7iw8/s+0Ic50LDDovDDKQID mUKVtdFdyN3AtenItzrRkOifixJH1j/bTyO5vxGP4S1AOoxyIehYzGi0LgpEY/t5bxa7nb2B wEbgE5NqHfUB56x6D8Yj0M/vnqH4QtL37XxHKoAdIjIBCxuQzHwXYwqSAdD9bAr4eEqcUNDH 7vP9h/9GZZNs6yPoK8F0qSJG4X+keGa2YYKMDekCAhZHpmlppik/SjxX6ejjSz9GDGXmHW6y zdwWTelEOqb0WbIyGnFMBA9NpvIQAaXuVy50T1Vm/ssiPN7x85rzOvuXGZlFkGPB+mVx66tC ECKPz7nIPyL4f/kxX/963smdPLUDKmkyeLz72T9/l409oBqrP0HwLAQF2P4eG310Vf+yMp9L Kc0fv9KfFipJV/tf2rY3koHgsdn6usmK/306pZxmjR/6a/clL3nJS17ykpe85CUveclLPl3+ A8OGx0bKklwyAAAAAElFTkSuQmCCkHof8CkLAAAuyuxjmHOG/GgTcFZBMc48TOB2FI1dsdmK FPPz3vhPwf8oAAAAHgAAADcAAAABAAgAAAAAAOAGAADODgAA2A4AAAABAAAAAAAAAAAAAICA gAAAAIAAAICAAACAAACAgAAAgAAAAIAAgABAgIAAQEAAAP+AAACAQAAA/wBAAABAgAD///8A wMDAAAAA/wAA//8AAP8AAP//AAD/AAAA/wD/AID//wCA/wAA//+AAP+AgACAAP8AQID/AOYK AADnRwQAAAQeAOdHAAAAAIcAPycnAJKE+gC/FgQAAQAdAAAAQgBfSAAAAAD6ABAAAAABAAAA foQ0AP//hwCShEEAvxb/AIc1AQDUhAAAAABvAEKFXwCkkKcAPCHHAPP/AAAAAA0AIADMAAAB AAAFtQAACQBgAGAAAAAAANQApwVGAFYYMgBfSFYAAQA0ABcEzgACAQAAAgCEAAIAAAAAAL8A BIUAAAAgbwABAAEAAAADAAAABAAAAOcAWodZANcDpACnBTwAxwUgAMwANgAdAAAAb0iwAAAA XwAGADcAVoVoAFchAQA3IFkAkMNHANYSNwA3INkAGxZHANYScgBfSOcAU3lzAGVgAAByhgIA nAAAAAcAAACMAAAAfQAAAJUGnwD7BpEAAAA3ABCGXwBPIAAANyAOAGe1RwDQAJUAnxb7AJEg AAA3IAAAAADoAAYOTwA3IDcAPIZnAEcgAABvSAAAAAD+AF9IAwBghiIACQAOABAABwC8AgAA AAABAAIiUwBzdGUAACJWAAAAEABIwNYAAQD3AEgA5QCcUgAAPx8AAJ7qBgCnBWcAAABeAA4U ZwAQAaQAGRRWAKcFKQCsCv8ADgAQAAAAvAABAgIAZW0AAFaQAAAQiAAAAABIANb/AAD3v0gA AADhAF74UAAdADYAHgABAAAA5gAIAFwAAABwAK6BNABZwBAAAQCkAK6BXACugQAArYEAAAAA NAAAoAAArYGkAIPDKABWkAoAWIEAAAAAnAD3v/4ALzwKAHQG9gBqhxoAAgCYALBIAADgRwAA JIeyABcBtQDgRwEALwFmAOFKFwBkEy8AZocAAE6HAAAAAMAAAABaALJ/FwC1f7AA90cvAJSH bgAXAWQALwEAAAAAlAAAAIQAAADwAAAA9wAAALAALwHvAAICvwCAs/cAAPOwAF0A8AAAAKoA tX/wACl5PgBWkFYApwXsAKwRVwDKGrYAAgCYAAAAAAAAAAAAKBkAAPBIAAAkh7IAFwG1APBI AQAvAWYA4UoXAGQTLwAoGQAA8EgAAGaHAABOhwAAAAAAAAEAAAAAAMAAAABaALJ/FwC1fygA /0cvAJSHbgAXAWQALwEAAAAAwAAAAJQAAACEAAAA+AAAAP8AAAABAAAAKAAAAAAALwHvAAIC vwCAmf8AAPP4AF0AQAAAAKoAsn8XALV/QAApeVIACo0KAKcF7ACsEVcA/hoKAA4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODgAADg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O AAAODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4AAA4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODgAADg4ODg8BAQEBDw8ODg4ODg4BAQ8BAQEBDg4ODg4OAAAODg4ODwEBAQEB AQ8ODg4OAQ8PAQEBAQEODg4ODg4AAA4ODg4ODg8BAQEBDw4ODg4BDwEBAQ8ODg4ODg4ODgAA Dg4ODg4ODg4PAQEPDg4ODgEPAQEPDg4ODg4ODg4OAAAODg4ODg4ODg4BAQEODg4OAQ8BDw4O Dg4ODg4ODg4AAA4ODg4ODg4ODgEBAQ4ODg4PAQEPDg4ODg4ODg4ODgAADg4ODg4ODg4OAQEB Dw4ODgEBAQ4ODg4ODg4ODg4OAAAODg4ODg4ODg4BAQEPDg4OAQEBDg4ODg4ODg4ODg4AAA4O Dg4ODg4ODgEBAQEODg8BAQEODg4ODg4ODg4ODgAADg4ODg4ODg4ODwEBAQ4ODwEBAQ4ODg4O Dg4ODg4OAAAODg4ODg4ODg4PAQEBDg4PAQEBDg4ODg4ODg4ODg4AAA4ODg4ODg4ODg8BAQEP DgEBAQ8ODg4ODg4ODg4ODgAADg4ODg4ODg8PDwEBAQ8PAQEBDw8PDw4ODg4ODg4OAAAODg4O Dg4OAQEBAQEBAQEBAQEBAQEPDg4ODg4ODg4AAA4ODg4ODg4PAQEBAQEBAQEBAQEBAQ4ODg4O Dg4ODgAADg4ODg4ODg8BAQEBAQEBAQEBAQEBDg4ODg4ODg4OAAAODg4ODg4ODwEBAQEBAQEB AQEBAQEODg4ODg4ODg4AAA4ODg4ODg4BDwEBAQEBAQEBAQEBDw4ODg4ODg4ODgAADg4ODg4O Dg4PAQEBAQEBAQEBAQEPDg4ODg4ODg4OAAAODg4ODg4ODg8BAQEBAQEBAQEBAQ8ODg4ODg4O Dg4AAA4ODg4ODg4ODwEBAQEBAQEBAQEBDw4ODg4ODg4ODgAADg4PDw4ODg4BAQEBAQEBAQEB AQ8ODg4ODw8ODg4OAAAODwEPDg4ODgEBAQEBAQEBAQEBDw4ODg4PAQ8ODg4AAA4PAQEODg4O DgEBAQEBAQEBAQEPDg4ODwEBAQ4ODgAADg4PAQEPDg4ODwEBAQEBAQEBAQ4ODg8BAQEPDg4O AAAODg8BAQEODg4PAQEBAQEBAQEBDg4ODwEBDw8ODg4AAA4ODgEBAQ8ODg8BAQEBAQEBAQEO Dg4BAQEPDg4ODgAADg4ODwEBAQ4OAQEBAQEBAQEBDw4ODwEBAQ4ODg4OAAAODg4OAQEBDg4B AQEBAQEBAQEPDg4PAQEBDg4ODg4AAA4ODg4PAQEPDgEBAQEBAQEBAQ8ODgEBAQ8ODg4ODgAA Dg4ODg4PAQEBDwEBAQEBAQEBAQ8BAQEBDg4ODg4OAAAODg4ODg8BAQEPAQEBAQEBAQEBDwEB AQ8ODg4ODg4AAA4ODg4ODgEBAQEBAQEBAQEBAQEBAQEPDg4ODg4ODgAADg4ODg4ODwEBAQEB AQEBAQEBAQEBAQ4ODg4ODg4OAAAODg4ODg4OAQEBAQEBAQEBAQEBAQEBDg4ODg4ODg4AAA4O Dg4ODg4PAQEBAQEBAQEBAQEBAQ8ODg4ODg4ODgAADg4ODg4ODg8BAQEBAQEBAQEBAQEBDg4O Dg4ODg4OAAAODg4ODg4ODg8BAQEBAQEBAQEBDw8ODg4ODg4ODg4AAA4ODg4ODg4ODg4PDw8P Dw8PDg4ODg4ODg4ODg4ODgAADg4ODg4ODg4ODg8BDwEBDwEPDg4ODg4ODg4ODg4OAAAODg4O Dg4ODg4ODwEBAQEBAQ8ODg4ODg4ODg4ODg4AAA4ODg4ODg4ODg4PAQEBAQEBDw4ODg4ODg4O Dg4ODgAADg4ODg4ODg4ODg8BAQEBAQEBDg4ODg4ODg4ODg4OAAAODg4ODg4ODg4ODwEBAQEB AQEODg4ODg4ODg4ODg4AAA4ODg4ODg4ODg4PAQEBAQEBDw4ODg4ODg4ODg4ODgAADg4ODg4O Dg4ODg4PAQEBAQEPDg4ODg4ODg4ODg4OAAAODg4ODg4ODg4ODgEBAQEBDw4ODg4ODg4ODg4O Dg4AAA4ODg4ODg4ODg4ODgEPDw4ODg4ODg4ODg4ODg4ODgAADg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4OAAAODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4AAA4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODgAAkHof8OkKAABBfUILz57Nk/NOiDJ0s6c26FaaK0EA IQn8FQr+OMcXyv8oAAAAIAAAADUAAAABAAgAAAAAAKAGAADODgAA2A4AAAABAAAAAAAAAAAA AICAgAAAAIAAAICAAACAAACAgAAAgAAAAIAAgABAgIAAQEAAAP+AAACAQAAA/wBAAABAgAD/ //8AwMDAAAAA/wAA//8AAP8AAP//AAD/AAAA/wD/AID//wCA/wAA//+AAP+AgACAAP8AQID/ ADQAAACPSFAAIwA0ACQAAQAuBK8Auv//AAAALgBaCwAAr0gEAAAEAAD+RwAAAABxACUA3gAG AQAAAACEAAAA+gAQAAAAAQAiAPdIAADvSAEAAADvAAAA9ADUhAAAAwD5ALN/5wCHFwAA3gAG APP/AAAAAI8AAAD3AGiJpwBgA9cABbUAAAkAYABgAAAAIADMAAABRgBWGDIAz0gaAAEAogDv SN4ABgH0AAIAeAACAAAAAAC/AASFNAAXBG8ABgF4AAIAHAAAIA8ANyACAAAABAAAANYANyCn AJiFGwBHBGgApwVgANcGIADMAM8ABgA3AFaFaABXIQEANyBZAJDDRwDWEjcANyDZABsWRwDW EnIAz0g0ACIANABTeXMAZWAAAM9IAAByhgIAFhsiAAEMOgAaiTIAFAKHAAAAzAAQhs8AFhsA ACIAAAAAANIA0hoAAKcFAAABAJUAnxb7AJEgAAA3IAAAAADoAAYOTwA3IDcAPIZnAEcgAACP SAAAAAD+AM9IAwBghiIA97/gABAABwC8AgAAAAABAAIiUwBzdGUAAHCuAADwrQBEYIMAKID3 AAByWACPAOUA/FMAAD8fAACe6gYApwVnAAAAXgAOFGcAEAFQABkUVgCnBSkArAr/ANAAEAAH AAAAAAC8AAECAgBlbQAAroEAAK2BRACDwygA978AAFiBAACtgQAAAADUAFsAnwAGhz8ArIG0 AK6B7ABZwBAAAQAAAAAAwACyfxcAtX/4APdILwAMh24AFwFkAC8BAAAaiQoAAAD8AFsA8AAv PAoAdAb2AGqHGgACAJgA8EgAAKhIAAAkh7IAFwG1AKhIAQAvAWYA4UoXAGQTLwBmhwAATocA AAAAWgC1f/AAp0gvAJSHbgAAAJQAAACgAAAApwAAAPAALwHvAAICvwBgsacAAPPwAF0AoAAA AKoAtX+gACl5AgAaiRoApwXsAKwRVwAOGxIAAgCYAAAAAAAAAAAAqBgAAChSAAAkh7IAFwG1 AChSAQAvAWYA4UoXAGQTLwCoGAAAKFIAAGaHAABOhxYAAAAAAAEAAAAAAMAAAABaALJ/FwC1 f6gAV1IvAJSHbgAXAWQALwEAAAAAwAAAAJQAAACEABbEUAAAAFcAAAABAAAAqAAAAAAALwHv AAICvwCAn1cAAPP4AF0AAAAAAKoAsn8XALV/AAApeb4ACqgKAKcF7ACsEVcAVhtmAA4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg8BAQEBAQEBDw4ODg4ODg4ODg8BAQEBAQEPDg4ODg4OAQ8B AQEBAQEPDg4ODg4ODg4OAQEBAQEBDw4ODg4ODg4ODgEBDwEBAQEODg4ODg4ODg8BAQEPAQEO Dg4ODg4ODg4ODgEBAQEBAQ8ODg4ODg4PAQEBAQEODg4ODg4ODg4ODg4ODg8BAQEBDw4ODg4O Dg8BAQEBDw4ODg4ODg4ODg4ODg4ODwEBAQEBDg4ODg4OAQEBAQEPDg4ODg4ODg4ODg4ODg4P AQEBAQEODg4ODg4BAQEBAQ8ODg4ODg4ODg4ODg4ODgEPAQEBAQ8ODg4ODwEBAQEBDg4ODg4O Dg4ODg4ODg4ODgEBAQEBAQ8ODg4BAQEBAQ8ODg4ODg4ODg4ODg4ODg4OAQEBAQEBDw4ODgEB AQEBDw4ODg4ODg4ODg4ODg4ODg4OAQEBAQEBDg4PAQEBAQEPDg4ODg4ODg4ODg4ODg4ODg4P AQEBAQEODg8BAQEBDw4ODg4ODg4ODg4ODg4ODg4ODg8BAQEBAQ8PAQEBAQEPDg4ODg4ODg4O Dg4ODg4ODg4ODgEBAQEBAQEBAQEBAQ4ODg4ODg4ODg4ODg4ODg4ODg4OAQEBAQEBAQEBAQEB Dg4ODg4ODg4ODg4ODg4ODg4ODg4PAQEBAQEBAQEBAQ8ODg4ODg4ODg4ODg4ODg4ODg4ODg8B AQEBAQEBAQEBDw4ODg4ODg4ODg4ODg4ODg4ODg4ODg8BAQEBAQEBAQEODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODwEBAQEBAQEBAQ4ODg4ODg4ODg4ODg4ODg4ODg4ODg4OAQEBAQEBAQEPDg4O Dg4ODg4ODg4ODg4ODg4ODg4ODwEBAQEBAQEBAQEPDg4ODg4ODg4ODg4ODg4PDw4ODg4PAQEB AQEBAQEBAQ8ODg4ODg8ODg4ODg4OAQEBDg4ODg8BAQEBAQEBAQEBDw4ODg4PAQEODg4ODg4P AQEPDg4ODwEBAQEBAQEBAQEPDg4ODwEBDg4ODg4ODg8BAQEODg4PAQEBAQEBAQEBAQ8ODg8B AQEPDg4ODg4ODgEBAQ8ODg8BAQEBAQEBAQEBDw4OAQEBAQ4ODg4ODg4ODwEBAQ8ODwEBAQEB AQEBAQEPDg8BAQEPDg4ODg4ODg4PAQEBAQ4PAQEBAQEBAQEBAQ8ODwEBAQ8ODg4ODg4ODg4P AQEBDw8BAQEBAQEBAQEBDw8BAQEBDg4ODg4ODg4ODg4BAQEBDwEBAQEBAQEBAQEPAQEBAQ8O Dg4ODg4ODg4ODg8BAQEPAQEBAQEBAQEBAQ8BAQEPDg4ODg4ODg4ODg4ODgEBAQ8BAQEBAQEB AQEBDwEBAQ4ODg4ODg4ODg4ODg4ODwEBAQEBAQEBAQEBAQEBAQEPDg4ODg4ODg4ODg4ODg4P AQEBAQEBAQEBAQEBAQEBAQ8ODg4ODg4ODg4ODg4ODg4PAQEBAQEBAQEBAQEBAQEBDg4ODg4O Dg4ODg4ODg4ODg4BAQEBAQEBAQEBAQEBAQ8ODg4ODg4ODg4ODg4ODg4ODg8BAQEBAQEBAQEB AQEPDg4ODg4ODg4ODg4ODg4ODg4ODg8PDw8BAQEBDw8PDw4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg8BAQEODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4PAQEBAQ8ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg8BAQEBAQ4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4OAQEBAQEBDg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4BAQEBAQEODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O DgEBAQEBAQ4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4OAQEBAQEBDg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4BAQEBAQ8ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4PDw8PDg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg6Qeh/wTQoAABF9aa/Irv1HNFS8tL5Y4PckT+fs6f0b7EctZuYl wj4c/ygAAAAsAAAAIwAAAAEACAAAAAAABAYAAM4OAADYDgAAAAEAAAAAAAAAAAAAgICAAAAA gAAAgIAAAIAAAICAAACAAAAAgACAAECAgABAQAAA/4AAAIBAAAD/AEAAAECAAP///wDAwMAA AAD/AAD//wAA/wAA//8AAP8AAAD/AP8AgP//AID/AAD//4AA/4CAAIAA/wBAgP8AMgoAAEdI BAAABB4AR0gAAAAAVwAJAJoAMwUAACUBmgABAysAAABCAIcSAAAAAAEAAQEBAAgAAgARAAEA //8DAAAAtwBChYcA5IynAORaxwDy/wAAAAAOACAAzAAAAQAABbUAAAkAYABgAAAAAAA4AKcF RgBWGDIAhxKWAAEANAAXBNEAAAGAAAIABAACAAAAAAD3AASFAAAAIG8AAQADAAAABQAAAEcA WodZANcD5ACnBeQAxwUgAMwAJAArAAAAtxOwAAAAhwAGADcAVoVoAFchAQA3IFkAkMNHAA4T NwA3INkAGxZHAA4TcgCHEkcAU3lzAGVgAAByhgIAnAAAAAcAAACMAAAAfQAAAJUGnwD7BpEA AAA3ABCGhwBPIAAANyAOAGe1RwDQAJUAnxb7AJEgAAA3IAAAAADoAAYOTwA3IDcAPIZnAEcg AAC3EwAAAAD+AIcSAwBghiIACQAOABAABwC8AgAAAiJTAHN0ZQAAIpYAAAAQAEjA1gABAPcA nADlAMpTAAA/HwAAnuoGAKcFZwAAAF4ADhRnABABbAAZFFYApwUpAKwK/wAOABAAAAC8AAEC AgBlbQAAlowAABCIAAAAAEgA1v8AAPe/nAAAAOEAUvdQACsAJAAsAAEAAADmAAgAEACugTQA WcAQAAEA8ACugRAAroEAAK2BAAAAADQAAKAAAK2BIACQwygAlowKAFiBAAAAAJwA97/+AC88 CgB0BvYAaocaAAIAmADgUgAAQEgAACSHsgAXAbUAQEgBAC8BZgDhShcAZBMvAGaHAABOhwAA AQAAAAAAwAAAAFoAsn8XALV/4AAXEy8AlIduABcBZAAvAQAAAACUAAAAhAAAABcAAADgAC8B 7wACAr8AoLUXAADz4ABdABAAAACqALV/EAApefYAloyWAKcF7ACsEVcA+hQOAAAClAAgAKgA AgCSAC88CgB0BvYA/oYaAAAAAAACAJgAAAAAAAAAAADwIQAAaEgAALiGsgAXAbUAaEgBAC8B +gDhShcAZBMvAPAhAABoSAAA+oYAAOKGAAAAAAAAAQAAAAAAwAAAAO4Asn8XALV/8AAvSS8A KIduABcBZAAvAQAAAADAAAAAKAAAABgAAAAoAAAALwAAAAEAAADwAAAAAAAvAe8AAgK/AECQ LwAA8/gAXQCwAAAAPgCyfxcAtX+wACl5ZgByiXIApwWAAKwRVwBCG8IADg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDwkODg4ODg4ODg4O Dg4ODg4PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PCQEODg4ODg4ODg4ODg4ODg8PDw8P Dw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8JAQ4ODg4ODg4ODg4ODg4ODw8PDw8PDw8PDw8PDw8P Dw8PDw8PDw8PDw8PDwkBAQkODg4ODg4ODg4ODg4PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dw8PCQEBAQkODg4ODg4ODg4ODg8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8JAQEBAQ4O Dg4ODg4ODg4OCQ8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8BAQEBCQ4ODg4ODg4ODg4O CQ8PDw8PDw8PDw8PDw8PCQ8PDw8PDw8PDw8PDwkBAQEBAQ4ODg4ODg4ODg4JDw8PDw8PDw8P Dw8PDw8JDw8PDw8PDw8PDw8PCQEBAQEBCQ4ODg4ODg4ODg4PDw8PDw8PDw8PDw8PDwkJDw8P Dw8PDw8PDw8PAQEBAQEBCQ4ODg4ODg4ODgkPDw8PDw8PDw8PDw8PCQEPDwkPDwkPDw8PDw8J AQEBAQEBCQ4ODg4ODg4ODg8PDw8PDw8PDwkJCQkJAQ8PDw8PDw8PDw8PDw8JAQEBAQEBDg4O Dg4ODg4OCQ8PDw8PDw8PCQ8PDw8BCQ8PDw8PCQ8PDw8PDw8BAQEBAQEODg4ODg4ODg4OCQ8P Dw8PDw8PCQ8PDwEBCQ8PDw8PCQ8PDw8PDwkBAQEBAQ4ODg4ODg4ODg4JDw8PDw8PDw8JDw8P CQEBDw8PDw8PDw8PDw8PCQEBAQEBDg4ODg4ODg4ODg4PDwkJCQkJCQgPDw8PAQEPDw8JCQ8J CQ8JCQ8PAQEBAQEODg4ODg4ODg4ODg4PDw8PCQ8PCQkPDw8JAQkPDw8PDw8PDw8PDw8PCQEB AQ4ODg4ODg4ODg4ODg8PDw8PDw8PDw8PDwkBAQ8PDw8PDw8PDw8PDw8JAQEBDg4ODg4ODg4O Dg4OCQ8JDg4ODg4OCQ8PDw8BCQ8PDwkJCQkJDwkJDw8BAQEODg4ODg4ODg4ODg4OCQ4ODg4O Dg4OCQ8PDwkBAQ8PDw8PCQ8PDw8PDwkBAQ4ODg4ODg4ODg4ODg4ODw4ODw4ODg4ODw8PCQEB CQkPDw8PDw8PDw8PDwEBDg4ODg4ODg4ODg4ODg4JDgkODw4ODg8JDw8PCQEBAQkPDw8PDw8P Dw8PCQEODg4ODg4ODg4ODg4ODg4PDg8ODg4ODg8PDw8PCQEBAQkPDw8PDw8PDw8PCQ4ODg4O Dg4ODg4ODg4ODg8ODg4ODg4ODgkPDw8PAQEBAQ8PDw8PDw8PDw8JDg4ODg4ODg4ODg4ODg4O CQ8PDw8PDw8PDw8PDw8JAQEBCQ8PDw8PDw8PDw8ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O DgkPDw8JAQEJDg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg8PDw8JAQkO Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4OCQ8PDw8BDg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODgkJCQkODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODpB6H/AxCgAAzO+VBF7JHCNkbjuKu0RsAsWsp1cctk2R145mPzAL v/D/KAAAACIAAAAqAAAAAQAIAAAAAADoBQAAzg4AANgOAAAAAQAAAAAAAAAAAACAgIAAAACA AACAgAAAgAAAgIAAAIAAAACAAIAAQICAAEBAAAD/gAAAgEAAAP8AQAAAQIAA////AMDAwAAA AP8AAP//AAD/AAD//wAA/wAAAP8A/wCA//8AgP8AAP//gAD/gIAAgAD/AECA/wDmCQAAPxME AAAEHgA/EwAAAABOAP9RRABGAgAArIQCAAE7IgAAAEIATzsAAAAAJwCyhPoAvxYEAAAA+QCz f8IABQEAAAAAhAAAAPoAEAAAABIAAAAAAGcAQoVPAFSQpwCIb8cA8/8AAAAADQAgAMwAAAEA AAW1AAAJAGAAYAAAAAAADACnBUYAVhgyAE87BgAAADQAFwQAAIQAhAACAIQAAgAAAAAAvwAE hQAAACBvAAEAAgAAAAQAAAA/AFqHWQDXA1QApwWIAMcFIADMACkAIgAAAGdSsAAAAE8ABgA3 AFaFaABXIQEANyBZAJDDRwDWEjcANyDZABsWRwDWEnIATzs/AFN5cwBlYAAAcoYCAJwAAAAH AAAAjAAAAH0AAACVBp8A+waRAAAANwAQhk8ATyAAADcgDgBntUcA0ACVAJ8W+wCRIAAANyAA AAAA6AAGDk8ANyA3ADyGZwBHIAAAZ1IAAAAA/gBPOwMAYIYiAAkADgAQAAcAvAIAAAAAAQAC IlMAc3RlAAAiBgAAABAASMDWAAEADAAAAOUAnFIAAD8fAACe6gYApwVnAAAAXgAOFGcAEAHM ABkUVgCnBSkArAr/AA4AEAAAALwAAQICAGVtAAAGkAAAEIgAAAAASADW/wAADAAAAM9I4QA6 9VAAIgApACIAAQAAAOQACAAUAAAA2ACugTQAWcAQAK6BFACugQAArYEAAACgAACtgTwAkcMo AAaQCgBYgQAAAACcAPe//gAvPAoAdAb2AGqHGgACAJgAqEgAADgTAAAkh7IAFwG1ADgTAQAv AWYA4UoXAGQTLwBmhwAATocAAAEAAAAAAMAAAABaALJ/FwC1f6gAx1IvAJSHbgAXAWQALwEA AAAAlAAAAMcAAACoAC8B7wACAr8AgK3HAADzqABdAMAAAACqALV/wAApeRYABpAGAKcF7ACs EVcAxhoSAHQG9gBqhxoAAAAAAAIAmAAAAAAAAAAAAPhHAADwRwAAJIeyABcBtQDwRwEALwFm AOFKFwBkEy8A+EcAAPBHAABmhwAATocAAAAAAAABAAAAAADAAAAAWgCyfxcAtX/4APdILwCU h24AFwFkAC8BAAAAAMAAAACUAAAAhAAAAPAAAAD3AAAAAQAAAPgAAAAAAC8B7wACAr8AIL33 AADz+ABeAOAAAACqALJ/FwC1f+AAKXmiAJ6NngCnBewArBFXAE4b/gAODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4OAAAODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4OAAAODg8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDg4ODg4OAAAODg8BAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEPDw8ODg4OAAAODg8JCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkPCQkP Dg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJ Dg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJ Dg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJ Dg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJ Dg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJ Dg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJ Dg4OAAAODg8BAQEBAQEBAQEBAQEPDw8PDw8PDw8PDw8PCQkJDg4OAAAODg8BAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJ Dg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJ Dg4OAAAODg8BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEBAQEJAQEBAQEBAQEBAQEPCQkJ Dg4OAAAODg8BAQEBAQEBAQEBAQEJAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BDwEPDw8PDw8P AQEJAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEBAQEJAQEBAQEBAQEBAQEPCQkJ Dg4OAAAODg8BAQEBAQEBAQEBAQEJAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8BAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEPCQkJDg4OAAAODg8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8PCQkJ Dg4OAAAODg4BAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBCQkJDg4OAAAODg4ODwEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEJDg4OAAAODg4ODg4PDw8PDw8PDw8PDw8PDw8PDw8PDw8PDw8P Dg4OAAAODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4OAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8A 6ANBCQAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAAB DwDyAyACAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1Qd8AQAAAAC3D0QAAABUAGkAbQBlAHMA IABOAGUAdwAgAFIAbwBtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQow AAAEEhAAtw9EAAAAQQByAGkAYQBsACAAQgBsAGEAYwBrAAAAbQBhAG4AAAAMtmIADLZiADS0 YgAEiQowWLRiAAgAAABYtGIAiokKMAAABCIgALcPRAAAAFQAYQBoAG8AbQBhAAAAbABhAGMA awAAAG0AYQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAQiMAC3D0QA AABNAG8AbgBvAHQAeQBwAGUAIABTAG8AcgB0AHMAAAAAAAy2YgAMtmIANLRiAASJCjBYtGIA CAAAAFi0YgCKiQowAgAEAkAAtw9EAAAAQQByAGkAYQBsAAAAcABlACAAUwBvAHIAdABzAAAA AAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABCIAAKkPCgAAAAcAAAACAAkE AABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8A AAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAA AAUAAIAEgAQAAAAADwALBJABAAAPAADwiAEAAAAABvBYAAAAByQAAAoAAABiAAAABwAAAAAA AAAHAAAAAQAAAAUAAAABAAAACAAAAAQAAAAIAAAAAwAAAAQAAAACAAAALAEAAAYAAAAEAAAA BwAAAAQAAAAIAAAABwAAAF8AAfDcAAAAYgAH8CQAAAAGBhHuxBfJvyhhPojfwyv4Diz/AA8N AAACAAAAAAAAAAAAywByAAfwJAAAAAcHTOB2FI1dsdmKFPPz3vhPwf8AMQsAAAIAAAAPDQAA AADLAHIAB/AkAAAABwfoVporQQAhCfwVCv44xxfK/wDxCgAAAQAAAEAYAAAAAMsAcgAH8CQA AAAHByRP5+zp/RvsRy1m5iXCPhz/AFUKAAADAAAAMSMAAAAAywByAAfwJAAAAAcHxaynVxy2 TZHXjmY/MAu/8P8AOQoAAAEAAACGLQAAAADLAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAA wAEBAAAI/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDzgAAAAAAPMD FAAAAAQAAAAEAAAAAAAAAAEAAIAAAAAAAADzAxQAAAAFAAAABAAAAAAAAAACAACAAAAAAA8A 0AfPAAAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAANgAAAGQAAAA2AAAAZAAAAGS0YgCK iQowXLRiAAgAAABmEgAAwAkAAOL8//+y////AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAA AAEAAABACwAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ABwQ8AAAAAAD9AzQAAAAh AAAAZAAAACEAAABkAAAADLZiAAy2YgABAAAAAAAAAMQRAABcCgAAAAAAAAAAAAAAAP//PwDZ DwwAAAAAANoPBAAAAAAAJQAPAPAPFgQAAAAA8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAA AJ8PBAAAAAYAAAAAAKgPGwAAAERpdmVyc2lvbiBJbmRpY2F0aW9uIGluIFNJUBAAnw8EAAAA BQAAAAAAqA8lAAAAU3RldmUgTGV2eQ1CcnlhbiBKLiBCeWVybHkNSi4gUi4gWWFuZwAA8wMU AAAACgAAAAQAAAADAAAABQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFgAAAFByb2JsZW0gYW5k IE9iamVjdGl2ZXMQAJ8PBAAAAAcAAAAAAKgPrgAAAFByb2JsZW0NVWx0aW1hdGVseSBjYWxs ZWQgKHRoaXJkLXBhcnR5KSBTSVAgdXNlciBhZ2VudCBpcyB1bmFibGUgdG8gcmVsaWFibHkg ZGV0ZXJtaW5lIGZyb20gd2hvbSB0aGUgY2FsbCB3YXMgZGl2ZXJ0ZWQgYW5kIHdoeSB0aGUg Y2FsbCB3YXMgZGl2ZXJ0ZWQuDUV4YW1wbGVzOiBWb2ljZW1haWwsIEFDRAAAoQ9SAAAACAAA AAAAAAAAAKcAAAABAAAAAAAIAAAAAAAAAE8AAAAAAAIAFAAJAAAAAQACAIEAFAAbAAAAAAAC ABQAAwAAAAEAAgCBABQAMQAAAAAAAgAUACAAnw8EAAAABwAAAAAAqA9iAAAAQ2hhbGxlbmdl cw1NdWx0aXBsZSBkaXZlcnNpb25zDVByaXZhdGUgbnVtYmVyaW5nIHBsYW5zDUludGVyb3Bl cmFiaWxpdHkgd2l0aCBsZWdhY3kgUFNUTiBkaXZlcnNpb24AAKEPJgAAAAsAAAAAAAAAAABY AAAAAQAAAAAACwAAAAAAAABYAAAAAAACABQAAADzAxQAAAAHAAAABAAAAAIAAAACAQAAAAAA AAAAnw8EAAAAAAAAAAAAqA8aAAAAQ0ZOQSB3aXRoIERpdmVyc2lvbiBoZWFkZXIAAKEPHAAA ABsAAAAAAAAAAAAaAAAAAAACACQAAQAAAAAAAAAQAJ8PBAAAAAEAAAAAAKoPCgAAAAEAAAAB AAAAAAAAAPMDFAAAAAgAAAAAAAAAAgAAAAMBAAAAAAAAAACfDwQAAAAAAAAAAACoDxMAAABQ cm9wb3NlZCBuZXh0IHN0ZXBzEACfDwQAAAABAAAAAACoDxwAAABTSVAgV0cgaXRlbQ1TdGFu ZGFyZHMgdHJhY2sNAACqDxIAAAAcAAAAAAAAAAEAAAABAAAAAAAAAPMDFAAAAAkAAAAAAAAA AgAAAAQBAAAAAAAAAACfDwQAAAAAAAAAAACoDxMAAABQcm9wb3NlZCBuZXh0IHN0ZXBzEACf DwQAAAABAAAAAACoDxwAAABTSVAgV0cgaXRlbQ1TdGFuZGFyZHMgdHJhY2sNAADqAwAAAAAP APgDqQkAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAAAAAYADwByAAAAAAAAAA///M AF5XTgD/zAAAzJkAAP9mAAD/AAAA///MAGAA8AcgAAAA////AAAAAABeV04AAAAAAP9mAAD/ zAAAmWYzAICAAABgAPAHIAAAAP///wAAAAAAOTk5AAAAAADLy8sAhoaGAE1NTQDq6uoAYADw ByAAAAD///8AAAAAAF5XTgCAAAAA/2YAAP/MAAD/AAAA///MAGAA8AcgAAAA////AAAAZgAA AAAAAAD/AABm/wAzzMwA/wD/AJkz/wBgAPAHIAAAAAAAZgD///8AAAAAAP/MAAAAZv8AM8zM AP8A/wCZM/8AYADwByAAAACAAAAA///MAF5XTgD/zAAAzJkAAP9mAAD/AAAA///MAAAAow8+ AAAAAQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wCAAAEA//// ////KAAAAAADAAAQAKMPgAAAAAUA//0/AAcAegADAGQAAAAABQAAZAAUAAAA2AAAAEACAAAA AAIAAAD//+8AgAACAP///////yAAAAAAAQAAgAUAAHkA1AEgAQAAAgAcAIAFAAB4ANACQAIA AAIAGACSBQAABQAiIAAA8ANgAwAAAgAUAIAFAAATIBAFgAQAAAAAIACjD24AAAAFAP/9PwAA ACIgAABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAACAAAA///vAIAAAAD///////8MAAAAAAEA AAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAEAAow9u AAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA//// ////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASA BAAAAABQAKMPUgAAAAUAAAABAQAABgAAAAAAAQABAAEAAQkAAAYAAQAgAQAAAAACAAEJAAAG AAEAQAIAAAAAAwABCQAABAABAGADAAAAAAQAAQkAAAQAAQCABAAAAABgAKMPDAAAAAEAAAAA AAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAHAABAAAAAAAAAAIAGAACAAAAAAAAAAIAFAAD AAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAACABgAAQAAAAAAAAAC ABQAAgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBFMFAAAPAALwSwUA ABAACPAIAAAABwAAAAcMAAAPAAPw0QQAAA8ABPAoAAAAAQAJ8BAAAADNBQAAmgYAAMMFAAD/ BgAAAgAK8AgAAAAADAAABQAAAA8ABPDGAAAAEgAK8AgAAAACDAAAAAoAAHMAC/AqAAAAfwAB AAEAgAC0KMcAhwACAAAAgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAACQAAABIBRg Aw8AEfAQAAAAAADDCwgAAAAAAAAAAQDHAA8ADfBUAAAAAACfDwQAAAAAAAAAAACoDyAAAABD bGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACqDwoAAAAh AAAAAQAAAAAADwAE8AoBAAASAArwCAAAAAMMAAAACgAAYwAL8CQAAAB/AAEAAQCAABQpxwCB AQQAAAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAKQEIAFAFegODwAR8BAAAAAAAMMLCAAA AAEAAAACAMcADwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFz dGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwN RmlmdGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8K AAAAUwAAAAEAAAAAAA8ABPC3AAAAEgAK8AgAAAAEDAAAAAoAAHMAC/AqAAAAfwABAAEAgAB0 KccAhwACAAAAgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAABUDxABwAV0EA8AEfAQ AAAAAADDCwgAAAACAAAABwHHAA8ADfBFAAAAAACfDwQAAAAEAAAAAACoDwEAAAAqAAChDxwA AAACAAAAAAAAIAAAMgACAAAAAAAHAAQADgAAAAACAAD4DwQAAAAAAAAADwAE8LkAAAASAArw CAAAAAUMAAAACgAAcwAL8CoAAAB/AAEAAQCAAKTyxwCHAAIAAACBAQQAAAi/AQEAEQDAAQEA AAj/AQEACQAAABDwCAAAAFQPsAfQDnQQDwAR8BAAAAAAAMMLCAAAAAMAAAAJAscADwAN8EcA AAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPHgAAAAIAAAAAAAAoAAABADIAAgAAAAAABwAE AA4AAAAAAgAA+g8EAAAAAAAAAA8ABPC5AAAAEgAK8AgAAAAGDAAAAAoAAHMAC/AqAAAAfwAB AAEAgAAE88cAhwACAAAAgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAABUD5AQQBV0 EA8AEfAQAAAAAADDCwgAAAAEAAAACALHAA8ADfBHAAAAAACfDwQAAAAEAAAAAACoDwEAAAAq AAChDx4AAAACAAAAAAAAKAAAAgAyAAIAAAAAAAcABAAOAAAAAAIAANgPBAAAAAAAAAAPAATw eAAAALIECvAIAAAABwwAAAAKAACTAAvwUAAAAH8AgACAAARBAQAAAAXBGgAAAAYBAQAAAAcB wMDAAIEBBAAACL8BAAAQAMABAQAACP8BAAAIAEEAOgBcAHAAYQBpAG4AdAAuAEcASQBGAAAA AAAQ8AgAAAA8A0ACgBYuBA8ABPBaAAAAEgAK8AgAAAABDAAAAAwAALMAC/BCAAAAgQEAAAAI kwGOn4sAlAHevWgAvwEeAB8A/wEAAAgAAQIAAAACBQKoKQEABgKoKQEAPwIDAAMABAMJAAAA PwMBAAEAEADwByAAAAD///8AAAAAAF5XTgAAAAAA/2YAAP/MAACZZjMAgIAAACAAug8yAAAA QwBvAG4AdABlAG0AcABvAHIAYQByAHkAIABQAG8AcgB0AHIAYQBpAHQALgBwAG8AdAAPAO4D XAUAAAIA7wMYAAAAAgAAAAMEBwkIAAAAAQAAgAAAAAAAAAAADwAMBAwFAAAPAALwBAUAAEAA CPAIAAAABwAAAAcQAAAPAAPwigQAAA8ABPAoAAAAAQAJ8BAAAACbBQAANwUAAAYAAACNBQAA AgAK8AgAAAAAEAAABQAAAA8ABPDGAAAAEgAK8AgAAAACEAAAAAoAAHMAC/AqAAAAfwABAAEA gADE9scAhwACAAAAgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAACwAUACQBWABA8A EfAQAAAAAADDCwgAAAAAAAAAAwDiAA8ADfBUAAAAAACfDwQAAAAGAAAAAACoDyAAAABDbGlj ayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACqDwoAAAAhAAAA AQAAAAAADwAE8MMAAAASAArwCAAAAAMQAAAACgAAYwAL8CQAAAB/AAEAAQCAAIT3xwCBAQQA AAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAJAJQAUAFewNDwAR8BAAAAAAAMMLCAAAAAEA AAAEAOIADwAN8FcAAAAAAJ8PBAAAAAUAAAAAAKgPIwAAAENsaWNrIHRvIGVkaXQgTWFzdGVy IHN1YnRpdGxlIHN0eWxlAACiDwYAAAAkAAAAAAAAAKoPCgAAACQAAAABAAAAAAAPAATwtwAA ABIACvAIAAAABBAAAAAKAABzAAvwKgAAAH8AAQABAIAA5PfHAIcAAgAAAIEBBAAACL8BAQAR AMABAQAACP8BAQAJAAAAEPAIAAAAVA/AAYAGmBAPABHwEAAAAAAAwwsIAAAAAgAAAAcB4gAP AA3wRQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8cAAAAAgAAAAAAACAAADIAAgAAAAAA BwAEAA4AXldO/gAA+A8EAAAAAAAAAA8ABPC5AAAAEgAK8AgAAAAFEAAAAAoAAHMAC/AqAAAA fwABAAEAgABE+McAhwACAAAAgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAABUD8AH wA6YEA8AEfAQAAAAAADDCwgAAAADAAAACQLiAA8ADfBHAAAAAACfDwQAAAAEAAAAAACoDwEA AAAqAAChDx4AAAACAAAAAAAAKAAAAQAyAAIAAAAAAAcABAAOAF5XTv4AAPoPBAAAAAAAAAAP AATwuQAAABIACvAIAAAABhAAAAAKAABzAAvwKgAAAH8AAQABAIAApPjHAIcAAgAAAIEBBAAA CL8BAQARAMABAQAACP8BAQAJAAAAEPAIAAAAVA9AEMAUmBAPABHwEAAAAAAAwwsIAAAABAAA AAgC4gAPAA3wRwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8eAAAAAgAAAAAAACgAAAIA MgACAAAAAAAHAAQADgBeV07+AADYDwQAAAAAAAAADwAE8HgAAACyBArwCAAAAAcQAAAACgAA kwAL8FAAAAB/AIAAgAAEQQEAAAAFwRoAAAAGAQEAAAAHAcDAwACBAQQAAAi/AQAAEADAAQEA AAj/AQAACABBADoAXABwAGEAaQBuAHQALgBHAEkARgAAAAAAEPAIAAAAgARAAoAWcgUPAATw WgAAABIACvAIAAAAARAAAAAMAACzAAvwQgAAAIEBAAAACJMBjp+LAJQB3r1oAL8BGgAfAP8B AAAIAAECAAAAAgUCqCkBAAYCqCkBAD8CAwADAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAA AABeV04AAAAAAP9mAAD/zAAAmWYzAICAAAAPAO4DyQIAAAIA7wMYAAAAAAAAAA8QAAAAAAAA AgAAgAAAAAAHAAAADwAMBHkCAAAPAALwcQIAADAACPAIAAAABAAAAAQIAAAPAAPwCQIAAA8A BPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPByAAAA EgAK8AgAAAACCAAAIAIAAFMAC/AeAAAABAAAAAAAgAAE+ccAvwEAAAEA/wEAAAEAAQMCEAAA AAAQ8AgAAACwAUACQBWABA8AEfAQAAAAAADDCwgAAAAAAAAADwDiAA8ADfAMAAAAAACeDwQA AAAAAAAADwAE8HIAAAASAArwCAAAAAMIAAAgAgAAUwAL8B4AAAAEAAAAAACAAGT5xwC/AQAA AQD/AQAAAQABAwMQAAAAABDwCAAAAJAJQAUAFewNDwAR8BAAAAAAAMMLCAAAAAEAAAAQAOIA DwAN8AwAAAAAAJ4PBAAAAAEAAAAPAATw3QAAAKIMCvAIAAAABAgAAAAKAACDAAvwMAAAAIAA JPrHAL8AAgACAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAA MAZwAhAUnQcPAA3wfQAAAAAAnw8EAAAABAAAAAAAqA8fAAAAZHJhZnQtbGV2eS1zaXAtZGl2 ZXJzaW9uLTAxLnR4dAAAoQ8gAAAAIAAAAAAAACgAAAEAMgAfAAAAAAACACAAAQAAAAAAAAAA AKoPGgAAABwAAAAAAAAAAwAAAAEAAAADAAEAAAAAAAAADwAE8EgAAAASAArwCAAAAAEIAAAA DAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/ AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwDuAzcDAAAC AO8DGAAAAAgAAAANDg4AAAAAAAEAAIAAAAAABwAAAA8ADATnAgAADwAC8N8CAACAAAjwCAAA AAUAAAAGJAAADwAD8HcCAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAI AAAAACQAAAUAAAAPAATwbAAAABIACvAIAAAAAiQAACACAABDAAvwGAAAAIAABPLiAL8BAAAB AP8BAAABAAEDAgwAAAAAEPAIAAAAkAAAASAUYAMPABHwEAAAAAAAwwsIAAAAAAAAAA0ANwEP AA3wDAAAAAAAng8EAAAAAAAAAA8ABPBsAAAAEgAK8AgAAAADJAAAIAIAAEMAC/AYAAAAgABE 8eIAvwEAAAEA/wEAAAEAAQMDDAAAAAAQ8AgAAADwAyABQBTQCA8AEfAQAAAAAADDCwgAAAAB AAAADgE3AQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8GwAAAASAArwCAAAAAQkAAAgAgAAQwAL 8BgAAACAAITw4gC/AQAAAQD/AQAAAQABAwMMAAAAABDwCAAAAAAJIAGQFfAMDwAR8BAAAAAA AMMLCAAAAAIAAAAOATcBDwAN8AwAAAAAAJ4PBAAAAAIAAAAPAATw4wAAABIACvAIAAAABiQA AAAKAABjAAvwJAAAAH8AAAABAIAA5PPiAIEBBAAACL8BAAARAMABAQAACP8BAAAJAAAAEPAI AAAAIA0gAZAVkA8PAA3wjwAAAAAAnw8EAAAABwAAAAAAqA9DAAAAR29hbA1FbmFibGUgdGhp cmQtcGFydHkgdXNlciBhZ2VudHMgdG8gcHJvdmlkZSBjdXN0b21pemVkIGZlYXR1cmVzLgAA oQ8wAAAABQAAAAAAAAAAAD8AAAABAAAAAAAEAAAAAAAAAAEAAAAAAAIAGAA/AAAAAAACABQA DwAE8EgAAAASAArwCAAAAAEkAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69 aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAXldOAAAAAAD/ZgAA /8wAAJlmMwCAgAAADwDuAwckAAACAO8DGAAAAAEAAAANDgAAAAAAAAEAAIAAAAAABwAAAA8A DAS3IwAADwAC8K8jAAAgAAjwCAAAAEUAAAArGQAAEAAY8QQAAAABAAAADwAD8DsjAAAPAATw KAAAAAEACfAQAAAA0A4AAHQQAAAAAAAAsAAAAAIACvAIAAAAABgAAAUAAAAPAATwbAAAABIA CvAIAAAAAhgAACACAABDAAvwGAAAAIAAJPTHAL8BAAABAP8BAAABAAEDAgwAAAAAEPAIAAAA kACQAMASQAIPABHwEAAAAAAAwwsIAAAAAAAAAA0A4gAPAA3wDAAAAAAAng8EAAAAAAAAAA8A A/CPIgAADwAE8DgAAAABAAnwEAAAAHACAABwAgAAAxMAAJoPAAACAArwCAAAACsZAAABAgAA AAAQ8AgAAABwAnACAxOaDw8ABPC5AAAAogwK8AgAAADnGAAAAgoAALMAC/BCAAAAfwAAAAQA gAB0muIAvwAAAAcAvwEMAB4AywFqSgAA/wEGAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8A iAMBAAAAAAAP8BAAAABwAgAAcAIAAFAEAABgAwAADwAN8D8AAAAAAJ8PBAAAAAQAAAAAAKgP BQAAAEFsaWNlAAChDx4AAAAGAAAAAAAAAAAABQAAAAAAAgAQAAEAAAAAAAIADgAPAATwrQAA AKIMCvAIAAAA6BgAAAIKAACzAAvwQgAAAH8AAAAEAIAA1JriAL8AAAAHAL8BDAAeAMsBakoA AP8BBgAOAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAIgDAQAAAAAAD/AQAAAAgA0AAHACAADa DgAAVwMAAA8ADfAzAAAAAACfDwQAAAAEAAAAAACoDwMAAABCb2IAAKEPFAAAAAQAAAAAAAAA AAAEAAAAAAACABAADwAE8K8AAACiDArwCAAAAOkYAAACCgAAswAL8EIAAAB/AAAABACAADSb 4gC/AAAABwC/AQwAHgDLAWpKAAD/AQYADgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCIAwEA AAAAAA/wEAAAAHARAABwAgAAAxMAAFcDAAAPAA3wNQAAAAAAnw8EAAAABAAAAAAAqA8FAAAA Q2Fyb2wAAKEPFAAAAAYAAAAAAAAAAAAGAAAAAAACABAADwAD8LAcAAAPAATwQAAAAAEACfAQ AAAAxgIAAIgGAACGEgAA4hAAAAIACvAIAAAAIRkAAAMCAAAAAA/wEAAAADADAABABQAA8BIA AJoPAAAPAAPwugEAAA8ABPBaAAAAAQAJ8BAAAABQBwAAEBcAABApAABQKwAAAgAK8AgAAADe GAAAAwIAADMAC/ASAAAABAAAAAAAfwAAAAQAiAMBAAAAAAAP8BAAAABgAwAANQcAAOAQAADi EAAADwAE8E4AAABCAQrwCAAAAN8YAAACCgAAUwAL8B4AAABEAQQAAAB/AQAAAQC/AQAAEADL AWpKAAD/ARAAEAAAAA/wEAAAAFAHAAAQFwAAUAcAAFArAAAPAATwTgAAAEIBCvAIAAAA4BgA AAIKAABTAAvwHgAAAEQBBAAAAH8BAAABAL8BAAAQAMsBakoAAP8BEAAQAAAAD/AQAAAA0B0A ABAXAADQHQAAUCsAAA8ABPBOAAAAQgEK8AgAAADhGAAAAgoAAFMAC/AeAAAARAEEAAAAfwEA AAEAvwEAABAAywFqSgAA/wEQABAAAAAP8BAAAACQEgAAEBcAAJASAABQKwAADwAE8E4AAABC AQrwCAAAAOIYAAACCgAAUwAL8B4AAABEAQQAAAB/AQAAAQC/AQAAEADLAWpKAAD/ARAAEAAA AA/wEAAAABApAAAQFwAAECkAAFArAAAPAATwqQAAAKIMCvAIAAAA4xgAAAIKAACTAAvwNgAA AH8AAAAEAIAA5O3iAL8AAAAHAL8BDAAeAMsBakoAAP8BBgAOAD8CAAADAH8DAAAPAIgDAQAA AAAAD/AQAAAAxgIAAIgGAADtBQAAbgcAAA8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwsAAABT SVAgUGhvbmUgQQAAoQ8UAAAADAAAAAAAAAAAAAwAAAAAAAIADgAPAATwqQAAAKIMCvAIAAAA 5BgAAAIKAACTAAvwNgAAAH8AAAAEAIAA1IniAL8AAAAHAL8BDAAeAMsBakoAAP8BBgAOAD8C AAADAH8DAAAPAIgDAQAAAAAAD/AQAAAA0wYAAIgGAAD6CQAAbgcAAA8ADfA7AAAAAACfDwQA AAAEAAAAAACoDwsAAABTSVAgUHJveHkgMQAAoQ8UAAAADAAAAAAAAAAAAAwAAAAAAAIADgAP AATwqQAAAKIMCvAIAAAA5RgAAAIKAACTAAvwNgAAAH8AAAAEAIAAtIjiAL8AAAAHAL8BDAAe AMsBakoAAP8BBgAOAD8CAAADAH8DAAAPAIgDAQAAAAAAD/AQAAAAYA8AAIgGAACGEgAAbgcA AA8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwsAAABTSVAgUGhvbmUgQwAAoQ8UAAAADAAAAAAA AAAAAAwAAAAAAAIADgAPAATwqQAAAKIMCvAIAAAA5hgAAAIKAACTAAvwNgAAAH8AAAAEAIAA FJriAL8AAAAHAL8BDAAeAMsBakoAAP8BBgAOAD8CAAADAH8DAAAPAIgDAQAAAAAAD/AQAAAA GgsAAIgGAABADgAAbgcAAA8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwsAAABTSVAgUGhvbmUg QgAAoQ8UAAAADAAAAAAAAAAAAAwAAAAAAAIADgAPAAPw2hcAAA8ABPBaAAAAAQAJ8BAAAABw CAAAoBcAAAAtAABALwAAAgAK8AgAAADqGAAAAwIAADMAC/ASAAAABAAAAAAAfwAAAAQAiAMB AAAAAAAP8BAAAABgAwAANQcAAAASAACoEAAADwAD8MsJAAAPAATwTgAAAAEACfAQAAAAcAgA AKAXAABwIwAAMCEAAAIACvAIAAAA6xgAAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAcAgA AKAXAABwIwAAMCEAAA8AA/COAQAADwAE8FQAAAABAAnwEAAAAFAHAACgFwAAoBcAAOAZAAAC AArwCAAAAOwYAAADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAAHAIAACgFwAAwBgA AOAZAAAPAATwcgAAAEIBCvAIAAAA7RgAAAIKAACzAAvwQgAAAL8AAAAHAEQBBAAAAH8BAAAB AL8BAAAQAMsBakoAANEBAQAAAP8BHgAeAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQ AAAAUAcAAFAZAACQEgAAUBkAAA8ABPCwAAAAogwK8AgAAADuGAAAAgoAAJMAC/A2AAAAgAD0 m+IAvwAAAAcAvwEAABAAywFqSgAA/wEGAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP 8BAAAABQBwAAoBcAAKAXAADgGQAADwAN8EIAAAAAAJ8PBAAAAAQAAAAAAKgPEgAAACBJTlZJ VEUgc2lwOkJvYkBQMQAAoQ8UAAAAEwAAAAAAAAAAABMAAAAAAAIAEgAPAAPwhwEAAA8ABPBU AAAAAQAJ8BAAAABQBwAAUBkAALATAACQGwAAAgAK8AgAAADvGAAAAwIAACMAC/AMAAAABAAA AAAAiAMAAAAAAAAP8BAAAABwCAAAUBkAANAUAACQGwAADwAE8HIAAABCAQrwCAAAAPAYAABC CgAAswAL8EIAAAC/AAAABwBEAQQAAAB/AQAAAQC/AQAAEADLAWpKAADRAQEAAAD/AR4AHgA/ AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAFAHAAAAGwAAkBIAAAAbAAAPAATwqQAA AKIMCvAIAAAA8RgAAAIKAACTAAvwNgAAAIAAtJziAL8AAAAHAL8BAAAQAMsBakoAAP8BBgAO AD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAUAcAAFAZAACwEwAAkBsAAA8ADfA7 AAAAAACfDwQAAAAEAAAAAACoDwsAAAAgMTAwIFRyeWluZwAAoQ8UAAAADAAAAAAAAAAAAAwA AAAAAAIAEgAPAAPwjQEAAA8ABPBUAAAAAQAJ8BAAAACQEgAAcBoAAFAiAACwHAAAAgAK8AgA AADyGAAAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAACwEwAAcBoAAHAjAACwHAAA DwAE8HIAAABCAQrwCAAAAPMYAAACCgAAswAL8EIAAAC/AAAABwBEAQQAAAB/AQAAAQC/AQAA EADLAWpKAADRAQEAAAD/AR4AHgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAJAS AAAgHAAA0B0AACAcAAAPAATwrwAAAKIMCvAIAAAA9BgAAAIKAACTAAvwNgAAAIAAdJ3iAL8A AAAHAL8BAAAQAMsBakoAAP8BBgAOAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAA kBIAAHAaAABQIgAAsBwAAA8ADfBBAAAAAACfDwQAAAAEAAAAAACoDxEAAAAgSU5WSVRFIHNp cDpCb2JAQgAAoQ8UAAAAEgAAAAAAAAAAABIAAAAAAAIAEgAPAAPwhwEAAA8ABPBUAAAAAQAJ 8BAAAACQEgAAIBwAAPAeAABgHgAAAgAK8AgAAAD1GAAAAwIAACMAC/AMAAAABAAAAAAAiAMA AAAAAAAP8BAAAACwEwAAIBwAABAgAABgHgAADwAE8HIAAABCAQrwCAAAAPYYAABCCgAAswAL 8EIAAAC/AAAABwBEAQQAAAB/AQAAAQC/AQAAEADLAWpKAADRAQEAAAD/AR4AHgA/AgAAAwC/ AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAJASAADQHQAA0B0AANAdAAAPAATwqQAAAKIMCvAI AAAA9xgAAAIKAACTAAvwNgAAAIAANJ7iAL8AAAAHAL8BAAAQAMsBakoAAP8BBgAOAD8CAAAD AL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAkBIAACAcAADwHgAAYB4AAA8ADfA7AAAAAACf DwQAAAAEAAAAAACoDwsAAAAgMTAwIFRyeWluZwAAoQ8UAAAADAAAAAAAAAAAAAwAAAAAAAIA EgAPAAPwjgEAAA8ABPBUAAAAAQAJ8BAAAACQEgAAwCEAAPAeAAAAJAAAAgAK8AgAAAD4GAAA AwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAACwEwAA0B0AABAgAAAQIAAADwAE8HIA AABCAQrwCAAAAPkYAABCCgAAswAL8EIAAAC/AAAABwBEAQQAAAB/AQAAAQC/AQAAEADLAWpK AADRAQEAAAD/AR4AHgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAJASAABwIwAA 0B0AAHAjAAAPAATwsAAAAKIMCvAIAAAA+hgAAAIKAACjAAvwPAAAAIAA9J7iAIoA+hgAAL8A AAAHAL8BAAAQAMsBakoAAP8BBgAOAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAA kBIAAMAhAADwHgAAACQAAA8ADfA8AAAAAACfDwQAAAAEAAAAAACoDwwAAAAgMTgwIFJpbmdp bmcAAKEPFAAAAA0AAAAAAAAAAAANAAAAAAACABIADwAD8I4BAAAPAATwVAAAAAEACfAQAAAA 0B0AAKAgAAAwKgAA4CIAAAIACvAIAAAA+xgAAAMCAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAA D/AQAAAAcAgAAPAeAADQFAAAMCEAAA8ABPByAAAAQgEK8AgAAAD8GAAAQgoAALMAC/BCAAAA vwAAAAcARAEEAAAAfwEAAAEAvwEAABAAywFqSgAA0QEBAAAA/wEeAB4APwIAAAMAvwIBAA8A /wIWAB8AfwMAAA8AAAAP8BAAAADQHQAAUCIAABApAABQIgAADwAE8LAAAACiDArwCAAAAP0Y AAACCgAAowAL8DwAAACAALSf4gCKAP0YAAC/AAAABwC/AQAAEADLAWpKAAD/AQYADgA/AgAA AwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAANAdAACgIAAAMCoAAOAiAAAPAA3wPAAAAAAA nw8EAAAABAAAAAAAqA8MAAAAIDE4MCBSaW5naW5nAAChDxQAAAANAAAAAAAAAAAADQAAAAAA AgASAA8AA/C/BQAADwAE8E4AAAABAAnwEAAAAHAIAAAwKgAAAC0AAEAvAAACAArwCAAAAP4Y AAADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAHAIAAAwKgAAAC0AAEAvAAAPAAPwgAEAAA8A BPBUAAAAAQAJ8BAAAABQBwAAECkAABApAABQKwAAAgAK8AgAAAD/GAAAAwIAACMAC/AMAAAA BAAAAAAAiAMAAAAAAAAP8BAAAABwCAAAAC0AADAqAABALwAADwAE8HIAAABCAQrwCAAAAAAZ AAACCgAAswAL8EIAAAC/AAAABwBEAQQAAAB/AQAAAQC/AQAAEADLAWpKAADRAQEAAAD/AR4A HgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAFAHAADAKgAAECkAAMAqAAAPAATw ogAAAKIMCvAIAAAAARkAAAIKAACTAAvwNgAAAIAAFKDiAL8AAAAHAL8BAAAQAMsBakoAAP8B BgAOAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAUAcAABApAACwEwAAUCsAAA8A DfA0AAAAAACfDwQAAAAEAAAAAACoDwQAAAAgQUNLAAChDxQAAAAFAAAAAAAAAAAABQAAAAAA AgASAA8AA/CJAQAADwAE8FQAAAABAAnwEAAAAJASAAAgJQAAECkAAGAnAAACAArwCAAAAAIZ AAADAgAAIwAL8AwAAAAEAAAAAACIAwAAAAAAAA/wEAAAALATAAAwKgAAMCoAAHAsAAAPAATw cgAAAEIBCvAIAAAAAxkAAEIKAACzAAvwQgAAAL8AAAAHAEQBBAAAAH8BAAABAL8BAAAQAMsB akoAANEBAQAAAP8BHgAeAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAkBIAANAm AAAQKQAA0CYAAA8ABPCrAAAAogwK8AgAAAAEGQAAAgoAAKMAC/A8AAAAgAB0oOIAigAEGQAA vwAAAAcAvwEAABAAywFqSgAA/wEGAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAA AACQEgAAICUAAPAeAABgJwAADwAN8DcAAAAAAJ8PBAAAAAQAAAAAAKgPBwAAACAyMDAgT0sA AKEPFAAAAAgAAAAAAAAAAAAIAAAAAAACABIADwAD8IkBAAAPAATwVAAAAAEACfAQAAAA0B0A AAAkAAAwKgAAQCYAAAIACvAIAAAABRkAAAMCAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQ AAAAcAgAAFArAADQFAAAkC0AAA8ABPByAAAAQgEK8AgAAAAGGQAAQgoAALMAC/BCAAAAvwAA AAcARAEEAAAAfwEAAAEAvwEAABAAywFqSgAA0QEBAAAA/wEeAB4APwIAAAMAvwIBAA8A/wIW AB8AfwMAAA8AAAAP8BAAAADQHQAAsCUAABApAACwJQAADwAE8KsAAACiDArwCAAAAAcZAAAC CgAAowAL8DwAAACAANSg4gCKAAcZAAC/AAAABwC/AQAAEADLAWpKAAD/AQYADgA/AgAAAwC/ AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAANAdAAAAJAAAMCoAAEAmAAAPAA3wNwAAAAAAnw8E AAAABAAAAAAAqA8HAAAAIDIwMCBPSwAAoQ8UAAAACAAAAAAAAAAAAAgAAAAAAAIAEgAPAATw twAAAKIMCvAIAAAACBkAAAIKAACTAAvwNgAAAIAANKHiAL8AAAAHAL8BDAAeAMsBakoAAP8B BgAOAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAYCcAADAqAAAALQAA4CsAAA8A DfBJAAAAAACfDwQAAAAEAAAAAACoDwcAAABvZmZob29rAAChDxQAAAAIAAAAAAAAAAAACAAA AAAAAgAOAAAAqg8KAAAACAAAAAEAAAADAA8AA/DWBwAADwAE8E4AAAABAAnwEAAAAHAIAABQ IgAA4CsAAMAqAAACAArwCAAAAAkZAAADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAHAIAABQ IgAA4CsAAMAqAAAPAAPwhwEAAA8ABPBUAAAAAQAJ8BAAAACQEgAAkCQAABApAADQJgAAAgAK 8AgAAAAKGQAAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAACwEwAAsCUAADAqAADw JwAADwAE8HIAAABCAQrwCAAAAAsZAABCCgAAswAL8EIAAAC/AAAABwBEAQQAAAB/AQAAAQC/ AQAAEADLAWpKAADRAQEAAAD/AR4AHgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAA AJASAABAJgAAECkAAEAmAAAPAATwqQAAAKIMCvAIAAAADBkAAAIKAACTAAvwNgAAAIAA9KHi AL8AAAAHAL8BAAAQAMsBakoAAP8BBgAOAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQ AAAAkBIAAJAkAADwHgAA0CYAAA8ADfA7AAAAAACfDwQAAAAEAAAAAACoDwsAAAAgMTAwIFRy eWluZwAAoQ8UAAAADAAAAAAAAAAAAAwAAAAAAAIAEgAPAAPwjgEAAA8ABPBUAAAAAQAJ8BAA AACQEgAAQCYAABApAACAKAAAAgAK8AgAAAANGQAAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAA AAAP8BAAAACwEwAAYCcAADAqAACgKQAADwAE8HIAAABCAQrwCAAAAA4ZAABCCgAAswAL8EIA AAC/AAAABwBEAQQAAAB/AQAAAQC/AQAAEADLAWpKAADRAQEAAAD/AR4AHgA/AgAAAwC/AgEA DwD/AhYAHwB/AwAADwAAAA/wEAAAAJASAADwJwAAECkAAPAnAAAPAATwsAAAAKIMCvAIAAAA DxkAAAIKAACjAAvwPAAAAIAAtKLiAIoADxkAAL8AAAAHAL8BAAAQAMsBakoAAP8BBgAOAD8C AAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAkBIAAEAmAADwHgAAgCgAAA8ADfA8AAAA AACfDwQAAAAEAAAAAACoDwwAAAAgMTgwIFJpbmdpbmcAAKEPFAAAAA0AAAAAAAAAAAANAAAA AAACABIADwAD8I4BAAAPAATwVAAAAAEACfAQAAAAUAcAAEAmAACwEwAAgCgAAAIACvAIAAAA EBkAAAMCAAAjAAvwDAAAAAQAAAAAAIgDAAAAAAAAD/AQAAAAcAgAAIAoAADQFAAAwCoAAA8A BPByAAAAQgEK8AgAAAARGQAAQgoAALMAC/BCAAAAvwAAAAcARAEEAAAAfwEAAAEAvwEAABAA ywFqSgAA0QEBAAAA/wEeAB4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAABQBwAA 8CcAAJASAADwJwAADwAE8LAAAACiDArwCAAAABIZAAACCgAAowAL8DwAAACAAHSj4gCKABIZ AAC/AAAABwC/AQAAEADLAWpKAAD/AQYADgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/w EAAAAFAHAABAJgAAsBMAAIAoAAAPAA3wPAAAAAAAnw8EAAAABAAAAAAAqA8MAAAAIDE4MCBS aW5naW5nAAChDxQAAAANAAAAAAAAAAAADQAAAAAAAgASAA8AA/C9AgAADwAE8E4AAAABAAnw EAAAALATAABQIgAA4CsAAEAmAAACAArwCAAAABMZAAADAgAAEwAL8AYAAACIAwAAAAAAAA/w EAAAALATAABQIgAA4CsAAEAmAAAPAAPwjwEAAA8ABPBUAAAAAQAJ8BAAAACQEgAA4CIAABAp AAAgJQAAAgAK8AgAAAAUGQAAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAACwEwAA UCIAADAqAACQJAAADwAE8HIAAABCAQrwCAAAABUZAAACCgAAswAL8EIAAAC/AAAABwBEAQQA AAB/AQAAAQC/AQAAEADLAWpKAADRAQEAAAD/AR4AHgA/AgAAAwC/AgEADwD/AhYAHwB/AwAA DwAAAA/wEAAAAJASAACQJAAAECkAAJAkAAAPAATwsQAAAKIMCvAIAAAAFhkAAAIKAACTAAvw NgAAAIAANKTiAL8AAAAHAL8BAAAQAMsBakoAAP8BBgAOAD8CAAADAL8CAQAPAP8CFgAfAH8D AAAPAAAAD/AQAAAAkBIAAOAiAACgIAAAICUAAA8ADfBDAAAAAACfDwQAAAAEAAAAAACoDxMA AAAgSU5WSVRFIHNpcDpDYXJvbEBDAAChDxQAAAAUAAAAAAAAAAAAFAAAAAAAAgASAA8ABPDI AAAAogwK8AgAAAAXGQAAAgoAAIMAC/AwAAAAgACUpOIAvwAAAAcAgQEAAP8AvwEMAB4AywFq SgAA/wEGAA4APwIAAAMAfwMAAA8AAAAP8BAAAACwEwAAACQAAOArAABAJgAADwAN8GAAAAAA AJ8PBAAAAAQAAAAAAKgPLAAAACBEaXZlcnNpb246IDxzaXA6Qm9iQFAxPiA7cmVhc29uPSJu by1hbnN3ZXIiAAChDxgAAAAtAAAAAAAAAAAALQAAAAAABgAOAAAA//4PAATwZgAAALIECvAI AAAAGRkAAAIKAABjAAvwNgAAAH8AAAAEAARBAgAAAAXBEgAAAAYBAgAAAP8BAAAIAIgDAQAA AG0AYQBuADEALgBiAG0AcAAAAAAAD/AQAAAAoAIAADADAACkAwAA4AQAAA8ABPByAAAAsgQK 8AgAAAAeGQAAAgoAAGMAC/BCAAAAfwAAAAQABEEDAAAABcEeAAAABgECAAAA/wEAAAgAiAMB AAAAcwBpAHAAXwBwAGgAbwBuAGUAMQAuAGIAbQBwAAAAAAAP8BAAAACwDQAAMAMAALcOAACw BAAADwAE8LYAAACyBArwCAAAACUZAAACCgAAQwAL8IYAAAB/AIAAgAAEQQUAAAAFwW4AAAAG AQEAAABDADoAXABiAHkAZQByAGwAeQBcAGIAeQBlAHIAbAB5AFwAaQBuAHQAZQByAG4AZQB0 AC0AZAByAGEAZgB0AHMAXABpAGUAdABmADQAOQBcAHMAaQBwAF8AcAByAG8AeAB5ADEALgBi AG0AcAAAAAAAD/AQAAAAEAgAACAEAADbCAAAGgUAAA8ABPBsAAAAsgQK8AgAAAAmGQAAAgoA AFMAC/A8AAAAfwAAAAQABEEEAAAABcEeAAAABgECAAAA/wEAAAgAcwBpAHAAXwBwAHIAbwB4 AHkAMQAuAGIAbQBwAAAAAAAP8BAAAACwEAAAUAQAAMERAABABQAADwAE8GwAAACyBArwCAAA ACgZAAACCgAAUwAL8DwAAAB/AAAABAAEQQQAAAAFwR4AAAAGAQIAAAD/AQAACABzAGkAcABf AHAAcgBvAHgAeQAxAC4AYgBtAHAAAAAAAA/wEAAAAGAMAABQBAAAcQ0AAEAFAAAPAATwbAAA ALIECvAIAAAAKRkAAAIKAABTAAvwPAAAAH8AAAAEAARBBAAAAAXBHgAAAAYBAgAAAP8BAAAI AHMAaQBwAF8AcAByAG8AeAB5ADEALgBiAG0AcAAAAAAAD/AQAAAAwAMAAFAEAADRBAAAQAUA AA8ABPBgAAAAsgQK8AgAAAAqGQAAAgoAAFMAC/AwAAAAfwAAAAQABEECAAAABcESAAAABgEC AAAA/wEAAAgAbQBhAG4AMQAuAGIAbQBwAAAAAAAP8BAAAADQEQAAMAMAANQSAADgBAAADwAE 8EgAAAASAArwCAAAAAEYAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAXldOAAAAAAD/ZgAA/8wA AJlmMwCAgAAADwDuA9gBAAACAO8DGAAAAAEAAAANDgAAAAAAAAEAAIAAAAAABwAAAA8ADASI AQAADwAC8IABAABgAAjwCAAAAAMAAAADHAAADwAD8BgBAAAPAATwKAAAAAEACfAQAAAAAAAA ACgBAAAAAAAAAAAAAAIACvAIAAAAABwAAAUAAAAPAATwbAAAABIACvAIAAAAAhwAACACAABD AAvwGAAAAIAARPTiAL8BAAABAP8BAAABAAEDAgwAAAAAEPAIAAAAkAAAASAUYAMPABHwEAAA AAAAwwsIAAAAAAAAAA0ANwEPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPBsAAAAEgAK8AgAAAAD HAAAIAIAAEMAC/AYAAAAgAAE+OIAvwEAAAEA/wEAAAEAAQMDDAAAAAAQ8AgAAACkBCABQBXo Dg8AEfAQAAAAAADDCwgAAAABAAAADgA3AQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAAS AArwCAAAAAEcAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/ AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAXldOAAAAAAD/ZgAA/8wAAJlmMwCA gAAADwDuA9gBAAACAO8DGAAAAAEAAAANDgAAAAAAAAEAAIAAAAAABwAAAA8ADASIAQAADwAC 8IABAABwAAjwCAAAAAMAAAADIAAADwAD8BgBAAAPAATwKAAAAAEACfAQAAAAbAEAABMBAAB5 ASwABAAAAAIACvAIAAAAACAAAAUAAAAPAATwbAAAABIACvAIAAAAAiAAACACAABDAAvwGAAA AIAAxPLiAL8BAAABAP8BAAABAAEDAgwAAAAAEPAIAAAAkAAAASAUYAMPABHwEAAAAAAAwwsI AAAAAAAAAA0ANwEPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPBsAAAAEgAK8AgAAAADIAAAIAIA AEMAC/AYAAAAgACE8+IAvwEAAAEA/wEAAAEAAQMDDAAAAAAQ8AgAAACkBCABQBXoDg8AEfAQ AAAAAADDCwgAAAABAAAADgA3AQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAA AAEgAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAE AwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAXldOAAAAAAD/ZgAA/8wAAJlmMwCAgAAAAABy FywAAAABABAAAAAAAAMAMABeGAAASQkAAPoSAAAHAEAAbh4AAH1CAABdRAAALxsAAAAA9Q8c AAAAAAEAAJIOAAMAAAAAPUYAAAEAAAAKAAAAAQBiAA8A6ANBCQAAAQDpAygAAACAFgAA4BAA AOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyAyACAAAvAMgPDAAAADAA0g8E AAAAAAAAAA8A1Qd8AQAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAA AAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAEEhAAtw9EAAAAQQByAGkAYQBs ACAAQgBsAGEAYwBrAAAAbQBhAG4AAAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokK MAAABCIgALcPRAAAAFQAYQBoAG8AbQBhAAAAbABhAGMAawAAAG0AYQBuAAAADLZiAAy2YgA0 tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAQiMAC3D0QAAABNAG8AbgBvAHQAeQBwAGUAIABT AG8AcgB0AHMAAAAAAAy2Yv7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuR CAArJ7PZMAAAAGxiAAANAAAAAQAAAHAAAAACAAAAeAAAAAQAAACcAAAABwAAALAAAAAIAAAA FAEAAAkAAAAoAQAAEgAAADQBAAAKAAAAVAEAAAsAAABgAQAADAAAAGwBAAANAAAAeAEAAA8A AACEAQAAEQAAAIwBAAACAAAA5AQAAB4AAAAcAAAARGl2ZXJzaW9uIEluZGljYXRpb24gaW4g U0lQAB4AAAALAAAATWVkc2Nob2xhcgBuHgAAAFsAAABDOlxQcm9ncmFtIEZpbGVzXE1pY3Jv c29mdCBPZmZpY2VcVGVtcGxhdGVzXFByZXNlbnRhdGlvbiBEZXNpZ25zXENvbnRlbXBvcmFy eSBQb3J0cmFpdC5wb3QAAB4AAAALAAAATWVkc2Nob2xhcgBGHgAAAAMAAAAzNQBzHgAAABUA AABNaWNyb3NvZnQgUG93ZXJQb2ludABvc29AAAAAYAOd7yMAAABAAAAAoNps+UViwAFAAAAA QNBA1Q9iwAFAAAAAIO2aIEpiwAEDAAAApwAAAEcAAADYYAAA/////wMAAAAIAG8QTQwAAAEA CQAAA2QwAAAGAKInAAAAABEAAAAmBg8AGAD/////AAAQAAAAAAAAAAAAugMAAMoCAAAJAAAA JgYPAAgA/////wIAAAAXAAAAJgYPACMA/////wQAGwBUTlBQFABo2wAwAAAAABQAAABEDccA AAAAALoACgAAACYGDwAKAFROUFAAAAIA9AMJAAAAJgYPAAgA/////wMAAAAPAAAAJgYPABQA VE5QUAQADAABAAAAAQAAAAAAAAAFAAAACwIAAAAABQAAAAwCygK6AwQAAAAEAQ0AEAAAACYG DwAWAP////8AAAAAAAAAAAAAyAMAANgCAAAJAAAA+gIFAAAAAAD///8AIgAEAAAALQEAAAcA AAD8AgAAAAAAAgAABAAAAC0BAQAEAAAALQEBAAkAAAAdBiEA8ADQAsADCAAIAAQAAAAtAQEA CQAAAPoCAAAAAAAAAAAAACIABAAAAC0BAgAHAAAA/AIAAP///wAAAAQAAAAtAQMABAAAAPAB AQAEAAAALQEAAAQAAAAtAQMABAAAAC0BAwAJAAAAHQYhAPAA0ALAAwAAAAAEAAAALQEDAAQA AAAtAQIABAAAAC0BAwAIAAAAJgYPAAYA/////wEAEAAAACYGDwAWAP////8AAEoAAACNAgAA FgEAAMUCAAAIAAAAJgYPAAYA/////wEADQAAAPsCAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAA LQEBAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAAIBAgAQAAAAJgYPABYA/////wAASgEAAI0C AAB2AgAAxQIAAAgAAAAmBg8ABgD/////AQAFAAAACQIAAAACBQAAABQCAAAAAAQAAAACAQIA EAAAACYGDwAWAP////8AAF8AAAC/AAAAwQMAAOkAAAAEAAAABwEEAAYFAABDD4YA7gAAADAA kAEAAAAAKABgA8AAYAAoAAAAkAEAADAAAAABAAEAAAAAAMAJAAAAAAAAAAAAAAIAAAACAAAA AAAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAADgAMAAAAAAAAAAAAAAAAAAAAAAAAAAAA//wAef/gAAAAAAAAAAAAAAAA AAAAAAAAAAAAAA/////gAAAAgAAAAAAAAAAAAAAAAAA////z////4AAAAAAAAAAAAAAAAAAA AAAAAAAAAeAP/7///3gH/EIAAAAAAAAAAB/AAAAP/////////9AAAAAAAAAAAAAAAAAAAAAA AAAAAAH/D////////3/8AAAAAAAD8AD////////////////4AAAAAAAAAAAAAAAAD8AAAAAA EEB///////////////AAP//4P////////////////////AAAAAAAAAAAAAYABg/AAAAAAAB/ ////////////////4D////////////////////////wAAAAAAAAAAAAAAAAf+AAAAAAT//// ///////////////////////////////////////8AAAAAAAAAAAAAAAAH//wAgAAP/////// /////////////////////////////////////gAAAAAAAAAAAAwAD/////z/Af////////// //////////////////////////////////8AAAAAf8AB/xxCEf////////////////////// ////////////////////////////////AAAAR/////////n///////////////////////// /////////////////////////////wAAA/////////////////////////////////////// //////////////////////////8AAP////////////////////////////////////////// ///////////////////////7AAD///////////////////////////////////////////// /////////////////////wAA//////////////////////////////////////////////// //////////////////8AAD////////////////////////////////////////////////// ////////////////AAAP//////////////////////////////////////////////////// /////////////wAAA/////////////////////////////////////////////////////// //////////8AAAP///////////////////////////////////////////////////////// ////+APwAAAC//////////////////////////////////////////////////////////// 4AAAAAAAA///////////////////////////////////////////////////////////n+AA AAAAAAAAf///////////////////////////////////////////////////////w/jAAAAA AAAAAH///////////////////////////////////////////////////gHwAcAAAAAAAAAA AAB//////////////////////////////////////////////f///44D+APxmAAAAAAAAAAA f/////////////////////////////////////////////////+fAPAD4AAAAAAAAAAAAAf/ /////////////////////////////////////////////gADmAAAAAAAAAAAAAAAAAAAD/H/ /////////////////////////////////////////4AAAAAAAAAAAAAAAAAAAAAAAAZ4Xiv5 T5////////////////////////////////////8AAAAAkAAgAAAAAAAAAAAAAAAAPKhB4AD7 vhHP///8AAgAg//5////////////////////gAAAAAAAAAAAAAAAAAAAAAAAABgBgAAD8AGE gGIC4AAAAAP/gf//////////////////7AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGADAAAIAG AAAAAAAAEAAf//////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABggBAAA AAAAAAAAAAAAAIP/AAA////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAAA AAAAAAAGAAKPAgAwAAAAAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAMAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAIAAAAAAAAAAACIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAACiJwAAQw/GAIgAAAAwAJABAAAAACgAYAPAAGAAKAAAAJAB AAAwAAAAAQAIAAAAAADAVAAAAAAAAAAAAAAAAQAAHQAAAAAAAAAYrd4AIbXeACG15wAhtfcA GLX/ABi9/wDAwMAAKcb3ADHO9wA5zv8AOdb/AErW/wDO3vcAUt7/AFre/wDe5/cAY+f/AGvn /wB75/8AlO//AJzv/wCl7/8Ate//ANbv/wC99/8A1vf/AOf//wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////FxYa//// /////////////xMU//////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////8KCgoKCgoKDg4OERMTFP//////////////GBkYEP//CQoK CgoKDAoMDA4R//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////xoWFhYVFBYNFxYZGRYZFhUVExMPEw4PDgwMDA8MDAr///////// /////////////////////////////xP///////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////wYDBAoDCgYJAwoKCgoKCgoKCgoKDg4ODxER //8UFgoDBQkDCgMKCQkDCgkKCgoKCgoKCgwMDw8KDv////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////xUVFRb///////////8XFhYVFRUUFBMUFQkI/xUV ExMPEw8PDg4MDA4ODwwMCgoKCQn/CQkJCv//////////GRoZFxoXFhYW////FP////8U//// //////////////////////////////////////////////////////////////////////// //////////////8TExMRDwoM//////////////////////////////////8KAwQECgMKBgQJ CQoDCAoEAwUKCgoEAwoDCgMKCQUKBAMKBAQICQkJCQkICAoKCQoKCgoKCgoKFhMTExMTFv8T //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////8UEw4VFhYV FRX/////FRMVDxUWExUVFBUTExUTExUTEwoKCgoKDgkKDAwMCgoKCgwKCgkJCQkJCQkJCQkJ CgkKCP8KFhYWFRYVFRMWFRYV//////////////////////////////////////////////// ////////////////FBMTDxMK////////////////GxYXFhMTEw8PCgwKCQMEBQUFBQUFBQUF BQUFBQUFBQUFBQUFBQUFBQUBBQUFBQUFBQUFBQUFBQUDBQYEBgoJCQkJAwYFBQMGExEGERER FBMTExMTExMWExYTFhMTExMTExMWFBP///////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //8WFxYWFhb//////////////////////////////////////////////////////w7///// /xf/////////ExMKFhcWExMPEQ8ODg4PChYVFhMVExUTERMRERERChMTExMTExMTExMUCgoM CQoKCgoKDA4ODwoKBAoECgoKCQoKCgoKDgMJCQkJCQkJCAkLAwoKBAoDCgQKBP////////// ////////ExMOCg4MDhEPExQPCgwODw8PCv//////GhgXFhUWDxQREwwMCgkFBQUEBQQFBAQE BQUEAQUEBQUFBQUBBQUFBQUFBQUFBQUFAQUFBQUFBQUFBQUFAQUFBQUFBQUFBQUFBQUFBQUF BQUFBgYDBggKCgoKCg4ODg8OERETERETExMTExMTEwoJCgoKCgoKDAoPDgoKCv////////// //////////////////////////////////////////////////////////////////////// /xMR//////////////////8TEf//////FxYWFxYW//////////////////////////////// //////////////////////////////8XFhYVFRUVExMTExMPERMTEw4PDg4MDAwMDAwWExMT Ew8TDxMRERERDxQTExMTExMTDw4ODw4MCgoKDAoMDw8KCgoKCgoEDAoKCgQEBAoKCgkKCgoK CgQKBAoDCgoDCgkJCQoDCgQKCgoE/////////xYRDg4PDg8PFBMTDw4ODg8PDwoKCgoDBAQE BQUDBRMTDw8MDAoKBQUFBQUFBQUFBQUFBQUFBQUFAQUFBQUBBQUBBQEFBQUFBQUFBQUBBQUB BQUBBQUFBQUFAQUBBQEFAQUBBQEFAQUFBQMGCQMKAwsKCg4OCg4OERERERMKEwkJCQkJCQkK CgkKCgoKCgoMDw4MAwr///////////////////////////////////////////////////// ////////////////////////////////////////////////////////////FRUVFRYWFhYW Fv//////////////////////////////////////////////////Df//ExMTEw8KDAoKFgoT ExQPEw8ODA4MDA4MDA4MDAwMDAwMDAwMDA4PExETDwwODAwKDAoKExMTDw4MDAoMCgoKCgED AwMECgoKCgwKCgoEBAQEBAQECgMKAwoKAwoEBAMKCgQKCgoKBAoECgoMBAoFCgoDCQkKCgMK BQoDCgMKAwoGAw8RCg4KCgoOBAQGBAUFBQUGBQUGBQUFBQUFBQUFAQUFBQUBBQUFBQEFBQUF BQEFBQEFBQUFBQUFAQUFBQUFBQUBBQUBBQEFAQUFBQYGBQYFBQUFBQYGBgYGBgoICgYJCQYK CAgICAgICAMKBgoDCQYJCQkJCQoKCgoKCgoMCgwMCgwMCgoK//////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////xYWFhYWFhYWFhYWFhYWFRYV/////////////xT///////////////// ////////FBUVFBUREQ8PCgoKCgoKCQkJCQoKCg4ODg4MDA4ODA4MDAwMDAwMDAwKDAwKCgoK DgwMCgwKCgoKDgoKCgoKCgoKCgoKAwoKCgMKCgEFBQMEBAQEAwQECgoKCgoKCgoFBAoFBAQE CgMFBAQKAwUJBAQEBA4KCQkKCQoKBgkDCgUJBAoDCgYKAwQDBgMEBAQEBgUFCgMEBAQKAwYG BQUFBQUFBQUBBQUFBQEFBQUFBQUFBQUBBQUFBQUFBQUFAQUFBQUBBQUFBQEFBQUFBQUGBgYE BggGCAgGCAgDCgMICAgIAwgICAYJAwoDCgMKAwoKAwoKCgoKCgoKCgoKCgoKCgoMCgoMCgoK DAoMCgr///////////////////////////////////////////////////////////////// ////////////////FBT//////////////////xcXFxYXFhYWFhYWFhYWFhYWFhYWFRUVFhUV FRQVFBQUFRX//xMTFBETEREP/////////xETERERERMRExEPDw4MDAwKDAwMDAwKCgoMCgoK CgwKCgoKCgoKCgoKCgoKDAoKCgoKCgoKCgoJCg4KCgoKCgoKCgoKCgoKCgoKAQoKCgUKAwME BgQDBQoEBAQFBAQEBAQEBAoECgQKAwUKBAoDBQoEBAQEBAQEBAQEBAQEBAMFCgMKBAMKBAoE AwoFCgQKBgYEBAUFBQQEBAQEBAQEBAQFBAQEBQMFBQUBBQEFBQEFBQEFAQUFBQUBBQUBBQUF BQUFAQUFBQYBBQEFBQYGBgUFBgMGBggGCAYICAgICAgICAoDCQgKAwkKCgoKCgoKCQoKCgoK CgoKCgoKCgoKCgoKCgoMCgoMCgwKDAwMDgoKDv//////////////////////GRkXFhcXGhYX /////////////////xsXGhYXGhUXF////xYWFf///xb/////FP////8U////FA8UDxQTExMT ExMUExUPExUTFRMTExMTExMTExUVFRMVFRUVFRUTDxMRERETERETEQ8TEw8TERMTDxMTDxMP Ew8PDw8ODAwMCgwKDAoMCgoMCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoK CgoKCgoJCgoKCgMKBgoBCgoKCgMKBQoBCgUDCgQKAwQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE BAQEBAQEBAQEBAQECgMFBAQEBAQDBAQEBAQEBAQEBAQEBAQEBgQGBgQGBAUEBQQFBAQFBAUD BQUFAQUBBQUFAQUFBQUFAQUFBQUFBQUGAwYFAwYGCgYICAYGBAYKCAgGCQMKCAgICAoICQkJ CQkJCQkJCgoKCgoKCgoKCQoKCgoKCgoKDgoKCgoKCgoKCgoKDAoKDAoMCgwODAwOCgr///// //////8Z////FxYVFBUTFBERERERDxEREw8RExETDxMRERETERMTDxMRERERERMRERMRERER ERERERERERERDxH//xERDw8TExMUExMUExMVFBYTExMTFRMTExMTExMTExMTExMTEw4ODhET DxMTDxMTDxMTDw4PDg8ODg4PDg4PDg8ODg8ODg8PDg8ODg4PDg8ODw4PDw4ODg8ODg4PDw4O Dg8ODg4OCgwMCgwMCgoKCgoKCgoKCgoKCgoJCgkJCQkKCgoFCgoKCgoKCgMJBQoFAwUDBQMF AwUDBAMEBAMEBAQEBAMEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBQQEBAQEAwQEBAQE BAUEBAQEBAQEBAQFBAMFBAQFBgYFBgYGAQUGBAYFBQYBBgUFBgEFBQYGBgUGBgUGBgYGBgMG CgMGAggICAgGAwkGCAgICAgICAoJCQsKCQoJCgEGCgYBCgYGCgYKBAYGCgMKCgMKCgMJCgoK CgoKCgoMCgoKCgoKCgoKCgoK////////ExMTGRcWFhYWFhUTExETERMRExETERETERERExER ExETERMRERQPERMRExEREREPERMPDxEREREREREPEREPEw4PDxEREQ8RDw8PDxEPEQ8ODw8O DxQTExQTExQTFBMTFBMTExQODw4PDg4PDg4PDg4PDg8ODw4PDg8PDg8PDg8ODg8ODw4PDg4O Dw4PDw4ODw4PDg4ODg4ODg4ODg4ODw8ODg4ODg4KDgoKDgoKDgoOCg4KCwoKCgoKCgkJCgoK AQoBCgMDBgMFBQMGCgoDBgoFBgUJBgoJBQUJBQMFBQMECQUEBQMFBAMEBAUDBAMFAwUEBAQD BAQEAwYGAwQFAwUFBAMEBAQFAwYFAwUDBQQDBQMFBQMGAwUGAwUFAwYDBgYGBgYGBgYGBgYE BgYGCgMGCgYGAwgGBgYGBgQKBggGCAgGBggGBgYGCAgGCAgGBggGAwgGBgoDBgYGBgoGCgMK CQYDBgEGBgEIAwMDAwMBAwIKCQ4KCgwMCQEKCQIKCgoKCgoKCgoCChcWGRUVFRQUExMTExER EREREQ8RERERERERERERERETDxEREREREREOERMPEQ8PDw8ODg4ODAwOCg4RDw8PDxERERER EQ8RDxERERERDw8RDw4TDw8PDw4PDw4ODg4ODg4ODw4ODg4OEQ8RDg8ODg4PDg4PDg4PDg8O Dg8ODw4PDw8PDg8ODg4ODg4ODAwMDAwMDAwKDAwMCg4KDgoKDgoKCgoKDg4KDg4KCgoDCQoK DgoKDgoKDgoKDgoOCg4KDgoKCgwKCg4KCg4KCgoKCg4BCggCCgMKAwgDCgEJBQMJBgMJBQMJ BQUKAwUKAwUJBQUDCQYGBQoGAwYDCQYDBQYKAwkGBggKAwQGBQUDBQoDCQYDCgMGCQUIAwoG AwoGAwoGAwoGBgYGBgYGBgYCBgYDBgYGBgEGBgYDCgYBCgYIBggGCAYIBggICAMIBgMGBggD BgIGAgYDCAMCAwEJAgICBgEFAgIKCgoKCgoKCgwBCgoKCgEKCgoKCgoKCQkJCQkJCQkJCQkJ CQkKCQr/CgobGxsaGhoaGRoRERERERERERERERERDxEREQ8RERERERERERERDxERDxEOEQ8P Dw8PDw4ODg4MDA4KEQ8RDw8PDw8PDw8PDw8ODw4ODg4ODg4ODgwODAwMDAwMDAoOCg4KCw4K CxEREREODw4PDg8ODAwMDAwMDA4ODg4ODg4ODg4ODg4ODg4ODg4ODAwODAwMDAwMDAoMCgwK DAoOCgoKCgoKCgoKCgoKCgoKCgkKCQkJCQkJCQkJCQkJCQkJCQoKCQkJCgoKCgoKCgoKDgoL Cg4KDgoLCgoKCgoKCgoKCgoKCQkJCQMFAwYKAwYDBgMGAwYDAwYDCAYGCgYIBgkDBAoGCgEI CAYIAwgGBgkDBgoIBgYKAwYKCQMKAwoGAwoICAgGBAYIBggGAgYCCgYDCgEKAQYKBgEKBgEB CAYBCAYCCAYIAwgDCAgICAMICAIICAMKAgoJCQkICwkJCQkCCQoJDAkKCgoKCgIKCgoKCgoK DAoJCQkJCQkJCQkJDgkOCQ4CCQkOCQkJCQkOCQoKGxsQGxoaGhobGhkZFRUVFRMTExERERER ERERERERERERERERERERDxERDw8ODw4PDw4ODg4ODg4JDg8PDw8PDw8PDw8PDw8PDg8ODg4O Dg4ODgwODAwODAwMDAwMDAoOCg4KDgsLCwsKCg4ODg4ODA4MDA4MDgwODg4ODg4ODg4ODg4O Dg4ODg4ODgwKDAwMDA4MDAwMDAwKDAoKCgoKCgkKCgoKCgoKCgoKCgkKCQkJCQkJCQkJCQgJ CQgJCgkKCQoJCgkKCQoJCgoKCgoKCgoKCgoKCg4KDgoOCg4LDgoKCgoJCQkJCQkJCQkJCAoI CwgICwgICwMICgMGAwoDBgYDBgMKAwgDCAgDCAMJBggDBggIAwgGAwYGBggFAwoEAwgDCAEK AQoCBgYKBgYEBgYGBgYKAQoDBgoGCgYJBgoDBgMIAwYKAwgCCAMIAQgICgMICAkJAggLCQkJ CQkJCQkJCQkJCgkKCgoKCgoKCgwJCQkJCQ4LCQ4JCwIOCQkJCQkJCQkJCQkJCRUJCAkKCv// GxoZFRUUGRkZGRkVFRUTERERERETERERExEREw8TERMPExETERERExEREw8TERERERERERER EREPEQ8REQ8PEQ8PDw8PDw8ODw4PDg4PDg4ODgwMDAwMDAwMCg4MCgwKDgoOCgsLChERERMO Dg8ODg4PDg4ODw4PDg8ODg8ODg8ODg4ODw4PDg8ODw4PDg8ODw4PDg8ODw4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ICQkJCQkJCQkKCQoKCgoKCgoKCgoBCgoKAwoK AwoKAQoKAwEKCgoICgoJCggKCgMKCggKCAgKCAgKCAsIAgoICwkDCgkJCQkLCQgLCAgJCQkJ CgMICggKCQkDCgMICAYJBgkKCQUDBgMGAwYGAwYDAwMDAwEDAwEDAQEBAQMBAwMBAwMDAwMD AwMDAwoDCAMKCAYKCAgICAgICAkICQkJCQkJCQkJCQkJCQkKCQkKCQkJCQkJCQkICQgJCQkJ ERMUExUTFRUVFBQUFBUUFBUZGRn/////GRkVFRQUFBMTExERERERERERERETERETERETERER ERMRERMRExERExERExERExETDxERERERExERDxERDxEPDxERDw8PDg8ODg8ODw8ODg4MDg4M DA4MDAwMDAwOCg4KDgsKCBQRERERDw8PDg4PDg4ODg4ODw4ODw4ODw4ODw4ODAwMDAwMDAwM DAwMDAwMDAwMDAwMCg4KCg4KDg4IDg4KDg4KDg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODgwODg4KCgIKCQoBCgoKCgoKCgoKCgMKCgoKCgoKAwoKCgoKCgEKCgoKAwoKCgoK CgoKAwoJCwoJCgoJCAkLCAMLCQkJCQoCCgoDCQoKCQoDCgoDCgIKAQkBAQEBAQEBAQEDAQMB AwEDAwMBAwEBAQEBAQMCAQEDAQEDAwMDAwMBAgoDBAMICAgICAgICAgLCAkJCQkJCQkJCQkJ CQkKCQkJDAkOCQkODgkRDg4RERERFBQRFBERFBQRFRQUEQ4RDg4ZGRkR////////GhkVFRMU ERMRERERERERERETERMRERMRERMRExERERMRERMPExETERETDxMREREREQ8RExERERERERER ERERERERDxERDw8PDw8PDw8PDw8PDg4ODgwKDgwMDAwODgoLDhUUDxMRExEPEQ8MDA4MDgwM DAwMDAwMDAwODA4MCg4MDAwMDAwMDAwMDAwMCg4MDAwJDgoKDgoOCwoLDggOCgsKDgoOCw4K Cg4OCg4KCg4KCg4KCgsOCg4OCgoODg4ODg4ODg4ODg4ODg4ODg4MDAwKCgoBCgIOAQoKDgEO Aw4KCgoKAwoKCgoKCgoKCgoKCgoKCgoKCAoICggJCggJCQoICgoICggJCQkKAgoKCgoKCgoK AgoKCgIKCgoBAQEBAQEBAQEBAQEBAQEBAQEDAQMDAwMGAwYGBgQGBgoGBgMGBgYECgYDCgkD BgoDAwgIAggICAIICAgIAggJCAkJCQkLCQkLCQkJCQkJDg4JEQ4RERERERERFBQUFBEUFBER ERERCRERExQUEf///////xkZGRUUFRMTExMUERETERMRERERExERERMREw8TERMRDxMRERMP ERETERERERMRERMRERERERETERERERERERERERERDw8RDxEPDw8PDg8PDw4PDg4ODg8KDgoO DgoOCwoOEw4REw8UEQ8ODA4ODA4ODgwMDAwMDAwOCg4KDA4MCg4KDgoODAwMDAwODA4KDg4M DgkMCQkOCgoOCg4KDgsLDgsKCwoOCg4KCwoLCgsKCg4KDgoOCgsKCwoOCg4KCgoKCgoKDg4O Dg8ODw4OCg4BDgEOCgoKCgoKDgEKCgIKAQ4BCg4KAgoBDgIDDgMKAwoDAwoDAw4KAgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKAwoDAwoKAwMKCgMBCgEBAQMBAQEBAQEBAQEBAQEBAQEBAQMG AwYDCAYDAwgGBggGCAMKAwYJBgMGCQMJAggIAggIAggCCAgICAkJCQkJAgkCCQIJCQkJCREO ERERERQUFBQUFBQUFf///////////xQUExQTFf////////////8a/xQVExQRExMTERERERER ExERERETERERERERERERExERERMRERMRERETERMRERERERERDxERDxEPDw8PEQ8PDw8PDw8O Dw4PDg8ODg4OCg4ODAwMDAwMCg4KDg4KDgoOCgsUExMTEwoODAwMDA4KDgoODA4KDgoOCg4K DgoKDg4KDgoOCg4MDAwMDAwMDgoOCQ4OCQ4LDg4OCg4KDgoOCgsODg4KCg4OCgsOCgoOCgsO CgoOCgsKCgoLCgsLCw4KCgoKCgoOCgoCCgoBDgEOAQoKCgoKDgoKCgEOAQIKAQ4BCgoKCgMO AQ4DCgMCCgMLAgMKAwMKAwIKAwMDAwMDAwoDAwIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDBgIDBgEGCAYGBgoFBgQECgYDBAoDCggICAgICAgICAoDCQkJCQoMCQwMCQ4ODg4ODhEO EQkRDg4ODw4ODxEOEREREREREQ4JEREREf////////////////////////////////////// ////////GhsbGRoaGRUVExMRExERExERExETERETERETERETERETERERExEREw8TERERDxER DxERERERDxERDw8PDw8PDw8PDw8PDg8ODg8ODg4ODg4MDAwMDA4KDgoOCwoOCwsLCwsKCxUT Ew8OCgwMDA4KDg4OCg4KDg4KDgoKDgoODgsKDgoOCwoJCgkJCQkJCQIJCAkICQgJCAkDCAkJ CAkICQgJCAkKCQgJCAkLCw4LCg4LCg4LCwsKDgkOCg4KDgoKCgoOCg4KCwoKCgoKCgoKCgoK CgoKCgoKCgoOCg4KDgoKAgoCCgIDAgMDAwICAgMCAwMCAwIDAgMDAgMDAgICAwICAgEDAwMD AwMDAwICAgICAgICAgICAwICAwIDBggICAgICAUDBgMDAwMDAwMCAwIBCgMKCgMKAwkICAoD BgIJCQkJCQkJCQ4JCQ4ODg4OEREJEQkRCQ4RDg4REREREREUFP//FBUZGRkVGRr///////// ////////////////////////////////////////////////////ERERERERERERERMRERMR ERMRExETERMRExERExETERERExEREREREREPEREREREOERERDxEPEQ8PDw8PDw4ODg4ODg4O Dg4MDAwKDgoOCg4KCw4KCw4KCwoTExEREQ4OCgoMCg4KDgoMCg4KDgoODggOCgoOCg4KDgoI CwkKCQkDCQkJCQkICQgJCAkICQkICAkICAgJCAoICAgJCAkICwgJCAkICAkICAsICAsLCwsL CgsKCw4KCwsKCgoKCgoKCgoKCgkKCgoKCgoKCgoKAgoCCgIOAgoCAwMCAwMCAwIDAwICAwIC AgICAgMCAgMCAgMCAwIDAgICAgICAgICAgICAgICAgICAgICAgICAgICAQoBCAgGCAgICAgI CQkICQkJCQkJCQkMAwkBCQECDwICERQREwMOCQ4ODg4RDg4TERQTFRUVExMVGRkZFRUVFP// //8ZGRUZGRkZ////Gxr///////////////////////////////////////////////////// /////////xkRERMRERMRExERExERExERERERDw8PERMREw8TDhETERERERETEREREREPEREP Ew8RDhMRDw8PDw8PDw8PDg4ODg4ODg4ODgoOCg4KDgoOCwsLCg4LCgoVFQoPEREODg4JDgkO CQoKDgoKDgkOCgoODA4OCg4KDgkDCAgJCAMJCQkJCQkJCQkJCQgJCAkICggGBgoICwgIAwgI CQgKAwoDCAoICAkICAoDCAgICAgICAgICAgICggICAoDCgoKCgoKCgoKCgoKCgoKCgoKCQkK CQgJCAkJCQkCCgIJCgIICQIICwgCCQgCAgIIAgICAgECAgICAgICAgICAgICAgICAQECAgID AQICAgEDAwMICAYICgMKCAgICAgICAIJDgkOCQsJDgkJCQkJCQwMDA4RExERExP///////// /xERERET//////////////8VFBX///////////////////////////////////////////// //////////////////////////////////////8aERERERERERERExMREREREREREQ4ODw8P Dw4ODg4PDxMREREREQ8PDg4ODgoODw8ODg4JDgkODg4ODg4JDgoLCQ4KCwoPDgwMCg4JCQsL CgsLDgsLCwsKFhMRExETDxEODw4PDg4ODgoMDgkMCQ4JCQoJCQkJCQkJDggOCQ4JCQkJCQkJ CwkJCQgICQkICQkDCgkJAwgICAoJAwoICAkJCQoIAwoICAoICQgICAgICAgICAgDCAYDCAYD CAgKCAEKBgoBCgYICAMKAQYIAwYICAMKCAoGAwoJCAkJCAgKCggLCAgICAgLCAgICAgICAgI CAgICAgICAgICAgCCAYIAwgGCAgGAwMICAMICAMDAwoDBgYG/wMLCAgICQgJCAIJAg4CDgIR DgkOCQkJDg4R////FBQV/////////xEOCQIJAg7///////////8ODg4RDhH///8VDv//EQn/ ////////////////////////////////////////////////////////////////////FRQU FBERFBERERERERERERERERERDg4ODw4ODg4PDhERERMREQ4PDg4ODgkMDA8PDw4ODg4OCQ4O Dw4ODgkOCwgKCgoODg8JDgkOCwsKCgsLCAMLCwsKCAkRFRMTERMRDg8ODg4PDg4ODgkODgsO DgkJCQkJCQkJCQkICwIJCQkJCQkJCQkJCQkJCAgJCQMJCQoDCQoDCgMKAwkJAgkJAwkDCQoD CQgDCQgJCAsICAgICAgICAgICAgICAMIAwYICAMDBggIAQoDBgoDCAoDBggCBggCCAEGCAgG CAgIAggGCAMICAsICAMICAgICAgICAgICAgICAgDCAgICAMICAgICAMICAMIAwgIAwgIBggG CAgCCAkICAgICAgJAg4JDgkPCQ8JDxMPERERDg4JEf//CAMJCQn//////////wIODg////// ////////CRQUExX///////////////////////////////////////////////////////// //////////////////////////////8bFRUUFBQRERERERERERERERQREQ4JDg4JCQ4OCw4J DgkOCAsOCQsLDgkOCQ4JDgkOCQ4JDgkLCw4OCQgOCQ4OCQ8MDAwOCQsLCwsJCQgICQ4KCg4I EQ4REREODhEPDg4ODg4ODg4ODg4OCxELDg4ODg4PERERERERERERExERERERERERERERDg4O DgkMDgoKDgwOCQkJDgkODgkJDgwOCQkOCQkJCAgICAgJCQgICAgICAIICAgIAwgIAwgIBggI CAgDCAYDAwYDBgMIAwYCBgIGCAIICAYICAYICAMICAMICAYICAgIAggIAggCCAgDCAYICAMI CAgIAwgICAgDCAgIAwYICAMCCAIDAgMICAgICQkODg4ODg7///////////////////8CDgn/ /wkJ//////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////xQT ERMRERER////DhEODg4JDg4OEQsRCw4OCw4JDg4JDg4JDg4ODg4OCQ4OCw4RCwsOCA4JDgkO CQ4JDg4OCQgOCQsICQkJCQkJCQkJCgoKDgoKEREODg4ODg4ODg4ODg4OEREOEREOEQ4ODhER FBMRFRERERERERQTExEREREREQ4RDgkODgkODgkOCQ4ODg4ODg4ODg4JCQ4OCg4KDgsLCgsO CgsLCwsLCwoKCwsIAggDCAMIAwgICAgCAQgDCAMICAYCCAIIAggCCAIIAggBCgMIAwgICAgI CAgDCAsDCAgGAgYCCAYDAwgDCAMCCAgIAwMCAwgDAwICAgICAgIICAoCCAgIBgYGBgYK//// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////EQ7//xEODgv/////Ef8ODgkO////Dv8R/w4JEwkJDg7/ /w7/Ef//EQ4JCw7//w4LDhEOCQ4OCQ4JDg4ODg4JCQkOCgoJCwsJCQkJCwkODg4ODgoOCw4O Dg4ODg4ODg4ODhMUFRkZGhkZGRkaGRkZFRkWGRkZGRkZFRUUFBQUFBEREQ4ODg4ODhEODg4O Dg4OERMRERERDg4LDgkJCQkJCgsLCwsLCQsJCw4KDgoKCwsLCwsLCwsKAgoDCggCCAIIAgMI CAgICAgICAgICAgICAkDCgMICAgICAgICAMICAgDCwgICwYICQgDCwIKCAILAgsICwgCCwgL CAsJCQsJCwkICQgJCAgGBgYG//////////////////////////////////////////8J//8J //////////////////8O//////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////EQsOEf// Ef8O/xH/////Ef//////Dg8JEf////////////////8JCQkJEf8CDg7/DgkOCBH/////Cf// /wgGCP//CgkODg4LCxERDgsRDhERExMREw8PDw4TERT//////////////////xv///////// /////xX//////xEOEREOEQ4RERERExERFP//EREREQ4ODg4ODg4ODg4ODg4ODg4ODg4KCQkJ CgsKCgoKCwoKCwkJCgkJCgkJCQkLCAkICQkICQkICQsLCQkKCgoJCwgICAgIAwgDCAMICAML AwgDCwMLAwkJCwIJAggCCQgJAwkJCAgICAgICAkICAIICAgIBgYICA7///////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////8REf////////////8REf///////////////////////////xEO DgkJCf//////////////Dg7/////C///Cv//////////Dgj///8I/////////wn/CgQK//// //////////////////////////////////////////8cGhoUFBEUFRUZGf///////xoVFBER CwkICQsODg4ODg4ODgsODg4ODg4ODg4ODg4ODg4ODg4KDg8PCQkKCQkJCQkLAwsIAwsCCQgI CAgJCgkJCQkICQkJCQkJCQkICQgJCQkJCwgJCQkJCQgJCQgLCAkJCQkJCQkJCwoKCgoKCgoK DgoO/wgG//////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////8OEf//////////////Dg7//////////////////////////wn///////// //////8GCv////////////////////////////////////////////////////////////// //////8U////////////////////Ew8ODg4OEREODhELEQ4RDw8RERERDxERERERDg4ODg4R EREODhEOEQ4RDg4RERQUExQUFBMOEw4ODg4OCQ4RCQkJCQkJCQgJCQgJCAkJCQsJCQkJCQgJ CQgICAgICAgJCQkJCAsKCwoKCwoLCg4LDgP///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////Dgr//////w7/////////////Dv////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////CP//////EQ4TExETExEPE////////////////////////xUV FRQUFBUUFBQUFBQVFBQUFBUVFBQVFRQUFBQTFBQUFBQVFBUVFBQUFRQUFRUUFP////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////8ECf////////////////////////////////////////////////////////////// ////////////////////////////Aw7///////////////////8J/w7///8KDggR//////// Dv//////////////Aw7///////////////////////////////////////////////////// ////////////////////CAr///////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////woI////////////////////////////Dv////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////Cv////////////////////////////////////////////// //////////////////////////////////////////////////8K////Cv////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////Cf////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////8EAAAABwEBAAgAAAAmBg8ABgD/////AQAHAAAA/AIBAAAAAAAAAAQAAAAtAQQA BAAAAC0BAAAHAAAAGwTBAIwDSABgAAQAAAAtAQMABAAAAC0BAgAFAAAACQIAAAACBQAAABQC AAAAABMAAAD7Asv/AAAAAAAAkAEAAAAAAAAAIkFyaWFsIEJsYWNrAFwABAAAAC0BBQAEAAAA 8AEBAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBADAAAAAyCq0AagAbAAAA RGl2ZXJzaW9uIEluZGljYXRpb24gaW4gU0lQACoAEQAhACMAGAAhABEAJAAjABIAFQAkACMA EgAjACQAGAARACQAIwASABIAJAARACcAFQAmAAQAAAAuAQEABAAAAAIBAgAEAAAAAgECAAQA AAAtAQQABAAAAC0BAAAHAAAAGwRTAoEDmAHgAAQAAAAtAQMABAAAAC0BAgAFAAAACQIAAAAC BQAAABQCAAAAABMAAAD7AtX/AAAAAAAAkAEAAAAAAAAAIkFyaWFsIEJsYWNrAEwABAAAAC0B AQAEAAAA8AEFAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBABYAAAAyCsUB 6gAKAAAAU3RldmUgTGV2eR8AEwAcABoAHQAOAB0AHAAaABoABAAAAC4BAQAEAAAAAgECAAUA AAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBAB4AAAAyCgIC6gAPAAAAQnJ5YW4g Si4gQnllcmx5ACEAEwAaAB0AHAAOAB0ADgAOACEAGgAdABMADgAaAAQAAAAuAQEABAAAAAIB AgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAWAAAAMgpAAuoACgAAAEou IFIuIFlhbmcdAA4ADgAhAA4ADgAiABwAHQAcAAQAAAAuAQEABAAAAAIBAgAEAAAAAgECAAQA AAAtAQQABAAAAC0BAAAHAAAAGwRGAVkDCAFoAAQAAAAtAQMABAAAAC0BAgAFAAAACQIAAAAC BQAAABQCAAAAABUAAAD7AtX/AAAAAAAAkAEAAAAAAAAAAFRpbWVzIE5ldyBSb21hbgAsAAQA AAAtAQUABAAAAPABAQAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAxAAAA Mgo2Ad4AHAAAAGRyYWZ0LWxldnktc2lwLWRpdmVyc2lvbi0wMS4VAA8AEwAOAAwADgAMABMA FQAVAA4AEQAMABUADgAWAAwAFQATAA4AEQAMABUAFQAOABYAFQALAAQAAAAuAQEABAAAAAIB AgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAMAAAAMgo2AbcCAwAAAHR4 dAAMABUADAAEAAAALgEBAAQAAAACAQIABAAAAAIBAgAEAAAALQEAAAQAAAAtAQQAEAAAAPsC EAAHAAAAAAC8AgAAAAABAgIiU3lzdGVtAG4EAAAALQEBAAQAAADwAQUADwAAACYGDwAUAFRO UFAEAAwAAAAAAAAAAAAAAAAACQAAACYGDwAIAP////8BAAAAAwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAABuAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAA QAIAAAAAAgAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAA AAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEkAEAAA8AAPCIAQAAAAAG8FgAAAAHJAAA CgAAAGIAAAAHAAAAAAAAAAcAAAABAAAABQAAAAEAAAAIAAAABAAAAAgAAAADAAAABAAAAAIA AAAsAQAABgAAAAQAAAAHAAAABAAAAAgAAAAHAAAAXwAB8NwAAABiAAfwJAAAAAYGEe7EF8m/ KGE+iN/DK/gOLP8ADw0AAAIAAAAAAAAAAADLAHIAB/AkAAAABwdM4HYUjV2x2YoU8/Pe+E/B /wAxCwAAAgAAAA8NAAAAAMsAcgAH8CQAAAAHB+hWmitBACEJ/BUK/jjHF8r/APEKAAABAAAA QBgAAAAAywByAAfwJAAAAAcHJE/n7On9G+xHLWbmJcI+HP8AVQoAAAMAAAAxIwAAAADLAHIA B/AkAAAABwfFrKdXHLZNkdeOZj8wC7/w/wA5CgAAAQAAAIYtAAAAAMsAYwAL8CQAAACBAQQA AAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAACPcA ABAfAPAPOAAAAAAA8wMUAAAABAAAAAQAAAAAAAAAAQAAgAAAAAAAAPMDFAAAAAUAAAAEAAAA AAAAAAIAAIAAAAAADwDQB88AAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAAA2AAAAZAAA ADYAAABkAAAAZLRiAIqJCjBctGIACAAAAGYSAADACQAA4vz//7L///8BAAAAcAD7AwgAAAAA AAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwAH BDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAAAMtmIADLZiAAEAAAAAAAAAxBEAAFwKAAAA AAAAAAAAAAAA//8/ANkPDAAAAAAA2g8EAAAAAAAlAA8A8A8WBAAAAADzAxQAAAADAAAABAAA AAIAAAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqA8bAAAARGl2ZXJzaW9uIEluZGljYXRpb24g aW4gU0lQEACfDwQAAAAFAAAAAACoDyUAAABTdGV2ZSBMZXZ5DUJyeWFuIEouIEJ5ZXJseQ1K LiBSLiBZYW5nAADzAxQAAAAKAAAABAAAAAMAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8W AAAAUHJvYmxlbSBhbmQgT2JqZWN0aXZlcxAAnw8EAAAABwAAAAAAqA+uAAAAUHJvYmxlbQ1V bHRpbWF0ZWx5IGNhbGxlZCAodGhpcmQtcGFydHkpIFNJUCB1c2VyIGFnZW50IGlzIHVuYWJs ZSB0byByZWxpYWJseSBkZXRlcm1pbmUgZnJvbSB3aG9tIHRoZSBjYWxsIHdhcyBkaXZlcnRl ZCBhbmQgd2h5IHRoZSBjYWxsIHdhcyBkaXZlcnRlZC4NRXhhbXBsZXM6IFZvaWNlbWFpbCwg QUNEAAChD1IAAAAIAAAAAAAAAAAApwAAAAEAAAAAAAgAAAAAAAAATwAAAAAAAgAUAAkAAAAB AAIAgQAUABsAAAAAAAIAFAADAAAAAQACAIEAFAAxAAAAAAACABQAIACfDwQAAAAHAAAAAACo D2IAAABDaGFsbGVuZ2VzDU11bHRpcGxlIGRpdmVyc2lvbnMNUHJpdmF0ZSBudW1iZXJpbmcg cGxhbnMNSW50ZXJvcGVyYWJpbGl0eSB3aXRoIGxlZ2FjeSBQU1ROIGRpdmVyc2lvbgAAoQ8m AAAACwAAAAAAAAAAAFgAAAABAAAAAAALAAAAAAAAAFgAAAAAAAIAFAAAAPMDFAAAAAcAAAAE AAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDxoAAABDRk5BIHdpdGggRGl2ZXJzaW9u IGhlYWRlcgAAoQ8cAAAAGwAAAAAAAAAAABoAAAAAAAIAJAABAAAAAAAAABAAnw8EAAAAAQAA AAAAqg8KAAAAAQAAAAEAAAAAAAAA8wMUAAAACAAAAAAAAAACAAAAAwEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPEwAAAFByb3Bvc2VkIG5leHQgc3RlcHMQAJ8PBAAAAAEAAAAAAKgPHAAAAFNJ UCBXRyBpdGVtDVN0YW5kYXJkcyB0cmFjaw0AAKoPEgAAABwAAAAAAAAAAQAAAAEAAAAAAAAA 8wMUAAAACQAAAAAAAAACAAAABAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPEwAAAFByb3Bvc2Vk IG5leHQgc3RlcHMQAJ8PBAAAAAEAAAAAAKgPHAAAAFNJUCBXRyBpdGVtDVN0YW5kYXJkcyB0 cmFjaw0AAOoDAAAAAAAAchcIAAAAAQAQABJQAAAAAPUPHAAAAAABAACSDgAD7k8AAFtZAAAB AAAACgAAAAEAYgAPAOgDQQkAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAAAAAA AAAAAAABAAAAAAAAAQ8A8gMgAgAALwDIDwwAAAAwANIPBAAAAAAAAAAPANUHfAEAAAAAtw9E AAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAAMtmIADLZiADS0YgAEiQowWLRi AAgAAABYtGIAiokKMAAABBIQALcPRAAAAEEAcgBpAGEAbAAgAEIAbABhAGMAawAAAG0AYQBu AAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAQiIAC3D0QAAABUAGEAaABv AG0AYQAAAGwAYQBjAGsAAABtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCK iQowAAAEIjAAtw9EAAAATQBvAG4AbwB0AHkAcABlACAAUwBvAHIAdABzAAAAAAAMtmIADLZi ADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAIABAJAALcPRAAAAEEAcgBpAGEAbAAAAHAAZQAg AFMAbwByAHQAcwAAAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAQiAACp DwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABA AgAAAAACAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAA AAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwSQAQAADwAA8IgBAAAAAAbwWAAAAAckAAAK AAAAYgAAAAcAAAAAAAAABwAAAAEAAAAFAAAAAQAAAAgAAAAEAAAACAAAAAMAAAAEAAAAAgAA ACwBAAAGAAAABAAAAAcAAAAEAAAACAAAAAcAAABfAAHw3AAAAGIAB/AkAAAABgYR7sQXyb8o YT6I38Mr+A4s/wAPDQAAAgAAAAAAAAAAAMsAcgAH8CQAAAAHB0zgdhSNXbHZihTz8974T8H/ ADELAAACAAAADw0AAAAAywByAAfwJAAAAAcH6FaaK0EAIQn8FQr+OMcXyv8A8QoAAAEAAABA GAAAAADLAHIAB/AkAAAABwckT+fs6f0b7EctZuYlwj4c/wBVCgAAAwAAADEjAAAAAMsAcgAH 8CQAAAAHB8Wsp1cctk2R145mPzALv/D/ADkKAAABAAAAhi0AAAAAywBjAAvwJAAAAIEBBAAA CIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAA EB8A8A84AAAAAADzAxQAAAAEAAAABAAAAAAAAAABAACAAAAAAAAA8wMUAAAABQAAAAQAAAAA AAAAAgAAgAAAAAAPANAHzwAAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAADYAAABkAAAA NgAAAGQAAABktGIAiokKMFy0YgAIAAAAZhIAAMAJAADi/P//sv///wEAAABwAPsDCAAAAAAA AABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfAAcE PAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAAy2YgAMtmIAAQAAAAAAAADEEQAAXAoAAAAA AAAAAAAAAAD//z8A2Q8MAAAAAADaDwQAAAAAACUADwDwDxYEAAAAAPMDFAAAAAMAAAAEAAAA AgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoDxsAAABEaXZlcnNpb24gSW5kaWNhdGlvbiBp biBTSVAQAJ8PBAAAAAUAAAAAAKgPJQAAAFN0ZXZlIExldnkNQnJ5YW4gSi4gQnllcmx5DUou IFIuIFlhbmcAAPMDFAAAAAoAAAAEAAAAAwAAAAUBAAAAAAAAAACfDwQAAAAAAAAAAACoDxYA AABQcm9ibGVtIGFuZCBPYmplY3RpdmVzEACfDwQAAAAHAAAAAACoD64AAABQcm9ibGVtDVVs dGltYXRlbHkgY2FsbGVkICh0aGlyZC1wYXJ0eSkgU0lQIHVzZXIgYWdlbnQgaXMgdW5hYmxl IHRvIHJlbGlhYmx5IGRldGVybWluZSBmcm9tIHdob20gdGhlIGNhbGwgd2FzIGRpdmVydGVk IGFuZCB3aHkgdGhlIGNhbGwgd2FzIGRpdmVydGVkLg1FeGFtcGxlczogVm9pY2VtYWlsLCBB Q0QAAKEPUgAAAAgAAAAAAAAAAACnAAAAAQAAAAAACAAAAAAAAABPAAAAAAACABQACQAAAAEA AgCBABQAGwAAAAAAAgAUAAMAAAABAAIAgQAUADEAAAAAAAIAFAAgAJ8PBAAAAAcAAAAAAKgP YgAAAENoYWxsZW5nZXMNTXVsdGlwbGUgZGl2ZXJzaW9ucw1Qcml2YXRlIG51bWJlcmluZyBw bGFucw1JbnRlcm9wZXJhYmlsaXR5IHdpdGggbGVnYWN5IFBTVE4gZGl2ZXJzaW9uAAChDyYA AAALAAAAAAAAAAAAWAAAAAEAAAAAAAsAAAAAAAAAWAAAAAAAAgAUAAAA8wMUAAAABwAAAAQA AAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPGgAAAENGTkEgd2l0aCBEaXZlcnNpb24g aGVhZGVyAAChDxwAAAAbAAAAAAAAAAAAGgAAAAAAAgAkAAEAAAAAAAAAEACfDwQAAAABAAAA AACqDwoAAAABAAAAAQAAAAAAAADzAxQAAAAIAAAAAAAAAAIAAAADAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8TAAAAUHJvcG9zZWQgbmV4dCBzdGVwcxAAnw8EAAAAAQAAAAAAqA8cAAAAU0lQ IFdHIGl0ZW0NU3RhbmRhcmRzIHRyYWNrDQAAqg8SAAAAHAAAAAAAAAABAAAAAQAAAAAAAADz AxQAAAAJAAAAAAAAAAIAAAAEAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8TAAAAUHJvcG9zZWQg bmV4dCBzdGVwcxAAnw8EAAAAAQAAAAAAqA8cAAAAU0lQIFdHIGl0ZW0NU3RhbmRhcmRzIHRy YWNrDQAA6gMAAAAAAAByFwgAAAABABAAj1kAAAAA9Q8cAAAAAAEAAJIOAANrWQAA2GIAAAEA AAAKAAAAAQBiAA8A6ANBCQAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAAAAAA AAAAAAEAAAAAAAABDwDyAyACAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1Qd8AQAAAAC3D0QA AABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIA CAAAAFi0YgCKiQowAAAEEhAAtw9EAAAAQQByAGkAYQBsACAAQgBsAGEAYwBrAAAAbQBhAG4A AAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABCIgALcPRAAAAFQAYQBoAG8A bQBhAAAAbABhAGMAawAAAG0AYQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJ CjAAAAQiMAC3D0QAAABNAG8AbgBvAHQAeQBwAGUAIABTAG8AcgB0AHMAAAAAAAy2YgAMtmIA NLRiAASJCjBYtGIACAAAAFi0YgCKiQowAgAEAkAAtw9EAAAAQQByAGkAYQBsAAAAcABlACAA UwBvAHIAdABzAAAAAAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABCIAAKkP CgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEAC AAAAAAIAAAD//+8AAAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAA AAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBJABAAAPAADwiAEAAAAABvBYAAAAByQAAAoA AABiAAAABwAAAAAAAAAHAAAAAQAAAAUAAAABAAAACAAAAAQAAAAIAAAAAwAAAAQAAAACAAAA LAEAAAYAAAAEAAAABwAAAAQAAAAIAAAABwAAAF8AAfDcAAAAYgAH8CQAAAAGBhHuxBfJvyhh Pojfwyv4Diz/AA8NAAACAAAAAAAAAAAAywByAAfwJAAAAAcHTOB2FI1dsdmKFPPz3vhPwf8A MQsAAAIAAAAPDQAAAADLAHIAB/AkAAAABwfoVporQQAhCfwVCv44xxfK/wDxCgAAAQAAAEAY AAAAAMsAcgAH8CQAAAAHByRP5+zp/RvsRy1m5iXCPhz/AFUKAAADAAAAMSMAAAAAywByAAfw JAAAAAcHxaynVxy2TZHXjmY/MAu/8P8AOQoAAAEAAACGLQAAAADLAGMAC/AkAAAAgQEEAAAI gwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQ HwDwDzgAAAAAAPMDFAAAAAQAAAAEAAAAAAAAAAEAAIAAAAAAAADzAxQAAAAFAAAABAAAAAAA AAACAACAAAAAAA8A0AfPAAAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAANgAAAGQAAAA2 AAAAZAAAAGS0YgCKiQowXLRiAAgAAABmEgAAwAkAAOL8//+y////AQAAAHAA+wMIAAAAAAAA AHAIAABwAPsDCAAAAAEAAABACwAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ABwQ8 AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAADLZiAAy2YgABAAAAAAAAAMQRAABcCgAAAAAA AAAAAAAAAP//PwDZDwwAAAAAANoPBAAAAAAAJQAPAPAPFgQAAAAA8wMUAAAAAwAAAAQAAAAC AAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPGwAAAERpdmVyc2lvbiBJbmRpY2F0aW9uIGlu IFNJUBAAnw8EAAAABQAAAAAAqA8lAAAAU3RldmUgTGV2eQ1CcnlhbiBKLiBCeWVybHkNSi4g Ui4gWWFuZwAA8wMUAAAACgAAAAQAAAADAAAABQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFgAA AFByb2JsZW0gYW5kIE9iamVjdGl2ZXMQAJ8PBAAAAAcAAAAAAKgPrgAAAFByb2JsZW0NVWx0 aW1hdGVseSBjYWxsZWQgKHRoaXJkLXBhcnR5KSBTSVAgdXNlciBhZ2VudCBpcyB1bmFibGUg dG8gcmVsaWFibHkgZGV0ZXJtaW5lIGZyb20gd2hvbSB0aGUgY2FsbCB3YXMgZGl2ZXJ0ZWQg YW5kIHdoeSB0aGUgY2FsbCB3YXMgZGl2ZXJ0ZWQuDUV4YW1wbGVzOiBWb2ljZW1haWwsIEFD RAAAoQ9SAAAACAAAAAAAAAAAAKcAAAABAAAAAAAIAAAAAAAAAE8AAAAAAAIAFAAJAAAAAQAC AIEAFAAbAAAAAAACABQAAwAAAAEAAgCBABQAMQAAAAAAAgAUACAAnw8EAAAABwAAAAAAqA9i AAAAQ2hhbGxlbmdlcw1NdWx0aXBsZSBkaXZlcnNpb25zDVByaXZhdGUgbnVtYmVyaW5nIHBs YW5zDUludGVyb3BlcmFiaWxpdHkgd2l0aCBsZWdhY3kgUFNUTiBkaXZlcnNpb24AAKEPJgAA AAsAAAAAAAAAAABYAAAAAQAAAAAACwAAAAAAAABYAAAAAAACABQAAADzAxQAAAAHAAAABAAA AAIAAAACAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8aAAAAQ0ZOQSB3aXRoIERpdmVyc2lvbiBo ZWFkZXIAAKEPHAAAABsAAAAAAAAAAAAaAAAAAAACACQAAQAAAAAAAAAQAJ8PBAAAAAEAAAAA AKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAAAgAAAAAAAAAAgAAAAMBAAAAAAAAAACfDwQAAAAA AAAAAACoDxMAAABQcm9wb3NlZCBuZXh0IHN0ZXBzEACfDwQAAAABAAAAAACoDxwAAABTSVAg V0cgaXRlbQ1TdGFuZGFyZHMgdHJhY2sNAACqDxIAAAAcAAAAAAAAAAEAAAABAAAAAAAAAPMD FAAAAAkAAAAAAAAAAgAAAAQBAAAAAAAAAACfDwQAAAAAAAAAAACoDxMAAABQcm9wb3NlZCBu ZXh0IHN0ZXBzEACfDwQAAAABAAAAAACoDxwAAABTSVAgV0cgaXRlbQ1TdGFuZGFyZHMgdHJh Y2sNAADqAwAAAAAAAHIXCAAAAAEAEAAMYwAAAAD1DxwAAAAAAQAAkg4AA+hiAABVbAAAAQAA AAoAAAABAGIADwDoA0EJAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAA AAAAAQAAAAAAAAEPAPIDIAIAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB3wBAAAAALcPRAAA AFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAI AAAAWLRiAIqJCjAAAAQSEAC3D0QAAABBAHIAaQBhAGwAIABCAGwAYQBjAGsAAABtAGEAbgAA AAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAEIiAAtw9EAAAAVABhAGgAbwBt AGEAAABsAGEAYwBrAAAAbQBhAG4AAAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokK MAAABCIwALcPRAAAAE0AbwBuAG8AdAB5AHAAZQAgAFMAbwByAHQAcwAAAAAADLZiAAy2YgA0 tGIABIkKMFi0YgAIAAAAWLRiAIqJCjACAAQCQAC3D0QAAABBAHIAaQBhAGwAAABwAGUAIABT AG8AcgB0AHMAAAAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAEIgAAqQ8K AAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIA AAAAAgAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAA BQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEkAEAAA8AAPCIAQAAAAAG8FgAAAAHJAAACgAA AGIAAAAHAAAAAAAAAAcAAAABAAAABQAAAAEAAAAIAAAABAAAAAgAAAADAAAABAAAAAIAAAAs AQAABgAAAAQAAAAHAAAABAAAAAgAAAAHAAAAXwAB8NwAAABiAAfwJAAAAAYGEe7EF8m/KGE+ iN/DK/gOLP8ADw0AAAIAAAAAAAAAAADLAHIAB/AkAAAABwdM4HYUjV2x2YoU8/Pe+E/B/wAx CwAAAgAAAA8NAAAAAMsAcgAH8CQAAAAHB+hWmitBACEJ/BUK/jjHF8r/APEKAAABAAAAQBgA AAAAywByAAfwJAAAAAcHJE/n7On9G+xHLWbmJcI+HP8AVQoAAAMAAAAxIwAAAADLAHIAB/Ak AAAABwfFrKdXHLZNkdeOZj8wC7/w/wA5CgAAAQAAAIYtAAAAAMsAYwAL8CQAAACBAQQAAAiD AQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAf APAPOAAAAAAA8wMUAAAABAAAAAQAAAAAAAAAAQAAgAAAAAAAAPMDFAAAAAUAAAAEAAAAAAAA AAIAAIAAAAAADwDQB88AAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAAA2AAAAZAAAADYA AABkAAAAZLRiAIqJCjBctGIACAAAAGYSAADACQAA4vz//7L///8BAAAAcAD7AwgAAAAAAAAA cAgAAHAA+wMIAAAAAQAAAEALAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwAHBDwA AAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAAAMtmIADLZiAAEAAAAAAAAAxBEAAFwKAAAAAAAA AAAAAAAA//8/ANkPDAAAAAAA2g8EAAAAAAAlAA8A8A8WBAAAAADzAxQAAAADAAAABAAAAAIA AAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqA8bAAAARGl2ZXJzaW9uIEluZGljYXRpb24gaW4g U0lQEAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0A AAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAA GwAAAP7///8dAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAACUAAAAmAAAAJwAAACgA AAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAA NgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAIYAAABBAAAAQgAAAEMA AABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAA UQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAAWgAAAFsAAABcAAAAXQAAAF4A AABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcAAABoAAAAaQAAAGoAAABrAAAA bAAAAG0AAABuAAAAbwAAAHAAAABxAAAA/v///3MAAAB0AAAAdQAAAHYAAAB3AAAAeAAAAHkA AAB6AAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAAgQAAAI4AAAD9/////f///4UAAAD+//// hwAAAIgAAACJAAAAigAAAHIAAAD+////jQAAAP7///+PAAAAkAAAAJEAAACSAAAAkwAAAJQA AACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0AAACeAAAAnwAAAKAAAAChAAAA ogAAAKMAAACkAAAApQAAAKYAAACnAAAAqAAAAKkAAACqAAAAqwAAAKwAAACtAAAArgAAAK8A AACwAAAAsQAAALIAAAD+//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAFgAFAf//////////AwAAABCNgWSbT88RhuoAqgC5KegAAAAAAAAAAAAA AADgfrwgSmLAAYwAAACAAwAAAAAAAFAAaQBjAHQAdQByAGUAcwAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIB/////wIAAAD/////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAL83AAAAAAAAQwB1AHIAcgBlAG4A dAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoA AgD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANAAAA KgAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAKAACAQEAAAAFAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAEAAAACcYgAAAAAAAFAAbwB3AGUAcgBQAG8AaQBuAHQAIABEAG8A YwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB//////////////// AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHAAAAD+7AAAAAAAABQBEAG8A YwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAA AAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAALAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//////// ////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjACAAQCQAC3D0QAAABBAHIAaQBhAGwAAABw AGUAIABTAG8AcgB0AHMAAAAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAE IgAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAA AAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJA AgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEkAEAAA8AAPCIAQAAAAAG8FgAAAAH JAAACgAAAGIAAAAHAAAAAAAAAAcAAAABAAAABQAAAAEAAAAIAAAABAAAAAgAAAADAAAABAAA AAIAAAAsAQAABgAAAAQAAAAHAAAABAAAAAgAAAAHAAAAXwAB8NwAAABiAAfwJAAAAAYGEe7E F8m/KGE+iN/DK/gOLP8ADw0AAAIAAAAAAAAAAADLAHIAB/AkAAAABwdM4HYUjV2x2YoU8/Pe +E/B/wAxCwAAAgAAAA8NAAAAAMsAcgAH8CQAAAAHB+hWmitBACEJ/BUK/jjHF8r/APEKAAAB AAAAQBgAAAAAywByAAfwJAAAAAcHJE/n7On9G+xHLWbmJcI+HP8AVQoAAAMAAAAxIwAAAADL AHIAB/AkAAAABwfFrKdXHLZNkdeOZj8wC7/w/wA5CgAAAQAAAIYtAAAAAMsAYwAL8CQAAACB AQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAA CPcAABAfAPAPOAAAAAAA8wMUAAAABAAAAAQAAAAAAAAAAQAAgAAAAAAAAPMDFAAAAAUAAAAE AAAAAAAAAAIAAIAAAAAADwDQB88AAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAAA2AAAA ZAAAADYAAABkAAAAZLRiAIqJCjBctGIACAAAAGYSAADACQAA4vz//7L///8BAAAAcAD7AwgA AAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAA HwAHBDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAAAMtmIADLZiAAEAAAAAAAAAxBEAAFwK AAAAAAAAAAAAAAAA//8/ANkPDAAAAAAA2g8EAAAAAAAlAA8A8A8WBAAAAADzAxQAAAADAAAA BAAAAAIAAAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqA8bAAAARGl2ZXJzaW9uIEluZGljYXRp b24gaW4gU0lQEACfDwQAAAAFAAAAAACoDyUAAABTdGV2ZSBMZXZ5DUJyeWFuIEouIEJ5ZXJs eQ1KLiBSLiBZYW5nAADzAxQAAAAKAAAABAAAAAMAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAA qA8WAAAAUHJvYmxlbSBhbmQgT2JqZWN0aXZlcxAAnw8EAAAABwAAAAAAqA+uAAAAUHJvYmxl bQ1VbHRpbWF0ZWx5IGNhbGxlZCAodGhpcmQtcGFydHkpIFNJUCB1c2VyIGFnZW50IGlzIHVu YWJsZSB0byByZWxpYWJseSBkZXRlcm1pbmUgZnJvbSB3aG9tIHRoZSBjYWxsIHdhcyBkaXZl cnRlZCBhbmQgd2h5IHRoZSBjYWxsIHdhcyBkaXZlcnRlZC4NRXhhbXBsZXM6IFZvaWNlbWFp bCwgQUNEAAChD1IAAAAIAAAAAAAAAAAApwAAAAEAAAAAAAgAAAAAAAAATwAAAAAAAgAUAAkA AAABAAIAgQAUABsAAAAAAAIAFAADAAAAAQACAIEAFAAxAAAAAAACABQAIACfDwQAAAAHAAAA AACoD2IAAABDaGFsbGVuZ2VzDU11bHRpcGxlIGRpdmVyc2lvbnMNUHJpdmF0ZSBudW1iZXJp bmcgcGxhbnMNSW50ZXJvcGVyYWJpbGl0eSB3aXRoIGxlZ2FjeSBQU1ROIGRpdmVyc2lvbgAA oQ8mAAAACwAAAAAAAAAAAFgAAAABAAAAAAALAAAAAAAAAFgAAAAAAAIAFAAAAPMDFAAAAAcA AAAEAAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDxoAAABDRk5BIHdpdGggRGl2ZXJz aW9uIGhlYWRlcgAAoQ8cAAAAGwAAAAAAAAAAABoAAAAAAAIAJAABAAAAAAAAABAAnw8EAAAA AQAAAAAAqg8KAAAAAQAAAAEAAAAAAAAA8wMUAAAACAAAAAAAAAACAAAAAwEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPEwAAAFByb3Bvc2VkIG5leHQgc3RlcHMQAJ8PBAAAAAEAAAAAAKgPHAAA AFNJUCBXRyBpdGVtDVN0YW5kYXJkcyB0cmFjaw0AAKoPEgAAABwAAAAAAAAAAQAAAAEAAAAA AAAA8wMUAAAACQAAAAAAAAACAAAABAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPEwAAAFByb3Bv c2VkIG5leHQgc3RlcHMQAJ8PBAAAAAEAAAAAAKgPHAAAAFNJUCBXRyBpdGVtDVN0YW5kYXJk cyB0cmFjaw0AAOoDAAAAAAAAchcIAAAAAQAQAJVGAAAAAPUPHAAAAAABAACSDgADcUYAAN5P AAABAAAACgAAAAEAYgAPAOgDQQkAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAA AAAAAAAAAAABAAAAAAAAAQ8A8gMgAgAALwDIDwwAAAAwANIPBAAAAAAAAAAPANUHfAEAAAAA tw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAAMtmIADLZiADS0YgAEiQow WLRiAAgAAABYtGIAiokKMAAABBIQALcPRAAAAEEAcgBpAGEAbAAgAEIAbABhAGMAawAAAG0A YQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAQiIAC3D0QAAABUAGEA aABvAG0AYQAAAGwAYQBjAGsAAABtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0 YgCKiQowAAAEIjAAtw9EAAAATQBvAG4AbwB0AHkAcABlACAAUwBvAHIAdABzAAAAAAAMtmIA DLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAIABAJAALcPRAAAAEEAcgBpAGEAbAAAAHAA ZQAgAFMAbwByAHQAcwAAAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAQi AACpDwoAAAAHAAAAAgAJBAAAQACjDwEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAA CQAAAAoAAAALAAAADAAAAP7////+//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////v8AAAQA AgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgA Kyz5rpQCAABQAgAAEAAAAAEAAACIAAAAAwAAAJAAAAAPAAAAqAAAAAQAAAC0AAAABgAAALwA AAAHAAAAxAAAAAgAAADMAAAACQAAANQAAAAKAAAA3AAAABcAAADkAAAACwAAAOwAAAAQAAAA 9AAAABMAAAD8AAAAFgAAAAQBAAANAAAADAEAAAwAAADwAQAAAgAAAOQEAAAeAAAADwAAAE9u LXNjcmVlbiBTaG93AAAeAAAAAgAAACAALXMDAAAAP7sAAAMAAAApAAAAAwAAAAQAAAADAAAA AAAAAAMAAAAAAAAAAwAAAAAAAAADAAAAsw0IAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsA AAAAAAAAHhAAAAoAAAAQAAAAVGltZXMgTmV3IFJvbWFuAAwAAABBcmlhbCBCbGFjawAHAAAA VGFob21hAA8AAABNb25vdHlwZSBTb3J0cwAGAAAAQXJpYWwAGgAAAENvbnRlbXBvcmFyeSBQ b3J0cmFpdC5wb3QAHAAAAERpdmVyc2lvbiBJbmRpY2F0aW9uIGluIFNJUAAXAAAAUHJvYmxl bSBhbmQgT2JqZWN0aXZlcwAbAAAAQ0ZOQSB3aXRoIERpdmVyc2lvbiBoZWFkZXIAFAAAAFBy b3Bvc2VkIG5leHQgc3RlcHMADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQAAwAAAAUAAAAe AAAAEAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAAAAU2xpZGUgVGl0bGVzAAMA AAAEAAAAmAAAAAMAAAAAAAAAIAAAAAEAAAA2AAAAAgAAAD4AAAABAAAAAgAAAAoAAABfUElE X0dVSUQAAgAAAOQEAABBAAAATgAAAHsARgBFAEEARQBFAEYAMAAwAC0AQwBEAEUAMQAtADEA MQBEADQALQA4AEIARQBFAC0ANAA0ADQANQA1ADMANQA0ADAAMAAwADAAfQAAAAAAAAA1ADMA NQA0ADAAMAAwADAAfQAAAAAA9g8iAAAAFAAAAF/AkeMbuwAACgD0AwMAYgBNZWRzY2hvbGFy CAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPYPIgAAABQAAABfwJHj1psAAAoA9AMDAAAA TWVkc2Nob2xhcggAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACfDwQAAAAF AAAAAACoDyUAAABTdGV2ZSBMZXZ5DUJyeWFuIEouIEJ5ZXJseQ1KLiBSLiBZYW5nAADzAxQA AAAKAAAABAAAAAMAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8WAAAAUHJvYmxlbSBhbmQg T2JqZWN0aXZlcxAAnw8EAAAABwAAAAAAqA+uAAAAUHJvYmxlbQ1VbHRpbWF0ZWx5IGNhbGxl ZCAodGhpcmQtcGFydHkpIFNJUCB1c2VyIGFnZW50IGlzIHVuYWJsZSB0byByZWxpYWJseSBk ZXRlcm1pbmUgZnJvbSB3aG9tIHRoZSBjYWxsIHdhcyBkaXZlcnRlZCBhbmQgd2h5IHRoZSBj YWxsIHdhcyBkaXZlcnRlZC4NRXhhbXBsZXM6IFZvaWNlbWFpbCwgQUNEAAChD1IAAAAIAAAA AAAAAAAApwAAAAEAAAAAAAgAAAAAAAAATwAAAAAAAgAUAAkAAAABAAIAgQAUABsAAAAAAAIA FAADAAAAAQACAIEAFAAxAAAAAAACABQAIACfDwQAAAAHAAAAAACoD2IAAABDaGFsbGVuZ2Vz DU11bHRpcGxlIGRpdmVyc2lvbnMNUHJpdmF0ZSBudW1iZXJpbmcgcGxhbnMNSW50ZXJvcGVy YWJpbGl0eSB3aXRoIGxlZ2FjeSBQU1ROIGRpdmVyc2lvbgAAoQ8mAAAACwAAAAAAAAAAAFgA AAABAAAAAAALAAAAAAAAAFgAAAAAAAIAFAAAAPMDFAAAAAcAAAAEAAAAAgAAAAIBAAAAAAAA AACfDwQAAAAAAAAAAACoDxoAAABDRk5BIHdpdGggRGl2ZXJzaW9uIGhlYWRlcgAAoQ8cAAAA GwAAAAAAAAAAABoAAAAAAAIAJAABAAAAAAAAABAAnw8EAAAAAQAAAAAAqg8KAAAAAQAAAAEA AAAAAAAA8wMUAAAACAAAAAAAAAACAAAAAwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPEwAAAFBy b3Bvc2VkIG5leHQgc3RlcHMQAJ8PBAAAAAEAAAAAAKgPHAAAAFNJUCBXRyBpdGVtDVN0YW5k YXJkcyB0cmFjaw0AAKoPEgAAABwAAAAAAAAAAQAAAAEAAAAAAAAA8wMUAAAACQAAAAAAAAAC AAAABAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPEwAAAFByb3Bvc2VkIG5leHQgc3RlcHMQAJ8P BAAAAAEAAAAAAKgPHAAAAFNJUCBXRyBpdGVtDVN0YW5kYXJkcyB0cmFjaw0AAOoDAAAAAAAA chcIAAAAAQAQAIlsAAAAAPUPHAAAAAABAACSDgADZWwAANJ1AAABAAAACgAAAAEAYgAPAOgD QQkAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAAAAAAAAAAAAABAAAAAAAAAQ8A 8gMgAgAALwDIDwwAAAAwANIPBAAAAAAAAAAPANUHfAEAAAAAtw9EAAAAVABpAG0AZQBzACAA TgBlAHcAIABSAG8AbQBhAG4AAAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAA BBIQALcPRAAAAEEAcgBpAGEAbAAgAEIAbABhAGMAawAAAG0AYQBuAAAADLZiAAy2YgA0tGIA BIkKMFi0YgAIAAAAWLRiAIqJCjAAAAQiIAC3D0QAAABUAGEAaABvAG0AYQAAAGwAYQBjAGsA AABtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAEIjAAtw9EAAAA TQBvAG4AbwB0AHkAcABlACAAUwBvAHIAdABzAAAAAAAMtmIADLZiADS0YgAEiQowWLRiAAgA AABYtGIAiokKMAIABAJAALcPRAAAAEEAcgBpAGEAbAAAAHAAZQAgAFMAbwByAHQAcwAAAAAA DLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAQiAACpDwoAAAAHAAAAAgAJBAAA QACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAA AAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAF AACABIAEAAAAAA8ACwSQAQAADwAA8IgBAAAAAAbwWAAAAAckAAAKAAAAYgAAAAcAAAAAAAAA BwAAAAEAAAAFAAAAAQAAAAgAAAAEAAAACAAAAAMAAAAEAAAAAgAAACwBAAAGAAAABAAAAAcA AAAEAAAACAAAAAcAAABfAAHw3AAAAGIAB/AkAAAABgYR7sQXyb8oYT6I38Mr+A4s/wAPDQAA AgAAAAAAAAAAAMsAcgAH8CQAAAAHB0zgdhSNXbHZihTz8974T8H/ADELAAACAAAADw0AAAAA ywByAAfwJAAAAAcH6FaaK0EAIQn8FQr+OMcXyv8A8QoAAAEAAABAGAAAAADLAHIAB/AkAAAA BwckT+fs6f0b7EctZuYlwj4c/wBVCgAAAwAAADEjAAAAAMsAcgAH8CQAAAAHB8Wsp1cctk2R 145mPzALv/D/ADkKAAABAAAAhi0AAAAAywBjAAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMAB AQAACP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A84AAAAAADzAxQA AAAEAAAABAAAAAAAAAABAACAAAAAAAAA8wMUAAAABQAAAAQAAAAAAAAAAgAAgAAAAAAPANAH zwAAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAADYAAABkAAAANgAAAGQAAABktGIAiokK MFy0YgAIAAAAZhIAAMAJAADi/P//sv///wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAAB AAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfAAcEPAAAAAAA/QM0AAAAIQAA AGQAAAAhAAAAZAAAAAy2YgAMtmIAAQAAAAAAAADEEQAAXAoAAAAAAAAAAAAAAAD//z8A2Q8M AAAAAADaDwQAAAAAACUADwDwDxYEAAAAAPMDFAAAAAMAAAAEAAAAAgAAAAABAAAAAAAAAACf DwQAAAAGAAAAAACoDxsAAABEaXZlcnNpb24gSW5kaWNhdGlvbiBpbiBTSVAQAJ8PBAAAAAUA AAAAAKgPJQAAAFN0ZXZlIExldnkNQnJ5YW4gSi4gQnllcmx5DUouIFIuIFlhbmcAAPMDFAAA AAoAAAAEAAAAAwAAAAUBAAAAAAAAAACfDwQAAAAAAAAAAACoDxYAAABQcm9ibGVtIGFuZCBP YmplY3RpdmVzEACfDwQAAAAHAAAAAACoD64AAABQcm9ibGVtDVVsdGltYXRlbHkgY2FsbGVk ICh0aGlyZC1wYXJ0eSkgU0lQIHVzZXIgYWdlbnQgaXMgdW5hYmxlIHRvIHJlbGlhYmx5IGRl dGVybWluZSBmcm9tIHdob20gdGhlIGNhbGwgd2FzIGRpdmVydGVkIGFuZCB3aHkgdGhlIGNh bGwgd2FzIGRpdmVydGVkLg1FeGFtcGxlczogVm9pY2VtYWlsLCBBQ0QAAKEPUgAAAAgAAAAA AAAAAACnAAAAAQAAAAAACAAAAAAAAABPAAAAAAACABQACQAAAAEAAgCBABQAGwAAAAAAAgAU AAMAAAABAAIAgQAUADEAAAAAAAIAFAAgAJ8PBAAAAAcAAAAAAKgPYgAAAENoYWxsZW5nZXMN TXVsdGlwbGUgZGl2ZXJzaW9ucw1Qcml2YXRlIG51bWJlcmluZyBwbGFucw1JbnRlcm9wZXJh YmlsaXR5IHdpdGggbGVnYWN5IFBTVE4gZGl2ZXJzaW9uAAChDyYAAAALAAAAAAAAAAAAWAAA AAEAAAAAAAsAAAAAAAAAWAAAAAAAAgAUAAAA8wMUAAAABwAAAAQAAAACAAAAAgEAAAAAAAAA AJ8PBAAAAAAAAAAAAKgPGgAAAENGTkEgd2l0aCBEaXZlcnNpb24gaGVhZGVyAAChDxwAAAAb AAAAAAAAAAAAGgAAAAAAAgAkAAEAAAAAAAAAEACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAA AAAAAADzAxQAAAAIAAAAAAAAAAIAAAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8TAAAAUHJv cG9zZWQgbmV4dCBzdGVwcxAAnw8EAAAAAQAAAAAAqA8cAAAAU0lQIFdHIGl0ZW0NU3RhbmRh cmRzIHRyYWNrDQAAqg8SAAAAHAAAAAAAAAABAAAAAQAAAAAAAADzAxQAAAAJAAAAAAAAAAIA AAAEAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8TAAAAUHJvcG9zZWQgbmV4dCBzdGVwcxAAnw8E AAAAAQAAAAAAqA8cAAAAU0lQIFdHIGl0ZW0NU3RhbmRhcmRzIHRyYWNrDQAA6gMAAAAAAABy FwgAAAABABAABnYAAAAA9Q8cAAAAAAEAAJIOAAPidQAAT38AAAEAAAAKAAAAAQBiAA8A6ANB CQAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDy AyACAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1Qd8AQAAAAC3D0QAAABUAGkAbQBlAHMAIABO AGUAdwAgAFIAbwBtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAE EhAAtw9EAAAAQQByAGkAYQBsACAAQgBsAGEAYwBrAAAAbQBhAG4AAAAMtmIADLZiADS0YgAE iQowWLRiAAgAAABYtGIAiokKMAAABCIgALcPRAAAAFQAYQBoAG8AbQBhAAAAbABhAGMAawAA AG0AYQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAQiMAC3D0QAAABN AG8AbgBvAHQAeQBwAGUAIABTAG8AcgB0AHMAAAAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAA AFi0YgCKiQowAgAEAkAAtw9EAAAAQQByAGkAYQBsAAAAcABlACAAUwBvAHIAdABzAAAAAAAM tmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABCIAAKkPCgAAAAcAAAACAAkEAABA AKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAA AP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUA AIAEgAQAAAAADwALBJABAAAPAADwiAEAAAAABvBYAAAAByQAAAoAAABiAAAABwAAAAAAAAAH AAAAAQAAAAUAAAABAAAACAAAAAQAAAAIAAAAAwAAAAQAAAACAAAALAEAAAYAAAAEAAAABwAA AAQAAAAIAAAABwAAAF8AAfDcAAAAYgAH8CQAAAAGBhHuxBfJvyhhPojfwyv4Diz/AA8NAAAC AAAAAAAAAAAAywByAAfwJAAAAAcHTOB2FI1dsdmKFPPz3vhPwf8AMQsAAAIAAAAPDQAAAADL AHIAB/AkAAAABwfoVporQQAhCfwVCv44xxfK/wDxCgAAAQAAAEAYAAAAAMsAcgAH8CQAAAAH ByRP5+zp/RvsRy1m5iXCPhz/AFUKAAADAAAAMSMAAAAAywByAAfwJAAAAAcHxaynVxy2TZHX jmY/MAu/8P8AOQoAAAEAAACGLQAAAADLAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEB AAAI/wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDzgAAAAAAPMDFAAA AAQAAAAEAAAAAAAAAAEAAIAAAAAAAADzAxQAAAAFAAAABAAAAAAAAAACAACAAAAAAA8A0AfP AAAADwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAANgAAAGQAAAA2AAAAZAAAAGS0YgCKiQow XLRiAAgAAABmEgAAwAkAAOL8//+y////AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEA AABACwAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ABwQ8AAAAAAD9AzQAAAAhAAAA ZAAAACEAAABkAAAADLZiAAy2YgABAAAAAAAAAMQRAABcCgAAAAAAAAAAAAAAAP//PwDZDwwA AAAAANoPBAAAAAAAJQAPAPAPFgQAAAAA8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8P BAAAAAYAAAAAAKgPGwAAAERpdmVyc2lvbiBJbmRpY2F0aW9uIGluIFNJUBAAnw8EAAAABQAA AAAAqA8lAAAAU3RldmUgTGV2eQ1CcnlhbiBKLiBCeWVybHkNSi4gUi4gWWFuZwAA8wMUAAAA CgAAAAQAAAADAAAABQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFgAAAFByb2JsZW0gYW5kIE9i amVjdGl2ZXMQAJ8PBAAAAAcAAAAAAKgPrgAAAFByb2JsZW0NVWx0aW1hdGVseSBjYWxsZWQg KHRoaXJkLXBhcnR5KSBTSVAgdXNlciBhZ2VudCBpcyB1bmFibGUgdG8gcmVsaWFibHkgZGV0 ZXJtaW5lIGZyb20gd2hvbSB0aGUgY2FsbCB3YXMgZGl2ZXJ0ZWQgYW5kIHdoeSB0aGUgY2Fs bCB3YXMgZGl2ZXJ0ZWQuDUV4YW1wbGVzOiBWb2ljZW1haWwsIEFDRAAAoQ9SAAAACAAAAAAA AAAAAKcAAAABAAAAAAAIAAAAAAAAAE8AAAAAAAIAFAAJAAAAAQACAIEAFAAbAAAAAAACABQA AwAAAAEAAgCBABQAMQAAAAAAAgAUACAAnw8EAAAABwAAAAAAqA9iAAAAQ2hhbGxlbmdlcw1N dWx0aXBsZSBkaXZlcnNpb25zDVByaXZhdGUgbnVtYmVyaW5nIHBsYW5zDUludGVyb3BlcmFi aWxpdHkgd2l0aCBsZWdhY3kgUFNUTiBkaXZlcnNpb24AAKEPJgAAAAsAAAAAAAAAAABYAAAA AQAAAAAACwAAAAAAAABYAAAAAAACABQAAADzAxQAAAAHAAAABAAAAAIAAAACAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8aAAAAQ0ZOQSB3aXRoIERpdmVyc2lvbiBoZWFkZXIAAKEPHAAAABsA AAAAAAAAAAAaAAAAAAACACQAAQAAAAAAAAAQAJ8PBAAAAAEAAAAAAKoPCgAAAAEAAAABAAAA AAAAAPMDFAAAAAgAAAAAAAAAAgAAAAMBAAAAAAAAAACfDwQAAAAAAAAAAACoDxMAAABQcm9w b3NlZCBuZXh0IHN0ZXBzEACfDwQAAAABAAAAAACoDxwAAABTSVAgV0cgaXRlbQ1TdGFuZGFy ZHMgdHJhY2sNAACqDxIAAAAcAAAAAAAAAAEAAAABAAAAAAAAAPMDFAAAAAkAAAAAAAAAAgAA AAQBAAAAAAAAAACfDwQAAAAAAAAAAACoDxMAAABQcm9wb3NlZCBuZXh0IHN0ZXBzEACfDwQA AAABAAAAAACoDxwAAABTSVAgV0cgaXRlbQ1TdGFuZGFyZHMgdHJhY2sNAADqAwAAAAAAAHIX CAAAAAEAEACDfwAAAAD1DxwAAAAAAQAAkg4AA19/AADMiAAAAQAAAAoAAAABAGIADwDoA0EJ AAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPID IAIAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB3wBAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4A ZQB3ACAAUgBvAG0AYQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAYS EAC3D0QAAABBAHIAaQBhAGwAIABCAGwAYQBjAGsAAABtAGEAbgAAAAy2YgAMtmIANLRiAASJ CjBYtGIACAAAAFi0YgCKiQowAAAGIiAAtw9EAAAAVABhAGgAbwBtAGEAAABsAGEAYwBrAAAA bQBhAG4AAAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABiIwALcPRAAAAE0A bwBuAG8AdAB5AHAAZQAgAFMAbwByAHQAcwAAAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAA WLRiAIqJCjACAAYCQAC3D0QAAABBAHIAaQBhAGwAAABwAGUAIABTAG8AcgB0AHMAAAAAAAy2 YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAGIgAAqQ8KAAAABwAAAAIACQQAAEAA ow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA ////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAA gASABAAAAAAPAAsEkAEAAA8AAPCIAQAAAAAG8FgAAAACLAAACgAAAGIAAAAHAAAAAAAAAAcA AAABAAAABQAAAAEAAAAIAAAAAwAAAAgAAAACAAAABAAAAAUAAAAsAQAABgAAAAQAAAAHAAAA BAAAAAQAAAAHAAAAXwAB8NwAAABiAAfwJAAAAAYGEe7EF8m/KGE+iN/DK/gOLP8ADw0AAAIA AAAAAAAAAABeAXIAB/AkAAAABwdM4HYUjV2x2YoU8/Pe+E/B/wAxCwAAAgAAAA8NAAAAAF4B cgAH8CQAAAAHB+hWmitBACEJ/BUK/jjHF8r/APEKAAABAAAAQBgAAAAAXgFyAAfwJAAAAAcH JE/n7On9G+xHLWbmJcI+HP8AVQoAAAMAAAAxIwAAAABeAXIAB/AkAAAABwfFrKdXHLZNkdeO Zj8wC7/w/wA5CgAAAQAAAIYtAAAAAF4BYwAL8CQAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEA AAj/AQgACAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPOAAAAAAA8wMUAAAA BAAAAAQAAAAAAAAAAQAAgAAAAAAAAPMDFAAAAAUAAAAEAAAAAAAAAAIAAIAAAAAADwDQB88A AAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAAA2AAAAZAAAADYAAABkAAAAZLRiAIqJCjBc tGIACAAAAGYSAADACQAA4vz//7L///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAA AEALAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwAHBDwAAAAAAP0DNAAAACEAAABk AAAAIQAAAGQAAAAMtmIADLZiAAEAAAAAAAAAxBEAAFwKAAAAAAAAAAAAAAAA//8/ANkPDAAA AAAA2g8EAAAAAAAlAA8A8A8WBAAAAADzAxQAAAADAAAABAAAAAIAAAAAAQAAAAAAAAAAnw8E AAAABgAAAAAAqA8bAAAARGl2ZXJzaW9uIEluZGljYXRpb24gaW4gU0lQEACfDwQAAAAFAAAA AACoDyUAAABTdGV2ZSBMZXZ5DUJyeWFuIEouIEJ5ZXJseQ1KLiBSLiBZYW5nAADzAxQAAAAK AAAABAAAAAMAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8WAAAAUHJvYmxlbSBhbmQgT2Jq ZWN0aXZlcxAAnw8EAAAABwAAAAAAqA+uAAAAUHJvYmxlbQ1VbHRpbWF0ZWx5IGNhbGxlZCAo dGhpcmQtcGFydHkpIFNJUCB1c2VyIGFnZW50IGlzIHVuYWJsZSB0byByZWxpYWJseSBkZXRl cm1pbmUgZnJvbSB3aG9tIHRoZSBjYWxsIHdhcyBkaXZlcnRlZCBhbmQgd2h5IHRoZSBjYWxs IHdhcyBkaXZlcnRlZC4NRXhhbXBsZXM6IFZvaWNlbWFpbCwgQUNEAAChD1IAAAAIAAAAAAAA AAAApwAAAAEAAAAAAAgAAAAAAAAATwAAAAAAAgAUAAkAAAABAAIAgQAUABsAAAAAAAIAFAAD AAAAAQACAIEAFAAxAAAAAAACABQAIACfDwQAAAAHAAAAAACoD2IAAABDaGFsbGVuZ2VzDU11 bHRpcGxlIGRpdmVyc2lvbnMNUHJpdmF0ZSBudW1iZXJpbmcgcGxhbnMNSW50ZXJvcGVyYWJp bGl0eSB3aXRoIGxlZ2FjeSBQU1ROIGRpdmVyc2lvbgAAoQ8mAAAACwAAAAAAAAAAAFgAAAAB AAAAAAALAAAAAAAAAFgAAAAAAAIAFAAAAPMDFAAAAAcAAAAEAAAAAgAAAAIBAAAAAAAAAACf DwQAAAAAAAAAAACoDxoAAABDRk5BIHdpdGggRGl2ZXJzaW9uIGhlYWRlcgAAoQ8cAAAAGwAA AAAAAAAAABoAAAAAAAIAJAABAAAAAAAAABAAnw8EAAAAAQAAAAAAqg8KAAAAAQAAAAEAAAAA AAAA8wMUAAAACAAAAAAAAAACAAAAAwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPEwAAAFByb3Bv c2VkIG5leHQgc3RlcHMQAJ8PBAAAAAEAAAAAAKgPHAAAAFNJUCBXRyBpdGVtDVN0YW5kYXJk cyB0cmFjaw0AAKoPEgAAABwAAAAAAAAAAQAAAAEAAAAAAAAA8wMUAAAACQAAAAAAAAACAAAA BAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPEwAAAFByb3Bvc2VkIG5leHQgc3RlcHMQAJ8PBAAA AAEAAAAAAKgPHAAAAFNJUCBXRyBpdGVtDVN0YW5kYXJkcyB0cmFjaw0AAOoDAAAAAAAAchcI AAAAAQAQAACJAAAAAPUPHAAAAAQBAACSDgAD3IgAAEmSAAABAAAACgAAAAEAYgAPAOgDQQkA AAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAAAAAAAAAAAAABAAAAAAAAAQ8A8gMg AgAALwDIDwwAAAAwANIPBAAAAAAAAAAPANUHfAEAAAAAtw9EAAAAVABpAG0AZQBzACAATgBl AHcAIABSAG8AbQBhAG4AAAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABhIQ ALcPRAAAAEEAcgBpAGEAbAAgAEIAbABhAGMAawAAAG0AYQBuAAAADLZiAAy2YgA0tGIABIkK MFi0YgAIAAAAWLRiAIqJCjAAAAYiIAC3D0QAAABUAGEAaABvAG0AYQAAAGwAYQBjAGsAAABt AGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAGIjAAtw9EAAAATQBv AG4AbwB0AHkAcABlACAAUwBvAHIAdABzAAAAAAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABY tGIAiokKMAIABgJAALcPRAAAAEEAcgBpAGEAbAAAAHAAZQAgAFMAbwByAHQAcwAAAAAADLZi AAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAYiAACpDwoAAAAHAAAAAgAJBAAAQACj D24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAD/ //////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACA BIAEAAAAAA8ACwSQAQAADwAA8IgBAAAAAAbwWAAAAAIsAAAKAAAAYgAAAAcAAAAAAAAABwAA AAEAAAAFAAAAAQAAAAgAAAAEAAAACAAAAAYAAAAEAAAABgAAACwBAAAHAAAABAAAAAIAAAAE AAAABAAAAAcAAABfAAHw3AAAAGIAB/AkAAAABgYR7sQXyb8oYT6I38Mr+A4s/wAPDQAAAgAA AAAAAAAAAF4BcgAH8CQAAAAHB0zgdhSNXbHZihTz8974T8H/ADELAAACAAAADw0AAAAAXgFy AAfwJAAAAAcH6FaaK0EAIQn8FQr+OMcXyv8A8QoAAAEAAABAGAAAAABeAXIAB/AkAAAABwck T+fs6f0b7EctZuYlwj4c/wBVCgAAAwAAADEjAAAAAF4BcgAH8CQAAAAHB8Wsp1cctk2R145m PzALv/D/ADkKAAABAAAAhi0AAAAAXgFjAAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAA CP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A84AAAAAADzAxQAAAAE AAAABAAAAAAAAAABAACAAAAAAAAA8wMUAAAABQAAAAQAAAAAAAAAAgAAgAAAAAAPANAHzwAA AA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAADYAAABkAAAANgAAAGQAAABktGIAiokKMFy0 YgAIAAAAZhIAAMAJAADi/P//sv///wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAA QAsAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQA AAAhAAAAZAAAAAy2YgAMtmIAAQAAAAAAAADEEQAAXAoAAAAAAAAAAAAAAAD//z8A2Q8MAAAA AADaDwQAAAAAACUADwDwDxYEAAAAAPMDFAAAAAMAAAAEAAAAAgAAAAABAAAAAAAAAACfDwQA AAAGAAAAAACoDxsAAABEaXZlcnNpb24gSW5kaWNhdGlvbiBpbiBTSVAQAJ8PBAAAAAUAAAAA AKgPJQAAAFN0ZXZlIExldnkNQnJ5YW4gSi4gQnllcmx5DUouIFIuIFlhbmcAAPMDFAAAAAoA AAAEAAAAAwAAAAUBAAAAAAAAAACfDwQAAAAAAAAAAACoDxYAAABQcm9ibGVtIGFuZCBPYmpl Y3RpdmVzEACfDwQAAAAHAAAAAACoD64AAABQcm9ibGVtDVVsdGltYXRlbHkgY2FsbGVkICh0 aGlyZC1wYXJ0eSkgU0lQIHVzZXIgYWdlbnQgaXMgdW5hYmxlIHRvIHJlbGlhYmx5IGRldGVy bWluZSBmcm9tIHdob20gdGhlIGNhbGwgd2FzIGRpdmVydGVkIGFuZCB3aHkgdGhlIGNhbGwg d2FzIGRpdmVydGVkLg1FeGFtcGxlczogVm9pY2VtYWlsLCBBQ0QAAKEPUgAAAAgAAAAAAAAA AACnAAAAAQAAAAAACAAAAAAAAABPAAAAAAACABQACQAAAAEAAgCBABQAGwAAAAAAAgAUAAMA AAABAAIAgQAUADEAAAAAAAIAFAAgAJ8PBAAAAAcAAAAAAKgPYgAAAENoYWxsZW5nZXMNTXVs dGlwbGUgZGl2ZXJzaW9ucw1Qcml2YXRlIG51bWJlcmluZyBwbGFucw1JbnRlcm9wZXJhYmls aXR5IHdpdGggbGVnYWN5IFBTVE4gZGl2ZXJzaW9uAAChDyYAAAALAAAAAAAAAAAAWAAAAAEA AAAAAAsAAAAAAAAAWAAAAAAAAgAUAAAA8wMUAAAABwAAAAQAAAACAAAAAgEAAAAAAAAAAJ8P BAAAAAAAAAAAAKgPGgAAAENGTkEgd2l0aCBEaXZlcnNpb24gaGVhZGVyAAChDxwAAAAbAAAA AAAAAAAAGgAAAAAAAgAkAAEAAAAAAAAAEACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAAAAAA AADzAxQAAAAIAAAAAAAAAAIAAAADAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8TAAAAUHJvcG9z ZWQgbmV4dCBzdGVwcxAAnw8EAAAAAQAAAAAAqA8cAAAAU0lQIFdHIGl0ZW0NU3RhbmRhcmRz IHRyYWNrDQAAqg8SAAAAHAAAAAAAAAABAAAAAQAAAAAAAADzAxQAAAAJAAAAAAAAAAIAAAAE AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8TAAAAUHJvcG9zZWQgbmV4dCBzdGVwcxAAnw8EAAAA AQAAAAAAqA8cAAAAU0lQIFdHIGl0ZW0NU3RhbmRhcmRzIHRyYWNrDQAA6gMAAAAAAAByFwgA AAABABAAfZIAAAAA9Q8cAAAAAAEAAJIOAANZkgAAxpsAAAEAAAAKAAAAAQBiAA8A6AOzCAAA AQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyAyAC AAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1Qd8AQAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUA dwAgAFIAbwBtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAQAEABAA tw9EAAAAQQByAGkAYQBsACAAQgBsAGEAYwBrAAAAbQBhAG4AAAAMtmIADLZiADS0YgAEiQow WLRiAAgAAABYtGIAiokKMAAABiIgALcPRAAAAFQAYQBoAG8AbQBhAAAAbABhAGMAawAAAG0A YQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAYiMAC3D0QAAABNAG8A bgBvAHQAeQBwAGUAIABTAG8AcgB0AHMAAAAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0 YgCKiQowAgAGAkAAtw9EAAAAQQByAGkAYQBsAAAAcABlACAAUwBvAHIAdABzAAAAAAAMtmIA DLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABiIAAKkPCgAAAAcAAAACAAkEAABAAKMP bgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP// /////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAE gAQAAAAADwALBJABAAAPAADwiAEAAAAABvBYAAAAAiwAAAoAAABfAAAABgAAAAAAAAAHAAAA AQAAAAUAAAABAAAACAAAAAMAAAAIAAAABgAAAAQAAAAFAAAALAEAAAYAAAAEAAAABQAAAAQA AAADAAAABwAAAF8AAfDcAAAAYgAH8CQAAAAGBhHuxBfJvyhhPojfwyv4Diz/AA8NAAACAAAA AAAAAAAAywByAAfwJAAAAAcHTOB2FI1dsdmKFPPz3vhPwf8AMQsAAAIAAAAPDQAAAADLAHIA B/AkAAAABwfoVporQQAhCfwVCv44xxfK/wDxCgAAAQAAAEAYAAAAAMsAcgAH8CQAAAAHByRP 5+zp/RvsRy1m5iXCPhz/AFUKAAADAAAAMSMAAAAAywByAAfwJAAAAAcHxaynVxy2TZHXjmY/ MAu/8P8AOQoAAAEAAACGLQAAAADLAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI /wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDzgAAAAAAPMDFAAAAAQA AAAEAAAAAAAAAAEAAIAAAAAAAADzAxQAAAAFAAAABAAAAAAAAAACAACAAAAAAA8A0AfPAAAA DwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAANgAAAGQAAAA2AAAAZAAAAGS0YgCKiQowXLRi AAgAAABmEgAAwAkAAOL8//+y////AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABA CwAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAA ACEAAABkAAAADLZiAAy2YgABAAAAAAAAAMQRAABcCgAAAAAAAAAAAAAAAP//PwDZDwwAAAAA ANoPBAAAAAAAJQAPAPAPiAMAAAAA8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAA AAYAAAAAAKgPGwAAAERpdmVyc2lvbiBJbmRpY2F0aW9uIGluIFNJUBAAnw8EAAAABQAAAAAA qA8lAAAAU3RldmUgTGV2eQ1CcnlhbiBKLiBCeWVybHkNSi4gUi4gWWFuZwAA8wMUAAAACgAA AAQAAAADAAAABQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFgAAAFByb2JsZW0gYW5kIE9iamVj dGl2ZXMQAJ8PBAAAAAcAAAAAAKgPrgAAAFByb2JsZW0NVWx0aW1hdGVseSBjYWxsZWQgKHRo aXJkLXBhcnR5KSBTSVAgdXNlciBhZ2VudCBpcyB1bmFibGUgdG8gcmVsaWFibHkgZGV0ZXJt aW5lIGZyb20gd2hvbSB0aGUgY2FsbCB3YXMgZGl2ZXJ0ZWQgYW5kIHdoeSB0aGUgY2FsbCB3 YXMgZGl2ZXJ0ZWQuDUV4YW1wbGVzOiBWb2ljZW1haWwsIEFDRAAAoQ9SAAAACAAAAAAAAAAA AKcAAAABAAAAAAAIAAAAAAAAAE8AAAAAAAIAFAAJAAAAAQACAIEAFAAbAAAAAAACABQAAwAA AAEAAgCBABQAMQAAAAAAAgAUACAAnw8EAAAABwAAAAAAqA9iAAAAQ2hhbGxlbmdlcw1NdWx0 aXBsZSBkaXZlcnNpb25zDVByaXZhdGUgbnVtYmVyaW5nIHBsYW5zDUludGVyb3BlcmFiaWxp dHkgd2l0aCBsZWdhY3kgUFNUTiBkaXZlcnNpb24AAKEPJgAAAAsAAAAAAAAAAABYAAAAAQAA AAAACwAAAAAAAABYAAAAAAACABQAAADzAxQAAAAHAAAABAAAAAIAAAACAQAAAAAAAAAAnw8E AAAAAAAAAAAAqA8aAAAAQ0ZOQSB3aXRoIERpdmVyc2lvbiBoZWFkZXIAAKEPHAAAABsAAAAA AAAAAAAaAAAAAAACACQAAQAAAAAAAAAQAJ8PBAAAAAEAAAAAAKoPCgAAAAEAAAABAAAAAAAA APMDFAAAAAgAAAAAAAAAAgAAAAMBAAAAAAAAAACfDwQAAAAAAAAAAACoDxMAAABQcm9wb3Nl ZCBuZXh0IHN0ZXBzEACfDwQAAAABAAAAAACoDxsAAABTSVAgV0cgaXRlbQ1TdGFuZGFyZHMg dHJhY2sAAOoDAAAAAAAAchcIAAAAAQAQAPqbAAAAAPUPHAAAAAMBAACSDgAD1psAALWkAAAB AAAACgAAAAcAJzAPAOgDswgAAAEA6QMoAAAAgBYAAOAQAADgEAAAgBYAAAUAAAAKAAAAAAAA AAAAAAABAAAAAAAAAQ8A8gMgAgAALwDIDwwAAAAwANIPBAAAAAAAAAAPANUHfAEAAAAAtw9E AAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAAMtmIADLZiADS0YgAEiQowWLRi AAgAAABYtGIAiokKMAEABAAQALcPRAAAAEEAcgBpAGEAbAAgAEIAbABhAGMAawAAAG0AYQBu AAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAYiIAC3D0QAAABUAGEAaABv AG0AYQAAAGwAYQBjAGsAAABtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCK iQowAAAGIjAAtw9EAAAATQBvAG4AbwB0AHkAcABlACAAUwBvAHIAdABzAAAAAAAMtmIADLZi ADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAIABgJAALcPRAAAAEEAcgBpAGEAbAAAAHAAZQAg AFMAbwByAHQAcwAAAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAYiAACp DwoAAAAHAAAAAgAJBAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQAAAAAAAAAAABA AgAAAAACAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAFAABAAkACAAAA AAAFAABgA2ADAAAAAAAFAACABIAEAAAAAA8ACwSQAQAADwAA8IgBAAAAAAbwWAAAAAIsAAAK AAAAXwAAAAYAAAAAAAAABwAAAAEAAAAFAAAAAQAAAAgAAAADAAAACAAAAAYAAAAEAAAABQAA ACwBAAAGAAAABAAAAAUAAAAEAAAAAwAAAAcAAABfAAHw3AAAAGIAB/AkAAAABgYR7sQXyb8o YT6I38Mr+A4s/wAPDQAAAgAAAAAAAAAAAMsAcgAH8CQAAAAHB0zgdhSNXbHZihTz8974T8H/ ADELAAACAAAADw0AAAAAywByAAfwJAAAAAcH6FaaK0EAIQn8FQr+OMcXyv8A8QoAAAEAAABA GAAAAADLAHIAB/AkAAAABwckT+fs6f0b7EctZuYlwj4c/wBVCgAAAwAAADEjAAAAAMsAcgAH 8CQAAAAHB8Wsp1cctk2R145mPzALv/D/ADkKAAABAAAAhi0AAAAAywBjAAvwJAAAAIEBBAAA CIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAA EB8A8A84AAAAAADzAxQAAAAEAAAABAAAAAAAAAABAACAAAAAAAAA8wMUAAAABQAAAAQAAAAA AAAAAgAAgAAAAAAPANAHzwAAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAADYAAABkAAAA NgAAAGQAAABktGIAiokKMFy0YgAIAAAAZhIAAMAJAADi/P//sv///wEAAABwAPsDCAAAAAAA AABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfAAcE PAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAAy2YgAMtmIAAQAAAAAAAADEEQAAXAoAAAAA AAAAAAAAAAD//z8A2Q8MAAAAAADaDwQAAAAAACUADwDwD4gDAAAAAPMDFAAAAAMAAAAEAAAA AgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoDxsAAABEaXZlcnNpb24gSW5kaWNhdGlvbiBp biBTSVAQAJ8PBAAAAAUAAAAAAKgPJQAAAFN0ZXZlIExldnkNQnJ5YW4gSi4gQnllcmx5DUou IFIuIFlhbmcAAPMDFAAAAAoAAAAEAAAAAwAAAAUBAAAAAAAAAACfDwQAAAAAAAAAAACoDxYA AABQcm9ibGVtIGFuZCBPYmplY3RpdmVzEACfDwQAAAAHAAAAAACoD64AAABQcm9ibGVtDVVs dGltYXRlbHkgY2FsbGVkICh0aGlyZC1wYXJ0eSkgU0lQIHVzZXIgYWdlbnQgaXMgdW5hYmxl IHRvIHJlbGlhYmx5IGRldGVybWluZSBmcm9tIHdob20gdGhlIGNhbGwgd2FzIGRpdmVydGVk IGFuZCB3aHkgdGhlIGNhbGwgd2FzIGRpdmVydGVkLg1FeGFtcGxlczogVm9pY2VtYWlsLCBB Q0QAAKEPUgAAAAgAAAAAAAAAAACnAAAAAQAAAAAACAAAAAAAAABPAAAAAAACABQACQAAAAEA AgCBABQAGwAAAAAAAgAUAAMAAAABAAIAgQAUADEAAAAAAAIAFAAgAJ8PBAAAAAcAAAAAAKgP YgAAAENoYWxsZW5nZXMNTXVsdGlwbGUgZGl2ZXJzaW9ucw1Qcml2YXRlIG51bWJlcmluZyBw bGFucw1JbnRlcm9wZXJhYmlsaXR5IHdpdGggbGVnYWN5IFBTVE4gZGl2ZXJzaW9uAAChDyYA AAALAAAAAAAAAAAAWAAAAAEAAAAAAAsAAAAAAAAAWAAAAAAAAgAUAAAA8wMUAAAABwAAAAQA AAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPGgAAAENGTkEgd2l0aCBEaXZlcnNpb24g aGVhZGVyAAChDxwAAAAbAAAAAAAAAAAAGgAAAAAAAgAkAAEAAAAAAAAAEACfDwQAAAABAAAA AACqDwoAAAABAAAAAQAAAAAAAADzAxQAAAAIAAAAAAAAAAIAAAADAQAAAAAAAAAAnw8EAAAA AAAAAAAAqA8TAAAAUHJvcG9zZWQgbmV4dCBzdGVwcxAAnw8EAAAAAQAAAAAAqA8bAAAAU0lQ IFdHIGl0ZW0NU3RhbmRhcmRzIHRyYWNrAADqAwAAAAAAAHIXCAAAAAEAEADppAAAAAD1DxwA AAADAQAAkg4AA8WkAACkrQAAAQAAAAoAAAAHACcwDwDoA9cIAAABAOkDKAAAAIAWAADgEAAA 4BAAAIAWAAAFAAAACgAAAAAAAAALAAAAAQAAAAAAAAEPAPIDIAIAAC8AyA8MAAAAMADSDwQA AAAAAAAADwDVB3wBAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAA DLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjABAAQAEAC3D0QAAABBAHIAaQBhAGwA IABCAGwAYQBjAGsAAABtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQow AAAGIiAAtw9EAAAAVABhAGgAbwBtAGEAAABsAGEAYwBrAAAAbQBhAG4AAAAMtmIADLZiADS0 YgAEiQowWLRiAAgAAABYtGIAiokKMAAABiIwALcPRAAAAE0AbwBuAG8AdAB5AHAAZQAgAFMA bwByAHQAcwAAAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjACAAYCQAC3D0QA AABBAHIAaQBhAGwAAABwAGUAIABTAG8AcgB0AHMAAAAAAAy2YgAMtmIANLRiAASJCjBYtGIA CAAAAFi0YgCKiQowAAAGIgAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAA ZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAAAAABAAAABQAA IAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEoAEAAA8A APCYAQAAAAAG8GgAAAAGLAAADAAAAGQAAAAHAAAAAAAAAAcAAAABAAAABQAAAAEAAAAIAAAA BAAAAAgAAAACAAAABAAAAAYAAAAsAQAAAgAAAAQAAAAFAAAABAAAAAMAAAAHAAAABwAAAAYA AAAAAAAABgAAAF8AAfDcAAAAYgAH8CQAAAAGBhHuxBfJvyhhPojfwyv4Diz/AA8NAAACAAAA AAAAAAAAywByAAfwJAAAAAcHTOB2FI1dsdmKFPPz3vhPwf8AMQsAAAIAAAAPDQAAAADLAHIA B/AkAAAABwfoVporQQAhCfwVCv44xxfK/wDxCgAAAQAAAEAYAAAAAMsAcgAH8CQAAAAHByRP 5+zp/RvsRy1m5iXCPhz/AFUKAAADAAAAMSMAAAAAywByAAfwJAAAAAcHxaynVxy2TZHXjmY/ MAu/8P8AOQoAAAEAAACGLQAAAADLAGMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI /wEIAAgAAQICAAAIQAAe8RAAAAAEAAAIAQAACAIAAAj3AAAQHwDwDzgAAAAAAPMDFAAAAAQA AAAEAAAAAAAAAAEAAIAAAAAAAADzAxQAAAAFAAAABAAAAAAAAAACAACAAAAAAA8A0AfPAAAA DwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAANgAAAGQAAAA2AAAAZAAAAGS0YgCKiQowXLRi AAgAAABmEgAAwAkAAOL8//+y////AQAAAHAA+wMIAAAAAAAAAHAIAABwAPsDCAAAAAEAAABA CwAAHwD/AxQAAAACAAAEDAAAAAAAAAAAAAAAAgAAAB8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAA ACEAAABkAAAADLZiAAy2YgABAAAAAAAAAMQRAABcCgAAAAAAAAAAAAAAAP//PwDZDwwAAAAA ANoPBAAAAAAAJQBPANkPDAAAAAAA2g8EAAAAAAA9AA8A8A+IAwAAAADzAxQAAAADAAAABAAA AAIAAAAAAQAAAAAAAAAAnw8EAAAABgAAAAAAqA8bAAAARGl2ZXJzaW9uIEluZGljYXRpb24g aW4gU0lQEACfDwQAAAAFAAAAAACoDyUAAABTdGV2ZSBMZXZ5DUJyeWFuIEouIEJ5ZXJseQ1K LiBSLiBZYW5nAADzAxQAAAAKAAAABAAAAAMAAAAFAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8W AAAAUHJvYmxlbSBhbmQgT2JqZWN0aXZlcxAAnw8EAAAABwAAAAAAqA+uAAAAUHJvYmxlbQ1V bHRpbWF0ZWx5IGNhbGxlZCAodGhpcmQtcGFydHkpIFNJUCB1c2VyIGFnZW50IGlzIHVuYWJs ZSB0byByZWxpYWJseSBkZXRlcm1pbmUgZnJvbSB3aG9tIHRoZSBjYWxsIHdhcyBkaXZlcnRl ZCBhbmQgd2h5IHRoZSBjYWxsIHdhcyBkaXZlcnRlZC4NRXhhbXBsZXM6IFZvaWNlbWFpbCwg QUNEAAChD1IAAAAIAAAAAAAAAAAApwAAAAEAAAAAAAgAAAAAAAAATwAAAAAAAgAUAAkAAAAB AAIAgQAUABsAAAAAAAIAFAADAAAAAQACAIEAFAAxAAAAAAACABQAIACfDwQAAAAHAAAAAACo D2IAAABDaGFsbGVuZ2VzDU11bHRpcGxlIGRpdmVyc2lvbnMNUHJpdmF0ZSBudW1iZXJpbmcg cGxhbnMNSW50ZXJvcGVyYWJpbGl0eSB3aXRoIGxlZ2FjeSBQU1ROIGRpdmVyc2lvbgAAoQ8m AAAACwAAAAAAAAAAAFgAAAABAAAAAAALAAAAAAAAAFgAAAAAAAIAFAAAAPMDFAAAAAcAAAAE AAAAAgAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDxoAAABDRk5BIHdpdGggRGl2ZXJzaW9u IGhlYWRlcgAAoQ8cAAAAGwAAAAAAAAAAABoAAAAAAAIAJAABAAAAAAAAABAAnw8EAAAAAQAA AAAAqg8KAAAAAQAAAAEAAAAAAAAA8wMUAAAACAAAAAAAAAACAAAAAwEAAAAAAAAAAJ8PBAAA AAAAAAAAAKgPEwAAAFByb3Bvc2VkIG5leHQgc3RlcHMQAJ8PBAAAAAEAAAAAAKgPGwAAAFNJ UCBXRyBpdGVtDVN0YW5kYXJkcyB0cmFjawAA6gMAAAAADwDJD0QEAAAPAAwEFAQAAA8AAvAM BAAAcAAI8AgAAAAFAAAABSgAAA8AA/CkAwAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAA AAAAAAACAArwCAAAAAAoAAAFAAAADwAE8NEAAAASAArwCAAAAAIoAAAACgAAgwAL8DAAAAB/ AAEAAQCAADSkWgGBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAA AAAAAABQByABDwAR8BAAAAAAAMMLCAAAAAAAAAAKAscADwAN8FkAAAAAAJ8PBAAAAAQAAAAA AKgPAQAAACoAAKEPFAAAAAIAAAAAAAAAAAACAAAAAAACAAwAAAD5DwQAAAAAAAAAAACqDxQA AAABAAAAAQAAAAAAAQAAAAEAAAAAAA8ABPDTAAAAEgAK8AgAAAADKAAAAAoAAIMAC/AwAAAA fwABAAEAgACUpFoBgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgA AAAAAJAJ4BAgAQ8AEfAQAAAAAADDCwgAAAABAAAABwLHAA8ADfBbAAAAAACfDwQAAAAEAAAA AACoDwEAAAAqAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAAwAAAD4DwQAAAAAAAAAAACq DxQAAAABAAAAAQAAAAAAAQAAAAEAAAAAAA8ABPDXAAAAEgAK8AgAAAAEKAAAAAoAAJMAC/A2 AAAAfwABAAEAgAD0pFoBhwACAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQIC AAAIAAAQ8AgAAABgFQAAUAeAFg8AEfAQAAAAAADDCwgAAAACAAAACQLHAA8ADfBZAAAAAACf DwQAAAAEAAAAAACoDwEAAAAqAAChDxQAAAACAAAAAAAAAAAAAgAAAAAAAgAMAAAA+g8EAAAA AAAAAAAAqg8UAAAAAQAAAAEAAAAAAAEAAAABAAAAAAAPAATw2QAAABIACvAIAAAABSgAAAAK AACTAAvwNgAAAH8AAQABAIAAVKVaAYcAAgAAAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8B AQAJAAECAgAACAAAEPAIAAAAYBWQCeAQgBYPABHwEAAAAAAAwwsIAAAAAwAAAAgCxwAPAA3w WwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAM AAAA2A8EAAAAAAAAAAAAqg8UAAAAAQAAAAEAAAAAAAEAAAABAAAAAAAPAATwSAAAABIACvAI AAAAASgAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMB3r1oAJQBjp+LAL8BEgASAP8BAAAI AAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAA AHIXEAAAAAEAEADYrQAACwAQALe2AAAAAPUPHAAAAAABAACSDgADtK0AAAO7AAABAAAACwAA AAEAYgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA --------------C01569BE03E8D00BE28611F5 Content-Type: application/ppt; name="SipAuthenticationChapPassword.ppt" Content-Disposition: inline; filename="SipAuthenticationChapPassword.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAaAAAAAAA AAAAEAAAcgAAAAEAAAD+////AAAAAGcAAAD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////8Qbh7wBw0AAA8Ye9AfA9+h7neS6NeZ0IER7sQX yb8oYT6I38Mr+A4s/4lQTkcNChoKAAAADUlIRFIAAAGQAAAAMAgDAAAACArcpAAAAANzQklU BQUFGCbeQwAAAGBQTFRFwMDA9+fe997O/+/W/7UY97Uh/70Y57Uh/84598Yp3q0Y/++1/9ZK /9Y5984x3rUh//fW/+d7/95a/95S/++l/++c/+dr/++U/+dj//e9///nAAAAAAAAAAAAAAAA AAAA4EtW2gAAAAF0Uk5TAEDm2GYAAAABYktHRP+lB/LFAAAMGElEQVR4nO2aiYKiSBKG3VnJ QyFtQAH7/R90448jMzmqprq7uqd21wC5RIX4Mk45nV7ykpe85CUveckni/unL+C/Vz5Pde5T v+0lvyzumMb/AaPz+TO+xcXtARnjnetkP7538od/5X+Fh95IdTt/4M7kJ4Ys+zOmvp/yJAt+ vSW//5o/T0KodlI6OmXF4OfG2lapQ5u6rmuHDpK6dtSpteUwFiDLJBKmIJJUImZapFB2ky7o oEkb2i9nIF13vF2J3EV1ILJ/cBUQVwfMM/msjzit5/Xa9wuN3/khB+79tAwdKYw4iLQ6Mwtl QiBM0akJNPus5pSJKA87kAHtgHw1n0WDkSh0PGFXDtKtrc4SIqmLp85cOJg43IxzPJhJU/Tq quG7Gfv3anvi5VDLONJh4jGMKwGDDrrrRELHSi6K19EfRM0pQhqeYpNsSgQNU8R2jAYHB6Jz 7oswgT10basgcKe0EbBJHiDBYREDeiulbsTZYMcTRirup1O1BNqCb8GblT7JodDYv4s8WGYI vDqpflnM7wiPcVlwFN8iw7erJe8FD5V7TE18U3AS1A0AyQcfwCMwgxolTfEjPNwuQv5sDvGO LNAJCW3CK4hL6Eao3V5tyy8sx641HB2AkKcng8kuoAsYyKTj1fAeZAFfP/fTgz1+PzMP+vFh 0V/dyMi/AwZtKDSEQRQcWMMEfNxOxgOjv/F0Ai3wBhPi7caLEA0cdP+8hTygEaAYhAiRmcxJ d2NoMxChoWvejy1808i7HHRh/+xHppGUjNE+boWByO8QDqCYsAXntObQ6jXQz5UAXAY8FjQ7 2YRmo/OsZFY53nCRMeWTBJHHrq+/ho0LND2DimYtG0WpR/6tMHhwTrJUC1nUhZOiJWsRFwLN 8HEasR3UyiMXxqD2RBxo5EZEEPIFMAH6KBvFMGZVa+4jU6oTociunB26iR6MUb38zgs1gsIW 0TuesWAGUL3nr/Bx92E76MvnG1lbyM8Tu192w0ylMIldrKjF48z7h+SuLIRKBWRQr69HaKcD EObUtaxnQAgaLXC9bBpsS1149JMB0VOFRxtqJBqNA/NQGBu1p81ag3RsYrYMGfACgwOF80nZ ZtDHcaVRT6fGxvbjXHNq7FMS7cM48oW3Lfw5JYEGQKQCgtuljSG9VRf8PZCpEs3iiYZuLOpQ lkoGzEOBJrmPeBahQZjCPFMAWeiNYFMJRMSrTS6mEF2wjCgPSefSyijUSA406oE16GJddXCw 9klnvG63G157ufACywv7qzoxaCx31pyYfCgyjX4y7bHbrbU5zwc6/iHhiLEsxmInyxrIwK9h 2fAozp+1DpVTQbEgSIdMQXMA5cIWEteewRxWiqsRypvkGzSeB4nwFYayeaP8ybe0rOTmbzd/ 05VtvS055LCB5a9n+/GD9yj2kTnTMcoAJ6n6hwH5I9JGKJVzxwdqqfv9b/Qvcr1eKfHk7GaZ 3mShNrMyjbpOGDRrajMOyblEbRRCFovOo8boNmdlbEVh46nFbRkbXhpfsTxYGi/F5MJexBiJ C02keA/VYy0ceGYsbA6CqwjjatREzs25gXCSUEWgRP5NUnv+NXQKdGS2VnIty9xTqkQJPnL8 DwGhs5FtSv5vvmrZTMZk46mWAmRQIhlJie/87eEwi91Kt3oZMthWy4kuZgFgXi+r/kYzpiCQ eI9Q4EAgS6EpeBjNjdY6s6ws6ECcbxwFpMbRq7GysobCtiM8xiH3EEYtoySDFDbLR4A8yUK4 HkOjoiZyYCBCSrPhOpQUzzVo4C5Y2r6FZcNnyZW+SaMYT8w8StXD8YhtAkzgrpBHSGIwWF3T MpQgYffG5gFScF/tjZkIChw5Fj5BXrd4uVz8ZS3+QogopXbIrBt2aI2LTjbqsKPW3aCDg0sc JLdXHWf9s87q2PN8kr+aS1r1ntNiHIeRfdXmyDofUUk+Zs7a6KS2rVzae1ZSF/5d9m4tg2i5 IuR3wq6sYWMyDLAR34qSt1K3V/Jmzgyw4en4ZSf+IkbjwMIhC6O8NxoWI9JkJGw9q0QASdJS xWMeyajTBAraFtywKEp+L4ZMWioWy1hyBNE0uHJaGh6YNZMaco2e50MkQRTfWgNgqD52KPhZ 6D3VuvfrtV+h8UE0JV1IAUMMGj7q8T00pRqEwDCL8Tejw1I1AmLuG2fg4lYNyKLBvye9k+5Z M9fncxLroHj+fGL9mPs3UawjSLaKVQQZa9PIquTBDrMarSocy+nWPNlN4+61l839FqV71ra6 HR3/QXpVWVccipu6H69cIq+o9OCuYzqze3JYqAgQoCg0VjiyZeSrk37nKgGkvJNg9NK+m2l1 Jwan79//9f0biwLpV55oFSOqzLYNw1qKxtraPDpzPiGwliVAjO2Rdjkk2kdDLuGPXUx1o1ZT hpJmlY7j9iMKhIyAEiZKkBpdlQawbeE92RZdO3FP8E5cdMqESCK9gAKkNChDqq8/30+7Ml6V B793+v6NeTy/TW+BMGuoaw3SW6hC+ApIHcsBY+g64ZmJsNUeAMkfDJbPdtu72WqXFZ7fzz3f ckSIQO2hqYSVbblSoZGJWCEoC9Y9Q/EKA5teVtHljqbMyZdr88EGy0EMqyw6C1Ug7LEk5d1z mAqQKXfBmUe7aBantCzREnISTDSsaOo35kPmr+TNzLIyKwverNJxQKuCKrHIma8sSg0Cx9wF btqEjktxeP6G1hj8OgfbEHswm6iAMCejVMwFPBpp+MJv8Y53CN7MwiZuk+F99m/nRhrJHPvP 3q+V/yaa8hcs0Xhe+V8JbX0fSS/FyBqUoBA0VpYszGPY/jldh40cKmQeq7gxGLASlSyNZgAl /WXLZwNhAl4GfxD1c6YpCJq8+jkBAzDhlWVUnO06d5YdSXv5LdT1YkNOWvdS5jvmBQvS3n7i CC/RrvCqMl/Uh2Ir03TQOelzxrtJeAkAGi5DATBLjTlvgYxj9a1V5M6gCgflNMhRPaUVyzjw YrRq1DkAxK9o/wgIU7icaXU+ny9nWWCbFjSJzp0XvZewbm7VuyR8mFl++9hI9jUiBXf4sevq KIV8PniVLJmW/Cd3bwt9eiPjmCscD3QBHsgj+jXmJdc1aAIPY44eFvY+InxfxEDGmWzARD5k E/EtBGIMZ55kBQgX46FLAkLeq3HZREr5UWdZ9eiRjTo2at9HgucBkB+Q7SMyqPev9408pMUm yR07R65I9CO5IbAYEC3rtBsS1lde7mxHzDMOL36rpsGQGv7n3I4bB/lPPebIgVEM1Zcz0L46 e6NxMSq6cy4Gkwk1uWSvpR49GylAKM8cfwnIG7IBcn9UCI+wghVcnl6zDCnNHeqqnltZ9E6b u4lrHPDGFQcpP4JSsAVnupas6RMOkclEJUVaZRyE52xyqa1it1W/K/7LxR2SPZ0VEb2h38Hj hGcVBMbHzv+L7aYfcEGPwNneYNXMqohfuPWiQOi0YbR6BW3cxqyotgw2Dn4SKGDRqFcLeMwk sWNTJsPCn01wV+etbNVe7KNeXypDKXIIRv1ZJiKjLf0yj23nUvfJbV0/SiPL9f7QB05ApEdv 1BLhR29PPSCFsNC0cFkj9zOqeTUCpMTTKJ1YbosEBaI/OOMxgXFY8FXSMxcgsBF/pmsA7rRT cOWyVoZSO7F6IgfoNIbDK0l3MU2ljlIodLPxNzyowiKB5MOny7iw8/s+0Ic50LDDovDDKQID mUKVtdFdyN3AtenItzrRkOifixJH1j/bTyO5vxGP4S1AOoxyIehYzGi0LgpEY/t5bxa7nb2B wEbgE5NqHfUB56x6D8Yj0M/vnqH4QtL37XxHKoAdIjIBCxuQzHwXYwqSAdD9bAr4eEqcUNDH 7vP9h/9GZZNs6yPoK8F0qSJG4X+keGa2YYKMDekCAhZHpmlppik/SjxX6ejjSz9GDGXmHW6y zdwWTelEOqb0WbIyGnFMBA9NpvIQAaXuVy50T1Vm/ssiPN7x85rzOvuXGZlFkGPB+mVx66tC ECKPz7nIPyL4f/kxX/963smdPLUDKmkyeLz72T9/l409oBqrP0HwLAQF2P4eG310Vf+yMp9L Kc0fv9KfFipJV/tf2rY3koHgsdn6usmK/306pZxmjR/6a/clL3nJS17ykpe85CUveclLPl3+ A8OGx0bKklwyAAAAAElFTkSuQmCCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAADwDoA5AOAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAA CgAAAAAAAAAAAAAAAQAAAAAAAAEPAPIDIAIAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB3wB AAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAADLZiAAy2YgA0tGIA BIkKMFi0YgAIAAAAWLRiAIqJCjAAAAYSEAC3D0QAAABBAHIAaQBhAGwAIABCAGwAYQBjAGsA AABtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAGIiAAtw9EAAAA VABhAGgAbwBtAGEAAABsAGEAYwBrAAAAbQBhAG4AAAAMtmIADLZiADS0YgAEiQowWLRiAAgA AABYtGIAiokKMAAABiIwALcPRAAAAE0AbwBuAG8AdAB5AHAAZQAgAFMAbwByAHQAcwAAAAAA DLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjACAAYCQAC3D0QAAABBAHIAaQBhAGwA AABwAGUAIABTAG8AcgB0AHMAAAAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQow AAAGIgAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAA AAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAA QAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsEaAEAAA8AAPBgAQAAAAAG8NAA AAACaAAAGQAAADsAAAAHAAAAAAAAAAcAAAACAAAABQAAAAEAAAAIAAAAAwAAAAgAAAAAAAAA TQAAAAQAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAABUAAAABgAAAFMAAAAAAAAABAAAAAAA AAAEAAAABwAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAEAAAABAAAAAAAAAAEAAAAHwAB8CwA AABiAAfwJAAAAAYGEe7EF8m/KGE+iN/DK/gOLP8ADw0AAAIAAAAAAAAAAABeAWMAC/AkAAAA gQEEAAAIgwEAAAAIvwEQABAAwAEBAAAI/wEIAAgAAQICAAAIIAAa8QgAAAAzM8wAAACZAEAA HvEQAAAABAAACAEAAAgCAAAI9wAAEB8A8A84AAAAAADzAxQAAAACAAAABAAAAAAAAAABAACA AAAAAAAA8wMUAAAAAwAAAAQAAAAAAAAAAgAAgAAAAAAPANAHzwAAAA8A+gNnAAAAAAD+AwMA AAAAAQAAAP0DNAAAADYAAABkAAAANgAAAGQAAABktGIAiokKMFy0YgAIAAAAZhIAAMAJAADi /P//sv///wEAAABwAPsDCAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAA BAwAAAAAAAAAAAAAAAIAAAAfAAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAAy2YgAM tmIAAQAAAAAAAADEEQAAXAoAAAAAAAAAAAAAAAD//z8A2Q8MAAAAAADaDwQAAAAAACUADwDw D40JAAAAAPMDFAAAAAQAAAAEAAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoDyYAAABT SVAgQXV0aGVudGljYXRpb24gdXNpbmcgQ0hBUC1QYXNzd29yZBAAnw8EAAAABQAAAAAAqA8e AAAAQnJ5YW4gSi4gQnllcmx5DURhdmlkIFdpbGxpYW1zAADzAxQAAAAGAAAAAAAAAAIAAAAC AQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8WAAAAUHJvYmxlbSBhbmQgT2JqZWN0aXZlcxAAnw8E AAAAAQAAAAAAqA/KAQAAUHJvYmxlbQ1IVFRQLURpZ2VzdCB1c2VyIGF1dGhlbnRpY2F0aW9u IGlzIG5vdCBjb21wYXRpYmxlIHdpdGggZGVwbG95ZWQgYmFja2VuZCBSYWRpdXMgc2VydmVy cy4NU0lQIHVzZXIgYXV0aGVudGljYXRpb24gKFJGQzI2MTcpIGFuZCBSYWRpdXMgKFJGQyAy MTM4KSB1c2VyIGF1dGhlbnRpY2F0aW9uIHJ1biBNRDUgb3ZlciBkaWZmZXJlbnRseSBmb3Jt YXR0ZWQgbWVzc2FnZXMuDU9iamVjdGl2ZQ1Qcm92aWRlIG1lY2hhbmlzbSB0byBhbGxvdyBh dXRoZW50aWNhdGlvbiBvZiB1c2VycyB1c2luZyBkZXBsb3llZCBSYWRpdXMgc2VydmVycy4N QWR2YW50YWdlb3VzIHRvIElTUHMgZGVwbG95aW5nIFNJUCB2b2ljZSBzZXJ2aWNlIHRvIFBQ UCBjdXN0b21lcnMNQXBwcm9hY2hlcw1FeHRlbmQgU0lQIHRvIHN1cHBvcnQgQ0hBUC1QYXNz d29yZA1FeHRlbmQgUmFkaXVzIHRvIHN1cHBvcnQgSFRUUC1EaWdlc3QAAKEP1gAAAAgAAAAA AAAAAADRAAAAAQAAAAAACgAAAAAAAAAAAJQAAAABAAAAAAALAAAAAAAAAAAASQAAAAEAAAAA AAcAAAAAAAIAHAABAAAAAAACABQAsQAAAAAAAgASABUAAAABAAIAgQASAAoAAAAAAAIAEgAB AAAAAAACABQACQAAAAAAAgAcAAEAAAAAAAIAFAA5AAAAAAACABIACAAAAAEAAgCBABIAEQAA AAAAAgASAEEAAAAAAAIAEAABAAAAAAACABgACwAAAAAAAgAcAEkAAAAAAAIAEgAAAKoPGgAA AEQBAAAAAAAABQAAAAEAAAADAIIAAAAAAAAAAADzAxQAAAAVAAAAAAAAAAIAAAASAQAAAAAA AAAAnw8EAAAAAAAAAAAAqA8aAAAAQ29tcGFyaXNvbiBvZiBoYXNoIGZvcm1hdHMQAJ8PBAAA AAEAAAAAAKAP+gEAAEMASABBAFAALQBQAGEAcwBzAHcAbwByAGQAOgAgAE0ARAA1AA0ATQBE ADUAKABzAGUAcQBuAHUAbQAsACAAdQBzAGUAcgAtAHAAYQBzAHMAdwBvAHIAZAAsACAAbgBv AG4AYwBlACkADQANAEgAVABUAFAALQBEAGkAZwBlAHMAdAA6ACAATQBEADUADQBNAEQANQAo AHUAbgBxACgAdQBzAGUAcgBuAGEAbQBlAC0AdgBhAGwAdQBlACkAIAAcIDoAHSAgAHUAbgBx ACgAcgBlAGEAbABtAC0AdgBhAGwAdQBlACkAIAAcIDoAHSAgAHAAYQBzAHMAdwBvAHIAZAAp AA0ASABUAFQAUAAtAEQAaQBnAGUAcwB0ADoAIABNAEQANQAtAHMAZQBzAHMADQBNAEQANQAo AHUAbgBxACgAdQBzAGUAcgBuAGEAbQBlAC0AdgBhAGwAdQBlACkAIAAcIDoAHSAgAHUAbgBx ACgAcgBlAGEAbABtAC0AdgBhAGwAdQBlACkAIAAcIDoAHSAgAHAAYQBzAHMAdwBvAHIAZAAg ABwgOgAdICAAdQBuAHEAKABuAG8AbgBjAGUALQB2AGEAbAB1AGUAKQAgABwgOgAdICAAdQBu AHEAKABjAG4AbwBuAGMAZQAtAHYAYQBsAHUAZQApACkAAAChD3gAAAATAAAAAAAAAAAAIwAA AAEAAAAAABEAAAAAAAAAAAA7AAAAAQAAAAAAFgAAAAAAAAAAAGYAAAABAAAAAAATAAAAAAAC ABgAIwAAAAAAAgAYABEAAAAAAAIAGAA7AAAAAAACABgAFgAAAAAAAgAYAGYAAAAAAAIAGAAA AKoPqgAAABcAAAAAAAAABgAAAAEAAAADAC4AAAAAAAAAAwAAAAEAAAADABUAAAAAAAAAAwAA AAEAAAADAC0AAAAAAAAABAAAAAEAAAADAAUAAAAAAAAAAwAAAAEAAAADABUAAAAAAAAAAwAA AAEAAAADAB8AAAAAAAAAAwAAAAEAAAADABIAAAAAAAAAAwAAAAEAAAADAAEAAAAAAAAABgAA AAEAAAADAAkAAAAAAAAAAADzAxQAAAAKAAAABAAAAAIAAAAGAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8sAAAAU0lQIFVzZXIgQXV0aGVudGljYXRpb24gdXNpbmcgUmFkaXVzIGJhY2tlbmQQ AJ8PBAAAAAEAAAAAAKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAAAwAAAAAAAAAAgAAAAgBAAAA AAAAAACfDwQAAAAAAAAAAACoDwYAAABGdXR1cmUQAJ8PBAAAAAEAAAAAAKgP6wAAAFJlbWFp bmluZyBpc3N1ZXMNTXVsdGlwbGUgUHJveHktQXV0aG9yaXphdGlvbiBoZWFkZXJzIChzZW1p Y29sb24gdnMuIGNvbW1hIHNlcGFyYXRlZCB0YWdzKQ1JcyBhZGRpdGlvbmFsIGNvbXBsZXhp dHkgb2YgTWFobGVyIGRyYWZ0IG5lY2Vzc2FyeT8NUmVmbGVjdGlvbiBhdHRhY2sgaW4gdHJ1 c3RlZCBzaWRlIG9mIG5ldHdvcmsNUHJvcG9zZWQgbmV4dCBzdGVwcw1TSVAgV0cgaXRlbQ1T dGFuZGFyZHMgdHJhY2sAAKEPfgAAABEAAAAAAAAAAAB+AAAAAQAAAAAALQAAAAIAAAAAABQA AAAAAAAAAAAcAAAAAQAAAAAAEQAAAAAAAAB+AAAAAAACABgAFQAAAAAAAgAUAAcAAAABAAIA gQAUABEAAAAAAAIAFAAUAAAAAAAAABsAAAAAAAIAGAABAAAAAAAAAAAAqg8aAAAAQAAAAAAA AAADAAAAAQAAAAMAqQAAAAAAAAAAAOoDAAAAAA8A+AOpCQAAAgDvAxgAAAABAAAAAQIHCQgA AAAAAAAAAAAAAAAAAABgAPAHIAAAAAAAAAD//8wAXldOAP/MAADMmQAA/2YAAP8AAAD//8wA YADwByAAAAD///8AAAAAAF5XTgAAAAAA/2YAAP/MAACZZjMAgIAAAGAA8AcgAAAA////AAAA AAA5OTkAAAAAAMvLywCGhoYATU1NAOrq6gBgAPAHIAAAAP///wAAAAAAXldOAIAAAAD/ZgAA /8wAAP8AAAD//8wAYADwByAAAAD///8AAABmAAAAAAAAAP8AAGb/ADPMzAD/AP8AmTP/AGAA 8AcgAAAAAABmAP///wAAAAAA/8wAAABm/wAzzMwA/wD/AJkz/wBgAPAHIAAAAIAAAAD//8wA XldOAP/MAADMmQAA/2YAAP8AAAD//8wAAACjDz4AAAABAP/9PwAAACIgAABkAAAAAAAAAGQA AAAAAAAAAABAAgAAAAACAAAA///vAIAAAQD///////8oAAAAAAMAABAAow+AAAAABQD//T8A BwB6AAMAZAAAAAAFAABkABQAAADYAAAAQAIAAAAAAgAAAP//7wCAAAIA////////IAAAAAAB AACABQAAeQDUASABAAACABwAgAUAAHgA0AJAAgAAAgAYAJIFAAAFACIgAADwA2ADAAACABQA gAUAABMgEAWABAAAAAAgAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAeAAAAAAAAAEAC AAAAAAIAAAD//+8AgAAAAP///////wwAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAA AAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAQACjD24AAAAFAP/9PwAAACIgAABkAAAAAAAAAGQA AAAAAAAAAABAAgAAAAACAAAA///vAAAAAAD///////8YAAAAAAEAAAAFAAAgASABAAAAAAAF AABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAFAAow9SAAAABQAAAAEBAAAGAAAA AAABAAEAAQABCQAABgABACABAAAAAAIAAQkAAAYAAQBAAgAAAAADAAEJAAAEAAEAYAMAAAAA BAABCQAABAABAIAEAAAAAGAAow8MAAAAAQAAAAAAAAAAAAAAcACjDz4AAAAFAAAAAAAAAAAA AgAcAAEAAAAAAAAAAgAYAAIAAAAAAAAAAgAUAAMAAAAAAAAAAgASAAQAAAAAAAAAAgASAIAA ow8+AAAABQAAAAAAAAAAAAIAGAABAAAAAAAAAAIAFAACAAAAAAAAAAIAEgADAAAAAAAAAAIA EAAEAAAAAAAAAAIAEAAPAAwEUwUAAA8AAvBLBQAAEAAI8AgAAAAHAAAABwwAAA8AA/DRBAAA DwAE8CgAAAABAAnwEAAAAFgAAAAJAAAADgAPAAwAAAACAArwCAAAAAAMAAAFAAAADwAE8MYA AAASAArwCAAAAAIMAAAACgAAcwAL8CoAAAB/AAEAAQCAANSe4gCHAAIAAACBAQQAAAi/AQEA EQDAAQEAAAj/AQEACQAAABDwCAAAAJAAAAEgFGADDwAR8BAAAAAAAMMLCAAAAAAAAAABAOIA DwAN8FQAAAAAAJ8PBAAAAAAAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxl IHN0eWxlAACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwCgEAABIACvAIAAAA AwwAAAAKAABjAAvwJAAAAH8AAQABAIAAVKDiAIEBBAAACL8BAQARAMABAQAACP8BAQAJAAAA EPAIAAAApAQgAUAV6A4PABHwEAAAAAAAwwsIAAAAAQAAAAIA4gAPAA3wngAAAAAAnw8EAAAA AQAAAAAAqA9SAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgdGV4dCBzdHlsZXMNU2Vjb25kIGxl dmVsDVRoaXJkIGxldmVsDUZvdXJ0aCBsZXZlbA1GaWZ0aCBsZXZlbAAAog8eAAAAIQAAAAAA DQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAABTAAAAAQAAAAAADwAE8LcAAAASAArw CAAAAAQMAAAACgAAcwAL8CoAAAB/AAEAAQCAAPSZ4gCHAAIAAACBAQQAAAi/AQEAEQDAAQEA AAj/AQEACQAAABDwCAAAAFQPEAHABXQQDwAR8BAAAAAAAMMLCAAAAAIAAAAHAeIADwAN8EUA AAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPHAAAAAIAAAAAAAAgAAAyAAIAAAAAAAcABAAO AAAAAAIAAPgPBAAAAAAAAAAPAATwuQAAABIACvAIAAAABQwAAAAKAABzAAvwKgAAAH8AAQAB AIAAdJ7iAIcAAgAAAIEBBAAACL8BAQARAMABAQAACP8BAQAJAAAAEPAIAAAAVA+wB9AOdBAP ABHwEAAAAAAAwwsIAAAAAwAAAAkC4gAPAA3wRwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAA oQ8eAAAAAgAAAAAAACgAAAEAMgACAAAAAAAHAAQADgAAAAACAAD6DwQAAAAAAAAADwAE8LkA AAASAArwCAAAAAYMAAAACgAAcwAL8CoAAAB/AAEAAQCAAHSY4gCHAAIAAACBAQQAAAi/AQEA EQDAAQEAAAj/AQEACQAAABDwCAAAAFQPkBBAFXQQDwAR8BAAAAAAAMMLCAAAAAQAAAAIAuIA DwAN8EcAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPHgAAAAIAAAAAAAAoAAACADIAAgAA AAAABwAEAA4AAAAAAgAA2A8EAAAAAAAAAA8ABPB4AAAAsgQK8AgAAAAHDAAAAAoAAJMAC/BQ AAAAfwCAAIAABEEBAAAABcEaAAAABgEBAAAABwHAwMAAgQEEAAAIvwEAABAAwAEBAAAI/wEA AAgAQQA6AFwAcABhAGkAbgB0AC4ARwBJAEYAAAAAABDwCAAAADwDQAKAFi4EDwAE8FoAAAAS AArwCAAAAAEMAAAADAAAswAL8EIAAACBAQAAAAiTAY6fiwCUAd69aAC/AR4AHwD/AQAACAAB AgAAAAIFAqgpAQAGAqgpAQA/AgMAAwAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAXldO AAAAAAD/ZgAA/8wAAJlmMwCAgAAAIAC6DzIAAABDAG8AbgB0AGUAbQBwAG8AcgBhAHIAeQAg AFAAbwByAHQAcgBhAGkAdAAuAHAAbwB0AA8A7gNcBQAAAgDvAxgAAAACAAAAAwQHCQgAAAAB AACAAAAAAAAAAAAPAAwEDAUAAA8AAvAEBQAAMAAI8AgAAAAHAAAABxAAAA8AA/CKBAAADwAE 8CgAAAABAAnwEAAAAAAAAAAAAAAA/////xAAAAACAArwCAAAAAAQAAAFAAAADwAE8MYAAAAS AArwCAAAAAIQAAAACgAAcwAL8CoAAAB/AAEAAQCAAJSf4gCHAAIAAACBAQQAAAi/AQEAEQDA AQEAAAj/AQEACQAAABDwCAAAALABQAJAFYAEDwAR8BAAAAAAAMMLCAAAAAAAAAADAOQADwAN 8FQAAAAAAJ8PBAAAAAYAAAAAAKgPIAAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHRpdGxlIHN0 eWxlAACiDwYAAAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwwwAAABIACvAIAAAAAxAA AAAKAABjAAvwJAAAAH8AAQABAIAA9KLiAIEBBAAACL8BAQARAMABAQAACP8BAQAJAAAAEPAI AAAAkAlABQAV7A0PABHwEAAAAAAAwwsIAAAAAQAAAAQA5AAPAA3wVwAAAAAAnw8EAAAABQAA AAAAqA8jAAAAQ2xpY2sgdG8gZWRpdCBNYXN0ZXIgc3VidGl0bGUgc3R5bGUAAKIPBgAAACQA AAAAAAAAqg8KAAAAJAAAAAEAAAAAAA8ABPC3AAAAEgAK8AgAAAAEEAAAAAoAAHMAC/AqAAAA fwABAAEAgAC0oOIAhwACAAAAgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAABUD8AB gAaYEA8AEfAQAAAAAADDCwgAAAACAAAABwHkAA8ADfBFAAAAAACfDwQAAAAEAAAAAACoDwEA AAAqAAChDxwAAAACAAAAAAAAIAAAMgACAAAAAAAHAAQADgBeV07+AAD4DwQAAAAAAAAADwAE 8LkAAAASAArwCAAAAAUQAAAACgAAcwAL8CoAAAB/AAEAAQCAAHSh4gCHAAIAAACBAQQAAAi/ AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAFQPwAfADpgQDwAR8BAAAAAAAMMLCAAAAAMAAAAJ AuQADwAN8EcAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPHgAAAAIAAAAAAAAoAAABADIA AgAAAAAABwAEAA4AXldO/gAA+g8EAAAAAAAAAA8ABPC5AAAAEgAK8AgAAAAGEAAAAAoAAHMA C/AqAAAAfwABAAEAgAAUpOIAhwACAAAAgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgA AABUD0AQwBSYEA8AEfAQAAAAAADDCwgAAAAEAAAACALkAA8ADfBHAAAAAACfDwQAAAAEAAAA AACoDwEAAAAqAAChDx4AAAACAAAAAAAAKAAAAgAyAAIAAAAAAAcABAAOAF5XTv4AANgPBAAA AAAAAAAPAATweAAAALIECvAIAAAABxAAAAAKAACTAAvwUAAAAH8AgACAAARBAQAAAAXBGgAA AAYBAQAAAAcBwMDAAIEBBAAACL8BAAAQAMABAQAACP8BAAAIAEEAOgBcAHAAYQBpAG4AdAAu AEcASQBGAAAAAAAQ8AgAAACABEACgBZyBQ8ABPBaAAAAEgAK8AgAAAABEAAAAAwAALMAC/BC AAAAgQEAAAAIkwGOn4sAlAHevWgAvwEaAB8A/wEAAAgAAQIAAAACBQKoKQEABgKoKQEAPwID AAMABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAF5XTgAAAAAA/2YAAP/MAACZZjMAgIAA AA8A7gPaAgAAAgDvAxgAAAAAAAAADxAAAAAAAAACAACAAAAAAAcAAAAPAAwEigIAAA8AAvCC AgAAIAAI8AgAAAAEAAAABAgAAA8AA/AaAgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAA AAAAAAACAArwCAAAAAAIAAAFAAAADwAE8HIAAAASAArwCAAAAAIIAAAgAgAAUwAL8B4AAAAE AAAAAACAABSe4gC/AQAAAQD/AQAAAQABAwIQAAAAABDwCAAAALABQAJAFYAEDwAR8BAAAAAA AMMLCAAAAAAAAAAPAOQADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAAwgA ACACAABTAAvwHgAAAAQAAAAAAIAAlJniAL8BAAABAP8BAAABAAEDAxAAAAAAEPAIAAAAkAlA BQAV7A0PABHwEAAAAAAAwwsIAAAAAQAAABAA5AAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPDu AAAAogwK8AgAAAAECAAAAAoAAIMAC/AwAAAAgAC0neIAvwACAAIAgQEEAAAIgwEAAAAIvwEA ABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAADABtACgBAtCA8ADfCOAAAAAACfDwQAAAAE AAAAAACoDx4AAABkcmFmdC1ieWVybHktc2lwLXJhZGl1cy0wMC50eHQAAKEPIAAAAB8AAAAA AAAoAAABADIAHgAAAAAAAgAgAAEAAAAAAAAAAACqDywAAAAGAAAAAAAAAAYAAAABAAAAAwAP AAAAAAAAAAMAAAABAAAAAwABAAAAAAAAAA8ABPBIAAAAEgAK8AgAAAABCAAAAAwAAIMAC/Aw AAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADw ByAAAAD///8AAAAAAICAgAAAAAAAAMyZADMzzADMzP8AsrKyAA8A7gPYAQAAAgDvAxgAAAAB AAAADQ4AAAAAAAABAACAAAAAAAcAAAAPAAwEiAEAAA8AAvCAAQAAQAAI8AgAAAADAAAAAxgA AA8AA/AYAQAADwAE8CgAAAABAAnwEAAAAPsAAAAAAAAAAAAAAAAAAAACAArwCAAAAAAYAAAF AAAADwAE8GwAAAASAArwCAAAAAIYAAAgAgAAQwAL8BgAAACAAMQbYQG/AQAAAQD/AQAAAQAB AwIMAAAAABDwCAAAAJAAAAEgFGADDwAR8BAAAAAAAMMLCAAAAAAAAAANAOIADwAN8AwAAAAA AJ4PBAAAAAAAAAAPAATwbAAAABIACvAIAAAAAxgAACACAABDAAvwGAAAAIAAZBthAb8BAAAB AP8BAAABAAEDAwwAAAAAEPAIAAAApAQgAUAVwA8PABHwEAAAAAAAwwsIAAAAAQAAAA4A4gAP AA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABGAAAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD/ //8AAAAAAF5XTgAAAAAA/2YAAP/MAACZZjMAgIAAAA8A7gPkAQAAAgDvAxgAAAABAAAADQ4A AAAAAAABAACAAAAAAAcAAAAPAAwElAEAAA8AAvCMAQAAUAAI8AgAAAADAAAAA1wAAA8AA/Ak AQAADwAE8CgAAAABAAnwEAAAAAAAAACgAAAAeAAAAAAAAAACAArwCAAAAABcAAAFAAAADwAE 8HIAAAASAArwCAAAAAJcAAAgAgAAUwAL8B4AAACAAAQSYQG/AQAAAQD/AQAAAQABAwIMAACI AwAAAAAAABDwCAAAAJAAAAGQFWADDwAR8BAAAAAAAMMLCAAAAAAAAAANAOIADwAN8AwAAAAA AJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAAA1wAACACAABTAAvwHgAAAIAA5BBhAb8BAAAB AP8BAAABAAEDAwwAAIgDAAAAAAAAEPAIAAAApAQgAUAV6A4PABHwEAAAAAAAwwsIAAAAAQAA AA4A4gAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABXAAAAAwAAIMAC/Aw AAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwEeAB8A/wEAAAgABAMJAAAAPwMBAAEAEADw ByAAAAD///8AAAAAAF5XTgAAAAAA/2YAAP/MAACZZjMAgIAAAA8A7gMDEwAAAgDvAxgAAAAB AAAADQ4AAAAAAAABAACAAAAAAAcAAAAPAAwEsxIAAA8AAvCrEgAAYAAI8AgAAAAgAAAAUigA ABAAGPEEAAAAAQAAAA8AA/A3EgAADwAE8CgAAAABAAnwEAAAAAAAAACgAAAAeAAAAAAAAAAC AArwCAAAAAAoAAAFAAAADwAE8GwAAAASAArwCAAAAAIoAAAgAgAAQwAL8BgAAACAAAQVYQG/ AQAAAQD/AQAAAQABAwIMAAAAABDwCAAAAJAAAAEgFGADDwAR8BAAAAAAAMMLCAAAAAAAAAAN AOIADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAAPwjAEAAA8ABPBMAAAAAQAJ8BAAAAAgCgAALgsA AOAiAADgGQAAAgAK8AgAAAAtKAAAAQIAACMAC/AMAAAABAAAAAAAiAMBAAAAAAAQ8AgAAABd BUAFJw8QDg8ABPBgAAAAQgEK8AgAAAAuKAAAAgoAAIMAC/AwAAAAvwAAAAcARAEEAAAAfwEA AAEAvwEAABAAywFqSgAA/wEeAB4APwIAAAMAfwMAAA8AAAAP8BAAAAAgCgAALgsAACAKAADO GQAADwAE8GAAAABCAQrwCAAAAC8oAAACCgAAgwAL8DAAAAC/AAAABwBEAQQAAAB/AQAAAQC/ AQAAEADLAWpKAAD/AR4AHgA/AgAAAwB/AwAADwAAAA/wEAAAAIAWAAAuCwAAgBYAAM4ZAAAP AATwYAAAAEIBCvAIAAAAMCgAAAIKAACDAAvwMAAAAL8AAAAHAEQBBAAAAH8BAAABAL8BAAAQ AMsBakoAAP8BHgAeAD8CAAADAH8DAAAPAAAAD/AQAAAA4CIAAEALAADgIgAA4BkAAA8AA/Bm AgAADwAE8EwAAAABAAnwEAAAAFAHAAB+CQAA0CYAAFILAAACAArwCAAAADEoAAABAgAAIwAL 8AwAAAAEAAAAAACIAwEAAAAAABDwCAAAALAEIAS6EGsFDwAE8KgAAACiDArwCAAAADIoAAAC CgAAkwAL8DYAAACAAEQUYQGKADIoAAC/AAAABwCBAQAA/wC/AQwAHgDLAWpKAAD/AQYADgA/ AgAAAwB/AwAADwAAAA/wEAAAAFAHAAB+CQAAgA0AAEALAAAPAA3wOgAAAAAAnw8EAAAABAAA AAAAqA8KAAAAU0lQIGNsaWVudAAAoQ8UAAAACwAAAAAAAAAAAAsAAAAAAAIADgAPAATwpwAA AKIMCvAIAAAAMygAAAIKAACTAAvwNgAAAIAABBhhAYoAMygAAL8AAAAHAIEBAAD/AL8BDAAe AMsBakoAAP8BBgAOAD8CAAADAH8DAAAPAAAAD/AQAAAAsBMAAJAJAADgGQAAUgsAAA8ADfA5 AAAAAACfDwQAAAAEAAAAAACoDwkAAABTSVAgcHJveHkAAKEPFAAAAAoAAAAAAAAAAAAKAAAA AAACAA4ADwAE8KsAAACiDArwCAAAADQoAAACCgAAkwAL8DYAAACAAEQXYQGKADQoAAC/AAAA BwCBAQAA/wC/AQwAHgDLAWpKAAD/AQYADgA/AgAAAwB/AwAADwAAAA/wEAAAAGAeAACQCQAA 0CYAAFILAAAPAA3wPQAAAAAAnw8EAAAABAAAAAAAqA8NAAAAUkFESVVTIHNlcnZlcgAAoQ8U AAAADgAAAAAAAAAAAA4AAAAAAAIADgAPAAPwbgEAAA8ABPBMAAAAAQAJ8BAAAAAgCgAALgsA AMAYAABuDQAAAgAK8AgAAAA1KAAAAQIAACMAC/AMAAAABAAAAAAAiAMBAAAAAAAQ8AgAAABd BUAFGgtDBg8ABPBmAAAAQgEK8AgAAAA2KAAAAgoAAJMAC/A2AAAAvwAAAAcARAEEAAAAfwEA AAEAvwEAABAAywFqSgAA0QEBAAAA/wEeAB4APwIAAAMAfwMAAA8AAAAP8BAAAAAgCgAA3gwA AIAWAADeDAAADwAE8KQAAACiDArwCAAAADcoAAACCgAAkwAL8DYAAACAAGQSYQGKADcoAAC/ AAAABwCBAQAA/wC/AQwAHgDLAWpKAAD/AQYADgA/AgAAAwB/AwAADwAAAA/wEAAAACAKAAAu CwAAwBgAAG4NAAAPAA3wNgAAAAAAnw8EAAAABAAAAAAAqA8GAAAASU5WSVRFAAChDxQAAAAH AAAAAAAAAAAABwAAAAAAAgASAA8AA/ATDAAADwAE8DgAAAABAAnwEAAAAEAFAACdBwAA+hIA AEMPAAACAArwCAAAAFIoAAABAgAAAAAQ8AgAAAAwBkAF+hLWDQ8AA/B+AQAADwAE8FQAAAAB AAnwEAAAAIAWAADwFQAAICUAADAYAAACAArwCAAAAD8oAAADAgAAIwAL8AwAAAAEAAAAAACI AwEAAAAAAA/wEAAAADMKAAAdDAAADRAAAAMNAAAPAATwZgAAAEIBCvAIAAAAQCgAAAIKAACT AAvwNgAAAL8AAAAHAEQBBAAAAH8BAAABAL8BAAAQAMsBakoAANEBAQAAAP8BHgAeAD8CAAAD AH8DAAAPAAAAD/AQAAAAgBYAAKAXAADgIgAAoBcAAA8ABPCsAAAAogwK8AgAAABBKAAAAgoA AJMAC/A2AAAAgACEE2EBigBBKAAAvwAAAAcAgQEAAP8AvwEMAB4AywFqSgAA/wEGAA4APwIA AAMAfwMAAA8AAAAP8BAAAACAFgAA8BUAACAlAAAwGAAADwAN8D4AAAAAAJ8PBAAAAAQAAAAA AKgPDgAAAEFjY2Vzcy1SZXF1ZXN0AAChDxQAAAAPAAAAAAAAAAAADwAAAAAAAgASAA8AA/B9 AQAADwAE8FQAAAABAAnwEAAAAIAWAACQGwAAICUAANAdAAACAArwCAAAAEIoAAADAgAAIwAL 8AwAAAAEAAAAAACIAwEAAAAAAA/wEAAAADMKAAA9DQAADRAAACMOAAAPAATwZgAAAEIBCvAI AAAAQygAAEIKAACTAAvwNgAAAL8AAAAHAEQBBAAAAH8BAAABAL8BAAAQAMsBakoAANEBAQAA AP8BHgAeAD8CAAADAH8DAAAPAAAAD/AQAAAAgBYAAEAdAADgIgAAQB0AAA8ABPCrAAAAogwK 8AgAAABEKAAAAgoAAJMAC/A2AAAAgACEEGEBigBEKAAAvwAAAAcAgQEAAP8AvwEMAB4AywFq SgAA/wEGAA4APwIAAAMAfwMAAA8AAAAP8BAAAACAFgAAkBsAACAlAADQHQAADwAN8D0AAAAA AJ8PBAAAAAQAAAAAAKgPDQAAAEFjY2Vzcy1BY2NlcHQAAKEPFAAAAA4AAAAAAAAAAAAOAAAA AAACABIADwAE8GwAAABCAQrwCAAAAEUoAABCCgAAowAL8DwAAAC/AAAABwBEAQQAAAB/AQAA AQC/AQAAEADLAWpKAADRAQEAAAD/AR4AHgA/AgAAAwB/AwAADwCIAwEAAAAAAA/wEAAAAEAF AACDCAAAMwoAAIMIAAAPAATwzwAAAKIMCvAIAAAARigAAAIKAACjAAvwPAAAAIAAhBZhAYoA RigAAL8AAAAHAIEBAAD/AL8BDAAeAMsBakoAAP8BBgAOAD8CAAADAH8DAAAPAIgDAQAAAAAA D/AQAAAAQAUAANYHAADtDgAAvQgAAA8ADfBbAAAAAACfDwQAAAAEAAAAAACoDyEAAAAgNDA3 IFByb3h5IEF1dGhvcml6YXRpb24gUmVxdWlyZWQAAKEPHgAAACIAAAAAAAAAAAAFAAAAAAAC ABIAHQAAAAAAAgAOAA8ABPAsAQAAogwK8AgAAABHKAAAAgoAAKMAC/A8AAAAgABkFWEBigBH KAAAvwAAAAcAgQEAAP8AvwEMAB4AywFqSgAA/wEGAA4APwIAAAMAfwMAAA8AiAMBAAAAAAAP 8BAAAAB6BQAAgwgAAM0NAADdCQAADwAN8LgAAAAAAJ8PBAAAAAQAAAAAAKgPYgAAAFByb3h5 LUF1dGhlbnRpY2F0ZTogQ0hBUC1QYXNzd29yZA07YWxnb3JpdGhtPSJNRDUiIDtpZD0wDTtu b25jZT0iY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2MiAAChDxgAAABjAAAAAAAA AAAAYwAAAAAABgAKAAAAmf4AAKoPGgAAAEEAAAAAAAAAIAAAAAEAAAADAAIAAAAAAAAADwAD 8HYBAAAPAATwVAAAAAEACfAQAAAAQAsAAAAbAACgFwAAQB0AAAIACvAIAAAASCgAAAMCAAAj AAvwDAAAAAQAAAAAAIgDAQAAAAAAD/AQAAAAQAUAAN0JAAAzCgAAwwoAAA8ABPBmAAAAQgEK 8AgAAABJKAAAAgoAAJMAC/A2AAAAvwAAAAcARAEEAAAAfwEAAAEAvwEAABAAywFqSgAA0QEB AAAA/wEeAB4APwIAAAMAfwMAAA8AAAAP8BAAAABACwAAsBwAAKAXAACwHAAADwAE8KQAAACi DArwCAAAAEooAAACCgAAkwAL8DYAAACAAESJXAGKAEooAAC/AAAABwCBAQAA/wC/AQwAHgDL AWpKAAD/AQYADgA/AgAAAwB/AwAADwAAAA/wEAAAAEALAAAAGwAAABIAAEAdAAAPAA3wNgAA AAAAnw8EAAAABAAAAAAAqA8GAAAASU5WSVRFAAChDxQAAAAHAAAAAAAAAAAABwAAAAAAAgAS AA8ABPCRAQAAogwK8AgAAABLKAAAAgoAAKMAC/A8AAAAgACEf1wBigBLKAAAvwAAAAcAgQEA AP8AvwEMAB4AywFqSgAA/wEGAA4APwIAAAMAfwMAAA8AiAMBAAAAAAAP8BAAAABABQAAigoA AOcMAACQDAAADwAN8B0BAAAAAJ8PBAAAAAQAAAAAAKgPowAAAFByb3h5LUF1dGhvcml6YXRp b246IENIQVAtUGFzc3dvcmQNO3VzZXJuYW1lPSJieWVybHkiIDthbGdvcml0aG09Ik1ENSIg O2lkPTANO25vbmNlPSJjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjY2NjYyINO3Jlc3Bv bnNlPSJkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZGRkZCIAAKEPGAAAAKQAAAAAAAAA AACkAAAAAAAGAAoAAACZ/gAAqg8+AAAALgAAAAAAAAAGAAAAAQAAAAMAIQAAAAAAAAAgAAAA AQAAAAMADQAAAAAAAAAgAAAAAQAAAAMAAgAAAAAAAAAPAAPwdgEAAA8ABPBUAAAAAQAJ8BAA AACgFwAAMCEAADAqAABwIwAAAgAK8AgAAABMKAAAAwIAACMAC/AMAAAABAAAAAAAiAMBAAAA AAAP8BAAAAAzCgAAXQ4AAKARAABDDwAADwAE8GYAAABCAQrwCAAAAE0oAAACCgAAkwAL8DYA AAC/AAAABwBEAQQAAAB/AQAAAQC/AQAAEADLAWpKAADRAQEAAAD/AR4AHgA/AgAAAwB/AwAA DwAAAA/wEAAAAKAXAADgIgAAMCoAAOAiAAAPAATwpAAAAKIMCvAIAAAATigAAAIKAACTAAvw NgAAAIAAZIRcAYoATigAAL8AAAAHAIEBAAD/AL8BDAAeAMsBakoAAP8BBgAOAD8CAAADAH8D AAAPAAAAD/AQAAAAoBcAADAhAABgHgAAcCMAAA8ADfA2AAAAAACfDwQAAAAEAAAAAACoDwYA AABJTlZJVEUAAKEPFAAAAAcAAAAAAAAAAAAHAAAAAAACABIADwAE8PYAAACiDArwCAAAAE8o AAACCgAAowAL8DwAAACAAASEXAGKAE8oAAC/AAAABwCBAQAA/wC/AQwAHgDLAWpKAAD/AQYA DgA/AgAAAwB/AwAADwCIAwEAAAAAAA/wEAAAADMKAADKDAAAhxIAAHcNAAAPAA3wggAAAAAA nw8EAAAABAAAAAAAqA8wAAAAQ0hBUC1QYXNzd29yZD0oZGRkZGRkZGRkZGRkZGRkZGRkZGRk ZGRkZGRkZGRkZGQpAAChDxQAAAAxAAAAAAAAAAAAMQAAAAAAAgAKAAAAqg8aAAAADwAAAAAA AAAgAAAAAQAAAAMAAgAAAAAAAAAPAATwrgAAAKIMCvAIAAAAUCgAAAIKAACjAAvwPAAAAIAA JIhcAYoAUCgAAL8AAAAHAIEBAAD/AL8BDAAeAMsBakoAAP8BBgAOAD8CAAADAH8DAAAPAIgD AQAAAAAAD/AQAAAAMwoAAJ0HAAD6EgAAvQgAAA8ADfA6AAAAAACfDwQAAAAEAAAAAAChDxQA AAABAAAAAAAAAAAAAQAAAAAAAgAKAAAAqg8KAAAAAQAAAAEAAAAAAA8ABPBIAAAAEgAK8AgA AAABKAAAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAF5XTgAAAAAA/2YAAP/MAACZZjMAgIAAAA8A 7gPYAQAAAgDvAxgAAAABAAAADQ4AAAAAAAABAACAAAAAAAcAAAAPAAwEiAEAAA8AAvCAAQAA cAAI8AgAAAADAAAAAzQAAA8AA/AYAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAA AAACAArwCAAAAAA0AAAFAAAADwAE8GwAAAASAArwCAAAAAI0AAAgAgAAQwAL8BgAAACAAASB XAG/AQAAAQD/AQAAAQABAwIMAAAAABDwCAAAAJAAAAEgFGADDwAR8BAAAAAAAMMLCAAAAAAA AAANAFwBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwbAAAABIACvAIAAAAAzQAACACAABDAAvw GAAAAIAApINcAb8BAAABAP8BAAABAAEDAwwAAAAAEPAIAAAApATwAEAVwA8PABHwEAAAAAAA wwsIAAAAAQAAAA4AXAEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABNAAA AAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAA PwMBAAEAEADwByAAAAD///8AAAAAAF5XTgAAAAAA/2YAAP/MAACZZjMAgIAAAAAAchc0AAAA AQBAAAAAAACYDgAASRgAAK0dAAAGABAAjyAAAAoAEABbJAAADAAQAGY3AAAVABAAbyIAAAAA 9Q8cAAAAAAEAAJIOAAMAAAAARjkAAAEAAAAWAAAAAQBiAA8A6AOQDgAAAQDpAygAAACAFgAA 4BAAAOAQAACAFgAABQAAAAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyAyACAAAvAMgPDAAAADAA 0g8EAAAAAAAAAA8A1Qd8Af7/AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuR CAArJ7PZMAAAAPRiAAAMAAAAAQAAAGgAAAACAAAAcAAAAAQAAACgAAAABwAAALQAAAAIAAAA GAEAAAkAAAAsAQAAEgAAADgBAAAKAAAAWAEAAAwAAABkAQAADQAAAHABAAAPAAAAfAEAABEA AACEAQAAAgAAAOQEAAAeAAAAJwAAAFNJUCBBdXRoZW50aWNhdGlvbiB1c2luZyBDSEFQLVBh c3N3b3JkAHMeAAAACwAAAE1lZHNjaG9sYXIAaR4AAABbAAAAQzpcUHJvZ3JhbSBGaWxlc1xN aWNyb3NvZnQgT2ZmaWNlXFRlbXBsYXRlc1xQcmVzZW50YXRpb24gRGVzaWduc1xDb250ZW1w b3JhcnkgUG9ydHJhaXQucG90AAAeAAAACwAAAE1lZHNjaG9sYXIARh4AAAADAAAANTkAcx4A AAAVAAAATWljcm9zb2Z0IFBvd2VyUG9pbnQAb3NvQAAAAKB6UiodAAAAQAAAAMDdSgUkXsAB QAAAAMAEjPJCYsABAwAAAC4BAABHAAAAZmEAAP////8DAAAACABvEE0MAAABAAkAAAOrMAAA BgCiJwAAAAARAAAAJgYPABgA/////wAAEAAAAAAAAAAAALoDAADKAgAACQAAACYGDwAIAP// //8CAAAAFwAAACYGDwAjAP////8EABsAVE5QUBQAaNsAMAAAAAAUAAAARA3HAAAAAAAAAAoA AAAmBg8ACgBUTlBQAAACAPQDCQAAACYGDwAIAP////8DAAAADwAAACYGDwAUAFROUFAEAAwA AQAAAAEAAAAAAAAABQAAAAsCAAAAAAUAAAAMAsoCugMEAAAABAENABAAAAAmBg8AFgD///// AAAAAAAAAAAAAMgDAADYAgAACQAAAPoCBQAAAAAA////ACIABAAAAC0BAAAHAAAA/AIAAAAA AAIAAAQAAAAtAQEABAAAAC0BAQAJAAAAHQYhAPAA0ALAAwgACAAEAAAALQEBAAkAAAD6AgAA AAAAAAAAAAAiAAQAAAAtAQIABwAAAPwCAAD///8AAAAEAAAALQEDAAQAAADwAQEABAAAAC0B AAAEAAAALQEDAAQAAAAtAQMACQAAAB0GIQDwANACwAMAAAAABAAAAC0BAwAEAAAALQECAAQA AAAtAQMACAAAACYGDwAGAP////8BABAAAAAmBg8AFgD/////AABKAAAAjQIAABYBAADFAgAA CAAAACYGDwAGAP////8BAA0AAAD7AgAAAAAAAAAAAAAAAAAAAAAAAAAABAAAAC0BAQAFAAAA CQIAAAACBQAAABQCAAAAAAQAAAACAQIAEAAAACYGDwAWAP////8AAEoBAACNAgAAdgIAAMUC AAAIAAAAJgYPAAYA/////wEABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAAAgECABAAAAAmBg8A FgD/////AABfAAAAvwAAAMEDAADpAAAABAAAAAcBBAAGBQAAQw+GAO4AAAAwAJABAAAAACgA YAPAAGAAKAAAAJABAAAwAAAAAQABAAAAAADACQAAAAAAAAAAAAACAAAAAgAAAAAAAAD///8A AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAA4ADAAAAAAAAAAAAAAAAAAAAAAAAAAAAP/8AHn/4AAAAAAAAAAAAAAAAAAAAAAAAAAA AAAP////4AAAAIAAAAAAAAAAAAAAAAAAP///8////+AAAAAAAAAAAAAAAAAAAAAAAAAAAAHg D/+///94B/xCAAAAAAAAAAAfwAAAD//////////QAAAAAAAAAAAAAAAAAAAAAAAAAAAB/w// //////9//AAAAAAAA/AA////////////////+AAAAAAAAAAAAAAAAA/AAAAAABBAf/////// ///////wAD//+D////////////////////wAAAAAAAAAAAAGAAYPwAAAAAAAf/////////// /////+A////////////////////////8AAAAAAAAAAAAAAAAH/gAAAAAE/////////////// /////////////////////////////AAAAAAAAAAAAAAAAB//8AIAAD////////////////// //////////////////////////4AAAAAAAAAAAAMAA/////8/wH///////////////////// ////////////////////////AAAAAH/AAf8cQhH///////////////////////////////// /////////////////////wAAAEf////////5//////////////////////////////////// //////////////////8AAAP///////////////////////////////////////////////// ////////////////AAD///////////////////////////////////////////////////// ////////////+wAA//////////////////////////////////////////////////////// //////////8AAP////////////////////////////////////////////////////////// ////////AAA///////////////////////////////////////////////////////////// /////wAAD/////////////////////////////////////////////////////////////// //8AAAP///////////////////////////////////////////////////////////////// AAAD//////////////////////////////////////////////////////////////gD8AAA Av///////////////////////////////////////////////////////////+AAAAAAAAP/ /////////////////////////////////////////////////////////5/gAAAAAAAAAH// /////////////////////////////////////////////////////8P4wAAAAAAAAAB///// //////////////////////////////////////////////4B8AHAAAAAAAAAAAAAf/////// //////////////////////////////////////3///+OA/gD8ZgAAAAAAAAAAH////////// ////////////////////////////////////////nwDwA+AAAAAAAAAAAAAH//////////// //////////////////////////////////4AA5gAAAAAAAAAAAAAAAAAAA/x//////////// //////////////////////////////+AAAAAAAAAAAAAAAAAAAAAAAAGeF4r+U+f//////// ////////////////////////////AAAAAJAAIAAAAAAAAAAAAAAAADyoQeAA+74Rz////AAI AIP/+f///////////////////4AAAAAAAAAAAAAAAAAAAAAAAAAYAYAAA/ABhIBiAuAAAAAD /4H//////////////////+wAAAAAAAAAAAAAAAAAAAAAAAAAAAAABgAwAACABgAAAAAAABAA H//////////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYIAQAAAAAAAAAAAAA AACD/wAAP///////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAAAAAAAABgAC jwIAMAAAAAAAABgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAADAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAA AAAAAiAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAoicAAEMPxgCIAAAAMACQAQAAAAAoAGADwABgACgAAACQAQAAMAAAAAEA CAAAAAAAwFQAAAAAAAAAAAAAAAEAAB0AAAAAAAAAGK3eACG13gAhtecAIbX3ABi1/wAYvf8A wMDAACnG9wAxzvcAOc7/ADnW/wBK1v8Azt73AFLe/wBa3v8A3uf3AGPn/wBr5/8Ae+f/AJTv /wCc7/8Ape//ALXv/wDW7/8Avff/ANb3/wDn//8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////xcWGv////////////// //8TFP////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////CgoKCgoKCg4ODhETExT//////////////xgZGBD//wkKCgoKCgwKDAwO Ef////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////8aFhYWFRQWDRcWGRkWGRYVFRMTDxMODw4MDAwPDAwK//////////////////// //////////////////8T//////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////8GAwQKAwoGCQMKCgoKCgoKCgoKCg4ODg8REf//FBYKAwUJ AwoDCgkJAwoJCgoKCgoKCgoMDA8PCg7///////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////8VFRUW////////////FxYWFRUVFBQTFBUJCP8VFRMTDxMPDw4O DAwODg8MDAoKCgkJ/wkJCQr//////////xkaGRcaFxYWFv///xT/////FP////////////// //////////////////////////////////////////////////////////////////////// ////ExMTEQ8KDP//////////////////////////////////CgMEBAoDCgYECQkKAwgKBAMF CgoKBAMKAwoDCgkFCgQDCgQECAkJCQkJCAgKCgkKCgoKCgoKChYTExMTExb/E/////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////FBMOFRYWFRUV/////xUT FQ8VFhMVFRQVExMVExMVExMKCgoKCg4JCgwMDAoKCgoMCgoJCQkJCQkJCQkJCQoJCgj/ChYW FhUWFRUTFhUWFf////////////////////////////////////////////////////////// /////xQTEw8TCv///////////////xsWFxYTExMPDwoMCgkDBAUFBQUFBQUFBQUFBQUFBQUF BQUFBQUFBQUFAQUFBQUFBQUFBQUFBQUFAwUGBAYKCQkJCQMGBQUDBhMRBhERERQTExMTExMT FhMWExYTExMTExMTFhQT//////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////FhcWFhYW //////////////////////////////////////////////////////8O//////8X//////// /xMTChYXFhMTDxEPDg4ODwoWFRYTFRMVExETEREREQoTExMTExMTExMTFAoKDAkKCgoKCgwO Dg8KCgQKBAoKCgkKCgoKCg4DCQkJCQkJCQgJCwMKCgQKAwoECgT//////////////////xMT DgoODA4RDxMUDwoMDg8PDwr//////xoYFxYVFg8UERMMDAoJBQUFBAUEBQQEBAUFBAEFBAUF BQUFAQUFBQUFBQUFBQUFBQEFBQUFBQUFBQUFBQEFBQUFBQUFBQUFBQUFBQUFBQUFBQYGAwYI CgoKCgoODg4PDhERExERExMTExMTExMKCQoKCgoKCgwKDw4KCgr///////////////////// //////////////////////////////////////////////////////////////8TEf////// ////////////ExH//////xcWFhcWFv////////////////////////////////////////// ////////////////////FxYWFRUVFRMTExMTDxETExMODw4ODAwMDAwMFhMTExMPEw8TERER EQ8UExMTExMTEw8ODg8ODAoKCgwKDA8PCgoKCgoKBAwKCgoEBAQKCgoJCgoKCgoECgQKAwoK AwoJCQkKAwoECgoKBP////////8WEQ4ODw4PDxQTEw8ODg4PDw8KCgoKAwQEBAUFAwUTEw8P DAwKCgUFBQUFBQUFBQUFBQUFBQUFBQEFBQUFAQUFAQUBBQUFBQUFBQUFAQUFAQUFAQUFBQUF BQEFAQUBBQEFAQUBBQEFBQUDBgkDCgMLCgoODgoODhERERETChMJCQkJCQkJCgoJCgoKCgoK DA8ODAMK//////////////////////////////////////////////////////////////// /////////////////////////////////////////////////xUVFRUWFhYWFhb///////// /////////////////////////////////////////w3//xMTExMPCgwKChYKExMUDxMPDgwO DAwODAwODAwMDAwMDAwMDAwODxMREw8MDgwMCgwKChMTEw8ODAwKDAoKCgoBAwMDBAoKCgoM CgoKBAQEBAQEBAoDCgMKCgMKBAQDCgoECgoKCgQKBAoKDAQKBQoKAwkJCgoDCgUKAwoDCgMK BgMPEQoOCgoKDgQEBgQFBQUFBgUFBgUFBQUFBQUFBQEFBQUFAQUFBQUBBQUFBQUBBQUBBQUF BQUFBQEFBQUFBQUFAQUFAQUBBQEFBQUGBgUGBQUFBQUGBgYGBgYKCAoGCQkGCggICAgICAgD CgYKAwkGCQkJCQkKCgoKCgoKDAoMDAoMDAoKCv////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////8WFhYWFhYWFhYWFhYWFhUWFf////////////8U/////////////////////////xQV FRQVEREPDwoKCgoKCgkJCQkKCgoODg4ODAwODgwODAwMDAwMDAwMCgwMCgoKCg4MDAoMCgoK Cg4KCgoKCgoKCgoKCgMKCgoDCgoBBQUDBAQEBAMEBAoKCgoKCgoKBQQKBQQEBAoDBQQECgMF CQQEBAQOCgkJCgkKCgYJAwoFCQQKAwoGCgMEAwYDBAQEBAYFBQoDBAQECgMGBgUFBQUFBQUF AQUFBQUBBQUFBQUFBQUFAQUFBQUFBQUFBQEFBQUFAQUFBQUBBQUFBQUFBgYGBAYIBggIBggI AwoDCAgICAMICAgGCQMKAwoDCgMKCgMKCgoKCgoKCgoKCgoKCgoKDAoKDAoKCgwKDAoK//// //////////////////////////////////////////////////////////////////////// /////xQU//////////////////8XFxcWFxYWFhYWFhYWFhYWFhYWFhUVFRYVFRUUFRQUFBUV //8TExQRExERD/////////8RExERERETERMRDw8ODAwMCgwMDAwMCgoKDAoKCgoMCgoKCgoK CgoKCgoKCgwKCgoKCgoKCgoKCQoOCgoKCgoKCgoKCgoKCgoKCgEKCgoFCgMDBAYEAwUKBAQE BQQEBAQEBAQKBAoECgMFCgQKAwUKBAQEBAQEBAQEBAQEBAQDBQoDCgQDCgQKBAMKBQoECgYG BAQFBQUEBAQEBAQEBAQEBQQEBAUDBQUFAQUBBQUBBQUBBQEFBQUFAQUFAQUFBQUFBQEFBQUG AQUBBQUGBgYFBQYDBgYIBggGCAgICAgICAgKAwkICgMJCgoKCgoKCgkKCgoKCgoKCgoKCgoK CgoKCgoKDAoKDAoMCgwMDA4KCg7//////////////////////xkZFxYXFxoWF/////////// //////8bFxoWFxoVFxf///8WFhX///8W/////xT/////FP///xQPFA8UExMTExMTFBMVDxMV ExUTExMTExMTExMVFRUTFRUVFRUVEw8TERERExERExEPExMPExETEw8TEw8TDxMPDw8PDgwM DAoMCgwKDAoKDAoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCQoK CgoDCgYKAQoKCgoDCgUKAQoFAwoECgMEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQE BAQEBAoDBQQEBAQEAwQEBAQEBAQEBAQEBAQEBAYEBgYEBgQFBAUEBQQEBQQFAwUFBQEFAQUF BQEFBQUFBQEFBQUFBQUFBgMGBQMGBgoGCAgGBgQGCggIBgkDCggICAgKCAkJCQkJCQkJCQoK CgoKCgoKCgkKCgoKCgoKCg4KCgoKCgoKCgoKCgwKCgwKDAoMDgwMDgoK////////////Gf// /xcWFRQVExQREREREQ8RERMPERMREw8TERERExETEw8TERERERETERETERERERERERERERER EQ8R//8REQ8PExMTFBMTFBMTFRQWExMTExUTExMTExMTExMTExMTExMODg4REw8TEw8TEw8T Ew8ODw4PDg4ODw4ODw4PDg4PDg4PDw4PDg4ODw4PDg8ODw8ODg4PDg4ODw8ODg4PDg4ODgoM DAoMDAoKCgoKCgoKCgoKCgoKCQoJCQkJCgoKBQoKCgoKCgoDCQUKBQMFAwUDBQMFAwQDBAQD BAQEBAQDBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAUEBAQEBAMEBAQEBAQFBAQEBAQE BAQEBQQDBQQEBQYGBQYGBgEFBgQGBQUGAQYFBQYBBQUGBgYFBgYFBgYGBgYDBgoDBgIICAgI BgMJBggICAgICAgKCQkLCgkKCQoBBgoGAQoGBgoGCgQGBgoDCgoDCgoDCQoKCgoKCgoKDAoK CgoKCgoKCgoKCv///////xMTExkXFhYWFhYVExMRExETERMRExERExERERMRERMRExETEREU DxETERMRERERDxETDw8RERERERERDxERDxMODw8REREPEQ8PDw8RDxEPDg8PDg8UExMUExMU ExQTExQTExMUDg8ODw4ODw4ODw4ODw4PDg8ODw4PDw4PDw4PDg4PDg8ODw4ODg8ODw8ODg8O Dw4ODg4ODg4ODg4ODg8PDg4ODg4OCg4KCg4KCg4KDgoOCgsKCgoKCgoJCQoKCgEKAQoDAwYD BQUDBgoKAwYKBQYFCQYKCQUFCQUDBQUDBAkFBAUDBQQDBAQFAwQDBQMFBAQEAwQEBAMGBgME BQMFBQQDBAQEBQMGBQMFAwUEAwUDBQUDBgMFBgMFBQMGAwYGBgYGBgYGBgYGBAYGBgoDBgoG BgMIBgYGBgYECgYIBggIBgYIBgYGBggIBggIBgYIBgMIBgYKAwYGBgYKBgoDCgkGAwYBBgYB CAMDAwMDAQMCCgkOCgoMDAkBCgkCCgoKCgoKCgoKAgoXFhkVFRUUFBMTExMREREREREPERER EREREREREREREw8RERERERERDhETDxEPDw8PDg4ODgwMDgoOEQ8PDw8REREREREPEQ8RERER EQ8PEQ8OEw8PDw8ODw8ODg4ODg4ODg8ODg4ODhEPEQ4PDg4ODw4ODw4ODw4PDg4PDg8ODw8P Dw4PDg4ODg4ODgwMDAwMDAwMCgwMDAoOCg4KCg4KCgoKCg4OCg4OCgoKAwkKCg4KCg4KCg4K Cg4KDgoOCg4KCgoMCgoOCgoOCgoKCgoOAQoIAgoDCgMIAwoBCQUDCQYDCQUDCQUFCgMFCgMF CQUFAwkGBgUKBgMGAwkGAwUGCgMJBgYICgMEBgUFAwUKAwkGAwoDBgkFCAMKBgMKBgMKBgMK BgYGBgYGBgYGAgYGAwYGBgYBBgYGAwoGAQoGCAYIBggGCAYICAgDCAYDBgYIAwYCBgIGAwgD AgMBCQICAgYBBQICCgoKCgoKCgoMAQoKCgoBCgoKCgoKCgkJCQkJCQkJCQkJCQkJCgkK/woK GxsbGhoaGhkaEREREREREREREREREQ8REREPEREREREREREREQ8REQ8RDhEPDw8PDw8ODg4O DAwOChEPEQ8PDw8PDw8PDw8PDg8ODg4ODg4ODg4MDgwMDAwMDAwKDgoOCgsOCgsRERERDg8O Dw4PDgwMDAwMDAwODg4ODg4ODg4ODg4ODg4ODg4ODgwMDgwMDAwMDAwKDAoMCgwKDgoKCgoK CgoKCgoKCgoKCgoJCgkJCQkJCQkJCQkJCQkJCQkKCgkJCQoKCgoKCgoKCg4KCwoOCg4KCwoK CgoKCgoKCgoKCgkJCQkDBQMGCgMGAwYDBgMGAwMGAwgGBgoGCAYJAwQKBgoBCAgGCAMIBgYJ AwYKCAYGCgMGCgkDCgMKBgMKCAgIBgQGCAYIBgIGAgoGAwoBCgEGCgYBCgYBAQgGAQgGAggG CAMIAwgICAgDCAgCCAgDCgIKCQkJCAsJCQkJAgkKCQwJCgoKCgoCCgoKCgoKCgwKCQkJCQkJ CQkJCQ4JDgkOAgkJDgkJCQkJDgkKChsbEBsaGhoaGxoZGRUVFRUTExMRERERERERERERERER EREREREREQ8REQ8PDg8ODw8ODg4ODg4OCQ4PDw8PDw8PDw8PDw8PDw4PDg4ODg4ODg4MDgwM DgwMDAwMDAwKDgoOCg4LCwsLCgoODg4ODgwODAwODA4MDg4ODg4ODg4ODg4ODg4ODg4ODg4M CgwMDAwODAwMDAwMCgwKCgoKCgoJCgoKCgoKCgoKCgoJCgkJCQkJCQkJCQkICQkICQoJCgkK CQoJCgkKCQoKCgoKCgoKCgoKCgoOCg4KDgoOCw4KCgoKCQkJCQkJCQkJCQgKCAsICAsICAsD CAoDBgMKAwYGAwYDCgMIAwgIAwgDCQYIAwYICAMIBgMGBgYIBQMKBAMIAwgBCgEKAgYGCgYG BAYGBgYGCgEKAwYKBgoGCQYKAwYDCAMGCgMIAggDCAEICAoDCAgJCQIICwkJCQkJCQkJCQkJ CQoJCgoKCgoKCgoMCQkJCQkOCwkOCQsCDgkJCQkJCQkJCQkJCQkVCQgJCgr//xsaGRUVFBkZ GRkZFRUVExERERERExERERMRERMPExETDxMRExERERMRERMPExERERERERERERERDxEPEREP DxEPDw8PDw8PDg8ODw4ODw4ODg4MDAwMDAwMDAoODAoMCg4KDgoLCwoRERETDg4PDg4ODw4O Dg8ODw4PDg4PDg4PDg4ODg8ODw4PDg8ODw4PDg8ODw4PDg8ODg4ODg4ODg4ODg4ODg4ODg4O Dg4ODg4ODg4ODg4ODg4ODg4OCAkJCQkJCQkJCgkKCgoKCgoKCgoKAQoKCgMKCgMKCgEKCgMB CgoKCAoKCQoICgoDCgoICggICggICggLCAIKCAsJAwoJCQkJCwkICwgICQkJCQoDCAoICgkJ AwoDCAgGCQYJCgkFAwYDBgMGBgMGAwMDAwMBAwMBAwEBAQEDAQMDAQMDAwMDAwMDAwMKAwgD CggGCggICAgICAgJCAkJCQkJCQkJCQkJCQkJCgkJCgkJCQkJCQkJCAkICQkJCRETFBMVExUV FRQUFBQVFBQVGRkZ/////xkZFRUUFBQTExMRERERERERERERExERExERExERERETERETERMR ERMRERMRERMREw8RERERERMREQ8REQ8RDw8REQ8PDw4PDg4PDg8PDg4ODA4ODAwODAwMDAwM DgoOCg4LCggUEREREQ8PDw4ODw4ODg4ODg8ODg8ODg8ODg8ODgwMDAwMDAwMDAwMDAwMDAwM DAwMDAoOCgoOCg4OCA4OCg4OCg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4M Dg4OCgoCCgkKAQoKCgoKCgoKCgoDCgoKCgoKCgMKCgoKCgoBCgoKCgMKCgoKCgoKCgMKCQsK CQoKCQgJCwgDCwkJCQkKAgoKAwkKCgkKAwoKAwoCCgEJAQEBAQEBAQEBAwEDAQMBAwMDAQMB AQEBAQEDAgEBAwEBAwMDAwMDAQIKAwQDCAgICAgICAgICwgJCQkJCQkJCQkJCQkJCgkJCQwJ DgkJDg4JEQ4OERERERQUERQRERQUERUUFBEOEQ4OGRkZEf///////xoZFRUTFBETERERERER ERERExETERETERETERMRERETERETDxMRExEREw8TEREREREPERMREREREREREREREREREQ8R EQ8PDw8PDw8PDw8PDw4ODg4MCg4MDAwMDg4KCw4VFA8TERMRDxEPDAwODA4MDAwMDAwMDAwM DgwODAoODAwMDAwMDAwMDAwMDAoODAwMCQ4KCg4KDgsKCw4IDgoLCg4KDgsOCgoODgoOCgoO CgoOCgoLDgoODgoKDg4ODg4ODg4ODg4ODg4ODg4ODAwMCgoKAQoCDgEKCg4BDgMOCgoKCgMK CgoKCgoKCgoKCgoKCgoKCggKCAoICQoICQkKCAoKCAoICQkJCgIKCgoKCgoKCgIKCgoCCgoK AQEBAQEBAQEBAQEBAQEBAQEBAwEDAwMDBgMGBgYEBgYKBgYDBgYGBAoGAwoJAwYKAwMICAII CAgCCAgICAIICQgJCQkJCwkJCwkJCQkJCQ4OCREOERERERERERQUFBQRFBQREREREQkRERMU FBH///////8ZGRkVFBUTExMTFBERExETERERERMRERETERMPExETEQ8TERETDxERExERERET ERETERERERERExEREREREREREREREQ8PEQ8RDw8PDw4PDw8ODw4ODg4PCg4KDg4KDgsKDhMO ERMPFBEPDgwODgwODg4MDAwMDAwMDgoOCgwODAoOCg4KDgwMDAwMDgwOCg4ODA4JDAkJDgoK DgoOCg4LCw4LCgsKDgoOCgsKCwoLCgoOCg4KDgoLCgsKDgoOCgoKCgoKCg4ODg4PDg8ODgoO AQ4BDgoKCgoKCg4BCgoCCgEOAQoOCgIKAQ4CAw4DCgMKAwMKAwMOCgIKCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgMKAwMKCgMDCgoDAQoBAQEDAQEBAQEBAQEBAQEBAQEBAQEDBgMGAwgGAwMI BgYIBggDCgMGCQYDBgkDCQIICAIICAIIAggICAgJCQkJCQIJAgkCCQkJCQkRDhEREREUFBQU FBQUFBX///////////8UFBMUExX/////////////Gv8UFRMUERMTExERERERERMRERERExER ERERERERERMRERETERETERERExETEREREREREQ8REQ8RDw8PDxEPDw8PDw8PDg8ODw4PDg4O DgoODgwMDAwMDAoOCg4OCg4KDgoLFBMTExMKDgwMDAwOCg4KDgwOCg4KDgoOCg4KCg4OCg4K DgoODAwMDAwMDA4KDgkODgkOCw4ODgoOCg4KDgoLDg4OCgoODgoLDgoKDgoLDgoKDgoLCgoK CwoLCwsOCgoKCgoKDgoKAgoKAQ4BDgEKCgoKCg4KCgoBDgECCgEOAQoKCgoDDgEOAwoDAgoD CwIDCgMDCgMCCgMDAwMDAwMKAwMCAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwYCAwYB BggGBgYKBQYEBAoGAwQKAwoICAgICAgICAgKAwkJCQkKDAkMDAkODg4ODg4RDhEJEQ4ODg8O Dg8RDhEREREREREOCRERERH//////////////////////////////////////////////xob GxkaGhkVFRMTERMRERMRERMRExERExERExERExERExERERMRERMPExEREQ8REQ8REREREQ8R EQ8PDw8PDw8PDw8PDw4PDg4PDg4ODg4ODAwMDAwOCg4KDgsKDgsLCwsLCgsVExMPDgoMDAwO Cg4ODgoOCg4OCg4KCg4KDg4LCg4KDgsKCQoJCQkJCQkCCQgJCAkICQgJAwgJCQgJCAkICQgJ CgkICQgJCwsOCwoOCwoOCwsLCg4JDgoOCg4KCgoKDgoOCgsKCgoKCgoKCgoKCgoKCgoKCgoK DgoOCg4KCgIKAgoCAwIDAwMCAgIDAgMDAgMCAwIDAwIDAwICAgMCAgIBAwMDAwMDAwMCAgIC AgICAgICAgMCAgMCAwYICAgICAgFAwYDAwMDAwMDAgMCAQoDCgoDCgMJCAgKAwYCCQkJCQkJ CQkOCQkODg4ODhERCREJEQkOEQ4OERERERERFBT//xQVGRkZFRka//////////////////// /////////////////////////////////////////xERERERERERERETERETERETERMRExET ERMRERMRExERERMRERERERERDxERERERDhEREQ8RDxEPDw8PDw8ODg4ODg4ODg4ODAwMCg4K DgoOCgsOCgsOCgsKExMREREODgoKDAoOCg4KDAoOCg4KDg4IDgoKDgoOCg4KCAsJCgkJAwkJ CQkJCAkICQgJCAkJCAgJCAgICQgKCAgICQgJCAsICQgJCAgJCAgLCAgLCwsLCwoLCgsOCgsL CgoKCgoKCgoKCgoJCgoKCgoKCgoKCgIKAgoCDgIKAgMDAgMDAgMCAwMCAgMCAgICAgIDAgID AgIDAgMCAwICAgICAgICAgICAgICAgICAgICAgICAgICAgEKAQgIBggICAgICAkJCAkJCQkJ CQkJDAMJAQkBAg8CAhEUERMDDgkODg4OEQ4OExEUExUVFRMTFRkZGRUVFRT/////GRkVGRkZ Gf///xsa//////////////////////////////////////////////////////////////8Z ERETERETERMRERMRERMREREREQ8PDxETERMPEw4RExERERERExERERERDxERDxMPEQ4TEQ8P Dw8PDw8PDw4ODg4ODg4ODg4KDgoOCg4KDgsLCwoOCwoKFRUKDxERDg4OCQ4JDgkKCg4KCg4J DgoKDgwODgoOCg4JAwgICQgDCQkJCQkJCQkJCQkICQgJCAoIBgYKCAsICAMICAkICgMKAwgK CAgJCAgKAwgICAgICAgICAgICAoICAgKAwoKCgoKCgoKCgoKCgoKCgoKCgkJCgkICQgJCQkJ AgoCCQoCCAkCCAsIAgkIAgICCAICAgIBAgICAgICAgICAgICAgICAgEBAgICAwECAgIBAwMD CAgGCAoDCggICAgICAgCCQ4JDgkLCQ4JCQkJCQkMDAwOERMRERMT//////////8RERERE/// ////////////FRQV//////////////////////////////////////////////////////// ////////////////////////////GhERERERERERERMTEREREREREREODg8PDw8ODg4ODw8T EREREREPDw4ODg4KDg8PDg4OCQ4JDg4ODg4OCQ4KCwkOCgsKDw4MDAoOCQkLCwoLCw4LCwsL ChYTERMREw8RDg8ODw4ODg4KDA4JDAkOCQkKCQkJCQkJCQ4IDgkOCQkJCQkJCQsJCQkICAkJ CAkJAwoJCQMICAgKCQMKCAgJCQkKCAMKCAgKCAkICAgICAgICAgIAwgGAwgGAwgICggBCgYK AQoGCAgDCgEGCAMGCAgDCggKBgMKCQgJCQgICgoICwgICAgICwgICAgICAgICAgICAgICAgI CAgIAggGCAMIBggIBgMDCAgDCAgDAwMKAwYGBv8DCwgICAkICQgCCQIOAg4CEQ4JDgkJCQ4O Ef///xQUFf////////8RDgkCCQIO////////////Dg4OEQ4R////FQ7//xEJ//////////// /////////////////////////////////////////////////////////xUUFBQRERQRERER EREREREREREREQ4ODg8ODg4ODw4RERETEREODw4ODg4JDAwPDw8ODg4ODgkODg8ODg4JDgsI CgoKDg4PCQ4JDgsLCgoLCwgDCwsLCggJERUTExETEQ4PDg4ODw4ODg4JDg4LDg4JCQkJCQkJ CQkJCAsCCQkJCQkJCQkJCQkJCQgICQkDCQkKAwkKAwoDCgMJCQIJCQMJAwkKAwkIAwkICQgL CAgICAgICAgICAgICAgDCAMGCAgDAwYICAEKAwYKAwgKAwYIAgYIAggBBggIBggICAIIBggD CAgLCAgDCAgICAgICAgICAgICAgIAwgICAgDCAgICAgDCAgDCAMICAMICAYIBggIAggJCAgI CAgICQIOCQ4JDwkPCQ8TDxEREQ4OCRH//wgDCQkJ//////////8CDg4P/////////////wkU FBMV//////////////////////////////////////////////////////////////////// ////////////////////GxUVFBQUEREREREREREREREUEREOCQ4OCQkODgsOCQ4JDggLDgkL Cw4JDgkOCQ4JDgkOCQ4JCwsODgkIDgkODgkPDAwMDgkLCwsLCQkICAkOCgoOCBEOERERDg4R Dw4ODg4ODg4ODg4ODgsRCw4ODg4ODxERERERERERERMREREREREREREREQ4ODg4JDA4KCg4M DgkJCQ4JDg4JCQ4MDgkJDgkJCQgICAgICQkICAgICAgCCAgICAMICAMICAYICAgIAwgGAwMG AwYDCAMGAgYCBggCCAgGCAgGCAgDCAgDCAgGCAgICAIICAIIAggIAwgGCAgDCAgICAMICAgI AwgICAMGCAgDAggCAwIDCAgICAkJDg4ODg4O////////////////////Ag4J//8JCf////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////8UExETEREREf// /w4RDg4OCQ4ODhELEQsODgsOCQ4OCQ4OCQ4ODg4ODgkODgsOEQsLDggOCQ4JDgkOCQ4ODgkI DgkLCAkJCQkJCQkJCQoKCg4KChERDg4ODg4ODg4ODg4ODhERDhERDhEODg4RERQTERURERER EREUExMREREREREOEQ4JDg4JDg4JDgkODg4ODg4ODg4OCQkODgoOCg4LCwoLDgoLCwsLCwsK CgsLCAIIAwgDCAMICAgIAgEIAwgDCAgGAggCCAIIAggCCAIIAQoDCAMICAgICAgIAwgLAwgI BgIGAggGAwMIAwgDAggICAMDAgMIAwMCAgICAgICCAgKAggICAYGBgYGCv////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////xEO//8RDg4L/////xH/Dg4JDv///w7/Ef8OCRMJCQ4O//8O/xH//xEO CQsO//8OCw4RDgkODgkOCQ4ODg4OCQkJDgoKCQsLCQkJCQsJDg4ODg4KDgsODg4ODg4ODg4O Dg4TFBUZGRoZGRkZGhkZGRUZFhkZGRkZGRUVFBQUFBQREREODg4ODg4RDg4ODg4ODhETERER EQ4OCw4JCQkJCQoLCwsLCwkLCQsOCg4KCgsLCwsLCwsLCgIKAwoIAggCCAIDCAgICAgICAgI CAgICAgJAwoDCAgICAgICAgDCAgIAwsICAsGCAkIAwsCCggCCwILCAsIAgsICwgLCQkLCQsJ CAkICQgIBgYGBv//////////////////////////////////////////Cf//Cf////////// ////////Dv////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////xELDhH//xH/Dv8R//// /xH//////w4PCRH/////////////////CQkJCRH/Ag4O/w4JDggR/////wn///8IBgj//woJ Dg4OCwsREQ4LEQ4RERMTERMPDw8OExEU//////////////////8b//////////////8V//// //8RDhERDhEOERERERMRERT//xEREREODg4ODg4ODg4ODg4ODg4ODg4OCgkJCQoLCgoKCgsK CgsJCQoJCQoJCQkJCwgJCAkJCAkJCAkLCwkJCgoKCQsICAgICAMIAwgDCAgDCwMIAwsDCwMJ CQsCCQIIAgkICQMJCQgICAgICAgJCAgCCAgICAYGCAgO//////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////ERH/////////////ERH///////////////////////////8RDg4JCQn///// /////////w4O/////wv//wr//////////w4I////CP////////8J/woECv////////////// ////////////////////////////////HBoaFBQRFBUVGRn///////8aFRQREQsJCAkLDg4O Dg4ODg4LDg4ODg4ODg4ODg4ODg4ODg4OCg4PDwkJCgkJCQkJCwMLCAMLAgkICAgICQoJCQkJ CAkJCQkJCQkJCAkICQkJCQsICQkJCQkICQkICwgJCQkJCQkJCQsKCgoKCgoKCg4KDv8IBv// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////DhH//////////////w4O//////////////////////////8J////////////////Bgr/ ////////////////////////////////////////////////////////////////////FP// /////////////////xMPDg4ODhERDg4RCxEOEQ8PEREREQ8REREREQ4ODg4OERERDg4RDhEO EQ4OEREUFBMUFBQTDhMODg4ODgkOEQkJCQkJCQkICQkICQgJCQkLCQkJCQkICQkICAgICAgI CQkJCQgLCgsKCgsKCwoOCw4D//////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /w4K//////8O/////////////w7///////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////wj//////xEOExMRExMRDxP///////////////////////8VFRUUFBQVFBQU FBQUFRQUFBQVFRQUFRUUFBQUExQUFBQUFRQVFRQUFBUUFBUVFBT///////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////////BAn/ //////////////////////////////////////////////////////////////////////// /////////////////wMO////////////////////Cf8O////Cg4IEf///////w7///////// /////wMO//////////////////////////////////////////////////////////////// /////////wgK//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////8KCP///////////////////////////w7///////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////wr///////////////////////////////////////////////////////// ////////////////////////////////////////Cv///wr///////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////wn///////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// BAAAAAcBAQAIAAAAJgYPAAYA/////wEABwAAAPwCAQAAAAAAAAAEAAAALQEEAAQAAAAtAQAA BwAAABsEwQCMA0gAYAAEAAAALQEDAAQAAAAtAQIABQAAAAkCAAAAAgUAAAAUAgAAAAATAAAA +wLL/wAAAAAAAJABAAAAAAAAACJBcmlhbCBCbGFjawBEAAQAAAAtAQUABAAAAPABAQAFAAAA CQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQArAAAAMgptAGoAGAAAAFNJUCBBdXRo ZW50aWNhdGlvbiB1c2luZycAFAAnABIAKQAkABcAJAAjACQAGAARACQAIwAYABIAIwAkABIA IwAhABIAIwAkAAQAAAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgA BAAAAAIBAQAbAAAAMgqtAGoADQAAAENIQVAtUGFzc3dvcmQAKgAsACoAJgASACYAJAAgACEA MgAkABcAJAAEAAAALgEBAAQAAAACAQIABAAAAAIBAgAEAAAALQEEAAQAAAAtAQAABwAAABsE UwKBA5gB4AAEAAAALQEDAAQAAAAtAQIABQAAAAkCAAAAAgUAAAAUAgAAAAATAAAA+wLV/wAA AAAAAJABAAAAAAAAACJBcmlhbCBCbGFjawBtYQQAAAAtAQEABAAAAPABBQAFAAAACQIAAAAC BQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAeAAAAMgrFAeoADwAAAEJyeWFuIEouIEJ5ZXJs eQAhABMAGgAdABwADgAdAA4ADgAhABoAHQATAA4AGgAEAAAALgEBAAQAAAACAQIABQAAAAkC AAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEAHAAAADIKAgLqAA4AAABEYXZpZCBXaWxs aWFtcyEAHQAaAA4AHAAPACoADgAPAA4ADgAcACsAGgAEAAAALgEBAAQAAAACAQIABAAAAAIB AgAEAAAALQEEAAQAAAAtAQAABwAAABsEXgHBAiABeAAEAAAALQEDAAQAAAAtAQIABQAAAAkC AAAAAgUAAAAUAgAAAAAVAAAA+wLV/wAAAAAAAJABAAAAAAAAABJUaW1lcyBOZXcgUm9tYW4A eLoEAAAALQEFAAQAAADwAQEABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEA EAAAADIKTgGjAAYAAABkcmFmdC0VAA8AEwAOAAwADgAEAAAALgEBAAQAAAACAQIABQAAAAkC AAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEAEAAAADIKTgECAQYAAABieWVybHkVABUA EwAPAAsAFgAEAAAALgEBAAQAAAACAQIABQAAAAkCAAAAAgUAAAAUAgAAAAAEAAAALgEYAAQA AAACAQEAHgAAADIKTgFvAQ8AAAAtc2lwLXJhZGl1cy0wMC4ADgARAAsAFgAOAA4AEwAVAAwA FgAQAA4AFgAVAAsABAAAAC4BAQAEAAAAAgECAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4B GAAEAAAAAgEBAAwAAAAyCk4BaQIDAAAAdHh0AAwAFQAMAAQAAAAuAQEABAAAAAIBAgAEAAAA AgECAAQAAAAtAQAABAAAAC0BBAAQAAAA+wIQAAcAAAAAALwCAAAAAAECAiJTeXN0ZW0AbgQA AAAtAQEABAAAAPABBQAPAAAAJgYPABQAVE5QUAQADAAAAAAAAAAAAAAAAAAJAAAAJgYPAAgA /////wEAAAADAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAC3D0QAAABBAHIAaQBhAGwAAABwAGUAIABTAG8AcgB0AHMA AAAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAGIgAAqQ8KAAAABwAAAAIA CQQAAEAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP// 7wAAAAAA////////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAA AAAABQAAgASABAAAAAAPAAsEaAEAAA8AAPBgAQAAAAAG8NAAAAACaAAAGQAAADsAAAAHAAAA AAAAAAcAAAACAAAABQAAAAEAAAAIAAAAAwAAAAgAAAAAAAAATQAAAAQAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAABUAAAABgAAAFMAAAAAAAAABAAAAAAAAAAEAAAABwAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAAQAAAAEAAAABAAAAAAAAAAEAAAAHwAB8CwAAABiAAfwJAAAAAYGEe7EF8m/ KGE+iN/DK/gOLP8ADw0AAAIAAAAAAAAAAABeAWMAC/AkAAAAgQEEAAAIgwEAAAAIvwEQABAA wAEBAAAI/wEIAAgAAQICAAAIIAAa8QgAAAAzM8wAAACZAEAAHvEQAAAABAAACAEAAAgCAAAI 9wAAEB8A8A84AAAAAADzAxQAAAACAAAABAAAAAAAAAABAACAAAAAAAAA8wMUAAAAAwAAAAQA AAAAAAAAAgAAgAAAAAAPANAHzwAAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAADYAAABk AAAANgAAAGQAAABktGIAiokKMFy0YgAIAAAAZhIAAMAJAADi/P//sv///wEAAABwAPsDCAAA AAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAf AAcEPAAAAAAA/QM0AAAAIQAAAGQAAAAhAAAAZAAAAAy2YgAMtmIAAQAAAAAAAADEEQAAXAoA AAAAAAAAAAAAAAD//z8A2Q8MAAAAAADaDwQAAAAAACUADwDwD40JAAAAAPMDFAAAAAQAAAAE AAAAAgAAAAABAAAAAAAAAACfDwQAAAAGAAAAAACoDyYAAABTSVAgQXV0aGVudGljYXRpb24g dXNpbmcgQ0hBUC1QYXNzd29yZBAAnw8EAAAABQAAAAAAqA8eAAAAQnJ5YW4gSi4gQnllcmx5 DURhdmlkIFdpbGxpYW1zAADzAxQAAAAGAAAAAAAAAAIAAAACAQAAAAAAAAAAnw8EAAAAAAAA AAAAqA8WAAAAUHJvYmxlbSBhbmQgT2JqZWN0aXZlcxAAnw8EAAAAAQAAAAAAqA/KAQAAUHJv YmxlbQ1IVFRQLURpZ2VzdCB1c2VyIGF1dGhlbnRpY2F0aW9uIGlzIG5vdCBjb21wYXRpYmxl IHdpdGggZGVwbG95ZWQgYmFja2VuZCBSYWRpdXMgc2VydmVycy4NU0lQIHVzZXIgYXV0aGVu dGljYXRpb24gKFJGQzI2MTcpIGFuZCBSYWRpdXMgKFJGQyAyMTM4KSB1c2VyIGF1dGhlbnRp Y2F0aW9uIHJ1biBNRDUgb3ZlciBkaWZmZXJlbnRseSBmb3JtYXR0ZWQgbWVzc2FnZXMuDU9i amVjdGl2ZQ1Qcm92aWRlIG1lY2hhbmlzbSB0byBhbGxvdyBhdXRoZW50aWNhdGlvbiBvZiB1 c2VycyB1c2luZyBkZXBsb3llZCBSYWRpdXMgc2VydmVycy4NQWR2YW50YWdlb3VzIHRvIElT UHMgZGVwbG95aW5nIFNJUCB2b2ljZSBzZXJ2aWNlIHRvIFBQUCBjdXN0b21lcnMNQXBwcm9h Y2hlcw1FeHRlbmQgU0lQIHRvIHN1cHBvcnQgQ0hBUC1QYXNzd29yZA1FeHRlbmQgUmFkaXVz IHRvIHN1cHBvcnQgSFRUUC1EaWdlc3QAAKEP1gAAAAgAAAAAAAAAAADRAAAAAQAAAAAACgAA AAAAAAAAAJQAAAABAAAAAAALAAAAAAAAAAAASQAAAAEAAAAAAAcAAAAAAAIAHAABAAAAAAAC ABQAsQAAAAAAAgASABUAAAABAAIAgQASAAoAAAAAAAIAEgABAAAAAAACABQACQAAAAAAAgAc AAEAAAAAAAIAFAA5AAAAAAACABIACAAAAAEAAgCBABIAEQAAAAAAAgASAEEAAAAAAAIAEAAB AAAAAAACABgACwAAAAAAAgAcAEkAAAAAAAIAEgAAAKoPGgAAAEQBAAAAAAAABQAAAAEAAAAD AIIAAAAAAAAAAADzAxQAAAAVAAAAAAAAAAIAAAASAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8a AAAAQ29tcGFyaXNvbiBvZiBoYXNoIGZvcm1hdHMQAJ8PBAAAAAEAAAAAAKAP+gEAAEMASABB AFAALQBQAGEAcwBzAHcAbwByAGQAOgAgAE0ARAA1AA0ATQBEADUAKABzAGUAcQBuAHUAbQAs ACAAdQBzAGUAcgAtAHAAYQBzAHMAdwBvAHIAZAAsACAAbgBvAG4AYwBlACkADQANAEgAVABU AFAALQBEAGkAZwBlAHMAdAA6ACAATQBEADUADQBNAEQANQAoAHUAbgBxACgAdQBzAGUAcgBu AGEAbQBlAC0AdgBhAGwAdQBlACkAIAAcIDoAHSAgAHUAbgBxACgAcgBlAGEAbABtAC0AdgBh AGwAdQBlACkAIAAcIDoAHSAgAHAAYQBzAHMAdwBvAHIAZAApAA0ASABUAFQAUAAtAEQAaQBn AGUAcwB0ADoAIABNAEQANQAtAHMAZQBzAHMADQBNAEQANQAoAHUAbgBxACgAdQBzAGUAcgBu AGEAbQBlAC0AdgBhAGwAdQBlACkAIAAcIDoAHSAgAHUAbgBxACgAcgBlAGEAbABtAC0AdgBh AGwAdQBlACkAIAAcIDoAHSAgAHAAYQBzAHMAdwBvAHIAZAAgABwgOgAdICAAdQBuAHEAKABu AG8AbgBjAGUALQB2AGEAbAB1AGUAKQAgABwgOgAdICAAdQBuAHEAKABjAG4AbwBuAGMAZQAt AHYAYQBsAHUAZQApACkAAAChD3gAAAATAAAAAAAAAAAAIwAAAAEAAAAAABEAAAAAAAAAAAA7 AAAAAQAAAAAAFgAAAAAAAAAAAGYAAAABAAAAAAATAAAAAAACABgAIwAAAAAAAgAYABEAAAAA AAIAGAA7AAAAAAACABgAFgAAAAAAAgAYAGYAAAAAAAIAGAAAAKoPqgAAABcAAAAAAAAABgAA AAEAAAADAC4AAAAAAAAAAwAAAAEAAAADABUAAAAAAAAAAwAAAAEAAAADAC0AAAAAAAAABAAA AAEAAAADAAUAAAAAAAAAAwAAAAEAAAADABUAAAAAAAAAAwAAAAEAAAADAB8AAAAAAAAAAwAA AAEAAAADABIAAAAAAAAAAwAAAAEAAAADAAEAAAAAAAAABgAAAAEAAAADAAkAAAAAAAAAAADz AxQAAAAKAAAABAAAAAIAAAAGAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8sAAAAU0lQIFVzZXIg QXV0aGVudGljYXRpb24gdXNpbmcgUmFkaXVzIGJhY2tlbmQQAJ8PBAAAAAEAAAAAAKoPCgAA AAEAAAABAAAAAAAAAPMDFAAAAAwAAAAAAAAAAgAAAAgBAAAAAAAAAACfDwQAAAAAAAAAAACo DwYAAABGdXR1cmUQAJ8PBAAAAAEAAAAAAKgP6wAAAFJlbWFpbmluZyBpc3N1ZXMNTXVsdGlw bGUgUHJveHktQXV0aG9yaXphdGlvbiBoZWFkZXJzIChzZW1pY29sb24gdnMuIGNvbW1hIHNl cGFyYXRlZCB0YWdzKQ1JcyBhZGRpdGlvbmFsIGNvbXBsZXhpdHkgb2YgTWFobGVyIGRyYWZ0 IG5lY2Vzc2FyeT8NUmVmbGVjdGlvbiBhdHRhY2sgaW4gdHJ1c3RlZCBzaWRlIG9mIG5ldHdv cmsNUHJvcG9zZWQgbmV4dCBzdGVwcw1TSVAgV0cgaXRlbQ1TdGFuZGFyZHMgdHJhY2sAAKEP fgAAABEAAAAAAAAAAAB+AAAAAQAAAAAALQAAAAIAAAAAABQAAAAAAAAAAAAcAAAAAQAAAAAA EQAAAAAAAAB+AAAAAAACABgAFQAAAAAAAgAUAAcAAAABAAIAgQAUABEAAAAAAAIAFAAUAAAA AAAAABsAAAAAAAIAGAABAAAAAAAAAAAAqg8aAAAAQAAAAAAAAAADAAAAAQAAAAMAqQAAAAAA AAAAAOoDAAAAAAAAchcIAAAAAQAQAHJIAAAAAPUPHAAAAAABAACSDgADTkgAAApXAAABAAAA FgAAAAEAYgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD2DyIAAAAUAAAAX8CR44I5AAAKAPQDAwBiAE1lZHNjaG9sYXIIAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAD+////CQAAAAoAAAALAAAADAAAAA0A AAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAA GwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJAAAAGoAAAAmAAAAJwAAACgA AAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEAAAAyAAAAMwAAADQAAAA1AAAA NgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAAPwAAAEAAAABBAAAAQgAAAEMA AABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwAAABNAAAATgAAAE8AAABQAAAA UQAAAFIAAABTAAAAVAAAAFUAAABWAAAA/v///1gAAABZAAAAWgAAAFsAAABcAAAAXQAAAP7/ ///////////////////////////////////////////////////9////aQAAAP7///9rAAAA bAAAAG0AAABuAAAAbwAAAHAAAABxAAAAVwAAAP7///90AAAA/v////////////////////// ////////////////////////////////////////UgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABYABQH//////////wMA AAAQjYFkm0/PEYbqAKoAuSnoAAAAAAAAAAAAAAAAQH4DUkViwAFzAAAAwAMAAAAAAABQAGkA YwB0AHUAcgBlAHMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAEgACAf////8CAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAEAAAAAAAAEMAdQByAHIAZQBuAHQAIABVAHMAZQByAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAaAAIA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAAACoAAAAAAAAABQBTAHUAbQBtAGEAcgB5AEkA bgBmAG8AcgBtAGEAdABpAG8AbgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgEBAAAA BQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlAAAAJGMAAAAA AABQAG8AdwBlAHIAUABvAGkAbgB0ACAARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAKAACAf///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAgAAAA+VwAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkA SQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAAAAAA4AAIBBAAAAP//////////AAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFwDAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC3D0QAAABUAGkAbQBlAHMAIABOAGUA dwAgAFIAbwBtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAGEhAA tw9EAAAAQQByAGkAYQBsACAAQgBsAGEAYwBrAAAAbQBhAG4AAAAMtmIADLZiADS0YgAEiQow WLRiAAgAAABYtGIAiokKMAAABiIgALcPRAAAAFQAYQBoAG8AbQBhAAAAbABhAGMAawAAAG0A YQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAYiMAC3D0QAAABNAG8A bgBvAHQAeQBwAGUAIABTAG8AcgB0AHMAAAAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0 YgCKiQowAgAGAkAAtw9EAAAAQQByAGkAYQBsAAAAcABlACAAUwBvAHIAdABzAAAAAAAMtmIA DLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABiIAAKkPCgAAAAcAAAACAAkEAABAAKMP bgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP// /////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAE gAQAAAAADwALBGgBAAAPAADwYAEAAAAABvDQAAAAAmgAABkAAAA7AAAABwAAAAAAAAAHAAAA AgAAAAUAAAABAAAACAAAAAMAAAAIAAAAAAAAAE0AAAAEAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAAVAAAAAYAAABTAAAAAAAAAAQAAAAAAAAABAAAAAcAAAAEAAAAAAAAAAQAAAAAAAAA BAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAA AAAEAAAABAAAAAQAAAAAAAAABAAAAB8AAfAsAAAAYgAH8CQAAAAGBhHuxBfJvyhhPojfwyv4 Diz/AA8NAAACAAAAAAAAAAAAXgFjAAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8B CAAIAAECAgAACCAAGvEIAAAAMzPMAAAAmQBAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAP OAAAAAAA8wMUAAAAAgAAAAQAAAAAAAAAAQAAgAAAAAAAAPMDFAAAAAMAAAAEAAAAAAAAAAIA AIAAAAAADwDQB88AAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAAA2AAAAZAAAADYAAABk AAAAZLRiAIqJCjBctGIACAAAAGYSAADACQAA4vz//7L///8BAAAAcAD7AwgAAAAAAAAAcAgA AHAA+wMIAAAAAQAAAEALAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwAHBDwAAAAA AP0DNAAAACEAAABkAAAAIQAAAGQAAAAMtmIADLZiAAEAAAAAAAAAxBEAAFwKAAAAAAAAAAAA AAAA//8/ANkPDAAAAAAA2g8EAAAAAAAlAA8A8A+NCQAAAADzAxQAAAAEAAAABAAAAAIAAAAA AQAAAAAAAAAAnw8EAAAABgAAAAAAqA8mAAAAU0lQIEF1dGhlbnRpY2F0aW9uIHVzaW5nIENI QVAtUGFzc3dvcmQQAJ8PBAAAAAUAAAAAAKgPHgAAAEJyeWFuIEouIEJ5ZXJseQ1EYXZpZCBX aWxsaWFtcwAA8wMUAAAABgAAAAAAAAACAAAAAgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFgAA AFByb2JsZW0gYW5kIE9iamVjdGl2ZXMQAJ8PBAAAAAEAAAAAAKgPygEAAFByb2JsZW0NSFRU UC1EaWdlc3QgdXNlciBhdXRoZW50aWNhdGlvbiBpcyBub3QgY29tcGF0aWJsZSB3aXRoIGRl cGxveWVkIGJhY2tlbmQgUmFkaXVzIHNlcnZlcnMuDVNJUCB1c2VyIGF1dGhlbnRpY2F0aW9u IChSRkMyNjE3KSBhbmQgUmFkaXVzIChSRkMgMjEzOCkgdXNlciBhdXRoZW50aWNhdGlvbiBy dW4gTUQ1IG92ZXIgZGlmZmVyZW50bHkgZm9ybWF0dGVkIG1lc3NhZ2VzLg1PYmplY3RpdmUN UHJvdmlkZSBtZWNoYW5pc20gdG8gYWxsb3cgYXV0aGVudGljYXRpb24gb2YgdXNlcnMgdXNp bmcgZGVwbG95ZWQgUmFkaXVzIHNlcnZlcnMuDUFkdmFudGFnZW91cyB0byBJU1BzIGRlcGxv eWluZyBTSVAgdm9pY2Ugc2VydmljZSB0byBQUFAgY3VzdG9tZXJzDUFwcHJvYWNoZXMNRXh0 ZW5kIFNJUCB0byBzdXBwb3J0IENIQVAtUGFzc3dvcmQNRXh0ZW5kIFJhZGl1cyB0byBzdXBw b3J0IEhUVFAtRGlnZXN0AAChD9YAAAAIAAAAAAAAAAAA0QAAAAEAAAAAAAoAAAAAAAAAAACU AAAAAQAAAAAACwAAAAAAAAAAAEkAAAABAAAAAAAHAAAAAAACABwAAQAAAAAAAgAUALEAAAAA AAIAEgAVAAAAAQACAIEAEgAKAAAAAAACABIAAQAAAAAAAgAUAAkAAAAAAAIAHAABAAAAAAAC ABQAOQAAAAAAAgASAAgAAAABAAIAgQASABEAAAAAAAIAEgBBAAAAAAACABAAAQAAAAAAAgAY AAsAAAAAAAIAHABJAAAAAAACABIAAACqDxoAAABEAQAAAAAAAAUAAAABAAAAAwCCAAAAAAAA AAAA8wMUAAAAFQAAAAAAAAACAAAAEgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPGgAAAENvbXBh cmlzb24gb2YgaGFzaCBmb3JtYXRzEACfDwQAAAABAAAAAACgD/oBAABDAEgAQQBQAC0AUABh AHMAcwB3AG8AcgBkADoAIABNAEQANQANAE0ARAA1ACgAcwBlAHEAbgB1AG0ALAAgAHUAcwBl AHIALQBwAGEAcwBzAHcAbwByAGQALAAgAG4AbwBuAGMAZQApAA0ADQBIAFQAVABQAC0ARABp AGcAZQBzAHQAOgAgAE0ARAA1AA0ATQBEADUAKAB1AG4AcQAoAHUAcwBlAHIAbgBhAG0AZQAt AHYAYQBsAHUAZQApACAAHCA6AB0gIAB1AG4AcQAoAHIAZQBhAGwAbQAtAHYAYQBsAHUAZQAp ACAAHCA6AB0gIABwAGEAcwBzAHcAbwByAGQAKQANAEgAVABUAFAALQBEAGkAZwBlAHMAdAA6 ACAATQBEADUALQBzAGUAcwBzAA0ATQBEADUAKAB1AG4AcQAoAHUAcwBlAHIAbgBhAG0AZQAt AHYAYQBsAHUAZQApACAAHCA6AB0gIAB1AG4AcQAoAHIAZQBhAGwAbQAtAHYAYQBsAHUAZQAp ACAAHCA6AB0gIABwAGEAcwBzAHcAbwByAGQAIAAcIDoAHSAgAHUAbgBxACgAbgBvAG4AYwBl AC0AdgBhAGwAdQBlACkAIAAcIDoAHSAgAHUAbgBxACgAYwBuAG8AbgBjAGUALQB2AGEAbAB1 AGUAKQApAAAAoQ94AAAAEwAAAAAAAAAAACMAAAABAAAAAAARAAAAAAAAAAAAOwAAAAEAAAAA ABYAAAAAAAAAAABmAAAAAQAAAAAAEwAAAAAAAgAYACMAAAAAAAIAGAARAAAAAAACABgAOwAA AAAAAgAYABYAAAAAAAIAGABmAAAAAAACABgAAACqD6oAAAAXAAAAAAAAAAYAAAABAAAAAwAu AAAAAAAAAAMAAAABAAAAAwAVAAAAAAAAAAMAAAABAAAAAwAtAAAAAAAAAAQAAAABAAAAAwAF AAAAAAAAAAMAAAABAAAAAwAVAAAAAAAAAAMAAAABAAAAAwAfAAAAAAAAAAMAAAABAAAAAwAS AAAAAAAAAAMAAAABAAAAAwABAAAAAAAAAAYAAAABAAAAAwAJAAAAAAAAAAAA8wMUAAAACgAA AAQAAAACAAAABgEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPLAAAAFNJUCBVc2VyIEF1dGhlbnRp Y2F0aW9uIHVzaW5nIFJhZGl1cyBiYWNrZW5kEACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAA AAAAAADzAxQAAAAMAAAAAAAAAAIAAAAIAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8GAAAARnV0 dXJlEACfDwQAAAABAAAAAACoD+sAAABSZW1haW5pbmcgaXNzdWVzDU11bHRpcGxlIFByb3h5 LUF1dGhvcml6YXRpb24gaGVhZGVycyAoc2VtaWNvbG9uIHZzLiBjb21tYSBzZXBhcmF0ZWQg dGFncykNSXMgYWRkaXRpb25hbCBjb21wbGV4aXR5IG9mIE1haGxlciBkcmFmdCBuZWNlc3Nh cnk/DVJlZmxlY3Rpb24gYXR0YWNrIGluIHRydXN0ZWQgc2lkZSBvZiBuZXR3b3JrDVByb3Bv c2VkIG5leHQgc3RlcHMNU0lQIFdHIGl0ZW0NU3RhbmRhcmRzIHRyYWNrAAChD34AAAARAAAA AAAAAAAAfgAAAAEAAAAAAC0AAAACAAAAAAAUAAAAAAAAAAAAHAAAAAEAAAAAABEAAAAAAAAA fgAAAAAAAgAYABUAAAAAAAIAFAAHAAAAAQACAIEAFAARAAAAAAACABQAFAAAAAAAAAAbAAAA AAACABgAAQAAAAAAAAAAAKoPGgAAAEAAAAAAAAAAAwAAAAEAAAADAKkAAAAAAAAAAADqAwAA AAAAAHIXCAAAAAEAEACmOQAAAAD1DxwAAAAAAQAAkg4AA4I5AAA+SAAAAQAAABYAAAABAGIA DwDoA5AOAAABAOkDKAAAAIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAA AAEPAPIDIAIAAC8AyA8MAAAAMADSDwQAAAAAAAAADwDVB3wBAAAAALcPRAAAAFQAaQBtAGUA cwAgAE4AZQB3ACAAUgBvAG0AYQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJ CjAAAAYSEAC3D0QAAABBAHIAaQBhAGwAIABCAGwAYQBjAGsAAABtAGEAbgAAAAy2YgAMtmIA NLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAGIiAAtw9EAAAAVABhAGgAbwBtAGEAAABsAGEA YwBrAAAAbQBhAG4AAAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABiIwALcP RAAAAE0AbwBuAG8AdAB5AHAAZQAgAFMAbwByAHQAcwAAAAAADLZiAAy2YgA0tGIABIkKMFi0 YgAIAAAAWLRiAIqJCjACAAYCQAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkA AAAKAAAACwAAAAwAAAANAAAA/v////7///////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////7/AAAEAAIA AAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss +a7EAgAAgAIAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAAtAAAAAYAAAC8AAAA BwAAAMQAAAAIAAAAzAAAAAkAAADUAAAACgAAANwAAAAXAAAA5AAAAAsAAADsAAAAEAAAAPQA AAATAAAA/AAAABYAAAAEAQAADQAAAAwBAAAMAAAAHwIAAAIAAADkBAAAHgAAAA8AAABPbi1z Y3JlZW4gU2hvdwAAHgAAAAIAAAAgAC1zAwAAAD5XAAADAAAAMAAAAAMAAAAFAAAAAwAAAAAA AAADAAAAAAAAAAMAAAAAAAAAAwAAALMNCAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAALAAAA AAAAAB4QAAALAAAAEAAAAFRpbWVzIE5ldyBSb21hbgAMAAAAQXJpYWwgQmxhY2sABwAAAFRh aG9tYQAPAAAATW9ub3R5cGUgU29ydHMABgAAAEFyaWFsABoAAABDb250ZW1wb3JhcnkgUG9y dHJhaXQucG90ACcAAABTSVAgQXV0aGVudGljYXRpb24gdXNpbmcgQ0hBUC1QYXNzd29yZAAX AAAAUHJvYmxlbSBhbmQgT2JqZWN0aXZlcwAbAAAAQ29tcGFyaXNvbiBvZiBoYXNoIGZvcm1h dHMALQAAAFNJUCBVc2VyIEF1dGhlbnRpY2F0aW9uIHVzaW5nIFJhZGl1cyBiYWNrZW5kAAcA AABGdXR1cmUADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQAAwAAAAUAAAAeAAAAEAAAAERl c2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAAAAU2xpZGUgVGl0bGVzAAMAAAAFAAAAAJgA AAADAAAAAAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAAX1BJRF9HVUlEAAIA AADkBAAAQQAAAE4AAAB7ADEAMwA1AEQAQwA5AEEAMAAtAEMAOQBFAEUALQAxADEARAA0AC0A OABCAEUARQAtADQANAA0ADUANQAzADUANAAwADAAMAAwAH0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2DyIAAAAUAAAAX8CR4xpXAAAKAPQDAwAAAE1l ZHNjaG9sYXIIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --------------C01569BE03E8D00BE28611F5 Content-Type: application/ppt; name="SipHideRoute.ppt" Content-Disposition: inline; filename="SipHideRoute.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAAQAAAAAA AAAAEAAAAgAAAAEAAAD+////AAAAAAAAAAB+AAAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ///////////////////////////////////9////MgAAAP7///8EAAAABQAAAAYAAAAHAAAA CAAAAAkAAABlAAAACwAAAAwAAAANAAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUA AAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAA IwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoAAAArAAAALAAAAC0AAAAuAAAALwAAADAA AAAxAAAAZwAAAP7///80AAAANQAAADYAAAA3AAAAOAAAADkAAAA6AAAAOwAAADwAAAA9AAAA PgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAARwAAAEgAAABJAAAASgAAAEsA AABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABVAAAAVgAAAFcAAABYAAAA WQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMAAABkAAAA/v///2YA AAD+////aAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAAAHIAAABzAAAA dAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH8AAAD9////gAAAAFIA bwBvAHQAIABFAG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAWAAUA//////////8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAAAR 8WtFYsABAwAAAMAQAAAAAAAAUABpAGMAdAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgH/////BQAAAP////8AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADw0AAAAAAABQAG8AdwBlAHIAUABvAGkA bgB0ACAARABvAGMAdQBtAGUAbgB0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAf// //8EAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAABdjQAA AAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAoAAIBAQAAAAIAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAMwAAAMRjAAAAAAAAAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgA AAAJAAAACgAAAAsAAAAMAAAADQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAA FgAAABcAAAAYAAAAGQAAABoAAAAbAAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMA AAAkAAAAJQAAACYAAAAnAAAAKAAAACkAAAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAA MQAAADIAAAAzAAAANAAAAP7///82AAAANwAAADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4A AAA/AAAAQAAAAEEAAAD+/////v////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////8Qbh7w Bw0AAA8Ye9AfA9+h7neS6NeZ0IER7sQXyb8oYT6I38Mr+A4s/4lQTkcNChoKAAAADUlIRFIA AAGQAAAAMAgDAAAACArcpAAAAANzQklUBQUFGCbeQwAAAGBQTFRFwMDA9+fe997O/+/W/7UY 97Uh/70Y57Uh/84598Yp3q0Y/++1/9ZK/9Y5984x3rUh//fW/+d7/95a/95S/++l/++c/+dr /++U/+dj//e9///nAAAAAAAAAAAAAAAAAAAA4EtW2gAAAAF0Uk5TAEDm2GYAAAABYktHRP+l B/LFAAAMGElEQVR4nO2aiYKiSBKG3VnJQyFtQAH7/R90448jMzmqprq7uqd21wC5RIX4Mk45 nV7ykpe85CUveckni/unL+C/Vz5Pde5Tv+0lvyzumMb/AaPz+TO+xcXtARnjnetkP7538od/ 5X+Fh95IdTt/4M7kJ4Ys+zOmvp/yJAt+vSW//5o/T0KodlI6OmXF4OfG2lapQ5u6rmuHDpK6 dtSpteUwFiDLJBKmIJJUImZapFB2ky7ooEkb2i9nIF13vF2J3EV1ILJ/cBUQVwfMM/msjzit 5/Xa9wuN3/khB+79tAwdKYw4iLQ6MwtlQiBM0akJNPus5pSJKA87kAHtgHw1n0WDkSh0PGFX DtKtrc4SIqmLp85cOJg43IxzPJhJU/TqquG7Gfv3anvi5VDLONJh4jGMKwGDDrrrRELHSi6K 19EfRM0pQhqeYpNsSgQNU8R2jAYHB6Jz7oswgT10basgcKe0EbBJHiDBYREDeiulbsTZYMcT Rirup1O1BNqCb8GblT7JodDYv4s8WGYIvDqpflnM7wiPcVlwFN8iw7erJe8FD5V7TE18U3AS 1A0AyQcfwCMwgxolTfEjPNwuQv5sDvGOLNAJCW3CK4hL6Eao3V5tyy8sx641HB2AkKcng8ku oAsYyKTj1fAeZAFfP/fTgz1+PzMP+vFh0V/dyMi/AwZtKDSEQRQcWMMEfNxOxgOjv/F0Ai3w BhPi7caLEA0cdP+8hTygEaAYhAiRmcxJd2NoMxChoWvejy1808i7HHRh/+xHppGUjNE+boWB yO8QDqCYsAXntObQ6jXQz5UAXAY8FjQ72YRmo/OsZFY53nCRMeWTBJHHrq+/ho0LND2DimYt G0WpR/6tMHhwTrJUC1nUhZOiJWsRFwLN8HEasR3UyiMXxqD2RBxo5EZEEPIFMAH6KBvFMGZV a+4jU6oTociunB26iR6MUb38zgs1gsIW0TuesWAGUL3nr/Bx92E76MvnG1lbyM8Tu192w0yl MIldrKjF48z7h+SuLIRKBWRQr69HaKcDEObUtaxnQAgaLXC9bBpsS1149JMB0VOFRxtqJBqN A/NQGBu1p81ag3RsYrYMGfACgwOF80nZZtDHcaVRT6fGxvbjXHNq7FMS7cM48oW3Lfw5JYEG QKQCgtuljSG9VRf8PZCpEs3iiYZuLOpQlkoGzEOBJrmPeBahQZjCPFMAWeiNYFMJRMSrTS6m EF2wjCgPSefSyijUSA406oE16GJddXCw9klnvG63G157ufACywv7qzoxaCx31pyYfCgyjX4y 7bHbrbU5zwc6/iHhiLEsxmInyxrIwK9h2fAozp+1DpVTQbEgSIdMQXMA5cIWEteewRxWiqsR ypvkGzSeB4nwFYayeaP8ybe0rOTmbzd/05VtvS055LCB5a9n+/GD9yj2kTnTMcoAJ6n6hwH5 I9JGKJVzxwdqqfv9b/Qvcr1eKfHk7GaZ3mShNrMyjbpOGDRrajMOyblEbRRCFovOo8boNmdl bEVh46nFbRkbXhpfsTxYGi/F5MJexBiJC02keA/VYy0ceGYsbA6CqwjjatREzs25gXCSUEWg RP5NUnv+NXQKdGS2VnIty9xTqkQJPnL8DwGhs5FtSv5vvmrZTMZk46mWAmRQIhlJie/87eEw i91Kt3oZMthWy4kuZgFgXi+r/kYzpiCQeI9Q4EAgS6EpeBjNjdY6s6ws6ECcbxwFpMbRq7Gy sobCtiM8xiH3EEYtoySDFDbLR4A8yUK4HkOjoiZyYCBCSrPhOpQUzzVo4C5Y2r6FZcNnyZW+ SaMYT8w8StXD8YhtAkzgrpBHSGIwWF3TMpQgYffG5gFScF/tjZkIChw5Fj5BXrd4uVz8ZS3+ QogopXbIrBt2aI2LTjbqsKPW3aCDg0scJLdXHWf9s87q2PN8kr+aS1r1ntNiHIeRfdXmyDof UUk+Zs7a6KS2rVzae1ZSF/5d9m4tg2i5IuR3wq6sYWMyDLAR34qSt1K3V/Jmzgyw4en4ZSf+ IkbjwMIhC6O8NxoWI9JkJGw9q0QASdJSxWMeyajTBAraFtywKEp+L4ZMWioWy1hyBNE0uHJa Gh6YNZMaco2e50MkQRTfWgNgqD52KPhZ6D3VuvfrtV+h8UE0JV1IAUMMGj7q8T00pRqEwDCL 8Tejw1I1AmLuG2fg4lYNyKLBvye9k+5ZM9fncxLroHj+fGL9mPs3UawjSLaKVQQZa9PIquTB DrMarSocy+nWPNlN4+61l839FqV71ra6HR3/QXpVWVccipu6H69cIq+o9OCuYzqze3JYqAgQ oCg0VjiyZeSrk37nKgGkvJNg9NK+m2l1Jwan79//9f0biwLpV55oFSOqzLYNw1qKxtraPDpz PiGwliVAjO2Rdjkk2kdDLuGPXUx1o1ZThpJmlY7j9iMKhIyAEiZKkBpdlQawbeE92RZdO3FP 8E5cdMqESCK9gAKkNChDqq8/30+7Ml6VB793+v6NeTy/TW+BMGuoaw3SW6hC+ApIHcsBY+g6 4ZmJsNUeAMkfDJbPdtu72WqXFZ7fzz3fckSIQO2hqYSVbblSoZGJWCEoC9Y9Q/EKA5teVtHl jqbMyZdr88EGy0EMqyw6C1Ug7LEk5d1zmAqQKXfBmUe7aBantCzREnISTDSsaOo35kPmr+TN zLIyKwverNJxQKuCKrHIma8sSg0Cx9wFbtqEjktxeP6G1hj8OgfbEHswm6iAMCejVMwFPBpp +MJv8Y53CN7MwiZuk+F99m/nRhrJHPvP3q+V/yaa8hcs0Xhe+V8JbX0fSS/FyBqUoBA0VpYs zGPY/jldh40cKmQeq7gxGLASlSyNZgAl/WXLZwNhAl4GfxD1c6YpCJq8+jkBAzDhlWVUnO06 d5YdSXv5LdT1YkNOWvdS5jvmBQvS3n7iCC/RrvCqMl/Uh2Ir03TQOelzxrtJeAkAGi5DATBL jTlvgYxj9a1V5M6gCgflNMhRPaUVyzjwYrRq1DkAxK9o/wgIU7icaXU+ny9nWWCbFjSJzp0X vZewbm7VuyR8mFl++9hI9jUiBXf4sevqKIV8PniVLJmW/Cd3bwt9eiPjmCscD3QBHsgj+jXm Jdc1aAIPY44eFvY+InxfxEDGmWzARD5kE/EtBGIMZ55kBQgX46FLAkLeq3HZREr5UWdZ9eiR jTo2at9HgucBkB+Q7SMyqPev9408pMUmyR07R65I9CO5IbAYEC3rtBsS1lde7mxHzDMOL36r psGQGv7n3I4bB/lPPebIgVEM1Zcz0L46e6NxMSq6cy4Gkwk1uWSvpR49GylAKM8cfwnIG7IB cn9UCI+wghVcnl6zDCnNHeqqnltZ9E6bu4lrHPDGFQcpP4JSsAVnupas6RMOkclEJUVaZRyE 52xyqa1it1W/K/7LxR2SPZ0VEb2h38HjhGcVBMbHzv+L7aYfcEGPwNneYNXMqohfuPWiQOi0 YbR6BW3cxqyotgw2Dn4SKGDRqFcLeMwksWNTJsPCn01wV+etbNVe7KNeXypDKXIIRv1ZJiKj Lf0yj23nUvfJbV0/SiPL9f7QB05ApEdv1BLhR29PPSCFsNC0cFkj9zOqeTUCpMTTKJ1YbosE BaI/OOMxgXFY8FXSMxcgsBF/pmsA7rRTcOWyVoZSO7F6IgfoNIbDK0l3MU2ljlIodLPxNzyo wiKB5MOny7iw8/s+0Ic50LDDovDDKQIDmUKVtdFdyN3AtenItzrRkOifixJH1j/bTyO5vxGP 4S1AOoxyIehYzGi0LgpEY/t5bxa7nb2BwEbgE5NqHfUB56x6D8Yj0M/vnqH4QtL37XxHKoAd IjIBCxuQzHwXYwqSAdD9bAr4eEqcUNDH7vP9h/9GZZNs6yPoK8F0qSJG4X+keGa2YYKMDekC AhZHpmlppik/SjxX6ejjSz9GDGXmHW6yzdwWTelEOqb0WbIyGnFMBA9NpvIQAaXuVy50T1Vm /ssiPN7x85rzOvuXGZlFkGPB+mVx66tCECKPz7nIPyL4f/kxX/963smdPLUDKmkyeLz72T9/ l409oBqrP0HwLAQF2P4eG310Vf+yMp9LKc0fv9KfFipJV/tf2rY3koHgsdn6usmK/306pZxm jR/6a/clL3nJS17ykpe85CUveclLPl3+A8OGx0bKklwyAAAAAElFTkSuQmCCAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAA AAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cIACss+a6cAgAA WAIAABAAAAABAAAAiAAAAAMAAACQAAAADwAAAKgAAAAEAAAAtAAAAAYAAAC8AAAABwAAAMQA AAAIAAAAzAAAAAkAAADUAAAACgAAANwAAAAXAAAA5AAAAAsAAADsAAAAEAAAAPQAAAATAAAA /AAAABYAAAAEAQAADQAAAA8A6AOADwAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoA AAAAAAAAAAAAAAEAAAAAAAABDwDyAyACAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1Qd8AQAA AAC3D0QAAABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAAy2YgAMtmIANLRiAASJ CjBYtGIACAAAAFi0YgCKiQowAAAGEhAAtw9EAAAAQQByAGkAYQBsACAAQgBsAGEAYwBrAAAA bQBhAG4AAAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABiIgALcPRAAAAFQA YQBoAG8AbQBhAAAAbABhAGMAawAAAG0AYQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAA WLRiAIqJCjAAAAYiMAC3D0QAAABNAG8AbgBvAHQAeQBwAGUAIABTAG8AcgB0AHMAAAAAAAy2 YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAgAGAkAAtw9EAAAAQQByAGkAYQBsAAAA cABlACAAUwBvAHIAdABzAAAAAAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAA BiIAAKkPCgAAAAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAA AAAAAEACAAAAAAIAAAD//+8AAAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEAC QAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAADwALBLgCAAAPAADwsAIAAAAABvCAAQAA AsAAAC8AAABbAAAABgAAAAAAAAAHAAAAAgAAAAYAAAAAAAAAlgAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAUAAABFAAAAAAAAAAQAAAAAAAAA BAAAAAAAAABCAAAAAAAAADYAAAAAAAAABAAAAAAAAAAEAAAABgAAAAQAAAAAAAAABAAAAAAA AAAEAAAAAAAAAD0AAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAA AAAAAAQAAAAAAAAABAAAAAQAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQA AAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAA AgAAAAAAAAAGAAAAAAAAAAsAAAAAAAAACwAAAAEAAAAIAAAAAwAAAAgAAAAAAAAABAAAAAAA AAAEAAAAXwAB8NwAAAACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAA AABeAQIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAF4BAgAH8CQA AAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAXgECAAfwJAAAAAAAAAAAAAAA AAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAABeAWIAB/AkAAAABgYR7sQXyb8oYT6I38Mr+A4s /wAPDQAAAgAAAAAAAAAAAF4BYwAL8CQAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgA CAABAgIAAAhAAB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPOAAAAAAA8wMUAAAAFwAAAAQA AAAAAAAABQAAgAAAAAAAAPMDFAAAABgAAAAEAAAAAAAAAAYAAIAAAAAADwDQBxMBAAAPAPoD ZwAAAAAA/gMDAAAAAAEAAAD9AzQAAAA2AAAAZAAAADYAAABkAAAAZLRiAIqJCjBctGIACAAA AGYSAADACQAA4vz//7L///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAf AP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwAIBDwAAAAAAP0DNAAAAEIAAABkAAAAQgAA AGQAAAAMtmIADLZiAAEAAAAAAAAAZhIAAFwKAAAAAAAAAAAAAAAA//8fAAcEPAAAAAAA/QM0 AAAAIQAAAGQAAAAhAAAAZAAAAAy2YgAMtmIAAQAAAAAAAADEEQAAXAoAAAAAAAAAAAAAAAD/ /z8A2Q8MAAAAAADaDwQAAAAAACUADwDwD+kIAAAAAPMDFAAAAAMAAAAEAAAAAgAAAAABAAAA AAAAAACfDwQAAAAGAAAAAACoDx4AAABTSVAgUmVjb3JkLVJvdXRlL1JvdXRlIEhpZGluZwsA AKoPEgAAAB4AAAAAAAAAAQAAAAEAAAAAABAAnw8EAAAABQAAAAAAqA8yAAAAQnJ5YW4gSi4g Qnllcmx5DURhdmlkIERhaWtlcg1TaGFpbGFuZHJhIEJoYXRuYWdhcg0AAKoPHAAAABYAAAAA AAAAHAAAAAEAAAADAAEAAAABAAAAAAAAAPMDFAAAABAAAAAAAAAAAgAAAA8BAAAAAAAAAACf DwQAAAAAAAAAAACoDxYAAABQcm9ibGVtIGFuZCBPYmplY3RpdmVzEACfDwQAAAABAAAAAACg D1QDAABQAHIAbwBiAGwAZQBtAA0AVgBpAGEALAAgAFIAZQBjAG8AcgBkAC0AUgBvAHUAdABl ACwAIABhAG4AZAAgAFIAbwB1AHQAZQAgAGgAZQBhAGQAZQByAHMAIABsAGUAYQBrACAAcgBv AHUAdABlACAAKABhAG4AZAAgAHQAaAB1AHMAIABsAG8AYwBhAHQAaQBvAG4AKQAgAGkAbgBm AG8AcgBtAGEAdABpAG8AbgAuAA0AVQBzAGUAcgAgAEMAbwBuAGMAZQByAG4AcwANAEEAbgBv AG4AeQBtAGkAdAB5ACwAIABQAHIAaQB2AGEAYwB5ACAAKABwAHIAZQB2AGUAbgB0ACAAaABh AHIAcgBhAHMAcwBtAGUAbgB0ACkADQBTAGUAcgB2AGkAYwBlACAAUAByAG8AdgBpAGQAZQBy ACAAQwBvAG4AYwBlAHIAbgBzAA0AUgBlAHMAdAByAGkAYwB0ACAAZwBhAHQAaABlAHIAaQBu AGcAIABvAGYAIABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AIABhAGIAbwB1AHQAIABuAGUAdAB3 AG8AcgBrAA0AZQBnAC4AIAByAGUAcwB0AHIAaQBjAHQAIABJAEMATQBQACAAcgBlAHMAcABv AG4AcwBlACAAKABmAG8AcgAgAHQAcgBhAGMAZQByAG8AdQB0AGUAKQANAEEAcABwAHIAbwBh AGMAaAANAEIAaQBkAGkAcgBlAGMAdABpAG8AbgBhAGwAIABwAHIAbwB0AGUAYwB0AGkAbwBu ACAAbwBmACAAcgBvAHUAdABlACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuAA0ARQBhAGMAaAAg AHAAcgBvAHgAeQAgAGkAcwAgAHIAZQBzAHAAbwBuAHMAaQBiAGwAZQAgAGYAbwByACAAZQBu AGMAcgB5AHAAdABpAG4AZwAgAHIAbwB1AHQAZQAgAGkAbgBmAG8AcgBtAGEAdABpAG8AbgAg AGEAYgBvAHUAdAAgABwgcAByAGUAdgBpAG8AdQBzACAAaABvAHAAHSAuAA0ARQBhAGMAaAAg AHAAcgBvAHgAeQAgAGgAYQBzACAAcwB5AG0AbQBlAHQAcgBpAGMAIABrAGUAeQAAAKEP7AAA AAgAAAAAAAAAAABRAAAAAQAAAAAADgAAAAAAAAAAACkAAAABAAAAAAAaAAAAAAAAAAAAMAAA AAEAAAAAACwAAAACAAAAAAAJAAAAAAAAAAAAnAAAAAEAAAAAAAcAAAAAAAIAGAABAAAAAAAA AFEAAAAAAAIAFAANAAAAAAACABgAAQAAAAAAAAAWAAAAAAACABQAEgAAAAAAAgASAAEAAAAA AAAAGQAAAAAAAgAYAAEAAAAAAAIAHAAwAAAAAAACABIALAAAAAAAAgAQAAkAAAAAAAIAGAAN AAAAAQACAIEAFACPAAAAAAACABQAAACqD1AAAACCAAAAAAAAAAwAAAABAAAAAwBLAAAAAAAA AAMAAAABAAAAAwAdAAAAAAAAAAsAAAABAAAAAwALAAAAAAAAAA0AAAABAAAAAwCPAAAAAAAA AAAA8wMUAAAACgAAAAQAAAACAAAABQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPGgAAAFJlY29y ZC1Sb3V0ZSBoZWFkZXIgaGlkaW5nEACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAAAAAAAADz AxQAAAANAAAAAAAAAAIAAAALAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8XAAAAQWx0ZXJuYXRp dmVzIGFuZCBGdXR1cmUQAJ8PBAAAAAEAAAAAAKAPsAEAAEEAbAB0AGUAcgBuAGEAdABpAHYA ZQA6ACAAUABsAGEAYwBlACAAcgBvAHUAdABlACAAaQBuAGYAbwAgAGkAbgAgAFMAdABhAHQA ZQAgAGgAZAByAC4ADQBJAG4AdABlAHIAbwBwAGUAcgBhAGIAaQBsAGkAdAB5ACAAcAByAG8A YgBsAGUAbQAgAHcAaQB0AGgAIABVAEEAcwAgAHQAaABhAHQAIABkAG8AbgAZIHQAIABzAHUA cABwAG8AcgB0ACAAUwB0AGEAdABlACAAaABlAGEAZABlAHIALgANAFAAcgBvAHAAbwBzAGUA ZAAgAG4AZQB4AHQAIABzAHQAZQBwAHMADQBTAEkAUAAgAFcARwAgAGkAdABlAG0ADQBQAGwA YQBjAGUAIABWAGkAYQAgAGgAZQBhAGQAZQByACAAaABpAGQAaQBuAGcAIABhAG4AZAAgAFIA ZQBjAG8AcgBkAC0AUgBvAHUAdABlAC8AUgBvAHUAdABlACAAaABpAGQAaQBuAGcAIABpAG4A dABvACAAcwB0AGEAbgBkAGEAbABvAG4AZQAgAEkALQBEAAAAoQ9uAAAALAAAAAAAAAAAAEMA AAABAAAAAAAUAAAAAAAAAAAAVgAAAAEAAAAAACEAAAAAAAAABQAAAAEAAACBAAYAAAAAAAAA QgAAAAAAAgAYAAEAAAAAAAAAFAAAAAAAAABVAAAAAAACABgAAQAAAAAAAAAAAKoPLAAAACYA AAAAAAAABAAAAAEAAAADAB8AAAAAAAAABAAAAAEAAAADAIwAAAAAAAAAAADqAwAAAAAPAPgD qQkAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAAAAAYADwByAAAAAAAAAA///MAF5X TgD/zAAAzJkAAP9mAAD/AAAA///MAGAA8AcgAAAA////AAAAAABeV04AAAAAAP9mAAD/zAAA mWYzAICAAABgAPAHIAAAAP///wAAAAAAOTk5AAAAAADLy8sAhoaGAE1NTQDq6uoAYADwByAA AAD///8AAAAAAF5XTgCAAAAA/2YAAP/MAAD/AAAA///MAGAA8AcgAAAA////AAAAZgAAAAAA AAD/AABm/wAzzMwA/wD/AJkz/wBgAPAHIAAAAAAAZgD///8AAAAAAP/MAAAAZv8AM8zMAP8A /wCZM/8AYADwByAAAACAAAAA///MAF5XTgD/zAAAzJkAAP9mAAD/AAAA///MAAAAow8+AAAA AQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wCAAAEA//////// KAAAAAADAAAQAKMPgAAAAAUA//0/AAcAegADAGQAAAAABQAAZAAUAAAA2AAAAEACAAAAAAIA AAD//+8AgAACAP///////yAAAAAAAQAAgAUAAHkA1AEgAQAAAgAcAIAFAAB4ANACQAIAAAIA GACSBQAABQAiIAAA8ANgAwAAAgAUAIAFAAATIBAFgAQAAAAAIACjD24AAAAFAP/9PwAAACIg AABkAAAAAAAAAGQAHgAAAAAAAABAAgAAAAACAAAA///vAIAAAAD///////8MAAAAAAEAAAAF AAAgASABAAAAAAAFAABAAkACAAAAAAAFAABgA2ADAAAAAAAFAACABIAEAAAAAEAAow9uAAAA BQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA//////// GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAA AABQAKMPUgAAAAUAAAABAQAABgAAAAAAAQABAAEAAQkAAAYAAQAgAQAAAAACAAEJAAAGAAEA QAIAAAAAAwABCQAABAABAGADAAAAAAQAAQkAAAQAAQCABAAAAABgAKMPDAAAAAEAAAAAAAAA AAAAAHAAow8+AAAABQAAAAAAAAAAAAIAHAABAAAAAAAAAAIAGAACAAAAAAAAAAIAFAADAAAA AAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAACABgAAQAAAAAAAAACABQA AgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBFMFAAAPAALwSwUAABAA CPAIAAAABwAAAAesAAAPAAPw0QQAAA8ABPAoAAAAAQAJ8BAAAACwHbIBwB2yAQAAAAAAAAAA AgAK8AgAAAAArAAABQAAAA8ABPDGAAAAEgAK8AgAAAACrAAAAAoAAHMAC/AqAAAAfwABAAEA gABUo+IAhwACAAAAgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAACQAAABIBRgAw8A EfAQAAAAAADDCwgAAAAAAAAAAQDiAA8ADfBUAAAAAACfDwQAAAAAAAAAAACoDyAAAABDbGlj ayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACqDwoAAAAhAAAA AQAAAAAADwAE8AoBAAASAArwCAAAAAOsAAAACgAAYwAL8CQAAAB/AAEAAQCAADSZ4gCBAQQA AAi/AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAKQEIAFAFegODwAR8BAAAAAAAMMLCAAAAAEA AAACAOIADwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFzdGVy IHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlm dGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8KAAAA UwAAAAEAAAAAAA8ABPC3AAAAEgAK8AgAAAAErAAAAAoAAHMAC/AqAAAAfwABAAEAgADUmOIA hwACAAAAgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAABUDxABwAV0EA8AEfAQAAAA AADDCwgAAAACAAAABwHiAA8ADfBFAAAAAACfDwQAAAAEAAAAAACoDwEAAAAqAAChDxwAAAAC AAAAAAAAIAAAMgACAAAAAAAHAAQADgAAAAACAAD4DwQAAAAAAAAADwAE8LkAAAASAArwCAAA AAWsAAAACgAAcwAL8CoAAAB/AAEAAQCAAJSc4gCHAAIAAACBAQQAAAi/AQEAEQDAAQEAAAj/ AQEACQAAABDwCAAAAFQPsAfQDnQQDwAR8BAAAAAAAMMLCAAAAAMAAAAJAuIADwAN8EcAAAAA AJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPHgAAAAIAAAAAAAAoAAABADIAAgAAAAAABwAEAA4A AAAAAgAA+g8EAAAAAAAAAA8ABPC5AAAAEgAK8AgAAAAGrAAAAAoAAHMAC/AqAAAAfwABAAEA gACUmeIAhwACAAAAgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAABUD5AQQBV0EA8A EfAQAAAAAADDCwgAAAAEAAAACALiAA8ADfBHAAAAAACfDwQAAAAEAAAAAACoDwEAAAAqAACh Dx4AAAACAAAAAAAAKAAAAgAyAAIAAAAAAAcABAAOAAAAAAIAANgPBAAAAAAAAAAPAATweAAA ALIECvAIAAAAB6wAAAAKAACTAAvwUAAAAH8AgACAAARBBQAAAAXBGgAAAAYBAQAAAAcBwMDA AIEBBAAACL8BAAAQAMABAQAACP8BAAAIAEEAOgBcAHAAYQBpAG4AdAAuAEcASQBGAAAAAAAQ 8AgAAAA8A0ACgBYuBA8ABPBaAAAAEgAK8AgAAAABrAAAAAwAALMAC/BCAAAAgQEAAAAIkwGO n4sAlAHevWgAvwEeAB8A/wEAAAgAAQIAAAACBQKoKQEABgKoKQEAPwIDAAMABAMJAAAAPwMB AAEAEADwByAAAAD///8AAAAAAF5XTgAAAAAA/2YAAP/MAACZZjMAgIAAACAAug8yAAAAQwBv AG4AdABlAG0AcABvAHIAYQByAHkAIABQAG8AcgB0AHIAYQBpAHQALgBwAG8AdAAPAO4DXAUA AAIA7wMYAAAAAgAAAAMEBwkIAAAABQAAgAAAAAAAAAAADwAMBAwFAAAPAALwBAUAADAACPAI AAAABwAAAAewAAAPAAPwigQAAA8ABPAoAAAAAQAJ8BAAAAAAAAAABEOIAQYAAABACAAAAgAK 8AgAAAAAsAAABQAAAA8ABPDGAAAAEgAK8AgAAAACsAAAAAoAAHMAC/AqAAAAfwABAAEAgAAU nuIAhwACAAAAgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAACwAUACQBWABA8AEfAQ AAAAAADDCwgAAAAAAAAAAwDiAA8ADfBUAAAAAACfDwQAAAAGAAAAAACoDyAAAABDbGljayB0 byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACqDwoAAAAhAAAAAQAA AAAADwAE8MMAAAASAArwCAAAAAOwAAAACgAAYwAL8CQAAAB/AAEAAQCAADSi4gCBAQQAAAi/ AQEAEQDAAQEAAAj/AQEACQAAABDwCAAAAJAJQAUAFewNDwAR8BAAAAAAAMMLCAAAAAEAAAAE AOIADwAN8FcAAAAAAJ8PBAAAAAUAAAAAAKgPIwAAAENsaWNrIHRvIGVkaXQgTWFzdGVyIHN1 YnRpdGxlIHN0eWxlAACiDwYAAAAkAAAAAAAAAKoPCgAAACQAAAABAAAAAAAPAATwtwAAABIA CvAIAAAABLAAAAAKAABzAAvwKgAAAH8AAQABAIAAdJ7iAIcAAgAAAIEBBAAACL8BAQARAMAB AQAACP8BAQAJAAAAEPAIAAAAVA/AAYAGmBAPABHwEAAAAAAAwwsIAAAAAgAAAAcB5AAPAA3w RQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8cAAAAAgAAAAAAACAAADIAAgAAAAAABwAE AA4AXldO/gAA+A8EAAAAAAAAAA8ABPC5AAAAEgAK8AgAAAAFsAAAAAoAAHMAC/AqAAAAfwAB AAEAgAB0mOIAhwACAAAAgQEEAAAIvwEBABEAwAEBAAAI/wEBAAkAAAAQ8AgAAABUD8AHwA6Y EA8AEfAQAAAAAADDCwgAAAADAAAACQLkAA8ADfBHAAAAAACfDwQAAAAEAAAAAACoDwEAAAAq AAChDx4AAAACAAAAAAAAKAAAAQAyAAIAAAAAAAcABAAOAF5XTv4AAPoPBAAAAAAAAAAPAATw uQAAABIACvAIAAAABrAAAAAKAABzAAvwKgAAAH8AAQABAIAAtKDiAIcAAgAAAIEBBAAACL8B AQARAMABAQAACP8BAQAJAAAAEPAIAAAAVA9AEMAUmBAPABHwEAAAAAAAwwsIAAAABAAAAAgC 5AAPAA3wRwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8eAAAAAgAAAAAAACgAAAIAMgAC AAAAAAAHAAQADgBeV07+AADYDwQAAAAAAAAADwAE8HgAAACyBArwCAAAAAewAAAACgAAkwAL 8FAAAAB/AIAAgAAEQQUAAAAFwRoAAAAGAQEAAAAHAcDAwACBAQQAAAi/AQAAEADAAQEAAAj/ AQAACABBADoAXABwAGEAaQBuAHQALgBHAEkARgAAAAAAEPAIAAAAgARAAoAWcgUPAATwWgAA ABIACvAIAAAAAbAAAAAMAACzAAvwQgAAAIEBAAAACJMBjp+LAJQB3r1oAL8BGgAfAP8BAAAI AAECAAAAAgUCqCkBAAYCqCkBAD8CAwADAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAABe V04AAAAAAP9mAAD/zAAAmWYzAICAAAAPAO4D0gIAAAIA7wMYAAAAAAAAAA8QAAAAAAAABgAA gAAAAAAHAAAADwAMBIICAAAPAALwegIAACAACPAIAAAABAAAAAUIAAAPAAPwEgIAAA8ABPAo AAAAAQAJ8BAAAAAgJQAAvAkAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAAAA8ABPBsAAAAEgAK 8AgAAAACCAAAIAIAAEMAC/AYAAAAgAD0meIAvwEAAAEA/wEAAAEAAQMCsAAAAAAQ8AgAAACg ArAB0BRwBQ8AEfAQAAAAAADDCwgAAAAAAAAADwDkAA8ADfAMAAAAAACeDwQAAAAAAAAADwAE 8GwAAAASAArwCAAAAAMIAAAgAgAAQwAL8BgAAACAABSh4gC/AQAAAQD/AQAAAQABAwOwAAAA ABDwCAAAAAAJMAPwElANDwAR8BAAAAAAAMMLCAAAAAEAAAAQAOQADwAN8AwAAAAAAJ4PBAAA AAEAAAAPAATw8gAAAKIMCvAIAAAABQgAAAAKAACDAAvwMAAAAIAAxBthAb8AAgACAIEBBAAA CIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACAAAEPAIAAAAAAagAoATbQcPAA3wkgAA AAAAnw8EAAAABAAAAAAAqA8iAAAAZHJhZnQtYnllcmx5LXNpcC1oaWRlLXJvdXRlLTAwLnR4 dAAAoQ8gAAAAIwAAAAAAACgAAAEAMgAiAAAAAAACACAAAQAAAAAAAAAAAKoPLAAAAAYAAAAA AAAABgAAAAEAAAADABMAAAAAAAAAAwAAAAEAAAADAAEAAAAAAAAADwAE8EgAAAASAArwCAAA AAEIAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAE AwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwDu A+QBAAACAO8DGAAAAAEAAAANDgAAAAAAAAUAAIAAAAAABwAAAA8ADASUAQAADwAC8IwBAABA AAjwCAAAAAMAAAADcAAADwAD8CQBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAA AAIACvAIAAAAAHAAAAUAAAAPAATwcgAAABIACvAIAAAAAnAAACACAABTAAvwHgAAAIAABBhh Ab8BAAABAP8BAAABAAEDAqwAAIgDAAAAAAAAEPAIAAAAUAGAAaAUMAMPABHwEAAAAAAAwwsI AAAAAAAAAA0A4gAPAA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADcAAAIAIA AFMAC/AeAAAAgABEEWEBvwEAAAEA/wEAAAEAAQMDrAAAiAMAAAAAAAAQ8AgAAAAgBCABoBQg EA8AEfAQAAAAAADDCwgAAAABAAAADgDiAA8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAAS AArwCAAAAAFwAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/AR4AHwD/ AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCy srIADwDuA5woAAACAO8DGAAAAAEAAAANDgAAAAAAAAUAAIAAAAAABwAAAA8ADARMKAAADwAC 8EQoAABQAAjwCAAAAEMAAABEKAAADwAD8NwnAAAPAATwKAAAAAEACfAQAAAAAAAAAKAAAAB4 AAAAAAAAAAIACvAIAAAAACgAAAUAAAAPAATwbAAAABIACvAIAAAAAigAACACAABDAAvwGAAA AIAAZBJhAb8BAAABAP8BAAABAAEDAqwAAAAAEPAIAAAAUAEgAWAVYAMPABHwEAAAAAAAwwsI AAAAAAAAAA0A4gAPAA3wDAAAAAAAng8EAAAAAAAAAA8AA/B5JgAADwAE8EwAAAABAAnwEAAA AKAFAADQCwAAIC4AACAlAAACAArwCAAAAAQoAAABAgAAIwAL8AwAAAB/AAAABACIAwAAAAAA ABDwCAAAAMADAAMzE+ANDwAD8AQCAAAPAATwTgAAAAEACfAQAAAAoAUAAPoOAADgKwAAOiMA AAIACvAIAAAABSgAAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAoAUAAPoOAADgKwAAICUA AA8ABPBOAAAAQgEK8AgAAAAGKAAAAgoAAFMAC/AeAAAARAEEAAAAfwEAAAEAvwEAABAAywFq SgAA/wEQABAAAAAP8BAAAACgBQAA+g4AAKAFAAA6IwAADwAE8E4AAABCAQrwCAAAAAcoAAAC CgAAUwAL8B4AAABEAQQAAAB/AQAAAQC/AQAAEADLAWpKAAD/ARAAEAAAAA/wEAAAAMAYAAD6 DgAAwBgAADojAAAPAATwTgAAAEIBCvAIAAAACCgAAAIKAABTAAvwHgAAAEQBBAAAAH8BAAAB AL8BAAAQAMsBakoAAP8BEAAQAAAAD/AQAAAAMA8AAPoOAAAwDwAAOiMAAA8ABPBOAAAAQgEK 8AgAAAAJKAAAAgoAAFMAC/AeAAAARAEEAAAAfwEAAAEAvwEAABAAywFqSgAA/wEQABAAAAAP 8BAAAADgKwAA+g4AAOArAAA6IwAADwAE8E4AAABCAQrwCAAAAAooAAACCgAAUwAL8B4AAABE AQQAAAB/AQAAAQC/AQAAEADLAWpKAAD/ARAAEAAAAA/wEAAAAFAiAAD6DgAAUCIAADojAAAP AAPwkAkAAA8ABPBOAAAAAQAJ8BAAAACgBQAAig8AAAAtAACgFwAAAgAK8AgAAAALKAAAAwIA ABMAC/AGAAAAiAMAAAAAAAAP8BAAAACgBQAAig8AAAAtAACgFwAADwAD8IoBAAAPAATwTgAA AAEACfAQAAAAoAUAAIoPAAAwDwAAyhEAAAIACvAIAAAADCgAAAMCAAATAAvwBgAAAIgDAAAA AAAAD/AQAAAAoAUAAIoPAAAwDwAAyhEAAA8ABPByAAAAQgEK8AgAAAANKAAAAgoAALMAC/BC AAAAvwAAAAcARAEEAAAAfwEAAAEAvwEAABAAywFqSgAA0QEBAAAA/wEeAB4APwIAAAMAvwIB AA8A/wIWAB8AfwMAAA8AAAAP8BAAAACgBQAAOhEAADAPAAA6EQAADwAE8LIAAACiDArwCAAA AA4oAAACCgAAowAL8DwAAACAAMQVYQGKAA4oAAC/AAAABwC/AQAAEADLAWpKAAD/AQYADgA/ AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAKAFAACKDwAAIAoAAMoRAAAPAA3wPgAA AAAAnw8EAAAABAAAAAAAqA8EAAAAIFJFUQAAoQ8eAAAABQAAAAAAAAAAAAEAAAAAAAIAEgAE AAAAAAACABAADwAD8EoCAAAPAATwTgAAAAEACfAQAAAAMA8AAFAQAABQGQAAYBUAAAIACvAI AAAADygAAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAMA8AAFAQAABQGQAAYBUAAA8ABPBy AAAAQgEK8AgAAAAQKAAAAgoAALMAC/BCAAAAvwAAAAcARAEEAAAAfwEAAAEAvwEAABAAywFq SgAA0QEBAAAA/wEeAB4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAAwDwAAyhEA AMAYAADKEQAADwAE8LgAAACiDArwCAAAABEoAAACCgAAkwAL8DYAAACAAOQWYQG/AAAABwC/ AQwAHgDLAWpKAAD/AQYADgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAADAPAAAA EgAAUBkAAGAVAAAPAA3wSgAAAAAAnw8EAAAABAAAAAAAqA8aAAAAUmVjb3JkLVJvdXRlOiBQ MQ1IaWRlOiBob3AAAKEPFAAAABsAAAAAAAAAAAAbAAAAAAACAAoADwAE8LIAAACiDArwCAAA ABIoAAACCgAAowAL8DwAAACAAEQXYQGKABIoAAC/AAAABwC/AQAAEADLAWpKAAD/AQYADgA/ AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAADAPAABQEAAAsBMAAJASAAAPAA3wPgAA AAAAnw8EAAAABAAAAAAAqA8EAAAAIFJFUQAAoQ8eAAAABQAAAAAAAAAAAAEAAAAAAAIAEgAE AAAAAAACABAADwAD8MICAAAPAATwTgAAAAEACfAQAAAAUCIAAHARAAAALQAAoBcAAAIACvAI AAAAEygAAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAUCIAAHARAAAALQAAoBcAAA8ABPBy AAAAQgEK8AgAAAAUKAAAAgoAALMAC/BCAAAAvwAAAAcARAEEAAAAfwEAAAEAvwEAABAAywFq SgAA0QEBAAAA/wEeAB4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAABQIgAA6hIA AOArAADqEgAADwAE8LIAAACiDArwCAAAABUoAAACCgAAowAL8DwAAACAAIQQYQGKABUoAAC/ AAAABwC/AQAAEADLAWpKAAD/AQYADgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAA AFAiAABwEQAA0CYAALATAAAPAA3wPgAAAAAAnw8EAAAABAAAAAAAqA8EAAAAIFJFUQAAoQ8e AAAABQAAAAAAAAAAAAEAAAAAAAIAEgAEAAAAAAACABAADwAE8DABAACiDArwCAAAABYoAAAC CgAAkwAL8DYAAACAAAQSYQG/AAAABwC/AQwAHgDLAWpKAAD/AQYADgA/AgAAAwC/AgEADwD/ AhYAHwB/AwAADwAAAA/wEAAAAFAiAAAgEwAAAC0AAKAXAAAPAA3wwgAAAAAAnw8EAAAABAAA AAAAqA9iAAAAUmVjb3JkLVJvdXRlOiBQMywNICAgICAgICAgICAgICAgICAgICAgICAgRShQ MixLMyksICAgDSAgICAgICAgICAgICAgICAgICAgICAgIEUoUDEsIEsyKQ1IaWRlOiBob3AA AKEPRAAAAGMAAAAAAAAAAAAqAAAAAAACAAoADQAAAAAABgAKAP8AAP4YAAAAAAACAAoACgAA AAAABgAKAAAA//4KAAAAAAACAAoADwAD8IQCAAAPAATwTgAAAAEACfAQAAAAwBgAAOAQAADg IgAA8BUAAAIACvAIAAAAFygAAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAwBgAAOAQAADg IgAA8BUAAA8ABPByAAAAQgEK8AgAAAAYKAAAAgoAALMAC/BCAAAAvwAAAAcARAEEAAAAfwEA AAEAvwEAABAAywFqSgAA0QEBAAAA/wEeAB4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP 8BAAAADAGAAAWhIAAFAiAABaEgAADwAE8LIAAACiDArwCAAAABkoAAACCgAAowAL8DwAAACA AAQVYQGKABkoAAC/AAAABwC/AQAAEADLAWpKAAD/AQYADgA/AgAAAwC/AgEADwD/AhYAHwB/ AwAADwAAAA/wEAAAAMAYAADgEAAAQB0AACATAAAPAA3wPgAAAAAAnw8EAAAABAAAAAAAqA8E AAAAIFJFUQAAoQ8eAAAABQAAAAAAAAAAAAEAAAAAAAIAEgAEAAAAAAACABAADwAE8PIAAACi DArwCAAAABooAAACCgAAkwAL8DYAAACAACQWYQG/AAAABwC/AQwAHgDLAWpKAAD/AQYADgA/ AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAMAYAACQEgAA4CIAAPAVAAAPAA3whAAA AAAAnw8EAAAABAAAAAAAqA88AAAAUmVjb3JkLVJvdXRlOiBQMiwNICAgICAgICAgICAgICAg ICAgICAgICAgRShQMSxLMikNSGlkZTogaG9wAAChDywAAAA9AAAAAAAAAAAAKgAAAAAAAgAK AAkAAAAAAAYACgAAAP/+CgAAAAAAAgAKAA8ABPCmAAAAogwK8AgAAAAbKAAAAgoAAKMAC/A8 AAAAgACkEWEBvwAAAAcAgQEA/wAAvwEMAB4AywFqSgAA/wEGAA4APwIAAAMAvwIBAA8A/wIW AB8AfwMAAA8AAAAP8BAAAACADQAAgA0AAHARAAAwDwAADwAN8DIAAAAAAJ8PBAAAAAQAAAAA AKgPAgAAAFAxAAChDxQAAAADAAAAAAAAAAAAAwAAAAAAAgAOAA8ABPCmAAAAogwK8AgAAAAc KAAAAgoAAKMAC/A8AAAAgADkEGEBvwAAAAcAgQH//wAAvwEMAB4AywFqSgAA/wEGAA4APwIA AAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAAQFwAAgA0AAAAbAAAwDwAADwAN8DIAAAAA AJ8PBAAAAAQAAAAAAKgPAgAAAFAyAAChDxQAAAADAAAAAAAAAAAAAwAAAAAAAgAOAA8ABPCm AAAAogwK8AgAAAAdKAAAAgoAAKMAC/A8AAAAgAAkEGEBvwAAAAcAgQH/AAAAvwEMAB4AywFq SgAA/wEGAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAAwIQAAgA0AACAlAAAw DwAADwAN8DIAAAAAAJ8PBAAAAAQAAAAAAKgPAgAAAFAzAAChDxQAAAADAAAAAAAAAAAAAwAA AAAAAgAOAA8ABPChAAAAogwK8AgAAAAeKAAAAgoAAJMAC/A2AAAAgABkFWEBvwAAAAcAvwEM AB4AywFqSgAA/wEGAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAAwKgAAgA0A ACAuAAAwDwAADwAN8DMAAAAAAJ8PBAAAAAQAAAAAAKgPAwAAAFVBUwAAoQ8UAAAABAAAAAAA AAAAAAQAAAAAAAIADgAPAAPw3AwAAA8ABPBOAAAAAQAJ8BAAAACgBQAAEBcAAAAtAAAQIAAA AgAK8AgAAAAfKAAAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAACgBQAAEBcAAAAtAAAQIAAA DwAD8B8DAAAPAATwTgAAAAEACfAQAAAAUCIAABAXAAAALQAA0B0AAAIACvAIAAAAICgAAAMC AAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAUCIAABAXAAAALQAA0B0AAA8AA/CKAQAADwAE8E4A AAABAAnwEAAAAFAiAAAQFwAA4CsAAFAZAAACAArwCAAAACEoAAADAgAAEwAL8AYAAACIAwAA AAAAAA/wEAAAAFAiAAAQFwAA4CsAAFAZAAAPAATwcgAAAEIBCvAIAAAAIigAAEIKAACzAAvw QgAAAL8AAAAHAEQBBAAAAH8BAAABAL8BAAAQAMsBakoAANEBAQAAAP8BHgAeAD8CAAADAL8C AQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAUCIAAMAYAADgKwAAwBgAAA8ABPCyAAAAogwK8AgA AAAjKAAAAgoAAKMAC/A8AAAAgACEFmEBigAjKAAAvwAAAAcAvwEAABAAywFqSgAA/wEGAA4A PwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAADgIgAAEBcAAGAnAABQGQAADwAN8D4A AAAAAJ8PBAAAAAQAAAAAAKgPBAAAACBSU1AAAKEPHgAAAAUAAAAAAAAAAAABAAAAAAACABIA BAAAAAAAAgAQAA8ABPAvAQAAogwK8AgAAAAkKAAAAgoAAKMAC/A8AAAAgABkG2EBigAkKAAA vwAAAAcAvwEMAB4AywFqSgAA/wEGAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAA AABQIgAAwBgAAAAtAADQHQAADwAN8LsAAAAAAJ8PBAAAAAQAAAAAAKgPZQAAAFJlY29yZC1S b3V0ZTogUDMsDSAgICAgICAgICAgICAgICAgICAgICAgIEUoUDIsSzMpLCAgIA0gICAgICAg ICAgICAgICAgICAgICAgICBFKFAxLCBLMikNQ29udGFjdDogVUFTAAChDzoAAABmAAAAAAAA AAAAEgAAAAAAAgAKACUAAAAAAAYACgD/AAD+IgAAAAAABgAKAAAA//4NAAAAAAACAAoADwAD 8A8DAAAPAATwTgAAAAEACfAQAAAAwBgAAKAXAABwIwAA8B4AAAIACvAIAAAAJSgAAAMCAAAT AAvwBgAAAIgDAAAAAAAAD/AQAAAAwBgAAKAXAABwIwAA8B4AAA8AA/CKAQAADwAE8E4AAAAB AAnwEAAAAFAiAAAQFwAA4CsAAFAZAAACAArwCAAAACYoAAADAgAAEwAL8AYAAACIAwAAAAAA AA/wEAAAAMAYAACgFwAAUCIAAOAZAAAPAATwcgAAAEIBCvAIAAAAJygAAEIKAACzAAvwQgAA AL8AAAAHAEQBBAAAAH8BAAABAL8BAAAQAMsBakoAANEBAQAAAP8BHgAeAD8CAAADAL8CAQAP AP8CFgAfAH8DAAAPAAAAD/AQAAAAUCIAAMAYAADgKwAAwBgAAA8ABPCyAAAAogwK8AgAAAAo KAAAAgoAAKMAC/A8AAAAgABkgVwBigAoKAAAvwAAAAcAvwEAABAAywFqSgAA/wEGAA4APwIA AAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAADgIgAAEBcAAGAnAABQGQAADwAN8D4AAAAA AJ8PBAAAAAQAAAAAAKgPBAAAACBSU1AAAKEPHgAAAAUAAAAAAAAAAAABAAAAAAACABIABAAA AAAAAgAQAA8ABPAfAQAAogwK8AgAAAApKAAAAgoAAJMAC/A2AAAAgADkiFwBvwAAAAcAvwEM AB4AywFqSgAA/wEGAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAADAGAAAUBkA AHAjAADwHgAADwAN8LEAAAAAAJ8PBAAAAAQAAAAAAKgPaQAAAFJlY29yZC1Sb3V0ZTogUDMs DSAgICAgICAgICAgICAgICAgICAgICAgIFAyLCAgIA0gICAgICAgICAgICAgICAgICAgICAg ICBFKFAxLCBLMikNQ29udGFjdDogVUFTDUhpZGU6IGhvcAAAoQ8sAAAAagAAAAAAAAAAADEA AAAAAAIACgAiAAAAAAAGAAoAAAD//hcAAAAAAAIACgAPAAPwDAMAAA8ABPBOAAAAAQAJ8BAA AAAwDwAAMBgAAOAZAAAQIAAAAgAK8AgAAAAqKAAAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAA AAAwDwAAMBgAAOAZAAAQIAAADwAD8IoBAAAPAATwTgAAAAEACfAQAAAAUCIAABAXAADgKwAA UBkAAAIACvAIAAAAKygAAAMCAAATAAvwBgAAAIgDAAAAAAAAD/AQAAAAMA8AADAYAADAGAAA cBoAAA8ABPByAAAAQgEK8AgAAAAsKAAAQgoAALMAC/BCAAAAvwAAAAcARAEEAAAAfwEAAAEA vwEAABAAywFqSgAA0QEBAAAA/wEeAB4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAA AABQIgAAwBgAAOArAADAGAAADwAE8LIAAACiDArwCAAAAC0oAAACCgAAowAL8DwAAACAAASK XAGKAC0oAAC/AAAABwC/AQAAEADLAWpKAAD/AQYADgA/AgAAAwC/AgEADwD/AhYAHwB/AwAA DwAAAA/wEAAAAOAiAAAQFwAAYCcAAFAZAAAPAA3wPgAAAAAAnw8EAAAABAAAAAAAqA8EAAAA IFJTUAAAoQ8eAAAABQAAAAAAAAAAAAEAAAAAAAIAEgAEAAAAAAACABAADwAE8BwBAACiDArw CAAAAC4oAAACCgAAkwAL8DYAAACAAMSBXAG/AAAABwC/AQwAHgDLAWpKAAD/AQYADgA/AgAA AwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAADAPAADgGQAA4BkAABAgAAAPAA3wrgAAAAAA nw8EAAAABAAAAAAAqA9mAAAAUmVjb3JkLVJvdXRlOiBFKFAzLEsyKSwNICAgICAgICAgICAg ICAgICAgICAgICAgUDIsDSAgICAgICAgICAgICAgICAgICAgICAgIFAxDUNvbnRhY3Q6IFVB Uw1IaWRlOiBob3ANAAChDywAAABnAAAAAAAAAAAADgAAAAAAAgAKAAkAAAAAAAYACgAAAP/+ UAAAAAAAAgAKAA8AA/AsAwAADwAE8E4AAAABAAnwEAAAAKAFAADAGAAAUBAAABAgAAACAArw CAAAAC8oAAADAgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAKAFAADAGAAAUBAAABAgAAAPAAPw igEAAA8ABPBOAAAAAQAJ8BAAAABQIgAAEBcAAOArAABQGQAAAgAK8AgAAAAwKAAAAwIAABMA C/AGAAAAiAMAAAAAAAAP8BAAAACgBQAAwBgAADAPAAAAGwAADwAE8HIAAABCAQrwCAAAADEo AABCCgAAswAL8EIAAAC/AAAABwBEAQQAAAB/AQAAAQC/AQAAEADLAWpKAADRAQEAAAD/AR4A HgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAFAiAADAGAAA4CsAAMAYAAAPAATw sgAAAKIMCvAIAAAAMigAAAIKAACjAAvwPAAAAIAApINcAYoAMigAAL8AAAAHAL8BAAAQAMsB akoAAP8BBgAOAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAA4CIAABAXAABgJwAA UBkAAA8ADfA+AAAAAACfDwQAAAAEAAAAAACoDwQAAAAgUlNQAAChDx4AAAAFAAAAAAAAAAAA AQAAAAAAAgASAAQAAAAAAAIAEAAPAATwPAEAAKIMCvAIAAAAMygAAAIKAACTAAvwNgAAAIAA xH5cAb8AAAAHAL8BDAAeAMsBakoAAP8BBgAOAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAA D/AQAAAAoAUAAHAaAABQEAAAECAAAA8ADfDOAAAAAACfDwQAAAAEAAAAAACoD24AAABSZWNv cmQtUm91dGU6IEUoUDMsSzIpLA0gICAgICAgICAgICAgICAgICAgICAgICBFKFAyLEsxKSwg ICANICAgICAgICAgICAgICAgICAgICAgICAgUDENQ29udGFjdDogVUFTDUhpZGU6IGhvcAAA oQ9EAAAAbwAAAAAAAAAAAA4AAAAAAAIACgAJAAAAAAAGAAoAAAD//hkAAAAAAAIACgANAAAA AAAGAAoAAP8A/jIAAAAAAAIACgAPAAPwkAEAAA8ABPBUAAAAAQAJ8BAAAACgBQAAig8AADAP AADKEQAAAgAK8AgAAAA0KAAAAwIAACMAC/AMAAAABAAAAAAAiAMAAAAAAAAP8BAAAACgBQAA gB8AADAPAADAIQAADwAE8HIAAABCAQrwCAAAADUoAAACCgAAswAL8EIAAAC/AAAABwBEAQQA AAB/AQAAAQC/AQAAEADLAWpKAADRAQEAAAD/AR4AHgA/AgAAAwC/AgEADwD/AhYAHwB/AwAA DwAAAA/wEAAAAKAFAAA6EQAAMA8AADoRAAAPAATwsgAAAKIMCvAIAAAANigAAAIKAACjAAvw PAAAAIAAhIJcAYoANigAAL8AAAAHAL8BAAAQAMsBakoAAP8BBgAOAD8CAAADAL8CAQAPAP8C FgAfAH8DAAAPAAAAD/AQAAAAoAUAAIoPAAAgCgAAyhEAAA8ADfA+AAAAAACfDwQAAAAEAAAA AACoDwQAAAAgUkVRAAChDx4AAAAFAAAAAAAAAAAAAQAAAAAAAgASAAQAAAAAAAIAEAAPAATw cgAAAEIBCvAIAAAANygAAAIKAACzAAvwQgAAAL8AAAAHAEQBBAAAAH8BAAABAL8BAAAQAMsB akoAANEBAQAAAP8BHgAeAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAMA8AAMAh AADAGAAAwCEAAA8ABPCyAAAAogwK8AgAAAA4KAAAAgoAAKMAC/A8AAAAgACEiFwBigA4KAAA vwAAAAcAvwEAABAAywFqSgAA/wEGAA4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAA AAAwDwAARiAAALATAACGIgAADwAN8D4AAAAAAJ8PBAAAAAQAAAAAAKgPBAAAACBSRVEAAKEP HgAAAAUAAAAAAAAAAAABAAAAAAACABIABAAAAAAAAgAQAA8ABPByAAAAQgEK8AgAAAA5KAAA AgoAALMAC/BCAAAAvwAAAAcARAEEAAAAfwEAAAEAvwEAABAAywFqSgAA0QEBAAAA/wEeAB4A PwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAABQIgAA4CIAAOArAADgIgAADwAE8LIA AACiDArwCAAAADooAAACCgAAowAL8DwAAACAAOR/XAGKADooAAC/AAAABwC/AQAAEADLAWpK AAD/AQYADgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAFAiAABmIQAA0CYAAKYj AAAPAA3wPgAAAAAAnw8EAAAABAAAAAAAqA8EAAAAIFJFUQAAoQ8eAAAABQAAAAAAAAAAAAEA AAAAAAIAEgAEAAAAAAACABAADwAE8HIAAABCAQrwCAAAADsoAAACCgAAswAL8EIAAAC/AAAA BwBEAQQAAAB/AQAAAQC/AQAAEADLAWpKAADRAQEAAAD/AR4AHgA/AgAAAwC/AgEADwD/AhYA HwB/AwAADwAAAA/wEAAAAMAYAABQIgAAUCIAAFAiAAAPAATwsgAAAKIMCvAIAAAAPCgAAAIK AACjAAvwPAAAAIAARIBcAYoAPCgAAL8AAAAHAL8BAAAQAMsBakoAAP8BBgAOAD8CAAADAL8C AQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAwBgAANYgAABAHQAAFiMAAA8ADfA+AAAAAACfDwQA AAAEAAAAAACoDwQAAAAgUkVRAAChDx4AAAAFAAAAAAAAAAAAAQAAAAAAAgASAAQAAAAAAAIA EAAPAATwBwEAAKIMCvAIAAAAPSgAAAIKAACTAAvwNgAAAIAApIZcAb8AAAAHAL8BDAAeAMsB akoAAP8BBgAOAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAoAUAADAhAADADwAA ICUAAA8ADfCZAAAAAACfDwQAAAAEAAAAAACoDzkAAABSb3V0ZTogRShQMiwgSzEpLA0gICAg ICAgICAgICBFKFAzLEsyKSwNICAgICAgICAgICAgVUFTDQ0AAKEPRAAAADoAAAAAAAAAAAAH AAAAAAACAAoACgAAAAAABgAKAAD/AP4NAAAAAAACAAoACgAAAAAABgAKAAAA//4SAAAAAAAC AAoADwAE8NgAAACiDArwCAAAAD4oAAACCgAAkwAL8DYAAACAAESDXAG/AAAABwC/AQwAHgDL AWpKAAD/AQYADgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAADAPAADAIQAAUBkA ACAlAAAPAA3wagAAAAAAnw8EAAAABAAAAAAAqA8iAAAAUm91dGU6IEUoUDMsSzIpLA0gICAg ICAgICAgICBVQVMNDQAAoQ8sAAAAIwAAAAAAAAAAAAcAAAAAAAIACgAJAAAAAAAGAAoAAAD/ /hMAAAAAAAIACgAPAATwqgAAAKIMCvAIAAAAPygAAAIKAACTAAvwNgAAAIAAxIdcAb8AAAAH AL8BDAAeAMsBakoAAP8BBgAOAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAwBgA AFAiAADgIgAAICUAAA8ADfA8AAAAAACfDwQAAAAEAAAAAACoDwwAAABSb3V0ZTogVUFTDQ0A AKEPFAAAAA0AAAAAAAAAAAANAAAAAAACAAoADwAE8LIAAACiDArwCAAAAEAoAAACCgAAkwAL 8DYAAACAAOSCXAG/AAAABwC/AQwAHgDLAWpKAAD/AQYADgA/AgAAAwC/AgEADwD/AhYAHwB/ AwAADwAAAA/wEAAAAFAiAADgIgAAcCwAACAlAAAPAA3wRAAAAAAAnw8EAAAABAAAAAAAqA8C AAAADQ0AAKEPFAAAAAMAAAAAAAAAAAADAAAAAAACAAoAAACqDwoAAAADAAAAAQAAAAAADwAE 8MEAAACiDArwCAAAAEEoAAACCgAAowAL8DwAAACAAASHXAG/AAAABwCBAQAA/wC/AQwAHgDL AWpKAAD/AQYADgA/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAPAMAADQCwAAcBEA AIANAAAPAA3wTQAAAAAAnw8EAAAABAAAAAAAqA8FAAAAKEsxKQ0AAKEPLAAAAAYAAAAAAAAA AAABAAAAAAACAA4AAgAAAAAABgAOAAD/AP4DAAAAAAACAA4ADwAE8MEAAACiDArwCAAAAEIo AAACCgAAowAL8DwAAACAAGSHXAG/AAAABwCBAQAA/wC/AQwAHgDLAWpKAAD/AQYADgA/AgAA AwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAIAWAADQCwAAABsAAIANAAAPAA3wTQAAAAAA nw8EAAAABAAAAAAAqA8FAAAAKEsyKQ0AAKEPLAAAAAYAAAAAAAAAAAABAAAAAAACAA4AAgAA AAAABgAOAAAA//4DAAAAAAACAA4ADwAE8MEAAACiDArwCAAAAEMoAAACCgAAowAL8DwAAACA ACSIXAG/AAAABwCBAQAA/wC/AQwAHgDLAWpKAAD/AQYADgA/AgAAAwC/AgEADwD/AhYAHwB/ AwAADwAAAA/wEAAAAKAgAADQCwAAICUAAIANAAAPAA3wTQAAAAAAnw8EAAAABAAAAAAAqA8F AAAAKEszKQ0AAKEPLAAAAAYAAAAAAAAAAAABAAAAAAACAA4AAgAAAAAABgAOAP8AAP4DAAAA AAACAA4ADwAE8K8AAACiDArwCAAAAEQoAAAACgAAgwAL8DAAAACAAGSEXAG/AAIAAgCBAQQA AAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAgAABDwCAAAAEAO8AOgEWAPDwAN8E8A AAAAAJ8PBAAAAAQAAAAAAKgPHQAAAHVzZXMgc3ltbWV0cmljIGtleSBlbmNyeXB0aW9uAACh DxYAAAAeAAAAAAAAKAAAAQAyAB4AAAAAAAAADwAE8EgAAAASAArwCAAAAAEoAAAADAAAgwAL 8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQ APAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIADwDuA+QBAAACAO8DGAAA AAEAAAANDgAAAAAAAAUAAIAAAAAABwAAAA8ADASUAQAADwAC8IwBAABgAAjwCAAAAAMAAAAD RAAADwAD8CQBAAAPAATwKAAAAAEACfAQAAAAAAAAAKAAAAB4AAAAAAAAAAIACvAIAAAAAEQA AAUAAAAPAATwcgAAABIACvAIAAAAAkQAACACAABTAAvwHgAAAAQAAAAAAIAAxIRcAb8BAAAB AP8BAAABAAEDAqwAAAAAEPAIAAAAkAAAASAUYAMPABHwEAAAAAAAwwsIAAAAAAAAAA0AXAEP AA3wDAAAAAAAng8EAAAAAAAAAA8ABPByAAAAEgAK8AgAAAADRAAAIAIAAFMAC/AeAAAABAAA AAAAgAAkhVwBvwEAAAEA/wEAAAEAAQMDrAAAAAAQ8AgAAACkBCABQBXoDg8AEfAQAAAAAADD CwgAAAABAAAADgBcAQ8ADfAMAAAAAACeDwQAAAABAAAADwAE8EgAAAASAArwCAAAAAFEAAAA DAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69aAC/ARIAEgD/AQAACAAEAwkAAAA/ AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIAAAByFzQAAAAB ABAAAAAAAAMAEACdHgAACgAQAGMjAAANABAAB0wAABAAEAB3IQAAFwAgAIgPAAA5GQAAAAD1 DxwAAAALAQAAkg4AAwAAAADzTQAAAQAAABgAAAAHACcwDwDoA4APAAABAOkDKAAAAIAWAADg EAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPIDIAIAAC8AyA8MAAAAMADS DwQAAAAAAAAADwDVB3wBAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBu AAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAYSEAC3D0QAAABBAHIAaQBh AGwAIABCAGwAYQBjAGsAAABtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAAAFi0YgCK iQowAAAGIiAAtw9EAAAAVABhAGgAbwBtAGEAAABsAGEAYwBrAAAAbQBhAG4AAAAMtmIADLZi ADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABiIwALcPRAAAAE0AbwBuAG8AdAB5AHAAZQAg AFMAbwByAHQAcwAAAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjACAAYCQAC3 D0QAAABBAHIAaQBhAGwAAABwAGUAIABTAG8AcgB0BQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA1AAAANAMAAAAAAABDAHUA cgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAGgACAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAEIAAAAqAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///// //////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACUYwAA DAAAAAEAAABoAAAAAgAAAHAAAAAEAAAAmAAAAAcAAACsAAAACAAAABABAAAJAAAAJAEAABIA AAAwAQAACgAAAFABAAAMAAAAXAEAAA0AAABoAQAADwAAAHQBAAARAAAAfAEAAAIAAADkBAAA HgAAAB8AAABTSVAgUmVjb3JkLVJvdXRlL1JvdXRlIEhpZGluZyAAAB4AAAALAAAATWVkc2No b2xhcgBSHgAAAFsAAABDOlxQcm9ncmFtIEZpbGVzXE1pY3Jvc29mdCBPZmZpY2VcVGVtcGxh dGVzXFByZXNlbnRhdGlvbiBEZXNpZ25zXENvbnRlbXBvcmFyeSBQb3J0cmFpdC5wb3QAAB4A AAALAAAATWVkc2Nob2xhcgBGHgAAAAMAAAA4MQBzHgAAABUAAABNaWNyb3NvZnQgUG93ZXJQ b2ludABvc29AAAAA4PT85BsAAABAAAAA4MLqt5VdwAFAAAAAwM84bEJiwAEDAAAATQEAAEcA AAAQYgAA/////wMAAAAIAG8QTQwAAAEACQAAAwAxAAAGAKInAAAAABEAAAAmBg8AGAD///// AAAQAAAAAAAAAAAAugMAAMoCAAAJAAAAJgYPAAgA/////wIAAAAXAAAAJgYPACMA/////wQA GwBUTlBQFABo2wAwAAAAABQAAABEDccAAAAAAOIACgAAACYGDwAKAFROUFAAAAIA9AMJAAAA JgYPAAgA/////wMAAAAPAAAAJgYPABQAVE5QUAQADAABAAAAAQAAAAAAAAAFAAAACwIAAAAA BQAAAAwCygK6AwQAAAAEAQ0AEAAAACYGDwAWAP////8AAAAAAAAAAAAAyAMAANgCAAAJAAAA +gIFAAAAAAD///8AIgAEAAAALQEAAAcAAAD8AgAAAAAAAgAABAAAAC0BAQAEAAAALQEBAAkA AAAdBiEA8ADQAsADCAAIAAQAAAAtAQEACQAAAPoCAAAAAAAAAAAAACIABAAAAC0BAgAHAAAA /AIAAP///wAAAAQAAAAtAQMABAAAAPABAQAEAAAALQEAAAQAAAAtAQMABAAAAC0BAwAJAAAA HQYhAPAA0ALAAwAAAAAEAAAALQEDAAQAAAAtAQIABAAAAC0BAwAIAAAAJgYPAAYA/////wEA EAAAACYGDwAWAP////8AAEoAAACNAgAAFgEAAMUCAAAIAAAAJgYPAAYA/////wEADQAAAPsC AAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAALQEBAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAAIB AgAQAAAAJgYPABYA/////wAASgEAAI0CAAB2AgAAxQIAAAgAAAAmBg8ABgD/////AQAFAAAA CQIAAAACBQAAABQCAAAAAAQAAAACAQIAEAAAACYGDwAWAP////8AAF8AAAC/AAAAwQMAAOkA AAAEAAAABwEEAAYFAABDD4YA7gAAADAAkAEAAAAAKABgA8AAYAAoAAAAkAEAADAAAAABAAEA AAAAAMAJAAAAAAAAAAAAAAIAAAACAAAAAAAAAP///wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgAMAAAAAAAAAAAAAAAAAAAA AAAAAAAA//wAef/gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/////gAAAAgAAAAAAAAAAAAAAA AAA////z////4AAAAAAAAAAAAAAAAAAAAAAAAAAAAeAP/7///3gH/EIAAAAAAAAAAB/AAAAP /////////9AAAAAAAAAAAAAAAAAAAAAAAAAAAAH/D////////3/8AAAAAAAD8AD///////// ///////4AAAAAAAAAAAAAAAAD8AAAAAAEEB///////////////AAP//4P/////////////// /////AAAAAAAAAAAAAYABg/AAAAAAAB/////////////////4D////////////////////// //wAAAAAAAAAAAAAAAAf+AAAAAAT///////////////////////////////////////////8 AAAAAAAAAAAAAAAAH//wAgAAP////////////////////////////////////////////gAA AAAAAAAAAAwAD/////z/Af////////////////////////////////////////////8AAAAA f8AB/xxCEf//////////////////////////////////////////////////////AAAAR/// //////n//////////////////////////////////////////////////////wAAA/////// //////////////////////////////////////////////////////////8AAP////////// ///////////////////////////////////////////////////////7AAD///////////// /////////////////////////////////////////////////////wAA//////////////// //////////////////////////////////////////////////8AAD////////////////// ////////////////////////////////////////////////AAAP//////////////////// /////////////////////////////////////////////wAAA/////////////////////// //////////////////////////////////////////8AAAP///////////////////////// ////////////////////////////////////+APwAAAC//////////////////////////// ////////////////////////////////4AAAAAAAA/////////////////////////////// ////////////////////////////n+AAAAAAAAAAf/////////////////////////////// ////////////////////////w/jAAAAAAAAAAH////////////////////////////////// /////////////////gHwAcAAAAAAAAAAAAB///////////////////////////////////// /////////f///44D+APxmAAAAAAAAAAAf/////////////////////////////////////// //////////+fAPAD4AAAAAAAAAAAAAf///////////////////////////////////////// /////gADmAAAAAAAAAAAAAAAAAAAD/H///////////////////////////////////////// /4AAAAAAAAAAAAAAAAAAAAAAAAZ4Xiv5T5////////////////////////////////////8A AAAAkAAgAAAAAAAAAAAAAAAAPKhB4AD7vhHP///8AAgAg//5////////////////////gAAA AAAAAAAAAAAAAAAAAAAAABgBgAAD8AGEgGIC4AAAAAP/gf//////////////////7AAAAAAA AAAAAAAAAAAAAAAAAAAAAAAGADAAAIAGAAAAAAAAEAAf//////////////////AAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAABggBAAAAAAAAAAAAAAAAIP/AAA////////AAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABgAAAAAAAAAAGAAKPAgAwAAAAAAAAGAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAQAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAACIAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACiJwAAQw/GAIgA AAAwAJABAAAAACgAYAPAAGAAKAAAAJABAAAwAAAAAQAIAAAAAADAVAAAAAAAAAAAAAAAAQAA HQAAAAAAAAAYrd4AIbXeACG15wAhtfcAGLX/ABi9/wDAwMAAKcb3ADHO9wA5zv8AOdb/AErW /wDO3vcAUt7/AFre/wDe5/cAY+f/AGvn/wB75/8AlO//AJzv/wCl7/8Ate//ANbv/wC99/8A 1vf/AOf//wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A ////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP///wD///8A////AP// /wD///////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////FxYa/////////////////xMU//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////8KCgoKCgoKDg4O ERMTFP//////////////GBkYEP//CQoKCgoKDAoMDA4R//////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////xoWFhYVFBYNFxYZGRYZ FhUVExMPEw4PDgwMDA8MDAr//////////////////////////////////////xP///////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////wYD BAoDCgYJAwoKCgoKCgoKCgoKDg4ODxER//8UFgoDBQkDCgMKCQkDCgkKCgoKCgoKCgwMDw8K Dv////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////xUVFRb/ //////////8XFhYVFRUUFBMUFQkI/xUVExMPEw8PDg4MDA4ODwwMCgoKCQn/CQkJCv////// ////GRoZFxoXFhYW////FP////8U//////////////////////////////////////////// //////////////////////////////////////////////8TExMRDwoM//////////////// //////////////////8KAwQECgMKBgQJCQoDCAoEAwUKCgoEAwoDCgMKCQUKBAMKBAQICQkJ CQkICAoKCQoKCgoKCgoKFhMTExMTFv8T//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////8UEw4VFhYVFRX/////FRMVDxUWExUVFBUTExUTExUTEwoKCgoK DgkKDAwMCgoKCgwKCgkJCQkJCQkJCQkJCgkKCP8KFhYWFRYVFRMWFRYV//////////////// ////////////////////////////////////////////////FBMTDxMK//////////////// GxYXFhMTEw8PCgwKCQMEBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUBBQUFBQUFBQUFBQUF BQUDBQYEBgoJCQkJAwYFBQMGExEGERERFBMTExMTExMWExYTFhMTExMTExMWFBP///////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////8WFxYWFhb///////////////////////////// /////////////////////////w7//////xf/////////ExMKFhcWExMPEQ8ODg4PChYVFhMV ExUTERMRERERChMTExMTExMTExMUCgoMCQoKCgoKDA4ODwoKBAoECgoKCQoKCgoKDgMJCQkJ CQkJCAkLAwoKBAoDCgQKBP//////////////////ExMOCg4MDhEPExQPCgwODw8PCv////// GhgXFhUWDxQREwwMCgkFBQUEBQQFBAQEBQUEAQUEBQUFBQUBBQUFBQUFBQUFBQUFAQUFBQUF BQUFBQUFAQUFBQUFBQUFBQUFBQUFBQUFBQUFBgYDBggKCgoKCg4ODg8OERETERETExMTExMT EwoJCgoKCgoKDAoPDgoKCv////////////////////////////////////////////////// /////////////////////////////////xMR//////////////////8TEf//////FxYWFxYW //////////////////////////////////////////////////////////////8XFhYVFRUV ExMTExMPERMTEw4PDg4MDAwMDAwWExMTEw8TDxMRERERDxQTExMTExMTDw4ODw4MCgoKDAoM Dw8KCgoKCgoEDAoKCgQEBAoKCgkKCgoKCgQKBAoDCgoDCgkJCQoDCgQKCgoE/////////xYR Dg4PDg8PFBMTDw4ODg8PDwoKCgoDBAQEBQUDBRMTDw8MDAoKBQUFBQUFBQUFBQUFBQUFBQUF AQUFBQUBBQUBBQEFBQUFBQUFBQUBBQUBBQUBBQUFBQUFAQUBBQEFAQUBBQEFAQUFBQMGCQMK AwsKCg4OCg4OERERERMKEwkJCQkJCQkKCgkKCgoKCgoMDw4MAwr///////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////FRUVFRYWFhYWFv////////////////////////////////////// ////////////Df//ExMTEw8KDAoKFgoTExQPEw8ODA4MDA4MDA4MDAwMDAwMDAwMDA4PExET DwwODAwKDAoKExMTDw4MDAoMCgoKCgEDAwMECgoKCgwKCgoEBAQEBAQECgMKAwoKAwoEBAMK CgQKCgoKBAoECgoMBAoFCgoDCQkKCgMKBQoDCgMKAwoGAw8RCg4KCgoOBAQGBAUFBQUGBQUG BQUFBQUFBQUFAQUFBQUBBQUFBQEFBQUFBQEFBQEFBQUFBQUFAQUFBQUFBQUBBQUBBQEFAQUF BQYGBQYFBQUFBQYGBgYGBgoICgYJCQYKCAgICAgICAMKBgoDCQYJCQkJCQoKCgoKCgoMCgwM CgwMCgoK//////////////////////////////////////////////////////////////// /////////////////////////////////////////////////xYWFhYWFhYWFhYWFhYWFRYV /////////////xT/////////////////////////FBUVFBUREQ8PCgoKCgoKCQkJCQoKCg4O Dg4MDA4ODA4MDAwMDAwMDAwKDAwKCgoKDgwMCgwKCgoKDgoKCgoKCgoKCgoKAwoKCgMKCgEF BQMEBAQEAwQECgoKCgoKCgoFBAoFBAQECgMFBAQKAwUJBAQEBA4KCQkKCQoKBgkDCgUJBAoD CgYKAwQDBgMEBAQEBgUFCgMEBAQKAwYGBQUFBQUFBQUBBQUFBQEFBQUFBQUFBQUBBQUFBQUF BQUFAQUFBQUBBQUFBQEFBQUFBQUGBgYEBggGCAgGCAgDCgMICAgIAwgICAYJAwoDCgMKAwoK AwoKCgoKCgoKCgoKCgoKCgoMCgoMCgoKDAoMCgr///////////////////////////////// ////////////////////////////////////////////////FBT//////////////////xcX FxYXFhYWFhYWFhYWFhYWFhYWFRUVFhUVFRQVFBQUFRX//xMTFBETEREP/////////xETERER ERMRExEPDw4MDAwKDAwMDAwKCgoMCgoKCgwKCgoKCgoKCgoKCgoKDAoKCgoKCgoKCgoJCg4K CgoKCgoKCgoKCgoKCgoKAQoKCgUKAwMEBgQDBQoEBAQFBAQEBAQEBAoECgQKAwUKBAoDBQoE BAQEBAQEBAQEBAQEBAMFCgMKBAMKBAoEAwoFCgQKBgYEBAUFBQQEBAQEBAQEBAQFBAQEBQMF BQUBBQEFBQEFBQEFAQUFBQUBBQUBBQUFBQUFAQUFBQYBBQEFBQYGBgUFBgMGBggGCAYICAgI CAgICAoDCQgKAwkKCgoKCgoKCQoKCgoKCgoKCgoKCgoKCgoKCgoMCgoMCgwKDAwMDgoKDv// ////////////////////GRkXFhcXGhYX/////////////////xsXGhYXGhUXF////xYWFf// /xb/////FP////8U////FA8UDxQTExMTExMUExUPExUTFRMTExMTExMTExUVFRMVFRUVFRUT DxMRERETERETEQ8TEw8TERMTDxMTDxMPEw8PDw8ODAwMCgwKDAoMCgoMCgoKCgoKCgoKCgoK CgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoJCgoKCgMKBgoBCgoKCgMKBQoBCgUDCgQK AwQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECgMFBAQEBAQDBAQEBAQEBAQE BAQEBAQEBgQGBgQGBAUEBQQFBAQFBAUDBQUFAQUBBQUFAQUFBQUFAQUFBQUFBQUGAwYFAwYG CgYICAYGBAYKCAgGCQMKCAgICAoICQkJCQkJCQkJCgoKCgoKCgoKCQoKCgoKCgoKDgoKCgoK CgoKCgoKDAoKDAoMCgwODAwOCgr///////////8Z////FxYVFBUTFBERERERDxEREw8RExET DxMRERETERMTDxMRERERERMRERMRERERERERERERERERDxH//xERDw8TExMUExMUExMVFBYT ExMTFRMTExMTExMTExMTExMTEw4ODhETDxMTDxMTDxMTDw4PDg8ODg4PDg4PDg8ODg8ODg8P Dg8ODg4PDg8ODw4PDw4ODg8ODg4PDw4ODg8ODg4OCgwMCgwMCgoKCgoKCgoKCgoKCgoJCgkJ CQkKCgoFCgoKCgoKCgMJBQoFAwUDBQMFAwUDBAMEBAMEBAQEBAMEBAQEBAQEBAQEBAQEBAQE BAQEBAQEBAQEBAQEBQQEBAQEAwQEBAQEBAUEBAQEBAQEBAQFBAMFBAQFBgYFBgYGAQUGBAYF BQYBBgUFBgEFBQYGBgUGBgUGBgYGBgMGCgMGAggICAgGAwkGCAgICAgICAoJCQsKCQoJCgEG CgYBCgYGCgYKBAYGCgMKCgMKCgMJCgoKCgoKCgoMCgoKCgoKCgoKCgoK////////ExMTGRcW FhYWFhUTExETERMRExETERETERERExERExETERMRERQPERMRExEREREPERMPDxEREREREREP EREPEw4PDxEREQ8RDw8PDxEPEQ8ODw8ODxQTExQTExQTFBMTFBMTExQODw4PDg4PDg4PDg4P Dg8ODw4PDg8PDg8PDg8ODg8ODw4PDg4ODw4PDw4ODw4PDg4ODg4ODg4ODg4ODw8ODg4ODg4K DgoKDgoKDgoOCg4KCwoKCgoKCgkJCgoKAQoBCgMDBgMFBQMGCgoDBgoFBgUJBgoJBQUJBQMF BQMECQUEBQMFBAMEBAUDBAMFAwUEBAQDBAQEAwYGAwQFAwUFBAMEBAQFAwYFAwUDBQQDBQMF BQMGAwUGAwUFAwYDBgYGBgYGBgYGBgYEBgYGCgMGCgYGAwgGBgYGBgQKBggGCAgGBggGBgYG CAgGCAgGBggGAwgGBgoDBgYGBgoGCgMKCQYDBgEGBgEIAwMDAwMBAwIKCQ4KCgwMCQEKCQIK CgoKCgoKCgoCChcWGRUVFRQUExMTExEREREREQ8RERERERERERERERETDxEREREREREOERMP EQ8PDw8ODg4ODAwOCg4RDw8PDxEREREREQ8RDxERERERDw8RDw4TDw8PDw4PDw4ODg4ODg4O Dw4ODg4OEQ8RDg8ODg4PDg4PDg4PDg8ODg8ODw4PDw8PDg8ODg4ODg4ODAwMDAwMDAwKDAwM Cg4KDgoKDgoKCgoKDg4KDg4KCgoDCQoKDgoKDgoKDgoKDgoOCg4KDgoKCgwKCg4KCg4KCgoK Cg4BCggCCgMKAwgDCgEJBQMJBgMJBQMJBQUKAwUKAwUJBQUDCQYGBQoGAwYDCQYDBQYKAwkG BggKAwQGBQUDBQoDCQYDCgMGCQUIAwoGAwoGAwoGAwoGBgYGBgYGBgYCBgYDBgYGBgEGBgYD CgYBCgYIBggGCAYIBggICAMIBgMGBggDBgIGAgYDCAMCAwEJAgICBgEFAgIKCgoKCgoKCgwB CgoKCgEKCgoKCgoKCQkJCQkJCQkJCQkJCQkKCQr/CgobGxsaGhoaGRoRERERERERERERERER DxEREQ8RERERERERERERDxERDxEOEQ8PDw8PDw4ODg4MDA4KEQ8RDw8PDw8PDw8PDw8ODw4O Dg4ODg4ODgwODAwMDAwMDAoOCg4KCw4KCxEREREODw4PDg8ODAwMDAwMDA4ODg4ODg4ODg4O Dg4ODg4ODg4ODAwODAwMDAwMDAoMCgwKDAoOCgoKCgoKCgoKCgoKCgoKCgkKCQkJCQkJCQkJ CQkJCQkJCQoKCQkJCgoKCgoKCgoKDgoLCg4KDgoLCgoKCgoKCgoKCgoKCQkJCQMFAwYKAwYD BgMGAwYDAwYDCAYGCgYIBgkDBAoGCgEICAYIAwgGBgkDBgoIBgYKAwYKCQMKAwoGAwoICAgG BAYIBggGAgYCCgYDCgEKAQYKBgEKBgEBCAYBCAYCCAYIAwgDCAgICAMICAIICAMKAgoJCQkI CwkJCQkCCQoJDAkKCgoKCgIKCgoKCgoKDAoJCQkJCQkJCQkJDgkOCQ4CCQkOCQkJCQkOCQoK GxsQGxoaGhobGhkZFRUVFRMTExERERERERERERERERERERERERERDxERDw8ODw4PDw4ODg4O Dg4JDg8PDw8PDw8PDw8PDw8PDg8ODg4ODg4ODgwODAwODAwMDAwMDAoOCg4KDgsLCwsKCg4O Dg4ODA4MDA4MDgwODg4ODg4ODg4ODg4ODg4ODg4ODgwKDAwMDA4MDAwMDAwKDAoKCgoKCgkK CgoKCgoKCgoKCgkKCQkJCQkJCQkJCQgJCQgJCgkKCQoJCgkKCQoJCgoKCgoKCgoKCgoKCg4K DgoOCg4LDgoKCgoJCQkJCQkJCQkJCAoICwgICwgICwMICgMGAwoDBgYDBgMKAwgDCAgDCAMJ BggDBggIAwgGAwYGBggFAwoEAwgDCAEKAQoCBgYKBgYEBgYGBgYKAQoDBgoGCgYJBgoDBgMI AwYKAwgCCAMIAQgICgMICAkJAggLCQkJCQkJCQkJCQkJCgkKCgoKCgoKCgwJCQkJCQ4LCQ4J CwIOCQkJCQkJCQkJCQkJCRUJCAkKCv//GxoZFRUUGRkZGRkVFRUTERERERETERERExEREw8T ERMPExETERERExEREw8TEREREREREREREREPEQ8REQ8PEQ8PDw8PDw8ODw4PDg4PDg4ODgwM DAwMDAwMCg4MCgwKDgoOCgsLChERERMODg8ODg4PDg4ODw4PDg8ODg8ODg8ODg4ODw4PDg8O Dw4PDg8ODw4PDg8ODw4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ICQkJ CQkJCQkKCQoKCgoKCgoKCgoBCgoKAwoKAwoKAQoKAwEKCgoICgoJCggKCgMKCggKCAgKCAgK CAsIAgoICwkDCgkJCQkLCQgLCAgJCQkJCgMICggKCQkDCgMICAYJBgkKCQUDBgMGAwYGAwYD AwMDAwEDAwEDAQEBAQMBAwMBAwMDAwMDAwMDAwoDCAMKCAYKCAgICAgICAkICQkJCQkJCQkJ CQkJCQkKCQkKCQkJCQkJCQkICQgJCQkJERMUExUTFRUVFBQUFBUUFBUZGRn/////GRkVFRQU FBMTExERERERERERERETERETERETERERERMRERMRExERExERExERExETDxERERERExERDxER DxEPDxERDw8PDg8ODg8ODw8ODg4MDg4MDA4MDAwMDAwOCg4KDgsKCBQRERERDw8PDg4PDg4O Dg4ODw4ODw4ODw4ODw4ODAwMDAwMDAwMDAwMDAwMDAwMDAwMCg4KCg4KDg4IDg4KDg4KDg4O Dg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODg4ODgwODg4KCgIKCQoBCgoKCgoKCgoKCgMK CgoKCgoKAwoKCgoKCgEKCgoKAwoKCgoKCgoKAwoJCwoJCgoJCAkLCAMLCQkJCQoCCgoDCQoK CQoDCgoDCgIKAQkBAQEBAQEBAQEDAQMBAwEDAwMBAwEBAQEBAQMCAQEDAQEDAwMDAwMBAgoD BAMICAgICAgICAgLCAkJCQkJCQkJCQkJCQkKCQkJDAkOCQkODgkRDg4RERERFBQRFBERFBQR FRQUEQ4RDg4ZGRkR////////GhkVFRMUERMRERERERERERETERMRERMRERMRExERERMRERMP ExETERETDxMREREREQ8RExERERERERERERERERERDxERDw8PDw8PDw8PDw8PDg4ODgwKDgwM DAwODgoLDhUUDxMRExEPEQ8MDA4MDgwMDAwMDAwMDAwODA4MCg4MDAwMDAwMDAwMDAwMCg4M DAwJDgoKDgoOCwoLDggOCgsKDgoOCw4KCg4OCg4KCg4KCg4KCgsOCg4OCgoODg4ODg4ODg4O Dg4ODg4ODg4MDAwKCgoBCgIOAQoKDgEOAw4KCgoKAwoKCgoKCgoKCgoKCgoKCgoKCAoICggJ CggJCQoICgoICggJCQkKAgoKCgoKCgoKAgoKCgIKCgoBAQEBAQEBAQEBAQEBAQEBAQEDAQMD AwMGAwYGBgQGBgoGBgMGBgYECgYDCgkDBgoDAwgIAggICAIICAgIAggJCAkJCQkLCQkLCQkJ CQkJDg4JEQ4RERERERERFBQUFBEUFBERERERCRERExQUEf///////xkZGRUUFRMTExMUERET ERMRERERExERERMREw8TERMRDxMRERMPERETERERERMRERMRERERERETERERERERERERERER Dw8RDxEPDw8PDg8PDw4PDg4ODg8KDgoODgoOCwoOEw4REw8UEQ8ODA4ODA4ODgwMDAwMDAwO Cg4KDA4MCg4KDgoODAwMDAwODA4KDg4MDgkMCQkOCgoOCg4KDgsLDgsKCwoOCg4KCwoLCgsK Cg4KDgoOCgsKCwoOCg4KCgoKCgoKDg4ODg8ODw4OCg4BDgEOCgoKCgoKDgEKCgIKAQ4BCg4K AgoBDgIDDgMKAwoDAwoDAw4KAgoKCgoKCgoKCgoKCgoKCgoKCgoKCgoKAwoDAwoKAwMKCgMB CgEBAQMBAQEBAQEBAQEBAQEBAQEBAQMGAwYDCAYDAwgGBggGCAMKAwYJBgMGCQMJAggIAggI AggCCAgICAkJCQkJAgkCCQIJCQkJCREOERERERQUFBQUFBQUFf///////////xQUExQTFf// //////////8a/xQVExQRExMTERERERERExERERETERERERERERERExERERMRERMRERETERMR ERERERERDxERDxEPDw8PEQ8PDw8PDw8ODw4PDg8ODg4OCg4ODAwMDAwMCg4KDg4KDgoOCgsU ExMTEwoODAwMDA4KDgoODA4KDgoOCg4KDgoKDg4KDgoOCg4MDAwMDAwMDgoOCQ4OCQ4LDg4O Cg4KDgoOCgsODg4KCg4OCgsOCgoOCgsOCgoOCgsKCgoLCgsLCw4KCgoKCgoOCgoCCgoBDgEO AQoKCgoKDgoKCgEOAQIKAQ4BCgoKCgMOAQ4DCgMCCgMLAgMKAwMKAwIKAwMDAwMDAwoDAwID AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDBgIDBgEGCAYGBgoFBgQECgYDBAoDCggICAgI CAgICAoDCQkJCQoMCQwMCQ4ODg4ODhEOEQkRDg4ODw4ODxEOEREREREREQ4JEREREf////// ////////////////////////////////////////GhsbGRoaGRUVExMRExERExERExETERET ERETERETERETERERExEREw8TERERDxERDxERERERDxERDw8PDw8PDw8PDw8PDg8ODg8ODg4O Dg4MDAwMDA4KDgoOCwoOCwsLCwsKCxUTEw8OCgwMDA4KDg4OCg4KDg4KDgoKDgoODgsKDgoO CwoJCgkJCQkJCQIJCAkICQgJCAkDCAkJCAkICQgJCAkKCQgJCAkLCw4LCg4LCg4LCwsKDgkO Cg4KDgoKCgoOCg4KCwoKCgoKCgoKCgoKCgoKCgoKCgoOCg4KDgoKAgoCCgIDAgMDAwICAgMC AwMCAwIDAgMDAgMDAgICAwICAgEDAwMDAwMDAwICAgICAgICAgICAwICAwIDBggICAgICAUD BgMDAwMDAwMCAwIBCgMKCgMKAwkICAoDBgIJCQkJCQkJCQ4JCQ4ODg4OEREJEQkRCQ4RDg4R EREREREUFP//FBUZGRkVGRr///////////////////////////////////////////////// ////////////ERERERERERERERMRERMRERMRExETERMRExERExETERERExEREREREREPERER EREOERERDxEPEQ8PDw8PDw4ODg4ODg4ODg4MDAwKDgoOCg4KCw4KCw4KCwoTExEREQ4OCgoM Cg4KDgoMCg4KDgoODggOCgoOCg4KDgoICwkKCQkDCQkJCQkICQgJCAkICQkICAkICAgJCAoI CAgJCAkICwgJCAkICAkICAsICAsLCwsLCgsKCw4KCwsKCgoKCgoKCgoKCgkKCgoKCgoKCgoK AgoCCgIOAgoCAwMCAwMCAwIDAwICAwICAgICAgMCAgMCAgMCAwIDAgICAgICAgICAgICAgIC AgICAgICAgICAgICAQoBCAgGCAgICAgICQkICQkJCQkJCQkMAwkBCQECDwICERQREwMOCQ4O Dg4RDg4TERQTFRUVExMVGRkZFRUVFP////8ZGRUZGRkZ////Gxr///////////////////// /////////////////////////////////////////xkRERMRERMRExERExERExERERERDw8P ERMREw8TDhETERERERETEREREREPEREPEw8RDhMRDw8PDw8PDw8PDg4ODg4ODg4ODgoOCg4K DgoOCwsLCg4LCgoVFQoPEREODg4JDgkOCQoKDgoKDgkOCgoODA4OCg4KDgkDCAgJCAMJCQkJ CQkJCQkJCQgJCAkICggGBgoICwgIAwgICQgKAwoDCAoICAkICAoDCAgICAgICAgICAgICggI CAoDCgoKCgoKCgoKCgoKCgoKCgoKCQkKCQgJCAkJCQkCCgIJCgIICQIICwgCCQgCAgIIAgIC AgECAgICAgICAgICAgICAgICAQECAgIDAQICAgEDAwMICAYICgMKCAgICAgICAIJDgkOCQsJ DgkJCQkJCQwMDA4RExERExP//////////xERERET//////////////8VFBX///////////// //////////////////////////////////////////////////////////////////////8a ERERERERERERExMREREREREREQ4ODw8PDw4ODg4PDxMREREREQ8PDg4ODgoODw8ODg4JDgkO Dg4ODg4JDgoLCQ4KCwoPDgwMCg4JCQsLCgsLDgsLCwsKFhMRExETDxEODw4PDg4ODgoMDgkM CQ4JCQoJCQkJCQkJDggOCQ4JCQkJCQkJCwkJCQgICQkICQkDCgkJAwgICAoJAwoICAkJCQoI AwoICAoICQgICAgICAgICAgDCAYDCAYDCAgKCAEKBgoBCgYICAMKAQYIAwYICAMKCAoGAwoJ CAkJCAgKCggLCAgICAgLCAgICAgICAgICAgICAgICAgICAgCCAYIAwgGCAgGAwMICAMICAMD AwoDBgYG/wMLCAgICQgJCAIJAg4CDgIRDgkOCQkJDg4R////FBQV/////////xEOCQIJAg7/ //////////8ODg4RDhH///8VDv//EQn///////////////////////////////////////// ////////////////////////////FRQUFBERFBERERERERERERERERERDg4ODw4ODg4PDhER ERMREQ4PDg4ODgkMDA8PDw4ODg4OCQ4ODw4ODgkOCwgKCgoODg8JDgkOCwsKCgsLCAMLCwsK CAkRFRMTERMRDg8ODg4PDg4ODgkODgsODgkJCQkJCQkJCQkICwIJCQkJCQkJCQkJCQkJCAgJ CQMJCQoDCQoDCgMKAwkJAgkJAwkDCQoDCQgDCQgJCAsICAgICAgICAgICAgICAMIAwYICAMD BggIAQoDBgoDCAoDBggCBggCCAEGCAgGCAgIAggGCAMICAsICAMICAgICAgICAgICAgICAgD CAgICAMICAgICAMICAMIAwgIAwgIBggGCAgCCAkICAgICAgJAg4JDgkPCQ8JDxMPERERDg4J Ef//CAMJCQn//////////wIODg//////////////CRQUExX///////////////////////// //////////////////////////////////////////////////////////////8bFRUUFBQR ERERERERERERERQREQ4JDg4JCQ4OCw4JDgkOCAsOCQsLDgkOCQ4JDgkOCQ4JDgkLCw4OCQgO CQ4OCQ8MDAwOCQsLCwsJCQgICQ4KCg4IEQ4REREODhEPDg4ODg4ODg4ODg4OCxELDg4ODg4P ERERERERERERExERERERERERERERDg4ODgkMDgoKDgwOCQkJDgkODgkJDgwOCQkOCQkJCAgI CAgJCQgICAgICAIICAgIAwgIAwgIBggICAgDCAYDAwYDBgMIAwYCBgIGCAIICAYICAYICAMI CAMICAYICAgIAggIAggCCAgDCAYICAMICAgIAwgICAgDCAgIAwYICAMCCAIDAgMICAgICQkO Dg4ODg7///////////////////8CDgn//wkJ//////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////xQTERMRERER////DhEODg4JDg4OEQsRCw4OCw4JDg4J Dg4JDg4ODg4OCQ4OCw4RCwsOCA4JDgkOCQ4JDg4OCQgOCQsICQkJCQkJCQkJCgoKDgoKEREO Dg4ODg4ODg4ODg4OEREOEREOEQ4ODhERFBMRFRERERERERQTExEREREREQ4RDgkODgkODgkO CQ4ODg4ODg4ODg4JCQ4OCg4KDgsLCgsOCgsLCwsLCwoKCwsIAggDCAMIAwgICAgCAQgDCAMI CAYCCAIIAggCCAIIAggBCgMIAwgICAgICAgDCAsDCAgGAgYCCAYDAwgDCAMCCAgIAwMCAwgD AwICAgICAgIICAoCCAgIBgYGBgYK//////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////EQ7//xEODgv/ ////Ef8ODgkO////Dv8R/w4JEwkJDg7//w7/Ef//EQ4JCw7//w4LDhEOCQ4OCQ4JDg4ODg4J CQkOCgoJCwsJCQkJCwkODg4ODgoOCw4ODg4ODg4ODg4ODhMUFRkZGhkZGRkaGRkZFRkWGRkZ GRkZFRUUFBQUFBEREQ4ODg4ODhEODg4ODg4OERMRERERDg4LDgkJCQkJCgsLCwsLCQsJCw4K DgoKCwsLCwsLCwsKAgoDCggCCAIIAgMICAgICAgICAgICAgICAkDCgMICAgICAgICAMICAgD CwgICwYICQgDCwIKCAILAgsICwgCCwgLCAsJCQsJCwkICQgJCAgGBgYG//////////////// //////////////////////////8J//8J//////////////////8O//////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////EQsOEf//Ef8O/xH/////Ef//////Dg8JEf////////////// //8JCQkJEf8CDg7/DgkOCBH/////Cf///wgGCP//CgkODg4LCxERDgsRDhERExMREw8PDw4T ERT//////////////////xv//////////////xX//////xEOEREOEQ4RERERExERFP//ERER EQ4ODg4ODg4ODg4ODg4ODg4ODg4KCQkJCgsKCgoKCwoKCwkJCgkJCgkJCQkLCAkICQkICQkI CQsLCQkKCgoJCwgICAgIAwgDCAMICAMLAwgDCwMLAwkJCwIJAggCCQgJAwkJCAgICAgICAkI CAIICAgIBgYICA7///////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////8REf////////////8R Ef///////////////////////////xEODgkJCf//////////////Dg7/////C///Cv////// ////Dgj///8I/////////wn/CgQK//////////////////////////////////////////// //8cGhoUFBEUFRUZGf///////xoVFBERCwkICQsODg4ODg4ODgsODg4ODg4ODg4ODg4ODg4O Dg4KDg8PCQkKCQkJCQkLAwsIAwsCCQgICAgJCgkJCQkICQkJCQkJCQkICQgJCQkJCwgJCQkJ CQgJCQgLCAkJCQkJCQkJCwoKCgoKCgoKDgoO/wgG//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8OEf//////////////Dg7///// /////////////////////wn///////////////8GCv////////////////////////////// //////////////////////////////////////8U////////////////////Ew8ODg4OEREO DhELEQ4RDw8RERERDxERERERDg4ODg4REREODhEOEQ4RDg4RERQUExQUFBMOEw4ODg4OCQ4R CQkJCQkJCQgJCQgJCAkJCQsJCQkJCQgJCQgICAgICAgJCQkJCAsKCwoKCwoLCg4LDgP///// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////Dgr//////w7/////////////Dv// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////CP//////EQ4TExET ExEPE////////////////////////xUVFRQUFBUUFBQUFBQVFBQUFBUVFBQVFRQUFBQTFBQU FBQVFBUVFBQUFRQUFRUUFP////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////8ECf////////////////////////////// ////////////////////////////////////////////////////////////Aw7///////// //////////8J/w7///8KDggR////////Dv//////////////Aw7///////////////////// ////////////////////////////////////////////////////CAr///////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////woI//////////////// ////////////Dv////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////Cv////////////// //////////////////////////////////////////////////////////////////////// //////////8K////Cv////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////Cf////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////8EAAAABwEBAAgAAAAmBg8ABgD///// AQAHAAAA/AIBAAAAAAAAAAQAAAAtAQQABAAAAC0BAAAHAAAAGwTpAHkDcABIAAQAAAAtAQMA BAAAAC0BAgAFAAAACQIAAAACBQAAABQCAAAAABMAAAD7Asv/AAAAAAAAkAEAAAAAAAAAIkFy aWFsIEJsYWNrADAABAAAAC0BBQAEAAAA8AEBAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4B GAAEAAAAAgEBACgAAAAyClUAUgAWAAAAU0lQIFJlY29yZC1Sb3V0ZS9Sb3V0ZScAFAAnABIA KQAkACMAJAAXACQAEgApACQAIwAYACMADwAqACMAJAAXACQABAAAAC4BAQAEAAAAAgECAAUA AAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBABAAAAAyCpUAUgAGAAAASGlkaW5n LQARACQAEgAjACQABAAAAC4BAQAEAAAAAgECAAQAAAACAQIABAAAAC0BBAAEAAAALQEAAAcA AAAbBDkCKQOAAYgABAAAAC0BAwAEAAAALQECAAUAAAAJAgAAAAIFAAAAFAIAAAAAEwAAAPsC 1f8AAAAAAACQAQAAAAAAAAAiQXJpYWwgQmxhY2sALAAEAAAALQEBAAQAAADwAQUABQAAAAkC AAAAAgUAAAAUAgAAAAAEAAAALgEYAAQAAAACAQEAHgAAADIKrQGSAA8AAABCcnlhbiBKLiBC eWVybHkAIQATABoAHQAcAA4AHQAOAA4AIQAaAB0AEwAOABoABAAAAC4BAQAEAAAAAgECAAUA AAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBABAAAAAyCuoBkgAGAAAARGF2aWQg IQAdABoADgAcAA8ABAAAAC4BAQAEAAAAAgECAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4B GAAEAAAAAgEBABAAAAAyCuoBIwEGAAAARGFpa2VyIQAcAA4AHQAcABMABAAAAC4BAQAEAAAA AgECAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBACUAAAAyCigCkgAUAAAA U2hhaWxhbmRyYSBCaGF0bmFnYXIfABwAHQAOAA4AHQAcAB0AEwAcAA4AIgAcAB0AEwAcAB0A HAAdABMABAAAAC4BAQAEAAAAAgECAAQAAAACAQIABAAAAC0BBAAEAAAALQEAAAcAAAAbBD4B QQMAAXAABAAAAC0BAwAEAAAALQECAAUAAAAJAgAAAAIFAAAAFAIAAAAAFQAAAPsC1f8AAAAA AACQAQAAAAAAAAASVGltZXMgTmV3IFJvbWFuAB0ABAAAAC0BBQAEAAAA8AEBAAUAAAAJAgAA AAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBABAAAAAyCi4BvAAGAAAAZHJhZnQtFQAPABMA DgAMAA4ABAAAAC4BAQAEAAAAAgECAAUAAAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAA AgEBABAAAAAyCi4BGwEGAAAAYnllcmx5FQAVABMADwALABYABAAAAC4BAQAEAAAAAgECAAUA AAAJAgAAAAIFAAAAFAIAAAAABAAAAC4BGAAEAAAAAgEBACQAAAAyCi4BiAETAAAALXNpcC1o aWRlLXJvdXRlLTAwLgAOABEACwAWAA4AFQAMABUAEwAPAA4AFQAVAAwAEwAOABYAFQALAAQA AAAuAQEABAAAAAIBAgAFAAAACQIAAAACBQAAABQCAAAAAAQAAAAuARgABAAAAAIBAQAMAAAA MgouAckCAwAAAHR4dAAMABUADAAEAAAALgEBAAQAAAACAQIABAAAAAIBAgAEAAAALQEAAAQA AAAtAQQAEAAAAPsCEAAHAAAAAAC8AgAAAAABAgIiU3lzdGVtAG4EAAAALQEBAAQAAADwAQUA DwAAACYGDwAUAFROUFAEAAwAAAAAAAAAAAAAAAAACQAAACYGDwAIAP////8BAAAAAwAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAADAEAAAwAAAD3AQAAAgAAAOQEAAAeAAAADwAAAE9uLXNjcmVlbiBTaG93AAAeAAAA AgAAACAALXMDAAAAXY0AAAMAAABQAAAAAwAAAAQAAAADAAAAAAAAAAMAAAAAAAAAAwAAAAAA AAADAAAAsw0IAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAoAAAAQAAAA VGltZXMgTmV3IFJvbWFuAAwAAABBcmlhbCBCbGFjawAHAAAAVGFob21hAA8AAABNb25vdHlw ZSBTb3J0cwAGAAAAQXJpYWwAGgAAAENvbnRlbXBvcmFyeSBQb3J0cmFpdC5wb3QAHwAAAFNJ UCBSZWNvcmQtUm91dGUvUm91dGUgSGlkaW5nIAAXAAAAUHJvYmxlbSBhbmQgT2JqZWN0aXZl cwAbAAAAUmVjb3JkLVJvdXRlIGhlYWRlciBoaWRpbmcAGAAAAEFsdGVybmF0aXZlcyBhbmQg RnV0dXJlAAwQAAAGAAAAHgAAAAsAAABGb250cyBVc2VkAAMAAAAFAAAAHgAAABAAAABEZXNp Z24gVGVtcGxhdGUAAwAAAAEAAAAeAAAADQAAAFNsaWRlIFRpdGxlcwADAAAABAAAAACYAAAA AwAAAAAAAAAgAAAAAQAAADYAAAACAAAAPgAAAAEAAAACAAAACgAAAF9QSURfR1VJRAACAAAA 5AQAAEEAAABOAAAAewBBAEEAOQBBADAARQBFADUALQBDADkANAAwAC0AMQAxAEQANAAtADgA QgBFAEUALQA0ADQANAA1ADUAMwA1ADQAMAAwADAAMAB9AAAAAAAAAAAAAAAAAAAAAAAAAAAA 9g8iAAAAFAAAAF/AkeM5jQAACgD0AwMAAABNZWRzY2hvbGFyCAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABzAAAAAAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABiIAAKkPCgAA AAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAA AAIAAAD//+8AAAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUA AGADYAMAAAAAAAUAAIAEgAQAAAAADwALBLgCAAAPAADwsAIAAAAABvCAAQAAAsAAAC8AAABb AAAABgAAAAAAAAAHAAAAAwAAAAYAAAAAAAAAlgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAYAAABFAAAAAAAAAAQAAAAAAAAABAAAAAAAAABC AAAAAAAAADYAAAAAAAAABAAAAAAAAAAEAAAAAgAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAA AD0AAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAUAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAAAgAAAAAAAAAG AAAAAAAAAAsAAAAAAAAACwAAAAEAAAAIAAAABAAAAAgAAAAAAAAABAAAAAAAAAAEAAAAXwAB 8NwAAAACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAABeAQIAB/Ak AAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAF4BAgAH8CQAAAAAAAAAAAAA AAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAXgECAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAA AP8AAAAAAAAAAAAAAAAAAABeAWIAB/AkAAAABgYR7sQXyb8oYT6I38Mr+A4s/wAPDQAAAgAA AAAAAAAAAF4BYwAL8CQAAACBAQQAAAiDAQAAAAi/ARAAEADAAQEAAAj/AQgACAABAgIAAAhA AB7xEAAAAAQAAAgBAAAIAgAACPcAABAfAPAPOAAAAAAA8wMUAAAAFwAAAAQAAAAAAAAABQAA gAAAAAAAAPMDFAAAABgAAAAEAAAAAAAAAAYAAIAAAAAADwDQBxMBAAAPAPoDZwAAAAAA/gMD AAAAAAEAAAD9AzQAAAA2AAAAZAAAADYAAABkAAAAZLRiAIqJCjBctGIACAAAAGYSAADACQAA 4vz//7L///8BAAAAcAD7AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAEALAAAfAP8DFAAAAAIA AAQMAAAAAAAAAAAAAAACAAAAHwAIBDwAAAAAAP0DNAAAAEIAAABkAAAAQgAAAGQAAAAMtmIA DLZiAAEAAAAAAAAAZhIAAFwKAAAAAAAAAAAAAAAA//8fAAcEPAAAAAAA/QM0AAAAIQAAAGQA AAAhAAAAZAAAAAy2YgAMtmIAAQAAAAAAAADEEQAAXAoAAAAAAAAAAAAAAAD//z8A2Q8MAAAA AADaDwQAAAAAACUADwDwD+kIAAAAAPMDFAAAAAMAAAAEAAAAAgAAAAABAAAAAAAAAACfDwQA AAAGAAAAAACoDx4AAABTSVAgUmVjb3JkLVJvdXRlL1JvdXRlIEhpZGluZwsAAKoPEgAAAB4A AAAAAAAAAQAAAAEAAAAAABAAnw8EAAAABQAAAAAAqA8yAAAAQnJ5YW4gSi4gQnllcmx5DURh dmlkIERhaWtlcg1TaGFpbGFuZHJhIEJoYXRuYWdhcg0AAKoPHAAAABYAAAAAAAAAHAAAAAEA AAADAAEAAAABAAAAAAAAAPMDFAAAABAAAAAAAAAAAgAAAA8BAAAAAAAAAACfDwQAAAAAAAAA AACoDxYAAABQcm9ibGVtIGFuZCBPYmplY3RpdmVzEACfDwQAAAABAAAAAACgD1QDAABQAHIA bwBiAGwAZQBtAA0AVgBpAGEALAAgAFIAZQBjAG8AcgBkAC0AUgBvAHUAdABlACwAIABhAG4A ZAAgAFIAbwB1AHQAZQAgAGgAZQBhAGQAZQByAHMAIABsAGUAYQBrACAAcgBvAHUAdABlACAA KABhAG4AZAAgAHQAaAB1AHMAIABsAG8AYwBhAHQAaQBvAG4AKQAgAGkAbgBmAG8AcgBtAGEA dABpAG8AbgAuAA0AVQBzAGUAcgAgAEMAbwBuAGMAZQByAG4AcwANAEEAbgBvAG4AeQBtAGkA dAB5ACwAIABQAHIAaQB2AGEAYwB5ACAAKABwAHIAZQB2AGUAbgB0ACAAaABhAHIAcgBhAHMA cwBtAGUAbgB0ACkADQBTAGUAcgB2AGkAYwBlACAAUAByAG8AdgBpAGQAZQByACAAQwBvAG4A YwBlAHIAbgBzAA0AUgBlAHMAdAByAGkAYwB0ACAAZwBhAHQAaABlAHIAaQBuAGcAIABvAGYA IABpAG4AZgBvAHIAbQBhAHQAaQBvAG4AIABhAGIAbwB1AHQAIABuAGUAdAB3AG8AcgBrAA0A ZQBnAC4AIAByAGUAcwB0AHIAaQBjAHQAIABJAEMATQBQACAAcgBlAHMAcABvAG4AcwBlACAA KABmAG8AcgAgAHQAcgBhAGMAZQByAG8AdQB0AGUAKQANAEEAcABwAHIAbwBhAGMAaAANAEIA aQBkAGkAcgBlAGMAdABpAG8AbgBhAGwAIABwAHIAbwB0AGUAYwB0AGkAbwBuACAAbwBmACAA cgBvAHUAdABlACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuAA0ARQBhAGMAaAAgAHAAcgBvAHgA eQAgAGkAcwAgAHIAZQBzAHAAbwBuAHMAaQBiAGwAZQAgAGYAbwByACAAZQBuAGMAcgB5AHAA dABpAG4AZwAgAHIAbwB1AHQAZQAgAGkAbgBmAG8AcgBtAGEAdABpAG8AbgAgAGEAYgBvAHUA dAAgABwgcAByAGUAdgBpAG8AdQBzACAAaABvAHAAHSAuAA0ARQBhAGMAaAAgAHAAcgBvAHgA eQAgAGgAYQBzACAAcwB5AG0AbQBlAHQAcgBpAGMAIABrAGUAeQAAAKEP7AAAAAgAAAAAAAAA AABRAAAAAQAAAAAADgAAAAAAAAAAACkAAAABAAAAAAAaAAAAAAAAAAAAMAAAAAEAAAAAACwA AAACAAAAAAAJAAAAAAAAAAAAnAAAAAEAAAAAAAcAAAAAAAIAGAABAAAAAAAAAFAAAAAAAAIA EgABAAAAAAACABQADQAAAAAAAgAYAAEAAAAAAAAAKAAAAAAAAgASAAEAAAAAAAAAGQAAAAAA AgAYAAEAAAAAAAIAHAAwAAAAAAACABIALAAAAAAAAgASAAkAAAAAAAIAGAANAAAAAQACAIEA EgCPAAAAAAACABIAAACqD1AAAACCAAAAAAAAAAwAAAABAAAAAwBLAAAAAAAAAAMAAAABAAAA AwAdAAAAAAAAAAsAAAABAAAAAwALAAAAAAAAAA0AAAABAAAAAwCPAAAAAAAAAAAA8wMUAAAA CgAAAAQAAAACAAAABQEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPGgAAAFJlY29yZC1Sb3V0ZSBo ZWFkZXIgaGlkaW5nEACfDwQAAAABAAAAAACqDwoAAAABAAAAAQAAAAAAAADzAxQAAAANAAAA AAAAAAIAAAALAQAAAAAAAAAAnw8EAAAAAAAAAAAAqA8XAAAAQWx0ZXJuYXRpdmVzIGFuZCBG dXR1cmUQAJ8PBAAAAAEAAAAAAKAPsAEAAEEAbAB0AGUAcgBuAGEAdABpAHYAZQA6ACAAUABs AGEAYwBlACAAcgBvAHUAdABlACAAaQBuAGYAbwAgAGkAbgAgAFMAdABhAHQAZQAgAGgAZABy AC4ADQBJAG4AdABlAHIAbwBwAGUAcgBhAGIAaQBsAGkAdAB5ACAAcAByAG8AYgBsAGUAbQAg AHcAaQB0AGgAIABVAEEAcwAgAHQAaABhAHQAIABkAG8AbgAZIHQAIABzAHUAcABwAG8AcgB0 ACAAUwB0AGEAdABlACAAaABlAGEAZABlAHIALgANAFAAcgBvAHAAbwBzAGUAZAAgAG4AZQB4 AHQAIABzAHQAZQBwAHMADQBTAEkAUAAgAFcARwAgAGkAdABlAG0ADQBQAGwAYQBjAGUAIABW AGkAYQAgAGgAZQBhAGQAZQByACAAaABpAGQAaQBuAGcAIABhAG4AZAAgAFIAZQBjAG8AcgBk AC0AUgBvAHUAdABlAC8AUgBvAHUAdABlACAAaABpAGQAaQBuAGcAIABpAG4AdABvACAAcwB0 AGEAbgBkAGEAbABvAG4AZQAgAEkALQBEAAAAoQ9uAAAALAAAAAAAAAAAAEMAAAABAAAAAAAU AAAAAAAAAAAAVgAAAAEAAAAAACEAAAAAAAAABQAAAAEAAACBAAYAAAAAAAAAQgAAAAAAAgAY AAEAAAAAAAAAFAAAAAAAAABVAAAAAAACABgAAQAAAAAAAAAAAKoPLAAAACYAAAAAAAAABAAA AAEAAAADAB8AAAAAAAAABAAAAAEAAAADAIwAAAAAAAAAAADqAwAAAAAAAHIXCAAAAAEAEABT TgAAAAD1DxwAAAAPAQAAkg4AAy9OAADbXQAAAQAAABgAAAAHACcwDwDoA5YPAAABAOkDKAAA AIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPIDIAIAAC8AyA8M AAAAMADSDwQAAAAAAAAADwDVB3wBAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBv AG0AYQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAYSEAC3D0QAAABB AHIAaQBhAGwAIABCAGwAYQBjAGsAAABtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAA AFi0YgCKiQowAAAGIiAAtw9EAAAAVABhAGgAbwBtAGEAAABsAGEAYwBrAAAAbQBhAG4AAAAM tmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABiIwALcPRAAAAE0AbwBuAG8AdAB5 AHAAZQAgAFMAbwByAHQAcwAAAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAC AAYCQAC3D0QAAABBAHIAaQBhAGwAAABwAGUAIABTAG8AcgB0AHMAAAAAAAy2YgAMtmIANLRi AASJCjBYtGIACAAAAFi0YgCKiQowAAAGIgAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD/ /T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAA AAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAP AAsEuAIAAA8AAPCwAgAAAAAG8IABAAACwAAALwAAAFsAAAAGAAAAAAAAAAcAAAADAAAABgAA AAAAAACWAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAABgAAAEUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAEIAAAAAAAAANgAAAAAAAAAEAAAAAAAA AAQAAAACAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAPQAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAABQAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAgAAAAAAAAACAAAAAAAAAACAAAAAAAAAAYAAAAAAAAACwAAAAAAAAALAAAAAQAA AAgAAAAEAAAACAAAAAAAAAAEAAAAAAAAAAQAAABfAAHw3AAAAAIAB/AkAAAAAAAAAAAAAAAA AAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAF4BAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ AAAAAAAAAAAAAAAAAAAAXgECAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAA AAAAAABeAQIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAF4BYgAH 8CQAAAAGBhHuxBfJvyhhPojfwyv4Diz/AA8NAAACAAAAAAAAAAAAXgFjAAvwJAAAAIEBBAAA CIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAA EB8A8A84AAAAAADzAxQAAAAXAAAABAAAAAAAAAAFAACAAAAAAAAA8wMUAAAAGAAAAAQAAAAA AAAABgAAgAAAAAAPANAHEwEAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAADYAAABkAAAA NgAAAGQAAABktGIAiokKMFy0YgAIAAAAZhIAAMAJAADi/P//sv///wEAAABwAPsDCAAAAAAA AABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfAAgE PAAAAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAAAy2YgAMtmIAAQAAAAAAAABmEgAAXAoAAAAA AAAAAAAAAAD//x8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAADLZiAAy2YgABAAAA AAAAAMQRAABcCgAAAAAAAAAAAAAAAP//PwDZDwwAAAAAANoPBAAAAAAAJQAPAPAP/wgAAAAA 8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPHgAAAFNJUCBSZWNv cmQtUm91dGUvUm91dGUgSGlkaW5nCwAAqg8SAAAAHgAAAAAAAAABAAAAAQAAAAAAEACfDwQA AAAFAAAAAACoDzIAAABCcnlhbiBKLiBCeWVybHkNRGF2aWQgRGFpa2VyDVNoYWlsYW5kcmEg QmhhdG5hZ2FyDQAAqg8cAAAAFgAAAAAAAAAcAAAAAQAAAAMAAQAAAAEAAAAAAAAA8wMUAAAA EAAAAAAAAAACAAAADwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFgAAAFByb2JsZW0gYW5kIE9i amVjdGl2ZXMQAJ8PBAAAAAEAAAAAAKAPVAMAAFAAcgBvAGIAbABlAG0ADQBWAGkAYQAsACAA UgBlAGMAbwByAGQALQBSAG8AdQB0AGUALAAgAGEAbgBkACAAUgBvAHUAdABlACAAaABlAGEA ZABlAHIAcwAgAGwAZQBhAGsAIAByAG8AdQB0AGUAIAAoAGEAbgBkACAAdABoAHUAcwAgAGwA bwBjAGEAdABpAG8AbgApACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuAC4ADQBVAHMAZQByACAA QwBvAG4AYwBlAHIAbgBzAA0AQQBuAG8AbgB5AG0AaQB0AHkALAAgAFAAcgBpAHYAYQBjAHkA IAAoAHAAcgBlAHYAZQBuAHQAIABoAGEAcgByAGEAcwBzAG0AZQBuAHQAKQANAFMAZQByAHYA aQBjAGUAIABQAHIAbwB2AGkAZABlAHIAIABDAG8AbgBjAGUAcgBuAHMADQBSAGUAcwB0AHIA aQBjAHQAIABnAGEAdABoAGUAcgBpAG4AZwAgAG8AZgAgAGkAbgBmAG8AcgBtAGEAdABpAG8A bgAgAGEAYgBvAHUAdAAgAG4AZQB0AHcAbwByAGsADQBlAGcALgAgAHIAZQBzAHQAcgBpAGMA dAAgAEkAQwBNAFAAIAByAGUAcwBwAG8AbgBzAGUAIAAoAGYAbwByACAAdAByAGEAYwBlAHIA bwB1AHQAZQApAA0AQQBwAHAAcgBvAGEAYwBoAA0AQgBpAGQAaQByAGUAYwB0AGkAbwBuAGEA bAAgAHAAcgBvAHQAZQBjAHQAaQBvAG4AIABvAGYAIAByAG8AdQB0AGUAIABpAG4AZgBvAHIA bQBhAHQAaQBvAG4ADQBFAGEAYwBoACAAcAByAG8AeAB5ACAAaQBzACAAcgBlAHMAcABvAG4A cwBpAGIAbABlACAAZgBvAHIAIABlAG4AYwByAHkAcAB0AGkAbgBnACAAcgBvAHUAdABlACAA aQBuAGYAbwByAG0AYQB0AGkAbwBuACAAYQBiAG8AdQB0ACAAHCBwAHIAZQB2AGkAbwB1AHMA IABoAG8AcAAdIC4ADQBFAGEAYwBoACAAcAByAG8AeAB5ACAAaABhAHMAIABzAHkAbQBtAGUA dAByAGkAYwAgAGsAZQB5AAAAoQ/sAAAACAAAAAAAAAAAAFEAAAABAAAAAAAOAAAAAAAAAAAA KQAAAAEAAAAAABoAAAAAAAAAAAAwAAAAAQAAAAAALAAAAAIAAAAAAAkAAAAAAAAAAACcAAAA AQAAAAAABwAAAAAAAgAYAAEAAAAAAAAAUAAAAAAAAgASAAEAAAAAAAIAFAANAAAAAAACABgA AQAAAAAAAAAoAAAAAAACABIAAQAAAAAAAAAZAAAAAAACABgAAQAAAAAAAgAcADAAAAAAAAIA EgAsAAAAAAACABIACQAAAAAAAgAYAA0AAAABAAIAgQASAI8AAAAAAAIAEgAAAKoPUAAAAIIA AAAAAAAADAAAAAEAAAADAEsAAAAAAAAAAwAAAAEAAAADAB0AAAAAAAAACwAAAAEAAAADAAsA AAAAAAAADQAAAAEAAAADAI8AAAAAAAAAAADzAxQAAAAKAAAABAAAAAIAAAAFAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8aAAAAUmVjb3JkLVJvdXRlIGhlYWRlciBoaWRpbmcQAJ8PBAAAAAEA AAAAAKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAAA0AAAAAAAAAAgAAAAsBAAAAAAAAAACfDwQA AAAAAAAAAACoDxcAAABBbHRlcm5hdGl2ZXMgYW5kIEZ1dHVyZRAAnw8EAAAAAQAAAAAAoA+0 AQAAQQBsAHQAZQByAG4AYQB0AGkAdgBlADoAIABQAGwAYQBjAGUAIAByAG8AdQB0AGUAIABp AG4AZgBvACAAaQBuACAAUwB0AGEAdABlACAAaABkAHIALgANAEkAbgB0AGUAcgBvAHAAZQBy AGEAYgBpAGwAaQB0AHkAIABwAHIAbwBiAGwAZQBtACAAdwBpAHQAaAAgAFUAQQBzACAAdABo AGEAdAAgAGQAbwBuABkgdAAgAHMAdQBwAHAAbwByAHQAIABTAHQAYQB0AGUAIABoAGUAYQBk AGUAcgAuAA0ADQANAFAAcgBvAHAAbwBzAGUAZAAgAG4AZQB4AHQAIABzAHQAZQBwAHMADQBT AEkAUAAgAFcARwAgAGkAdABlAG0ADQBQAGwAYQBjAGUAIABWAGkAYQAgAGgAZQBhAGQAZQBy ACAAaABpAGQAaQBuAGcAIABhAG4AZAAgAFIAZQBjAG8AcgBkAC0AUgBvAHUAdABlAC8AUgBv AHUAdABlACAAaABpAGQAaQBuAGcAIABpAG4AdABvACAAcwB0AGEAbgBkAGEAbABvAG4AZQAg AEkALQBEAAAAoQ9uAAAALAAAAAAAAAAAAEUAAAABAAAAAAAUAAAAAAAAAAAAVgAAAAEAAAAA ACEAAAAAAAAABQAAAAEAAACBAAYAAAAAAAAAQwAAAAAAAgAYAAIAAAAAAAAAFAAAAAAAAABV AAAAAAACABgAAQAAAAAAAAAAAKoPPgAAACYAAAAAAAAABAAAAAEAAAADAB8AAAAAAAAABAAA AAEAAAADACIAAAAAAAAAAQAAAAEAAAAAAGsAAAAAAAAAAADqAwAAAAAAAHIXCAAAAAEAEAAP XgAAAAD1DxwAAAALAQAAkg4AA+tdAACtbQAAAQAAABgAAAAHACcwDwDoA4IPAAABAOkDKAAA AIAWAADgEAAA4BAAAIAWAAAFAAAACgAAAAAAAAAAAAAAAQAAAAAAAAEPAPIDIAIAAC8AyA8M AAAAMADSDwQAAAAAAAAADwDVB3wBAAAAALcPRAAAAFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBv AG0AYQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAYSEAC3D0QAAABB AHIAaQBhAGwAIABCAGwAYQBjAGsAAABtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBYtGIACAAA AFi0YgCKiQowAAAGIiAAtw9EAAAAVABhAGgAbwBtAGEAAABsAGEAYwBrAAAAbQBhAG4AAAAM tmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABiIwALcPRAAAAE0AbwBuAG8AdAB5 AHAAZQAgAFMAbwByAHQAcwAAAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAC AAYCQAC3D0QAAABBAHIAaQBhAGwAAABwAGUAIABTAG8AcgB0AHMAAAAAAAy2YgAMtmIANLRi AASJCjBYtGIACAAAAFi0YgCKiQowAAAGIgAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD/ /T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAA AAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAP AAsEuAIAAA8AAPCwAgAAAAAG8IABAAACwAAALwAAAFsAAAAGAAAAAAAAAAcAAAADAAAABgAA AAAAAACWAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAABgAAAEUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAEIAAAAAAAAANgAAAAAAAAAEAAAAAAAA AAQAAAACAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAPQAAAAAAAAAEAAAAAAAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAABQAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAE AAAAAAAAAAgAAAAAAAAACAAAAAAAAAACAAAAAAAAAAYAAAAAAAAACwAAAAAAAAALAAAAAQAA AAgAAAAEAAAACAAAAAAAAAAEAAAAAAAAAAQAAABfAAHw3AAAAAIAB/AkAAAAAAAAAAAAAAAA AAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAF4BAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ AAAAAAAAAAAAAAAAAAAAXgECAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAA AAAAAABeAQIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAF4BYgAH 8CQAAAAGBhHuxBfJvyhhPojfwyv4Diz/AA8NAAACAAAAAAAAAAAAXgFjAAvwJAAAAIEBBAAA CIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAA EB8A8A84AAAAAADzAxQAAAAXAAAABAAAAAAAAAAFAACAAAAAAAAA8wMUAAAAGAAAAAQAAAAA AAAABgAAgAAAAAAPANAHEwEAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAADYAAABkAAAA NgAAAGQAAABktGIAiokKMFy0YgAIAAAAZhIAAMAJAADi/P//sv///wEAAABwAPsDCAAAAAAA AABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIAAAAfAAgE PAAAAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAAAy2YgAMtmIAAQAAAAAAAABmEgAAXAoAAAAA AAAAAAAAAAD//x8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAADLZiAAy2YgABAAAA AAAAAMQRAABcCgAAAAAAAAAAAAAAAP//PwDZDwwAAAAAANoPBAAAAAAAJQAPAPAP6wgAAAAA 8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPHgAAAFNJUCBSZWNv cmQtUm91dGUvUm91dGUgSGlkaW5nCwAAqg8SAAAAHgAAAAAAAAABAAAAAQAAAAAAEACfDwQA AAAFAAAAAACoDzIAAABCcnlhbiBKLiBCeWVybHkNRGF2aWQgRGFpa2VyDVNoYWlsYW5kcmEg QmhhdG5hZ2FyDQAAqg8cAAAAFgAAAAAAAAAcAAAAAQAAAAMAAQAAAAEAAAAAAAAA8wMUAAAA EAAAAAAAAAACAAAADwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFgAAAFByb2JsZW0gYW5kIE9i amVjdGl2ZXMQAJ8PBAAAAAEAAAAAAKAPVAMAAFAAcgBvAGIAbABlAG0ADQBWAGkAYQAsACAA UgBlAGMAbwByAGQALQBSAG8AdQB0AGUALAAgAGEAbgBkACAAUgBvAHUAdABlACAAaABlAGEA ZABlAHIAcwAgAGwAZQBhAGsAIAByAG8AdQB0AGUAIAAoAGEAbgBkACAAdABoAHUAcwAgAGwA bwBjAGEAdABpAG8AbgApACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuAC4ADQBVAHMAZQByACAA QwBvAG4AYwBlAHIAbgBzAA0AQQBuAG8AbgB5AG0AaQB0AHkALAAgAFAAcgBpAHYAYQBjAHkA IAAoAHAAcgBlAHYAZQBuAHQAIABoAGEAcgByAGEAcwBzAG0AZQBuAHQAKQANAFMAZQByAHYA aQBjAGUAIABQAHIAbwB2AGkAZABlAHIAIABDAG8AbgBjAGUAcgBuAHMADQBSAGUAcwB0AHIA aQBjAHQAIABnAGEAdABoAGUAcgBpAG4AZwAgAG8AZgAgAGkAbgBmAG8AcgBtAGEAdABpAG8A bgAgAGEAYgBvAHUAdAAgAG4AZQB0AHcAbwByAGsADQBlAGcALgAgAHIAZQBzAHQAcgBpAGMA dAAgAEkAQwBNAFAAIAByAGUAcwBwAG8AbgBzAGUAIAAoAGYAbwByACAAdAByAGEAYwBlAHIA bwB1AHQAZQApAA0AQQBwAHAAcgBvAGEAYwBoAA0AQgBpAGQAaQByAGUAYwB0AGkAbwBuAGEA bAAgAHAAcgBvAHQAZQBjAHQAaQBvAG4AIABvAGYAIAByAG8AdQB0AGUAIABpAG4AZgBvAHIA bQBhAHQAaQBvAG4ADQBFAGEAYwBoACAAcAByAG8AeAB5ACAAaQBzACAAcgBlAHMAcABvAG4A cwBpAGIAbABlACAAZgBvAHIAIABlAG4AYwByAHkAcAB0AGkAbgBnACAAcgBvAHUAdABlACAA aQBuAGYAbwByAG0AYQB0AGkAbwBuACAAYQBiAG8AdQB0ACAAHCBwAHIAZQB2AGkAbwB1AHMA IABoAG8AcAAdIC4ADQBFAGEAYwBoACAAcAByAG8AeAB5ACAAaABhAHMAIABzAHkAbQBtAGUA dAByAGkAYwAgAGsAZQB5AAAAoQ/sAAAACAAAAAAAAAAAAFEAAAABAAAAAAAOAAAAAAAAAAAA KQAAAAEAAAAAABoAAAAAAAAAAAAwAAAAAQAAAAAALAAAAAIAAAAAAAkAAAAAAAAAAACcAAAA AQAAAAAABwAAAAAAAgAYAAEAAAAAAAAAUAAAAAAAAgASAAEAAAAAAAIAFAANAAAAAAACABgA AQAAAAAAAAAoAAAAAAACABIAAQAAAAAAAAAZAAAAAAACABgAAQAAAAAAAgAcADAAAAAAAAIA EgAsAAAAAAACABIACQAAAAAAAgAYAA0AAAABAAIAgQASAI8AAAAAAAIAEgAAAKoPUAAAAIIA AAAAAAAADAAAAAEAAAADAEsAAAAAAAAAAwAAAAEAAAADAB0AAAAAAAAACwAAAAEAAAADAAsA AAAAAAAADQAAAAEAAAADAI8AAAAAAAAAAADzAxQAAAAKAAAABAAAAAIAAAAFAQAAAAAAAAAA nw8EAAAAAAAAAAAAqA8aAAAAUmVjb3JkLVJvdXRlIGhlYWRlciBoaWRpbmcQAJ8PBAAAAAEA AAAAAKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAAA0AAAAAAAAAAgAAAAsBAAAAAAAAAACfDwQA AAAAAAAAAACoDxcAAABBbHRlcm5hdGl2ZXMgYW5kIEZ1dHVyZRAAnw8EAAAAAQAAAAAAoA+y AQAAQQBsAHQAZQByAG4AYQB0AGkAdgBlADoAIABQAGwAYQBjAGUAIAByAG8AdQB0AGUAIABp AG4AZgBvACAAaQBuACAAUwB0AGEAdABlACAAaABkAHIALgANAEkAbgB0AGUAcgBvAHAAZQBy AGEAYgBpAGwAaQB0AHkAIABwAHIAbwBiAGwAZQBtACAAdwBpAHQAaAAgAFUAQQBzACAAdABo AGEAdAAgAGQAbwBuABkgdAAgAHMAdQBwAHAAbwByAHQAIABTAHQAYQB0AGUAIABoAGUAYQBk AGUAcgAuAA0ADQBQAHIAbwBwAG8AcwBlAGQAIABuAGUAeAB0ACAAcwB0AGUAcABzAA0AUwBJ AFAAIABXAEcAIABpAHQAZQBtAA0AUABsAGEAYwBlACAAVgBpAGEAIABoAGUAYQBkAGUAcgAg AGgAaQBkAGkAbgBnACAAYQBuAGQAIABSAGUAYwBvAHIAZAAtAFIAbwB1AHQAZQAvAFIAbwB1 AHQAZQAgAGgAaQBkAGkAbgBnACAAaQBuAHQAbwAgAHMAdABhAG4AZABhAGwAbwBuAGUAIABJ AC0ARAAAAKEPbgAAACwAAAAAAAAAAABEAAAAAQAAAAAAFAAAAAAAAAAAAFYAAAABAAAAAAAh AAAAAAAAAAUAAAABAAAAgQAGAAAAAAAAAEMAAAAAAAIAGAABAAAAAAAAABQAAAAAAAAAVQAA AAAAAgAYAAEAAAAAAAAAAACqDywAAAAmAAAAAAAAAAQAAAABAAAAAwAfAAAAAAAAAAQAAAAB AAAAAwCNAAAAAAAAAAAA6gMAAAAAAAByFwgAAAABABAA4W0AAAAA9Q8cAAAACwEAAJIOAAO9 bQAAa30AAAEAAAAYAAAABwAnMA8A6AOCDwAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAA AAoAAAAAAAAAAAAAAAEAAAAAAAABDwDyAyACAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1Qd8 AQAAAAC3D0SBAAAAggAAAIMAAACEAAAAhQAAAIYAAAD+//////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////wAAAFQAaQBtAGUAcwAgAE4AZQB3 ACAAUgBvAG0AYQBuAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRiAIqJCjAAAAYSEAC3 D0QAAABBAHIAaQBhAGwAIABCAGwAYQBjAGsAAABtAGEAbgAAAAy2YgAMtmIANLRiAASJCjBY tGIACAAAAFi0YgCKiQowAAAGIiAAtw9EAAAAVABhAGgAbwBtAGEAAABsAGEAYwBrAAAAbQBh AG4AAAAMtmIADLZiADS0YgAEiQowWLRiAAgAAABYtGIAiokKMAAABiIwALcPRAAAAE0AbwBu AG8AdAB5AHAAZQAgAFMAbwByAHQAcwAAAAAADLZiAAy2YgA0tGIABIkKMFi0YgAIAAAAWLRi AIqJCjACAAYCQAC3D0QAAABBAHIAaQBhAGwAAABwAGUAIABTAG8AcgB0AHMAAAAAAAy2YgAM tmIANLRiAASJCjBYtGIACAAAAFi0YgCKiQowAAAGIgAAqQ8KAAAABwAAAAIACQQAAEAAow9u AAAABQD//T8AAAAiIAAAZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA//// ////GAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASA BAAAAAAPAAsEuAIAAA8AAPCwAgAAAAAG8IABAAACwAAALwAAAFsAAAAGAAAAAAAAAAcAAAAD AAAABgAAAAAAAACWAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAABgAAAEUAAAAAAAAABAAAAAAAAAAEAAAAAAAAAEIAAAAAAAAANgAAAAAAAAAE AAAAAAAAAAQAAAACAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAAPQAAAAAAAAAEAAAAAAAA AAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAABQAAAAQAAAAA AAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAAAQAAAAAAAAABAAA AAAAAAAEAAAAAAAAAAgAAAAAAAAACAAAAAAAAAACAAAAAAAAAAYAAAAAAAAACwAAAAAAAAAL AAAAAQAAAAgAAAAEAAAACAAAAAAAAAAEAAAAAAAAAAQAAABfAAHw3AAAAAIAB/AkAAAAAAAA AAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAF4BAgAH8CQAAAAAAAAAAAAAAAAAAAAA AAAAAAD/AAAAAAAAAAAAAAAAAAAAXgECAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAA AAAAAAAAAAAAAABeAQIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAA AF4BYgAH8CQAAAAGBhHuxBfJvyhhPojfwyv4Diz/AA8NAAACAAAAAAAAAAAAXgFjAAvwJAAA AIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgC AAAI9wAAEB8A8A84AAAAAADzAxQAAAAXAAAABAAAAAAAAAAFAACAAAAAAAAA8wMUAAAAGAAA AAQAAAAAAAAABgAAgAAAAAAPANAHEwEAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAADYA AABkAAAANgAAAGQAAABktGIAiokKMFy0YgAIAAAAZhIAAMAJAADi/P//sv///wEAAABwAPsD CAAAAAAAAABwCAAAcAD7AwgAAAABAAAAQAsAAB8A/wMUAAAAAgAABAwAAAAAAAAAAAAAAAIA AAAfAAgEPAAAAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAAAy2YgAMtmIAAQAAAAAAAABmEgAA XAoAAAAAAAAAAAAAAAD//x8ABwQ8AAAAAAD9AzQAAAAhAAAAZAAAACEAAABkAAAADLZiAAy2 YgABAAAAAAAAAMQRAABcCgAAAAAAAAAAAAAAAP//PwDZDwwAAAAAANoPBAAAAAAAJQAPAPAP 6wgAAAAA8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPHgAAAFNJ UCBSZWNvcmQtUm91dGUvUm91dGUgSGlkaW5nCwAAqg8SAAAAHgAAAAAAAAABAAAAAQAAAAAA EACfDwQAAAAFAAAAAACoDzIAAABCcnlhbiBKLiBCeWVybHkNRGF2aWQgRGFpa2VyDVNoYWls YW5kcmEgQmhhdG5hZ2FyDQAAqg8cAAAAFgAAAAAAAAAcAAAAAQAAAAMAAQAAAAEAAAAAAAAA 8wMUAAAAEAAAAAAAAAACAAAADwEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPFgAAAFByb2JsZW0g YW5kIE9iamVjdGl2ZXMQAJ8PBAAAAAEAAAAAAKAPVAMAAFAAcgBvAGIAbABlAG0ADQBWAGkA YQAsACAAUgBlAGMAbwByAGQALQBSAG8AdQB0AGUALAAgAGEAbgBkACAAUgBvAHUAdABlACAA aABlAGEAZABlAHIAcwAgAGwAZQBhAGsAIAByAG8AdQB0AGUAIAAoAGEAbgBkACAAdABoAHUA cwAgAGwAbwBjAGEAdABpAG8AbgApACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuAC4ADQBVAHMA ZQByACAAQwBvAG4AYwBlAHIAbgBzAA0AQQBuAG8AbgB5AG0AaQB0AHkALAAgAFAAcgBpAHYA YQBjAHkAIAAoAHAAcgBlAHYAZQBuAHQAIABoAGEAcgByAGEAcwBzAG0AZQBuAHQAKQANAFMA ZQByAHYAaQBjAGUAIABQAHIAbwB2AGkAZABlAHIAIABDAG8AbgBjAGUAcgBuAHMADQBSAGUA cwB0AHIAaQBjAHQAIABnAGEAdABoAGUAcgBpAG4AZwAgAG8AZgAgAGkAbgBmAG8AcgBtAGEA dABpAG8AbgAgAGEAYgBvAHUAdAAgAG4AZQB0AHcAbwByAGsADQBlAGcALgAgAHIAZQBzAHQA cgBpAGMAdAAgAEkAQwBNAFAAIAByAGUAcwBwAG8AbgBzAGUAIAAoAGYAbwByACAAdAByAGEA YwBlAHIAbwB1AHQAZQApAA0AQQBwAHAAcgBvAGEAYwBoAA0AQgBpAGQAaQByAGUAYwB0AGkA bwBuAGEAbAAgAHAAcgBvAHQAZQBjAHQAaQBvAG4AIABvAGYAIAByAG8AdQB0AGUAIABpAG4A ZgBvAHIAbQBhAHQAaQBvAG4ADQBFAGEAYwBoACAAcAByAG8AeAB5ACAAaQBzACAAcgBlAHMA cABvAG4AcwBpAGIAbABlACAAZgBvAHIAIABlAG4AYwByAHkAcAB0AGkAbgBnACAAcgBvAHUA dABlACAAaQBuAGYAbwByAG0AYQB0AGkAbwBuACAAYQBiAG8AdQB0ACAAHCBwAHIAZQB2AGkA bwB1AHMAIABoAG8AcAAdIC4ADQBFAGEAYwBoACAAcAByAG8AeAB5ACAAaABhAHMAIABzAHkA bQBtAGUAdAByAGkAYwAgAGsAZQB5AAAAoQ/sAAAACAAAAAAAAAAAAFEAAAABAAAAAAAOAAAA AAAAAAAAKQAAAAEAAAAAABoAAAAAAAAAAAAwAAAAAQAAAAAALAAAAAIAAAAAAAkAAAAAAAAA AACcAAAAAQAAAAAABwAAAAAAAgAYAAEAAAAAAAAAUAAAAAAAAgASAAEAAAAAAAIAFAANAAAA AAACABgAAQAAAAAAAAAoAAAAAAACABIAAQAAAAAAAAAZAAAAAAACABgAAQAAAAAAAgAcADAA AAAAAAIAEgAsAAAAAAACABIACQAAAAAAAgAYAA0AAAABAAIAgQASAI8AAAAAAAIAEgAAAKoP UAAAAIIAAAAAAAAADAAAAAEAAAADAEsAAAAAAAAAAwAAAAEAAAADAB0AAAAAAAAACwAAAAEA AAADAAsAAAAAAAAADQAAAAEAAAADAI8AAAAAAAAAAADzAxQAAAAKAAAABAAAAAIAAAAFAQAA AAAAAAAAnw8EAAAAAAAAAAAAqA8aAAAAUmVjb3JkLVJvdXRlIGhlYWRlciBoaWRpbmcQAJ8P BAAAAAEAAAAAAKoPCgAAAAEAAAABAAAAAAAAAPMDFAAAAA0AAAAAAAAAAgAAAAsBAAAAAAAA AACfDwQAAAAAAAAAAACoDxcAAABBbHRlcm5hdGl2ZXMgYW5kIEZ1dHVyZRAAnw8EAAAAAQAA AAAAoA+yAQAAQQBsAHQAZQByAG4AYQB0AGkAdgBlADoAIABQAGwAYQBjAGUAIAByAG8AdQB0 AGUAIABpAG4AZgBvACAAaQBuACAAUwB0AGEAdABlACAAaABkAHIALgANAEkAbgB0AGUAcgBv AHAAZQByAGEAYgBpAGwAaQB0AHkAIABwAHIAbwBiAGwAZQBtACAAdwBpAHQAaAAgAFUAQQBz ACAAdABoAGEAdAAgAGQAbwBuABkgdAAgAHMAdQBwAHAAbwByAHQAIABTAHQAYQB0AGUAIABo AGUAYQBkAGUAcgAuAA0ADQBQAHIAbwBwAG8AcwBlAGQAIABuAGUAeAB0ACAAcwB0AGUAcABz AA0AUwBJAFAAIABXAEcAIABpAHQAZQBtAA0AUABsAGEAYwBlACAAVgBpAGEAIABoAGUAYQBk AGUAcgAgAGgAaQBkAGkAbgBnACAAYQBuAGQAIABSAGUAYwBvAHIAZAAtAFIAbwB1AHQAZQAv AFIAbwB1AHQAZQAgAGgAaQBkAGkAbgBnACAAaQBuAHQAbwAgAHMAdABhAG4AZABhAGwAbwBu AGUAIABJAC0ARAAAAKEPbgAAACwAAAAAAAAAAABEAAAAAQAAAAAAFAAAAAAAAAAAAFYAAAAB AAAAAAAhAAAAAAAAAAUAAAABAAAAgQAGAAAAAAAAAEMAAAAAAAIAGAABAAAAAAAAABQAAAAA AAAAVQAAAAAAAgAYAAEAAAAAAAAAAACqDywAAAAmAAAAAAAAAAQAAAABAAAAAwAfAAAAAAAA AAQAAAABAAAAAwCNAAAAAAAAAAAA6gMAAAAAAAByFwgAAAABABAAn30AAAAA9Q8cAAAACwEA AJIOAAN7fQAAKY0AAAEAAAAYAAAABwAnMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --------------C01569BE03E8D00BE28611F5-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 9 22:49:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00019 for ; Sat, 9 Dec 2000 22:49:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CDF344343; Sat, 9 Dec 2000 21:49:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id 4779B44336 for ; Sat, 9 Dec 2000 21:48:52 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Sat, 9 Dec 2000 22:46:36 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sat, 9 Dec 2000 22:46:38 -0500 Message-ID: <28560036253BD41191A10000F8BCBD110316FFEE@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: sip@lists.bell-labs.com Cc: Dean Willis MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0625B.CBF12B60" X-Orig: Subject: [SIP] SIP List Thread Summary, 17-23 September Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 9 Dec 2000 22:46:36 -0500 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_01C0625B.CBF12B60 Content-Type: text/plain; charset="iso-8859-1" Some discussion items below. 9/17/2000 Thread: a query.......... Rahul Pande had a query for which he had received no answer on the confctrl list, on where to find documentation for the grammar of IANA-registered SDP attributes and on the intent of the sdplang attribute. Jonathan answered his questions. No action. 9/18/2000 Thread: words of 2543. Farhan mused on the density of the specification and called for more-easily-understood public-source implementations and detailed textbooks on SIP implementation. Action: ... 9/18/2000 Thread: H.323 international conference. Advertising. No action. 9/18/2000 Thread: Question concerning SIP/ISUP interworking. Anna Simpson asked why, in draft-camarillo-sip-isup-bcp-00.txt, release cause 31, normal unspecified is mapped to the SIP response 404, Not found. Gonzalo Camarillo showed how that had been reached by a process of elimination, but suggested that 480 Temporarily Unavailable might be better. The context is a call outgoing to the PSTN where the gateway has provide a response indicating that the PSTN responded to the IAM with a Release. Further discussion indicated that this would happen under abnormal circumstances, particularly where an exchange originating a tone or announcement timed out. Action: check to see if 404 changed to 480 in latest issue of the draft. 9/18/2000 Thread: Which Proxies should be stateful. Anoop Tripathi postulated a situation where a would-be stateless proxy has to communicate with a proxy that insists on communicating over TCP. He asked whether the first proxy could stay stateless under these circumstances. Hisham Khartabil resolved the paradox by pointing out that all proxies must support UDP. Thus the first proxy could remain stateless, while the second proxy could be stateful if it wanted, but could not enforce TCP. Pathangi Janardhanan muddied the waters by pointing out that proxies also had to support TCP, so the first proxy could be forced to be transaction stateful if some other proxy contacted it via TCP. Jo Hornsby commented that the cited text was inconsistent with recent discussion and suggested modified text for 1.5.2 and A.1. In a slight diversion, Ford Trueman asked when a proxy should be stateful and when not and Jonathan described some of the design considerations. ACTION: establish whether Jo Hornsby's proposals (message of 9/19/2000 9:33 am GMT) represent consensus and if so, update 2543bis. 9/18/2000 Thread: Do Requests using record-route always go over UDP. Anoop Tripathi asked whether requests using Record-Route must always pass over UDP because there is no way to specify otherwise in the Record-Route. Pathangi Janardhanan pointed out that the UA can use whichever transport it wishes, since the proxy is obligated to support both. No action. 9/18/2000 Thread: draft-ietf-sip-cc-transfer-01. Robert Sparks announced an update of the draft and listed the major changes. - Cliff Harris observed that a note on the use of Accept-Contact to steer the INVITE to the right party had not made it into the draft. - Subramania Sivaram asked if transfer could not be achieved more directly, by the control introducing the other two parties to each other, rather than via REFER. Robert Sparks pointed out that this would direct media flows properly, but leave the controller in the signalling realtionship. Moreover, one of the exchanges would require delayed media specification (no SDP in the INVITE, SDP in the ACK). Action: none. The note on use of Accept-Contact appears in transfer-02. I accidentally captured the following thread while following through the preceding one. The issues raised may need further discussion. 8/22/2000 Thread: draft-ietf-sip-cc-transfer-00 comments and questions. - Brett Tate listed a number of open issues he felt the draft should address, and proposed a Pending Invite indication to supplement the process. Jonathan suggested that by leaving the REFER and the session within it is sent unrelated, many of the interactions Brett was suggesting can be avoided. - Brett responded by asking how the target of the INVITE knows how to interpret the incoming call request, whether as call transfer, multiparty call, or unrelated new call. Jonathan suggested presenting the call to the user to decide. Rohan Mahy repeated Brett's question more succinctly. Jonathan responded that the REPLACES functionality (one of the alternatives) is complex and needs more work. Moreover, it is up to the 2543bis draft to describe what it means to receive a call from a different party but with the same Call-Id as an existing call. - Rohan Mahy expressed disagreement with Jonathan's proposal that reuse of Call-Id indicates new party to an existing call. He was also concerned that common Call-Id means common session description, something that won't necessarily be true in these cases. He suggested that there needed to be a way to link multiple calls with multiple Call-Ids. - Tom Taylor reported that he had been designing call flows using REFER and incorporating the assumption that if the target recognizes a matching Call-Id, it should anticipate that the new call will replace an old one and therefore not automatically give it busy treatment. Rohan Mahy asked if the assumption then was that the calls were mixed/joined in the interim. Tom responded that he put a branch on hold if necessary, to avoid the need for mixing. ACTION: resolve meaning of Call-Id reuse. Agree on whether intent of INVITE is left to the target user to resolve. 9/18/2000 Thread: A question on forwarding INVITES. M. Ranganathan asked if a proxy forwarding a request needed to have a registration from the next-hop server. He also asked if there was a perceived need and agreed method for passing registration information between proxies. Jonathan replied with respect to the first question, that routing is a matter of local policy, and registration was not a necessary condition. On the second point, he didn't think propagation of registrations was a good idea, both on grounds of scalability and because of the implication that proxies might be bypassed through use of the propagated infformation. Ranga accepted these answers and followed up with a question on routing procedure, to the effect that routing would be more efficient if the originator talked to the location server rather than leaving it to a proxy. Jo Hornsby responded with modifications to the suggested routing procedure based on the thought that Ranga had unnecessarily separated the registration database from the location server, but concluded with the thought that there are many ways to set up routing. Jonathan noted that routing procedures should take account of which domain owns the namespace of the Request-URI, and also noted the processing required if a Route header is present. No action. 9/18/2000 Thread: Overlap dialing in SIP. Aseem Agarwal asked how additional digits could be provided if an INVITE cannot be issued before the initial one receives a final response. He also wondered if a re-INVITE to change session parameters is an exception to that rule. Pathangi Janardhanan referred him to draft-camarillo-sip-isup-bcp-00.txt for call flows showing the correct handling of overlap dialling. He confirmed that in all cases re-INVITE can only be issued after the first INVITE transaction is completed. - Tom Taylor questioned this, pointing out a need for redirection while ringing is in progress in the blind call transfer case. No action on the original query. Call transfer issue may be resolved through discussion related to 8/22/2000 thread: draft-ietf-sip-cc-transfer-00 comments and questions. 9/18/2000 Thread: register method and cseq. Jean-Francois Mule noted a discrepancy in the handling of CSeq in draft-ietf-sip-call-flows-01.txt, where registration followed by keepalive is illustrated. Jonathan agreed that the illustrated call flow needed to be corrected. ACTION: verify that CSeq is corrected at indicated points in reissue of sip-call-flows. 9/18/2000 Thread: SIP conference. Nishith Chudasama asked how the members of a multiparty conference are made aware of each other in SIP. Junyoung Heo expressed the view that this is out of scope for SIP. He described how his own MCU-based implementation worked, based on dissemination of "o=" information from SDP. He could see RTP doing the job in multicast conferences. No action. 9/19/2000 Thread: syntax clarifications in the bis-draft-02. Ashok Roy noted that the grammar allows Alert-Info, Call-Info, and Error-Info to have no content and questioned this. He also noted a section heading duplication. Henning responded that permitting empty headers promotes robustness. He had a fix for the duplicate section heading. Ashok questioned whether the permitted empty header policy should be made consistent over all headers. ACTION: verify editorial update in 2543bis-03. Complete discussion on whether empty headers are allowed only for specific headers or for all headers. 9/19/2000 Thread: Modify media during a call. Francois-Xavier Guitton asked whether it was possible to change codecs in mid-call. Pathangi Janardhanan Referred him to section B.5 for an example, and suggested that instead of direct replacement in the single m= line there should be a deletion in a first m= line followed by a second m= line giving the new codec. Jonathan indicated that Francois-Xavier's original suggestion was acceptable, that in general it was permissible to change anything but the medium in a given m= line. No action. 9/19/2000 Thread: Call-ID in Two-party Call example. Stefan Runeson noted an example in chapter 16.3 of 2543bis where the Call-Id changes from the third response onward, and asked if this was correct behaviour. Neil Deason responded that the Call-Id should stay the same throughout the call. Henning said he had fixed the typo. ACTION: verify fix in next draft release. 9/19/2000 Thread: clarification o 302 message content. Commenting on 2543bis-01, Sunitha Kumar noted that section 7.3.3 talks (in the recursion case) about the UAC adding a branch to a new request, keeping CSeq the same, and wondered whether this was correct or an action reserved to proxies in forking situations. She also noted that the specification did not mandate an increase of CSeq for a re-INVITE where all other fields are kept the same, though this is shown in an example where no branch parameter is added. The general question was one of consistent treatment. Jonathan responded that a proxy and a UA look the same to the outside world, so he saw no reason to limit the UA's actions. He agreed that the text should describe the CSeq case Sunitha had noted. Further, the procedures around the cited example should be restricted to simplify things. ACTION: someone to create the necessary text. 9/19/2000 Thread: draft-ietf-sip-mib-01: Why no response counters per method? Brett Tate asked why this was the case. Kevin Lingle responded that this was partly oversight and partly a view that more aggregate statistics are sufficient. Brett suggested specific examples of why such counters might be wanted. ACTION: further discussion? 9/19/2000 Thread: Methods in Allow header. Billy Biggs asked about the need to include ACK, CANCEL and BYE methods in the ALLOW header in minimal implementations. Jonathan responded that it didn't matter much in practice, but to be consistent, all methods supported by the server should be listed. No action. 9/20/2000 Thread: IPv6 addresses in SIP. Pekka Pessi proposed that, looking forward, IPv6 addresses should be allowed in any parameter, but that this poses parsing problems. He presented three possible solutions, including redefinition of token. Ashok Roy proposed a less problematic variation of this last which would have the effect of restricting IPv6 addresses to parameters, but Pekka felt this might be too restrictive. ACTION: need to close off this issue. 9/20/2000 Thread: A Clarification. Prashant Murthy noted a discrepancy in the classification of the Www-Authenticate and Authorization sub-headings between the notes on Henning's SIP page and 2543bis-01. Jonathan noted that this raised the issue of challenge-response authentication of responses and expressed his doubt that that was workable. Response signing, on the other hand, is important. Brian Rosen saw a potential need for responder challenge, but was willing to back if if it proved too difficult. Jonathan noted that the responder is already protected by the standard request authentication procedure. The problem is in thinking of a proxy challenging the UAS for credentials for a response. He suggested that a UAS signature on the response is sufficient. ACTION: assuming Jonathan's view is consensus, follow through in 2543bis and the SIP page notes. 9/20/2000 Thread: question on receiving multiple invites. Pathangi Janardhanan asked if, when a UAS receives multiple INVITEs due to forking, it should respond 200 OK to the second INVITE and add a branch parameter. Jo Hornsby referred Jana to a link on Jonathan's SIP page which discusses request merging, and expressed his preference for one of the alternatives presented there which does not require the UAS to add a branch parameter. Further discussion led to the suggestion that a text change is needed in section 1.4.5. Henning proposed new text. ACTION: confirm new text in next update of 2543bis. 9/20/2000 Thread: About via-receieved: Bodgey asked whether every proxy is responsible for checking the address in the top-most Via header field, and how this could be done. Kundan Singh indicated use of the appropriate socket library call and possibly a DNS lookup. Vijay Gurbani provide more details on the library calls and suggested that the procedure is so easy he would expect pretty well every implementation to do it. 9/20/2000 Thread: Content-Disposition Header questions. Sudipto Mukherjee sought clarification on the use of the different possible values of the disposition-type parameter in Content-Disposition. Jonathan agreed with his interpretation of the "alert" value for early media, but expressed some confusion over the precise intent. He noted a need for the "manyfolks" resource draft to define its own value rather than use "session". Henning noted that he had had in mind that "alerting" meant that the body contained the actual content to be played out, and "session" would cover the alternative where the body contains a session description for the early media. He saw no need for a value to specifically indicate "early media", since the 183 response code does that. Sudipto wodered in the "manyfolks" case whether the presence of "a=qos:" attributes in the body would be enough to qualify "session", so that a new value is unnecessary. Jonathan invoked a general that something that affects SIP signalling should be carried in SIP headers. ACTION: Henning to clarify text for "alerting". "Manyfolks" has already provided a new value for its own use. 9/21/2000 Thread: Post-SRV Request-URI (was - [[SIP] A question about Request-URI:]). The earlier thread included a question on whether the Request-URI should be changed following a SRV record lookup, to reflect the outcome of the lookup. Jo Hornsby maintained the original Request-URI should in general be retained, because rewriting it could result in a fatal loss of information. Similarly, the entire Request-URI in a Route header is copied without modification to reflect the results of a SRV lookup. Jonathan concurred, stating that conceptually, SRV lookup follows URI construction. No action. 9/21/2000 Thread: Record-Route and port. Jo Hornsby noted that in constructing a Record-Route, 2543bis fails to mention that the entity's port should be part of the information copied. ACTION: update 2543bis. 9/21/2000 Thread: More problems with SRV. James Undery reported an argument to the effect that if SRV is not mandatory it is useless, specifically if servers listen on a port other than 5060. Henning responded that making SRV mandatory might be acceptable, but few servers weill use a port different from 5060 in practice. James responded that the problem is with proxies, particularly one adding itself to a route. One of the potential problems is when the same device supports multiple SIP servers such as an outbound proxy and a specialized service proxy. Hisham Khartabil suggested that the address placed into a Record-Route includes exact location and port, so a SRV lookup will be unnecessary. Routing would use an ordinary A query. Jo Hornsby disagreed, maintaining that normal 1.4.2 procedures should be followed. He was concerned that only 12 out of 50+ implementations at the last interop could do SRV, and suggested that for the next bakeoff each implementation should have its own domain so this could be tested. Igor Slepchin addressed James Undery's concern about being able to reach the right SIP server instance on a device by pointing out that mutiple SIP proxy instances on a device, Record-Route, and load-sharing will not all happen together, with the result that the proxies pointed to by SRV can all use port 5060. Apparently this closed the topic: no action. 9/22/2000 Thread: RE: [Test Bed Technical Forum:] Determining the length of the SIP message body. Duke Snyder posed questions about how to determine the length of the SIP message body in various cases, if Content-Length is absent. Jo Hornsby responded, beginning with the observation that 2543bis has now made the Content-Length header mandatory. Jonathan pointed out that, contrary to the supposition in Duke's inquiry, RFC 2543 does not mandate the use of Content-Length with TCP. Instead, the message body continues until the connection is closed. No action. Tom Taylor +1 613 736 0961 taylor@nortelnetworks.com ------_=_NextPart_001_01C0625B.CBF12B60 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable SIP List Thread Summary, 17-23 September

Some discussion items below.

9/17/2000 Thread: a query..........  Rahul Pande = had a query for which he had received no answer on the confctrl list, = on where to find documentation for the grammar of IANA-registered SDP = attributes and on the intent of the sdplang attribute.  Jonathan = answered his questions.  No action.

9/18/2000 Thread: words of 2543.  Farhan mused = on the density of the specification and called for = more-easily-understood public-source implementations and detailed = textbooks on SIP implementation.  Action: ...

9/18/2000 Thread: H.323 international = conference.  Advertising.  No action.

9/18/2000 Thread: Question concerning SIP/ISUP = interworking.  Anna Simpson asked why, in = draft-camarillo-sip-isup-bcp-00.txt, release cause 31, normal = unspecified is mapped to the SIP response 404, Not found.  Gonzalo = Camarillo showed how that had been reached by a process of elimination, = but suggested that 480 Temporarily Unavailable might be better.  = The context is a call outgoing to the PSTN where the gateway has = provide a response indicating that the PSTN responded to the IAM with a = Release.  Further discussion indicated that this would happen = under abnormal circumstances, particularly where an exchange = originating a tone or announcement timed out.  Action: check to = see if 404 changed to 480 in latest issue of the draft.

9/18/2000 Thread: Which Proxies should be = stateful.  Anoop Tripathi postulated a situation where a would-be = stateless proxy has to communicate with a proxy that insists on = communicating over TCP.  He asked whether the first proxy could = stay stateless under these circumstances.  Hisham Khartabil = resolved the paradox by pointing out that all proxies must support = UDP.  Thus the first proxy could remain stateless, while the = second proxy could be stateful if it wanted, but could not enforce = TCP.  Pathangi Janardhanan muddied the waters by pointing out that = proxies also had to support TCP, so the first proxy could be forced to = be transaction stateful if some other proxy contacted it via TCP.  = Jo Hornsby commented that the cited text was inconsistent with recent = discussion and suggested modified text for 1.5.2 and A.1.  In a = slight diversion, Ford Trueman asked when a proxy should be stateful = and when not and Jonathan described some of the design = considerations.  ACTION: establish whether Jo Hornsby's proposals = (message of 9/19/2000 9:33 am GMT) represent consensus and if so, = update 2543bis.

9/18/2000 Thread: Do Requests using record-route = always go over UDP.  Anoop Tripathi asked whether requests using = Record-Route must always pass over UDP because there is no way to = specify otherwise in the Record-Route.  Pathangi Janardhanan = pointed out that the UA can use whichever transport it wishes, since = the proxy is obligated to support both.  No action.

9/18/2000 Thread: = draft-ietf-sip-cc-transfer-01.  Robert Sparks announced an update = of the draft and listed the major changes.

-  Cliff Harris observed that a note on the use = of Accept-Contact to steer the INVITE to the right party had not made = it into the draft.

-  Subramania Sivaram asked if transfer could = not be achieved more directly, by the control introducing the other two = parties to each other, rather than via REFER.  Robert Sparks = pointed out that this would direct media flows properly, but leave the = controller in the signalling realtionship.  Moreover, one of the = exchanges would require delayed media specification (no SDP in the = INVITE, SDP in the ACK).

Action: none.  The note on use of Accept-Contact = appears in transfer-02.

I accidentally captured the following thread while = following through the preceding one.  The issues raised may need = further discussion.

8/22/2000 Thread: draft-ietf-sip-cc-transfer-00 = comments and questions.
-  Brett Tate listed a number of open issues he = felt the draft should address, and proposed a Pending Invite indication = to supplement the process.  Jonathan suggested that by leaving the = REFER and the session within it is sent unrelated, many of the = interactions Brett was suggesting can be avoided.

-  Brett responded by asking how the target of = the INVITE knows how to interpret the incoming call request, whether as = call transfer, multiparty call, or unrelated new call.  Jonathan = suggested presenting the call to the user to decide.  Rohan Mahy = repeated Brett's question more succinctly.  Jonathan responded = that the REPLACES functionality (one of the alternatives) is complex = and needs more work.  Moreover, it is up to the 2543bis draft to = describe what it means to receive a call from a different party but = with the same Call-Id as an existing call.

-  Rohan Mahy expressed disagreement with = Jonathan's proposal that reuse of Call-Id indicates new party to an = existing call.  He was also concerned that common Call-Id means = common session description, something that won't necessarily be true in = these cases.  He suggested that there needed to be a way to link = multiple calls with multiple Call-Ids.

-  Tom Taylor reported that he had been = designing call flows using REFER and incorporating the assumption that = if the target recognizes a matching Call-Id, it should anticipate that = the new call will replace an old one and therefore not automatically = give it busy treatment.  Rohan Mahy asked if the assumption then = was that the calls were mixed/joined in the interim.  Tom = responded that he put a branch on hold if necessary, to avoid the need = for mixing.

ACTION: resolve meaning of Call-Id reuse.  Agree = on whether intent of INVITE is left to the target user to = resolve.

9/18/2000 Thread: A question on forwarding = INVITES.  M. Ranganathan asked if a proxy forwarding a request = needed to have a registration from the next-hop server.  He also = asked if there was a perceived need and agreed method for passing = registration information between proxies.  Jonathan replied with = respect to the first question, that routing is a matter of local = policy, and registration was not a necessary condition.  On the = second point, he didn't think propagation of registrations was a good = idea, both on grounds of scalability and because of the implication = that proxies might be bypassed through use of the propagated = infformation.  Ranga accepted these answers and followed up with a = question on routing procedure, to the effect that routing would be more = efficient if the originator talked to the location server rather than = leaving it to a proxy.  Jo Hornsby responded with modifications to = the suggested routing procedure based on the thought that Ranga had = unnecessarily separated the registration database from the location = server, but concluded with the thought that there are many ways to set = up routing.  Jonathan noted that routing procedures should take = account of which domain owns the namespace of the Request-URI, and also = noted the processing required if a Route header is present.  No = action.

9/18/2000 Thread: Overlap dialing in SIP.  Aseem = Agarwal asked how additional digits could be provided if an INVITE = cannot be issued before the initial one receives a final = response.  He also wondered if a re-INVITE to change session = parameters is an exception to that rule.  Pathangi Janardhanan = referred him to draft-camarillo-sip-isup-bcp-00.txt for call flows = showing the correct handling of overlap dialling.  He confirmed = that in all cases re-INVITE can only be issued after the first INVITE = transaction is completed.

-  Tom Taylor questioned this, pointing out a = need for redirection while ringing is in progress in the blind call = transfer case. 

No action on the original query.  Call transfer = issue may be resolved through discussion related to 8/22/2000 thread: = draft-ietf-sip-cc-transfer-00 comments and questions.

9/18/2000 Thread: register method and cseq.  = Jean-Francois Mule noted a discrepancy in the handling of CSeq in = draft-ietf-sip-call-flows-01.txt, where registration followed by = keepalive is illustrated.  Jonathan agreed that the illustrated = call flow needed to be corrected.  ACTION: verify that CSeq is = corrected at indicated points in reissue of sip-call-flows.

9/18/2000 Thread: SIP conference.  Nishith = Chudasama asked how the members of a multiparty conference are made = aware of each other in SIP.  Junyoung Heo expressed the view that = this is out of scope for SIP.  He described how his own MCU-based = implementation worked, based on dissemination of "o=3D" = information from SDP.  He could see RTP doing the job in multicast = conferences.  No action.

9/19/2000 Thread: syntax clarifications in the = bis-draft-02.  Ashok Roy noted that the grammar allows Alert-Info, = Call-Info, and Error-Info to have no content and questioned this.  = He also noted a section heading duplication.  Henning responded = that permitting empty headers promotes robustness.  He had a fix = for the duplicate section heading.  Ashok questioned whether the = permitted empty header policy should be made consistent over all = headers.  ACTION: verify editorial update in 2543bis-03.  = Complete discussion on whether empty headers are allowed only for = specific headers or for all headers.

9/19/2000 Thread: Modify media during a call.  = Francois-Xavier Guitton asked whether it was possible to change codecs = in mid-call.   Pathangi Janardhanan Referred him to section = B.5 for an example, and suggested that instead of direct replacement in = the single m=3D line there  should be a deletion in a first m=3D = line followed by a second m=3D line giving the new codec.  = Jonathan indicated that Francois-Xavier's original suggestion was = acceptable, that in general it was permissible to change anything but = the medium in a given m=3D line.  No action.

9/19/2000 Thread: Call-ID in Two-party Call = example.  Stefan Runeson noted an example in chapter 16.3 of = 2543bis where the Call-Id changes from the third response onward, and = asked if this was correct behaviour.  Neil Deason responded that = the Call-Id should stay the same throughout the call.  Henning = said he had fixed the typo.  ACTION: verify fix in next draft = release.

9/19/2000 Thread: clarification o 302 message = content.  Commenting on 2543bis-01, Sunitha Kumar noted that = section 7.3.3 talks (in the recursion case) about the UAC adding a = branch to a new request, keeping CSeq the same, and wondered whether = this was correct or an action reserved to proxies in forking = situations.  She also noted that the specification did not mandate = an increase of CSeq for a re-INVITE where all other fields are kept the = same, though this is shown in an example where no branch parameter is = added.  The general question was one of consistent = treatment.  Jonathan responded that a proxy and a UA look the same = to the outside world, so he saw no reason to limit the UA's = actions.  He agreed that the text should describe the CSeq case = Sunitha had noted.  Further, the procedures around the cited = example should be restricted to simplify things.  ACTION: someone = to create the necessary text.

9/19/2000 Thread: draft-ietf-sip-mib-01: Why no = response counters per method?  Brett Tate asked why this was the = case.  Kevin Lingle responded that this was partly oversight and = partly a view that more aggregate statistics are sufficient.  = Brett suggested specific examples of why such counters might be = wanted.  ACTION: further discussion?

9/19/2000 Thread:  Methods in Allow = header.  Billy Biggs asked about the need to include ACK, CANCEL = and BYE methods in the ALLOW header in minimal implementations.  = Jonathan responded that it didn't matter much in practice, but to be = consistent, all methods supported by the server should be listed.  = No action.

9/20/2000 Thread: IPv6 addresses in SIP.  Pekka = Pessi proposed that, looking forward, IPv6 addresses should be allowed = in any parameter, but that this poses parsing problems.  He = presented three possible solutions, including redefinition of = token.  Ashok Roy proposed a less problematic variation of this = last which would have the effect of restricting IPv6 addresses to = parameters, but Pekka felt this might be too restrictive.  ACTION: = need to close off this issue.

9/20/2000 Thread: A Clarification.  Prashant = Murthy noted a discrepancy in the classification of the = Www-Authenticate and Authorization sub-headings between the notes on = Henning's SIP page and 2543bis-01.  Jonathan noted that this = raised the issue of challenge-response authentication of responses and = expressed his doubt that that was workable.  Response signing, on = the other hand, is important.  Brian Rosen saw a potential need = for responder challenge, but was willing to back if if it proved too = difficult.  Jonathan noted that the responder is already protected = by the standard request authentication procedure.  The problem is = in thinking of a proxy challenging the UAS for credentials for a = response.  He suggested that a UAS signature on the response is = sufficient.  ACTION: assuming Jonathan's view is consensus, follow = through in 2543bis and the SIP page notes.

9/20/2000 Thread: question on receiving multiple = invites.  Pathangi Janardhanan asked if, when a UAS receives = multiple INVITEs due to forking, it should respond 200 OK to the second = INVITE and add a branch parameter.  Jo Hornsby referred Jana to a = link on Jonathan's SIP page which discusses request merging, and = expressed his preference for one of the alternatives presented there = which does not require the UAS to add a branch parameter.  Further = discussion led to the suggestion that a text change is needed in = section 1.4.5.  Henning proposed new text.  ACTION: confirm = new text in next update of 2543bis.

9/20/2000 Thread: About via-receieved:  Bodgey = asked whether every proxy is responsible for checking the address in = the top-most Via header field, and how this could be done.  Kundan = Singh indicated use of the appropriate socket library call and possibly = a DNS lookup.  Vijay  Gurbani provide more details on the = library calls and suggested that the procedure is so easy he would = expect pretty well every implementation to do it.

9/20/2000 Thread: Content-Disposition Header = questions.  Sudipto Mukherjee sought clarification on the use of = the different possible values of the disposition-type parameter in = Content-Disposition.  Jonathan agreed with his interpretation of = the "alert" value for early media, but expressed some = confusion over the precise intent.  He noted a need for the = "manyfolks" resource draft to define its own value rather = than use "session".  Henning noted that he had had in = mind that "alerting" meant that the body contained the actual = content to be played out, and "session" would cover the = alternative where the body contains a session description for the early = media.  He saw no need for a value to specifically indicate = "early media", since the 183 response code does that.  = Sudipto wodered in the "manyfolks" case whether the presence = of "a=3Dqos:" attributes in the body would be enough to = qualify "session", so that a new value is unnecessary.  = Jonathan invoked a general that something that affects SIP signalling = should be carried in SIP headers.  ACTION: Henning to clarify text = for "alerting".  "Manyfolks" has already = provided a new value for its own use.

9/21/2000 Thread: Post-SRV Request-URI (was - [[SIP] = A question about Request-URI:]).  The earlier thread included a = question on whether the Request-URI should be changed following a SRV = record lookup, to reflect the outcome of the lookup.  Jo Hornsby = maintained the original Request-URI should in general be retained, = because rewriting it could result in a fatal loss of information.  = Similarly, the entire Request-URI in a Route header is copied without = modification to reflect the results of a SRV lookup.  Jonathan = concurred, stating that conceptually, SRV lookup follows URI = construction.  No action.

9/21/2000 Thread: Record-Route and port.  Jo = Hornsby noted that in constructing a Record-Route, 2543bis fails to = mention that the entity's port should be part of the information = copied.  ACTION: update 2543bis.

9/21/2000 Thread: More problems with SRV.  James = Undery reported an argument to the effect that if SRV is not mandatory = it is useless, specifically if servers listen on a port other than = 5060.  Henning responded that making SRV mandatory might be = acceptable, but few servers weill use a port different from 5060 in = practice.  James responded that the problem is with proxies, = particularly one adding itself to a route.  One of the potential = problems is when the same device supports multiple SIP servers such as = an outbound proxy and a specialized service proxy.  Hisham = Khartabil suggested that the address placed into a Record-Route = includes exact location and port, so a SRV lookup will be = unnecessary.  Routing would use an ordinary A query.  Jo = Hornsby disagreed, maintaining that normal 1.4.2 procedures should be = followed.  He was concerned that only 12 out of 50+ = implementations at the last interop could do SRV, and suggested that = for the next bakeoff each implementation should have its own domain so = this could be tested.  Igor Slepchin addressed James Undery's = concern about being able to reach the right SIP server instance on a = device by pointing out that mutiple SIP proxy instances on a device, = Record-Route, and load-sharing will not all happen together, with the = result that the proxies pointed to by SRV can all use port 5060.  = Apparently this closed the topic: no action.

9/22/2000 Thread: RE: [Test Bed Technical Forum:] = Determining the length of the  SIP message body.  Duke Snyder = posed questions about how to determine the length of the SIP message = body in various cases, if Content-Length is absent.  Jo Hornsby = responded, beginning with the observation that 2543bis has now made the = Content-Length header mandatory.  Jonathan pointed out that, = contrary to the supposition in Duke's inquiry, RFC 2543 does not = mandate the use of Content-Length with TCP.  Instead, the message = body continues until the connection is closed.  No = action.



Tom Taylor
+1 613 736 0961
taylor@nortelnetworks.com

------_=_NextPart_001_01C0625B.CBF12B60-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 01:44:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA27921 for ; Sun, 10 Dec 2000 01:44:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B7D5144337; Sun, 10 Dec 2000 00:44:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id A879544336 for ; Sun, 10 Dec 2000 00:43:45 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eBA6j1V07427; Sun, 10 Dec 2000 12:15:01 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eBA6qck07507; Sun, 10 Dec 2000 12:22:44 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652569B1.00252EE5 ; Sun, 10 Dec 2000 12:16:08 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jonathan Rosenberg Cc: archow@hss.hns.com, sip@lists.bell-labs.com Message-ID: <652569B1.00252D82.00@sampark.hss.hns.com> Subject: RE: [SIP] query on forking. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 12:16:04 +0530 Jonathan, I was thinking of something simpler like adding a caller-callee preferences token asking the forker to return all responses (or maybe in require). How about that ? Regds Arjun Jonathan Rosenberg on 12/10/2000 03:42:59 AM To: archow, sip@lists.bell-labs.com cc: Subject: RE: [SIP] query on forking. Reach all is not supported through the existing forking mechanism. You will need to do something like fully-distributed multiparty conferencing, TBD. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: archow@hss.hns.com [mailto:archow@hss.hns.com] > Sent: Wednesday, December 06, 2000 12:42 AM > To: sip@lists.bell-labs.com > Subject: [SIP] query on forking. > > > > > Hi, > assume I want to set up a chat with a group called "all-boys". > My proxy server knows who all are in "all-boys" , I dont. > so I send a message: > > MESSAGE sip:all-boys@hss.hns.com > > > and the server forks this to > > sip:boy1@hss.hns.com > sip:boy2@hss.hns.com > > Typically, if say boy1 returned OK and boy2 some 4xx message, > the forking > proxy would only send > me the 200 OK. (best response) > > However I want to receive both success and failure. That is, > I want to > know if boy2 returned fail . > This may be necessary when I am sending a group request to > people and my > intent is not a "reach first" but > a "reach all". If I know boy2 failed, I might use another > means to send him > the same message. > Note that I do not want to broadcast or multicast. > > so my question is: is there any way to use a forking service > here and have > it return all responses and not > only the "best" responses ? > > I noticed the recurse tag in caller and callee preferences - > but that only > seems to take care of either replying recursively to 300 > class messages or sending them back to the caller. > > Regds > Arjun > > -- > Arjun Roychowdhury @ Hughes Software Systems > > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 03:49:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA16631 for ; Sun, 10 Dec 2000 03:49:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4259644337; Sun, 10 Dec 2000 02:49:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id 650D044336 for ; Sun, 10 Dec 2000 02:48:41 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sun, 10 Dec 2000 02:48:30 -0600 (CST) From: Billy Biggs To: archow@hss.hns.com Cc: Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] query on forking. Message-ID: <20001210024830.A8417@div8.net> References: <652569B1.00252D82.00@sampark.hss.hns.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <652569B1.00252D82.00@sampark.hss.hns.com>; from archow@hss.hns.com on Sun, Dec 10, 2000 at 12:16:04PM +0530 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 02:48:30 -0600 archow@hss.hns.com (archow@hss.hns.com): > I was thinking of something simpler like adding a caller-callee > preferences token asking the forker to return all responses (or maybe > in require). How about that ? You want to receive ALL responses to a transaction? Uh-oh. This will never work for non-INVITE transactions since there is no mechanism to reliably transmit multiple responses. Too bad. You're not much better off for INVITE transactions. First you need a parameter to indicate you require this behavior. Next, all proxies along the path MUST (proxy-require'd) send some special response code signaling to the previous hop that all branches have been checked: otherwise there would be no way for anyone to know when to clean up transaction state. UAs would need to send this special code as well, sending two responses to the INVITE (require'd). All of these responses would require unique To tags. Wow, that's alot of work. There is no simple way to solve this problem at the SIP layer. Use the user's or group's presence information instead. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 10:55:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA17138 for ; Sun, 10 Dec 2000 10:55:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A50A844337; Sun, 10 Dec 2000 09:55:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from austinit00.austin.polycom.com (austinit00.austin.polycom.com [216.54.148.225]) by lists.bell-labs.com (Postfix) with ESMTP id BE94944336 for ; Sat, 9 Dec 2000 19:32:48 -0500 (EST) Received: by austinit00.austin.polycom.com with Internet Mail Service (5.5.2653.19) id ; Sat, 9 Dec 2000 19:32:17 -0600 Message-ID: <38C2271BB6BDD411902B00A024D3D2ED2C0968@austinit00.austin.polycom.com> From: "Narayanan, Balaji" To: "'SIP List '" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C06249.081DCFC0" Subject: [SIP] List Thread Summary - Nov 26 - Dec 2 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 9 Dec 2000 19:32:17 -0600 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_01C06249.081DCFC0 Content-Type: text/plain; charset="iso-8859-1" See Attachment Thanks, balaji ------_=_NextPart_000_01C06249.081DCFC0 Content-Type: application/octet-stream; name="Summary Nov26-Dec 2.txt" Content-Disposition: attachment; filename="Summary Nov26-Dec 2.txt" Content-Transfer-Encoding: quoted-printable 11/26/2000: Thread: Sending Binary Data:=20 In SIPForum, Naresh Kumar Agarwal asked that whether binary data can be = sent=20 in SIP. - Jonathan suggested that SIP related questions be posted on the SIP = mailing=20 list NOT SIPForum and clarified that SIP can carry pure binary. Resolved. 11/26/2000: Thread: Queries:=20 In SIPForum, Naresh Kumar Agarwal asked following questions. 1. Is it = possible=20 with in SIP framework for a redirect server to send back some data to = the=20 client, which the client doesn't need to interpret but simply need to = pass the=20 information along to a proxy server. 2. How to do challenge mechanism = in SIP 3.=20 SIP supports PGP. How does the called party know the key.=20 - Jonathan again noted that SIP related questions be posted on the SIP = mailing=20 list. Anwering question 1: It is possible for redirect server to send = some=20 non-standard data through encapsulating in the header to client and = client can=20 send it to the proxy server. But proxy server and redirect server = should have=20 pre-arranged mechanism to understand the data. This is a dangerous = thing to do.=20 If you need something from SIP that is not already there, you should = raise that=20 issue instead of attempting non-standard extensions. 2. Although SIP = provides=20 digest authentication, which requires a shared secret between parties, = it is=20 better to use one of the already developed key exchange protocol. 3. = See Ans 2. =20 Resolved. 11/27/2000: Thread: SIP Security Abstract:=20 Tom Tang initiated the discussion on security for SIP. He posted a = small=20 abstract on problem statement for security. There was no other = follow-up=20 discussion on this thread. Not resolved.=20 11/27/2000: Thread: Session Progress:=20 Baniel Uri brought up an issue that in the bis 4.2.1, it is said that = UAC should=20 be ready receive the RTP data (according to SDP) as soon as it sends = the invite=20 request. But in 183 draft says, two way path needs to be established = before UAC=20 starts receiving data from UAS. Question: Why is the two way path need = to be=20 established for sending RTP information from UAS to UAC.=20 - Henning replied that 183 draft is not valid anymore, it may be fold = in to main=20 spec. The question whether "Early media is undesirable and should be = abolished"=20 needs to be resolved in the IETF Meeting.=20 - Jonathan seconded Henning that this issue needs to be discussed in = IETF=20 meeting. Not resolved. To be discussed in the IETF meeting. 11/27/2000: Thread: 305 Reponse, What For?=20 Emami-Nouri, Mohsen suggested that 305 response is not necessary and = 301 & 302=20 can cover the 305 Response.=20 - Billy Biggs responded that the wording implies that if you get a 305 = you=20 should send only that specific request through the proxy. Future = requests=20 within the call-leg should instead be directed at the old Contact = address. He=20 added that he thinks most implementers treat all 3xx responses almost=20 identically. Resolved. 11/27/2000: Thread: Many folks Draft Question:=20 Ameet Kher requested a clarification on the latest many folks draft: = For a UAS=20 with no qos capability, should a comet be sent out by the UAS? =20 - Bill Marshall responded that qos capable UAS responses are detailed = in the=20 section 4.2. If the UAS is not qos capable, it responds with no qos in = the SDP.=20 Call proceeds in best effort. Resolved. 11/28/2000:Thread: Multiple SDP bodies in a SIP Message:=20 Subhas Nayak asked whether it is possible to have multiple SDP messages = in a SIP=20 request ?=20 - Jonathan replied that multiple SDP is not used in SIP. Only one SDP = is=20 allowed. He said he will make a note to add this point to the RFC. Resolved. Note to be added in RFC. 11/28/2000:Thread: call-flow; each user has 2 UAs:=20 Joshua Fox wanted to know what happens in a scenario when 2 UA s are in = each=20 endpoint dealing with two different media types communicating with one = another. - Billy Biggs answered with an illustration that this type of scenarios = can be=20 handled with 3pcc. Or with another app which monitors these two UA s. Resolved. 11/28/2000: Thread: JAIN SIP Factory: Chris Harris suggested that having all the create methods for all the = messages=20 and headers in the JainSipFactory could be a problem and it can be too=20 restrictive for an implementer. So it is better to define the create = methods in=20 the interfaces rather than JainSipFactory Class. Further he suggested = that=20 reflections and exceptions be used on the input parameters to the = interfaces to=20 differentiate between different implementations of JAIN SIP interfaces = in an=20 application. He noted that public review period for JAIN SIP spec = closes today. - M.Ranganathan largely agreed with his proposal. Resolved. 11/28/2000: Thread: Multiple Transaction Refer Billy Biggs had the following proposal to solve failure of single = transaction=20 REFER. REFER looks the same, but it is responded with a 2xx if the far = end=20 accepts the REFER and intends to act upon it. A REFERDONE request which = signals=20 back that the spawned INVITE completed. Success or failure is = indicated in=20 some header (or in the body?). This request requires a header, = Refer-CSeq or=20 similar, to indicate which REFER transaction is being completed. - Robert Sparks suggested that REFER (non-invite msg) does not have a = timeout=20 value defined by the protocol. (referring section 10.4.2., 10.4.1). Why = can't we=20 define a larger time-out value. - Billy Biggs replied that it is not good have transactions hanging for = a long=20 time. If half-a-minute is not enough, it is better to have multiple = transaction. Not resolved. No Conclusion. 11/28/2000: I-D ACTION:draft-hamer-sip-session-auth-00.txt submitted by = Louis- Nicolas Hamer - Henry Sinnriech noted that (on page 9) 1. The service provider and = access=20 provider DO NOT NEED to be the same. 2. He also did not agree with the = draft=20 conclusion that it is not feasible to provision each network host with = fixed=20 routers and proxy servers. 3. He also did not agree to the draft = proposal to=20 extend RSVP, COPS/DIAMETER and SDP. 4. He also raised some concerns = about the=20 terminology like Bearer and Control. =20 - Louis-Nicolas Hamer - 1.Agreed 2. In a wireless network, if the host = is=20 moving, it is not possible to have same fixed edge router. 3. He = intends to=20 extend RSVP, COPS and SDP to accommodate the ticket concept used in = mobile=20 network. 4. OK with some agreeable terminology. Resolved/ Not Resolved. Both of them agreed to resolve their issues in = the bar =20 since there is not enough time address these issues in the meeting. 11/28/2000: JAIN SIP - Issues to be resolved M.Rangathan: suggested that 1. whenever there is more than one header = to be=20 returned, it is better to return a vector than an array. 2. By letting = receiver=20 check for the validity of sent headers, we can cut down lots of setxxx = API=20 messages in the JAIN SIP Spec. 3. Parser should return portions of = header which=20 it cannot parser. This point will be moot if point 2 is accepted. Not resolved. No further discussion. 11/29/2000: I-D ACTION:draft-ietf-sip-session-timer-04.txt was posted 11/29/2000: I-D ACTION:draft-ietf-sip-call-flows-02.txt was posted 11/29/2000: Threads: REFER for Remote Device Control:/ Music on Hold in = ietf- sip-service-examples-00 - Billy Biggs objected to the sip-peer-3pcc draft way of providing = PHONECTL=20 functionality using REFER. He said it is out side the scope of REFER = and the=20 meaning of the request is hidden in URI and it does not provide enough = info to=20 identify the call leg. He is planning to rewrite the PHONECTL draft by = this=20 week. - Rohan Mahy asked Billy Biggs to show some example where the = Request-URI, To, From, and Call-ID aren't sufficient to identify the call.=20 Billy Biggs sited the Music on-Hold call flow scenarios from = sip-service- examples draft and said the method=3DBye in the REFER is insufficient = to indicate=20 the UA which call should be disconnected.=20 - After numerous emails discussing this issue, Jonathan noted that SIP = is a poor=20 control protocol and should not be used as such. We should add text to = REFER=20 about the requirement and non-requirements of processing REFER at the = endpoint. - Rohan Mahy disagreed and said that REFER with some additional = semantics is=20 good enough for (Billy's requirement) the job.=20 - Henry Sinnreich agreed with Rohan Mahy and observed that device = control=20 protocols like H.248 are poor engineering option.=20 Not resolved. 11/29/2000: Thread: Processing BYE request at Proxy Dongsung Kim had these following 2 queries: 1. If a proxy forks a = INVITE=20 downstream and the BYE response has lower Cseq than the INVITE request, = what is=20 should the proxy do ? 2. Is it possible for a proxy to generate a = response to a=20 BYE request under special cases ? =20 - Jonathan replied as follows: 1. the proxy will proxy the BYE request as normal. The request is rejected by the UA. The response is forwarded = by the proxy. 2. No. Proxies do not respond to requests. If a BYE is sent, = it is=20 forwarded. If there is a Route header, its used. If not, its forked.=20 Resolved.=20 11/29/2000 WG Last Call for draft-ietf-sip-guidelines-00.txt=20 Dean Willis posted this. Jonathan corrected it is = draft-ietf-sip-guidelines- 01.txt and it will be treated as BCP. 11/29/200 WG Last Call on Caller Preferences posted by Dean Willis 11/30/2000 as if there wasn't enough traffic on this darn list... Jonathan Rosenberg proposed that if we drop the SDP in ACK and SDP in = PRACK, it=20 will keep SIP simple and solve lots of confusion. Brett Tate noted that Broadsoft sends SDP in ACK for re-INVITE to avoid = getting=20 into SDP-Change-Loop discussed in "[SIP] 3PCC and the re-invite = response". - Dave Oran noted that it is simple and better to let SDP in any leg of = an=20 INVITE transaction and just use most recent SDP sent or received.=20 - Vladislav Zubarev noted that there are already applications = implemented the=20 SDP in ACK scheme: Ex: H.323-Sip Gateways. So he suggested that we = continue to=20 support this and recommend using reINVITE in future. - Bryan Byerly noted that there are two commercial implementations of = assured=20 QoS using SDPs in PRACK. He suggested Jonathan's view is unwarranted=20 restriction. - Arjun Roychowdhury expressed concern that J's proposal will break = H.323-SIP=20 gateway although he has no objection to no SDP in PRACK proposal. - Finally, Jonathan Rosenberg observed that the proposal is dead. Main = reason=20 being there are many commercial implementation of SDP in ACK available = already. Resolved. 11/30/2000: Thread: 3PCC and the re-invite response / Thread: Re: No = SDP =3D> take=20 off hold? - Gethin Liddell was concerned that according to 3PCC draft, it is = possible for=20 a USER to change its SDP in the re-INVITE response, which will cause=20 inconsistency in the overall session set-up. - After numerous emails on this issue, Jonathan expressed this final = following=20 opinion: I think this thread, and several others, all relate to one = central=20 problem: we need a general way of describing SDP processing in UAs; how = to=20 determine what the "current" set of SDP is, and how one creates a = response to an=20 offered SDP. With a general algorithm in place for that, these problems = would go=20 away. I hope to cover some of these issues at the meeting. Not resolved. Jonathan will raise the issue in the meeting. 11/30/2000: Thread: Single Line Extension work Dean Willis brought up this issue to check whether this issue still = open.=20 - Brain Rosen notes that he was suppose to be working on this issue. = Unless=20 there is a draft, which explains the issue and a proposal to solve the = problem,=20 this issue is not a active WG item. Resolved for now. 11/30/2000: Thread: Questions on = draft-rosenberg-sip-app-components-00.txt Alan Johnston asked following 3 questions on the draft: 1. On page 16, = section=20 5.4, referring to Figure 3, should the SDP in re-INVITE look different? = 2. In=20 Figure 5, the IVR call flow shows RTP flow before 200 OK. In PSTN, any = packets=20 before call completion will be dropped. 3. In Figure 9, the Web Enabled = Message=20 Drops call flow, how the Web Caller's SIP URL is sent to the = Controller, since=20 the Controller initiates the INVITE (3). - Bert Culpepper replied , Answer for 1: I believe the authors leave it = to the=20 reader to decide how to build the SDP component to specify the desired = media=20 destinations. Using your example a complete media description will be = as=20 follows.=20 m=3Daudio 5004 RTP/AVP 0 m=3Daudio 53000 RTP/AVP 96 c=3DIN IP4 200.201.202.203 a=3Drtpmap:96 telephone-event The above indicates a different destination for the second media=20 stream according to RFC 2327 (SDP). Resolved - Q1=20 Not resolved - Q2,Q3=20 =20 =20 ------_=_NextPart_000_01C06249.081DCFC0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 18:43:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA08643 for ; Sun, 10 Dec 2000 18:43:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6FA4844337; Sun, 10 Dec 2000 17:43:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id AB7D644336 for ; Sun, 10 Dec 2000 17:42:13 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA01096; Sun, 10 Dec 2000 18:44:35 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Dec 2000 18:39:49 -0500 Message-ID: From: Jonathan Rosenberg To: "Arnoud van Wijk (ELN)" , "Sip (E-mail)" Subject: RE: [SIP] multiple calls for IP telephony client MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 18:39:49 -0500 > -----Original Message----- > From: Arnoud van Wijk (ELN) [mailto:Arnoud.van.Wijk@eln.ericsson.se] > Sent: Tuesday, November 28, 2000 11:19 AM > To: Sip (E-mail) > Subject: [SIP] multiple calls for IP telephony client > > > While I was thinking about functionality of the User Agents > for IP telephony. I got myself tangled in the following: > > A call is one or more sessions ----> no problem, all sessions > have the same Call_ID > This means that if A initiates a call, and B receives the > call and B will then add 2 minutes later another session (a > text session for relay purposes or a seperate video stream), > it will be considered to be the same call? Yes. It would be a re-INVITE with the same call-id. > I know that SIP > can just do this within the same call_ID via a re-invite. > But if B wants the text stream or video stream > But if B's session is seen as a new call, does it mean that > the IP telephony client is handling 2 seperate calls? Why would the re-INVITE from B be a different call? It would be the same call. > A second question is: > Can the originator of a session be found in the re-invite? > If A calls B with session 1 and B comes then with session 2, > the re-invite (adding session 2 to session 1) has then from: > B@buffy.com? > even that originally the invite (session 1) was reading from: > A@Angel.com (A started the call)? > I do believe so. The From field is always the identity of the originator of the request. So, if A reinvites B, the From field would have A. If B reinvites A, the from field has B. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 18:45:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09078 for ; Sun, 10 Dec 2000 18:45:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 02D2144355; Sun, 10 Dec 2000 17:43:27 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 52CB944336 for ; Sun, 10 Dec 2000 17:42:14 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA01090; Sun, 10 Dec 2000 18:44:35 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Dec 2000 18:39:49 -0500 Message-ID: From: Jonathan Rosenberg To: Rohan Mahy , Billy Biggs , Alan Johnston Cc: Robert Sparks , SIP List Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 18:39:48 -0500 > -----Original Message----- > From: Rohan Mahy [mailto:rohan@cisco.com] > Sent: Wednesday, December 06, 2000 4:45 PM > To: Jonathan Rosenberg; Billy Biggs; Alan Johnston > Cc: Robert Sparks; Jonathan Rosenberg; SIP List > Subject: RE: [SIP] Music on Hold in ietf-sip-service-examples-00 > > > At 10:11 AM 12/5/00 , Jonathan Rosenberg wrote: > >Billy raises some very important issues. These are some of > the things that > >motivated a thread on the list many months back (on the road > now and can't > >dig up the reference), where we discussed adding control > functionality to > >SIP, and how this was insufficient for a full blown control > and monitoring > >protocol like megaco. > > We need to keep the distinction between MEGACO-style control, > and what we > need. > 1) SIP uses requests, which the UAS can decline. Indeed. This is precisely my point. The problem is that since REFER is just a primitive, there is no easy way for the user to determine the ultimate service being invoked. So, while the user can be queried about whether to accept a REFER request, what would a typical user respond to when asked "you are being requested to send a re-INVITE within call A to add a media line with a new address"? They'll reject it since they have no idea what it means. Any sensible UA would likely reject any REFER thats not for an IVNITE request received as part of an existing call. > We need to request that call legs move around to include > certain users. we > *don't* need to be notified when someone presses "hookflash"; and we > *don't* need to tell the UA exactly how to write something on > a display > (that may not even exist). You are oversimplifying the way in which this equates to megaco. Seems like what some people want is a signaling level control protocol. Such a protocol would not report hookflash or allow for control of displays; thats a device level control ala megaco. Signaling level control would allow me to instruct another device to send signaling messages of any type at any time. The feedback would tell me what responses were received to those requests, and what the resulting call level states where. Rohans two drafts (3pcc with REFER and feedback with 189) seem to be attempting to do exactly that. Now, my point is, that even though this control is at a higher level, its still a control protocol nonetheless. It has the same issues with transactional integrity (several REFERS may need to succeed all together) and security as megaco has. I would argue that for things like this, forking is anathema. Do you really want these REFERs to go all over the place? No. You want a direct channel, from one entity to the controlled entity. All of this is what SIP is not very good at. This is my point. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 18:47:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA09570 for ; Sun, 10 Dec 2000 18:47:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D48344358; Sun, 10 Dec 2000 17:43:43 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 7031944337 for ; Sun, 10 Dec 2000 17:42:14 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA01112; Sun, 10 Dec 2000 18:44:37 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Dec 2000 18:39:51 -0500 Message-ID: From: Jonathan Rosenberg To: Billy Biggs , "Henning G. Schulzrinne" Cc: SIP List Subject: RE: [SIP] From tags (was: I-D ACTION:draft-ietf-sip-service-examp les-00.txt) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 18:39:49 -0500 > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Monday, November 27, 2000 1:05 AM > To: Henning G. Schulzrinne > Cc: SIP List > Subject: Re: [SIP] From tags (was: I-D > ACTION:draft-ietf-sip-service-examples-00.txt) > > > Henning G. Schulzrinne (hgs@cs.columbia.edu): > > > I'm not sure, but it seems that there's a simple fix: > simply have the > > UA create *different* tags depending on whether this is for > a From or > > To. However, the tag is constant across calls and requests. > > Even safer to use "predictable-random", however: > > Choosing predictable tags does not make a UA crash-proof. The SIP > spec should not recommend any behavior on generating tags. Why not? It already does make recommendations. I think a reasonable proposal is the following (I will be discussing this at IETF): 1. if your UA is not trying to handle crash-and-recovery of calls, then your tags should be unique for each call leg 2. if your UA is trying to handle crash-and-recovery, you should generate tags with the following properties: (1) the tag is a function of the UA instance (something like SIP port and machine name) (2) you maintain two tags, one that you place in the From field, one within the To field (3) if you get a call with a new Call-ID, with a tag which is one of the two you maintain, its a call that occurred before a crash/restart. There is obviously a lot more that you need to do to build a crash-proof UA. But, we have lots of other things in the spec - guidelines, advise, etc. - that help people build reassonable UAs. I don't see this as different. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 18:50:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA10208 for ; Sun, 10 Dec 2000 18:50:24 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5115A4435E; Sun, 10 Dec 2000 17:43:58 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D77D544350 for ; Sun, 10 Dec 2000 17:42:14 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA01113; Sun, 10 Dec 2000 18:44:37 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Dec 2000 18:39:51 -0500 Message-ID: From: Jonathan Rosenberg To: Billy Biggs , Joshua_Fox@vocaltec.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] call-flow; each user has 2 UAs MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 18:39:49 -0500 I agree here with Billy that 3pcc, using a master controller above the two devices, is absolutely the right way to go. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Tuesday, November 28, 2000 9:45 AM > To: Joshua_Fox@vocaltec.com > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] call-flow; each user has 2 UAs > > > Joshua_Fox@vocaltec.com (Joshua_Fox@vocaltec.com): > > > As a simple example, say that the two medias are audio and video > > (although in real life, of course, an app/device with video > will also > > likely have audio). > > > > Jack Jill > > Audio <-------------------------------------------------> Audio > > Video <-------------------------------------------------> Video > > > > The important point is that the Audio and Video devices are NOT > > integrated and have separate UA's, yet we want all four apps/devices > > to be joined in one "session", with Jack's audio talking to Jill's > > audio, and Jack's video talking to Jill's video. Perhaps we > can assume > > that Jack's audio and video both have the same SIP URL. > > The session you describe is an abstraction layer above a > SIP session. > > I see two ways of handling this: > > Remote The first method is to have a SIP call > | SIP between the remote side and some > Master controller which communicates to the A and > / \ ? V apps and incorporates their addresses > Video Audio into a common SDP. The master can be a > 3pcc server if you use SIP to talk to A/V. > > The second method is simply to have two > Remote calls up, and use some other means of > | | SIP association higher up. This may > simply be > Video Audio Jack telling Jill about the > other session, > or some new header which flags the app > telling it to associate the two calls. > > > We need some sort of four-way session with proper use of SDP to > > distinguish media types. To add two UA's on the UAS side, we need > > forking with non-exclusive response from two UA's. We also have to > > decide how to bring in two UA's on the UAC side. > > You don't need to get so complicated. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 18:54:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11035 for ; Sun, 10 Dec 2000 18:54:23 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7ED6C44366; Sun, 10 Dec 2000 17:44:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EFAF544351 for ; Sun, 10 Dec 2000 17:42:14 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA01116; Sun, 10 Dec 2000 18:44:37 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Dec 2000 18:39:51 -0500 Message-ID: From: Jonathan Rosenberg To: Gonzalo Camarillo , Jonathan Rosenberg Cc: hgs@cs.columbia.edu, sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] RE: draft-rosenberg-sip-app-components-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 18:39:50 -0500 Long airplane rides are great for sip mailing list catch up... Comments inline: > -----Original Message----- > From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@lmf.ericsson.se] > Sent: Wednesday, November 22, 2000 12:41 PM > To: Jonathan Rosenberg > Cc: hgs@cs.columbia.edu; sip@lists.bell-labs.com > Subject: draft-rosenberg-sip-app-components-00.txt > > > Hi, > > In the draft > http://www.cs.columbia.edu/~jdrosen/papers/draft-rosenberg-sip > -app-components-00.txt > > you propose to invoke text to speech services using an INVITE with two > "m" sections. One sendonly for the text and the other recvonly for the > speech (audio). > > I see a TSS server as a particular case of a transcoder, that receives > media in one format (e.g. GSM) and converts it to another format (e.g. > PCM). > > And I see a transcoder as a particular case of a conference > until (MCU). > It just takes media from one participant and sends it to the other > (adjusting the format). > > Since conference units are usually INVITEd using one INVITE per > conference member, I think transcoder services should be > invoked in the > same way (with two INVITEs) as it is described in section 3 of: > http://search.ietf.org/internet-drafts/draft-camarillo-3pcc-qos-00.txt > > Thus, I would invoke TSS services in the same way. I would send an > INVITE with an "m"section consisting of audio and a second INVITE with > an "m" section consisting of text. The TSS server would related both > INVITEs using the Request-URI (as a conference unit does). I don't think this works. A conference is different from a TTS service. A TTS service is fundamentally two streams, and two only. Once stream comes in, gets converted, and streamed back out. The conference has many streams. If I do as you propose, and two people both INVITE the server twice for the same URI, now there are four sessions. Which ones does the server transcode, and to which other ones does it get sent? Furthermore, in all cases, accessing the service requires a single INVITE from any entity to initiate a session to it (a conference may reuqire multiple INVITEs, but each is from a single participant). By your proposal, a single entity would now require more than one, and I think its needlessly more complex. > A minor typo: in section 9 Peter Mataga seems to share > Jonathan's email > address. > Yes, I noticed that. Copy paste error. For those interested in contacting him directly, its pmataga@dynamicsoft.com. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 18:57:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11759 for ; Sun, 10 Dec 2000 18:57:44 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2DB084436C; Sun, 10 Dec 2000 17:44:28 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9432E44336 for ; Sun, 10 Dec 2000 17:42:16 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA01101; Sun, 10 Dec 2000 18:44:35 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Dec 2000 18:39:49 -0500 Message-ID: From: Jonathan Rosenberg To: Alan Johnston , Jonathan Rosenberg , Peter Mataga , Henning Schulzrinne Cc: SIP List Subject: RE: [SIP] Questions on draft-rosenberg-sip-app-components-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 18:39:49 -0500 > -----Original Message----- > From: Alan Johnston [mailto:alan.johnston@wcom.com] > Sent: Friday, December 01, 2000 11:33 PM > To: Jonathan Rosenberg; Peter Mataga; Henning Schulzrinne > Cc: SIP List > Subject: [SIP] Questions on draft-rosenberg-sip-app-components-00.txt > > > Jonathan/Peter/Henning, > > A couple of questions about some of the examples in your excellent and > informative draft. (If I could only get some of the MEGACO > proponents in > my organization to read and understand it...) Thanks! I consider this draft an important one. As applications grow more complex, and people begin to build more and more sip enabled servers, we need to have a way to talk about and understand how these all work together. > > 1. On page 16, section 5.4, referring to Figure 3, you say: > > "The next step for the AS is to get a > stream of DTMF digits to flow from the caller to the media > server. To > > do this, it sends a re-INVITE to the caller (11). This re-INVITE > contains the same SDP as the response (6) from the called > party, but > with the addition of a new media line. This media line is > audio, and > contains a single codec, the RTP payload format for DTMF and tones > [8]. The connection address and port are from the SDP returned from > the media server. This tells the caller to send an additional media > stream to the media server, using only the DTMF codec. " > > I'm not sure I understand what the SDP in the re-INVITE should look > like. Lets say the SDP in the 200 OK (6) from the Callee contained: Bert has answered this one correctly, so let me address the rest of your questions. > 2. In Figure 5, the IVR call flow shows the Callee sending > IVR commands > to the IVR Server after the receipt of the 183 Session Progress, but > before any 200 OK. I think this could be useful, but I'm wondering if > User Agents that support Early Media like this would actually send RTP > packets prior to getting a 200 OK. For example, if a Gateway to the > PSTN sends a 183 Session Progress, it may not include the a=sendonly > attribute, but any RTP packets prior to call completion in the PSTN > would be simply dropped. This all gets back to the meaning of early media, and is something I hope to discuss during IETF. The idea here is that there is nothing about the INV/183 exchange that implies unidirectional media. If we decide that this is too liberal an interpretation of early media (which it may very well be), the same flow can be accomplished using re-INVITEs. > > 3. In Figure 9, the Web Enabled Message Drops call flow, I am > trying to > decide if the first message should be a HTTP POST or a GET as it is > shown. Your description indicates that a single click activates the > service - the trigger is simply that the particular URL has been > accessed. I understand that each mailbox for each user would have a > URL. My question is how the Web Caller's SIP URL is sent to the > Controller, since the Controller initiates the INVITE (3). > Would it be > somehow imbedded as a parameter in the URL? Or, should the > message be a > POST, in which case the Web Caller would type in their SIP URL, click > the submit button, and the combination of the URL and the form data > would give the controller enough information to setup the call. There are several ways. Certainly the form post can work. Another way is that the user browsing the web page has previously signed up for this service, and during that process, gave their SIP URL. The web server returned a cookie. Upon revisiting the page, the server can determine the URL of the user from the cookie provided to the server. > Finally, one perhaps dumb question relating to this example. > If the SIP > User Agent and the HTTP Client were on the same machine, couldn't the > Web Caller just click on a link containing a SIP URL (instead > of a HTTP > URL) of the desired mailbox which would cause the caller's SIP User > Agent to simply place the call? Assuming that the call was to be made to a VoIP phone on that PC, yes. The advantage of placing the call from the controller is that the SIP URL can route to a PSTN gateway, ringing the phone of the user. Or, it can call a different VoIP client on another machine. Its a matter of flexibility. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 18:59:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA12127 for ; Sun, 10 Dec 2000 18:59:35 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C51B544372; Sun, 10 Dec 2000 17:44:42 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 73B4544336 for ; Sun, 10 Dec 2000 17:42:19 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA01109; Sun, 10 Dec 2000 18:44:36 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Dec 2000 18:39:51 -0500 Message-ID: From: Jonathan Rosenberg To: Cliff.Harris@nokia.com, "'sip@lists.bell-labs.com'" Subject: RE: [SIP] Receiving unrecognized To tags MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 18:39:50 -0500 I recognize that this thread is ancient, but I am putting together text/proposals for open issues on the list, and the issues of tags is one of them. As such, I thought it useful to answer some of these older questions based on more recent understandings. > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > Cliff.Harris@nokia.com > Sent: Wednesday, September 06, 2000 7:05 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Receiving unrecognized To tags > > > Section 7.4.18 of rfc-bis says a 481 is returned if "the > server received an > INVITE with a To tag that does not match the local tag value." > > Section 10.1.1 says, "An incoming request is accepted unless > the Call-ID > value matches an existing call and the request has a tag > value of To header > that does not match the user agent server's tag value." > > Section 11.5 says, "It is possible that the To header in an > INVITE request > has a tag, but the UAS believes this to be a new call. [...] > The UAS MAY > either accept or reject the request." > > What if a UA receives an INVITE with an unknown Call ID and > an unknown To > tag? Sections 7 and 11 would seem to imply that the INVITE > could be rejected > with a 481, and section 10 would seem to imply that a new > call leg should be > created. Which is correct? Or am I misreading something? Section 10 is incorrect. If the Call-ID is new, and the To tag exists AND is unknown, reject. If the Call-ID is new, and the To tag exists, and is a tag that the UA knows it has used for itself, it MAY either accept or reject the request. > > If a UA always uses the same tag value, shouldn't it > automatically reject > any request that has a different To tag? Yes. > On the other hand, > if a UA for some > reason generates a new tag for every call, I suppose it > wouldn't necessarily > be able to tell whether an unrecognized To tag was one that > it had in fact > previously issued. Right, in which case the call is rejected, and the UA cannot recover from crash and reboots. A perfectly acceptable thing to do if you don't care about this feature. > > Also, I'm a little confused about the forking issue. Suppose > an INVITE gets > forked to two UA's, one of which ends up as the UAS in a > lengthy call. Later > on, a re-INVITE from the UAC gets forked to the same two > UA's. To the one > that is not in the call, couldn't the wording of section 11.5 > apply, so that > the UA that is not involved in the call could reply to the > re-INVITE with a > 200 OK? I would have thought that the existence of the tag in > the INVITE > would indicate to this UA that it should not accept the INVITE. Your assessment is correct; the wording in 11.5 is wrong. The UA not in the call would reject the call, since the To tag is present and not its own. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 19:02:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA12679 for ; Sun, 10 Dec 2000 19:02:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 355854437D; Sun, 10 Dec 2000 17:44:58 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 945DB44337 for ; Sun, 10 Dec 2000 17:42:19 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA01084; Sun, 10 Dec 2000 18:44:33 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Dec 2000 18:39:47 -0500 Message-ID: From: Jonathan Rosenberg To: archow@hss.hns.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] query on forking. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 18:39:47 -0500 This is simply not going to work. It would require modification of fundamental retransmission and transaction processing in all proxies on the path. The current state machines assume only a single non-200 response is ever sent. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: archow@hss.hns.com [mailto:archow@hss.hns.com] > Sent: Sunday, December 10, 2000 1:46 AM > To: Jonathan Rosenberg > Cc: archow@hss.hns.com; sip@lists.bell-labs.com > Subject: RE: [SIP] query on forking. > > > > > Jonathan, > I was thinking of something simpler like adding a > caller-callee preferences > token asking the forker to return all responses > (or maybe in require). > How about that ? > > Regds > Arjun > > > > > > > Jonathan Rosenberg on 12/10/2000 03:42:59 AM > > To: archow, sip@lists.bell-labs.com > cc: > > Subject: RE: [SIP] query on forking. > > > > > Reach all is not supported through the existing forking mechanism. > > You will need to do something like fully-distributed multiparty > conferencing, TBD. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: archow@hss.hns.com [mailto:archow@hss.hns.com] > > Sent: Wednesday, December 06, 2000 12:42 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] query on forking. > > > > > > > > > > Hi, > > assume I want to set up a chat with a group called "all-boys". > > My proxy server knows who all are in "all-boys" , I dont. > > so I send a message: > > > > MESSAGE sip:all-boys@hss.hns.com > > > > > > and the server forks this to > > > > sip:boy1@hss.hns.com > > sip:boy2@hss.hns.com > > > > Typically, if say boy1 returned OK and boy2 some 4xx message, > > the forking > > proxy would only send > > me the 200 OK. (best response) > > > > However I want to receive both success and failure. That is, > > I want to > > know if boy2 returned fail . > > This may be necessary when I am sending a group request to > > people and my > > intent is not a "reach first" but > > a "reach all". If I know boy2 failed, I might use another > > means to send him > > the same message. > > Note that I do not want to broadcast or multicast. > > > > so my question is: is there any way to use a forking service > > here and have > > it return all responses and not > > only the "best" responses ? > > > > I noticed the recurse tag in caller and callee preferences - > > but that only > > seems to take care of either replying recursively to 300 > > class messages or sending them back to the caller. > > > > Regds > > Arjun > > > > -- > > Arjun Roychowdhury @ Hughes Software Systems > > > > > > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 19:07:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA13709 for ; Sun, 10 Dec 2000 19:07:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 26CC84438B; Sun, 10 Dec 2000 17:45:29 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 411A644336 for ; Sun, 10 Dec 2000 17:42:42 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA01086; Sun, 10 Dec 2000 18:44:33 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Dec 2000 18:39:47 -0500 Message-ID: From: Jonathan Rosenberg To: "Piotr S. Kossowski" , SIP discussion list Subject: RE: [SIP] Detecting of retransmission in the first INVITE case MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-2" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 18:39:47 -0500 > -----Original Message----- > From: Piotr S. Kossowski [mailto:P.Kossowski@elka.pw.edu.pl] > Sent: Saturday, December 09, 2000 3:58 PM > To: SIP discussion list > Subject: [SIP] Detecting of retransmission in the first INVITE case > > > Hello, > > Section 11.5 of RFC2543bis-2 says: > > "If the Call-ID exists, the request is for an existing call. > If the To, > From, Call-ID, and CSeq values exactly match (including tags) > those of any > requests received previously, the request is a retransmission." > > I am not sure whether this statament applies when we > processing the first > INVITE. The first INVITE does not include a tag. The tag is added when > response to this is created. According to 11.2: The text should be updated to say (including tags, if present). That is, the process is the same with or without tags. > > "The UAS stores the values of the To and From field, > including any tags. > These become the local and remote addresses of the call leg, > respectively." > > So, when we want to detect retransmission it will not be easy > possible, > because UAS' To header has already tag, but retransmission of > the INVITE > still does not include To's tag. You are mixing two different things. A call leg is not the same as a transaction. The call leg is idenfitied with a tag, but the transaction is identified based on the To, From, Call-ID, CSeq, R-URI and top via. (the latter two being new since rfc2543, to handle spirals and request merging, respectively). -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 19:09:47 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA14292 for ; Sun, 10 Dec 2000 19:09:46 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A23044385; Sun, 10 Dec 2000 17:45:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CBCF644336 for ; Sun, 10 Dec 2000 17:42:22 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA01092; Sun, 10 Dec 2000 18:44:35 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Dec 2000 18:39:49 -0500 Message-ID: From: Jonathan Rosenberg To: Igor Slepchin , "'Billy Biggs'" , "'Henning G. Schulzrinne'" Cc: "'SIP List'" Subject: RE: CANCEL and Record-Route; was: RE: [SIP] Re: My comments on bi s-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 18:39:48 -0500 > -----Original Message----- > From: Igor Slepchin > Sent: Tuesday, December 05, 2000 3:48 PM > To: Jonathan Rosenberg; Igor Slepchin; 'Billy Biggs'; Henning G. > Schulzrinne > Cc: SIP List > Subject: RE: CANCEL and Record-Route; was: RE: [SIP] Re: My > comments on > bis-02 > > > > > A proxy might be stateless and still record-route. Route > > > actually does make > > > sense in a CANCEL in this scenario. > > > > I think this is far more complex than it first seems. > > <...> > > A ---- P1 ----- P2 ------ P3 ------ B > > terminated by P3. So, its P1 that needs to insert Route into > > CANCEL. Where > > does this route come from? From the RR in the final response > > to INVITE? > > No, certainly not. It is taken from the request being > CANCELed. This is only useful (and only needed) for > consecutive signaling, e.g., for reINVITEs. Ah. Problem is, these are the requests least likely to be cancelled. 100% of the usage of CANCEL to date is for the original INVITE request, I would bet. > > In you scenario, stateful P1 would copy Route header from > reINVITE to CANCEL for that reINVITE. Stateless P2 would then > receive a CANCEL with the same Route as the reINVITE being > CANCELed. This will ensure that CANCEL goes to precisely the > same place as the request. Hmm. So the request arrives at P3 from stateless proxy P2. Now, the proxy after P3 is P4, but P4 didn't record route. The Route in CANCEL thus points to P5 next (since P5 did record-route). Now, based on this, P3 would forward the CANCEL to P5, since thats the one listed in the Route. But, this is wrong. The CANCEL should traverse P4 as well. > > > Adding RR to CANCEL seems a big, big departure from what we > > have been doing > > until now. I'd much rather not do this. > > This sounds more like an optimization to me. It eliminates > the (somewhat unlikely) chance that a sateless proxy would > route CANCEL differently from the request being CANCELed (due > to some time-based logic, for example). I'm not sure why this > is a huge departure from what we have now but I don't think > that this change is critically needed either. Since this is only useful for CANCELing re-INVITE, AND only when stateless proxies record-route, AND there are issues when the original INVITE path and Record-Route path are not the same, I'd prefer not do this. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 22:40:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA13711 for ; Sun, 10 Dec 2000 22:40:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2645D44353; Sun, 10 Dec 2000 21:40:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id 2116F44337 for ; Sun, 10 Dec 2000 21:39:16 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eBB3eU202460; Mon, 11 Dec 2000 09:10:30 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eBB3lqk02451; Mon, 11 Dec 2000 09:18:03 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652569B2.001442EB ; Mon, 11 Dec 2000 09:11:18 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jonathan Rosenberg , billy_biggs@3com.com Cc: archow@hss.hns.com, sip@lists.bell-labs.com Message-ID: <652569B2.00144295.00@sampark.hss.hns.com> Subject: RE: [SIP] query on forking. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 09:11:17 +0530 Jonathan/Billy, Im obviously missing something. Let me state my requirements again. 1. I want the proxy that forked to send back all final responses to me instead of the best. 2. When I say I want to receive ALL responses, of course Im not talking about a new fangled way to receive non-INVITE responses reliably. If that response gets lost and I retransmit, the case is no different from any other non INV transaction in SIP. I'm talking about an inbetween proxy forwarding that response back - thats all. This means that the only server inbetween that really has to honour my request would be a proxy that forks. Proxies that dont fork, as it is will proxy the final responses back anyway, Now come to the case of the forking proxy. Im suggesting that we add something like: Request-Disposition:all-response which is propogated to all the proxies in the path, and is processed by proxies that fork. It is possible that some proxies in between do not understand this extension of ccp. Well, in that case, either he will return an error saying he cannot handle it, or I will have to live with the possibility that someone in between may be chopping off final responses. Im ok with that. The only place I see which has to add logic is a forking proxy. And that too, its an extension. If you dont support it, return an error. Im fine with that. I dont see why it results in UAs sending special codes , or why it breaks all nodes in between. Could you sight an example as to why this would not work ? Regds Arjun Jonathan Rosenberg on 12/11/2000 05:09:47 AM To: archow cc: sip@lists.bell-labs.com Subject: RE: [SIP] query on forking. This is simply not going to work. It would require modification of fundamental retransmission and transaction processing in all proxies on the path. The current state machines assume only a single non-200 response is ever sent. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: archow@hss.hns.com [mailto:archow@hss.hns.com] > Sent: Sunday, December 10, 2000 1:46 AM > To: Jonathan Rosenberg > Cc: archow@hss.hns.com; sip@lists.bell-labs.com > Subject: RE: [SIP] query on forking. > > > > > Jonathan, > I was thinking of something simpler like adding a > caller-callee preferences > token asking the forker to return all responses > (or maybe in require). > How about that ? > > Regds > Arjun > > > > > > > Jonathan Rosenberg on 12/10/2000 03:42:59 AM > > To: archow, sip@lists.bell-labs.com > cc: > > Subject: RE: [SIP] query on forking. > > > > > Reach all is not supported through the existing forking mechanism. > > You will need to do something like fully-distributed multiparty > conferencing, TBD. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: archow@hss.hns.com [mailto:archow@hss.hns.com] > > Sent: Wednesday, December 06, 2000 12:42 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] query on forking. > > > > > > > > > > Hi, > > assume I want to set up a chat with a group called "all-boys". > > My proxy server knows who all are in "all-boys" , I dont. > > so I send a message: > > > > MESSAGE sip:all-boys@hss.hns.com > > > > > > and the server forks this to > > > > sip:boy1@hss.hns.com > > sip:boy2@hss.hns.com > > > > Typically, if say boy1 returned OK and boy2 some 4xx message, > > the forking > > proxy would only send > > me the 200 OK. (best response) > > > > However I want to receive both success and failure. That is, > > I want to > > know if boy2 returned fail . > > This may be necessary when I am sending a group request to > > people and my > > intent is not a "reach first" but > > a "reach all". If I know boy2 failed, I might use another > > means to send him > > the same message. > > Note that I do not want to broadcast or multicast. > > > > so my question is: is there any way to use a forking service > > here and have > > it return all responses and not > > only the "best" responses ? > > > > I noticed the recurse tag in caller and callee preferences - > > but that only > > seems to take care of either replying recursively to 300 > > class messages or sending them back to the caller. > > > > Regds > > Arjun > > > > -- > > Arjun Roychowdhury @ Hughes Software Systems > > > > > > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 22:59:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA15992 for ; Sun, 10 Dec 2000 22:59:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D821F44371; Sun, 10 Dec 2000 21:59:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0266644337 for ; Sun, 10 Dec 2000 21:58:03 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA01559; Sun, 10 Dec 2000 23:00:26 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Sun, 10 Dec 2000 22:55:41 -0500 Message-ID: From: Jonathan Rosenberg To: "'archow@hss.hns.com'" , billy_biggs@3com.com Cc: sip@lists.bell-labs.com Subject: RE: [SIP] query on forking. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 10 Dec 2000 22:55:40 -0500 > -----Original Message----- > From: archow@hss.hns.com [mailto:archow@hss.hns.com] > Sent: Sunday, December 10, 2000 7:41 PM > To: Jonathan Rosenberg; billy_biggs@3com.com > Cc: archow@hss.hns.com; sip@lists.bell-labs.com > Subject: RE: [SIP] query on forking. > > > > > Jonathan/Billy, > Im obviously missing something. > > Let me state my requirements again. > > 1. I want the proxy that forked to send back all final responses to me > instead of the best. > > 2. When I say I want to receive ALL responses, of course Im > not talking > about a new fangled way to receive non-INVITE > responses reliably. Of course you are. The request is non-INVITE, and you need to get the responses reliably. If that response gets lost and I > retransmit, the > case is no different from any other non INV transaction in SIP. > I'm talking about an inbetween proxy forwarding that response back - > thats all. No. It effects the basic retransmission rules for non-INVITE. You simply cannot receive more than one final response. Period. This is documented in the FAQ: http://www.cs.columbia.edu/~hgs/sip/faq/cache/91.html Its not just that one proxy, of course. The multiple responses would have to be forwarded upstream by all proxies to get back to you. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 10 23:21:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA18418 for ; Sun, 10 Dec 2000 23:21:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 59C6A44353; Sun, 10 Dec 2000 22:21:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id 9EB5544337 for ; Sun, 10 Dec 2000 22:20:32 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eBB4LmE04027; Mon, 11 Dec 2000 09:51:48 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eBB4TLk04458; Mon, 11 Dec 2000 09:59:26 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652569B2.00180F77 ; Mon, 11 Dec 2000 09:52:48 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: Jonathan Rosenberg Cc: archow@hss.hns.com, billy_biggs@3com.com, sip@lists.bell-labs.com Message-ID: <652569B2.00180E4E.00@sampark.hss.hns.com> Subject: RE: [SIP] query on forking. Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 09:52:45 +0530 > > 2. When I say I want to receive ALL responses, of course Im > not talking > about a new fangled way to receive non-INVITE > responses reliably. jdr> Of course you are. The request is non-INVITE, and you need to get the jdr> responses reliably. Agreed. Although getting response reliably was not my primary goal, I realise that this scheme will fail in it - and that is a good enough reason for not using the mechanism I was suggesting. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 01:25:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18155 for ; Mon, 11 Dec 2000 01:25:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8E794433C; Mon, 11 Dec 2000 00:25:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-131-150-91.ce.mediaone.net [24.131.150.91]) by lists.bell-labs.com (Postfix) with ESMTP id A1F894433A for ; Mon, 11 Dec 2000 00:24:11 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Mon, 11 Dec 2000 00:23:59 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Dean Willis , sip@lists.bell-labs.com Message-ID: <20001211002359.A16172@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Subject: [SIP] Thread summaries for Jul 31 - Aug 4 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 00:23:59 -0600 SIP Threads from Jul 31 - Aug 4 31 Jul 00: LDAP schema for SIP Is it worth the effort in defining a schema for SIP? Henning sees this more as an extension of an existing (person) schema than something new. 31 Jul 00: Proxy initiating a BYE 1 Aug 00: Proxy initiating a BYE - contd. Dvir Oren asks about proxies initiating a BYE. Proxies don't initiate BYEs, but B2BUAs do. No issues. 31 Jul 00: SIP Call Control Services Some questions asked, Robert Sparks notes these are resolved by the REFER draft and soon-to-be-started seperate multi-party conferencing work. 31 Jul 00: SIP-T Draft Feedback Adam Roach brings up many issues with draft-vemuri-sip-t-context-00.txt. Nothing outside of this scope. 31 Jul 00: draft-ietf-sip-session-timer-02.txt Adam Roach brings up many issues with draft-ietf-sip-session-timer-02.txt. No responses. 31 Jul 00: SIP Presence and Instant Messaging prototype Robert Sparks announces the availability of a prototype. 1 Aug 00: Change in SIP URL syntax Discussion of SIP URL syntax. Questions about whether @ signs need to be escaped in URL parameters. Resolution when Henning notes that @ is a reserved character and must be escaped. 2 Aug 00: Legal Loop Detection Hisham Khartabil brings up some text in the july 13th bis that says that a proy server must not send a request to a host already listed in the Via list, but this breaks legal loops. Jonathan Rosenberg says this text must be removed. 1 Aug 00: IMPP:Following the long WG session 2 Aug 00: a proposal for a way to compromise? (really, not a joke) Two threads on IMPP and its involvement with SIP. Neither bring up any issues with the SIP spec. 2 Aug 00: Comment on draft-moyer-sip-appliances-framework-00.txt Ben Campbell questions whether sip-appliances's RPC mechanism is appropriate for SIP. This launches into a large discussion, none of which brings up any SIP open issues. 2 Aug 00: DTMF discussion from WG meeting Rohan Mahy discusses what he brought up at the IETF about DTMF digits in SIP. Suggests using a SUBSCRIBE/NOTIFY mechanism. 2 Aug 00: TIPHON SIP presentation on-line At http://pages.hotbot.com/edu/sijben/ 2 Aug 00: Events mailing list At http://www.egroups.com/messages/sip-events 3 Aug 00: A universal problem with the t= line. Question about the t= line in SDP which only allows for 10 digits. Resolution is that nobody thinks this is a big problem. 3 Aug 00: How to locate a user? Question abotu SIP location servers. No issues. 3 Aug 00: Further queries on SIP Draft Some questions were asked about the 00 bis, all of which Henning noted as being already clarified in the 01 bis. 3 Aug 00: What do we want with SIP? Some comments about the scope of SIP. No replies and no issues. 3 Aug 00: SIP - Research Question about SIP and IP mobility research. No issues. 3 Aug 00: More inconsistencies and questions Peter Kjellerstedt brougt up some issues with bis-01. Some discussion about using the existing TCP connection for responses to transactions should be clarified in the spec. 4 Aug 00: Via header encryption and "received" parameter. Issue was brought up about hiding the via. Jonathan Rosenberg notes that this was already clarified in bis-01. 3 Aug 00: QOS and SIP Questions... Question about QOS use and SIP. No replies. 3 Aug 00 via headers required? Yes, Via is required. 4 Aug 00: SIP parser: newbie Question about using lexx/yacc with SIP. No issues. 4 Aug 00: Authorization Header in PGP Authorization = "Authorization" ":" "pgp" #pgp-response vs Authorization = "Authorization" ":" "pgp" 1#pgp-response ? Jonathan Rosenberg thinks it should be 1# 4 Aug 00: questions on SIP/SDP Some unanswered questions on how to use SDP to do various things. No replies. Compiler's note: SDP has many limitations. 4 Aug 00: received parameter is invalid Gethin Liddell notes that the proposed received=host[:port] is invalid since : is not a token. Igor asks when the [:port] thing happend, since it won't really work. Compiler's note: I think this was continued in another thread, since the [:port] thing definitely does not work. 4 Aug 00: SIP and World Domination Philosophical discussion about the scope of SIP. No issues. 4 Aug 00: Keep it simple Well deserved warning to please keep SIP simple. No issues. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 06:12:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA21594 for ; Mon, 11 Dec 2000 06:12:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9509844337; Mon, 11 Dec 2000 05:12:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id A2FE544336 for ; Mon, 11 Dec 2000 05:11:03 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 03:10:50 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , Peter Mataga , Henning Schulzrinne Cc: SIP List MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] More questions on draft-rosenberg-sip-app-components-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 03:10:48 -0800 Hi all, Excellent draft. My questions relate to a few specifics of the ever-thorny stream/DTMF forking mechanism (or as some people may dispairingly call it: "The forking DTMF problem" :) I know it is just a draft but these are a few of the issues that concern me: 1) How does a UA know that an added media line actually should be a copy of an existing stream (voice or DTMF or both) rather than a new sendonly session? 2) If there are multiple audio or data streams, how does the UA know which to fork ? 3) In the Figure 4 example (where there are two proxies requesting the DTMF stream): How does Proxy B know which stream in the 200 OK (to the second re-INVITE) is the stream that connects/forks the DTMF stream to itself? [Especially if the two applications are hosted on the same server.] Does it need to if the streams are sendonly? [Deletion?] 4) In the above example, how does the proxy differiate between forked streams and new streams added by the UA ? 5) How many locations would you suggest that a UA be capable of forking to? 5, 10, 20 ? 6) How does a UA protect itself from unwittingly being part of a denial of service attack on a third party (eg by the proxy asking you to fork 20 streams of G711 to the target server)? Requiring user intervention on forking streams really defeats their usefulness. 7) How do you know if a UA supports stream forking behaviour ? Do we need some sort of Allow/Accept field? 8) What happens when AS's in both directions are generating re-INVITE's towards caller and callee? Without stream identification, things are going to get fairly complicated for the proxies (require end-to-end request glare avoidance?) It seems to me that without SDP media streams identifcation beyond the standard "n'th m line" routine, things are going to get very brittle? Do we need to require the SDP Media Stream Identification draft (a=fid:x) for proper stream forking? Where do you foresee that these issues will be trashed out? On the list, at the IETF, in a separate draft or as part of the aforemention draft (which I doubt) ? Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 07:43:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11066 for ; Mon, 11 Dec 2000 07:43:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0698F44337; Mon, 11 Dec 2000 06:43:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from michelangelo.lostwax.com (unknown [195.224.151.254]) by lists.bell-labs.com (Postfix) with ESMTP id A039644336 for ; Mon, 11 Dec 2000 06:42:35 -0500 (EST) Received: by MICHELANGELO with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Dec 2000 12:41:36 -0000 Message-ID: From: Paul Duncan To: sip@lists.bell-labs.com, jainsip@Sun.COM MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0636F.ADF3F560" Subject: [SIP] subscribe sip@lists.bell-labs.com Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 12:41:27 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C0636F.ADF3F560 Content-Type: text/plain; charset="iso-8859-1" subscribe sip@lists.bell-labs.com ------_=_NextPart_001_01C0636F.ADF3F560 Content-Type: text/html; charset="iso-8859-1" ------_=_NextPart_001_01C0636F.ADF3F560-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 08:51:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA23198 for ; Mon, 11 Dec 2000 08:51:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4977D44337; Mon, 11 Dec 2000 07:51:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from michelangelo.lostwax.com (unknown [195.224.151.254]) by lists.bell-labs.com (Postfix) with ESMTP id B312E44336 for ; Mon, 11 Dec 2000 07:50:36 -0500 (EST) Received: by MICHELANGELO with Internet Mail Service (5.5.2653.19) id ; Mon, 11 Dec 2000 13:49:37 -0000 Message-ID: From: Paul Duncan To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Writing Sip Servers Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 13:49:32 -0000 Apologies for my last subscribe post. I have just written my own simple UA and a multi threaded "bear bones" sip server which replies successfully to invites. At the moment the sip server listens to a well known port and reads the contents of any UDP arriving there. Eventually we want to be providing services such as time of day routing etc... And this is where I have trouble with the design. I want to write these services as EJB's for scalability, but am unsure of the best way to call them. It seems like I need my sip server to parse the sip information and decide which service to apply. This means my sip server has to call an ejb service. Does this sound a reasonable design? Many thanks Paul Duncan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 11:06:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12096 for ; Mon, 11 Dec 2000 11:06:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EDA5344337; Mon, 11 Dec 2000 10:06:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E3DBA44336 for ; Mon, 11 Dec 2000 10:05:21 -0500 (EST) Received: from dynamicsoft.com (1Cust108.tnt3.dub2.ie.uudial.net [213.116.44.108] (may be forged)) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA04265; Mon, 11 Dec 2000 11:07:32 -0500 (EST) Message-ID: <3A34FB22.1AE6280@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: jainsip@sun.com, sip@lists.bell-labs.com X-Priority: 2 (High) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] JAIN SIP discussions @ SIP Bakeoff Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 16:04:50 +0000 Content-Transfer-Encoding: 7bit Folks, There were some in-depth discussions about the JAIN SIP API at the SIP Bakeoff last week, and some interesting suggestions arose: If you are getting an optional parameter/header/body - you should not throw a ParameterNotSetException/HeaderNotSetException/BodyNotSetException since these are not exceptional cases - returning null is preferable, as seen in other APIs. The use of arrays for getting and setting multiple values is not nice at all - why not return an Enumeration/Iterator? (Although according to the Collections framework documentation it is preferable to pass a generic Collection and return the most specific subinterface of Collection we can - possibly SortedList?) Currently the JainSipProvider always passes a clone of a received Message to an application. It was suggested that this is too inefficient, and that it would be preferable to pass a reference to the Message, and warn in the documentation that the API user must clone the Message or part of it if they want to do anything other than get its values. (Personally I find this approach unacceptable - I think it gives the API user too much scope to mess with the internals of an API implementation) Currently get methods in Header interfaces throw a JainSipParseException if the header value could not be parsed (i.e. an implementation is allowed to delay parsing until the user asks for a particular part of a header). It was suggested that it would be better to throw the JainSipParseException on the getHeader and getXXXHeader methods i.e. force parsing of the header value when the user asks for the Header object. It was suggested that the getHeaders and getXXXHeaders methods (which return multiple headers) shouldn't throw a JainSipParseException, but that the methods for getting an individual header in the Enumeration/Iterator/Collection should throw the exception. [Note that a JainSipParseException contains a String field called unparsable - but do we need a JainSipParseException that includes a reference to a Header object - since this will not be returned if the exception is thrown? This would be particularly useful for the method getHeaders() which returns all headers in a message - if the exception is thrown with just the unparsable header value, then the application has no way to determine the header name. So I suggest that there should be a JainSipParseException subclass for this case of header value lazy-parsing e.g. JainSipHeaderValueParseException (extends JainSipParseException?) which has a getHeader() method - then the application can call getName() and getValue() on this header object] Do not need UndefinedHeader or UndefinedRequestMessage - does not add any functionality to Header or RequestMessage. Do not need InviteMessage, AckMessage, ByeMessage, CancelMessage, OptionsMessage or RegisterMessage - they add no extra functionality and only differ by their method - RequestMessage is sufficient. Do not need header types - do not provide anything meaningful - header types alone do not give enough information to do anything useful with an unrecognised header - the default protocol behaviour is sufficient. Do not need setName() method in Header - it should be read-only. I would be grateful if you could send any comments on these suggestions immediately, so we can get the first public release out asap. Regards, Chris Harris _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 11:40:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19902 for ; Mon, 11 Dec 2000 11:40:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C7A644337; Mon, 11 Dec 2000 10:40:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 0C19B44336 for ; Mon, 11 Dec 2000 10:39:14 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 11 Dec 2000 16:39:05 UT Received: from gethin by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id QAA20407; Mon, 11 Dec 2000 16:37:40 GMT From: Gethin Liddell Organization: Ubiquity Software Corp. To: Chris Harris , jainsip@sun.com, sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP discussions @ SIP Bakeoff X-Mailer: KMail [version 1.0.29.2] Content-Type: text/plain References: <3A34FB22.1AE6280@dynamicsoft.com> In-Reply-To: <3A34FB22.1AE6280@dynamicsoft.com> MIME-Version: 1.0 Message-Id: <00121117302801.10276@gethin> Content-Transfer-Encoding: 8bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 17:17:46 +0000 Content-Transfer-Encoding: 8bit hay chris, any points i have not commented on, i agree with (as per our meeting last week) On Mon, 11 Dec 2000, Chris Harris wrote: > Folks, > > There were some in-depth discussions about the JAIN SIP API at the SIP > Bakeoff last week, and some interesting suggestions arose: > > If you are getting an optional parameter/header/body - you should not > throw a > ParameterNotSetException/HeaderNotSetException/BodyNotSetException since > these are not exceptional cases - returning null is preferable, as seen > in other APIs. > > The use of arrays for getting and setting multiple values is not nice at > all - why not return an Enumeration/Iterator? (Although according to the > Collections framework documentation it is preferable to pass a generic > Collection and return the most specific subinterface of Collection we > can - possibly SortedList?) > > Currently the JainSipProvider always passes a clone of a received > Message to an application. It was suggested that this is too > inefficient, and that it would be preferable to pass a reference to the > Message, and warn in the documentation that the API user must clone the > Message or part of it if they want to do anything other than get its > values. (Personally I find this approach unacceptable - I think it gives > the API user too much scope to mess with the internals of an API > implementation) OK, but keep in mind that JAIN SIP will be limited in what it can achieve effectively if this is done. i.e. it would be no good trying to create a real proxy with JAIN SIP because it would be very slow. as i said at our meeting, we need to do what we can to help the performance of JAIN SIP. > > Currently get methods in Header interfaces throw a JainSipParseException > if the header value could not be parsed (i.e. an implementation is > allowed to delay parsing until the user asks for a particular part of a > header). It was suggested that it would be better to throw the > JainSipParseException on the getHeader and getXXXHeader methods i.e. > force parsing of the header value when the user asks for the Header > object. It was suggested that the getHeaders and getXXXHeaders methods > (which return multiple headers) shouldn't throw a JainSipParseException, > but that the methods for getting an individual header in the > Enumeration/Iterator/Collection should throw the exception. > > [Note that a JainSipParseException contains a String field called > unparsable - but do we need a JainSipParseException that includes a > reference to a Header object - since this will not be returned if the > exception is thrown? This would be particularly useful for the method > getHeaders() which returns all headers in a message - if the exception > is thrown with just the unparsable header value, then the application > has no way to determine the header name. So I suggest that there should > be a JainSipParseException subclass for this case of header value > lazy-parsing e.g. JainSipHeaderValueParseException (extends > JainSipParseException?) which has a getHeader() method - then the > application can call getName() and getValue() on this header object] this seems reasonable now. trying to set an incorrect value would throw a JainSipParseException and trying to parse a header would throw a JainSipHeaderValueParseException (why not just JainSipHeaderParseException though? shorter by a whole 5 letters :) ) Although (as a reminder) what about the discussion we had on the minimal parsing required. i.e. Jain Sip is transaction aware. therefore each implmentation needs to at least parse the transaction identifiers, To, From, Call-ID and CSeq. so for the message to reach the app, then these heades must be valid and there is no need to throw exceptions on them. no? > > Do not need UndefinedHeader or UndefinedRequestMessage - does not add > any functionality to Header or RequestMessage. > > Do not need InviteMessage, AckMessage, ByeMessage, CancelMessage, > OptionsMessage or RegisterMessage - they add no extra functionality and > only differ by their method - RequestMessage is sufficient. minimal is best > Do not need header types - do not provide anything meaningful - header > types alone do not give enough information to do anything useful with an > unrecognised header - the default protocol behaviour is sufficient. > > Do not need setName() method in Header - it should be read-only. > > I would be grateful if you could send any comments on these suggestions > immediately, so we can get the first public release out asap. > > Regards, > Chris Harris > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gethin Liddell Ubiquity Software Corporation http://www.ubiquity.net mailto:gethin@ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 12:06:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA27233 for ; Mon, 11 Dec 2000 12:06:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E0EE644339; Mon, 11 Dec 2000 11:06:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E4D4744337 for ; Mon, 11 Dec 2000 11:05:33 -0500 (EST) Received: from dynamicsoft.com (1Cust108.tnt3.dub2.ie.uudial.net [213.116.44.108] (may be forged)) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA05086; Mon, 11 Dec 2000 12:07:52 -0500 (EST) Message-ID: <3A350948.6389B84A@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Gethin Liddell Cc: jainsip@sun.com, sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP discussions @ SIP Bakeoff References: <3A34FB22.1AE6280@dynamicsoft.com> <00121117302801.10276@gethin> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 17:05:12 +0000 Content-Transfer-Encoding: 7bit Hi Gethin, Thanks for the quick response. Some notes below... Chris Gethin Liddell wrote: > hay chris, > > any points i have not commented on, i agree with (as per our meeting > last week) > > On Mon, 11 Dec 2000, Chris Harris wrote: > > Folks, > > > > There were some in-depth discussions about the JAIN SIP API at the SIP > > Bakeoff last week, and some interesting suggestions arose: > > > > If you are getting an optional parameter/header/body - you should not > > throw a > > ParameterNotSetException/HeaderNotSetException/BodyNotSetException since > > these are not exceptional cases - returning null is preferable, as seen > > in other APIs. > > > > The use of arrays for getting and setting multiple values is not nice at > > all - why not return an Enumeration/Iterator? (Although according to the > > Collections framework documentation it is preferable to pass a generic > > Collection and return the most specific subinterface of Collection we > > can - possibly SortedList?) > > > > Currently the JainSipProvider always passes a clone of a received > > Message to an application. It was suggested that this is too > > inefficient, and that it would be preferable to pass a reference to the > > Message, and warn in the documentation that the API user must clone the > > Message or part of it if they want to do anything other than get its > > values. (Personally I find this approach unacceptable - I think it gives > > the API user too much scope to mess with the internals of an API > > implementation) > > OK, but keep in mind that JAIN SIP will be limited in what it can > achieve effectively if this is done. i.e. it would be no good trying > to create a real proxy with JAIN SIP because it would be very slow. > > as i said at our meeting, we need to do what we can to help the > performance of JAIN SIP. I hear what you're saying - but also let's not forget that the implementor has total control over the cloning of messages - so for high performance JAIN SIP applications you should use an implementation that doesn't create messages from scratch each time it clones one - A good implementation will pool JAIN SIP objects and give the clone operation access to these pools. I would see this as another way for implementations to distinguish themselves from their competition. [Although I have a feeling you will come back with saying this will be even faster if we give the application the decision of whether to clone or not :) ] Like I said before: "Safety versus Speed". I would prefer to see safety built in the API and speed determined by the implementation, rather than speed built into the API and safety determined by the application. > > > > > > Currently get methods in Header interfaces throw a JainSipParseException > > if the header value could not be parsed (i.e. an implementation is > > allowed to delay parsing until the user asks for a particular part of a > > header). It was suggested that it would be better to throw the > > JainSipParseException on the getHeader and getXXXHeader methods i.e. > > force parsing of the header value when the user asks for the Header > > object. It was suggested that the getHeaders and getXXXHeaders methods > > (which return multiple headers) shouldn't throw a JainSipParseException, > > but that the methods for getting an individual header in the > > Enumeration/Iterator/Collection should throw the exception. > > > > [Note that a JainSipParseException contains a String field called > > unparsable - but do we need a JainSipParseException that includes a > > reference to a Header object - since this will not be returned if the > > exception is thrown? This would be particularly useful for the method > > getHeaders() which returns all headers in a message - if the exception > > is thrown with just the unparsable header value, then the application > > has no way to determine the header name. So I suggest that there should > > be a JainSipParseException subclass for this case of header value > > lazy-parsing e.g. JainSipHeaderValueParseException (extends > > JainSipParseException?) which has a getHeader() method - then the > > application can call getName() and getValue() on this header object] > > this seems reasonable now. trying to set an incorrect value would throw > a JainSipParseException and trying to parse a header would throw a > JainSipHeaderValueParseException (why not just > JainSipHeaderParseException though? shorter by a whole 5 letters :) ) Sure - although I am starting to think that it might be better to add a header name field to the JainSipHeaderParseException rather than a header object field. > > > Although (as a reminder) what about the discussion we had on the minimal > parsing required. i.e. Jain Sip is transaction aware. therefore each > implmentation needs to at least parse the transaction identifiers, To, > From, Call-ID and CSeq. so for the message to reach the app, then these > heades must be valid and there is no need to throw exceptions on them. > no? This is true, and I totally forgot about it - must be the jet lag :) > > > > > > Do not need UndefinedHeader or UndefinedRequestMessage - does not add > > any functionality to Header or RequestMessage. > > > > Do not need InviteMessage, AckMessage, ByeMessage, CancelMessage, > > OptionsMessage or RegisterMessage - they add no extra functionality and > > only differ by their method - RequestMessage is sufficient. > > minimal is best > > > Do not need header types - do not provide anything meaningful - header > > types alone do not give enough information to do anything useful with an > > unrecognised header - the default protocol behaviour is sufficient. > > > > Do not need setName() method in Header - it should be read-only. > > > > I would be grateful if you could send any comments on these suggestions > > immediately, so we can get the first public release out asap. > > > > Regards, > > Chris Harris > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > -- > Gethin Liddell > Ubiquity Software Corporation > > http://www.ubiquity.net > mailto:gethin@ubiquity.net > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 12:57:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11181 for ; Mon, 11 Dec 2000 12:57:21 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D0E1744337; Mon, 11 Dec 2000 11:57:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id E13C744336 for ; Mon, 11 Dec 2000 11:56:19 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA23044; Mon, 11 Dec 2000 12:56:09 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA26504; Mon, 11 Dec 2000 12:56:09 -0500 (EST) Message-ID: <3A35405A.3F27D301@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Bich T. Nguyen" , sip@lists.bell-labs.com Subject: Re: [SIP] Configuration management for SIP phones References: <4.3.2.7.2.20001211093641.02c6e9d0@mira-sjcm-1.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 13:00:10 -0800 Content-Transfer-Encoding: 7bit Followup: Subscription information is at http://www.egroups.com/group/sip-config _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 13:55:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21716 for ; Mon, 11 Dec 2000 13:55:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE20F44337; Mon, 11 Dec 2000 12:55:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 3816944336 for ; Mon, 11 Dec 2000 12:54:25 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id KAA20643; Mon, 11 Dec 2000 10:54:13 -0800 (PST) Received: from sony-laptop (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with SMTP id AAC82607; Mon, 11 Dec 2000 10:51:00 -0800 (PST) Message-Id: <4.1.20001210153934.00cce8e0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: rohan@cisco.com, dean.willis@softarmor.com From: Rohan Mahy Cc: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_268694628==_.ALT" Subject: [SIP] summary for the week of Nov 12-18 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 10:52:37 -0800 --=====================_268694628==_.ALT Content-Type: text/plain; charset="us-ascii" Announcements - Jonathan Rosenberg announced the SIMPLE BOF - Many IDs where announced: dns-gl, sip-app-components, sip-deaf-req, sip-peer-3pcc, sip-189, sip-replaces, sip-t38callflows - Henning said 'Please do not include numeric citations, such as "SIP [1] ..." in abstracts' - Steve Donovan announced dynamicsoft's test message service. - last call on ISUP MIME type Threads - a short thread on the use of Call-IDs devolved into a discussion on its use for distributed conferencing, and the deprecation of Also. - Threads on torture tests: consensus was to fix text for test7, deprecate test10. many commented on Neil Deason's proposed new tests. Consensus was to be liberal in what you recieve; several of the proposed torture cases can cause the example error or be handled despite the error. Neil agreed to modify the example of escaping inside the Request-URI. Anders suggested additional tests for brackets and parameters in Contact headers. Anders and Hisham Khartabi commented that according to the bis draft, semicolon-delimited parameters not included in brackets (< and >) are header-parameters as opposed to URL parameters. Finally, Ashok Roy suggested adding an IPv6 ;maddr parameter to a torture test. - In the thread "What am I doing wrong?", someone was having problems with a UAC receiving a 180 from a first branch then a 180 and 200 from a second branch. Consensus was to add a torture test for properly handling tags from forked calls. - Henning proposed also using the Alert-Info header as a response header, instead of implementing Adam Roach's ringback draft - Another thread on ringback tone devolved into a discussion on 180 w/ early media vs. 183. Robert Sparks summarized the thread consensus best "if a PSTN gateway knows that the callee is being alerted then it should send a 180 with (or without) SDP. Otherwise, if the PSTN gateway only knows that inband call progress tones are being provided by the PSTN network (but not the callee alerting state) then ... 183 is more appropriate." - M Ranganthan replied to a query for availability of SIP grammars, that an antlr (grammar for java) version would be available shortly. - 11/15-11/17 "Jain SIP - Issues": Chris Harris asked a) what kind of exception an implementation of JAIN SIP should throw if it doesn't like one of the header values, and b) should an implementation automatically respond to un-parsable messages, or pass them up to the application. An default class/subclass approach was suggested with some lazy-parsing. Chris also asked if overriding equals() is desireable. 11/13-11/17 "Identification Problem"/"Record-Route" : Jo Hornsby started a thread proposing adding an "original-uri" parameter to carry the parameters from the original URI lost when rewriting the Request URI for Record Route processing. Bertil Engelholm proposed a non-backwards compatible change to Route (that it should act like Via). Billy Biggs enumerated ways in which a proxy would build the Record-Route, and proposed that RR reflect the next hop in Route as opposed to the final destination. Sean Olson proposed using both an maddr and raddr parameter, and claimed there was no clean way to fix RR and provide backwards compatibility. 11/13-11/14 "SIP End-2-End Security" Tom Tang asked how to do end to end. Michael Thomas clarified some properties of end2end vs. hopwise encryption. 11/13 "Gateway and Redirect Number": Pete Kazimier asked how to translate Q.931 redirected number into SIP. Brian Gracely provided a pointer to the diversion draft. Hisham Khartabi provided a pointer to a directory of telephony-related drafts on the main SIP site. - 11/13 "Possilbe REFER problem": Robert Sparks and Billy Biggs had a spirited discussion about using Contact as the Request-URI in the Refer-To URI. Robert noted that the Contact may be in a private name space and hence unreachable by the UA that receives the REFER; Billy noted that the well known name may be unavailable in some cases; Robert suggested using the Contact, then using caller preferences (Accept-Contact=) if the previous REFER failed; Billy noted that the previous REFER may fail for reasons other than an invalid Contact address. - 11/16-11/18 "ID extension of REFER": Rohan Mahy announced an draft extension to REFER. Venkatesh commented on some potential uses for the ongoing status of a REFER. Sean Olson asked if the draft causes different timing/attempts to solve the retransmission problem (it does not). Sean asked why 183 was not used, Venkatesh asked why the provisionals aren't simply forwarded. - 11/14 "From header to ISUP"/"Redirect server returning new From": These two threads disucssed the mertis of Reply-To and Also-From headers. Rehashes - 11/14 "Session-time with INFO" Christer Holmberg flogged a dead horse proposing a new "lite" session timer-like mechanism which uses INFO. - the "why does INVITE use a 3-way handshake?" question. Billy Biggs, Jonathan Rosenberg, and Henning mentioned forking, reliability, and speedy message delivery. Billy Biggs mentioned that retransmissions are problematic for REFER (because the REFER can be outstanding for more than 32 seconds). Billy also stated that forking is problematic for SUBSCRIBE and MESSAGE, with which Jonathan disagreed. - 11/14 "SIP-H.323 INVITE w/ no media": Michel Maddux asked about using INVITEs with no media for SIP to H.323 calls. Vladislav Zubarev provided a pointer to and quotes from http:// search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt and the bis draft to answer the question. - 11/13-11/14 "Redirect vs Proxy Server": David Schmidlin asked when to use a redirect vs. proxy role. Billy Biggs and Jonathan Rosenberg replied on ease of coding, data hiding, and control of the two roles. 11/17 "SDP coder negotiation": Duke Snyder asked about the behavior of codec negotiation. Billy Biggs and Simon Barber replied with the correct behavior. Simon asked for a survey of implementations of many of the implied SDP behaviors. Questions without replies, potentially needing disabiguation. - contiguous CSeq: bis 6.20 says CSeq number must be contiguous. (insert "within a transaction") - what is the "MD5-sess" algorithm in Digest authentication? (clarify reference) - can I include both "proxy" and "redirect" in Request-Disposition? (no) - does CANCEL of a REFER, cancel the referred INVITE? (yes) --=====================_268694628==_.ALT Content-Type: text/html; charset="us-ascii"         Announcements
-  Jonathan Rosenberg announced the SIMPLE BOF
-  Many IDs where announced: dns-gl, sip-app-components, sip-deaf-req, sip-peer-3pcc, sip-189, sip-replaces, sip-t38callflows
-  Henning said 'Please do not include numeric citations, such as "SIP [1] ..." in abstracts'
- Steve Donovan announced dynamicsoft's test message service.
- last call on ISUP MIME type

        Threads
- a short thread on the use of Call-IDs devolved into a discussion on its use for distributed conferencing, and the deprecation of Also.

- Threads on torture tests: consensus was to fix text for test7, deprecate test10.  many commented on Neil Deason's proposed new tests.  Consensus was to be liberal in what you recieve; several of the proposed torture cases can cause the example error or be handled despite the error. Neil agreed to modify the example of escaping inside the Request-URI. Anders suggested additional tests for brackets and parameters in Contact headers. Anders and Hisham Khartabi commented that according to the bis draft, semicolon-delimited parameters not included in brackets (< and >) are header-parameters as opposed to URL parameters. Finally, Ashok Roy suggested adding an IPv6 ;maddr parameter to a torture test.

- In the thread "What am I doing wrong?", someone was having problems with a UAC receiving a 180 from a first branch then a 180 and 200 from a second branch.  Consensus was to add a torture test for properly handling tags from forked calls.

- Henning proposed also using the Alert-Info header as a response header, instead of implementing Adam Roach's ringback draft

- Another thread on ringback tone devolved into a discussion on 180 w/ early media vs. 183. 
Robert Sparks summarized the thread consensus best "if a PSTN gateway knows that the callee is being alerted then it should send a 180 with (or without) SDP. Otherwise, if the PSTN gateway only knows that inband call progress tones are being provided by the PSTN network (but not the callee alerting state) then ... 183 is more appropriate."

- M Ranganthan replied to a query for availability of SIP grammars, that an antlr (grammar for java) version would be available shortly.

- 11/15-11/17 "Jain SIP - Issues": Chris Harris asked a) what kind of exception an implementation of JAIN SIP should throw if it doesn't like one of the header values, and b) should an implementation automatically respond to un-parsable messages, or pass them up to the application.  An default class/subclass approach was suggested with some lazy-parsing.  Chris also asked if overriding equals() is desireable.

11/13-11/17 "Identification Problem"/"Record-Route" : Jo Hornsby started a thread proposing adding an "original-uri" parameter to carry the parameters from the original URI lost when rewriting the Request URI for Record Route processing. Bertil Engelholm proposed a non-backwards compatible change to Route (that it should act like Via). Billy Biggs enumerated ways in which a proxy would build the Record-Route, and proposed that RR reflect the next hop in Route as opposed to the final destination. Sean Olson proposed using both an maddr and raddr parameter, and claimed there was no clean way to fix RR and provide backwards compatibility.

11/13-11/14 "SIP End-2-End Security" Tom Tang asked how to do end to end.  Michael Thomas clarified some properties of end2end vs. hopwise encryption.
11/13 "Gateway and Redirect Number": Pete Kazimier asked how to translate Q.931 redirected number into SIP.  Brian Gracely provided a pointer to the diversion draft. Hisham Khartabi provided a pointer to a directory of telephony-related drafts on the main SIP site.

- 11/13 "Possilbe REFER problem": Robert Sparks and Billy Biggs had a spirited discussion about using Contact as the Request-URI in the Refer-To URI.  Robert noted that the Contact may be in a private name space and hence unreachable by the UA that receives the REFER; Billy noted that the well known name may be unavailable in some cases; Robert suggested using the Contact, then using caller preferences (Accept-Contact=<contact>) if the previous REFER failed; Billy noted that the previous REFER may fail for reasons other than an invalid Contact address.

- 11/16-11/18 "ID extension of REFER": Rohan Mahy announced an draft extension to REFER.  Venkatesh commented on some potential uses for the ongoing status of a REFER.  Sean Olson asked if the draft causes different timing/attempts to solve the retransmission problem (it does not).  Sean asked why 183 was not used, Venkatesh asked why the provisionals aren't simply forwarded.

- 11/14 "From header to ISUP"/"Redirect server returning new From": These two threads disucssed the mertis of Reply-To and Also-From headers. 

        Rehashes
- 11/14 "Session-time with INFO"  Christer Holmberg flogged a dead horse proposing a new "lite" session timer-like mechanism which uses INFO.

- the "why does INVITE use a 3-way handshake?" question. Billy Biggs, Jonathan Rosenberg, and Henning mentioned forking, reliability, and speedy message delivery.  Billy Biggs mentioned that retransmissions are problematic for REFER (because the REFER can be outstanding for more than 32 seconds). Billy also stated that forking is problematic for SUBSCRIBE and MESSAGE, with which Jonathan disagreed.

- 11/14 "SIP-H.323 INVITE w/ no media": Michel Maddux asked about using INVITEs with no media for SIP to H.323 calls. Vladislav Zubarev provided a pointer to and quotes from http://search.ietf.org/internet-drafts/draft-singh-sip-h323-01.txt and the bis draft to answer the question.

- 11/13-11/14 "Redirect vs Proxy Server": David Schmidlin asked when to use a redirect vs. proxy role. Billy Biggs and Jonathan Rosenberg replied on ease of coding, data hiding, and control of the two roles.

11/17 "SDP coder negotiation": Duke Snyder asked about the behavior of codec negotiation. Billy Biggs and Simon Barber replied with the correct behavior. Simon asked for a survey of implementations of many of the implied SDP behaviors.

        Questions without replies, potentially needing disabiguation.
- contiguous CSeq: bis 6.20 says CSeq number must be contiguous.  (insert "within a transaction")
- what is the "MD5-sess" algorithm in Digest authentication? (clarify reference)
- can I include both "proxy" and "redirect" in Request-Disposition? (no)
- does CANCEL of a REFER, cancel the referred INVITE? (yes)
--=====================_268694628==_.ALT-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 13:56:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21914 for ; Mon, 11 Dec 2000 13:56:51 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 703034434A; Mon, 11 Dec 2000 12:55:28 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lists.bell-labs.com (Postfix) with ESMTP id 374B244336 for ; Mon, 11 Dec 2000 12:54:36 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by motgate.mot.com (motgate 2.1) with ESMTP id LAA08126; Mon, 11 Dec 2000 11:54:26 -0700 (MST)] Received: [from grumpy.rsch.comm.mot.com (grumpy.rsch.comm.mot.com [145.1.80.93]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id LAA17358; Mon, 11 Dec 2000 11:54:25 -0700 (MST)] Received: from labs.mot.com (localhost [127.0.0.1]) by grumpy.rsch.comm.mot.com (8.9.3+Sun/8.8.8) with ESMTP id MAA01793; Mon, 11 Dec 2000 12:54:25 -0600 (CST) Message-ID: <3A3522E1.D05DDC46@labs.mot.com> From: Bryan Thale Organization: Motorola Labs, Networking & Infrastructure Research X-Mailer: Mozilla 4.73 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: jainsip@sun.com, sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP discussions @ SIP Bakeoff References: <3A34FB22.1AE6280@dynamicsoft.com> <00121117302801.10276@gethin> <3A350948.6389B84A@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 12:54:25 -0600 Content-Transfer-Encoding: 7bit Chris, Comments and musings below. Bryan. > > > Currently the JainSipProvider always passes a clone of a received > > > Message to an application. It was suggested that this is too > > > inefficient, and that it would be preferable to pass a reference to the > > > Message, and warn in the documentation that the API user must clone the > > > Message or part of it if they want to do anything other than get its > > > values. (Personally I find this approach unacceptable - I think it gives > > > the API user too much scope to mess with the internals of an API > > > implementation) > > > > OK, but keep in mind that JAIN SIP will be limited in what it can > > achieve effectively if this is done. i.e. it would be no good trying > > to create a real proxy with JAIN SIP because it would be very slow. > > > > as i said at our meeting, we need to do what we can to help the > > performance of JAIN SIP. > > I hear what you're saying - but also let's not forget that the implementor has > total control over the cloning of messages - so for high performance JAIN SIP > applications you should use an implementation that doesn't create messages > from scratch each time it clones one - A good implementation will pool JAIN > SIP objects and give the clone operation access to these pools. I would see > this as another way for implementations to distinguish themselves from their > competition. [Although I have a feeling you will come back with saying this > will be even faster if we give the application the decision of whether to > clone or not :) ] > > Like I said before: "Safety versus Speed". I would prefer to see safety built > in the API and speed determined by the implementation, rather than speed built > into the API and safety determined by the application. > In that case, shouldn't the API define public message and header interfaces that contain only get and test accessor methods and no set methods? Set methods could be added by private-to-the-stack extensions to those interfaces. That would prevent an application from messing with anything internal and not rely on the good behavior of the application, nor would it dictate cloning policy. All the same, though, why is it necessary for the message and header objects to be owned by and internal to the stack anyway? They are merely encapsulations of data that should be able to be freely exchanged between the application and the stack across the API boundary just like a String object can be. What is dangerous about letting the application set a value in a header or message object? Isn't that what an application is _supposed_ to do? > > > The use of arrays for getting and setting multiple values is not nice at > > > all - why not return an Enumeration/Iterator? (Although according to the > > > Collections framework documentation it is preferable to pass a generic > > > Collection and return the most specific subinterface of Collection we > > > can - possibly SortedList?) > If the API specified a Collection, couldn't the choice of concrete representation be left up to the implementation? That is, the API wouldn't need to specify that the Collection must be backed up by a SortedList but could be any Collection-derivative appropriate to the implementation. > > > Currently get methods in Header interfaces throw a JainSipParseException > > > if the header value could not be parsed (i.e. an implementation is > > > allowed to delay parsing until the user asks for a particular part of a > > > header). It was suggested that it would be better to throw the > > > JainSipParseException on the getHeader and getXXXHeader methods i.e. > > > force parsing of the header value when the user asks for the Header > > > object. It was suggested that the getHeaders and getXXXHeaders methods > > > (which return multiple headers) shouldn't throw a JainSipParseException, > > > but that the methods for getting an individual header in the > > > Enumeration/Iterator/Collection should throw the exception. > I think this sounds like a vast ease-of-use improvement for applications trying to use the API. It seems rather onerous to force an application to catch, and theoretically deal intelligently with, a JainSipParseException whenever it calls something as innocent as hasQValue(). > > this seems reasonable now. trying to set an incorrect value would throw > > a JainSipParseException and trying to parse a header would throw a > > JainSipHeaderValueParseException (why not just > > JainSipHeaderParseException though? shorter by a whole 5 letters :) ) > > Sure - although I am starting to think that it might be better to add a header > name field to the JainSipHeaderParseException rather than a header object > field. > I think the header name is preferable since you might not be able to construct a meaningful header object in the presence of a parsing error. > > > If you are getting an optional parameter/header/body - you should not > > > throw a > > > ParameterNotSetException/HeaderNotSetException/BodyNotSetException since > > > these are not exceptional cases - returning null is preferable, as seen > > > in other APIs. > Yes, there is nothing exceptional about the absence of an optional element. Speaking of exceptions, it seems like IllegalArgumentException is used to signal a null parameter being passed in to most methods. Why not throw the more precise NullPointerException instead? -- Bryan Thale Motorola Labs, Networking and Infrastructure Research mailto:thale@labs.mot.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 15:11:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA01633 for ; Mon, 11 Dec 2000 15:11:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A14AA44337; Mon, 11 Dec 2000 14:11:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1F93E44336 for ; Mon, 11 Dec 2000 14:10:36 -0500 (EST) Received: from dynamicsoft.com (1Cust27.tnt1.dub2.ie.uudial.net [213.116.40.27] (may be forged)) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA07242; Mon, 11 Dec 2000 15:12:54 -0500 (EST) Message-ID: <3A3534A5.B948033F@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Bryan Thale Cc: jainsip@sun.com, sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP discussions @ SIP Bakeoff References: <3A34FB22.1AE6280@dynamicsoft.com> <00121117302801.10276@gethin> <3A350948.6389B84A@dynamicsoft.com> <3A3522E1.D05DDC46@labs.mot.com> Content-Type: multipart/alternative; boundary="------------319CA0F72AE6FAE2C33B7AA2" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 20:10:13 +0000 --------------319CA0F72AE6FAE2C33B7AA2 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bryan, We need to make sure that an implementation does not let an application alter the original received message (which will may be stored in some transaction object). We can do this several ways: * Simply don't allow an implementation to give a message object to an application that it does not wish to be altered externally * Allow an implementation to give a message object to an application that it does not wish to be altered externally, but warn that an application must not alter this message (even though the set methods are available) * Allow an implementation to give a message object to an application that it does not wish to be altered externally, but only expoose it through a read-only interface without set/remove methods I think the first option is the simplest, the second is a no go, and the third is a possibility - but it means having 2/3 interfaces for each message and header - one read-only and another read-write (and maybe one writable). We also need to allow the application to create a read-write clone of these read-only objects - a regular clone and downcast to the read-write interface would suffice, but it would be a lot nicer to define a method that both clones and downcasts. (Of course there would be nothing stopping an application downcasting the originally received message/header to alter it - but at least it would be a lot more obvious to the developer that you shouldn't). Regards, Chris Bryan Thale wrote: > Chris, > > Comments and musings below. > > Bryan. > > > > > Currently the JainSipProvider always passes a clone of a received > > > > Message to an application. It was suggested that this is too > > > > inefficient, and that it would be preferable to pass a reference to the > > > > Message, and warn in the documentation that the API user must clone the > > > > Message or part of it if they want to do anything other than get its > > > > values. (Personally I find this approach unacceptable - I think it gives > > > > the API user too much scope to mess with the internals of an API > > > > implementation) > > > > > > OK, but keep in mind that JAIN SIP will be limited in what it can > > > achieve effectively if this is done. i.e. it would be no good trying > > > to create a real proxy with JAIN SIP because it would be very slow. > > > > > > as i said at our meeting, we need to do what we can to help the > > > performance of JAIN SIP. > > > > I hear what you're saying - but also let's not forget that the implementor has > > total control over the cloning of messages - so for high performance JAIN SIP > > applications you should use an implementation that doesn't create messages > > from scratch each time it clones one - A good implementation will pool JAIN > > SIP objects and give the clone operation access to these pools. I would see > > this as another way for implementations to distinguish themselves from their > > competition. [Although I have a feeling you will come back with saying this > > will be even faster if we give the application the decision of whether to > > clone or not :) ] > > > > Like I said before: "Safety versus Speed". I would prefer to see safety built > > in the API and speed determined by the implementation, rather than speed built > > into the API and safety determined by the application. > > > > In that case, shouldn't the API define public message and header > interfaces that contain only get and test accessor methods and no set > methods? Set methods could be added by private-to-the-stack extensions > to those interfaces. That would prevent an application from messing > with anything internal and not rely on the good behavior of the > application, nor would it dictate cloning policy. > > > All the same, though, why is it necessary for the message and header > objects to be owned by and internal to the stack anyway? They are > merely encapsulations of data that should be able to be freely exchanged > between the application and the stack across the API boundary just like > a String object can be. What is dangerous about letting the application > set a value in a header or message object? Isn't that what an > application is _supposed_ to do? > > > > > > The use of arrays for getting and setting multiple values is not nice at > > > > all - why not return an Enumeration/Iterator? (Although according to the > > > > Collections framework documentation it is preferable to pass a generic > > > > Collection and return the most specific subinterface of Collection we > > > > can - possibly SortedList?) > > > > If the API specified a Collection, couldn't the choice of concrete > representation be left up to the implementation? That is, the API > wouldn't need to specify that the Collection must be backed up by a > SortedList but could be any Collection-derivative appropriate to the > implementation. > > > > > Currently get methods in Header interfaces throw a JainSipParseException > > > > if the header value could not be parsed (i.e. an implementation is > > > > allowed to delay parsing until the user asks for a particular part of a > > > > header). It was suggested that it would be better to throw the > > > > JainSipParseException on the getHeader and getXXXHeader methods i.e. > > > > force parsing of the header value when the user asks for the Header > > > > object. It was suggested that the getHeaders and getXXXHeaders methods > > > > (which return multiple headers) shouldn't throw a JainSipParseException, > > > > but that the methods for getting an individual header in the > > > > Enumeration/Iterator/Collection should throw the exception. > > > > I think this sounds like a vast ease-of-use improvement for applications > trying to use the API. It seems rather onerous to force an application > to catch, and theoretically deal intelligently with, a > JainSipParseException whenever it calls something as innocent as > hasQValue(). > > > > this seems reasonable now. trying to set an incorrect value would throw > > > a JainSipParseException and trying to parse a header would throw a > > > JainSipHeaderValueParseException (why not just > > > JainSipHeaderParseException though? shorter by a whole 5 letters :) ) > > > > Sure - although I am starting to think that it might be better to add a header > > name field to the JainSipHeaderParseException rather than a header object > > field. > > > > I think the header name is preferable since you might not be able to > construct a meaningful header object in the presence of a parsing error. > > > > > If you are getting an optional parameter/header/body - you should not > > > > throw a > > > > ParameterNotSetException/HeaderNotSetException/BodyNotSetException since > > > > these are not exceptional cases - returning null is preferable, as seen > > > > in other APIs. > > > > Yes, there is nothing exceptional about the absence of an optional > element. > > Speaking of exceptions, it seems like IllegalArgumentException is used > to signal a null parameter being passed in to most methods. Why not > throw the more precise NullPointerException instead? > > -- > Bryan Thale > Motorola Labs, Networking and Infrastructure Research > mailto:thale@labs.mot.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip --------------319CA0F72AE6FAE2C33B7AA2 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Bryan,

We need to make sure that an implementation does not let an application alter the original received message (which will may be stored in some transaction object). We can do this several ways:

  • Simply don't allow an implementation to give a message object to an application that it does not wish to be altered externally
  • Allow an implementation to give a message object to an application that it does not wish to be altered externally, but warn that an application must not alter this message (even though the set methods are available)
  • Allow an implementation to give a message object to an application that it does not wish to be altered externally, but only expoose it through a read-only interface without set/remove methods
I think the first option is the simplest, the second is a no go, and the third is a possibility - but it means having 2/3 interfaces for each message and header - one read-only and another read-write (and maybe one writable). We also need to allow the application to create a read-write clone of these read-only objects - a regular clone and downcast to the read-write interface would suffice, but it would be a lot nicer to define a method that both clones and downcasts. (Of course there would be nothing stopping an application downcasting the originally received message/header to alter it - but at least it would be a lot more obvious to the developer that you shouldn't).
 

Regards,
Chris
 
 

Bryan Thale wrote:

Chris,

Comments and musings below.

Bryan.

> > > Currently the JainSipProvider always passes a clone of a received
> > > Message to an application. It was suggested that this is too
> > > inefficient, and that it would be preferable to pass a reference to the
> > > Message, and warn in the documentation that the API user must clone the
> > > Message or part of it if they want to do anything other than get its
> > > values. (Personally I find this approach unacceptable - I think it gives
> > > the API user too much scope to mess with the internals of an API
> > > implementation)
> >
> > OK, but keep in mind that JAIN SIP will be limited in what it can
> > achieve effectively if this is done. i.e. it would be no good trying
> > to create a real proxy with JAIN SIP because it would be very slow.
> >
> > as i said at our meeting, we need to do what we can to help the
> > performance of JAIN SIP.
>
> I hear what you're saying - but also let's not forget that the implementor has
> total control over the cloning of messages - so for high performance JAIN SIP
> applications you should use an implementation that doesn't create messages
> from scratch each time it clones one - A good implementation will pool JAIN
> SIP objects and give the clone operation access to these pools. I would see
> this as another way for implementations to distinguish themselves from their
> competition. [Although I have a feeling you will come back with saying this
> will be even faster if we give the application the decision of whether to
> clone or not :) ]
>
> Like I said before: "Safety versus Speed". I would prefer to see safety built
> in the API and speed determined by the implementation, rather than speed built
> into the API and safety determined by the application.
>

In that case, shouldn't the API define public message and header
interfaces that contain only get and test accessor methods and no set
methods?  Set methods could be added by private-to-the-stack extensions
to those interfaces.  That would prevent an application from messing
with anything internal and not rely on the good behavior of the
application, nor would it dictate cloning policy.

 

All the same, though, why is it necessary for the message and header
objects to be owned by and internal to the stack anyway?  They are
merely encapsulations of data that should be able to be freely exchanged
between the application and the stack across the API boundary  just like
a String object can be.  What is dangerous about letting the application
set a value in a header or message object?  Isn't that what an
application is _supposed_ to do?

 

> > > The use of arrays for getting and setting multiple values is not nice at
> > > all - why not return an Enumeration/Iterator? (Although according to the
> > > Collections framework documentation it is preferable to pass a generic
> > > Collection and return the most specific subinterface of Collection we
> > > can - possibly SortedList?)
>

If the API specified a Collection, couldn't the choice of concrete
representation be left up to the implementation?  That is, the API
wouldn't need to specify that the Collection must be backed up by a
SortedList but could be any Collection-derivative appropriate to the
implementation.

> > > Currently get methods in Header interfaces throw a JainSipParseException
> > > if the header value could not be parsed (i.e. an implementation is
> > > allowed to delay parsing until the user asks for a particular part of a
> > > header). It was suggested that it would be better to throw the
> > > JainSipParseException on the getHeader and getXXXHeader methods i.e.
> > > force parsing of the header value when the user asks for the Header
> > > object. It was suggested that the getHeaders and getXXXHeaders methods
> > > (which return multiple headers) shouldn't throw a JainSipParseException,
> > > but that the methods for getting an individual header in the
> > > Enumeration/Iterator/Collection should throw the exception.
>

I think this sounds like a vast ease-of-use improvement for applications
trying to use the API.  It seems rather onerous to force an application
to catch, and theoretically deal intelligently with, a
JainSipParseException whenever it calls something as innocent as
hasQValue().

> > this seems reasonable now. trying to set an incorrect value would throw
> > a JainSipParseException and trying to parse a header would throw a
> > JainSipHeaderValueParseException (why not just
> > JainSipHeaderParseException though? shorter by a whole 5 letters :) )
>
> Sure - although I am starting to think that it might be better to add a header
> name field to the JainSipHeaderParseException rather than a header object
> field.
>

I think the header name is preferable since you might not be able to
construct a meaningful header object in the presence of a parsing error.

> > > If you are getting an optional parameter/header/body - you should not
> > > throw a
> > > ParameterNotSetException/HeaderNotSetException/BodyNotSetException since
> > > these are not exceptional cases - returning null is preferable, as seen
> > > in other APIs.
>

Yes, there is nothing exceptional about the absence of an optional
element.

Speaking of exceptions, it seems like IllegalArgumentException is used
to signal a null parameter being passed in to most methods.  Why not
throw the more precise NullPointerException instead?

--
Bryan Thale
Motorola Labs, Networking and Infrastructure Research
mailto:thale@labs.mot.com

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

--------------319CA0F72AE6FAE2C33B7AA2-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 15:19:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA03436 for ; Mon, 11 Dec 2000 15:19:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CD5CD4434A; Mon, 11 Dec 2000 14:19:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251]) by lists.bell-labs.com (Postfix) with ESMTP id 3D72A44336 for ; Mon, 11 Dec 2000 14:18:02 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id PAA07784; Mon, 11 Dec 2000 15:12:39 -0500 (EST) Message-ID: <3A35366F.D133F30F@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: Chris Harris Cc: jainsip@sun.com, sip@lists.bell-labs.com Subject: Re: [SIP] JAIN SIP discussions @ SIP Bakeoff References: <3A34FB22.1AE6280@dynamicsoft.com> Content-Type: multipart/alternative; boundary="------------029BBE8D8D441FB102D4173A" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 15:17:51 -0500 --------------029BBE8D8D441FB102D4173A Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Hi Chris, Thanks for posting this. With all due apologies to the Pillsbury dough boy, I was not able to attend (one has to have something to bake off in order to attend a bakeoff). However, opinionated as I am, I shall air opinions as usual, which are posted below.... Regards Ranga. Chris Harris wrote: > Folks, > > There were some in-depth discussions about the JAIN SIP API at the SIP > Bakeoff last week, and some interesting suggestions arose: > > If you are getting an optional parameter/header/body - you should not > throw a > ParameterNotSetException/HeaderNotSetException/BodyNotSetException since > these are not exceptional cases - returning null is preferable, as seen > in other APIs. I agree. IMHO Null is a very reasonable way of indicating that a parameter has not been set and it has ample precedence in several places in the java api (check out the sax parser for example). Throwing exceptions for conditions that are not exception conditions makes the application full of nested exceptions which is quite confusing to deal with. > > > The use of arrays for getting and setting multiple values is not nice at > all - why not return an Enumeration/Iterator? (Although according to the > Collections framework documentation it is preferable to pass a generic > Collection and return the most specific subinterface of Collection we > can - possibly SortedList?) Unsurprisingly, I agree again. I think that Collection is much preferable to array because it can be extended and additional functionality be provided as needed. Array cannot be extended. > > > Currently the JainSipProvider always passes a clone of a received > Message to an application. It was suggested that this is too > inefficient, and that it would be preferable to pass a reference to the > Message, and warn in the documentation that the API user must clone the > Message or part of it if they want to do anything other than get its > values. (Personally I find this approach unacceptable - I think it gives > the API user too much scope to mess with the internals of an API > implementation) IMHO this is not a problem. Put stuff in a separate package and make every field protected with get and set methods as you have done. Passing a reference is OK and makes life run a tad faster. > > > Currently get methods in Header interfaces throw a JainSipParseException > if the header value could not be parsed (i.e. an implementation is > allowed to delay parsing until the user asks for a particular part of a > header). It was suggested that it would be better to throw the > JainSipParseException on the getHeader and getXXXHeader methods i.e. > force parsing of the header value when the user asks for the Header > object. It was suggested that the getHeaders and getXXXHeaders methods > (which return multiple headers) shouldn't throw a JainSipParseException, > but that the methods for getting an individual header in the > Enumeration/Iterator/Collection should throw the exception. I think this makes sense - delay throwing the exception as much as possible. If this is returned as a collection, you would have to throw this exception for the next() method (NoSuchElementException (?)). > > > [Note that a JainSipParseException contains a String field called > unparsable - but do we need a JainSipParseException that includes a > reference to a Header object - since this will not be returned if the > exception is thrown? This would be particularly useful for the method > getHeaders() which returns all headers in a message - if the exception > is thrown with just the unparsable header value, then the application > has no way to determine the header name. The exception need only contain the header text (no need to include the header name). The exception handler can look at the first token to determine the header name. Its not tough to do. > So I suggest that there should > be a JainSipParseException subclass for this case of header value > lazy-parsing e.g. JainSipHeaderValueParseException (extends > JainSipParseException?) which has a getHeader() method - then the > application can call getName() and getValue() on this header object] Too fine grained (less complexity is better). A single parse exception which includes the entire header text is all that we need. > > > Do not need UndefinedHeader or UndefinedRequestMessage - does not add > any functionality to Header or RequestMessage. > > Do not need InviteMessage, AckMessage, ByeMessage, CancelMessage, > OptionsMessage or RegisterMessage - they add no extra functionality and > only differ by their method - RequestMessage is sufficient. Agree. Basically, all you need is SIPMessage, which is subclassed by RequestMessage and ReplyMessage. > > > Do not need header types - do not provide anything meaningful - header > types alone do not give enough information to do anything useful with an > unrecognised header - the default protocol behaviour is sufficient. I agree with this also. You can do everything with introspection providing header types is redundant. > > > Do not need setName() method in Header - it should be read-only. As you may expect, I would go one step further. You dont need setXXX . If you want to construct headers, just provide a header formatter interface (as I outlined in our previous discussion we had on this subject). You dont need to parse the input values at all because the other end will throw exception anyway (the end-to-end argument would make sense here). Perhaps you may say it is not OOcentric and maybe there is a point there but it is faster and simpler than have the applicaiton 1. do a set of each field and be prepared to catch exception and 2. have the jain sip implementation validate input values via the parser and 3. have the recipient re-validate the argument anyway. > > > I would be grateful if you could send any comments on these suggestions > immediately, so we can get the first public release out asap. I would welcome any move to reduce the size and complexity of the API. > > > Regards, > Chris Harris > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------029BBE8D8D441FB102D4173A Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Chris,

Thanks for posting this.

With all due apologies to the Pillsbury dough boy, I was not able to attend (one has to have something to bake off in order to attend a bakeoff). However, opinionated as I am, I shall air opinions as usual,  which are posted below....

Regards

Ranga.
 

Chris Harris wrote:

Folks,

There were some in-depth discussions about the JAIN SIP API at the SIP
Bakeoff last week, and some interesting suggestions arose:

If you are getting an optional parameter/header/body - you should not
throw a
ParameterNotSetException/HeaderNotSetException/BodyNotSetException since
these are not exceptional cases - returning null is preferable, as seen
in other APIs.


I agree. IMHO Null is a very reasonable way of indicating that a parameter has not been set and it has ample precedence in several places in the java api (check out the sax parser for example).  Throwing exceptions for conditions that are not exception conditions makes the application full of nested exceptions which is quite confusing to deal with.
 

 

The use of arrays for getting and setting multiple values is not nice at
all - why not return an Enumeration/Iterator? (Although according to the
Collections framework documentation it is preferable to pass a generic
Collection and return the most specific subinterface of Collection we
can - possibly SortedList?)


Unsurprisingly,  I agree again. I think that Collection is much preferable to array because it can be extended and additional functionality be provided as needed. Array  cannot be extended.
 
 

 

Currently the JainSipProvider always passes a clone of a received
Message to an application. It was suggested that this is too
inefficient, and that it would be preferable to pass a reference to the
Message, and warn in the documentation that the API user must clone the
Message or part of it if they want to do anything other than get its
values. (Personally I find this approach unacceptable - I think it gives
the API user too much scope to mess with the internals of an API
implementation)


IMHO this is not a  problem. Put stuff in a separate package and make every field protected with get and set methods as you have done.  Passing a reference is OK and makes life run a tad faster.
 

 

Currently get methods in Header interfaces throw a JainSipParseException
if the header value could not be parsed (i.e. an implementation is
allowed to delay parsing until the user asks for a particular part of a
header). It was suggested that it would be better to throw the
JainSipParseException on the getHeader and getXXXHeader methods i.e.
force parsing of the header value when the user asks for the Header
object. It was suggested that the getHeaders and getXXXHeaders methods
(which return multiple headers) shouldn't throw a JainSipParseException,
but that the methods for getting an individual header in the
Enumeration/Iterator/Collection should throw the exception.

I think this makes sense - delay throwing the exception as much as possible. If this is returned as a collection, you would have to throw this exception for the next() method  (NoSuchElementException (?)).
 
 

[Note that a JainSipParseException contains a String field called
unparsable - but do we need a JainSipParseException that includes a
reference to a Header object - since this will not be returned if the
exception is thrown? This would be particularly useful for the method
getHeaders() which returns all headers in a message - if the exception
is thrown with just the unparsable header value, then the application
has no way to determine the header name.


The exception need only contain the header text (no need to include the header name). The exception handler can look at the first token to determine the header name.   Its not tough to do.
 
 

So I suggest that there should
be a JainSipParseException subclass for this case of header value
lazy-parsing e.g. JainSipHeaderValueParseException (extends
JainSipParseException?) which has a getHeader() method - then the
application can call getName() and getValue() on this header object]

Too fine grained (less complexity is better).  A single parse exception which includes the entire header text is all that we need.
 
 

 

Do not need UndefinedHeader or UndefinedRequestMessage - does not add
any functionality to Header or RequestMessage.

Do not need InviteMessage, AckMessage, ByeMessage, CancelMessage,
OptionsMessage or RegisterMessage - they add no extra functionality and
only differ by their method - RequestMessage is sufficient.

Agree. Basically, all you need is SIPMessage,  which is subclassed by RequestMessage and ReplyMessage.
 

 

Do not need header types - do not provide anything meaningful - header
types alone do not give enough information to do anything useful with an
unrecognised header - the default protocol behaviour is sufficient.


I agree with this also. You can do everything with introspection  providing header types is redundant.

 

Do not need setName() method in Header - it should be read-only.


As you may expect, I would go one step further. You dont need setXXX .  If you want to construct headers, just provide a header formatter interface (as  I outlined in our previous  discussion we had  on this subject).   You dont need to parse the input values at all because the other end will throw exception anyway (the end-to-end argument would make sense here).  Perhaps you may say it is not OOcentric and maybe there is a point there but it is faster and simpler than have the applicaiton 1. do a set of each field and be prepared to catch exception  and 2. have the jain sip implementation  validate input values via the parser and 3. have the recipient re-validate the argument anyway.

 

I would be grateful if you could send any comments on these suggestions
immediately, so we can get the first public release out asap.


I would welcome any move to reduce the size and complexity of the API.
 
 

 

Regards,
Chris Harris

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------029BBE8D8D441FB102D4173A-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 15:29:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05559 for ; Mon, 11 Dec 2000 15:29:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 373B04434A; Mon, 11 Dec 2000 14:29:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 08ACB44339 for ; Mon, 11 Dec 2000 14:28:46 -0500 (EST) Received: from CINQUECENTO ([207.137.72.234]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id PAA07545; Mon, 11 Dec 2000 15:30:57 -0500 (EST) From: "Robert Sparks" To: "Rohan Mahy" , Cc: Subject: RE: [SIP] summary for the week of Nov 12-18 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0006_01C0637E.5FBB3F70" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-Reply-To: <4.1.20001210153934.00cce8e0@imop.cisco.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 14:26:38 -0600 This is a multi-part message in MIME format. ------=_NextPart_000_0006_01C0637E.5FBB3F70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ftr - I think that was Robert Fairle-Cuninghame instead of me. - Another thread on ringback tone devolved into a discussion on 180 w/ early media vs. 183. Robert Sparks summarized the thread consensus best "if a PSTN gateway knows that the callee is being alerted then it should send a 180 with (or without) SDP. Otherwise, if the PSTN gateway only knows that inband call progress tones are being provided by the PSTN network (but not the callee alerting state) then ... 183 is more appropriate." ------=_NextPart_000_0006_01C0637E.5FBB3F70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
ftr - = I think=20 that was Robert Fairle-Cuninghame = instead of=20 me.
 
- Another thread on = ringback tone=20 devolved into a discussion on 180 w/ early media vs. 183.  =
Robert=20 Sparks summarized the thread consensus best "if a PSTN gateway knows = that the=20 callee is being alerted then it should send a 180 with (or without) SDP. = Otherwise, if the PSTN gateway only knows that inband call progress = tones are=20 being provided by the PSTN network (but not the callee alerting state) = then ...=20 183 is more appropriate."
------=_NextPart_000_0006_01C0637E.5FBB3F70-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 15:41:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07298 for ; Mon, 11 Dec 2000 15:41:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1062244341; Mon, 11 Dec 2000 14:41:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtprch1.nortel.com (smtprch1.nortelnetworks.com [192.135.215.14]) by lists.bell-labs.com (Postfix) with ESMTP id 290DA44337 for ; Mon, 11 Dec 2000 14:40:40 -0500 (EST) Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Mon, 11 Dec 2000 14:40:06 -0600 Received: by zrchb200.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 11 Dec 2000 14:39:58 -0600 Message-ID: From: "Don Jackson" To: "'sip@lists.bell-labs.com'" Importance: high X-Priority: 1 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C063B2.81582560" Subject: [SIP] Delete name from mailing list Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 14:39:49 -0600 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_01C063B2.81582560 Content-Type: text/plain; charset="iso-8859-1" Please delete my name from this mail list. djackson@nortelnetworks.com -----Original Message----- From: sip-request@lists.bell-labs.com [mailto:sip-request@lists.bell-labs.com] Sent: Saturday, December 09, 2000 8:50 PM To: sip@lists.bell-labs.com Subject: SIP digest, Vol 1 #603 - 1 msg Send SIP mailing list submissions to sip@lists.bell-labs.com To subscribe or unsubscribe via the World Wide Web, visit http://lists.bell-labs.com/mailman/listinfo/sip or, via email, send a message with subject or body 'help' to sip-request@lists.bell-labs.com You can reach the person managing the list at sip-admin@lists.bell-labs.com When replying, please edit your Subject line so it is more specific than "Re: Contents of SIP digest..." ------_=_NextPart_001_01C063B2.81582560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Delete name from mailing list

Please delete my name from this mail list.  = djackson@nortelnetworks.com

-----Original Message-----
From: sip-request@lists.bell-labs.com
[mailto:sip-request@lists= .bell-labs.com]
Sent: Saturday, December 09, 2000 8:50 PM
To: sip@lists.bell-labs.com
Subject: SIP digest, Vol 1 #603 - 1 msg


Send SIP mailing list submissions to
        sip@lists.bell-labs.com

To subscribe or unsubscribe via the World Wide Web, = visit
        http://lists.bell-labs.com/mailman/listinfo/sip
or, via email, send a message with subject or body = 'help' to
        sip-request@lists.bell-labs.com

You can reach the person managing the list at
        sip-admin@lists.bell-labs.com

When replying, please edit your Subject line so it is = more specific
than "Re: Contents of SIP = digest..."

------_=_NextPart_001_01C063B2.81582560-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 15:53:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA08671 for ; Mon, 11 Dec 2000 15:53:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CBF3D4435F; Mon, 11 Dec 2000 14:53:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.mediatrix.com (mail.mediatrix.com [205.237.248.11]) by lists.bell-labs.com (Postfix) with ESMTP id 4583F44341 for ; Mon, 11 Dec 2000 14:52:30 -0500 (EST) Received: by mail.mediatrix.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 15:52:48 -0500 Message-ID: From: Eric Tremblay To: "'Jonathan Rosenberg'" , "'Fairlie-Cuninghame, Robert'" , "Henning G. Schulzrinne" , Billy Biggs , sip@lists.bell-labs.com Subject: RE: [SIP] Re: My comments on bis-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 15:52:48 -0500 > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Saturday, December 09, 2000 17:17 > To: 'Fairlie-Cuninghame, Robert'; Jonathan Rosenberg; Henning G. > Schulzrinne; Billy Biggs; sip@lists.bell-labs.com > Subject: RE: [SIP] Re: My comments on bis-02 > > > > > > > > -----Original Message----- > > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > Sent: Wednesday, December 06, 2000 12:21 AM > > To: 'Jonathan Rosenberg'; Henning G. Schulzrinne; Billy Biggs; > > sip@lists.bell-labs.com > > Subject: RE: [SIP] Re: My comments on bis-02 > > > > > > > > > 5. Due to the proliferation of the Also header in BYE > > > > requests, I would > > > > > suggest that it be added to the bis draft, with its meaning > > > > > restricted to use with the BYE method. > > > > > > > > Tentatively added. > > > > > > Hold on a sec.... BYE/Also is in a draft that has expired a > > > long time ago. I > > > thought we revisited this and came up with the REFER > > > mechanism. Also, AFAIK, > > > has been discarded, along with its usage in BYE. I don't know what > > > proliferation you are talking about. > > > > Jonathan, > > > > It is such a simple yet useful mechanism (that I beleive quite a few > > implementations support), isn't it reasonable to leave it in > > the bis draft > > even though it does overlap (or is a subset of) the > > functionality of the ful > > blown REFER. > > I think it is confusing and will ultimately lead to interoperability > problems. > > I am sorry that there are implementations that choose to ship > products based > on -00 drafts that are experimental in nature. The BYE/Also > mechanism has > issues, and we have resolved these in the REFER draft. I totally agree with Jonathan. I think the standard should be "technically driven" (addendum and modifications to the specs for technical reasons) instead of being driven by the fact that people have already implemented a draft. A draft is bound to change, and it can always be dropped. Let's see it that way: It is easier to remove code than to add. Since people will be supporting the REFER spec anyway sooner or later, then why add the burden for future developers to support the BYE(Also) service? If we leave it in the spec, then it will be used and we will be running head first into interop problems. This is just a short term patch for those that don't yet support REFER, and a patch should not make it to a standard. If this makes it to the specs, then we will have to decide where to draw the line. Do the SIP WG wants to always have to cope with vendors that have implemented and sold a draft version of a spec and modify the standard accordingly? We are talking about a standard that could (I hope!) have a very long life, and things can easily get ugly in the long term if we decide to add something in the draft only because "some implementations already support it and it once was a draft (that was dropped!)". I need a much better reason than this to convince me that this should get into the SIP standard. My 5 cents, EricT > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 20:32:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA22767 for ; Mon, 11 Dec 2000 20:32:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C4A3544337; Mon, 11 Dec 2000 19:32:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 9BC4544336 for ; Mon, 11 Dec 2000 19:31:05 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 11 Dec 2000 17:30:47 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , sip@lists.bell-labs.com Subject: RE: [SIP] Re: My comments on bis-02 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 17:30:42 -0800 > > > > I am sorry that there are implementations that choose to ship > > products based > > on -00 drafts that are experimental in nature. The BYE/Also > > mechanism has > > issues, and we have resolved these in the REFER draft. > Hi Jonathan, I think this statement is being a little harsh. Companies wanting to be a step ahead of the curve will obviously want to add things above and beyond what is set in concrete in the core SIP spec (which is still a moving target in terms of compliance). I dont think there is anything wrong with this - __in the commercial world__ you can't begrudge companies for wanting to release products with differentiated feature sets. I don't see any difference between a company coming up with propretary additions and implementing standards still in a draft stage as long as they don't affect core SIP compatibility. The BYE/Also is a good example. If the BYE/Also is not adopted by IETF then UA's who have implemented this will not suddenly be incompatible or cause problems with or UA/proxies not supporting this. So a year ago, if a company needed to add blind transfer capability, why shouldn't they have implemented the BYE/Also draft rather than coming up with a proprietary scheme BYE/MyAlso ? [I am just asking a question and _not_ advocating that BYE/Also should be added to the draft (which I agree should not be driven only by the realities of commerical world).] I understand that it is undesirable from a techical standpoint that companies add "extra bits" but in real world, being "sorry that there are implementations that choose to ship products based on -00 drafts that are experimental in nature" is an unrealistic expectation. [Feel free not to reply to this email as it is now more a philosphical than technical argument.] Please note, I am not (and was not) infering or refering to any capabilties about any product produced by the company owning the domain of my email address. It would be a mistake to assume so. Regards, Robert. -- My opinions are my own. I tried selling them once but everybody seems to already have one. -- > > I totally agree with Jonathan. I think the standard should > be "technically > driven" (addendum and modifications to the specs for > technical reasons) > instead of being driven by the fact that people have already > implemented a > draft. A draft is bound to change, and it can always be dropped. > > Let's see it that way: It is easier to remove code than to add. Since > people will be supporting the REFER spec anyway sooner or > later, then why > add the burden for future developers to support the BYE(Also) > service? If > we leave it in the spec, then it will be used and we will be > running head > first into interop problems. This is just a short term patch > for those that > don't yet support REFER, and a patch should not make it to a standard. > > If this makes it to the specs, then we will have to decide > where to draw the > line. Do the SIP WG wants to always have to cope with vendors > that have > implemented and sold a draft version of a spec and modify the standard > accordingly? We are talking about a standard that could (I > hope!) have a > very long life, and things can easily get ugly in the long > term if we decide > to add something in the draft only because "some > implementations already > support it and it once was a draft (that was dropped!)". I > need a much > better reason than this to convince me that this should get > into the SIP > standard. > > My 5 cents, > > EricT > > > > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 11 22:18:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14433 for ; Mon, 11 Dec 2000 22:18:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D63944338; Mon, 11 Dec 2000 21:18:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from c000.snv.cp.net (c000-h008.c000.snv.cp.net [209.228.32.72]) by lists.bell-labs.com (Postfix) with SMTP id 93BAC44336 for ; Mon, 11 Dec 2000 21:17:02 -0500 (EST) Received: (cpmta 16837 invoked from network); 11 Dec 2000 19:16:52 -0800 Received: from ietf.207.137.71.33.tx.verio.net (HELO sbarberlaptop) (207.137.71.33) by smtp.barber.net (209.228.32.72) with SMTP; 11 Dec 2000 19:16:52 -0800 X-Sent: 12 Dec 2000 03:16:52 GMT Message-ID: <01bc01c063e9$855d7c00$214789cf@sbarberlaptop> From: "Simon Barber" To: "Eric Tremblay" , "'Jonathan Rosenberg'" , "'Fairlie-Cuninghame, Robert'" , "Henning G. Schulzrinne" , "Billy Biggs" , References: Subject: Re: [SIP] Re: My comments on bis-02 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 11 Dec 2000 19:13:37 -0800 Content-Transfer-Encoding: 7bit Eric - can I say I agree very much with this view - we should not be tied by supporting previous drafts - this will end up making a very messy protocol. We are, of course, bound to support previous versions of the RFC, and we should ensure that implementations of RFC2543 work with any new RFC, but we CAN deprecate features from new implementations. BYE has it's problems, and we must continue to support it for RFC2543 implementations, warts and all - but we should use a completely new mechanism, if it makes sense technically, rather than extending the broken BYE for the new RFC. Simon ----- Original Message ----- From: "Eric Tremblay" To: "'Jonathan Rosenberg'" ; "'Fairlie-Cuninghame, Robert'" ; "Henning G. Schulzrinne" ; "Billy Biggs" ; Sent: Monday, December 11, 2000 12:52 PM Subject: RE: [SIP] Re: My comments on bis-02 > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Saturday, December 09, 2000 17:17 > > To: 'Fairlie-Cuninghame, Robert'; Jonathan Rosenberg; Henning G. > > Schulzrinne; Billy Biggs; sip@lists.bell-labs.com > > Subject: RE: [SIP] Re: My comments on bis-02 > > > > > > > > > > > > > > > -----Original Message----- > > > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > > > Sent: Wednesday, December 06, 2000 12:21 AM > > > To: 'Jonathan Rosenberg'; Henning G. Schulzrinne; Billy Biggs; > > > sip@lists.bell-labs.com > > > Subject: RE: [SIP] Re: My comments on bis-02 > > > > > > > > > > > > 5. Due to the proliferation of the Also header in BYE > > > > > requests, I would > > > > > > suggest that it be added to the bis draft, with its meaning > > > > > > restricted to use with the BYE method. > > > > > > > > > > Tentatively added. > > > > > > > > Hold on a sec.... BYE/Also is in a draft that has expired a > > > > long time ago. I > > > > thought we revisited this and came up with the REFER > > > > mechanism. Also, AFAIK, > > > > has been discarded, along with its usage in BYE. I don't know what > > > > proliferation you are talking about. > > > > > > Jonathan, > > > > > > It is such a simple yet useful mechanism (that I beleive quite a few > > > implementations support), isn't it reasonable to leave it in > > > the bis draft > > > even though it does overlap (or is a subset of) the > > > functionality of the ful > > > blown REFER. > > > > I think it is confusing and will ultimately lead to interoperability > > problems. > > > > I am sorry that there are implementations that choose to ship > > products based > > on -00 drafts that are experimental in nature. The BYE/Also > > mechanism has > > issues, and we have resolved these in the REFER draft. > > > I totally agree with Jonathan. I think the standard should be "technically > driven" (addendum and modifications to the specs for technical reasons) > instead of being driven by the fact that people have already implemented a > draft. A draft is bound to change, and it can always be dropped. > > Let's see it that way: It is easier to remove code than to add. Since > people will be supporting the REFER spec anyway sooner or later, then why > add the burden for future developers to support the BYE(Also) service? If > we leave it in the spec, then it will be used and we will be running head > first into interop problems. This is just a short term patch for those that > don't yet support REFER, and a patch should not make it to a standard. > > If this makes it to the specs, then we will have to decide where to draw the > line. Do the SIP WG wants to always have to cope with vendors that have > implemented and sold a draft version of a spec and modify the standard > accordingly? We are talking about a standard that could (I hope!) have a > very long life, and things can easily get ugly in the long term if we decide > to add something in the draft only because "some implementations already > support it and it once was a draft (that was dropped!)". I need a much > better reason than this to convince me that this should get into the SIP > standard. > > My 5 cents, > > EricT > > > > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 12 01:25:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28541 for ; Tue, 12 Dec 2000 01:25:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F393744341; Tue, 12 Dec 2000 00:25:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 6045644336 for ; Tue, 12 Dec 2000 00:24:07 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id MAA02717 for ; Tue, 12 Dec 2000 12:29:30 -0600 Message-ID: <003501c06403$cb49ba20$e64a89cf@dynamicsoft.com> From: "Dean Willis" To: "IETF SIP (E-mail)" References: <008601c05e4c$797a0860$ea036e3f@dynamicsoft.com> 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: [SIP] Planned Bar-BOF on SIP Security, Thursday 14, 2000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 12 Dec 2000 00:21:41 -0600 Content-Transfer-Encoding: 7bit Please note, the slides I showed during the Monday SIP session incorrectly indicated the Security BOF on Wednesday at 2200. The correct (according to the original posting) time is Thursday at 2000. -- Dean Willis, the Temporally Dislocated. ----- Original Message ----- From: "Dean Willis" To: "IETF SIP (E-mail)" Sent: Monday, December 04, 2000 5:38 PM Subject: [SIP] Proposed Bar-BOF on SIP Security, Thursday 14, 2000 > > I would like to propose a bar-BOF -- location TBD -- for the SIP Security > Task Foce on Thursday night at 2000. > > -- > Dean > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 12 02:23:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26066 for ; Tue, 12 Dec 2000 02:23:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 52BBC4433A; Tue, 12 Dec 2000 01:23:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 888ED44336 for ; Tue, 12 Dec 2000 01:22:33 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA11823 for ; Tue, 12 Dec 2000 02:24:47 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 02:19:59 -0500 Message-ID: From: Brian Bascom To: "'sip@lists.bell-labs.com'" , Dean Willis Subject: [SIP] Thread summary: 11/19-11/25 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 12 Dec 2000 02:19:54 -0500 SIP list thread starting from 11/19 through 11/25. 11/19/2000 Record-Route consensus - Robert Fairlie-Cuninghame restarted old discussion about proposed Record-Route changes, including handling non-SIP URIs, the "stack-popping" behavior preventing proxies from seeing earlier headers and losing state info, and detecting new parameters in Record-Route. Strong discussion of not allowing non-SIP URIs in the Record-Route. Only apparent consensus: UAS should not "mangle" the reverse Record Route. Very lively discussion, still ongoing (although thread changed a couple of times, including "New Section 6.34"). 11/19/2000 New I-D on multiparty conferencing models - Jonathan Rosenberg submitted draft on six ways to do multiparty conferencing with "vanilla" SIP. Brought under serious fire as regards assumptions about SIP UA behavior not specified in the rfc. 11/20/2000 Spaces in SIP URL - Sreenivasa Reddy D. asked if spaces (and by extension, line breaks) are allowed in SIP URLs. rfc 2396 prohibits in URLs, although escaped spaces allowed. 11/20/2000 URL Comparison - Stuart Wray pointed out inconsistencies in 2543bis draft concerning matching of URL parameters, and use of A records with default SIP port 5060. Authors admitted some textual errors, but issue of omitting ports discussed. 11/20/2000 VIA Response - Uri Baniel wondered how a response to a multicast request should be returned 11/21/2000 SIP Extensions for Presence - Hisham Khartabil asked a number of questions about transferring subscriptions without waiting for timeouts and responding to Contact-less SUBSCRIBES with 4XX messages rather than simply failing to act on the SUBSCRIBE 11/21/2000 Registration Question - Bill Moloney asked if a redirect such as 301 Moved Permanently occurs, what is the scope of that action? Only MUST impact the current transaction, but MAY impact future similar transactions (depending on implementation). 11/21/2000 More Torture Test Messages Available - Neil Deason added more Bakeoff stumpers to the list 11/21/2000 Deprecate Early Media - Billy Biggs described problems with media arriving before the 200 OK, raising the question again for attention. General agreement. 11/21/2000 Changing CODEC - Mo Zonoun asked how to change codecs without disrupting the established call. For sending codec, any listed in SDP can be used; for codec to receive from, need to re-INVITE and include different codec choices. Disagreement on whether to end call if re-INVITED party can't support new codec, or use existing codec and reject re-INVITE. 11/21/2000 I-Ds - Gerhard Gross announced two QoS I-Ds: QoS and AAA Usage with SIP based IP Communications, and COPS Usage for SIP. 11/21/2000 New I-D: draft-hamer-sip-session-auth-00.txt - Louis-Nicolas Hamer requested comments on his I-D dealing with session setup with media authorization. 11/22/2000 Multi-proxy authentication deadlock - Alexandre Charest requested an example of the deadlock situation arising from an expired challenge after a successful response. 11/22/2000 Via procession rules - Hisham Khartabil asked about what a UAC is expected to do when processing a response with more than its own VIA headers. Answer: it shouldn't be receiving more than its own (UA was acting as UAS, not UAC, or was broken). 11/22/2000 I-D ACTION:draft-rosenberg-sip-entfw-00.txt - Internet-Drafts announced availability of SIP Traversal through Residential and Enterprise NATs and Firewalls. Some comments on divergence from "typical" web traffic patterns causing problems. 11/22/2000 INVITE/200 OK/BYE or INVITE/200 OK/ACK/BYE? - Vijay Gurbani posed the question as to the proper response to contemporaneous 200 OKs received by a forking proxy. Latter is correct; ambiguity in bis draft acknowledged. 11/22/2000 Multiple location - Sanjiv Deshpande asked whether a UAS receiving a forked INVITE can, after responding to the forked INVITE but before receiving an ACK, make another call. Received brusque response from Jonathan Rosenberg concerning protocol versus implementation; moderate third-party flame ensued. 11/22/2000 draft-rosenberg-sip-app-components-00.txt - Gonzalo Camarillo raised the point that TSS services work similarly to MCU services (which require one INVITE per party), so the correct way to invite for TSS is with two INVITES instead of one INVITE containing two media descriptions. 11/22/2000 Preview of draft-calhoun-sip-aaa-reqs-00.txt - Tony Johansson announced updated version of AAA Requirements for IP Telephony/Multimedia. 11/22/2000 New ISUP mapping draft - Adam Roach announced new ISUP to SIP mapping draft. 11/22/2000 New SUBSCRIBE/NOTIFY draft available - Adam Roach announced new draft incorporating changes to the -01 draft. 11/22/2000 The parser - Robert Kajun asked how the SIP parser should operate, and whether the @ character could be escaped. 11/22/2000 Help with sip - Arun Kumar Chippada asked if it is possible to run SIP Proxy Server and SIP UA on same machine. Yes, it is. 11/23/2000 Inviting users to join a centralized conference - Ya-Ching Tan asked whether using REFER method to inviting users to a conference was intentionally omitted. No, it was omitted unintentionally and will be included in next draft. 11/23/2000 Multiple headers of a given type - M. Ranganathan asked for a list of SIP headers that can appear multiple times in a message. Any header whose BNF begins with # can appear multiple times. 11/24/2000 NEW I-D: fid SDP attribute - Gonzalo Camarillo announced a new version of the SDP media alignment draft. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 12 12:25:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA29470 for ; Tue, 12 Dec 2000 12:25:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C4A0744337; Tue, 12 Dec 2000 11:25:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from nmh.informatik.uni-bremen.de (nmh.informatik.uni-bremen.de [134.102.224.3]) by lists.bell-labs.com (Postfix) with ESMTP id 91CE444336 for ; Tue, 12 Dec 2000 11:24:27 -0500 (EST) Received: from plumps (daemon.informatik.uni-bremen.de [134.102.218.45]) by nmh.informatik.uni-bremen.de (8.10.1/8.10.1) with SMTP id eBCHO3912033; Tue, 12 Dec 2000 18:24:04 +0100 (MET) Message-Id: <200012121724.eBCHO3912033@nmh.informatik.uni-bremen.de> X-Sender: jo@127.0.0.1 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 To: "Dean Willis" , "IETF SIP (E-mail)" From: Joerg Ott Subject: Re: [SIP] Planned Bar-BOF on SIP Security, Thursday 14, 2000 Cc: confctrl@isi.edu In-Reply-To: <003501c06403$cb49ba20$e64a89cf@dynamicsoft.com> References: <008601c05e4c$797a0860$ea036e3f@dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 12 Dec 2000 18:22:42 +0100 Thanks for the clarification. We have planned an SDPng bar discussion on Wednesday at 2200 -- so there is no overlap anymore. >Please note, the slides I showed during the Monday SIP session incorrectly >indicated the Security BOF on Wednesday at 2200. The correct (according to >the original posting) time is Thursday at 2000. Joerg _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 12 12:30:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA00605 for ; Tue, 12 Dec 2000 12:30:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B76C4433D; Tue, 12 Dec 2000 11:30:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtp2.gtsgroup.com (smtp2.gtsgroup.com [195.158.230.80]) by lists.bell-labs.com (Postfix) with SMTP id 5743944336 for ; Tue, 12 Dec 2000 04:19:44 -0500 (EST) Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 11:19:30 +0100 Message-ID: From: "Agboh, Charles" To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] static payload types Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 12 Dec 2000 11:19:28 +0100 Hi, Is the use of static RTP payload types in SDP discouraged for SIP? If yes, then why? -charles _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 12 12:42:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03168 for ; Tue, 12 Dec 2000 12:42:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 123BA44346; Tue, 12 Dec 2000 11:42:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 3501344336 for ; Tue, 12 Dec 2000 11:41:41 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA09781; Tue, 12 Dec 2000 12:41:31 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id MAA00147; Tue, 12 Dec 2000 12:41:31 -0500 (EST) Message-ID: <3A368E6D.C0CED035@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Agboh, Charles" Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] static payload types References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 12 Dec 2000 12:45:33 -0800 Content-Transfer-Encoding: 7bit RTP discourages the use of static payload types - period, regardless of the protocol used. Obviously, there's nothing wrong with using the 'static' values in fmtp. Static payload types are a BAD IDEA. "Agboh, Charles" wrote: > > Hi, > > Is the use of static RTP payload types in SDP discouraged for SIP? If yes, > then why? > > -charles > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 12 12:56:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06778 for ; Tue, 12 Dec 2000 12:56:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 735EE4433C; Tue, 12 Dec 2000 11:56:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E90BC44336 for ; Tue, 12 Dec 2000 11:55:18 -0500 (EST) Received: from CINQUECENTO (ietf.207.137.73.167.tx.verio.net [207.137.73.167]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id MAA15589 for ; Tue, 12 Dec 2000 12:57:42 -0500 (EST) From: "Robert Sparks" To: 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.2416 (9.0.2910.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal Subject: [SIP] Solving the REFER retransmit issue Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 12 Dec 2000 11:53:22 -0600 Content-Transfer-Encoding: 7bit The presentation of status of REFER and the discussion of the REFER timeout issue is at http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-cc-transfe r-02.htm Rohan Mahy also proposed an optimization of 2 where the REFER was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress of the REFERed action would just happen and could be ignored/481'ed if the the REFERing agent didn't care. Jonathan R. stated that 2) requires any agent accepting a REFER to implement being an event server (must implement accepting and managing subscriptions), and this is asking too much. Discussion? RjS _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 12 13:08:53 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10427 for ; Tue, 12 Dec 2000 13:08:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F14F244342; Tue, 12 Dec 2000 12:08:24 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 2287D44336 for ; Tue, 12 Dec 2000 12:05:09 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA08755; Tue, 12 Dec 2000 10:05:03 -0800 (PST) Received: from sony-laptop (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with SMTP id AAC93666; Tue, 12 Dec 2000 10:04:47 -0800 (PST) Message-Id: <4.1.20001212100548.02464b90@imop.cisco.com> Message-Id: <4.1.20001212100548.02464b90@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: rohan@cisco.com, dean.willis@softarmor.com, brian.rosen@marconi.com From: Rohan Mahy Cc: sip@lists.bell-labs.com Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=====================_352329970==_" Subject: [SIP] peer to peer 3pcc presentation for IETF san diego Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 12 Dec 2000 10:07:42 -0800 --=====================_352329970==_ Content-Type: text/plain; charset="us-ascii" --=====================_352329970==_ Content-Type: application/vnd.ms-powerpoint; name="mahy-sip-peer-3pcc.ppt" Content-Disposition: attachment; filename="mahy-sip-peer-3pcc.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAAQAAAAnAcAAAAAAAAA EAAA/v///wAAAAD+////AAAAAIwHAACNBwAAjgcAAI8HAACQBwAAkQcAAJIHAACTBwAAlAcAAJUH AACWBwAAlwcAAJgHAACZBwAAmgcAAJsHAAD///////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////+g Rh3wEQwAAPpgpnvDxOKy9pFPDAbz243//9j/4AAQSkZJRgABAgEAYABgAAD//gAmRmlsZSB3cml0 dGVuIGJ5IEFkb2JlIFBob3Rvc2hvcKggNS4w/+4ADkFkb2JlAGRAAAAAAf/bAIQAAQEBAQEBAQEB AQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQICAgICAgICAgICAwMDAwMDAwMDAwEB AQEBAQEBAQEBAgIBAgIDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMD/8AAEQgAEACPAwERAAIRAQMRAf/dAAQAEv/EAaIAAAAGAgMBAAAAAAAAAAAAAAcIBgUE CQMKAgEACwEAAAYDAQEBAAAAAAAAAAAABgUEAwcCCAEJAAoLEAACAQMEAQMDAgMDAwIGCXUBAgME EQUSBiEHEyIACDEUQTIjFQlRQhZhJDMXUnGBGGKRJUOhsfAmNHIKGcHRNSfhUzaC8ZKiRFRzRUY3 R2MoVVZXGrLC0uLyZIN0k4Rlo7PD0+MpOGbzdSo5OkhJSlhZWmdoaWp2d3h5eoWGh4iJipSVlpeY mZqkpaanqKmqtLW2t7i5usTFxsfIycrU1dbX2Nna5OXm5+jp6vT19vf4+foRAAIBAwIEBAMFBAQE BgYFbQECAxEEIRIFMQYAIhNBUQcyYRRxCEKBI5EVUqFiFjMJsSTB0UNy8BfhgjQlklMYY0TxorIm NRlUNkVkJwpzg5NGdMLS4vJVZXVWN4SFo7PD0+PzKRqUpLTE1OT0laW1xdXl9ShHV2Y4doaWprbG 1ub2Z3eHl6e3x9fn90hYaHiImKi4yNjo+DlJWWl5iZmpucnZ6fkqOkpaanqKmqq6ytrq+v/aAAwD AQACEQMRAD8A0z838Avkttw9XnN4Pr7Hxd35FMZ0zVyd19Oy0HaE1TjFymPn2pkKbfE1FLRZWOqo 4aaaqkpUlqsjSQ3Ek6L7917pqyXwa+ROE7M3H07nMHsfB9kbO2TF2JvDbeY7f6nx3919oGKauq8r mM1U7zj29CcVhIkyVXAlXJUQY6eGdk0SLf3Xus2W+C/yCwO1th76zNF1rjtjdo5WjwnXO86juvqL +7e8cpW09XOtJjMlHvR0pWppKGSGdqwUqQ1A8bkG9vde655f4GfJnb/a9D0ZuDaW0sH23kdoZTfV HsnK9tdS0lZJtrDK9Vkq18s+9v7t081Ph6aqyPgkrUnbHUFVOEKQPb3Xuo+T+D3fWH64wncmSi6x p+oty5zEbawHZY7r6lqNp5PP5fKPiRiY6yl3jNVU1Ti6qmqWrzUQwx0UNHUSSsqRMffuvdS9zfAn 5ObN7G2F1FunaG1cL2T2hjshl9g7Uqu2ep3qdyY2ikp4KeqpcnTb1nwNKM5UyyRY5KmrgkrpKWcR K3iPv3Xuir5rbeRwm5chtN5Mdl8rjstLhS+2Mrj90YzI18VR9qBhMvgaivxucp6ifiGaklminuDG zAgn3XujdSfy/Pkgmzt+7qjxWx6vJ9WYnH5zsvrih7J2ZWdpbCxeUhapopt2bKp8tJX4WtelRnah mZcghVo2gEytGPde6Fn5K9QfObs/enxM6e7c60wdJ2BkOqMf170jszbS7Xo8xVbM2lLVRpV7sqsd lqyioayGip2qqh6mpgp6WlRpWigYz3917opXZXxw3/1rHsmoev2Vv+j7D3LunZW1azqjd+K7EjyG 9NmVO26XcO0jT7feeviz1LJvDFtDC0NqyOuhemaVHDe/de6E/cPwO+QG2utuxOzK2n6+raLqB6GP tramB7O2TuDfnWkmQmFPDBvLbGHy9ZPiK+Kc6J6Qu1ZTyJJHJEskE6xe6904ba/l8/JDcz7OxEeM 2Pg9/wDY206jfPXvUm6+xto7a7U3ltSGnnqo8vi9oZXJQVNDHXQUdQ9PFkHop5kpZmVCsTsPde6J znsDmtrZzMba3Jiq/B7h29lK/C5zC5Sllosnicvi6qWiyONyFHOqT0tbRVcDxyxuAyOpBFx7917o wvTfxI7g7sx+Aze349m7V27u7dB2PszcPZe+Nt7Bxu995jxBtsbKiz1dBld25SKSdI5f4fTVEME8 iQyyJLJGje69060Xwp+QM+7e3tq5XbeE2pD0JURU3b+8t2bt25hOvtjzVbxx4uHIbwmyD4qurc1J NGtFSUTVVZUNIoWK97e691G3r8MPkNsjc/V+2JtmU+6G7up1q+n9w7H3Bgt17Q7HpzFFO7ba3PjK 98U80EE6SSw1L088MUiO6Kjqx917oc4/5U3zUlrN54cde7d/vLsnBY3cNbtFOxNk1G68xQZDFUmU d9t4OlzU9Zl0oXrBRyTqFpJcjHJTU808sbKPde6D/d38vP5TbM65272fkdlYXJbf3BvHB7Bak21v Xae5c1t7d+5cjTYjB4HddDhstVxYDIVuXroKR45pddHVzxw1QgldVPuvdf/Q14fjJ3X1Tvf+XVlJ e6JabJ7u/l+dp4btDqrFVvjmk3O25Jco3WG0cisksVXkdtV/Y2QnpcnAnlSLGUlOGARF0+691J+e 3f8A1pv34w9SfJLbctLF8gvlv1BgemOw0oHpYTh9q9U7qbN9rVBpqZmlpKrcO/qLGYyF3SFqjCQt GCY9SD3Xuk58Hez+me0fgn3n0V8jnSv278Xd1bd+TmzMZM0f3Oa25R7ggmzexsWuoGKPc24amowU 87DVF/fUMpJUBfde6X3yt+UGwu3fhb1V8u6iaih+UnYfXe+vh/nKfFLDSLj45cxh8t2buL7WKcyU kLbLNXTU9OjPHFS7/GoAqoHuvdBL/Lf391T2l8aPlX8PvkPmqjEdbY/AJ8jMNmKYwnKYaj2NWYet 39Dg3qpYwMi0eIxstLTxENKJqzg62B917od+3Pln1l3D8H9r/LqpxWK2r8iup85238ZutNu4COGh odvSdtYxqXG1lHDCTULR7D6SeWbFVDIVhzML6WR3JPuvdE86f+NNH8S+wP5evym7g7D66ynWPcu8 9sbwNJj6meoqtjQJBisxjsjuI1kENJLBtqoy1NJk5oSRi6yneNg5RWb3Xulf86vgl3xtHuv5Cd54 7ce1aXojtfcO8OxMB2AN/wCKhpt9SdgZao3piOqcPtTDVtfvHdm5sruGpioMfT0+NqKCZkhqpJ4q dJJofde6Or33L3RtDvf+WHu3pnb2LzXYnXvxnzGHiwm446oYXKbrwPTeYyG5Oo62spEkGM37u/bW OyOLxdNI0c4yU8THSqOy+691j3O/xc2B8nf5fvyX3L1jkfizuvs/fvZGQ7U+P+9qmXDU2ys3XYXI bT232pltr1EGPh2RFUb4bG1H370eJgyVHTxVM1PE9NUsPde6I18n/hH3J8de4O2O5t5Z/bEfxsyn YD9hY7clZ2HiV/014jJ7tTeGC67xmzqKvqdy7n3nVrU+ORZ6AYyneGWseqSlCzt7r3Rv+/dgb67h /mXfG75cdSyVO8Pjhl8h0jv6q7oxErjrrYe0evK6iq+w8Jvnda2xeychBiMZUyS0WVkpJZpK8U+k yF0X3Xuikd29F0Xz778+fPyS6W3917t3rrpyHHbo056rrqOTfFLhNlzY+tzOGCUzmhoty1ew62ri qqoRxST1kSWUM7R+690M+/vjRuj5pfBD4Q7i+JAwu7NzfH7b25di9l9d0e5ts7Yy+A3HuGtxFfl9 yStuDL4SgxNXNuHb9RXTtUTxy1tNkYKqIFEkY+690xbF25Vdgfy8vlH8Udh7swXanyS2b33ie1Nx 7c2FlqndWa7ZwTUmynz1Zs6pMFNk+zqvauTxlbFWyUSVySTYxZKd54qmilm917pz3VU5Ta3xG/l1 /EbdWPrv9mRx3yTg7WreupacPvXrfrqDdvYVVT0m76Ep/EdrT5el3RBklpaoxSQ0lI7TLGKeye69 0ezrLD5Oi/nY/Ivsarop6br/ACXSO2Bj97TKI9qVj1mw+oMHSRU2fYjFyz1WX2hlaeOMSl3lx1So B8Mmn3XuiBdCdZdjp/KS+ZnW8myd0x793L3dsqTbeyJcNkIt0Z1ds776dpNyzYbASQrksjFhajbd fHVvDE6wvQzq5BhcL7r3X//ZoEYd8Oo3AAA5HtKqT1VDvfXVaB5kWoYs///Y/+AAEEpGSUYAAQIB ASwBLAAA//4AJkZpbGUgd3JpdHRlbiBieSBBZG9iZSBQaG90b3Nob3CoIDUuMP/uAA5BZG9iZQBk QAAAAAH/2wCEAAEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQECAgIC AgICAgICAgMDAwMDAwMDAwMBAQEBAQEBAQEBAQICAQICAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMD AwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDA//AABEIADsB7QMBEQACEQEDEQH/3QAEAD7/xAGiAAAA BgIDAQAAAAAAAAAAAAAHCAYFBAkDCgIBAAsBAAAGAwEBAQAAAAAAAAAAAAYFBAMHAggBCQAKCxAA AgEDBAEDAwIDAwMCBgl1AQIDBBEFEgYhBxMiAAgxFEEyIxUJUUIWYSQzF1JxgRhikSVDobHwJjRy ChnB0TUn4VM2gvGSokRUc0VGN0djKFVWVxqywtLi8mSDdJOEZaOzw9PjKThm83UqOTpISUpYWVpn aGlqdnd4eXqFhoeIiYqUlZaXmJmapKWmp6ipqrS1tre4ubrExcbHyMnK1NXW19jZ2uTl5ufo6er0 9fb3+Pn6EQACAQMCBAQDBQQEBAYGBW0BAgMRBCESBTEGACITQVEHMmEUcQhCgSORFVKhYhYzCbEk wdFDcvAX4YI0JZJTGGNE8aKyJjUZVDZFZCcKc4OTRnTC0uLyVWV1VjeEhaOzw9Pj8ykalKS0xNTk 9JWltcXV5fUoR1dmOHaGlqa2xtbm9md3h5ent8fX5/dIWGh4iJiouMjY6Pg5SVlpeYmZqbnJ2en5 KjpKWmp6ipqqusra6vr/2gAMAwEAAhEDEQA/AN/j37r3Xvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3REOzP5ivx26s7HyPWmal3nl8ng8l/B9 x5vbeBoMjtzb+TimMGQoq+oqc3QZWqnxEgK1IoqOq0OrRrqkVkHuvdHfxOVxuexWMzmHrYMliMzj 6LK4rI0riWlr8bkaaOsoa2mkHEkFVSzK6N+VYH37r3Th7917r3v3Xuve/de697917r3v3Xuve/de 697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3 v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuv//Q 3+Pfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde 9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737 r3XvfuvdUk91fyt+wN6dzbn3bsffez6PZG9t0ZPc1d/eOTOf3h25Lna+XJ5akp6GjxlZS5yGCqqp PtWespndNKSlSDK3uvdXFbC2jQ9f7G2bsTGVFRV47ZW1dvbToKqrKmqqaLbuJpMRSz1OmyeeaGjV mC2UE2AAt7917pWe/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917 r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve/de697917r3v3Xuve /de697917r3v3Xuve/de697917r3v3Xuve/de697917r/9Hf49+691737r3TTnM9gtsYupze5M1i dvYWjanWry+cyNHicXStWVUNDSLU19fNT0kDVVbUxwxhnGuWRUW7MAfde6Qn+nDpX/n7/V3/AKMD af8A9dvfuvdPu3uyOu93V8mK2nv3Ze58pFRy5CXG7e3Tg81Xx0EE1NTT10lHja6pqEo4aishjeUq EV5UUm7KD7r3TF/pw6V/5+/1d/6MDaf/ANdvfuvdcW7z6TRWd+4erERFLMzdg7SVVVRdmZjlwFVQ Lkn6e/de6WGe3jtHauOpMvujdW3Nt4mvqIqOgymezmMw+OrauopqitgpaStyNVT01TUTUdJLMiIz M0UTsAVUke690kD3l0ooLN3B1aAASSewNpgADkkk5ewAHv3Xup2R7f6mxFbPjct2h13i8jSmMVVB kd7baoq2mM0MdTCJ6WpycU8Jlp5kkXUo1I4YcEH37r3UL/Th0r/z9/q7/wBGBtP/AOu3v3Xun3M9 kdd7dpsLWbg37svBUe5KOTIbdqszunB4ymz1BDHRSzV2Fnra6CLKUcUWSpmaWAyIq1EZJs63917p i/04dK/8/f6u/wDRgbT/APrt7917pTba35sfej18Wzt57U3ZJiko3yce2txYjOvjkyBq1oHr0xdZ VNRpXNQTiEyaRKYZNN9DW917pirO5eoMdWVmOyHavW9DkMdWVWPyFBWb52xS1lBX0NRJSVtDWUs+ USelrKOqheOWJ1V45FKsAQR7917rqPubp+Wmq6yLtbraWjoHo466rj31td6aifIvPHj0q51yhipn rpKWVYQ5UymNgtypt7r3Uf8A04dK/wDP3+rv/RgbT/8Art7917p+272N17u+tlxu09+bM3RkYKV6 6bH7d3RhM3Ww0UUsFPJWS0uNrqmeOljnqY0aQqEDyKCbsAfde6T6959JuquncPVjo6hlZewdpMrK wurKwy5DKwNwR9ffuvdcx3f0sxCr291eSSAAN/7UJJPAAAy1ySffuvdK3cm8NpbOp6as3dunbm1a SsqDSUlVuTN4zB09VVCJ5zTU0+TqqWKeoEMbPoUltKk2sD7917pHt3n0mis79w9WIiKWZm7B2kqq qi7MzHLgKqgXJP09+690Kfv3Xuve/de697917oIOx+/+luopFp+x+ytqbVrnRZExNbkknzjxOodZ 1wNAKvMtAysCJBBoNxzyPfuvdBRgvnb8StxVqUGP7r27TzvOacSZ3G7n2vRCQW9T5Lc2CxGOjg5/ zrSiP/auD7917o19NU01bTU9ZR1EFXR1cEVTS1VNLHPTVNNPGssFRTzxM8U0E0ThkdSVZSCDb37r 3SM7A7O6+6qwj7j7F3hgdn4cF1iqs1XxU0lbLGod6bGUd2rsrWBDfwU0csxHIX37r3Sow2Xx24MR is9h6pK7EZvG0OXxdaiSRpWY7JUsVZQ1SJMkcyJUU0yuA6qwB5APHv3Xuom5d0ba2bhqvcO7c/ht s4GgQPW5jPZKkxWNpgeFEtZWywwI7nhV1amPABPv3Xuisy/Pz4hw5A4x+58UakFh5Itt73nx/oZ1 NstDtiTFEEobHzWYWIuCL+690YrYnZvXfZ+Oly3Xe9tsb0oKfwCsm25maHKPj3qVkenhydPTTPU4 ypmWJisVQkchCn08H37r3S59+690jd7dibE62xRzm/8AeG3NnYol1jrdxZeixcdTJGFLQUa1U0cl dU2cWihV5DcWU39+690W4fPz4hmvOO/0z4r7gC5kO3N7ig/UE4yh2z/DCbn6Cb6c/Tn37r3Rmtnb 32f2Fg4Ny7G3Pgt24Cpd4Ysvt/J0mVofuIghmpZJqSWVYKyn8i+SF9MsZNmUH37r3Sp9+690Xff/ AMs/jh1hXVGL3p29tLH5WjZ463E46oq9zZWhmiMgkp67GbXpMzXUVSpjIMUsaSXtx6hf3XumXaPz U+LO+KunocD3TtNauqdIqaDcAy2zmnmkleGKGM7vxuCV55ZUsiA6mutgdS3917oz8Usc0cc0MiTQ zIksUsTrJHLHIodJI3QlXR1IIIJBB9+691z9+691737r3Xvfuvde9+690BfY3ya6D6mrHxnYHam0 8Dl4v8/hFrZMvnaUWupq8HgocnlqRXH6TLCgexte3v3XukXtL5t/FXe1fTY3A9z7ZWtrJlp6WHP0 2d2gJp3bRHCk27cRg4PJK5CoNV3YgLcke/de6NOCGAZSCCAQQbgg8ggjggj37r3TZms5hdt4usze 4sxi8BhcfEZ6/L5rIUmKxdDACAZqyvrpoKSmiBI9Tuo9+690VXLfPb4jYWu/h9Z3RhZqjzNB5MTg t4Z+h1qYwW/ieC25kcb4f3RaTy+M2Nm9LW917oZOuO+Om+3dadb9kbU3ZVxRmabF4/JxJm4IAATP Pgaz7bMwU/NvI8CpcEXuCB7r3Qte/de697917oNsL3D1fuTfmR6x29vjAZ3fWHwtRuHLbfw9YMnP i8VS12PxtRLkaqiWbH0VTFWZWnU00ky1NpVbx6bsPde6R/Z/yf6C6arDjOx+z9u4DLqsby4SH7/P Z6njlGqKSqwW26LL5ekilUXRpYUVh9CffuvdP/V/e/UHdEFVN1fv/AbuegjWavoKGeamzFDBJIYo 6mtweShoszSU0ko0rJJAqM3AJPv3XulFv7szr/q3DHcHYm8MBs7EFmjhqs7kYKI1kygM1NjqZ2NX kqsKb+Knjlk086be/de6BvY/zM+MXY2bg25tPt/blVm6urFBQ0GWps5td8hWsyJFS46XdOJwtPkZ 6mRwsKwPIZnOmPUePfuvdGc9+691737r3Xvfuvde9+691//S3+Pfuvde9+690m93bQ2vv3b2R2lv PBY3c22sutMuTwmYpo6zH1oo6ynyFJ56eQFWamrqSKaM/VJI1YWIB9+691rCfOLoai6A75ze3tu0 ElBsbctDR7u2VAZJ54qTGZEy0+QxCVNQ0sj/AMHzdJUxRq8jyrS+FnJLgn3XurSP5VZ6xzHU2Ur8 VtLAY7tbZ2Tyu1t17ogo4huPN7b3JkE3NhJK3IXac4+SSk+0SK6pfFBtNxqPuvdBv/Mj+J3WO1Or 6buTrba+C2XlcBuKhod20WJKYyhz+J3FN9jT1cWN8oppMzj808JtTxJJLT1E8kpYQqV917oifwEp uqsx8iMJtLtraWB3Zht54bL7fwMO46YVmNx+63WnyOKqHpZpBSTy18OPmoYhJHIfPVR6dJ59+691 skdh9f8AWe99qHD9l7Y23uDZ+CJzYo9x0dPUYrEtjMbW0oykfnGiikoMXVzoJlKtHG7WIv7917ql j4B/FzrTure/anbe59px5Xqrb+6cjg+t9rZf7qbGVNVV1cuTVsnFJIDkk21t2oo4hDOZY5ZKwtIp aJffuvdG/wDn38T9h706f3v2ds/Z2Mx3aG0KWm3VUZjFQmkrNwYDBU8NPnsflUhvFX/ZbagaenLR mYPRxxowRmB917qkP4xZXr/Ed8dbTdp4DD7k2FW55cLuHH56nFVioYM9S1GHpMtWU7XjlgwmQrYa twyuNEJ9JNre691tE7+6E6c7P2/htsb76925uDC7bxlRhttU1RSNTy7bx1VT4+lmp9vVtFJTV2FD U+Kpk1U0kbBYEAPpHv3XutU3uvrmXqLtnsDraWsjyC7P3NkcTS10ciSfd45JPPi6ibx+mOrlxs0T Tx/7qmLIeV9+691sh/BGi6nqvj7sjeXWm0MFtfI7i29iMPv2bF0yR5HKbq2d97ichJmqsj7qrk/i M1VU0/lJKwVgK+lh7917oif8yXqLrqr390vs/rPZuCxncnbm8s1VZirxFK1HU5dM9k6Gkiym4hTD wzvkdw5GeZqp42lAgnYsFBv7r3VjOwPh38fth9ejrtOu9u7goK6jxMe6clnselfkd25LErM8GWy0 07zOs8dXVTSwRxssVIZSIQo9+691rxfMfpCHoLvvd2y8VSyUu064026NkrI8soG2c4JJIaOOaeSW eZMLkoamg1yM0j/a6mJLX9+691cX/LB/0X5ro+HObe2htzDdl7brcrsnfWeoaOGPPZulkrk3Bh6u uqyGrJKKsoKmBAGYxmoo5NAAXSvuvdFx/mUfFHrXr/YW2e2urdq4PZX2G4Y9t7txGFUY+gylJmqe STD5KnxxnFJFV4ysx7xOtNGsk0dXrcFYbj3Xuisfy56bqfO9+Js3tTaOA3Qu6sBXQ7Ml3DTpWUuO 3XiHTMRJHT1F6TzZDFUlSsbuC4njjRPVJ7917rYX7d2T1XvLZ2Rk7f2zgNybR2vSZLc9UNwUaVVP iIsbjKt6/LU7krLSVFNjTN+7Gyuqk2I9+691Tl/Lp+KPXva/9+e5Ow9nQ5rZ1Pn6rbnXe1s6ZavF mSMiuymSr4ZJB/GRi6WrpqOBpfJA0pqCwaWNTH7r3V7vv3Xuve/de6rJ/mB/M2v6NxtN1Z1pWRRd nbnxjV2VzqaJpNjbfqGaGmnponR4TuLMlJPty9/tYUMxXU8De/de6dvjJ8E+q8ZsDBb17p21T9o9 q73x9Nunc2S3tNWZyDGVGcpkrVw8VBXTPS1NXRRVAFVVVCT1EtX5GWQR+NV917ol3zX/AJfWb2xu bG7x+OOxMznNo59ZIM5szb61WYrNrZuI61qsdSSST5F8BloWuFUyiknjcEpHJCi+690dno/oz5IY 34ZbX6ypex6rpvs+LKZTKUtXVY+l3HW4ja9VkMjU0Wz6qUzO2CeqaeOoM9K0s9EhEIUEvGvuvdUE d00e/cR2hvbbnZe6K/eO8tr7iyu3cznq/M5POtXVWKrZqWWamyGXP30lHK6Fow6oQpAKqePfuvdb X3R//MleoP8AxF3X/wD7yeJ9+691QD/MP7jzfY3yRzGwMzlK7H9e9Z5PH7eoMXAzSQRVMlLRzbk3 K9Ev7dVlZpaqSOJjcimhjQWLPq917q8Hb/xl+MdT1/itu4fqbrXM7Nr8FSfw/JfwDEZOuy2NrqWO elzCbr8L5qrrK2GVZkrlqvMSwdHFlI917osfwU6Ny/Q/bfy52q2E3DR7NXcnXUGxM7mMbX09FnsJ DHv7JRRY7L1NPFR5upw1Bm6SKseBn0SupcLrUe/de6Mx8p/kVg/jR1ZX73roKfK7irqhcJsrbks5 i/jW4KiKSRGqPGfOmIxVPG1RVyLp9CCJWWSWO/uvdV4fDvoT/ZuH3F8mPlBWZDsZ6/OV2B2VtjJ1 tZTbep6fHGOTIV8WOoJ6eKHD0tbUNSUdDG0dMskM8kscjMjj3XuhF+Zv8vvZm5tiS7v+Puw8dt3s Hbjxz1O1ttKKDH7xwlliqqSlxLSpjabPY8WngaFYmqlEkTiWRodHuvdNn8sLpDurqqbtHMdjbbzm ydt7gptv0WKwO4EehrslmcdUZGSfLR4eUmopYaKjqPD5pVi8/mATWEYp7r3QdfzHvmTuPF7hq/j9 1Xm6vBpjKeL/AEl7kxVQ9Nkqusr6aKpp9o42ugZZaOipaKdZMhJEwkmlkFPdFimWb3XuhV/l9fD3 rSl6h2/252Rs3Dbx3lv1KjL4en3TjKbL4zbe2PuJqXEChxOQjqMe9fl6eH71qt42kEU8UcejS5k9 17rP/MA+G3XeW6nz3bXWmz8Fs/eXX1Ec1mqbbGLp8Pjdy7TortmVrcXjUp8cmSw1GzViVYiEzwwP DIWUxGL3XuiU/wAv75gbn6x39tzqLe2cqsp1Vu+vgwOJhydS0w2LuDJVCQ4qsxdRPrekwNdXSCGr pdS08Rm+5XQyyib3Xuti737r3Xvfuvde9+691T9/MB+ZW7Nt7lh+OvSGTqMfuyr+xpt7bnxMsceV o6rNrCMVs/b9aJA2OyVRBVJLWVKaJYRLFHHIj+bT7r3Rmenv5f8A0BsHZtFjt67Kw/Ze9a+hR927 r3UlRlGrctUxq+QOGpamY0+IooqlnEDxItUUs0kruSffuvdVefLX+X3v/YnY5reidjbl3n1xuhWr cbQYWGbN1+z8iZCK3AV5DSVpxcZZZKKqmveF/FJI8kTSSe691c703DluivjFs4dy5hYa/rbro1m8 a6So+/OLosPS1NauLWeKScZCfCYpYqFPCzid4QItQZb+691QN2N3B2j87O/NqbRmyNThtu7j3bR4 DZW0opZJMNtPD1dUI581W0aTRxZTNU+LV6mtqWPkk0GOMpEsca+691f5sj4mfHjYm0KLZtB1NsfM 0VPRLS12U3TtjBbiz+clMQjqK7MZbJY+apqamqa7FVKQxFtMSRoFUe691Rf86vjyvxZ7i29ujrCp ye3tobxWp3Fs2Wgr6uCv2juLDVNP/GcPjclFKK2Onx7VtLU0cpk8qRVHiuxhLt7r3Vqn8v75W5H5 C7Eym2d8VME3ZvXqUEWTrlCQybq29Vh4cduN6dQiDIwzwNT1/iHj8pilsnnCL7r3RYP5kew/kXt7 D5rsr/Tlk8n0/ktwUOGHW+Oaq2p/AaXKwyJR0tZBiZVod4USVNMyvNVt9wGlU+MqGZPde6Il8G9o 9xb77Y3HtTpjfdJ1rmMz1zl6bde85YZJ8lh9jnc20Wysm3UgVagZ+bKLQxwtHLTSKjOVnhI1j3Xu j69kfyn8TDsvO5zaHau69wdjUtDX5lk3LjqCXGbpykUU1ZPSf5ITlcbV5WcELPJPWkSN6w1yw917 qobqLsHevV/Yu1959fZVcRujHZKCGhmm8j0FSlc4o6jH5anjINXia6GYxzxfUobrZgpHuvdXe5P+ Wlle1Kqq3h8gvkJvPeXYmSiYy1eCx+PpsDhizSSJjcXT5WOpLYemmkLRw00GMhAJCxJe/v3XuqZ/ kN0pmfjz2zuPrHL5KDMNhmoq3E5ykhkpY8thspTR12MrjTSM70dUIpPHPEHkWKojdUeRQrt7r3Wx 98G+w892d8YOsdyborKnJZ+no8vtzI5OrkaeqyX92M7ksHQVtVUSO81VWT4uigM8shMks+t2JJuf de6Np7917r3v3Xuve/de6//T3+Pfuvde9+691737r3VaH80Lpsb96MpexcZRibcHUuT/AIlO8aFq ibZ+demx24IQEGp1oqxKOtYt6YoKeYi1z7917qsT+XN3IOqvkVhMLkapodtdpwLsPJqzKIY8zW1E cu0q5lYoPKmbVaQMTZIq6Q2PA9+691Y18v46z5MfIrqf4f4Svq6bbWER+zO4cjjm1S4yijo3OMpZ b6o4KuPFVOmEyRyR/c5qlYiyn37r3VF2exG6umezslh55Xxu8es95ywR1cIZft85tbL6qTIUhcAt CamjSeFvoyFWHB9+691fR8rvk/TZr4Uba3Ps53XcnyLxuJ2fh8bQF5qukkysTxb+x8UcchllOPWk qsSxUsRUVMf1v7917o4vxr6jpujukev+uEjjXI4fCxVW5JoyHFVurLs2V3HMJrapoUytXJFAW5Wn jjX6KAPde6G6op4KunnpKqGOopqqGWnqKeZFkhngmRo5oZY2BV45Y2KsDwQbe/de61Gvkr1HP0d3 dv8A64ZJRjcPmpKrbk0vqNVtbMImV29N5blZpY8ZVxxTMDYVEUimxUge691fr0v8scTUfCWPvbc1 XHXZnrra1XtzdEE8zCbKb627HTYfD0VTP6ytdvOesxs5YcK2RBsACB7r3VLXdnx733hOkuuvk/u6 srclme6t0blzG71qVUNQSbmlkzm0Mk6pCrBt0UlNXVkjFjGglgQWZiPfuvdHI/lNdzHG7k3t0Zlq rTSbjpm3ztFJHYKucxcMFFuSggT1Bp8lhVgqRYKFTHSEklgPfuvdDj8e4B8l/m/2/wDIarVa7YvT Uf8Ao862ldVkpKjIqlbiIMlj5QXiqKf7FcnkSD645MvTuNJUD37r3VsXv3XuqrP5qvTbbt6m2923 iqTy5frHKGizbxRAyy7O3PNT0kk0rJeSZcRn46QotiscVVPJdQGv7r3RDf5ZXcv+jjv1dj5Kq8O3 e3qBNtyLJN44Id141p67adU6m4klqJJKrHxrYEyZBeeLH3XujvfK3F1ny5+T2zfingstU47aHWu3 8rv7szMUPinFBnKzFrHh43gZmilloIslQ0y8q6HLz8ft39+691SJSVG7+l+zoKlUkw2+OsN6JIYZ Ve9FuHaeYGuCZDoMsC1tEUdTYSRkg8H37r3V8vzb+QcO5fitsDH9cGar3B8pm29hNs4yjlSXI/we uXHV25Mcp0rHJWCrqqbC1EZCkPXOPSVNvde6PL0Z1bjulupNh9ZY3xOu1cDTUmQqoUCJkc5Ul6/c GTC6VYLks3VTzKDcqrgEm3v3XuhY9+691737r3WpB8rN4V++vkf3RuDISzSuewtyYaiE7Xkhw+2c jNtzCUxUPIsZgxOKhUqpKgg2J+vv3XutsjAZKjzWBwmYxwjXH5bEY3JUKw28S0ddRw1VKItKovjE Eq6bKBb8D37r3Tv7917r3v3XutSb5bf9lOd8f+JR3f8A+7ep9+691tEdH/8AMleoP/EXdf8A/vJ4 n37r3VEX8yf467s2N2/nu5KDG1mQ687FqaGvqMvTxTVEG3dzmjpqHIYnMSqpWjXJVNN9zRu+lJBM YlJaI3917oDfjz83O7PjvHS4TCZSDdewoZWZtibq81XjKWOWV5aj+79fG6ZLbssjyu4WBzSGZzJJ TyMTf3XuthD41fJ7r/5ObRqdwbQFVis1hXpaXde0co0b5TAVlXE8lO6zw6Yclia0wyfbVSKgl8bB 0jkVo1917qon+bVu+vyPdOwdleaX+EbX68izUVMxIiXM7ozuWhyM6IGKtrx2Aol1WBupH0+vuvdW Lfy18lQV3xF2BS0ghFRhcxvrG5QxadbV8u881mIzUaVU+b+GZamA1Fj4wvNrAe690fD37r3Xvfuv dab/AGxnq3dHaXZG5MiZzXZ7fe7cvVCpTxTpNkM9X1TxSQ6nEDRGTT4wSEtpHA9+691tj9CUsFF0 Z0xR0sYipqXqjruCCIFm0RRbRw6IupyzuQo5LEsTyST7917oQ8/hqLceCzW3slGs2Oz2JyOGr4mX UstFlKOahqo2W41K8E7Ai4vf37r3Wl7LHU0FXJE+umrKKoeN9L6ZIKmmlKtpkjbh4pU4Kn6i4Pv3 XutzXZ+Tqs3tLa2ZrQBW5fbmEydWAoQCqr8ZS1VQAqqiqBLKeAAB/Qe/de6Ufv3Xuve/de61Cttb 9qNyfInbfZu6KgifMdyYPemcqHe4hFXvSkzNdpaRwqw00bMEBIVUUDgD37r3W3r7917r3v3XuiF/ zKM7XYX4m70goZHi/vBnNoYKskjco4oZc/SZGojBAJKVP8METi41RuwNwSD7r3VO/wDLix8Ff8ve spJwrDG0e+MhHG6JIjzpsXcdNESHB0tC9V5EYcq6KR7917rZ89+691Vx/NlwNNXfH/Z+fIUV2A7R xcEMhFyaHM7c3LFWwLxw0lTR0z3va0R/JFvde6ID/K2yNXRfKKOlp5mjgy/Xu7qGvjBOmemhkxOU jRhe3prcdE4/4L7917qzf+Z//wBkq5b/AMPbZv8A7mVHv3Xuq8f5Sv8A2UbvX/xCe4//AHuut/fu vdbDnv3XutLrbX/Hx7f/AO13iv8A3Pg9+691ui+/de61rf5n/wD2VVlv/DJ2b/7h1Hv3XurX/wCW r/2SNsP/ALXe+f8A3r8v7917o+fv3Xuve/de697917r/1N/j37r3Xvfuvde9+69005/B4vc+CzW2 83SpXYXcOJyODy9FLfx1mLy1HNQV9LJax0VFJUOh/wAD7917rUD7W2DnelO2N4bBrpp4MxsTdFTR 0eRiZoJp6emnSswOcpmTQ8IyWMkp6yE+llWVeAeB7r3V8v8ALn2RuPNYDsD5P9jMa3f/AHpn6qSl rpadaYw7UxNZLETR0yxxCipMrmonCRLeP7SgpSht9fde6JZ/Na6cO2e0Ns9xYulK4rsfGLhtwSxp 6It3bXp4aaCad1VUjOW22adYl5ZmoJmJ/A917oPP5emyNyd09x7Dxm4qmqyXWvx9lzXY1Djqgq1D jdxZyqx5xNHT3BZXr9xYyHIFCCrLQTfQub+691sh+/de697917qm3+bN02K/AbG7zxVKzVWBnXYe 7ZI1U/7hsjLVZHbVdLYArFQ5d6mnZiWLPXRAAAe/de6rZ+MOB3v3PurA/GjH5Gpi693xvzb++N8U sBaM0+N2Vj8t/Fa1KlXQQifD10iBGus1bHR/Ro19+691sh9+9M4nt7ovenUtPR0dItftoU200WOO Gmw+dwSRVm03gtoFLS0uRoYI3CFb0xeMnSxHv3XutUDbu4t2da7rizeArq/bO7NvT5OiSqh1U+Qx tRPS1mFylOQw1RSmmqpoXB5AYj37r3W0f8M+mV6O+Pmxtq1dKtPuTLUf98N4koY5zuPckcNZNSVI IF58JjhTY8kcH7S/5ufde6NL7917pM702nh9+bR3PsrcEAqcJuvBZXb+Ui0qWNFlqKaimeIsCEni SbXG/wBUkUMLEA+/de61Cd27d3T0r2jmtuVM8uO3d1rvGamhyFOHhaPKbdyYlx2YoS3qEFQ1PFVU 786o3RgSD7917rYM/l3df5yLr/d3f+/NVV2H8hdz1u7aysmjKSxbZp6ytGHhgjkMjUtNkK+qq6uN Y2EbUclKtrRL7917qur+aR00dj91Y7s7F0hjwPbGM+4rZIkIgg3jt2Klx+XjYKWSE5HFvRVQJ0ma ZqhgCVY+/de6zfy39jbj7j7f2rl90VNTktgfG3C1+T23Q1CLJQUG5d1ZjIV+HoogVBWZ8nPWZQPc sslBEPpb37r3Ww67pEjyyukccaM8kjsEREQFnd3YhVRVFyTwB7917ql7fv8ANujxW+cjjtg9W0O5 Ni4zIyUUGbzG4KvF5bcdNTTGOXJ0FNT42pgw9LWaS1Msy1EpjKvIqMxiT3XurVem+2Nsd39b7Y7N 2g064bclJLKKOsES5DF19HUzUOTxOQSGSWNKvH19PJGSrFJFAkQlHUn3XutYv5l7AyHXPyZ7fw1Z SyU9Nl94ZbeWGZk0w1GF3lVy7ionpHF1lgpTkHpiQTpkgdG9SsB7r3VxX8ur5V7Y7C6z290zunMU uM7J2BjocFhqTIVKw/3u2nQKsGEmw71Eg+5yWGoQlJUUilpPHCkyAoziL3XurIM/uDBbVw+Q3Dub MYzAYLFU71eSzGYrafHY2hpoxd5qqsqpIoIUH9WYXPA59+690FPRvfO0fkDhdz7n2NQ55NtYDd2Q 2pj85mMa+Oo90rjqShqJc5glkYzvi5Jaxo1EqxzqY/3ERjpHuvdayny2/wCynO+P/Eo7v/8AdvU+ /de62iOj/wDmSvUH/iLuv/8A3k8T7917pKbF7j2Z3JvHuzqWbb7fddV5ei2zufGbhjxeQoNx0Oag rjHWwY8PVRVGIqBROjpOur1AOqkge/de6rY+bf8AL46+29sXdXc3TEL7Sn2rRS53c2xvPJUbdrsR A4fJ1+3zVPJU4WuooXadqYSPSSRRlIY4WAD+690XP+VPV5iL5J5ikoHlONq+sNyPnYQ8vg+0pszt o0VTJEqtEZYcnLDGjtp0iZgG9Wlvde6Eb+bf1/X0PY/W3Z0VO5w+4doS7NqqiNCYoc1trLZHLRCp kAIjnr8buECIEjWtG9h6G9+690mv5afyn251LnM91F2LloMHtDfOSp8ztzP1860+Jwe7xTw46qp8 tUSssFDQbhoKenT7pyscE1IgkskrPH7r3WwUk0MsKVEUsckEkazRzo6vC8LqHSVJFJRo2Q3DA2I5 9+690X3anya61353Nlultj1Fdu7Kbc25WZ3cu68DDFX7MwVZTV9JQpt6rzcMzRy5eU1DE+IPAjxm IuZlkSP3Xutcb5k9T5Lp/wCRXZG36qllgxOcztfvTalQykQ1m2t01tTk6P7ZySZUxlVJNQSMbEzU j/4E+691sP8Awx7AouyPjL1DmaWoSaqxG0cbszMoGUzwZjZcCbbqxVoHcxT1keOjqgDbVFUI4ADA e/de6HbfW7MfsPZW7d7ZaSOLG7S25mtx1rSNpU0+Hx1RXvGDcEvKINCqPUzMAOSPfuvdamXQPUub 737g2d17joaqpXO5mCo3JXIXZsZtmlqEqdyZioqCriNqfHh/GzkeSpeOMHU63917rbbzeYwuztt5 fcGXnhxW3dq4OvzGTqipFPjsLg6CWtrZyiAkQ0dDSs1gP0rx7917qmip/m8yLvNlpOnY5OvVyCxL LPuJ494y4sMEeu8KUj4aKudbyrS6mjH+bM5/zvv3Xuri9k7xwHYW0dt742tVmv27uvDUGcw9U0Tw SSUOQgSoiE9PIBJT1MQfRLGwDRyKynkH37r3WoT2zsLI9Xdmb669ysEsFXtHc+Wwy+ZWVqiipquT +GV8er1PT5PGNDURN/bilVvz7917rZE+FXyq2x3/ANa7fxGUzlHD23tnE02K3dgKyphiyuYfF08V P/e7G07FGr6DLxKs1QYlIpal3jYKvjZ/de6NZvnfmz+tds5LeG+9w43bO3MVE0tZk8pULDFqCO8d LTR+qeur6nQVhp4Vknmf0ojMbe/de6J92pU0Xza+Gm98jsPbm6MdLnqavymx8fuOggx2Yy2R2NuB a/HSUEMFXW0k1PuZMS9LCwkZb1DLcMuoe691RN8P990nV3yc6j3VmZVx+Po91PgcvUVREEWPo91Y 7IbQrautMqkRQY6PNNLKWAKLGTwRce691tke/de6qj/m17vocd0vsDZXniGW3P2HHm46YsplfD7X wOWgr5lj/UqpkdwUQ1/Tkjm/HuvdAn/KZ6bykmf3v3nlKOSDDUuIl2FtSadGVcjkq6soMluGuo9Q BePFU1BBTeQXRnq5EF2jcL7r3Ruv5n//AGSrlv8Aw9tm/wDuZUe/de6rx/lK/wDZRu9f/EJ7j/8A e6639+691sOe/de60uttf8fHt/8A7XeK/wDc+D37r3W6L7917rWt/mf/APZVWW/8MnZv/uHUe/de 6tf/AJav/ZI2w/8Atd75/wDevy/v3Xuj5+/de697917r3v3Xuv/V3+Pfuvde9+691737r3Xvfuvd VNfO34S74717c66331ni6SWPNQUe1ezq+TJYnH/wOhx+QgXH7ukpcnX0c+YMGIrpopYaQS1BSihV Y2LX9+691aNtTbOH2Xtjb20Nv0wo8HtfC4zAYimGm8OOxNHDQ0iOyKivIIIF1NYamufz7917oBfl 50nL370NvLYuNp46jdMMMO5NkiSWngvuvA+SooKRamskhpKU5qmefHtLK6RxJVszMoBI917oNfgP 8cs38eenqql3tioMV2NvTO1Oa3VSR1eOyMuOo6AyY3buFfJ4mqraCtjpaNJKseKWRUlr5FvcH37r 3R4/fuvde9+690G/b/W+K7e6w3x1rmdK0W8NvV2JWoZdX2GQZBPh8qi2YNNiMvBBVRgggvCLgjj3 7r3RC/5dnxI3n0JFv7evbG34cFvzPTQbXwdAuVwuaNFtKkFPkq2uSswORyVEo3BlmiUxvIJo1x6k qok5917qzz37r3VQm8fgPn8785cf2RTYClbovLZyg7K3JXR5DCRJBuekSbIZHbEuEkrkzVYm4N04 +OonljpTTimyDr5NaMB7r3Vvfv3Xuve/de697917qo75m/BbeHdfyG2Jv3YmNg/uxvCPDYnt3Kpk sNj59vJg6qkoG3ItNkK2Cty9RW7WdIIYqWCodZcePJpWRSPde6tfw2Ixu38RisDh6SHH4jCY2hxG KoKdQlPRY3G0sVHQ0kCDhIaalhVFH4VR7917orvzW6GrPkH0Rn9qYCiird74Sso917GikqaSi+4z uM8sE2M+8rZqakgXMYesqaZTNLFAs0kbyMFS4917ps+Dfx9yPx66PoMDunHQY/sDc2Urtzb2giq6 TIfZ1sz/AGWKxAr6GoqqKoTGYWlh1eGR4RUyTFGYNqb3Xujf1dNDW0tTR1Cl6erp5qadQxUtDPG0 UqhlIZSUc8jke/de61vd+fyx/ktg97ZDDbJ29i967Oavb+DbvXde18Qgxc07fatmsXmcnjMvBkaS mK/dLTUtRFrB8LSC3v3Xurxvi30gfj10rtXrSoyUOYy9Aa/K7hydKkkdFU53NVktdWx0CzBZTQ0K yJTROyo8qQiRkRnKD3XukD8tfh/s/wCUeBoJJ6/+6vYO24J4ts7vhpPvEajmZppMDnaNZYGr8NNU nyIVcTUkrNJESHlil917qlvcX8tT5b4DKyUmG2XhN300ErGnzm3d8bUoaOURsDFNHFurLbZy0TN9 QGpwVI/1r+690O3VP8tz5DdhZbFv8h92Vm1NlY2sjqarBS7wTee6a1UurU+IWhrsztrE/cQgxtVv UySQhwVgl5A917q33dOzN+7D6swuyPi5i+rNs1+BekxmLx/YUe5RtXH7eENa1fNAdtLUZSo3BLXy xzeWoEqzyPNJOXdrn3XuqkN1/wAr/wCR/YW6ty753j2T1B/ebdueyu4cycdPu56Jq7LVktbOaZX2 lRGGASTEJGEtGgAubX9+691Zb8adofKrYNHitmd15npLO7B2vsqjwG267YjbzffDZLD/AMGx2GTM TZjE4XAz4pcHTVInkSAVL1PiP6TJ7917oqPanxs+WXX3yZ3j8kfjfWbNz0O75Kdq/ZdbkYsTNkqN cViIMlhs/QZd8Vha2krsljvPHUQ5KGoWW0l4m5PuvdRe4qL+Y38hdpzdXVnTmxeo9r7hWKn3Vm4d /bZyUuSo1midsdNU47dGfyVDiJ3UPPHT0Us8yJ4zJoZ45Pde6M58Ovh9gvi3t3Kz1eVh3R2LuuOl j3NuGCCSnx1JRUbSS02A2/BP/lKY6GeUvNPIElrJQruiKkccfuvdD93L09svvXr/ADPXO+6J6nD5 VUmpqumZYsnhMtTBzj85iKlkcU+RoJHOklWjkjZ4pFeKR0b3XuqHezf5XHyH2rlqhOvF2/2lgXlY 0FVR5nFbVza05kKoMri90ZDHY+nqAnJFPXVSEfQg+ke691w2P/L1+aOeaLam4WPXOzpAIK1s12Lj cth1oZXLVUdNt7Z2dz/3chUkiGRIIpHIDSKCWHuvdXc/HT457D+NexY9obOhasyFa0FZuvdlbDHH mN1ZaJHRKqr0NIKWgoxM6UdGjNHSxs3LyvLLJ7r3TX8lfi9178nNqU2D3as+Jz+Gaom2rvLGRRPl sDUVKoKiFo5SkeSw9YYkNRSOyLIUVkeORVce691XN1P8dvnj8PdxZaHqLH7I7g2NnalJ8nt6TcdB icZWyRIIYMs1DubK7Xq8Dn1plCO9JUVMTqqLL51jj0+690IPa+w/5gnyqxUfXe7todf9Bdd1NVTz 7h8W76LO1efipnjnjgrpttZfc1VXUcE6CWKjEdHFJOimaQhUZfde6OP8YPif178YNt1NDt5pNwbw zUcI3RvnJUsEGSygiCMuOx1NG0ww2AhnUyJSrJKzOQ0ssrKhX3Xuhw7H2TQdk9f716+yk8tJQb02 tnNsVNZAoknoo81jqigFdBGzIkk9E04lRWIVmQA8E+/de612q7+WT8qqfd8m3qPbe3K/b/8AEDSw 79Xd+3qbb7URY6MnNi58gN3wxhLa4lxskqtwoceo+691sIdO9dU3UnVuxOtaWvkykezdt47CyZOW MQtkKuni1V1asALfbw1NbJI8cWpzHGwUsxGo+690U75ifBjbfyVEO79tZGi2Z2tQUqUYzVVTzSYT dNBAhWkx25o6RXqoJ6LhYK+GOaaOK8TxzIIhF7r3VRVb/Lm+Y+By3+4fr6kybUciyUucwHYOx6KF pFJ0y0jZfcmDy0Lra4LQRkX9+690ajpP+Wp2tvDP4rcPyi3XUQ7dxMsU67Jh3RU7o3DltEkcsmMr c1BV1OLwOLqDxM9HU1FRIoZU8JKzD3XurucXjMdhMbj8PiKKmxuKxVFTY7G46ihSno6GgooUp6Sk pYIwscNPTwRqiKoAVQB7917qsb5X/wAt3Adw5zJdidR5bF7F3zlXeqz2BycEsezdy5ByWlyiy46n qKzb2Yq2JapkjgqYKqSztHHK0ssnuvdQ+t9w/wAy/q3bVLsbKdIbL7Ypdv08eNwm7K/sHaGOyc1B SxJT0cdbUSbyxlRlYqeGNQsk9JBVuOZZHbn37r3SIk+D3yD+TvZdP2b8uN2YPa2KpYKejpNibGqI 6+vo8TTzGoGAxs6PW4bBUUstRI8tWarJ1UkhNxyjp7r3Vs2z9oba2BtjCbN2fiKTA7Z27QxY7EYm iVlgpaaIsxuzs8s9RPK7STTSM8s0ztJIzOzMfde6ID8sPj98uvkd/Edh0e6eh9vdPJuWkzGIh8u+ oN61tLQRTLR/3lc7fzGLlqIZqp38VJJBEzJGSeDf3Xui89K/Ar5c/HLe4371Z2J0XU5epw1ft7K0 m6JN6vi67D1tVjq56KaCj2lLVMrV2Mhl1xTU8iNCoDMrMvv3XurCeyqH5g5LZGyaLrDL9BYLfVTh MhD2flc+m+ZMRQ52SlxkeOqOtETG5dzQw1LVzv8Axemlay0/pb90H3Xuqm6f+Uz35RinrqXsbqWP K0rQ1UEZrN3NSx1kDrLH/lL7OkZ40kW4LU5vblPfuvdW57Kg+WtL1zu2n35W9A5HtSGOFOv67BJv 1Nm1TCJfPNvtJqShyayPNqsMZDGmm3pB9+691Wz29/L4+V3f2/Mn2L2X2F0bTZ+upMdj4oNsybzT F09BjYDBT08MNVtKCoQJy2qSWd3ZzdgAoHuvdGw+I/R3yu+PcWD653PuLovcHStDktw11UcZJveb sOiGRpcnWUceDkmwWFwPjqNyTQS1SVhqGjp2lWJ9Wge/de6sG9+691737r3Xvfuvdf/W3+Pfuvde 9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737 r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvd e9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+69173 7r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuvde9+691737r3Xvfuv de9+691737r3Xvfuvde9+691737r3Xvfuvde9+691//ZEG4e8EZNAQBkQE45mVy9fBU+X/UyvbS0 h/HhsBAvWoRkdechlhzoCv+JUE5HDQoaCgAAAA1JSERSAAADIAAAAI0IAwAAAHjE7vcAAAAEZ0FN QQAAsYiVmPSmAAADAFBMVEUJDTEMFTwMFTQFDSMFFTsMHUMGDR0LFSwWHS0EFDMNHTwKEyUOIkcS ITsKIUgMJlIOKlYOIkIWMV8ePnIaNmIGJlQKKloOKlINJksWMloKKlYMLloKIkISMl4PKk4OJkYL HDQTLlIaNlsFJUwEHTsDFSsKKlIOMl4OLlYTNmISMloWOmYPJkIWNl4aPmoSK0kCLmAGLVoKMl4K LlYKKk4KJ0YOMloOLlISOmYOKkoSNl4QLk4NIzwKGy4WOmITMlUWNlkbPWQaNVMGLVMEFCUKMloM NmIONl4OMlUSOmIUPmoSNloWPmYVOl4cRnIcRGwbPFwjRGcFNWMFJUMHKkoKNl4NPmoKL1IKLk4O NloKJkESPmYdS3QfTnlLYHQGPWsDHTMGNVsMPGQTRnIUQ2wWP2AnWYMTKTwoU3cwYosEJDwEGy0K NlgUTnoNLEMMIzUdVH0cRGMYMUQhOk0pR10GPWMKRW8MTnoNRGsUTHQSQF8VNUwcPVQzbJVygo0G RWsFMEsGNVMFLEQLTHQFIjULPFwKMEgUVHwYW4QMKj0QMkgmZIsgT2xfdoWPl5wMVHwLRGQJNU4G GiYUTGscZIwUPFMmbJM4eZ2Dj5YGVXwFPlsFKj4LTGwMO1QUVHQURmEKIi4eYoQdXX0dVXMeTGQF RGEFO1QLXIMLU3UUZIsNQ1wTXH4XbZMedJsUS2Updpouf6MoYn05hKdEj7MFZYsFTWwGVHQMZYsL XHwMS2UUdZsTY4UWU2webI4dW3UocY45dI0FS2UMdZoLbZMLZIQJU20Ua40UW3UefJ8dc5Qmhqgl gKA1j7BckaQGdZoFbIwFZIQFXnwGWnULbIwMW3UUfJwWgKIUc5QefJkea4Qsjq45mLhDocBQqskF c5QGaoYLfJ0Kco4LdJQLaoYQg6MOY30UepYZiaoUa4UWco4bhKQfjKskj68qmLYznrx0l6EFfZ0F epYJhKQMi6oMepYTkrASi6oaj64elbOTnqD+/v7z8/Pj4+PMzMyzs7OgoKAJ4z0FAAAgAElEQVR4 nDS77VMa6d7vG80w7vQwau89a9FG00Ci0qJg7WB4aAxIVJ7pNjcPGmlqtLtDDIJpMwvSjUkhtNgo qaId1KlENEEnK8xwKlO5TyUnq7Iyc99V596rzvvzZv8352KqjoPh8Yfzor98P5++Li71QNc10xDs tEOwbWjZpp2E1DPXUbt2xg719MDojNZiV4MfFIZgu0MLdTsWDLAW1bpsMGxxOeBv9CRisWEkjjjx RcuYMYDiBDkWHCdwJQRhVjLow/WYzoyrlBh4DFYS1DgyrgoSqKrzQrjHSKoGVT7Ch/jGvINB9prK QZE+NkiZlZAC85NBK47pwTiiNAcJM6QliRBiRIxGBJ0ao8a7NIRBZVaNE3rEh5vMQb+zP5ggcdZI YIou2Bw0+v//ccTDEhj034kE3keghBFR9bOJ8e6h5DWzbpCgdJjfetNNMNduEhwRI4iEWanooymK iVmvuWm3ta8/lmD0CpLi3IPEIGe82n+T4vyXriZ1brcukbipY+koeIXHnUgyLJGgBnsVV2MUwcas HjdNu/tM8QSLdSUSiUGcxRPWq6ZoIuG55Ema3FGaE+atLO2OJXgdzXEMIyQEc2+vjk8IDG+lYzHe txjlOR5DOI5aZeMsR3tuxjhuvotPRmM0zwlRhpFjApejmeS5kMk0hWjfqJzhJEHk+VxBoKN8pima Pc0ml5V4rkLL2Va1Eu2tnOfEglStyZmaKLabYk6qNqWKVG3RppvgfkVqMQ1RlGS6ITXF+XizepY9 p8/Ps3I20+SmbpxThVz2LNnICmKhIHF89uz9BXMmcPJiZFEWLuoNvpzNZmXTYrZOlXvz9UR5kZyt B2cXi6+e578KU/eK6cVXZHG2nC6m7+cXZ+8/D6Xz9+8vDX81tBjKB9IHU0uz24tD4aXQ6a0rzqOF SPgovGBJhcPOhaXLw5vL4cito6Nw+KAU3j5aCpfuPN3f3draSl25Mlza2t8tLafCJ6XlleGTrY3h kf39x6nhjZ3H0ysrOxuPd75eebyys7LzYG99ZQdcT++srzx4sPPo0aOducuX59YfvV5Z/3FkZGR9 7vLcj7fXL0Ea9S3oNmS39fSAoExc19qgHgiyTcJOdELTg6rVM66FkFOp0DpBisgFSGuZQdWw2o5i NsjiGICRAS8C2YxOSKFWoXoqiMMKBHEEvCyuUsC4zgyOF8JhUfnjCGZcMyIeX9CLoZY/I4OTYwgW 96AKPaGHlCoMCyaMZYWyb4o03yM9KoXSZ8Y747hWRfqUZnJtDDU7rCoMwe5hOlTpI/VKvU+nhvWk qjPeb6SMHgiZUpFeDwneFXGbfVRn3IIR1xCcSoKk+uOqQUTn0blRlZ8w943F3Qjip/q6+sxmcwIc 4op+k4666RfcfYpr9E0mmUwkrINWQXfVn0yCrBDsoLvfHaOtozeJzLV+lnX3qRiir7ffrXMnO+OD 4MXgiPX19bpjbgqMU27MLwya2GTyrzQt0IM3B2kQGVWUYsxmnvf0DVIMcmPQ7aGT4JFe8zzL0AJD Y318jOaSSU5w32QEc1R4yJl4PhPPRqM8zdMmkIt5WsjRV2mOmTKBoIhVTpyfpbMcU+BEed4k5sRm tdrMyFlJAvl6xtHiE4nn6YIoiny01cxkeakVi4pN8WqWB0E5Pq9F3YVCU2w1W3yUfiK2qsfVqsQX mjVabD4748WzNv8hmxMbT8BbnovRxplIr4rnhamyLMsX5xeN0dXsS+5N46JQvpFuZPm15MUFf68s yLP08+S9dPYdb3o5lX6ZLk/NyvX0VPnXcuRGeTOiiCzOFjfJfHH4RmTp/va9fPHWcKS4fbp5d/P+ wa2lfCR8sLl5a2n76OBWJFzajmwPh4+ObqXsB5HhYe/R8JVUCYTjaCt8JRW+dRA+2C8NXwmXwvtP 72xtnews74NcPN1aWU5tnOzsDKfAz/rOxvLKyl5qZWR9b29uZB1EBoRj5PL6yM7O+qMdEIr19fXX ICyv5+Z+XAe/ty+p1dND6m4NpIEm4GlIo4HUE923e6Zt0KQa1fYo1ZAaNMjMdbv2OgprBlwa2Gnp FErAjjrsalfA65zSOxW2KSWiR1EUhlEcgxVdXj06pvfhkM6rDPhUAZLwjJNeBKEIhcqHqzDVvaD5 JolhhM+HY1ZMiamQ/jGLRaXsxaxapQK6BloBj+sVHhViwFVjJGEeJzGlinIoMNysUqlwB6Y3qvQs 7jNj43YlNoV4r6lUqBIx+xBQXG6zyor7LUqPSuXAp4IEoWON/b36hKE3MG7u92LWcbPVCArNGte5 /f2I7mq/Zwwzq5A+n1/V14vEPDrWz/SpYv1mv3ueSRB0gjHfMCb1fTHWPdh50s2wNwkC3HOz/Sq3 adBq1Xn6+wZjnXEVe9PqZwWlOXbVDZqBSjD+BGu+wSb7/xrzR806N+N3C/55Sojxnhg7ao6a5lmP pzw6GuXjKhWojijLMkIvzQ/GmOyfncLxulkuORtleDpKxwQ+xvFuDny80yJvorPRrEDLtGmVFlmz CeEb2YyYyYyKuSjTkvnzZgt8/mfpZnJVllqFAi9KolgR+aZUe5Jri3QuJ+ekXIOnvxfb4N3nz1p8 u1YR5mvi92fSB6lZbZ03RZqvcv/WqIkFvtCSGuI5LzbPWuKHMz7KZ7N843s5u5oFTZU2jTZkWvhH hp7NvSz/4x8v2YuLN1R9dbZ8np8ty+XVdFF+labfmfJkWU6vyou30rPbq+ml2alwJF2+FR4aKs8e BE7zvb3FW1OnxcjR/dBB6CgybL97K7W0GAlHIgfektcZdp4uHZQiB0OpUiq8C1KTGk5t7w4PXxne Pbm1u3vQnSrthHdLqf2t3dLWxs6VjR9WVk5OwItSeycpkI6NvdTJTmoaRGN9fQf8A6piZ2Vk7vLI yvptUClfr6/PjdwemXv9GgRlbu7rHy9ND03D9mm1WqMBlLUMumRywK6GYNASkPo6pNb2dKttkFar HrLp1T2QA4WdM069E3UaLC4XwKoZi01vsOidSpQI2SyoEg2SPr0Nc+gtCE4oAyFIgWNo0IdZ9EZL N0qZLX6jL+gDNIQnCJUv6DCbwK/PjHgTOOpFlRhJ+HFUZ3VaEAep9um7lD47ZtRhFtyPdA8QKksw iAdxM/g3EVSFgmOYBdwLYeoApQfNotSTZDzQyY8KZV1IXNuFWFEzec+L+YJwl4NQ4WwwzuIe0u9f C5r9rNWsI9xjcayPTegGPX19voTgHxv0+3X9usR3JqZfMcj005T7pptlexUU0++nGPAJ78+wQtJq ZZiY203RMXbQRCXcHjegNk5gxzr5Mbm5a1GmTxFl+2OUOwoCoegFkMVQLMPQPMVzSZ9PAOMxgeZ5 8zyX8dB0v5nhBN4NskebYkksJvQhMntTEOisnIn3mjj+niAJgiALUu48mWUEEBQmUxD4aDaZAaUy T0vnEjiWMwzvEatpUTDNi3y2kuF5keOn6MNGrF2R2pIonbeq1QJgKfFDW2pJoixW2wUxlxUr1Uot 12qDgmlXs+2z+ewn/kPziZirncuzwiHIRVuqtMC/rep5ISNJjQLXEs9y5UZVzPL0Kn/++xmfbQhy tnz2fFWge1cb0TdUNvuSry+Gg0IxX38n1+ky+05ey6flV7+mV1+VV/PFSP45QKxIJP3zq3IxUi4v RrY3nZFy5KvIvXDxPiiMU+/wV0enYe+RN326vXR0cLR5ENnyLkUiR5GlpfDw0VEpHBkOLz0FaQjv 7oZT4afL4X3QIruAtMKpk/3SyJX9jeGN/Y29jdTyRgqwVmpvL7Wzs7ezk1pZebC3sgK6ZOcB6I51 cBlZfzC3vnIZtMjc+u25ubn1ua+/vgQPTd+CNJP2yQm1HZ62wUNam90Obmu10PSMBp4BYVFD6Izd Bttd6h61Vq02uJwBVK212QxOyEna7HqbLeQIWQIOiwW36MEBHMLwYDAImAjGSMBDTjRkDOlHxymk y2lQeUkyGMRGDRhmvKYMEpjeN4oZ/ePe8XGvzud1+H1Gn9kRZMfVY8Yhg9GCOPtREAezykgou/R6 1EsYg0FUZVCBwCnJoCXgAejmcDiDDgzHseC4g8XNDj8bQoKu3iAYv4ap2CDQIIKEFIZrKjxhNPpV Zh9mBZ/9Cf+g1a2yEqwfJ+K6uHWeirGE1U0IlPUq5bhK+fVXfWYdxVh1Vo5Q9Bmtg2ySJVgTKAyW +Ksu6QfuMciCivALoFRod4IhqBhQlww+n7hmSsT7563z1gQT18WSccWg0W1mkgzl/59xWicwJl+S BjMeoBwsK8QAfQGJyVA8DzQiQHODbi5udsei4N15N9P09dIsDeokkwEPAVQT5uvNGC/GaEnK8CAy fAbkIMNl+IzESeVc82ajCVBMACqSEXmpSo/WMwW+CRwjBwpDrLTo8+qHWudWpfKkUhFBLqRmu9kW 25VmRa41s6B2ZEHMVc6llvi5CpolUxCr5+cVvpDJCeeN7Hml0GplxXPprMGdFcRW4SxzxgmFswuu vipQs8I/y6tyuSz8k5fLF9SNSD6/Sifq7LtiNL+afze/ROVXfy0vlsm8L/0qXyyXi/fz+fv3ivn7 r7yRvDN8P7AbOYgs5QPe7cXNwJUh71LYu3nk9IYj9rD9NHxr4aB0sB0+OPIeLDl3SweR0tGut9MX W87l1NFQamt3OrWRAvVRSpWeblwa3kulNrY2NvZ2Uqmdjb2VR493dk52Vvb2pnem93ZWHgHiAgKy sgK4amT90cjIo/VOMtZfd1Lyeu7rSxrNbXTytnpyYlKttcMTQ9AGZHdCE2q1Uw3PABPRXgcABmtn HCh0dwC0ihaoiNrmtNtAckJ2pV2tvD8wZDDMGJyky+LF7AMq0oUEAnrS6SX1TmPHl5XOIElhSNKF IlhIOTAODlDcolJYSGxKj/STeoQ0jI/jRNCLY85rXsIx5dDhBGYmvLiR6OiFHryLyp4Eqq3XKww4 6sH1FlSBGVGVU+kkVTZC74jjhMPksVzzmik9ChJGWsZIzOenjEBFDCRBjho64z5MOe6xdLiur3eM 7TebESulwhI+0CgJv5vGOklwm1krS5gZwGUMR4wiGAs85i9EcqzfxAz2ETRoCOtNVR9DDlpv9jGJ q76En2AJzk/HdKyO5W56GCtF3EywIGdJ/yhiZhMcM5rgxkzzjAkDysyyPvfoKICseBQTiKtsghX4 BBfnYzrGneGicSHOsTRXp7lMkx9dpAUuyZuqnDtNC6seUBUCCNNiVGKjfBn4/WoiQ0nMOZcDrCTI 5xxQZrHJ5MCFqzQbq1H+vFLNZZ+1Y1lRijJSriVlGrkoeL7QionNTKEpnVda1War1gLsddhutGtS VXxSBVx2eCiW5Uzlf1dF/qd29vvWWfasBgjrrMAD8+AB34EIyk2BO2u9lxoNuc4X3jdooVHn5MaF XBfOL7Kjq/zFRWI1/p4vgrREWHlVjpdXizfy70zl9I18fbH4vPyKzpO/pl/OhmbTz4uLeaDp2/n7 xVB+s3xrKHJ6//798MzPS+HwaWQ4sA0ICxDVsHcLgBXwj3Dk6f7WgfPp0u52eD988DRcOgARCW/t g8vRBrCT/a2t/ZWtreWV1MbOyn4qBcQdINXG9EpqBfjHyvQeiMfeg52Oe6zs7HV469Hr9Ue311+/ BhH5eq5z9fWj2yOXbndr1HaNZrp7enJmYVIDQZqeiQUYgqFJFJqwO1F4wTXRAwzlurMHuIfN6YRh iw12ugIuLax1EVoICTlgNaIIBCgKV9rQXug7woKqUEcICQRZ3LmWQBS9CoTydTuBJAfHEdTnRYxU sHPmiVqzAKgaVzgR5bh/LYEjU5ZeiAQgZQHkhBqMrBlfI5Swckib8HbrnRY86FNjPnSKJIKkFnUk iA6T4ZAesY0b1yg9gqoUCiqIWlRY8B4aYlnteJKElcregYQKuqbHfCSO6IDkExRLYJg/San6PAm3 YqwPhCCZ0PUPziv6kuxVndnNeMwsReiph6A4+voIrq/PCnwjQatifpMViDs16GYeUv2Dfs6NWPvc DPeQ0w3qbvbqHvrndfN+RjfGJBhd4qG/d/QvKorrHYy7aSbhxvj4vB+MM2Zr5iGzqGO4ea/vql9I PsyYPZ5VxF+NRWmaETyswDF08qF1yjQ6n5R63X6Zz2TcHuDXQlNqMmWx8pAHUMWtWmOrglStZsp0 LDubqeZivCzVaKHSFJiHx/GbdFSuSlOiILYqbbkhiYVKtV09K0hfjoUsCERWyH1fqfz2TALu/v1q tQoMXqy0c9Lnw8zZT9VYtpBl/miZWoJYa7a/bwCsalYr1c65ryqfFd/XVoWOsP/xsJGVC6urSS4r y4WzRlaQQEQeXsyairP55MuInM/KF3IxC7zjgqo/T6f5358vzpafv+zNR4qv6mvP05HZYjjyPL9d 3E7ni0vlV/ml+89Dw0PhcGAzrDhY2j5dWAofeMO7mwtHIBend4+GwgcLpeGl4VunT+8+DYfDpSup zd1UOLx7EF4+ONpfvvN048rwyvDW0ZXh5ZPw7n5qpXSys7e1vz8B0vID4Kq9jRWAVDt7jx+DZKys z71+AIxkfWcH4NajnZFHD0a+nrt8+fX613M/zl0C7WFTT3drNOrpb+1Oze0JLdxjvz7RMw1Pw3D3 t0DWXTPwJNw9aVdPgtKYAbClRXu67aAwnKpJygUHDAFUqYZDiJZ0wUqPa1Jxl0Bhixcc5bBWP+VK uCwGFHzwaw0WxEIGzWYH1q00jK+RuHcg6ZoKOqwqBEWN6H8H72XzGdVKikCUXr0FU8FOr4pMOEDr KBx6QGdqPTlu9o6j3QgYN+pV3yWvW4JjDmQKQYO27wjDEBp0faulSBjxmjEMVQ5gGAHGHUqlXz+A W5Axwu/xGJFu5ziRJD3Y/3io95BWP2JS6Yz9Rg7vBS6vHEuSvf00UIq+fqvOzSWtHj+CMe7xcd1V IgHohkG6xlguScUGkw8H/ZSfHb056DcOEMlrfTRl7DUmjTd0NO2m+wb8Omsy6bOO3xhjrEarGYhK jmaZXoWPSSYF/hoYZwQmborOC/ExLmle5BOuKaoaH3XzsVjM5GCiTJWL8fFRXoizfLSj6zmB7VWx wsNmho8fJ8sZgFfZbJmLscnzVXeLC+rOq/F5XmzkclG2c2aq2cjw81INNIfMNCs1UBKjPqny7LAt Cj9VC5V2JVdo5JqNRLWZzbWbPF895uWPrSctMZ5pic1n52IFWExNALk6q1ZarUquj5fOnzVbjYuf LhrnUjtbkOVzmqqercrShVl+fx51F3iZf3mPl2XufV1mV9N12cdGV99RdVmuF78KyM/X6nKRTN4r b8rxSHHx3qvF+8+BbrwKDTmf3weyXiwWI+p728W7P3sXncO3fl20eCPhwP309kFg+JLtdOHu0cGt p3fDwEYOhkvhJfvy1sKt4W3n5PDkU/tKuHSrVBqGdsOlp083Sssr07vLG6A29h+XTpb3rlze2/th a+NkZ2sL5GMvBSx9+tHKgwfrIyt7mrnpByvAPkBI5n5cH3n94PXI+sjX4NaPc3OXnBrbnaFJLRDw 6W+gOxMazYSzp+fOJDRhgyDndI9NDasnbZNOSI261ohJDXARyK6d7oJsWrXN1oNeV7uMXgcJbMTW 7SQxtToU7IaJGQBDSjuphHxeTO9whozKgG/t2ZpKiettiANHIMQ8psUs3QaHJWHEScIMhaagznIG YnQAlXeq8IDSaYSVPsyrd6mC40rckXyYQBDciyAuTAnGB1AvAjn0+oTDR5IWRUgJ+YHvoMS1SwNU vwrHlKGgwubBzPqgyuhQ+4wPnxFKi8+MoCTWq8DcBszTq2D1dNLKUtRVJN6LUIS5T8/puv3coM6v UxFBhSdmBipuTlj72cSzn4g+t9Xdr6MGEcTtHx+LKfoSOuZhjOCoq1isd5Cj5vvHkle7EkAfWJ2J iivoWDRmZdwJH7DvZ8+IKT7uxmhqHhl1sz7f9woPNw/oKZMUpnyxXjopRM3s+aiSS0R5IRrl6F4x R/MMU+fccTH50zN+UQAqzAjR2TQIDJ/r5bnvm1WRa2ZMQiEiVoUsnanMmqtA21s034yZaq1GBih5 hW61j//9mZiVWrxckb6PAkwCGGaSKuJxtX14XIu2c6ufjzOFXLNiahxLYhuA1KFMv221ak2x2Yy1 2z/9n38Uvm+3CoXzVrYMxutiYV46E/+QpGbzw7yUTbff57JyUrjBV+U3wj9WhYvZMhB3/ix7US82 hIf/wc2Wedm0+jw6G0nL8XvZqUj9nrwmv6LqxQh9I1LfTEcWnxe/yj+fnQWWns8PL5VnT7357Vfe W6f319buh5cOlsLAyoeHIwf2W9tfhRdKp39bOlo4TQ0dDIefHoVTGwupS0dPU6WlcGrLdqVUOtkt 7S9vLad2t/72t40VwFbDKWDuK6mT6Z3U5ZXHKxuPU3uPT0ZWdi4D5ALN8WDk8h4QEFAgj9YvrwBX X1//8fUcuPfgwetLmm9uayc0E/ZujQ2e1qgnu7unIY3WPrE8CSgLxEaDLmi1yygMtES7YOuBbZPd zk2XfRm1dcPXEVjdPWm0qw0OCHFpLeqQfkipRWyuEGb2WdCQvkuNuAhjyDtmR/sHvqNU3RYchUiK 0qv0KkhlRJHOqSknSo5DZqMTQx3OIcSJYuSY3uxTWYIWSIkQpDHgDSGoZcBFwJAKVw8RBEA4sw3C XAgCdy0YVfYOZRm9Ku24tletVztJ3Iz7AGUhCkSVIAnwXogFM/wPQqHArEpkjaD6vR5EEQqimEJB sP2GhEfBkrrBMQabUlmR8QRtBSDlY5A+VTRJJDy0f1A3ZkxQin43q9Q9TCQGQT/0Ev5+nRIBHDXO 6acYkh70E4Ozg7GrTCIWY2PzoCr6F/mHBOXmrSb3OJlkFDdpttdf5aibdAy5moiZ3Ep9kvEQnHme Y3kz8O55mo5yEtB03i0ISLSz+JGJAeWgWaqa66Vz7KhQbQrZBj8aPQfhQ6xNgeYq3gIniLR0Fs2y uVhFEkWg7FILo2OVahMkhOeZM+64cVWsMavN4+NMribOi81cjp/nvrTE6md37bBVq3+WCoVaTqy2 P9WAsn9+Um7kvlSrUqv9QWydJauFm2Kbz1arxw3g46st4CC0iWs26lWp2DoH79WuZ7ONbCMpNhpn BfmMnl198/7id5mvR8vyO+pidvRlfXF27eLi5ao8eyPPLqYjQ8/r8/ee02F5M1289yp9Yyl9o0y+ TJfLgLIi4RsHz+9vbqfTkaWDO5v5r8LbgeHIz5sLpe3F4eEjbyry1VcLR2H7Qnj41L4N2iScWt4e PrgDLGUXUNbK8HDpKbCR3dLwyfLGnd2R4ZONkeUfgJCkUiMrG8srOyNXHgMH2VhfAZ6+npoGgVgZ 2Xu0s7Kz3jnPOze38qBzkndkbu7HH//b3CVN99fTk9DtyclpCNJOTNq116cn7RMgDhAEegWanIAn bWq7dsIG9/RoB2C1PQRBMzNqtdYCoa4QhEI9TgMMk9dRxG50hlzg49zh8KIBTG1xuDAUtzhDei8e wgJTXZDRiHqDxl6UBJqA4wqcciAY1OUIKlUJg0WlJ/VBco00kw69yoEhWDCoVeEWPa43O8CVsltJ uqYWjQ5YSzpsQOcVDmIAwbohR0ipTTgtFpwMBI1rjmskDsYtNj0ZVDlxlQHXe4K4V98LeimEeSm8 9xrlU92zYgiZ0GPmS32kVelLegbNLOEnqKTPn4jjOnYes1LsoNWn88esMcbqtiJd33HAQpKePj8X H4yz5sEEd809eEmXsPYRSQBkCZJNJB7SbCLmsTI3B4F6z/utOpaP80QsTvcqjJybjiVvYgRHe3jG 5E5yZnq+K875TBwX89AcI3DcQznD8TTDROkM14iCxhAYXsjwfGzqRiZJ82Iz6uE4Xs4I5lz1PNqI 9gqVeLbK5fhcVeCa1WquUmnxksg3uIoIrsV2S2y3QV5M0WazIFYAR1Wb4NF2VjquFFrR+UpTFp8B dKpV280vz6qfDiufxMoL4BuHYPBJrfKp9rn9pJ37n/Jx88PHZiV7Vm3nWu2z7HkVOItp/rwdFR9m PjTOmmdc8+GFeH7WkKUC3eDOAE7JfINvCI03/Gr4Hld/mb34h0m+4NOyXF6sX+RXy19N1fNTv66V V1dfbebrP6+Vyz+X08WOgWzmZ++dggu4lz5YDF+xb3q3tzeXhrwLxfDBaST8dPNWpHTp1tHS8NFm pFQ62rIfzfxt9+Bot7RxEA7vb4GM7C7v7pZ290u3Tq6MbNxJnZzcSe1sbKVSJxsrO1uPgaRffrSx s77xAERi49He3oPHK4/2dtY7+Xj0CBDX+o/rnZ8fOyd5b69f0sA9mgmg4ZOTQNXVAK20GmgCPOSE eqa1k/C0HdZ0fwPuwTOTkM0J2UBWuic7q+ouSG2ZAdGBbCFnl9aBu9TKUAgJXVc7LbASNyIQZgyp LD4U7uqaIZVOUo/iIcTsc6ihEK5UGQkYwx1THq3Sa3R2GYzjRrXdaLCMD6gDFtjmMMIwTjqm9D5Q Et2OILgDwqa36R0hGHJgCovRBXtxA4ojaq8RhYLBcRAc48yiUW/DERg1OhQwMHIUxxFlN2QMwkGj xTKuV3mCPlhp9Co9lAsxs/h8HFF5qD4lwZDjyBg15qGuYf6riI7y96oYyoextErVhSSMfRShczPX 3H4iplRRgyAk41dpykezfTp/Yqo/QSXGVWzCRycwN2sajSesyE0qQXsYuq+vS885zBwRjVEemiFo BM/Mm5gkHo0lAECNZgVqFOcyHK3PcDGBi8aZ+XmGi4/KIAh0Rp439forOH0u0IyUzQmJ2CIrRWmp ScsiFxOZm7yUmWUqXEWmK5WcxNGiWM5Kzdj8k2alIbYL9Pxi5pCuVaVcrVKotSuNqPQp+6F5KHd2 lnwSAUpJ0fbh52pBOGy2Dis5gFG5ZrUgt6uVjwDBCjdXm4exdhWkRc29MgoAACAASURBVBJrlUrh 385r2VazmW212x8+8bLYbKyeg59svXlWOBdkYOwyd7aaPjsXskIjW76xfUEtChf0y3/GX4JWXJy9 eLlIX9Rny/X8S3mxmH1evFF/9y4/Va7fW/0ZxGE7kt4MhSOvNtPb+XQk/NWtV4Hw/ftT2/ml7fRR cTh8v7Oqbg9vH+1ue4eBpaeGjo6eLqW8R7bto3DJnkrtHm2shI/ulML7peHhSztHE6mt/VQYXEr7 J1eg/Z2Vja1pIOkgKFd2Nh6MaDZARNb3HnROYYFWGdmZXp/rJOTHznr61z8+mpt7vT438uMljeab biDoGtAPQD6WoYlORrSAsLQwDKknvoHU8OTEtG0atgPLsE2qB65r1XYnEBHSjthDWpAfWD3TWVok XRCM2Q2GJcOmw4k5XEDSvZZu1IvhdhRXY6EgpsADeiNpsDh8iNKxhoEPfeAKCqV3HIgNsuboQs1e F+4dJx242eiyYNg9W5cFMwdA3SjNDgcK43owrrfcD6gRI2WxhIz3vDAM6x0oAmsT17tQrz7oxIJg /J7RYcG8HiVkxnS4yoyrPcbxKcRn9hHgL5IeREVRJrOR9JkVSJ8vqBpVjievKcw6K+XxUAm/L075 dR5fTInEdfFxM23F/FQnC242QcVpyq3Ckwk3TRG8Ttk/yLKDV0GJ6BG3m6VofyLBxtjOKeNYrBeL udn4zZjvJpPIjdIMTQFiAsG4Gq8KnT1UbLTvnltg3PNYMmnGQF9wsfp5QuBBjfCxRg6hczzD0yId y3CiSRRy3HlnySMGyEvgxcqZSC/SvMTEotFq1UyDyqh8kKqVTGdZQxRb4lW+c+a2IfFiu9Kia1Lt sNoWQY4KlWe11ttqu8bTOWAZotx4dhht1GqH7RfN42b77WHzyYvaJzHaqtVAubRzn5qHH75vf2pX q+2PzTZI0LOPIF/tVpbOnlUahWzj2cUqL4rnrQbXPBMb5xeFQkMszzb+k69n5Ua0cSG8XG3I9YsL OftP2VS+WHuZrdflcmRxSX5VLE7l1wLhdLr8Lv138ud8ufwuXyymXw6FT4v3TpeKB5Hy/XJ46bR4 tLlQXDw6CC9tLmxvhwIH28Ph8Kk3HAYlMjG8XTo42t49emrfPrizWyqVtq+kQH9shEsdB9ldOdk4 2d/aPznZT63s/bCROnm8kdoZWVnZOAFK/uAxyMXK9N5KZ6mwsxjSOaV1eQ7Ux8hI53J7/euvL01M /LnNZBK0BgxpNJpJNaAt0CQ9E9PQBOSyTy5Mwmrb5ARArYUJjVZr6+DVgtOmRu1qtWHB4ERsiF0f 0kJqvU2ttoUChhlLIIRCuA31ate+C1EDlgDu83pRnLApHXgoaOkcw2Zw4KssRtIVsGCo3kF6oX7c jqidwdB4QB9yIHAIeMPAGm6knN4AjmNeVYhUow7wlMobJANeiz6AeknS5cVUdtxhRBXOexZE3Vml dOKhkFIdQrwW15qeIp3X8JDPbAZ/qtcSNButFg9J4PfMOD7qowhWBzQ+yBKjiNuKqUaNrJ/S+Vk/ gvkX6cHEWixJeWIsG3e73QliykrQCVYHSCpO037rTSKRINy0zk1QxFVVPGY2myiGpdwME+zzxefp +WSCTVJR4Nl8zB1LslcZIcaxboFL8LEYOKwTHAdiQoPeEExRhgd/ghMyIAEZ1sTE6Qb9kBMedu4K YiPGVHkzMO5zPiYlATqJmRyfbFaEnMiLUjOT5qVGjM9VJA4oR5uPgky0mGeVyjOpJUnt1hOxfZzj K+32YavVPK7UWp/aT54cVg/brVbr0+dqLdYCKCbWDj8fttuVXxryLyJ4xU+VL8/atfbnSu3Fx8of H8Rm+3MTsBfIVasmgSBWm62W+EFqNxtlsdUovBHOpXPx7EzKls+yhcLF+/r5e0BYgvCmkL24WKUF +aJe5qmLf2SzALLiF8/r5Wy6LNfJYuTXX1eXtvPv8uRqPp+PLJaX0sW7P5efbxZPy/l7xYNtUCre fHHhdPt0YfNguwhCc7SwcLS0HQFUdRQePgBYFd5yHhyVvFu7wxuAr06ePt19ulXa3d3fLZ2U7nSW 0UtbG6mNra0TAFuAtR4/3kt11tI3QHF0VkbW9x492lsB6ZjTgHyMPHi0/gAYCAhHZ6FwZO7SxDQI h0YzDYNr+PbtHvUENK3R2LUaYCFoz6QW2nRNd08M2Jbhaa22p8euBm0xbbOpLajTDlvuXnfOgLSg FqdlJmQBn+cBp90CIy4HbPBaDJDDpU1SCDRj1Hst9qDhEox7cVSJ6C1ePODQIwuJYMBhxFXewLWA YxyMIz69F4NRAodBhGZgo+F6kkQUBhKzgDRpLyFePYAmVG/BcH3IgrgoAHZBs8V771pg3GGHFfYQ prfAGGFWOrwBLUI4jQ/9amXQOOhdNJPoJYs5hCM2DDd7rL5g5xRw0EqSnkFwz0qygwhyjTVbsT7r mg5jPH7ttcTg2jMWeD7hdgOUQrqsbsBcmDvuiflZRnczmWRApbjdMb+fpZjBvj4/445hGMPpfAxN qPxJ3cNn8T5zgorRUYZTKliaiWGeWMcyBCYaAwkQOPAciBAIyb17XlHg+aib48qMGJOuZs7pZ8/4 RT6Zycnfc1zvIqiWXBlQVC4jSk+ymYdNSWpKucaTzBOp8qRM05LUEmm5WolJklgpV5qZn45zWala q4niYXuUBjYhFsRPrReVWqUmfv7tsN08BqLxFgTnsFYAgtOu1XIfn33ONYGnx740K/9+LMqV6qda q/UlM8vX2p3xdusFSFGr0XzWbDebNREksHZeaZSzDZDbRlZ8L9L/ajTq5XOe+4/fs+mzi4L8hv/d N5wHSgJ6gs/Kdb5efnmxVpef17PlsvyrzL4rbk/dC77s7DR5nl7MF/NLiz8f3F3LR269ug/ycPpq 6MpB8agYjmynt4ungdPI9uam83ThCCi55cB75zQcTh1slQ7CqdOn4Y2D0tbw7tPlp3/bHV4+2i+d pPa3Rq5sgBJZSS2fpEonGxs7gLv29jo1ktpL7T04AWWxAxpkfWTvwcjrnfVHl18/WH/wYGTuR8Ba IwCyRi7BoDWmp20Tmp7bE87JHmAfkAYkpNMf0xOaSe03kFMLMMp+R72svQ5roGntjBOCJlBgH3Y1 PKNHYMQCGgUwloscgCBUj6q9asSLqpyoV+m43oPeDaJKb4jEvEajHUbQIGlQq8ExHvDpUWD5IGf6 AKm3wTaS0ncpMBxFvWoVwCqvBYi09tIAGQTv5jBavEYXAgPzJ51KtQWMG7w2bTCAdjJDWgBjEYQW gs0hpQVTWgIoCIoKJSe7DWBchQeNJpw0IghiJgl9r8qLm31Wz1SH8Cw+PEiZ+xDrWgJTTFnjfT5d n9tqtrp92Bin7CUSgK1YirjpT7Cq/n5AUDp0kI7ToFb+yhJWsy4WI6ibo6NEksN6MTZuiemwmDUa p2ODfq6rj0uwJprhGFpIspjHDETcg7n5GC8IfFTgeHcMgFOCNs8nqtz8KC3wnhztFvkYIzMeiet1 n3N8NCc1hVymmouCCDQlGuhHQ5AyDbrSkXMp05T4Mt38ozLvAcco34rlag1AVk/kQ+6GeHzIFGqV aqvWBMd6TqwcV/hcq/aiXQGVUa08+QjScdwWc+Ifv1Wyhdpn0ByNj59Bglpt8Qu3Kh0fgkeaxy9q f1TFXKN1+Ee78KFVa7XPQTCabbHRkv5V/Vgotx5WhdWyeCY3GvSHs8IHocDLTV9ESJ6VZfGCe9Pg Ll6uluULTi6W38gdvlrNP5fLf5d/5Z+/XJz9de15Ojz7a3npZTkCUlIupw/SzxXhzc18+KD86v42 kPZIpJTe3FwKRw4ODk4DB+HTpwcRcDvwtASy8beny1+FDw6GtkupbUBWpe3w7tNLw3dAnZQ62xV3 7+wOAzvZ2kqtgP4AATlZ2QDhAOnY2PiTsTY6mxV31kFCQJeA/+YePfoa/HY2Y4F03H79+tL0xO3u aY1aOzHd0zN5F+7WTANZRyc0tkloGvoGuq6Gp6fVEzA8MwDI6g40DS9PLjiBlEzYtDYtPDRgn0bQ Wy7XjEUzfTeJwmq9Q213aG0O3GZRdzsJvRdFARFhpNHpou4jNhR1UAYVaka9uDeAAGhSei0IZcQt ELqWRNU2hwOAksriwlGLEjIAmEIsAS+qp1zeTWpGjaIqB+UEqeiM6xGtQwtQamrNoUc12uQaAtwk pAwEUQwkxwtDRlKnR/Qe7yKecOBEYmBKBf4/EqCN7nW2m+inrrGYyoeZk0afSjH2LNGvMiV8oyxh ijNus0eJJAjad9VPu91k0u9fS44N6m66E0kz6B8P29nX66fMZsBcD4lYXy/xUwIzRznfIEWsAhfx uRWmZCZG32RiMTqRZIVk0g0OcT7Juel4LCbwAu0RqCjNuBNVgTGZuJ8EHDxL05yQzXS2pY/K1Uwu F5PEDk2JXBWIOc8LVa7A5zo7ciVelqSsKBSAGog3s9V/F+MgSTmxefah0m60+PnWcbvzNQ/w+X98 WKseg6daYuW3SksEiPW5cyr3sJ2r1T7+dvy5Rrd++vdW48nhodg+BC7yWfyUyzZ/a3/62H776cWn Z//77R/PKh/E1sfms/af4+1P/yq0mq2C9F8fnjX/JabF/3j2n3yhKb05Oy98OBfeNKJF7lxsvGmI jf+svz+r/55kX2bfZC/ey9my3NkcL6/S9fKqHH35npSL4fzDC29n18li/t1s+VW5WOy9sfmu/Pft Mrh5/3no9O7Pi9tL2webm9vbs0XgI6dL4dOZ3dJp5OAusJJh59rRcri0UAofOYGLREqlK6mnW9ul k12gI1s/7O4//SEFrHz5h85JrFRq42Q5BeAKhGVlD5DWyMiDHzqbTB50OGt951HHQEY6i+qdlZCR R49+vP3o9aWe6Z7bUM+3k6BHII0aqPltYOwT6p5vnZN2uKdnYnIahqanQXwm7T2ws7OdUYNO2mBo UmtTb9igCTukRoecITVqQZHrC6QFGDsS6OxixF0oBOsDFgsKSmFS4dBDXiOCBmxqgzOgVBoCoGEs CsBjKova5QBFYNG6jKTWHrKoHE7oO9IQRLvVIT2GdsbVsMsJ4eOIRa9GDF49rA4FLKgXhbwobLEo jTNIwKzCXCSJakOWzvqJiwgFEcjm8JpRi0qlR2xGFA46psx4r8URwJWqIA6Oc1SJqxAPpqJ8Kp/b NE4mKJUj7vUQi30JoCd9Cj3rpjEc6PqUnur/C+UfpP19bpK2Ijjjd7v9/f2xfoyev8Z18rJqTCQF jPRHY9RVfTKTYFQIcJbYNdodj42y1GiUi3l4/2KM4uNXWQFoCG/WiWYPT7PJGC3m5ARXzbgzgixk 5tmkVGEwkyA1+DjPi/wqJQHSArkArQNe4c5IQNJFD98ClyxXyQk1MZdsViUeWElbckvH0mHLQ0vt JyID3EL8vtn+t9oxCIuYq7TfNnKVjobU5FatAOirethqv629qB6DPDU/gdR83/zt85ca3ah8/tQC dfFW/FBtZz9/AW0jfqhIbblRAaH7JMotcGkVqu3C//viQ6tZbTbqnY3wjej5e+k8a5LPGh9ouSCL 5ewFXTwDXdJIZ+vyPxaz9YacldOL4PKmnH4up+Xsy/zPz+vFfH715bsi8vPPr15Fwgf30y+XikDX S0uvIjdenUaKp+GDo3QxvBQ4Xdou3koBPwcS8ueexdLW0cJReOugtL0VHnp6dGd/eHj3oFRaBv5R AvoxnNoqpUoloOobqZXljY6GrKwsr6ykVqY7exZBWh48nl7f21nZeTRy+0FHRObWH3UCMvLnV0O+ nvvxEgQERNPT8+fVtOb29PQ3tyFAVprLGlhrn9T02CBYO9k9OfNt98LkhB2Gvp0BUAbbNBAKawec Wqfzlk0NDVnAQau2I7Bzshu2oQ4X1I06jQ4DBFzdaXRCBgJWrlmcBjDjQpSQ3QshevV9B3B2g8oL IA0PKUEMELSzxm6zGIPdkFdPgnF1wKY3akEVfIsmUCeuVlx3qJWQ0wIhTsThCOEhvcoLw1M4DqN2 DIzDEGgX0tEN6UNkUA+h5ikHicIkCRkSFgOOKIwGBBnyYBCmx1ijP27UmT0IMu/3IZgOH/X4exEz Zk2MX0J9ZELAFQ63jqBUqqQRoBbOxjEkMa7qQ2ODvT7cSnWUnHbTqqu0YDV5aOtVv7931K1jkngX wKtEBu8VaDqRMI1VXX9JJuIUbzYlrWaTTpw38b46x2WERIyPmaINKU7Hc+Dg50ejhRjX9PTGmOS5 RE9JfK4prQpV4+rxGSPlovEmT8/zT8pZgZcqlbbEdb76BBiK5wFX5SRxXga28UVnEqXqYSVGt0Xp SzvbPGYLP9Wkz61C5ouYy2ZqMkjKL4eHv/zSfPG2Vfj4+RexVnvban1uZT+2Ph1/8WTblT8Of+Eb nz9+Pq4Vjo/Zjz/V2hWxcN4Uc2+kF1kw3mx2dv5+rPHyh3a70BBbfKNNv2wUxOb5jdUz6X1bKPJi 4excXn3PeRvv5Xo9O3tRT6dn+TeL5Xj54p/1Rh1USXH25Tu5mC6XZ8tyZHu1mH+e/ypCvyLf3Qvf e7n4anPb9nxhKL95EChHwpunkUg4vZ06WDq4f3R0unCwDeR8GzRIZHsXANZwuHTr4OmtS+Hdo6dH t67sd5ZHUstP1StPt072S6nhreXhlZ3Szspyam9/A/x0vjn15x7GFUBXqZ3OJhOgIJf/3Pc+8nVn PeT13I8P5uYerQNJ//OLhD2gNL7t+VqjVqunoW615lvg7d90T0yAhAA5AX2iuXN9AtTLzB2ox3nX 6dROwtCM3e6EJtWQzWmDtLcW1FAPGpqZcarVejVAn2+7gK/fD0wC0gk4uybvknb9jIt0KSCScgQN AaWaDBgMsLOzvxdBnFMkAnU7XQ7DjFIbQGaCTgVkM+iNoGQUcAjt0t41ojMGF+mAIIp0BAecMErq DU61E0EsoLucqk2lBgoEHSE9rHciIQcKQSqDgdRqMQgZR6HrVNBiCJHU/S50jWBZ8Nf1BO5yWvAp zONH9DhO9HYp4xQLguLHTQQ5qOx1x1lK7zMr54k+JZEk3EYiwfm7xh5SlBAc62MTLGXG/SY3TfRZ rSxxQ9HPUATjVwk+N8XcREZZluKusTokJkz1d76GywDG8iuEZ5zEMVZTAoRjngVHN8N4WJ4T/tpL c5196x4pxlcy9OhqRjyv+Fplk5Ax+ZJVUchUqs0YUnlWqUhnfLYpZSq0IGZFSZAzYlMsjzKHIDAN vt0AmiKncxXp8DNTi2XbUlQ4PgbH9+HxIR89/unwy+e2+OH4bbOZAwD26ZeM2H5xLGazlS+Hv3xu SZWPzS/tRqz1S+WPSuZt4cNnKdt+9kftc+XLb1+ysd+eHX4B+Cb+AcIB4vih9Rmw3n9VC6tlqdmW avLZWUE6b5RXG2fSeb3Op19y8mz9/blcF7jkPyPl9+cXZ0A/5N/5On1PXi2/qS+W89nns+FIvf7u lTwF4OodW4zcKv+ar3vLxaHiq8jQwvN8MZT/+efTr5bWNvP508Xw0f3ThW17sbRdPAovHRzMpK4M HR119mWd7kaOtk5Ae+xuHS0vpYaBrGu2nu6W9vd/uLNxeeNvW/v7oEIe7+/tr0wDBTkBXp7amx65 vLK3t5daWf9zz/vI3MjrlUePRjotsn557jXQ9Nuvb1+aAIquuT0xrZkGEemZ1KoBTGknJ9Ww5ttp Tac9vtFAUE/PNxpAWhq1a7L7W9fA5PUFLXhOo/62u7P2blPPoHbnzGTH0w3ohMuxEApgMKAnVGsc 6IanbFB3t9qCALhac3ZrqYXrm2QAQhDIMgEBRQ+hWofdqXdMQihJOlCUdBlDPgustcCWGVLbDatA drqnLIha7aJQaIAAHEdaIDUYhxVgLgRMxBYIhdSQFoyrtaTDFcItSr0FZIdQQsgi0tXVZcGmEBsB xo3Ud3cJAvg4cgNT9mJA0VEHa/b5jWivYy3BIsEESbB+TGUdxIC1IEj/6pRC0XtTp5u9lkz09yaS 42tcYhDR9d28hvzVx7KMmWFplmBVU0QyIfQJSSrBsDodr4vGE1xvf5S+2tt7lafpef9D7upgMkms JbmoiTbR1lGaFYQ6kA5e4BigLw85wcw1OU4S3LxI55gmBxolNz/6l6wYy2WFZ9I8fZxMVKuVMp2L ivFVPiO1BfG8lZGamXIMaEaGP6w2K5/bMUBPIvelEi2IH7PRVfGF2Mo1f2pnpd+ayePfKp1vb7wQ Cq32//VLDUjH518OpULtt2dfpNbxFxCU9of2W/FF8//hsuKLj9ls9uOLFlD6n87eVH5rvj9+9kkW PxRaPBhvVxrt5n+12+eNrFCtnsti9bwpSY1sA9gH18wXsx+ys8XZQuFNVj5/T89eJN+tXZy/WYy+ TNOLxbzM11fj9fI/2Fem7fza83dL+efvyPyr4hIwj/Tm81ugUraHh8PF4vb24t2fQYX8fGcBaMjQ dnh7aSi8dOo9Kh0Flk6PvOGU828LR8OAs462Ont5w6WNo6dXQKUMd76efhIGRbI1PPzD1uPHd7Y6 ZJXaubKTOtnbW9nY29nbm14fefD4waORvQd7jx519vKur99+9Ojy3Mj65a87W3nn5kYuARfXQD0a aGPCroVufwNk5BsgHtrJiWkYZKdn+g54CthIN9BzdbdG22kbdU+31glBkxNqclKj1dpt07csCwN3 jWoI0obgnokZlws4QgB8vkMDLtg+gIdQCCiKF4LHUBjSqroB6ignB5AAhcIGfQBVq/TGEEUCmDM4 AJuFSGPIgAX0AN1c34FGCTnUCq1FZemanAHV4ES61UYnDMZDhBoJOQNqxI6TDsqFQOoFHOrSOsA4 DhweVQ6RA0p9yBdSw17Mi3Y5DRZIgSNdKkKvdBpGCQpxjuPWKVVnZ3vSr1JgRFyhGCcSFBuz+j06 RJUY6PezRHCqz3fT3d9rtOoUV/03FNaEW/WddTWZQPyMlb2qAxzFPWSv3vAlYgrQLSAnPMvQdJ8n 6XYznXUNXYzmB/8i8DTyb8zsXwSOvkbGYtWMRRAEJpoVk1y1ykTnmXP+hjvTrHKSeJbheRNTzfIS sJF0TMy1zKuVXMzLi/9zlavE4hIv/ibRklQTZLFWrRwfi3JWOiyM8pXjL823nTOyrWylCuirctiK PXnx5FM2d9jKZWu1bOHL55xQab39qdY4/Py51nrx+fj/+OmPVuHD4ZcCeIvffvvyy9vPn1+0cl8O P7Y///KlVWi/ePEp22q+KGTbreyH43ZOaH9s/tYALgLK6GO72nzW/JD9R7NdXq2fV5tAUM7Egvwy KbwRz84usquNQkGe5evybLGxGsmuyen7/MuL39P5ulwvvnxTf/7P5LtiBMhI+EZ+8+K5LANNT0e2 n6eXfu0si0TSf//7VPg0XRwunYaHDzaXwvaD7Z/vh+1HB95SqXi0sPA3b3g48nT7yvDW04Wnp9sH QD+Gl5+WwrsHW7vDQD5Kwyv7pZMrqY2VKxv7Kc1yKvXDxsrexp8N8njj8ePU+sjOg53LI48egIh0 vhuyPrf+YG6kc1oLxORHICGXer6ZhoCha769rXkAAU+fmOj5pkcDw7e7H8HwxMS3ExrYPjlwRzMN DGRiQgt1tmw5p+1Om3MGVW9e75lwOmdstxAnhM5YnJO2GS2kgW4N2GEYtXgDWtR5y+mYIYKwxan9 Dh0I2VAl6gipQyFv0OV1rl3vVgUcDgtqn1HMfOcdQC0OLQTBSAiF1Rav3qDVWpCAw0CFYK/TabAb BmwIrHIZ1C4w7rDMrGm7nd7OmWLtAGwIeWdQpwPVKGBbZ9zrvYdrnZYpR9CRwGFcbwg5g4FRFDGT hj7S4SGC82QShRw45TNjuAFhg7TDayX7FX0IzmII5qHjfoPfM08RRHJMxVpZo48acw9i8cQ4zrEs x7i5h8o+xs+xUbd/TAfAza9jhMFek8nPDGLuGM8QcZASjuIe0h6Bp8AIHfO4M2D2XMg0M98/rCL3 JCHZiHW+dsuJEhOTMlGs7M5k3OCj/4kk1DMFpilVqzH+jKkwmWYuR/OVJi81W5XDmvisCuLQPnwC 5LvzEOiSipSlC4UKMJcnAKokqS22D3/57UtBeisdSp8PX7TE2pdDIClvv3x5+/an5qr0C7jx4tNh 7pcvb3+R3n5py6BxDj81xLdvP/8CdP7jL1/+10//K/d/f24ftpsgM40XXw4/VA8/fTl8Ufkpsfqv T9VmSzxrF84rLanRaorR7JsP542Xhf9qtc7qrUbh939JfwjlVr1+xl80CtnyP7h6+Xeh8fvZm4v3 gRt1+eJdtiznTfV38qvVfD19a3a7DAqk+BI8eO/XdPHVq1drf4/8Ws6XvZvp4lSkvHl6sPn/kfS+ T2nce/9/Y491ujFJd+a6RtKku5DmB8eqzNUYNyvKQhoVRcB+VNpEmBogRk1QTCOCmgFcESLOgEck A6IGf+0iRkzOEcmHEK9OCbmY3riapDM9ufW9caYzPf/F9/X2YwggsiY39snz+Xi/X6/XepZHxl0j G6Wdi/Mj4C0T308tLrulXcuLnec7O+cnOs9PuWbmZ4eOGGRxcmoQItbQ0MTSElroXXo0MTQzMTQ4 8SOqWLyPtgp7p+8MLg33QtS6cPcuUPrRDIcnR0W9T4aHwUb+BnL56DjwxxBQemNZI4QtYA+8oQxD vF7WUFWFVYk60E77CaYKFWsBhDTgNLAIViUnGxrImxJgcqnoHI1hNzFgAUYtp+UEDn9EOMZUMtLK bzUiAYmLtCJarZKpaxS1VJ1YLseZr2iShhNbBBmrQ0aQcAitrFfXyJWtBEmBHEpxlYqCjKSlaLKK 0QoIGRiJVk1TN6hqOV4pE5BEBVEpwUSUQk2W4zROKKtlispKGUlQpXWiUkG9SimWGbRoZlG1RqBs b21v16gr6urr2lXlX7XXVojFyr8SJ+uVmp5TAsFlQd3VGpMe+os4OAAAIABJREFUwENQV3eq54uT SnNbS6tmQFNXWXFZY7j8lUlj0lt7LunsVzWtn+u1l79oaf6r+dQp89X+tsviy2c+N5pMBoNRYxIb m5tMly5edZh77NYBR3PrpWaroduh91qsfXYdazJZrzZbHZ6rOrvdcabbYYqbum8A6dssXqvPZrV0 o6ZyY5PJ62AtoYcrdp3RFLfASW9Nxv0xNsBbfEFTfMxuYlmHt9uW9PrZoJEN2pBV+AKgjYBtLGm3 J31A5eFUgGVt3rA3HcqGCuFwJJDNAJEncwE+EIhkfc5ANpTLsLEIG8mHcuEEl0NrVlyWZRMJLll4 nMoEeDabCkRy2VzuMJTm8pl41pbMpXk+8C7JbwZAIPsx534wnYH/3JsA6jIM8rHRoHeFZ5MDazF7 cHSlbxMEsb7yzLEZi9lXFm4t6KMe4+bowg13MLi+cOueO+qOBncXwDl2v/FEvwl6uu6tBj2e3f5d 973vvxvfcHluj4+PzC2DbNy3l7vGF13fA54vXum8MT+yPNU5NdXpUi4uTrqY5UHXVOf8lfMzE/Mz 0sUH81M3B5euTRw1FU5Mour3odmb07ND00dLvZ8CeNwf7EVfg48gXE0/GkSbINN3ryMLmR6+8+TC 39D0n+uNd580PgEGaTxeBSReJixrxIUNJNJI1fAJiUQIoQqkIWlAi1wNkgbg8RMSaQOGNyDliOTw BrmEJCGiyQHTG65gOEPL5ZSMETC0SKEqpyiKIEXnCLIcPEdJyJUkrVYLSIomlDQpU1CYRCGmKeBt BWiKrMVplRQoe4QhVIRKqxSIlEqCPF0NnoFhciWhBqKRnRbQlIBQlgtqFAQmVVQIGAqDf4rGBbW4 tFKsUKlrwLaIai0lECuVFYJqFQEIUSqrU8rglZr62gplrfiLWrFGQZSqa5Ti+rrSdm39Z4IKsaCl tVXTCuh9tadOY7hU12psbRJrWy9fFpw8ZWpuNV/67Ct9z5mW1ibj1cs9Vo34lEbT3NzWLTAZepoq upsut/UAuBsMzWaz0Wo1GlExSYu1zdj9+cVWh85kARdB+4J2I1qu6nO03LNadHaH8YbVajKi5lmH ydvn8FntXtYU99nRpoXT7GOdultNJiBvr1OHqqhY1jnm2PT5vUZnyIuqEe0h31jQztptyTFfKJnz 8cmxZNjHBjJcgPWGArwNctFBIMTxfCiXHosEIslAOgwpKRDORrisLVAMZVj+LRsAdeQSqSxXyMA9 DxkrE8mGMpF9pzOUz4SSyHrSfCASSabTh34+mPR708mA803Ix4PpAI4E4smkn+eT+2t+3snzfAwR uzPqufVmP7YCVLLu2Az+tLkZ8wTX9B73wnpwdGHzm139LsgjClIJzgV35zzB4L2Fuei90W3P1ner 4253V1fXeHR5HI0AWkYlJlv3ppQb6q5OtXretezqXOyYBx5xdc7PKzvmJyen5udn4H7KNe+aurI4 0wm8fnN+Co1xmJmYQiUmIJmhCdR7OzQ4CFiOVn17p0EhqOv2DnjJNJqTdXca9UwN372AppygzRCA kI+EaNQPMLqwofE4PBvGJWANpAQYBMOrGuAPqkVBVVqktErIXKOrGlDSagBVgEo6cFxK0yI5RZJy oIebUgoNCJJXq9UqOPcZVIACd3IpUQ4ZSCpQwMksqibEalKqrReU39bSdCX4hExJENUYRtFKBvKW vFohU1QTwDBKRqRixPLTBFFOquulRM1tEJ+aZuoxpkZFSmoUJFFJKNXtFC1WleBUrZJRyCiZul0h q5eifUimsr5SqZYT35VXtLcSlRpFveCvaqJVVt6qqa8V69sFda119WbtPXFL/bGKuhvNPfqarzUA JJC/etqMYDptPVfNX9VdulivN5+pMWjamjTmS+aeCo2h5/LVPvMZ3VH9Yne3uf7kpVGdDm2ZG/RW g8FsNDlspjaHyWzSmwHQTVZHt6HPYjJaHEaLudlqtXU7/GyzA1UYeu1279XPY3D2e/vGWJ8v3udz sF4va2G9cPM5nE6j12exx/1ehw1+AuoJ+VidL8zbvQEIW8kxNhHsDqQD3lAImDsEnB0IQEDyJRNw F/dG2FgCTvFwOIuIPLnDBsKFAJ9LRXjwiVz4IJLJOW35SB5sgoODw+EcBKxsPgt38H3gLcvnQplA KocO/y0btyUPE2n+EHwkGQjEP2TS/Fo0+C4dSMbX0mtr8fhaMsa/gYwFX69XVl44AaPeBBeerTg2 HS9HFxz3Fl6Bx7xybAXtQftLx2bUvvrlvWgUJLIQXdidm1sYj24Ho+Oe8XHIViCSb5ZBKuMb4x7X 7XHXOFgI+MbyBtoX+X65Y9zlWv7+fBdwx/Kk0jW5ODm5+L1rftY1OzM7O+OamF2CiDUxOzgxCZqY HVqavTk4MbHUO/TjUu/U0uCj+2Anj3ovTP8/iYA6gEF6e5+gppBpNPEHiQPuUcQ63og1NgqHG85d A59AGyHCKgnaGhxGa7hVItE1kUTSMISVCIUIR0hcKJJgUgmqAG7AT5MgLilZRUvl/SNVjBonGYqu rpaKRCpaKlPRqD9Eoa6mVCRG4hTOqBkwD5FARmAkBXANj7hUSSNhDCjwdshHKopQqEWMUk0wNZWE TKvVyhDv4xhJSvHTaiVJKAhCQcPh5QKlTIDhlBIsRVUzUE22V18RQyyrkVMqVXVtvVYpVmg1Gpms VawuxQU0QcpkLWSlVqDUCjBKTFTIzIJyQesNqq7lK+tAdZ1edrG1p6XF0Np6ta0HuL2+VQ/ArdW3 Gb8Ch7kkrtNodRVthsttmv8UtDY3NWlMFaeUbcY6o10z8FDWY+3pNpt15j4AdNOC0WrQmfr6Bvos VofNfLnukq5FZ7XYb3itRou36RJEJ53Vcam7h7frTKz38cMei9/utHhjXr9jzOJl2bgPnvoH4j4I S6ZunXHM6PB5WbtvzelLdtt5W4yNB4xoR4MNBELPU7Gsn2V9mQDSiC/LZ8IJPhQOp3KhEEQmG89y tiyc4XwxGcklnTwXCHC5jI1Ngjq4g/Dfw3wxHMkk8vlwDmRRCORT4Cipx6lcLpdPpFmez7BwOJ/J BSLhdz/wAbCKD6wzluH4QCbpfx6Phdb2+SSf9idRceR+Mr7Crvn9/rU17/4KEEXQObqywnpia8HY q+h3gOGjCyue7+7Zf4IfLTwbWPWsm7fGg6Ob/Ue77LfAS7bn4Gt1dzw63vX9vNs1f3vV07U8Ak4C KWre5erYvtLZtQyvuxfnHszOj8yDe6C29fn5ifkpyFvgJx2TExPzrqHzg4PgHhOzU+dnZwdnZnt7 IWANzi6BdSwNQtoa+vHH6aX7073D/08jqJj3zjDqIrwzPIzKFT++jr4A0o8j80B75sLjOPhJmbDh hLCxCv5iw2UgFilqpWqAwFUmRFsiwyWSc1iDFEwFNU+JGkoAI+Aw7JwCx+Q0RWK0VInjclASPCeZ aoBoUABJ0CUkOp1xXKFAtSgkMIhKi878L9Q4Vk7WKHBSXaEUVAGcQ5gCLFGSGKGSAY9DJsMJsoTE caUYw7UynJJJSQEtVtcwpZhAVY+V4oRWUSqpp+qO2B5+XisQMCT+PeizWknDbxWTxwSlApWytFbf Wl7frqyoEN/Qai6Vl4rb2jEBcbq/5uxfr7a0Apy3tgqM2rqKutaKUy1mjcHcUtfSLG4WnARM0XWX t/S1fb6gaf76azjDDcZTp3SanpOfndH2mU9pdWb7RYhW9jMOh7GpR1d3yQ7csaAz2q8a7aeaui8D jH/uGLA3ey12XdDG+tecdd0Wn/kykLzf9PWazcJ221iLzZj02o1jtmYwl1DcG7ON2Wzs5aCum/c6 u33hGOtD1VMBSFI2oy6ZMI3abf6wSRfiOd4e4HyoMJG1cbxtLBuC8z0S4NhApDkNL3GsLReGszwL BJIvpEJpZySRYwFsUimWL2ZAP1w+MRYpcgE+i/ZIcqkcCCjPZ94ZI/tslttnD3PsH7kMzwPYh5P7 P/DZeNAeWzn0Ox2gnpjzXSAZTMf3nTHeGWTfrD17wwf32eD+qHvz3ib74tbos5Xu2EpwNLgZW7e+ uOXeXFjoundrvH/BPf5iE5VpbQddQQhd9zxoA3FjbtXjjm65t7q+dIFfbHW65zyu7XFUzrs1MuLu 7HQvKs93dk18u3h+cX7eveRyzc90zqMhWTOdN11gJvNHhDLVe37w/NIMeMbk0iCIZBDC1sT9wU97 l4YQdty5P30BDQNCI0inL6DZWL13UaPt8NFe+t8uXPgECaQKTvuGaw1ln5QJj2QiOo4U8okQFyJW BzRBXNJANlZJG0QSCFfXyjBpVQmYzE0pCEokokns3LcirIwEb8ExhUKIX5FLSqSgDooEfCBJsA9G icnVUkWlmFF0YLQa2FopoCtLSohqlZg+q9WqsBKRFClO04GRAgVewihBIOVoJJeAqRSopJismlIw VKX2NEaoSaySIqVMSYmoWqUkr/RrK7ESiobDCf01TCDQYpiKIUmxgETGUV8pkH1eqq2vrKlXqvWi cnG7oLy1TtCiLMFU7a0tBNWn/QIrbRYLBIL6vtMnxWf0peVtLafEzVQtGEedua3OdEZsaDPrrxq1 fZUXezRffmZqbjJ/ceyUWa/rOWN8qG8uPaW7dFH8uebhZ+JmnaG0zqG73KPrrrvc0my32Hss3W1r JmCNmNXf1GxxXO4BAViay5stVpY1Wh9bdSd1bPBrY/fawyaAdcNFu9fmGYsFjaMAKT7WkhxdCbEh nzcQ94/afZZuC9hG0vg564Mz3RZ6nLVfHgsAp8fCD0djbMJ7L8CNxTiWjdn5QDIR8GWduRw4Sj6b yjkzO0lbNgGM8YMxmStkA+nU4wJr5Die5QN7h85ApLiiQ2u8+XSaZTOZbCESyscgcx0muGwqvp/J 8c5sks8kRz3JD9k/+P3H4eRod4Z/EXSuPFwfZff90e7fQB1wGw06Y4Ah1n3P2grqNFx5tnsrthK9 teLcfGH/8rvdlRd2T3RgPeiq/cnj/s49/kz1TTQ619W163EvR+/Nd33jdq9uu1fd8xue8RGPZ3xu vsvT0fk9ApLv/4J2C5e75vsn5/9ydsvV2dm5+OBsp2tm8tOziNtdnYNoLC8akzU4tDg1MTEzMzs5 iPxjcAYAffrj80NDS0etIdMf96LOkAuP7l8AhQx/jAYsojKs6xeOhsg9QcXuT+4+AQdpBDo/MQwx C1kGJikrO35CVHYcvASxByBISVWV5FyDRCTskGBDkg7QDLgKfEB3SPAqKSYkMYlcJMJpKSmicZEc cOWcQlgiomm5WkkoIVOppGotoagmDYxAqfi2BCuXy+tlUkoLLM9gVQQuV6gqqyhKWiklq8+Bpr6V lWAMUQHWQ1WqSEIuVWgF36okBhFBaTtKMFItV8tqGQBxRgSf/qXVahVTrhRVVBK0gjlZin2rLsHq a5U1MkpZX48Dnmu0hKbytIFS1vWfPlZOmOvb2y/LNHUVrZWlYkqgNX9VL2ita+kRX9J/USEQ9AGP 9DT16M0trT1mQZv5r336v1rrNX2XruoG6kovtujNem034Hi35pJA13LGoDddbbYbe0wQolovV9QP XC1tRtW7FrvJ4ThjcZgG9I4+o7/P7mAfdp/qdqxZ1hw2vxXIw3iJNdr70Lrsis3rDY75f/B0O8LG i2hgmx+1dlh0Pm/yodfndz70AY48jH7tTAKkePmwjx/z2YMZmzeXyLIBjgdbyYZith/iKWOzLxDJ hblMNuFlQxCVkuFc4HkiAI7wgy0S2gkVOW4vm+ESbCDPJ4oFSFQHXIHL5HIRfv/hU7szkcmHi/l8 ohBI5rhUKpLKZZ5nM9nU4Q+xdC4bykWyh8nIH5DUIvvxeDYZy2RQvIonQRWHvsujyf0A4Aj/Jhlk 1/b9z2L+lZcDsRg7sPCNJ7jueLnuXHll31ywuzc3o3MvF15EXwSDLzyj69tu93fPxs+6AUDmdqPB 1VXX+Gq0f+Pe3PLI3LLH068863KPbN8ed4+MzLu3Zzrdrq6O8eV5QPLl5SnXCMjkyoOZT6/MT01M wouz0sH52ZnJiZnJqcnFpZmZB72fojlyE0MQt5ZQhckS2gQ5GiQHvD58p/fuBeH9Cx/39t4dbgBw f9J4ffrukzt3nwxfv9N4ARgExNAAGgEOEZYdbxgGtzh+7Rr6rrFBeLxMck4ItD5BAoHAUyEmJSXS KtG3HVVVirlztBSiFyZlcAkDCqHhsxswHcP6O/ArNI1L8ZIqrfYKwTAKKcmUfltzFifUlEpZMdJf Q4j6+xUUA+EKl6twVXU5oyQgZFHV6hKiT07SBE2K8BKJXgEOBOAAiUmrOIuL6pXVygptv6K2sr9f ppRi5FlSXYlXV5JKZQUmqf9OXV8i7xOTRAXEOuwY1S+jlSq1VkApJQbZyfL6+rr2urr+vvaLNQN9 X7VWlFcIKrT1hLm1orVFXFrf1qJpPaYZaKq40SJuaSkvbR/oqetp0xgut37xVd9XFy9qzT16o3lg wNxteDhgNp059fVnRqvukqGn2WRv+VJjslt1gr6Ho806XbNdJ7hoeGg3OixW66jDaBiwtzSjBhCb 9eFDh3PgcdjibW6BH/vspridDfC6r73esbi95WHYaWfZ4JjtsjH0eJ9NJkM+m1cXehgDOAfA4EOP UwE29Tyc8ensrC0ZYr1w4zI2ewiY22l6XmQjgQDLsUYWTu5MIpFKRhLwNM0md7KFBJd6nuLyz/+e OsiyfIQP7fCFXCCb4Fh+J1/YcSb/vhPg8pnAARvMPE+95RJ/PgYj4VPhdDoZyueyf6SeH2ayz5/n siAQNh3PxuCWSaaDjmwk/settce/Ofl0LMZ7bjkewjverPh/isXsfms0urISW4+xzwZWNh3/PfAy FnSP3hvVx+45dkdf2KPfjO9uzgU7Nwai9zzRrainq3P8WfDW9urqnNtzb7EfYPz2dnRka7F/btw1 0t+/PO7qdHUBe8x0gD7mu84vLrsmXb0j305NuVxTrpm/nF984Jqan1icWJrpvD85NDiN7GRpdnIS BPLgx6XZow31+4PTQ6haERzk0TTQ+v37d+8eFbx/fL3hDvhH43Dj9bvXnwz/7aOqKgxthZQNA2M0 lB3HGstEkuNV1ySIyskqSF6gjYYGDKgcrAQtdknk56qARUAYEpGIkZ6TCHGGxuDTXMpgQilOzp3D OrRqCidpGYN9jI0waGVXjV2hceYKRhLqb7US7DRdTguq1dVqeY0UQhNRpVDiKhGGK3FRvxz/VitD CK+gSj6W1DCgDUoNVlHOkKUkuImWxNQkThPV1R3VshoBJpKRV0YqylFPI1Wq7hed7P9WfZEUVCpE JR+fRq3sgko1RhGESlBeq9LOacrLvyKAS9plNTKNFvJWTW2l5ozYXFla2XJSMyAWDxjMTWh3vfLY Rxp986W2y21fnWwWy3QVFV+bDf2GU2e0l8983abRGzRW/WcVDs3lNmv3VUvLyTbjZ30DTeaHfQ5j t9FgNR4r7bPqdA6d96smu8dhazHaLX6/9RuzxahzgmzWvH5rt9FnGbX4dBaf8Z7XrnsYHvU99idt dqB0+8nPwj52bIX1mZ28zssaAczDYeuo12sDIM/GQ9mwL8iGvLZQlvUl7MYsa9kLO8OPcxxQdTjr PLWQSkSySW7HxnNsKAI+E07tJZ0hbiwTKYRyxZ2Ubz9b5CKpA76YYPmDsfjzUPrx42IeJJJK2L5Z SSXeJgJ5CGYcH4qk+fxhKsU7P0T4d4EP8Q+hXHjFmQwBmWfYP5OjsYxz7fGK87/98bRzfyXON3Wu P+P3vU5+5VYsFlzZHA3G1vqeeaLrm5vBFysv11+uv0LLvdHgetTzMgjm4p575rn3bH03ei+6+9Jz /i8jG9Gtcff2eFfUvbztcrm3v90Y6ZpZhWfLk4sjixu3u6YWF6fmb7vmx2fOz7s6Rx5MzT6YXJ6a Qi9/9NHk4tTUzNT80PmpwdkpAI/ZyR/RMCxgkEdDs/eH7g/1ohmkj4ZQt+31wd679+9fGL5/Zxot 8U5f+OSTO9Oo3P3J9esXPr57/aPG4yhcwQ3onKxqbCwruyNBNFE1jDbPJcJPQBlVkirRHaFEKKxC vbnwOlbVcLTwK7+GKIOuqqJJKSbtYEA3+DmFlDgtUpE00yGvxsvKaYpRU98SuAITUDSjkp4VVZ4l 0OBSpVx7Dr+CitkpihY1VGsZgQCnFTXSympGLqAqFepqrIQkKJVMpKmiZaARurISZKbEKQGJmqO0 zFm6lkKHE2JcVsNcEeAiRQ19+gvUj6tWyOpLMIFSqW5X6cspdSlFievrqZPqG+V1FYJyolWrV10R n2mpr22pq6us0OjrIW/J9Bple3tPe5NRo9G3HiPEV+GJyVDR3n6qucWo1bV8rjF+ZqwTC1rM1r5m pdGoa2uyG3UtLVZrm7FZrO8zGA0mh1kH0GG1HzMaWQc8sXZb25tZHWtljUavzcgGmy/Z0BY5nPNj rH0sZtE5/D40Yt3nt475vD4Hqh8J2S4iGI8nw3BW220BNuAL2NgsKmC32wO+cC4GXsHxAS7A2ZPh EGocDIezyUQiFOCy4VyO7Y5AkModpJL8UzaTzyQKXMRX4DmAcDaxs5eLRH7lDgLZPJfgd1IFUEEy lcoWdhI5DhA+txNzvs3nc8XE40zkcD/DgRdl0r4sy/2WZvlsDogk8jbzB4DKu2QsdJjk0Wg5f3ot +Sa5z/vi8eSt6D7Pr60hC3kVjcUQkERX9j2xTc+tYOxV32501PlTLBoLbgY96+vbox63vX8uijbV o5vauYVgKUjCs7u7OufyjLuibs+4Z8u1ugV2Ac6xPbIx3wX4Dt+65+drUSPuTOdix6RrcXFe6kLL va6POjtnXItgIYMTVwanlqZmgT5mOwenBiFcDU1MTE+j3pDppeklMJJH09O9d+/ceYQG9KJrIQwP X/gE5NE7fBcs5MnRPkhZ2V1MWIY3ogqTqqqqEyAR4JJh5BaQqOAe0AQHn2mUgF6qMKGEBB6RNlTh QlLCdEgbcBJ0IT+BCXGpvPocsDZ83ZRW0yR9haakAOo0yAKgu0MpqgZfqZTSanWlgCIwpbwD7AXV 4zL/gcPb5DJFO1V+thTDaKVMSn6PmtoFOE7TKjmDkx2VTD2F0yqCkKkZmhKAvkBLkL3UuFyNweHq 2zUKgjyLl+Lfq2S1NFVL1VEEXk5R6urKsxWKunqZslzcWlGnbVcRdYSgpV2vqaSo1naBub1cIGip 0eg1Z2oFF8tPNZu1TTeaWlp6LtUJxC3NGrPsokzfg64F0mP+QmfQ93Trzlwya/oMzajYqg71Gja1 Gax9jubuy02fddusDqPuB53NojOeMdpMXoupW29lrRb71ysWu9fvXbCxLTav1Y82BH0OexwMx+mN x/0+ndMYbLYF4l7QzdiYN2YLsmNeH7pYgS8AlGGHv75QdowPBDlUn4uWeL3enCNmH/PlcmHQjs1m S3NhjuciHJcHIXBcIhQK8OHCQS4RCOxkueLTApfn2EKiCGjBJYqZxFMvvC33NJU6iEQiPP+2UMxz 3Nv8QRZp723o34VIIFxI5LLpTCH5Ry6XjeQzsXz88BA13+ZiWb895uTjH/wfftvf/8npTCfjr1+n X/O/8bGg8/X+2psVsA5+BZUwrrzYB2APxoJRx8qrtWBwc2El+vLld/fcaKDDy9Et9y33vc3dhSh8 bQej976DqLW76nGpNjyrq8uu8XG3Z2N82b3lmveMb4zMz7vGF+HW2Tk1P9kxstgFdA5PwT1caK9w amoQotbExNE1ECBfnZ+ZWZpBgxumegeHZifQahYQCBoZ1zt4Z+j+IzTh/cLdaTT65yhnXUBjG548 uXC9ER4/akBFJcKyowL3ssYTIIzGsgYUpVAvrqQKpNGAYY0NEvyEECMbaAmGak4YCTkkAmk0SM5J aVIuwc51oGJeiVQK53KDiKJJhqm6IpXLlQwDIjnLVMI9QRGqapKuZhQyhlIetVjJFfWESCG4olWg LRFKxNwGKVQqCXgTCSpRMajhijyrUlEE+IRUrSqHf0BRraQqq0kpRVcr6ulKBUloR9QCjBQxKjic VikJkZoha1UKdWV9vViMLucjFtFKpbJdJTh9W6W53XKjFYRSp6zRXqXatYL6fo2ZIJX1arOmWnDD 3HKpXtsqvmHWmJEo6qk6TU9rfVOP8aqh9UyN3mzV6HpM7Zd0o1cNBlOzXn/ZNGA1VV42ms1WQ5vY brHrNFYwFdTwYbHY7N0mq4NtQ0PR43Z40er38mNWk51nwTW8prhV5wv7vT0/OCzeuG/BGIAPYzSW hI/7fEetsU5vNuA1jaGtckhW8VDYF0iGHOAbvnAoGcj50uFUMYkml2RzIZ7NZjkulAhE0M54IpQH t0js5LMBLsHt5CJcuJAKF/IgCy6Rz6XgB099b1Opp1k+ki3kirlAoHBwkM8VMr8epHKFwk7+IBPJ 5fLZTD6bz+X4ZO7Po1LGEA9+lDsM/ZbN8ZnD8Afenk4m46GknU/+xv+2FoiBSsBJkmk+6Ex6+YUg z8fWXjoXXq08W38ZW1kI/hSzr6+vBF+uR+3wisc9umqee7nq9iwER8cXgp7o7sLui91g1OO+txvc 9oCVRDduuMZHxjdWPdHVZffy8vzI6rZr/PbU9oORxStT88sTHYvznfPLLtfE4kyXC1X1ToCrDLom 5mduohmLSCizsz/OTk3N3lxaGnw0MTQ0fb+qF01vQMtXDWAfd9HFEI6mmjyCe/R4NN79b6AUNN19 uGr4eGMDahs8/vFx7JqkAWsAtaAik4YTOBgIPoQh4jgnBangVcOQuSS0pEEqJWkAdMkVUYekgZQz zDmRsEQo13ZQjIghhXIFTVMiiiQJphq0QCu0KpokRBQ4jJRhVGQ1fHzj5SpRrUIrJUWKarVChJXg iv6vKuVwAKaoIWiGUYLBgKhEFFGjldNX0OFnMYaBpAXBC/PYAAAgAElEQVSHS0uJeqpWW0OQpxXV CgUBeUxrkFXKK9Egu3ZIdirlFYJS19M3lIxeo6olKLmy/GS57ItWtbK9pUV5sq79Rp1BK1a2a2pQ CfwxcX+fuaemvV0gtmqaWtvbjBXgHz1neppr+vp13d2tNc0Xv6nQmE09PXq7veWy2aTTDRi+Nuqt Bqv1kuCUfWDA4tBbTN+Z/ZYfTCaLvTsG6tBZ7NaHfazdZjLYu0E4Fq/JAp+q6MoFbOChz+noi/vC Pvj13sdhb9Lns3Rbw17W6/WxNrT5HUiO+VOoJMQLHuK0+DhfIJ7guBibyEZCKR/LhUO5pwnbqC30 PJVNJApeZy4FzpFNRCL5xE4me5BM7e38mgHdRNLpBJz3XHHn4CDC7RR+fbqXzSRSxWKqwDrTqedP C7ncTgaIPp8vFA4yb/PwHVofflx4+5YLZdPpdOjPROG3XCH/xz784O3hYSAdz8Vzh4HNUfbw8QcQ dNLuPIyz6ZUk79xH07NW+AW/f2X/qOBkNLrCe2POdTCXKPjJT32vNkcXXr2EhPVN12b/s4WF3d1d 93L/AlrD2nZHtxeCW+Oe1bm57a2t5dtRl8u1Or7tWV71eNxd24vurbkO13zHyPjIbdf588sPHiwr IWGdn+kAMJlddg26ZhZdQCETk5Ouzqmh2aXzkLHgAZUxojKTpaUfH6GFLOQeFy48un9/sGH4aGg1 2kafRjUmaKPwwpPhJ3+7+1Hj8MdlVcKy40LhcSFI4ngjGEdjY4PoxJF9NGKozreqariq8XjVOUlD AwB9FapllGLCKlIqxSWSEsk5CY5JaUykkFZhV6QSkrx5TksSCoaBz/MrJE1WSwlGWHLuW6aWLMFo MY7jtSoclzJqRqASCatlUvqsvAKTodkLEMoI+sqIlhRpK1XMlVqSoAUKkmJKMIVGTOElGEHh+FmA dhxMhCKqJZhCLaXxegJv11IkXiGS1lZc0dSQKq0KfjtFUgJqRKBkSnCthqkrP1Zep4Q4pVKXEjda 2+sqzUS5vk35WUX7dxUGTT1R0dJaB199mgqtoc38RVPLZz2fGfWXe+r/Iu4z9OgEpZeNV09912Su +fJruwYNwbp4pk9jvHTV8fXVPoMd8pQZzSx5qG/uW7NYjXad0dHssOocPV+aB3wm9vMzwTFT96g9 6ei28WjSm6/bFLawTkty1PIwuRJkvZYx1uZLeVkwh4QtPRbz2nxx1qe7ZX3sCwS6jQGOtbF8iHWC cBKBbMjpS6EBJVlbKJXwshnOx2X48F6S2wsVCgEuE+AixQSXsP0Qfg6KCrL5gwAfyRfHIvlCscDt JPbDqQMukjvgn+4l8vBiNp9/m9rLJPZ2IFj9ClHsbQp4xLkffnyQz2ymuTyfTudz++l8NpfN5ECI uWRgP/QuljtMvt6PJPl3fPrh4X7yMJl8s5/e52Ov4zF+xT36zM+/NrpHX78e3YSgdW8TeCQWXPfc WlsPBqMrm55X6+Aawd3g5mb02dythfXdBQ+q0HJvz20FPYPK/o1otKtzPuoBiWwvdrk926vu5RFX 14Ptedf89tTMg/H5KZdbOe9yzT9YnJqcXIaY5eqESHVtaubmp0MPJqZcvZ92Ti0Bd8ze7AVenx0c Grp7fuLRYO+jpd6G+0cjFYenwT/uD9+9Mzw9fOGo4Xb6yYUn1z9pvAMOUnbi+CeNDRho4vj1a0fL VGjZV3inAWlDIoGHBlTX2yE5XiaRIAYBewGLIcFeSMk5khSVlUkYBrQixPUdDJq0KCSkJLAIRUvg 5MUoCXzko8r0s2p1NYWubgiILVHSoBSVgmZOl2GMWgWUIqT6FfDIYBhTQSgqSAhKNbcJnBGclVOK frqElHWoKbT/TgloWkxiENIUdLXoeKlKXS9QKYXV/TVMrYrCcBUlqqmlK4nT2nZCoCYFX4m1/eUl THvNbYoWUHVKglLWCwR19dqai1rmI6rN3KNsryzVD+hbm9pbTla01X2lb6rsqdQYNMomc+0lfU9f n6C0zaDXNDddNhqNda3GNvFlnbnP1G0VH+uxGExGS/1/DTy02u0G4+dGi85g/cFuarP6Dc02b7fJ 53jo/+y/vH0+r01nRxcINLEOo20MWMTp7z5lAcfgAT4ep0JjY77YqAX8AqQTcPjDPmfA50xmfc9D l5yQn9A4uGQgAGTgtfNcIgX5qrs7u7PD+RL2yPMUKqFibVw+GT6IJDhf6mkifZAdA9j4eyIYKRaL ibcZ7uCAS3KF/Fj+oJjKF3KjsZ1ikSvssAd/3/s3mEYgXTjIpv71tpAPAa9HCslI7n3qeTLIFQ+L 2beRTDafSWayGZbL5w7fhuK3Ytncn5lsdjP7/DD5Lpt0OrPpN/50LMlbc3F2PwnMkfb/d9ANrP4m 5twEUn8Ri/HB0f3Xa+ubr+xnt1fWX26+DLpfDbx6sbmw6d5a2FxdB/7wbKwv3IvuuqMLwf5+V+f2 xsZq1O3e8mzdW0Yq2dr+dtW10fXpvdury/PjM50bD0bc84uuzq5lF0KQeXpxcnFpahEFrAeTf+md WQT26FyaGpoahLvzg1NDII37n36M5ptMD93t/fH+EKp7v9C7BAnr7nRv4yO0hIU2CXvvPPnkY3CS j4YlwuMflzUCoJd9cmQekgZU2Yu20Yc/Pl4lAfsoAxe5JhECn58jAdEBS0SMhEA6YRjRtxKhkCQb pB1Y2TVU3KtgMJzGcCktpctKOuS4XISDKGrUANuybxkVRUulFECIioSzXaGW6UVYqVQqqFRg2DmC EDA14DoVQlpJKMmPTtQwpILASbJSC68SihpEJFKK0srk6HCponpEQ2BnRQStVhw78R/S7wXVWlEp AaJEreofkVqRtJ0up4n/0CsFVKVG21pfx4hbWvTtrUAWApWm3WAgSi+qxXXammMiRX3ddxp95alL dSdbjC2tgk9VfWK14aK4rlnT19rU3danN5mNV6/qTH0OU1uz8RuN1THQd+Zit6lH16c9+R9as260 z2rsthvPsCYb+3mp3t9s6evW6ex+v92OLqPp87IOx5jP7/M5WPaHeNz3MG4cZb2sJez4xmpw8GAc dlvA+UMmEAjc+jwUtsVDqDEknOMDY6HHiQQHcYsrhrOJQCbAhnO5vZDdmfEFsine6PdxHBgHH8jv gzyy3OhoKhwohtIB8IMiEDukLMhViYP//SUFkjqAF54+fV5g08AcO3u87TB78GthrxDJH6TzhfwB t8n+ksuARjKZwvOdSD4PKQv8JZv/V6oYgne9SxZzqVQSkDwZ+XC4aX/mzaTjh8n9dGT0XSb92/43 wcMVRzzmjMVQde/+ih+YhH8d4/lnr1ZWfoqNLqytPHsWvBWNBYPr61+qNsBJ1teDW5ub3wRR1cl5 db9nfM7tvre8MeeBrNW/sToe3fZ4tucgZAGmj29sz218P4UWsUYW/yJaBGIf6XBNuac63fPz8+c/ lT7onFgEOUyh6t6liUl00duhqan5H2dm0eA44PYfZz/tBSRfut/w8YkT09PT6CIh00dXLJz++JPh OxdQL8iFv50YvnABbOQjSFLgGWXHG+8IP/nkE5SwqtAcOZCKsOrE8Ua0sAv0jmaeNB5HRe/SKolE 2DDBXKsiycYqXDJyjgGsENIdVWWgqisSqRpgQURLcVotKhGoCLkcgtEVgUiAlYhkhFymlFfiIkWH gqYIjJCc09fI8Ss4xtTgZSUlpVJKrlATFANBilJISwi5SAaH41cIRoAJVeekajUlU2FyhUxRy9Cl BK3Qa6vx2lJcpThbVnIMpyh1u5oQy2spUlkjweQqpl1dekxQS1UKsNLb6rqa2y3auvJ2jbZG3AJi FPf362WCy+WEVnP22LHSivoWjaatzihraaHM+oqTba1mfdvJ8jPdrVfPnKwwmNsMGjAJscFq0BvN n7X89auBvj7z5ebPjVbHlye//NyosfUBcjhMNnvQ2nfm/1ht1jXTN2eCNgdrvKiLW8A0vCFbW8jv twS8RofJ8vhhyOG0NbNh73/dugVSSaJxhz4vmvQW6raFAqEQ3x0cAyBnu7mcNwHSCLHecDGc5Dhb xgvMUfSO8TYulRkdHWXBQZ4WAdE54ItU6AduJ18sZpx8hDvIR5yFFJhGobgTSPxPKnXwc54Hq3i+ 9zTJRfjC3tvNfTaSKBRTT/MHOZDHv1IhZ3bnoFiMxCJv8//i0rFcMR8uHhQLfCgVPnybDQBeHD5O fWDfsrE/w/u3Njf3k5kPH7J8Zi2d2f/NvxBNJn/7kAxGnfuvf9uPepKvVtbgxo+uxNde7b8Obu6+ ePZs7WXUeS+6su7u+sYdfQFKWfC82N0MRnfn7rl2gy/mgq6uLfCTrU73xmpwY3V7Izq/sbFxe2v7 +/nlxQdzG8tT7s75kfHO8+c7XYDtk8uu5QmXa2px8vzgomt+cub8+ampGdfgp4OTszPXZmcmlgYn JiaG0DrW8KMff5xt6B28O31/ECRwAQLWHTTWBA1ZHB7++MIw3F84aie8e/2Tu9c/+gTMA2tEpVgN 90+ALCSomrfxBFrIwidQUwio4UQZ3tBwjSwBrQhFQOQNx0skIqxBdLTTXiWSklhJlVTeIZVIaIWI VshJRsqQtcy3clpK0XIFiTO0UivF5XKMVDA0A6e8vJqk5WexshKRRMZQGEaoFN+KGGmlVkRpq0kZ Bfyg1sq/VwLcK8oFKrpeS+DVDGCOSMqcLSHVcpyCw4/jIomCgsOVam0NHA4Yw+iVRDulqlXWaFTf 14lrtYryCjXVriXodgaNaGRaS4+JzDJBfWtt6Uci0RcaZV2pwKg1aFtlSr2+vqevpV5j7KnrMfRd bTF3d/fVXDSamw0Gcb2+uVbT39xjPnmyxtre5DA3nfyoTYb6BGsvOawDBpPG6LeavA+dJiuLJr35 TazXZgrrjRYL6+8zOuL25nhfzOL4r0vekMMWZ3+4fNJi8sXHbN02X+ihz2sNPEwEcuExXzaZDGQf hgMBXwTxSBY+7kM2tIYVDgWygf9jD+UCgVxgv7vFlwwVuDFnJhFOhRLZ7F6CS6Xe5g4KHLjC03z2 ANWZvN3JgzXwO8VI8ped/A7n9BafZrinbyOj9kL2nzsHEf6g+MveTiGxs1d4v1f89enBTv79P5// +x+F97+mUhmuCL8rGygW0tnUn9lE2vlbMRfJ597t33Ikk+E/uP0Y9yF8+IcvEzrMcI8zv32IJNOZ D4fJdDLN+uPB9Fp6zQ8+shJdib92rETd4B2bDsfmrc6e3QXrC6fbE1tZW3+xG1x/FYw9Az/Z3I3+ tN7/YvPFZrR/1w3fvZxzezY8rtW5rfHtLzs9G+Pu1WVX56eqicURtxuUsbrRsbzo2uiYX3zgmkde svwATTxxzTyYHZyZd01ODM5MdII0poaGPu1F6Wp2afrCxzcbHt0fnL4w/Wj2/qOGBjCQ6aH7kLCQ gxwtbN29e+cuWulFm+l3P/rk+PHjwuGGskYIV2VlJ442QaqOlzUOV2FlJwDNsaGqc9fQ4BPJNQhV QkyCrocrgZeFJSCNExDFqqTMBCYl6W8BvBuqTpRI5EIczl8aU8kxTFIv71fcZEhsBDyDxgmVCKO1 kjKBElhDzaAdSSkDLiGnGS1JM6QELznHCAWkXE1XySrhPSpFv5yU45heQTA0TqkpTKrFyyjEGmrg ldKzIpWCIavpam05RZESrERBYbRArRbQ7ZXYWXW9tq+SlpVLDAplJSFQ3RZjrfqzJS1KjGjXqrGT glpZj0ZFtYv1morWOtHpkycNdaUtdZq2y/V64BGNuW+gtcVc+x8DZhBNk9nUIrD0nzxpaj7ZbDGY T55p+tph6evpMen6DC0O3VdXP6/zN4vtJqulGQRxWRe3Pnxoc1iarA+9AYvd5vPpmkP+/2xNovnr cUuT0xnzxUMOr3csZTX5WJOp2RF2BseSIc4GXmEM5MAkxpJJYzgFqYkNhBIxNhW6xR/EbFwuFBhN s1xoB5yFy+4lk4mA1+vMPrVFMokiFygW0ywYyt9T3A7H7u39o5DNgAGk83uJzfx7lt95WsywbyOJ 338pIgk85xL/5nyZ/eIOm/+1+PRX7mnxXeTfxdTfi29zb/m91K8JLpItZveze7+N5vMxvpALsfvp dDZ7mOX/jHxI8ck/+JXYpj8z+o7/kGVfh5KbzrU/Dh+/2V/7yX4Yf/1bzPlm7XWU90e/4WP3gt5X K7ei0dGXK68WNhderL/yLARR70f/5nebnpcL0e2Xwe+35nb7n23f23Wp+nej2/e2Vne3unbnOju3 3Z3u1RFPJwL27Y35+eX5jcmZRTc929m5MTUIElnunJ+cGpxaXHzwYGpm9vzsgxnXzGAngPn0xMSn vTODvTdnZ2+iJpChodnpm4PT9xt6H/UKhRfuogtNQeq6gK5PCA5y5w6w+idorsn1j8A1Gk40orWr smHQRiMI5Hjj8WEwjobjZVUY8hc0VQ4CVAMYCHwHn/snJjCMxoQNIpHomlR0TVQloUXSBgaCFomd ReNOGBEtp4Q4Q4BCaFElTstLMCUjPyskaQIvkSrwKwyOE7JzMoVcrVBJVJRKeRa1TF05eQU7i2P/ QRGgBKKaQixTXYkpq8vwOtXpsxhJVOAlpxUYxZSSlEKtUMhlcHg96IaUY+VKgYA+RuKYghLfJjCR +jO8XEko6vAW1UdEfWv9WZwQK0ux9prSunpBRb22XVNTo9XXM20t5rovqkvFLRcvX8bqiAp9i1Ej FvSYWwTiq5WG5gpT/bFLZo1OUNFiNApOWTX/udB2pltvMPQZDNY+c5vDYTE62i7a7cbR0VO6r9t8 NguwiNViP2N3mPw2na/nM9Ybt10KAqNf0oX0PyRN9qMtjbjf7w9YuKTP5rN5AoF91tnN66wQrRJH XVFBb8CXA13ornLZ0JidhaxlHHvqTScCfCQczqV2wuFiMnRQSLBF3nbARSJpNsKGC/liwcYVExE+ m8/9Hjko2vlC4elbljv4B2c7+CXJ/Z7h8qmnqV+e/nOvmC2+/73APU0Hfv6V+0c6w6VThX89BSEV C5HAQb74e6SQc74p/PvfET6T//8itj9TfL6QzmQPi4eHudxhIZngcsl0fJPPpNPpzfRrpz+TiQc2 38T5zdhKLJ4JZrzuhd+SXshg+69Hb7xZi/Irm5tgGmtrK6/WVoIrsZXgiwX35k+bm5uuzei99eCL lx737oLHfS+4PRd17453LkPucrnvRaNdXburrm2Py726sfrt6urIBiD68jhI5Gjyieu8q/P7Dtfy 4lTn8kTX4BXXEHp289Oh+Ympo9kNvecnhs7PoCtNzc5OzM7evz/46NHSIySJo/nVF3ovPHmELk94 d7gXbRM2An88QZeDfoL6QVCdCdjIiYYTwuOoU0qCnygTnihrPGoCEYJeyvDhMomk7LiwQ4Sh+pPG MlxSVdXQgNHgGFgVzVQBhMhFcohScvmI4pwIE0nwKvjEp6ibmLAEV+HYiLykhOrvOHnkARikIaqc JlWMgIa3yUgcxxXy2+iDX6GtUYjwahqnGaaWoUgMKxHU47hWVIKp+6vPljNqNNiEAbMQ0PUMLSAp laKUxElt9W0BIZPd1iu0RPntcpJQMRUqJVmKlShluMAgKinV9rUKLsraK0rLb9ffUF6klO31SkLZ 0q49WSFgDFot1arR6Ps0hjNi7XeftZhbIVl9frK2VKcVyPq++MupvoG2y90aTdPFOpPZbjQ26ww6 Xb3OpDc0NTdp+voszXqfte9hX5/RbGg2sl4UsJqbbjV5LbesYeOpHx4+ZHVs3OfsZrPeo2bxEGux g1n4dLEf/Dm/zxYKhcKP/aF9kAuIAnA8EPshaEskf8iF7V8HnqciPJfLpmPJUDYPkJ7Y4ZIWrrDj 43k2VUxBCio+3dtL5SI72QB3sMMVChy/bwv832R6r8ja3v/9l7dc4WkhEins/PwzQPrvxXw2ebDz zzzHZfb+mTrI//PpL3t7e4W3xXwm/3PuHzvvuXSazRczkec5J7sDVoK22NPpQiGfz7zN/DuRCWTy hUOeT/OpXO5dJpfLpQ7Dmdcf0iz/RzKS/G3fuRnl14Kxw5Vbo/H/fuPcf7MW29x8s/I65vzppzex WPBFbGU9uh0NPltf31xYX19Hj56X0Whw4QWQ+pbL3RXcdW/33+h09/dvu6NgIa4tYPWtLffW6vLy 9+7l8dtTLtfixsi4a/H25MhGRwf4x9SUC2LWPKp4Pz8/e35icvDTpckH4CgTs4Pnl2aHpgDSl2YH G1Cz1KPe6d6jXfRHjx7dv3/nERragIaPTk/fvXD94+vTf7sOPPLJ9TvDH5VdLwM5IIkAgKByE+EJ FLjQc+BykIFEArhedkJ+rex4FZoGJDknl0KswoUQuJhrZ7GbN5lrNF0ikQKKYFUkwYhEZ2kawJ0h SDkjUjANUqWQ0XaAhhRyaW2HVis/y6DRDiSukF0R1NYq1Mz3JYwK7AYnCLmqGgCdIDG8mpDKGDSW UU6BOE6XYGAWFDWi1VbiKhWkLaQKspao1VYra4+pVEqiFA6vVqmpcmWtABeoKaWiTq0Vl6vFuLb/ 9DGyRtuqrDPoDZW17a0UUVdeaVBfFNc1GdpbxOVtbUaxoOLSDc1VbUuFsfs7Qb25qUbfA9BR4Wiq 6BuoLr2EOmnNA9Y+Y73e1G3UXTb1oSZz+4DD1P01cIaxqcdkW2OtTh1rM15yeG1WnyU+4LT7dOaH D9s+t4TjvjHfQ3+YdcSTNpYdjT/kbYGIL+wL2FFvB6sb88LJH0I+wdp8HBB6Nhze9yZsvucp1phI hbJcaC8VjiR3uDF4SzEViXDcTipxYOMKifxRu9POTiGS/QfH88UD7ulOYa8YKRTSO89TPPt/957+ fPDL871/cjvws/cc98svv3I//+OX1M7/8ju///w+kzn4V/HfxfdvC//7ayBTfH+Q+jdASWTnfbr4 vLjPF1M7B/m9x3uFzE6Oe5dPJ1O5t5m3b1O57Ftn9s98JsZnMh+SHzKvuXfpGJ/lkx+Sa4eBn3zv gv6Hb269iMfXeN7/YYAPJt/sb74eXXi2Apay/wxi2S2QzOY9BOmx9WA0thl1by9EF16+WOiPbi1E QRzgIXNzELP65+bAW1bd7mjX+Nyye2treW582eUaX95ydbm23JPLky7Ujt45vwz5CvWody4u3Xww CR4yOTE7hYoVl0Ahg0uDvbM/gkoGQRqDvb1DaGjc9DQYCUKP3guoaQrtpA9f+Nv09bt3hgHS7340 jJZ2hcJh7EgjYBeNqOQEfGIYLfo2iIbRlT0byoarJBK0P3I0skEqFEqkWJWkBLsmkkglNKowAbjH SIhX6FK4JNMhl+KoCEUhZYC7KUwkl0lLSCkq7JWeVmMCtQpXMkJaUV0pV1LMaYVciUN+wnCBUoLR tTIFZCYlIZApvuvQSAHiT1cqiBK6glYKRJRaJaTQCEXwqRo16EFZKR8BUZXSNBxeSZYLKEWNGhRQ S2kV32n1KKyp280kpqTEN2i1UluPtWjrL/YwpTJNe1v7jdYerab9hkBwgzhJXG4TfNdtNOjNLTd0 3a1WjbHPcMl8qUKvN5wS6C716L429Rh6ak2GHqOl+nOD1WF1AGJY+6y6Sx7bpTNGu+VrHeJzr43l bZYB79hDv80XNPv8vhbjmG0sYPN5/azRF3LwIZ3TH/KFfJzP5/cnxuy2QNDOB3zOsUAiHM6OcVwg m/Jl90JcgvUmwiEjzwU4LplIFMfGdnKBg1xsLFUsFBMHhR14DIxF8izPHWRZ7tdi6ukB9/MBV9w7 2Hm+UyhEck9/KdjzB/mfD97/XPwfPv8/xczvRT6x9/T3p4Wff38Kj1wgfwAR6mfglH+k9lI/53/+ V/5/9g6ePv/z3wd8DuzJmf9X/n3+z38hRinmMoXEfvaoH/fgz1zqQ559HeGd6XdZfj+Syfk/RPg/ 0qCGd/5Dfi0dXFv7ELvFv37N76/wa288/NrKT28WoiuQsFZiPIpZL6LRn6L3NjcXtqKbL16tvwwG f9oM9r/c7F+PgkBebrx0Q/bybG6tRje2u7Y3PFur810jG+Or48vbiyMj46CJralO1/z2kss9P9Kx 6AL/mH+w7HowOTXfeXNxcrH3POQrdM2piZu9s0gk072z94eGhpaGUKXJ9N3ewQsXpsE8ensH76B9 dNDLnSfTd4YhW/3tyXDjJ0ctt2WgjLKyYbQkJSxD1z8AaVSdQEOAhIg5joNVoK0RoQQVbTXggCDM CZycqGoQoYnXN4dITIgPMecEcIbjDTelHVJaek4ETkLAKQuuImIIQoiTpAK4BSekAiGhQLvoFCkj 8HKapkBpNKWuoXEpRZICuQwEo6BoqpoiaNR2K6+kqBIBSSswnEZlvyWn23GGkUkJWQUORKMkMLJW qaipxSlKQNYqZEqlSksRIBwxKbhRjssqldSxCoJRYIIKoq5OAAhS3tpao6yvActQKsE9xHU9Bu3F itaWy+Kv9RCtagzdl9rMRmNFi+6UWK8zXjrZ3WTWnuyu69bp6gRW/RmH3mLUWJpbrursJmOdzm7p sxqNFptOZ/NbWYt1zWazesdYyFkttriF17WwtrijmQWIYHXGsNUGuoCwZQPBBAKsPcCFHmZtqM11 jAtnOS4cgld8HMdynC2ZO+BsLMc/5W0cz3FczJLyJRNPC4FiIgCC4fI8D/C9dxDIF0BAO78UDnZS O9xB8eDgIPD+gC8U3//McnluD4CCe//zQTr0S7bw+y/vD375+S0Henmf4f71/pe999z73/P5f/wz 9fP73/d+/vX3p+//9yDzPv+uuPP+PZvP51PpTD5zcMDt51KZAiStbDHPv+PeHmTYzNvsYfhtOp99 x0dyOe6P7OHb9B/xTCb9movtryV/exdN76/EN1/s7/Pp2NZaHDLW2v5KMnb0yoto8KeXa682N2MQ vn5aW4/FFtA3Cy82PdEX7q25F8Ho99Ho6ohra3oKRkEAACAASURBVAuy2FbX3Ih7FZLW6qrbBQay 7e7a2lrcGHfNLwOCuB8sbm1NgoksLrvmQS+A6ShoTS1N0NNTS1MzU4PYBOpKnx2cnRlEtbxL073T 4CJLvdNLR2tXg0dDTY521K/DDc2v/vj63etgIdc/Ov63T7BhtANyQgLCGEZQjvZAhoVliEFQRS/K W+iCIdeulTRUCYdJoVCKV1VJ5A3XpDelIiHQh7CkpKpjRERLRSRIgKavSCniplxEUldougrD8Zs4 Kae+VeDfM2cJBpPIyP+fpnf9SvPe134bu9TRW2PL3nMtSesEbJvEaT2MlaAEUJEuoxhETDtjmohP nGiImnrIoaDTOKJiBGPGIDYeBniqiXCDgKCRg6CxykEQxxJEg8mcO6n6JCPm3TPG/AP29+faO7WC IO2b+8p1fe7f98Ci89h0dj6Jm4qRbyVjxyjJF/ncn1LziWQOi0UnpQB95HFIKUQSiRxNjkeLq1iC r5M4HDKLhSVfJ3NpeWzSLfjOwpj8RAzDTghKWTQGl0hN5aB9CazLpBIOjUOiobp2IonIKcmr5aEd 0rzs6GI+seQKv4QhYICRROdVJsZHE/miyuLimnMpl0rOCbOFFyqKigVFFYWnhYVfnbqUcuWrC6WC uu/OVAvPlwpPCQRFrS0iQauourW5/MvmuktfflEkbxdJW5sBMmStUrFEJhNXTkobpPCnHDKYGHxj qL1aKofkJC0fkEv08iFFX59d3ictHxq6LyyUoiYO+QCkJBAGKiy0DngVTgXKWlLQkGLANmzW4l67 wiCRGJ1OEAFu8rsNS0pZYAhoBjfP+W1efxDQA65ilwHFK7chCM+VIA7cbXTNmUECuDdi1wVshjCY g9kYNhqVTrPBrtR65+b8roh/fh5Frc1IxBUKRGx77nmbW+mGzwdNe8A/YW8I0prOZF+yLZvcpiWg eHARp0Vq0Q0PO906pzLk1L8DvTjt20t6pd1q3xq1WEYhb03qf3+6ot++r9f+svZ0Yc06+1Q7C2Yy qhqffaz624PxutnR0fEnavXiwijo5cnKBID6AjC7SgP/AJE8mf27amFaM/OgY2ZCMzH9aGJianp6 SvPXiSnIUx1Td6c0Y9fHOjRjELU00+gwHY116OhAHeldXf39QCBdD7vq20a62x6ONPbc6brdNtL4 EHLW7arPTnbfvnOjPgcdgaCadzQTCx2mo/2dBeh85ORv8DOaalIQk3v8yEMo3+fkHs/JRXexcnOO utFjUel7ztFwUlRY8j0lNy2NUJZ8HA12QDNIIVZlYlHJZWlYztUkVi0LmINMgKSVxkojYCSIPHDt puYzOXTIVvl5bAKBS4MLHX6FTKeSo2j5BDInGtCCTibQ6ey6ZBqbSydTyGQql0Am0OgEYJokHpfG IXLIqTw2O4nMJeUJ8onxx+hE+DiHRSBxsGh+HplIJpFKRSwOmwvsQiLSeAQiOYUYTyRgxAxuEYd6 hZ5XUspOolVcLq1NTSRGc1KyidHFDGJ2UfSp2prEFNp5Rl1d0QXBuSunogsvC0u+5KQIU1Iuf55w qVJYU15UXlRaKeKfKmktFNWdKzz7Rbmw/NRXDTXnq8Wfl9c1FArLW1qH28XNfdUthV9JyxsahOUg jZbyokJJn0QvkUhaJ/vaZUK5XDLcDvDRIpEoC6U6iVivEOLDaDCJcuD5kGJoSKEQi3GFDu3wwMFt Rkd1RpsOfMKJjq2lBp1uzoQrxMg5WpQGhcKrEBvMNrsdx43/NLpNRjeutePuiBOHv+2VbqVC6fC5 IjaX2wD8HcSNLv9zn82ttdnC89Kw0e2OhEKB9Q9ud3je/E9/2Ly76ba63Zt+txt3vUVdhaHdiNd1 EHZHhsymkNt/ADDiDnlAMaHR8NLWO5vHavLb7cpQ0DSH7vfaraMgi0mLVQv+4Rl9bHml18MLnqeT fZNqrd4z+fv46H2VZ9SiVm2Pq0e1P6tnn6pXHq+M1v0+uvhicUXVeV81+kT1CwQulernTjXo5LF6 QTXzqHaic3pGBaSu6e9QqTQdHRNjHdOaHzWP/g6hCjD+7tjELYCRHzs7xtoA2/u7QBz1Hfc6kE56 2u7dawTT6Lp3p2vk2ypg9M/qH9Z3NwK73xnp7q7v7r1zu7vxdjfa4InmvJ9ERyAnCwqqmqpQseLN 35puFPzPOUguSKEpNuZGDjpIz4mNyYVrPxfd9UXzTrBMNBsrKvaozRBLo2ReLMukEDIb0bjrzEwC hZKUycyhs7DYi8kUJpr4HktOKssjY0wsip5MwCAzsdBRIIV3kUUHCimrFbAwDgu8hk7jJtMJhKx0 FpnDwyjwMovF41EwUhZc9AQWhtFYhCRUlYI+jt3is4gkGv1irSAZbR0hx5PgDTohnpiXSmTwsLRa Unwq93o6mo8lSCcTWVh0KouQxecxeAxOdDRRIGCQOBxabV0lJ/5ccTaJlF1cwkgkJp4vLUqpKYk+ IUpJKakoLYlKETJEF744XZyQUpH3+XlRTU11SxHxG4ZIdOFSTWFJXbuosKihteVMYUtrazV4jFgk bmmu/vfavnMtDQ2i1mixtKG9Qdgq/apF1npF0i6Xy2Vi4Q+y9iWZVKZtnpvrk7bqUOeTTIc6PCQ4 BKol2d/ah6SoxUP7lUK5ZJJLnZIWu04m1pl1Op1NK742YDY40XS353N+K2qcteM6gxeNLDEYca8R vzbnV7oMfqPkvi1oCjiVXrvUdojbjWYDGAKYhG/OYXMb5k3Pn0dC8JLNbTM4IjYcD+465g0+uxVe jviNPqnVNT/nc7ojdsWeAQ/tBgz+SHjLvhUwQwLzus3P57xb3kOQpNtrcOJb9tDygd27ZBkffmfV fVjyPrDYlaZXWqv+/n29fdQy5NQ79drH90eX+1BVr2f592XPY/22dOX+6PjaOICG5alnZW28c2b2 sXpx8cWTLPXKwuzig8cLlx8szHSqap88mVlQdXaO1T6bVj0GSJ99pPl5YvpBZ+cD9L2jXzOl0UyM 1Zc9QrsKb/V/Alnr7lhXf0d9V//D+o67/YNt/SP13/bcbesZ6RnJvHu3rb4erWSrH+lpBK10j9yu r2+sP3n7NthHU2/Vp1VVvTeOBvKiAYtVN34DhRR8+mluE6rFygUGoeTGplFi4tKQfdxoA+uIOZ5J Scuk5HyfiRwEPAEQPjetjQnGEpdz8SIllvk1vBybc7HsKj0tLZlAZjNjCLcIBEoa+yKJhFG+LqOX sen5tV9jrOt0Jo+FEWLJPDYvGouK+lokiMLYfC4hOjZZdAv8IZlLZJUmxyTziVlYpoBPS8GSLl5n ZkAGqz0BUqNx2BwCIZbEzsjH4ON/quNHZfH5nKToqD+J8jjZWflc+tel8THpfGp8dErtrRTOMbKg hFPKpglELBAIIAl8PCqVX5pOiD4WXQofzxYIsqnRmKCuRFhBK6mglVYmxQpKz5/6pqauurgwukhU WiEqFdbVMUAgQn5l0RcJ0TW1oopTn0efrRsujW6tE5UXfv5le3urtKG8ubW8ry/hm7pm8SWhaFjW Wv2lrF0mb5c1DLeXS4ZkWkhSLV/8IB8akgiFX1UPP2/9T93wkER66f7cHO7EZQN6mcmfcM2sV1ik pjmbU3JtyeQcMjkH5sxSnQm3DfkVikuSIZNJMSq+pnv+vOE+cLXd3oI/N9u8NqffpptzfIPP2dxS 3LzhcimUAbMNvozPA0pjwOUK+HG83B0w+3CF1mr854YsFJhz4EGp95/mPUfYYLT5N1xfRubmg0rv xtz+vjJkDrjMgXDguT9k2g27Agb4Xx2YzP6Q1WJZfm5uCZnM3i3lytJzv9sLQGJfGt765tAU2rLo wWDcj62mJfvyK/vysN6yPLltX96+v/Lz9qs+vVr9s7puePJnT9+sFixi9vc1rXZlfHzhxWxn9NMX K2rVk9/XRkc7H88uzswuLszOTqtrF9Qzz6Y7O7rAQ+Dhan/t/7r143Ttoweav3aBnUxPd16fHpua +jZq6u/gKveQwXwLChm8OzZ2924XCASVLtZ/VgUe0vXtt5/V372b9tlDtGbqs6p7d0ZGRuobR3Ju N8acBPq4WXXjDnw/2XS7u+lGd/ftG+jYEHikoCDmU+D0T3LjTsbdjCsAYcTEHEdYnpt2/DjqD6Ec h8hFAXK/Ackrs42JoS07aVHwK5llmbFpqKkwKg7SUVoOMAYIIy6ujMXMTCKVsVgkCj2flF/KvEpK ikpjka4ml2Vcj8eSSFwmgURI+ro2k8IqSycnY1GsZCKdTsoiUlgXY7DSfC4z68TF/LxMLJvHYQto RFpSFB1iUz6bz4OPcxiJZFJ8FruWgKWz88nMKCyfSaMnkqhEjHcxJl7A45Ky2PwTJZkEXh6LL6BR afHHWAwalc0vzSMSqEUltEROfIpABMxRymCxjpHYnCJa0fmUywmCi5/+qbbmQvZZQW2JIDGxlX9B 1FxUKKQmZNRcKqoUiaq/PFVY3VoEl3h5Xd2//6UZjOUv0Rcqy8XlLeIWYWEf+xNRX7NMLO6ra54U 1kzKZcN94gZJ4SWRTNraNzQka7mmlU+KJdprzuH2HxqGlmT66v+AyIU4QyFuMP9f/94+NKBT4Kah gQGxzKgbmBtQ6pRi6ZBOqTOBJ2il8wZUwK40PB+y6ExGuU5bjooO3WADVt366V/MRoML95pNxiWl 1xcxPjcEXUGr0+8N+s3rAVsId+3CK3jQ93xJGVn36bwKrRGII+zaDCsNr89oN3yOvWDEbAx4Q35f JLBhcMPHdf4wfNzsCyqDe35d0AZh6rle6zcd6p2j2iWnO/TObQ8BuH8zPryks2+9Wn61NG4ZeOVc HrZv2S3qNf2WZ7JvedJy37KN2gzvW/p+Vy88nRx/AkJ4MepZ8VhW7queCv7tyew4GMqL2sUXD1TP xp/M1qofL/ytY2ZGrX5U++yJplM1M/MAspW6trYDFDE99nP94C0AlDENwPmjzM/KpganOzpu3R28 99ee64Njd8sgXNXXt/V39dy7d6+nvr7rYRvAenfPnTtVV9varvZ+e7IX3e2tr4dQ1Rb3KVp5W9WN ZsWdrOptQiXvaGxD082TuU1NTZC2TgKkIwOhQM5qOx5DuZGTExuX+2kuOjJH96woqDoLvuLQAh0K OQ2SVw4G+SozNjatLZmVCSRCTiPko/tYtcmx+WxWfhKWFJXMTiMwCfByJiiGQKZjgNICFoGbzPma 8BOByExnRWGsvDw2i0wGXCchBiHVkaJABulJ5CTKnzIIdBaZmE5nspIz40lMDMsX1CaSeRzeCfJl wA02LYrAZZdkcIhEEpfMyiCTCal18Rj/Ykl6PBgDP4NAyifTeCQWI5VET0mJTioRCS6jHdCsxGxi Nqs0MSoxg18K0Soxu4R6QUD9IrG0LoEkElRWJF5KoNaWUv9y7mxFDePChe9OZAsZn5+trBNdqqhu af5zectXNTXNZxLKm0Wi5ppyYU1DUbPoklDY3v6f1e2ivlah9G/l7c3Chtb7zbJquUxWLZZJgcHn hqRyuX5IjEtG9fKBa5eAN0AjCrTRfGhALLXOmX4ZMKNh06FrcrNTMgA5S6fXOeUy3KmQOs3PDbhB 5zUpbLjCZjCIpV4jhCdwH8haAQOQ+D+NYtOcMYCHgtaldSfux+eNLp3Dq3PavDgYw3OH2xeJBPA3 8zZvwGHFHYHAukN3YIt4veteN773/3i15rlAIDgf3DKZbc6I+60p7IU3nWGvXbk0NxcBIt/1hzZD zrDp7WjIbzKZvHb7OzTH127XHjy3j5qWl71W8JjlJeua02r/oNDr9eNa+/aK5dXy8pbWaZ8c92yt aEEnZy1PJycnx0dXRmWPxxGDPP1d9fejwkXkK89UMwvqhcXHM6MziMw7VYtILTPqZ2NqdSdC8x9V U1OPph6MdY5NdEzc6ujsmKr9se3Rran+Ds1Ix93Bv7aBb4z1AKc3dvV31Xfdu3uvq6e/5159Vxfq tK36bKSt7ajftre36mFvVVXVndsnc2733oZodbLqdtPJJjSzAd3A+vWol7Dpxm8F8OST3NymOEpT 7Ekg8zgKGtoAeYtyHM2Q+zWtKSfteFpmTmYmRonL/D6qEZ5SrqIz9saoWGDxRnoyk5zMupqcD9c1 /BKzjEzGrjKzmPlpUWSM/DWTlc/kpbPY+XQ0UY6QzgOooNHRJlwKlkVn0VLzuLS8fCqbR6dlnUiO z7tIpROIKXQuj3yMSiBdZ6Xns0rSU/mpNALGZ6OdByxyKoA7jYvqe7kcHpvLYacm8hlUDvFEMimD DVxP4yTyrhOwxHhWyZW8fB6/uFjA5cQTazMSS68Xp/5UHB+fUJx3jHiZW1yUgd4sZlQWny3KzkjN ruQXZVOFxYWlpcRvLp2qEdQIMkqbawSiisL/+ksd/5yoRsAor/78/PnWCwmF16pbW+UiqQyIoq9V LK1urqnukzWIhTKpZLK5qFwsnpTLJxv6hvR9kKauNQ83yIfwgWq7/BexWNd6SaqU4/KhJdvAEA4p Cgf60OqGbXqJVofrjPIW4GuTzjA04Dd5TSY3LjXOKfwmm19h8wK9O2QWpdsQNviMYaPPZgwAcy8Z cMfcPJiJwRYJ6LRBfD4QMRoNAZ9j3ecKKtfngr6Ayxh0eJV42Kewz4cdEeP67mrA5zL7wvs2v8Ht W98Mu8P74Z2AbmsTDwciu0Z/YDdiBg8Jmc3BwG54KRjBt5QHkdGtoPswDDZiMx26Td7ggf2V0+5f dtvRrWDdkud+yKNfejcwCdg+uazXWrS/T3peyd+NW/ULK+q1tZ9XLJ617aeTa9uzVs/s+H3PyrPR 0dk11GO4sDL+7GfNimrx2cKzGWCSRQhZmunZmelnE+AgMx2azpnpHztVEK7ARiamVNOPxjSasXua sbvTY/1d6IB98EcA9MHBsXttg2Vj9+51dNU/vNvz8F4HOEhPVX19T85ngB1djW23Rxrb0C1epJSq nNsj3VU36xGJoPLEnO6mpt9y0FEhwPpvN9CWqU/iYuIKYoFBYnNjUNFJHOKRWHT0gSYrArrnouoS dBCSmYahKfAUOkKTtDRyTuZVMhO15eagzkIymYLRmUwsh0Qn5CSXsfLJScl0MolAZqIBcslRBFTG C1d6Gu9ETjKflJxM5tJY+aws+CAHYJuZiZE5qTT4RiMmlWVw8+jkVCqVmUWChMS7khwFcSiRS4vH 6HknotP5xNRkEpfG5XHiyXQil8Eiov4rIPckUmoikZyRUXwdvIUG/ynAcn4xg3UslX+FU3yFGJ3K zyfyBYklqdnnikpqiqiJKT9fuFCcXZyScPpCzRliUcWfv8qurCytOV/ccklYeP6CEIRRzYgubS4v r245e6qm+cJpkUjYUFMtqW5ulp4+1yJulrWKW4svSWUA4w3gGa1DA5Oy+zKFVCYV6yWyIbm8unBg QCGXK+6Xy5caGkx9CrlCbrMtDSjFMgU+MIAr5GIprtMppTadTKkzG/0QrGyoat0LEG7wSqVGo83g xaUKoxHXmVHTrMEGbwQVuNtmRG0eWtwViYTwiMuNA6D4XHhkcz4yb4uEfQGHQ+sMOFwOx7zS6fO5 /RveiD/sczl8jnm3bRMewi5vaD7iiARtwO3u3XVjYPOtYzO8Fwy7wqCRiPRDwBAGoSiduwb7stl9 qHMf2tCZux0PeZc+hNx6i/2D9x34hn5ra3n5w5LV7lRub1ntoe1l5zuZSv/Kvq2HxDU+uXZ/ss8C zrJmXXtqVS+MWtbWtKOex6oVLSSsUc+o+vHTF+Pj8MbKymPVwsrCiyczf++49QxZiKZzYvHvmkeP NBMPph+rJyZUHSCOiYkxzfRPXZrp6Y6uMTRD7u4EOgXRoPtX/R1t90A237YNdjwEL/n2YVtv/b2H Iw9HGrvQeXpVN0ilsb6797Ob3eAmN+uPzgd7e48OCqtQb8hvTVUA6b/9dvImGl4dF/srKlI8GorV lBMH5vFr7NFGz6YcCpaGztgBO1Cv7dGYEwrGJKQxmZmZELjSyKxkjEC+ejWTTC/DUEluPkbGCIS0 5MxkFjOZRYNLn0Yi0+k8ZlQSnZxEJpEJTMg+Zbx8kAf9JzAXAolOI3Lp3AyMlEcDsqAS6BgzPzOf y+LmcxgsEotJJ9HYpCgijZhFB/Gl8tA0Bh43hUNK4fJZRCaNRuKReBnRHOAOFolKYCaxuMk8Riqj 6EoJl8ag0VKu8KnHaKnUU4kcUlbJd2czSi/UVBQVZRddEPw5Jft0UXbN30pLvympudCcWpR9ikGt KWHway6gyewVwupLFcKaypRvhOd+uSSs+POZytaWZlFzc2trtVjaLCqvgQdps7iv+ZdmmbyvRdpS 3oqmNcjhDzrZUMilCoVzoPyaTGGVKsBehpz40NLSktOpwHGjSStDN3GduEmuHNJBxMK1Cr1kQD5g 0BlAAn4bRCQdSEBsRTd7bU6F2+j1moxGv9dgC4NB4F6bDYKSy4zjARf8aIPYZTN6DcaIwxFxGMP7 ERtc5BHrfMQ2f+DyBiMgjIAv4NuPbK6+X9+1eV17m7uuyGt3OLAf8AXDQW/Qa/Q6dv2O9/s+/yaC lLDZZoWXg7awM3Tof+vf9RsPw153+BBSltPtDi7hhyar26/zO+0hq97idOqdH5xOp3vg3ZZza9tu 7/OorWtWq0c7atHrrU9f6Se3t7VW7drs6OioxzO6ZnnxVL24Nj47CpqYUS0+mVl88mRxdPQZajF8 vLLwTNOhnlap1NM/a2ZmVFOPZqYeT4+p4Mnfxh5oxlR/10yVdVwfuz7Vqeno6e8aHGsbGxwb7B8b 7OhA97PaBsE2urpGuoA50Og4iFddjcDnD9u6c0ZQzqq/3VR1o773RtWRLHop3U3d3Udbpo5u8jb9 9mkBuuf7SW4B6AFEUpAb92lubm4O8pLj4CIxR01TqMoXUUhOGpaTi32fQ0FFildBG2R4FyNfJbNy yI0EAJGrTIxCpzPzs5KS4PqmJ8XSWCRyWhqJTiJfpROSueRkAu0iOgf8iQrSIEEaiiazSPkMOgdN 8CH+xMIIHE5+HpWclZpHoiUd43JpdDKdmXiZTKSSuQw6IAwfbIFFu8zhklgpRAKBxCHxuEwOhx5/ hcpJxYjc7DwelUrMY9NSkqKLuRwSkZbCySaSONSSYk4qMYNP4lQUZZ8vLqYxik4RiUVFV0qLi4of pNAqsoW8hOwKoaDm0vnzgtLCom++aK0p/vNXxUJhebZQWFRZfe7cJZGgqKWhpUXc2nqhVSw8U9gq rUbbNQHTG8Sy6jOtsgZUYSLpa5ZIf6gekDUAf0gUMjFa1KGXabUmuVQ3AMCgk+vluFQs0eFyI47r cIneiesUYp3NZrKh1r8BN37fadDJcYUONKF0K3VG2wBuM+vwiME274p4dYZ5+M8Y5g0+m8trQyJx 4MqIIWLeDM5HAhHIVBFfBF6NuFzw+/Ogikgw8tob3nG43qzuRCKrm/PusMMFRrO6H3ZHXHsOPOiI +AKb85uOgGs/qHy/G4aPezdd7rebQf/OgSEUMbsPIpHNTZff6YXQZXeHD/zeA3hq94bcH6zKD+6l pVBI6V2yv7NYvGAZWtCGXWtVel45tWuWyVceMJGtLb3es7ZlWVnxaD2T2/DNsjJu0Y6qRrWeF+Mr K+qnz1YWVKrxxYXH6mkwEJVarYLn06pnixowEbV6ZuHBBHgJOIZqSvVgWqXpnNY8GAMHGZsa6+zv vDXY2fEjIEh/z1G5yUhHV88g2pV+72EXWgvd9bCxFw1sAGC/+hDdxepGc7G6b9aPdN9GZ+m9yDKq mo6OCdFJIRoDBCBS0JT7SSwkrNwCcA2khqajVdCosjcNiKQpN/Z4bm5a2tGBeu73aTllZQQIWxTy 92mxR2CSA7kqC0JVEiQl1JbOSmbmMwlRZE4+G8CcBhGMgM4OmWQ6mSxI5ogeoZnWZO4tGkbPR/Xu EKlIpFRaFvOIqbm8VAaPRYxKZlznYwQuK4uUTCDlpdI5aG9bLYdXdzGFQ8So1/nEaFo6Kyk+hYaR SOARxBRi9vUvGLw8bl4el0jhMjL4GJGXSmSlxHMywERASem12aXtfEYRNf48X0DNKsxg/DWxmJOQ zSmquXK2KOUCn3GhtPSCgH8hMaG6urk0oai64syFwq9qKsFAzghPV4pa6oYrq8Wnv5KKmgsLG5qr LwkbhGekLdpmKfiGvBkN7Wnuk8uE5+QDQ80/NMgl0mapWD4gU+ilEqmpHZ97PinHxVKdaUAq0S0p pAqdRArSMIAo8CXdgHfIqDN5dWKZw2gGKRngRVzhN+JHJ4Vm0/zz517DPBCI2aAM+o1u3AYfdEEq mrfZwr5DgwOyVMAR1up2fK/1IXg57J+3+XzhSDhsm3/uW/3n88hqGJ/3vY6EXD7jvHv/fSjscvlW N/fD+wAsO4EdSGNhRWQnMIfkMh8+DIYD/nDkANDk+eHOP+e8e27lwa7ZbQ/7QQte95bb/fbQFjrA bX7nq0O/d2npw9aC07u8bNnSvbO+03vsS/qtdyAR/fD2q7m+d3bLgvXVrOX+9tPxFcvaqFpr8Ty1 rHhW1l6Mjr94Mf503KP+eXzt6TPNwiK4B0QsZCKqx6ons+oX/wte0nSqIWF1Pp4ZA9jQdKo00xMa jap/Ynrs7xPXB28NarquTk/fHazvHwRO7+o6Kl3sOmq6vXv3YU9XfX3HnYfd9T0P67uPRvPWjzTW o6c54B+9vY1N3SdP9oKTnEQ7CtGpYdPRaXpB0283bzR9UpAbizwCUTmSSFxuUy5gCagjLvZ4DtrE RslMa0Jl75k56GlbMlryCQJJy2dSopLJFDoZFSyCTaSxyJnMq0wmnRIFMYwEkE6jc7Ow5FssSFF0 jE3CMgHY2YRY7AQJI7H4HIyQRydwWGwui0cisUh5TBZgyhUSdgzCGi2JmcfhMIiEfD6HQ+LSo+Hj yXlcPhuLIvCIGIfLT8ZIQBrZDD6Xy6MmPFbmGQAAIABJREFUsmjXExkcGiObdLTjkJaVXXKFUUzK YpdyGBwGNZFPik+vKBGURB8jlaApcZXZSYxSYlFxjaCi5sL5wsKKmsKaouKWmq8SiKT00tNnawTC 6mrgEZGwWlj9t5Lm8ymC1ua6hgRiRfOZQulkX/l/NjefbpCK+hqeysQN0mZ5A5ovLRP/rbAcnokn BxQDuLhhaEgpV+jhJ3HrgG5oWHZGKB+4L7GZTArx0ADYxhBEKyAO3K9DiwINOuV98BaD0g5oYbQp gEfgr3Kb0hiR6ByGgNl5X+r3Km2uOaPdHjAoI5GADwwCEpTPGzHaIg6XUmnHjftA2Q7Xjgv3vzau uhx7+Pq+3fByx7xus+p3Xfj+zsZu0L1ucO+8X/ft+Fz7DkhYDsCU965QCHfv7AXBh/Z3wrjfHImE 38+7A+HtpfcRs8lusfuD9nDEfGh1mt7hELMODf6g+4Pbj3/44P7gxS0Wj8Ibsr5bcoKtWF8t251b To/2lXXh6buny5PqB6OTFrVd36dVjz9d8Gj1s9sv1iwez/ja6JpndHx8BS74CaCRxWcrix6V6lnt yhP1gmrikWoMglftTMdfp2c0GlCJqmNipmMaMH16YlozNjY9OAYP02MdaIbcWEfH4GDnYOdIDzB6 f39//cPB+quDPYP3Gj/7rPHht/Vd37fVVz1srGocuQ2kjoZX9yJQbwInKUCVvCdvNnVXNaFSrKYj G/nt5qcFv34SA2rIRfYBkA6aAKFQjqcdb8qlpFGOTkHQEWJuTk4aqsZCO9Uz27DctGRgcvJFJggm FsuhZ5JZTGZWLHaVnk+mpLHKylhMMotHzqJnUZIIBC6ZTOPwCHQOmvlDy2OTk9LLaBxCvohF5tKj 4smItlM5P0WRqawSMkZj8Nk8CE9sIolGxLKi6Tz4NCOPQEslRkWDrNjEJHYejZOWIaKRGfEYkc6j 8Yq5XOoxIpVXEk/gfFf6HZuTUsKmcjjEaGo0pyK+KLuihMgtIh4jpvAq2VRqZcbpoi9qRamcCwkJ l7P5Z/g1FRVno7N/Li1N/LKiVFRaKiyvLD1TUf7FqUvEmtKUanFl6Xk0qbqwvLWusrC8rkHcUtPe Xt4q+0pYLhVJRXKZ4lqRWNonF4rlfe2iyf9Zg6ZouaYVDsjFOnxJJtXh5eUSfGBYJ9WbB2wK+XOT QudFpbsGnR94AyAdN+mkuMFkHlpCNexOm02ixCXGAdxlMDoByqVA8D6zVwlXrQs3/DOAAz7jbsAN n8PosjrnXeaw3eVbNweMmz6zywZ24QYLCXtXdwK28I5LYXc51s2uYMD8L4fN90+fbcelBOt57/Pt vH+jDLver4fxfd9rc+C9y2feDO+H7W+DXp/7cP+9DyThtsK3gMkWCpjCh/bd595Q5J0VlZ8sHXq9 wVF7aMm/ZXUvmYbQOKClLfs7q2XLov/g0ds/TFq2nZZfLFv65UnLyvJT6/bo8u9aj/6xesHy1PNC v6ZdebBgWXuhVntezL54Njr6YhHeAerQPFlUPVlZfKJZWNB0qKZnaqdUGtRcOFZbC+bx106NZko1 NTGt6siCZ2jV1K2psnv9aFlbf2fXSEf94NhIf/9gT1d/z7dVI11t9xrru+6AkfTebeseaTxZBd9A IL0j4BeoMb2q98aNnKaq7qNyXpAKBKsCiF1oD0JMzCe5cYg+YtAt3pjcuJwbcZ/GgVrSjsei8e6U o17b47HIX+KakpviIFahYvYyNB+oLDmHXgZOQUbzSfMvAolgZV8nUdBGTTaTwEqmZzGZ+eQ0NjOJ EJuGRbH4hGN0MpPGZdeWZpIICbUn4rn8/CwOjUDGsvgCSFxE/vUkNMA3lU+L57FoACs8ciYfyDyK iB3j8ZMwElz2bH6tgEyLZtaeoJaUJlM5KfFELEXAJ5ATkwW8hGhSKokhoJFKimi0K7w8crqAeJlw jHksiV+aREy5XFwkENQJqD8T2SLGeUHt6TPCosTL8RWiyqzss3xRxedE4bnTguYzjNaaQmF5qeBL gei/hERiYUK2qPLzQmFLq7SvblgkFJ8RtVdL6/rEUplYWF4oHxb9Ir3W164QlitkkqE+MWCHAkfN UEND95WF5dJCybBTqFDgOp3JPIfG6A6b9DazSWnTKSQSqXFuQIsrzWZcqrDpwDWUBqMNt3mNBgWa SCJWAKHM2aRHBSLm5/8w2Nyh5wFbZM4HRBLEcXfgH7qgy/3aPK+wRWyR1w63bwcoHEBE9xpyltaG a3c25u2uzciOb+MfzyP7tvBzX/jjxu7m6upbG745t+F+ux/eCLzFIZC9n9u3+Rz7m5GIz+Y1ezeD 0gO7ctccss+/PdzfNT+fc2/avXOH7l0zAP2B3W51D5u3Qm7n8KHVan9n/2AKbR86Q6F3zgGPc1kb sjzWqkdfLa2MWq1r26+Wf1+2WO+/+H3cM9nnsW571KMqbd2sGlBkdlw1PepZWJtdeTzuWVkZXVxU Ldaq1J396p80Lx51gmBm1I9qZ6dUqs6p2mkVhC3VtKa/s2Oi9laHpqPsrqarQzPWP3EL9dz2a1Dj 7eC9kY5vu0f+beTeQ1Tv/rDn3p27t+tHqtrujIzceYh2FlZVVTXeyblZfxNt0bnZ/f9X896sAhAp QGNNYgoKYk42/frpJ03orlVcXMyvlNjcG3FoRUhsLrgKMo+czLQ0kE1OG2oihKz1PSEXS4OkFUXI RIuo0Lw4AjvzKokMxA60zkLLcVhJZEJsLMYiUMj5F/+Uz8Oi8m+xuVg0HaNfpBHorHRyFCGZFw+g wmfRslilySQOjUaOTuaRM24Bh+eTaeSoKEIeAaOxS9nsvGMYG+3XIZMwLqiGxkPbqE7kkcnHkkuB 7ssETE4qjRNPyOeRStlZefzUrGzCsShiCYGQza/MKL0elVAqEDCiqbSEEkEKNbukIj4+8bsMIjH6 u8ri7FOVldkVxZcKE7+oySgWfXdW0Fz8VQUxOiGvlPpFi0hUKao5dkkkElWcEhaebxYJhdXNDV9k lzdX/nD6K1GfRFzeDlJQSKTCFnmDrB20MySRyi59JZTLC8UD7e19JsWX+HD7EAJ1q2lIq3Qu4eUS +ZBOIpaajDpcMTcEiO3GJbgRX5pTQO7CcZsYUhRYiXHObDTjQsMcqhGxKebnInYbpCgJbvDpcG0I tT/ZnhuBtV22kNdnC2zgq68D866wVor7DuyuwMbrwDpu8W1s+NzzLty14TjY3/kYttscH10H9vDG zn7Y/w9HZGf/Tdi9GnCtzwV35nbm921KbTBwgO+ZN8yBwJYSNVjZ58P2/blwMGx8/27bfbjrDmkP 5rwHwWXzQfjw7duQPbwUMi1vHZqcWwfalZbtJY/HvTy8vPxBbVleXnbet26NglI8W5POlRaPHlxE rX+1bbXM9nnWFB7rysLa+Ojss5Wns54Vzy+dnQvPVKrF2dlns6N/Vc/WvpjpVKs1z+A19eJCv2Z6 akbT3zH1CPAc3fBVazQd/RNjY4/GNFNTmv6xH78dGRv8sWvs7t3Bux2f9d+9h3rTR368NzjyY09b 12f1QOkA421o2PudxvreEXSS3tjdexsdoyO3+PQkylbwQ9ONgpjfboBE0J8mNDiu6deYo/7BXDSZ Fzg9rikN8PxGJginKQdyFZjH8bbv0SkIcDlgCKpfTGMxYynMr8tyYrCyHIzJTCZcTb7KZLMA05Py 2SxWFrAGIYtFo/PQ3nPWRX4eC5wjn45lcmlYFI2TwYgis/kZhLhkPpkMEEFm8kh5fB4nj5VwK4PH pdZmRJNJ6RxWSTJGiC8TlJZcofH4wB7JvBSMksopTY0i8QV8LO5rfjwtj8eL5+SBnooZt1iJgpLr jBRRSQI9hcfl8RPjySRwHH5REV9QQk3Iq8jGokuKa68c41WKSo99IiglCktrLpwCAqmsrampLBKK quHnutJT2eWCckFz0RfZ50R1ouaWapGo+szfKltbPj8ta+4r/1JW1y6P/rxdLkQT4Vrkcln7kHyy T6ofHhjQ9w3L70vlA4q+ITFkp2E01G0Arn6pZEinEEoMQyapeMg8Z/tCPKeTGox+p8KgM8yZDEYj bpgD8zBt6FAVos1kVCrhFZCKzWE2hxU2nwuX6hzrAQUe2NhwXXJveN0+n0+36XMZNwIOn2/et+Hz uTY2bG6X0eFa34WUtfuPjfWXq77XgTfuSGDVbY/svP6oCK9vbMw/NmyEXb7Ax/Ab335gw7cT8G2+ Xvf59p6vu217u+/3zZFQ8G1gYy7wHpzDFwx5d8NK6+GhOSI9CMwFrL8sB+xuv99vPzg8MJkOvcsf Qib/kvfd3JJ1690Ht3N5zaLdejW8/Oqd/dWy02PR67fVj/Vry1rVWt/yK03n7NPH20+frq1o17Sz s2vjT0ctdc9ejHvqnqnUo4sLiy8eq1QrtbOziwsLj2oXVJqZGXVH/8wMAMjMo9qZb68+AgyBhNU5 DWQ+Nfj3W/2qu9NlY4N3B8FKBvvRhvSujrt37w329B+Vm7T1jHyW09PW9i2Yxp2uTz+7g1YfNOZU 9db33r6B6Dzndk4vEstR0y04CIQrUErVzd9QsWJM3PGYAtRvW4CK2xGi5964gRbfUmLjQDnoxBCi FqJ0CnKPWAByShohrQ0DKGElR8VknqBcTcpkMXPopCwyk0VOYrK/ZgJ607GoqCwWL59GJWeRmBwC Rmfl0aOO57FZ0SfI+WVIP+z8qFheOplEZLE58RxOIonLI2Wl89mc9PQMEhaFJTLyALyJ9BRmKoFA Y7BJUZklt5Lj8+Kv5xHI5HT+iahjfBaRRuRlcIh/vnKZlldMo7IFGdw8Nj8x+lg8pyQjr4iTmJKd zUggXskoOXXsBF+QTeVTBRkJ1LP8yuKohNrs7EvZpYLC7JryQpBK0aVKkaBGUFl5JiH6y/LKyupq YWF5dXVNyqXqZllhQqWor/xcc3lf5Zlysaiv+tgv7eVSaXXfgLRVrpDIBuRSSXv7gHygfUAsPCPF h/rAJiQ47pQBeQ/ppIV+k0mpH8DNcqsSB8V8js8pcVxn8uM67zyKVLjXbDYYjBCspFK3IWA0uGy4 yxVxK+YNZpdCGoAL1WAwrOuCuMscwIUOcxAIfd1hA8R2OXyRsGNj3fHSByFLad/bWfet7rtc+/s7 B0AX6/u4c30dJBTxrYcBSl4HQuKPgc3/s7mzvrO5s/Nm3/dxf9M3t/7+pW9uP6TEXbsBn2MvvLm3 997thh/CVmfAfBjadZt2Q273odlgsZi8wbfBQ9OB/fAg6D48xENLw0sfvEvLodH7VvsrAHW71h4K 6S0e+6tX1l/WXi1rLa8sr56uWDxP+9b+S7Xs8VgtT596LGtai3ZtbWHlxeya58WLF2pNp8ry7Nni wsr0ysrChEq18GxR9deZZ49UqkeqRxOdYCSPpv+t8xEgvWZqAvBcpRmbgFw1dXd67PrUYEf9t12a MghaqCmkv6cecL2//jO0CGHk4Uhb77fd9SCTmPq2qv8Z8N7dW989goqxbqOhoze6T3766c2jZZ5o KNbNXz8tuPlbLkD6r6AE4A7IVSfjco8fR4MWY4E//r8+dZAFGkAaS0gDtXyfCbyeie76EpIAK3KY mVHHmWQAk3x6bFROVg6Tnc/EKElXWUx6/k8ECkYjUXkX2agaN5WDUXn8fAINQhadkEUj0eKxFB4N I3JpZCwxgxkVTSfRGfw8DhZNJOaROHmX0QYR8JpSPlz+ZB6HkMIWsIgp6QwilUDiJHLikxglTCyF kRIfnc0H2CclJkKmSoE0Rs24zMi4TMQ+LzpbXFpbys8m0Wqys4oEtamcn2vOJZ4nni+8UkRMrKlJ JZ6rKEwk1ghORX9x5VJRZW0r0MalwspfqgXC/yAWtggbkH2UQ6wqP9NaV1dRLW5uEIoLUStUoVg+ WS5slkmF5ZOiH86IJVJF+9Ck5AeJVD+gHNApxEI9rhwaHjYtKSQ6g0KJJvjo3EOQkiRumw2X4iaD AqwDlyiMBqkUHQSCieDSeTRa2hhxS6Qu1EQO9uHGjQ583rhhxiMuH0Qym8uFdBNw4LadVRseXndo cQhXOyCOID4fBoII/BHG8dXVVTCK9ZfhsG/H/WZ9IzD/r52Prjdh17/2VwHi4ZcjL1fD7v3X+wr3 5r7rJXhQMLi3GdjfD+zbQu7Vvf31ObP5ve2tb9+9F5jzH+y9f2+bx9/u2fbw0OGuTemNhO3WsCk4 qgy6Q36T/8CyFQr5Qx+WQtpRrTvkXDYtL9u3t5a2LO+Wl9e2tybfebZGrVtb2xbLu0nPyviadUUN 0PHzCupOB3FogD1ewMsrKs2CZwWC1otnj1WPF9Wqhdra6cfqxRmNWoMaqTrBTjT9iM87J6Y6fuzX aJA4+n/s6Bwb7J8e7Oiq7wc8h4SFduiMdaHFUiM9XWhXOtoUMlJV/7Cx6tvGkfqbVQ97TwKuI3H0 3iw4mu0OCFJQUHUTLbpt+g0NNykoyG365Fd0EIKaQuKARMBKCnIRsyPkoDRhMZQmNNEBeQfoIjcq sw1VoVAwylVyTg4zB2Nl0slJ9LQoLAnLoRNyQBJJTAKFEkWmJ0HcokXR6QQaLYuZzr7M4tEJBPaf KEQOjZxFprHoiTwyqSSVQ6NfATzJiqfTyPQsAPVsMnYsinWZnM5hkDAOicziELnsDFoem06g87/G SNk0Op3IYVBTeEROCYNLozGI0SQiOZEGTkJI4HDjCcewIhr1OkNIjC5KTGQUUfP4/Gx+xqmE1Mr8 hOziK6doKeeKOcILl0tKKyouFdacIl46+0VRIedSyqmvKi58/nnC59WFxdU1rZ9ni08Xt7YIK0XN YlHDg/OCunNnpEeNtQ0NYpmsHLKVTKqQC4USsVjWIEXbaHFZ+TVQjlIu1+mEEqcUBwsZMi3p2nUK 6dCwBBgcrWD26nBQxpDRa8DDOgBzAG3c5lYogy6dRCp2GnBwkdVRG7CDY97mMzsiZi8w/LrS5gDy mA87DBCqbAHfqsO1CmiyaZuPhF1hPOhyhHG7MrK66XO8XLWvroYdL9841l+v+tZXbbbX67hrByxl b/Xl/upHuPp3dlbfvNzHw5vhvdWway+4ufeHzW0PAaD73r/ct++7wu/fb74PmPfBPvCDud1QOOJy H7zdixyE/e5w4HDv4G3EbXUHwVDsQTuA+sG2ddTyIRRach5uWdz2rQ/vtj6An7wa2LLIIHBtvduy ejx2PXxZ1ia37YDto2qLZcXjGQUwgYfpXzQPtlcWxhfHVSqLeuXJinrxxbMVsA/NzOy05vGCWgVu MgFfmpmp6cca1UR/h6azE0056e/o1Ix1ddV3jHWMjY1N13cAs4OFDN4b7L+Hugnv1dd39YzU/zjS 01jf04tWpvfWjxwNaUDTFNFq2+7ukwWoEQRQvfvTmxC0fruJ7vSiGVkFv36CVJFb8CtopIkCEvk0 Dp0WgoWg2sVM1JIe14Shw0JKE1ogkoxRyJlpQOWZzKv5rBwyHVX4Mq/SyZSkr5lJaNEti5dMJZBp dDLYCXaZGYXRyEk8Dj2LySV/Qs4gkrmpHC6NxONyLuZlsbgcsJpUWiqJQOJziHQyRsorYQCMc0n0 eAY7+kpyFCGbTr2eTaJyePFRySXExDzGFQYnJY/BFeSRGCAQeDOFkZiQ+ogDComn1ZQUc4hXGLRT 1Aw2sZh0jFpMPM8vuny2uCT+2Hd8KoNfUXzhQWHphQu1JVdqKs4VnRcIiy5kn6qpFJ4p+uKUsFlQ XZjdUlN4qVCUcak1O6Gw9bS4uUV4rbL11L+LZMKG5oaGZmnDpGyyvaEBDQmV9KHjcvHAkEQiaRHj 7QNOicQmV2hlJplyQFyI66S6IVyJL+mu3Td5pYYhnRfVUdnMZhyVk+Be47xNpwToxm02AA8E3/gq Oh834y6/Vuoy4EZjeB6cQ6p87cJ9IAqHCzjj9fq80QHXssP3xuFyb75+aQOFhD++Bk9wvYzsze9s zK/uKIN/RDYDL/f3AcO14df7e+sfd17u/Cvw8V8b6y7fyz/+9ca3839ers6/2djZ3A+799bXd1aB 5V17th1zcCeiDO6ENwPvNzcju27rYSDoBTCJRMK7/v25XTc8CQf94beH7tCB+SDktlvdy36v237w wR7aWlqyHqzdtzq1oSVQzrtJi9r5yrMGNOK0b08Ch+i31/TbHs+kVbttWdHPeiyjK2rP7IvtUZDJ wsrK0yfq8elO9SKEqxW1+sliZ8ejJ6oZoJGZ6YWphZna6emJxxCsplSqaU3HxBQopKNjbGriQX// 2BjEqlsPOwZHQCwjaApQ12BP1bf3ekYetvX09HT1POx6eGektxEIvb6xfmSkquo26rc9ebP3BqpY PGopvAEYAmK5WYD255z87WRMwScFBZCs4nJBD7mU2JtA6ked6ZSmnJyju1ppuaglHVWaUAhMCuA5 hZKZDJnr27ScNKCRzPykq/QkQhuThPgjC1XyMvOT6cx8LgujortaZIxOSmJxaT+RuWwsislKoLN5 6Tz6X1nUxOskAo9NpXGySDwGl8RLp9JSqVxAawYNHYkTUvOw1OvkeBowBoNFI5Wwj2FcFpHDz8vL I1K5iazrJGJGCZWTfeQknJL0y1euXP7u+vUMxvm8khIGsYSXcL2ERGSkXM4oZlzJLi2Jjs9jXC6u rOFfuHypIruk+mxKZc2lisKUC4KaigrBhUs1wkJBaWtlTTkwSMX5ypL/rK3+86VqYXlza3VLi6gy obCypby5vXlSdq0VnQxeq26XSWUKsbxPLpMP6BUDCuXQwMAQjvctDSmUpgalSY/WpuFDOieAhvya bAnHh8x+VIqow40GCF0AHjZQADC60WYz2Fwmh9HoMhgDRtu8GbeZbbgNVZREDDbHulPqhd8BCgm4 Nh0uL+Qh4+s3rlWXK/BxB1jb9d8glXUfcIcvsP7Rtvo6GHkNQcqx6fvo+MP18XVYgY4EX69/XN8H KI+s/2s+8PrNv/5wrcLHIx8Db1Z33gCmr/v2fYHAztv3gaAjEHZH9jZ3dyL7e76Afet9JOg1B3Z3 bW/9b727b4FF5sN7Qa8x4j3wHwbDH4JLh4d+b3Bpye/c8r6yLA1sW532rVfOd3b70iv1gt5u1S9P vnpq3VrbWpu0ePr01u2t0e3JtXHP0zXLtsfyYm3thRYxyKj6xRP1C8+0+ol6BZHIwosnHaoZtWqm dgalrAkVBKzpR9MqIPeJqekH07emNdMaza3piTKN5t7EYH/HvZ6Osv6urv4udKje0XOv57OrD1HQ etjWWA/JCgLWyB0Aj/puEAr8iypOuo8601Fn4c2bvSdvNqFd6UcuAs8LPgVIjzmazJube9SEfjOO Ett0vCD3qOYkDb5yjmZXp6VBwgICiaWQc7HMphwyKCYWS87ByFgOi0xJTm5Lbsxnken0NFpWPusq k8nMo2eV0en5IAYMo6fnsYlkAReROsbkZtE4yUQyRuSRyTQCKY+ZdP0Ej8HJyE/kUJNZP2WwiFxO agaVwyax8jJK6Fg0i12SQWXWpkYncWjRXC4xm5tMImIpecTEFAIrg0Tkc0t4DD4j5copLuc8P5ta fCWPf6o4g1ZcIrhAjSbm8Uv5p3iiKwlEYXZCDe9sRXHR2cSEigwa5K8Lgi9AC4KamsoaYTlopEX0 y+nW8tbKS5UCoaBB1HDmC6FANNn8g2io5vQvspYfRFIxqrMSXpM3lzdIyif7rjUMgUQGhmR6XDKg 1LUrZTr50ABoRTG0ZNZJxZCxTAPK4YBeojQAcNhwA6hCojTplAZcYfQrDSaQiClgM7hw47zRHPQ6 vGaDbd0AIcrsVSq8voA5gm98BLUAdfiAxiPgMvMBwzzkr3Vj0OeDsLX+0bXz3y7fm/WPQNw7ryP/ /Tqyur6+vh8E2ICQFf7Hx/Db/Z15x8f9VUTkwf11197OZmT9/ea6L/Dxj9cf9/94E9l5A8D+8l87 r8Or63uRwHpgEw9GAoH1zfDz9+7QfiQEIolEvG/dobDRfRAOeXedIdOh3x82HR6Egx/cbrQ54eDD cgh9fVg+tFqszlfLS1b98DuL5922ZdJufWfftlpW1p6CJFaQTmbXnq6tTa4Bro9btLOWhXHPs2cr 489WFl88BfhAGeuZ6tHsgkY1o9IsTqtnkHOg4VjwMDHToZqaAGFMjY2p+qf7x6b6+6fH7g12TAx2 DA6WoXaQwXv3Ho6gu70j6EZW10jP0enHw94qeGi8UdV7o7ex/kZjd313VS/8gILWjaqbRz0hKFqd bGr67WYBoAhAekxuLrBHTGxuzg1KXNzJghgKso3YJsAPtCwnEykkNjczLQ7DMDR+NPcqgZLJymSl Ucisr9MoWDKLkkagMJlsNhNLSsKi8tlAGUksWlryFR6NyWcDmWBkPic2OZlK43GTyBxSVnoGl00n czP4dIzKZmAsMoHLEJSCwIjRWMYtIgnYnkvklpTQ8iszoqOTkhIFzKg/s2jZYCwkLp2YweeBLopL +cSEy3xG9IkEYkVJrYBDpJ5KSqgsoabQOBeu0PJqajglolsJCQlURuWpaB6jSFhaRCwSXj5dKagp TcmuFpWmnBLWCokXTmVXV9Y1F58+LUw4W1dz5hwam1jR0NxcIWov/fzM3wor+85kC6rFDX3VhZKG 8tahvklRefVAu7ylRd9uLW++JhsYmmuXSCXWa5I5pwRXypcU8qUhg8w0J7+vtUpMpvuyAR2aRiJx gS6OGv90gTkDClW4Xqf0GueeQ8hyByWGDRdug/jkNvgCRu/Ghk6J6P2lxOt3uV4G5oFCNn2vfesO 9876RgRC1XrQ4Jp3vNx4/nHe5ZoP+Tb2XW82P750+T4CZPxjI+yeD+5v/G+lb2f1j4/rm67/7Xqz /vrjumPz5evXSCYfg7t78x99GxCyXG/eBtdf7+259gI7Yd/HwPv3G+tudzB4OLcP9uHa970PhvcP 3u6a3wcO3O/NAchWgf2tQ3vI75/eIOWoAAAgAElEQVSDkIUHrVsmf+id3b10YPceLr1bGl7yeKxW 5/LWY6c+9O6VHSjEan3V92HSAy8+9axszW6p11Ys+snfZz0roxbVSt3aimfFs2ZZWFxbW3gxu6gB 6Fh8AQgCNvJsQbOyoJp+9gj5x8yzmX60Xqd/ugNcpHZK09/Z2dU/NdYBIWsaAB0Njrvb/+0IGtFb f/VhTwcaP9rTVd+IXORbiFu9Vd2ND6uqcm7W996+gxqnbhZ030YFvaAMYPWmmzduQLT6FNQRU/Dr r5+gNpDYuJgC8BGwjk9R0Io5noamZVEQhkC8aktDPYU5V1F5L8jlag6ZANGLXJZPvkq4mI8GNRC+ xbDktMyyfArGZB3Hvi4jYFnA0lkYvMVDh3+EKBaLmJyVBPmKlsilR6Wl5gtKONQTtelZABIJWQlZ eZknLvKwBG56NJmfEU+gXSbRiGQWjciuTSemEjAeh8SiJ7D4xSmcYlIUiVdSW8JJZIvyacU8XgKV SC1J/JMgPZpazItOFvCjidlXUlKoJF5KiqCWl8JLINZkpzIuU/MENUXCmsRj6TUCUbXwq9q6PwtL W2o+P/9VkeAvpaJz3xS2/t8JfFHpqaLylnLhmfTqwvK6upry6i/Pyaurq4XC5j6ZVCIv/Lyhub19 UtEyPFytH5DLr0nE8snKvnaJGB9oLu8blotRASIuleskujmzHJeL5QaAdqVyyORCHYHVA/65OXCS 53NKA8QrZRDylgGgROEyDihMc6jYygtIMeDAjRvmMCjK7wBXsdnWA6v7Ow4lbvT94/XLfcM/Xs+/ 9L10zYfnAw7j6/Wg7Q+f1/YaBas/Vlff2Ix/uNb/sY5qqj7uGHb2XZHXH/9Y/ehQen0f4eOru/9c f/Px48u9TdfmeiSwEQhuvvQ5va/Xwwf/vb+/v3fg3w+vb+zuRdwh37+8kYO3h4Hd/b1dm+eDf3du d//A/9z/1n8YCQWD7t0PS6ZDa+hwSftu2G/dCrrfhZRrzlBoedgJPO5Zsq8BnqNVOyGnR7XmfPX7 5LZn9vdx7VO9fsUy6nk6+qJvUW1Ze6ZanF1TrVjQ3JOJJysLs7MzKzOq6cWFiQXQyaMF9cKM5q8T i49qZ9RH5SYzEyAPzeDE2F3UTzg92HVvaqyrQ9Pf39/1EKRy92hqdeNYV0/XyEjbYE9X18Oqzxof 3rsDKevOnapeNFIRnCOn6cbtmye7e6sKbtyoKkD7O2+ezK06+duNJghZMaiot+DkJ5RPc5sgUYFO CmIAzQviKMdjYo6jl0AFsTGoqj0nJweCFdbG/jonFtWYpKVFxUZdzSSkJcWlJefkf09m5dOjMpNi SRCnCCxubA47OYmEKnaxKA6VnswlcXkEWupFUWkWxkkhJ+WnYBTC5XwSkxjFTSfxecgpMG5CFI+f mEXPSP+E9CiRmM2JT8nDoosu01LzSCXpBMZfauv4WWi0FTGPFn2MmA0Xf9ax66mcyuLiEv7l6OIk DB6IyQLuJ+mViaeKsonF32FE4dkiRs3Z0mJiRU1deyk1peJK4uXSrxKiv6pgpwsTEtC2g4rqSsH5 xJpvvmgWFJ7/TnTumED0t8Jq4ZnKmoRyaXlrdXOLqLpQJhoelp8B9CgXi679R6FU1tygOFNeJx0Y VgwMDYhb8R+kpgGttNksPTNkkuBehWRI/oPOhusG/l+a3j4q7TNf+63mGJ8h1tR1nhnZDVUyuxrG pmbtiBDwLXargCJ0Zu+YRuGJRwmJOok20/FlJ1nbijuamLPcZhs9apw0bZRqUNGoKNFY+EHEHxx5 E1TMIK+iYGZpxpU+/z3ne9vnWKRKpP3HK9f1ue/vyzzqGZTJX7yQ1ckgUw2N9EzVTco6h6y1UrlU P4Hp5MqeIawWmxjRaEbkPT/iOim2CrShkKg9qK9pCVesKh1/3fBIbcDjSp2pR+PUyWTOaSVudTiU QNZSJdajNCiNVhzvURh0RpsLMpJV6ls+sAdtQdxqt2/A2712G2YM2iY1RpduS71s1umB1e14yKWx G812x5YRGL5nx7BqtB1Mbuk1GpfTs4W6TDRba4Y3+KZiy+M16azm6U3P0o7V9OPajnVia2ltbfPH Vcv02pjG7B/bHtiWz6BC39fzUz96QSjzM/Pb09vb3RPz2hX/jHZ63TKg0s48X5z5d9X6yuLCiv/p 06nZxQHVU1TXO/7421fjKtVfVAOLc9+Clcw+/kH1arZX+0PFT3ODs6Oz6BqksaMXdKECJO8HVgcm AWWAdTwZbHz0rPHTZ183HlYrdlSipqmOR0AjTWAl33RUAp9XNt2v/FXpYf1VQuX9yvs30YYpCFU5 aL57afXVhCNX06sQr1dXHUUtUxnfAX4koPPe7z44dvQomupOPpqD5lSTM46gJvVqkEE1OSH9lymk H55GQEJOP/NF+rHD4qzzYCqk9EgymmUdefq38elfsMOLgdFjTqaRCYwYUmFWWloWMfV8XHhM8efZ hVlUdnwq4x+yf08Mp9KjCJl8UAKbGM7IjEmNCj/Pj4v7mhlG58bR4zj0iBh2fFwyk81mUqmZcWFE YnLy1+wTzCgq/fPf86LCEmlREXw+7ysqLTWM/VkUNSYsm0/P4rHCWFwKJYlLiWZciqbxWSwWJ5Em iougUgR8HptVQjzBzBYIoqNpJVFUsUB4glaWGP0Z96NTxOhrglOficuiy3l5ecmCs//8SdHHInF9 fXn5H8pbPjp1qqiiRowGXdWXi+88/ThPcv1UbXdb2+W69rI/tF6vrcsrutNZJ+6SXO58Kr3e2SmZ apHWdo5JFZ1DPZ2y2rofFRNdXVLZULsUIpisSDrZKQFPQSdW0z0jQ1KFpNUgezmml0p1MmxoRGmW Ap3o9J5VpWxSp6xTaJQGvQ6zySZXl8YMagnmkfXoDA6lUe2UTuKYAmuXGZQYjkuduHJ5NaibNCqd VjzgcgU9Ttw1g7lDBlwH33jUOnzDObNsWzXhBofN41rWuIFBPFKdY8tjCEr38dX9peDWpHXLiDls Lpfd7Qx6zFY3rse3PDavG1uT45oeZCZyvdy6iW1arGsazcz02pr39djqtHVJ493e0VhmvD2aBavX +9rs31mZtpgX5hdQs8iKf31hYQry1eOphfX56emZqYGV51M/DgysP9UuQsqa+R4V9GoHHmsHtONa +BpS1sDwgGr8h1eqx3MD/zk6d23u28GB2W8Hxh/M9Q4MdDSOApY3djx4AvFqsHH435CNNDZ2DDb1 fz042N/f2D9cCYj+zSM0hbSv6f6tbzp+1dd0oxSN6D08uLpfWVqZQL51r/nqzYTSGwhAqsFDShPu 3UOHvlXNzUcSHpaia5CqhzkPM76rRtW8kLGOHSWTc449BOqorr6KyhQPgb0aXZ+jKl40hRTEcgwA hFCcFk5OAzq/kRp++vxJMin8GOMkIf23t1LjGaij8MsvUwuy0uLp1Hgi+Er8SWJaFp3OTqKeTA0n ZxamUj8vjGBkZxKpSRRCEv9zEjUsvLAwJpaXRaVfSmZnZvOzKVwmO/bzFAY9M5POSKIXcJJozIKL 7OjwCH4h8WJyIYnN/yyOzWRHcARJxIvhEVwOiS1kX6Rw+Jf4fGEmi89hsktyY1l8bgq7gMLN55Rx OTRmdNhJYWHK/yXkED8TilLKSmjHBWLm2QthHwnyj4vEnP8418AT1QgrROU15aKihrK88hrBn0Ui EEf5jzWS8vJ/+kdeW3mtpEKS11rRUtvSWlvbdae8TnL8eldL7fyd9nZp19POrq4JUMKQtHUIPKPr dfvQS6lMNoTNDykUtf/eJQddTJilY/LXJtlqOzroVUjLhvRDUrlcgWFy2YhcblDo9EpMplQYR/Rq jRLDdEo1mv6G9fTocQVmc0xacQeG2WwajwGf9GjqdLjV6tB71GqwEofDAbBuV+tcmDqIuzC72ha0 ++xBtc1pluK4Ux3AjWrHrmc56NPYDUHjslkTDFo9Bt3+lsuxheMG/AC32zy6fbdaH/RYle4t+9aB zeZe3bRo8LVNp27NtCpfM7pX3TNb8h2TcWpmaWnGKt/e9L5e2l4ak+94115bNTumGc3Sjvm5Bjh9 W7P9csY/NfDjwnPQi3/q+cJL0AvQ+sJfpqf7Hz9dVD2vAEk8/37x++/HF1e+X0EthirUPfX4sWpO Ozc191g1O9g4+urJgOraQD+gR+/s7ODggwf9vYOV/c+GG0fRffqTJ8PPnj3rH/66v7+jv6Ox/zZi kcZ+yFq3Ohobm0vv30bL2NB+qbuHvem3bjVXlh6pvNlciibGNd+oBli/WZqO2m1RM0h1aULV4Y5b 1FWYA3iOSk2OHkP96OTDfvTqyIwPczLARtAuz4zDnZ5oNQL5DOq6DU8/g4bFEY6djicTzpwnp99I S0+NB+9gRDLOn8winc7KgrQVk8ZAy3EIaMR0aloWiRQennUlhp4ZF0M7n0ovYKaGnWfHEAu5EfSC z4mX4iK+So4jF3ILC0knuZl0biExiU6Khj+NYPKZVPjpaBAWN4KZHUvlMKk0LgcciE1KSU4msa8w L7KIqTR+bESyCL1PVMjmFyRyYlMT+VwSkcvjpHA4VGJYBE8ULeKnUEScXI6ohBgtyCVyhMmJZeUl F4A/ioT/fFx4XZB/QlSTXCQ+l9dw9jfnasoTWTXi8qKaWtbZ43liYd7TmiLJ0/K6dnH7qaK22qLn d4T17W117UNlktauy+VjXV0tks6x1qHuOmlnXd3QWOu/S8fGFNIRTV3d5daxTikamDsmnZSNKCRD I9KeEXmrAhtTYLJ2xchIzxCu0ysUOjmmlE/KlCapEn/ds4rrMZkOk0p/lOGvMVypUOOT8AuP9SzZ FZNBA4gFd7uUmuWQzjyyG8QxWQgHVYB0Jo3wL43PEFy2BZ2YyRx0gK5sHh/udAUDmElvty7jDqPL jjt9q5MgDFMQDwaxVRw/COrdNs+mUY9Pem0OndNmM06aIYhpbHq31bZm9Kxtacx6p9St15vda6tG z0uzVa8BG1laMm+vIXXM7JhABzvTlp2FbfO212JRaefXtdvzKzPbz83mdf/U1Lplambh+ynL05Xp mcfalXXVwPr694uqxaeLP64/nl1UDTx+9Zde1atXWpAHmmPyaq73h7lh1dyAanYOKaN3cBaMY+DZ QO9sR+/ws0a0k62/Y/hZ/+ERVmNT/5P+vsYnt1G8amoqbbp9v+/R/X9pvNXUdPdWU2nf/crKu7fS 0foDNGDx3ukE8o0b9w7nxTWjI6yEBPK9KjTRHbWk5xw5mlCNrkEON0zBRw7qkTpaDfCBsBwVLZLB PjLQ4pAjGagPnZweTj4dnx6ZTko/k3aDcJpBzjjz5WlSfBYjlRBOOE1PJRDSs8+HE9Lis7JST/73 rLS4gvMMBoOeGh7/FeNkKpEdQy0spBIu0emZ2VnUgqR40ufCi7GXstkXYwgx9MI4YgxDWBjGYNMz C6iFyYVJl7iZiRT2JWJYCrgPkV4QBS9Qo5iUAn7yJ4ncU1HEr4UXL3K4LFpEVDQzk5oYnyX+nECh sZLBM3iZTBbvs5TcAnSXnsJkpkDEKuHlJwKB5At4Zbk8iF8113IvCAQlZUQKRcTLzf1IVJFJLCoT CYuKaq411DeIeUW15ZLEE+W1DeVldQ1FLeLWvNpWSWtbW52kre7y9TugjranrXV5tZLO1jpJbVd3 eb1UOoSmlHQNDcnGwEOGFPXtQ+jWHN16jGF1CtnkmHxEMTSi6JG9GFFgciWmqENTF0xS6cREi3QV G9GDRsaUap1c5lxVeqYVakz5Gj10uBoIRK136J32IDap27At23G7yy2dXA2qMYViw6GxAoEHl4MO eHkXB0z3qaXwbFerfZgrhLusPrvP4QjuB4NOI77hOrA77C6j12gLetzW1Q29ybMH9uEMOoI2F653 Hhy4rDMez4HS7bFNHuj1Rs0WAIl+1bi2ZdLoJ4zurbVVq3nG7F4yaWa2J+anNV7v0rZpaWFn27qw Y9ZorNNaoJKXFv/Lac38tmV6e+Zl17rfsj4ztbKwYLG8XF+xDExNPQf2mF1cmBvQalcgaH0//hf4 99wUmEpv72PV49mBx/8FDKLtHZgbmPvhh4H/nFMNDl97AN8CkQCgQ9QabHz2oONu/+AwpKtnXw4P PrqNnGOwsqmjsQMApLHpFhBJU0cT6kbvu9VXeuNPdyv7bt7oa04obb5RCUh+82ZCFYQsSFdX05sP i7AA1I+gW5CEhKqch+AkR4988DDyaM7RY1WoXwp5Rc7h1oNq8uG0RXLGrQ/Jh4NL0qsBN26RM+JP x5xMT2d8caaYdDq+mJR16ySjuJjESMtihJ9OSyWR4gtOZmWlgZMQskiMr+J+n5X0NT02i51Eh7j0 dWpUIbvgShw9k8+8SM9iU+nJ2VfY1ERqEhMo/aOCOCIR8lVmAZPDSY3JJNIvfi7M4vJoNCaTc5Ed y+WnxpWwMrl0GvcBk8JmJl1k8vlcNiXlIufc14kRp5iJVCqHyxExS0o4xDhuIi2Xf40lFJwqKykp +WPeJR6f+kl5mUDEKhEKS/LK8osuiIRCXlnZ2bIGHqL0+jzWWUFNeU3RdWH5iXMNebWXxeLyNnHt 9ZaW6xLJ9bbWy9dbWypAJBVdLe3tre2SzjtoEDt4RlunRDI01A5gju4Ju5aGJBCyFNKJsddA3jKZ 7LVCMTTxumdkBIKUYmRCD/iwioFa5COHPeP6kR6FDX7NFXrdiE6p08mkI5hVjb3QKw06zK7TqUEn BmwyqLPhNnXQgKvVNrvag4MWnMvgE7htEuIU5lE7gkGA8qBHEVSDNt4Egxt2F7zkAukYnJ6QPehw uXADfG/3LbscDty2vA96c6g3Eae4lSE7boO3u71Bt+fAZrDpHShh2eCP7Pgm6q3Suz16+Zbb41nd XNXr114bN72rS2smi3XH5De9XtpZ2t7ZeW2eAYGY5se2F8b83u1tr9nvn5+fnln3r29b/PMLfsuM f2Xav77+dMWitTz/fn1KtbgypVUtQszSLi4uDoCPTKnGxx+Pv1Jp5+a0KtUs2Aj4xw9zA6M/oLOs 2eHe0QfPRnvh48nok28bh4e/Hfz2yW2QyPCj/iZgkMHGb253PHuEqk7uHl4U9t2/33h4mX4LslZT HwD6/cN+23s37iWUpjeXgolUQ8ICdaDBWKUJ4CFXv0Ogjg6xqtH6g4foFj0nMhJtKTx2eMybcSwy PR21pKcfSz9N/uLW4XxeEA7x9JHI4vTThHBy8en0+NQzNwiML7POpGWlFacy4tLoWQwyIZ2dRv2K kJpdQEhKo54nFBaevMaPIZy8Qv+KysjM+iAGoCI1hsim0wvYhex4jiC7IDO5gMouSKIVZl6MiGFw aGx6zFc8ZgyHTTkfwy/MFPPjSZl8kAElmf5B3CUWkxhPZ1JyOUDlVL6Qy+TyWRdZICku92IUEUyC w466IGQS82nMpFgBU1DBpxJ5vAtnczmCj8I/4eSXxaaU5V8oE4lErLwaMa9eKCwDBBeVCxvOUlKK BGUNZbTyinpOTe31TFFbbUV3zdlzbWKJpLam7ZPjLXWtdUW17Wg+O9o3O3YHBNEllb7sHAL0qJOg qpIhaZ2sW9oKv+R1nd3SFy+G6l6CDhSmkZHy2iXFiGIGgpV1VTmyqlACro/I0c2fUqmTK6VS6YgO UyoUOK4YsWF6QGjZmw1MKnPYljEM10ukdnUQpGVTL9vtQRuGDmtxR3BZ7bPbcLAIqzVgd9kxpyGE 4T4Xrgjh9jcbamPQ4dtzHTiCPYqgK7jsXva59oI+3OUJbOBB3GHfd9nh7cFlq9ED5uGyehx2a9B1 oPPiQd0b3Lqpww+cHg++I7EebB14N602t3PLs+be1E+sra7p3V736o5naclktniXvK9NM165d2Z+ 07u9srC9NDFvmQZON5v984u9M/6XmmmtxW+e8fu3p39cX/je/3TdYrEsrkC+mlKpANMXtaqVce3s 4tTi7Oz47PhPcwMDr34Atcz90N84qhqdBVBH+gD3GH7wYPTJM1RqgoZkDXegfYX98K9flhaCSr5u /Oabjr4bt/ubkIeU/up+3/3DLenwQDt0bt28ce8m4HlfOppsUnV4zAv4ca86gQwgklNdXXXzasLh BoSEnO+qEtB0dzS2ISPn6BHyh+SjRyNR0UkO6ioEKolM//Boxpl48kMCGmNy+gxQPDn+VjykruL0 1DOMdMLJNBLa0gEaIacXZseFkxn0+BgGIZ4eD/mKHlH4xQdxXxfGk+gFV+j0wuxUApGRmcwmxVDZ F5OYNCojmUmlsmkFyTRGRCyPxw6LoDAZsZQY+idUyiU6jcg/+cF5Xn48kXWFn8Lmc4lRYDp8WhT8 IZvJSaImgRMlguHw2dSoS0IBJYLI4lBpuVEsDuU/ODTaR8K4ML5QdJxdwuef5QhFiR9d5AiErOO0 snN5ovKSlGRhPStPJGoQlp1IKa8Qn4o+W15+4nDPeVlteXlRedtHvxG31aC63VZUUFJWW9vaBQQi qWtvRxMY2rqkABytnV09EknXxJikqP31UJ2ivQ4bksoUQ+0y+bk6uXwIOEMum1yawNCkH/mIVIrK ccFNpHJkJUqlHlBjUm7QSdsxO6ZQKxTKVcwGStHJa4cMuGxSqcNtTr3DA28LAlsr1C6wDbAMHF9W q+2QlZYVTsdGUKNQI+fAlu0Hy/Zlu3tX32PbcKw6QUWuPdyxbD1Q7zoAS1y+PV/QvrzqCOx7XD67 w+UxHmwYbJpNm91zcGA9sLsPbB6bG1+aXjMErW6bDvd4UMjaxPRyj2nT6oF85dm0Qt4CdayOGTUA 6vqX0zPeVbN30+J9bfZua/z+tb+o1sfmfzRvz8+bNQvb09PgGgsz2mmzH6QyM/095C3tzOIiQIlq cWH9cS/4iEo7NaD9UQUBa1Y73j/4Ck1bRGPf/+vVf/UO9I7+8EPv4DCabTI6MPgMKGRwdnj02eBg x5MHo41NHcODjYMddwdBIIP9TY9uA3/c7uhDuxDQQujKJmQfIAjwjxuQr24cDldES9iqSq/e/KWk F1UoojOsqlIQyNEcNHUUHfUmZHz33QcPHx7NOXYkozrj4dGjZDCLYxnVOZHV5Kpq1KZ+BG2FRn23 1eRbZ9LPfHHmcA/C4ZR3QgyjmJFefPIMITWV9Nsv6YxwQva1VAIp7TyJUchILWCnMuLD6b8HR4ll X0yj8wvZ2bzCaCKVWshLojLYRDaTXUCkZybFs+nUB8AO5Nhr4n+NIWZmptK49BRgEXo04TPeJVos m5lLSRJeYfKEnxOp9BS+kJYYy4q9xGExqZdESVQWJeWaiHMxLKlCnEhM5HOIJfwUloiVQiNG8wRl eSklnLy8fLFIdE2cmZLLyhOKWRculLBEovqSXJEwL1eUV1QhKD9xnNctPnuqTFyfJ6wpK6+pLar/ +GyF+HpdEdooKL7T2nrnTkOtpK7uzp06STtYyUsIWU+7gNN7OifmhySXu/7fkbp2qVzR3rXUIxuB hFUrnRhRvJYuQXiST8jGJuQQoiZlE/JJdA+oVI8oJnU6EMik7oVO3W6e+KtSo8Acxtf4iFOnwzxY +/ILIIhVu2tZbTDY8A2HEcNQwHI60a24K4h58CCmtjkdEJo0xo2/7lk99l2ncte2FwpCwtL4Nnzv XK4AyGHD4TNs4M4D115oI7i87FO7Aq7gPmIOm8u54YC3e968cVqdwaDRhh/sgxzVRlPQYNt3b9kO 9rcM+i2HYW3T7XbqDatGt8fq2YKQtbO2Y1q1boKRbE57X8hNM6a1HfPOkgacxKwB6xjzbgKoa0zb 3dvbYwsvLRazeWFhxmLxW/x+CFmLT1e0/mnLT98vTg28+mldpZoa106hEhQA9KnegfFXWq3qL/D5 w/jc3Pg42hcy++raQK9qeHj2MGQdVioOX3sCZP7kfzzpQKPeO9AMh+GOjsbKxm8O90GDs4BM0PBq tELn9q0+gPO+u31gHTduoL05927eq0xIuPondHZ1FQzkl2OsqiMJV9F14XeoEOu7qu8+/A6dYh3N yUHL1zIe5hweWpEzEsjoljAdnewSUG0vuhSJPJ0eSUgjkItRPW8xGAnjRjqpOJyQSk5PJWRlxTC+ Sk397ZfZDATubDohKzmrkBienpT1FSM+DmyF9CWdzM6mEtnxUef/gRZDYhawqRfjCNS4GDolmp9J vUSjs5P5vIuUTEpiJjuCK2ByqWFETgGNEUe/SCMSk+mEkmQqnUVM5BYwo6klnKSLtNiIpNhoGpsq 5FA5ELR4Al5KYQkthZ9L5Am5ouMRFBEnj85m5bJiaQLKP6J5iWWxLF5+PpHFq+fk1VOO/+cJCrCH uJxVXvtnnriihtXQUFRfU8ZqE9fUnP24vFUiOVcLAPLn622Xi9paa1vai9rbnrcXtRxuuqmtHaqV SNtbuxGR94x0d4+0d6HhoT2tE2NjsrpaWdckJgVZKHqWADMmMOmqQqockymkMp0SftulUqVUoZwc cWAyF+aUg4ko0AxEnWnEEMQhcul0y2rgdLVnUheUqg3LkK4mg7gdaAQMxOVSAECrXU58V233uZYd DoNdHbItBwNG/UbA4dJgAaANj8vl8zh3fZvvDXsun9oTCr53owt0F7z9QG10uZwO3GN37bscBodt K2hzBm2TELxwz4wVEhfm9jgPrEa9x7ymN3oONjfXtrZM8OSxur0zbq/ZajTpdzQ77k3rmHzNu73j NS15LQtjO0vmKf+ORjMzYwatrMxbtPPbgCLTlnW/f+rHdf+MZUY7BQ/LtLbNr52xTD8fX3g6tbgI mK6aHf/+1eJA72MQyLBKpXo8gJpwfxiFaDU4+wCehudAHqrBbwcGBwd6+x+ASMBXnj170vFouGPw dmPHN/8GIFLZ8QjN/GlsbOrruFXZdLuprxHt8WwCSL97rw/dhfSVNleWpt9EG0Kar169mX6ojuqE jKsAIkdy0A6dHATpORlVR7G8cj0AACAASURBVHOqPsiJzAGJHH2I6rHgSwTraB/b/+4mjDyWnkG+ kZ6QnhYZ+UU64XQzmZwG9A6yIMcQGGloqVRxKolM+CqNFB/PIJHY8eGk1NTzV8LDGfTswgICAVyC SyEUcD+MvhZHL6CSTmbGkwh0NoHIjirMzGRlFiZeZEQQmcz4WJBBHIcYRk1k8/PDw5KYfC6TQGQl /o5Pj+CLwijXPmYzqdGFmfHEiCRaRCwtjisCJC9MuUQkflzChKDGIrLziSTKxywB94MojkgoYkYk laWIBCeoQh4hX5xbkp9CFXA/SiTW50XloekNDeWoQvFEblGD6ERRUdEJUcNHvykqaxDzwvKu14hb RcevN9Q+bSvK7xL+pq1C0tpSe7mipbao6KXkcnsdhK3OoTuopESimAe1KKSHd4NoOWDrH6SysbER ae2IQjE2Bg7TKZGPKEZeH45/Q7KQYi+VevmIUg5hSwoZCqKWGpvUKXsgRuGO1mmZzYEHFVI7pnQg ucgmN+xqndqKOTDF5KpPYQQCwfFgcHfZpVY47QGPGn75lwMujdPlcrzVmGx2w24AmGTZ/tZuxN++ dr5x+QIut33X4zba3lmdPiyAh4KB0L7LY3Xa37tBLp6DoMfkAaGEZuDtjqDdZLVDOls14bjfbQBo t5p0a16NedVjNnq8a7q1g7Uto1szs7nlMVm9br93Z8Zi0njHdlSWnZ2xpe0pv9e8MzYzPbb+eHvM vP3SMr3+Ujs99dI8ZVlZWV9/6V9fsQCcT6OydwuYhf8/IWGtjC82qhZfjS/ODj7Wql69GvjP8dHB uVcqNBbr1ewgpKpekAUkq9FZyFjDg4ODaDYWGiA3jIpMhp/d/7SxH3j9bmU/mMejvru371fevtXU gUoV0bqcu5VoINb9G0AgkLGqSitRGdbhEs8jwOTV9xKOQuSqbs458h0yjyMPq3OOoqpFdMybg1IW +Rga1ZCR8Ut3OpjHkWPVqCMdLAUR+5lbaEH0yTPkY2lfnkmLP00mZzHOZJEZxRCq4gnxxYXx4ZGM gpP0tOIYOulkIZ1AjimgX8mKYZMIBSfD4n7PpyYVZPMLI8h8XmZhEjsqlX8ps5BYQCde5BCJ7K/4 REIYM5nDLIinJxELkykxEdQrTH5SLCsmmksnfHKNR8nM5Au4hCihgJtfwIqiCzjJhbEcemJuPpGS xBYSwyK4vJJzHCKHmcLnU4jRSSKR4BNmXtTHPFoUX9zAEvGENaIwWoVQUF5SklhSIxKe44jyLhQJ Ys8VicQfR38kRANFTzTkXxbXlJ040VBT05Z/XXKqVlx0qqK79Xrr0zt3Wn5TM9HW2dnSUtvZ1dnV 3tpaJ5V21QKSd0ny6sZGZLKhOlmrYqxLKmmXycb0aB8tNtbTLn+hhO8mcFk9xCmdUqmQynUj8skR 5SSmHJEqMXxEKnmN2202mQIwHbdNSiF9AavbMZMtaJIZDC6dHjfgWDv+JhSw2zGjA/QBf9k7XQG7 1bbnsJmktt1AwK72BNH5rXXSGQo6QsqgxxgITto2/ubCQ46NXbfmbxuhnwN2z/KGD73d5dwLbHls +waPSWPftfvsbpvNHXQcWDWeoM6x5rF5jcED05rB4dGt4Q7djMbg0NkPtjRWfEu/6oV45d7SeN2b cvO0ZWdta8c683rbtIRWRWt25pf8L73T5p0Z7Xr3knl9G81wWOmeX98GC/Ev+J/OLPoBR56qtCAW Va/q+6criysDyEFeTQ0MaBdffT87p+1VvQJZgFjmfnj1arbxCWQtJJTRudEHAOegFDQca/hZY1/H kyfA6E3DKGM19jX199/+t6Z+ePnRv/Td/qaj4/6j249u/Or+N7fu34Vwdf/+jZuAH6WoYQqiVnrC kdJ7lemVpQloSUgz2i31HSikNOEIWlEItJ6BWm6PgT4gXkUCqMOX1VfJvxSakA9XemZUn04/gvbe HkH3IeSMq1+ejqz+4uSZL86jE6vwdEIk6TQD5IIuPcA8irOzCxgxVwqzsgriCEQ6iZHFPRkeQSWS w8NT6anE1C+vscOyBNnZfN6lGCI1gh4REUehcehJyR8V0AqJBLpAwI2j87lcZgk7gk0jUjJ5cWHE FGpYWNjFFCo1liekfJp5Lfn3AgEtmp4YzY4g0ZmsfAqHn8LhcInRnGsCfuzvBPn8knwakUW7yBQJ iVGJFxLDoiPyWCdSPhGLadECMe+aWPwfx/OAR45/zKkvb2ABpJeDNP5JUCGuOSGsQE1RRackRfXX W9tOnS3qKfv1b/5QVyepvd7dJbp8p7vtTneXpLb93+uuX657PjTU2d7VJe2UdUp6gNNH6sbkspER tB9Nqpgf00vaFZM9tZIe+Jvf1PVCL5UaJsYmDPpJhVWKDfUoZEqbDtOPqJV2mXRy4gWuU8BvYlBn U7xWY8s6XN8ziS1LzT1GtdOJ6d8ETasbBrlhI4B5lif3XpvUSqBt267d7gvYrMsbGw776tvdUCDg cyt9yy58127y7O1takzL7/bU+7tv7EbbG4fBsOFzq/eNe6+NBzZf4MC+C6AeWN08MGyElFuOUNAe BFA/cB/odlfN1n232Wx27rvdbrkBcpZhTS53eDTWTZPbb/ZinjXvjt67s7rqt+zI9Wuabf3O0s6O xgJG411YW9FaTJapqSn4L1j8C2MrU+tj6wsLC2atZXp6ZXZqBVAEWH36+fPFWdXiT+vfzz4fX4SP 2QHtFKp2H+4dmBr4drBXpQIuH381DFp5dg2B+gB4RsfgMCD64OgTdI7V2Pjkm2dPGq88ezT8qL/x LirDuv2osq+psbL000rAj74b3wCg3/7i/hd/ug+gXlrZ/Kvm5r7ie8337jVX3mtOqLp682p1wj1I V9WlCQ+B1TMOi3gTjoBvgGJyEj7IQD23QCEZGdUfAqdHVqMG9atodFxzNVA64Wbk4di4SDKhOT0y koGGvhcf+1VaGipBSf0yHhXzxhP+5avzWV9nx5MJJ8+TIuPPg06yvmJnpcaHnf+axEi6VEAkMBIh V5EyqTEESlw4KbmQFJVFZAni4q8wmXHEr1h87jU+NSIqm0sKo2QL+FwOjcOkEkn8bCKFyckkkti5 KTRCbDY7IppJ/T+oAlZU3OeJXGEsJZ9TEkvNLRHwxfzj0bG8ooiIQv41AdrdwTpBPX7ts4ucEpEo kcgqK6NFnBPlRSeKEiPOCouO/8O5CzU1H+UL6htO5BVdF4srhCd+XSRuOP5PDagNvUVS01B7VnSn vKilpbWmrKilrr32D+LWurx/b738h9ax9qKa5z2gk875oc66HkXXmHxivk7S2a0o6unqnpCPyFYh XdUNvZCCBkZkPVKIUNIeoI86hbKnZ0SueC57bTTopMhONJgax19sKDUmpQNrt+oNBhx3gU1gUt2G 0WO3B8BnXGqfZhJXYlK13TSJh7DXOrXrjR2DX2ebe9nn2N3YcFmN+K4T/hMbht3Qu0BA7TKGNsBh AiG10bbnemf17Lo8Rp9r0ukIuHeCB76/uQBIggfOPZ8jtGFwTjrxkNFkO+xid4E3uTdxHCRkD4Kf AIiY3Xq3ybRltRjlW6aXq5s23Pt6bXVLYzKu6tcm1kwWzdqOZXp7Tb62tGPd2TZbLGPbFqCSbcu0 36SZmfJvz0xNb2sHLAszU39ZtKzPaxdf+sFFLM/X1386LFVc6R1YHF8YX1yxgJMMqMYfq7R/mZsb 6AVmHx6cG1V92zs62Dj7YKB/eHjgwdzg8Cias9j77Nmza08am/qfDfY1PnqGprsPAp/3dXzT1NjR 33+3EuCjEWzjLsjibmlp0y0AD4hbN0pvoGLe0sqrN27eRINGr5YeSaj+ZXTcd2AdVVfRxLiqhCMI RI4eRUMbjmXkHN4SfgcmApwOUQueI3MyyKVoAUIVOf70mTMZQOenCelnyJ+Gf8o4Q4CUlXY+vjj7 i2MxaWlZqaTULFJaEpUejwoUwwmkLDqJRKXT2WnouOpKIe9KDJsdWxiXVUilxlAzmfGZmTQun510 7fMP6AXcTHYiOzOaw6Ux49jcLEJENFALkZpyicXMotESOSKuuCSKyUr6jJ7JTIyNpogyiXxuHk/0 R674ZBiTxc+n0QDok0V5v4vl8CkR0dRcUVIi5UJZSX4SJy+XxyuvKImtP1ciYvFL8mgflwnzaTW8 +hrhn4V3/iG6XCQuLyor552tuV4uymsQso6fvSCpKUJrOFtqylsktW1tbd119a0gk+udh1s2u1qv 3xkaGuuUdk+cq+0a6lZAzGptHYN8JR0ZqauVojMs6SQmU8paZZMKuU5uUAwpZZC/9FZAdiUuW5Ur dQa788WLHxU6pUGNefSyVVxpW8VwHXpjEJBk2WULKldtTqUDNzgwm10ZVNp2nWqjJxDyBB2uXcN7 1xtHjzoUcLxb9oXUQYcvoHTtBie9zuWQ3aPe8/kCdptvL7gberOr9gV8IZsdgMXp+jm0v7v7btfx zvcGN9t8oZDLZQu5A7su++pByKbZNO4HXW7nPrjK1hYQOx40BL0225Z91QaaMbmDW5v6tQNc77a9 mJ92r+q3rJs7S6a1NfeO5vWaZnrGrFnSmM2b1tev/dsa8/zSTrfXsu31b/vXX5otWvP8S8vCtn9h 27zePafyrywsWiyLr6bW/SsrU4vfQ6ZSobsQlVa78heIWKpXQCPaYe3s3Cw8VL3otnD41SyacfLD tY5vR4efIT4fHnwG+Wpw+EljXyMa+ANPg/0ddw9HkKINIR13O+7evdXXVFl5937xvVtNd2/dqLz1 J5Sr0OJndIFe2Uwura5OOIJmx4EeDiveDw+w0Ow4VO5e9cvoUfCQI0ePJICLkBMgY1VBvDp2BDWn V59OO7xZP0NATYU3zpz8lFBcDK/F3CpGm23jGeGEtLTzqQQCiUBi0LMK2YyCOBIDFbsT2FkUekEy n84gxp/kx1EzC7gcfjaVTqMUZkYlcalxsRcvMrMIdFY2l06M+iqCSuNw+cxT3DgiJZVGi4jicFhJ XCHvBDuW+LmAmiLi8PMFyRcvsS4lc4lc/kU6JZeWmRXBZAlEKVRiSlRuGZcnALuIpdCI55KiPxKV cM41iAUXmJQUnjClTMAXCMSiC0WiIvh5geAsB0TA+ySxPF/ccOHU2bwT9Q3A5eXXa1hF9XktRSeK Wluut7TdeSopR3vVap8DenTded4uHWrtQmuh2lukplZkGkPdnT3tPT11CtnI2JhiZASNYAD0GBqR vR6RvxhRvH45JB8zjej0OrRBUKkEgbzGlQDjTqVOqgiOGJSTaOyC2q534Mu4TaHGMLtCowyCJhyA 5kpMadA58cBuyGBYdvl8wV2lzeFS21x79uCkOhAw+DzYMrb8LoC/Db3btTtdHmAJtz3w3hfa2PC5 bMu+DfvebuDtz4a3ey54cfcA3ae7XHvBoNEV3HW49t371n1fILQbdIUOPC7gEKPVDjgUNDggablt Bve+3q4POvROz8GBTue16Y1WiFxbVvOOW7+2uWmGf9w7SCNb4BWWHa9lZmfHu70kX9P4Z8zrY5bN he35eRCFxutf39ZurwOkm1e2tVPPV9r801rttMqy8vz7dcvic1CGavFx7+PD46zxV9rZWdUPrwa0 rxbnfhifVc2CUkaH50Z7hwcGkHmMDj9AlD4IaWv42bPBfxtGrSDDoAhUsvjom/7G+02NCNBvPbr1 6HZT091DaaAbdDS3urT03r37lahDqrS5+h5ErfTmBHQPkpCD7kKqq69WJSQkPARAR1WLGeii8GjG w5zDs97IhxnVkdXkHGD1dECUUnRbeJVcFZlzjFBceroYTTf5FC2ALiaQ026lhhOy4knFqYT0glug kFRCcRaj4HxaYVZqFoOenZVKp9OpqVnZ1FQSISzrErWQnRqbmUklsqlUNvFfs7NjI6jZbCqFRqJz mfRo4sUoeiEN6INfwOYkFvKYVNqlUymxmclsanREBDePzaVR2fzMRPqpiyksagovmR6dxKelsC5F M/mFJ4gpucRTJSxeSb6wIC//hEiYRykr41yg8USs3OPRVEEZp7yMdk4oys0ru1BWdKJMzDuc01Am Kvq1oEZUdqKs7Gx5Q4O4oUZc1NBS1FrxuP46uEd5W42ktiyvqLOnpbNO0npHWlcnrZM+lwzd6ZRI OjulPZ3S2q6xoZ72SfCNoS65bKxbKpMp5HLFkGwVmxySyyYne3qGdM6RkdeoGtGKYUYMmxwxjGgU +AjmGTEqcFxpVSwrMLtSh5o7MLtNCTiutNldyyO7SqfRZLIFloNBD+hlT+1yLbvUzl2H3bjssC/7 7M7VXdzl9Ox5lkOuXcd7R8gVcPk24NP33uUK/k/fntNoDPx9b/e92ra7u+fy7e35lvcduza3y+Hb 9/mcWyAL9PaDgA0PofIsVM1l99h8rn0P/D+dxs1NnQvI372ltxvdHrfzYNOIr1nNbp3buOox7+hX N/2bmxrr6s7a0uqY1bpj2tFb/Var16RZ3/GbLYDvm5od/4x/ftti9sNj2rLw0jKFjrD8FpV//bl2 SmuZWllcXF/8fh2IHYShBQOBV18tAnz0DqP2QtXA6KvZAfhWNds7+wPSxij8SW/H6DPgcpAIYAhq vP22t3/w9hM0uAEoBKykqa8SWP1+BzrqBRBBE38qb9y611wK6aq5uLLqxr1f7gXvoXFY99JBGaWo TrH00D6q0P7OSPjql6kmOShfgQYAQHJQH2E18pH09HS0DaG0mkxA3yAXKT6dnnHm1ul0AoOUnkYm ZZ1MJ6d9WUxISz1NP59GSmWTw6n/wkg7X0hN+7yw8EoBg5rFprPjCiBonadSU6MKObHE5GxaHL0w NokTxeZfoRL5/MRYJpvC5bO+onMIEbmJl1jJIjASEZ9fAvAOsYr2b5/QOIWxfyTGijh0Ck/EvMjk UjglRI6gJJEi4H9MK6GxeLwLJy59FkFk5ZYBi1zgiwTA+rmc/LISDkcEQSv/RN4JVkM5CEQguiAS 5ZWXf9QgFp3NFwvO1pefK6+pqS8rF/1jXn1tw3U04adGLBa31LbAx/WW1ustNa2Susstba0gkM7W us7W9vkhCagCiENWhwb4oImhstZa6SSYSLcMGxuTy0EYshFs5DXwB2SrSUyq1CsV+gmd0qobwfBV UAU2qXuhttqVqzqHzokFsR6102XHDTYbjqMqKbXd7rKrg3a7Xa9cXsYCITu6ELSpQzZbSK3e2HVh uxt76vd2V8gR2HOFMKtvz/d+9y187jreAncHAu8CvkAQnMG2pz4I7fr2374NvPOFXO9Dat/Gz66D XWQoNni7z+UKbBrfgVzAToKhEO4IHrjsPpvNZre57DoPEHpQ53Hjept7ywb+4t1ybBlf4+AjB1b3 mt696d6ymN2HJrK5tLS2NrZjsu5Yrdve117v6+0Zk8UPSOJfmN82v9w2b7+c3l7wT68soDaRFf/6 umV6ZXFgymJZAYlYvkcfi6AXkMjcX7TauTlQxeyruYG5V3OzA3OjA3OzqLVwcPbBKBppPftsFDJW f9OhRp49Gnxy+8nXt9FWNlRu0gEf94HQOx7dRfMaGvuAQ+6jkve+5hvw2QcaQQNN+koT0OgfkEjp vep7qFbxu9Kq737ZEIIAvQpNNkHHvOAfD3Myrn54NIOMLkISyB9mQKrKAGFkpN84gwb0ph92hqT/ Kv1MKsji9Kdp8YDq6Z+SslLJhPiviuMZX2Vd+5KQVQg6oVMLC+lZ7ALGxWxUmcvnZxYWsguiSEQG O4Z5hUmN47KpXDohjh1HZCdfjIinsGLpl5jciuRUUTaVzbmUwv+MyWR9dpHF47BFPIEgmSu6dC4q OpZOI3JFnFgaj5LLuxhBY8UCndCj45hlF1kgjDvZHwtE/8zML7sgFHFKSkRn0TGuoOaamCfglYmO f/QJM48maBCdENXQ6oW5x88VXchruH7qo1PltedEkoaK7v8TCP3PDWAbFUgXNbWtbShi3bnT2dba 3noZGcr1ts6XaL7PUFdtbau0vacLDXyTKaRD2MiLF61DchCLEpNNyBBwYHo5NiKfmJjQyW2rMqli aFWqlOvUUlw/GdSbhpQQsXA7sLt9WQYk/OaFzA4wYgdNGGx2O67ec+Bq3LCx4cB3gS4mV1d9mB3+ tlfv4su7QUB3lxo8wIrZ3iOz2P3rhifwdtn1sw/o4j1wue/dW3CUjY2Nt7u7f//5wOmyvfMEHGAq b4N7Dp/R5QPIcLiMHp8P3u7b/avDHdrddwXf7TlCqIHkwOewH4Qc6LQgeGC3ej2rB9Zg0GY8wN0e 3G12e4ybW2tes2bVY3V7tvQvlrxrSybrqtU9trPj3tnZ3Bnb9q6NjY3tLOxsbk9P+/3mmZ11r8W/ gB5Ti35UzaudWvHPQNjyL/y0qF1HqrCsjK+gYyzt4jiKWOPjc68Wp+Z6B2ZRR/qctnf0h97ZB4OD aDzW3Ozgt4OzvZC2Zq9d6+9/NtwBLNL/DM3E6m989KSj/zaaOgq0DpTed/dfmtA83vv3gUJKS/sq gdn7StFFOtp98KebVZVX0UUIwAg8H3akw+fV6urvUDfIEfCPI///PQga3fBhzlFywsOEY1UZ5ARU 9R5JzkiIrD59+kY6OaMSnftWZUSmx5RGMr4gpKcVpxNIqYzzaZ/+ipBGJ5AJMV9mxxA+T6WnRvwr nR2TWkBPJbEZEcSCK9nZKFRFUYnhqSQSm0YifZ1MZGdSYqmJNI6AGU0gcjikaEasQBAdJ6JcSiTS WBxiCvePcVRWbBSbyxeIWPQU1vEUahg1mspkQV4SUTkiGp2emycScogR7PyS6LjYT8QCIlPEKkuk 5JWUJJbxWBdpJZRETrlQyCvKzSuiXPg4OjfxlKjseJ5YdKJBUJaXV1ZfIxalJNYLy399Ko93R3hC cL1cklckaWnJqxNLUNIqaulsu9PaXtfTUlt3+bLkct1QT5G0e0giQ5uipIruMXRJONJZ297S9WK+ bkz2GmtXYEo0ykohxUAVSjk+MYJhHkyB9UgnpZjSKFW+WMWC8BrmsUGS0ihcuNqMyQwbSoUDwGJS 7bOrMVRoZVdiaju6HQcpqJeXpU4j5rMvWwMbatcuvLb87v1GaN+IgSEY1eq3b1yrbyFdOd+9D7gg ULnUAZ/a9fPuhgNVmgBwbC4vO31/d3p237p8u+gFeHvAadwPBNzugwPDhnMrBKpxg1zcrhBgic/j PgjijpDN43Ghs16IWraDzU1cbz3QgyrcB3Z8y2Q2bm2ZTRrrhN68s2V1+zVG944ZVZr4rZoV7w54 iddv8qKzXohaXtOUeWHb4l03o6KT9QX/FCgEYcfiT0+nXiFM1wKcqCxA6doVAA50XYiAXaVCB7sD c6pB1fhsr3YU7WNTPXgw8G3H8OhwY0f/kwdPGp/0Dg42/u9mwsbG/o6mpsFHw7chZDU2NjV9igYq 3u1rvnu77xBBKlG5+6dVVX33ADtKr96sTrjX3Iyq35tRW2FVTikqcq8+XOEJ8SrnKEStDzKOorPd SHR0BVnrKPnDo8cA1sFMqo5lVKHlt2gAECE9IT2efCY+nZR2porAKI6MYRAqGZGRaF9ODOG3X9MJ H8QzSCCTwuzwmNTz8eFp7NQI0AgpIpXKLqBmpRAKMxOzkyi0rzMj6FfiCAWXiHQmOSzrMw4tkSgU MCPCk9jECGKcMDuCmsiPCuPQqEQWlRhNTKQwObGZf4wScWl8Josj+DyaKYqN5nJi/8gMi+CISliU FLGAExFWxjpOBJn892haiiA6qj7vI0pZynEgHJaohNZwIVYoKoFHufh3H4uEH59oKDpbfy46lne9 oT6v6M61ouPHG+pPnD1Vfic/r6i27dd5rZKiWslldJbV0tpa2ykp72ptbWuVtnUDlnfVtndJ24dA RvNdQ0PtQy/GpJfrZNL29vaRF+3gFWOXXypBIAoNaEiBtqHpJufxVb1eqZQbFIqgTvo6iEC8TqbH XUpM/wbH6rDDanfHhgZUoe9RBtVW1zJmhV99e8Ble28ErsZxu89hMKp/tk/aA2pXwCq17YZ8vmXH m5BH6vKpjR712w2jem9XNwn84fTt78Pvtivwsyvwd+furuttyPfesOv0/U+bM/jetRfY9PpCPwNp bGwEjBqfy2P0eDZw4/7+7o7JDupwOd1GUI7N7g7ub4KN4LYDm2PNdBBEQjE6VwHEdVtb1k2DftVi OfCaQBMTO5ZNk94ClG42w8My4/fvAMibVpa2NfPbGpSs/PPT2m2/xT8z8Pj5Nio9+Wl9ZUA1Y1FN qVZ+AmFox3sH/NOqKS3iDZV2DphdNfxKO/dqdnbu1XDv7Nxg75yqd3a4CShkeGBw+NroYNNd8IyO xicP7oJCnlR29A82daAKk6a7kLLudvTdeNR4H20nRMsK75ZWglCaShOab4BQSu/96V7pkdJmYPOE 6ps5CVXfVR9JaK46XEp45JdT3qqcBLQGGp1igVAyMh4ePfbwcJtn9bEjRzNOwyfYBWKPanJVcXX6 STT954v45uIzX4KzxJ9hpBWTfhtPIKUhOmecz0ojpMal0uNI7C8/JZA/zw4Pp1OphZnsr9hJRCLn q2welZ9JvHaJzkrmkQnEQiaQRC4PEJ0ZQ6VFZyZnFhJzL9GZNGpydnR0hCAffvfpND6XxWJyiOz8 FIGAIuRSxCwaR8gPi/6Yzynh53KEpz7mcIi0XCqfl885XsY6VUKjCT5LJP6jOD/suCi3BDV7iESx JbwL4msXxCJ+RVlRfUVy9MdlQpFQUNQgzstryP+oqOysuOa6KE9SX369qLaiIe9s3p2G6KLW2taK 1vb21tbLrZ3t3W0t3S1d3e1DQy+u50mkXZ1d89KxLrQ5rU4hlXajVQaYQraqeD2h6AHBDF0eUk6O yEfUyhEluup4odNNYC/kmM32Rto+aZfbcN2yQY85g5jChQGSBzFwCZ0dsxsw46RuQ2G22ZZ3HUEX KmoP2fENu8Ow/Ab4My8zFgAAIABJREFUO/Rm0rQc3A04fHsbwb13IbXn3XLw7W5A/e69K+Bzhd4u O52Ot1ZrACIWEEcAFLDr293wAbK8Cbx7DwIy7ocCIce7dxuA6CHPwTtnwBEKON/59oK+g1DI6d40 hDTe4LLLgbtcoI6t4L7D4XEE3RtbB2jctcmNNrW5IWqBeWg23aa1ta1VjdsN0LG5tgOqkO9Mzexs WteWvN7tHfP2jmlswT+2vd3t13i7t1XTlnn/9rp5e8Fi8T+fWrFo15/6F7Vmy8pz7fT6ikqlWtAO omp38A7t4uLA4uLs+A+z46M/vJrVzo4/GQSFjCIQeTbQOzoMtjL44NkwGho3PNwx+Ky/sfHuNx2g kMbDSdb9HX2AIbf7799uuv2o6W7jN2jVwX1U637/BtrBVtUH39+7V4om8zZXNV9NSEgovZpztOqw 5RaReg6aPfow47uc6ozDnnTQxhFU4p7wEOmiCiRy8/SxyCqAkYwjkTduIRg5k04uzjjzBZlMOEM6 zSCd/Pq3p0lf//63qWnhn5I+TctKZ6BhcVQCoYDOZhJirl0B5GCk0knh8bwHRHpBAe8ktYDE45Pi 6VcozEspPDGPzhaL+eyCCCKVmFnC4JwjsljsKEYJi1MSllTBIVJSKLGsqDA2GsJzjiukszlxQh5o TcQSsS5cq+DlllRU8Ms+iU6MTeSXJIpKKGVlp4g0UR6vKIx/hxObl3fhVBkx+lxF+dl6Ubn4LKfk d228Eym88iJhUXnFHeGfa7rvCBrO/absVJm4Ia+mvOy6pP4sr0Uibj9e0V1+WVJXW9d+6g+tEy11 4B13JNKW1olWiaSrU9olXXrxokuKxpSMtKOh02My6djQkAyT1o0sYXJFueHFpALDFKtYXY/8DZq6 LgdtKPQvlAqFXKnEnfibFzrnxl9fKHEF/JzSgY3gSpfdhU2CSeDY0JsNp3rZhfnUGszwZtkVCBjw 5YDTsKH2qB0A3Xtv/7rhe/cGngKY07Uc2FUHAcrfv1N7dt+/33Uq//o/l13v3h349q22v/1tzxf4 GX46sP+3jf0D3+67UODd2zcb73xv/up4F3Q6D/ZDIXSz8t635/aEfMHApu1N0Hng2vf43JqtjV0n 8JDB47G5DbjRuBX06A4OHBu4e+vFxtrBjnkTFS9q1rY2V91G8/aWe809vfPCa/JuavybluntCchb OztjZq/f371jsWxva9ZN/u5uIHV4erkyZdFa1v3a9RWtf8WiWly0PF3pHT/0EXgM9M6hLyFnqdAY 67mB4R/mVHNooDUIZHx8dnSwo3ew99lw/+hhtWIjCOXJYN+zZ+gWBAylsu/RN4130YV6Xwcg+uH6 g6b78NWfmipvfXOr7x5QRynIpPkeqlYszUlvbk5PyLl5FV2DoGk/OdXopjADHfPmZFQnfBCJjngz 0Nw4eIBAjh07ffVINQgiMjIjHV2rw5fN1eQbkRmEjGJCFTmd8cUXpyPjTxPAPtLSstJ+ywiPKWAQ ztMJbDYhjE2Kf/DbT7MFhexUIpXLJhyJ4Rf8KzvuKw6BejGeSSQRKdk8Xhohk06MpWd+xuVy+ewI tohO5bOIXGZEVB7xc3Fm9DWh6BQgCo8VceQfBJwUTiwzP4JCi+UmEhNZvGvC2GgRJZZySiTiA8RT os/xKBQhiyLKi6aUUHkVzMSKa+V5lLMlwnNhH/BrSljlNJEouuzs70QnTlwQicXilBPCvFNlIqGw pkEsPvWbhpoykbg+v1X06/K6sxXdReUTFU8ltbVP2+qioyvutNd11g21FrWDUCSS9s7u7rHa6109 PdKurq6xpe4xCFZjUtnYZKdeKgFgn3gB+pkYmVRM6vWKotoJObaqxHQyqVoxsgp6CL54IUd9URim w3FH0KCfxPCgUR/C7AAkgB5vNoz4G4N9Wb3sCGASxUZoz253/bzqcTlDLo/6HYA3PhmEiLUX2t19 +/NG0Gh7G1x++7M69LPH/d5lf/PW+fbNW6Dxd28Dzp6ljZ/33gO4u13v1Lt7Hnhx4292967vwPUO 3r4bems32nZ9+w6fJxQ0un1OHahjYwN+0nOwazNNLRl8+7YDV1DjOXDb3JtgHA6HVaNH4WttTWfT 663mVb13U+/2bu1YXrrNS4Zt84R+adNver22PTWwvuY1bZut26j3dttisWgWxhZAE4Ag/vVt+Ac4 /fn69Mq6RftyZQDwY/ynKe1PYB5T6NLw28bDxnSVdrRXpRoFMB8YfTX+YLB/rvewVvHZ7INngx2j TwaHRwf7nww2PRps/OZB46NryEgaHz1q/FXz7UdoL3RHU2Vj31104Hv3T7fvl967i8D8xo379+7f qyq9l151715V872EHGCPq1chaKFVnmiLztGj1d8lPKw6hJAjVTloT/rRnF+I/WF1Rk7OsSPV6ajn tjkjo/R0enEk0Ehz+un0W+nhNyLJleTiVBKBwCCnkz4lk1PTvsgCVE9lpMb/ayqbQM9mk1JJUZnZ lJO/ZRcwqOzsws8jwoHQmVfYAnoql0BNoTI5bGISM5pNJ0bHM6/wCtGqZlYcLZfNieLymImxRLZA QDvHZXIoNC5PlBkRBhiRL8q7lkgRRZzIpZSUnKKWlBHzKFRiYglfyEnMZbFKUvIusM7FCoScE7nE c9eEeTxRvehsmUAoFEUQTxXBF/UVKSW8xKKysobysrOC+hO1ZadO5DXUVIjO1tbXNpRJaiXlReK2 8vqiszUVFRJxa2uNpL2toq3l17WSVmlXW+ed2s7WWmk7hCopAAgEq7o6qUzePdQO7CCDfLU6NDQh H1IopHKQhHxkZBVTyuUTWC26GpTrcPmkXmZVY2pciWFBNFFXoVDbDQYMAwRXotZxTIc6aTHMYcBd jmDAtmc3OBzL7S7AZkdgI+h0rKrfqX0h37LtZzCIZY/HF9hwIKt4D5/vAp6fIUZBKvrbRiDg+DkE nrHx1uHUvPP9/ee379/49t569uBHQ+/2gu89796BQ7z/GRgf3vp3+D/svXeH3gYOXE6b460rGPKF Dt4FHXhwU7PvcgXxgw23Ezcd7LvtgOlrB5sH7k3vpk3n2Np0A6yjp1UNOu31mnfkeu/SknvH5F1a W9qZsmi83p2l7TGzZl0LkLK9bbasb4JaLFo0CGjRgsZaa+FpUbs+voLuCMfXp7/3ryxOWb5/9b12 cGBKi+4IxwfmkEZUACQAIIOzqMx99sEPELFQQwiASH//M9Q21fjkmyeDjx71A63fvvKo41eNaDBW /6NHffeL0RXIfRDJ3b5KtFWq78b9m6UglGYwkeZK1IsOmSrn3lW0+wDNMqmubj5yFHnJd5Cxcr5D 9yD/63/9P//3/7j536r/27FjqCCxOgONez+C6nkTDtekR0YmIIWQyBln4ovPxJDJ8cUExkkG6f9r 733A0rrzfP92ZnxmN9vF7HNvGzZm+mfbMWk6k5mqMdZ0k+neFdQYnclvQrYVYi9QJmbXDu3kgj4d s9nYp9La1JvnsVqTm9vbbhMeMxgNkNIwNkbQxgABUSEKCOfIgaMHDj0c/qZNu7/Pl/ypSdNOZ27n z87NR0UQQU2+L97v9/fvU6u+sX7j5h8/tnvVY5X3PbblbyCMbP7R1q0bV60Cgtav2bqj5J9KCndU 3vU3eSX/VF5ezuXUlZduqlxfUrWh8JmaqsLSHRx+VZ2wvGTH6pp7y6V33ZVXWVNXV1fK5XLvuqu4 SlpZXFpcyi9dweWW/su6+vqSFcJ6sZRfUlpdWVErLSvlF3PrQQTK11SU1RZK6zglXHGtUCTkFxSu 5BaKpcLtYLJ4At7q/AKxQCiRFpTJpZIWQUF1C69ZLpKIFZBA5DJZtVjQJOfJRQVwUybreEvS0NDA a+5UvdWm7FR2qpRgttTt3V1oEKTv/S51W5ems6/nfJ8abcU+oB2AaA0CMtjViTYRHdSidVLqToPJ 2u8AkbAb0TkeJqNl3KgftJgsrnkD5UarAoEJg4my6Cxmk8kzbvL0G6b8lMfjpebR0R92wuMGjcBY 9/y8GWPJKOnye6Ksh8BMERKSRgQa9nwiQnsj0Lqjboo2+ufZCA2xg7HbTfNMmiYAGjaRxpJAQySS wUBjEtF0nED9wNEMxmLzaXg4gTFENElGkxDKI56oh4Bcj+MQTrA4wyRZDJ/Ck3G0+SJucRFU0oEO bLOi3l58NDljtVwE1zUeDM84R534jHVgZirgdIacgcUZsF6B4FRwdNIZHF3MDYJAIIFsvuDMjR6i Xt6F4fenIYjMji28jWa5vzU7+9bY2CngYBINo6Oxwv81chys1pmhsaOnz6ABkUMnhg6dfnXo9KGR Y8dPD736zqFDh0BAUEfWseNvvvkOWie1bz/aYPEY2jTuGMrpaLjwpd0vQEw/CHS8tPulF54FRJ4G CXkB3NWLLz8ODgtAePzll3/2Itqj4R+/+zTa8gflcyQc/+fnP/vZ8zsPvPYf/wGAXKnX9u78i7/4 2c/+Ggj5JgSRv7//59/+ZzRe+OLjy+6//58ff+rxZX9/P1pne/+yxx7b+A+PPbV+4+OrHlv/2I83 PLZ+y32rfvTjrY/duerezZt/VPk3eRsqS0o2Vd5XsuOJ8i1Pllfu4HK2VFWuuG/HlkpI4xtqqurW VVXya7iV/MpHamvWbKlbsUNYK92QV1JeViMtvyu/il+6uo6fX8qvq66qrwZICutr+BBJqvh1m0oe rqsX1Yn59dXLt/P4teDFyoQrtstEtcvvqqhfVyuB2C4V8+qF4gKeVNQihdAB14QSwcOrm6VSubRI IpLI5JLmllqeQgF+q0kgkvGUjR1y3mqFXC7rkvAkKqVS1aFs61V1dKm6utSdICZ96vbePrRFe2/3 wPs93R8Y+rvUHxg02oFudLJgv26wv1Nt7oZg/oHaDAYKnTPrtwyOj1vd0OKNVpfpA7Pb5PaYzRaL xUa5jRbjvBtUwuI2WSyOqNfm7nO4LJSHMpkJAsMsyER5oiQZcWOY3x0lCBNLAgMY5olGvZEEGXUx aTbijaYJmmLoGE2YTWQEtf1kOs2yNDDA0tFMJptgMYaMJggXmwE04gQdQek9HcXYBDw8QhC0i6Ft UWwqTlCRiBufJwiGsBDzkFcoN0UBYThFxS/iTDhJzTjCFkjq4XmXC033tVpd+Lw1iFusM8H3Aovh mRk8NIHjwanzwRBabji1uAiq4lxcCIScwWDofHASfNXwbDC08GuQjtDs+wsgJGPvDc++jcLGudnQ 9MgY5PZzuZtncgMiY0dHzqDzEODjzOmjJ/79xJmh0yPAyOnjgMqJY7ld3t9BHbvH0YHQ+48dOXbw 9eM5j/V6bmP3wy+9/tK+w4fRLJPDh1955dkXXoIbj+8+fPjlV9C625effvn5Z3Nnov88R8qLEMv/ z3dzmyk+/zyg8cY1Lq4Dch2TPb/4xfPP//W3v5k7B/rnu7/x9y+iM6AfX/aDzY89dP/u+7734l/e /73H7oOgvnH9T5ct27hx/QPP3btq44+2/OiZDQ99Y9mmV2sqf7R2y333b3qipOTJzU+W/LRyS1VJ ZeWaOiGISvH3y9dzVq2tKq8qXFf1ZCn33rLy3BraTXV162pL8+7kQnyvqnmknsuprV1TWl9fVVjM r67fUMUr3yUqKy7m11RxH+TW1NfX82urxXwuX1q1XSTiF0hFIB88Tt4aWaNQWiuVrlguE/LE0lpB BdKP1ZLmOplM2sCrFjYvL1otkjRJpPKWFkEFXFE0ygQCCCYdHc2P3iNp7VGpwGHxJK1vtalUKrVC re74tbKrr6NnILc/ohqUZUBz/oOuAbSPqKbfYNYN6g2DoB7WUWVbv043Pj4wrkH7+piN/eMmPegH ZBDjoM4DDqvfYtLrNRY3leu1BVoozO21+N0eUA/SrNZTc17SYiFdektuP5IIYwf9INxk2uaLshhr iTB+uzsaiUBjT6RNpgzJZnwRhgTxiKX9jnl6LpYBSlwOOkYQGTLDMIlMlk2niZgvA5ISheeLk6Ao DJ1hiTiWSUOmIeIUDXGGgIxB+6JEhCJxh8eDJd0U4Y9jJOVHm8WDuPiTFOaAVA43/dYw+Cx8BiCx TAVmrDMz1qnJd4NW7Uz4/OLF90LWmQlI50FnAC5DHwQXBgYAlNDs6LsoqS+MQgIJOcdCcDE8O4nE Y3b23ZGjY8NnQ6G3z50bOZ0bNTw3NnJqLLc91tDJM6chhoC9Onp06PSJKxMXIXscPfrqCbSWEBLJ wf37XwdSXn/zyJHDaAvrY0eOQPwARvYffOl1CCOH97/0CloB8sqzzwIbhw+jbX52737+5adffPln L/9s93f/8R9//vzPXnzx5xApfgEtf+feN24k4iZArmOy8xe/2PP8z5Z9937ktJ56/P6nvv3N7/3D 93Y//lfffvypZU/f/9TGZffft37jvas2bLx/49bHVj20ceNDm5/bcN+yn25+oOSnq56o426o2/Lk 5vU7Srgl3Jo1haXLlj0hKq0s+cay4lLuem5lDXd9Kb++fEfN2lXr6ko3cGoqOHXC0nu5pVX8ijWF QtGKql31ZeUlRSsq1xTXFqyuupMj2rWdn38nl8fjFq4Q14GPqpeChKx9UFRbXrlCsn2NSCReXiiu Fov5RTJRca1MKi0rEheIV4vlfEEZZzWA0FzAWa1oLtjOk4geFUta0NGcZdsa5c0CsapB2vhWi7ih Xd6kbFP2dCg6WlW/bursbFMrVa3KvvYfqrStBoOioROdXKDWdPUazP39Bs2gWq09bzD09es12vEP 1Pp+NAZo1A2YbYPucYPdZEB7L5jdht5+nQXD1GoIHXqIIv16E5IJyuMweiGaj5P+cS/pMpvclIux R3xuoxfkwwRWiDBFIljarI/6SJbVO4gEZrezWZcdVACad9QfiZGYPZK2Z3xpYp4l4ZsY2kdQsWwq A6kD9ICm2DTu9/hAWBx+iBxxho0m40Q6m8ailB/IwOIR1g+gJOdRV3EyTtNJiqYIAmeSyWQ8mkxi EwGPDUvizkAy6XA4klTAkUwCHeP4hNWKAyGOIHwencAXUToZnJlYHMQXgxNTzqBzdAZc1qlpICQw eWpyAkzX5OjC2GTo1wvO9yCjD6Otf9AWJ7PTpwAKCCJjw2+fOnlyGk3GQhu9nxkZO/1vp9EGQJA8 RkaOQVQ/cezQ6RMnjh4fOnbs1TfRJJNjR9DWvMeOvA5B5Mg7r+9785dHjqARwn37D6I+LLTj6P79 Tz+dO3tt90svAyfPPgsu659ffH7300//fDd8/jm4qhd/Bmj84nNoXAXk008+hbo1Jgd27gE9+R4w 8dQ/fO+vvv3sD37w1EP3P/TUU8seWrb+qftXrd/4d+vXb77j2xu2VHI3VH5j/a5NW366ccOqZRs2 3Ptc5frKDZvrnlmzqvSBVeVPbtq19o71T9RsKn2QW1hZWriikL+CA3pQW1y+6Y68sprqNVVVy/iN tfXFEFa4VaXloidLqvibRNK1JfVrSqR8YePyO4tra6X84sLSKt6a0tXiNVzwUcIK6cN3rJBKpBXS sjxJq0i6XcrPXynlrZNtL5JWCWUt/CJhQZGoWda4PE8glzdVF60WSAS8+mYJOKoWmbxBXn1ntUre 3iyX/LCjp7G9TdW2TaFqk7W2KVXtjQNdSmWHorPb0NMj2NY1MNCt7uw0aAxqlUHTqTb0a/snBtt5 moFBjdmq6rXptNDUDchiaS16o7Ffaxs3mK16k8Wts3VOWG0WK6RwNFJuxFwGM0F5x+02dSfa6s1N Gvw+rwfDSLPeTbpsGbubGI95SDth8ZMkOecZdUTpKImhzM66WBIcVxp133r0hkw0S5AZMzMXi7IJ Mh4n02QszWTSlhidZtJkPJOOzpEBhqajaUg1gImLRSilozSE9ompDNgykgyycxBgAAo/ibltWJzC KE8k7HeHHRQW9V6cxCMWKonjflcSn8fD+Oh8GO3CuDgGCcQVDF+cDNusFwOLuDMEl9bA6GLwvHVx dALyxvngwOD0SHB4cWEU+aqJ6ZDz15PvOkdBO2anD00vzEI0mR6ZPTs7nRtCD42dmYX8MXTm5LmR EXg/M3by5KFjY2fODI0cPTRyeuT40ZHTx+DKqycODR08fPzEiePHTqCt495BoOw/iCYr7jt45OAv 3wREjhze9/rBX/7y6YcOvv4CZBC0cmo32pr3xcMvo/lY3/3m4ZdfBtX47j//Yg/UEkMFdenaFcTF p5/ccfmTXH36JZigJ9nzwv2QPv7hvvueenwV5I/Nj22EmL5s8+bNz238xkOPbVy/4Zll3/i7B+79 6Ya6B/LW71jGqSypLPnLZc89sWrTWk5JSfmuR0p2bKgRPlz1ZGVl6fa6mqoyiOkb6urrdn0nj8sv X1NVe9ff/OT75cU1onLOGn5eMa+Uv+GOe0WbVtStzV+zpkZWX7iaLxJV1/P5fLFYJK2WruEVlwul ItlaDjoQRyLMe0D4SFWRUF6ezxNzQEgEy7/1nY5HHpavLuLxRI2SIgEkjpaW5maBpE0mb2oRK7YJ Ze2NHWWPCtDKc9nd/0XWpFQ0dksaOtu2dao7VQ13y3taVN1tynZVq1bVq+7SDpzXGPr6IHqc7+/S m3sHBiF8tPca+j/QDPYrWoET8FsGg0mvNppMxt53rTqQD73Z7LLZjH6TVYc2zjUaCdJmiRgxzOzx UD6LwYFRJsJrnBi0QN7wRuf9rN+fhtd+/YTH649E/BhBemOQKTy+aCZNEEQiS0eycBuj6awvOm8n MiwZw3A6QrKkL4MxCT+TAhACfpqOg6kiwIVlQUtoXyaTYIl0gqYzEFEYjI5mfRREcgosGj7loQiG 9LrxOBtgCIxIOnEbhQMjyfiMl/LHwx6P2wWKgsXhswuPOy5aXBbPB85AGJ9yWZ0hK6jHjHXBGcAn g3gQD42EBhdC50edoYnFHvBaCwOAyMRoaDQwDCZrcmIyNLwwPDw9Mhk6Nzn79tGht85Nvzs7OzYy OXZ0bHJseuTY0Mmx/3VmZAQuTkIQAZc1NDZyGsLImRMnTqMtgIZO7xo6+G/Hjh8/9M7x/a+/Cerx zpsv7YNoDjICqvH6HiQf+/e/hDY02f/KL1956aXcxiYvgMfavfvFZ185jPb6efHZX+zZuXPPUtV4 7fq1HBmfXgHjjssfXc7Vl3Py2hsH4On27Hn+BxvX/2Djsu+9sHnz+vXr77/vvgd+8szmZatW3f/Y E9xv/uVfLivZWPnclpKSB0ogo2964C+5WzfUbFp/Z95Pd5QWrlpWXldaU4NyxNbaurpi/hrO2s11 MmENt5DLqRJy7/hW3oOlT1YL60srvl/JW1FU97ff4tfwa6XcPO5/KxcXc+6S1lbVSutr6/PrRMLa ovo1+VUP75LJ1+UX5RfWih78Vh6nuEogFEl4ghqxoLRZtJYjRXtRr+RCEGnm5RfIRRJ4lylWQ+SQ K1p4YkltY2uHsEjBE3TIfsh5tEjR1N7RoWprl3e2t/V1lG3rUHW1qhoalOo+Q2eDsuf993vO9/UY 2gd7esBedfZ1va/TDWrUerVBO678V2XvlMaohchh7DddNFODSv2gCZ1yozabXCaz2mhzUzaK9JiM NpvNzbqnjOPWOa/HaLYjn+Wc0OsxN2mLEhjlIjAmalHbPWzUhunNDLzm2/VpL7zqZzI0Q8W83jRE EJKKzsUgZDN+MkZMOBxguzKxLGR3AuX0SIClAQbMEWcSaTaOZ2j08Gg2l1jYFIGTlMcXyyQZEB1v fCIQiAOJdATDKDSVMRp2EiR4MHwCjyex+UCAirjQu8sxY7FY8ORUILwIkjgTdIxOzFidpyYnJ/Cp mZlwcGoR8JiaCb27iH8wszg55pwIBp3vTi8uLpyfDb4fnHx/+P1ZZ2h6LBQaHh7+1anJU2OzsyOH juYWp8+eGwMdmT41feboUTRlcegQWkI1BuHjzBCaz3tm5Pir//7vQ0dPownuu3YNHT92aB+Agfqr IHW8gwbQ4W3f8dd3Hz6y78gv9yHVgJD+9OHXX0InFIJuvPDCKy8fBlf18xeAjJ2gGq/dop1fUY1c 5aj46OM7PrpSOU4+uYJJznX9x604eWPvTgBl5y/++v6Nmx9ftXnZQ3/17Y33ba5cv+xb6yu3PrHx 3nv/qa5yw3Nbf7q18smSHc8ItyI/9cw67k/Ld/DrKvPKn+GsqCuvrFr/rcdq1hWW1jzIuSPv+2vr yis4eaU1tbVr15bWCMv5u2oKavlla7YLd9WX5pYE5hdUV1SLSrnSmgerRGVV1Q/mrZXUrhFLV3Lu eOCRR0RVYi5XXCsSlj3CF8rrmxurxXKBlNcsk0nAT4lltfeIW8Ry2erVcumjQlmzpOXuu6Uykbil Zds931pXK2pUKB/lNb3VIWtqauvoburq6Wzv7lUpVT1oNx+1uqerbbRLPTCgVA2old096ASctm7A ol+jbtvW3dWv1ZuVBqNFO96vQbuFWnT+cYvJaKZ0NpPRbTfq+vWuccxmgW8x6m02E2WcMFhsRpPF 5Ff3WsYtHkglJtJjs7jHMV/ETXvtaI4VlvHR8HrPZrwuO0mkY9F50sNgXprNYA4TJAeWZuz6qShF Z1kMZ7N0LEKS6VgmHaNZOp0CmQHZSCfYbIxgMmwqRiYzUYaIZQh4uAvNWMwy8Qk8QtEksMNmoh63 2wWYoaUkUdSNFvUixxWPWHA/FSc8ySlAI+xxhd0BJ26lHElXYOLdhcWwdR6fcM7PQARZnJqx4uFB PGh1LEJ+H4QQHwgMnHdOLAYWZ96bXlyYXDgfWlgYO4VWhiyEJkcOnXs7NDv93sipEIT0aRASdGAI ZPbJ6bHp2ZOTaE3IyaGjY0NobxNA49DQGbS3Itqy4RB83nf4zeNvvnMIssfxE0DGkWPvHD9y/J1j R948CF/agxaFoP3iDu87uO/1F3bvf+Hw7hdeOfzs7u/+87O/3JNDY+9rn0fj0//4TDQuIzYQEbm6 Bsg1Tj6+riYfydjPAAAgAElEQVRXw8ktOHntjb0HrgjKY3/z7WUP3bd5y+ZVG7gPvMp9rPK+H9z1 jc1bl3HWb9m6Yf2mTevzKrfWyJ4r+X5JnrCuuLySu6OmfNUG4QN3VPLzOFU1VXd9i/v/ra6v25Rf U1yzC81L/Nt789bV51WulNZUFNZWc7j11cLGdcXSlffKhNvrVxdWSao44l35d5aJOfnS2kc4nLvv rpEKHymQikWy71TXf+e/LufIqzni1ULJdp5cml/cIpG1SniioodbRc2SsiKJXLCyqfFujrL5bsgk Lfk/3LatXd4hUaiUrY0SubJWJN7WquR1NnUDId2qBmV3V49Ore4+JdN1G7rUas2Auq1/sKHN2NfW 1z+gUfSq9QP9gx980K8BKRk3v39erdbp1eZ+i0s/bjOpzZ5xn89spPSDPrebQp28ZrPH0msgzQa3 xWLs9evt0ajH6Ha7fZQrYhrv1xu9fjODFtJGabvZHQWRYCKE2etLkBBBshE7FiMnsJRpnsxGXXrG zkI2wTIE6SPdGdbi9kfoOMZmsgkwYEw8k6XnaDbLJn2xRCrNENlMnACxIdLzcFdk3hGPExk6kiSx iA9zp9E+PhEygKafMEk0tO4GjSEBkAWvJw7pI0klA0mPYzKZHA26qHDIGZgIh63hYBif0QYX8SA0 eys+PRU4H54Igng4FxcHtIvOxclQz2JgIeQMLobeDQ6/OxIMnZqE7DFyCsL6wuw5yCBgrkBT/vfI yCw4rLEz06eG4MrIuXNo4sm5oydODo2dPn10aAiM19C/HTwNugHZYx/k8xOnTxxBK0HePAJJ/fX9 +96BXH7sdRAPtF/1kSN79ux/6ZXdL/zyJbSZyUu/BDAOHDiw9yuJxscf30DETYBcVZMrmFy+brpu mU4QKFdIeWzzP1VuWLVl2bIN61dxHlrGfehvKzdsrbyzpHwDJ6+y8r9WcSq3fuOuqvKq9XkllRXc O8vrODuquCWldWhlVE1dzdqa7dX8Qmkeh1dYcncetzCvrpxfx89bLS3l3Fu1traeW1Zz5xppdfWD 3AL+9vw8qZDDq84vLhMKhbV1tSJpVa1YyFtdxykQVDxalLe6IF8klop4+dVCXuF3pI/IJMWS6ryy pibJowXiZsU9y+XylW0tqxuawGnJVLLGplpVk0rSJP9hm1Lxr4pHlQpBdydkD0VXV3tDU5+qR63U yLepNP19bZ19BkNb02C30qzpRZtPDw5YB7XG8+NGq75f06vx6/X6XrPhA4vJakH7JpoN/eP9NpPZ 0qced1tMBrPJbho10uN6AoyVxwOyEQVzbyHJiD16UU8wfrtfjzmoKOuJmO1Ryj5PpS00NGyzmSSz jBkjEozZHXMzKTSXhKZjUbhIRxPZDEPH/WmGYezzhD+aSdAZP5slmSSZprNMOusIp9JRJsmyCcZB 0kk2lYSHw2MzYLqICJtJx6M4nojH4475pMNCYBFXAIskHTiR9BA44XbCh9sRmE/GA6OuyGg8HHAk rZR1fGbGEl504TN4IOwM4oGJANrOZCaIzwQnFxaD0PyDM8H38IWRhcWFhXcnIaKPjS3Ojk2E3gVA Zt9Hk01C5xbem52cfnsEksepU0fHECPTb4+haYpHTwMrcO30sRNjQ2Noc5ORY4fOnDiGUvrQ0NA7 J06ceOf48RPH37yyZGrfvn2HD+5HR3ke37//yMF9h186+NLr+w8ffPHp13flwLg1GUuiRk40Ll8T jd8IyHVQvko6AU5e25sDZU/Jqq3f31r33NbNq7ZsWFVSuqXkydL1eXl3rq/irqrdeueyLbJ1D3L5 NaWr8qo2PckvLC6s31S5dkV5fR23pJArfKSuYo1UKoV4wS+pW1NSKq4qrRGvzOPcWSrN58qq7uRI G6WFxTWS1RyupEwsLljNl1TzysvrJcL8ijWrZbXCoqomoUgmEvEKREUF9ZJqMFgV+XdzBE3LeY1l ecUgJUX/QyQXP8qTt0jaBAKJqqlFKmlXybYpBC2tsrcU8q6Ojp7Gxramjra2X/Wp1F1qZYOC19eh UGnbtym1WkOvurtfrURHChoMavPAB/19mn7rQK9BPaDVjhvGLYMenXZQbxwEFKxGNwVxXa92j+st OkOvyec1mTGPxaE3WtwEZrK7PZjb6CY9lMMEed1G2dEgYMwWtVMWO5aIYOkMWjBrzrjNtNesZ0FK sARNAghZNBjIZKMseK8MTTIYFqNjaQwRE6MzTBS0IpGFZs/G/X4sS8RjtMOfmqMZJh1Nx+OQ1dMM y2YyLIUeDsE7SUeiLHiwKI0GPFDHLgFBhIg7AhPJNI7b3M4A5aUcfhdISMAdRivVcVd4fhFPhq0T wcCUZcYagAAyY5mZCY7OBEaDOPiqKeekcywI+jEYGpkMa4OTzoVF59jkYigUmgR2QqFptKDw1OTY udnZt9+dng3NDr89Ozb29im04hbt3XD06LHJoUOnT54+djS39ejQ0CFA4zR8/dDIieOnjwAdJ0BH jr+Dlku9+eaJd555c9/B1/ftyy0m3L/7xcMvvIoEA8C4dOlWTfZm1bg1G78RkKWYfLLEdn0RJ28g Rdm588drORt2cPNWba1c8cSW0ue2rFr7ZN73dz3zUF5d7TOlFXWi2qqSqpoK7pMl99au+287KiqE 68or8qrqxRXce/n8unXSqhJeRSF3hXQ1v66qTMgvqeFxhLJH8rgikZQn3iXfVb+yTrp9ubjwb+XS 4v/O48lry4o4Egnk8LWCMpFEVF/QzCsqfLhFLJVLamWCe0SC5bLGag6vUdakkDR2NDYL5E0NYsW2 2samBkVbW6tc2bC6S9WOFkm1d6i6OxWqXoWivau3o7uvuxWCR2+TVtveoNL2dBs0uh6toW/AqDfo gQqzGo169Jv0BrSZVZ/GaNS6POYPML/BMO62D1rcgzaH0aLX+HSa3nGdh8IsPpvNPu5xmzG72WPD /AxGeinWYYTcYTK7CdIGWcGdYOzmaBpkhPQCLhm7xeedd2S9NJqKGwMu6ASWYO0QN6BobyYBzGQS IC/Q3rOgGAmWwbIJls6QsWw8krJHffT8fBbyewIenmEiEFsSTDIWZRiWAQViHSTANJ8kiEgmksYJ Jo4nI4wrQlAewkFhAYvXOoFHPVQyCZrnclBuvyMZwC0uB477LWDLnOHwPA5U4DPhGXwUlMQ5Gg5M nccXB4LOxcD0zODCqemZ4cVAcGB4IDSJtgRyvhsaDr3rdDqHF6YnRwCWyTEU0qffQnDktjbJrStE Pb2nAY5jp1E/7+mTkEbQottDR4+dePXosUNH0WHpxw5CYD+27wjEjyNvoj2xDh8++OYuJBhvABm3 EI1PfxsyvjIgVyj5aEmIv55PbonJa2/krNeeX64t5tbXVdaI1gIgW2rqSr+xo3QDf8faqhpp3o51 9Vzxw3lrhTU1NdvF9TW1NfwVnMLiPG5x1RpucUWdsI5fXLW9QCjiCWWrq8Ucaa2o9E5+FV9cWl0v lHDEQmmh9BHOOiBAWi+V1IrqxMuX80o5BdulBQVisUguFPMkYrFMDlFdLGpYLpfJivKbmyVtYpFE 1nRPk6xF0C59VN4ol0PYUMk6VEqBQNnAUyhVCkmvurW1q7OzT/nrnu4+bY+6W9000DOgbDP0Gczq Ac2gRmkc7DKMq9SDWrTqY3xwUAtuymBXq6fM46hbV6d1+41us1tncfs88xazxmKzqM2EEYTDQtFG R8RmwqJms9cT8VBEJOqxkZjZxE6hiVdmjCG9NpIhWSzqy6R9USJjd9OxzBSWJhIJIpulMWjVWDo7 T4Bc0KlENgufWQxLzGNo+hULwRwafQoAiaWy8AypeCQbS+Nsgkiw6VQUHBaoTDriJ2JZyCppMkJH 0iAaDD7PEOF4kkFzveIEk4x6sIg3CYBQkWjSmevidbko92jS6gL9cIYtMy5XMhx2WWfw4Ggg8N6o Y3E0FAzMWM8HwG8FreeDVusoOK3zwzMgJcHRoHMhOBwcC70fci6ETs2i/l7nwq/BZkEcnzyF9vqB j8nZt8+hgD528u2xkyfReqlzZ84cO4SmmwAb/w6sDJ0G9Tg29M7pE+jYW7BZhw6i7t2Dx47sP/jm SQQGNL9bScaVnLA0hP9mMn47QJag8pmefBkoV1BBQ40/fuZfSpeVFJbU5XEquRVP7shbW3vvk1V1 2zdIS7krKir4pdzCiqpaYTGXzy8sLJbWVqGpVBXiav52MGFruNJqsTivoGJ1LQesFE9cylknyq+u For5Ql7JWr5YsD2/FLRCVLRcIFhduk0uFDRLZAKxpEUg4PEkBavlEkUzR7BNIrqbJxYrFA13Ayvt cpmiSdbMU7QpmxS8tiZVY0eDol2paOtt7ehUdbT2qrsgkis7+xSdA30GtcKg7u6ACxAMtXJwQN0/ MKDvHzeg/eCMaCmtVTeuNxjnzWaTzmqC+G0CG4WBo3Kjzl3WbMDsHuMoZjIRmFnjtZpIT8TuoUzz ECUI+zyWjnrTfoxkTGhHkgTpzbIECAhrSqTNoBYJU5LFYqb5BJpAZXfFKBCKFJpvhSWgwHel6Rjc l2IhncfSiVQsxaaycA+WSsez2VRiHnQm5gfNSSRYPxUD60YnCJrIzeVFl2mU51kC2MhECZAnIgm5 hEkmiSROkQwbgHhuCeBxfzI+PzETCQIl/nkKD6K1ungAx8NWawA+ocUhM+gWHry4OOUIjeIh5/mF qcBYALwV2l0xGHCOLQ5PLizMOkOzzncnp50gHJPToWEwVs7pHBvT0+dmwXMBImjZLZqHNQLZY2jo GFpgOHIUQvqxoRMnjp44AWbr+NHjV3b8gbx+AmLG3hwXX0jGJzdoxsdfkYzfFZCPrnSAfXz5RlK+ qGP4qvnau3fnzjrO9vKSSn7e5toVm7bX1FbU1lTU1HOWC8s5eXl80a6q7fWP7CiurxeXVtSX8YuF 9XxxxfbthfnFK4oLK2rrZXWFgqriMjGnTLRGKhaKyuRwWf1gmaw8n5MvaZQ1C1qkRTywWmKxRCIo kzcLmsXNgqLVvO1iXrNI3irc1iLhNTWvlMvE8rYOWVNjU5OsaZu8UcArEnT0tHaqO1Rtyq4+dGZU l1rVivp41Whee6e6s697QNelRlvDGQAQQ3+/tn9Aa+wfNHcOavXqTgMaRncNmgx2i9uF6PBbPej4 MwwFc7N5nqJsPiNGmkwWu9lmMVKUl7DZWIvHZLbZ/FN6l9fnYSGbY4koycLLe5rxgJOCho3ZTWgP q2jC54PmzxIZxh0jSVCGRIxOZCG/x2j7vD/t82VBSVgAI5VIZLKATxaAASDQXHiwYQlfLJ4A3UjF KZqADB9jY9lENBOHJ/PjOOGNkWwGMn2aTKD9sth4lMCIOMP48Th6i2CQQLCw35UMhC04lbRa0BJc KjyxaAEKnGGbZX4+DMkdrFYA7dkQnJkKImCczgl4Cy7iPQvOIAT30NjC+5MgI4tgsEKzobHQMETz sdnhWef0AsQTiCXoPB3I7BDZoUZyNTZ07uTpkaGRo7lerKOnT585cWLo+OkhtOvPGcTFpSUR40Y+ bqUZX1U0/q8B+YyUyzcIyqdf1uV15Y9ApOx5IK9yzZNgmWpKNpShaYkbCgsrVgtb63nC6opCTnFx RTUwIa4oLOZyCqXV9eICcYVUKBLeXSrdXttYU1HM4VWIK/Ka1xVWNXNXykSlRWCrGlsFkDl4FVxx kaClgFcEOYRfkL9NrpAoxBKBXNYoelTaLmhsbRZsu0ehaOMVtTf9j6bOexQ9KoFCoZRre9q7Gn+l VPAQIAql0tDZCYqibjV0GdR9fQM92u5eTb9Bq4N43mkGr6VGR6WZOs065KrMg3M6k0WLoYUeZmx8 ymzC0Mx1A2bD0FED4x6bbtxhJTGf1w7AoMMH7FGTOYIZSB9lR1N357wEbWOR08JIeARaqGGaN6Xp BGroEdobA8uVSUBSZ03opR9nIYFkWH8WTbIChZijEyiTxOF6imAZYIPFGCabTQAxaJgEHp5NZ3xR lkWCwuKJaJzIxP00TaDerdhchqAjTBLHkkw6ycyzyXgcEkaEIIh5Ik5FPFHHPJWkvLndFf1xPJQM B/DkRMBCTTlAPbTei2HrxcCoEw86FicCITwIQWRyAgRlajQ4ujg8cH4ytDgxPBhyTo4BUZNjwdBk aHRkcngBUJgMnT0Lef29MTSQPnluBPVooUXpp95GgWTs9LkzJ9ERbCNnTo4cPX5k5PTIkXfOIr1Y CsOlG+H4vGT8Llh8TYBc4+SWSf4mTi7d8Ge8hiZ67frJ1h/de29pXf2OqmoOR7aVW18trb4zr+hf dklXFFZxOHw+N18oFEjrxdz8QpFMXMmr4staZWX5YLsKVoqlUnFBfvF/FzUXSSX5axsfKYAwIrlz JcDSUsBvzl/ZLFi+XSZqETUp7nm0rLFR0iBRtLT2NCrKVE0KsUApb29r5gmUjZ1tKtU2WY+kraur W8VRqlU9XW2dqgZln1qi7tG83/2Boa23S6tF+tGtu6DVq8aNaBPRAbTeY8qkNWsoYy+QY7RYbWaF 2UTpjAajUW12XVRjOgpNMJnSW30el92CeebmPHZXJI2Z7BS8TpvA+HvAULn1PtpMRsH3q1k26iPs aczApjFz2hcBLDC7PwphBICg5+ayDJnN2SmwUZiJBeFIZQn/HM2kIJ+YHAk2FiOYFIbDvXFI5tlU iokztA84Sydic75UnMwk0KwseNpkks2mwXLh8770fDoSyQQDLOPNJOcJPIBhuCMSdVMEM4XjEM7j SVfS4/MkA24XOKsk5A98NOCwJtHOJkHbYiAcngmPOQOOwbBzYmpyMhh0OmcWFxdBOSZDMxDXg6Hg gHY4txHplV4soME56wTdGDk3DN4qNDv9b2OTk8Pn0IJb+Dg0cvLcuf8Nn49CTgdMTgydPXDgwzc+ 56GWfuEmM5Ub7Pu/ZCNXXwcgV+vyNeP1ydKe4S8TFFRo0PEnP2l87i9+sqt0DWeLTMQX5xWKhHxR bamocd3dQkmVWMjj5t8h3iWvy+fkcUStsjuL5LuqiwvhqkggKaqVFIkai+8QyfkVd0vhK80cXiOk cyHIRe02NKlEJihYntfU2NhSdA+nqFEn40haG5saCn7Y2iPrVCneUkkaW7fltXYoFQ1v6bo61TxV T3dXT5dKq1OptRrD+R413NOv1XYplQq1bq67wajTavSdTt1cv3HcPDh+UWdrUOqsZr1eO2d0mdSU jrTo3NScz4zp3ETU5je/p/d4vYgn19xc/0TEZ8OwCf/cHJEm3R7C7aPf1fgIzG/yzrEE5gBZoL1E dM7HpGOQMKKgN9DEY9i82ZGem3OhVbUs60/M+RKpNGhMZi7Vm/CB5hA+H4QSJhZLxWIJGtQmG0uk IKwQo0ANDQLhz8755uN0LMtgeHouBuJCZpmIjx1Le5kkxHZ4WjxOexjI6R5fxB+JoO2zcMck5vFQ joBzwuLzvIdbPECIk/JZ42E8HMZnbIH/GYYY4ly0gWRMBwZncOv5Kat2cWJmMTcmMnlqYWBgYXJy ZHJAuzjiHBgGNk4N96Ce3tmFydnhkUOzs++OjZw7GxqbPD42fA7t2TB8dgwBcubkmaF3Xj3w4Y3j 3jdD8ulNZHzyO8SML62vEZDP6up4/I0R5UtCSk5T3njjwM6f7NnVuGvXjx94rrZM2FhVVF+YVy7l V9SJRJKVnJX1El5BUX6BqHVFfq1IuuY7d94rLBPzxDwe70Gh8JvfaWyR8opEMqH8OyuFIkljo0Ag Kbi7ViQQyyBx/PCehiaIJYoiRWPPPWJZY5OgmrNO1qJsUyrb2gTdu74lAiQ629DxBm2S7u4ubY+6 y6BQdHerDT09g929SjXEcoOhU6PT9fYNajUf9Cm6e8xGyBh+fZ9X/kOtzWo0m3U6y6BBY7NYfDbT OGaYslF2t81rc5sdmCUCXspMzXn1bpvN5TL3WizovEAW87tiql4vDbrC+ry0xe+mo9E5GkKI30iT bCQGmoAxbDYDQZvJznn8mRjtJuenaBTFIXvHM7FfOXx0KsGmfDE6EocMT8+hEOInIM1ngQ2Wiaey aSYBTzJHwf1ZgsDxbBpCP5SfpMfwWCZNxCPeaNQVIKMEaBhD+APhCBanPNGIP4ATVBKPO/CIbypA WVzBeZAF4A2HmpiZObTgCSenAjODMzMhZ3hm0aoNBnHnJOjHxPDMzKITjYGEnBOTzoGesenF9xem p0emIaqD2ZqcHJs9t+8cZBII6cNvvz0y8vbs7NmzJ0+ePPPqhZvG9i59Do6lIePyZzHja6/fCyC5 unwtyOd+/RvM102g3NRjnZvJsmfXrp/sefUnf/e35Xzug3WNMvFqqViyrlhcwROLeHmPCkUiuaCg YLV0ZbV8dVF+bc89d8lk8pZHxY/eLZMXSFu2C0Tiaon0YZ5AcE+RrLVRIWlqk9U2tPFaJI0Ndytk HY0dTQKFpB3oaVAIGnXb/ktPa6uqrbdB0dPd9lZXb1d3u6qvq6nToGrr1Oq0eo1Ro1WhjXU1WnXb xcFBnUVj1l80GiyDerNB5+sd0Nl0JrNdr9FZzFaj30Jp3O5+jdll1Bt1c7SdJN1eM4uZSIvHoXfT Xm/UhdndhJFGR3HO0XqLz+tlIBhTPtIVJSCXu9NptwtLY37SB809m8rEmARLpOis356JxXzQyHNr oTIMlpjL+mM+yBkQQkB9CDQIkiBSaTeBFoBkfHMp9HD6ysNTeDxL07EM5Jw05qaJeDIxRwTpWDSK htKjdNJFJuOReJhIhueTSdxBeb1YksAoCmfwZNKSdAIhFkt4yoGHg2HQlVDYF5i2WK3hAAQPqzWw sDgRDAcW8GAohPzVee0ACiWLC87AZCg47BwJzS5CTIcsDpkdlGNstmdkaBiS+pnZMycBjbNozPvS VSKuZosbeqc+vcbFJ0sF4/dDxtX6/QFyvS5/JimfzYb8jXk+V28gVnbt3LNnZyMQU11TIFiRn18m zcsvKpMKIHE0y6UCmWS7YJtwHU8mEpQtFwjEQvnyBwUFEnmLXCTqaJJ3SJq3lbWK6hub5JKG9oJt vPYmzra2pnY0c1fVqmxvbVeqOxubmlo7VJ0KtVrd3SFoULd1dWsGOgZ6NANag6G3S9fRp9VY+/T9 SrW6X6PQm/v7jYNal1VnGtehye2DGqOOMs4b3CbMNqjW280WS8Rm8XhJG7gpv8XXb/ESHhNL6f2m jFFvxyIk3JOOell4Z1nSY4r4EiRmSrNp2uJgMIbORGNRaMcxOsHaaR9Lg2liEqSfIbKYn01kU9kY CAV8ERklmmaz4LcgoLOpWNrPMmwsRdPoO2IAC3guhqbRw4l4PJHC/SyRSWTpbJrOsnSGTTDRCBal 0RpDliGjSUc8jkWJSISKRogokYw7aA8epQgXjuEBCB9OiOeupJtyhS2ueUsYdGVmccpqxXEnjgfC M6HJgBOfwWfOL1oXF2cWwJdZF0MzSEHQzibBhZFJJySQhdnQwnBo4SyQcRbqAKjF9Xhx63Hv61h8 uiRhgJP6nbqlfsv6AwCytC7fOH/lqwaVq/O+0FzMnQiW2idKpQKJUProw2KeRCjg1a9+kCdpEawU S6p5PJm8SbRN0NTQLNgmVTRD25dyRB2KNnmbuEj0Vi2vo1Egl0hUSpWss0HSpux6q13ZroBM3tWr UIPNau/p1rzf26dBxw5qDH3afo1KMTBo1vSb1b0D1j61VgsyctHosgya9Bp0hLnR3G/QGymLeQoD SIy6qMXtHyfshNlOMRavhdQYbFGGJFnzvCdqNPosWMRIspDJGbsbnV9DEG6znSAzdhNEEibizUbT oCDw6o9ieSyTmXfFkISwGAbmiPRl0hk2i1o4y6YhY6TQaAhE9BTDplJoAm8WmMrmzFcK+Eml/OlY KoFAISCPZGLpdJrNJFJZkB4itzARrR5MZ0BK0gQWj0bTkXiSZBgMeMHgd3NNhKNYkmLigTDlClAe HOK5K+6mkg4cd4ThBj7lDCTDuHNqHg8GZmbC4UBwMRAITgQdQesivjA2OxMMLgYhji+GwEaF3kdM 9Fy4gsXVzqhbD2As5eLTm+TiD0PG1foDA3KtwH99fFVTLt+Myo2w3PCvl+v2fg1N/jpwlZZdr9Y9 J+S1yFZWiyTyarG4oOruWiHar6GlpUUuUSAf1Sbj3a2QNDQoFLxtMhXYK5VM1dTU1q4CcWlRtivf 6uxobHirq6u1Sd2paFd0d3R0d3Vp+jQDffrz6r4+zaBS2afRGwx9avXguFmrtQ66jUYz2kpUc9Fk NFpNtgE9mrpudpmnjECM1TLujhARcFGUyc2CqXJQbjuGucwmmiS8tMeTJgmQDfAzBEugiepuxpam 6XiawdxY1BLNkplMIpplExlgAEwVk4HmzlJYIpZOxWiaRiOBoA4sARxkU6kYkQA5gW9nwVTRmWw2 k0qlsuh74H46jYOysAnQD5TogZ8sPC1K70n4bjZDpOk4G01ESWAiGSciVCRNEGmCJOIElsSwaHIi 7orHkdtyU3EqQlHupAtPhi3hID6fBLEIWyfwmXlqMehA53aGF8P4VBjHw3hgMQh13jkWWFjICcWF C/B+4Y0PX/uigYslYNw0hnGFjI9/i9Hvr7P+SIB8Vh9fEZVPPksqS6LKbxaWKzOKES4Hdp7duavu uRahoPnRgna5pFoslShaxM0NYlmTQNqAzv6QK3MnR8mVioaGps72RlX7r+AraLpJQ1PXr1u7ejs7 BzrU6n9V9nd3qdRdfQbQEX3fAAiJerDfYLSa/ebxfs24Ua83GE39NpPRhU68MVOQNNxundtvN9qs dpPeGLWMGyGls5QfY9wet9tkh7BBRsFORSh3JGE320FDvGgVOUOQbMbtJ9Npb4LB0jEScnOazpAE GKEr8wrpBAmmiWRRk09kMxnQCaQWqI8KJXP4GoR3dBM8Fp1OoESeylyhAwhAHcFMAgIKGkVMZNLp FGR24HfORncAAAlYSURBVC6aWzEST8MPSMYzbIRmmHgmirF+Rxp0I4m5GPBX8ThFxcM4EcGTBGCC ucBeQWaHNEK55pNxMFX4fHgCTXmfcQTAYTmCzvfCoBuB4fNntWfPag9cuHDgwN4PP0QzBq/T8EVy cYNY3KAXf9z2+UcH5Hp9fG0w5bOs8tXDSu5f/sp0yb0H9uZw2bVT9JxQLmkGEZE2tbZ0XJAplQKe EtRC3AlxRKECX9XW2aVEOzN0tKNznbs7+pTV/Zqe7gb1ebW6CyzWAGLkg74BrVk316oxGdQm7aBe D5lDbx53GIxml9VuNpos4/3jHsu4zeoyaCIW77jeZTHZx00myoLO+XDbvV52bs5CEuCivB6/nfRg 4KnsaFQwwqANR0gqQ0cz3kzaNJ6lY4BLBkhiWHBLYIjSrI9OzM0BGMCFD1o7GjVPgKVC8sEikUhl QBey4KQwEh5OMNkMGka8QlQinfBlU3O+HFZAUZzNRADEBBpUzKQZMHJZgspk05loGsOpdJTG8TT4 LYgkpDsJjCSTMVfa50li8QAICB6Iu9AoIZplMu/CHf4pHB0uNYMmZQ2f1YJEABN7L+z98I1LN2ft WzFxXSs+WYLFkkmEf2Q0rtSfDiCf1TVUlk6P/HJhucX/wCWEyzVgDuzdufNs48mzooJ7qjsaeJ0d rZJtog5Bu7qr9VdvvaVUq7o61O+r+rq6lA0KpapbreweMPRr1OoerUFj0Di7tWrV4Pigtl+p1Ayq DZjW9kHv4KDabRrUuSxus8ttsbotRreFcqj1mnGL3+7xYB7C7NbZWIpw+8F9jdOkzeueMFuifizh 9Zocnog5k6a96ShoSYImQV6gmfoddlc0w7B0NEEnTKQPEZJgwE1FIHTHCD9GZxAlNIPFMhiYK7BW SCtoEBTgJhWPAz6AENiobC6PpCC7M7EUk4XATmMOLJuOQ5DPxDGaSCZAqNIoyQAiIGWAosOBJyOs n0B7M8ZxiiYIAAWPollZhIcKoqM8A0m3JzyBU+j0HB0C4sKFD3OFpqguGbD4Ive0BIrP1OJ6J+3V aPEnwcX1+lMEZGldDStXRlVuRctX8GHof+zSa1dmT+7dm/Nke/fuPHB2165d7R2dHd2qvjZBp7q7 q03Z193T0ajuG3gfrUNXAif9nf1ma7/aqOlFu43qBtR63bjpokanMxsptQGCiBGkw63vM9ltlMFE 2nSDgxhlA9lgzXa7IWoxk2mP20QSBoeJsHmtfreXTBDknNdERhwYRnpIOkomHEYWTJSfyMa8niha KQtGyMSwJjpDpLI0AaHbbofU4SPjoBMpNotWCqb8CcQEDRAwBNyZADbQihC4RMxgKJVDik/RoDYs gJMCwOKgSSmGngO4CJwABclkM2kWx1giiuFofWGEYDKROEGgWVhhMuliSQrHXPgEnrTobD0IiA+v AAFZAnzTlcUWl3Ld9F+GxDUobmDiWl/U1zLc/XusP3VAltbl651gnyyF5dMbabkFL7cSmEtXJubD 294rQrMXDPPJxtbG7h61agBCuQboGND2GpRNfW1q7bjSoDf3G226C1qzWa/TGU06rdnkNoHCWHyD ervDpjMZzG63y+uxWz0U5G1LBE1GhG8w6ce9hAHDwEt5fXMexmT3+Yi0z8YkSBZzmeg5ys4yXh8z j6XRzgtMFF7+0+loBotFGdbvxvxpH+uHQAE2CqwWZI25GJv1oZYP1xOxOYJJsL4YCxCkwYNdsVap bG6UhJ1PJP3ZGDOPerWyMZ8PBIlFAytwXyKNYThLx5Jx1gWqAjmDIGk2Cfph9Wi1OXn4cC9i4RKa RX7pSpD4zRH7RiSWpIrLS2LFnzgUS+s/EyDX6/JHS2j55EZeluLyBbzcUmHgdRC9JqKJ069dMQxv fAhyc+HDAwfOdjRe0PbpLw4a1X0ai1VvUA8CIGadzWQx2u16o2ccDYfYvCYzoVcbLON6k8Wns+kw NeHz2kwOyORejwlLgOlyoeMM4CadIAhABXW/2gmaiPrAd8UYNu2YwmhyHi2NivlYQ3YOjBHDYqwv iyXATWHpVCzN2lmwVonUHPJR8Hj4Oh0D4wTAJOJ+lmYxuA3F+OFZsgyTiCdQckll2SQBesLgbCwF +QNQgTfrIBAPsnDhErJJuWVGOWG4lqqXBokvrptEYknQvvq/8ycWK36r+k8JyE21JLPcrC438vLV /NiNwTLXWBA/OVORqzeQw/jwwN4PUSbV9pzVagd0OspiM7l9Fos7Mjdutkc8rM3mMBvdPp/Ogw5l TpswD2k3mKJ0bN7vgZfyXpMvYsrQNMWgmbbeDO2FVhuF8DFHYCifx7J2NDnEh6a2x2IJlqBTDE5m Y3SSBSVITKSRWNA0iurgudA1NDsxAWCxKIQg+UhkffDjbV74yFEAEFzK9SldheDqX3YVh0tX//Qv h+EmHm4i4gah+PgPPGLx+6k/B0CW1OUcLp+NR94CmE8+h8xXE5mr8Nx0uXQI+NJ1nl7LrW0DivYi 146a5oULwNMF8PHw1oPsfM9Z2wWGZUk6y6ajiQRJZ3KzqTJoNqHZxGaQTKDuqmwaQ7nCfnHugk6r 0+nmwP7Y5nTas+h5UZvPtX0kAfCjP7x0vW5u7b+x3X8lHL6IiM/6niA0/rEbwddaf2aA3FyXr9Jy bX3XtZlhS5C5IjKf3NAIfjtqlrS+15Z+7cYNA37XFvoVf/IX/YRLv+H+JfU5Fr6YhiW26fKfFxA3 1585IJ+rXK/YR5evI/NZhLlRZm5BzRJ0fit6vqQu/cf1V/olrv/ajc9U4NLXxtent+Tg6l97TWK/ gIbLV15qPv7zJuKm+n8NkM/XZ4n/4+sN4ZPr45VLpeaaP/vk01vD8xlB197+kLXk534egOsUXAXh 05tIuP7XXv4cDJc/+s+Yrb+2ug3ILetalkHt5DNurpNz+Vqbuqk+vf55CUfX37/2+uTzb1d/hU9v /s2u/rZXXebSTo3LH119/38Zgy+u24D89vXxx9ezzQ3dATdrz/UZZlcN3C2I+p3rM3W7/MknN/zE m9v/5auUo9/24+tdrbdh+Ip1G5DfR338MTLql294z3VGf3ylPvo8WV+hPrp8/cmu3rzyVFeebsmP vF1fX90G5Hbdri+p24Dcrtv1JXUbkNt1u76kbgNyu27Xl9RtQG7X7fqSug3I7bpdX1K3Abldt+tL 6jYgt+t2fUn9/6gWY+cEomDQAAAAAElFTkSuQmCCEG4e8Pm+AgDr62BJT21F30S1DED90RwOUAul RXeoCSerJJ7MARbTl/+JUE5HDQoaCgAAAA1JSERSAAADIAAAAlgIAwAAAK2ockIAAAAEZ0FNQQAA sYiVmPSmAAADAFBMVEU7Cwy5Fhypl5hFMzWjCRy7pqokFByGfIErHCTCsrucjJgWDBQ2KzZhXmEc FB2Og5Cmmqmto7cfGy8UFBwfIDmJip8nKT0KDBSXnbiPla5DREd0f5mEk7F1hqQmKzR3jLCGm7wU JDwVHCZrjLR5lLUUJDQMFBwcLDxKdJ1af6VniatZbYIfPFQ7S1g3ZIY4VGpslLRNW2YULDwsWHY1 XXpEZHslTGUcN0gkRVosU2wrPkoMHCQoNDoVJCscLDMMJCwULDQcNDwECwwMHBwMFBQUHBwUHBQc HRzj5OMsNCgUHAwcJA0sNBc0PCAkLAw0PBRETBxETBRUXB1MVBxcZB5eX1FGRylDRBxiYzA0NAxU VBRMTBQsLAxmZRxERBRcXBwkJAxUVB1nZyVMTB08PB40NB8UFAw0MxRgXBQ/PBR0cDh8cyJcVBSG fkEpJxdMRBRUTBhmXB5cVCBMRB80LAw8NBRiXEPMtFnMtGosJAzatEk8NBzImizitDzXqTnmuErW rEfZtVjhvmbMtHjUmx7EkR/bpinkrTG2jCrNoTnEmji7kTfLpEjBmkfJpljWtGfmxn3a1MbcnB4c FATkpSfRmCkkHAzUrFjJqGirlGe7pHThz6mwi0m9mljUrGfWtnvIq3cMCQQcFgy3mWk7NSvXuo/I hCdaSzbJrYh3aVa2bxuqdzurlHnbwaDVqnu3mXgkFAQUDAQsHAzFmGyniGfFoYCOeGTYcBejfV63 nYe/pY+ahXTIrpnSuaTbw65kRCy2gFd3VDqldVFINiiAYUqJbFZTRDmmi3csFASFVziPXz44Jhma aUa4iWdwWUlIPTWqlYbalGgkHBdWTkl2TDVXOilnSTckFAzIckRRLhx4RStELB8sHBS2i3U3KyVn PCfRTRuYRCawVjMkDAQ4FgssFAw2HBQcFhR1JhC5Qh5fHw9LGg0YDAmsjIWNJxO2oZ3NMBuiKRe2 Khp1bGueioh1FhOJFhYsFBQkFBQsHBwpJyc4Nzf8/PwUFBQMDAwEBAT0xtZPAAAgAElEQVR4nJy9 X29aab41mKAgZEYt4AIJBAgkfGGwJuPWdH+H9wvMx2hpLt+bGfWoLuZm3lenpJFOIF2nLFlIu2Uw F7At9mbj0CgRsgdGlORqJW4hl63RKKkaTGwTz1zOWut5NraTVHefs2PDZoNxUvUs1lq/f8+Ts7Oz c3ydn7Tn0+G0g+/pdMib3qhz4HY6nfm803EPHNftjCaTyWjacdtt18Fj1513xzhzGo7veq4zaASO E7Re4jgaOJ4f+L7jezgGeDwYtI6OBkEweHgc6YnBEQ/e+avYbIk/q+UgiPRXMx+nMz+yWnmLlect cDLj66Ox2+3bWGyF913EYonVKoJjkUjgx46Wse3YKr7CxeUyEr9NLJeJWHwZT8S249F4Ih5PJJbJ eDyejCdy8Wg0ktzAWTyNC9FkPJpKxHPpZTSdiCfTuTRfFk3Fc7nf/+53v3v+++3kRmI7nUqm0+lc bjuXTaXylUo2tZHMZjKb+XyxmM9sbKQymdJmPrWxkclnMpl8vpTa+DaVKW9ubJSq1c2MjlK5yttS KZNJZXCT2dwsZUpZPC7hJ6pl3Jc2N8u6z2zidaU8LpQ2M6UdPbLHJn5MN5s7ur5T3tnh4/JOsVyt Vso438F9pVLd5G2F51U8o2OztLNVKW9W8fodvQRHdeu5nivv8AfLeB/9ON4Rt+VqZWursoNrm/wl /LWbO/wq7pgLJf4ddMu/1w5+Hl/8dRW9acW8B39Xxbwt/jl8QWWLb7yFY1N/uR3c8iT8m+qvXS3r FfpH6A3NO+tfpTvzvpUvjy1+6c9/8HhyDnC8enV2fjx1DUBwABLt6XA0JBjm0+m8QzS4znQfEBmN cH3aOQgIkW53Lqz4nusDHEFj0HBaraCBb88lSHzXD5yAOGgBAa0BAEKMCCfB4OW3BEhAeAghg1Vs 5XvLVT8SBJFVPx4Eq9hiOZtFIqtZxFv6i/4KEMPLbm8BkFgkiM6AjtVqsQImVolIMIjGb38fS0SW hEw8HkvEl8sVXriM4yaS4BPxSDyHC2k9F0kCO4k0QJBIRuNxgCQdSydzaVzOpdPxJI5sLpHb/v3v f/88F91Ib6eTkXQ8myZ8kqlsoZDN57PARb6Yz6azmRQAUgIycL9ZAG5wDqxspErAyUaqWtkpGYTg qVSpWikBR8RJaVNYKAEk+U3gjKc40VN6uiw84Cuj1xFQGbscuUoFJqIKSMHK5wrarJY3DUC2tsqb O1xcZbP0KjubVSCAr8Iq2+GBpYvH1erWll2euiE+tDo3uSrL+IFKuai3FR5KJXu2aRGyE4LGgJaL XxjBD5b1/rgpayXzl5dLqRKRaFaxQCIsFcv6tQZZXPK6I46eb1kg2Ocr1Qew2DLXv0SHQYjFyX8I IKevzs/PAJCzkTsXeYx6U8KhM+32eoTCdM6DLNIZ7YNDJmdnk+GoAwy4XnfedhoDQsVbuA3H9ZxA WGoctXznaAB4+AF4g+ggQB6Sh6UOnYhgBiAErz8OBn7sFrDwVmQQIAb4mBl8LCMr0ARg4eEuAYSs cIBwIvHZAgDxg0EEaCC3LIMlgIPXEimx2DJIbMcHkdtYPJLE4+1YFLiIxNOJHOCAS7Ht7VwCKz8a Xea2wSKJZCSRA92QWsA0cVBGGhc34glyTTIHnCSzJJ1sMl1IAwQZwKEETsFhYJLJZIvFTaxyrmWA I8UXVbgsUiU8m98s5be28IRWPBc7oVPKZPkDZBLykLnKlVgltWyWdEWACZnE3G9W8ALC0F6skBuw +MpYWVgi4JUKP/yJk+oO2WJns4wVg095QEh0AdBUtvBioEXruloAfwhDWHXFzTVqdsg9BquWSMI7 QG5H3+ZmUw/4bjslnZXs8+VyhbjYKZXAqUCzXclbdoWHRzkkD8t6W4ZADEAePHkPBEs0X8JD/KEv c/w7cfLkDAA5Pzt9dXYCBIA2oKE67hzqCmgBRsAfUx3AyHx0eXI5PDk/Pz45GQbAxVQE4jQgsLz5 PGj4cygtgML3gZ7WywFOAqIDN+AWYsCiwSqt1hovgVFc/moxaAX939z2Z15ktlhCc60WkRmOpR/x ARFwB67gJAj6MYIhsVrglREvsiJ/AB8JgOR2FSwXoBDiIxGH9IombuMbVF+JZTQCDEQjeHU8tx0j j0B64T4GRETBQFj9cWoxEAi1FM6TVGFREFIkTnUWTeZ+9/scySUKFkmCTsgz2Uw6TxjwiwBJbZBc JFJ2Nr4ViaQ2q0XcUnpx1WFVAzilTMqARHKrBIDkDVrypazFCBkEZMQ/eX107xTth7j5JC+V8FYp gybDMPz055o3q2aH67DKl2F14Cr1lJgBC5l/kU0ufC4/LN/qZrFqPu2LxBffBS83H+sSPmWjotb0 YRCilS/WKFLjrWllx6i/khBikFLmAXz8p5IeSXpxza41VeXBnfBRlLyzCMH1Ytlio/wAXVZD3sus rc8pZCukqn8nQF7JguDr2A2mw94IzuMAvAEGIXtM3U63Rwah0JqOjk9Gk+Pzs5Pj41HbX7S743kb TsT13cBpAxyB4wEqMCN+4PpAguv5DmTXINDNQ/cR3NMJTo8CmZPWUcQLWgFQcduP+N5qFgwgqiLA CiSW788IkD5R4enncEJALCLLpR+QKhYLQymJW6ovEA4gAgGGGy9BVkncbsfJLQkcy6ONxG0ighUP DEWkrbj4NwYJmpU4jEokDczAjQACwM4yLslFW7IBhPz328noEs8ko1E8AYxkCxUxSIY3GynjR1Ik kkoV5xtkhSzkGPFRKlYr2dBgEFOUZWKQPFwLsAaplTfWA998OZCRN1jZsZ/g4RkpqoSPfi5CKTLz qqoRRmQOrnIqLryCAAGbkEPkNIqEAh4UzUc1BQ8QAVuBq1ViYocAsViTd6gKnPzVOxJbskWbBhGb QEe5vEZNaJKMPSpJexUBDt6YqzuVcmhL8BcrlUNwlM2vWlOIxYclENKewUfZskgIkAeGxAqqEB7/ UYn1XACBCTmnzprPYTuGvekPwEWnM+0Nu9PutA2pNTU0guePjycAx/7k+Oy45/tgjbbrtedzKCyX j7xBYHASBMCMAOI3BjDrXM+t1gN8BEePlJZlkIEXHLW8xWzWj80GwWwW0ECATLwZJRaAgvVP4uh7 i0UQwKDrmC29ZeBHFvQdeAXFGawMbL7QEpGJpzZbCjn4ZZEYjXskHtsGocCYAA9LAIUmZJCCU0kD McBWEhwiTMQpxXA5EjcQIUJ+l4hGkxF5e+ivdJTePZmUyCKDVAuAC6XVBkx8SuY9D8eS4srPgkGK UFwACxghS/BkrdQCDLJc5jAiQM0mdZt0F4CDD2bIKKirzeq9wMobW8xl+tDAgwbwVZGvLhbJEgII cVMVQrTKd7QicVoqCkwABfAEPVUscu3pk1sCZ6coJhRKIBzBFFz95ZBJxGQ7MkCbRb1z2Vxbk4fQ s3OPIdqVUnkrNBRc4lVrW4iPonEdocHYsuteNqVMRN+bkYcM8pA/7hnE+Jv/OEKeCBwwIu/Oe/Me /MdwZGzHlPgYTskd7rzX6xEm08nxBeTV5egYPsQLXMKBKAkCgMRpwpAEfnsB1QWIACGAhuMHLb/t U2YdGRI5MtA4OmoJEmsbgrsWiCTwgQ9vdhsLWjNAY7boxxaLGXSUB4Ss+ljyoonVAl6lD68ClCz0 gCpr5S0XAEhEz0eACJoXevbZzI9QJtF+DKCvlnFINSqruLHzQBB4KAGnzkfw8AAMBRo9BxVXOp3Y zsUBgrhCW4MlVFZ6YwOwgOpKJgENwCUNnw6MJLHiCwUIrmiKX4ZUQB/VKlZ9vliAn68WMt+KYDZ5 kTEvoEEUA0RkwRZy4XmZEcJFkSO5k82dfKlczJtA16Y18fZzWseOeQT3UzAWu7hpzJA+wQ1F0KNI XVFFUVMVRSjQT7T3BI4CYTshQO6DSWuPTgYjvz1wIztr3rCPwnMjCAGMsoJzRUM9VaOYwo99oAZC zggw/D3knqohwdxbDlwq5jfXgauQQsxp9bHA2tp6YD8MPL6ise6tydfx8+T81atzwyIn8/lIB/hj Pu1RYBn34U57o+EcGqs9PTkFQCaTE/BIF+zgzbtTUAYYBPacMSuHIsth7ArgcLDw4ZwD6CYrqo5a 90bdAuXbbwWVFp464msXM7yPHztctPz+Ag4c4JgBM3jDYNYnQMAngARJYxHrMwY868Ofg0V8UAXR BajA1gNHwQByarZKeIMIo1nQWpRkCgfDj+R0GokKC/QrS6KEJ3QbeFJPASTCSmI7FknGctRk8cjG RmT7v/t9/OiITiSSlB+J4iaepilJpdKFvGESQiRJ9QShls9EU/Ql+XS+upUlu8DRVwt5CbBi0QS9 MlkGh6W3NoknnWwCRXlGkjeBtRIZhICiHMtYfFgtZiQWly1+KF8kc+A7z58sVAtUR1hJNCSU/2QT 3hSrVnIVJaj4BOCxo7OyAYhwYvEhojAKL7wNAWKjzmWhwUaCLZUYeWW0mLFQVHqyIHLWVZkT/FxV ADF+B8iuWqIIyYIIKW+Wy2uEhNbDqrHPLfqjGNavMIglma0vXfxzMsirczgQGvXz8647muDPcEoD 0iNMZNA7bcIA1r0Nm35ijsnJ6chnxGo+77Whslz4EEZ0mRBhbNehl3ACAxDInZYAYvIdBhqtljm3 OZAQND6w4Hse9dWAVALmAA2smj5Xe4xgiNC+i1IWDGH5IA3iRQCZgW2oxgQRMAiE1ypCPPBBTKHe 2+3beBBd0srnwueosUAduDG+hZHgNO7IJ4BMnEY+B8DgO0IHH92Ixrd/tx3lQTgRIXF7A5bJgkqi G0ZiESVZcQiYZYMeJJtJFra2ACMIMlgUCTC4EzzI55MESFa+hDTBGHKKa52mPYN1kVE+pUSmkYEH 4AQHWpS8tfSl0K7nwTb5AlcjJB1WfDGkgSolE5hDcp68AZYB1RR3iiVjxYukj7Lu7fIshxmSMDCw jhI8DPha8rg3IjtrGimbJ4o2eUIuK5cyOxWrjuBMdmhQivhNRcMcTOoIO8WyWfnSYopVEeg2clUp 279hRbD6XF9VHq7/fyyxvoKiJ+cGHDwm7nxiGOQH2PWhjV/Njf9w3QN33p1MaEJOQCPHE9eHpnLc cbeNxUoSATQchXppzQPg54AhXzoOWXCCwfDIkRFX9vwoZJVANgQM4oEwvFnge8oTemQOD3jpM647 I2xWyn3gAIcEfLxYRIQXEgrO8DNLvgoow1lAOOC52+0YFNf2LRY+uSJ2u52ICCvUVzPQRKA0CbMl iVxiuVxadgHNRAOiBJ4jSSMSWcKbMzScJEREKvF0Al/pSDaXy8U3ILeiyoCAQo42sOpT0F4bxsHj JFup5PJZOhYhI5UXhLJkkSItelZRYrjzoix9PmvzH1nzkDxT4svyggjAIbu/KUbBNQMVogYrsVgt VHcKm9RLWviFypb0FZ6tFqBp5C/0jIlZCUA71TAZV34Qda0ohBUi4l7XbYb5ypJBwk5550F+xNya 8JaBDp5mJItEiFWrVb1jKMakF41BLzO+LRiEpj1c+lVF4dYWxijB8peh34fcUQmtyD+GycMXyIP8 aPHx7njuDgkQJtJHsCOgkW67DZMOS+Ie+G572mMu/YQCCzdTH/bDd+ZjgIe5dR8o8RsBOCSA8cCt jzfC1wET7CEGyBetkDnCDPpLISYQXLzmyhNIFvjG+vfBB6AOPFjFDmP9PjQXbvtUW3h8G/P9ReCv +BD4ofwCbcwWETn6/gJrHl8e+SQSRG5/s4riRyIzMAlAEdv+bWIp4pgBFgoBM+NIi64UCpa/8iFw MZBbeEh2SeIHkgY828AIvP0gGl9uJPHCGOx9IgHrv7ERZ3wL+iojgiimhQxBwuCGceFkeC2jJ0ge yWwBqz9LcQWhlTUAIY/AnjDXTjYpmWwjA8GhwNJ5RoEu0g3jwgRTsVDYKXDt847rimlInAAThaJC t4VKkZKNwS25f8CowHCtFpvuiuW1yGIAKS+I0FasOUTZyXXO0niOonUh9O56pkjM4KZo1VeZhkMp G7FAWbgq0p8U5X9IE/jHMf9hQ1cPUxzGHlmRZZjDgvhRIuQhOB5Ykb+HkDD69ZBBfjw/++tf/3r2 6kfYdLcHfPSYK+8RH7jtdKifOvDgRk9RXR1LY530fM/BJc+FNycqyCGgDp+BrAEcfBBM9wG4kwnE Wqfj2CDWkc2qCxcmh87jpYEKYLIaW2XlDTy4iyXAMmvCZfheP9YnffSBi74Hiond/ua3tysf6gtP wXUDITPSCEjDp29hEAuGJvBnkQBCKghiZBAsdwAEl14ub3+7TUO+TBAWt1BhcCmrBIEi976En4cX gbCKJxIgmCT5JS63Eo9Hj6LxxHZII4MofDzUFVw9jTteGlH8K5nNRKGs8knDHUkKrZQx70kKKaFE /JEkYoADWhYII6Aky4Bvlk8zOa/KlYzowubjwwR85h4xdC5ctWWpss1qkRUwMCMFWBAsJrBNNVel npLmKhSrW9W8rC0T94xfUf/L3otOlCAs2rz1A4tevM8W4qfEFyaMy3VuCCNEi1VaxJlyJUQffQrw UeR9xTBC0bh4yqyihF1R720AYsTdg7VvMySVMGdCYKxDCV8ej6yILvxjClm/hh7k9PT0+JRM8qY9 JX+MesPu0Bp0U2UyF0jabWiwU9CHdNbZCEYDCIED8ViNRRcClTUgUDyjsTpDvNnJ8T7eczh9nEZv qTaLzlzHt4KISrNmzeZYAJk5/moM5iBcZgSI3HggMPT9FhOK/+1vABVmIxe4dts3qfUFjEhksWDS RPEuJuIhobwgElstZwDJLALHsgSdRQgriq048+00IqsEQAYESK3Bn8Rp7Onwc7cJFqYs4yKaZDwy 2Igy8AWIsBRsY2NJj85cicK/8QjzjFRjtCYCQ9RSRUZ6S0cyEwaGk5l0ni8E4zDxUilkU8BHkgCx lMKYcCkl/SXrTq9iMu0WHib/bmJYeRPhYgIlDYDAn2PVV3KGPzL5rS1SCIXVVsXYAEW66DqKRYsP oIoLtljcCeVLtVy0iDDx2xAAemhiu4ZMSqHIWke0SABVm0Zcw0yunGt2J29gROohRoUZ/SICpGqy lMW1Mb+HiXKFVcMiYci4+siqVyxthInCf05kPTyeHJ+9Oj47PVMcazJ3jS2f90YqWewcdFSxSIve 6fambXd0DDRBZp2dHU+mQcBCLEaxCApWZJFDAiUOGeF1Wdm1D7ohkwQmsmtLTBTPMhyC05c8eanS rKPAazZnQgVBQv6YudRcuF+NfcWymAkJAr9/+5vfHK4WLGjxx+APCa/xoi+DAkgtYry4iil74h8F gAMRE4E1gduASmKehUVdiSWwwuQi0LAiMmjZVxE/Sq6Jx1ZRPL1NawLrgReTSCIDphOhwcguuVgC HLKxjMPZL6MbySxTkcyf4FFE2ZMl6x6x5gGIbFpkQubIGoEFgDCJKPwo5pWnJiOBZCyLsHSFHl55 eKVNhJCsrfey+CgZEpENUVC4uFVN06aDPyC3KuQG0AiVfw4OhAwCg7LFPAOohv6jIG4BKvTNj/E8 z6sP6WOzvLbpxn/A25dMimPTiK31Ubw/VaEK1FixWrYR4B0KqrJShOFrqPuUN6eBL1VNirBqYlth LK1iIbBlAFI2PCKOWxdofVa5uHV/F4Lln+AQe/ZkcnYG/jgTRk4AEFbvuh1adaiszpx1WXNm1g86 b173Ok5nBDidKJ1+cgJZJd5wmCUkUgKHtSb05Q6dCCgEb7Q/OT4Bk7SPTE3vWmgRIN++DFUWb1rC jt8GLGD8feqpJnHiz1Z9z1mAWUQt/cPDvueNF54HRCzgUsaw7jgFEvCKMa7NGAsLvAWhtDoEZ8Ru PZZC3t7GAZ1VbDCIkFWig8EyQeuOxT2TdBJW4sqNqEY4DncC/QUQJBYMcgWRBCsflSSJ4zpl2BK2 IwaTAkFGyNDZs5ArKfeelNKKm7MsUJLMFpM0IQr6EiBJY0CypI8kbUgyKclVpMbCAQ7IJJWFVxA4 JIuUjQfnBZBHVJJR9r2aSW1ubW0WdFQLQEpegMhn83gI3BRIFvl8oYLni9n8/WdwMUQFUbJD+iGR FNeGe/OBMzeCDizzMJS1Y/XWjiUQgopWAexguYXyqSyvrWiV9fFSa2WmBjfxLyB5VEwmp2q12M5n HqNiK4YtPORBQgoJUyRba4hs/bP4eICRypPR6TnBcXp6dk6AKO0xnSqnPmQ2fUi8ADQH89Hrnts4 mMJ9jE7O352NRqc9z28TFw0VmhAkgYK8wYB+BABxh/uXk9Hk+Hj/u+Fw8K3VVWHy/IHzsPfUXqAQ 4oPBXryF16Rhx+qH7Gpi9c8AizEllk8W8RcrrwFOiY0hp0ggi5m3WPUhzqi7fH/Zv/VYA+wtYF+g 0mK/ia0i4KVBsJwtAw9OezlLMGc4U2Ujk++gDpr2WcQm5gGS5Wr7t7dMiyQInSC62jZ6TCmV5Yqe PgGTb9wJMJfejsVNkp3RLeNb0izvikRVtgWeUOYkWwgBkiSByLjrT5ZsUyzkDYVQJaWLrIEEhxAq ISwEmazBBXRVscT6lU2TkwdBlFKbUC9FLv9CzsCiWmE+BI+hu4ACnBAYwE8xn9k0iXKSjHQWnxaV MHvOxWfCutXifRTLAkQf5SXrPRSNuqeOHSmyIm0GS152itbRl1TkVbaV9nIpyhUariEEKzZ+VWaq 01BHsVh+AI1q2eJDRVnrYNtXTUh493V8fK67wmgvX/5kdHz+I2uxTvHnuEdRZONYU1Vm9aa96YE7 pdCa9zoHjguA7E9H52fHw+HxyPfnntd2Bw0XLh4rt20aQGDaF14wgNqasodkMrkcDfeHzj1zMHEY AAzfHt2XZR3Z9Lp6SaSoABQnaDfJCcQGATIDpfjNw9tDiCrAgdW/R0H/FqsfKKHIwg/N+gAAzDoD xbHb1dEA6IDGOly0Bqtb+HtoLAg0QABSK+rHY+wu2b69hSlZSmHZanlZEXDELBKN3/7293TzrNpa Hh3Fb2OJGdQVy4aZSGSojAmWGMx+HGSU244tN5ZUVzArORV8xU1pcFTV8klDJhupdJpgYTIxay7S gWTkzHFfAHNIYeFTvlpNbnxLWMDQU3IpsqUKR2XcU5kquAAXlRjJm6aTLBtNSiCOfCHHVCMBIjah AUnn0/qRTOH5c2KlSCphVhG4wGorGCdSkCkhTsoEhlIZ5bUksnlB8/m9vlgyYqscVmKJSCTQLAfl 7cuAOzCCfTumQAg/5Qn1UzZ2xviXLbyvlNfLf8vmDxk5NnqqHFqRtVWpPoZHaEe+oqO+yH6EZY14 +ZPh5N07lStSY03cDpY0ANJTa4hivaNRpzPtNICQtsrgJ2fHI4Z64dQnfjBnEZbrMMwLBpl7Kld0 A+YK8SHecCf7ZJwhO0mmgY3myn4IIC8fpEDu4TNwmFDhG/Wb0GrNWH/skUrGBF8Tb9w/7M9c2I7D fsxrtRZQXP4g4ENl2ldc//3DGLgG2IG2cg5/ExsDPQE9DUwHKIO59NsVMSGXcvvb394G3x7BtMej xqBHPAFiBYePk9g2UygkHPz1NiCxmDNhseOSRSlLHvAqsQT0GLkEfgZcsVS6JJYDqFTQFY/oLCG1 BRkV3cimSSfRVFS6KptUpYqMiLkhOgCbDNlEVV1WaNHBM+aVVOCL1SolhqgAiayJDotD2GZFsKSx 8qmwsEIKhZwRXFXFtkhPledbZJdCvrTJ9hZyC1YW5VdFUKIwY1y4bHxHubizhocJZVWV3M6H9iRM rBdNrRaOsi11ya9hZWz+pgnzmroucATxo/gVf6hYMaVkRAh5Q87ksQE3ADIlZWE7WPkhgXyNTb4S yH1YiPL4ggDSGZ6/O4e+Oldr4dRlHMsgZAqFNezMR29Yh3XQOoA96c0bzuT8HC59pFRIO2jPA5c1 i07gKJ7ly67zITMhA2e0fyIHAicydExRYnBkKrNsxvAoREiwTrPD+gMhtN5AhjMbN1kVTLHFw1Xa A5hpAidjf+BTWrWDBvOIM5KM4CS9hfvb3xz6cudwHvgxvGUTcKAjgdwC+8ygvYIVvTr0HtDDgLDo w/NV7WjSiMa8w2VE6d9XiYjPeBYJxKTg+R01cAE8KMsALVbSL9mdpWw7AUKHgssRBYEZ8BVxUGTh T5r1KARI1tp30grLu0QVSRMItiwBJMi20OBnGRIuKDvOUBdrVaoqVsFrobNKmZ1cpZBPFwpblVxB iotHmjABzIpbzysKdBWKLIOBluN5TrpMlp2MQ4AwA5JnCqRYtBXvNku4U1TbS2hQdu5P7QvK1q+L W/jTwMIO0/YwSRWDEMavdlgjWbYhMnkOLdHQnz9uHLSVWSZDYoq3Qtm1Rkf5kVV/kFx/KLTWFx8g p3KPF0isH6Zn7wQO0cjIndN8MBMytJFe6qzhFO4DZn00bzS6ZJrJRIW9U9gMeo85GwzN8vVZ404C cRYQSMEIr5oo/TgZukcsO6GmCmxGPYxmHZkk4ssQKtBtHjgkaDT77Fj02566d+lsAEHH+PQm67Zw mcJrrIoU1aUsxv0FBBasu0p+b38T82axw9nAHx/2mWb3PaVR/Bmz8EviI4BAi62OjgJ2JS5nTKSw +Av2BECgHWHmfrlcLKMBa78YClan4oqwIJ5UxhXgAbwNUyas5VoRI+xqzCXII3Hl5KMBMyQESDy5 XCajJgZMQyJMECGs50plpcOIDqIAf2Tk4VP4WZ/JFgwAyCZMxmeylWqaISslUrIp0oAaTwCQfBZ2 JFdIZ9O5rVwFHJPPVYQQ3Obx3jmwBE7SMBxpQg/SqyADQoNSFU74yoJKVqw1zz+oG7ZMULYmfnPH YEVYKoU1KZZbJKTkUZjvqO5sZDa5QE38iqEAVl8pWF2s2jVaCUNXKol/3PGxNiPFR9WLYVVW+YEi e8AgIRzs7ZpW1nb+cZNu5cl0CMetrnTwyOnEdYekj2FPAKHM6jhLjpgAACAASURBVHUhtLpTNRn2 5gfO/Ji1JgDJ6ORs5LSAj2633QCPyK+rYhH+GCta3SBQbPuT0T4YZPR2PghbbtcJEVvSq+KssMSX kV4ApN0ctz2v6zEJKWzYg4Utzgw2ZOw0fIfB5fFMNh70ETiLQ6XZD03iJGjhhX+OLRb9RaOlAkYT PvYDb7Vk2dds1V8awz5jZMv3I6bY0efKj4FisP4BlJjRWkw3MtfOri2Vpcwig2V8JhaRRQfDyNon 1BGvfD1kG+6ZjI8wj6IXRoSSuKq42Jm4AfmULqjFN6uSYHYs6kxBLWNQUhlgI5UtFFPZapVQAY2Q SICIklBTVI6xqJ4TFa9QbFFjbVZz6XS6kMvl0vi5ylYObEGSSGdSRTr0XCELw5MWOujM8dIqTYpK j2Hwqbfy1pJv2kaVTCljAGOKiTftR39IHvkw2mXlFla+EujVvGK2hEmRjSxbjFhRgKmNSt0tLMes GD219aAppBwCxNJD9d5bsIQ+7KFa18bYGq3Kl5gKcbC17iR5CIu1DFt7kOHk3OBDCUNVmyiCpdZz DmpgUr07mrIWi0FgF+RxDJm1jx88dge+S+vhEiFavC7Jw3EdrEH6EG9IdEz2RSG+YQjQSFjVexQ2 E9ociVVZMiBt0UTb9Zqs8mLbO5ik2eRvaTjQV0yKsK7Rw5lDhIASBrPbw9vx+PaWCKHZhwk5POTE B2UcVaky0w/NBCEse5Z+eRBH/pKlW0t2l3jATASGHqyCiyZ3Ykq/VrT2K3b74qWM+y5FL9RkEUaB JbkArUjAIq+ImlBisCWJlYmKLdWYqIpIuZKlCrg2NuTT48kNdigKGsKFiXeJXMgkhSrJBWs8RyZg 3TxppagCYOZEUurJMsnIrLglb4BizQeIJA+gVHJkBmAGP4hnqnicTQoehTTAQbuCg4ARPqpkEVvr VSrZKsk1gxhBtJPPl8vmQj4kjTDZLtpQnxRBkjeF9DbnuMVGEAsiBbgYcChZ/aRi/bIiV1Uz3cHW I5rU4DozXmXDia2LZxw5jPtW7tMiX9DO1sPkyCMOWcPHKq4nk7dMapypIgsQGdKEgEGU/IY375z8 hU69+wbkcdBm4WJ7CPpgnnA4OTvrBcqfK1nosSTLZ7W7zzgWTXrgBXMiZAJfsz+ZzA1l+N4aGGFL euvIXjIU4tcJh+bhYdfxm+NxU2NU6Era8zZR6JAecJXdIwDBIZxKE7Rx6PnN/u2f+7MxXXzg+yQa FXD5M0oprx+bqdhxwXkpbA0mTnyKM6baZ1jWuPOWeCVW/e3tDB5lxTw8yx1BDLAyUWM7lqnoAMt6 g8WKcSxx1m1tsPqKZe9RaKloMioSoSuJJ0ypcFyFwnHFfZNMMBIyLPZaspskubQBrXiWSXggJJo0 CMmmpbWyuXSK0FFOhC2MaYGAca18pcjzdNZkSuTuM5kq/QrMPYQMeQDIgNAqpJkRyfGcuounDAJn iRBjTwiSIkRZ1iBFboRKrWSSkHmV1pu0i62/4tAIk7u3ucNHvVTquLKNhPQbZZtEh33HGlwDyfRG MqhlmIPairJLkyLyZTV/lR8lzS0+bKGwrTc2DSVVGwW29SiV8uOZJ1v39POIWO5Lt9aO/clouH9y ztEm1FinZ5N5R2FewKPLTLo7et3r9Tputzc9aLhTZkTaJ2cQWWenJxBaE3ddY+K22/IH9OlzySyW v/vOkHHefSUMR77JgPjWoysXEkZ4Hw51CLy65zccr9luOL3DbpuyyietND2etyXg2mSWJhw8IARg egwGj8fjw//h0G0whjb2YDsOb2/741V/BpGFazOmGhVB9lYiExAIPf9KtAISWar9fUBcyFfAXuPM CKdlJLbNokVChE1XwdIHaOTlZ+ainhOVRNMsX4GmUk9vxLgNUyecMCCRa48oEZ9g10ksIWwRFYBI Gt+paCatRAlTIfiMrxRSG1ks3LwUVx4eO6kwVypV3NpKp0zslwXzWbptrO8Cb6mwKrjHD0JhZSGz yCK57Rwr89MCSZ53YA4LENFHgekXoUMGnmRUSmXYupUtZTVYQpEyazCqJQ0wKtkOlfy6IN48D4FV tMbEJEFYUaIIWMXm0eVwMplN82mvVIwpyCKFFPF+Kjqphj68el+YaLORJk0Y4iOESyWMAX+1Rusz cDwQWg8OSCwygSl6Z2c6NBZ8R8+YdHaE9Fiy2HB7PbdBNTWdAyAnw8nx2Smk1mTuc0oW5BXrFgEL f+6xMx3Le+C6QdAInCmAAYDIhkwFhECTHMJ+2/Vck/u698EAaKsDEW2g5PBNDUpt3G1CazXbwAch 0jR3DPviIJt4fhuvAEgO/3zrvmy0BmMorwU8xqFcyXi8Wi1mfCMWqcw81v8q/e63PEaHm9BYwIdH T07CgOFmE4lJdvhEU5O8NG/Pu/Nuz+SKoBpPJsPhW9Dj26E9FNOYzufdNzBJi4W3ivXjog+WarGK EbdZlmhFmEEkwaxo6hOx7VxEDYopQCprrAlDvjrk1gtbhY0NfeyLV/KUYtk4/PtGBrZC+UXiIyNt RoNSVJ18trpVsRlH/GJW42uw19Y2pBrejBPAskJHmpGtgqxKgXSSZbKdgouEQv8OAFSrDBzny0UW 02dsd7yKTVJ2NoshlrytO7Y18UWWh+XXwWHDIqoMZme7sibVsmqRq/oIL6tgC9DIi4Dwy0QgWuXr 4hJrMsqmiN5MlCizfkUNJesREI9tyN8HytfqtAxAhA7RyOlUBVTToTpChqPu1DRPuSpcnPa60/Z0 QsXEcsWzk8mUHoShKzanN9VRqHoThzAZsInWHV2CQYYTFWSZOsUgaD1gjwe1JiaZDvz4zRoXf63d bh723FbLZUgXvqPdFDra46arGkb82tms7fMSsdJu4jV/PnReOg338LbdaFB/3bIuRda9P8aJ12pQ WSmn2I/desHscLZcJeSwl6kNrFUmU/APGaui+c3rk8lodHk5udRxcXH54cPF9fXVzYeb6+vrm5vr p9c3H/FHB+6ury9uPnz4cPnhAi/lwZTRW7q6N6/fdOdz/E1WKs+SZ9jgKk2DW9T+OwOXEBsWF6p0 zPJxGkakss1YV9ImTeTc06ZABf9bWe6ogFdSNkUlKsV0ER4eSy5vyrbwRvDmwkFuu5JLJ5N4hF9f SccLZBGiAY8LBEia8CsYSmEIK18yNWJYzcyw5O18FVIC23vNXK58UbXEBidhEMv2c22qg96CJE/T bhOGpjq+aObl2W7aMpMr+aK4J180Y01Mv5Q16qEHN7AIA8QsEVZF8s4aIHayls22/wpG1t78M3w8 19AGfLhPjt8BH39lPv3V2ch1h1ODEfxfVa06y957qjfpYM3gI3Ro226BkJE78Di6AVddOASYdlYr ek6rsehzREkwOJiO9k9O3g4npJAwVxi2FrbozhXstc1TElhqr+2Oa91+v9utOS9fvnS6IAKKLUKB QBiDQZqGSWZtsQgIptskIA7HTgskAWfSaAQeYNX3GrLnAAh9Sqvlz/A+LAMGj3Ce3MYyFqPyWjXr 9d7r16+Pj9++fXvJFf7h4ub66opr/+n1s+unT58+e/YMN/jzUacfn/L4+PTjx6f2/LPj2fXN9R0g 9PHDzcXVxQdBRtP3erBWrBmLrBKyDnDILFlRBYsa3WVB1KSYZY1wYbsgUZSE17HBLhPxynJql3Iq WYMDeZFM1hj30tbzir2e4cC7giCwtU0m4fhITvkqaPAXr1uEEDYK+malx9J5RsVKDJltVmhB2PQY tmWxClgBLFavYLmbPnn1BGuOEft9CR3VGJdMGoUKq2jFV1GlJGFevlRUb4dteWQOn/BhBKtoUiNm jYstqsaRMPi1ozDYjsLH5Z2dYhjMMrVZJo1S/RV4WJB8wR3PLYNMWCv1o3UhZ6emHksl76Ohsupg j+5owkkOFFzd7hQijIFeQIQqa3oUqFBx3PWYTw9ctwHz4A6CRXfOkSbBwB2NxDmAyfDAdIMEquNt WZyskTEww0n5jQXcPewdHh62Ocu01e4e1ro12HKXX1RaBEW7bdECFdV0GgBH0wW5tL3FYt5cwKQ0 F80+/HvTZBmbdCiHfXfAENvKWyqJ4cVwpftmBKUEknhLjri6u+OKJwAEB97Y4+bp02s8B8ow318c N+YpvmaNGAukZ3d6H9yQeyxWLvnfhmBZ3cYAgDhkFYeeRtRTYnLuyq9zLUc10pHSi7xD5GTZ3hu2 XXFNwztkWdiVDUkjg5VBPtE0oaxMRzL9++c5EkU2zpFegAp+51aOWUkeefM+GiDJB9RyKiFWH1eZ 7FFi95aQAhxuikBwjYFbKjA7rshAREShGLHRWHok411UZIsGXMRiOCfP+iyVDtOQF02dZL5IgOSL 657bati5bkDB+UWKkgkZ6t0thkNPbcxrPYfxK17dFl09Zo7n4cmTCczzJbHxSrN/zk97zBWqIoux XnXgdke9+XTYhlOfd6bdNgByenIMEmFvyAiOuu00AnYdMsI7nwdHDZcmer7wHBaWBEM4EIiMycnl dx3rMcKi3gc5EXUUBstwOCn0VbfbPezWAZDGQbsGdDBMBq/D2cBuW+YD6Bjj7wP4HHb9ho87r+G4 II9mc+40xrIf7kuvPwamfLc5b7Lbqu8PWi0P3v6w3+5ORydnl1BNH6COuPztgl7Dgav9Rut9DYGv AuOfOAzRfHz0K549hSiTFjv+CwTYmLXGCQ5DzZrqX+NGlsBHTnMhZLRpVLBwlR7BQo9+C+8OvpFE YvmIIJJU97sKVtIKE5NQkmnSU/r5Nn3INqRdNm4kHjRXmuaH3GFgp8F5aRJOOm9rhItlQkQLWi3w mhpBfaTxErpSUiZfliNrUiesQtFPmNBvRpLK1LXjJ8vqAMtsmnl0rCAzYSqOs6NTJ5bMGBOZDlJJ RcMfizuGLYo7mg/MxzuUVkU7E9i2C6+Hl66nonwGEltQ8jl1PN8KQfJETlN59FfnPxIjI3cOUAga NCITnHe7sB9wI73R3O3AhPRGJwLIMRPqbmAmWS/m7bYzaMznzku4DH8x9z1SCI4O7Md0uI/b4dBV IoQeZJ0xDB7cDsyoUkKlXncBi1r7+wZDyLAjMDZ1RgTIGy5P27zarMH5tAGFmuc2+2+64K9uvwuW cQL49cP+4bjVIGCaLqNXMO2xfr99cPDD27fHZ/QT+DC/tsj4e6v7p88Q8tOvPfurP/4YVxJleCfL KU9voMOkwE4u8cnUX6346a6lnaHYogYy01OWcQmjPMdw8SW5rezRRlrjVAxmsqZCRYNUsjaNkk3h BxQcBsDihe0c3To0W1wckpR3z+U4OJLAsLARQtLGjrDNK1OpaspdxigmOJJiNs8xPGzdMtbcRAeM SRGFqAolC+GlBpWShuZVKblsd0nedAxj2RbNkyw9Kdrhj2WVpjAwwBla6gsxI4t25DvIG2QO0+Gu Jl4CgwwSTsAOh2bfC6zP4FH5or3w+RohIYPsw4Senp//1YZ6z0/c6WjYoe2AwCJOphqryGw6T+Az utOp+m45weHsrOcPXHc+5hM8/LnbaLUGrrfwVXVCm06FNTm+wM1kyjoTaKiXA04lfUwhVmuJXY5a Dqvom/Tp7XZ912nX20CMPYgWF1ea41q72207ThMIGbcdt3bY9GFFGg2mLJv0IzD2gXfI6G4QMPX4 ZgLrdPnTTx9v7u6ADHyA3/waMn76lQc3j575h4TyjyjnRi8gSPWFhx9AKZNRlzX8iTgnXadStAkU Q8y5EyC6IcXktnMpuJKUMe6mKDieLKhUJStfYuJd5JYUmYepSc7CE+Q0N5VlMLntbZqSdDobosLc 0ZUkM3lNra8qR68qL9XcF5XU26R5Z5lxxqZI5E7IL1kJLE69K5qJKxzWgiWZJ1MUSwDOpokJ77Ad WMCzg+SrrIEEdTChyNByme7czAjeCb2GgFFUhTw1FijEqCuVza8TI1U792Qdy6qukbFmkMeu/AE8 jEmnZTwBeeDPO5j0d6e9LoDBTOHojbY7mHZ7vO31uuydAk/M29MhHDqNOhbb6dx3lU2fq1oxcIkQ xbU4XxF6H4xES78PjJzsTxvfmkx6YLdCeLgjQsvOBdLkRcetAxM1WPX2nkRV3RVA6lBaQI1rDEgd MOgCSjWIrDbuIbpqXZbEd+FQ8KMw6/0giOHZ7hAm4+Ls7OLq0ycJnLu1m/j70PiV4/r65h4gNw9u df/wbe2TX/6ym8cAUhTMstmN+OQCn0JvDmdxjTXJV+GtOUgCK9nQSNxMz84mN6JRW5CiI4OLKvLi Zz9pSDEpE9wSNRBuCb6N4EE5lzauPTwKoR0hQNgWz4Ji1kKa5nfbxcgFX8SdpnplVfqiPCUtvTjE zO9mLMqMxUupy4MJlXLRpB1pa5QyVzU9xZQWMzCl7nRm34GdKqNXLLmqhuNNyR2bMuRq6JXUEncI KXYGt9FTtmc9dOj3jVSfR3Sff8YiumEUa3Q5OXv37sd3fzs/PT579+PrOUc3cHbD5OQv3CSkN3kD 8uhx6rvwAYBMNdjk+BgO/7TnGcsxZrahbfIfrh+4XtBqBK2A001OTk4upgcslB8efHvEROFn1BHm 0cPrdCLuHjiitlfb26u1KagciSvABOQhXmnvybUDBo2GC8PSb3pSXiCVMbjF7FDi4emDHvjx4gND snd3z57h22DjVz7afw0eN49On16FELHvxFiXLpGVwmeora6v7wxkbm5CIJmnrw0XffnXuLFO5frZ NR0KOL4/9maJbc35TVH7wEoslU+kD0kTH/F11VYyi2Wd3EhJnlkHkrQWHIjKJdLkjxznDjOjr1BA gvmRuIYXMU0iGGUNUFjQktGI4dRmVXUt+bxqJDm8S4Ap5s1OJ3LzUFgZaL2SKTxmzdWmGTNscudl 2vgSbX1R9gP+gzOtGO2CEclbu2AiW2aMYlUmnd1Sxr0Xbe6RRCKlRYQUWS9JwSWUFDfDUK+JBH/R qv4rnenPt9beI7zw5IQdG5PTd397B4AcAyB/O+WQXlr00eTNyWh+MAU+NOFkD6ux02bDoab0gj2O Rz+MjoeDluPgA3/e7Y2xYBsDLFe/ETiug9MgaDQG85OL/cmoA+cyYq6QrNEKB/J+edh9dgKnXq/v dQGDvVrdre/hrXfBJa6RWrUp+AUIwkMJLqAHzEHDXoMlqo2bTI3XQXX70PU/ffj0s1gDy5qy6jE0 fvp7oHiADWY9Qi5QBuTu7urarncDDh3KhTxbM8pPH6+v7qDmiJkb+w431yGg7uH1tePp02sTRgNM Li/fnrw+XESi/OyGXsL6h91OCCBxkzzJxM2EYKbLdd2Eg6WwjOAii2D5xxIcZp8zUyXNAGLiBVQS T5ux9vxmxQuYiEjYyGhGKrWUyiN5midq8mwezqplK2MGeim6DFOSZaISosm0b0lm5Zmz5J4PWK/w GxXW55cUyVLLCJMjeauGynml34tsDMH63qpoJFFZTSMs2tKg382iMSIqdtlhy66mQxpvUgzz6evJ co+d+T97PFHD3/7J+bsfX7Fa8fzdu7OuawDC+T89zsJSsWK3N2R/esf1pt32lCNIVfd+cjyEXnKD huNr1rvrtjRUkS0dgWOGjjaYSj8Z/cDSx5H77bdHD3TVg7JFo644XpFXg2DXbXfBHyCtzp5bhxup 15suYQFC2Wu6wgcRQZ8CiLSbbegqgMRpDZrdujsdTi4+ABHXAAYW8/XHL1fjTx+/4p/XiFif3NhU 4PXVlWEIvB8uQKvd3YghCBfg4EoI4en7q/vfdX316f37T4KXwZhwcvMAH//QpCie9vTu0/Xl5WhM A5/ObDAxmDYbldBmc6adIlLRZWF7K66naO4LqutSBWTSdJik0wmz90lkmdTw4YgUVkKzU+OaRJw2 DBKXQ+fw4GylmFKYt6SMPYfW4VG1kNGUCTJH0iCE0+xUI1nKajoqUAIwVcvCDpxEZuPbb7Msq6Ka 2uIuOopObZoqxjLzgvyoL9Lhc9Mudk6p9IQGxNRzle9benfCO8avhAtDK9JZZgjdo3FA/+RUkwcU IonFWpDTdz8SH2fMiIzmTJazZHEIO/76dZcGZNo1O+t05tzwwD0+Pz6BYzkD5wxbLwO30fDnShb6 LpSVGXYCb+K8POJOCD6nm4wOflAxxsDOibMoaQkVgYWIv7QDSfG829mr7+mo7ZEvGNbaJZeAVWq1 2l4TV6C48Kxb75JaGNjy/WbT/be3THpT2qw/rimqfvopXHE3jxfgjcGKLLu5ch0yw5oguLCZNNSz BhPvf/n5Dq+7+nRN7Fxd313xD+5//n//76v177n59PMveOH1jc05KnFIHIVUdnMv1b4E6/1jQP1G 5uTi4mTU68ezZtsEFbCkTSVLHBIqmqw83+KSZ1zYZPzWaXclULIaUS9RleBdAj+f4MZBEUsdaQMR vJ1enQJZZRgD0xgieQzOqC9Wi3mNuzM3pkNeVWCKYmVNH6/UFxiAtZSsp8ps/KcUuz2qkFkaRGfy fSZrDhyQliqsO8makav5ipKEQB1ju2bSiiBS5vzSTcMfZqTWTgic8qax8TaTaA3Ir+Dj+dbnx/NH Z8qkj95OgIx3zBMqjsURo6anEPg4GXEMUG/EvkLioyuQjGDST0+ZMLyYdI5cU+7ebJM14M4bbKRi vbnXarmePxh0GOL9Yfgn4GQ4t0bcDx579COOAQoY3Doym7VBY8Go83tvr0O+AFQkrICOJsxJbUqs QIbV9ubdPVYwNvFMb8K8xkcqeCynB2vsASoeSxvjHAAR8xEfFo6EADGkoEVtbAce3Iku7j798svd zfUnMMnd3Sd73MHj/PLf/D+/QNM9u5NCIj74EtAYfupORHPPNoQd4HhzdSd83nzm8B9hRVTyjAj7 cHYB+77wkqZrykolkzNRQCobZysvR9fhkgBSkPrCHSuQk5HEdi6RiCRZ48IdG7dBJGr2SnDXB23Q mCTi0sBHsbCRzOeTth+eZSwgDCxn2XcNWzFlYLYKJVvSh78CWFJjnEzHokkwB7fYyhittakyEi57 c1BecXydqguFMm19AjDRtfA9Q/JQCoV/ynLsSquY0b7aZcFEfIthOuS+OX1rPfB9y5z/ExzCcvd9 dtBCY/3t3StVvp/25ozwTqc/dIaT4zfaO6f3uqdqLPjzabsLLmEx1mTIhMjx0F1o8qLnUepwoknQ aA18Z9BqgE4czxkctU2FMGAy2p8Ovn3kOe73DTk6ejnwgaeXBjgB4QFmcOuARw0AqQEGMCSd2rQ2 r+1NaeBhyOvQVs2aV9/d7UyO8fF6TeG+/vwPj5+Ue/jpwWp7sPJoHT6uuWKtgG6Mdro2C/rp1Sda fJj8T8+EB0Dh05P/6+c1Nn755ckvn+A2cAGY+EVP8DW//PLp8RH+xB3BxAPEAh1GHhIG/77oMmEu /OTVGctWDhdJbjaSyRfi0eUymqTDZrYDWos1xEs7VBuiK2ujw2CEXCxNs06uSOSACbNVUPzBwUrk JEglqw3mNjbSJlKFY7NotgqqGgdiDz1L3jA9wVnN3gZ9pLi1ScXAgKab+XcCZJNPcxiENmhgtpFw MZHdMiRWFrSRyZvKE5OaNJ2Hm4ZsTA0K67T0eMcYkKJx5zum4GTn8V5tdsXbIaT/QGo9D+/YMDUZ nahg8W9/+xFK6/TsjDuFMLI77fRAIBwgN2XuUG2FEFIUXAcdDmOAzD/Bnbvos8CkPSdCyCXARct3 G9ylMOAQ0oE7BAwnts1E+ipskLKBK2YUuUPuUeAFL8MYsANZxVAWbvaaDGl1a/VxrV6H4urU5rgI uHR7dae+VwN83779gCXMwpBfSW08iKdy3d9fuTEWRdjQKjULFZ/UXO3rQ4tal/A0bMbV9cX1+S/v ri4uL87PLi7UdDYBT7JAZ6JpSuenFycXsGqw2OfneMX79+efrt5Dhd1ZgNzd/RzSzs+f7swvu7oT X4Uu5XPeC/8lNPAgqevry1F3FokkzSai4I8c6MEWPC6jy3CDhiw9ClUTlVeBnpyThI3nUO6eo1WT 8RAmrDtmW5eSJ9nU0QYMvvCRzxcKnC+8kSpUtA2QhrBorh3Du3mTJLRmvZgF/ZjwEwRZ3nh1dgJT LwkgnKzCMDBncLP/wxiPcpEvZZq+aGdCmG1OimVNYLHVWxYoBiqat2IzJJpMX35gQB4zxrrwao2Q X4tokUFAEqMhuOBEWcIzePXzV9N5bzLUfoWjk9cjFrWO3sCYj3ouUxHdbnfaCaaCxlAV3x2vO3ca Doc3cJac66mPfA72WMy9gFsguL19lYarBtI5aq1542G419Qw+vfdVKAQiCqGsdq7u/W2jfryArQV XYju2vXp24uzDxQfd6FE+pXP3lBaXduArBFMNww0XYVcgdV7fWUWrz7h7emnOyDijFUhbLjssSqt O2dZ+//5Zr5YsN+9f9jvL/CXj3r4d3gcIbG65TB69qIsl/3xgi84PDzs9fEBdPj69Qn+i1wCM+9/ /vnne3KxuJGnuTZscmNKvG5uHqPEXFTShInF3ioaZUMt7QhWOnCQTkdNWtGMReUF05gCBw9tBdKg P2dbSjqW0w4Q+lEzrd5u6MB2eQ6k527XSfnzrCasgIUIEDPMS3PtKLyMS5FlLzKZyAAYVvQOWwM3 hZ9iEbChq9DYxrzGc4OSZOiVG8ziFSVT8KX1X65aM8PUiYltyX4YmBQV3lXRyo7dQcGmBR+ZcxvZ fcQg69lXfw8eLHcfYYGPTkbMpr/ilrfQWiOAgeVYQ+a+NfpnMuq05yzlnZt0etudTk5PTo/fgkIA sPmC8av2fAFrPp+PgRZ33meZ+qI/9ltwJP50ooYQvOufhh2708HjI7iPYgX2/Mh5QQsCIOw6jnEg e1RZZBU4jzYUWG30p8tLftY/u3moqeQpPst3hytNNtkmLEwQ6un1p5+pcvjRfnevgHByJVBcXDBo QUR4vhcx04I52I6bn6zYtKjBdjN2mKgdP2h4nNXFWRFmq3NUDwAAIABJREFUexNt6bAww1VWmsjF 4aiRBafcATGs2LkEv5y/f2/JxeJEf9Hre8l38/EzUrF0qEjwh8vJm99sx/CpTtaIprShoiLBS+NA llkWQyq8BX8SYdFwRBuURtW1lYzEl0nb8GiOpeasRDVyO2lGBbO+lxPrwSjVXD6ZEjLU6GuHryTN wK6w5F5TV/LiDx1FDUqsyMNvlozpB3BwuSQ7QiCUVWxJnilLdeW1kQNDwUXSTblQLhbDuaYa96s6 90I5HAy/3towbAbZ2rrfAeExDr5Wxvv4eHKinc9H+yenrFbkiMV3fzttu7zY4TheFmP1lAnpMRfS BTrwBTMy4azS4VDj3nuBP6fA4nafLDt3B864P3YHLXe+aLQgt2xv+v5QBVl+CI7HICEyPB+qy/h3 XGi4u6COvfqu+40FiAsW6e3BnHgeLMlIsaprJdQerJwv0thmWd2FIagb1V/p5M7oKXyG3z17aBPe X5xxuFGvp08FFvSzQZedYBo8rwEqPgtp2MHLUag+h26rr1cgAUDG/cOYH3jsOxGRzPoc9qBhwxws NIv4EbUgsgElNvb8+eGbQ/4+GinA5OcQpCQy+fm765uvGBQbCAORAObnZyc/uBGuYCxW/JZsnAVW kFrsz2KBcFaKS/thLc2kFY0kMttomY5gCixiIxIxm2el2Om4Yerrs2rU4i5znLNFN5PJKEhm5tPL wGsOS4aZF8WwUhp2WtLMLjV8FKnItO0Vb81eWnQ2eY2t48xgltNnixX2MRp3whezsMu8w9qB8GvH jHIsFs3mVGbjObv11OeVJVv/vhSIAcjZCcQP2OKYs+POfzw//curX36c+tBTQ/dgOGHVYnc0AVCw WLq4cTvunpYMW9MndDCT49PRgOPj3AWz7E6j3XcBmK7nNAZBe8GBio7va0yvaoOnw3ZYcdU6eii1 uAXb0mcEKzChrKMjBwA56NR5V2fecNfdrcOIEC3fDS8/3EiHP/38Y/VhEiMM1EJLmbQFP5W10BiI ugpNM4303aeru7Ori7NLcGJ33mtztpe4wgx6dByv2W/iAQdHcGqww/FGGht02MRVNv36A3ZjNWeB 3+83x7eHzmCGpc/ZkIcLHwg5HPuqmWRPPIHTXA6WnNiViHD2dSKSZPMhaKXfGx3DvVydvb+STTEW 6O760931OoawrnKx/9ynwtLTjz9djsYe3XWGyiqihGHKGJGoJFREAIlGlyvQh0Z5mT3oNEw4zn4U M57FiqyUGUuk3hNT30WeYFsuAJLJ2sFeekpjINXWmDGbAGl7oHwyaQp/pcO4gelGKq8QsIlU5dlQ z7F3HKNSoOoSLsryLKaDJG9c/GZoP4zzsEZ9x45O4STI9difz8TVr2UJH211YDjl8UuenF2cHF/A WZ6cvTs9ffXjj6fHr348P5lzfty0o/EmU7Oqe28mLFhsqyBr2p1TY8mmHx/DpgdUWFJXHLGoce/w Iw0XPOK7nJ/gDvf3wSDDH2D4h863dh+d1mMugQPx1xkSFmY1nINdgsPdPai7uHF26cjrAAfQwYjS 05sva5wemtkbW/hBSEDsf7p5yoye/PedCc7SAFxf47mzSw4Bg45y1bHV9AfOrNnW9Ow6uxs99pp4 Zrgq2xfBDhyb0gRhjPGY0yPG3IUUaGgPWt4YFuTWb/jcUo6dv31OitQGjDMvCDTlkfs5+Lrrk4K0 fxa3j8PneGrJ0VtsEnvzGp9EF9ekFKP/4LQA7VBxfbwJ8zj8d4ZNWheXk+mMQ4XSAgW74lMy7Ipr LZPyIhHt08B+eEMky7BZPsIBdxJgZuMfIoJ1LaqDp/+HULNzhTVhPqM6yYyGQJqdrlOmZAtkktpI mmlFdiwk1BQ3aCxW2I2lOJcdzFIkQKDFGExm06xYg5rK9N6GBSabNsJrzbl2kivm7a4itsn2vq7k s9LEX0ujP5hHug5wVUKAnB0fHw+HoBGTBjnlCFIT6DXA6ExhQA6mNCJTMsScm07Nu/P2iFuxDacE yNDlRrfyrdoxhAN7uRnbwB1zCDtE+aBBOzMdmlYTR6GrL0pNjjgR63H9O7lj92D3BUDSqe863+x2 Oi+Gbw041lnArxpyG6wydvwGn734BhiUzrMfyDiDR35/dvF2OHxzWGu8bPlNTnH0mnWGrP16u95k j++u7+rf1G5rmzlRSL/LARWOV+Ms1OasPTOk4nN7hibHVbR9MAjLwYCiJtmi3xQZkZM0r0ibO3DT E0IrRhU2NlIML+UGWZxNp4W7Wizm8zen4JOrq/f4F8jEwzhZe/LxRokU89/ixoSB+V/nw2i4WEX0 4R6JG1WlqC9nqJihdXZMl6ZGrCILDbSPL+NsxY8vuBE29wYyqXoVCaujxNStSGhFVcqivRzsVg52 wxPORNUw1aR2ZkxyyZsdSrP4oAetcKKQOWzikQ5fQ+UVGbbJEW3/I31lSlXIKuKQvLaoEr1UTf8h jhxnD6t3kNMgK49A8bjG/WE861Fq5H563P1UE05VvIT+mUw09sdMsT7tcfrPm1Gn09nt9CZ7jQOm QrqdeW/qwoI0mTN3eyxXhLtna0hnEMy77UXvEBakTfZYtLXHJweecCoixNOU+4T88J0ivW2TPDdM EQQDmzJ8eeSvFjNu0wYbwuk7waCx+4LI4PHNN984u9+9vdQKuPlCi3/hOtYVUrrhygJEbHpCwuo9 zDdtxtRtObVud1xvOPUxrL+/12zW277DKUaKnTXbPPN81RI7Gv/VPOy7PumECCKzcNBdk0XMzf5Y 12fB+M+HM4fSC/hwAZwxBxeRdYgfM0fVCC5ODD7kxqVmD8aV8Swrbhc/Y1dwQHewWICaur3TM7h5 aa5nwonslBBydXdzXw55LTK5voDcisNAcDXLsyejgohCwAp1RVbx+MpM7QJAzKaMAg63Q+EwI6Oy UkqjhIcppmdUWbX4hIS64YmMpKx6Ktx0jnvEQ1HlOIOFicUKkyrZqhkoYfDBicBFTZngPEczbkLR XGUdM6G9Nzyi7X7XucWi9lfkEGFqK95z7Jc2QjEMwp21KpV1w9TajYRq6uEok8rWg/u1xPr5f3x/ NvlhuP92dPrqldkIATAZaYo1vMnBQad3oo10OlOW9DKZLi/uOOQOAxBqLJiQdnus9nQsIKgRM8Ga c01812m0AleTG+zwD9+WKj5MpqsKC4zDbUNIJT67Cwe7nRfgj2+chvOiM3x7+SGsBv8V4ngEEFP+ dP3sivGgn3++u35698v/9wRS5eoaTmPYmddqWN11v/WSw4VqAIhbq9V9fKsdy/GderPW5KAIPPDq LlsY69Rb+CaCuC+jmuE90xavyfaADOiDjfCNJgucuXGDMShtzsyzrsbXfC7PzOYa0797A86ul/Dq zyIerwoo3OZhOTND5xaR5ao/772BPZGRV9oewL95dm2qZG6uDKcY60UiAUam89lMeoh4WIo5ljLq Akh8lUgY8ohEOYrbzPCKmGFFnPRlrYjFB9a4uUtq+0V5eLFTaEfspllR/ULd4RE7ujgDMlOtpLmP fFVxL0a/Sibape0c1qggHjhwyNSsmASKHolLLEDKHIta0YRUM7e+QhIRTsQguWqukivYOl7rTR70 gXw2HMtgYruy9djLV55wBty+ArDH5xrd8NfTsDN99PoEAKE91wY6HfWEtFlpwh11HGgs7sY2Gk3Y oe5piPVc0oojThasxnK4aaHjciBvwx8NO8yFaIOFts0Nth4qLBbBLz2fTehHnKol5DiExzff7L54 eyl0PHv690v7LDwMNp4xRHV39f7Te2mqZ8/ufv7l3fkFd4LvOK2XAZY/Fv5uq7EHfHRrzvdOs+04 tRr8NzsVWUs/Jm2YLyz9GgdzAR1NJ3DqWNvtugZHOG1OtwNe2u1G0OYwSOgsKDan3T/kANUZEIRl 7zQGPvdvEJEQDE2Po8OIiL52XeR4IU+GxGeYyzMQWemMGztoymkUbBI7nPd7k2N6k59/oTe543QV W+d1E+aCbtRZ//Tjh8vL4XymT/gkaIEmfRmP6iQZYRSNhLHQuKPIPT6AJdDNcoND7cwQCTFJyjAK YaFBeZwKmVSWJCkw4CLn6RFBaUFEp0nu1JjNaHM52hB1KRIg8OQphb7APnlOFVaqxKgtM0/70WG5 paiRRMCHnVYfHnrMXRtyHFEvAslVuJ9DjlujPI5nfSbC7Ly47QdUIgZhufvkgkm8iSoV/6pt00/n DgByfAyRxRFAwAP/qCmk43IEEHHSOz6+JCdwwMlJ+wgAYd/4QKnCNifJedzflo0hDc6R68H2T/an 3zEVMgy+DfPnIUpa2pINqDh6VAl/BJH1bz/8F9qOf9AWa7IEqjfXvUoHuXaMoAJrXFxwO59Rre60 nZcvG0G9293bre+5re/BJQRIw6016y5UloMVXWOhCyuF6144JgL3dCX1GekFMoys0eyO2b1Vb/oc ogJHwokrfKnXaGn2nWNMPW06B6o0NRRVFgTaSzMiaT9gOwKGu1bjcV+7YGsGZLPPKdwyK0DMYoZH K0aJE/ENmu/+YW9yds78CehRZStXtnDsZl14+dH09H64HM2bqxWUVYrhW31zgPYyql18F3FN4o4s zax67RlvJg9BZClrCFBpbiT9vskgEhrcytdmH4WFqN2hVNO8CJkoWSabVCYlmS2o4L6Qt3s7KDOv bRi1q69BQ4FVKoXi5/jI2gLIEByEw3alkM6JK6o5s5NWxQKGyOC1Coergkr0xCOrXvnseLBpzv0A oErlCfDBPdL2h6yOMPMVadV7jppC2JXOkpMOWEMqiw2uLq8ABXQVE9VV4Kt9FDATwrkNbGliExW3 KuCIE3w2gkm8NkuxzMitP2nSuwlXtdbZkMBUuVtfEpbBN6wp/7voWBuSsCuDFSHv70AdBh/v3/Mz 4Ie9vd2Xrd3u4R/e7IE1nHqt3WjU207rYE/4eAmA1Fj8xeL6bp0mXQ5EpfbtNpWXafuliKq1m/iP wWL7cb/Z9n0XYrLhjGsatKIxXS40GmQZ/Tgejw/7+G1y50SFEiqQXg2KrWYTGms8eBnMYodMiTgc lWrnP/qeBYssPfw8jYrZEl5redE/fPP65Oz9+6v3trqL8esb81/CBoLNkKKby8veYkmEmFIr1pZg uQcgD48E4i8XkVkEr8D9gqO46eUBi6Uhm2gyLO3iHWduCx8GK1ZPmccESDppFZZ5Bbedy2YKBXZz VdNKmChknLHR4XRRdVwGCYJF2lR1PQAJ91ss2HGoHDWc28rlOOSLSsqySDVXDcelctETMRVd1mYn jyHyGT4qle2tR17EnLMf5BIMwgGB1Fjnf9U+IWd2dIO29NR2t8PhnNKqO3cOXHYVHkB/wISMhqPj E84YnMKmj+faxZP7sgkj/D/dGDiw7AtGervKEg6/4w5v08HjapOG2TlE+yPIwJvOdNDRD5c30lU3 X+8sspGb63X57bXy4QyFmlzb9dXFxdnJaG/3e8fZ3dv7vtHYrfX+sAdDDhzARjQajQO3Nq11975/ 2fCZZXHrPl/TJX3gFXXX47CIOgBCpoDAgk9xmv0ae3vb49qYTgY60m9AYx0yJdJWJIy+XbEvmfp2 8/Bw1iBCmtraweTiZzOXfn48Hv/5N4etl4PZIQfakUv6wgfoRriwAJmNtYNWc2lQA1aJ9bWr+9Kb v4bgOpMvUeXwxxuy5p1C3HdGdj4lRkZdL6Jd3AmPZMRsRLpaRAiMSOSBxNJ2i/zDsFeE4eJIGCQ2 Wy+GsTCgRDOKo0aGJe0dULJhcLOml0IlzQBWxbZwmTETGqzK7zynnWrK0BoUZpcTRbmKBc1CTecK Oc3vAnNsb+G0wlW/HpsqAsnJqlNbcfM5BrWMe6eTz31OHJ9Ft9biK/QoTyZUHScnb6fWhGgC6enp MY0Ht2ETRrpmumLHuHR33p0fOG4bGksUMgH7HI/8oKnBDUHDnbMXpDkXb/gN7ULrBi3OsR5+Jwbh prdh+Ko1aK0VVcs2E5rBJoOBK1f+7O+Y8hAVpvAWn5xPr+k33n+yyur8Apz13d5efXe37nzDuvnd 77//Zq9T7+w6uNLA9/cNdZ3UOo3WQZ31kEACjUh7jyABQHz2YtV33dq4y54tkkqdc4ia3Vrbr/Vr sOxsBaZ59zidCCcOJ8ubnnnNt4MWa3KSHd1HU5OFRSFNs/EJDAvWPhMrfSACpkTrnwMjVxRb1q97 C5M4WR0yNznT1tba5QQWPohGFQzujS4vrkz1oz4o3pvWx7DGRvGNy8tRP4IPdCx1GvOAnmZhkAEq WZgNgcggJp9oyCNiMydLCCsVQBI3fELQMI48bsVXXJgxs7zDii7u8RDHSqbKEj4UA0ubeRLcn0QD XDRSWLqLVcEiE31pwx+2ynPsI+EBtJA4NAZSs1I5nTtNKskVzPD6igGKNFbebqtF0Ag5+HNPILkH +HiwBYKFCBlkaAptRyegjr9qhvXx8elfDqmksLrmAokGWXdUp9hxe29GbsOdjqGx2EU7Gr2FCZnD nc7x/7vha9Y7B5HCmbeVJwwY6B0EGgVhUyHt4IHRCNb7hgSBfbARuNO3H54p3/GVeQcP+eMm7Kqg Br8KC6neX7GGaghoOI3vv2FPCevm63Xm5b9v7PZq3zc4SAiPBQ/op8a/gEp6NRbZU0zt1jl1iP2L gIOivt3DPcdhDVjNdL5Ld9WgOR2ZDjoWD3wJwvH8Ol6v+DAppNmc0cFoOxPeM5kiPM3wtuCU/rgN k9bkXlqeGTmv1Ime92A9OEjYW876iz701yo2awQmEsyNTmIrb7HwltyjGmsX1DM5Obu4uvp0Z6pU rlRLE2YVP37kf9Dry7fT+cKUay3Npj4Laz6YyF/oASexEgdR2RCWMUaUQ5EFTxp+sUfK5h5T0ZBB NPj+PizMYNdGNA9FVFRbCoPEnBCpwUQkDuEjpXYuW8Wllva0aWzn4sfyT7OQn6rKzJXg+FSemx2B 0uqlz1mfbhhEj3KGSR6hw5x+RWjdgyZnPfuTEw1tmLDjb6RukHOzL/Rx1z3omL0Kp0O6DzIHe0Lw 1Xv9etpwe93uxGRC2BZyMvIY6WWvLWnEY4tII3AX3PjWbDoLucR6LE19Hu0PDRJaof24/9Zj74e3 H65tqvxX6MNG/W9sGe4DcECP044Pp3svvnHEHrudPcMiRMhe/RtIKNGHSr26cuh4GoapRvZoubi0 h+c5WIX1w3s1SEY4kV7N8bvdGltUQJHdZh2MwyiX49XY9ouX1K0cY/GWiRVzPhFzjE3uKsc8fNOr a+eUdt1XjsjhzMcmnmwa/gAwqKTaIBbPmPk+hZuvnKK2/J0FsOpw8zPu+K7d4Sm4Ij5cBIPBrFR5 c3mm2B3z7yoMDl07aYQdAeCRuR9JJ7JY4IGFxhJMgm/ceEZhiTLgH46iEe7RG5UnUQ09cGIMygZt xzJkEiO55NwNlShPKSraiJqxEXDo2jBIkeK4sSKSWqysLNi9r/GEzgpm1LaGSCTM3G29R077nBA4 2fXcbW2AAuogoeQMBnBFi52ck6uGCCnkDFoEj9yDr6/FtZ6ccPrlJRnkLeuxTlmzyFzIydzpTG1b oXzInLWLXe4QsjftjabcTmfeUyrk7XDC8SZz7TLlOPOxC0muXTwC2hDeqXpj4LMrhBNNgRMzQk6c EbTCGl4LELDTW+XKw2rvX3XmNhUYRqzuxBww5G+/O/jGrH4cL+oGGrt1Pazv7e429CyrhA8Ovtlj iWANl/+l5YA5HLoU/FOZN8RPsuS+vcfyL7DFHiBx2KUxgSGv9Zpsjiem6gSIcfV7kFMCCJiEVOJQ T9VlPBgb5kz6ets1oS2Hew2pS5jlvuMxkyrsOzPVXtzXxIWDH8eYC1HOkHuejFdGdPX74xW3YeT+ vrOVUWEz7uSwogVf9CenZxcX720h15URoNd24go9+7OLSe/wEBorcLS7C2tcIK2YuDf40F4o3OmB H/Zxk4w3afh4nM9GLC6EF1HL0lRCGpzErdhK2uLIqEVI2gDEDMIzQ1fyHMMFLBU1HDhpIRLnLAlz sBVY95qsnQthY4ijyOVvWCZPwUVgVEgdOXqQ3NZ2hfvCCzo5i5yqxUrlq9gIJ8rBt9soljbwAA+c nx9zv/TTU5CI68zVlA5wdDp7025Ps7GGXbLIHJ+I826zPSdAuJXOCQAy5Q5QzH1w8qHHGaHaRIc7 3wTaCCHwqLH2R5qNPZoGNpAVMHEuN0KIbAwCkIcZ5fGrvXU3H0NLLnyoy8iUqYM68JcGHl7svcBq 3t377gUQsPfiP+/+Z8CjJoB0dne/r9cY4IVzJ1xqfwKH7O7VGy3c1L/XOJVez2ntEhGOyxmoSiMC Cu297h96e/i37TrO3mEPZFHrHXLk467TVvKk2axxJFfda9KutBXNE4PU8V+m0aDC8mz8gpuguNys zpf6ao7HJrmuUpaZMo++HIiSJE0mEf3w0kp4Ujoe4DD5RZarKBU/7q/gSoCR8Xx0dmY7sq5s3l2T VyhL2Rt5AR7xOv/lX/+Xf/3jH/+1PVsaIwI2CQw6wBIby3hEcBB74GNeGwNZYNCZLGUweMFqMDqT tbhSXMsGt6JqjE8rP282cTCWgwgpMAzACLDZ1kHt8cl0jlO2E2n+CYnE4KMQPiiIQgwszJNc8NsV s6MWYbFNsJiNHYQK89qCVNS2VVy8sf4jFyKHl4wHmbwlQrByYUJOz358d3Z8+urseOrOR8IHAMLw lTZiA6WIVObTOTDTVq6QNe8cZd2DFedsacWvpC3w2QRwKKHOU6gKliuGRsQ3W4UQIKbsROEsdyjn 8TTsz/66/bA7DciBXt0ZafWz0NF58aLOvCI0FRDyQsJq708dUggv4cDjzm59CnDsdfd24T44AULF Xrvf1PZeHDSAI1zea+CkQxUG7/GHP7ypv2zttesdGBA8zZrJepu847iHf6i1vq87fs1h4h0Y6h52 vYbb7eOUHMKBwjTsdaZNvT2TjMd/DfuUiWm5dk9Gs9GJ9mtomh2wZtwjyAcKhBvcWa0168umEBkz 04tCnCi6xWYTfDSpmH7Rm5y9f7+unL/if60wrGH8yOX+8OD7f/3j//q//9Hdbcuu+97C0gfW8lE0 kYjggyuiZOEylFEBmUROhYgYbCjItdQDk4CMqJDLmBPZdQ2R0LT6eMrOudOQU1PkZcvpzQ50FFTx RJyDJWK5WEKDwNgjzIleIUjC4StGYeUAJY2D1N4OWPdpkY0VWzkb9+KrRBmUXkBDaEYKlYJ1HvfW REl1eBAakMn+PgTWaF8bhfzt/zg//gu3WJu3tUsh/YcivUNmCTnbpEYiYc0iAXJ6PJlOJ9wTeuQD C3MCw+7J5tCws+eWTeos6PXdkdoK2X8yHM1V0Rt6c+HDn769NHWItlj1S+b4eB/PJcfYZCCENisC pi+UdH8BnwEk1F98t9d5Ud/7Dsv+BSmlvvuNioP3XkBd7e1+QxeOcwiq7t73B+SbXu2bxvddUASI 5ftd04CiNq0/vNltNeTeOfER9NEEOGoCSO9Nt9HCxSbNfJPhrO5hTWEwBogZFubPeM09V9tiwcp7 rL7xGe5qM9jFTeHNtHrFuDxQQ3N8OPaow3B1pX1/VLAiY070zFTyZepVVgAKVZZJnuhak0lFD7ae Migy7vdg3MNGMJtLVA2ncXkf4AcPfvivIJE//k//dY73B4mo3p0CC0ufPVVHG8u0uUCiiCw3osak mF3oNgwslqE1X1rVZeCxNHwifGj+itSXHdWVNNtpJa2qsoMfCQV2ccVybAdWc/ADQNCPJEgkHDAp nSWKsGgRQ6xJpiCpRdNSzIV0odCX4RmRBx8WFNjKVR4KLmAkB4l1fCl9NWK49/zV+bu/nb8+ZiCr 57aFj45JEXZ6k96B03s9mrrtHiS6ewCl1Ts+O76cdoac3XDsDlhm4ZgoFgy73+AOtbDntOoN7X47 NeEA7qWzP/S/VU1vywZ1HfeHt2tf/tWo1c3DCquwYZz/4y8uLvfffvcdGAN/IKu+e6Hjuz0gZBd3 L77pvGBRlw4Qyzff0JbsvqjX/tT5l5ff7/2pt9f4plOX5oKSGtV23V0TzOqoAx4gqXW+N00pjrO7 y6QIJz52e+1dwKRXb9C31+RRGBrrASG79CTikHabNSi0Kq7JILa54yK9e13sASDtmXJHs4kvt2lg Jl51w4Y/xk0bLHaVDlmxtAt6qy3vIrsigDBP4hkWGZvcCeuCubBBJCdyJD///LBT8QOzIzdv8X/O m7udf/2f//jH/+1f/w1uxGwnBGaAgw9YuLgxINaEjyVrgwcGO3xBNLr285Y+bHYxqh9YGqDQwqjj PR3a9yRHEcU1H1i7BElWJXjEhYoESQG3vGJ0VogUwyQJM3RCpEKToiF5hfTatWjPE/OQHJMOnzEI qXBb7IpUF8PBVZ5tV+wVgWRbPuQJHPoJ6QNGfX/IUQM//u3HYy7300nbFTKmFiR05u3R68kUQopE wimk3ZNXZyd49oQ7Q/ecwOwQok3ZmtyRTbubs3HC4TTSIPAZUjY6i0XvLDYJN/PsiDzunq2549GY HtsdyxTxU01VuLPUgU/Ei5P/n663620jTbMEnRob2tRcqG7yomHUD2j0v5j/sgVs53qAXuwOuYZT JYmVWeJXUN0oLyNofk0H6GFJlAK7DCqDH0pRHBEEmeRCVaA8llwcpXRRleqGrLRLaXRfTNU+5zxv UHLNLCWTwSClrLLj8JzzfHYLhXLUFWDkC7YQQ0Ge2nW7DqC4AgjhEeEL2HV+l8u7JBJRY65vVzYp s2Do63L14xUwA0RWuYFmRoGItmgJpsCLQIkvusyHUXHxTN5fFtPu7wVoA5bfJD4F8+cBDvRACqpy tYHTqDKwJS9AjOZqHAIDt+7VnL1alfxSqyE8hmwKvYpc6/7Aq6FSHq+BP2ptNfA16CtPM5K1QROF joZh5HxNnDw9TdtU0AMjApKLM9NKzLFD+jf9yVVSOK7aAAAgAElEQVRvxn33jdmkXlj56lfZJq5s +fOpXv9IuCs4TOx34Sf7n96QN4yXZ/rwRhWVyqwbCizdBb8QVg6jVPivPluC49durL/iLK8lTurC hY+FwNreSKD8zeMlBQiGQT7WGSyQW48NNu54BaMkdWXD48ehWzHLgsLliyG7MJOiONFvpZCfzsPA c50lEFGTPuaGTRr14dnBybenhwKQQxQs1nd3EdpFjnDi1XHkB73ZrlBLH09m/qR/Nh2jZQT7poaz TqtSwbJCAQXuaNDRFqK7b+E3Zt3tbSIEcaxvtHcQJYn17iUSgqEv/2iUx11L9luGYz5AJjAX+AG2 I1+w7FjUtgQfbiFvx3ZtAKMuTwtw6gXBCcyHOBGgI+fapaLoqpjGuApurFzPO3apnJN3uSWcLtG1 C6zAFxXxJgYHQicNgMTlwGD/STkXiGGv0/yLwa/6T8AgOVHy/b6L7KPHkfQisoSP6PeroJRqzqnl ygBOjRXDQI0YFn6aYKRws+ajQrjWxgMiwJ42MsKD1JRSmhiDLHDAnDyor+s2CooHIraYa28Pbkkg vKvpYxOrrkEkw7PvWWJgpqd88v5qexxguQs3UE5+042nGuLM5Sb/MuAJAiBkD82yK3D0BILE9O76 THOHN/pDQI2GhYV1Pv1Ulyss6eA6MggJhG3w4A0RVLdLOpxr+THUFQDzWKeukFmgqjB5GwyClx7r LwQ+dG7qX92psJ/eO7rn7x+b3KJyxz18qFEPZZhmEmnS4UGIDsEIhrWf/v7b6dEUyfSgKZYb1kOo o84g1gTtIHVv4k98EVl+EPi9KQHSExMynQad/WpV96Y3jrm6uYmidwGKhxHwcrzPqaZds0e3aoqu qpMwYX4fIKHMCvtLwRs/fi//qt9/b8jj7cW4m4ecikJP4VuQUJTHArkDEsugxIaywrmCiLByVGCx CzUmkCgg2lsQUOAZz0BLCQf4bkyUVSkm9NJ7wgsfboRqC2WMzpOgVPX/9oljVxsgl1IpJ57dpZJy n4joQoIRmiqHkBdYSP5CqNswnAVswqxJA++p1VxsOREdlnPawh0+eAFeH3pLvEZzgDBXS6nBa/os FkbykbsUkQjB9gcBAVGDcuA2S7lqVGfqW1gcuXDTbF5PgpHhEcEIik/GMJLAyG8QfemOu7PWI0ax CAgeKULUtys+OsoeC6Y7F+/+9BEfVVz9hIUoJq4FhMjrP9HZjTqSbkGlFm2GIAJYWFxWcOC2KF8C gs8e60kOJ+K79ND4EB1cxCmQ+mj8/Hw85D2s/FQz8YqGnxq99dPH90jlbwyp/PXcofzN4wfc8jHW VPrw/Pxkev7mlF2F5wd9fKJga2tv4mk6RGx53QeNBA35AycSDA+GSP1hCNCwJ1oWeRCW8s4gH9iC x10IbJzq7He0YnGb6cLZp9+IxG1MaMw/uTPmd9Xac/r4gfMVULj+1kz8ePt2tJ0vRKPGbpA2LHwX RWgVi4SFTfKIAiw4FnyIlIL+EjiUYVicgkgxsS7wI0BX3XWCgrCLqCeQiFOulJFFDDBYxYxVcerM yTtw8kF/PNmVtyCfIpDxMaDLqZYaCI/R0EOYmQGROdR+5YQvahxVVFWH0uAYCtZCtlAojEncXtup tQPPa+/VvAHWxNO6tBpoW4QX8QcMCMOStNDhy2lCf9zDyiC+gIW88quYaddlpRwyUeMJXuTX3fEF S1LeXVyORxhFcD4dYdYsJqCJovAJkI7mQczD/qMFAmVh6QbMf8ME443WNAIUn+4TQhRZP9GV2I+4 FBsQYRfK0g3yHxifogjhfAiVVViKrdxxu6QmZNG4EcisUHJ9tihUweGPIBS6EB24SgL5iSJkWW3+ X9zmfIJ8InLyat4/YzR4bk7mXxrsgkt5MBpxD+v4tfzFnP3T6anuYjuQ+7OxmPAeEnuToBtwpmJ9 NumhLqs3mQUisvxg4PcPzlDMC3ycjRrfIPPloZPwGlGYlu7UqYlJ7zQ94RfYdBoQjnDANp1J2D87 H2hlmOMePLTOCorgR9OX/eFinC8ULACioHyBO/m2gIR8vmyrzsJ9QcEB+pCHUjmftzejiGu5BQek IrgoF20afNFhhTyCvIKl4MmTfKFciXH/guNQSaH8BPOCOT8iVsZ7/NiuYKVckfueD7ZxRGwJQhy2 QWoYzKPwEnmGA4xH9RQsuaaOp6+xkgWveN7AbVa9/q9/3W9zl5ZTA2cgF5/Tkkf0L7Z9oR6kS5CR H5A+Bnu/bncqTTp6+XONKkmsAm5jx2/tGvZfqMTTrhL5a2/BkIh9uxy9Oj85OdcCI26DEUN62aPC IjA6jBaDKPQ5ALJPaiEgFgxlQCcDD6qrzO3RgpansOLxZmn5J/vfPMLQbDOcTt340vLt8u21PLvl n1vFwqICRJTWsnnvMmJbxArW/6g3QagLuOAgFkMhn+nBZx+HvT4OgSlQfvr4s8dq6n+qYa3Qw//1 nEn+WhhE8DG8QCZ8OMT+nNPpaMqVhdOzkVedCH/4dc7/8SbMhASTwO8Hg6Dfc9GD7gfTKbamy+3s fFjHPilTyzvAMh18i78cNOUfb9bZaTVbM6i5bl03jVer3Y+SHvMxBHfTej5OlqvDvLjYLmSj4jsI DssAxA5hsv0kb2fEeyCMBW6p4111KjA7JgDpuSKoFDFAhEgxYRS4FAa2cjkQTc7N5wUqsUrVgb8v iNXADOCymaYtFzvMer7fE5p50tt9sVMWPwLOCVxx/eUqCKZq1wEOHb2NCkehC4zzctS5Nxoklgb2 nJgK+1oOJfTVZv/Xf/vrvse0ooPEvLzKqmBdjt1ui/ZqVJvaenUsCBk0sZBRJCxy8J4orxq8C9wH i4PbTJloWhFAgR28WTgO5IPx6OTNm1MwCJpJh6Mxh6Ftdz1KK/luGVg8MpBB7a/JIj4y8BDttC/0 8WmYeldaeaRqjJ79Jyxk0Vw87PnSrQDh9nYZeFi+XQCJ4CkxsoSXlpH9wIPcDEBC945Dqi2YEC40 WeBcYjNQWAGi2+OWDY/MVZfySEgmDP9+Ntdbd47kTmbJjSZ9dHZ2AQMiRuLvTqf9ozP5G4MJmbQm rOmtN2ZB4E26fjDuuXWILm/c91F54vuzvemwN8boB8ws7XBtemPmXc9mg0anMUPhKsR1q9O47qCR 1kP1LwAS+PltjiYJYRByx/v5CcMebAHCqEHG8d+OxJbj8rZsRQe+BSu2pWRSyG9v58WIEzUw8IWC MgnhIlBw8m4dhpxJQ4IEjAF8xMoxqC187ufEpwuMYsAGsib1XF2ICWn4XJ1MArOCyK4rTj1feVFx AwZ+4XaqIAckU+QXub4PwpCf8X2BTNkzPh6TjHIUWMigIPiFbYsONpdWK7m9vnCIU9kHgeQaLa/V YPKk6XCGBKQXwlfo75Wz/l4bzwAT0gZiYWJHsHIHXfKo3sIAO+0JZiSMjb6DpjjH0zf/0+/f/JvT 01P+g+MCuBwjpjkBdYj8DRVWK5RcrTla7vDRebQ/L0sxTh6cYcx9WIuCIRCYEUFAAA/6R67vxT8u gzeIFpxZMgyCxXCLQIxSCLUYIQFwLCla9AEoQEQLM7kBBjUqum3OrFo0EJmLr8dh8eNnocL6+PY3 hlAe9LrIows4xlRaw9Pzfn9IxhX73ZwJ6brdSQMUAqHVF5fe64+FRI44vkFw443GvcNzzEYZDcde S/BRnWHdExaiXc9QfKLbaTut6n5F/mUmY7aFBBj6xoKS93fmI4ztvr93M91P73RGz8XodT5NaQV4 pAUdlly4xVIMV7oCZPuJAGSzZAiFZ1Vd2SQSOYi60FYiw5BUxAGhI6ILT8WAABf5wK7s2Ahz2Tn8 bI5bGJhIIVxc1NDbzNMju1h1ChBf8PF8LLtPeoIQCjSfkS5BSgVm3YVlF1OPhCPWyeWqGFyPPUE1 rHVoIyG/1//boz5XaiGVmPO0nl6ziY2WSCpc6wIcePdqe8+B0RcK4WZsk0wZyHsaxwgBNzy+H+Es MAvqHRtI0Xvdi7OT86k4dGH/KUd2XIzQHST/MhPY9BYFloKCWDH0sN8JNZRyyqM5o+iDRrPMMw1p IV+Jbndg4lrBsbhMPAhfgCbmgBFw3NKA4C2LApBrsMotTYkxKCGV6Eh7fC0bE4859TTvGjU2rl0Z JHQnd/4EyUYtfrzDxU/vgsD69MF2DyEsDIHDzsHR+Pxg2Be1dHBwcnY+9WtiN5BB95hIFxfXqGDo Yr8/OgrEjqN6sYpukDMs1BGtNm6hCGsW+O1gVt2pes3aDP/GCOh3OIiw2mn0NFd4efFu7sw/Krl6 f5cQJDYeaiG74OPiYiSUAMaQOxIGHux83ioJhcCeAzb5je18urQZTSs8DGxwnBdTL2AQNCH2tQt4 xNTjC7oIMfKFLTgQnrErYlUK8PoIb9ULcpEXkD1h/YqL8uB6To0GK7xMKWSdrxAhAQqCXUa9EFIG 7yCMVcYGhzKP0YNVrmosWHuyUFTccPee/PrJXo6ZlJxYEXQ5yl8iK70aQk4imQQrgp+9QbXa3PMh YgcDxxdzMmhq6QqklrwBZh3cojZdkHMMgdVAseNN/XJrtJ1MpFKpdDqfH2Na/3b+9evX25ddUceC j9YNptHcoEq4CVnFa37h+NGnHSKjA+oAw5i6rdYcFPfRokpL7iGmrgkC4ASa6va2favX/iLNB8Bh 0CG3BZymwlq+1bDWkga6FCQ6FDIUXeYcw8UmmfiZwsSIss9CLP2V2aO1rDTCP4/vEMJY1+N7pPJA 5NFwxKW1I0zZDYbTw6PplCN6Tw/GHqYq9nqaAZlMZvJP3giCvfH4aDpG+bsvChrTTQ4xvgE2HTkw b+Y3dUAviyuw3FM+tZgq3O90WjPMxL7iPNn396aY39WShL7DlLGjQRB1dReXXSttFeRfk7oKd7Df ApDtfDFDuFjQWVZeKMQqZeoWWcO2jE8R6IjrFoSUYziH3AkBUlaMxMqFAlKMNmoby3KUK+/GoMvy jr2LtKMoLSTjoc7qSjmoE24ggOw4+Vxst+w4pBQm3OW6D4Icosc5zTYCTIQH9RmvfG1SaZgAl+bi uQfI2dsLfCwtzaGGXmQZSrk8vy0GpooWLa6Ir3Y84Y6OI/zgYeajkIhAoebJX7SgQ746rTb6G9u/ /iMIBPUtxohUjzEYthh/+dUXX3zxc9zkIZV/nVj56h9+8eXW9uwR8AHmkH+whWO91jFkBtRxjMfO I0VIx4S5Ht2Fu/CkMz/mNKElea/QQRuTiYEMIEQpAzQhlLIodwqZxWXDJkskFmZGYFZUgQEHt2pV ls3I1IUFkzj5bEEZxdj/pbkIm5+9fwtl17LmHLG0cTmEyz06EYB0tzFjlx//w/GkXh8dHtKln5x+ ++3pYQ1xrL1A/LTLlHqjsethCGlvdNj3Gt3AqzT8YESWHmGC3Li3D4E1E6LhtqnWfkc+xdg81UBS XRhkv9XtXXAD87v34S6Ov6hCfG9sB9Gh7HHxela3MtGCfNal5WaRO4gH0Vn5dLRk5YUx8nKmEE1v f75tl2IETxRnjDlB0KpYsk1Yy5Kr3pSk8JQKLSQOC4AQlZkNwhnn6yVbo8ZItrMIkruv6jbTIjgl Qiq2u5sr0OrnyjHMu4uJykIjSnlXy+6ZZiTn5KjFqszJu4ZVGBlzULClxh6+hDsYxcVzir3XdJCp Fyg48h6nLcYjN6hVKwPk3RtNx2l6CPiCWWp7zYbX9irVvV8LSvZ+3R6YmUSCIZKLiC03uwpcECG8 /+Kr57/6xS9eyu11QziiZQJY8om20ARhHLeQNxQGOe6QQVokFeGPG+NSQniExoXpd8HC4uJ1Z//R 7eIfF68FGCCR2zuAyFV/DTMuL13Dgxh7srx0TYe+qFRDalkStbVs8AK+wWy72+V7MAhNCfzI0n93 fn77iVa1LH8W/qEq444UrVp5vHzPizzYRnYQFILLu1t3R2eHR8NzVvW+OTn0ql4wDlDnznITD2ug QSiYQ9qo+gENB5YVnomL2cbKkI4gIgga6ARBM12n2rxWHyJo8bAqBFnBhx/mozPDnUrzGf/3mjxM e/mHD5evZ/KDhWymkE8KPPIAiPgPG3wCJWWtl6w0kAOrXixsfL4tEgs+PlK07TsKsTQKHIaEbT7X CPD8fPHuDGmiDmEGG1Koo3xF4145nEfaBEFigUXBrouriKGQHglHe1drviZItLu5SiWHYhZgwMwY xvyHcixWJt54ShdoiUHBmG7WqLiYEYF1E9rh67vyBzsYsY1bDL2wCcY6VqsOsugeU4eO7zgDp9HY 22tVa/12q+m3a5BgVQ8QAc+Ia68i9VjOrgomnsptdeWLldWV+Mrz58+/3tp6+ZuCfAw2b1j2cNNp CRq+UQ5pgUFumq2F4wX5jFtodkgTLQXDPCLcuSuUZ7FjUzhjsX0trxyTJhaOlTZwGle4kAe9BtXX 9e38RhwoPtS8L5pHjBMmgogY0AdCYDxamCPEOPe75wYY4R1fNTXC+GJGZXk5NO8f3R6Mt0dTAQhD WCOhkPH52Xj46mzKbQjDWXPWFdggj97wuRo66Pb6E4/Z9Sr2ZHi+AEQYBCtvRa11EbKaATjMqTd1 WaGWZFFizZD3uHPmH+0LDCGjzgOBK+Y8LrsNduzm7EwhKZerQEHoA1ZdzUjWjiiTyJdVzFrFvDDI ZomXv7oVixc/DEqxPA8MGwWGY8uKxQghV3jEQpIEiRRFQAEHKESxUc5VZ+ALAeO61njBpAjl5Bzh LExIxTvrOT1w8r0nItAqlXKQZ/RKwFIlnWCZtWIFFFKljGIiMsZiR8yrc9xqi+69wdVBAxdTVJya 33YqmCwhYMEa00plEIjN94M9jFdBn7zvsUPF29vzxduXMcdupyo6rA2mcdqDVrPmWE9Xv1r54unK U8HGajz+/PnLl4KOra0eal84rBsy6gbj7W72BQ4it8gVsOsLzUf7rRvMvWxRd83de6ujfh21J6j9 wpxhNKgMbput1jUMh+ADYyMBEBVUC02AYxEEghPXhMi1IgT4WHi0IPdLxrtTaoF1jE3BVBeNdplI 11x36W2BeFi4j4+Pacbgg+WPj0khj/VL7YgBCHrRh+Ph3+Fg1Kt3p9x3e4Yxi8NhgDkAATqc/O74 aBz4goz+2Bfz4U/EavhBv9/ze+LQh9PpiADhiEV/MPNajcYxc+rABwoY8RlU715yA9R9b/4+bC3/ IVzyhGLTt7qr48eLy4kuQ3jUaUBRpdOpAhiEliOp17lFaBALxSKebm/koyXVVpYKKrw9aiEe7JJJ LBVpGtpyxd9rIBggIplElUcKZJFCnvXxttFkCGCBOjTLCJQ4+K2ivwQiKGERS19nVbGTD57kc5Ud 2zFRYbdc0RowOpV6TjPsld2y2VVaLjXcBnoVA1f+xsom196g5Ko5QiNCEuLa/ZoAhCa+0dxzKhWn v+cDIP7AQeIfc4OrTUAI0x+rlUoV2USn1mzV9vZyJSsurLGivJEQbLwENrZeXo4DenMgA7CQewEI hv41CQS49jlmFBItdRtkDnUsjwQXrU4LxfYLzea1oOG6KT9+vdjmtc/1KIIPA4XmzW17cZGgMPRB +WQO5YUb+pNlUMwCTkBTLShQ4ONv1N8TEbdqUBaWQrwscAn8PWr5SxuyvDRHyGPN1Bt1tXxPZD0Y vcZkxB4aNXRQ3OjN708ODg7OXyHQe1Rzg54uTT+aYgRpw+/r0ikUYs1morWOZrPR2ZgWRn7TuCsA mUEZYB8bZC8QgjhWC/YcfebGmv8wZ497JVdqPd5qBy2SHmPRVt98qu24nUI6S1EFnCTlGofWgszS g6hdtDIZgMWy8qg2IQ5sgEYNvTgYAMqa59zV61t2yCnIm9hzW4L0oRZ1hfdEBmofEf5VusFJm0+d fN7FlO1SGQ0pOdR1OYWy6/vlUgltV8ihsP9XPAnLh6tl7QSul3erqNUSDSXgKCPk5QRPHPadaJ6E i30dBzEuTIvw2JXloOHG8ff63k41EHdSc5VCBqK+fK9agQATI4MDceyOKDFxPc1BYP386VcCj7gS x8stUsflVrfe5DTkFpazyIXf4g2Dtr8RpcVCU0y7hAlp4h+jdXPcpKiiGzEPj9jihWURcu1jCsv1 NQrBWjfXeyK0qKyuj1VMtXEHg7LXVrQc05gQLrcfyS0598c/hsY+zKDwRgJhEFiTJ8AHhwwrlejX 0sL/CCBIzGsmUelDv1BWr36dhzh6gMsaXUxYZT7GTrXhybcn5yfnBwevBCbToCn+A9zRPzjo7VZ3 G5Oj4dG4P+73hDoa/qzu7/mzMYK88DCIE3uta1/MeHPAmkVv1uo0OBmq0+ghsPv23V9yR2g+WFDC 7U/h+IWLXkOH995ob24O2EgnAZA8GSOdTxYiVgriyirCszOalbayEUtwRHKxKbEAg6KdNvFhm26E R0BL1JSrREEu0fIcH1HYfBccZVxLwVSsGEoqlDRP4pJTBCEFQUx5dxf6jLX0iCgX8nXNPtqI89pO XgCDspTA3d1lmzx6flEhzMkRqB6Ww0COUcPFfhLVYS4S+R76GGs58e9lSDBU2D/ZGzScwHf2+LLg hkoMfA2nUkPnAXAiqBq0qg07G19Z+eKLlXjiOeEBZfW6+5t6vQFgABVAwX7rGIuyWmrUcfqG+IAr 0aTIfueGr7c6atOx2EXzj4wnt8gfIBA5vBYOgREx+mkhvLzxHPxxfRzakrnIEkJZuJ0DQgCySOhc L5pciTLN9QI3NyyBVpYYJFZlxcAZEbKw9P9PH8t06kvLpm5eS4YXSSCKEWWSByMd3YPx7qi7QqE7 QlgnB3AhJweHA2+CzGAgymtcb+xORsO+3MZHgplZfYKWkFktEHAcDVn2OBxOxBuiH2TmDMgkjY5g RUSrf0ljYYbHvg+TgvfCuu90hxIgwgZatCng3wyfV5iK8qgK+khupJU7cLFv5DWclbZUNgmCihE9 g3fIQcQy0S5NvCtVFIEOlV7w+rTxPGlHiyw8kTe7maJ9n07Qnqh5FeWNQhjqpTAro9Q+x6y9i67f XJkhY4TGENYC6hzYmFy+5+7G8r183ilXS1RZqrmACrmLCSsEPebky1juC2lWZn4EJcBiTjDYrgw/ ggIwaDFhcrEXvkgoNGFhsCPGpwom4OU5uE7QBo8+qGayT59+9Xzl6dMVgYYRV6/rzE/x+jcI6YAy aEQUMMBBRykFxSdiL/Z5lj+1j3IU4RNO4gYoMFeYxcPXut/hRtc0tsEd2jM/EGAg5NtuXy8qcOZ8 oVhZmMss9fB/FJMCamHoVwlk0SRUwB2IaJkfOMYU7iU6+2ODFmQabz/mjtC6M7OypPB4vKxF9Chy ecxexseL2CT/AIN7WIiFlZyFwpgc8ubbE6ybenNyMt2bCXLcRnBwMkS6MDg6PBL+6GN9uouCd3Ep no9dOsimoGJRKMSbeQMEWwbt2TWzhJ3ObHzxQczHWxO+mrvz+QKo9+/MJs0PH94+FP44Gw+ADB1i bW6tXMpKbgtAUoKEZF5RUEyl00oHBSttnAiOhEHkWdHYdLxgClOAjaxlXIkBT8EqRZGfj0YZ6Iry oo8Wi4Zq2Imlyfu71KOadatMZAhSHPabFPIsbXGRsXRjqtTKLPWCYYmVHbHtoBu4EootRrzQgZIH KqoYkJJ3DW2QQMoNVBOjFMwrY9Fvo1IRU/5E+EgQIYb8CRoP5N5FzhGxLiz5crEN2OOwCObfa/I/ dk2c+c9Xnov5ePbypfEe2/V7f71V3bDIy19QoZBohTfCpSNYrjXFED5SXkEkC3X4raahD4/x5Ebz 2lR+gUeuMU1CTEgNEDk2TfMYWw/l1V6Ut/LiviaZtEkh14ZMbskdi3PpRcSAhXBSEQI0LWglF6gD dh+5xSWiJ7Qkt8sKk1tTJKySzCDmM1Nib2ogjVln7FcAIgJre7J9doAlBvXdbrc+Gb75L78/nx6c vnkjRNIf9EcoyBqP/Tq4RCyIsIdARKz7nnBJgKHu/XPNpMvtbBi0jhvNYE8+/mfoaPAwMbB7hUbP 9+/f6nj+sEXwo6ISlutiYuiPHz6c0XsYWqe+Itm35ErfyAsMopH8RjISpTVHcLcIZ5IiXxAkaT4U Clm56oth1p0MoyrLttIIhpUyiAIDI7Y6+GjZImPIz9gRRojtMInCoi481jX2ZWmqxDX3ZTvvWJBV eaceU9VVKMQwj6vAZhSXKCkV88IeEGSQZL4QT54Ek/OFUaDCyuw28Zg08cIi+SBwyAMOvIrvkjjY lAKEOHsis1ApyXYT5O3Fm2AaEVLzA+x3EEFmp5Nfxr/44qtnX6w8e5Z4afDx3et67ZifQWCRaguj JACCaggLXPXVECD05IL/ScGOVTs7HUKIpfRobGS/Sk0T9iKqjrE4CSwiXyyZvB4MgIpb9HJh6gS6 gTEXEs0rxzccW8QsySL5ZAlYaS+qCAMUFtvL7eU7plG/AsO/CPeyZHhHALN0bOjHJEvm7KHw0CzK 0pw+4EVMMf1j8yfs8qUh+QxLPFE7iGrDg7PepDf5TWH07b+8mU5Pvv39m9PT8/5ALPp4NPHqjXp/ eEiA9Hs9P8C69HE/qDdcP+hzT9WQTmToo37XD7xqdRZgCUJt1r0U8/HB5AV/uEt8fPd+vgiKQV12 mQs+LnrC5aQPfrLddEKLCBcihCEupAgEZI3ZEGAwe2hlGefKAjOGS+DZU0os+BkqMggx8SPyE8VS lIkSyCvYGLtYJF6ywidFZRaAxNS3qEJjfbBVmNt3NPqyUtj4fOTi2Q9vF7R+RWCB2HI5ZtdzlZh4 +TxzLHD1dgk0URdoCAFUSmX2KuZYs5JrUFzltGER7e4Oqx3RDoxYFjvlkW10nScCj/4Tt8SWdy5q 4GJ5F3wjKHHtzGr8yy+//MXK02fPEySPLQ3rpndRGUQQVA1XyGVOo67wwBAidSPq11vu9kiUdTFb LJXKTe1y9Dwm51ushDSdWYNrZOxb1yLxOFUAIEsAACAASURBVDa1fVuDtGInMIZ5cSwLBNcAOLjV ucPHXCAE7WVcCclEEPJHfbL4sXXH+xaMZT+G3FoAoeg+ICBleSlEiBZAapUXa1JuTfXKPaE171p8 bMjks0XlkAfDUbde6GGwyfD89HzUy0+6vRN0hZz+/nfCICdHM78XDM97jUbdRxnKeHQ05vLXoOdj pV+j0Qj6ffSwm5KV3qTZnM0G/gAbC8Urivl4++FuJv9dS9R8eg+aPd5CfRlrHtwhYt/wfaizqrzq RWalMuLN0+lMkQlCeA0lE7m6DWYKxIydQmoRcEkpj6TTGgdjDDidLWWJAVsLvKyICXxlNnGg5r8I gUV4pE35F4NelnoTxq+EJMK+FOGSQp3+HgqsiPouuxTLO9RYtjj4fBCIm6m7KA4um7RI3XV6Tgxj VAq88FnvJS7Ezpnor0uRJbY8J59M4k4cv+eDLLxqI+eIvCKDMD/CskfPxUBIcSRyERdSP//5yrOv Vp5/KXfPIKviz79kZHeC5UbYAoRCUtQCEScYAInHqpptHYup+Oi44+FZr7ErX79JJ92qUEeNi4Za qPJCGlKO0QsvyJB/vuvBdas5aHOwF7t/MfPuVphE1FP7muO7jhnPAmbINgMDARP/Yjz4eFFDxMy2 L7fv+fzrG80zKqeY+BXMx+0tS7+gsOhnlo2FNwVfS/fwsbwUtpj85e0xQsiPFSDdEQpse2enp2fc BjKaHhwcnH77rQDkfFSb9cYHZ8HublcI5HAc9Jkv7AfBRL7gQbygH2A+1pmGsnpdrzXwJwPByAyV Wb0Ls6V5Do73d/gwsV1dbMF63YveTNGw3+G/SSfkEYKkZWdT4kM2NgqZbDa/sZHJWMmkBXGVKqSM vLIUIKLFkslCsZBOwoIUmHqnk1eI8C35ZEgtgELENn5EUFFSp48fKdrI1psaSSO40jAaVhjNyjOu lTfWBCfRwivgqbuFsBiyQI0l5wUYeZ8EkhMTIradOUgXEitn50AWqLt3Oaooh/yIRoB15JCIKwf1 8AE9CCYKI0fS23vSF9xUkRzRpL12KQo8qnYcpnxl9enTZ1/GVxi5MsGrelVth24Ba+awKQ8D/jpY LcfcLvt8W3oeKHHGo8uLcWtfPizlYzRt1bF+kSuTQBVse4TO4sAV0dXs3gI2roVBsMmU44oGHOFF 3SW6Ck59QGcisAl3NBInorsYFYahByqM4JoTCKLE1xrxXRKVdUyAHB8vQaktaVCYfSdsMCFKWFPP Yi41IoZf5lbk/g0DJB5jVsSD4bg76UFn9brjs/Nht9DtdvvTg+kBOmkOzg8Og9qsf34u7wpGR6M+ yEPQgYXQiJ+IPZyIwgr88VAT8kNSCCYvIqfb6kwu330wMxLDdvP7aQ/Oi33PrOBbA4+OOEDFRMsA xGADu2Fb5SwkVhKh3oy1vZ0QhPDGaz5FIFjpFBhDnsPPo3gLlzhQYRWyiFKBCOS5wGJb3iF+I5IV OkKQuCjnaPijGSuttgXw0aphdPJGi6q3tBIshAPe6SLdKOyBV+XazkRjrJO0Coxz2ShTkcd6bFfM PIJYfp5BsLr2AMfKOXTLo8dRJ3U9yefEvTdQBMwbi4VzZdVWQIYgpo6Jwpjvhc7GwNEheK5Pfcb5 XMIFdmoFN9SUrD57Oc8Kbn2Xr9N2gEAqFboPfHP+ZZPzglETXNXgVVXxgU1Jl1uvdzu7DTOG3PFU XdVqxyyzRzVkzbvGfC9Prvdj9jtySOqx2RIEWYUpE9cw54xkUXuBKWpEBnKI7UFbp7GIBLs1BNI2 j7f3EKJLHZGe1/QjeUMOl8gbXCt3344g96jJxlvjTZZVbIV1kCwaDm3IY/E+AMh0u15HD8BoOM73 UNDbE6QIg5yL/zg4eDWd9j1veHoutNEXO6/aCgBhSzoHN0ywmU3Hmow0HTIYNKrebOA166+vPtzV lYTpwbvCkndmPJOmzT9cjGcYPTqHBMj9JnzG8GOnYwMh4kKEL6zk1kY2w4AVb6KlrHTo0uXDP70h Z5KCl2wkBUjgxRQ4BIwjF37USifzaSuTLWazxEI0I5d0VkCCfitlI5vlLNBqTJkAQZBatpauaMCM vYxuGA/WpGRdZ0jYoZvXmmFwTRGZk3zvSa9gmyQ9yuvLsZgwiRMUHAdjJJ6M/d0KMok5V5CEsULa Es/hqbToiB4jXxL4Za4g5YucHUzZhRUmnZ2d2OpXXzxl5mNlJa7ksbV1tfXdS6GPqt7IHyASAMEo LD0DBte3QHt5wMdY3EtvzHH/3GIhaqGBfSj4QPRMw4rOF74W0DQqzfZeu3bc3qtdgz2ORV4NABzM 8RLUQGYpOARBwND1YLFdE4AIHMKwMALE4JpbfZyHf9vABCpXluDu6fAXWjfzSHHo5BfCNiw5XEIt 5DJOL88NiqLiVv36ImdFLGpxPeAh3w+GXfbpoxirO8Hwn5HIqNErZkIODqbTg+FscHg67XLr7R6S 6oKPHqHhEyOBh/70YDRFxxRtyDhoXzflM6zWvfqEc67ulZZobvDK4IOz+X80O8vfjRuPDBpaN605 eTAKP392U42kRGSlE2lNiUQEIEIoCYWIgCFCs4FyLVvUl7AKLTrxlLZIIwz5FrNq6XEcLSpahCuK OBCFlbFT6vFJH/JzYueZMtECYp0MoYEtA4F5tqRgol1h1YrphifSTKq+VHK3n4hF3y3bTi8PcBVL lV0cO9Ba9ZxQjF0y9Sd5BwXE8CSADipYnHyQl3c10PnoBL26OH/QCnb+CGlg+nbZcWq56osXL9a/ WkE1YlzuEwIN5Y+LrZeNDvlCDQgeOxWlkBZJpdLhK02+WtWwVhfNVNsvf7F1cY7tMRjb3L0cd9Hn i6WMxw24kCanEbNuGDmY1mCvLccio0RZmRbgNufZ7bWvOU7imF4Em+dg2JuDP+4RErfoEr7G+Pqa 2hJBxwCmnZgBXJaPw13At1jnCHXVFAYxGXcTyaLvX9TeLKg1lVi3alRIG7ehpmL1l/kKPQg64h+M C5wozWxIF8vUhufTcf/g9PQAc97lbhp4o/ODXs7tjfs9lGONxaT7QVcs+qTrc+A7BjigrQTjY/A5 02u3Z42afyne44MuKr9Lnt8L75qtBf9EdfVhPJsnpsIYfEuTV4TGTRjQsuNyyScSgEcyFYEHEXwk CJEUUZICTnAYScOfiHoiYYiMSobkIRd5CgeAWkpeUXOCwBUNSTSD6hTEALIMg6EGEidMQl7cDhMt tCwgFlPLwjtNSLLMK8c+YICnGGUzCvMrKKLP2Pnedj4WFXmVf4JilVhJ8IBjxLpcjFQp13PaGQzK QH9KHicFE7HdnJN/gieVUgVzIxxOW0GXsIgwNJlwiLzjAiCbq/EvVldWntN9KD6uLrZe4/LHqLtq ZZ+zgSskChZuYeJ8q6XkwtH8+qzTnAg+htOXz7exJGPIvUkYLDBpMHjlkUW4mpIzt3USJAaoVjGn q8ZxqmrMMURCHmBVxJhjUBHgQm+P8NY18ogAznWNQa4Bo1ngD7HsNdarDEzFowIE8EDsTGxIE1bk GBxB8SUwCONctwvLS/Mc/q16E5atGN7Q4i62aJk4lsHKg0kdg3gIC45zEyNycDQ8eXNyfnB+wgEn o0FweH7oVX3WmASzvqBkEsgff0aRhb5CmBB2bo5Y2TUYNFtdFuS+e282U9w5j3BHMwYkIjv4PVZC jbqt/ZuW0kfr7t7IrdZcZrU6dbmq6UPEqa9nU/IghkSeCiZQoiWYSKXzNOwpwdCGWI5U1gqVGOCS FkGVomMBTop8QYO6ZBn5gSzKuoSE+GIBP0B3wsseWivNMFZaa73ssH7FDmsltTte6cXkTIoYtSIf +3n2mOTzqrbME9BBrLS5WUbgN1bCWwPUfaHxsa5N9PTqQd7AAm3wrh2rlKiyAt+pw8QwM4KlchxQ 5+QqL178/YviV6so130ZwkP01UWeQ8Wr4AyxH7mcmLtcUyFRqXKsdqOlniTHR/j0anNyOR6+Odn+ xcuL6VQ+TV+Pzs7QnHt5OYEhJz4wmwiunb3Ajdpee0+0Nobccf7d8bEAY2BG2GOIRLvGcq3BIod6 YVgRQlcgFG6bE6i0ockGA6orRoNvsVSbNh/5eI0NL+gyOn5xObCuBr5l6fCxBsCOWWfP0RCLIb1o lwnoZdHMULknsUJHsvzArWOQhbiOMwz46bKc6lAI5AT4gBd5dThoy8dFvREMD0eo5+2pU58whgWp JYTiD8SgYGzDsAcuqt346Kj9ZM4d7+YzfUx5CRPnTB2yHQqJD83UmoogUwBkHEiLpaXUWo+qFgGS 2NhIi0PfAD4AF+ZHeCykkg4V18b2Bj74s1ZG35JKF0yYK2WohBRjfEkWfsJmzjGbpaVhA2NazEkG ZZIcDMGft019F1KKWnaPPHteHH8hDS8fKjHaFEMtgMh2vlDazBAsBQoujX/lFRnoAd6N2Y4wiIvU iQAC4kpMfa+Hypac82RcqGxWCk+e9HKlku3KB1T+Sb4nqKlUOCC1hbna7C+pYpv2ixeV7IrAg8Gr LQHIxdXWpVvdxyIG7OAFmrinsXp3406faqMlmKkwBZLDd6c6GZ2f/v48GX+5hRk43e7oDDuOR1ef XF2+dpkoqQ20jR5exKs2HXjzqigJFLrorBUu2uJ8Lg9DvjDDHjMo2mZB/LWgSEBxTYDApGB+6i1z i7fqSQbMk6i2guO/xlKUBc2iNLFdngBBKAvLs7X7hD1YNPF3KRSTS2wvL5pqYXDHLRlk+S8AMgFA xiORUoKPeh0lWcHhgdxOTg7ODqevTk5eDWr+xBUhNj4cHQXdoHfUI0h8hq/k32gv8CezYDw2TSGC kMkEhSV3cxJJIFdmqs/VDyb1wfQIIrwXY+/TfYOPlklT3dNVRnI1VXO1cuiiTuCCF32U3thIWKKw cI2DTSicDD5S2Uz68w3oqkwmCsNieAP6i1FhEEbK6C85zmayKWgn4MuKIqkIjDFYXBSApFDXouVe oRrLWtqDZfgjnbe0jlI8jGbmTc2XjlXBeAkBCFriP3+yXYgWtQsYZcZ5QkZYBOHhWEk4IyZGPv+k l0c+Mf9EbuJKSnU5mlQ2Re0+catlpydnHVT+Vl5USo1cLgZsCEBictnvv3ixgz+l1dCbq7zacjAe VnzKzs6OoAS18ABIpXIfJOpG4D8aIsUAkWrHOX/zr2+GKyvPti4uRtxriRkol++xQPJqe4IIr+fh DzRXDUZdF9BBXQ0G3jHQ4QkSeEKOMWcb2OB4CeETcfUYqApUcZQ9OGPQHCA2bALBQIwgBFx0PTAW 5FjH4gEjC/giPm6PlTG0QJix4eO7HOOyuVtUd7LIpnhN1/OIhiTEh3iQCTz68FDsA+aGASC9syEh IhZdKOTkldjwbtBFvwjy6MyB0IzMAvRQBZoM8XqMYaFicTi6vHqo+uqjpqj392raUbUrEHlIePSC ybyStHOjPBK6D6O2WqZatHNz0yikIile6bjmU0kBSyodp6PY2Epa2TgdSIocwYs9nZBLH4AiakAj eC+RotDIZkEeFuJXFhOLZB9EjdPaswgSyhbkN2QthpBtOBqCJBUKKowZyqZN7TyzJ1YxVgy7S6L2 PCIshrxY2N4GMkrMnuTZHkx2KQM8dmWzVHBsUVY9gQZ0mWBETL0bK8bK+dETt2QLcp4EbqGXZ1DL cUs7GJiSq1QIELn6c9X9nRf7AMGOnRBkIG/+HfTV6wY2aFVIIMRH1RBIpVqqzo87GruiJWmaZKJz 9OrkfPuXK/EvhUJGowtBx/Diiv+wnzz85Op1d8IPMUCCk/GqDa+l2+Wdmhh4hUUTAKnVtDzs2CMc 0OgoGKrByA+u23vYFD8gu1zXmGPkNmxKr1ug5FaT7gALOUTQAPJQtdXkwW3oTgxrtEOs3B7PU4s6 d6sNgdUOZZaRV4obZZMHusgZ3RxyYY/Z/DE6HB2eH0zPDw6nAo/p4ViufgFO0EVv1Ks+tkz1hxis iPhVT42I4wWmWlF+2TuFx1+kzu/hA8vA3mpq8AKyDUtvb+ZFDXO70QkzVB0T8KXIarmJVDaVEKG1 gTBvSvABToHiSmxspRHlIgyQUUym1i0x8FY2laYISyD8lUpF0ix4BD6K2ZT8tmxWUQOgIPRF2QVe kvdbVl7knCUYE1cifsZSW098aKpEfg8zKBl4dsuKMlYWRdmKTdNPi5/RAsgo2uLzefEe26b+MQ+h VYqCJ7aRbIyKt7YLruUSGYEWbuXzbqkoP+rKj8Gx956M8sIYMfnGbusdcIcILTnGegYx35XK/o6S RIHsIRD5+upiu7JTjVViAgPX6fXy273edt79iDs682cVmhnhDzJKzivngl76q5Wvnr/cYmfD+PLi 4btwheQnDx9edbFwroOVwKjilgOEsho1B93xDQyyQ13KgFse0P4rjqQGaBx7NTOLG33DiPvSv7d5 gFOtzvHeACIMp4EVLsO+DQfXmzIVajSKrGsVYebPHWv85a2tpZDARnuRDb4kEHLKrbHpApAhciCH w1F/ODpC4btIpOloBIUFfSUWZHqEEaSCI7RJIYgbBOPhkRxjLFYvmM1Y0zvojdg1NRxevPvwyR19 hGGrUFwxqvWjLvd4KPTR05unSGiayBWx0LoJqxVbof5iI08jkc5GREClNz5Prq2BDFK8rtfWU+JI UmsZRnYjcoFvpLNrqUSSoa1EQq56DQgbEZZMIUplZBdLu6wUiQO+3rgYBoKRUCQJaf69QL4J8/bC JXL9R2yTxYdT13YVJE0YH0O2UPCivsUuRuHCNzctiKrCvBpSSEJuopnyRQFIiZPq8wWXEsxG3/tm CUUrZUyMrJddQZNTeoFZ9OUquxMxKqKyU2a8NyZQ2d8nPMRo5OqvLy62rq5EYG1Hcc7pHx3+3dn5 /3J6+v0/nX9/4UJdVbCyJGSQO1Oi4awWty82yuWGvfJ8ZWXjEmLh4kJ3tIT/wCK1LkaTBqpSOvsc VcRVjVg1VKPV52hIvcGr1+5uoAmMrleUCGnBtUNKtZlUbDavb3VO5GK7pvaE/gVpxbtb896xlg3D oFzPscBY2EcAWRZYtKmtbhfVhbSXOYCL4ksV2OKDs7MR1oJMR2PmMAgQ+Xw4PCU+EO0V0phh+Rrm YmH9gegrwYem0TGI1DcJQ+WPoZpzzZ2/AzDegT6ulEH0/Nvvv/+A1Md7TpYnQLrNT++Zj2ar8xGT 3CtXhB8pYJiTiKutjdRaFle3FYEtQX2WmPY0EEIMYOgTBFgqnqLkAoOkQT0pOvpEcT1LfYYLHrEx S5UbkBER2jBUIlYmJbhDEgUWRV7OhmWQBjBZLRhOK7MgcQhZVsiUGOWyTTmkDqG3RErlgYIS/QeC WcxP5rc/Fxn1uWivemazhA5gcR+iyhytibTLmxWb2XhMEK5UMJeOiqpBeNioCC692Mk5OjilUumI Sd8RpyHm3RW2EuOw9XcXafnBo4M3b/6P33/7v//zP//z6ff/6/dn2wqI8pw3FByxqkKmwcBxVYfb C3fFV1aebw+nw8vLd2Y56Pwj8JOH73543W12qjv7WP3ThGNvtKpodHQwdKiB8V3AiNh2h15koPDY 8+9UFyYKtwZ7A+gtcScDRreIKK852Nu7xbx6BLRQEokdKdfXpoBe9wYZ0aXFXNcaET5mlPg6xMdx iBikG0EebZQK04WQTXB8uxjmRAQgvXoPm59Nkg/9hYKSQ+QIBSAnZ/Iw9F2aDfwRs350OBJnTvch JKLBXkS3Rv3R8Oztu4fzzIcAhMC4ej9v/ODObnTUst283ugdyn+yJz/sa1JQVVXYq9Mxqqpz36yj pvcZrnfx5JFMGnorq9d8KhHJCmoSaxlhj2QCUICootxK0Hyk4/AdAAXOFzP0IjT2TJcAPkyhpC1h o+0kxZQAJJJO3jEKA2FqUPQHkVxMMQ8pToWF9xz5KKYfqkqEF/Ej7xKcZAQJeZS/ZDIYUgQoWdFS hrNUYEzyYRVknmpLE43gGHeX8IjJrVTarLi9fK4SAy6w6QQAyZXF47Ow0S1XdoRABCAYtVIICrs2 6eni817/P/znf/+P//hf/p/ff3t69vnnWxsvv3y2RsUFQKgViREbItSImbKY9Fy1iQ3znD6UY0p+ 6/Jy6+Xr8QUGlt0BREjkk09+uNyuMyOPQVwIaKHy3seqExcM4tV8g4Wa5/jCEh6MiD/gVK8BXxrU uP4ETkQXotR4rL69fdzgrqCmgUOTuXgdG9m8TyTXNCCMXTEPr1/te6GsW61fASy0qL6N3ve2kVuL GuFafDAddScoNcTWNbEhY/1MH48OX716dXCC1vSD82lQ6x9hWugYEd7x0cifIHkOYExIIAEfRJde 3NmPH4gSJs3vSq+0qP0tq9rHjfpuowe6kt85Dpr7N3ecYQw7Sha12iQESUfbQkgHGwIFMSPp9Krc Jy25isWNW2JMRDqlGNgCzyTIIbiz1J0QNfQwVsQQUErzJgSZpbGu9YzGxLJKLKaYJZnNMpkCNMlX ViEiYoqiKyViq8iS+gI9CUPDVqZoYsIipzIZO5+ORPVZumhekXcUopslK88pwzYiWQIVy2Utfpik 1wjYZqUUq2xWooUA2UO2I5Z0xlBZrnMoMIxVKQk4Xvz9C9YKF5x6sY6Acn57+J//8Oc//+lffve7 352ebb18/nyFE+OiZfHnBMmcRsrmqCznQR9lUVj1Okrz7dWV589ffimG5uff7NTHF/gHv0OIYuTq 9QS7fVkIjDVBjmdujPZiGguc+8DzfESABSFKJD7G3hk4+LW2gz2mTb444CHG2tPUEx3NECLEhu5A MfgYsGz4GCmUW9RGkkJY4LWIthOUsSD7OCAY2mjZ4qOAwyRFCJpFdSgPRmhIx1CS6SHRITqJVmQk 9uPgVDz62cGrw6B9OJ64AXtvg/5Rj8NNRF71WGsiZMJsYQ/y6t1ddnDuQa7YMch0yCdmzu6PF73O N6x5myAsIDTSNEVYd7ewjLfTmiNE41o3jPSKmsqKA0km45GI3KciKPSNZGDd5cMbNEFaAEYSzL3z gz9FmYXQlggvkWZpOHaRUakktRcMCtgmK3jD78kacBBVIstSa3izZcLFGvxCiEveyIS7WJ+UOamF xVYxE9WaLTktWgytFCKpiqZinuUsxShjvCXbLmaKBc54NOMjtBgYOEE2JG9XKiWCBEX2WL0o/BEV /sCMLSGLGMqAOTyIOZCdHSEGtAmXQUfddOI/CTx+9tvf/vZ3/+f5y1/9/LkgJP48vvK0XCE+YjD3 dwxSzc19iM7zdoVEPGv1+bPnzwUfz9d2vnkhEJHPxA8P383rI4iRh5evu6KwsOu6o6Y9hwEeniit nIlrOYNazhNM+KgDxkRh4GVvrwY15aOAS3DhEzkCIVoWhIiBlfk2oONw7RwzK4ZBmqHIUubA1KHj GvDAm6KlHWbmwUhUWQYpy7fttkZ8NeoLb/IAQ3963dHBGcJPR71gxAWFPf/o9EQk1snBq4Pp2WGw d3TUmxiRhZJeHZGl3kNAskcK6WFhUVh/aHoGr+ap83f3xlCLvJp09verhW5vUheITMX7eKzibWnR biucq3Gv3L0zr87qtArP5GLd2oisC0ISuCLl+l7bzMjx+qa18flWorgqCIisajQ3zfCV8AwzKAl1 MCmGvyDQYN0jcCO88E0ILMmg8fqaCDnkHy1ExEwqHvUpWvwlyEghAkbDntUMCaLFWRPjStOrEyjC CABNMVKMZpCt1+IWJhEFFent7bS9GaWoMvUrplmL7t4uVWLw5Xk3t1mpbO6If3GQIIG+QgcKZFeM 63sxelsOAA987WC0Y93GxPvt18X/9//+87/92T/+y29/93+db/1qZSXxfHXl579cWV2NqumI5aox TYfEYiGdyF2M81LlDpSVXVnRkuCXv6G339+dXL59i6QXEfIObXCgkfcX3RxbTLS5BHPR0CIv36iC waYHUV+iseTYY3BLzMnensCmBr3lO3yoGYTUNHmCN9bMNiAsSznWLVvHZh22fiOngpO3TDpqixYV G+HAlfK3Bh+3IUgMPlRpAShodEQ9JCQWd3uE0xWRDR/x87w3PDk/OcXsH4HIq/5eX3wHt01Nekfj PpRWz5Qs6t1gEIy1sP3d/erdq5BGWFfyVrdvirXrzSCcKhMuTOdSo/EEsxmazXmdyV3ANwz5tu6s uy1X69bnWym5gOki8J3NrEUSiezmekpeSabBG2rgLRqQRMgllFzCGMyVGIZR6MjZOABA544ar1Rm Hc0nW9vJLAK+STXtdC1MqeD306VYzNMDAqjtyqpZR1k9gKLP8gWhNWELlkhqIT3AIJ7FBoU8+VxI JGMXCY4YCx7zOtSrFLMKMaEXB/lCcR6bOy82c8wsshde3irUUYqh67fg2IKUUqm88+IbJREx8uh/ RIwsvxn8+z//7N/+4Q+//e0fvr346jnK4FfjqdUvVlYZCQNGSkog8CRlY9XLbGuso/Q+Vy6urrKq S25F5hh39iuNSe/iLTauf3KntZAZuRwFOSEQRQky9EIfZJBZzcUQOw+yymdfBHrma+LVIce4BULQ 0nYIDaZIQj+ve7WOPYWGBwvP3aY1BYWRWseKGrDIAEuymTJpK2fcasYxpBCRVcuh0OIzEoj6ElBI Wxhkm7HZsyHV1fjsZNjlQujhgTj08+kUw38ODvvB0TCYBSzmPRIJ5iMDElBiTWjSB/hL+hDqq3dz dRV6j7ea9jBl7SYv2JkEGDfEwukxi7Gac3HV4pQMTmnab5nBTGEpY6fTSCeSWwhiaRYkoTY9BRqI rK8nBSEJU6ZF+ZSiJ5Ez4tyJFMHMRtKghqwh+iohFialviUOltjYsNbX19LynxGu2kBafkOrVVCI YqkYg8hCdVeKA1EBDFMaqSUsrHJJRcJiYqZFsjrmztbMZIE1kNmoldz+PCk+JMuIr22nC1HWvUQz 0VJJiKUk7OIibyg2ffPFTinHekWMw94xvQAAIABJREFUP425bqnECJnAyskJmVRiZaRAUIr1Yn9H jMiugAShZfffiMT62c/+8bc/+93ZP4gHib/cnk63v1hZsXLQV4KGkqKkVGI2JQYTgtldLqemuvVy 9pfxOIdpXW3Vq1qsUhEll+teimEX/XBvxPInD99djCc5NvWEyflcs6mDvdDP5fli3gGQoC3PB6LR HWZOlF6wNgtTvoRI5E+bA7sHGgpmuIvfCG0xOIy1Diq2aqEvwevQV7rFVAmkfRs+Yc0KzyiDACO3 5oBksnirVfcPxuNLFg2YCe9TIIVlBAfoB0Es60BAcjQQ+1FHN2FPDDXS6D0FSNDTKFZX/oLevfuI QAx7XKk312GJ4I+3o9n+fpNE4GFfeo/tBUIhOgUghAj7CVv6Pkz4M2qLL3Va9gaiVWssNUkZFoF8 SiafRdYTwM56Bg8bnO8PjNCZJ1RgsY5RABJPpEKU8A9sjFgTPKOtWV/PJj/fSCdEtG1kNi3WesmP 4teRS9Lqc4Aw0WAI+cLEw9cLVsSmJ03GJPQjVkgnsCRZtnWhOp998JhaLzyRL5i1J6xSKZWiGQDE jkWZiS/GoraY9BfsbXew2DdWKmCdiV0uiUXXMfVCIjtaiaVOZGenAgFml3b/gzDIn/70sz/89mTr a/Smb09P/rfxyspXK0VBBUZugz9KEFgkEPIHdzlyI0o9Z31hps1tbb0Wi4IKF+bk9yv17lgMqFwD 4ZR+uQmrXLzuusyjYM9xBQeNZg61jDMPo4a5XcgJfDwJMBsSU1twvolhqeJPBDc+J+GBRWDsa22N gGkgrA2AwPojHS8uhWtOjexiUoVtJjVj2GHUwR+3eHKrTj1kkvZ9V3KXMwGDjM3It6EuMWAqHInD g5NXhwev0Hx7OD0/dPriFvweYYGxcVqNRVcy8/eC3sWHHz/cw8dd3vwqrGsngbAwEVe7Ngu2UMDC zgLM5fL2Ozo+hr06rTA/yERI8/je+J9m65G3pQ7EAMQKWSGR3EggxbG+uQ67Lhd2WvGRiic3qLQS WfCMAAWTHhLpuNxSIcSUP1KquHi4ymRL6svPt7IESNIIMJNV0Z80Jh4YWbPILIoD1qYwsxJCBJhg 0DfFuRNMqEB0pa1Mplg0/VimLNKKRlEfbwmJYGBXFGUqqNba3BSVFStwFJecQf5Q3ii8UkGORJ6U Y6U7dGi+sIJQVzHT/2//7me//fYPf/p260ut7t1OpuT//8oXTzMUV2WOewRxQGyBQ8r1et3lAkfs C1r9igQCgLzMVXMxgEMg0qhW93eq9deX3//44ZOw5+c79evvLwty5TdR+lhpeTl0mFQgthrVGiKf zszhakYgY+A7M3kiJj3wqjlyBmZFOtj7IJa9rWKLSfha6Eu4MsjDuod52lFNO+5g6Y2Jv61pS8kA tALXjtfUllBvmTAwIBG2ZemTByOd6z4eHWINAot5UU51eDg9mx4CHucHh69OpjNhCVcreV1/jM50 9R9BsCfufMQPj/dhfjBkj3nllS7Cefv9h4cfLusdDHzhQIbWccBtU3LD1LpJ59G82KRZu2dF9jum CkVLs25anW9a25/jehfTIMIoay5qtIUkExsbG8/WX2yuQWPJ1T2/QVTJhblqwYkkROCIE0/M6SdO TKySP3g2rjY+LVY9Apik11KsQiHnoHpF7uVNSRMXTqi/11xjimIrZbL0BIwZrZIGZgxIDK3YqHqx ixn0bYkaE1ceYUoRl32WJl7oo1DUxGKJt4ooLt3RGC0BFaAase6Y6xVFSXCZDII7VlyhFrFUrhcy 7n/9j/96dnHyH/91+PUWG0Se/8OvVkRqrayulUE8os/AHQBLFYGxcqOOKd0Cj7otR1kkQXRgkDCI QAmmXm5l2BbBSrl39v0HxLTevbuL+/7w/mzoYywEso1Nk6XHmiUPZMF+4pqnCIEbGZBCNDKco+Kq cY28N/Cx8/eOPTwEwxgT84RAPK3xOmYk2axorFFfCabw51boRtsWUUIv50VtDZQpam1j2EkZIrXY hGKM/IPhkHND5fsVmjlGRyzIQspwePjqjCWLh69OT/sDzvmBxJr54z7sOpODfb+317sQcoALf//R 1ParkD50ng/Hib577cm1XsO0E2olsfZobuae9m5gpmcADM1rrKQK4dJCCeNNqL4EJd/sOyqfIuHV b3LmEFnIj6zTvocA4IO4kIhlJTSjmBAsMKJl6AAokQs+klIhllrN4l0CgARAlkVOBBYmbbIpSfx8 MpE2dV9JFk0aMkmFpfMwRmmCQ8dKyE8WtKFL7HrKCivvwyauYhR9I8wbxqJRNABnijHUbWHssNh0 LdoSXJQ2YxRd2AVU2WT/YhSxX4CqjNN2tLLzQm0IsNFheaJd6Bbt//Tn062vL799c/H11q9+ySJ4 gUf8+Uo2VoZ3qVSBEMbEILbKOax6ADhEYeVsa+WXqwTIFiUWKutR/1UBmqoodKlUXUDkoQ6YVRIR L/Lh3eVvcpy7lcvpzBR0nRjL7nEmN/UWBRaw4e8pQJwaNgfVMAxswOHECgeDEUJHj+7xR+2uoMVU 16MVpXbLehZqrAGzkPQqA1QIDwyD4HU9ZKmjSbc/wI660XRKIuH0aZQyj/vjEXpEcHslMuvNm8Nm bTLx+6Z4V1vTezPhlcHe+OIh/cf7j+zHHB7aF8XUubhzVuWiY6bV4KTKiXiQHpOTorKajzrhNKZW 7bg17y1s8os6q4l5453O/jct1Tvmhos5QYDIEWAhwFldNS/JK8/SLEVZz2QTycQ8bqWPiUTcQORZ cg2RYoSzshExKCKikskvafjJUPAgqUhao2EaJtawVkKRkaV6E3pIMTJgkUeQ59chXsyzQNiBYNKa eteIVpYBYRFZYI+M3IQhrAyKfDPsILaL0UyMQ7eRNGFtcDQmr4qwquC0VapsglTKxai4DXlDGQCp oKCXmY2K2Pq6K7/o6M/fXn399cUZEhm/es4m3MTzxPPnWWRUiAvNhIA+YFt0K4qAoy5WRLyKifFu XW3lbRAIWEQDw6LHSqijd3rjC41UCot8B5C8/+ThJz+8fl1wyB9IHeaguKoe5qjobgcByF4Ay0Hb 3gCF4OaBIoRgGjXfMdlGZB3FwTgu0eF5IVAUFQOzBqVmUvDHBigDgkReZQXkgPWONTXzCHFxvgpS JNBei/MiSCROyCC6x5FBLJSbHA7HRxhEOn6FEdZnqHg/PTlsNv2JHxacYK5i76gvCtIPBB8EyL3W 2qt7e3Dgzj980K7aCx9bojH8otlQfIhNHwtEtB6rN9EoVRMoQrTbuPSWjrA02qtp2gvL/KRPm2R5 yjhu3uKgi0R2zXCLvE0+7OOpbCaztsbolZKESYUwZchbcsMS3z9PlMhPbuC2tZFdtwAJeBxc+Yn4 HB/q+FFvD1itZZGQRHbR5OzZbZLVWmKgA5EroMcySUudFkFCscWGlDLRTDFbFISIMRGk6JYgWzgl EyuiziRqs2DFYquJVYqVYlFOSy0Jmix5vRQti8yK2eWKkAdLFfdxxQtAymK0d4vBn/7dycXF11+j /F37RMR0P3/+PFVElhEQkZvWCAtACnWzEMXGzqDUL1eQRde29qvtXEN+oFLVbVoIAccqsRhq6auF 3uUF5v+ZmK+akU8uRkGujP4rDlSVBziSKkYLNQiDADABQjzMoBjQfQAj/qzmuYh25UA4jotsCpIn GDYpx0CRkVo4ObjjGKouk6XXmBe/YO1rqO9iVyIqItvsWhwgIHxs5qyYbt5bSqwzwccRJr6NOIH6 6Gw6BqWMxaaj1uRgevLm5OwQ+zxNpjDoHY1EXsk7fM8fXTzUGO69/EdoQdhSq8sMwB/j5g33gPFL Rx23GqSQQAESeI9ozBULx9dCFqHkugkRYmK9nZuqTcWTMJ/e+MBnQCqdUKHFB9gFHMUTcbp4NRhW ipyBDEkqkl2LhB4FOmo9kmAwN8GQl6g10VjPIlmGhxPxhEaMk4lVhWc8jIDhQf8TbBpJh9oNGEGa PYGeYA2UkXPQsWipVxF8ZGyAolRajxYzkUgxY0eKmBUsNh38Et0Ua55BpXy0XCrpUEfhizwsO6K7 UQwVxsbFaEkAJPcCEoHEPgFCCoEOwlKSUuG//vlP//MBa9/nCInjq1hmHl5kFnmkBIjkODM1V67r tJaVlacrCdO3KwySw1atSpkL4/lVhdYqU86Vu6OzD5pgf/9dmBn5cPW6y7JHSCu51qs5AUeuloMh QcmWfnOgEe5nIrUCB2lFx0VcC4VcgAam4gEarqGUGXabEiB32mquxe4lUphLAV68AXvkYd4BC85X gdAiPmphrsT0lAAgQiGwHozzDtFveyDqCgCZHrw6PwGLnJ5Mp0fB3thM/PHHQx72R+JFYD+AAuY/ rjRlrjmQd5oeBHm85aoPr3U88xocwhfejpszzJTvTgQjAErr0/mcy1Zr0G6KrGqqBTHndb0LR53k kl/SMMjVGDe+IJ5IKAEkniXCGC4O5QIVAknJ5Y53QnvFyRpZXp3ZOUASqyQBJZQEw16oD55TE34N MPdMRFc8sfEMVcLm3SmFpsVnqykquYTaELbQq0GiDMPzCLIqIuSy7HfUm3iLjFh1ObKt6HrJRpkw x3MLQDZxUjglliGBIHhVKGQ2K4ILgYUgBMorBoqJIhRc2nkRwoPluXLtikl3S7uH/+3Pfzhj/9TX W1+//JoAia+srBZLyMXH9A65FNF3Vh0b5HN1ju+yVr/6YjUeNidebBXK2HWqCUaUbpVzdPVV+UH8 V3eRGcG82XegkO/gSRHfei06C9NSMHa4ijUOQiQYUSSCQpcFebrmwZk5uYYTBF7V49BVMSUNTO+G CAM8QBxGcjm1mTuTR9oVnNKc+wDZR+4F1k4UxocHJvc40Hp71nYN+LDYNimTY5oQUwV8TIklCBlr Ka8QSU/I4xC9U0ImQ4w1OTkBQMSp71Fg4dM+GDPOi6qsi6uH8/THnEBCoOjAXUxl4K6PmnhyHwE5 tsyEtxrsRzBhyTsqFg1DAA9ojJGjm1Z46gatBia2ddOpyiWWMLnwFCwDGg3lMn2WVLSk0qKXkkk0 GGZXU4oPo57wHByyKlfrWmYVhjqSTQuBrMkZXuKIccnz9fX01kYyAjStkiQINgit1YS6mfScQRQp cSOuSDAJZFYSTLsk41m6euAD4bKMlU9m1jczQGgxAnysZ0rrGVSiCEqs4jpa1zk8BdVcIr6EQ7Kw ItrnLlxhRQQbpbIFCmGNY6mECK/gA9Zkf0ebBmPMjZeruzF3Uqhb/r/+4dz0T3Gt1BZEljjv1VBf IUTGW8zVOn0U2ZdL1Sy27jwPm3evtusw8DQqZWYVTWNKTJMpFfj1ywv2NGhihAmST95fbRdyGGsq BgSTU8WCVHWIl5h2DLsTanEnLnjCE2seuGi98jnyS1cIuTTujrgQBq6wWx6rg5QxHGiuGpY9eKLQ BsDHYA4QhwxinkBSoawF2JCHvT0gRU3JgNEuBIJvYUkeTDl0ejgUf344RE8tZ1CrEznAaBOA5Pz8 1cm45vcCxq9Q1MssYf88LC4J8TGnEFp2kxjEso+LnoBhhsyn512zlEb+wGYc4xd2xaEHGCLjPTJz k2+axnqQO25MIAuLJImOJtYcxYQcEszphTd46xQtegLh1+xa4ktFRCSSzSa2lAri5kNeQ1d4FDCs RlCqtSqQApbW1rIRQm5zM4GSRbnUs5pNQXNIQi72tazorQSu9tUQGvOClTjfqRYFDVuIhWm+MsH/ ICuBYUwim5vrEQFIxMqsRwQBcouIusKpjKgqrgqyrEgEJgU8Q3awsErOzjBJAndiY9mcXSJAiiLT YmLj5d701MY0vYGaLUyzK9iHZ1ffaX8hvyC04EKyfwmQXV14yvXX4mEqqyFAVGK9ZPbQLmtMWD2I rsziupOySLpcrtC7QEwLyWJ17OiqurrMc1BEtebAhwg4RGbBlBAxOX55HC4MgJQbmGffaLiOycBz 2ZYLheUQNHgn/IiL8nmWQUJxuQNHQeHoyuwB4KGkouLLgcxq+6CQmk6xC/OLbe2Kv9XcYvvBGeZZ jQ5HfYGE6ZgVfNCTqEs/OZkegEUOfayE7o1FanF89V5/fPZPP37y7s5+vLtLf7DeRKzH2x+/50Tq YXDdas5qgxmlpHpuNd6iscge/N6efFzP+3Ftr5FYalOOm48q1gYkVTr8/E6kV9fClAj1lRjnBOGQ XUdWBACJ80M+sZHIrKXu3VZRciiX+lNhEMHIWkY4RvQPe6U2Etm5IVf5pE6EhY5AFSAHk3MPJmpJ 8D9mNavRACUXc0O5llz3a0IT2TXE1tbIIJk1AbJVtDIwHZsWphdFUKuYzpSKaUsu/qgIMN1MagkI oKVEWEEMoecKaXc5K0ZfDEyUdSCVmCb8WA9fLxVRcbJ1JV9bc5POWzxbLJU/QgiXyAvjgK1iOxiw Nc+BYPbDxTbMO7Y8CBTo0etalZLTbXNY+YuOYLd3gRKkHz+8Ey/yHSfaoEpr24EZwUpTucx1tArn FTm13PzmYYa9K6qLa4TwB2AQa6IYAZnI3YwcgnuIL8edYd0pdpkCG1jaCKTA8A/wxHPCRsYBC4pp PsyoiIFmTgZsOkFoC4mT9uKD6eEQLbaoMhmOxwYg7C4fw6afvzo4mb4CgxwENR9ZdCGOERikP7oQ 4/323Ye3WoBlKrCMunpvahM/QF79OPZZNSP/C0EcA6OwFCJNQoP8IehrPQpNSDOUV2pIVGVpDItn j286RcyL0ysSbkCvwHRcVQ4y57QkcWWGJMyE5hZhN9bWwSUJ1l1ls4ZRVq3IKkqAV9eeytW/no0n VldZgRVnKIAF8Ym4lSVK8ItxlL3TV/KTxGNWbU02JLYU/xsmcsYCYEGfwCEjD1lBRsSKyJ2wCUxJ VszI+maJnVdCLRg+LHix0vamXPwlW+du4RTq5guEBOYMESEZMSTMnhSNvtqt6IIeMRO7pd1y3c2+ NgD5+stf/MPzX6DHXCw6EBErRUOIgIxCgVVwK3//Yiez8sXqyvNnL+dBLG6NL9QLdUSDbe36jZVd s+haDmM5N1RaP/7zj5o5vGLUV2jksouUCBIpNWCl2irrRC85CS/SRCzYc7n4t1HeFZPuOjqJWAd5 M0ciPoUYcplkRHkX41kOt50KJmYDrsUeUGc5ChC2oYRplAGbULTflxBR6LRr2q11S6zQgwy1zAR9 6YfQWcPDviiuo/F4en5yoDeU9A56Pkuwev3xXm8PvecAB2AQyipFyNU8e/7W2PPZYM9vNGaYGoY6 5dkdPuTaD7Trln1aPefG4KEZguheBIs2ZM4nTbgQFo0kQrOewKUcFrRvbKDsJJWA4QBcxLGoh0/j tYQyiKBpFTXByixP40Z6kSbWwAerzMDT26dovFWgZePJkCpW6WjmvCFMEidtULMpYlJyJosUJlqE gYw1xAasbGRtje4jC1W3JnSSzWyul9bFkhcprdIAiPj49RebkXQ6itciiGsVI5HiZmm9slkU445Q bwZl8VlgBd9i5cW/w51jgWhZILK7W87Zu9BYheTW1uutl69fJl4m4iurTzG1Fw4dQJO7KEASixaj OmmYy4J2Xux8s/n0FythkhAIS+p6xnKhgFnaLndg50plFD0iLJyrQ21VwS65QnckSvuhXCfaPHeF KR5Xlz2nxVYslxEwzrwrI90ObJRbegIL5XcrFTcIHEa4BDKQVNyBwg2M2P4rLwmCZo7wCHPwLku8 XBatoJKlBpOijBImGVG/osZEVJbfVqS022FWkTkT+hNhkCNg4mg4PdRGENadCFpgSUbjw5OTc3YV vjo7mPbbKHEf9/wASzzHFz9+mMd3TYdtWHoV0sc7gw/hjxlROUNdGfM6rNv3WMA8IEDGeuvBX2Cj F+v+W807tGgF133J9ahVEE54ltSQajysRcRTXK/JpNj1VdaPIGD7TC7SeILJdTnx7J7kWaUJl9ee phJabBI39Vj80EcYLBEChASRmHNGnHrJ6CoiMcGAsKGk+N1/BGEv+fm1SCoiei+7tr6OELPgZF00 1rrAISNf2TUNWG2uW4lIKSP/2zObGaguOavjvXSFFt+0Xtp8IdYjA+tRRFwYDqQEJ8M/dCDl3Ri0 UJ0iSz7u0TfVLVj45K//pri7K29fX1+/4w3UyiM/idtukS0piBjv7FQyoJo5gVzkOcOoniu4hVwZ 0+uxJD6GGBgHSMDA51hXLFLLsSfbF1gc9v7d1Q/fhfW+V6/zyMXHSDjVGNoVBVJlJBBRWo/qX+4x xXQV7Ehx6665ASRYEeRqXNifYdmDMyEmfPh3F2ih3GKhlxwirQKxRVRRcukRDn20ngwUJ2ZmFwu2 OFJl78Fo+OoMU7GYSj8bAhZHR4e6C2c0PD1BnPcVw1lHvt/HDjY/6B8djVDe/O7thxAe8/qrd/PS REwVFX/+Nhjs7U2aXr8fzLzajF0zKJnRWWG49IOxwQdYpLF/U7tuzhnkBjUnHW2kVImFbcU36kZa jQS6mRgw4tySNFMeKVMwlWKbbQJKaiOhoeB4PJnQKQ5MiMh7xY6vERfp+GrEyKI5csKkYSKMUCHy ZVGWKf8YFknG5b+xqtODnontya6uqjVRw8IgGAvyxQyl5OrNxlPrm2sCLbk8MxFBhZXIboLSxH28 ECiUNlNJjFFB7X4Uw+fljZuljKkIhrnfXMsI07zYLEXgyYtRRMBQGo9IcQnfYiUqmsNDuWHdbuCx bnfzdbnysXQhFs7HEochuuyeuoqi4VF3pVjlig4P6pQE4YDH1+LQry628maJlpBHQUCA3kZb++PR 2ghOoc6C4HJEauV6Xfj1Dx9EXyDs+x1HmL/uuTEKK3gXV2lEmSPH9AonCOukSO5sdCmzctwPBF/i aMwr5zoTiC/Gt2ZUWoCLGBN55s8gulyWeMHZawoRVkbUmAZ+nbb8WgEIQGTCXPg0Z4xrkZn0QwJk CpcufqQ/Gh2eHY57o6PR0akwiKgsrIU+OfQHqIQfsysd83Tf0X/cqzBRbx5O3f1A/3HWb/t7/XZj cHTUbnk6H6w2w//MGYACw14L4aHzf250JyRLrzDD4pq176CVmzChLgJrAQ+isTbY4pGmwkprhjuh 16/aErIKvQYbb+8UGNMmz1JPsySWVfXTqdU5PFRrJfhagtMe9JcylZ6gsNJCYKRL8CuNv0iQbwCQ RJwhYf1F0FByW+e9vCgUInhE0bFoK8FDGlEDS9TV5noqYWWthJVBrn19E4FooRp5ZV3XzEWEPDYF WBmiKYtloyQPRcZ6KcyqVKosct9FvQgcdd2qowurLsDBopJyqYJqFFQ1/v0LCjOgSpxNlOhA45Zd rIq8wtsQdSqmEi81OnxxMdqm6ckVOGkFU7jhOvCAmFfZJjRsACdWzruYHBwrdy/f/YiW03kd4w9i 1ws2oWAQoVtQxLtjjXxDkBJr6SZGMSaMZCmV5EgpwiKCEAy254I6AQmiXz6kFpMn6licsCJy4DPW JWdr3oB2pcYkPFxKuy0gQTm94KRmEouwIu29NsO8UzLG9GzU60FrHY0OD1i4OBqeoOsWJCIAOe8P xKOPxaLDn4fpQXXoV0wLzkvbsatT5BfCuzMRc+g43Dvq11qztgAa8ET95bEYdu6yawas/1KEdGFC mjdzbVVT5lD2MAjphM69U1DjrfhQLLCGHRoL13Y8GXJAfK6+1LLQTyRNfmN1ThsajLJCMMT5lP+J UHLN781PxDe2MMohQcitml8RV3UFLRfPglkAC3Ec6yKvoLAi2dVIRpAgDCGQERZBAj4SWcvIO7LM ugvHrFmpNBw84ltQVBlUPWbXkGoUbKwDIGLVuac0GjWwEOCIgQFcYqVqdXe3LvYDWgirFuoa6C3J 9b4LYxJjM8eLFxVBCAIAQkNCQVBYZpaEskengukPcsnXrbxuxt3a3s5jeTwtiF2wkIW3GUrGegZs j8fwFYAiV66UtNlK8FjPj2hb3199R7v+HfIil9vMrsPdc2M8oAJRRV9SLVVRl4L8IRc75HSBVr2e c1wNbdW5GgXEwr3B0FquLlHB1Q+4yBsmvg8GgQVBpQoDWGJUai4NvAN70gZWfBgSv6aY0QAXAHI4 nYoJORohW94bYs3aiLVZIrIOD04BEP06HQ78vlzF0Fc/Mnb19q5/MPTpob4yG6POguZ14LcDfxDs tWszOJFr5vybLE5mWVmz2RsZA4KbA1U1v90ch1BRfXWDzEgnrGBsNZPPFBcJ5AZBFYk5WHAdx5Ph Z3tCHHJK3XwyoUOBmPo2Ikiu6bQ69bA9hNIMYWITCTPhALnq6c+zEGV0LIgDw+UzOZlVb4K2E4gq oajs0zX5XiMQ5M/qGrIs8r0qbPJUvIi+Ym1sxNcJn3WUpSC1KDJK/vcKZlhDZuLBiH9ZKUv8OiAC CsmQVopFpQC5ygGpzcz/R9nb/bZ1Z9mCSiUzCeDED7aRBm6AAjpPaRjlIECMCwwwL4PGuP+AG8Av gwHykAcHGqAGmFAgyMNDyqJ5+Kk0oEtKJikNNHZFlmw/SMXQpemSqCJLkKKonI4kyEqlZeuhIzmw Kk7aHtwG5Jq91t6/Q8pJVc8cSocfouRU4SyutfYnRdOtCYLic0EIHlRuwaWjFh49VBO/HiRArq3u XfuHq9eIEM2jcMAdKoJZLT/IuXLUarXCYnV6DSOEUDc5y555LnSYQE5mAAARzsDeICQMUakywTYu OPhBjH2sYZrWY2MRCK3vv/9uuwZ/zhCxHiqq+AIe3eZmB/mvQKr9kwkEt8ZmCQP0qEzOVT/HEhVd bKrKSw3IKD37pBGIoOC2VgRDas2MzjXmYN6FT9irOId2X0FHo0FOmReEqIHva63sCEDElrc4nlf8 h8CFY+SWVuUlCCykQTbv3bvXas7Jh3yjsbIj+HiqdYjf2wyTA1etaMGrp/sw6Icra3fvCnyb8i/P 3b79tQD3a2qr5a9nYEFuP3qrgwMZAAAgAElEQVSEqqw5juKyGYtNpQ/Fx8/UrmsdvPKIeXStQrmz iECvFplkLZ5lRVmOLTS4RMQEyGoHKBXJaYIk0GrevFZydfMUcoiVIOtwG0mQdzBUZ2JQYsFKQOiB irpVjtR0hXJZ+CMZjQo+ooQBDrgTX3xPqpx3L/FeLHuKciuF343K30gNl7KsQBbXkywVfRCGW+tb LqmZH756dVitVlE5JFIeHx4ow82XBxDgRWf7ZG2xRohM3BJ3vliD66bx/uTa+LWrt/ae7E/f/BhY GBZ5paOI6rcIj5uc4QD9JKfZyiRGd01Pr61N1yDXiA2dC1kcBESYe8cYicmxiqkszlqpVPSRXPGz i9MoQREWObASFAHK3uLkJ4ODY7Ncc6Is8uuJ7uMxjIsEmYwxXS8ehEvk1bDP6gZgkAUX0k1yB/Ak S7hUZs3Rrs8BD4TEDM18o8GmE+BD48TwKXKVIpmIVsflUQ1k9W3wwNif1Y2ttuAC/mMFM+DEiqy0 OYKUKz3vbW505hiS3emNX4Ut6I+dP9d1tWJSniAH2Xy03FyebzYbX9+58/Xo1zMWgp7Ho6/vYij+ nT/NLK1plLeztNhcmvnNb+52q7Us2itwcIXwd/6kNfN49qexQiynNsQ+4cOoL4gChh2Xd6AJEzqG 8E2klWxgg+Us0KsEEijgSB5502a5govsAla+b7k/vDGW16iwAwgucd+iYoAEUTCcipr/CHzlkIic SvoaLcZwUn4nlaI/KecEIH5BgCTw8cXByCN5i2g1HZJXFO4QkZUCQDiPXvBVKtVpPlLY1iAPEN4F QGZt03u9Ah6p1WjMeQOBzCK+tH3NZjyM1yvlumgv7dVF3SECtaSfWR2PurYmDoRL6HXfnG4xZV6/ Msmhd+jkGuMuhwkhlUE2BE9oNh9irLbH5lyOTLMyLfEilFiTlolHhp5hLUSBiQYdroLo1rUxoxfD yOxkzUQVN9CJ+pLLGz/6fFRBAjLB8TXwMgPzImIKfX4ACNBym8kTbQGeR+BrHqPskDiZG13u2+EG Z47F2tlttYVJFjY4x1pk10p7rSX0sbWxsPk7bAxpo9Ad+uqphXEVHvAgGsUy//FUy6/2V9ZEqc09 Egci/z0zWA0toECH1yMkDrHFjuUmd+42LYZFldW8g6hVWM2o5SYhUiyUZZHff/q/KzE0SOWULXpB ovFf++yHpIrx55nrAToBs4Ez8FmXYORHfyEbmM1QPRWozsqy0h14oiZjuiRQj8Kn8oYArl0bEwPi J+Yno7i0fd+HlIJ+gqzyCZC8T+Aoh/ixGK7+VDKficHOp4gVsIpwSglu3gcYwDDlEqppinDv+A05 J7UpHhHjMu1KajwFgAyjh1exUVgsiMqq3RJyEMRU0P13U7vW5XxrDeVAs5jwoGNQxodv/vaq0se1 8U+Q1pDfXazqfhM5VqdXq1yHXTCMVHUv4wAnRwiTjI9P6DyviQHx7YNoXJFHCBhggtf4J5Xq9gMu h1EWuY/uiIPtmmqssYkJhxJkSCpECNKIlF3yAzh2VkdOyINZgkSl1WTtc93H1ZxDJFiTiNw8f1sw wtIVPtaSR1qS21osPKl2HUMkBDe3eTc/p+UpfTuwIC2qLDCJwKLVXltqW9nJEpLpHEKKY2N+fml1 B/lzjkd0nGEgcclBbqxF/ApLb1dXmzPzza/nm0IZ+EfFfsCIfE2kfD1zx+YYcX0oQSL3d/6739y1 TKJOzAvx8ScGt5ASYZ5EAPJPg6hJj2WMD/CFYtuCPiOXCFCQTxzKxjI5tOQCINpGRehoRJi0EGSd ly8w3Z7zgST+TsCaXqWdLOO3FsR1sVxNMSq5ZIOoeBFPLn/k8CN+1DeJ5SfJB1E5CXhgQMo+qmDk X0nhKAcouU+CTPKBQghXumi0FCxIqlzCC0I8EXLOMAACq1NmTr4UqYuTT6mnR/3jAARVcVaMQ1VE 1my9LgwyWx+/Ns5mKgXE1Y9vLj5++mD2as/xcS8+5JO6Kn9gemmax97KNGbQo7EFw+04iJg7sgdc v29F/gHb2jg+wdzKAKNpA5MEEP377PYDrk/6ThMj95kXqclVPzk7qBRSUdOO/YwIAPOhEseYVteD TljjIlc4VtXVlEOwX5vbTPUZgaFVKiq9ZlAxD/NuCUeCA8GtGeKiKewDpIgpgGYbnUGpyQYMSEuz 6cwbLq21MGax3Vpdam/eW1jY2uS+qc2FuTud/UPgwypMnK466MEHtp3v78s3m0xWVzqPYEFAWl/P YTwFQDKniUOs4+LEljtzNOmrS0tIwSyj1AqFjOCPmbtmRrCj0eoXNaClweBPioBBwHlXqqsEEaJP IjrUPeAr6rfZ/qRySFMcauQLakRyNOMFpAW1Hx2QAJiy+ssMfQEO8o6ylTqSYIJkMrBKE1KHz6iA T2XFU9mPUF1FyRklIZRkgi+X8ZqSylDGI0T8QGwLUORH8oARCQaQCcoQWGWYdWTfk+Qk0W1J1IwR E6h7HJefD8DTI3OSKs6CODgtGyO2bmlyb9wlQK4aa1z94vHjX38MsHQPVKqg9n1sdnZW1/tMT6+s YkTUdLVIgcV2eV3hyAb7AWxDYQJ+XLyMrpcbmEBPF+asYNgKo8DIuSOjOLu9J0LrMUjkviqtA7LI IEu8MIpb0KJEgml4k4OfVLiKcdLt0IKx/zVNii1yFC74vMYMyOjoopGKxrY0skVM6EJHlHGNcdjw pI6MAGKAELPuIrLmeIjEEn0FeLQ4WFGuTtj19qrm0kVirex+tbDFmndgpLG8ovzxNKxRtC9DBxlk H/yx3yIFrax0Zu6KBQEiBSPzmrb82pXkL8+QJGa+XtJxEau4de78CaPAVGGRQn5mYkvBotHeO9ZK NcYNnurVSR4IuGZYZEszblkKfvZnbigPZB1/0GMoa6jTD6y5BHMVEfbKKFyygUNDAED5eZdGZzVK 2TKHuPR9KCr5+AdrkDOS0TyBECVn0I6rGZEf4jX+LCbAZagrJb9KNVaGkReIREsknhLIR4y9PIsw +V4qM2o8jHeWWOs4DpWFMhY8YwqyXIMpl0/8xWqhVoVfgOS6JZ/wHGfFwQ4kjL2nXziwGEoUQxNC OZOznMsIbbXyYPXBdK7oBk5w9GOxWtM1cxjCgq2l6E9htlGHpgpuBvFsAN2PE2w5GSCNTNSm9x7T rn9HkKAIZW97VtgCjqUyxgJkjIsYE1KZHB0bn5iEWx+b1B5GDXmNWRIRZh1IqHLTPHZph8Jrkh0m o6Ma42KlI3GCZDzrVgCcGbUpmLPC7PsoIlr06gBIC5n09koHNe7gkY2t1mp7Zamz2mphUQimmmyC RTa3WhtPnhzCZTiHbjmQEB2hwNpBc4n2mizfbc6LB1mGwFIOIUwweVVk1iMOk2SuEAWSKGJZmvnZ zKM73Sl5vXbkTii5fqPm5Gd3ajkUleAS17lwIppETGX9AgkjG1PoCAbKIrIyYcArpzZcu2XBO1ne ozS9ACxkMkE0iFE8sTKRDiMbhIXy5mPy8r6yH3igDF7sXj4aFZsRjYgBgUryy4IYPpCfRwUFCGsh riUXPuO/KAADbUShw1L4pRQCX/JGZ1ssRowzUoYIdsGwkEQAFPKJJkGADNY/yg9SJbEO/PDPLS5W F+WjfhbWekLwgWp4yxICIEsv7cn5tzaOkWe481sT9DCLAhAIrFVx59PcoV0rKmtUyhiiitmoGAVZ R+4QBcX1yuDw8GClpmsfBkAa8CK30KmCPPsAO+AHJ4qLe5zGCbd+X1lkT1hkUKeowoGgpKtifkRe 5gyJsYnxidCt2KGYMh8ChKgzUeYgOhQuLhPPnKOCRHsYbzNjMqq0gcTInCZF5vtgylsbqFHsIPGB wVgLOxwkt4a6k/YGxjbsbm5tMaP+5FiC0Ax6l0DY/0F/zlkQ6DBZWWk+QpB3Gf/g1wwPCFzmOcFb zQjM+kyH44aURJaaOsceM1cfIZ/YHeftFNbP7lheRHTWRI6boHPmOQoZNeUcrJjpBq3oH/BJHeSA n1wsa2mOrOkwVWIFmA6Y80xG/bcJtKBAv274IDTozmM3YpRYoAzRUH4AJpCHcvgETR7Kil958AuB QSgph8iVLqoqCMSXpBLyJIq35GFaovhhBA/UzKtJB5vIkxK8TIm+BUalKKyRZHYdGXrxJ6l6Us4F bFRYnK5uV7fFqNe+QA1WTXzBrUGMRQwRcnX76Us1RyGGkqtILE6IQBN4qDdf2ZvOcbp3XXcBKYsU CpVihHMiiwaPcfQAj98cZsH8wAAz/UiMCJPcGgRGoLoGdEZEZXpPc4f3v1Op9d33ezVc7QMTGKU6 ODk2YI5dMQWXX7EalgklGjP1Nj8YVWDgjxo9iVuj7VQWfcltp7ycNptD3HhSR9aNNnVgBHACxdXo 0wiWfGEubwutIK0NnbS41mZ6BMN5F3SC3M4TDg8NEYIOkK77eAx4QF89fLiPnekbrBBe2VmdX0am UC06z/ONOZbg4/GjGfmaedRcXUGSflV5BN7kLhqryB9usj0e/SlkEnZVAS+/xvBpK9bNufCufIE+ HFWAG3JCAugJCTK5mBwhbnJZa/8jj8Qs7sUGj5yCI+8H7om6cwthsSN3SPy1XOKgjGhE3kiOkCeM XvE7kNeFLORJyvei5kWSUQWRAEWISm7RFOGRRMG9iTGAI3AZlJJlTWAwmJHPixYjWuQnZfw0xXeB QwRIEXaY5PYEIgITUVmFxUVs9ZEP+4lfCz4Gw0iWUMitB08f33IAufpbvnxtluRBcKytCX18mOPW 35pmSjh8u4xxknWMwAM+MJRoHE3DGCRRGh6+hpV0XOEgCBkoaUdwnVprUHTYBEzJYB0zOZFd/04x Im59b3tSs/KD/GKFl+7S4hD7CRc0HjTq0EYteBHGf0dHMQYSEJmjZ2eapEbXbu5kbHTSUYqLDt+e DEWWQoPfTQUI5l9hxVQbhYp06ngklyrv25tW7765e/h0//CpZkBCjfV916GjP0rI48nD/SWkG1c2 7OhgLvGcyiswB0bnOaigNosd9YzxkkaW2mtzf9IB9xzWzbpetN9iWcpyFy3hge2aBIhGseSznpOn GebN9lII5pLcyKLXvPfV4FhwWF+x0K3AiF3nrE/Mygc9inKJDdeXmIwBIFFP9ZPve/Kxn4S8kkPE ViSpD4US8C1AISqi0FqgHD5ICqwCegxDDd7iq+ZKBnmNBdOsAB1GJj7MSlL1lkouKK1oEoZkOKVE k0rV5fre5jWOMxKGCGRN3Lqli20NIh9f23vp6d61ECEmsmDOF5n6EPfx4XRVOQNzIIEUPBAHUiCf FDTSK9AYLw0M3JKXBoaFQ0AqwwhpDWCexGCJPfPjcq4jbygwEcIZKIpdF4gcKIvQre8VxjS9SKBM aORL23vHmU1R/hjUeRHGIbr4Afcs6YLSoiUhk5A9FuFOemw7ITPJaPAYfTrCV02z58RKs9G3sLWz g43orFgUF7LQAoe05DJtw4+sNtcY4V3Y+NXu/pNDEkgor7oPCJp9EMiTh0/21+aFjcT8rwjuMDd+ ea7RpAcxXYeYFk5q1O9yKsv82uoSd+g2l9ZWm3/6kw4gXn6k4dy7Gs1CsxfCVxrotWzJb24XhjhS MWfeW4RVLDOU0aBuLJdzOREwiqguEgtjXpoNDAqxEBYxfuWYRNe/FVOmsLITl1GE9FLVFPVisTzF FS583zd1FaHniES9KPgAUa0o3qzXPo088YTnAouAWEjAk3uBD2klroZcQ6iYdRF9hbeVEfUV/4K6 eVKJZeOjWsNCuIhzV6dSMALgscik92xFS24/sVAWTMjiSy99X/+HcGCpnmct8bG3emNnZZrjJgpu ujD3ncg5ZwBhd3C9fqvElsaBIir0K9wfPz5eKaLhhP3B44N1sfD1umisen2AkyYECOJFWJVxcN8Q Il5kcVCr7rn4xJmWCkuFBycsTz9h1fUsJRb5JRf64C2u+UH2RnMjlFt8sAh04PkszLwr2VIGAauM 2qRHXUo7Z569bwHTEzeR897YXWm3FnY5twFDGxDcQuAV9Vi74kMeUmB15ZXqK+v+UHfO/ODD1eVG p7V7T8CxsAseacN2sGJxDpWL88jCECdzCpBHwiJIhXQ66tKXltaW/3QHG1MeLTMIzImRM9zeSCJh M7sChJKrhoJa1iViLK+wBBxJLjOUY1wL9Ywsv4qxxzBjvsQYxmBiZ+Iox5wiMKDTUQLHKZoqMZzg 6g4CLxmNQV9F83QbyhERRYtc0j4ufUZ/BTIeTmQUjxChp/fJILzyNRIsfzOaSkRhS0gbwkEJhYjo JhcZA0xEttG3+8BNScGR1IQk3lLCLVWeFpG1uofrHHumhUC0zRxl5OOOQj6+euvgpZe2b35s80qv 6vaEa1UUXom6Wl3F/ocyRnpxTpEO+yrq3jmsjq9Vc7Uy1mwVEbJChrJSF+ZA3GxgeLiEEG8FkBgf 1JYVuSOZAAAIdA0Wtx88fukQE9XuayEjYr4VphjF09cnKvXBCa1Zoa5ioMvEF84u8FUZu9XNNLIy GIl2zZNgo8rn1VGDzWivMzGp1VSVNSoA0QIuOc33wWBsLEBgyaUsBLKw2iFAWsyOLHVEc/0OQayt XQZ4nx6GVSYHjy0H8tgGt2O46MMnT1Yazc7axj0AZGcDf2tl/u5yo9lozqusapI/GqQQmnb4kLt3 mmz07YhJn2uudu5iLNYdJBIfcZyq2PXlZd3/cDcsZjTj/rPbHLvOi1/Uk/iMmHYQxpRX5D4GvJBI 8IRQyOWGcrzwtU/Q1BX4Q/1JXu251msxwKtpefR+KF/IZY7Pex9jc2BNPIVGMoqQFpgjqXLKj/kp souHkzJIVB/KG8rkESoq8ITQkudRankeEAazLpd7AgCiWydG5EX80wYQV0qfSpoTUQtDyNWmjT7E rk8XZlnZi7peTH0jgxAhN7e/f+nxtiMPl2avMW3+YPVGLl8HQLCERYcO69AJhUshVwOB1AfpTUp1 mhBUFJdg3euY3YUGSWxBwVQWNAWzT3iCmfc6uulFbCGidRgm10Ej97dZA8l6Fa2nH+BjmBooqgpx oja9MnY8qqWyq2LWhIZEBNdoddTYBJDRcPBomC6Rnxo+Ri3shXMf8ueChfbqahu42NH2wpa2Fsr1 KgDhoik0gBAEzoAc8GYBXmYOMcDk4cOVTqfR6Gzc293hrPidhY2VjqCiodlCU1d6A7PML2tX8J05 7YNfw5q3tVVQyMxdt6iR47rne9bQaebQ/Pqdu9UhBrKQ5wB13BCNFOuakhw1FyRXjg+hu2KZGBFi 5iTI9pSp5GKBOn1Mfu+qLS1vRMjJ16s7gGYiG+Au8AJe6aquPKTKhS54pYsBV1Oi77Z0CWNcKs6S UfUkEErJaN4TzEFF4Q9a0ItXPt4QpRqTXwjy+gu+xYSThEfCMiwllV5i56tykXM96HZOQ71qQyY4 cXrcZdS/ePzSSwe3nMKyF2en927sfbg6XUURcQkEgYGq9TK2p2ChVr5c58wvXThfZ4KkXMGU+gGM iKwUSwPwIHXGt+oY6lXHwlJhGbHyg6XKAPPumAwpHJMSFsHVdXBfD3HrNxYrgyztqnCcKviEKcga qoZrFWowWpWBblCrG+DSCRIIEFcUFdW5Wm2uNqa+RHTW4mQPQgCHKjFSnRsNa4MJkN2FhRZM9cam fOgj9NRBUKuNnvQ1LITm6NEd8d/7xh7dJEhvePdQ5zOsdDD5vdHa3V3YWVlbkvvWart5d74BDhGJ 1elgI0pDcNJg8pChLO7FhsBabWtd71rz7p8osHS7FlZlG1zuuJ2moVOXu8mMBnpznIRIESXnoUzM Ktt15ruABgRiUd5c18DrO9h3GLOirS5wYsw0atYENEGEMGMeILbrkUT00GQI3bqYbqEAvf75FkFM UlCUVwYxG68AocGA84h6cefe9donuch1LpyScs5dgAHeKAe+YaGc1JykkFEiaeFjehJ9UM7trZnE mi6w5KQyO4b+EMgsM+qisb7//oUXkAwBOBxCxqY/RHCXS+boPMplHSys6oobtTBVuFC2pVoUXwOc fodpLIOQWcIdeIKmrhKqhTmaBQ5EHpaEVwZtQTaE1rQVoBhEkBahSWHlo61snEAnYwVJ9vGKVXxR YE2oHhu02BaAIYDBchNuOBlDSfxktWZ8Iicjk9HaaJhebypCNPA1OoMQsABEnDQIY621+3/c222x O53+Y6O9tEZiQakiCGSfORAa8gOnrYxAHh/CwXM+XGNJJNZSe0PAtrq0trO7i5LeGbElDSTRAZC7 X883dCSRhXqXadhZsYjp8thC0ln+zR2M8np0mwu3uBfF0OJSJM6NoPGqoPTAvEcm5xxHBgihJ0cc OMbI1nXNt0NKcZAcZFWGwkrfFusaktDGZ2NGJ7jUqbC6oCATkAYCd8WTNfCYr8BNCL3E8OmvHOOp BZE7eVAmjKIREVQIhvGyhv6C8dD0ibj4vPwQz6IJ+RuegggYTCXk/eWkK2TRCHNSQQUuYioxLxRi EFnUopMaxlFzpJW13F79+Jr4yRe+/0LElqorxno/mX7wYDqjw1m4DQUDwtw0el1hWshVRV7pIt8y f1CPyOUfwZS7SF3suM0WLorqEmCwbaVOeqHiglHnQ+qswXph78Hh08ffhzrru4Pt2QGEuypWLixU U5lkKeQA9RfoQ6Ndg5Uw9gs0YaciNZgChH5EmaTmSrfUwFdp3FHyJdyhKqs5aQwiNr2vJZfwBuYo dtYW7t1bWEEIS/PpCzvtNVQurm397p5Yi8N9HfDz+LAHG85/sDtqHwMaBB9LIrI63KqwtrK7i6zj 2vwMA1lfEwq3ZwAPEVdYHyRk8oibTefnIa+AyDX0LS7/DFFdhrFm4OKXH9lI4dtagML4L58AOpM5 aiuc1YRTYKnsIrfQfcjPYxm15znzIjmVWjGoLvmG6Ioh9x5TcCiUYppAF4klVzPKSOSSB4OojrLo lXKIISSvdALTkcdAKQ9BqSgox94q/iIWU37BbBGTWwRXgtZF1RWRl4qLXxdoRC19GDXiiTISnNQS liikFn8pgWhvQhMtAEgijyoqQESu5enqbB296bMisnS5xzWtdBcT8v0LB18cE1k3l6YzBfaKlUvl rI49Krj5LUXdTZ8DPso2pJvWvQgUlIv1EppXihhYX8d2IKBjAAKMPFKPEB51JhfBLyhLweSv2vQD ehElEUHK3nYRUKgzX1+scKSE1rEwv1Jhl1aFoEBeBc/tVTDIoD6qsNeRu7ImUd1lJDJa09IUwANt vKKuRHLxjNAwJmr3baBcty2f3CsdzOBF+nuhxVJetIiIL+nMtTYfwqA/3Vd3bgqr14GINdl/8vDp k0NBxhJmOmCnIaq7NnY4mG6lAbcxx/wHqniRCXHjuubmrTALGgvwaAtWsTf9Z5jiBWeODUFUWNzV +Eg3AD/Stb8kmEdKIRn1GRlFiZNQcOgQVVnYdKIop+Ykp15Eg1vgG76rR2AZt5A9oJKYAfHkKo+I zMpDa8nHtwcHkdTAlMebOhGPPJFXuoil8eHu0b44GAVDsWjSi3l4B/BjikzxoTgyoCT8tLBLMmrR YZ8E4oE/5AE4ROu+VIOZ2mIIDeEu+cWEhrJW1qYXt6dzzKbPUshjJaEz6tcOXvr+e7Eh3WSIAKSQ wwr6fJAtAwMFUojtfHAL5bFmDt3zunZO18gXU8MVYZIySATgqJQpurBOHsqqNI7XBxjrqkSKdUET KlIwdrsk9qS69wBR0u+cFznYzs4W6USQbxxk+YpiRPfI04cMTDg3P8AoFzOMFc3JV8ZqY2ATlnZh nBfBIThBnmSupp5EC+VHzYtYHLgKibWzubslxnpVsxaABhxIGw9araXVnY0lTFDc1/CVBbAOuzZE XxZsYH77arOBFbgdAUinzSrhFQWb2PS55jxdB8HwNeoVhTUay48wPKIxLyZjXkDVQrVie1X++QZo QiF099GMrjAVlDxaVv+BMt+7d27PkEoEI5Ogi2mFiGVAFAz60hBgIZ5ELviMIoE2BKgQ3LA4ZUhw 4iK/se45RoUEXQVs8CEufFzrgYGmq7bABr5dynLh5/00XhAYiE1PADM0LFGCJ3bZE700RDAEaS9q AS7KM/X2XmjhvZB5oi4Pr+9RokhaGFglFl4sq48RIqFxyWdWp9Wr067Th9RmJ27paijlkC9eeEFs yHa3aPG3V8d1YB7ypJh2V2RjAAYpoZIHkzJyOa70regaLdIHEiL5gRLmGJXrnGuEmUTizlFmHKkL HkpMtvNWj0QQx4pUysiJwNrDwtQdi4Re5EZN0VAf6LIH0DUB4UXCwGkQ0yZoWVCtMmjyy6wLKKRi OIH0qmhxoyABdCKupqZJktHaHJSW5diro30rrZ0FAYRcxiKqWmgpXGEMa3Wpg8L3JRQsHjLCexgC xO4O9BH11T734zQb8B9LghJBysaGDqRjVe/8cpMlWFqmyBXxc2LcG5hZL5ZE7u8uz3UEGvhGPGt1 Xq5/Tkq96/YB6USvu7ZAnkyCjl3a9dvqQJjzsMPoRN25hbEQBb5uEJFXRE1BY1FYMYGYy1pmkdiA J/dtiSHjuYGXVyOCh4zvEjOCHfnoxlvynhWVMNIbpajKR0VlgSwgsjzyhyccFAuovZAZjFJmIUgM UBgwohRoHoO9Ub6V4NHIcdI0lcJDZVlCq3/VxchvIgOpCcYU0yHCINUcA1qLAMgk5jZgN5QC5ONb 91/6/rsXvtu+Gfr0mxGfJZ7Zcljej8foI+AXCt/KmGvHnUE0Jjo1EmQCHwL+4LYTQQcEVolSC/O5 6+LN63wRaKmXeeEz/CW/NzB+q0AWOTgI3fp2jT6Fsx5ha0rGH6QhxJW7wmvM+rbo3gc5H1Ub5Sfc z9WaVNAJNgrwKH2ASmBI5NSsqXVHmFf9+MJGu7PaWthdYVwXoFilH8D3yqGDhzLHQTeOdXC4j9AW 4lf7T8Wgc6tnB+joNFw6FnMAACAASURBVJsttroDJautlea/zYNBsNeQ0V0YERDKsngLTNfmxh/u Sxd8YE2ouBDwhHAMMyDQVvJepkzcTuwZw4oA6e7tas58ei6rPgTYyGliJJfTTTjqwkEZ6J3KXOfz ocx19iRmHDKGMi6zHtjhiaBSsMiFohjxFCwWCPYCBno1Dw6wyGe+QEQA4mlAmNd7SAVyVceGYlRh wiFpvMGLhrkVko8fmnloLLwuSHERAKegohoCFm5KJqJMH0bNfWhWhTUwfK+orNUH09OLSiFMhtRm NRf9icunbwuFfC8IUQ6B6uIMJL/guvq5F8iWbWEHMGGDKasFqKsS0oji1pkoSQ6wY0tO6I8vJcvs AsaAeqAGhEJSgQmR35HLHWsbhWrkaoeFGagXCRFHImwW0dVBNRZFVsg49Or67KcO1BCbOdEo2IT5 FRf5GhClRbwgLKaGhPpKQ1s1ptn7EOHd2NhdWFlrb+ws7Ii6WdHiXozFwr6Q1Z0nlgA5Ht5VByLc cWgB3v3VRnMJFNJZanQEJatkImRZQo0l6IA7h1O/I7wB44HmdB1Gf/fuHAb/rrUBMkGIUAgGb4tB /zfuXkS+8C7y7nfDTfFu7a/ILLXpuYKRB4NUlFc0GznFh/l2Zg6JB1AK2SWmDBI6kEBHMvDAne/0 FZIUIjMEHaQPOccCn8oKkkueki5woQeBuvQgquQTxVXsQCACiyVZsaEhL+oAoc5FscbHNCj6I09D YxrzirqSLufnSTKaJcE/E02wrCuV8gJ1KBrLQrVJdbuq/YUY4lAhi1y79k9onvriO1DIC999cfNj Nek3yz3F/QoSmxsmVJnL+aUyB9Xni772/BbNriO+ZVOItGgyUk6K3BpI1a3VMaKswqNCnERw7QMp ZVBMJTIwWKpv71FohVmR7YJNs2MVfV09SL1uaos40Yn3hgqHGwsRO7cyRoDA6uM0pm/V4O8kXMmo dpSoyqqNYuzP1s7C5sZaG0vRW6skFGYKoYw22qtWwnv4o+yHxXyZAAFCVuW6JnUIOpbEinSEP3Za WpS1gZLeBlRWE44De69Fc4nMEnE183W40AQzFlflT3DRtNj0RmeesSw0jdCTcPMiz3eXNfZ7m6Vc gpDFMBNoJsT0FZ0F9qjx55ob7CYRkW/PIBacG9LfibGG3eEicLAQUAgmYvwBLvy8p86EYd8opZUD jFNfeBBEme7zY6hHSZq79ngI3SRSHvHBWhVaE002MveoCHFpSMYCRGB5aabZHUwSJCtUxKf8WDRl FgQn8Ty+eJwglfL9BGJggaisNebT5bYolxkohKFRxyHbwiCCkIOweWrcZ3Wm6w3LcqRqoDU44kJS JTdzlUMxmC7J06uUgYtxUXblSLmeKtXREixMESnzcR0gAU1EBuplAkV4JFJC+ItiqY4gcCnFKsau FXEQqbCSGPFhF8eqsB++AtmmlcRuSbCBwh5M6tQVVV+DCgz0yut8CcSAnQ+ZZM08M+4CkJYQx+7u RmdlYXNBLs7WFkecuO7b1ZV9E1hdZx7Gssy3P+Gx02w2liCNGhhuDZCwWH5Hh6asNObhQQQQBAkC vEIOyxBXM7YcSw4MpmtjckN7RWho5t/kp3dmUIrCTIilP5ZVX2Gjwx23pVEejU5nxKWrEdF4rzy4 ceNGxvRVhkFeRreyihrEcG8IbyDMa4EuRHW1cdBxRz6EQaBpdE2FgEfwcozXtIkh7moCOAL9gpNP IrMXxIYuxzz14+rz1YSnommGsSwEZmxguCCzkEOiftqzQkd5JRGmWqLR0K0jiSLvidOTJEyFJZA0 SapXTyTyubW9NfSG0KfPumCvRXtvXv34GhHy3Qv3v3BRrJLvZnlj7GQODQN5zZhmcnnkIHXQcQSd l0FWh9rDtmMvRIl9jQKM1Dj75ZNlhH5TJSOXSNn2BpFLiogK1yNKIIh1VSLFgeESIPLYxXzFIO1t FwewXwuzUcW4FCO84tWXCDLqAxP1CYtsaazr+WPCWRGd3qUVkGh0xB5G4ZOamBCBCCqANac4qmN/ FhZacCALbbkyN/ip39JJ1h0lkKdPnx7+iELUl6B/EPyxS+dA84DPfzk12vKXNcqLv7SsyXS5dURb NeaWGw1NETJL+LWu/VljSyFGAIsHmrsrZPMIy+TuPlJR9YgAQU0WVNldTJ57BAZBQn2mCoYQG5oz c84TAUJOcYKLP41ZPNheYtGWgANVWMYSipJY1oCSN3XVPbwuy2hWULnD/YSFWh7y51GPOoqHIsdT ZmE9SToG9023jj/hrDlpg9c8Hnr06lq75UJZniuMV+BYelHtidUJJ33qOMNLIh8WnVSrBRT2Yola 5dY4Y1lIEH7xnSJEVJY13kZiGE+Pwkj5/0OILq8lapjjLfjg2DGOyivY4FXuREkytYjaYo6648DH OiCBZVplFV36OjWXvFYq07kXiyVc2ayjFyeCnHxx+uCQXuRAQ757BXp0wUlEaAYVLsUisymab6xX SCB8i4KkZkCp2bfZE+wCxh0LvAQjyCU6286KrdqoVmspgwgo2hsLOxvokhXHDheCq3ultcYedObJ 6UEOn8cHVuRgg9STDYIC5gEHZFYHAeOdLdutsCqgaMKFACPMgzQ6Ta5naLB9CssVl+eXsKUdfwV1 Ls1Hd9WdPNKp9NxwcnfGLSEFn+grTBreHgU88JXpRUhGUyDGI45faN4R2EJZPOwHsobMFcZc2hyT e4NsLNuFhNNc0EteoDoMKwRYoS6XMKQZUELPEtUyRnzKCz5idi1TemneA2Qg2igGaknSpcurcRRu RU2BGYWQa4AQfkN5KSSc38cR94x+8G6ILBTLpxIOP0RMIpqb3rOyxSor30EjYxO3bPOmgGIbNsRU FmVWKYZpRqwW0BZjFnb6ybIH2GQy9B7QW8Wkm2pMzgGXYAQLp0sAJ8VysoR+4ZJ1zBtwdBS9QgdB YdFcRVz3RbEjiA4LajQtojTC1HqhNoC3FSuRSlGRMFDB9oc6kynwJQAHTxU7FbscEg4k4sTH8brV Q44VGQF2GfYxIgVP+hbEICywYHFja6WNFIQ8hbveYfwJ2fEwAxIi5LCHQFDg/vDJjvwuPIjQiMax 5DHs/47jonYT1SYswILIguASCkHQt4EG3CaHz880sP6wg+E/YJE5zYRgZ+8jRLCEOzDwmjfm0TWz Lk+REZlUeBRy09NsoAJAbjjaOHZ0U4oZJgpNWzmDHrM5JrGsk1s9KBFYZIdimG0Ccz4UUxTAgIhd jzEpgoSgKi82QgXAB3OGvNYDXuew/Z4ootiQgCqaCNI+f6R2g+YDDOILv6jm8r20AifuDIhnfBG+ EPXjBA8jwXHHLtaVFWcwLAORpRBZXETR4qQYkUGtOcEkoPFtMenf0alfoxG5hs0mAAd6iXVYcTaW x0SWfIzdZ8hGlrNuzSkC4tgGwWAXK+7VofNIlotcLpfkANUSx3gZQkrgEGED3Mmr8CmMBZehwsqF vQco4vgurM8qVNBxwt4tkAUAJVd5BGuEBkgh+gIa8CvcLQTGqdW05AtP8R6k5AcmNI0yYMHhyYFJ ptmhtiZJJGN9WxsoV9za2MJkE8EHekIWUJGFWQ4tjA+1OT89DkQdCZsLWWHy8OHOWnsLZYri0JuN ppGIkFCLc02ZDOnMi0tvACBNYIK1WHNac9IwHpl5NCewUBqC2GrMkELYlYudJnL3SCt773KJA0O8 t2fuAB+3QSFVYCQznSkUMpnpEAuqtTLPHcidI3+oycFYNtOTQg9UaREy1irVVVd40TMFFkOuhCTC OJdV+qKDFkwgDkUBEk2y2sTXNyLOZboquDxEMYayE+UHsx4eEyaiztJeXPFihOLIA3CwRCIxQcYR C098OMfih4+osRJ+ZhW9IZYuFLkun5GzrmoRNuTW/Re+V4TYrMVxXRAUC2ycJDpkfCG8PBJHNzL5 FPc8cKirbo4IylifgoV24AxQiEBEb2UdbsczQCF4IGJSzCWW+R48KCGbCGREsJEuwqYWBLScFRGd VStzeUkxoo6EXVwMEg+oiy8auaCKuEZIVIoa+sIbmEwcGFcjP2CRX/UnA+pFILtAIZWxPqELcR9i Q3aQ/mhzfJy2qbdEfKH+kJFcYxArdj90HVIisB6CQMRwtFoCCjk6TmY1Ohs79PvyhzAyviGug20h epub/3qZD+BNljHLjmjhhtDOqqBktdNE7kMjXDry2hYtWqD37swjcMgMd/KIzjIKmSY7iF9n8btL rv/EwdJGnQwU0yL4boGiZtENJl2HfuzwYupXzHMEnpXt+gAOhRSwIAY9lkzqj+WldACjTluPX0uD NeQtwiAmu6ySMVAiiV0OPGWO0Jir/fDtTiglqV5FcSRqK0yV8C/QuHtRhpgT5WnXHDJdrYyPz4oP Qe0799Ii2Pux2BDdTPDC/VvopLqZDDCXRUg1BrWlXgz/A3OZoRsZtnwxjyr/JzGbqkskdAUdBtwl U5gMqYO3I4z7otkxVbfm+jKAkCRcxLQnzdnXy7TwdfRgCYwqA8n8MbcOnaWN8drjWCxG5N2iuSKV ejhNwjBS18SiqSx4eQt6oe/R8OLMyaSdxii6xuDRxvpwAWMmw9YCRphsIGfY0lbydmt3n0VW+0+7 EqtXXh3uq8B68nBnqbPCIqq5uUaHCFlrC0Lo0jcotMSqI34FDpFvRYg6Eb5EQmnSmKwRIWui0VaX lg0hKDhBnlAYRdMgMyw/uQ10YK2bxbKEQuSWmdZw73QGIMn8NDhc4jCXVfhAYOXCWveY1ixabS82 TMGPhBpLLxJILXuNGsS36JZAhPFgT9lkSBx6Mgm2AYBiCApDZsHAx9K8pIPLMYGNwCyuRSjkgECl VvoyKMTeqATiKXm4nInGveLKFXESSYLCK0FAqWPx2OEbGnVCpDh+q4LBvbNoNeIqhGv/RKNuEIHM +oer4xzLwv+Nnm5EQeQinx3K3BgKhlMCgjxDGzmFjk9NViaUsC4oif2k7E3BSCLCQ/f5gilAJ8mI cYotbKSNLwsd8PrH3i3xG0IleXaLHHR1VpHSitNUxK+LPotwDFExhIh5kDrJA4DB2yolbZGvlAbV pQwoKGphWFg+MwYmQrwQIEIf2LGGTqmN1paNWkRTIbDxdN+KFF2l4qFWvFsESwjkycP91cZKq9Nc EpZAKAsGRENZLYMHC+rXGnL5NxpLChEgA5CAEQFCSCUo6RVv3wZCABPRWGyrYtEiNu8sM1mI8b5o 071Li+78+8zynOAjU51GKCtTzdwQKqn+RXBYYQqcOrtyc1YYn2UrlcmtmKteZNutmhE4E7lEfMGH +AfFC6qz8irDQCdMlDOzmEQEK5aP0p/AdoAy1LAwZwI3ApbAVZ6O2VVPT5P2nbJSyxKj4JKLPxH1 TWQBN+rA5WX5T4iH1EGmSQAlBAzlFUJa0WQiB4TAiFQLX1Rqi+wvnMUONI5xuPnbECEvvPTd9i1B CHsemZgpR63WHx8PCBDmh1PR4eFoLDNELnXrh3SsXr6oYyWjZc7t0gMrijCBBTYkwm0OMPECFhoW eo9ynSu1UOPFaUaisKCoysnC3qG1HCKcdXCjUBwolwtIraPZt1J2yIi4oUSVcgS+HWn6gQhHSlSw P1vDwqXBgZoSjBj8inh0+BEwyRixMlGxjkUByJZgAnNL2sogHEey2tpot3eYH9cAb1diHbr8B2Jb 7EF/stJYam+1GoIQubzbIrQajPZCZJFDFjY4aUuIoxNSSNPsOjpxsci9aaMc5FdXVgm2JVFr84/I HvMgkBmlEeyyfvSILsTSIDx/jbUOVTEggo0ccTGtp+5daEOs4NeRCwJcatkptVimlYtZYh318XwU li7yGT5IcelrKFjbpzwnvSiy8ky+x6i2BEYAEyRWzFKIUW8oxuITQEaZQcNb1p4IWxFchif3FSUg EUFEojv5hO9KoB5R41bRuEZ0zapEzbF7atkToBeBFyYBrWLKCSb2VhfRnTc2i8peAuTm1Ztf3Hcq 64X7XwzfLLnmF6EGRB4wGxIMMjQkCiuB6dn834YgcJQrr+UER1/26UOS3I7i+uVLeT+CJpVSMo+x EpRYZBWCQgkGdxF0wKtnSZaKxTwWxUeKYkUIEY1nCYlElELkrYgI28BHBQoGBrNuRZQU5VYxotGt AboWYRK0AQ9UimGwa8BRCFLsfIzZqX1bW3AhGwu7Cyhu31LvgVmk7RVc/SxyP+yJ8RqFIO6LBlt8 7baFMTYW2s1GWzy+JkLamhFZ2WKiUAAi131nHvzRJEYaxASiWZg1D6BYEcpcE+4Da3o6iIot9xyP lplVv7vMre+YpgX+QKJx5vZtzOKemxP7CTDkqkTEtAFiOvNheO6lkBAfjHMxWYj7mE7AZnrkmHc3 Bx9jXhxhY4ULJdaxAwDxWNIu104MJkMpxQcTAEny0S8/w7Q4P+YZNrzAdY4I3Shi5D5O8w3MXfZp wuUiT2gWkJe/ACSBsisGevETAYL8EiAhaEL8l3+BaXgKL7+6JgApEB2FWnVylrHeiXFFCFXWfaey Xvju/hc3k0zuaO1yjG3w8GNDmSGdv5KIYoVdPpY3FEU5S1KfIZQFitDWRg5PxWYU5RSwhka3wCxF ZQ3M9OKrNOd11kIW8XIxWyhGCtMPDl2F1sH397ev1wqotMfFrz1bSh61SEm9iTAISATbU4qY8wh2 qUT4LlQO1wbqWtlVnGS1Pdik0gMV9LX3YWaDiKuFzV0ChdN/WhzWCwI57BYqdlUWBRY6CPcfQmA9 3OkIc4iHwdgeA8YqNZYARCDHhArm/bab8yKxILOAEpIHHmGXiUZ+5/lNC9NZW22jsXB+2VGIZttZ aDJPmfXILX63jVWjy/Oj1f4Pp/v7p6flK9OfUZD0Z0I++bFLz7gWkqxCRjt2EdvCy9k8q1KAkUws ZJEsd4IKgUB5aeLED457eA8uJEmAICnoXQZSPCtECXj9M3son/4xK8HyQ3Lx0jGxLQmwhhp3qq20 /BIS9/FoCpjoWnHQR5w+3IjCgYMCjHFh2hL59oRL4vnp6T0ABFNOmA7BCIdb47c0knXz5scfEyGq s17YvjqMKBucR1LEVJBirzz+11NTIcwrVCf/fyTLQBGKmBH34oHEoWmrpNkRI5NyySQXY1sR1gBD f0U4zisC+84h3WVdfSpGv84lKPncnmtcx1D4A0xCLduUFaETBMAEGvm6AaTIIXcRoRDMJopo7qRS wYNSSdBgoGK0q2JBrUpoTFC1Mta3iaBuu7WzeW+TM0hxMQMmKrAEIftaZWIkYjkR8eeCkCcPvxWE YFpQS76ENtotQUZbSaSNR23m6Vn3Lq7f0EGNRXNOk65Pw9gWHEyYj19qcrDDnFvtbq1V86hcVG1l DVd4NDo30+y/dOlDPfoz/Th/KLTRD3h82EscdrL+KUWKzWe0vkSk3HUKkBahZLPW3m4GPpbTqt8Y 84r5bmVvSCGwtRmmOZL+EP0KY8FUaQEYJEYdxbp3RL9w9UNGITqGcK1a+TiSi0BIMJIW4iE5JBIa wUJoKk5L7jNYFYdtp0NnwoRPElElHHXtjGbl0Hw7vY2yXk0Yom4Rk6ewaw059N9+sU2FRad+9WZK AKBT59HklUBnJMJ7mFxM4UVFiZ0n9CeCmTxJxDr3dekcmURXzunou6RmEct+xC/TmQAfeQS9CI4I 9zqWtHoF2+OTaEBhl9be4ZPDx8IgB/cxP6tQwgr5WkEHEZWIDLh8U1slWBFBUN3CwUzSV2oGHU2X aCoRt4hDx4CpLgHIPTQUyuW9cO+rexwfx2JFud9XA/LUkh4OH2EGHSW8334LAuGIOeGHTrsl4BBo tNsAC782UCLcWiHqVjDuZMkVnMgxpxhpNpRAhEvAISE+0HulKZL55XnXd6gL3pd1HCNxwbZELsIW gFx6XyBy6dL7goz+/g/f/7B7ZAiX/n4wSn8os3IZVyWfcz27ds5Z5S/AktUhvzE2sRvLoOaCDSUx TZuwAsMhxM9Dh8WIAmTV+SyWhg8hAMKQLkJYQR4vGkICWg1VW1rMa8n3tIdol0ascKULKMRzyF+g nkIY2IuaIxcCSdu7oiq6olZu4qFyPrA4L2xITdezcReH9qhz99rwF19s3ydGvvj4agm9kyzZD3Ix zB4GqOX6RZpUR1fkY9lylLX+MCKKGiz6LbNB2UK6sCLMjYAlygQJdzWCRTBeGESClpZSmSkUsAoZ RjikXhpQLoH3h856amW+3x3cDzA+opAv5IEKUEihjNquQhGhMjdAWCSWjZ1AYT2pxCBU0hr6SsV9 WRi4qNmRyb7NzYUWhl9t7d67t2ByCPhwBOIivD3Y2LcK9/0n3z789ttd+BWAYpWdgJBZ4kTkoM5a EXyw9JFl7w0UMTaMRFRZMYKllqQxT9HV0GIsVDwudSC6GhzvoDMeZviosXxXVRcVGFHCKUJzjf5L cnv/ovDIpf4PL/3yl7/sxUj3AFL6FSf9FgsOUZK17/CZK5jPhnOEEOrKR/KI8yqFsGCesd9uPhFJ cnzwutKUbowYr7BZBGAYipn1gOOwcixQhas38bqNU2nmRNRMqA9JRJnoiIusiqcJkHgiHk/A0Sfk AUCjkEkmxJnQgshfspKTKgb2sihrdmKyhu6Qa9cmxj7RMSc3r90CRrZvXb06LP+1Pjq+SI0jfsLH ThSMFI5pXY1Ft/ywt5Ltj5hsV5afuKFebumD0olSBkxYXqcL+0nO98Lcu4i6FL/o05WwPDhPi4JW 32QpLxAhi+D49P405g4VUGuvNCLQwBtLwyULZ+FnJAnxKsobSjHw6gNFewRvYpO2i0y9K7n0iTuX z33Bx+4u8bGjHn1n/+ETRHn31aQ/DinE8h+HT+k/vv32Id4twIDLIELaqq3QHAiwIOu4oMlCUEin E8JDPYjprE5j3r3W7PTUPK41mWOnl2dWXYPCYkLmeYLeotBq6GIFIqT1oeAD6urS++9/CDqRZ3L6 KawITIAVgKU/c4xNcq69pNADFwca6LG8aS6MzYpRb+nyZ85gjOEl2+Bm0S4CQ5FCCtERKcyYGEQC y49YCBhYEVaJWjQ4oQ9Ec3kJOnVBgnxr9YnIqxhOxEuCUoo+hYZd7Xs8zs4rxJgsFQKbDhLBqKzJ 2YlfT3zyya/HoLIAkY8FJLe+QGHvcH7I85MJ8R1ZzKtQKx4lLxIZNB/4dPA5P9LrmfiCRoCym7Hi hneFmx/y2fLwsG4JKvt0KzoDr2xTuJFzjHDFg9Z34XmBLFPYe7D/hNt3PhWttZeLlPLYo43kZJlE UizUhEhY+JKHjy+p6CorcUTE0otxZy8wHQgz8kg11gdc8dYABFdRPIh4D3EQHM+LnCFJRJ4/5Bzq /cN910wYaitnQVilKAILGXjMu25RWCk2jEFoQhZQTa+TrOlCmsYhigYHl+a8cyTzoB5ONkHOkT+Y m28aRGZAKA16EDPu8kwJBOGwuWY/JRZOH/ZfIlAMGTj9Lzi93wOUS8ew0m9QqWaqxxGSO4YR7SYp ZFWBuQEQiA0HNrdXAALIaM9hlm7eAUSjwQoUT0viqa18VwtshGKZdFz2dCi48s14ICiV0qL3OHOD wIDHmhRhmThIRAsYaUsMLuQZsJaYAs8VLW5jejv36lRmJyufjKPoBBTyySc3u3Pef3szGWPdTKBd lL72gvm+NcSgRjnoDkJilJshrLBbP5rQBULaAgyxxbmrZUwuGsYCB/T0MmlStimRel9OovVKPDvl lR/JJ+U+wuyIkIhcnEitf3r/+4ODQimCkRJFpFRAOEmSSVntCOYTlevFiGVKgBEUO0Yi9UqECUmB woDGh+VRRCu5Bqy/t+/eV59tbrTXF+4xiNVi1IkCC5N+nhAfjx2HdC06hpgAQk92W2rRVzEuqN0g RFY6IUjkieBjYYHB3lZrhTadMgtV71qbpcwxb75dTk1jkPYaOrBUhGmIiwYETxHNUnVFR4KirobO +22sAh/w6pcUH0Ig5A+Awe7s227ufT3iS72KfOX6HVgcSrJuMkoPsehMU6Tj87a/CoXCQzHbfJjB paVl9DFLjZjk4pAUzxq0tG03xnosjxt5GO91OXUdmgJ37o14qZQ2IKImhfBgNYrnnA0Y5gpaRxJ4 TBjFo4z3aq9idlpLsrg8BGul8Sk9Pjw8Pj589dq1q9cIEA4g5TrP5GU4ciop7U/pTmfp4QvCQWfn 6c8VJqg+caMlgJKyoiSqI5NABwE3nRISUWYM5dKOhiWOEagr7I8o+hwdAXVWLuWzGVT5atpQ/Po2 u4GLmkgp8hQhQJChF9HFTIt593qE87vQwGWCi8gZ0HotRYhz6uJBvvp2U0zIrsWwNrSwd5c5Qk5z 7yUQxQdnxFGCqUPnikP4fFAIyrna4SFXeWvBNpCg/4ro6KjS6jSavWqLSRGlEoTANNWI4keXc+co LXUkLpjFCDD6sHQSHYJgorGUP7r4eB+kAZC8r1zSCxG+7pCCX1WQvP8hQaJfQEo104sUrrIqGGYy +hIFGne9ZbngUPgkr+Y9xrr5mDPwMC0xkkmMGstCYBhtnedYFL3wsETHG4lF/ZGA3YU+xRVxgPrf JMHAyBWKeFlrIqYjjsJ5MkecSROm3sklxIjNzS7ojJPF6nQm6+UL1Vrl88+bn0/eHm2OiVEfvjnO Wt6bDiUphqbFe3i+tt1brX3PPBe+Jq4jZuThlBg2RnCOhc181OJ74CAiyOHUVAAJdKJZRQIEaPE1 wAVuEXzkOTiijPou0UxJ3S25zfmFcOsH929sC7ewXauoZwFEMY/RQ0Qa0/N1iwVznwm648sa1yJQ KnWwCRoaySCc1FUUk74Ll95ub7Gid4EUstVa2DeA7IcA6Zp1E1iwIE9QQ8Kudrn4W1stgwbnlhpC 2PLe0uLHlVanoQhRmLiUofKGNVSRXESdrTWEQFg2bxFg5ZGGtrJ3AULM6Mxf/q4BRI/3cXxopw/t 0YfvAxjvExo9a5TZCAAAIABJREFU2KBtUZDI7/HlfhCKiS8nwarVak6xgmGD2awz8gwQZzmAEB12 mSHbn8DuEgbAOOc30HR8GO6C2tJ+Rb87stFQ4jKIOvjaOqeiKqUY29X+XfEhvgWwBAppT/w4MaQ2 JhHV2HDUC8egRrNrqyg3uZ6/vra21t76/e+//MMfXnzx9y+++OIfvvzyvfWpxvygbQ65Ckcyzpxl NOV7NpQl7AM2aGhpJR7GAp1CrF362n4MIEE3JTiFyCatyGMOuI+WdcODW75FlGiNSjIq3FMG//hI wJOM8smktqBks+VUMrv3+AlzIlp7AhOvwS6IqqTxCZKOuIvUtX4Fycc8nXzZLAkqHYvcg1Uso+IR emsAU+7kvk9z56hxF3wsyDUuZ0cgDh6HLg/i9BXnxOG2q9yhwWF+C4W0GMXqtMAfqx0UeDEyxkbe Tg9Aul4kDGzNK0KQebSa4I4GshrMt88RIZYK0cCWaS7EiOeYfez0Gz5ADvL1PmBCZOgdOYXwcDAw ulFcEST6F/rxmiOSS0TIhyFOwCpVFkfmHDIImmyBO6hRt1LIs9wxb9sTgrxb+hZgqYIW/unyKlKI 6DEvgvkpChXGT1mU4jAT9eMujMvOD19rd3FtxuOETVybSrx0Oo2Gd82bXAGVxPErWpcv1JTb05LF pfbmi6++furUyZMnT584eUpOJ06flq9XXv3Dl1Nzd1jxfvO310rap4VyLl75goW4oiAs4vfMRdkY Fz9grtAbcpi3jfBcqaUkktShLFihBSBEscWBMyoxkxiwKet8scB3MS/hkwAbU7WUJYu2lNz0oRiR A+REDr7fu66jJfJF5h0x2bGkOk2e16m7VIUJPiLlkhsEyZxIBc2NcCB1syGlEkPBk324qrdYbLKl VSeCjx1c/OxFf45BLAGCPTkirx4+3AckLE8IcLRbPfLK0YkFsbb0LQ4bHVVZnYZLrlv9Cc8dw8cS vpgm6ebaLei7rNYDzrzBjSMGrv5Gs+3o41IIDhVaIUwADd4+VCTZ0R9+96uR6ddvnpVO+BzSrL97 VKvi65Ho5eZpMAv6UZgzKYS723VEvC47zGrAK2vb3DgjRVHCmkfPCRRn1kETeZ3iEGdhFQNaRITP e+0z9MAkrNkKtHU9rT9kt3scQyeY0ZQ/nRVw3Jhe2Xrx1VMn3zz15km5vXlavgQbApBnJ579zdGJ f/73P3z5w2+AkEGAIuGm4Wn42QdEPFeW7CZ4s3fMt42lvsa58PbAT6BTHhWTgo5y2eanYrCEH3AP ti0f4iziJKFSRkaFe7mixIeoLFFWed+YxE2QmFadRSdycF131hetoou2wy+rJyEwyooPbNNGPwpE Vl6L5SOlklAGiyXrSLeXi/rd1xJcbG2CRzDVBDSytYESErn1EMgxf45V6fvAx5MNNucqeWyh6YNs ooGsECobur5KbXq702h3GcRJrE4viziE9FAIDby6FHZXzdlyEdZxzWuoeA6/1y9/sz9UWMRFlztU cLmz4offzx3Eh/2RfgWLvaZIMRSRavQElEB7VQEP7meHB1F0QHTBs+QLtl+hoOsQuZTE7ZK2jdJM pWhnHnGStwQDp8vZ0CytQYzr2BMX+Y1a3a8CIkibI1eRlSQByF8aUcXjieLLTa/+/tWTp/Q4jZM8 OXlamOTkm6ePjk4/O/E3J46OvvmXj+av3hSgmWyyYfWei0ErMH0tFtN2FN+2QxDWjD6YZ0/Y1Hod ZU8awpgirVWRv1EGZMo9UyQ9rkPVupUoN8+XtdMdqXcfG75QUS/nB0+e2oi5g71sXkO9TMHzAY2I EQngUUIw2Fp+zdGj1hFz7MS3YCSRwGagXKzlkYaf7FvX9YOgj11s6tyV6xjsAI112KWQboB3Hw1U yiD7K05erZjEaq8LMFRitdmeqBSyFXZgtcAd7R6N1WE8q0dtASIdhYca9Y56E2YR8aVeZN7WuM0r MpyB6QdKjlPIpfd/2YOSLlT0PRd56+GQ/u59P++UQrrgIVYuOnYhVHrYhEgpVDFfJesgAaOCKbaW aKQM4xY4+UQUPslnw8XSWRshovoryGuwy8u7SVmuMMtg4kYI4QpNhw/T6YDZj7R6eAovX2PHLFtB reFI4cszp94UXPwtzidPvfmmyCyIrKPTghGByNHR3zyT48T/NZbQGSteTF0G/3nclVG7aA7JAlqh RTGzwi4YJ70S2viYsOkS8oaU0FLKTcyL6kzJsiOgPODC+fZMqfMVBIiZYGTGiamUIFnefvDgqbYb Ck6uCyNBUkVZo1IOwYHieUGYFX9BYGlRS7ksRIFZKppoh/ASdVV2SfhKX3trc2FBjPoutjxvofh9 QWO8whO9AutxD0SYA3nIHKHm3Tfa2EglCs3UVrvnQBxLSxbJUq1jAOn0UkgPSjqOQDggJbz8jUPm WJ1CdFhrybxjHkFIp9N/qR0iRL4uXnz/2IEXL12Uly9dvHjxOYTwmOJ3v576py4ZcUz1O+Vl5NL/ Y4AYSvoRBhNGUTdPgYVhhMIl/MpyeCeGP7NIAjelkFzW1kxzqHpe52VTZlF4h5eeNRDSlmieMdBq FfIHqSQaZ0VX3HjFZkloHUw+NrL4qiDjjNxOQWABGs/+XnByJALr9Mkj8SICkRMnnv35g2lTcB6r KuO+znDxtCF4xAK9VqkfZkh8G3KXDlyCR6vE1H5YD3Bcl6OI+ktqg7DbukWe9LuTJlliD4hwkqSf 1InIqGEuc4RE/gaLfBUinxaSSh5qRfIs9RJs+EW/WHblK3lW20fKWlRfZMW8KrASVwFVBCTYCgSA QFot7C5gjdTmLq7hXU5heNoTw+olkEOFB0K8u1b9u9FDIa1W27FK14wAdzQ6rc3NFvPsoQ9REnFI kfumAaRXY4VNJJo10dYq67ma19iwkk8HBNIJGQQwIFkIGvTufaDlon7LTy8ag3x08aNLuE3Z7dIU vwUaU/qon6/i3M8f494B5Ef4EGgIKs3PVzXulasWVH6pBLMj5/ChUClywQCNZpC3KSJyJWTVqWjX iS3psb71uCqrIJYeYT/iiOeHQisaMHeoWksTlDq4CPpkJPfqyZNnVGG9SR9y8sQJAcqJZ4IT8SGE yIm/P3r2wUo6bktRWJMILuNlGucLgQLDYKClx9rwqCiyVmTNdLp5XVqrr9Pr4932ee0k9txsI7es rkxXkseObUw39rVXOdD8e8DF234WEDlAuFdk1nWoMYa/WAbJm+gspFqUQZLaEFwyfMCHJOsWHibB MBRMhAhAaEKwyJNE0lrf2P/2IZOE+/vHEPLY4lcowwLBPHy4s87B11rhuELuaCs+AAoCpNVaVxOi RgTzIDpgEIPIVCcsPgm9OnnFMYia9SWHALXwGvSdo+Cad2l4vqUDjdXf4Cd86yLgQf4QkXWR8BBg /PJ98IYdwMdHH1167xK+7fbRVBcoUwoGfWQwATgMIw199BMI6b90Ub6POXngpFAtPHf0vlDkKe/o pAA6Cdw6DgS81KvYFaJBKV8LfUcCZZW0bWAIrKc96l32uIjXJtTjK4v2lfT0qydPnAKFACWCEPgP OT44OnlBZNbpkwKOE0dwIgtBQkfixVF6CdoIXCTa90eGDAFxAtc11euFbvFf34gNTt1S/Jz+2DPG y2ZHElgBJ0TaChT9MEDPZAA5FeWEFa6rD5LDSfJVnlHkMjtFzIlsu/wJe7aCoAgCwjQ7P3Qj+YK6 +KTFsoxBEBKmGRGJRQYp9q0jrru5uQWNtbu7udXe+ZZNHk/3D60O6zh/CG6AEJgQXvomnpQziAdi o+W0FjOIBMiWso2VahEhbQWIii1HJo0wWeIYpKe+kVAIOcOqGx1++k2cddqhxrp4kdjA9y8v/peL vYfQBg7A46P3BBQfAR9T+H5P4IDvqfdAIyCRLjL4rB/vnyKbCDyAHIHAMaCYj7Hjw+eAgsFtuNUE ITWBDR7gBRBKjYRSw372XIgOZ9wpkKyCy7eyDuYe2V9ophlF8mJEPJvagJ72mNuMxTKxvB8P2q8D HGecTQc44M5PwKufOC3s8cGJvxebfvTs33PxqBKIf32Il/uIRsbklvCHrnsJr4sYNyayG+FS+4Ni mRjqJyG0vLSf0GJ9XWWq07zMpAgAo8MpnZ/n64R8xyb2Ei0Z5q2iCt9atOQ7e+Nw3yHk0yxYAs4l KEbzWS3yKvvIrRM7UFzlYtLBBaxSKmuIi0WR9ZIqL7HqfevtrV1u6dxEVdbm5sbuE9SwPzzc/0mF ta8IAcfsrK9zMDyIYcP0FUYHtbeAEDmty629jjziggKJb1oHf+DUkxAJYdJwjxw6lEJccKvZRYYj j97gsHqQ/k5/xxlwEshFE1b/RW7/axceIqsUJe99pMwBULxncDDGmOLFryjp128gQe+puKYMGFP9 P0bJXzkUJzUgQ81Irca62ppwSq0o8BA+yeXQ/pD/0UFIwMi7pl5lEg1RBaFxZ/Ld14pHa+PKc+fi 9Wzc77x+5vUzAIiggSrr9Jsw5ydPHsGhCz6O/kbAcUJI5NmWd0UjBLEb1/2ENxIEYbAA84rknxwJ HCy6kWCKrhEnr0aUQiyJYw3BSiFMqthkryiHfcdTqaRJNFbWBOFyIsaDNbSXSCby8o+jDNgWdGVB IiKyPgVGrjOBb0NW2BmvxIGsvEZ6HZtomXBJfUk9hIuW1wuDyKW8ublLiQWR9dU9JtEBAEqs/ecY 5CktCBzIw90tlFq1FqyACwSx1WWPrS3iBSBZpwPRdwiHKECIkKljEOlSSHiELuTYMR/e6yPm0Pmr /epr5NJdv9QCRKCjCI/n+AP4wHHxIxIIgUF8yO2HqR9em5KTnfnFR/YMxxTuGw25xz8tP20AG0Ji /V3M/H9ByZwco6NERkG/qoaVojwqFrgjs3gcH8YkVlvvmENn1cEiaPG8XcU46RthaoLc9dz1bGyk 8+rfCj5g0U+9eUIcCINYR6edSxf+EPo48QynP//zWjyRDGLX2UWIqXj42yMx36JTQM6IJft9i0Nr KEHzOZ5jE64B1uJJZPb9uNAcSi+vRK2hC8kVzlpNYjKFZiM97Rxzy7s8TfIEWS85nKL9SGoEmsAU J2Iy6+D+dhbbTbXoPslOR6AICAFEfC0OFi6xOFcKDSl5w0xJ0yXlYiFf69tqtxY2mSTE9+Zn37LN HN8/RSH7NOn7qMS699UCKq2EHcAhWwsbOnxOAOF8OsCByC9yJGrSgaGN9lRXY3WxEabYG+6Eyi6L eK11fpwrsbDWc0cH/CEXaBjBpR/vOf53FVcXCQ7hDbm9J6CQ47XXXnvntdd+kO+z78jXWbl/Tc5n 8fgH3uMmj3547YcfzhImenbHywKZ/obio/EfggRv7W/IL738cuPleQcTUEhNEeKggnY5hYluBXQw yVuIy4WneAX5rtVKP4CjWjvPMapc+X4dMbTL0y/+7RnTV2fOnHx2QkNZoq/Ei8hTBLCeCY3w0bM/ /8FLRGM3xH/EhlCUhcjVyNAIcRjT8kj9jGduJN6lEd9BNHDEJtoPnSvxMHnjJRJajpzw0tG4FdH4 EGKaYInrn/Ft8ZCDmvyHpK4Oo1s5aiFhX1Pu1x+Ee6QPrkcTZVZEwo94sOU2idtxCSsh2eqrvYvJ IkauMNBlUBHB27e5vo5yrK0tYRHILHHogpFDpNL39/eP0wdLTKCywC/3vtokgcix07JcxwYhsaVe HXfrsOpCIRsayGK5cKsnAtzlkIZhpIc+2mtuAISqr14ecVaEj+2B/XxK3jnVFgpZF+9NEvllL0w+ MoBcJDQADIXGOzjOytd5wEMe8faa3Z89+44hRN4gt9fk+6ycebwjj3/g7aywinHIVA+VNHpA4W56 d9aOlwmTefBJ1cSW0YqeBCEkE4t5ZZ3yggfNBm5shF4tDFjZ52pgJS0aEkNJJRaobb1+qguQU8/+ /OapUydOqsQ6dfLZB7DoJ765cEIefXPi6M//vBofGroxBIUkzIGWLlFWI4FTUtr0GEdci5LOSo/D T3zGnZ0tiaKe0ruiTSqKDeZqEtE0wm3xuLZFopJfuUiBotPzWNyFhsahIW94eDjOWXYMCih1JaP5 zN4DJg0//fTggOG2vKIHEXLfxgyXsKEOcyJDhaXNJxi6HdFIMJY4ADDZat9X4iAEIDDqMCH3Hn7b 9+1DksT+82nCfcuBCL3sAyALcv3rbHjOm4O+wkFx1TYyWVefvrWzZSKMCxBxTD2HkB8f7edkVmjl e7zHfKP3Od8jV2WHwVhyyHPkcfFXTl0ZPl57T7FBiLwGhMi1L3evnX8tRIj7JjgUJef1BcUMGIcH UULJ1f+Dia2GPJoCoTSmQugAGfganRcSOvvyG/g6e/aNH86+fFZY6GXwydxiL5sUnATDEA/4d+7P LOYR48KuDjp3RIS1LZxJE5JK3tORXsiwIDmZzdzIZXOt1//2zOvqzgGSE8/kJJxxmgHfU8+eoTIL QgsMIiLrf/rfbty4PmQj7wQZPtadMKA8Yg5cYwHaRh/3uxCxTQ7yjrgraYwm2ONljcPaAJa+guZh z7d6fZ0k6bnJeEpS+geCkeTwVR/DjlMpjkD2w4p7LA2CPRISOTCZ9SmmQgYBDAiREi0HSg1+HruB hDkAEIxZoQfhjK6kGwwJ+OSzhb7PNtsbBMiC4GNzE+6CDAIr/iOA4MX9fYSwRGHd29xClYkQCNmD hVyKkS1TVw4k7XVlEAt3telBFB/HjcjzAEFRb1sxQgZZOt6R2Gi4LHqvyBKUTHUYiEVqI8QI4SH4 uKjq6iPi4533iA3jj3fOhyfBxnnHIo5LCJF3QBdGKjy9Zuzyg5NgMCcw9D/A1AMdP4Smvt9BQ9yL cMbLBIdxyBv4ekNh9sbLUF7z803ihMgoVM3E1ywenGcGpZjXJGSedeXZwI8wjmsJQR+lSQWRYwXW hWXzhcx0Jj/94pkzrxtAYEK+OXlSPIjg4RvGe589E8N+8gPk0Y++OSki689HC0NDGQ+WO/BG8LdF YTHpoZ4gHQAoI54GuMJ6rbSFCyz0qzEtlihf8eJaXikPOAtShxzFrVSZr7PIbERL+T0d9iK8dTkm 0gpbhwQfl52S5J8VAKUSlHyBOBGTWfev09T7jj3KyC8itVJmKSgjWiAUlBDnfYIHqss3BQaN1ffH 37XWNZOOGNaujhKF/zAG6cEIQ1iHyi4P730GgLRZu7WxoybDSrK2WqEFafO+bS5E9NUW41jt9Vao stpgEQXJVMgbOLXbIYm0e43880XAvQcuwA4YZGpK41gf9XAIyUPh8SXw8Y672XH2nVBZnQdHACLn 7cADgOb82fMGHfIJYUJCsQNwgR/pD29kE5gTUMsPig2qsR5cvKx3io/uAQyRTgQni4huFRkNNjqp wZnYwALUrmBTB05sjkcTllasCIWgrDhb0EaW6Vxh7RURVq+feQXo+O+FO8Sai7J68wSk1ZunjgQX 4kjk7tkHR+Lc5cGJf8lcZiCMvBGozjKrAR6B3OL8OyYQvS4s3DES9DxlfxediLh0tgQrp7Dl8Yqn 8PE5NjWdNjIKEAYbuTw0NBQdTsRHgmgi0Vv6oghJJIFS4ZzrB8gaEiRZ31IqJBm2qzA/gk0nZbXt 5WRUO+BZCMlxERxDxJqvQt+//stWmylCfu9+yz5Ba0bfd7lBg4kGedFqKwD56t69hfX2lhCIYGTB 2XARWBvrShxdGllvs82ECNHn6+vrTmVNddrP4aBt5hwrb9cwB0LnP3QlVo9b7/Ui5kP6G1NTRAhc yKWPiIoQIb+y7MdH733Ziw0jjvN667lzRCKPiRG8bI8UK+ZCFByizl77QSHScIEvwAMIwR18/V84 3jjbxUeIk7cUJ2Cb+UazObqokqtIHuFd0WXhubkc91ljFCgurEYLCkofxMc0urtawh+vnDGBdVIA 8uYrRyQRwcipN48gseThCYR5TwuvHH3w7MKap9PstYteeSKwSG+QHvHQ5TjicJHwzJ84PtGJX8oi qDBm+5b4cqgtjF/hkIk4R3q5WfYJUUxRz6q0WJyJ96SHhkauaDhYgRh3NgctiokyDYt4EYSzDg4O PhWQXMcfSXLAsK/9XKwQFjUG6aWlkFoBaZGtpBYOI3UinzC1vs+++tW6mHPyx+buw75vdVZDTxp9 /5hFp3ff37/3u3u/27wnWNhBenyBJe0LDFSBJNY3ELxaNxdCrCg+5Kd4k1DIeq9VF6iQPlxkq/3c 7TiHdEKb3rXr8z0QYYYb2QzggxqLxvxXF/Xry4tfCjzeM4S81wMPu/7fOf9XjrOEh97hBKDwl86e P3bBa2Crn1DBl2ONv4gQPc4fE1tvhK/pn8SkpNHRyVoNQBGAOBNP1cUqYhZBwpoUxJkUtKsryzr8 LBsfp6ez1d+fev3VV35OCnlF63gFFScZyTohePk/n4nOOiE0cvrEB0dHH5w4+ubEB7/KxVENnGUU a2gk0O1Z6kFQb5XQqiuAYihIyA8Cmy3cjcwynoUkChKGbJFHt2MifTmNKSxX4h6ZRORVOi2vpFKJ VIJvSHBQS5QMkfAwChz0MZL2NSqgUExzzjxdDya5JP0bh05nfTrC/hTlEAgrbgZG7jNado0o1Fac G2G9vlZfn/eLfZ/96wJMCI+F3YfKIPtdj77fNeikkH0N89LSozJFA1jABSCwpVjY2nLg2LJ7ZRDD B0QWILLeRQjwAZS0tRDFkLFqj9pdfFg+8NhxnEJEsPWDQuDTWWKl+NDglWgr0VdyOyaugI/z598m MrqnvwqTY4/Dy/i8cyW4nvtd/Jfhrb8OjL94vMG//EbIKvAmIrtGP6+5aDDtSaWoVSt5q4JEyKqg AClo92OhmqvK9/T1tRdfFeYwE3LygpwusJD36MRpUod4EDEkrDR5hu+jb46OXplO+Pnr1zFplR31 IqtGcBJjDfVjBoNYGEFH40goqPzwJzYgUn5JkZC+HE8NDwtCvHgaUuuKmnc0e8VTqfiVRILhrYRy ByowBTOXbSuwp54+3XU2zvBYdCB3YCSiRiTgGFam5llKlmT5JJfbo6mRk1esmh6OxDUT5wGQzXYL 8astoZCHGAW3b/78eLU7MyBGIUIw9+4x777eIT62WkoeC1stjNgK0+qhzFqH9AJaFCHrMCHrYTBr Cmet0Dp2C0ekmMgKsyQ/gscxpQUzQxOyPmX4CEO7X4rAEgZ576P3fvHeO1++c0xhvS0QOf/22+ff /Q/A8ddAw6v5vMNIDyj+A3yolvq7s8/R0PNQcUpM3D1iwkQJgSFsUnVoyWk0mMWQ1RyZBdgoVLG/ UU5rL4I8lEAunD4CTI6eXThz4Ui01tGbp7559oyZdDSFICHyAU5HW1nv+o1MPprNwoDYShQ6A48O ZMTT2fWUVU5tjWjpIq/hEZJI1OP1Hb8iTgNdj3LJc8EDxJW8lgY80vG4YEN0mxDFFS8MkBEhQh1D l11pf9ru8APdHTSinoT/aKzr1YEQZOFZI0zS0DZeLHHEcFTOIEpaKoWGvszx23kA5L/98Xftddaa bG1+JfTx7ZMnKrCe11iGET12N4EQDmW09W3EBCJZBgjNEIZWZB0UYyKrpRqrdZxCILN0plbH2fcO DUg7NCWdrsB6Hh09DNKhwuqwDnedCEG5LgzIlxfJHu8Jf3wJhITgeJs3pY135RHO/7+AEgovlV1/ 6Rp3PzjvgHDeoHE2vJcHykU/ARXwyBsOJ2/Qw6MVee7zKnFSFJQIABYZ9aq5cmEQjLzGJhWM+sm1 XxSF9crrQiGvnD75ygWorAsowTotLHLim5Mn/575QUKEPoTnf5lOZ4ZyIuKz13WQV2Af3jbBayTk D+ooCK70SMy3T/oRlFPiko+ODPEjXugCNHJF7oRIogBKIm1HHLLq8mVIL9Fe6SvpK54ONoqj3z6K n5iuEguSiKZjsD+cCKajj9K61THqXd87POBcoPufoiHSGv0DbY4slwPtPrFySBAIe+B9dp2wABKj VPo+++NXrTZapha2Nr/tQxqdjSBESI+4siiv6qsnApDN3wEhW+11ztPSLYdgExfexQQHVVcKki1D CE9apQWAhCAJg1pay9hpO6C07Xk3o/g8SI7rrCktVkFhoTLIJQvrfqTsQXRQYb3zC8JDSAPsQZi8 +y4Y5N138Y27nsdATPf213jkbPf2/EGSUTSZixGInMfN7t7C6+fkxl9/qwdLJrLe6OJEMYWQ8Hxj bm7xc3iT6nYNozYxtx03AQZu+DKATFfX/tP/IOAQgJw5deHCqTNvfnPhJLtuRV6d1Jbbo5MnUKx4 +iQJBBTy7H9upbE3Jx+zXfEjgXWkQ2cRGiag5BIcgf4SnIykPRsSyVcgvvyRId8IQAAiduMKgCDo SInWSuMx6APORA6Y+CtXhFhgQsSo+Bj5lRCjng71mlzs3uWhGMcWi/UfSStsKLMSidjBg8MHhhA/ sLR8wJoWbVHRGkgqL0yKZP0wXEo5H5STRA8Y5LNfIRaFcsVvtc7k0PBxLMIb4gOnXVoQIZEFbMMl OqCd2kIhrVaXQ8KJDusa3mKwlwVbCGwphSDma0lD1Vuh7ejBjLPqBpHngPEjFgGFdKa0lYMAUXyo /3AG/Rcmsd7Gt0DkbULBUOFgoFjg+Zy+dE6fnjt3Tr7xMl4516Oywqu/ixI7nT0b4ke/zp01SJwH KMzYnHtL8MHnbynDvNVll258S2PCf2c0dPYNlKxg60oT673h4YGPQrV7TLuv6trvBRuvvv7qqTM/ /zltyNEFcSFvnhRhBZgcIZN++sTR338gLxwBI998IzhZuM55eCPZEcCDkV3wgsdSxXSgcVgt4B1J W3GisQoRQqCAS+JAkSdXvRqOy5evJFIUVfG4AETAAYSIK4H0Is/ESR1xdEqCW9LKIEihXB7SzsnL l/lPxTEBXyWZh0aZeNxSIkDIiLbKsCSHY1+RXIe40nB1GY2OmM5FmZXUtmHBChjks811lGPJJY8M yLcPLYvDeTM3AAAgAElEQVTugrw9gV6tM0Ellios+d5a31gQdYaKLJ34QPLY2ur6j5BSgKEt/nRj A4HelgZ718O84VRPbuT5o7dN98cMclxkTdGoszZdJNbURyFEFB7CHyKvjD1we5fUcf5dQCQ8zndZ hIDoeUXwoNh5V+HxU3osjHKZWKI96VVjAgEBwzl98JZg5dw5PevPABKyy3knwN56zomc7Vr3roU/ +8MP88tCJrVFgMJOi4qQxerSUrVZrS59+frrr6LO5HUWm7wJcMCeCxxAJCdOHLHnFtJKsPHNCZj0 o2e/y3hZLQUWiGgm3SdOjBzQlKLJCoMIk3yIdQUc5cWWFX7mw9anPV78V+Ta/sf4sDjyOHARF4Ck gAd5Rg65zBRJGskRAdTQUDwlb7ks3uMKW19GLlORcVCFzgdLaxoF/2AaGRcYEdSdCEauMxbtdVuE zaYL92GIBMNgvk2z4w8Q8oLE+m//9bOt9QVkCu89FAMChLgsYSiy9kP/oRC5R/pQCmnt7oJDtnaQ 43A1vQ4hvQn1LRY0qlOHVUG1/Pp6FyXPSa3j6Ah7rDo/yobM/wgjU0gWah+HMogdYj7AHhbi/UWI EKgsoON5hLx7jt+4CULO4fucvaZ3cjm/SyohUs6dO3f++cMhw32HB38H2AAugBC74ck5sAvI5Zwj kPNdkLxlRv3vfsrkUHKhWgVssui4A0N4l6q4CTzW1sWk//zVU6+e+fmZU/9+4cJJsR8XTr9JKjk6 +Q2wcRKQwN3po9MCkSP5fvbKqgAkdz1zHXPvsFVLHHMwNEKMsIDQWGVohBLK0ILsIa9KPEi7xyNA CFUTLnf4D3qShLpzDOBOJBQfCTS2CJDwWhr2nC6e8KLNB89w7irElkgwcSyeMpSAhzGBoRsPDg6I kE/9qFslDJQkkvEAoySQG0mGc1ho5S21CKop9v3rH/+fz37V2kIe5OG3Wsf7cL+LkH3nQZw9B4Ps /s4QIvfYkbsQOgyrNREv7pDRPVgvrAJry6K/9CLtn0LIjxmk3emN9f6EV+/FiHIIEPLR1HuGEWbP AY93vvyF+o+3DRpvgz3ePgaPHnQ4jITAOKdAOXfuGHreJTrsKj8OkecenOPVf9aAdR68AXCd07Mh 7a3zBBCkltNbb4Ve/q0ePDynvcIfiuRqNJtzS0tLi4oMYY8lgcfvRV29+sqpV0VnCUIEH2JELnyD pOGbQIjObGAYSxzJN8SMIOTEB7/PlvOZGzcywAg8iI9+whgBIfBIqxXhU/KJMYqvlys/0EdQlCJP bXY9MGGePA6AXEkjugtSuEKADF2+koJLT8eZJsE+Uzs8pt7THm/82WW16WJ78O/ApFy+zPRlOn39 BsZmfQqZhWBXnO0noq6whAhzWqIjwLrPvE6S0V+DC70JPMgf/7gpFy/rFDkO68lD9R9hteK+y6Fr Hv3h/j0aEEDk3lcLmDm3oMOvGO8lAHpwIf58XYERJtMBJ5cocdGs9R4o/EWIdAnkWDJk/nkCmTKN NSX4EJEluNDk+Zf4+gXo40tA5BcKEYHG2+++/WN06MlRhoLkXJc+lELedTf4ErAM/cpP+vdzXXyc d2DoOc53X7A7yi6hGJzhWM6+RZi8ZUh5nkPeOPujYhWW4M9j8/DSkuCjvf7lq6//Z6QJBR+v//zM 6z9/5cKpnwtKLlw4c+Z/tLbb09o0JadvSB8XLnxz8sI3f/PZdL7AfcC561zSKAgQv64xXhyIIA1d NroQAZYeuj4yEk3gogWRCITk0g64BMgLyChX4kyGJOJ6eOnE8PCVf0wrQtJ06cyxI54b/0dEtQwj Krw0ZUKMACZ4EEPIWH4TBBLj86E0jchjIuS+ZjcRx4onojZGhaXCSSI+mkq50V7auiiepE/wgXIs cd2kDyQJTWOpEdl34SsiRB8RHJubX6G6cROlXAv/L2vvFxPnmaX7Ih1pdy5CX7RGfcGRctFXGcWA UJUxoJ4tnYtRdO6miz8HgWhUcINi+hjwiK1JA063oMo2nTOjEpVzE52L0YgS9l10FG9pLtxpbJS9 aWEp1eDQWJ3ONGbSRmqdkTVKJq0tnfU8a633fb+vCsc9s7/6X4CTOPXjeZ611vt+H1n6NgsVIDmy HeM0ehCgI33qfHCnoCwi7TjR8tZOO4vl4mGMPHdEbLXs6I7aK07virvqFn+lAQRsmLsyPAq4FS4A hUAkKuIveekxv3XZTFc0TMkLEweVjvCoR7Enc7xO2/W6Q4XnEkjewM2FxDSlHSZ2XLbGzPPnz6m6 D0Q9vvvqd4de/TPw8QoLWULJm98WRF5Dv/DNb//lt//yn98UNERE3vw2R7G+/c+fvCmQ/I83PxKD tbm5vYn5YLKxsq0nJl0TFDaQOaAf1TVEEryob2zUETjke5SReuwZ1hFTRDKqCN6QjzUUrG6gP1hF 35B5pIKvoxCMbxW/9VMFBKWuNcSQVU0jFX4dEK0xvzPdV1b4TGTonRtr259/jqD+//3+3vbqO+AH G9i9w128rIz1E/AmfPwEyPzE5UPe+n869vfPnpwcHNzf/ezZORUEC2qDv0qyOsd4rQtyfAI4wIeE kCOcAJQZXY2WcnEUCHFg2Gz3mS1wcmAC4tWsb/BZmTpWwkjbMpbw8aGGEJgsxUPru0oI5cPUgwoi cBSUEIJS6JGLImMo9CTMZAUl+wy1rfaE8Brx6MmykSMkgMIrCJFA0nOZBWFXET7785Dg81Xl/zW8 c5mUdPZ1Db0qBouQiICoiHz3u1+/+cr30FF/k7VeMV1/KTIiYeTN/4H4ISlFbp98+5O9m7oLMU7w ixxSX6lz+e0tkMAUXjd/paVfVq5gqfASSlO55UUtxJAKIgMdlhqs1VWtZUE+YJ82ahUKC6pRq9SI G7Rka+QB37627qUwsrB2A2WwNbNhpATTWzgZRP3Ov/xejdY99FhuaVTnlnp6JnndgPInP/2prS5Z 1f2+1kRB/m3//zzbP3pwdHzMvRKf6YIoK/N+8YcEFS/yso0OQlRHjjipyFKWDpscGRJhfYjVtVDE 0mETr2ZZqYsFrXQ668UZJK7ObasgxOPDKCGjO9ioZNQO8VbirppI526w6K8KlA658F4p6Um0IyEi oyw9iYLYs8tIJcUoFdmHHBb+tJh5J/m21/mDdFl4dRkRnmIi73pTESlek/yfBzaMDI6qeAjC74Pu 7q6hoe9/99XXXn0NKeQ74ri+852/+M4r3/sak1lvim587y+FiG+DC6HkTTwTPuS2e5fbEN9+99bt 7c06ZETbIfVtpI1V4HFLq1VKCNmp1LUafMuih23itUZHxnKtVnjlw4yex40bIis3/u6nlRoclo2k 0Ipp9sBj1WLIahWGCuLBohYi/Rp9HNMKhURPLwTvF4LI9jvWfcfGET9hP0bP6SjZRBzWSuUd7vyI N9Aw+b9EQfafGCA846BBkCb0L9IylrXRT1jnhYoc6balmOp1Po4CH0futuK0ljot6MfRkTbZHygj +aZhq4CE5VW5Um9OQZ5nPBaXmeshcGgHhCG9149ib0GuykdQEMeiEBUivCnqou+HlBJ5sY96kZkk U+Fq+ez32B9xoXwERljo6nHXBflQTISNnjes1mXu63WfCkuc1huhtqzTNEKJMILja0kgr3399Wt/ 9vV3REL+4rXvfPvN7yG3E4yAxytvvvLKJ//pN3c5DXwb63axvXBd99qCftyy/eHYECQmiBjMHbdo p7SheEsnR5BXVEsq1eo6K7yAo0JZQMWXCQTaUvVMjifyVlUiihayqCNAANlj1ewVRAUObI136wwr N3C+xmp1BVkdxax79+p2viGeK3hN90Nd5bZGP8W8PGtYnFZG1esnoiD/tv/k8OBAu4RUEF1sa5Q4 K8nxmTYJOd94vCsBBDsH3beJdw3qv0pdlqZy7tqYHL/S7zigzXrwkS0R+UZEHoYc4og4Gt/ilXw8 TwnZsUXnTSKi7cHuXs/nWr7qNX9VoI4YH2kYod9y+Qj8xPzuOhK0hZ//YigQJxg4cJGKYvFijxWZ 0rjeY2py+fXXictl48J6Jn9O33X5cpaPyxlGLl8uKiTis76PXuGbQsmbr/xngeVrOC1cxHK98pfk 4z+98goQ+frNr/+bjcvzjEHbK3XbM6K+fUv7hGte6iUVqhRKhtqsW2sWqa2BiMoXsKhWVUMqq+a0 VtFfx0Cv9tYrvAXx4Ig8gztulB58w7rKhsYQ/Mg6JeTtVfJ0Y3X7n3zupM6NI+prN37KLewwdM9F Wzf0ZPNYEv/OKoe7brz9txLS9588OVl+cIjzDbKRrsuiAiNf5Pn4AqeMZhWLDfXjBkdMEEKOXB/0 ovWqj/zqCuJW6yPuDGQbn1hDxLL6Tjs2MvNY+VZIblUhEMHV9ipJ/ZVG9O7ebhKCj0oBh94XNKMH MUlfWEgxUqAiCk7qujy2Jy2URC2yjPhb4bteJCOvExSTkB7tlbxO78WHHhBy2aUErsqevR6H8yMe RY4HyH96d79Q8v3XXvv6O3/25ne+/rPvfP2973wtl1eEjjfFbwkXKh+vfP3K15+8cgQJ0ZMIbQMS 7ob9M64PURclZgpv6aSvRnG8W1HJABm3KrdsZ1Rywr6epguDo+r9Q/bUoRE3CERVucDkSQU5nvFd e4baKiEglVgK1r4Jz6vFMa7V1RWzWfd+u4GTyK9X7ESoWO2re3T56VfecZN148bfssy7v3//wWfn /3r+jKc0QBhPlSOarMykolmsk5P7MEu/Rgr5lY2049P/K7VXv/LylUaP+waHdtWZ1DWrf2TNEMej BRHuhYI61k5IIrk61j+qgKiGPFQ8lJDOHezMMNo36hO83b2W0KEg8pnvLbjDKmgMiSxEr5W8wFd7 CoaFmrBsYgmmqyeVmFAR7gm5I8fQiwl53Z55HnldLZw5Lm09wnFRVjjQBQF53bqVchWl5DQm/t2o m72FwX74re+DktdEQf4CvUNA8p8BhvIh4vFvQsjXj+5u4vIp9hfe3MZSdyyikqx+C7112+ARvQ5v sNvNex9oIWrDRK0Wm4ccyPJKr2JCu0U5WdO3Kl7mIkFUEkYPTp3oN6+tb1SscwhS1mm0VG1YK5bP /Y1bd37/L2Kz7v3+t3XJ83V2RXB6Uz3tinyDTcy/rbufyr/f6k/+lmXeJ+Kxfk0FefavYUnUF7HA m5WQzz77zJogsFon+4cfYX9fnHfnvtOhjyGbewULYd4pCTnFGoYPPvIMYi6rnYokOb3lnCJus9Ic glV9nc5H56jO72oECQmkgIuB4TmkUHDhcFZiiQtkFFQ/erTWpQUveytb0SqGZ0ExzIolrUYH44VB xPB4PZASX75+WSUFleAeoKExnr14rROjo/KGxPreohos8GGtH/kLGOwdGIDh+v53xW99/T2hAjoi YPzFKxCPNwEHjt+Ix3pfJ+g3N29x53pdRcXpLPlksaxF11Vf0weKij5Z84pWXUepKswmku5FJpBB NKyTDg0dVaJSrSozvGPkqFq3UFRoY0MijAR6YaVW4yivPEHDfX1jQwRibb3OMplm+srbb29rV/23 93QFoy7ZsuktnHX+HazxfTssbLz19o3/uwMOC52Qzzqcj2cBD3NaaSNE5OWzX392zENDyMnxETKI ffQVg49sJtHmE4OEJHgYIwceQ4LBSizWTgaPB94HyWxW2sZmPWcMIR075KMT107gwf6gqocqiHw6 Cn4Uw53nkAQMN1g9BaUCT3ivmBgsPfZe1JFENUL4sJ8BEYWkylt0UF5MyusBDJa4ss+ISJG9+Td6 rBF/WadaenQQUx+AxqAaTPk7GOwXIe3tHxgiJULH91D6fcXI4P1v5PYRzvu5+f674fRztxUOXrG5 Cf2VvkNr5RMnbHvgsWqNQ/ovDGzJO6vIGVX9JFdJwKr12FdByZrWgDmPhVdVuKvKeg26s3EP2gG5 YHtRa10I89ZmhKwghVTX2I6/cWNbNAQuCzlEAIG/Wq2s2u4Rqz9Z1UHHd3QHCZyl6790fPLkydmT r/4Bi21Z5w1CkTirRD+Ens9+dd/KWMfH3BX+SKfl79vadJePo5BJzF+RDqaVhJCPBJED66ln1lAl D7w+9Fu6tDCvIYnJYgwhJsQDhy0h7A36QTp6C5GR4LRCWPe7lBDtkvQUvVvCb+lxjArJbEqmzKVW TL4TWPTAm6mcFIyRQl5DvqG2FRWlxxxWz+vuuxBKtIBGEQlTYiSk16YwB/kfhr+GwQKJQSyh43rt NfTYjQ2B49XfvCr3e7949y7POycua1P4+BQywm0hbptSrJl6VOq3KtwwG9kar7TZfgtLPIwctr7X 6+8wTXBOETO8Vc3kHFFk7QpDV/RajB+ERKfkFavqak1Y0fYgtCVkkAq6jahkQShW1ZDJOzc//wPL vfe2K6HCy60i5AmMXNV2lOAaLfm31U76k/fOUORlGYt9kH9NCMlUeJ/JhRbLNeQ+zipyxA0f1GHd DzQkxsoTiDJ0ZPfWGzlAVx0CovcX9EN29M5bhc/bbXDyj4YIBIR4PBRCOp8bH7q3T3eYT8Qvz0H5 dBQGEwkJKlKMfstVBO+pdqh+FAoxmQSuegJfRWPIEoqJR4+qhkaPQgJBQkPhm7jIwhGf+Fd8tstC Ss/roT/ZWwwKYhqCx0Iv/yb6hRv5rxoUJYHjYnoXPl4TOuTym68f/dJn5t/d/HQbIsKzyd1WAbF7 f6YD8RWdYqxoCZifVrxbYR9E3lunrFTdZ1U4k7XF1YX6vEr50PSxVtVVh+vr1a0NueMnWpnwKpbq BxvtFc4EVzjKwq4Ihx/vfP45F+Le266xTVLVMgB6KOurenJgxhbMSQoiBshX++fYL47nXcPOWF7D ysBhhHz22X2mdEYQ3etBFeRIteFXigifJpWr+/Fy//79aLRQxjo68EqWJZCdAIQHdl+nvhMLvVk+ vpVBhaVe8kFEXEEsg/SmAsIC1mBExEWjaG4rxhF++J0Rjx4RjTipYiHFxITPTHQKarYUE2pJWuEt ZEH5Rk4ybJhyXI7ZxMtd2ocpIpNoeyYpX6MHJO6qONg/KB7L/1oGaUFFS/74fbIBFfnNq689esCx x7tc3P6+nQxbrRa8Fu7esUKWXCtojPC2ZrUtLCrknlpYGFJfrVBWNupM3uyHMCxQNipgiB/gNV16 mNirGtaQSNSoWotkvSJ+a0276FW20IHNmtWL125o50R+jtWwjTs4vTpsFhfqAi7hAmUtgQJbsogV e5s7r4CVn3U8+Tfh48nZOedM6LFsmjfaq2xGfyYKwk7IiRJyqOdvO2SV91feDzmyx/uBDvdXR/eP Ih+/4iCjOyzbyGHngT1k5IPQ7OT2yMof34oZxPkgHs8DHrF8BT74YYh8ZI4ASiz6WsooJhEkmjLT jaKriIcSXC13kA3XlKSeFXmIULwIj2+CBsflli+8zvyhI2OZ6tyg/C30o6rVj1QyKC9ZCGazpLu7 649/fPXVV/93sVj/8OB9EvLzu7q0991PISJABJsMaV4HCrdRxbplcNTpsCgWHDEBIPIZrq9XbtXq GxvbGxXOtNcoFCGY28xVVSMJ3dOqBnZ8pSY/s15DnXeLBV5LMVUt9HLB+7qePQi+Skj0IUb8SXWe awcuCyvitV62ekM3CkZWWeO5tLF1CqbokUGePPnk30RAzvXMzjGG5OzVF1+wCCx0kJATrWLRZx2p LFjOMDFxNpSG+3xyP8pIKGYti8s6OLBeiJV6d3ydYZCSB7qxg20zt2OIPM/A8a2gJLrXjmYQFxDb PjE4LIQP+qsWPBIuYuk3CIqJSLykGhJf9IRv7fHQUnCbVXBCiEGGEEXoT0Tiwrcv5x69flYMU2YS REDIYD/8Vb8QMgghucwBHD0gJd1dXf/LH1/9h4/ef18RuftzcVl28p/bdurrn92+Xb8Nu6WLDplG 6nVbgAhM6qtVPFtnl6TOtSTr22hWMIxX8Stey1hcqs5Bdi3q6md/tUKnVdmqQDGqW1vUEr2v6bdW mULQNPFCF0q8dFoSLmoCixDAVVTsqmsFWPTpHW6ovcYhSL5Vqaievf2zjq8ED8np3LMaAKi/CnOJ SUR/5hbr+JCA6DQWloYoIMpA8E6a2B0OZ+i+HWkxCzlda70kRHQCcODuYCcnILoxEDPITrupXsvn HkNs2x0VkE5bYBsKvKADJZz2ClKM98FvKSs9yTtJcmn56WIhaImpiqWRML5iiaTg+bwQdeRPFJAL UGk9ilwdGWsI4jBBSz9kA+IhMtIPBentlQdggo5ise9yb59AcvDwv/7XX7z/8/d/cVfXK777vojI p1ASzSPvCh3I7CzvahBxOFj/1SCyxtZhfUO+tr5xbxt1LpDB5gVFAnFZsahqTRf1qVVPJXgborEF GtZrtWpVex8CCjRlAz+pWlKzBr31GuXrN3Rz+XufWy2L2zoi5dxgJWutekMn7MVvvb0K0yUK8t4n arG0imX+SteE5HvoxCe0QU6OrV/IPYPuh3DB0d5Q91U/dT+Dx1Hqs7hc5ODAA7oriHusgyghHtMf tG0WfuvDVD8CH26yosXqDfVdXJ2PNowUU5sVtaSYYaKYefDnPYWCS0ixaLbMM3tolvSENGJHDoqC k/Onu6223JiMeDeGCmK2UP8WeKHDulxkDrmsEsIRLm6rx5Oi/AJ8EI+fv/vzeAY5q/tiSItCQkwU kBVOn5i/0q77LUKC3UShKXVvfVTNaXGGnVZrDfNXDOuVqrIBXmq1mrbPRTxurEJDtHK1JZqi8+8A Qp0Xq2IoT1XZgxcY6ncUkHt1Ll9fvXHjbQ48orDLHr9uH4FepoT090RCBJBn54nBevbsi9bjmSkI HRb42LV5xUO1TOGjf9+9FVXEvniUCkha6mUIsdl381gqIXwMWX3Ht8+iwdrRQtbzlpz+LcDxrQ95 dhs93Q34wM7SLiEhhAzi41DoTRAxSgZ98iTTP4y6kOehVUASUlQ6CoUwzdWTIcSHG11CCj3WgPwP YHHRkQ5/2ZIWX/+ivyyKjGS93mc3m0U++nRpfd8bnfJX+/BDrOf9FDsKceMUOyXpbWDCOUaQgjUj 1BHAsKKFXkJS5+IpHUEBHZXtOvdnUGulOYR8rHkc4XsVbYCsU1vkcUtnUtapMzVdaFUhOTXIC9eQ 4KfxY4glqBazVIwf277Hwax7W6uhR/m29WJsGlLX/96ykH6OIm8YNfnCp01ygKDI+0wiCEKIWizP 6UdRHMLH/743PexN3jd4a9w/2nObZQry0UHiscJ+QPRZ2WKvDSzu+A5AYU/oXFLPOSyPIIEOdshA SMghkZLBFIJiKPlm7VOLclx0aJ5X49/jC02KxaT8GwkJH2QrdHlc+Z8MiIsI/iEFrbXhP5pSgqIW Kem9XJTsrt333mQNMRj5lvyVCyQKRxCScGr4W7e32R2BxVrRFLKGsd+KEmK2Sy0XZaVasexhHUKL H/A/NQQI75+v0yfVFYdq1aSj6gkdgaTGGzqJhAP9QoqOlrU4ACycbP9WRaRW5RJ4JHQs1Fr1fqPu IrF2S0P6k47AR4t0/CGVjy9UQASRY61iHZuEpEcQj0Q79GjkvsuPZSrIQTRalIsDyx6E5CAmdcOD p8jd4WBiQORb3gjJZZA3OnHeKO4Rhz0UrZg5OJgSMujq0UYdWtzWSx89haSHEoN6ulrXB7Osk+jq kWJRiMNb/4GjEGZaMm1M0xCSUkD+4K+OXvZJcDU8uKN3n62/4gqsbwkj/+/PkdehJZ++z53quKjq NgG5dXtlpY4L7pQGcVvh4NhWBeBUVrF6vKI6UqtoUNehqyqLVvZSuVitrhsgEJCqqEW1slGTH6wh loCnikKCMIJ8wdJWRbfXQgOeH/8NG12srXEsEsP1dfTlOQzJFgnGfBHS9598csoIwlmTdt4qKWI9 e3asgIRhLN3V9/7RoZ2HJ2e2ElD02ONN7huOyIFOLLqCqGoc+J6kqiE7aSXLC1k7D7OL061JaFXe rIKoxbrsEqLpXC232+8AifbXY4M9ff7vOYqF2Ajp8SnhyIL21tMJX/tST/ihf09ubz2SoeFiXIiS jmEaJWyPFHpVRxBILtvGRthgL7PYhFtDCCM/15rWp+/aODyXHt7GFigrODa4mcPKCotYZrQqwsc6 S1nrNRSAKyGV251HdPxS31pjYaq2teoRnGOKKPgCm/V7FcNGREWyOd6D69JS8eoqEkuymSOoWdtW QO5xty3Q4/807Puo29VVREHeQ5/wzPmIDusiQCIfh9YrZLvQTgJ6FFN4sFVJ8DhsBK1JmiFcfXvk M+9yZQRhAnHdsCkt64VEk2Up5LlfP8wi4nw8T6q8l3UVYa8l9MFCoiN+CSYr4aI384HPHPHHLhKR os+nFG1CPqyUSqu9xSAiRW+Z+O/+zMN//PD9JsIEshZ99b+u6KGkoEv1ezNbSWJ0vjOzMQSUBJBY VQuIvIszWuEQQiSL1HF+KtvcAccK83tF+FiPgkIo1vjrH22RNZKgd86MwlPbUjSqdYUBpqpW2WL0 YEqp3hBY8BNbYshEkbDCfV0nHhVBdj7W7vz+jposDoGhxltjN76qm9WhlV79mVqsc2YQ3fTH2h0X EXKcEHIYpt4P91Q8MhYqfRZfHdr37cl7jayCeAjh2hDAsGNo+IhvKPuahGhOVxF5Hmq8z5nUo4Ko hrxBj3W5L44pDpqADGazSCasKxi5z34Ghwxa7fsqoZQVk3oYiE/nUFKLpQ13F56eYnxo8V//TkbC Ii73Wz1FXw+Df678p8R+O5ZY+d5Ffa2r3/F3/OE/CiKbepiObK5sboqEUETq2mEHGiu3VDjEW+F8 H6tMJ1oArrpxqlmwkF/msFAcxNK9GVjHYhypb61vCCxcXHUDa3Rr65pCtm6Ijmxpshd0RAvkNXaP 559YwRjjFtI/FhmKiAAy3U17lX2UNV0Yz62z38GoyScSQTrOQwRpx4fm8y8CIJ/pWqlDVxCOnPA8 0vKvFQgAACAASURBVHlE0sJViCG0WIjqSSskrJqycSwtYVFCvC9yEDzWg2CykNKjemj64H2CCItY XubtY+2yyDY67dVgzCKZT3uvK8UgMRmMPEQwkvJoCzkZPOL0iXosj96OQ/BYxQBBoZgISzq19T8v tGcWrGjVtxgCiUlJ2A8p2d7LEXmeo4RKYg6Lx23Dww6KCRCBeGygxru9sord3TaoJRSLKtcCshdo Sdz8FhOJRhHGDLmvQShqtdW/+zsJ4rUNwQp9wxoAqWnpa4vCs1W1NqL2I2GeUCWu31GXtbVq+oQS AbQGu2RjSr66+o7OYiGicz0hT4B+gYAoIWTDxhWpILvKSCNEEHzwL9AS4eKQt6zJOtDLgU8rggYq yIFxcWAGa+fAgslO6KfH7azzJisnITitMzJI6BP2DgY2XEECHUVP7L2JloQUP5iDIrVqma8ZH4XY nLfDmCiEUlboj4R1ioUwQe8UJS/SN/5k4UifJgtXWMvK0eHpJN2w+w0/I0pEQ09fakry4S9+rnNa IGRFLhsiIxsbCCJyW9kAJXWAsoFBEytlUUzqnsHDTC4/4JVa+GwjhGvzgx4LtV4uuIJEIHNs1QiI BPYt/RE8SgKpMYZYK173TREatjZ+/zmnsrQKsFarxMbiqi7YAiDsglgEEUTkyUV0gI9jXmxvXm5h bRKic4uZQtULDmjI0V5QEM68x14h61i+sXUkJJy2Tfdv0AssFvTCEUkuAQ/tgzCFAJHLbKM7IAGR XBaJkT1jp7JuKj0K4S7hKWnGJwtFYi2r0BOLuXHBSE8UFruPM/EaXP4DU1vF7ItMRasYx2WK6eBv KyHZ0zLK7Vt2Ci0qyV2dZoTPunkT4nGTfMgdEOGOjDRW2+u2jl2iOnSEv8kdEGt5VKycpSJSAyHs dXDUfQueC70PgUMTCwL5FuzSllaAJXtsUUbwgttio7Cr7Zb13/+LFXtROVtn/KjYPivyXdUKFeS9 M1Z5MYwlJJy3AQRwGCNogeBy7NsrHprJUoOlCWOv1Vp5AMHX9owRk5BlFZGPsiaL8sFY7rQcJEE9 xBDGdDdaybhJlhENIZet0Gv60Zv7eKd4pCxkXdRg7po/Colfi4gUfV+hoq0dsbzujcHEY9n7xYQO LXXhj+qJChIF5N9huYqZ+7BupSeUs/RlT0pIeiSnZbicqIgEdn14+KMf3X3/JhFZuYljBRfhZGNl mzJimqHNEV2ZK8/ZsGAQr1hRq+qAWOOjpgpSYT7nFFa1roMmFW5joiEeb6uWWMm4tqVtlhurmE3h 9PxaVd7bVgm5V9UpYlUwXaGFoV4C8tWTs46Oc18P0sZgPbMhE5cQoeMzByNkEBMQSMhhWzZCPiEk ezag1TCL9VH0WF7rVSDSJ+lyQ+wt+jBk9ecfOiTPwzBvSgcdFmOID2MNpogEn5SRj0xwHwwCEozU RUf4wUwOKYQlu8UkhsTF7BbdQyc9d/HMko/phYSVP5GWsCbed4xMTZVREXOIa0hPJovo+bHfsFPE ExOec27nR29d/ZEcNzdvboIKwePmhlxW5AoZ0WNdZYQ7B0FDYLKqGDVc136dYSHWCb//K1a+xQCW 6IXEjfUNCeRcMmVWzKe3tuxnK7p1UBX6UWW3AxNZGt91e4g7OAsVJESiyapvPRS2V8Es1lfvfSKA kA9qxPmz1iJv4OML50PHTdKYrvJhOf0wX9OKxiqJJo1k3OQgWXnLux1eyIqzYbyEqZNYy/rwoUrI w6AfmV66tUL6NISoxwp8FJJPdioa4VVquxI/9qIjV8wqZpaNFAuuEUXf/8EySPycFpK+u+mHhoMe X4+StEZeym1d1GU0PiIRma1XWzxWTwKJnxDoDT8JI8VDz1/6I/LBu7siIJuChfJxc0OekBFRErFa 28LHtpWxdME6Bnnr0V2tsf9RJSPr7G7QUWkfHSEExasaZ01q7AjW8K210CfkdMpWrY4BYC7HWuUC d00uoiFYHFLD4GLk44au1MKCrI5PPvjkA7NYPL3UBa0Q8nHMNgiX2h6y0rt7nEiI8mGktPCxl4EE AYRh3ugwBYnN9B1vGYYMEmJIQITLQ2izICEPP3QJCSWsD/MSYsMml7MpPWb0xGAVMhIS+Wg5+l+C kKQRXyzq/Hsx7D9XTO5MXArJhLzhYGWwkOu9e1LIXtvAUGyhIX2w3OMnQgmo9ERiwvmEelI+/Kxz aRnrDQwt2Pl9hY6rcr3Kh5t6bJiKyD2g2GZyN7uF3X0rbIfUNYTUsQbQIMEEIkSiVtOEwllF+dSL iUL/Azd5ygIX5rBqIKLmhWJ+EypZdFc+DsneOYCwdsjWjRvyPbrz0A1b27hqIf1UR7HOnzkgz6Jy JAmEX4JuYOKdLisZNklrvS4hhxk69nKwpK1C4nH0UTpvssOOug1nhfaIFrNCKWsHpd7nTCLYCIuT WQkhSZ1XJKTvDe+l24Lb3hhDoi4UMiki2ytp1Y5+XPtbKIlTwjlCbH2hS4K+iHnDM7wB4YsUfZtg 1aIe+9m0jFXwopS9EerILSpivIQtHy/rCYH07FqX3VBFe3XZzpSSOfNc2L7+DTtnKS6CxxvOBwB5 CwJylTdh5EfGCCLJxoaxokJCk7UNm4WnhGO9orv3rMXIDoGo2byuhg8G8hrHE/moPZQt9NQZKbRu tVXTeUa/2yIhFR2ORDX3jsaQVfTkdfcUdtzXzGJ98virc28UPvMiVnrzeG5V3uNnWA9i0qEnCdFx rCAgiYJEKdEJkxjRGywHNzSEYM3UUcwg6KXrnc+dPEg6iGFrh52dB9YN+fA5COH6KTxaM6SlzGtl LB/nzXqsNFlku3+FC1yVwaF09KeMuEkrtCPEV7mraerxW8FycsFmP3z1e8HaEz3hpmKSyeo5qWhn p5JBFlWDRBqSU871Fu0LetcbKOmJcMSzOzCr2ynilQ7+LiIgb6nBckR4uIyQDeCxrYWtFYjIinCC fkjllnzMMde4TlgUEBtnFwygERxSrEImRBwgFqhmbaEpsrEu1gkrQ6rsrqMVwiW6N9j50HoY17pX FRBRi20bW9xS42Yei5sMVd/p+Orx3yd9wi/C1nEZb2X5gx6LCnIIi8Uq1u5xktNjVE8VJMkdQUOO 7icOy+u8R0E+DhhAIB0HOzGFhL3ldvyCA2n9oVd7Ax+aQB5mpk1Y6+1Ll0xd4I4G0xJVq3JQM/r7 jQ3nJC8ksYGSS+qxUBT3SfHc7ui4ePToLHDRl5Zowbdotqtg41p515SBIpEO/SZ+xov0S1ETTB/Y NL+s50sxQghOZCZTzPKzL0JA8DsIGkI+On+kKd0s1lW7AyNXbzofTooWgFcq2hxZES5W1td1enGN 44jcraRmCV3M1HpNMnplXVOKGS3kky0iI0wINVs6JQ9QRFAEGvnCDVtXYoPDq8zt1QpjyD3Ux7Zs gwi0CvnkJx1///dfPQEfvvHoM83q2RCSNtKPUeP9LCy3VT52YxCxtB4lJPFY8eJ8+LAJVt7qNr2O yM6BIeLq4bek3LtjG1qLy/pw57mNLiKOPNe7oB/PWeb1DOKIDPZmS72FzF2cZoxf7c+w0E9OXEb6 TVUyApSt9AZCElZCbi/2hK8m228ZHr4hhMmOl7UKca4rjo4k6YJwJFGjhydg6Cmmp1WMH/si97a2 4V0803P+8qHtiX2xPgQTvmaxOhlCnmM7sregIMYEEQkikkKimODe2ogbbB+Kw9pYx2aHMFpKiurI uuIB+djiclvkCw7uChD0WNQUPKlY4NBgUrmxulWzsnFY+F61jgdmTlDIusexFG2A6H6P6KT/8+P3 nna4x0KRl32QZxlnFduEz8RgfZYScnyym1WQkNfvZ1sj2YPjWXsZBUnrvAkhAYiEkLhhlgmItQsR 1i2BQDpwl0rIGyYhwWQN5gnJKkXWVQUMnAniMRie5hSES3nbRfVESOKmdHEr07iJSlznnu6zoquv ws+Hj38SuVv0JEzKX+apGVoODLL38k7Phq2YFB0T48VOhu0g8ce0Y9hHCcHeGKOEY+ett94SPngX FCR/3HS/RUJUSDZY3lpZu7W+sSGAVOC51tc4maU+C0/prshKhaPwW+vaKLSJRe+W1LhcvQZRADts qOtS9rBhIyeuuMIQZ9jRfqGmdI4Po0J8q+Of38MsL00WtOMLvX/2LHqrIB70X8rHoRKyiyXpcndo iwtzUb0NGj6f1VAVSRHJFrJ2/OHBQQAlIyJaxkoGF7Gh+3PthjzU7XmfB0I6n2eW3fa90GOleLRC YgLS32+IOByJgvgfoCG/EJZfFRO35Et4kxmUggfx0FAM35JdrpXpWPhWp8V4lyATt64zkxTdlJGB C56FF30BGKxFd0r4Lbq4kD/AJYZCCP42sZRAfgHpCb3e0kPweOvqW1flehEhpOSORnazW0rIyprK iMQQUiBJBNUtYoI3auumJVtM6Gq5KhwyQcMEw1xKR0XrwKs3tKS1RQumEd3KVVWVkK2NP/wLSr33 NJisWUQRpDY6Pnnvq9MOlRAbeD/3xmCUji80nRzTYn0WV4Lg2a692D3MIXJ436fgD7MtdM5jJds7 2DRWzmJZI8T81U5kY+cgbp4FSh5SRJ4/pI4ghOyYllhI3zE+Epfl625bFaStnLg+uJvyp9nHbDUr 31HJLEQspo4riSQBGVebzBL4MKySCkiyyVWiGzlJCXWqnkBHCsNlLe7Fg0uj/Et9fblvNkb6dDoa 3SUxV6PcRv8t6scO8QAhkJDgsy6CJNitO7zXgZR1ySFyx5l4gKJsrNvM7nqNZ8Gt6L4N0A0gwGxS 47yv1bjYQ2Tk1i9UuWOpbf+AL6BhLrfa559j23dbgbuq/qp6o1pb6Xjy1eMPOnQ5SCjzWlZ/Fsu8 BsyzY++DaPw4VgnBWUJ2j/MmK3FXjTii1XAZyW6QFScWc8dObB56CzGdXgz1XuQQu1g3/WEM6UFC fB4rbo31QkKSaGGZvN+kI3O0WqxQDIsjXdmxrOQ+ySU5dUn6J+nuECYpGTQiKqYaiOFF7oClu/Ea HVE5LjsGfc7H5eRmkOTgsIu/SzhUP5yP0bfUYdlxFRLyYj6yjLjVgpIIIwjs6+DDtMT3bicqOtS7 XtMDZ9dZt0oUXm7JYTOOq5jNqtmCQ+CCr6Dci5EsMLFVXWdO/+090ANvJT8ChtZvdXz11eOzc11x e57Yq2eJghgez47VYdkc77FvQEqLdZwQct9qWZli1mHDRt0bRkca0m1pekrIjleygng8yDJibUTV kJ2wj4NC8lDd1Ye6bcOObdwAQt7IbB+Hj3Fv+1Zf8EtBHBJX1ZaQ/tRhZdspWURiEIld9jw2DlNQ nDAVHK/FfNu7J3QueryI21PU/Xijr+pNP+l/wtHr0Lji8OdJiAjIaCsewoYh8tYL8YhuyxC56ZhA RlZW1rCL+/pGXdFA/dfGFW2zHxtd5KQvO+oqF1tardriYG+tynEVDx8VdObhr0AJc8nG59jF4Z4l FE7J4xtvdXzy91+dSgZhndenTVRBooh4+ReI+K68GtGPT9hNJx67WZN1/zChw8jQpba6a8MRE8j9 KCDeLsxqR6og/mCI0IM5Is/FYO04H8+13KtGa6e1F5Jsr8iNBB2HFlRCvsgrR6hghTgSMnvOpRUG W1eIxEiRLWtFLIr5703rWaGnkj286+2Q6G7uVr6NcOTo8KWWneFZu+Ny5tllIwN3XKzZucOzeMkV IWQ0RSRDxxTvpuLz9LijDXdaLZeRFQnp76xtYNIXbLiArGtal7u1mr5VwxBJbYv1LNzwIecQF5bp YtHVqtV2fb37FpbayvexviVu6g7PHRIIgQRhiwdRkCenHaca0eUu4SMrHyYhx8eJdhzunnDzn+Pd XSJy3OKzDjVwJB4rsxYX+hE05OAgw0faL/T4kTwLk4uGiEvIc53KehgC+o5vjeUbLPqvQzdZvUFC +rNkRN/U752Ptocn9TaExUGu1qMYP/upYKSvMhupBIfVho2QwItJ9TY8hMJVNnBwnT5/ZXTGh059 7wWs9PUFpICH/hQM1k4GDh4z4GOGtxQRYWQqg8jUVHguSrKh0V0bJJLZV3A6Zw7Dm9nSACLeC72L jfWtCleIbHFRupZztbG4xUO3ga/6mUYQ1zGOAodFcFAvXr2xrZvJbRtAVYy3VKtrEtIfS0g/tYH3 uKYwJpFEPlDldZdlIrJrQQRRJBk6yXRDPIjQWDGgH7GClSCyTAk5MEpailn540EqIRbUn0NClAuX ENMQyyC2Mj3TLByMChJkRKUgKeVeiEYGkfBjWf1oB0cx6kVCQcaIFVtep2XfJN3HIRFvhntjo5iI B5J1X+/l8Pu/s8+QyMBhr40Ufe1/Y1md4X1nOFQ7KB+8jYONGaAxM4MH8jEzMyVMBDampq5OJYjw pq/v3LwZXJZjAkTQP1xZX4+EWNtQLRfT+5YussUSka2qtz2qOqcIValVVVe2MOuOBYfV1S2uzoWE 6EyWfr8NstzqePLJV6cdyaxJMFcRFatgKSHZg3hARXaRQ3aPc1k9yel7VtqNIyeQlcxEb/uYvpNk 9MRpPQgboOyEjnosZeFuJypIqiE5BUk8VuyLBwHpD+bqBZTEbmFILXmXdaGMtEHj4jfiWj+lw0+l VkyAKFotVt+ydoU874uh3D7k/ru/sw8n3+ocjQdf8pR1EQEjqc+JSUgadUIgIaMCx7ITooxcnTFC iIVZrCm/poC4vICROzrzuxIiO6paBooTUueyW+VEWyKVms1m1bzfoSvTtwyWLXZCOI/F2ROaKe5y slrXpSFbq04IprjqHWefPJUMcp4oSMghCR56pPqhq211f8Xd3RDWD5Nyryd1dVlpKwRiooKSlLGW 1We1K2Wl8SNlxPY/SaZOnn+48/B5etnJCMgb+kuRCpIWevt740CVZYn+luAxoLeBixDpD74sqWiF pVc4Xg6SC8hJpKPXdj4s2kRIL4eovD2RbGN12ZocfRo9TAk6IxxGRufoqJ2mrjNBJTwDKnLXlwJj P9/n3/bWMuhYBhq8zfhFFWRGBWTGKJhyDckar+i3pljbillEH9VqaRjZsLIvQzp36dWtfmrWN7Sd 53TaxLf69X1StqAcui6X1a4b1dXanT/o2qlwSNZf6dh/8lj58HnexFd90cLHudNxEhREYohKCAnZ Pc601TWF2KBJQzVj737Dd1gEJ8m4yTLoWG5hY6ctGzabteMuiwqy482QeKfn8kxSSCzL2NFvkCRd jd42xirhY6AdJfnRLN7FtYeBjpcVk8zR6w8886aj0Stk9BX70Jcoso/nJSYjIlPK7Yt89LXQ8YKj L9y9+CAebyke40E/aLFwm7rKuymSMmMGSx3X1FQmt5MPeyeFJOiJyslGEke09FtTRmo6pqhRg2fD xUAK19yuxk8/sME3WnaXxzt/4MqQevgWZpCTJ09OvU/YxmXlD+MjgAI4TnaPNazv0mRlDdb9Q9/I JNl81AeyOMybFrJaYvqFx4NkCy2IB+6eP9QTE4Zyr7orPY3O887MaRC4K3OY6e1XEeHnvB0cphsD iYRktcRbIcFnycvMSqy0dVjIK8o38RL25NLTpvHcBLgIE0oG7kMVNnT5wvO0YJVKxzeg8fKHxnOR j+Xx8XHHA9eZtwyPKXmYUgm5qjIy5aEjBPY0lEy5kNzBTEpEQ/ngbb3ubgvddjFaNS371myRbs0W 0QYF2dLtTWwxlG7wYFEFlmpDPFbNTZZN/AKQL72TnvLxRcgh/pL+KhNCwIagcUIR2T1RQvKlLI0h jQBFQ7XEEsiRKkgjy8jLIaJN9Z0IyUMPIs93nj9PosiOj/O2VxB0QnDptwevSnVn8RgIFxOQrIjE 0axkbGswduMzG56kDcQ2s/HJKl/Ho1ef9KZ0cGPpXqyxj/27yEm70pOm8IyNkmN5dHl5mfej+miX Ud5efJivGh0fHYe7Un9FQJQP5g+G8xlyAVKicFA7XEtCFdht1tTVuTlVkptRSBJK1jfswlaiJZFK 2MdaFxlCS7a4hQnn4jmopYGkVuPYL1fvbiHE1+58fs9i+qrtpV19RwB5ryNkkGfPMhrSKiLHx8+y ePglKMhudurE6EhSSLoohEtCMilkmR6r1WYl9iodR7HdHTyEPISbQj1r56GFcz2HjnqscB6EzDbv gyjzdg8SDepHd3/2GMjw0R6P/hhA+tsE9VRLcpHEX6bGazDhJpDTq/nDzioIPC7r2GXAoRWLVDss ZbfQQSbwQE6yx2j6YNCMRoSWgQfffWsZeCwLG1SQmXHFQ48piAjQmJqJWFw1NDSLJIZrKgIy52aL b91J6ViJYsJIQsPFkXcO/m7ZCpIt5YN7/1gJuKbbAtVsArhSrbnVqm3YXqSmIFWuB9nfFwU5b1PH yh/nOQUJZJycUEV2jx2SxGfZ6hBbI3XYYI3XEdk72rt/lK5Lt2VTLyUhmd1PUO6146E6refBZpnH CicqjNu898UMQjy6E9XoNjYsbQxE7QiwZEmJ44uplrRSkpyHo2VaKz4N29AVdHMuP5lir26byjsq CBlpQaPTL6GU20fl6BttoUM//m8t8+4tvYMoRCwiHclb9mx8lD8wPo478gH5GFeHNaMl3ikiclU/ /1eNEtOOREFcR/wN4cNeXp3zLH9z42YOEChInXuYrluXPUR1W2C1pSrCRKLTWeh6rPpiXd18UecY a3fu6Gl1ViseQwSQsw/UYlk3PS8iIaDrFWhEEVFEHJLdk7YS0lBE9kI3PZEQIpKhxM6mk9eQBy2E 6LFj+zs8MESMD4YR81eqH7zLEdLdi/NBd/cSjcGccgykVOhlQN8L2PRn+EgUpD8ISZ6RuClKWPMe VCSKRnZzukG3V4O9riGkm7XqvIny/8JMlwOpg3i0gYNYLI8rI3Y/jisufHrBQVul3wdE6K2gHpEO 1Q8gYiSYiqichHyee1ycgnTwDi/nUmFBt/3Ohi0dCYzUucnvOvdFWa/X6hUWf32d7nrNt2nU6V9B hsvRuabEV6rDf63X7vxWZ3qrnkwkpIuCPFUF6Tj1icULNQQyEvTD6TgxCdH3dlnQStZPhX1O9hJ3 teeRRItaaaX3gAtw29usjzKvHhgiab+Qx3MarZ2dHdcQPVNhjOny4enWE0J3SwTpHiQcg9QNPBvo TtwUwXBU/I2WkB6bha4eSOkXTHkVBlu4cLVok1C4cR3PqFjsVQ2hemTZ6Osb7YtoZMqw1Iw+VY7O SEcQDvuQpwc/8nxzGbf0ktLj3zeu1ooPMxCQzDFlV0VjKtCSO+aMAjyZE9VQHZkTXhBGqCVzc1PW R7zdkkh099KgI/IM5wlF/ZdF3zUlRPngtgwVnuSwVtU+IbfD3qrf8RACc4byLyzWBx3RY73IZR37 xYq8HtDDsXtyYpWs41wzZC8pZTXSGHJ0yKB+P5fStZTVBpGP8m8kkMQjiSA7SRRJXBYPPR+0iIgJ SCIhQTD67WFgIPDRYrL8BzMT8OnsSS6PBB2Jkyhpfg+ZJD4NJ2Qo9no6Jx+9AY5RWCgvxvbxMqpw tKQOCxHL9FFvRSaIQpYUvFhWBAIomWfLpGM54MH0EQkJbOSxuACSLDFzQGROzRfZWJxjakeL5Oqd GElcTdAlqVBG1jgkz23fdTlijSdeDztmIbBXbSAFk1i2dL1Wv2f7vYcpx7WOk/3TjzFqEkq9F6nH ueaQcy3ynlvx6uT8JKMiYrOgIYe7ic1qmM/ay2T0PeuNsLTlM1lNHTpZfmG1N0eJrlh3k/UwKkjS BYGE4JKt9PaJxxI+BnqjvRrIXwZUQQIiBkq0VwMuH14bThrrbfjI1rQGW9CIRqwQdlVRHek1PoiH FhmcjgDEqJapMmqRrzupPVo2GFwaslS0HC1U5FniQTaIx7jywXw+40Dok5EXKYhbK/Na6VcRRRan rBO/ePVqS2FrvW4nPKyo56rV6r5rEE83xShi2wdhvLeim21t6Zgv4kr1Dgu921rD2tpSi3V2enrq jcKL+YCEnB8/OyceQCElI8OIN0TSud4GJUQe9rKI2PajrPkmG5wQj/alrBwdDxwStAytnx5sFh/0 2hl3bvAMAgGBfAglIgK9UJBuMVd5PgYCHwMZBYllrRwXIYqEia4LGYmQBGoKUVoCK3rGp0IYQO7r Tenoe+leXswP47RXF8DwwmM5SksbOsYT+ZiZCmzMZFVjJj5voUUlIjy96k8Wp+aEjsU5uQgi8wuL UwwkWUTqkkf09NIbarTs4tuiaGGLVsv1RI0Wpk/WuYuceyyMaZmCnJ12xE7I+QUp5PyYAcUIOQce IEQp2ZdLarXYUs9JCMu9h0dW0+L1kNc93Yg0KWUtW0/9BeVekuLVXl86ksHDGWFep4AE/fBxk+4+ SIjIB+AY6O82Q5VjInkZqfDyVbuGerbom8wF53cOKmRIiE8LhQwhvrmKBxDgAT66gUezb7TZ941w JIVaSx4XaQU+5P+eQ8Bw5Rh3PGIebz1USUYSQuTzP8eHuYQUMqFasji1eHVR8FiE2ZpfmLdAwmUk KSP1+krcp5GJXbd9qG+p39JlU77vL2fja7bIanX1js5j2coRuat37J+cYZr3XFcV6tT7s1xDxJfi KhqaPgyP/RODwxERk6Xj78dZQsxnWafwfsM50eleSog2DN1lHQSXtdwKRovL8m2CUjxgsnZCDul8 nnqsJgmhiFA6+slHBCCpWbVA4jk95PVcVh/MFLUiIW1HGaOApM9TxzWo9oqD+a4gVI+m4dGUywVY jCatjNGYr8dbYvl48Efh4g8vj0eSzomGXEeMkBwNfGdkZGp6ZGrEniFnKCOKCF6paiwGVASP+XnI yiIOfosP/6a99u2NlVt+OqsKINH9Gpk4Kn62qi3dsdd219Lz7twIgFBD5Kh3nMFidZyehmZ6S63X XruGQD3kTiA5VzDOWxTkhJ2Q3dRk7R3auUG0s65wIL7vHR5pS0Qdlm1m3QwhZLkVkZY3dhyRY8Ms JQAAIABJREFUnRYNMT52OrWQlSn0QkG63WQBEVGRixUkMJNA1NJUzFCSpePiQJLCEcUjLkjkybB6 g8kiHt3dTforRwOQNNu0+tJeRlqCyqnGTPjtrzbJpWTGndP4RaiEH7U/ZTyTzkeMjpGEi/BsUS74 2uLI9CL4mJ6etvruHIRkcc5cFfDQl3KdFzAAhxWGF+fCXOPKzY2b25sCCnb6XdGTkNxyRNb0xNM2 hGLny6nq3ll8QJd9tXrH1oRoKhF5EUDO1GKdehHLY4jryHl8BjiAxjngoHzsn7uGBEiOT+JUVoYR PXdOw8q9h2qvDu/7ltagIxPUD+R+OcCwbAHEG4lH0WQdhKmTDCOWQkiJdkJEQUIZSyWkl72Qfs0f /QPdIXe00JGTkIva6TlM8i4rt3SdVLRFJntqBZ602tWjmyVq+S8QBRlV/Wj6oMgFiHhZto1wzBgA i+OLM+Mj4yN6N6Kf9JFxVxK8y4sf/J6ZmZlEfUZm9L0pv0wldIyMjEy5Wozw9Rzfn5aLPJ2TB0FA aRBlmJubXrQniyheQSzAhSgIXi9SUSSqz5GdRdURygc2/93GGUm2wQfPsSt41HDe6Rp3xV6rOCe+ oanuaIoTU3Gf3t/eq1Rt2dXWrY4nBORUOyE2sZjkkEjLeSogJzRY5wZGTkGMkISPPfqrRtgti3oS G4g+6GtjWcjpTV8c0r6elX3LFx7ucLZ3Jw9JEBF1WXI0O81hdUNDuumyBrrbM9EKieb0pIb1IkRy dLTIyEV4xPzei/yBeyME1TezVwkdbZDIdS+SwlWiHeOChnyuR/QDvjjOO6HE3lrEI7nBZYTfCjZU XfQ1fnLc8BhJK1Uj4THjrOx9QUMc1rTAMSLaIWhMi4yMCBIiJHKFXMi7cF0GCoSET0kKyLiKN6b4 JkP7TZ5+5ObNlU2ehUTpUEIoJWt17hrvxS0d29IzU61zAoWA3EEGqSG902I9+eD01DohXut95rpx bmw8C3CAj3MkdArI+T4d1rkQwqu3Q05aUsieRRFw0ThUv6XgHO4ZJ3v3w9RiUxuGoZgFVJYjK0cW RpIo4gvY84QEmxXgMI+FTxj46KW/6kb9qruVkUvtNCTpFbZfHpIVkf6wI0oKSyIoL3Bcdh/oEPno Nf1QBYGxWtZr2qbI8THetiZryjGzKEzoZVE+4Iu4Qk1m/IJ3xhUUisiMATRCZMb5rfKC4JCAmalA gT2ORDDkbm6KmWMEiIASqIg8ygt5X+iQC/yWsDE9Pw9WFuWO+XzOr4uaUMAKsrsdV+9evXtzmzqy 6ecPvV1f4elDQQlP1QMJqbrbWjNOsK0iAZEM8ts7KABr/XeNFutjyyAiJGqnzj2Wez5HQGeEZ0pn PD+nvTp3CUlV5Dg0QxwRtAsbhGHvUPfIgow0lIxDi+xHmtObLGM1UclqEotM4DBKjlp6hjs72X6h gRFfdeolaRXi02YKcqF+5BCJfLRfE9IGkWwgScgIqFyoIsFhDVpEJx8QEMAxGvkgDc3x5ayVapPE Uz7wSV9UBAwDUYwZftJVVHhZHFFMpvHCriPT+jViQjjEWDFvjEzNeCR3PnJ0TM3xjowYHySF90RD eICEzE/DUAENvS1Oz0/PSwYhH1NkA8zQeumdQbK5icWI2yu3Nzfrmyv0W3UP7Vr1VZdVx7ltcepc 7ojNE4BKBrnz2zvbuucD9m245RmEHgtCYnSE5OFPXEHOoSByY+6gdOzvGx/7AZHdY6/1ehUL11Du hZ7sqd/iawnqe9zQeu8o0w1R4VDBWE6rvi4hLZC08Vi8dlpMdz6anTQp3ZQQ0468gFwCHG35GMiM aH0jIfknLbvNFfr7LxYSLglO+ejuHu3O6QfY4M2UIt5diIYaK/z2X6RiLPKzrv5J7qfxucd7i+MM 04t8KXF6ZBzXcf0O4oI/h1+eyjKBaKGZI+IyBUMlHFA9RsDBNMP5tOLCN+bUYemLaWjI3CLRmAMh i3NLgAS5hMld6ZgyFVkCIW/98u5dZPbNlc1tnqv9dv22OC253aqokoiKILFjB8W1ag2nW1/HmUe2 6rBYv73DvbD1HCRrHfuBEE5jnbuAJElETZYe1gKBuzrf95ROQvZPEg1JphYTSHi/Z3F9Txhp4F7D O/G4v2caIoQ0zVY1FY4DQ0UnUYSNtisP23msjIIQkVGtY2kVS48sHEbGJYUkj0h/f4zpL1ph2MJJ utA9aEjYdK4/Z7n6s4iwq9nLf+k+JUToAB+BjZfr+wke016PVWcFLISFaa0qLU6ZZOAL0zPEQh4X F/W9aZUZ2LJFPhnhV+RDCkRw9cschUIAkDxOxXBg5vA1QWSRCUQ4MVQIxJxxoU5LiJgGFnJZmp5f 4hPBRZL6vIWRNsf46M7OL99n5Xdzc3vztlBy67ZE9tu34LVuqYIgkaC+tVat1/QMuZJEtj8XQO7c q2F/FI5tVddY5u2wOm9YWuixI4ZzTyFy7J+7wTo/OYOK4JpxWcdGSBLTVUAah5Y89sx2xQzC0m+m F6IxJOT0pMF+pBar/Vg8cGhRkZ2DQMiBKohmEA/pqiADA0OOhd21U5CBMJaVDrx/Uxpp9V3pMkT2 EWNBOE9IEBD8C8u/efdoE3wAkOY4LuONl2uKs1oFPFC0WvSMAVb0dz4JUSbkgk+uyoYJiD8xSREo FAy8mlpkgQpSABamaaZIA2tWJIWXKVZ1lYARCMXItNMxYWjwFeGYmFZEREjmcVuaByrIJhlKzGHh P+S/zSwuy//hnYcPf3kXG/1u85TUOOpUEpR+b9VZ812rrW9DTbgxCqK6tUGIB3fUqr4DQJ4aHx2W Qc4z7sr81bnSQQkR/RAmhIszxHSicWZ87Gc05Hg3s2WvhvX7Rgt91qHWew/3Qk99zxGhcCgifiwn wLQOLobtfCMijOdBQTIhRPhoJnx0A44hMqLeaihxWJcS+UgH3+Mi9RcuVm/ruUI4STfWskSSye66 /WOvlqQdEeODdDTAh95ehAaLslp3or+SNxbZx5vh7/0pfNSn9NPvlEwZHXhz0cFYNI6mhBcnhz83 YjVc9v/kNjfiwqHVqmnUeonGCMCDdMxZDUuPeTJC6ZiemCcb5GJC7stymeZNOZleAizEIisk+K9s 8n+xMHL3fckhOGO73Oi2Vm6LiojJUkTq2+vb63WcJrcmkrK1fudfJIHc27bcDkLWUOY96zjVVsjH vm4qVq6Sp0bHOeu7Gs8pHftnwsd+ttx7zLUhqcPSOhZbhsFvKSI6cXJo3fSwjQNVZBkWa1nTSPMg DPryutwmqbvJMj46FQ+7qb+ihDTZCelOJGSIiAwZH1SQoUvtPFZitFw/ksGTlxWSuJNW5k4eCqEa nHgsdVgsSzetgGV8LAsYeinh1ijJ45KYKIvRi/oEaIyw17E4wvhBW+TlJq8+TREK52PKcVHtUDOF 96eVG9MSfv+0agQe+IPAA2RQM9D7Q+QgM1qronaADjdUKhwTIYYoKyWhZAI4lKkdcj9dVjyEkoUl eC55tTifIeQjufr2K8rItmQRsVrvwmzBZN1aoYqscf/47RoaiXKpSAL5PZZMrW9x4QjnfFHFevLB xx0fp810b6hnGfEYcqIuiwKi/uokxvSTXArJzPXSYhkiDWPk0N9DUYsSQpOlKSTZKcuzui3IXc5W fPMxpMVlpZQwg6jHagYFGQoKMqDScSlNIJeycGQnTvrjysO4OvflNCQ8poRkdn4YtJXyLEej5iaE 4EIFGZfr2PL4GOmQozTOTh6QmJYX04ICMVnEbUZbGjN0VtrSmxJ7JQoSC01mloKGjLDLPTJtX5gO tODZtArItL8NAMQ8wTVNKxtqqPjalGNaszjEYzq4K+MD2iGETEjwEDQmICDAQ6RDGJFbeamsdCzh frq8MIEAvxQJmUH+YAgZPxjlb0EeYrV4vvbN2+q1biGL3La6lugICBFAqpJAPr/z23u/36jZwhEs PUSj8IOzjqdCiLXSO/J8pBHdSlj7bITsM4bsQ0H0tp/mENvEgXQkNquhmpFcD2mvDvd8Uks9VhOM NCEbzTB40rTWCBvtB57XW/YJstlFtVY7Xr6KIf0geCy4+TSDUEGEiqFLVyAfl7KUpBkkzvImw4vZ PU9evggc5CRN7bEm3DuYFRDQwWO5a7yxvEw8REGWBImSaMeS8LHE8hILsfxkQzdGtOUxrp0NjddC yAgJ8QSyqMHCC1eLjsSIFWPlnWlN1eRjOv2AoyA1opkcF141kUMxDBsIiDJisSP5E4iHWi3FY57W Sh4nhJJyeWJiobwARoSN+aWlhQXAQkLkfnFpaWkcRazxmV8tLi4fdKZ7eD14eHdzm1bLGVmBkCTF 3zpKWBbRK1xsqGvX0Sg8++D046eZgd5otCIfocq7T/2wDEIszpWNjILs2trC3eN8ClHNcDj8Yc/b 6nvWDdGOOq/LrGMtExEarQMbRDloN6oVMsiDHcfkILitzp0DKogIiJV5DZGh7iFzWENMH4DD3Fab am/qtHIDvomCvGxo9wJXXkx4hx3tuge5cMX8YHO0W+lQBVE+1FkJGEuCghgs/YiLhriCWO7WNiBb ekBjkdnao8NUksDNRk1POxHe0xuZyn6q/WAlSuRiRHvjIyRozh0U1IVaMpUAlTkmjI+5CeSM8vRE GW+VIR7CRlkpWZhYmCgvCBoL0xPygG9dskCyxCKvMEIRWR7tPGjid2FTazIHD3/5PupZmyGy37LK rw81VsAHDNY6O+2qIALIk7Mnp0876LGydCSYeASxGhZ91fl+fNh3CVGzFUYWfeydLmssz0lAJOqI N9T3tNbrIQSBXRFhe6RJRI4SLUkgscFF5pBOZ6MzBBLLIMFjOR2BD+bzS6oflwZaJCSX1bOEZIpa Sav9m4NJiOmuKFFOsOmKR3QA3Wx2u350jQ8jfIxBOcpyKZWmS0REWxXUj3FxPeRlJijDjJZ0Zzxx LE4tJg6L5SmzVFNuplwz5kYCMCPhgz5HJOYUAb/aZWQ6QMFwgdThVaskgMzPOx+IF/BX81AO0Q9B Q5AAJAJHWaiw+3lisoQgQjVZskP4WBofX1xudkY+dJftnYe/+AXTuhzbVtfaXpE4so3eiPDx+R1x WNuIIzWWfrGjw7YoyJMPnj49BSHnycrbRD8Sg+WI7LuEZA7tFMacfpxfGDIWWaClioyg7qsTKFbI snZIUwlpWsuQV9a2jjyALLdUe3ciIQdexLI7CAg8Fh2q8tGMKWRIABE2KBzqtVRJ2if1/iwoyYhv KiBJhH8JHUmah1bJwoYr2FSCCtLHf131VyIgDVawxsY1nMNiSO4QGuTju8SPHbK6dTK03T0eGVkc 8RF09kGmvPwkQIRq7jQtVWCBeIyMjLRRkNDgIwIj4c7oID2MHHMJWDyEaQNjvjRdnrPcMaHSMS+u SjCYoHAQDsgGH8gLvlRegOdSOHjXACDjR6PiE0YtcfpOBMLI+5t+3AYmm8IIxrXWJIB8LgZL3FZN L+s8Cc9GxwdnT75EnfcpCDk9zwX18xZEHI+gIPvnZxlUjJBdDeq6tnA3P5WVkxE1XGgi7jVUQZjT myoSXsuinhyFqpbtEKQDv8FljWovRPshqiF82nlgKeTALJan9C65UEEoIJpBrgCMoaAhF1eyLLQn Q/BZUJJC8Isgiak97ifvRWDsaDfY3W0JHZ5QLoJHs9loDjeRPsqlMjSkVFpCBhEuliwzyIFPOaZE DBPvCnriCAJC2ZiatnrVtOcOV468bIwE7bCLXjWQx65fYqT8my4wWKIaAgZKVmqsplnXLZutKpML A4V8TFBAhBN8lyjIEnTENQSENERDRjtHDzqb/N/tiIARZPZ3FRIoyTZC+x3w8U/3tlnYwjIr1rVq tW1YrKeiINosbANHq4RkEPF4vn92sp8rZMWZ3t1cUg8l3kcpMnuHtlCECuIdQ7koEE1qSNMqvM1l C+whrOOro0FBlBEL652GxwHxOAi9wqbrh5qsoSF6qyGSMWQ3r/m2YyO6rGTleuyJRD4GXnL0Nz7z NjuWy6OG1asJxCpYPEqgQyIIEzrgwHV6Ceohn+Ql/3R7j2/GAgZbf+xqTM1YOdct1ZTl8JFYqHIY GC38gz0yl9qj+JlPdKONwuTfKlE/qB0TE8FdTTNsyDvz0IcJCEd5IeFjYVIuE5P6zvyEUiJWS2yY ATKul/Hl5dFmkyrSTPK6MEJEtoOMABDw8Tn5sBVWuMfpR7AeBID8ruP0Y868ZzWk5djXDKKXs/0Q QbyIlUZ1hBCzWYdezNptryJquDjJuKc5PcQQZWOZqbxpOzo07ayfnGT05vpymtWJR2eqIXhsVRD5 tEFChsxg4SIOK4QQ6xe2j+j9yWOy90lcMZIMNaYZ5SWcVqhtERXuuKISQj5EQJbHhI+x5Qb5KMkh FqukNSx8ltVhaQmWASSO5dpMlUqElXNVQpBBVCgWvYOeMVPx6Rw+2OKN5ko2HZIKxUVIzGVfGB6o WpWntaSLcpUQgXzOwq4CgchBSMjJpKBRlhsI0aOsN0FkKUFkfOn+uHxScAIHEGJR3QhhewTysbn5 6eb2u7c+/afPf40Esh1W6lagIFgjsiIWSyLIUytjnZ6fpysLW/PHeaIeJORs/+w8NVjZpSGWQnK7 nOB4lD56IcsKvgKJashRgwrC0d6jpF0Iu3VgV80nTQvqy26yVEc6DyysM3zAZ9nF61iJggwEBVHt UB0ZiBrSbvS9PyUkXUw1kLiu1svLKQkVBIsWNZ+7hPjRQIV3bHys1AAdZRBSXioJHEtWg7XeBcLH tMoH7memPYx7LTcyMw2TRVvmYbw9I0QDEoAnJbniCboX0yW2wiMSrjVZPCbwwyUlZN5nSaAfKFdN kI7yvMnHpKmHsDFZBhnCyKwCMrGQYFIuOx9LS4gh40sz8mR5GR0jsKGMYDuCbrNajCOfbm7e/fzX X/z6838SPrbrGUbqsFhnZ18+faqNEEhIppTVFg85zs6tS5gISGyEBA05NgHxxYVWzBoLaDxKUFFI GlbKOmoIIk0b7IVgwGfBVmGIsYlwotejZZUOWy5ixayd2DBMCr2KixHS5EAvYnoTIWTIERmgx7py 6Qopsa76pfajva11rXQZeza+p69ezmuFXMIFj8oIInqXXCkhY/I7ZIweq9SQX55leCyhZEQ+dUu4 joyEUarpRDrUVMWJkilrhi+GipOljXa1XD+MiTlXEVUEHZ+ato9+CSA4KaUMHuav9NtRskLwQDyf 0OQxYXZK8sZEwIOIkI9JkxI/lpyQMpqJDWoIZKQx7larUz2D6QjmKLrRHfnl3Zubd0U+fg0+brPh HgmpV2rbOD/I2QePoSC6aOr0tAWJPCZnqYL4xZNIJoWEnH6YHTpJBKTVZ9lGJ6GQ1TxSJqygZfud EI6DI193qP31aLJGPYkcIHgAiLAaJOiHKAj56EZIZyedCmLuyiXkUoghPuD7oiO6rv6BlI+stLxU t73feyPgw5etdKvBYkDHnIk6LEnpMFlyvwQFWdIa1ojToaO6rhckhVFDv27fszji8+z82cXQ/EiO jH6U+OkvzYU6FPvfbptKcxPJ+GEp3Nlb8/xGfN+8UCJP52mxUNPlhcXdCS9XTU4gdQwrI6BkgRZr VumYxXfNLuEqvyZmyyKngkhjXK6LjSWUwZeAiMtI09bLdWLNdeeDX4p8/Br54+5tRnZJJChr2bGN kP7kyZlISMfTEELO20ES9OOMjKiGWAxJ+MgjYhKyG/shu4bHbhSQR0lTfU/7IQ2MnOyFnH4E6ViG 1dIIwihC38WaVtOCejMmddx32lxWp9d8TUFGD8yX0tAjgyCEqIRgAksZucIogs5I0lC/kI/MBiip 8Yp2K6sn36gjPKgeqGENGh90WF1N0Y/xMfVXcpHfnMCj7Ijg4+ed7nGmdFZno5+amo6zI9OhVc52 RUjmiy0SEmwS9AMaMCEYlOa0xUcC5u35hIJgbys28U38FL9YnkcAIRxUENoruZu39GHaUVYYVDom Ya9mGdVnJz2KzFJGyrOzs0tLs0vj5VkgQkrGSQomDgIh8muRcxRcNNdsfvSrzz//7zexAlEUZHuT E7/b1j9cv3e748nTD758ekoB0TrWxXiYgpxpDjk7t/hhCtLSKdR1Uye7sZgVCNnNCkka3blQhHiI gzCX1eTQiRZ5lxNG9MSfTRuLb8bt5kZt4oR2iiHkwPSDVSwU/0ahIM2+LlWQLi1iaQoZunRlKOqH Z5BLyXxW20jS8ka7bJJRkJeK7YMMIUFBhGZrhIjBkmupMcycLpAggsBkyecRlawl9UlUEl3sEaZH MFQ47TndLrnYkaPDUrnqwASqslAQuKjSvH3u5eLCIB965aJkX0EVd9pKVcRDW+XaDoS1wh2Lutr7 ICHDVAozVTRXQgfxSBVk0ghRfzWLqN5gHpEggpvOOgslrGr1Nc1sIbdz0XVf8+C/3727uf0p8wht lo7F19fW6tvbHYLHB08khHwskHysa9NfgMiZ3VM8zmmvznRm0fvpvgA3VLKOjZCQ1Hdptx4ZFnim Tx/FuK4mi1MnAkfTiGDFl4bLyr5N5hLrjmilazkScuCSsUNSmEs61XA1Dygg2pZmJ6TLy7wmIFcu DSU2y/AYaClpvdhx5b1XDO5pWm9Vk/iim7duVrEUD5GQLlWQrnEkECEEaBAPxJBpFHz1U76ktV5V jxEWp3y4atpeQUymbdxw+gWHiUBJP/KkQGREICEBE0pHiT3weaYKXMq8leW7y6V5e3O+pI4Mw1Wc ZS/rTCJagxMTmtEXvH5lfMjnX8MHJUMVZNaUJKAit+vl67NLs9cBR7kxtiR/MWKxlmizBJEjpJHl pg0ZNSkh+P/POPLw4d27n2rh91MqCcLILeHDFMTKWDBZp98gIQIH0AAjoIOYxG7ISb6Q5R7r0NqF GQXxFVVpSUv0Y48aInzsaSnL+yHKCDqHlBTttOsOKE1buk4dUTogHgcGB8dMtIkul1FtHfH3sNV5 WeZlDLnkF2+GZBDBgNbApURHXoqWdLvSgax4tAskmRe6rV13lJAuXpqNLgqI6EcZiNBkCSXTLGRR RlxA8NG3oVytavm41eJ0gsqLQznFIkQJasWE8FGaDp4K70y4jVJjVSIeejGJmcaPQTsIz7ylc7dW 5GMhJvRhuUyaiEA+hJJr6rMmJ5UOY2PWir3Ch8QQBBHxWuBDBGSJg5y+KKDhiHTq70dJI1jH3Nvs fPj+3fc/3fx0e3Pz3W122cFH/XbHl+QDdSzdP44x/SJGzsLjvl7VW53lI0hop5vHQqU347KseegG y4OJZRFzWZx8bzYshYRqr95zGp41rKael6pJabHTUykjgEFjiFZ8TT/kzVEqSKdldOGja8hMFjUE VawroVd4yWAZciGJPDgjlk++SVDycT30EnOQ5BFxQrq0U8ga1rJcNIOMlcDGMPhYwkdvqZQWjdA6 5C4LnsunfbUS78xneTxvVQ5/UtLOR0lnpiZQqaXPkg+6XEs2SzWhL0oTPm6oJDgfglFpwr6iTXP2 PqggGTomJhMFMUAWrmmJd/barDx1szV7LcSQBVgsudgvjDLUo1Qep4T4qpkl8e2S2LktDDbfY2Dn Vq6dOxyM//T25ru3uVJXjvrPOp4KIY+fPv3d048Vj28IIpbPz42Qs7Mzm3Y/yxESClmmIYdhcYiX tNKXaSKxnL53v7G3x1KW2yw4LJeRICWgo6mzWdo4bAZEaKs6tYbFrJ50QdRjqYh0aQoJIQRoXEnQ CBpySQe0wohWmkZeGo+UkKyCpH2SgYhHKiDyrwoBEQXpEj4auAxDQBrDZT1otpaY0+2ghIQJ9bCG g3BMezfwAgUpISs4JSztlmC2JmzBhvglfNTR/cbnfkK4KM+V1F2VlYOyOTAc/MHSvH5lfr5smV4p oYJYVTe0OCY1k0/qQTSuUUGuIaHP8lkQkoXZ8gI81hKy+thsmUmk3BAhwTKysksINEUY4ZK57s4m uyK202Z388Hdu+wefnr7002UtLbf7Xj8wZfoFP7udx3WCDnVEHJxQ53uilem8/N9pSTLSGync/Ld g/pulI/dw8Rxqdl6JJe9BJFGAzLSPLIFIs0j48IVpKn7A+mELzsjy5rT05662ywRjh26LtEPYYQe SwebJPd2dfmwCTXkisWQLCY+vGgFrVj5veSr1y9cgdhOR+x5OrwVmAnKMtDvOwe7w9Iy71izgUYI IvrYcMCDiEgUYdfQ+EDVd9y66k7GiFsufsdi+/n1aXqkabQey5o6+B7+YCFhniZrvqzxoTThIsEy bbkMaso0XUoA/oiyfxGIlMvzFjkoIo5HnEZcWBhesORxbRJEiL2CWFxbuHaNjUIoyrWFhWsLsZJV FpdVngUiktfFfOICPkRLGmXVEfday/TXtsMxwzrWEug8o46hfHr73e3tTQnpHzyhyfpY+yAWQ9oZ LX0ffDgiCCM0WInHymwiZ4jY0pDdKCRRP3Iy4nwccuaEKUQQaZjNWk4E5KgZ1lXpLAq6IU1ICJzW qIkIHykeAsrogbUJsadtMwkhQkfXUMqHtgpTPgZaHgccGrdaQUwckkvhrg0l/TG6p5Wt/DYQQGQg KgiqWMKzZBBGkLESUrqmEOejzJ6hBpFpl44lDPdqZSsOIH5T8ijjukRGSkFCNGyUIAeQDFoqqgI/ /SUNHGV9R42TAAQWpglH2ZqBypJ+uay2yv3VJOCYVThmqR8SPa5dIx4GxbVZ0EKrpSaMbgtpREK6 2KzymNyN0WktjSGslygl6rV4XW7s2W9Ibk7gW5mjOfILCezist5FaUtCusT0xwghT09psLyMdZqD I6SQU4rHOeg4P4tF3pyCyO3HPpEVEDm0u8MkkWSjideyVEJEQI72DBGhI8Bg8ydqs0xPNIYkZ5FW REBGJyGxiwgIM8iBWawu9tK7coXeS5ZElBNFZSCjIWnN91JCQ7v83n5vlIHYfk86i+Ej8vpJAAAg AElEQVQN4oENte3MJeqw1GCNqYRYL2SsPFyOIiIuC+Ve+SCziuV3I2q3llxEDJHFaVeRTHAxg1Uq u8/S4hVqUCV4pdL8BIMGrhNMIPJsTlHBwWhi4kGOSiVb+FQuT8TLhA8l4gWbHjqMaEmcHsv4IB0K x3VTDhUUC+plK2+VMbsohMyi4tsgInRZ8ltkCZLbsESCY9mXzXEHqK7uPu72382RX6SQu9vvd8Bg ye1jySAfU0A0grTJISorZ4nH2tc61lmg4ywRkcwuWaFleOiERClJg8mjUMrC2lw6rAYJISLUkWV4 riNfLJLoic6bsNArKjIaTFZnSCOsYDGENKkirGMQD8vpGkFwuaKNQvNaLYEkUZEBF5W0RXJp4MJ2 CXjpT0DJjG21ZBLep1Us8NzFXuEYREQc1tLYEmpZ+LWpxxIaIjp3Ml3ySi+1Y8lW+i22k5BSwkW0 WMj85rFos4gH6ODnfl4FRD7dJYoF6DStmNBjGvgEMiAg0zZOgnv7Lk/maJkrJozjWtilw5pNBSR4 q2umItpjRyYpg5RZ5BHmkFlLZ2PCCBtGuI4RDnmQjxKG8Wi04K/UZXFyGivZP93cvv1uxwdfSUb/ knUs5HS9BEJaITk/Ow0ZREP6eW7aJCISeiGh2psLIlkBSRrt0JAGMNF2iJmshtBhnsp2zmr6ysOm Wa8DLWbpWNYoL6ojo0aKWS+dPaDD6mqSkKGuJIQIJlegIEOXrgQNCZTE6UV96ThklCVMybdftnup /1LotyfB3flIgIn7PmrBzSzWmMjIuKZ0SSEiIOInhsupkBghJXTVl7QrEgSlvZ3SUhX1omSDh0II +UAWn0ejQ6RA3oJ7Knv3YqI0YZ//UsKBa0RZ8SnntIOLzMtYLIjLhHFhGgJR0JnESeUDNFw3AdEi ljy/jpfCzuSs9wvxcyj5SgZZwC+M69CRxmwDLUSRkjElBBM6JiEgBNtg6GJmPaVSny4uaIrV2pQM 8vjL954+fsoy1qkryGmqIDGPhHcNEUjHedCPDCJ5CYnD7zbeuxvziL9wUKgie2SEiDQ4mMXhrKaX fTW1N5IgEtM7dUQkJBnMGh0NdS1qCP2VF7HweYutQh4GRnq54AiUZMGJEpLZGeXFfZNkfitoC9/g 1sGxjqU2q4sKMiYRHSkEdhu2O4nrJTNaDCMlDyK+VOSixEE8ypx3DK0MbfcxlgtwxEDd0wSomQgw BAfl2SPwknyxnMSOsiqHtsy9a24DV/RWCOjXiAPouK4S4jFEhYQKMmv9Q40hxsgsAjs4kTSCIFJG SUMwGVP9EIclgHT3dXH7py4931g3z3zMM1dCRn7+i47HgsfjJ9oq/FjHTRSEvISc2v3ZabBYPOiy cjOLJ1lEdoOKaBQJ6qG3bH9EEWFKp4Igp0NGmnuKB83WctMXVDVCYHcNaTRjqXfUY8io5Y9OKsio EMONc3SyCYwMJSaL+uHdkBfwMZA+CfMoydMkpCR1rtYokj4NUcRjPM/rw1XBxgf+dQWO5hj/X49J BoHDGjMu0jBSMjjEaHnzsK2EJO6qbFhoBQsjIvLnUEgmNJbTRdFRMaJn4HAKXDvKQUWS2IEr5ti5 FAp0TCxoS3DYWx6UjtlrHj6EEcrFNZMQSeiMIdc8rLP2ywCio++zjCLoGc4uXZ+dRcl3GITIFYRQ d3HfBCBdYW+0Xt2p2San+y8N9IqMdDzGQQX53VNVEIT0iMdpCoeJyJn3089bUkhbk6UddReR493d qBrHiX4k5axHTshhg4tDkNZdQBpeumok6tHUea1lHzpp4rkJSGBEC7wUkGaY6CUe3eqxTESuDGEc 64rermhbJMnrCR1+l/QUW0a2YmqPLZM2ChJzugX15A16rERB2AxBUB9jL0T+56uCsE8Ws/p0SX3W 0kiJEaSkeJRyGlIKE4XznCdROkRCymkvvKzrPVxBPHQkNKTRm/LRgk54a0H38BE8NHHIbTjWoxDN r7GERUJmrwXhuI6rSgr5gHxoR2TWhk6AGgABIeBEsgiGGEU/YLbKakmZ1fHbRWeNwsJSXZbW66Nv 8hffGxTkdwghoiEfn6al3ojHqROiMf0UV8BxFkxWrpAl1x9bJYuD7yGHqMs6djzahHd3WZg62Qs5 ZI+zi8CCmcTa7Hrvp6by6Xgt+S4rHJ5ERmmx9Il8z6iXeWnqh7q6hmKz8IoRopcrriIXOq0gIgkk mUyShaQ1vefVJN1CXndG7R4Y0jIvCeka6+JQb8O6hWqy1GIN68KIJdwhM1BHtOhbyi4tz4Tykpqp EsHADZYKwsHuI7oeJWoGBiOJR2kiZIwMHW2YMTQWQsOjTAWZxHWYMuI9QSUEzmqSinGNCsIHonEt VrHkQfiBfGj3UBPIsBqucCEe6B2i7CsigtuY+SyhxPOHnq5SV6b1Qq65F9mlblGQ975UQDCv2MFa 1nkmpp9mFIQh/VQd1vnpvtusNjk9s1fvrq4OsU2tY1/EjuNc+dcHT7QhwhwCJohIwxBpupyoy2Ju DzNbB/RZOpk16uqhacSuoc7LlN6d8HElFLLgtIjHS6SR9vEkvWuJ6yHfm5z0p6E9Y7sspA95TqeI jEFB4LDGhuVSHmMImY0lX8CxZBeTkmm6LVuSm5cQDklxoIuILDGMo6VnFoudwFLZlv1FOFwtUofF Y5iXstqoCS/mLuhKqAUv5y7o3PosS7rQgmuTSodWsKAfs5pBjA8+qOXCpMnk7ILB4IONEBG/zKK7 fp1NEeosWkf8nbInd82xPTUQiX70Gx98ICBfioQ8fhyXFeYU5DQT1b2JqITsn6p+JISEFNK6Gama LL261TpOYkk+qysdexpEjqwrIjyImDSxWsTKW0e+0Zz3SJbZT8SUliKSEMJnUJiQQExA0kqvMuIG KyiI26wXQ5LvJyZxJGu4LqGSlTVb/Er/pUBGWEmCSpYjEvmQa1eDUUQUZNj5yDBCSlxEpnUYXgdG fJpQn9hrdCs4fGv2CmDgCTsbrNBOUFISiRjWzsfEcHlhIpAxEWO6kmHGyvfv0VQ+QcEYZo121tcK 4g54TCoAkwuuJBbUr0E/3HHNYtLkunXag9NSHRqedURmUcy6TiURDZm1yh/iGz5akQ4/BsgG5xeG uju+evz4iUDCMhaKvba/SWDERSRmEqBx6oScnWU0JN9UP8ksUT9JCYkSEoxW9FmP1GU9ChLCIHK0 p4tEjmy1iEpJQ31X0zfSwj0GCY5wbpkD4hAI8Rji54X1EKIma8gJuUJEIhhXgowEr/WSajKQye4X XIwN0nDRpApd1hAQMUK6iEcXNAS1LOVjbHhW4CAhw/6xtskTCkhJl1NFBUHNKgwSslhFIkpevCpx qEplRC0WFGRiIjqpYUqFkuINv2GPIkrHQkADlEBPJsuGB6VD6TBCIBzXFJFJsqGEGB0W1UnJdbos ZnrzWGqzYLHKk3Rb8meTE9DBIZQxNNmXxogHCBljDTNkkH4jZBABpLufCvL0seV0EHL6cSz1niay kZgtJnjB46+9kOUDvWf5am/r7HuYzdLQHvQjmK3DICOobbnFOuRYlnUNGdmblBJtszOPeBFY6756 ltwmtwc6sB1LR616NeoaEiSEfOinLioILRYhSThJZUSPb2bEK1ztGImVrf526xWD5ep2QoiI/rvu oZRlCsIgYh5L8MBt1utZPptlF0b0oBhawfWuBytVZeKh3Y6yUkNXpdZKvmO4XA6NwWC0hhfKrhnD nMWd8PFc5YXNDl8HVbalThNxOdSsI3KNeCgfmj8mzU/NBkSuB01BF0QU5JrOpVi+92LYLApjQGRh 9jpS+3VQMtZg11B/rYw198a6ujIaMqDT04MARDLIUMeXisdjhBA1WVbLSiTkPJGQUw0hLGXFWu9Z QOQsJyH7J7+xpJ4RkZNUOVxHMjXgR4ePXEP2LKwfIa43dIixYcldrZZ3SBosZ4nPaqJlyLEsIYG3 REmaumgq1nl1XhElrCAhV1xCMncZSoKEfAMlA5diZs+1Suz24nn5UMeihAyFFCKQjMmVrZCQQdg+ nqWCuNEquc8qlTytL1nZqsSmoAOgRatS2Su7+ghnxSKWjuGGRoeBgZDNB25CMlGenKCohOa4LQ+U Y5J0zLLXITZLy7mzvNh6wUn91DOATGp9VzHJSciCUYJiFyIKXRlbiih7aR6hlMzyNmtZRPAQpyUG S/668CtFPktje4+6dFcCFZABPeMx/tKHUExEBnn81dOgIB+ndLTYLG8husMCHn/tIpJMLWZHFzMN wx/vhshu3ZEMJfEI072P9gIiGtcbOqGFopb6rqM9bSOqmhyx686miIaNA5USRQN0jHJQ8SCXQVjo 7co4LBeQ/BFDe3y4lNeWC2FJELnkI/OxrNUyyBUSCcpYA5bTzWLBYe3J/2T+OrQYil+Tw9ohGy6n lPBWKvlVL0tuqVQ7WLYql5WRkjbQJ0r602WtYYnOmKNCAkedlpoBTOTF8KSLxoIvLPdm4CyzxyTs 1aTtTzKZTLOjneHx3M3VNUcEIkIkrl+7FmmhrMxeUzqcEH28pqvX5R9AlzXJLOIH6RjDX5voL+Kc rZljt2mg2/UasPR2PHYF0Urvxy1B/TRqh/YPT01BTs9yR7s9TojHj4mI68ju7knmQrMVplFCPUuX 4qKa9cj7IRlKKCcaRY4aR4ZM7LVrYF+myVLxaJrVaqrnYgrJQZIqyFB7PC6ZlLSrakVBubizmAnv 3ohvX/rNh5AhVZBUQ8RnjY1pQ33M+Rg2vz0cGYl5PVz9otcJJaREBMCIIlK2Jrg/hpERk5AFrVMt DKuQqLmaHF4wsYDTsgESreXS8yx4s3xBp61wDZ/sa17gDZXeyYhEFo9r6rpwJyHkB6YhhgrvMCGv /XgmEaODfz38lSKfqbFHY+y96uaaWk7vxz60A/0YT+11QMxjSQh52mELCzWH+ODJqaeP81PtgZyh 2HuaM1hPWvohwWglOeQk0Y+TtLR1ktaz+BQK8kgV5H6Aw7sjhomONKp87IXeOnyWrTL0iwkI70ep IJ0ZPLq7MmWsFxyXWkXEUAkdxYtDSiof+eGUCzeU5wFChjiZ770QmCz+Nhzbk//n8j9/zMv+w6BD fNYsY7tjUiqncGQhodEqJaHDv2rTVeWytwaHy1bBHZ5ASXVYZAPXCeVjQq8LnDy0R10iyOLVsGnG wmSKB2q7qEylypEFI8Ixm7yAfpiI/EDufpDICc3aAl/NahIxRuT3SDzEoXgNU/O5Jr5LdlLXAMjj x+ylRwEJfirthVBCDBgdVjw1k+UzJy3NED8DbjaGxL6Ia4jycRwNllksSshh4rL2nIwjm9Nyk2U7 oaCe1fAZ3+ZySkhzNFyhJKNBPgyR2Cz8fixkvRiTjI4kenLlhUriAhKJyBa02sQRP0mcikiXH2N0 WnuERP3VmH4KFBSNIt4/LMVEEj/8BocKBK8WSKwCFgdxQ7fDJMTslRos1QjEbvKxsBAQ8UErRvJh 379n0mpXs/bbHgO7IZvbzV5eTzBJ2LiuDZJZ6ojKxw+cDrdbkuB9aAVR3SSEWgsN2ePfnf6PV3Hm 7k96ymO9SwCBhDx96hOLCSThUSWE7kou539zFun4a/DxZP/sCQl5sp8dy+LlN5mgblbrJCckJ14C NkyEEKSQR3t7aVo3HQlpJPCh12aYgte2SCAkXDGKFUJIjCEZi3URH0E+AiSZCJJ23S/AJJmQT9/J RHcPJH5cshDC3SVcQroQ0vfGtNjLAxIyrJfyMF3WcBJFhmMWiQ9ZCaHFyny57POGriBRQyZFPCRt i8PCc7NYw5xan4BSqHoQlfIEMkiyhpac4He/Ngb5FNcfymXSJOSHeXMVGZk1pVE6QMkP+cf8IDVb 14w7+fLsJPC4zqtkdatiIYzAp+reaCogQCScFDyxWNhfUXP6x6cpI6fZQm/g5sxa6uH4G8Fj39ff tgxmKSE/DlHkx5GUkwSP3XQ8Ky4Z2RNO9rIykvNaKibaFuEUmqoI59+Xl/MKojdnxPnQZsgfTUK+ /2L9SOKIN0vwkMnuAY+X7L/nGopeCY6ckBCaLPzWC1nd/nfL78WgIMzqIMQxUTVJF+e657InE+aw bHI9BnuLISYiE8QDTyeHqSISuuWDz48/nJZccKXbYiWXmIT2nZdzNZirwcLEYUveyFustm/AbU3O mikDG+TiB5M/5J+OPqIJCKfir/Fv5fpY4rIQ1EOf2Hag9fPxocrugHypHivLR0dQjbySQEDkXpUk TemCCC5nvKWDWb8hI78JcOyGpogxErTkZDet9z6Sq6jIIxa02h2A477NM5qgNG0FYiOYLJ5QnE/8 2qIgTefDDNbFCnIBJUZGJp9kxOWF2T2Ut9KUMpCsUByy05eoCxjKVLK6+P+5oQqSJQRGa3iYaIQm u3LCa46XiYjNcPZ97ZaTC/kKRwKHIQrDk5OiIFCR2dkJ1YYJPUGBxo5JzluRi2GmjmHbtcc+vu6J ZrXn8UMTEFOSHyYaEsi4nqdEbdYsGRE0fgjafnDtrwie4jfLGx6uz16/jjv8TQVEjJAu3aBZi1hD l1oyiJqsDj3bVEZCPIyEF9YGSfXjCSI6+Dij1SIhbbY68TRiUpL1WDGxJy7r0a4PLz7KZxEl5FAT /H3nQ3vslBDXkTSHWG89M20S+ZDrHwMjIiL/28tBEhvurck9g8bLNBatvOXRJBtHhrwbMjQUFGQv eKwy+UgQUUgWKCUEYzaCYq4rXCZwMxjyiJT1S8PgY0IlhHxAI0CHDo0MUz8mVTwoFH5GD1s/G+0V P7A0QBqxZ/3D/sPMQ2qzsmEkERG1WddmfzhpRbC/cl2a9Cow/mHXRUGuqcXCTel4NBZTSJdrCGM6 S1meQb6Cx/odV4V8/DSbQZIKlj/RgwtDlJG/SatZT/RuP9tSPznRbd9/nPVYkZGElMCI1Xs1iLiE PMrwQS4O/aky0uStESRk2e6XmwYJn4wmnZDgsUJIH/p+9FjfTEkSSFol5CUnHZNYEhsjoVMSRGSI EqIO64+a0tkOCSEE//v/anZWGwDGCAmYHTarVbbkvmAywg+8DhsaKyWPLK4zpKM8SUyGh1VBFsqT cFW2lmPYy1NGxERYBDXBeStdAzWrS2knban5rLctrmkep2T8UL1WkJBWHRE6rsfWyKRTIuLxf/By TfTjr2C5VJzczYEWppDr168zhvAQRB49SlyWhpD/n7f3aW0z7bK9A54UHNODCjyDGhhiUDSpnmjw 5iG2LBlXTjCPYzsUb4SeCOHGdgtNbheU3WD8MQKexwhqWs4XOINACBja4KLagxhNXEkN2vOyZd70 u/dae+/rumUnlT7d5+i/ZOdf1f3zWmvvfV031wVBQQ5SoVcRuXMjhPyWE+I1rN/cX5mM7IqGnOGR JusMgSSvZFlb/V201pOElBQkWiUmIMfaVYeCILKDhhwSLqsCHf/LwoiGEJv3ZRIJNOC30qDJ/3vT YlkIMYtlGvIliGRN9zIppTrXZ71Wbrjy7nuWQzD3jp9zlkKckIyP1dWyyQpK1sc0RG4/qG8aayki mHwfK3j/TlrQHfwBTxirAiF/h136Hn3x762E+/fnoSA/5DOIfLDBq/gJ7z/1yYjDkB5vmqySx/ox ZfZ1eYXfK5RENEU4Wbc6wI8I8z+umsn6MUKIIiI/bHQQFD9+YLMeYqvZrIrFQhYUxFeFpEienv89 oZPhkZyWoqFPKiDI7KVqb3Ym9T0+ZGMontdflytZIASUHBMPtVqqKG9i3vd/laI7fNYv7LUrIr/4 kvVfdFOgLIb8620h5BoCMgsFmTU45FaT65fqSHrIxhqT/frWxx3/xGrlovJX22oeCkI8QMh1lHoT Iy2FpOVgrHpcl0e5sKrFV5oj8KOfU+nf80IV+T7TD/wCFZofcNfrc7VX3z8X2pQLua5TJaAWFtM9 jq97zep5zCWytPujV7Hk2orgYZDEy/za2spfhs9a3wqfxQzz1CRk3YvFQoZ8Zb0reCkimkSe/fhj khBFxF0WbziP67f/T1IQj+l3bH8T22Ux76qHhJCO35jQ5f4K0iF30Q0GEH0hfJzdrGUpE1xIteeQ lKxWZrbi4lH9V+R1ykYWR+ysCbbpNS5qsrJilsLxLz6jxVsKIESkVMfSCDL7EHTM8wFPtS/LJJmO ZEXhb/MhYC9x/annskhicQRB/R//6i7roUvIsf4v5mX12bPW6uqzVUXEBi34QDH54XvGdYVjHZTo PQWR7106StFEB0s4d2Uey0zW391XoYCrYSRgyOUjtcwBidV17ae9XLdgi6gZXZLRjZflC7jo8mIy 0gIuLeCyjlqWJ3387i1BZV1fPF/XT5WP1o8t8pEhIv8JrzlqBBlB2+lbKsiFA3KOVgj2ec9MVsod JQkxgxUS8kqDOm5n9FlHVs4aJ6R8lrackVI1q5REXhOPYzZEkEgoIm9u5PafvOqrcYRLELl16S9e 0vrXsFxZRM9Mlqd0SoixQRV58ODPhCSsVnmVFSUkr/re6Ll/DhJqCJMI//dRQOQvKyoC/QhGWvK/ XQ6B1fVVNsaerz6PPBJKsu4isk4lUW343spdOS9BDbQGaqMweAxBI11FgxOHNkj7/Q+eNBIXSUJ+ 8DESCdNb3efe9OhuJdkIHQlUTDRaRIR4dIFGEhJ5R8Olv7FQx0pWGlnRP00SylZL9GNVGIlCFvAQ Po6vr9kJc0QefvuPdw5OD1IKMUJi5e0NSP79tzFGgMkr0oHrGUOIPJyNRfWsZ3iU5XWrZ+3lhd6b AqKEaNEXeR0O69eA49c32WB85rZ+0a6hLTb8JUvrwca/5gpiGoL/RNdmsh4EIVWQQf34Qq+VTFWK 6w9YCS533D8Nx/gc8EOUVv761+SyaLKuM4cleKz+uKoqoowAjNXn6z6z54xg/6h/0h6fHOGJmGAk TQNDQ4gP563AxQ8e1NVLoY6lFKqS6O05CXFHlU5fEP0PYwTOR37iP++uu0EaU5CxWm+X+sFvVA1p bf3YdXTkS+sAYUs7Ik/NakFMFAx8Rb6hBTx+/PFGVB88GxzHxgR/xWldXUEOksdSRHRZSJo5yUPI v+d4/JYE5NUHFxAqCPH4cPShbLJSz3CvrCGJFIsi3I8xY+Q1uyEg5Dhk5DgXEM8j/+YbznkQ+Rd4 LIZ1w+JfSnjkvcJr8KFlLCAyL3DM013VHrjJqv1pbr/JSDwl4/UgNUq+YCjloZksO1EDh/OVjuNv jkVFXEJaem2Jj9D08aN48e46jtX151lhS0nRlK2PLiVQCMcjrJZnEK1Z6diVFq5cQZ7/3QKJK4gT YIJRfhmz7f5zHWys2+qoXEG6W4HHVresId3s4iG+awLSMg8Gl6W/o7XVgc3WU/nFgktrax14yH+g Zy24rNck5FopOR4cX/v+T3rCMQHkIDNZmMd6b0F9XELGLs7Hb69+g4Iwh5ydGR+qIGdFdERKk1m6 mwP2dBi+06vdyh7rXR7Wj/VujDCJoOwLMTl+ky09zA3XT/Rbv/BmKsIcwjXr5KU8jsWgJjIySz5m wYfgMK8pfb7mWYQy8gWJ5NvSy29z61V2Wp+FJJzWQ0aRLIRcUz++eRZ8yN0QkQcN68LI6ur6U3U7 xkqpvqVtEjTa10HJejbgCHn5gS7s+3XQ8Rw8KBU/MHJ8TzKISaztyGAps7Plw7b2sz7rCNpR73ci QqHoW9IoAWJf62YSQg8Gp4XGOn57YbAlbGw9xW/5o2Z1+U/z448tICL/wTaOTUVURK6PWepXBfkr AIkMcnquvZDzO9gi6wYi5S6IOyxvpb8yj2U2yxSEjfWxIPLuU33D8WmtvGl4rIiY1wIcVu11CTmO hSOxF4o+qIYwhbjRYhz5JcfjlzfCxxvTD5Sx4LEkgtBhCSRWx1IpUWS+qK4V+z1kST3TjjyoMMP/ aW3rr0giD70d8jBcljAiDvrZNREBH/okfOAKK6PVX+QRcV6AZPX7VfVGlksQTf4pxrdYDP7BTJcA sY5GIItV2FoaVV2cs/x7ixrriQObMjdl8Y+2nntdV5P56pZldLwbw2PL3ykpfXguOfj73f4tgJQk 5EdA4ZFdm4c6pqVmTP48waSlxEgMUUSAR4sSMqDPuh5oyfehIfKParEuTi8OLkox3dbe3iCkbLkI ySsUsex6Zv4qKDlCO+RsTEFUPFREhAmKSe62hu8Gcs2Hs3KjZRKiNguyQRmhgEBQUnnrpyyxKyM/ EYl/Y/r4t1IG+SYv9Op/n1mbxprVBFLVW+0Br2avCIfVtzzFf95tpWJvPoKS6lp/1mXHltpWn/dq i6pdqIiarMEzVxCt1ehFBEQY6YrT6q6afjwXRr5/npK7IfJP63RX61yViMsPkVHkO56v/12JEoX4 ft0Wk39vIyS3EVKO6bbPVdbcTinbWx6JEKWi29+K13Lr35QPiEc3BZUWXqzz9+NqkS7clioIvu8p w36rq3UMaAj+a9Fm6X89/Q84GFxzo82/msUSSs4NEO0WKh/v35ZE5IbD+u233z6kq4d0u9FnFSj1 IqrnK0TexUIqH4OnxbpZz3pdlhBL6a9tMkshsRByHAJynFWAf/JJRrVYPyUF+VeHxETkjWlIZJBI 6VCQqmEwX5s3l1VTGclrvn8W279NL77NZSQSyYPxOP9JCXkYImIC8vCba+XjGvqh/3c3noWAtNZF P+Rg6GpXYFUuYrVWn5uC6NNTCINLiNsuqgn3YDNIWMLl2JVVq76PzmCSisxXlaTD3mzZt1ktdh0K 0rUoHcVbt1ekwl7cTCBZrbfraBhs4qL4wbr2Pp7ztSGiOtMSDem2Wv5DBLb0WSCigAyOXUHUYR2I glxEIQubkGLeZKzYO+awnJJXFkH0au4qHtRh3Sj25ojseWzX2zCF9lTPKiuIImI6EhJSEhPj49eU RH5ym/XTL57Vk+Vyi6Xy8camNx4ypovDejjPECLXqvIxn0kIpWMst39GRdxhldpDWnEAACAASURB VCQlXFdpo5Rb+YjNG3GuarNYyjKDyLNvlBAyQkSMEQWkBU6etp6ut56urj4Vn0VInquWIJaAku+9 yKUiogUu+VCFxuUDr7Ht1PNoefCF3fT+lN0On0GMaRJvf3DulgqSlan41AcYPPD7eJWzIq9uOKxu K7UNefDba/bcu942aQGvFr9dn11hf3y2IXF9o/V6Q6yWRBD1WQPF5BoF3zvirwyOCwshsFmCyNvf 7txusnI4JKDL0xn8VZIPvxyxJVJ8uKUhspctyMU7IsJZFFzUauW1rOO4/WptkWNoSCYm+cxW3hrx piGg+CmrXgUj37yBhEwwhRgi8yIh1fl5uc2rkNT0WR+q5rfmPa3j8YuHUsJx5dzcNpxyS5tEGdFz uZcQwVURQQoZCCEbrdJFDomn+gCfpZencl1XMdEj2ruJz1NLUadzSQTeWZHYjdLz9ZJwrLq/yhcJ chiRo4hsdnCAF02Jp1uRNLa8H0hr5U6qH/c+IgjdVh8f5JzgF7Y8d5QlRj5bVTaS9uhvAkgEndaP oIR35JAWBRiYqIpcKyAHIMQVxPh4y10WbwnqNxAhI68+vAcjclVSopZFSJjUb640xOTJ0PL6MFuY u6d0OCXvyhqSFMT3PYn9T45jWmusmqVxxBlJiT0XEGjIm9Qq9E7IrMChLkuuNQOjqpJRhd+ilNQC j9oDF5Qv7bjnZiv7wBJ7Vt56kMlICunms65hs55dXyNkbuh1o1ViRE244KFWXOPIamsdjBgh8vx8 1QkxGr5f/z7BsQqNeZpSxrp3B0kIruvrT+V7trIovuXOSj9Xs7OKiUTFQwemWnnk8JSurqoPMel7 7tgyOpQTg6ef7FgLv0Fra6wiLM6t+9T4wY1PLTKiitJSREAI/2PhvxsYGQglrzc3BRFVEIXDUvq5 EkKX9V6bhZ9M6ry8Ykj/zRL6Kw/nr1xIPqSkfnaU6r3vbnTW8XqYFh6GhojHGrwr17IyETkOUrxF 8qsJyvjqql+0oPWLa4grx79lWuJlLFcQL2PNziOjq4rIsY8XNcQRfaf3UJBQkS8hY2wlSVbUymvB pej+MHsGJWynu4Ighlzz519LbVYrGOnypgrSEkI0sj9trT4Xv4W6Vkru5riwvANJ/HtrNOKLJhQU kzSUuxqYCEK+KDxmdb1KhYDetaHd50ky4qCmuQomqB2mGUBlyxQlhKTf5WwW+x/d8YjiCR85fgt4 4HULlgtXljGUkNZr+W+2sTGQx9dCiPyYGY42B8/e3BEyaLJ4E/04f8uNet9+gYS80tt71Y9QkLNX ucn6UFixdzyHZLuTDo/2WPL1ZbnDJB54GLzW2+vXE47IcSpnUT3UXYGP47HNtJKKqHi8oYLQZJGO n5jQ33xjpd7wWALIX+CwlA/1WeqocK1qWavG1K5UIJ6k5uH8l/TaH+QD8g9CQdKz2ysvcD0MDXmI GJJpiHplocP4uH5GCXmGH4uZjPDH6Ko+rbKuJaw8NcO1uhrH+dPUdaeirD53jPJaVbwEI5QQ4WOV G7MrGOtpjxEVla4vZuoqH3JvmYR412PL9MOOfnsN+ejzK1vhrfoBgYcKzzEZHw6J8cGEjg/Uc+mt ZS4LF/kPtrehF5WQ1rPN4ebG+jNVkIOLfB7r1DbIQi3rTxBBG+TMgvofSgboCESi2BvtkLG0niRk yOGTozBcQyJyY+7EEMmCSDy9eZ1iCLzWGCVCwxs3WaElUcT6JRREG4VCCCyW1nkRQ6rVag31KyGE YeQBZcQmtGoPon/4+bx+CyulGBLV33jlwf1BMlqaQuJybYUsuqyBSgj+R+P/eavVp7fQR9RunvK9 Gq3VVhdqosf3U4Ky6uZLkXnKA38V4fupw7GelazWnz/Fl5+Doufa2zDR2NJf3OIivy1dpYGGNuYI szmS4AM49LODn1qxZSGkb2Xfbr/vKoLPWlvELNhIHivjxfnoMoPYZy3cHQ/9bwUR2fhRXj97tjna fPbspzsHiCAoY2U2C4wYHm9/uzma5fKhCeS3V+8/qIqIjrw6e39GTDIhQU/9lobhEXvqYwNaw73S AMqAPmugt7wdwmtyWErIa69oMahzu4d8NOsNuuroq78xJTEBEfEQDZHrMQtZ19AQuVTn/wJbRWtV rSkkVeqIvlWHVYOmaA+RhLh8fOHo77c332eOK6TG6XgYhHxrjFx7Ur9mHUsQefbEFATWWghRSFr0 4U+7gIJ6Iow8BSngpQshQCQRQgQTqsJTOe7jpX7LU+//6RtVh5YucbW5J8yZP0fcsN2tVm0XBuPi aWZ/UgZhBDdbpReDg0rieNCA5cc/BMbU8ZbLVnwF4sEM4jarG3hQaH8USlREMI7Q2tvckzyijUJY LNawIqYjhtx5+1ZvCsMnGNFqMPF4/wp45Gy8SjpypF2R8YaIGa29vK5FSI6G1JBhEKJcDNRj8RZG C0OMx6YnkUxs9HfMaf2CO6PIT04HEXnDpO51LO0UXs8ig8zPzpMPCAivQoRwoalEKQkhMePFWRQv bvmrL6puRZu9ZMGyohYeKCDwWS4her02m/Xs+smzgfwchIbg3trot3il8+5aHFEBQW4VZNaVD8Pl ueQT0ZUtLXQ9VSxUGgSY57pmVQRinZlekXiuUCkV689b69yZZIvyoU9Pu4wbq9qEaGVjJSEfmR1i x6NPYyUvPXq4gPQjuHdLX8p5u42QrVbpbWQQg0R/dPQdkQ1etDNCs/VMFOQCOR2lLC3zct4ES6fe Iql/Cg7F4xXvyscHFLBe/XE2hok5LY74fihuaIhVsrLMnsd0IsKKb7pMOB+/Mo289md9/NXzOqYa y0brF/ZFjBO3WpAQ9kGgINemIIjp8+aw9FqTS7UGj6XyUWPhFx2Sqta3fAKl5hpS0pI/ZSRtkpL7 rQcpsGftkIff5nwwqF/rwLbWsVDJ2jCftdHdMDbkWOg7H13EkS7ExARFHoSPp2gnKh+r3ae6QcjT p4qBCINA0X3+lEFDOXmKvRHk+fmqfK726qkFjW53XT7Vdod2sfW4XNfa1fMExVZ6sjoVpaMLEiAh BKHfD2q23G8JFbRcW59usHfHGeyG0bKgTkHlf5eEiDzv7fEniwqKAHIABbFmiFgttEJMQjj4bmm9 RMlbqofx4RLyh8rIK+XjfUlDzGbdltXfxR1o8LxUQ++JDA0RCsiAcf3YXJbZLMfEir0ByZtfo7le lhA4LOjIG8sgtF/wWKogqPNCQmZn/zI/awKSSYgKh1ACydBgIi/RTqxRQqqcaqyVJlC+tPhbdlb5 +l07c/vDlEK+zQgRCWEIET6eiMmSGyWkLx5LEFmhhPRxSHgVJ5V0FBJx5BqdV7UWrBKiQ+IgQ5cc reqRr0ViIUZE5Kl876o8PUeXHt+pqy20mNsFFQoQpgO1a/60G2WrW6M0g7h6KMSLftSp9PO+iUWm G2MKcgOFMoaMNVuR1bsmIaoeeKS+emlcvNXeHiocCogOYulNrZa1CpUQ3SJL/VVsA3SHcf2t40E6 wMcH4CF0yP1Mn/8Yr2VhsvdTQcQQEV+VmiPWFvGp+IG8yqL6BJOIicaxrRXxXBI2682v4woS4uF4 /EQ8rBPyBgrCwGsZxC1WFUBQQPQ2zzSCKMISsNZ8qw+yufhYXuVlrS/vj6QIkg88JlZwhtGyhlyD EHiswTUIMZe1gfiplLSUku5G1xgZo0R/mD7NPtTJ8Oct0YRV0qMEaGdBVKMr36jHfBcodckIlicp Gho6YLG6bHngSP3scWxgOBZxg5yUfVaJDWKFvP4JEclwEBicQ/sFVrzQX68/OiAlqGzsbW5uoDmy twGLpXhARzyKvD+PuXctZOFmZivweJtT8v79b2e/vT97TxVRSM7+GK/5us+yjbNuMVr2MOSUlm/w MGQMketrvwohE9YPiScXFBcXN1rHNyjB5EmAYoiYgCClT8DMi4Q8VD5mq7MwWYpIVfMHbi4luEoG 0dIvIDH1wADXfC1zXA7N58Yab+Gk1EXMhrWUEJxJ8QYhA9UQuWyky8rGSl/uIATXPiOJZ9V0a+We Sw5xGq+umi/lhew8R3BZXX0OmVhtadhYtWTxVCVDfy1ko2szUrf9VPef7IgbBoQ9xq1PexUvSnT0 fbj31hGU7M/QX6Z4tLoxDcwX+gd3AUZf/4vw6UfxWHvQj5291jM2Cg8uTELOMbZoAyeqH5ZC7vzm fLx1PvSua6vUX8nje+ED6vGKWX3/7PRs7KLDi8zq4zv4vovHd0M87Q0555tslk1mDWi2GNatIcK0 nmV2rtCN5VU5Hx7UnQ/3V9+YwfJpE5isWe2EgA/BYw4wUEDmISY1s1tVRUT1g/MoVcsjNSttUThc Q2quKpzx+jItuTGO8vBbKgh2EMbyLnVZxsf1k2ttdHlQt6y+oT8eoSKaScAJQkkr5yPdVS0SQKst JcUOe6+DbaEGBh7IAK1Ul7oRZSaftr0FEZRtDYGxGhZuXsAqvwg6ut2sOnzLJHzSjy2Gr34AE3z0 +TF+YIgTVSXZ6G2q4Wr195Y2VUGUDsvoXsyypH6OucUIIpmE2EuJIYqISsgrEY/3mkEElLNTkZBT K/emliE3l0sb946f8vMIJuvIW4hDjp6IzdIYIkIiIjJ47RLyenCcN9ZNQnj7lZO/vwYiOSUUkPGr aQgVhEfa7MNJrfPqleoxV6021ViBDqtnVaEmVeuO1GC3FJVgxFEptUqyRmL1C7uKaRDF6lk8BZbx MQs8koQ8eTIQm7XxJEmIOGxRkdaKphG5KR99iIn5mhIi5XjSLRt3nevSR8iM9vvgswICSkjX3ZVN 0n76x3uXQ4mZdLiU9F05+ma18rtnFc759rPfb1w+8I2tra7Tl33JZErh4LOGNQGjt9Hf0zByVAzu 0FpdoJZ1wZHFcw/q6IW8pb2yAFJ68d6vGtMR0c94PdvfV0rcZ5XHF4/OwmSVZuAzOIZR7vWUzpks jetsqw88qVNGwmRFdqeaWLWXeByXfNaYjFBALKRDQhjSicicCIjA0cQDTZYFktp81htBZufaEQ0n WFllqSR2fki7pNCKPQhePkHKt+NPJiUP9XTVOJHJQxMRI2QAFSkT0ldCNkiI4AJI5KG7ogFem4nd fvwUb8Ux1ErP3k2wF6u8ryKOlNoa2g2xb0bj+lNUsA3ooaObZCMpyFZkEBcRDSK4d0N+fBzlFkTC TrXwj8qkJos8LSeSRkslpLe3o1q7t7GxhwwiiByg0GtDixfn52lo8b3XsVK/8K1XseQDpQN4vKfJ kuv++/0/oCCvLs9YzXrlIURFpDg7Kj54b/3WyzAyu4SRoXmsYeQQu01YS8RqvqVBLV9bZR3EN8dj TcNf3pT5SALy5lgEZGLyG/48tioWFEQZqTZrNXDCrD5vfsuCCR8UFcyl2HRK1LTmS932BzbtWON+ EH+yPDEbZMy77XYyrFmIiEgeFQQWS/lQSMDISqgISBHt6MtNIZHnrrxasUhihsvbJv1upPlcU0pd uVbp3VbXZShrbJcP2b692vIxq+htBB7pspU9mnh0+7knc9tkf/UxBcG3teJb+yU8koAQDX3c2+kK IJs7/e7GTq/ffUpAoCBoh6h8oNLrxSzrqKuMOCQqH95gBx+/IZwDkfevTv9QTk7PFJP9s/0zecgn T9g0/FDYWXZuUjKMJ0gIw/rQKlljWR0l3wjsRkZqtidKsJnWJxiJWGKddOxCCT5mZydNQuaqvDZr c3JVRAIOkFI1QYkMr/3DGruIGN6qcVEJ5lLmfV2JkFHNc0jtz0FJSmIvcS5FM1lK9LW7LCiI4iHX J4aHZnU1Wv0Vvu7zLY6OFUADdDZSDmhlB+FYRnE+/rSAVObDClVeye0mLLrxkEJ5brK2vEXCXolF 7K6F/O74HGOajI/5rnGxyioDfSNkRy1W70g8luiIvLcqFq+nbBnCYllQVxUBItiQ1PYDiiqWoPGW Naz3lBCkECjI6atLvSoi789KLksdVpIQ3m4WtbysNYTR2gsJEZ81fG1BHQoySFiYilinvTSwlW2k dbuMoIT1hoXeiQnrSqMPggyiAlKda2oIaeJmQtJMRCQJsYkUDm5VEcaxjKQGZ0UIqh5N0Dwpg/FF WsIUYmcbfYjBseuHsyi+KR5AhNeNzY2NJys0WkAEVyUCtxZf0GzJsSJ4rGzgwFlhOHHvEcboP3nJ j9t45gG7ZYcqf9b7wRuXHWKykzTEkzyfUlonSOW/YNSMu/mv7fe7JVz6/RIie/pyZ6m3I//8Hflh QQW5cAV5oXgc0GNhrtdOGHInKr3RWrcdSt/75RUfTxFCRDxOhZFT8VmXgojez/JlIr5ChLvLfeoy fGeEeM/QFUTlY8KN1jHdltd9J8ZGGmP1IXdkLBPySx5GNIEcq8WymK4/kFVCpqpyCw1RPIQLpBFR k2ozEeKKEhMpqbPIwm8VAYUJpGaL3JnSa5bpoyR8u5J8W371kBryMImIK4gQoj5L+JALCNlYeaJO a4UlX6v7kg1ws0FKcO+mx24/Dqrkar5EKei8UiZ2sfDD1H/I+7E5DsdNn9XND2cvX8XiKiTxGwKS ebCQqdKrJFt8s7NDHdHxg51eb49VLFMRQeRcMTn3QhZqvedM6axjZW11ZnRL6q/IyCsgcnopaV0Y +QOcXGpUzzUEHUPfD+jsVp+F1SGWQ5hIlJCBe6xyFAkmJvxV5rSO0wlGbNVhph+5kLyBgEBBric4 t8FeenUqHNbcHPFQn6VhpMnRE32uRnCP/A4jpU9YgsgQz6JWlZqh0NTSHkLZ+NaDsVe3gOKJBHTM c3kXbKFKyCJLWUrIYFMQEUI2iQeN1oaaq35/g2z0zXUpKi3YLMVjBYcMfNhtlxIN+c/stJgptRz6 2frA5H7GokAcqp9mJP/+bn8r/T78G2W/e/qzMhwzlzX2BzmoO3v412ontb/X6/V2XEFeoNQbQYQS AhXhNlkGCTyWC4lR8vZ9dhHVeK/SIWTI9f0+FUTTSF7O+uCjWUcuIZ/yWNYaGbIj4lueDExHXueI JExe+wfH3kO0qd83LPh+Mw7JLzbKqxHkzXFe6UUnZHZuah58NFVC5ppxsaqW0DBXS9LhdstyPJ+0 QzJPRFDsegB4qr7bFt4+8NrwbfNct2uJnc5dn7jLBEZkrhWRxUVD5Mlgc2PzCVRkkwpiWKzo0U8p MUr8gZcVv2Ufh4akI9x/bLcyPvyHuR/VqajazX54R9RJ+vCZSzrWYyplK3SpWxKoMfbyP+fmb5hi SHdnZUdNFiZQxGgdKSBusA6Mk9PzC9WR83NucWJDJ1APPqSwDnI4tGWXfUXkUjFRd3V6Kff9U3RE LjMJ+VAoIrtHNqOFHeA/EUQY2onIXpSy3tlUllmtgWWRCT6VLmkYxQtaJiLf+M34QAVL7hNisSyD WEifqk5V5TY3Bzqq2ZWXqrmubBJl3h/m2SSpWssd81ueULJA4gWu1DTJfFbtT1LJA2wvoZPHwYci Mhgsyg0xRNP6plCyt6Kg9DZW9txprayE1bI3KZwk5fiEhpSvJVj8+AwJuWH585/9Y0+fQyQNxVvl K/NP3TE6PgdH+gNLX1pB8OFHO4XG9JRBnBAdW1SnZSLihLwHHhZHUiDRDYJKCvJeJOQPJeRUHlRB 9i+FEMkhmtdBya7elA5WsgSNwrRkzGoN/aZrDocRRcDIkHiwp+4lLZMU/9g8lzXbY4+H8ozvNyUV Ufk4PnYB8RAyO6f2ShRkDoT4Zc4oqTW1uoVkUsudVtR/syFHBWfeeyf85qrv/1D1ZmKtlqWRz+lI ftEEggs9Fq4DpUQJgc+SNCJoPFnZ06cducsLfTIcqCkruWrY2/IRlB3MN35eZ4anJCBZ7So7ZtPP 7y+5JBtWQjJy+djfJ/0N/3OX3o4DIg6r9WMoiMLxwjyWEuIOSyu959ExtLahWa33dFgs9hohGkL2 T0/3/3h1efqH+ixxW2d6G5s7ObJAYlXfW/bPysO6sWJBZCgaMrRi7wSXiRgiCZRywddd1huv+GZo 2CsumTrWkw0dX9s8lqaQqSm5VafmAMlcZa7SxLXarNRos4yQpsmKNhKbPtPoCHhlK43KV31/LX2u smNSsz0hXD70+2zb7BCTm/qht1nKCPfysiByTUQWw2U9ERV5srm3ufJEFUTvPcNjR17trKzgrg+B SnJeN1nJD70sWPhR2e3nzqqsFrnTuoWEdr/dH6cvjn8XDrF0sdEif1l3zFN9QbTxr8Y37ODmgKx0 8yqWUXKOpE6XZaWst5zLupMNLtoD4knmstRjvdf9tS7lQXPI5em+1XsRRrxnCBWx3Ry0KSJcpJUi Y4wYHO+GpiKv9TbQqO5ZHYzw7ogMfGJrIujgnBb0o8SI1XfxAnhMwGRNQj9YxpojHpW5e3MqIk17 EBiIC0iZcw1panmrNp96JVHOYqckkgnmHKsccKw+YOIHGGUJSaH9E9pBTGYfmoDonRIidOh1c/BE b3qVFPJkb/PJnjICPHrGhqGx0lMWdnDLc0nfX5VSSskrZSKSHZa3uaeShPy5s7r5K/MwXvpTu+Xb f+r35kVSiP3rVEHEYl2MX1jNEjasYcixxbcWP8xosaaFDRjfWxKBfLyHsXrPjH4KSMRjyfUPG17c zxYaFq9sMS52YfSNfMcye2ocShQBI5QQn81KMAwygxV2K8J6WqCbTi9SkpE3zOfH+nB9bSZr0hUE 8qFcqITMVWrAQt4xs1eoIggkTVaANZM0lRKONfJSzea4bHoLMyo2Qs+eSNXEouZeq5oaJbUUUewy T0TsCgm55hU5fdGSyKIisgFCBI/eZk8I2YSC7OhDT59MR1xKkpz0VzIsPlnXGjuSS3njU1//wss4 hslktXI1+mSR6ssvWualhsg/fae3s6GA/HMuILifAxIE9XN0QzB3UjJZb7ni0OF4mwiBgoi9uhQ2 yMi+vhFCyh2RvHOYds8iHeV1VYghfHgHQpQOFrMICWtasFz68O51cDKIaZQU1sucKBdM6OgkIoKo xwIeKiJCyJw6rDk4LIGkUiEUSoo+zfGZSgI0VElYBGYd2K42AWxhft4b8dXoo1Sr/m3VxIlPqERl q9wl8dn5WXASl2vPIoPFRSVkc7C5SQ3BU29zZbOnqb33RJxET+54cEp6Oyt23SE6Bs6KsVEWl08d 1f/9lyQTTovHmy9zU5+G2+jXf6++ACe9nayKlfULBY8DM1oxciIicp5k5K1uvAgNYQmYpWB1V7zy sn8KhyUPSOmnZ0wi+6j47sboydlRvlJEW+totSsoVyWrNdS+yNCCiD6w3KvbOQx9waHSUdKVVO89 LosIYHiTi8kxMojcYLGgIZOTU6ohc1OOSAWMGA/6oGzcU0j0Ta1SMy1xCanWvFtSyyip+srdWshH jVVfLsKqclSl5nDUcFPpqGaGqxqEzD/gyX5wzoZZjyEDGi36rMVNkRLSgUtvE4gIFk8IBjnpGS56 DUFxUuSw2UE62Qmj/n/7MiYgYzHmT5m06sPObZiYkaSGwGHKP1ks1uENRExEVDzOTUJEP87vqIrc STLyPm7QD5xo/f172+I3GLlUBVEp2ZfHM4xnlS7cwtfsVZHtBX9VDiNDtkYQRbKm4UDY4D2mtLwK TEQmfEstXz1iSd2H4IEH5txVQY5Bh6R0+qtJtAqnLIUQDyiI0lAxGTE4hBQP7KEjpCOWIiZFSUy4 lPjso8vJg5rvb1rz4RQL8L5w8QF48WWK8y4h81bMml2Uv75Xs1RFBk9UShyRJ47IXk8eCQW5gJzs qIa47QItkVMAix48X2K1/k9cov417qY+lfr1b4r7Ct4kuFfSd9g36b9LPu0pKPLvp4Lcgsj5AcI6 ilmc7GUSOScYFkTMYbmA0F+Fglzi5pzs/2FRXcd8z7y3vvshfFY6hbRer47G9IN99SEm4E1FVEKG TkYwoni8Axv5jnMRQ16PiQhu/sAQcjxxfeyrCkVCeDGDBUQIhGGBG/iQD+6pishjVuAiK9XMa5m0 xIijIxSJHt0S3eyU67BiilFrWqn4i0EuezEPOOYZRJLHmr2eSlFkEYiEhEBF5Kp89AIRlxAwskKz tWICgpu8buMnLPVk57ZacH+MnZ3+f7Pk5HXe8TrATURWSq/1nRbJ5J+x45/Zi94KKcE/rqc/HfpU kMOLw8OyfiCFWDfdUgjp8Cjy3t3We2OkZK6Sx0JI1zCyj3IWorppSGkP313fCf6sNKZ15ZQMg5B3 QYgO+KKepS+FENOSd6hwvYtGyUTUsyZKPstTyPEbH2Sktui44jfisCauJ+U6O3UNPNxiVVDprUM6 KhCTStNDSX6510xy0gQDgEKJmbNJxyy/V0M8khPDdsAPqp5H4uwkVeeklowW96kjHvMph0wxrE86 IZuLet8sESKPK3uOSNlm2aud7A1EpS2Y7LTtJ65facLATRmXKJt+GpO2374Qjn4/e/j8ZcX+djBW /Cu07e+0U2Jb/wF6ZxDpyz9Vv1/7IIe3uqyLc96YQmizzoGHx5H3byN92NPp20jpfrmMMKKvXrGg 5UZrbA4eVqswUNBjvxlESMnekJQMUc8CD/BW5rgY3N+9juF4XzNyPFEiJHVGwMUx8ZjQq3cKp2Yn tYo1xRAiEjJXJx7yCDCsLVKp+INXfu+pnFgf0Tru3ky0fgmzfB5MUpTXuG6sYHqLX3ngVS1Fgw0S 6AhXwKuAlEREbZYYrUWKyCIrvgAlY0Qum0u93pIgsmR4xGWFvitiiTmwnbYwsoMnHFZx7Ft1eKcf kaXEEN7sfEZN2tnjn1DyJXgQjhVrkO/wg7YV4txS9a1SJ5/19K/f0++RL8g/U/6qzwCICMgNRs4Z Q0hH2unkPOfDEjpWjZwbHafjMmJaso+4DjbQVGdPBGH9AzuG2i4sfMFhoQ12gHJ1FG5r6FejQxfi 8gl0vOMDtSVJCKtZmPeduEVBjjHDyzEtUiIPEBAoyKSWsYjHVH2urhJSk2auYAAAIABJREFUF+VQ OvSh3qSGNPNQkomJBxO/2lM16HATltORKPGdIXxMq2y1qsEH87vOe83q3VXEpmUmJ11FQMnmpsvI klypI4JIb6l328X5aIecKCVy/ENHgMgKA4kisYJKKfMJGTF2dvqpOtTPG3Lt0I92osQ7L7dx4S// jI+2WT33gpAHM1HtHWdkxf92iOf467NwJ/8+baWbxdIkUmKEMd0hyXwWGutusQwP24vx/c8KyQ04 Dqgfktb3GUb0eouEoJ3+obCiL853eGRZ5OrItwWKIAIV0XLv0JarD1OZ12mxTR4GE57XbYluWUNM QYAH9ORar2wVXk8JH5OeQVRD6spHXeCoi4RASupNSkizWakEGxULI81aJSQkKHEq5jjBhQWKKdQb MFWf52JfkYpiY8DWca/5jCNPE2dnU4SM+EX4WJycXbyeEj4mFy2KgA+XEYWkZ3FElcSc1lJ7SZFo y1XYaK+UJET4kI/0GNKjqY2f0/bDGrEEP5Z3zN3sAJ02DtnQlCAlHcv9gCQQ+d+4uGtasWYG/tAV j+ltfrSDvwsHr/jX4+sV/vV79FfyT+9pH+Two7msm17r/Jw3LFGHhnD8/Tzc1bmXeX9WRm7icYD7 AetZNFiXGMyijNzYQEuXUuljYTUtLXGhyQ5ShtZYH7KUNSQjnM0aunLEdUBQyAYVZJA2Qil5rOS0 BA4Sck0FEYtlHmtu7mtREAQQRQMXECKPrGrRZeESAsLorrHdUEHHPRhpctmVQeFPuZbE6quqF7cM Ds8fVZ5XFMuyICJ/mdUB+9n8okZr1hlZpMtadEA2abGMkBuXds9A8fhugWRHr1SQtpZ82juWQjTJ 09LLYagvd+j8zf8HIXgIJrIXQcgnKfmMeuz0Q4DaHjNYXhAwdtpt/G12rKiFkhX+il506HkYwT9b APlnYPHx8DYZKSnIqQ+dpCuHtHRRlcDz8/vTc00hb28SgqdorctV4NAF6/uvzko6chST8NwXvuCC wysh5CplEW+H8DLg3QwW6lpOyLt3w9febvc1VuRkXEEyUjSDHE9M0GPRYi1GBtEIolcQUofPUiFx Ziy7OyiGR83bivpUi567KQppsVVYtRh5LKWTqH89sCT/wOMIa8FVt1mYqRdM/vJAN7yrZngAEcGD t8XFIRL75uISCdFHxBB5wLW9BDkhFxkqbV5XrCLc1iSiP27bbJh4sautVw0qIKfP9NvWH918m6WT zF2Fy+qb4PS/TEqy7qUJU3vFM4c8t81AEVL+bViq9nI1ZHCFycnKd/YTAAqS9OPQir6HQQhLvRZF bJHheVbHOjc+tJKl4/HKwM9lOg4oIeq0tCFyeSoO65ILRaxpWB5h3MVzQQWxHVCuOKpV+BoqhPQ9 N1rYFmgQEgI9eY1536HVtLyNeDw4Rs33dkTiQosFPgSPyajzkg5FAw+8ybUh14qLSd3hcONldNTU dLn5qvBdzQrDwKKSLJhoyFyGRi05rVpszhUdEk7M6+5dPBcWNxOerwKRKdzkPmmBHXwoIcPktMRm yU2TCCXEn8uK0u4lXAgKTZfWgnuQEMGkzYNth8ohB2obTLSpMDhEcQQ7BS4i7TE6ssD+SS3JSsz2 RMUAJvgz9U8XPnryGlxSPvB365NoE5J2D8NXbXZ/hPteAZUcSAb5aGjkZLiAkBFKyM8CSaYgnEBh JsEVu8PLR6e2Tfyp05EriUCyTwnZzwu++WoRYFJ8+JCGUAo0DRFFipTVDQ/0Q7jiEBKiIlIyWiYh VueVZ6Hk+FMyYhGEHosh3fgYqcX6mvpRRwSpGySI641mA1ZLrxrezWi5lNhX7lmPxCaBmVJ05jHF +DSn0qymPBKM+OJ3Dm2BGpxhFBarWrVzYcl91q/AQ+CAjCxOJqO1OGRaX1pkEhEsVEaWlpKKKCLt cTRyVdnp8Wctp1T0AFREcMODHJc9ComafoUEDzhagQ4ekQp2zGcl8YiK7M0a8G0TYe2oMMNdMXis yG/YBpxt+wMQltpwV+q7DBn5JRq3wHSv118RQLRBunlHC1jCiNFxeFgOImayLhQPXt5Hx5B1LW58 cgoBOX1rq3XH3NWBRZF9L/jqIhFUtM72b5nMAiVFefrkyluHVz75nlyWdQ3BCFeMDAdZIHFCfDoe hKiP+hQhEyxiUUPg3lNKN4dVn6sQEhKi+tGoVOi7nIm6U+GEuNW6Z8GE7ovPEBVGFUpJBROP1kBp MpZEbvfBYGu1P7AN6nCyUXv+iz7+RQFxpzVFqzW1OOkqojqyOWIOGRIRkZJQEMpHR4CwvG5keHiX n7cQkh09sBSSHTzLkajWiz+O3XHpD2biYeWkVPddcZfVjgO9xMQthPAXtvv2S+1ph7F7x90Vygde ZYOU0PGttHc8aCgi8uvVJaJwvWPxXJ63tZsugHy8eKlMKCIfGUMuciVxk4Uo8rMLRz6aZck98MDl PEfEjJbcfrcMok/oq7/6Q6xWaXe53TMr+jot3j+UHFIwh/hCqhjMYlYHJaIfg6EXfz2ZvH6H9gjL WcdW8r1Rykp4HEcZCxlkcuQaInDIrUkFaRAHedOoN+zuyZ0mzDJ7sxIBvpk6JzHO1eRoMOIInZdO 0dc8yTezLOKTjbECngrCjbO55gp7eJnjQlaHjEyZz5qamr2emloEI0Mysrk4YhYplJBiUxVkm6l9 qQMV6YCPTma32vFQdlw7FuYRQUJFKCz20HabI9LCn9zQFloj1ZO84ut6skMMVrKVXDY2kpwVpgx3 +Nv0d/g7UcOMCzq9iCAxYwZ4e/xEXSL+FQq46siGlnm1jOU26/AwpZESJKnYixtdlfVGUOYViTn9 WU8BKldNIXZeN8sfB04LBlAwAs/hxVgk8ioXkQ9cSoWGofIhAqKnFoHHkudRWUFUMNg6fDeIRYdI JsoHc8jg3YQt0aWEaL33My5rAuOKA+VjIEeU4jFVZx2rDj78MV4KEI0KqWm6itTDXoXjyjQlu95L WaSCYFLj2ErJdKXMzr3kufEWz3Tlab1WBRZhtSSH6M6QcFqII4tTSFXIIkNcNYgUyCJAZOlI9aNY UjyASQd3EZKO0NIxBHpJU0JZ1MP30D9UG68JfkXNv2aBlbYxokVWhpQdxmQEEztM2/00CBnVLLVD Vghum1rs2HPQhF9v0yPIOW3r7NNW7bTbdHv8g/lnr7jAIYu0qSw7Pf71+1ap00YhMogIyMeoZjGP HGbtdEpIbOTw1kSDjFBRzhURwePn09xmXSSP5deQEF8ncvlqfAJ+N55guIoj1H1ZzLo6Gpa6hp7T B2a0vLIFLLxHgpovbJaPxU+4zZoYt1rqrY45zTsQAVmUEKJlLIkgcyOhY1Q3RCr1FEJMQfQTiSJU D5aCG3qrW0sxqUkuI2a3UODCk3ktvemXqrY1RLXmu6ikde8ParbsKrXddX0i9qK3s/5ozZfbpzoi s4LHlPyjwmZpQWtphIJWsVmIghQ0WcpDZ8nFo2N3fVRczGYly6VuC0841rQErO4LWb7teNgP9JWQ E6uprlAi9Id8SMhKSAhsEF8nY+VTVRYjlEM2OaBOXiywpG7ygT/K6mu0fv63oITQLuKf0dsuOh00 Cg9psg6RRADKYdiswzyHXMRk1nlGyFtL62LA3tNjEY7zAxICJYl2CO4cgt/34Syfgb/9chRdxCu7 ag4ZOR5HkUNcQ8xhDWOroKG12Dl0MphQi6USojUtc1VGibNyLT7Ly7yLk1bGGlkvnYSULg1LIuq2 LJIoGI1GE9GETXdPJe67mkle0rgKZMPmHu/Vau66as3oKWa99vnUdfd9tmxfoXkL7ErJLDERNubp shQTwUMZGYq/EkRGEJCR4MG+IRkxHVFOlighPSPGSDFM3Fe5jITpKpeGeyvuvFbC7bC57em5TfVo t/seSlbcOzFr6NFtX9mxwG0zx3jJD23Mpc0iASvOFkGoFB5E8PfZsbqb/rUUZaWDVaxCK1lisV4e vtRmIcH4yLnFw5LNipb6ubcMo46lScQFRPmAzTr1vRkvcoOVsrrigckTaIjWe6Ot/irpB6NImK6j gkEEFqswCSEeR1bNis4hEeFnhsfrTEL0iSYLMjIgGBOJlWvIyADXSbXrSCGaQUQ/iAcVpIFXDcYQ PFJNKCl1xcPbig1WuyocTmlmqSQIsRqwri/hlbjQd92zMcdcSvJw4pe0cUrVzhtXZcFXnk1EwIg6 LQR2IIJAotUsCyICQQGLVaiOFGQBtHRMQOwRTx0P7Z5F2hkkucr0zN/gME2HLN2Q9bHbK1lkh3VC RmnTU3GWOCyXGSb96go9VJ8Hvs5VEZG+dTHbOyUB6fXbNq+MyIGEvgPd6cFp9YrOjojIxp2Pwodq h14+GhqH3lXXF+eRQi7Oo5J1nuq8Vtl6j14JDJbe/czSph8H9qhXm4GHjOiWWa9Oz27mkDyQIItc ya2AggwLcVnDQq5ZwTfXEXdcgGM4zKu+sdODVrO0LwI+BqEiGR82zusKMhpNscr7dSSPRi4hikWD IOh7CgqyOlokmkbMa7FT0kwyYg2TEBYYLjVY5OMeIzw3qqs2bRylWe61e8f9AZskTCY4b9y8k6JG ax6IYBEY6GAWGeltJBJCRISPAkVfyEehDx2oSKdjtgvXpbBceuxv95KMBCu9MT6s6GX+qmcHL3yR ApC1TRBDtK+ix3xIBjhqq9sCLsCLP/xBXB+zL30i125TL9omIWzKeAbRLO4ywliuoQkJykYFthWS QkP6SyHk4qVeD01DVEsOxz2W4nGRLaEyBTn3RoiWuGxHRn+6cE74InUMD7CG6tKiiK7F1SQyvvHJ LaQcFdZWtxAyMgkpX/asi4iBlIEvHRE+JjB/MsGe4QTokOcJHUExMtAFkRAyOOZ5BCYHGkEWp0bs hHgEycDISMG7BtHQV4Sm7pqCo1++2hwrbJUqXRZQavL+ngUSpHarBquKGBzeILnlzidsNR9pZBZp fb46ZzZLb/iXqdFC11CMViFxHWldoojc5CoMKCJFh14LbEBIOtsdGCznRY6o7bEmibxp42YP7sFW kFbM7+CwZUuEHmkFhaa2tbZVG6wqxWItRw15qHsNF5SxXubeiV6KT5gv6dknWppeoY4oGOa0WKXW 2YDcH2739u5ciLV6+VEJISWHNpp1WK5l0WZZz/Bnc1moZgGVUyhIRsiBXE9PX5zyBKGn/miE2BA8 93PY14WGf9iE76eziAT1K7FZV6oiRSFoXAGP4pMqwtJWnE2aUyjYb04ZUUoGHM8CHddqsAauISIf A63zSkzXlA5CRhLSp27LH9P16YbD0YDjajCZmxcDL1rkqpvEiJZoX7FRaeZghOHyrgk+YzOxWbO2 ol6r93xfiGYaa6zmz1nLfZ4nb5ivmtmaVSmxku+UlrM0sUNEhBHFRBlZAh6b4q3kFWtYmkI6nkYA xNK2Pnc8uLfdfG2Xalvt5LTCgrVxuKJdshLOp21F3h3YKIQLIrNjk8NtBhc9uFe862j5wgK4RQ0n RI9+NglRxeIosgoXb3xYQWri/EybTc/2jtHhjcKPDOjI6BcwXCTFMaHNisnFWInriJzyhdMRKvLC FEQ3jtcIQgmxvL5/aguqdAtGFLNCQdKCw7LP0hQicFwVMd9rSWQ4Np+VQjsgYX/knS+wsrFfIeB4 MAGDNUEhGUBRJqAjiod8VSRkUsczkNGVEFWQr8t4NEJCQi1y1+XtkgamUBo0XeQCjDRSEgk9iclg 7itU88lgX4qVeoe+8GoMjprvXUcdsTQyqyeSm61OzVXnpuC0tH4teIzMZI0Q15cWQ0BEPJb41Ck0 g3ScDiWj49UsYcM/FavVht8CEtvtLJikqxy4ISv2k10PVj2KAUDbYXABMS1YCRSSZ1rJQg2uOPBZ SkNrUhlhw99KbD1U1lbaJWSjSp3pX0csYJ+NwpfOB40W1OQwK/ie6y2Ve1NHxO46onXKN6eYSPlZ 0Tg4Bx8vkEJw86R+YL0QpPRTrA+xtYYqILc6LYnrVx+uzuCxrljxHYqEUEDGuiLc+sSVhGkkfBaD +oAtdR3uHbDiO2FJRLP6APIxIfIhfAxEQlQ/5KoZZORoTBsSjWlA0nAJcRmpNFxB+G0VVoIrVBc8 Nite5ELVq9lwPUmLS1DDqlhXxApazXtz92LFVTVEJM7JUNq0Dvtu2SlI1WRJChGjNeVhRBGZzCHZ HCkkCCJa8e1pRUvrWT1FRIO7aYjWeDrJXzkfyOudXhiuXDeyNiP5gLHBcUs+8LO/zUTCQtcKp1Eg NCvtdt+qTczU7ZWULfBFXSHM9r6R0bba846VoI2iG2wkYuJvqP9ceaUKQmclAeTjS6Lx0g0XoogN +GbtEJisnxMib22KsSwh5+c8ZRXPwU4VucgQYTULY1l/7EsC0eETIeHEJeSWGZTiDCarACWa1fP1 IcOoaY2h4lpi16G2DF/DZsFpWSULj5o9BtdmsTSDTA7UYi1OjrQVUlcJqWf6Md2Y1mN/WiGZrpuS 8F4xw2W8eGKnhPARJotF4YZVhv0pW1xS8aJvxbaEoILEst2mryVp+ph8MxeTmod1kxG9TFW1KTI3 ZVlkcSrVs4QPieqjJS35qnbIRZ+gH/rQISfbeCEWyxlJqOCl2i09+jrt9ra+GVOQXtuyCQ7hHn/S 93boiLx94bhAUnC0M7G0rV/hmRuRO8kKjnQy0gtVaYeP4uG/kl7ewi4v2/ozoLdxRwIICGH8QBzR oP7yMOuqI617CknFrMAjXNfP3k28OOcOv4rHOU/NE1dCYh0RZYRRRJVDAgkU5MQIGV8tIhYLWeTK ir1XIiCFG6zwWZ7P9xImAx9qhHroOvaJqGgpI8aJPF3DeAkeqiIDOCzBQzRkpCmkPkohZNoI0QfB YEaujelQkcSLvaCiWMckCYlPb9k7VZGoauXJnWqCaq/vDDF3r8kPrJVIOHgqxfE4woqWWS09Hakw Ijoya1tSTGpYH6HYK0Ki5azCS74aRAAJCCk6HUiIkkFEcgXR6zbfd/I8sp3VtJwTt1nphUf6lTjU w0v1Laes+Oc9n2MhOm3mBupEVnLGH4i0Ye5qp90uYVFKR6YdVsUutgEIAsdLLWW9fEnB+PgSGeSl VbN8jnFcRX6OAUaM8rID4idvO72gv1JGDqgfegoSjSAHVvBlVx3lLAYRFLMgI/uvTs5ucVrFGYdO CrbUrasuiLBteKOYNXwXkNhCXI6isLEODCaoI8d+Rwg5vtbXA+Ah34dCL6tYTCEjhUMdFmRDX8zU p6cVlGnlRIGhosB4MZszi1ifpG5t+IaneDZRrADcsJASlFjfvcZhlEpsBnEP01qVuXsIKVWfAjY4 Ipy4z/K6L6zWnO5YPzc1Fz7LbJbkkE15UCFRm0UBQQpBENF6b2F0KCnIIgpNJxMScVedbY3tAU1b 32S1rKhtOSzZwUrRWDHVWLGgvWLl2pAH5O0dQoJYzfzhcGR9/fY4BalVUy5Am3hgOlP/FR2uBzlU Mj5CNjSPfITBslRSiupWzCopyM8mIKfpo4vzF3L/GTKiQQSbYb+AywIrqWUoOUSf9nmWBIy/X3I4 C+dZPzvzNzkjBXoiVxrVRTxEQq5cOQoL62gclmZ9U3OEEkIdGXjJl0Zr4towISswWYqHDpsMR9oI ETxK+Xy6ThxosECESgjuzCaOSbpakctnUyqMK2lViS01aVZ8hUm2FYQ93KvcS+t55aqo+Bp37yNC Qpo5JdVqLiIiIfNTmkfAyBT50KjlEiIisilWC5BAP3oFwIDbUiZQ1UJlS9+y9GvRvaNHV6+z3eNR pqB0sn57QsXyuputkJAxBbEG/E5mnjBKTB6ySLGTGTmfcslIaI+jkYGThY+eSZ/+c1fEYn0EDC8R Q16mam8kdZ+APzw/9I1OLkpEvIWSUD5+9gSC/X1f4NTSWswS8TjAm4tSEDmItepaxuIDO+v7SUIy RK70XtBgHQEOHTtRBRmljRedjew1d0EZvLPe+msWfAd5FMFVeyID66KrhHAWa7goCqKIfC2IWAqB hMzUnY9G4kT1gzIyBkcqdLl08PNK1IJtSEWnHRtpMiVL7jXb4NS2cKzYTKPqSLWi2T22g7BNhrJC l101hqjDEkbmVUXm56ZMQqYQ01VD9Lo0GnEwyxQEr2i0VEgKUMJHELMNTIpekhIiAj3RY1Bt1nYc so6F262SK8qyA4/7dhqsD2DilX+xXDDLPhn72k0JiW/o2McdlK63JYTs3WHwUCg+WhELj2QmFXxZ zzq/0VT/+dwqvCUheaGvsdLq1KPHuRd5L7zei5h+YLudXOoZEi55HhH6q5NbBAQRRJ+u2FUvNKqP UO8dyS2IyB7zLR5iKF6XGprJMkLsNV5CRTSAqMmCxRpqIwQZpK45XRFRQqZnpusz0/LYmM4xabh6 8K13SRputiKZVBpe72rYwCMHhN1sacMkG9+yNvu96LdzlXuVoYQnh5Mvs01yL+io2tKrYMSGGasa QpSQOST2KReSESu+COuZzxI2eFMsCmiI26tcPawU3NmmghASNEnanZ7LRq4ieRLx6O7fYUCkVoV/ 0EYVi4Vi//kfFq5MSJKP7RIj+t0dVhD8e9jRadtUpt44aoJYLgGEfHz0Um+6xvzJYUohyWj9nBe2 mD90X98X5wc8j8KLCwYQ7hvPDKIqYk31y1OPIjq+iD2udTnVq0xAypRoJatIC9XxEngcZUG9pCXJ YtmU1mDIGBJVXxByPaH2KngRj8VGutxGKiGSPlRARvXHxkddtWKG4UNfEYgZKokxUgchpV6iqYmX hs15MZw0Kj4ozOGtSlp2FXmEVS2LJbHwyrJ7VTedv5eaJVbncimZ09PFwWrNQUvm53StiFW02FgH HosQkqGE9SX0DakeiobmEBMSq/wWRIZmSx+L6Lbztg2v1THLlQWP1GXPWCl1FPk18rPjRPWMjbKn 6qHx4gRAr9CVaaPkbP0Z/1q7hES751MzbcvoRYdDNWKxLKRfvAQdcFofjQsUfC2o++hJmlx8kSES kEBD0G+HaJz72aWRRC4sg7jJskUi3PAEtzM3WXo9MQnZZ/E3icgVjZYqiCiHOK2hKUgRspH5rKMx Rrwl8i5iyIS/SIYL8QP6MRhKBAEfisjXbIRMGyJqpkRBZkCFoCJPM43phIzVtSgkdYb3fCql4S7L BMYY4ZJ3L3NZsSvyiHcW77GwpZhUONs4Z+0SbbdX7NrMOiQe18nInPKBk8vNJg0Rs2WMFIuFSojc UOxF0XfJeCisnGVoWBah27IEr1xEbleblY+kbNsxvZ2EZBwbSxeGTC9+6hsfpVxBOLKBlhh72baX 7R4/6eS/CFKhyyURlLwYhxmzwiYxNYPAS718CV9lnCgyFy+RSy7GXNZYSz1dbF8H4QbnFrlIdz29 NIOIn5D9IIYXVUgOLrlh1v7lK6XkzFqHZ4mPTEIKJHX0Q2wwS5IIJhcVlaM0d5IVtkpd9oHdEhRR 0XJEkEBQx1I8FlnoBSJqsB6bgiBr1GeUCRWPmRm9KTEGi0JBUakzss9QL6aTgpQSij1WzG/VPbsz lmT13mYzVl41fRGWSglKv0JLtWLxHVPyNjYPEUnpXbih1dKWYRW71xsd4rGmFi2IiMPStE6XZR0R uioFY8lko+gkCUGOBySY3tq2sq86re0emyLWcTdM9LN2jkZYLr7duZEfemHNcv3A777d62UV5eSp iEnPWjRQtyW2NQFOx3OHDSarQ5RXKwQEBV4tYH00k/WSs1kWSF5ardc7hnlSDxFxCTnVT075JX06 UIN1AAWhkhxQQwwMtkMubWNSiMiltUQunRDb/eTklqh+xba60KGUgJHhKK0USVH9xkW3PbG9rwcR 1SOJTBgdA1MREKJ4jNRkeZV3etpCiAiI3urkYiYpCNxVlt79TX06VbmySpfVextcVGLFYCtt4amR BMQnHY2NWoXLEm2301q03qEgHOAKr6WpRHVlTjVET987N4U4MkUVWUx4yLUYyXUJpSwTko4+Ox4F TVUgwovVtyKUGCF2/CUt0SOXFqidfv63SzklO9ztazve6oiDnw92925MjzdDA99inX59g5dL7qfs Fy1FCwRj/tu93R7XpFNABAulAzXfl/RbigdJsQUihzaYdX5+o2WYhATzJhxsvFDhOH9hp5m+sBOy 61nfUPL1bsiBb026z5Mk2BCjbu2Ansi+hxF3WleqI0KILzIcaVlLndYV2DBG8kxyg5PAo6QjEUcU FVisRXFY7rG0hjUSk6UaoiZrWhN6gzkEAqKk1PHUUGb07tEdtwjtLHLJB3KvhIw0vA4cnDC2h+mq NPJAkpZbpaUl93w8vsK1VrjP1eaaFe4HzJpvk6fqacJmqdmyvVUjq7MjInCI0VoaicnypO4tw8Kj ekHp6JEM5pTsw+1tR8PnfwOWth/Kbb+3AUpYqXYWv1NssD78thkrznzRSLH5Ekqz7eKBB+vGdCAh be/S9GLcMnU7LT4Va0UhgFxYi1ArViodWsx6GbnEUDn0JHJuOYRZZLwnAkl54Sn+xXlYLBUPkRKN 6wcXNveegsgBzkR1GWHklLNZmtP3VUtOISAn5OOENuuqwG5AxdUVhxdFOXStuoQQwcMpKRe0jhIb w2itZz2RicGgbLSgILRYi6YgqUs4XX+kGmL6wYfGNF818NbRsPTeMD6i4IV6l9xnWO7KYojdbEOI SvJa9WwqpVm+5UnepuRtfCutvrKNs8FH0/hgGEEecT4WdbBmhBwyKpSUJYkjPndCCVlO2hGgLLmC FNmTVbSsxY7Dc1vt1ra5r23DR8HAcd7zuN3Ln4KPbZivbUNKf0UbDzjeLUl0IBftTrpbNyYbirGx S19IzM8wtOxaoktutzubzCASyx0KdkM+vqS/wuNhpiEXPt57fhh4vLghI/KJnaNK9eM0k49yELHh XkXkct+a6pxiRC1r37coFSU5eeV8nDCKCBln5rLgtI5IRgEWoCF5LkmtAAAgAElEQVSIJMXw6HYN CT6ytmFJUSbtSgGZxKzJ12qypkdhsGamp4MQXhqQEEvsxIbJPWzXTGhKfbph7XaKCjuNjdSAT+ri +kFMfBx4TEJsiIuOq2JTW00GEVUQcVxoLEJKLKzP8fSLVTvBg0EyMqMFRASSotDnGM2igsh1OVkr Vw5L6gX7h0XH4NjGx9smI/lYyjbzAWO8HunbHhpMWKgSbqcs4fc44YXjni3JtolSO1UCiFCH78zX ub1zz+eiATSKDufLOszpS8WeZBAxWBQQ5eCji8bLl/6SWcRKWYdpKyBzWReJkRf8xJ60RYg+up5g WtHQk7AbHuiNxPy7N9a5Ul1rvggjLGl5Tesy81hcigv5wHBvoQIiMlKMhojsR8bIqDTGOF7x9bxe slpZP8QVRG4jFHqhINOa0R8rIYBjOjSkPsOEPqPUgJi65/dpkxF973ZLNChEJvVKGjY/zxZ7Gpb3 LVTS6Fas2s2XtVswkcBeq9xrxtSW7tSIcpf6rDnbI9vSSI0mS69TflVEpkZGCPohVsIqPIMgjy8X nZLVStIRRV/zXvzZvZ1+gAMMT/BChQUG673THkEJzET1XC8yv8TvVrHY9mOf+UIVhSS2A8OwdOYH l7YTH/HE58K05USEbhN9EBUQJJGPkUQgKS8ZSl6+9GJvzJ2cR9cQZd0xIQE6pwaLWi2mdCSRA9OQ g4PIIWiH+FYnFBCGEVUSIeYPpJF9k48TCyEqIMzqvsqQq6gY1ouoYhXp9IZZXz2LIUMbPpnMBGQy ErqWsUaCCfCYGzGFPIbNeqS30JB0sbfpXqfjUmGpoyIMF6Z6MpP5LQvz/tIHU0JJKt5BbPhK3kbl hoA4NE1QEoRoLqk2m77YvYKdTecAzJwkFPChp/LFmYJ0i6PFqVFoCHyWuSwislQsFxSR3Y7eI553 dq3qW6S43rPi73Z5Yguf2I99FxYe6NtulwyUSCgmIJQOvOnQS3mcARc9t1SBAEUqE4zeUm/bIjmf zWL1KCA6gLnSw48CySAfmdFtWNGcFl64hNhXfREVPRYmT1JSv3A0IoKQD9vB9IXB8YLuytuFKGdZ u9DO2Hbpp6VSv3ViWV0SCG5n+5FDUMsqrj5wfYjG9REy+wgF3yOEErbZh1rbssW5N2SklEUmHQrD Q7+ySI81shBiEb3+eHr6UT0U5NEMRSRjJaKJxxP6sfBcmP6F+fJO43Qa5MJ1Ok1ypdnGRuLEB+Sb jaQgQUmuKmwnsrDlqNBq2dwvnRZ8linIHDYCGzGJoJalib3wSlbBGKIeqwAfeIXn3Qgf1isxVLY7 jOlsjkTr0N2X6sQ2EkqbiFjFVtShDYVpd0wVthMMAAxxpp2Ofa7f2t623zvg61irf8nGyELKKBm+ EswcFugs1tY27xyGkTq8MAVx3TgMMoKPtMLwnIwkSC5CQ17Ypy9IycUL7vL74sISiMeQA0PEB7Ns mTrziErIJaUjzpeg+vHqhCpyckYRQUov5P6VSMiVSsjVyCgZ2jalUcy6GUZyBUlea9LuQ8VlqAsl xGeN7CIxXUIIUsgj1LEAxKNcP5J6hAObcZvltDC+GxeQlbGprulKowHHVfF+otW08mH5WEYSelLa zbFS4er2mg1y3eNoCjvu6rjgupDXtS9CRJQSxSPxgSiCDBL9wg5rvfBZu53dzGWlKa2lCO1LVvLt RGTftg+2fV7LLFjEavRMTBu2UzOFhSiFSgiBwdqOnn3m3qLA7GNh/oenPSc60Q8pojCN8lyPs5f6 q04UkI8AQUVEGyFYV/iSq27zCwN8BBHYrIuU1OMhJlFe+J5zL8jICwpIFtJZ8fWGOrdy4KnVBQ2c 1nCf9d5LyIjvEZQ05MyC+hXXqV+hITLCHvBXI/bWj0ZXw5H1EbXPfqOtbi9CRSaHGSWT+rFWeSct gVBAvtJeIfB4NP2IdKiIPHJQpkuc5JZrOqyWV4BR+dJIb7jYoDwKwGy9e73LSlwNn5H3wF5PZa1G uUPixS184mYL7UPtJVZ940ataM0hnFQtrMNojabmFuf8p4LWewt9WnIJgXh01oDJGhjZpcWiiuxm vZEln/G1x23rjFhwTyGlY7lhO+XubY0q20lnOoYFARBIOlkZudcJeerwu7MMpJQsZX/a0ph0uMiQ +20N7T21WB9RwoKzOjTxuEhQxI0rRnwdFfyVPOTTi9E4TOHd9nrwLojS8eIi0XFqk4sxuujnSEhn bPOOiMGhwf1EblCRK3TVrzyHcIVIwcCuo/CqIzrMKGhcxSC8FbjGsroarclsPdVkxBMFRjfoHLmC fA2LpSG9TgFROqYXCMcj15JMRqYzHbErp1P80YrBHFKZSQrS8FW82bCjzTjyKZmtwIQ71TVKQkIB cX9V4yL3JkWkSselXmvOClr0WbqPpC4yHs3Z8KIismQmq0AEwWNnt1hGDpGrkpIyeymyZ2k9e0iD Wtud5IOoAOCk49nEBWLbggZnIXOb5DndOQF82xSRJecwKmimF71E8BLDh35SuNESsdq8Ywe+PRx+ TDTkl0PesUDEm4YW0g9TP8R3BrIcoipiIeSFXfNirxuttC3ppUSRA/ZEPKpz3boVfE+EDnnMallX Z0aHgsG4PkTn8Gr0le7lq+tyMYIyYh7hVPwoF5I8iBCSScIxiZfaBREF8SqWWqzH4rCmHysZj8BE epiZWZi55ZL5LK8I1xlIUNjiPLAWuGbKNss775rck4pEZatRrv1yz61GriWVUnUrIkmtYqMoVTvn LrekQ2K3em/IyGiUVGTEtrrB0TFQdotiLezVMkI7NWQ3IMlAKWzB7jZjSVx6pRcOA3UDh/Z2JwRh O9Qi9o6IL26Xf5NOzBlHk4NY2ACAsLO9ZAMy+EWAqcclYT3tpFtN11ofFs1pu0qUILpbOcs3uuYK kTytJ5cVj6xj+YVddVLCxVPIIjF5Yr1ClxBzVnw4OT1zHcmCSEydnF0NrzSpi6HSlK6QYEmV8qBa MjriMCPhKEpea+ArcifjFRERfyUpPxTka22CjKbVYsFhqRjAVS24v3JWFgKKUnCf8d5J+tAVZMa6 JYmSVNuarnOIfnx9iQ2igBJ/XVpGUqpuUT/MaqnNio2E7Kw95rIsrGMN5dQcU8jIDdYoy+lyW1YJ KXbXdtc6a2sdlZFlxPXd5Y58nkZQipRJOumj/LKNQEJp8KPckod/lHgoQZBo2TbrlgFn32rN/iWO iZW+XLjZ8rVg1gTZlr+/KgjyBrOHrQNhVC8nEBMRi+pUEOT0snjk7+xqSxEzCckE5OJgbAWV73ly 6oMnpxbWcT2hybJrccKpkzNoCDcEKtRpSVrXk+5guaEOoAxtO0ZFZDTEroy3lLQyRiYpIPReQsko eazR4689g0BA5PpIcVh4NHN/JkTk0czYpdRQdELiw8SI9RhNQGJSftrwKC1O5NoSX4cYRst2E2pm TfcSKRXfKpsjvwJGpYl9UqoVrWelCyu+c6MI6kpJflk2SqAnQkqxK35rVx+EkN18UVV+OGagdKgk JS1JClE+xrc7ueiEmQpVKH3F/tD0lW1ftlKwkGUzMbY1i/8Vl0Teim2zaqKMmkEumEE+ukgcMqMf vhxH5ML67Da4aFs6iIBwKVXePMzpOOeSkOxy8CLaIbE0xBXkAGcR0a4IOyKn2FnOt3XASaQBihkt SSMwWWdmszjhe4XxRaFEfRerWuKuBJcRB+OHt2iIEzIZCqJvlA6cIyBSugiIeKxI6eqzFIf78nhX 2FgAHwsEJTmvm6TM5J6rkUZTzG0hklg9OHJKuQwc41o+ulWJjbe8qGWcZFykriLDiFa3sKa9adtA zNUSHqz5sv1jNisr9zoha5LR14o1oUJfLQOXNajIWipp5dUt/7H9+cu4B/OPeg5L4JBjVKQCVie1 LHueNxIK6YVrXM9XDxfM7ku7IomYxdJOoUV07RVGp3D8YhoSs73cL+swlbFenI/zUaLDNCRvF2aV rODjknn98tQ6Ijht2yUy+4ngcUKDpYScpMkT0uF9wysoyAj9w9FIodHVudgoCMsOPahvjrdFhpY+ KCX4ZBHDikk/JIU8nlY+YK8Ej7vGxwJAURlZ4GtPJBHds3aiNUXCbE1Hgm+Y7ZqBhNiaEu8dTjdY +805SdsJNewUiXV78l23ApESKbYJMAP7XJMnEp1j3zBdOKOZlbPCYAUjGs7XdvWhWFZYdnfFXS2v WWHL3FQ27Vt8AR4ZFKYx2yEHdFDe3sg/244D/5Y/IK0P9r9BL32zT5X52Ix+49rJboF9sT5CMT5y GcihRZLDcTyiXRJB/fAQDuuQQkIcDs9LeHiZ68XFeZZCDgwR2+3k4PQiM1gA5XeVEUIRvRHvGFJC sC73BMWsk6uTsyuvZo1wY9lXJUSd1lcqIfJ6+FUBBUFav71z6CMok9SUSSCieAQjXz9WBZnWq+IB lVhYABl35S5w3MdTILLgiNyEJBKKKUqSEBS5GrYnRIkS46TuyxPdaEV/xNa1k46GDQA3SoutfCLF TmjlezcKG/dqlblqMzNZ6IrYEMGosFsmINAQrfnqg2KiArLLetZarh5xYKbRLVwY6T8BBw/57fJn Nw5+IsKPtwv/bksUloO8WlUEE1GENoStI7JrhQSdvix2tcxrpkqnrw4/vhyvX93k5MIIgXocHhoX 6rV8JZUFd0vpF/nDRcLDoojVe72lrl1164lgybq8walxvSNiIeTVSUQR3enkpODcyZVpSCFQsJE+ Ih5XBbYIuipGRoimEcjJ2GURmcPwWBxiFCsTkK+UkJRBQMjCIzVXdxeckxl7IicLKZi46xqvAWda kmWVRookEdZnTESmuX9KWplY940gTFAimFh6t1u+TUoW3DGtxUrwnLYSK3OVIEQ3O5pKJmtU8Fqy WWt2VUwkri93NLELKWud5U5W+fWZlF0/RgOO3fT6dlq201PPxaQHGnqEowgmcvzISM9VIaFRxjVz gpqlWP1d2m4Xa3t3uDsD+yAvbS7r4hOQXMTAbxrNOoeOGB+HsFlW1Tr0Rro3CvNlIVnHEJSkGOLn oWLh91QJ+X0/NrqOvE6TFZRcnbCrbh4LOkJahgWa61/hK+qxiA1LvmM5ZJGMEI9F1xK0QYbD5LEQ QR6DD3mAPNxVQu7fX5gJRhbuGxjqux7NZK4LUN1WCPZZFB99tCVY0z6+VbeRx+lESJrVsgVX1BGH hKdkqCdCGiUdiSuntbjPljYR5+ZKKjLiNapZhROyTDwQPCSFrBkpGkk0sGsDUQu/xETD+/JuwqPI 8PDCsNeHcdvWx7BN6rIKklK4XpRx6DgI+ev84M8EJPmwzP5xlf0aoQJYzCB0TtAPbxZ+UkcOo5R1 4aPv59Y3BCIXaRL+0Ck5TGXelNSzuRPue5JXsQ7sus/Sr3UPT08vTUXQLUzlrJPiRFfh5hKSylpX piCjI878Dq9Qz2JXZLyc5c111Q19o5TouHvC4/Fo+vHXNFhKh2aQuwt3AYTAIYwIJffVZuGju1ba MunI2XjkPUU3XdPRTLSRrbrHkWlf8+7VLMsi2byWVX7tnKJe862XHzAE3Bing3m94gusdNcHEZBK lkPmjBEXkJKCrLmCIIPoFYhICpGXxTKLWnLQqeFatlQSvZLCsHAwQkZCXIryQX0zZJfkIMThRuYp Sr9VSTdyx9XR6QAuGNav2SyWiYiKCe6fdlkXtoDK5rLOgYnNZQUlJIWomLk6NxF5MY5HKIhpCHsi dtboDJb96Kuz6ousjp76yYnN+V6deM8wHjR4ML3b01c6fIJOCSq/KGaNDAl7XMzOdGhFLIkheSt9 9FgpgYTM3JXjXFAQRoCFCog9MZAwklhCWZiBmixEIMmLXKWxrelbClwNg2U6GvDsIKbNUuzEJJW0 15aFktjdtFI6PUk4rXu+X4rullKtSE4fQySrZLGaldksJ4Q3vBKvtQZIdtkmkaN9zYhYizpwdi1z 4aDsltUge8q+YBht5zykwz+XK/t42QStKP1mSVOKTttUhGXely4eF1iKzj7hZ0NIbrEOzw99uvfi PETEKDm04J7l85KCxBLcfLMsn8xiRcvH4DmkdZoxImn95MSaIgqH5hAJ7EXSkOyKtF7wnCLWHUEG AR1HmjHKQQThnLRgGnjInK4Z5LGEECgITNYjlY9HcvzfX4BwyNP9+3ajkFhRa8Hsl1a8PJ94GnmU RCTpSBoCbniCn7HliTahZYsRG6gLlxqIdlbqbC0iR+RZ8+X4bzASla0adxTCel0k9UqmIAgj2Pio nEHWbhDC+3LRAS5QkGVMokgw0QNwTWtccS1zEg/Eg834YuzYzyVkLLDn+MgfrSx0OFEJNNTv+a9b JqZ+3U3aggqvfo/EKbFYul5Kj/iPvrAwNgH6hIK8zLohXu49P8xzenirUBDqizXSX/xzMILbKddQ HfAcCc4JB08uT81tobD1uxPiXcPLkxMr9yoeUJDiBD4ru3+F3oiIh439akULmMBiHSU47MWku6z0 rtQohIRQQURAHukh/0i4uGsKwhSidmuB17sLri33PaBoZOGrRzML41ISfivP7D4BbDKCKGJ5Xd5X bCTFd9+yc8RV4nyJlSyYZDJSyuuVmNbSd6ohGSKjOfNYhIScPHZElhMhriNra8t2NeultWDNKRLj 0U7EpTPOiI8GBx6UiCxil4phiSEfbNG6c8dkQj/TQoF+sAvdQE9Tb/rHLAdTCRX8ibhrd2cXs1iH MaxrGzUc/omE+AKqC5tbhNM699a6LRWxcffD84tPJpBcRKIdcpB6IqxpUUMuT0NIcpe176OLWu4t MMOoNayr7D6yWUZNJF/xtCLaSsdU49WQb4pMROCpRgCDEjJKfHylt7rwUVdEENHvqsuS7HF3QTm4 71jIxYmg7UIsuR+VrkfKxt2sFOwdk1QJno7yL+8N3G3N7sw0Vx9OWxZp2HrdvIloG5ymcUZ7US93 DrNFVqYhlTl5FjoqKaqTj7nQkFIOsQqWI6JsGCUqHvpOxUPrWsqHHKy7eCYrgMJ/jCs5BomBEoc/ 12bxsHcXltafBDe7SscaywMFsFjG364DCePvDfGwVSxQt7WSKglUPfpEDekfMaB4yH2rX1oL/TMa Ugrq3hBJCuIRJOPmMLRkLIXkhSxfPBUnxI0bNSQpCcd80TWUnG4KwsWGQCEUJM8jePMVntVpoQqs c/FFLh43nJZ9JTks6MdXUBA6LK3zLohGLKi1Ug1ZABtI6AsBC/yVPQgmcrlLk6XvYtYx65bEUGNq vNtESuqVTCOLMJSkZYil2pYlkuS3fPikXqmM9dh9y0ZwomNaYIQaUk9BPQp5WVL/W0CyVlIRRpGC qqHvtMql6OzqgQoR0ac1foPWh+1YNvvFI5rX5bBBnk12swKVfgd/VQeH9VqHDmrZP9U2vzKKeRj+ biZXEpIwRUYOrX+jvEDxtFFIGF5+9DWEN5aC3KDDg7rP9Z5zDe5h2Cre7BUqwecW6D2FxFCWF3x9 WznHxMAQU6UtQ636egZRQjgCr4ScnuxbV506cnJCkzUW123zE/VVPKsIBk9GYGXkW2oNHRIOlzgi o2FJQUaoY7nHenT3kdaw7iocRCMgMTQUAr2Zilhm11ccTbGeCQ1X2W1lBa54VTe7hfXuugjLhhrr sSVwI69rpd3jG94baZQqvs1yU8TXjyCry1tzWYbIKBgpylnkbxFD1lxEGNQL/0D9lR6JOPZdPLTh LgepYuOMdPSDAnc9qgv3YAgyHS8Se1bhgc9IYT19cIA5Sf3IVzquaQgCQPa7d0hjx6LSGo3Vsv0D 8EvWil5by7xUEGz3EynjU50QZ4Sz8VlSz82VpXRLIiYefi/5LBs1cZN1cOorDS2GUEn2ubucC0ha JnKyzxQSdGjLEHGdZFzFM/XDCltHWDxS8JTSQ6w8HA1tbW6eRUaOi74IRh5rTpeYLng8Zp33EVLG QmauQjcsheht4b55rPsOygJKW2wy3rXS1t1UAi7NNcZiEm8dznBPLi658imu6B7Wcx0JXvLYXrep xvJQfNNv4q6ac3m9tw5C6gjq2D5PEojg8bhks4wRTyF8raJRsOZL77WGAAI08KwHLYHBY4HvRFul UET0k7VlfL4LdVlzb9XJ68bLhE7VRo7vNWiRviQVoixru1y0wv6MTlOqqGhdTf5GBeizRS1ra4Sq 0+lx25+LOOoPY2nIn1wOXUIOfXFIQsTrvBkiyoOfZORF1iy0NGI7ndjqkIuDjI4DI2Nf6eAGvqj6 XsbICScXWfDFiG+h0yclBXFcWOplKhld4UcgNtNCWh+hs05IGDvceOUK8lU5pVM/ENGNjfv3I4tk pPD1TEQTx0Qzic03PkJlGB15UrKgs16lVBIvdSfHWMw+0/BMkoZRsp0bfSLFz0uSXSvWGsnWII6d tkdZsX4hVGRUnzMFeWwS8tgh+VsW1P1ikrLsL/WgX9bZePlk13I8kvuyj3KhNiyf6aPCQMEBJWal OMCyCwLW7An8MAgV0CUN4fq7FPytdPrFPBv4AKeqIvoHE0RKHrhbplSp0UKj0E4oZQ2RWIr+mYvv 4Hth+nF+kUtIWidihMRXCMehMfLPpRXqriCpqW5K8ruXfffx8ndVkAObfj85ZRAJk1VoEjGfZdaK q9ZjBsXyemzKiHIvNi0dclVuoDFKb8BHMKL6AZP1CBd1WFARx+EGGPqwYME9WLFAcn+BOnLXx4H5 OnVKpsc6iGwi6qee2D2MWIkrfFayW5WGb5OdZuMryW4ZJM14DDXRpI6r4lEfRUekTkYeRwz5WzBS CiPhuhDUlz2+YyAFj7s0Vu6wLK3g2zSz7PIXmsBQP9iOVGFAWwU6oMf+MtPKms9PGk2qG2y97PIb 0ebXZE792I1RS/zVWQmwt5JBYnQ364R4ufezJit1Q2wfoJCMyCHnUd9NvZDIIPlupH52BFs/FZs5 pKT+u04wHmDw5MBSiFWy2A+JCAI8tKilhAgoJ5ZBQkogJCPsyag/AHUURfuGRsgoxCM3WBHRr0w/ 4LG0mX5XQ8hMSTI+oyDZO3VcyO0obLFHsmCgaA0YLZO7mW5Ml4WkYWWuBmcaWc4qr0is294oLPyW V+w6Gs2sPZLN/LqG6JPXeuv25KWselGSEDDiFd6ygvhlN/tseTeRkL6tg/uuXRWp3YSHZfc1/HDH NyKCa+hmMZlQ6DfrjW/XKFbKwy4n8te0NUNS9UsqGwW+gklkA7iDTKK7mnzMBMRXSx1+ftokEfIy W4A75rJCQayOdYi598MxSoyQkJCLWGTIgm9WywIip2q1dHbxd6eEkLCeRZ8lZCgY1JCTzGYlFZEH SSSjI05qodirOwYBEy/5BiqWP/KU/pUJCCRkwWyWBvXSxQNJ2XaVntVq3aWMsJ2I613vxM/kBa58 eaINxtvYLzbbmkFjhIhARUoFrUYWRmxr0yZXtTflWndEspYIxURySKWZJEQMFk72S0Qeq4ooHI+j kpVKWGU2/EBlDlm2A9xI0ClgSkgyXssmIPoRD2cPKh0c+CoSdFiUEFMVlydCoh5rF8KhVBChZXdy UBC8hoh4YtplBMF3wWJhf7hD2yruI7sgN9ak355CYiMg9tK9P2hBPXvLeH4YlByOzZz46imcPMS4 uEg+K3muA22ugxOl43cXEdqss8gh6ItATQSRkxuN9ShtjWxSa2QSgtWGUdVNJot0HLF4gzLvCIig iMVC1v3veJh/hyP/uxyMUjZZCB2xD1KL5G60EsEHPNd9L2k9Kq9ITCqCN+ivz7CpHivaY1Rr2k+w G1Wthp19pGmn6YkhrXwMxW9msua+rquM1HGuXyLyGIyogjyGhJyoyToJNm4wYg5q10ixbypMWowi iop9N3oUlt/doS13TBt2vSGJGgB//He8elYEEIz7SDv2EkxAPMhg5gd3l3dNQ+SP7WBvXq5BPzzk aaZig96xy3/glscQX6Eey0LyQlZapK5QuJgwgWQScpCn9Auv83KRiDVH8o2zTuGzMOKrffZYhgtG /OJOS4fgT6gkeh2XkMLa6iPdTWtkjBQjLskdDcsyMvJh3q9GJ3pgPP5KK72Pvcx7/xH65d8pGQu4 3eebW7TEP4l6F5omNqeSGu4LHH+cvg9G2E98lMGRjcXPZGEkVrXP+H5BY+2ReCqdWKFpiDgX3mPn zQkRPjSqe7+QHqsefJzAZtmBdnITjvFLwiKhtIu7tz9w9O+Gf0IM4bGO8LFMD+ZzX/p9HcSW3WX7 jXgt2Me3dV35zFj+p1sFrpN3c7iriZ7QNt+uGhnkz1eGeLfw4qJU6r2IRuHFC594P7fd5l7YFicl Tg7ypSFZxzCJRpKQ3y22nyKJ/H75uxNyidn3DJJCGZHMblGkOCtJiKLhyByhpEVGMMc4NFBGgYf3 Ca/0Jv6K+pE1QuCuwMN36ZkX+yALH64gEUbu021p1ff+QsSR+9YiYVPxboSQaCK6mjRiHMUntkoa 0hijw6K6l4BjghETWlzNXs/2DZqrhMeiguBKQiKHwGbJEfY3kY+Tv30BHI7D7ue+nLI6/NmyGTQX nSKF+GLNfBKJMn0IBrIXa7s5mU5yEXhSP3aNElSxbDufj7ap4seXMX1y85KLSK4hZrIuvKHum2S9 iMDOnB5hPeupR1Q/5Z7v5rY8gpR66r5V6e/oGGJTh99JCGtZ+6YfJ+6yrkiKCIipSKppsSvCjbSO Rl8VVsziU6hIAeultyv2xx6LjLjHevzoH6JV+B381XcGxXdlVuSDFNzHlCTZMPTj7y5gasUmVMjI XXYS78aA40xKIjNcPdLIt423143peB/lX1uCaK11P9dCxatZlUZCo9RFpIbUVUOYQep1nywoeJWb 4KE9Q/is2wzWf+qynPgx+1REnXgN6hGdl2WDqWMRxhRgN1OKgr/bbt6syS+JILxyHUkh3ZzVRyyZ um0Y6z/G8Xj5Mk/peUI/jFHeGFk8fOG7yOVcvIgiVrZAPQ/J7pwAACAASURBVNC4iKSelX4lg/yu PktTu8BxcElETk5Pyhd21V1OqCLeM+TUSYaIrh3R4SxtrxskI5cRdEjYJKGCPOa4idd5Qcdd+dF/ 97u7xsR3xkhZSsZMVx7Y+TRDJcEcMLL7fV+CtcDqVpZGXEOyRYg8L0ljxgdSmOPptWbMZ02X1yDG iUis2644qOtqZpjURTvkUVSkjiCikNQthTxmNyQldXFZa6ogf5Nj7G//NT5uaktWI1vOh75MT/yX 7Jq9uq2atpt/oHeAfJK9ZkwqdGG9WazDpAdpF8XD8VXp/3FTQbKFITb1nhNyEdXeAEUsl7zyCu+L XDzSIkM/Ia7HkNNMOTDiS1Z+P7CwfuAjJ9loll8KQ6RAJoGe6NLD8pCWvhhhA5QRttIajWCzgEXh DZACz4XycaIj7+DjsfdBkED+v9AKefjOCclexBddN0pNk2iPLBgiPuQYOmJFYJSByzs3chGibUSH U/Kwr26n2Z1u+Cl6qCH6FVt82PCxxop3SPxMb3Wer90SyVzFENHr13Mpp0sCUTxETxMi6ltw1P2X RWScj47jkOX6ZerHrhmy3YwEz0NQkyI4+sTFjaFpB9qGuru7ng2d7fTDbJPRl7fsa/IftyESJ4nm cGK2LMQweRHbOZjDihW4aSArrZziVK+JyMVBLiD5nJY+/I494fd/PwUhVs0a1xDIB4xW9EVudNkR 2NFdH7qIqKOy3qBpSEH5kOevHhcuIY//AR7r7iMc+f/zfpmHJCDBR9z9ZcrvWbVrJkWUmONauOuz Wma58nWIWfk3LWif5lZ00V+3bbamucmWNddjrweeatcGURrcp7EOUPACWcQJwVUFxIq9RgcJUf2A jqiGfHkc+d+45F2X5ezToiwUpcRBEE5KT2tr+2vZV/bj23eL3aU7xMBTOgyWnZXtthTyHzki9k0x +J51zBnW89F3L/eOtwwjo2dWy/Y7oVZceFj3ku8lozoSu9ayftfWyGVKIjcYgX4gtp8RE6eE/RA1 WVc4+468HiKLqIowjBRDlHbZIEFE19r/VxZBVEMQQR5JTB+DY0xB7t+Uksx9ZZC4ukBDOLslr+/q u7sL1nCHkDxyIpLTirUjOn4yk5aO2OrD6RhqLM9qmYz40hGsHmlSQBQNIlLXd3O4Z7Vetk2ZRBSP x1bpjWPvv2i0PkXGDSVYzhkY78PsOknBawauYrHPD0jLCdvs2nK00x/4cltblh5W61YJKV8SH3Ha kIusQ+jLQg7PY9Gtr5oqxZGAI06uk8+fHOTygSesntrXGKJ5XXMI5MNa6xkfmeG6MlC0tnWVOohc cZiW6NoqERS1TEIKq2BBRkCH6AfGTR49Rhvkf97XjH73u3EJGTNZ9++XZYX14FTiSg0TezkTD9ly q0exfCSzWvnmKD6OYqdvT+F9JkmJ5RCedKRS4iOf9/WtTEFHJiEJEfJh7fTHRgd05AQSEsfh/ylS chwKpo/Sl3OdGUNjP5OL+M1U+mymUn/pndhKMWKIzypejLFB9ciyuk1v2cJCa4bY/ooWRl6cvzgv bXLyguf2JB2lLeTGF4c4G//jIMSkTAua679jqaHwcfk7ZrPGJIQDWo5JarMX3iEJnzXi+KLPMF4N bQcoglJ4l1B1RmLIY1qsf0AE0ct3kkGCCL74zt+P8TL+cqGkJElCUi9RWyL3bR8INA8ti8TJFqbH 88iMnbBnupHOs9to2DnfXEqy/YIMkSyv2zmstDdSr9BkKSWUkLmvUcWyUtbjVMk6ocsSPmCz9GDc /9u+H4r748dkHKf/rZfb0nnpzy0yj8VX4awY1v9/1t5ex5E0yRYsYICcaLCmMLMUCIwwQgBDfeVA bi2YjGDdYGOfISSKqd/HaBCgTn+C4HO05itQKZQSwLri2gjNyB4672dm55jZ52RkVe8uf50/EdUz 6SfOOfYrDLLTwz//MKS6koHTGpgoHNHINYMcvHPKV7O5U/d5WR7M2rLi3cctbr2stx753qcmw9qI hGUnPBrxIZIUaSWg1QmT3EQJLXurLeyKkZEXAUy+3okXMc/+rizyV0PGVx0a/82DvIBIMelFYi3t 5iKKKBnhhWYkRNY4qxjZkUglAjHTuakupZApEu3TG/W+MRob+xJjvJZqLs6hQx1K1DGirvE/mSH5 GZMa03iUz+QQRYj4kNVXMet2fZFH8SGtWhANZ5XHXbm9rPUsFMCUg7j66fv/h2H5MLFS/hdQ9zmZ reO/Ko/dy8vYwHz9Ifz5IQik5wrPWyrrkiiEFVlgkAPz6GrStyx978EjmJK1zWvZ+po6qKtcax39 jUQgjfoQ5ZCmK8eCkFOz61qXWFcQyXRiUDEzEqW+IBDlkDs9sCSYouSvrDSRj9u79g4uvZh0SKxp QAG4cAYJxkjvjnikEle38+7e7q4kYjJrWpWhjJpH7rFpgS0kNvbXKlBSWAuDHhQquqBHXcl//idm bFF4GUL+T43yItQLjJTb12AR4w+BiJ6QazslCQ9BhJyXSXHt4nH3cnX8/+FCX9G+MGbgH5X/CWvn N4IELxQcVofyoks8uR19v48EiGfVK4l1TSFpqQ66QjDK+hAZ9aATHUGaN7JtAyZV2WLSWag+4UEO +p70LiHfHXWWhrJON+HhSstCvvLiq5XGRzjrG0p8Iaze1YRYtlgiWHfq0tvgkKm49CeRWI9XJ30Q x4hBbhj42rKnqFZk3cOhTG0wytxa2qfXO0mqiNa9dSHeP/hYbLr2e4az0kQUksfPUa/FPnafJqQM 4iILHj3lC9fFqWcKWe/sLFVkmOBSQjFWEeSsd2tAYq1v+0n8D8Lk11sY0TN9rf99Qma9Y/SqBX2Z Z1I0W3z6f9o31YP0efDuQaeQ3h5ffRmZEP5c1PT2zA8CFltsnKJttxFZB9NYCRnbZoSNpLMCGhH2 PTXakVv4Q26aOyxWXfBRlFbXfkghXx0mkWjXu/ar693qs5AZsWqt3yy+aw9fC3e8MxGiEJkWiDwu z7X5qBAyvtUwGcW8GP6tNZaDBhmS+dST7NqVqHtKnENSzS+mmqIe5XNeGap8Ei1WUaeloS2TW8mb pH3U4BCTWBbK+gqV1Vrpuxr1dq2W/YVX447dmrBwVuFfb6MW1V27tX/1H7m01ZNddvZ716HjWv29 9t99aRmNbmurokjBZEVyhR0Nh7Ahty8ZInmMHFYixKBFUVox0PrwlvYWcmWIp0LSdk9PhHCTIbDS k0A6gYYaEHkpKqsBhTStGPaulfvHOospxECIQEGukFfadM3I1Vchj69mScqBxLFac+kFIY+KEBNZ GQCz8jjTp5m9P9NbVmKjpMmyTpGMJFalu7ROHs3tD1b2q3LrS8Ujo6IUq4r3lT1IIsrpnxpIEPL9 zGlBn32C6c/BIUSJMchn+HSyyLpdlb/Fwh6tJdblah6AiBBXslOEvKypbAARRYXRy/+7C87yXTDE et3ihfzy3Roktm4NOy1B5D+Iy9cCkFgmhU1spq6uR/RebjEI1ZgvUI9cCJum7L7Vq+ZDssQalStm 5shR33ypBgSRTgQhIrLEqwuJtHXOsEIHqERzh62XxdOPvAtI3m1UkFThvQMY6tEVLBLnlTiWsshP Guh9EnRMK9/h8DBczOazkTdx+ZVsfaaQMUJymOuBjuSLSa0vcCOPmUgqPnmAJ0ExSsCEM1I+p5Jf 7xmpilG4jTrQ8b+ZEZFh3oAIYlla+d4KgwR9KCRwWqr8UnzY+aoYMQO/5t91KC/D0u8iInNF5WTI DOs4/4nMnR7Z/4od/YmpLy8/kVITq+NFwtDaCgeulPqQOy4JHb0vRPD5JVGT1XsD1eEN4OByz20f qwtrcYUHiioSyNFnO8RFCrOak8qsE/DRadC3FRLR222U/Ep0aIYd0d87VsB/tYDuuzOI4EOOFCxF Y9GkF4icNdJbTvKpQaCgQphCIOESS+EhULFvhGt3lIQjqQXXlS1JVkTu6CJ5BI2U2/31osR6eJCt 5zH59bOsd9Op2Ca8Pt9jayjaEImUzyxHCXwEiXwOV1Y0lmQMV1+fLJa1NpxI6GStf8nlD7rgoy2n 5Rq2ZAfpRQqxE3VHWlm/gFB2SXAZ+7xcEU2Kir0YPezofupra793x/8UfNJLtyZ9lNufOfanZ82i N6ZfTSAN/hgzSL+PksUDdh1YA9UWYayD0Qc6prZuQSLaO1qqQ1uObdFNsiCRPrQ1IhrL0pLF5nRS FilCq+2Ii4+EFpnEGKSA5A5l8NqMiykoqreKpkL8VwDTfmtXd+5BrJr3SeJYT+lsnytI9GE200O+ sQR0KmyQQTyeFTLLUVKjw8u2vmAk8AOkFvIk1sueAltBIZ5812UKtohaDn9G/e9nz5KkGXT/SRdC GiE67oVAvq2QUieJtPpgFNKuza+/GJ+0DgYFhqAEesvOVwa8oLPg6u1uymvtMIijETw8YAZX0xIs prT0Lrho7bevcwCrHHy1F//TolhD7CAkVA7WX3iTQ1CRVRWc+Ar1A7chcCgWak5iG4Icc2ObQsRs SIPHJustOo8mQOOCK5RXZ9HenfiSAo9WQCIRXzUigg8lkcDJr+MD0kj5VzWj/s3iWXffvjF/yCyI wEjivKviQ1pDyEqjWGcTWcEgo8tM7Ydiw9CyBIhmtCazRB1V8HeUI6nNiBWlwIxMH5g+xFFFIDwE IB44HJuWBA0kLN56QCg4cMJOq2sC+Wy7sVfMD4kNKTJrtf6qCHmB2Gpf+OfbjgQtazlJKb/gyQ0l uxcIL4ICluUl3rmikEwfYS7a9ctuzB9r/Hr5X7fbJXHWZj23U5OeBpsQJofr2SaXikZqClGVBZ0F G6IgYfeU+A+YEOmievM6k2CRWmLVGotdIpXewkNnGcPyuDudjqKwdqa1JGNYBJZh5EMagQ35amTy rn/6ILXUhwAYxZmoB1GHXtyoEkgr8HjsVlP1IOf5ORHCLF8JGEivggWzJUlkVf4l0ohLx8aVL7Gx v3ONZwlkYEYeHwiUR3azj6b8Qmx91vU8aGv3rkTp3EXe/Wf6kjqfiGmN+bL6/JmzLGDTVWmV/48W oLRKJGveWtVWCo6dm3KlET9r1waKRCnUQlBLfOeqfAVRY3PhdsbvKOPMfRhpGfrAIi+IqDk4YOg1 GmxroMOO+/Gt8ViVR7/U+DikxpDeViLkidZejqX1vb2ZEas5OVooa1tprBBZo6iWE8dxEj5EGUSA 0hk6xHiclDgk5rtzqfVBeoQ8Yu3rBSUW0dJekTsFitpz0V3f3lt16V890vuTJkLORWOd52SLJeWV 6yo7VAMyE82VEDMTX2IefhZICR65aUdSDbDeDSNf6EYguWw1SWrUjSlbaZKQtZHYOkTDB2uAfVz2 55xQtPqtuNx/U5tuFOJORKNZK/Mg8CGtiizhD9FZrTgStwb1X/eXeMtQsUaKxE5lvgO0ZP6gXCIh 6DdBFTv/T+148EJCa+mAqiTmbi15EKcNMxNkju/0295yIazISo1TFr8SUBy8txCJEs+lvyULcu3S 3ZpnTdW7MUkYOWnkt4BEdNZJxVZxImJEVGg1oJHfMyRfjUjKv67Ge1VQvQt5GFCKARE/0lq1e6sK 60lFVsFHOben4IFZhglv5kcUGTMckkFm9PEz/wUOjWWikxvh3zz9AVHfOSq1kCLxwQ+pX/c+GMWG NVp1vBbI22LdB8yAqDHyM7HhGLmHzlohHWLgKJe1mRHzIrAiQIqekhBXwMG1Alq7CHpxjxKS62WU JCEgkGjUj+L3MmK2CygSNQqhxlCxpudhHmWttVjVzs7Brfp+PKWXxYqutcKDJBcShe86kxceZGtO 5GBSq+CC4V6LYh2tKOs2QiIJwpRhukw0V9igW72zVvWm+JDO+KOzYFar1b6KkF13g0neW2+rklzw u3r21bsmRYorV6/eKkJWYkBapRBjkO6xeywMIlcnEEJkFm+4LQkTojiZz4RY1JPMHCvZwtd5koSS VPsLGrGor6/reXjAiC0HSirYulJdP9PR/4w+knum3n0pIoq4oLQIjpXkU1aKEGIEIFlLOGvtGHHH Xh5eDCd+rZxBir6SUl7Co6wRn4WV93jV7oVoekk4uPGfGNGVcJn8uhZxs5eWDqcVk04hJaFdI5AD 8+PfZ5BR/22/9zCWzmdQGxLzG8SIoJDXHgAPznCwaG9OhfSwIMQEpgJVoOlp0xukDoVAusZYRONZ BobOoCHJEeOQWwWNgMm7iiwJYRVoFCElfqQ8tBrNaqVnpJwEd3cS54UJEZde0FE4ZBoYgJCakS3A GeAVfBBoMa+uUWC3LpXemifJNSaSh6hlxGQUn9Y4ZRZRpj7MH4JDHCwe6PpsifYHg8fDw8++Wfc+ 5qMolyg0ap0V0ayMkZZKSy3JOsFET0IcfsAgfh6/vDg27NwHdF5e1h6/9TQ8XYwhwX7xS/6V9haQ Aoviak4YxbTWy/+lcEHDVI+Cd70PFFnXLiTkVYKHUU5qvtU5JyqlDlGNtX3zJerblE/fwoMce9tT aNctPccxHPtV9CrI5GhlWQYVqTqxlKGQR2cpdc2KkExw2F71VxmNSJCybQsyClgKnRRQtCqthFTK Q6GQ91b0VXn4pCKrmJDz4/J8dn6YJYaQo0UiltksQcOticeAoa5AIrMUN64a3D9IJbJN147QrPsl x7SmwR6us1iQ8pDGmqJrl4bdK+bz8If7z7yv9C6rTVnmTCuiWRF5FiSs2mxJnELqv/TXAadQSShR ITrWhIiqqp2zDH7AgVfptvx7yyWoxlLtYBPJgaw7a5iypTlCAMPeZmN5ZmSMjZwmvNQ+/dCz+ZZT snqvyZJ0CBKFwhyI8b4ljBQGOV4ZkVBWVfQKH03oQSYQWSd1IZI4FBrpNJKlORH1IpoxVJxonn2n vHJtSTQrUkDxtYBAIr3vd2LZC0I0LyLR3XJY7pRY3aqbyvWscd6ze/RZToQsZ4tZQCNTyCzhxKx6 QosGu+YJMVdVKVdhLb1MbRid9iDOWYXyZVotFE3VKKMglyXbf8bArTDqGR/s2f2cnciq0MjKeCS8 iFT3CkrsoV0zORLufd026zadutdUks7s/CYSjKa17FNz8OsUGftQZ+nnRjHVmy+7br1jZnL9QpMe kOjDfAy3nPo1g4CCvHUKPsQHZaEyi8UmBhMSyRt61As8tg1TIs0YJdcE0iOt3jtxIJwl15PWv1us F9fO3Ic9MUEiOZNriJS/c21ByLfW3LoqLWORd3UjEsO6U4HVol5RM4UFIRLpnYVF17N/AQJZ2JuL KwJJYsuOLAy8nMHs2+FsmbMj1UChmkYcJg+c/KCjTG37yDTb98q4Z7h4Uzvq5FktHyixMmCbCfEZ D4VF7pEPSRkR8MhXKi5RWnYLDlHTXv95/0BupW+oqXay0Gzj2n5F/pE/QCAOJPzIC0sq5fCrmHTA AUTi1NHH+IYbKMl84qXAqFXM5YrIonO6ydvhLXChBt3sOmjkOIJFynkcE3+kYC+eO6tYbFDb23SE hzw2nRWedOAQtevlftJyxqtaFCGRlboRseLfRHAJMCSqLzSyUrC0hEf306rYdOEP1VhnZxBFxmIm twKVxXwx05dXBDKLNxwjFhGeeWKRwa1xKjFl3JPQ+oIRQtN5LFxAfp0yy/KJ9Wxsnx1vN8fGQ9W3 i1JgqVfRIpV7EMi91WQVoBiHrCwpEnfLHwqVrJPUMnTIqdvJKdncOJEzgdRvvHh+0aHwsq6+cYW2 Th+bRCA52gUO2bn1FwbBWN7epmKltKHl02+BoxrdoJeDz2/oUz4k7WU72CS57Rua1A0mb9vY7Clz qz2dHlVYngqpL5X86uJ94kPElrRSdV1HBuHthACXgeaKQ1YKEh2FYl250h/1VW+SJRTj/q61WAIR MSGisCQVYvWKs2UIK8PJLDyInOuL2xQS16V/buiYM7k4qz171Y9Yx7PwbOh4YFWK1W5BZxk4pvfh 1hNaKrioYw9PwpmmFtC6NwIBRD5bMIs04lrL84cWAGyFQixH0jEAvJOTdx0QuX11hmAbCc/pa1g1 1291QR7Njv/FFPpNGEQ+vTCIjoozhTVYb0hKGn5Y8z6CiCVCIpuecyEHLkE4wIWgZvENOZDy4ohA r/KIR7H6RBZ17HdUnJWhcTKNJc/mQXBrG3XrZtlZzKgKC3LrBkq0oOhdkSFhrdVXTSFKsl0+X6kL 6dSFPHXFg5hLTx5kod6jEEe5K30sDCsLU1qLzCGjvPsMZmSeQlqz+Uhm1SySUVIN2jIzwnVvXzwE PGU74qgwvhJb4dwf3IVwtum95kYcHoU8VGh5zvCz2/VvIbZUaa1zTXwBR4dTucn4aPRWXxGGeiFT IFHYfICOG79hBBtiziSVHKZirvL2V51qopvSQ1l52ckw6poaVbxfxXp9pyf5o9rh+ZayhYaRrWXV 0aP+qhnAY8SxciKkzn40cOnlLt/omokPBnKJJTRy6lB20gEezYmmBByCYHB3CyS6UHolqGilxbbQ h7LJNwlwfVu1K4qsx07CvIVBzjlatVRoKEr85DesmPoycpHHBSPAydtHXAuFjWAmlNCP8iI3u0hS S+KDSa4HwOWBRMIpQvPKtYc3qQvnH7CQhI1WDz9bQwkjv/emsz4zJ5K0lqus1jKIAg9YdiWR3VNr f+D15G6IkFtnNgkkscdL9Zl/t9mNKQm/GipLPxcIZRraeU+X1vWyYeoQ5bw25b2eIfeBzkrwOORh 70SHr0SwAScHi/b2Ia8skiWjTgo8fMzJ0ctLart+7K8Bk2aTmkHHk6HCDjWR3oXKasEjrSbbc7VW V6FDfYaILAGJSaxW7Id4dPuSMEjxIGJCRGMVDjnPzjyZFQMAhdIH4DGztIjak0WyHa7HUnTLsikQ Xgj9znMdfVJbNxqtGPw1LuG69i8PXq/lamteRbMym5BPfsYgUzoW9rXfY3zjZzyRRgwpIJPakiD+ GxQiJuSJtFHOUDuRAyh+koetWK8JDMKjkkqNnv5NBTg8d+t4kQkF9fYWPN4ZNb34VJP+oH2ETiHc gXB7DcKN9nQOWYwwVszI8t5CcyBIpzs+mDsUndX0b0TDOM5bwSGVNLrEwhOCvVrTq5eT5Q9bWPdT o4DRWhQLZJ1ahrpcXdmRVDGuNKUuekqY5FuBzEoCXPKGGnUL9IrCmp6DPIw9FAcmsPzsh7xaeJRL GWW2CMuSwsNWu4Uo8BKFW5E/rA3JzUR7YhBe0K87jfFBUbhVg4TqKvdf/Ryp9p9JHw+msyoSubdt 8iCSzxkirrRaCi1lkfLY6elsJ3Kzq87uMCHZK9CHVAzS5MMKJHgeCa9sV17W3W4dGXrpBzGIWCd6 3w/uQwbHzIce5GoOqdVjIZrVY1BW1TSVJvZqW8ir2ZDtUSveFSLXjsPrGOOmKMmgaGzWSWf3jpEs DeoKIBQfWsvYokyrAMUjwTQinYNDwlkrjWkVLIhPl6DWN6uLl3oT01idmPTV+fF8FvrQRMgkO3Uq LJoQU1iCGnljuSCUAJGZU0iluNy9G2Cos0ghtwYJ3eARbh4xGsF2hbnvoa5pJcV/Pa7lb3sjovTt PqhfJ4V8lqMVNJdg4948O5nEC+JXa0AEHNIxwiSPz+UqGuk5/eXPuHCkNCjJ2ikQElE0Wao16dc4 ZEbybZQiQSPk1x9Yo5hCu0lyXbfdOofUJVl1qPfAnZ6puZDFi5EMQULk2FugVxlEEyLwIXU/euKS YxxOeHgkhZxIIg0ZRAhE4NEioiVwaVqDivGMNbDfwIjWbCtKvolHF8e+ktR6Ac37ChqrSKzubBwi CsuAMZTbAgZk4VQyM9++WPIjUopJL/ui8QvF1yyhLZoUlU/SVKF6BnDVuutGZASZL84hBIrHtlL+ cBTZQhWKFTiiVoshYIn7Wk5EUbIKpaUJxASSFf2IBHzLY4dgr53JDTEi5ymQ4sTiJ3DAJP78U1oZ WioU6E83GT1jdooD7zppBSCDpQRRpCjZkCHHez9wHzcaQxge9myILw3J2NiCSjzUKy79FXeb4HC8 mVAfB7R8nUgOZZ045eRoDt2oRf25AMPeYHLEDiTSa6NQutYxsnJ4WN5wpUtGrELxq38BGkvKsaTa RF26qqwBp/SwnNGE6MHCXpsJQYwLNkXfXZJdlqbCPFw8c8Nudp5Jd220WubxdITJTcv+xWlEJ8jP WdiIdxQr9/P7qtnqfqy4Hphix2JE8yIqs/T43g27cYl6klBbVURrpRXxK2irnTw87RwMeH6u2UDP cRdUzGmYo3jeRTLluVwdWfZjziGV6Ap7Yy9Y6a488ucfembAOTbuwBW2prNuuvTkQupgb4gswCOm OPjMXrXlPrU3+kOKuBK91eRob5O7b5umhkN+bbXuetQhEaLPJ4Sxdp4RaSOyZUA5RXUWUXIjvX7X avpDcGKJkJYMoiakEwJRkaV/8heFQhZmwmnSlTrAIOZKFvAiYBAcMfAF8BAd7ty94Msrfme3rMhH 4x/chjzIqh6ChCTiyKgS7YTGfaW8LDGilfJaIK+Zw88iuqC3lEwMJKzV0r1c34JC2hWtiBJIp8El o4HGTuz1c222Pb+Bc1pI5Nlg0SjjAAzPV2aERNK46xjLrDV9DYrpLVGI6hLhDoBEJ2MNLrZu2A93 IbkcSwnogP70HpMWe+6+7dk4xWIsRcmrxXtfuZ1NKxcrdFQMEqVYcp24ykLFu60NsTkOCoETA1pt yqo7OBD+1ep4R4ZzyCr8+rtlRVrrtP2q6HhnnLfgo1tNz0/qQsp5e1bmWJIFFvQaC1AJFJTLrZlD ZHBxJaZl6Q6kqtjyvInUySuPLOfgktw54g3tNYOQR3yvAraKPji/uG+fppqt6oI4lqXZMRHbrMiD uvX7FNPyR2QO76GzvGdEGKRTB9IYjTwbLp4DE8+mjlx3MURlkgpk4ub7mRSjP9c8643sAXDdNiG5 5v6FfSEI8x564IBFvR703d/ou734tb70e9IRZdZbNq2H7AAAIABJREFUxHuTEdm+YRSp5kHUrL8K SLbwIIzo9j765yMC6a8pBQgpGuuImkUFQ1OnQ7TvECmTlh960nBV08fKfLpaD4XHVxVeevtJEDKN SBYCWYNFcXHOm0VXmQW3PrM3jDIgw/DK+GYJ5CgLeb28e3V7ni+ps5ZLDt3KOuuDqkaDRgS3iI4v ziVT30BilVs5FZIDwahFUQ7hAlEVWw81RtAycs/s4edU6ytG5EkQIme5pgwtRdE8N+tgjTX5JE5y pYG1ne6QUMRTqCqnjfJB4x6lIeZGIbKIHL+gr1DDvFhO2PsSnajlvVXwHjRylQ3p0TmVU+q9bwyp yrGcTSwdwqGkQiCaD3kbuY8bVYx9RH271BPCoBZYooED6fhoEa3GTIqSDBIitdJa1TgBJAwqK15X HQO957MFsmZnnL+D6ypc5WHBVOFi6Vd7tbAjD3HleNYi+fXAyYz2w6K/s2VOtldm3RmFVAJ4zCMA /DDnciuEfDWXSIik5pFab/2M6SgWDDZ4fPY7ZdZnC2yt7lGwldy6hrIKhRSIKIUYfTzjbNZz+Fme 7OyP05ogUU1F4aX6bBf2pYHJV3w9890ReCobohWPKFZ8cQbpbfvz3tHhLek+9/0KHpfbI+S8Hit6 p6po1pYJQ0ECGtQVKK8qtCyQFcHecT79ii4m0Xdr8orw0NP/aGkQoxBkzTnRwcJbGPHQaLIkEOLp kJQUEfMh/YYr+PaWEFEL8ogo1lLreQdVWaSP5SzAID7EIDLMHDblYZgtI52IIkeTYTDv7LtK2fYZ qGV+nXcPkNw2Ij4Ne+4o+eIJxQfrS7yfP9SzUbJPd5QIPtBQYnEt1VmGlAdSiD6p0lrdj0NZT+JA nnZPlgMxkwBgCE6ecU4rRiJI+wx/oUZ8rcorhbueAyKN+RJ5eA58RBAguXZUQKJ+xaJZX39IMxXB GmpG6D0+3KNzXbDoRSpe9w59pROt3zj2XSe+b5VCrPkWAS2r7GUb7jFTRYryXgW4LHno5Yqdxnu1 FqvZMZWOcG9LvQVsnBgFRqlWJpAQWrXeWgErvHbwIB0ppJgQtSCDuQoTV0uyiFLIEvIKmMF9MZgE s68zFEwHY1l58kikElVnWaHWjONSEjiqgaY3HXuAZD5HgsS6raKVpAppZZAgO4JieBwbnxgqHuDZ URJ/b4Hf+yrgKz7kab3adRbL6hQkz3F+N7w97wos1jjZU75Dn59BJSGnmkDLsweJm+qaIltrT6yz f9GI5M+2J1332vYGDeyFPnhB1o1lnhdXV7UTOfju9BTLYtE747uHLaeR2lwgU1jYjdDQiWxHte+3 GcST6bTpqdhEI70npZBdimLpY3MyYLC3CtmRXVDIKoEDbALmWLVZZFmtyUoSIUgWIsCrPoQWfcFD gQi4oeCHuBn4DrmDbDMDd9CWuBPJ+ZFlwMOlV90/UqcQY4VolMfHll03Iw9MIVJ1VUHf6EKM6Q/3 Nm3LaESd+z201j1CW5YfqeAhHFIE1pNn0ePMNi54Nq9dEPLS7J4hl54NBqKoKKNw/ttLfXzmRybN nptx3NfcPsmjcQbhyCH1IP3h4L0fB08UDnm0SU0jEca61O/4gMaoyDITwuHuqfcWaUIzIAhobd+8 LaRGSISwbjAIRZb5jyNdyNG70w0D7jwsH2IPJ73u8HYbkWC9upKqjEjKIa7aTiDSPSpCQCETd+mD nuZx8iuDWPR2sXBppcyRwQLioX9BQkR1GXMoTLJXca45UolzTm6cj9Ps49L4qNRKyXYUxpstiTT7 2ISk1/dpgHw8KTx0pCkgYnkRgch9rbFWBSGdMUjzBAIxbfVMuaRE0ZiRaCzDjhSi6yb93Aijvvq7 5beASML1S5bF04s7unRWK8KDaJWJzuPt0TyLyQ39gc2GNTwuFYWMdNahmkNqg4BSHEuet1wT3b+h uxAg2aJ2Eei4WXZy89JVR9Z4e/JaLGOQXbSGtMYijXON1zKeMkYShTBq9Q4GsSyhUohorCnzIOLR zzAgeqLzxB+UOdSNW9Zw5jBZiCEBliDKDFwMDC9Y1sjYb5oBETVbLrBmyzFEvqO1nDzyisQvqQhl xCEZFg+jGzjkngtJdODvZ1NdpBGLZt3fJ3yU/1ev109PZsWzwAIcCli2a2GLteUMlULsFKdrt/N8 7YRxbdTtd4XNT4adDKJ3rV2xJOGLMsiBpbveT8i57ljrebNran8jhLXfh5WJUG/PkdYofFcLggDv FvPjoK/Up285Sm7rKfUmVWJlUpFs+oSY6dSNWGfhkblCmJHOLw2zg9W7O2iwtoJQW1PICubDXjCV bh7ksSOBnDWPPqhBR67QMWKR3lmFDEVHkIhCJBzLbOFpRlZyLdjfPqrWCtvuEAlHcsUgy4yPOIh0 ezwYkXD79JeKSa42LPzs2PnsU1IUFkIknx/L4eOYQQp9FAvS7XZGH+SNgopn1VBGCc1OIUJTsntm IhHX8kb5XB9Dn2XHvqsFVhPQ8HAWm01S/5UwSI8NOgee3VisxoKsGyXvhTcCHhWJRL0JI7065eTQ WyBr66uhWZNlNSdGI68sYAwPcrTGKdqNJh1GlJdthR0JBF0hzgzNacfIldVktfq8c2R06ZNUE59Q EkGtMCFRrugQWZ4nWmpSzvRBA70hrRYDXDqAgY+ytCpvykvSyaARLWZDoqwRxcER4oqa+NQ1Ml96 b3s1pDEj5UvGyHjkr6/VjVKteeQP66lBTLnrzMafnUJ8XrZC5OH+0cJaqwDJU1tu3aoQiKCjAzrk ut7qOb4laNRrQC8x0HUNEQAoay199byrEQWWcX8uYWSWr2gzFhIhBSAHa7jtYT2khNd2paM269Zw k0Qg1yMcOL7BqhZtb+GBg0gPTKKz6CSSIb4c4chw71skz/vsRXJ7+kSJg6HeZNSVPDQRcvKyktbj ux1jWF10jUQqUb60UoSs2CpCjWVtIgSJEYiYkLOb9Inm0uXsHsJjKHsQFoqD2YJMMthdvmo6q/yI 4WaIOPAy0Lb0kNYi5FbVm5jnoyhY5jdCWwkNo/UjX8KqZx6JkJZDJFU05pZ2V1uSdv9sbKKO/VEY 5PGzrI14dAJZrbtiP3bdUznDn3bPzH74tY5Jqax6diZJTkN55Vmy8M8jjLg0y0/MrEQaPeJYOlXR olhyFnuHFCHiCwqtr/AGg+xDYI1q3vuqJisGLaZ63oOZj+gP6cOobxssVNdkiFFIxHhv2RCrOWEY 68QxvebUAYETKnibztqnWkSwkDExq95lCmlZk9WtsgdJRSioVjSMMM47KQhhFsRIYHDCAEQY1hVb slxkbhlgV6QSeDBnEn7d7yhPUZAss9TK2USOnQN5VErrthWpl4cGRhI+vjw8cPZDxSI1k1B9GZHc f3bA3D+go+rRPIhApDj0VfdUrt3zU/PU+An+rCJr+5xeN3rb6WuTTA3T5oDIc3IwzyMqSdQCmJBD +ITOW8ulKzpaA4j5DjMdA/7880T/cETvhy6d04MOeeC7b2Y79FvrCdmyQGtrnbdh1N9Y+L5l4Xvz VudD+tGz23MfQhrDsZgGQbk7WCIbEHwpEiWoaOyMPzQhEn490EJwrPSHnjzMO3GJhVNfPMaCfLFQ giAY1H0wP0KMyFsa4HISGQAkzzbWAWF2kjg2iBUgp1r8diWzRobdG9oNIoxqyTnv0V+0IH6psZGt SS5KMWQ8mEd/hAl5TPBoJYD1JH/km07PaxBCseaKkXyOe2JdNdNzTimKFrPSqxQCc4Qk7kDW0a3H GjmQFsjwbQkqsTbaS6jj45AKoZWIvturTEgUvI9NiPt0L+gFQqoxDluWZGFhCLtvfRYQ0GEPEeJN cDhyckMTjVMNFZbFsY5MBh69FKtxAOzS1QSYKrKxBxGTYQ+e+khpdE8VTsWCKIcMEskyBhmWTgGG jQXlFRChT2pLDCdLAmI2eDiLIEJx4wKlXOggWXL4wyIKGaNJd+79ImnEbwLJcswj4+AWo70eBf7C eQ/GIbpdIUoa6yYrZZPPeVb2o4a1HoVBVGCVh65gRAnkqRCIntugj+cCDVDHVpCyxSdgAsPJ+pkq yqjGfp4E8vxM8Fi4ODGIQqSq9pXZKrYdTqdq69ad3fqrmHRdBI2pP15sUtVkjUTW5YpALmMX4u3p PkEujQEyjPgIOTDImwHjDUB5lXyIiqyqbLHOgKi6ikRh5wbE5ZMB4OTVJVqaWPOHfWqlJsmDJJ8O GgmLrjghw1igFwxSOGSjaZDBEoVLk1B2pbNY2LF+CCjoa0Z8DT32Q0yy6x3BYeUTFLFAdwWnLENn mTvhaK2aRNLsuSsOCZ+u8d+HOcpPdOX0IyEyfagyJOFJ8swggkONOghEEaIc8vRUWKRrnzRH+NQ0 UFZymm8NGsWlm9ZSiBgAzKbsBDZuVuyjJgjk2fBDAy/RXpiZdWqdwmEn7KH7fVouhH7R9QxgEC0x NP7Y+4L0nob72qZ/j0H2XvfYRyQLTv2Nu3Ushe5qy4bHbTntBCHeLdfrjMpN2G979EITKqxjsulM poei8tYpYKBJV/SPRKq9YyOucoTRSEoQrjwRslI//+gmpHj0YbmZDcoCy0H9dgRth4W/WhhQQC0K D3kIB8/8yQBWcVIx9vBMu/WfMEHiEd9U+ztPPSM3SOSKQ0JkoabxgU9yELO1bCzKY4r0XpU1ZtNe KERw8lgA4h694GMlDPL0pBGsp0Qh+ljgoXTxvBVgbJPI0i+uw7/Li+eED882klM82+4VJnZvwSA6 TFt548V2xQlGhEHKyTygMd02Ex4sN2KhLVb7/lEPkrbvMBfiHepsLuypslBxAgqR8kXEsvTpKALr o3R6w4O+2hPSRHO6aSyc/7uOESy3Ia0Hsk70IMy5U2WtooVKINIlkWXoEX3VViZEwryTmbkQC2IB AhBXi+xBjE0AHIOO8QnuM741MGHi8Io04iyoJOK+Xq1FwTXHGNPrAabfF1ruRr6wQ1cXTz9G48iD guTRrTs5JAWAiRCBiMKj3AtGHgsuCn08rbvCHk+KjqAQs+hyoj+HZ3/m6f/sX3zOP6U/J4TxjHKU EGXrdABsvHCSnIJDh8URGV9tFW/758IgOq9aT+oBpSKD9Ux5IuR6T8iYQS5jhBwOvlLH+EPbCw9s wUXpogoqeJD+jXUnXnOSjHp/VZBVzzqpqt153Nmod9gP+HQmQlyA7YxZdMpJU+cKPdJrHsQg0lmV u5LHqrMo1so9yHIzsa7bcg2EqNMeEmsMOJwlBvEnRn6DWxQdM20wsdJ4hwnaq7wRcUlv4lVb3mo1 n824ZgH3cCcfTHqAbX8IN+LdIg8+7dcuXNNTt1ndP6AORdMgKq/kUeHx06NbkCdFSD7fnyGtxIHw xGdcy0Na6ZqAQlw1cChNBQ4/VGx0tn+hqCuu5BV0SA7ElkELg6iy0nLFw4A5JoKLofdNnmMCEWhc EUg9691oJG3U6V1nsf126xmRNxT4Jngojxx7hHqPMsHBZZaO6UU3+oR8whhWw9lxbLyNBnSUZbUu qzwVkoQYwUGPTg/SwYQAIkouK6KjgMNz6Q6OYbmA2yYa4haXYUEcDHxaeIYkSTPGiCG4vOTR6yBn s7AjaLLy3Hoe1DhPOxVS8rBmkRTzJVDCr+vUeCOQOXXWtDpImqtOtj8qTB4VIKtCII/qz8u1eUr4 MEwIOkRZPbvk2uZPKwbZphemwXLuxGxINbuhBTjWO46aV9uhcxoEJO1XWfHzIiZ9c9Dpo15eMhyQ WdeKEQPOjUxIKjS50V14SAtDci4EdSdvyKkzJaKRK275TMOtTWdZVdZ2NNuknphFKmFXSJMklgDh FFNNGgZydz6ptOs8GmyCaZdJJCVCulU+FPuh319ZJr07T4rG2kjBokSwhsCH12JVqBigpJwnmFRP ooyc4nlFctLgKELbu4V8URs/8ylCqV8X3SJz2/YWycPYPXId9/1SQcTQ8YD5c3MdgI2gb1j2UQ8J 7EdBxsMjHMjjdCU32YCq7PEkWZB0vm+et5vnZgMesLN/6wgxkIA1tvZxUAstSETEEnkoLGzUKSbL v2hcVyDxojsUy0G5Fw4pd2UQEVZMBg7jHOH+4/G8DpEbeRBizXeG9Km29w0yywa7o1oxCnytQ2Rr velYrNPHVEVnEsPIsW88kBU00kXFe7gQ9Npa8wcBQQY5NdZWlfIgHJYFqrDCXVVZdCMdShUtE+IU IlFeLcYaNIEx8O998MMiH9Guz1xneTqkohC+taBem7HjfQFLbzf0Vc3Yp5s62Z1C5mMzciOqVU3C RlKErSO6NnRKv24Df71b11TWIwPBWWsJRB4cIp14EKWQJiusTUN7vnnebHETNrF3t4RJyK/tSG4B WFahyLJFeegUGg6RWOYjukp3Vn8VXLR6JC/W334oZ7FtXuuHPH/Uwr4W3ToM19io8iEfooRj5LD8 FgTS26BeFL8nN2KFJ6jqfdVSE1mj3rxpWS91VsPdINW83pBY1TQ5tBUi2Os23CK5x1yMZUMe0FRl Vr5tmVQ3zkjFWB0CvS0RwqZbTRYaf9CGBBEswoEENCoLkr/MA1KNm5aBKUfnkOXChwoheWjYWKRo VpqrbZILNb9Vyn3u2faaRRKDGEbmc++tepxz6Yh5EQ9yPSowCnd8wUpqQcej3FVkTYtLf9QA1pMI rCdhjnLTc19gAQtCMWUvIjkSIqsiD+gxMkgqW1S00HSoyLKt1ModBg5x5/LWVzv++vXPP+yHDRLp rL0a9mHQB04BGreEjAnkUpsQIu1Ao27ZEHXqCPjShvgIINZlyatXzDvRkhPfG8IaxWpGliJnkoBi qgkaq+k6L3sPB95F9rxj5zre8p6pDsvajDOQNFTLvjKl1alXN/54VBtiLn2yMQ4pEPFirCStsgMZ 0lENkyG9TU5h1Dd4xYTWEnCbxZAUL9uaeQYxAlpc0x6tI4qRcfz3hh/Ba4/8PnD6nKxo9zRiuJFp VSRf8PJFIVIYZPoo8CgeBA6kXEVRqbAqyJADkVkbFVtyoNRSILIBOuDEm4BMuu6i5MQebKKQDm80 edW+dLGc2sJW7QtQ0crtpdV3dE86VoF4cJZtT3xxRSE1Jm4yCDtDDubUw6WbVbeq954ssmXSEFN7 t5ERkREO0py+bSqY5GBvZENOngvxpZ470EgTU346LcbyuXIM9fLzsOqWH0yF75YN6VaRNwwKocLa FAcygU0XjOQwbliLSm0FUKr3Ekj8x+g+hoWXrcyiij43ss9YrrXglqto1V36xLnZmEHGdqQqz/K1 Cs4mqNYyaEgo+EvKksw5FcX44+F++qgCS9Eh208fQR/lQf/eGz4MDXK4lQd9Y4tHo5fgExqNUYTL 8iDJfLQN1oPosoV2F+BYKx5EJAgyvio+DCkFI19/KwwiWZA90ukasDpgCRsL3W+MWLymkPpiuBJ4 sK6XIgtWXVPrMCCHIBDGsNSgmMgqT0fdcJsbp1IuvUEepApjdd4SwuDUCZHeXRXi1TpF7ztkV0gk C0EhFuHtUFrSekakSxbkKXpCCjomprI8jT6KWAVaKtZI9DHU2FgMnk739CJlFkK/zisGlSW0l7dV ZXzMs32H2hpn2a/Gl4YhGRc2PsyxD3E0hy5BxJIlBRwPUxVYU0FJ9zR9MgbZdM/lwXDR0HY0G3Uh yiFy34YrMaBE6n0T9kPvKqkEIl2DZndlD4lY1fh4cWi0uMbTt2+//f0H+g3mL3oxI4dUavLBcCwG em8NOOmTC0mxLHCJrgvB2vTYjND70F5WLG6tC5d1i6CPY8UhzeggcKJL03WlDgp3tS7rRK3VMr4b 4d6Ty7CO7elebGIs0uHZPAgiWsiEBDwmy80ZtSaDMsiIP5LGqgK+6Y1RIDgzyBAZeY9sLUJUebMV 0ZFG/1alv8yFqMyaB5vcKGe8PRUllcabK5Ghcxwaj8JfD2rNp9BdorCmeoMB6Z7O8lDQYeBQphAI UF/ZwWYrVNKYdTdACEioxnIypNHkO2QVGw+1nr5ViLQt4PHVoKFB3TZDo1y+FXCUy4//9MNFd+cM 9mdfLro1Z/Cixf21A6k0Vhq0GBjBBjcUBftAax32znCWj1tE5aLW8lounes+5c2tpkGEQwqbHHWB CFqlsKdtEgghOE7UVw1dSIe4lUCjaQmNxt/26vfOdiO0mUeQHrRM4cry684qOYolJmRy3pxnm5kU mwyWTP8dcAyLMVNU3FKFvRJSTGpFfiQyJ6SP5YIzgWfWaJU7RmZZcGFT6HVM6woiV1Ow514Vn6Zq fQGVmDd50Luk4AuFaG2KIkQWn04fz8Ig56fmvBHmMCw04I2thns1kltAIe89q0EpdKJUY35lo+YF jgQQMXcuDVh6Ggg4djpBXj35miMGDBAODDv6+vX9252g48fffvzxt3/6YZ9KdofIX8CV6Ok9jBik 0ljhQa4rsrz7ljW9sfo2NodsCRMnEUsTbjF0UQ62KMmKqt7jVT69WlUYcSxWvB8zZSB0deJcLLSi 5zCWcgjzgi2qTtJArNb8+ioFss6sxio2BC59YWGs4fq0r1/fogr/IMEnFaWEqYfcIn0EVjARxdiE w08rdMz9ikbdcZHW8oYhyRIrUwheQ2dNcwD4EVtEyyMYxBTWuQjTQiGbs1CIkIid+4qUzbPTR3kQ g1Ee9WNVV0TJs3r7nFqXkHGjA4SEO4qq6gwcxht6eWnddyRgCDbewR13dwUhBSI/7C+DImCoUh6D GXQaipEFGY3nvW6bStTTR6bQ6rI4a/FgSgsxXg45oVHfbm2c3NEZZGslvce6LeTIjGE1P67DIzQW K9qZKm+7AImP/zlxAEoUKvoLVrszctWGwOpWKZBFmTUsC0SCQW7KqNsa6+q9UaAr3vUaYDaVLJAV IXM4o/h8rWqCaU0mc/j2KPtNPVUftI58yaaEk0ynprW+WCOJZNy/TJFaLIcSE378oggRAnn6qUBE rk+boBC9ExVyaJ8oeWwMJBuVV88kj6ZpwnyYL38SfAh3lH9S8+WOjxcIKoiqr7Kw9c6gUZjDlNVv ejEGuWC7FIiCf/j3nLiI0dY39FWqyroa38DfEyqLlb3on9IpWAaO8sBxpFye/uZzrc2KYLdOLA7J Hh1AqY06hNbRENIw3otwlrXhjmY3GGw6nxKUryvW9rImizaEuRBlkCeLY03OYUFEBw01CVzjoTby Q0Uhbt6v8cTukgBMigHXYsvThk4io5AWug7Nmngfe67T+qh/ZFSSMk91W18KSqaIBqvcKmJraj59 aiKrm0oFwqY7K4M8mcJSiGydPewJesreUPdRYNJs6M/BHHI1X64M0klRif65W6NDFKYcAqvcZLX3 N7kLNu54/bFcy+M/icQaOBsuorkHRrFwrocfqSFyyfrqGiQ+3iSyhV6uqLWLKrZcY22xnw1HhT5Q +c5FuFH5frT1Osegjlprnbx6ESg45XAWIXOizjoiF3Lscj9Il9HB5AcCvCt/Nn21sq5bpkKWG8kT IpJVR7HS+V6TxEcKKyMjpw9TxfyQlNViSP6DXe3RjYip2rUhiY26jP6moO+4lvFmO/uXammod1lN AY7H+ZcvGgwWjHyZlkdjkKnEeIVAns4wH5oKQbxqw4tRyHYTGGkYC1Z8JIf+pASiGFECaZ+6SJfT epioEmgIcXz99l7AoA8Gkh+NRH5Uk76/7IeU53Bt5RYbFDLCx4g0PhgAdHAXcshSi7W9b74WwRMh ngkxJ3LUF+bOt81WjXpqDrFwVV3wbrmQxj06ikgsD+Jz5Kx213OEFYV0DGQlBmG9CXLoq45QQUGv hHlpQooH2Uxm50HTIAMtyHcI5HuXscQa0rueF1nQmCx8Zoq8uUwVKLNFNd5huVgmhbVkIaNDxEsa b+xBDB75MoLJmEJ0SbvJr4KPR7Xsc8NHoRDBxxm6tCs+vREGocAylbVFBmRDLhEMaXS3PDR6II/S a2UPz1AFGt7dFVg0QR7Eht7vFB+CkK93ghFFh9EHiORHuSlA8smvs7Bwfgeh3DYhVtSbp8hdXXrv Tt8zEcIoVsx8F4XVMxHy5lWLW45z8NHW7C2kD6ma0jlfESSi0IC+4gggjuPdkVkcFOw+1KBv690j obBII54jZMNtGxDpvOZ9shyk7dYZ5KZAyhC4ws8HGmv8nWAW1mtFU+8y5nHlKfMcIj+L7dQzztOy Y9r12ah5JBVrjUJbI8mVan/nlmMvXkTwUd42Cikgefpynp4VI2LVi00v8ABEGkIkPUk8SwAhsmpj PINyxsaI47l5eu6edp08PNmcRsFJW11WsOXvho5yLcTx7a/f7v767R3qSu353W+AiAHE41Sx3dby fDard7i9D3pUZnLTg7ALKzEIBlqz/1az6bEvhGuntpwK9KpYOVrtokzujdYQXq4mnfigXrt33ASS w1mqrjjSweaacOFOmJAoWbT8R8eqd5S6a0ehoSMHsjbn4kLO5kHEpVMY3YRCPstvoKQ6jF/A31eR ypDcu2EmpUV8V6LvrVo4gcy4TneO1W6QW3Ofh1JFt4iP5Eg8KVKV/rJ2y2JZc3Pr8+I+DCIFHNOz rR4qLr1RhGz0DmyYZRer3sCkq/NQ/lCxZdiQGybOPpm2sn+/nYYh1+3K4SHs8a2Vdfdf3+8knFsk 1vvd3bug4k6juwaN38SDCIVIFOuCJhDEsuzGjlvjj9uL2PYj9riO9R58ilw1w8GS6X1vEa2eacKD TZAjl+iLVyt7782EvNkYOa07aaL2pElx3y7DQ6gDNJKKd8NzdKngJE3xZQALIgvJQKZCwoBgP4gy TFdRyGZ5nm3g001jLW6zwIeXG18dK6x4dxaPs4GM4kOG0rBfK0rhQC3fFLp0jCDJrkC4qvu9klhX 0a2rnnZ4kS/KHSKvQCBfCoNYHuSscayzRnsR6n0mcThK6EMsuJusOeDxJMRhw7VkyKzulW7XaHPD g21jfX+XPcWFOootf38v+PhNbnfw5vJMIhGqE9hMAAAgAElEQVQG0TzIJQK6ezLIYc9s3+Dr0keD G6qW9Bt5EKRV9kjL560hh8CI4UIhcXAfQqNuISwrXNShWbJFvWGot0dB72iRJ9tCMMbawlhMfxyT 58jexDnF6xatFCs3T8GEdCASg4cVa62sJSTwIeVYVa7w+wn02+hweZXdx+hrVRrF4QL+mMWhrbvC bp7FYumr3qynvdqqMLfew6XvsMpDfq+Y5CqsFUSSPXtwiuHjcX6eKoNop7KYdCURYMEuW7xo4NJN WaEk3t59Cgbxpoad6+PR5eu7rCkunkP4Q6yH4EPpQ/nDgfGbRLHEo5cHYxC3G/2e/MEKEyvMuhXo TZn0WxChXBtUqR38xnm9SIj45hBO67VmqrdIiZgNEQZ5E4e+jVBWnnDCIb1dVlcn1GMBJBkETYKG Fb0DPCdMliNE6NC9GKv1nLobEaeQJ9abFJ+uFGKR3goifwgew2X01Zsa60ZEmG+h2zdRiUBkwYYR K0JJ8ayUGzGkACagkvl8eeVFbs/Xuh5n+iWhRhzJHAh5ms7PT9juWP6wbMr1eaMFWU4izxa60nes qgTMsXlCTFfCuvpPC8vhMZUxPgQSRV7diboq8kqElSKksIeYECMQvf2IF3dq0i8jl96zsoTjf1ja e6Oit2KQW0WLrMaKgb0sWoxBJ9jMtu1zBGvLXbhb8R9vgo03TrTWUFbFIU3MN+mjGMumN+gka3Hq uySjTliS3ljTYRXEStt2PNILpdW6YUcjbgfUuAfxQFbxIBPEeWcsyLoyGRe9Li63cDPYF66Ac+O7 NZF4OIs5EpbcYyniImz7bObZwwUIZO71izNEtma2The2ZJa62DOHXCVIcp1WGJOpPct+3em0IGQK dWUgcQ4xcCh3PAeBNGAQ5Q0NY1l3w3MX5NH5zNgaHnetLCh+b+/eQR5KIMIeghAIq5BXghGz6z/Y IOrez2hII4v82uBeWpEr9qgJ5Cql7mWO0RTi2RCP9B76PvYieFkvAr9IFhaINOX5qKNJOebkaOhI g04m0UKlKDnqnRt16iCWuXYWaZFQjvQgGOTAKBalVTTcrvhiRZsi/zJPTIVshEOKT2e94qjcvUYJ gHIhHi4D0YPzXN643FRYixHLkENinGluaEdhfMohznjgBJJpBOtGZpzNiLjWMqssgiUdfalh4oUp ipDiRcSPFKQUAnlailU/Ex24ZpXV0Igw/2HoODdSAiyW/Ilh3c7+Snl9aZtHxRYCKfLqzry5MMed AEOxcfdXUIfg5DcSCZ80inWpGj5YhkUKOeDF7VTh9xkEw1EOXpLVH9Ig0j5He917wIGYQeeuaIyz PloLLnYY2txeMkg9I6sKYxkWWJfFMFb485OHsVBx4lGsHf4aoYFwTCHoUkcYizbdqk3Og3WFmAu5 9ec/YSKgcBmSxAq46Js4vIyFVm1RckDAh6o4cyxQwBjomKW5KKmAMdeg8KYYmS+vug9v8Mf1sTsT xUgRWUtJhSynHsk6n5+JD+MLrXdvyCDGGc9ds+ks72GLWnPYqkJHiCtBx91KEUJ8vAs+lD4UGr+5 STeBpUIrPMg+1qyxiCpaQapBciNwjClkLLDIQlhcyDEnZkN6RrI40HrbR7bQU4ZAiz4f2amu4Niy w9AGnUSwt1Obbr2FzQlhrCY6Cznsx18HhXTUV75b3QVthy70NspMWg6V69qAiCa+JjogS9hjSQK5 ggj5InPIIn0yRo/+3Pgtvu+/PODBIhQfH79wjMCtLznDdEG7HtWMKUeCbSPcOQLTvuSsh+RM6lqU q/xhcMp0viz4WD6qUedFOKRTDiF/WPUiRZZUo3TdhjWoqMWO2msa81WCh8gq23Mv+HiHN39XfSXh 3XdFx1/vcKkZRGAiALn4YB9TWIfIo3sqfX89/MeRcvkIIQiEHfrkQHyadY+lCChZ3L5hxkmfELL1 xQg2tFd6p7bbIBC2UfEyCQrpbGN6k0Y4NAjvxuXo5bz5dcsgVpJY3hfi2cLWewrRoq4IeQJCyr+y tN7Ooq9w9Hf+kiAQZz1hUn+irwYe7+lbbkqs0Rvse/fmqgXHPHDkAxHiympRc0i4jxlwgVwJ15DM s+C6qkmp+YMm5AtcyKMlC9Wkw6cXPFBl+fVZTPlZ/jk3jY14MHC4W/RQSjIfnxQWKxFWBQbyJPwh IFGDLo+KifeEDKDE3vhRoGISK2usg70aggO8v+P2Ip39dxDiJOSNU31y6mLW33o362QLTDvh3Cxo LfQbHquBixz+Uw96T+MbiI3Yp9MlsPB1vUrHglhNivFqKBcE4pordd8mAmE91nm2WZ6HDUSWZQuv IbJIgPiIQQwLGTYFI/b9qgw+nqsc4gzVKKO+EeCCAx5Y1mhb3nJh/NUTjEgorSriG8/Lq+iWg0Vg chYXUmjkfJ6e47IphFIgoVTSnJU+yrOAY9MoRJD6zVWmLBilvCKPqDXX7d16qOB4J0LK/a/lDgq5 JhAgpZh0Pcv7fDpzNuIQ9Vj7667byKPX+LgeRXqw4Q0KEpbzesmJ6ywb/nMYMQg61NWJHHUL7qvg 45W5Qpvy7nVZdcmipUKOwMfRWwtrrKTXFuttAyXu1INCVqkjBPHeFTPrq+4nUoj0pg+b2dJFlhvo kQv5HQa5jL5WXMot6TWCX0CEl9EaBpsUtFi6aV9Gse+IQsKuc87DnLPoGPm6mWof8YldptBdYkHK Y8HHo+XTNdS76QQZzRm17wUVoqie5IV48migTtjQf6VVxHVhQT4VYfWp/fT+btpKYNG+O4OARu78 /k5YvN9BXEFkmQfJ8gm2o84OasXJjQFZVx5kXLKIEYuDb9ShTz8YLGx9oR1uOVKOCPFRDoqPV8XI m6ksdR1b71XnuraKOejQO994i73Q9CANrHkao0WgtDYlyK8rD2OhKqsDToCaYJCI9MoEOdSbRJ3u ZbhkJPwBD5K/BnwpSIaLyS55SCmWUSzZ94wsfD/JkKp9oyae4SzCY9RcNUsjfi3ci1Kt2fxWxVbk 3a/d+1RN+vzL+UuBR1CINgs0clS4YlMehUQ2Qhtndr5liLDgIac+fipXgYXIq08wIHftpzs5KhSi KLkjiQAoCSIa0pIbwlq//T+QWBdbTMiLrUE4cFJvv6+CwGMO+Z4H8aoVTGuMRDr7063exIpNFBax fWq79brF/pVkcixvNlr4fuT0Uavn5aVKqndIiEiod8wYJ1Re5RIUC/Win6rddRkijGKlmkVMtV6t vBxlFcMbrPN2OTBbOARIRgQyYpD8Ts0nCUjD+EdH1Sdjy5NX90RIa6aj7SC5MCEI7h059ihG8Vzi XFEym9OcaB4R7n0+El1Vqj3VbU0VJmLUy+3JVVZnLHIWISXksek6RUg5eLY/YYVHctVQ29rUGdJ7 wcVKsPGuCPn0vrr7VBBh/uP9Gh4Kjfe/GjDcldhzQUd5Gyb9kijEJ+sechDrcLhFIPv973kQJhoH H96QBsn1WB5SrWjjhPe3t6y0NNL7isHvMgzINrQ5byRLkufJHY1Jjh12FnI0Q0UZjTuQUyKQDsEs T4esohEEnO5ia+Vtt4/BIRxBOszAIDkZcql5IjNIfidAMIoJB24uxEqdWR/DI6p8vZhx4UsWEPYF i8QcrQoiMet3VsFjafMeFBIz5xEnkqpQHjprvlR4PApCrNrEfbq2T21Mb23UlDdnp43G5zIxuEif KOwhoDD6MJTcKVSK0tIMoV2Bj3d/hmO/I6G8vxuL/Gao+e0HEEBNDvi7zxm93K1zs2axZpAb403Y N8X+WzSox+4pX6SOUdZ0IX1yIhiaJdW8b80W+RCMsVahFQyCUdZHu1defWdjsjJp7DxfiGG9OrRB ooenNH80M0hLdeXvrdCyPi5639j4H5liTZseZ21GQSAh7EaGRX731s+4P7myHoFKA8qQEJMmZDuj 5BKUuis3xbXicG41jvOlVzbOx+49cccyw+eL4EObphQenXeG6LGQRmeDMIQ2moQR/vFC6uNT2xVE lLuqK8qrT5/e7eHdHsyHKDKSDTGF5UghVqC43t2DXEYM4tWKxiKYldVf+/TEI98pNuktYeizSHs3 IjbjRG3IG2cujooWtz6S9K3HICDbjnDUgdZHDFscxbGyyrIsSK5yrzdAnxKhnGw4aYsR16cc7V1F zCona9Gvrla9Yzr9jKr3JVoLZ17zPpiRSKd4hkoy40ElgZVMPPlnah2W473D6D0LaXmuPZBh9MGF 07ZvxGK/8O0pksXDuRbIz3xlKHbrjvPsFVaEOsSiz8/zs/LH8qwFJ0EhnXJHwYgEryRZvulGFzMf rf4DfeoEIuXf4kTzoTRivPEuWkvxIT5EUFJc+ycCAlRCMrmLZwLJJJae2LmpUJumDtx7q4UiLPi9 UW/yfQ9CmOisLYSz+lz3/pYKTg5VkeJ2RB/Y9Sn0IdEsoxFhk2rSew0TNBeesLWQJSa81N7cfDva 0gEUxrGiJKtt03he5KVMC6+cQbivcLMZpLOQDqQKYRkCLhkpPPP3jh9HSOaVikHipwiESnARHDMS B0ACvTUElRATMOyQVgtOLB0RSNAKfLqvVZi5JxlXo1BsqcI6z6fTaSis8v8x2/NoD84eo5EBuUKu E+oQLdUBGnbwCUSiOCk6CwgRYCg87vQp08ZYdkFy6acqsS65GitiulFjorBRIrhNH99DiO0FPdgY 0gOnnPjVGKRPgSyzG1sMfB+FewUbOgLobYutId6gfkwe5MgBveCGhkUmPsgkakwqOtFsO4p5d3kb Gx4Yueq8z8DHLVJkrdyETGQf2yYqFnPdem0nKiWVKeIWgVziY0FY+tEP0uxDwkZil1l8EPVZBpUZ V+kaY/h6hRmnYUdaJKXbvZVkqdW/akjmozLgAom54KMcFSaRJKGbkI4yS67JeGRw5ASuPYFBOhFZ 0FefcDOzbhqrNeqwGx4oud4reKR3FCDomh1GgV40ggxsDLk1YXHMJYzzjmBi6mzQ3emHrLKYUn+D VedStmiZesu3rQmuApGj7g05brc2Ua5PIuuKQ5RCumCOpkqmN5X4Qi8IPUh32vEfJadBjDW6GCbX erFiTSEbmZA1LKNtqvqzbinxLIwcGRUIPnAmN9AQb6Za+LHGos6CvsLeQ3ckrPdlRt1LUgIM4UGq yq25D0ZZ+mbEnFDUl1N9iUKTaWERlVbl/tM1g9y4tBZ+Lw+Ci87sx6e2fiCFmA15B0rekRNRiHwi RpxDXG/hkWBhmPfi4mmIfkJLfUSW8CMT8r1yRbUwMDC9zE9J3eksOVHykOGikkw/eKQXJe9b7xPx VerbLUoXt6awgJJjaiysTUhjjj3CuqPUObXWSWK7Zj+alEbfcWUhbDqL3JEt9HZ1g0h5eEIuRAdZ D5s83sRM9D6DIhvv9Hi5SSF42ifDDh65po6ssSJCEBQyRLFWoGaWn23yNau2jFEW7kGu8uxmSOZc 8AZczBjMUuKQFPpS1dVUiWMq+uon5Y4phNVNjCDroXShztzoozuFxkoe5FPrV7h1gYj59ff66epy l57vwCBVqtAGNxz2aWHIcEBLyPX0hu9UKyYGUZ9usaxD7/23PcNZ2D/1hplYaJN6q4qyWIby2guF vGGkHDfqHIkNJ5AJWkOOTBgeu5MN/HHOqGuxfIav2Q/UKzZ1Ir2LMmpPrHdYkbCyf8NpiKzN2Vbp RNG7YGO/8DP+ttaqoFFTysiYj5IqI6BcFjWJ5IuNwfZYlht0pEXAJ2hd93ivImDBPsSq9JfmZMbD OT1KVZeyVHNu5sPkFVyI4mJ6kzkw8NIUcWGO7qSPCoSfCkJObWDCCSRBxJTXu9KJMYlDw8NcUF8j xBQPcrEw1iE1FXr4ivsJbQ7Qh0N6979n0d2KsOykH8WyDCFYHxL6inN6uQnXXr/qUjYZe2LpEHqR 3KE+yRRCb56aQj7Kg9gQeFa8exTLH1fRKQUGgWVfocTXJ2QpRJbSfbtRDzKrh/9UeiqHbvnWBwSS UJQCwTd8u9NIRSIp5b7g/l0v0XIamfkAFM8gxuw5Hxw088T7zLGDsC+ziUubkDJforFdLIgJrAAH BopN7S/LRwJLIKGMAdtxMleuIV6TWyfVVzV7EDOfUHki34ApUWh8Cjz8CnhU8kskFiikzgMCJQM2 nntbyP6WCxkbkKsJWXvOj7dIL+sVvfkW6Ojdh3CySQ5j6Zu+WKcQSIPeEK6b0v4przc50oJ0ZBBi JGdCqqzIiXOs7XYalbx3rZsQtt22zICg+KSDEeGMrM1kY32FMec9nahelpspJNFADuMGSPJjZUaQ CvGfznhMEit5Id81PWAAiveLpOmlbGSPykZHRV2vteSbc5LKfMlBWzOTWEYhCO5SXk06Pn0Ej09I 4X4y+miNPux6UiKRR4NItiM1RD79qgzyKwO/gIHlSsr9by2BIValNYj89sOFsxFdYw04rwdb4qkM YiXwHxRkJaDcvBj/cA6prViIokWrWOw9m95bTRZpo08YgcrSUUCCkldpVdexveZBesgsqiyGsLRw 0TRWh+gtSOO6FgsDUBQWJ7UfrW/0XHkCvfPBDWQQQmQ0Imt5tknWw3Ixy9UmKeeROCDO/MqWX6Nj nCoZ6auKSj6cWbdY5BU8C3aN+AhsmBHMC2LYlwt1GekKiHjRlpqROSZAUGVpxl2SH6awDB8FF8Ig k+6n8v+ySbl+cDkZNJRHTp9O+q9xUv5Q/6EYKRg4ybXlgx7oo0DnRAZpP/0aFfHCLO+ffn1vW+iv ltD5mxWnoNQk4rxR126oYADLldf1Lp3vX/rkZSLU29cuve+j3sTceFT1+iigV7Ssywg5WBCM7MX6 qWOT+6ZGa9kY2N2h9uSKQKouKt2q3uWtnh5cJEg8pU6N1XJ4gzxgfMNmMttIsjC5kFEtbxXFyhm/ ZDYujgiorMQdSXslD+MI8NdVlj0rr4VPQPGqxmXNINxahaQI3UjUoywCIxHeghWZM12iKmtS+GN5 ZnHJdDIVhJwLMqa3wRETy0xm6WawVpkDvNHJ46l8pLD5JAcKFQWGgQUIUYI5tX8zKaZQUYz8zXyK RLv+9t7+2spdaEZEl5WaqCzK40f3GEfa7wefKsecyEczsj68HBx4vlChH9sQtOAqUPqeiQ8ft8iq RW0rZHHWq1W+I9br29MxBqjPJVk2v8HrTdyFECY5rS5DTRrkQU45C8KykhabD9gdgg6RNi+9jTm9 2ji1RC4kRNZ1wQkNR37ncvG3FimleLm6Jl65CZOAx9X/BmYvfRtv3p6QqlCQS1y42pqF9UDv7mIZ 4a00pdEa26ezqSBkep5BYE0KJs7dT4U3zj8pd0x+ukEc1FjlzD/9JGCRU96YBJRCrYVPPp2ULk6n OCoHCo+TXEAnf7NrwYSA5G9KIL8iPNzq4fv7qfUoVpUq3O8R3/WxiF69eCvUe12K9VFnIYoeNdib DDpseh8Vi/aUB/bq9ZVDHaTi5BUli9Yc8tZ4ZVbOgnATAhOHpyYTx6muxTIPghmMgo4GNj3SUsDI inW9HPzTxqT3VWcuBJHe4byUiix0hSRsOCiuKeSSTnEXUQGgujIrWOYmNtSL3HDvAZwFSk98KejC +g3dgSww+tq7dOFEkm1nzHfhFOJpEytCsS27Mi5sKcO9JYs6EX01Kf9vKrgQiJjKytjg5q8TUcJH 4Y5yqnfAhF0KDAwfnWEDEDGQfLLX7ScipXXtZX7lbydDy+m9fKo5xla+plEs45DwIATBIIdDXbq4 H9v5371EinHQYaaWIhy82oT96R7q9UFAVFn9NsOkOBApfm+K4ipoeFX+QDtIE369z5unSCGqsZxE du46Uh7EPhAKQb2ijrB0ErFWdESxWu8GAVQQxFrZPzHHN2i2UJtCcnf6DQbJRsKBkm9ZVcV7+Ucv H1DIdy72P0YzIrmHPex6WHYbi71Mft77EWlHnEJ4BIyoL5kKRiamq876UGAxMe9BaEz8oSIRlVrK E3KuyxtKISdGfRUmn0yC2UcdkGMgOSkm9KVpLX1DEXJSdJxMb9lHn07v+kl3ek8MUtWRYKKiaaKh j7jWzU0Iv3MZsNPT0ik+SS6mN1hCPaxIYGTLEvhACGb2voE8to3uwoUPOXKtTpNUlvdOGUJOrq92 41qsE4fAax5kh8r3bEGizL1DmWLr5SdESzUja6NDFrW3cDZUOidnNxJeFklXxXkfCLkODWc/HznD FOKyWSl4TNfMIwtCxDOGkV6nDXFzYmGtpc1F8YG/vhIxSCXFuApKzpPiQJbCHhOdazGZaDBj4rCY 2FM5MyfGHHo7nSq1pSDpiIoTZtLIOye89gMHT/eJb55wBMXVGlDsqBz8epK6xyKu7NO7H5BIT7l0 ZtP3NSTYG3I7nf5dheW/y2aQDrEOoc/roU1uoUOdNgRViynaqzbkVauyXpVBpINKAlnkD67ZcZEF eBy7E3Mhejl2DFpVHuSkeRAU9bI5JGqyqhwIuAONIiqzOg4BgsqSzkKZkGXlWBHJCkiMDMUYBVlC 1WkQDwtXTiQRSA5t3WCU3ATsdfDYpoBl0yxEWdaUskgZxRoTCoc0OJ74mMyK+RAGOSs2FCLAhqFi UhGHIKSbnEJmkUN41seNRp5ISQfpjfz6E0ECePD2SYnEqKYgpAiI07fMIGndgdRODTDWVqWo5VQQ TMM/RCI99vHAodstVqf37kM4uyFFtLZcW1gX9erekFcJ9zaitsSO6DSgIwJZWJY+IYUcG69YPKFi d4dmqJRXpwdBAZYEsk4ASZS8kyhaSwuyCdpzIjYm6ykzSDkzLBWyoE3PPmTEH1WOowrkJgNfI6KS Z5eAQh0ju34NkFzjpdqeC1Oe1yeAQuA6QCMLIAMrdWsGsdt5NjF8TIQ7BCFxdYX1kwEjvIdTCUNZ GvSNc/5E9KTrGCokm7gAKfpBC9ZpIcFaKK7T6f0dQxsuFYMQJ9imM4xgcbUu5A8DBTFfs+kxwOHQ h9LS+Vj9G6/b1BoS2ZBX1Jy8alXvVk2IBH25ja2vFBY71I+M9Eb4is+VB/EciXqRU1ZYzAgmCslZ EGzU8YVTzBZKa+Ew5K3QY7O+zwi4IoMbQEmfp0/IQNc2f2HZl1sSq6a0aDjEnKDFyI+AQpauvxYY O5dKHJlfj5KtiXLHcqbPE/Vm3UTwAgYpTycVV/qUDbq+NoZIsitQ0GVYVKxRv6i+moBClFmwqzX1 pWxS1NYdG6Yuas6rk9mivdYZolDpQSa38PE7Fe+WSx9Qz6vwGOrW2zodgjknHNbbp5QIModajlUQ IuRh4+SORiBHEMkxg+MIhJyIEDk6db7yYORBOqDkdOVBOgz+aVfxMqp6V1whkkdknZeFQDa2cWqW 9t3e/GM/5oIwJZYMqcJZCSGJeNLvHfwXZB7xV2laF+EyWyQaWbBHV9/IqfZlqmv07Txe1KhcwuqU nG+fmLQCg4TEmtCATAwcEwqsbsJzfzI6//2kTyf/LXWVcXNKP1kzi6gpCcnogQaGJaNS/uXfrR+k TqYHT8hUxMNgcS0SyKHuE7mJlfHFVo9kAhGVNURLiAmsLcvfDRMHrMDtR/n08bVg49WKFokQwmNC W6KZ9KbjZk9DQYO/KSMPEq90T5uFsnYJIyw3QQ9ImgFky9Pz5nQzIeXP5iYxSG4ZT1473MLIiY8J JLHGiGhS4Oty/atv2pCRxCKPcLZvQkkSWeHdARnkER1GhpaFl26pQS9XYZCJMogSSNFZWWZN1HtM zJIoTE54z5hkAhnmNuVksDp1ZBq8mBgqAC+DGgmkVmAjBCUjo3ePYkmmsNpUiPAuSkQEIz21VoDo j14wnHdgQdbh4JtvI5Z1iGAWjHrv6z2r65uP7dVppMdX2awjeutoLbiaN7RedRVcJ+KjQzbE0FHt LHTSiBVU1jDVjJaxgUKY9OCcy7R2CmEsWRgCjXVeboblDPUmGR9xxiahlGjjBi/kMHD6kcqNZ4GV nY29cld+W2KNpj3EtioOLx2HgM2FOC7QnktsDDNbRTeRR/lDMZls9CowKRhpyrWTR0Bk4pLK6IN+ BIJrcjIAGMnYS4PARIc6TU7+pnzx2PF7+GPYTW5wTKg1C4XhQd7KHmSknOTP/ODjR6176jBEb/o/ BhGbJOQFi66v8owTuW97m/yugd7tNX2kw1f1HwKV7bZ5s6osXdF23Zt+NPIQieX1iqcYHwMPcqqB csJjDmK5VSdxIIe4SnakDQoBQiaZQqIppDqdq7/wl9G5P5Zd1eG+/l4d+LpU8Kg8PIFQa6zMbhbQ ipGMC5aiMO7rhDIwFOwBL0XLoBAxCzIUYVUgMiv/z1CJtTkXWGwEFgIRQEXB0jXlrJbjE8hEuINQ 6eydTBnlWoBwFGDIX7+JlNZNjnItX7S/iPK5UpAqa33hgmGs2vRA8mCnk+dBQCF+OtvJPwAIwx7s MfgyHW+q+kMXX8ODsHG49DRjUeFx8Eiv9U+5yBo1GBItApJiRwp7vFoPVcMbd7QdgRAb1NtZd/rJ pJZqrWgobE52JUrQvXZqayOyqh5XYdYZ20JdYzEhnN+wlFzhLE16HxWc1HQgB/sRP8Qp/5Hoqqgl AaEKjRkGAiLV/4QbL1gR70UoyCFSZTlGFh7vmkVyJBGIPU/sTwUYRO6N3xwJIJTyj1TOdzvloavK OX+a6L+efF0gJCAo1wm64eRnj8ISjRKNImRy6k+GoIKhcgKU3yhf1h9Vjhn5fIYCjGretR+EDDLU Z7UUZGk11gF3idAOJrlut6d/n0AwYpFbdapIVkqn061vD6avksZCQS8pZKvbdbTSRA4aDWbpUKAc xVJwNOgrRCq9aneu2wuTB9GiLBQs1hWLqy45EFdd2BlikV4kC2OjDhLqw3AFjf0VgyQ81JRRG/fM LA6uq6hv1ldaDz/Ef8l5pHqdJNaC574fkU9iypYHsXJ3u6zZVbml636XkwFXU1fl0RjDbl1DBlHm MK0lj41QiyCg3OWfTdHTCXLKeyf9BebVvCYAACAASURBVEo6prkEGaK15K2mLx+fBAjCMBMVCaLZ BEVHGBX51EqQCJOGUqsxpLzbVBP0pecz2qNVhwMYxA7ErQ9chPvHLz4jBSbE8oRDNag3IIJAFsK9 XtxrAd8suI4a7t1qa1Wjdt0yhsBIaC3TV4j0NsiB7CoPcqo9CEoW6dKbqqI3DXr37hAOe++8qtd6 gXRl4WbJbSFXcd4rBvHXDOkqhjJlECTXTqSObhEUiXEopKKmeCyxXHeRO3wWiiXafeHILHRXjGok PpgQGQAR4Q/ZmVJuhT96ckhvKOkncqrSjsiZ23fGEJ3eywNiXHLWd8YfXS+gEPiUp75cj0Ysoq4a Pf07bSudHO298u5x0uuPyJ9JBRBCZoocsok89uARMsiIQnqUmahZZ5bPep6YE/mHSk56KqzhQCsz JB9SUYjXvx+wM2Rbt4RkHyK34tEllf6q2NAwlqZDUOIr/9/RjZ4NZsiJxjr57nT+2bhl1gUjzIdo Z3pOhHQpiNV5oLcDs6zySjYULcbCqXECO5/LmUAuNw+y1ah4JFmXxejnAoVJeWGm7/c1lmMFSGFq ZEiT4qs8YiTYpdVYA9tLgmNmBl3gUO6CEsFHP5G9eQIWObt7g0jTBaV0ChY5obteX05IJuXfrE9G 377fTOrrUd8D/lS0FdVlqEBbtpwNhkYxokl0lb+NmUFyxftwQFj3wD4phQpHOhz+QYgc+DTsfX6c xXmLissu/YAZDkYgW3iQg+c/3jxPqAc+7kTKso6SWUc65IjxP0d2FwqBnICQJox5t7OaXSOQ7EmU QOT/S+3uRhzLj1ZRmtW2qUTLEeIXZRCRHTFFzs/XSiaRGz4QVnEQ5oRKalH9lus3dOD1laQahX+v 4lsj4MTSaaYUMzQQ95Whv4PKrJn93z0Zhs3MVBZNiMJjoxjBySzwEC7o6/O87/T8N1ZRrdTr2a3v HPXkLj951BJVg9jR7j0gU74j/EJiMg+iCkwOFHAnEW6MGvc9Qr/vnItliZBqhLWac8JkiMp3e+8f 01gDZz/Qpw+WNRwqqx4Eov3pvY06CadeEcirehC6EC086Y9So9XDpDMhcrRK3oZPoI8d80tjAuEa dX3XYNKO04WJQNBBtYox1j7fpNymmAAk0mI4p7W36W9zYo70XGUx0lnu0KhMfTYfobHiN/DX4ozP y9wMAZcPFZZdYvIc0aHw8CRJlSHRvwIzjWorh8x0kZAYEEHHoNKqVwbZ9Kayyj+74cXNCP7mN4aF 3qgE8stAwStopunlAWzRlX99+w29oKL8oLysueVEEB4NTAUaJtOQQBEg5TzIpa7njWBVjHm3CniD xj8UyCKDKC8NrMca+mt8HIiSt1TZm1pvNYz1GirrKBCRYNarpAuPWtgrNOJlJ4hkHTtk0zsb9X5E EsSiVqCQFMRCGEvbRkZT9lM2ndbDq3lXSBS2bE7nBKDzZpkmWZNB9otYjVOTxjg8FeUlyaPnFxkP WVfVH6UAFnYpXDwfc7kpsUZVvyg9YUyLSffBa1Cy5CJQaNAHvRWIqLoqgqufmNLqYT56QCGeOvkr p+/3GTCJXHpFAWDWGR46e9nIS1NoDSx5CDfx90cjokjG2L3b9J0edq15EE62SqsKD66HaNOtWN08 xJ7bov9AMKt3tLH7VpnDK05GKOnDkdiMxd4mnSDYy0jWK3MhDGZtDRyWELFQ1rHBlgSMjzOL7vDw 8K4CxTmkAYcgmbjTepNTpNFThrBjKyH7QbxBHSMcYEPMqE82My1aXKR1IRV1hEG3J8dEthXuQWoE ZWs+opCaoC4phkVxNRJdYw02DijAqydP4ulE1G9ZbkTJI8qYFR/iPQwiRhp+rV7Yua9negdppQYF ODAg9XQcfmCGJjkRSDajGX3R8C4qTn9XpeVASD2lWu1B8uk+cOhPzzSIdaiz+n3AN/7IxZvZe5VW TBUeRukQNyPmQLa9dt/2mPhOD8Iw7ysw0mgoS8t65csNBjlovzqTIDAkOqkXu6EtiHXS3nPPD8Uc hw4YYR6dlBIRrJRUx6rCatAifbq3Fp43s2JVI86bqhXz3/YRgXhQ6spqJHf+AULiMmaQQAhgYq0i l6rHsMZFIDql2vOkoKgA1tSiIWU2G3hVeGwMJEOvkd5er3DreNWfy135ou/MzTcuvuTk1ReKJzvL 5WebPsjHMALA2buGrE7P+663X6IxMP0BQ2FjjKN2hcZFbp+so5DJwnodtIZzBwaftHMKDVRWf3KI yYvfu1ghFhSb/sYBvbeDxbCGCiToT7e8oU3t9ThWX9e9b2WwiTOI5gxlHpCSSINMIf36yYNYJ+gq K8VqTh33pu8Agxjiqw5eUiftLrNHRHjdmTO1vrIglj51uS1E5/Qu2Zzu52FyzFWuj6+DPSrWSDKr YpKw7U4gIatGXtzO+Pgf8IcUVv4KhVZ+mZy7NoglAgGH9GrTh15Q0psXKXcRWxbc0keBiZzVGzvB N3ai64dy9ouKsp8Ak/BAr/bVDrghSuw9g1f5jcQKDAx+Wr7aAWtqXNofgj9qBqnGV/coxsrrPYc9 dob83sWm/hys1mSg01cKgdpyCxIoIY1I7QnmVocNoQt5fTWrLi+KF2kMJJYM2W4tmhWFvbYsBFVZ 3ObVWPE7jYcGsdoI9nYnRHcxC2hU17sCOjpPpXsYWOFhKuuJC3UKOlRlofc2zrzqLK4M9qI+zYMG KJ+CVqrAb6Cswp6/PfBB36ul3lWYayyxRmkcp5Ahl2rprjdIrNmQPUj5xxWcABsuq5geKdoLLn5i B/6tApeNGe4zkNDYt+w7wknOGU2PPMtG/ysFcBtBhdLQRgFj/0H7UXr9crAxedVP1MC0Pllx1JfO P/iAiFIIC6msbvHwh2O9AySZ1SrC8wMao5KTNAfIILIFg1hhFhsMXWLhJryhdr15618LPF6VQrZH rmhDvJcbEIxCooBXiKJxg+5RrK5jUe8ulfQmdHQY10sOYTWWqix2F0475tKloHWYoTs9S5nRWRz+ egSLcWJkhJfk4JNOy2Dhb9b/dvbrwSTDJfHEH9BYwSE2Y2vQLYjmTRQiGtXW/7MLOAos5GESENFo Fg70tNWzue/93NVT34AzMa+Cdxr7Nn5BU/0e/Za9RU02sV9sZGSx5QbhLYkg9xtkLE1fwYQUBkkC qx6OZYXuzIJY1cnBoGNAGRwh37n0nF1qeDJwSJJQdJXYfkmrD4GQCGdJ2eLWik50Q3SfhjfkkkUb 4aCli3IgHbnmQY4W4z02TVgRe0DJYpeQYAa9SUGso6fbuyoPMmYQFpt0beBjtfJMiA5ZfLLN6cvN jEvZvPU2G5HF4hoBzhAJHUCGO5LL6CcSKCoUVW9lPPghURNjGb8jsTJ4ItQLhUWfleVVrw/iQQwe ghdQgwLDzu8exNHztZ7wfT/JoAH5MFAMzAAe+BaoxWzOWVnnHAhy5rFvKF4MYvQtk95Mes6EJAqB vegRfDow4Nsf2N5hGDoMRMGHCutAE8IOXqvrHXqObxjGFSc51os4FmtOtolDtuQQz4nYUGtNmPRW loXlIUef8Y7JDTGu4eilu2MCOTK+28Gx7xKD0LLnWt74LJW9x3wTKVocfHU646aDQ2NEIItLPI3C u6NUCFGTCGRkQPRQMHCJE/5aSwEc6b9egyQhI781qxAzLFKMd+RCBo1T9HaVc9CPcOITLjzaQAw5 EvQtnt39hhqqt096sMekh+dPITLwiSLknPAG9caPQDCKk83phxTljUQIE+YDZNYBxwd4EO3mcAX2 sbQifZggszx8DwJRK6KTgKw/fbjGx5s5dsZ6t1HSy1TIKzTWq5oQbRBRBtGBpFaXhVyIuY8jqxdB Do1786brEkqcQrAxWjtv8970jslBT6treGuVWMTx8cSSxc1yYuNNfIYclM4oFntTTFWiKVMIoVNH tGpkXPKJzQSIs1c2JPo/6/J7Eitb+KpPZJgFWoZgkBnAATQMprDsRQ+Y9MonG2OVjWsvO697irGe QOLZ79TSR/oxQWPjrGIog6HBazAIKmA2ZoQAv168SltHsRjGQupib7kPtxx9ar1lVpxwuuaQgZ/u 3cz3qAo+2LaQg1OIFJzE0sLIiKg3t9reXPc+ohBlkHIgFb06MavXypP+aFtE4EFi81S0TVkyvQGF NFcUAsFlk3rHvbfIDTJ53jIdgs84pzcoZHIuIstmWS+iO524yMYiTu30/ggojqr8hWsKyf+BG5cP NJb9j7ss/qDGmqWDATFeGPVAhzAHnkNhDQ6aib6l+Djos77Wk3WYgBwmYB1IqI05bcgrO+sTUggh 0I+jDF+jSJsQiFB4+EX6w7VJr+JY9peebenKJVpqaJ0hKNFSL//REAfszkF0l3lFYyN2huw12mvt hYNPkXOEqBl52xpCwoW85UyhJUSMSraWFMG0k63AwqJYxiHdkSbEh70LHE5BIMeKQJgzbNI+nYpB mAUhSlaeRFwxp66roRHp3Uywb2pI800q+TLWRqOirEQ3o4RJbr6t0MCv7DMatFDx8kGicBi7lt+V WHQfQ5JZtCBhQ8x60KiTMwZ/6BH7tXvv5NInT98PfMM+JBDi3cwuSK70zhOEWK8JF/uugquZBNKU TRQoZw3zZpN+zQI+EevgHsRMh2c1OO9kXKiyp9OHPUf2HWn5fkBrOpsKh57TG0JnbRnytR23Wwv3 blGR5aFeRLK0ehHpkMIc0mtYcPHWZA4RcFjTlA0lZUT39wmk6dB9W2EEMGnbrK3a1DnFSdYY1Hse MAJoNkSkd8gnciKQWlfVkusqvHXTg1TKzQ78DE7MEBC4VCxx+UMK6yoPP2OufbbINt1hAnXV+wuA JOGFCsxwU2Np4gpt41+dmDhL7KIfU3ltjBhILFUYmX6dbBQEUh46LzUZjbA+DFJ2NRwQo7VS3gPs eDSXWy7xhkkf8Ih0yj76dAeOfTB8DLjW7YUuuKze3XtDlB763BRChYWqkyMpxEadSLhXS06OTU6G dDa6QWBwBDKIjqamEGsyNBti+NjVHAKZxZzIKvqmOlCINKdj1rvMLTjP0kK20C0feJDkKG5Gdse6 a+RBKqXlrJTP6ICGeQ8jlUuc+kNy9d8JYznSqqhv5c8DH3zSM5/IIEr6wMakzxgZmEBJGNpM4GP0 BYXbQLpR1AwbO+Hp58OkmEZT4thYXZiEgicTHE48inU1f3RIQ7AG9DkZWxwwPw61ioeRsU/4YEjX IMLSld6T83sMJOXeW5FYgxcsZgqx/nTvnQoTsk3q6hUvRV414kWOZkQMKNohgnU6UrcoKRGvyDpF 5RWo5FhRSKujSHVabx3njeISz4wQJ52WZsWAkyfYdOsLsVnWPDv3tz1IQkhij/rqaEka7Aoi+bmc 8JH8/mCs9ZDQhK/diHeNZVegh/E51NSMwNFX1yCTLL0cFZlBBnwrQcQ1mWfmmZ8HRACzifn/iJbR nWezwocNC403jGLtg0Gi2MTtwp4TejVFOHjblPWI6IEHhSsH4psO4fFZJI/2XQ1k9WpiBtSdjEUW soU9cupbK83qr3IhghDVW/2rmxDVWq+aDmlyPgT1WFbXizqTzowIJvVGLRYqttSktA6PanG6F/EG f/hEB5b1pkjvWZOFPsv6lgcJ/hjBY5ECWKPHS/WzI5FVW3U8uAlfBFcQM9m313AYFpWu+kBixVcr D0KQDAkXGQbxKrkSWPlJensYfTeBI961035QBAyBCHlE1tFCvhsPdpnp0DcUS3qERKGDxMVR7xix rkKYDnbfRiKdOwyH+FkSDKodh4EmhL/4wP4SeTQXgohWasH1563efNSiYgNFWQklr9tXbxHR2iyt VowW3MaF1glZkc4Ksmg0uDiEsHACsUx7h92FaY29ly6u0q7byBd2K9dYbAuxUe86Qo7rEPSyX+Rz uz6XM30QNR7XTRrrliobAW8xfrcWUAkZFtDKCuvimBgjoUIPMX+LQIgQwcjBCSGYJMEieOaA7/U1 mvAmvq3YOIBKwCKDCqzenMmE0V5DBpQWtBZDuzAgzbk3uSXyq41+EGu8rdxE5L4PWBJ1YPm7RrA0 qIWUu1t6n4mytyEo/SH8vIXF+sH7S8zGIIylHSJDkEfKh7wBI1tWwINEUnt6oENJRNoLj+Jfjq86 dPHYR3thZ1OATlrX2+X9OXlrunsQQ8qu86XpwSAr33abPYjjJE0ijcXQ2lq4HNyHjKV9lQXJ7qG+ X8ur0a2SZRkcV9bbPxzoREaXaKfKb9ZfGdMhel5qiPQBksOgD37S83ynNalFmP6Uf5VfdyMzBDYg ujbIgSDOBVvCzAiqVyxgRXxYNuQ8sfoV+4KHeW8UvO8Rnt3DqqOBiiUnBzvlyScM9TqTOB72+Ok8 TwukgnYT2cs2pAXq2Yhs6UMAD194q/AIF+IqS17ZkJPyqsGwE7SHHI8sej9CTjUn7yaMEt5jlzez 2VBrlGnVLmTVOTQib5hqTqpkIUTWsKyXel7hIp+xF57+o5bBsRFJwAgKueKQtJ99kc/m4VI7iAoa I6gs/ojGsvjccIUPpQ5t3JYTmyyidDLUp3uyKolWaFT49XFsy9mkV2BMhjApPeshjTcmkVRnTWTA x9KG8un50w+XbEJGBb201vAOvZ7HMXsBDgNCi8hw/w4GcavOWBZivYe0gMQ3IgxVHCsuKrNoQBjQ quJY29ysrm2GNvJEo1kY+67JEI5a1B7DEyK9YI5jwgVzIDvkEn03dHIhyBImw95ljDBhqCxyDh+C 5vRoC7mBk6S4xsai5pCxwKq/V6HIzPc+f6sOYi2wtIQKS7PthpEbJPKRxLIX1FoVf+zp1OU0AVIU Jwc7lw+OimARx1GfHwcnEADiAJKgfdevuOJSbmJOEK2MEy8FBmNIMmTSBJb6SRO1WLcyIQebOgof QkrhoCwWmhyCHeBJDFkcrcXuXNZw2RdRsgihJdAY0F04RGOIh3p736/Dcqy3q9aQNFDOnsWCiEtH CxUohJMWbRZpE+bDVZZpLq9aVKVl8a62w04dcyGrLkZXx2Lo0FitJwtjJ9tE51jPIlto59R+5KYT Vuoob7YhV2C6cML1tQnBb4y/8YtFTSgOk+uAFcBxu3Qr/cb8sCA4EkT2euv3pAvZdpwsSFiPg78R iHEwBGn0GS59JE80sbjRNGIk0lHcPkH9lbkQjOeyzpBeERIthgKX9oecR68oBOb8MHBTutUWYpC1 D+oFkUTcKhOQMgd6CAeKMWwaQcXJYQgKwaQT9yG5Kgt9U+5DNB3isPBgr5GIDiQVF/Imm0R6OHXs +Dyyw1C0FrLnDZLoDSeHOVJEbnUtYXHl0G11Tkuw5Jw6UyLIp5+99/Y824BCxjJrEVgYR6PGpJHe TEaFvt211liL7Rf+W6uz26oYb2DjFoCyc7rxf0Hl1BcJHcYdcrw3mz7AzCp3aLLYJBio4hCRYbr7 bEuSe5GXDHSxsguZ9mFi8Sqm1idxR8eVTppnFr0BSqxHfXPiGmgGeuuUX++Z8oFuhNs90eNh3VCD d04dPMw17N2DgFdgVgx+1kC119gxSk58kFw/VlhMGfbGHig82W69O2S0MVosuzj041areova0nFA nGutQSwd/+Ozen2aOwcC7Tzee3IKQb0J4dFBZGWL7rMV65LFcvv3v/z3f//X1OaQzmwQ6WIWp5nK /X/5pXwnLPVV/uM6XhUR4RpJH1DIR2+OPqqqstJ79nwDPbcg4hZ9kSlECKS3R70Zk9g6TGcMqCqH R+3ak1cfaM+RPLHolT5NvIBrQ0PuVcBGD2kmivSfn+0QPSEW7SWDpExhQgj6ZHW1uYuhfZrVy4Is zxYipd47KAav4cU8xuFAU4+SLmTVUbao7Hpgh0jOh7jWslCvxrF6l1M5aeiokVFAxzdRWTLbuj9G 3aLNODk2VvceWwubJK2OaXqDZkxOkjDU1imwSDSFrJxKVpE2dCNiE4D+9b//8stfvnEdAoz6guUm 9vCv//1v//2nx2t/kZBRZTgCQlcI4sN+kfEV4NuHYhpDJtIjF39tdYsfg2sYXZ09agYBEg4mtA7Y GWAYsXhmZTrSU6KM9Aldudc6OkZ61vGyjsTrrFBmYvMcDTwwH/qy0c0lE2SQ737Y17UmyYUgC+5S yeqyDjype0anDgOZI2GEHoT5Ri/IQvliMMje1pDsfQVuOPTDiEC2FsfqUZxl6ZDKfVzZES3Kki1t OgzoGNmQjveYIMcpWZYcRFQXULH8SGisnaOgazkba0Ui6TKD6LSsVXf+5Zd//9Mvfz9/+/u3yfL8 49+l4uTb31flDHr8+zecqt/+9Mv/+NOfVstv0/N/nC+Lb38vZ+S3//hWPj6Xp3Kuffu2WP3HeSEf nWlPHCwjprlx4Zv76/du+wvGfIf0RtZVHyispLGqCNbetJIlAIw3MoFcQeAQxxVMsisZrPzEkuqU V1yy4CbcLAjA0tjH/YYzTcpLGQIk/8zcByeLdH/69OnTXZh0aqy4KDAGjrFKm3PAGf2Bcd6qnDc6 cQcMqx5oVQxzrM8yd36wRpO+9zFAmOJwqDDCYG/PDdHswXW/ngNalg7Ru+ZDvMXQmqdSPp3r0yXT ESUmHWa1gkJ22PiJWFYkQrqUBslM4okQupCuK/Txz//2P87/8ss/L8//8pdf/mW5LHj41+ni8V9/ +dPf7Zx6LAj6P/598fe//PN//eXfF//3X375r8XTv/3yl7/8/fK//+WXP60W//GnP33751/+ZWEf ZYYJ2x6x3svlsshXYIHoAL8sIsr7ATXg12KA1nAzi3KdTDcoDeXrjo69YUT3X2oEa7CN44MWaJAX DgN9SNh39+yJWFiyOCF6lDrgzQd26qZy+Mm5B1lsfBCWyiodYWp74GyvwqfuJOD4VB6+1Q1TV+ug D44UqKrBV3wc/ldvX8/c2JVkWTERK03ptShpFR0VLaOMMdZbo/1WG2iowPoB8xMW5vj7MxiIoH9f zA/A678xxkZQBhyFHEzMc65XDoZFXuy7medk5n14YJVippvgBwgCIEu6BydP5slMRGBM8nLGdUQX 0r/gIh/zIBAZOBMFDIM16irRS8sgOgJIsr0ohwg4cqiHNPYsu+Q6KavSDDZ9Ah4ItVBU17PfB8IQ CrGUb52yh6kNlVlOJtR9T0gU54E9XIJsbu/eTlTy/OHpy+fN66en14/l66en259X/3x7+/QN3Oi/ f7qbsPJ2wsTtn6d46+nuzXr6/Prt6sPT3Td/WX28ffr69dMEkPqjHxf2grTJ3tlbKJDor0t+dY6K s39eUVBc4qDFxEWEFSvpyT7rh+4tQwEw4eyLdSnwRxliZBVqgoFXFCc0mlSIoNup0DXSeU1Qx9Wp 0qi7SQwoio8JHTenm5vpo65cr8twJwaJEZYU09tSoboKtZQx2Bzr5J3pyhc5IIoW95SoODCrGu23 g9tWOEwoZXV7IcISiMySvTsDihdC0GSIzzHDG21aMt36KHtwD9p+61tDNNsrV07NhkLBA428QMsh GrIMIyNrIQaUaFzEGCBhkI811/v1BJDHu7s/fLNZf3P73d3Xb768/ebu27Ue1AkBd39aPX/39PRV +cvr6U7r1ea72x9WE0D+OB3t6ce/v3v6cC6vb7/55tHRsVQUWZ1nF4KkAU8Q3G2OuVEfnihTmJw/ FWLFRO9KWQRjO4pID1QL0aqqSEmIoFArGWK8dZG6UsowGhFsTG+4oWwzIyw0Vkk3umVwOx1Dp2LD 97rdYKPVF+PNzTjRx83DDRgkNaXCNsxqa+E6/0dDI5Y14G9kJsvyVEZBNEAOxRgFOV4Flk+PFwoB PHKe1Qu1pm4KRJO+nu+dG3yDHpE6yFFHOWC0tbWHVBYZOQDo1FODHJDoxdbP+5OJdzVmBcOiT24A h7Tl9FEn+X5fATKO7ypAfvru6avNev0Pt//8w+Nqiplef7vGC/QPt0//sFp9+TTRRPnD07ebKtxv /3SuDPLl+vynCT+3lUG+evr2xyjWmd1tO9VnJz4e9JURR3OfYiDgs85LgJ+OsJxAgkZPfJeTDzmi BJIVKhqQl4tkVZvmBQCywSXTqbjVsAqtglb/83nyW6hw2R0StyLqhl1Z03bT3VQOmV4abyqDRA2y BBDdlF6wEor5K92jBp8V7VjOIXQ0KiJk4Q4rHew+DBEXCvQl5nnpyRq2bYTFa0fQyBGhVr7kjn34 rCq9rkfIusPwYBwitXQsRmCM5W4soxPjkPtT/9A23rpMdxUSFbrgRSlk0iA/fHgUBnmecPBh/e6r px/erAQg363lTK0/Pv5xutvqh6eJNc4f756+nG77rkZdH56evntevb99eqrYOf9p+lGJ+iNSyFIe mDBog6+L9NVlLcRjrcble/kWqyPAx9xokrQAgnii0GskMh1IGIqhAuGXa/IGNp0VOYQ26sxGG4Tl 6pxfumeNqrh/RNDR2363Uffp3mg0fXPqlEFG0SAprLldGmGdnEJ0Ki9thoXthJEyBhMuxfK85vUd zI4ycPpvWDadMmUIre9D8JyECEsphOMWEWqFUkhMYu0PipN+LxtEjgcMXQz9hbqZzZJZJJEeDkUu 29Ee9gfZGXKKhqyYuYr4GGE2wd7bSYP8z69uf64Aebf5+ZsJB2++uv3664/rL28/3H37Ts7U44SU 17d/Wj3e3v3T6vmHL2/vfpoAogzy9bspApv443aS5+WH6fFvY8mDpJE8huKCwtXqAkMBKS9WRTzO mpHEizGW/czCKzVWGHGo6lCXickT5n0bxoiyQ24FgchPrBEXEsRGaFkSq1LHc36mg33U7VZKHl1v HDJh5KabOOMkCqRGWDXMqgxyQwbxZekXlRAeXAmtuPuGlcLBNoUYEIYmvMLEOL5m6NDqkPUqcAmz QT2Xi7WeDY3sEGodUVsnPLzH8MixJ+Y6yTqYtLZP9Qixerbh9vBkIZd1Gn0vwj3bDs0W3596c/QG U69GV+7tbXJYaJuaHjCJh9e3GzpjLQAAIABJREFUH6cQ66vnj7ev727fTtD47vbD+sPtH26/1aP1 493t13d3P642dzVldffd69vH8/p/3FYGuf3wtkwa5E4A8vz69Xf11tgxEuohDLVWi7BYna+iQh/e GMNMrnPhToDDpRer+DVApCGQRImutQ/odLO0K4UMxSOtoDcQWdFapehAxqqOMlU1XjSZi3f5UMKw AuDYBV0OASL7DCcC+aIbBRkKlIlEHipAUAhRArkQIXQhpjhd0drKExX60DyEwmOwEvyQ6GBMRkhx pTS6qFSB0HQw5O10bXsJkaZ76ogCiTkWQ4H9KL73CpbDbrf3iUAHTlvEGsMR7l6uMLxH5UMjLfas y3cPlUJC360necfLCCvUQn6ahMXT683zh6dvnx9fTxGTZLGefqiy4+mDnqz176dbfl9WP97ebc7v Jqn++k1lkI+VQZ7uNhNAXk+XD+d1/dHmzLE/iKK8EEgcxMRvK1dWM/5oEsFnwOSiRPIpL5ZeW24H odMETl79LoUKCUjFG6pcdlCadxiJUjpCpvPAilUOdgV2HSeNjrkzwtB6IK/rytBa8pguVXvc1ESW XD3d1FIIAZIsz3vxpue2YEB7MBcqi6hWL7D1WnGRLSFCOCiCZFzLgUEAE59xYjo9Lma7ZBDrCwE+ hEJsbJZVRSwIO2hVpLcYK/eY2StDstBAhQjLwi2fnQWcnKBKdJJcq0QuFAjyWhphPYyP39y+/nn8 6ee7L989//Hu9c/b9U9f3X65Xq+/vPv2zxhy8P7bu68eV6vNH775frX64fXdD9OtX9Zb/vd3r7/9 p9Xj7z9Ml5/lRz+TLYLmuEhbtQIkEMXstnO8Gr9BgvfcxlFXKoUhx7tQJXTiEKmh8lbkhxtLcoys 3K9b81SFfhLUyzkcDo20XiYX1sikD/DIdqQIqYAZXaLrSmmsAK3RlSBFL1WHPM68WA1I3MAuZ5lD 4rK5TQbOcLB2EO8rLMYbCgeoepuVld3oK0ItIdFbvJjOOUA551avKzhUo2ctFjYUMium7xUl1dd7 UGNvf4h7Q9BgKAuFTZufxpOvTxeLCSb3PrAQYhSycWvJjDkeVKLDkfWv7zfvxs3bx3fP794+Tsgo m8e/TP/n129/slO2/vO6Hst37+o3P/5Yj+a6Wk/Wm5+mO63eretlulF+NFPiIX6aV0TmyGnr7vMq PK8gbWWfgYglRrloELnoAwlcYcSRQ30kuSERakMh0ilqzE+ilQ7ByFZXVlVQ6EI3zl+osiObgQRl j64mr5Q7yCCClFOtDgocKoV8MSqT1ICr3lQZJPkCnYXhWEPyikfKmCOHeSbcj4BTT1qgNQuTUMAg SjHZJ73bdJREa1aioVciLEJjeynSySBCILuKDSEQm/++a73wdZH6/qBdVflw7H2aXOaCtlPPRkNU 0FkoPLlBi3q9x+JbL6hvQhKriaxg8NV9OjLs/R2bQrBxynYhzF7NpyOawnUedKmQr+rLGVHhvJG8 CdczvYsFwxmDLH7jkxebgmHz1mr0UiI8rjAI1flQvHo+K3iYLleQoAhoZt2CyiC7oIQuvEtwCwLB qulu2xlKRm6XBnUoSm4MKzWPdXPTfVFFei0VTgh5fFWST8ZaLITQoIsCCL/ArlgS07QEhxU6SBY+ AB6V9WLShm1UDNriBCCjkgH80TciHeZeOk+EQGZurCadNd1Ppp1IOUSFSG4GAo0w9tpuT+mf6jHw 5GAd61jvaUNIaegdFyIs3RQiUPlob7/7+Lv3enn7/u3j2/ePb6vf6re/tbwQioMrIsNV+6zQ3sRf M4aRTerWAHJmvaT4lzIDBqHAH5Vy2UjIN6ZvnUBYH2zKgQaITu+Ob+BJFLNu7rDsUNcmMHeljsNq 0H1mnKUlQfmoIj0yCIFxkgqIaA8T6RUh0CAtf8wSvTb1DcAYICRo5OXIOOKAaSyb8sMUceEGNpZD VLnYfrfErWzKHwNIZAg8EksiRxPq2l54ZEEkL4RaB0Raio/jDtCwPvVaJdeqyMH6QU4w+LrDV1ey AR/zKOvBaiFNFYQDez8+/Te/Pc7QYV+avO81vrieyloF3UFgBGXR8AjwYGksAONqgAVwqOhIQXa4 BnGjFfFBBiGP8F1phKoD9cCMiQuKh958Jb1CIzDIyTEiX0+4LjC50VKhivQU+KP181KkU2Fn5Hr9 0LMSkj3dFQoiWJegUdYFhegNJtM1BawUwrVT28ggyiGm0pnr1SZ1tOSGIMvcWPyubg3RpZ86uteH AcEBz96Qvp1p3Y9YH3KvlZGRewujQmflPDYWcgaphFf//QCZKYuAlnr4E5FxXuCIOYWES7F7zUb+ tBRiwNB0LgARUlcLEMntV68Fzjzt+q65Kg5OFPIgb6D4UTzMstbZ54qG57oTNKunhNJ8NNpw+jjp zmeJraZQ69RJFmu8MR1S7e4l+ZZCRcecQTD0Z0ClY0DGV52YNCsyMRU5RJlCxUUSGyKsXfJ0ZQDs 1LKFp9RaSNFZpLJEfctE1jYgJDKIjTnJMcZqcaJJLOkvFJTssBrBMaKZLOWQg1pMpPG2v+foXkny jnWRoTuxvFY4OoUEAgG9TGD5mzLI/Py3BDJjC7/HyxQCX0nxm+giCbgga7TdH9fRMfdTYUSJYUSx gQDLvFVKJEjwquvK8lOq1be4ZKmZV+MVGAT5XSWTOUKcQU4UIjdVsk/f1zzWdEVCrBSrIHMGSTRN laTJuZyKJXlpVkTyil9deCeOBaKJUb8OJuUxT0gliBATLFlFLb2Sz/IcVh2QqAMcKljQY6j2d8n1 Oom0mSzARIdaV/44cixp5vYp2E16Li8cOUeOZZD7XgmklhGbKIujGzgDiAjZYDTWw98mxLrGIKnR IPMkVQugKxRi6YGVswTFhrME6oEeUq2WsVGMKrJ9Y1GVXg3CI0ZXChJzlaA0SOXe7J/KqAlmEMi2 cwZxeASHYlDr40mLIXCdCDIqgUyfJcQKdqw5ODQgAgmwndAG9rqpvYRuWsr0kji8Glt2OF1R5Dim M6LjKqPXRHsXrR8k+LFCvZByHa3pptl3tJ/kSCG+Y/2gOOnF4ItduHC+25rPyiBsRuck0oNjxZZO ncaH0BjinkXXHtwJDcD8nRjkgkICShoGWaSQEgKrFLexOSSIGVvVWwwd14R5RMmlLZcpXdXjbtTV fZ9IZqGQLiFXx47aLVJVnNpTxQfIQ0uDW4oQ4MICrY5pLFKJxVrT1RuUDk/sKIQACZFWE2NlIgIF PRnbQPf7kGnNNSpBjZBNVUpBBW5HTHmQVkOoezbdasClZhPp4S9iWpQvW+4P6uXCMUAZjiwuMUQr lWKkjbbUFm8RlqxUr8msQ5hLKpFVxcGBhUKf+G5LDe/lvxtCLE9kxUphm8raKJP8/Rgk6oxzvGZA eZFCYhqrzVpZuirmcqPuuIYLq2ZELe66AzxRCqkCj0DxvMPt9WqnveYdJzBgDQ76PjB9WsyJWycO 1+q4MoYo69QpPLQkcupgW9T73NwIQIw+mMwKCLH1Oe4uGdj4pMUP7ZgcvAxi5kT2JCYd14DyIjrT lUwyBYpu5tEG+DK4CKmEUXL7tmOcpdyRUU+Hxdd0ui3FDcnfCTc1wNpDqguDYC5pz05cTWiNWH/b c1sbqiKACcwm9mlj0ZWTBmX7+PfVIF4cnNtMqMxXVwhEbmcSyyUHM1jLfbSffOucQCxwYi1Q5koX +nONQZDV9SFwYBNoconEshJI8VYo748ym/vWoyxtqm3lSIBKI0y0ReRGGURirDj65zLIgqrW1iZf fQA3lW+DLtZMNRAy2fiFz8GAjd0hGbsQkC8bCsa863isYTswwNIP6PTpVOuHJKpo7qXxJM9LhlZU t7aRuifhMO8OGQ8wKKIUcoI4P9WCiLZPnehVDEJ9Aw4ZHR5uNvm7axAvFTowzuHzPPZqFUjQ9PWK 0cSqsa9bNvdlsGSggzU/AMVWFOgNXu9A/tbLINnjLJZB4LgSZuHG6G12pzu+9K7ht84fozkVhUkU Jy0wkNvCbdAgLT5mbbfmO0SlA9VxRkzezmGeRdumU5gCswEWHLOFQC2HmiO2TREiWQOtDLuif+pV oYc4C03qqB7OpUej2EWH9BplHSlEaOzVUSfy6VRhoo22mOFAD0pN91bVfrqfUQiLIZs2yvr7a5AL 4ghNh/H4X5AHPxd3tLMC4rj4XP7oSkSHLkqPB5/iggldEeAEUtfcBQyiH9L8ods91KyYO2cOG7fL hc7kD01rNTBpM7+uRroRgVZ9+4IAsQBroafQ+tGDsZC7dDgsjm0dCanbwaxWGd3nwdWevNAI05ZZ 4QftzhqgQQaksha0+q6n/+RorepHTANSYTLL+ZpUr8iorSIiRHbwvPcU60Yh/b21pYsAAVxOkO4P YxjgwHL6ppn+YxpkuiwC5HefiYXFG19kEAPKnC0a6LQXmzvKdkPniN8UWRk0CIsSNAhV+ACoGCSU QZjc1Y9i+sMpRK0lqtFRKOQC9ewt6NsMdxbHUD/rdz3ex3DNrb5gEtMnBIgPVjxftIRkGwzHWVaZ 3iouCkmZLSKmP2iRRw4LvkbzYw2kDZ16kjHnelADZNwObSJki3K6yvSdUsiOmV5UQ2wLVchmmedk z0DrULeIwOJb+eMId2/fg0GoQbCASldRsXR4uoff5GQMMppzN0wiDQxSf74IkPf/JYB8SoNE0nCU XFEfacJSRUEiiTQX44/f8BYPPz86/978VR1vh5ddM7ulUSKF9UHtOEfIhZZz3fjRbW2eaMZ10gnn iNb7glSyY0VK7Bk6Prda5PSfr0oTY5lKjxIEr/ND8UFxmp3CdFKrmNNh5XtzlDLwCF2gkAcvprCl ShNdmb4sNoR4lOXhlad6zb8YNiPsdB0VxmZxpQgzWdGrtT+IZXHHJW0HJnzpfe91EBCkuXp5mfrt H6ISCV6sar3aeCn9Uxrkb8Ag+DRni/br/DHBFrnCHrYzY6trdfEX+CMbjdhWdAuugvEwFD1MgpNE FBXqL/EvmsKyujo6bgU9WJFjvSG+32Db8fiPxiFOIFDxY2jJta7ccXz+x1dDG2Jd4IOxUbJZ1Jwb lz09i7Yor6Fbb62deSgMFFVsb4K6uzLTyINOFNKNt8IjWwWHSRCQSFM1dGEe5p3solA342I2Fqkb DevMrIM0ifQUIhNORimon0Syc8K7N+IetAxykkQW8fFg7NGshaY16xpA/ksMsiC0GwppCCVEVQ6G kM9KAoy0gkPR/bgLGwyuAaNDQGXZKCURucnSUTlAqMUNAymjDiCHRsVim3G0Fz2r7906bjub1cB0 lq01YC54G2+2gdVARI/Gqk4H82pV8cEYJGZ5L/eEiBErsV6IbdCJbVKJc3pR+MjJElfW+5EwEL6G UZn+eSs3DroFgWGXBFpaSxeMlKjS+0ggud+5xzdjiWGO2V6DR+CPAwuGU3RVF6sfQjJrxKbPyiSo EVrBULUIoizpTL/3jNZmDFMVQx1klNb0vxGDXLBBFBerBhPni6vN/bWFMK2KZ3g/gyz4bqIj0Acj LKhvb57NoSYO3yFyXB29V7ZO3fdFZUGJUgjvA0eWhlScwUtvFif/dP6dXXnWnwleRhbbZVQWCozw p/znq0gd54UIC07CpDUQmBJlew5NhqiD2EgGGqySzjQZ0NiuC23R257p7lXLoxnpVdZgCCm2IWRv mqKp1zBiNXUMtIYOsUyvfQT/u74fRK5XBqlj4DlJjpHWRB73EmvVr1yEq323PfeEPJxmHLLhdJMx qhC8LwLkM1NbL2mQq/W+Rqi3U0qv6pVzMPGm31bysKQTxXf27wvXP3WADrU670oC6QJzZGOermAc dfaSoc7bZQeVV0v0/Nsu6I5DeZEc3pJTMjNdIuO5nG0CCxLGzIFBpEcVsiBCPEGVdFka4yTKjqYL JNnIhmLrQrK5gkVTIKTKLK9bqKU8Io7FQktWEVfvlhmsrakRz/WiTV1iq2NVIdP7rkGIE4g2juwF MlWEwJaFRkN5P3FcFqdjcXt67xMd7sf5vkL4EkdnkFEZZVzWIB+FQT5JIo98vwDIIjr8oF9aFh0O /uE/LZLGko8zsrwvwqFzHd6RUJCuMhLJJICQxYqTppHApQYxc6JJktL5xF0U1Yk1AEKnKcLXi8eC c2qlRBeFSFT1rM25z+CQjFzXFjnhbpTao9ZUnhFuPQAgnNawLEJsLk/ibFH1ForBF/ZeWtnNeeX6 hUVFLMkR627OnMk76LZbpsLYPSUUktk7lbdDi46+ranvuDxE3Sd5OLZLP4+zZSJHWYebZb+6bos+ yOIQG+SgBfVeKYSz5bAd4V5yXA9iORFHljVObYIbqx2UtQyQj58hQ64C5FoOyyDSEEcgE4vNHDIW YilGKjhkXs/5CjwMBPxsEZRyB/UDLFaMqqwgHuVH0CAAjlfWLQEM0LCKbrGYY63zIaRmSLHfqoNI Q7ld26kylkxtdcCDxmmm9LdRg9BxkpZEegExFHixMAyODi3Awr0mRjpcNcXhoz6RQfCVMfYkF5uW AvmBBVRqfRdPlvdMRZD0yiU+z+G4Y49IcJx4GYSSBJksVSL7fn+ocmRnxsWDuLEOLKVXhX6PPSG1 ToihQA9IZoWKIYf1EhmjmnprR+F/P4MYD1zkpSjAPXRqyCTQCG8rdp8JHmkKsMqiw4rjRmJJg7RB OZKhxFkFN3uV6XafS1LY1FFAEt7l4apewylfRFifzKgmhycIssYdKcAeZpJKdlhoREULl9+ybVeb EatG0RuMQdKMQcoCRgbqkGTFPirwnDgUK4c6SEJYpfPhORNOjFhKIFn3gmgBBNV0DAPm5J/ByupS Um96p3YWYqkOOeKH2og7aMIX2d7gN/FrB23C1SCr1kIyt7QdNJkF3X6PQEuHLmoeqxZC7r2S7qkr thhaQ8jfiEGMBhZyt43EaHTHolQpZ9XnMvwqoUSY5uggczCkKgYVEws4vgyWCCjlCLyU2/fePsjq YOcQ1J9mypRoObFH+P50ayHJau8CXgJCzAWcrXXEBy9u0YhIuPTchbv94lXxGCtMWLwQIZxDrZnd +tX0g6W0fDjvEKbG0bFIDyI2PgscqEVCRy9WTcvddENEqINQp1tNpCeBsCiyO3qrupZEsikPrxs2 JfaKkTqYtD8c+xhlaecUVMgJNZB7rY2cdHRDO/1nZFJ3xERF7bYdr9RB/qsMcg4CYlGJOEM0VpPZ VXzL2XASXKXVleAqOnJ5CS6rbPrEycGsIoYVmwoH1qD4qADAUDhd9mHynFDwHkPmwqz4jo2dFrIB SYjq7G/OhqVKJ9DvtiohrIPWGrwxSHpJgwxU4FbUMM8iukNs2q7P3C3sSEcZBc20hReJsKoYp1pX SgEh8a7IY5V28a3VQnYBIhwElDO9vU17CGwonvbllV6oRPe0hQbc/nSgGKlxVe+DFtW1OD7YdBPf xeY4ad8vGeRjYJAXMPLYvrcMEqrkM2wspKmuEQnQw1IhSoRldak/eMTDVS/5GTqYse0sBMu8rmGS Vkk63qkr3i7FEoqjgWDygmKGJGkLktkqMERH8ERqmGdJNAUMcmZbvcaaPPEp9FJvDAC5nsZK1iM1 YIPWQBe8dockGHd9CK+PbjBPCYZeSQWwYqMU60LXQsgwDLl1sIRBvUMhfWyt99YFSI8giylfFAtJ Io6RXUMi3oBbB/fqhctw1fp+sjb1UUDCz0oh2Fn4AJTQZbJ5cDLZYPnUXIN8DAzyQpT1IkBCgmpB h5xnwGiIJA5dlBhrJTGWRFdltUQggQEsdmpjKNKBxv7JE1R+sC0Ks3tnzr6yrbWRnGLqyyqR9fQO 8RH2RCZhNKLLpuUDQjvEYQRPoJ8SKyfGICUg5GoWS5s4ko/wEdHNDls6tRQdmVFZRp53gB0YBkSE TYONaMg1hEocGK85McyRQ2ch5shtB2cQz/OGICsMBaIMiQWRRoXYlwMcjBgF1NcR8LicwjVppTqg fapqkNNIt6L0hnhj4cj0bnS+/00YxLNRV+mjUSFMarX5Yb2ua0AqkQAe55IWIeIIocowO7owCHZD dT6IGgfRk1skkMA1nRXgjZTs9MYUGYjK0gIRrM0vLCU+RCUQH9ANLEIiyJPkroJHVYgcsk4YRHNI 1k+45Oi1kw57yIDRWEkTWjQyBq+JtUzJD7JOuS7CPBmpLJEkMijOBpJKNAUtAgRS1Wv5ZF4LkUhr F2XIzlQ6RzDGgkhQIeQRgYnQSM12STLLdMjB5zeoCuknAXJ/4khSLDKMMxwwzt3mAKE1fa5BPrbv 76+QyOPSe8MgHkPNVAix0kKFCS9LYzUks4IPywlkLtMth+VntdXUMFDZuSdbNGRg4VKjQUoOL/Zd /AWsgvhNOd67o6pAghjIMn3P78k4nc2JYL4LuYA6+hppsi36sHKrQWzqzyWFKHO4ucrcUzzNtGIF 6zvLiFxti3ElRTfZSnIL1XWuDynkFFHqAhEtiAiFlIF5LLpO3LroKS1tmfJ5ckGox4KIxVp1YfTu uBedXmOs3nuowmCgE6eTSnjVo9uwFtNtDKlV1NXm/oCRcUxsXQPI765L9bcvA6QREsuX5ucBBrMg TDWIlgcl3ko1zmrxke2zndX29dsxMNgBpzzAuQ4oMVzl0h5+B19TT8yex8pdQFzDGdndLfhru9kz F+LVc8slYNQBSb0eQyxONFmASPHZbg4Rc667QKEA8STxwBI6CiCJJhJQiFQbByj1wTd92rKQgRQS DSdmyuppWfSxi0Yh8tVmXCuXWFXEgi3WQ6oOqZK9bo0+GDBoz5KSYd2qjo07WgmRtdBhcbrDIdoU lUQMIB+vMMjbz6CPiJHHljgWcr1+QyCRM0GyOjuDiFWRZRDBBzRI8qnsAQYWwMQYZnbUczxzzdFv n2v+MRM15eKJnHZchPDG9psISHu0MVfzVESeZNEKHZITRMZXg0kQqxXOCSTzrBfrKGRpj/NMismO xGXPSP+GlhHMYRgYXKkgkeEl2tjOThCW5jHihMMWbXt6017YEggMJ9ToUjs8Dm3JMMZZNC9OIqRW C+v1iUWOrfgAQmQcUC8D5Hp3vZ/aEVnMYY1M9jZu3kt0/C5I9bcBHYv0ETHy6LzwuRgJ9402Ez5P 0oGKqdoVS0Mg3N8coimPreycN8exPeDhVj/E4Yjio0VBaSATAUlw+Z/ToqplqBn27C78k8ND5VtL JExgGV/RE0Krokn1NsIq0B/Eg81UZJ7XZrjTtUhMFXSpa5NtseoGoi0UDJMslKLGieZGDDgZmt70 Rqxj1EmACD0nO1jgEWUNx2Nw+YZOdc32ZhEged6qftAuXNmzc5Do6r7XUnrtUX/om9bCTeAQ7y1U kX7t3RjkPaHx9jMw4hqkHc6wGGOd27jqAlHFqEQmmnAdlF7as9ZK4pkmmTFEG4Q1x7VhCn4Uf+W3 mKwBWEsKFzde/pn2zH5f+80BnvEabhcP1zB6iHVOPv9n8Y37z/WVPalWL0g+lTDf3ZbYFuSwBk5j zCyDQGgg7StQ0edEaZ3mxsGlfOaK6ACO+V6ESCPZSobVmjWoA2U4thQyRVfYZzhxyH5fGQYJX8eH TMySXkOdB+TrQkYYskb6sejJeiCDuKP3GjpmDDIDxUsYOUcKWcLHJWDIGC1G1IeVRJ6fxeUuMj1s tzGY8MyXbCubU1iRhpfgcD4vgyYc2RBw2XEdZvdt8RGwFXHSACAsbeNjhkgZM7Q1QG44UL8OxUKs ZDp9UaXbehxFBMIrG3sVIzELyJLBJSUDhuZtNdSCWsf4Bi2zF4zpLfQvDqpXRIOUITeud8v29kvw UC2yU+ciHSc7z/nOF6vv636d6jipsZaOPDEVckJdRIKukR541SEoF1pJnYldn2ldkfLx48f/97F5 +1d5fy+z3uug97fvH9+/fZRZ73r5s05x//PFO6a72/luIPISSpjdanlEnSbyIwFGTWVFCtGT05a0 cKAUN1zlnCR51LxAW/oIB3co4TVbbpKDyIUI9rAhkkA8wQ1H1WcbmtWf7cHPCFNIczpeWm8JFBXg krnnCpexEekvICQksQABthIWVsyb4AooMQ3CUMkIpEFIAVUkrYhA2qtKTzqLVBK9tlsnyHVrEekD PDJUCMItbVl396IRSIOQgzBJdfli006orGPkySjX3Jl1MiJ5iBfKdJUho0t2dh7q2/P4/KzrQuqk s7J+I9tCymwNx/ninbc3BNIIjKtxVmvOsm90VJyuRZddtE0SS/fbhBA+5cJZ5tm+FLkaAiU9eImP T9x2ILtyElalB27KeOYBv6cMXBo9KAya13ie8oYD9PpA5pBP9TfJiy3vkQJxDOHZ5sisb4FBwhrP BZWuNUD4SwamswpnVXNXSML1hFEoChJ98RlQBinZIiuV3wMbCqVioku51J+iEZqFYvJ6kMu2Gdfr Ut3hccxhzQ6bcEO6l85eOk72NcRSJXLY1WtoD8mzfBb2JMiXe+zAPYUxWd5nu/G64cYxstEmdQm/ xp8qQrBOZ/tc1nAAstv14i3WMuYI+LQG4be+yjCi5ixDG6RQWCTWCts2cYKx0Ftfgwtwwdsz16uR YIaCm7PJCh5P3CsTEHhhH5AL0M233Demp8GDO/y2AUiV19tAJMSUrnUL0RUeXNCoJ3tl5SWbrwOZ wVghTCR0uWCQK5V0pnKtnM6+Wnll8IlYvJXPOoQBWsGFBYXOEqD5e+H8JWFlWFkK873cqcNyYcz3 NgGWoWMXaus+zKFJZFV0IMgCg6jnZGdhljXjctWOXg467l18i5cM0lhOVKhvKEwqPjaybUpYZNut u/W2Lpx6M10AjqRfZwKiefEPxvXP0CABS67sKyi48qDi4iwldOLDNqQlUEAmKBIJQSOrIkrEX5oB kUZNgDWIgYIFIR4ehagp89QaN2CnekFEp7GePR1/AqLJRk12LSnZAclJqQV/W8K69gHILba2PbUM Erpul4U6B4ey3bZgnhy1kBn/AAAah0lEQVQsJRzVQOIYNKllE35g5y046bQi6slPWkiXySk6kVTb cVO2cYvqwBnCYs/tjEd8JunuyHmLJJGMxtsmkeVA2U+8IQxyxGQ53ZEQGEQbRA4ja+zcD/0gQj1o kJH9tx5mKTzALXIvgQgQUhmkk4VsLzNIjJLiy3/M135KqYfZcv5URRmkxlpCIWzxwTiC4uxh8RRO HKKnjGOIF/9k/CGv2fChFpMydl7VsYRHynMNiZgYgElyS+GfQeAkxkt4goFYKoz9kv65g0kqDxxR WsByRCUYEJOSnDylM4hg5CqD2IKcEmQGrFel3ZFuIdlg98daEaZ4Wfsz3e7VdWGY0EQVXL2oKiLO Cr0h3j61Y6Blia0jbSc2TY7WLJMhyiJ7Y5W9tFBVsByOB+4QYZcIN7XJTAdZIVKNKA/92O71HDee zGLqd2R4pV82okJ+GiFCntfr7RvlkBL21cRq+SpEUhcljUZavIiROH0Rir2cIUEqgdTwSr0mPFDJ L4QEKMaQY8GX6guPmsAgepR1vA3ioMx7lazDC4C/kmk1AlwSpz8DA4myFzSSEhGi9TjQBkJD6h1i FqjUf5zGWPCEFLmqYMoATOpeWY/TGS4T/7zMHxoQxSVqiTZDS2FFU9bAVxXtsdW0AnyI8OmGVkOR 85rkVe8J+9nhdSzmOskLb5z4zmm91qjOpK/p8kwGCSJdYizdQlX5Y5/73c5KIXCeHMzGONK7aJ3p hhCLrUbrDeGwkzrlREWJgoQM0m27N9vp/8zEIm/i8qYlAjl7SOXhUqCUl/hjZQkrEyMpPKqca8BV /38izkoISaI01xgEaoNCw3ad28HPmFiTg+zQOwNgdrBdzVC54xe6lB8s1htAKnzBH6iDCMcUBL62 rELXyEMSfwY8IgQDOvgr8G8sqX8VEUBcLMZXVCBonyIzpGRVQrfzwpE1WCkk4Q/VOrorD/kPhpWd 7nPnTMZh4Nhf8wLHMSezRJbXC0O7IRvVjztOljtyioMlspxDDuLLqtd0gYi6s7yJStNZ3Pkpaa17 2dZ2H9ERNAg+xg17RaDfjUKMQZ7XpVJIIYWUgIy5BlmFzFVMTc3wsUgn/oNQOxQjFloKVYY0+OCL OMkiaBDsdOWPVCcAKqQUff3H2eFjyRiZL/nCCAqHgbhRnV7UqCcNrfz92sMtcT1+TGJTYlF8JAMT FAsBF3lRfjkYpAzEJU5z5yHWmeBYohDzsA8Yw6AEoge5pFAsJH94b4gyQcYoONutFihk4ChFFSVD 5mg69JlgPt1g6z23OlGujbFIIj2pxA3wx4xpQLsAkcAnSh97LarvdZlhrYboGpG8kMqS8iE6Dm3g +32IsDaspgMxVCKgEpXpG9XpkujdPlcKWdviJg+yFilkDoprlZAlhFxcKbguRZD6ASUeTjWjJJII hQj0BzJSzA/ZOw4pWMEkBHAEUUJEDUSOAsIlCzRGQTjF0gfljVED+QxPZt2upAbomeT/NMcIBQH/ HCWxGmKd+eLvo00uaaTwZb0kFgpNeGB31Hy0ojuAMRurFM/xWk2dMROKHkUdi+CezHkqmudSZy/x NY+yek/39hZvUZzvPOG7w+hFF+heTq8I2WsmSysjPWYC7WYg6dWidcIsoHughBcOcQhlQ2Z5H0Z0 4Y5j5JDtert+8ywE8saGqqeGQS4TWU1P+lUl8oIoUeo426QfsIdEWoEnMv6v6/+TEEiEd4yh9fQX XoYlqckeopIDNUFE86Veb+ITD6ZwmZlNCMhIZnbNtYXzi+cMCs6+AcNRGS7Jk3ORIIdnXeLp3BGV SPNGdsDSjxBl6S8eLI01G5Cl/6EGM+c6LHCBCGd1hPOwBCUsIGJ1tJHNsEU2a9saF7mBypvUj6Ff nalfhlqtJWvP950EW/1RbIsHYKPZI6LD5eSqpLKkjSrWQsyzyMG9qBiOgId+3WgtRBHSrbvtm1J1 Ouepv1gKCXFXrIN8OspaopSCHPC55nxJIDEoSqjuWeKHp5UKXQ+gnFPVzfo51EgSIxnTyB7KiDuD WrwwkNKYxxJEhWNCKGvsRZQkZ0TXBFHgBwutUqQK+zsM9yGInN5G3ZNeyBmBPBYmN6BxHOQFk0lO 3MOJKnvTLZUK7qD/cjh6lTNoMVA+sWIHIyr8t0Q7VaYIoRSZdRg2CV8V63tLax1tR7SKEjJKMPRG fOwP1ZUlV2vd0EZch8r6qBCRLbgTm1zsTt8QIiMHZDG4Aj6Q5vU81qTT32w10/vG1nLMc7dzfIBI IpP8ZnQkXRktDKIUcsZLboAIXmXtSJJK5Hrma7/lLXmSeXC4CoNREg92RmcRz/sQjjAGSllgF6sz +LuaEx4y0/a3s2rfUsgFWYR/HGGH77og0ptt6cu5XoZRAwFhzYOloRljGWMSXf1BjijI2Wagwxxa WvfATCCFFXgkYXZQsTEOhhHvLgzNIfXroaJj7/3qO2OO6MZClAUBUsXHUdvVxf8+Ucl+h007QazT wqhr2pxB7qPtXb2Lm9Gdi6y0byDTQylESoXCII0GuU4h5I8WOXMcfBIlksSq/8PrlPeaxuJBSoYQ nLdsnzzOsTOVLOObZ5lhHk0tGg98wbYniecS2LITPPhPsoHU/6rwizRIygEi9u8AsOwhyxTiT+Ox TyPSm7b0BWzos9rWZ5UVHGli1pBkz1dYBxlAOaV4FJW1Ywro8P4pWrJAIUNCzEmegpHRCoysqrfO E45zAEZko/qR2d4w0iEOJRWM6Ltg5QBikX3qWlMXjCC+8rphX+0mGNc7higqUggECG9hvKUy5B0d WbWeLmmsN74QsKWQWXg1S++urFj4Sdq4vAljq1PRzsLZ+cdh40t/jtENcEHyCIedl6FE5WAv13bM w5PxBNuD7XFzAplJbXuYJVGLKZDPJpDmz5KHbF/5iXZwLO0q5Lg4Gt5JE8FmwmvZ6iElEAiGu4dk bzZFATahpwTbPQvnOAiBaI5Ah2ohzNJZDiGV5aYTG3tSIXJw8wm24krzFNckeKBFoa7exX3lkIqZ 3T7TeJIPTPci1JKukF623zbdhWiaUn0+Gjg4c3Gk32RjjqzqxxK/iSh1gOOiFnKR5208JwaW34KN pFGW1NDPqRAlqTkszav1wgHTyvbSj9rHxBftCAu9DJDLC4+bE0jzQBb67C+2+8wJZIE/DJUGEXvo xCA0rqdkZsUr/SCEQBmIhWzBFBYVKhbkC3NaA3VWBtHI+VYKMSZQaxldJ0gj4lfUx2JoL9upKOqZ KDZr1jZbeGWTszguK7pOjnU51dFmY5kpS1K9ey8dIp914F71XX/Q1eqHGGxNRHI6WG9I1CFuxxpt QVvoohIKeTeCQbrpQ/K867g4c0YhM4He1gxx629Ah2BDb04YaZLIIPPTffXs20t8eC2evTKHsGsB NLNLTosQvKSQi4fNf29DIbPfPf9aSEoGrYqD7SvvHw9294XpP/rIbJ1RoSuK1pLIJQSd4Thbo4fN aqCHHRQCh5bbrwr7QzKeYYDrF9wT0lmLAZbVRKZDrSxicJH4KlBIY8qS1TpiztLC+k7XqkvlUCFi HHLSPSI6MOuhwcfGh1mPFl/pCirEWBtUC9/B0ztRyPOaYz1Xq3LJIJE/gg7h921u64rxZMHESAqp /7csuvKzEkLyy5ffKy/K4b6zwxnu9jLi5kB6kUIuLuEfYQ+2R9kf1qAkPLH9CBokzxGyODtOGSMs k7ISemHDre3QSZgsl4gLwZa1BqoHWqMtmBBh1JICKxZNYURdUhNX4oKSMiDOsrlZPskhTFycdYiY CwsIQVrr6Kb3YMrSz4e9lAvrujZtptox6WvzSWXcydhPAVZFiI4ijabezcglhZwA5HCpnBP9JrUr pMDT61msssggjQ4JsIhIuYKP+Y8CmZydP8Ais9g8Hv6IgtnBW0CQvWDOb/4kOuLjw5N/FqZaAolo KPZnzymvfjrz93aveJzp5V1WIP4fYzDOoCbHRMUAnFTsWfmvGqz+T+YYBnZMFVtygLqIpbA4/zcl a4S3Soo1JW4HbIpuK4Y7wuQg7HEwPuHwd2SyMsZjWUFdNYh9HNEfIr6sDKnuDsaTGuF1q849qoQw 9SqBmA7x9hD5Xnik8ZtMCuRZq+lWCblIZUUCOS+WQAw2n8YGqENm/hg6zuEFtEFH8tvnZypgaYaS KF9m5eoXUeHYK+0TlvCz6xeDiQF4/qA5NhyD5/Dd9tWQIkQcHZcQQa8fgNBSiJmxBhMgxXul5LV/ oKfKaul4+deELSkEzvai66DZUFKwHQEMQi7SYmEj033cogyVwyL1g3xMuOhZCvGvYuk9WrL3SBWi liyFiNkY91nSWayKmFKvG0MOD+Opt51TsffWrvPKCNuJUsj3o1HIRCCq0lkKWc1PegywvAQyw8fn oCNEWIKPJG2FARiJMbSftHB2Z6+A4fNigN9gaH5Ew02Gi0BXs1Pc/OzaG3+tgTb8q1xo+B+B+9Y8 N74TnDRpXkfFEoUU+8fTd2XVIKrz7BzCN/lGE7aitQdIEDAJi4VwZRmFDIP13nIje0logddbbAmu PNCyvdvs63VYGdnVXO+B1pMKFgRYO7zvdvT1spK+37N9Sha0HXV9yE771XcH7I2OU+VOPXpDHpxE xk2ogIwsgrjhBBRied7txB9TlBUaQy5kSAORgJi4Wkp+dBUjkT50IpbgQ8ikMH/VKJES/9/79XgA 54C6wEGASeQZ/hJHggU+8Zna13v/2Qvvl39OiY+/uOZYsr+lgqB7NZR4oF8Mr1I0u+upB4WwDdCa QFL2q/wT2MMObV5f/71WCFrRCiCkfFJ3zaDrdOj8l3/KwAlCGmjlUC+E62Rno60PtulTQbI7zvK9 R2MQYZP93jvV6yJc3WZYIVPNvhpjhYEO2kI1yrisex1KGka9b+Luwg07cTe6VqdqlibI6p6ftVT4 pviS8pY/Gnlu354bCe/1kE9ghFEWsrwuPy5eWVM4PDPCmHFHav+v+wFsoObhPz5aYFwe7nCmL2D7 4gMXr89REmkgaZ5br3czu7vDZPbGWYqFQPH/DvBMwoPi3ne9IzpHEizLUBA5EAinXpFEEIVh3mKi z00n1iXlIVH9g40lHWzwYshi2cCsQ8hjHTDAwbX67qioCcbe4944pH5Tk7+H2kQ1EU1FS+8rDW2R SH+vg0lP1hoyjtZQ+MCZ1qP3qKMxBL1TNPWW+g5PLzNZS6WQcPgNHE1uK5YQ8aEq3PnjrEsP9EKP yWWKdx4CLcNj4UFLL9CEQfiZF74Xj3N7ZXbTC+8XGGhMKvNnbJiK/7YKku2rkhtBfZ1CrH+WLVk0 YWmBwtCgR9m+JHQCcDoJvSLwv9P4XpjDovqWYQ7o6x2sfm/mNdTYGaNRpG99U/QhmBeBjipAhFIO jo+wx9AyWTvnEN2lLp+8XV2aRGx2lswEOnHP59iPbAhhMcQ7qELGV6+CQb6npbduJ16ro5chVlqt mpMdjnxgkIZCzqsGGTHXlazeYQNHz3JLgsmkvnqmBDuWX+aUEo/w/DzPIgf8aJZoLeG+PMHxCMfj 2v4tjrFP8YdzzuwpS0kXf1HEf4E98SyFwkAw59lXf9PHse6JLQXmNEkYvRjGZA3+yMGt780iHRt4 FbpDPMMF3yJSx9qaONBCrJVHDbNUhAw+66S3j97SWMxjHXbZ1Ai2Q6s9K1u1cM8OKnwrtcPDTiFS p5O6/50MwimlsnoKxkUrp3P8KEVIszeErVOkkCrRn12E0K74KQpR2dFqeKiMYt0eHnGVJr1rKoQU 4i+pzRG/dhYbhMwOczjv8cDHp24eyEcGrFw8wwIILu57CdL4R9mJ9meLH2f/BbUfRFeXLxNI8UNe YDYZONIH2VjWuQtAUMgj6vxNChwdwADiYSVk4DQ455RMRVLgW9Q6Cn6PPm39q7hAhN6VkM2yRG9v nwQlWmA/kEN2OzLIPke7yY7oYIy1ryxSR5/sD7py54A2KklmsQlXtu3okraTcgh7Qqx3ii5FXtsw z+t9U9tu+7yWzts3JXbezkTIeY6aBj7nlc8SLfxGKCOQD2gE8hyhVYi+Fw9d8+p+FSHLHDJ74XaT rieBLwgkHu3rf88VhFxgPF1/0MVdz3hE98o8hRekQYToz+kgKcj12tQSSBPstEWjOgjEtu4UtGYm b5kqsO+imsG4qti8Ex2UhV4rjuEaaJHUP41NiYBZ2I4QA6xeeERwsWPz7T6jSR3FECWRxv6uDt89 /VkCGKkXVmsWq4ZYGX041OWFwiIshjBxNfpOhJECnRXDKlQQZJFCno1B4OptVEijx5vsrd5asOFD QzOrFyYjiSTNH4Xf6+KcxBoIC+mzAxPjnYWD1Zzj5fs0zxBevuMdwgkuyWksUtj872mpyf6+C4AK QluT4gKFGTTlqvyn2L7yPZpXMFISh5pksEFi3zivDt6GiyfJUdIDJGKwYoAFfwlrIUYethsBXYQD ZpMKRPy/w4DJMYlFQ2xS9yW4vROIkwm4RIOsiTj2tpNKIGID5TyLhVTWHiJkTx+joCPHOQ6YJndv qz1DSd2KIQAGrxMePyGPNQmQbSf4WLezG1LLIK7NVy12CqlFPslONZ+zJaGU/KjBR/3vSXzI6TrP z89C9NRSR7n4+UUwFO5YfE5CCWHKzLzenv35k1+jAsqNUlKgprLgci+zf134PQTv2UKs+GdGaMhD IIrpqE0cxSI/U+AQFYVH1idlATnwsEs8VsAiPoQhCHNWQ3SMg859QYWSUVziJC5gW3Ng7MENu6IN HAfgom7HEUQc1OSba/UvTpJzBrFKemSSg0y5VvJwIeIz4CuBTCrk3oIsqo5GorMlpF4bYet9F9tC urYSci4NDAJEoggR6iCRaNAk7KMxlqKsQJiccW3iE6SzFBVLGayLE9lGTu35al/mnQ5mOaQQ8RhY TEiTBOKJ9wAtPGVa+lP90EdqWmaQC3dXeHKMz+teQQmjN2zGHPxiCiNpTQIWqxxoBHOs8Pcg7ZTD f0R4RUgJTF4FTMB+iMYpDF7MmFJXDMka6mkNUZUOlynEmYvUHvGrXDtoSV0EyIElQxZIfIfIcU9H 1l5ViMRcukhESMQvptHvx4M3hujmQre/jz5r0Wrqo+WxvDe9+rG20hTSYCSgYcYdaRWQpCHWCpEZ hu3iCQxqlUaQRK4IKdZIGA4fD1lAyFKc5QBoTnSrsGcImTFIrBL67Xac7eEzhrn4LRE6JTwuMEiD sfjnRqzZq0X9PdtXqqQzW7cuKITQQSMwNhPAYSuNiWi1NUO6i5CSOEGLC6MwhzrbdBNLYpFENMJC d0ge2L2MKQ6cDIB/DDyNjM62wiPegEsC6aXynfUzLFrHXvV6hQl4Q+Isl+rw9LoO2dPnK8X1OMvB o6wJIkoh957KcsOJzTRxw3s7h1QYJBYLtRAyd2RZMipBaqzOfi8di4Iyo4JDMMSlBrJiDTSDq6UB RzhszcGb6+z22L9wMYTZ07vLy+TB8kEPOd3mrwm2kcWHJccXf7dz1ZV/W4qsWL9IiAX/rOOg+Zch lLLtnTobjxDJOrpK8RUSVTjPOcRCEDla7Bh8XyGZJHyYEBkUknmwoQ2GYHlK1lwwYKudc7J14dFn Q4dEWjtR7MoZdT969tLhLsRbsTNEOUTiLS2t79ToG+ZmcXrviHwvwEH2cPUBlIwq1kcker+3GXLr zlS6+01mFfCo3UEbZ71qukU/nXHLGeGXAK5+U1aFo0z02JzDy217+PN1FFz+JC/fy+9aIoXM4LaI D7/T/KeXD5whaPb4GezmhFmSOyMJmO0rjC7VeXmXKgQtxByqImmnpJ0a2IKTbG9BzpzHbiULdo8I gNRjZX7EIUJEmwrdeeLbEYyuisFD0aETX8V1UoUI2kOGuL/QY6veGaSHuxeV9Vx3E/Y1rRUSWmbt ZX/IUXO9NbYCi8DhGxzwp77msk6yAffh/gFKfXRkhJ5CM6HUXO9ozeliN9m+2UpXyBtO6b2op3sx owmoYAC28b5GQfwmCYJsB7qMaUjFVz7bYfLv9GvmoOf5K6i9pnJGtT2ab/aDbHdqB2fZc/uU67L4 RzQ3zu700i2BPJpnuJAl9m/ycLJ7pXNAi/4bL/CJDuQhcQqezK1De4fepFnbhFKJFj8Ku0Os3Qk2 kULXrraAQFpLawjWYFkDFbvVMYk1WxIraCTWH5kf9vZCD7Fm+BCM0AG/x1AHkSN79ofEorp7siSj pR8Hxc7+gBHwBzYZjvc6B+ie1vcww4G9UyMr6RslERuy+I5zrNdTnNXWChERBQIJNkY95yCNUtpP s29i9KXjd7ny+exnhlRQbJK6vdhmP/DzdzuJmYcjc8Kigy6+qs9f2zHFKjlswh+ReUdOo+PfM7s7 52aFW2wRg/88F/vLSvOXgVwYgZ0nkY4tOzrNMECIsgxrE/TJs76oT0E/TCEa3WjJLrv/JCHfhamK CM/YTS7/nXWnFM2GBeuj9KrN6+WAh4QXKRiHQ6ClE0qZNubQXt9C1fczFqnxVY+6uoymznupjghY mkYRr6e7/lDrySRC9irXd6ZEmMeqJHIYT9qi3th6MZDUne8PNtxBJ2SxsRDwWLtOnzGIivUgT3Dw 7exHAonfFIOL3Tm8XcQ+Dgp/kW/Pdgh9so9zb+/2+QSSSCAxNrLfo3eUn0ZULv1JS0x2+WZ/yyVr 1oOvJaFXdeRA7ageu/rRd/I2yofedBq7w+hvJ2l90Lc61PzE72R3eLgu9u++62UyTidrxqdvxRV+ wnamKViv0bo6NOqXUa/W66eTPrPuc5J5uN305+Wuq7vf+04+1Qpg/SWjbBDs9YFTfHO6f/jl9Msv D7+8/PZXfPprvfz1r/+By19x/d/rlX+XC3/0H3L1/8rV6Yu+/SIfv/zbL/82vf2Lfvz6L//26/Tp 119//T+/Nm+P8jF9fv/r46NenS769i+Pj5t/3ODtp5++f/f9+vvn//W8Xnfr5/Wb6SKfpi/1ynTz m+fpJ+vu+4lz1s/66fn72eVZPsQo3OES36f/0fVDP3X8v8/LST7bu95wuvLZ3sONfIrmchPep8uN /UB/Ga7yWeJf0l6z7/hge+T8lvb95D+aXS7fNv8fy9fKMc/SkN0AAAAASUVORK5CYIIAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA8A6AOCJAoAAQDpAygAAACAFgAA4BAAADARAADQFgAABQAAAAoAAAAC AAAAAwAAAAEAAAABAAABDwDyA0TyCQAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1QdU8QkAAAC3D0QA AABBAHIAaQBhAGwAAADt8QIwfLRiAIRxvwEIAAAAdMZ2ADi2YgA4tmIAYLRiALfxAjCEtGIACAAA AIS0YgDJ8gIwAAAEIgAAuA++GwEAvhsBABwbAQABAAIAAAAAEAILBgQCAgICAgQAAJABAAAAAExQ AwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAANqkWmAAAAAAAAAAAAAAAAAAAAAAAAAwAQQByAGkAYQBs AAAAAAAQAFIAZQBnAHUAbABhAHIAAAAAABgAVgBlAHIAcwBpAG8AbgAgADIALgA0ADUAAAAKAEEA cgBpAGEAbAAAAAAAUFFQUFBDUVBQVFBgFAMZF+mZCYpQUVdAUFBEXBwEAxhE0z7CUFBCmFBQULIf A39iwALE2VBQUehQUFAGBhQdCADCOqVQUEP8UFBBxDM9MSB9+rFSUFBeOFBQUvAzJiRwK3rNYVBQ Y1BQUFXYNiA3PSd3+aVQUH0AUFBV4DcxIyBQSFBZUFBSQFBQUEA3PCk2PpbTQ1BQAVhQUOEqODQ9 KCQRY8FQUGxQUFBFWDg1MTSS3AKdUFBRbFBQUGY4ODUxX3ZXVVBQUSRQUFB0OD0kKJJyG/VQUGjY UFBTKDs1Ij5TP1LhUFFU2FBQUtg8PzMxj9blT1BQQVhQUFHuPTEoIFO/WIBQUFHIUFBQcD4xPTUq vtZFUFBScFBQXBcgPyMkapcnClBRUtRQUFJRICI1ICWShpBQUHUQUFBYX1BRUFBQUtBQyEb5Zg9f bKVYSVhQUFBQUPKzd3pQUFBQ4IkxeK/yrgFYUFd8UFBQWVBRUFBQUFBQUFFQUFdurh5QE1hPr/Kv 6VhQUFFQUFBQUFBQUFBQUFBQUFCOUFFQUFCOUAhQV1AAUFRQUlBAUEZQElBQUuFYX1BSUFFQUVPY UcBQVVBQVcpVY1BQUUtVylVjUFBTgVA2UkJYVVJbVlRSUlJSUlRQUFBTUFBQUFBQUFBQUFBQHT8+ P1AQUHBySVWDrgFRY1duUeJQUFBRUFBQUFBQUFBQU1BYUFJQQVBRr69QU1BQUHxSRlBRUFBQUFBQ UC9QUFBRUFBQUFBRUFVQL1BRUFBQUFBSUFdQoFBRUFBQUFBTUH9QsVBRUFBQUFBUUFVQL1BRUFBQ UFBVUFxQqFBRUFBQUFBWUFdRQFBRUFBQUFBXUDJQL1BTUFFUU1BSUFxRR1BTUFFUVVBSUEBRd1BT UFFUVlBSUFxRZ1BTUFFUV1BSUEBRE1BTUFFUWFBSUEBRA1BTUFFUWVBQUK5RM1BTUFFUWVBRUFpS 8VBTUFFUWVBSUF5XEVBTUFFUWVBTUA5Xc1BTUFFUWVBUUFpS8VBTUFFUWVBVUEhXAVBTUFFUWVBW UF5X0VBTUFFUWVBXUJRX31BTUFFUWVBYUHZYA1BTUFFUWVBZUNpYKVBTUFFUWVBaVJJSMVBTUFFU WVBbUDJZU1BTUFFUWVBcUDZZNVBTUFFUWlBSUFxRR1BTUFFUW1BSUEBZm1BTUFFUXFBSUFxRR1BT UFFUXlBSUFxZi1BTUFFUQFBSUF5Zt1BTUFFUQ1BSUEJZpVBTUFFURFBSUFxRR1BTUFFURVBSUEBR R1BTUFFURlBSUFxRR1BTUFFUSVBSUF5aV1BTUFFUS1BSUF5aRVBTUFFUTVBSUFxRR1BTUFFUT1BS UFxRR1BTUFFUfVBSUF5ac1BTUFFYWlBSUFxRR1BTUFFYRlBSUFxRR1BTUFFcWlBSUFxRR1BTUFFc XFBSUFxRRwQpIDU2MTM1cPlwBDg1cB0/Pj8kKSA1cBM/IiA/IjEkOT8+cCA8M35wFDEkMXD5cAQ4 NXAdPz4/JCkgNXATPyIgPyIxJDk/PnAgPDN/BCkgNXADPzwlJDk/PiNwGT4zfnBhaWlgfWFpaWJ+ cBE8PHACOTc4JCNwAjUjNSImNTQRIjkxPPhwBCIxNDU9MSI7cD82cAQ4NXAdPz4/JCkgNXATPyIg PyIxJDk/PnAgPDNwIjU3OSMkNSI1NHA5PnAkODVwBQNwADEkcHZwBB1wHzY2fnAxPjRwNTwjNSc4 NSI1fh0/Pj8kKSA1ahEiOTE8cAI1NyU8MSJqBjUiIzk/PnBifmRlcHgdOTMiPyM/NiR5ESI5MTwd BFAeUD9QIlA9UDFQPFA+UClQP1AyUClRXVA1UDpQPlC5UD5QP1AiUD1QMVA8UANQJFAxUD5QNFAx UCJQNFPKU+FT7VPvU+1T6VPqU/xQBFApUCBQNVA2UDFQM1A1UHBQ+VBwUARQOFA1UHBQHVA/UD5Q P1AkUClQIFA1UHBQE1A/UCJQIFA/UCJQMVAkUDlQP1A+UHBQIFA8UDNQflBwUBRQMVAkUDFQcFD5 UHBQBFA4UDVQcFAdUD9QPlA/UCRQKVAgUDVQcFATUD9QIlAgUD9QIlAxUCRQOVA/UD5QcFAgUDxQ M1B/UARQKVAgUDVQcFADUD9QPFAlUCRQOVA/UD5QI1BwUBlQPlAzUH5QcFBhUGlQaVBgUH1QYVBp UGlQYlB+UHBQEVA8UDxQcFACUDlQN1A4UCRQI1BwUAJQNVAjUDVQIlAmUDVQNFATUD9QPlAkUDVQ PVAgUD9QIlAxUCJQKVBwUCNQMVA+UCNQcFAjUDVQIlA5UDZQcFA0UDVQI1A5UDdQPlB8UHBQEVAi UDlQMVA8UHBQM1A/UD5QJFAxUDlQPlAjUHBQPVA/UCJQNVBwUDhQJVA9UDFQPlA5UCNQJFBwUDNQ OFAxUCJQMVAzUCRQNVAiUDlQI1AkUDlQM1AjUHBQJFA4UDFQPlBwUD1QMVA+UClQcFA/UDZQcFA5 UCRQI1BwUCBQIlA1UDRQNVAzUDVQI1AjUD9QIlAjUHBQMVA+UDRQcFAxUCNQcFAjUCVQM1A4UHBQ OVAjUHBQPVA/UCJQNVBwUDlQPlBwUCRQJVA+UDVQcFAnUDlQJFA4UHBQJFA4UDVQcFA9UD9QP1A0 UHBQP1A2UHBQJFA4UDVQcFA8UDFQI1AkUHBQNFA1UDNQMVA0UDVQI1BwUD9QNlBwUCRQOFA1UHBQ JFAnUDVQPlAkUDlQNVAkUDhQcFAzUDVQPlAkUCVQIlApUH5QcFBwUARQOFA1UHBQP1AmUDVQIlAx UDxQPFBwUCRQIlA1UDFQJFA9UDVQPlAkUHBQP1A2UHBQM1AlUCJQJlA1UCNQcFA5UCNQcFAjUD9Q NlAkUDVQIlBwUDFQPlA0UHBQNlAlUDxQPFA1UCJQcFAkUDhQMVA+UHBQOVA+UHBQPVA/UCNQJFBw UDlQPlA0UCVQI1AkUCJQOVAxUDxQcFAjUCRQKVA8UDVQcFAjUDFQPlAjUHBQI1A1UCJQOVA2UHBQ NlAxUDNQNVAjUH5QcFBwUARQNVAiUD1QOVA+UDFQPFBwUCNQJFAiUD9QO1A1UCNQcFAxUCJQNVBw UDNQJVAkUHBQP1A+UHBQJFA4UDVQcFA0UDlQMVA3UD9QPlAxUDxQcFAnUDhQOVAzUDhQcFA4UDVQ PFAgUCNQcFAkUD9QcFA3UDlQJlA1UHBQJFA4UDVQcFA2UDFQM1A1UHBQMVBwUDxQNVAjUCNQcFA9 UDVQM1A4UDFQPlA5UDNQMVA8UHBQMVAgUCBQNVAxUCJQMVA+UDNQNVB+UHBQcFARUCJQOVAxUDxQ cFA5UCNQcFAxUD5QcFA1UChQJFAiUDVQPVA1UDxQKVBwUCZQNVAiUCNQMVAkUDlQPFA1UHBQNlAx UD1QOVA8UClQcFA/UDZQcFAkUClQIFA1UDZQMVAzUDVQI1BwUCdQOFA5UDNQOFBwUDNQMVA+UHBQ MlA1UHBQJVAjUDVQNFBwUCdQOVAkUDhQcFA1UCFQJVAxUDxQcFAjUCVQM1AzUDVQI1AjUHBQNlA/ UCJQcFAkUDVQKFAkUHBQI1A1UCRQJFA5UD5QN1BwUDlQPlBwUCJQNVAgUD9QIlAkUCNQfFBwUCBQ IlA1UCNQNVA+UCRQMVAkUDlQP1A+UCNQfFBwUD1QMVA3UDFQKlA5UD5QNVAjUHBQNVAkUDNQfFBw UDFQPlA0UHBQNlA/UCJQcFA0UDlQI1AgUDxQMVApUHBQJVAjUDVQcFA5UD5QcFA+UDVQJ1AjUCBQ MVAgUDVQIlAjUHxQcFAxUDRQJlA1UCJQJFA5UCNQOVA+UDdQcFAxUD5QNFBwUCBQIlA/UD1QP1Ak UDlQP1A+UCNQflAdUD9QPlA/UCRQKVAgUDVQalARUCJQOVAxUDxQcFACUDVQN1AlUDxQMVAiUGpQ BlA1UCJQI1A5UD9QPlBwUGJQflBkUGVQcFB4UB1QOVAzUCJQP1AjUD9QNlAkUHlQEVAiUDlQMVA8 UB1QBFARUCJQOVAxUDxQ/lBwUARQIlAxUDRQNVA9UDFQIlA7UHBQP1A2UHBQBFA4UDVQcFAdUD9Q PlA/UCRQKVAgUDVQcFATUD9QIlAgUD9QIlAxUCRQOVA/UD5QcFAgUDxQM1BwUCJQNVA3UDlQI1Ak UDVQIlA1UDRQcFA5UD5QcFAkUDhQNVBwUAVQA1BwUABQMVAkUHBQdlBwUARQHVBwUB9QNlA2UH5Q cFAxUD5QNFBwUDVQPFAjUDVQJ1A4UDVQIlA1UH5QHVA/UD5QP1AkUClQIFA1UHBQBFApUCBQP1A3 UCJQMVAgUDhQKVAdUD9QPlA/UCRQKVAgUDVQcFAEUClQIFA1UHBQFFAiUDFQJ1A5UD5QN1BwUB9Q NlA2UDlQM1A1UHBQfVBwUAJQP1AyUDlQPlBwUB5QOVAzUDhQP1A8UDFQI1B8UHBQAFAxUCRQIlA5 UDNQOVAxUHBQA1AxUCVQPlA0UDVQIlAjUHBQYVBpUGhQYlA4UCRQJFAgUGpQf1B/UCdQJ1AnUH5Q PVA/UD5QP1AkUClQIFA1UH5QM1A/UD1Qf1A4UCRQPVA8UH9QPVAkUD5QMVA9UDVQf1A9UCNQD1Ax UCJQOVAxUDxQflA4UCRQPVA8UDhQJFAkUCBQalB/UH9QJ1AnUCdQflA9UD9QPlA/UCRQKVAgUDVQ flAzUD9QPVB/UDhQJFA9UDxQf1A9UCRQPlAxUD1QNVB/UD1QI1APUCdQNVA8UDNQP1A9UDVQflA4 UCRQPVA8UB5QP1AiUD1QMVAxUDxQOVAeUD9QIlA9ULFQPFAeUD9QIlA9UDFQPFA1UANQJFAxUD5Q NFAxUDFQIlA0VE5UYVQbVBdUbVQbVGlQHlAxUCZQMVA0UD5QP1ARUCJQIlAlUD5QJFAxUFBQUFJQ UVBQUFBQRFBTUFFQUFFMUFBRVlBQUVBQUFBQUFBRUlBQUFJQUFBQUFBQUFBQUFBQUFBRUFBTVFVW V1hZWltcXV5fQEFCQ0RFRkdISUpLTE1OT3BxcnN0dXZ3eHl6e3x9fn9gYWJjZGVmZ2hpamtsbW5v EBESExQVFhcYGRobHB0eHwABAgMEBQYHCAkKCwwNDg8wMVAyMzQ1Njc4OTo7PD0+PyAhIiMkJSYn KCkqKywtLi/Q0dLT1NXW19jZ2tvc3d5Q38BQwVBQwsNQUFBQUMTFUMbHyMnKUMtQUMzNzlPP8PHy 8/T19vf4+fpQ+/xQ/f7/UFDg4eLj5OXm5+jp6uvs7e7vUJCRkpOUlZZQUFCXmFBQmVBQUFRR0lBQ UHhQcFBUUFhQLlCvUQNRMVEoUS5RwlKWUoxwRHBKcE5wcnB2cGBwanD8cXJySa+vUFBQcFDwUQJR MFEoUS1RwlKWUoxwQ3BIcExwcHB2cGBwaXD8cXJySa+vr7NQUK8ArzqvZK8fr1mtr626sMFQUFBQ UFCwKLDUsCWwYY86jshQUVBQUHZQUFBQUFBQUFBQUFBQUFBQUIRQiFCMUFBQUFBQUFBQUFBQUFBQ U1DJUNRQ1VD9UMJQnlDWUN5Q21DEUMxQylBAUNpQjFDTUMFQh1CIUN1Qw1DYUOFQmFCGUMVQzVCK UIlQi1DIUM9Q51DlUPBQMlAzUN9QNFDpUDVQ5lDoUO1Q6lDrUOxQn1A2UJBQ7lDvUPFQN1CFUMBQ k1CRUJJQOFCBUINQ2VA6UDlQO1A9UDxQPlDGUD9QIVAgUCJQI1AlUCRQJlAnUIBQKFAqUClQK1At UCxQ+lDHUC9QLlDQUNFQglCEUPtQ+FD5UOJQ9lD3UONQ0lDgUNdQUFBQUGZQZlBmUGZQKVCdUc5S sVPlVPpUnVVdVRxV7FWgVnxWH1Y9VvVXY1fTWHhYglk5WkBa/VtTW+xcDlzcXLtdfF00XfdecF9w X4BAA0CyQQZBy0GFQtBCm0NxQzdEFkQ+RRxFh0YcRvFHIEgeSUdJAUn/ShRLbEzDTRtNiE5WTmtO N077TpVPU0+0cC5xQXH7cgBynXPVc690AXTvdZB2Qnb5d2N373gHeLZ5FnorerF7N3xgff9+33/T YDNgsmFYYdlhiWGnYkFif2IAYilixGLiYp1iuGNQY01jb2MLYy9jymPqY4JjvWRfZH9kFmQOZC1k yGToZIBkuWVeZXxlFGUOZSplkmZVZq5nmGjwaJZpQGpUa35sdmzMbI1tQm3Ybi5ulW8yb4gQOhDi EcYTUxMuE+0TtRQlFIcVZxU7FdkV/BWaFtIXHRc5F9IYRxj9GVQZBhn3GZkZtBrQGukathsGGz8b 7RwfHdod+B2aHbgeQx5kHgceJR7eHv8enh62H1UfeB8QHw8fLh/lAHgAOAD8ALIArAFGAX4BGAHU AloCgQK6A1cDBwOCBCME4QVHBcIGGQauB6UIRAjtUFBQUFCOV1FRUftWVlZVVVZWVlZXV1ZXV1ZW VlZWVlZWVlZXV1dXV1ZRdVVcXFxcQkxuTFVWJUxCTEJCVcpMT9WwxkJXV1eSVlZ2ZVZzdzUDZ2m1 DWkhZ3RlA1Z7QmeW9IWUM1auVldVVVZVVldWVlZWVlZWVlZWVlZXV1dXVlZWVlZWVlZWVlZVVlZW VlZBVlZRVlZRXFZWSEZIVXlcsVdWVlZRVVVXQVdWUUREVVVWVlVcVldWV1VED1VVVVVVV1dXV1dX V1ZWVq9WrFFWUVVWTDOuVlZVVlVWV1ZWVlxUXFZWUFBQUFBTUFNRUVFRUVVTU1FSUVFQSFW8W5BQ qFivUFhQWK+uUFlQWa+tUFpQWq+tUFtQW6+tUFxQXK+tUF1QXa+tUF5QXa+tUF9QXq+tUEBQX6+t UEFQX6+sUEJQQa+sUENQQq+sUERQQ6+sUEVQQ6+rUEZQRK+rUEdQRa+rUEhQRa+qUElQR6+rUEpQ Sa+qUEtQSq+qUExQSq+qUE1QS6+qUE5QTK+pUE9QTK+pUHBQTa+pUHFQT6+pUHJQcK+pUHNQcK+o UHRQca+oUHVQcq+oUHZQcq+nUHdQc6+nUHhQdK+nUHlQdq+nUHpQdq+nUHtQd6+mUHxQeK+mUH1Q eK+mUH5Qeq+mUH9Qe6+mUGBQfa+mUGFQfa+lUGJQfq+lUGNQf6+lUGRQYK+kUGVQYK+kUGZQYa+k UGdQY6+kUGhQZK+jUGlQZK+jUGpQZa+jUGtQZa+jUGxQZq+jUG1QZ6+jUG5QaK+jUG9Qaa+iUBBQ aq+iUBFQa6+iUBJQbK+iUBNQbK+hUBRQba+hUBVQbq+hUBZQb6+gUBdQEK+gUBhQEa+gUBlQEq+g UBpQEq+gUBtQE6+gUBxQFK+gUB1QFq+/UB5QFq+/UB9QF6+/UABQGK+/UAFQGa++UAJQGa++UANQ Gq++UARQG6+9UAVQHa+9UAZQHa+9UAdQHq+9UAhQH6+8UAlQAK+8UApQAK+9UAtQAa+8UAxQA6+8 UA1QBK+8UA5QBK+8UA9QBa+7UDBQBq+7UDFQB6+7UDJQB6+6UDNQCa+6UDRQCq+6UDVQC6+6UDZQ DK+5UDdQDK+5UDhQDa+5UDlQDq+4UDpQMK+5UDtQMK+5UDxQMa+5UD1QMq+4UD5QM6+4UD9QM6+4 UCBQNK+3UCFQNa+3UCJQN6+3UCNQN6+3UCRQOK+2UCVQOa+2UCZQOq+2UCdQOq+1UChQO6+1UClQ Pa+1UCpQPq+1UCtQPq+1UCxQP6+1UC1QIK+1UC5QIa+0UC9QIa+0UNBQI6+0UNFQJK+0UNJQJa+z UNNQJq+zUNRQJq+zUNVQJ6+yUNZQKK+yUNdQKa+yUNhQKq+yUNlQK6+xUNpQLK+xUNtQLa+yUNxQ La+xUN1QLq+xUN5QL6+xUN9Q0a+xUMBQ0a+wUMFQ0q+wUMJQ06+wUMNQ1K+PUMRQ1K+PUMVQ1a+P UMZQ16+PUMdQ2K+wUMhQ2K+PUMlQ2a+PUMpQ2q+OUMtQ26+OUMxQ3K+OUM1Q3K+OUM5Q3q+OUM9Q 36+OUPBQwK+OUPFQwK+NUPJQwa+NUPNQwq+NUPRQw6+NUPVQxK+MUPZQxa+LUPdQxq+LUPhQx6+L UPlQx6+LUPpQyK+LUPtQya+LUPxQy6+LUP1Qy6+LUP5QzK+LUP9Qza+LUOBQzq+LUOFQzq+KUOJQ z6+KUONQ8K+KUORQ8q+JUOVQ86+IUOZQ86+IUOdQ9K+IUOhQ9a+IUOlQ9q+IUOpQ9q+IUOtQ+K+I UOxQ+a+HUO1Q+q+HUO5Q+q+HUO9Q+6+HUJBQ/K+HUJFQ/a+HUJJQ/q+HUJNQ/6+GUJRQ4K+GUJVQ 4a+FUJZQ4a+FUJdQ4q+FUJhQ46+EUJlQ5K+EUJpQ5a+EUJtQ5q+EUJxQ56+EUJ1Q6K+EUJ5Q6a+E UJ9Q6a+EUIBQ6q+EUIFQ7K+EUIJQ7a+DUINQ7a+CUIRQ7q+CUIVQ76+CUIZQkK+BUIdQkK+BUIhQ kq+BUIlQk6+BUIpQlK+BUItQlK+BUIxQla+BUI1Qlq+BUI5Ql6+AUI9Ql6+AULBQma+fULFQmq+f ULJQm6+fULNQm6+fULRQnK+fULVQna+fULZQnq+fULdQgK+eULhQgK+eULlQga+eULpQgq+dULtQ g6+dULxQg6+dUL1QhK+dUL5Qhq+cUL9Qh6+cUKBQh6+cUKFQiK+cUKJQia+cUKNQiq+cUKRQiq+c UKVQjK+bUKZQja+bUKdQjq+bUKhQjq+aUKlQj6+aUKpQsK+aUKtQsa+aUKxQsa+aUK1Qs6+ZUK5Q tK+ZUK9Qta+ZUKhYr1BYUFivrlBZUFmvrVBaUFqvrVBbUFuvrVBcUFyvrVBdUF2vrVBeUF2vrVBf UF6vrVBAUF+vrVBBUF+vrFBCUEGvrFBDUEKvrFBEUEOvrFBFUEOvq1BGUESvq1BHUEWvq1BIUEWv qlBJUEevq1BKUEmvqlBLUEqvqlBMUEqvqlBNUEuvqlBOUEyvqVBPUEyvqVBwUE2vqVBxUE+vqVBy UHCvqVBzUHCvqFB0UHGvqFB1UHKvqFB2UHKvp1B3UHOvp1B4UHSvp1B5UHavp1B6UHavp1B7UHev plB8UHivplB9UHivplB+UHqvplB/UHuvplBgUH2vplBhUH2vpVBiUH6vpVBjUH+vpVBkUGCvpFBl UGCvpFBmUGGvpFBnUGOvpFBoUGSvo1BpUGSvo1BqUGWvo1BrUGWvo1BsUGavo1BtUGevo1BuUGiv o1BvUGmvolAQUGqvolARUGuvolASUGyvoVATUGyvoVAUUG2voVAVUG6voVAWUG+voFAXUBCvoFAY UBGvoFAZUBKvoFAaUBKvoFAbUBOvoFAcUBSvoFAdUBavv1AeUBavv1AfUBevv1AAUBivv1ABUBmv vlACUBmvvlADUBqvvlAEUBuvvVAFUB2vvVAGUB2vvVAHUB6vvVAIUB+vvFAJUACvvFAKUACvvVAL UAGvvFAMUAOvvFANUASvvFAOUASvvFAPUAWvu1AwUAavu1AxUAevu1AyUAevu1AzUAmvulA0UAqv ulA1UAuvulA2UAyvuVA3UAyvuVA4UA2vuVA5UA6vuVA6UDCvuVA7UDCvuVA8UDGvuVA9UDKvuVA+ UDOvuFA/UDOvuFAgUDSvuFAhUDWvt1AiUDevt1AjUDevt1AkUDivt1AlUDmvtlAmUDqvtlAnUDqv tlAoUDuvtVApUD2vtVAqUD6vtVArUD6vtVAsUD+vtVAtUCCvtFAuUCGvtFAvUCKvtFDQUCOvtFDR UCSvs1DSUCWvs1DTUCavs1DUUCavs1DVUCevs1DWUCivs1DXUCmvslDYUCqvslDZUCuvslDaUCyv slDbUC2vslDcUC2vslDdUC6vslDeUC+vslDfUNGvsVDAUNGvsVDBUNKvsFDCUNOvsFDDUNSvsFDE UNSvsFDFUNWvsFDGUNevj1DHUNivsFDIUNivj1DJUNmvj1DKUNqvjlDLUNuvjlDMUNyvjlDNUNyv jlDOUN6vjlDPUN+vjlDwUMCvjlDxUMCvjVDyUMGvjVDzUMKvjVD0UMOvjVD1UMSvjFD2UMWvi1D3 UMavi1D4UMevi1D5UMevi1D6UMivi1D7UMmvi1D8UMuvi1D9UMuvi1D+UMyvi1D/UM2vi1DgUM6v i1DhUM6vilDiUM+vilDjUPCviVDkUPKviVDlUPOviFDmUPOviFDnUPSviFDoUPWviFDpUPaviFDq UPaviFDrUPiviFDsUPmvh1DtUPqvh1DuUPqvh1DvUPuvh1CQUPyvh1CRUP2vh1CSUP6vh1CTUP+v hlCUUOCvhlCVUOGvhVCWUOGvhVCXUOKvhFCYUOOvhFCZUOSvhFCaUOWvhFCbUOavhFCcUOevhFCd UOivhFCeUOmvhFCfUOmvhFCAUOqvhFCBUOyvhFCCUO2vg1CDUO2vglCEUO6vglCFUO+vglCGUJCv gVCHUJCvgVCIUJKvgVCJUJOvgVCKUJSvgVCLUJSvgVCMUJWvgVCNUJavgVCOUJevgFCPUJevgFCw UJmvn1CxUJqvn1CyUJuvn1CzUJuvn1C0UJyvn1C1UJ2vn1C2UJ6vn1C3UICvnlC4UICvnlC5UIGv nlC6UIKvnVC7UIOvnVC8UIOvnVC9UISvnVC+UIavnFC/UIevnFCgUIevnFChUIivnFCiUImvnFCj UIqvnFCkUIqvnFClUIyvm1CmUI2vm1CnUI6vm1CoUI6vmlCpUI+vmlCqULCvmlCrULGvmlCsULGv mlCtULOvmVCuULSvmVCvULWvmVCoWK9QWFBYr65QWVBZr61QWlBar61QW1Bbr61QXFBcr61QXVBd r61QXlBdr61QX1Ber61QQFBfr61QQVBfr6xQQlBBr6xQQ1BCr6xQRFBDr6xQRVBDr6tQRlBEr6tQ R1BFr6tQSFBFr6pQSVBHr6tQSlBJr6pQS1BKr6pQTFBKr6pQTVBLr6pQTlBMr6lQT1BMr6lQcFBN r6lQcVBPr6lQclBwr6lQc1Bwr6hQdFBxr6hQdVByr6hQdlByr6dQd1Bzr6dQeFB0r6dQeVB2r6dQ elB2r6dQe1B3r6ZQfFB4r6ZQfVB4r6ZQflB6r6ZQf1B7r6ZQYFB9r6ZQYVB9r6VQYlB+r6VQY1B/ r6VQZFBgr6RQZVBgr6RQZlBhr6RQZ1Bjr6RQaFBkr6NQaVBkr6NQalBlr6NQa1Blr6NQbFBmr6NQ bVBnr6NQblBor6NQb1Bpr6JQEFBqr6JQEVBrr6JQElBsr6JQE1Bsr6FQFFBtr6FQFVBur6FQFlBv r6BQF1AQr6BQGFARr6BQGVASr6BQGlASr6BQG1ATr6BQHFAUr6BQHVAWr79QHlAWr79QH1AXr79Q AFAYr79QAVAZr75QAlAZr75QA1Aar75QBFAbr71QBVAdr71QBlAdr71QB1Aer71QCFAfr7xQCVAA r7xQClAAr71QC1ABr7xQDFADr7xQDVAEr7xQDlAEr7xQD1AFr7tQMFAGr7tQMVAHr7tQMlAHr7tQ M1AJr7pQNFAKr7pQNVALr7pQNlAMr7lQN1AMr7lQOFANr7lQOVAOr7lQOlAwr7lQO1Awr7lQPFAx r7lQPVAyr7lQPlAzr7hQP1Azr7hQIFA0r7hQIVA1r7dQIlA3r7dQI1A3r7dQJFA4r7dQJVA5r7ZQ JlA6r7ZQJ1A6r7ZQKFA7r7VQKVA9r7VQKlA+r7VQK1A+r7VQLFA/r7VQLVAgr7RQLlAhr7RQL1Ai r7RQ0FAjr7RQ0VAkr7RQ0lAlr7NQ01Amr7NQ1FAmr7NQ1VAnr7NQ1lAor7NQ11Apr7JQ2FAqr7JQ 2VArr7JQ2lAsr7JQ21Atr7JQ3FAtr7JQ3VAur7JQ3lAvr7JQ31DRr7FQwFDRr7FQwVDSr7BQwlDT r7BQw1DUr7BQxFDUr7BQxVDVr7BQxlDXr49Qx1DYr7BQyFDYr49QyVDZr49QylDar45Qy1Dbr45Q zFDcr45QzVDcr45QzlDer45Qz1Dfr45Q8FDAr45Q8VDAr41Q8lDBr41Q81DCr41Q9FDDr41Q9VDE r4xQ9lDFr4tQ91DGr4tQ+FDHr4tQ+VDHr4tQ+lDIr4tQ+1DJr4tQ/FDLr4tQ/VDLr4tQ/lDMr4tQ /1DNr4tQ4FDOr4tQ4VDOr4pQ4lDPr4pQ41Dwr4lQ5FDyr4lQ5VDzr4hQ5lDzr4hQ51D0r4hQ6FD1 r4hQ6VD2r4hQ6lD2r4hQ61D4r4hQ7FD5r4dQ7VD6r4dQ7lD6r4dQ71D7r4dQkFD8r4dQkVD9r4dQ klD+r4dQk1D/r4ZQlFDgr4ZQlVDhr4VQllDhr4VQl1Dir4RQmFDjr4RQmVDkr4RQmlDlr4RQm1Dm r4RQnFDnr4RQnVDor4RQnlDpr4RQn1Dpr4RQgFDqr4RQgVDsr4RQglDtr4NQg1Dtr4JQhFDur4JQ hVDvr4JQhlCQr4FQh1CQr4FQiFCSr4FQiVCTr4FQilCUr4FQi1CUr4FQjFCVr4FQjVCWr4FQjlCX r4BQj1CYr4BQsFCZr59QsVCar59QslCbr59Qs1Cbr59QtFCcr59QtVCdr59QtlCer59Qt1CAr55Q uFCAr55QuVCBr55QulCCr51Qu1CDr51QvFCDr51QvVCEr51QvlCGr5xQv1CHr5xQoFCHr5xQoVCI r5xQolCJr5xQo1CKr5xQpFCKr5xQpVCMr5tQplCNr5tQp1COr5tQqFCOr5pQqVCPr5pQqlCwr5pQ q1Cxr5pQrFCxr5pQrVCzr5lQrlC0r5lQr1C1r5noUpHjdEJPrxFBUu9QUVBPUu9Qf1LvUG9S71Af Uu9QD1LvUN9S71BWUu9ScuI0T0IRW1LrUJpYUFBPUuJQuVhQUE9S9lDyWFAQOk8QdhMZYhBwExli EHZqbWIQcGptYs9wz3ZSEHbGyWIQcMbJYhB23sJiEHDewmIQdtTcYhBw1NxiEHYq0WIQcCrRYhB2 PCZiEHA8JmIQdjQ6YhBwNDpiEHYKD2IQcAoPYhB2HwRiEHAfBGLoUs7ndHdPZx87UXARX1InUGBS J1AQUidQAFInUFRSJ1InUidQqVRQUE9Sy+J6ek/oUsoQe3l6T9DqUdDsUdACUdDyUdA1UdAuUdDR UdBsUdAOUdB7UdBMUdBOUdAQUdDrUWhQUVDQURDkUdAQUdDrUWhQUVDQUWkQSFHQmlHQ/VHQI1HQ dlHQdVHQdFHQcFFnEOhSceIZYxDoUnHiFWMQ6FJx4xESYhDoUnHjbW5iXxFfUnFQb1JxUC9ScVBT UO9ScVCfUnFQr1JxUFNQEFJx43ByYhDoUnHjSU5iEOhScuN6b2IQ6FJx435qYj8RGFKTUC9Sk1Df UpNQj1KTUFRQf1KTUDBSk1CfUpNQU1BfUpNQb1KTUA9Sk1CQUpNQv1KTUK9Sk1BWUI9SclBRUN9S clBRUF9SclB/UnJQb1JyUA9SclAvUnJQv1JyUFZQ71JxUL9ScVBSUD9ScVAvUnFQ/1JxUFNQf1Jx UG9ScVAfUnFQU1KTUpNSclJyUnFScRBNQExAe0AYU99MUV9OUR9Or05SZ1BGRlBQUEJBWEHoUV3m p12op11QWRFZUt5S31BNUE9SwFLfUE1QT1Lf4qlNT+hRyOJ2608RRVHHUE5UUVBPUWlQdlF1UE9R aFAjVFFQT1FlUExYUVBPUWRQTFL7UE9RYuJMBk/oUV/idnxP6lFeUE5UUeZPqUy0T7lM6FJR5k+4 TOtPh3DoVFHiT4VM6FL75k+ETNlPmX/oWFHiT+x26FFR4k/qcOhSUeZP6UxoT/2a6FRR4k/RduhR yuJPLnboUcrmTy1MF087TOhUUeJPNXboUcriTw4j6FRREF9PAnYKTxhM2U8UTDJPECPoWFHmT29M Dk9sduhRyuJPZUzoVFHmT2BM6097TOhUUeZPekwGT3lM6FFR4k9zTuhUUeJPBWfoUTgQfFfGVwhX H1dmV2JXfFdxV09XTVdLV0RYQlhAWF5YXFhaWFhYVlhUWFJYUFhE6K+wEHtQUFFQRFZAUFBRUFZU UFBRUFRAUFBRUEBSUFBRUFJQUFBRUFBSUVhSUBpQ4ENTG1IbAxJRG+CQM1AbMnDgpgNz6FFaAQrg VXMSUeBCG1AbBBLgaHsb6FevAuBnexvgVwALCOFRUd4J4Gh74FLY6FFQBAjoUa/hUVHe1UvgQhMI 6VBRUUHV3UvpUFFReNXdCQlQSEYmb0hvQm5BaRYUbkFpFhRuQWkWFG5BaRYUbkFpFjAUbkFpFjAU e3t7e3t7e3t7e3tIe3t7e3t7e3t7e3tIe03gxhsDCOD6TQngYhsDCOCvTQkb4MMDcAwI6VGiUaAV FOlRoVGgFRQJCOlTblGiFQII6VGiU24UCQkb6FEGA3AMCOlQcFGhFRTpUHZRoRUUCQjpWE5QcBUC COlQcFhOFAkJG+hRygNwDAjpUHVRohUU6VB0UaIVFAkI6VlZUHUVAgjpUHVZWRQJCRvoVFEDcAwI 4SN0FRThdHQVFAkI6UdwUCMVAgjpUCNHcBQJCRvoVFEDcAwI4Zp1FRThdXUVFAkI6UbQUJoVAgjp UJpG0BQJCRvgbgNwDAjhTEwVFOFOTBUUCQjpUUpQTBUCCOlQTFFKFAkJG+AGA3AMCOFMTBUU4X9M FRQJCOlR2VBMFQII6VBMUdkUCQkb6FNRA3AMCOFMTBUU4UxMFRQJCOldsFBMFQII6VBMXbAUCQl7 e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7ezUSe3tR42sJMwwVNXMVMHMV NTBzFTDg2yY4SODQMnBw4TMJFTVzFXDgU3YwMjM4cOBTdjE14AlzNRTgM3MUcOFrDBU1cxVw4FN2 MDIzOHDgU3YxNeAMczUU4GtzFOFQDBUECOEMEDUU4msQaxVzMRQJ4xcAZGcVNXMVMHMVNTBzFTDg 2SY4SODQMnBw4WQAFTVzFXDgU3YwMjM4cOBTdjE14ABzNRTgZHMUcOEXZxU1cxVw4FN2MDIzOHDg U3YxNeBnczUU4BdzFOFQZxUECOFnEDUU4hcQFxVzMRQJUBsDElEbAAjhWFASCRMMCOFYUBIJ41Jb WkITCDBLcQkSRkAgbuBCEwjpa3FILkvqVFBR+FBbewngXHMS4F1zEuBCEwjpfRF9EUvqVFBUUFBb ewngXnMS4F9zEuBCEwjpSC5rcUvqUfhUUFBbewngQHMS4EFzElB7JCUjJVBIFTkUFTkUFTkUIyMj IyQlIyQle3t7eyQle3t7e3sjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMje3t7FeAQMRQjJFBQG+B6 AxvgbwEKCOFXVxXgEDAUCVAb4GoDG+BvAQoI4VtbFeivkDAUCVAb4H4DG+BqAQoI4VNTFeAQMBQJ UBvgfgMb4GwBCgjhWVkV6K+QMBQJe3t7e3t7e3t7e3t7e3t7e3t7JXt7e3t7e3sTDAjpUNBS6+NR EE5RJFAjCVPgThsEUuBCGwQK4EITDAoI6lDPUnJQUVAjCVB7JCNRe1AQEREQb25tbGtqaWhnZWRj YmFgf359fHt6eXh3dnV0c3JxcE9OTUxLSklIR0ZFRENCQUBfXl1cW1pZWFdWVVRTUlFQfBVzFjBw 4HYw4FR2cxgYfXwVcxZzMXDgdjHgVHZzGBh9fBVzFjDgcDFw4BYw4FR2cxgYfXwVcxZzMeBwMHDg djHgcDHgVHZzGBh9fBVzFjDgEDFw4DYw4FR2cxgYfXwVcxZzMeAQMHDgdjHgEDHgVHZzGBh9fFFA cGxQbH18cBVzcOCdFHNw6FEKAQhzcODdFHMJcOC9AQhzcOAdFHMJcODAAQhzcOBdFHMJcXF9fHBw FUg4FHDgUTBwFeAWJjjaFTAUfXxR4VtaE3MTNVp9fFDhWlsTcxNbfXxQ4EdzIOFRR25R4EdzIOFS RxVq4VJQWF19fBXgSnMUFeBJcxR9fHAV4FN1FTE04AABCBUUS3FxCX184FETM3My4FBzEuBfe318 cBXgUBMwFH18UeBWE+BXEzVafXxwOeAQMeBQ23DhfJDa3OhAUDIwe1w0czQxDAjgUzEJfXwV4EF7 4EdzFOBHKrRIfXwV4EF74EdzFH184EITCNcV4EF74EdzFOBHKrRLU9oVSDlw4EdzFNra13Dg8AEI 4EF74EdzFOBHKrRLceBHKrQJCUh9fH184FJ1FjDaFuAQMdwYfXwbA3AMCOBS1QkI4FHVCX18cOBT dRXgSXMUFeBKcxQVNXMVcOBTdTA6cOBZcxJzONo6MDFw4Era4FACKXHiSkoQ6a+wUEoVcNoECHNx 4G9LcwkxFEzhRFDaAinjSRBwSRVw2gQIc3Hgb0tzCTEUfXzhQEETcxNbfXzhXl8TcxNbfXzhXF0T cxNbfXzhXF0TcxM1W3184V5fE3MTNVt9fOFAQRNzEzVbfXwbAggVFEtxcQl9fFFw4FN1cxngEDDg cDNw4FACCHPgUnVoc+BSdTVoUNozaEtxcXFxcQlRfXwb4DQBCBU54FkTMNpAaktxcXEJfXxR4FV1 QHNw2qVQ4FEwc728fXxR4FV1QHNw2qVQ4FExc728fXxR4FZ1QKVQvbx9fHDgUTBRQHBsUGx9fHDg UTFRQHBsUGx9fOB7e+B6en18UOBXE+BWE1t9fG7genp9fGV9fCboUnNzIEBw6FJzFXDgUAAI4FEx CWp/SH18cXFcNHM02+gQUDJ9fHHg0AEIXDRzNNvocFAyS+JQEH97CeBSMH18ceCQAQhcNHM02+hF BTJL4lDQf3sJ4FIwfXxcNHM02+gQUDIwc3F9fORQUVBQUEXgWHbgWHbgWHbgWHZfQEZDFThq4FFG fXzkUFFQUFBF4Fh24Fh24Fh24Fh2X0BGQxU4NWrgUUZ9fBsDcxsBCghwFdowFEtxcQl9fBsECHAV 2jAUS3FxCX18GwNzGwEKCGhLcXEJfXwbBAhoS3FxCX184EMTCFNLUgl9fOBDEwhSS1MJfXwbBOBC EwwKCGhLcXEJfXzgQhMMCFzgVHXgVHVWXDRzNDE06FdYAQjgVHXgVHVRcBbgQDAYcBbgQDAYCVpx cUtxcQl9fOBCEwwIXOBUdeBUdVZcNHM0MTToV1gBCOBUdeBUdVFwFuivoDAYcBbor6AwGAlacXFL cXEJfXwbA3MbAQoI4Gp7S3FxCX18GwNzGwEKCOBre0txcQl9fBsDcxsBCuBCEwwKCGhLcXEJfXxc 2lMbBOBUdlIbBAra2lrgQhMMCghoS3FxCX18GwII4FR14FR1GeBUdeBUdRkxcOBQBAhxcBPgUAUI 4FN14FN16K+QaOivkGgJS+AQBAhwE+BQBAjgUnXor5BoCUtwE+BQBAjgU3XgU3Xor5Bo6K+QaEvg U3Xor5BoCQkJCXFxcXF9fBZzFjDa2hZzcBbaMNox6K/QMnNwQHPa6VKSUpLaIBUwcOBQAAjgUTHo r+rbS+AW3AngQDA4UWp9VepQSVXqUEpV91BJVHZQSFBQr7dQUK+4UFCvt645r7hV6lBJrjmvuFK6 UFBQ6FBQUOivr6+vUPhQ/VE5UP1Q71CSUaBQSFD/UOlQ5FCYUEdQFFDMUCxQxFDXUFZQClCYUNlQ AlACUFVQFFDEUUmv5FB/UPFQU1DxUJ1QR1AHUC5Q6lBGUUivuVAvUNVTg1DXUNVQXVByUBFQAFA/ UN1RHK8lUAxQj1TTUGdQHFA+UCBR0K8Ir96vwq/0UPVQ6VOYr61QW1BKUDNQM1Cdr75ViK+MUH1Q DFDFUMlQj1HCWeVQEFAHUNBQ6VPNUCJQylMNVFGvN6+qUFNQcVAnUJ1QVFAdUJ1RkFJ7UBxQNVC3 UUhRLFMTVYiv86/gr5RQU1BMUA1QOFDKUOpRZVEXUnFVDK8dr51QRlB9UChQ0FDJUOJQ5lDmUOhQ 7VCKUVxVoK/0r6BQSVB8UBlQL1DkUJ5RkFOurdGub1BQUFVQSFB5UGlQGVA/UO5Ql1CAUXNRkVI/ VVxVYlUQVSqvhFBEUGFQBVAHUPdQ5FC2UadSLlIuUi9TllQWrxJQXlDVUMFQ71CSUJVQsVFKUX9R H1EGUnlSP1LOUyJQWFB8UGFQYVA0UDlQ2VDIUJdQjlF7UeZSXFKfU/NU+1SrVk2usK9eUFZQdlDL UM1QkVFdUUhRcFEjUdJRhlGzUhNSD1LLUrJTxFT5VIJXMVBMUA5QPVDdUPtQp1FCUWhRAVELUThR LFHXUcFRyVGdUYBRuFIRUgRSO1K/UzhTIVPtVBJUElQDVCNU01XWVdtWuK4IrpSuga6nr2Kv1lAB UCxQ0VDBUMVQzlDkUOlQn1CJUIlQj1CyUVVRW1FeUV5RcFFxUQVRK1ErUS5R3VHyUfhR+VHkUYBR gFGyUblRolGlUatSUFJQUlZSS1JxUnJSclJzUiJSJ1LEUsxSn1KfUoBSvFKpU0dTclN7U2VTbFMJ Uz9TIVPXU8BTwFPlU7FUSlSfVK9VYlViVcZVz1X4VftVklWgVlxX0lhQWJys8616rY6uUK7Yrsau 4q7kr7FQRVBJUEpQTFBPUGxQAVAxUDFQOlAoUMZQ9VD/UINRXFFIUUpRelFuURxRAVEPUTpRIVEo UdJR1FHKUfVR+FH5Uf5R7FGdUYdRv1JQUl1STFJxUnJSflJlUhJSH1IfUg5SNVIhUsBSwlLkUoZS qlNXU1tTX1NFU3pTF1MNUzVTJFMpU8ZT4FOcU41TslOmU6xTrFOvVFpUT1RyVHZUe1QXVA9UJVTO VLdUt1UMVZtVtVZaVj1W1lboVqFXZlduVwBXAVcNV99X5leEWDBQ5lCTUOVQ51BQUFBQUFBQUFBQ UFGwU9FTFVPlUN5SY1RJUp5SnlB9UA9QNFMdUm9QUFL4UdhSLVHkUnRVKFZrUmtRHlCgVHZSxFKW Us9SplJrUx1RG1EDUDpSYVBQUFBQUFZEVPpQUFBsVJNQvVTsUjVSnlPlUChWXFEuUr9WXFDiUVBS aVBQUZVTYFR7U5tQilOPUVdU8VCLVFpRR1G9UvdTAFFbUe1UblUIUHFTzFD+UyFRLVDlUhVQUFqr WNxRe1EeUfpQ11AEUWJRqFOvUFNSHlDkUGdTs1DTUDtSiFC9UCdQ2FDHUTRUN1DeUGNRLFC3UPZS zlN5VT5WelZFUZlSOVTaUkNR5FBSVPlQUFJpUXRRU1VEUNRRDVPKVr9SiVAlUJ9UWlCOU/xU7FKf Uv5THVSgVQJROFA9UC1Q1lAhr9FQKVUIVIJRN1BTUQZQdVSwUMRQLFNiVHFQxFAvUCJQDFB/UOZQ SFDqUOhQEVMdUCJQSFBPUBxROlEFUMlQylDKUMhQ4lBUUChQOVBEUAdQPlCeUORWBFLoUDdVXlE1 ULdQUFSbVlBRUFBQUFBSaVBQUmlQUFJpUOBSh1AOVCNQRVQjUBlXTVAnVQZQCFHXUApS+lAsUvpQ LFNNUBBU/FAiUmlQ+lL6UBFSaVDqUmlQUFQjUAVUI1CPVCNQbFQjUAZUI1BKVCNQBVQjUB1UI1Ax VCNQA1QjUAVSaVDpUmlQ+lT8UCBU/FAiVPxQIFQjUApYT1A/VQavrVUGUMZVl1A2VZdQzlUGUPJU s1D4VmlQPVWXUPRSaVDvVFBQZ1UGUMZUI1DGVvpQyFWXUMxWaVAzVQZQzlZpUAhVl1DxVQZQDFSz UGBVl1DxVQZQWVfdUElVBlBZVQZQVlSzUHlSaVDbUmlQUFJpUHdTkVBmVCOvsVL6UAlUI1AaVCNQ 1lRQUABUI1AWVCNQG1JpUENUI1ASVCNQ11GXUNhRl6/yVFBQ2FGXUNNW+lDXVCNQ11QjUBRUI1DX VCNQGFL6UNVUUFBvUmlQdFQjUNNUUFBKVZdQVlRQUF9UUFBxVFBQeFL8UGlSRFDsUvxQf1T8UAdV Bq+tVQavrVWXUDhVBlDyVZdQzFZpUDNVl1DxVCNQGlQjUBpUI1AaVCNQGlQjUBpUI1AaVFBQAFQj UBtUI1AbVCNQG1QjUBtSaVDtUmlQc1Jpr7VSaVBZVCNQ11QjUBRUI1AUVCNQFFQjUBRUI1AUVCNQ 01QjUNNUI1DTVCNQ01QjUBlTY1DQVCNQO1QjUEtUI1ABUp1QPVQcUFFUs1DJVbVQU1W1UFNYUFCx UvpQjlL6UG1YUFBRVmlQA1Q0UB5UI6+tVMxQ8FKmUH9SvFB9V01QFFSzUNFUs1DOUvpQuFT8UCJU I1B+VCNQ1lQjUNxYUFC/VQavrVUGr61WaVAzWFBQ0VfdUAJUI6+sWFBQUFL6UANS+lAXUZdQ0FGX UDxUNFAeVFBQcVUGUFZUI1AaUvpQDFL6UAxUI1AZUmlQ6VGXUDxS+lAXWFBQdVUGr61VBlDyVQav rVUGUPJVBlDyUmlQ3VJpr7BSaVBUUmlQRVZpUDNWaVAzVmlQM1WXUPFVl1DxVZdQ8VJpUJZS+lBJ UvpQVlL6UPJS+lA7UvpQeFUGUAxUUFBvVLNQeVRQUHhSRFDsVZevrVQjUBlVBlBWVFBQcVUGUM5U I1DXVPxQ8VL6UDtS+lBJUvpQcVb8UDtW/FA7VvxQcVQ7r7FUI6+0UFBQSFBQULBbW1hQU1NSVFZW WldSVFRUVlNUU1NWVlZWVlZWVlZWU1NWVlZWW1hXV1dWVlhXUlVXVlhXWFZYV1dWV1haV1hXU1NT VVZUVlZWVlZUVlZSUlVSWFZWVlZUVlNWVlpWVlZUUlRWWFhXVldYV1ZWVlZWVlZWVlZWUlJSUlZW VlZWVlZWVlZWVFZWVlRWV1hYW1RUW1hWVlZUVVpWVlJWVlZWW1hYWFtaVltUVFJSVlZYV1RUVlNS VFtYVlhWVlJSUlJYWFhXV1dSVFRUVFRXVldWUlhWWFZXVlZUVFRaWVpWVlxcWVBTU1NUV1dbWFJU VFVXU1RTU1dXV1dXV1dXV1dTU1dXV1dcV1hZWVhXWVlTVlhXWVlZWFlZWFdZV1tXV1dTU1NVV1RX V1ZXV1NXV1NTVlNbV1dXV1RXU1dVWVVVVVRTVFdXV1lYWVlZV1dXV1dXVldXV1dTU1NTV1dXV1dX V1dXV1dVV1dXVFZYWVlcVFRcWVdXV1RUW1dXU1dXV1dcV1dZXFtXXFRUU1NXVVdXVFRXU1NUW1dY V1hYU1NTU1lZWVlZWVNUVFRUVFhXV1VTWVdXVVhXV1RUVFpaWldXXV5aUFRUU1VXV1xZUlRUVVhU VFRUV1dXV1dXV1dXV1RUWFhYV11ZWVlZWVhaWVNWWVdbWVpZWllZV1lZXVdZV1RUVFVXVFdXV1dX U1dXU1NXU1tXV1dXVFdUV1VZV1dXVFNUWFlZWVlZWllXV1dXV1dXV1dXV1NTU1NXV1dXV1dXV1dX V1VXV1dVV1laWl1UVF1aV1dXVFVcV1hTWFdXV11ZWVpdXFddVFRTU1dXWVdUVFdUU1ReWVlZWVlT U1NTWlpaWVlZU1RUVFRUWVdXV1NZV1lXWVdYVFRUW1tbV1dfX1tQVFRVVVhYXVpTVVVWWVRVVFRY WFhYWFhYWFhYVFRZWVlYX1laW1taWVtaU1daWFtaXFpcW1pZWllfWVlYVFRUVVhVWFhYWFhUWFhT U1dTXVhYWFhVWFRYV1tXV1hVU1VZWVlbWlpcWlhYWFhYWFhYWFhYU1NTU1hYWFhYWFhYWFhYVlhY WFVYWVtbX1VVX1xYWFhVVV1YWVVZWFhYX1lZXF9eWF9VVVNTWFdZWFVVWFRTVV5ZWllaWlNTU1Nc XFxaWlpTVVRVVVVaWFhYU1tYWVdaWFlVVVVdXV1YWEBBXFBUVFVWWVleW1NVVVZZVFVUVFlZWVlZ WVlZWVlUVFlZWVlAW1tcXFtaXFtTWFtZXVtcW1xbW1lbW19bWVlUVFRXWVVZWVhZWVRZWFRTWFNd WFlZWVVYVFhXW1dXV1VTVVlbW1xbW1xbWVlZWVlZWFlZWVlTU1NTWFlZWVlZWFhYWFlWWVlZVllZ XFxAVVVAXFlZWVVVXllaVVlZWVlAW1tcQV9ZQFVVVFRZV1lZVVVZVFRVQVtbW1tbU1NTU1xcXFtb W1NVVFVVVVtYWVdTXFlZV1tZWVVVVV1dXVlZQUFdUFVVVVZZWV9bU1ZWV1pVVlVVWVlZWVlZWVlZ WVVVWlpaWUFbW1xcW1pcW1VZW1ldW1xbXFtbWVtbQVtbWVVVVVdZVllZWVlZVVlZVFNYU11ZWVlZ VlhUWVdbV1lYVlVWWltbXFtbXFtZWVlZWVlZWVlZWVVVVVVZWVlZWVlZWVlZWVdZWVlWWVpdXUFW VkFdWVlZVVVfWVpVWllZWUFbW1xBQFlBVlZUVFlZW1lWVllVVFZBW1tbW1tVVVVVXFxcW1tbVVZU VlZWW1hZWFVcWVtZW1laVlZWXl5eWVlDQ15QVVVWV1tbQV1UVlZXW1VWVVVbW1tbW1tbW1tbVVVb W1tbQ11dXl5dXF9dVlpdW19dX11fXl1cXV1DXVxcVVVVV1tWWltaW1tWW1pUVFlUQFpbW1tWWlVa WV1ZWVlWVlZbXV1eXV1fXVpaWlpaWlpbW1tbVlZWVlpbW1tbW1paWlpbWFtbW1daXF5eQ1ZWQ19a W1tXV0FbXFZbW1tbQ11dX0NCW0NXV1RUWllcW1ZWW1VUV0FdXV1dXVZWVlZfX19dXV1WVlVWVlZd WlxZVl5bXFldW1tWVlZAQEBbW0VFQFBWVlZXXFxDXlRXV1hcVldWVlxcXFxcXFxcXFxWVlxcXFxF XV5fX15dQF5WW15cQV5AXkBfXlxeXUVeXl1WVlZYXFdcW1tbXFZbW1VUWlRAW1xbW1dbVltbX1pb WVdWV1xdXV9eXkBeXFxcXFxcW1xcXFxWVlZWW1xcXFxcW1tbW1xYXFxcV1tdX19FV1dFQFxcW1dY Q1xdVlxcXFxFXV1ARURcRVdXVVVcW15cV1dcVlVXRV1eXV5eVlZWVkBAQF5eXlZXV1dXV15bXVlW X1xeW15cXFdXV0JCQlxcSEpCUFdXWFldXUVAVVhYWV5XWFdXXV1dXV1dXV1dXVdXXl5eXUhfQEFB QF9DQVZcQF1DQUNAQ0FAXkFfR19AX1dXV1xdWF1eXF5dV15eVVZcVkReXV5eWFxXXltBW1xcWFZY Xl9fQUBBQ0FdXV1dXV1cXV1dXVZWVlZeXV1dXV1eXl5eXVpdXV1YXV9CQkhYWEhDXV1eWVlFX19Y Xl1dXUhfX0NIR11IWFhVVV1cQF1YWF1XVVhKX0BfQEBWVlZWQ0NDQUFBVlhYWFhYQFxfXFZBXUBc QF1eWFhYREREXV1LTURQWFhYWl9fSEJVWVlbQFhZWFhfX19fX19fX19fWFhAQEBfS0JCRERCQUVD WF1CX0dDRUFFREJAQ0FMQUJBWFhYXF9ZX19eX19XX19WVl5WRl9fX19ZXlhfXUNcXl1ZVllAQkJE QkNFQ19fX19fX15fX19fVlZWVl9fX19fX19fX19fW19fX1lfQURES1lZS0VfX0BaWkhBQVhAX19f S0JCRUtJX0tZWVZWX15CX1lZX1hWWU1CQkJCQlhYWFhFRUVDQ0NWWVhZWVlCXkFdVkRfQl5CX0BZ WVlHR0dfX01ORlBYWFlaQEBKQ1ZaWltBWFpYWEBAQEBAQEBAQEBYWEFBQUBNQ0NFRUNCR0VXX0NA R0VHQ0dFQ0NFQ05DQ0JYWFheQFpAQF9AQFhAQFdXXldJQEBAQFpfWEBdRV1dXlpYWkFDQ0VDRUdF QEBAQEBAX0BAQEBZWVlZQEBAQEBAQEBAQEBcQEBAWkBCRUVNWlpNR0BAQVtbSkJCWUFAQEBNQ0NH TUtATVpaVlZAXUNAWlpAWFZaTUNDQ0NDV1dXV0dHR0VFRVlaWVpaWkNfQl5YRUBDXUNAQVpaWkhI SEBAcHBIUFlZW1tCQkxFVltbXENZW1lZQkJCQkJCQkJCQllZQ0NDQnBFRUdHRURJR1lARUJLR0lF SUdFQ0dFcEVFRFlZWV5CW0FBQEFBWkFCV1dAV0tCQUFBW0BZQl9HXl9fW1hbQ0VFR0VHSUdBQUFB QUFAQUFBQVlZWVlCQUFBQUFCQkJCQl1CQkJbQURISHBbW3BJQkJCXFxMRERbQ0JCQnBFRUlwTkJw W1tXV0JfRUJbW0JZV1twRUVFRUVZWVlZSUlJR0dHWVtZW1tbRUBEX1hHQkVfRUJDW1tbS0tLQkJx cklQWVlbXEJCTUZWW1tdQ1lbWVlCQkJCQkJCQkJCWVlDQ0NCckZGSEhGREpIWUFGQktISkZKSEZF SEZyRUVEWVlZXkJbQUJBQkFaQkJXV0BXS0JBQkJbQVlCX0dfX0BbWFtDRkZIRkhKSEFBQUFBQUFB QUFBWVlZWUJBQUFBQUJCQkJCXUJCQlxCREhIcVtbcUpCQkNcXE1ERFtDQkJCcUZGSnFPQnFbW1dX Ql9FQltbQllXW3BGRkZGRllZWVlKSkpISEhZW1lbW1tGQURAWEhCRV9GQkNbW1tMTExCQnV2TFBa WltdRUVxSVdcXF5GWlxaWkVFRUVFRUVFRUVaWkZGRkV2SUlLS0lHTUtZQ0lFT0tNSU1LSUdLSXZJ R0daWlpBRVxERUNFRFpFRVdZQ1dPRUVFRVxCWkVBS0FBQlxZXEZJSUtJS01LREREREREQ0RERERZ WVlZRUVFRUVFRUVFRUVfRUVFXURHS0t1XFx1TURFRV5ecUdHW0ZFRUV1SUlNdXNFdVxcWFhEQUdF XFxFWlhcdUlJSUlJWVlZWU1NTUtLS1lcW1xcXElCR0JZS0VHQUlFRlxcXE9PT0RFentwUFxcXl9H R3VMWF5eQElcXlxcR0dHR0dHR0dHR1xcSUlJR3tMTE5OTEpxTlxFTEdzTnFMcU5MSk5MektMSlxc XENHXkdHRUdHXUdHWlpFWnRHR0dHXkRcR0dNRkVFXlteSUxMTkxOcU5HR0dHR0dFR0dHR1xcXFxH R0dHR0dHR0dHR0FHR0dfR0pPT3peXnpxR0dIQF91SkpeSUdHR3pMTHF6eEd6Xl5ZWUdFTEdeXkdc WV57TExMTExcXFxccXFxTk5OXF5dXl5eTERKRVtOR0xFTEdJXl5ec3NzR0d+f3NQXV1eQEpKeU9Z X19CS11fXV1KSkpKSkpKSkpKXV1LS0tKf09PcXFPTHRxXEdPSnVxdE90cU9McU9+T05MXV1dRUpf SkpHSkpeSkpaWkdadkpKSkpfR11KR3FHR0dfW19LT09xT3F0cUpKSkpKSkdKSkpKXFxcXEpKSkpK SkpKSkpKQkpKSkBJTHJyfl9ffnRJSktBQXlMTF5LSkpKfk9PdH57Sn5fX1paSUdOSl9fSl1aX35P T09PT1xcXFx0dHRxcXFcX11fX19PR0xHW3FKTkdPSktfX192dnZJSmJjdlBeXkBCTEx8cVpBQUNN XkFeXkxMTExMTExMTExeXk1NTUxjcXF0dHFPd3ReSXFMeXR3cXd0cU90cWJxcU9eXl5GTEFMTElM TF5MTFxaSVx4TExMTEFJXkxJc0hJSUFcQU1xcXRxdHd0TExMTExMSUxMTExeXl5eTExMTExMTExM TExETExMQktPdXViQUFid0tMTUNCfE9PQE1MTExicXF3Yn9MYkFBW1tLSXFMQUFMXltBYnFxcXFx Xl5eXnd3d3R0dF5BX0FBQXFJT0lcdExxSXFMTUFBQXp6ekxMZmd5UF9fQUNOTmB0WkJCRXBfQl9f Tk5OTk5OTk5OTl9fcHBwTmd0dHd3dHF6d19LdE59d3p0end0cXd0ZnNzcV9fX0hOQk5OS05OX05N XV1LXX1NTk5OQktfTUt3SktKQl5CcHR0d3R3endOTk5OTk5LTk5OTl9fX19NTk5OTk5NTU1NTkZO Tk5DTXF4eGZCQmZ6Tk5PRERgcXFBcE5OTmZ0dHpmY05mQkJcXE5Lc05CQk5fXEJldHR0dHRfX19f enp6d3d3X0JAQkJCdEtxSl53TnNLdE5wQkJCfX19Tk5qa3xQQEBDRXBwZHdbQ0NHckBDQEBwcHBw cHBwcHBwQEBycnJwa3d3enp3c316X013cH96fXd9end0endqdXZzQEBASHBDcHBNcHBAcHBdXU5d YXBwcHBDTUBwTXlMS0xDXkNyd3d6d3p9enBwcHBwcE1wcHBwX19fX3BwcHBwcHBwcHBwR3BwcERP c3t7akNDan1wcHFFRWRzc0NycHBwand3fWpncGpDQ11dcEt2cENDcEBdQ2l3d3d3d19fX199fX16 enpfQ0FDQ0N3TXNMXnpwdkt3cHJDQ0NgYGBwcBMUYlBDQ0ZIdXVsfV1GRkp3Q0ZDQ3V1dXV1dXV1 dXVDQ3d3d3UUfX1gYH15ZGBDcn11Z2BkfWRgfXlgfRJ7fXlDQ0NOdUZ1dXJ1dUN1dV9fcl9pdXV1 dUZyQ3Vxf3BxcUZBRnd9fWB9YGRgdXV1dXV1cnV1dXVCQkJCdXV1dXV1dXV1dXVLdXV1R3R5YWET RkYTZHV1d0lIbHl5Rnd1dXUTfX1kE291E0ZGX191cX11RkZ1Q19GE319fX19Q0NDQ2RkZGBgYEJG REZGRn1yeXFBYHV9cX11d0ZGRmhoaHV1GxxoUEVFR0t6ehNiXklJTXxFSUVFenp6enp6enp6ekVF fHx8ehxiYmZmYn5qZkV2YnptZmpiamZifWZiG2FhfkVFRXJ6SXp6dnp6RXp6QUF2QW96enp6SXZF enVldHV1SURJfGJiZmJmamZ6enp6enp2enp6ekVFRUV6enp6enp6enp6ek56enpKeH5nZxtJSRtq eXp7TEsTfn5HfHp6ehtiYmobF3obSUlBQXl1YXpJSXpFQUkcYmJiYmJFRUVFampqZmZmRUlISUlJ YnZ+dURmemF1Ynp8SUlJb29veXoDBG5QR0dJTX5+GmdATExwYEdMR0d+fn5+fn5+fn5+R0dgYGB+ BGdnbGxnYxFsR3pnfhVsEWcRbGdkbGcDaGZjR0dHdn5Mfn56fn5Ifn5CQ3tCF35+fn5Mekd+eWt6 d3hMRExgZ2dsZ2wRbH5+fn5+fnp+fn5+R0dHR35+fn5+fn5+fn5+cX5+fk19Y21tA0xMAxF+fmBP ThpjY0lgfn5+A2dnEQMefgNMTEJCfndmfkxMfkdCTANnZ2dnZ0dHR0cRERFsbGxHTEhMTExnemN4 RGx+ZndnfmBMTEwVFRV+fgwNFVBKSkpxY2MCbUJPT3RmSk9KSmNjY2NjY2NjY2NKSmZmZmMNbW0S Em1oGBJKfm1jGxIYbRgSbWkSbQtubWhKSkp5Y09jY35jY0tkY0RFf0QdY2NjZE9+SmN9EX19fU9H T2ZtbRJtEhgSY2NjY2NjfmNjY2NISEhIY2NjY2NjY2NjY2N1Y2NjcGFoFBQMT08MGGNjZXJyAmho TGZjY2MMbW0YDAdjDE9PRERjfW1jT09jSkRPDW1tbW1tSkpKShgYGBISEkhPTE9PT21+aH1HEmNt fW1jZk9PTx0dHWNjNDYbUExMTHRoaAkTQ3Fxd2pMcUxMaGhoaGhoaGhoaExMampqaDYTExgYE20e GExiE2gDGB4THhgTbhgTMxISbUxMTHtocWhoYmhoTWdoRkZiRgRoaGhncWJMaGEXYWFhcUpxahMT GBMYHhhoaGhoaGhiaGhoaEtLS0toaGhoaGhoaGhoaHhoaGhzZm0aGjRxcTQeZ2hqdXUJbW1Pamho aDQTEx40Dmg0cXFGRmdhEmhxcWhMRnE0ExMTExNMTExMHh4eGBgYS3FPcXFxE2JtYUoYaBJhE2hq cXFxAwMDZ2hQUlFQUFBVUFVQUFNQV1AS5FJRtFZX6FLJEENQVVS0U1BaV1S0UVBJWFZVtFJT7FJh UFlRyVF+UEh7QKZsrWweQKRsHa1sUG9srWxArGytbGFgcUFxQXVxQXFRUFRQrHBTkKwQVVCrUHBU kFBQUlDgUFBR31XqUFVQWVAH4UxV6FL/EHZYbFZSUFZaW5tTWWpVaFRsUGhWalFTbFJScFFRUZta WlvRcfHISHt7HkCkDWwdQL1AtLSttLRAvlBvbx1ArbYbAwjjVVRQUVFAbEBsCWFgQ1NBY0FTU2Vj Rbdnj2Tzn1E8U1lRFa7rrKeuxJ2dUFBSUA5T41InVepQVVBbUCXpUFCvqONydWRV6K+oEHJ2eWRb VlpXVVBUUVBVVVZbvllYWFNTUlBXWGxaX1nQWVJZ6K+QEEVdX2RZjlFTVGxSURBdQWRRSVwh90h7 HkCke2wdrWxArXsNbK1sUG9sQGxAbK1sbEBsUUFCaWlBQmlpYWBRe3tDU2VjRVNjU2VjRVPAYp19 jWGdYFPjUUegoK65UUegoK65UFBSUEWvt1QJVYNQS1BPUWEQ13hNaE1SWVRZTVIHX+dD50yXQ5dM qE1WUVJFUFlUU0RQWVVWQVBZWFdAUFlbV0BLWlxXQEhdX1dAR15CVkFHXkNTREdeRlJFR15JUkVI XUpSRUtaTFNES1pNU0RIXU5WQUhdT1ZBS1paS0t1UFlEUFBZXUhIdUdeREdHXkVSdURTU1BAV3VB VuhR5hBoXl5dXVpaWVBLSEhHR1BaRUREQUBuXldWVlNSblBIxF1HxF11XhBBaR9ez15SXiVxWsRL WcRLdVDor5DlQWlwUFFQ6FLx43D5OEh7QKYNe720QLRApg17vbRAtECkbGxAbECkbGxAbFBvbEBs QGxvbEBsQGxArWytbEFpf2ytbNdVfnstQJTXfkh7LUCUX19fX19fX19fX19fX19fX2FgUQ0NIUdD c2VjQ3FlcUNjU3FDY1NjRXNTcUVxU3NDcVNDcUNxNwf5lxquv1F/B8YHUWsHxwf9mxtRRq6cB8YG rpYHJVFqG66VSVH6xVE7xVH9rgNR/a4Dxa7Fxa4GUfquBlJvUTtQU1AZr31UQ1YRUHpQYVBoUYQQ dSxOUVRgfGZmfxZxBXEAfw1mOlMzfypTJ3Ejfytm13HQf95mQGHor47nW2lOcHB0ZHzor7AQfHBz ZDpYaHpGXGdwRnpgcVtQRVxnYWBxUEVncWBgmlxnRFxcZ2BccWdUR2JW6FL05gBVUVW9UUzqUvRQ S1L940dPg3voUWUQWkRFRtBHR0RVUHroUWfiUVpi6FFl5HmDUV1M6lFoUEtSyOJlI3bor5AQWkJp YHYQdtB2U3boUgIQX3pGR0dPT3BwaGhiYnl5euhRwxBGUEVERHt7YWFbW1paYFAQUNBQgFBUUOhS XBBZVX4jP0AvQFJA6lHeUFZRaBBfb1UfVS9V31VUVUlpl9tIex5ApA0dvaQhvUCkDWxAbEBsQGxA bEBsQK1sQGxAbEBsQGxAbEBsQKQNe72kvVBvpK1sQKRsb2xApGxArbRArbRArQ20QUJHaddefnvX Xi2UX19fX2FgSBMpEBpxZ1xDdHVzdXJ1U1ZCdl5fXV9SVmdxZR9RY3hlH1F8Q34fUGBcfh9QZnVo H1FxcGdoZHdiH1BjYn1Bex9RfHtDRH9fYR9QYGFcW1BAbEBse0BsQGx7QGx7QGxAbHtRe3t7e3p7 etHRUXt7UHsNUQ1VZX5Sd2dGR0ZHQXZ3dnZlZGdmZ2VjRUZHRkdXdnZ3QUZHTlJFRFZXRVNWVkVE RkdDZmZlZHZ3Ua7X+Sta5UVlHDo/JAYN2AvjOs0MJkjqQDUI2HwEOmm+7To5KTcrOjnZMcGD5EEH ktxywRQwW1JtRRFg+jyQJwBCBgZfHTL7TDohQq2pckN1OsIF66pZ5lZ4QNgNDCx1rUZdzCMyJ39Q UFVQJ6+aVs9Vg1BbUEdQS1B3UGNRVxBawEnASlI4WEpLS+hSyhBfSElESEhJSEtFX0lKYXtC7FLP UFlRNVBcUs8QW1NKSUlTUUtISHV47FLPUE9RNVB+Us/idVtM7FLKUHtRUFBhUsrjcvxlVuxSylBF UVBQX1LKEFlwUFFQJWQHCkh7QKYNvaS9QKa9pL1Qb72tvUBsQGxvbEBsQL2tvVFBQmlpQUJpadd+ ey1AlGFgSBMpEAJRY3lOe09QY3BhT1F9dntPUH90YU9RXVJfT1BHVEVPUUFaX09QQ1hFT1F6TXhP UWJxeE9RfHd+T1Bgc35PUF5RXE9RRlVcT1FAW0JPUERXQk9QUHt7e3t7e3t7UXt7e3t7e3t70VEN Q2RmY2JGRURWc3J2UXJWRURGY2JmZWR2U1FjUVFkZmNiRkVEVnNydlFyVkVERmNiZmVkdifOxtrl 59bV4VFpEwkKEhQJChJTcsKssVG1zsfa5efX1eFRahQJChIVCQpUCs2Mle/qmZZRlSTL3SMkyt4j qiNWWamnUd7Oi5Xv6pmXUZQky9wkJMreI1BTUAivjlV3VYNQT1B8UGZRbRCYKkUiRiJHKn4qf9ZG 9n+NUFjGTfNGUtl/02ZS00zUcVLkRlEwRzFxUkZFEEY6UFP6TopGUiNMI01SJUoiS1IlUCtGUtpH 00tS+UX+RlLTTtpwUtpa00xSm3CWd1KdRpJLUupKlkRSOWbqRlI5RzVjUjV/UQZjDGZSFmMKT1Id RhJLUmBKaU9Sdkt0cFJQfX1OfX5aWlBLRkZNRXBGRnBw6lp9RFpafXZ5QFFkeU5qU1tL1k1zDjBD IEPwQ1N/QxBDUkOMTd9IUUjoUgoQTEluTiJwTVFNaGh5DvBdUV3wYQ5wV1FXOmchyEh7QKYNvaQN vUCkDbSkvQ1ApA0NvUC0UG+0vW+9115+e14tQJRXXmzXXkCUV15AbGzXXkCUYWBRDQ0NDQ0NDQ0N DQ0NDQ0NDQ0NDVANDQ0NDQ0NdVZWc3J3dmVkZmd2dmVkZmNiRkVEVVFmZ0dWV0ZHV3ZRZmZlZHZz clZFREZHUVFWVkVERmNiZlOdCYIqsdQ7//4zEp/Nxu+uu1FXfUnrYAI10Ck9rk4lFQ8XGTFzc1Ed rubCNt7SAf39MzPILMnYiwMi3hLUk+jRgcSu4QgkeJAs1gvfFlPVFThvGw8OFHIbeq1lUckHxRkJ kDVQUVAKU+NRd1XqUFVQdhBFUFVTUVW+UlBT0XBRwFFSUTpWIfdIe0CmDb1Qb71RQUJpaWFgQ1Nl Y0VT2H6dYFPjUUKlpa6+UFFQLK4BUjBVg1BAUG0QWndfUVBAQldYQEDoUWPjUM9eWOhRYxBBV89e DlBTQFNwU1NT/EHN3Eh7QKYNraa9QKa9UG9sb2xhYFENUXZSQWRnZmdjVldWV1ZFQFFRj8WeHQrs 0Sl3bXN7UXuuAexRqFFevoqtq4AJ2sbr7a5PrnBQUVAbrgFSf1WDUEBQbRBceFJ4QFJZWkBRUEJZ 6FFj41rPU1HoUWMQX1DPUw5fXk9eUl78Qs3cSHtApg2tpr1Apr1Qb2xvbGFgUQ1Dc1BBZHd2d3Z3 Y0ZHRkVAUpzRUXt7cm13KtHsCh2frgFRsFGx7OnG2gqCq62Kvq6irlhQUVAQUzNShVWDUEhQ1hAa W1FbWktRS1pUWllcXl9AQVdWW1FSSEZFRENXUFRTWEdCXVdXVlVIR0ZFQ0JBQF9dXFtEVFdTWFFa VlVbUFBAcERRRO9WVVBb9VboUcUQXVX1UBBBQ2RQSUkg3Eh7HkCkex2krbRQb2ytDWxpf2xCR2lC R2lRQUJHaUJHaUFCR2lhYFANQ2dGR3Z3Y1ZXZmdHVldGR1d2d1ZXd2ZndhB+zxhDUcFTRDfVfi8q bT8oah8aaCYkYtFU/d5oeeUUM8VkfN56XmXYBR/Y3RoF335JUFBRUCJQvVRqVOZQW1BoEE9QPllS qVhTPlVXVlk+WlRaqVVRPm9SH1JSUklcBwpIex5ApA0dpGy9bEC0bGxQf6RsrWykYWB1QXFlcUFj QXFFcUFSUa4hUd/6Ud+uIb1RwvhR364h+K4+UFFQ+q6OUdNQnVBaUB7lWlNQV/tW6FEAEHZRU2xS UlFaUWxQWlJTUVNsUFZoV2ofUA9QP1AvUPBQVVDwW/HISHtApA2ktEC9bEBsUG+9bEBsQL1Arb1R QUJpYWBjZWNFRFZXd2ZmZ+adAAdiaWZTnZ0h23YdSTELUFFQEVHoUjpSPVBTUHwQSSBSIFNSHVEd UlJRc1BSSlUgUFFQSVQg3Uh7HkC0DUC2UH8dvWFgUCFRDUNlcUURUnlR6OXlUFBRUOpQUFHXUJ1Q U1B1EEhSbFBaUmwPUD9QL1D/UFTwUFFQ8FTxyEh7QKYNDb1Qb71hYGNlY0XqnZ2dUFBRUFCvt1Jp VYNQU1AD6VBTr47iRGlS6K+OEHBEacdTUVJTz1P/U1JTJlBRRFBQUVJRUFNQWlO4UFK4UehR+eVQ UFTjKkh7QGxApL1AvVBvbG9s11V+ew0tQJRhYFENe3tFUWNRUfnArghJVbyqRFBQUlAFr7dUQVWQ UEBQTVDl5FZwSUBM6K+g4lJwW+6vsFBGr7BQQq+wUF+vsBAyVFbXUthb2F+ZXlVZV1tIUhVDHEUa SRNLBEMMRQxJAks7VztbM0M8RTtJMEspUidWJlsqX9dWyFfGQJlIilKGVoZbi19KSk5UVUROXV1H I1kQcXNkYFlRUFlAWVJZwE9BI1Dor5AQXnFzZHBQEFBSUMBOl9tIe0CmDXu9QKYNIXu9UG+9b71h YFENIVANUGhoaGhoUWhoaENAQmZjYkZGQkVAUlZzcnd2Q0BGY2JmQUB2c3JXVgU7g/Am4iQSOoPx hCnB6fksLPn5LiwaDVKDUVRRbfwP466viq6urpP9yOdRza7Hv6BROFE6vjnWUFBRUI9QUFKrVZBQ WlAjEHBTEF1BZDtUL1LfUslYVPxUUVlQVlVSU1lVUVxSUZpaUOivkBBCcXNkYFBRcFBRUEpcVRBd X2RV6K+QEF5xc2RgVVFwVRBVUlVJW+pRbFHVUEh7HkC0DSF7e0CmDSF7bB2tbFBvb0dpUUFpYWBR DVANe3FzQVZWV2VmZmdjUqvkEYMEx7J/JFQrbixP/heaD1BQUVBsUFBUV1WQUE5QtxBma1VrVutV 71brV5dYmUxXGVwJXAReO1w0XipCKkPZQuxCtUq1S6BKXO9b50NSS0BMQE1ATkBW7q+gUFevsFBY r6BQWa+gEEpOWkBYVlaaTEpETExKWExKU1FSWEpMU11OQOhS9OMfQVFB6FFI5V1ORFVQTuhS6xBf UVJcWiNHg1BQURBxc2RR61LRUHBQQFFoEFxB5W9SD1I/Ui9SVFLqUnRQT1Hf4dtIe0CmDaS9QKZ7 bECkvVBvbK1sb72tDbRBQkdpUUFCR2nXXn57Xi1AlFFBQmlhYFBoaGhoUWhoaGhQDVENInVFcXZn ZmZnZmZlZHZzclZXd2ZmY2JGRURWVldWVldUV6xnUkd188q/+Mkr0sxR6UOogYOmGPeS8gxO/f0R bDOQLpS1NjvDzNpDn4m6/Qj67PTYMWFQUVAGr7ZURlWQUHtQgxB4VV1GXRVd1l1UFUEHQSZLUwJG PEA6RDRGJV0pRNZd2kTZS/VdWlVwU+ivsBBbW1xdXlRXUXNdXFHoUvTjEFBRUOtRSFB5UF1RZeRc XEVUSOpS9FBJUjgQdEVOTFVUTnldQiMPcD9wUnDQVyN2EHFzZGB2UVB2QHZSdsB9SOhRaOJJg1Hq UWhQUK+QEFtxc2RwUBBQUlDAfOhRwuHbSHtApg17vaS9QKYNIXu9pA29UG+9b72ttEFCaX+9QK0N tEFCaVFBQkdpYWBRaGhRDVANUSFDZ0ZGY2JmZWR2c3JXZ0ZjYmZlZHZzclZXd2ZmY2JGRkVEVldG RkVEUHNydgbkT8U7L//yLWMcREJbI+jWOjncRORxuv4omjs2NNLArriGka9R00jJ1+DSLPFEzlIo LTPS1NRw5Zc34jQPzH5O7d6QrqW2UFJQSlBQVEBV6lBaUF1QpBBmQghcOFzKXPlcmVxVHFMcXcRU U0JRUlhQXFZTV1VaW1NXUFxcXV2aU1REU1NUU11QUlxdVFdT61LrUFhQUlHwEFpQVFRQXFxQmlpU 6FI251VVWhBNT2Ra6FFnEF1XEHJzZFfQcWVXwF9S6K+QEF1dRGRQUkBScFJTUuVe6FHc4dtIe0C8 DXtApnt7pHtsQLZArWxQb29ApGymbEFpaVFBQmlp1357VC1AlF9fX2FgURMMCOlQXa+O4kJpXeiv hBBbY2lTcn1pU1RNTWx7e3t7CQ1QDRMMCBBEXBBbaVzQAGlcEHZpXHJMaVwQfWl7e3t7ewlxQXFl UWNBY0VzQVNBUVLGrdRSzcOWluSuZVEP9VPmrBr1rvFSVFLFrTtQUVAFr7dUcVX2UE5QuhBNG0op TdpNxkP3Q5NchlyLS1hZQ0heekpTWWBVYFvqr7BQU6+wEEBDWkVCQ0OaXl9EXkNEXl9d6FL0EENe Wk5FEF7wXlJeXl8QRVFFRUxC6FLr519UUYMQUFFQ6FFIEHNUTkxdQQ9AP0AvQN9AVEDQVyNIEHFz ZGBIUVBIQEhSSMBwQuxRZVBfUcVQXVFo4l7lUepRaFBQr5AQW3FzZHBQEFBSUMBP6FHC4dtIe0Cm DXu9pL2kvUCmDSF7vaQNbFBvva0NtG+9Qml/DUFpfw1AvUC011h+e1UtQJRQQUJpYWBRaGhoaFEh DUNnRkZjYmZlZHZzclZXd0NxRXFTZmNiUEVEV1ZzcnYF7UXJPNLk/dwH3Hj53lKJrecf1MGQUVgk 3aSYrVHQQNrblPLK4h9vRlKh/K4mDK6mgZfB4rBQUFJQHa+3VEVVkFBNUHpQ4hB3O0lRFFcQRRRJ FHAKQgRwO1M0VzRYOkI0cCRYJUzVWNZMhliERkFX6K+w5Hdwc3Bx6K+wEEF4ThBdAF1SXV1ES1GD D1BRUOhSOBBZVU5LVXJORF1R6FFoEEVQ5XUjQBBxc2RgQFFQQEBAUkDAfFrqUWhQTlFpEFpvRw9H P0cvR1RH6FJ043uX20h7QKYNvb1Apg0he72kvVBvvW+9rQ20QUJpfw29YWBRaGhoaFENUA1RV3Z3 dnNyV1ZWV2ZmY2JCRURWVnNyUEFAZ2ZjYkZRREZGY2JmZWR2c3JWU6vjSHwZOwYRBTJSEew35K0n gNSxrrTN2bj9ja1nH94eIvTyKyr6VANeOmAdYG6+jDMwrqeC2r0uURtRLFH5kfiSrI0N+gnozsj/ /1BQUVAxUFBURlX3UF1QIBBelF1RVF1RVFJYVFlTXVDoUusQYFJRVFlcXSNTU1IQcXNkH1IPUj9S U1JKX1gjWbtQH1EPUQ9SU29RD1E/US9RVFFJXuhRwuHbSHseQKQNIWwdpL0eQKYhe2wdQL1Qb29s rWxpQWlRQUJpYWBRIQ1DZXFFVlBTVldzZkJCZzFT5dyuvRtmX+lT0qPZVKr93MWuQq6r6Iv9UbpR l8xQUFNQA6+3VElVkFBHUHNQYFCPEGdlRlF5RhlGGXa2XLlgVVlgUS1QLVEsVCRYIVsiXCVdKkfb UNpR3FTWWNFb1FzWXd1HnEGWQ0Jy6K+w4kxwSuivsOJwcH/or7DifXB26K+wEE55cFxQTkhQXEtO fvB+UX5CcU5WVXhOQl1OI+9ZUVnoUjcQQHsjXxBwc2RgX1FQX0BfUl/oUcHmYkgj4FNRU+hSN+J0 I0Xor5AQXnFzZHBFEEVSRcBhl9tIe0CmDXu9pA29QKQNIXu9pA29UG+9b71CaQ1/vWlpUUFCaWlh YFFoaGhoaGhoaFENIiFQIVF2dmVkZmNiRkVEVldGRkVEUHNyUGVkZkNERmNiZmVkdnNyVlNERkZj YmZlZHZzclZROiA8tu+Qujs9192upomJrqbBMtY7ONXZNjfYahnAA9H4/dIv91NLecg68IqP8DbH eXyU2OyvUFFRkN+RUQQ41NMPM9fUrK8dwB/20NL6+FBSUAWvt1RJVZBQTlB6UO4QZGpKHEYQcwtG B3M2UzxGPUo3cypKLU7cSttOykb5SuxKuka2cKZwQ21Gzkb9RlNqeTRWUnfqr7BQc6+wEEhxcFZw eE4fXg9eUl5eTHJORFVRgwBQUVDoUjjkVE5MXU/qUWlQW1FoEEFIEHFzZGBIUVBIQEhSSMB8UehR aORQ5XUjQeivkBBecXNkcEEQQVJBwHuX20h7QKYNe72kvUCmDSF7vb1Qb72tDbRvvUJpfw29YWBR aGhoaFANIVENQ2dGRmNiblJlZHdWVnNyUmVkUGNiRkJBQFJWc3J2UWR2c3JWRURGY2JmIP1GLDED LQBmUWbrPeasUVeW370rKqHy/IpSm/UkKOL5LC3xUQNAKj4cL4ggXEgGO1FYiI9RQMqus66irreu 4/7vU2TL5pTM3P//UFBSUOlQUFHWVHZQU1BXUGgQcFRVUFZXWVJWbFRTbFFWVFpSbH9Qb1BScFBR UPFY8chIe0CkDSG9UG9vvUC9UUFCaWlCaWlhYENlY0VTZWNF6Z2dnVMJnZ2s952dUFJQ+q6OUdNU dlBTUF5Q1RB/I1vTW8Nb81ugW1VQW1F2WmdaFloGWjVa5VqyWldbWl5XVFNsUVdsVlZVXlRb+1ro UQAQc1VsVFFWVFpS0VBQVVZXbFRaaFtqVX9Ub1RScFRRVPFf8chIe0CkDSFspLRArWxAbEC9UG9v QK2tvUBsQGxAvUC9UUFCaVBAmWFgUSFQIiFDZWNFU2VjRURWV3dmZmfmnZ2dAAdiaWZTUwmdnaz3 nZ0h23YdSTELUFBRUCBQslRrVJNQVlAKEFzfU9BVUlNVVlNYUlXrUgpQVlBTUgriUhBW6lEAUFJR ABBFUPtR+3BUUkpYVGxRcFBRUCVXBwpIe0CmDWy9HkCmUEl/Sh29vb29SEpAvUC9UUFCR2lhYFAN Q2VRRVFRRSBTm6yuU1JS0fhRyuOulK6R41BQUlAiUfFUalRWUFNQV1AXEHdVVlFUV1lQdVNRdVNS V3VUVFZ1YFJRz1KfUlJS71VQSllRSVgHCkh7HkC0QLZQfx29DSG9bEC9QGy9QL1RQWlpQWlpYWBR cWVxQXFlcVRqrGhTmKxoU5hTDvity/hQUFFQIFCyVGtUk1BWUAoQXNBS31RSVFJRU1dVUutSClBR UFRSCuJVEFHqUQBQVVEAEEVQ+1b7cFNTbFZQSlhwVVFVJVcHCkh7QLYNHkCmbB29UEl/Sr29vb1I SkC9QL1RQUJHaWFgUA1RUWVRUWVRVGusZVNRrK9Tm1LRrjHjUW9RbOOuNlBQUlAKUFBUXFWDUE5Q clDUEH/cSttLUixKLEtSMko1S1I7XDFeUgpcBF5SZl4UXlJLSVhXVFBAd0FBUF15RFFOUOhS/xBz cXJxbE9aT2xycnBscXFOUA5OPloORzp0QA5wQVFBOnMHCkh7QKYNvUCmvaS9QGxAvWxArVBvvWxA pmxvvUJpf7RBR2lhYFENDQ0NUA0NUXZlZGdmZ25SZWR2c3JWV3dmZmNiVEVEVldeUldTZWNFUYhR TkZhdOto9CcjykjpSaebh1FQCtMIZkpS6J1ROXRCOh1qa3v1Mmo5z8DJRp2KuvYw8iQeGjA8rsed nVBSUD+uAVeFVYVQF1AHUKcQB1RxQHBGcXF1ZV1jXhVeGUgUcRZ0FhkXBgReKnleRnV5UXZZek12 eWVKZmkTdQZICU0LcQZ5BhkJBjVINXU2eSZKKk0idNVI1ErcTdtx13ZJXkAAXlBTA+hS6xBaX3dg WwBbUltXRutSGFATUBtS6+QTalNaT+hS6+dqUXB7IHtSe+pRHVB3Uuvmfxh0X1dRV+hS0xBfQABu UHRC8F90YEAgQFJA6lH5UEtSzuRvaHp0e+pRWVBzUs4QWXBlUWVJCAfcSHseQKQNHb2tvaS9pA29 pK20QK0NvVB/vb0Nb71vtL1AvW8NtL1CaWlRQUJpYWBQDVENdVZWc3J2dmVkQmZjYkZHZ2NTVkVE RmNiZ2ZCZWRSdHNyVFJFREJUY3B0Z2NWVlRzcnR0d3ZlZGdCUHFiVEdGRUBXVnNydnd2UURGY2Ju UmVkdnNyXlJU2RHxAQn4OfOiIgfOaXLjwE55TWUGItX7rv2duq4thYVRw6VRVlEyCOVjqK76oY6u 2a6oEwQ0KlGRURCoUdsiMZzmiBUFRF2uRtIEaCwhGNcxECE6EPMbCziI0c9Rb/ALDcutMdxfS3dt AFFd3/dRcv6Lrje6pa7O+eAuOYovIrXF7YukjVFfUXCbmf2bro6xmnp3SVEc2cgT1Js22MYRwJ5Q UFKvrVBQVQlV6lBXUF5RThAzf0BgQDdYOFkwQNhTwECZVZZWkECgQFtYVQlRBlIAQDhb4ECjXKNd o15ZVFxUXVReU1taWVVUVFxdXlhWV1dcWVVUWFZcV1FQUHBXXERXV1xSU1NwVFxEVFRcWU5VVVhO VlNW6FIgEFlQWFy5EFJRUlLqUVtQUVFbEEJccFA1V1MCAFSfVI9UU8BUUVToUVEQWwBckFePXFPA XFFc6FFREEBfV59XUi9X0FdSV8NfhodIe0CkDSFJpA0hpA0hSL1AvUpJQL29UEhvbEq9b7RsQL1s QL3XVX57LUCU135Iey1AlFFBQmlpQWlp10CUlF6UlNdVQJSUXpSUYWBRG+BbAxvgTgEKCORUX1NY V+qvoFBQr6hoaGhoCVEiIQ1zUWNRc1NxU0NxU3Z3VldTUmOBUgiN+63L8YlRockWckxjVeqqFlHs rhRSClHG6Sfd21BTUMZQUFS5VepQQVBNUHpQ0RAAVFQWcwZzNnMjWdRZVjlKJVUgWSNb01XTW1Z3 RllTSHd6TkZNWVlDQk56enl5UExNTlJRUk9OTkFQWEh2VgR1dlxKfE1OcFFwUFFQDXtrDEh7QKYN bK1sHkCmHb2kvVBvbK1sb2ytbEJpf2xArWxpf0FpQUJpUUJHaWFgUQ1QDWNBcWJGRkVEVldGRkVE XlJzUXFiZ2ZmZWR2dnNxQXFiZ25SZWR2dnNxxlJ2+JsjNjfV3wfQkdyuw1Ft0WgaGxbSzq6LUT0O dhMKagTF3K79VeoJ6TUO9mN37NA34TBhUwJBRjYdGT95q/BXXGg7FgIpYVBQUVA2r7dVJlWDUE1Q 6BAwM1I6TVJwUGJdM1AgUCRN0FDUTcBQylX7U/Vd6VPkXZddgFC0TaNNQV5CTUFNTVN6VnhBekxw TxddBkQHRQZJOFU7TStC20LKU8leykz4UfRS+EGFXkNQRFBKQERASlRS6K+O4nhpUeivkBB3eGlA X1BRVEtDTlxTS05UWUB2XxpQdnBRUVFKT0d2cFhRWElOMwxIex5ApA0dvR5Apg0dvaS9UG+9b71B R2lhYFF7ew0NIVANUSJRR1ZUc3J0UmVkQnRjYlRHV3Z2c3JWUkVEQkZjYmZU5JJtrpO1va6Hy/9R E5KMUXxr72OSw/mzDD221vOyUlJhv6uRUT6CtVEF4bCbffDC8q6/weuuudrsUFJQzlBQVQpV6lBf UE1Q1BB2cE9RE1hMTU5SUVJBQE5fUFhHdnBZUVlKT01AcFFwUFFQDU5rDEh7QKYNbK1sQKYNvVBv bK1sb2ytbGFgEykQZlNLV1hWWFVYVFhUVklISkhSVltaXFpdWlNWRUZERkNGU1ZLU0dxUUJeR3FR SFhMcVFGWkFxUHt7UXt7enp6etFRDWNBcWJHRkdGQkVEUl5Sc3VxYmZnZmZlZHZ3dnNxzlGp+wou CSQjHirBndWu4VFpwfVhFR3HPB79rpxV6kVNHDKun5T3rq75MWL9ZmEVufa2p3pOUFBRUPJQUFS4 VepQW1ALEEVWVU5YWFdXUFNUTlJRUlpZTltQWFfor5AQTEBCZFcEUxpwWnBdUlpKXVRZcFFwUFFQ DVxrC0h7HkCkDWwdrWweQKYNHaS0e1BvbK1sb2ytbEJpf2xArWxhYGNBcUVxQXFFcUFxRfJUdKzO U3ushVPUVer9rm/8rl39UFBRUPhQUFTVVepQWVAbEHpWVU5YWN9XUVdXUFNUTlJRUlBYV8xwUnBb UlJKW1RZcFFwUFFQDVprDEh7HkCkDWwdrWweQKYNHbRQb29srWxCaX8NbECtbGFgY0FxRXFBcUVx QfhTjay1UuCtAFXq/a5q/a02UFFQPa+3VelVg1B1UIgQFUtES0VSMHdRDlhDUUJTdHRQcUJHUnVQ TlJRUVZHTl5TcU5WWVFRdnd1dHBTU3BScHcwUlNSItB3UXdNdnBaUVpJdjMLSHseQKQNHb0dQA2m DWwdQK1sQUJpf1BvvW+9Qml/bK1sQUJpQUJpUUFCaUJpYWATKRAUVHNLTEpMSUxTVlx2QHVFdk92 WHVUdnN1SF1NcVBGX0NxUUFCRENwV01xUHJVdXFRTFtHcVFEQUdxUU5ZcXFQdFNxcVBQe3t7e1F7 e0BsQGx7e3t7e3t7e3t60VENUA1RZXVBVlRzcnRSZWRCdGNiVEZHV35Sc3JWVldWRURCVGNiZmdB UxxSPd+ugPCIrs/k41EAi89RUcJ2/3Ey5j/VkidxaNdRUsEuoG5Sb/xRrbAiI+lRDoiGUSPkN+jE YCDQHQHUH9jPlK6o0DFnUUFQUFFQ8VBQVU9V6lBbUDjpUF2vkBB3Q0VkVFNOWVrwWoBaUlpVUlJb WFhVWHBXV1YN0F1RXVJbcFFwUFFQ6K+QEEVDRWRQDVxwXVFwXQBdMF0gXVRrCUh7DSFApnsNbK1s QA2mbECtbFBvbG9saQ1/bK1sYWBRe2NBY0FxQWNBc0FxQfGSUqqSkq1WVeqt9lIKqhZS460dUFFQ 71BQUdFV6lBTUMTlUVJQWFJV6K+Q42htZFXor5DjY2RkVeivkON9YGRV6K+Q43h5ZFXor5Djc3Vk VeivkONNTmRV6K+Q40hKZFXor5AQf11AZHBVwFX/VVNTcFFQUN9Q8FDgUFR/UBBQAFCPUKBQVUJw UN9QwFBTUPJUhglIe0CmDRMMCOLQUFFRDQkhImytDXt7e3t7e3t7bFBvb2FgY0FjQe+SVeqqFlBR UGevt1MxVepQQVAdEEA1UjdWJFIlVthd2EFWWVJR6FFKEHFUTl9ZWXZaWlh2Ww1wQ1FwQxBDAEMw Q1RDUXZQG0LmCUh7QKa9QA0hpr1sQL1Qb729b2FgUA1DZ0ZGY2JmZmVBY0FEVlZzcnZr/1cgMxk6 eJIJkdKRnVHwSPgsEyMuU6KsSeiaOo5QUFFQxlBQVQJV6lBbUdUQYVNyZ2lYWWp3WmVWZloXWgdT 1lOHU1cmWolTiVpTeFXcVNpV+lS6WFVaVFFlVIZUUlnor7AQWUJxZFNwQnFkU+ivjuNcaUJZ6K+w 40JxZFjor7DjQnFkVOivsONNcWRU6K+Q40JGZFjor44QbUlpWFl1dW1YWUlJbVZWV1laWVhaVVNU VHBVWkRVVVpZWFhwV1ZEV1dWWlpQVVJUUVJXW1hQWFpTUltRUFToUmoQX2BVUfBV4FWQVbBVVFUa WOhSahBbYFdRcFfQV+BXU1foUtYQW1twcFBRUA1ca/hIe0CkDb2tDSG9pA0hvUBsQGxsbFBvbGxs b2xsbEJpf9dVfnteLUCU11V+SHtULUCUV1hAbFhsURvgSAMb4EsBCgjpUFSviGgJYWBRe3t7e3t7 exMMCBBBWXJJaVh8SWlUfElpVHJLaVXor47mRmlUckZpVuivjhBbQmlYckRpVBBEaVjor47ldWlU EEVpe3t7e3t7e3t7e3sJUHt7e1EhIg1QIQ17e2NBY0FRcVFRcVFXQcaSUohRV63JUtKvUK2moFXq rXlSh63+rMhStrquVFBQUVDGUFBUelXqUFVQYxBcUVJUU05VUFhwVFFU6FL3EF5XUlNwUXBQUVAN VmsMSHtApg1srWxAtg1Qb2ytbG9hYGNBY0FxRcaSUoJV6qqj/VBRUMhQUFZfVepQQFElEC9QUl9Y RFJLWFQmXNZcmFxTWVwZXBlfU3lUdV18XghTC1QmXShe111YW1JVWGldZl4fUhtTFFcQWB1dEl5a yFLJU8ZXxlj4U/dXVkJSX15eYFVSRFVVUlhcXV1gVVhEVVVYXAJfAlEQUVJSWFhZWltbXV1eXkBQ WFlSMELQQlJC6lL4UF1RYeJVcFjoUWEQWlxZWnAQXC9bUVvqUgZQXlFb4lVwUuhRWxBZX1FQcF8g QFFA6FIG53BVMFXQVVNV6FL440FrCUh7SUCkDaQNbEitbEC9SklAvaQNbEpIrWxAvUpJQL20DVBI b29sbEBsQGxAbEBsQGxAbEpAvb3XVX571y2U135Ie9ctlGFgUBvgWwMb4E4BCgjtUFyvq1BYr4ZQ Uq+GaGhoCVEb4FwDG+B4AQoI6VBdr6jhXlpoaAlREwwI6VBdr4TmcWlefHFpXeivhOZnaV5iZ2ld 6K+E5X1pXnx9aXt7e3t7ewkiIQ1QIQ1RDWNBcVFGR2ZnUXFBc0FRc1FByFF0UQtgRkllUQ9RVeuu Bv+uCFXqq6LBGADLU6yqFlSbq2VUsKtwUFBRUMxQUFVPVepQWVC64UJb6K+QEGVDRWRYUlNTcFdY RFdXWFJXU1NYWVRSUllXWFRTcFZWVQ1wW1FwWwBbMFsgW9BbVVtYWXBRUOivkBBcQ0VkcFBRUA1a awlIe0CmDXtsrWxADSGkbECtbFBvbG9sQmlpUUFpaddUfnvXLZRhYFF7EwwI5FgQFmlT6K+Q5hZp WBBiaVPor5DmYmlXcklpUuivjuZJaVdyYmlS6K+O5mJpV3JzaVLor44QW3NpV15EaVdeQ2lS6K+k 5kNpV15NaVLor6TmTWlXXkVpUuivqOFFaXt7e3t7e3tRe3t7e3t7UHt7e3sJY0FjUUFjQXNRQcyX U1Lql6yuVeqr0VQvqhZU0KvQUFJQM6+3VY1VhFBeUEtQLxAwSl9RREBEREtHS0tUVEBURFtHW0tU +UfmXpZeU0dHSEtScE0QQR9DH0cQSghVCFkHQAVBD0MKRw9IBkoHS9tHyVJASU5TU0JOW1lFdnBX UVdK0E1RTV92cFBRUElMMwxIex5ApA0dvR5ADaYNHb1Qb71vvWFgUQ0hUA0NDSFDQFBxYlRCRURS VHNydFJnQFBjYlBBZFJ2c3JQM1HYUWabURb75K7m75+u6viYUU2Hi1FLKbnBnq6HUppRPVHNkq71 jI+u8OWYUQrurqeun1FkUUvjUVvDrrVQUFJQzlBQVK1V6lBdUEhQBxBlNUE7RFIbQBtEC0ALRFRb XE5fXl5QR0hOUlFSUFhCdlhKcEpRcEpRSkhdcFFwUFFQDUlrDEh7QKYNbK1sHkAhDaYdvVBvb2yt bEJpf2ytbGFgUQ1QDWNBcWJHTlJFRFJxcUFBcWJmZWR2d3Zzcc5SecIdPMIJvq6ZrthRK+zODRxh 1K7ZVepeQjXmPeuura38U1HcLwzTRV1QUlAIr95VvlWEUEVQeFFCEMIPds92UklIZ0VSW0xUT1Rz S0xET0RzVnpVfUd7dmtVbEdqdhxVHEcZdg1VBXMIdj9VK1MqVdxT3FXFUMpT9FD7U4VQhUa1ULVH tUhKTFV7UHpVa1VUDVXCSMZ2hXZUdUZ6dmRGaXYZSBlMFU8Vcxt2BlgIQQVFCkwKTQZPB3AHcjlV NkU7dit23kzedotIjHZJReivhOJLaVDor4QQbUtpUlNGeFNXeHZIRlVQVnFTQ0pVUnh2SEZQVXRO Tl9TUlh0TldZSnZDGlJKcHrQelJ6cXZwW1FbSXkzDEh7HkCkDR29HkANph2kvVBvvW9vvUFHaUJp UUFCaUJHaVBBY0CZQJlhYFF7ew1QIiENUQ0hInVGR1d2d1ZzcnRSZWRCdGNiVEJFRFJ1RkdmQWRS dnNyUEFAUGNiZ3Z3VKXXImnOzfOVl67s/+BRFZmbURb7Pq22+D37KbnBia6yUUuMOAwLNc0Ne9dp KwuQUQyKiVE06pGu9Yrlro/dfw3MUWniUVrDroeuia6yrp53a0lQUlDxUFBV/VXqUEhQclEcEF9C W15RQmZMCk82WD1PVELor7LjQkpkQuivoONyd2RB6K+y4013ZEDor7LjTXdkX+ivsuNNd2RC6K+I 4012ZEHor7LjQkpkQOivsuNCSmRf6K+yECNCSmR1XhpMGnADWwxMPUwiWSheKV/VWthfx135X+hf uF63X0BeXFxwQV9EQUFfQV9cWUJLUnFKRlpWQkFAXVxVSFlZRkdKSU5HR1Bxck5SUVJQSEhfX15Y TnZezFYNcHQgdNB0U3RySHBRcFBRUA1za/hIex5ApA1sHa1sQA2mSbRIvVBvbEBsQGxvbK1sQml/ rWxAbGl/QkdpUUFHaddefntVLUCUYWBRDXt7e3t7e3t7e1ANEwwIEFpYEF9pX0BqQUJqe3t7CVEh EwwI6VBer44QSklpQXJJaUJySWleEExpQHJEaUByT2lAckVpe3t7e3t7ewljQXFiRkZFRFZXRkdG R0NzU35Sd3Zzc0FBcWJmZmVkdnNx8VLalJwqmoMdeAUcr6SSBT4HfXEbsVHx1cYex/OuYFXqH5gp zIZNdXQeJa4hUWHU3GhbV60lU2NnKRc41lBQUVAMr7dUu1WDUGBQrhDMM1MzVCNTJFRUdXdlU2lM E1MZVxxNFU8UdBZ3A1MJVwxNB3jZQ154XXZ0UnRTd3VmX2RzFHUVfwpwBnMFdTxbOl07XjZENUgp WypdKl8tQCV0I3XWU9pb2V3aX91A1XTTdcJdxl/GRU51dF5dW1VxTE1OS1hXVlRTUlZRdXRyXl1b VlVOS33fSlFKvUZQfUBRcFEAUTBRIFHAUVZR6FHgEHV9Tk5GU1VOfVlLdkoaWXZQeVF5SmJxdkJR dkIEcFBRUElhMwtIex5ApA0dtL1AvR5Apg0dvaS9UG+9b71ArQ20QK0NpEFCR2lBR2lBQmlpUUJH aWFgUA0hUQ0hQ2dOUmNiZmZlZHZ3dnR3dnZlZGZmY2JGRkdXdnZzclZFREdGVEdGRkVEVlZzcnR2 DOddD5gtP/oDAAxrrjwBOTcuosTzqdZV6l/9+eDxaWhRiQjQKtarzZeuo8lRh0A+3QcSIxQVN3NH MXtn8zU/kTQ5nNFe297RCx9jYzt4a+UmJZ8jJLlQUVBgUFBU6lXqUFdQHxBdVVJOVFNSUFhXVlVU WehSI+NwVFFU6FFR51ZwUVJ/U1FT6FFR5VFRcFBRUOhSI+NY5slIe0CmDWxApA1sQK20DbZAbEBs UG9vbK1sYWBxQXFlcUVxQVJDrk1U2q5LVV39/aqjUFBRUPGvt1VyVepQRFAhEFp2XwhUCFiZWFRG 6K+QEEZDRWRkVGtYFlQaWCZf9lW4X1dcUFJB6FLrEExWWUR2Ug1wRlFwRgBGUjBGIEbQRlNGXXZw WlFa6K+QEFlDRWRaDUVrCUh7HkCkew29HUANDSGmHb1Qb71vbGFgUQ17UA1RY0FEUlRzcnRSZUFj QURGRmNiZkFUMJI0rquEnq6qIJIX/S2G5lXqrOGNrqzz3lFduVMfrOLv5TKSUURQUFFQWVBQVRZV 6lBaUKUQGH9VUXpQeFN1Wn9cYFwwXNlY2VnAXJBcoFxbcFwAXFJUUltYUlpZWXBYVURYWFVQUVFw UlVEUlJVWVFSVblwWlBYWTVYUTVSWOivkBBbeGkAWFHQWMBYUljoUVEQXVIQeGkPUlHfUs9SUlLo UVEQQXBVAFVSYFUwVcBVkFWgVVVV6FLY41sw+Eh7SUCkDSG0DSF7tA0he0hAvUC9UG9sSkm9SG9s 11V+ey1AlNd+SHstQJRRG+BbAxvgRAEKCOJQX1ror6HiWUJR6K+h4lhEUuivvmhoaGhoaAlRG+B4 AxvgZgEKCOlQUK+QaAlhYFENIQ1QDXFRY1FGR2ZnUWNRUhGtmIJRLX5Pcn1R3JatklXqq4fQICgo VHmqFlBRUElQUFcmVepQSFHcEBR5UHZBeUJ2SGlQZkFpQmZIGVAXQRlCF0gIUAdBCEIHSEDIWMhf UlNUVVVSVldYWFVaW1xcWV1eX19cRENCQkVGR0hIReivbONVUEhw6K9s41xCQXDor2wQCkVYWXBQ VVJScFFQRFFRUEhVWFhORUhERUVIQlxZWU5FQkRFRUJBXF9fcEBBREBAQUJZXFhIRVVfQUBcUFJV RVxVU0hAX19ZWVhYUlJRUkhCQkFBUFhKR0dKQBFZUQFQcFBcUQFQRVEBUBBQVVEB5nBwUVFRSUno Udvh+Eh7HkCkDUpJHa1KSK2tSkmtSB4VNRS2UG9sQGxAbG9sQGxAbEBsQGxCR2lRQmlpQUJpaUFC aWlBaWnXHX571y2U135Ie9ctlNd+SHvXLZTXfkh71y2Ue3t7115AlJTXXkBslNdeQJSU115AlJTX XkCUlNdeQJSUURvgXwMb4EEBCgjiQlpI6K+maGgJURvgdQMb4HoBCgjpUFCvkGgJUBvgWwMb4F4B CgjjXBBVEGhoCWFgUSINcVFjQ0ZHZmdRY0NCR2ZnQ2NRc1F2d1ZXUVHOriuXj3RKaFpRR7qCH3NM fbaTrj7rrpt3V0dErplV6qxvx8W7dFOOrUquvKPb5FP+qhZUDdxwNRer81BQUVBZUFBVGVXqUENS BxB5dkJRSVFGW1J5QnlDaFFnU2hYaFloXWpeZUJnQ1pCQ3BCcWRCcEJxZF7or7DjQnFkXeivsONC cWRZ6K+w40JxZFjor7AQmEJxZFRwQnFkU3BCcWQnUSdbUnZUeVd4W3pedkJmVGpYaltqXmVCGFgE VA1YDFsKXgRCN1E1VDpYO1s5XjVCJVQqWClbKl0nQidD1lTaV9paxVToWOdCllSZWIdUiFiJXoZC t1S4WLhetkJ8VldYWVlRVlVUU1NbQEBDX15dXVFAQF1BQkNDW1FQWVJdW1NcQ1pbUVZAUkNZWkND cFBZRFBQWVNSXV1wXFNEXFxTWllZU1NSUkNdXVxcUFh/RVFFR0dKcFwQXFJc6FEP53BawFqQWlNa 6FHo5Q9Sz1JSUuhR6BBaVuQQQABAn0BTQOhRDxBacFBJREWScTD4SHt7HqRKSR2tDUi1Sb0NvQ2t DUgeFTUUtg1Qb2xAbEBsb2xAbEBs11UdfnvXLZTXfkh71y2UUEFCaWlpaV9f115AbGxYlNdeQGxs WJTXXkBsbJTXXkCUlJRhYFENUA1Re3t7e3t7e3sTDAjpUFuvjhBbSWlRcklpXkhLaULor47iS2lD 6K+O4ktpVOivuOZLaVhyS2lZ6K+Q4kxpXeivkBBPTGlDEExpUxBMaV1eRkdsQ0JGR21YWUZHbFNU RkdtW+ivjhB+QmlRckJpW1xNcW1RUE1xbFtaTXFtUVJNcWxbXENHbVFQQ0dsW1pDR21RUkNHbHt7 e3t7e3t7e3t7e3t7UXt7e3t7e3t7e3t7CVEhUQ0hY1FRY1FGR2ZnUWNRUXNRdndWV1FZUmeuXLdR WgNzYRNRd4OtrVJ7oK7fT3FhRa7AUqxS7q7YJW8AB1HVrR2sqVJbfWUATq5RUFBRUFZQUFUWVepQ XFFk5lhZalNUa1nor7fjQkdkWOivtxBeQkdkVElCR2RTSUJHZFnor4jjSHFkWOiviBAWSHFkVHhI cWRCdlR5WHpaf15UOFE4VjhbjlZUVVRTU1ZYV1lWVllWU1lwWltEWlpbVlNWWVNwUlFEUlJRVlxb VlFTUlBRW+hSSRBZWlpZU1JSUFhe6FJIEFlcWQIQWtBaUlroUeUQXVtbXHBQUwIfUt9SUlLoUeXi UVFQ6FJI5l1eknEw+Eh7e6ZsQKQNvUCtbECkDb1AtlBvb2xsbECkbEFCR2lRQmnXfntYLUCUVdd+ SHtYLUCU116UlNdAXpSUG+BHAxvgTAEKCORYXFlcVOqvpFBTr6RRaGhoaAlhYFANUQ0TDAgQWVly SWlYcklpVOivjuFJaXt7ewl7e3t7e3t7e3txQVFjUUZHZmdRY1FBUmutm7xRcQAVEg5RTLKt51I9 Ux2uFiwsI8BR/6zjrcNQUFFQeVBQVOBV6lBcULbhQl7or5AQal1BZBhRF1gYWVNaWFtZUvtUUVNS UVFUWVpUWFpadk1xZHhaUalaUVpwUVREUVFUWnhbTGRReFtMZFjor4jjW0xkVOiviBBDW0xkUVpU WFVOV1ZSW1pOXFBYWutR5VBRUFRR5RBLUFdgWBBYUlgaXG9bUVtKXlFQVVYBUEld5slIex5ApB2k bEBsHkCmDWwdpCFsQLRArFBvbK1sb2ytbGxBaVF7e3t711V+ew0he9ctlF5AlNdeQJSUUSJhYFEh DXsTDAgQWVJycWlRSHFpWeivjuVJaVJySWl7e3t7CWNlUWZncWVxRVFXcUV5Ur8AGKyeVEqsmQlT +ORT+zQa/f2sVzf9UFFQ2645UkhV6lBXUGgQT1RTe1FSQFVWe1BXQlNSUldW/lRVdVFwUFFQ/FjN OEh7QKYNbK1spGxsQGxQb2ytbG9srWxhYENBcUVzQWNF21HdiYmuOVcBxamJxVBQUVBQr7dSaVWD UFNQHBB0UVFyRGlQckRpyFBRUVDAUPBQUlAmU1JEU1NSUlFQU1BaU7hQ6FH551K4UVFU4ypIe0Bs QL2kvVBvbG9s11V+ew0tQJRhYFENe3tVUWNRUfmuB8FR+ElVvKpEUFFQd645UeRV6lBXUGQQTFRV e1dWQFNSe1BRQlZVVVFS/lRTdVdQ/FnLCkh7QKRsrWykbGxAbFBvbK1sb2ytbGFgUXFlY0FzZXFR 5K4jiYlR3a45xVZ3xVBRUGZS4lPbVYNQVlAx6VBQr5AQRURpUBBEaXZSeVNSVlJZU1JVUVZsUehR NRBHUlVsVFBsUVZWU1JYaFSMUzxSjFE5V1jsUWJQcVHvUdFQSHt7pqSmpLRBQm1pf0hAvUC9UH+9 vUBsYWBRISF7e0NzUWNRc1O/6VExwVEz5adS4lNxrI9SBVBQUa+xrjlU2q67UFNQShBcUW9QUkpV UElUExFIex5AtEC2UH8dvWFgU2VxRU9U+a450tJQUFFQCVT6UYFVklBTUDAQW1NoR0lkUhBfQWRQ 6K+Q40dJZFPor5AQSkZJZABRAFNSEFMAUFJTUlBQUUBRUlHXUlBQ6FID4lHWU+hSMONSSVQh6VF/ UEh7HkCkHb2kvVBvrQ1sQGxhYFENDXt7e3tRc1NjUYHBt6FU+lFIUFBSUBqvuFRMVG5QeFBnUU0Q 3lldWXpJXUp6eV16emldZkVnS2p6GXoNXQ16Ol05ejBg2l3WecpGy0r5XUX2Sfp45knreJRJn3iC RY14WBRGUU9HT0h7fHpkaVRpfBlUGHwGWAl7Nlg5eyZc11yZXKldqXtBZ2ReUVRAf3RkR2JxREgP eT95UnlMf15vXt9ez16vXlXPXv9ev15TXl5MU0foUvoQRkjFRExMV1AVd1piTFNbeTFAMVB1cXTo UgsQQHcQUHZAdnB2YHb/dlV2YWnor5AQT05zZGBpkGlS8GlRaUd1SHJ/dO9Wn1ZST1ZvVlJWYWhA pg0hvaS9QA0he6YNvaRsrbW1UG+9b7Rvva20QUJpfw0hvSFBQmlBQmlpUUFCR2lhYFANUSENUCF1 VlZzcnZlZGZmZ2ZnZmdmZWR3dnNyVld3blJjYkZGR0ZFRURGR3N2U1ZXXlJFREZjYmZnZmVTbDTp Ov/sFyMYZTuKN1FjFdgvKU3gSD6A2dj6AEBZR3LsTEcylD8MYj05OPJ2TdMFFvvVHtEeRF5dSnR1 Wj59bQkhSCHbGxAxGn4ooKvVbWhRjXhMQHgdfxgwCx9tJ1BSUNavuFRPVepQQFBNUIYQ/FFVXF90 VWVVFVVVb0/gT1JPT3JMY0wSTCBPwE9WakNsRmxKHEYcSg1YDV0IXw1GDko6WDxdOF8+Rj5KkE+J XIpHikmyQ7xHvEmzTbBPr09JcFV/X39EYFVvXxBVHF8AVTZVik2lVKpAXEBFXlRWUlBLTFZXUVpF TF5bSHSAW1FAWxBbMFvQW1RbJFFBY1BjU3VSUpBRUcBR8FHgUaBRVE9Rb1EfUVNRSU4XZ0h7HkCk DSEibB1AraS0QK0NIb1Qb71vb71vQWlBQmlhYFANUQ0hIlAhcXNBY0FmY2JOUkVAUHNyd1NER0Zj YmZlZHZzclZRfffkIuEy/yEQrqLt7DtSZAXBJvz1JSb8Veqtpd8f35ojrr+uhs1Rxu8F252bgJad UFFQAK+4U71UblBKUJ0QF1lcUU9ME0MTRwNDA0cwQzBHy1LLU8pd9ED0SlxYXUlaOlI5UzpVJVwg XdBd9lzlWeZa5VxcRlzWXLNSU15yD18/Xy9fU19R6FL6EBlgUBBQAFAwUCBQwFDwULBQoFBZUF9f W1BQVEJMW1dITFRbTF9RX3RecktQUVB0W3tPUVFQUVFRGUxFdJ9XUU9Xb1dSV2FLZJRIe0CmDSG9 QKYNIhsDcxsBCgjpUFGvkGgJvSKkvSJQb71vvUJpf0Fpf0ANtEANtGFgUA0hUQ0hUUdWVnNyUEFk QmZjYkZHV3Z2c3JWRURGY2JmU2zhTb/+iq6nIrnZ/YxP/0kvCtj69NQ63lHVR+efUU1RWvxRUtH/ 8Us7PJODhpLSUFJQFq+4U49V6lBBUE1QhhD7WlJUXXVdZF0UXVVlRGVMB1IEWgJEA0w3UjRVNVkz RDBMkE+EVYVDjUm1Q7VEv0e7SbVNsE+vT0ZPT3tKbEZsShtKIE/AT1d+UnRdfkZqUmVdG1IVXRZE GUwHWgZdN121VrdGqlGkXkBRRVNeW0BfUEtMW1dBUFpFTFNbSGNRUHVBX3VAQIBBUUBBEEEwQdBB VEEkQnTvV59Xj1evV1RPV29XH1dTV0lOZABIex5ApA0hHb2tDSFsQL1ArWy0UG+9b2xvvW9sQWlB QmlhYFANUSENUCFxZVZzcnZ2ZWRCZmNiRkdBY0FRREZjYmZlZHZzclZTaDWUL4UlOoTTMMZ/461w /CUm9fgrKPHWztyr889RU9oBEVJeqhZSQpyakZaKnJRQUlAbr7hUTlRuUEVQTVCOEDRPUExFUgVT DVUNWQVbNVM7VT9ZNVtYQFBAUUBSd0KJVapEpkpXYUJqSWFMEUIdShFMAUIMSQJMMUI9SjFMKFYo RaZSpkhAUEZRX11HRwBGMEYgRlNGTF/AQPBAUkBAVEtMWldQ6FL6EFlRxUNMVFtHEF3or5AQWXd6 ZOBdUV1KT+ivkON1dmRP6K+QEE1Oc2RgT1FPRmNAdFcQdHpkT1dvVx9XU1dJTmRnSHseQKQNex2t tB5AIXt7piF7Hb1Qb72ttG+9Qml/DWytIWxRQUJpaUJpYWBRDVANUSEiUUdWVnNyUEFAUGNiUEFE V3FGRmNiZlFxdnd2c3JWUw7qfL7pua6/UUSMhVFeUay4WuLVM9ytilIBXGgG2Sz5UQZH8+RRT1FT UVxReK6OrqlAcP/qOFHF1hM49lBQUVBDUFBS0FWDUEdQ4xBORFlRX0l/SWBJEEkgSctczF35XVhK XXhd4EmQSVRJ6K+QEHhKT2RNWF1TXF9MWlFFUntEQ1RTVlBaz0RRRK9DEFRHdVRQU1LCUVFQ6K+Q 42FoZFDor5AQWkxPZMBQUVDzSEnsUepQcVCmUVpQSHt7pg17e2xApGxAbL1Avb0NUG9vbGxsrWxv vWlBaWFgEykQREBBVllXVlhWUlZAWUJLUEFWX0tRe1F7etHRUXshDVAiY0FzZWNlZGdmZmNiR1d2 c3JWRUVjRXNB4s/PQ0rTJhwMS2hiAhSfn1PK3CE7ZBYHQs1aFjAy3Kw2UFJQEq4BU7pUblBOUHpQ oBAwW1tVRHxbdUQcWxVEVllNSU18W3ZEfHNpW2ZEGlsWRAZXCFs4W6papUVefnN8d25zbnccd8B8 8HxXZnFmeW98FlsWcRV5BHEEeTlXM3EzeTB80HyKd7hxvnO/d0FHRlZF6FLh5HhMQ1dR6FL6EEBw UGBQMFAgUNBQkFCAUFdQ6FItEBFVTExfWhVyTFxaRkVjdWNadUhIgEdRQEcQRzBH0EdURyRfUXVQ ck9071+fX49fr19UT19vXx9fU19Je3wkcWQASHt7HqQNIR29pL1ArQ0hbECttKZsUG+9tG+9rQ20 b720b2xhYFENIVANIUdHRkdGY2JmZ2Z3VnNyUmVkQmZjYkdlY0FEVlZzcnZDREZjYmZlZHZzclY2 /1tiEyQt2EheUSbgi6A+gd3sKvY1i/Duusn2LSz4/Soo+AhKAXViNApn4NtRbI3IUVHcyNCsOqif KPtTeoGQ75yTlpNQUVDXUFBTuFXqUERQ4elQRq+QEF1FR2R1VGVTFVPqXVRT6K+wEHRHSWRHWEFc QURTVVFQX0xVV0RbWlx1WRBjZmSvWVGQWVFZHkbor5AQR2RmZOBGoEZSIEbwRuBGr0ZURlJEdVFQ 6K+QEEVjZmSgUFFQUHBQgFCwUFRQHkUXAEh7QKYNIXtsrWxADSF7pA0he71Qb2xvvW9BaUFpUUJp YWATKRBeVl5XdV5WXEtRXVhfS1FQe1F7e9FQew1Re2NBY0FmY2JGRkVBc0FkdnNyVlZFQdfkLpAm /hvkJTsA3WxV6q2iwg30zK0PUvHXKwPeLa3rUFJQ2FBQUWxV6lBTUFdQLRANH1nAWfBZ4FmQWY9Z oFlXUFlPWSBZ0FnPWeBZkFmPWbBZr1laT1lRUFFXVFJTWVZTLlFQVlVWVFpWV3VVUFTPVPBU4FSQ VLBUVpBUoFRSUFRwVIBUsFRUVB5YFwBIe0CmDSEibK1sUG9vbG+9UUFCaWlBQmlpYWBRDSIhQ2Vj RVNBY0HY5OTkVLufn6tFVHarilBQUq/yrgFRalXqUFNQQlDJEB1UVXVVa1RjVdZVVUdYVVVXVFRS VFVDUFFdW1JTRFxUQVVbV1MuUVBbVldMQV/ARFFER0dKXFxddVpawFtRT1tvWx9bU1tJQ0T9cRcA SHt7HqQNIWwdQK1sHkAVNRS2IVBvHb1vb71BQmlCaVFBQmlpQUJpaUFjY9dAWGxhYBMpEF5YQF92 WEBaS1FZXldLUFB7UXt70VENQ2VjRVFnRmNiZmVBY0FEV1ZzctbkrjhyZk9nZuRjEccZVLmBgakr yV4ZwlQMq/CUHTRQUFFQ2FBQU6hV6lBbUZwQSldWBlYKWVNfXaNVplZTBVMnWlJCVnBDcWRY6K+g 40J3ZFnor6DkQndkQlXor6DjQnFkWeivoBDUQndkVlRUVVRWZ1kXVFV1Vn1aCFonUyVailOzVlf2 VlFzVnZXdVhpVmhZb10fXQlUCVYIVwlZLVQpVclZllaCVIZWtFa5V6dWqVhFQlpaVVNTVFJWVldZ WVhaWlVZWFh1V1ZEV1dWU1RUdVVaRFVVWlpZVlNUWFFSUFRVVldYWFtbUFpU6FFf4lVyWOhRXxBz cFdvV1JXSsBdUV1bdVBSdVFRwFBRb1AfUFJQSVxdsXEXNkh7ex6kDSFsHUC9QL0eQCGmDR29pL1Q b2xAbEBsb2xvbEFHaddVfntULUCU11V+SHteLUCUV0BYbFhsU0BYbFhsYWBREwwIEFpZfE1pWVhN TWxW6K+O4k1pVuivhOJwaVbor4ThcWl7e3t7ewkNUCENUSFQe3sTDAjpUFavkOJxaVPor5DiRmlT 6K+O4kBpVuivjuJAaVPor47iXGlT6K+O4Vtpe3t7e3t7CVF7e3sTDAgQQo1UUVhERmlZWEREbFlY RERsVuivpuJIaVbor7zhS2l7e3t7e1ENCVANUQ0hY0FjQVFjUVFzUVdB2ORR+rmuOlHvjq7xL1Xq rOxR4K4mrTRSTyquC1BRUNNQUFFnVepQU1Dc6VBVr5DjZ2hkVeivkONkZWRV6K+Q42BhZFXor5Dj cnVkVeivkBB1RUdkX1VPVc9Vj1VUH1WPVaBVU09VIFXQVa9VVFFQUFpSU3VRUOivkONnaGRQ6K+Q EEpjZWTPUFGQUKBQUlBQcFCAULBQVFAeVBcASHtApg0hInt7bK1sUG9vYWBRDSEie3t7e3tjQWNB 0+RV6qoWUFFQ11BQVnZUblBzUJbpUFmviBARW11kdVS0VLRZsUe1cFWFVaZwUkdYcHNZSEtwWVNT c05MVkVMW1tWV1FWc0pJQFqAdVHAdfB1UnVHR0pedcBBUUHoUQ3lSHXAS1FL6FENEElQUmNzdVGA UFHAUPBQUk9Qb1AfUFNQSXR16FEo43EXAEh7ex6kDSEibB2ttECkDb2kDa0eFTUUtiEiUG9sbGxv b2wdQL1AvUFHaVFBQmlCaWFgEykQXlxEQ3ZEXEFLUUJdRUtRUHtRe3vRUQ1QDXtjQWNFZmZjYkZH ZmNiRkVBc0FkdnZzclZFQXNBZHZzclZWRUHX8WL2OibHTy6azvrjcwxuIMTkCDQc0WpUdsUeDzII 6v/mrXdSzTwPasX0rcdS4igoAMrBrYlQUVDXUFBTtlRuUEZQnBBDVVNWQ1L4QOhAs1O3Q6BTpkNW VOivoBBhW11kKUBRyECASLBIr0hUcFhEXkRGQkxVV1FWRl1aXV5cXnRbEGNmZK9bUa9bUVseSOiv kBBKZGZk4EigSFIgSPBI4EiQSFRIU1JjRUZ1UVDor5AQQmNmZKBQUVBQcFCAULBQVFAeR0CmDSF7 bK1spGxADSF7pg0he71sQGxQb2xvb71BaVFCaWFgEykQRlZBWVpYWldaU1ZAdkFWXktRX1pCS1FQ e1F7e3rRUQ0hUHsNIWNBY0VmY2JGRkdGRUFzQWR2dnNyVkVB1/IljTDxAEBa5Ho7GCP3VHbH/xUg HWItrSNS1j49EcKcrexQUlAUr7hUd1RuUF1QSVCREA1CV1pJXBdWGFgGVglYN1Y5WFhkQGpCakZl SBVAG0IbRhVIDFUMWQJADUINRgJIPVU9WTRAPUI9RjRIJ1FFWVZVXQtTBFUEWgtcPFM1VTVaPFxa R0xUV0FMW1tEdFfor5AQQ3R1ZGBXUVBXQFdwV1NXYY9LUUvor5AQSU5zZGBLUUtedFAQdHVkT1Bv UFJQYUpkZ0h7QKYNe71AIXsNpg0Ne71Qb71vvWFgUSENUCETDAgQWQNVA1kyVTJZVFENCUNAZ2Zj YlBFRFZWc3JQQ0RGY2JmZWR2c3JWFPTZlYtRRiu724+uveni19bi49XX4lJDUXfeJq6xrZ270lFO UV2cm5yBlZuaUFJQ1645VHFUblBCUE5QnxD1XEB9QG1AG0BUb3DgcFJPcHlcc01iRWJNEk0gcMBw WGpHaksaRxpLCVgLXAxHDEs6WDtcOUA9RztLkHCDRI1IjUqDTrREtE6wcK9wRnNUe0B7RWVUakAW VBpACkC1W7tNrkBbQV5TRkxMVldRVkZMXltQXkl0gFpRQFoQWjBa0FpUWiRRQ2NSY0J1UFCQUVHA UfBR4FGgUVRPUW9RH1FTUUlPF2dIUXseQKQNISJsHUCtpLRArQ0hvVBvb71vb71BaUJpYWBQDVEN ISJQIUNBY0VmZmNiRkZFRFJWc3J2d0FTREZjYmZlZHZzclbX9GrCONiAOiWPKwrffkH2Jij79yQj 4a45Ve3aAQHcr8jzrqvbHGqtq1P0nZSbhZuah1BSUBiuOVOwVG5QQFBMUO4QyFtSe1J6SGtSG1Ip XFZvRW9JG0nATvBOVWRDZEtvThRDFEsDQwNLM0MzSzBO0E6EVoVCtla5XLpIQHlSclx7RWlSZVwZ UhZcClI5Uolci0izRrlJtkusUl9RVF1ESkxbV15WRExUW1BeR15jUHVAQIBfUUBfEF8wX9BfVF8k QXTvV59Xj1evV1RPV29XH1dTV0lNTiRxZABIe3sepA0hHb2tDSFsQK2kbFBvb71vb71BaUJpYWBQ DVENIVAhUUFWVnNyUEFkZmZjYkdlY0FRREZjYmZlZHZzclZTfHrHBe2uvz+DLpUh8q1x/Cgj9v8m JfOuOVJYax5RflFX8K7T9t6qE1P9nZ2Tl4SGl1BQUVDVUFBSllRuUEFQ0xBrf0NRQFRRc1RkVBNU A1Q2VCRUVllBWFlYWV1DQVldUFNYUVtMVldRVlBaWXjAWFFYcnBDUUNSckF1UVDor5AQRWNmZKBQ UVBQcFCAULBQVFAeQheUSHtApg0he2yttEANpCK0UG9vb71BaWlBaWlRQUJpaVBAmddeLZRhYFAN IlENY0FjRWZmY2JHV3ZzclZXVkVB1fJuOW8LDm4SEmsORE5UdvEhGGr3dxdvMCKthFBQUVBvr7hT 4VRuUGBRiRArVHJEcmpZGlkUdAZyNXIsWd5Z1HT2Q/t8klNdWUdKSEdgG3yGR1VLUgVSUkBiUVpI DFgMWQxaDFsMXAxdOlg6WTpaOls6XDpd5Hbkd193dnR3dHlmdApaCVs0djR4JHMkdNB0w1rMXMJ4 x3zFYPRa+Vzzd/R443aVdkZN6K+OEEJOaQpYd3VcWlRKcHZFVFt+TUroUvoQTE9Jb0kfSQ9J/0mf SVZfSU9JP0mPSVRPSd9JUknrUgVQRVBQUvoQQEBREFFSQFGAUVJQUUBRUlHor5DjREZkUeivkBBO XkFkUVF+DE08TVJNTEVXVEx+W09KUUp0SRBDSGRJ6FIL4ld0euivkOdMaYB6UXpKYuivkBB2d3pk MGKQYlJvYtBiUmJAUVFRdFBwdF9yj1BRb1AfUFJQSWFkZ0h7HkCkDSEdpL1AvSIeQA0he6Yhex29 pHu9IlBvvW+9IUJpf3t7DSEitECtDSEitEFCaUFCaVFBQkdpYWATKRAQd31Oc1VEfHZBQEJAQ0BT VnJdcEtQWXhXS1FVfVdLUU5EcEtQcV5zS1Byc11cWHlaS1F4d1laVntUS1BPQE1LUVB7e0BsQGx7 QGxAbHtRe3t7e3p70dHRUHsNIVENIiENQ2dGRmNiZmVkd3Z3flJlZGZnZmZjYkZGR1d2dnNyVkVE R0ZHRkdOUkVEVlZzcnZv4l/ZKywoZXXDlskfEWh6wQMt7QpB4FwjOSw6RkZ/S9TvxwY5li2fiVFt TDsiNRRtc0h1YhnRHhcpeE97GCs3SAIMAmdzTE1DWnRjESwMCs8H/FBQUVB0r6JSelXJUEdQ0OlQ Wq+Q43N2ZFnor5AQEXN2ZNBJUVBRXF1aUVNQRkBZe19aVkZMU1tfQHJQclFdQnVcUa9XWBVZFTBX IFfQV8BXVFBXcFfwV+BXkFeAV1ZX6lI6UEhRZuE2SHtApg0hpLRAvWytbEC0pGxQb71vbK1sQWlC aUFjY0CZYWBRDXt7dUdWc3J2dmVBc2VjQWdBY0VzQURGRmNiUkBKHGwyPHzU1OPl5UN7eE7xz0Bu NfJSM9xRVzyu3dytwx18SlBQUVDTr7hTsFR2UEhQ7elQSq+QEFlFR2RScENGZF/or6AQeUJEZHtD UXRYQ0ZcUUNGW1ZQWkFMU1tQY0Z1SEcQY2Zkr0dRkEdRRx5K6K+QEEVkZmTgSqBKUiBK8ErgSq9K VEpcdVnor5AQRWNmZKBZUVBZcFmAWbBZVFkeSRcASHtApg0he71ADSF7pg0he2yttFBvvW9vbGlp UUFCaWFgEykQSlRAXl1fXVJWV1hWWFVYU1ZAVFxLUF1YQUtQUHtRe3p60VANUXt7e3FlVnNydnZ3 dmVBY0FER0ZGY2JmZmVBY0FTbyyFDvMfQFvkW0E+AQHea+TM5Bg9H2UjUsKt491hFwED39hSaauK UFFQSlBQU7hUdlBaUQ7nZVVRUHJBaVror44QXUFpWUZCTGRYRkJMZFLor7rjQkxkUeivuuNCTGRa 6K+IEFlOcWRQeE5xZFror7gQWXJ1ZFBGcnVkWuivihDleH5kUHB4fmRfXHlQeFl2WmlQZVoYUBda BlEGUglYCFk2UTZSOVg5WShQJ1EnUilYKFknWtdR11LWU9lX2FjaWc1QyFnBWvxQ8lrtUOdX4VqZ UJVailCFWrxQs1qrUKRafFpQVVpIUEZaeFB2WmdaH1AQWllVEEJGZFUQW11kWldYWHVZWkRZWVpQ U1JSdVFQRFFRUFVaWlBaWVhYUlJRVldaWVNQUVV/XFFcclgQEBBZ0FlSWehRS+UQVdBVUlXoUUsQ WXBSEFFyW7qCSHtApr1KSa0NrQ1KSL20DUFCaWlCaWlQb2xAbEBsb2xBaddVfnvXLZTXfkh71y2U YWBQe3tRIQ17e3t7e3t7e3t7e3tQDXFRY0NGR2ZnQ2NRUf6uPO60dU9Ie7zprj5Udq3UNz8EJlLY q4pQUFFQVlBQVedUdlBCUuEQQF9EUXpUeVpSGkELQd5BU0Hor6AQWU9xZEBMTXdkWeivoBD9T3Rk VFZcWUNWS1lJQlVUUFRWW1lbXlhCQFBDU0RXTFhLW01edFB1V3pYe15kUGVXalhrXhRTF1YQVx1Y G1sTXxdBGkILXwJCO1c0WDdCKVYqVyRY6VbqX+ZCpVarWXhbQXhQeF13Xnhfd0J/RGhQZ0InWNZY yFPHXPdR+FL4W/Zc5VDmVupemFSGVolZuFS4X7dCpFaqWUxCU1VVUlZXV1VZWlpYW1xcWkBBQV/o rxvjVVBCcOivGRA2Wl9ecJNBV1hwV0FCQntVV0RVVVdeWlxcdV1eRF1dXlhBX197WlhEWlpYUFVS UnVRUERRUVBQUlFXQlRYX0FcXl1aQVpUU0JdXFxYWFdXUlJRVkJfX15eUFpEpkBdUTBdIF3QXVNd 6FH3EFpwH1pRP1ovWlJa6FIFEFkfQVE/QS9BUkHoUgUQW0BVUTBVIFXQVVNV6FH35VGmQ6Y2SHse QKRJHaQNDUitDSGtDSFKSa0NDUi2UG9sQGxAbG9sQGxAbEBsQGxCR2lRQUJpaUJpaUFpaUJpadcd fnvXLZTXfkh71y2U135Ie9ctlNd+SHvXLZR7e3vXXkCUV15AbFdeQGzXXkCU115AlBvgTwMI5F1w XHBS7K+wUFGvsFBer4DkUGBfcELor7BRaGhoaGhoaGgJG+BkAwjpUFivgOFXYFFoaAkb4HEDG+Bj AQoI6VBYr7DhV3BRaGgJG+BCAxvgTgEKCOlQXq+A5l9wXXBccFjor4DiV2BC6K+w4lBoUuqvsFBR r7BRaGhoaGhoaGhoaAkb4EIDG+BHAQoI6VBBr7DjWnBUcFBoaGgJYWBREwwI6VBer4TmQmlQfEJp UOivhOFDaXt7ewkNISJ7e3tQIQ1RDXFRY0NHZmdDY0NHZ0NjUXNTd1NRG67r6vlvVGP56c9lbeb/ ruTr+XmHVHaty7RBmlI+rcibnVI2q4pSLOWsn1BRUF9QUFOhVHZQQFEn519CUV9ySWlW6K+OEOZJ aQpfxlTGWMleyl+QVZBWkFebX1lfEEZpSlNDWUVdSkBlUWpb0VHeW1h/QgdUCVcJWwhex1HIWshb 51LoXJhbml6cQIpThVmBXYtAtVpCQlZWU1dYWVlRVlZZVVRTU1tfX0BeXV1RX19dQFtRUFlSXVtT XEBaVl9SX1pAllCWWVJAdVBZRFBQWVNSXZZdUV11XFNEXFxTWllZU1NSVkBdXVxcUFofQlFCGV0u XHJaXzFWWS4QWuhRS+cQVgBW0FZTVuhSExBecFMuUnIfUFFQGUEslEh7QKYNpL1KSa0NrUpIvUC1 QKS9tg1Qb2xAbEBsb2xAbEBs11V+ew3XLZTXfkh7DS1AlFBBQmlpX1/XWJTXXkCUWJTXXkCUlFiU V15AbGxYbGFgURMMCOReSE1pW+ivjhBbTWlcckdpU3JHaVvor47icWlA6K+QEFpFaVFycWlZEExp e3t7e3t7e3sJDSFQew17e1ENY1FRY0dGR2ZnZ2NRUXNTd1FfUdSuybHzfkx8deOHrsFR242Kaq65 UnhRrqkXYBJjq65crZ5RGgmuDVBQUVBxrgFTvlR2UEpR1+NfTFFf6K+OEPRMaXhEBl//WlMQXRBf Ul9weGBkQHB4YGRXXFlCRl1IQndbd1x3XWZcZl1lXslBW3hCeEMYRglCCUMJRTlCOUM5RSlWJl0p QSpEKkXVXdpB3ELcQ9lEyFr4W+xA60HqRLpat0SlXa1AqUSvTE5CX19cQEFCQlpQU0lEQ0N1QlpE QkJaX1xfQVx1W1pEW1taQ0JCXFxbVlNMSV9QTEBMUn9M70xSTOhSb+VfQxBCEEToUgQQW29CEEJS D0LvQlJC6FES5l9RclAVS1roUgQQQl9wWxAQcFxgXB9cUwBcr1xSXOhREuN/X1Ff6FJv5EtwLDZI e0pJQK0hpA0hSki9SklAvUhApLRJQLQNIb1KSEC9SUC0DSFQSG+9b2xAbEBs11V+e1gtQJTXVX5I e14tQJRQQUJp115AbGxYlBvgXgMb4EgBCgjrUFyvuFBbr7hRaGgJYWBREwwI6VBEr47mZ2lacmdp XuivuOVFaUFyRWl7e3t7CQ0he3tQIQ17UQ1Dd0ZjYmZnZmdmZ1FjQ0ZHZmdDY1FWV1ZWc3IvRGt8 bBhHQXZVW649ko17ck97s+SuPBF0YCwGZK43+UB4dEs7X01UeK3JJdEsJlI7q5j/EgkDUFBRUHhQ UFOEVHZQXlHYEF1C6FKZWFJCUWJCR2RY6K+eEFlCR2RRbk5xZFjor5IQGk5xZHlSeFl/QGlRaVoZ URZSFlgZWR9ADFEEUgRYClkAQDxRM1IzWDpZK1EkWCtZ21HVWNlZqVGkUktJWHZReVh7WWlY9ViH UVdA6K+Q50BFZFJ8QmlZ6K+EEHdCaVFSallaUlhaWnVRUkRRUVJRXV5YVlIxVXtXVlZaMV1QXXte WlLoUV/kWFhXVVboUgsQfFBXcl3wXlFQXhBeMF7QXqBeVV4kUFouUVH/UFEfUD9Qr1BTUElfQCRx LJRIe3sepA0hbB1AvUCtDSFstECkbEBsQK1Qb71sQLVvbK21QWlBQmnXVX571y2UQF6Ue2FgUXt7 eyENUHt7e3sTDAjleVF2WFJR6K+eEFlCR2RYYkJHZFHor5LnTnFkWG5OcWRQe3t7e1EhCVENEwwI 6VBYr47iX2lZ6K+O4l9pWeivuOdLaVlYRkttWeivoOJHaVnor6gQWkZpUkRGaVJKRml7e3t7e3t7 ewljZVFWc3FlcUVRV2ZjcUV4UvQjCK4fUzStkT8pOlG7wlNYVsInrQ4rWctQUVBprgFSLFWDUHpQ KxAdF19ReEJfQWRSQl9BZFdIW15kdUJbXmRGd0ZQeXp6XE91cENddVxBXVxcT3D+S0JBdVVJakt1 dlNqVf56d2p2/np6D1DfUFJQOXsgOEh7QKYNbECktECktECttECtbECkbGxAbFBvvW+9Qml/vWlR QmlhYHt7e3tRIUNuUkJnblJnZmNjRXNyVkVAV1ZWV0ZGRURHRkZjY0Vzcnd+UlJ2dndpHTFwUlVZ YRhodgZoTzgUW0IHDT4zVFgRD09oMnwQBElScDEdUjRSH9pRHmUENm1AWs0b0q6qFTskfX7th5N1 FGbNQEc3zlE42gBSUFBRUOyuAVEJVYNQU1Bi6VBTUS4QSFFQVfFSUs9T/1NSUyZQUHBRUVHxVPHI SHseQKQNbB1ArQ1sQL5Qbx29YWBDQWNB7M2uAVfSqC5QUVB/rgFSIlWDUHpQ0elQU6++419BZHno r77jX0FkduivuONbXmRY6K++EGlbXmRHeEdQeVFRXXB1cUFedV1DcXBwXl3+QkpqTHV3RGpCdVZ3 anj+UVRqVv5QAFHQUVJROXzL3Uh7QKQNbKS0QKS0QK20QK20QKRsbEBsUG+9b71CaX+9aVFBaWFg e3t7e1FFXlJSV15SV1Zzc2VjYmZlZGdmZmd2dmVkd3Z2c3NlY2JHTlJCRkZSIh0xcFJVWWEYaHYG aE84FFlAMAgjDlVXEQ9PaDJ8EARJUnAxUjTzUgDZruJlBTVtQFvNG9OqEz/VdWflh5N2E2XNQEY4 zq7I2QBQUVAHUn1UBlMlUEZQBRBEW1tURktbREZUXXB7XGtcUlxRcFDor7AQXlteZFBAcFmEXFCE RHBT6FIIEFxcXVxKSFFQSUch3Eh7HkCkbECmbFB/HaSttECkvUB7vUANvWFgUA1DZWZjYkZHRkZj YmZnRVZWc3J2dnNyVgc6/GzUKhUVcxHbZhDTAmw9vR8QIVJ9nShzZE1CHmuEbGZMOmdQr6+vrVBQ VQlWsVJ2UHRQUFFXUN5RblFOUHEQQFNSRBBCRGREXDQYe1JTUkbqUnFQeVE01VB7UXt7ZWVQr6+v rVBQVQlWpFJ2UHRQUFFXUJdRb1FXUEkQQFNSr0JRQlxQOHtSU1JOUnlQe1F7IWVlUK+vUDauC1Um VYNSdlB2UFBRV1CYUcRQUFByEElRUGBwYB9gU39gL2DfYFNgVFAYe1FRT1h5UHtRew0hZa+vUPJQ UFS4V3xSdlB4UFBRV1DdUQRROlB4EEBRUF9RgF+gX1J/X8BfUl9S6K5T5Bh7UVFf6VJxUHlQe1F7 DQ0hZa+vUMxQUFVPVqtSdlBhUFBRV1CWUfdRAVBnEEpRsEuvS1I/S/9LUh9LUbBLr0tSD0vAS1JL VOiuKuQYe1FRSepScVB5UTTVUHtRew0NISEhZVCvr1Azr7dVjVaxUnZQYlBQUVdQ3lGXUU5QTBBe U1L/cFFwUzQYe1JTUnPpUnFQeVB7UXsNZWWvr1Dxr7dVclaxUnZQaFBQUVdQ3lHZUU5QchBDUlEP SVFJEEJEZElBPhh7UVJSTOlScVB5UHtRe3shZWWvr1Aar7hUTFWSUnZQFFBQUVdQ3VChUFBQSxBe Un9rb2tSa0xQGHtSUWvpUnJQeVB7UXshZVCvr1Aar7hUTFWSUnZQFFBQUVdQE1CqUFBQSxBeUs9p v2lSaUxaGHtSUWnpUnJQeVB7UXsNZVCvr1Aar7hUTFWSUnZQFFBQUVdQlVCOUFBQRhBaUlBqbUxM EVJRbulSclB5UHtRe2Wvr1Aar7hUTFWTUnZQFFBQUVdQ3lCOUFBQcBBCU1IgbNBsoGxTbEwyGHtS U1Jv6VJyUHlQe1F7DWVlr69QGq+4VExV+lJ2UBRQUFFXUJZQjlBQUHoQQlIZEElKZBkQW11kLxnf GVIZTOivgOQYe1JRF+lSclB5UHtRew17e2Wvr1Aar7hUTFW9UnZQFFBQUVdQl1CNUFBQThBAU1Jf EU8RUhFMUDh7UlNSEelSclB5UHtReyFlZa+vUACuP1O9VG5SdlAWUFBRV1CYUJNQRFB9EEdRT0x/ TFJATFG/TK9MUkBMYEwvTFNMW+ivyOYYe1FRTFh5UHtRew0NISJlUK+vUBuvuFROVZJSdlAYUFBR V1DdUKNQUFBLEF5SsHGgcVJxWlAYe1JRcelSclB5UHtRew1lUK+vUBuvuFROVZJSdlAYUFBRV1AT UI1QUFB24VJP6K+QEEFbXWRfT1EgT1FPWlAYe1JRT+lSclB5UHtRew0he2Wvr1Abr7hUTlWSUnZQ GFBQUVdQlVCPUFBQRhBaUlBwc1paEVJRdOlSclB5UHtRe2Wvr1Abr7hUTlWTUnZQGFBQUVdQ3lCP UFBQTBBeU1L/clFyWjQYe1JTUnXpUnJQeVB7UXsNZWWvr1DtUFBSflWSUnZQlFBQUVZQ3Y9QUHvh UVfor5DjR0lkV+ivkBBecnVkf1dRV1EKGHtRUVfpUnJQeVB7UXsNe3tlUK+vUHNQUFHLVZJSdlCU UFBRVlATmlBQeBBAUVUQR0lkVRBydWRwVVFVUuiv9uQYe1FRVelSclB5UHtRew17e2Wvr6+/UFBS OFWSUnZQlFBQUVZQlYZQUEYQWlFQVllRUhFRUVrpUnJQeVB7UXtlr69QWVBQUmpVk1J2UJRQUFFW UN6cUFBIEFtSUVhSUBh7UVJSW+lSclB5UHtRe2Vlr69Q11BQU7ZV+lJ2UAFQUFFXUJZQr1BQUHTh UXjor5DncnRkH3hReELor7LkGHtRUXbpUnJQeVB7UXsNe2Wvr1AUr7hUd1WSUnZQAlBQUVdQ3VCk UFBQSxBeUrBNoE1STVRQGHtSUU3pUnJQeVB7UXsNZVCvr1AUr7hUd1WSUnZQAlBQUVdQE1COUFBQ duFSS+ivkBBBW11kX0tRIEtRS1RQGHtSUUvpUnJQeVB7UXsNIXtlr69QFK+4VHdVklJ2UAJQUFFX UJVQsFBQUEYQWlJQTE9QVxFSUXDpUnJQeVB7UXtlr69QFK+4VHdVk1J2UAJQUFFXUN5QsFBQUEgQ W1NSTlQ+GHtSU1Jx6VJyUHlQe1F7ZWWvr1AUr7hUd1X6UnZQAlBQUVdQllCwUFBQYBBHUn97b3tS L3uve1Ife997Un97b3tSe1Tor7zkGHtSUXnpUnJQeVB7UXsNDQ0hZa+vUNOvuFOwVZJSdlAIUFBR V1DdULdQUFBxEENRTBBeQGRPTB9MUkxBbBh7UVFM6VJyUHlQe1F7IXtlUK+vUNOvuFOwVZJSdlAI UFBRV1ATUVdQUFBFEFpRUUpBUBh3UVFK6VJyUHlQe1F7UK+vUNOvuFOwVZJSdlAIUFBRV1CVUIxQ UFBJEFxR30lRSUFzGHtRUU/pUnJQeVB7UXsNZVCvr1DTr7hTsFWTUnZQCFBQUVdQ3lCMUFBQTRBf UlEgSVFQSU9BQRFRUlJw6VJyUHlQe1F7DWVlUFBRUBmu9lROVchQW1AOEGNSUVlaWlFwVFtQU1RY V1dUPlZVUFhZVldXWlpZPltwUFVUVFFRUD5TEFLAUlJSblwg3Eh7QKQNbKRsQGxAbECttGxAbEBs QGxQb2ykbEBsQGx/bECtbEBsQGxhYFFBcWVxQWNBcUVxQVGIriFR3+RRwq4+rvZU7PBRxq468KsU UFBSUNBT+FL7VYNQW1BHUGvpUF9S3eVQWVFZ00XoUt3iU1FC6FLd5V9WUVbTXOhS3RBZcFBRUPxI zSlIe0CmDb2tDb1Qb72tDb1hYENkZmNiRkVEVnNydmdERmNiZmVkdnNyVtDzIiTy8yMi8z0zFhUz MxUWM1TuI/LyIyPz8iQWMzMWFjMzUFJQO643VFpV6lBwUHpRNBDARUtETFJmUQ1UCEA4XzhIOHEo XyNMJU3ZeflxtlG4X7hLqHCpcahzQRhJGk0ZcDhJOE04elYaWRtwOV87cClf9lD1Qfl5+Xq2XloV TjZVNU5TTVhfX0BIcXp6eUlJXlBQcFFRU1xcWktLTEpKXXpxT0tIX1xRUFl3TldWX1xReldTT05Q U3FWS0hzSUpdSUpd6FIOEEdeSUReXkldXl5CXUl3SldWXlpdSklGV+hS+hB2VlZcSElQcWNzTEZX SFdcW1NMWlteXlZ0V0p8d3RPQm9CUkJJe7bqUWBQSFFM1XseQKQNHb0eQKYdvVBvb71vb2+ttG9B Qml/tEFCaUFCaVFBQmlCaWlBaVjXfntY1y2UUEFCaUFCR2lBQmlpQmlRQUJpQkdp10BYbFiUWGxY bNdAWGxVbGxYbGFgSBMpEEJ0dkNFdXVEdnRFd01QdkNzTVFQe1F7e3vR0VAhDVEhDVAiUVNGY2Jm Z0dWVnNyd1N3Q3ZSZWRmZmNiR0NHU0ZGR1d2d3ZzclZWRURGR1K4jnFMOMdB43Gn+GFmJiAjI8Il uSl0ECE+IDM6Rf9K4HBCAt8XEGtTLq1SWd7QROmEXq4lcFHeZ1FRkeKv0FhR03CuLXvBPUsgOVML 7y7U5nxQUFFQS6+0VGpVg1BpUL4QGj1nJnvWe1NGcVFEV2pIGUhTeXh3dFRyemlQU1NVaFJTU3R0 dU52UVBQd3d2dk5+YncPYT9hUmGuEGVRZXl+UVoQTXJkWhBCRGRa6FHF439LUUvoUugQWkRATkH7 Xk5EW0/oUgrmTltiDmFoQOhR3xB8cEFgQVJBSmtRUvVyDnBVUVUdaA7vep96v3pTeiJPdnV3Tm7/ T1FPSWr53Uh7HkCkDUkdtEikbECkDa2kDb2kbB5Apg0dtKS9UG+9b72tvUCkDb17e2+9Ia0NtEFC aX9sQGxAbECtbEBsQGxRQUJHaUFCR2lhYFENIVANUXFFcUZFRFZXZmNiR0ZjYmdHVlZzcnd2dnd2 c3JWV3dmZmVkd3NlY3Z2ZWRnZmNiRkdXdnZzclZFRFHcUWuutEMDDx8RAzj8bRomagw1Ynp7S51O f38Y8xMVMNZBlMpxQsos4OW7S+NfxTg/w1N5xHx8B5I1Rkl5aPV3SFhVb1ZYYnv9ZZXebW/EIDdh gCUNl+RLKNrfNT9QUlABrgFURVWDUGhQGlCEEDpUYERgdGk2fzVqJVYkQSpNKX0pbitvKxArESMZ IxrUVtRB203Zfdtu22/bENsR0xjTGdMaxHlLeV15Q3R5cmFUGBNCXFQVEm9pdVpVcmp/d1NsVxgT Em9qaX93dUJcWlxMUWZMVNZRTHdL6FFDEH1PTEhRUHdRW0xsS257Vw5ibmx5H3tRe0occg5Fbl9R bFBoFXkfX1FfSRsh90h7HkCkDR29pL1ApL0eQKYNHb2kvUCkvVBvtG+9rbRApL1BQkdpUUFCR2lC R2lBR2lhYFENUA1HZ0ZGY2JmZWR3dnV+UmVkZmd2dmVkZmNiRkdXdnZzclZFREdGR0ZHRkZFRFdW V0ZGRURWVnNydlFmZmVkd3Z3dndWVkVER0ZHRt/lTCo5NiN0bq66xCUaKDkXapj164JF60U5CQwh dGiqzWcXExl6IAAfNOw977BSYxoZZGX82RMBFX5+8dYWStI5OBZjexv6CzfcHDDMTxQjEdDs4vlD KjAzbGR8FMgwfWzQGyEAfn9t3AAIzQPvUbR2NWBpb286BGZ+DGhvaWkPH1BQUVA9UYBSOFObUFtQ T+lQU1EDEF5ZVpxwUGBQUlAlXAf3SHtApg29UH+9YWBDZGZjYkZFRFZzcnY9xTg5xcU5OMVSnjnE xDk5xcVQUFFQUa45VANV6lBfUAoQXR9aH1sfXh9fVFtcUV/qUbpQUVE5EHFXWV5zWFdQXVxzWlsi QVGpUF9AX1JfX0BYSkFUSUDjKkh7HkC0QLZCaX8NHb1ApGytbFBvbK1sQL29QWlpYWBRIVBRQXZ2 ZWRmY3FFc0FzQXNBUcXriaG4UinA+o+uOVRFWo/9kbX9qQxW9KkMUFBRUMmvt1TzVYNQZlEdENVb fUt9b2gWWhZBFUMfaAx+OnQ6fiBoWxlYdnV1eEFAdXd3dUBCREB1d3d1QEJEQEBCR0hJSnFwT05N WUtyeXh3dnV0c15fQEFCQ0ReRXt8fX5cW1pZWFh6UlNjYVZgVn9QfXx3dXZMS01CQUBbWmNkX09i TFVRT0xIW2ZQWn9MWPRFenRd6FJ9EEVFS5nPTFFMTGVydFBFMEUgRdBFVEXoUm0QXFBlZlFmdXBQ UVDCZ+hRZuFnSHtApA29bEBsQK0NvUFpfw29QKS9QKS9UG9sb71vvUFHaVFBQkdpQUJHaUJHaUFC R2nXXn57Xi1AlH5Ie14tQJRAbNdeQJRhYEgTKRBkYGRGcVJXU3ZwR3JLUU5JTEtQTUxKS2NUZU1Q YVZ/S1FxRk9LUE1KT0tQZFJiTVFgV2JLUVB7e3t7UXt7QGxAbHt7e9HR0VENY0FkZmZjYkZFRF5S RURHRkdGR0ZFRFZzcnZ3Z0ZGY2JmZWR3dnd2d3ZlZG5SZWR2c3JWRUHJCYDS/ZZ0DEhGRTTYfRCd 8C7uf8tiNGccPHBFC/Z3eEs3cD0LO9hTt+eVIP0iYzzxb0hwT3ARCWYdOduW1zoYDRg4Fmh4Sm4i aWlsdwDgCHJuD9SMrHFQUFRQU6++VbhVg1BfUE9QZlAQUdMQZspCxEbESspOi0KERoRKi05Y73zp fVJ2d3l9eWB7YfdT+Fv5XeZ7lnuGe1o1WGBhfzR/JH9Sf+ivgON2fWR/6FIyEE9+fER+fnx9fHt6 eVV+YGFiU2ZgYXhjfXx7elh/eXll6FIy5WdncHEQb+hSMhBMcVBy33JScsRQfn9/Zh9wUV9wP3Av cL9wVHDESOhSMuJYW0DoUjLiUFNr6FIy4nYEf+pSMlB+UUbmVBBnZWZxZu1SMlBwURpQXFBMUjLj VEoSROhSMuVcSRHjKkh7HkCkHb0eQKYdvUCkvWxAbGxsQKS9pL1Qb71vvaQNIWxsQGxApA1srWxB Qml/rWl/QkdpUUFHaUJHadd+e3shXi1AlFFpYWBIEykQGmxuUXV0dW12QnVedlJ1TnZGdlp1VnZK dW5za3xRQV9EcVBPUUxxUUdZRHFQSVdMcVFsdW98UUNdQHFRTVNAcVFFW0hxUEtVSHFQUHt7e3t7 UXt7e3t7e3t7e3t7e3t7e9HRUQ0hUA1RYlRCRURSVHNydFJlZEJ0R3JUUkVEQlRjYnRCZWRSdFFB cWJGRkVEVldGR0ZHR3N3dnd2c3NBQWNiZmVkdnZzc1Km7lE6mpeuyZSUrsmYm1E67s+ug/r3UXzz 81F89vmugq5HUUff0BwvOXtKYRcz8BgFZHQVHc8iA3gXMMVVg5OuxZWTrsiXl1E4k5VRO5Mt866B 9POuhff3UXvz9FF/86u5U3x9IG8J1FhCSWAhz9DHdkyu91GZFGh0aUxQU1BTr75VuFWDUF9QT1Bq UWMQcMRCxEbLSstO9lP4W/hd6WCEQoRGi0qLToVjhmZeIFhw6FL743HXdH/oUvvjYH5RfutSMFB7 UGhSMhBAH3RRX3Q/dC90v3RUdMRYYuhSMhBbUHvfe697U3vEUEjoUjLiWFtA6FIy4lBTf+hSMuJ+ g3DoUjLjcdhUZe1SMlB3UjRQXFBMUjLjVEpsROhSMuVcSWvjKkh7HkCkHb0eQKYdvUCkvUCkvaS9 UG+9b71ApA29QKQNIb1ArQ20QK20YWATKRAEY2d1elFPeXZCdV52UnVOdkZ2WnVWdkp1Y3plT1Bn dWVPUEFfRHFQT1FMcVFHWURxUElXTHFRZHhiT1FmdmhPUENdQHFRTVNAcVFFW0hxUEtVSHFQe3t7 e3t7UXt7e3t7e3t7e3t7e3t7e9HR0VENUWJUQkVEUlRzcnRSZWRCdEdyVFJFREJUY2J0QmVkUnRD R1ZWc3J2ZWRmZmNiRkdXdnZzclZFREZjYmZSpu5ROpqXrsmUlK7JmJtROu7ProP691F88/NRfPb5 roIEK06T2+CMNOkn1eBwJ04lHyPF3SAK2FWDk67FlZOuyJeXUTiTlVE7ky3zroH0866F9/dRe/P0 UX/zrUB0LcW0mtSTMy89TRof9MnJzThQUFJQsVLbVqdV6lBXUERQzBBPDVtRaUFlQhpBFkJUW0FC X15XUFRCQUBbVERDVFJEWOhROeJZUlXoUjIQWl1cWllUUF1eQF7qUjJQX1Fr4kH8QupRa1BEUjLi WFhZ6FJV4lX1V+hSMhBeUPVScFNgUzBTU1NJRYnpUX5QSHtApg1spK2kpmxAraampr1sQGxQb2xs bGytbECtbEFCaUJHaUdpUUFCaWFgUQ1QDVFBcWVxRXFBcUFjQ0NjQXNBU3NTQVG5rqhSyq6mUTWY npeULIIri1LbUuYpKa0aU3+tJVLbrIFS/K0EUuatGlBQUVCOVPpSH1WSUFNQNelQUa+Y40dJZFLo r5DjR0lkU+ivkBB2R0lkL1HQUo9RUz9TL1AvU1M/UD9RUh9RAFJSUFBTQFNSU9dRVFHoUjDiUtZT 6FID5VBJVIn3SHseQKQdraStUG+tDWxhYFENDQ0Ne3t7Q0NjU47VvIxU+lFIrrhQUFJQbVSmUj5V k1BTUFdQGBBzUFNSV2xVVVJQVldVVFJTUVBXbFTPU2wPUD9Q31DAUPBQVVDoUnTjWCDdSHseQKQN Ha2mrUBsQGxAbEBsUG9sQL1BaWlhYENlY0VjZWNFbezp7FSmnZ2dnVBSUFFQUFfAVepQX1BDUPAQ cl5AQ19eQFxQQ19fcFBRRFBQUUNfUVNcUF1eTkBAQUFQUUDoUvcQYlhWVU5XL1jfWFJYWFBTQ05S UVJaWU5cW19cUFhUWXBcXEJCREVXBFMaWkpFUElEMAtIe0keQLRIQKYdpLRBQml/bECtbFBvbGxs QK1sb2ytbEJpfw1srWxAtkFCaX9sQK1sUUFCR2nXfnstQJRRQUJpaVdsbGFgY1FxRXFBcUVxQXFF cUFxU1FxQXNRUpFU461PUv2tA1KsrBGtmphRSlG0wVXq/a5t/K5f/VH3rglSA1LqUFNQA6+VVb1V oFBLUHZQYFEWEOB5UHpRdV9TQFJyUHJTaF9qSxV2GXcVeAJZDHECdgR+OV7TUNBR0FLTU9RL1Uzr S6xQqnZGW0xXdlt3U2pUbWAaURpUGU0VcBh3G30LUAtTCUwFcAlxC3cCeQp9O1E5Uipg21LVddt3 8lmkUUhUU1tDRFRLQ1RUcFt9RHBLfVRCU3d4X0BAUlBMdkJBQVF6eHZ1VE1Md2BUcn96eHZ1VE1M d2BUfE9SQEBgQVFEQUFRT+hS6+JJU3zoUuviW1lR6FFbEFtSfX92V0pwYlFiQepRW1BAUWEQW3J2 cEVRRUlhMwxIex5ApA0dva29HkANph29pL1Qb71vrddefnstQJRQQUJHaUdpUUFCR2lHaVdAXmxs bGxXQF5sbGxsYWBREwwI6VB4r47mRGlMckRpeOivjuVCaUxyQml7e3t7CQ0NDSFQDSFRZ0dXRkdG RURSVHNyd3Z3V3dndnZlZEJ0Y2JGV3Z2c3JQQURHRkdRUUZHRmNiUEFkVLL4M+AGTnjmrufp2iAG I/gz4DIS5FEVl9aZVA7dD4uuskZAY1NsrUkdEQUzilFMVWTsBJbQMC7Msa7w5HdOBewElcWDxLJR MeYXjxpmroeuiSQKEzJSjKyQb0lxUWRRRoBQUFJQHlBQVEZUnVBbUF9QHhB+WVJYU1A+UqlTPl9V UVVfXqlcXVVdWlxYPlZaqVVRXVE+b1LAUvBSU1IFQCHcSHtApg20bEBsrWykbFBvf0BsrWxADaSt tEBsQGxhYFFBcWVxQWNBcUVxQVFxZXFRja4hUd/6Ud+uIVHfrGhTmFFUUcP3Ud+uIfeuPa6s+FBR r61QUFQ9VepQSlCKEGd0WHRbe197QilYJkLZWNVCWCRd1F1SQkFBRVhZWVVcW1paXV5fQEBdXUpd UFlJuEZGVEVVUbhU6FL/51WpWFhPQlFC6FEwEHBBQUBAWlpZUFBaSEdHRERDaEFSU1NWVldoWUBs cEFRQehRUBBbRUVKc1BabH9ZUVnoUVDiVVVQ6FFJ40vjKkh7QKZsQKQNvUCtbECkDb1ApGxAbEBs QKRsQGxAbFBvb2xAbEBsQKQNbECtrr1AbEBsQL1BQmlRQWnXXi1AlJTXXkCUlNdVQJTXQJRhYFAN UQ1xQXFlcWVxZXFRY1FGR2ZnUWNRcUVxRXFFcUFRja4xUc+uMVEFrjqYUXJhS0drUUKGrjtRBa40 UcyuNFEV29/EUpetrAgSZT5Rq61pxN/brutQUFFQ8K45U6pUdlBJUMgQNXhUeFV4RmhUaFppWxhU GFoYWwlUC1k6VDpZK1QrWtpU2lpBQkZJXFNbUkJGSV9WUlpETFdbXV5SY0l1UVBKMEvQS1LgS5BL UoBLsEtSS19cdV1dsF5RkF6AXlJQXnBe4F5TXklK6FFm4QBIex5ApA0NDWwdQK1sHkANDQ2mbB2t tFBvb71vb2xpaUFpaVFBQmlpYWBQDVFBc2VWV1Zzcnd2d0FzQWNBREZGY2JmZmVBU6rxZGMWDQMQ YGri4mQlHAAuZFR2q4ouAE55cUkara5V7a5upcEECNukUZVQUlB/UrpSnlWDUHNQYVDbEF5QTlt2 dHpbdkJ9cXFSfepSLFBSUU/mSUV3b0ZRRupS6FBCUiwQZUlRXi90TXS4YKlOaHKpcHFRcTnAY1HQ Y5BjUjBjIGNSEGMAY1JjRbhvRlFGd3p5VTliy9xIe0CmvaQNvUANDQ0Npg29pL29bEC2UG+tpA20 QK29QGxsQUJpaVFBQmlpQWlhYFFWc3J2ZWRmZmdmZ2dmZ35Sc3JWV3dmZmNiR0ZFRVdER3N2U1ZX VldWRURGY2JmZ2ZSdCrWIdRwb2JzEMMYSFFKF2sfHlnZXMjd9BQTUXnEREFl2wpLTBRuGTxCV1MF OyswYBhoQVtaRl5WFmBzEWxyCSdtbiegbdZieFF8XkZeSUp2eWoeaURQUFJQfVK0Uu1Vg1BbUEdQ E+N/SVFC7VIsUFZQVlFPUFxSLBBKUFZEUFFFeVM5v0lRIEnQSVJJX3lZOUjLOEh7QKa9QA0Npr1Q b29Avb1AvWFgUQ1RYkZFRFZzcnZlZGZHclZFREZjYmZlZHZRJcHn6N/B6OfBATM1HwA0NVWDmOD/ mJT/5JjVItEuJSXTKiRQUFNQFK+4VppUblBlUGxQGlC6EDBtaW0YHHkfaQp5DmkqVVd4EGByZHUc VRNeEnUUGAtUBl4GXwN1OVc3XjVfNHMnQCR210BCQkxQbUBtUm1tRxZmTMB+8H5Sfn5iakzFR0xw akx3d3BXFkxZYkxQUEBQUlDoUi0QSFNTWVtmdUJjbXV+ZxCPflFPfm9+335TfuhRlBBfe2V0UGNA e2B7EHvQe1R76FG0EEdcS3VMchN0j1xRT1xvXB9cU1xJG2RnSHseQKQNIR29pL1ArQ0dpL1AtA0h vUCttL1Qb2xAvQ29QL1vbEC9QL29QUJpfw29QUJpfw29YWBQDVENUVZWc3J2d1ZWc3J2ZWRmZmdm Z2ZlZHZzclZWV3duUmNiR0ZHZmZjYkZCRURXcU5SY2JmZ1FxdnZzclZXVldWV1ZFREZjYmZnZlaW YqDiL+8dOIUr/O8z4ZLGNlE50wcoaUP/TDmU0/c2a3gQ8iPyhDJSrVFSE8MIN99Lre9SGF7IKi7x 6R+jPXxrOjUj+0pfURX35jA2NjDhLwbHHklETUlALjV6HQVFJdkeYk0QFhnNrq4tQ3rA0gcmO1FM zsLwpHJ3QXJ/HBcxIgVkUFNQ1q/hVDlUN1BJUHFQe1IaEK9IU0VVclB8XXVJFlAESTRJWEVJUXhx UUBURFVMQExBTEJFchZTGV0cQBxBFU0bdgpKNkU0TjZy2krQcp9KQ0JKe3xTe0p/cmtQVVxQW1JU X0pSVOpBvFSrUaZfVG1BaHYETepSVI99uVC6UrtTVAhZDEEOdtpyVNVQ2l3aQNpLVLlRukqqUKpS VJpxilCKU7tyVJpQmlKpVFPPQcpx+lP7cVQsSylxKXL7c1Q6cTlzKl0qQFQ8QTZKPXYlUFRHUGty FVIaX1R2SX1KfHJpSlT1UJRKiVK2X1QdXBNJGU4Wd1QqciZzxEDFclQ0WT1FPU44cttyVUJTcnNd Xl5SUEoQYXFAX1FRX18tXlJEXl5ScXNKclR4T1J9U1FQU3hXX3xAXV5TT0RQTEdddVtfXkRSV1Ho UgvkTExHV17oUgsQQnVMW1t4dJ9Xj1e/V6BXVFdKfeivkONCRWR96K+QEHNdQGTAffB9oH1TUH1w fdB9sH1UfU90T0SPRL9EU09EUURJfOpRY1LBUEh7HkCkDSEdvR5ADSF7e6YNHb1Qb720b720QWlB QmlBQmlBQmlRQUJHaUJpQUJHaUJpQUJHaddefnstQJRXXmxsbGxXQF5sbGxsYWBREwwI6VBQr47i XGlx6K+O5kxpcnJCaXPor44QWklpSnJ1aUoQTml7e3tQe3t7CQ0NDQ0hIVENDQ0NDQ0NDQ0NDQ0h IRMMCBBOeUlySnNyU7lfUXNTdEpwclO2ULVStFOzVLRyv31WUQ0hUA0hCVENIVAhDVFnR1dGR0ZF QFdWc3J3V3dndnd2ZUBQY2JGV3ZzclZFREdRUUZjYmZlZHd2U8wzMDtvR0/52ZHPKjkOPGtJeFF2 lgLaRws01eRkUl+ubx4y2+VcWFO30BbaBhY01a6E3SEA1xfdFBQ92lF9UV164RacmsY1Ubqt6W+c nBxpelBSUM6uA1QfVHZQU1ByUNgQZ9xPUSxP3E5SO08sTlIwQDtOUg1ODU9SG04CQFIcQhtNUmpC FEBST01bXFRURHdFRVRBeUhfclToUv8QcVJSUWxTVkQORTxwdFF0UGxSclQOctheDnBLUUsmc87I SHtApA29pL1AbL1ADaa9UG+tbECmbG+9Qml/tEFHaWFgUQ0NDQ0NDQ0NUUVzZUNGRURXVldeUkVE RmNiZmdHVlZzcnZlZGZnblJnUo2dkVFORmF062f0JyLLSOhJp5qIrwnTCWZJUlR2nZ2ux3JBPh1q a3v0Mmo6zsDIRZuMuvYx8CQfGjA8UFBSULauPFGVVHZQU1BZUB/hTFToUv8Qc1FsU1dTVlubUGpU aFVZaFNqWGxVVVZscFdRV5taW9FxiaVIe3umDa1sQK20tEC0tLZQb39ArbZhYBsDCONUVVlYUUBs QGwJUUVzZUNDQXNBQ1Htn/Bnj2RUdp2drsOsqK7rURVTWFBRUCJR+FRqVFZQVVB/5lJTUVBTdVTo UU0QXlBSUXVVUEpXU0lWBwpIex5AtECmbB2tbFB/rb1AbEBsYWBRc0FxZXFUavqsslOYUfhR5vhQ UFFQfq4BVG1VhFBxUOQQDjdWUVFZWVBXWltbVklMTUhQUXJMS0laWVdWWEJDc0pQcFFYU0NZQkBF SE1NdVZbRFZWW01IW1ZUSlZNWFNbSFlFTEBRS0xXWHtKSVpZVlNMcF9wSlFKSnNwWFFYSXLoUc/h gkh7HkC0DUC2DVBvHb1vbGxsrWxsbG+9QWlpQUJpaVFBR2nXXn57LUCUUEFCaUJpQUJpQmlRQUJp aUJHaUFpaVdsbFdAXmxsV0BebGFgUQ1DZ0ZjYmZnQ3NnY2dmZ2ZmY2JHV3ZzclZXV2NXc1NWVnNy fnM1Y2ZqQOGZSJlIRkdPIw0A13M3Y2hoQ0OcSZzvSiogDq47y0ZoMFRC3NUofW4WdslIZzk33Kvs xCFQUFJQ1lAYU49TiFBVUFtQ1BBbWVNdWUlTTVlUWlToUZsQW1hSWKlXV1upWiVW6K+Q40lMZFbo r5AQS19BZFb+WRBJTGRZEF5BZFnPUFK4UWpVqVQlUOivkONJTGRQ6K+QEEJfQWRQ/lBTQFNwU1NT /Fz/KUh7QKYNrXt7pq2kvUCme3ute3umrWxArVB/bK1sYWBRDVFRc1FRY0NRc1FRY1EEUVPCrpFR b8QuUVjIrpdRachSQK5oUZhRmK5ormhRmFGYUFBSUNxQGFO1U4hQVVBbUNAQW1ZTUllGU0JZVFFX 6FGbEEhVW1pYqVdXW6laJVYQSUxkVhBfQWRW/lnor5DjSUxkWeivkBBzXkFkWc9QUqlRalW4VCVQ EElMZFAQX0FkUP5fU09TUlP8Xc3pUdZQSHtApg2te3umraS9QKZ7e617e6atbEC9QFB/bKZsYWBR DVFRY1FRc1NRY1FRc1NHrqvEUW+ukcMvrqjHUWqulsdSQFGYrmiuaFGYUZiuaK5oUFBTUL9QUFdC UJ1QU1BXUFtQbBBCVlVSUVRabFhYV1dUVFNaWmxZ6FFJ4ldsVehRSedTbFCbXImlSHtApq2mraat UG9sQGxAbEC9R2JhYGNlY0VxZWNFcWVjRb+dUY6dUY2enZ2dnZ2dr6+vrVBQVQlXfFJ2UHRQUFFX UBNRN1E6UHHhUkDor5AQW1tBZEBcUBh7UlFA6lJxUHlRNNVQe1F7e2VQr6+vrVBQVQlWq1J2UHRQ UFFXUJZRBlEBUHwQSVJfcFGvcFFwEEhNZHAQW0BkcFECGHtSUU7qUnFQeVE01VB7UXt7eyEiZa+v UDOvt1WNVqtSdlBiUFBRV1CWUZtRAVByEFtSf31vfVIPfVF9U+ivsuQYe1JRe+lScVB5UHtRew0N ZVBSUNGvt1fvVYNQR1B0UKAQ8ERJRE5LcEt0VFRJVE5bcFt0VDxwPnRSNUozTlJgSWBOUnBJcE5S KVdRVV1Rt1tR51aWW1LfU9BeUjtUUSBeUSVbI11SLlMsVFJTRkdeQkRDTkZGRUVSX0hOXFNBQk5A X1JQR05RUlhPTlVZcn1fUk5CR2BHAEdScEcwR1JHdXZFBEEaYFAQUFIAUDBQUnBQIFBSUEovdlF2 THZwWVFZSXXoUWPhyUh7HkCkDR29HkANpg0NDR2ktEFCaQ0Nf2ytbLRQb71vbK1sb2ytbG+9QUJp f2xArWxBaUFCaWFgUA0NDQ0NDQ0hUQ0NDQ0NDQ11RXFlVnFwd3ZBQFBxcEdlcUVxQXFFcUFRclZS RUBCY2JCQUBSV++s8teup66Dy9hRTFFkUVjYU2+tJlIHrfmt6jWQMrfw8bW3/f2EvbidURNRElHi j5b9rhD8rlxU2dKup4uuga6yUU1RGVFiUUtQUFNQAq+4VxNUblBwUH5QZVC7ED12RQdbUhRGFHMb dht6FH0bYhRkB1UHWANzD3YPegN9N1g4XjB0PHY8ejN9QwxiBGRSAkYLSVJiRmNza3ZqemN9bmJi ZFdQXXhQRUR1XWVjf0zARPBEUkREU3tMWmNMQEBaV3VMU0dMUEtAS1JL6FItEEROTlNbfxB4EERK EEtjj0RRb0RRROhRlOVgEIBDUUPor5DjW0FkQ+hSLxBAcXSPVlFvVh9WUlZJZmRnSHseQKQNIR29 rXshvbQNIaS9QK2tUG9sQL0NvUC9b2xAvUC9Qml/Db1BaWlBQmlpUUFpaWFgUQ0NDQ1QDXVWVnNy UEFkQmZjYkZHZmZjYlBTcUZGY2JmZ0dWVnNydlFER0ZjYmZlZHZzclZWVXF2dnNyVlOCHJYqsa69 Jb/C2p1jEJksjFFAUqygU+PWM99w5Hu749aErKsXDMPR6OXUB8IdU31SG1zPJij3/zM0UU5RUPlR W9QjCA0+roKug/aRPz9K9eM5UZTqMS6El5adMpBBx8z0UFBRr6xRmlQ/UgtQU1BOEF9RZVBSSlVw UFFQSVTjKkh7HkC0DUC2UH8dvWFgU2VxRVRUI1GawcFQUFFQUFGaWFBSC1BTUEoQXVFlUFJVcFBR UFTjKkh7QGwNQGxQf71hYEFlcUVYUFGawcFQUlADU6NSClWDUFtQR1CIEAzPSf9JUr9Xv0NSj1eP Q1KfV59DUu9X70NS/1f/Q1LPV89DUt9X30NSLlcuQ1KrWKtEUjxYPERSClgKRFJcWFxEUkRDWFdH XF9bUFNfqV5TqVJeXVJRXGxdUGxdUehRABB/Qz9XL1ffV1NXUUNoRGxeXVxsX19eEEdKZF4lUVdo WGxSUVBsU1PfUlFSSUgh90h7HkCkDWwdQK1sQK20QKZ7bECtbECttFBvDWytbL1AvUBsQGxAvUC9 UUFCaUFCaVBAmUCZYWBQIiEhIVEhISEhISEhIVENUUVzZWRnZmdHVlZXcUVzZWRnZmdHVlZXUUSR cHoLfGdkU1HEkXB6C3xnZFNUlIH11mwAeRZHCweB9dZsAHkWRwsHUFJQF1O5Uh5VmVBbUEdQixAe z0n/SVKgWKBEUlFYUURSsFewQ1KAV4BDUpBXkENS4FfgQ1LyV/JDUsJXwkNS0lfSQ1IgVyBDUjVY NURSA1gDRFJEQ1hXR19cW1NQRPtD6FEAEFxdX6leXlxsXVFY+1foUQAQYFFTqVJSUGxRUV5fbFxD aER3XUduXFxdEEdKZF0lUlJTbFBXaFh3UHBRUVE6SCH3SHtApg1spLRArWxApntsQLRApLRArWxQ b71sQL1Arb1vvWxAvUCtvVFBQmlBQmlQQJlAmWFgUSEhISEhISEhISFQIiFRDUNlY0VEV1ZXd2Zm Z2NlY0VEV1ZXd2ZmZweRT3sLfGZlU4iRT3sLfGZlU1SogfXWawF5F0YPA4H11msBeRdGDwNQUFFQ 0FOjUQFVg1BbUC4QZitY3FhSXVhRrVdRjle/V1LtV59XUstX/ldSClc8V1JYV1tQU6lSUlFbUGxR WGg/US9R31FTUehRABBFV1BRUFdoWHdQbFNTcFJRUklczSlIex5ApA1sHUCtpLRAbFBvvQ1RtFBA rWxAbEC9UUFpUECZYWBRISEhISFQIiFRRXNlZGdmZ0dWVldREZFwegt8Z2RTVJSB9dZsAHkWRwsH UFFQPFO5UW1VmVBbUCQQdoNXs1dS4VeTV1KiWFHDWPFYUiNY0lhSBVg1WFJSWFFYW1NQWPtX6FEA EE5RU6lSUlFbUGxRUFJTbFBXaFh3UFBwUVFRSVzNKUh7HkCkDWwdQKS0QK1sUG+tbEBsQL1Arb1R QUJpUJlhYFAiISEhIVEhIUNlY0VEV1ZXd2ZmZyyRT3sLfGZlU1SogfXWawF5F0YPA1BQU1AeUW9U RlQ3UFNQV1BbUDzlWGxQWVFZ6FL5EFkQVVFVqVBWUVboUvkQY1Bs4FFRYFHAUVKQUbBRUgBRIFFS UVc+UmxQPlZUPltsWVZZPhBVAFXAVfBVVFUhXCHcSHseQKQNHbRsQK20QKSttFB/DQ0hIa2mIa0h piG9YWBRZWNFUXFlcVFlY0VRm51RLqxoU5it5Z1Typ2drrX4rkidnVCvr1BxrgFTvlWTUnZQDFBQ UVdQ3lDmUFBQeeJSUU/or5AQQ3tgZF9PT0+gT1NPXzIYe1FSUnLpUnJQeVB7UXshe2VlUK+vUFZQ UFUWVrFSdlBsUFBRV1DeUQBRTlBLEFtSUUFbUBh7UVJSROpScVB5UTTVUHtRe2VlUFBSUBpQu1Rx VJBQS1B3UO0QSH95UVhAXl9GUlBRR19BQFlRU1JGcUBRQOxS8lBBUuhQRVLo4k95Q+hROeVVWH5S UVLsUvJQV1LoUFNS6BBGdXlVWX5fYF8QX9JfVF9ucnleblpuXOhRORBLTHlKR3FRb1EfUd1RVFFu SG5QbmhKGEqfSlNK6FGu5XhVV84pSHtQb1EeQKQNHbS0pA1sQL2ttLS9pA1sUB1AvbS0pA1sQK29 tLSkDWxBQmlpQUJpaVFBQmlpQUJpaWFgUQ1Dd2dHZmNiR2dHV0ZFRFdHV3dWc3J3V3dndmVkR0RG Y2JmZWR2c3JWhdsj2zrT1DnbJNsXF9sk2znU0zrbI9sX88g7O8jHPDvIU5HYJ9sYGNsn2D4tLj7Y J9wZGdwn2D4uLS08yMg8O8jIUFBRUAxQGFJ8U4hQVVAc6VBQr77iRmlQ6K++EFpHaVdQR1D3UFNU 6FGbEEZSUalSJVBVhVQlUGxwU2BTwFNTUzpW6FEb4QpIe0CmDa2mvUCmvVB/vWFgUQ17e1FRc1FR Y1FzUVnFrpVRa8VSX65pUZdRmVBRUC9QGFIUU4hQVVBk5VdTR1NSUuhRmxBHVFWpVFGpUiVUJVBs b1PPU1JTOlch4kh7QKYNrbamvUC9UH+9YWBRDVFRY1FRc1HYrqfFUWCugMVSQlGWrhCuYFBRUBmu 9lRyVfZQQ1DIEAFdXl5VVVZwV1dcW1tY2FpZUEBfX1RUU3BRUlJBQkJR2ENQXF1dQEE+Q1pbW15e X19CQkNwUFlYWFVVVFRRUVA+UldWVlJSEFPAU1JTbkQg3Eh7QKQNbEBsQGxApGxAbEBsQGxAbECt bEBsQGxAbEBsQKRsbEBsUH9spGxAbGxAbK1sQGxAbG9spGxAbGxArWxAbEBsYWBRQXFlcUFxZXFB Y0FxRXFBcUVxQVGLrj5Rwq4+UcLkUcOuPVHDrj2u9lEi8VKF8VEnrtnxrXvxrt5QUFFQ6VI7UdZT aFBTUEoQXlFsUFJscFBRUPBU8chIe0CkDa1Qf71hYENlY0XpnVI7nZ1QUVA8rqFRbVCBUFtQPhB4 o1hRwVjwWFIiWNRYUlNYUYJXUeRXk1dSBFc0V1JYW1NQWPtXU6lSV+hRABBIUlFbUWxQWFPRUFdo WHdRcFBRUElczSlIex5ApA1sHaS0QL1Qb71sQGy9QL1AvVFBQmlQmWFgUSEhIVAiISEhY2VjRURX Vld3ZmZnLJFPewt8ZmVTgfXWawF5F0YPA1BQUlAXrqFSHlCBUFtQR1CGEB7PSf9JUlBYUERSsley Q1KAV4BDUpBXkENS4FfgQ1LwV/BDUsFXwUNS0lfSQ1IjVyNDUqBYoERSNFg0RFIEWAREUkRDWFdH X1xbU1BE+0PoUQAQW11fqV5eXWxcWFdX6FEAEHxRU6lSUlFsUFheX2xcQ2hEd11cEEdKZFwlUlJT bFBXaFh3Ud9QUVBJSCH3SHseQKQNbB2ktECtbECme2yktECtbFBvrWxAvUCtbG+tbEC9QK29UUFC aUFCaVBAmUCZYWBQISEhUSEhISEhISEhUCJRDWNlY0VEV1ZXd2ZmZ2NlY0VEV1ZXd2ZmZweRT3sL fGZlU4iRT3sLfGZlU4H11msBeRdGDwOB9dZrAXkXRg8DUFdQda+aV4tVg1BTUF9QTlB6UGlQFVAE US4QW8hRx1NS41hRUlNT6FLKEF9QUURQUFFSUWJ7U1BHQEPsUs9QXVFPUEtSzxBbV1JRaldRU1BQ eAHoUs/ibW1m7VLPUHJRT1B4UBlSz+ITE37oUs/keFsGOR3sUspQEFHmUBZSyuJqOmLsUspQdVHm UHtSyuJPPEfsUspQWlHmUEBSyuNUOQUG6FG943HLOEh7e6a9rb2mva29pr2tvbZQb71sQL1Arb1s QL1AbEBsb6RsQL2tvVFBQmlpQUJpadd+e9ctlGFgSBMpENxVBAN1H3YbdWh1ZHZgdU11SXZFdQJs Fk9QAG4dT1EYFBZPUBoSHU9RZ3F7T1Blc2JPUX15e09Qf3diT1FMVkBPUEpYR09RQl5AT1BEXEdP UQRrAU9RHm8BT1EXFRlPUBwRGU9QaXBmT1FjdGZPUXx6fk9QYXZ+T1BOVUtPUUhZS09RQV9DT1BG W0NPUFB7e3t7e3t7e3t7e3tRe3t7e3t7e3t7e3t7e3t7e3t7e3t70VENVVFjUVFkZmNiRkVEVnNy dmdERmNiZ2ZlZHd2c3JXVlFkZmNiRkVEVnNydmdERmNiZ2ZlZHd2c3JXVlVkZmNiRkVEVnNydmdE RmNiZ2ZlZHd2c3JXVlEQUgnTrfiuMc3R0PDcwtDwxB8Ra3B7fHJsbnF9UhLN0NDx3MLQ8MQfEWtw e31ya25xfVJezdHQ8NvD0PDEHxFrcHt8cmxucX1mVlmpp1TRl+XmkpSX6pXIOn1sy8hvf35vrCKX 5eaSlJbplcc7fW3KyW5/fm7El+XmkpSW6ZXHO31tysluf35ur6+vrVBQVQlXfFJ2UHRQUFFXUJVR EFE6UHHlUkEQXkFk6K+e50FEXFwRUlFF6lJxUHlRNNVQe1F7e2VQr69Q8lBQVLhXfFJ2UHhQUFFX UJVRO1E6UHoQQlFcEE5wZFBc/1xSf1wPXFJcUuitr+QYe1FRQulScVB5UHtRew0he2Wvr6+tUFBV CVd8UnZQdFBQUVdQ3VFvUTpQceFSQuivkBBbQklkQlxQGHtSUV/qUnFQeVE01VB7UXt7ZVCvr1Dy UFBUuFaxUnZQeFBQUVdQ3lE8UU5QbOdSUV4QSExkXuivkBBETXBkXhBfQWTwXr9eUvBe4F5SXlTo UV7lGHtRUlJD6VJxUHlQe1F7DSF7e3tlZa+vUPJQUFS4V3xSdlB4UFBRV1ATUdFROlB4EEBRz13/ XVI/XS9dUhBdUV1S6K2r5Bh7UVFd6VJxUHlQe1F7DSEhZa+vUN1QUFGuV3xSdlB8UFBRV1Ddr/9R OlB74VFX6K+Q40dJZFfor5AQXnJ1ZH9XUVdRChh7UVFX6VJxUHlQe1F7DXt7ZVCvr6+wUFBSCVd8 UnZQfFBQUVdQla+XUTpQcRBDUVQQY2RkVBBNT2RUUTEYe1FRWulScVB5UHtRe3t7ZVCvr1BUUFBS ZVaxUnZQfFBQUVdQ3q+XUU5QSBBbUlFYUlAYe1FSUlvpUnFQeVB7UXtlZa+vUGZQUFH+V3xSdlB8 UFBRV1ATr41ROlB4EEBRVRBHSWRVEHJ1ZHBVUVVS6K/25Bh7UVFV6VJxUHlQe1F7DXt7Za+vUDOv t1WNV3xSdlBiUFBRV1DdUZdROlB04VJP6K+QEEBGSWQgT49PUk9TUBh7UlFP6VJxUHlQe1F7IXtl r69QM6+3VY1XfFJ2UGJQUFFXUJVRllE6UEYQWlJQTnFTUxFSUXLpUnFQeVB7UXtlr69QM6+3VY1X fFJ2UGJQUFFXUBNRk1E6UHThUk3or5AQQFtcZABNv01STVNQGHtSUU3pUnFQeVB7UXsNe2Wvr1Dx r7dVcld8UnZQaFBQUVdQ3VHYUTpQexBLUUgQXF5kH0hRT0h/SFIvSN9IUkhBUBh7UVFI6VJxUHlQ e1F7DSEhe2VQr69Q8a+3VXJXfFJ2UGhQUFFXUJVR2FE6UEUQWlFRRUFEGHdRUUvpUnFQeVB7UXtQ r69Q8a+3VXJXfFJ2UGhQUFFXUBNR1VE6UHMQRFFGEEdJZC9GUc9GUUZBUBh7UVFG6VJxUHlQe1F7 DSF7ZVBQUVCWUFBRKlR2UFNQdhBGUlFWUFpV81JTdVFQUHBQUlDzVLqCSHtApg1srWy2UG9vbGFg Y0FjQZbkVHarilBRUElU+lLCVZJQVlAZEERVVlFQUkBSUlLXUDRUU1BVbFZtVOivkBBBWVxkVDRQ NFMvUWxSSVf5OEh7SR5ApEgdrUmmSK2te0mmSL1Qb2y9rQ1sbGxhYFFXc0NjQ3NRCCGeiJCxnFUE +lFIrrhQUFFQVlSTUvRV+lBHUMcQQddeURBYQkBXVVRbR1BqX29Y6FLo4kNvVOhS5BBJXFBJR0dK XCZb0UAdQc1HJlAvSEmwceMqSHt7pq2mtKStHhU1FLZQbx22vKyttFFBQkdpYWATKRB8REZZXlFT RXVSdkRTRmJQRUZSUURTR2JQWV5bYlFFUkNiUUZRQ2JRWl1YYlBQe3t7UXt7QGxAbHt7e9HR0VEN Q3ZnZmNiR0ZjYmZnY1ZWc3J3dnNyV1ZHV1FqaQluO2tzcHJX0lM9BG83E09yRUZRVJM4bm5mTnNk IiJodEhIf1BQUlDyVC9SWlW9UFtQR1Bl5FnUXx1W6FLkEERQHUXUU1FW1EIdUx1c1FA8SM4pSHtA pq1JpKRIvVBvrUmkSKZJpEi9YWBDZGZjYkZFRFZzcnZnREZjYmZlZHZzclbyOxkaOjoZGzocb3t7 b258e29Vahk6OxwdOjsffxAQfX0Qb1BRUDuuC1JMUEdQRVAR5FtZXGpZ6FLl5V7MH1BRUOhSChBf UlFaXGpb9VYmQh1RUsxR6FFu40YHKUh7QKatQKS9pLRQb2ytIaa9pEBsYWBHZ2NXRkZFRFZzcndn RmNiZ2ZlZHZ2iGTWcQUGwMECblsQTg52TUduyuE7WgVkGyNcJVRKRE1CTERQUVB4VPpS8VWSUFZQ GBBDVVZRX1JPUlJS11A0VFNSbFFtU+ivkBBBWVxkUzRQNFQvVmxVSVfLKkh7SR5ApEgdrUmmSK2t e0mmSL1Qf2y9rQ1sbGxhYFFnY1NzU2NRNz6csZCInlVI+q64UUivr1AMr7dUu1d2UnZQZlBQUVdQ mVF4UTRQSRBcUaBhUWFGQhh7UVFk6VJxUHlQe1F7DWVQr69Qb6+4U+FVklJ2UAZQUFFXUJlQxFBQ UEkQXFEgYVFhRUIYe1FRZelSclB5UHtReyFlUK+vUHlQUFTgV3ZSdlBtUFBRV1CZUURRNFBGEFpR UEJfVlcRUVFA6VJxUHlQe1F7Za+vUHhQUFOEVZJSdlANUFBRV1CZUOhQUFBJEFpRUERBVl4RUVFD 6lJyUHlRNNVQe1F7ZVBQUlDsrgFRCVWDUFNQV1Af7VBSUv5QV1E1UFZRLhBzU1BZ8VBTUlBRUVVV z1T/VFJUJlZXV3BSUVLxWFhZhXHxyEh7ex5ApA1sQGwdrQ1sQGxAbEBsQL5Qbx2trbZhYFFBc0FD QXNBUQnNzc1Vg6y6U0arxay5U0dQUq+tUFBVClXqUENQdVDFEH0TWHNTYHRSUlBwcU5WVVJFRE5D UFh0dHZ3S3ZQXVFdSndxRHBVUmlQDXYwC0h7QKa0bK1sHkCmDR29QUJpf1BvbK1sb2ytbEJpf2yt bGFgEykQZldPW1xaXFlcWFxUVk1MTkxSVl9eQF5BXlNWSUpISkdKU1ZPV0txUUZCS3FRTFxwcVFK XkVxUHt7UXt7enp6etFjQXNlY0FxYkdGR0ZCRURSVldWc3VxYmZnZmZlZH5Sc3FBcUVxzvHxUar6 Ci4JJCPeltEX367hUWnC9GAVHh0syM2unFHErjxSy9RSy0VNHDKun5Swru3CT0H9ZmAVuPf8nixg rkLUUFJQGa+3VHFV6lBMUHhRVRDSX0lPSWdTak4GUw1MVlRQRFB6VXRIDVBVYlhSU1NRSEhGVlZX SUlVS0tQSlNTU1FLS1BKSlRMS0tQSEdFVlJVTXNFQnBIR1ZSVFBJS0pJVFNRUFdzVVhNS0pVU1RQ SXBMcEJgQlJC30lUUVBQSVd2TFtbTXRYSnpzdE9fUV9JeWRnSHseQKQNHb0eQKYdvVBvvW9vbGxA pg29QUJHaVFBQmlCR2lQQUJHaUFCaVFBQkdpV0BebFdAWGxYbNdYbNdAWC2UWGxXQF5sYWBIEykQ dHF4WUFddXFBc01QdVxzTVB3Wk1NUXJAcE1RdF52TVB4WXZNUFB7e3tRe3t7e9HRUQ1QDVFjRkdn R1dQQURQc3J3dmVAUGNiRkd2dndVd2d2UWR2c3JWRURGY2JmUWSJGGWGffxREK66h6/fDVFSkmoI EnRmZK69fL8xUZTl1NL6/9PQ41XqZmA2NgOuwK4ora6Lki+NUVVRTEhzGQFrLzc9CqzykJubgZKU n1Cvr1BWUFBVFld8UnZQbFBQUVdQ3VEdUTpQSBBaUVFAVkoYd1FRQOpScVB5UTTVUHtRe6+vUHGu AVO+VZJSdlAMUFBRV1DdUJZQUFBPEEFRUE5RwE6wTlJOX3IYe1FRTulSclB5UHtRew0hZVBQUlDO UFBUrVXqUF9QSlAYEHpASkRfQE5eilBJSk5UU4pRUlBYRHZAWnBaUlp+TFJfcFFwUFFQDUtrDEh7 QKYNbK1sQKYNvVBvb6RsrWxApL1RQUJpaWFgY0FjQXFiR05SRURScXFBQXFiZmVkdnd2c3HOklE3 wh48wgi+rpmu2FEr7M4MHGHVrtlV6q6GXkM15j3qrq2uhlGH3C4L1EVeUFJQ1645VHFV6lBEUHBQ 3hBuGHAHVAhCNlQ4QrtwVmdPUXlYRURQQ0hfU1dRUE5MV1dITF9bUF5LdFtKclJTQ0R1UU9Qb1Af UFNQSXEXZ0h7QKYNbK1sbGweQKYdvVBvb71vvW9BaUFCaVFBQmlhYBMpEExJTVheWXVddk1YS01R SV5LTVFMWk5NUUpcSE1QUHt7UXt7e3vR0VENUA1DQWNBZmdmY2JGRkVEUlZzcnd2d0FTREZjYmZl ZHZzclbX5BlnGAzYgDoljyoDF2YYQfYmKPv3JCPhrjlXAa2sHUly3K/I9K6s23FKG62rU/SdlJuF m5qHUFFQ8VFwVFlU2FBbUK/md1RRdFRRLBsDCBBHTkFaVltSWVdWW1NYVFNYUFVRUFVSWVXrUidQ VlBTUifjUldRWetSJ1BYUFtSJxBIUFZSxHpRUVHEWGBQwFBSb1AAUFJQWlRYEVpSwlBZUFZSwlBV UFJSwlBTUFBSwhBGW1lVxFTEU+BbkFtSz1tRcFtRW6xczulR0VBIe0CmDQ0NbEmsrGxIQLxAvEC8 QLxAbFB/DSFsSawNrGxIQLxAvEBsQLxAvF9fX18bAwjiVnpY7q+GUFevsFBTr7BQW6+wEF1RUFJT VFVWV1hZWltbUUdoaGhoUGhoCRsBCBBZUlFaWVBUVVRXUUdoCQlhYFANUQ1DUVFnUVFHUVFXUVHx UWuulipRalFpKK6YUWoqrpaulVHJUWtRaiqullFpKa6XrpYqUWqulVBRUDtSjVGMVZxQWVAAEEBR ckJpU3JCaVdYUFFUU1lQ6FFP41hTuFToUvMQX1dXWFFYWWVRUJtUUyVaB+lRf1BIe0CmbKZsrWxQ b2xApL1ArWxBQmlRQUJpYWBQe3tRQVZXZWZmZ2NBURs2Km7IfzxSjVJ6AXArRDptrUFQUVBJUo1S 2FWcUExQPRBLU1RcSFIlSLVHtUisU1RaVVFKSUhTV11ISUJK6lIxUExRT+ZBXXdvXlFe6lLoUFpS MRBEQVFLTGpXeUTvUF15XndQSU35OEh7HkCkHaS9QK29pGxQb62kDbRAra1BaWlRQUJHaWFgUSEN UCFDZmdmdGdmZWR2c3JWV3dmZmNiRkVEV1ZXVldxRUlWeW9RcEt1FhQSEUXHTd/Wx91rffADc1HS Uo1paQaBTnl7YG5/E0A/OSYFBBtoI210KVBQUVBxUptS1lWcUHtQJhBBc1hAQ3NAHV9fRlVRd2BQ UVDsUuhQVVIxUHlRTxBcTUl3D0o/SlJvSlFK6lLoUEZSMRBJTVFf8EN5cHdYeXaPUEl5SndReVBJ fPk4SHseQKQdvaS9QK29pK2kUG+tpA0itECtraQNtEFCaX+saVFCaUFpYWBDZ0ZHRmNiZmVkdnNy V1ZzZ0ZmZWR2c3JWV3dmZmNiRkVEVldGRkVEVnNydnHCRHB7axcGGAdcRV5YRgEbbGtob0ffeS0o wNMXEwkEzsLcxFPxX2xGTh5nYmxSUT5RbHt1ZHxqRzoEOwBnBkNGNRQN2j9QU1A7r5dW2FWDUFNQ XVB6UI8QR39LUX98Y3FvdhRxBHH8eOx4vHhYUlNT6FLKEHFQUURQUFF4eV9AQVNLXlBTUVJUfHtb XFRVWFdMSEtXuFjoUvPiW1Rd6FFPEFlbXGpSUVFLHUjvUjFQT1FPUHhSMlBeUHlSMhBbenped1BQ U1led0vqUjNQTFFNEENFeXJqenp5OXxVVFxdeVRYV5tU6FEU43sHOEh7QKambECtbEBsQKZsQKS9 rb20UG9sQKRsQL1Ava2tpG9spGytbECkrUFCaUFCaVFBQmlBQkdpQUJHaUFp1357LUCUYWBRDVAN R1FjUVNBVldlZmZnY0FRZmdmdGdmZWR2c3JWV3dmZmNiRkVEV1ZXVldxRbRUHc2r42Y2Km7IfzxS bVZ6blFwS3UVFRIRRcdNwNXH3Wt9zwRzUdJpVlyppFNGUnoBcCtEOm2tQa1UaGkHgE95e2BtfxJf IDkmBQQbaCRtcylQVFA7r5dW3lWDUFNQXVBIUEtRURBwRkFRcFFwUnlBe0tqQWpLBlA2UNZLWUtL NksmS1NRUFDoUsoQTVNSRFNTUltcVFBTUVJUTUxLQUJIXkpBQktVV7hY6FLz4ltUXehRTxBFXFxb UltqUVFGR0dAX0tJRURESTRf6FLg4l5DQuhRTxB9SEheUFN3XltKZUNLqUFBD0BRQL5eZUNGHXBI UUj8TVxdZVVUWFebcFRRVElM61HxUDhQSFFe1XseQKQNHaZsQGytbECmDbRsva0NbEC9QL1Qb6Rs QGxArWxApK1sQGxAbEBsbEBsb7RsQGxArWxApK1pQUJpaVFBQmlCaUFCR2lBQmnXfnstQJRhYFEN DVANR1FjUVNBVldlZmZnY0FRZXFlUWNBY0VzRVNBU6xUHsyr4x42Km7IfzxT6q7RUcUqODjAtmlW XKmkU0ZSegFwK0Q6ba1BrVTKK1GKrkc8ylFWUVeuqVBUUHGvl1beVYNQU1B9UGhQa1Fj5X9tUVJT U+hSyhB3UFFEUFBRQkVBUFNRUlRtbHVcRWJjanVBQlVUWWFqYmBCHUFBSFlV6FL6EFtAVHBUYFRT VMFZS+hS+hBHT0x/TG9MUy9MUQ9MP0xSD0w/TFJMwUjtUjFQT1BZUjFQe1FPEEJPY1JRUWVkZGlm Z2d/a2k0YH/oUuHifmNi6FFPEFloaH5TUN9+W0HoUmAQTUVrqWFhYL5oamVjZsFjfnloHm1FeXJy XHlgeFF46FJ4EF1US3lMclV5VElsLDZIex5ApB29pL1ArQ29pL1Apr1stEC9QK1sQL1ApFBvpmxA bECtbECkbK1sQGxAbEBsQGxvbKStvUCtpCIhIQ20QKQNtEFCaX+sQUJpaUFCaUFCaVFBQmlBQmlB QkdpQUJp1357LUCUYWBRDUdRY1FRZ0ZHRmNiZmVkdnNWc2dGZmVkdnNyVld3ZmZjYkZFRFZXRkZF RFZzcnZRZXFlUWNBY0VzRVNBU6xUHc2r467YwkRwe2sXBhgEYlhGARtsa2hvR995LSjA0xcTCQTO wtzEVQ+u0lHEKzg4wbVpVlyppFOKX2xGTh5nYmxTPlFse3VkfGpHOgQ7AGcGQ0Y1FA3aP6z3yitR iq5HPMpRVlFXrqlQUFGvsVZOVNpWz1BTUHUQXVJgU1NRYFBTSlVQSVTqUdlR3lBIex5AtEC2UH8d vWxAvWFgU2VxRU9U+VZO0dFQUa+0r7dUA1WDUH9Q7uM2UlFC6K+w411BZFTor7DjWUFkQeivsONZ QWR96K+cEEZeTGR9e35+UHZHcF5MZEdJRkZORFd26FID5FjfdVF16FID4k9fTuhSAxB+Xk9PRFBO e1NETklZXUBZVlReTXB0d1Rbdk9yTl9eXltYV1dbfX5+R2F1Tlt2cn+9hGxAhmxBY0Fpf2NCaX9j QUJpaUFHaUJHaVBvvW+9QWl/bK1sQKYNbK1sQUJpf0Jpe1BBQmlIf0Jpe2FgUXt7ew1RcldWV1ZX cVdxVkVER3FXcUZHRmNiZ0VWc3BTdndzZ2N2ZWRnc2djQnVmY2JHV3ZTRvgiFGdoWlL6S60xUVFS 1Eyt/XrwI9brOS3HrmzPcEfJTDlTUdNMJG5RVfGS6i94KlV9AWAICwLWRUMdX9a1MBUynmpRKBw8 1nphREXWURbeCAHqNVBQUFJQUFBQUFCvd1DGUFBQUFBQUFBQUFBQUFBQUFBQUFBQjlBQUVJRU1BT UFRQVVBWUFdQWFBZUFpQW1BcUF1QXlBfUEBQQVBCUENQRFBFUEZQR1BIUElQSlBLUExQTVBOUE9Q cFBxUHJQc1B0UHVQdlB3UHhQeVB6UHtQfFB9UH5Qf1BgUGFQYlBjUGRQZVBmUGdQaFBpUGpQa1Bs UG1QblBvUBBQEVASUBNQFFAVUBZQF1AYUBlQGlAbUBxQHVAeUB9QAFABUAJQA1AEUAVQBlAHUAhQ CVAKUAtQDFANUA5QD1AwUDFQMlAzUDRQNVA2UDdQOFA5UDpQO1A8UD1QPlA/UCBQIVAiUCNQJFAl UCZQJ1AoUClQKlArUCxQLVAuUC9Q0FDRUNJQ01DUUNVQ1lDXUNhQ2VDaUNtQ3FDdUN5QwFDBUMNQ xlFUUM1QzlDwUPFQ8lDzUPRQ9lD5UPpQ+1D9UP5Q/1DgUOFQ4lDjUORQ5VDmUOdQ6FDqUOtQ7VDu UO9QklCTUJRQlVCWUJdQmFCZUJpQm1CcUJ1QnlCfUIBQgVCDUIRQhVCGUIdQiFCJUI1QjlCxULRQ tVC2ULdQuFC5ULpQu1C8UL1QvlCgUKFQolCjUKRQpVCmUIpRVVV+PiU8PEA+Pz49MSI7OT43IjUk JSI+Uz0lYVclPjliYBETUFBQUFBQUVBQUtRQUVA5UdBQVlCmUFNQdK/fUFNQZ6+LUFNQbK+LUERQ RK84UHRQU6/fUHRQZ684UHRQaa84UHRQaq/kUHRQbK84UHRQCa+LUHRQCq+LUHRQDK+LUHRQ+a84 UHlQX69NUHlQQa9NUHlQdK/fUH9QU6/kUH9QZ684UH9Qaa84UH9Qaq84UH9QbK84UH9QDK/kUH9Q +a/fUGNQU6+LUGNQX66oUGNQQa6oUGNQdK84UGVQZ6+LUGVQaa+LUGVQaq+LUGVQbK+LUGdQU6+L UGdQX69NUGdQQK/fUGdQQa9NUGdQTa9NUGdQTq9NUGdQdK84UGdQYq+LUGdQFK9NUGdQFq9NUGdQ GK9NUGdQHK/kUGdQAq9NUGdQBa/kUGdQBq9NUGdQCK/kUGdQCq/fUGdQDK/fUGlQX68UUGlQQK/f UGlQQa8UUGlQTa/kUGlQTq/kUGlQdK84UGlQFK84UGlQGK/fUGlQHK+LUGlQAq/fUGlQBa/kUGlQ CK/kUGlQDK/kUGpQX6/fUGpQQK+LUGpQQa/fUGpQTa+LUGpQTq+LUGpQdK/kUGpQFK/kUGpQGK+L UGpQHFBQUGpQAq+LUGpQBa+LUGpQCK+LUGpQDK++UGxQU6+LUGxQX66oUGxQQK8UUGxQQa6oUGxQ Ta/fUGxQTq8rUGxQdK84UGxQFK84UGxQGK8UUGxQHK/kUGxQAq8UUGxQA684UGxQBK8UUGxQCK/f UGxQCa/fUBlQGa+LUBlQ+VB1UAVQX6/fUAVQQa/fUAVQ+VAcUAlQX684UAlQQa84UApQX6/fUApQ Qa/fUAxQX684UAxQQa84UPhQ+K+LUPlQU6/kUPlQBq+LUPlQ+a+LUFBQUVBRUFFQUFBRUFBDplBQ UERQUFBQUFBDvmDSQ7pWWXrWGNanXVFXUvDSQ4tg0kOHUlFRYV5gXFZYetYY1qddUlVVUGAwVlp7 VlFUUdJnUlFU8AJgAGB8Vlp7VlFUUdJnUlFM8k7QTFBsUGxQbFAfUDJQI1A/UDxQNVAkUDVQblBu UG5gcGBcVlh61hjWp11SVVVQVEBLGCTbDh82bA4sjvONuI318NJfgmDSUpBg0lJ5UkRD2eSB2rj3 lO1ll8vd2JpPmgMGwWBdVll61hjWp11RUVRVUGDRzmFPYE1WUwVUWkNGBjUiOQM5Nz5wBCIlIyRw HjUkJz8iO2FHYEVWUwVUW0NeBjUiOQM5Nz58cBk+M35hfGB6VlMFVFtDcwY1IjkDOTc+cAQ5PTVw AyQxPSA5PjdwAzUiJjkzNXACPz8kYWRgYlZTBVRbQ3seH3AcGRESGRwZBAlwERMTFQAEFRR8cHgz eWlncAY1IjkDOTc+fHAZPjN+YE5HXWlnYGVhYmBnYGBgYApHXWlpYWJjYWBnYGBgYApg0c5hT2BN VlMFVFpDRgY1IjkDOTc+cAQiJSMkcB41JCc/IjthR2BFVlMFVFtDXgY1IjkDOTc+fHAZPjN+YXxg elZTBVRbQ3MGNSI5Azk3PnAEOT01cAMkMT0gOT43cAM1IiY5MzVwAj8/JGFkYGJWUwVUW0N7Hh9w HBkREhkcGQQJcBETExUABBUUfHB4M3lpZ3AGNSI5Azk3PnxwGT4zfmDRz2BdVll61hjWp11RUVFV UFPR3VBg0dlS0dFQg35woDgsfH1+0UzhVuL3W+dBXQeKA4gls5ljeuKEplkLZKO5wK5ZXICLSwrp nbem2OHNkNd1uy0IQCM6KJshRa2WCKZ5+wgOxlStfTJBCNFMmiHEhXIIf4WcRFXUZurE+uQdGrm+ a3L9Bskuccw81pAaF8c65PZmhaxZfYPkactSU1FQUWBdVll61hjWp11RUVRVUFPR0VBqQczVVW6C udCrK4X5pPwprFWsxW0hc/l7eI/cQzXZrnzXUd8KyjKaQffQpOfuROeBBsk7WDIVlvL1imUvVXKO In1U1lX3LFlGw0QToKdGHYZX3stAPAiuWmXHmtnPj1QgzHotMd6RuFshyviXNjISbcXEcmLIctna qjRYdKWCqmDSUp1g0lJmUkVQ7UHKihO9casWCNTZmhbYwHW+RDBgXVZZetYY1qddUVFUVVBg0c5h T2BNVlMFVFpDRgY1IjkDOTc+cAQiJSMkcB41JCc/IjthR2BFVlMFVFtDXgY1IjkDOTc+fHAZPjN+ YXxgelZTBVRbQ3MGNSI5Azk3PnAEOT01cAMkMT0gOT43cAM1IiY5MzVwAj8/JGFkYGJWUwVUW0N7 Hh9wHBkREhkcGQQJcBETExUABBUUfHB4M3lpZ3AGNSI5Azk3PnxwGT4zfmBOR11pZ2BlYWJgZ2Bg YGAKR11paWFiY2FgZ2BgYGAKYNH8YXdgdVZTBVRbQ04GNSI5Azk3PnAEOT01cAMkMT0gOT43cAM1 IiY5MzVhT2BNVlMFVFtDRgY1IjkDOTc+cAQiJSMkcB41JCc/IjthZGBiVlMFVFtDex4fcBwZERIZ HBkECXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58cBk+M35hR2BFVlMFVFpDXgY1IjkDOTc+fHAZ PjN+YUFgX1ZTBVRXQ1gZPiQ1Ij41JGDRzWBdVll61hjWp11RUVFVUFPR21Bg0ddS0dFQ+zG95P3d wBfAjORBDjmMWi8ywFZhnZ6v2MEWhxlqxLmEVm/N/fIoCryprDMVH+hbPmC/8mb7fVmPoT93+10B MFVlHy+eBB+A53wSiFuA3egOr+bQgLPG5C9yGRJAPIPI4FEG85Offs9qpC/4CPaHcjW13PsozOyJ FxI4C30treVSUVNgXVZZetYY1qddUVFUVVBT0dFQPTCryQ/0OeODKyB7MnNOFHAB/3NFlyRSqRmi d0oM/NYhZVh7pt+OsOXGuNv3G7MjmBhZzeCK24pFwppTtVl1Bla3HvQX9YEHFoRoBqVxnZN2a311 Yp7Lsu8QF7qIPRcmtZBg81/Qni+Iay7wqcV6YXtFqphEvY3guQURIBZ9fC5g0lppYNJZ8vBTUlFS UkAebtQ+B7DAgInbHJxy0wkdYF1WWXrWGNanXVFRUlVQYDFhQWBfVlMFVFdDWBk+JDUiPjUkYUdg RVZTBVRaQ14GNSI5Azk3PnxwGT4zfmFjYGFWUwVUW0N6BjUiOQM5Nz5wEz89PTUiMzkxPHADPzYk JzEiNXAAJTI8OSM4NSIjcBMRYE5HXWlnYGZgZGBgYGBgYApHXWloYGZgZGJjZWllaQpg0lEVYUFg X1ZTBVRXQ1gZPiQ1Ij41JGFHYEVWUwVUWkNeBjUiOQM5Nz58cBk+M35hY2BhVlMFVFtDegY1IjkD OTc+cBM/PT01IjM5MTxwAz82JCcxIjVwACUyPDkjODUiI3ATEWEWYBRWUwVUW0NtJycnfiY1Ijkj OTc+fjM/PX8iNSA/IzkkPyIpfxMAA3AZPjM/IiB+cDIpcAI1Nn58HBkREn4cBBR4M3lpZmFrYGlW UwVUW0NiFDk3OSQxPHAZFHATPDEjI3BjcH1wHTkzIj8jPzYkcAM/NiQnMSI1cAYxPDk0MSQ5Pz5h W2BZVlMFVFZDUgUDYUFgX1ZTBVRYQ1gZPDw5Pj85I2FKYEhWUwVUV0NBFTw7cBciPyY1cAY5PDwx NzVhcWBPVlMFVFNESB0/Pj8kKSA1cAQpID83IjEgOCl8cBk+M2AMYF1WWXrWGNanXVFRUVVQUxtQ YBhSEVDydQ4QA6OnI22oFjfIS4YImrcY/5OInGLnZs2U4KUp8q420uQ0a/t9XVvxmS6EE5muUMD9 ErOCCET8qXiYgT81UlNRUFHz0lceYNJXGmBZVlMFTUNUUmBQYFtWUwVNX1RUU1JV8GDR2FZTBU1R VNHQYC7QQCvGtIETrTjIo2icPmuiW9LxM2AxYUFgX1ZTBVRXQ1gZPiQ1Ij41JGFHYEVWUwVUWkNe BjUiOQM5Nz58cBk+M35hY2BhVlMFVFtDegY1IjkDOTc+cBM/PT01IjM5MTxwAz82JCcxIjVwACUy PDkjODUiI3ATEdJVUuRQUFFgcVZTBU1UUVGvVEdgRGBeYFxWWntWUVRR0mdSUUZTUlfQUGBdVlMF TVpUVmBUU1JWEGDSVGZWWntWUVRR0mdSUVpRUa9U0lRzYNJUT/B50Hc4JCQgI2p/fycnJ34mNSI5 Izk3Pn4zPz1/IjUgPyM5JD8iKX8TAAPx0lPo0dJT5AQ4OSNwMzUiJDk2OTMxJDVwOT4zPyIgPyIx JDUjcDIpcCI1NjUiNT4zNXxwMT40cDkkI3AlIzVwOSNwIyQiOTMkPClaIyUyOjUzJHAkP3xwJDg1 cAY1IjkDOTc+cBM1IiQ5NjkzMSQ5Pz5wACIxMyQ5MzVwAyQxJDU9NT4kcHgTAAN5WiY1IiM5Pz5w YX5gfHAxJjE5PDEyPDVwOT5wJDg1cAY1IjkDOTc+cCI1ID8jOSQ/IilwMSRqWjgkJCAjan9/Jycn fiY1IjkjOTc+fjM/PWtwMilwFX09MTk8cDEkcBMAA30iNSElNSMkIxAmNSI5Izk3Pn4zPz1rcD8i WjIpcD0xOTxwMSRwBjUiOQM5Nz58cBk+M358cGJlaWNwEz8xIyRwESY1fnxwHT8lPiQxOT5wBjk1 J3xwExFwaWRgZGNaBQMRcBM/ICkiOTc4JHB4M3lhaWlmcAY1IjkDOTc+fHAZPjN+cHARPDxwAjk3 OCQjcAI1IzUiJjU0fnATFQIEERkeWgcRAgIRHgQZFQNwFBkDExwRGR0VFHARHhRwHBkREhkcGQQJ cBwZHRkEFRR+WloHEQIeGR4XanAEGBVwBQMVcB8WcAQYGQNwExUCBBkWGRMRBBVwGQNwAwQCGRME HAlwAwUSGhUTBHAEH3AEGBVaBhUCGQMZFx5wExUCBBkWGRMRBBkfHnAAAhETBBkTFXADBBEEFR0V HgR+cHAEGBVwGQMDBRkeF3ARBQQYHwIZBAlaFBkDExwRGR0DcBMVAgQRGR5wGR0AHBkVFHARHhRw FQgAAhUDA3AHEQICER4EGRUDfHAZHhMcBRQZHhdwBxECAhEeBBkVA1ofFnAdFQITGBEeBBESGRwZ BAlwHwJwFhkEHhUDA3AWHwJwEXAAEQIEGRMFHBECcAAFAgAfAxV8cBEeFHAHGRwccB4fBFoSFXAc GRESHBVwFh8CcBMfHgMVAQUVHgQZERx8cAAFHhkEGQYVfHARHhRwExUCBBEZHnAfBBgVAnAUER0R FxUDfnADFRVaBBgVcBMAA3AWHwJwFBUEERkcA35aWhM/PiQ1PiQjcD82cCQ4NXAGNSI5Azk3PnAi NTc5IyQ1IjU0cD4/PiY1Ijk2OTU0AyUyOjUzJBEkJCI5MiUkNSNaNSgkNT4jOT8+cCYxPCU1cCM4 MTw8cD4/JHAyNXAzPz4jOTQ1IjU0cDEjcDEzMyUiMSQ1cDk+Nj8iPTEkOT8+WiYxPDk0MSQ1NHAy KXAkODVwGRF+WvNm0GQ4JCQgI2p/fycnJ34mNSI5Izk3Pn4zPz1/IjUgPyM5JD8iKX8mNSI5Izk3 Pjw/Nz9+Nzk2YNJST1ZTBU1TVNJSRmDSUkJg0lJeYNJSWlZbMNYYUdaoFVFXUVFg0lGpRtJR9wQ4 OSNwMzUiJDk2OTMxJDVwOT4zPyIgPyIxJDUjcDIpcCI1NjUiNT4zNXxwMT40cDkkI3AlIzVwOSNw IyQiOTMkPClwIyUyOjUzJHAkP3xwJDg1cAY1IjkDOTc+cBM1IiQ5NjkzMSQ5Pz5wACIxMyQ5MzVw AyQxJDU9NT4kcHgTAAN5fHAxJjE5PDEyPDVwMSRqcDgkJCAjan9/JycnfiY1IjkjOTc+fjM/PX8T AANrcDIpcBV9PTE5PHAxJHATAAN9IjUhJTUjJCMQJjUiOSM5Nz5+Mz89a3A/InAyKXA9MTk8cDEk cAY1IjkDOTc+fHAZPjN+fHBiZWljcBM/MSMkcBEmNX58cB0/JT4kMTk+cAY5NSd8cBMRcGlkYGRj cAUDEXAENTx+cHthcHhkYWV5cGlmYX1oaGNgcBM/ICkiOTc4JHB4M3lwYWlpZnAGNSI5Azk3Pnxw GT4zfnBwETw8cAI5NzgkI3ACNSM1IiY1NH5wExUCBBEZHnAHEQICER4EGRUDcBQZAxMcERkdFRRw MT40cBwZERIZHBkECXAcGR0ZBBUUfvBeVlww1hhR1qgVUVdRUVHxXlZcMNYYUdaoFVFXUVFSYHxg ekZ4OCQkICNqf38nJyd+JjUiOSM5Nz5+Mz89fyI1ID8jOSQ/Iil/EwADcGBGVlp7VlFUUdJnUlFL VFhgVlFRr1FRr2BdVll61hjWp11RUVJVUFPR0VDQpQ43yh22CU5em+uMniWtZrf2x7AuFyjMVVP0 w0ZyR+yHl8mzFKp1qftSD12GPqyEiJaOXiizvylygUak03iYuBatKmxu47jpfoW0i70Sy6Wog+e0 LYj4vzN81cBVnkIVaYcy2lZOrS2VGK0KO4ATDH+ewSxqvgp9ZCHxgMh00mHSU9hg0lPUUlFRYCVg MWFBYF9WUwVUV0NYGT4kNSI+NSRhR2BFVlMFVFpDXgY1IjkDOTc+fHAZPjN+YWNgYVZTBVRbQ3oG NSI5Azk3PnATPz09NSIzOTE8cAM/NiQnMSI1cAAlMjw5Izg1IiNwExFSQB5u1D4HsMCAidscnHLT CR1gXFZYetYY1qddUlVVUPDRhGBJVll61hjWp11RWVNhXFZae1ZRVFHSZ1JRVGBMVlp7VlFUUdJn UlFbYV5gXFZae1ZRVFHSZ1JRRmBPVll61hjWp11RWVRhQlRAQTKMOjVoT/4XKagBO/+z5WAoVlp7 VlFUUdJnUlFcYTpgOPAa0BhQEVAiUDlQMVA8UHBQH1AgUDVQPlAEUClQIFA1UHBQNlA/UD5QJFBw UCdQOVA+UDFQPlAjUDlQcFAzUDhQMVAiUHBQI1A1UCTxStBIOCQkIGp/fycnJ349Pz4/JCkgNX4z Pz1wYF1WWXrWGNanXVFRUVVQVBDXDEzCa9WnH6buzcgMo/TrwjxgGcqGtw6WSl8cfOE6+UzZ5TCQ Xu5vY9CZyRQieCwf3PBkXDc0optJoQDizkOm8dJRgGDSUZxWWXrWGNanXVFZVmHSUe1g0lHpUlFR YNHoYNHOYU9gTVZTBVRaQ0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7YUdgRVZTBVRbQ14GNSI5Azk3 PnxwGT4zfmF8YHpWUwVUW0NzBjUiOQM5Nz5wBDk9NXADJDE9IDk+N3ADNSImOTM1cAI/PyRhZGBi VlMFVFtDex4fcBwZERIZHBkECXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58cBk+M35SRVDtQcqK E71xqxYI1NmaFtjAdb5EMGBcVlh61hjWp11SVVVQ8AlgSFZZetYY1qddUVlTYVtWWXrWGNanXVFX UWBMVll61hjWp11RWVVhX0ddaWhgYWBoYGBkZ2FjCmBPVll61hjWp11RWVRhQlRA765AjNAkQmgH OLQy+lbDf2BdVll61hjWp11RUVFVUFTR0HgxmtCIWIyDZLKd/To1WsNr8WMvVcgJXc68w8U+4e6N hn7pPBoQLimYtxfauZYb6gV++9eB9Dhf8iDvewMG1Aj+SPkZPQ+g+G5Qg92OPxboXwjq8GQG0Z/b /S80rEef1Up688zfHt8RZu/8ch1yxHrQA7kHT+08+H5iCsYrQSojUFAQALgPtiEBALYhAQAQIQEA AQACAAAAABACCwcEAgICAgIEAAC8AgAAAABMUAMAAAAAAAAAAAAAAAAAAAABAAAAAAAAAG7dNSsA AAAAAAAAAAAAAAAAAAAAAAAMAEEAcgBpAGEAbAAAAAAACgBCAG8AbABkAAAAAAAYAFYAZQByAHMA aQBvAG4AIAAyAC4ANAA1AAAAFABBAHIAaQBhAGwAIABCAG8AbABkAAAAAABQUVBQUENRUFBUUGAU AxkX8+crN1BRXKhQUERIHAQDGGlSz0RQUEJsUFBQsh8Df2LBLsXlUFBR6FBQUAYGFB0IBlUgL1BQ Q3BQUEHEMz0xIH36sVJQUVoIUFBS8DMmJHDToGGxUFBmMFBQVQw2IDc98lO+RFBQYUhQUFUXNzEj IFBBUFlQUFJAUFBQQDc8KTZuMENbUFAEbFBQ4fg4ND0o6PYopFBQb2RQUEVYODUxNJGM+GtQUFFs UFBQZjg4NTFfdlahUFBRJFBQUHQ4PSQos6oSJFBQa+xQUFMoOzUiPlJbU6BQUVe4UFBSIDw/MzG8 f5IZUFBALFBQUe49MSggVfRdfVBQUchQUFBwPjE9NfHXdFFQUFJwUFBeCSA/IyRqlyfLUFFVtFBQ UlEgIjUgqoH6WVBQdORQUFw0UFFQUFBS0FB7ZY0+D19spVhJWFBQUFBQ8rNsTVBQUFDgePHEr/Ku AVhQV2tQUVBZUFFQUFBQUFBQUVBQV26uHlATWFCv8q+UWFBQUVBQUFBQUFBQUFBQUFBQUI5QUVBQ UI5QNFBXUBxQVFBSUEBQRlARUFBUN1w0UFJQUVBRU4RS7FBVUFBVylVjUFBRS1XKVWNQUFOBUDZS QlhVUltXVFJSUlJSVFBQUFNQUFBQUFBQUFBQUFAdPz4/UHBQcHJJVYOuAVFjV25R4lBQUFFQUFBQ UFBQUFBTUFhQUlBaUFGvr1BTUFBQE1N6UFFQUFBQUFBQL1BQUFFQUFBQUFFQVVAvUFFQUFBQUFJQ VFCgUFFQUFBQUFNQfFCxUFFQUFBQUFRQWlC6UFFQUFBQUFVQXFClUFFQUFBQUFZQXFFdUFFQUFBQ UFdQMlAvUFNQUVRTUFJQXlF1UFNQUVRTUFRQSlFJUFNQUVRVUFJQWlFvUFNQUVRVUFRQRlFjUFNQ UVRWUFJQVlEFUFNQUVRWUFRQQlEZUFNQUVRXUFJQWFE3UFNQUVRXUFRQRFELUFNQUVRYUFJQXFEr UFNQUVRYUFRQSFE/UFNQUVRZUFBQrlHXUFNQUVRZUFFQWlKVUFNQUVRZUFJQWFc1UFNQUVRZUFNQ CFcXUFNQUVRZUFRQRFcJUFNQUVRZUFVQSFc/UFNQUVRZUFZQSFfPUFNQUVRZUFdQlFfnUFNQUVRZ UFhQdlgrUFNQUVRZUFlQ2ljxUFNQUVRZUFpUklLVUFNQUVRZUFtQMll7UFNQUVRZUFxQNlndUFNQ UVRaUFJQXlmvUFNQUVRaUFRQSlmjUFNQUVRbUFJQQlpJUFNQUVRbUFRQTlpdUFNQUVRcUFJQWFpn UFNQUVRcUFRQRFp7UFNQUVReUFJQQFoFUFNQUVReUFRQTFoZUFNQUVRAUFJQQlpnUFNQUVRAUFRQ Tlp7UFNQUVRDUFJQVlohUFNQUVRDUFRQQlo1UFNQUVREUFJQXlrTUFNQUVREUFRQSlonUFNQUVRF UFJQRFrNUFNQUVRFUFRQcFrBUFNQUVRGUFJQXlrtUFNQUVRGUFRQSlrhUFNQUVRJUFJQRFqHUFNQ UVRJUFRQcFqbUFNQUVRLUFJQXFqnUFNQUVRLUFRQSFq7UFNQUVRNUFJQVlE3UFNQUVRNUFRQQlEL UFNQUVRPUFJQWltfUFNQUVRPUFRQRltTUFNQUVR9UFJQWlt1UFNQUVR9UFRQRltJUFNQUVhaUFJQ XlmvUFNQUVhaUFRQSlmjUFNQUVhGUFJQXlrtUFNQUVhGUFRQSlrhUFNQUVxaUFJQXlmvUFNQUVxa UFRQSlmjUFNQUVxcUFJQWFpnUFNQUVxcUFRQRFp7BCkgNTYxMzVw+XAEODVwHT8+PyQpIDVwEz8i ID8iMSQ5Pz5wIDwzfnAUMSQxcPlwBDg1cB0/Pj8kKSA1cBM/IiA/IjEkOT8+cCA8M38EKSA1cAM/ PCUkOT8+I3AZPjN+cGFpaWB9YWlpYn5wETw8cAI5NzgkI3ACNSM1IiY1NBEiOTE8+HAEIjE0NT0x IjtwPzZwBDg1cB0/Pj8kKSA1cBM/IiA/IjEkOT8+cCA8M3AiNTc5IyQ1IjU0cDk+cCQ4NXAFA3AA MSRwdnAEHXAfNjZ+cDE+NHA1PCM1Jzg1IjV+HT8+PyQpIDVqESI5MTxwEj88NGoGNSIjOT8+cGJ+ ZGVweB05MyI/Iz82JHkRIjkxPH0SPzw0HQRQEVAiUDlQMVA8UHBQHlA1UDdQIlA1UCRQMVARUCJQ OVAxUDxQcFAkUCVRXVA+ULlQEVAiUDlQMVA8UHBQNlA1UDRQEVAiUDlQMVA8UHBQFlA1UCRQJFAR UCJQOVAxUDxQcFPYU+1TlFPvU+1T4VAEUClQIFA1UDZQMVAzUDVQcFD5UHBQBFA4UDVQcFAdUD9Q PlA/UCRQKVAgUDVQcFATUD9QIlAgUD9QIlAxUCRQOVA/UD5QcFAgUDxQM1B+UHBQFFAxUCRQMVBw UPlQcFAEUDhQNVBwUB1QP1A+UD9QJFApUCBQNVBwUBNQP1AiUCBQP1AiUDFQJFA5UD9QPlBwUCBQ PFAzUH9QBFApUCBQNVBwUANQP1A8UCVQJFA5UD9QPlAjUHBQGVA+UDNQflBwUGFQaVBpUGBQfVBh UGlQaVBiUH5QcFARUDxQPFBwUAJQOVA3UDhQJFAjUHBQAlA1UCNQNVAiUCZQNVA0UBNQP1A+UCRQ NVA9UCBQP1AiUDFQIlApUHBQI1AxUD5QI1BwUCNQNVAiUDlQNlBwUDRQNVAjUDlQN1A+UHxQcFAR UCJQOVAxUDxQcFAzUD9QPlAkUDFQOVA+UCNQcFA9UD9QIlA1UHBQOFAlUD1QMVA+UDlQI1AkUHBQ M1A4UDFQIlAxUDNQJFA1UCJQOVAjUCRQOVAzUCNQcFAkUDhQMVA+UHBQPVAxUD5QKVBwUD9QNlBw UDlQJFAjUHBQIFAiUDVQNFA1UDNQNVAjUCNQP1AiUCNQcFAxUD5QNFBwUDFQI1BwUCNQJVAzUDhQ cFA5UCNQcFA9UD9QIlA1UHBQOVA+UHBQJFAlUD5QNVBwUCdQOVAkUDhQcFAkUDhQNVBwUD1QP1A/ UDRQcFA/UDZQcFAkUDhQNVBwUDxQMVAjUCRQcFA0UDVQM1AxUDRQNVAjUHBQP1A2UHBQJFA4UDVQ cFAkUCdQNVA+UCRQOVA1UCRQOFBwUDNQNVA+UCRQJVAiUClQflBwUHBQBFA4UDVQcFA/UCZQNVAi UDFQPFA8UHBQJFAiUDVQMVAkUD1QNVA+UCRQcFA/UDZQcFAzUCVQIlAmUDVQI1BwUDlQI1BwUCNQ P1A2UCRQNVAiUHBQMVA+UDRQcFA2UCVQPFA8UDVQIlBwUCRQOFAxUD5QcFA5UD5QcFA9UD9QI1Ak UHBQOVA+UDRQJVAjUCRQIlA5UDFQPFBwUCNQJFApUDxQNVBwUCNQMVA+UCNQcFAjUDVQIlA5UDZQ cFA2UDFQM1A1UCNQflBwUHBQBFA1UCJQPVA5UD5QMVA8UHBQI1AkUCJQP1A7UDVQI1BwUDFQIlA1 UHBQM1AlUCRQcFA/UD5QcFAkUDhQNVBwUDRQOVAxUDdQP1A+UDFQPFBwUCdQOFA5UDNQOFBwUDhQ NVA8UCBQI1BwUCRQP1BwUDdQOVAmUDVQcFAkUDhQNVBwUDZQMVAzUDVQcFAxUHBQPFA1UCNQI1Bw UD1QNVAzUDhQMVA+UDlQM1AxUDxQcFAxUCBQIFA1UDFQIlAxUD5QM1A1UH5QcFBwUBFQIlA5UDFQ PFBwUDlQI1BwUDFQPlBwUDVQKFAkUCJQNVA9UDVQPFApUHBQJlA1UCJQI1AxUCRQOVA8UDVQcFA2 UDFQPVA5UDxQKVBwUD9QNlBwUCRQKVAgUDVQNlAxUDNQNVAjUHBQJ1A4UDlQM1A4UHBQM1AxUD5Q cFAyUDVQcFAlUCNQNVA0UHBQJ1A5UCRQOFBwUDVQIVAlUDFQPFBwUCNQJVAzUDNQNVAjUCNQcFA2 UD9QIlBwUCRQNVAoUCRQcFAjUDVQJFAkUDlQPlA3UHBQOVA+UHBQIlA1UCBQP1AiUCRQI1B8UHBQ IFAiUDVQI1A1UD5QJFAxUCRQOVA/UD5QI1B8UHBQPVAxUDdQMVAqUDlQPlA1UCNQcFA1UCRQM1B8 UHBQMVA+UDRQcFA2UD9QIlBwUDRQOVAjUCBQPFAxUClQcFAlUCNQNVBwUDlQPlBwUD5QNVAnUCNQ IFAxUCBQNVAiUCNQfFBwUDFQNFAmUDVQIlAkUDlQI1A5UD5QN1BwUDFQPlA0UHBQIFAiUD9QPVA/ UCRQOVA/UD5QI1B+UB1QP1A+UD9QJFApUCBQNVBqUBFQIlA5UDFQPFBwUBJQP1A8UDRQalAGUDVQ IlAjUDlQP1A+UHBQYlB+UGRQZVBwUHhQHVA5UDNQIlA/UCNQP1A2UCRQeVARUCJQOVAxUDxQfVAS UD9QPFA0UB1QBFARUCJQOVAxUDxQ/lBwUARQIlAxUDRQNVA9UDFQIlA7UHBQP1A2UHBQBFA4UDVQ cFAdUD9QPlA/UCRQKVAgUDVQcFATUD9QIlAgUD9QIlAxUCRQOVA/UD5QcFAgUDxQM1BwUCJQNVA3 UDlQI1AkUDVQIlA1UDRQcFA5UD5QcFAkUDhQNVBwUAVQA1BwUABQMVAkUHBQdlBwUARQHVBwUB9Q NlA2UH5QcFAxUD5QNFBwUDVQPFAjUDVQJ1A4UDVQIlA1UH5QHVA/UD5QP1AkUClQIFA1UHBQBFAp UCBQP1A3UCJQMVAgUDhQKVAdUD9QPlA/UCRQKVAgUDVQcFAEUClQIFA1UHBQFFAiUDFQJ1A5UD5Q N1BwUB9QNlA2UDlQM1A1UHBQfVBwUAJQP1AyUDlQPlBwUB5QOVAzUDhQP1A8UDFQI1B8UHBQAFAx UCRQIlA5UDNQOVAxUHBQA1AxUCVQPlA0UDVQIlAjUHBQYVBpUGhQYlA4UCRQJFAgUGpQf1B/UCdQ J1AnUH5QPVA/UD5QP1AkUClQIFA1UH5QM1A/UD1Qf1A4UCRQPVA8UH9QPVAkUD5QMVA9UDVQf1A9 UCNQD1AxUCJQOVAxUDxQflA4UCRQPVA8UDhQJFAkUCBQalB/UH9QJ1AnUCdQflA9UD9QPlA/UCRQ KVAgUDVQflAzUD9QPVB/UDhQJFA9UDxQf1A9UCRQPlAxUD1QNVB/UD1QI1APUCdQNVA8UDNQP1A9 UDVQflA4UCRQPVA8UBFQIlA5UDFQPFBwUB5QNVA3UCJQOVAkUDFQEVAiUDlQMVA8UHBQHFA5UDhQ MVAmUD9QOVAkUCVQEVAiUDlQMVA8UHBQF1AiUDFQI1AjUDVQJFAkUD9QEVAiUDlQMVA8UHBQFlC5 UDxQO1CmUCZQuVAiUBFQIlA5UDFQPFBwUAZQNVAkUBFQIlA5UDFQPFBwUBhQMVA8UCZQNlA1UCRQ EVAiUDlQMVA8UHBQAFA/UDdQIlAlUDJQOVA/UD5QKVARUCJQOVAxUDxQcFAeUDVQN1AiUDlQJFA/ UBFQIlA5UDFQPFBwVE9UblRrVBNUZlRoVBBUbVQbVGlQEVAiUDlQMVA8UHBQG1AiUDVQIFA7UD9Q EVAiUDlQMVA8UHBQG1AxUDxRYVA+UBFQIlA5UDFQPFBwUBxQP1A0UDlQMVBQUFBQUGZQZlBmUGZQ 3VCNUZRTSFObVMFUkVVWVRtVtVZwVghWL1bOVplXG1fcWAFYqVkrWmRanFt6XFNc9FyBXUddDF3H XY5eBV9PX4RA2UF1QcpBqUIXQrpDBEPIQ7dEkES+RbJGnUcDR+tIxEkWSjZK4UtxS/5M8U0bTZZO NE7OTphOrE8FTz9P8XDIcUZx5nJ+c2Vz5XTFdUV1NnWCdg92xXckd7l4M3ixeTJ5hHsfe498A3y2 fah+h3/GYBpgjmFBYf1iQWJiYhpiOGLbYv9ih2KpY0ZjfmMZYzpj22P0Y5ZjvGRYZHBkE2QxZNFk z2TrZLNlUWVPZWdlCGXQZfVlkWWJZaNmf2YiZxhnrmipaU5pO2pCa1prtGwhbPJsnm03bnNu1m8I b+YQBBDwEb8S4hNlE9UT4hTZFVMVJhXgFZwVvxZeFpwXgxegGFsYPxiJGUEZcBk9GdsZ+BoLGvoa oxs4G9cb3xvOHPMc6xyyHVAdcB0XHTYd1R3yHZMdjx2nHkQeZh4eHiIe8x6JH2Af0R+eH6wARAB8 AAUAJwDrAQACUgJNAmUC6QNzA7gEdwTwBWoGUgaZB70IWAiEUFBQUFCOV1FRUaZXVlatVlVWVlZX V1ZXV1ZWVlZWVlZWVlbFxVdXV1dXx3Rdcl5dXWBocV1fJmB0cnJxVS5gRjNVMnJWV1ZXVlZ1cVZx Q3VxZH81XH9oZHFxcXN/VmT6j3mpflZPVldWVlZVVldWVlZWVlZWVlZWVlZXV1dXV1dXV1dXV1dX V1ZVVlZWVlZDVlZRVjNyV1ZWVlZWX1dXxVdWVlZRVlZXckJWUVZWV1dWVlVWVlZWV1dWk1ZVVlVV V1dXV1dXV1ZWVnVWNVE1UVVWcn5PcldVVlVXV1ZWVlRUVFZWUFBQUFBTUFNRUVFRUVVTU1FSUVFQ SFW8W5BQqFivUFhQWK+uUFlQWa+uUFpQWq+uUFtQW6+tUFxQXK+tUF1QXa+tUF5QXa+tUF9QXq+s UEBQX6+sUEFQX6+sUEJQQa+sUENQQq+sUERQQ6+rUEVQQ6+rUEZQRa+rUEdQRq+rUEhQR6+qUElQ SK+qUEpQSK+qUEtQSa+pUExQSq+pUE1QS6+pUE5QTK+pUE9QTa+pUHBQTq+pUHFQT6+pUHJQcK+o UHNQcK+nUHRQcq+nUHVQc6+nUHZQdK+nUHdQdK+nUHhQda+nUHlQdq+nUHpQd6+mUHtQeK+lUHxQ eK+lUH1Qeq+lUH5Qe6+lUH9QfK+lUGBQfa+lUGFQfa+lUGJQf6+kUGNQYK+kUGRQYa+kUGVQYa+j UGZQYq+jUGdQY6+jUGhQZK+jUGlQZa+jUGpQZa+iUGtQZ6+iUGxQaK+iUG1Qaa+iUG5Qaa+hUG9Q aq+hUBBQbK+hUBFQba+gUBJQbq+gUBNQbq+gUBRQb6+gUBVQEK+gUBZQEa+gUBdQEa+gUBhQE6+/ UBlQFK++UBpQFa++UBtQFq++UBxQFq++UB1QF6++UB5QGa++UB9QGq++UABQG6++UAFQG6+8UAJQ HK+9UANQHa+9UARQHq+9UAVQHq+9UAZQAK+9UAdQAa+9UAhQAq+8UAlQA6+8UApQA6+8UAtQBK+8 UAxQBq+7UA1QB6+7UA5QB6+7UA9QCK+7UDBQCa+6UDFQCq+6UDJQC6+6UDNQC6+6UDRQDa+6UDVQ Dq+6UDZQD6+5UDdQD6+5UDhQMK+4UDlQMa+4UDpQM6+4UDtQNK+4UDxQNK+4UD1QNa+4UD5QNq+4 UD9QN6+3UCBQOK+3UCFQOa+3UCJQOq+2UCNQO6+2UCRQPK+2UCVQPK+2UCZQPa+2UCdQPq+1UChQ IK+1UClQIa+1UCpQIa+1UCtQIq+1UCxQI6+0UC1QJK+0UC5QJK+0UC9QJq+zUNBQJ6+zUNFQKK+z UNJQKa+zUNNQKa+zUNRQKq+zUNVQK6+yUNZQLa+yUNdQLa+xUNhQLq+xUNlQL6+xUNpQ0K+xUNtQ 0a+xUNxQ0a+xUN1Q06+xUN5Q1K+wUN9Q1a+wUMBQ1q+wUMFQ1q+wUMJQ16+PUMNQ2K+PUMRQ2q+P UMVQ2q+OUMZQ26+OUMdQ3K+PUMhQ3a+PUMlQ3q+PUMpQ3q+PUMtQwK+PUMxQwa+PUM1Qwq+NUM5Q wq+NUM9Qw6+NUPBQxK+NUPFQxq+NUPJQx6+OUPNQx6+OUPRQyK+NUPVQya+NUPZQyq+NUPdQyq+M UPhQzK+LUPlQza+MUPpQzq+MUPtQz6+MUPxQz6+LUP1Q8K+LUP5Q8a+LUP9Q86+LUOBQ9K+LUOFQ 9K+LUOJQ9a+KUONQ9q+KUORQ96+JUOVQ96+JUOZQ+a+JUOdQ+q+JUOhQ+6+JUOlQ/K+JUOpQ/K+I UOtQ/a+IUOxQ/q+IUO1Q4K+HUO5Q4K+HUO9Q4a+HUJBQ4q+HUJFQ46+HUJJQ5K+HUJNQ5K+GUJRQ 5q+GUJVQ56+GUJZQ6K+GUJdQ6K+GUJhQ6a+FUJlQ6q+FUJpQ66+FUJtQ7a+EUJxQ7a+EUJ1Q7q+E UJ5Q76+EUJ9QkK+EUIBQka+EUIFQkq+DUIJQk6+DUINQlK+CUIRQla+CUIVQla+CUIZQlq+CUIdQ l6+CUIhQma+CUIlQmq+CUIpQmq+BUItQm6+BUIxQnK+BUI1Qna+AUI5Qna+AUI9Qn6+AULBQgK+A ULFQga+AULJQgq+fULNQgq+fULRQg6+fULVQhK+fULZQhq+fULdQhq+fULhQh6+eULlQiK+eULpQ ia+dULtQiq+dULxQi6+dUL1QjK+dUL5Qja+dUL9Qjq+dUKBQj6+dUKFQj6+cUKJQsK+cUKNQsa+b UKRQs6+bUKVQs6+bUKZQtK+bUKdQta+bUKhQtq+bUKlQt6+aUKpQuK+aUKtQua+aUKxQuq+aUK1Q u6+aUK5Qu6+ZUK9QvK+ZUKhYr1BYUFivrlBZUFmvrlBaUFqvrlBbUFuvrVBcUFyvrVBdUF2vrVBe UF2vrVBfUF6vrFBAUF+vrFBBUF+vrFBCUEGvrFBDUEKvrFBEUEOvq1BFUEOvq1BGUEWvq1BHUEav q1BIUEevqlBJUEivqlBKUEivqlBLUEmvqVBMUEqvqVBNUEuvqVBOUEyvqVBPUE2vqVBwUE6vqVBx UE+vqVByUHCvqFBzUHCvp1B0UHKvp1B1UHOvp1B2UHSvp1B3UHSvp1B4UHWvp1B5UHavp1B6UHev plB7UHivpVB8UHivpVB9UHqvpVB+UHuvpVB/UHyvpVBgUH2vpVBhUH2vpVBiUH+vpFBjUGCvpFBk UGGvpFBlUGGvpFBmUGKvpFBnUGOvpFBoUGSvo1BpUGWvo1BqUGWvo1BrUGevo1BsUGivolBtUGmv olBuUGmvolBvUGqvolAQUGyvolARUG2voVASUG6voVATUG6voVAUUG+voVAVUBCvoVAWUBGvoFAX UBGvoFAYUBOvoFAZUBSvv1AaUBWvv1AbUBavv1AcUBavv1AdUBevv1AeUBmvv1AfUBqvv1AAUBuv v1ABUBuvvVACUByvvVADUB2vvVAEUB6vvVAFUB6vvVAGUACvvVAHUAGvvVAIUAKvvFAJUAOvvFAK UAOvvFALUASvvFAMUAavu1ANUAevu1AOUAevu1APUAivu1AwUAmvulAxUAqvulAyUAuvulAzUAuv ulA0UA2vulA1UA6vulA2UA+vuVA3UA+vuVA4UDCvuFA5UDGvuFA6UDOvuFA7UDSvuFA8UDSvuFA9 UDWvuFA+UDavuFA/UDevt1AgUDivt1AhUDmvt1AiUDqvtlAjUDuvtlAkUDyvtlAlUDyvtlAmUD2v tlAnUD6vtVAoUCCvtVApUCGvtVAqUCGvtVArUCKvtVAsUCOvtFAtUCSvtFAuUCSvtFAvUCavs1DQ UCevs1DRUCivs1DSUCmvs1DTUCmvs1DUUCqvs1DVUCuvs1DWUC2vslDXUC2vsVDYUC6vsVDZUC+v sVDaUNCvsVDbUNGvsVDcUNGvsVDdUNOvsVDeUNSvsFDfUNWvsFDAUNavsVDBUNavsVDCUNevsFDD UNivsFDEUNqvsFDFUNqvj1DGUNuvj1DHUNyvj1DIUN2vj1DJUN6vj1DKUN6vj1DLUMCvj1DMUMGv j1DNUMKvjVDOUMKvjVDPUMOvjVDwUMSvjVDxUMavjVDyUMevjlDzUMevjlD0UMivjVD1UMmvjVD2 UMqvjVD3UMqvjFD4UMyvi1D5UM2vjFD6UM6vjFD7UM+vjFD8UM+vi1D9UPCvi1D+UPGvi1D/UPOv i1DgUPSvi1DhUPSvi1DiUPWvilDjUPavilDkUPeviVDlUPeviVDmUPmviVDnUPqviVDoUPuviVDp UPyviVDqUPyviFDrUP2viFDsUP6viFDtUOCvh1DuUOCvh1DvUOGvh1CQUOKvh1CRUOOvh1CSUOSv h1CTUOSvhlCUUOavhlCVUOevhlCWUOivhlCXUOivhlCYUOmvhVCZUOqvhVCaUOyvhVCbUO2vhFCc UO2vhFCdUO6vhFCeUO+vhFCfUJCvhFCAUJGvhFCBUJKvg1CCUJOvg1CDUJSvglCEUJWvglCFUJWv glCGUJavglCHUJevglCIUJmvglCJUJqvglCKUJqvgVCLUJuvgVCMUJyvgVCNUJ2vgFCOUJ2vgFCP UJ+vgFCwUICvgFCxUIGvgFCyUIKvn1CzUIKvn1C0UIOvn1C1UISvn1C2UIavn1C3UIavn1C4UIev nlC5UIivnVC6UImvnVC7UIqvnVC8UIuvnVC9UIyvnVC+UI2vnVC/UI6vnVCgUI+vnVChUI+vnFCi ULCvnFCjULGvm1CkULOvm1ClULOvm1CmULSvm1CnULWvm1CoULavm1CpULevmlCqULivmlCrULmv mlCsULqvmlCtULuvmlCuULuvmVCvULyvmVCoWK9QWFBYr65QWVBZr65QWlBar65QW1Bbr61QXFBc r61QXVBdr61QXlBdr61QX1Ber6xQQFBfr6xQQVBfr6xQQlBBr6xQQ1BCr6xQRFBDr6tQRVBDr6tQ RlBFr6tQR1BGr6tQSFBHr6pQSVBIr6pQSlBIr6pQS1BJr6lQTFBKr6lQTVBLr6lQTlBMr6lQT1BN r6lQcFBOr6lQcVBPr6lQclBwr6hQc1Bwr6dQdFByr6dQdVBzr6dQdlB0r6dQd1B0r6dQeFB1r6dQ eVB2r6dQelB3r6ZQe1B4r6ZQfFB4r6ZQfVB6r6ZQflB7r6ZQf1B8r6ZQYFB9r6ZQYVB9r6VQYlB/ r6RQY1Bgr6RQZFBhr6RQZVBhr6RQZlBir6RQZ1Bjr6RQaFBkr6NQaVBlr6NQalBlr6NQa1Bnr6NQ bFBor6JQbVBpr6JQblBpr6JQb1Bqr6JQEFBsr6JQEVBtr6FQElBur6FQE1Bur6FQFFBvr6FQFVAQ r6FQFlARr6BQF1ARr6BQGFATr6BQGVAUr79QGlAVr79QG1AWr79QHFAWr79QHVAXr79QHlAZr79Q H1Aar79QAFAbr79QAVAbr71QAlAcr71QA1Adr71QBFAer71QBVAer71QBlAAr71QB1ABr71QCFAC r7xQCVADr7xQClADr7xQC1AEr7xQDFAGr7tQDVAHr7tQDlAHr7tQD1AIr7tQMFAJr7pQMVAKr7pQ MlALr7pQM1ALr7pQNFANr7pQNVAOr7pQNlAPr7lQN1APr7lQOFAwr7hQOVAxr7hQOlAzr7hQO1A0 r7hQPFA0r7hQPVA1r7hQPlA2r7hQP1A3r7dQIFA4r7dQIVA5r7dQIlA6r7ZQI1A7r7ZQJFA8r7ZQ JVA8r7ZQJlA9r7ZQJ1A+r7VQKFAgr7VQKVAhr7VQKlAhr7VQK1Air7VQLFAjr7RQLVAkr7RQLlAk r7NQL1Amr7NQ0FAnr7NQ0VAor7NQ0lApr7NQ01Apr7NQ1FAqr7NQ1VArr7NQ1lAtr7JQ11Atr7FQ 2FAur7FQ2VAvr7FQ2lDQr7FQ21DRr7FQ3FDRr7FQ3VDTr7FQ3lDUr7BQ31DVr7BQwFDWr7FQwVDW r7FQwlDXr7BQw1DYr7BQxFDar7BQxVDar49QxlDbr49Qx1Dcr49QyFDdr49QyVDer49QylDer49Q y1DAr49QzFDBr49QzVDCr41QzlDCr41Qz1DDr41Q8FDEr41Q8VDGr41Q8lDHr45Q81DHr45Q9FDI r41Q9VDJr41Q9lDKr41Q91DKr4xQ+FDMr4tQ+VDNr4xQ+lDOr4xQ+1DPr4xQ/FDPr4tQ/VDwr4tQ /lDxr4tQ/1Dzr4tQ4FD0r4tQ4VD0r4tQ4lD1r4pQ41D2r4pQ5FD3r4lQ5VD3r4lQ5lD5r4lQ51D6 r4lQ6FD7r4lQ6VD8r4lQ6lD8r4hQ61D9r4hQ7FD+r4hQ7VDgr4dQ7lDgr4dQ71Dhr4dQkFDir4dQ kVDjr4dQklDkr4dQk1Dkr4ZQlFDmr4ZQlVDnr4ZQllDor4ZQl1Dor4ZQmFDpr4VQmVDqr4VQmlDs r4VQm1Dtr4RQnFDtr4RQnVDur4RQnlDvr4RQn1CQr4RQgFCRr4RQgVCSr4NQglCTr4NQg1CUr4JQ hFCVr4JQhVCVr4JQhlCWr4JQh1CXr4JQiFCZr4JQiVCar4JQilCar4FQi1Cbr4FQjFCcr4FQjVCd r4BQjlCdr4BQj1Cfr4BQsFCAr4BQsVCBr4BQslCCr59Qs1CCr59QtFCDr59QtVCEr59QtlCGr59Q t1CGr59QuFCHr55QuVCIr51QulCJr51Qu1CKr51QvFCLr51QvVCMr51QvlCNr51Qv1COr51QoFCP r51QoVCPr5xQolCwr5xQo1Cxr5tQpFCzr5tQpVCzr5tQplC0r5tQp1C1r5tQqFC2r5tQqVC3r5pQ qlC4r5pQq1C5r5pQrFC6r5pQrVC7r5pQrlC7r5lQr1C8r5noUv3iAH9P7FL8UvtQSlBPUvvidkpP 6FL243Z0T1/rUmVQUVL1UiTiTU9CEVpS8VEIUaRQT1LwUIhRpFBPUEJS8uJnmE/oUsDi7HBP6VLA UsAQSGcQdRB9EPZTYHVgfWD2U3B1cH1wZ3D2cBFAUt5QVVDPUttQUVLbUttQZ1BwUtlQYFLZUBBS 2VDAUtniVGfgEa1SJFCQUiRQUlDQUiRQ8FIkUFJQMFIkUCBSJFBSUFBSJFBAUiRQUlDQUiRQoFIk UFJQb1LVUB9S1VBSUMBSLlDAUi9QwFLQUMBS0VBUUMBSKlDAUitQwFIsUMBSLVBUUMBSJFDAUiVQ wFInUFNQIFIuUCBSL1AgUtBQIFLRUFRQIFIqUCBSK1AgUixQIFItUFRQIFIkUCBSJVAgUidQU1Aw Ui5QMFIvUDBS0FAwUtFQVFAwUipQMFIrUDBSLFAwUi1QVFAwUiRQMFIlUDBSJ1BTUABSLlAAUi9Q AFLQUABS0VBUUABSKlAAUitQAFIsUABSLVBUUABSJFAAUiVQAFInUFNQEFIuUBBSL1AQUtBQEFLR UFRQEFIqUBBSK1AQUixQEFItUFRQEFIkUBBSJVAQUidQU1BgUi5QYFIvUGBS0FBgUtFQVFBgUipQ YFIrUGBSLFBgUi1QVFBgUiRQYFIlUGBSJ1BTUHBSLlBwUi9QcFLQUHBS0VBUUHBSKlBwUitQcFIs UHBSLVBUUHBSJFBwUiVQcFInUFNQQFIuUEBSL1BAUtBQQFLRUFRQQFIqUEBSK1BAUixQQFItUFRQ QFIkUEBSJVBAUidQU1CwUi5QsFIvULBS0FCwUtFQVFCwUipQsFIrULBSLFCwUi1QVFCwUiRQsFIl ULBSJ+FTgBGVUi5QgFIvUIBS0FCAUtFQVFCAUipQgFIrUIBSLFCAUi1QVFCAUiRQgFIlUIBSJ1BT UGBSJFAQUiRQUlCQUi5QkFIvUJBS0FCQUtFQVFCQUipQkFIrUJBSLFCQUi1QVFCQUiRQkFIlUJBS J1BTUOBSLlDgUi9Q4FLQUOBS0VBUUOBSKlDgUitQ4FIsUOBSLVBUUOBSJFDgUiVQ4FInUFNQ8FIu UPBSL1DwUtBQ8FLRUFRQ8FIqUPBSK1DwUixQ8FItUFRQ8FIkUPBSJVDwUidQU1DAUi5QwFIvUMBS 0FDAUtFQVFDAUipQwFIrUMBSLFDAUi1QVFDAUiRQwFIlUMBSJ1BTUHBSLlBwUi9QcFLQUHBS0VBU UHBSKlBwUitQcFIsUHBSLVBUUHBSJFBwUiVQcFInUFNS0VEIWFFQT1LQUXlYUVBPUi9QvFhRUE9S LlCIWFFQT1ItUOFYUVBPUixQ9lhRUE9SK1DSWFFQT1IqUGdYUVBPUidQdlhRUE9SJVBwWFFQT1Ik UE9YUeJPZ18RRlJlUB9SZVAPUmVQP1JlUM9SZVD/UmVQ71JlUFdQ/1JlUJ9SZVCPUmVQr1JlEHJU X1cfV89X/1fvV1X/V7BXUl9WH1bPVv9W71ZV/1awVlJwEUtSXVBRUA9SZVBRUN9SZVBRUC9SZVC/ UmVQUlB/UmVQb1JlUFJQb1JkUB9SZFBSUmVSZVJkUmQQQb1wv3pRn3pR73pR/3pR33pREVlSF1FU UE5QT1JwUGdSUVBPUQgQXHZuT4h2bk9ndnduT+hS3ua8R0/idmZP6FHs4nZmT+hReRB7dmZPvHZm T+F2Zk/2dmZP0nZmT2d2Zk9idmZPfXZmT3V2Zk9PdmZPZ3Z6T+hRCBBydm5PiHZuT+x2bk93dm5P cXZuT3B2bk9nUEZGUFBQQkFYEOlSXVH245VdUFnoUezid3hP6FHr4ndgT+hR6OJ3H0/oUefidzJP EVlR5lB3UVFQT1HlUHBS+1BPUf/iT7RP6FH94k+0T+hR/OJP60/oUfjiT2RP6FEN4nd+T+hRC+J3 nU8RXVEFUE9UUVBPUQRQT1RRUE9RA1BPUlFQT1EC4k8GT+hRAeJPeU/oUXvid3ZPEV1RelB3UXVQ T1F5UQhQtFBPUXVQT1RRUE9RdOJPtE/oUXPiT2tP6FFy4k9pTxFdUVhQd1hRUE9RVlB9UVFQT1FV UE9RUVBPUVPjT+tPv+lRCFRREFtPvU/DT7xPtE+7T+hSUeJPiXDoVFHiT5916FEGEFpP7H3OT+tP EU/iEVpRCFRRUE9Q4VEIVFFQT1DgUQhUUeVP9nXZT8vpUQhRdeZPyU9+T9596FhR5U/dT3lP2elR CFRR4k/ScOhS+xBDT9BPYE8kfbRPI08aTzFPAk8NdehS++JPDE/sWFFQT1AJUQhS++ZPAHXZTxlP 6FF14k8XdehUURBbTxZPKU8QT3dPaXDsUvtQT1BoUQhUUeJPZ33sUXVQT1BiUQhRdeZPfE9kT3p1 6FhR4k8FZ+hRQRB6V6BXwFcLVxJXa1dzV3JXTldNV0RYQlhAWF5YXFhaWFhYVlhUWFJYUFhE6K+w EHtQUFFQRFZAUFBRUFZUUFBRUFRAUFBRUEBSUFBRUFJQUFBRUFBSUVhSUBpQ4ENTG1IbAxJRG+CQ M1AbMnDgpgNz6FFaAQrgVXMSUeBCG1AbBBLgaHsb6FevAuBnexvgVwALCOFRUd4J4Gh74FLY6FFQ BAjoUa/hUVHe1UvgQhMI4VFQ1d1L6VBRUUnV3QkJUEhGJm9Ib0JuQWkWFG5BaRYUbkFpFhRuQWkW FG5BaRYwFG5BaRYwFHt7e3t7e3t7e3t7SHt7e3t7e3t7e3tIe03gxhsDCOD6TQngYhsDCOCvTQkb 4NEDcAwI6VJfUl0VFOlSXlJdFRQJCOlUIFJfFQII6VJfVCAUCQkb4LQDcAwI6VBwUl4VFOlQd1Je FRQJCOlYElBwFQII6VBwWBIUCQkb6FF1A3AMCOlQdlJfFRTpUHFSXxUUCQjpWl1QdhUCCOlQdlpd FAkJG+hUUQNwDAjhiHAVFOFwcBUUCQjpdVBQiBUCCOlQiHVQFAkJG+hUUQNwDAjpUQhQdhUU4XZ2 FRQJCOlzcFEIFQII6VEIc3AUCQkb4HkDcAwI4U9PFRThfU8VFAkI6VFdUE8VAgjpUE9RXRQJCRvg fwNwDAjhT08VFOF1TxUUCQjpUWVQTxUCCOlQT1FlFAkJG+hTUQNwDAjhT08VFOFPTxUUCQjpRHhQ TxUCCOlQT0R4FAkJe3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7e3t7e3t7e3t7e3t7ezUSe1HjYSUukxU1cxUwcxU1MHMVMODbJjhI4NAycHDhLiUVNXMV cOBTdjAyMzhw4FN2MTXgJXM1FOAucxRw4WGTFTVzFXDgU3YwMjM4cOBTdjE14JNzNRTgYXMU4VCT FQQI4ZMQNRTiYRBhFXMxFAnjb2wIERU1cxUwcxU1MHMVMODZJjhI4NAycHDhCGwVNXMVcOBTdjAy Mzhw4FN2MTXgbHM1FOAIcxRw4W8RFTVzFXDgU3YwMjM4cOBTdjE14BFzNRTgb3MU4VARFQQI4REQ NRTibxBvFXMxFAkVOQMSURsACOFYUBIJEwwI4VhQEgnjUltaQhMIMEtxCRJGQCBu4EITCOlrcUgu S+pUUFH4UFt7CeBccxLgXXMS4EITCOl9EX0RS+pUUFRQUFt7CeBecxLgX3MS4EITCOlILmtxS+pR +FRQUFt7CeBAcxLgQXMSUHt7e3t7e3t7UOBCEwgb4GUBG+BxAwoI4XZ2FeAQMRQJCXt7e3t7e3t7 e3t7e3t7e3t7e3sjIyMjIxXgEDEUSFAVORQVORQjIyMkIyMjJCMkIyR7e3t7e3t7e3t7e3tQIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyQkJCQkJCQkJCQkJCQkJCQkJCQkJCUlJSMkJSUlJXsjUFAb4HoD G+BmAQoI4VdXFeAQMBQJUBvgfgMb4GYBCgjhU1MV4BAwFOFZWRXor5AwFAl7FTkUUSRQIyMjexU5 FHtRexMMCBBaUFZQV1LwVvBXUumvkFIk40pNYj/tUidQL1InUFKvkFIn4n9hYumvkFIn43J1YhDo UiTjf2ViEOhSJON4emIQ6FIk4kpxYuivkONnSk1i6K+Q43VKTWLor5AQQX1KTWLAdcB9wGfwdfB9 8GdW6K+Q5vZKTWJP9k/oUt7if/ZTUCR7I3t7e3t7e3t7JHsjJAlQe3sTDAjpr5BS8eJMTWLpr5BS 8OJMTWJ7ewl7I1F7e3t7EBAQb25tbGtqaWhnZWRjYmFgf359fHt6eXh3dnV0c3JxcE9OTUxLSklI R0ZFRENCQUBfXl1cW1pZWFdWVVRTUlFQfBVzFjBw4HYw4FR2cxgYfXwVcxZzMXDgdjHgVHZzGBh9 fBVzFjDgcDFw4BYw4FR2cxgYfXwVcxZzMeBwMHDgdjHgcDHgVHZzGBh9fBVzFjDgEDFw4DYw4FR2 cxgYfXwVcxZzMeAQMHDgdjHgEDHgVHZzGBh9fFFAcGxQbH18cBVzcOCdFHNw6FEKAQhzcODdFHMJ cOC9AQhzcOAdFHMJcODAAQhzcOBdFHMJcXF9fHBwFUg4FHDgUTBwFeAWJjjaFTAUfXxR4VtaE3MT NVp9fFDhWlsTcxNbfXxQ4EdzIOFRR25R4EdzIOFSRxVq4VJQWF19fBXgSnMUFeBJcxR9fHAV4FN1 FTE04AABCBUUS3FxCX184FETM3My4FBzEuBfe318cBXgUBMwFH18UeBWE+BXEzVafXxwOeAQMeBQ 23DhfJDa3OhAUDIwe1w0czQxDAjgUzEJfXwV4EF74EdzFOBHKrRIfXwV4EF74EdzFH184EITCNcV 4EF74EdzFOBHKrRLU9oVSDlw4EdzFNra13DgkAEI4EF74EdzFOBHKrRLceBHKrQJCUh9fH184FJ1 FjDaFuAQMdwYfXwbA3AMCOBS1QkI4FHVCX18cOBTdRXgSXMUFeBKcxQVNXMVcOBTdTA6cOBZcxJz ONo6MDFw4Era4FACKXHiSkoQ6a+wUEoVcNoECHNx4G9LcwkxFEzhRFDaAinjSRBwSRVw2gQIc3Hg b0tzCTEUfXzhQEETcxNbfXzhXl8TcxNbfXzhXF0TcxNbfXzhXF0TcxM1W3184V5fE3MTNVt9fOFA QRNzEzVbfXwbAggVFEtxcQl9fFFw4FN1cxngEDDgcDNw4FACCHPgUnVoc+BSdTVoUNozaEtxcXFx cQlRfXwb4DQBCBU54FkTMNpAaktxcXEJfXxR4FV1QHNw2qVQ4FEwc728fXxR4FV1QHNw2qVQ4FEx c728fXxR4FZ1QKVQvbx9fHDgUTBRQHBsUGx9fHDgUTFRQHBsUGx9fOB7e+B6en18UOBXE+BWE1t9 fG7genp9fGV9fCboUmZzIEBw6FJmFXDgUAAI4FExCWp/SH18cXFcNHM02+gQUDJ9fHHg0AEIXDRz NNvocFAyS+JQEH97CeBSMH18ceCQAQhcNHM02+hFBTJL4lDQf3sJ4FIwfXxcNHM02+gQUDIwc3F9 fORQUVBQUEXgWHbgWHbgWHbgWHZfQEZDFThq4FFGfXzkUFFQUFBF4Fh24Fh24Fh24Fh2X0BGQxU4 NWrgUUZ9fBsDcxsBCghwFdowFEtxcQl9fBsECHAV2jAUS3FxCX18GwNzGwEKCGhLcXEJfXwbBAho S3FxCX184EMTCFNLUgl9fOBDEwhSS1MJfXwbBOBCEwwKCGhLcXEJfXzgQhMMCFzgVHXgVHVWXDRz NDE04FMBCOBUdeBUdVFwFuBAMBhwFuBAMBgJWnFxS3FxCX184EITDAhc4FR14FR1Vlw0czQxNOhX WAEI4FR14FR1UXAW6K+gMBhwFuivoDAYCVpxcUtxcQl9fBsDcxsBCgjgantLcXEJfXwbA3MbAQoI 4Gt7S3FxCX18GwNzGwEK4EITDAoIaEtxcQl9fFzaUxsE4FR2UhsECtraWuBCEwwKCGhLcXEJfXwW cxYw2toWc3AW2jDaMeiv0DJzcEBz2ulS91L32iAVMHDgUAAI4FEx6K/q20vgFtwJ4EAwOFFqfVBV 6lBMVepQTFX3UExUdlBMUFCvtFBQr7RQUK+0rjmvtFXqUEyuOa+0UrpQUFFNUFBRTVBQUFBQUFBQ UOJQ/FCHUXhRcFDjUapQR1CoUUlRYVAZUFRQp1BTUP9QrVDFUERQBFDGUUJQdFBGUAVQGVFUUUlR e1DcUcuvJq+5UG1QwlDyr+dR0q/6UEZQ31CWUKhQTFCOVFFQZ1AeUAVQBVA1ULlTtVAJr8pQWFDX UFtQa1ACUUZQMVCGUIZQpVBQUMNQxFDuUSyvqFBUUERQ0lDCUGxQEVARr5GvrFB6UNxUwFWIWeVQ wVDrUVavM685UE5QclDaUnuvhq+PUHZQCVDzUPxRVFF7UZBUGFBxUDtQ1VDIUUlTllA7UMVQ9FCu UVxSDVMTVe9QUFAZUAZQPlAnUNpQ+lCaUUJRAFWIVaCvK6+3UFZQQ1B4UDFQOVC5UWVRHVL1VFyv bq+KUAtQ6VCYUUlRSVFJUZBUC1T3VQuub6/Nr5JQRVDnUVpR7FGRVWJV3q3Rr/Gv/lBcUHZQYVBt UB5QBlAyUNNQkVCZUKFQolIvry9QGFADUCdQlVFNUXBRdlF4UYZSSVIuUi5Tg1B+UBFQDVA7UCVQ z1DgUOJQ6lDrUO1QhlCLULBQtVFEUUtRGlEyUcFRolJcUjRSn1PLU+RThFRRVPlQRlBzUHVQelAk UPVQ5lCcUJ1Qn1FVUXBRYFEAUTpRP1HHUc1RsFLgUrxSp1RYVNNUq1StVXausK6rrx6vpVBIUEpQ HFAqUC9QwVDzUONQ5FCeUIVQolCjUKZRQFFoUThR8VHgUbBRvFJZUnJSH1IgUsZS9VL9Ux5TwVOR VGVUElQ7VJ1UilXWVdtXMVeurPauw679roGv56+BUFNQXlBIUHZQFlA5UNFQ31D1UO9Qg1CFUIlQ jVCyUUlRe1FoUWtRClEOUThRI1HYUcRR/VGVUYFRulGiUlBSUFJQUnJSa1IUUh9SP1IiUi5S0lLD UsRS9VKfUp9SgFKKUo1Su1KlU1VTclNmUyFT8VPgU+hTgFO2VEBUdlR+VGFUH1QKVK9VYlViVRdV A1X4VftVklWgVmxWNFYgVrhX0lfUWJyteq2OrlCuOK7gruOv+lBYUAlQKlDBUM5Q8lD/UORQ61Ca UJxQnlCJULBQpFFEUUpRcVF3UXtRaVEWURtRHVEHUQxRNVHSUddRwlHIUctR8lH+UZVRlVGBUldS clJ7UhFSA1IxUjVS1FLXUt1S5FLkUupSmVKGUohSvVKlU0dTc1N7U2FTGVMKUwtTPlMhUyRTLlPU U8FTwVP6U59Tg1O3U7hTvVRYVEdUTlQlVCpUyVT3VORUgVUcVT1VPVXyVe9VkFWBVaxVrFZSVkpW TFZ/VjpW+FayV1ZXZlcAV9lXhFejWCBRTFF6UUpRcFBQUFBQUFBQUFBQUFJJUFtQTlL6UkRUL1G9 UFBQTVFUUF9QwVB7UdhRA1FCUaNQb1OuUThRXlQvUb1TPlNFUklUQ1BQUFBWEFTgUFBSJFHrUGVR lVAvVlJTUVBQVLBQ4lGMUrBUk1JtUIVRMFFJVPdTPlWaUnFQ+1R2UMBS7FLrURJQ5FJsUgZSzFNQ UbVR+FC1UDtQKFDEUTtRI1D7Ub1RalEtUWdRL1CEUkZTA1HUUGyv8lJUUVlRGVGgUD5TRVDRVDRQ DlBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFFpUIxQua7OVF1ULFF7UOhQxlAJUPxQj1H5 UKpRVa+8UEdQU1AFUDFQVFDcUPNQ1VB4UXBQDVCGUC9RdlFJUVRRPFafUORRVlBQV2dWblQqUKBQ qVC5VlBRUFBQUFBSaVBQUmlQUFL6UOhTm1AgVCNQQlQjUBZXTVAJVZdQClG3UAxS+lA7UvpQE1NN UExU/FAFUmlQJVL6UCNSaVDDUmmvrVQjUAZUI1DyVCNQY1QjUB1UI1B2VCNQC1QjUAdUI1AHVCNQ A1QjUBFS+lCZUvpQ+lT8UA9U/FAFVPxQD1SzUDpXnVBtVZdQUFWXUMZVl1AxVZdQxFUGUMVUs1DH VmlQMlWXUMZSaVDcVCNQc1WXUMlUs1DNVvpQwVWXUMhWaVAJVQZQxVZpUAlVl1DGVQZQGlSzUHxV l1DDVQavr1fdUFdVBlBQVQavrVSzUEZS+lDCUmmvrVL6UHZU/FAjVCOvvVL6UHpUI1AZVLNQ11Qj UAVUs1AEVCNQEVL6UEhUs1AEVLNQwlJpUMNSaa/yVCNQ2VJpUMNXTVAuVLNQwVSzUAJUs1DbVLNQ C1NNUNdUI1BgUvpQT1SzUN1UI1BbVmlQWVQjUFxUI1BeVFBQclNNUGxSbVDgU01QfVT8UBNVl1BQ VZdQUFWXUDFVBlDFVZdQyFZpUAlVl1DDVCNQGVQjUBlUI1AZVCNQGVQjUBlUI1AZVCNQB1QjUBFU I1ARVCNQEVQjUBFSaVDCUmmvuVJpr51Saa+AVLNQwVSzUAJUs1ACVLNQAlSzUAJUs1ACVLNQ3VSz UN1Us1DdVLNQ3VQjUBRTY1AGVCNQBFQjUF1UI1BrUp1QElQjr65Us1DbVbWvp1W1r6dYUFCIUvpQ 61L6UFVYUK/6VmlQb1Q0UGJUI1BRVMxQP1KmUHVSvFBKV01QCFSzUAdUs1A1UvpQk1T8UAVUI6+8 VCNQMFQjUDpYUFCZVZdQUFWXUFBWaVAJWFBQGFfdUAhUI6+sWFBQUFRQUNRUUFA5UmlQyFJpUCJU NFBhVCNQXlUGr6dUI1B9UvpQG1L6UBtUI1AUUmlQw1JpUCVUUFAhWFBQUVWXUFBVBlDFVZdQUFUG UMVVBlDFUmlQOlJpr/5Saa/vUmmvkVZpUAlWaVAJVmlQCVWXUMNVl1DDVZdQw1JpUMNS+lBTUvqv o1L6UMFS+lB2UvpQU1UGUBpUI1BgVLNQRlRQUHJSbVDgVZevrVSzUANVBq+nVCNQXlUGUMVUs1Db VPxQPVL6UAtS+lBJUvpQeFb8UAxW/FAMVvxQeFQ7r71UI6+wUFBQSFBQULBbW1hQU1NTVVZWWVhT VFRUVlNUU1NWVlZWVlZWVlZWU1NWVlZXW1hXWFdWVlhXU1ZXV1pXWFdYV1dXV1haV1dXVFNUVlZU VldWV1dUV1dTU1dTW1dXV1dVV1RXVlpWVlZUU1RWWFhYVldYV1ZWVlZWVlZXV1dXU1NTU1dXV1dX V1dXV1dWVFZWVlRWV1hYW1RUW1lWVlZUVFlXV1NWVlZWW1hYWFtaVltWVlNTVlZXVlRUVlNTVltY VlhWVlNTU1NYWFhXV1dTVFRUVFRXV1dWU1hXV1ZXV1ZUVFRZWVlWVlxdWVBTU1NWV1dZWVNUVFVX U1RTU1dXV1dXV1dXV1dTU1dXV1dcWFhYWFdWWFhTV1hXWlhZWFlYWFdYWFxYV1dUU1RXV1RXV1dX V1RXV1NTV1NbV1dXV1VXVFdWWldWVlVTVVdYWFhXWFlYV1dXV1dXV1dXV1dTU1NTV1dXV1dXV1dX V1dVV1dXVFdXWVlcVFRdWVdXV1RUW1dXU1dXV1dcWFhZXVtXXFZWU1NXVldXVFRXU1NWW1hXWFdX U1NTU1lZWVhYWFNUVFRUVFhXV1ZTWVdXVlhXV1RUVFpaWldXXV5aUFRUVFZXV1pZU1RUVVhUVFRU V1dXV1dXV1dXV1RUWFhYWF1ZWVlZWFhaWVRXWVhbWVpZWllZWFlZXVlYV1RUVFhXVFhYV1hYVFhY VFRXVFxYWFhYVVZUWFdbWFdXVVNVWFlZWVhZWllYWFhYWFhXWFhYWFRUVFRYWFhYWFhYWFhYV1VX V1dVV1haWl1UVF1aV1dXVVVcWFhUWFdXV11ZWVpeXFddV1dUVFdXWFdUVFdUVFdcWVhZWFhUVFRU WlpaWVlZVFRUVFRUWVZXV1NZWFhXWVhYVFRUW1tbV1dfQltQVFRUV1hYXVtUVVVWWVRVVFRYWFhY WFhYWFhYVFRZWVlZX1lbW1taWVxbVFhbWV1bXFpcW1paW1ldWlpYVVRVWVhVWFlYWVlVWVlUVFhU XFlZWVlWWFVZWVtYV1hWVFZZWVlbWltcW1hYWFhYWFhZWVlZVFRUVFlZWVlZWVlZWVlYVlhYWFVY WVtbX1VVQFxYWFlWVV1ZWVRZWFhYX1lZXEBeWF9YWFRUWFdaWFVVWFRUWEJZWllaWlRUVFRcXFxb W1tUVVVVVVVaWFhYVFtZWldaWVlVVVVdXV1YWEBCXFBUVFRYWVlAXFRVVVZZVFVUVFlZWVlZWVlZ WVlWVllZWVpAW1xcXFtaXFxUWVxaXVxcW1xcW1pcW19bWllVVFVZWVVZWllaWVVaWlRUWVReWlpa WlZZVVpZXVlZWVZUVllbW1xbXFxcWVlZWVlZWVlZWVlUVFRUWlpaWlpaWlpaWllWWVlZVllaXFxA VVVAXFlZWVZWXlpaVFlZWVlAW1tcQF9ZQFhYVFRZWVpZVVVZVFRYQltbW1tbVFRUVFxcXFxcXFRV VVVVVVtZWVlUXFpaWVtaWVVVVV1dXVlZQUJdUFVVVlhZWUBcVFZWV1pVVlVVWVlZWVlZWVlZWVZW WlpaWkFbXFxcW1pdXFRZXFpdXF1bXVxbWlxbQVtaWVZVVlpZVllaWVpZVVpaVFRZVF5aWlpaV1lW WlldWVlZV1RXWltbXFtcXVxZWVlZWVlZWVlZWVRUVFRaWlpaWlpaWlpaWVdZWVlWWVpdXUFWVkFd WVlaVlZfWlpWWllZWUFbW11BX1lBWVlVVVlZWllWVllVVVlCW1tbW1tUVFRUXV1dXFxcVFZWVlVW W1lZWVRcWlpZW1paVlZWXl5eWVlDRV5QVVVVWVtbQV5VVlZXW1VWVVVbW1tbW1tbW1tbV1dbW1tc Q11eXl5dXF9dVVteXEFdX11fXV1dXV1BXV1bVlVWW1tWW1xbXFtWXFxVVVtVQVxcXFxYW1ZcW19b W1pXVFdbXV1eXV1fXVtbW1tbW1tbW1tbVVVVVVxcXFxcXFxcXFxbWFtbW1dbXF5eQ1ZWQ19aW1tX V0FcXFdbW1tbQ11dX0NCW0NaWlVVWltdW1ZWW1VVWkVdXV1dXVVVVVVfX19dXV1VVlZWVlZdW1ta VF5cXVtdXFtWVlZAQEBbW0VFQFBWVldaXFxBX1VXV1hcVldWVlxcXFxcXFxcXFxXV1xcXF1EX19f X15dQF5VXF9dQV5AXkBfXl1eXUVeXVxXVldcXFdcXVxdXFddXVVVXFVDXV1dXVhcV11dX1xbW1hW WFxfX19eXkBeXFxcXFxcXFxcXFxVVVVVXV1dXV1dXV1dXVxYXFxcV1xdX19FV1dFQFxcXFhYQ11d V1xcXFxFX19ARURcRVtbVlZcW11cV1dcVlZbRV9eX15eVVVVVUBAQF5eXlVXV1dXV15cXFtWX11d W15dXFdXV0JCQlxcSEhCUFdXV1tdXUJBVlhYWV5XWFdXXV1dXV1dXV1dXVdXXl5eX0dBQUFBQF9D QVddQV9FQUJAQkFAX0FAR0BfXlhXWF5dWF1fXV9dWF9fV1ddV0VfX19fWV1YX11DXV1cWVdZXkFB QUBBQkFdXV1dXV1dXV1dXVdXV1dfX19fX19fX19fXVpdXV1YXV9CQkhYWEhDXV1eWVlFX19XXl1d XUhBQUJIR11IXFxXV11dX11YWF1XV1xHQUBBQEBXV1dXQkJCQUFBV1hYWFdYQF1eXFdBX19dQF9e WFhYREREXV1LTERQWFhYXV9fSERWWVlbQFhZWFhfX19fX19fX19fWlpAQEBBSkNERERCQUVEWF9E QUVERUJFREJCREJJQkJBWVhZQF9ZX0FfQV9ZQUFYWF9YSkFBQUFbX1lBX0VfX15bV1tAQ0NEQkRF RF9fX19fX19fX19fWFhYWEFBQUFBQUFBQUFfW19fX1lfQURES1lZS0VfX0BaWkhBQVhAX19fS0ND RUtJX0teXlhYX19CX1lZX1hYXkxDQkNCQlhYWFhFRUVERERYWVlZWVlCX0FeV0RBQl9CQUBZWVlH R0dfX01PRlBYWFheQEBJRVdaWltBWFpYWEBAQEBAQEBAQEBaWkFBQUJMQ0RFRUNCR0VYQEVCSUVG Q0ZFQ0JFQ0tDREJaWFpBQFpAQkBCQFpCQlhYQFhKQkJCQltAWkJBR0BAX1tXW0FDQ0VDRUZFQEBA QEBAQEBAQEBYWFhYQkJCQkJCQkJCQkBcQEBAWkBCRUVNWlpNR0BAQVtbSkJCWkFAQEBNQ0NGTUtA TV9fWFhAQERAWlpAWFhfT0NDQ0NDWFhYWEZGRkVFRVhaWlpaWkNAQl9XRUJEQENCQVpaWkhISEBA cHBIUFlZWl9CQkpHWFtbXENZW1lZQkJCQkJCQkJCQlpaQ0NDRE9HRkdHRURJRlhBR0RLRkhESEZF REZFT0VERFtZW0NCW0JDQkNCW0NDWlpCWkxDQ0NDXUJbQ0FJQkFAXFlcQ0dHR0VGSEZCQkJCQkJC QkJCQlpaWlpDQ0NDQ0NDQ0NDQl1CQkJbQkRISHBbW3BJQkJCXFxMRERaQ0JCQnBHR0hwTkJwQEBZ WUJBREJbW0JZWUBPR0VHRUVYWFhYSEhIRkZGWltbW1pbRUJEQFlHRERBRURDW1tbS0tLQkJxc0lQ WVlbQEJCSkhYW1tdQ1lbWVlCQkJCQkJCQkJCW1tDQ0NEcEdHSEdGREpHWUJIRE1HSUVJSEZFR0ZP RkdGW1lbQ0JbQkRCREJbRERZWUJZTURERERdQltEQ0lCQ0FdWV1DR0dIRkdJR0JCQkJCQkJCQkJC WVlZWURERERERERERERCXUJCQlxCREhIcVtbc0pCQkNcXE1ERFtDQkJCcUdHSXNPQnFBQVlZQkNH QltbQllZQXFHRkdGRllZWVlJSUlHR0dZW1tbW1tGQkZBWUdER0NGRENbW1tMTExCQnV3TFBaWltC RUVxS1lcXF5GWlxaWkVFRUVFRUVFRUVdXUZGRkd0S0tLS0lHTUtZRUtHT0tNSU1LSUdLSXNJSUdc WlxGRVxFR0VHRVxHR1paRVpxR0dHR15FXEdFTUVEQl5aXkZLS0tJS01LRUVFRUVFRUVFRUVaWlpa R0dHR0dHR0dHR0VfRUVFXUVHS0t1XFx1TURFRV5ecUdHW0ZFRUV1S0tNdXNFdUNDWlpERElFXFxF WlpDd0tJS0lJWVlZWU1NTUtLS1pcXFxcXElFR0JaS0dJRElHRlxcXE9PT0RFentwUFxcXkRHR3NO Wl5eQElcXlxcR0dHR0dHR0dHR15eSUlJSnlNTk5OTEpxTlxHTkpzTnFMcU5MS05Md0xMSl5cXklH XkdKR0pHXkpKXFxHXHVKSkpKQEdeSkdxR0dFQFxASU1NTkxOcU5HR0dHR0dHR0dHR1xcXFxKSkpK SkpKSkpKR0FHR0dfR0pPT3peXnpxR0dIQF91SkpeSUdHR3pNTXF6eEd6RUVcXEdHTEdeXkdcXEV7 TUxNTExcXFxccXFxTk5OXF5eXl5eTEdKRVxOSkxHTEpJXl5ec3NzR0d+fnNQXV1eRkpKenFbX19C S11fXV1KSkpKSkpKSkpKQEBLS0tMfU9xcXFPTHRwXEpxTHVwdE90cU9NcE97T05MX11fS0pfSkxK TEpfTExcXUpceExMTExCSV9MSXNKSUdCXUJLT09xT3B0cEpKSkpKSkpKSkpKXV1dXUxMTExMTExM TExKQkpKSkBKTHJyfl9ffnRJSktBQXlMTEBLSkpKfk9PdH57Sn5HR11dSUlOSl9fSl1dR3tPT09P T1xcXFx0dHRwcHBdX19fX19PSUxHXXFMTklPTEtfX192dnZJSmJkdlBeXl9ITEx6dFxBQUNNXkFe XkxMTExMTExMTExBQU1NTU9hc3R0dHFPd3RdTHRPeXR3cXd0cXB0cX9xcU9BXkFNTEFMT0xPTEFP Tl5eTF58Tk9PT0NMQU5Ld0xLSUNeQ01zc3RxdHd0TExMTExMTExMTExeXl5eTk9PT09PTk5OTkxE TExMQkxPdXViQUFid0tMTUNCfE9PQU1MTExic3N3Yn9MYklJXl5LS3FMQUFMXl5JZHNxc3FxXV1d XXd3d3R0dF5BQUFAQXFMT0ledE9xS3FPTUFBQXp6ekxMZmZ5UF9fQUpOTmB3XUJCRXBfQl9fTk5O Tk5OTk5OTkFBcHBwcWV1d3d3dHF6d19Od3F9d3p0end0cHd0Y3RzcUJfQnBOQk5xTnFOQnFxX0BO X39xcXFxRU5CcU17Tk1LRV9FcHV1d3R3endOTk5OTk5OTk5OTl9fX19xcXFxcXFxcXFxTkZOTk5D TnF4eGZCQmZ6Tk5PRERgcXFBcE5OTmZ1dXpmY05mS0tfX05Nc05CQk5fX0tldXR1dHRfX19fenp6 d3d3X0JBQkFCdE5xS193cXNNdHFwQkJCfX19Tk5qbHxQQEBCTHBwY3peQ0NHckBDQEBwcHBwcHBw cHBwRERycnJzaXl6enp3c316QHB6c2F6fXd9endzendnd3ZzQ0BDcnBDcHNwc3BDc3NAQHBAZHNz c3NHcENzT31wTk1HQEdyeXl6d3p9enBwcHBwcHBwcHBwQEBAQHNzc3Nzc3Nzc3NwR3BwcERwc3t7 akNDan1wcHFFRWRzc0JycHBwanl5fWpncGpNTUBAcE52cENDcEBATWx5d3l3d0BAQEB9fX16enpA Q0JDQ0N3cHNNQHpzdk53c3JDQ0NgYGBwcBMTYlBDQ0VwdXVrYEBGRkp3Q0ZDQ3V1dXV1dXV1dXVH R3d3d3kRfWBgYH15ZGBDdWB5aWBkfWRgfXhgfRF9fHlGQ0Z3dUZ1eXV5dUZ5eUNCdUNseXl5eUp1 Rnl1ZXVyckpDSnd9fWB9YGRgdXV1dXV1dXV1dXVDQ0NDeXl5eXl5eXl5eXVLdXV1R3V5YWETRkYT ZHV1d0lIbHl5R3d1dXUTfX1kE291E3JyQ0N1cnx1RkZ1Q0NyEH19fX19Q0NDQ2RkZGBgYENGRUZG Rn11eXJDYHl8cn15d0ZGRmhoaHV1GxtoUEVFSHR6ehBmQklJTXxFSUVFenp6enp6enp6ekhIfHx8 fhllZmZmYn5qZkV6Zn5vZmpiamZifmZiF2JifklFSXx6SXp+en56SX5+RUV6RRN+fn5+TXpJfnls enZ2TUVNfGVlZmJmamZ6enp6enp6enp6ekVFRUV+fn5+fn5+fn5+ek56enpKen5nZxtJSRtqeXp7 TEsTfn5IfHp6ehtlZWobF3obdnZFRXl2YnpJSXpFRXYaZWJlYmJFRUVFampqZmZmRUlISUlJYnp+ dkVmfmJ2Yn58SUlJb29veXoDBW5QR0dKd35+GWxETExwYEdMR0d+fn5+fn5+fn5+TExgYGBjAWls bGxnYxFsR35sYxdsEWcRbGdkbGcfZ2hjTEdMYH5MfmN+Y35MY2NHR35HGmNjY2NwfkxjfxJ+fXpw R3BgaWlsZ2wRbH5+fn5+fn5+fn5+R0dHR2NjY2NjY2NjY2N+cX5+fk1+Y21tA0xLAxF+fmBPThpj Y0xgfn5+A2lpEQMefgN6ekdHfn1ofkxMfkdHegVpZ2lnZ0dHR0cRERFsbGxHTEpMS0xnfmN6R2xj aH1nY2BMTEwVFRV+fgwMFVBKSk18Y2MBEkZPT3RmSk9KSmNjY2NjY2NjY2NPT2ZmZmgKbxISEm1o GBJKYxJoHRIYbRgSbWcSbQdtbWhPSk9mY09jaGNoY09oaEpJY0oCaGhoaHRjT2hiGmNhfnRKdGZv bxJtEhgSY2NjY2NjY2NjY2NKSkpKaGhoaGhoaGhoaGN1Y2NjcGNoFBQMT04MGGNjZXJyAmhoT2Zj Y2MMb28YDAdjDH5+SkpjYW1jT09jSkp+DG9tb21tSkpKShgYGBISEkpPTU9OT21jaH5KEmhtYW1o Zk9PTx0dHWNjNDcbUExMcH9oaAgYSHFxd2pMcUxMaGhoaGhoaGhoaHJyampqbTIVGBgYE20eGExo GG0DGB4THhgTbRgTDxMSbXFMcWpocWhtaG1ocW1tTEtoTAltbW1td2hxbWYAaGVid0x3ahUVGBMY HhhoaGhoaGhoaGhoaExMTExtbW1tbW1tbW1taHhoaGhzaG0aGjRxcTQeZ2hqdXUJbW1yamhoaDQV FR40Dmg0YmJMTGdlEmhxcWhMTGI3FRMVExNMTExMHh4eGBgYTHFwcXBxE2htYkwYbRJlE21qcXFx AwMDZ2hQUlFQUFBVUFVQUFNQV1AS5FJRrlZX6FJvEENQVVSuU1BaV1SuUVBJWFZVrlJT7FF2UFlR 4FFIUEh7QKZsrWweQKRsHa1sUG9srWxArGytbGFgcUFxQXVxQXFRUFRQrHBTkKwQVVCrUHBUkFBQ UlDoUFBRuFXqUFVQWVAr6lJjUFtSYhB7WlUQSU9kX1VPVVJVClhoVlNSUFlWWt9bUVtJR0pTWXZW WHZXVHZRU3ZSVupSxFBXUsQQXFJwUWBR31FTUUlaW+hRWONxtvtIe3sepA1sHbS0QL1AvUC9QL0e QBU1FLYNUG9sb2wdQK22DXthYFEWFBYUUVNBcUFTU0FxQVFRGVFgGIxRSVEqUrhRCK74rUiu1lFJ rrdQUlAgU+FTNVXqUFVQW1A7EGTXVddbplWmW1RWVVZbNVU1WyZVJltWUFVTUVZbWlhXVVFQVFNb pFhYU1BYcEBaf1pvWlNa6FErEFpTcE9RcFFgUVNR6FLG41z1E0h7QKYNva0NrVBvbEC9QUdpUUFC aWlBQmlpYWBRIiFDU2VxRVNjU2VxRVP1ZVFifqRlUWJ+U+FRQaiorr9RQaiorr9QUFJQQq+3VAtV g1BLUE9RMRDXWFRXQhhaGF4IWgheVkhcR1FERV1GUURCXUZSQ05cR1JDSVlKUURNWUpSQ1BYS1FE U1hLUkNPXEdVQEFdRlVAXl1GVl9bXEdWX0xZSlVAVFhLVUBaWUpWX1dYS1ZfWUpKGUtYREtLWF1G RhlHXERHR1xfXl5bW1paV1dWGVVAQUFPT0xMVFRV6FLMEA9SREVFSEhQURlSQ0JCTk5NTVNSUlhG R0dKSktaXVxcWVhQRENDQEBfbl1c90e7RvddEEhKZF0QdHZkb11R313PXVJdHnFWVVVSUW5LWfdK u1j3YEsQSzBLU0secPIsSHtApg20rbRApGxsQGxApg0ie3ukrbRApGxAbEBsUG9sbEBsb2xAbEBs Qml/bGxAbEBsQGxArWxsQGxAbECmbEBsQGxAbEBsQK1sQGxAbEBsQGzXVX57LUCU135Iey1AlF9f X19fX19fX19fX19fX19hYFENQ3NlY0NzZXFDY1NjQ2NTY0VzU2NFcVNzQ3NTc1FTY0PK2ORsoFFN H7AfjR24ANrnbKOusB+PHY4fslHIa45qUT2MUXeNUdauKlHWriqNromMripR1q4qU9muiVF3UFNQ Fq9jVEhWYFBwUHdQflJCENlUQlVGR0IIVTdGVQVCC0Y2VTdwJ1UlQiZwJX3XVdVC13DVfVxWdkZ2 dlFnQmV9FlEXfQVVWCZCJEMmfVNaQEF+R0hXcXdRSklRUn59d3ZBQlhAUEZLeEpWW3Facl9eQHBP eVNOUEdGeHl+fUFCQF9aW1xdSEpLUHBRUnd2cXJXVlxUSU0nAE5RTupRBlBQr5DjQkZkUOivkOZK TmRQ9kp46K+Q40pOZHjor5DlQkZkePZI6lFSUEpRGedHWV0nX15RXuhRcRB4QBBCRmRAEEpOZH9A b0AfQFNAvFpxEEJGZHEQSk5kf3FvcR9xU3G8WOhSCudaV1VZn0hRSOhSchB9WEnvSZ9JUg9JP0lS X0lPSW9JUy9J30lSSXtOXhBbXWTPXp9ej15TT15/XlJe6FLAEF1dJ097f3tSexBbXWR76FLA5gBE UURKYHTor5AQWVtdZEB0cHRSdOhSwBBdL1TfVFK/VK9UUlQnTuivkBBZW11kQE5wTlJO6FLAEEAv Td9NUn9NUU0QXF1kTUl/6FEd4ZJIex5ApHshDR29IXukDSG9IXseQKYhHb17IaS9ISF7QUJpISIi In9srQ1sUG9svL0Ne3tArQ17e6QNtG+0vL17e0Cte3ukDbRRQUJHaUFCR2lQQUJHaUFCaWlBQmlp QUJpaUFCR2lTVUBsXmxsbGxeQGxsbGxsYWBQIQ0NUQ11QXZ2ZWRmZ2VjRUZGR1d2d0FGRkVEVldF c2V2dnd1RkZDVlZFREZHQ2ZmZWR2d1G5lOef/MHP7EqtRzGg/ouTwf2ITlFVQAhmaxYQEcEbDh8K iVHzaLPy9I9BMzND48ZxJnquKRGf8uWoTOvmRYiVTAAkVFBEMGplC0ytYl4/GxMxSlBQVVAJr5VW 7VWDUFtQS1BPUHtQa1DiEB5PTD9MUUyFTU5ETU1OTVxMVkROcE9kfExgTXO0aKVgtE17eVm0QKVI tE9OU1FQbUBtUm1HR0pQdlGgdlF2DGT/UHxRoHxRfAxfcE9wUnDoUVkQTVBWUaBWUVYMRP9QXFGg XFFcDB9QD1BSUElsHRNIex5ApA0drQ0hpq0NIaYNrQ0hpq0NIR4VNRS2DVBvbGwdvaS9f7S9pL1B QmlRQUJpQmlBQmlCadd+ew0tQJRhYENkZmNiRkVEVnNydmdER0ZjYmdmZWR3dnNyV1ZRc1FjUWRm Y2JGRURWc3J2Z0RHRmNiZ2ZlZHd2c3JXVgn9xMn9/cTJ/YtxSXx9SXBwSX18SXFRbIBTXZqu7/3G x/39xMn9i3FJfH1IcXBJfX1IcVQAle7tlpXu7ZjfYXR0Yd/fYHV0Yaq3VlurJpXu7pWW7u6X32B1 dGHf32F0dGFQUFNQCq+KVfZVg1ByUH5QaFCNEChbQVp/SkFJf2dPZ2DNdPZe+Un1cPl09n5cWVRW c0lUR3N1U3pNdnFoYMRzvVO2SltMTEpNTV1JSUhzc3B/f2BoaF1dYn9zSVN8aExKU1R2cE1RU1BG UFNWaH9zcE1MSkldWWV5MUNRZRdWW1FbUEpqdstARn9GUkboUdQQXVp8y19AT0DAQPBAVEDoUU4Q X2LLX1pPWmBaU1pJaR0sSHseQKQNHa2tDb1ArQ29HkC2UG9vHb1vvUFHaUJpaVFBQkdpQkdpQUdp QmnXQFhsV0BYbNdAWGxhYFANUQ11V3Z3VlZzcHd2ZWRmZ3Z2ZWRmY2JGRURWV0NmZ0dWVldGRlFn ZmVkdnNyVkVER1NWVkVERmNiZmdV9votIwmY2q6+2jv49xschZXuhjrxnHRKrnZocH/FrXYcBAEV ExwQeTEwJzQSKhjjiW07ABzKJ8vdsQMJ8RjV6ZLcCfA1rqMQN2rXLXp8OVNcahEQZhwTfGQari9h 2hgLI2RsUFFQDFPhUd5V6lBVUG4QRtZVp1VSVlU2VSZVU1BVU1FRVaRSUFPoUVgQW3BRYFFSUbFW HRNIex5ApA0drVBvHb1pUUFCaWlhYFEiIUNTZXFFU8FlUWJ+U+FRQaiorr9QUFFQO64BUjhVg1BA UBYQXnhf91NSWFlRUFlAUEJY7VFyUFlQUVFyUFBSxBBaWaNcy3BUYFRSVOhSxuNB9TtIe0CmDb2t pL1AvVBvb0BsQGxhYFENUXN2UmVAQ2ZnY1JSRURCR0ZSNZHJ8DMG1JDZN21lc64Bt1GiuVFxUVKw 7a6Brge+9K74yzZQUFFQE64BUhBVg1BAUBkQSHdSd1o3Ujdax1L3UvheV1lYQFBYQFBCQO1RclBQ UFlRclBQUsTkWKNVy1zoUsbjQjoTSHtApr2ttL1AvVBvb0BsQGxhYFENQ25TZWRSU2NGQkVEV1JT FQMUakw22e/H9xIb/K4B4u6ojyW+UflRf4euTqiBv66krqtQUFFQTFNIUqFVg1BOUJsQddlDUQVN Bk5SFU0WTlJNXFtVSFVfXltcWkhVTVNGUEvWTHtQ1lHoUXYQRFlGtUVZtRBFe+BaUVrYX15QRW5G 6K+QEHdBQ2RGbksicEwQSkxkH0wPTFJMbl+1EF4QSkxkH14PXlJeblAicFHor5AQRUFDZFFuWm5f WVFvWd9ZUllJT/IsSHseQKQNIUkdtEike0pJraQNe0pIrUmkDXtKrUike0m0UEhvbKQNtEq8QL1J QKakSKRJtEFCR2lBaWlRQUJHaWFgUA0NDUN3ZmdmZ3Z3dndnRkd2ZWNEV2ZnZmdHVldHRkdXd1al xxgeT1hJJgVLa9M3SOJLRBIKHGU/wih0RcnXbVNIJQEaTlhUTUVa4GUQ8zcZk1hPeU3lSUjXeUo1 jzxQUVAFUINUBlSEUFtQEhBEWFNZUlUyYFMQU1JTZ1IyUFgyVlroUvIQQFVRMh9S31LwUlNSSVwd E0h7HkCkDR2kbK1stFB/pK0NtEBsQGxhYHVBcUFxQXFBcUFxQVGFrtBR0FFQUdGuL4NRLVFXUS2u 066prtNQUFFQJa7pUfVRSVBbUG/lWVhbVlpX6FFOEEtWzFFoW1paIlF2V3RfUE9QcFBgUFRQSVw3 Jkh7HkCkDR20rb1Qbx29pK1RQWlQQWlpYWBDcUVEVlZXd2ZmZ3PcUUl6JQpnBRhS2FFJmSrdIHAk TDIFUFBRUBFR11I5UvBQU1BiEHFgURBRUlFnUFBTQFNwU2BTVFMUVUBQcFBgUFNQSVT1PEh7HkC0 DR1Atg1Qf70NYWBDQXFBEVJ4UddRSa63UFBRUMNQUFH8UUlQU1B0EEVSaFBaUnZfUE9QcFBgUFRQ SVQ3Jkh7HkCkDR2tUG8dvWFgY0FxQcNRSVFJrrdQUFGvra+3UmtVg1BTUGgQTVBRURlSU0RSUlNS UVBTUFpRu1JKVVO7UElUwzxIex5ApB29HkCmHb1Qb2xvbNdVfnstQJRhYFdRY1FTUTuDrsFJVbyq RFBQUlAGr7dUXlWQUF5QcFDDEBsoWtha91H6V/pZ917nWZhZWAZBCUYJSgZPN0E4RjhKN09YaVJp VmZZZl0ZUhlWFVkWXfdZm1KZVpRZlF2JUotWhFmEXUFASHBIUkjor5AQdUJGZEj2WF1PX39fUl8Q QkZkX/ZQVU2IH1RRVEpyRIhbSXGDkkh7HkCkHb0eQKYhHb1Qb717IW+9eyFhYFENUA0NUWJHRkFA V1ZzclBBQGdmR3JWV1ZBQEZGY2JmZ2ZBQHZ2UmKFKN/AJ4WGrqrAJ4VjAEZNZB9jYwBGTWQfVZDI 5K4PrjDmxlEZUfZRzubGuREEPa6urq6REBEEPFFSUVKREVBRUPJQUFN2VZBQWVAGEFk7UitS21JT UlToUXnjD1VRVehSDudYWVVRUFxZUOtRCFBSUFFSDRBdVVBUT1RwVOBUVFRJWupR91HwUEh7HkCk DWwdpmytbFBvbG9spA29aWFgUA1xcUFWV2VmdGdjU3aut8qBPlFSYLRUc8AVr3SZ1lBQUVBjUFBU XFWQUE1RcxAP5UjmSulLmlSXSIBIgEmASlgTSxNME00GSctUxUj6VPZMWFZKcFB4VmdKGFQTSBNJ E0pYdEh0SXRKU0Z2VAZU2EjMS8xMzE36TPpNWEJQTUBNcE1hTSZN1E3ATYZNWE3or5AQRkRFZE1S QFxfTUBQcFBScFBgUBBQU1Dor5DjQkZkUOhS8eNSUVxf6FEGEHNPXH9cUlwQQkZkXPZDVVmIRkZR H1BRUEpPX4hAJ1JJToOSSHseQKQdpL0eQKYhbGwdQL1Qb617IbRvbK17DSFsQUJpUUFjew0TDAjp UE2vkOJBaU3or5DiX2lN6K+QEF5AaVRYQGlVWEFpVFhBaXt7e3t7ewlhYFENGwEI7VBLr7BQTK+w UE2vsGhoaAlRIQ0NDVFBcWZCZ2ZnZmVkdnNyVld1ZnRjYkZFRFZXVlRWV1RcrHdA8Lzue2o1CQg4 WK64SVFYlomoFx1jrqYXRlFVrqvEUVmL4W8HBQ41OitMuJq6/jPjMhGkAHZQUFFQHa+3VEtVkFB5 UIEQf91G3UeZRVMrTNtMUvZT+VX3ROZT6lXmRIpIjUlYRkRRcVpdUFRRR0NGcU9dQFxa6FF0EFkQ Xd9dUl1dUUboUVIQX09Df0NSQxBCRmRD9ktVUehRBuVAVHBUUlTor5AQYkJGZFT2d13gXJBcUlxc RkCIL0/fT89P/0/vT1VPsFeIH3RRdEp7RohHJ1GIUEl6g5JIex5ApB29pL0eQKYhHb2kDb1BaX8N UG+teyG0b617IbRBaX8NvVFBQmlBaVBBQmlBQmlBQmlhYFEhDQ1QDUN1RkZjYmZlZHZzcldnRmZl ZHZzclZXdW5SY2JHRkVEV0ZGRURQc3J0HVFAXSIBByciAmYbTyIoCBkYNluurUs9kymfLTeDLseu toKXrqpR1XE4PtQgOixFtVM5BxoINDB81c8L1DzYkSNL7NWRrqC1UFJQdlBQVBRVkFBaUF1QmRBp XHBdaVlcSVx7XANcO1yyXFa9XVFWVEZUdVR4XRhdC133Xeddll1ZUVJYUFxWXVdVWltdV1BcXF1d 6FH+EEpTVERTU1RTUlxUXVNdUlRaUFcQXZBdgF1TXetReFBYUFJR5OZQVFRQXFxQ6FEI5FXfWlFa 6FFSEEJAV89X71dTV0pfb1IvUlJSSV7qURxRGFBIex5AtCFApg0dpA1srWxQb29ApGytDWxRQUJp QmlpUEFCaUJp11V+e1QtQJRfX19hYFENDVANe3FBcWVRY0FjRXNBUUFRUi6t+FIsvObmrqCu/1F3 plPzrA6nrolSTlGlrltQUVALr7dUZVX2UE1RQBB5WF5wXGdCFUIZScldzl7HQopeWUJBQ0JxQXNC 1UJVUFRRXVpcXF1CQUHoUvAQRl5dRF5eXUJaRHBRYFEQUVMAUcBRUlHoUQblQFRwVFJU6K+Q50JG ZFT2S11c6FIKEF1PWn9aUloQQkZkWvZE6K+QEFtERmRwRGBEEERTROhR+xBEQUFPQH9AUn9Ab0Af QFNAEEJGZEDoUvAQQ19fXlRfQLBXiIBHURBHUUdKT17oUXEQQl0nUeyAUFEQUM9Q/1BTUElOg+lR F1BIex5ApA0hHb2ktB5Apg0hHb2kbFBvbECtew0hbECmDXuteyG0b617IbQNIUFCaddVfnteLUCU UUFpUEFCaUFCaWFgUSENQ3VGRmNiZmVkdnNyV3dDcUFxV2ZjYlBFRFdWc3J0C1FIXCYdCCopMSkw tMBSt62+fA4y61FUOd+um69QUSlNDz/fwNfXO3FSq66pqX+uoInl3pKKUFJQB6+3VHpVkFBHUHNQ 6RBrOlslWNdYx0n3VfdY+V76Q+le5kHtQ5BBn0NdRVVmQRRAKkblUoJAgERX61CfUFJQVFFXSEJA S3BLUkvor5AQS0JGZEv2X11PcX9xUnEQQkZkcfYQWYBZr1lTWehRH+P/UVFR6FFxEHJPVH9UUlQQ QkZkVPZFVVGIUCdOiB9cUVxKdUiIQkl0g5JIex5ApB29HkCmIR29pL1Qb617IaQNpg29eyFvvXsh UUFCaVBBQmkNYWBRDVANUVV2dnNyVldmY2JCRURQc3JQQUBQY2JGUURGY2JmZWR2c3JWVF+uoFoE EwkrQDnM4KuuqJ+OrrJRer73i63xLgEeOCAEASBUA04EAPCtLK6khLGuoFEJUdlRw1E066y52cUq 29/VL1BRUAdQUFRIVfZQW1DW6VBUr7AQYV9BZFpbSltqVGhaGFUGW/pb7ludW4lbWnFbUVtTV1BP W39bUn9bb1sfW1NbEEJGZFvqUvBQU1H851JSUVRXWFxY6FEI439XUVfoUjAQXlIfU1FTSl1RUElc g5JIex5ApGxApiFsHaQNrVBvbG9sQL2tew0hbFFBQmkNYWBRDXtDQXFFVlJSR3FCQmcHU5EnptFR rqFXvZZU8VFVnCWuGq5DklFgUiipUFNQA6+2VEdVkFBIUHRQYFFx5WBYTU9kduivqBAnTU9kl0GX Q4dVh1dURVtHXkVARUQlQCZE1EBXdlB6XGZQa1wWUBxcPlQzWDdBOEUnd9d3x13ISPRd+Uj5SvZO 93f2fPlg6UrnTkcnQ9ZD1kTXd1THXFFcx1BRUEx+yFxRXHtZx1BRUHVTT35RfhBCRmRvfh9+Un7q Ut5QTK+QEENGSGQgTNBMUvBMUUxMVkJAeFF46K+QEFlCRmRgeBB4UnjoUt4QQEJdT3JRb3IfclJy EEJGZHLoUt4QSlZVT4hZJ3uIH19RX0piSYhTJ3WIRklhg5JIex5ApB29pL0eQKYhHb2kvVBvvXsN IW+tDXshQEFpfw0he70NeyFRQUJpDUFCaQ1QQUJpDWkNYWBRIQ1QIQ17e1F2dmVkZmNiRkVEVldG RkVEVHNyd3ZlZGZDREZjYmZlZHZzclZTREZjYmZlZHZzclZRGD0ztYOBtzowKi+urYeY1c0m6Q8f ADAPHgEwSicJByIkCTc1U0d+8TD0hob0Ns96Yewrm645LIgnl1EBBA4PBB8PMK1tJNItJjct3lBQ UlARr7ZURFWQUEdQc1CcEAhrQRtBNVsqWNlY+VX5WPZe9kPlUOlT5V7oQeRDlVCaQZBDQWRDBlsJ XQ9BAkMwQ1ZJVSdGyUeNQI9EVThDUVBUUVdIQk9Lf0tSSxBCRmRL9l9VQHFwcVJx6K+QEF1CRmRx 9h9Zj1mgWVNZ6FEf4/BRUVHoUXHlQFRwVFJU6K+QEEtCRmRU9kVdSIgfQlFCSnVRiFAnTohcSXSD kkh7HkCkHb2kvR5ApiEdvVBvrXshpA2mDb17IW+9eyFRQUJpUEFCaWFgUSENUCENQ3VGRmNiZmdW c3JSZWRQY2JQQUBQc3J2UWR2c3JWRURGY2JmDVFAWgQVBypBOs/9q1FZnY9RTq6Gv/yEUg4tAh43 IAQBP1EDTgMA8KwrUVuGj1FBrveuJa4+rsznU0zYxivc3tXQUFJQmVBQUbJUdlBTUFdQfhBLU2hR VlZoVFpZ/1NSUlZ2UXBVYFVSVf9YnftIe0CmDWytbEBsplBvvW+9YWBDQXFBUUFxQZlRSa63UUlT XVFJrreso1FJrrdQUFJQ+q7pUYpUdlBTUF9QGxBaXVxaXltTaFFWW+hRThBMWsxVaF9aQf9TXiJT VXZQW3RwVGBUUlT/QJ37SHseQKQNHbRsrWy9QKZQbx29pL1vvVFBQmlQaWlhYENBcUFRcUVEVlZX d2ZmZ3ORUUmut1FJeiUKZwUYUthTXVFJrreuXJkq3SBwJEw0A1BQUVAPUPdUHFVRUFZQDhBAVlVR V1VHVQ9VU1FwXkFkUuivsBBbXkFkZ1YXVlJUZ1PoUdoQWVZnUFNQVlZUU+hR1BBbEFXScFJRSVcd E0h7HkCkbEpJHb1KSK1sbEBsUG+9rb1hYFANe3tRDSF1UWVRQVFRVBysQ1O9rRNS7fdR5aJR466z rqSuulBQUlAFUSRUBlRiUFNQV1AaEHtUVVBWV1lSV29UH1RSVGdWVf5Tb1AfUFJQZ1JgURBRUlFW UkpZUElYHRNIex5AtEC2UG8NbB2tDWymbK0NbFFBQmlpQmlpYWBDQXFBUUFxQQVUUauvVFFTYFFS rq6uFFFTrq1QUFFQD1D2VB1Ur1BWUDYQQF9SUVlSSVIAUlNWcF5BZFXor7AQXV5BZGdRFlGHVlNT Z1ToUdoQWlFnEFBTUtJwVVboUdQQXlBUU1NRH1BRUElXHRNIex5ApA1sbEBsHUCtbEpJvVBIb0q9 rb1hYFANe3tRDSFnQVFRQVFFD1LurRJTvvZRS1FEUUFRSa4doFBSUDpQUFTWVZlQS1BPUNMQelZA XkNkVUBAQmRqSGpJEFUFRTZK+1dWWUZDUBBJT2RfUE9QUlAKTmhMX+hSw+JAylzoUiQQckNRTFpM UU9QUXZQUEBZcUBGcEZSRkpxX3FAQFFASXD1E0h7HkCkDR29HkCmDR29Qml/vUBsQGxQb2+tpLRA rbYNe0JpaWFgUA17e1FzdmVkZmZnZmVkdnNyVld1ZnRjYlRFRFZXVlZTQXFBUr+vUQKmSHXTPzvA S66uW1FLtqJRTjn8CXutUUlRKmdcLPCYT2FrAiUqLXDjqq34DfbfGgquQlFJrrdQUlBtrgFXllWE UG1QHlDOEBFZS1d1VmlHdUZpRh1WSUhnbVJIFG5zdBh1eFBBYEgRUHN0G1Uxa99QYzFdURvRcVd0 VlBaewxFEdFKSkVaYBhRGOpR4FB4UTsQSGAxQW5wUWBRUlFKAG7RTTJnMVlJHzo8SHseQKQdvaS9 HkCmDR2kvaS9DVBvbEC9QL1vb2+9b71ApL1BQmlBQmlRQUJpQmlBaWlCaWlhYFANUQ11Y1ZXVnFw dFJBQFB0cWJUQkVEV1JxcnZ3VnNydmVkZ2ZjYkdncVNWRURGY2JnZkJlZFBxcFRSRURCVGNidFFE RmNiZ2ZnZmZlZHZzclZWVqGFNJ+9rvuu5q5wulFaUZ5ReaxR2J/Nla6cAwReJsr2i9TwquIFSVFY x15HQGAcNi6uzK6RrqGu1++FUdGov1EIrGA3HGlidnVlHTkABsIaQ5sj1I9R41FQUUlRtaOUrseG r56urGpoIrXuu5K82D+tYxRESUlqHFFQ2aZRG42uP4mDrvbP1VJwLyhMRHttujUhKdWmUFBSUFBQ UFXvVepQV1BaUWLpUFeviBBZZ2lkVnhnaWRX6K+QEFl4ZWRWEHhlZFfor4gQAHF3ZFZ4cXdkeVB6 VHpVeFp/XGhQZ1VvXDpQOlI1UzZVOFg3WrhTXxpWUVJYWVFTWllZVFdZUVFwUFdEUFBXVllUVHBV VkRVVVZYWhBKTW5a6K+QEFtKTWRadVJTU1ZUWehR7BBeVldSVVRUUVBYXEdHSlDoUjEQW09RUXBR YFHQUVNR6FJ0EFlPWVFgWdBZUlnqUnRQVFIxEFlwVVFVSVsOM0h7HkCkDR2tSaYNIaQNIUitHhU1 FLZQb2xsQGxvbB29QUJpf2yte3ts11V+e9ctlNd+SHvXLZRXQGxs15SUYWBRG+BbAxvgTgEKCOlQ U6+u4lhUWuqvrlBXr6zhVlRoaGhoaAlRIQ17e3t7e3txcVNxU3FRcUNTU1Xvru7QreYprpZSa1Fp epqWUR2u41XqrNpScK2wUFNQxlBQVTJV6lBDUHBQfFCKEBEneohfUjheKHq2VKZUVFlxRVlWeHxx dUZCT0UfRVJgRf9FUkVFRHNydUJDWHBEdVFQUkt3IFbQVlJWG3h3/1xRXOivkONZW2Rc6FLcEHFg fhB+AH4wfiB+0H7AfvB+WHB+YH5SfkRycFBwQ2BDUkPoUtvjfWEDSHseQKQNbB2tbB1ADSGmeyEd vaQNvVBvbK1sb2ytbEFpfw0hEwwI6VBFr9DiTWlF6K+Q4kppReiv0OFDaXt7ewlsrWxRQUJpUEFC aWFgURvgWwMb4F8BCgjhWnBoCVENUA1DcWJOUkVEVldGRkVEVlZXVlVxUUFjYmdmZmVkdnd2c1NB cWJnZmZlZHZ2c8ZSGv771wo/D9bADfEmGq61rl1ReJL9ehwHGxp8gfpRQvB7EgMQKZpV6k0MyQ83 /Ht37C807SFdWFJUlq79VVkHFxQFWVWt6a4oWVwNHhIMelBQUVAxr7dVDlWDUEpQhBAd1lnZRNlG yFaXWYRThFulU1h1WXhceF15RHlGJVUlWdZVWFdDV0dHQ0dHeVJ6U3VVV3hVb1EfUclVx1mZU5Vb iFVYUQJAUFGwUKBQUlDor5DjQUhkUOivkONaXWRQ6FEKEEdIfVRYXhBeQmReGw9fUR9fUV8QRUhk X+hReBByQn1aU1+/XgZQv1BRH1FSUUpgTFFMRXfwV1FfV09XYFdTV+hS3ONLLgNIex5ApA0hHb0e QA2mDR29pL1Qb62kew0htHtvraR7ew0htGFgUA1RDQ0NUVVWVHNwUEFAUHFwR0ZHVXZ2c3JWQUBG Y2JmVG9RTxKunbyujK7YUSpRZFFd+DRirotK9Sbzm5jwJvpSSwuguVHfUQpRPlHFzw7gFiLUuq6q rrq8xlBQUlDEUFBVMVXqUEBQT1AvEGN4VXhaF0c1VDVcVXpHaUcYRglGOEZVaUdmS9dLyVXGW1VP QXVRUFJDQnVfQFhJd/9XUVfor5DjWVtkV+hS3BBD0HFRcHFgcVJxQUJwUHBAYEBSQOhS2+NwYQNI ex5ApA1sHa1sHUANIaZ7IR29UG9srWxvbK1sYWBQDSFRDUNxYkdGRkJFRFdWV1ZXVnNxUUFjYmdu UmVkdnZ3dnPEUk3nMNHoMH1nNh3TMvStg1F4jSxnGA9sbDwDbuVV6kx2kq63nuXT8DMbek9Ukqxl XkIGlfr65jZCXlBQUVDFUFBUoFXqUFtQwBBtWFVUV1h1VkJPVVFgVf9VUlVVWVNUdVJRUlpZdVtQ WFdWG1NSGFpQW1FbSnBdYF0QXVNdVFlwUXBQYFBSUOhS2+NcYQNIex5ApA1sHa1sHkANpg1sHaRs pGxQb2ytbG9srWxBaX8NIRMMCOlQVa+Q4k1pVeiv0OJKaVXor9DhQ2l7e3sJbK1sU1VAbGxhYGNB cUVxQXFFcUFxRcVUb6y5UrCtcFNjVeqoruunriGnUFFQx1BQVNRV6lBZUCIQb1hVVFZVdVdwWGBY 71iPWFR/WMBYUlhYUFNUdVJRUllQWFdvVh9WUlYCU1BSUVJKcFtgW1JbVFlwUXBQYFBSUOhS2+Na YQNIex5ApA1sHa1sHkANpg1sHaQNbFBvbG9srWxCaX8NIWytbFNVQGxsYWBjQXFFcUFxRXFBx1O9 rWtSNK3MVeqorvWorcFQUFFQMq+3Ve1Vg1BwUIgQFmhOG04GVyZYJlzVWNRc1UfUS1lWR1ZLQkdC S3hBeEh4SnhOWBhbC1QEWQpbOlQrVCpIJErmXuZAl12WQIdAt0BeU0xWcFDor5AQT0ppT1BRUHVS UVFGTH1WWUIQXkJkQhsfQ1FDEEVIZEPoUXgQekZ9X1NQUVFwSQ9DUUN3QgZST3BwU1JKcHJgclJy SXfwWlFfWk9aYFpTWuhS3ONxLs9Iex5ApA0hHb0eQA2mbB2tbECkvSFBQml/bFBvraR7DbR7b71B aX9srSF7bEFCaWFgUA1RDQ1RZXFBVlRzcnRSZWRCZ2ZjcFRHVXZ2c3JWRUBCY2JmZ2VTb1IuDa7P 5bau+vyQ6d2CUUFRY3yuik/70JK1uOwN6xNSS6et6ArZkVE3g7VRNA8ZtZpnPC2moq6rrqsZZOpQ UVDGUFBVelXqUFtQ8xB1WVRVWlNSWVp1VEL/U1FTU1BWVVVSUVJXWFhbUFhVWHBWn1dRV+hS2xBy EF0AXTBdUyBd0F1ScF1gXfBdkF1UXVJbcFFwUGBQkFBTUOhS2+NcYSVIex5ApA1sHa1sHUANISKm DWwdrWxQb2xsQGxvbGxAbEJpfw0TDAjpUFOvkOJNaVPor5DiSmlT6K+Q4UNpe3t7CWytbFNVQGxs QGxsYWBjQXFBcUFxQXFBcUHGUXhSFFF4roit7FXqre9SEaoWUtGtL1BRUNxQUFHkVepQU1A/6VBV r5DjYmRkVeivkONzdWRV6K+QEG9ER2RQVRBVAFXQVbBVVU9VMFUgVaBVVNBVUVJRUlNQWFJTiVFQ UOBQsFBTkFCgUFJwUGBQgFCwUFRQPlRhz0h7HkCkDSEibB2tbFBvbG9sYWBRDSEie3t7Y0FxQdxR eFXqqhZQUVBzr7dTnVXqUEJQChB0OVj3XVIEWTZZOV05QDlBKkDZQFdaGFvRX31XWVFQUlBCcFFS 6FLbEEIgRFFgRFFEW79PWlFaSUOtJUh7HkCkDR29HUAhIaZsHa1sUG9sb62ktGFgUA1RDVFxQURX VlZzcnZ3dUZHRmNiZmVS9lF3cHuy6Ym6UVFHVXBgMjMCVeqsMOYy0Muju3AuZB8h4lBRUMlQUFWT VepQW1EpEEpYVlFCQlpaVVNSU1RWVldZWllYWlVZWFlaWOhR5xB7V1ZEV1dWU1RUcFVaRFVVWlpZ U1NWWlNZU1hbVlZXVVRUUlFSUFtbWFdYVOhSNOJVGFjoUjQQQldKcF1gXVJdUltwUXBQYFBSUOhS 2+NcYTNIex5ApA1sHa1sSR5ADaZIHb2kvVBvbGxAbG9sbEBsSUJpf1FBQkdpUEJHaddVfkh7VC1A lNdVfkh7WC1AlNdYQGxYlFNYQGxYbGFgUBMIEEl2VndZwFTIVvBU4FSQVFfUVvhUuFSmVVRZ6K+w 42cCZFnor5AQdGcCZHVWbVokU9ZTyVPJWcpa+lPqU5lTWpFTgFOsWlNtWhJTUiIhDXtReyENCRMM COlQVq+440Jbb1bor7gQQ19bb1RgXUZvVGBcRG9UcFtCb1Por4DjX0lvU+ivgONeR29T6K+A411G b1Por4DjXERvU+ivgONbQm9T6K+A4l5Db1B7e3t7e3tRe3t7e3sJUQ1jQXFBUXFRUXFRV0HJUXhS BlHerYhSFq7Rrj2gVeqtJVLbrZWs0VLgpa4VUFFQzVBQVPVV/lBVUG0QSgBXUVJRUlRTdVVQWFRV SldSU3BRcFBgUFJQ6FLb41Zh6Uh7HkCkDWwdrWweQK5sUG9sHa1sb2xhYFENY0FxQXFFzVF4UrBV /qsZp1BQUVDBUFBWSVXqUFxR/BBbW1N2WHZbU1RTUVPor9AQWUxqZFpwamtkWeivsONqa2RZ6K+w EPRMfmRacEx+ZFZZWFqzWbxaVFRZWlpDUkxUQFlPWnNSfFRwWX9aN1I4VDVZOlonUihU9Fn6WuVZ 6lqmWapaRs9UwFnPWpZZmVqHUohUhlmJWrdSuFS1WbpaXSdZKFrTUtxU01ncWsBSVwhbNVI6VDdZ OFomUilUVxRSG1QUWRtaB1gHWQhaV0haf15kUmpUZFlrWm9eV1NSXFRWWVlaRVJKVEdZV+ivaxB9 U1pZcFRYWVliU1REU1NUUltaWmJTUkRTU1JbWFNTXFRSUlxaWllZV1hPXlFe6FFd41dWVVTqUmhQ Va+Q4wsNZFXor5AQRwMEZFViVxBXL1hRWO0vU1FT7VtwW1xS6FJoEEJRUFAQCw1kUBADBGRQYk9c UVzoUV3jXWElSHtApCG9e3tAbL5AbEpJQK0hrSFsSkhArXt7vkBsQLQhUG9sQGxAbG9sQkdp11V+ e9ctlNd+SHvXLZR7YWBRG+BDAwjpUFivsOFbcGhoCVENDQ0NDQ0hInt7e3tQeyENY0FxUVFxQXFB UXFRQcFR61FaUVdR7K69ro2us66OVeqsSFO4qhZU0qsuVNKrLlBRUMhQUFVzVepQWVH2EF5ZU1ZY SVNHWFRCWFJTU+ivUONCW29T6K+Q4wsNZFPor5AQegMEZFNiV1hEV1dYU1hSUldTWVRSUllXWFNU EAsNZFQQAwRkVGJWn1VRVehS2xBJEFsAWzBbUyBb0FtS8FuQW1JwW2BbUltYWeivkOMLDWRZ6K+Q EF4DA2RZYlFwUGBQkFBTUOhS2+NaYSVIex5ApA1sHa17e2wdQA0NISKmDWwdrXt7bFBvbG9sUUFC aWlQQmlp1357e3t71y2UYWATCOlQU6/Q5ltlWNBbZVPor5AQbUp+ZFgDSn5kVVNGU2JTEFNUFlPV WMBY8FjiWLRTVpRTn1iKWFNwU39YZFNrWB9YwlPPWPBT/1jgU+9YW1for5AQWWNlZFIQY2VkV+iv sBBdf2JkUnB/YmRSV0RlV+ivxxBZcX5kUgRxfmRX6K+QEBZOcGRSBE5wZFhSV1dIUlNHV3xSd1dr UmNXHlIQVwxSBldZRFJLVx1SFVfKV/tXm1KJUrhSt1epUlt3UnhXGlcoV9hX/FJWUQ0hIiJ7e3t7 e3t7e3tQDQ0hInt7e3sJUA1jQXFRQXFBcVFByFFwUghRQ66HreFV6qx9U4OqFlPsrBRQUFJQCa+3 VbdVg1BfUEtQ9hAJx1XHWMhcyF6HVYhcVlhRV15YX1dId0goWSdCVydBKEXWVNlY2VzWXtVC2UTY RdhH2EjWSlxXQlhEV0pFQkpESkhFSldDfV1ZSX1XU0Z3/1pRUFpAWnBaU1roUtwQcGBNEE0wTSBN 0E3wTVZwTaBNUk1Ad/BQUV9QT1BgUFNQ6FLc40wuk0h7HkCkDSEdvR1ADSGmDSEdvVBvvW+9YWBR DQ0hUA1DZGdmZmdmY3BQQUBQcXBQUURCY2JmZWR2c3JWCRNi/TfZ41EUUdWuLq7trumuLlFhtuHh s43n57BShLDIIOJ7aq4+rsquza4/Ud9ROKmur6+vrKirUFBSUMVQUFSoVepQX1BLUCcQdVZV6UTp SFMXVVE3VYZVUkJBdV1eXlBLQHVSUVJfUFhGd/9XUVfor5DjWVtkV+hS3BBGT01gTTBNIE3QTVVN QF9wUXBQYFBSUOhS2+NMYQNIex5ApA1sHa1sHUAhpnshHb1Qb2xvbK1sQml/bK1sYWBQDSFRDWNB cXBHRkZFRFZWV1Zzc0lSY2JmZmVkdnd2c8VRi1FeAi76MsceOpmR8v8mEw4YZfBV6kZxjf/X6DlB Ra2HVJKuMH4yEQA4XVpQUlAJrz1WTlWDUEVQeFF3EMTWTddxylDKRMxGzEdWKEAtRydw1lrWXthA 2ETZS1hWTVl1SktETURxSXU7RypQWCRQUcZGtkamRlMJVzhXKFcpSilOKXDaV9lB2UrWcMlXyVrK W8dex0DGQflX5kaWRodeh0CGRkZnSwhBOVc5WipQKVdWU1FGRhxQFEYMUANGPFBXdEZyd3d0RldQ U1ZSdkx9X1N36FIc5XYfcn1ZUuivkONfQWRS6FEDEF9ThFlZdnZPSXdSG/96UULor5DjWVtkQuhS 3BBwYHoQejB6IHrQevB6VnB6oHpSek938FxRX1xPXGBcU1zoUtzjeS6TSHseQKQNIR29HUANIaZ7 IR20rUFpf1BvpL17QK2uvW+9UUFCR2lQQUJpaWFgUCENDQ1RIQ0NDXVGR1d2d3Z3VnNwUEFAUHFw UEFEV1Z1ZmZlZHZzclZFQEZjYmd2d2dGVWE90D0TEF7nwP+u/q7RUdBRGVEWUS5leK7qaWmw5eWx sfwQaQoNA8LqHn6BRHNXK29R3lE4UTdR364hrsnuwD4QE+4rrqusra6vr0VrcfliUFBSUMZQUFXs VepQRVBxUKgQ0mlfGV8HVzpbOlz6Wfde8HPmXohZWlZYVlpHWEZaZl4WXhZfV1hAWUFEXkRfREBm XmZfF18lXilAg1pbKFkoSSZN2FnYSdZNVllGRFlcX14DXiVe1F7EXvNeVV5wXVxEXV1cX1xFXUdG dUNARFEwRPBEUkREUHBxdVJRUl1eXkVQWF7oUewQd1BdQF1SXYRLd/BW4FaQVoBWVFbXIHNRcHNg c1JzcUVwUXBQYFBSUOhS2+NyYTNIex5ApA1sHa1sQA0hpg29pA29UG9sbEBsb2ytbEJpfw0hbK1s UUFCaWnXfnsNXi1AlFFBaVBBQmlhYFANUSENDWNBcWJGRkVEVldGRkdDcVN+UnNzQUFjYmZmZWR2 d3Zzc8ZSP7uF0JKRMC06467OhiIEDjZsi4U6bB8YdOS3VeofmtL1h0xo1vuuslFv+wlxrcxTHnQI EhoLXFVQUFFQGq+2VKJVg1B8UeAQbelB6E3meJZ8VFdDV0VHQ0dFSHs1VTV4JFYoXSR4iVyGc1wJ WgVeBXIJczhcNkI3cTl4N3wnTdZNxnFcQnPor7DjTk9kc+ivsBA1SUpkAXIBc5FykXNUIXIhc9Fy 0XOxcrFzVntael10cnRzaV1kcxtaG10UchNzOl01cyldKnLZXdpy9lr3XfhyQ1laWV1WclZzSVpJ XUZyV3JzWl1UUUcGSBBJcGQ/SFE/SM9IUkjqUjVQS6+QEFxKaU9LUUt9RFNQGFHor5AQGUpwZGBR EFEAUTBRwFHwUeBRkFFYUb5UEEppQFRRVH16WUi/r0dRRxBDR2RHG1d3dkp+T3fwQOBAUkAbUb9B cFBgUFJQSX2CA0h7HkCkDRsDCOFQEGgJHb2kDb0eQKYdvaR7Ir1Qb60he6QNe7RvrSF7pA0ie7RC R2kNDSEie3sTDAjpUHKvsONLTW5z6K+A40tNbnPor7PiQ2ly6K+w4kNpc+ivmeJCaXLor4AQX0Jp XXBCaVpwQmlacF9pcuivuBBeXGldcF1pWkhdaVpIQ2l7e3t7e3t7e3t7e3t7CWFgUA0hUQ1DdUZG Y2JmZWR2d3Z3dnd2ZWRmZmNwVEdVdnZzcldWRURHRlRGRkVEVlRzcFAaUXBKz9ffwW0cZOm+MNcv v/lRRFFHV66IQy0t0Rl/fGhR4J8l3K9Q7666roZRjUzB2CkBZBlLQn5rBin+IJM2oppdITNlcmlk dX82Pe3bLow7UVFQUFFQfFBQVOlV6lBXUCIQc39ZYFRgVQBZIFnQWcBZV1ZRVVJ1VFNSV1BYWUdH SlQvVVFV6FF9EFpWV3BRYFAvUFJQ6FF9EEFTXgBSIFLQUsBSVFJJWK38SHseQKQNGwEI4VIQaAls HaQNbK1spA1sFTUUtFBvbG9srWxsbGFgUQ1xQXFlcUVxQVGPrh1U3a4eVJKoqKtuUFFQw6+3VXRV 6lBJUNoQaFdYV1lXQEdYRlkXWBdZVwdZBkDGQMdByEXLRvdA50aHRbVWplZbXVxcUVBSV3VDWVxb cF2fXlFe6FLbEHIQSwBLMEtTIEvQS1JwS2BL8EuQS1RLUVJwUHBJYEmQSVNJ6FLb40phJUh7HkCk DWwdrWwdQA0hIqYNbB2tbFBvvW9sbEBsYWBRDSFDcUFER0ZGY2JmZmVBcUFAXlJzcnZ2d3Zlw1F4 W0PfLC7QSlF4YNGI/oKJLkRNVeqstu1oCj03xv5Te6yurqiKxgkxywUuplBQUa+vUFBVBFXqUFZQ v+NQU1FY6K/Q4kJpU+iv0BAESmpkkFiGUYZSiVSJVVUmUilUKFXHUcZSyVTIVc9YWFNQW1Z/WDdS OFQwWCdRV0lQRlZ5UHZWGVAXVgdQV1BTUlJwUVBEUVFQVlNUVHBVVkRVVVZT6FIyEFtWUFhVVFRS UlFSVepSMVBUr5AQX0JpW1RRL1TQVI9UsFRUVOhRWxBaL1PQU49TsFNUU+ivkOVCaVtTUVPqUVtQ UlIxEFlgUVFRSVcOM0h7HkCkDR2tSaQNew2kDQ17SL1Qb2xAbEBsb2y911V+e9ctlNd+SHvXLZRh YFEhDQ0NUHtRe1ANcVFxUVFxUVJbraRREVEjUTdRaq2jVeqrk1RtqhZQUVBXUFBX21XqUFxR8xBC e1N7VnBbY1tUUFZRWxBKamRW6K/Q40pqZFPor9DjSmpkU+iv0OJJZVnor7cQWUpNZFpJSk1kXOiv txBZSk1kUElKTWRV6K+wEA5GTWRUcEZNZFdZWVpWXEpQRVl5UHVZV7lat1ynWalap1xVl1WZWpdc ilCEWYlahly6ULVZWftU81X7WvVc61TjVeta5VyYVFl+VHJVf1pwXMtUw1XLWsVcWJJbVFVw6K9g 41ZaWXDor2IQDFNQXHBQU1JScFFQRFFRUFpWVVViW1pEW1taWVZXV3BYWURYWFlUW1xcYlNURFNT VFtWU1NcUFJRVFxTVVpbV1lYVlhXV1VVVFRSUlFSXFpaWVlQWF5HR0p/WFFY6FFgEFpwVu1b7RB/ U1FT6FFgEFxwcFFgUVJRSV0OM0h7HkCkDUpJHa0NSkitrUpJrQ1IHhU1FLZQb2xAbEBsb2xAbEBs QGxAbFFBQmlpQmlpQWlpQmlpUEFHaddVHX571y2U135Ie9ctlNd+SHvXLZTXfkh71y2Ue3t7YWBR DQ0NDSF7e3t7e3tQe3t7eyENcVFxQ1FxUUNxUXFRUVE1rvJRf41RXFEwUVGxUXquzK6WroyujVXq rEFTv6xQVFCqFlQYq+hQUVBQUFBVA1XqUFtRRBDxQVRLWgFUClpU+1X2V/tZ9FuLUYRXVtVbyFHE U8pVx1fKWcRb+FH0U1lKUUVXeFF2VwlRBlfVU9pV2llZZFFrV1JJWnBUf1oUVBxaC1rUVNxawVTP WvBUhFSOWl1nVGhaw1TLWpdUmVqAVFdaUllWW1dTWFZbVFNYVVBRUllVUFlYU1NwUllEUlJZVVZb W3BQVURQUFVWVVVTUlJYWVlbUFXoUeznVhBDRWRWG1noUezjWEpdU+pR7FBSr5DlQ0VkUhtb6FHs EFtwUGBQUlBJXA4zSHtJHkCkDUgdvaR7vUkeQKZIHb2ke71Qf2xsQGxvbGxAbNdVfnvXLZTXfkh7 1y2UX19fX2FgUA0hUQ0hISFQImFRUXFRUXFRUXFRUVGlrmpRClF2UXBRB65oUaWuy67rrupSrVLt rnlRh61orV5Rq65VUFGvrVBQVQhV6lBYUJXpUFSv7hBuW2WQWlFUU1RVU1dUVVRTVVFUU1RVU3BS UURSUlFUVVRTVXBWV0RWVldRVFdTVlhXVFFTUlNZVFBVWlhRBlfoUjcQW1ZWVVVTU1JSUFha61JH UFhQVlJH5VdXWHBQUuhSR+dRUXBQYFBSUOhSNuNZDjNIe0CmDWxJQLRIQK1sSUC0SEC0UG9vbEBs QGxAprRRQUJpQmlBaVBBR2lBQkdp11V+e1gtQJTXVX5Ie1gtQJRXWEBs11hAlGFgUQ1Qe3FBUXFR UXFRQVJGrbdRC1EJUQJRBa21UjlTAa3sUhSs/a3JUFFQRlBQVO1V6lBZUV/pUFevoBBLX2lXUlFC UlZXV3BRUkRRUVJWelVSU3VVVFJR6FJ2EF9QWFd1WVBYVlUYWCBZUVnor5AQdVlcZFlKEFsAWzBb U1tUYFMQUwBTMFNUUwJRX1BPUFJQSVqs/Eh7HkCkDWwdpA1sHkANpnsNbB2kbFBvbK1sQLZvbK1s QL3XVX571y2UYWATCOlQUa+Q40twZFHor5AQc3F3ZFbQQWUQURhWAFE0UT9WIFEvVtBRWFJwcXhk VxBLcGRS6K/24kFlW+ivkBBlQElkHlcNVzNSOVciUi1X3VflUutXWU1SQFd9UnBXb1JgVx5SEFcM UgBX2lLQWt9bqFKgV19RIQ17e3t7UA17e3sJUQ17Y0FRcWVxRVFxRUZTUq0FVGGsjVMSUVtT56i2 rHOnUFBRUMKuM1LUVepQV1AAEGJWYFUQVVJVZ1BTb1QfVFJUZ1FAUEJTUlZSV1RVQFdRV6RVy1BQ cFFgUYBRU1EwWDcsSHtApg1sQL29DUBsQGxsQGxQb2+tDWxArQ1sYWBDQXFFc0FjRcJRore3rjNX B42qM41QUFGvra+3UmtVg1BTUGgQTVBTUxlSUURSUlFSU1pRUFBTu1JKVVG7UElUwzxIex5ApB29 HkCmHb1Qb2xvbNdVfnstQJRhYFNjUXNTn1E/g1WDqkRQUFFQdq4zUkhV6lBXUBQQem9VH1VSVWdQ YFQQVFJUZ1FCUEBXVlZST1NRU6RRVVTLUI9RUVEwWfMmSHtApg1srWxArQ1sbEBsUG9vvQ1AvQ1h YFFBcWVjQXNlUkiuXre3Veqo+Y1Vz4tQUVAjUuRUaFWDUFZQ2OlQUa+oEHxJS2RGUUlSh1K3UlT4 VPdWUshUxlZS11HYUlIqVVFPVd1VUlVWVFVTVFZUUOhRieZRVmhQVGhT6FF+EF6PVb9VUs9V/1VS cFVRVehRfhBdT1AwUCBQU1BJV/WBSHseQKQNHa0NDQ2tvUC9UH+tbGxAbGlRQUJpYWBQDSFRDQ0N DXtDUWNRcVNTI1Eoj1E+rrSWlVLkU0+ssVG5rkdQUFGvva47VC2vcVBTUEoQXFHrUFJKVVBJVG1k SHseQLRAtlB/Hb1hYFNlcUVDVMCuO+bmUFBRUHpU+FG/VYNQU1AX6VBTr7DjQkVkU+ivsBBcTnRk AFFRUFFAUVJR6FEJEFpSUFG1UD5AU1FT6FIx5VJJVPP7SHseQKQdrQ2kvVBvvQ0hYWBRe3tRc1Fx Ub/hrrxRa1T4UXtQUlAZr7hUflRuUHNQYlEAEDpXSlhMVU1GShpLGEwZdYtAj0FZZkkWSQd2Nkk3 dtZ2wknDSvZK6UuXSphLt1NdVlZdRUZWSUZ3VnlFCUknUtZS9lblVpZWXO9kiUBSTXRiYUF8XXQQ e35kdBByeGR0EElNZD90rHRSdBZN6K+QEGBeX2RtTVFQTUBN4E2pTVRNTXxRY1AQXl9kX1BPUFJQ BXEQTEFvcRBLQG9xEEhKZHHoUiTlVFdcXVp86K+Q40xBb3zor5DjS0BvfOivkONISmR86FIkEBBE W05hdlh5WXhdCU9cz1xST1xRr1xRXBBeRmRcSh9kUWQwUFFQ3mBRUVFjeXEPR1GPR1EfRw9HP0dT R0ljORFIex5ApA0hIh29pCG9DR5ADaZ7DSEiHb2ktK1sUG+9e3t7b2xvrXt7e6QNe7RCaX8NIXu9 DXt7e0FCaVNeQGxsbGFgUSENUA0hUXdmZmNiRkZFU0RGR3F2d3Z3VlZzcnZlZGZmZ2ZnZWR2c3JW UVZWV1ZFREZjYmdmZ2ZlUTWve4Kf7OgbU0t1rrpbQFdTGPQN9O0Gy8KVHAA/GwRRDma6dGcIFBwV Y0BbUrJ+ysQJ2eeu6NzVHExnSVgWFuLYCt0bTHVwTAEVa66CQmJId2xrBmJ2Z3Q1UFBSUNevuFTE VepQX1BMUM3pUEKvqBBhW2lnSxdLUkIGVgZaBkYGSAlMp1dWZVRrXWtDZUsVVBtdG0MVS8RXyVla XF5RUlFQSuhSJOJVV0ToUiQQQ1tbX1BaR3FYSiBOUU5AeVJTdl/oUXkQXFEgUNBQUlBJTW8RSHse QKQhbB29rWy2HkAhph29UG9sb71vvW9sYWBQIQ1RDRMIEFs2VjZaNkY2SDlMVQ0JUA17Y0FxQWZj YkJBQFBzcnZ3RUNER0ZjYmZlZHZzclbXUUnS4pKurq3pC+EQQmQZKQ3T1Dc11lXqraDErreuqa6g rooLCcxSevUfIM/75vHNUFBRUAWvuFRvVG5QSVC1EAUIXwlCCUY4XzlCOUYtSClJx1LHXJZAlkiH QIZIuVa5WLlDuUWoVkNoQ2hFGkIaRhZICVw5XFdqQmdGZ0hTJ1UnX9dV1l/ZSfhC90bpQuZGukK2 Rlte6K+Q40hLZF7or5DlQkRkXmNd6K+Q40lOZF3or5DjX0FkXepRVFBaUiQQQkFbUBBIS2RQEEJE ZFBjwFFRUepRUVBUUiQQcEdXURBCRGRRcVB/XRBCRGRdcR9eUV5KS1dxRElKCBFIex5ApB29HkCm DR29e6S9e1BvraQNtHt7b62ke3u0e3thYFANIVEhDVFVdnZzclZFREZjYmZnVVZWc3JQQUBQY2JG VGGuu14zHzktLzsANkVRRHuknbmuu1FGvZK1UrxiAwTB+u3MCz9/7pJRdlFUUVdRdfdQUFJQBK+4 VDFV6lBfUExQwBB9QglWCVoJQgZGBkgJTMhXyVmoWVkgTtBOUmpTZFxqRWRJGlMUXBpFFEnJWVlE 6FIk4lVbSuhSJBBeW1deX1BRUFpHeV5ddlHoUXkQX19QSt9OUU5AcVhJTQhsSHseQKQdvR5AIaZs Hb2tbLZQb2xvbG+9b71hYFANUSENEwgQXTlWOVo5QjZGNkg5TFYNCXFxZVZWc3JQQUBCY2JHQXFR REdGY2JmZWR2c3JWVDGuqxHhCueuq66S4tJRSa1CfxQqMdjUNzTXzAsJUXdRWFFeUUnEUkCsIPoc PvX05/HPUFJQEa+4VHdUblBEUExR9elQQK+oEB9baclZyl3GQPhV91rrWetd6EqqVaVaWldaUVhE URhSF1YWWh9O+F3mVuZKl1qYXIZaiFyoV6hZp11eTF9MRRBLTWRFEF5BZF9F70WfRVNF6K+Q419O b0Xor5DjXkdvRehS3RBcX15CAF4wXlJeSEJR6K+Q5klLZFFjQlDor5DjTXBkUOivkONyeWRQ6K+Q 43t9ZFDor5DjRUxkUOivkBBfXl9k8FBRUFBAUFJQD0JC6FIk41RbQkjoUiQQdFtXUHFRf0VxH15R Xkp/Tg9OP07PTlROX3FYEF1fZFhJTTkRSHseQKR7Hb0eQA2mDR29pL1Qb70TDAgQREgQeERvSBBO X29IEEtAb0gQTEFve3t7ewlvrRMMCOlQQq+Q43hEb0Lor5DjTl9vQuivkONLQG9C6K+Q4kxBb3t7 e3sJpA0he3t7e3sTDAjpUFCvkOJCaVDor+DjWVpuUOivkOIRcW97UHt7CbR7QUJpDRMMCBBEXhBf Tm9eEExBb14QS0BvXhBeR29Qe3t7ewl/bK17eyJ7e2xRQWNhYFENIVAhDXtRVVZWc3B3dmVAUGNi UFNxRkZjYmZDdnZzcldWR1KqUUhmuf+uu9U5UUSDvVFCVq0QU9IxEgp3UygGDGxsUVECf8rx5cGN UVhRe66Xru0t2xhRPCovExMjUFBRUEhQUFK2VYNQRlDoEGJmVFF6VHBAcEEJVNBIVVhU70hSRUZB UkRCRkFeQ19QQF5DUVBAUkRZWF9bUQ9br1tSW+hSJBBaVlFBX0ZRr0ZRRuhSJBBOQFBQUaBQUVBW Q0RaWWNvWB9YAFhTWHhAf0EPQVJB6FFUEF1eQ3ZSRA9Q8EaQRlJG6K+Q5llcZEZJRyjpUjlQSHse QKR7IWwdrGytbKwNbKQNSbRQSG9sbw0hbK0NIWxvrQ0haWJfX19fYWBRIQ1QDUNjZWRmZmNiR1d2 c3JWRUVjRXNBcUFzSMxpySUoI3YTbm1lgoKut8xUdgDW1AN0lEBpARuNrOdTGVBQUlAErgFUMFRu UHNQf1FiEDAnTddNUkJcXSBh1l3QYVRwUXNSc1NgUWNSY1MQURNSE1MJXwlECXUGeQZ7CX+oQahD QWtdY0ZreGN8G10URht4FHygXK1HWt5cUVxbXF1belxdd15GR0V9XVxHRlRIdFHor5DlSUtkUWNQ 6K+Q415BblDor5DjW1xuUOivkON4emRQ6K+Q43N1ZFDor5DjYWRkUOivkBBZRUtkMFBRUA9V6FIk 4k9fd+hSJOJeWn3oUiQQW0VXSElWenlbdkpI6FF5EFlJSUpK32FRYVHoUegQWlBjdHFCSWAIbEh7 HkCkHb2kvR5AIaZsHUC9QK20UG9sb71vvW+tpCJ7e3t7e3u0e1FBQkdpUEFCaWlBQmlpV1hAbGFg UCENUQ0hEwgQXTlfOUQ5dTd5Nns5f1YNCVANR1VGR0ZjYmdmZ2ZlZVZzcnd2ZUBQY2JHZXFBRF5S c3B2ZWRDREZjYmZlZHZzclYpURFYTXgGPmd1Q10ukIYtMlFR75XQUVduIOvfrqKyrNMwN97YODXT FndoRU5xRmFzDsv85d+FUVtRSv3FrBfs6jps6d5eUtP5zfHO9fDNUFFQwlBQVAlV6lBGUOIQe19R T1FpUWNSY0ASURJBjlGpUVlXVUZVdFIIQThBVVFRUkNEQUJDU0RSUV/oUiQQTVNXWVpaREVaRlBQ W1p2WFkQcHRk/1lRr1lRWUpI6K+QEEZydGTASPBIUiBIoEhSv0hRSFBEdkZF6K+QEF9wdGTwRVGg RVFFSUdvbEh7HkCkISJ7bB2tbB5ADSEie6YhIntsHa1sUG9sb2xsQGxvvWlpQUdpU15AbFhsYWBR DVANUUFmY2JOUkVBcUFkdnZzclZWRUFxQVH72O0xzB9NrrdwAW0WPmOut1XqrbXPGCDY363BUmH3 CmUU2datvFXqUFBSUMNQUFH8VepQU1BXUCfpUFmvkBBvQVpvEFkAWVLQWeBZkFmAWb9ZVU9ZMFkv WfBZ4FlVU1ZXUFVUU19QURBQgFCwUFNQDVJRUFZVVldUWlJXdlFU6K+QEFlxdGRUSVhvbEh7HkCk e2wdrWxQb2xvbG9srQ0hbFNVQGxsQGxsYWBRIQ0ie0NBcUFRQXFBw1FJrrdRSVTmUVSurKsaVHar ilBSr/KuAVH2VepQU1BFUNsQHUZXdldwR2ZX5lhV0EdRU1RVUEVEXUBcQFlTX1BREFCAULBQU1AN UlFQVEVWD0BRQN5ZX1FEdlJAVVFVSt9HUR9HUUddY0BcUVxJRkZH6lI7UHFSOuFsSHt7HkCkDUkd tEgeQA0hpg1sHa1sUG+9DW9sb2ytDSFsQUJpQWNTVUBsbEBsbGFgUSENQ0FxQUVBRFZWc3J2d2dG RmNiZmZlQd1RSWXHJXoxaGFEc197Z0JU5lFUrqzAq6ub9w5fX6BUVXVk0lOlUFBRUNlQUFQPVepQ W1Cx6VBTr43jXUFvU+ivkBAtSX1kV1NAU0NWd1k2Vv9a71qYWZtailpaA1MwU1JdV0hZFlYHWCZW VeZZj1S9VKxUpVZVHlceWDZWLVTcVMtUzFXKVspXylhaT1RCVntUe1V6VnpXelh/XRtUG1VaVlZX WVpZWFpVWllTVlRbVVRWUlFQUFtbWFdaU1paW1ToUj0QSlV/WGlPV1FXNV1SW3ZR0FBRT1BRUElc bytIex5ApA0hbB2tbElApiFIvaS9QGxAbFBvbGxAbG9sb2xCR2nXWC1AlFhsYWBRDQ0NIVAiDXt7 Y0FxQVFxUVFxUVdB2VFJURlRCq7FUdWuga6l01XqrKZRJq4srQ5Rjdmu/FBRUMNQUFH8VepQU1AD 6VBVr5AQeUFabxBVAFVS0FXgVZBVgFW/VVVPVTBVL1XwVeBVVVJRUFNQWlJTdlFQ6K+QEFlxdGRQ SVRvbEh7HkCke2wdrWxQb2xvbGFgUSENIntjQXFBw1FJVeqqFlBRUC5QUFbIVG5Qd1EV6VB5r5AQ B0Fab1VWVlxFVkZcZFNkWGRIZHMUUhVYFUgUc1xwU395A1kwedB5z3n0VvdX9lzlVuVc4HmAebB5 XlB5f3kAec9573mPeVZ5EEpMZG95AHnQeYB5sHlVV+ivoBBaRUdkV3FUV0pNRuhSJOJaV3HoUiQQ TlRXQEFBd0tMTHZ3WlFQVl9AdkJBEAplMEFRP0FRQehSFhBfSkt2TUwQCmU/TFEwTFFM6FIW5HV2 dndR6FF54lBQd+ivkONfWW936K+QEGZBWm93EApldxARZXcQbGV3EHR3ZHcQam1kf3efd493U193 T3fQd1NQd3B3YHevd1R3SXizbEh7HkCkDSEie3t7e3t7e2wdQL1ArWymDSF7bK1spiENe2ytbFBv bG9sbEBsQGxAbG+9b71RQUJpUEFCaXthYFEieyENUA1Re0NxRWZjYkZHZmZjYkZHRkVBcUFkd3Zz clZWRUFxQWR2dnNyVlZFQXEuUVPbkDbGYBbyDCXyeE2ut013AWs4fq63Tm9mETh9rrdUdsH5BAUF BA8MFMitCVIPzn5sGNvGrlJSFssKfBbUya2sUFFQwVBQVAlUblBGUM8QSFdDR0MKWDhYVOhUUWRY ZEAUWBRfuUBVVuhSJBBNQVdeXVZcW1tRUFpSUXZGUBBwdGT/UFGvUFFQSkjor5AQRnJ0ZMBI8EhS IEigSFK/SFFIWlt2XF7oUXniXV1c6K+QEF9wdGTwXFGgXFFcSUdvbEh7HkCkISJ7bB1AvUCtbB5A DSEie6YhIntsHa1sUG9sbEBsb2xvvWFgUA1RIQ1xcUFkdnZzclZWRUFxQXFFZmNiTlJFVAmut3QB aRkke663UVXbgw3KH09STvw1aADU4q5PVHbM5BM41CtQUFJQAq+4VMpUblBdUElQyxAcuFG3WKdD p0VUl1K3U7hZuFtUQklVSVlSCUAGQwZGCUjHUshWyFjHXOhZhVKLVYxZhVy3VbdWuF1A91ibUpxW k1iWXFUlWNlW1FhTQehSJOJaW0foUiQQRFRXRGlXSjBLIEtSS15xUElKCBFIex5ApB29HkAhph29 UG+9b71hYFAhDVENIRMIEFk5QDZCNkY5SFRRDQlQDVENQ2RCZmNiUEVEUHNydHZ1REZjYmZlZHZz clYC2q3MoVFkrpm8wq6n2lFwxj4+xcU+PsZSctxRVtqul7+hrpPUr/jO+PjwzPj4UFBSUNuuPFTH VG5QQFBMUMoQfmhDGENSQmRTaV1pQ2RLFFMZXRlDFEupS1kGVgZaCUIGRgZICUymV6lLWFFQVkro UiTiVVdE6FIkEEZbW0BfXkdxWEogTlFOQXleXl92QEBR6FF5EFsgUNBQUlBJTW8RSHseQKQhHb1s QK1sQLQeQCGmHb1Qb2xvvW+9b2xhYFENUA1REwgQXTZWNlo5QjZGNkg5TFYNCVANQ3FFZmZjYlBB QFBzcnZ3QXFRREZjYmZlZHZzclbbUVZj/jrpUVKurOkI3x+ut1FG3jYy0tYzN9hUdswANK6Orq2u pq6JFgWtuVPp4/vN4/fyz1BSUAuuPFQyVG5QQVBNUM0QZ0JsUmRdZERsTBpSFF0URBpMWCBPUU1Y RUdkCVUJWgddBkMJRwlKBk32WvZMqFmmXadEXEFQXkvoUiTiVFtF6FIkEENbV19AVkhxWElOQnlR UVB2QUFf6FF5EFnfQFFASk8IbEh7HkCmIR29bECtbEC0HkCkHb1Qb2xvvW+9b2xhYFENeyFQDVET CBBdOVU5WjZDOUc5STZNVg0JUUFWVnNyd3ZBQFBjYkZHZXFBUWR2c3JWRURGY2JmUxln9A/lJdpR U5A6y2xRU66g1TQ22dQxMcKuPFJGFwPYz1FAUVBRTwoLzaoWU+Tzz/Lg/8v+UFBRUNdQUFNnVG5Q QFD4EHjHVVFZXlEDVTZVJVVTf0IIXjheIEJUWllfXE9cUt9cr1xSb1wfXFJc6FInEHlXV1FQWlNS Vlp4UFlAWWBZIFlUWUovQs9CUg9CL0L/QoBCVEJAUHZRU+hReRBbUlLQUfBRUlFJQW/pUUxQSHse QKQhbB1AvUCtbB5ADSGmDUkdtFBIb2xvbG+9DSEiaWJhYFENUA0hUBvgRwMb4GUBCgjhWmJoCVAN cXFBcUVmZmNiR1d2c3JWVkFR8K63UVUTOxQwCQcXbWsCf1R2xzsUZaV+EfquoVBRUGCvuFRAVG5Q elIiEM5WQVZzWHdHQUdzyELIRMd3xXpZV0QWRFJC613pXpdxtXOoXaZyVnldBV01XcVbx0L3culc VxFzEHQUdjdyNHbXQtdE1nLTdFlndhVWFlsaXR9fFnEScldydHd2Z1xlcWVyZXNldFdWWlVBWXFI XXdccnJyc1d0chB8I1woRClFJnklethF1HrKRcV65HLkc13QUd9H3EjJevl64HxWcuivm+N4emRx 6K+b43h6ZHLor7DjTnRkceivsONPdGRy6K+w40lKZHHor7AQS0lKZDtdUWZyFnLIXcRylHKEclZx clxdVFRKUOivkOVJS2RQY1Hor5DjR31vUeiv4ONZWm5R6K+Q43J1ZFHor5AQT0pMZFBRYFEQUQBR VDBR0FGgUVNQUUBRAFEwUbBRVVHor5DjQ0ZkUehRURAiUFRRD1SgVFJUFnhbRhBJS2RGY0cQR31v RxBZWm5HEGVnZEcQe35kRxB1eWRHEEpMZF9HT0cPRz9Hv0dVRwVKEHJ0ZF9KUQBKr0pSShZDV0dx RhBxc2RGEExPZE9GUY9GUUZjWHEAdd91UnUQSE1kdUp86K+QEEdBWm8AfFFgfFF/fFF8TnFgQFFA Y1FxUOivkONfWW9Q6K+Q40Fab1Dor5AQWVldZFBJeyjoSHseQKx7e3sdvaQhvR5ADSEie6Z7IR29 pCEie3u9UG+tDSF7pA17e3t7e3u0e2+tDSGkew0hInt7e3u0e0FCR2kNIXt7e3t7e2FgUSENUCEh ISENDRMMCOlQdK+ZEFlbQm9feFtCb3Hor7zmXWlcRFxpceivvOJcaXLor7rhW2lQe3t7e1F7ewlQ IQ1DdUZGY2JnZmVkd3Z3dHd2ZWRmY2JGR1V2dnNyV1ZFREdGVEdGRURWc3J2YFFKQj4zPWd1REUZ rvwLLoq1ioR4rqdBDwg/YHBMdlGRCQikv4mtUX97AgV4TH9wRURBG24Gydrs3tthbhJPRnNORUw2 GhvWwoLgUFFQT6+4UsFVzVBJUJ0QeXBQcFFzWnlfal4aXglfV0lFUEhTRkVQR0JDRFFHQlJEUUhT WVdaV1xI6FFREF9QR/BH4EdTMEfwR5BHU0foUVTiRVFE6FIk41BFVlfoUiQQXlxbWX9af1BQf1EP UVJR6FFUEHhIU3ZHQgVFb0TPRP9EUzBE0ETARIBEoERVUERARHBEYERURElKKPBIex5ApA0hIhvg ZwMb4GsBCgjpUESvkGgJbB2sbK1spA1sQKRJtFBIb71vbK1sQKQNIbRBQmlBY19fX19hYFENUUVz QURGRmNiZ0dWc3J2dnd2ZUFzZWNldUFSKpBbd0x3GkgyLBwqaVtZ0dFRSlR2sK4E0ntMS4p6YwEV YcVRn7CD9K7ZUFFQ3a+4VANUdlBGUMwQRwdBN0HGVVNZVklWbFJsQRtSG0G3Uldf6FIkEEFUW0ZQ WkVERFpZVkNEdkVFUOhReRBeRhBwdGT/RlGvRlFGSkjor5AQRnJ0ZMBI8EhSIEigSFK/SFFIWlt2 WVjor5AQX3B0ZPBYUaBYUVhJR29sSHseQKQhIntsHa1sHkANISJ7piEiex29bECtbFBvbGxAbG9s b71hYFANUQ1xZVZWc3J2dmVBcUFERkZjYmZmZUFxQVMeau05O/ocUUlPAm8YInpRSc8FMg76xlLw rkiwNWsfJbRRkKuKUFBRUFtQUFQKVHZQW1C+EEVVeEp/ZFd4Sn9kVnhKf2RYeEp/ZFPor4jjSn9k VOivkBBwSmpkylRRVlNbWFhaXFtFUUVSQlNKWUpaclB9W5dbXFDor6AQeE1wZFpQVVtEUElbdVB6 W2RQalvXUFlbUFpUW1pZWVJSUVZbUFpZaV3or5AQSEx4ZFtdT11gXRBdVF1HR0pAWm9aH1pTWuhS YBBbVFJpW1RvVB9UU1TqUmBQUa/QEF9cZVBRcFEQUVNRSVyU8Eh7SR5ApA17SB29Db1ArQ1JHhU1 FLYNe0gdvVBvbG9sQGxAbEJpUUJpaWFgUSF7DVANe1F7e3t7e3FRcUNHZmdmZ0NxUVHnrgRRd5hq R1ZeQJpRca4KVHatsuUVRn19Uk6rilBRUFlQUFZoVHZQXFG1EGFQW1FaUFZSWldVWUtQRlJOVEFV SldEWU5aQVxcQntTe1ZzW2lTaVYYUxhWyFPIVlle6K+QECh8F2RaUFtUVFVUWVtaVFxLUEpURlVE WUlaRVxcc1B4VHdVfVl4WndcYVBnVW5ZFlAXUhdVGFcZWSdQKFQnVShZKFonXNdQ2FTXVdhZ2FrX XIlQiVSFVYVZiVqFXLpQulS0VbRZulq0XKlQqVSmVahXplmpWqZcfVXor4MQWUtqZFR2S2pkWeiv ihBZS2pkWnZLamRc6K+DEFlLamRQdktqZFbor5DjSWpkU+ivkBBdSWpkWxBJamSSW1RVcOivHeNW Wllw6K8cEGJTUFxwW1ZTU1xQUlFUXFNVWltXWVhWWFdXVVVUVFJSUVZcWlpZWVBaf15vXlJeR0dK WBFZUV5QcFBWUj1QW1I9UBBQU1Fe5HBRSV2U6VFKUEh7HkCkSkkdrUpIra1KSa1IHhU1FLYNUG9s QGxAbG9sQGxAbEBsQGxRQUJpaUJpaUFpaUJpaVBBR2l7e3thYFB7e3tRe3t7e3t7UQ0he1ANEwwI 5FsQXWlW6K+o4l1pU+ivqOZdaVsQXGlW6K+g4lxpU+ivoOJcaVbor7DiW2lT6K+w4VtpUHt7e3t7 e3t7CVENUA1xUXFDQ3FDQ3FRcVNTUQmu4FFBl+dRX+GbUUWu+66i5+RUdq0YUuitGFLoq4pS+60F UFFQXFBQVDBUdlBbUdAQ23hXmFRSyFfpUYxRhVegXVVYV0pUSFZ4VmdQaFgYUQlRLFElV1p2UXtX ZlFqVxZRGlfIW6hWqFdZdVR2V3paZFRqWhNUHlqTVFgcWgRUCVo0VD1aKFEtWsRUxlfqWoVUjFqs Wl1TVFdXWVpGVHBUelpjVG9aFlRZRVRJWmpaHlo7WvdU51SZWqZUWVfor6DjQkhkVOiviONFR2RU 6K+wEEVcQWRRVFpXVFBSUVRaV1RYUFlYU1Por7DmeX1kr1NRU+ivsBBfRnRkU3ZSWURSUllVVltb 6K+w5nl9ZKBbUVvor7AQR0Z0ZFt2UFVEUFBVVlVVU1JWWFlZW1BV6FI94lZjWehSPRBbWDUfXc9d sF1TXVPoUj3iUmNb6FI9EEKgUFFQUEBQcFBgUFRQNVyU8Eh7SR5ApA0hSB29pL1JHUANpkgdvaS9 UH9sbEBsb2xsQGzXVX57eyF71y2U135Ie3she9ctlFFBQkdpUEFCR2lhYFB7e3sNISEiUQ0hISJj UVFxQ0NxUVFxU1NcUS+uwVEH7JZRGq7IUdmu94iKUnNSU66MUXSuWa2BURmu51BQUVBergFUAlR2 UENRZORCeFVRQ+ivsBBIXF9kWEZdX2RXRl1fZFZGXV9kVUZcX2RS6K+QEE9KamRVVlZUXVteVkBS UENWVENSVFNTUVFQVkMwQFFA6FH/EEJbX11/XnhQcEVgRTBFU6BFUUXor5DjcnZkReivkBBCTE5k RUdHSlRpUxBISWQvU1FT6FF3EFlSEEhJZC9SUVLoUXcQQlFpUBBMZmRwUGBQUlBJRJTwSHseQKQN ex2tSaQNe6QNe0itHhU1FLZ7eyEiHUCktFBvvQ1/b2xAbEBsUUJpQWlQQUJpQmlpQWlXXkBsYWBQ e1F7e3t7ew0b4EADG+BqAQoI4lRAUOqvoFBRr6DhU0BRaGhoaAkTDAjpUFWvuBBeXUFvQ0BDSW9D QEJIb1Xor6DjQ0lvVeivoOJCSG9Re3t7e3sJQ3FDQ3FRV15Tc3J3d0ZjYmZnXlF7rqhRc67ZE3UT By8AAR5JEmUyDklUdq1eUqKsUukNMm1yQYxdIwlQUFFQclBQU4ZUdlBAUXjkQplUUVHor68QYUBB ZFpRQEFkV1FYWlKnUahaUmdbF1oXXAhRCFI5UTlSL0JYj1SAXL9UsFxUWn9U8VfrUiRQWFBaUQQQ WVlZWFZRf1zxX+hSJBBfQEBQWt9Uz1RSVHB2fmRU6FF75FlaY0Bf6K+Q419Zb1/or5AQdUFab1Bf QF9wX2BfEF8vX1ZfShBCUZBCgEJSQldYY1DQXMBcUlzor7AQWXZ+ZFdcR1xSXOhRe+JRUVDor5Dj X1lvUOivkONBWm9Q6K+QEFlZXGRQSUEoK0h7HkCse3t7bB1AvQ17IkCkbB5AISKmDXt7bB2kbL17 IlBvbECtpbRvbEC9QK2ltFEhYWBRDVANIXt7USETDAjpUFKvoBBaW2lbQFxpW0BdaVB7e3sJUGNl UWZnVldVZXFFUVdmY3FFclHeMn9hAK7ZUz6uOt8lTFHji1GZIH9TUVK5l658y1enUFFQbK4BUrhV g1B+UPAQRnh4KH3YfVNJT1dJURdQUHRvXx9fUl/oUsHnXkFgcxBzUnPoUsEQRXRDdHNzXnBfUV8Q QUVkXzhgf0NRQ+hSweVYWH9FUUXoUsHmV8pQf01RTehSweR7f09RT+hSwRBfe3rKUXBQP1BSUDh/ OjtIe0CmDWykbL0NQL0NQKS9DWxAvQ1ApnsNbGxAbFBvvQ1vvQ1CaX+9aVFBQmlhYFENQ2VuUmdm ZWRmZmdmY2NFclZWRURXXlJXTlJHRkVERkZjRXNyflJlZHd2dmwZGmZaWHQOCm3TZT9vTllVehET axt4VldwETxl18AzckBGCVHKoFR0BRBgJ5LJDUtCv0ljbm/gMysAe3IL0j32fhJkS6B7NMPO6GcA FVBQUVDgrgFR31WDUFNQHBBZAFVREFUAVVJV6K+Q40tNZFXor5DjQUNkU+hRyBBBUVBSUxlQUD9R Ue9RUVFJVLbpUUlQSHseQKQNIWwdQK1sUG8dvWFgUXt7DSFDQWNB4I+uAVfSqC5QUVB9rgFSiVWD UH1Q/xBJJlLXUoZYU3hYUUdDeEd9F1BQcmBeEF5SXuhSweddQ29xH3FScehSwRBackFxcnJeYF1R XeivkBBaQUVkXTh+cEFRQehSweRXcENRQ+hSweRWcExRTOhSweR5cE1RTehSwRBFeHh5ylBXVspQ UGB9MH1SfTh/8ztIe0CkDWxApGxApGxAvQ1AvQ1AvQ1AvQ1ApnsNbGxAbFBvvQ1vvQ1CaX+9aVFB QmlhYFANUQ1RXlJXVkVEVlZXVnNzZWJuUmduUmd2d3Z3dnd+UnNlY2JOUkVER0ZGR1KJGRplW1hz Dgtt02U7Ek9RWFV8GWkacn9BW1VRSREhZdfAMnNfRgoMUcpUdAUQYCaSyg1LQqBLYyr8OC0HcWB+ EjYWvhtiS796NcPO52gAFVVQUVATUldUOVPMUERQ0RBqVFJbWVtcWEFURERSS1lLXEREeUFpXGZE XGZSaVlSelx0RFJ0UnpZUmBTEFNSU2dDYFoQWlJaZ0N7W+hSyBBxYFcQV1JXZ157YFEQUVJRZ1Bb X1pPWlJaSkZRUElFOjtIex5ApGxApg1sUH8dvQ2kvQ2ktL0NQL0NYWBQDQ0NDUNBZmNiRlRjYmZn QVZWc3J2d3ZzchMv+W86UUNhaMMWfvUIYg83ygjcUldRU9pJPxUbrqJgBEh9E6+vUFBQUFXvVq9S dlB0UFBRV1DeUSpRfFB3EF5TUh9C/0JSf0LfQlJCWehRDuUYe1JTUkLpUmRQeVB7UXsNIWVlUK+v UFBQUFXvVo5SdlB0UFBRV1CXUdBQjFBFEF1TUl5ZUBh7UlNScFJ5UHtRe2VlUK+vUDGuDVUOVYNS dlB2UFBRV1CYUftQUFByEElRwHLgclJQckByMHLgclRySHQYe1FRelh5UHtRew0hZa+vUMVQUFSg V2lSdlB4UFBRV1DdUQJRNlB8EEVRcF8fX99fU1BfcF/PX/9fsF9VX1HoUhPkGHtRUV/pUmRQeVB7 UXsNIWWvr1DIUFBVc1daUnZQYVBQUVdQllHEUQZQfRBNUS9I/0hSSBBKTWRIEEJIZEgQW15kSFRQ GHtRUUvpUmRQeVB7UXt7e3shZVCvr1AJr7dVt1avUnZQYlBQUVdQ3lHqUXxQZRBKU1JQT39PUtBP z0+gT1NfTxBPUj9PL09ST1for8zlGHtSU1Jz6VJkUHlQe1F7DSEhImVlUK+vUMOvt1V0Vq9SdlBo UFBRV1DeUdpRfFB5EF9SUT9xUS9x/3FSH3FRcVfoUQTlGHtRUlJx6VJkUHlQe1F7ISEiZWVQr69Q Ga+4VH5Vg1J2UBRQUFFXUN1QolBQUE8QQVIfZlFwZs9mUmZUUBh7UlFm6VJlUHlQe1F7DSFlUK+v UBmvuFR+VYNSdlAUUFBRV1ATUIpQUFBFEFpSUWRUUBh3UlFk6VJlUHlQe1F7UK+vUBmvuFR+VYNS dlAUUFBRV1CVULZQUFBLEF5SD2g/aFJoVEk4e1JRZ+lSZVB5UHtReyFlUK+vUBmvuFR+VYNSdlAU UFBRV1DeULdQUFB3EF5TUk9qL2pSf2rfalJqVOhRCeUYe1JTUmrpUmVQeVB7UXsNIWVlUK+vUBmv uFR+VeRSdlAUUFBRV1CWUL9QUFB4EEBSX2NRj2OvY1J/Y+BjUmNU6K9t5Bh7UlEU6VJlUHlQe1F7 DQ0hZa+vUBmvuFR+VlJSdlAUUFBRV1CXULZQUFBHEFxSU1JmVFQYd1JTUmbpUmVQeVB7UXtQr69Q Ba4NVG9UblJ2UBZQUFFXUJhRRlBQUHrmUUBxD3FSceivkONISmRx6K+QEF1ARGRxWncYe1FReVh5 UHtRe3t7DWWvr1ARr7hUd1WDUnZQGFBQUVdQ3VC4UFBQYRBBUrBwoHBScHAfcFKwcKBwUnDor5AQ W15BZHBbeBh7UlFw6VJlUHlQe1F7ew0hIWVQr69QEa+4VHdVg1J2UBhQUFFXUBNQgFBQUE0QQFJf Tk9Ob05TTltaGHtSUU7pUmVQeVB7UXshZVCvr1ARr7hUd1WDUnZQGFBQUVdQlVCMUFBQRRBaUlFy W1o4d1JRcelSZVB5UHtRe1Cvr1ARr7hUd1WDUnZQGFBQUVdQ3lCMUFBQexBBU1JvTVH/Te9Nj01T D01RTVvorpDlGHtSU1JN6VJlUHlQe1F7DQ0hZWVQr69QLlBQUhNVg1J2UJRQUFFWUN2TUFB05lFX EEJFZFfor5AQW0hMZFdR0hh7UVFX6VJlUHlQe1F7e3tlr6+vuVBQUf5Vg1J2UJRQUFFWUBPvUFB3 4VFV6K+QEFpCRWRVEEpMZFVS6K/Y5Bh7UVFV6VJlUHlQe1F7e3tlUK+vr51QUFIiVYNSdlCUUFBR VlCVmlBQdBBdUT9ZL1lSL1nfWVJZUuivLOQ4e1FRWOlSZVB5UHtRew0hZa+vr4BQUFIgVYNSdlCU UFBRVlDem1BQcBBBUlEvW1GvW1FbUoIYe1FSUlvpUmVQeVB7UXsNIWVlr69QwVBQVAlV5FJ2UAFQ UFFXUJZReFBQUGYQTFHwR4BHUu9Hn0dSIEdRj0e/R1JfR09HL0dTR13oUXzkGHtRUXjpUmVQeVB7 UXsNDSEhIWWvr1ACr7hUylWDUnZQAlBQUVdQ3VF9UFBQcRBDUkBNUQBNME2wTVNNVGIYe1JRTelS ZVB5UHtRew0hZVCvr1ACr7hUylWDUnZQAlBQUVdQE1FEUFBQcRBDUi9L30tSSxBbXWRLVFoYe1JR S+lSZVB5UHtRe3sNZVCvr1ACr7hUylWDUnZQAlBQUVdQlVFwUFBQRRBaUlFPVFE4d1JRTulSZVB5 UHtRe1Cvr1ACr7hUylWDUnZQAlBQUVdQ3lFGUFBQdxBeU1JfcT9xUk9x/3FScVToUQnlGHtSU1Jx 6VJlUHlQe1F7ISJlZVCvr1ACr7hUylXkUnZQAlBQUVdQllF5UFBQZhBLUsBKUa9KUZ9Kv0pSX0og SlKQSo9KUq9KUUpU6K8S5Bh7UlF76VJlUHlQe1F7DQ0hISEiZa+vUN2vuFQDVYNSdlAIUFBRV1Dd UXdQUFB/EE9RP0ovSlIfSg9KsEpT/0rvSlIASjBKUkpfZhh7UVFK6VJlUHlQe1F7DQ0hImVQr69Q 3a+4VANVg1J2UAhQUFFXUBNRX1BQUE0QX1FPSFHASFFIX04Ye1FRSOlSZVB5UHtRew0hZVCvr1Dd r7hUA1WDUnZQCFBQUVdQlVFLUFBQRRBaUVFMX3M4d1FRS+lSZVB5UHtRe1Cvr1Ddr7hUA1WDUnZQ CFBQUVdQ3lFLUFBQSeRRUlJOX+hRJ+UYd1FSUk7pUmVQeVB7UXtQUFFQFK7yVHNV+FBbUBYQfFBV UFl/Um9SH1JTUmhYU1mhWldoWmhQVVGhQFKfUlIPUv9S71JTUklcOhNIex5ApA0hHaRsbL29QLRQ f2ytDWxvf2FgUUFxZXFBcUFxRXFBUeGuw1E9UVdRO67FrvJUzLhR0q4uuKs0UFJQBlMFUoRVg1Bb UEdQaulQWVFR4l+KRehRUeJTUVboUVHiQopc6FFREF0PUD9Q31BTUElIHRNIex5ApA0dvaStUG8d vaS9YWBDZGZjYkZFRFZzcnZnREZjYmZlZHZzclYG69TU6+vU1Ov2Cm9vCgpvbwpUxNXq69TU6+vU bwoKb28KClBQUlAErj1UblXgUE5QdlF2ED51dWlPGlEYSxt2B1kHSghPOEvYSdd2+ErmUOdPh3Zf J17XXlJnSlFoUWlYUkR1e050dmpKaksvTlZKUFFcXV1JR092X15eSEZLTnB1UltAWFpFRktOcHVS W0BYV0JJXV3IXkhEXl5ISWNIUExjTepRUVBxUiTkRVdXY1bqUVRQU1Ik5lpbXmNdXkjoUj8QcEkP f01vTR9NU01xTH9/Vm9WH1ZTVnFQV0BXcFdgV1RX6K+Q5l1BZFdKeF3qUj9QXlFR5XB0UXRxQuiv kBBZXUFkQkl3CCtIex5ApHsdvQ2kvR5ApnsNHb0NpL0NpL1Qb7RvraS0b62ktG+0115+e14tQJRR QUJHaVBBQkdpV15AbGxVbGxXQGxsXmxsYWBQDVENDQ0NUVNGY2JmZ1VWVnNyd1N3Q3ZSZUBQY2JH Q0dTRkdVdnd2c3JWRURHUrjmRkcfN0VRRHuknGJjJSok2sVRRrx9YSErIO0TrrtczF1bOi0cU3ut 9lQLP3/ukleuLnJR0WxRQepRU1F0VlEoc67dGLZiGA5RwvqSBlBRUF2vt1QDVYNQZlCdEHhXW0hS RltnWFTzVfljiWNTKnzYfFJoWBhZUnZSe1hSS0hMdnV1QkJB6FIkEFxAeF9fd0BASFRMyk/oUiQQ W0hRUJ9RxFQAf1F/6FIk539XUVdlWXtl6FIk5FRbTGhL6FHQEHREUNZRSmh2d996QUBAWnpoX2Vy y19EUUTWQFlRWdZaSWfyLEh7HkCkHbQNpA29pL1AbEBsQKRsHkCmHbRArb1Qb720pA29DUCtvW+t tEFCaX9sbEBsQK1sQGxAbEFCaWFgUQ0NDQ1QDVFHVlZzcnRzcld3ZmZlZHdzZWN2ZWRmZmNiRkdV dnZzclZFREZHcUVxRkVEVldmY2JHRkdGY2JTtzxpxRYKroQYKi87ITNUgM15J4rRlbpKrqFDNBsA Ok1FUWiuplNsDWcDc0xeFCl8HlFNvk93BQeiAecDS06NJik9ljeX6ng7DjsBetppjUZGH9Y9TFRS QU9QUlBrrgFUfFWDUGNQEFFhENcqe/p89WRT1kPXStZ0U3p8OEI3SlNaR1VgSUZGf0Zkh3aJZIhq WHVDyFvJalP0evd/iXVTZHRCUUJuRWt7Z35QX194KV8pZ1QDeANuIG5TIHjgeOBuU5J4v1+/Z1OS bqtyrWdTT3JNZFJFeGV4Gl9TWmcaZzpnU35XeG5fZ0VyQmRre1xIYUvoUsPjTLVPUOhSwxBbUdhU TwxIVAxhUXLqUeJQRa+QEHVcQGRFbl/PUVFRaG9QH1A/UFNQZfBnUWfRX0oSwExRTGhLbnhX6FHi EEZ+Zf9uUW7RX3hPeJ94v3hUeEkROjtIex5ApA0dvQ2kvUCkvQ0eQKYdvQ2kDb0NQKR7vVBvvX+9 QKS0QKS0QUJHaSEhIQ0NDQ0NUUFCaWlBQmkNaWFgUA0NDVENDQ1RVXZ2c3JWRURHRlRHRkZFRFZX RkZFRFZzcnZ3dUZGY2JmZWR3dlB2ZWRmZ3Z2ZWRmY2JGU2ZmZWR2d3VWVkVER1OKrr1UHxYRFH5P UQxoBxsLC21sjoCYoEZRQkI1HRIedXauZ9oKD2Jjg++Usbd8e343rr9yZNdU0k0aHml0YX1OsGAZ 3wcNzRBoLxfEmJb1cQoLFWF/dXVRc5AnMvhmZiBq1+vrrF14GXJxFhuWRBp6NQtQUFFQElH8UsFT q1BbUE3sUFlRPVBTUFBRYuVWSVw6O0h7HkCkHb1Qf71hYFFEVnNydmVkZmNiRlLB/Sor/f0rKv1S hCv9/ioq/fxQUa+urj1UOVXqUEJQB+JQUUDqUb5QUlEuEHBbXUIZXFtQXF3WXl5fGUBAX0EfQd9B U0EwQkJQGVFRUuhRXOVVSUPDPEh7HkCkHaRsQK1sQK4hbECtbECkbFBvbK1sQK20aWlhYFFzQXZ2 ZWRmZmdmY3FBc0FzQXNSK6PunALbDmjzUgUhvcCuPVRHXojiOf82RFyuq6noVhhQUFFQ26+4VMtV g1BjUOsQeW1ICVoNRwhIuXK4c1ZVV1VDRldFQ3lHe3N7dFdWQEZAd0lTScZASFFI6lFzUExSJOJF W33oUiQQWVVRY1BaMElRSehRVBB1T0hRD0g/SL5IU0h4GXVRdXFcBXpxX1hRX1hPWFI/WC9Y31hT WOhRVBBLT3FCSgBlz2VSZWJjCVHQUPBQoFBTUElkbxFIex5ApCFsHa1sHkANph29pA0hIr2krQ2k DSG8DVBvbG+9b72tDbRhYFANUQ0NY0FkZmZjYkZFRFZWRURHTlJFRFZzcnZ3Z0ZGY2JmZWR3dnd2 ZWRnZmZlZHZzclZXVkVB2xec85yaPUBJQIAYmco6/nyURWRPeWlOQSn5EWNCEmdiGV1CU+iYgNP+ 0QeXfEBxdEeCwh7Bkz0AI3d4a3x5ekki8g1r1zhoTnxuZHln+6wYUFBUr6evjFWjVYhQX1BPUGhQ E1FHEClpTvdR+Vf5WfdfVWlCZkZmSlMfYx9kUkV61Xb3U/dV+Fv4Xf97jXtYJnYpYy1kUzhN2WTM Y1M3QzdFOEpTZkYKZDdHU2ZCaUppTlN5ZGlSZl5TYGR7U2FqaRVmZ2doEhMVciBxUXH+QNhQUWFi YmgvcFFw/kjYWFtu6FFREF3PeFH/eJ94j3hTeBti6FFREFpvYSBh0GHAYVRh6FJ2EFpM2NBUUVRK FRNo6FFR5nHfcM9wUnDoUnblRNhcSRQO6VEaUEh7HkCkHa2mDWytbB5Apg0draYNvaQNIb1Qb62m DWxsQGxvraYNbK1sQWl/bK1sUUBHY2FgURvgWwMb4F8BCgjpUHavsGgJUQ0NDQ0NDQ0hUA0NUWJU QkVEUlRzcnRSZWRCdEdyVFJFREJUY2J0QmVkUnRRQWNiR05SRURWV0ZGR0ZHR3N3dnZzc0FBY2Jm ZmVkdnZzc1KllVE6n5uuxZiYrsWbn1E6ls6ujvfzUXTw8VFz9Peuja5X9bhMAgttIzh1eHNZYzCc FBUKFXsT3xV4dxjdE1WIla7AmZiuxZubUTuYmVEglcbOrojy8a6M9PRRdPHyUXjOq65TfVJXYzkQ CC1fXnF+XAf01NUVruJRnkZnc3JlR1BQU6+nr4xVo1WIUF9QT1BqUKcQBtZm91H4V/hZ91+JfVYp ZCVm2WRTNWb2aodyU2hOOU1SZko5QzZFU2lTaEJmRlN4cnh9Z3xTN2P2U/ZV+Fv4XZd5VmZGN0dS ZkJoSmlOU3h1eHlnXlNx6FLD44BwUXDor5DjWVtkcOhSyBBcaBUvdFF0/kjYWFt+6FLDEFmPf1F/ EFlbZH/oUsgQeGIVIHtRe/5A2FBRf7V+fnC1b3HPcY9xU3GHTNjQVFFUSmxltYB3UXfoUXbnRNhc SWvDZEh7HkCkHa2mDb0eQKYNHa2mDb1sQL1Qb62mDa2kew20b62mDa2kew20YWBRDQ0NDSFQDQ0N DQ0NUWJUQkVEUlRzcnRSZWRCdEdyVFJFREJUY2J0QmVkUnRDR1ZWc3J2ZWRmZmNiRkdXdnZzclZF REZjYmZSpZVROp+brsWYmK7Fm59ROpXOro3281F08PBRdPP2ro1M8XbgKvuIMOUgK/V+8kwJbQsk IgATMlWIlq7BmZiuxZubUTuYmVE/lsfOrony8K6M8/NRdPDxUXjOrXdmLtawldGaNCUudhkS2cLC 2h9QUFJQiFLXV1VV6lBXUERQmhBuaUJRdUF6QmdBU8lclEGbQlM9XCNaK1xTA1oLXDNaU9Va21zF WlMbW1EQWwBbxVtTW0FCX15XUFREQ1RSRFjoUS4QXFlSVbRdXFpZVFBdXuhRURBCQF8QXkBkX/5B MEIQXkBkQv5E6FFR4lhYWehSxuJVnlfoUVHmUJ5SUFNRU+ivkONeQGRT7FLOUEVQnVFIUEh7QKZ7 DWykraSmbECtpnumpntsrWxQb2xsbGytbECtbEFCaUJHaVFBQmlhYFAhDVENDQ0NISFRQXNlcUVz QXFBcUNDcUFzQVNzU0FRha1SyaZRCVFTxcZRU87hxuBS11L13t6tC1NjrZxSZKydUt2tI1LdrSNQ UFFQ61T4UtBVg1BTUBMQQ1FwQkVkUXBOdGQAU1FQU0BTUlPoUQkQWVFQU7VQQFJRUuhSMedRPlBJ VLYsSHseQKQdpL0NQL1Qb70NIWFgUXt7Q0NxUevaUWuuvVT4UXuuhVBQUlBVVLJS9VWDUFNQV1Bm EE9QV59VVVJQVZ/gVrBWUlZKWVOfD1BRUElYWflxwzxIe3sepA0dvR5Apg0dvVBvbECtbGFgQ2Vj RWNlY0VVoe2iVLKhoaGhUFKv+lBQV81V6lBfUENQtRAYAEQwROdAU9BE30VSf0RgRBBEU1VYWUFd XFxCQF5fQ0NfX3BQUURQUFFWVXVXQFhRf1gfWMBYU1hYVFlBQHVdXl5fU1R1UUJD6FEDEHdSUVJa WXVbXFxfUFhXVhtTUhhaUFtRW0oQRVFFVFlwXAZAQlFCH0PsUkdQX1IxUFFSHxBbT1B/UFJQSXBE UUToUfHhA0h7HkANpA0dtK2krg2krWweQA2mDWwdpGykbFBvbGxAbK1sb2ytbECtbEJpf2ytbEFC aX8NIWytbNdVfnstQJTXbJRXQGxsU0BsbGFgUQ1RIQ1zUXFFcUFxRXFBcUVxQXFTUXFBcwZS/FV8 rXpSza0zUqGrt65UxlFTUcIjVeqoruqoriOnUQmu91IJUtNQUFNQb6/+VlBWUFBEUExQdFChECBX UVhcR1FIXHlbZ1BpW9VX2kHWRNpJ1XJcVkhYcUNIRU5McXdOOl8pXydMKE3WVFtTTU5bXFxSUEVM Xl1dUVpPWXBERkNFTUxOVHBHTE5NRVRKdFVzVl9LQEpdhFwbcH1ZWVKEURtHfUNTX1FPUVJR6FIM EEBSGHN30FZRVkp2UFxAXFJc6FIMEERdGEp330BRX0BwQGBAU0BJdS6TSHseQKQNIR29SaRIvQ0e QKYhHb1JpEi9DVBvvUmkSLxvvUmkSLxRQUJpaUFCaWlBR2lQQUJHaUJpaUFCaWlXXkBsbGxsV15A bGxsbGFgUQ1QDVFnR1dGQkVAUHFwd1d3Z3ZBQFBxcFN2c3JWRURHUVFGY2JCQWRUh87b9xMari6u k6699fLe+8JR0lESUVtYNcvmsH5Sha3JN8HitVUf4SrsCq6pxK7zrj8t5iyQk1FpUQtRwq7+Bqut zyFSRa0dClFSUVDyUFBSUGJQUFRjVTVQW1BfUNIQc1xdUFJeX0FYVjJYYFMQU1JTZ1lSMlsKXmBd EF1SXWdfXFpb6FLyEFtQVFVRUDJSWVgyVuhS8hBKVTJTU1JSXV3QXPBc4FxTQFwAXFJcOEDzO0h7 QKYhDWxAbEBsQKStpGxApGxAbEC9UG9srQ1spqRsrQ1stFFBQmlpQUJpaWFgUUFxQXFBcUFxQXFB UUFxQVHirtBR0FFQUdGuL63QVFFRNFEtUVdRLa7Trqmu067MUVeuqVBRUFFQUFQ5VepQSlESEA9X WGsZVxRBUhVXGkHXWthdVAdXCEFSZFdqQVJzV3xBUidaKF5SJ1dRQUBARFdYWFRbWllZXF1eX19c XElcWEpIEF9BZF9IUa9IUUi7RUVTRFRQEF9BZF9QUa9QUVC7U+ivkBBFSU9kUwpfVFGvVFFUEF9B ZFS7V1dB6K+QEHVAQWRBjEBAX1lYUEpaR0ZD30JRQm5AUVJV0FZRVm5YX9IQQFFA6FFcEFtEREnh SlnSH1hRWOhRXBB2VFRKEGJlZEoQfWBkShB5e2RKEHR3ZG9KL0rfSlMQSlFKokvDPEh7QKYNIXt7 e3tsQKQNvUCtbECkDb1ApA1sbGxApA1sbGxQb29sbGxApHtsQK17DSGue70NIXtAbEBsQL0NIXtB QmlRQmlXQF5sbFdAXmxs10BVbNdAbGFgUQ0NDQ0NDVEhe1FxZXFlcWVxUXFDRkdmZ0NxUXFFcUVx RXFBcVH2rt1RI67dUVWumVFkmHZAQ3OcUWSulVFZrthRKK7YrrdRQY0ojVInrgYAbRIbUfqt2Y0o ja6/UFBRUD+uOVRlVHZQSVA3EEgpQSlG+UH5RlRYW0hfR15YUVZeWltRVlboUiQQcUNbSV5ef1t2 XVBcQFxSXEpLUUh2SUlQUEBQUlBJSrPoSHseQKQNbB1ArWweQKYNbB2ttFBvb71vbG9BQmlCaWlR QUJpYWBQDUNxQURHRmNiZmZlQXFBcWVeUnNyd3Z3QXE/UUd6ZThoNGBRTK6qTmYLdhdnd3+uuVR2 rk+AGzEY0OFRtKuK0GhoendNBq25UFJQdVK3UpRVg1B2UGNQ8RBkREheQWRXSUhLeUtoSzdXJ1fX V7pLtnurS6Z7W1pLVnuGS1NBSEVMZF9BW2N3TVRgtENeX+1RK1BDUStQVFBRUsMQflAQREZkb1BR UGVztFRRd01NMGNRY4VaXnRfW1FbHmVQhVF0P31RfYVG1WTzO0h7QKa9DaS9QK4NtGytDWxAbFBv raQNe7RAva1sQL1CaWlRQUJpaVB7YWBQIQ17Q3dmZmNiR0ZHRkVFREZHc3Z3VnNydmVkZmdmZ2Zn ZHd2d3ZzcldWR1ZXVldWRURGY2JmZa7tR9vdwxthSF9dQe5dWgjQItBvbX3fH35RUUFIa2RKQ5dG eDxEeGZ7ahtUtHYzNndJEHgivzgXckp9CSkPFA5LQ0xAQV5XYV9FQV2BXVhHXEl4T2IDH1BSUEpS tFKAVYNQW1BHUBwQXLlduUG3RLdGVF+0WehRKxB1RbRTUTBCUUKFcFZgVlJW1Uk/XFFchVBQcFBg UDBQVFB0SPIsSHtArA29DUCmDb0NUG+9rb1hYFANQ2RmY2JGRURWc3J2Z0RGY2JmZWR2c3JWSu3O ze7tzs7tgxpraxsba2saVAvilpfh4ZaV4D4NDT4+DQxQUFNQCK+4Vu1UblBgUGtQGFGQEDtaYFFU c0RzeFh0c2lYZV9lcxlYFV8VcwdvNW/XTtZuXldBVHRGQFNaXEpcF1IJXzlf107QGsh4pXhZB1IH TjdOJk5UeFtnThlSU8dBUVd+VHNJcHNXbGt7a2EQS01kX2HvYZ9hU2EQX0FkYetS3VB7UHqvkOJM aXror5AQfktpMHpRenpmfmwQe35kbBByd2RsEElNZD9sr2xSbBZfRVFQRUBFMEVTRUUUTFHor5AQ WUlLZFFjMFBRUOivkONNcGRQ6K+Q43J5ZFDor5Dje31kUOivkBBZRUxkUFBAUFJQ6K+Q5EJpUA9+ 6FIk4lRUFOivkONISmQU6FIkEENaW01jX0xPTD9MU0wFSRBISmRJ6FIk4nBwZuhSJBB9dldQcVF/ YXFQekB60HpTekpwGg8a3xpTGntxRXlfbNBsUjBsr2xScGzAbFJs6FIWEF0RTN5NYxFxXUkZCOhI ex5ApB29pL1Apg0NIbS9HkANpg0dvaS9UG+9bECte6QNtG+9e2xAraR7DXt7e3sNtHtBQml/DSG9 DXt7e0FCaX8Ne3tsrXsie2xRQWNCaWlQQUJpQUJpUA1hYFENDQ1QIQ1RIVFVVlZzcnZ3VlZzcnZl ZGZmZ2ZnZmdlZHZzclZXd2ZmY2JGR2ZmY2JGQldxRkZjYmZDdnd2dnNyVldWR1VWV1ZWRURGY2Jn ZmZVzFFDabjkIO4dF7En+u4TDwV4ljMWBAsADkSvYoeMOPNqbcED8I0vUa1uQSYGFzR1VkJJNRRr CUpzU661t0QTZQcWGhFgS1EDYc3NGRltBeHXAS4XSl15RUdMHRwRFGHKwWFhYWHXrqmg2CoZUTkI d2gQZ2cZECRtV0ZuemoCf3M5UFBTUAev51TPVA9QRVBNUHVRVxAqekNqQ1JGUndbBkP+WudX61tW y1v6W+1aUytb0VDcW1NXUlhdR1JIXSxULFvIX1d3Unhdd19TEFQWQxZwUxxfHEUZR1MbVBtYDUVT U05PW1xcUlBGTV5dXVFacFlxRUdERk5NT1RxSE1OT0ZUS3VVdFZfTEFLXcZcY3HoUiTmWVtSxlFj SOhSJBBBRFdREFlbZFHGUmN0cVZKd1zor5AQX1lbZFzGXWNLcUFJdggRSHseQKQdvUmkSL17HkCm Hb1JpEi9e1BvvUmkSLxvvUmkSLxRQUJpaUFCaWlBR2lQQUJHaUJpaUFCaWlXXkBsbGxsV15AbGxs bGFgUQ0NDQ0NUA0NDVEhUWdHV0ZGRURQc3J3V3dndnZlZFBjYlN2c3JWRURHUVFGY2JmZWRT4jgg PGwVrpa9/NcjPiRsFVFjoOJIEwUhzUxRsK4oEgUjzFO3KAwsF5M7vq6UBNUP1hmaOqBRZa6jZv7N Mx9RHa5rYP3MDlBSUDWuDFTSVHZQU1ByUMMQdlZZRllSZU5lT2VwH1kKcTZLOXFXFkdRWll4WVJd TElTUFRAVFJU6K+QEFpJT2RUClFoU1ZE6FLD4kPKQOhSJBB0SV9TVlBVU1RVdlRUTENxUERARFJE SnRdcVBMQExSTElzs+hIex5ApA0dvR5Apg0dvUJpf71AbEBsUG9vraS0b622ew1BQmlpYWBQIQ0N UQ1RQXFBQ2NGRURWVldWRURGY2JmZ1VWV1ZWc3J0ZWRmZmdmZlKrrrdLrlIHrUlJ1D873k1RUkFm Gr3foa6xYz0nB3tUdq63UUmu1hJaIvWeeXlkHSUn0HEtAyE8rfYQKSoyFg1QUlCTrjlRo1R2UFNQ WVA85VBUQFRSVOivkBBySU9kVApRaFNWV15QU1bfW1FbSUdKUFZ2V1V2WFF2UlB2V+pSxFBYUsQQ QVJwU2BT31NTU0laW+JxnftIe3sepA1sHbS0vUC9QL1AvR5AFTUUtg1Qb2xvbB1ArbZ7DWFgUUFx QUNDQXFBQ1G4rraMGa6AGVR2rrdRSa7QrUuu+FEIUrVQUFFQBVEoVAZUYlBVUGgQQ1XTUW9SH1JS UmdUU1ZTUklWUVDoUvLnVVVUSlcdE0h7HkCmbB1ArWweQKRsUG9sHa0NbLRhYFFBcUFxQVMFrVBU UVEoUelRUa0WUFGvvK4BVCZVg1B0UWgQN1lVWVdJVUlXVEhFSHR0SGdICVY4VjRFN0g0dCdU11T6 V+lXXUZdUUVQREZBQlFDQUZSU3NRQ3RQRHNTQUZGdnNTRHNzU3NTc3NlU2VzBXNVc0ZTQVRbTFNz WU9BRl5KXBBCRmRc9lvoUssQeF4QSkxkXhBCRmRe9llRRFAQSkxkUBBCRmRQ9lFDQkJSUmBRIFFS UU3or5DlQkZkTfZM6lLLUE+vkONKTGRP6K+QEHxCRmRP9kpfRGNDQ0xbUWNQIFBRcFBRUExcY2Bb EFtSW0p2TXhgTBBMUkxJdepSwlFKUEh7HkCkDR20HkCmDR28QmkNIX+0QUJpf7RQb717e6W9e38h bEBsQGxArXt7bG+9e3ulvXtBQmlpQUJpaVFBQkdpDddefnteLUCUX19fX2FgUCFRDSFRZ2NnZmdm Z2ZjYkdXdnNyVldXY1dzU15Sc3J3Z0ZjYmdmZ0NRRHSaQExEcGga19fUZg4QZmRBW4B1nf1EEdIi zCxpPWpuSURBxlMDgwnJexJyfHmyTGAGaIOsfickFXiNR3ZNOFM5UFBSUDBQFlRRU4dQVVBbUOEQ f4ZauFG4V1OGUYZUhldTllSWV5ZaUwhRCFeWUVNpVxhRGFdTeVF5V2lRU1VQUFZb6FHQEG1YWVlS UlNXaA9aj1pSWqRYW7tWWbtWf1hRQFhwWFJYSl1Vu1BQU7sAUoBSUlKkUWhAVHBUwFRTQFSAVFJU 6K+Q51tlVElc9RNIex5ApHshDR29rQ29bEC9HkCmDSFsHb1AvUCtDb1Qf2xAbEBsrWxsQGxhYFEN DQ0NDQ1ZUnNRUXFRUXNRUVIprqxRVI2ulFFsUjWurVFTja6UUWxTh65trmJRnlGTrm2uYlGeUZNQ UlA6UBZUW1OHUFVQW1DzEHyJWrdRt1dTiVGJVIlXU5lUmVeZWlMHUQdXmVFTZVcXURdXU3VRdVdl UVNZU+hR0BAVW1VTu1JSVbsPUI9QUlCkUWhPVH9Uj1RTX1TPVFJUEF1fZFRKXVdoAFqAWlJapFZZ u1hYW7tfVnBWUlYQXV9kVklc9RNIex5ApHsNHb1sQL1ArQ29HkCmew0hHb2tDb1sQL1Qf2ytbGFg UQ0NDQ0NDXVRUWNRUXFRUWNRUVGiUVSurI1RbK6UrctRVK6sjVFsrpQWUZRRna5jrmxRlFGdrmOu bFBTUJlQUFdoUUlQU1BXUFtQbhB0VlVSUVRaaFtbV1dUVFBaUnZRold2VaJbdnBYEFhSWElcnftI ex5ApA0draatpr1Qb2xAbEBsQL1HYmFgcUFxQXFBcUFxQXFBVk5RSqxsUUmsbFFJUUmut1FJrrdR Sa63r69QUFBQVe9XaVJ2UHRQUFFXUBNR3FE2UE0QQFLwW+Bbr1tTW1dQGHtSUVzpUmRQeVB7UXsN ZVCvr1BQUFBV71daUnZQdFBQUVdQllErUQZQfBBDUlsQRklkWxBbXWTgW1E/W1FbWeivaOQYe1JR TOlSZFB5UHtReyENe3tlr69QCa+3VbdXWlJ2UGJQUFFXUJZR61EGUHQQXVJfTFF/TC9Mj0xTTFfo rxLkGHtSUX3pUmRQeVB7UXsNIWVQUlAYr7dXkVWDUElQdlCtEAVpVGdfHFMJU+lT5U7lc5lTWM9Y wFrpWOVaVCxO21PQWN9aVHpXelt5cnl2f3dgdxB3D3g/eOtb61xb/1b/XO9W61dUeVZ5XC1WK1xU 0HffeFJFSElT6K9WEBFZZVNTVEBBVHFVVE1SRkV1R39IH0jASFNISERQSXVRUlhDRHVCQVJxfVVZ Sn1dU0dGG0NCGFBRSnhESXBSUkEGdOhSZxBCTXdfWU9Zf1lTWUlwd1F3gulIex5ADaQNHa2mpGxA rWweQKZsHaRspGxQb71vvW9srWxvbK1sQWl/DWytbFFBQmlQQUJpU15AbFhse1VAbGxhYFEhDQ0N UA0NDXVFcWVWcXB3dkFAZ2ZjYkZHZXFFcUFxRXFBUXJWQUBHRmNiQmVAdleRrAEjrqOuq8Lj/8an LYEQU8OtPlIKrfat+sTgMxvG5d//qan9lvqAUS5RKpv/NgXyqK7qqK4lU42Krqmuh9AxUUOhUV2K UFBTUAivuFdqVG5Qc1B7UGdRMhB1p0umY1LHX8lLx3lTB343fsdcUxhSFVsWXwhSVFlzUVdIXUFv ROivuBBZXUFvV0hcQG9E6K+4EGBcQG97TnZEZkQWRFNEd0d5V2lXGVdTV39aRFdOYnt0EEtNZF90 73SfdFN0EF9BZHToUt3kTjBNUU3or5DiS2lN6K+Q5kxpTU13cVHor5AQXUlLZFFjUFBAUDBQU1Do r5DjTXBkUOivkONyeWRQ6K+Q43t9ZFDor5DjRUxkUOivkOJCaVDor5DkXmlQD3HoUiTiVFR/6FIk 4lpbd+hSJOJHR2XoUiQQckFXUHFRf3RxTUrQaVFpTnFfYlEQYjBir2JTcGJgYsBiU2LoUj7nfHFd SWgIEUh7HkCkHa2mDQ0hvR5ADaYdvaS9UG+9bEC9b71sQK2ke3t7e3t7DbR7QUJpf3t7DWyteyJ7 bFFBQmlpUEFCaQ1BQmkNUUFjUHt7e3thYFEhDQ0NDVFVVlZzcnZ3VlZzclBlZEJmY2JGR2ZmY2JO U1dxRkZjYmZDdnZzcldWV1VERmNiZmVkdnNyVlZKUUJhof01lhsf6jy5rp/Trs4/6RsV4Tw1+z8d clGtFVoqDBINflgoCjNqeVqsqC8sON3dOD7dUQV8x/oYHBoaUWeixVFe2hoaGhoUN8mRKdHRFlE8 0i0AaCc9O5f19sfy9lBQUa+sUfpUP1IsUFNQceVgURBRUlHoUi0QWVBSSlVQScM8SHsetEC2UH8d vQ1hYFNlcUVUVCNR+oKCUFFQUFH6WFBSLFBTUE7lYFEQUVJR6FIt51BSVVBUwzxIe0BsQGxQf70N YWBBZXFFWFBR+oKCUFJQ1FM4U9lVmFBbUEdQIRBeVlpXQkZDX1xRXGhHukPoUU4QWUJfUFFQaFu6 V+hRThBzVkJQVlBXdFBaIlJRW1BRdlD+XUN0XEYiXl1HXXZcMEk3gUh7QKa9bEBsvUC0QKatQGxA bB29QLRQb29Araa9DUCtpr0NUUFCaUFCaWFgUXFlZGZmZ0dWVldjUXFlZGZmZ0dWVldjUc2ut3sk CmcEGVLYUYWut3slCWcEGVLYUziZKt0gcCRMNAOut5kr3CBwJEw0A1BQUlA5UwlTIVXqUFtQR1Au EFpWWldCRkNfVlFW6FFOEFlXultoUF9CUULoUU4Qe0O6R2hcUFBcUFd0UFoiUlFbUFFoUP5dQ3Rc RiJeXUddaHBcYFy/XK9cVFzoUmvjSPUmSHtApg29bEBsvUC0QKatQGxAbB29QLRQb29Araa9DUCt pr0NUUFCaUFCaWFgUXFFRFZWV3dmZmdzUXFFRFZWV3dmZmdzUghRSXslCWcEGVHXrnhRSXolCmcF GFLYVeqaKtwhcCVMNANRSZoq3CFwJUw0A1BRUMhTOFGYVZhQW1BvEFtWUVdQaF9bUVu6V+hRThBE VlBaIlJRV3RbUXb/UFFQSl03gUh7HkCmDR29bLRAbL1Qbx2tpg29UUFCaWFgUXFlZGZmZ0dWVldj UeGut3skCmcEGVLYUziZKt0gcCRMNAOvr1AlUwZR9VXmU1dQX1BQVM1QWeRQUVBQeVB7UVBQU1Bh UOlUYlS+UFNQV1BbUA3iUWdQ6FLP52BVEFVSVWdU6FLP41lnWFroUvIQQFlZAFhRWDJUAFZRVjJS UFLoUvIQXQBRUVEyVVVUSVzzO0h7HkCkbB1ApCG9bEC0IUCkIWxAvVB/raatDaa9YWBRQXFBUUFx QVFBcUFR9VFJrSNUUa0jUUlThVFJrreuK1FXrqmuOVFJrrdQr69QXq4BVAJVg1J2UAxQUFFXUN5Q sVBQUHEQWVJRf0vfS1JLUuhRM+UYe1FSUkvpUmVQeVB7UXsNZWVQr6+vrVBQVQhWr1J2UGxQUFFX UN5RCVF8UHAQQVJRL0BRr0BRQFeCGHtRUlJA6VJkUHlQe1F7DSFlZVBSUH1QnlRvVLJQc1B/UIQQ FMtdxUHFT8tz+V32QfZP+XNYxlTJWMlGxkr1VPtY+0b1SlhM6ku0TkW0ROpCWupZtFxTtFLqUENl W2WwelF6F0JuXG5f6FGxEGK/dFF0F01lUG5RZU5ucUlgRGVMZUhOtE3qS1HqULRTXLRb6llD6kK0 RW5Lbr93UXcXSOhRLxBCWmVSZVluU26wfVF9F1ZW9YFIe1BvvQ20tLS0rb0NtKS9vUC9vUC9vUC9 vUC0tFEeQKQdtLS0tL0NrbS0vQ20tEC9vUC9vUC9vUC9vWFgUQ1QDUN3Z0dmZmNiRkdnR1dGRkVE VldHV3dWVnNydndXd2d2dmVkZkdERmNiZmVkdnNyVuHU9thlPWhpPmTW99RMTExM1vfYYj1raDxk 0vrSTE1LhicDBCYmBAQmU/3T4thNTExN1vnVYz1qaT1k1fvYTE1MTNP41GQ9aWk79AQmJgQEJiZQ UVAbUBZSNFOHUFVQJRBwGFVRuFFRhFGHVFKTUZdUUhhRCVFSeVFpUVJRVFBVUlXoUdDnU1W7UFBT u1Lor5AQQlxAZFJKV1FoYFQQVN9U71RUVOivkBBZX0BkVElWHTtIex5ApHsNHb0eQKZ7Hb1sQL1Q f71sQGxpaWFgUQ0NDQ0NIVlSc1FRUjSurFFUja6UUWxTh65trmJRnlGTUFBRUBtQFlI0U4dQVVA6 EEt1UWZRF1EGUbdRVYlRiFRSmVGZVFJUUVNQU1LoUdAQeFBVUWhfVGBUAFTPVP9UVVRKV1O7UlJV u19QYFBSUBBBRGRQSVYdO0h7HkCkew0dvWxAvR5Apg0dvVB/bKRsQUJpaWFgUQ0NDWdRUWNRURtR VK6sjVFsrpQWUZRRna5jrmxQUFFQFK7yVHNV+FBDUPIQD0BfX1RUcFNgUxBTU1NoUkFCQlJRzENQ XV5eVVV/Vm9WH1ZTVmhXXFtbV1jMWllQQjJBQUAyX19eMl1dXDJbW1poWVlYMldXVjJVVVQyU1NS MlFRQFBRYFBRUO5EOhNIe0CmDSFsQKRsQKRsQKRsQKRsQK1sQKRsQKRsQKRsQLRQb2ykbGxAbECt DWxAbEBsf2ykbGxAbECtDWxAbEBsYWBRQXFlcUFxZXFBcUFxRXFBcUVxQVHkrsBRIK7AUSBRVlE5 rsdROa7HrvJRHblSwLlRB675ua0gua7jUFFQw1JtUfxTBlBTUHIQRFJoUFJ2X1BPUHBQYFBUUElU NyZIex5ApA0dvVB/vWFgQ0FxQcNRSVJtUUmut1Cvr1AlrulR9VFJUlZQX1BQr69QOa7oUyFRSVNX UPdQUKsPUFrlUFFSR1h5UHtRUFdQUa+VV69Vg1BbUE9Qc1B/UBNQH1AzULUQFjBwMHFScXBwhXNy RHNzcnBcc1ZGcXRyamBwBXMXtOAPUQ+lBbQdHX13tOBvUW+lZbR9c3B7fVm070BRQKVLtFNycXFT UTXoUsQQYD8aURqF0ArAClIK/j8AUQCFXxRRrxRRFLE/elF6hdBqwGpSav4/YFFghR90v3RSdOhS 1BBHP1ZRVoXQRsBGUkb+P1xRXIVQNDTDPEh7QKatDaYNrQ2mDa0Npg2tDaYNIa0Npg2tDbRQb2xA bEC9pCG9f6RsQL2kIb1AbEC9pCG9QUJpUUFCaUJpQUJpQmnXfnstQJRhYFENQ2RmY2JGRURWc3J2 Z0RHRkZjYmZnZmVkd3Z2c3JWV1ZDUWNRUWRmY2JGRURWc3J2Z0RHRkZjYmZnZmVkd3Z2c3JWV1ZV ZGZjYkZFRFZzcnZnVkdGRmNiZmdmZWR3dnZzclZXVlHy0C/x8NLTzZNfW3lJSnhcX19ceEpJeFxf BFI1lK3MURLy0C/wz9LUzJJAW3lJSXlbQEBbeUlJeVtAUYzy0C/x8NLTzZNRVFlgT0l6XF9fXHhJ SnhcX1QP6uro7p/r5po5ZXZwcHZlOTlldnBwdmWrQFZXqalR1urq6O2A7OeaOWV2cE93ZTk4ZnZw cHdkDerq6O2A7OeaNUZnY3F1Zjk4ZnZwcHdkr69QUFBQVe9XZVJ2UHRQUFFXUJVRL1EyUEUQWlJR QFlcOHdSUV/pUmRQeVB7UXtQr69QxVBQVKBXZVJ2UHhQUFFXUJVRHlEyUGQQSlFQQWBBUpBBgEFS b0EfQVJfQVFwQc9BUkFR6FJg5Dh7UVFA6VJkUHlQe1F7DSEhISJlr69QUFBQVe9XaVJ2UHRQUFFX UN1RP1E2UHEQQ1I/W1FvWx9bP1tTW1ZiGHtSUV7pUmRQeVB7UXsNIWVQr69QxVBQVKBWr1J2UHhQ UFFXUN5RDVF8UHUQXFJRb0NREEP/Q1JDUehT3uUYe1FSUkPpUmRQeVB7UXsNIWVlUK+vUMVQUFSg V2lSdlB4UFBRV1ATUT9RNlBkEEtRMF3vXVJfXU9db11T313wXeBdU39dD11SXVLorYrkGHtRUV3p UmRQeVB7UXsNDSEhZa+vUDpQUFJ/V2lSdlB8UFBRV1Ddr/9RNlB05lFXEEJFZFfor5AQW0hMZFdR 0hh7UVFX6VJkUHlQe1F7e3tlr6+vhlBQUitXZVJ2UHxQUFFXUJWvg1EyUHQQXVE/WS9ZUi9Z31lS WVLoryzkOHtRUVfpUmRQeVB7UXsNIWWvr6+DUFBSI1avUnZQfFBQUVdQ3q+eUXxQcBBBUlEvW1Gv W1FbUoIYe1FSUlvpUmRQeVB7UXsNIWVlr6+vplBQUetXaVJ2UHxQUFFXUBOvnFE2UHfhUVXor5AQ WkJFZFUQSkxkVVLor9jkGHtRUVXpUmRQeVB7UXt7e2VQr69QCa+3VbdXaVJ2UGJQUFFXUN1R/1E2 UE0QX1JAT1H/T1FPV1AYe1JRT+lSZFB5UHtRew0hZVCvr1AJr7dVt1dlUnZQYlBQUVdQlVHvUTJQ RRBaUlFxV1I4d1JRcOlSZFB5UHtRe1Cvr1AJr7dVt1dpUnZQYlBQUVdQE1GcUTZQTxBBUk9Nj01S r01RTVdaGHtSUU3pUmRQeVB7UXsNIWVQr69Qw6+3VXRXaVJ2UGhQUFFXUN1RO1E2UHkQSlFATaBN UrBNoE1SYE0QTTBNU01XUBh7UVFN6VJkUHlQe1F7DQ0hZVCvr1DDr7dVdFdlUnZQaFBQUVdQlVHf UTJQRRBaUVFPV1A4d1FRTulSZFB5UHtRe1Cvr1DDr7dVdFdpUnZQaFBQUVdQE1HYUTZQfhBGUZ9L j0uvS1NvSx9LP0tTSxBHTGRLV+ivpuQYe1FRS+lSZFB5UHtRe3sNIWVQUVDDUFBR/FR2UFNQGBBz gFW/VVLQVeBVkFVTMFXgVVJPVS9V8FVTUlFWU1BaUlN2UVDor5AQWXF0ZFBJVG9sSHseQKR7bB2t bFBvbG9sYWBRISENDWNBcUHDUUlUdquKUFBRUFNU/FL4VYNQVlAX6VBSr6QQd1Fcx1H3UVJUVthV IlFQU7tU1lXWVrsvUFHfUI9QUg9QUVBJV8M8SHseQKQNISEdrUmkpEi9UG+tpGxhYFEhaGhDQ3FD c3dXU4JRVJ+yJDxU/FF3ronFxVBRr6NU5VL3VeRQSFAPEEI/WDVEKlgmRFQJWAVEUlFQe0HoUVEQ XlBaQFpwWlNaZVZeXXtG6FFREEdWUF0VX15PXlJeSkpQFVFJSUr5cW08SHt7HqQdvR5Apg0dvVBv vaRsQKQNraRsYWBRDQ1Dc3ZlZGZjYkZGY2JmZ2NWVnNyd3Z2c3JWJNBRNgBzbM99cHtW0lEzHnJx R+h6cHRU5UddOSFfF3h/1yRXVhZ3UFBSUMFUKlJJVlJQW1BHUAUQWldVR1V3VVNTskXoUsXnUEJA QnBCU0LoUsUQRF+yWVFQslxlX1NPU39TU1NlQrJW6K+QEFlbXWRWSUg3Jkh7HkCkex2tpA2kvVBv raYNpr1hYFANUURWc3J2ZWRmY2JGV2R2c3JWRURGY2JmUkkjAQEjIwEBIztkdXVkZHV1ZFVuASMj AQEjIgJ1ZGR1dWRkUFBRUHauDVIXr6RQR1AAEF13RGdEF0RTdkNkQ1JQ6FLDEHNGsnBTUVPfWrJf WlcxQkpJX1xPXFJcZU9QUVBJSEmLcfMTSHt7HqQNHbQNHkCmHb1Qb72kDa20YWBRIQ1DZUZjYmdm ZWR2c3JXZ2ZjYkZFRFdWc3J2NwYJe3FuERATSh4KLdIYMeXRrj0mW3BIdnJiRDNLPh8IZxtQUVBT VPxS+FWDUFZQaBBwViJS2FRUUVBUu1PWUtZRuy9Q31CPUFMPUFFQSVfDPEh7HkCkDSEdrUmkpEit UG9sHUCkvWFgQ2NHZ2NTcVOzPCSyn66sVYPFxa6JUK+vUBqvtlSiV2tSdlBmUFBRV1CZURtROFBF EFpRUX9ERDh3UVFj6VJkUHlQe1F7UK+vUGCvuFRAVYNSdlAGUFBRV1CZUJpQUFBFEFpRUX1DXzh3 UVFh6VJlUHlQe1F7UK+vUEZQUFTtV2tSdlBtUFBRV1CZUVxROFBoEE1RXBBwcmRAXFFPXIBcUh9c D1xSD1w/XFJ/XFFcVOhSTOQ4e1FRX+lSZFB5UHtRew0NISEie2Wvr1ByUFBThlWDUnZQDVBQUVdQ mVD3UFBQehBCUX9DwENSEEMAQ1L/Q79DUkNY6FH+5Dh7UVFG6VJlUHlQe1F7DSEhZVBSUOCuAVHf VYNQU1BXUDAQWQBZURBZAFlSWeivkONLTWRZ6K+Q40FDZFPsUVlQVlGJUFdRyBBGUVBRUFJTV1YZ VVRVP1BR71BRUElYtulRSVBIex5ApA0hbGwdQK1sbGxAbFBvHa2ttmFgUXt7DSFDQWNBU0FjQeCP j49S7VNGrLqrxFNHrLlQUq+tUFBVMlXqUENQdlD9EHHJVcZaUnVNUUhBR0RJRUJGRElDQkZQX0BB R1BfRtBCUULoUawQe0dPQVEfQQ9BL0HfQb9Br0FWQUFQX3ZEdVFQUkpJdV5fWEZHR0lwd/9XUVfo r5DjWVtkV+hS3BBA0HhReERJcFBfQkF+cF9RX+hS2+N3YQNIex5ApA0drGxAbK1sHUAhpnshHb1B aX9sUG9srWxvbK1sQUJpfw0hbKUNbF9fX19hYFENUA1DcWJHRkZCRURSV1ZXVnNxQXNlY1FBcUVx QWNiZ2ZnZmVkdnZ3dnPFUkzqMNLoDTc0HdIy9a2EyMhRd1FqrpaOwxEGfW9lNwMQ71XqTXeVrrie 5a6NMRl6T1LQ6lHYrijqridITgAhuPXjPkZAUFJQA6+3VMdV6lBOUHpQiBBqVVZHV8xWzFf5V1UZ V9hX2ktTOVNRR0pRVlNXS0ZTRksXWhlBB1PHVlhnSmdNF0tTd1N3SndNU1VLS+hRHhBMTFRETExU X0tPS1JMS1RVVENQVVRZUUtPTF9QcuhSJOJcW3joUiTjAENRQ+ivkBBeWVxkQ1ZRUFB1cVlKfFHo r4gQW1tdZFFpU1BCUFJQ6FF3509xX0l7CBFIex5ApB29SaQNSL17HkCmHb1Qb2xvew29b71RQUJp QmlBQmlpUEFCR2kN115+e14tQJRhYFANDQ0hUQ0NDVFxRkdnR1dGQkVAUHNyUGVkZ2ZjYkdGR3Z2 d1d3Z3ZTREZjYmZlZHZzclZRHFF1aWTlfcCQ966cpLuun/LX+WZneBl3ZGeqe4o0GsE5O8bKOTfB Vep8fQkyE5GuK/2urq6XUWeno8zSQFx5Fh4VJzA3DKz8z/f4xMX881Cvr6+tUFBVCFdpUnZQbFBQ UVdQ3VFkUTZQSxBeUVwQTXBkXFRAGHtRUVzpUmRQeVB7UXt7ZVCvr1BergFUAlWDUnZQDFBQUVdQ 3VC3UFBQRRBaUVFHUnMYd1FRR+lSZVB5UHtRe1BQUlDFUFBUqFXqUEFQTVD6ECL2S1H0V/ZYUsdL 9VZSxlfHWFLUS8ZWUiZL1VdSFVYkV1JHV2RWUlZWVldShVenV1I2V5lHUkBDQlNSREN1X39AUUC+ QUFQWE1CdVRPU1FvU/9TUlO+UlJRUkl3UFlRWUpPUkFwUV9QcFBgUFNQSU5hA0h7HkCkDWwdrWwe QKYNHb1Qb2xApA0hbK1sb2xApA1srWxTVUBsbGxsYWBRDQ0hISEhISEhISFjQXFBY3BHRkZFRFZW V1Zzc0lSY2JnZmZlZHZ2c8VReONRXgMu+TLHHjqZkfL2fW4HFTODVequvEZyjf/W6DpARq68U/6u D1tfNgQUNXRQUlDbrjxUx1XqUEBQTVA+EE82SjZMUglGBko5RlM2VjZaUgZWBloJTVNSXl9RUFBL 6FIk4lVXRehSJBBKW1tAX15IcVhKT0F5Xl5fdkBAUXZQSU5vEUh7HkCkHb1sQK1sQLQeQKYdvVBv bG+9b71vbFNeQGxsYWBRDQ1QDQ1DcUFmZmNiUEFAUHNydndBcVFER0ZjYmZlZHZzclbbUUkD2wrp UVKurOkI3x+ut1FHZBkpDdPUNzXWVeqtoAMRro6ura6mrokWBa25U+71HyDP++bxzVBRUD1Qu1Rt VOtQW1EWEEVRUllQVVdTWFtWVFNYUFVaUllbVlDor5DjXERvWOivkONcRG9V6K+Q41xEb1Por5Dj XERvUOivkONdRm9Y6K+Q411Gb1Xor5DjXUZvU+ivkONdRm9Q6K/q40JIb1Xor+rjQkhvU+iv6uNC SG9Y6K/q5kJIb1U0WVboUsTmWFtWUzRbUuhSxBBZUFlSVVBQRxhQ6FLyEFxbVkRbW1ZTWFhHGFjo UvLmWVJEWVlSUOpSx1BYUtrjWVV7U+xS2lBWUsdQUlGJ41t7WVDqUsRQUlGJ4lU0WexS2lBYUsRQ VlGJEF1wUzRQW3BbIFtTW4dcSUCmDUi2SkmtSKRJpEi2Sa1IpFB/tEmtSLZJrUi0SUCtSKbXXn57 XielLUCU115+SHteJ6UtQJRIUVhAsECwWECwQLBQe3t7e3t7e3t7e3t7UV9fX19DUVFnUVFHUVFX UVE/UX6ugOpRYFF+5a6CUWHqrp+uglH0UX5Rf+qugVF+5q6Crp/qUWGuglBQUVALUodRv1WcUFpQ AOdZUFFSVFVQUehRKxBzWVS0VbVaWVFSMFFRUYVaAFAvUFJQSlxVMFTwVFJUSVsd+0h7HkCkDWxA pg1sHa0NbFBvbKS9QK1sQUJpUUFCaWFgUXNBVldlZmdmZ2NRv+4OKA8dZkjKUodSURFxy0tsempQ UVBJUodSKFWcUE5Q3RBAVEhESWRUV5lMiExT3E1RTuivkBBGSnBkE04DTjNOU05HUkBcX05QtFFR UuhRKxBgRF8QWlxkX9ZctERRMFlRWYVHR1BfhUB0UlEAUFFwUGBQUlA4cC9S/1JSUhRP8ztIe0C2 IUCmDQ1sQKS9QGxAvQ1Qb620e0CtbECtbEFCaVFBQmkNe2FgUSENe1FFcWZmZ2ZnZmVkdnNyVld3 ZmdmY2JGRURWV1ZXVldSKK3xWwfHIkdPYmNjYlbtX2wAwtvDfmJKPWpJUyXOBdYnCU12d3V8YRJA JWYX0AdmMWRKBn1IUFBRUHhSm1LRVZxQe1DiEHhXc1EXTgdONk5Tc09Xc15bUFFUSERHUVFEP0dR R0dEVLR5RLRMXptb6K+Q5GplW1t56FErEH1MUVx0XV1IP09RT4VBdDBXUVeFP3afdlLQdsB2UgB2 4HZScHZgdlJ21X1HhUjoUsQQXVGFUBBFTmRQ1Xw6LEh7QKZ7vaS9QKYNDQ0hrQ2kvQ1CaX+0UG+9 aX97vUC9QL1BaX8iQWl/QUJpQUJpQUJpUUFCaWFgUA1RDUNnRkZjYmZlZHZzcldnRmZmZWR2c3JW V3dmZ2ZjYkZFRFdWV0ZGRURWc3J2eOhYan9hbGl+Tm1HZGtJenl5YljiSWEc1CzBRUxgExX42dDK U+JEZ2VsYHtoX8JRR3NGTXV9ZUo3fBQsAHZwfU1IDW4Pwy5QUFNQDK+aVihVnFBaUF5QfVCqEEpD SEVJZFNGMFwwXVNZUFFdXFyFW15EW1tefeivkBB6SnBkfUhFSWQQfQB9Un1BXl12T1tcUFFPTktS VLRVtVlOEFpcZE7WS7Rz6FErEFlBfV+0QEFcUFHoUSsQRFpZUV5dUVxbWU6FT3QwQVEQQVFB6FE9 EFtAMEhRSIV2dl9fQOivkBBeWUBkQDh/Wj9QUVCFUlHrUs5QVVBUr5AQWVxAZFRJfh07SHseQKR7 bB2mbK0NbECme2xAbEC9DUCtIQ2kvVBvbG9sb2ytbG9srWxAra20e0CkrWlBQmlRQUJpaUFCaWlB aQ17e9d+ey1AlFFBQmlhYFENe1FzQVZXZWZnZmdjQ3NRY1FFcWZmZ2ZnZmVkdnNyVld3ZmdmY2JG RURWV1ZXVldRoO4OKA8dZkjKU89TNc9RcK3xWwjGIkdPYmNiY1XuX20fwtvDfWNKPWlJUodSURFx y0tsemqprlZSqvfNBdYnCU12d3V8YRJAJGcX0AdmMWRKBn1JUFBUUAyvmlbIVZxQWlBeUElQTFF2 6VBMr7gQEUdMZFheB10wXDBdKF1VS0xMKUJDREJCQ11cXIVbXkRbW15eXV9CW0FcUFlaUUNES0xK QlJUVUtKQ0JBTFJVVERD6FErEHJfQUBASExKSkVFRrRHR0gPSUlfXFxbXl1SW1lUtFW1WVBR6FEr EHxaWVBCQaFfS0pKQEAwX1FfhUlERUVISEnWRlBHEEcAR1NHFE5aP1BRUIVSUetSzlBVUFSvkBBZ XEFkVElNHSxIex5ApHtsHaZsrQ1sQKYNbKRsQGxAbECtDWxAbEBsQKRsUG9srWxApL1vb2xAbG9s QKRsQK1sQGxAbEBsQGxArWxBQmlBQmlBQmlBQmlRQUJpQUJpQUJpQmlBaUFCaWnXfnstQJTXfkh7 VC1AlGFgUQ17UXNBVldlZmdmZ2NDc1FjQ2VxZVFjQWNFc0VTZVdRoO4OKA8dZkjKU89TNc9zrshR Lsw7O+LnUodSURFxy0tsemqprlZSqlrC3VGGrn7BwlFzsbFQUFRQeK+aVshVnFB7UH9QalBtUdzp UG2vuBAXR0xkV3MwfTB+UxZOBk43TlNzT1dsbW3IY2REY2Nkfn19hXx/RHx8f2RlbG1rY39+aGJ8 fU9Qc15bY2JtbGtkUFFUSERHZWToUSsQRWBta2dmZmu0YmFoaWlhD2pgXF6bW+ivkBBcamVbW0x5 UVFEVLR56FErEB9MRxBqZT9HUc9H70dSb0dRR0dURLRMUXx9WX9+UFx/XV1BSGNioWBsa2thYTBg UWCFamVmZmpqadZnUGgAaFJoNW8/T1FPhUF0MFdRV4V26K+QEEdwcmRwdlHgdlGwdqB2UmB2gHZS P3ZRduhRnBBdUEeFSHlRhVBJbijwSHseQKQdvaS9QK0NDSEhInutDaS9DUCmDWykbEBsQGxArQ1s QGxAbECkbEFCaX+0UG9sb2xvrUFpfw0hIntAra1BaX9BQml/e71vbKRsQGxAbK1sQGxAbECtbEFC aUFCaUFCaUFCaUFCaVFBQmlpQUJpaUFCaUFCadd+ey1AlNd+SHtULUCUUUFCaWFgUA1RDXtDZ0ZG Y2JmZWR2c3JXZ0ZmZmVkdnNyVld3ZmdmY2JGRURXVldGRkVEVnNydlFzUWNDZXFlUWNBY0VzRVNl V3joWGp/YWxpfk5tR2RrSXp5eWJY4klhHNQswUVMYBMV+NnQylGFz1M1zluuyFEuzDw84uZT4kRn ZWxge2hfwlFHc0ZNdX1lSjd8FCwAdnB9TUgNbg/DLqzRVlKqWsLdUYaufsHCUXOxsVBQUa+9VkBU LVaXUFNQTRBaUetQUkpVUElUDulRGlBIex5AtEC2UH8dvWFgU2VxRUNUwFZA5+dQUa+wr7dUY1WD UH1RWhA+V3tRUgVMUYVMUVNYS1FCUkVDJUPVQ1PKVepVmlVTWFUYVVJOU3pYT3Fk90NRgUNRU05B cUheUaheUV5aeFd1eFoIWlJaWlNFSEpXR0dHUllHRX1KXVB8WFFRXlBRU318U0BfWRBYWFxHUXBQ R0for5AQY1leZEd/QVdcd3MQJU7VToVOUwdO905SU054d3g3eFJSeFhzSHNSWVBzT3Z2EFlDZHZw d39snXtRQGxIfw8ODWMPDUCVDw0NSkAdrZRiQJZ7UUhAhkpJnUFCaUh/Sp2EnVBvHa2WDw4NQWlv rZYODUFpQUJpfw1sjWxAhg0hbI1sUQ8NYWANe1APDg0NDQ8ODQ8NIQ8NUVN2c3JXVldxV3FWRURH cVdxRkdGY2JnQVZzcHd2d3NnY3ZlZGdzZ2NmZ2ZxYlRjawXz8zVpSFJ2cK22UVJRrXCuaElkNPCQ ItL9rozs0HnEcDJRUtNwJ3ot7VFk+FXGrrsFJRIzy0d0c3bLO20mJq6eEZjYm8tIS35zy5fWmlBQ UlBQUFBQUK93UIdQUFBQUFBQUFBQUFBQUFBQUFBQUFCOUFBRUlFTUFNQVFBVUFZQV1BYUFlQWlBb UFxQXVBeUF9QQFBBUEJQQ1BEUEVQRlBHUEhQSVBKUEtQTFBNUE5QT1BwUHFQclBzUHRQdVB2UHdQ eFB5UHpQe1B8UH1QflB/UGBQYVBiUGNQZFBlUGZQZ1BoUGlQalBrUGxQbVBuUG9QEFARUBJQE1AU UBVQFlAXUBhQGVAaUBtQHFAdUB5QH1AAUAFQAlADUARQBVAGUAdQCFAJUApQC1AMUA1QDlAPUDBQ MVAyUDNQNFA1UDZQN1A4UDlQOlA7UDxQPVA+UD9QIFAhUCJQI1AkUCVQJlAnUChQKVAqUCtQLFAt UC5QL1DQUNFQ0lDTUNRQ1VDWUNdQ2FDZUNpQ21DcUN1Q3lDAUMFQw1DGUVRQzVDOUPBQ8VDyUPNQ 9FD2UPlQ+lD7UP1Q/lD/UOBQ4VDiUONQ5FDlUOZQ51DoUOpQ61DtUO5Q71CSUJNQlFCVUJZQl1CY UJlQmlCbUJxQnVCeUJ9QgFCBUINQhFCFUIZQh1CIUIlQjVCOULFQtFC1ULZQt1C4ULlQulC7ULxQ vVC+UKBQoVCiUKNQpFClUKZQilFVVX4+JTw8QD4/Pj0xIjs5PjciNSQlIj5TPSVhVyU+OWJgERNQ UFBQUFBRUFBSPFBRUDVR0FBWUI5QU1B0r+RQU1Bsr4tQRFBEr99QdFBTr+RQdFBnrzhQdFBprzhQ dFBqr99QdFBsrxRQdFAJr+RQdFAKr4tQdFAMr+RQdFD5r99QeVBfr01QeVBBr01QeVB0r99Qf1BT r4tQf1BnrzhQf1BprzhQf1Bqr99Qf1BsrxRQf1AMr+RQf1D5r99QY1BTr4tQY1BfrqhQY1BBrqhQ Y1B0rzhQZVBpr4tQZVBqr4tQZVBsr+RQZ1Bfr01QZ1BAr99QZ1BBr01QZ1BNr01QZ1BOr01QZ1B0 rzhQZ1Bir4tQZ1AUrzhQZ1AWrzhQZ1AYrzhQZ1Acr4tQZ1ACrzhQZ1AFr99QZ1AGrzhQZ1AIrzhQ Z1AKrzhQZ1AMrzhQaVBfrxRQaVBAr99QaVBBrxRQaVBNr99QaVBOr99QaVB0rzhQaVAUr99QaVAY r99QaVAcr4tQaVACrzhQaVAFr99QaVAIr+RQaVAMr+RQalBfr99QalBAr4dQalBBr99QalBNr4tQ alBOr4tQalB0r99QalAUr+RQalAYr4tQalAcr75QalACr4tQalAFr4tQalAIr4tQalAMr4tQbFBT r4tQbFBfr01QbFBAr99QbFBBr01QbFBNrzhQbFBOrzhQbFB0rxRQbFAUr99QbFAYr99QbFAcr+RQ bFACrzhQbFADr99QbFAErzhQbFAIr99QbFAJr99QGVD5UHVQBVBfr99QBVBBr99QBVD5UBxQCVBf rzhQCVBBrzhQClBfr+RQClBBr+RQDFBfrzhQDFBBrzhQ+FD4r+RQ+VBTr99Q+VAGr+RQ+VD5r+RQ UFBSUFFQUFBQUERQU1BRUFBRTFBQUVZQUFFQUFBQUFBQUVJQUFBSUFBQUFBQUFBQUFBQUFBQUVBQ U1RVVldYWVpbXF1eX0BBQkNERUZHSElKS0xNTk9wcXJzdHV2d3h5ent8fX5/YGFiY2RlZmdoaWpr bG1ubxAREhMUFRYXGBkaGxwdHh8AAQIDBAUGBwgJCgsMDQ4PMDFQMjM0NTY3ODk6Ozw9Pj8gISIj JCUmJygpKissLS4v0NHS09TV1tfY2drb3N3eUN/AUMFQUMLDUFBQUFDExVDGx8jJylDLUFDMzc5T z/Dx8vP09fb3+Pn6UPv8UP3+/1BQ4OHi4+Tl5ufo6err7O3u71CQkZKTlJWWUFBQl5hQUJlQUFBU UdJQUFB4UHBQVFBYUC5Qr1EDUTFRKFEuUcJSllKMcERwSnBOcHJwdnBgcGpw/HFyckmvr1BQUHBQ 8FECUTBRKFEtUcJSllKMcENwSHBMcHBwdnBgcGlw/HFyckmvr6+zUFCvAK86r2SvH69Zra+turDB UFBQUFBQsCiw1LAlsGGPOo7IUFFQUFB2UFBQUFBQUFBQUFBQUFBQUFCEUIhQjFBQUFBQUFBQUFBQ UFBQUFNQyVDUUNVQ/VDCUJ5Q1lDeUNtQxFDMUMpQQFDaUIxQ01DBUIdQiFDdUMNQ2FDhUJhQhlDF UM1QilCJUItQyFDPUOdQ5VDwUDJQM1DfUDRQ6VA1UOZQ6FDtUOpQ61DsUJ9QNlCQUO5Q71DxUDdQ hVDAUJNQkVCSUDhQgVCDUNlQOlA5UDtQPVA8UD5QxlA/UCFQIFAiUCNQJVAkUCZQJ1CAUChQKlAp UCtQLVAsUPpQx1AvUC5Q0FDRUIJQhFD7UPhQ+VDiUPZQ91DjUNJQ4FDXUFBQUFBRUFFQUVBQUFFQ UERUUFBQRFBQUFBQUEOsYNJDqFZZetYY1qddUVdS8NJDuWDSQ7VSUVFhXmBcVlh61hjWp11SVVVQ YDFWWntWUVRR0mdSUVTwA2ABYHxWWntWUVRR0mdSUUzyTtBMUGxQbFBsUB9QMlAjUD9QPFA1UCRQ NVBuUG5QbmBxYFlWVXteU1JKVVBURFii/2TzP5UfLL1fHWJiLA49Osfj8NJfgmDSUpBg0lJ5UkRD 2eSB2rj3lO1ll8vd2JpPmgMGwWBdVll61hjWp11RUVRVUGDRzmFPYE1WUwVUWkNGBjUiOQM5Nz5w BCIlIyRwHjUkJz8iO2FHYEVWUwVUW0NeBjUiOQM5Nz58cBk+M35hfGB6VlMFVFtDcwY1IjkDOTc+ cAQ5PTVwAyQxPSA5PjdwAzUiJjkzNXACPz8kYWRgYlZTBVRbQ3seH3AcGRESGRwZBAlwERMTFQAE FRR8cHgzeWlncAY1IjkDOTc+fHAZPjN+YE5HXWlnYGVhYmBnYGBgYApHXWlpYWJjYWBnYGBgYApg 0c5hT2BNVlMFVFpDRgY1IjkDOTc+cAQiJSMkcB41JCc/IjthR2BFVlMFVFtDXgY1IjkDOTc+fHAZ PjN+YXxgelZTBVRbQ3MGNSI5Azk3PnAEOT01cAMkMT0gOT43cAM1IiY5MzVwAj8/JGFkYGJWUwVU W0N7Hh9wHBkREhkcGQQJcBETExUABBUUfHB4M3lpZ3AGNSI5Azk3PnxwGT4zfmDRz2BdVll61hjW p11RUVFVUFPR3VBg0dlS0dFQg35woDgsfH1+0UzhVuL3W+dBXQeKA4gls5ljeuKEplkLZKO5wK5Z XICLSwrpnbem2OHNkNd1uy0IQCM6KJshRa2WCKZ5+wgOxlStfTJBCNFMmiHEhXIIf4WcRFXUZurE +uQdGrm+a3L9Bskuccw81pAaF8c65PZmhaxZfYPkactSU1FQUWBdVll61hjWp11RUVRVUFPR0VBq QczVVW6CudCrK4X5pPwprFWsxW0hc/l7eI/cQzXZrnzXUd8KyjKaQffQpOfuROeBBsk7WDIVlvL1 imUvVXKOIn1U1lX3LFlGw0QToKdGHYZX3stAPAiuWmXHmtnPj1QgzHotMd6RuFshyviXNjISbcXE cmLIctnaqjRYdKWCqmDSUp1g0lJmUkVQ7UHKihO9casWCNTZmhbYwHW+RDBgXVZZetYY1qddUVFU VVBg0c5hT2BNVlMFVFpDRgY1IjkDOTc+cAQiJSMkcB41JCc/IjthR2BFVlMFVFtDXgY1IjkDOTc+ fHAZPjN+YXxgelZTBVRbQ3MGNSI5Azk3PnAEOT01cAMkMT0gOT43cAM1IiY5MzVwAj8/JGFkYGJW UwVUW0N7Hh9wHBkREhkcGQQJcBETExUABBUUfHB4M3lpZ3AGNSI5Azk3PnxwGT4zfmBOR11pZ2Bl YWJgZ2BgYGAKR11paWFiY2FgZ2BgYGAKYNH8YXdgdVZTBVRbQ04GNSI5Azk3PnAEOT01cAMkMT0g OT43cAM1IiY5MzVhT2BNVlMFVFtDRgY1IjkDOTc+cAQiJSMkcB41JCc/IjthZGBiVlMFVFtDex4f cBwZERIZHBkECXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58cBk+M35hR2BFVlMFVFpDXgY1IjkD OTc+fHAZPjN+YUFgX1ZTBVRXQ1gZPiQ1Ij41JGDRzWBdVll61hjWp11RUVFVUFPR21Bg0ddS0dFQ +zG95P3dwBfAjORBDjmMWi8ywFZhnZ6v2MEWhxlqxLmEVm/N/fIoCryprDMVH+hbPmC/8mb7fVmP oT93+10BMFVlHy+eBB+A53wSiFuA3egOr+bQgLPG5C9yGRJAPIPI4FEG85Offs9qpC/4CPaHcjW1 3PsozOyJFxI4C30treVSUVNgXVZZetYY1qddUVFUVVBT0dFQPTCryQ/0OeODKyB7MnNOFHAB/3NF lyRSqRmid0oM/NYhZVh7pt+OsOXGuNv3G7MjmBhZzeCK24pFwppTtVl1Bla3HvQX9YEHFoRoBqVx nZN2a311Yp7Lsu8QF7qIPRcmtZBg81/Qni+Iay7wqcV6YXtFqphEvY3guQURIBZ9fC5g0lppYNJZ 8vBTUlFSUkAebtQ+B7DAgInbHJxy0wkdYF1WWXrWGNanXVFRUlVQYDFhQWBfVlMFVFdDWBk+JDUi PjUkYUdgRVZTBVRaQ14GNSI5Azk3PnxwGT4zfmFjYGFWUwVUW0N6BjUiOQM5Nz5wEz89PTUiMzkx PHADPzYkJzEiNXAAJTI8OSM4NSIjcBMRYE5HXWlnYGZgZGBgYGBgYApHXWloYGZgZGJjZWllaQpg 0lEVYUFgX1ZTBVRXQ1gZPiQ1Ij41JGFHYEVWUwVUWkNeBjUiOQM5Nz58cBk+M35hY2BhVlMFVFtD egY1IjkDOTc+cBM/PT01IjM5MTxwAz82JCcxIjVwACUyPDkjODUiI3ATEWEWYBRWUwVUW0NtJycn fiY1IjkjOTc+fjM/PX8iNSA/IzkkPyIpfxMAA3AZPjM/IiB+cDIpcAI1Nn58HBkREn4cBBR4M3lp ZmFrYGlWUwVUW0NiFDk3OSQxPHAZFHATPDEjI3BjcH1wHTkzIj8jPzYkcAM/NiQnMSI1cAYxPDk0 MSQ5Pz5hW2BZVlMFVFZDUgUDYUFgX1ZTBVRYQ1gZPDw5Pj85I2FKYEhWUwVUV0NBFTw7cBciPyY1 cAY5PDwxNzVhcWBPVlMFVFNESB0/Pj8kKSA1cAQpID83IjEgOCl8cBk+M2AMYF1WWXrWGNanXVFR UVVQUxtQYBhSEVDydQ4QA6OnI22oFjfIS4YImrcY/5OInGLnZs2U4KUp8q420uQ0a/t9XVvxmS6E E5muUMD9ErOCCET8qXiYgT81UlNRUFHz0lceYNJXGmBZVlMFTUNUUmBQYFtWUwVNX1RUU1JV8GDR 2FZTBU1RVNHQYC7QQCvGtIETrTjIo2icPmuiW9LxM2AxYUFgX1ZTBVRXQ1gZPiQ1Ij41JGFHYEVW UwVUWkNeBjUiOQM5Nz58cBk+M35hY2BhVlMFVFtDegY1IjkDOTc+cBM/PT01IjM5MTxwAz82JCcx IjVwACUyPDkjODUiI3ATEdJVUuRQUFFgcVZTBU1UUVGvVEdgRGBeYFxWWntWUVRR0mdSUUZTUlfQ UGBdVlMFTVpUVmBUU1JWEGDSVGZWWntWUVRR0mdSUVpRUa9U0lRzYNJUT/B50Hc4JCQgI2p/fycn J34mNSI5Izk3Pn4zPz1/IjUgPyM5JD8iKX8TAAPx0lPo0dJT5AQ4OSNwMzUiJDk2OTMxJDVwOT4z PyIgPyIxJDUjcDIpcCI1NjUiNT4zNXxwMT40cDkkI3AlIzVwOSNwIyQiOTMkPClaIyUyOjUzJHAk P3xwJDg1cAY1IjkDOTc+cBM1IiQ5NjkzMSQ5Pz5wACIxMyQ5MzVwAyQxJDU9NT4kcHgTAAN5WiY1 IiM5Pz5wYX5gfHAxJjE5PDEyPDVwOT5wJDg1cAY1IjkDOTc+cCI1ID8jOSQ/IilwMSRqWjgkJCAj an9/JycnfiY1IjkjOTc+fjM/PWtwMilwFX09MTk8cDEkcBMAA30iNSElNSMkIxAmNSI5Izk3Pn4z Pz1rcD8iWjIpcD0xOTxwMSRwBjUiOQM5Nz58cBk+M358cGJlaWNwEz8xIyRwESY1fnxwHT8lPiQx OT5wBjk1J3xwExFwaWRgZGNaBQMRcBM/ICkiOTc4JHB4M3lhaWlmcAY1IjkDOTc+fHAZPjN+cHAR PDxwAjk3OCQjcAI1IzUiJjU0fnATFQIEERkeWgcRAgIRHgQZFQNwFBkDExwRGR0VFHARHhRwHBkR EhkcGQQJcBwZHRkEFRR+WloHEQIeGR4XanAEGBVwBQMVcB8WcAQYGQNwExUCBBkWGRMRBBVwGQNw AwQCGRMEHAlwAwUSGhUTBHAEH3AEGBVaBhUCGQMZFx5wExUCBBkWGRMRBBkfHnAAAhETBBkTFXAD BBEEFR0VHgR+cHAEGBVwGQMDBRkeF3ARBQQYHwIZBAlaFBkDExwRGR0DcBMVAgQRGR5wGR0AHBkV FHARHhRwFQgAAhUDA3AHEQICER4EGRUDfHAZHhMcBRQZHhdwBxECAhEeBBkVA1ofFnAdFQITGBEe BBESGRwZBAlwHwJwFhkEHhUDA3AWHwJwEXAAEQIEGRMFHBECcAAFAgAfAxV8cBEeFHAHGRwccB4f BFoSFXAcGRESHBVwFh8CcBMfHgMVAQUVHgQZERx8cAAFHhkEGQYVfHARHhRwExUCBBEZHnAfBBgV AnAUER0RFxUDfnADFRVaBBgVcBMAA3AWHwJwFBUEERkcA35aWhM/PiQ1PiQjcD82cCQ4NXAGNSI5 Azk3PnAiNTc5IyQ1IjU0cD4/PiY1Ijk2OTU0AyUyOjUzJBEkJCI5MiUkNSNaNSgkNT4jOT8+cCYx PCU1cCM4MTw8cD4/JHAyNXAzPz4jOTQ1IjU0cDEjcDEzMyUiMSQ1cDk+Nj8iPTEkOT8+WiYxPDk0 MSQ1NHAyKXAkODVwGRF+WvNm0GQ4JCQgI2p/fycnJ34mNSI5Izk3Pn4zPz1/IjUgPyM5JD8iKX8m NSI5Izk3Pjw/Nz9+Nzk2YNJST1ZTBU1TVNJSRmDSUkJg0lJeYNJSWlZbMNYYUdaoFVFXUVFg0lGp RtJR9wQ4OSNwMzUiJDk2OTMxJDVwOT4zPyIgPyIxJDUjcDIpcCI1NjUiNT4zNXxwMT40cDkkI3Al IzVwOSNwIyQiOTMkPClwIyUyOjUzJHAkP3xwJDg1cAY1IjkDOTc+cBM1IiQ5NjkzMSQ5Pz5wACIx MyQ5MzVwAyQxJDU9NT4kcHgTAAN5fHAxJjE5PDEyPDVwMSRqcDgkJCAjan9/JycnfiY1IjkjOTc+ fjM/PX8TAANrcDIpcBV9PTE5PHAxJHATAAN9IjUhJTUjJCMQJjUiOSM5Nz5+Mz89a3A/InAyKXA9 MTk8cDEkcAY1IjkDOTc+fHAZPjN+fHBiZWljcBM/MSMkcBEmNX58cB0/JT4kMTk+cAY5NSd8cBMR cGlkYGRjcAUDEXAENTx+cHthcHhkYWV5cGlmYX1oaGNgcBM/ICkiOTc4JHB4M3lwYWlpZnAGNSI5 Azk3PnxwGT4zfnBwETw8cAI5NzgkI3ACNSM1IiY1NH5wExUCBBEZHnAHEQICER4EGRUDcBQZAxMc ERkdFRRwMT40cBwZERIZHBkECXAcGR0ZBBUUfvBeVlww1hhR1qgVUVdRUVHxXlZcMNYYUdaoFVFX UVFSYHxgekZ4OCQkICNqf38nJyd+JjUiOSM5Nz5+Mz89fyI1ID8jOSQ/Iil/EwADcGBGVlp7VlFU UdJnUlFLVFhgVlFRr1FRr2BdVll61hjWp11RUVJVUFPR0VDQpQ43yh22CU5em+uMniWtZrf2x7Au FyjMVVP0w0ZyR+yHl8mzFKp1qftSD12GPqyEiJaOXiizvylygUak03iYuBatKmxu47jpfoW0i70S y6Wog+e0LYj4vzN81cBVnkIVaYcy2lZOrS2VGK0KO4ATDH+ewSxqvgp9ZCHxgMh00mHSU8Vg0lPB UlFRYCVgMWFBYF9WUwVUV0NYGT4kNSI+NSRhR2BFVlMFVFpDXgY1IjkDOTc+fHAZPjN+YWNgYVZT BVRbQ3oGNSI5Azk3PnATPz09NSIzOTE8cAM/NiQnMSI1cAAlMjw5Izg1IiNwExFSQB5u1D4HsMCA idscnHLTCR1gXFZYetYY1qddUlVVUPDRsWBJVll61hjWp11RWVNhXFZae1ZRVFHSZ1JRVGBMVlp7 VlFUUdJnUlFbYV5gXFZae1ZRVFHSZ1JRRmBPVll61hjWp11RWVRhQlRACyai+mbbdfRoFbq4/Gyy eGDR1FZae1ZRVFHSZ1JRXGEmYCTwBtAEUBFQIlA5UDFQPFBwUBJQP1A8UDRQcFAfUCBQNVA+UARQ KVAgUDVQcFA2UD9QPlAkUHBQB1A5UD5QcFARUB5QA1AZUHBQM1A4UDFQIlBwUCNQNVAk8UrQSDgk JCBqf38nJyd+PT8+PyQpIDV+Mz89cGBdVll61hjWp11RUVFVUFQQMSID2/EfdVFl4JRz0x5yuAnT +5k+erpv0HBxlKqr4rGI7T6KKdbAFJk5n7+0TDJvdTF4a6qoNra5LlojU5sJYfHSUYBg0lGcVll6 1hjWp11RWVZh0lHtYNJR6VJRUWDR6GDRzmFPYE1WUwVUWkNGBjUiOQM5Nz5wBCIlIyRwHjUkJz8i O2FHYEVWUwVUW0NeBjUiOQM5Nz58cBk+M35hfGB6VlMFVFtDcwY1IjkDOTc+cAQ5PTVwAyQxPSA5 PjdwAzUiJjkzNXACPz8kYWRgYlZTBVRbQ3seH3AcGRESGRwZBAlwERMTFQAEFRR8cHgzeWlncAY1 IjkDOTc+fHAZPjN+UkVQ7UHKihO9casWCNTZmhbYwHW+RDBgXFZYetYY1qddUlVVUPAJYEhWWXrW GNanXVFZU2FbVll61hjWp11RV1FgTFZZetYY1qddUVlVYV9HXWlnYGhiZmJjYWVjZQpgT1ZZetYY 1qddUVlUYUJUQFm6m8vhiBx03eTXvvJfIhNgXVZZetYY1qddUVFRVVBU0dBEkK+liHWpjNdiO+Q3 YAP3VgaIXVKyogSh+TcJdcR3xkeMCoKpqkSpiJLj+64yUz2abOM7vLeQpFixyMNsylbdqvdkJ+Ck FaPBYhe/xDQbSaCN2NOQ6GwqMUMTrB/AJ4vfDj98MCR85hRDonrltLCMIY1wZel5s6OqbI0Zr0uX OyAAuA8qEQEAKhEBAHwQAQABAAIAAAAAEAILBgQCAgIJAgQA/5ABAAAAAExQAwAAAAAAAAAAAAAA AAAAAAEAAAAAAAAADwmBaQAAAAAAAAAAAAAAAAAAAAAAAAwAQQByAGkAYQBsAAAAAAAOAEkAdABh AGwAaQBjAAAAAAAYAFYAZQByAHMAaQBvAG4AIAAyAC4ANAA1AAAAGABBAHIAaQBhAGwAIABJAHQA YQBsAGkAYwAAAAAAUFFQUFBDUVBQVFBgFAMZF+pkm9pQUKwwUFBETBwEAxiediTnUFBCCFBQULIf A39iwALEn1BQUehQUFAGBhQdCAAvOqBQUENsUFBBxDM9MSB9+rFSUFCpkFBQUvAzJiRwZJtxm1BQ YHRQUFUcNiA3PUvoFz9QUHq0UFBVbjcxIyBQSFBZUFBSQFBQUEA3PCk2O+I97FBQHaBQUPc6ODQ9 KP0927ZQUGi4UFBFWDg1MTSSAX9YUFBRbFBQUGY4ODUxX0FWBlBQUSRQUFB0OD0kKJJ3NEhQUGUg UFBTKDs1Ij5VIFQ3UFCnMFBQUg48PzMxyIgg0lBQQMhQUFHuPTEoIFNgVoFQUFHIUFBQcD4xPTUl hRhUUFBScFBQXiUgPyMkausnClBQpQxQUFJRICI1INn1UqNQUHSAUFBWQlBRUFBQUtBQOdFZXw9f bKVYSVhQUFBQUPMiku9QUFBQ4Hjxgq9YrgFYLld4UFJQWVBRUFBQUFBQUFFQUFdurh5QE1hPr1iu ulguUHFQV1BQUFBQUFBQUFBQUFCOUFFQUFCOUAhQV1AeUFRQUlBAUEZQEVBQUaNWQlBSUFFQUVPY UcBQVVBQVcpVY1BOUUtVylVjUApTgVA2UkJYVVJbVlRSUlJZUlRQUFBTUFBQUFBQUFBQUFBQHT8+ P1BRUHBySVWDrgdRY1duUeJQUFBRUFBQUFBQUFBQU1BYUFJQQVBRr69QU1BQUBNTelBRUFBQUFBQ UC9QUFBRUFBQUFBRUFVQL1BRUFBQUFBSUFZQqFBRUFBQUFBTUGZQsVBRUFBQUFBUUFxRR1BRUFBQ UFBVUFxQr1BRUFBQUFBWUF5Rc1BRUFBQUFBXUDJQL1BTUFFUU1BSUF5RbVBTUFFUU1BUUEpRYVBT UFFUVVBSUF5RB1BTUFFUVVBUUEpRG1BTUFFUVlBSUFxRIVBTUFFUVlBUUEhRNVBTUFFUV1BSUFxR 2VBTUFFUV1BUUEhRLVBTUFFUWFBSUFxR+VBTUFFUWFBUUEhRzVBTUFFUWVBQUK5R5VBTUFFUWVBR UFpSo1BTUFFUWVBSUFxX81BTUFFUWVBTUDxXJVBTUFFUWVBUUEhXsVBTUFFUWVBVUEhX4VBTUFFU WVBWUExXqVBTUFFUWVBXUJRYRVBTUFFUWVBYUHZYiVBTUFFUWVBZUNpYr1BTUFFUWVBaVJJS41BT UFFUWVBbUDJZ2VBTUFFUWVBcUDZZu1BTUFFUWlBSUF5RbVBTUFFUWlBUUEpRYVBTUFFUW1BSUERR 2VBTUFFUW1BUUHBRLVBTUFFUXFBSUEBaDVBTUFFUXFBUUExaAVBTUFFUXlBSUFhaKVBTUFFUXlBU UERaPVBTUFFUQFBSUF5a3VBTUFFUQFBUUEpa0VBTUFFUQ1BSUF5a91BTUFFUQ1BUUEpay1BTUFFU RFBSUFxR2VBTUFFURFBUUEhRLVBTUFFURVBSUF5akVBTUFFURVBUUEpa5VBTUFFURlBSUF5ai1BT UFFURlBUUEpan1BTUFFUSVBSUFxapVBTUFFUSVBUUEhauVBTUFFUS1BSUF5bXVBTUFFUS1BUUEpb UVBTUFFUTVBSUFxR2VBTUFFUTVBUUEhRLVBTUFFUT1BSUFxbd1BTUFFUT1BUUEhbS1BTUFFUfVBS UFxbb1BTUFFUfVBUUEhbY1BTUFFYWlBSUF5RbVBTUFFYWlBUUEpRYVBTUFFYRlBSUF5ai1BTUFFY RlBUUEpan1BTUFFcWlBSUF5RbVBTUFFcWlBUUEpRYVBTUFFcXFBSUEBaDVBTUFFcXFBUUExaAQQp IDU2MTM1cPlwBDg1cB0/Pj8kKSA1cBM/IiA/IjEkOT8+cCA8M35wFDEkMXD5cAQ4NXAdPz4/JCkg NXATPyIgPyIxJDk/PnAgPDN/BCkgNXADPzwlJDk/PiNwGT4zfnBhaWlgfWFpaWJ+cBE8PHACOTc4 JCNwAjUjNSImNTQRIjkxPPhwBCIxNDU9MSI7cD82cAQ4NXAdPz4/JCkgNXATPyIgPyIxJDk/PnAg PDNwIjU3OSMkNSI1NHA5PnAkODVwBQNwADEkcHZwBB1wHzY2fnAxPjRwNTwjNSc4NSI1fh0/Pj8k KSA1ahEiOTE8cAI1NyU8MSJwGSQxPDkzagY1IiM5Pz5wYn5kZXB4HTkzIj8jPzYkeREiOTE8cBkk MTw5MxEiOTE8fRkkMTw5Mx0EUBFQIlA5UDFQPFBwUBNQJVAiUCNQOVAmUDFQEVAiUDlQMVA8UHBQ O1AlUCJQKlC9UCZQMVARUCJQOVAxUDxQcFA7UCVQIlAjUDlQJlARUCJQOVAxUDxQcFAbUCVQIlAj UDlQJlA/UDlQJFAlUBFQIlA5UDFQPFBwU/BT61P8U+NT6VPhUARQKVAgUDVQNlAxUDNQNVBwUPlQ cFAEUDhQNVBwUB1QP1A+UD9QJFApUCBQNVBwUBNQP1AiUCBQP1AiUDFQJFA5UD9QPlBwUCBQPFAz UH5QcFAUUDFQJFAxUHBQ+VBwUARQOFA1UHBQHVA/UD5QP1AkUClQIFA1UHBQE1A/UCJQIFA/UCJQ MVAkUDlQP1A+UHBQIFA8UDNQf1AEUClQIFA1UHBQA1A/UDxQJVAkUDlQP1A+UCNQcFAZUD5QM1B+ UHBQYVBpUGlQYFB9UGFQaVBpUGJQflBwUBFQPFA8UHBQAlA5UDdQOFAkUCNQcFACUDVQI1A1UCJQ JlA1UDRQE1A/UD5QJFA1UD1QIFA/UCJQMVAiUClQcFAjUDFQPlAjUHBQI1A1UCJQOVA2UHBQNFA1 UCNQOVA3UD5QfFBwUBFQIlA5UDFQPFBwUDNQP1A+UCRQMVA5UD5QI1BwUD1QP1AiUDVQcFA4UCVQ PVAxUD5QOVAjUCRQcFAzUDhQMVAiUDFQM1AkUDVQIlA5UCNQJFA5UDNQI1BwUCRQOFAxUD5QcFA9 UDFQPlApUHBQP1A2UHBQOVAkUCNQcFAgUCJQNVA0UDVQM1A1UCNQI1A/UCJQI1BwUDFQPlA0UHBQ MVAjUHBQI1AlUDNQOFBwUDlQI1BwUD1QP1AiUDVQcFA5UD5QcFAkUCVQPlA1UHBQJ1A5UCRQOFBw UCRQOFA1UHBQPVA/UD9QNFBwUD9QNlBwUCRQOFA1UHBQPFAxUCNQJFBwUDRQNVAzUDFQNFA1UCNQ cFA/UDZQcFAkUDhQNVBwUCRQJ1A1UD5QJFA5UDVQJFA4UHBQM1A1UD5QJFAlUCJQKVB+UHBQcFAE UDhQNVBwUD9QJlA1UCJQMVA8UDxQcFAkUCJQNVAxUCRQPVA1UD5QJFBwUD9QNlBwUDNQJVAiUCZQ NVAjUHBQOVAjUHBQI1A/UDZQJFA1UCJQcFAxUD5QNFBwUDZQJVA8UDxQNVAiUHBQJFA4UDFQPlBw UDlQPlBwUD1QP1AjUCRQcFA5UD5QNFAlUCNQJFAiUDlQMVA8UHBQI1AkUClQPFA1UHBQI1AxUD5Q I1BwUCNQNVAiUDlQNlBwUDZQMVAzUDVQI1B+UHBQcFAEUDVQIlA9UDlQPlAxUDxQcFAjUCRQIlA/ UDtQNVAjUHBQMVAiUDVQcFAzUCVQJFBwUD9QPlBwUCRQOFA1UHBQNFA5UDFQN1A/UD5QMVA8UHBQ J1A4UDlQM1A4UHBQOFA1UDxQIFAjUHBQJFA/UHBQN1A5UCZQNVBwUCRQOFA1UHBQNlAxUDNQNVBw UDFQcFA8UDVQI1AjUHBQPVA1UDNQOFAxUD5QOVAzUDFQPFBwUDFQIFAgUDVQMVAiUDFQPlAzUDVQ flBwUHBQEVAiUDlQMVA8UHBQOVAjUHBQMVA+UHBQNVAoUCRQIlA1UD1QNVA8UClQcFAmUDVQIlAj UDFQJFA5UDxQNVBwUDZQMVA9UDlQPFApUHBQP1A2UHBQJFApUCBQNVA2UDFQM1A1UCNQcFAnUDhQ OVAzUDhQcFAzUDFQPlBwUDJQNVBwUCVQI1A1UDRQcFAnUDlQJFA4UHBQNVAhUCVQMVA8UHBQI1Al UDNQM1A1UCNQI1BwUDZQP1AiUHBQJFA1UChQJFBwUCNQNVAkUCRQOVA+UDdQcFA5UD5QcFAiUDVQ IFA/UCJQJFAjUHxQcFAgUCJQNVAjUDVQPlAkUDFQJFA5UD9QPlAjUHxQcFA9UDFQN1AxUCpQOVA+ UDVQI1BwUDVQJFAzUHxQcFAxUD5QNFBwUDZQP1AiUHBQNFA5UCNQIFA8UDFQKVBwUCVQI1A1UHBQ OVA+UHBQPlA1UCdQI1AgUDFQIFA1UCJQI1B8UHBQMVA0UCZQNVAiUCRQOVAjUDlQPlA3UHBQMVA+ UDRQcFAgUCJQP1A9UD9QJFA5UD9QPlAjUH5QHVA/UD5QP1AkUClQIFA1UGpQEVAiUDlQMVA8UHBQ AlA1UDdQJVA8UDFQIlBwUBlQJFAxUDxQOVAzUGpQBlA1UCJQI1A5UD9QPlBwUGJQflBkUGVQcFB4 UB1QOVAzUCJQP1AjUD9QNlAkUHlQEVAiUDlQMVA8UHBQGVAkUDFQPFA5UDNQEVAiUDlQMVA8UH1Q GVAkUDFQPFA5UDNQHVAEUBFQIlA5UDFQPFD+UHBQBFAiUDFQNFA1UD1QMVAiUDtQcFA/UDZQcFAE UDhQNVBwUB1QP1A+UD9QJFApUCBQNVBwUBNQP1AiUCBQP1AiUDFQJFA5UD9QPlBwUCBQPFAzUHBQ IlA1UDdQOVAjUCRQNVAiUDVQNFBwUDlQPlBwUCRQOFA1UHBQBVADUHBQAFAxUCRQcFB2UHBQBFAd UHBQH1A2UDZQflBwUDFQPlA0UHBQNVA8UCNQNVAnUDhQNVAiUDVQflAdUD9QPlA/UCRQKVAgUDVQ cFAEUClQIFA/UDdQIlAxUCBQOFApUB1QP1A+UD9QJFApUCBQNVBwUARQKVAgUDVQcFAUUCJQMVAn UDlQPlA3UHBQH1A2UDZQOVAzUDVQcFB9UHBQAlA/UDJQOVA+UHBQHlA5UDNQOFA/UDxQMVAjUHxQ cFAAUDFQJFAiUDlQM1A5UDFQcFADUDFQJVA+UDRQNVAiUCNQcFBhUGlQaFBiUDhQJFAkUCBQalB/ UH9QJ1AnUCdQflA9UD9QPlA/UCRQKVAgUDVQflAzUD9QPVB/UDhQJFA9UDxQf1A9UCRQPlAxUD1Q NVB/UD1QI1APUDFQIlA5UDFQPFB+UDhQJFA9UDxQOFAkUCRQIFBqUH9Qf1AnUCdQJ1B+UD1QP1A+ UD9QJFApUCBQNVB+UDNQP1A9UH9QOFAkUD1QPFB/UD1QJFA+UDFQPVA1UH9QPVAjUA9QJ1A1UDxQ M1A/UD1QNVB+UDhQJFA9UDxQEVAiUDlQMVA8UHBQGVAkUDFQPFA5UCFQJVA1UBFQIlA5UDFQPFBw UBRRAVA8UCRQEVAiUDlQMVA8UHBQE1A/UCJQI1A5UCZQP1ARUCJQOVAxUDxQcFATUCVQIlAjUDlQ NVA2UBFQIlA5UDFQPFBwUBtQJVAiUCNQKVAnUDFQEVAiUDlQMVA8UHBQGVAkULFQPFA5UDNQP1AR UCJQOVAxUDxQcFRKVBNUEFQRVGhUYlARUCJQOVAxUDxQcFAAUD9QylA1UCZQPlA/UBFQIlA5UDFQ PFBwUWBQJFAxUDxQOVA7UBFQIlA5UDFQPFBwUBVQJFAqUDFQPlAxUFBQUFBQalBqUGpQalDSUMpR HFIcUrdTlFReVBlU3FSkVXxVOFXWVc9VlFZnVsZXTFf4WAdYpFkvWZlaOVtRW3tbLFvuW71cYVzL Xd9eUF77X31f/EB5QMZBZUGQQkhC30NfQwtE3kULRY9GCkdxR4ZIxUiqSSBJiErLSzFLgkwATMFM 6kysTWpNBE3RTmNOuU8MT7RwLHFTcY9yw3MRc5x0InSvdbV21Hakd/h4BXi9efl6SXqTe3t7uXzD fVZ9Ln5Ifml+j399fxZ/Dn8lf95/9n/vf41/pWBdYHxgFWAOYChg3mD2YO5giGClYVxhdmETYQth JmHeYfhhlWGzYa9iSGJhYhxiNWKHY0ljh2QoZWJlDWXLZhhnRWf+aHNoBWjUaXtqVmoea1pr5GwH bM9tzm43bopvcG8Wb40QfRApEO0QhRC+EVkRiBLjEp4SthMXE+sUUBQTFN0U+hSVFdEV5hW3FtgW 8BaLFx0YTBhqGAUYPRjdGPYY7hiMGKUZXhl2GRAZCBkhGd8Z+BpOGgca9BqOGwIb3hv7G5QbjRuo HH8cgx3AHfgdkB4RHoMfbB/AH6UAPwF/AlUDUgNzA+VQUFBQUI5XUVFRV1ZWVlVVVlZWVldXVldX VlZWVlZWVlZWVldXV1dXVmJVVVZWVVdXVntWVVbDVldVV1ZVV1xV31VVV1dXV1dWVlZeVlZWV01W aVxfYI5WcVZkVlZGVkLNbF7HVldWV1VVVlVWV1ZWVlZWVlZWVlZWVldXV1dWVlZWVlZWVlZWVlVW VlaYVldWVmBWVlFXVlavVlZVV1dXVwlWVlFVVVdRV1ZRVq+5r1ZWVZ9WVlZXVa8cVVVVVVVXV1dX V1dXVlZWc7WzUVavVVZMx1dWVlVWVVZXr1asVFRUVlZQUFBQUFNQU1FRUVFRVVNTUVJRUVBIVbxb kFCoWK9QWFBYr61QWVBZr61QWlBar61QW1Bbr61QXFBcr61QXVBdr61QXlBdr61QX1Ber61QQFBA r61QQVBAr6xQQlBBr6tQQ1BCr6tQRFBDr6tQRVBDr6tQRlBEr6pQR1BGr6pQSFBGr6pQSVBHr6pQ SlBIr6pQS1BJr6pQTFBJr6pQTVBLr6lQTlBMr6lQT1BNr6lQcFBNr6hQcVBOr6hQclBPr6hQc1Bw r6hQdFBxr6hQdVByr6dQdlBzr6dQd1B0r6dQeFB0r6dQeVB1r6ZQelB2r6ZQe1B4r6ZQfFB4r6ZQ fVB5r6VQflB6r6VQf1B7r6VQYFB8r6VQYVB9r6VQYlB+r6VQY1B/r6VQZFBgr6NQZVBgr6NQZlBh r6NQZ1Bir6NQaFBjr6NQaVBjr6NQalBkr6NQa1Blr6JQbFBmr6JQbVBmr6JQblBnr6JQb1Bor6JQ EFBrr6FQEVBrr6FQElBsr6BQE1Btr6FQFFBur6FQFVBur6FQFlBvr6BQF1AQr6BQGFARr6BQGVAR r79QGlASr79QG1ATr79QHFAVr79QHVAWr79QHlAWr79QH1AXr79QAFAYr79QAVAZr75QAlAZr75Q A1Aar71QBFAbr71QBVAcr71QBlAdr7xQB1Aer7xQCFAfr7xQCVAAr7xQClAAr7xQC1ABr7xQDFAD r7xQDVAEr7xQDlAEr7xQD1AFr7pQMFAHr7pQMVAIr7pQMlAIr7pQM1AJr7lQNFAKr7lQNVALr7lQ NlAMr7lQN1AMr7lQOFANr7lQOVAOr7lQOlAwr7lQO1Awr7lQPFAxr7lQPVAyr7lQPlAzr7hQP1Az r7hQIFA0r7dQIVA1r7dQIlA2r7dQI1A2r7dQJFA4r7dQJVA5r7dQJlA7r7dQJ1A7r7dQKFA8r7ZQ KVA9r7ZQKlA+r7ZQK1A+r7ZQLFA/r7ZQLVAgr7VQLlAhr7VQL1Air7RQ0FAjr7RQ0VAkr7RQ0lAl r7RQ01Amr7RQ1FAmr7RQ1VAnr7NQ1lAor7NQ11Apr7NQ2FApr7NQ2VArr7NQ2lAsr7JQ21Atr7JQ 3FAtr7JQ3VAur7JQ3lAvr7FQ31DQr7FQwFDQr7FQwVDSr7FQwlDTr7BQw1DVr7BQxFDVr7BQxVDW r7BQxlDXr7BQx1DXr49QyFDXr49QyVDZr49QylDar49Qy1Dbr49QzFDcr49QzVDcr49QzlDdr45Q z1Dfr45Q8FDAr45Q8VDAr41Q8lDBr41Q81DCr41Q9FDDr4xQ9VDDr4xQ9lDEr4xQ91DGr4xQ+FDH r4xQ+VDHr4xQ+lDIr4xQ+1DJr4tQ/FDKr4tQ/VDKr4tQ/lDLr4tQ/1DNr4tQ4FDOr4tQ4VDOr4tQ 4lDPr4lQ41Dwr4lQ5FDyr4lQ5VDzr4lQ5lDzr4lQ51D0r4lQ6FD1r4hQ6VD2r4hQ6lD2r4hQ61D3 r4hQ7FD4r4hQ7VD5r4hQ7lD6r4hQ71D7r4dQkFD8r4dQkVD9r4dQklD9r4dQk1D+r4ZQlFD/r4VQ lVDgr4VQllDhr4VQl1Dir4VQmFDjr4VQmVDkr4VQmlDlr4VQm1Dmr4VQnFDnr4RQnVDor4RQnlDp r4RQn1Dpr4RQgFDqr4RQgVDrr4NQglDsr4NQg1Dsr4NQhFDtr4JQhVDvr4JQhlCQr4JQh1CQr4JQ iFCRr4JQiVCSr4FQilCTr4FQi1CTr4FQjFCVr4FQjVCWr4FQjlCXr4BQj1CXr4BQsFCYr4BQsVCa r4BQslCbr4BQs1Cbr4BQtFCcr4BQtVCdr59QtlCer55Qt1Cfr55QuFCfr55QuVCAr55QulCBr51Q u1CDr51QvFCDr51QvVCEr51QvlCFr51Qv1CGr51QoFCGr51QoVCHr51QolCJr51Qo1CKr5xQpFCK r5xQpVCLr5xQplCMr5tQp1CNr5pQqFCOr5pQqVCPr5pQqlCwr5pQq1Cxr5pQrFCxr5pQrVCyr5pQ rlCzr5pQr1C0r5pQqFivUFhQWK+tUFlQWa+tUFpQWq+tUFtQW6+tUFxQXK+tUF1QXa+tUF5QXa+t UF9QXq+tUEBQQK+tUEFQQK+sUEJQQa+rUENQQq+rUERQQ6+rUEVQQ6+rUEZQRK+qUEdQRq+qUEhQ Rq+qUElQR6+qUEpQSK+qUEtQSa+qUExQSa+qUE1QS6+pUE5QTK+pUE9QTa+pUHBQTa+oUHFQTq+o UHJQT6+oUHNQcK+oUHRQcK+oUHVQca+nUHZQcq+nUHdQc6+nUHhQdK+nUHlQda+nUHpQdq+nUHtQ d6+nUHxQd6+nUH1QeK+mUH5Qeq+lUH9Qe6+lUGBQfK+lUGFQfK+lUGJQfa+lUGNQfq+lUGRQf6+k UGVQf6+kUGZQYK+kUGdQYa+kUGhQY6+kUGlQY6+jUGpQZK+jUGtQZa+iUGxQZq+iUG1QZq+iUG5Q Z6+iUG9QaK+iUBBQaq+iUBFQaq+iUBJQbK+hUBNQba+hUBRQbq+hUBVQbq+hUBZQb6+hUBdQEK+h UBhQEa+hUBlQEa+gUBpQEq+gUBtQE6+gUBxQFa+gUB1QFq+/UB5QFq+/UB9QF6+/UABQGK+/UAFQ Ga++UAJQGa++UANQGq++UARQG6++UAVQHK++UAZQHa+9UAdQHq+9UAhQH6+9UAlQAK+9UApQAK+9 UAtQAa+9UAxQA6+9UA1QBK+8UA5QBK+8UA9QBa+7UDBQB6+7UDFQCK+7UDJQCK+7UDNQCa+6UDRQ Cq+6UDVQC6+6UDZQDK+6UDdQDK+6UDhQDa+6UDlQDq+6UDpQMK+6UDtQMK+5UDxQMa+5UD1QMq+5 UD5QM6+4UD9QM6+4UCBQNK+3UCFQNa+3UCJQNq+3UCNQNq+3UCRQOK+3UCVQOa+3UCZQOq+3UCdQ Oq+3UChQO6+2UClQPK+2UCpQPa+2UCtQPq+2UCxQP6+2UC1QIK+1UC5QIa+1UC9QIq+0UNBQIq+0 UNFQI6+0UNJQJK+0UNNQJq+0UNRQJq+0UNVQJ6+zUNZQKK+zUNdQKa+zUNhQKa+zUNlQKq+zUNpQ LK+yUNtQLa+yUNxQLa+yUN1QLq+yUN5QL6+xUN9Q0K+xUMBQ0K+xUMFQ0q+xUMJQ06+wUMNQ1K+w UMRQ1K+wUMVQ1a+wUMZQ1q+wUMdQ16+PUMhQ16+PUMlQ2a+PUMpQ2q+PUMtQ26+PUMxQ3K+PUM1Q 3K+PUM5Q3a+OUM9Q36+OUPBQwK+OUPFQwK+NUPJQwa+NUPNQwq+NUPRQw6+MUPVQw6+MUPZQxK+M UPdQxq+MUPhQx6+MUPlQx6+MUPpQyK+MUPtQya+LUPxQyq+LUP1Qyq+LUP5Qy6+LUP9Qza+LUOBQ zq+LUOFQzq+LUOJQz6+JUONQ8K+JUORQ8q+JUOVQ86+JUOZQ86+JUOdQ9K+JUOhQ9a+IUOlQ9q+I UOpQ9q+IUOtQ96+IUOxQ+K+IUO1Q+a+IUO5Q+q+IUO9Q+6+HUJBQ/K+HUJFQ/a+HUJJQ/a+HUJNQ /q+GUJRQ/6+FUJVQ4K+FUJZQ4a+FUJdQ4q+FUJhQ46+FUJlQ5K+FUJpQ5a+FUJtQ5q+FUJxQ56+E UJ1Q6K+EUJ5Q6a+EUJ9Q6a+EUIBQ6q+EUIFQ66+DUIJQ7K+DUINQ7K+DUIRQ7a+CUIVQ76+CUIZQ kK+CUIdQkK+CUIhQka+CUIlQkq+BUIpQk6+BUItQk6+BUIxQla+BUI1Qlq+BUI5Ql6+AUI9Ql6+A ULBQmK+AULFQmq+AULJQm6+AULNQm6+AULRQnK+AULVQna+fULZQnq+eULdQn6+eULhQn6+eULlQ gK+eULpQga+dULtQg6+dULxQg6+dUL1QhK+dUL5Qha+dUL9Qhq+dUKBQhq+dUKFQh6+dUKJQia+d UKNQiq+cUKRQiq+cUKVQi6+cUKZQjK+bUKdQja+bUKhQjq+bUKlQj6+bUKpQsK+bUKtQsa+bUKxQ sa+bUK1Qsq+bUK5Qs6+bUK9QtK+aUKhYr1BYUFivrVBZUFmvrVBaUFqvrVBbUFuvrVBcUFyvrVBd UF2vrVBeUF2vrVBfUF6vrVBAUECvrVBBUECvrFBCUEGvq1BDUEKvq1BEUEOvq1BFUEOvq1BGUESv qlBHUEavqlBIUEavqlBJUEevqlBKUEivqlBLUEmvqlBMUEmvqlBNUEuvqVBOUEyvqVBPUE2vqVBw UE2vqFBxUE6vqFByUE+vqVBzUHCvqFB0UHCvqFB1UHGvp1B2UHKvp1B3UHOvp1B4UHSvp1B5UHWv p1B6UHavp1B7UHevp1B8UHevp1B9UHivplB+UHqvpVB/UHuvpVBgUHyvpVBhUHyvpVBiUH2vpVBj UH6vpVBkUH+vpFBlUH+vpFBmUGCvpFBnUGGvpFBoUGOvpFBpUGOvpFBqUGSvpFBrUGWvo1BsUGav olBtUGavolBuUGevolBvUGivolAQUGqvolARUGqvolASUGyvoVATUG2voVAUUG6voVAVUG6voVAW UG+voVAXUBCvoVAYUBGvoVAZUBGvoFAaUBKvoFAbUBOvoFAcUBWvv1AdUBavv1AeUBavv1AfUBev v1AAUBivv1ABUBmvvlACUBmvvlADUBqvvlAEUBuvvlAFUByvvlAGUB2vvVAHUB6vvVAIUB+vvVAJ UACvvVAKUACvvVALUAGvvVAMUAOvvVANUASvvFAOUASvvFAPUAWvu1AwUAevu1AxUAivu1AyUAiv u1AzUAmvulA0UAqvulA1UAuvulA2UAyvulA3UAyvulA4UA2vulA5UA6vulA6UDCvulA7UDCvuVA8 UDGvuVA9UDKvuVA+UDOvuFA/UDOvuFAgUDSvt1AhUDWvt1AiUDavt1AjUDavt1AkUDivt1AlUDmv t1AmUDqvt1AnUDqvt1AoUDuvtlApUDyvtlAqUD2vtlArUD6vtlAsUD+vtlAtUCCvtVAuUCGvtVAv UCKvtFDQUCKvtFDRUCOvtFDSUCSvtFDTUCavtFDUUCavtFDVUCevs1DWUCivs1DXUCmvs1DYUCmv s1DZUCqvs1DaUCyvslDbUC2vslDcUC2vslDdUC6vslDeUC+vsVDfUNCvsVDAUNCvsVDBUNKvsVDC UNOvsFDDUNSvsFDEUNSvsFDFUNWvsFDGUNavsFDHUNevj1DIUNevj1DJUNmvj1DKUNqvj1DLUNuv j1DMUNyvj1DNUNyvj1DOUN2vjlDPUN+vjlDwUMCvjlDxUMCvjVDyUMGvjVDzUMKvjVD0UMOvjFD1 UMOvjFD2UMSvjFD3UMavjFD4UMevjFD5UMevjFD6UMivjFD7UMmvi1D8UMqvi1D9UMqvi1D+UMuv i1D/UM2vi1DgUM6vi1DhUM6vi1DiUM+viVDjUPCviVDkUPKviVDlUPOviVDmUPOviVDnUPSviVDo UPWviFDpUPaviFDqUPaviFDrUPeviFDsUPiviFDtUPmviFDuUPqviFDvUPuvh1CQUPyvh1CRUP2v h1CSUP2vh1CTUP6vhlCUUP+vhVCVUOCvhVCWUOGvhVCXUOKvhVCYUOOvhVCZUOSvhVCaUOWvhVCb UOavhVCcUOevhFCdUOivhFCeUOmvhFCfUOmvhFCAUOqvhFCBUOuvhFCCUOyvhFCDUOyvhFCEUO2v g1CFUO+vg1CGUJCvg1CHUJCvg1CIUJGvglCJUJKvgVCKUJOvgVCLUJOvgVCMUJWvgVCNUJavgVCO UJevgVCPUJevgVCwUJivgVCxUJqvgVCyUJuvgFCzUJuvgFC0UJyvgFC1UJ2vn1C2UJ6vnlC3UJ+v nlC4UJ+vnlC5UICvnlC6UIGvnlC7UIOvnlC8UIOvnlC9UISvnlC+UIWvnlC/UIavnlCgUIavnVCh UIevnVCiUImvnVCjUIqvnFCkUIqvnFClUIuvnFCmUIyvm1CnUI2vm1CoUI6vm1CpUI+vm1CqULCv m1CrULGvm1CsULGvm1CtULKvm1CuULOvm1CvULSvmulQ0FL04xUoYhDoUvTjYmpi0OhS9ON6YWIQ 6FL043R1Yi8RQFL0UFFQv1L0UFFQX1L0UH9S9FBvUvRQL1L0UFRQEFL040VNYtDoUvTjWURiEOhS 8+NKS2Jf71LzUC9S81C/UvNQU1AQUvMQWllEYkIfVh9XUr8RZ1G7UFFQz1G7UFFQL1G7UFFQD1G7 UFFQb1G7UFFQf1G7UFFQX1G7UFFQL1G6UFFQv1G6UFFQ71G6UFFQ/1G6UFFQf1G6UFFQb1G6UFFQ H1G6UFFQP1G6UFFQL1G6UFFRvVG9UbxRvFG7UbtRulG6EEJQfFFQT1FAfFFAT1EQfFEQT1HpUVlR W+JkT8HoUVsQZ2RPfnATT2JwE09jcBdPfHATT09wE08rehhPfXoYT3F6FE9nUVBRUVBZUVJQWFBH R1BQUEJBWBDoUfznrtddrdddUFnoUW/iehxPEVlRalDqVFFQT1FmUE9RylBPUVTieiJP7lFRUHBR ylBPUVBQcFL74k+rfehRBuJPqk/oWFHiT6lP6FJREENPqE+0T6dP60+lTxpPmXr7T+l96FHK4k/o T+hUUeJP8HroUvsQX0/bTwJPK3q0TyhPPE8+cOhUUeJPPHHoVFEQW08zevtPCnoKTwhw6FL74k8e cOhRBuJPF0/oUcrmTxV6+08UeuhRUeZPEE/ZT2N96FRR4k9icehUUeZPYU8iT35P6FHK4k98T+hU UeJPeU/oWFHiT3hP6FhR5k93TzxPcnHoVFEQFU8FXVldWWfAjFfA+FfA9lfALlfAEVfAa1fAZlfA ZVfAYFfAf1fAe1fAdVfATVdEWEJYQFheWFxYWlhYWFZYVFhSWFBYROivsBB7UFBRUERWQFBQUVBW VFBQUVBUQFBQUVBAUlBQUVBSUFBQUVBQUlFYUlAaUOBDUxtSGwMSURvgkDNQGzJw4KYDc+hRWgEK 4FVzElHgQhtQGwQSSOBoexvoV68C4Gd7G+BXAAsI4VFR3gngaHvgUtjoUVAECOhRSeFRUd7VS+BC EwjpUFFRSdXdS+lQUVGv1d0JCVBGJm9Ib0JuQWkWFG5BaRYUbkFpFhRuQWkWFG5BaRYwFG5BaRYw FHt7e3t7e3t7e3t7SHt7e3t7e3t7e3t7e3t7GwAp6VBPUQjjV09tV3t7GwMp6VDAUQjjV8BtV3t7 SE3gxhsDCOD6TQngYhsDCOCvTQkb4MMDcAwI6VH+UfwVFOlR/VH8FRQJCOlTfFH+FQII6VH+U3wU CQkb6FHKA3AMCOlQb1H+FRTpUf5R/hUUCQjpWIZQbxUCCOlQb1iGFAkJG+hUUQNwDAjpUHNR/hUU 6VBwUf4VFAkI6UZwUHMVAgjpUHNGcBQJCRvoVFEDcAwI6VBOUf0VFOlQelH9FRQJCOlHsFBOFQII 6VBOR7AUCQkb6FRRA3AMCOHqcxUU4XNzFRQJCOlGcFDqFQII6VDqRnAUCQkb4GwDcAwI4U9PFRTh cU8VFAkI6VFSUE8VAgjpUE9RUhQJCRvgFgNwDAjhT08VFOF9TxUUCQjpUX5QTxUCCOlQT1F+FAkJ G+hTUQNwDAjhT08VFOFPTxUUCQjpXXBQTxUCCOlQT11wFAkJe3t7e3t7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7e3t7e3t7e3t7e3s1Ent7FTkDElEbAAjhWFASCRMMCOFYUBIJRkAgbuBCEwjpXUlu9Uvq UIJTu1BbewngWnMS4FtzElBvb0h7QGxRf1Zc4FZzEuBXcxLgQhMI6WtxSC5L6lRQUfhQW3sJ4Fxz EuBdcxLgQhMI6X0RfRFL6lRQVFBQW3sJ4F5zEuBfcxLgQhMI6Ugua3FL6lH4VFBQW3sJ4EBzEuBB cxJQe3t7e3t7e3t7e3skJCUlJSVQSBU5FBU5FBU5FBU5FCMjIyMjIyMjJSMjIyMjIyMkUBvgegMb 4G8BCgjhV1cV4BAwFAlQG+BgAxvgbwEKCOFbWxXor5AwFAlQG+B+AxvgbAEKCOFTUxXgEDAUCVAb 4H4DG+BsAQoI4VlZFeivkDAUCRMMCOYffFEfT1FneyQkCXsje3t7IyMke3t7e1BQEBAQb25tbGtq aWhnZWRjYmFgf359fHt6eXh3dnV0c3JxcE9OTUxLSklIR0ZFRENCQUBfXl1cW1pZWFdWVVRTUlFQ fBVzFjBw4HYw4FR2cxgYfXwVcxZzMXDgdjHgVHZzGBh9fBVzFjDgcDFw4BYw4FR2cxgYfXwVcxZz MeBwMHDgdjHgcDHgVHZzGBh9fBVzFjDgEDFw4DYw4FR2cxgYfXwVcxZzMeAQMHDgdjHgEDHgVHZz GBh9fFFAcGxQbH18cBVzcOCdFHNw6FEKAQhzcODdFHMJcOC9AQhzcOAdFHMJcOBUdgEIc3DgXRRz CXFxfXxwcBVIOBRw4FEwcBXgFiY42hUwFH18UeFbWhNzEzVafXxQ4VpbE3MTW318UOBHcyDhUUdu UeBHcyDhUkcVauFSUFhdfXwV4EpzFBXgSXMUfXxwFeBTdRUxNOAAAQgVFEtxcQl9fOBREzNzMuBQ cxLgX3t9fHAV4FATMBR9fFHgVhPgVxM1Wn18cDngEDHgUNtw4XyQ2tzoQFAyMHtcNHM0MQwI4FMx CX18FeBBe+BHcxTgRyq0SH18FeBBe+BHcxR9fOBCEwjXFeBBe+BHcxTgRyq0S1PaFUg5cOBHcxTa 2tdw4PABCOBBe+BHcxTgRyq0S3HgRyq0CQlIfXx9fOBSdRYw2hbgEDHcGH18UUh/fXxw4FN1FeBJ cxQV4EpzFBU1cxVw4FN1MDpw4FlzEnM42jowMXDgStrgUAIpceJKShDpr7BQShVw2gQIc3Hgb0tz CTEUTOFEUNoCKeNJEHBJFXDaBAhzceBvS3MJMRR9fOFAQRNzE1t9fOFeXxNzE1t9fOFcXRNzE1t9 fOFcXRNzEzVbfXzhXl8TcxM1W3184UBBE3MTNVt9fBsCCBUUS3FxCX18UXDgU3VzGeAQMOBwM3Dg UAIIc+BSdWhz4FJ1NWhQ2jNoS3FxcXFxCVF9fBvgNAEIFTngWRMw2kBqS3FxcQl9fFHgVXVAc3Da pVDgUTBzvbx9fFHgVXVAc3DapVDgUTFzvbx9fFHgVnVApVC9vH18cOBRMFFAcGxQbH18cOBRMVFA cGxQbH184Ht74Hp6fXxQ4FcT4FYTW318buB6en18ZX18JuhSZnMgQHDoUmYVcOBQAAjgUTEJan9I fXxxcVw0czTb6BBQMn18ceDQAQhcNHM02+hwUDJL4lAQf3sJ4FIwfXxx4JABCFw0czTb6EUFMkvi UNB/ewngUjB9fFw0czTb6BBQMjBzcX185FBRUFBQReBYduBYduBYduBYdl9ARkMVOGrgUUZ9fORQ UVBQUEXgWHbgWHbgWHbgWHZfQEZDFTg1auBRRn18GwNzGwEKCHAV2jAUS3FxCX18GwQIcBXaMBRL cXEJfXwbA3MbAQoIaEtxcQl9fBsECGhLcXEJfXzgQxMIU0tSCX184EMTCFJLUwl9fBsE4EITDAoI aEtxcQl9fOBCEwwIXOBUdeBUdVZcNHM0MTToV1gBCOBUdeBUdVFwFuBAMBhwFuBAMBgJWnFxS3Fx CX184EITDAhc4FR14FR1Vlw0czQxNOhXWAEI4FR14FR1UXAW6K+gMBhwFuivoDAYCVpxcUtxcQl9 fBsDcxsBCgjgantLcXEJfXwbA3MbAQoI4Gt7S3FxCX18GwNzGwEK4EITDAoIaEtxcQl9fFzaUxsE 4FR2UhsECtraWuBCEwwKCGhLcXEJfXwWcxYw2toWc3AW2jDaMeiv0DJzcEBz2ulS9VL12iAVMHDg UAAI4FEx6K/q20vgFtwJ4EAwOFFqfVBQVepQSVXqUElV9lBKVHZQSFBQr7dQUK+4UFCvt645r75V 6lBJrj+vslKyUFBQ5VBQUOVQUFBQUFBQUFDsUO9Q3FDjUPZQ9lDhUEBRVFA0UClQ21DbUJFQulDa UPJQwVHkUCNQKlD0UPJQ61HtUiBQClDQUEdQIFCTUGBRU6+AUPxQLVFdUFZQQlCZUJ1QBlDBr99R Q1BbUElQE1AiUOlTmFOHr75RFlE+UFJQS1AUUAJQ5lO+UIhRVFJtVUhVI699UFVQWVCWUJ1SHK+3 UEFQRVBnUBlQHlAMUPZQ91DlUJVQi1F4VROvj1BxUBBQA1AgUClQ3lDzUJpR31I1UiVS9FOYVQWv yq+Hr75QVVBYUHZQFlA5UCBQI1AnUMpQkVC/UVpRQ1GRUbVTSFTMrqKuqa/0UFBQd1BkUBFQFVAl UNBQlFCbUIlQtVCoUQVRNlJ7UgRTIFRVVDevRq/kUFJQTVBiUBpQGlAdUAVQMFAsUC9Q3FDNUOFS 81PcrpSup1BRUFNQU1B9UGdQZ1BqUAZQClD0UJ1QilFBUUlRdVF3URhRA1E5UfBRq1JXUmlS0VL0 UqdTVVN4U3hTZlPzU+VTjVOPU6FUGFQoVLZWW694rxuvOK8or8+v76+xUEJQT1B4UBxQClAMUA5Q MVAgUCdQ0VDTUNhQ4VDMUMxQzVDPUPVQ5lDoUOlQ6lCDUI9QsVCiUKdRXlFiUWtRbFE2UTxRKFH+ UeVR51GfUYJSDVIxUvJSnVNzUwpT81P0VFBUFFQAVCNUgq5Qrmiu3K7hrp6vXq/ir5evvK+tUFVQ T1BxUHVQdlB9UAhQNVDRUNVQwVDJUPVQ+1D/UOBQ4FDqUItQjFC5UKhRWVFZUUBRRFFHUXRReVF9 UX9RZlEAUQFRClE3USRRKVHSUd5RwFHJUcxR4FHjUedR7lGVUYpRuFGgUaJRq1JQUlBSW1JfUk9S clJ8Un1SflIeUjdS11LAUvxS5VLsUuxSgFKEUohSi1K1UqFSqVNBU0RTRFNyU3ZTGFMaUwxTP1Mo UylTLlP7U+VTm1OwVFRUVVRfVHhUfFTUVPVU/1SfVLtUqVVbVd5Vw1XIVbVVtVZQVkBWbVYAVjhW xVboVolXU1cBVzZXLlcvV9JX5lhQWHNY/FDiUO9Q4VD/UFBQUFBQUFBQUFBQUgxQ8VCDUe5QjlH2 U0RS+1EAUvdRxlFeU0hQO1PLUYFVG1DZUmxS4FEdUkZTo1EmUSZQRVP5UaRQpFDmUlRSiFF7VPdR 8FDsUe1S3FI7UihUX1EHVPlUrVEkVIJUU1K0UPZSvlBQUFBWRFT3UFBSJlBQUT1RblBQUjdQPVDO UkRQm1L0UNVQIVCSUM5WWVLAUOlQ31B2UhhQZVEZUMFQyVK/ULtQ3lBBUW9QOlApUK1R81UkUvFR KlO4UlxQBlGtUo9Ra1UkUDZWQFDRUeNSHlObUbRQnVLsUWJRG1E4UmlRMlCtULZR8lG2UgVQHVLT UPNUN1WEUY1Re1EeVThQIFBQVLBTGVM2UkNS61BQUFBQUFBQUFBQUFBQUFBQ/1DkUFNQnVAcU5hQ DFHCUCJQnVJ7UBlSP1DNU+1RuVDkUSxUN1M4UMlSKFJUUdNS0VL8UONTGFRbUBJQ5FPkUO5R+FOG UXtQ/1QoUT5Rw68VrQ1QpVb2VP5T4VVmVEyvmq6MUfVRgK/qUqFQZ6+aUwWuN1HMVElQBVAsULVQ IlA9UFtQ+1F7UMxQi1H2UFhRe1B1UAZQ3lD1UEVQQFFZUJtQFlBHUBxQDlGiUOhQ01BBUWZReFAe UnJQO1IRV3BWRFBQVlBRUFBQUFBSaVBQUmlQUFJpUCNSh1FbVCNQD1QjUDlXTVCXVQZQ8VHXUVRS +lD9Uvqvw1NNULxU/FDoUmlQYVL6UA9SaVAmUmmvyFQjUMFUI1F/VCNQKFQjUCBUI1ANVCNQ3lQj UPtUI1CoVCNQyVQjUNpSaVAlUmlQYVT8UOhU/FDoVPxQ6FQjUVRYT1A/VQavh1UGUAlVl1DqVZdQ C1UGUAxUs1ANVmlQl1WXUAZSaVAlVFBQFFUGUAtUI1ACVvpQClWXUDRWaVDrVQZQCFZpUO1Vl1Aw VQZQwFSzUK9Vl1CWVQZQrlfdUVBVBq/vVQZQv1SzUGJSaVBdUmlQ/lJpr9hTkVDAVCOvLlL6UXpU I1AKVCNQFFRQUCNUI1A8VCNQOlJpUA1UI1BlVCNQFFGXUG1Rl69YVFBQFlGXUGZW+lATVCNQFFQj UDRUI6+7VCNQOVL6UBRUUFAeUmlQI1QjUNBUUFDyVZdQz1RQr61UUFBQVFBQeFL8UDtSRFDsUvyv BFT8UPRVBq+HVQavh1WXUOxVBlAMVZdQNFZpUOtVl1CWVCNQClQjUApUI1AKVCNQClQjUApUI1AK VFBQI1QjUDpUI1A6VCNQOlQjUDpSaVAtUmlQLVJpUC1SaVAtVCNQFFQjUDRUI1A0VCNQNFQjUDRU I1A0VCNQ0FQjUNBUI1DQVCNQ0FQjUOpTY1FBVCNQylQjUBBUI1BuUp1QPVQcUN5Us1AaVbVQA1W1 UANYUFFIUvpRClL6UL1YUK/9VmlQ/lQ0UCxUI1AbVMxQXFKmUPdSvFDfV01QB1SzUMlUs1D8UvpQ JlT8UOhUI1B+VCNQ8VQjUANYUFF2VQavh1UGr4dWaVDrWFBQ9FfdUNFUI6+sWFBQUFL6UIhS+lCG UZdRWFGXUVBUNFDQVFBQUFUGUL9UI1D0UvpQMVL6UHFUI1BbUmlQ6VGXr6FS+q+IWFBQ2FUGr4dV BlAMVQavh1UGUAxVBlAMUmlQJVJpUCVSaVAlUmlQJVZpUOtWaVDrVmlQ61WXUJZVl1CWVZdQllJp UC1S+lCdUvpQkFL6URhS+lAdUvpRWFUGUMBUUFAeVLNQdlRQUHhSRFDsVZdQC1QjUDRVBlC/VFBQ UFUGUAhUI6+7VPxRVVL6UUdS+lDIUvpQ+Vb8UCtW/FD7VvxQ+VQ7UOVUI1ABUFBQSFBQULBbW1hQ U1NTVFZWWldSVFRUVlNUU1NWVlZWVlZWVlZWU1NWVlZWW1dXWFhXV1lYU1ZXVllYWVdZWFdXV1db V1dXU1NTVVZUVldWVlZTVlZTU1ZTWVZWVlZUVlNWVVdWVVZUU1RWV1dYV1hZV1ZWVlZWVlZWVlZW U1NTU1ZWVlZWVlZWVlZWVFZWVlRWV1hYW1RUW1lWVlZUVFpXV1RWVlZWW1dXWVtaVltUU1JTVlVX V1RUVlNSVFpXV1dXV1NTU1NZWVlXV1dTU1RUVFNXVldWU1hWV1VXVlZUVFNZWVlWVlxeWVBTU1NU V1dbWFJUVFVXU1RTU1dXV1dXV1dXV1dTU1dXV1dcWFhZWVhXWVlUVlhXWVlZWFlZWFdZWFtYWFdT U1NWV1RXWFZXV1NXV1NTV1NbV1dXV1RWU1dWWFZWV1RTVFdYWFlYWVlZV1dXV1dXVldXV1dTU1NT V1dXV1dXV1dXV1dVV1dXVFZXWVlcVFRcWVdXV1RUW1dXVFdXV1dcWFhZXFtXXFRUU1JXVlhYVFRX U1NUXlhYWFhYVFRUVFlZWVlZWVNUU1RUVFhWV1dTWVdYVlhXV1VUVFpaWldXXV5aUFRUVFVXV1xZ UlRUVVhUVFRUV1dXV1dXV1dXV1RUWFhYV11ZWVlZWVhaWVRXWVdaWVpZWllZWFlZXVlZWFRUVFZX VFdYV1dXVFdXU1NYU1tXV1dXVFdUV1ZYVlZXVFNUWFlZWVlZWllXV1dXV1dXV1dXV1NTU1NXV1dX V1dXV1dXV1VXV1dUV1haWl1UVF1aV1dXVVVcWFhUWFdXV11ZWVpdXFddVFRTUldWWVhUVFdUU1Re WVlZWVlUVFRUWlpaWVlZU1RTVFRVWVdYV1NZV1lWWVdYVVRUW1tbV1dfX1tQVFRUVVhYXVpTVVVW WVRVVFRYWFhYWFhYWFhYVFRZWVlYX1paW1taWVxbVFhaWF1bXFpcW1pZW1pfWlpZVFRUV1hVWFhY WFhUWFhTU1hTXVhYWFhVWFRYWFlYWFdVVFVZWlpbWltcW1hYWFhYWFhYWFhYU1NTU1hYWFhYWFhY WFhYVlhYWFVYWVtbX1VVX1xYWFlWVV1ZWVVZWFhYX1paXF9eWF9VVFNSWFhaWVVVWFRTVF5aWlpa WlRUVFRcXFxbW1tTVVRVVVVaWFlXVFtYWlhaWFlVVVVdXV1YWEBBXFBUVFRWWVleW1NVVVZZVFVU VFlZWVlZWVlZWVlUVFlZWVlAW1tcXFtaXFxUWFtZXlxcW1xcW1pcW19bW1pUVFRYWVVZWVhZWVRZ WVRUWFReWVlZWVVYVFlYWVhYV1VUVVlbW1xbXFxcWVlZWVlZWFlZWVlUVFRUWVlZWVlZWVlZWVlW WVlZVllaXFxAVVVAXFlZWFZWXlpaVVlZWVlAW1tcQF9ZQFVUU1JZWFtaVVVZVFRUQVtbW1tbVFRU VFxcXFxcXFRVVFVVVVtYWldUXFlbWFtZWVVVVV1dXVlZQUFdUFVVVVZZWV9bU1ZWV1pVVlVVWVlZ WVlZWVlZWVVVWlpaWUFbW1xcW1pdXFVZW1leXF1bXVxbWlxbQVtbWlVVVVhZVllZWVlZVVhZVFRZ VF5ZWVlZVllVWVhcWVlYVlRWWltbXFtcXVxZWVlZWVlZWVlZWVRUVFRZWVlZWVlZWVlZWVdZWVlW WVpdXUFWVkFdWVlbVlZfWlpWWllZWUFbW11BQFlBVlRTU1lZW1pWVllVVFRBW1tbW1tVVVVVXV1d XFxcVFVWVlZWW1laWFRcWVtZW1laVlZVXl5eWVlDRF5QVVVVV1tbQV1UVlZXW1VWVVVbW1tbW1tb W1tbVVVbW1tbRF1dXl5dXF9eVVpdW0BeX11fXl1cXl1CXV1cVVVVWVtWW1taW1tVW1tVVFpVQVtb W1tWWlVbWl5aWlpWVVZbXV1eXV5fXltbW1tbW1pbW1tbVVVVVVtbW1tbW1tbW1tbWFtbW1daXF5e Q1ZWQ19aW1pXV0FcXFZbW1tbQ11dX0NCW0NWVlRUWlpdXFZWW1VUVkRdXV1dXVVVVVVfX19eXl5V V1ZWVlZdWlxaVV5bXVpdW1tWVlZAQEBbW0VFQFBWVlZXXFxDXlRXV1hcVldWVlxcXFxcXFxcXFxW VlxcXFxFXl5fX15dQF9VW15cQV9AXkBfXl1fXkVeXl1WVlZaXFdcXFtcXFZcXFVVW1VBXFxcXFdb VVxbXltbWldVV1xeXl9eX0BfXFxcXFxcW1xcXFxVVVVVXFxcXFxcXFxcXFxYXFxcV1tdX19FV1dF QFxcW1hYQ11dV1xbXFxFXl5ARURcRVdXVFRcW15dV1dcVlVWRF5eXl5eVVVVVUBAQF9fX1VXV1dX V15bXVpVX1xeW15cXFdXV0JCQlxcSEhCUFdXV1ldXUVAVVhYWV5XWFdXXV1dXV1dXV1dXVdXXl5e XUhAQEFBQF9DQVZcQF1EQUNAQ0FAX0FASEFAX1dXV1tdWF1dXF1dV11dVlVcVkRdXV1cWFxXXVxA XFxbWFZYXkBAQUBBQ0FdXV1dXV1cXV1dXVZWVlZdXV1dXV1dXV1dXVpdXV1YXV9CQkhYWEhDXV1d WVlFX19YXl1dXUhAQENIR11IWFdVVV1cQF1YWF1XVVZHQEBAQEBWVlZWQ0NDQUFBVlhXWFhYQFxf W1ZBXUBcQF1eV1hYREREXV1LS0RQWFhYWl9fSEJVWVlbQFhZWFhfX19fX19fX19fWFhAQEBfS0JC RERCQUVEV15CX0ZERUJFREJBREJJQkJBWFhYXV9ZX19eX19YX19WVl5WRl9fX15ZXlhfXkNdXl1Z V1lAQkJEQkRFRF9fX19fX15fX19fWFhYWF9fX19fX19fX19fW19fX1pfQURES1lZS0VfX15aWkhB QVlAX19fS0JCRUtJX0tZWFVVX15CX1lZX1hWWEtCQkJCQldXV1dFRUVERERYWVhZWVlCXkFdV0Rf Ql5CX0BYWVpHR0dfX01ORlBYWFhaQEBKQ1ZaWltBWFpYWEBAQEBAQEBAQEBYWEFBQUBNQ0NFRUNC R0VXX0NASEVHQ0dFQ0JFQ0xDQ0JYWFheQFpAQF9AQFhAQFdWX1dIQEBAQFpfWEBfRl9fXlpYWkFD Q0VDRUdFQEBAQEBAX0BAQEBXV1dXQEBAQEBAQEBAQEBcQEBAWkBCRUVNWlpNR0BAQFtbSkJCWkFA QEBNQ0NHTUtATVpaV1VAX0NAWlpAWFZaTkNDQ0NDV1dXV0dHR0VFRVdZWlpaWkNfQl5YRUBDX0NA QVhaWkhISEBAcHFIUFlZWVtCQkxFVltbXENZW1lZQkJCQkJCQkJCQllZQ0NDQnFFRUdHRURJR1hA RUJLR0lFSUdFREdFcEVFRFlZWV9CW0JCQEJCWUJCV1dAV0tCQUJCW0BZQkBHQEBAW1hbQ0VFR0VH SUdCQkJCQkJAQkJCQllZWVlCQUFBQUFCQkJCQl1CQkJbQURISHBbW3BJQkJBXFxMRERbQ0FCQnBF RUlwTkJwW1pXVkJARUFbW0JZV1pxRUVFRUVYWFhYSUlJR0dHWVpbW1taRUBEQFhHQkVARUJDWltb S0tLQkJxcklQWVlZXEJCTUZWW1tdQ1lbWVlCQkJCQkJCQkJCWVlDQ0NCckZGSEhGREpIWEFGQkxI SkZKSEZESEZwRkZEWVlZX0JbQkJBQkJZQkJWV0FWS0JCQkJbQVlCQUhBQUFbWVtDRkZIRkhKSEJC QkJCQkFCQkJCWFhYWEJCQkJCQkJCQkJCXUJCQltCREhIcVtbcUpCQkJcXE1ERFtDQkJCcUZGSnFP QnFbWldWQkFGQltbQllXWnFGRkZGRlhYWFhKSkpISEhYWltbW1tGQURBWUhCRkFGQkNaW1tMTExC QnV1TFBaWlpdRUVxSVdcXF5GWlxaWkVFRUVFRUVFRUVaWkZGRkV1SUlLS0lHTUtaQ0lFTktNSU1L SUdLSXNJSUdaWlpBRVxFRUNFRVpFRVhYQ1hORUVFRVxDWkVDSkNDQlxaXEZJSUtJS01LRUVFRUVF Q0VFRUVaWlpaRUVFRUVFRUVFRUVfRUVFXURHS0t1XFx1TURFRF5ecUdHXEZERUV1SUlNdXNFdVxc V1hEQ0lEXFxFWlhbdUlJSUlJWlpaWk1NTUtLS1pdWlxcXUlDR0JaS0VJQ0lFRlxcXE9PT0RFenxw UFxcXF9HR3VMWF5eQElcXlxcR0dHR0dHR0dHR1xcSUlJR3pMTE5OTEpxTltFTEdzTnFMcU5MSk5M eExMSlxcXERHXkdHRUdHXEdHWVlFWXNHR0dHXkVcR0VPRUVDXlteSUxMTkxOcU5HR0dHR0dFR0dH R1xcXFxHR0dHR0dHR0dHR0FHR0deR0pPT3peXnpxR0dHQF91SkpeSUdHR3pMTHF6eEd6Xl1ZWUdF TEdeXkdcWV18TExMTExbW1tbcXFxTk5OXF5dXl5eTEVKQ1tOR0xFTEdJXV5ec3NzR0d+f3NQXV1d QEpKeU9ZX19CS11fXV1KSkpKSkpKSkpKXV1LS0tKf09PcXFPTHRxXUdPSnZxdE90cU9McU98T09M XV1dRkpfSkpHSkpdSkpaWkdadkpKSklfR11KR3JGR0ZfXF9LT09xT3F0cUpKSkpKSkdKSkpKXV1d XUpKSkpKSkpKSkpKQkpKSl9JTHJyfl9ffnRJSklBQXlMTF9LSkpKfk9PdH57Sn5fX1pZSUdPSV9f Sl1aX39PT09PT11dXV10dHRxcXFdX15fX0BPR0xGXHFKT0dPSktfX0B2dnZJSmJidlBeXl5CTEx8 cVpBQUNNXkFeXkxMTExMTExMTExeXk1NTUxicXF0dHFPd3ReSXFMenR3cXd0cU90cWBxcU9eXl5H TEFMTElMTF5MTFpbSVt6TExMS0FJXkxJdEhJR0FdQU1xcXRxdHd0TExMTExMSUxMTExeXl5eTExM TExMTExMTExETExMQUtPdXViQUFid0tMS0NCfE9PQU1MTExicXF3Yn9MYkFfWltLSXFMQUFMXltA YnFxcXFxXl5eXnd3d3R0dF5AQUFBQXFJT0dddExxSXFMTUFBX3p6ekxMZmZ5UF9fX0NOTmB0WkJC RXBfQl9fTk5OTk5OTk5OTl9fcHBwTmZ0dHd3dHF6d19LdE59d3p0end0cXd0ZHR0cV9fX0lOQk5O S05OX05OW1xLXHxOTk5OQktfTkt3SktJQl5CcHR0d3R3endOTk5OTk5LTk5OTl9fX19OTk5OTk5O Tk5OTkZOTk5CTXF4eGZCQmZ6Tk5NRERgcXFCcE5OTmZ0dHpmY05mQkJcW05LdE1CQk5fXEJldHR0 dHRfX19fenp6d3d3X0JBQkJCdEtxSV53TnRLdE5wQkJCfX19Tk5qa3xQQEBARXBwZHdbQ0NHckBD QEBwcHBwcHBwcHBwQEBycnJwa3d3enp3c316QE13cGB6fXd9endzendod3dzQEBAS3BDcHBNcHBA cHBdXU1df3BwcHBDTUBwTXlMTUtDX0Nyd3d6d3p9enBwcHBwcE1wcHBwQEBAQHBwcHBwcHBwcHBw R3BwcERPc3t7akNDan1wcE9FRWRzc0NycHBwand3fWpncGpDQlxccE13cENDcEBdQWh3d3d3d0BA QEB9fX16enpAQ0JDQ0R3TXNLX3pwd013cHJDQ0RgYGBwcBMUYlBDQ0NIdXVsfV1GRkp3Q0ZDQ3V1 dXV1dXV1dXVDQ3d3d3UTfX1gYH15ZGBDcn11aGBkfWRgfXlgfRB9fXlDQ0NPdUZ1dXJ1dUN1dV9f cl9ndXV1dUZyQ3VyYXJyT0ZBRnd9fWB9YGRgdXV1dXV1cnV1dXVDQ0NDdXV1dXV1dXV1dXVLdXV1 SHR5YWEURkYTZHV1dUlIbHl5Rnd1dXUTfX1kE291E0ZGXV11cn11RkZ1Q19GE319fX19Q0NDQ2Rk ZGBgYENGREZGRn1yeU9BYHV9cn11d0ZGRmhoaHV1GxxoUEVFRUt6ehNiXklJTXxFSUVFenp6enp6 enp6ekVFfHx8ehtiYmZmYn5qZkV2YnptZmpiamZifmZiGGJifkVFRXN6SXp6dnp6RXp6QUF2QW56 enp6SXZFenZmdnZzSUNJfGJiZmJmamZ6enp6enp2enp6ekVFRUV6enp6enp6enp6ek56enpKeH5n ZxxJSRtqeXp5TEsTfn5JfHl6ehtiYmobF3obSUhAX3l2YnlJSXpFQUgZYmJiYmJFRUVFampqZmZm RUlISUlJYnZ+c0NmemJ2Ynp8SElKb29veXoDBG5QR0dHTX5+GmdATExwYEdMR0d+fn5+fn5+fn5+ R0dgYGB+BGdnbGxnYxFsR3pnfhRsEWcRbGdjbGcAZ2djR0dHd35Mfn56fn5Hfn5CQnpCFX5+fn5M ekd+emx6enhMRkxgZ2dsZ2wRbH5+fn5+fnp+fn5+R0dHR35+fn5+fn5+fn5+cX5+fnB9Y25uBExM AxF+fn5PThpjY0xgfn5+A2dnEQMefgNMSkBAfnpnfUxMfkdCSgNnZ2dnZ0dHR0cRERFsbGxHS0pM TExnemN4Rmx+Z3pnfmBLTE4VFRV+fgwNFVBKSkpxY2MCbUJPT3RmSk9KSmNjY2NjY2NjY2NKSmZm ZmMMbW0SEm1oGBJKfm1jHBIYbRgSbWgSbQhtbWhKSkp7Y09jY35jY0pjY0REfkQdY2NjY09+SmN+ E35+e09IT2ZtbRJtEhgSY2NjY2NjfmNjY2NKSkpKY2NjY2NjY2NjY2N1Y2NjdGFoFRUNT08MGGNj YnJyAmhoT2ZiY2MMbW0YDAdjDE9MQ0Jjfm1iT09jSkRMDW1tbW1tSkpKShgYGBISEkpOTU9PT21+ aHtIEmNtfm1jZk5PTx0dHWNjNDUbUExMTHRoaAkTQ3Fxd2pMcUxMaGhoaGhoaGhoaExMampqaDQT ExgYE20eGExiE2gDGB4THhgTbRgTMBMTbUxMTH9ocWhoYmhoTGhoRkZiRgJoaGhocWJMaGIZYmJ/ cUpxahMTGBMYHhhoaGhoaGhiaGhoaExMTExoaGhoaGhoaGhoaHhoaGhzZm0bGzVxcTQeZ2hndXUJ bW1xamdoaDQTEx40Dmg0cXBFRGdiE2ZxcWhMRnA0ExMTExNMTExMHh4eGBgYTHFwcXFxE2Jtf0oY aBNiE2hqT3FzAwMDZ2hQUlFQUFBVUFVQUFNQV1Aa4VJR61F+UFZQV1Jn4lBVVOhRfuRTUFpXVOhR fuVRUElYVlXrUX5QUlBTURPjWQvuSHtApmytbB5ApGwdrWxQb2ytbECsbK1sYWBxQXFBdXFBcVFQ VFCscFOQrBBVUKtQcFSQUFBSUCNQUFI+VepQVVBZUA8QcU9RT1JPU09UVGhRB1RSVlJZU1RTWVFS WBVWUFNSUFZaVehRoxBGUFBWUyFZFVIhf1YfVg9WU1ZJWmrYSHseQKQNHbSttEJpf71Qb29sf0C9 UUJpQUJpV1dhYFENDUtSY1tSZ2NXtT9vixSEs3uce1EiU0xRfK7rrK2u3p2dUK+vUUVT41M+VepQ dlBaQVBRV1BaUQxQUFBF41FRVlDoURvnGHdQUVJSUHlQe1F7UFBSUEWvt1QJVYNQS1BPUKIQ8VhG SEZSWElISVJRUkVQWVRTRFBZVVZBUFlYV0BQWVtXQEtaXFdASF1fV0BHXkJWQUdeQ1NER15GUkVH XklSRUhdSlJFS1pMU0RLWk1TREhdTlZBSF1PVkFLWlZXUkRFcUBaS0twUFlEUFBZXUhIcEdeREdH XktIR15dWllQWEBFUk9EU1NQQFdPQVaFXl5dXVpaWVBLSEhHR1BaQLJS5HAm6VF9UEh7QKa9UG9s QGxAbG9sQGxAbECtbK1sQWl/bK1sUUFHadd+ey1AlNd+SHstQJRRQUJpaUJpaV9fX19fX19fX19f X19fX19hYFENDUdDc2VjQ3FlcUNjU3FDY1NjRXNTcUVxU3NDcVNDcUNxNwf5lxquv1F/B8YHUWsH xwf9mxtRRq6cB8YGrpYHJVFqG66VSVH6xVE7xVH9rgNR/a4Dxa7Fxa4GUfquBlJvUTtQUFNQOa9s VMVWTFB4UGBQZ1EcEDV0VnZEckx2T2JWaVtmRBZWH0cfSB9JH0oGVgZEKVjZWEB/RG9EH0QPRDRW pnlWWmdRQnp5WFhaV1B4eENFTE1NTmFidndERHd3cnhDRHh4Q015QmJYYXp0ZW9wcEh3XW9+fkNT d+hRY+R4eEhTROhRY+NDQ1NJ6FFQ40hKaVToUVAQWVNJaEgaX0lRSehRbxBZekxMekVFdEJM6FLd EFl6F0PNQnhTGlToUtcQXVdQUEJ0V1dCYhd0eHfoUZcQQHh0QlV4aHhDQHh4aFrZBUh7e0BsUX97 bHtAkFFQb397pGxQQK1BaX9BQml/QKS0e0C0UK21QUJpf0Fpf0CtDbRRHkCkHb0eQKYdvUJpf71B Qml/vUFCaX+9QUJpf71QQUJpaUFCaWlV1357LUCUV2xebGxYbF5sbFdAXmxsWGxebGxVbGFgUCEN UQ1VdnZ3Z0ZGR0N2d3Z2ZWR0Y2JHZ2NXRkZHV3Z2d1NGRkVEVlZzcndXc0NDdlZWRURGQ1NGZmVk dlGWwpJZ5lk7AiQmZRoeUVLvVnJANEPYzEH9Xh4bOZrH147BWkJ0M4w1HdQYG/E/1+gEXU68+1so xk1SeWN7a/AEzqNRHgty48RZCTpKrlkDlCgitDpR+1RxUbBTbSQVHD6uqq29VfsmHiJQVVCXr5pW glWDUFNQQ1BxUGFQb1AlEEhQUWpQf1NsT3iJZU9/U1BHT0GJTk9aUlHoUsziWlBS6FFq5FFRaWJT 6FFqEElQUERUcnBi9Wlwe0oRXXBL9URwVEkQMv1Iex5ApB2tpr0eQKYdraa9QUJpf71BQml/vVBv pGxAva29f2x/va29QUJpYWB7VVFjUVFkblNjYkZFRFJWc3J2Z0RGY2JmZmVkdnNyVlZRZG5TY2JG RURSVnNydmdERmNiZmZlZHZzclZWUU5U6/SrGq9QdRgIOBLdwTH5JtPaym9lbzdrFGdqMm5StHUY CDgS3cEx+SbT2spvZW82bBRnajJuZlZZqadUfXn61gB239ojr1AnxS4EFjGIHRMYDZqsiHn61gB2 39ojr1AnxC4DFzGHHhQYDZpQUFNQ8a+NVWZVg1B0UGBQa1FUENUwcCBw0HDLXMZzVThzUXN1UWNk ZEl1dUtbW2FaWnZwS0tySXV1SmNbW2JQYWFzc3JLdUtNdRRbYURbW2F1dkhkZHJadkRaWnZQS3BE c1VNYVpkdkhUZ0l1RmNbf192SFpkW2N1SVhNfHJzYUtQcE5Vak1NU3xwQ1FqcFNbc1tyNk7pTcBh 6FG341ZGHnnoUQ8QXH8eXyFnHlZJbD0jSHseQKQdvaS9pL1ApKSttFBvb71vvUJpf0JHaUFpQUJH aVFBQmlpQmlpQUdpQUJHaddefnstQJRY135Ie1gtQJRRQJnXQF6UV0BebNdAXpTXQF6U10BYlFiU 10BelGFgUA1RIQ11VlZzcnZlZGZnZmd2d3ZlZGZmY2JGRURWV0ZHZmdHVldGR1d2UWZnZmVkdnNy VkVEQ3Z3VldWRURGY2JTqC3iPJikCwoV12RbXg78Nd39xInTKRkSzhIlETjYNq7Fw298AWoWO67r ONhqAcsgx982GbviJOIYZm0jd2gQBP0y9CUzkz29yAkoAdvVAyU9B1MqGx9maGsBIR4PrKalkhBs BD8izVBRUVRT41JCVepQVVAhEGwQUPRVUiBVUVVUUVRRVXhSUVEUVFNEVFRTVVFSVFRTUFRRV1JU wVNRwFJ4UFWEU1N4UlBT5ldQSVYL1Eh7HkC0HUC0UG97bFBArWx7QLRAvVBBQmlpUUFCR2nXXn57 VS1AlHtBaWlRQUJpYWBRDSFRQ2djV1NRVFxknmU5U+NRQqWlrr5QUVD9rgFTHlWDUF5QZhBfzV79 XlJXQFBCXB5SWKhX6FGl41JeqFDoUaTlUklfPSpIex5ApB2kvUCkvUC9UG9vYWBRDVFSQWRCZ2Zn Y1ZQUkVAQ1EazS/SBu3dJa6rJiOuAVEIUTuiUfGc2IgtrmquGo2u5q7OUFGvw64BUmRVg1BeUBYQ QTlaUcNe8FDwXlNeQFhCWKhX6FGl41JeqFDoUaQQXFweX1JPUn9SU1JKQOhRA+EYSHseQKYNHb2k vUCkrVBvb2FgUQ0NUUJBRFJXVldzZlBCZUBTUcbOL9IH7N0kUVYlI1WDrviuxqOuMJ3YiC5RllHl jlEaUTFQUVAQUzNShVWDUEhQJxABWllcXl9AQVdWW1FSSEZFRENXUFRTWEdCXVdXVlVIR0ZFQ0JB QF9dXFtEVFdTWFFaVlVbUFBAUERARHBEU0QtVlVQW8BWflXAAFBRUPNJndhIe0CmDaSttFBvbK0N bGl/bEJHaUJHaVFBQkdpQkdpQUJHaWFgQ2dGR3Z3Y1ZXZmdHVldGR1d2d1ZXd2ZndhB+zxhDUcFT RDfVfi8qbT8oah8aaCYkYtFU/d5oeeUUM8VkfN56XmXYBR/Y3RoF335JUFFQIlC9VGpU5lBbUG8Q cFhTWVJVLFMrUixvUFFQWCxWWitVUSwQUlHvUlFSSVwy6VIrUEh7HkCkDSEdpGytbLRQfw2krbRA bEBsYWB1QXFlcUFjQXFFcUFSUa4hUd/6Ud+uIb1RwvhR364h+K4+UFBRUGGuiFE4UJ1QWVAeEEF0 V2VXUldWWVNYVFVTUFY6V+hS0uJZUFPoUsoQQlJSURVQWlP/UhVR/1AdWj22SHtApqSttFBvrWxA vUBspr1BR2lRQmlQQJlhYFENY2djV1ZWV2dmZz97nnVy3zFBJ3ad4/HGWx9x6FBRUA9R6FL9Uj1Q U1BwEEBRK1BS/1PKVVH/UElUJhJIex5ApB20QKa0UH+9YWBDZ3FXD3ZSeHVR6OXlUFBRUCZQUFE+ UJ1QU1BJ5lEVUFpSFVHoUaTjVGq2SHtApL1Qb71hYGNnY1cme518nZ1QUFGvyK+4UxlVg1BTUH3m UlFQU1BaUhFbUWpQUVEsUFNRalBQUaNQVFE+URRQSHtArb2kvVBvbG9sYWBXUWNROFNEzay8SFW7 qkVQUlDBr7dU1lWQUEFQdFAgEEUHRCdX1ldTV0FRSEhdQWRJSF1BZHPor7jjXUFkcOivuBB/XUFk 2UDUcVJ2WylAJHFTb0hjcTVEOUk3c1VOcFZVRnBfXUJvUEl1S29ZSnYpBUh7HkCmHb0eQKQdvVBv vW+9YWBRDQ0Ne3t7e1AhDUNkQm5SY2JGRURXUldWc3JSZ0RHRmNiZ2ZCZWR2c3JWV1ZXVsE/2MLd BvixHgz0LvH1s/99bSg5BiwtKTMYLWkBbGNRsepR0LbSbaq8o76utt07UVOZ1xw5D9ZSVfTO3BoK L62IUFBRUX9QUFOGVZBQW1DYEE4bUi1RUglRUWlaGFEZWgRSCFpVWltb6lBRRFBQUVToUasQXlNa eFlVW3hQXFpaWVtb6FFQEFpQWVFRWQBQUVBQ6FIJ5V1ZUUBQR+pRGlF6UEh7e3tsUXsqQKFRSH8N e2xRf3sqQKFRSH97bFF/UG97bFBve2xQf73XVX57LUCUYWBRDVAhDXFDVlVnZnRnZmdjUVG9uMau oHLXUVcSeHQ5rp1UAyYX9Gb+EXhpqhBQUVAoUFBUL1WQUHFQ8OceXx5MOUpTXuivnBAdXkFkXHBe QWR3X3RKdUxpU2ZfaUIQTRJOCVI9WzhDNkowSzBMM00yTitSK1PaUtpTw0v1VuhTR09wUE1LQUBV U1ZMSlZUVE9dcERVcE/oUVDmcVBccKZzQOpRUFBBUZcQW1BJclpvSEpz2f5Iex5Aph29HkCkHaS9 QLZQb2ytbG+9QUdpR2lRQUJpYWBRDXt7UA1jblJnZmdmZ2ZlZHZzclZXd2ZmY2JGRkVEV1ZVVlZX cVcoTDP0ut5kG3JH3zg3ynHhSqvrLZs2OBCumNbTcVLAc9Phz+shZh4bY2w13d/OSpOxOOw0wtcE pzrYbPZQUFFQIK+3VCVVkFB6UMkQXn93UURwX0FkWXBeQWRG6K+c415BZFPor5wQR15BZGdHYncV UhZHVHJaSUhdU0VfURpQ6FEFEEF4XBpfcFpaeEVwTFVUcHhdUehRUBBcUEl7V291zU9/SVFI6lFQ UElRmedCb09KfNn+SHseQKYdraS9DUCkvR5ApB29UG+9b71CaX+9tECttEFCR2lCaWFgUQ17e3t7 UA1DZ0ZGY2JmZWR2c3JXZ0ZjYmZlZHZzclZXd2ZmY2JGRURWV0ZGRURQc3J2IOBE2T/Wk8IrXnxP SkjL99kzMctG4nyq++SPKSkGBa6JnZelUdBGytWQLDzdVMdUxz412t3RdOWWis8k/WljwA2Vro+P UFBSUA1QUFQHVepQWlBdUU0QbVVcUfdc913nXJZcpFxVVFwaXFJ/V29X0lXUXMtd/V3rXZtdWFFS WFBcVl1XWlVZUlhaVVtdV1BcXF1cUF3oUa8QRlNURFNTVFxcXVVaWupQXERQUFxTXVzoUVsQWVV4 VFRdV29SWOpRnlBSUZ3kWnhQXFfoUlDj0FhRWOhRieJZVFToUlQQWllVVVpZWVlZWlroUVAQWlBZ XFxZUD9QUVDoUgriX1lT6FJQEFtfUlFSSV5cQFBH2elRelBIe3t7bFEeQKQNHbR7KkCgDVFIf3ts UX97KkChUUh/e2xRf3tAbFF/eyqyUUh/QKQNtFBve2xQtrRArWxve2y9UEFp11V+e9dYLZTXVX5I e1gtQJRfX19fYWBRDSFQDSFxQ3FnUWNTY1dzU1NDUVI0H636dlNlxJOecZ4fFdCtjlEm41PBrAzw rtpSRlI0rcxQUFFQ3q+3VMRV9lB2UJLlFkcnR1JP6K+G40BBZFXor7AQaV5BZF1kXkFkSVliQNlD U3dHdU8WR8dLlkdVR0FGREV4UHVRQFtTQF5CQUZGcENCRENDQkdKXlEaUOhRQeNxXm9K6FFb4kIa QehRKBBcQ0VGb0RDVFdwcV1B6FGrEFlCU291SXdbb03oUtXjeCkFSHtApL0eQKQdvX+9UG+9b2yt bECtpK29QK20QUJp11V+ey1AlFBBQmlRQUJpaUJpQWNj116UYWBRDQ17e3tQDUNnVkVERkZjYmZm ZWR2c3JWV3dDcVdxU2ZmY2JGRURSVHNydnZlZN/oUhMjEAT+PMEmH91tzo1SnHOtgz5u0xX4iMSu rcYukjFR80J3WBLWFySOPSvEHBxbUr72rtt9fY6R+a6zySKYNFpQUlD7r7dU21WQUE1QelDFEEVq TBpMUkhwX0FkSXBfQWR3el1BZHDor7AQcFxBZEBMK0Epcyd613pVcVhlTRZQN1ApQNlH2XNXR0ZQ 6K+gEHVbQWRQdU5QeHBTpkcaRoFKcENVcXBaXUfNdW9WzUZKfE5vXUl76FLW4QVIex5ApB29HkCm HaSttFBvvW+9raSmvWlRQUJpe0CZYWBRDQ17e3t7UA1RZmZjYkZFRFdWc3JSZWRnblJjYkZHV3Z2 c3JWVlNERmNiZmZlZHZzclZRzBzHGveK8tyY5qMebOGXLcbuXfheOx0B9CYFyjEUyDrDOCieUwJv b7SRqeLJUVunjbzluz7r/kAnOi6nrbks+TeCONbxu1BRUKhQUFSTVfZQXVAHEH4kW9RbUktUCVU8 VTZbLlXeVVZYWV9WV1BeC1VRVV9dWVVWcFhXVFBcXW9PUFFQ7FGGUF5REVFiUEh7QKQNvVBvb2yt bGlRQUJpDUFCaWlBY2NhYA0NcWZnZlBncWdxV1ZTUlNReUgeDVF+6a11c1P4cr7inxzEgKtRv+L2 9oGu5q7TrshQU1DJr7ZU1FWQUElQdlBkUPLlcnBAQWRM6K+wEF5AQWRhcF9BZE5kXkFkdeivsONe QWR56K+wEE5eQWRZRUlJUllQSX1GY1N8SHh9PU9TDVBRUF1NcGLor5AQRllaZGJiRHNwV1V7cERd R29fd093UnfoUX/iSm9T6FEY42V/b0HoUWPncG9aSmYpBUh7HkCmHa2tvUCmvaUNvVBvvW+9Qml/ e71paWFgUSENDQ17e3t7e3tRdnZlZGdmY2JGRURWV0ZHRkVEUHNydmVkZkNERmNiZmVkdnNyVlZT REZGY2JnZmVkdnNyVlGeAgIw0IuRjijQCHZhrrm46br2zSk6LMspOgDWEd1rKB3DCxjVPNjtU3Z9 3QHVIcmfxjv8Y2duATyVrpy0+/G3UXwOI8c+DSUaL61QbSAS2jwtNtKaUFBSUNqvt1Q5VZBQTlB+ UPIQXmVWFlZS1n1RSFheQWRT6K+G419BZFLor4YQWV9BZHhwXUFkceivhhAWXUFkJUkkSil0Jn3a dFVLV3xBaVgYWDhY1lFWUVBYQltBZFh2T1hycFumURpQgUx6cENVVHBMXVHNT29fzVBJf3ZvRkpg KelRelBIex5Aph29HkCkHaSttFBvvW+9QK2kpr1pUUFCaXtAmWFgUQ0Ne3t7e3sNUA1DZ0ZGY2Jn ZmdWVnNyd3ZlZGdmY2JCRURXUldWc3J2Q0RGY2JmZmVkdnZzcl5S2vpBOhk4CdNuC90a1jrc8tua 5qAAD/LU9ciRtcM1G8Q6FilubCQzYVEAQSs4CtSnFGoKJYuo4ciuo6a/ua6+0jrtUqDa9DabOwTA GRAs8VBQUlAlUFBST1R2UFNQV1B5EFtQFVFWVRVUWlIVUehSDuJWFVXoUtjjWGojSHtApr2kvVBv vW+9YWBRZ2NXUWdjV1F4e5x6rtB7nXxTCZ2drPednVBQUlBhrohSSVR2UFNQXVA1EEh1W2VbUlta XVdYXFlTWlRTUBVSUVZaOlvrUtJQVFBXUsoQXlZWVRVUWlf/VhVVUhVR6FIO51X/VEleaiNIex5A pB2kpL1ArbRQb61sQL1Apr1vbK1sQUJHaVFCaVBAmWFgUQ1RZ2NXUWdjV1ZWV2dmZ1Fye5x7rtF7 nnVy3zFBJ3ZTCZ2drPed4/HGWx9x6FBQUVAgULJUa1STUFZQDRBaU1VWU1hS0FVRVehSyuRW31NR U+hSyuJSEFbqUQ5QUlEOEF1QOlE6cFRSSlhUFVFQ7FIyUFdQMlIrUEh7QKZsvR5AplBJf0odvb29 vUhKQL0NQL0NUUFCR2lhYENlUUVRUUUgU5usrlNSUtH4UcrjrpSukeNQUlAiUfFUalRWUFNQV1Bm EFpVVlFUV1lQUitR6FFAEFpWK1VQSllRSVgy6VIrUEh7HkC0QLZQfx29pL1RQUJpaUJpaWFgUXFl cUFxZXFUaqxoU5isaFOYUw74rcv4UFFQIFCyVGtUk1BWUA0QWlRSUVNXVdBSUVLoUsrkUd9UUVTo UsriVRBR6lEOUFVRDhBdUDpWOnBTUxVWUEpYVexSMlBXUDJSK1BIe0C2HkCmbB29UEl/Sr29vb1I SkC9DUC9DVFBQkdpYWBRUWVRUWVRVGusZVNRrK9Tm1LRrjHjUW9RbOOuNlBSUVRQUFQsVYNQTFBw UDUQdyJJ0klSFlwIVDhUU0hKSVVUVV5OFU1MTE1eWn5BUV3/XlZNWkUeV+pRMlBdUVEQQF5JcU8V TstQYkxMcXILEkh7QUJpf62kvR5ApB2tpr1Qb2+0b71BQml/QL1CR2lhYFENDVFmZmdmdGZlZHZz clZXd2ZmY2JGRkVEV1ZXVlZXUWdjV1H9Wm4RdlFKA9U5IsdJ5Xun4CmXNhpnkNMAQK6se517UT8L 3Rp6td1sACnf+E6GhDL6Cz81HMk6KDKuwZ2dUFJQP64BV4VVhVAXUAdQsBBvVHFUBUJxRHVEBXxN VnodaR0aHVNBQkNDQF4AH1BQXx0YHh8AAV5VX1B6b0sdXlBTA0ZAQ0N+UF9EUFBff3536FLOEEd6 T35qUQN+W1dfVnpaRmITG35TBBNaQO5SDlBDUVFQX1IOUFBRPRBBV0t+b8vQe1F7SgkYHh9XUVfo UkHlc35lSQgJ7FH0UHFQalIrUEh7ex6kHb2kDb0eQKYNHaS9QK20rbRQb6S9QL1vb2+9b71ApL3X Xn57VS1AlFBBQkdpUUFCaUFCR2lCaddeQJSUbNdeQJSUYWBQDVENdVZWc3J2dmVkQmZjYkZHZ2NT VkVERmNiZ2ZCZWRSdHNyVFJFREJUY3B0Z2NWVlRzcnR0d3ZlZGdCUHFiVEdGRUBXVnNydnd2UURG Y2JuUmVkdnNyXlJU2RHxAQn4OfOiIgfOaXLjwE55TWUGItX7rv2duq4thYVRw6VRVlEyCOVjqK76 oY6u2a6oEwQ0KlGRURCoUdsiMZzmiBUFRF2uRtIEaCwhGNcxECE6EPMbCziI0c9Rb/ALDcutMdxf S3dtAFFd3/dRcv6Lrje6pa7O+eAuOYovIrXF7YukjVFfUXCbmf2bro6xmnp3SVEc2cgT1Js22MYR wJ5QUq+HUFBUv1XqUFdQXlDwEBZYVlZSVlhYV1VZWlxUVlheXFxXVlhfVVlAXMdcUVJwUVBQTldc RFdXXFJcVFROU1JEU1NSUVdfVFNSU0Bcq1JRUllYcVVW6FHrEF5XV1RUU1NQWFz5X9PSSHtJQKRQ SG9sQGxAbECkbK1sb2y9UUFHaUFpadd+e9ctlNd+SHstQJR7QUJpaUJpaddAXpRVlJTXXpRVlJRX QGzXQJRhYHNRY0NzU3FTUXFTdndWV3lTb7ei7het/7tRb1G1aXFYYjBV6qoWUfauClJtUSCLwi79 UFNQCVBQVW1V6lBCUExQeFCFEBd2cEBBZEVwQEFkaXI5RZdMl01UQ3hNTHh2RUNbVXR5W0N4TE1N TlBRRFBQUURDcXh4d3dQVEtMcVEweFRSTk1xeEJQWEd6WOhSxhBdXnpQdB90MHTQdFR0dOhRhRBO TVlRUVBZTExZTU0rWV9Qf1BSUFAWeVlRQFBHFgFIe3t7bFF7Kh5AoFFIfw17Kh2hUUh/e2xRf3tA bFF/eypAolFIfw2tpL1Qb2x7rVBsb3ukrVBsQUJpf2xArWzXVX57LUCUUEFCaVFBQkdpV2xsYWBR DXt7Y1FxYkdOUkVEVldGRkVEVlZzUXFiZmVkdnZzcVNxYmduUmVkdnNxCVFjUZYsbDLXGtXZJybb td2u/lF5hetqMdaumL1RHtV+DSQS0eWu3FXqWkEFwwkp6GB3zTkpjilTGNjSbgp5q8NZQB0uFTc7 UFFQ6q+3VYhVg1BLUM/jxlhRQ+ivsONfQWRE6K+wEF5eQWRAcEBBZEFwXUFkSOivsBBhW0FkVEhE SFJ2RG9AFlMoQFRAXkRGRUlAQl9pXsJbUWnAUFFQUFRCfVtTSX1UWVArUehSMRBEXyteRnpgV1F/ V1FXZExeE01kE0h7HkC2QKQNIR29QL2kvVBvvW+9Qml/DbRAraRBaUJpUUJpQmlhYFENDXt7e3t7 UA1RR1ZQc3BQQUBDZnFiVEdXdnZzcFdWQURGY2JmVIOSDK7wi66lrpe+hFFruVFxR+dN5d+uo/bA juLIplJUS66urFEWUWBR3FFTt6qDQc/Nv56utbK+llBQUlALUFBV4lXqUF9QcFDCEBpHcFtBZExw W0FkUERwRGBE4ERUX1FfcFJZUVtMT1FLTE9wf1F/cFcXVVFwQEBOUFFEUFBRT3BxUVF4UlJDaUBx eF9QWEp6WAFyQOhRVxBBX1B/UFJQFnEgUVFRQFAWAUh7f3tsDVEeQKQNHb0eQKYdvVBvbHutULRv e2xArVBsVdd+ey1AlGFgUA1RDQ0he3tjUXFiR05SRURSVlZXVnN1Y2JnZmdmZ2ZmZWR2d3ZzcQtR YlHqzwQo+gY7/e3RMt+uh7jNKhxmF2ocCywwF8aurVXqR0/PvsThro2NLU5H9k1Cc30aMqvw4u9P R1BRUAxQUFXhVepQW1CUEG17UnlTalIQVzJSVVpTUlJbVVhZVFhdXFRZWU5QUURQUFFWVXFYWFdX UFNUcXhSUVJaWXF4W1BYV5JQVlFW6FIP51VVVFlTklJS6FIPEE1ZVFRZWVkrUFlRUVlfUH9QUlBQ FlxZUUBQRxY7SHt7e2xReyoeQKBRSH8Ne2xRf3sqHUChUUh/e2xRf3sqoFFIf7R7QGxRf6QNtFBv bHutUGxvbHutUGxCaX9sQK1s11V+ey1AlFFBQmlXbGzXQJSUYWBRDWNRcVdxU3FXcVNxVwxRY1Ry c6zyMFMYc6zoOlPLc1Xq965o965S9lBQUVANUFBVGFXqUFlQ+xBmT1FPVEtYU2NTZlavUqtWVFVY WVRVWFtaVFlZTlBRRFBQUVZVcVhYV1dQU1RxeFJRUll4UFhX6FEl40BWUVboUZLmVVVAVFOSUuhR khBIVFRAWSskUVFRQF9Qf1BSUBZaUUBQFjtIe397bFEeQKQNe2wNUR2te2xRQKS0QHtsUUC0DbRQ b3tsUG9se61QbEJpf2xArWxV1357LUCUUUFCaWlXbGxhYFENDWNRcVdxU3FXcVMNUWJT6XOtWzFT U3OsrdtV6veuffetN1BRUJevt1ZxVYNQcFCc6VBOr7AQQV5BZBdPUU56XkFkRXBeQWRI6K+441tB ZEzor7AQEVtBZFtES0RETGtFFkBVUFFySlNPUE14cE9PTlNSRFNTUk9OQ2lCwl5weFBxUnhRUVZG fV5TTX1WWUN6QlJZUkBT6FFuEEdySnpgWlF/WlFaZFNxeFJAU1NxWmQBSHt7QGxRf3tse0CQUR6k DSEdvUCme2x7QIRRvVBvvW+9Qml/e2xQrXtsUECttFjXfntVLUCUe0FCaWlRQUJpaWFgUQ17e3t7 UA17UWdxU1ZUc3B3dkFAQnRjYkZGR1d2dnNyVFJFREZjYmdDUxdzUtItKa6axq6QztW5UTOJzKjU TZBPk8nPrrz1ipDvjBJSEvat+xwwkfNRUFFYUeGfIe3IRcfx/a7zjo2yLlFrUFBRUAZQUFZYVepQ W1CPEBpUWVhYVVNaW1JaWVRTVF1cUltbTlBRRFBQUVZXV05YVURYWFVZWlRTcVpaUltWVVVSUnhR UltYWFdXeFBYVlZZV1crWFlVVVlYWOhS2hBzXVlSUllbWytQWVFRWV9Qf1BSUFAWXFlRUFVYQFBH WEcW/Eh7e3t7QGxAbFF7KkCiUUh/DXtsUX97KkChUUh/e2xRf3sqQKBRSH97bFF/eypAoVFIf3ts UX9Qb3tsQGxAbFBve2xAbEBsUEFCaX+tbEBs11V+ey1AlNd+SHstQJRRQUJHaVdsbFdAbGxhYGNR Y1NxQ2NRc0NxUwZRY5MvUqgvlK6elMCtWcFV6q3PUjGqFlLjrR1QUFFQJVBQUjtV6lBTUMQQWUBV UVlRb1VSVeivkON2emRV6K+Q40hzZFXor5AQd0RFZFJTU05QUURQUFFSeFFSU3hQWFJSWVNT8FBZ UVFZUBBCc29QUOivkBBBSnJkQFBRUM5UWVFAUEfOx0h7e3tsUXsqHkCgDXtRSH97e2xRf3sqHUCh UUh/e2xRf1Bve2xQb3ts11V+ey1AlGFge3t7UQ0NY1FjUSVRY5OunlXqqhZQUVAUr7dUGVXqUEVQ 9BB0JkBRYF8QXwBfMF8iX/hd6F1XUERRW1NdXl5OW1xEW1tcUTBQ6FLcEElWXFJWfUFZXV1ZXl56 W1kwXCBcUlxcWVtb6FGQEEtZU3p/RG9EH0TARFREBltGeFxAW0dbRloWOUh7e0Bse3tse0CQUR6k DR2teyqiUUh/e2xRfw17KkChUUh/e2xRf1BvvW9ApLTXXn57VS1AlFFBQmlCaWFgUQ0NQ2dWRURG Y2JmZ2ZnQ2NTVlZzcnZlZAPmQDUKETNPSEmKk49/jPvm6lH7XQV4ATFrbn8qVF+rgbKS+MgTUFFQ C1BQVb5V6lBbUJMQB0JQU1FPUU9SS1NLVlRZWVhaWlVTU1RaWlVbUlJbW05QUURQUFFTVFNSVE5V WkRVVVpXVlZOWVhEWVlYVlVaWVhXU1VdXFpZU1NbVVRSeFFSW3hYV1BYVehRZxBdXSJRUVFAX1B/ UFJQFulRZ1BIe38Ne2wNUR5AtlBvbGx7bFBve2xQbGxCR2lRQUJHaVjXHX57VS1AlNd+SHtYLUCU Vdd+SHstQJRXWGxYbFdAWGxhYFENUCITDAjkVHhCSGRRewljUWNTUXFRUXNRUVMLUWKUw1NMUUSt B1Gji64Jrp00VeqtblKSrfusy1K3rqWudFBRUAJQUFRiVepQVVAlEEhSU1NOUFFEUFBRUnhRUlRT cXhVUFhVklToUXkQS1dSUllTUytQWVFRWV9Qf1BSUFAWVllRQFBHFulReVBIe3t7bFF7Kh5AoFFI fw17bFF/eyodQKFRSH97bFF/HkCmHbRQb2x7rVBsb3ts11V+ey1AlGFgY1FjUXFXAlFilK6hUqlz VeqqvPZQUFFQClBQVqpV6lBIUlQQEM9KUWZTZ1dnWWZAF1cXWRZAGUIJUwtCPFM9VDlYO1k5XDld P0I5Qz9KKUIvStlT1UHaQvlCiEKPSkvPSo9KUl/or7DiXnBW7K+QUFWvkFBUr5AQc1NUVVVSVldY WFVcXV5eW19AQUFeQ0RFRUJGR0hIRdheWFlw6K8141VCQXDoUXgQAkVRUnBSVVVOQkVEQlVYQkVY VVVOQV5EQVVSQV5ZWlpOW15EW1teUVBQTkhFREhIRVVRSEUKUlleK1h4WFJSUVJIQnhCQUFbW1pa eFBYWVlaWVjoUSXlVVFRUFlS6FFrEEBVUFArSFlFRVlISMNVWV5e6K+Q43l7ZF7or5DjRXVkXuiv kBBsXkBkXn9bz1v/W1M/Wy9bj1tTW39Kb0pSSppaWVpaK1lbW8NZcFXAVVIwVVFVVUlKXltFSEBb R0hHFvxIe3t7e0BsQGxRSUFCaX8NIXsqoFFIf3sqsVFIf3tAoiEqQA0hkXt7e1FJf3sqQKBRSH97 KpBRSX97KkCxUUh/SUC0e0BsUUh/SUC0e0BsUUh/UG97bEBsUEBsQGx7QGxQb2xAbHtAvWxAvVBB QmnXVX57LUCU135Iey1AlNdYfkh7VS1AlNdYfkh7VS1AlHt7e9dAXpSU10BelJTXQF6UlNdAXpSU 10BelJTXQF6UlFBoaGhRaGhhYFEhDSJjUWNDRkdmZ1FjUXNDZkNWV1FzU3Z3VldTClFiocRNWW3f UlKlrp6RyWUzbw2tju3DRFlJSJNV6qwa6/zErVPcqhZSmadRY9/1rBFT/NH8kSGsCVBQUVA0UFBW XlXqUENRGxA5JFMmVSleU2leCV42VTle0EBVd1xnXDRBJlomW9dS2V1XWFlaWldeX0BAXUFCQ0BA Q0BdQ05QUURQUFFcW1tOWldEWlpXUkBdXU5XUkRXV1JbWlpSeFJRUlcKXENdQApSeF1cXHhQWF1d 6FGqEEpcWVJSK1FZW1tcWVpaV1lcXKtZVxBX0FdSV+hR1hB5UFlAQENZUVFQWUNDK1lfUH9QUlBQ FllXRHhRUFpXQFBHV0dXRFoW/Eh7e0Bse3t7QGxAbHtAkFF7Kh6gUUh/DXsqHbFRSH97QGxRf3sq QJBRSX97KkChDVFJf3sqsVFIf3sqQJBRSH97QGxRf3sqQLFRSH97KkCyUUh/UG97bFBAbHtAvUBs QL1Qb2x7QGxAbNdVfnvXLZTXfkh7LUCU135Ie1gtQJTXXpSU10BelJTXQF6UlGFgUQ1QDQ1jUWND RkdGR2ZnQ2NRc1F2d1ZXUzRRY+6nIRJ2Ykt55O+unpKuxDFmX3vqVeqtiqz8NPrplVMOqhZTH7D7 34Cs1VBSUOuvt1Z+VYNQQFBPUMYQSndSeFtSKUPURFJIcFtBZEdwW0FkTHBbQWRD6K+w41tAZE7o r7AQTltBZFZDWUxGQ0tMVHhRGEgHQ1NNfVNTRX1dWUp6VuivkON0aGRW6K+Q40tyZFbor5AQR0ZH ZNBWUVYBcUF6YFBRf1BRUGRwZAFIex5ApA0hHb0eQKYNe3t7Hb1Qb71vvWFgUQ0Ne3t7e3sNUA1D QFBxcFBBRFdWVldWc3J0UmdERkZjYmZmQmVkUnNyUOtRlVETUUJRCQcRliHG+OCuj8WRO4QlIZzx DaXktq7wUjZR2FG1rsuuhIbn2ZdmGPhRffDRiCo771FH14tRVK4nUFBSUAhQUFXFVepQX1BKUMsQ aPhU90NSfENqQyhD2UJUXkBKX0NAXkBFS0NSQUpfX05QUURQUFFBQHFdXl5QSUpxeFJRUl94UFhK 6FHvEHJFen9Wb1YAVjBWIFbQVlZWOUxPUSRRUlFAX1B/UFJQFjlIe38Ne2wNUR5Apg0drbZQb3ts UG9se61QbEJpf2ytbFXXfnstQJRQQUJpUUFCaWlBaVdsbGFgUQ1QDWNRcWJGRkVEXlJXVnNxU0Nx YmZmZWR2dnNxCFFjUjTPzzgaISQS3cCuwSzPURPs4DpoNsGu2FXqGeE+C+wqbl9xrf1SqQH2DRgL e1BSUO2vCFZgVYNQSFB+UKMQRAl5OVU2StRKVGZJYEpSSnBeQWRx6K+w40BBZHHor7AQWV5BZE5w W0FkdeivsBAUW0BkVnVLSktORnXQdlV4XnlBd0cveapQVXZQaUFpeStKJnG5UFZsUGpSbEkVe1R9 fHtTc0l5U1JGTFRTUFVJeXd8fXvoUWUQQXdTfVJpV099Q1N3fVdZTHpG6K+Q43RoZEbor5DjS3Jk RuivkBBHRkdk0EZRRgFgc3pgXFF/XFFcZH9kAUh7HkCkDSEdvR5Apg17e3sdrVBvvW+9QKS9QKa9 QWlpQmlCaVFBQmlpQmlBR2lhYFEhDQ0Ne3t7e3tQIQ11RkdXdndWc3J0dlJlZGdmZmdmY3BQQURS dWZCZWRSc3JUUkVER0ZjYmd2d2dGRlSGGi4H1TrF1zyurv4zGW2TJMniUUJRCeiutinGpOHErr70 yijZPQcLMBcROSYIAiQHLBYC9lFVzu//wIFpG67LroSNrttUDlEZ4o5RVf2u4pWn1zlyA2IqTB1Q UFJQMFBQVYdV6lBHUHRQvxDRcXBAQWRNcFxBZAdbUV1eXltAQkJfRkh0R0tIRkNZVU91Q0Z0R0dO UFFEUFBRQl9fTl5bRF5eW0JfW1N1XnZPW0JHWdZGSzBIcUZGRUVQc3RxeFJRUkdfeF9eXlBYdHRZ R0crUFlRUVlfUFFQUOV1WU96cFZgVlJWE3ZRQFBH3xNIe3t7bFEeQKYhHb17KkCiUUh/DXtsUX97 KkChUUh/e2xRf1BvbEBse0BsUG9se61QbEJpf2xArbRAtUJpaVFBQmlCR2nXfnteLUCU11V+SHst QJRQQmlRQUJHaVdsbNdAXpTXQF6UYWBRDXt7Y1FxYkZGRURWVUZHRkdDc1N2d3Z2c3NTQ3FiZ25S ZWR2dnNxMFFjUjfm7Du6rqsAeQxoIIs5aRliOCW02PlRX+xpP94eag4hrnJV6m340OO8c2tp0dqu vFFBxDwbf60lU3pVWx7UHBAPclBQUVDAr7dVD1WDUGdQielQfK+w411BZHror7AQSF1BZFxwXEFk JH7SeVJmVGZYaHFTWWZRVOivsBBkXUFkcXBdQWRXcF1BZHV/Zn3EW1NfXVt6fH5WRmVNaUxQaVFN TUZRUWVzfUZTVn1lWVErUOhRaxBdd3pwQmBCUl9CIEJSQuhSY+NoWXph6K+QEFpcQWRhl016SjBM 6K+QEEByeGRwTGBMUn9MgEywTFNM6FLb42mYE0h7QKUNIXukraR7vUCmDSG9pL1Qb71vvUJpf0Fp f0C0QLRBQkdpYWBRDXt7ew1QDQ17e3tDZ1dERkZjYmZlZHd2d3Z3dnZlZGZmY2JGRkVEV1dkd35S c3JXVkVERkdGR0ZHRkZFRFZUc3J0wJBSHuQs4OlhYo/9bzMOLL/G46Y/Ue1bRATDC/AJFGgZZJPO bAAGwa9Q9amulVGKQmMF3R3KMxVpaDAbeBHJMiHmMCiYC1lFX25zbQRjGGcLZgV5TQYWeGXHMCeZ PolQUFFQr1BQVfRV6lBXUM8QZktSUXBQcFdmU1NSU1lYUVZTUnhWV1dOUFFEUFBRVVJxVFNSV3hQ WFZWWVdXK1BZUU9RUVFZUOivkONxcmRQ6K+QEFxMTmR/UGBQ4FBTUFDoUZXmWFlRQFBH3+lRUlBI e3t7bFF7KkCiUUh/DXt7e2wNUX97KkChUUh/e2xRf1Bve2xQb2ytbNdVfnstQJR7QUJpaVFBQmlp YWBRDQ1xUXFncVdxUVGBUV+uT3NU0nOuc66hVUP396q9UFBRUJavtlZZVepQSFDGEGJZQFlBZHdA cEoLRTlFJ1EoRVZdXl5OW1xEW1tcUVRUTkZQREZGUF1cUVBSeFd9Qll4XehRa+VeetZcUVzoUWsQ WRBbAFtSUFtRW+hSNxBeSlHyVHrWUFEgUFFQ8kboUarjSWTSSHtAprQNIa20QKQNIbQhrbR7b1C9 e29sbGzXXn57VS1AlNdefkh7VS1AlGFgUQ17UWNTVkVERmNiZmZnQ2NTVlJUc3J2dmVkZ1HGlOxH 6t0gkSB9+ZTjfsaupuD2oyl5VeqsKyBmJsA3mItTd6z0jK6vyz6SKx3sUFFQrlBQVl5V6lBaUMwQ QxRRFFIEUQRSVFNUVVVSVldYWFXorz8Qe1VQWnBZWlpxVVhEVVVYUFFRTlJVRFJSVVVaWVhYUlJR UlpQWFkrWBBak1jqUUdQUFGoEFxVcFErEFLyVetbcN/pUVJQSHtJSkCtSKRKvUlKQL1ItEm9SEpA vVBvbG9sQGxAbEJp11V+ey1AlNd+SHstQJR710BelJTXQF6UlGFgUQ1xUWNDRkdmZ1FjUVJIrrbt +n9eDGtSW5qsjFXqrMa+wuw+U5CqFlBRUVBQUFguVepQTlFEEDV4R1EYUBlJCFAJSTlQOUkpUClJ 2FDZSVpJSktLSFhXVlVUU1JSWV9eXV1AW1xcWUJERUVATU5cS05OTllcRFlZXEdARUVORkdERkZH TktZR3BAS0BZU05GRV1cUlJOSEdYRSsQRuhRLeJAcEfoUW7jSHFAXOhRbuVdcUtSTlHoUYLjUHFZ cOpROFBAUYLlS+tZw0/f6VEQUEh7QKStrbRAva29QK22QK22SklArUpIvVBvbGxvbGxsbEJHaVFB QmlBQmnXfnvXLZTXfkh71y2UQF6U10BelJTXQF6U10BelJTXQF6UlJSUlJTXQF6UlBvgSQMI6VBL r7DmQHBZcEtAWVAtf38sf1FoaGgJYWBRDVANcVNjQ0ZHRkVEV2ZnUWNDRkdmZ2ZnUWNRc1N2d1ZX UVEKCpdyU1dSUSpmUe6aYVhTQn4Zc1HymK1GgmFXVG15rlRV6q17ZLYQSkECqjZTHKz3w59jNfMW U2qqFlMoIvbbHawYUFBRr+9QUFZ3VepQRVFhEP1UcFtpcFQTXdpRU2laaltpXBhbGFwUXhNfBlsG XOhbqFClRKRFokZeU1N2UGZc2FvZXPhdpltXWVtRWFhVWVpbW1BUVVZXWFhaXl5TQEFCQkRfX1JD QkJAREVFXEJSX1xFWFNeW1BRUFtSX11TXkVcWEJHRlhCUkVbUFBORVxERUVcUl9fTl5TRF5eU12T UVFTXFtTUlJFX15QWEUKUF8KXhBbClxwUwpSEF5AXOhRlhBccFJZf1BRUMxGu5pIe0keHUCkDXtI hEpRSR2te2xKUUhAvUpJQL1KSEC9QL1Qb2xsbG9sbGxBaX+9Vdd+ey1AlNd+SHstQJRQQUJpaVFB QmlpX19fX9dAXmxYlF5s10BYlF6UlNdAWJRelGxsbNdAXmyUWJRhYFEiIQ1QDXtzUVFjQ0ZHRkdm Z1FxUVFzU3Z3VldREVLsrjGI7RtbSk8ay1ESUVCta1HChb5zfmYerjdStVKFruTTRmEUNPNRA61b rWtR/W8zGQKuHFBRUL9QUFZ/VepQXFD2EAI4WThaUldYWVlWW1F4W1xbWlxOUFFEUFBRVltaVlNa TllWRFlZVlZRUlZZUk5TVkRTU1ZZVlJTVF5dW1ZRU1pZU1JSUQxccFx4UFhbQFwrUUBQ6FGY5l1R QFDfmkh7f3tsUUCme2xRrXtsUG97bEpJQL1IUG9sbGxHaVFBQkdp1357WNctlFXXfkh7WNctlFXX fkh7WC1AlHtCaddAXpSUYWBRDXFDUWNDRkdmZ1FjUVNSbCaubYKIFxMa0FEIuq0UI1JnU9OuBNzw 2PFR/6w+rYhQUVBiUFBVSFXqUEVQ+hATGVvJU1J4X3hBUlJTVFVVUV9BQV5eXkFFRV1FRFxbVEdR WVhXU1tVXkFBTlFVRFFRVVVBR1FeXFXWW3FdXFJE1kFxUehRZuNFUFhd7VLGUF5Rf1BHUFFSxhBb X1BPUH9QU1DgRuDpUWFQSHseQKQNHbRApLRQb2y2rbVvbK21QWlRQUJpadd+e9ctlFBBR2lRQUJH aVdAWGxXQF5s10BelJRsYWBQDVENY2dRZ2ZnVnN3V1dxZ3FXUVZXZmNxV2JDUo7IfnsNdWBqaa5D c1OjQay9wXd8XVNPc8NTPehof1tRUVH3yawJ/XxW91BQUVBdrj9TcVXqUFdQCBBIVFVVTlBRRFBQ UVNUcVFAVlVxV1BCUv9T6lFVUFRRj+NVV/9W6FFV4lUVUehSQeNQSVg36VFWUEh7HkCkHbStpLRA pKS0UG9srWxvrWzXVX57LUCUYWBDUXFXc1FjV11R0VHDTYuu5I1Nrj9XG9upm9tQUFFQ/q+4UmBV g1BTUGUQR1JTU05QUURQUFFSUVBTUFpRqFIdU6hQ6FJe41Q97kh7QKa9pr1Qb2xvbNdVfnstQJRh YFVTY0NR9KbcpkhVu6pFUFBRr9iuP1LyVepQV1AMEE0YUBlTUldQUE5TVERTU1RTUnFRQlVUcVZX QFb/VehRVeNUUf9S6FFV5lNXFVRQ6VToUY/lUx1YudpIe0CmtL1AvUCktECktFBvbK1sb61s11V+ ey1AlGFgUQ1RcWdjUXNncVFIriBNjVEcjE1Rw64/21Zl21BRUGZS4lPbVYNQVlAF51YVUlVRi1JV EVlRUVBUUFBRUVBRUFRRj1BTr7DjWUFkU+pSz1BWr7DjWUFkVu5Sz1BSUY9QUVLYUFdRMeHtSHtA pqSte617tEC9QL1Qf61sQL1hYENzUWNRc1O/6VExwVEz5adS4lNxrI9SBVBQUa+xrjlU2q67UFNQ ShBcUStQUkpVUElUuf1Iex5AtEC2UH8dvWFgU2VxRU9U+a450tJQUFFRelT3UipV6lBTUG0QS9BS UStQ31DwUeBRkFFVUlBQU1FTwVFQX1NRU+hRHONRSVSd6VIrUEh7HkCkHa0NUG+9DVFpaWFgUQ0N UVNjQ1G9k4wkVPdRQ669UFJQCq+4VGZUblB3UGVQkRABC31RdVp1W3NcdXxqURpRVn9YaVgHcTdx VGR8eltUf3h2XVNfUHVOc3h7U0NdWmJKeHt7fFpdRFpaXUZ0T0dRRwJDT0pXdlpiT1NbRwhfRlFG 6FGTEE5/cFZ2Zl9wTlAIQHMgc1Jzr04QQUJkUE5ATj9OU07sUihQZ1B2UihQSHseQLYNex2mDb1A vR5ApB2tpg29UG+9b2+9rQ20115+e14tQJRQQUJpaUFCaWlRQUJpQUJHaUJHaWFgUQ1QDQ11VlZz cnZlZGZmZ2Z0Z2ZlZHd2c3JWV3dmZmNiR0ZFRFdTVkVER3N2Q1ZWV15SRURGY2JmZlNADv4zw+QB 1jFtUQUaRX5vKSLBcedoo+mVIwhJa0xG519tdgc2ztISOTEK9jDUARv91wnZA0JcXk0aYW90YjUN QM74DhYgBSCuqC4fYg5kUbZfQFleew5pHDIP+lBQUlAUr7hUGFXqUENQc1CsEDZKcF5BZE5wXkFk VHEfdSVF2kH5QelBVnlBf3VvdRdFBkU2RVYqcVFTQkRFckNSRURCU0x0U1ZPQ1JSc1FQRFFRUFJ4 UVBTdE9PVldDeFBaSE9fW1lwQm9MUVBMf0xvTB9Mv0xVTEzoUe8QXFBZUlJDWVFRUFlDQ+hRZhBJ WWBQUX9Qb1AfUA9QVFBQBnRZUUBQRwY1SHt7e2xReyoeQKBRSH8NInsqHbFRSH97QGxRf3sqQJBR SH97KkCgUUh/DSETDAjjIExRZ3sNCVG9UG+9b3tsUG+ttG97bNdVfnstQJRQQUJpUUFCR2nXXpSU lJSUYWBQDVENDXt7Y1FjU2ZmY2JGRUReU3NydndXQ1dERmNiZkJlZHZzclZXVhRRYuU9BtwcxZcA Ji7UbTnwfXo9UdIxD8820Q8y9Gd5VeqtpB8RjoTdus8Pfz8imVHkctje1VFKJ9bEx80lUFFQI6+4 VEZUblBLUNwQWmlTOUQ3S8dWVEjor7AQBUBBZGla20FSDEs5QCxZKUDJWFVWREZEeVkTUQhSCFhW X3ReA1tRdGBQMFDAUFNQUFRCT1tXSU9UW1AIcFFgUVJRoF5GcFd2TF8IUF5AXlJeG01oG0h7HkCm DR29HkCkHb1ApA29UG+9b71CaX8NtECttGFgUQ0NDXtQDVFHVlZzcnZlZEJ0Y2JGRVd2dnNyVlJF REZjYmZTceUUq/D9h9pRUfX7mOJRIw498AsoCAjxUdNDl5Gwmf5RAP+Rz1w1Itqut9LY2NZQUlA8 r7hUmVXqUF9QT1D46VBNr7DjQEFkQuivsBAPXkFkWVNWXlRNSVM5XOhd5l5XRl5ETXlXc0UXXgde VkRHUX9RcVp8RQZaNlpValFiWmxFG1ESWhpFVkhfX1xbW0RZXFBLT1lXX15aRE9SW12cXghcnEBf D18/X/BfVF/oUXTmcUBwVXZwdulRdVBIex5ApB29HkCmDR20rbRQb71vbG+9b0FCaX/XQF4tlGFg UA0NUSENDXt7dVZzcnZlZEJmY2JHQ2NRc1FERkZjYmdmZWR2c3JeUlNAy/nHmc+/KJY1KOSunveu YHw6Gis01tQ0ETs5GMrij4SSURHw71JrqhZR7T/QBdD6qi7eatuGUFBSUDqvuFQRVG5QSVByUJDp UHGvsBBZQEFkT3BAQWRG6K+wEAheQWRZVnhy20jbSVRISRdKUldQ5UmVSVN2U3xbJ0rXSlRQcEBB ZFBLSlBTQlFBX01QdEBRMFFSUFFAUQBRMFFUUQNUS0p8QcBC8EJSQkJUcE9cV0dPVFtC6FLCEEtE cFh2c01wXxBHcGRQX0BfIF+PX1RfbnR2bkh7HkCmDXsdvR5ApB2ttFBvvW+9Qml/DWytbECtDSG0 UUFCaWlCR2mZe2FgUQ0iIQ17e3tRR1ZUc3J2dmVkQnRjYkZFRFdxVkVERmNiZlFxZmVkdnNyVlMA 4Hauv+0mlTfxUVDF7rNerKJU2TMN5K50UgRR2Dsk71E5QtO8PYDV/lEXz7ycHgJPScXNKlEqTFzY wfBQUVANUFBTE1WDUEZQkhA3c1dReFF5W2lXj0OPRFVIUXZCZkJTVFFQU1RFU0JFRkZBVFFQUFVc W1xTW1leQUZGc1BVRFBQVV5wWVFEUnxTQ0JCVFRTVkZ4UFpDJERTJEBSUVJCJEVFWUZGCFBZVCRR UVl/UFFQUOhSRORHWZvcSHt7KkCiUUh/DXtsUX+0eypAoVFIf3tsUX+0fw20f7RQb3tsUG9sQGxA bECtbG+911V+e14tQJRQQUJpQmlAmVdVQGxsV0BsbGFgUQ0hDVANY0NzZ2NnblJjYkdXdnNyVldX Y1dzUw2R8k3yT0hjIzMV03EMbmVnREiaTZqRU8rcxyE0EU3OSGUzItysNlBQUlBlrgdU1FRuUHJQ Y1FN6VB2r7DjQEFkYeivsONAQWRi6K+wEG9eQWRUYURhUlRIaVkFdjV20GVVdXtgZVJ1QnVFb1Bs T1RGRkV8R0daWkl4XXhISUlzWkdEWlpHUXRQUEBQUlDoUt4QY11/T0RXSHhHVnhPXVpWT01fSEhZ SUkIWVpaR1lGRllHL0dRT0d/R9BHn0dUD0dRUEdRR+hSdeRZc3BAUOhRnxBMUnDfcVFxlUB2b1pR UFpRWmR4R0BaR1pkWnYPSHt7QGx7e2x7QJANIVG2pg29tUCteyqiDQ0hIlFJf3sqkFFIf3sqQIBR SH97KqFRSH97KpBRSX9QSG+9b71ve2xQb71Apg20115+e1UtQJR7QUJpaddeQJRYlGFgUA1RIQ0N e3t7R0dWRkdGY2JnZmdnVnNydmVkQmZjYkdnY1NeUnNydnZlZENER0ZGY2JmQmVkdnNyXlJq51Jy dWEe9Bh/eELdz/GJ+7wtgSF09oZzIpvV0OkLt0VOPxQJ4D3BOxIsO2cwQW5uQUYFae8G372J41F8 yZb+q6/57TgSLwJJUgM9Zx0BLVFWJ9PLF8GaUFBRUBRQUFRrVepQSFFEECcXVFF2V1FPXE9dUllR dVgZURZYB1PXWJ5BVzdXKlgqQflB61jrQVZUW1ReUkRbRF5SU0dIUlJISHNQUURQUFFZXFxzXUBE XV1AQ09WV1J4UVBdeFBaWVlZXFwIXVnfQFFAQFl/XW9dL12fXVRAXR9dD10/XVRdXehSLRB9SllS UllISAhQWUJRUVFRWWBQUX9Qb1AfUA9QVFBQBklZUVBAXUBQR11HBm5Ie3t7e0BsQGxReyoeQKBR SH8NIntsUX8NeyodQKFRSH97bFF/eypAoFFIfw0he2xRfw17KkChUUh/eyqQUUh/UG97bFBve2xQ b73XVX57Xi1AlNdVfkh7LUCUV15sbGFgUQ0NDQ0iUA0hY1FjU2ZmY2JGRURXU3NDZmVkdnNyVlZX UxRRYuUlNf4M1MJw0+XXTRgUMuI1eg9V6q2dMgXbImjGrd1S09x0ZBI345euaFBSUG1QUFJ0VepQ U1BXUX8QWvdTllO3U6VTVFnor5AQHH9oZB9Z0FmAWVNPWX9Zz1n/We9Zr1lWUFVUVFFTVldSUFFT eFJXV3NUUURUVFFTM1J4UVBWVVZXeFRaUlJZV1c+VFlAUVFRUVlCVFTor5AQSH9oZNBUgFRSVBBb X2RUJVhZUUBURwZuSHt7e2xReyoeQKB7IXtRSH8TDAjlVBAdfm9U6K+QEFlvdm9UEG51b1Tor5Dj G3ZvVOivkBBeEXFvVBBEeG9UEEJzb1Tor5DjTWBvVOivkONMf29U6K+Q40d2b1Tor5AQWURxb1QQ TXdvVOivkOJJcW97e3t7e3t7e3t7e3t7CXtsUX8NeyodQKFRSH97bFF/UG97bFBvbG97bFC911V+ ey1AlHtBQmlXVWxsV0BsbGFgUQ0heyFRZ2NXUUNjU1EVe+R7rhSO5Y5UvZ2dq0NUdquKUFBSr1iu B1JzVepQU1BCUJ0QF9lZUX9EB1tSUFtaWlFTXF1dUlVUUFFTeFRBVVtXUl1dc1pRRFpaUVMzUnhR UFtWV3BBX1JSWV1dcFpZUFBZUVtRUVFaWVRU6FHqEHJZWhBfaQ9aUVpAWn9ab1ofWlRaBllaQ3hR QFpHWkNaBuNIe3tAbHt7bHtAkFF7Kh6gDVFIfw17eyodsFFIf3tAbA1Rf3tsUX97KkChUUh/e2xR f1BvvW9ve2xQvddefntVLUCUUEFCaUJpe0FCaVBAmVdAVWxs10CUbGFgUQ0NUWdjV1FnRmNiZmdD Y1NWV1ZzclEVe+N7rUBwbmBqFXWP5bZ7aBvWF1S9nZ2p1MpBHf9UYKv/nxs0UFFQFlBQVD5V6lBb UULpUFqvoBApW0BkcFUQVQtUOlTbVMhUylVXWVRRX1NzU/FatVqlWlU5WdRTx1adU1RWVldZWVha WlVTU1RbUlRWVVNUWFJbW3NQUURQUFFTVFNSVGNVWkRVVVpZWFlaWHNXVkRXV1ZZWFdWVFNWXVxW VFtSeFFQVVRWW3hYV1BaWehR6BB7WlQzf1VRVdxvXR9dD11TXVJAWwgiUVFRQH9Qb1AfUA9QVFAG XFFAUAbcSHt/e2xRHkCkDXtsDVEdrXtsUR5ADaYNHb1AtlBvbGx7bFBvbG97bFBBQmlRQUJHadd+ e1gtQJRV135Ie1gtQJRV135Iey1AlFBBQmlRQUJpV1hsV0BYbFhsYWBQDSFRIQ17Y1FjU1FjUVFz U1dTFlFj5O5SQL+ua1FCloSMGlXqrCNRqa4krTZSce6uzVBQUVBmUFBSTVXqUFNQrhAFMFVRH1XQ VYBVU1hRT1V/Vc9V/1XvVa9VV1JTU3NQUURQUFFSeFFQU3hQWlJSWVNTPlBZQlFRUVFZQlDvUJ9Q UtBQgFBSUBBbQmRQOFRZUUBQRwYPSHt7e2xReypAoHshIkh/EwwI5VAQSEJvUOivkBBZb3ZvUBBu dW9Q6K+QEF5MZ29QEER4b1AQQnNvUOivkONxZ29Q6K+Q40d2b1Dor5AQWURxb1AQTXdvUOivkONJ cW9Q6K+Q4xt2b1Dor5DnEXFvUBBzQm97e3t7e3t7e3t7e3t7ewl7bFF/DXsqQKFRSH97bFF/UG97 bFBve2zXVX57LUCUYWBRDSEiY1FjUWZRYuWunlXqqhZQUVATUFBW0FRuUHpRGRBtFkFRfBBZWmTP fOtz73yfR5lzt1JWyUfJc/5G/nL/fOtHVhVeBlgFXgdCNl4vfFZZUXJYcl5lWGNeFlhWfOivkBAf XUBkU3l6UlJ6enNQUURRcEBpJFFRUFBRTU5Oc09wRHBwQGkkcFFPT3BfQkJzQ0RERHBAaSREUUND RHVPVklPXFxWV1J4UVZ6T05DeFBafOhRghBdRF9ZQghEQFBDQENSQ+hROxBdT01ATghwQFBPQE9S T+hROxBPUFJAeghRQH9Qb1AfUA9QVFAGe1FAUHBAT0RAQwZuSHt/e2xRf3tsUX97bFEeQKQNe2xR Ha17bFFApA17bFGte2xRQKQNe2xRrXuUUUC0UG97bGxsbFBve2xQb2xAvUC9Vdd+DXt7Xi1AlFXX fkgNe3teLUCUVdd+SA17ey1AlFdebGxhYFF7DQ0NDXsNY0NjV2ZmY2JGR2ZmY2JGRURXU3NDZmVk dnNyVlZXU3NDZmVkdnNyVlZXUxOO5XU1zw0z1UUB4zPV1Uff5cJDEmwB+A1zPOXGQBFkHfk6cjlU dv8hBjkONDMuImEhrQRS7gZ1ZGwyz/WtrVKdGU9kEDL/8q5aUFFQFFBQVGlUblBHUL8QAHRXZVdS c1J0WGZSFlgGUgdcNlIpWChB+kHvWOtBnFiZQV5TRkdSVFZTUkdHc1BRRFEQQGkgUVFQUFFZXFxz XUBEQBBAaSJAUV1dQENPVldT6FGuEEFSUlFWeFxHXV1QWlFQQF1AWehR5+JcCEDoUecQXW9dUUBd H10PXT9dVF3rUi1QSVBSUeriRwhR6FHqEEN/UG9QH1APUFRQBkhQR11HBm5Ie3t7HkCkDR20rbRA pA0htK20e0BsQGxQb2xAbGx7b2xQSUC0SG+911V+DXt7Xi1AlNdVfkgNe3stQJRQQUJp116UlGFg UQ1QDWNDY1dmZmNiRkVEV1NzQ2ZlZHZzclZXUxSO9Hc76jHRw0rX5d1FGRXbiWM3VHbpPTTcJWsv rS1S8TJ/ZRKYo65CUFJQNK+4VAJUblBeUHBQKOlQQa+wEANeQWRLcF5BZHdZUTByIHJSVlVLRURO UwlECkUGTgZPP0UwT1YTVVEkQCZEK0oqTuRTVUxPVFdCT1tbX3BQEH1/ZFB2cUlwUFdAVyBXU1cj cnY1SHseQKYNHb0eQKR7Hb1Qb71vvWFgUA0hUQ0NIQ17e0NAZ2ZjYkZFRFJUc3J2dmdERmNiblJn ZmVkdnNyXlI058elkLvErr/HLJs75cA/aiIyFUVPwT4F3CFlUcNRZ5z4oJznrpX4OpLBxst/MCsX MwvAzwHMn1BQUq+7rjlUGFRuUEFQcVCqEHIVTwZUDl8KRTtfVWpFZU8VVB1fGUVVdVR+X3tFZ1Rs X1VA6K+gEAFeQWRMcF5BZAlIKFEpSNlRx1CocVZJSHZcaFEYUTdAOEhWWHFRQkFSU01HUkFBc1BR RFBQUUBAXk1PVldSeFFWR09eW0F4UF5ZcEpQSg9KUkroUnEQdFBZUlJZQUEIUFnYUVFRUVlAUFFQ UBxZUHJ4UUBQR1ByWptuSHt7QGx7e2x7QJBReyqhUUh/DXtsUX8NeypAoVFIf3sqkFFIf3sqQKAN UUh/vVBve2xQb71ve2xQb61BaX/XVX57LUCUUEFCaddelGFgUSENDXt7UA0NDVNRY1dmZmNiRkVE UlZWc3J3U0NER0ZGY2JCZWR2c3JeUkVRY/dPDcMCyJg+8PQG7zko4UFJIhvMkNEwFSY1Eq45Ve3E MRuNnvauv/Yekq3vUxknfhEAUQ/n18MZwYJQUlA5rjlUO1RuUEBQcFC+EFvqXFErSdlK1k1TTuiv sONeQWRD6K+wEEFeQWRKRmtQaV4fUAtQOlBWcuivkON9Y2Ry6K+QEBlHTGRWTkZOB15TR0hAQF1Q RFxLUl5fX3NAXURAQF1LT1lXXnhdVkRPUltAeF9eXl5ZX18IQFkgXVFdXVlAUEBAQG9AH0APQFVA 6FEzEEBZQXBVdkBxeF1AQEdAcVp26VF2UEh7e0Bse3tse0CQUR6kHa17KqINUUh/eyqQUUh/DXsq QKFRSH97bFF/UG97bFBvvW97bFBvvddVfnstQJRQQUJpQmnXXkCUlGFgUQ17eyF7ew1QDXVWc3J2 ZWRCZmNiRkdnY1FzUURGY2JmQmVkdnNyV1ZXVlKiy97EnMuh0DHPYXnMrp7lrsjSMQL3O9YxDxcN ZXgowLGfllEQ8D0+k6oTUxfNx9hRQC/SxG4AxyRQUFFQFFBQUwtUblBfUKQQK1lT1lnDWMFZVFZd Rl32WJdUuVSqU1Z2UnhUaFFmUhhRKVHZUVdeX1JTW1JfX3NQUURQUFFZCFhWW09WV1J4UVZfeFBa UlJZX18IUBBeQGRQWVFRWUJAUHBQYFBTUFBAUFIwUCBQgFCgUFRQf1BvUB9QU1AGQFlRQFBHm+lR bFBIe3t7bFF7KkCiDVFIfw0hIhMMCOlQUK+Q40Rxb1Dor5AQWV5Hb1AQXUZvUOivkON9R29Q6K+Q 4k5Cb3t7e3t7CXtsUX97KkB7oVFIf3sqkFFIf1Bve2xQb3tsUG+9b73XVX57LUCUUEJp116UYWBR DQ0hY0NjV2ZmY2JHV3ZzclZTUxSO8H0CzQJmHxp/aA+YaQpUdokrJnf4coSuva4GUFBRUB6vuFRT VG5QfFCi5Vt6X0FkT+ivhuNfQWRT6K+wEElfQWTFXcxxzHJTJlMqScZbxVxUW3BeQWRw6K+w415B ZHHor7AQFF5BZNVT20j0W/ZdVBZTKVvYW1N6XHRxcnNoXFRwXFtTTXJYcnBcW1RRR3RGAkNQdFFR eUpPQ1dVT3lbTXAQQFFAJFF86FLCEFlRCHBQUX9QUVDoUkQQQH1PR1FHoFhwUHVAdVJ1oEbor5AQ QXR5ZFBGQEZSsEZRRpF+BpFIex5Apg0hex2kDa20DUCmDSK9tECkIb1Qb71vvUJpf7RArbRBR2lR QWlCR2lhYFAhDQ17e3tRDQ17e3tDZ0RGRmNiZmVkd3Z0d3Z2ZWRmY2JGR1d2dnNyVkVER0ZHRkdG RURWVnNyd3YF5WDRBigodHWusXgTFJjkmIFU4VTQJQ44fU4tgGYGMZfX6NHRUTtbHj4WMBF/enor SXk/GC7k6cdcMCAGYmJ2SmYKZAMnH8gLCwtQUVAjr75SwlX4UEpQ2BB6Gl82XyZf11/IXslD91ng TJBMuENaUFFRU1BJX1BCW3xBXFZJT1NbX6BB6FGu4kAkQupRrlBDUkvjRAhZXOhSS+JdJFvsUktQ WlJLUFmvkBBbdHxkUFlAWd9ZU1noUt/jS2jjSHtApg17pLSktECtpLSktLRQb71vbK1sb0FpQmlA mWFgUQ11V1Zzcnd2ZWRnQ3NnY0NnU2NXc1NWRURGY2JRu04RbTwQYErR303fZ58B4k7hK0d1emzD xEFleBVzLlI53FFVLa4u3K3lIEZwclBRUNCvuFQmVHZQSVCuECVJWElZxVvmV+Zat0W1SFdZWFlZ 1FzWSMVXxVr7U/lWWHdaZ0gmVyZaJFwlSFZ8UX9AaUEZQVRFSUhHR3NGSURGEEBpL0ZRRkZJWVxc c1VYRFhgQGkiWFFVVVhQWElGWVhHVnhfT1JbSUhaVUp4RklYVUBHCEboUeoQX0gIb0lRQEkfSQ9J P0lUSehSLeNLWQhY6FHnEExccGBVUYBVsFWgVVN/VW9VUlVJR1VHVUpaaJFIe3tAbHt7Hn8NISId vaS9QKQNIb2kvXtAbEBse0CQUG9sb717b2xsbFBBQmnXXn4Ne3tVLUCU134Ne0h7LUCUXkCUYWBQ DVENDQ11VnNydmVkZ0NjU1ZFREZjYmZmZ2ZnQ2NTc1NJ75grx3LQ5d5CGRccwTlxRk0w5Y73kIjd NhPzUjWtCQV/bBMaLgZn2lGbq4pQUVDyUFBUKVR2UFpQzRAbQndTcFwWWhBcAFzZV9hZ0Fz1UfZa 51FbVlVVWkZUd1poUFVaWVljWFVEWFhVVVJVWFJjUVBEUVFQWVhYUlJRVlpQWlkIUFhAWFJY6FFF EEFSCHBRYFGgUVM/Ud9RUlGvW+pRHVIoUEh7QKYNIq2lDb1Qb2xvbEBsQGzXVX57WC1AlNdVfkh7 LUCUYWBRIQ0TDAjkWFpCR2RRewlxU2NDRkdmZ1FjUVEA/uALX0ZkAVEz763wVHat5zCJIcJSL6uK UFFQz1BQVmdUdlBKUUUQdrVJUV9Mj0xSeUkXSSdD1lPQW9Zc0kPVSNBKx1mFRLdZuFq4Q15M6K+Q 401xZEzor5AQE1tAZEBfXl5BXVxbW15FRkdHREhJSkpHWVhXVlZaVVRTUlJWVkpQXkNHREJBQVtb RzNaWlJSUVZDXjNEREpWM0pQWkPqUjRQRFI150pMR0dKQghB6lHpUFtSNOOQWlFa6FHp41IIUUro UjTjX1BRUOhRkRBZX1FRUUlL3dxIex5AtCEdpiG2QK2mDa5JpkitSR4VNRS2SB1Apr5Qb2y9QGxA vWxvbEBsQL1sQGxAbFFCaUFpQUJp10BeLZSUlNdAXpSUlNdAXpSU10BelJTXQF6UlNdAXpSUYWBR e3sNIVANcVNjQ0NGR2ZmZ0NjQ0ZHZmdDY1FzU3Z3VldRUV4//mBDUlROen6tlXNYUmIhtOWtqex4 VFJ5aK63VHauc66kTgs2PTVSeq29KZrWvlGyq4pSP2r4OyytxlBQUa+tUFBUHVR2UF9RXhBEQkBB cEFSd18QQQBBNl8pV7BBVkHor5AQGX1rZFZZRllSUVZWUFFRUlZXV1BUVVZWV1lZWFpaU1FRUFxe Xl9bW1JZWVpeX19YXllWUVRfWFdXU1NSVlpbW19fUFpZHFZaM1voUa4QWV4cUV8zUFgzV+pSclBW UlvjUVMzUupRrlBRUUTlQFA/UFJQ6lGfUEBRU+HjSHtApQ20pL1AraS9QL1AraS9QL1Qb2xAbEBs b2xAbEBsQkdp10BeLZRYlNdAWJRebFiU10BYlFiUXpSU10BelFiUV0BsYWBRDXsNIRMMCOlQWK+m 4nRlX+ivpudKTGRYWkhlX+ivphBZRUdkV1pCR2Rne3t7e3t7CXNRUWNHRkdRY1FRc3d2d1FTUZ6u p5gKYnhRYo2uElFcmDpye66UUktSW+06MVHYrbeto4gVNq4tUFFQUK4BVC1UdlBEUMgQA3BGYFsQ XBBG11pVWVxbXUZZR1p6W2hdVlhYWV1eXldQUUVQQ1FYU19AQGNXXkRXV15dXlpXQFNdWF9eXlpa WVZYWlNwQ19fCEBeUUBeUV5aCFlR6lLCUEVRU+HcSHtAtH+9fw0ivVBvvW9vbEBsQGxCaUFpaVFB QmnXXn57VS1AlFBBQmlCaVFBQmnXQFSUWGxhYFEhDUFnRmNiZ2ZnZ1NjQ0ZHUWNRVlZzcltoZWdy fGRq4eIASEFRi+2tCzLIM2+uNvpASXELOFR5rbfPz1MHqx3gIlBQUVB4UFBUSVR2UEFQ+hAV1lLa XVJWWyVRL1QqWiBduFtWXFtaWl1TUlFUUVFAXVFUVGNaXURaWl1aJFZWV1lXY1hWUXRfX0BQQGNB WkNHRxtZQCRB6FHn4lpAWehRKeJXJFjoUecQQFFA/1BRUBBbXmRQv0K/G0h7HkCkew17bFEdpLSt e2xRpLQeQBU1FLZQbx29bEBsQLRvvWxAbEC0Vdd+e9ctlNdAXtdelJTXQF6UlGFgUQ0hY2dRZmdW c3FncVdRVldmY3FXeE1Sa20b0WiuJXBTZUitkGExx2hR8nHcUtMUGV3HIq0pZzBZz1BQUVA7rgFT wFWDUGFQzuVqUlFKTk7oUVEQWXp+RHp6fkNEROhRURBJU1ZEU1NWR0pHUHFhYVxycXVfX3FcUV3/ XuhSOxBCQ6hgVlFW5kQVUyd+c/9fdFF07FFaUE5RUVB6UlflSul+UP9h6lGkUH5RE+NizypIe0Cm pLRAra29rQ20QKS9pA29rbRQb71vvUJpf71pUUFp115+e14tQJTXXn5Ie14tQJRhYFANQ2ZmZ2ZC Z25SZ2ZjY1dzclZWV15SV0ZGRURXVkVER0ZGY1dzcnd2dmVkZ2ZlZHZ33h0idEwZREsbBm5zAWhy TwUbeHF6GD00GBV9cF9bZw1yZw52ahJ+cwAeUjRSHgBtUR1sAzdoX1jNeQnFlv89e3EhDR6fwnZ2 RkFDzV1EDx4UivVqAANSUFBRUOyuAVEJVYNQU1B351NQXlJRUFJT71FRUFFQUFIyUFRQMlI8UEh7 QKZsrWxQb2xvbGFgQ0FjQezNrgFX0qguUFBRrwSuAVIpVYNQYVDnEEI2fVF+RjlEKUTZRFR6SVFU VlboUVEQWUJGREJCRnt/f+hRURBJTHBETExwSUxJUXFQUHZfcVxfc3F2UV3/XuxSO1BCUVFQVlJ8 EEBG6XBUUVTmf1H/z1D/UFJQ6FGk5X90/3Xme+pRUVBwUnzlTOl/f1F/6FGm42O5yEh7QKYNraS9 pLRApA20QKQNvaS9rbRQb71vvUJpf71pUUFp115+e14tQJTXXn5Ie14tQJRhYFANUQ0NUVdeUlJX XlJXVnNzZ2NiZmdmZ2ZnZmZndnZlZGdmZWR2c3NnY2JHRkZFRFdWRURGUilzHCMQGUJMHAducgFo ck8FG0dBcHlNdyoNHm99cGcIT3JnDnZrEXFgAFI081Ie3K7haAU4aV9YzXpidcftGTYsdHk5Dx2f wXdjfM1dRA4fEsy3aAACUFFQB1J9VAZTJVBGUAEQaSlC2UJSVFtbRkRbS0YmVdZVVnRbekZlW2tG FlsZRlZZK0AEUFBRUIBcRCtTBFxdsc9QUVBJRz3USHseQKQNHbVQf6S9QK0NpL1hYFENDQ1DZWZj YkZHRkZjYmZnRVZWc3J2dnNyVgc6/GzUKhUVcxHbZhDTAmw9vR8QIVJ9nShzZE1CHmuEbGZMOmdQ r6+vh1BQVL9WsVJ2UHRQUFFXUN5RLFEZUEcQXFJTUkFcUBh3UlNSQ+lRulB5UHtRe1Cvr6+HUFBU v1a4UnZQdFBQUVdQl1H3UVpQRuRSU1JLXOiv7ucYd1JTUk5SeVB7UXuvr1DqrgFViFWDUnZQdlBQ UVdQmFF8r6pQRONRUX5b6K9r5hh3UVFNWnlQe1F7r69QDFBQVeFXd1J2UHhQUFFXUN1R31E9UEfj UVFdVOhRhuQYd1FRXOlRulB5UHtRe1Cvr1A0UFBWXlahUnZQYVBQUVdQllGFURtQRRBaUVFEUmwY d1FReelRulB5UHtRe1Cvr1Drr7dWflaxUnZQYlBQUVdQ3lHvURlQRxBcUlNSclNQGHdSU1J06VG6 UHlQe1F7UK+vUJavtlZZVrFSdlBoUFBRV1DeUYJRGVByEERSURBLIEvQS8BLVEtXthh7UVJSTelR ulB5UHtRew1lZa+vUAqvuFRmVepSdlAUUFBRV1DdUIFQUFBFEFpSUWdKBRh3UlFm6VG7UHlQe1F7 UK+vUAqvuFRmVepSdlAUUFBRV1ATUUFQUFBFEFpSUWlKtRh3UlFp6VG7UHlQe1F7UK+vUAqvuFRm VepSdlAUUFBRV1CVULNQUFBzEEVSUGpgalJ/arBqoGpTakrpGHtSUWrpUbtQeVB7UXsNIWVQr69Q Cq+4VGZVyFJ2UBRQUFFXUN5QgVBQUEcQXFJTUmhKUBh3UlNSaulRu1B5UHtRe1Cvr1AKr7hUA1X3 UnZQFFBQUVdQllC/UFFQR+NSURtK6K/X5Bh3UlEb6VG7UHlQe1F7UK+vUAqvuFRmVY5SdlAUUFBR V1CXUIlQUFBJ5FJTUhJK6K+W5Rh3UlNSb+lRu1B5UHtRe1Cvr1AjrjlURlRuUnZQFlBQUVZQmDVC UETjUVF+W+ivMeYYd1FRTVp5UHtRe6+vUDqvuFQRVepSdlAYUFBRV1DdULJQUFBFEFpSUXRcBxh3 UlFz6VG7UHlQe1F7UK+vUDqvuFQRVepSdlAYUFBRV1ATUUJQUFBFEFpSUXZcuxh3UlF26VG7UHlQ e1F7UK+vUDqvuFQRVepSdlAYUFBRV1CVUKBQUFBJEFxSYHdRd1zkGHtSUXfpUbtQeVB7UXshZVCv r1A6r7hUEVXIUnZQGFBQUVdQ3lCCUFBQcBBCU1LQdY91r3VTdVxXGHtSU1J36VG7UHlQe1F7DWVl r69QLVBQUptV6lJ2UJRQUFFWUN2BUFBFEFpRUVVR3Bh3UVFU6VG7UHlQe1F7UK+vUC1QUFIrVepS dlCUUFBRVlATUVBQS+VRMFdRV1HoUXDkGHtRUVfpUbtQeVB7UXsNZVCvr1AtUFBSqVXqUnZQlFBQ UVZQlY9QUHEQQ1EfWFF/WG9YoFhTWFGNGHtRUVjpUbtQeVB7UXsNIWVQr69QLVBQU1ZVyFJ2UJRQ UFFWUN6RUFBHEFxRUlJWUTMYd1FSUljpUbtQeVB7UXtQr69QFFBQVBJV9lJ2UAFQUFFXUJZQjlBQ UEvlURB9UX1W6K6m5Bh7UVF96VG7UHlQe1F7IWVQr69QNK+4VAJV6lJ2UAJQUFFXUN1Q7lBQUEUQ WlJRclQEGHdSUXHpUbtQeVB7UXtQr69QNK+4VAJV6lJ2UAJQUFFXUBNRRlBQUEkQXFLQdFF0VLgY e1JRdOlRu1B5UHtRew1lUK+vUDSvuFQCVepSdlACUFBRV1CVUIBQUFBPEEFSYHVRb3UfdVJ1VMYY e1JRdelRu1B5UHtRew0hZVCvr1A0r7hUAlXIUnZQAlBQUVdQ3lDuUFBQchBEU1JgcxBz0HOfc1Rz VFoYe1JTUnXpUbtQeVB7UXsNZWWvr1A0r7hUAlX2UnZQAlBQUVdQllCUUFBQTedSb2YfZlJmVOiv CuQYe1JRZulRu1B5UHtRew1lUK+vUNCvuFQmVepSdlAIUFBRV1DdUL9QUFBH41FRS1/oUW7kGHdR UUrpUbtQeVB7UXtQr69Q0K+4VCZV6lJ2UAhQUFFXUBNRR1BQUEfjUVFNX+hRmuQYd1FRTelRu1B5 UHtRe1Cvr1DQr7hUJlXqUnZQCFBQUVdQlVCNUFBQS+VR/05RTl/oUcLkGHtRUU7pUbtQeVB7UXsN ZVCvr1DQr7hUJlXIUnZQCFBQUVdQ3lCHUFBQRxBcUVJSTF+qGHdRUlJO6VG7UHlQe1F7UFBRUOqu 81T7VfZQW1D9EGgXUipY1lL3VvtY6lPqWLtTulhZFFAUW1JRUllQVVRTWFBVV1NYW1ZaUllbVlZb W05QVURQUFVQW+hR8hBhVXhYUz5ZUoVWVnhVUFj/WSxaWlZAWz5QU/9SLFFRVUBwUFFQ9VBceFVA UFBcWjLYSHt7QGxRf3tse0CQUaYNe2xsUUCktECte2xsUUCktFBve2xQQK1srWx7QK1sVdd+ey1A lF9fX19hYFANUQ1RQ3FncUNjU3FXcVNRG6+uIE9RwAnlCVHdT64jr67zVJLGUfuuBcarblBSUNBT +FL7VYNQW1BHUGjlX3dQWVFZ6FLwEFpFd1NRQndfVlFW6FE25Vx3/1BRUOhRE+NICxJIe0CmDb2t Db1Qb72tDb1hYENkZmNiRkVEVnNydmdERmNiZmVkdnNyVtDzIiTy8yMi8z0zFhUzMxUWM1TuI/Ly IyPz8iQWMzMWFjMzUFBSUMquOVRtVZ5QcFB4UKAQ3mdxFnH7XOpBVFZxUVZbRltGdXlU9ktVW0JD Tk9PWlBYcXJwcFlycU5DQltYUFhfd1BOQ3FJRUJeW1hyWk9aWU/bcFlEcHBZT3BPcHdSWVpeX3BM T1pZVl90XgNycFhJdEhITlhZUVZXWFdOW0VwTFtPXkgISaBed3BQUkBSUlLdeV8IUF5AXlJeknrd bkh7HkCmDR29HkCkDR29QKS9UG9vvW9vb29BQml/tEC9rbRBQmlBQmlRQUJpaUFCaWlY1357WC1A lFBBQmlCaUFCaWlCaVFBQkdpV0BsXmxVbF5sV0BebGxsbGFgUQ1QIQ11dkFkQnRjYkdDR1NGRkVX dnZ3UUZjYmZnR1ZWc3J3U3dDUXNyVlJFRFEC6NpRUvROT/g68TA14lF2e67uR0MI8X7lFKvwf3/z PLBRakAgzwtLPFFa/lEA/1RRxH2uK3nwJVwQA0+spFTW2UOXkVquJ39STFKl2662Ld1QUFFQEK+3 VIxVg1BmUPMQE0Z6XUFkWWbbW1JzUXVQQ0dEWltYT0xOVllaTU9OTllZQFB7BHV8/3V+ZCdQeWJ+ flBbRMBHfkBRfMBNRHDAQ1FDLE3oUaDiSh5d6FIO41lwYlbqUVVQWVJ8EF1PUX9Rb1FTUUlnJdpI ex5ApA0dpKS9QKStpKQNvUC0UG+ttG9sQL1ApL20QLRBQml/bECtbFFBR2lQQUJpQUJpaWFgUQ17 R3dmZ2ZmZWR3c2djdmVkUGNiRkdXdnZzclZFREdxV3NHRFZXZmNiRkZjYmdHVnNyd35Sc3JWBUU+ Am5oVI1P/UJRRYD0vkb1X905LP5EUXJwq1EPJWZIAQ3zZyE8Zsgje3xw3jNoBdlJ4RcNFvBsXXDH 1wyTUVuRlEHQ1evyFyzHfDecCFdfZ2/zGlpYa0Z6UFBSUG6uAVQhVYNQZFATUP4QY2p7bGYfYztj VGB3FGX4ZfZtm2VVZVdEbXNGfH9XbWV8d3VEW1cTdndeVE1aUMtRVH5iTehSzBBETIBwfklRW0lR WlpiX1FwUFBBFE3oUVEQXExMeRVXYn/zFXNiRuhRvxBeFGhieWwVb2JBSRQ9Ekh7HkCkHb1Apr1A pr1Apr1BQml/vUFCaX+9UG9vb29Ava20QL1AtEFCR2lHaVFBQmlBQmlpQWlhYFANUQ1HZ0ZGY2Jm ZWR2d3Z3dnd2dmVkZmd2ZWRmY2JGR1d2dnNyVkVERkdGRkVEVldGRkVEVnNydlFmZmVkdnd2d1ZF REdGR272SMc2My9KSnWvNXNlfNDMH53o/utM5VEkNQwkHcOGI9neYmKH6f+5Ujo8DHsr+BWSRU8j Cnoo0CQaT21PfZwAd2o1ED31HjA63O3w40U2IToYZCwn/cAMD+QTZyJr0pPnUYFiKWZ7FzXbHT7X eXZlDVBRUD1RgFI4U5tQW1B56VBTUTAQQFldR0dKVoPPUFFQSVw9I0h7HkCkDR2tHhU1FLZQfx29 YWBDZGZjYkZFRFZzcnY9xTg5xcU5OMVSnjnExDk5xcVQUFFQ3q45VLBV6lBfUBPjW1xRX+hR8xBO UYtXWV5yWFdQWeZbXVxyWlvVQVSFX+lRUUBBz+dIe0FCaX+tvUCmbK1sQLRQb2ytbEC9vUFpaWFg UUF2dmVkZmNxRXNBc0FzQVJy64mhuFIpwPqPrjlURVqP/ZG1/akMVvSpDFBRUBqvt1TaVYNQZVCQ EH90eHZyWFtfel1BQ3BaWHp5eHRyQV9bWlh9TWRlZXNQUURQUFF9T1VRUFpNT0dbSuhRZhBcSUmc UFlwcEMkWHB66FJ3411wdnboUZEQTVlkZFllZQhQWVFRWVB/UG9QUlCgZllRQFBHm7pIe3t7bFF7 KkCgDVFIf3tsUX97KkChUUh/e2xRf3sqolFIf72kraS9eypAoFFIf71Qb71vb73XVX57Xi1AlFBB QkdpUUFCaUFCaUFCaWlCaUJpaWFgY0NuUmNiRkVEXlJFREZHRkZFRFZWc3J3Z0ZGY2JmZWR2d3Z2 ZWRmZmVkdnNyXlJXVldTGoh0JbIvx+JlzXZLBCpkNZA3hN7IYzJiA9RyKQh9bZIEF301HGRDWUWE VFn8/iDGBWIomB1wTWEHLTdsAvc0uwIyF9MbcWwmBwd5YC6iE3wWc2gUZkk2rFxQVFBTr75VuFWD UF9QT1BmUBBQmRBmeXhRCX0MYaRiU318fH5gYX9hf396fnxEfn58fXx7enl4YGFiY2RlXGZ+YGFi Y318e3pYf3ll6FJl5WdnZhCjcehS2edAelBTfn9mcOhS2RBcSHpYWX6Sa3rPdlF26FJj4kx6VOhS ZBBcRBB6cWZ6cHBwcVFx6FJi5UR6XEkREuhRyONxJthIe3sepB2tpg1sQL1AvUCkraYNvaRQb62m bGxsb62mrUFpf71pQUdpUUFCR2nXfnteLUCUV15sV0BebGFgUQ1QDVFiVEJFRFJUc3J0UmVkQnRH clRSRURCVGNidEJlZFJ0UUFxYkZGRURWV0ZHRkdHc3d2d3Zzc0FBY2JmZWR2dnNzUqbuUTqal67J lJSuyZibUTruz66D+vdRfPPzUXz2+a6CrkdRR9/QHC85e0phFzPwGAVkdBUdzyIDeBcwxVWDk67F lZOuyJeXUTiTlVE7ky3zroH0866F9/dRe/P0UX/zq7lTfH0gbwnUWEJJYCHP0Md2TK73UZkUaHRp TFBTUFOvvlW4VYNQX1BPUGpQJRBeEnEcflJwcX9+VGhiT3voUsTmQHpQUWhPdOhSxBBOSHpYW396 fjZwenFxTHd6/2XvZVIfZVFlZWBETHpU6FJf5UR6XElrbOhRyeNxJthIe3sepB2tpL1BQml/IQ29 Qml/vaS9UG+tpr1vraa9QUdpYWBQIVFiVEJFRFJUc3J0UmVkQnRHclRSRURCVGNidEJlZFJ0Q0dW VnNydmVkZmZjYkZHV3Z2c3JWRURGY2JmUqbuUTqal67JlJSuyZibUTruz66D+vdRfPPzUXz2+a6C BCtOk9vgjDTpJ9XgcCdOJR8jxd0gCthVg5OuxZWTrsiXl1E4k5VRO5Mt866B9POuhff3UXvz9FF/ 861AdC3FtJrUkzMvPU0aH/TJyc04UFBSULFS21anVepQV1BEUMsQTGxbHVtSW0FCX15XUFRCQUBb VERDVFJEWItZUlXoUWkQXlRdXFxaWllZVFBdXkBe6FLW5Q9fP19SX+hRpuRBHULzROhS1hBcWFgA WTBZUlnkVcBX6FLW41DAUlPoURPmRUa1cZ22SHt7pmykraSmDWxAraampg29bEBsUG9sQGxAbEBs QK1sQK1sQUJpQkdpR2lRQUJpYWBQDVFBcWVxRXFBcUFjQ0NjQXNBU3NTQVG5rqhSyq6mUTWYnpeU LIIri1LbUuYpKa0aU3+tJVLbrIFS/K0EUuatGlBRUQpU91KqVepQU1AVEEQGUzdSJ1JTUFNRU8FR UVJQ0FJRUuhSVxBf31FRUcpT6X9Q31BSUElU6FEe4dhIex5ApA0draYNrQ1Qb2xAvQ1hYFENUUNj UVEK7LSuplT3UUOuvVBQUlC9VJtTFVXIUFNQV1BoEFlUUxVVUlBWy1foUVHiVctU6FIy5VLLU1HL U+hRUeVQ81idKkh7QKa9tEC0prSttFBvbK1sYWBDZ2NXY2djV7177Xvke+x6VJudnZ2dUFKv/VBQ WAlV6lBfUENQqhABcFZwV3BacFv3VFVVWFlZVF1BQkJcXkBDX1RCUXhDX19OUFFEUFBRVFlZTlxC RFxcQkNfUVNFRFdYcVZVVVBTQ3FSUVJAQXFdXX9eb14vXlNe6FHrEF9fWllxXHhbX1x4UFhbklro UsYQXFeSVpdTklJKRVRAWehRV+JCQFztUYVQQ1GSUF9QUVGUEFtfClBJREJAXLs7SHt/e2xRHkCk Hb20QLSme2xRrXtsUR5Aph2kpKSktFBve2xQbGx7QK1QbECkDWxArWxvbK1sQml/bK1sUUFCR2nX fnstQJTXfkh7LUCUe0FpaddVlJRXQGxsV0BsbGFgUQ1zUXFXcVNxV3FTcVdxQ3FTUXFDcwNT1lV2 c61cD1Ktc61TO1Mdc6u1CK2aqlEPUaPGg1Xq965o9q5R9lHyrg5SGFKbUFBTUP6vyVZmVk5QS1B0 UH5RSRDOQgZLNkslSyZMKH7IXFZZV3lUdUJnXhdyVWlQpkqkS1MPST9JLkksdYd2VVZbW0h2V3hF H0gWdFZeXl9JdXV+dkpKXVBQUVtMTHRNS1x2dU1JW1VzfkB9UX9SX0BgdFJzTllPd0h4R1pPWUlL dnVNXlBVeFtdT1xLXF1LekpdREpKXUtKXWBAT31ZU11TeH1HSpdLMEdZc3pSSX99ekDor5DjS3Fk QOhSxuNgZAFIe0Cke70eQKQdvVBvpLRAvW9vvVFBQmlY1357WC1AlFBBQmlCR2lBaUFCaUFCaWlB QmlRQUJpQUJpQUJpQUJpQkdpV15sWGxebFhsV0BebFhsXmxYbGFgUA0NUSENDRMMCONMWkBlUXsJ dXZBZGdmZmdmY2JHZ0dXRkFEV1ZWV1ZzcndXd1FRdnNyVFJFRFFRRmNiZmZCZWRRBcoZbJMjyeCy zPAJ8soFEZghxviEz/EPUXBSqiLCw66+9FPPrVgpxSGc8Q3/51FK7/7AgWkcJZAfk+CusZ/m25dn GCWTH1EIU8IO/q7ikOlS7qw+DjvvUUfX+VBSUB5QUFRGVJ1QW1BfUAAQRF1eUFJcX0FYVixYUytZ Uix/W1Fb6FLQEERfXitcXVpYLFZbcFVQLFJJQM8jSHseQKQdpGytbLRQb2ytbKYNpGytbLRRQUJp aUFCaWlhYFFBcWVxQWNBcUVxQVFxZXFRja4hUd/6Ud+uIVHfrGhTmFFUUcP3Ud+uIfeuPa6s+FBR UBtQUFUGVepQTFFcENlGRAlC9kDyQVRTVldXUltcXV5fX1pAQUJCX0ZJSkpFUVJKUFVUU0lQVUhT SUxHS1JKTEdFRk5XVlNSVE1JSk5fVUdXVnhHTExOUFVEUFBVX0RDX1pDTkJfREJCX1lYWE5fWkRf X1paWV9TTk1KUitJU6xGVitFV1dQQ0JaWVBMeFBaR0BMK1VAUOhRAhBZTV9fTU5VQFAm6VFWUEh7 f3tsUUlBQml/SECme2xRrXtsUG97bFBvbGxsQml/bK1spmytbFFBQkdp1357LUCU135Ie1jXLZRV 135Iey1AlHtBQmlpUUFCaWlCR2lBY2NfX19fV0BsbNdAXpSU10BelJSUlFdAVWxsYWBRDXFDcWdx Z3FncVFjQ0ZHRkdmZ1FjUXFXcVdxV3FTUfAUrjdNUclPrjdMUQiuv+YkA1dLX3kIUQ2wrbRRHk2u Ok9Rxk2uOhRRF9rD2lKcrpWzQx1oDSlRsK1k2sParulQUVBcrjZUw1R2UEdRURAOSVBJUVI5WDxB OUQsWCpB3UFWblhtQR9YHUEaRAxYDUEJRFhAW19fXEVSVEZGUV5dXXNcX0RcXF9RRkZzR1BER0dQ QEVfRkdeXFFQXVZ4V09CW19eWkdIeFxfUEdASe9RrlBcUF1R6lBeUWZQXFHq53BfUV9vX1Ff6FHv 4kdZUehScuJGCFDoUnIQQW9HUX9Hb0cfRw9HP0ffR1ZH6FLCEFtIX0dHR0dIWpsPSHt7QGx7e0Ck DSG0rbR7KkCgIVFIfw20rbRAtHtAbEBse0CQUG9sb717b2xsbFBvbEFpaddVfnstQJTXfkh7LUCU 10BelGxs10BelGxhYFANDVENUWNTVkVERmNiZ2ZnQ2NTc2dWc3J2d1NzURPjOnc6DCsGEHwo47Lx QtjSGj9lPOJUdq5d5hkANQkUnlJsq4oEPWwRrlJQUFJQ91KwUxZVg1BzUH5Q6RAL+U1RRXBcXmRE cFxeZEtES0WYdlNbRFtFekR5RflR6ESNRI1FWERFRVxZdnl0clxTXlBNcUtgUHJ2dE5NWVV8TEVE U0FaWnJBd0hTckR8d1NERX5PRN9Ez0RTROhRGxBOXlZ+z3lReSFQfk9Lfl44f09vT/9P709UT9Vg PdhIe0CmDa29QK2kDb1Apg29UG+9b2+9Qml/QkdpQkdpQWlRQUJpaUFCR2lCaWlXQF5sYWBQDQ17 e1ENUVZWc3J2ZWRmZmdmZ2ZlZHZzclZXd2ZmY2JGRURXVkVER3N2Q1ZWV1ZFREZjYmZSIHbSEDgp FdnYOBVfGRBrM0rdf8ws2NxmTUTaV0lni3N0bWAC0FNncmUmBxE+Z1hWQHxFe21sbEc4IiQDHZc6 Z2t3R1FjQERNTXl4aCFQUlDfUrJTG1WDUF1QTFBkEE06UzVZUklPVFNCT1pERk9XSk5eT09QUVBJ Tc/lSHseQKQNHb0eQKYdvVBvvW+9YWBRDUNkZmZjYkZFRFJzcnZ2Z0RHRmNiZmZlZHZzclZW3wDn LNv+luI2yhTDcGABZyIbDxZtIxBUfB6b3v/Zxq6NAtkkDnwSGc0BADQFxVBQU1AHr7dWvFRvUGNQ bVAbUU4QX2ljH27WV9liVG5wQEFkbOivhuNAQWRt6K+G40BBZGDor4YQBV9BZBtwXkFkaXBeQWRo XzkaPBsmV1R1QnRDUhsRQ1dURhVzZWd8bhBaSURBGHBXG1Fhc2tNbhAQfEFEREFBREx0T01RTQJJ T3B0a091V2VkfHxQdFHoUlgQRHt7fHxadWFPVBhPVHRaW1AIUSR76FLCEFlncHlKHWRwRnzoUsIQ XH5wUEZRRkYcHUwITehSSecVcF1JHHZuSHseQKQdvaS9QUJpfw2ttEC9HkCmHb2kpL1Qb7S9QL1B Qml/bECmtECtbG+9pL2tDbTXXn57Xi1AlFBBQmlBQmlpQUJpaUFCaWlRQUJpaUFCR2lhYFANUQ17 e3t7e3sNUUdWVnNydndWVnNydmVkZmZnZnRnZmVkdnNyVld3ZmZjYkZHZmNiRkZFRFdxVkVERmNi ZlFxZmVkdnZzclZXVldWV1ZWRURGY2JnZlWq5wep9iSZER+HIPDgHCUObFEbGEcwDiLDd+Nkpeo8 9mncgSuRNl+sq1TUNgr2rm1SF1FrIxI3mKs6ySF4bm81DSgCOlE3QeXpIiorIvrcB9oXQ1xLRhhj GggyNl/L+xkZwT+CKmwyTk7GxyNR0XFaANIV+6pJXlpeRQNvADIEPlBQU1DDr8pU9lTXUEVQTlB4 UV8QPXtae1twRWxbYUUcWxFFVyle2F70UfRe5FHkXpVRV3V4ZngXeDlexFHEXpVeV0RKS3NSU1t4 T1xcUl5QTkZdUlxc211RRF1dUU5PRnhUdlxeW1NMXVBRdlJSUVBTRHhGTk9IXltxXVxxT1lIT1Hr UsdQRFBcUsflWURXWVtS61LCUFVQXVLC40B2cFXor5AQdExxZFBVQFVwVRBVP1WgVVZVSnpMcGBA EEAAQNBAVEBAUUBJeehRU+E1SHseQKQNIR29HkCmDXsdvUC0QKRQb29AtEC0vUC9QmlCaWlBaWlp aUJpaUFpUUFCaWlBQkdpQUdp115+ey1AlEBsbGxsV0BebGxsbGFgUQ0NDVANUWdHV0ZFRFJUc3J3 V3dndmVkQnRjYkd2c3JWUkVER0dGY2JuUmVkd1OLIAslDcKuvsfYPCIKIzXGUVrz3FcRCTfmOnEa EQMa1SQUTlOq3RjDJevgrpX5b90VwCTt/1EZ9pBk1K6o1DURCn4YwYkOBBVQUlAkrgNTvFR2UFNQ cFAnEGNmVhlAB1g3WCRY1FhWZFdjWBdWFVcVWFVLTE1ZWFVCUTNQcHBCUF5PRV9BJEJaUFZJcFvo UTMQWUFSM1EkVEEIQuhRkeZyVHBwcHFy6FFT4cZIe0FCaX+9QKa9QKS9QKa9UG9vtG+9QUJpf0C9 QkdpYWBRDQ1RV3NnQ1ZWV1ZUVkVERmNiZmdHVlZzcnZ2ZWRnZmdmZmdTzHudeyRabxF1rrYD1Tgj x0nle6fhKJc2Gmfv1B9BVHadna7BC94Ze7XdawAqwPhOhoQy+Qw+NhzJOSgzUFBSUG6uPFJpVHZQ U1BZUAgQRWdVUVZQV1NVUFZYU1ZXWaxSFVNWWehRoxBGVFRTViFQFVchcFNgU1J/U29TgFNTU+hS XuNaashIe0CmDSG0rbRCaX+9UG+ttn9sUUJpQUJpV1dhYFENUVdzZ0NTU3NDQ1Jpe5x7Cj9ujBSE VHadna7erLSuhFEVU1NQUFFQIlH4VGpUVlBVUHzpUFNRaeRULVBSUehS1udVUEpXU0lWMulSK1BI ex5AtECmbB2tbFB/rb1hYFFzQXFlcVRq+qyyU5hR+FHm+FBRUH6uAVRtVYRQcVCTEDcmTtRPUlFZ WVBXWltbVklMTUhQUXJMS0laWVdWWEJDc0pQcFFYU0NZQkBFSE1Nc1ZbRFZWW01IW1ZUSlZNWFNb SFlFcEBRS0xMV1dYfFlKSUlaWllWU09wX0pKc0BYP1jfWFNYSXJz6lFFUHFRHeG3SHt7HrQNQLZQ bx29b2xAbEBsQK1sQGxAbG+9QWlpQUJpaVFBR2nXXn57LUCUUEFCaUJpQUJpQmlRQUJpaUJHaUFp aVdsbFdAbGxXQGxhYFENQ2dGY2JmZ0NzZ2NnZmdmZmNiR1d2c3JWV1djV3NTVlZzcn5zNWNmakDh mUiZSEZHTyMNANdzN2NoaENDnEmc70oqIA6uO8tGaDBUQtzVKH1uFnbJSGc5N9yr7MQhUFJQ8VAY VBxThFBVUFtQNRBPN1A/VD9VN1Y/Wj9bVlpfVE9UUlTsWFFX6VjVVlvpWuxRplBWUVFQWVGmEFlQ UahSylBVqFTqUaZQUFFR41NJXD3pUitQSHseQKQdraa9QKa9QKatpr1Apr1Qf2ykDWxhYFENUUNz U1FjQ0NzU1FjUQ7P2IRRwd94zMKWUdTLUl+uaVGNUf+ua65pUY9R/VBSUANQGFRaU4RQVVBbUAsQ QjhQOFZSV19RT1FSUexbVFXpVOhRpuVQUelS1VDqUVFQU1Gm41Zb6VroUablVleoWNVW6FFR5VlK XSYYSHseQKYdraa9QKa9QKatpr1Apr1Qf2ykDWxhYFENUVNjQ1FzUVNjQ1FzUZLEwJCuKPNSpsXY nq45wFJZUZuuTa4HUelRg65LrglQUFNRdlBQVyZQnVBTUFdQW1AEEERaVlZSFVNYV1dUVFNaWstb FVnLWOhSDedUVstXFVXLVOhSDRBdUFLLUxVRy1BJXJ24SHseQKQdtK20QKS0rbRApLSttFBvbEBs QGxArWxAbGFgcWdjV3FnY1dxZ2NXUXZ7nXxRsHude1Gwe5x7nZ2dnZ2dUK+vr4dQUFS/V3hSdlB0 UFBRV1ATUaFRPlBFEFpSUUJcjBh3UlFC6VG6UHlQe1F7UK+vr4dQUFS/VqFSdlB0UFBRV1CWUdNR G1BH41JRdFzorzTkGHdSUXTpUbpQeVB7UXtQr69Q66+3Vn5WoVJ2UGJQUFFXUJZR71EbUEvlUm9l UWVT6K8H5Bh7UlFl6VG6UHlQe1F7DWVQUFJQ9K+2WApVg1BJUH1RVhAKX3NPcU9yT3NPdFVrX2NE GV/7X+ND4ERWQkVGRkFQXUlJXlBKXUV/c1BOSV1CQUZGTkleRElJXkNCcUVFRERJXnZ9WlNAQXF4 X15STnpTR0ZxeEhJWFNZSJJH6FHW40lEkkPoUUcQXUJ6c5dFenFxQElfkkDoUUfjQUFARuhRV+VP XlFeQEnoUe0QREp6X1ZPVlJWSX5zc35/XkBJmDtIe397bFFBQml/HkCkDR2tpntsDVGte2xRQKS0 QHtsUUC9pK2ktECttFBvb2x7rVBsQL1vbHutUGxvvUFCaX9sQK1sVdd+ey1AlFBBaUFCaVFBQmlp QmlXQF5sbFdAVWxsYWBRDQ11VlZzclBBZEJ0Y2JGR2dxV3FTcVdxU3FXcVFERkZjYmZnQmVkdnNy VlZXVldWU68YzT24ro+dUQXnIZMWdFNvcq3UMVLSc60vOlKWc6wmrS0c9zXetGgW6NYd1yd+bXRg PBQSUW1Rfa5R/Ik2Mf73rmH3rln2Ujfs6TmCoFF9JNvpazsVCz/HUFNQ0a+4VwpUblB1UGRQbVCu 5U1wQEFkbOivsBBZQEFkf3BfQWRi6K+w419BZHjor7AQWV9BZHtkXkFkS+ivnONeQWRt6K+cEHle QWRZVERid20nZdt6+ELmX5ZfWHt2UF1JfWVtZkdQe3BMXW1rZU90cOhSwBB4RmZlfEZHR1NgT1pr T0FBWld5T1NMT3NzU1tPcHAkRnZwQFZRVkluZuhSwuJocEboUsIQWVBEQERSREpvR+hSwhBZSU99 fW5vaG5Ie0FCaX+ttB5Apg0dtK20HkCkDR29QKS9UG9sQL1AvW9sQL1AvUJpf2ytbECmtEFCaWlB QmlpUUFCaWlBQmlpQmlhYFENe3t7e3t7e3t1VlZzcnZlZEJ0Y2JGR2ZnZmNiRkVEV3FWRURGY2Jm Z0dWVHNydlFERmNiZkJlZHZzcl5SdXFmZWR2c3JWU5UImdGQssFRU84qkmcOFD/U57hCrK9TJiYJ +GDrGq6iyCTsrWbWPTHrNykrA8M8YFNjUhVT1Tsz7ec2ObiD5lFr+jgwNHZuv5gDAHRwIOTTOUH5 ljVRD/HH3lFKKj7/BvGI209B1t7OUFGvrFGaVD9SC1BTUE3pUFFRaRBaUFJKVVBJVMkSSHseQLRA tlB/Hb1hYFNlcUVUVCNRmsHBUFFQUFGaWFBSC1BTUEjpUFFRaedQUlVQVMkSSHtAbEBsUH+9YWBB ZXFFWFBRmsHBUFJQiFONUx5Vg1BZUENQJxBGelZ5QFJXVkFAWVBSQ1pcUlAVUVc6UehSyRBaVkNa FVtBOkBcW+hSyRBLQEBWUVAVU1EVU/9SHVtaFV1bFV3/XElEICpIex5ApB20vUC9QKa0vUC9UG9s QKRsQL1ArWxAtL1AvWxRQUJpQUJpUECZQJlhYFENUVdzZ2ZmZ1dWV3NXc2dmZmdXVldTQHuednHf MUAleZ97nnZx3zFAJXlU+p3k8cZbH3DqneTxxlsfcOpQUlCGU+5TB1XkUFlQQ1DNEHJ1VnVAZ1Zm QFRXVkFAQ11aWVNQQl9eU0BaWFVUU1ZQQDpB61LSUFpQXVLKEFtcQ1oVXFtbUlY6V+tS0lBQUFNS yhBIUllQFVJRUEXmXf9cFVv/Wh1T/1IVUf9Q6FET40QgKkh7QKakrbSmpK2ktFBvbK1sQL1Apr1A bEBsrWxAvUCmvUFCR2lBQkdpUUFCaUFCaVBAmUCZYWBRDVFnY1dWVldnZmdjZ2NXVlZXZ2ZnUUR7 nnVy3zFBJneKe552cd8xQCZ4VLed5PHFXB9x6Z3k8cVcH3HpUFFRWFONUm9Vg1BZUAwQRHhWN1gm WNVY+FXqVZhVV1dWWVBT6FLKEFpSUlFZUBVRVzpR6FLJEEJWUVs2UVAVU1EVU/9SSVoL50h7HkCk HbS9QL1AtFBvtL1ArWxAbEC9UUJpUECZYWBRDVFXc2dmZmdXVldSUXuednHfMUAleVT6neTxxlsf cOpQUFFRUFPuUmdV5FBZUAkQQXRWZlZSV1ZZU1hVVFNQVjpX6FLS41AVUVPoUsoQX1JSUVBbR0dK U/9SFVH/UOhRG+NaC9pIe0CmpK20HhU1FLZQb2wdQL1Araa9QUdpUUJpUECZYWBRDVFnY1dWVldn ZmdRbnuedXLfMUEmd1S3neTxxVwfcelQU1AeUW9URlQ3UFNQV1BbUA8QWlBRWVJTVFtRFVDoUtPi VnBV6FLT4lkVWBFZUs1QXFBSUTpQVlJBUFlQVFJB4lsVWehSQRBZz1VRVUlczyNIex5ApA0dpK20 QKS9UECmraatpr1RQUJpaUJpaWFgUVFlY0VRcWVxUWVjRVGbnVEurGhTmK3lnVPKnZ2utfiuSJ2d r69QUK4BVC1VyFJ2UAxQUFFXUN5Q+1BQUHAQQlJRcEfQR/BHU0dd7hh7UVJSSelRu1B5UHtRew1l Za+vUL9QUFZ/Vo5SdlBsUFBRV1DeUcBRFlBMEF5SUS9fUV9WGhh7UVJSQelRulB5UHtRew1lZVBS UBpQu1RxVJBQS1B3UK0QfPhU9lb2QvlE6VTmVudC6ERYWEBeX0ZSUFFHX0FAWVFTUkZxQGBAEEAA QFRA6FLF4kNBRehSxeJPcEPoUS4QXFVYflJvUh9SD1JUUuhSxeJVV1PoUsUQS3VwVXlHR0pcWX5f b18fXw9fVF/YcnBe2FrYXOhRLxBiTHBKR3FRYFEQUQBRVFHYSNhQ2N9Kz0r/Su9Kn0pVf0pvSh9K D0o/Si9KVkpJeFVXeHnsUS9QcVAgUitQSHt7UG9RHkCkDQ0dtLSkDWxAva20tL2kDWweQBU1FLZQ HUC9pGxApA1sQK29pGxApA1sQUJpaUFCaWlRQUJpaUFCaWlhYFENQ3dnR2ZjYkdnR1dGRURXR1d3 VnNyd1d3Z3ZlZEdERmNiZmVkdnNyVoXbI9s609Q52yTbFxfbJNs51NM62yPbF/PIOzvIxzw7yFOR 2CfbGBjbJ9g+LS4+2CfcGRncJ9g+Li0tPMjIPDvIyFBQUVAxUBhS01OEUFVQFRBAOFQoVNhUU1NQ VV9UT1RSVOhR0xBCUVJV6VTKUelS1VAVf1NRU+RW6lExUXdQSHtApg2tpq2mvVB/bK0NbGlpYWBR DVFDc1NRY1FI8NifUd3FUl6ualGNUf9QUFFQcVAYUh5ThFBVUG4QXzdUJlTWVFNTUV9ST1JSUuhR 0xBAVVRV6VTKUelS1VAVU+RXC+lSJVBIe0Cmraatpr1Qf2ytDWxpYWBRDVFTY0NRc1HbxsGYrj/M UltRma5xrgNQUVBbrvNU5VX2UENQoBAcElAQQ1J4U3hXF1AkUiFWKFwnQtFWtllZUVJBUFlUU0BQ WVVWXVBZWFdcUFlbV1xDWl5WXUNaX1NAQ1pCUkFDWlpDQ05QWURQUFlDUOhR8hBeWXhAUz5BUlpc V11XPlboUvAQcVlQXP9dLF5eQENX/1YsVfFRQSxCQkBDU/9SLFFRUFpAQ+hRURBFWUBPUHBQUlAh UER4WUBQUERaN9hIe3tAbFF/e2x7QJBRpA17bFGte2xAbFFApLRAe2xRQLRApKS0QHtsUUCktFBv rb1sQGxvbK1se0CtbFXXfnstQJRfX19fX19fX2FgUQ1QDVFDcWdxQ3FncUNjU3FXcVNxV3FTUR0e riBxUd/JriFxUd8f5R9R23GuJclR23CuJR6u81ElzVKMzVEortjNrXTNrttQUFFQ6VI7UdZTaFBT UEgQW1EVUFKZUElUMrhIex5ApB29UH+9YWBDZWNF6Z1SO52dUFGvoa6IUXhQnVBZUBwQQXVXZVdS V1ZZU1RYVVNQVjpX61LSUFBQU1LKEEJSUlEVUFpT/1IVUf9QylomuEh7QKakrbRQb61sQL1Apr1B R2lRQmlQQJlhYFENY2djV1ZWV2dmZ397nnVy3zFBJ3ad4/HGWx9x6FBSr4iuiFIFUJ1QWVBDUMwQ cnVWdEBnVmdAVFdWQUBDXVpZU1BCX15TQFpYVVRTVlBAOkHrUtJQWlBdUsoQW1xcWxVDWlpQVjpX 61LSUFBQU1LKEE1SUlEVWVBaRR1d/1wVW/9aHVP/UhVR/1BJRDfISHseQKQdpK20pqStpLZQb2yt bEC9QKa9QGxAbK1sQL1Apr1BQkdpQUJHaVFBQmlBQmlQQJlAmWFgUQ1jZ2NXVlZXZ2ZnY2djV1ZW V2dmZ0Z7nnVy3zFBJ3aGe551ct8xQCd3nePxxlsfceid4/HGWx9x6FBXUNivmVhXVYNQXVBLUE9Q fVBrUBlQB1DHEHRMTx17BE8QiR1PF2hPdIlhTxd7TE97W0FPW4lIT1ROTU1UUU3oUWrkTk53ZU/o UWoQd0xMXlAJR0dKAX4TLRp+bORlfnctfn7PcFFw1UV+Vy1eflBJCM8SSHseQKQdva29pg29rb2m va29HhU1FLZBQml/Hb1BQml/vVBvbEBsQL2tvW9/bEBsva29QL2tvUFCaWlhYENkQmZjYkZFRFJW c3J2Z0RGY2JnZmVkdnNyVlZTUWNRUWRCZmNiRkVEUlZzcnZnREZjYmdmZWR2c3JWVlVkQmZjYkZF RFJWc3J2Z0RGY2JnZmVkdnNyVlbYC84gJtYM8zgn18FqYwtlEmxgZA8QAFPnyKwXUcQLziAm1gzz OCfXwWpjC2USbGBkDxBSTgvOISXWDPM4J9fBa2IMZBJrYWQPEFO1PlFQ0NsrIa6j0d3XBxQkwdcV EwuMq/ZWWamnUUc+UVDQ3CshrqTS3dgHFSXB1xUSCoxvPlFQ0NwrIa6j0d3YBxUlwdcVEgqMUK+v r4dQUFS/V3dSdlB0UFBRV1CVUdZRPVBxEENScENgQ1J/Q29DUkNc8Bh7UlFD6VG6UHlQe1F7DSFl UK+vUAxQUFXhV3dSdlB4UFBRV1CVUchRPVBL5VEfQFFAUehS5eQYe1FRQOlRulB5UHtRew1lUK+v r4dQUFS/V3dSdlB0UFBRV1DdUehRPVBFEFpSUUBcAhh3UlFf6VG6UHlQe1F7UK+vUAxQUFXhVo5S dlB4UFBRV1DeUfNRFlB1EFxSUV9ef15Sv15RXlHoUaHlGHtRUlJA6VG6UHlQe1F7DSFlZVCvr1AM UFBV4Vd4UnZQeFBQUVdQE1JHUT5QR+NRUV9R6FKq5Bh3UVFf6VG6UHlQe1F7UK+vUCVQUFNNV3dS dlB8UFBRV1DdUHNRPVBFEFpRUVVR3hh3UVFU6VG6UHlQe1F7UK+vUCVQUFMSV3dSdlB8UFBRV1CV UHhRPVBxEENRH1hRf1hvWB9YU1hRuBh7UVFY6VG6UHlQe1F7DSFlUK+vUCVQUFMfVrFSdlB8UFBR V1DeUFpRGVBHEFxRUlJWUTMYd1FSUljpUbpQeVB7UXtQr69QJVBQUulXeFJ2UHxQUFFXUBNQb1E+ UEfjUVFXUehRWeQYd1FRV+lRulB5UHtRe1Cvr1Drr7dWfld3UnZQYlBQUVdQ3VGLUT1QRRBaUlFx TTgYd1JRcOlRulB5UHtRe1Cvr1Drr7dWfld3UnZQYlBQUVdQlVGcUT1QSRBcUm90UXRTyxh7UlF0 6VG6UHlQe1F7DWVQr69Q66+3Vn5XeFJ2UGJQUFFXUBNSd1E+UEUQWlJRc1OGGHdSUXPpUbpQeVB7 UXtQr69Qlq+2VllXd1J2UGhQUFFXUN1RmFE9UEfjUVFKV+hRR+QYd1FRSelRulB5UHtRe1Cvr1CW r7ZWWVd3UnZQaFBQUVdQlVGFUT1QchBbUVBNYE1SoE1RTVfoUc7kGHtRUU3pUbpQeVB7UXsNIWWv r1CWr7ZWWVd4UnZQaFBQUVdQE1JUUT5QR+NRUUxX6FH45Bh3UVFM6VG6UHlQe1F7UFBRUC1QUFJA VHZQU1CCEEcEUjRRNFIhUSFSVVBVaFEYUQRR0FVVVeivkONxcmRV6K+Q401OZFXor5DjSEpkVeiv kONERmRV6K+QEHRdX2RSU1NzUFFEUFBRUnhRVlN4UFpSUllTUz5QWVFRWbBQUVDor5Djd3xkUOiv kONxcmRQ6K+Q401OZFDor5DjSEpkUOivkBBfWVpkUFBoVFlRQFBHaMZIe3t7bFF7Kh5AoFFIf3t7 e3t7IntsUX97Kh1AoVFIf3tsUX9Qb3tsUG97bNdVfnstQJRhYFF7e3t7ew0NY0NjUy2O5Y5UdquK UFFQnVT3U0pV6lBWUB0QT3dWZ1YVVgdWN1YoVdhVV1VUVVFUVvFVOlJRUFgdVVDoUVHkVvFUy1Xo UTfjVzLaSHtJQKa0pEi9SUC2SFBvbK2kbEFpUUFpYWBRDUNRY0Nzd1edUVmYLM4A9VT3UUOuveLi UFFQkFSVUzRV9lBFUAIQYGhcGlwIUT1dL11VQUBWVVRHRVd+XgRQRSdCflNQWlBH5Fp3X1tPW1Jb L0V3UElGMulRbVBIex5ApB29rQ2ttlBvb62kbKS9UUFCR2lhYFENQ2ZmY2JGRmNiZmdjVlZzcnd2 c3JWV5BxMRlxb8xNR3RcKVohGnht2nBwellUltULQBVxfjckSmx5fFBSURhUIlLkVY5QW1BHUHji WeJf6FLE5kXiU1FW4kLoUabnXOJQ9UifEkh7QKatpr1Qb62mvWFgUWRmY2JGRURWc3J2Z0RGY2Jm ZWR2c3JWURg7Gxw6OxsbOxtvfH1vb318b1V4HDo7Gxw6Ohx9b299fG9vUFFQHa4HUh1QXFBFUPAQ G3pcf10QXP5T7lOfU1ZFQkZTUVBcX1pSU1N5UFFEUFBRWndfrFDpUnhRWlZiQkLKWVNTUllcNl3k RlNTUllQUFFZUlLoWVFRSUZZnelRd1BIe3sqHkCgUUh/eyodsVFIf3sqQJBRSH97KkCQUUh/QKa0 eypAgFFIf3sqolFIf71Qb3tsrVCmvddefntVLUCUUEFCaUFCaVFBQmlhYFENR2djV0ZGRURXVnNy d2dGY2JmZWR3dqx53EgIDG0IkTEZRm0FNxNNe8XxClwxbRh7blwgU3xLcEVOUFBRUVhU91MEVepQ VlACEEp6VmhWGFYIVjhWVVVUVVZUVlJROhBV8VZQWOhRUeJVcFDoUVHkVvFUy1XoUQ/jVwsqSHtJ QKS0pEi9SklAvUhQb6RKrWxAbEFpUUJpYWBRDVFRc1NjR2dTBK6nmCvOHPZV6q69UUPi4q+vUMCv t1UPV3dSdlBmUFBRV1CZUSVRPVBwEFpR/2yfbK9sU2xG6K+B5Bh7UVFp6VG6UHlQe1F7DWWvr1Ae r7hUWFXqUnZQBlBQUVdQmVDkUFBQR+NRUWFD6K+j5Bh3UVF+6VG7UHlQe1F7UK+vUGJQUFVIV3dS dlBtUFBRV1CZUV1RPVBH41FRSl3orfTkGHdRUUfpUbpQeVB7UXtQr69QeFBQVElV6lJ2UA1QUFFX UJlQwFBQUEvlUXBGUUZY6FEB5Bh7UVFD6VG7UHlQe1F7DWVQUFJQ7K4BUQlVg1BTUFdQFBBCUVKL UFNQVFeLVVZeUFFRVFRV6FFR5lZTUlJXV1bsUjJQWFAyUjxQSHtApmxAbEBsQK1sQGxAbFBvbK1s b2ytbGFgUUFzQUNBc0FRCc3NzVWDrLpTRqvFrLlTR1BQUlAaUFBV4lXqUERQeVCTEBB4cVFRUnhQ VVRTd1BVdlN3RXV5UnhFdXVFRU5QVURQUFV3U3F4Uh9SL1JSUkJYdHVxVTB4WFJIaUVxeEJpUFh4 71LGUHdRJlBTUsZQUlBSUlUQTlBZdXVZRUUrUFlVVVlQUEl6WU96XUp7VUBQR84BSHt7e2xRHkCm Hb17Kh5AoFFIf3tsUX97Kh1AoVFIf3tsUX97KkCgUUh/pK20UG+0e61QtG97pK1QbEFCaQ1/bK1s 11V+ey1AlF9fX19hYFENY0NzZ2NDcWJHTlNFRFJWVldWc3VjYmdmZ2ZnZmZlZHZ3dnNxU3FXcQvd zkzP3VHl2mgIzilqPPzt0TLAroi3zSocZhdrHAosDxjFr1A6UcRMrjxSytZSylpAB8+BJuGujY4s Tkf2TUJzfRoyq/Di709Hrl3WUFJQNK+3VA5V6lBOUHxQvOlQU6+wEEJeQWRfS3pLekxqS21MVbhU UUfor7DjXkFkeOivsBBZXkFkenBeQWR06K+wEBpbQWREdEt7UtpJ6klSVkpLS1VNTVBTU1FMVE1K SFFQVXZTVllPSHJSTUpWU1RRRFRMVFVMdktVREtLVUxLS3ZUVVlPTEtVVFRQUehRBBBMS5VIqXJP RFZ5T11bdnBASX1PcCBZUVlKfnY1SHseQKYNHb0eQKQdvVBvvW+9vbakbEdpUUFCaWlCaVjXfntY LUCUUEFCR2lpQmlRQUJpaUJHaddYlFhs10BelGxhYFENDXt7e3tQIQ17UWNGR2dHV0ZCRURSVnNy dmVkQmZjYkdGR3Z3V3dndkNkdnNyVlZFREZjYmZCUiLsdXXhfswDAPen+Za9yK0qCRxqFksftGCC FabfJDH8INokP+sIVepzeBsyFtiuvOWBrsrzvZb9UW7xT0hu3980NA8KrKHXxiSs1sLFzlFSr69Q v1BQVn9Xd1J2UGxQUFFXUN1RylE9UEUQWlFRXlaQGHdRUV3pUbpQeVB7UXtQr69QUK4BVC1V6lJ2 UAxQUFFXUN1Q4VBQUEUQWlFRRl2mGHdRUUXpUbtQeVB7UXtQUFJQCFBQVQZV6lBBUExQ8BAHS0VR U0BCTEFSTEJAU1RHTVJRU3hSQUFOUFFEUFBRQ0JxX0BAUVBLTHFUU1NQUjB4UVJBeFBYR3pYSk5S QEErAFFRT1EgUVJRQF9Qf1BSUElNUUBQFhNIe397bFEeQKQNe2wNIVEdrXtsUR5Aph29UG97bFBv e7RQQml/bK1sQUJpf2ytbFXXfnstQJR7QUJpUUFCR2lXbGxsbGFgUQ1jUUdTcWJGRkVEXlJXVnNx U0NxYmZmZWR2dnNxCFFolG9Ry8/POBohJRLd367DbzNREOzgOmk1wa7dVepRrogZ4T4K7SpuX3Gu hlGAAfYNGQp7UFKvu645VBhV6lBBUHFQ5RA0aVFRY1QfXwxfyV9UU0BAX0JBUlNNR1JBQXNQUURQ UFFAQF5SeFFQTU9WV0dPXltBeFBeSnBQWUBZf1nfWc9ZVVlKc1JSWUFBCFBZUVFZUFBQQFBSUKBZ UHJ4UUBQR1ByWptuSHt7QGx7e2x7QJBReyqgDVFIf3tsUX97KkChUUh/e2xRfx5Apg0dvVBve2xQ b71vvW97bFBBaX/XVX57LUCUUEFCaVdebFhsXmxhYFANUQ1TUWNTZmZjYkZFRFJWVnNyd1NDREdG RmNiQmVkdnNyXlJFUdnlIALAHMmYPvD0Bu85KOFBSSIbzJDRMBUmNRKuOVcBrb0CFY2e9q6/9h6S re9TGSd+EQBRD+fXwxnBglBRUPFRcFRZVNhQW1DeEG0mVydY2VHXVtdXVcZRUSdXJ1jZVtdXVFpR UlJZV1RTU1hXWltbVlRRUFBVUFtYWVZVUlNbWVNVVFZQWQRb6FFK5VUEU1gEVuhRSuVSBFBJXAvp UitQSHseQKQdtK20UH+krbRRQUJHaVBAmUCZQJlAmVdAXmxsV0BebGxXQF5sbFdAXmxsYWBQDVEh DUNRUWdRUUdRUVdRUfFRa66WKlFqUWkorphRaiqulq6VUclRa1FqKq6WUWkprpeulipRaq6VUFBR UUdSjVKGVZxQWVAoEENTVFdQUFFXeFhZWXxQUURQUFFU6FLLEF5TU1hZiVh4V1Fby1eoWOtRZ1BR UFlRZ+JRQFDoUYoQXFBaeFFAUFBaWp0YSHt7QGxRf3tse0CQUaZ7bFG9QK29tFBve2ytUEFpf71V 1357LUCUe0JpaVFCaVBAmWFgUUNWV2dmZmdjU1HzPzfESxzmYiDNUo1SRBhOL0Y9b61BUFBRUMhS jVNlVZxQTVA4EERUVFRGUtBLUUtMUFJRR0FLv0xRTOhSy+JQTV7qUsxQXVJXEEJNiVp3QVFN/0zL V35ESk9d6V7oUnzlUElOPedIex5ApB2kvR5Aph29pLRQb729rbRAbK0NbEJpaWlRQUJpDWFgUQ1D ZmZnZmdmZWR2c3JWV3dmZmNiRkVEV1ZXVlZXcVfIT8j/NUhzb20YHkPJTs7U2ttsfcUJE0VRK0lS jTj9M2lJdXp2Z2hqXzshKQkBFGEKZWRLKVBQUVD5UptTY1WcUHhQLRBJX1tRrEWvRqtHU1leV1tw XXeAWlFaWkNUUOpSzFBRUlfjVHd2R+pSzFBGUlfmdolDd0pReuhRo+ZzYlf/TX5A6FET4kbpR+hS fOdRqFBJeT3nSHseQKQdvaStpr2krb1Qb729rbRAva20QUJpfw29aVFBQmlpYWBQIVENQ2dGRmNi ZmVkdnNzZ0diZmVkdnNyVld3ZmZjYkZFRFZXRkZFRFZzcnb530cCahkfERt5R3ERNBBraRhGw0rG KdraAAgaa/PcK/RT8kBpZhhlfmg7UWpneGdhZUMGOSMCbg1FTgJoCNwoUFNQK6+TVs5Vg1BTUF1Q e1C6EGk2VzZYUlRCVHRSV19YUVggeVF5el5AX3VPe1JTU3xQUURQUFFcXV18VFVEVFRVVFVbeFtU VVtdeXroUsviXntM6lLMUEtSVxBMSHdPiXtTUFJRUF1UiVxbUXv/estFfnLVfUvpTO9SfFBeUkZQ U1BSUVFQUVJf41PpUFvoUaMQX1wVVV3pVSdUIVDmfJ3USHtJQKSkSLS9QK29QL2kvUlApkikvUCm vaS0UG9srWxvbH9sf629rbRAbK1sQUJpUUJpe0JpaddVfnstQJTXfkh7LUCUUEFCaWlpUUFCaQ1Q QA2ZYWBRDVANR1FjUUNDVldnZmZnY1NRZmZnZmdmZWR2c3JWV3dmZmNiRkVEV1ZXVlZXcVcrVST/ qi/WPzfESxzmYiDNUZNPyP81R3QQbBgfQslOzdXa2218xggTRVErSm1WQKmgU0pSRBhOL0Y9b61B rVA4/TNpSXV6dmdoal87ISkJAhNhCmVkSylQUFRQ+6+TVp5Vg1BTUF1QSFBLUWkQAVRdS1VLXVNf Sl5ARkRDSEtFR0NIQEZJSl5LRVdYVVRbeFtdVEJBQdtLSkRLQUBLSkNISHxeSkReXkpcXV18VFVE VFRVUVJTU3xQUURQUFFDQuhSeONvSlFK6FJ35UFFS9tGQOhSWBBZSF5dU1BSUVVY6FLL5VdXYF1R XehSVhBZXFtRRv9FBENA6FFR5UHpS0LLS+hRE+VKSKheqEPoUVHkEErBcFHoUVHjUkpNW+hRoxBf XBVVXelVJ1TAU+lQSUw96VF9UEh7SR5ApEgdvUmkSLS9QK29SR5ApkgdvUlKrUhKva29QLa0QL29 QKS0UG9srQ1pf71vbH9sb2ymbK1saaQNrWzXVX571y2U135Iey1AlNd+SHstQJTXWH5Ie1UtQJRR QUJpe0FpaVBAmV9fX19hYFENR1FjUUNDVldnZmZnY1NRZ3FnUWNTY1dzV1NDUftVJP+qLwY/N8RL HOZiIM1TSHCuLUlSUCUzNEo0TwYQrrNtVkCpoFNKUkQYTi9GPW+tQa1QyClRjq5MI8hRW1FZrqdQ VFD5r5NWvFWDUFNQfFBnUGpRbRAUeXRRfml9f2VjYmdqZGZiZ39laGl9amR0QV5dQltfYGFgf2Hb aWpEaWlqZ2JifGl9RGlpfVNQUVF8UlNEUlJTYGp/YmHoUnjjb2lRaehSd+Rkattlf+hSWBBeZ31S UVNQXihBQUtUdFXoUnjnWCh6S3RKM3roUSkQR0coTlFlJGRkYv9/UX8I/2BRYAhqYaBq61GRUGlQ Z1FmEEN9Ygh9qRBpGXBSSmx3T1skcU9E6lGRUEpRZuJLoFXoUWbiVCRT6lFmUFBR6ONr3eNIe0lA pki9SaRIvaStpr2kvUkeQKZKHa1KSL29QL1AtrRAvQ29DUBsQLRQb729rbRAva2kQWl/vX9sf2x/ bKZsrWykDa1sQUJp11V+e9ctlNd+SHstQJTXfkh7WC1AlFFBQmlpUEFCaV9fX19hYFANR1FjUVNn RkZjYmZlZHZzc2dHYmZlZHZzclZXd2ZmY2JGRURWV0ZGRURWc3J2UWdxZ1FjU2NXc1dTQ1GZVST/ qi+S30cCahkfERt5R3ERNBBraRhGw0rGKdraAAgaa/PcK/RU33CuLUlSUCUzM0k0TwYQrrNtVkCp oFOPQGlmGGV+aDtRamd4Z2FlQwY5IwJuDUVOAmgI3CisysgpUY6uTCPIUVtRWa6nUFBRr7FWTlTa Vs9QU1B56VBSUWniU1NR6FFp51BTSlVQSVRk6VEQUEh7HkC0QLZQfx29bEC9YWBTZXFFT1T5Vk7R 0VBRUAGvt1V5VYNQeVDN5XRzaVNSQeivkBAdQEFkQkBDQ0VbeHBcQWR4UHd3V3VKW0taVnBVT1ZW dUV9QFN1fVBZcUxJU05wT0tKEE9PTkpKTkJDeHd7XHBcQWRUWVxTTltWWlVOeld/vY1saWlCR2l7 UUhAhmKWYkFpf0Jpf0pAnUCdQkdpUG8dvW+9QWl/bI1sQIZsjWxBQml/Qml7UEFCaUh/Qml7YWBR DVVwd3ZTc2djZmdzZ2NmZ2ZxYkdXdnNwV1ZXcVdxVldxV3FGR0ZjYmdXVlKurqvIxEE7TB9TWylM LmvShFFrscEDDOquo/ZjcFIlTa0vXVVSKE2t9l40OeLMJ30jScbDUVfWFBDW5963JvouvxoB1hAU 1uU5IDOGf1BQUFBSUFCvpFBQr3dQxlBQUFBQUFBQUFBQUFBQUFBQUFBQUI5QUFFSUVNQU1BUUFVQ VlBXUFhQWVBaUFtQXFBdUF5QX1BAUEFQQlBDUERQRVBGUEdQSFBJUEpQS1BMUE1QTlBPUHBQcVBy UHNQdFB1UHZQd1B4UHlQelB7UHxQfVB+UH9QYFBhUGJQY1BkUGVQZlBnUGhQaVBqUGtQbFBtUG5Q b1AQUBFQElATUBRQFVAWUBdQGFAZUBpQG1AcUB1QHlAfUABQAVACUANQBFAFUAZQB1AIUAlQClAL UAxQDVAOUA9QMFAxUDJQM1A0UDVQNlA3UDhQOVA6UDtQPFA9UD5QP1AgUCFQIlAjUCRQJVAmUCdQ KFApUCpQK1AsUC1QLlAvUNBQ0VDSUNNQ1FDVUNZQ11DYUNlQ2lDbUNxQ3VDeUMBQwVDDUMZRVFDN UM5Q8FDxUPJQ81D0UPZQ+VD6UPtQ/VD+UP9Q4FDhUOJQ41DkUOVQ5lDnUOhQ6lDrUO1Q7lDvUJJQ k1CUUJVQllCXUJhQmVCaUJtQnFCdUJ5Qn1CAUIFQg1CEUIVQhlCHUIhQiVCNUI5QsVC0ULVQtlC3 ULhQuVC6ULtQvFC9UL5QoFChUKJQo1CkUKVQplCKUVVVfj4lPDxAPj8+PTEiOzk+NyI1JCUiPlM9 JWFXJT45YmARE1BQUFBQUFFQUFIKUFFQMlHQUFZQnFBTUHSv5FBTUGyvi1BEUESvOFB0UFOv5FB0 UGevOFB0UGmv31B0UGqvi1B0UGyvOFB0UAmvi1B0UAqvi1B0UAyvvlB0UPmv5FB5UFOvi1B5UF+u qFB5UEGuqFB5UHSvOFB/UFOvi1B/UGevOFB/UGmv31B/UGqv5FB/UGyvFFB/UAyvi1B/UPmv31Bj UFOv5FBjUF+uqFBjUEGuqFBjUHSvOFBlUGevi1BlUGmvi1BlUGqvi1BlUGyv5FBnUF+vFFBnUECv FFBnUEGvFFBnUE2vOFBnUE6vOFBnUHSvOFBnUGKvi1BnUBSvFFBnUBavFFBnUBivFFBnUByvvlBn UAKvFFBnUAWvOFBnUAavFFBnUAivOFBnUAqvOFBnUAyvOFBpUF+vOFBpUECv5FBpUEGvOFBpUE2v i1BpUE6vi1BpUHSv31BpUBSv5FBpUBiv5FBpUByvi1BpUAKv5FBpUAWvi1BpUAivi1BpUAyvi1Bq UF+v5FBqUECvi1BqUEGv5FBqUHSvi1BqUBSvi1BqUBivi1BqUByvvlBsUFOvi1BsUF+vFFBsUECv OFBsUEGvFFBsUE2v5FBsUE6v5FBsUHSv31BsUBSvOFBsUBiv31BsUByvi1BsUAKv31BsUAOv31Bs UASv31BsUAiv5FBsUAmv5FAZUPlQHFAFUF+v31AFUECvi1AFUEGv5FAFUPlQHFAJUF+vOFAJUEGv OFAKUF+v31AKUEGv31AMUF+vOFAMUEGvOFD4UPiv5FD5UFOv31D5UAavi1D5UPmv5FBQUFBQUlBR UFBQUFBEUFNQUVBQUUxQUFFWUFBRUFBQUFBQUFFSUFBQUlBQUFBQUFBQUFBQUFBQUFFQUFNUVVZX WFlaW1xdXl9AQUJDREVGR0hJSktMTU5PcHFyc3R1dnd4eXp7fH1+f2BhYmNkZWZnaGlqa2xtbm8Q ERITFBUWFxgZGhscHR4fAAECAwQFBgcICQoLDA0ODzAxUDIzNDU2Nzg5Ojs8PT4/ICEiIyQlJico KSorLC0uL9DR0tPU1dbX2Nna29zd3lDfwFDBUFDCw1BQUFBQxMVQxsfIycpQy1BQzM3OU8/w8fLz 9PX29/j5+lD7/FD9/v9QUODh4uPk5ebn6Onq6+zt7u9QkJGSk5SVllBQUJeYUFCZUFBQVFHSUFBQ eFBwUFRQWFAuUK9RA1ExUShRLlHCUpZSjHBEcEpwTnBycHZwYHBqcPxxcnJJr69QUFBwUPBRAlEw UShRLVHCUpZSjHBDcEhwTHBwcHZwYHBpcPxxcnJJr6+vs1BQrwCvOq9krx+vWa2vrbqwwVBQUFBQ ULAosNSwJbBhjzqOyFBRUFBQdlBQUFBQUFBQUFBQUFBQUFBQhFCIUIxQUFBQUFBQUFBQUFBQUFBT UMlQ1FDVUP1QwlCeUNZQ3lDbUMRQzFDKUEBQ2lCMUNNQwVCHUIhQ3VDDUNhQ4VCYUIZQxVDNUIpQ iVCLUMhQz1DnUOVQ8FAyUDNQ31A0UOlQNVDmUOhQ7VDqUOtQ7FCfUDZQkFDuUO9Q8VA3UIVQwFCT UJFQklA4UIFQg1DZUDpQOVA7UD1QPFA+UMZQP1AhUCBQIlAjUCVQJFAmUCdQgFAoUCpQKVArUC1Q LFD6UMdQL1AuUNBQ0VCCUIRQ+1D4UPlQ4lD2UPdQ41DSUOBQ11BQUFBQUVBRUFFQUFBRUFBEWFBQ UERQUFBQUFBEUGDSQ6xWWXrWGNanXVFXUvDSQ71g0kO5UlFRYV5gXFZYetYY1qddUlVVUGAxVlp7 VlFUUdJnUlFU8ANgAWB8Vlp7VlFUUdJnUlFM8k7QTFBsUGxQbFAfUDJQI1A/UDxQNVAkUDVQblBu UG5gcWBZVlV7XlNSSlVQVES59ZUpVDnCG1XkEs/x2h+NjZEzJfDSX4Jg0lKQYNJSeVJEQ9nkgdq4 95TtZZfL3diaT5oDBsFgXVZZetYY1qddUVFUVVBg0c5hT2BNVlMFVFpDRgY1IjkDOTc+cAQiJSMk cB41JCc/IjthR2BFVlMFVFtDXgY1IjkDOTc+fHAZPjN+YXxgelZTBVRbQ3MGNSI5Azk3PnAEOT01 cAMkMT0gOT43cAM1IiY5MzVwAj8/JGFkYGJWUwVUW0N7Hh9wHBkREhkcGQQJcBETExUABBUUfHB4 M3lpZ3AGNSI5Azk3PnxwGT4zfmBOR11pZ2BlYWJgZ2BgYGAKR11paWFiY2FgZ2BgYGAKYNHOYU9g TVZTBVRaQ0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7YUdgRVZTBVRbQ14GNSI5Azk3PnxwGT4zfmF8 YHpWUwVUW0NzBjUiOQM5Nz5wBDk9NXADJDE9IDk+N3ADNSImOTM1cAI/PyRhZGBiVlMFVFtDex4f cBwZERIZHBkECXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58cBk+M35g0c9gXVZZetYY1qddUVFR VVBT0d1QYNHZUtHRUIN+cKA4LHx9ftFM4Vbi91vnQV0HigOIJbOZY3rihKZZC2SjucCuWVyAi0sK 6Z23ptjhzZDXdbstCEAjOiibIUWtlgimefsIDsZUrX0yQQjRTJohxIVyCH+FnERV1GbqxPrkHRq5 vmty/QbJLnHMPNaQGhfHOuT2ZoWsWX2D5GnLUlNRUFFgXVZZetYY1qddUVFUVVBT0dFQakHM1VVu grnQqyuF+aT8KaxVrMVtIXP5e3iP3EM12a5811HfCsoymkH30KTn7kTngQbJO1gyFZby9YplL1Vy jiJ9VNZV9yxZRsNEE6CnRh2GV97LQDwIrlplx5rZz49UIMx6LTHekbhbIcr4lzYyEm3FxHJiyHLZ 2qo0WHSlgqpg0lKdYNJSZlJFUO1ByooTvXGrFgjU2ZoW2MB1vkQwYF1WWXrWGNanXVFRVFVQYNHO YU9gTVZTBVRaQ0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7YUdgRVZTBVRbQ14GNSI5Azk3PnxwGT4z fmF8YHpWUwVUW0NzBjUiOQM5Nz5wBDk9NXADJDE9IDk+N3ADNSImOTM1cAI/PyRhZGBiVlMFVFtD ex4fcBwZERIZHBkECXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58cBk+M35gTkddaWdgZWFiYGdg YGBgCkddaWlhYmNhYGdgYGBgCmDR/GF3YHVWUwVUW0NOBjUiOQM5Nz5wBDk9NXADJDE9IDk+N3AD NSImOTM1YU9gTVZTBVRbQ0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7YWRgYlZTBVRbQ3seH3AcGRES GRwZBAlwERMTFQAEFRR8cHgzeWlncAY1IjkDOTc+fHAZPjN+YUdgRVZTBVRaQ14GNSI5Azk3Pnxw GT4zfmFBYF9WUwVUV0NYGT4kNSI+NSRg0c1gXVZZetYY1qddUVFRVVBT0dtQYNHXUtHRUPsxveT9 3cAXwIzkQQ45jFovMsBWYZ2er9jBFocZasS5hFZvzf3yKAq8qawzFR/oWz5gv/Jm+31Zj6E/d/td ATBVZR8vngQfgOd8EohbgN3oDq/m0ICzxuQvchkSQDyDyOBRBvOTn37PaqQv+Aj2h3I1tdz7KMzs iRcSOAt9La3lUlFTYF1WWXrWGNanXVFRVFVQU9HRUD0wq8kP9DnjgysgezJzThRwAf9zRZckUqkZ ondKDPzWIWVYe6bfjrDlxrjb9xuzI5gYWc3gituKRcKaU7VZdQZWtx70F/WBBxaEaAalcZ2Tdmt9 dWKey7LvEBe6iD0XJrWQYPNf0J4viGsu8KnFemF7RaqYRL2N4LkFESAWfXwuYNJaaWDSWfLwU1JR UlJAHm7UPgewwICJ2xycctMJHWBdVll61hjWp11RUVJVUGAxYUFgX1ZTBVRXQ1gZPiQ1Ij41JGFH YEVWUwVUWkNeBjUiOQM5Nz58cBk+M35hY2BhVlMFVFtDegY1IjkDOTc+cBM/PT01IjM5MTxwAz82 JCcxIjVwACUyPDkjODUiI3ATEWBOR11pZ2BmYGRgYGBgYGAKR11paGBmYGRiY2VpZWkKYNJRFWFB YF9WUwVUV0NYGT4kNSI+NSRhR2BFVlMFVFpDXgY1IjkDOTc+fHAZPjN+YWNgYVZTBVRbQ3oGNSI5 Azk3PnATPz09NSIzOTE8cAM/NiQnMSI1cAAlMjw5Izg1IiNwExFhFmAUVlMFVFtDbScnJ34mNSI5 Izk3Pn4zPz1/IjUgPyM5JD8iKX8TAANwGT4zPyIgfnAyKXACNTZ+fBwZERJ+HAQUeDN5aWZha2Bp VlMFVFtDYhQ5NzkkMTxwGRRwEzwxIyNwY3B9cB05MyI/Iz82JHADPzYkJzEiNXAGMTw5NDEkOT8+ YVtgWVZTBVRWQ1IFA2FBYF9WUwVUWENYGTw8OT4/OSNhSmBIVlMFVFdDQRU8O3AXIj8mNXAGOTw8 MTc1YXFgT1ZTBVRTREgdPz4/JCkgNXAEKSA/NyIxIDgpfHAZPjNgDGBdVll61hjWp11RUVFVUFMb UGAYUhFQ8nUOEAOjpyNtqBY3yEuGCJq3GP+TiJxi52bNlOClKfKuNtLkNGv7fV1b8ZkuhBOZrlDA /RKzgghE/Kl4mIE/NVJTUVBR89JXHmDSVxpgWVZTBU1DVFJgUGBbVlMFTV9UVFNSVfBg0dhWUwVN UVTR0GAu0EArxrSBE604yKNonD5rolvS8TNgMWFBYF9WUwVUV0NYGT4kNSI+NSRhR2BFVlMFVFpD XgY1IjkDOTc+fHAZPjN+YWNgYVZTBVRbQ3oGNSI5Azk3PnATPz09NSIzOTE8cAM/NiQnMSI1cAAl Mjw5Izg1IiNwExHSVVLkUFBRYHFWUwVNVFFRr1RHYERgXmBcVlp7VlFUUdJnUlFGU1JX0FBgXVZT BU1aVFZgVFNSVhBg0lRmVlp7VlFUUdJnUlFaUVGvVNJUc2DSVE/wedB3OCQkICNqf38nJyd+JjUi OSM5Nz5+Mz89fyI1ID8jOSQ/Iil/EwAD8dJT6NHSU+QEODkjcDM1IiQ5NjkzMSQ1cDk+Mz8iID8i MSQ1I3AyKXAiNTY1IjU+MzV8cDE+NHA5JCNwJSM1cDkjcCMkIjkzJDwpWiMlMjo1MyRwJD98cCQ4 NXAGNSI5Azk3PnATNSIkOTY5MzEkOT8+cAAiMTMkOTM1cAMkMSQ1PTU+JHB4EwADeVomNSIjOT8+ cGF+YHxwMSYxOTwxMjw1cDk+cCQ4NXAGNSI5Azk3PnAiNSA/IzkkPyIpcDEkalo4JCQgI2p/fycn J34mNSI5Izk3Pn4zPz1rcDIpcBV9PTE5PHAxJHATAAN9IjUhJTUjJCMQJjUiOSM5Nz5+Mz89a3A/ IloyKXA9MTk8cDEkcAY1IjkDOTc+fHAZPjN+fHBiZWljcBM/MSMkcBEmNX58cB0/JT4kMTk+cAY5 NSd8cBMRcGlkYGRjWgUDEXATPyApIjk3OCRweDN5YWlpZnAGNSI5Azk3PnxwGT4zfnBwETw8cAI5 NzgkI3ACNSM1IiY1NH5wExUCBBEZHloHEQICER4EGRUDcBQZAxMcERkdFRRwER4UcBwZERIZHBkE CXAcGR0ZBBUUflpaBxECHhkeF2pwBBgVcAUDFXAfFnAEGBkDcBMVAgQZFhkTEQQVcBkDcAMEAhkT BBwJcAMFEhoVEwRwBB9wBBgVWgYVAhkDGRcecBMVAgQZFhkTEQQZHx5wAAIREwQZExVwAwQRBBUd FR4EfnBwBBgVcBkDAwUZHhdwEQUEGB8CGQQJWhQZAxMcERkdA3ATFQIEERkecBkdABwZFRRwER4U cBUIAAIVAwNwBxECAhEeBBkVA3xwGR4THAUUGR4XcAcRAgIRHgQZFQNaHxZwHRUCExgRHgQREhkc GQQJcB8CcBYZBB4VAwNwFh8CcBFwABECBBkTBRwRAnAABQIAHwMVfHARHhRwBxkcHHAeHwRaEhVw HBkREhwVcBYfAnATHx4DFQEFFR4EGREcfHAABR4ZBBkGFXxwER4UcBMVAgQRGR5wHwQYFQJwFBEd ERcVA35wAxUVWgQYFXATAANwFh8CcBQVBBEZHAN+WloTPz4kNT4kI3A/NnAkODVwBjUiOQM5Nz5w IjU3OSMkNSI1NHA+Pz4mNSI5Njk1NAMlMjo1MyQRJCQiOTIlJDUjWjUoJDU+Izk/PnAmMTwlNXAj ODE8PHA+PyRwMjVwMz8+Izk0NSI1NHAxI3AxMzMlIjEkNXA5PjY/Ij0xJDk/PlomMTw5NDEkNTRw MilwJDg1cBkRflrzZtBkOCQkICNqf38nJyd+JjUiOSM5Nz5+Mz89fyI1ID8jOSQ/Iil/JjUiOSM5 Nz48Pzc/fjc5NmDSUk9WUwVNU1TSUkZg0lJCYNJSXmDSUlpWWzDWGFHWqBVRV1FRYNJRqUbSUfcE ODkjcDM1IiQ5NjkzMSQ1cDk+Mz8iID8iMSQ1I3AyKXAiNTY1IjU+MzV8cDE+NHA5JCNwJSM1cDkj cCMkIjkzJDwpcCMlMjo1MyRwJD98cCQ4NXAGNSI5Azk3PnATNSIkOTY5MzEkOT8+cAAiMTMkOTM1 cAMkMSQ1PTU+JHB4EwADeXxwMSYxOTwxMjw1cDEkanA4JCQgI2p/fycnJ34mNSI5Izk3Pn4zPz1/ EwADa3AyKXAVfT0xOTxwMSRwEwADfSI1ISU1IyQjECY1IjkjOTc+fjM/PWtwPyJwMilwPTE5PHAx JHAGNSI5Azk3PnxwGT4zfnxwYmVpY3ATPzEjJHARJjV+fHAdPyU+JDE5PnAGOTUnfHATEXBpZGBk Y3AFAxFwBDU8fnB7YXB4ZGFleXBpZmF9aGhjYHATPyApIjk3OCRweDN5cGFpaWZwBjUiOQM5Nz58 cBk+M35wcBE8PHACOTc4JCNwAjUjNSImNTR+cBMVAgQRGR5wBxECAhEeBBkVA3AUGQMTHBEZHRUU cDE+NHAcGRESGRwZBAlwHBkdGQQVFH7wXlZcMNYYUdaoFVFXUVFR8V5WXDDWGFHWqBVRV1FRUmB8 YHpGeDgkJCAjan9/JycnfiY1IjkjOTc+fjM/PX8iNSA/IzkkPyIpfxMAA3BgRlZae1ZRVFHSZ1JR S1RYYFZRUa9RUa9gXVZZetYY1qddUVFSVVBT0dFQ0KUON8odtglOXpvrjJ4lrWa39sewLhcozFVT 9MNGckfsh5fJsxSqdan7Ug9dhj6shIiWjl4os78pcoFGpNN4mLgWrSpsbuO46X6FtIu9EsulqIPn tC2I+L8zfNXAVZ5CFWmHMtpWTq0tlRitCjuAEwx/nsEsar4KfWQh8YDIdNJh0lPJYNJTxVJRUWAl YDFhQWBfVlMFVFdDWBk+JDUiPjUkYUdgRVZTBVRaQ14GNSI5Azk3PnxwGT4zfmFjYGFWUwVUW0N6 BjUiOQM5Nz5wEz89PTUiMzkxPHADPzYkJzEiNXAAJTI8OSM4NSIjcBMRUkAebtQ+B7DAgInbHJxy 0wkdYFxWWHrWGNanXVJVVVDw0bVgSVZZetYY1qddUVlTYVxWWntWUVRR0mdSUVRgTFZae1ZRVFHS Z1JRW2FeYFxWWntWUVRR0mdSUUZgT1ZZetYY1qddUVlUYUJUQOosmveswkhE5Nk+7OpXQQxg0dhW WntWUVRR0mdSUVxhKmAo8ArQCFARUCJQOVAxUDxQcFAZUCRQMVA8UDlQM1BwUB9QIFA1UD5QBFAp UCBQNVBwUDZQP1A+UCRQcFAHUDlQPlBwUBFQHlADUBlQcFAzUDhQMVAiUHBQI1A1UCTxStBIOCQk IGp/fycnJ349Pz4/JCkgNX4zPz1wYF1WWXrWGNanXVFRUVVQVBDCqjBveuIrsD2teErgs+YOjasq XCPljmPvZGeIRpDwnyB79Lv4Ve3Znw3XuANwl9ykTjIj7K3lxQg6kvaFrmiy8dJRgGDSUZxWWXrW GNanXVFZVmHSUe1g0lHpUlFRYNHoYNHOYU9gTVZTBVRaQ0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7 YUdgRVZTBVRbQ14GNSI5Azk3PnxwGT4zfmF8YHpWUwVUW0NzBjUiOQM5Nz5wBDk9NXADJDE9IDk+ N3ADNSImOTM1cAI/PyRhZGBiVlMFVFtDex4fcBwZERIZHBkECXARExMVAAQVFHxweDN5aWdwBjUi OQM5Nz58cBk+M35SRVDtQcqKE71xqxYI1NmaFtjAdb5EMGBcVlh61hjWp11SVVVQ8AlgSFZZetYY 1qddUVlTYVtWWXrWGNanXVFXUWBMVll61hjWp11RWVVhX0ddaWdgaGJmYmNhZWFgCmBPVll61hjW p11RWVRhQlRA8g4LcPO38vks9hovIEQyKGBdVll61hjWp11RUVFVUFTR0EhxGcfjYDC6htX0znQK INm3JGvYO+k8BHpH4giJ/D/4FNzOJydxe1k74+G54HzomRgWU/vrCajP5LxAxofoDoBNQnazmCvg p0MkIHwHufm5s/8egXzQQO+k5asOM+edqLbJ3asZnZe1px6QKcp2eIpqMfpFhdtiaF5n76Mutb9C MAC4D2Y7AQBmOwEApDoBAAEAAgAAAAAQAgsHBAICAgkCBAD/vAIAAAAATFADAAAAAAAAAAAAAAAA AAAAAQAAAAAAAAAw3K4YAAAAAAAAAAAAAAAAAAAAAAAADABBAHIAaQBhAGwAAAAAABgAQgBvAGwA ZAAgAEkAdABhAGwAaQBjAAAAAAAYAFYAZQByAHMAaQBvAG4AIAAyAC4ANAA1AAAAIgBBAHIAaQBh AGwAIABCAG8AbABkACAASQB0AGEAbABpAGMAAAAAAFBRUFBQQ1FQUFRQYBQDGRdB+6yeUFF2LFBQ RHgcBAMY833vtFBQQ5hQUFCyHwN/YsEuxmVQUFHoUFBQBgYUHQgFZD/GUFBE/FBQQcQzPTEgffqx UlBRc4xQUFLwMyYkcB2sDQVQUGc4UFBWyjYgNz0HKFkDUFBhrFBQVTs3MSMgUEJQWVBQUkBQUFBA NzwpNimrKEVQUAbUUFCYvjg0PSiJVEsVUFARLFBQRVg4NTE0kjx7JVBQUWxQUFBmODg1MV8cVbdQ UFEkUFBQdDg9JCizqA7mUFBuVFBQUyg7NSI+V/BWv1BRcShQUFI0PD8zMVEOgkdQUEJYUFBR7j0x KCBVjFwtUFBRyFBQUHA+MT01hDrAU1BQUnBQUF+2ID8jJGrrJ8tQUU8kUFBSUSAiNSBSlIa2UFB2 EFBQW+lQUVBQUFLQUEj+jGAPX2ylWElYUFBQUFDzAe9mUFBQUOB48eWvcK4eWPFXblBTUFlQUVBQ UFBQUFBRUFBXbq4eUBNYUK9wrspY8VBxUFdQUFBQUFBQUFBQUFBQjlBRUFBQjlAxUFdQGlBUUFJQ QFBGUBFQUFTPW+lQUlBRUFFThFLsUFVQUFXKVWNQTlFLVcpVY1AKU4FQNlJCWFVSW1dUUlJSWVJU UFBQU1BQUFBQUFBQUFBQUB0/Pj9QcVBwcklVg64BUWNXblHiUFBQUVBQUFBQUFBQUFNQWFBSUFtQ Ua+vUFNQUFATU3pQUVBQUFBQUFAvUFBQUVBQUFBQUVBVUC9QUVBQUFBQUlBbUKBQUVBQUFBQU1Bj ULFQUVBQUFBQVFBBULpQUVBQUFBQVVBcUURQUVBQUFBQVlBCUXBQUVBQUFBQV1AyUC9QU1BRVFNQ UlBOUW5QU1BRVFNQVFB6UWJQU1BRVFVQUlBKUThQU1BRVFVQVFB2UQxQU1BRVFZQUlBEUd5QU1BR VFZQVFBwUdJQU1BRVFdQUlBGUf5QU1BRVFdQVFByUfJQU1BRVFhQUlBKUYBQU1BRVFhQVFB2UZRQ U1BRVFlQUFCuUbpQU1BRVFlQUVBaU3hQU1BRVFlQUlBGV5hQU1BRVFlQU1A2V/pQU1BRVFlQVFBy V+xQU1BRVFlQVVBIWEBQU1BRVFlQVlB0WHhQU1BRVFlQV1CUWBxQU1BRVFlQWFB2WUBQU1BRVFlQ WVDaWWZQU1BRVFlQWlSSUrhQU1BRVFlQW1AyWZBQU1BRVFlQXFA2WnJQU1BRVFpQUlBOWsRQU1BR VFpQVFB6WthQU1BRVFtQUlB0Wu5QU1BRVFtQVFBgWuJQU1BRVFxQUlBKWr5QU1BRVFxQVFB2WrJQ U1BRVF5QUlBKW0RQU1BRVF5QVFB2W1hQU1BRVEBQUlByW2pQU1BRVEBQVFB+W35QU1BRVENQUlBG WzhQU1BRVENQVFByWwxQU1BRVERQUlBMW9pQU1BRVERQVFB4Wy5QU1BRVEVQUlB0W+JQU1BRVEVQ VFBgW/ZQU1BRVEZQUlBOW7JQU1BRVEZQVFB6W4ZQU1BRVElQUlByXFxQU1BRVElQVFB+XFBQU1BR VEtQUlBMXGpQU1BRVEtQVFB4XH5QU1BRVE1QUlBEXDJQU1BRVE1QVFBwXAZQU1BRVE9QUlBIXNJQ U1BRVE9QVFB0XCZQU1BRVH1QUlBGXPZQU1BRVH1QVFByXMpQU1BRWFpQUlBOWsRQU1BRWFpQVFB6 WthQU1BRWEZQUlBOW7JQU1BRWEZQVFB6W4ZQU1BRXFpQUlBOWsRQU1BRXFpQVFB6WthQU1BRXFxQ UlBKWr5QU1BRXFxQVFB2WrIEKSA1NjEzNXD5cAQ4NXAdPz4/JCkgNXATPyIgPyIxJDk/PnAgPDN+ cBQxJDFw+XAEODVwHT8+PyQpIDVwEz8iID8iMSQ5Pz5wIDwzfwQpIDVwAz88JSQ5Pz4jcBk+M35w YWlpYH1haWlifnARPDxwAjk3OCQjcAI1IzUiJjU0ESI5MTz4cAQiMTQ1PTEiO3A/NnAEODVwHT8+ PyQpIDVwEz8iID8iMSQ5Pz5wIDwzcCI1NzkjJDUiNTRwOT5wJDg1cAUDcAAxJHB2cAQdcB82Nn5w MT40cDU8IzUnODUiNX4dPz4/JCkgNWoRIjkxPHASPzw0cBkkMTw5M2omNSIjOT8+cGJ+ZGVweB05 MyI/Iz82JHkGNSIjOT8+cGJ+ZGURIjkxPH0SPzw0GSQxPDkzHQRQEVAiUDlQMVA8UHBQHlA1UDdQ IlA1UCRQMVBwUDNQJVAiUCNQOVAmUDFQEVAiUDlQMVA8UHBQJFAlUV1QPlC5UHBQO1AlUCJQKlC9 UCZQMVARUCJQOVAxUDxQcFA2UDVQNFBwUDtQJVAiUCNQOVAmUBFQIlA5UDFQPFBwUBZQNVAkUCRQ cFAbUCVQIlAjUDlQJlARUCJQOVAxUDxQcFPYU+1TlFPvU+1T4VBwU/BT61P8U+NT6VPhUARQKVAg UDVQNlAxUDNQNVBwUPlQcFAEUDhQNVBwUB1QP1A+UD9QJFApUCBQNVBwUBNQP1AiUCBQP1AiUDFQ JFA5UD9QPlBwUCBQPFAzUH5QcFAUUDFQJFAxUHBQ+VBwUARQOFA1UHBQHVA/UD5QP1AkUClQIFA1 UHBQE1A/UCJQIFA/UCJQMVAkUDlQP1A+UHBQIFA8UDNQf1AEUClQIFA1UHBQA1A/UDxQJVAkUDlQ P1A+UCNQcFAZUD5QM1B+UHBQYVBpUGlQYFB9UGFQaVBpUGJQflBwUBFQPFA8UHBQAlA5UDdQOFAk UCNQcFACUDVQI1A1UCJQJlA1UDRQE1A/UD5QJFA1UD1QIFA/UCJQMVAiUClQcFAjUDFQPlAjUHBQ I1A1UCJQOVA2UHBQNFA1UCNQOVA3UD5QfFBwUBFQIlA5UDFQPFBwUDNQP1A+UCRQMVA5UD5QI1Bw UD1QP1AiUDVQcFA4UCVQPVAxUD5QOVAjUCRQcFAzUDhQMVAiUDFQM1AkUDVQIlA5UCNQJFA5UDNQ I1BwUCRQOFAxUD5QcFA9UDFQPlApUHBQP1A2UHBQOVAkUCNQcFAgUCJQNVA0UDVQM1A1UCNQI1A/ UCJQI1BwUDFQPlA0UHBQMVAjUHBQI1AlUDNQOFBwUDlQI1BwUD1QP1AiUDVQcFA5UD5QcFAkUCVQ PlA1UHBQJ1A5UCRQOFBwUCRQOFA1UHBQPVA/UD9QNFBwUD9QNlBwUCRQOFA1UHBQPFAxUCNQJFBw UDRQNVAzUDFQNFA1UCNQcFA/UDZQcFAkUDhQNVBwUCRQJ1A1UD5QJFA5UDVQJFA4UHBQM1A1UD5Q JFAlUCJQKVB+UHBQcFAEUDhQNVBwUD9QJlA1UCJQMVA8UDxQcFAkUCJQNVAxUCRQPVA1UD5QJFBw UD9QNlBwUDNQJVAiUCZQNVAjUHBQOVAjUHBQI1A/UDZQJFA1UCJQcFAxUD5QNFBwUDZQJVA8UDxQ NVAiUHBQJFA4UDFQPlBwUDlQPlBwUD1QP1AjUCRQcFA5UD5QNFAlUCNQJFAiUDlQMVA8UHBQI1Ak UClQPFA1UHBQI1AxUD5QI1BwUCNQNVAiUDlQNlBwUDZQMVAzUDVQI1B+UHBQcFAEUDVQIlA9UDlQ PlAxUDxQcFAjUCRQIlA/UDtQNVAjUHBQMVAiUDVQcFAzUCVQJFBwUD9QPlBwUCRQOFA1UHBQNFA5 UDFQN1A/UD5QMVA8UHBQJ1A4UDlQM1A4UHBQOFA1UDxQIFAjUHBQJFA/UHBQN1A5UCZQNVBwUCRQ OFA1UHBQNlAxUDNQNVBwUDFQcFA8UDVQI1AjUHBQPVA1UDNQOFAxUD5QOVAzUDFQPFBwUDFQIFAg UDVQMVAiUDFQPlAzUDVQflBwUHBQEVAiUDlQMVA8UHBQOVAjUHBQMVA+UHBQNVAoUCRQIlA1UD1Q NVA8UClQcFAmUDVQIlAjUDFQJFA5UDxQNVBwUDZQMVA9UDlQPFApUHBQP1A2UHBQJFApUCBQNVA2 UDFQM1A1UCNQcFAnUDhQOVAzUDhQcFAzUDFQPlBwUDJQNVBwUCVQI1A1UDRQcFAnUDlQJFA4UHBQ NVAhUCVQMVA8UHBQI1AlUDNQM1A1UCNQI1BwUDZQP1AiUHBQJFA1UChQJFBwUCNQNVAkUCRQOVA+ UDdQcFA5UD5QcFAiUDVQIFA/UCJQJFAjUHxQcFAgUCJQNVAjUDVQPlAkUDFQJFA5UD9QPlAjUHxQ cFA9UDFQN1AxUCpQOVA+UDVQI1BwUDVQJFAzUHxQcFAxUD5QNFBwUDZQP1AiUHBQNFA5UCNQIFA8 UDFQKVBwUCVQI1A1UHBQOVA+UHBQPlA1UCdQI1AgUDFQIFA1UCJQI1B8UHBQMVA0UCZQNVAiUCRQ OVAjUDlQPlA3UHBQMVA+UDRQcFAgUCJQP1A9UD9QJFA5UD9QPlAjUH5QHVA/UD5QP1AkUClQIFA1 UGpQEVAiUDlQMVA8UHBQElA/UDxQNFBwUBlQJFAxUDxQOVAzUGpQJlA1UCJQI1A5UD9QPlBwUGJQ flBkUGVQcFB4UB1QOVAzUCJQP1AjUD9QNlAkUHlQBlA1UCJQI1A5UD9QPlBwUGJQflBkUGVQEVAi UDlQMVA8UH1QElA/UDxQNFAZUCRQMVA8UDlQM1AdUARQEVAiUDlQMVA8UP5QcFAEUCJQMVA0UDVQ PVAxUCJQO1BwUD9QNlBwUARQOFA1UHBQHVA/UD5QP1AkUClQIFA1UHBQE1A/UCJQIFA/UCJQMVAk UDlQP1A+UHBQIFA8UDNQcFAiUDVQN1A5UCNQJFA1UCJQNVA0UHBQOVA+UHBQJFA4UDVQcFAFUANQ cFAAUDFQJFBwUHZQcFAEUB1QcFAfUDZQNlB+UHBQMVA+UDRQcFA1UDxQI1A1UCdQOFA1UCJQNVB+ UB1QP1A+UD9QJFApUCBQNVBwUARQKVAgUD9QN1AiUDFQIFA4UClQHVA/UD5QP1AkUClQIFA1UHBQ BFApUCBQNVBwUBRQIlAxUCdQOVA+UDdQcFAfUDZQNlA5UDNQNVBwUH1QcFACUD9QMlA5UD5QcFAe UDlQM1A4UD9QPFAxUCNQfFBwUABQMVAkUCJQOVAzUDlQMVBwUANQMVAlUD5QNFA1UCJQI1BwUGFQ aVBoUGJQOFAkUCRQIFBqUH9Qf1AnUCdQJ1B+UD1QP1A+UD9QJFApUCBQNVB+UDNQP1A9UH9QOFAk UD1QPFB/UD1QJFA+UDFQPVA1UH9QPVAjUA9QMVAiUDlQMVA8UH5QOFAkUD1QPFA4UCRQJFAgUGpQ f1B/UCdQJ1AnUH5QPVA/UD5QP1AkUClQIFA1UH5QM1A/UD1Qf1A4UCRQPVA8UH9QPVAkUD5QMVA9 UDVQf1A9UCNQD1AnUDVQPFAzUD9QPVA1UH5QOFAkUD1QPFARUCJQOVAxUDxQcFAeUDVQN1AiUDlQ JFAxUHBQE1AlUCJQI1A5UCZQMVARUCJQOVAxUDxQcFAcUDlQOFAxUCZQP1A5UCRQJVBwUBtQJVAi UCNQOVAmUD9QOVARUCJQOVAxUDxQcFAXUCJQMVAjUHBQGVAkUDFQPFA5UCFQJVA1UBFQIlA5UDFQ PFBwUBZQuVA8UDtQplAmULlQIlBwUDRRAVA8UCRQEVAiUDlQMVA8UHBQF1AiUDFQI1AjUDVQJFAk UD9QcFATUD9QIlAjUDlQJlA/UBFQIlA5UDFQPFBwUAZQNVAkUHBQE1AlUCJQI1A5UDVQNlARUCJQ OVAxUDxQcFAYUDFQPFAmUDZQNVAkUHBQG1AlUCJQI1A5UCZQEVAiUDlQMVA8UHBQAFA/UDdQIlAl UDJQOVA/UD5QMVBwUDtQJVAiUCNQKVAnUDFQEVAiUDlQMVA8UHBQHlA1UDdQIlA5UCRQP1BwUBlQ JFCxUDxQOVAzUD9QEVAiUDlQMVA8UHBUT1RuVGtUE1RmVGhUEFRtVBtUaVBwVEpUE1QQVBFUaFRi UBFQIlA5UDFQPFBwUBtQIlA1UCBQO1A/UHBQIFA/UMpQNVAmUD5QP1ARUCJQOVAxUDxQcFAWUDVQ JFBwUBtQJVAiUCNQOVAmUBFQIlA5UDFQPFBwUBtQMVA8UWFQPlBwUWBQJFAxUDxQOVA7UBFQIlA5 UDFQPFBwUBxQP1A0UDlQcFA1UCRQKlAxUD5QMVBQUFBQY1BjUGNQY1D4UJdRlFKGU/1U31SAVUdV MFZKVihWkFa4V1lXbVfLV65YnlnZWjNbSluCXB5cql3wXbBebl7aXrBff1+aQIVBPUJ8QudDaEOX RGlFTUX6RnFGz0cpR4lIp0mlSjVKuUvMTCNNEU2yTt9Or0+4cORxLnJSciZyzHNDczFzLHPxdO91 DnW4dtF38ngueSJ6ZXqfe/p8531Tfhx/fn/lYDZhb2GeYrVjpmSZZTlmMmfaaN5pf2pQan1qrmsJ ay1r+GuUa41rqGxIbGtsCGwkbMFs5myCbKBtWW1xbW1tDW0sbcht5G2ebbluUW5JbmFuHG41btBu yW7kbp1ut28zb/gQLRFqElkSbxL1EwIUFRVZFcsVlhZKFqMX+xhmGKsZwxp9Gj0bxxzZHUodyh2L Hjwemh9hH9Qf8x+VH7IA7wHHAeQBgAJlAuACoANmA+UDhAOgBPQEnASkBc0F5gWnBjsH8weWB7EH rQhHCGIIHwg8CNwI+QiTCLAIqglDCX8JAAnHCYsKZwrwCroLTwtpCwQLIwvAC4cMPA1rDQQNPQ27 DiwPSA87D6gw9zHMMsgzhzOhNCdQUFBQUI5XUVFRSUJYWK1MrVbEWFdCVlhYWFhYWFhYWFhYWEJW V1dXTHx+fn5+WExXfhhGfkytfnRedH56cV9OX3ZHXlZYr0VYVkp3RUxYQkxMeXdCFGBMd3d3RH9H enpOYH5BWLlHE1ZWVlhWV1ZYWFhYWFhYWFhYWFhYWFhXV1dXV1dXV1dXWELHWFjvBVdBQUBWXlFX AlhOWFhHe1xOV1hYRlFWVldeSQU0WFjjWFhYWFhWVlhYWFjpVlhWWFhYWFhYV1dXVlZWeVZWUV9R WFhMQblWcVhYWHtXVlZWWFhYWFhQUFBQUFNQU1FRUVFRVVNTUVJRUVBIVbxbkFCoWK9QWFBYr65Q WVBZr65QWlBZr65QW1Bbr65QXFBcr61QXVBdr61QXlBdr61QX1Ber61QQFBfr61QQVBfr6xQQlBB r6xQQ1BCr6tQRFBDr6tQRVBDr6tQRlBEr6tQR1BFr6tQSFBGr6pQSVBHr6tQSlBIr6pQS1BKr6pQ TFBKr6pQTVBLr6lQTlBLr6lQT1BMr6lQcFBNr6lQcVBPr6lQclBPr6hQc1Bwr6hQdFBxr6hQdVBy r6hQdlByr6dQd1Bzr6dQeFB1r6dQeVB2r6dQelB2r6ZQe1B3r6ZQfFB4r6ZQfVB5r6ZQflB6r6ZQ f1B8r6ZQYFB9r6ZQYVB9r6VQYlB+r6VQY1B/r6RQZFB/r6RQZVBgr6RQZlBhr6RQZ1Bjr6RQaFBk r6NQaVBkr6NQalBlr6NQa1Bmr6NQbFBnr6NQbVBnr6NQblBpr6JQb1Bqr6JQEFBrr6FQEVBsr6FQ ElBsr6FQE1Btr6FQFFBur6FQFVAQr6FQFlAQr6BQF1ARr6BQGFASr6BQGVATr6BQGlAUr79QG1AU r79QHFAWr79QHVAXr79QHlAYr79QH1AYr75QAFAZr75QAVAar75QAlAbr75QA1Acr75QBFAdr71Q BVAer71QBlAfr71QB1AAr7xQCFAAr7xQCVABr7xQClACr7xQC1AEr7xQDFAFr7xQDVAFr7xQDlAG r7tQD1AHr7tQMFAIr7pQMVAIr7pQMlAKr7pQM1ALr7pQNFAMr7pQNVANr7pQNlANr7lQN1AOr7lQ OFAPr7lQOVAxr7hQOlAxr7lQO1Ayr7hQPFAzr7hQPVA0r7dQPlA1r7dQP1A1r7dQIFA2r7dQIVA4 r7dQIlA5r7dQI1A5r7dQJFA6r7ZQJVA7r7ZQJlA8r7ZQJ1A9r7VQKFA+r7VQKVA/r7VQKlAgr7VQ K1Ahr7VQLFAhr7RQLVAir7RQLlAjr7RQL1Alr7RQ0FAmr7RQ0VAmr7RQ0lAnr7NQ01Aor7NQ1FAp r7JQ1VApr7JQ1lArr7JQ11Asr7JQ2FAtr7JQ2VAvr7FQ2lAvr7FQ21DQr7FQ3FDRr7FQ3VDSr7BQ 3lDTr7BQ31DUr7BQwFDVr7BQwVDWr7BQwlDXr7BQw1DXr49QxFDYr49QxVDar49QxlDbr49Qx1Db r7BQyFDcr49QyVDdr49QylDer45Qy1Dfr45QzFDAr45QzVDBr45QzlDCr45Qz1DDr45Q8FDDr45Q 8VDEr41Q8lDFr45Q81DHr41Q9FDIr41Q9VDIr41Q9lDJr41Q91DKr41Q+FDLr4tQ+VDLr4xQ+lDN r4xQ+1DOr4xQ/FDPr4xQ/VDwr4tQ/lDwr4tQ/1Dxr4tQ4FDyr4tQ4VD0r4pQ4lD0r4pQ41D1r4pQ 5FD2r4pQ5VD3r4pQ5lD4r4lQ51D4r4lQ6FD6r4lQ6VD7r4lQ6lD8r4hQ61D8r4hQ7FD9r4hQ7VD+ r4hQ7lD/r4hQ71Dhr4hQkFDhr4dQkVDir4dQklDjr4dQk1Dkr4dQlFDkr4ZQlVDlr4ZQllDnr4ZQ l1Dor4VQmFDpr4VQmVDpr4VQmlDqr4VQm1Drr4VQnFDsr4VQnVDtr4VQnlDur4RQn1Dvr4RQgFCQ r4RQgVCRr4NQglCRr4NQg1CTr4NQhFCUr4NQhVCVr4NQhlCVr4JQh1CWr4JQiFCXr4JQiVCYr4JQ ilCar4JQi1Car4FQjFCbr4FQjVCcr4FQjlCdr4BQj1Cdr4BQsFCer4BQsVCAr4BQslCBr4BQs1CC r4BQtFCCr4BQtVCDr59QtlCEr59Qt1CFr55QuFCGr55QuVCHr55QulCIr55Qu1CJr55QvFCKr55Q vVCKr51QvlCLr51Qv1CNr51QoFCOr51QoVCOr51QolCPr5xQo1Cwr5xQpFCxr5tQpVCyr5tQplCz r5tQp1C0r5tQqFC1r5tQqVC2r5tQqlC2r5tQq1C3r5tQrFC4r5pQrVC6r5pQrlC7r5lQr1C7r5lQ qFivUFhQWK+uUFlQWa+uUFpQWa+uUFtQW6+uUFxQXK+tUF1QXa+tUF5QXa+tUF9QXq+tUEBQX6+t UEFQX6+sUEJQQK+sUENQQq+rUERQQ6+rUEVQQ6+rUEZQRK+rUEdQRa+rUEhQRq+qUElQR6+rUEpQ SK+qUEtQSq+qUExQSq+qUE1QS6+pUE5QS6+pUE9QTK+pUHBQTa+pUHFQT6+pUHJQT6+oUHNQcK+o UHRQca+oUHVQcq+oUHZQcq+nUHdQc6+nUHhQda+nUHlQdq+nUHpQdq+mUHtQd6+mUHxQeK+mUH1Q ea+mUH5Qeq+mUH9QfK+mUGBQfa+mUGFQfa+lUGJQfq+lUGNQf6+kUGRQf6+kUGVQYK+kUGZQYa+k UGdQY6+kUGhQZK+jUGlQZK+jUGpQZa+jUGtQZq+jUGxQZ6+jUG1QZ6+jUG5Qaa+iUG9Qaq+iUBBQ a6+hUBFQbK+hUBJQbK+hUBNQba+hUBRQbq+hUBVQEK+hUBZQEK+gUBdQEa+gUBhQEq+gUBlQE6+g UBpQFK+/UBtQFK+/UBxQFq+/UB1QF6+/UB5QGK+/UB9QGK++UABQGa++UAFQGq++UAJQHK++UANQ Ha++UARQHa+9UAVQHq+9UAZQH6+9UAdQAa+8UAhQAa+8UAlQAq+8UApQA6+8UAtQBK+8UAxQBa+8 UA1QBa+8UA5QB6+7UA9QCK+7UDBQCa+6UDFQCa+6UDJQCq+6UDNQC6+6UDRQDK+6UDVQDq+6UDZQ Dq+5UDdQD6+5UDhQMK+5UDlQMa+5UDpQMa+5UDtQMq+4UDxQNK+4UD1QNa+3UD5QNq+3UD9QNq+3 UCBQN6+3UCFQOK+3UCJQOa+3UCNQOq+3UCRQO6+3UCVQPK+2UCZQPa+2UCdQPq+1UChQPq+1UClQ IK+1UCpQIa+1UCtQIq+1UCxQIq+0UC1QI6+0UC5QJK+0UC9QJa+0UNBQJ6+0UNFQJ6+0UNJQKK+z UNNQKa+zUNRQKq+yUNVQKq+yUNZQK6+yUNdQLa+yUNhQLq+yUNlQL6+yUNpQL6+yUNtQ0K+xUNxQ 0a+xUN1Q0q+wUN5Q06+wUN9Q1K+wUMBQ1a+xUMFQ1q+xUMJQ16+wUMNQ16+wUMRQ2K+wUMVQ2q+w UMZQ26+PUMdQ26+wUMhQ3K+PUMlQ3a+PUMpQ3q+OUMtQ36+OUMxQwK+OUM1Qwa+OUM5Qwq+OUM9Q w6+OUPBQw6+OUPFQxK+NUPJQxa+OUPNQx6+NUPRQyK+NUPVQyK+NUPZQya+NUPdQyq+NUPhQy6+L UPlQy6+MUPpQza+MUPtQzq+MUPxQz6+MUP1Q8K+LUP5Q8K+LUP9Q8a+LUOBQ8q+LUOFQ9K+KUOJQ 9K+KUONQ9a+KUORQ9q+KUOVQ96+KUOZQ+K+JUOdQ+K+JUOhQ+q+JUOlQ+6+JUOpQ/K+IUOtQ/K+I UOxQ/a+IUO1Q/q+IUO5Q/6+IUO9Q4a+IUJBQ4a+HUJFQ4q+HUJJQ46+HUJNQ5K+HUJRQ5K+GUJVQ 5a+GUJZQ56+GUJdQ6K+FUJhQ6a+FUJlQ6a+FUJpQ6q+FUJtQ66+FUJxQ7K+FUJ1Q7a+FUJ5Q7q+E UJ9Q76+EUIBQkK+EUIFQka+DUIJQka+DUINQk6+DUIRQlK+DUIVQla+DUIZQla+CUIdQlq+CUIhQ l6+CUIlQmK+CUIpQmq+CUItQmq+BUIxQm6+BUI1QnK+BUI5Qna+AUI9Qna+AULBQnq+AULFQgK+A ULJQga+AULNQgq+AULRQgq+AULVQg6+fULZQhK+fULdQha+eULhQhq+eULlQh6+eULpQiK+eULtQ ia+eULxQiq+eUL1Qiq+dUL5Qi6+dUL9Qja+dUKBQjq+dUKFQjq+dUKJQj6+cUKNQsK+cUKRQsa+b UKVQsq+bUKZQs6+bUKdQtK+bUKhQta+bUKlQtq+bUKpQtq+bUKtQt6+bUKxQuK+aUK1Quq+aUK5Q u6+ZUK9Qu6+ZUKhYr1BYUFivrlBZUFmvrlBaUFmvrlBbUFuvrlBcUFyvrVBdUF2vrVBeUF2vrVBf UF6vrVBAUF+vrVBBUF+vrFBCUECvrFBDUEKvq1BEUEOvq1BFUEOvq1BGUESvq1BHUEWvq1BIUEav qlBJUEevq1BKUEivqlBLUEqvqlBMUEqvqVBNUEuvqVBOUEuvqVBPUEyvqVBwUE2vqVBxUE+vqVBy UE+vqFBzUHCvqFB0UHGvqFB1UHKvqFB2UHKvp1B3UHOvp1B4UHWvp1B5UHavp1B6UHavplB7UHev plB8UHivplB9UHmvplB+UHqvplB/UHyvplBgUH2vplBhUH2vpVBiUH6vpVBjUH+vpFBkUH+vpFBl UGCvpFBmUGGvpFBnUGOvpFBoUGSvo1BpUGSvo1BqUGWvo1BrUGavo1BsUGevo1BtUGevo1BuUGmv olBvUGqvolAQUGuvoVARUGyvoVASUGyvoVATUG2voVAUUG6voVAVUBCvoVAWUBCvoFAXUBGvoFAY UBKvoFAZUBSvoFAaUBWvv1AbUBWvv1AcUBavv1AdUBevv1AeUBivv1AfUBivvlAAUBqvvlABUBuv vlACUByvvlADUB2vvlAEUB2vvVAFUB6vvVAGUB+vvVAHUAGvvFAIUAGvvFAJUAKvvFAKUAOvvFAL UASvvFAMUAWvvFANUAWvvFAOUAevu1APUAivu1AwUAmvulAxUAmvulAyUAqvulAzUAuvulA0UAyv ulA1UA6vulA2UA6vuVA3UA+vuVA4UDCvuVA5UDGvuVA6UDGvuVA7UDKvuFA8UDSvuFA9UDWvt1A+ UDavt1A/UDavt1AgUDevt1AhUDivt1AiUDmvt1AjUDqvt1AkUDuvt1AlUDyvtlAmUD2vtlAnUD6v tVAoUD6vtVApUCCvtVAqUCGvtVArUCKvtVAsUCKvtFAtUCOvtFAuUCSvtFAvUCWvtFDQUCevtFDR UCevtFDSUCivs1DTUCmvs1DUUCqvslDVUCqvslDWUCuvslDXUC2vslDYUC6vslDZUC+vslDaUC+v slDbUNCvsVDcUNGvsVDdUNKvsFDeUNOvsFDfUNSvsFDAUNWvsVDBUNavsVDCUNevsFDDUNevsFDE UNivsFDFUNqvsFDGUNuvj1DHUNuvsFDIUNyvj1DJUN2vj1DKUN6vjlDLUN+vjlDMUMCvjlDNUMGv jlDOUMKvjlDPUMOvjlDwUMOvjlDxUMSvjVDyUMWvjlDzUMevjVD0UMivjVD1UMivjVD2UMmvjVD3 UMqvjVD4UMuvi1D5UMuvjFD6UM2vjFD7UM6vjFD8UM+vjFD9UPCvi1D+UPCvi1D/UPGvi1DgUPKv i1DhUPSvilDiUPSvilDjUPWvilDkUPavilDlUPevilDmUPiviVDnUPiviVDoUPqviVDpUPuviVDq UPyviFDrUPyviFDsUP2viFDtUP6viFDuUP+viFDvUOGviFCQUOGvh1CRUOKvh1CSUOOvh1CTUOSv h1CUUOSvhlCVUOWvhlCWUOevhlCXUOivhVCYUOmvhVCZUOmvhVCaUOqvhVCbUOuvhVCcUOyvhVCd UO2vhVCeUO6vhFCfUO+vhFCAUJCvhFCBUJGvg1CCUJGvg1CDUJOvg1CEUJSvg1CFUJWvg1CGUJWv glCHUJavglCIUJevglCJUJivglCKUJqvglCLUJqvgVCMUJuvgVCNUJyvgVCOUJ2vgFCPUJ2vgFCw UJ6vgFCxUICvgFCyUIGvgFCzUIKvgFC0UIKvgFC1UIOvn1C2UISvn1C3UIWvnlC4UIavnlC5UIev nlC6UIivnlC7UImvnlC8UIqvnlC9UIqvnVC+UIuvnVC/UI2vnVCgUI6vnVChUI6vnVCiUI+vnFCj ULCvnFCkULGvm1ClULKvm1CmULOvm1CnULSvm1CoULWvm1CpULavm1CqULavm1CrULevm1CsULiv mlCtULqvmlCuULuvmVCvULuvmehTHONRck8w7VMbUC9TG1BSUBBTGeMTE2Iv71MZUM9TGVCPUxlQ U1AQUxnjYGNiEOhTGeNlZWIQ6FMZ439hYhDoUxnjd3diEOhTGeNydWJfEVxTGVBvUxlQL1MZUJ9T GVCPUxlQVVAQUxnjWUNifxFxUxpQL1MaUFJQ31MaUO9TGlCfUxpQj1MaUL9TGlBVUF9TGlB/UxpQ H1MaUDBTGlDPUxpQVVBfUxpQj1MaUFJQEFMa43lqYhDoUxrjQkRiEOhTGuNbQGIAEUBTGFAvUxhQ z1MYUFNQz1MYUFFQj1MYUL9TGFBSUBBTGONZQGJC6a+QUoziEBFi6a+QUoziaWxi6a+QUo7jbBFi hBFJUo5QUVBgUoxQEFKMUABSjFAwUoxQgFKMULBSjFCgUoxQV1BQUoxQwFKMUPBSjFDgUoziVGfA EXJSm1BRUMBSmFBRUBBSm1BRUBBSmFBRUGBSm1BRUGBSmFBRUHBSm1BRUHBSmFBRUBBS9VBRUvVQ JlDAUvRQ8FL0UFJS9BB1D7BWsFdS71bvV1L/Vv9XUs9Wz1dSH1YfV1JfVl9XUv9W/1dSXxENUxJQ f1MSUB9TElDPUxJQVFBfUxJQb1MSUA9TElD/UxJQkFMSUK9TElBWUH9SZlAvUmZQUlBfUmZQT1Jm UH9SZlBvUmZQH1JmUN9SZlDPUmZQ71JmUFhQ/1JmUFFQX1JmUH9SZlBvUmZQD1JmUC9SZlCvUmZQ VlBAUmVQL1JlUFJQX1JlUH9SZVCAUmVQU1AvUmVQUVBAUmVQb1JlUB9SZVBTUxpTGlMSUxJSZ1Jn UmZSZlJlUmWvkFKc4nFkYumvkFKb4nFkYumvkFKa4nFkYumvkFKZ4nFkYumvkFKY4nFkYuivkOM9 Smxi6K+Q47lKZWLpr5BRC+JKZWLor5DjLEplYuivkOMmSmVi6K+Q4zBKZWLor5DjfkplYuivkOJ6 ZGPor5DiemNj6K+Q4npiY+ivkOJ6YWPor5DiemBj6K+Q4np/Y+ivkOJ6emPor5Dienlj6K+Q4np4 Y+ivkOJ6cWPor5Diekdj6K+Q4npGY+ivkOJ6RWPor5DiekRj6K+Q4npDY+ivkOJ6QmPor5Diel1j 6K+Q4npcY+ivkOJ6W2Por5DjekplYuivkOJ3ZGPor5Did2Nj6K+Q4ndiY+ivkOJ3YWPor5Did2Bj 6K+Q4nd/Y+ivkOJ3emPor5Did3lj6K+Q4nd4Y+ivkOJ3cWPor5Did0dj6K+Q4ndGY+ivkOJ3RWPo r5Did0Rj6K+Q4ndDY+ivkOJ3QmPor5Did11j6K+Q4ndcY+ivkOJ3W2Por5Djd0plYuivkONxSmVi 6FKc4nRlT+hSm+J0ZU/oUpridGVP6FKZ4nRlT+hSmBBbdGVPPXRsT7l0ZU/oUQsQT3RlTyx0ZU8m dGVPMHRlT350ZU96dGVPd3RlT3F0ZU/oU2/i3nlP6FNu43BzTw8RWVNtUD9TbVAvU21Q31NtUFRT aeNwcU9PEUVTaFB/U2hQb1NoUB9TaFBUUM9TaFD/U2hQ71NoUFNQf1NoUG9TaFBSU2XmdGVP329s T+hRSeZ0bE+ndGVP6FHj4nRlT+hR++J0ZU/oUQbidGVP6FEF4nRlT+hRSxAedGVPqnRlT7p0ZU+C dGVPJ3RlTz50ZU8HdGVPHHRlTxN0ZU9tdGVPZXRlT2dRUEKwUaBRUkIgUdBRwFFTUVFQWVFSUFhQ R0dQUFBCQVgQ61JGUFBQWVLZ4jlDT+hR5eJ4N08RRVHkUHhUUVBPUeNRD1RRUE9R4FA5VFFQT1H7 UHdRdVBPUfpQd1EGUE9R8uJ6zk/oUc/iemJP6FHN4np5T+hRNeJ4TU/oUTTieHBP6FEz4nhgT+hR MeJ4EU/oUQvid85PEVlRB1B3WFFQT1EGUHpRylBPUQXietlP6FEE4nrZT+hRA+J6E0/oUU/ieHBP 6FFO4njDTxFbUU1QOVL7UE9RS1B3UvtQT1FJUHpS++JPqnfoVFHiT6l36FL75k+neh9PunroWFHm T7l6KU+FeOhSURBfT4R+nU+CcZ1Pk3h/T5I56FL7EFtPkDmdT+56H0/hdOhUUeJPynroUQYQW0/J emhPwXplTyx+6FRREFtPJ36dTyZ6+08geOhS++JPP0/oVFHiTz5x6FHKEFtPPXfDTzV60U8wd+hR yuZPD3p6Twd+6FF14k8COehSUeJPHH7oUQbmTxtxnU8ZOehS+xBbTxd6e08UOZ1PE3roWFHiTxF4 6FRR4k8Qd+hRURBLT21xtE9remhPZ37rT2V6a09hfrRPc3oVT3I56FEG508FXVldWWfA6FFzEGZX wI1XwCJXwAVXwGRXwH9XwHtXwHZXwHVXwE5XwE1XRFhCWEBYXlhcWFpYWFhWWFRYUlhQWETor7AQ fFBQUVBEVkBQUFFQVlRQUFFQVEBQUFFQQFJQUFFQUlBQUFFQUFJRWFJQGlBC4ENTG1IbAxLgaHsb 6FevAuBnexvgWAALCOFRUd4J4Gh7G+CQM1AbMnDgpgNz6FFaAQrgVXMSUeBCG1AbBBJI4FLY6FFQ BAjoUUnhUVHe1UvgQhMI6VBRUUnV3UvpUFFRSdXdCQkTCOpQz1JGUFEjCVBGJm9Ib0JuQWkWFG5B aRYUbkFpFhRuQWkWFG5BaRYwFG5BaRYwFHt7e3t7e3t7e3t7SHt7e3t7e3t7e3t7exsAKelQT1H4 41dPZld7exsDKelQwFH441fAZld7e0hN4MYbAwjg+k0J4GIbAwjgr00JG+DZA3AMCOlSSFJGFRTp UkdSRhUUCQjpVONSSBUCCOlSSFTjFAkJG+hRygNwDAjpUHBSSBUU6VB0UkgVFAkI6V5YUHAVAgjp UHBeWBQJCRvoUvsDcAwI6VBPUkcVFOlQeFJHFRQJCOlI9VBPFQII6VBPSPUUCQkb6FRRA3AMCOE5 cBUU4XBwFRQJCOlzUFA5FQII6VA5c1AUCQkb6FRRA3AMCOlRD1B0FRThdHQVFAkI6XPwUQ8VAgjp UQ9z8BQJCRvgewNwDAjhd3cVFOF+dxUUCQjpUUxQdxUCCOlQd1FMFAkJG+BlA3AMCOF3dxUU4XF3 FRQJCOlRD1B3FQII6VB3UQ8UCQkb4NwDcAwI4Xd3FRThencVFAkI6VP6UHcVAgjpUHdT+hQJCXt7 e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7e3t7NRIVOQMSURsACOFYUBIJEwwI4VhQEglGQCBu4EITCOldSW71S+pQglO7UFt7CeBa cxLgW3MSUG9vSHtAbFF/DRMMCOIvUVENCQ0TDAjiv1FRDQlWXOBWcxLgV3MS4EITCOlrcUguS+pU UFH4UFt7CeBccxLgXXMS4EITCOl9EX0RS+pUUFRQUFt7CeBecxLgX3MS4EITCOlILmtxS+pR+FRQ UFt7CeBAcxLgQXMSUHt7e3t7e3t7e3t7e3t7e3t7e3t7IyMkeyN7e3t7e3t7e3t7e3tQe3t7e3t7 e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e1BIFTkU FTkUFTkUSBU5FEgVORQjIyQlIyMkJSMkIyQkJCQkIxUUIxUUJFAb4HoDG+BoAQoI4VdXFeAQMBQJ UBvgfgMb4GgBCgjhU1MV4BAwFOFZWRXgEDEUCSMjIyMjIyMjeyQlJHt7exMMCBBhEHpkYxB6Y2MQ emJjEHphYxB6YGMQen9jEHdkYxB3Y2MQd2JjEHdhYxB3YGMQd39j8BFaUptQUVDwUphQUVDPUptQ UVDPUpgQY1EQenpjEHp5YxB3emMQd3ljEHpCYxB3QmMQenhjEHd4YxB6cWMQek1lYhB3TWViEHdx Y1B7e3t7e3t7e3t7e3sjIyMje3t7e3t7e3t7e3t7CVB7IyQle3t7IyQkJXsje3t7e3sle1EjUHtQ UFAQERBvbm1sa2ppaGdmZWRjYmFgf359fHt6eXh3dnV0c3JxcE9OTUxLSklIR0ZFRENCQUBfXl1c W1pZWFdWVVRTUlFQfBVzFjBw4HYw4FR2cxgYfXwVcxZzMXDgdjHgVHZzGBh9fBVzFjDgcDFw4BYw 4FR2cxgYfXwVcxZzMeBwMHDgdjHgcDHgVHZzGBh9fBVzFjDgEDFw4DYw4FR2cxgYfXwVcxZzMeAQ MHDgdjHgEDHgVHZzGBh9fFFAcGxQbH18cBVzcOCdFHNw6FEKAQhzcODdFHMJcOC9AQhzcOAdFHMJ cOBUdgEIc3DgXRRzCXFxfXxwcBVIOBRw4FEwcBXgFiY42hUwFH18UeFbWhNzEzVafXxQ4VpbE3MT W318UOBHcyDhUUduUeBHcyDhUkcVauFSUFhdfXwV4EpzFBXgSXMUfXxwFeBTdRUxNOAAAQgVFEtx cQl9fOBREzNzMuBQcxLgX3t9fHAV4FATMBR9fFHgVhPgVxM1Wn18cDngEDHgUNtw4XyQ2tzoQFAy MHtcNHM0MQwI4FMxCX18FeBBe+BHcxTgRyq0SH18FeBBe+BHcxR9fOBCEwjXFeBBe+BHcxTgRyq0 S1PaFUg5cOBHcxTa2tdw4JABCOBBe+BHcxTgRyq0S3HgRyq0CQlIfXx9fOBSdRYw2hbgEDHcGH18 UUh/fXxw4FN1FeBJcxQV4EpzFBU1cxVw4FN1MDpw4FlzEnM42jowMXDgStrgUAIpceJKShDpr7BQ ShVw2gQIc3Hgb0tzCTEUTOFEUNoCKeNJEHBJFXDaBAhzceBvS3MJMRR9fOFAQRNzE1t9fOFeXxNz E1t9fOFcXRNzE1t9fOFcXRNzEzVbfXzhXl8TcxM1W3184UBBE3MTNVt9fBsCCBUUS3FxCX18UXDg U3VzGeAQMOBwM3DgUAIIc+BSdWhz4FJ1NWhQ2jNoS3FxcXFxCVF9fBvgNAEIFTngWRMw2kBqS3Fx cQl9fFHgVXVAc3DapVDgUTBzvbx9fFHgVXVAc3DapVDgUTFzvbx9fFHgVnVApVC9vH18cOBRMFFA cGxQbH18cOBRMVFAcGxQbH184Ht74Hp6fXxQ4FcT4FYTW318buB6en18ZX18JuhSBnMgQHDoUgYV cOBQAAjgUTEJan9IfXxxcVw0czTb6BBQMn18ceDQAQhcNHM02+hwUDJL4lAQf3sJ4FIwfXxx4JAB CFw0czTb6EUFMkviUNB/ewngUjB9fFw0czTb6BBQMjBzcX185FBRUFBQReBYduBYduBYduBYdl9A RkMVOGrgUUZ9fORQUVBQUEXgWHbgWHbgWHbgWHZfQEZDFTg1auBRRn18GwNzGwEKCHAV2jAUS3Fx CX18GwQIcBXaMBRLcXEJfXwbA3MbAQoIaEtxcQl9fBsECGhLcXEJfXxRGwNzGwEK4FJ14FR14FZ1 GXMVSDkCCgjgUnXgUnXgVXUWcxU5MBgJcXFxfXzgQxMIU0tSCX184EMTCFJLUwl9fBsE4EITDAoI aEtxcQl9fOBCEwwIXOBUdeBUdVZcNHM0MTTgUwEI4FR14FR1UXAW4EAwGHAW4EAwGAlacXFLcXEJ fXzgQhMMCFzgVHXgVHVWXDRzNDE06FdYAQjgVHXgVHVRcBbor6AwGHAW6K+gMBgJWnFxS3FxCX18 GwNzGwEKCOBqe0txcQl9fBsDcxsBCgjga3tLcXEJfXwbA3MbAQrgQhMMCghoS3FxCX18XNpTGwTg VHZSGwQK2tpa4EITDAoIaEtxcQl9fBZzFjDa2hZzcBbaMNox6K/QMnNwQHPa6VMTUxPaIBUwcOBQ AAjgUTHor+rbS+AW3AngQDA4UWp9UFXqUEtV6lBLVfZQS1R2UEtQUK+1UFCvtVBQr7WuO6+1VepQ S648r7VSt1BQUUxQUFFMUFBQUFBQUFBQKlCGUXdRSFClUUJQ/1FNUJpQ5FCIUXpQLFCdUTRQRlBH UKxSdFBwUVVQVlBIUARQ+lCaUVdQCVDjr7lQ+FAHULxUUVDBULBRfFAGUJxRXlBTUAVQzVAeUUWv +1C7UVKvsFBHUGpQAFDAUURVJlWIUdJQVVFTUtWvf1BdVFFQ01BEUG5QzFCDUSxZ5a+FUGdQ7VQc r6FQyFFIUnpQXlAgULZQoFF3UX1SaFINrz1QMVAvUJFRVlMTVcOvfFA+UKxT1q/zr7lQV1ADUAVQ D1AuUMdQu1FuUZBS/1U0UExQb1AYUBpQDVA9UPZQ/VI2VaBQUVBSUHZQPFD4UJdQuFH9UYtTuFOp VFhUDlTcVXWub1BeUHJQY1BoUAdQD1AyUCNQ3FDIUO5RUFFPUQJRyVVirdFQRlBwUHZQYVBoUNBQ 0lDZUONRUFFeUUFRRVEGUc1SLlKfUr5U+VWIr59QdlBkUCZQLlDTUJFQlVC7UKJRVlF+UWBR0lHp UYFSUVIpUqpTcK9Qr+xQeFAXUAJQDFAnUNFQwFDJUOJQ7FCcUZFSHVMTUydT4FS7VKuulFBcUApQ MlArUONQmVCFUIZRQlFMUnZSvFNxU9VT81OcU6VTqVRDVNNUq66wUHJQYFBhUBxQHFADUA1QI1Aq UNdQ3lDxUPtQ5lDqUJFQgFCBUItQtVFFUWhRO1EsUc5R61GmUapScVJyUmxSP1LFUuBS6lKyU0ZT AVMEUyFTxlPKU5ZTg1RBVBJUG1TNVOZUilZ9VrhXMa71rrOvHq8Ir9Gvwq/rr5Kvg6++UFlQXVBy UHNQfFA5UDxQIVAnUC9Q3FD+UO5Q7lCYUIdQiVCKUIxQtVClUVBRXFFLUWVRGlEDUQVRPFEiUd5R 31HEUchRlVGeUlpSQVJFUh9SAFI3UtZSmFKfU2lTa1PoVHhUYlQVVApUO1QkVNZVYlViVR1V3FX4 VfpV+1WgVaxWQlb6WFBYnK16rY6uOK4mro2vWq9er06vYK85r6VQVVBOUGhQMVA3UNdQy1DxUPRQ 9lD8UJBQlFCcUIFQhFCJUIxQjVCOUI9QtVCjUKxRRFFGUUhRSFFLUXxRblEeUTpRKFHRUdJRyFHL UfNR5lHoUexRk1GdUYBRgVGCUYhRsVGyUbpRvlGgUlNSSVJPUnNSe1IPUjhSL1IvUtZSw1LJUspS mlKfUp9SgFKGUrhSvVNAU3JTf1NoU2hTbFMRUxJT2lP7U4BURVRHVBJUH1QlVCpUzVT2VJBUkVSB VLNVUFVAVUNVdFV8VRtV21WQVZdVoFWsVl5WSFZ2Vj5W01bUVvVW6FdUV0ZXZlfSV9lXy1fxV4RY RFhzWPBY61FLUXhRSVFKUFBQUFBQUFBQUFBQUQhRllD/UxxRCVHXUQRRXVHaUQlQRFJ7UPFUIVIa VMxS31J6UvtQUFBQVmlU4FBQUFBT+VDeU1FSX1TAU8FRxFDlUVFQa1DUUW5QJ1HCUNxQllEgUItQ fFDKU+9TrlIWUVBTUFH0UWhQplOfUFCvhVGTUWRRYVEXUBpSmFSeVZcM11J0Ug5RiVQOVllUllDD UutUMFRlVFFR5lEpUVBQ2FPdUGZQvlMjU7RQnFE9VMBQ7lEsUVRQbVJrUKRRVFCGUVxRQFF1Un5Q b1EZU0lRAFM2UUpRS1EpUVBQhVA+UDlS4VJvUJRRxFI7U3hRK1FiUKVQrlDjVZNQyVUCVIWvHlTl r3BQrlAqUFBQUFD6Un5Q4FBQUdxTMFR5rweup1HXU0hSkVN2Um1RolQxUjmu/lEfUWRStVNhUSNS JFGrUeNReFD2UJpSHVIRUUpS9FBdUKVQvFCMUKxQoVDiVMNT3a+OU/uuAVLsUHRVDFCCUKBRVlAB UupRo1CDUPpQ7lIvUlhQiFH9VGZQ5VM+UKBTMFLoUq1Rp1KnUM5Q/lE0UP9Sd1GLUhBQvVYPVLBR tT9eUU5TNlA9UFJQ9VBWUDJTvlARr7FQT1Ekr5+v71FLUh9S6lDZUKFVk1I/UMJQK1DuUMlQLlDI UDFQo1A8UFxRKVBVUF5QXlDjUPFQolADUEdQU1BVUFdQPlAnUMpQGlDqUCNQhVANULhQ8VCMUKZQ L1DJUItSUVAAVsxRVlCgUJJQpVCqUVhQ6VBiUP9RXlBoULSvplSCUFBQ5FDZU1FQk1dDVm5U1lDt Ve9QUFZQUVBQUFBQUmlQUFJpUFBS+lAuU5tRf1QjUDJUI1AKV01Q6lWXUPpRt1FmUvpQ11L6rzBT TVCZVPxQ9VJpUEVS+lAfUmlQClJpr/dUI1DUVCNQo1QjUCxUI1A4VCNQaFQjUNJUI1D2VCNQhFQj UNdUI1DSUvpQwFL6UANU/FD/VPxQ9VT8UP9Us1CsV51Q1VWXr7lVl1ACVZdQklWXUAlVBlAEVLNQ AFZpUOVVl1AJUmlQF1QjUGtVl1ABVLNQDFb6UANVl1AMVmlQ41UGUANWaVDjVZdQClUGUC5Us1Cm VZdQ61UGULhX3VCgVQavklUGULtUs1BjUvpQRFJpUPBS+q/eVPxQh1Qjr71S+lFCVCNQDFSzUBpU I1ArVLNQKVQjUCdS+lA+VLNQEFSzUAZSaVACUmmvcFQjUB1SaVAAV01QGVSzUAZUs1AsVLOvpVSz UCpTTVASVCNQfVL6UMpUs1DAVCNQyVZpUMNUI6+DVCNQXVRQUHJTTVAGUm1Q4FNNrwJU/FDZVZev vVWXr7lVl1CSVQZQBFWXUAxWaVDjVZdQ61QjUAxUI1AMVCNQDFQjUAxUI1AUVCNQDFQjUCpUI1An VCNQJ1QjUCdUI1AnUmlQAlJpUAJSaVACUmlQAlSzUAZUs1AsVLNQLFSzUCxUs1AsVLNQLFSzUMBU s1DAVLNQwFSzUMBUI1D9U2NQsVQjUChUI1B6VCNQfFKdUPZUI1AKVLNQGFW1UAlVtVAJWFBReFL6 UShS+lD9WFCv7lZpUM9UNFDSVCNQYVTMr+RSplD4UrxQxFdNUG9Us1A8VLNQZ1L6UEhU/FD1VCOv vFQjUPhUI1B+WFBQ7lWXr7lVl6+5VmlQ41hQUN1X3VAnVCOvrFhQUFBUUFFQVFBRV1JpUI9SaVCt VDRQ0lQjUF1VBlC7VCNQ11L6UCpS+lBEVCOvrlJpUMNSaVBFVFBQV1hQUNtVl6+iVQZQBFWXr7lV BlAEVQZQBFJpUBdSaVAXUmlQF1JpUBdWaVDjVmlQ41ZpUONVl1DrVZdQ61WXUOtSaVACUvpQI1L6 UO5S+lFkUvpQXlL6ULBVBlAuVCNQfVSzUGNUUFByUm1Q4FWXUBtUs1AsVQZQu1QjUF1VBlADVLOv vVT8UO1S+lC7UvpQ+FL6UMxW/FD+VvxQnFb8UMtUO1DcVCNQZ1BQUEhQUFCwW1tYUFNTU1VWVlhY U1RUVFZTVFNTVlZWVlZWVlZWVlRUVlZWVlpYWFhYV1dZWFNWWFdbWFlYWVhXV1hXW1hXV1RTVFZW VFdXVldWVFdXVFRXVFpXV1dXVVVUV1ZYVVZWVFNUVlhYWFdYWVhXV1dXV1dWVlZWVlRUVFRXV1dX V1dXV1dXVlRWVlZUVldZWVtUVFtZV1ZXVFRaV1ZUVlZWV1tYWFlbWlZbVlZTU1ZWV1ZUVFZTU1Za WFdYV1dTU1NTWVlZWFhYVFRUVFRUV1VXVlNYV1dWV1dWVFRUWVlZVlZcXFlQU1NUVldXW1lTVFRV V1NUU1NXV1dXV1dXV1dXVFRXV1dXW1lYWVlYV1lZU1ZZV1tZWVhZWVhXWVlcWFhXVFNUV1dUV1dX V1dUV1dTU1dTW1dXV1hVV1RXV1pWV1ZVU1VXWVlZWFlZWVdXV1dXV1dXV1dXU1NTU1dXV1dXV1dX V1dXVVdXV1RXV1paW1RUXFlXV1dUVFtXV1RXV1dXXFlZWVtbV1xWVlNTV1dYV1RUV1NTVlpZWFlY WFNTU1NZWVlZWVlTVFRUVFRYV1dWU1lXWFdYV1dUVFRaWlpXV11eWlBUVFRWV1dbWVNUVFVYVFRU VFdXV1dXV1dXV1dUVFhYWFhcWllZWVlYWllTV1lYXFlaWFpZWVhZWV1ZWVlUVFRYV1RXWFdYV1RY WFRUWFRcWFhYWFVWVFhXWldXV1VTVVhaWllZWVpZV1dXV1dXV1dXV1dUVFRUWFhYWFhYWFhYWFdV V1dXVVdYW1tdVFVdWlhXWFVVXFhYVFhXV1ddWlpaXlxXXVdXU1RXV1lXVFRXVFRXW1pZWllZU1NT U1paWllZWVRUVFRUVFlWWVdTWVhZV1lYWFRUVFtbW1dXX0FbUFRUVVdYWF1bU1VVVllUVVRUWFhY WFhYWFhYWFVVWVlZWV9bW1tbWllcW1NYW1ldW1xaXFtaWVtaXlpZWVVUVFhYVVhZWFlYVVlZVFRY VF5ZWVlZVlhVWVhcWFhXVlRWWVtbW1pbXFtYWFhYWFhYWFhYWFRUVFRZWVlZWVlZWVlZWFZYWFhV WFlcXF5VVV9cWVhYVlVdWVlVWVhYWF9bW1xfXlhfWFhUVFhYWVhVVVhUVFhBW1pbWlpTU1NTXFxc W1tbVFVVVVVVWlhZV1RbWVlYWllZVVVVXV1dWFhAQVxQVFRVV1lZXlxTVVZWWVRVVFRZWVlZWVlZ WVlZVVVZWVlaQFxbXFxbWlxcVVlcWl5cXFtcXFtaXFtfW1paVVRUWVlVWVpYWVlVWVpUVFlUXlpa WVlWWVVaWV1ZWVdWVFZZXFxcW1xcXFlZWVlZWVhZWVlZVFRUVFpaWlpaWlpaWlpZVllZWVVZWl1d QFVVQFxZWVlWVl5ZWlVZWVlYQFxcXEBfWUBYWFRUWVlaWVVVWVRUWEFcW1xbW1VVVVVcXFxcXFxU VVVVVVVbWVpXVFxaWllbWllVVVVdXV1ZWUFBXVBVVVVXWVlfXFNWVldaVFZVVVlZWVlZWVlZWVlV VlpaWlpBXFxcXFtaXVxVWVxaX1xdW11cW1pcW0BbW1pWVVZZWVZZWllZWVVZWlRUWFReWlpZWVdZ VVpZXVlZWVdUV1pcXFxbXF1cWVlZWVlZWVlZWVlUVFRUWlpaWlpaWlpaWllWWVlZVVlaXV1BVlZB XVpZWVZWX1paVlpZWVhBXFxdQUBZQVlZVFVZWVtZVlZZVVVZQVxbXFtbVVVVVV1dXVxcXFRWVlZW VltZWllUXFpbWVtaWlZWVl5eXllZQ0ReUFVVVllbW0BeVFZXV1tVVlVVW1tbW1tbW1tbW1ZWW1tb XENeXV5eXVxfXlRbXlxCXl9dX15dXF5dQl1dXFZVV1tbVltcW1xbVlxcVlZbVkJcXFxcWFtWXFte W1taV1ZXW15eXl1eX15bW1tbW1tbW1tbW1ZWVlZcXFxcXFxcXFxcW1hbW1tXW1xeXkNWVkNfW1tb V1dBXFxVW1tbW0NeXl9DQltDWlpVVVpbXVtWVltVVVpEXl1eXV1UVFRUX19fXl5eVlZWVlZWXVtc WlReXF1bXVxbVlZWQEBAW1tFRUBQVlZWWlxcQ19VV1dYXFZXVlZcXFxcXFxcXFxcV1dcXFxdRV9e X19eXUBfVltfXUJfQF5AX15dX15EXl5dV1ZXXFxXXF1cXVxXXV1WVlxWRF1dXV1YXFddXEBcXFtY VlhcX19fXl9AX1xcXFxcXFxcXFxcVlZWVl1dXV1dXV1dXV1cWFxcXFdcXV9fRVdXRUBcXFxYWENd XVZcXFxbRV9fQEVEXEVbW1VWXFxeXFdXXFZWW0RfXl9eXlZWVlZAQEBfX19WV1dXV1deXF1bVl9c XlxeXVxXV1dCQkJcXEhIQlBXV1dbXV1EQVVYWFleV1hXV11dXV1dXV1dXV1YWF5eXl9HQEBBQUBf Q0FWXUFfREFDQENBQF9BQEdAQF9YV1heXVhdX11fXVheX1dXXVdFX15fX1ldWF5dQ11dXFlXWV5A QEFAQUNBXV1dXV1dXV1dXV1XV1dXX15eXl5eXl5eXl1aXV1dWF1fQkJIWFhIQ11dXVlZRV5fV15d XV1IQEBDSEZdSFxcVlddXUBdWFhdV1dcR0BAQEBAVlZWVkNDQ0FBQVdYWFhYWEBdX1xXQV5AXUBf XlhYWERERF1dS0tEUFhYWV1fX0hDVllaW0BYWVhYX19fX19fX19fX1lZQEBAQEpDQ0NDQkBFRFhf Q0BIREVCRUNCQERBSUJCQVlYWUBfWV9AX0BfWUBAV1dfV0lAQEBAW19ZQF9FX19eW1dbQENDQ0JE RURfX19fX19fX19fX1dXV1dAQEBAQEBAQEBAX1tAX19ZX0FEREtZWUtFX19AWlpIQUFYQF9fX0tD Q0VLSV9LXl5YWF9fQl9ZWV9YWF5LQ0JDQkJYWFhYRUVFREREV1lZWVlZQl9BXldEQUJfQkFAWVlZ R0dHX19NTkZQWFhaXkBASkVWWlpbQVhaWFhAQEBAQEBAQEBAWlpBQUFCTERFREVDQkdFWEBFQkhF RkNGRUNCRURLQ0NCWlhbQUBaQEJAQkBaQkJYWEBYSkJCQkJbQFpCQEZfQF9bV1tBREREQ0VGRUBA QEBAQEBAQEBAWFhYWEJCQkJCQkJCQkJAXEFAQFpAQkVFTVpaTUdAQEBbW0pBQllBQEBATURERk1L QE5fX1hYQEBDQFpaQFhYX01EQ0RDQ1hYWFhGRkZFRUVYWlpaWlpDQEJfWEVCQ0BDQkFaWlpISEhA QHBxSFBZWVtfQkJMR1dbW1xDWVtZWUJCQkJCQkJCQkJbW0NDQ0RPRkdHR0VESUdZQkdES0dJRUlH RUNHRU5FRURbWVtDQltCREJEQltERFlZQllMRERERFxCW0NBSUJCQFxZXENGRkdFR0lHQkJCQkJC QkJCQkJZWVlZREREREREQ0NDQ0JdQkJCW0JESEhwW1twSUJCQlxcTEREW0NCQkJwRkZJcE5CcUBA WFlCQkVCW1tCWVlAcUZFRkVFWVlZWUlJSUdHR1lbW1tbW0VCREBYR0NFQkVEQ1tbW0tLS0JCcXJJ UFlZW0BCQkxIV1tbXUNZW1lZQkJCQkJCQkJCQltbQ0NDRHBISEhIRkRKSFlCR0RNR0pGSkhFREhG T0ZGRFtZXENCW0JEQkRCW0REWVlCWU1EREREXUJbREJKQkJBXVldQ0hISEZHSkhCQkJCQkJCQkJC QllZWVlEREREREREREREQl1DQkJcQkRISHFbW3FKQ0JDXFxNRERbQ0JCQnFISEpxT0JyQUFaWUJC RkJbW0JZWUFySEZIRkZZWVlZSkpKSEhIWVtbW1tbRUJEQVlIREZCRkRDW1tbTExMQkJ1dkxQWlpc QkVFcUtYXF1eRlpcWlpFRUVFRUVFRUVFXFxGRkZHdEtLS0tJR01LWkVLR05LTUlNS0lHS0lzSElH XFpcRkVcRUdFR0VcR0daWkVacEdHR0deRVxHRU1FRUNeWl5FS0tLSUtNS0VFRUVFRUVFRUVFWlpa WkdHR0dHR0dHR0dFX0VFRVxER0tLdVxcdU1FRUVeXnFHR1xGRUVFdUtLTXVzRHZDQ1paREVJRVxc RVpaQ3VLSUtJSVpaWlpNTU1LS0taXFxcXFxJRUdDWktHSUVJR0ZcXFxPT09ERXp8cFBcXF5ER0d0 TlleX0BJXF5cXEdHR0dHR0dHR0deXklJSUp6Tk5OTkxKcU5bR05KdE5xTHFOTEpOTHhMTEpeXF9J R15HSkdKR15KSlxcR1x1SkpKSkBGXkpHcUdHRUBcQElOTk5MTnFOR0dHR0dHR0dHR0dcXFxcSkpK SkpKSkpKSkdBSEdHXkdKT096Xl56cUdHSEBfdUlKXklHR0d6Tk5xenhHe0VFW1xHR0xHXl5HXFxF fE5MTkxMW1tbW3FxcU5OTlxeXl5eXkxGSkVbTkpMR0xJSV5eXnNzc0dHfn9zUF1dX0ZKSndxWl9A QktdX11dSkpKSkpKSkpKSl9fS0tLTH1xcXFxT0x0cV1KcUx3cXRPdHFPTHFPe09PTF9dX0tKX0pM SkxKX0xMXV1KXXhMTExMQklfTEp0SUpHQl1CS3FxcU9xdHFKSkpKSkpKSkpKSl1dXV1MTExMTExM TExMSkJKSkpfSUxycn5fX350SUpLQUF5TExfS0pKSn5xcXR+e0l/R0dcXUlKT0pfX0pdXUd8cU9x T09dXV1ddHR0cXFxXV9fX19fT0lMR11xTE9KT0xLX19fdnZ2SUpiY3ZQXl5BSExMfHRbQUFDTV5B Xl5MTExMTExMTExMQUFNTU1PYXR0dHRxT3d0XUx0T3p0d3F3dHFPdHF/cXFPQV5BTUxBTE9MT0xB T09eXkxefE9PT09DTEFPTHdMTElDXUNNdHR0cXR3dExMTExMTExMTExMXl5eXk9PT09PT09PT09M RE1MTEFMT3V1YkFBYndLTE1DQnxPT0FNTExMYnR0d2J/TGNJSV1eS0xxTEFBTF5eSWJ0cXRxcV1d XV13d3d0dHReQUFBQUFxTE9JXXRPcUxxT01BQUF6enpMTGZneVBfX0JKTk5/d1xCQkVwX0JfX05O Tk5OTk5OTk5CQnBwcHFld3d3d3RxendfTndxfHd6dHp3dHF3dGN0dHFCX0JwTkJOcU5xTkJxcV9f Tl9gcXFxcUVOQnFOek5OS0VARXB3d3d0d3p3Tk5OTk5OTk5OTk5fX19fcXFxcXFxcXFxcU5GTk5O QU5xeHhmQkJmek5OT0REYHFxQnBOTk5md3d6ZmNOZ0tLXl9OTnROQkJOX19LZnd0d3R0X19fX3p6 end3d19CQkJCQnROcUtfd3F0TnRxcEJCQn19fU5Oamt8UEBAQ0xwcGB6XUNER3JAQ0BAcHBwcHBw cHBwcENDcnJyc2l6enp6d3N9ekBwenNhen13fXp3c3p3Z3d3c0NARHJwQ3BzcHNwQ3NzQEBwQGRz c3NzR3BDc3B9cHBNR0BHcnp6end6fXpwcHBwcHBwcHBwcEBAQEBzc3Nzc3Nzc3NzcEdxcHBEcHN7 e2pDQ2p9cHBxRUVkc3NDcnBwcGp6en1qZ3BrTU1fQHBwd3BDQ3BAQE1mend6d3dAQEBAfX19enp6 QENDQ0NDd3BzTUB6c3dwd3NyQ0NDYGBgcHATFmJQQ0NGcHV1bGBfRkZKd0NGQ0N1dXV1dXV1dXV1 RkZ3d3d5EWBgYGB9eWRgQnVgeWdgZH1kYH15YH1vfX15RkNHd3VGdXl1eXVGeXlDQ3VCbHl5eXlK dUZ5dWR1dXJKQ0p3YGBgfWBkYHV1dXV1dXV1dXV1Q0NDQ3l5eXl5eXl5eXl1S3Z1dUZ1eWFhE0ZG E2R1dXdJSGx5eUZ3dXV1E2BgZBNvdRRyckFDdXV9dUZGdUNDchZgfWB9fUJCQkJkZGRgYGBDRkZG RkZ9dXlyQmB5fXV9eXdGRkZoaGh1dRsAaFBFRUl0enoUZkFJSE18RUlFRXp6enp6enp6enpJSXx8 fH4aZmZmZmJ+amZFemZ+bWZqYmpmYn5mYhdiYn5JRUp8ekl6fnp+ekl+fkVFekUTfn5+fk16SX56 anp6dk1ETXxmZmZiZmpmenp6enp6enp6enpFRUVFfn5+fn5+fn5+fnpOe3p6SHl+Z2cbSUkbanp6 e0xLE35+SXx6enobZmZqGxd5HHZ2Q0V5emJ6SUl6RUV2AGZiZmJiRUVFRWpqamZmZkVJSUlJSWJ6 fnZEZn5iemJ+fElJSW9vb3l6AwpuUEdHTHd+fhtsQkxLcGBHTEdHfn5+fn5+fn5+fkxMYGBgYwFs bGxsZ2MRbEd+bGMTbBFnEWxnY2xnHmdnY0xHTGB+TH5jfmN+TGNjR0d+RxpjY2NjcH5MY34Rfn56 cEdwYGxsbGdsEWx+fn5+fn5+fn5+fkdHR0djY2NjY2NjY2NjfnF/fn5LfmNtbQNMTAMRfn5gT04a Y2NMYH5+fgNsbBEDHn4EenpGR35+Z35MTH5HR3oKbGdsZ2dHR0dHERERbGxsR0xMTExMZ35jekds Y2d+Z2NgTExMFRUVfn4MDhVQSkpPfGNjAhJFT050ZkpPSkpjY2NjY2NjY2NjT09mZmZoChISEhJt aBgSSmMSaB0SGG0YEm1oEm0HbW1oT0pxZmNPY2hjaGNPaGhKSmNKAmhoaGh0Y09oYxhjY350SnRm EhISbRIYEmNjY2NjY2NjY2NjSkpKSmhoaGhoaGhoaGhjdWVjY09jaBQUDE9PDBhjY2VycgJoaE9m Y2NjDBISGAwHYw5+fklKY2NtY09PY0pKfg4SbRJtbUpKSkoYGBgSEhJKT09PT09tY2h+ShJobWNt aGZPT08dHR1jYzQ4G1BMTHF/aGgKGEZxcXdqTHFMTGhoaGhoaGhoaGhxcWpqam0yGBgYGBNtHhhM aBhtAxgeEx4YE20YEw4TE21xTHJqaHFobWhtaHFtbUxMaEwJbW1tbXdocW1oHmhoYndLd2oYGBgT GB4YaGhoaGhoaGhoaGhMTExMbW1tbW1tbW1tbWh4amhocmdtGho0cXE0HmdoanV1CW1tcWpoaGg0 GBgeNA5nNmJiS0xnaBNocXFoTExiOBgTGBMTTExMTB4eHhgYGExxcXFxcRNobWJMGG0TaBNtanFx cQMDA2doUFJRUFBQVVBVUFBTUFdQbORSUedWV+hSpRBIUFVU51NQWldU51FQSVhWVedSU+BZ745I e0CmbK1sHkCkbB2tbFBvbK1sQKxsrWxhYHFBcUF1cUFxUVBUUKxwU5CsEFVQq1BwVJBQUFJQLlBQ UoNV6lBVUFlQ5BBFUBBiSW9REGJJb1dAS09kVkBLT2RX6K+Y40JFZFbor5gQf0JFZFRb0EE0ZlBR QFFwWxhV4FuQW4BbV1BRUVVXWFhUUlZZWVNQX1FPUVJfUVFR6FN6EFpWVFNQV1YZWVpQ61NwUFhQ UVEB41lUIFPoUpAQX1gZUFlAWXBZU1mmWv/qSHtApg29pL1AtEC0UG+tbG9sQKYhDWzXVS1AlF6U 11VAbF6UYWBRIQ17e3t7e1B7e1FzQ0NxU1FxU3FR8s4KGFF9Ha5iUUxqrrRRJVK8UQmu3ayerrtQ r69RZlPhVF5V6lB2UFpQUFFXUFpRPFBQUHTjUVFWUOhRwxBFGHdXU1dUYFNgWSBd0F1WUFFSWFB5 UHtRDXtQUlBCr7dUC1WDUEtQT1HdEI8QURBSNlM2VDZMNk3LVMxYx0HGSstM/FD7U/hX+Vr8SfxK +0v7TYhYiVyAQ4BEhkaGR4ZKhku4VLhPTdZGiViJXIZFhklVUFFES1hTUkNLWFRVQEtYV1ZfS1ha Vl9KWVtWX0dcXlZfRl1BVUBGXUJSQ0ZdRVFERl1IUURHXElRREpZTFVASllNUkNKWU5SQ0dcT1VA R1xVVlFDRHFfWFlKShBLWERLS1hcXUZGEEdcREdHXEBVEF9WMV1dXFxZWXhYUENSEERRMUtKSkdH eEZaVlaKWVlQUKpZWVmIWV1d6FEB519ZX0Q/RFFE6FNiEFxZR89H/0dSR4hZS0voUQHnWU9RUWBR UVHoUq7jcA03SHseQKQNInsqHaBRSH97KqANUUh/eyqhDVFIf2x7KkCgUUh/eyqgUUh/eyqxUUh/ eypAsVFIf1Bve2xAbEBsUKRsrWxve2xAbEBsUECkbK1s11V+e9ctlNd+SHvXLZRRQUJpaUJpaV9f X19fX19fX19fX19fX19hYFEhDUNzZWNDc2VxQ2NTY0NjU2NFc1NjRXFTc0NzU3NRU2NDytjkbKBR TR+wH40duADa52yjrrAfjx2OH7JRyGuOalE9jFF3jVHWripR1q4qja6JjK4qUdauKlPZrolRd1BT UAqvZVTMVnlQcVB3UH5R2BA7RXJ5WXBLFlz5eJRKukdXWkNaRFxHXXVUWEh2VnVXdXh2eWNWakho c2N5B10JTjhbP2DJV8pYykfKSMpJynLKc4hHRVhJWHIWTxp6VEh5Ql9Wc1B5T3hCSElPeHlwcEFQ VldfcnNxcUBT5lTtUf1QeVBxUfFQeVKGEFxPReZfRlHPRlFGNXPqUoZQQVLf5V9VeE9dQehRzOcf QA9Aj0BTQOtSi1BaUHBRzBBcUHFAcRBx8HGPcVVx7VKKUExQRVKHUEavkBBeYmV/Rm9GgEa/Rq9G VUboUj/lcHxgfFJ86FKHEEJQTEBMYEwATMBM8EzgTJBMWEzoURwQWjBgUWB/dm92UnbtUodQWlBT UodQVFKJEEEAWjBa4FpTUFpAWmBaEFpUWuxSiFB/UKRSgFBIe0CkDQ2kvUC9DUANpg29DaQNe71A rQ29QKQNvVBve29QvK2tDSG0QL20QK20V1VAbF5sVWxebGxsV1VAbF5sVWxebGxse0FCaUFpQmlC aWFgUSENUCENVXZ2d2dGR0N2dmVkZmZjR2djV0ZGR1d2d1NGRkVEUHNXc0NDdlZFRENTZmZlZHZR /d/oXK1DIgzPwyWHMGVC30bRzF2mQh8D4suusrh137ocBSGWBCEraFpztfxd/GRR6haNKDybIVEG N3Do310/fK4iGIfakK6j4FQxUTtRPRsgriquP1kqBGcAUFVQ6q+RVrpVg1BcUElQTVB6UGdRVhBl V1hRSlJLWExYTVd2X2lpTGlNNFI5WDhMOE00cDl2MGkjSiNLKkwpTdVK1UvHSkcZTFFNSkroUo4Q XktMREtLTEpLTE1UaWhA6FKN4lqXRuhSjRBbU01MTFNRS0oVeGToUo3icZd+6FKN5nhbaUdHSnTo UowQQ19hYGGQYYBhVDBhIGHgYVNh4HvoUowQXUBO4E5SUE7QTlJO4FboUowQR2BDUV9DUWBDkEOA Q1MwQyBD4ENTQ+Bd6FKMEFxQUFEQUFFQSWj/M0h7HkCkIQ0draYNISEiraYNIa2mDSGtHhU1FLZQ bx29rb1ApGxvbEBsQL2tvVFBQkdp1357LUCUYWBRIQ1DZEJjYkZFRFZWc3J2Z0RGY2JmZWR2c3JW VkNzUWNRZEJjYkZFRFZWc3J2Z0RGY2JmZWR2c3JWVuqe6S7HN+I+LMmDfHYYMX51ehNrCLdUlrat 9J7pLsc34j4syYJ8dxgxfnV6E2xTo+9RcfDfJr4/zD9jf4kpfGEVmav2VkKrQu9RcvDfJr8+zD9j f4gpfWEVmVBTUPqvjlX2VYNQdVBhUGpRXxDWcGxRWVRbWlV2X2pLWkV2f1tvWjtiNmkoWyB0Jnb2 dPN3o2lAW1pWcnpYfVp2dRlYH1pXVFRUS0h2dU51T3RwcXI2VDxFOWknVNZU1lvZSNlJznT2VORU lFSaRaxpRQBnUUViR2l2cFNgWnR6V1ZUUVBVbE1WWl1pYnZ0cEVUUVBZZ3B9UX3oU3cQWUpRZ3dd W1dbeuhTTeMvTVFN6FEo5kBiYOBgUmDoUogQSBBH0EdSRxBAQWRfR1H/R69HUkew8GRRZOhR4xBb UEBAQFJASWvCN0h7HkCkDR2tDaYNIXshvQ1ArQ29UG9vvW+9IUFHaUJpaVFBQkdpQmlpQUdpQmlp UA1hYFENUCENUSFRR1ZWV0ZHV3Z2d1ZWc3J0ZWRmZ2ZndmVkZmNiRkVEVldGR0ZHZlFmZ2ZlZHZz clZFRFNWRURGY2JndlSHn00NeGkJ5XI5dBiKLrSurDcCa9URsejO6c/maQVjT2Ou1SZgcmdgbAAP liYyJy7HUi4saNN1bRvsQgZ2aRyh/z/vFGEX3TnKgvcgD40MMCwccWNRimxtfH15ZQMTEK41M/IM JgPoUFFRZlPhUvJV6lBVUA4QaFZTVlRfV0BQQ1FEU0BUQFVwU3VUYFNkVARU11PjU+NU41WSU5JU g1REVVRTU1JXUVFVilJQV7dR6FNwEFlQUFFQSVaGuEh7HkCkDR2kpFBvrWlRQUJpR2JhYFENUUNn cVdTUWZVZVFiZThT4VFBqKiuv1BRUNeuAVMsVYNQQFAbEE1bUExQR1p/UAdS2FlWWUBRQlDSXlG3 VFqqUFlRWehRdRBdXgdQVEBUD1RTVElB1OlRSlBIex5ApA0dvaQhvUC0QLRQb29hYFENUXN2UmVk QmdmZ2NWUlJFREJRu5MCH9PXBeyK7582fa4B71HX85xRy4XYhbCuJq5gjsautFBQUa8wrgFSBVWD UEBQABBfXVJMUnBQU9BCUVlCUUBB6FEyEFxQ0l5aql9ZUU9ZUVnoUXUQXFG3XgdvVB9UUlRKQuhR 5uEaSHseQKYNHb20pA0hvUC0tlBvb2FgUSENQ2NGQkVEUldWV3NmQkJlZFKhkwIf09cG64runzZ8 VYPurijynK41htiFsFHYUYGPx1FLUFBRUExTSFKhVYNQTlFbEDkKXMtcUl9NQVpEW0VDQURBRR9N V14QcXNkQF1CXkxfT0B3XHRfd0B6QXhMdk5lXGdeZ19sQWlMZk4qTNZI2UnEW8Jcz0PPRMhJiEiJ TLpTqUxMWUBJQHlAFFEZSRpLGkwqXKlcqV1aSFXqUUBQQVKr5lxcWVpLO1HoUR/iTBVQ7VF7UF5Q RlNPUFlS+OJFFVroU0AQQF9eTV5RVVxBTUheX1dGWUzoUc0QWc9Lr0tSS/hGUOhRzRBMwFGgUVJR +FlF+EBGUUaWWvhQWUBZUllJT/8lSHseQKQNHbStDbRApA29QKQNvUFCR2lQb39AbKS0rLVArbSk tkFCaX+1rWxhYFEhDXtQDVEiQ3dmZ2Zndnd2d2dGR3ZlY0RXZmdmZ0dWV0dGR1d3VqXHGB5PWEkm BUtr0zdI4ktEEgocZT/CKHRFyddtU0glARpOWFRNRVrgZRDzNxmTWE95TeVJSNd5SjWPPFBRUAVQ g1QGVIRQW1DZEEQPUA9bUlhTWVIAVVFVMWBTEFNSU+hSABBEUjFvUB9QUlAAWFFYMVZgWhBaUlro UgAQdlUAUVFRMQBSMFLgUlNfUjBS8FLgUlRQUkBSb1IfUs9Sj1KvUldS6K+Q40NJZFLoUqzjXBYa SHtApnsNISKkDWytDWy0DVB/DaStDbQNQGxAbGFgUA11QXFBcUFxQXFBcUFRha7QUdBRUFHRri+D US1RV1EtrtOuqa7TUFFQRa6SUeNRRVBaUDAQedtT21fQXFNaWFHaU1FYV1lWVlVSUVpW7VVZVddQ GVpaUVlRUFlAWVJZ6FEBEEBaURla+HBQYFBSUP5bFiNIe0CmDbS9QLQNIVBvvbRsQL1BQmlCaUFC aWlhYA1RIQ1DcVdWVldnZmZnc8JRcWB55cBMGB9D1FFFtZb1U9VAAwZQUFFQH1HWUuZSy1BTUGQQ c1AZH1NRU1L4UFFRQFEQUVJROlP4UFBAUO9Qv1BUUKZUFnxIe0CmDbStDSG0UH8NvWFgQ3FTcdlS fWqtg1LLrrtQUVAKUFBR4FFFUFNQdRBHUBlTWlL4URlT+HBQYFDvUFNQ/lQWI0h7QKYNtK20UG+t YWBDcVNxxFFMaq60UUWuu1BQUa/3r7dTFVWDUFNQGhBFQFFAUhRRFFJUUlFQU1BaUqggUVFR6FGL EFxTqBBQEEZIZJ9QUVDoUcriVHCV6VEOUEh7SklArQ17Ski9pA29UG9sb2xhYFENV1FjUQlShpit e0lVvKpEUFBSUNSvt1TCVZBQXlBwUBoQQVpUWFZUW1ZduEaoRlZ5UlFL6FFM4lVVQuhRTBBEXF1I OVBYQFhSWEpyXzlQSXHsx0h7HkCkHb0eQKYNHb1Qb71vvWFgUA1RDUNkZ0JQY2JCRURSUHNyUnVE RmNiZ2ZDZmVkdnNyV1ZTVtQbDFFw4OK196604uK3UUocbABuAxBjHWwcawdvZlGNjbNRRVFerq6m sa5brqVRUuomMBozUXO31z4xGTqupbdQUFFQo1BQVEZVk1BZUMUQSxtQHVkPUA9RD1lVfFNpU2ZV ZlYGU6lZVlRVVehRD+dWV0RWVldXUOpSPlBRU0cQW1NTVFVVVlxXVkBTEVtR8lBUUTZQV1LdUFVR 4FBWUiVQUVIhEEFAUFFQUG9QH1AwUFRQSVpWR+hTROGjSHt7HkCkDSEdtKa9pK29e0BsUG9sb2xA pK1p11V+ey1AlGFgUQ1QDUNDdGdjUXFDVlajZlEjm/+um66PhQq7UxpRUPKHqm1TqGowUFFQLFBQ VMFVkFBPUWUQDFBZUFpQW1BcUF1QQ1YpRFHKQ1FCf19/QH1HakcfXx9AH0QfRR9GB0PEQ/ND40Pq SOVPkFqQW5BDg0OJSLBDtUa1R6RDpUalR0pfQV9CX0NfRFRgXhBekF6AXlRe6FE6EEFBUU1QX2Be EF7gXpBegF5VXuhRDuZAQVwPUFFQ6lIiUE1RTOJUVUDqUiFQX1LfEF1KOd9Xr1dSUFdAV1JX6FJ6 5nFQOXBRUVHoUj/jQEFRQepRHlBwU0Thx0h7QKYNpA29QKUNIb2ktFBvrbQNb2ytDWxBQmlRQL0N YWBRIQ0TDAjpUF2vsOJCaULor6jiQWlZ6K+Q4kFpWuivkOJBaVvor5DiQWlc6K+Q4kFpXeivkOJB aV7or5DiQWlD6K+o4VxpUHtRe3t7e3t7e3sJUA1RIQ1RdWZmY2JGRURWV1ZUVldxU3FuUmdmZ2Zm ZWR2c3JWUk2ut3Kp6526GAJrrqQHeFGsZqzVXjPElcR3FmQHExQ2U6F6nImO+wf/MBSpC2OuqjyT +Oveex4ifhoMN1BQUVA4r7dUK1WQUHxQohB6cEgUVjNL1HJUf0irWFJwWAZKOUwme8pSVVxaXV9J RUhQVFFzdkJdV1xf6FFMEExAWlFaf1ofWrBaoFpUWkhQUVEwUSBR0FGgUVRR6lN5UFRRTBBfel1f SFE/SC9I30ivSFRI6lN5UEVRTOJNVVfoUtnnYHYfdlJ20ULoUtkQXFBwQHBScEp+EFxRXOhRxxBf wEjwSFJIOVBJwEngSVNJ6FHxEFvAUVFROVBJfaSjSHseQKQdvQ2kDa0Ntg0eQKYNHb2kDb1Qb620 DSFvrbQNIUFpDX8hvVFBQmlBQmlQQUJpQUJpQWNBY2FgUQ1QDVENQ3VGRmNiZmVkdnNyV2dGY2Jm ZWR2c3JWV3VmZ2ZjYkZFRFZXRkZFRFdWc3J2OFFDQQkaMtE4CEZIYl9eIygBEm4yTa6qYgnXlZqC 1iUNCCPNqOqhUS9xJQrUNwo5VL9SJTQXAgs+ZPIH0rHNIuh7YcwF8tjqhVBSUGhQUFQrVepQWlBd USIQLVpcSVxSV1JZU1hVU1ZTV1hbWFxSXUhTSFVGVkdXSFxCXV5CbFIcUglSOFL6UutSVnhTA1M1 Uj9TMF0rU9lTy1P2UvZY+VzoU+dUlFKZU4pTh1SHWEJZVVlcGVUZWxhcVVJSXVFbXFpdVlhUWVFX VVRZXVZQXFpRV1JTUlFT6FEHEFlcXURcXF1UWVnoUQ8QXFpcRFpaXFNaV1lWUuhTSBBDVhBdgF1S XYNXT1FRUVFTWVpcXOhROuVUU1RcQFntUeBQWlBUUU9QXFH6EEZ/Wm9az1pTL1rvWr9aU1BaD1rf WlNa6FKdEFpdVkpfUFEwUVJR6FLX5QBd4F1SXehSPeJeWkfoUcnho0h7e0CkDb0NHkC2HUCmDQ0h rb1AvXtsUG9stW9sQml/DWytDWy2UUFCaUFp1357LUCU135Ie1gtQJRfX19fUEFCaVFpYWBRIQ1Q DRMMCOlQXa+wEFpAaVNAQWlSQEFpUXt7ewlRDVANUXFnUWNTY1dzU3FDQ1FSKa3vYlNJqJHiY+Jv rqIiD64tUXugU8+sNaSuhVJPUZmuZ1BQUVDSr7dUz1X2UHFRUhATQxBbaUQQW2l/X39AbF9rQB1f HUAOXwpAP160WKZFpkZccFFwVHhAeERwcG1Ab0FvRMdAyEHKRLhBs0K1SqVFX0RFRehR/xBGQEFE QEBBQF9FXEhQAFEwUSBRsFFUUepR/lBWUUzlT10/X1Ff6FLf47BcUVzoUQoQQEhDcERvRB9E70Sf RI9EVkToUQ7jQkFUWehS2eJL5kLoUiHlUENAQ1JDEVxRx1BzUERSiVBFUnRQX1H6UEFS3VBAUokQ W1E5X1BRUEly7MdIex5ApCEdvaS0va20QKYNtKS9UG9srQ1sf60NtA1vraYNaUFCaUFp115+e1Ut QJRhYFENUA17e0N1VkVERmNiZmVkdnNyVld3Q3FTcVdmZmNiRkVEUlRzcnbSUUdRCxk29w4eaDlh vI9SsWauSRN6BHn4iMeupMProVH0SURaNjaT/DY4ZGVCUr2uqrJDQ7LuyK6JzqJQUlD2r7ZUy1WQ UEpQeFC9EDhYcFV3UmVYZXcSWBJ3Nlg4dyZY1ljGWMtG9limWKpKqXNeVlhRVldaR0RXRFh6SWdw FlcIRjZYOUI6dyZY1FjFWPVYhnezVrhGtndDUFRRWHJLAHVRdTVAWh9aUlpPUVEPUc9Rj1FTUepR 8VBUUUziSFVO6FFMEF9BXX9RUVE5L1DfULBQU1DoUiEQQ3I5X11RUF1AXSBd0F2/Xa9dVl3oURwQ QHpLORBF0EVSUEVARcBFU0XsUp1QeVHwUoBQSHtApg0hvUCmDSG9pA29DVBvvW+ttA0ifw29DVFB QmlQQUJpYWBRDVAhDVEhUVV2dnNyV1ZXZmNiRkVEUlZzcnZ2ZUBQcWJGUURGY2JnZmVkdnNyVlZU y66jWBNpGWkBYQ04+ozKttArlTtRDFFN9JKtZQwUBGwBChFnIG9UBEYHFmoD6W24mM+utdIrvJZR 2VJ05KzzJD4eOeEiPQPlUFBRUIRQUFSCVfZQX1DkEBZfEFtpUBBbaahUUVlfR1QQUBBRF1cWXBZe ClUIVgdfNlQ2VyZVKV0pXilf1VXbXtlfyVTJX/lfmF2YX4dXh1xKW19RX1lT6FHyEEBSX3BQb1Af UO9Qn1CPUFZQ6FEO5lJRVFlaXFPoUiHjUkpBWexR4FBaUiFQUVIhEFxvUB9QD1DwUFRQSUDqUfZR y1BIex5ApA0dtKS9HkCmHbRQb2xvbK0NbECtUUFpYWBRIQ1QDXt7Q0NxV1ZSUldWV3FmZ2ZCZ4Rn U5d7DI7tbANErr9CEwKm/lTNUVmcGq6HrsH1tD8+kLxR6JtQUFNQ16+2VNlVkFBJUHVQYVCVEG9q XWxeBkL3XIZ7VXtdcEJwQ21VY0JmQxhCBV4JQiZe1l7YdMhYyFzpdLhyqHJBXVBRXVBNf11acFBK U7B/UX/oUQoQWmBNUU1Nc795UXnoUQrlRF2wc1Fz6FEKEE5XVXw5P0BRQNFwOVBaQFpST1pRWkpj SjlwU2BTUlPqUj9QdlLZEFtQR0BHUkdJYuyjSHseQKQNHb2kDb0eQKYhDR29pA29UG+9DW+tDUFp fw29DVFBQmlBQmlQQUJpaWFgUSENUA1RdnZlZGZmY2JGRURWV0ZGRURXVnFydmVkZkNERmNiZmVk dnNyVlNERmNiZmVkdnNyVlHoHR08h9iUjCwsCgk6yq6lkrz0qgQTHSUGEx8h0AoYPykNGArbU3dj 1QEOkiCczD7zZmfNNfbYlLXhw7hRdhUFJR4XCCStVgIOlCMaD/ZQUlDSr7dUJ1WQUEhQdlCeEA1q WGp1H1g7WClY2FjJWMREolKpWKRIpXFcWVdTRUxXTFh4V3ZHaU4ERDlYN0EqWNlYylj5WIlXiUWJ dbZTuVe5WLZIuXVGLlcqWFJQVFFYcEkPc1FzNSBaUV9aUVroU0XlAFHAUVJR6lHxUFRRTOJGXUzo UUwQeUBVSTlQQ0BDUkNKeHA5EF0AXTBdwF1UXdFwUVFROVBQQFBSUEl37KNIex5ApA0dvQ2kDb0e QKYNHb1Qb71vraQNpg0hvQ1RQUJpUEFCaWFgUSENUA1DdUZGY2JnZmdWc3J2ZWRQY2JCQUBQcXJ2 UWR2c3JXVkVERmNiZmbSUV1YE2kZaAJgDTf6jFFKuZ6KrvOus/eYUoUMFARsAQoRZyBvUQJGBhZp A+lst5iwUQyuhK9QriWtju9TAiQ9HjnhIj0E5VBSUMBQUFLZVHZQU1BXUAMQRNBZUVAZU1QZV1pS +FEZUPjwU1FT6FEfEE9UVvhVGVT4X1dRUFdAV3BXYFeQV4BXr1dXV0lYODNIex5ApA0hHaSttECk DaSttFBvvX+9YWBRDVFxU3FTcVNxUT5RS2qutTpRTGqutFR2rrquVa67UFJQA66SUt9UdlBTUF5Q KxBz2VdRXFtdWlpZVlVeUBlTXV5a7VnXVBleWlL4URlQ+PBTUVPoUR8QWlUZVFFdUUBdUV3oUQEQ RF74VRlQVEBUcFRgVDBUIFS/VFdU6FEI4184N0h7QKYNvaS0DSFAvaQNpK20UG+9pL1AbH+9QUJp QmlBQmlpYWBRDVFxU3FTcVdWVldnZmZnc1EjUUxqrrQ5UXFgeeXATBgfQ9RUdq66rlW1lvVT1UAD BlBQUVAPUPdUHFVRUFZQPRBCiFGHUlJXVRZV1lVTUFRWU1hT6FErEEXQUFE/ULBQUlBTUFNQVlZU VABTUVPoUq8QSlIgVSDQUVFQUUBRwFHwUZBRsFFWUcJX+hpIex5ApA0hHa2trQ1sQGxAbEBsUG8N Ib1RQUdpYWAhUA11UWVRQVFRVBysQ1O9rRNS7fdR5aJR466zrqSuulBSUAVRJFQGVGJQU1BXUNDm V29UH1RSVOtSAFBWUFVTd+ZTb1AfUFJQ6FIAEEhSQFFwUVJwURBR71GAUaBRVVFXVlZTU1Lor5Dj WVpkUuhSreVZVFVVUVDor5DjQ0lkUOivkONZWmRQ6FKs41gWGkh7QKZ7e2xsQGxApntsQGxAbFB/ DSJsrQ1spmytDWxhYENBcUFRQXFBBVRRq69UUVNgUVKurq4UUVOurVBQUVAPUPZUHVSvUFZQJRBc h1VRWFJRVFNRU1dU6FErEEPQUFE/ULBQUlBTUFFRU1MPVFFU6FKvEENVIFIgX1bQVlJ/VgBWkFaw VlRW6FKvEEFQUEBQcFDAUPBQVVDCV/oaSHseQKQNHa0NIa2trQ1sQGxAbFBvDSG9UUJHaWFgUSFQ DWdBUVFBUUUPUu6tElO+9lFLUURRQVFJrh2gUFBSUKxQUFSiVYNQSVBNUJ0QZFJVVltVXF5AVFpG SUbfXFN6R3BPZkATRhlHBVUGRgdHKVMgW9hT8kZcXlp/XVFdic9aUVroUUwQXEFRUF9RUV9RT1FS UehTehBBShlNWkBXwFdScFfAV/BXU1foUgDnUERARHBEU0ToU0rkcE9RT1DoUgAQXX9RD1FSUX1L GUr4TV3oUgDlf14PXlJe6FEf50wZQE1wTVJN6FEy407vfEh7QKYNvaQNvUCkvaQNvUAhpA29DSJQ b62mDSFsb70ivQ1BaWFgUQ1QDVEhUXFmZmdmZmVkdnNyVld1ZnRjYkZFRFZXVlZVcVNxUuyurkQv 7/FpMjUg3k6uqWNRdIGKpDi5whSugVFMaq60UT7WlfXdCnpuAyrWfpOyiccI/5EqMPyuu1BQUlBt rgFXllWEUG1QHlFxEAwtSSVyUhJyFmoWbVNvRm9HYHJTVURWZVltWBlHREZlSW1IGSYYWQkYORgm dlNqFwl2Cm1TanZrYmgWU30VeRZ6GVN5S3l2dGlTUABRdnd4eHVzGHRISBFQc3QbVehRRuNrkVBj 6FFG4l1RG+hRRuZxV3RWUFp761FGUEVQEVFGEF9KSkVadbd4dLd4Gd9IUUjqUYhQYFFG4kH4UOhR RhBbUFFRQFEgUdBRU1HoU1AQX6AAUQBuB1BNUb9NUU0xZ+hRRhBZUFlAWVJZ1B8A6FJe43EfN0h7 ex6kDR29pA0hvR5ADaYNIR29pK2kDb20QLRQb2xAvUC9b29vvW+9QKS9QUJpQUJpUUFCaWnXXi1A lJRhYFEhDQ0NDQ0NUA0NDXVjVldWcXB0UkFAUHRxYlRCRURXUnFydndWc3J2ZWRnZmNiR2dxU1ZF REZjYmdmQmVkUHFwVFJFREJUY2J0UURGY2JnZmdmZmVkdnNyVlZWoYU0n72u+67mrnC6UVpRnlF5 rFHYn82VrpwDBF4myvaL1PCq4gVJUVjHXkdAYBw2Lq7MrpGuoa7X74VR0ai/UQisYDccaWJ2dWUd OQAGwhpDmyPUj1HjUVBRSVG1o5Sux4avnq6samgite67krzYP61jFERJSWocUVDZplEbja4/iYOu 9s/VUnAvKExEe226NSEp1aZQUq+5UFBVM1XqUFdQWlClEASPWVEQXFFwXCBcilOEVFQfXClU71yA XKBcVXZTelR4WQZTBlrIVMdaV1lZUFwZUBtWGlgQXFZQWFlXUVpZWVJVVlZyV1lEV1dZVFNTclJZ RFJSWVnoUgniVFha6FKYEF5QUVFTVVRSVldXUlNYVuhS0hBbcFcvV1IAV49XUlfrUUVQWVBTUgkQ Wk9Sf1IgUrBSVFLoUuYQX1BZEFkgWYBZVFBZQFlSWexRYlBbUuJS51BIe0lApA0hpg1IvUlApA0h SL1Qb2xsQGxvbEJpf2ytbEC911V+ey1AlNd+SHstQJRXQGxs15RsYWBRIQ0NIVEiUCFRcVNxUXFD cVNTUVRErevgrppTbVEfvq6yBgWuzlEUruxV6qoWUmhSHq3iUFNQAlBQVf5V6lBCUE5QeFCtEG5w elEGQFH4UfdP8HqQelQ0XMdW91CAelQHQwdPMFugelR7W3dcYHpTQ3hPTltEd1tYSE5PT09QUURQ UFFEQ+hSmBBHd594UXhweI94Un94H3jgeJB4VHhPTU7oUpjkUlFScE/oUpgQfUJQWFFQQEh4cFhR f1g/WFJYm3R4EHpRUF5AXnBeYF4wXs9e715XXg4gelF6TupSwlBPUnQQQZBQgFBSYFAQUABQU1Bs eVBH6lL6UgdQSHt7QKYNIa20QA2mDSK9pA0hvXtAbFBvbK1sb2ytbEFpDSF/IWytbNdVfnstQJRR QUJpUEFCaVdVbGxhYFENDQ0NUA1RIWNRcWJHTlJFRFZXRkZFRFZUc1NjYmZmZWR2d3Zzc1NxYmZm ZWR2c3ECUWNRpfMRPMYe2N4hL8auqLWftsvYFBBrcS66nlFz5y0bPC6uyFXqWl8Kxgsq435PzzTU vThTOnw0aWgYXFasd388bBkPUFBRUJKvtlWnVYNQS1DiEH4fUB9REF4QX1RXR0dHe1l7WntEGFUf XxdEGkgJUgpTClzGWV1RUEleH18PX1Jf6lH9UEJSmxBaW1N/UG9QEFBTUOpR/VBJUpsQalRZUHg/ Ue9RUh9RD1HPUVNR0V94UF5AXlJemxBNUbBNUXBNEE0ATTBNVE1GeBBXAFcwV1NQV0BXUlfoUsrj TGliSHtApg0hvUAhDSKkDb2kDQ29UG+ttA1vraQNaUFCaWFgUQ1QDVFVVlBzcFBBZEJ0Y2JUR1V2 dnNyVlJFREZjYmZUKlFgCa7Mv66jroGbUTiEvlF2Sq6PSNkiLYnS+S4lk1JAfqeuq1EUUWSqUc+M r4xM0CPIru3x4JDIUFJQCVBQVZxV6lBBUE9QyxBy1UhRZ1BlQhtHB0IHT+pF6UeaRZpGWU9CQk9Q UURQUFFDQuhSmORBUFhOT+hSmBBKUlFSUVBASXhQWkBaUlpKEHFRcHFR73FRcU/sUsJQQlJ0UFFS FBBBkFCAUFJgUBBQAFBTUGxwUEfoUvrhYkh7e0CmDSG0rbQeQA0hIqYNHb17QGxQb2ytbG9srWzX VX57LUCUYWBRDVANY1FxYkdOVEVEUldWV1Zzd2NiZmdmQmVkdnd2c3MJUWNR2/V+C98lBX7l2Tn2 DpP2yfbFbgkqNRpk1f9V6lVZaDXe6T69rsE8BHhGvHloAVFe58zNSkJQUFFQBFBQVZVV6lBbULgQ ewdZz1PPV89bVGZZEFIQUwdUVFhRcFpwW2dQVFVYWVRUWVlPUFFEUFBRVlXoUpgQX1dYf1gfWOBY kFhUWFlTVOhSmORSUVJaWehSmOZbUFhRUEBX6lISUFavkOJmZVbqUhJQW1IS5RBaMFpSWupSwlBT UhIQQwBSUVBSQFJ/UgBSVM9SUVJKXVTsUsJQWVJ0UFFSFBBBkFCAUFJgUBBQAFBTUGxcUEfoUvrh PEh7e0CmDSG0rbQeQKYNDSIdtKQNtKR7tHtAbFBvbK1sb2ytbEFpDX9srWzXVX57LUCUV2xsYWBR DQ0NY1FxV3FTcVdxU3FXBFFiVG9jrL8WUqdjrVkMUwVkVeqlruOlriKlUFBRUABQUFXVVepQWVDl EElYUQdUB1iHWVRYVVRZVFlZT1BRRFBQUVZV6FKY5VdYWFlTVOhSmBBaUlFSWVBYUVBAV+hSEuaA VlHgVlFW6lITUFNSEhBEwFJRUFJAUpBSU1JKcFtRAFtRW1TsUQ1QWVIJUFFSFBBBkFCAUFJgUBBQ AFBTUGxaUEfqUvpRRFBIe3tApg0htK20HkANIaYNIh20pA0htHtAbFBvbG9srWxBaX9srWzXVX57 LUCUV2xsYWBRDWNRcVdxU3FXcVMAUWNUUmStfBpSlmOtatJV6qWu8KWtwFBRUOWvt1YZVYNQcVEE 6VBwr5DiQ2lx6K+QECFDaUlTeFtpUxlTCFvXTsdO9E7wT1nvUuNOUldSUVZSVlNAUUBSQFNHSkBO QE9AcHxSd11+TnlPalZoX2hAaU8AUQxfDEDPUc9Ozk/PcPRQ91L7VIZShk+qUU5BRUJwT09yUlFE UlJRT3BSVUxw/3FRcehSmBBbUXBQUVAAUFFQQkzoUpsQWVVZD0JRD0JRQupR/VBFUpsQWV5TUnJ4 UVJAcehSEhBFUB9QUQBQz1CPUK9QVFBJT5vfcFFw6FJ05QBQ31FSUehSEhBNQngQQVFQQVFAQVFB 9XNJeBBZAFkwWVNQWUBZUlnoUsrmclJHUnJaaelS/lBIe3tAbHtApg0hvUClDQ0hvaQNrQ2kQWkN IX+0e0Bse0CQUG+ttA0hb61BaQ1/DWytDWxBQmlCaddefntVLUCUUEFCaWFgUQ1RIVAhDVB7e1Fx U1ZUc3B3dkFkZ2ZQY2JUR1V2dnNyVlJFREZjYmZnZ3FT1FLA1CSu//+uoMGWBTZRKK6uUWNirrd1 9S3CpNr48jGcGn2u2lNfrdsbOCv4UW+GlLxRVLyycCwuyK6S7OnhZ3aKUFBRUAlQUFZOVepQW1CP EH4GWgBdUlhUB1IHVgdXVFBXWFhbUVZVVVJZWlpPW1hEW1tYVVJST1NURFNTVFBR6FKYEElXVmBW UVZUWltbUlNYWVhYVVRSWFtUU0BY7lIUUFtQVFIUUFNQWlIJEEQPW59bj1tTj1tRUFvPW49br1tU W+hRPOQQXVFdUuhSCRBDkFOAU1JgUxBTAFNTU2xcW0dTR+hS+uEqSHt7e0CmDSG9QCKkDSEivUC0 QLR7QGxAbFBvbGxAbG9sbEBsQmkNf2ytbNdVfnstQJTXfkh7LUCUV0BsbFdAbGxhYFENDVFxU3FR cVNxQ3FRcVQXrZnZroJRY1F9JlJnJ1F9rp6uglLfrSFV6q2aUmaqFlBRUBdQUFL3VepQU1CA6VBV r5DjExdkVeivkONvEGRV6K+Q42xtZFXor5DjY2RkVeivkON/YGRV6K+QEBF3fWTAVVFYUVhSEFUH UgBVMFUvVfBVl1K3UrBVoFVcQFUPVc9V4FWAVVUQVVFSU1NPUFFEUFBRUlFSU1BYUVBAUu1SFFBT UglQcFBRUhQQcCBQwFDwUOBQVGBQEFAwUFNAUFGwUFEwUPBQUlCxVFBH6FL64TxIe3tApg0NISIi SbRKrbR7QGxQSG9sb2zXVX57LUCUYWBRIiENInt7e3t7e2NRcVEXUWNRfa6eVeqqFlBQUVBrr7dU nFXqUERQ4hAckEavVlI4RChQJ0SYQlRoU2hCYEY4UlRBVEJCQkNARFRAUEBRQFJCU1RQQVBCUENQ RFRQUFBRUFJQU1RaQFtaXVhEUFBPUVJEUVFSW+pR91BAUpsQXFVZUVBSUUV4UlFAUuhS0uMgRFFE 6FIWEEBdeNBYUVgORVFHUUVa99NIe3tAbHtApg2tpg29e0Bse0CQUG9sb62211V+e14tQJRRQUJp UEFCaWFgUQ0NDQ0NDQ1RcVNSVnNydmVkZ3VWRURGY2JnZmdT9FF46RqgqYOCVVFHVgADJH9zYlXq rNiuz6qS93N7TnxNFhoUZKFQUVABUFBWOVXqUFtRJhAjXVpNU09aU09TT1pSQFZPWEBZSVpUWFFQ VUlTSVRUQntXe1gIUQZVBlY5VDlVJlbWVtlY11nYWs9UxlbJV8lY6VWWV4pYhlmAXbpYsF2pWEhb VFVXUF0ZVNBdgFVWwFVRNVbcU9xa91blVlVUUxZTFlRTWOxSdFBXUnxQVFLDEAhAVVFVShBdUXBd UQBdUV1aWllTUlNUUltWVldZWllYWlVSW1tPUFFEUFBRWFdWVk9ZWERZVlVZWFNWUVpQWVZZWFpT W1JZWVFXWFhbUFhVVFRSUVJRUEBS7FIUUFtSCVBRUhQQQZBQgFBSYFAQUABQU1BsXFBH6lL6UURQ SHt7QKYNIbSttHtAbFBvbGxAbG9sbEBsQml/UUFCaWlCaWlQQUJpQmlp11h+e9dVLZTXfkh7LUCU V1hAbFhsV1hAbFhsUUgeQA0hIqYNHb2kvWFgUCENUSIhDRMMCBBcWXBdaVRwX2lUcEBpUXt7UHsJ UQ0NUA0NY1FxU1FxUVFxUVVTAVFiUX7SUvZRxK0+UbOu+67GrrMOVeqtwVI/rZGs1VLqqa5vUFFQ DFBQVPdV6lBVUM4QfnBXUXVQdVNwVHBVZlBmU21UEFUGUwNUAFU/VCBUIFX3U19SU1NPUFFEUFBR VFPoUpgQWlVQWFJRUlFQQFXoUhIQRFBUQFQwVM9Un1SPVFZUSgBXUVdS7FENUFNSdFBRUhQQXGBQ EFAAUFNQbFZQR+pS+lIHUEh7e0CmDbSttB5ADaYNHbR7QGxQb2xvbK1s11V+ey1AlGFgUQ1RIWNR cVNxVwxRY1F9r1K6Y1Xqq2ulUFFQA1BQV1dV6lBcUasQsl5WWVdZWBVQFVMWWj5YJlbVUNpR1Fag WVxgXhBegF5TX1dZXHdSfFwaVxZcL1fAV+9cWUlZSlxPXnZQell8XHBeV1NbU1y2ULpYuFygXlZW UFtRX1JYVVlXVlhTWleVUJ9Yl1qWW5hcVcday1zkUOtY5VnnXFbYWtxczVbPV89YyVlWK1ksXN9W 3VffWNlZVjhcMF4pUC9WL1crWFYZWBdcCFkIXD9WPFdWaVloXB9WHFdUXFI2WFdXcVBcRFBQXFla WnJbXERbW1xVVFRyU1JEU1NSUlFTXFtSU0BfV09XUlftUtRQUFBcUtJQWVIU5F5HR0pa6FLREHgP W49bUi9br1tSX1tRv1uvW1LPW1HfW1EvW1FfWz9bUl9bT1sfW1Nb6lHiUFBR4hBGb1EPUY9RU19R L1FSW1FPUd9Rr1FUUe1R4lBTUFVSFFBTUtEQf99U71SvVFNgVBBUAFQ/VC9Uz1RWVEldW0dTR11d VFxcXVJYUlVSW1hRWFRYaCpIe1Bvb29vb0FCaX9CaX97ex5ApA0hHb20QKYNISKupg0NDQ0NDSEh Iq0eFTUUth2kvUC9DXtAbEBsUUFCadd+ey1AlNd+SHstQJTXVH5Ie1UtQJRhYFEmf0l/URvgWwEI 415ZXVRAbEBsCVENDQ0NDQ0NDQ0NUA1RIiFxcVNTcVFxQ1FxUXFRU8+usmW5rqBRYlH+fVGkUeOu na69UXFUmatnVeqrrVRTqhZUkFBQUVAMUFBWSlXqUFlRlxD1UVdKUlJZUFJSXFdZWUpRRVJHVUpX WEJ8UjRSOlfGUspXvlegV1ePUlF1UHlReFJoUhdTGVYAWzhRN1MmUipX1lLYV8dQyVHGUshVylf4 UPZU/Ff4WPhZ7FDpV+lY6lmXUJhRl1OXVJpVllaKUbtWp1CmUqxXdtBbUVlQUHJRWERRUVhWU1Ny VFVEVFRVV81QUs1VWVhYVlVSVFNTUVBYWFFVVEBQ6FHiEHpREABlURAYGWRREGxl31GfUY9RU19R f1EPUVOfUY9RUlBRz1GPUa9RVFHoUT3kEFtRW1PoUtEQQ5BUgFRSYFQQVABUU1RsWlFHVEfoUvrh 00h7e3tApg0hvUAipA0hIiJ7e3ume0BsQGxQb2xsQGxvbGxAbEC9QL3XVX57LUCU135Iey1AlGFg UBvgSQMb4EkBCgjpUFevnuFSYmhoCVAb4HUDG+B3AQoI6VBXr57hUmJoaAlQG+B+AxvgfgEKCOlQ V6/q4VIWaGgJUBvgYgMb4GIBCgjpUFev6uFSFmhoCVEhDVAiDRMMCOlQV6+gEEdbaVJIRGlRQERp VUhEaVVwQGlSZkBpV+ivmuFAaVF7e3t7e3tQewlRDVANcXFRU3FRcVFDcVS4rreuJJ6ut1FiUUpR 3Z1RSFOJrHdV6qx7U4VQUFJQ46+2VhZVg1BAUE1QJBBJRkNIRklKR014VHZcOEaZVJZbWVlUVVtS ROhSm+JdWUvoUpsQfFZTSHhQWUBZsFlTWUoQTzBP8E9TT0F4UFBAUFLwUFEQUABQMFBTsFCgUFJQ 6FLK405pYkh7QKYiISENvR5AIaYNHb1Qb71vvWFgUSENQ2RnZkJ0Y3BQQURSVHNydFJ1REZjYmZC ZWR2c3JQ43djgVFum1FAUR+Krtq8na66JFF66MYqscPqwI2uu1Jv0sCRUUz1rv6uubiuHrrqUUPC x5zxURfL/ZWuNFBQUlADUFBVzlXqUF9QSlDhEH1ZUkZVeEMHXwlDB0o/TIlDj0y5Q1plSoBMUmlK UUBfUEpKUFBPUVJEUVFSQUDoUpjlXl9fUUlK6FKYEE9TUlJQUVhSUUBFeFBXQFcAV7BXVFfRf0wQ TDBMU0xK7FENUFBSCVBSUhQQQZBRgFFSYFEQUQBRU1FsS1FH6FL64TRIe3tApg0htK20HkANpg0d vXtAbFBvbG9srWxBaX9srWzXVX57LUCUV2xsYWANUQ0NcXFRcWJGRkVEXlJXVnNzZ2NiZmZlZHZ2 c3NR0a6CUWNSBM/pPAYtwCoXk5FiDb/wDH8Fw4hV6hv9KD+CLhFBWqNs1B9lFE9QUlDjr21WFVWD UERQflCeEBpKRmlUZls5QDlGKUCZWJZyq0GpQlpaWFFERkZxdl90QXVEeHpqURpRC1E5UClQ/VHs UZ1RjFBffHhFUEBCVkN9fXhFUEBDVkJ8fe1SFFBzUENTfFBzUpviU1JL6FKb5lpTfHxIcELoUhMQ ekh4UF1AXbBdU11KEGAwYPBgU2BweLBWoFZSUFZAVlLwVlEQVgBWMFZTVuhSyuN/aWJIex5ApCEh DSIdvR5AIaYNHb20QUJpf1BvvW+9tEC0UUFCR2lQQUJHaWFgUA1RIQ11VlZzcFBBZEJ0Y3BQQURS V0ZHV3ZTZkJlZHZzcl5SRURGY2JnZmZlZHd2d2dGVGYWxgCupK7lnlEnv1FAUR7jxjA63twNCz/q wDP43Qntw3l9QFdObxc+101LTFEfUV6NUZS/rv+uuIauKCoObOsUUbIMUXTR/pUL/K4v+5VWU1ZW WExsSvgUUFJQClBQVb5V6lBGUHFRbRArWFJWVVRZRlVPX09ATUFXQlpAXEFcQ3pK41lVel12Smtb bV1oQWlKH1oZXRlAB1AHUQdSB1wHcdNZ3EHfQspdyUD3Xela6VvpXelAmVubXZlAi12KQIlBtVq/ Q7lKqUCrSnNGR3FQcVBQT1FSRFFRUkhwR2BHEEfAR1RH6K+Q4kNpR+hSmuVFRkZRcHHoUpgQXVNS Ul5fX1BRWFJRQF/oUgkQT+BeUV7ITHhwV5BXgFdTUFdAV+9XU1ebEHNRcHNRc3HsUQ1QUFIJUFJS FBBBkFGAUVJgURBRAFFTUWxyUUfoUvrhNEh7e0CmDSG0rbRAISKkDSG9pA29e0BsUG9sbEBsb2yt bEFpf2ytew1s11V+ey1AlFdsbGFgUQ1RIRMMCBBAShBCaUkQQmlIEEJpRxBCaVB7e3t7CVENcXFR cWJGRkVEVldGR0ZDcXZTdnd2c3NnY2JmZmVkd3ZzcVHYroJRY1Lb+OsjsLNqYzUsrux3Im4Wezsr fvCjzwoReNWu5FXqFejT66NNZAX8rpYsUVfeYU2MaiwUAHhIUFBRUC6vt1U5VYNQelFBEDsSVxpA GUEdSzldOEA9Qz9NM3nAUc9Yz0bPR8BMwU76S+lLmlyQQZhLknhFUHxRFlwZcRtzUxZZEFseTh9P H3DQfFZWT0laR05FT2ZyHVsfXRZOEE8TcRBy9E6YQ5V1ik6KcEBQVVFFP0ZRRuhRCRBf/0nvSZ9J U09Jf0lvSVNJ6K+Q4kNpSehSm+VCU59RUVHoUQkQQ1UQQ2nwVeBVkFVTQFVwVWBVU1XoUpsQTHdZ WHhQdEB0UnSlRnhARVFFSnxMeD9fUc9fUV/oUnwQX1F4UFBAUHBQU1BJe55iSHseQKQNHb2kDSG9 HkCmDR29pA29UG+tIQ17tA1vrXshDaQNaUFCaWFgUA1RIVAhUSINQ3VGR0ZjYmZlZHd2dHZ2ZWR0 Y3BUR1V2dnNyVkVER0ZHRkdGRURQcXJ0dtJRT1Z5EuLE1GZ2rvvNClFcrlFSUUtero9b0i8tO2Fh +K0VN66drr7trrsiUYtf2WAeOhsRfXHEM8466aSimV05IAgTb3l6GT0UNM2Srr0vslBQUVCmUFBV /FXqUFdRShAOIFlRX1NfVF5VXlaJV7hSVolSgFSAVVPjV5lSmFdT81LzV+RSU89Uz1X3UFPZUttX yFJTJ1DUUNVRUxBWN1A3UVMXURhSH1RTb1NvVBdQU1dQUE9RUkRRUVJQUVhWU+hSmBBZVVRSUlFA VelU6K+Q4hRlU+ivkOIUZVXor5DiFGVW6K+QEEgUZVBWQFZScFYgVvBWU1BWkFawVqBWVFboUjfk cFlRWVDoUgkQclFU6UBTUWBT8FNSUFMgU7BTU1MQU1FT8FFRV1EQUbBRU1HoUhbkWFlRR9bpUUhQ SHt7e0C2DSFRaSF/DSEitEC9QCGkDSENe3t7e7R7QGxQb2ytbG9s11V+ey1AlGFgUQ0NDQ0NDQ0N DQ1RIXFxUXFncVdxUoKuglFQrgJjVNNjrghUlaWlUFFQ66+3Vk9V6lBKUKkQC3lSelx5X3lKalBq UWhdaF4aUBpRGl0aXghcCUoATD9QP1E7UjZAO0opUilK2FDYUchcyUXISudfTFJTVFVVUUpJSEdG RlBeX19PXF1EXFxdUVVVT0ZQREZGUFjoUpsQQkNZXl1dUVBSRlxLeF1cUEZAX+hSCRBGQFwQXI9c U0Bcn1yPXFPwXOBcr1xTXOhS5hBPVXiQRoBGUmBGEEYARjBGVEZsS1lcR0ZHXEZLWmmPSHt7QGxs e3t7QKYNIVGtpg0hIr17QGxAbHtAkJBQb2xsQGxvvddefntVLUCU115+SHtVLUCU115AlJSUlNde QJSUlGFgUQ1RcVNXVkVERmNiZmZnQ3FTVlJUc3B0ZWRnZmdR11F99nlULyk93h54+FF992XarriG r1CuoFdUT1XqrLSUSUYHIQLyklNxrI6trqT4q5V5YHDGUFBRULhQUFYJVepQVlDoEGNvWAlQClEK VA9YN1DFUMlRyVXvWFpAWHBYH1iOUVRQVlZyVVREVVVUUVJST1NURFNTVFToUnQQW1FWVVVTUlJQ UVhW6FLSEF9AVQ9V8FVTcFXAVZBVU1XrUpNQVFBSUgnlf1MPU1JT6FLCEEFAVHBUAFTwVFRQVEBU sFRTVOxRilBXUNZTTVBIe0lApA0hpA1IvUlApA0hSL1Qb2xvbGxAbEC911V+ey1AlNd+SHstQJRh YFEhDXFxUXFDUXFTYa7urqlRfepSD1F7Veqr+1QFUFFQoFBQWNtV6lBcUcIQ0lxSTFJSU1hZW1lc U0KGV4paUiNXgldSf1V/XmVQZVNvXhVTGlgfXgZTD1UPVg9XDlgPXjhQPVU9Vj1XJVPSUNRT21jN VeVQllC1U7BUpFBMUFBWU1pXW1hQXIJQgFhXV1pSU1VUWFdXcVNSRFNTUlBRUVNTVFhcW1tZWVhY VlZVUlzoUtLlUFsgW1Jb6FLk41rbWVDoUgrjUdtSVOhSChBeU1VPVgpPV99XUk9XUVfoUT0QXFhP U99TUlBTD1NSU+hRPeJYs1noUrbkQFJRUtbpU01QSHt/Db29tA0hQKQNIaS9QL5ApL5ApKQivVBv bEBsQGxAbEBsb2xAbEBs1357VS1AlFBBQkdpYWBRIQ1QIVANEwwI6VBXr7DiW2la6K+A4ltpUuiv uOJdaVfor7jiXWlX6K+g5lxpW0hCaVDor6DiQmlc6K+w4kJpVeivoOZCaVhAQmlT6K+w4kFpUOiv sOJBaVDor7AQXkBpWHBAaVhIX2lYSEZpUXt7e3t7e3t7e3t7UHt7e3t7CVENUA1xcVNRcVNxQ1Fx Q1FxVZaun3Gtuq6ZZ1F3XVGnURdyUbNRdFRgq4BV6quuVFKsWVOnUFBRr5JQUFYVVepQRVFtENpH UEdFUkJQRzhSOF6QR1Q5UlHbWVFwRmhSZFNkVGZVaUE5VDZAJFArWytcJEXaVNpV3V/5Uvtf+kHo UuBHmFCUWpRblVyaRJpFSnpSeV95QQ9HVENQXVNAXlBdVF9ZVF9cUVJRXFNAVFNAQE9fVERfX1Rc XVBQT1FcRFFRXF1cXFRTUl9AQFBRWEDoUnTjz19RX+pSFFBcUsYQR1BdMF2QXVNQXRBdIF2/XVRd Ss9HUUdU7FIJUFNR4VBQUsYQRZ9Rj1FSUFFvUTBR31HPUf9RVlFJRupRFVNNUEh7HkCkDSEdvaS9 HkANpg0hHb2kDb1Qb2xsQGxvbGxAbNdVfnvXLZTXfkh71y2UX19fX2FgUQ0NUA1QIVEhEwwI6VBb r4jiQGlc6K+IEFpAaUV4QGlQeEBpUXt7e3sJUQ1xcVFRcUNGR0ZHZmdDcVFRcXd2d1ZXURiuKlLX rsRRa99XC1ZXKgO3USutMVE5rvw+Bkx38lK2UoSuvV/sWkHFD1FVrKytGo3/HGvpUFBRULtQUFYX VepQXVEEEN1TVVFCGFI8Ui5S2lnYWulS5ljqXYpavFJacFBwUXBScV1oUmdVaV0aWBddB105WDpb MF8lVyNYJVkpWyBfzVjMW/ZS9l2YUpZahlOAX0pWUlZZVlpUXUVdFlNWV5BSXVBQT1FSRFFRUldb V1RbT1xdRFxcXVdUV1tUT1NSRFNTUlxbW1RTUlBRWFJRQFvoUnQQQwBcgFywXFNQXGBcEFwwXCBc VVzoUQ3kX1e6UlToUgnjb1NRU+pR4VBQUgkQTzBRUUBRcFEAUVPAUYBRsFFTUFFAUWBRAFEwUSBR VlHoUrDiXlFH6lKPUoJQSHt7QKYNDSEhvaQNvUC9QKQNDb17QGxQb2xvbGxAbNdVfntYLUCU11V+ SHtYLUCU11V+SHteLUCUUEh/vWFgUSENUA0TDAgQRFxAX2ldSF5pXUhfaV1wXWlScFtpUHt7e3tR ewlRDXFxQ1FxQ0ZHZmdnQ3FRU2WugyeuPFER5hFGdWHbn1EOrTBSa1MvrjLFEhEZklF5rDVQUFFQ Y1BQVQhV6lBdUJ7pUFGvqBAZW2lXVmsPUgBXUnhRy1FSCFdRXlJQV09SQFd/U39UEF4PUw9UB1YH VylRJVbXV/VSllKnUkFfUlBXDlEOUlRRV1ZQU1JRVlJTUutSmFBUUFZSmONVUlxb6FKY5F3AUVFR 6FKY4lBYXe1SElBcUhNQVVBSUsYQWVabQFVRVUpfVO1SElBTUQlQUFBXUsbnUZtQSV73PEh7HkCk HaS9QKS0HkCmDR2kvUCktFBvvQ1srWxvvWytbFFHaEdoYWBRIQ1QIg1RIntQe2NnUXFncVdRZmNi Z3FXY2BTHK0FY1RxfKz72EUw+VEKY7dTjqW2rExTUqVQUFFQRK48U9NV6lBXUO4Qf3ZXZlcWUhZW FlcGUgZXNlYmViZX11bWV89Qz1HPVcdX/1HwVPdW5lZEVFNRUlBX6FIv41J4VVboUi8QXHhTQFJC VPhVUfhQUOhR+eNXWVVV6FH5EE5WWVZXV09SU0RSUlNXVyBSWVZWqllTU1lSUklYWQ3pUUpQSHt7 Kh5AoFFIf3tsUX97Kh2xUUh/eypAsVFIf9d+ey1AlHsqQLBRSH97KkCgUUh/tEC0UG9ve61QbHtA rVBsQGxAbFENVVdxUXFXc1FSen2uR1HXUbh+i66F7oZXHo+qN1BRUPCvt1IcVYNQU1BgEFlSUVBT UFpRqFLoU0rnU6hQUEBQUlDsUXBQVFA4UcRQSHtApg29pr1Qb2xvbGFgVVNjQ1HTs5mzSVW8qkRQ Ua/erjxTUFXqUFdQkxB78FH4Uv9U+Fb4V4hXVjhWKFbZV8BRx1PPVFZ6UnxXaFMZUhhWVVRTUVJQ V+hSL+NSeFVW6FIvEF54U0JSQFjdVPhVUfhQUOhR+eNXWVVV6FH5EHFWWVZXV09SU0RSUlNXVyBS WVZWqlNZH1JRUlJZU1OIWFnoUUrhDUh7eypAoFFIf3tsUX8NeypAsVFIf3sqQLFRSH/XfnstQJR7 KkCwUUh/eypAoFFIf7RAtL1Qb297rVBse0CtUGxAbEBsUQ0NDUNncVFxZ2NRuH1Ru64prkV/jVF7 VLSGqOKwVchQUFFQI1LkVGhVg1BWUCIQR0lSZFBqUzBY0FjLUcRSy1TEVuBYWlRW6FF95VUgEFFT UupTeFBRU3gQTVVwUxlwVGBUUlSoVVAZf1ZvVlJWqFBVQFUwVVNV6lNYUFdTV+E3SHtJQKQNpA1I vUlApA1IvUpJQL29UEhvSr2tbGFgUQ1DUWNRcVNTI1Eoj1E+rrSWlVLkU0+ssVG5rkdQUFGvva47 VC2vcVBTUEzpUFFRRhBbUF9SFVVQHlRqfEh7QLVAtFBvvWFgU2VxRUNUwK475uZQUFFRQlTgUvZV i1BTUH0QXFJQU0BTUlMgUVBTUuhRBBBaU6hRGVBJVKs3SHseQKQdvaS9UG9srQ1sYWBRcUNzUUJR RNCSVYuuhVBQUlAMr7dUFFRvUHNQYVHyED8oeNZK0kvVTNp4VUJUU1ZwUGNTW0IWShRLGXfYStl3 6UqZSotKi3emdltGSVF/Y4ZTuH+4YLBjrHulf6VgWH1QdElqQglCOUI4SStJ6VDnSopShUiGSbhK une7eF8ISVFhdExTTl5XQVFQca90UXToUUYQSkxgTBBMIEyATLBMVUxxXl9aU31DfVKgfVF96K+Q 42JJb33or5DjeERvfeivkONzQm996K+QEEpOX299d0RbUFBPUFJfUE9QD1A/UIBQoFBWUOhTdBB5 cRBiSW9xEHhEb3EQc0JvcRBOX29fcVGvcVFxelRXVxRPTlFATnBOUk7oUhUQSlwCQWNQX29fUiBf kF9SUF9AX3BfYF+vX1Vf6FJv5mNQdF9RUVHoUhUQSHoURxBvZQ9HUWBHEEefR49HVEdJYhKaSHse QKQNIXsdvaQhvUCkDSEipL2sISK9UG+tDSF7e3t7tA0hb717e3t7DSFvbEFpDX+9IUFCaVFBQmlC R2lhYFANDVENUCIhUSETDAgQQFEQWmlQEFppURBZaVAQWWlQe3t7ewlQDVF1ZmZjYkZFRFZXVkVE R3F2d1ZWc3J2ZWRmZ2ZnZmVkdnNyVlFWV1ZXVkVERmNiZmZnUbeuuGC/lZ2UQWN6SK65QVRv9APU /O2jnRVCGhkdCVFRSnuIEn8YaxEjaUZSqUje8PUnYDy27hwUA2puFhv92MjmQ0FIbHR+bm+u7FdW SmJ0bWIVbzM5UFBSUBqvt1SAVepQQVBPUIcQIRlAUXZQdFtyXHFAcUJxQ3BEdEcRQgdT+FC4UVyA cVEUVMlYUlNAQUBfQVJARV5TTFZTQFJCQkFSUnBRUERRUVBSUVBMelZXRXdeW0FQWlFQQEl0WRB6 YGT/WZ9ZUv9ZUQ9Z31mvWVNQWUBZcFmgWVRZ6FEb5HBxUXFS6FJw4kEnUehSx+cfUFFQ3nBQR+hR 6eEdSHt7QKYNtK20QCGmDSEhInu9e0BsUG9sb71vvW9s11V+ey1AlFFIaX9BaWlQQUJpQUJp11gt QJRelGFgUA1RIQ1QIWNRcVNmZmNiRkVEUlZWc3J3V0NERmNiZmZlZHZzcldWGlFiUXA3H9kB+JoP z/8wtDt1LikCGNMHJQM8HjtV6q5GbGOxh8Guv/sDmP9R4TvWOLQkIdE02VBRUCuvt1TUVG9QS1Dm EGhLS1F6XAlSCVM7UjtTK1IrUypVIE3YS/9Q+VL6U/xK+UviUeVS50HgTUN7WmhSGFJTUUlQXkJf UOhSchBbSXdUW09fUe9fUV/oUnIQb0J3W1dQdFFvUT9RUl9RT1FSr1FRf1FvUR9R31HPUe9RVlFf FFBeQF5wXlNeSk1GdFBXQFdwV6BXVFe1THkGSHtApg29HkCmDR29aQ0hIiJ/vVBvrbQNIm+ttEFC aUFCaWFgUQ0NUSJRVVZUc3J2ZWRCdGNiRkdVdnZzclZWRURGY2JmU3JRRxWuouKbvsBRcv3ssF6u v1oJGAPAHQwVFdBRwH3qkqKE/VFk4ZTwTQkELKc8DjY0UFBSUCmvt1UJVepQX1BMUIIQx3VLH1MT XB9EGkgaTChMV2taakhqSwhFAE7QTvZQ+kaXULdQuF6nUKNTqVpeelp4RSdCIE5URVNwTlJdUlFR Xl1KW1JDVVJHXVNeUVBfX3BeUUReXlFQUVpDd1VbSndbV15fUF5AUAJRwFFRcFEgUdBRU/BR4FFS V1FGUXBRYFEAUVVRTkB0UFhAWHBYoFhUWLVNUUd5nUh7e0CmDb1CaQ0NISJ/vXtsUG9sb71vvW9s 11V+ey1AlFFBQkdpUEFCaUFCaddeQGyUYWBRIQ0NUA1xcWdWVnNydmVkUGNiR0NxUURGY2JmZmVk dnNyUlR3rqBIHscP9Z1RcL2GOyNRT6xnIwQe1wEsAS7yIxsRsYyvUcz6UnWrpiLQO4w1I96uuFBS UCevt1QgVG9QR1BwUYgQwdhC2k9SR09RQttZ2F3UXr1ZVENYQFlGWlNMWEpaT1tIQUlFQ09CcAlY WNpA10/tWeZenFmLWbNYV1tXWkJAUUBSQFNAVEBOQE8UTxVwWgZdNl0qVyhCKE/ZV8Vw81n1XexX 71ifWIlYgFqKW7lXv1iqV6lYokSrTKRPRntB2EJSB083T/JaU3BYSO9wUd9wUXDoUr8QR1BRQFEA UVIAUVFwUVFRVkJNd0NXWZxY6K+Q43V4ZFjor5AQRUlOZABYUR9YUVBYQFhwWIBYoFhVWOhSFxBj QlZ3XFtYLFmcTUjdSFJNSFFIFFBGQEZwRlNG0HJwdNNRUVF0UF9AX3BfoF9UX7VxeQZIe0CmDb0h vUCmDb0iIaS9UG+tEwwI6VBWr5DjYklvVuivkON9R29W6K+Q43hEb1bor5Djc0JvVuivkOJOX297 e3t7ewmkDSEie3u0b70TDAgQSU0QYklvTRB9R29NEHhEb00Qc0JvTRBOX297e3t7ewlBaQ0hIn9s rQ0ibFFCaWFgUQ0NDSFQDVEiUCIhEwwI6VBAr6jiWmlZ6K+Q4lppWOivkOJaaVnor5DiWWlY6K+Q 4llpWeivkOJeaVjor5DhXmlQe3t7e3t7ewlRDVANUXFWRURGY2JnVVZWc3JQZWRnZnFiRkVEdWZl ZHZzclZXVAytYFEpB98AUVEbq8yGrqQp9VFik7auqlE6CQndSVHqQVk60sR7y8tRX4+K+rahiTgM Q1omJtbTUFFQPlBQU5RVg1BIUTEQ81hSWFW2VLBXr1GgV1aAV4hZsFC2U1SAUIhSh1OIVVSXU5dU mFWQV1TgV+lZkFCYUlT/UP1R+1zgUFQoWSpc3FzQSlR1RmZZZUUWUlR2UnZVcFkWVTdTOlxWE0AV RVJ0QGVFFlJTQEFfQ1EPQ1GvQ1FDEHNCb0N3XlFIUlNHUlNTSFhVVFRZQUBQR1NTcFRZRFRUWVFW EE5fb19WUa9WUVZ3UFfor5AQSXNCb1BXUVdWU1RaWVRAUEBR/0CAQLBAU0DoUhfiUJxR6lIZUFJS cuVTAlRXnFbqUnJQVVJyEElvVA9UUn9UUV9UwFRSQFRwVL9UU1QrSVRH6lLpUpVQSHt7QKYNISEi pKS0QK20pKS0DSF7QGxQb2xvIXtsrQ0he2zXVX57Xi1AlFFBQmlXQGxsV0BsV2xsUEhvrXsNDSFi aRvgdQMb4G0BCgjhQXhQaAlhYFEhIQ0NDQ0NDQ0NDVFXc1NxQ3NnY2dmZ2ZmY2JHV3ZzcldWV1dT Znyb4q6x4vB88EdMSXLXPdTCaDcQYUhAQUBUdoKs/FMEgj3WfxAbYJ1zT0QFG1BQUlAQrgFUq1Rv UHVQZFEbENtwZlHXR9N/UmZzHl0bch56VHZHeGBhUGNRVElfdlFSF0eXS6BmU9p/0Gb9fvh/VABm J3ggZtRO13hVan4XSxZOGHwISFV3e3h+aENoSWl7VX1DeWJSSFxbW0lRVVBcSFx9SFNJW0pLS3Bb SURbW0lLW3leSklWYHpFV3l3XlpAUHBQUlBQQFBwUFNQ6lN0UFWvkON4RG9V6K+QEF5OX29VenFf W2V4SVtASutSclBLUElSGhBwSxFQW39bwFtTX1twW5BbU1NbQ1twWwBb8FvvW6BbV1voUZUQS2ZR dFDednRQQUBBcEGgQVRBtWVbR1tlWtxgSHt7QGx7QKYNvaa9QK0NISK9tEC0e0Bse0CQb617e7QN IW+9b71vbEFCaWnXXn57VS1AlFFBQkdpUGlpQUJp115AbJRhYFENDQ0NDQ1QIVANDQ1RIUdVREZG Y2JnZmdmZ2dWc3J2ZWRCZmNiRkdncVNeVHNydmVkUURGY2JmZmVkdnNyVldWE1F/ThNqC2d5SkBJ WsXPzJjYptA64GF4UV3ofW4AKvYxsbZRBT0CG90bKgAd0XpwaHx+f3F0TG5302IsjITrUWjwIDXs rNuF5jwZcMrjQ1JIKS8igjIh2iovMlBRUAZQUFTqVepQSlF5EJlwTFFJVVH/WfpCjFmHXIdAiEG8 QldEVFFYUlhBSFxIX3VRdVx1X3RKZlFoUmZYZlxmX2ZKFlgWXAdUB1wHSilcKl/VWvdR+Fn3XPdf +UH5QvdK5VrmXOZfl1CXUZhSmVmXXZlBmUKHUIhch12LQIpBi0K6QLpBf1RKUFBTQF9eXkFbXF1a SFNQWl1dcF5BRF5eQVNQUHBRUkRRUVJTUlBEeldXXV5eUVBaQV5SUUBdAsBeUXBen16/XlNfXn9e b16vXlRwXi1eUl7oUmIQXFACH1FRUd5LXkdRR+hR6eGaSHt7e0CmDb2kDSEhIr17QGxAbFBvbGxA bG+9b2zXVX57LUCU135Ie14tQJRRQUJp116UlNdeQJSUV15AbGxhYFENUCINUSIhcXFRcVNmZmNi RkVEV1NxQ2ZlZHZzcldWV1ZXUSWusVFjUU8+Mfgw0cZM0q6x1UUSaRgSBn1JeVXqraYcE8QoENat w1IpN01lEGISMGWUUFBSUAJQUFLzVepQU1BXUVcQ2nBZGFPAWfBZgFmgWVZGUUhTUl9SX1NSWFRY VUhUSFX4V/9ZmFSXVpdXh1a9Ur1TuFRdc1RzVX9ZZlZmVwZVB1bQWcZWxlf1VvVXuFNdWFJYU1BZ U+BS4FOQUpBTgFKAU79Sv1NYUlVWVlFTVFdXUFJVUVZTVFBXUVZWcFdQRFdXUFLAU/BT4FNTU+iv kONHSWRT6FN1EF5UUVBQVFVWVldaUFdAUehSx+JWAlDoUscQX1cQb2XAV1EfV1FX3lhXR+hS6eGd SHt7QKYNIXu0rbR7QGxQb2xvbG9sQKZ7IWzXVX57LUCUUUFCaWlBQmlpV0BsbFdAbGxhYFANUSEN UQ1QIVEiIVFxU3FXcVNxUdRRT2ausU5RT46usVXqrqzAq4pQUFKvcK4BUvZV6lBTUEJROxDjRlFG UkpASUFUHVktWZBTl0GAUoBTv1K/U1jgUuBTkFJTX1JfU/BS8FPgUuBTVlhUWFV/RGZWYFxgXWZC FVcSQTdWKUHFVcpA+FT4VfhB+EL/RJ9cuFK5U7hUuEKtQEjXVdlB0ERTF1YHVAdVU1hTXEFKQHBE F1b0UvRT8ETkUuZTgERbUlVWVlFTVEJCUFJVUVZTVFBCUVZWcEJQREJCUEFcQlxdWlJQU8BTUqBT UbBTUVPoU3UQWVRRUFBUVVZdX+ivkBBLQ0dkQF9R0F9RcF9gXxBfU18sWl9CQ3hQQkBR6FJ34lYC UOhSdxBaQl2cf1xRb1xRXOhScBBfr0JRH0JRQt5DWUJHQkNa6FLx4Z1Ie3tAbHt7QKYNIVGkDSG0 QLSttHtAbHtAkFBvrQ0hIntib2xvbECmDQ0hbEFCaVFBQmnXXn57VS1AlFFBQmlpQUJpaVdAbGxX QGxsYWBRIQ0NDVAhDQ1RIlFxU3FXcVNSV1ZzcndnRmNiZkNR1lFwZq6wTlFw7QBpBu4mMn0Vf2oW aVXqrqzArC2uLwIvcL1BClFfUFFQHVBQVLpV6lBbUY4QkVhVVVZIVFNcU19aTFlPWlRCGFEZUxhU GVg9VN1U11tXF1MXWTVWJ1PDU8VW9lPkU5VThVOKWYpas1O3WapZqlpAVlNZWVlaE1MiU9JTi1mL WlhFU8xZUnVQd1ZzV3NYf11mVmFXYVgWVhNXEVgHUwZaNlU2VjpXOFjWVtBdxlPJV8lY91D4UfhW 91rnU+hXl1OYV5hYh1CKUYhSiVOJVIdVhVaJV4lYhluAXbhRt1O1VrlXuVinVadWqVimWadaZFTo UiYQCVVWVldZWllYWlVaWlVTU1RSW1pZVlNUVFhSW1twUFFEUFBRU1RTUlRnVVpEVVVaWVhZWlhw V1ZEV1dWVlRWV1lbV1hYW1BaVVRWUlFQUVBAWAJPV1HPV1FX6FIYEEJPVVHfVa9VUlBVQFX/Ve9V VFXoUhXmH12PXVJdUuhSxxBaWwIfUFFQ3lxQR+pR6VEUUEh7e0CmDa20QA2kDSEipA0hvXtAbFBv bG9sb2xsQGxRQWlBaVBBaddVfntYLUCU11V+SHtYLUCU11V+SHstQJRQQUJHaVdYbFhs11hAlFiU UUhAvWFgUQ1QIiENUSETDAjpUFOvsBBCXGlXQEBpVEBAaVhAX2lUQF9pUXt7e3tQewlQDVENY1Fx U1FxUUNxU1dTHVFjUU/wUSZRJa4Fs66xwpITVeqtVVE3ri6tDFG7/K6RUFBRUABQUFLxVepQU1Ar EENQVXBVwFXwVYBVsFWgVVfgVVFV6K+QEG0TZX9VB1PQVf9Vl1CYUZdTiFGHU7hRp1NbUlNTcFBR RFBQUVJRUFNQWFFAUwLgULBQUsBQUR9QUVDeVFBH6FHp4Z1Ie3tApg0hIr17bFBvbG9s11V+ey1A lGFgUQ1ReyIhY1FxUQBRY1FOrp5V6qoWUFFQGVBQVqNUb1B7UlcQQmZXFlcXSVNYUFhdWERYcFRC feivkOISZX3or5AQr29lAH0wfVJ2WP5c/UX5cYxciF+HRFd/fQB9MH2QfbB9VXVfdUJ1S3VNdnl2 e2dQaVdmX2ZCZ0tmeRVbF18XQhdLF04GWwdfB0vXUtVb2XDQfflQ+Fz2X/ZC+UX2S/pw93v/feVb 413mX+ZL5k7gfZhQmVyXQJlFlkyWTZlxl3qXe4hfh0CJQ4pFh0yKcItxh3q4ULdAuUW3TLtwuXG3 eqlQqFwR1lGffVI/fVFSUlN5enpRXl9AQF1DQkFBRFdzUnd5U3pRXUBAcEFEREFBREtMTHBNTkRN TU5Renpwe1BEe3tQQEFBTE1NentaR3paWnN6VFdRUFZEQU5NUHtAQBBaAn9Br0FSn0FRQehS7RBb TAJ/Ta9NUp9NUU3rUu1Qe1BRUhjiegJQ6FIaEERge1Ewe1Efe8B7UnvefEFHTUd7R+hS6eGaSHt7 e3tApg0hIrSttECkDSG9pA0hvXtAbEBsQGxQb2xvvWxAvW9sbEBsbEBs11V+ey1AlNd+SHteLUCU 11V+SHteLUCUUUFCR2lQQmnXXkCUlNdeQJSU115AlFiUYWBRDQ0NIVANUSJ7exMMCOlQX6+44kBp ROivuOJAaV3or7jiQGlK6K+g4kBpS+ivoOVAaXBIQGlRe3t7e3t7CVENUA1RcVdmY2JGR2ZmY2JG RURXU3FDZmVkdnNyV1ZXU3FDZmVkdnNyVlZXVldTcVF3UV5Lzv4o0kJnnj8v3kzYrrHYSWVlOwRt ezWusdZHaWJ/NBtLXEs2rrFUdtHKNAgAPNggZ9etJ1LZKkB8YyEBnq5OUtI/cXpmaDIddC+uSFBR UAZQUFTrVG9QSVE7EORaV1FYUFhWV1dYX1RCWFZwSwBYU0lSUf5AjFe5V7lAVLhQuF+6QFOaQJdG l0iLQFTkXOddmFeXW1T2ReJY5lrkW1RmRxZW9lr2XVR1R2daZ11mRFR1UHRadl1TiFqHW4leU/pf UfxX+Vn5XlMpVytfKUBTFloXXQdaU1JHSEhRXl1cXF9ZWltYRVFIWFtbcFxfRFxcX1FISHBJUERJ SVBbXFxISVpCelVXUVBWX1xQSUBbAlzor5AQTBdlwFxRv1yvXFJwXJ9cUl9cf1xvXFNwXC9cUlzo UmIQXEgCH0lRSd5KXEdJR+hS6eEdSHt7e0CmDb2kDSEhISJ7vXtAbEBsUG9sb71vbGxAbNdVfnst QJTXfkh7Xi1AlFFBQmnXXpSU115AlJTXXkCUbGFgUQ0NDQ0NDQ0NDQ0NDVANUSIhEwwI6VBYr6Di QGlf6K+I4kBpWuivoOJAaV3or6DhQGlRe3t7ewlRDVANUXFXZmZjYkZFRFdTcUNmZWR2c3JWV1ZX U3FRZFFATDbhMtPHcS2usS5MEWpvynxweAuusVR22ggbxixozK33UgvXSmdvOgdu764cUFJQLK+3 VJtUb1BcUEpQ/hBkGUmATKtJqUpUm0maSlJ5UndYeEJ3SRdCGUkATDZUKEnYSaBMW0AQYklvQBB4 RG9Ad1NXR+ivkONiSW9H6K+QEGB4RG9Hd1lbXXRWEHpgZFYQF2VWEBVl/1afVlIPVt9W/1avVlRQ VkBWcFYAVqBWVVboURsQRnBMUUxEdEBQUVBQcFCgUFNQtUt5HUh7QKYNDb1AIaYNISJ7e3u9UG+9 e3tvvXt7YWBRDVEiIUNAUHFiUEVAUHFydnZRZHZzclZWRURGY2JnZixRHVFfu1FYruauu8a4IlNi Jw4NwAAsDiYAIlHpUXdRD66ti66urtgojFEbNisjiwwi1jXfUFKvpa47VIhUb1BAUE5QqxDdHV0Y QhZGFUw2QlVkWxdfAHA2QiBwyFDLX8tA+FD2X+Zf40KZUJdel0C3X0DcX9xAUnRadEZSWFBZU19D NkGAcFVSQV5fUVJLUV5EXF5BUlNAUV9fcEBQREBAUFFQVkt6VVdEd1xbX0BfSHT/WJ9YUlgQemBk 31ivWFIPWP9Yn1hTUFhAWHBYAFggWFVY6FEb53BwUdBwUXBR6FLH4l8CUOhSxxBAUEBRgEBRQEBw QNBAU0BJT+hRxuEGSHseQKQNISIdtK20QA0hpg0hIXsivVBvbG+9b71vbNdVfnstQJRRQUdpUEFC aUFCaddelJRsYWBRIQ0NDVANUXFXZmZjYkZFQFdWc3J3U3FRREZjYmZmZWR2c3JWVlF3UUBHB8gH 95v/xp2DPCOusVGPKQIX1AciCALXGlR2PRhutrSusZb5+62JUwos2Te/NicvJbNQUFJQKq47VVBU b1BAUE5RGulQX6+g4llpRuivqBDwWWlUcF9pWUZ5RnBwGFQIVDVSNVOAcFh3UXdSeVR5XHlGeU1n QGRGb3AZVB1JL1IvUyxUKVUsWCxZLEIoRyBw3lLbU91U2VXdWNxZ3ULYR9BwzVLLU8xUyFXNRvdS 91PnUudTl1KXU7dSeUJAfVR3QH9GbkBVQEBfSEdUU1NQVERXVEhAU1BTUVJScFNQRFNTUFJTX0R3 V1tLd15XUVBWUetSx1BSUFCvkBBHE2WwUFFQUDBQkFBTEFDwUFI7ULBQUlDoUtUQYFICUw9TUV9T UcBTkFOAU1NAU3BTwFPwU+BTVVNwT0EUUFpRQFpwWqBaU1q1T3lgSHtApg0ivUFCaQ0hISJ/vbQN ISIie0C0UG9sb71vvW9s11V+ey1AlFFBQkdpUEFCaddeQJSUlFiUYWBQDVENUSFRe1B7e1FxUXFD VlZzcnZlZEJmY2JHUURGY2JmZmVkdnNyVlZTqFFYrp6usTcc1gX5nNql37Y3reokAhnYBSoAEtkH VHaqFVG/bmWyiPtRFP+Qrnc7LjO0OSfXOL9QUVASUFBTm1RvUF9QsRANdVJ1WmRZl1OLXLxcVgJT UVhQVlxHXHVQdl1/QWddG1cHWw9BP1cgVtdRmFCXXZdfh123XUJdU0ZSy1fHXlQFV8ZXUlJSU11e UVZSWVRSXVFeXnBfUERfX1BeX1pZ6FH+EFlUV1FQVlBfQFbor5AQXm1lAFZRQFZRUFZAVlJW6FIV EEFwV1EwV9BXUlfe/0FRQV4CUOhSGucfX1Ff3kBfR+pS6VFGUEh7e0CmDbS9QA2mDSK0DSEie3tA bFBvbG+9b2zXVX57LUCUUWlpUEFCaWnXXpRYlGFgUSIhDVAiDVFxV2ZjYkdXdnNyVlZXU3FRcFFc e8b/bhc+d3wayQZ6Fq6xVHaet0+7XiDrm67jUFFQfa+3VDpUb1B8UfPpUHOvsBBZTl9vSHBOX291 6K+o4llpc+ivqBDcW2lAfnB+YH4QfgB+VVpeWHlmWxdcJ3OLXYV1uF1YV3NVdUZzQ3V0dRZaFXNX VlJZSoB+U3B+ZHJmdRVyF3UQfg1QC14ERQBGAkcHdAR2D3wAfid71nvKXvpF8HvwfOB+m0WbRpB7 lHypSkteXVxbWllwcXJzdHV2XUR6UFRRR09IUV9IT0gPSD9IVEjoU3QQQkJMekRXQFFRAFEwUfBR kFFUUehTTBBfQlR6eltIFH9Hb0cfR1NH6FIM5Vh0gHdRd+ivkBB3W2VQd0B3cHdgdxB3VXfefk8U QFF0f1BRD1A/UFIAUP9Qn1C/UFRQ6FJyEFwfQFFfQIBAUnBAUUDoUfTjfRIGSHtApg0hIqQNISK9 QL1Apg17Ib2kDb1Qb60TDAjpUFSvkONiSW9U6K+Q431Hb1Tor5DjeERvVOivkOJzQm9Qe3t7ewm0 DSFvrRMMCBBETBBiSW9MEH1Hb0wQeERvTBBzQm9Qe3t7ewmkDSFpQUJpQUJHaWFgUQ0hUCENUSJQ e3t7e0N1RkZjYmdmZWR3dnd0d3ZlZGdmcWJGR1V2d3ZzclZFREdGR0ZHRkVEVnNydn1RRnU+DzJr eUVGMa6sbjEO01FSnYJMrqdFfxAKCh94SdiCFzSut7arUXl8CBl8TntNR0ZwBmIeLi4LL8bQfmpN d2x3eEpAeG1rAyXHjvlQUFFQyq+3U3BVxlBJUZwQox9T31OPU1OPU1FHVFHCWMRbi1RTK1TVVNRY 1UlUUVFfV2ZUU11TzlOYU5ZUiVO0VFZ4Uy9T2lNTUlJXVFVVUFZQV1ZZVkhGUkZVQVZBV0BARkG4 WLBAukmgVkGPS7BRtFSxVlSPV4lYj0GJSVSUVpRAg1GGVFTnWO9BlFGXVFT0WPVZ9kj0SeBR61dW 0EHQS8NUxljGWfBUVghIKFkpSNBW0FfQQFZySRVUF1kIUwhZCUVWclh2WXBAdEF9RXZIVnVSdVNw VHBVcVZxV1ZZW1tUSEZGU0lTRlBXWFRbUFdVVFtRVlJTRlFWWVtUXlpeQUBDU+hSGBB5VFRbVFNb cEZTREZGU1dfUFGvUFFQd1ZRVlBAUaBAUUB3Q1tBnOBAUUDoUhcQXVacV8BXUa9XUeBXUVfrUgxQ S1BYUhUQWVtRnM9QUVBjSehSFRBFW3TARuBGkEZTUEZARnBGkEakRlVG6lIcUEpRReGdSHtApg0h vbSkIrRAtCpAqA0hIkh/pKQhtFBvvQ0hb2ytDSFs115+e1gtQJRQSH+0QUJpaXtBQmlpX19fX9de LUCU115AlGFgUQ0NDQ0NDQ0NDQ0NUA0NUSEhIVEiUCIhQ2djZ3VTY1dzU1ZFREZjYmdXVnNydmVk Z0PKfNxzURkd/3zgDUl6Z0McfRoeyNp1CVMBhfqWrsCFrhMpQXF1V4VfJThh4VH7UFFQwK+3VKRU dlBKURoQKFJYQGlrWW1EHVkdRPRVVUNaQVtSWEhIUElIeFB4SHBMGEggTPBMgExaUExRWlBaUVhf WEBJUkhASUp1XHVBaEoYSgVeBEE2XTZeNEEnUiVeJEHWQZRVmECWR4ZSj0aHSqBMS15dQ0JDREJf U1RVU0BDV0VDXl9CQe6vqlBer6pQVK+jUEivoBASQUBAcF9CRF9fQlFUVHBIUERISFBQUVFfQFZB QlpXekVbSEt4X0JQSEBBJy9Cn0JST0JvQh9CU19CUXBCL0K/QlNC6FGIEHFUdFBIUcBI8EjgSJBI gEhVcEhgSFJIWUJHSEdIS1oBBkh7e0Bse3t7fw0hIlG9pA0hISG9e0BsQGx7QJBQb71vbG9sbEBs 115+e1UtQJTXfkh7LUCUUWhoaGhBQmlpUEFCaUFHaddYQJRelJRhYFENUSIhUCINUXtRcVNWRURG Y2JuUmdmZ0NxU3FnVnNydmVkZ1F+UU/TSBRldhoebktDRjpRT46upE7gn9PGclR2rdshTH4STWsc bn44UaqrisD5xi5n9FBQUVDJUFBUolR2UFtRW+lQW6+Q4kJpUOivmBAJQmkCVlFQXQ5XBVpTVFBE UHZQc1F7VWNRGVATUQZQBFE0USNRKVjTUc5Qy1HPUs1TyVnJWshbwF35UOBdmVqYW4BdS1BdQ1Em UClbyVDKUfpQ+1GZUYpRWlboUiYQSlFZWFdWWlRVVlZTUFpWUVNbWlpTUlZQUVpa6FKoEEJPW29b D1tTr1tRUFtAW3BbU1voUhUQQwBdMF0gXVNdUgJPU8BTUpxTUVPoUhUQWwBWMFYgVlNQVlFW7FGf UFxS71ERUEh7SUCkDSGkDSFIvUAhpA0hIr1Qb2xvbGxAbFFCaUFCaddeLUCUlNdebJSUUEhAvWFg USENUSJQIlF7e3FzU3FDRkdmZmdRcVI1p4VRShtPVlgrXlFYUWZUdq5h7G5BsUdRkFBRUMNQUFbp VHZQXFHkEO9eUlJXUlpCV0RaVVZTV1hFU0lYVEJQXGtQXGtQXGtQXGsUV1GMVoxYjFm0WlSaVJ5V l1aZWpZcjFKMVVf5W/Be4FDjUedX61rpW1fZVNZXzFDMVcxWyVv4Vlc6VzlaL1QqVyhYL17UU1cb WwtXAVgAWQRaO1I5U1dlUGZUYVVpWmhbb14VUFd4UH9UfFZ9V3pYdFxwXld2UGZQElAVVhRXGlsQ Xtlb01yDWlpRUFNRW1VbVlBaRlFJW1dSVVRXWuhSJhBHUVFQUFNUWllYWFZbXFxWVVZYWVNXUlDr UndQUVBcUqjm0FtRsFtRW+hScBBHWlACP1GQUbBRU1Gcj1pRWssPWT9ZUlnuUhhQUlBUUfNQV1BV UvIQWg9WP1YvVr9WVFboUgwQTFBX0FdScFdgVxBXIFfAV7BXVleHUFJwUm9SU1LoUqnjXQGdSHtA pA2tDSGkDb1AvUC9Db0hpA29QKQNIb1AvUFCaUFjUG9sbEBsQGxAbG9sbEBsQK1sQUJpYWBRISEN DQ0NDQ0NDVAhUXt7e3sTDAjpUFqvsBBaR2lYSEJpV0BCaVF7e3sJUQ1QDXFxU1FxU2NDUXFDUXFU +K6iZK7srqbVrxpRG1FVdFEZUXBS9K0MVHataFKYrWhSmFBRr4NQUFS2VHZQW1JeEIlCBFBRUF1A UkBTQ1ZDV3BdAF0wXVhaU1VVW1tgXRBdDFAKUQ9YCFkGW1psUxhTGFY2UDdT2lDPUMpTw1ZZeVN9 VH1Vdld0WH1acF1mUmZTZlhmWWBdG1AZURhSHlMbVBtVHVYYVx5ZCVALUwlZO1A5UTJTMFQ0VjNb JVQoWSpaJ1vYUNNR11nPUMRRyFnIWsxbwF22U3xTVlZSU1NUVldWVVdSVlZXWVpZWFpVU1NSUFtQ UVtUWVlaUFFQW1FYUFlWU1RRWFdXVVVUVlpbW1FRUlpZtFbUWlFa6lIKUFtSFxBacFBRULRT1FFR UehSCuRS1FhRWOhSChBcMFfwV+BXkFewV1VX6FJ35la5U9RVUVXsUgpQVFIaUFNRmxByT1JRX1JP Ug9SU09ScFIPUj9SL1LfUv9S71KfUo9Sv1JbUupRWlBcUUXhnUh7QK0NISK0pL0NQK2kDb0NQL0N QK0NpL0NQL1Qb2xAbEBsb2xAbEBsQkdpV1hAbFhs11hAbFgtlNdYQJRYbNdYQGxYlNdAlGFgUQ1Q DVEhUSJQIRMMCBBBW0BCaVNAQmlUEEJpU0BDaVbor4DmW2lQcFtpWuivoOZBaVNYQWlV6K+w4kFp UOivsuJCaVDor6LiQWlY6K+I5kFpU0hAaVXor5AQWl9pW0hfaVNIX2lRe3t7e3t7e3t7e1B7e1F7 e3t7CVFRcVFRcUNRcVFRcVJrrqiu8FG7rqJRYctRXVENrkNRXK6fUXquhlJwUlaugVF/rYmuUVBQ UVBdrgFUp1R2UERR6hDkdlNRQlBGFljVWLBGoFhVT0QQRlK4Q6ZVpFanW1S1UrVTtVS2W1SWVZVW h1KFU4VUVeZV5VaWUpVTlVRV9VP6V+VS5FPkVFXDU8JUx1bBWPNSVdBT1lXeQ9VEw1JVJlImUydV KUPXUlUJWABGOlE6WT9EVRVUG0MGUgFTCFdVZVNoWGlZFlIUU1V1UnVUdlllUlRvWddDwFRTVlVU V1JTVFRRWSdAX0JdWbTQVFFUJ0RaWVhY6FEPEHdXVERXV1RUUVRXUXJQRERQUERYV1dRUFZCd11f X2MQQNBAUiBAUUDoUgMQSERYEdBXUXBXYFcQVwBXwFfwV7BXoFdYV+hSbxB8VFACsFGgUVJRJFS5 YEQQRNBEwERUQETARIBEsERUUERARHBEMESQRIBEVkTqUr5QRVKX4f1Ie0CtDSEiraQNvUCkDSG9 QKYNIbRQb71vbGxAbNdVfntYLUCU11V+SHteLUCUUEhvvSG9QUJpYlG9114tQJSU116UlGFgUA1R DQ0NDQ0NDQ0NDQ0NIiETDAjpUFavoOJCaVfor7DmQmlVeF9pWeivsOVfaURAX2lRe3t7e3sJUQ1D cUNGR2ZnQ3FRXlJzcndnRmNiZ/tRThhLU2gyrlFgrSABDdMMCyJJZGHUBVR2rb+cAvPlUYerIsEk EnCGX5hQUFFQclBQVHZUdlBZUUPlVnBOX29R6K+wEAlOX29VUVVSIFYgV1TCUfBRUnZSHFAfUR9T H1QfVx9YH1kPUgBXAFs4UjZXMFsgW91Q31HeUtpXyFf4UvhX71DvUu9T4FfvWZxQm1OUVpBXm1mA VoBXvlBzV+ivqhBZUlZTUhBOX29S6K+A5UdpUndUVuivgOdHaVZ3VVZYV+ivkBBGTl9vV3hHaVd3 WVF3UFpZnE9Yb1hSWOtSFVBVUFKvkOJeaVLoUiYQXVZjVUpbVJzfU89TUlPoUhflUFcAXmlX6FIm EFtRnG9QUVBJWvZgSHseQKQhHaS9e0CkDbQeQKYdpL17QKQhtFBvvWyte3tsb717bK17e2xRaGhh YFENUA1RIVB7e2NnUXFncVdRcVdyeVIWrnV/UxFzreVRr2GSUtSw+609uFBRUAKuAVO4VYNQf1FD EBFlR1FySWlFa3gWSRl4BEcFfDpZNEc0fClZJUnZWdRJwF3PdflF4FHlU+lElFOZRIZGR1lYdElv Rm9HGn9VQ0hRUepSh1BQUUDmSEh0H15RXuhSh+VdQRB0UXToUocQXXVDSHFNS311+F90UXTor5Dj W11kdOhRH+NLXvh06K+Q40FDZF3or5DjW11kXehSkOd/Q89D/0NTQ+hSABBfVqh9UfhQt39Lz0v/ S1NL6FIAEFp9+H9wz3D/cFNw6FIA4xB6UXror5AQW0FDZFB6QHpwelN67FFHUGBQFlFKUEh7QKYN eyG9Day9DaS0QKStDaR7e7RApHshtEFCaUJpUG+9DW+9DUFpf629YWBRIiENUCFDZ25TZ25SZ2Zj Y1dyVldWV1ZXVlZXRkZFRFdWVkVERkZjV3NydnZlZEJlZHYCZBkFGHxLdh49D2/SZGMiGkJeT2hD dDIJa2hccUFNaDFkZdrYGhYbUcqgVHUJJtDnygVKQb9NTkUujmAHPWJ3PwpzGJMYSEt2QqB9OAIT UW9lBx9QUVDgrgFR31WDUFNQb+ZSVcJfNGZT6FJdEEBRUFVHR0pSUlMQUFBRwlRV7FH7UHFQwlEQ UEh7ex6kbB1ArWweQBU1FLZQbx29YWBRe0NBY0Hgj64BV9KoLlBQUa8ergFStFWDUH1RRBADU1VR WUJdRExCTER2Qn1HaURpS2V1GUQWdQdSCUMJRA9LBnUPeTJVMlY5RDt5J1MmVSZWKUYredZS1FXU VtlG23nPWslBxkTAcvZE71CGRIB/d33oUofjf1BRUOhRQOZFRXEQW1Fb6FKH5VpDH3FRcehShxBC ckFFTUpIenL4UHFRcRBbXWRx6FEfEFlIW/haEFtdZFroUpDncEDAQPBAU0DoUgAQX1SoelD4fbdw SMBI8EhTSOhSABBaevhwTcBN8E1TTehSABBDD3cvd893/3efd1V3EFtdZHf+f+hSz+EzSHtApnsN vQ2svQ2ktECkrQ2ke7RApHshtEFCaUJpUG+9DW+tDUFpf60NvWFgUQ1RIVFeUlJWVldWc3NnYmZn ZmdmZ2ZmZ3Z2ZWRnZmZlZHZ2c2djYkZGRURSRURGR1LgCTcaGB49DhDSZWQ8HkReT2dBczwCEmJc cEJJaTRkZdrYGhYbMFHKVBDfrvXKBUpCoE5PRSuMfAcremE2CXQWkB9LS3JBv303ARSukWUHAFVQ UFFQE1JXVDlTzFBGUDrhXEjqUq1QQlF8EEdmXFtTRkxbREZyUH1cZlBkUmpcaV5aUOhTQeJFkVXo U0bjXECRWuhTQuZcUFxwXFJc6FEo51BQQFCwUFNQ7FNZUEdQH1EUUEh7HkCkDR2lDVB/pL1ApK20 YWBQDVF7Q0FmZ2ZjYkZHRmNiZ0FWVnNydnd2c3ITFwRtBG8kxzRq39Ng9x1jNzXKCNxSV1FTHXNK Tm553a6iYgRKfROvr6+5UFBVIldSUnZQdFBQUVdQ3lGnURZQfRBEU1JQQlFAQgBCMEIgQtBCoEJW QlToUWblGHtSU1JB6VJlUHlQe1F7DSFlZVCvr6+5r71VM1aFUnZQdFC9UVdQl1GJUJ1QaxBgU1Jf R09Hf0c/R1RQRzBH30fPR/9Hr0dWQEcgR9BH/0fvR6BHVkdUPhh7UlNSSlJ5UHtRew0hImVlUK+v UJKuDVWnVYNSdlB2UFBRV1CYUdhQVlBNEFlR33NR33NRc2ToUtPmGHtRUXtYeVB7UXshIWVQr69Q BFBQVZVXa1J2UHhQUFFXUN1RulEzUEfjUVFcUehSGeQYd1FRX+lSZVB5UHtRe1Cvr1AMUFBWSlau UnZQYVBQUVdQllGCUR9QS+VRb1tRW1XoUVrkGHtRUVvpUmVQeVB7UXsNZVCvr1Djr7ZWFldSUnZQ YlBQUVdQ3lG1URZQdhBHU1JAdQB1UmB1IHWwdVN1VvsYe1JTUnTpUmVQeVB7UXsNIWVlr69Q66+3 Vk9XUlJ2UGhQUFFXUN5RhlEWUHsQQlJRb3KvclJvcs9y/3LvclRyUOhS8uUYe1FSUk3pUmVQeVB7 UXsNIWVlUK+vUAyvt1TaVYhSdlAUUFBRV1DdUV9QUFBPEEFSf2JRL2LfYlJiVBEYe1JRZelSZlB5 UHtRew0hZVCvr1AMr7dUFFWLUnZQFFBQUVdQE1CmUFBQTRBAUlBjQGOgY1NjVBEYe1JRZelSZlB5 UHtRew1lUK+vUAyvt1QUVYpSdlAUUFBRV1CVUVZQUFBPEEFSIGKAYlJQYlFiVDMYe1JRY+lSZlB5 UHtReyENZVCvr1AMr7dUPlXsUnZQFFBQUVdQ3lCjUFBQYBBwU1LAafBpUlBpQGlwaVNwaTBp4Gmg aVRpVPYYe1JTUmjpUmZQeVB7UXsNISFlZa+vUAyvt1Q2Vf9SdlAUUFBRV1CWUKhQUFBN51JAY7Bj UmNU6K6q5Bh7UlFj6VJmUHlQe1F7DWVQr69QDK+3VBRWWFJ2UBRQUFFXUJdQtlBQUHIQQ1NSgG5R EG7QblJuVFAYe1JTUmvpUxpQeVB7UXshIWVlr69QK64PVNRUb1J2UBZQUFFXUJhRVVBYUEjlUS9z UXNJ6K+35hh7UVF7WnlQe1F7DWWvr1Anr7dUL1WIUnZQGFBQUVdQ3VFUUFBQRRBaUlFxQ3IYd1JR dOlSZlB5UHtRe1Cvr1Anr7dUIFWLUnZQGFBQUVdQE1C6UFBQTRBfUmByUX9yUXJDchh7UlF06VJm UHlQe1F7DSFlUK+vUCevt1QgVYpSdlAYUFBRV1CVUVdQUFB1EEdScHFRAHEwccBx8HHgcVVxQx8Y e1JRculSZlB5UHtRew0hZVCvr1Anr7dUIFXsUnZQGFBQUVdQ3lCfUFBQdBBFU1KAeFFAeLB4oHhT eEPdGHtSU1J36VJmUHlQe1F7DSFlZa+vUAJQUFMeVYhSdlCUUFBRVlDdg1BQTxBBUT9UUX9Ub1RS VFDqGHtRUVfpUmZQeVB7UXsNIWVQr69QAlBQUpdVi1J2UJRQUFFWUBNxUFBPEEJRf1UgVdBVoFVU VVCFGHtRUVfpUmZQeVB7UXsNZVCvr1ACUFBTTlWKUnZQlFBQUVZQlaxQUEsQXlF/VIBUUlRQixh7 UVFV6VJmUHlQe1F7DWVQr69QAlBQUwdV7FJ2UJRQUFFWUN6MUFBO5lJRIFtRW1DoUULlGHtRUlJa 6VJmUHlQe1F7DWVlr69QBlBQVOtV/1J2UAFQUFFXUJZRc1BQUEUQWVFLUM0Ye1FRS+lSZlB5UHtR e2VQr69QLK+3VJtViFJ2UAJQUFFXUN1Qn1BQUEUQWlJRS1MQGHdSUU7pUmZQeVB7UXtQr69QLK+3 VJtVi1J2UAJQUFFXUBNRSVBQUEUQWlJRTFNvGHdSUU7pUmZQeVB7UXtQr69QLK+3VJtVilJ2UAJQ UFFXUJVRZlBQUEsQXlIgS9BLUktTCRh7UlFM6VJmUHlQe1F7DWVQr69QLK+3VJtV7FJ2UAJQUFFX UN5QrlBQUEcQXFJTUnJT3Bh3UlNScelSZlB5UHtRe1Cvr1Asr7dUm1X/UnZQAlBQUVdQllCqUFBQ S+VSUExRTFPor1DkGHtSUUzpUmZQeVB7UXsNZVCvr1DAr7dUpFWIUnZQCFBQUVdQ3VCuUFBQR+NR UUtQ6FJJ5Bh3UVFO6VJmUHlQe1F7UK+vUMCvt1SkVYtSdlAIUFBRV1ATUWxQUFBL5VHQTFFMUOhS XOQYe1FRTulSZlB5UHtRew1lUK+vUMCvt1SkVYpSdlAIUFBRV1CVURFQUFBH41FRS1DoUnLkGHdR UUzpUmZQeVB7UXtQr69QwK+3VKRV7FJ2UAhQUFFXUN5RaVBQUErjUlFyUehRZeUYe1FSUnHpUmZQ eVB7UXtlZVBRUP2u8lSRVfZQW1DvEG5IVEdaeFR3WjdWNlkoVtZRWHBRcFIQURBSD1EPUlZQVFtY UVNUW1dSVlVaV1JZVVpYUVhRUXhSV0RSUldRUuhSfxBsW39Ub1QfVM9UVFRxWlUxV1dYUFviUFri WVUxVlQxU1lZUVBQWFFWVlJTU1dSWDFReFcxVFJwUlJSrFzC6VFdUEh7QKYNtK20QUJpf0Fpf0FC aX9BaX9AtEC0QLRAtFBvbECkbK0NbKZs11V+ey1AlF9fX19hYFANUQ1RU3FDcWdxQ3FTcVdTfKau oqau339RIQJRXgJRNn9Tbqs0VMyPUdmuJ49QUFJQBlMFUoRVg1BbUEdQbuPQSVFZ7FKRUF9RlFBF UpHiU1FW7FKRUEJRlFBcUpEQWw9QP1BSUElIy+pIex5ApA0dvaS9UG+9pL1hYFENQ2RmY2JGRURW c3J2Z0RGY2JmZWR2c3JWBuvU1Ovr1NTr9gpvbwoKb28KVMTV6uvU1Ovr1G8KCm9vCgpQUFJQKK4l VNBV5lBwUHdRTxArV3R8VX9deUJ/R39IeXJ/eW9Ab0ElWSdbJVwqXStHJ3TZR9hy1nTGW89I8En0 SqldSFlWWUJXQ1hyUHNQdFZIdAlByFzFR1RZQlFcQkNOT09bUFlxcnBaWnBwn09bRE9PW19CQFxZ cldDcUlTSFBORUxPcXl2IEjQSFJI61IYUEVQQFJyEBJyd1daUFdXWVdOW0V3TFtPXnlHR0pAX1EA XzBf0F/AX/Bf4F+AX6BfWF90QN5JdHBIUUh2dFBTQFNwU1NTtXh5Bkh7QKYNvX8NvaatDSIeFTUU tlBvbx29b29vb0CtvUC0DVFBQmlpUEFCaWlBR2lBQmlpQWlp115+e14tQJRXVWxebFVsXmxXVUBs bF5sbGFgUCENUSENdXZ2ZWRCdGNiR0NHU0ZGR1d2d1FGY2JmZ1VWVHNyd1N3Q1FeUkVEUQs2LchR cPFOcsspwzfQV6xaa66hW1UULH1RWBCuo/58ZMsqolFcMMQZQn+IxuRRZfdTUSphrsl5+CJKD2Wt O1EwIHnol1iu1mBSHlLbVtqhOTxQUFFQeq+LVLJVg1BhULIQSU9NR0l3cE10WFlcQURDU0JQR39T X1JDYHroUgAQQXlgEEJhX2FRYVV0L1nfWVJZ6lLCUFxRTOJVUUnoUsLlf3dRd9JN6FFMEER0W3lb Q/hCkV9g+GFht1JP0nC3WehSAOVQWEBYUljoU3gQQGNfB39SUVKReX16sGIW+Uh7QKa0pA29QK0N vaS0KkCoSH+0QKS0UG9vvaQNvW+ttA1BQmkhf2y9QL1AbFFBQkdpQUdpUEFCaUFCaUFCaUFjYWBQ G+BbAxvgQwEKCOlQeK/gaAlQG+BHAxvgSgEKCOFPbGgJUXZlZFBjYkZHVXZ2c3JWRURHY1dzVlZX ZmNiR0ZjYmdHVldWc3J0c3JXU2ZmZ2Znc2dRHUFRSorut12ur0ExGgzVX61/k1YMIhoadmwGYj8l BgdhERQyrqEG2c1ONMVwSFm2f1MZBh6BUUWG5kk7DMfXYgywIeE3TltAZaR0W14aBlFTe8oVYh+w UFJQfK4eVCtVg1B/UBFQixBiCXFRZnZlamkQCl8JQDl5yUPGecZ7iVlaVnN6EStAU0hJTFBRVHho YEBURX1fSU9JUknoUvgQfUx3RVFQUUBRUlGoVHd9QGBPQmloeFNtV3BRUVEsUNJdcE9RTyxfQk9C f0JTQuhRWRBicGNRYyxQXVFd/hJ/V1FXLFB6QHpwelN63W1/SVFJLEh/bVFtLEj4UHVAdVJ1sBM4 fEh7QKYNtL0NQL0NQK0NvQ1Apg2tDa0NvQ1ApL0NQUJHaUFCaWlQf620DW+ttA1BQkdpQUJpQUJp YWBRIQ1QDUd1RkZjYmZlZHZ3dnZlZGZndmVkZmNiRkdVdnZzclZFREZHRkZFRFZXRkVEVnNydlFW VkVER0ZHRkdmZ2ZlZHZ3dnxRVUs4HRQWZ7ksNNbWbJqY5ZRFrq1WHxFtF2AshjTU0ASJkOylUe8f Z3JGxjlYF31NYATpB2s+CxB/cgewJvEMJv8YMQ7al/r7SQgAFmh5AiCQ4go46hAlOteSkFR1YQVh YH9NwTVYS2dzfXYFAeRQUFFQElH8UsFTq1BbUG7jUF0zcehRfOJmUF3oUq0QREBwZlkgUCBWIFNT IFAgWSBQVlFW6FHw41wfM0h7QKYNra2tUH+9rb1hYFF7e1FEVnNydmVkZmNiRlLB/Sor/f0rKv1S hCv9/ioq/fxQUFGvrq49VDlV6lBCUNrlf1xRUFFA6FG85FK9W11C6FH851xbUFLPUVFR6FH8EERC UFBQQFBSYFBRUENEXVxBz0BRQOhR/BBbX18PXj9eUn9eUV7oUR8QXVz5RD9VUX9VUVUWQ0ToUSzj cWo3SHt7HrQNIkCmHaQNImxArSJsQGxBQmkhDX9srSJsUG9srWxArbRpaWFgUQ1Rc0F2dmVkZmZn ZmNxQXNBc0FzUiuj7pwC2w5o81IFIb3Arj1UR16I4jn/NkRcrqup6FYYUFFQGK+3VPdVg1BlUO8Q aF1CUVhSWHVIdXVSeFR3RnVlF1AYewZQBlEIS81LzUz7dZpTQFlL0EnQTFNlUFBwUVJEUVFSS0hM 6FN2EF9PYXdWUVFaT3dIW1JRQEzoUhgQXksrUHh0315REF6wXlJe6FIaEEx+dFnfclFydFnFX0RP RFJEEEFHZFBEQERwRFNE6FIr4mdRR+pR/1EUUEh7e0CmDXshtL0hQL2kDSG9QKa8e0BsUG+9b2+9 QLRCaddVfnteLUCUYWBRIQ1QIXFxQ25SY2JGRUReUkVER05SRURWVnNydndnRkZjYmZlZHZ3dnZl ZGZnZmZlZHZzcldWV1E3rrGZeg+54+noYMBxXETEfA36Oj6TbJxNaHVkFEtkCmZ/C39HZX4MbHl9 U5GW7t7wJ2k7+m1ISUl2lj1vCv8PPQYjenEUY3FsEiAnYX48Km9kSnljCm2DUFBUr6evjFWjVYhQ X1BPUGhQE1FeEBsVEFtBZGlSZEJkRmtKak4bfhtkC34LZDZCNkY4SjlOO2MrY8pg+WCWZIRkqWNE FnbaZFJsZHtTaGJuYUx4ZGJhU2h7Z2wTanFyQHToUUEQXF8TUe8TrxNSE81QZ+hRQecwaN9o4GhT aOhSCBBDampYQNVQU0jVWFlM1WBU0FRSVOhRXxBN0BVRFV9uH25SP24vbq9uU24P0HhRAHjfeO94 U3joUYYQQnATUGgQaFIwaCBooGhTaA9xcOhSAuJE1VzoUV/jFC9iSHseQKQdvaRsrQ0hbECtDSG9 DSEeQA2mIR29UG+9b71CaX+9Db1ArQ0hvUFpaUFCaUJpQUdpUUFCaUJpQUdpYWBRIQ17UWJUQkVE UlRzcnRSZWRCdEdyVFJFREJUY2J0QmVkUnRRQWNiR05SRURWV0ZGR0ZHR3N3dnZzc0FBY2JmZmVk dnZzc1KllVE6n5uuxZiYrsWbn1E6ls6ujvfzUXTw8VFz9Peuja5X9bhMAgttIzh1eHNZYzCcFBUK FXsT3xV4dxjdE1WIla7AmZiuxZubUTuYmVEglcbOrojy8a6M9PRRdPHyUXjOq65TfVJXYzkQCC1f XnF+XAf01NUVruJRnkZnc3JlR1BTr6evjFWjVYhQX1BPUGpQmxAPbBBbQWRpUmBCYEZvSm9ONkI2 RjdHOE42YzZny3bKeV1+f2JxUHBAcHBwsHCgcFVw7WjVX3RRdOJYX39Pf39/v3+vf1V/7WLVUHtR e+JA1VBRSNVYW3DVcXF/1UB+UX7oUSQQWXdM1WBU0FRSVOhRX+fQbFFsEGVRZehS+BBDUHcAd9B3 UwB38Hevd1N3MUTVXOhRX+NranxIe0ClvaQNIb0hHkANpiEdvUCtDb1sQL1Qb71vvaQNrbQNQKQN rbQNaUFCaWFgUQ17UWJUQkVEUlRzcnRSZWRCdEdyVFJFREJUY2J0QmVkUnRDR1ZWc3J2ZWRmZmNi RkdXdnZzclZFREZjYmZSpZVROp+brsWYmK7Fm59ROpXOro3281F08PBRdPP2ro1M8XbgKvuIMOUg K/V+8kwJbQskIgATMlWIlq7BmZiuxZubUTuYmVE/lsfOrony8K6M8/NRdPDxUXjOrXdmLtawldGa NCUudhkS2cLC2h9QUFJQiFLXV1VV6lBXUERQhBAOVlpZXFJZQFlDSltKQEpDGUM/WypD2VvZQNlD yUDJQ11gRhlbG0IARjZBOEIwRiNaLFwmQShC1FrbXMVaylxfW0FCX15XUFREQ1RSRFi9WVJV7VRd XFxaWllZVFBdXuhR8OZAL1+QX1Jf6FFH50H+L0KQQlJC6lFHUERR8OJYWFnuUV9QVVIEUFdR8FBQ UgTkUjBTUVPoUpDjRcuOSHtApg1spK2kpmxAraYNpqYNbK1sUG9sQGxAbEBsQK1sQK1sQUJpQkdp UUFCaWFgUQ1QDVEhUUFzZXFFc0FxQXFDQ3FBc0FTc1NBUYWtUsmmUQlRU8XGUVPO4cbgUtdS9d7e rQtTY62cUmSsnVLdrSNS3a0jUFBRUShU/FMrVYhQU1BpEFxSUFNAU1JTIFFQU1LoUQQQXVNRIFCo UFNAU1JTSVTqUedRSlBIex5ApA0dpL1AvVBvbK0NbGFgUXFRc1IZUWKu7O9ViK6EUFJQ/VSXUytV 7FBTUFdQ0RBxH1nAUMBRwFTAVfBQ8FHwVPBV4FDgUeBU4FVdVldXUlJT6FIAEFlQVVRUUVFQU1Xr UgBQVFBWUgDiVPhX7lFHUFJQUVIAUFBQUlIAEFtQ+FBTQFNSU0lYwulRSlBIex5ApA0dtL1AvUCm tL1AvVBvbEBsQGxArWxAbEBsYWBRDUNjV3N1Y1dzsKZjplGIpmOmVeylpaVQUFKv7lBQWClV6lBf UENRCxAJ+UHrVOtX60FUDEALQc9Wz1rPXvtQVhpQH1ccWB9BDlALWFZ2XGZUaFdoQWZDVVdXXEFC QV9DUVJSQlBAQUFfW1hXXFdcXHJfQURfX0FUU1NyUkJEUlJCWVjoUpgQQFpbf1sfW+BbkFtUW1dc QEPoUpgQWlBRf1FRUVRTXVzoUpgQWl5fX1JTWFdWVkLoUpjmVVRSQV9AWuxSElBZUhJQXlISEF3v XZ9dUt9dz13/XVNd6lIYUFZSEhBZUFVAVVJVSkVX7VLCUFxSdFBfUFNSCeN/UlFS6FK45TBCIEJS QupSylBBUQ3jz19RX+hSt+JEX0foURXhPEh7e0CmDaSuDaQNvUCttB5Apg0dpKQNDbSktHtAbFBv bK1sQGxvbGxAbK1sQUJpDX9srWxBQmkNf2ytbNdVfnstQJTXfkh7LUCUV2xsV0BsbFdAbGxSWEBs WGxhYFENDQ0NUXFTcVFxV3FTcVdxU3FXcUNDc1FT/a5HgK6aUwRVN2OtYhZS4mStHwNTV2OrsNAv 4672UT+uwVXqpa7hpa4kpVI0UjGtz1BQU1DPr9ZWG1ZyUEVQTlB3ULcQDlhaV0VURlxPCU8JcFZS W1BcXEdGWklFSUdBcHVbZVxveG95OlA3WjhFN0dfW09wQ0REWlhHRlBFRVlIV0lWcUJyQXdcdl1O UU1SRchEpXByYHIQcsByVHJ+QVlayFnoU04QXn9Jb0kfSc9JVEl+VlNZ6FFBEF9aCnZ4UF1AXW9d U11KeUToUUEQQUUKTXhQUkBSb1JTUkl4aWJIex5ApA0dvUmkSL0eQKYNHb1JpEi9UG+9DUmkSLxv vQ1JpEi8UUFCaWlBQmlpUEFCaWlBQmlpV0BebGxsbFdAXmxsbGxhYFENUA11dmVkQnRjYkdnR1dG RURSVHNyd1d3UVF2c3JWUkVEUVFGY2JmQmVkUWXaglEmup7a3NrA07Gu3bKW08PdUQtS1h87Lbjb U0ut0gQxJrHJ/Pe3ulGUuwn4Iv3wqr6uHrIA4SJR8VNXZ/au7M4PUnCtUGfwURj4AVBSUGJQUFRj VTVQW1BfUIEQdmBdYF4QXRBeVGBaYFsQWhBbVFxdUFJeX0FYAFZRVjFYYFMQU1JT6FIA5lkAUlFS MVvrU3pQXlBdUgDjX1xaW+hSABBGUFRVUQBQUVAxUlkAWFFYMWBWEFZSVuhSABBcAFVRVTFTU1JS XV1c6K+Q4m9lXOivkBBOamVAXABcUlBcUVBcQFx/XB9coFxVXLVAQW5xHzNIe3umDSEie3tsQGxA bECkDa0NpA1sQKQNbEBsQL1Qb2ytbKakDWytDWy0DVFBQmlpQUJpaWFgUQ1QDVFBcUFxQXFBcUFx QVFBcUFR4q7QUdBRUFHRri+t0FRRUTRRLVFXUS2u066prtOuzFFXrqlQUFFQYVBQVQVV6lBKUXUQ wldXWUNAREFFREhESXpZc0NtRBRaFFsVXDVVNUcvUydaJlsmXEJqWWlebl9uQ1RUV1hYU1xeXltA QUFeRUhJSURSU0lRVlVUSFFWR1RIUEZKU0lQRkRFTFhXVFNUS0hJTF5WRlhXeENCQpJBXkRBQV5Z WlqSW15EW1teVlFRklBGRFBQRlpbS0FMXl5aWElTNUhU6FNeEEVFRVc1WFhERFBCQUFbW1pQUXhQ Wl7oUYjlS0ZAUEcf6VFMUEh7e3tsUUlApFBIb3tsUG9sQGxAbEJpf2xArWxApmytbEFCaVFBQmlC aWnXfnstQJTXfkh7LUCU135Iey1AlHtBQmlpUUFCaWlCR2lBY2NfX19fV0BsbNdAXpTXQF6UV0BV bGxhYFENDXFxQ3FncWdxZ3FTcUNGQ2ZnZ3FRcVdxV3FXcVLXrrVqrtt4USVLrtt4UUCcUXQXS2Qp LC9RF65hUUd4rt9KUSB4rsBRRpEvkVLzrq01rqWh75OtDZEvkVBRr+SuNVT9VHZQSFCIEDIeRVF3 UX9KZlZnW2ZeFlQXWhZeE0cUSBBJMErUXthI0ErISIBKoEpCQEoQSlJbQF9fXEZSU1VHR1FGSUBK VV94QFheUEhIcEdRREdHUV9cXHBdXkRdXV5dXFxRUXhQVl5aRuhSFxBKWHdDW0h4R15VVUpHSXhR R11eQEdHXkdHSVroURbhCUh7e0Bse3t7QGxAbHtAkFFCaX9Qb3tsUG+9tG9ve2xAbEBs11V+ey1A lNd+SHstQJRQQUJpe2lRQUJpQmnXQF6UbJRs10BelJRhYFEhDVANQ3FTV1ZFREZjYmZnQ3FTcWdW VnNydndTcbtRTzZKVg8VHyx5JVFMsK9QRR8GYhINez6usVR2rkQoeXYCNC2QUnyrijMBe24craRQ UlD4UrdTHFWDUE9QeFDnEGBbQIBRUmlSUVlFWXJZeItRi1KIRlZfdl1fcI9wUnDtSUlUdm8PQVFB fVBdUXBdUV3oUSQQalSAUFFQfb9Rr1FSz1GPUVJR+I9OUU5vVFFwSV1TS19cWlCAUfhEV4CAS1FL 0lqA0F9RUF8gX8BfU1/oUfkQXXOAUERARFJE/nnC+Uh7QKYNraQNDb2kIb1ApL1BY0FCR2lQb60h pA0NtCFArSENpCK9Qml/vSFBQmlhYFEhDVAhUXdmZmNiRkVEUkVER3N2d1ZzcnZlZGZnZmdmZWR2 c3JDVlZFREZjYmZR+5B6+C/c1ANFkFhTCzoyJA0LarJeen4KKPMRenNmGlS1SjY+IQUWrpF5ZWNG SW8jCAA+R15HZUxJca63Q310THcVUFBSUMRStlMBVYNQXFBIUGHpUEBSkeJal0boUpHiU1FD7FKS UFZRmVBdUpLlUElJOPlIex5ApB2tpL1Qb72tvWFgQ2RCY2JGRURWVnNydmdERmNiZmVkdnNyVsSC /93/MeMj3PqabGECOGthAjlUSvtRXv3WMLAq+yFlbpM3Zm3uUFNQb6+3Vr1Ub1B8UGVQEFHeECVA VkBXUgZT9FXzV/JYmViLWIZxuVy5EK1Wr2tbT1ZMV09YU1pWUEnZV91Y1XlVcFZ2V3BfdkN8Tmlo GmgKQghoOmgvQidDJHQvfS9gL2UpaN9932XLaL1DvWigV0dSV1R22UTUelRPS05XVFZGSFtTUT9m UWboUUYQSkbQRlFgRhBGIEaARrBGVUZtS2UffVEgfVF96FK/EHBQUFEPUT9RUlFUYnp4eHJQTk9O Ul9OT04PTj9OgE5VTuhSFRBIX0tRS3pyV1BWgFZSUFZAVoBWsFagVlVW6FIXEG9Ud1lZU21RoG1R bXddW0BlUWVjURRm0GZR8GawZlJmf2pWLFecT39R3X9RfxRQe0B7cHtTe9APEoASUhJOFE/oUhUQ RGoUX0APQFJgQJ9Aj0BTQEkREppIex5ApA0hHb2kvUANpA29ISKkvUFCaQ0hf620IlBvvQ0hbECt tA0hb60htA0hQGxAvUFpDX9sQK0NIWxBQmkNIX+tDVFBR2lQQUJpQUJpYWBQIQ1RISINUCJRcUZG Y2JnVVJxcHdWc3J2ZWRmZmdmZ2ZlZHZzclZXdWZmY2JHRkdmY2JGRUR1ZmVkdnNyVldVVFdWRURG Y2JnZlaKrXRULwrAHVFS/K6SrrYi6K/K5CP/84RsWB4DGwNGrr12o5XAB2522oeTvK6rUTsHDclM roqusglmGm4OGTFR6CTW2nmumKio/donzm1fQ0dxSBcZahJM1fh6Tm3VooUxAERdIijY0yJPbXVs YRYXDFBQU1A8r8VUhVTCUERQT1B4UQsQx1lSVlxYcUlSSVNHXElxc1B2UXlbcER/RXlJe09wcWZR b1ppW29FaU9hcR9FGk8OSgB1NlA5WjZFOXDXWsdayHH6UPlU+lnpRelwl0WJcKlFeElPaUIWchp1 AHogesZKyXX8XplxsHqgelwQShtOEHqAelRAelFTcHFaW1tSUEVPXVxcUXJZc1hGREdDeFR3VU5e TV9cJFvoU3bmc3dYW1IkUehTdhBqR3dDV1G0UmPfd1F3dBBVUVBVQFVwVQBVIFXvVZ9Vj1VYVUp6 W7RcY9BNUU10UF9AX3BfU19JeXkdSOhRUtV7HkCkDR29IUmkSL0eQKYNIR29IUmkSL1Qb71JpEi8 b71JpEi8UUFCaWlBQmlpUEFCaWlBQmlpV0BebGxsbFdAXmxsbGxhYBvgWwMb4F0BCggQXEVRcE9R cUVRcHFRT1BAR2xAR2xRQEdsQEdsCVEiIQ1QDVFnR1dGRUBQcXJ3V3dndmVkZ2ZxYld2c3JWVldW RURHUVFGY2JmZmVkU7osPyo9ruauvMwnLzwqPS7xUW71fWYXbjQPT3xfUkWuFmcWDcgJVFLADt4t ma6vrtgQwjDd0ZO14bOicmMgHj43f35R3K5QTyW3Mn5QUFJQZ64DVH1UdlBTUE1Q6RB4W1lYS0tZ SUt0QHBBVlBUUFVScktwT2hEGUomVy9f1lffX1hCXkGJXuhRTBBZRV9UUFVAVVJV6FN65FAZU1ZB 6FIAEFpwQj9Cz0LvQlRC6FEf5FNRGVBU6FIAEEhwVVFVfVD4UhlTSk9PW1H/W1F/W89bUlvoUgAQ Wg9IL0jfSM9IVEjsUiFQTlDcUW9QSHtApg29DQ0iHkCmHb2kpA29QL1ApA29UG+tpg1sb729QWlh YFENUCENUXFDcVFxVlZXVlZFREZjYmZnVVZUc3J2ZWRmZ2ZmU92utGpRTK72UVJEL+/xaTI1IN5P UVZirouBiqQ4ucIUU0BRRq7C1pX23At6bgIq1X6SsonGCf6SKjBQUlBIrjxSIFR2UFNQWVCbEEpa VF9VWFZYV0dWR1l4VHdWdllZU1vQQ01mUOivuONLT2RR6K+4EGVLT2RQaEJFZFFoQkVkVVRcVUZU T1V2VXhWaFYoVclWyVn4VvhZXFlRUlJYVlBTU1dUcFVRVehRKhBBWFhXUVBSUBlTVlH4UlD4U1Tr U3BQUlBVUQHjU1ggV+hSkBBfUhlQU0BTz1NTU0pbDTNIex5Apg0dvaS9QLRAtEC0QLRQb71sQGx/ bECtDWzXVUBsXi2U11VAlF6UYWBRDXt7e3t7USFRcUNxUWNTU3FDUmautGpRTK6MzgwYroIdU0BR Rq7brUOu+FEiUFFQBVEoVAZUYlBVUDDpUFVRe+dTUW9SH1JSUuhSABBaVFNWUG9RH1FSUehSABBP VTBUUVBUcFQQVPBUkFSwVFZUC1LQU1FQU0BTz1NTU+hSrONWwjdIe0CmDSFsrQ0hbK0NbFBvbK0N bEC9YWBRQXFBcUFTBa1QVFFRKFHpUVGtFlBRr7yuAVQmVYNQdFD8EA3BTFFIW3hFc0h4dGVHGEVW QkVGQUFGRnBzU0Rzc1N/Xm9eH17PXv9eVV4sWVFbRH9Qb1AfUM9Q/1BVUDBRQ0JCUlJwUVFRc0xw T2BPEE/AT/BPVU8sSl9MY0xjdVPoUhjlUHNwc1Jz6FJ243BRUVHsUgNQdVH/URJQSHtAtg2mDbRA tLRQb70Nf39/DWxAbEBsQK0NbH9vvQ3XXn57LUCU11WUbGFgUQ1QDVFnY2dmZ2ZnZmNiR1d2c3JW V1djV3NTXlJzcndnRmNiZ2ZnQ1FEdJpATERwaBrX19RmDhBmZEFbgHWd/UQR0iLMLGk9am5JREHG UwODCcl7EnJ8ebJMYAZog6x+JyQVeI1Hdk04UzlQUFJQPFAXVC5TgVBVUFtQLRABB1MHWbFWsFmw W1VVW1FYWFewWlFaqlvdViBQWRBZ0FmAWVSAWaBZUlmmUFSqVd1QGVNXglBYEFjQWFNY/lGCgFJR UuLfU1FAU39TIFPQU1RT6FNW4136fEh7QKYNIaQhraYhvUC9rb1Apg0hva29DVB/bEBsf2xhYFEN UVFjUUNzUVFjUUNzUlVR1aSuzi+erc9RzKGux9SZUnlR+K4SrmRRsVH5rhSuYlBQUlB+UBdUEFOB UFVQW1DfEDl/XQhTCFkAXSBd0F2dUZxSnFOQXVpYUFhW31ffWFSWU1FRWFhXVVtXgl9YH1hSWP5R Wqpb3VYgX1kfWd9Zj1lUj1m/Wa9ZU1mmUFGCUuJTVKpV3VAZEFPQU4BTU1BTEFMAU1NTlFwfM0h7 QKQNIb2tvUCkvUCmDSG9rb1ApiG9UH9sf2xAbGFgUA1RIQ1RUXNRU2NRUXNRU2NS964rpFExLp5S Ma4zoFE51ZpRoK4HUe9Rm65wrgZR7VGdUFBTUO5QUFcSUUVQU1BXUFtQOBB8YFBgUWBSYFNgVGBV YFZgV2BYYFlgWmBbXFgZW1pUGVdaUBlTWlr4WRlb+FjoUXDmVvhVGVf4VOhRcOZS+FEZU/hQ7FIE UFxQ/1EQUEh7QKS0rbSmtK20prSttFBvvW+9b71hYFENQ3FTcVFxU3FRcVNxqFFMaq60UoFRTGqu tFKCUUtqrrVRRa67UUWuu1FFrruvr6+5UFBVM1duUnZQdFBQUVdQE1G0UTNQcxBFUlBcUUBcIFzQ XKBcVFxUiRh7UlFe6VJlUHlQe1F7DSFlUK+vr7lQUFUzVq5SdlB0UFBRV1CWUZBRH1B6EENSUFwg XFJAXABcIFzQXKBcVVxU6K/Y5Bh7UlFc6VJlUHlQe1F7DSFlr69Q46+2VhZWrlJ2UGJQUFFXUJZR tFEfUHAQWlJAT9BPwE9TT1borqnkGHtSUU/pUmVQeVB7UXsNZVBSUN2vt1jxVYNQSVB6UXkQElVI Qkh2SGZIDF1VWHFYckhycFlyWm97H3wJcM1Tx1jNc1tUV1hYU0lcW1tQSElTUFxdWHNQW1NYWHJb UERbW1BVVOhSmBBaVlcfV1FXUFtSU+hSmOVRUVBSWVjoUpjiWltN6FKb4l9ZduhSm+VGU1BbQFPs UsJQWFJ0UFBSFBBcW19bcFtgW1NbWkpWEVlSElBVUhJQWlISUFlSwlBSUhIQcFBRQFFSUUp8SngQ QgBCMELwQlSwQqBCUlBCQEJvQlNC6FLK43tbR57pUURQSHt7HkCkDSIhHb0eQKYNHbSktKS0QUJp DX+0rbR7QGxQb71vvUBsrWxvbECtbEFCaQ1/bK1s11V+ey1AlFFBQmlQQmlpQUJpaVdAXmxsV0BV bGxhYFENUA1RcVdxU3FXcVNxV3FnVlZzclBBQEJ0Y2JGR1FERmNiZmZnZmVkdnNyVldWVLhT6WOt NRRS12OtKARSjmOsU0kQxTmLroiYUTHgI+xgrIb11A/fD3VkxCYugRJkVeqlrumlrjylJhoVUW9R SFFRUeuJNQitV8f8CfHKhdLSyuaZ8lBQU1Anr7dX3VRvUE9QeFBlUVsQAXBWcFcvcC942U3fcN94 s1ZYH3AfeFJ/RGdXZVg2VyZTKVUoTCt02lW9Vb9Wu1etValEoExfWlXZV9lY21pUSWJGV1RWW1t8 XklbUX94IHBRcOhSvxBGUFBRAFFRD1E/UVJRVHV3S0tid0ZXVuivkBBFdXhkAFZRUFagVlJQVkBW gFagVlRW6FIXEGlUd1lZfHdeW3hjURR/YH/wf1J/cnlWLFecchRQTkBOcE5TTtCgZ1FneXRQQkBC cEKgQlRCtWZ5Bkh7QKYNvUANpg29pL1BQmkNf620UG+9bECttA0hIntvvWxAvUFpDSJ/bECtDWxR QUJpaVBBQmlpQUJpQUJpYWBRIQ1QIQ1RcVZGY2JnR1JxcndWVnNydnZlZEJ0Y2JGR2ZjYkZFRHVm ZWR2c3JWV1VERmNiQmVkdnNyV1ZXJK1kUigIxB2v+66ZvNYfnC7FtSjeUUOYJesV+4yZuK6nUTkG CNZzrIApDcD4KQ0qHSFR5yzXxX2um88fACSz1/NRf/gaGsShjDgORF8jJCvfmTErUVfzKNIx31BQ Ua+sUfpUP1IsUFNQcONRylBS6FEs41BJVFXoUSzjcWo3SHt7HqQdvVB/vWFgU2VxRVRUI1H6goJQ UFFQUFH6WFBSLFBTUE/jUcpQUuhR2uNQUFRV6FHa43ENN0h7e2xAvVB/vWFgQWVxRVhQUfqCglBQ UlFQUydU0VWbUFpQRVAmEEElV9Ze1kJTV1hWWVAZWlsZRetTd1BBUFpTdxBeVu1VVUHtQFBfWU9Z UlnoUQHkWvhQGVHoUUfmW19ET0RSROhRARBdRfhbIMBcUVxJRu8lSHseQKQNHa2ktA1Apq2kpA1Q b71sQK22QKa9QL1BQmlpYWBRDVFxZ2ZmZ1dWVldjUXFnZmZnV1ZWV2NUVK6Pf3rlwEwYHkXUrbSu jmB65MBMGB5E1FMntZf1U9VBAgeuu7WX9VPVQQIHUFJRV1M2VNhV6lBaUEVQ8RBqQ0JEQUFAXVxF WFdZVlZVUlFaQe1ARFBAUUDXWxlfRb9FUkVW7VVZUFVRVddQGV9av1pSWlBEQERSROhRARBcRVwg RfhbUFlAWVJZ61EBUFpQW1FHEFxRGVr4UFBAUHBQU1DoUXDjRu8lSHtApg20rbZAtA1AtL1AtA1Q fw29tA1sQL1/Db20DWxAvUFCaUJpQUJpaUFCaUJpQUJpaWFgUXFXVlZXZ2ZmZ3NRcVdWVldnZmZn c1HUUXFgeeXATBgeRNRSTVFyYHrl30sYH0TUVeq1l/VT1UADBlFGtZf1U9VAAwZQUFFQj1MnUi1V m1BaUB8QXl9cT1zVU9VV1VdVUBla6FN3EFpW7VVQX1lPWVJZ6FEBEF1aXLBa+FAgUFFAUVJR7FEI UFtQq1FdUEh7QKYNrbS2QLQNUG+tpr1hYFENUXFnZmZnV1ZWV2NSUa6OYHrkwEwYHkTUUye1l/VT 1UECB1BQUVCtUzZSy1XqUFpQDBBzWlJaU1JYV1lW7VVZUFVRVddaGVBQVn1QVUBVUlX4WlL4UVno UQEQXVpRGVr4UFBAUHBQU1DoUXDjW+/5SHtApg20vUC0QLRApA2kUG+ttA1sQL1BaWlhYFEhUXFX VlZXZ2ZmZ3NRKlFxYHnlwEwYHkTUVeq1l/VT1UADBlBTUGFQ6VRiVL5QU1BXUFtQkRB/UFRQVVJQ VlBXQFZAV29Ub1UfVB9VAFYAVz9UP1VccFFgURBRU1EZUKZgVRBVUlXqUgBQVFNeEFpwWWBZEFlT WRlY6K+QEBVvZVgQamVAWA9YwFiPWFRfWBBY0FiPWFRvWB9YP1gvWMBYVVhwU2BTEFNTUxlQUHBb YFsQW1NbGW9YH1jwWLBYoFhVWFfoU1IQW11VoFRRVLVcHzNIe0CmDWxAtn8NvQ1sQL0NUH8NISJ7 e60Npq0Npr0NYWBRDSFRQXFBUUFxQVFBcUFR9VFJrSNUUa0jUUlThVFJrreuK1FXrqmuOVFJrrdQ r69QXa4BVKdV7FJ2UAxQUFFXUN5QsFBQUHMQWlJRb0xRAExRTFHoUTrlGHtRUlJL6VJmUHlQe1F7 DSFlZVCvr1C7UFBWF1dSUnZQbFBQUVdQ3lHMURZQTuZSUf9FUUVT6FNG5Rh7UVJSROlSZVB5UHtR ew1lZVBSUH1QnlRvVLJQc1B/UIXpUExRWeVLp05Fp0TrUVlQQlBaUVnlWadcU6dS6FFZ5VBD0lvS euhTWhBaQvhc+DBfUV++dOhTWhBfTdJQ+FHSTvhQcVFQcVFx6FLdEFlgRNJM0khOp03rUVlQS1BR UVnlUKdTXKdb61FZUFlQQ1FZ5kKnRfhL+HfqU1pQSFFgEFla0lLSWfhT+H3oU1rjMFZRVuhSnuLU I0h7UG8NvbS0tLStvbSkvb1Avb1Avb1Avb1AtLRRHkCkIQ0dtLS0tL2tDbS0vbS0QL29QL29QL29 QL29YWBDd2dHZmZjYkZHZ0dXRkZFRFZXR1d3VlZzcnZ3V3dndnZlZGZHREZjYmZlZHZzclbh1PbY ZT1oaT5k1vfUTExMTNb32GI9a2g8ZNL60kxNS4YnAwQmJgQEJlP90+LYTUxMTdb51WM9amk9ZNX7 2ExNTEzT+NRkPWlpO/QEJiYEBCYmUFBRUCpQF1NXU4FQVVB7EEpRVVGCUjFTVKpV3VAgUFNAU3BT U1PgV9T5SHtApg29rb1ApL1Qf39hYENRY1FDcypRzKGux9SZUnhR+a4UrmJQUFFQRFAXUt1TgVBV UHoQQVFVVKpV3VNRglLiUBlQU1FT6FFw41YNM0h7QKYNvaS9QK29UH9/YWBRUXNRU2NS3a4rpFEx Lp5RoK4HUe9Rm1BQUa+urvJUnFX2UENQrxAAWVhZXEdSSFhIXEdCd1J/WX9cd0JaUFxDQFVRWVJA VVRYU0BVV1hTX1ZaWVJfVltcQ19WXl1CX1ZBXUJAVVJwWWBZEFnAWVRZcVhYU+JVVVboUg4QAkN/ XG9cH1zPXFRccUJd4kBfUFPiVFLiUUPiUELiQV0xXlwxW1kxWlgxV0FBVVBQVVFRVVRUQFVeXlZb W1ZaWlZXV19WQDFVeF8xQFZwVtBWU1boUTDjRB/5SHtApg20rbRBQml/QWl/QWl/QWl/QUJpf0Fp f0Fpf0Fpf0C0QLRAtEC0QLRAtEC0QLRQb2ykbK0NbKZsQKRsQK0NbF9fX19fX19fYWBRDVFTcVdx U3FDcWdxQ3FncUNxU3FXU2nbUTV/rssXrqEYrt1/USLbrt5+USMYUV4YUTV+UyCtN4+u+lEGj1LJ j1EHrvmPUFBRUMNSbVH8UwZQU1BGEFtRGVBSGVD+VDgjSHtApr1Qf71hYENBcUHDUUlSbVFJrrdQ UFFQRa6SUeNRRVBaUAMQT9pTUVhXWVZWVVJRWlbtVVlV11AZWlpQWUBZUlFZUVnoUQEQQFpRGVr4 cFBgUFJQ/lsWI0h7QKYNtL1AtCENUG+9tGxAvUFCaUJpQUJpaWFgDUNxV1ZWV2dmZmdzwlFxYHnl wEwYH0PUUUW1lvVT1UADBlBSUFeuklPYUUVQWlBFUMUQYkNCREFBQF1cRVhXWVZWVVJRWkHtQERQ QFFA11sZRVpW7VVZUFVRVddQGVpaUERARFJE6FEBEFxFXCBF+FtQWUBZUlnrUQFQWlBbUUcQXVEZ WvhwUGBQUlCmRhbpURNQSHtApg20rbZAtA1AtL1AtA1Qb720DWxAvW+9tA1sQL1BQmlCaUFCaWlB QmlCaUFCaWlhYENxV1ZWV2dmZmdzUXFXVlZXZ2ZmZ3PUUXFgeeXATBgfQ9RSTVFyYHrl30sYH0TU UUW1lvVT1UADBlFFtZb1U9VAAwZQV1Dbr5ZYfFWDUF5QTlByUGFQEVAAUDBRCBAVQk9CcDlTME8w cDBxMHI5djkVIE8gcCBxIHLXT9Jx0nLDT8JwwXHAcsAymU+ZcJlxrzJJXzJPMn8yzzL/Mu8ynzJX cXBw6FKOEEJPckRPT3JPcHFyVDIxcE8Vf23oUo3ieHgM6FKN4xeXHkLoUo3iXJdK6FKN5lVycXFV UWXrUo1Qf1AEUo0QWR4ef1syR0dKGuhSjBBbwAlRQAlwCZAJUwnor5DjX0JkCepR/FABUoziEgB7 6FKMEFvAalFAanBqkGpTauivkONfQmRq6lH8UGJSjOJzsFjoUowQW8BHUUBHcEeQR1NH6K+Q419C ZEfqUfxQX1KM5yBQwFCQUFNQ6K+QEFlITWRQSTE46kh7HkCkeyEdraZ7ISKtpq2meyEiraatpnsh Iq0eFTUUtlBvbB1AvUC9b2xAbEC9rb1Arb1sQL1ApGxRQUJHadd+ey1AlGFgUSENQ2RuUmNiRkVE UlZzcnZnREZjYmdmZmVkdnNyV1ZWQ3NRY1FkblJjYkZFRFJWc3J2Z0RGY2JnZmZlZHZzcldWVlVk blJjYkZFRFJWc3J2Z0RGY2JnZmZlZHZzcldWVttmMyoCI9kz/TI51up0T3RMdG15THJNeGgQllPk na2JZjMqAiLaM/0yOtXpdHB0S3VseE1xTXhpUalmMyoCItoz/TI61el1T3RLdW15TXFNeGlTvBCd wxfC0jmurNDALWh7TXeCEXl9cH2dq+dWXatCEJ3DF8LSOa6s0MAtaHtNd4IReX1wfZ1zEJ3DF8LS OK6r0MAtaHtNd4IReX1wfZ2vr6+5UFBVM1duUnZQdFBQUVdQlVG0UTRQexBMUgBbMFsgW5BbVOBb kFtSIFvQW1JbVK8Ye1JRXOlSZVB5UHtRew0NIWVQr69QBFBQVZVXblJ2UHhQUFFXUJVRk1E0UEvl UfBcUVxR6FIP5Bh7UVFd6VJlUHlQe1F7DWVQr6+vuVBQVS1Xa1J2UHRQUFFXUN1SUlEzUE0QX1Kw W1EAW1FbVK0Ye1JRXulSZVB5UHtReyENZVCvr1AEUFBVlVdSUnZQeFBQUVdQ3lGXURZQSeRRUlJD UehSxOUYd1FSUkLpUmVQeVB7UXtQr69QBFBQVZVXblJ2UHhQUFFXUBNRq1EzUEvlUSBdUV1R6FIZ 5Bh7UVFf6VJlUHlQe1F7DWVQr69QF1BQU8xXa1J2UHxQUFFXUN1QcVEzUE8QQVFPVFEvVN9UUlRR /hh7UVFX6VJlUHlQe1F7DSFlUK+vUBdQUFM5V25SdlB8UFBRV1CVUBdRNFBPEEFR31RRIFTQVFJU UYAYe1FRVelSZVB5UHtRew0hZVCvr1AXUFBTz1dSUnZQfFBQUVdQ3lB0URZQdRBcUlFwW1F/W89b UltR6FFJ5Rh7UVJSWulSZVB5UHtRew0hZWVQr69QF1BQU0BXblJ2UHxQUFFXUBNQOlEzUE8QQVEA VVEgVdBVUlVRnhh7UVFX6VJlUHlQe1F7DSJlUK+vUOOvtlYWV2tSdlBiUFBRV1DdUm5RM1BJEFxS 305RTlZsGHtSUXHpUmVQeVB7UXsNZVCvr1Djr7ZWFlduUnZQYlBQUVdQlVJmUTRQTxBCUk9O0E7A ToBOVE5WAhh7UlFP6VJlUHlQe1F7DWVQr69Q46+2VhZXblJ2UGJQUFFXUBNRoVEzUEkQXFIgT1FP VhIYe1JRcelSZVB5UHtRew1lUK+vUOuvt1ZPV2tSdlBoUFBRV1DdUfFRM1BH41FRS1DoUjPkGHdR UU7pUmVQeVB7UXtQr69Q66+3Vk9XblJ2UGhQUFFXUJVRulE0UE3nUTBL0EtSS1DoUsnkGHtRUUzp UmVQeVB7UXsNZVCvr1Drr7dWT1duUnZQaFBQUVdQE1GfUTNQeBBBUVBMUX9MMEwgTNBMz0xVTFDo UjzkGHtRUU7pUmVQeVB7UXsNIWVQUVACUFBSH1R2UFNQIBBmYFXwVYBVoFVUUFV3UnBVU1hQWFFn UtBV/1VVdVB1UX9VU1FSUnBTUERTU1BTUlpRUFZQU0BR6FIa4lICUOhSGucfU1FT3lRTR+hS6eFg SHt7QKYNtK20e0BsUG9sb2zXVX57LUCUYWBRDQ1RISFRcVNxUWBRT46usVR2q4pQUFFQI1T9U3JV ilBWUDEQFEhQUVdRVlRHUXdRZlG2UFZWUFRURlR1VNtQVUxQTFFKVgZUVFZVUVBSUFFAUVJRIFRT U1UZUONQUkBS8FJTUklX1CVIex5ApA0drb1Qb2y9DVFBQmlBaWFgUSIhDVAiUVdzUXFDc1Jf4LxR eVFcKpZVD+JRfa6DUFBRUO5U7VM+Vf9QRVA/EEAHQTdBJkHcV9BBy1fBQVdZ6FN8EEdAUEA7UFFA UXBRYFHwUeBRkFFXUYNcQ+hTfBBcVV1cFVVTXO1fXVFd6FF1EFtQ7VBRQFFSUUlG/+lR81BIex5A pA0draQNvVBvpGxAvUCtDbZsQK1hYFENUXNmZ2ZjYkdGY2JmZ2NWVnNydnNyVlFsLkt1ZgBk1h5N R3Be0EMhFn2WS058VO0qYRZhTE1hKyUAc1BQUlFkVNZS5lZYUFtQR1DVEFwfWQ9ZP1kvWd9ZVVno UqoQXBBfAF8wXyBf0F9VX+hTQhBcH0UPRT9FL0XfRVVF6FKqEF5TUxBWAFYwViBW0FZVVuhSqhBJ H0IPQj9CL0LfQlVC/hBcAFwwXCBc0FxVXOhSqhBZUFBRUElIhnxIex5ApA0drSGmIb0hUG+tIaYh vSFhYFFkZmNiRkVEVnNydmdERmNiZmVkdnNyVlFkIQAAISEAACE9YXNzYWFzc2FVFwAhIQAAISEA c2Fhc3NiYlBQUVBergdSc6+2UEdQFxBbAElRXF1aX1BSyEboUTfkWshfW0LqUUZQV1EIEEBcUfhQ t11971xRXP5IDSNIe0CmDbSktECmvVBvva29aUFCaWJhYFENQ2dHYmdmZmVkdnNyV2dmY2JGRURX VnNyXmBpBR5hcmVvcGpyGGs+IQgqsm+uCyRRSF95Rk15WTNCMBUEbghQUFFQsFT9U99VilBWUBMQ dVhRSFF4UWhRVEpUeVRSUVJWUFVTUFRAVFJUIFZTUuNQGVVJV8vpUUxQSHseQKQdrb1Qb60NbFFB QmlBaWFgUSENUWdjUXFTY1Gj4Lyuh66kKpZVeOKug1F9UK+vUC6vt1U5V25SdlBmUFBRV1CZUdhR NFBJEFxRP3tRe0IdGHtRUX/pUmVQeVB7UXsNZVCvr1B9r7dUOlWKUnZQBlBQUVdQmVCJUFBQSxBe UQB9z31SfURNGHtRUWHpUmZQeVB7UXsNZVCvr1BjUFBVCFduUnZQbVBQUVdQmVE4UTRQdBBdUVBe UUBeH16gXlNeVOhSduQYe1FRQulSZVB5UHtRew0hZa+vUHJQUFRpVYpSdlANUFBRV1CZUPpQUFBw EFpRL1r/WoBaU1pU6FHo5Bh7UVFe6VJmUHlQe1F7DWVQUlDgrgFR31WDUFNQV1A2EFnAWfBZ4FlT VlnoUvjjWwpmU+1RfVBRUFZRfVBXUl0QR1FQUVBZR0dKUlJTU1dXVhBUVVVQSVhZ7FH7UHFQwlEQ UEh7ex6kbEBsHa1sQGxAbB5AFTUUtkBsUG8drb1AvWFge1ENQ0FjQVNBY0Hgj4+PUu1TRqy6q8RT R6y5UFJQG1BQVZ1V6lBEUHZQ4BBPeFBvdG915FDlRVVUUVBQVXN2RXJyRUVPUFVEUFBVRutSmFBQ UHJSmBBKVXXGUrh0U39Tz1PvU1NTUFVSUFhVUEB1m3ToUrnnU5tSClByHFXqUhRQRVJ0EE6QUIBQ UmBQEFAAUFNQbHdMeFBeQF5SXkp4UEdoYkh7ex5Apg0dvUCmDSG9pL1ApKSttHtAbFBvb0JpDX9s rbZAvUC911V+ey1AlFdsbFdAbGxhYFENY0NzZ2NDcWJHTlRFRFJWV1Zzd2NiZmdmQmVkdnd2c3NT cVdxCdnHdsbaUdb2fgvfJAZ+5L32MJj1yPbFbgopNRll1foGUWl2rpdS0eJS11VZaDXe6T6+rseS eUi8eWgCUV3nzM1KQq474VBSUCyvtlSNVepQT1B8UV4QIHdceHR/fX9+akQAfjlP5lS5TKB+WtVQ 2k5SX0xfTU9MT013U3FVdUN1RGdTYFQAVDdTOk3FUspMyU1AVktMTFVTTk5QTU1UTktQU3ZJVlNR VFlwSXNOS1ZTVFFFVWBMYE1ScExwTVIATABNUkxVVEzoUR0QZ01URE1NVExNTE12VHBVfllVTUVU UVBzd0VWeXddW3Z0UEFAQVJBSX2AcFFwdFBZQFkAWaBZVFnoUpcQWyB+UZB+UX55HUhQ1XsdQA0h pg0dvSIeQKQNHb1Qb71vvW9sQmlpUUFCaUJpQWlpWNd+e1gtQA0NDZRQQUJHaUJpUUFCR2lCR2lX QFhsXmxXQF5sbGFgUA1RIQ1RcUZHZ0dXRkJFQFdWcXJ3dmVkZ2ZjYkdGR3Z3V3dndkNkdnNyUkVE RmNiZmZS4FFfSkmaceMyG9j3roGKJ/za8a0PGGdtcxSic7B65ikOyPknMQrIHlXqdXYbMxPhrrvh rq+UojHavr3+nHFJEvAtBzMAE6ypOyyuu9w5Ki6HUK+vULtQUFYXV2tSdlBsUFBRV1DdUZlRM1BH 41FRXlPoUpPkGHdRUUHpUmVQeVB7UXtQr69QXa4BVKdViFJ2UAxQUFFXUN1Q4FBQUEfjUVFFUOhS HuQYd1FRSOlSZlB5UHtRe1BQUlADUFBVM1XqUENQTlDJEHpWU1ZER1JDU0REaUcZUxlUGUcIVMRS 6FlcVE5EQ1BTU1BQT1FSRFFRUk7oUpjnH1TfVMBUU1TqUYVQQ1KYEHBFUEVARRBF70VURVNQU1JS UVBYUUdJeFBbQFtSW0pwUOhSCedRSU9RR2hiSHt7HkCkHb0eQKYNHb17UG9sb2xBQmkNf72kDb3X VX57LUCU15RsbGxhYFENcXFRcVNxYkdOUkVEXlJXVnNzZ2NiZmZlZHZ2c3NR0a6CUWhRfWtRcdVn GiUaBi7BKxWSkmQMv/AMYh3IhlXqrrhaXgnyMTmDLxFBWaJt1R9hGktQUq+9rjtUglXqUF9QTVDt EDphUmhdYUsWUvhcVWVSCFAJUgBPOF/ZXtpfyF9Yel1oXzpdU0BPUV1SQF5eUVJHQFJUSlBfX3Be UUReXlFReFBQSnpUV0N3W1tfeF5eR3QPV1FAV39Xb1cvV99XVQBXUVeMT0BRD0D/QFJA6FE7EFpe TnhRQF5HXk5a6FHp4R1Ie3tAbHt7bHtAkFGkDSGkDSEivVBve2xQb71vvW97bNdVfnstQJRQQUJp UUFCaddAXpSUbGFgUSINDVANUXFTZmNiRkVAV1ZzcndTcVFERmNiZmZlZHZzclZWUStRTzbBy/eb /8WegzwlrrFRsSkCF9QHIgcD1htV6q5FILazrrCW+futiVMKLNk2oDYnLySzUFBRUD1Qu1RtVOtQ W1CkEEddXVFSWVBVV1NYW1ZUU1hQVVpSWVtWVetTcFBZUFZTcONYW1ZT61NwUFtQUlNwEFlQWVJV UFBHGFDoUgAQXFtWRFtbVlNYWEcYWOhSABBZWVJEWVlSUBVY6FK041lVFVPoUrTiVhVS6FF9EFlb FW9ZP1lSWVARXlNwUFJRfVBVU3BQWVK0UFhTcFBWUX1QcFBTU3AQWlBbcFvQW/BbVFvpU1NQXElA pg1ItkpJrUikSaRItkmtSKRQfw20Sa1ItkmtSLRJQK1IptdefnteJ6UtQJTXXn5Ie14npS1AlEhR WECwQLBYQLBAsF9fX19RFi06GENRUWdRUUdRUVdRUT9Rfq6A6lFgUX7lroJRYequn66CUfRRflF/ 6q6BUX7mroKun+pRYa6CUFBRULtSh1K1VZ5QWlAlEEFLWVFQVkVWRld2V3ZYVVZXV+hR8xBbWFlE WFhZVVZXWVDsUsxQUVL4UFhSu+NWVVFW61ELUFdQWVEB5VhRx1CmV+hR8+NAWFFY6FEy41vLI0h7 QKYNvaa0QLRAtFBvbL2kvWlRQUJp1357LUCUYWBRDVANQ2dmZ2ZnY1NzQ1a7dytkNhQq7JQrJlQl y2BLZm2tWVG8aFBQUVD4UodTe1WcUEpQkRAStUFRQEEAQVJUQVFmWWdaFlkWWgZZBFoPXQ9eNlU1 WjBdMF46QyhD1lXeQt5D0kr1WfVa51nlWuZBR1FQVEFeX11c6lK8UF9Su+NvUFFQ6lIAUEhRQ+JU UVzoUkcQRW9fH18PX99fVF/SUV59AF1RXfhXUOhRR+VROo9FUUXoUUgQRFBXYFdSUFdAV3BX0FdU V0pMwiVIex5Apg0NHb0hrb1ApA20QKQNvVBvvb0Nra1sQGxjQUJpYWBRDVAhIg1Rd2ZmY2JGRURW V1ZXcVdxZmZnZmZlZHZzclZR5e1GxSnU2wz5SmRRTHeti10L/NR/enV3ZFSaRyMoKgdu3CpCYM4H Lto4FkhNeGJQUVDMUptTTlWcUGBQgBB5cFFRb1pvXG9dh0u5TVV2d3FCdndfWlBRVEpGXV9cWi9J UUkYRrBfUV/oUUMQWlqfWlFaTn5R+1TsUUNQflK7UEZRQxBcTlF2d3dKSV1TRl9Q6FFHEFpQUYBR UlEAXH1d6FEf5FfQSVFJ6FFH5eBKUUo6QuhRSOJx+FfoUUgQX1B7QHtwe7B7VHvdYsIlSHtArQ29 pL2tDb0NQKSkpiG9UEFCR2lCaWlvva2ttEFCaQ1/vQ1AtA1BY0FjQWlBQmlBQmlpUUFCaWlhYFEN UA1DZ0ZGY2JmZWR2c3JXZ0ZjYmZlZHd2c3JWV3dmZ2ZjYkZFRFZXVldXRkdGRURWc3J2zOpafXpo EWNgQU12QlxubEFGdHNjQeRyfwXSKtV2TnlXUVRPeOPbKt9T4EJtemx6dX5VxlJleExfQ3xpTg16 HiYCex1DSVZXVkx1GAvOJlBTUP6vk1b/VZxQW1BfUHpRChAPUFZDVkZXRVlEXERdQF5AX9py9Un1 Sls1SjBNME49c1R1VnVYBEkGSjZFVVVQS1olc9lQxnH1ceZxVzlQKVAlcpVxtXFVb0BvQR9KGXJU RXEAcVJFcWRxxXH1cVRWV1foUfMQSFhZRFhYWVFQVVhZUVBBQERVVldBTk9NTO5SvFBPUrtQQFIA UHhRQxBbT0RRRFxdXV9eUFDsUsxQUVL4UFhSu+NWVVFf71K9UF5Sf1BdUr1QXFBMUkcQQm9PH08P T99PVE/SQU59TfhHQOhRR+JBOnXoUUgQWVBHQEdSR0p8VutRC1BXUFlRAeVYUcdQplfoUfPjQFhR WOhRMuN7yzdIe0CmDb2mtEC0QLQeQKYNHb2tvUCktECkDb1Jf0i9pr1Qb2y9pL1vbG9sfw29va2t bEBsY1FBQmlQQUJpQUJpQUJpaddVfnstQJRhYFAhIg0NDVENDQ1DZ2ZnZmdjU3NDV1ZTc1FjUXdm ZmNiRkVEVldWV3FXcWZmZ2ZmZWR2c3JWu3dWWZnRK+2UK0QyXv5Vbv6uz+5HxCrU2w34SmRRTHet i1wM/NNge3R3ZFQjy1NTFiKtWlG7WX+ralZZq61HIygqB27cKkN/zgYv2TkWSE13YVBQVFCcr5NW 6FWcUFpQXlBJUExR2BAGSFZKWUlBSUxUUlZDVkVZRltAXUBedld2WKZfpkSmR6ZKXFVfVURVR1VK SUp1X3VEdUdYSktJTEVHQ0hARkRDSExFX0tJQEZLTEtJTJ9BQkRBQUJDSEjoUfMQWUlLRElJS1ZX V+hR8xBOWFlEWFhZRkhFQUxAVVZXWVBRQRVFTLZGQEBJS4JC6FJrEFpISVxbXF1eXVBQ7FLMUFFS +FBYUrvjVlVRXuxSvVBdUn9QXFK9EEagW1Fb/0BRD0DPQI9AU39Ab0AfQFNA6FEL4kwkSOhR8+NJ QsFD6FEL53BLgEuwS1NL6FJqEF5QSUBJwEnwSYBJoElWSehSJuNFSk5W61ELUFdQWVEB5VhRx1Cm V+hR8+VAWKBYUljoUTLjTcs3SHtApg29prRAtEC0HkCmHa0NrQ2tvUC9pr0NDQ1Jfw1Ivaa9UG9s vaS9b2xvbG9srbVCaX9srWy0QUJpUUFCaUFCaUFCadd+ey1AlNd+SHstQJTXfkh7WC1AlF9fX19h YFEhDVANQ2dmZ2ZnY1NzQ1ZDc1FjUXFnUWNTY1dzV3NDZ1e7dytkNhQq7JQrJkD+VW7+rvmu8HNR ivciOXU5df0bbLNUI8tgS2dsrVpRu2iralZZqs7dUYGuftzEUXCzs1BQVFDLr5NWgFWcUGBQZFBv UBJR4RAQSWdJEnFRpGdUh0uGTIhNuU2pZ1VWZVdqVm1XEFQQEW8Sa21pbmZsamluEmtlEW9mbBES EW8Sn2doRGdnaGlubuhR8xBzbxFEb28RdndxQnZ3X1pQUVRKSUZsbmtnZmfFaxK2bGZmbxHqUQtQ aFJrEERub1xhYl1kY1BdX1xaL0lRSRhGX+hRQxBaWp9aUVpOflH7VOxRQ1B+UrtQRlFD4k5RZOxS vVBjUm1QYlK9EENh/2ZRD2bPZo9mU39mb2YfZlNm6FEL4hIkbu1R81BvUGhR81BpUQsQW1ARUXAR gBGwEVMR6FJqEFxQb8Bv8G+Ab6BvVW/oUibja0oUUOhRR+dQUVFRAFx9XehRH+RX0ElRSehRR+Xg SlFKOkLoUUjicfhX6FFI5UB7oHtSe+hS6uMTAR1Ie0CkDb2kva0NvQ1ApKSmIb0eQKYdrQ2tDSGt vUC9pr0NDQ1Jf0i9pr1Qb72trbRBQmkNf71AtA1BY0Fjb2xvbG9srbVCaX9srWy0UUJpQUJpUEFC aUFCaUFCaWlRQUJpadd+ey1AlNd+SHtYLUCUX19fX2FgUSENUA1DZ0ZGY2JmZWR2c3JXZ0ZjYmZl ZHd2c3JWV3dmZ2ZjYkZFRFZXVldXRkdGRURWc3J2Q3NRY1FxZ1FjU2NXc1dzQ2dXy+pafXpoEWNg QU12QlxubEFGdHNjQeRyfwXSKtV2TnlXUVRPeOPbKt+2/lVu/q7BrvBzUYr2ITh1OXX8Gm2zU+BC bXpsenV+VcZSZXhMX0N8aU4Neh4mAnsdQ0lWV1ZMdRgLzias0lZZqs7dUYGuftzEUXCzs1BRr71W QFQtVpdQU1BK41FzUFLqUidQUFI341QvYkh7QKW9UH+9YWBTZXFFQ1TAVkDn51BQUVBnr7ZVTVWD UHZQ3RBNUHVRUVNwQ3BcQWRDRUJCSkBWcFdPS1xKW0tLQFPoUpvidVNA6FKbEHVFWVpYVVNdXFtX VltbXVZWXVBRQ0J4WXFRTE5xU11wS09KXXhJf72NbGlpQkdpDUCGYpZiQWl/Qml/QJ1AnUJHaVBv vW+9QWl/bI1sQIZsjWxBQml/Qml7UEFCaUh/QmlhYFFTdnNwU3FXcVZXcVdxRkZjYmdTVnNwd3Z3 c2djZmdzZ2NmZ2ZxYlVNPhzwrqTQUaJOraxYXVJQTq5IV/km4dQS09SupsPYRtxOIVRbzk7zH5Pt UVKaVSauoTiuvMpwNMsm+TSugGHL3qPLYATKvsfDUFBQUlBQr6RQUK93UIdQUFBQUFBQUFBQUFBQ UFBQUFBQUFCOUFBRUlFTUFNQVFBVUFZQV1BYUFlQWlBbUFxQXVBeUF9QQFBBUEJQQ1BEUEVQRlBH UEhQSVBKUEtQTFBNUE5QT1BwUHFQclBzUHRQdVB2UHdQeFB5UHpQe1B8UH1QflB/UGBQYVBiUGNQ ZFBlUGZQZ1BoUGlQalBrUGxQbVBuUG9QEFARUBJQE1AUUBVQFlAXUBhQGVAaUBtQHFAdUB5QH1AA UAFQAlADUARQBVAGUAdQCFAJUApQC1AMUA1QDlAPUDBQMVAyUDNQNFA1UDZQN1A4UDlQOlA7UDxQ PVA+UD9QIFAhUCJQI1AkUCVQJlAnUChQKVAqUCtQLFAtUC5QL1DQUNFQ0lDTUNRQ1VDWUNdQ2FDZ UNpQ21DcUN1Q3lDAUMFQw1DGUVRQzVDOUPBQ8VDyUPNQ9FD2UPlQ+lD7UP1Q/lD/UOBQ4VDiUONQ 5FDlUOZQ51DoUOpQ61DtUO5Q71CSUJNQlFCVUJZQl1CYUJlQmlCbUJxQnVCeUJ9QgFCBUINQhFCF UIZQh1CIUIlQjVCOULFQtFC1ULZQt1C4ULlQulC7ULxQvVC+UKBQoVCiUKNQpFClUKZQilFVVX4+ JTw8QD4/Pj0xIjs5PjciNSQlIj5TPSVhVyU+OWJgERNQUFBQUFBRUFBSMFBRUDNR0FBWUIJQU1B0 r+RQU1Bsr4tQRFBErzhQdFBTr+RQdFBnrzhQdFBprzhQdFBqr99QdFBsrzhQdFD5r99QeVBfr01Q eVBBr01QeVB0r99Qf1BTr4tQf1BnrzhQf1Bpr99Qf1Bqr99Qf1BsrzhQf1D5rzhQY1BTr+RQY1Bf rqhQY1BBrqhQY1B0rzhQZVBnr4tQZVBqr4tQZVBsr4tQZ1BfrzhQZ1BAr99QZ1BBrzhQZ1BNrzhQ Z1BOrzhQZ1B0rzhQZ1Bir4tQZ1AUr+RQZ1AWr+RQZ1AYr+RQZ1Acr4tQZ1ACr+RQZ1AFr4tQZ1AG r+RQZ1AIr4tQZ1AKr+RQZ1AMr+RQaVBfrxRQaVBAr+RQaVBBrxRQaVBNr+RQaVBOr+RQaVB0rzhQ aVAUr+RQaVAYr+RQaVAcr+RQaVACr+RQaVAFr4tQaVAIr4tQaVAMr4tQalBfrzhQalBAr+RQalBB rzhQalBNr+RQalBOr+RQalB0r99QalAUr4tQalAYr4tQalAcr75QalACr4tQalAFr4tQalAIr4tQ alAMr4tQbFBTr4tQbFBfrxRQbFBArzhQbFBBrxRQbFBNr99QbFBOr99QbFB0rzhQbFAUr+RQbFAY r+RQbFAcr+RQbFACr+RQbFADr+RQbFAEr+RQbFAIr+RQbFAJr+RQGVAZr4tQGVD5UHVQBVBfr99Q BVBBr99QBVD5UBxQCVBfr99QCVBBr99QClBfr+RQClBBr+RQDFBfr+RQDFBBr+RQ+FD4r+RQ+VBT r+RQ+VAGr4tQ+VAHUHVQ+VD5r+RQUFBSUFFQUFBQUERQU1BRUFBRTFBQUVZQUFFQUFBQUFBQUVJQ UFBSUFBQUFBQUFBQUFBQUFBQUVBQU1RVVldYWVpbXF1eX0BBQkNERUZHSElKS0xNTk9wcXJzdHV2 d3h5ent8fX5/YGFiY2RlZmdoaWprbG1ubxAREhMUFRYXGBkaGxwdHh8AAQIDBAUGBwgJCgsMDQ4P MDFQMjM0NTY3ODk6Ozw9Pj8gISIjJCUmJygpKissLS4v0NHS09TV1tfY2drb3N3eUN/AUMFQUMLD UFBQUFDExVDGx8jJylDLUFDMzc5Tz/Dx8vP09fb3+Pn6UPv8UP3+/1BQ4OHi4+Tl5ufo6err7O3u 71CQkZKTlJWWUFBQl5hQUJlQUFBUUdJQUFB4UHBQVFBYUC5Qr1EDUTFRKFEuUcJSllKMcERwSnBO cHJwdnBgcGpw/HFyckmvr1BQUHBQ8FECUTBRKFEtUcJSllKMcENwSHBMcHBwdnBgcGlw/HFyckmv r6+zUFCvAK86r2SvH69Zra+turDBUFBQUFBQsCiw1LAlsGGPOo7IUFFQUFB2UFBQUFBQUFBQUFBQ UFBQUFCEUIhQjFBQUFBQUFBQUFBQUFBQUFNQyVDUUNVQ/VDCUJ5Q1lDeUNtQxFDMUMpQQFDaUIxQ 01DBUIdQiFDdUMNQ2FDhUJhQhlDFUM1QilCJUItQyFDPUOdQ5VDwUDJQM1DfUDRQ6VA1UOZQ6FDt UOpQ61DsUJ9QNlCQUO5Q71DxUDdQhVDAUJNQkVCSUDhQgVCDUNlQOlA5UDtQPVA8UD5QxlA/UCFQ IFAiUCNQJVAkUCZQJ1CAUChQKlApUCtQLVAsUPpQx1AvUC5Q0FDRUIJQhFD7UPhQ+VDiUPZQ91Dj UNJQ4FDXUFBQUFBRUFFQUVBQUFFQUEREUFBQRFBQUFBQUERcYNJEWFZZetYY1qddUVdS8NJDqWDS Q6VSUVFhXmBcVlh61hjWp11SVVVQYDFWWntWUVRR0mdSUVTwA2ABYHxWWntWUVRR0mdSUUzyTtBM UGxQbFBsUB9QMlAjUD9QPFA1UCRQNVBuUG5QbmBxYFlWVXteU1JKVVBURFaOYPsQy5+DZxlrZLpj S8yn02Cy8NJfgmDSUpBg0lJ5UkRD2eSB2rj3lO1ll8vd2JpPmgMGwWBdVll61hjWp11RUVRVUGDR zmFPYE1WUwVUWkNGBjUiOQM5Nz5wBCIlIyRwHjUkJz8iO2FHYEVWUwVUW0NeBjUiOQM5Nz58cBk+ M35hfGB6VlMFVFtDcwY1IjkDOTc+cAQ5PTVwAyQxPSA5PjdwAzUiJjkzNXACPz8kYWRgYlZTBVRb Q3seH3AcGRESGRwZBAlwERMTFQAEFRR8cHgzeWlncAY1IjkDOTc+fHAZPjN+YE5HXWlnYGVhYmBn YGBgYApHXWlpYWJjYWBnYGBgYApg0c5hT2BNVlMFVFpDRgY1IjkDOTc+cAQiJSMkcB41JCc/Ijth R2BFVlMFVFtDXgY1IjkDOTc+fHAZPjN+YXxgelZTBVRbQ3MGNSI5Azk3PnAEOT01cAMkMT0gOT43 cAM1IiY5MzVwAj8/JGFkYGJWUwVUW0N7Hh9wHBkREhkcGQQJcBETExUABBUUfHB4M3lpZ3AGNSI5 Azk3PnxwGT4zfmDRz2BdVll61hjWp11RUVFVUFPR3VBg0dlS0dFQg35woDgsfH1+0UzhVuL3W+dB XQeKA4gls5ljeuKEplkLZKO5wK5ZXICLSwrpnbem2OHNkNd1uy0IQCM6KJshRa2WCKZ5+wgOxlSt fTJBCNFMmiHEhXIIf4WcRFXUZurE+uQdGrm+a3L9Bskuccw81pAaF8c65PZmhaxZfYPkactSU1FQ UWBdVll61hjWp11RUVRVUFPR0VBqQczVVW6CudCrK4X5pPwprFWsxW0hc/l7eI/cQzXZrnzXUd8K yjKaQffQpOfuROeBBsk7WDIVlvL1imUvVXKOIn1U1lX3LFlGw0QToKdGHYZX3stAPAiuWmXHmtnP j1QgzHotMd6RuFshyviXNjISbcXEcmLIctnaqjRYdKWCqmDSUp1g0lJmUkVQ7UHKihO9casWCNTZ mhbYwHW+RDBgXVZZetYY1qddUVFUVVBg0c5hT2BNVlMFVFpDRgY1IjkDOTc+cAQiJSMkcB41JCc/ IjthR2BFVlMFVFtDXgY1IjkDOTc+fHAZPjN+YXxgelZTBVRbQ3MGNSI5Azk3PnAEOT01cAMkMT0g OT43cAM1IiY5MzVwAj8/JGFkYGJWUwVUW0N7Hh9wHBkREhkcGQQJcBETExUABBUUfHB4M3lpZ3AG NSI5Azk3PnxwGT4zfmBOR11pZ2BlYWJgZ2BgYGAKR11paWFiY2FgZ2BgYGAKYNH8YXdgdVZTBVRb Q04GNSI5Azk3PnAEOT01cAMkMT0gOT43cAM1IiY5MzVhT2BNVlMFVFtDRgY1IjkDOTc+cAQiJSMk cB41JCc/IjthZGBiVlMFVFtDex4fcBwZERIZHBkECXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58 cBk+M35hR2BFVlMFVFpDXgY1IjkDOTc+fHAZPjN+YUFgX1ZTBVRXQ1gZPiQ1Ij41JGDRzWBdVll6 1hjWp11RUVFVUFPR21Bg0ddS0dFQ+zG95P3dwBfAjORBDjmMWi8ywFZhnZ6v2MEWhxlqxLmEVm/N /fIoCryprDMVH+hbPmC/8mb7fVmPoT93+10BMFVlHy+eBB+A53wSiFuA3egOr+bQgLPG5C9yGRJA PIPI4FEG85Offs9qpC/4CPaHcjW13PsozOyJFxI4C30treVSUVNgXVZZetYY1qddUVFUVVBT0dFQ PTCryQ/0OeODKyB7MnNOFHAB/3NFlyRSqRmid0oM/NYhZVh7pt+OsOXGuNv3G7MjmBhZzeCK24pF wppTtVl1Bla3HvQX9YEHFoRoBqVxnZN2a311Yp7Lsu8QF7qIPRcmtZBg81/Qni+Iay7wqcV6YXtF qphEvY3guQURIBZ9fC5g0lppYNJZ8vBTUlFSUkAebtQ+B7DAgInbHJxy0wkdYF1WWXrWGNanXVFR UlVQYDFhQWBfVlMFVFdDWBk+JDUiPjUkYUdgRVZTBVRaQ14GNSI5Azk3PnxwGT4zfmFjYGFWUwVU W0N6BjUiOQM5Nz5wEz89PTUiMzkxPHADPzYkJzEiNXAAJTI8OSM4NSIjcBMRYE5HXWlnYGZgZGBg YGBgYApHXWloYGZgZGJjZWllaQpg0lEVYUFgX1ZTBVRXQ1gZPiQ1Ij41JGFHYEVWUwVUWkNeBjUi OQM5Nz58cBk+M35hY2BhVlMFVFtDegY1IjkDOTc+cBM/PT01IjM5MTxwAz82JCcxIjVwACUyPDkj ODUiI3ATEWEWYBRWUwVUW0NtJycnfiY1IjkjOTc+fjM/PX8iNSA/IzkkPyIpfxMAA3AZPjM/IiB+ cDIpcAI1Nn58HBkREn4cBBR4M3lpZmFrYGlWUwVUW0NiFDk3OSQxPHAZFHATPDEjI3BjcH1wHTkz Ij8jPzYkcAM/NiQnMSI1cAYxPDk0MSQ5Pz5hW2BZVlMFVFZDUgUDYUFgX1ZTBVRYQ1gZPDw5Pj85 I2FKYEhWUwVUV0NBFTw7cBciPyY1cAY5PDwxNzVhcWBPVlMFVFNESB0/Pj8kKSA1cAQpID83IjEg OCl8cBk+M2AMYF1WWXrWGNanXVFRUVVQUxtQYBhSEVDydQ4QA6OnI22oFjfIS4YImrcY/5OInGLn Zs2U4KUp8q420uQ0a/t9XVvxmS6EE5muUMD9ErOCCET8qXiYgT81UlNRUFHz0lceYNJXGmBZVlMF TUNUUmBQYFtWUwVNX1RUU1JV8GDR2FZTBU1RVNHQYC7QQCvGtIETrTjIo2icPmuiW9LxM2AxYUFg X1ZTBVRXQ1gZPiQ1Ij41JGFHYEVWUwVUWkNeBjUiOQM5Nz58cBk+M35hY2BhVlMFVFtDegY1IjkD OTc+cBM/PT01IjM5MTxwAz82JCcxIjVwACUyPDkjODUiI3ATEdJVUuRQUFFgcVZTBU1UUVGvVEdg RGBeYFxWWntWUVRR0mdSUUZTUlfQUGBdVlMFTVpUVmBUU1JWEGDSVGZWWntWUVRR0mdSUVpRUa9U 0lRzYNJUT/B50Hc4JCQgI2p/fycnJ34mNSI5Izk3Pn4zPz1/IjUgPyM5JD8iKX8TAAPx0lPo0dJT 5AQ4OSNwMzUiJDk2OTMxJDVwOT4zPyIgPyIxJDUjcDIpcCI1NjUiNT4zNXxwMT40cDkkI3AlIzVw OSNwIyQiOTMkPClaIyUyOjUzJHAkP3xwJDg1cAY1IjkDOTc+cBM1IiQ5NjkzMSQ5Pz5wACIxMyQ5 MzVwAyQxJDU9NT4kcHgTAAN5WiY1IiM5Pz5wYX5gfHAxJjE5PDEyPDVwOT5wJDg1cAY1IjkDOTc+ cCI1ID8jOSQ/IilwMSRqWjgkJCAjan9/JycnfiY1IjkjOTc+fjM/PWtwMilwFX09MTk8cDEkcBMA A30iNSElNSMkIxAmNSI5Izk3Pn4zPz1rcD8iWjIpcD0xOTxwMSRwBjUiOQM5Nz58cBk+M358cGJl aWNwEz8xIyRwESY1fnxwHT8lPiQxOT5wBjk1J3xwExFwaWRgZGNaBQMRcBM/ICkiOTc4JHB4M3lh aWlmcAY1IjkDOTc+fHAZPjN+cHARPDxwAjk3OCQjcAI1IzUiJjU0fnATFQIEERkeWgcRAgIRHgQZ FQNwFBkDExwRGR0VFHARHhRwHBkREhkcGQQJcBwZHRkEFRR+WloHEQIeGR4XanAEGBVwBQMVcB8W cAQYGQNwExUCBBkWGRMRBBVwGQNwAwQCGRMEHAlwAwUSGhUTBHAEH3AEGBVaBhUCGQMZFx5wExUC BBkWGRMRBBkfHnAAAhETBBkTFXADBBEEFR0VHgR+cHAEGBVwGQMDBRkeF3ARBQQYHwIZBAlaFBkD ExwRGR0DcBMVAgQRGR5wGR0AHBkVFHARHhRwFQgAAhUDA3AHEQICER4EGRUDfHAZHhMcBRQZHhdw BxECAhEeBBkVA1ofFnAdFQITGBEeBBESGRwZBAlwHwJwFhkEHhUDA3AWHwJwEXAAEQIEGRMFHBEC cAAFAgAfAxV8cBEeFHAHGRwccB4fBFoSFXAcGRESHBVwFh8CcBMfHgMVAQUVHgQZERx8cAAFHhkE GQYVfHARHhRwExUCBBEZHnAfBBgVAnAUER0RFxUDfnADFRVaBBgVcBMAA3AWHwJwFBUEERkcA35a WhM/PiQ1PiQjcD82cCQ4NXAGNSI5Azk3PnAiNTc5IyQ1IjU0cD4/PiY1Ijk2OTU0AyUyOjUzJBEk JCI5MiUkNSNaNSgkNT4jOT8+cCYxPCU1cCM4MTw8cD4/JHAyNXAzPz4jOTQ1IjU0cDEjcDEzMyUi MSQ1cDk+Nj8iPTEkOT8+WiYxPDk0MSQ1NHAyKXAkODVwGRF+WvNm0GQ4JCQgI2p/fycnJ34mNSI5 Izk3Pn4zPz1/IjUgPyM5JD8iKX8mNSI5Izk3Pjw/Nz9+Nzk2YNJST1ZTBU1TVNJSRmDSUkJg0lJe YNJSWlZbMNYYUdaoFVFXUVFg0lGpRtJR9wQ4OSNwMzUiJDk2OTMxJDVwOT4zPyIgPyIxJDUjcDIp cCI1NjUiNT4zNXxwMT40cDkkI3AlIzVwOSNwIyQiOTMkPClwIyUyOjUzJHAkP3xwJDg1cAY1IjkD OTc+cBM1IiQ5NjkzMSQ5Pz5wACIxMyQ5MzVwAyQxJDU9NT4kcHgTAAN5fHAxJjE5PDEyPDVwMSRq cDgkJCAjan9/JycnfiY1IjkjOTc+fjM/PX8TAANrcDIpcBV9PTE5PHAxJHATAAN9IjUhJTUjJCMQ JjUiOSM5Nz5+Mz89a3A/InAyKXA9MTk8cDEkcAY1IjkDOTc+fHAZPjN+fHBiZWljcBM/MSMkcBEm NX58cB0/JT4kMTk+cAY5NSd8cBMRcGlkYGRjcAUDEXAENTx+cHthcHhkYWV5cGlmYX1oaGNgcBM/ ICkiOTc4JHB4M3lwYWlpZnAGNSI5Azk3PnxwGT4zfnBwETw8cAI5NzgkI3ACNSM1IiY1NH5wExUC BBEZHnAHEQICER4EGRUDcBQZAxMcERkdFRRwMT40cBwZERIZHBkECXAcGR0ZBBUUfvBeVlww1hhR 1qgVUVdRUVHxXlZcMNYYUdaoFVFXUVFSYHxgekZ4OCQkICNqf38nJyd+JjUiOSM5Nz5+Mz89fyI1 ID8jOSQ/Iil/EwADcGBGVlp7VlFUUdJnUlFLVFhgVlFRr1FRr2BdVll61hjWp11RUVJVUFPR0VDQ pQ43yh22CU5em+uMniWtZrf2x7AuFyjMVVP0w0ZyR+yHl8mzFKp1qftSD12GPqyEiJaOXiizvyly gUak03iYuBatKmxu47jpfoW0i70Sy6Wog+e0LYj4vzN81cBVnkIVaYcy2lZOrS2VGK0KO4ATDH+e wSxqvgp9ZCHxgMh00mHSU/Vg0lPxUlFRYCVgMWFBYF9WUwVUV0NYGT4kNSI+NSRhR2BFVlMFVFpD XgY1IjkDOTc+fHAZPjN+YWNgYVZTBVRbQ3oGNSI5Azk3PnATPz09NSIzOTE8cAM/NiQnMSI1cAAl Mjw5Izg1IiNwExFSQB5u1D4HsMCAidscnHLTCR1gXFZYetYY1qddUlVVUPDRoWBJVll61hjWp11R WVNhXFZae1ZRVFHSZ1JRVGBMVlp7VlFUUdJnUlFbYV5gXFZae1ZRVFHSZ1JRRmBPVll61hjWp11R WVRhQlRAeex0XJV2bjPytUTxc39YG2DRxFZae1ZRVFHSZ1JRXGHR1WDR0vA00DJQEVAiUDlQMVA8 UHBQElA/UDxQNFBwUBlQJFAxUDxQOVAzUHBQH1AgUDVQPlAEUClQIFA1UHBQNlA/UD5QJFBwUAdQ OVA+UHBQEVAeUANQGVBwUDNQOFAxUCJQcFAjUDVQJPFK0Eg4JCQgan9/Jycnfj0/Pj8kKSA1fjM/ PXBgXVZZetYY1qddUVFRVVBUEBESQYZGuC6SMLd1Em71rMMooeP8QZKL0/iD4bBdhQC5raao3BXk TWr2oVigsDZWjBtVtCV+oKDr+03Gap7lPSXx0lGAYNJRnFZZetYY1qddUVlWYdJR7WDSUelSUVFg 0ehg0c5hT2BNVlMFVFpDRgY1IjkDOTc+cAQiJSMkcB41JCc/IjthR2BFVlMFVFtDXgY1IjkDOTc+ fHAZPjN+YXxgelZTBVRbQ3MGNSI5Azk3PnAEOT01cAMkMT0gOT43cAM1IiY5MzVwAj8/JGFkYGJW UwVUW0N7Hh9wHBkREhkcGQQJcBETExUABBUUfHB4M3lpZ3AGNSI5Azk3PnxwGT4zflJFUO1ByooT vXGrFgjU2ZoW2MB1vkQwYFxWWHrWGNanXVJVVVDwCWBIVll61hjWp11RWVNhW1ZZetYY1qddUVdR YExWWXrWGNanXVFZVWFfR11pZ2BoYmZiY2FlZWUKYE9WWXrWGNanXVFZVGFCVEAC6JijqknrhVCc Irbfr1EJYF1WWXrWGNanXVFRUVVQVNHQZiKjohvjWc9Z5h+YtTLHrXRvwgMcKxZNKn7cnu0phBEV 0678KOySQbV8QoFZEb3ABlT1gnpdbCvxj7opuoJH8G2GDAM7CLHCpz+1rxOpmjGu+jHkrfHCscwU 6EvYS2DjdKDV4VTGJpDEsb/DVeYtmj7TFfKRN77NybDAhEtCmAgQALcPRAAAAFQAaQBtAGUAcwAg AE4AZQB3ACAAUgBvAG0AYQBuAAAAOLZiADi2YgBgtGIAt/ECMIS0YgAIAAAAhLRiAMnyAjAAAAQS AAC4DyZqAQAmagEAXGkBAAEAAgAAAAAQAgIGAwUEBQIDBAAAkAEAAAAATFADAAAAAAAAAAAAAAAA AAAAAQAAAAAAAADZ0s8hAAAAAAAAAAAAAAAAAAAAAAAAIABUAGkAbQBlAHMAIABOAGUAdwAgAFIA bwBtAGEAbgAAAAAAEABSAGUAZwB1AGwAYQByAAAAAAAYAFYAZQByAHMAaQBvAG4AIAAyAC4ANAA1 AAAAHgBUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAAAAUFFQUFBDUVBQVFBgFAMZFx1i hrNQUQUcUFBEQBwEAxiq4ZCFUFBDBFBQULMfA39iw7bAXVBQUehQUFAGBhQdCB5zONJQUERoUFBB xDM9MSB9+7FSUFEC/FBQUvAzJiRwnO/LU1BQZ8BQUFaCNiA3PWcl939QUGJMUFBVIzcxIyBQSFBZ UFBSQFBQUEA3PCk2yLu/N1BQBxhQUKbKODQ9KDQbz6RQUBGwUFBFODg1MTSR/touUFBRbFBQUGY4 ODUxXqBWBVBQUSRQUFB0OD0kKM0JZkJQUG40UFBTLDs1Ij6u1KsrUFEfpFBQUug8PzMxUCcoUlBQ X4RQUFPQPTEoIFW5XZ9QUFHIUFBQcD4xPTVzTloMUFBScFBQXeMgPyMkkBVXOVBRHbRQUFJdICI1 ILQTNeRQUHWcUFBcAFBRUFBQUtBQcZ+CiQ9fbKVYSVhQUFBQUPKzTZJQUFBQ4HjyIq8zrhZYQldV UFBQWVBRUFFQUFBQUFFQUFdxrhVQB1hQrzOvYFhCUFFQUFBQUFBQUFBQUFBQUFCPUFFQUFCPUV5Q eVAIUFRQUlBAUEZQEVBQVNlcAFBSUFFQUVNlUcBQVVBQVcpVY1BQUXVVylVjUFBT8FA2UkJRVVJS VlNVVFVSU1RQUFBTUFBQUFBQUFBQUFBQHT8+P1AQUHBySVXcrhZRY1dxUetQUFBRUFBQUFBQUFBQ U1BYUFJQQVBRr69QU1BQUH1SclBRUFBQUFBQUC9QUFBRUFBQUFBRUF9QL1BRUFBQUFBSUFdRVFBR UFBQUFBTUGlQu1BRUFBQUFBUUF9QL1BRUFBQUFBVUFxRXFBRUFBQUFBWUEFRdFBRUFBQUFBXUDxQ L1BTUFFUU1BSUFxRZVBTUFFUVVBSUEBRFVBTUFFUVlBSUFxRBVBTUFFUV1BSUEBRMVBTUFFUWFBS UEBRIVBTUFFUWVBQUK5R0VBTUFFUWVBRUE5SL1BTUFFUWVBSUF5T2VBTUFFUWVBTUCJTB1BTUFFU WVBUUE5SL1BTUFFUWVBVUEhTyVBTUFFUWVBWUHJTmVBTUFFUWVBXUIhSL1BTUFFUWVBYUHZTu1BT UFFUWVBZUNZUQVBTUFFUWVBaVQZUx1BTUFFUWVBbUCJZvVBTUFFUWVBcUDZaD1BTUFFUWlBSUFxR ZVBTUFFUW1BSUEBalVBTUFFUXFBSUFxRZVBTUFFUXlBSUFxahVBTUFFUQFBSUF5asVBTUFFUQ1BS UEJav1BTUFFURFBSUFxRZVBTUFFURVBSUEBRZVBTUFFURlBSUFxRZVBTUFFUSVBSUF5bUVBTUFFU S1BSUF5bX1BTUFFUTVBSUFxRZVBTUFFUT1BSUFxRZVBTUFFUfVBSUF5bTVBTUFFYWlBSUFxRZVBT UFFYRlBSUFxRZVBTUFFcWlBSUFxRZVBTUFFcXFBSUFxRZVBTUFFfUFBXUDZbewQpIDU2MTM1cPlw BDg1cB0/Pj8kKSA1cBM/IiA/IjEkOT8+cCA8M35wFDEkMXD5cAQ4NXAdPz4/JCkgNXATPyIgPyIx JDk/PnAgPDN/BCkgNXADPzwlJDk/PiNwGT4zfnBhaWlgfWFpaWJ+cBE8PHACOTc4JCNwAjUjNSIm NTQEOT01I3AeNSdwAj89MT74cAQiMTQ1PTEiO3A/NnAEODVwHT8+PyQpIDVwEz8iID8iMSQ5Pz5w IDwzcCI1NzkjJDUiNTRwOT5wJDg1cAUDcAAxJHB2cAQdcB82Nn5wMT40cDU8IzUnODUiNX4dPz4/ JCkgNWoEOT01I3AeNSdwAj89MT5wAjU3JTwxImoGNSIjOT8+cGJ+ZGVweB05MyI/Iz82JHkEOT01 Ix41JwI/PTE+AAMdBFAeUD9QIlA9UDFQPFA+UClQP1AyUClRXVA1UDpQPlC5UD5QP1AiUD1QMVA8 UANQJFAxUD5QNFAxUCJQNFPKU+FT7VPvU+1T6VPqU/xQBFApUCBQNVA2UDFQM1A1UHBQ+VBwUARQ OFA1UHBQHVA/UD5QP1AkUClQIFA1UHBQE1A/UCJQIFA/UCJQMVAkUDlQP1A+UHBQIFA8UDNQflBw UBRQMVAkUDFQcFD5UHBQBFA4UDVQcFAdUD9QPlA/UCRQKVAgUDVQcFATUD9QIlAgUD9QIlAxUCRQ OVA/UD5QcFAgUDxQM1B/UARQKVAgUDVQcFADUD9QPFAlUCRQOVA/UD5QI1BwUBlQPlAzUH5QcFBh UGlQaVBgUH1QYVBpUGlQYlB+UHBQEVA8UDxQcFACUDlQN1A4UCRQI1BwUAJQNVAjUDVQIlAmUDVQ NFAEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlD+UHBQBFAiUDFQNFA1UD1QMVAiUDtQcFA/ UDZQcFAEUDhQNVBwUB1QP1A+UD9QJFApUCBQNVBwUBNQP1AiUCBQP1AiUDFQJFA5UD9QPlBwUCBQ PFAzUHBQIlA1UDdQOVAjUCRQNVAiUDVQNFBwUDlQPlBwUCRQOFA1UHBQBVADUHBQAFAxUCRQcFB2 UHBQBFAdUHBQH1A2UDZQflBwUDFQPlA0UHBQNVA8UCNQNVAnUDhQNVAiUDVQflAdUD9QPlA/UCRQ KVAgUDVQalAEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlBwUAJQNVA3UCVQPFAxUCJQalAG UDVQIlAjUDlQP1A+UHBQYlB+UGRQZVBwUHhQHVA5UDNQIlA/UCNQP1A2UCRQeVAEUDlQPVA1UCNQ HlA1UCdQAlA/UD1QMVA+UABQA1AdUARQHVA/UD5QP1AkUClQIFA1UHBQBFApUCBQP1A3UCJQMVAg UDhQKVAdUD9QPlA/UCRQKVAgUDVQcFAEUClQIFA1UHBQFFAiUDFQJ1A5UD5QN1BwUB9QNlA2UDlQ M1A1UHBQfVBwUANQJFAxUD5QPFA1UClQcFAdUD9QIlA5UCNQP1A+UHxQcFAGUDlQM1AkUD9QIlBw UBxQMVAiUDRQNVA+UCRQcFBhUGlQY1BiUARQOFA5UCNQcFAiUDVQPVAxUCJQO1AxUDJQPFA1UHBQ JFApUCBQNVA2UDFQM1A1UHBQNlA5UCJQI1AkUHBQMVAgUCBQNVAxUCJQNVA0UHBQOVA+UHBQYVBp UGNQYlBwUDlQPlBwUARQOFA1UHBQBFA5UD1QNVAjUHBQP1A2UHBQHFA/UD5QNFA/UD5QcFA+UDVQ J1AjUCBQMVAgUDVQIlB8UHBQNlA/UCJQcFAnUDhQOVAzUDhQcFA5UCRQcFAnUDFQI1BwUDRQNVAj UDlQN1A+UDVQNFB+UHBQcFAZUCRQcFA4UDFQI1BwUCNQJVAyUCNQNVAhUCVQNVA+UCRQPFApUHBQ MlA1UDNQP1A9UDVQcFA/UD5QNVBwUD9QNlBwUCRQOFA1UHBQJ1A/UCJQPFA0UCNQcFA9UD9QI1Ak UHBQI1AlUDNQM1A1UCNQI1A2UCVQPFBwUCRQKVAgUDVQcFAzUCJQNVAxUCRQOVA/UD5QI1B+UHBQ cFAEUDhQNVBwUD9QIlA5UDdQOVA+UDFQPFBwUDRQIlAxUCdQOVA+UDdQI1BwUCdQNVAiUDVQcFA9 UDFQNFA1UHBQJVA+UDRQNVAiUHBQA1AkUDFQPlA8UDVQKVBwUB1QP1AiUDlQI1A/UD5Qd1AjUHBQ NFA5UCJQNVAzUCRQOVA/UD5QcFAyUClQcFAGUDlQM1AkUD9QIlBwUBxQMVAiUDRQNVA+UCRQcFAx UCRQcFAEUDhQNVBwUARQOVA9UDVQI1B+UHBQcFAZUCRQcFAkUDhQNVA+UHBQJ1A1UD5QJFBwUCRQ OFAiUD9QJVA3UDhQcFAxUD5QcFA1UChQJFA1UD5QI1A5UCZQNVBwUDlQJFA1UCJQMVAkUDlQJlA1 UHBQIFAiUD9QM1A1UCNQI1BwUDlQPlAmUD9QPFAmUDlQPlA3UHBQNlAlUCJQJFA4UDVQIlBwUCdQ P1AiUDtQcFA5UD5QcFAdUD9QPlA/UCRQKVAgUDVQd1AjUHBQBFApUCBQNVBwUBRQIlAxUCdQOVA+ UDdQcFAfUDZQNlA5UDNQNVB+UHBQcFASUDFQI1A1UDRQcFA/UD5QcFA1UChQIFA1UCJQOVA9UDVQ PlAkUCNQcFAdUD9QIlA5UCNQP1A+UHBQOFAxUDRQcFAzUD9QPlA0UCVQM1AkUDVQNFBwUCVQI1A5 UD5QN1BwUABQNVAiUCBQNVAkUCVQMVBwUDFQPlA0UHBQAFA8UDFQPlAkUDlQPlB8UHBQOVAkUHBQ OFAxUCNQcFA9UDFQPlApUHBQP1A8UDRQcFAjUCRQKVA8UDVQcFAzUDhQMVAiUDFQM1AkUDVQIlA5 UCNQJFA5UDNQI1BwUDJQJVAkUHBQJ1AxUCNQcFAxUDRQMVAgUCRQNVA0UHBQJFA/UHBQN1A5UCZQ NVBwUDVQKFAzUDVQPFA8UDVQPlAkUHBQPFA1UDdQOVAyUDlQPFA5UCRQKVBwUDNQP1AlUCBQPFA1 UDRQcFAnUDlQJFA4UHBQN1A/UD9QNFBwUDVQM1A/UD5QP1A9UClQflBwUHBQB1A5UDRQNVA8UClQ cFAlUCNQNVA0UHBQOVA+UHBQMlA/UD9QO1AjUHBQMVA+UDRQcFA9UDFQN1AxUCpQOVA+UDVQI1B8 UHBQNlA/UCJQcFAiUDVQIFA/UCJQJFAjUHxQcFA/UDZQNlA5UDNQNVBwUDRQP1AzUCVQPVA1UD5Q JFAjUHBQMVA+UDRQcFAxUDxQI1A/UHBQNlA/UCJQcFA0UDlQI1AgUDxQMVApUHBQMVA+UDRQcFAx UDRQJlA1UCJQJFA5UCNQOVA+UDdQflA4UCRQJFAgUGpQf1B/UCdQJ1AnUH5QPVA/UD5QP1AkUClQ IFA1UH5QM1A/UD1Qf1A4UCRQPVA8UH9QPVAkUD5QMVA9UDVQf1A9UCNQD1AkUDlQPVA1UCNQPlA1 UCdQIlA/UD1QMVA+UH5QOFAkUD1QPFA4UCRQJFAgUGpQf1B/UCdQJ1AnUH5QPVA/UD5QP1AkUClQ IFA1UH5QM1A/UD1Qf1A4UCRQPVA8UH9QPVAkUD5QMVA9UDVQf1A9UCNQD1AnUDVQPFAzUD9QPVA1 UH5QOFAkUD1QPFAeUD9QIlA9UDFQMVA8UDlQHlA/UCJQPVCxUDxQHlA/UCJQPVAxUDxQNVADUCRQ MVA+UDRQMVAxUCJQNFROVGFUG1QXVG1UG1RpUB5QMVAmUDFQNFA+UD9QEVAiUCJQJVA+UCRQMVAZ UDFQPlAAUHBQA1AlUCNQMVA+UBxQcFAXUAdQMVA0UDVQcFAdUDlQO1A1UBRQJVBwUBdQIlA1UDdQ GFBwUBVQPFA5UBtQcFAAUABQMVAkUDhQNVBwUHZQcFACUD9QMlAeUD9QflBQUFBQUFBQJlBQUCZQ UFAmUFBQJlBQUWBQUFJ4UFBTplBQVlZQUFhCUFBaFlBQWppQUFseUFBbgFBQXfhQUF4oUFBfRlBQ XyBQUF+YUFBAalBQQTxQUEIAUFBDrlBQRYxQUEa+UFBIMlBQSZ5QUErgUFBMlFBQThpQUE6KUFBP +FBQcPhQUHEaUFByClBQc5pQUHb8UFB4mFBQe5hQUH1qUFB+KFBQYFJQUGHYUFBjGlBQZIRQUGXg UFBmnFBQaYJQUGruUFBtQlBQb0ZQUBBiUFASUlBQE9pQUBW2UFAYsFBQGl5QUBv8UFAdmFBQAXhQ UATGUFAG7FBQCFZQUAj+UFAJYFBQCYpQUArOUFAKilBQC2BQUA5mUFAPyFBQMdRQUDNqUFA1sFBQ NyhQUDsOUFA8qFBQPhBQUD/2UFAi3FBQIyJQUCX+UFAnHFBQKVRQUCriUFAsMlBQLdBQUNFKUFDS GFBQ08hQUNYQUFDZplBQ3lRQUMBcUFDB7lBQwuJQUMNwUFDEQlBQxIBQUMVeUFDFAlBQxc5QUMWE UFDGQFBQxhZQUMYuUFDG5FBQxqJQUMdoUFDHKFBQx/ZQUMeGUFDIUlBQyGZQUMgiUFDI+lBQyLBQ UMlKUFDJGlBQydJQUMnqUFDJplBQyn5QUMowUFDKzlBQyopQUMtIUFDLAlBQy9hQUMuQUFDLqlBQ zQZQUM5+UFDwXlBQ8ihQUPSwUFD1bFBQ9YhQUPckUFD63FBQ/N5QUP68UFD/FFBQ/4pQUOGmUFDj ylBQ5MxQUOaCUFDoFlBQ6YxQUOqaUFDtYlBQ7ppQUJB2UFCQnlBQkXZQUJL4UFCTEFBQk4xQUJSO UFCVSlBQlQhQUJXeUFCXnlBQmjJQUJrKUFCaglBQm4hQUJuuUFCc+lBQnRxQUJ5gUFCeOFBQnspQ UICGUFCBalBQgcpQUIRKUFCEOlBQhNxQUIXwUFCIKFBQiOBQUIlUUFCJElBQidJQUIniUFCJtlBQ inhQUIoKUFCK3FBQipBQUIqoUFCLelBQiwpQUIvAUFCLkFBQjOhQUI1kUFCNplBQjuhQUI/eUFCP qFBQsGZQULAkUFCw/FBQsLxQULEgUFCy5lBQtOZQULS2UFC1RlBQtjxQULeAUFC4slBQucpQULro UFC7jlBQvYxQUL88UFChClBQochQUKVkUFCmylBQUI9XUVFRNzhYYFg+r1ZWDFhHDVhtTk5OTk5O Tk5OThc4WFhYnGMVGF4QSDIXbjU1MzVIEBAJEHtpAhAThBMQMa81ph9YNWIObxgbtDQEa+IyF6ME Dg4Of3JjBDEMM5c1QaRXXVZWWFdWVlZXV1dXV1dXV1dXV1hYWFhYWFhYWFhYWFhYMzEyMmijMTER V2Knr/dOWFh745t/e6o3WEqSlV5WVlZeRVhRv0L7iFhYVlhWVjOqVqpCVldWV1dWVlZWVlZWVlZW aw9WUTgPWFgxNaQVWFZYCSxYV1cxVxBXWFFOUFBQUFNQU1FRUVFRVVNTUVJRUVBIVbxbkFCoWK9Q WFBYr65QWVBar65QWlBar65QW1Bbr61QXFBcr61QXVBcr61QXlBdr61QX1Bdr6xQQFBfr6xQQVBf r6xQQlBAr6xQQ1BAr6tQRFBBr6tQRVBCr6tQRlBEr6tQR1BEr6pQSFBFr6pQSVBHr6pQSlBHr6pQ S1BIr6lQTFBKr6lQTVBKr6lQTlBLr6lQT1BMr6lQcFBMr6hQcVBNr6hQclBPr6hQc1Bwr6hQdFBw r6dQdVBxr6dQdlByr6dQd1Byr6dQeFB0r6ZQeVB1r6ZQelB2r6ZQe1B3r6ZQfFB4r6VQfVB5r6VQ flB6r6VQf1B6r6VQYFB7r6RQYVB8r6RQYlB9r6RQY1B9r6RQZFB/r6NQZVBgr6NQZlBgr6NQZ1Bh r6NQaFBir6JQaVBjr6JQalBlr6JQa1Blr6JQbFBmr6JQbVBmr6FQblBnr6FQb1Bor6FQEFBqr6FQ EVBqr6BQElBrr6BQE1Bsr6BQFFBtr6BQFVBtr79QFlBvr79QF1AQr79QGFAQr79QGVARr75QGlAS r75QG1ATr75QHFAUr75QHVAVr71QHlAWr71QH1AXr71QAFAXr71QAVAYr7xQAlAar7xQA1Aar7xQ BFAbr7xQBVAcr7tQBlAdr7tQB1Adr7tQCFAfr7tQCVAAr7tQClABr7pQC1ABr7pQDFACr7pQDVAD r7pQDlAEr7lQD1AFr7lQMFAGr7lQMVAHr7lQMlAHr7hQM1AIr7hQNFAKr7hQNVALr7hQNlALr7dQ N1AMr7dQOFANr7dQOVANr7dQOlAPr7ZQO1Awr7ZQPFAxr7ZQPVAxr7ZQPlAyr7VQP1Azr7VQIFA0 r7VQIVA1r7VQIlA2r7RQI1A3r7RQJFA3r7RQJVA4r7RQJlA5r7RQJ1A7r7NQKFA7r7NQKVA8r7NQ KlA9r7NQK1A+r7JQLFA+r7JQLVAgr7JQLlAhr7JQL1Ahr7FQ0FAir7FQ0VAjr7FQ0lAkr7FQ01Al r7BQ1FAmr7BQ1VAnr7BQ1lAor7BQ11Aor49Q2FApr49Q2VArr49Q2lArr49Q21Asr45Q3FAtr45Q 3VAur45Q3lAur45Q31DQr41QwFDRr41QwVDSr41QwlDSr41Qw1DTr41QxFDUr4xQxVDVr4xQxlDW r4xQx1DXr45QyFDYr41QyVDYr41QylDZr41Qy1Dbr41QzFDcr4xQzVDcr4xQzlDdr4xQz1Der4xQ 8FDer4tQ8VDAr4tQ8lDBr4tQ81DCr4tQ9FDCr4pQ9VDDr4pQ9lDEr4pQ91DGr4pQ+FDGr4lQ+VDH r4lQ+lDIr4lQ+1DJr4pQ/FDJr4pQ/VDLr4lQ/lDMr4lQ/1DMr4lQ4FDNr4lQ4VDOr4hQ4lDPr4hQ 41Dwr4hQ5FDxr4hQ5VDyr4dQ5lDzr4dQ51Dzr4dQ6FD0r4dQ6VD2r4ZQ6lD2r4ZQ61D3r4ZQ7FD4 r4ZQ7VD5r4VQ7lD5r4VQ71D7r4VQkFD8r4VQkVD9r4RQklD9r4RQk1D+r4RQlFDgr4RQlVDgr4NQ llDhr4NQl1Djr4NQmFDkr4NQmVDkr4NQmlDlr4JQm1Dmr4JQnFDnr4JQnVDor4JQnlDpr4FQn1Dq r4FQgFDqr4FQgVDrr4FQglDsr4BQg1Dur4BQhFDur4BQhVDvr4BQhlCQr59Qh1CRr59QiFCRr59Q iVCTr59QilCUr55Qi1CUr55QjFCVr55QjVCWr55QjlCXr51Qj1CYr51QsFCZr51QsVCar51QslCb r5xQs1Cbr5xQtFCcr5xQtVCer5xQtlCer5xQt1Cfr5tQuFCAr5tQuVCBr5tQulCBr5tQu1CDr5pQ vFCEr5pQvVCFr5pQvlCFr5pQv1CGr5pQoFCHr5pQoVCIr5pQolCJr5pQo1CKr5lQpFCLr5lQpVCL r5lQplCMr5lQp1COr5hQqFCPr5hQqVCPr5hQqlCwr5hQq1Cxr5dQrFCxr5dQrVCzr5dQrlC0r5dQ r1C1r5ZQqFivUFhQWK+uUFlQWq+uUFpQWq+uUFtQW6+tUFxQXK+tUF1QXK+tUF5QXa+tUF9QXa+s UEBQX6+sUEFQX6+sUEJQQK+sUENQQK+rUERQQa+rUEVQQq+rUEZQRK+rUEdQRK+qUEhQRa+qUElQ R6+qUEpQR6+qUEtQSK+pUExQSq+pUE1QSq+pUE5QS6+pUE9QTK+pUHBQTK+oUHFQTa+oUHJQT6+o UHNQcK+oUHRQcK+nUHVQca+nUHZQcq+nUHdQcq+nUHhQdK+mUHlQda+mUHpQdq+mUHtQd6+mUHxQ eK+lUH1Qea+lUH5Qeq+lUH9Qeq+lUGBQe6+kUGFQfK+kUGJQfa+kUGNQfa+kUGRQf6+jUGVQYK+j UGZQYK+jUGdQYa+jUGhQYq+iUGlQY6+iUGpQZa+iUGtQZa+iUGxQZq+iUG1QZq+hUG5QZ6+hUG9Q aK+hUBBQaq+hUBFQaq+gUBJQa6+gUBNQbK+gUBRQba+gUBVQba+/UBZQb6+/UBdQEK+/UBhQEK+/ UBlQEa++UBpQEq++UBtQE6++UBxQFK++UB1QFa+9UB5QFq+9UB9QF6+9UABQF6+9UAFQGK+8UAJQ Gq+8UANQGq+8UARQG6+8UAVQHK+7UAZQHa+7UAdQHa+7UAhQH6+7UAlQAK+7UApQAa+6UAtQAa+6 UAxQAq+7UA1QA6+7UA5QBK+6UA9QBa+6UDBQBq+6UDFQB6+6UDJQB6+5UDNQCK+5UDRQCq+5UDVQ C6+5UDZQC6+5UDdQDK+5UDhQDa+5UDlQDa+5UDpQD6+4UDtQMK+4UDxQMa+4UD1QMa+4UD5QMq+3 UD9QM6+3UCBQNK+3UCFQNa+3UCJQNq+2UCNQN6+2UCRQN6+2UCVQOK+2UCZQOa+2UCdQO6+1UChQ O6+1UClQPK+1UCpQPa+1UCtQPq+0UCxQPq+0UC1QIK+0UC5QIa+0UC9QIa+zUNBQIq+zUNFQI6+z UNJQJK+zUNNQJa+yUNRQJq+yUNVQJ6+yUNZQKK+yUNdQKK+xUNhQKa+xUNlQK6+xUNpQK6+xUNtQ LK+wUNxQLa+wUN1QLq+wUN5QLq+wUN9Q0K+PUMBQ0a+PUMFQ0q+PUMJQ0q+PUMNQ06+PUMRQ1K+O UMVQ1a+OUMZQ1q+OUMdQ16+OUMhQ2K+NUMlQ2K+NUMpQ2a+NUMtQ26+NUMxQ3K+MUM1Q3K+MUM5Q 3a+MUM9Q3q+MUPBQ3q+LUPFQwK+LUPJQwa+LUPNQwq+LUPRQwq+KUPVQw6+KUPZQxK+KUPdQxq+K UPhQxq+JUPlQx6+JUPpQyK+JUPtQyK+KUPxQya+JUP1Qy6+JUP5QzK+JUP9QzK+JUOBQza+JUOFQ zq+IUOJQz6+IUONQ8K+IUORQ8a+IUOVQ8q+IUOZQ86+IUOdQ86+IUOhQ9K+IUOlQ9q+IUOpQ9q+I UOtQ96+IUOxQ+K+HUO1Q+a+HUO5Q+a+HUO9Q+6+HUJBQ/K+HUJFQ/a+GUJJQ/a+GUJNQ/q+GUJRQ 4K+GUJVQ4K+FUJZQ4a+EUJdQ46+EUJhQ5K+EUJlQ5K+EUJpQ5a+DUJtQ5q+DUJxQ56+DUJ1Q6K+D UJ5Q6a+CUJ9Q6q+CUIBQ6q+CUIFQ66+CUIJQ7K+BUINQ7q+BUIRQ7q+BUIVQ76+CUIZQkK+BUIdQ ka+BUIhQka+BUIlQk6+BUIpQlK+AUItQlK+AUIxQla+AUI1Qlq+AUI5Ql6+fUI9QmK+fULBQma+f ULFQmq+fULJQm6+eULNQm6+eULRQnK+eULVQnq+eULZQnq+eULdQn6+dULhQgK+dULlQga+dULpQ ga+cULtQg6+bULxQhK+bUL1Qha+bUL5Qha+bUL9Qhq+bUKBQh6+bUKFQiK+bUKJQia+cUKNQiq+b UKRQi6+bUKVQi6+bUKZQjK+bUKdQjq+aUKhQj6+aUKlQj6+aUKpQsK+aUKtQsa+ZUKxQsa+ZUK1Q s6+ZUK5QtK+ZUK9Qta+YUKhYr1BYUFivrlBZUFqvrlBaUFqvrlBbUFuvrVBcUFyvrVBdUFyvrVBe UF2vrVBfUF2vrFBAUF+vrFBBUF+vrFBCUECvrFBDUECvq1BEUEGvq1BFUEKvq1BGUESvq1BHUESv qlBIUEWvqlBJUEevqlBKUEevqlBLUEivqVBMUEqvqVBNUEqvqVBOUEuvqVBPUEyvqVBwUEyvqFBx UE2vqFByUE+vqFBzUHCvqFB0UHCvp1B1UHGvp1B2UHKvp1B3UHKvp1B4UHSvplB5UHWvplB6UHav plB7UHevplB8UHivpVB9UHmvpVB+UHuvpVB/UHqvpVBgUHuvpFBhUHyvpFBiUH2vpFBjUH2vpFBk UH+vo1BlUGCvo1BmUGCvo1BnUGGvo1BoUGKvolBpUGOvolBqUGWvolBrUGWvolBsUGavolBtUGav oVBuUGevoVBvUGivoVAQUGqvoVARUGqvoFASUGuvoFATUGyvoFAUUG2voFAVUG2vv1AWUG+vv1AX UBCvv1AYUBCvv1AZUBGvvlAaUBKvvlAbUBOvvlAcUBSvvlAdUBWvvVAeUBavvVAfUBevvVAAUBev vVABUBivvFACUBqvvFADUBqvvFAEUBuvvFAFUByvu1AGUB2vu1AHUB2vu1AIUB+vu1AJUACvu1AK UAGvulALUAGvulAMUAKvu1ANUAOvu1AOUASvulAPUAWvulAwUAavulAxUAevulAyUAevuVAzUAiv uVA0UAqvuVA1UAuvuVA2UAuvuVA3UAyvuVA4UA2vuVA5UA2vuVA6UA+vuFA7UDCvuFA8UDGvuFA9 UDGvuFA+UDKvt1A/UDOvt1AgUDSvt1AhUDWvt1AiUDavtlAjUDevtlAkUDevtlAlUDivtlAmUDmv tlAnUDuvtVAoUDuvtVApUDyvtVAqUD2vtVArUD6vtFAsUD6vtFAtUCCvtFAuUCGvtFAvUCGvs1DQ UCKvs1DRUCOvs1DSUCSvs1DTUCWvslDUUCavslDVUCevslDWUCivslDXUCivsVDYUCmvsVDZUCuv sVDaUCuvsVDbUCyvsFDcUC2vsFDdUC6vsFDeUC6vsFDfUNCvj1DAUNGvj1DBUNKvj1DCUNKvj1DD UNOvj1DEUNSvjlDFUNWvjlDGUNavjlDHUNevjlDIUNivjVDJUNivjVDKUNmvjVDLUNuvjVDMUNyv jFDNUNyvjFDOUN2vjFDPUN6vjFDwUN6vi1DxUMCvi1DyUMGvi1DzUMKvi1D0UMKvilD1UMOvilD2 UMSvilD3UMavilD4UMaviVD5UMeviVD6UMiviVD7UMmvilD8UMmviVD9UMuviVD+UMyviVD/UMyv iVDgUM2viVDhUM6viFDiUM+viFDjUPCviFDkUPGviFDlUPKvh1DmUPOviFDnUPOviFDoUPSviFDp UPaviFDqUPaviFDrUPeviFDsUPivh1DtUPmvh1DuUPmvh1DvUPuvh1CQUPyvh1CRUP2vhlCSUP2v hlCTUP6vhlCUUP+vhlCVUOCvhVCWUOGvhFCXUOOvhFCYUOSvhFCZUOSvhFCaUOWvg1CbUOavg1Cc UOevg1CdUOivg1CeUOmvglCfUOqvglCAUOqvglCBUOuvglCCUOyvgVCDUO6vgVCEUO6vgVCFUO+v glCGUJCvgVCHUJGvgVCIUJGvgVCJUJOvgVCKUJSvgFCLUJSvgFCMUJWvgFCNUJavgFCOUJevn1CP UJivn1CwUJmvn1CxUJqvn1CyUJuvnlCzUJuvnlC0UJyvnlC1UJ6vnlC2UJ6vnlC3UJ+vnVC4UICv nVC5UIGvnVC6UIGvnFC7UIOvm1C8UISvm1C9UIWvm1C+UIWvm1C/UIavm1CgUIevm1ChUIivm1Ci UImvnFCjUIqvm1CkUIuvm1ClUIuvm1CmUIyvm1CnUI6vmlCoUI+vmlCpUI+vmlCqULCvmlCrULGv mVCsULGvmVCtULOvmVCuULSvmVCvULWvmOlQEFM342kQYm/rUzZQUVAQUzbjSU1i3+tTNlBRUBBT NuNZWmIQ6FM241leYhDoUzbjWV9ib+tTNVBRUBBTNeNZXGIQ6FM140pNYhDoUzXjWV5iOxFeUzNQ K1MzUFJQRFMzUHRTM1BkUzNQFFMzUFRTM+J0f0/qUx5QPVhQEF5PL1IvUy9UL1VUYBRRQu9TYlAA WFBQT1BCU31QbFhQEHlPD2xRZzBZIFnQWVNAWXBZYFkQWQBZVT9TL1PfU1NPU39Tb1MfUw9TVeiv kOJXamPor5AQF1ZqY8Bb8FvgW5BbgFtV4FaQVoBWsFagVlVwVmBWEFYAVjBWIFbQVsBW8FZZwFbA V1IwWyBb0FtTQFtwW2BbEFsAW1VPV1HwEdVTMlBRUFBTMlBAUzJQIFMyUMBTMlBUUKBTD1BRUHBT DlBwUw9QYFMPUBBTDlBUUFBTDlBQUw9QQFMPUIBTDlCwUw9QVVBAU19QcFNfUGBTX1CAU19QsFNf UFVQUFNfUEBTX1AAU19QMFNfUCBTX1CAU19QVlBQU19QQFNfUHBTX1BgU19QsFNfUKBTX1BWU19Q d1BQU15QYFNeUFJQsFNeUKBTXlBSU15QGlCwU11QoFNdUFJTXVB3UIBSrFBRUEBSrFBwUqxQAFKs UFNQgFKsULBSrFBSUFBSrFBAUqxQcFKsUGBSrFAAUqxQMFKsUFZQsFKsUKBSrFBSUHBSrFBgUqxQ EFKsUFNSrBAxd5B5UeB5UfB5UcB5URBsbxFiEHJvEWJCQkIPcw91D3gP9VQ/cz91P3g/9VQfcx91 H3gf9VRvc291b3hv9VR/c391f3h/9VRPc091T3hP9VTfHP8c7xyfHFQPHD8cLxxTZ+ivkOPie2Bi 6K+Q4+JydWLor5Dl4klKYmdfEW1S/1BRUA9S/1DPUv9Qj1L/UFNQX1L/UE9S/1B/Uv9Qb1L/UD9S /1BVUv9S/1BPUv1Qf1L9UG9S/VAfUv1QD1L9UFVQj1L9UFFQX1L9UE9S/VBvUv1QD1L9UM9S/VBV UA9S/VCPUv1QUlBfUv1QT1L9UG9S/VBTUBBS/OJqYx8RHFL8UA9S/FDPUvxQU1B/UvxQb1L8UFJQ X1L8UG9S/FD/UvxQU1DgUvxQsFL8UFJQH1L8UA9S/FDwUvxQU1BfUvxQT1L8UH9S/FBvUvxQVFBf UwpQUVBfUwpQT1MKUG9TClAPUwpQIFMKUFVQn1MHUI9TB1BSUF9TB1BPUwdQIFMHUP9TB1BUUwpT ClMHUwdS/VL9UvxS/FN8EF1hRU9QRkZQUFBCQVhAEUBSXFAaUF1R+FAaUF1RyFAaUF1R2VAaUF1R b1AaUF1RdBBeGl2mGl3uGl3WGl13Gl3uUnhQEVBdUcRQEVBdUXEQWxFd5BFdHxFdeRFdEUBSR1Bx UF1SRVBxUF1SVlBxUF1Ru1BxUF1RHlBxUF1RfBBEcV2pcV2jcV2hcV3NcV0hcV1tcV0RQFJMUE9Q XVJEUE9QXVJbUE9QXVHGUE9QXVEaUE9QXVF2EFtPXZZPXQdPXWdPXRFdUc5REVBdUBJREVBdUE5R EVBdUEtREVBdUaLkXxRfUFnrUaJQFFBdUlHibHlP6FJQ4mx5T+hRr+JsEU/oUa7ibBdP6FGt4mzO T+hRquJsw0/sUalRX1FRUE9RpuJ0tE8RRVGkURlUUVBPUaNRGVRRUE9RoVEZUPtQT1GgURlQN1BP UfZQbFF1UE9R9OJs0U8RRVHzUV9RylBPUfJQclhRUE9R8VAAVFFQT1HPURlRylBPUc1RGVA3UE9R zOJ8Mk/oUcvifClP7FHKUHxRUVBPUcfifLRP6FHD4nzZT+hRwuJ8PE/oUd/idc5P6FE64mx6TxFB UTdQdFJRUE9RM1B1UvtQT1EcUV9RylBPURhRGVA8UE9RF+J82U/oURXifM5P6FEU4nwpT+hRE+Jz YU/oUXfibNFP7FFzUABRUVBPUU/ic7RPEUVRTVBzUcpQT1FMUHNYUVBPUUtQdVhRUE9RXlFfVFFQ T1FdUHJUUVBPUVjic9FP6FFW5HW0T6ds61F1UE9QpVFf4s5Ps+xRGVEGUE9QslEZ4vtPgelRGVRR 4k+ffOhRdeZPnnPrT5V06FEG4k+QfOhYUeJP73zoUlHlT+F0tE/g6VEZUlHmT/98N0/9c+hYUeJP 9XPoUlEQW0/PbH1Py3MKT8l16FJR4k/RfOxUUVBPUD1RX1EGEFtPCXxuTxxs+08WdehRUeJPEGzo UXUQWk9qcyJPaWz7T2joURnj+09hdOhUUeJPYHXoUvvmT3p0tE92c+hRBuJPBWfqUmVQV1ElEHxX JFcyVwZXAVdrV2NXfVdwV01XTFdEWEJYQFheWFxYWlhYWFZYVFhSWFBYROivsBB7UFBRUERWQFBQ UVBWVFBQUVBUQFBQUVBAUlBQUVBSUFBQUVBQUlFYUlAaUOBDUxtSGwMSUeBCG1AbBBLgZ3sb6Fev AuBoexvgWAALCOFRUd4J4Gh74FLY6FFQBAjoUa/hUVHe1UvgQhMI6VBRUX/V3UvpUFFRLNXdCQlR G+CQM1AbMnDgpgNz6FFaAQrgVXMSSFBGJm9Ib0JuQWkWFG5BaRYUbkFpFhRuQWkWFG5BaRYwFG5B aRYwFHt7e3t7e3t7e3t7SHt7e3t7e3t7e3t7e3tITeDGGwMI4PpNCeBiGwMI4K9NCRvgFwNwDAjp UiFSPxUU6VIgUj8VFAkI6VEqUiEVAgjpUiFRKhQJCRvgFwNwDAjpUHJSIBUU6VBsUiAVFAkI6VHj UHIVAgjpUHJR4xQJCRvgHANwDAjpURlQchUU4XJyFRQJCOlRklEZFQII6VEZUZIUCQkb4DcDcAwI 6VB0UiEVFOlQAFIhFRQJCOlSTlB0FQII6VB0Uk4UCQkb6FJRA3AMCOlRX1ByFRThcnIVFAkI6VxQ UV8VAgjpUV9cUBQJCRvgTANwDAjhdXUVFOF8dRUUCQjhZ3UVAgjhdWcUCQkb4PsDcAwI4XV1FRTh c3UVFAkI6VEJUHUVAgjpUHVRCRQJCRvoUVEDcAwI4XV1FRTheHUVFAkI6VJYUHUVAgjpUHVSWBQJ CXt7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7e3t7e3t7e3t7e3t7e3t7NRJ7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7e3t7UeMxjDQzFTVzFTBzFTUwcxUw4NsmOEjg0DJwcOE0jBU1cxVw4FN2MDIzOHDgU3Yx NeCMczUU4DRzFHDhMTMVNXMVcOBTdjAyMzhw4FN2MTXgM3M1FOAxcxThUDMVBAjhMxA1FOIxEDEV czEUCeP2LxMbFTVzFTBzFTUwcxUw4NkmOEjg0DJwcOETLxU1cxVw4FN2MDIzOHDgU3YxNeAvczUU 4BNzFHDh9hsVNXMVcOBTdjAyMzhw4FN2MTXgG3M1FOD2cxThUBsVBAjhGxA1FOL2EPYVczEUCRsC ElEbAAjhWFASCRMMCOFYUBIJ41JbWkITCDBLcQkSRkAgbuBCEwjpa3FILkvqVFBR+FBbewngXHMS 4F1zEuBCEwjpfRF9EUvqVFBUUFBbewngXnMS4F9zEuBCEwjpSC5rcUvqUfhUUFBbewngQHMS4EFz ElB7UEgVORQVORQVORQVORQjIyMkIyMjJCUleyMjJCQlSBU5FCMjJHsb4HEDG+AWAQoI4GzgbBXg EDAUCVF7e3t7JSUlJSUlJSUTCBBA72yfbFI/bC9s32zPbP9sVSUlCRMIEELvcp9yUg9yP3Ivct9y z3L/clYlJQkTDAjmEGzPcr9yUyUJe3tRJCQkJBUUIyMkJCUlFRQjFRQjJBUUIyQlIyMjIyNQJSUl IyUlJXt7JSUlJXslexMIEXJQM1N9UFFQU1N9UENTfVBzU31QY1N9UANTfVBVUJNTfVCDU31Qs1N9 UKNTfVBUUNNTfVDDU31Q81N9UONTfVBUU31TfRVIORQkJCUlCXsTCOlQSFNi42BlYmjoU2LjMTZi aOhTYuMDCmJo6FNi4xUeYmjoU2LjbBFiSOhTYuJvY1oRX1NiUFFQ6lNiUJpTYlCKU2JQulNiUKpT YlBVU2JTYhVIORQkJXt7e3t7ewkjUCN7UXslJVB7e3skUHt7eyN7JFF7EBAQb25tbGtqaWhnZmVk Y2JhYH9+fXx7enl4d3Z1dHNycXBPTk1MS0pJSEdGRENCQUBfXl1cW1pZWFdWVVRTUlFQfBVzFjBw 4HYw4FR2cxgYfXwVcxZzMXDgdjHgVHZzGBh9fBVzFjDgcDFw4BYw4FR2cxgYfXwVcxZzMeBwMHDg djHgcDHgVHZzGBh9fBVzFjDgEDFw4DYw4FR2cxgYfXwVcxZzMeAQMHDgdjHgEDHgVHZzGBh9fFFA cGxQbH18cBVzcOCdFHNw6FEKAQhzcODdFHMJcOC9AQhzcOAdFHMJcODAAQhzcOBdFHMJcXF9fHBw FUg4FHDgUTBwFeAWJjjaFTAUfXxR4VtaE3MTNVp9fFDhWlsTcxNbfXxQ4EdzIOFRR25R4EdzIOFS RxVq4VJQWF19fBXgSnMUFeBJcxR9fHAV4FN1FTE04AABCBUUS3FxCX184FETM3My4FBzEuBfe318 cBXgUBMwFH18UeBWE+BXEzVafXxwOeAQMeBQ23DhfJDa3OhAUDIwe1w0czQxDAjgUzEJfXwV4EF7 4EdzFOBHKrRIfXwV4EF74EdzFH184EITCNcV4EF74EdzFOBHKrRLU9oVSDlw4EdzFNra13Dg8AEI 4EF74EdzFOBHKrRLceBHKrQJCUh9fOBSdRYw2hbgEDHcGH18GwNwDAjgUtUJCOBR1Ql9fHDgU3UV 4ElzFBXgSnMUFTVzFXDgU3UwOnDgWXMSczjaOjAxcOBK2uBQAilx4kpKEOmvsFBKFXDaBAhzceBv S3MJMRRM4URQ2gIp40kQcEkVcNoECHNx4G9LcwkxFH184UBBE3MTW3184V5fE3MTW3184VxdE3MT W3184VxdE3MTNVt9fOFeXxNzEzVbfXzhQEETcxM1W318GwIIFRRLcXEJfXxRcOBTdXMZ4BAw4HAz cOBQAghz4FJ1aHPgUnU1aFDaM2hLcXFxcXEJUX18G+A0AQgVOeBZEzDaQGpLcXFACX18UeBVdUBz cNqlUOBRMHO9vH18UeBVdUBzcNqlUOBRMXO9vH18UeBWdUClUL28fXxw4FEwUUBwbFBsfXxw4FEx UUBwbFBsfXzge3vgenp9fFDgVxPgVhNbfXxu4Hp6fXxlfXwm6FLgcyBAcOhS4BVw4FAACOBRMQlq f0h9fHFxXDRzNNvoEFAyfXxx4NABCFw0czTb6HBQMkviUBB/ewngUjB9fHHgkAEIXDRzNNvoRQUy S+JQ0H97CeBSMH18XDRzNNvoEFAyMHNxfXzkUFFQUFBF4Fh24Fh24Fh24Fh2X0BGQxU4auBRRn18 5FBRUFBQReBYduBYduBYduBYdl9ARkMVODVq4FFGfXwbA3MbAQoIcBXaMBRLcXEJfXwbBAhwFdow FEtxcQl9fBsDcxsBCghoS3FxCX18GwQIaEtxcQl9fFEbA3MbAQrgUnXgVHXgVnUZcxVIOQIKCOBS deBSdeBVdRZzFTkwGAlxcXF9fOBDEwhTS1IJfXzgQxMIUktTCX18GwTgQhMMCghoS3FxCX184EIT DAhc4FR14FR1Vlw0czQxNOhXWAEI4FR14FR1UXAW4EAwGHAW4EAwGAlacXFLcXEJfXzgQhMMCFzg VHXgVHVWXDRzNDE06FdYAQjgVHXgVHVRcBbor6AwGHAW6K+gMBgJWnFxS3FxCX18GwNzGwEKCOBq e0txcQl9fBsDcxsBCgjga3tLcXEJfXwbA3MbAQrgQhMMCghoS3FxCX18XNpTGwTgVHZSGwQK2tpa 4EITDAoIaEtxcQl9fBZzFjDa2hZzcBbaMNox6K/QMnNwQHPa6VMIUwjaIBUwcOBQAAjgUTHor+rb S+AW3AngQDA4UWp9UFXeUFBVHFBPVRxQTFPEUEtQUK+xUFCvtFBQr7iuGq+sVTtQc646r7BTQ1BQ UP1QUFD9r6+vr1B1UMZQz1B0UKBRYVCSUJBQGlD2UBFQAFDEUBdQn1D/UF5QKVGbUFRQc1AUUPhQ dVFPUFJQFlBHUVVQyVCJUAxQIlC1ULBQeFAbUI5RQlB0UBVQIFBGUGmvuVBGUBtQ2K/pUIlQWlAT UP5Q6lE8UQNQf1ATUBhSfFF7UHVQ36+QUEdQeK+dr4hQdVDNULVRdK/hUBhQzVC2UEFQd1AvUMFQ QlA6UJqvrFBQUHRQMlD3USxRuVBxUDBQ21RkVNqvO1BrUOVQhVEbrztQHVApVYhZ5VA8UMFQ81FH UZCvj6+3UO5UUVA1UC9Q0lDYUMlQ4lCQUn5TE1XwUHBQdlBtUB5QMVA1UCtQiVFDUWFTEK93rxKv yVAeUPdQolJ7UpZTV1BBUHtQGVAPUN1Q8VD/UIZQtFClUVtRZVHNUftR+1GBUb5ViFBQUBtQJVAq UNBQzVD2UPdQ/FDpUWFRYVJHUkdQUlBHUHlQBVDQUN9Q9VDiUONQgFEbUQlRkFGRU/VVYK5vr0Sv Ra+3r69QelAIUMlQz1CRULRQpFFgUQlR+1H7U3JTJFROVCRVYq3RUB1QNFDMUIBQgVCGUI5QtVCl UKhRelF6UbFSLlIvrwev+K+1UFBQWFBPUGhQAVAKUD9QJlAnUPJQkFCSUJRQoVGrUllSLlKfVJVV KlWgr8JQQlB2UBJQG1AfUAFQA1A0UNtQ/lDiUOhQ6FCGUKVRQVFwUWFRaFEeUQJRN1HfUcZR6FGJ UYlSVlJxUiFSulPgU5tTjFRmVVWvalBCUEZQTlBPUHNQB1A4UDxQLlDYUMJQ9VD4UJVQmVFFUXZR fVFgUYZRiVGmUmtSFFIUUvNSn1KOU9VT31SsVdausK67rquv2lBXUBRQF1AIUCVQ+lC0UL9RRlFw UXlROlEjUbNSLlLAUuRTXlNAU3NTZVMRUwRTCVPYU8RTmFOeVCJU+1SKVRlVMVX7VzGuPq6Brxuv 1FBQUFFQVlBOUHdQfFBkUGdQMlA2UDpQO1A8UCBQIFAiUCxQ0VDaUN5QwVDCUPBQ+1DoUO9QmVCF UI1QvFCkUVBRcVFgUTlROlE9USxR1VHeUd5RyVH8UZFRlVGZUbFRplGmUaZSclJyUnhSZlJvUhNS FlI3UtVS1VLEUoBShlK4U0xTM1MvU9BT0FPOU+ZTiVRQVFRUr1ViVWJVGFXbVfdWm1d4VxhXMlic rL2teq0JrY6uUK5Krguuxq6RrrevBq8pUFFQdVB9UH5QLFDXUMFQyVDxUPVQ9VD6UP9Q5lCWUJxQ h1CNULxQolFSUVVRR1FIUXNRelF8UWFRb1EXURlRGVEdUQFRAVEFUQVRB1EKUQpRMVEyUThROFEv UdBR0lHTUdRR3VHFUcVRxVHIUclR9VH5UeZR5lHnUepR6lGFUY9RtlG6UaJSUFJQUlNSR1J1UndS f1JpUhNSE1IXUh9SAlICUjdSP1I/UiBSIlImUi5S91LjUulShlNDU3VTfVMxUyFTyVP+U5JThFOp VFJUfFR/VGxUBlQ3VNNUn1SBVIhUq1VPVRVVOFXOVZJWS1ZkVgVWOlbIVv9WuFasV1ZXAFcyVyxX hFevWHVQ/VCXUPpQ5VBQUFBQUFBQUFBQUFB/Vp9RI1VEVChSj1DMUEhTIFXXUQVQdVBWUgRTPFPe U4JVNlGgU3BRilHaUzlTO6/zUxZSqFM/UQZS71FyU09ValM2UNxQr1H7UrFSpFK3VEVRBFK5UXhU wVHnUj9TE1JWUFBQUFWDVEVU01W4UFBSh1BqUi1RkFKVU9NT06/tUGpVzlGPVc5SgVBwVLBSQ1CP UZBR11LHUFBQnlI5UttQCFRkVatQOVEKUflVKFHSUW5S2FF6U4RUzlC1U3NSo1GgUcZQKlCdURpU dFIOUmlR+1CfUK1RTlC9USFQIFHFUBBR61GNUehQUVH4U/dRHFJcUd1R4FJdUWdRUFCdU3FRhFNa UAlQUFBQUXZSRVEAUqBSBVPsVoBTZVFRUIBQglAqUVNRYFAsUFBQUFBQUFBQrlA+UDZQxFJ3UHtQ FVAdUINRYlBIUMdQEVCkruyvuVBGVYhV21DBUPFTfFACUGBQDVKbUGpQwlC1ULVQCFDWUGJQ6lDJ UNhQYFLIUCyv0FE0UHhQHVA1UFJQ6FE6UH9RW1BBUEdRUFAvUFRQRlJyUPZQD1BQUKhQWlCaUBNQ G1G+UCdRcFCkUZBQeFQPUFBQ3FQVUJJQMFArUNtQ21A0UA1QklDMUMJW5VWDUB9RR1BQVmlRTFBQ UFBSUFBQUlBQUFL6ULRTFFDVVFBQdVRQUDxW+lAYVmlQG1EhUAFS+lAEUvpQflRQUMFU01B1UlBQ PlL6UANSUFDBUmlQU1RQUBpUUFCgVFBQfFRQUANUUFBwVFBQMlRQUAhUUFAcVFBQLFRQUAFSaVDg UmlQ3lTTUHVU01B1VNNQdVPdUAxXDlAxVZdQQFUGUHJVBlAaVZdQc1SzUHpUI1BxVZdQGFWXUHNS +lBjU01QelWXUHJUs1B5V01QclWXr7VVl1AYVCNQclWXUBhVBlBzVCNQ0FSzUG5Vl1BbVZdQQlfd UEtVl1BfVZdQQ1SzUEpS+lD4UmlQU1L6UBtTkVB1VFCvv1L6UCZT3VAZVFCvq1PdUBZUUFAUU91Q HFL6UB9UUFBtVFBQXVJpUGxSaa8zVFBQQVJpUG1WaVBBVFBQXFRQUBVUUK+pVFBQFFL6UF1TTVA0 UmlQRFRQUFJUUFBBVZdQXVRQUEtUUFBcU91QeVOHUUtRylDxU4dQ4VQEUERVl1BeVZdQXlUGUBpU s1B6VZevtVWXUBhVl1BbU91QGVPdUBlT3VAZU91QGVPdUBlT3VAZU91QFlPdUBxT3VAcU91QHFPd UBxSaVBsUmlQbFJpUF1SaVBSVFBQXFRQUBVUUFAVVFBQFVRQUBVUUFAVVFBQUlRQUFJUUFBSVFBQ UlRQUDVTY1AyVFBQ0VRQUG1UUFDMUp1QIFPwr6JUUFBzVkRQFVZEUBVXh1BOUvpQvFL6UGlXTa+4 VZdQGVQ0UFhUUFBSVMxQ1lJlr6pSK1BNVQZQGVRQUHdT3VAJUvpQtFTTUHRUUFBSVFBQEFRQUBBY UFC2VZdQXlWXUF5Vl1AYV01QG1WXUBNUUK++WFCvvVPdUBNT3VATUvpQ6VL6UJFUNFBHVFBQXFWX UENUUFBLUvpQJ1L6UCNUUFDbUlBQwVL6UJFT3VATWFBQEVWXUF5Us1B6VZdQQFSzUHpUs1B6UvpQ Y1L6UGJS+lBiUvpQYlWXUBhVl1AYVZdQGFWXUFtVl1BbVZdQW1JpUGxS+lBsUvpQRlL6UMZS+lDr UvpQbFQjUC5TTVA0VLNQSlPdUHlRylDxVZdQc1RQUBRVl1BDVFBQXFQjUHRUUK+pVNNQ9VI2UNhS NlBEUjZQfFZQUNZWUFDWVlBQelRQr79YUFBTVFCvuVBQUEhQUFC0W1xZUFNTVFVWVllZUlRUVlZT VFNTVlZWVlZWVlZWVlNTVlZWVVpYV1dYV1ZXWFRUWFdaWFhXWFdVWFhXW1hYV1RTVFVWVFVVVVVV VFVWU1NWU1lWVlZVVFRUVVZXVlZVVVJVVlhYV1dYWFhVVVVVVVVVVVVVVVNTU1NWVlZWVlZVVVVV VVRWVlVUVVVYWFxUVFtYVlZVVFNYVlVUVlZWVlpYWFhaWFZbVlVUVFZWWFZUVFZTVFVbWFdYV1dU VFRUWFhYWFhYU1RUVFRUVVRXVVJYVlhWVlZWU1NTWFhYVltWUFBQXFxZUFNTVFVWVlpZUlRUVldT VFNTVlZWVlZWVlZWVlNTV1dXVVtZWFhZV1dZWVRVWVdcWVlXWVhWWFlYW1lYWFRTVFZWVFVWVVZV VFVWU1NWU1lWVldWVFVUVlZZVVdWVlJWVllZWFdZWVlVVVVVVVVVVVVVVVNTU1NWVlZWVlZWVlZW VlVWVlVUVlZZWVxUVFtZV1ZXVFNYVlVUV1ZWVlxZWVlbWVZcVlVUVFdXWFZUVFZTVFVcWVdZV1dU VFRUWVlZWVlZU1RUVFRUVlVYVlNZVlhXV1dXVFRUWVlZVlxWUFBQXV5aUFNTVFZXVltaUlRUV1dT VFNUVlZWVlZWVlZWVlNUV1dXVlxaWFhZV1dYWVRVWVdcWVlXWVhXWFlYXVlYWFRUVFZXVFZXVldW VFdXU1NWU1lXV1dXVFZUV1dZVVdVVlJWV1paWFdZWVlWVlZWVlZWVlZWVlNTU1NXV1dXV1dXV1dX VlVWV1dUVldaWlxUVFtZV1dXVFRZV1VUV1ZXV1xaWllbWVddVlZUVFdXWFdUVFZTVFVeWldaV1dU VFRUWVlZWVlZU1VUVFRVV1ZYVVJZV1hXV1dXVFRUWlpaV11WUFBQX19cUFRUVVVYV11cU1VVV1hT VVRUV1dXV1dXV1dXV1NUWFhYV15bWlpbWVhaW1VWW1ldW1tZW1pYWVtbXlpbWVVUVVZYVFdXV1dX VVdXU1NXU1tXV1dXVVZUV1dbV1dWV1NXWFtbWllbW1tXV1dXV1dXV1dXV1NTU1NXV1dXV1dXV1dX V1ZYWFhVV1hbW19UVV1bWFhXVFRaWFdVWFdXV19bW1tdW1hfVldVVVhXW1hVVVdUVVZfW1lbWVlV VVVVW1tbW1tbU1VVVVRVWFZZVlNcWFtXWVhYVVVVW1tbWF9XUFBQQEBcUFRUVVVYWF1cU1VVWFlU VlRUWFhYWFhYWFhYWFNUWVlZV19bWltbWVlbW1VWXFleXFxZXFpZWVtbX1tbWVVUVVhYVVdYV1hX VFdXU1RYU1tXWFhYVVZUV1dbV1dWV1NYWVtbW1lcXFtXV1dXV1dXV1dXV1NTU1NXWFhYWFhXV1dX WFZYWFhWV1hcXEBVVV1cWVhXVVVbWFdVWVhXV0BbW1xeW1hAVlZVVVlXW1hVVVdUVVZAW1lbWVlV VVVVXFxcW1tbU1VVVVRVWVZZVlNbWFtXWlhZVVVVXFxcWEBYUFBQQUFdUFRUVVVZWV5dU1ZWWVpU VlRVWVlZWVlZWVlZWVVUWlpaV19bW1tcWllcXFVXXFpfXFxaXFtZWVxbQFxbWlVVVVhZVldYWFhY VlhYVVVYVV1YWVhYVldVWFdbWFhXWFNYWVtbW1pcXFxXV1dXV1dYWFhYWFVVVVVYWVlZWVlYWFhY WVdYWVhWWFldXUFVVV5cWVlYVVZbWVdVWllYWEFbW1xfXFlBVldVVVlYW1lWVlhUVlZAW1pbWlpV VVVVXFxcXFxcVVZWVlRWWVdaV1NdWVtYWlhaVVVVXV1dWUFZUFBQQ0RfUFVVVlhaWUBfVFZWWVtV VlVVWVlZWVlZWVlZWVRVW1tbWEFdXF1dW1teXVZXXVtAXV5bXl1bXF1dQl1dW1ZVVlhaVlhaWVpY VllZVFRZVF5ZWlpaVlhVWVldWVlYWVNZWl1dXVtdXl1YWFhYWFhZWFhYWFZWVlZZWlpaWlpZWVlZ WlhZWllXWVleXkRWV0JeWlpbVVZdWlhWW1laWkNdXV5BXlpDWVhXV1pZXVpWVlpVVlhDXVtdW1tW VlZWXl5eXV1dVlZWVlZWW1hbWFNeWl1ZW1pbVlZVXl9eWkNZUFBQRUZAUFVVVlhbW0JAVFdXWlxV V1VWW1tbW1tbW1tbW1ZVXFxcWkNeXl5fXVxfX1ZYX1xCX19cX15bXF9fQ15fXFdWV1pbVllaWVpZ V1paVlZaVkBaW1paV1hWW1pfWllZWlNaW15eXl1fX19ZWVlZWVlZWVlZWVZWVlZaW1tbW1tbW1tb W1haWltXWlpAQEZWV0NfXFtcVVdeW1pWXFtbW0VeXl9DX1tFWVlXV1xZX1tXV1tVV1lFXl1eXV1W VlZWX19fX19fVldXV1ZXW1hcWVNAW19ZXVtcVlZWQEBAW0VbUFBQSEhDUFZWWFpcXERDVFhYXF5W WFZXXFxcXFxcXFxcXFZXXl5eWkZBQEBBX11BQVhZQV9FQUFeQUBcXkBAR0FBXlhXWFpcWFtcW1xb WFtcVlZcVkJcXFxcWFlXXFxBXFxaXFVcXUFBQF9BQUBbW1tbW1tbW1tbW1ZWVlZcXFxcXFxcXFxc XFlcXFxYW1xCQkhXWEZBXVxeVlhAXFpYXlxcXEhBQUFFQVxIXFtYWF1cQVxYWFxWWFxIQV9BX19Y WFhYQUFBQEBAVllYWFdZXFleWlVCXEFcXlxeV1dXQkJCXEhcUFBQS0tFUFdXWFpeXUZFVFlZXV9X WVdYXl5eXl5eXl5eXlZYX19fXElDQkJDQV9DQ1haQ0BIQ0NfQ0JfQENDSUNDQFlXWVxeWFxeXF5c WFxeV1ddWEReXl5eWVpYXlxDXV1cXVVdX0NDQkFDQ0NcXFxcXFxcXFxcXFdXV1deXl5eXl5eXl5e XlpdXV1aXF5FRUpXWEhEX15AVllCXlxYX15cXEtDQ0NIRF5LXFxZWV9dQ15ZWV5XWVxLQ0FDQUFY WFhYQ0NDQ0NDV1lZWVhZX1pAXFVDXkNdX11fWFhXREREXkteUFBQTU1HUFdXWFpfX0hHVFpaX0BX WVdYXl5eXl5eXl5eXlhYQEBAXEtEQ0NFQkBERFpbREFKRURARENAQkVFS0VFQVlYWV5fWlxeXF5d WV1eWFheWEZeXl5eWVtYXl5EXl1dXlVeQEREQ0JFREVcXFxcXFxcXV1dXVhYWFheXl5eXl5eXl5e X1teX15aXV5GRkxZWEhEQF9BWFlDX1xYQF9eXk1ERERKRV9NXF1ZWUBdRV9aWl9XWlxNREJEQkJa WlpaRERERUVFWFpaWlhaQFtBXVVFX0VdQV5AWVlZRkZGX01eUFBQcHBJUFhYW11AQEtJVVtbX0JY WlhZQEBAQEBAQEBAQFlZQkJCXk1GRUVHREJHR1tdRkNMR0dCR0VCQ0ZHTUdHQ1tYW19AWl5AXkBe Wl9fWVlAWUdfQEBAW1tZX19HX19eX1VfQUZGRURHR0ZeXl5eXl5eXl5eXllZWVlfQEBAQEBfX19f QFxAQEBbX0FISHBaWk1HQkBCWFpFQF1bQkBAQHBGRkdMR0BwX15bW0JfR0BbW0FZW19wRkRGRERb W1tbR0dHRkZGWVtbW1pbQltDXlVHQEdfQkBCWlpYSEhIQHBAUFBQcXFKUFhYW11BQUtJVVtbX0NY WlhZQUFBQUFBQUFBQVlZQ0NDX05HRkZIREJISFtdR0RNSEhCSEZCRUdHT0dIRFtYW19BWl9AXkBe WkBAWVlBWUlAQEBAW1xZQUBHQEBeQFVAQkdHRkRISEdfX19fX19eXl5eXllZWVlAQEBAQEBBQUFB QFxAQUFbX0FJSXFaWk1IQkFDWVpGQV9bQ0FAQHFHR0hNSEFxX19bW0JASEFbW0BZW19xR0RHRERb W1tbSEhIR0dHWVtbW1pbQlxEXlVIQUhAQkFDWlpaSUlJQXFBUFBQdXVNUFlZW19DQ09MVVxcQ0VZ W1laQ0NDQ0NDQ0NDQ1laRUVFQHJJSUlLR0NKS1tfSkZxS0tFS0lER0tLcktLRlxZXEFDXEBCQEJA XEJDWVlCWU1DQkJDXF5aQ0JLQkFAQldCRElJSUdLS0tAQEBAQEBAQEBAQFlZWVlDQkJCQkJDQ0ND Q19CQ0NdQUJMTHVbW3BLRENFWlxJQ19bRUNAQHVJSUtxS0N1QUBdXURBS0NcXEJZXEF1SUdJR0db W1tbS0tLS0tLWVxcXFpcRF5GQFdLQ0tBRUJFW1tbTEtMQ3VDUFBQenpxUFtbXkFFRXNwWF5eRUhb XltcRUVFRUVFRUVFRVxcSEhIQndOS0xOSkdOTV5ATkl1Tk5HTktHSk1Od05OSV5bXkRFXkNEQkVC XUVGXFtFXHFGREVFX0BcRURNRUNDRFhER05OTEpOTk1DQ0NDQ0NCQkJCQlxcXFxGRERERERFRUVF RUFFRUVeQ0VwcHpdXXZOR0VHW11MREJeSEVFRXpOTk51TkV6QkNeXkdDTkVeXkVbXkJ6TkpOSkpe Xl5eTk5OTU1NXF5eXl1eR0BJQ1hPRU5DSEZIXV1dcHBwRXpFUFBQfn50UFxcXkJHR3Z0WF9fRUpc X1xdR0dHR0dHR0dHR1xdSkpKRHpwTk9xTEpxcV9CcUx5cXFKcU9KTXBwe3FwTF9cX0ZHX0VHREZD X0ZGXFxGXHJGRkdGQEJdR0ZwR0ZERlhGSXBwT0xxcXBFRUVFRUVEQ0NDQ1xcXFxGRkZGRkZHR0dH SEJGR0dAREdzc31dXnpxSUdLXV5OR0ReSkdGRn5wcHF5cUd+RURfX0lGcEdfX0hcX0V+cExwTExf X19fcXFxcHBwXEBfX15ASkJMRFhxR3BGSkhKXl5ec3JzR35HUFBQYmJ3UF1dQERJSXp2WEFBSUxd QV1eSUlJSUlJSUlJSV5dTExMRX1zcXF0T0t0dEFDc058dHRMdHFMT3R0fnR0TkFeQUdJQEZIRklG X0lIXFxJXHVISklJQUNfSUh0SEdGSFpIS3NzcU90dHRGRkZGRkZGRkZGRlxcXFxISkpKSkpJSUlJ SUNJSUlBRkp2dmFfQH10S0lNXUBxSURATElISGJzc3R8dEliRUZAQEtHdElBQUldQUVic09zT09B QUFBdHR0dHR0XEFBQV9BTENORlp0SXRHTElMX19ednZ2SWJJUFBQZmZ6UF5eQUZLS315WUJCS05e Ql5fS0tLS0tLS0tLS19fTk5OSGJ2dHR3cU53d0FFd3Bgd3dOd3RNcXd3Y3d3cUJfQklLQkhLSEtI QkpLX19KX3lLS0tLQkVfS0p3S0tISlpKTXZ2dHF3d3dISEhISEhISEhISF9fX19LS0tLS0tLS0tL S0ZKS0tCSEt5eWZBQmB3TktPX0F0S0dBTktLS2Z2dndgd0tmR0hCQk5Ld0tCQkxeQkdmdnF2cXFB QUFBd3d3d3d3X0JCQkBCTUVxSFp3S3dLTktOQEBAeXl5S2ZLUFBQamp9UF9fQUdNTWB9WUNDS3Ff Q19ATU1NTU1NTU1NTV9AcXFxSWV5dnd6c096eUNHeXJkenpwendwc3p6Z3p6c0NfQ0tNQ0pNSk1K QkxMX0BNX3tMTU1NQ0dATEx6TExKTFpMT3l5d3N6enpKSkpKSkpKSkpKSl9fX19MTU1NTU1MTExM TkdNTU1ESk58fGpBQmN6cE1xQEJ3TUlBcU1MTGp5eXpkek1qS0pERHBMek1DQ01eQ0tqeXN5c3ND Q0NDenp6enp6X0RDQ0FEcEdzSlp6TXpMcU1xQUFBfHt8TWpNUFBQExNkUEFBREtycmhjXEZGcXZB RkFDcnJycnJycnJyckJDdnZ2TW5/fX1geXR/YERKf3dsYGB1YH11eGBgbmBgeEdCR09yRk5yTnJN RnFyQ0NyQmRycXJyRkpDcnF/cXBNcFxwdH9/fXlgYGBOTk5OTk5OTU1NTUNDQ0NycXFxcXFycnJy ckpxcnJHTnJiYxJFRWtgdXJ3QkV9ckxEdnJwcBN/f2BsYHITTU5GRnVwYHJGRnJBRk0Tf3l/eXlE REREYGBgYGBgQ0ZGRkRGdUp4TV1gcmBwdXF2REREYmJichNyUFBQGxtqUENDSE52dm5qXUlJc3pD SUNFdnZ2dnZ2dnZ2dkVFenp6cRVlYmJmfnplZklNZn0TZmZ7ZmJ6fWZnFmdmfkpESnN2SHF2cXZx SHV2RUV1RWl2dnZ2SU1FdnVldXRxdF10eWVlYn5mZmZxcXFxcXFxcXFxcUVFRUV2dnZ2dnZ2dnZ2 dk11dnZJcnVpaRpISRFmeXZ7Q0didnJIenZzcxtlZWYTZnYbcXFJSXl0ZnZJSXZDSXEbZX5lfn5J SUlJZmZmZmZmRUlJSUdJek1+cV1ndmZ0e3V6RkZGaGlodht2UFBQAwMRUEVFS3N6ehUQXkxMeH9F S0VHenp6enp6enp6ekdHf39/dhxraGdsY35sbExxbGIabGx/bGd+ZGxsH2xsYkxGTHd6S3V6dXp1 S3l5R0h5R295enp6THBHeXlqeXh1eF94fWtrZ2NsbGx1dXV1dXV1dXV1dUdHR0d5enp6enp5eXl5 enF5eXpMdXpvbwJKThhsfnpgR0tnenVLf3p3dwNra2wabHoDdHVLS354bHpMTHpFTHQDa2NrY2NM TExMbGxsbGxsR0xMTEhMfnBidV9semx4f3l/SUlJbm9uegN6UFBQDAwYUEdHTnZ+fh0XX09PfmRH TUdKfn5+fn5+fn5+fkpKZGRkeQQSbW0SaGMSEk11E2gCEhJjEm1jaRITBxMSZ09JT3t+Tnl+eX55 T31+Skt9ShZ+fn5+T3RKfn0Sfn14fEF8YhISbWgSEhJ5eXl5eXl5eXl5eUpKSkp+fn5+fn5+fn5+ f3R+fn5weX4WFgtOcQASY35lSE1tfnhOZH58fAwSEhICEn4MeXlPT2N9En5PT39HT3kMEmgSaGhN TU1NEhISEhISSk9PT0tPY3RneEISfhJ9Y35kTExLFRUVfgx+UFBQNDQeUElJcXhiYgMdQXFxYmhJ cUlMYmJiYmJiYmJiYkxMaGhofgwYEhMYbWcYGE94GGsJGBhoGBNobRgYDxgYbHJKcn9icHxifGJ8 cWFiTExiTB5iYmJicXdMYmIYY399YEJgZhgYE20YGBh8fHx8fHx8fHx8fExMTExiYmJiYmJiYmJi Y3hiYmJzfWIcHDJwcwYYZ2JqTE8TYn1xaGJ+fjQYGBgJGGI0fHxxcWd/GGJxcWJJcX00GG0YbW1P T09PGBgYGBgYTHFxcU1xaHdsfUIYYhh/aGFoTk5OGxsbYjRiUFBQUFJRUFBQVVBVUFBTUFdQHeFS UetS7lBWUFdS7+JQVVToUu7kU1BaV1ToUu7lUVBJWFZV71LuUFJQU1F5UFlRO1EOUEh7QKZsrWwe QKRsHa1sUG9srWxArGytbGFgcUFxQXVxQXFRUFRQrHBTkKwQVVCrUHBUkFBSULSvtFGWVTtQXFBI UDjrUvpQSVBZr5AQWWZoZFAQEBFkWOivkBBETnFkWkqoXjdmUBB6ZWT3UOdQUlHoUxnnXVdTXRBD W1HoU2UQXVBQWlRAEEZkWhBUqElApr2kvUFCaX+9UG+9b0C2YWBRIXt7e3tQe1EWFFFzU3ZlZGZj YkZFRFdTYkZFRFZzcnZlZGZROHYIVhN/fxFUPn4REX5+ERFRN1N6ZUpvHBwbSHusYBF9fhERfn0R UFBSUNVTc1LsVTtQXVBKUMzn6EmYSadcU1zor6jjc3VkXOivqON9YGRR6K+443plZFDor5gQTXpl ZElIemVkSmh6ZWSnXFFXXEdcUlpM1V43Zl1Q6FEE41dTSl7oUQTiRFNQ6FNl5F1dWlRe6FNlEEZK SkdBWj1Uk0c9UEFRQdVLTMRxOipIe3umDa2mvUFCaX+9QUJpf71Qb61sb61sYWB7USENe3t7e3t7 USJRU3d2ZWRmY2JGRURXU3FTdmVkZmNiRkVEV1NSEGZGUmh+e2lDaa4yZ0ZlfXxqSmZTc1F0KUlJ b2pqYQUzrotReCp8EGprYXferolQUFJQda+0U4tVO1BLUE9RDhAMWFVXQkhVR0JUQl5HVkFfV0Be R05dSFZBXFdASF1PWktWQVtXQEtaVVlQVkFYWVBXQEldSFJFQ1NER15GR15SRU1TREhdSlJFS1pM S1pTRFFQWVJFVFNEUFlaS0voU3cQWVBZRFBQWV5HR+hTdxBASF1ESEhdRUZGSUlKSlFRUuhTdxBH U0RDQ01NTExUVFPnV0FCQk5OT09VVVboU3cQfVdAX19cXFtbWFhXVl5dXVpaWVBHSEhLS1BaQEFB RERFb17XR/1d1zBIIEhSSOhSXRBHWtdLWddL/VBvUldWVlNfUlFSDHAI9Eh7QKYhbGxAbECkvbRA tKYNtK2kpGxAbEBsUG9sQGxAbG9sQGxAbG9sQGxAbEBsQGxArWxAbEBsQGxAbECkbEBsQGxAbEBs QK1sQGxAbEBsQGzXVX57LUCU135Iey1AlF9fX19fX19fX19fX19fX19hYFENR0NzZWNDcWVxQ2NT cUNjU2NFc1NjRXFTc0NxU0NxQ3EjDfvrFa9QUUMLAwtRATEDD/rpFq+uoA0BC679Dz5RAxiu+0xR lwJRBwBRl65pUZeuaQCu+QKuaVGXrmlSSVEHUFNQPK80U8lV7lB1UHxQZVE34Uxn6FHFEAlDOWZ3 Sn9n2Efcf9lgVWpkG2QPZDZ8KUcmSSV8JmApZdlVxk39Vv1X/0T/RZFjlmWpVaplQ1pJURBYd3ZV VFRxZX1JSFRwRkVidX1UZXZJVVRRQ0ZFSFx3Xu9RwVBFUklQX1BeUc9Qd1Ez5F9fXFVR7FH8UFRR M1BxUcnkcnJPXVHrUd1QUFBFUd3j/0RRROhRwBBGYrLwTFFMSlBnUXBnEGcwZ7BnVGdecOhTdxBZ XVBxMHEgcVNx6FJC4nqyWehRuhBcQFBwUA9QP1BUUElm6lHFUVFQSHseQKQNHaS9pA1srWweQA0h pg0dvaQNvUC9UG9sQLS9vW9sQK29QL20QUJpQmlpQUdpQmlpUUFCaUJHaUFHaWFgEykQen5heHlN TlpbYGF/YVJWfk5iMlF4W3oyUGFNfTJQTk9+fXladzJReHdbXFBAbEBse0BsQGx7UXt7etHR0dFQ IQ1RDXtDY0ZGR0F2d3ZlZGZnZWNFRkdGR0FzdnZ3QUZGRURWV0VzZXZ2d1FBVlZFREZDZmdmZmVk dnc8fFvGxbEbZef6EAJoTfN3XdvbrN+B6hAO8jJRMjQxCP0beGgRH81RHtnCXlIY2zscPSvoQwwM VV5Xbq6Fz8NerlTg9yzagkDQ0FRzeFNKUYFcNx4ZL6zAXUhzIRASJjxQUFVQGK+YVjNVO1BTUEFQ clBhUBFRFRBze1B7U1L5VvZc+UD5dfZ8+WDpVuZc6UDpdeZ86WBcwlhTUlLoU3cQRFFQRFFRUFFS T0VQU25mSxZaQhZa6FEJ5lRTVFBiFnPoUQkQSmoWenpSUlFQU1Fbd2huqmZoAH5RQH4QflJ+6FKO EF0SV2hPqkVoXkkSBApIex5ApB2tpr1Apg0hraa9UG9vQGxAbEC9rb1AbGxAvb1AvVFBQmlpQUJp add+ey1AlGFgSBMpECBVEWR1YHZ1dRB2aHZ8dWx1QHZxdkdGSEZJRlNWXHVNdWNhZk1QEXRuTVFp e2ZNUGt5bk1RQ0FFTVByVU9NUUpbRU1QTFlPTVFlf2JNUW92Yk1RZ31qTVBteGpNUERfQk1RcFZC TVFGXUtNUE5YS01QUHt7e3t7e3t7UXt7e3t7e3t7e3t6e3t7e3t7e3t70VANUQ1RUXNRcWJGRURW c3J2dmVkZmZHclZFREdGR0ZjYmdmZWR3dlFiRkZFRFZzcnZ2ZWRmZkdyV1ZFREdGY2JnZmVkd3ZV IKx0CVOMrAXXxfgmH9QfANsWYx9GQXRFT2ByYmFwU/kX3R36JBnZHx/ZF2BzfX5yYH50YGBxVTuq DVXzsMH+7gf8OTnhB2gokNsZZ05CZB3k7h1jrT4K/Dfh6wr3Ozn+BmVmFpPjF2NnGeLsG2NQU1Ab r7FVq1U7UGFQbVAZUQkQdlAbsBtSQBtRVl5ZS1twRl5LcEkRVhd6P0s/eD9jPxIqS1ZUYlEb6K+Q 40RGZBvor5AQfF5CZHkQY3dgGxN3MlcwTDB5MGI1bSBiJG2KcFxcXXtDVm5iEXlMXF1SelZW6FEc EHJuTERubkxTVHx+fWB/V1FjTHpWfHtuQxFZWWHIUFLIUVFQ6FMB5GgWc1NZ6FIvEFtAF59GRkBb YVBSUehRYONQFXZW7VHxUG5Rl1BJUHlSludMb08bR0dKXehR0xBDSU92UXbRMGVRZetr4T9PIE9S T+hRfRBLFGwPST9JL0nfSc9J/0nvSZ9Jj0m/SVpJSRob6FHT43EECkh7ex6kDR29pA29pA29IkCt HhU1FLYdQKS9QKS9QKatbEBsUG9sQL1AvW+9pGxAvUC9QkdpUUJHaddefnstQJRRQUJpQUJpaUFC aWlAmWFgUQ17e1AhDVENIiFRcUVWVlJXRkZjYmZnR1ZWc3J2d1ZWc3J2ZWRmZ3Z2ZWRnZmNiRkVE VldGR2ZlZHd2d3VmZmVkdnNyVkVERkN2dndWVkVERmNiZlRFUfQHA+A+CdwXFTBEdXX0PQL5NCyX IfWS/qB/ci4yLSfGwegv2uBORnmu0iwrCRIHCXKd1DZtKCnaJW8lUzl1V2+ukto4AxsZS93WCTo+ BeAqKaHRONVt+woW3Tc68A+y7ILAfnRLVVtrxgwYDilqYSmtSeT2KxX2MTvyYlBQUVABU3NRSlU7 UFxQARBLWl7QTjdmW0h6ZWRcaHplZOhbmFuIW7hbVFxQ6FEE51ZTXkdHSllQ6FNlEFpcXFk9U9Bd BPRIe0CmvWl/vR5AFTUUtlBvHa1sYWBRInt7e0NTdmVkZmNiRkVEV1POZkdkfX1rSmZTc1F4K3sQ amtgdcGuiVBQUVAErhpSLFXeUENQahBzxkH3QVLWXNlBUlrIWUFQyFFDUVBQWln4XnIAVlFW0EQE Dkh7QKYNva1sbEBsUG+9b71hYFANUQ1RRXZ3dlJlQFBnRVZWUkVER05SUizHNcDMUWKmK84ecUoa La4/dRw2wVHahFFmUa8+ehS8rsaVhv/a98pQUVB+rhpSBlXeUENQaRB0eVR6WBhVU1DIUUFayFlD UFFRWVr4XnJwVmBWEFZTVtBFCPRIe0CmDb2tbGxAbFBvvW+9YWBRDUNlRkdGQkVAUFdlZmZCZWR3 flJ+yDXfzK6fpyvPHXFJGyxVNHobNsKuJ4Wumq5RPnUVu1E7lYXg2vbKUFFQwVIAUyBV3lACULoQ 3UUE1V8LZule70rjFucCn0qTFo5KhBZYZ1VrXmhfakprdmVnZhZjAlhETUByQGxEEUQSRBN8S3wV bUttFR5LHhUPSw8VKUgjTCMTKRjYSNZM1RPZGMhIxkzFE8gY+kj2TPUT+xmadppncAEZE2lUYhxk FmZUSnt3dE1HQFRPWl1Qd2ZiVFp7VE9vfixybOhR5xBzQmQfLFdQUMhdhUVkT4V3yGaFb29wHGAc nxyAHFQc1QM6Kkh7QKYNbECtra2krb1Qb6SkrWy0UUFCR2lBQmlpQUJHaUFCaUFCaWlBQkdpYWBQ DVEhDXtRdnd2ZWRmY2JGRURWV2ZnZmZjYkZFRFZXVldGR0ZGRURWc3J2d3Z3RkdGRURWc3J3dmVk ZmZnVldWV1ZzcnZlZGZnZmdmZ3Z3dnd2ZWRmY2JGRlG+VEhyYXRPfmVWZ3wUEnJxfRLUHWNkGykb fU5OGW55bVJFdGBLdU5FflxVa3wZdUpMcmB5eUswbmtmGytNfX1OcRo+VEQVFDJ1ZGZmYn3xFHNi H3Z9T3VqTUFGS15GEndOfHoZYXtpEyZ7eGdNRX5g12Nid2ACRkB+TElnQlxEXUlLX0pFcX9LfXov UFBRUHVQ3VQLVJNQW1DPEEp/Un9TcFhwWVR/UHBVcFZ/Wz9QP1tWMFZRVhFfUwFQV1N3UFpTAVBb UFNTd1BSUwFQUFBYU3dQWVMB5ltbUDBVUVXtUwFQVFBQUwFQVFN351EwWFFY61Zb6FN3EEpVMFBR UOtwUmBSEFIgUoBSVXBSUVIMXAgOSHtApg0hpA1srWy0DVB/vbRAtA1AbECkvUCkvUCkrbQNYWBQ DVENdUFxZXFBY0FxRXFBUkeuXlGiAFGkrlzdUaMCUaGuXwKuXVBQUVA+rvtRyFCYUEdQAxB3CVIJ R5RGU1lHMEmASVNZUVBXVFRfWEJQ5kIQXFtUal9FT0XQRVNF6FF6EFtPXw9fUl9JSMz0SHseQKQN Ha0NvVBvvbRCaVFBQkdpYWBRDVEhQ2VmZmVkd3ZzcldWc3J2ZWRmY2JGRURWPjchWVdXW3VCRGFq G2YSN9+u+3xy3wBDXVlEWWpjYRYjDzfhUFBRUANR0FIIUkdQU1BvEHBSVdBNNGYvVVFRUFJQ4FNT UFJAUQBRMFHAUfBRgFFWUehRZOVQ0FQECkh7QKatDWxAbFB/vWxAbGFgUQ17Q3FFcQNSVa2rUkfH UFBRUMGvtFE/UJJQW1B7EExQEFZbUxBZEGplWRBvZQ9ZUc9Z/1lSWdVcOipIe0CmISJ7e71Qb71h YHViRkVEVnNydmVkZlFQfxARfn4REZIRfn4REX5/EFBQUVBTr7RSblXeUFNQAhBZUFWbTzdmUFFR 6FN3EF1SU0RSUlNTUFBSUVtQ6FFPEERwU2BTMFMgU/BTsFNWU+tR/VKbVOhRP+GPSHtApr2kDb1Q b2xvbNdVfnstQJRhYHtRUXNRUm6uRQBRu1XeqgZV+lBQUlAar7hT51U4UEBQdFDq4jFYcOhRVuJV VUXoUVbiXV1K6FFfEEJZSlB2EHZSEHYwdvB2sHZUdkHoUV8QXg9QP1AvUN9Q8FBVUEl16lFOUVFQ SHseQKQNHb0eQA0hph29UG+9b71hYBMpEBxRdHN0cnRSVlJRU1FSVld1TEtNS05LU1ZDdl91W3ZI SUdJUlZxVEEyUE9WSjJRRF5BMlBGXEoyUXRRcDJRS1hwMlFCQEUyUElaRTJQe3t7e1F7e3t7ent7 e3p7enrRQ2RCZ2ZjYkdGQURSVnNyd3ZnQEdGY2JmZ2ZBZHd2d3ZzcldWUhrcJAowzCzL2IMyktE9 lBVpIWYkTn5gdGl5ahRlGGRSzrhRHwIRz5Wu/7yu5sW1kaeuuOHFMSL8UWm4yyNgcW0DrsxQUVCg UFBTVlU4UEZQxxBEEEgwSPBIsEhUUEgQSFImUNZQUl4RQ1E5URFQWVHwUHJQU1E5URFQWFHwUHNQ UFGoUF9ROVBGURFQUFGiEF5RX19SWVJRVVlYXFJTUOpRp1BTURkQQl5eXxBBZWBfL1/AX/BfVF9J R+pSdFG0UEh7HkCkDXtsHUC9tEBsUG9sb2xBQmlRQWlQpb2sUaV7e2FgUA1RIQ1DdWNBREZGR0Vx ZW5SZUFkd3Z2c3JXoFEacUNsDK5SMGhGWld1SnUSVJfxq9ciaE5SdXVSTWEqUozEenBOT1BQUVB8 UFBT+1U4UE5RFhDSV0hbaUdITG1kSBBMbWRJEExtZF9ORkZ5V2xXGVf5V1YQcAtUClgLRwpIO1gk QSRCzFvNXslB/Fv8XplVmUeYSIlHiUiwcKlUqUdFRVFNVElVS0VJRklHTUhXWUdbSFtNZEkXSdlH 33BXSElSUkdKSVxJVl1TSVJVVkhHRkVEV0NUXehROBBZWRBEXG/QWVFZ6FNjEFxAVUrfSVHPSf9J UknqU2NQU1Hd41FSXE7oUd0QXVBWsh9DD0M/Qy9DVEPoUVcQQxBQUVBKUHAQcNBwUzBw8HBScEnr UalQU1BdURAQRA9SP1IvUt9S71KfUo9Sv1JYUklP6lHeUVFQSHseQKQNHbRsvR5ADSGmDR2kDb1A vVBvbL2tDSFsb60he7RBQkdpQUJpUUFCaWlSQF5s10BVLZRelGFgUSEiDVANUXt7e1B7UVNxZVBQ ZWR2c3JWV3NmZmNiRkVEV1ZXUldxYmZmZ1P7D6ywUTFRcM4+NM92dUmfy/WNYBr2qW5RMjwHFkpR Va6rdVESUcj50fYlIemWhMA3N/LlrqBoQGF9UFFQA6+4UwZVOFBiURzpUFqvsOJcaVnor5AQbFxp EVkVWhZbG3JUn1lReXloeRBkMGSfZLBkp1pXUGRREVkvcyp++nTpdOp+mX6Pc491i366crl1XBlY eehR3ON4eEBQ6FK044BgUWDoU2TlU1VARlFG6FHP5U0Qe39kTehRE+NAXXl461E4UERQWVKzEFsA cNBwUsBw8HBScOhTY+PgXFFc6FHAEFsAfdB9UsB98H1SfehTY+UPVy9XUlfoUrUQWhBkUfBkkGRS ZFDoUW7nEEPvQ1JDSWPqUU5RuFBIex5ApA0dtEANIaYNvQ0hpA29DSG0QKRsUG+9e70ib70NvUJp f71hYBMpEGZ+f052Wl9UVnJxc3F0cXVxVFZVdV52dlpwMlF/VH0yUU5fcDJRcVt3MlFaWX5WYDJR T11NMlB7e0Bse1F7e3t7e3rR0dHRUA1RIQ0iUCF7e0NmZmNiR0ZFRFdGRkVEV1ZxcnZlZGZjYkdG RkdGY2JmZWR3dnd2dnNzZW5SZWR2c3JXOGrh1PMHEuot0CDCrrvZM39xSUpBKEd1ejbHc0pPe8Ye cB/PGNEwyzhUGtnFOh8KxM5h5ivg0fgUd018WFVvVlvOPB8baE14EU5aDtQfNy/2UFBSUHBQUFPp VThQWlBdUIcQeEZdUV9QFV0QX1MQX1F6XFFFV1FSVlFTWVVWUVRcW11QVFxdVFZcXV3oUUwQQldY RFdXWFhTVFdWXFhQT11RXetRzFBWUFtRzxBdVVFWWVhWVlhVVFxcVOtRGVBTUFhRNhBbWVlfU1HP U/9TUlPoUacQSFFvUFFQSlBfUTBf8F+wX1NfVhBXUVdJXupR3lFRUEh7HkCkIWxADSGmDWwdpA0h bEC2QK1sUG9vaX9AbEBsQL1ArSJsQWlBaVFBQmnXfntULUCUUUFCaV9fX2FgUCINUQ0hIlFFc0Fz QXFlUWNBc0FRU+nm9a2SUiU+9a50UaTerspRNtBT0qzcUvGtD1BQUVAyr7hTKVUcUHFRVhAT9FRR QglOOU4vVS9WL03cVN1NV2VSZXEFUwVwB3E7TCZVKUzXUtpK2kzzU/hZ8HOwc19Qc1FfQEFCQ0VG R1hEXVJTU+hRTBBBcHFEcFNUcHFKS0xTV0hUVVPoUc/jcHBxQ+pRqVBIU0MQXF1dUbJQUrJxcVBU UOpRblBLURfl0FfwV1JX6FGlEFoQc1EQczBzUnNG6FGp5kBS8HFRcVPoUc8QWXAQQPBAUkBJcupR xVG5UEh7HkC0DR1AvUANbEC9QA0hpg29tFBvbEC9QL1vvb1CaX+9UUFpQUJHaddYfntVLUCUUEFC R2lhYFEhDVANEwwIEFs7VD9CNE4gVSBNVQ0JUQ1RV3FXVEdGRURWVldWc3J2ZWRmY2JGR0ZjYmZl ZHZ3dndRUykerjgJUVnL1QfUASMpKj9+c0p3fxsdJeHO2z3sUVRVHPrmd87Y6Dvm0HdnA2JMe0Bx ZOEvK4VqfVdSX1BQUlAIr7hT4VU4UEhQeFC9EHolWSZaJ17SWYl1uXVWVlNRLVMqVCpG1UdUbFh4 VlVTc0l4SVZTcA9YUVjoURPmcHZRdnZfUehR3eNIUFVw6FFW419dUVDqURBQc1FfEEJbSlB6EHpS EHowevB6sHpUeknqUW5QS1FfEEJQQ0BDcENgQxBDwEPwQ1dDSXnqUU5RUVBIex5ArA0drbQeQA0h ph29pGxQb71vbL1CaX8NvSJCR2lRQUJHaWFgEykQfEx1WUJNTE5MUlZBdV12dVlzMlFPQEsyUHFe czJRdFp2MlFMQnAyUHJccDJQUHt7e1F7e3t7e3rR0VANUSENUUVeU1dmY2JGRURXVnNyd3ZBZEJ0 ZmNRVkVERkdGY2JmZWR2c3JWU8bU9/M7dMDB25w3LJzbMe7CUV+oO62cQhcWYxkH2dgtdgdVOHVd H/KX2TOw4Prc+gzjUU3mURiuCK0U1wMwsRJ/9Mj7qnBQUFFQHK+0U/VVHFBbUP3pUFSvsONDS25V 6K+wEHtDS25JWFFVU3pZElAQXTBd8F2aUZlSiFGIUrBdW0pQUVtRUF0QXVNSVVRU6FHDEEpTUkRT U1JUU11VEBdlVbJRVhAXZVayUVBUUOhRyebwW1FbSVxV6lK4UFNStxBcUFRAVBBUAFTwVFVU7FK2 UFxRTlFRUEh7QKYNvbQeQKQNHaRQb2y9e0C9e29s11V+e9deLZRhYFEhIg1QIlF7e0NxRVFzUXFy V1ZXd55Sh65sIFHFrtshYARjTVUcdqruVJVLfjBbUFBTUCyvuFPaVThQSVB2UGNRKhDqCVFRWWNP Y3p3P2MqctBb0FzQStBL0nXQdtpj+Uj1Svd141zkSud263eVWpVbh11GV1BaUVZdUkpZd0ZdR0p1 XXVeG1HcUdNd1V75UF5rUGpRG1AbURl4D1ELdwxjOlA6UTlSN3Y6dzhjK1EsdyZ8LGPfVN9V0FfQ WNJB0kLfRN9GyFTGWMRBxkLLRvZ2/Xf9Y+hU5li5W7pcuV65d7lieVddWXdqUGlRaGJVFFhQXEp3 VFBcSndUQEdw6FFW4lZVfehRVuJDXU0RWVFfUFlREFBZURBQYFFfUEBRNhBAUGUQZVIQZTBl8GWw ZVRlc+xRX1BTUW5QelFfEFpgRxBHwEdTR0lk6lG+UblQSHseQKQNHb2kvUANIaa9tKS9UG+9b71B QkdpUUdpYWATKRBie39OckFGVFhFdXFVczJQT1dNMlF8RHoyUH5CYDJRclRwMlFOWHAyUXtGfTJQ f0F9MlBQe3t7e1F7e3t7e9HR0dFRIQ1QIQ1QIlF2dmVkZmNiRkVEVldGR0ZFRFZzcnd2ZWRmdWZm ZWR2c3JWRURGR0NWVkVERmNiZmVkd3ZR2fENnPn0mDz74GkciuGRPAYpUWEoECY2NtBlYWYDAN09 PNJ2F1L71PAG1O/iIhzOO9geNiHfmykxIwrhhjwtHzknJh9kOH+utxb1MNHLKgcYaTpQUlABr7RT +FU4UEdQd1FcEGMrd4lVh3KJd1Q4VClVLVgqWSdcKF0pQydw21jTQ1pZWN95UmtYVXdIcXdIVVNO dVRQV1XqUTNQSFEQ5HcAV1FX6FETEFl/dT91UnV1UE7oUVbiXlVR6FHc5EdHUF1I6lFuUEpRX+dQ QkBCcEJTQuhRNRBCUHkQedB5UxB5MHnwebB5VHlR6lEQUHFRX+cQWu9aUlpJeOpRTlG4UEh7HkCk DR29tEANIaYNrbRQb2xAvW+9Qml/Db0iQKS9QUJpQUJHaVFBQmlpYWATKRB6S3RYQVx2QHVMdnN2 T11xMlBNX0oyUXRYcTJQcFtOMlFLQU4yUXJZdTJQUHt7e1F7e3t7e3t70dFRIQ1QDUdlZmZCZ1Zz cnZlZGdmY2JHRkVEUldWc1FmZWR2dnNyVkVER0ZjYmY80rCBec0v35w2K5b3J8KOlvHuUmNCEikd CdYJEQ9+Lkx1UiVRdP81jefi2/na+6uyrinROlLp0h4xsSjwzoMnBnxQUlDgr7RRwFPgUFtQR1AS 4VNJ6FF1EE1dN2bASfBJUlYQUFdcEEJbXxBFUxBZZMBF8EVSRexRdVBIUIJRUFBIe0CmDaS9QL1Q b71vvWFgUQ17UWJGRURWc3J2ZWRmQ2JGRURWc3J2ZWRmUXF+ERF+fhERfH8REn5+ERFT4BF+fhER fn4RrUMSfn4REX5+ElBQUlDervtR6FPhUFtQc1AzEEtxdZFBN2aWX5RyUlxdS0NFQFlc5khcVhBQ V0ToUx4QT04QSFtTEF9ZT1lSWWZLQGpfcU9x0HFTcZhLSXQ6Kkh7HkCkHa0NvUCkDb1Qb629b71/ QLRRQUJpaUJpaWFgUSF7UWJGRURWc3J2ZWRmU2VmZmVkd3ZzcldWc3J2ZWRmY2JGRURWUUp+ERF+ fhERDjchWVdXW3VCRGFqG2YSN99T4RB+fhERfn4Qqqp8ct8AQ11ZRFlqY2EWIw834VBRUHdQ61QL VMRQVlCFEFtnU1FHUEhWUlRTU+hTdxBbVlVEVlNSVlVSU1PoU3cQWVBRRFBTVFBRVupTElBQUxLi U3BSEVlRFFAQUFFSiVBTUolQcFBUURQQfhBVUW9VP1UvVdBVVFVSUVFUUFUQVVLAVVEAVTBVUjBV 0FVSEFUgVVJQVXBVUlXqUgNQU1GhEEZQX1aAVlIPVt9WUj9WL1ZSVgxXCA5Ie0CkDQ0hbL2sDQ0N DQ0hbGxAbFB/DSG9SkmtrUpIvUpJQL2911h+SHtULUCU11h+SHtULUCUYWBQIlENQ1FFUVFFUXdU ZKwyU86rnFKSUYIHrj6uOgpRhlBQUlB1UYtUDFMjUFNQV1As4VZX6FN35lUfVA9UUlTuUxxQUlBT U3dQUVBQr9AQa2plUFDQUFIAUNBQ8FCAULBQVVBWVlVVUlJAUVGAUVFgURBR8FFTUFFAUXBRU1EM WVdUVFNTUAxYCA5Ie0CmbEBsQGxApg0NISJsQGxAbFBvDSF7bK1spg1srWxhYENxRXFFcUVxdVRn q5lUZ6uZUyMCpAJQUVB1UOtUCVTEUFZQtRBdSFBHVlJ7U2lTUlRTU+hTdxBbVlVEVlNSVlVSU1Po U3cQWVBRRFBTVFBRUOpTElBWUxLiU3BUEVlRFFAQUFVSiVBTUolQcFBSURQQexBRUW9RP1EvUdBR VFFVVFJfUR9RUj9RL1HfUc9RVD9RUV9Rf1EfUQ9RVFHqUgNQU1GhEHhWUFBRkFCwUFIQUDBQwFDw UFRAUHBQYFAAUFRQUCBQ0FBTUAxYCA5Ie0CmDQ0NDSFsvawNDQ0hbGxsUH8NIb1KSa2tSki9SklA vb3XWH5Ie1QtQJTXWH5Ie1QtQJRhYFENUCJRUWVRUWVRVAmrnFPPrDFUZFLdrn4GUcJRxguuelBS UAyvtVNrVTtQclB+ULjlWVhfYFJS6K+wEGhgZWR/YG9gH2APYCxZ21n1XPVK80tZdlhcXV5TQEZT VXFPVFFfXkNaVlVUU0BXUlNxU3Z8L0NRQ+hR5uVaFklTUFHoUwIQS3MQeVtROFBQdnxX4Y9NUV9N UU3XdkA9RrZ8YOhRPed2EHB8YHxSfOtSXVB/UGBRZ+NxzApIe3umDa22QKS9QKQhIb1BQml/vVBv raZsb729DVFBQkdpQUJHaVBBQmlpQUdpUUFCR2lhYBMpEEpHTFhcS3VbSF1NUFlKV01RXEdaTVFY TFpNUVB7e1F7e3vR0VENe1EhUXNmZmdmZmVkdnNyVkVERkVEVnNydmVkZmNiR0ZFRFZXVlZXYkZF RFZzcnZlZGZRlnlXYR1sdNcyBzRsfnF6FZL2njEYEQvBEUV/ERJ+fhERURAu9cMhKW4vxgJgdTxM dGEDGiH+KAg7Gco49NmkEX9+ERF+fxFQUFJQMa4WV3xV3lASUARRjRA69lD2EbwRU1BJUExASUVM AEkFTCZGV1FAUHi4ULoRsAamFVQIAPZF9kaABlRwAHABcAIPSFRxUHBRcFJwH1Q4UDVSN03XUFQp UNpQqxFT4VgREhJjElAfAmESEVJQVFtUSnofEWNSVBNLUOhTEhBZQG5RbjhQE1ET6FMS5xJfFnZQ EldM61MSUElQS1MX5RzRZk4WR+hTARBmVxZ+ZGZaAjdUaGFhBQZbFnpvSv1wS2BLEEtTS0oGaWhf GdAZUhn4Q2pwcmByEHIAclRySQUG6FGJ43HMDkjoUWfVe3sepA0dva0NvR5Apg0dvaS9QUJpf621 UG+kraS9QK22QLVvb71ApQ2tDbVBQkdpUUJpQUJHaUFCaUCZ10BebGFgEykQaxQbZ21VYBcYFhgV GFNWa2psalJWfHZZdUV2cHVBdXR2eHVddhRtGSRQG2cZTVBWf1RNUFh9WyRRRk9D6FEl41BITUro USXnUUxLSUpAdUPoUSUQTVBed1skURhqEyRRGmgcTVBVYFdNUFp7VyRQRHFH6FEl41BJTEfoUSXj UEJzX+hRJeVRXHlfJFFQe3t7e3t7e3tRe3tAbEBse3t7e3t7e3t7e3t7e3t6etHR0VEhDQ0NDQ1o aFANIVFTVlZFREZjYmZCZWRSdHNyVFJFREJUY3BQQ2NSUHFydFJlQEJQY2JUQkVEUlZzcnZlZGdW VnNydmVkQmdmY2JGR2dXcldWV1ZFREZjYmZmZ2ZlZHZV0CURTHtwGZ3C9a6D5reuJLebUSCEUVdR +SRqCq52roG+rjiyqFHvq59RHf7zrNkcHULE4hQXPu3MIwsTCUBxkhsdIQBrF3xq0NxwaBlT7q4h sCh0cHzCURji+1Fyy6WuZKi2rtiRUUpRX66+rvyxUc2oUVhRmVFR+67n6eeuyfQYEWgL4zovOsFR OCEDFRU+Qx8klcAIbx8I5wzPNBIeUFJQQFBQVeBVO1BMUE9R/BBLWF5fX11AWk5ZTwBxVkVfQ0BK QUpLS0xITVZx6K+Q4nVlceivkONgCGRx6K+Q43t+ZHHor5DieWVx6K+Q43B2ZHHor5DjSk5kceiv kOJHZXHor5DiRWVx6K+QEMdAQ2RdX1tAWk5pXxpfFkAZTh9xCV8HQAVECE46XzdAOE4mQNBU117a X9dA10LZTthPy1/LQMlBy07pX+lA7UrpTptfmkCYTZpOi1+IQLtfuEC4TqlfqECpTalOfFlfG0tS T05RUU9OUlBNTk5MWV5aS1lGTEdLRlhSV0tYRUFES0UoTl9AcEBOTExyQUBEQSBBUUFAX15e6FKZ EEFSTkRSUk5PTfVQUCBR0FFSUehR5RBcWEBfU0VGRlhYWVhM6FGqEFlfQVFBUvVeEEHoUmDjH05R TuhSvBBecBBeAF6gXlNe93A72kh7QKYNSUqtDb1ISkC9QA29UG9sQGxAbG9sQKQNbECtbNdefntV LUCU1w1efkh711UtlHtIUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQ10AtlGxXbGxXbGFgUSENe3t7 e3t7e3t7USINUXFXVkVERkdFcWVmZ2ZnUWNRRkZHRXFlZmZlZHdbUlP5raMMcmsyrgUFSWNuUY1z UYhpDQOtuQFpeD62vFGWhh93T39XdXVfSGDDVAyryNgBVXV1VH5xfA9RXVJ0rYxQUFNQclBQVLZV HFBOUHtQaFIJEGAKUApO2VDYTtljyUrNd/xK/He5Srp3t39caFAqdyljymLJY/V0+mOISoh3iHha VGroUrfjXzdmauivkONMcmRq6K+QELNFR2RjEHF8ZGMQSU5kYhBzeGRiEEtNZBR0FHXZSolRhnSK Y7V1V1R0UXVdYkBTRVZLSkRORnRGeEVgfmIVdBpkB1EISQp3xlJBQFBAagVRCnQwaiBq0GrwalhK YEpiAFBTQFdKdE54SX9UVlJTTkdOH2PYdMp0iWNXcGoQagBqM1IzUzBVMFYwVzBgJlYjSiNLIE4k dCN3KnjUVtZL1k7fY9Bqmn+Kf7t0qnRJCVhfT0tZcXJAT0tGcXNjdFBTVHxQZXtPdFNyeWh8Y1N+ cnhlZVlGeXhHR0ZSfnhYWFlYwHZRduivkOJqZXbor5DiEmV26K/Q428RZHbor5DjExZkduivkBBE EmV2HA9MUVpOYExSTAVUe09ofGHor5AQQBVlQhBU8FRSUFTwVLBUU1Tor5AQWl1BZFBUUXBUUVTo UYHmfHJAX85pauxRgVBxUDFRSFBIe3sepGwdva0NIXsNIRMI6VBhU325S+lQYVN9vQl7QGxsbECk DSK9e3t7e3siUG9sQL1vbEC9QUJpf71CR2lBQkdpQWlRQUJHaXt7YWATKRARf2RzeEhOUVdKS0lL UlZWdnR1UnVjdnhIdmNRf1dhY1FzTnZjU2RRYWNTd0t5Y1FgVX5jUHVNcmNQTmJTZWNRUVBAbHts e3t7UXt7e3t7e3t7etHR0dFRDSFRIiIiUCIhUHt7e3tRe3t7UA1QDVFGR0ZFRFZWc3FlY2JnZmVB ZHd2c3NlcWJHRkZFRFZ1RkZjYmZmZWR2c3JXQUZjYmZlZHZ2c3JWV1Pi3RYx0I+1rdBjBXVHTXcd Y1Ia9DPGziytK3UPacLDHpLqNAAkIeXuBpLfbghLUuROEgzVNekFdWZzIlM8LnF8dUh05yc28V9X V2/SHSf4Rqs/S/MoH8IEVFVQUFFQGq+xVV9VO1B0UKsQEllOf1F/Un9Tf0/GX8lO81/zQuZf50Jb WE5RRkdRLVMrRShG3VPaRs1Txkr8U+tTWVxTXlRSTRhTCVNVf1hAQXRLUOhRVeVSS1FR6lDoUxvm cMpVeExTUehSj+VBe+BAUUDoUxHl313PXVJd6FN/EHlEWVL8UFFRUWJA/P9BUU9Bb0FSQUoQdlF2 WWxwSFFfSE9IUkgZdTQzSHseQKQNIh29HkANpiIhHb2kIb1Qb60hpA2ktm+9vKS9UUC9pL1AmWFg EykQcEVLVlxXdUp2W3ZGdVZLWX1QXEVZfVBYSVV9UVpHXX1QUHt7UXt7e3t7e9HRUSENUCIhDVFD c3Z2c3JWUkVEQkZjYmZnR1ZUc3B3dmVkQnRjYkdGY2JnZmdUgU9Pbrbx14otJr3I1JopTzauoOuu /+na5lFv7cPfekJLREpbVTuuY5/m2a6Ej+iuosAh+ETl+KrqrJtRBOsYRkNLYFBSUHNQUFUpVRxQ RlBxUJ8QC1tLW03WQMVAhUBVJkAmRNdAyEPJRZlLmU2EQFhIQUJETU5TV0VR10rYTlJ4WFZPS1Bx cldPS11xc0dxSU94Xl5dUkl4RkZQWExsH0JRUEJAQnBCYEIQQlVCGXPor5AQSm9lEHNRcHNRIHPw c7BzU3NxR3JXVs5yMTNIex5ApGwdrWwdQA0hInumDSIdvVBvbEC9b2xAvUFpaXt7YWATKRBMSk5f RUB1RHZOX0wGUUpFTAZRTUFPBlFLQ0kGUHt7UXt7e3vR0VANIVEiDSFjZWNiZ2ZlQWR3dnNzZXFw VEJFQFdWcXdGY2JQQUBQc3JXc2MGdEZMdx1jUnhRYFFtkfyRriWLLwa4UWKunqAKI3VncSNTPC9w fHXaru6DrrXuhDJMURZRR1FJURRNUFBRUHpQUFTkVRxQY1C/EAUQZTdMJ0zLYPlI/GDrYLBlWAZJ IFYgVy9YL1nQVtBX31jfWVl0T0tNcXJ1T0t7cXNYcV5eT1lLWFdxUlJPVktXTEBLUlFzXl9fTWNQ 9Xt+UH1AfVJ96FKDEBh8fHtSRUT1TUu4TExNWFn8WFhW/G9XL1dSUFdAVx9XU1cmfvx8e099f31S fTxK/HBLEEuPS1NLAwBlIGXwZVNlUEBydXTOZLDpUddQSHtApmytbEANpg29pA20raYNDb1sQL1Q b2xAvECtbG9sQK4NbECtbEJpf2ytbFFBQmlAvbxQQKVRQL28UECle3thYFANUQ1RQXFiZ2ZnY0Fz dnd2dnNxQURGRmNjYmZnZmdjU3FlY2JnZmZlQWR3dnNzZXFDc3Z2d3ZzUfxReiR3ZFZ1dV5eQgIF roZAeGi2IzhgbhF4Jau7YGB7cEdKdARgVEVfd0VjYng1VVKtuHN+JK54M0xzeK4RCndHcH9uLa78 dUdAEDNTIdFOeHWuhzsARV9QUVBxUFBUT1UcUH1RUOF4f+hRThBndTRmWVRZWuB/U8h76nuWe4lT g3u5VLlaq1SrWlkgVSBWL1cvWNBV0FbfV99YWFdaWXpSV3FcXOhRdhBdWEtXTU9LR3FyVnFSUuhR dhB5VUtWXk9LRnFzTk9LdnFze3x4WlhcVFVSUlFzXF1dR31Qc3ZQeEB4UnjoUoMQdXd3dlJGR1h3 e3j8UHlRUHlgeRB5IHlUecBWVk9XUR9XUe9XUVfoUeUQWlBeck5Nzn4xM0h7HkCkbB2tbKQNISJs QKYNIa20UG9sb2xAvg1ArWxCaX9srWxBQmlBQmlRQUJpe3tRQL28UECte1FAvbxQQK1hYFAhDVEN IXtRQWNiZmdjQXN+UnNzQURHRkdGY2NFcWVjYmdmZUFkd3Z3dnNzZXFDc35Sc1HzpwUfXXV1UXcV FKddWnB8YGGt6mAEdkhdWk97YWBToV1zShU1OlVSrbsbP65lHxp1rgY3cUlCSHV1YXAqUzw3cUlC SHWuhg8JeFBQUVAYr7FV+lU7UGRRdRAEWlQWflJJd0p4UkBIQElScGYQZjBmKFggSCBJKHrASMBJ 4EjgSVt9fyZb11tTSGZ+SgBmIGbcVP1UsGZUXFPWW5BmUxhYTk9LSKNyQk9LR3FzZEtQ6FFV41JL UVHqUeNQUFMbEHthynxHSEhyVnh8U154cllRe09OckFBAELAQlJfQh9CUlBCQEIvQq9CVEJC6FKo EEBabAB2UV92T3ZSdhllNNpIex5ApA0iHa2mfw0hImxArWy0UG+9b71CaX9sQLykvVFAvaS9e3th YBMpEGRwe1dAWHV4d3l3endTVlx2dHVfcUFrUXBPQEFXe1p9UF1zWn1QQHBea1BZd1Z9UVt1Xn1Q e3t7UXt7QGxAbHt7e3p70dFRIQ17UA1RDVEiUCIhUUNzdnd2c3BXVkVEQkZjYmZnQWR2dnNlcUVz cldWRUFWVnNwd3ZlZGdmZ2ZjYkZHRmNiZmdUuXNzZQQp7q6t1yHGo9Ab3BFPEQJSXUkeTUQjsNmu J5zJBjbixZsaKT9oQ0NLU1U7rgTwASWd/b+SrpDFdnVR2DZvcXZ2ZHU9rjFuaqztp+P0kzkHSHlF c2NQUVBzUFBVzVUcUBVQlxAhIBfwF4AXsBdUQxfOTBBmABewF1JCT0tbcXJyT0tMcXJkT0t+cXIV T0tucXJST0tacXNDT0tLcXN1T0t9cXNlT0ttcXNRUHNzdHRLbm1tW1taUn59fUxMS1hCQ3JSEHJR j3JRcHJgciBy8HKAcrByVnLoUnAQSkAXMBeQF1NwF1EXFXVyZQBkMGRSZM4WMYxIex1ApCJsHa1s QCEipA0hImytbFBvbEBsQGxvbEBsQGxCaX9srWx7e3t7e3t7e2FgUQ17UQ1RcUFkd3Z3dnNzZXFF c3JXVlZFQURHRkdGY2NFcWVjYmdmZUFxQURHRkdGY2NFcWVjYmdmZUFkd3Z3dnNzZXFFc3JXVlZF UfVSJl1acHtgYFIUYGB7cEddWk98YGCt7GADdkmt2l1acHtgYa3rYAR2SF1aT3xgYFIVYWB7T0hS h1HUOHFJQkh1dUdAETSsxTdxSUJIdXVhcCpRza4zN3FJQkh1dWFwKlM7OHFJQkh1dUdAETRQUFFQ Y1BQUihVHFBPUCsQDXEQeGVJcTFBNGZYT0tScXJIT0tCcXJJT0tRcXNZT0tBcXNCQVJSUVhISXJZ IFjQWLBYU69YUWBYAFgwWFMPWJBYgFhTWDFwIHHQcbBxU2BxAHEwcVOQcYBxUjGMSHseDSEiQKQN ISEibB2tbFBvbG9se3t7e2Fge3t1RXFlY2JnZmVBZHd2d3Zzc2VxRXNyV1ZFQURHRkdGY1Ioretg BHZIXVpPfGBgUhVhA3ZJXVpwe2B1dXVhcCpTPDdxSUJIdXVhcCqsxDdxSUJIUFBRUHqvsVNBVRxQ c1DiEGsVQlEPQw9EUjRHIEfVXPtfkHVVQkhRYHUQdVJKWFhPS1Jxck1PS1Fxc0ZITEBGSVJRUmBE EERSAERRROhTWhB1SXhdWU1McllZYFgQWN9Yz1j/WFXvWI9Yr1hTWEp1j0BRQLB0dehSYeNxsPJI e3setA1Apg0hbB1ArWxQb729DSFvbEFpUUFCaWl7e2FgEykQQEpLWlxKXExrUVtaS1tJa1B7UUBs e9HRUSEiDVANIUNlcUVzcldWRUFEVlZzcnZlZGdmY2JGR0ZjYmZlQWR3dnd2c5xSFWEDdkgT9CQO PElxfHBjd0d0S39dWnB7YFV3dXVhcCqtOcnu3Q1sYUlPegtmEgRTzjdxSUJIUFFQclBQVYhVHFAT UhAQoSte7l5SPFBRL1AlUiteJmApZSpm71rqXVg9UFFCVBV+QTRmZlIFUjVS0FLZEMBSyRDjXeRe 6mPqE4Vdh2JdQltRU15SVlJVYttQ12LOUPxR8F6BYlhbUFFRUFJVXE9ZTl16UHVRf1lvWR9Z3FCW ZIlQomRfWVtJW2BRZVJjEBIQABX2UfNS9RDmUuZa4BKdUIxQgFGEUoZTu1C7UaBRpVqgXKJdSEZj RmRkYmBkBFHJUMRdxmLFZFlWXVdLVk5PS0hxcn9PS3hxcmwRbUtsVVRUS1VfT0tHcXNPT0t3cXNr ZGpLa1FQUHJeXUReXl0RUFDoUpkQBGBkRGBgZFBRXWQRVRVgUBFkVGpdUVJcW1pZV1deIF7vXlJe dldUV1dGRkn8SGxra3h4d21qanl5dvx3SEdHVlZVd1JVWGzDVF5gYH9U0FVRIFVRVehSaBBcEF0A XVLQXVHgXVFd6FKp539fck9OzhQV7FFsUHFQMVFJUEh7ex6kbB2tbKYNISKtDSFsQGxAbEC0UG9v QGxAbEBsQK1sQGxAbEBsQGxAbECtbEBsQGxBQmkNf0JHaUJHaVFCR2nXXn57LUCU115+SHstQJRI UEC9UUCQe3tAvVFAkFBAvVFAkHt7QL1RQJBhYFEiDSFQISITCBBZf2N9EX8SfRNUDQkNexMMCBBa ZkhGXW9acERpYuivsOZAaRBAXmlR6K+44l5pUOivsOJeaVHor5DiQGlQ6K+Q4UBpUHt7e3t7e1F7 ewlRIQ1QIQ1RUUZGR0VxZWJmZWR2d1FBREdGR0ZjY0VxZWNiZ2ZlQWR3dnd2c3NlcUVzcldWVkVB ZmdQZ2ZlZHZzc2VxRV5SV1ZXUjRRpCv+B60ramNDZa58XVpwe2B+re5gBHZIXVpPfGBgUhJ+f3xP SEQlUXluS3piT1GifBg4HEblUqCuXysJVnV1d0hIdmRRn64bN3FJQkh1dWFwKlM8N3JIQkh1dUdA EDSuMUM8UUALeE5Hc3V1UUZvFkTpUFFQeVBQVOdVHFBwUNYQS0BQQFFwUHBREHIHUjdSJ1LacMlw +XDpcFxRcuhR3hBjXjRmBVIMTlJZT0tTcXJGZ0tBbXJaT0tAcXNwT3BQYFAQUFNQt0xBQFJMc1JT WFD8UTxS6FKUEFtGR3JZWVrOcTENSHseQKRsHUCtbKSkvVBvbL1vbEC0DWlpe3t7YWBRIntRDVFH U3FlY2JnZmVBZHd2c3NlcUV2VlZFQURHRkZjY2JmZlTGcSSrtmMGdUVMdx1jUjY8B3BAXGLTM8wu OFEnV67AdWhwJFM7L3B8dXVRehAprPwDT0VEfiVQUVByUFBWolUcUGBRkRC4X0hRXlBYR15JXXhf eV96VGBXQm1RbX8JSD9ROEg9fylIx1HKf5tIiki4UbtIXV1IUVpHVmAWYFNmSGZgF0hTRmB3SHZg U1ZIVWBHR1N7UHlIdmBrUGpHaUhlSWVgb2IfYjhQKlAmSClJJGDaUNlI1WDJUMdg+VD2YPBi4GKc R5lIkGKMR4lIgGK9R7pIukmwYqZQqkenYHUYURlHFn8KUQlHBn86RyhJlkiVYIZIhmC1SLVgXl9P S1lxcnBPS0pxcn5PS3hxclJPS1hxc0BPS0Zxc3FPS3dxc0dISHJQUURQSElQUUlISOhSmRBuYH9E YEhHYH9If1F/SFNGR0pJSUdSWVhYUFBgYHd4WGALUFBSSX9+cnBwcfBx4HGQcYBxsHFWcc4QYlFi UVLoUpnmQF/OYTGMSHseQKRsHa1sHUANpg1sHa1sbEFpf65Qb2xsQGxAbEBsb2xAbEBsR2lRQWnX WH57VS1AlNdYfkh7VS1AlEh7e3t7e3thYFENDSEhISFQIQ0TDAgQS39ARFxvUUBEXG9RQEBpSEhB aUhAQmlQWEhpR+ivgOVHaUdgRGlRe3t7UHt7e1B7ewlRDVANcVFBREdGY2NFcWVjYmdmZUFkd3Z2 c2VxUVFxRXNyV1ZFQURHRmNjRXFlY2JnZmVBUVMWraRLdQBgrnhgBnRGRF4bA1HQUbxRtFHQfwd0 Rkx1AH+tkGAHc0atpVQlrCYtT3p1dWRwIlMmCnhNd3Wri1R1dWRwIqzaLU96dXVkcCJT2qvbUFBR r7WvulX6VRxQd1HaEBvaQlFC31FRUhAfZd9SUUJNUlF3Un1DaEMoQ8hSj1KvUldDcnJCQE9LWnFy cU9LS3FyU09LWXFzRE9LSnFzQkJBUVJSckJyREJCcnLoUfIQX3f8UVpZWVFSS0pYQllTUuhSmRBe QgNBQXBAYEAQQFNAznnor5AQQG9lEHlRcHlR8HmweVJ5Q0ToUpkQXnFxYHJRkHJRckl4MfJIex5A pA0hbB1ArWwdQA0hInumDWwdQLatbFBvb2xvbEBsQL291357VS1AlFBCaVFpSHt7e3tXQGxhYFAN IhMIEHhZQklCeVFvUGlCH1AaQg9QCkI/UDpCKkLLUflR61HlQptRqlFCv1JRUA1RDQlQIXtRIRMM COlQUq/4405Cb1Lor5DjRl1vQuivuOZHaVEQTGlC6K+44kxpQuivuOJLaULor7jmSWlRWEhpQuiv iBBfQmlCRkJpUkBFaVJASWlD6K+I4ltpUuivgOJbaVLor6jlRGlSEEFpUHt7e3t7e3tRe3t7e3t7 e1B7ewlQDVNxUUFkd3Zzc2VxRXNyV1ZFQXNRQURHRmNjRXFlY2JnZmVBdnZ3dnNLUSBTbUx1AH9R iGAGdEZ0rNJLdh9grnh/B3RGa21rTWtVHKxXU14tT3p1dWRwIqvZVBSs7S1PenV1ZHAiU/8VfENZ UFBSUBivsVUoVTtQXFBLUOEQYcdC+Ff5WvlAVCdRKVfXUdhXVBNYXXhQU0V4VllIbE9Tf1NSUFNA U3BTYFMQU1VTGU3or5AQSm9lcE0QTVJNQWxAWXBZUl9ZT1lSWRlMNDNIex5ApA0iHb0dQCF7pg0i Hb1Qb71vvWFgEykQYlFLX3Vbdkp2Q3ZeXEF9UEtRSH1RRFdBfVBGVUh9UUBaXX1RSVJdfVFCWEV9 UEdURX1Qe3t7e1F7e3t7e3t7e9FRDQ1RcFBBQFBxcFBBQGdmR3JXVkFAR0ZjYkJBQHd2Ur1RWFHT riquu664rtOM76fmPtnePePvqdk+VTuuP66ErpuuOFHeUWxRE5zhGdf4ruyu5OPYUXpREVEM+9hQ UFJQclBQVHtVHFBPUHxRHulQfq+QEMNqZX9+JUgkSyRMLHggfsVMVylI53TqeItLi0yKdFZJd0B+ eHZpdWl3a3hgfgp3OXcgftB+W5ZQUUpMeUwbTIdJi0tV+HhRmnSJR4p0iXeIeLt0VkwQc014WF5P S1hxclFPS1dxc19PS0Vxc1BNcHx6TXhvcx9zUnNzV0V6eEZGRVJYV1hCUEpASmBKEEogSlVKGX7o r5AQSm9lUH5REH7gflLPfpB+gH5TfnxRcl9ezn1+6FEn43ExM0h7ex6kbB2tbB1ADSEie6YNHRMI 6VB2U325S+lQdlN9vQlQb2xvbEC9QUJpfw29QmlpQml7e3thYBMpEEx0eUdMSHV4dnlHdmNRdEx2 Y1F3SXpjUXVLc2NQe3tRe3t7e9HRUBkEKRBATnJxT3NrVHJOcGtQcXBPUFFAbEBse1B70VEhDVAh IlEiUA1RDXtRQURHRmNjRXFlY2JnZmVBZHd2c3NlcWJGRkVEVnNydndGRmNiZmVkdnZzcldR9Ex2 HWSt62MGdURLdx1jUaHmgsCLmGEiEWUCTTjHGNQEYwBSK64l0E98dXVoTyRTPNBPfHUb4ir2gF4X Wlrx0AjHG0NQUlAYrj9VKVU7UEVQdlCtEHkVUQhXxVFTVl5RB1EIVzZRJlHWUcBQxliXX7VQWVRf EFASUVMGWFPHVOhSgBB/WEZ4QFNQTvxYWHBQYFAgUNBQVFACWFhdU3tybE9Df0NSUENAQ3BDYEMQ Q1VDGXjor5AQSm9lcHgQeFJ4SmxAXXBdUl9dT11SXRl3NDNIex5ApA0iHb0dQCF7pg0iHb20Qml/ vQ1Qb71sb71ApL1hYBMpEBBZdnB1THZbXFpcUlZIdXRzdXNSVk9Fcn1RTVlKfVBHX0p9UHZBcn1R cUROfVBFUEtcTn1QWVhJXkZ9UXNCRn1Re3tAbHtAbHtRe3t7e3p7ent70VEhDVAhDVVGRkdFdnR0 d3Z3dlJlQFBxcFBBRFBRcldWQUBHRmNiZ2ZBZHd2dlPWNr3H2q6Wrrc2wAQq11HaUUhRWlHVrruu KuY/3N4+5ewj1xpp7V/g9lxwVTXjNWoRMVFLkVFgUcKuPa6dqa7YVLrS867grufi2dnyUWyj9tAp UFBSUHNQUFU4VRxQeFBkUe8Q6NdyUULVdpVzlX1TGXT3fVJIT0d+NnRTWVFZdXZ1F1AIUT9SP3Qr UStSI08jcCZyKHXaUddwyH37Uft153bsfa90RVZw1FHcdNR3ynT1UfRS9nT/fe99iGC/fa99XUJQ RlFKUkJ4SmBKYWp+amA2dDl/WnpYUkxMUUVPS19xclB1eEtQWE9LXnFzRk9LTHFzEFJ8dXR0clJR RFJSUXT8UnBSV3p59VdAVwBXMFdTwFfwV1JXUEv8TGToUcEQX2J4TU1MUl9eXlFRUFhCceivkOII ZXHor5AQcR9lUHH/cVIfcfBxUnHlQGZREGYgZoBmU2ZkWHJGRc5lMelRSVBIex5ApGwdrWxADSKk DSF7exMI6VB/U325S+lQf1N9vQlQb2xAbEBsb2xAvb1AvUJpDSJ/rWxAbElKQL3XXn5Iey1AlFFC aUpIe3tAvVFAkHvXQFUtlGFgSBMpEEx9YU5zT3V9c39jUWFOf2NRfnJ8Y1BzdGBwYmNRUHtAbHtR e3t70dFRIiENUCIhDRMMCOlQda+w4lxpUeivoOJEaXjor7DmRGlSQElpeOivoOVAaWBAX2lQe1F7 e3t7UHsJUQ1xcVFWc3J2d0FER0ZjY0VxZWNiZ2ZlQWR3dnNzZXFiRkZFRFZXUUZGR1FiRmNiZmVk dnNyV1U4rsauZWNwXU5ATHYcZa3rYwZ1RUx3HWNRvoid3/P7UUgw2j+sbUNMWZKVz9NqM1IqUlFR ribQT3x1dWhPJFM80E98dW/5JS3odq4r1ghcUsRR+NIvz0NQUVDQr7FUVVU7UGhSBxBJQsV8UV9R X1JbU1BfVHhQeVV7H1EfUllBauhRFhCAZmhmSlNLVA9ID0kPSg9LVlVdVV5QepBqVCRbJF0kXiZf IE4gTyB/IGDZWNZb113XXtRf13v4VPhjQEJdY11kXWVNY01kTWV/UX9SfVRwTnBPeXl9Y25RblJv VGBJYE5gT2BxbWRtZRhdGHoEWwZdB0AGeQZ7TU9RT1JLY09lS2YESARJBEoJYgxjDGQMZQxmCmde U1tbeUNbS3lzW3Bqa3lgaiJCIkPZdMhXyH/JYPh/kHiRepZ7kGqgakQeWGhLUD9SS/9Rn1FSUS9R UVHqUOhTGxBdZcphTEtNP09LTk7qTehTGxBkScpEent7bFxeRFxcXntcel5Udll7XHpeVFZzUa1Q UFZ4YVNzeERZUvxREE5yZFFRT3ZRduhRcxBAf0HvQVKPQVFwQf9Bj0FTQehS1+dP/E57QFlRWehR cxBPz35R736/fq9+U34QF2UQfp9+v35TUH5wfmB+kH5UfuxRFlBpURZRSFBIex5ApA0NeyEiHb0i pL2tDSEirSJpf3u9UG+9b71sQL1BQkdpUUFCR2nXXn57Xi1AlEhQQLykvVFAvaS9UEC8pL0NUUAh vaS9YWATKRBmdGBXQ3h2W3xZY1B5X3ZjUXRDdmNRV2BZY1BafVxjUFtcfHt3QHpjUV9eeXp1QnNj UFh/VmNRUHt7QGxAbHtAbEBse1F7e3t7e9HRUQ1QIg0TCBBZM1s2XTdAM3tUDQkNUSEie1AhUA0T DAgQXFtIX2lUYF9pY2BfaVB7e3sJUUFzflJzclZFREdGR05SRURWc3J3dnZzclZXc0FjTlJjYmZl ZHZ3dnR2dmVkZmNiR0ZjYmZnU/t1Qg38DDjYe2657tsbv+xrZE+TSklNV3V1SgjlPC3BZ2p3rvTD HLD9PCloR0pxWlU7rnvX8A4vAW5jGy02PcQByo9ZVW9Of1GBwsEw1ApiNnxOkyTcBMKDZUlPf1BQ UVBuUFBU4FUcUE9QmRBqClEKUgpNCk47UTtSO007Tlh/cW9xH3HIVcdL+FX2S1dSUU1ORk9LQHFy WU9LX3FzV0hzUE9SQF9YcehSkBBDWVF7UBBHXm9CX1BPUABQ/1BUUOhSeOdYWXJHRk97TuivkBBe R15vQlBOQE4PTvBOVE7qUnhQRlKQ43A0DUh7QKakDRMI6VBOr5DiW2VO6K+Q4ltfZHt7CXu0QGyt bKQNEwgQWVAQW2VQEFtfZHt7CXu0QLZQb2xvbK1se3tRQJlAmWFgUQ1QDVFDc3Z3dnZzc0FER0Zj Y0VxZWNiZ2ZlQXNyV1ZWV3NDVPFfdltDTzcE70t2H3+tkWAGdEbzD3hkGld2QFUcrpIEdGpnq6Qt T3p1dWRwIlRcXkM8DFFuUFBRUFuvsFXhVRxQflFI6VBgr5Djen9kYOivkONwdGRg6K+QEARGTGR4 VmpWHFYpX1R1c3V3YnNidxVzFXf1d1d5d2l3UgBgJFsrX8p373eodlZsXlhPS1Jxck9PS0lxcnpP S1Fxc0NPS0hxc0lISFJSUVJ1eF1ZennoUpkQQllZWBBcaVgQb2VwWGBYUlhKYOivkBBwb2VAYFEg YPBg4GCwYFRgT3ByQkIvQ1E/Q1FDSX+k8kh7HkCkDQ1sHUCtbB5ADSF7pg17e2wdQK1sUG+9b2xA bEBse3t7e2FgGwEp4WdYEykQdnF4WkFycXNxUlZfdXd1dF5wfVBAQXZceX1RW1pxQHV9UHhbdX1Q e3tRQGx7QGx7e3t60dFRDSFQDVAhUXt7e1FlcUVzcldWRUFEVlZzcnZ3dmVBZHZzc2VxRXNyV1ZF QUROUmNiZmZlQWR3dnNTgVGwYwB7RQG9nI62YHAVHWNSGmQEdElNHN841YIdTHcdVXd1dRNPIa2K nLHxytIJpVJCLR51dWV0Iq3hH5wiGiTliFJ1L3B8UFBRUEKvsVX+VRxQT1H9EEFaX1ZPUkJAcVFG WFtp+UZRceivkOJIZXHor5DjY2VkceivkON8f2Rx6K+QEMdwc2SjQqtPoHFT6kfpSOtK4HGpV1X5 SfxK7FXmVulXVfpV91b5V/pF90ZVy1fAX8BCykbAcVU5RTRHJFQpWtBxVQpGB0cAcTVWOVdVC1cJ WAtaDl4JRVUQcQBQBFMHVQNWVXBxZFRoRRZQGV5VdVZ5V3hYeEV4RlVQcXBxYHEwcYBxVVBVUUtQ X0VAS19eWF1LXk9HTktP6K/XEEFGV1ZwWFdXckZFREZGRVVWVuhSmRBlRkdERkZHT19fXl5QUldW WatHUUe3YEYQRsBGoEZURrhgRRBFAEXgRaBFVXBFMEUgRdBFVEXoUrvmcHHGcTvaSHt7pA0NSaQN tA1QSG9sb2xAbEBs11V+e14tQJTXVX5Ie14tQJR7SFBAvVFAkFBAvVFAkFBAvVFAkFBAvVFAkGFg USENDQ0NDQ0NDQ0NDXt7e3tQDXtRIhMMCBBZWkhCaV8QQmlU6K+45kBpWFhDaVfor4jmQ2laeENp VOiviOFfaVF7e3t7e3t7CVENUUVWV1ZXUXNRdnd2dndlcUVWVkVER1FRZmVkdnd2d2VV/hh1ZXmu d3WuVHdASRluUnoOaH5RCVEQf2oVVVxVHHVdcWE1qy5UwQpET3NVdXVZfnRiOqy1U0EkfU1lW1FS dVBRUEuvsVctVRxQaVL4EElZVl1XXFhaWVdaWmBWaVdCXkhDaVxIQ2lL6K+Q41hZZEvor9DjWFlk TOiv0BCvWFlkZlllfxpZCVQIWfdZVnZWe1h8W3hceEN4SnlLenh3YWZWaUpkYBdWFFcbWxhLBFYI VwhYCVoIXAhKCGAEYTlWNFc8WzhKOEs7YyZUJlYmVyZaKFsrXCtKKEstTChwJX/VVNxY2kzYf9hg 2WHCV8lbw0PDSMlKyEvEeMV/xGD4WPpZ+lv6SvhL+Uz6Tfd/41fjWOda6ErkYJdgqVipW6xNqXAa OH81YDhh2VlUaEs8Tj9PPn1UNVc1WDhZUxtZHE8YeBt/VAlLB38BYFMAVwBYCltTVFdQWlNbW0xG f3pMeU9hV2lbWVlMTFhZWVpMTEtNTk5YUFZRS1BDSkRLEEVDeH95S3hCXEFLQndOdkt3aWFoS2no ryDjS1tacOivPxBEYFhXcFxbW3JLSkRLS0pMTE5ZWlroUpkQRUtMREtLTH9NWFhyYH9EYGB/YVZX V+hSmRBMYGFEYGBhQ0J3eHhpaUJQUltaWlhYV1lrzlb1Yeiv0OIQZWHor5DiamVh6K+QEHZ9YGRg YdBhwGFTH2EPYTBhIGHQYcBhsGGgYVhhuFi3WQJbS+VKW+pScFBKUaoQWxBcAFyAXFNc92pr6FI6 43E72kh7e6YNvbRJQLRIQK2kpA0he3t7rbZQb2xAbEBsb2xsQGxAbEBs11V+e9deLZTXVX5Ie9de LZTXVX5Ie9dYLZTXVX5Ie14tQJR7e0hQQL1RQJBQQL1RQJBQQL1RQJBQQL1RQJBQQL1RQJBQQL1R QJBXQF5sWGxYbFdAbGFgUQ0NDQ0NDQ0NUA1Qe3tRe1F7exMMCBBEeHhGXW9OeEZdb3BgRl1vT0hC W29Qe3tRe3sJUQ1RRXJWV1ZXUXNRUXNRdnd2dnNlcUVzclZFREdRQ3d3dnd2d3Z3dnNlcUVzclZF REdRUWZlZHZ3dnNlVy1lEk5Ee67WeK6brp10rj19XEQVa1GmSGVofFFbsXhwRUpdQ0lJQ3lSQHRo ZH1RVFFSfE1Gdm1VHHV2ZHPUq+tTM6zNVDYuR3Z1dXVgcnMurVdS1yILYnZDXUJYVnV1YHljL61P UrssYEd4WF51UFBRUF9QUFX/VRxQb1LyEEApQVFdSVl2alEoUCdxVUJP6K+wEF5faX9ARGlAERB7 EBFTEeivkBCKT3NkJlAoQSpyIHsqfcpyyXP2UfZA+XH5cvlz9n35f+tz63Xrdupo5m+YQJVLlXCY aZARhUKFcKlboBFMQn9AcEJycHR7eH5/f21AYEJgcGtxZndgexdQXUJQEXARYBGAEVSWfVEkfSx/ 1XvZf1QTewlcCXFTWXNJc0ZubxEbShN3VkJEflF0fjVx9XH1flR+cH9RfXFwf0ByQUByQm9QUX1C b1ZAV0tWSnBLS0p3fXhLd2lvaktpVVFUS1VJQkhLSXZydUt2aH9nS2h9ckBAclF9RFFRfX9vQkLo UpkQbnB/RHBwf35xQVBUfnFBUFRRcmloaHd3dlJKSUlWVlVYOG9Rb3tQUVFfUXBRYFEMUTBRIFHg UZBRsFGgUVpR6FKqEF8UcANwNHBTcGJQcvByUnLoUpPmEBHGcTvaSHt7pg2kDa0NIbQNUG9sQGxA bG9sQGxAbEFCR2lRR2nXXn57114tlNdefkh7114tlEhQQL1RQJBQQL1RQJBQQL1RQJBQQL1RQJBQ QL1RQJBQQL1RQJBQQL1RQJBQQL1RQJBfX19fYWBQDQ0TCOJwf1ENCVENDQ0NUSETCOZ/UXlyf25T DQkNEwgQWTlxNHs/fzARVA0JDXtRIntQexMMCBBfNnc5aFJ6SEZdb3NAXWlS6K+4EENcaXNIW2l+ SFtpcxhGaXZgRmlS6K+Q5kZpcnhGaVTor7DiRmlE6K+w5ltpSEBCaVLor6AQW0JpfVhCaXJwQmlo 6K+44l9pd+ivuOJfaULor4jiX2lw6K+I4l9pe+iviOJfaW7or4jhX2lRe3t7e3t7e3t7e3t7e3t7 e1B7e3t7e1ENCVENUA1RUUZGR0VxZWZnZmZlZHd2d1NRVlZFREZHRXFlZmdmZmdRUXZ2d2VxRVZW RURHQ0NmZmVkd3Z2d2VxRVZXVlZXUxRRcyklCq3qakxFS1lXYLautH1CZhyuT2N1biAYURCupT3I M1IjAGtggKF6Q1xffhhRsWl0ZgoCUr+uHuQPVXV1UVtZdUNHR0EXUQyuxGp3RXB6U3V1VUBKCAtR xFHXzzNTdXVTfkx1F66ZUWFmeEVFQEVBUXV1U19HHjlQUFFQQ1BQVflVHFB+UcbkVVBRQmDor5AQ +G9lEGAOSA5JAGBUfEcrRyl2KXfbR9l3VklVSVZSUGBFV0V4cGAAYFVVVVZXVnhFUlRxUHBRdFd4 d3R4dX5gYBZREGABUQhXCk4IeABgI1YjVyN4I3ogYNBR0FbUV9R40HrQYM9681HzUvBglE2FTbBg cNVW11fXeFNRV1JLUUZPS0Bxck92cEtPUHh+S1BZT0tfcXNOSE1LTnR2SEdHcnd2RHd3dldYWOhS mRB5d3hEd3d4SHZHf3hXYFh4V3d2SFVPQFFQUE9PTlJAX1hHRnIQWFn8cHfor5AQQl1lcHdgdxB3 AHcgd9B3wHdXd+hSyON/O9pIe0lApA17Sq1sSkitbFBvbG9sQGxAbEFCR2lRQUJpaUFCaWnXVH57 Xi1AlNdUfkh7Xi1AlFFCaUhQQL1RQJB7QL1RQJBQQL1RQJB7QL1RQJBhYFENDSEhUCFQDVEiUXsT DAjpUFWvsBBeRl1vUXhCW29QeEJbb0jor7jiXGlX6K+44lxpd+ivuOFcaVB7e3tRe3t7CVENUXFF c3JWVldRQURHRmNjRXFlY2JnZmVBUXZ2d3ZzZXFFc3JWRURHUVFmZWR2dnNTgFGJSko0Amyu6Ux2 AnytkGAGdEau3BJ/GkR2UhROfx9tUUtRWmxNZmZVHHV+BjGtra78LU96dXVkcCJREVJoNGJzWnV1 fHx0Dq4bUfIOfkx8SVBRUEpQUFT6VRxQQVFS5EIQQ1FD6K+QEDJDSmRoX2hAFFUaX9ZU2V3nWelf 6UBZdVEeUBVRHlo0VDJXMEMkVCJXIEPWVNNX0EP5UPla9V3vUOhR71roXURfQFVWV1VTU1ZBVVZb UFFRcllaRFlZWllAWFpRUFNWQVlRWehTEBBjWFpbc0FBUFJSUXNXWFhZWHBWYFYQVs9WVFZKf0Nv Qx9DU0NBYnBAUUDeWElCQylxOw1Ie3sepB2kDbQeQA22DUBsUG9sHa1sb2xArWxAtkJpUUFCR2lB QmnXfnstQJRQQmlpUUFCR2lAmUCZYWBRDVANUXsiEwwI5FBAXGlQ6K+g4kRpWuivqOFEaVF7e3sJ UVFxYmZnR1NxZVFxclZWV3NDVMqs1VJ80NllcRCr4FM2rh48MWNFdkxVHKtWIPtWrsl1VIZ/CSpR A1BRUPiuOlIwVTtQV1DREEgQWVFQV1lTVFV2U1JAV1Z2UFFCWUdHSlPor5DiEGVT6K+Q4mplU+iv 0BBzZ2VAU3BTIFPQU1TQU8BTUvBTUVPXVVbgUVEAUjBSUlJJWFnoUWHjcYIKSHt7HqQhbB1ArWyk DSEie3t7HhU1FLZQb2wdrWxvbK1sUUFCaWlhYFENUXFBcUVxQXFSMK4YUeiujlFyrjpXUR+pzFBR UFOvtFJtVd5QU1A04VFV6FFTEFtMNGY4UThSUlBRUehTdxBfUlNEUlJTU1BQUlFbUf1S6K+Q40JE ZFLor5DjW0BkUuhRf+dQ/VNJVFXEcehRU+GPSHt7HqQdraZ7e61Qb2xvbNdVfnstQJRhYFENe0NR c1EDUboArkZV3qoGVfpQUVAbrjlSU1U7UFdQ1BB0EFnwWVIwWVFTVFVWV3ZRUEBVVHZSU0JvWVFZ R0dKUVFS4FZV6K+Q4mplVeivkBBOZ2VAVXBVIFXQVVTQVcBVUvBVUVXXYFD/UFJQSVhZ7FFhUHFQ BFFQUEh7ex6kDR2kDSEie3tsrWweQBU1FLYNUG9sHa1sb2ytbFFCaWlhYFEhDUNxQXFlcUFxG1Ho rhhRcq6OVTuorh9WNFBRUHVSy1PLVThQVlDIEHdRWAheNGaIUlEZURlSFlQWVQlRCVIGVAZVOVE5 UjZUNlVcU1RTUlToU3cQWVVWRFVVVlJTU+hTdxBdUFFEUFNUUFFVVFRSUehS5RBZVlBVUDdWN1NS 7lEUUFFR5lBTUeZQVFEU5VUIVwgOSHseQKQdva2tvUC9rVBvbKxsbEBs11h+e1UtQJTXfkh7WC1A lGFgUQ0hUXtRUXNRUXNRUaJR+Qyu8q7yDlH/VTitY1IareZSnVBQUa+/rhZUQq7KUFNQcOlQUlN3 EF1QX1NQZlVSUTdUFxhIe0ClbECkbFBvvWFgUXFlcVRCq41Uc64WBFBQUVAmVEVR71U+UFNQaxBE IFWAVVJgVVFfUFFQhVNfUlFS1FHoUa3mb1BRUMxUVehSWeNxzI1Ie3sepCEdrbQNUH+tDWFgUSEN Q2NDcyaPOnNVPq73UFBSUBmvvVPZU/9QYlBtUgUQP1tM2mNSQgNmUUJwT2nQb/hZ5lpTQntCLVAt Y9ZQ21vbZVZNQkZqQG/Qb1RZTBxVHFYVcBVyHGoQb9lNWFpeV3BQchlRG1oZWxllG2cTahltB1s3 W9VZ1FrUW18ERtNGUk9vD29SMFhjUGRsfnl9ZOtRS1BcUFyvkOZZaVx4W2lc6K+QEEpqZUBcAFxS EFwAXDBcU3BcAFwwXCZcVFxsSOiviBB5W2kfSA9IP0hTf0gvSFJILk9AUUB1TldgbBBsUmx8VCB9 0H1SfWV5fGDoUxYQQVRbfpB9UX0wdVBjXVxcZGRj61E3UHRQda+QEEReaVB1T3XQdcB1VBB1oHVS 0HVRdetSE1BXUEWvkOJPaUXoUTcQTkt/aWFXEF5pcFcAV9BXU0BXUaBXUQBXUVcTbhM+SHseQKQN ISIiex29pL17QK0NISJ7bK1sQGxAbEBsQKYNbFBvpK20DUC9IW+9Iq0NIXtBaQ0hInt7e3+9QUJp QUJpaWFgEykQF2VrTHNVQ2doZmhSVllYWlhSVnFycHJSVmVbaXBQQU1DTFBCQ19PXUxRcnNrVWlM UGhYZHBRZWRbQkxATFFeckBMUWpWbExQe3t7bEBse1F7QGx7QGx7e3p6etHR0VEiUSFQIVEhIlAN Ewjib0JRDQlRDXtQIhMMCORhEF5pfuivsOJAaX7or7DmXmlncF5pcOivuOJcaXDor7AQW1tpSHBb aUdwW2lM6K+gEEpbaVp4W2lneFtpWnhaaWd4WmlaeFlpZ3hZaVB7e3t7e3t7e3t7e3t7e3sJUA11 VldWc3J2ZWRnZmZnZWR2c3JXVkVHRFZzcnZlZGZjYkdGR0ZFQURGRmNiZ2ZnRVZzcnZ3QVZXVlZF REZjYlIX3XRmbQ8rTnmbvAcDb3V2Un92dX/gzyoea0xCWkdfQFxFbCA2YWpRx3wfFAZoHNQ9QUnS OhNhFCgGdNk2cnJ8an5iZH0GwHlPEnvVrpnTa0RXXWxoxhTDUQ1sSXwwaRgPUFBSr6uvtFPpVd5Q RlB0UKAQKUB2UfRW5lblV7pPVFV2E10NZnB2JVMmVNZT11T2U/tYVxdXUWpYRHddEUNORBRIR1xQ VEtGUEBxUXEJUldLdVlbTmFPVcBVUjBV0FX/VVNVu1xGUFBIdFxcQF0AXSBdwF1U0F3AXeBdU1Bd QF1wXWBd4F2QXYBdV13or5DnbGVdMHWSG0h7HkCkew0hImwdQK1sQGxArQ0ivVBvvW+9Im9BR2ml vaxRpWFgEykQeElwU1tXdnBTTnBRSlpITFBJSFtcTFhOcFFPVHFwUUlbS0xQTVZLcFBQe3t7UXtA bEBse3t70dFQIVENe1ANUSJRZmNiRkVEV1ZzcnZ3QWR2dnNyV3d1Y0FBRkZjYmZlZHZzcldWUWvV yt2C8tv7APUGX3BITHpeUUN9Yz1pC83NNGVleFKm6aGBpMXQampT5cwYSkBzIK14rYxiY5jv4O1L RFBRUBavtFMaU/9QcVHS5FhUUUJz6K+QECN6fWRQcxNdDWZHXQdVUkxDBFQDVQNWBFcISwhMVzdV JlXQUNBx5EuVcIBwsFC1VVlnURdRBkgFTA9zMEgwTCZIIkzaQt5DwEHASPZR9FL/c+NRkVGXV5dJ uVi0TLpwpFFIVlIaQgdC20/bcNBzoHNXQXBR7K+wUHCvsFBPr7DiUE1Q6FMWEGBAcVEwcdBxUlBx QHFwcQBxMHEgccBx8HHgcZBxgHGwcaBxXXE2TY9fUV+XRnVZV03or4jiRGlN6K+IEGhCaU1hU1tx nE9cUR9c31xSXH9AUGBQEFAwUCBQwFDgUJBQsFBZYFAQUFJQ+iNK00pSAEpRz0pRSuhRXBBCoFZR UFZAVnBWYFYQVlVWE3IT6VLBUEh7HkCkIiEdvQ0iIa0hDbQhIr1Qb717e2+9vSFApA0hIrRCaWFg aGhoUWhRIQ1QDVEiUCJ7exMMCORQQEhpS+ivoOZDaVVAQGlR6K+Q4kBpcOivkOFAaVB7e3t7UXsJ USFRVlZzclJlZFBjYkZFRFZzcnd2dnd2c3JXVkVERmNiZ2ZnUxp1iNPMuFFR5Nf+YXxrTkFbc3Nu NG0B8dkyHmdkUQzlk1FWj4hRXt8ddn92RSZPThoy8fSrE34pUFBSUBSvtFRVVd5QT1B9UX7pUH+v kOMXF2R/6K+QEBJ7fmQwfyxULFXaVNB//3+Qf1cQf9B/UlB/RnpFewVVBVgEe8ZXVxhXUXB/Z1oX WgZayFT3evB/V5B/oHtScHBQcHHqr7BQW6+wEBVscB9wDnA2WjxwKnDPUM9w+lfpV5Z6W3ZYQ3dc EUJOQxRFTXdGEUxOTRRPUHBxW1R8RVB1dVlXT3xRfHxPU1tPUFtxXHDoUTcQQkUwRtBG/0ZTT0bA RlJGu3kAVuivkON4fmRW6K+Q5xdlVhN+Ey9Iex5ApHt7Hb2tIg1srWxsbGxsUG9svSJvvW9BR2lA pb2sUaVQQKW9rFGlYWATKRBKdntUWHd1dlh5cFB7VHlwUHhXdXBRelV8cFBQe3tRe3t70dFQDWho aGhRIQ1QIVEiIQ17e3VWVnNydmVkQmNiR2VkdnZzcld3dWNBREZGY2JnR1VzZUF+UnNyV1ZFREZj YlKXE9AaxrCokykfX3BISntdUUF9X3FGS31brqB+VmwzfwgVC+A8CzcWbauVlVEXHfnNGEpAcyCr jfEXTEFzIZlRiBQgaR84mJqHUFBSUByvtFMDU+BQRFBNUhMQSUIPSA1JMFAwRIZTVUlwTGlHcExp RhBMaU/or5AQWhMaZFhPE10NZk/or5DjeHhkT+ivkBALen5kS1ZJWQhDDkYPRwpIC0pXUVNZVldZ WFxVRRlW2VLcVtdc2kDVTfNS+0jlQ4RSiV+KQKRSo1NDQlBXUFhAV0BYMFcwWCBX0FfZWZFXmF+g V1xUUVdd1FJTWeqvsFBWr7AQE2ZZFlIXWR9PBFIEWTJSIlLZQ9lJyUP0WfRa6FjlWeBal1K3UrBc pFpEWIBXUVBXgFdScFfAV/BX4FdUVy1URFBgRkXor5AQQ0JpQg9FL0XPRY9FVEVFS4NUUVTor4Di RGlU6K+44kNpVOiviBAYQmlUYVtbDEtRS3VBV1ecWEZ4S2lfRlE/Ri9G30ZTRqRERNBYUWBYwFhS YFjfWI9YU0BYEFgwWCBY4FiwWFZY+l5FVFDZUFJQ6FN8EEJgXhBeAF5TUF5AXnBeU6BeUV7or5AQ WRMaZF4TThMbSHseQKR7ISIiHa0hbECtDSENIWxAvQ0he0C9UG+9Im+9e3t7IkFpfw0TCOI/RVEN CXtsrWxApA0hImlhYFENUGhoUCENURMI5FZQUVJSIQkhInt7e3t7e3tQIhMMCOlQV6+QEFtzaVwQ fWldEH1pWOivkOJ4aVfor5DieGlW6K+Q4ktpV+ivkOJLaVjor5DiS2lX6K+Q4lppWOivkOJaaVfo r5DiWWlY6K+QEF5ZaUVASWlJcEFpXXBBaVB7e1F7UHt7e3t7e3t7e3t7ewlDVkdGY2JmZ0dWVnNy UmVkQmNiRkV1cXZ3dnZzclaKUTQ01wrVfU9Fmsj1u6Hmypat11H4VUBJM2YD01JrnCQkMyhE2bFR UYm7UVeb+moIdGgQ0VBRUB9QUFMqVdxQe1FNEG7bcMlFyXZTFFMUXBhJ1VPVXFXKVFF/fS9xwFbA V89Yz1nOQM5B4H1ZQFZAV1IPeg97UkxYXuROWMJyUeROV+hTWBBPc07PTu9OUk5BdHVHUXsAQFFA YHp5QkFWWFdaQEtRS+hRAuPffVF96FKm4lF6e+hRQBBdeHlRQl9BQMJfX1F0XuivkOMwMGRe6K+Q 42pqZF7or5Djb29kXuivkON0YWRe6K+QEEZMcWTAXlFQXkBeD14gXpBegF5WXkl86lNWU1dQSHse QKQNInt7e3t7Hb1sQKRsQGxAbGykbEC2DbQiUG9sb2xsbK0ibG+tQWkNf3t7YWATKRBCdXdERnZ1 RXZ1RnhMUHdEdExRe1F7e3vR0VEiIQ1QIiENUUFER0ZjY0VxZWNiZmZlQXNlY2VkZmZjYkdGRURW c3J2dnd2c3JWVkVFY0VR9kx1bgOtjXl4Ekni4gjlITkIamROR2MaT092fhBMvFMcrfbQcnx0dHgU MlIKGGzZ7iUUfWhOZXE9Q0NhN4YSGFBTUG2uFlOLU/9Qa1AZUAlStRDSQkYAx3bJZlNQfUALUiZ6 JgNSUHpWflYC23BUb2cfCz9nJXYgC99U31XTR9RI32XabtMV3xvWH8VHxUjJH+hU6VXkR+RImWSZ G5ALgAuwC6ALS0pwRWNAZURmTwtV91gaZm9LUEZTZnEaS1BJE0JBQF9eXVxbWllZQ0NEWVjQdVFC deivkONEXG916K+QEFtCW2/Pdf9173VTdehRzhBeCHvQcVFCz3H/ce9xU3Hor5DjRFxvceivkONC W29x6FHOEELAGlEaEERcbxoQQltvGgBEUUToUVjmWGVWyRNRE+hTYRBcSRpaf0lRAEnQSVJJ7VKC UFZQWVMdUGxTYRBaVldJAVEBfHxfHe5TYFBgUE5TYFBpUB1TYBBIQGBRP2DfYM9gU2BlaX5T0ARR BHVPeFF46K+QEE1HSmTfeFEfeCB4kHiAeFR4JXALYAsQC/ALgAtVC+ivkBBGW1xkC17fxhZRFmFw RlFfRiBGn0ZTRuhS7RBDyW9Rb2FgUwBTUgBTUVBTQFNSU+ivkONJTWRT6K+Q5ltcZFM5CgvqUShQ cVFa4dlIe3ume3sNISK9Iq0NIb0itEB7IaYNIXsivSFAtKQNIr1AvUC9UG+9Im+ttkC9DSFvQL0i QKS9IkB7ew29e3sNEwjkn3GPcVINCSKkvQ17exMI5J91j3VSDQkiQGxAbEFCR2lBQmlpQUJpUUFC aWlCaWlhYBMpECobB2oVdGVMTUdIUVV2dWJhY2FkYVNWEXYfdn51enYGdQRMUUxrTkxQG2UdcFAS UW9wUG1Vb0xQAH0dTFACewRwURRIFkxRBXcHTFEGB01qS0xRTEtrUBxhGnBRGxplZhBSE3BQUVBu VGxMUR5/AUxQA3kBcFAVRxNMUFB7e3t7QGx7QGxAbHtAbEBse0Bse1F7e3t7e3t7e3t7e3t6e9HR 0dHR0VEiDVAhDVEhUCITDAgQWn5AQltvZUBCaX7or6DhQmlQe3t7CVF2dmVkZmNiR2NiRkdGRURX VlZzc0ZFRFZzcndWVkVERkdGR0ZHRkZFRFdWc3J3dmVkZ2ZnZmd2dmVkZlFyVkVER0ZjYmZlZHd2 UVZWRURHRmNiZmVkd3Z3dlFlBAqd8NMwknteU1ZVU197J2iU9RQXfE9xYEwgnm0NPzrMq5HVG1tB ZVcPZHtpUUUaNBRkABwyFWOuqH9gajTt5PtjZMqxUR55wwnYlBBVVllHSlpVVhgg0OZEdmlEQXBX VFNVWV0gAiEzwgdiZkhIdRJZM09hT3MOUtcmKs4HEiIqzwoSrNFjCHVgdG4vGGRGRlRWUFFQXVBQ U6NV3lBmUKoQf2gQemVaaDBdDWZfdV920GjAaFTgaJBogGhTe1ZRAGgwaCBowGhUEGhRcFhIeU5B 6FNfEEFyfXlOdxpyWnlOQBpzcXlOduhTXhB+c2V3fhFkTmUUUXB3ZlBQTXxUV3d2dkFBQFpJSHRZ wFpR4FpRX1ogWs9an1pUWuhS7RB1fVBxdH5PfQB9MH0gfVTQfcB9UuB9UVB9QH2QfYB9VH0wZ/Yv SHtApg0NISJsrWxArQ0hImytbFBvbEBsQGxvvW9sQWlppb2sUaV7e3t7YWATKRBESkxVWFZ1S3ZM VUlMUVdYSldNTFF7UUBse3t70dFRISJQDVENIXt7UUFmZmNiRkdGRUFER0ZGY0VxZWNiZmdmZUFk dnZzclZXQURGRmNFcWViZ2ZmZUFkdnZzcld3dVEdP9IRHiBLQ15aYBCubkUQYlpTTxRgYToaRWkW rmptc0RIX09KRX9eUUJV3q0yKhUGDBD6ruwHcEhMdHR3dkAeURTGDn9kH65MDn5PdHRDWmgGU23N GEpAcyBQUlBsUFBSV1XeUFtQclCLEEnAdFEwdCB0wHTwdKB0VXB0AHRSEHQAdFJ06K+Q42JiZHTo r5DjaGpkdOivkON9YGR06K+Q43N1ZHTor5AQfklKZEh5TkMacl15TkIac3F3SRFwTnEUXElcQ8BW UVZpUFByXFdDQlrAWVFZaVPor5DiE2VT6K+QEF9vZVM7XFxdSV10SBB7aUjor5AQSmZqZMBIUQBI UTBIIEjASPBIoEhVSOJz4vNIe0CmDSEie3u9bEBsQKR7e70iUG9sb2xvvSJBQmlApb2sUaV7e2Fg UXt7e3t7UQ0hDVEiUWJGRURWc3J2ZWRmQ0FERkZjRXFlYmZmZUFkd3Z2c3JXd3VReXpra3p6bGsu SWERrhMTfktZV05KTHheUURV3mt6emxsenprrnGtcAZpTHR0SmwFUTHFfHBJX3QgUFKvM64WUd9V 31BbUHlQuObMSlFWSVF76K+QEGlnZV174l0NZhB7AHvAe/he+E3we1ZwewB70HtTQHvAe4B7U0pY eHdwEXdOeBRJQ0pZeklLcHlcV0boUV4QQkDAVlFWaVBQXFdLnkBfz0NRQ+hRNxB8esBZUVlpUxAX ZVN+e0dHSlxcXXRPT8BwUV9wUTBw8HCgcFNw4np7gXHi80h7ex6kDSEibB1ArWweQBU1FLYdpHu9 IkC9DVBvvW9vvSJAvW9saUFpUUFCaUJpUKW9rFGlYWATKRBATE5eX011TF9PTFFOXktMUFB7UXt7 0dFRIiENe3tQIQ1RYkZFRFZzcnZlZGZDQURWc3J2ZWRmY2JHRkZjYmZmZUFkd3Z2c3JXd3VReHts bHt6bGzQmPALCGFxSktBMXFIfkZZV05KTHheUURV32x7emxsentsrnCsNru0EnNzYl1XB3UHwVLc x3txSV90IFBRUEFQUFRcVd5QZ1JrEK9faU9pUkJWQFFWQFHDWcVawFvAXMtfykHLQspPz2njWlpp SWlKD0APQQ9PPEA/QT9Py1JZu069T1LQWdFellOWX7lSuV+9Qb9CWG9Bb0hvT2hwb2kWXyJaJV9Y f1J6QHB1cHZ/aWhRaEBXRUAFUQJABHBUc0AHUQdftkClQFUZQRhPklmSWrNaVUdZRkBPTU9PFVIS X1ZbQV9DXUpcTV9OXk9WA1MFVANVCUAEQQRDVklfTU1OTwNSVEBfUVJBQkNDQElPSk5JfnlOd3dy WlJZTlpxeU52d3Nmd38RZU5mFFB/UFtDQEB0cE9EcFFScE9fQEBgUVJEUVFSUXBQcE8QX0NRVHdS X1pAQEhaZ1BQR+hRvBAcSFycW1taVnd2dklJSFpbYFzQXFKgXFGAXLBcUiBckFxSXH9HR89IUUhK T2lRaXF0flB0f39QfkB+4H6QfoB+VQB+UdB+wH5SfjBoaehRKONx9j5Ie3sepCEiDWwdQL1AvR5A IqYNbB1ApA0NDSFsUG9sQGxAbG9sQL1AvW9sSUFCaX9CaWlCR2lRQGxs115+SHteLUCU11h+SHte LUCUUEFCaUhApb2sUaV7QL1RQJB7QL1RQJDXXi1AlJRXV2FgUSIiISENUA0iUQ0NDQ0NDVAhUCET DAjpUECvuBBEQltvT3hCaVF4QmlNEF9pT3hfaVLor5DiW2lb6K+Q4kFpX+ivkOJBaVnor5DiQWlc 6K+Q4UFpUXt7e3tQe3t7e3tRewlRDVFBZ2ZnZmVkdndlcUVWVldXQ0ZHRkdGY0VxZWZmZWR3UUFE RkZHRXFlYmdmZ2ZlQWR2dnNyV3d1UR+5GlxYcXZR3gI9Ebu7MnJgdElurhN2S3iut0l+Ha5+FnNF W19ecEpFekFRQFXerCCFFEJcXERNUnBwUn5ria6HK3F/Xlp0dFFFQ0djUTeugAloSFF0dEFbR3EB UxLPF0tBcyBQUVBtUFBSX1XeUEVQy+fAR5BHoEdTR+ivkONvFmRH6K+QEGppa2RRR+JdNGYAR1EQ RwBHMEcgR8BH8EegR1dceU5XGnJReU5Wd3NEd10RQ05EFEVQUFdWWlBRdF1c6K+Q428WZFzor5AQ SmVrZMBcUQBcUTBcIFzAXPBcoFxVXOJG4vNIe0CmDSEie3tsrWxQb2xvbKW9rFGle3thYFENUSFR e1F7e1EiUUFERkZjRXFlYmZmZUFkdnZzcld3dVErSWQXrm9vfkpeT0hKeEFRQVXeqxEGaE10dEps BVMQyxdKQHMgUFBRUEFQUFZgU/9QB1EUEExkV4AJv0ZT0AlRQQkwXQ1me11RwAlRcFhweU5I6FKs 5HJneU5h6FKsEFtyHHlOFxpyQXlOR+hTXuRze3lOYOhTXeRzEXlOFuhTXRBucwV3HREETgUUWHln HRBpeXhYUFd1FwYHV2x8VXV8XFpbV1ZUVVcXFmFgSEdaCUdHSkBBdHFgcFEgcOBwUnDoUWUQX2d5 fnt0aGBnUSBn4GdSZ+hRZRBGHQcRdBwcTx0AHVLQHcAdUlAdQB1SHeivkOZERmQdMAgJ6FIK43H2 L0joUTTVe3sepHsNISJsHUCtbECkISJsrbRApCEibK1sHhU1FLZQb2xsbGxsb2xsb2xsHb1AvW9s QUJHaVFBQmlQpb2sUaV7e3t7e3thYBMpEERydFxfXXVzdnRccUxRXl9yXnVMUXtRQGx7e3vR0VEi UA17USENUWZnZmZjYkZHZmZjYkZHRkVBREdGRmNFcWVjYmdmZ2ZlQWR3dnNyVldXR0FERkZjRXFl YmZnZmVBZHd2c3JXVldBREZGY0VxZWJmZmVBZHd2dnNyV3d1Y1EANEJ9OGMGLEU33hsZIXFGXVpm ba5sQ2txR1pUS3cGZTscUlJFahauYRxpW1VxfB9mZQN9SWEbrmtvYkpZV05KTHdfUUR7Urw0X3Z6 NA8oGxsFaiyuJgZwRk90dEdAc0EAUdogfhBlGFt7rhsOfk90dHR0QQJR2iBhEE18Z65FCmZLdHRL awVRDsd8cUlfdCBQUFFQXFBQU6dT/1BjUVgQamUQemVYZTBdDWZgZQBlMGUgZcBlVX1UURBlMGUg ZdBlwGXgZVbgZYBlUuBlUTBl0GWQZVNNWEZ5Tl/oU18QQXJ5eU50GnJYeU5eGnNNeU5z6FNeEH5z YXd6EWBOYRRMUHNiY1dKfFJXdHNzX19eWkdGdFfAWFHgWFFfWCBYz1ifWFRY6FLtEEt5Y010ek95 AHkweSB5VNB5wHngeVNQeUB5Unnor5AQWURGZHkwZPYvSHtApnsNISJsrWxArQ0hImytbFBvbEBs QGxvvW9sQWlppb2sUaV7e3t7YWATKRBCSElTVlR1SVNHTFFVVkhVSkxRe1FAbHt70dFRDSFRDSFQ DVEie3tRZmNiRkdGRUFER0ZGY0VxZWNiZmdmZUFkdnNyV0FER0ZGY0VxZWNiZmVBZHZ2c3JXd3Vj URvxwhs8cEZeW2ESrmtDEGNaVBEdJyZbXmEbrmtEFmFfT0pMd19RRHtSvZIbBmwsrikHT0lMdHR3 dl8fUSctIdKuTQ1GTUt0dBc0UQT1GEpfdCBQUFJQFa+0U+lT/1BfUE1RCBAVQtBFUfdG5kaVUZlZ lE2JWVZCt1pRGFkVRgdF1VHcWdlfiUtXTxBiZVRPE10NZs9PUZZFmUpSEE9RGVhAdVBXR3VYW0JU 6K+QEHtCW28fVFEQVFGAVFEQVABUMFQgVMBU4FRWVLxcEEJbbxBcz1xSXBNOExtIex5ApCJ7Hb0N DSEiexvgeAMb4AABCuFcThnhT1QZAgoI7VBcr5BQVK+QUE+vkGhoaAkTCOxQSlNiUFRQRFNiuUC5 S+xQSlNiUFRQRFNivUC9CVBvvW+9YWATKRBmUU1CdV52UnVMdlp1VnZBX0RwUE1RSnBRRllEcFBI V0pwUUNdQHBRS1NAcFFFW0dwUElVR3BQe3t7e1F7e3t7e3t7e3t70VEiUSEie3shUQ1REwgQQSVS JVYqWipeKkIoRiVIJUxYDQkNUA0TDAgQWUxAQWlLQEFpReivoOFbaVB7e3sJUWJHRkVEVlZzcnd2 ZWRmZkdyVlZFREJjYmZlZHd2UlCALjsmny+fKjctnANlOxLP0jEuORdT/87X/yus0PXb/S6pJxFv ziyYro7wk6TcMFBQUq+prhpT6lP/UHdQaVFUEC5aaxNdDWZpQBlAC0DZQVTWfFFrfG9rG3wLfDpB OnwjWClBKXzUWPVXuVipWV1gawhjCWQ8ZFQQa1F/WFN4eUJDcHlOSdZyQ3lOSHdzUHdxH3dOUBRS Qnt4U1R+QGZRZglWV1JXfnVeW0lIXmJhT1rAWlIwWtBa/1pTWrtwUkPoUTcQS3BwAHEgcVLQcVFQ cUBx4HGQcYBxVXEwapIbSHtApg0hImxArWxArQ0ivVBvbG+9b2+9IkFHaUClvaxRpXt7U15AbGxs bGFgEykQcH9lV11YdWR2XHZgdWVXYnBRf11icFFjWWZwUWFbfnBQUHt7UXt7e3t7e9HRUSEiDVAh DXtTdWNFZmZjYkdGRURXVnNyd3Z3QURGRmNFcWVjRmdmZmVBZHZ2c3JXVUFER0ZGY2JnZmVkd3Zz cldWUlFKdhffH9oMIdgg+hpmeGJHaRuucElnd0NFQHNOSHVRZFlePQM0bgEMEAhgf3RTaSKGKTE8 1IS9yy9FX32uuQ5jTnV1UUZbYTRTMglgSF4vrvo/c2oIHjbpgiEeSEJQUFJQFK4aVFBT/1BNUHtR exD+Sl9KTgZAU1F9MF0NZntwSHcAfVIQfdB99HjwfVRgSmBxb3poex9AEEoQcR96GHsIXwBKCU4A cQp6D3s/QDJKMnE/eixAIUovTiFxL3vVSt17zF/GSsxOxnHIes57+Eb2SvtM/XvpRu57nXuKe7x7 q3t6cH0jdSN430PHQ8dEkH1XA0NRclheeU5Xd3JReU5Wd3NLSF9OT1NzSnlReQlCW3N1TUhXV1Ze S0tQT09e6FE3EHNQT1HAUVIwUdBR/1FTUbt2YUBFAEVS70WfRb9FU0UTfBMvSHseQKQhIh29rQ0i bK1sQUJpf1BvbG9svW+tIkFHaUJpe3thYBMpEEh0eENHdEd2cFB4Q3ZwUHVGc3BRd0R5cFB7e1F7 e9HRUSINUA1RISJoe1AiUUFERkZjRXFlY2JnZmZlQVZWc3J2ZWRQY2JGR2ZnU0FkdnZzclZFREZj YmZTO0hjGq5iQ2hNREgL2BnVgVFEk2kwdmpl03c0byDw8yNrDFP/qzYIYkx1dUBbaQJR2jwfopu5 UXVwcEx0rX9R/hsGbO6R6ZBjUFFQXVBQUudT/1B4UPQQP3BScF9iUmJfEFIQX9JUVxB6UQ96UU95 Tkh3ckF5TkfWc3d3cBF2TncUUFpbekFEcEBRVEjQWVFZaUBcUVwJU1NQV0hHWg9WURBWUVZ+T3pR elBBdE9PT3BR0HDAcFJQcEBw4HCQcIBwVXAwefY+SHseQKQNISJsHUCtbEAitCEiUG9sb2xAvSK9 DUFHaVFBQmlpUEClvaxRpXt7YWBRIiFQDVFFZmNiRkVEVnNydnNyV1ZXQURHRkZjRXFlYmdmZ2Zl QWR2dnNyV3d1URwjKWcYZHRzB0VCRX1gQ10Sbq57FnJJWlVdc0pPd1pRRVP/np4TfHdmFUR5Dq4Z HHdLdHR0RkBzQQBRM/BtTF90IFBRUDSvtFKFU/9QYVNZEHlZfEl8UkJCfhBbaXx4W2lIRAlcCnbL QMR0VVpXWnhaeTBjIGPQY1ZfY+hRcBDXXQ1mm12bXpR0lHWHc4Z0iXy2VLZztnS5fFtCb3wNfD59 LXzfUd9S31PQRdBK0EvQTNl9335dX1FfUlpTWVxWTFp8mHKZc1hMU0ZEQkxGTUl5S3zJWclay3DD c8N0W0J7XXh8GnwfYw9jKHkofNZe+HP/Y7hTtkxceVhhTlDtUk5RT1F/UVJR6FF74lDtfuhRShBB ekhOSe1LTkpPSlFASnBKUkroUXviSe1G6FFKEHJCQnRzXVtUX3d0c11bVFVOUZdQfn96YVBQVXV6 V0ouSUlI6FMWEERGf051QltSnEJRUUKfcY9xv3FTcehTRBBbIF9RMF8gX8BfU1/oUWYQSXdKSX5P WFFYfM93UTB3IHfQd1Nwd2B3UnfqUXBQYlFw4RtIex5ApA0hIh29IqRsQK0NIa0NEwjir3FRDQlp fxMMCOKvUVENCb1Qb720pGxAvW+9bEBsQLRAvUFCR2lRQUJHaRMIEFp0c3N0XVtEXV1b115+e14t QJQJSFBAvKS9DSJRQL2kvVBAvKS9DVFAvaS9YWATKRBMeHlPcEBBVldPQXFMUVZ5WExQcEBOTFBX eFVMUVB7e1F7e9HR0dFRDRMIEFmrV6ZApkGreFQNCVEiUCFQDRMIEEnPUc9Sz1PPW8pdwEXASsBL wEzJcsdzz31cDQkNe1EhUCJ7exMIEFt/c39023zLdMt8VQ0JEwwIEEF4cElpWXhJaVEQWmlSEFpp S+ivkOJaaUror5AQSVppfhBaaXwQWml8EFlpXEBOQm9ecE5Cb17or6DiS2le6K+g4klpdOivuOJD aXPor7jiQ2lc6K+45kNpfEhDaUvor5DiQmlK6K+QEF9CaVEQQmlSEEJpfHBCaXTor6AQX19pfEhf aVNAXWl+EF1pc+ivoBBCXWlcQF1pfHBdaXxIQWl8SEFpUHt7e3t7e3t7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7UXt7CVANUUFzdnZzclZFREdGR0dGRURWc3J3dnNyV3NBY0ZGY2JmZWR2dHd2ZWRmY2JH RmNiZmdSwHF2JwwWBnBPD8Kb7SUEPHFFR11xcUzOMhUHMa6OfX3LK2YdY0FAQlxT/66YwzoafWh4 eX4XM/ItyU5aSlEX3N4BaRUOwGppByHIR19eSFBQUVBEr6FSbFSRUEtQhulQXa+4EBFcaQ9RD1JS b03JQclJ70XvRuhJuElXz01R2UpRH1wfXQ9cD12lSFVWSEVId0hTRkVISUpTUUhJSlNES/BRU0Vg VOhRSxBMUVNgUlJRVlxlWHxfW0afRY9Fv0VTRTVES5xQW+hRvBB8cFxRXH5/TeBNUk1QUVFUVFV0 RABDUdBDUVBDQEPgQ5BDgEOwQ1ZDMEz72Uh7QKYNISJsrWxAbEBsQA2kDb1AvUCkDWxQb620b2xA vUC9rWxAtFFBR2lQQUdpQmlhYFAhDVEhIg1QIntRQWNFc0FERmNiZmdjVlZzcnZ2ZUFzZWZmZ2Zn URqGhmN4cW5Bd3PQFH4IesFnI31HeVSRroMWrf4Jbnl4MjNjDzNSOHFGORh2NVBRUFKvtFOtU8RQ dVCMEGVRdzBdDWZwdzB3IHfgd1RkW2dPanAYTxhwVUpYQx9OSHdzcR9OdXdzWHdREVdOWBRwW3VN WOhRFRBDWlB1dUlJSFZNfF5eWltaW1txcOhRNxBeUOBRUV9RIFHPUZ9RVFHoUu0QdUJJSnRCQgBD wENS0EPAQ+BDU1BDQENwQ+BDkEOAQ1ZDMHaSL0h7HkCkDSEibB1ArWxArQ0hbK1sbEBsUG9sQL1v bEBsQGxAvUFCaWmlvaxRpXt7YWATKRBAS0xfQUxfSkxQQEFLQE1MUHtRQGx70dFQDVENe1FBREZG Y2JnR1VzZVZWc3J2dmVBZHZ2V2VxQURGY2JmZ0FkdndlUzNfcUZPd16uvn0mLBUdIXxMZxhREQlv ez0baQpTxK2FzxdMQXMhktASCdzQUckRYktRda3L0ABmHFJXHmdSdVBRUEGvtFO9U8RQcFJqEFlC A1oISAtJU0nor4jiW2Vy6K+QEDFFZURJREpzWXJacUFwQnRIcElwSmpZaVpqQmlIZUlqShpYGVkU WhVIFUkZSjlYzFjJWc1KykvPcvlQ+Fj1WfJJ8kr4S+5Y5VnmWuZI50nqSutLkHKFSKZapkirSn3P WVFy6K+Q42IwZHLor5Dje2FkcuivkONOeWRy6K+Q4xcXZHLor5Djd3dkcuivkONzc2Ry6K+Q40FB ZHLor5AQEElMZF9yLFAiUSJSIFUscNFV1UHfcllqWGRaZEhpS5ZWkHGISlfYWtlI10lTZ0IYSFJD SEROQ1BLcE5QQlpBTkLor9YQfFlKSXBISUlgWVpEWVlaS0pKdFlYRFlZWFdWVVRUWFJOUUNCQlFR UFZKSVtI6FFNEEIPWlFAWnRaz1rmWoRaVVotWUvoUTcQQBBWf/BY6VieWFNYLVlJJUrrUUtQcFBZ r5DjX0JkWeivkONJTWRZ6K+Q4mJlWeivkOdcZVBZkFlSWehR7+ZAclHQclFy6K+Q40lNZHLor5Dm X0NkcfvZSHtJQHt7ISKkDXt7e3tKrUi2SUCkDUikSr1JQKQNIki9UG9sb2xAbEBsQL1RQUdp1357 Xi1AlNdVfkh7Xi1AlHtIUEC9UUCQUEC9UUCQUEC9UUCQYWBRDQ0NIXt7e3t7e3t7UA1RDXt7USIT DAjlWnBGXW9Y6K+450Zdb1l0W2lI6K+w4kNpWuivsBBaQ2lYcENpS3BDaVF7e3t7UHtRe3sJQ3FF c3JWRURHQ0NmZWR3dnZzZXFFVldWV1FzUXZ2d3Z3QVH/THd5RYWGR1hbcmRRe2REc0yu63mu6UZ4 T0FiU8R1dnBzYK5WUl1oTV5ZX1t1dVRBThasvlNVZn9AWVhQUFFQXa+0VeRTxFB8U3LhQn7or5AQ TG9lRndwQHBBdXdwfg9+OVkgfrl1uXiodah4XH7or5DiQ2V+6K+QEJhLT2Rxfn55NGZNSUlPS3NA flRadk12fHZpdgVH90f3SPd2WFt1Z3Rndx9QHFEdVxlYF3QWdx14HXnYV9BA0EHdddh42HnQfspA xEf3SPd160Dpdel4736YdZh4iXWJeIB+T1BVVFdWRVRHWXVXd1l4VnllRxNAE0EAVQJXBkgCedlb 30DYSNlJ2XPYddh20H5H11nWR9d2U11ZCVEnQCdBVFlZWHZ2d3V1WlFXUk5RQEdBTkBwc3FOcFB5 fE5QX1peTl9PSU5OT+iv1uNYeHdw6K8tEBBIdXRwWFdYWVd0eXhEeXl4dnd2dXdgWFlEWFhZSEVI SUV0WnVEWlp1c3R0YEhJREhISXl2c0lIR1pZWFdaUHhx61G8UHBQTlG8409RX0HrUbxQQFBeUbwQ Wl9fQEBPT3BwUFLrUbxQUVB8UbzjUVBWSOtROlB1UFhR9hBfeBB3dXV0dHhbcKxfNVpR6FHh5JBQ NXlz6FFYEEUQS38ASVHwSVHtSZ9Jj0lTScJ0f0joUUvncF91UUB1UXXor5DjW1xkdetRQFB2UEVR NxBcEFp/D3ZREHbQdlJ26FG85Fktd39Y6lFLUFhRSxBacFB4UdB4oHhSeOivkOVbXGR48FfoUTcQ SwB5UdB5UVB5QHlweRB54HmQeYB5V3kwffvZSHtApg0hIr2kew0hSUq9rbSkvQ0hSKRKvUlApHsN IUqttKQNISJItEq9QKRKvUCkvVBvbEBsQGxKQL1AvW9svUC9QGxAbEBsQGxAvUC9QGxAvUC9QUJH addVfnteLUCU115+SHtYLUCU11V+SHtYLUCU115+SHtYLUCUe3tIUEC9UUCQUEC9UUCQUEC9UUCQ UEC9UUCQUEC9UUCQUEC9UUCQV0BYbFhsYWBRDQ0hUQ1QDVEie3t7UQ17EwwI5XZARFxvdOivoONE XG9D6K+w4k1pR+ivsOJNaUfor7DiRGlH6K+g4kdpdeivoOJFaUfor6DhRWlRe3t7e3t7e3sJQ3FF VlZFREdDQ3d2d3Z3ZXFFVldWRURHQ0NmZWR2d2VxRVZXUXNTUXNRdnZ3XVHQZXFBlJVkSHdGbFHk GE5EWICRRHdpUXEHea6eebWupXWuik1obFPEdVROTE98raFR/ddsR15TdXVTR0BzREWtolGrZnBD TlJ1dV05rLtSGa3nU1IZY11QUVBLUFBTt1PEUGhTNRCvQhVaUd9d317fQdd212SGW4ZHineKY1lf fnZadVt0XCJaJVu2YldMan5fCmZUfm9Vb0BvQWh2b3hpZGBqGVsfQB9BFk4Zdhx4G2QQagZJBnUA aiVXL1svQC9BL0YvR8VXz0DPQfdI63ZOXlVfQF9BX3xPQE9BT3x5WnlHf2paQGoFWQpmAGpUdkhI SUdGRndkZGVaW1xcY0haWVdXSXZkZWRjZXVC30Z/QVFBZVxdXUZcTS1JAE5RTn91P3Mvc1Jz33NR c0l1fn5pY32ieXl3YwBQUVAtZVFlVVVXdUlXV3RldURlZXVcRnd3YGNcRGNjXGVkdkhZXEdjd3VJ W2h/EHp2SFpTXGRXZV9MUUxPT3x/f35DQFJoTlBCQUFRUVBWflR9UX19Tk5NWlzoURXlP0ZRRn51 6FFe43BJUUnor5AQXEBlEEngSbBJoElUSeivkONfQmRJ61JmUGNQV1E34mV+d+hRWONQY1Fj61KR UGlQalId43Gd2Uh7e6YNvaS9QK17DXshvaQNvVBvbEBsQA1sb2xAbEBsQK1sbGxArWxsQGwNUUFC aUFHaVBBQkdp115+e9deLZTXXn5Ie9deLZRRSEJpLX9IvEC0DUFCaX+0QUJpf0FCaQ1/DUC0DUC0 QUJpf0AsvA1AtFdYQGxebNdeQGwtlJTXXkBslFiUV15AbFhsXmxhYFEiDQ17UA1RIVAhEwwI6VBb r6DiWmlb6K+o51lpR3BOQm9b6K+4405Cb0Xor7gQWUxBb10QS0BvSOivuONMQW9I6K+4EENHXm9V EEJbb1dIQltvZhBCW29q6K+Q50Jbb3l4X2lb6K+g5l9pdXBfaVror4jiX2lX6K+w4l9pYuivsOZd aXVwXWlX6K+wEF9CaXZwQml2cEFpdXBBaVvor4jiW2la6K+w4kJpWuivsOJBaVror7AQS11pQEhC aUFIQmlHEEJpQEBfaUFAX2l8EEVpQ+ivoOJFaUbor6DiRWlC6K+Q4kVpSuivoBBDRWlmWEVpeGBE aXlgRGlBWEZpWeivsBBLRml5EEFpeRBFaWIQRWlicEFpR3BBaVtwQWlC6K+Q4UFpUXt7e3t7e3t7 e3t7e3t7e3t7e3t7e3tQe3t7e3t7e3t7e3t7e3t7UXt7e3t7e3t7UHt7e3sJQ3FFclZFREdGR0dn ZmVkdnNlcUVWV1ZXV0NGRkdFcWViZ2ZlZHd3V1ZFREZHRXFlZmdmZ2d3dnZzS1H/eXFzW0YRGxhy dlFmYXRhBS20BBhprgB9SUMQ1sMUfX2uhXRLdgqQ/hoBbVPEdUxHSGJAcjg4M0pFTXV1U0hyIveu 6ClhU3R0RF5HRw2UlAtBSHdSdHRVRE0nr6w8Z1BQUVBcrhZTpFPEUGJRPBD7WUBCW29ee8V5UkNk fkY0ZtNV1VZSWVlVQlhJWEpZe0RKdll0QnRKdntoUWZCZUsXQjhZOFo5STZKM0s4fChYKVopSSdK JEsofNla2UnIUMhZx0rGe+tQgGS1VnNZWVh7e3x6elpRWFJOUUNJRE5DUHxiTlBCWkFOQnZYcElK SmB6WkR6elp8e3t0WVhEWXt6WVh7ekpZVFpYfHt6SklaWVhYc0NCQlFRUFZ36K+QEF5CW293f3Np TV9kR0dKSehRWBBL31pRj1qgWlIwWiBav1pTWi1vWR9ZD1lTWS1Y6FFeEE17hl9wUV9wz3BScN8P fFF/fG98UnxJY2T5cfYvSHt7HqQNIh20DSG0raQNpA0NIa0eFTUUtlBvHa20e29sQGxAbEJHaVFB Qkdp11h+e14tQJTXXn5Iey1AlFFBQmlIUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQV0BYbFhsYWBR DVEhe1ANUXtDcUVzclZFREdDQ2ZlZHd2dnNlcUVWVldWV1FWVnNydmVkZmNiR0ZjYmZnZ1F2d3Z3 dndcUftFfX1xj51BV1hye1F6dXhIWUmu22b/AWscZ2BxaXhaThd0Ea7nX3FJQEdjU8R1d013Fa5i Uap5eEJZW111dVRIcV5vrD7V2BR8emNGX24Jz1LjT35zXEBcUFFQeVBQUzxTxFBFUQ8QaEJYVEhU z1TPXc9e+VToVFfPR1FdRyVdYWYAUAhfAEVTS1RHXkNfDlQCX49UgF9XUKZAQBFFTlBb6FF0EGJV VeRaTltUXl9fdFNURFNTVFNbUlRfUVxeR11TX1JeVABVUVVgXVxWQA9fUV9gUVJaX+tSblBeUFRS bhB8U1F+z1BRUH4AXVFgXRBdIF1TXUp/R29HH0dTR1x+W2VQUlFSSUZH8XGd2Uh7ex6kIR2ktB5A DaYNIh2kDbRAtEC0UG9srSJsb2ytImxpQUJpUUFCaUFCaWlBQmnXfnvXLZRIUUC9vFBApVFAvbxQ QKVhYFEiUCJ7DVENEwwI6VBer4AQWU5Cb1NgTkJvVOivkBBdTkJvXxBOQm9UdEZpX+ivjOZGaVR4 RGlf6K+I5kRpVCBCaV/or8DmQmlUSEVpX+ivuOZFaVRIX2lf6K+44V9pUXt7e3t7e3t7e3t7e1B7 ewlRU3FlUXFyVldWV3NncUVRcWJmZ2ZnUwxbrIhSMK6EMWxDS1R4VlNQrcpRHjkbR0BbUUmut3RT eklzYhqudayEc3xwN1BQUVFLrhZTGVXeUHZQ0hAcKFMgeFILUwRCO1M0QjRDJEJWTls4P1pRWlpb WkU4REFQOFFDTv1bWixUaHR0SFdocXFeaEtuQWhI40VQUVFERHBFYEUQRQBFIEVVRepRdVB4UTvh Kkh7QKYNbEBsQGxApL2kvWxAvUBsQK2kbL1Qb71vvUFCaX8NvWlhYFANUQ1RRXZ2ZWRmZWR2d2Vm ZmVkdmVkZmdFVlZFREZFRFZXRkZFRFZFREZTGfeBfik7Oyl+gfclPX3Ew8DHfT2uOXNHsdkY72UY LV55XiwZZe4Z2LJGc0wvHGuRFDXuZGWSNRSRaxwvUFFQ8a4WUKRV3lBTUAMQXFBVOkE7ZsBRwFJS UuhRixBZU1BVR0dKUFBR6FN3EF1SUnBTYFMQU1NTSVRV7FFPUHFQOlFQUEh7ex6kDWwdQK1sHkAV NRS2UG8dvWFgUA1Re0NBc0GkA1XeqOhXGFBQUVDhrhZSj1XeUHZQ0BAaJ0JRdVh5WVIEUwtCNVI1 UyZSJVOoTVdOWjhwW1GAW1FbW0RQOFFBRThEQ079WlpbLEFUaHR0SFdocXFeaEtuQWhI40RRUFBE REXoUXXjd4KNSHtApmxAbEBsQKS9pL1sQL1AbEC9QKRsQL1Qb71vvUJpfw0hvWlhYFANIVENQ2VG RkVEVkVERkdFVlZFREZFRFZXZWZmZWR2ZWRmZ3Z2ZWRmZWR24feBfik7Oyl+gfclPX7Fw8DIfj1V O3NGsdoY7mUYLV55Xi0YZe8Y2LJHc00uHWuREzbuZGWSNRSRaxwvUFBRUHxR3lQHUvZQR1A+EE1a U1VfSlNFX3lTd19qU2VfJkNZWUBURVRRXF1kRehTd+ZULFlRUGRZ6FN3EHJAUMjAUfBRUmBREFFS UFFAUXBRU1EVYElRSVzIXRVICI5Ie0CmvUANpg0NDb1Qf72kbECkvaRsUUFHaWFgUA1RY1ZWc3J2 d3ZzclZXc2ZmY2JHRlRjYmZUen1U3DV+Oo3KERYwRHxW2Ax8fjhRAxUbNlLz0sNPChAGMdffXk7B MFCvr1BAUFBV4Fb8UnZQdFBQUVdQ3lHZUSNQdBBFU1IgecB5n3lTwHlReUBiGHtSU1J26VL8UHlQ e1F7DSFlZa+vUEBQUFXgVvVSdlB0UFBRV1CXUdZRRVB5EE1TUtB2UX92UQ92US92z3ZSdl9zGHtS U1JiQFAYd1B7UXsNDQ0hZWVQr69QGq4qVV9VO1J2UHZQUFFXUJhRAVBQUGEQSlEQdVEAdTB1UiB1 0HVSUHVgdVLwdeB1UnVE6K+y5hh7UVF1WHlQe1F7DQ0NDQ1lUK+vUHpQUFTkV1VSdlB4UFBRV1Dd UXBRx1BLEF5Rf2dvZ1JnUaoYe1FRZulS/FB5UHtRew1lUK+vr7WvulX6VuxSdlBhUFBRV1CWUdpR IFBxEENREHkweVJ/eQ95UnlEABh7UVFp6VL8UHlQe1F7IQ1lUK+vUBivsVUoVvxSdlBiUFBRV1De UddRI1BMEF5TUr91UXVFChh7UlNSculS/FB5UHtRew1lZa+vUFuvsFXhVvxSdlBoUFBRV1DeUepR I1BOEEBSUW9oH2hSaHU0GHtRUlJl6VL8UHlQe1F7DWVlr69QGa+9U9lVPlJ2UBRQUFFWUN0lUFBN EEBSfxFvER8RUxFORhh7UlFv6VL9UHlQe1F7DWVQr69QGa+9U9lVPlJ2UBRQUFFXUBNQ3lBQUHMQ RVIQbyBv0G9TIG/Qb1JvTkYYe1JREelS/VB5UHtRew0hZVCvr1AZr71T2VU5UnZQFFBQUVZQlSVQ UH4QRlJAFAAUUiAU4BSAFLAUVEAUcBRSFHXorYTkGHtSURTpUv1QeVB7UXshDSJlr69QGa+9U9lV aVJ2UBRQUFFWUN4kUFB4EElTUiAX0BfAF1PgF5AXgBdTF04EGHtSU1IU6VL9UHlQe1F7DSFlZa+v UBmvvVPZVRxSdlAUUFBRVlCWJVBQRRBZUht1Thh7UlEf6VL9UHlQe1F7ZVCvr1AZr71T2VXCUnZQ FFBQUVZQlyVSUEcQXFJTUm5OUBh3UlNSFOlS/VB5UHtRe1Cvr1AWripTGlP/UnZQFlBQUVZQmD1Q UETiUXJT6K+35hh7UVFyWHlQe1F7Za+vUByvtFMDVT5SdlAYUFBRV1DdUNJQUFBJEFxSb3FRcUFi GHtSUU/pUv1QeVB7UXsNZVCvr1Acr7RTA1U+UnZQGFBQUVdQE1D3UFBQchBcUgBPME8gT/BPVE9B 6K+65Bh7UlFx6VL9UHlQe1F7DWWvr1Acr7RTA1U5UnZQGFBQUVdQlVDKUFBQTedSIHSgdFJ0Qeiu uOQYe1JRcOlS/VB5UHtRew1lUK+vUByvtFMDVWhSdlAYUFBRV1DeUMmvr1BMEF5TUjB3UXdbChh7 UlNSdOlS/VB5UHtReyFlZa+vUGxQUFJXVT5SdlCUUFBRVlDd7VBQchBbUR9KUS9K30pSSkbor7Lk GHtRUUnpUv1QeVB7UXsNIWWvr1BsUFBSV1U+UnZQlFBQUVZQE4dQUEfjUVFIRuivg+QYd1FRSulS /VB5UHtRe1Cvr1BdUFBSEFU5UnZQlFBQUVZQlYFQUHAQWlEQTQBNoE1TTV/or2jkGHtRUU3pUv1Q eVB7UXsNZa+vUFJQUFJrVWhSdlCUUFBRVlDema9QcBBCUlHAcPBwsHBTcEZ4GHtRUlJN6VL9UHlQ e1F7DWVlr69QXFBQU6dVHFJ2UAFQUFFXUJZQ+1BQUHEQQ1EQEQARwBFTABFREVKCGHtRURXpUv1Q eVB7UXshDWVQr69QFa+0U+lVPlJ2UAJQUFFXUN1QzlBQUE0QX1IfcVEvcVFxUEAYe1JRT+lS/VB5 UHtRew0hZVCvr1AVr7RT6VU+UnZQAlBQUVdQE1DnUFBQR+NSUU9Q6K+g5Bh3UlFx6VL9UHlQe1F7 UK+vUBWvtFPpVTlSdlACUFBRV1CVUOZQUFB0EF1Sf3Q/dFIgdO90UnRQ6K6i5Bh7UlF06VL9UHlQ e1F7DSFlr69QFa+0U+lVaFJ2UAJQUFFXUN5Q+a+vUHIQQ1NSIHfQd1KPd1F3UAUYe1JTUnTpUv1Q eVB7UXsNImVlr69QFa+0U+lVHFJ2UAJQUFFXUJZQ+lBQUHQQXlJfe397b3sQe897VXtQ6FEa5Bh7 UlF/6VL9UHlQe1F7DWWvr1BSr7RTrVU+UnZQCFBQUVdQ3VDWUFBQTxBCUR95D3k/eS95VHlNRhh7 UVF46VL9UHlQe1F7DWVQr69QUq+0U61VPlJ2UAhQUFFXUBNQ7VBQUEvlUc93UXdO6K+65Bh7UVF5 6VL9UHlQe1F7DWVQr69QUq+0U61VOVJ2UAhQUFFXUJVQ/lBQUE3nURB80HxSfE3or1bkGHtRUXzp Uv1QeVB7UXsNZVCvr1BSr7RTrVVoUnZQCFBQUVdQ3lD5r69QcBBBUlGQf1HQf1F/TmsYe1FSUnzp Uv1QeVB7UXsNDWVlUFFQNa4LU8tVK1BvUMsQXSARUThzKHPYc1NVbW0RQ1MEUFVRrVBqUxJQeVMS UFhTElBIUxJQXFEUUEJRFFB/URRQZVEUEEFiUXJRYlZqN1g3eTdIN22fYupRYFB0URTiVZ9f6lFg UE5RFBBBUDdRN3AQcVFx6xARxXHM9Eh7e0mkDUq9tb29vb29vb21vbVQb0hvf0lAvb29vbW1tbW9 tFBAbGFgUCFRDVFzUlN2d2ZmZ1ZXVnNydmVkZmNiR0ZHRkd2d3Z3dmVkZmNiRkVEV1ZWV2ZnZmdm Y2JGRURWc3J3dnZ3RkZHVlJSXHVUTEVgY3xWERM5YH1oa3xJRVsObBhRVldHZhJ+ehNYWhdUF20z QEZHYGtrfGc+YHp5VX1iYHauC1HkUVqX43wyD1dMfGZ5emlWU3lKVHlFT2fQEmoYG2dOTnf9FlZI d1RWaHp4aH9EWlMONnnnrsdQUFJQMlNTUplVOlBbUEdQ3BBAU0n+SDRm0EnwSeBJU2dYQuxTd1BW UZJQXFN34lBTRexTd1BTUZJQX1N3EETQWfBZ4FlTcFlgWRBZU1n+SMz0SHtApg0hva29UG+9rb1h YBMpEHpRR11bX01QR1FFTVFBV19NUENVRU1RXlpcTVFGUlxNUUBYQk1QRFRCTVB7e3t7UXt7e3vR USF7UWJGRURWc3J2ZWRmR3JWRURGY2JmZWR2UcXR4+TQL+Tj0A3S0g0M09JVOuTQL+TkL9DkBNIN DNPTDA3SUFJQ0a7VU9RVflB8UGZRZBAtUHx/RHxN1WbpRlVAZlFHRmd0F3Q4Wzl6OH4oWyl62FHW dNl62H7JReVEgGiwaKpMQVpwWnFSTVhZQ31+TEREWFZGc3RFRVd8UH1+fHRzcEZDWVZaSl1WWVR9 fHRQVHh+c3BTTUZDYEVXV2BYRERYWERXWGRdREVKZVdUWEXoUeTmYHVBV0NXWOhRQRBzeGFUW0p/ X1BRUEp/aBBoUmhkYX9dEF1SXUlnRERKXWdo+nHqUVpR2FBIe3tJQUJpf0geQKQNHb0eQA2mIR20 UG+tvW9vrb1BQmlRQUJpaUFCaWnXfnstQJRQQUJpQkdpQUdpQmlpUUFCR2lAmddAXpRsbGxXQHts XmxVbF5sYWBIEykQQmFjXkBidV92YUBkcFBjXmBwUVB7UXt7e9HRUSENUCENUVZXVnNyd1NzQ3Z3 dmVkZ2ZjYkdDY1NGR0ZFRFZzcnd2d3Z3U0ZHRmNiZmZnVUN2c3JXVkVERlPUfyQK0wEB3hbLAXRj zSjJRHncGME1dWBgfmdPQlhUXbRodkx5bSBqZq5cj0xwNmwCc1EN7DgBc64qUfscHj7crtg5VFEv rj59emZtd352RmxPcq3Zdl1aYxUgIFI3XBo0+BsuUFJQba+4U4FVOFATUB9R2BBmX2BfaX9gf2kf aVV0EE0X3VhdXnUUcHhWRHNRElNuXV5hRB0UWlZwF11edk1naGRrFmTPfhN361MMUFBQdlEI5H5V TXMX6FNqEGRa4UEdFkdHQVtnaE9hUWEsUE9ewF5SXkoBU2hzZHBmeGZuaHosdzcaFlBKwErwSlNK SQAB6FEr43EEDkh7ex6kDR2tpaS9pKSkvR5Atg0dQKQNvVBvbEC9QK2mvW+tbK1sQL29QWlpQUJp aUJpaUFpQmlRQUJpQUJpaUJpaUFCaWlAmWFgEykQNBgfaG17YHFyQkxUWXx2WHZxVXMkURhMGk1Q bH1uTVBqf2hNUWloHEgaTVAeRhRNUUVEHxRZQlZNUFdWQ0RyVHAkUFVWcXAZSxdNUW17a01RaWBr TVEbSR1NUB9FHU1QV0NaTVBQe3t7e3t7QGxAbHtRQGxAbHtAbEBse3tAbHt7e3t7e9HR0dHR0VAZ BCnmFRZOTxVPF+hS4uNVFk4U6FLi5FEVFE9wUUBsQGx7UHvR0VANUXFGRURWV0ZHRmNiZmdHVlZz cnZ3VlZzcnZlZGZjYkZHZmZlZHdzZWN2ZWRmZmNiRkVEVnNyd3Z2d3ZzclZFREdGR3FRdnZzclZF REZjYmZSg66uUUtzlExkYgM4SHRF9TUUPsR4DWViEwwYQXpKUlFFkpJdMv0zLi9hTXZJW1hOT2gf N1xXU1FSrgdGekV9YndKcW9Sw35GDvA4b1ZcHQNZ8fZhPwAAFWwTCVRUSnZdCKEPxWIqmjvYFHBi dkInTEwszBkiG3Gt6l5eYXd0em5QUFJQzK4gUzRVOFAYUAdRJhDucgmTQTRme1F1dHAJYnRoGGAJ KhkmAdoZ8AngCVvWdtYBUlpUVXkldth1VFlwXx5JT3lPF08aEBkTGRRYd1h4fH8RfxN/FH8eGAUH HihQKlEndSgZJgHZUNlR2Bn2T/oS+BPrGLZUtG25E0dnBxceCAVT5x+WdolMU9YB5naWH4YQVAF1 FngZUFlTAXVQGVR7Vk1PT2gFUUQFBVERExNoHnZEHh52Ex4RdlR4FlFNBU9UclNRTQVPEx4RdlhW YetTW1B7UF1TWxBNRzh/Vm9WD1bwVuBWsFZWVms4e2dofkRoWWhAZnjsU0JQblKWUANTQuM/clFy 6FEI5RZ+aGRmU+xTQlBKUpZQG1NCEEFAFnAWYBbwFuAWVRaTCDoqSHtApg29rb2kvUCtDb2tvaSt vUC9UH+9fw29vUC9QkdpUUFCR2lBQkdp115+e14tQJTXXn5Ie14tQJRQQUJHaVFBQmlpQUJpaWFg UA0NDQ0hUQ0NDVF7UXZ2ZWRmY2JGRURXVnNydmVkZ2ZlZHZzclZFREdGR0ZHRkVEVldGRkVEVnNy dmVkZmNiRkVEVkVER0ZjYmZlZHd2d3Z3dmVkZmdWRURHRkdGR2ZlZHZ3dlEpE2n0KD7fSkNycnxY VWpjGTVLfTqZGmQ6IxZl9Cg8339PT3xASXdoEz1PYC7sFGM8wcd1ZMEWZMkI2QJTGxoqbyX11gZ3 TkV+T192R0R5ZjYZEHoWHcEjAgoL5hUdIBEq9NkIdWN/eEsRQU1DTjhtbmEbD9w7AQsM43UL0xZr AT5lYA0vEd07b1BRUCBR+lI2U/BQW1B+6VBWUermUFZdR0dKU+hRA+NZSVxd6FED43HM9Eh7ex6k Ha0eFTUUtlBvHa1hYFFiRkVEVnNydmVkZlE7OMPDODjDwlPwwzg4w8M4OMNQUFGvoq4WU/NVHFBC UAvjUFdRV+hSiBBbQEJUyUBSVVJW/VXqUXVQVFF1EEdTU1JWhVJ2UI9RUVEnX0FRQT9EWz5DROhR aONxF49Ie3setECmDR2kDWy9vUBsQL6mvVB/bG+tbEC9DWFgUUFzQXNBc0F+UmVkZ2ZmY3FFU04Y 6xnv7TR7apHMUb9VRalhVp+pYVRDWAXhPj4WMDNnUFFQc6+jU+5V3lBqUKwQamBJH30ASTBJ2GTL RvpJV9VY2F9SEEkoaFJgSmBLUlBIQEhwSGBIVBtYVXlOUBpyQWNwT3VNeEFgf03oUfYQcFBgdX9/ UGZ1WlBQWnh1R1p0fnBhz0pRSmVgYGtsY2Fd6FFYEEJ8YURKbGlqdFZVSWtsu3H2G0h7ex6kbB2t bB5Aph2trb1BQml/pA2ttFBvvW9vvUJpf71AvUFCaUFCaWlRQUJpe2FgEykQZmRodXtFSVdcenVn WWlMUFhXZVtjTFF3SHVMUHZ1eUZ8TFFoWGZMUWRcZkxRdkl4TFB7RXhMUHt7e3tRe0Bse3tAbHt7 0dHR0VENDVANDQ1jZW5SZUFkZ2ZjYkZFRFdWV0ZGRURSc3J2ZWRmY2JGRURXVkVER0ZjYmdmZWR2 d2ViZmVkdnNyVkVBc2xjRQ0N+/LuZngx19rmyQc5e3R3e1RWX19KbHdjw8Q6PTkHATZ0VXBpD1K1 qTg35946GmZ6eJbx/q6rMBJ6fXt0QEFIW0JeXmUWwoCkWmktwtYo0O+ro1BUUBWvsVWAVTtQX1BP UBJQHFJ2EONkEFtpYRBbaWMQW2l4EFtpfRBbaX4QW2l/EEJpfxBCaX8QRGlIflFUHhlPNGZUclp4 XX5QZFBlVU9+T39SX3hfflJZQlZGVkpZTn9lf2YrQyZFWFVzeHNSP0k/T1IPTzBBMEdTAEEARw9J Uyt3L39SfH8Mdwx/UyJYd39+fuF4d0R4eHd4fn9Td314fHcTfxL8cGf8ZmT8ZRP8f6BgUWBgcWV8 /H0ax3BAcVFQcXBx73FTcehTERBcUH1+fmZPZVHgZVFl6FMREGtYQBZQU0gWWFllUGRAZHBkU2Te YRJwe2dPZlFmPGzQfFF8PNB9UX08TxdRXxdRF+FAdFHQdM90/3RTdOhScBBEVGATExwcQGFRYeFt f2zfbMBsU2zoUnDmXEwWkFRRVOhTcxBbRBYAXFFcGR00M0h7QKYNva0NvUCkDWytImxAbEBsQKQN Ir0NIrQNtA1ApA1spGxApA1sUG+9b71ApA0ibGxAbECkDSJsvUC9QUJpfw1svUC9QL1AvUFCaUJp UUFCR2nXfnvXXi2UYWBIEykQBBQZUXYVdUJ1XnZSdU52RnZadVZ2SnUUdhdjURlyF2tRQV9EBlBP UUwGUUdZRAZQSVdMBlEWdRNjUHZ3GHMaa1FDXUAkUU1TQCRRRVtIJFBLVUgkUFB7e3t7e0Bse1F7 e3t7e3t7e3t7e3t7e3vR0VENDQ0NDVAhDVENIiF7UCJRe3t7UHt7e3t7e1FiVEJFRFJUc3J0UmVk QnRHclRSRURCVGNidEJlZFJ0VXFiRkVEVldDRkdGR0VzUXNBRkZjRXFlYmZnZmVBZHd2dnNDYmZm ZWR2c3JXU1rjUQTv7K7+6Oiu/+zvUQTi866a/vtRZPj4UWX7/q6arYRR0sHINyeBdk5DcuiuihxW fROuwWB4WVdTV3V9vSY9aiEIdn5VO+eu++norv7r61EC6OlRBedt+K6Z+fiunPz8UWT4+VFn+ITT DRwjT66GZURcU3FRxa6bcU5xcUdGQB1SWxpdR0mu034DZQE+QFBTUBWvsVWAVTtQX1BPUBFRfxB1 JkImRy9/L2IqZVUXYgl4BXwJaDl4Nn05aCVFIGAgYdV/Wx9YYOhTExBcYQ9hP2EvYVNhaWNu6FMG EERwcnFxYxFwZHU4UGlAaXBpYGlUaehTBBBAQBZQU34WX2NPY39jb2NUY+hTBBBASBZYWWDIYWZw ZnLIUHFRcehRfRBLVHvhX2ZPZn9mb2ZUZrZcTBbwVOBUkFSgVFRU6FNzEF1EFgBcMFxSXNASBApI e0CmDb2tDb1ApA29QKQNvbSkvVBvvaQNvW+9pA29pGxCaX9sQLRBQmkNf7RhYBMpEGpRT0J1XnZS dU52RnZadVZ2SnVBX0QkUE9RTCRRR1lEJFBJV0wkUUNdQCRRTVNAJFFFW0gkUEtVSCRQe3t7e1F7 e3t7e3t7e3t7e3vRUA1RDVFiVEJFRFJUc3J0UmVkQnRHclRSRURCVGNidEJlZFJ0R0NzdnZzclZX VlZFREZjYmdHVnNyUGVkUGNiRkdGY2JmZ1Na41EE7+yu/ujorv/s71EE4vOumv77UWT4+FFl+/6u mutEd3TNPgLQeU545sWTJXXbpJiuqVFIin5tHklcQEZbVTvnrvvp6K7+6+tRAujpUQXnbfiumfn4 rpz8/FFk+PlRZ/iQrrgnJRRpe94fhJnyQ5tRU+mQUV9cSlhBTFBQUlBOUnVX5VUcUEdQElHIEBbc f1ENfjJII0gjSSV9Kn7WSNR92n7Jfvd9+H5cE30ZfglJU2l+FEgVSlNiSGZKZ3xTVUhPdk93QGVA ZnRIdkp7flhwlBJL6FFZ5HJtlBIS6FFZ5HNxlBJ16FFZ5HN7lBJ26FFZ5HJglBJm6FFZ5HNslBJn 6FFZEG9yQZQSXd1yWJQSXN1zREl+fXBISWBKcHxJR2Z8f0NSdMh1d8h1dnZmfX5+ZchmZmjIZ2dc XVZXV0JCQ8lQU1LoU27iUUZH6FNuEH1QSBJMyEtLEcgSElFKUVBSfcg6flF+/UlJbEJBV1htbHx7 cBRHR0p7el9xUXHoUhnmbWDJUGxRbOhSehBCWFPIUkbIR2ZQUmZR11h6UNdB61JdUBNQFFGK43EI Kkh7e6a0raS0QKS9QL1Apg29bK0NvR4VNRS2bEBsQGxAbEBsQml/Ha0NvVBvbGxAbEC9bEC9QGxA rmxArmxArWxAbEBsf2xsQL1sQL1sQGxAbEBsvUC9QUJpaUFCaVFBQmlBQml7e3t7e3t7e3thYFEN DQ0NDVANQ3FHc3Z2c3NBREZHRXFlZmZlQXNyVldzdVFRcUVeUkVBREZHRXFlblJlQVFzUUFERkZj Y0VxZWJmZmVBZHZ2c2VjUohGcloFMxt4Eq7aEXMcDwBfclQ2UUFRWVFHaHVCdhmuImt5Q66dcK6c QXV3dK6eaHdCQXhoVRyZGBWt7QR9U3R0VnsCUhRvHpmtlFJsdVFEfBaufAV6VHR0UUZ6EVG8rT5S 2a5OFHlGdHREehVRghx4RXVQUVC8VEVSZVU+UFNQaRBfUFJRUV9QUVCFUlVHR0pQ6FGt5VPUUklU VehSWeNxtfRIe3sepB2krR4VNRS2UH8dvQ1sYWBRDVFRc0NSZa6JcjlVPq73UQlQUFJQaVQwUiJV aVBbUEdQGRB8U0kEdzRmXBAvQlFCUBAvVlFWSUdHSlMQgFmwWVJZ1V8QD0U/RVJFBEgECkh7HkCk DR2tpg2tHhU1FLZQfw0dvX8NvWFgUXtRYkZFRFZzcnZlZGZxYkZFRFZzcnZlZGZSVn1vb319EBCu nH5vEHx9EG9VaRB9fW9vfX0QEH19b299fRBQUFKvuFBQVrRVHFASUBVRGBA3YWJiYBQTdHQUExN1 V3FdXWdYS1dyT0tMcXJ8YH1LfFZxUlJnVUtWe3V6S3t0FGl7YmBgc3UTRHV1E0tfSnVgexZicml4 dHp1YEpEYlETaBJzdHMVFIBSUXNdXl5MEnNpbFBrQGtSa+hSgxB7amj8amlSSUq4S0tMfHtE9U38 e0xYSfwXR0dKSmp7a/xfbE9sUmwZVkr8SetRclBWUFdSfBBZUF9yE3JyFhd76FK843xJFhfqUjdQ cVFS4Q1Ie3sepB29QUJpf2ytbKRspr1Apg2ttB5AFTUUth29UG9svb1AbEBsQKxsb2y9QK4NbEC9 Qml/bK1spGytbEFCaUJpQUJpaUFCaVFBQmlBQmlpQUJp115+e14tQJRRQUJpaUhQQL1RQJBAvbxQ QKVAvVFAkHtRQL28UECl11UtQJRsV2xXXkBsYWBRQXFiZmdjQXN2dnd2c3FBREZGY2NiZmdmZ2NT cWVjYmdmZUFxV1ZFREZHRXFlblJnUWZlZHd2d2VxQ3N2d3Z3dnNxUXFUU1FRIw5YdHRceWBHDa6v Xnxp5j0mZxl/djysVmMDd0iuJCwWbTCuBnxvGmlRzB1LciBUB19yXXVLY007raWuy1E1VVKtuAY/ rnk0FUVbrm8Lc0h0ZBQ/rvt1YXApUU651HlMf1d1dVF0DjpTU99icEJJVnWuhjdmd0JarQRQUFNQ Ga+BVSlVKFBGUHJQYFFTED4JR1Fgf35zc0dSXm5YU11zdF5eUlBAR3JfUUBCdHJHXVBVcFNWfXRy R0BdU1BXSXhRX19zXlJEXl5SXl9wQlFSVn1feFpSRVFTSXhFU3h4WlleWX1sT1ZRVkoQYlFicGxA QlFfQg9CUkJJYTQzSHseQKQNIh29HkAhpiIdvVBvb71vvW9BaUFCaVFBQmlpQUJpaddefnstQJRQ QUJHaVFBQmlCR2lBaVdebGxsbFdAXmxsbGxhYEgTKRB+eXxKT0NEV1lOT01PTE9LT1RWWHZ7fHp8 UlZKRHB9UHlZfX1RT0NJfVF8V3h9UFB7e1F7e3p7etHR0dFWXkBsUUFCaWlQDVFnR1dGRkVAV1Zz cnZ3V3dndkFAUHFiR3ZzcldWV1ZWRURHUVFGR0ZjYm5SZWR3dlQr02rVOA6k7LE3swTRa9SZUdhR RLMPJIMNZhtrHxoZUoatA2ZuCT051iUEQl5UhvJ89yG4za75hPMbFM9/9J9REVF2UcGs5UZOEgiu z7fhU1as4gJ2aG/UoOQrOR1QUFFQR1DdVB5Uk1BfUJkQdH9Qf1F/VH9VcFpwW3BecF9YcFdwWDBX MFjwV/BYVl5dXVJSUetTd1BfUFBTAeJTWFfoUwEQWVZbU1pZWVZWVehTdxBcVFRcUzBb8FtSW+tZ 6FN3EEMwVvBWUlbrVTBe8F5SXutYXVdd6FN3EEtSVVRUMFLwUlJS61FRUBBqZVAQZmVwUFFQm0Do UVPhDkh7QKYNe3tsQLQNbEBsQL1sQGy0DUCkDa20DVB/bGxArWxAbEBsQGxApGxApGytbEBsQGxh YFANUQ1nZXFBcWVxQWNBcUVxQXFFR1Girl5RogBRpK5cUaXdAVHyAlGhrl8Crg4BUFFQUlBQU69V HFAQUSgQbHJPcXNyenFlZE9mcmVzZHpjZTdl1k/WelwGTwZ6BmVTFk8WehZlU2V8ZBJlZmtnEmZz T3ISc3R6dRJ0RehR9+QSXYNyVOhR9xBCElyDc05PT3J6e0R6entrfHt76FKZEGVsa0Rse3psa096 EUV8a2xTElRPenxrVHMQSl1LbWxse3tOTk12TG5vb0tLX0xPTH9Mb0xUTOhTBBAXR1FQUElJSHZH U0ZGUkdHXWZlZXRzUlxdWG1ublFR8FJRUudTTUxMSEj/R1FH50pJRkZFchAQUFNUyHBPew97Ut97 UWB7UXvqUetQEVFT4Y9Ie0lApA0hIkqtbGxsSkitbEBsbKQNbEBsQGxApA1sQGxAbFBvbG9sbEBs Qml/bGxAbECtbEBsQGxApA1sQGxAbECtbEBsQGxAbEFCaWlBR2lRQUJHaUFCaWnXWH57114tlNde fkh7VS1AlEh7e0C9UUCQUEC9UUCQUEC9UUCQUEC9UUCQYWBRDQ0NUXFFcUVER0ZHRmNjRXFlY2Jn ZmdmZWVxZXFld3FlcVN2dndlcUVWVkVER0NDZmVkd3Z3cndlcUVyV1ZXU3FFcVdSBVH6rgZbWUl1 YHmtrXAWckhZVK4IUfhfrjdRKYV1F2hR6hhhQoaFRUVeYllCUQpsS3t7hlHTrg1XUfkZPCBPRkBG eXlKQ3ZDNTwZwHQZUaAHaFF2dlV0RUB7ralRqGJJRURdVFN2dkdzMa5LGUBQUVDWrhZUFlPEUGhQ gOlQaq+Q4kFlauivkBBEX2UgauBqUkBqUU1ZdFNaSVpRVkDoURXlSUUfRlFG6FH2EEBJV3xwcElb fV90dFJoTVlF6FG85EbCXFla6FE3EEZbW09cUX9cb1wPXFNAXB9c/1yfXFRc6FF4EERwajBqIGrQ alRqYAB6emhSUlFoUehRNxBfUFBAUHBQ0FDAUFVQ22ni6VLBUEh7QKYNvWxAbEFCaX+9QA2kDSEi bECtbECkvUBsQUJpf1Bvb2xAvUCtIWxAvW9sQUJHaWFgUSINe3tDY0FER0ZGY2JnQWNBREdGRmNi Z2ZnY1ZWc3J3dndWVnNyd3Z3VkVER0ZFRFZzcnZlZGdmZ2ZlZHeU9EJdFnkmJvVYV3JDSkJKW3pZ PAEeek5YB8YdZXdMc1FyXWh2dWJNRFJcUVPErbvBZXhi1lL/rSI0T0hLRk8XKT9qewk2CEVAYE9f H/Bte2BuamN+JwBINxxVFlBQUq+qU19SYlU4UH5QaFCk6VB/r5DiW2lQ6K+QEDhbaVZQRFB2fhFQ EGACUI9zi32LYYlnj2hbX3RfZx9zGmEfaN9z32hXf35ufihd2F3IXfhd6F2YXVhJXXhd0FbQV1Ro c39lTchMn3BkZWp2f8hrUBtQC1BTUG9QU1kQQGlZEF9p33ZRduhRkuVPWX9ZUlnoUpYQXVPIX1NN TNBEav5DQ0ToUcvlc2hoUFB/6lF9UGJRyxBeeRBWUVbRXG55SWlqxHHoUVPhj0h7ex6kHaS9IUC9 pGxAbEBsrWxAtkCmbFBvvb0hvSF7e0FpJn9IDb1AvaStvUFCaWlhYFEhDVAhDVB7e1FkdnNyVkVE VnNydmVkZmNiRkZFRURHRkdGY2JnRVZWc3J2d1ZWc3J2ZWRnZmdmZ1ZWRURGY2JmZ1EEZWVgfnFJ R3EhKQwzS1JTWFdWXnwZYkpJd1lvPHxlHkZOHWT1KAdjdkZrdVTMPRN7fn15ckpnCG4SHIplWF1X Vk5gZUV5Zn1+HGB8cX5/T054MGByZEZGUFJQTVNDUjNVOFBbUElQyxBLxkHJSIVUU9ZB2UhSJUEp SFJYSEhIUm1YQxZW6FGSEFlcFlBTS0dHSkbsUctQU1GRUF9Ry+NZSUpL6FGR43EIjkh7ex6kHb2t vR4VNRS2UG8dva29YWATKRB+UUlIdkF2XVtfTVBJUUZNUUJXX01QRFVGTVFeWlxNUUdSXE1RQFhD TVBFVENNUHt7e3tRe3t7e3t70VAhDQ0NUWJGRURWc3J2ZWRmR3JWRURHRmNiZmVkd3ZRFCzz4iom 9PU2ZBoVd29pGxd8VTj5LCzk8y3a+3sKMs8zaQkwzTNuUFBTUBmvtFVIU+BQb1AWUARRJBAGCWsF bQVuDhEOEg4TAAZXAFAAbzBQMG9UFReGAFJKTxpPE2caHQBwAHFWdU55T30da09rHVVZRFkXUn8G GWMJYzljyVTJW8lcy0D0beRtkm1baBBxWlnor5AQRl9EZFBZQFlwWaBZVFktVQ9QUVBgEBvoUUvl cRBAEFEQ6K+QEA91eGQPED8QLxDPEFQQVRQQcVFQcXBxYHFTcXECH31Rf31vfS99U30uZU8UURR1 bE91UXV1bGVXVWFeYAIQAlICfF5JW18RUT8RLxHfEVMRpG9vWZwAWlFgWhBaMFpTWuhSueIGUBDo UTcQS3F5YX9hb2FSYX9MG29x73G/cVNPcQ9x4HFTcehRAhBeH2EATFEATFFMSQUTG0h7HkCkDSId vaQNIWxApA29QK1sHUCmDSIdvWxAvQ0hUG9svSFAvW9svSJAvSJAvQ0hQWl/DSFBQmkNeyJ/QL1A vSJAtA17aVFBQmlhYFENUCENDVEhUCJRIlFWRURGY2JnZmdHVldWc3J3dndWV1ZXVlZzcnZlZGZn ZmdlZHZzcldWRURWVnNyd3ZlZGZmY2JGR2ZnZmNiRkV1cXZ2c3JWU3Z2ZWVWV1ZFREZjYmZSjlHA IDEfYmlwdCcG0TwddBtce2pEfzpoDtEHL8woABMSdXZBdEt3RU4ZzTksLkRgZRcxwOWtllEqUjcA AD8uRUrXIRoPEncHUmdjR5n6bXcoRvI8Hn9HCllyf1tLcNUwByoRAHoMPAlwcXgEYkpHcHhkOBgX ZGxLdJLnES4jLa2cfcEVCXoGaQkfNHlQU1B3r+1TiVODUEhQcVB6UV8QI3hReVJ3SRtJCkogVCBX IFgpRCB42FJbSnJAfFJWXFZfRlxGX3Zdb11WS3JRf1hTXHJzXV1SUF9JcXFPXl5RXF9PQklyekpU RlBTVXlzcnFJX1xTUFhMdlJdXWBeUUReXlFeQntMdUZXUX9SV15bdnVZW1LoUbznUX55AFVKfF7o UbwQXV1+TwBAQlFCSXsTG0h7HkCkIh29pL0eQKYdvaS9UG+9b2+0b71RQUJp115+ey1AlFBBQkdp UUFCaWlCR2lBQmlp10BYlF5sbGxXQF5sbGxsYWBIEykQcHd4TU5DRVZYRHZXdk1FT3BQd1h5cFFO Q0xwUXhWdnBQUHt7UXt7e3vR0dHRUCINUSINUWdHV0ZFRFZWc3J2d1d3Z3Z2ZWRmZmNiRld2dnNy VkVER1FRRkZjYmZlZFN21X7XOiSd0APQG9d/3WJoKZwqAtVwYzMSMtJ3UeGuPWMyFTMtUxDDe8jX 4Sat0WNvyXvPbuQeJ6IvZPwJFfDpLNpR0K5uDBXwlylQUlAJrhZTaFOfUFtQe1CMEBL/QFF2cXl1 C18LejtfO3osXyx62l/QQ9p6yV7JX8l7+Ub9dEBGR0hTSnBfQHp4VF1JSE1EQEpBXl1ce19ZUyBN UU3oUeQQXkQWc1wgXdBdwF3gXVRd6FMVEHdWaVBdIFxcU1lKAF9wUVVwRXBScLZTQQCAdlFadkp2 UnbXWV99UX3oUsXlU2lfWVFZ71LFUHxQfVGYUHFRcFLBUEh7e6YhrbYhQKQNIb1ApA0hvUFCaX+9 UH+tpg1sf729DVFBQmlpQUJpQUJpUEFCaWlBR2lRQUJHaWFgUQ1QDVFiRkVEVnNydmVkZkNjVlZS RURGY2JmZWR2ZWRmY2JGRURWc3J2ZWRnblJRlH4REX5+ERFzd1V39dQ4BzRuYHF5FpP5+plNe4Zs U58Rfn4REX5+Ea7zLMGu9CPUwAJhTztwcn8DFSP/69IDFTKn2FBQUlC0rhZRllOeUFtQSFAH6VBc r5AQWhARZEBKqF43Zlzor5DjemVkXeivqBBZemBkx133XVJd6FMZ5VZDVhBQXehTZRBbXFxTEFlk QBBGqElApr2kvWl/vVB/vX9AtmFgUSJ7e3t7UWJGRURWc3J2ZWRmQ2NDRkVEVnNydmVkZ1EGfxAR fn4QEEp2CVUTfn8SVVOeEX5+EBB+fhGuLayGZUpvHRwcSHtQUVB0UYhUDFM+UFVQZ+tQVVN3UFBR YOJTVFPoU3fiUlJR6K+QEFxZXWRRSldQCFYIDkh7HkC0QKZ7bB1ArWxQf629YWBDcUFzQXF0VGgf rEdTPq46URVQUFFQUq4BU7dVO1ASUO8QZFl7T1FJezh59RC5UbZTV1NVEnNSUFF0ElVyc1JxeRJV VXRxeURxcXlxVXkSVFltIH1JdV/rUV5QWVBjUV4QEn1RUFB0YHNSU1Nyc3NZfVlec3RRUnFVeRJY XGZ8YCVQFFEQFDAU8BSwFFQURnxC/1BcQFxwXGBcEFwwXMBcV1wdE+hSWuEvSHtApg29vUANIaa9 QkdpUG9/Qml/bGxAbECtbEBsQL1Avb1AvUJHaddefnteLUCUX19fYWBRDVFjV3NSU1JXVnNydmVk ZmNiRkVEV1ZFREZjYmdmZmdmQ2ZDc2dmZmdmZ2ZnZmNiRkVEVnNydmVkZmVkd3ZzcldWV1ZS/+JB /mQoDj8ECWgSf05Kd15aXltEQU5qT1YAVyThXzNjQUpyGRMSAW4beExKdUZZWUFwSnNbS1M7Eq6j rhmu+zwDbXx3YnRERkBcV1hdWkEO0kZR2XNRjxJXQUdyNIRsaxJ+c3pzRUB1WFtYV0hxYylQUlAQ r6hTkFP2UFVQW1ALEEJZU1dXUVpdR0dKWlf9VlZa/VnqUXVQW1HxEFpYqlVR/VBQVP1T6lF1UFVR 8eNSSVxd6FGd43EECkh7ex6kHa2mrWxAvUCmraatbEC9HkAVNRS2UG9sb2xhYFVzUVFjU1FzUVFj U1Gsaa4tUdNppFLoaq4mUdpqo1hRiFGGrnqueFGIUYauelBSUBCvqFOQU/ZQVVBbUA0QQllTWldR V1xHR0laV/1WVlr9WepRdVBbUfEQWliqVVH9UFBU/VPqUXVQVVHx5FJKXVxd6FGd43EECkh7ex5A ph2tpq1sQL1Apq2mrWxAvR5AFTUUtFBvbG9sYWBRY1FRc0NRY1FRc0NSVGlR064taaStGGpR2q4m aqNT9q54rnpRhlGIrniuelGGUFBTULavtFdKUJJQW1BHUHNQxxAgcHUQdVJQEFZcEEJIEE5OQkJW W0sQcRATZXEQb2XPcY9xUl9xH3HfcY9xVD9x73GvcVNxiF8QRRATZUUQb2XPRY9FUl9FH0XfRY9F VD9F70WvRVNFiFMQWdBqZU9ZD1lSH1mPWVLfWY9ZUlmodLWNSHtApg0hInutpg0hInt7raYNISJ7 e71Qb2xAbEC9QL1AvWFgUQ11YkZFRFZzcnZlZGZxYkZFRFZzcnZlZGZxYkZFRFZzcnZlZGZRBX8Q EX5+ERFSiX4REX5+ERFSiX4REX5+ERCSEX5+ERF+fxARfn4REX5/EBF+fhERfn8QUK+vUEBQUFXg V1VSdlB0UFBRV1ATUdtRx1ByEFtScHFRIHHAcVJxQOivlOQYe1JRc+lS/FB5UHtRew0NZa+vUEBQ UFXgVuxSdlB0UFBRV1CWUdtRIFB0EF1Sz31Rf32ffY99U31O6FEO5Bh7UlFh6VL8UHlQe1F7DSJl r69QGK+xVShW7FJ2UGJQUFFXUJZR2FEgUEvlUs95UXlQ6FEQ5Bh7UlF96VL8UHlQe1F7DWVQUFJQ G6+gVrNVCFBmUBhROBAzIFUgVi9XL1jQVdBW31ffWFg3SidKx0r7Y+pjl0pWeUZqRtdKi0ZUf1hX cVtbT1hLV1ZxUlJPVUtWSl1JTxRxUlFzXFxbQFsQWyBbj1tU0FvgW7BbU1tLfGz1eVNgUH9Af1J/ 6FKDEA9+ZlBzfn1SQkNISbhKQ/VKS3tNS1gUeHFZWPxXV1X8QFZvVh9WD1YvVlVWJmD8fntPf1Ev f99/Un9/UU9/UX88SPxwSY9Jv0lTSQMQGlEaUF1yZwAYwBhSbxhR8BhRGOhSjxBbEGxAdXB1UnUZ GTTpUddQSHtApiKtpg0hImytbEANpA29pA0NISK0raYNvWxAvVBvvW9ApGy9QKxsQGxvbK1sQK4N bG+9QUJpDSF/bECtbEFCaVFBQmlAvbxQQKVRQL28UEClYWATKRBwbRNyeG51EnZzdW13EH1QE3IQ fVBvdmx9UXd4EXQUfVB7QGx7UXt7e3t70dFRIQ1QDVFBY2Jmd2NBc3Z2c3NBREZHRmNjYmZnZmdj U3FyV3JXVnNydFJlQGdmcWJHRmNxQ3N2d3Z3dnNVZHZ3dnNyVlJFREJGY2JmZmVUAOcjMFF3d1kE JedER19uOCgPYxtmeDyuS91OXMs8dfmuufTd+VEUR/vcL1GJXHBIQ0lkcT6uEHVzYh0s7Q8E69Uc DHNVUq25DzWueCsfrhAAYF1YSn4ULK78UVlW+1EZkFFSlb1XVa6GJk94Rl2g0gNETcKug+3Lroz2 YwzeUFNQE6+0VdhT4FBzUGJQa1GMEDYGcARyDmQOZQ5mDmdWAFAAczBQMHNUH1gfW9xC1krcflVp YglMD2I5SzpiIVQpSyR7LGIma9NU2X/2cOZwlnBfU1hZX1LBWEBMYGtUUFNjWWVacnNaWVZMaWNA Vn1zD1BRUGBkY2Por5AQRBdlD2M/Yy9jz2NUY2lWdHVJaXVP6FMWEHJJV1BZUVBZQFlwWTBZIlnC WfBZ4FlYWS1WYV19dUNDXVtj6FN8EHxgcGDwYIBgU2BsbV9kUT9kL2TfZFNkpHNzWZzPWlFQWkBa cFpgWhBaMFpWWuhSuRBcIG3vbVJteQDARlFG6K+QEFl6fmRGE2wTG0h7HkCkeyIdvUANpg0ivWxA vQ0hQUJpDX+9UG9sQL1ArbQNIW+kvUC9QUJpDXt/bK0ibEFCaUFCaUFCaVFBQmlCaUFHaUJpaWFg EykQO2VrTX9eSFNVZ3ZxdWZlZ2VSVnd4dnhSVnt2VHZocGVMUXFyZmVqTmNMUE1MaHBkTFF1SHlw UHxEeXBQfkJgTFFBVV5ScFBfQGZxaUxRa01pTFNlcmlMUXhHdHBRekV9cFB/QX1MUlNfVnBSUHt7 e3t7e3tRQGx7bHt7e3tAbHtAbEBse3t7enp7e9HR0dFRIQ1QDVAiUSJRVkVERkZjYmZnR1ZWc3J2 d1ZWc3JSZWRCY2JGR2ZmY2JHRldRclZXVkVAR0ZjYmZlZFJVcWZ3dnZzclZTD1IT1B8AK3RxdOMt Mdlzbs8x4KGn4DvOf2vSDsMMDFWsEnQzS3U2bgsJJddRS1EPUUlCBn8TN1JtSV0OnDQ2JEGR/Q4T AAFRUYa1UV8IFgUaMzP9UWtlEAPFrq7ECsTruVFFqhYQYGkoUFGvvlGVVEFSXlBTUE3pUFJTdxBa UFBKVVE3VBcYSHtAtR5AplB/Hb1hYFFxZXFUQauNVHNRlRlQUa+9UZVYQlJfUFNQTelQUlN3EFpQ UEpVUTdUFxhIe0C1HkCmUH8dvWFgUXFlcVhCp4tYdVGVGlBSUBNTN1MDVTtQRlB9UNIQeFFQXlRI R3VLT3hyWEFbeBBy5kdBEFvmUEdTUFN/R0dKX3VPddB1U3XoUXoQX0tq8HtRe5NfXk9e0F5TXuhR ehBZVGr/RFFESX5/6FEk43EECkh7ex6kDR29rQ2mDb2tDR4VNRS2UG9vHUCkvUCkvUFCaUFCaVFB QmlpQUJpaWFgUUVWVkVER0ZjYmZjYkZFRFZzcnZlZGZ1RVZWRURHRmNiZmNiRkVEVnNydmVkZlEW CBxaWV1dfEJ5bRpnEzzVUgs1EFtbXFt8RnltHWgSOtZVO3l+NGtzXV5fbXxgFSQFNP12dmoMbkxe XkBre2EYIgU5/VCvr1ATUzdTA1U7UVNQ41BQVPNQQRBbIGHQYVJQUVJ6U3lQe1ENUFBRUOlTNVG6 VTtQSlAHEHFQUFZIUlFQWlhRUFRAVVhEEF3mUFNMR0dKX0BPQNBAU0DoUXrlVWpHSUtM7FF6UHFQ glFtUEh7ex6kHb2tDR4VNRS2UG8dpL1pUUFCR2lQQJlhYFENUUVWV1ZFREdGY2JnZmNiRkVEV1Zz cnZlZGdmUew2dUtcW19aQktBeG5Pe2kUOghrVTt7bmV3ZXBfX1dZbH1jTHYiBCYxEFBQUVCRUzVR olU7UEpQHxBNWUlRUVBVQFlEUOZdEERTTEdHSlVqX0dPR9BHU0foUXrjQElLTOxRelBxUIJRbVBI e3sepB2tDb0eFTUUtlBvHa20QmlRQUJpaWFgUQ1DZWZnZmVkd3ZzcldWc3J2ZWRnZmNiRkVEV1a+ N3VKW1xeW0JKQXhuT3pqEzsJa1M1f21ldmVPX19XWWx9Ykx2IQQmMRBQU1BHUUdUHVRjUFtQX1BL UNbn8FzwX1JQ4VboU27jXkbhQOpTblBdU3fkXhBvZV7or5AQE2tlX15RcF4AXtBe4F6PXq9eVs9e n16vXlNvXj9eUl5gXBBcUlzYQ+FJYF8QX1Jf2FPhWVlJ2F9dH12PXVNdFUwIjkh7QKYhpGxArbQN QK20DVB/DQ0hInt7raa9QKa9YWBRDVFiRkVEVnNydmVkZlFxZXFRYkZFRFZzcnZlZGZSYnRjY3V0 Y2NSEKuaVGattXVjZHR0ZGNUY2N0dGNjdHRjrh0CrqVkdHRkZHR0ZFCvr1BcrhZTpFVpUnZQDFBQ UVdQ3lCfUFBQThBAUlHfbMBsUmxZcRh7UVJSaelS/VB5UHtRew1lZa+vUENQUFX5VvxSdlBsUFBR V1DeUfJRI1BHEFxRUlJod3oYd1FSUmXpUvxQeVB7UXtQUFJQS1CWU7NU2VBOUHtR5BBm+FT4eehU 6HmZVJl5VmNbZU5SCEoITjhKOE4pUChK2ErYTshQyEn5S/h76Uvpe5hLmHtAWFdX6FN3EFlaWURa WllBQkLoU3cQWV9ARF9fQFJTU+hTdxBZUFFEUFBRR0ZG6FN3EFlJSERJSUhC/UHoUwDkQCdC/UHo UpblQCdfV/1Y6FMA5FknV/1Y6FKW5VknWlP9UuhTAORRJ1P9UuhSluVRJ1BG/UfoUwDkSCdG/Ufo UpYQc0gnSVBQRExQUFVPWlpcRFpaT1VfX1xEX19PRElJTERJSU9VEV5S1VB4U21QclNtUERQdVN3 UFxTBVBEUwVQT1N3EFlMXBV1m0ybT3joU3cQWn9VYFVSVdhP2HLoU3cQQl9EUT9E/0TvRL9EVERJ fAQKSHseQKQNIR29pKQNvUC2trZQf72srL1Atra1UUJpf1BBQml/UUFCaX9QQUJpf1FBQml/UEFC aX9RQUJpf1BBQml/UUC0vb1QtLS9UUC0vb1QtLS9UUC0vb1QtLS9UUC0vb1QtLS9115+ey1AlNde fkh7LUCU115+SHstQJTXXn5Iey1AlGFgUCFRDSFRZ0dXRkVEV0dXd1ZzcnZ3V3dndmVkZ3dnR2Zm Y2JGV3JWRURGY2JmZWR2dlNK32rANzfAat/W2Aj3eMJowDY2wGjCZPAZFcmwx4OExcWGMvxTq95p 3dTFytLBZ983bXrfZ8El9c0u3WnefWlkTYXGw4SGwwvgDlBQUVAnr6hSY1P2UFVQbxBdUFFaU1RX Uf1QUFT9U+pRdVBVUfEQXFBSQFJwUmBSEFJVUupRW1BWUfrh9Eh7QKYNraatbEC9UG9sb2xhYFVz UVFjU1Jjaa4tUdNppFhRiFGGrnpQUFFQI6+oUmdT9lBVUGsQXVRTWlBRV1H9UFBU/VPqUXVQVVHx 519ST1L/UlNS7FFbUFdQzFNPUEh7QKYNraatbECtUG9sb2xhYENjUVFzQyNqUdquJmqjU/aueK56 UYZQUFFQ264WUyVV3lAtUU4QRBAvIC9S0C9REVkZU1YVGVYVU1kR6FHx4lksfRFCUxJQTVMSUG5T ElBcUxJQaFEUUGJRFFBBURRQR1EUUERQRFKx43VTLBkRQ1HxUFBTElAcUxJQPlMSUAxTElAGURRQ AFEUUCNRFFApURRQJlKxEEA3UXVEJlw3bjdNN303EZ9ZEVxRFFByURRQeFEUUERR/lB1UDpRFFA0 URQQWxmfUDccNz43DDdT6lEUUCZR/uM3ZWQD6FH+EFpwdZsQN1E36y4v6FFn43E6Kkh7e0mkDUi2 SUqtSLRJQL29vbW9tb29vUC9vb29vb21vbVQf39If29Jrb29vb21tb29vbRArUC9vb29tb29vbS9 QUJpaVFBaWlQQGxAbGFgUSENUUZGR1ZWRURGR1ZWV2ZmZ2ZjYkZFRFZzcnd2d3Z3RkZHRkVEVnNy dmVkZmdmZ1ZWV1ZzcnZlZGZjYkdGR0ZHdnZ3ZmdmZWR3dndmZmdeUnNydmVkZmNiR0ZHRkd2d3Z3 dnd2ZWRmY2JGRURWVldmZmdmY2JGRURWc3J3dnZSQlh0YmJ8emRgdVl3c2YFYXlkZHh5Bn5MRXlY WkBiant6al1xSFd9Y2EcdXliZXt4GWFLRXtZdWJ+RE9wQ35gdVt5c9phdmJhdn4FY0lCd1JWW3JF UlRqe3tmW21WfHZpHGJ4YmR6fx9jeFOAEhB4Gd47NNkdeREQVlpGc2J2eGR1Q1dVUm13dD5mfWxu fkdlCBEUUlxGcmF3eWNwRVZVUm1vd21rCyMmB2ZjdBEVU1lnYnZ1YXJFVlVTe0R4CWVXQktibWpp T3jdAVNZSHFhdndicUdaUFBRUMFSZ1E/U0VQW1ByEF9QqFZdR0dKU6hZSVw6Kkh7HkCkHa0eFTUU tlB/Hb1hYFFiRkVEVnNydmVkZlFQfxARfn4REVNFEX5+ERF+fhFQr69Qm677UaVQmFFWUF8NUFBf EFlQIF9RX0iRGHtRew1lUFBSUBOulFMDUJhQR1B/UNsQbcxLzH75f+h/mH+5f1YqXiVH2l7VR1RI SUx3UFFUX3FYelxI5noQdFtQ5kIQXFthb0xqAH1RX31PfdB9U33oUXoQX/B3UXeTVGpfRU9F0EVT RehReuNfSWBh6FEk43EECkh7ex6kHa0NvaYNrQ0ivbRQb720b720QUJpaVFBQmlpQUJpaWFgUSEN Q2VmZmVkd3ZzcldWc3J2ZWRmY2JGRURWVWVmZmVkd3ZzcldWc3J2ZWRmY2JGRURWIzVvWltdWkZG RnpsHWcSO9dRMwcdWlpcXUZHQXltGmYUPNWulHppDW1MXl5YWGx7YBgiBzn+dHp9NWtzXl1YWG57 YBYlBTT9UFBXUBGvmVftVTtQU1BCUHRQY1AUUARQNVH9EHcfN9A3UvlW9l35Qfl39nv5Yvcf6Vbl XelB6Xfle+li5R9euFhTUlLoU3cQX1FQRFFRUFJJX1B5EU0WW+hRCRBaQxZUVFNQU2QWdehRCedt Fn19HQUWFehRCRBJDRYdHVJSUVsZaDKqCWgB/nloEaoRqmloYOhRlhBdNlhocapJaF9JNgQKSHse QKQdraa9QKattqatpq2mvVBvbEBsQL2tvUBsQL2tvW9sbEC9rb1RQUJpQUJp1357LUCUYWBIEykQ 5FU1B3UDdhd1NHYLdh91G3YwMQ8xUlZnaGZoUlZidnd1E3Zrdnt2b3VHSEZIRUhTVkF2VnVzdkt2 XXVPdQYECU1QNRYyTVEMHglNUA4cMk1RZWNpTVAUdhFNUWx+aU1QbnwRTVFEQklNUHRVcU1RTFxJ TVBOWnFNUQgCBU1RMxgFTVEKAA1NUDEaDU1QaGFkTVESeGRNUWp/bU1QEHptTVBIQENNUXJXQ01R Sl5NTVBwWU1NUFB7e3t7e3t7e3t7e3tRe3t7e3t7e3t7e3t7e3t7e3t7ent7e3t7e3p6e3t7e3t7 e9FQDVENUVFzUXFiRkZFRFZzcnZ2ZWRmZkdyV1ZXVkVER0ZjYmdmZWR3dlFiRkZFRFZWc3J2ZWRm ZkdyV1ZWRURHRmNiZ2ZlZHd2dWJGRkVEVlZzcnZ2ZWRmZkdyV1ZFREdGY2JnZmZlZHd2VJSsZAlT nKymHdgd+iQa2x8e1xdORHFCRn9xYX5xYWBzUiUY2B8e3Rch/wDdEk9Hc3Z+cGBhcWFicFI6FMEd GN8ZGdkdHMJvYk59fnFiTkdyd39zVTuqDlXyCvw4+ZEI+Ds4/wZlQE1qHdnpGWJkHu/jGWStOwn8 ND34CpP4Of4GZUNNLcPkF2FiG+LsHmNlB/U1KfMLCfU2JfwDZX8ZlOcXYkNN08b6FmNQr69QQFBQ VeBXUVJ2UHRQUFFXUJVR2lHIUE0QX1IPdFEvdFF0X0kYe1JRdulS/FB5UHtRew0NZVCvr1B6UFBU 5FdRUnZQeFBQUVdQlVFwUchQahBPUVBqUTBq0GpSAGogalKAalGwaqBqUhBqIGrAalNqUOivsuQY e1FRZulS/FB5UHtRew0NDSEhIWWvr1BAUFBV4FdVUnZQdFBQUVdQ3VHaUcdQcxBEUh9zUX9zb3NS L3NRc19hGHtSUXHpUvxQeVB7UXsNDSFlUK+vUHpQUFTkVvxSdlB4UFBRV1DeUU9RI1B1EF1SUQBt 0G3AbfBtVG1Q6FFI5Rh7UVJSaulS/FB5UHtReyFlZVCvr1B6UFBU5FdVUnZQeFBQUVdQE1FwUcdQ RRBaUVFlX+kYd1FRZ+lS/FB5UHtRe1Cvr1BjUFBSKFdVUnZQfFBQUVdQ3VBQUcdQSRBcUWBzUXNZ Phh7UVFx6VL8UHlQe1F7IWVQr69QY1BQUihXUVJ2UHxQUFFXUJVQUFHIUHgQQFEPdj92Uu92UU92 f3ZSdkjorsPkGHtRUXbpUvxQeVB7UXshDQ1lr69QY1BQUihW/FJ2UHxQUFFXUN6vr1EjUEcQXFFS UnlIWhh3UVJSdulS/FB5UHtRe1Cvr1BjUFBSKFdVUnZQfFBQUVdQE1BRUcdQR+JRcUjor/LkGHtR UXPpUvxQeVB7UXtlUK+vUBivsVUoV1VSdlBiUFBRV1DdUdhRx1BJEFxSH09RT11AGHtSUU3pUvxQ eVB7UXshZVCvr1AYr7FVKFdRUnZQYlBQUVdQlVHYUchQTedSb3K/clJyXeiurOQYe1JRTulS/FB5 UHtRew1lUK+vUBivsVUoV1VSdlBiUFBRV1ATUdlRx1BH41JRTVDor6DkGHdSUU/pUvxQeVB7UXtQ r69QW6+wVeFXVVJ2UGhQUFFXUN1R21HHUEUQWlFRYnUWGHdRUWDpUvxQeVB7UXtQr69QW6+wVeFX UVJ2UGhQUFFXUJVR6lHIUEvlUT9lUWVd6K6s5Bh7UVFl6VL8UHlQe1F7IWVQr69QW6+wVeFXVVJ2 UGhQUFFXUBNR7FHHUEUQWlFRYHVQGHdRUWLpUvxQeVB7UXtQUFFQbFBQUldT/1BGUPvjwEhRSOiv kBBJYmJkIEj/SKBIU3BIAEhSEEgASDBIwEhUSOivkONoamRI6K+Q431gZEjor5Djc3VkSOivkBB1 SUpkXHlOVxpyUXlOVhpzRXddEURORRRdV0ZQV1dWWlBRXVF0XOivkBBJZmpkwFxRAFxRwFygXFIw XCBcUlziR+LzSHtApg0NISJ7vWxAbFBvbG9sQmmlvaxRpXt7YWBRe3t7e1ENIQ17USJRQURGRmNF cWViZmZlQWR3dnZzcld3dVErSmERrhMTfktZV05KTHheUURT/61wBmlMdHRKbAVRMcV8cElfdCBQ UVBsVE5SP1U5UFZQCBBxKlSWVFIlUCNRJ1QgVSBWlFOWVIdUt1RZUlNWUoVQVlFW6FF9EEdUn1BQ VFRfUlFSxC9WUVZJV1jEcQQKSHt7HqQNHa0NaX9Qb728Db1CaWlhYFENUA1DY0NzdVdzqejuT66/ tU5VOa7lhYVQUFFQRlQVUsZVHFBJUD4QE/df6VLmX1PZV9Zf1kNTJl8nQ9tSUzZDKlIpV1M6UjlX NF9TyVLGX/hSU1BRZEHRWSdcXUbRVFRdUFw4X11PXX9dU13oUSDnUDhRSUoIjkh7HkCkHb2tDb1Q b2xAvUBspK2kbGFgUQ0NDQ0NDUNzZmZjYkdGRmNiZmdjRlZWc3J3dnZzcldWZnBUOh55cn31eHBh Xk9RYw1/HyVvfEV5SFtUGdkqXUE9ZgUNPW0Ae0J0QVBQUlDGVEFSRVXAUFtQR1Am5GdYVhZC6lNZ UFlTWeZcFlBQUxZF61NZUFZQUFNZEF1fFmBZEFlSWdVIOipIe0CmDa2kbKS9UG+tpKS9YWATKRB6 UUddW19NUEdRRU1RQVdfTVBDVUVNUV5aXE1RRlJcTVFAWEJNUERUQk1Qe3t7e1F7e3t70VFiRkVE VnNydmVkZkdyVkVERmNiZmVkdlEFACAgAB8gPwBjFxdjYxcXVcAgHwAgIAAfIBUXY2IYGGJjF1BR UOuuKlGgUEBQRVDAEHtVR8peN2YZRVEJRTlFUilF2UVSekVqRVJaRUpFUlJRUclQRURQUEVSUVBF 6FEU5VJSUF04WOhRYBBAUVBaRUVQW1paRlBVaEBkUehR3xBaMFAgUNBQU1BJRupR+1EwUEh7HkCk DR29pL1BQml/bEJpf1BvbK2tQWl/vVFBQmnXfnteLUCUYWBRDQ0NDQ17dWNXRkZFRFZzcndlRmNi ZmVkdnNyV1E5bGJvbigPdWlMRGMWfnJaQEAfQBxmGD1Xe1QTe058UlBQUVBsVE5SP1U5UFZQFhBE KlArUSJUKlUvVlVSU1BfVlFWhVLoUX0QRFSfUVRUUV9WUVbEUklXWMRxBApIe3sepB29DUFpf1B/ vby9DUFpaWFgUQ1Rc1NjVWdjUeLo7k9RQbVOVE5RG4SEr69Q0K+xVFVXUVJ2UGZQUFFXUJlQj1HI UHMQRFFPa1Ffa1HPa+9rUmt+KBh7UVFq6VL8UHlQe1F7DSEiZVCvr1A0r7RShVU5UnZQBlBQUVZQ mWlQUHYQQFFwZG9k/2TvZI9kv2RWZFjor/bkGHtRUWPpUv1QeVB7UXsNZa+vUEpQUFT6V1FSdlBt UFBRV1CZUXxRyFBNEF9RgEhRz0hRSFpQGHtRUUPpUvxQeVB7UXsNDWVQr69QeVBQUzxVOVJ2UA1Q UFFXUJlQ0VBQUHUQRlF/TFFATHBMUi9Mz0xSTFQ+GHtRUUfpUv1QeVB7UXsNISJlUFBSUPGuFlCk Vd5QU1BXUAzmVFk6QTRmUuxTb1BXUQlQVlGLEF1TUFNSWUdHSlBQUVVU6FN3EFxXVldwUhBSUlI6 WFnsUU9QcVA6UVBQSHt7HqQNbGwdQK1sbGweQBU1FLZAbFBvHa2ttmFge0NBc0FDQXNBpAMDA1Xe rUpStqvOrUpStlBSUHNQUFUoVRxQSVB4UJQQNU92JkQmR1NbTVtxUldIUdVN2nFSdVhWT0tQcXJb T0tBcXNKTHRyd1hzdn9Zb1lSWXJ4QkJBUkx4SUlQWF9ZUVlZckxPWVFZA3l3d3l6T2xGSiB6UXp0 SnJbT1ZRVkl5eilxMTNIe3sepA1sHa1sHkANph29QUJpf0C2DVBBQml/DW9sQL1vbEC9QA1srWxC aUJpe3thYBMpEEpNcUNIRHVxQ08GUU1ITwZRcEVyBlFOR0wGUHt7UXt7e9HRUA0hUSENY2VjYmdm ZUFzZWNBZHd2c3NlcXBUQkVAUHF3RmNiUEFAUHNyV0FxRXFzYwZ1RZOTTHcdY1J4UWtRfpSuwa4n iS8Gt1Firp6/CiNR2a4ndWhwI1HmGlE8L3B8dd+ulYOusa4gNExRFlFHUUlRFE2uWxpQUFJQFK+0 U+VV3lBPUHxRIxCzZlFRWVFbUk9RT1JpUsxdyV5XGlEbUjhQKlBUfFF4UmxRaVJUUlJaWlpbQ1FE UktaSltgUWBSEFEQUgpODE8oSChy9E+lUUHUUdRc0F30UVQpSSlOLnzQUFQoXSVCKkQqRVQZUhpd GU4bT1RrUWlSanwZUVR5UXhSUlRRdFFkURJRVGhYU1laWlJQXFtbUVZXVkZOXFlXU1BWenNOcFxZ VlNQVVpKW1FRYFJaRFJSWlFSRlpzW196W1JRU1pKV1BaUXB1UEpASgBKU0pXd3VDW3oAT19RX0p+ cwBARlFGSX0TG0h7HkCkIh29HkCmIh29UG+9bw29b29BQkdpUUFCaUJpQWlp115+ey1AlFBBQkdp QmlRQUJHaUJpUECZ10BelGzXQF5slGFgSBMpEHhxeUBJSHZ1dkF2cUlzcFB2RHNwUHhCenBRckdw cFF0RXdwUHlAd3BQUHt7e1F7e3t7e3vR0VEhDQ0NDQ0NDVANDQ0hUVd3Z3Z2d2dGR2dHV0ZCRURW VnNyUmVkZ2ZjYkdGR3ZXclZFREZGY2JmZWRSUYWnTrkSE2dLKC+pcrXukiOAL+Os2ib0YXdPYgAy MNIB2hsLLs5Uwddn1BNndHtsD9tn0vWuI+nbudJRW5qDytFdWnT19/KS2LU/zuGxUUCvr1BDUFBV +VdVUnZQbFBQUVdQ3VH/UcdQRRBaUVFid1UYd1FRYOlS/FB5UHtRe1Cvr1BcrhZTpFU+UnZQDFBQ UVdQ3VD3UFBQRRBaUVFmWVAYd1FRZelS/VB5UHtRe1BQUlB0UFBUdFUcUHtQaVDlEBAWWExPS0Zx cntPS3RxckBPS0Vxc01PS3Nxc3x9Y0Bp9VG3dHRzUn71X19PX1Jft0ZGRVhjbFdKa3tAck1MSWpr 6FEn43ExM0h7ex6kbB2tbB5Aph29UG9sQKQNvW9sQKS9UUFCaWl7e3t7YWATKRBof2hSXVVWVFZT VlNWZWRmZGdkU1ZZWFpYW1hcWFRWYWJgYlJWaFJjY1F/XWNjUWRWaWNRYlh+Y1B7e1F7e3p6enrR 0VFjYkdOUkVEXlJXVnNzRURGY2NFcWVjYmdmZUFkdnZzc2VxRXNyV1ZWRUVBY2JnZmZlZHZ2d3Zz UfQaxho83wtqMiwzdMsWFQR5re52DXhERhtmeFISeHxiTk58KhQKBm41bngxVEhcQwvIDh3TDmhd VW3RHXV1aEwnUzQiZXx1dUdeFjPfrf1Mdt4OGy4XXVhQUq+prhtT6lXeUHdQaVDoEBArQS9720FT flhweU5J1nJDeU5Id3NQd3Efd05QFHt5eFNiQ3t4QlNUZn5xVlJQZglWV351XltJSF5rR0dKWgBi 6FJuEEFwUkN0cVBwUXBJamu7cZIbSHt7HqQNbB2tbECkrR4VNRS2UG9sbx29b71vQmlBQkdpUUFC R2lQpb2sUaV7e2FgEykQcH9lV11YdWR2XHZgdWVXYnBRf11icFFjWWZwUWFbfnBQe3tRe3t7e3t7 0dFRDVN1Y0FmZmNiR0ZFRFdWc3J3dndBREZGY0VxZUdGZ2ZmZUFkdnZzcldRQURHRkZjYmdmZWR3 dnNyV1ZSUUp2F98f2gwh2CD6GmZ4YkdpG65wSWd3Q0VAc05IdVFkWV49AzRuAQwQCGB/dFVMIq0X KTE81IS9yy9FX32uuQ1iTnZ2UVFGW2EzVRUJYUhfrc6u+j9zaggeNumCIR5IQlBRUPVRXlOKVBNQ W1CfEHdRUllQVVdTWFtWVFNYUFVaWVJbVlWbWVZkWFtWU5tbUmRQWVJVUFDoU3cQWVtWRFtbVlNY WOhTd+dZUkRZWVJQWOhTe+JZVVPsU3tQVlNtUFJSiBBbW2TwWeBZUllQZFLoUojiVZtZ6FN74lhk VuhSiBBBcFObT1tRUFtwW/BbU1uoXILpUVBQSHtJQKYNIki2SkmtSKRJpEi2Sa1IpFB/DbRJrUi2 Sa1sQK1s115+SHteLUCU115+SHteLUCUUVhAsECwWECwQLBfX19fQ1FRZ1FRR1FRV1FR9VExrvBq UTBRMGiu8FEyaa7Ors9RGFExUTBqrvBRMGmu8K7OalEyrs9QUVDYUshRjVU4UElQNRBzX1lQXFJB kRJb3XJTkRJa3XNHSVBRUkJJyF9QUVD9UVFSW1roUQgQQlJVUlNQUFFQ1EJT7xBBUUFJSuhTQeGN SHseQKQNHb1stA1AbFBvrWxAbECsDb1RQUJpQmlpe3thYFENQ2djQURHRkdGY0VxZWJnZmZlQWR3 dnZzclfYnXNWVVtAb67rEEBcWlVTX1xEf1VBB63gbF5ZVVhwcFdVRm5RJhdHQF1EUFFQRFLIUm9V OFBMUJMQDalYqFxSWFxRUFRQVVBGUEdQSEdId0hXWkfQVNBV0EfTSMBUwFXAR8NIkFSQVZBHkEiA VIBVhkaAR4BIsFSwVbBGsEewSKBUoFWgRqBHoEhMSERTVEdVU0FTSFJMUOhTBuJJSUjoURTlUl5f XVFd6FNZ4lpRUupRCFBaU3kQRUFVV9FEblDEUl3IXmZTU1JJTQgOSHseQKRsHUCkvUCtpL1Qb72t bECkDWxArWxApGxBQmlBR2lRQUJpYWBRDSFQIQ1RV3FlZmdmZWR2c3JWV3NmZmNiRkVEV1ZXY2Jm Z1Jvba5CpwFiA29pBkZ9Xi81OtVgG4zqB2lEU2DITZApGhVtA2trMj8kGBIbJeJIcFBRUHxS2VJb VThQe1D64Vx96FN5EHBbNGZyWmBaJlbWVsZW91b1WvB9WDRWqXpSWXpRWVdyUOhTFuPPe1F76FHx EEZUc8gUWQRZNFkkWdRZxFlWWf1yclRG6FEU4kkWX+hRCOPfeVF56FN5EENUVXNycldDezhQfkN2 0Vd/TNFc6FJ55UNJfAj0SHseQKQdrb2kvUCkvUFCaX9sUG+9Ia29vUJpf70NvUCtDbRRQUJpYWBQ IQ1RDXtDZmdmY2JGRURXRkZFRFZzcnd2ZWRmY2JGY2JmZWR2d3Zzc2ViZmVkdnNyV2d0fRAFDDo5 GBn78QR1SnFKTDp2aABlemx/Th05EmcFblSdGnJ/DGcUB0oxazfESEFGQUxgH2V9AkBHTA5tYW4I UFBTUNavmlWGVThQSVBNUGpRGRALqXaoelJYelFUclRlR2Z2ZlRfWVBcWmXQctBz0GXTZsBywHPA ZcNmkHKQc5BlkGaAcoBzgGSAZYBmsHKwc7BksGWwZqByoHOgZKBmTUGRElvdclORElrdc01MTOhT dxBPS0pES0tKZmJxTUpMS1Rsa3Jlc1N/cWZwXMhbWchbWuhRCBBdUUnIX1BRUP1RX3tRe+9TWVB4 U3lQf1EIUHBQTlMG4mdnZuhRFBAVT3BSUVFKTUxLW01Ve8h8ZnFxcPhOddGgYlFQYlFiblBOUWBO EE4ATrBOoE5VTkpsUFBRUNRCUlOfQhBBAEFSQaprOg5Ie0CmDWytbEC0DR5Apg0hHaQhDb1ArWxA pL1Qb29sQGxsQGx/bK1sQLRAra20DUCsDb1ArWy9QL1BQmlBR2lRQUJHaUFCadd+ey1AlEh7e2Fg UQ0hUCENQ2djQURHRkdGY0VxZWJnZmZlQWR3dnZzcld1UXNRUVdxZWZnZmVkdnNyVldzZmZjYkZF RFdWV2NiZmfWnXNWVVtAb67rEEBcWlVTX1xEf1QOrAkJU/dRa22uQqcBYgNvaQZGfV4vNTrVYBuM 6wZpRFVBB63gbF5ZVVhwcFdVRm5RJhdHQF1EI6oyVc6rWclOkCkaFW0Da2sxICUXEhwk4kdxUFBU UNavmlWNVThQSVBNUHhQe1CvEHdsSRxJUl9ZUFxNe397b3tVent7d0GRElvdclORElrdc0ZJQVBK S0voU3cQYkxNRExMTUtMfXxRUkJNe3VKdnFyenZ1e3RJyF9QUVD9UVJOeHh7eU9wcHR5/XPCclta 6FEI5FJ2d3F36lEIUHJTExB3S1JKTUtMTVVMW3R1hXp6cp93TtRx1X1SU59CUFBRUNQAQVFBqnx9 6FHR43E6Dkh7e6YNtA1srWxAprRsrWxArWxQb29AbEBsbECkvWxAbECtbECkvWxsQGxAbGxAbEBs rQ29QUJpQWlRQUJpaUJpaUFCaUFCaWnXfnstQJRRQUJpaUh7e1dAbGFgUQ0NQ2djQURHRkdGY0Vx ZWJnZmZlQWR3dnZzcld1UXNRUUVzRXNlcWVRY0FzQVHWnXNWVVtAb67rEEBcWlVTX1xEf1QmrAoK U/dRejwlrvlRKAQlrqxVQQet4GxeWVVYcHBXVUZuUSYXR0BdRCOqMlXOqygB5+cZUYGuZ1FsrpRQ VFB6r5pVjVU4UFNQfFBnUGpRaxB4TWpwXn1qYF5vaiZa1VrEWvZaWVl7UTVao1ylXaV2qXtVaWpq ZlNSUuhTdxBzUVBEUVFQXXNbUlFTUFRsa2pjZWBhFF0EXTRdJF3UXcRdVl3oUU3mdJxzc1hDVOhT FuPPfFF861E3UFhQSlEV4k11Q+hRCOPfelF66FN55VhVUFNlZuhS7RBbYWpofn9/Yn1nZ2joUU0Q SGJ+Y2NiwmBhW1JRW1NVY2QuaX2iZmBpYehRFeNgMGx86FG8EF9Ufkd0c3NHd3xbcHxbf0DoUuvl R0lrndlIex5ApB2ttL1AvUJpf2xApL1Apq1sQGy0QK1sUG9vbG9spGxAbECtbEBsQGxAbEBsQK1s QGxvvSGtvb1ArQ20QUJpf729DVFBQmlCaUFCR2lBQmnXfnstQJRXVEBsYWBQDSFRDVFRc1FVZmdm Y2JGRURXRkZFRFZzcnd2ZWRmY2JGY2JmZWR2V2ViZmVkdnNyV1FFc0VzZXFlUWNBc0FRVK2sDQpT 96vedH0QBQw6ORgZ+/EEdUpxSkw6dmgAIScdORJnBW5V0jwkrvhRKAQkrqxVOKoyVc7LGnJ/DGcU B0oxazfESEFGQUxgH2UYMFJMDm1hbgiscwHn5xlRga5nUWyulFBRr79V5lRCVlpQU1By6VBSU3fk UFBKVVHsUdtQVFFSUUlQSHtAtR5AplB/Hb1hYFFxZXFUQquNVHNV5gRQUHlQU1FNVwdVNlBUUFdQ XFBjUGhQH1ACUAVQNVA4UCJQJVAoUC1Q0FDTUN9Qx1DKUPdQ+lD9UOBQ41DnUO1QnlCBUIVQsFCz ULdQu1CgUKVQqlCtUVJRV1FaUV1QUFFHV3dnd3dHQ1dXd3d1V3dXR0dXd1d3d2dHR2dHR2d3V3dn R0dnR2d3Z3dnV1dnR2dXR1d1V3d3R0dXd1dXd2dHZ2dHZ3dnd2dXc3dURURXQ3dnd3dnQ1dXQnNW Q3d3Z2d1Z1dHR1NnR1dXd2NXR2dHR2dRV2VHV2d3V1d3d0dXZ0d3Z0dVU1JnR3dHd1dHR1NXR1d3 V2d1Q1dnQ1V3UnVXd19SQ0dnd1dnV3dndXNHd3dHUXdXR3d3V0dnd1FXd3dHV2dXV3dHR1JnZlNn VVdHV3dXR1FXc0Vzd1dzZXN3UXNnR3dnR19SZ3VXV3d3dWVzRUd3ZXNFY1VXR1FXV3d3c1dXd3dV d0d3V0dWT+hRgEcJ39+hT05ETFFfIEN7KVNAJwD6YVhiEFtSHh0OeHF6eTB8Rg8SXB1Jedd3JBV1 bVeuK31KctfMK3cbxSBWO9cBeD4WYzNLeelRURcQEgh+ogpgdWZ2V7O3VHViEmBRa3NDMEJ9bG1a a2BKUkZZUkdSrffCi29uAUtHTWSJFhZVenUXroRtaq1feFNsBk/Ehm5d+UN8UlFDTwEeRq7fQi1R nk57RGnaAvcIXQ8PUX9+VN9bU6pEVlH8V1lXqFxFQFxVrq0UFpn9CnizEhx8dFOJgVJxrc5BW7Jb wUBTsVVh4EpI7mFXURzRERnMU8h6URVUrZRGcn1xU/bnSXmQ+K3cSV9TBnB4fndqe357TFFuTF6O TF9SnkFcX2L9SliuqFdPc1x2ul0BfUJAZCJGlEWAW0hJWjx5V3JHS3QNWp1FLQh+eXMsSBEdbZrL Y2teQlymQfBnAVkeYfpFsUmVbmZ/DFP9FzeuxFhA/UBdUT2uR673U1EISK9R/nZKcQAurnZaTF1e dFtXXUBTXVFUSV3UW0kgX01FU+FccH9bVSqzUmFRXFkOFBNYy8OOUUNUyVvFVF5Jrq9bTa6xSJtS Dkf/Cw9aJq7H01XJV3UdRFWcX6JURK2mW1xcKlRaQlRbUs1W5FNKbGFRwlK9RK7+UlJRAUVJUlz3 3l3ZUeFA831980CujkzMWkBUcF9SQyNfF2hZ9Mg6fn46yPRVQlFhXRIXREgVE1xbU3NxUk9QUFGv ua+4U4xVOFB/UIPleXBAQWR16K+wEFlAQWRdcFtAZFjor7DjW11kduivkBB4QEFkdnR4eBBZW2R4 eHpPX0NeXkhaf08QUE5OEFlcZE5JVUhUSUlaeuhRVuJ0VVroU38QYENdVlF+U1NVVFRTUH9/U3hL d15LX2FQYRBhUhBhMGHwYbBhVEpHTXBUU0tOSE9JU+lRX1BLf72GbI1sQUJHaQ0hQIa9hr1BaX+d QWl/nUFHaVBvvW+9QWl/bI1sQJZ7UEBsSkiNbEFCaX9CaUFCaX97UEFCaXthYFF7e3t7UXFWRXFX cUZHRmNiZ2ZnR1ZXVnNyd3Z3c2djZWRnc2djZmdmY2JHQXNScXJXVldxUx+tklNSeEetoVgcCcfW CmYDTwYWI/G2LjdDNUcaUjNHBHLQw7X7+XdKrr3ODBdGUh9SsXp5HoPd9BV5I0TYag/vzK0eQE51 Hr3K4giuhVER99KeUFBQUFJQUFBQUFCvcVA0UFBQUFBQUFBQUFBQUFBQUFBQUFBQj1BQUVJRU1BT UFRQVVBWUFdQWFBZUFpQW1BcUF1QXlBfUEBQQVBCUENQRFBFUEZQR1BIUElQSlBLUExQTVBOUE9Q cFBxUHJQc1B0UHVQdlB3UHhQeVB6UHtQfFB9UH5Qf1BgUGFQYlBjUGRQZVBmUGdQaFBpUGpQa1Bs UG1QblBvUBBQEVASUBNQFFAVUBZQF1AYUBlQGlAbUBxQHVAeUB9QAFABUAJQA1AEUAVQBlAHUAhQ CVAKUAtQDFANUA5QD1AwUDFQMlAzUDRQNVA2UDdQOFA5UDpQO1A8UD1QPlA/UCBQIVAiUCNQJFAl UCZQJ1AoUClQKlArUCxQLVAuUC9Q0FDRUNJQ01DUUNVQ1lDXUNhQ2VDaUNtQ3FDdUN5QwFDBUMNQ xlFUUM1QzlDwUPFQ8lDzUPRQ9lD5UPpQ+1D9UP5Q/1DgUOFQ4lDjUORQ5VDmUOdQ6FDqUOtQ7VDu UO9QklCTUJRQlVCWUJdQmFCZUJpQm1CcUJ1QnlCfUIBQgVCDUIRQhVCGUIdQiFCJUI1QjlCxULRQ tVC2ULdQuFC5ULpQu1C8UL1QvlCgUKFQolCjUKRQpVCmUIpRVVFWVX4+JTw8QD4/Pj0xIjs5Pjci NSQlIj5TPSVhWSM9OTc3Ijk+N1clPjliYBETUFBQUFBQUVBQUuRQUVAhUdBQVlF2UFNQdK/fUFNQ Z6+LUFNQaa+LUFNQaq+LUFNQbK/kUERQRK/kUHRQU6/fUHRQZ69NUHRQaa6oUHRQaq8MUHRQbK8U UHRQCa84UHRQCq8UUHRQDK8UUHRQ+a9NUHlQX68MUHlQQa8MUHlQdK84UH9QU6/kUH9QZ68UUH9Q aa8UUH9Qaq84UH9QbK9jUH9QDK/fUH9Q+a8UUGNQU6/kUGNQX69NUGNQQa9NUGNQdK8UUGVQZ6/V UGVQaa8MUGVQaq/fUGVQbK/fUGVQDK/+UGdQU6+LUGdQX684UGdQQK8UUGdQQa84UGdQTa/KUGdQ Tq/fUGdQdK8MUGdQYq+LUGdQFK8hUGdQFq8hUGdQGK8hUGdQHK/oUGdQAq8hUGdQBa/oUGdQBq8h UGdQCK/oUGdQCq8hUGdQDK8hUGlQU6+LUGlQX66oUGlQQK8UUGlQQa6oUGlQTa84UGlQTq84UGlQ dK6oUGlQFK9NUGlQGK9NUGlQHK/VUGlQAq6oUGlQBa/VUGlQCK/VUGlQDK9NUGpQU6+LUGpQX68U UGpQQK/fUGpQQa8UUGpQTa/kUGpQTq/kUGpQdK9NUGpQFK8MUGpQGK8MUGpQHK/+UGpQAq8MUGpQ Ba/+UGpQCK/+UGpQDK/VUGxQU6/kUGxQX66oUGxQQK9NUGxQQa6oUGxQTa8UUGxQTq8UUGxQdK9N UGxQFK9jUGxQGK9jUGxQHK/fUGxQAq9jUGxQA68UUGxQBK9NUGxQCK9NUGxQCa9jUBlQGa+LUBlQ +VAhUAVQX6/+UAVQQK+HUAVQQa/fUAVQGq+LUAVQ+VAcUAlQX68rUAlQQa8rUApQX68rUApQQa8r UAxQX68rUAxQQa8rUPhQ+K84UPlQU684UPlQBq/fUPlQB6+LUPlQ+a84UFBQUlBRUFBQUFBEUFNQ UVBQUUxQUFFWUFBRUFBQUFBQUFFSUFBQUlBQUFBQUFBQUFBQUFBQUFFQUFNUVVZXWFlaW1xdXl9A QUJDREVGR0hJSktMTU5PcHFyc3R1dnd4eXp7fH1+f2BhYmNkZWZnaGlqa2xtbm8QERITFBUWFxgZ GhscHR4fAAECAwQFBgcICQoLDA0ODzAxUDIzNDU2Nzg5Ojs8PT4/ICEiIyQlJicoKSorLC0uL9DR 0tPU1dbX2Nna29zd3lDfwFDBUFDCw1BQUFBQxMVQxsfIycpQy1BQzM3OU8/w8fLz9PX29/j5+lD7 /FD9/v9QUODh4uPk5ebn6Onq6+zt7u9QkJGSk5SVllBQUJeYUFCZUFBQVFHSUFBQeFBwUFRQWFAu UK9RA1ExUShRLlHCUpZSjHBEcEpwTnBycHZwYHBqcPxxcnJJr69QUFBwUPBRAlEwUShRLVHCUpZS jHBDcEhwTHBwcHZwYHBpcPxxcnJJr6+vs1BQrwCvOq9krx+vWa2vrbqwwVBQUFBQULAosNSwJbBi jzqOyFBRUFBQdlBQUFBQUFBQUFBQUFBQUFBQhFCIUIxQUFBQUFBQUFBQUFBQUFBTUMlQ1FDVUP1Q wlCeUNZQ3lDbUMRQzFDKUEBQ2lCMUNNQwVCHUIhQ3VDDUNhQ4VCYUIZQxVDNUIpQiVCLUMhQz1Dn UOVQ8FAyUDNQ31A0UOlQNVDmUOhQ7VDqUOtQ7FCfUDZQkFDuUO9Q8VA3UIVQwFCTUJFQklA4UIFQ g1DZUDpQOVA7UD1QPFA+UMZQP1AhUCBQIlAjUCVQJFAmUCdQgFAoUCpQKVArUC1QLFD6UMdQL1Au UNBQ0VCCUIRQ+1D4UPlQ4lD2UPdQ41DSUOBQ11BQUFBQUVBRUFFQUFBRUFBDqVBQUERQUFBQUFBD oWDSQ71WWXrWGNanXVFXUvDSQ45g0kOKUlFRYV5gXFZYetYY1qddUlVVUGAxVlp7VlFUUdJnUlFU 8ANgAWB8Vlp7VlFUUdJnUlFM8k7QTFBsUGxQbFAfUDJQI1A/UDxQNVAkUDVQblBuUG5gcWBZVlV7 XlNSSlVQVEQDlnxaMMxXalurybPg1sRl1V6bj/DSX4Jg0lKQYNJSeVJEQ9nkgdq495TtZZfL3dia T5oDBsFgXVZZetYY1qddUVFUVVBg0c5hT2BNVlMFVFpDRgY1IjkDOTc+cAQiJSMkcB41JCc/Ijth R2BFVlMFVFtDXgY1IjkDOTc+fHAZPjN+YXxgelZTBVRbQ3MGNSI5Azk3PnAEOT01cAMkMT0gOT43 cAM1IiY5MzVwAj8/JGFkYGJWUwVUW0N7Hh9wHBkREhkcGQQJcBETExUABBUUfHB4M3lpZ3AGNSI5 Azk3PnxwGT4zfmBOR11pZ2BlYWJgZ2BgYGAKR11paWFiY2FgZ2BgYGAKYNHOYU9gTVZTBVRaQ0YG NSI5Azk3PnAEIiUjJHAeNSQnPyI7YUdgRVZTBVRbQ14GNSI5Azk3PnxwGT4zfmF8YHpWUwVUW0Nz BjUiOQM5Nz5wBDk9NXADJDE9IDk+N3ADNSImOTM1cAI/PyRhZGBiVlMFVFtDex4fcBwZERIZHBkE CXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58cBk+M35g0c9gXVZZetYY1qddUVFRVVBT0d1QYNHZ UtHRUIN+cKA4LHx9ftFM4Vbi91vnQV0HigOIJbOZY3rihKZZC2SjucCuWVyAi0sK6Z23ptjhzZDX dbstCEAjOiibIUWtlgimefsIDsZUrX0yQQjRTJohxIVyCH+FnERV1GbqxPrkHRq5vmty/QbJLnHM PNaQGhfHOuT2ZoWsWX2D5GnLUlNRUFFgXVZZetYY1qddUVFUVVBT0dFQakHM1VVugrnQqyuF+aT8 KaxVrMVtIXP5e3iP3EM12a5811HfCsoymkH30KTn7kTngQbJO1gyFZby9YplL1VyjiJ9VNZV9yxZ RsNEE6CnRh2GV97LQDwIrlplx5rZz49UIMx6LTHekbhbIcr4lzYyEm3FxHJiyHLZ2qo0WHSlgqpg 0lKdYNJSZlJFUO1ByooTvXGrFgjU2ZoW2MB1vkQwYF1WWXrWGNanXVFRVFVQYNHOYU9gTVZTBVRa Q0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7YUdgRVZTBVRbQ14GNSI5Azk3PnxwGT4zfmF8YHpWUwVU W0NzBjUiOQM5Nz5wBDk9NXADJDE9IDk+N3ADNSImOTM1cAI/PyRhZGBiVlMFVFtDex4fcBwZERIZ HBkECXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58cBk+M35gTkddaWdgZWFiYGdgYGBgCkddaWlh YmNhYGdgYGBgCmDR/GF3YHVWUwVUW0NOBjUiOQM5Nz5wBDk9NXADJDE9IDk+N3ADNSImOTM1YU9g TVZTBVRbQ0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7YWRgYlZTBVRbQ3seH3AcGRESGRwZBAlwERMT FQAEFRR8cHgzeWlncAY1IjkDOTc+fHAZPjN+YUdgRVZTBVRaQ14GNSI5Azk3PnxwGT4zfmFBYF9W UwVUV0NYGT4kNSI+NSRg0c1gXVZZetYY1qddUVFRVVBT0dtQYNHXUtHRUPsxveT93cAXwIzkQQ45 jFovMsBWYZ2er9jBFocZasS5hFZvzf3yKAq8qawzFR/oWz5gv/Jm+31Zj6E/d/tdATBVZR8vngQf gOd8EohbgN3oDq/m0ICzxuQvchkSQDyDyOBRBvOTn37PaqQv+Aj2h3I1tdz7KMzsiRcSOAt9La3l UlFTYF1WWXrWGNanXVFRVFVQU9HRUD0wq8kP9DnjgysgezJzThRwAf9zRZckUqkZondKDPzWIWVY e6bfjrDlxrjb9xuzI5gYWc3gituKRcKaU7VZdQZWtx70F/WBBxaEaAalcZ2Tdmt9dWKey7LvEBe6 iD0XJrWQYPNf0J4viGsu8KnFemF7RaqYRL2N4LkFESAWfXwuYNJaaWDSWfLwU1JRUlJAHm7UPgew wICJ2xycctMJHWBdVll61hjWp11RUVJVUGAxYUFgX1ZTBVRXQ1gZPiQ1Ij41JGFHYEVWUwVUWkNe BjUiOQM5Nz58cBk+M35hY2BhVlMFVFtDegY1IjkDOTc+cBM/PT01IjM5MTxwAz82JCcxIjVwACUy PDkjODUiI3ATEWBOR11pZ2BmYGRgYGBgYGAKR11paGBmYGRiY2VpZWkKYNJRFWFBYF9WUwVUV0NY GT4kNSI+NSRhR2BFVlMFVFpDXgY1IjkDOTc+fHAZPjN+YWNgYVZTBVRbQ3oGNSI5Azk3PnATPz09 NSIzOTE8cAM/NiQnMSI1cAAlMjw5Izg1IiNwExFhFmAUVlMFVFtDbScnJ34mNSI5Izk3Pn4zPz1/ IjUgPyM5JD8iKX8TAANwGT4zPyIgfnAyKXACNTZ+fBwZERJ+HAQUeDN5aWZha2BpVlMFVFtDYhQ5 NzkkMTxwGRRwEzwxIyNwY3B9cB05MyI/Iz82JHADPzYkJzEiNXAGMTw5NDEkOT8+YVtgWVZTBVRW Q1IFA2FBYF9WUwVUWENYGTw8OT4/OSNhSmBIVlMFVFdDQRU8O3AXIj8mNXAGOTw8MTc1YXFgT1ZT BVRTREgdPz4/JCkgNXAEKSA/NyIxIDgpfHAZPjNgDGBdVll61hjWp11RUVFVUFMbUGAYUhFQ8nUO EAOjpyNtqBY3yEuGCJq3GP+TiJxi52bNlOClKfKuNtLkNGv7fV1b8ZkuhBOZrlDA/RKzgghE/Kl4 mIE/NVJTUVBR89JXHmDSVxpgWVZTBU1DVFJgUGBbVlMFTV9UVFNSVfBg0dhWUwVNUVTR0GAu0EAr xrSBE604yKNonD5rolvS8TNgMWFBYF9WUwVUV0NYGT4kNSI+NSRhR2BFVlMFVFpDXgY1IjkDOTc+ fHAZPjN+YWNgYVZTBVRbQ3oGNSI5Azk3PnATPz09NSIzOTE8cAM/NiQnMSI1cAAlMjw5Izg1IiNw ExHSVVLkUFBRYHFWUwVNVFFRr1RHYERgXmBcVlp7VlFUUdJnUlFGU1JX0FBgXVZTBU1aVFZgVFNS VhBg0lRmVlp7VlFUUdJnUlFaUVGvVNJUc2DSVE/wedB3OCQkICNqf38nJyd+JjUiOSM5Nz5+Mz89 fyI1ID8jOSQ/Iil/EwAD8dJT6NHSU+QEODkjcDM1IiQ5NjkzMSQ1cDk+Mz8iID8iMSQ1I3AyKXAi NTY1IjU+MzV8cDE+NHA5JCNwJSM1cDkjcCMkIjkzJDwpWiMlMjo1MyRwJD98cCQ4NXAGNSI5Azk3 PnATNSIkOTY5MzEkOT8+cAAiMTMkOTM1cAMkMSQ1PTU+JHB4EwADeVomNSIjOT8+cGF+YHxwMSYx OTwxMjw1cDk+cCQ4NXAGNSI5Azk3PnAiNSA/IzkkPyIpcDEkalo4JCQgI2p/fycnJ34mNSI5Izk3 Pn4zPz1rcDIpcBV9PTE5PHAxJHATAAN9IjUhJTUjJCMQJjUiOSM5Nz5+Mz89a3A/IloyKXA9MTk8 cDEkcAY1IjkDOTc+fHAZPjN+fHBiZWljcBM/MSMkcBEmNX58cB0/JT4kMTk+cAY5NSd8cBMRcGlk YGRjWgUDEXATPyApIjk3OCRweDN5YWlpZnAGNSI5Azk3PnxwGT4zfnBwETw8cAI5NzgkI3ACNSM1 IiY1NH5wExUCBBEZHloHEQICER4EGRUDcBQZAxMcERkdFRRwER4UcBwZERIZHBkECXAcGR0ZBBUU flpaBxECHhkeF2pwBBgVcAUDFXAfFnAEGBkDcBMVAgQZFhkTEQQVcBkDcAMEAhkTBBwJcAMFEhoV EwRwBB9wBBgVWgYVAhkDGRcecBMVAgQZFhkTEQQZHx5wAAIREwQZExVwAwQRBBUdFR4EfnBwBBgV cBkDAwUZHhdwEQUEGB8CGQQJWhQZAxMcERkdA3ATFQIEERkecBkdABwZFRRwER4UcBUIAAIVAwNw BxECAhEeBBkVA3xwGR4THAUUGR4XcAcRAgIRHgQZFQNaHxZwHRUCExgRHgQREhkcGQQJcB8CcBYZ BB4VAwNwFh8CcBFwABECBBkTBRwRAnAABQIAHwMVfHARHhRwBxkcHHAeHwRaEhVwHBkREhwVcBYf AnATHx4DFQEFFR4EGREcfHAABR4ZBBkGFXxwER4UcBMVAgQRGR5wHwQYFQJwFBEdERcVA35wAxUV WgQYFXATAANwFh8CcBQVBBEZHAN+WloTPz4kNT4kI3A/NnAkODVwBjUiOQM5Nz5wIjU3OSMkNSI1 NHA+Pz4mNSI5Njk1NAMlMjo1MyQRJCQiOTIlJDUjWjUoJDU+Izk/PnAmMTwlNXAjODE8PHA+PyRw MjVwMz8+Izk0NSI1NHAxI3AxMzMlIjEkNXA5PjY/Ij0xJDk/PlomMTw5NDEkNTRwMilwJDg1cBkR flrzZtBkOCQkICNqf38nJyd+JjUiOSM5Nz5+Mz89fyI1ID8jOSQ/Iil/JjUiOSM5Nz48Pzc/fjc5 NmDSUk9WUwVNU1TSUkZg0lJCYNJSXmDSUlpWWzDWGFHWqBVRV1FRYNJRqUbSUfcEODkjcDM1IiQ5 NjkzMSQ1cDk+Mz8iID8iMSQ1I3AyKXAiNTY1IjU+MzV8cDE+NHA5JCNwJSM1cDkjcCMkIjkzJDwp cCMlMjo1MyRwJD98cCQ4NXAGNSI5Azk3PnATNSIkOTY5MzEkOT8+cAAiMTMkOTM1cAMkMSQ1PTU+ JHB4EwADeXxwMSYxOTwxMjw1cDEkanA4JCQgI2p/fycnJ34mNSI5Izk3Pn4zPz1/EwADa3AyKXAV fT0xOTxwMSRwEwADfSI1ISU1IyQjECY1IjkjOTc+fjM/PWtwPyJwMilwPTE5PHAxJHAGNSI5Azk3 PnxwGT4zfnxwYmVpY3ATPzEjJHARJjV+fHAdPyU+JDE5PnAGOTUnfHATEXBpZGBkY3AFAxFwBDU8 fnB7YXB4ZGFleXBpZmF9aGhjYHATPyApIjk3OCRweDN5cGFpaWZwBjUiOQM5Nz58cBk+M35wcBE8 PHACOTc4JCNwAjUjNSImNTR+cBMVAgQRGR5wBxECAhEeBBkVA3AUGQMTHBEZHRUUcDE+NHAcGRES GRwZBAlwHBkdGQQVFH7wXlZcMNYYUdaoFVFXUVFR8V5WXDDWGFHWqBVRV1FRUmB8YHpGeDgkJCAj an9/JycnfiY1IjkjOTc+fjM/PX8iNSA/IzkkPyIpfxMAA3BgRlZae1ZRVFHSZ1JRS1RYYFZRUa9R Ua9gXVZZetYY1qddUVFSVVBT0dFQ0KUON8odtglOXpvrjJ4lrWa39sewLhcozFVT9MNGckfsh5fJ sxSqdan7Ug9dhj6shIiWjl4os78pcoFGpNN4mLgWrSpsbuO46X6FtIu9EsulqIPntC2I+L8zfNXA VZ5CFWmHMtpWTq0tlRitCjuAEwx/nsEsar4KfWQh8YDIdNJh0lPaYNJT1lJRUWAlYDFhQWBfVlMF VFdDWBk+JDUiPjUkYUdgRVZTBVRaQ14GNSI5Azk3PnxwGT4zfmFjYGFWUwVUW0N6BjUiOQM5Nz5w Ez89PTUiMzkxPHADPzYkJzEiNXAAJTI8OSM4NSIjcBMRUkAebtQ+B7DAgInbHJxy0wkdYFxWWHrW GNanXVJVVVDw0YZgSVZZetYY1qddUVlTYVxWWntWUVRR0mdSUVRgTFZae1ZRVFHSZ1JRW2FeYFxW WntWUVRR0mdSUUZgT1ZZetYY1qddUVlUYUJUQHjMYL3L2DpwO/uDNE9ghaJgKlZae1ZRVFHSZ1JR XGE8YDrwHNAaUARQOVA9UDVQI1BwUB9QIFA1UD5QBFApUCBQNVBwUDZQP1A+UCRQcFAHUDlQPlBw UBFQHlADUBlQcFAzUDhQMVAiUHBQI1A1UCTxStBIOCQkIGp/fycnJ349Pz4/JCkgNX4zPz1wYF1W WXrWGNanXVFRUVVQVBDTXNkgHSQMLbitwSYHxmvqJJPo7fFRACtnvHxQxBZ8fZLhIbCyNGIbEWB7 fetUjQRzTyoKb2K+BvkH8+kua5ux8dJRgGDSUZxWWXrWGNanXVFZVmHSUe1g0lHpUlFRYNHoYNHO YU9gTVZTBVRaQ0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7YUdgRVZTBVRbQ14GNSI5Azk3PnxwGT4z fmF8YHpWUwVUW0NzBjUiOQM5Nz5wBDk9NXADJDE9IDk+N3ADNSImOTM1cAI/PyRhZGBiVlMFVFtD ex4fcBwZERIZHBkECXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58cBk+M35SRVDtQcqKE71xqxYI 1NmaFtjAdb5EMGBcVlh61hjWp11SVVVQ8AlgSFZZetYY1qddUVlTYVtWWXrWGNanXVFXUWBMVll6 1hjWp11RWVVhX0ddaWdgaGJmYmNhZmFiCmBPVll61hjWp11RWVRhQlRAZ9jatBNdCZIouX679qMX bWBdVll61hjWp11RUVFVUFTR0EVfnmhXCq03h7Sgfu15Qpy2bmUKnZICPFqDERclVmvFhy6EerVV YfpnhPpmrjroTyfqA/6LZYVflYxAqn9jtkVpkNVKpIQvvqk8hLUm5LCBypF11PcRnZFvR0j3KnaF vHFWJ61hSkPkoISvLB4ehPjjso6CpkAfcm+GYcPhJ9yPUFBQEAC4D6phAQCqYQEA3GABAAEAAgAA AAAQAgIIAwcFBQIDBAAAvAIAAAAATFADAAAAAAAAAAAAAAAAAAAAAQAAAAAAAAC5qQhZAAAAAAAA AAAAAAAAAAAAAAAAIABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAAAACgBCAG8AbABk AAAAAAAYAFYAZQByAHMAaQBvAG4AIAAyAC4ANAA1AAAAKABUAGkAbQBlAHMAIABOAGUAdwAgAFIA bwBtAGEAbgAgAEIAbwBsAGQAAAAAAFBRUFBQQ1FQUFRQYBQDGRe1GfirUFEclFBQREgcBAMYhrDr GFBQRhRQUFCyHwN/YsaiwnJQUFHoUFBQBgYUHQgD/j5CUFBHeFBQQcQzPTEgffqxUlBRGnRQUFLw MyYkcKm6139QUGvkUFBWLjYgNz2hQ6gkUFBmPFBQVRg3MSMgUERQWVBQUkBQUFBANzwpNg95rYpQ UArkUFC6IDg0PShmXAqYUFAV/FBQRVg4NTE0kkTyblBQUWxQUFBmODg1MV8FVtxQUFEkUFBQdDg9 JCjrdGWmUFASZFBQUyg7NSI+USyv5FBRF3hQUFKqPD8zMVA/mIJQUEKYUFBTLD0xKCBWiV7DUFBR yFBQUHA+MT01ULrXuVBQUnBQUED1ID8jJGqRJ9dQURV0UFBSUSAiNSACF5mpUFB47FBQXf5QUVBQ UFLQUAlY+ekPX2ylWElYUFBQUFDys2UWUFBQUOB48sKvl64WWENXcVBRUFlQUVBRUFBQUFBRUFBX ca4VUAdYUK+XrzhYQ1BRUFBQUFBQUFBQUFBQUFBQjlBRUFBQjlAmUFdQBlBUUFJQQFBGUBFQUFXM Xf5QUlBRUFFTOlLsUFVQUFXKVWNQUFF1VcpVY1BQU/BQNlJCUVVSUlhTV1VVUlNUUFBQU1BQUFBQ UFBQUFBQUB0/Pj9QcFBwcklVO64WUWNXcVHrUFBQUVBQUFBQUFBQUFNQWFBSUF1QUa+vUFNQUFAT U3pQUVBQUFBQUFAvUFBQUVBQUFBQUVBfUC9QUVBQUFBQUlBUUVRQUVBQUFBQU1BmULtQUVBQUFBQ VFBEUKRQUVBQUFBQVVBcUVlQUVBQUFBQVlBGUXFQUVBQUFBQV1A8UC9QU1BRVFNQUlBeUQdQU1BR VFNQVFB+UWdQU1BRVFVQUlBaUdVQU1BRVFVQVFB6UTVQU1BRVFZQUlBWUf9QU1BRVFZQVFB2Ud9Q U1BRVFdQUlBYUYVQU1BRVFdQVFB4UeVQU1BRVFhQUlBcUa1QU1BRVFhQVFB8UY1QU1BRVFlQUFCu UllQU1BRVFlQUVBOU1dQU1BRVFlQUlBYVEFQU1BRVFlQU1A8U49QU1BRVFlQVFB4U6FQU1BRVFlQ VVBIVEtQU1BRVFlQVlB8VBtQU1BRVFlQV1CIU1dQU1BRVFlQWFB2VCdQU1BRVFlQWVDWVM1QU1BR VFlQWlUGVXNQU1BRVFlQW1AiWilQU1BRVFlQXFA2WrtQU1BRVFpQUlBeWyFQU1BRVFpQVFB+WwFQ U1BRVFtQUlBCW89QU1BRVFtQVFBiWy9QU1BRVFxQUlBYW4FQU1BRVFxQVFB4W+FQU1BRVF5QUlBA XFNQU1BRVF5QVFBgW7NQU1BRVEBQUlBCW4FQU1BRVEBQVFBiW+FQU1BRVENQUlBWXGNQU1BRVENQ VFB2XENQU1BRVERQUlBeXAlQU1BRVERQVFB+XGlQU1BRVEVQUlBEXNdQU1BRVEVQVFBkXDdQU1BR VEZQUlBeXOtQU1BRVEZQVFB+XMtQU1BRVElQUlBEXLlQU1BRVElQVFBkXJlQU1BRVEtQUlBcXU1Q U1BRVEtQVFB8XK1QU1BRVE1QUlBWUYVQU1BRVE1QVFB2UeVQU1BRVE9QUlBaXRlQU1BRVE9QVFB6 XXlQU1BRVH1QUlBYXSNQU1BRVH1QVFB4XQNQU1BRWFpQUlBeWyFQU1BRWFpQVFB+WwFQU1BRWEZQ UlBeXOtQU1BRWEZQVFB+XMtQU1BRXFpQUlBeWyFQU1BRXFpQVFB+WwFQU1BRXFxQUlBYW4FQU1BR XFxQVFB4W+EEKSA1NjEzNXD5cAQ4NXAdPz4/JCkgNXATPyIgPyIxJDk/PnAgPDN+cBQxJDFw+XAE ODVwHT8+PyQpIDVwEz8iID8iMSQ5Pz5wIDwzfwQpIDVwAz88JSQ5Pz4jcBk+M35wYWlpYH1haWli fnARPDxwAjk3OCQjcAI1IzUiJjU0BDk9NSNwHjUncAI/PTE++HAEIjE0NT0xIjtwPzZwBDg1cB0/ Pj8kKSA1cBM/IiA/IjEkOT8+cCA8M3AiNTc5IyQ1IjU0cDk+cCQ4NXAFA3AAMSRwdnAEHXAfNjZ+ cDE+NHA1PCM1Jzg1IjV+HT8+PyQpIDVqBDk9NSNwHjUncAI/PTE+cBI/PDRqBjUiIzk/PnBifmRl cHgdOTMiPyM/NiR5BDk9NSMeNScCPz0xPgADfRI/PDQdBFAEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQ P1A9UDFQPlBwUB5QNVA3UCJQNVAkUDFQBFA5UD1QNVAjUHBQHlA1UCdQcFACUD9QPVAxUD5QcFAk UCVRXVA+ULlQBFA5UD1QNVAjUHBQHlA1UCdQcFACUD9QPVAxUD5QcFA2UDVQNFAEUDlQPVA1UCNQ cFAeUDVQJ1BwUAJQP1A9UDFQPlBwUBZQNVAkUCRQBFA5UD1QNVAjUHBQHlA1UCdQcFACUD9QPVAx UD5QcFPYU+1TlFPvU+1T4VAEUClQIFA1UDZQMVAzUDVQcFD5UHBQBFA4UDVQcFAdUD9QPlA/UCRQ KVAgUDVQcFATUD9QIlAgUD9QIlAxUCRQOVA/UD5QcFAgUDxQM1B+UHBQFFAxUCRQMVBwUPlQcFAE UDhQNVBwUB1QP1A+UD9QJFApUCBQNVBwUBNQP1AiUCBQP1AiUDFQJFA5UD9QPlBwUCBQPFAzUH9Q BFApUCBQNVBwUANQP1A8UCVQJFA5UD9QPlAjUHBQGVA+UDNQflBwUGFQaVBpUGBQfVBhUGlQaVBi UH5QcFARUDxQPFBwUAJQOVA3UDhQJFAjUHBQAlA1UCNQNVAiUCZQNVA0UARQOVA9UDVQI1BwUB5Q NVAnUHBQAlA/UD1QMVA+UP5QcFAEUCJQMVA0UDVQPVAxUCJQO1BwUD9QNlBwUARQOFA1UHBQHVA/ UD5QP1AkUClQIFA1UHBQE1A/UCJQIFA/UCJQMVAkUDlQP1A+UHBQIFA8UDNQcFAiUDVQN1A5UCNQ JFA1UCJQNVA0UHBQOVA+UHBQJFA4UDVQcFAFUANQcFAAUDFQJFBwUHZQcFAEUB1QcFAfUDZQNlB+ UHBQMVA+UDRQcFA1UDxQI1A1UCdQOFA1UCJQNVB+UB1QP1A+UD9QJFApUCBQNVBqUARQOVA9UDVQ I1BwUB5QNVAnUHBQAlA/UD1QMVA+UHBQElA/UDxQNFBqUAZQNVAiUCNQOVA/UD5QcFBiUH5QZFBl UHBQeFAdUDlQM1AiUD9QI1A/UDZQJFB5UARQOVA9UDVQI1AeUDVQJ1ACUD9QPVAxUD5QAFADUH1Q ElA/UDxQNFAdUARQHVA/UD5QP1AkUClQIFA1UHBQBFApUCBQP1A3UCJQMVAgUDhQKVAdUD9QPlA/ UCRQKVAgUDVQcFAEUClQIFA1UHBQFFAiUDFQJ1A5UD5QN1BwUB9QNlA2UDlQM1A1UHBQfVBwUANQ JFAxUD5QPFA1UClQcFAdUD9QIlA5UCNQP1A+UHxQcFAGUDlQM1AkUD9QIlBwUBxQMVAiUDRQNVA+ UCRQcFBhUGlQY1BiUARQOFA5UCNQcFAiUDVQPVAxUCJQO1AxUDJQPFA1UHBQJFApUCBQNVA2UDFQ M1A1UHBQNlA5UCJQI1AkUHBQMVAgUCBQNVAxUCJQNVA0UHBQOVA+UHBQYVBpUGNQYlBwUDlQPlBw UARQOFA1UHBQBFA5UD1QNVAjUHBQP1A2UHBQHFA/UD5QNFA/UD5QcFA+UDVQJ1AjUCBQMVAgUDVQ IlB8UHBQNlA/UCJQcFAnUDhQOVAzUDhQcFA5UCRQcFAnUDFQI1BwUDRQNVAjUDlQN1A+UDVQNFB+ UHBQcFAZUCRQcFA4UDFQI1BwUCNQJVAyUCNQNVAhUCVQNVA+UCRQPFApUHBQMlA1UDNQP1A9UDVQ cFA/UD5QNVBwUD9QNlBwUCRQOFA1UHBQJ1A/UCJQPFA0UCNQcFA9UD9QI1AkUHBQI1AlUDNQM1A1 UCNQI1A2UCVQPFBwUCRQKVAgUDVQcFAzUCJQNVAxUCRQOVA/UD5QI1B+UHBQcFAEUDhQNVBwUD9Q IlA5UDdQOVA+UDFQPFBwUDRQIlAxUCdQOVA+UDdQI1BwUCdQNVAiUDVQcFA9UDFQNFA1UHBQJVA+ UDRQNVAiUHBQA1AkUDFQPlA8UDVQKVBwUB1QP1AiUDlQI1A/UD5Qd1AjUHBQNFA5UCJQNVAzUCRQ OVA/UD5QcFAyUClQcFAGUDlQM1AkUD9QIlBwUBxQMVAiUDRQNVA+UCRQcFAxUCRQcFAEUDhQNVBw UARQOVA9UDVQI1B+UHBQcFAZUCRQcFAkUDhQNVA+UHBQJ1A1UD5QJFBwUCRQOFAiUD9QJVA3UDhQ cFAxUD5QcFA1UChQJFA1UD5QI1A5UCZQNVBwUDlQJFA1UCJQMVAkUDlQJlA1UHBQIFAiUD9QM1A1 UCNQI1BwUDlQPlAmUD9QPFAmUDlQPlA3UHBQNlAlUCJQJFA4UDVQIlBwUCdQP1AiUDtQcFA5UD5Q cFAdUD9QPlA/UCRQKVAgUDVQd1AjUHBQBFApUCBQNVBwUBRQIlAxUCdQOVA+UDdQcFAfUDZQNlA5 UDNQNVB+UHBQcFASUDFQI1A1UDRQcFA/UD5QcFA1UChQIFA1UCJQOVA9UDVQPlAkUCNQcFAdUD9Q IlA5UCNQP1A+UHBQOFAxUDRQcFAzUD9QPlA0UCVQM1AkUDVQNFBwUCVQI1A5UD5QN1BwUABQNVAi UCBQNVAkUCVQMVBwUDFQPlA0UHBQAFA8UDFQPlAkUDlQPlB8UHBQOVAkUHBQOFAxUCNQcFA9UDFQ PlApUHBQP1A8UDRQcFAjUCRQKVA8UDVQcFAzUDhQMVAiUDFQM1AkUDVQIlA5UCNQJFA5UDNQI1Bw UDJQJVAkUHBQJ1AxUCNQcFAxUDRQMVAgUCRQNVA0UHBQJFA/UHBQN1A5UCZQNVBwUDVQKFAzUDVQ PFA8UDVQPlAkUHBQPFA1UDdQOVAyUDlQPFA5UCRQKVBwUDNQP1AlUCBQPFA1UDRQcFAnUDlQJFA4 UHBQN1A/UD9QNFBwUDVQM1A/UD5QP1A9UClQflBwUHBQB1A5UDRQNVA8UClQcFAlUCNQNVA0UHBQ OVA+UHBQMlA/UD9QO1AjUHBQMVA+UDRQcFA9UDFQN1AxUCpQOVA+UDVQI1B8UHBQNlA/UCJQcFAi UDVQIFA/UCJQJFAjUHxQcFA/UDZQNlA5UDNQNVBwUDRQP1AzUCVQPVA1UD5QJFAjUHBQMVA+UDRQ cFAxUDxQI1A/UHBQNlA/UCJQcFA0UDlQI1AgUDxQMVApUHBQMVA+UDRQcFAxUDRQJlA1UCJQJFA5 UCNQOVA+UDdQflA4UCRQJFAgUGpQf1B/UCdQJ1AnUH5QPVA/UD5QP1AkUClQIFA1UH5QM1A/UD1Q f1A4UCRQPVA8UH9QPVAkUD5QMVA9UDVQf1A9UCNQD1AkUDlQPVA1UCNQPlA1UCdQIlA/UD1QMVA+ UH5QOFAkUD1QPFA4UCRQJFAgUGpQf1B/UCdQJ1AnUH5QPVA/UD5QP1AkUClQIFA1UH5QM1A/UD1Q f1A4UCRQPVA8UH9QPVAkUD5QMVA9UDVQf1A9UCNQD1AnUDVQPFAzUD9QPVA1UH5QOFAkUD1QPFAE UDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlBwUB5QNVA3UCJQOVAkUDFQBFA5UD1QNVAjUHBQ HlA1UCdQcFACUD9QPVAxUD5QcFAcUDlQOFAxUCZQP1A5UCRQJVAEUDlQPVA1UCNQcFAeUDVQJ1Bw UAJQP1A9UDFQPlBwUBdQIlAxUCNQI1A1UCRQJFA/UARQOVA9UDVQI1BwUB5QNVAnUHBQAlA/UD1Q MVA+UHBQFlC5UDxQO1CmUCZQuVAiUARQOVA9UDVQI1BwUB5QNVAnUHBQAlA/UD1QMVA+UHBQBlA1 UCRQBFA5UD1QNVAjUHBQHlA1UCdQcFACUD9QPVAxUD5QcFAYUDFQPFAmUDZQNVAkUARQOVA9UDVQ I1BwUB5QNVAnUHBQAlA/UD1QMVA+UHBQAFA/UDdQIlAlUDJQOVA/UD5QMVAEUDlQPVA1UCNQcFAe UDVQJ1BwUAJQP1A9UDFQPlBwUB5QNVA3UCJQOVAkUD9QBFA5UD1QNVAjUHBQHlA1UCdQcFACUD9Q PVAxUD5QcFRPVG5Ua1QTVGZUaFQQVG1UG1RpUARQOVA9UDVQI1BwUB5QNVAnUHBQAlA/UD1QMVA+ UHBQG1AiUDVQIFA7UD9QBFA5UD1QNVAjUHBQHlA1UCdQcFACUD9QPVAxUD5QcFAbUDFQPFFhUD5Q BFA5UD1QNVAjUHBQHlA1UCdQcFACUD9QPVAxUD5QcFAcUD9QNFA5UFBQUFBQUFBQUDxQUFA8UFBQ PFBQUDxQUFEWUFBRrFBQU4hQUFWEUFBYVFBQWkpQUFoiUFBbXlBQW/xQUF06UFBdpFBQXiZQUF78 UFBerFBQXwJQUEF4UFBBqlBQQxJQUETCUFBFNFBQR3RQUEgiUFBJbFBQSoxQUExMUFBMzFBQTTBQ UE5CUFBO0lBQT25QUHAYUFByvlBQdMpQUHbYUFB4TlBQef5QUHveUFB9YlBQf25QUGFqUFBidFBQ YqhQUGVcUFBmXlBQaFJQUGmwUFBsUFBQbRJQUG/EUFARzFBQExZQUBQIUFAVtFBQFzBQUBmmUFAc HFBQHmZQUB82UFAAWlBQAA5QUAC+UFAB2lBQAe5QUAJCUFAEqlBQBphQUAh2UFAKfFBQC5pQUA0m UFAPolBQMghQUDPAUFA0rlBQN2RQUDhiUFA7GlBQPYJQUD/EUFAhxlBQI9xQUCVgUFAoHFBQKWhQ UCtmUFAtTlBQ0FhQUNMMUFDVBlBQ1y5QUNi2UFDZdFBQ2vJQUNsAUFDb3FBQ24RQUNxCUFDcGFBQ 3ChQUNzmUFDcvFBQ3XZQUN04UFDdzFBQ3YhQUN5GUFDeHFBQ3tpQUN7qUFDeolBQ33JQUN8wUFDf 3lBQ3+5QUMBSUFDAblBQwNhQUMCWUFDBUFBQwWBQUMEiUFDB7lBQwahQUMJmUFDCPFBQwuRQUMRc UFDEulBQxuRQUMggUFDLVFBQywhQUMxQUFDN/FBQ8GJQUPHuUFDzpFBQ9BxQUPSeUFD3ZlBQ+QZQ UPpMUFD8BlBQ/fBQUP8gUFDgUFBQ4gJQUOQUUFDlDlBQ5mBQUObGUFDoBlBQ6SRQUOoQUFDqvlBQ 62JQUOvaUFDrmlBQ7sBQUJAuUFCQ5FBQkLpQUJGgUFCSvFBQky5QUJRaUFCU7lBQlUJQUJUCUFCW 0lBQl3RQUJf6UFCaelBQmtJQUJteUFCcWlBQn9BQUJ/oUFCfoFBQgHhQUIA+UFCA8FBQgIBQUIFQ UFCBAlBQgdRQUIHuUFCBvlBQgk5QUIIyUFCC4FBQgrxQUIOSUFCETlBQhJBQUIU0UFCFqFBQhghQ UIbCUFCGnFBQh1RQUIcQUFCH/lBQiThQUIqMUFCLTFBQiwhQUIzaUFCNrFBQj0BQUI+IUFCwvFBQ smZQULR+UFC1qFBQuBRQULguUFC6IFBQUI5XUVFRxVZWVopUV1ZWVlZXVldXVlZWVlZWVlZWVkRE VlZWVld1GEpWQwJucGhWb0QEX10Cb0deTkTSYJQTilZXVlZWVhwcSBxIxUwcf0qqZd0cHBwcZUpW HAWjhsmrVqpWVlZWVlVWV1ZWVlZWVlZXV1dXV1dXV1dWVlZWVlZWVlZWr1VWVlatVlZWVkRWrlFX VlZFV1dWXlauVlZWVlFWVldRVlZRVlZWVlZWVkVWVoGvVlagVlVWVVVWVlZWV1dXVlZWdVY1UVZR VlaKpKpWXlZWX1ZWV1dXV1dXVlZQUFBQUFNQU1FRUVFRVVNTUVJRUVBIVbxbkFCoWK9QWFBZr65Q WVBar65QWlBar65QW1Bbr65QXFBcr61QXVBcr61QXlBer61QX1Ber61QQFBfr6xQQVBfr6xQQlBA r6xQQ1BBr6tQRFBCr6tQRVBDr6tQRlBEr6tQR1BEr6tQSFBFr6tQSVBIr6tQSlBIr6pQS1BJr6pQ TFBKr6pQTVBKr6pQTlBMr6lQT1BNr6lQcFBNr6lQcVBOr6lQclBPr6lQc1Bwr6hQdFBxr6hQdVBy r6hQdlBzr6hQd1Bzr6dQeFB0r6dQeVB2r6dQelB3r6dQe1B4r6dQfFB5r6ZQfVB6r6ZQflB7r6ZQ f1B7r6ZQYFB8r6VQYVB9r6VQYlB+r6VQY1B/r6VQZFBgr6RQZVBhr6RQZlBir6RQZ1Bir6RQaFBj r6RQaVBlr6RQalBmr6NQa1Bmr6NQbFBnr6NQbVBor6NQblBor6NQb1Bqr6JQEFBrr6JQEVBrr6JQ ElBsr6JQE1Btr6FQFFBur6FQFVBvr6FQFlAQr6FQF1ARr6BQGFARr6BQGVATr6BQGlAUr6BQG1AV r6BQHFAVr6BQHVAWr79QHlAXr79QH1AZr75QAFAZr79QAVAar75QAlAbr75QA1Abr75QBFAdr75Q BVAer75QBlAfr71QB1Afr71QCFAAr71QCVABr71QClADr71QC1ADr7xQDFAEr7xQDVAFr7xQDlAF r7xQD1AHr7tQMFAIr7tQMVAJr7tQMlAJr7tQM1AKr7tQNFAMr7pQNVANr7pQNlANr7pQN1AOr7pQ OFAPr7pQOVAPr7lQOlAxr7lQO1Ayr7lQPFAzr7lQPVAzr7hQPlA0r7hQP1A2r7hQIFA3r7dQIVA3 r7hQIlA4r7dQI1A5r7dQJFA5r7dQJVA7r7ZQJlA8r7dQJ1A9r7ZQKFA9r7ZQKVA+r7ZQKlAgr7ZQ K1Ahr7VQLFAhr7VQLVAir7VQLlAjr7VQL1Akr7VQ0FAlr7RQ0VAmr7RQ0lAnr7RQ01Anr7RQ1FAo r7RQ1VAqr7NQ1lArr7NQ11Arr7NQ2FAsr7NQ2VAtr7JQ2lAur7JQ21Avr7JQ3FDQr7JQ3VDRr7FQ 3lDRr7FQ31DSr7FQwFDUr7FQwVDVr7BQwlDVr7BQw1DWr49QxFDXr7BQxVDYr7BQxlDZr49Qx1Da r49QyFDbr49QyVDbr49QylDdr45Qy1Der49QzFDfr45QzVDfr45QzlDAr45Qz1DBr45Q8FDCr41Q 8VDDr41Q8lDEr41Q81DFr41Q9FDFr41Q9VDHr4xQ9lDIr4xQ91DJr4xQ+FDJr4xQ+VDKr4xQ+lDL r4tQ+1DNr4tQ/FDNr4tQ/VDOr4pQ/lDPr4pQ/1DPr4pQ4FDxr4lQ4VDyr4pQ4lDzr4lQ41Dzr4lQ 5FD0r4lQ5VD2r4lQ5lD3r4lQ51D3r4hQ6FD4r4hQ6VD5r4hQ6lD5r4hQ61D7r4dQ7FD8r4dQ7VD9 r4dQ7lD9r4dQ71D+r4dQkFDgr4dQkVDhr4ZQklDhr4ZQk1Dir4ZQlFDjr4ZQlVDjr4VQllDlr4VQ l1Dmr4VQmFDnr4VQmVDnr4VQmlDor4RQm1Dqr4RQnFDrr4RQnVDrr4RQnlDsr4NQn1Dtr4NQgFDu r4NQgVDvr4JQglCQr4NQg1CRr4JQhFCRr4JQhVCSr4JQhlCUr4JQh1CVr4JQiFCVr4FQiVCWr4FQ ilCXr4FQi1CYr4FQjFCZr4BQjVCar4BQjlCbr4BQj1Cbr4BQsFCcr4BQsVCer59QslCfr59Qs1Cf r59QtFCAr59QtVCBr59QtlCCr55Qt1CDr55QuFCEr55QuVCFr55QulCFr51Qu1CGr51QvFCIr51Q vVCJr51QvlCJr51Qv1CKr5xQoFCLr5xQoVCMr5xQolCNr5tQo1COr5xQpFCPr5tQpVCPr5tQplCx r5tQp1Cyr5tQqFCzr5pQqVCzr5pQqlC0r5pQq1C1r5pQrFC2r5pQrVC3r5lQrlC4r5lQr1C5r5lQ qFivUFhQWa+uUFlQWq+uUFpQWq+uUFtQW6+uUFxQXK+tUF1QXK+tUF5QXq+tUF9QXq+tUEBQX6+s UEFQX6+sUEJQQK+sUENQQa+rUERQQq+rUEVQQ6+rUEZQRK+rUEdQRK+rUEhQRa+rUElQSK+rUEpQ SK+qUEtQSa+qUExQSq+qUE1QSq+qUE5QTK+pUE9QTa+pUHBQTa+pUHFQTq+pUHJQT6+pUHNQcK+o UHRQca+oUHVQcq+oUHZQc6+oUHdQc6+nUHhQdK+nUHlQdq+nUHpQd6+nUHtQeK+nUHxQea+mUH1Q eq+mUH5Qe6+mUH9Qe6+mUGBQfK+lUGFQfa+lUGJQfq+lUGNQf6+lUGRQYK+kUGVQYa+kUGZQYq+k UGdQYq+kUGhQY6+kUGlQZa+kUGpQZq+jUGtQZq+jUGxQZ6+jUG1QaK+jUG5QaK+jUG9Qaq+iUBBQ a6+iUBFQa6+iUBJQbK+iUBNQba+hUBRQbq+hUBVQb6+hUBZQEK+hUBdQEa+gUBhQEa+gUBlQE6+g UBpQFK+gUBtQFa+gUBxQFa+gUB1QFq+/UB5QF6+/UB9QGa++UABQGa+/UAFQGq++UAJQG6++UANQ G6++UARQHa++UAVQHq++UAZQH6+9UAdQH6+9UAhQAK+9UAlQAa+9UApQA6+9UAtQA6+8UAxQBK+8 UA1QBa+8UA5QBa+8UA9QB6+7UDBQCK+7UDFQCa+7UDJQCa+7UDNQCq+7UDRQDK+6UDVQDa+6UDZQ Da+6UDdQDq+6UDhQD6+6UDlQD6+5UDpQMa+5UDtQMq+5UDxQM6+5UD1QM6+4UD5QNK+4UD9QNq+4 UCBQN6+3UCFQN6+4UCJQOK+3UCNQOa+3UCRQOa+3UCVQO6+2UCZQPK+3UCdQPa+2UChQPa+2UClQ Pq+2UCpQIK+2UCtQIa+1UCxQIa+1UC1QIq+1UC5QI6+1UC9QJK+1UNBQJa+0UNFQJq+0UNJQJ6+0 UNNQJ6+0UNRQKK+0UNVQKq+zUNZQK6+zUNdQK6+zUNhQLK+zUNlQLa+yUNpQLq+yUNtQL6+yUNxQ 0K+yUN1Q0a+xUN5Q0a+xUN9Q0q+xUMBQ1K+xUMFQ1a+wUMJQ1a+wUMNQ1q+PUMRQ16+wUMVQ2K+w UMZQ2a+PUMdQ2q+PUMhQ26+PUMlQ26+PUMpQ3a+OUMtQ3q+PUMxQ36+OUM1Q36+OUM5QwK+OUM9Q wa+OUPBQwq+NUPFQw6+NUPJQxK+NUPNQxa+NUPRQxa+NUPVQx6+MUPZQyK+MUPdQya+MUPhQya+M UPlQyq+MUPpQy6+LUPtQzK+LUPxQza+LUP1Qzq+KUP5Qz6+KUP9Qz6+KUOBQ8a+JUOFQ8q+KUOJQ 86+JUONQ86+JUORQ9K+JUOVQ9q+JUOZQ96+JUOdQ96+IUOhQ+K+IUOlQ+a+IUOpQ+a+IUOtQ+6+H UOxQ/K+HUO1Q/a+HUO5Q/a+HUO9Q/q+HUJBQ4K+HUJFQ4a+GUJJQ4a+GUJNQ4q+GUJRQ46+GUJVQ 46+FUJZQ5a+FUJdQ5q+FUJhQ56+FUJlQ56+FUJpQ6K+EUJtQ6q+EUJxQ66+EUJ1Q66+EUJ5Q7K+D UJ9Q7a+DUIBQ7q+DUIFQ76+CUIJQkK+DUINQka+CUIRQka+CUIVQkq+CUIZQlK+CUIdQla+CUIhQ la+BUIlQlq+BUIpQl6+BUItQmK+BUIxQma+AUI1Qmq+AUI5Qm6+AUI9Qm6+AULBQnK+AULFQnq+f ULJQn6+fULNQn6+fULRQgK+fULVQga+fULZQgq+eULdQg6+eULhQhK+eULlQha+eULpQha+dULtQ hq+dULxQiK+dUL1Qia+dUL5Qia+dUL9Qiq+cUKBQi6+cUKFQjK+cUKJQja+bUKNQjq+cUKRQj6+b UKVQj6+bUKZQsa+bUKdQsq+bUKhQs6+aUKlQs6+aUKpQtK+aUKtQta+aUKxQtq+aUK1Qt6+ZUK5Q uK+ZUK9Qua+ZUKhYr1BYUFmvrlBZUFqvrlBaUFqvrlBbUFuvrlBcUFyvrVBdUFyvrVBeUF6vrVBf UF6vrVBAUF+vrFBBUF+vrFBCUECvrFBDUEGvq1BEUEKvq1BFUEOvq1BGUESvq1BHUESvq1BIUEWv q1BJUEivq1BKUEivqlBLUEmvqlBMUEqvqlBNUEqvqlBOUEyvqVBPUE2vqVBwUE2vqVBxUE6vqVBy UE+vqVBzUHCvqFB0UHGvqFB1UHKvqFB2UHOvqFB3UHOvp1B4UHSvp1B5UHavp1B6UHevp1B7UHiv p1B8UHmvplB9UHqvplB+UHyvplB/UHuvplBgUHyvpVBhUH2vpVBiUH6vpVBjUH+vpVBkUGCvpFBl UGGvpFBmUGKvpFBnUGKvpFBoUGOvpFBpUGWvpFBqUGavo1BrUGavo1BsUGevo1BtUGivo1BuUGiv o1BvUGqvolAQUGuvolARUGuvolASUGyvolATUG2voVAUUG6voVAVUG+voVAWUBCvoVAXUBGvoFAY UBGvoFAZUBOvoFAaUBSvoFAbUBWvoFAcUBWvoFAdUBavv1AeUBevv1AfUBmvvlAAUBmvv1ABUBqv v1ACUBuvvlADUBuvvlAEUB2vvlAFUB6vvlAGUB+vvVAHUB+vvVAIUACvvVAJUAGvvVAKUAOvvVAL UAOvvFAMUASvvFANUAWvvFAOUAWvvFAPUAevu1AwUAivu1AxUAmvu1AyUAmvu1AzUAqvu1A0UAyv ulA1UA2vulA2UA2vulA3UA6vulA4UA+vulA5UA+vuVA6UDGvuVA7UDKvuVA8UDOvuVA9UDOvuFA+ UDSvuFA/UDavuFAgUDevt1AhUDevuFAiUDivt1AjUDmvt1AkUDmvt1AlUDuvtlAmUDyvt1AnUD2v tlAoUD2vtlApUD6vtlAqUCCvtlArUCGvtVAsUCGvtVAtUCKvtVAuUCOvtVAvUCSvtVDQUCWvtFDR UCavtFDSUCevtFDTUCevtFDUUCivtFDVUCqvs1DWUCuvs1DXUCuvs1DYUCyvs1DZUC2vslDaUC6v slDbUC+vslDcUNCvslDdUNGvsVDeUNGvsVDfUNKvsVDAUNSvsVDBUNWvsFDCUNWvsFDDUNavj1DE UNevsFDFUNivsFDGUNmvj1DHUNqvj1DIUNuvj1DJUNuvj1DKUN2vjlDLUN6vj1DMUN+vjlDNUN+v jlDOUMCvjlDPUMGvjlDwUMKvjVDxUMOvjVDyUMSvjVDzUMWvjVD0UMWvjVD1UMevjFD2UMivjFD3 UMmvjFD4UMmvjFD5UMqvjFD6UMuvi1D7UM2vi1D8UM2vi1D9UM6vilD+UM+vilD/UM+vilDgUPGv iVDhUPKvilDiUPOviVDjUPOviVDkUPSviVDlUPaviVDmUPeviVDnUPeviFDoUPiviFDpUPmviFDq UPmviFDrUPuvh1DsUPyvh1DtUP2vh1DuUP2vh1DvUP6vh1CQUOCvh1CRUOGvhlCSUOGvhlCTUOKv hlCUUOOvhlCVUOOvhVCWUOWvhVCXUOavhVCYUOevhVCZUOevhVCaUOivhFCbUOqvhFCcUOuvhFCd UOuvhFCeUOyvg1CfUO2vg1CAUO6vg1CBUO+vglCCUJCvg1CDUJGvglCEUJGvglCFUJKvglCGUJSv glCHUJWvglCIUJWvgVCJUJavgVCKUJevgVCLUJivgVCMUJmvgFCNUJqvgFCOUJuvgFCPUJuvgFCw UJyvgFCxUJ6vn1CyUJ+vn1CzUJ+vn1C0UICvn1C1UIGvn1C2UIKvnlC3UIOvnlC4UISvnlC5UIWv nlC6UIWvnVC7UIevnVC8UIivnVC9UImvnVC+UImvnVC/UIqvnFCgUIuvnFChUIyvnFCiUI2vm1Cj UI6vnFCkUI+vm1ClUI+vm1CmULGvm1CnULKvm1CoULOvmlCpULOvmlCqULSvmlCrULWvmlCsULav mlCtULevmVCuULivmVCvULmvmemvkFN74lheYumvkFN74kZLYumvkFN640RHYk8RQFNqUFFQX1Nj UFFQUFNnUHBTZ1BgU2dQ0FNjUFSvkFNi40BCYgARNFNiUFFQEFNiUDBTYlDwU2JQ4FNiUFRQQFNi UGBTYlAAU2JQsFNiUFRQX1NmUC9TZlCvU2ZQU1AgU2ZQoFNmUFJQX1NhUG9TYVDfU2FQ71NhULBT YVBVUF9TYVAwU2FQUlDfU2BQUVAwU2BQwFNgUFJQAFN/UFFQQFN/UBBTf1AwU39Q0FN/UPBTf1CQ U39QoFN/UFdQn1N9UK9TfVBSUGBTfVDQU31Q4FN9UI9TfVBUUD9TfFAvU3xQUlBCU3BQrVhQUE9Q L1LJEGpRL1AvUS9SL1MvVC9VL0AvQVgQZXV8YhA6dXxiEH51fGIQeHV8YmcwWSBZ0FlTYFkQWQBZ U0BZcFlS6K+Q4ldqY+ivkBBCVmpjih26HaodU0JnwFbAV1KfEVxRQVCPUUFQv1FBUFNQn1FAUI9R QFC/UUAQ11Ofbo9uv25Tnx2PHb8dU5+Oj46/jlOffY99v31TEB1LamJnD1E/US9R31FUT1F/UW9R H1FUD1M/Uy9T31NUT1N/U29TH1NUMFsgW9BbU2BbEFsAW1NAW3BbUsBb8FvgW5BbgFtV4FaQVoBW sFagVlUAVjBWIFbQVsBW8FZWT1d/V29XEFZUoBETUotQUVDwUotQ4FKLUFJQ0FKLUMBSi1BSUEBS i1BRUJBSi1CAUotQUlDAUotQUVAwUotQIFKLUFJQEFKLUABSi1BSUHNSi1BgUotQUlKLUHNQ8FKK UFFQ0FKKUMBSilBSUBBSilBRUHNSilBgUopQUlKKUHNQUFKJUFFQIFKJUMBSiVBSUokQTHJgdBB0 UkB0cHRSUHRRoHRRgHSwdFLgdJB0UpARalKIUFFQ8FKIUOBSiFBSUNBSiFDAUohQUlBzUohQYFKI UFJSiFBzUJBSh1BRUPBSh1DgUodQUlDQUodQwFKHUFJQ8FKHUOBSh1BSUNBSh1DAUodQUlAwUodQ IFKHUFJQEFKHUABSh1BSUHNSh1BgUodQUlKH4nNnXxFJUstQUVAPUstQz1LLUI9Sy1BTUH9Sy1Bv UstQP1LLUFNQX1LLUE9Sy1BSUstSy1AQUsrjd3xi0OhSyuJ2YxDoUsricmMQ6FLK4k5jEOhSyuJM YxDoUsrjSUpiDxFfUspQz1LKUI9SylBTUF9SylBPUspQb1LKUFOvkFLJ4hRjEOhSyeJtYxDoUsni amOPEWlSyVBRUA9SyVD/UslQUlAfUslQz1LJUFJQf1LJUG9SyVBSUP9SyVBRUF9SyVBvUslQUlDg UslQsFLJUFJQIFLJUPBSyVBSUB9SyVAPUslQUlBfUslQT1LJUH9SyVBvUslQVFLKUspSyVLJUF9S KlB/UioQW1JQRkZQUFBCQVhC6FLq4jlCT+hS5OJ4QE/oUuPieEBP6FLi4nhATxFDUlNQc1BdUb5Q c1BdUf5Qc1BdUc9Qc1BdUcRQc1BdUQdQc1BdUV8QW3NdqXNdlXNd93NdEVpSGlB0UF1RoFB0UF1R uVB0UF1ROhBedF24dF2WdF3zdF3ydF3rUbNQclBdUXEQSnJdtXJdjXJd53Jd+nJdw3JdDHJdAXJd HHJdEVpSeFBwUF1STVBwUF1RDlBwUF1RTBBHcF2scF2xcF2bcF2YcF3xcF0JcF1qcF0RWlGiUGRQ XVHMUGRQXVHHUGRQXVFl52RdT2RdTWRd6lJSUF9RC+JfUFnrUlJRC1BdU1riem5P6FNZ4npuT+hS ceIddU/oUkziHRFP6FJL4h0CT+hSSuIdIk/oUkPiHcNPEVlSX1HhVFFQT1JeUeFYUVBPUlzietFP 6FJb4nrRT+hSWOJ6Dk/oUlXiemlP6FGu4npzT+hRq+I2TU/oUariNk5P6FGm4jZkT+hRpeI2ZE/s UaNQNlJRUE9RoeI2zk8RWVG6UHhYUVBPUbdQdlL7UE9R6OIdb0/oUefiHcNPEVlR5FBuUXVQT1Hi UBBUUVBPUfzieiJP6FH44np4T+hR9+J6dE/oUfbienRP6FHz4npPT+hR8eI2fk/oUc7iNsNP6FHN 4ja0T+hRyuJ4PE8RWVHJUHhUUVBPUchQdlRRUE9RI+IdS0/oUSHiHXRP6FEg4h1/T+hRP+IdZU/o UTvibp1P6FE54m60TxFZUTdR4VHKUE9RNlB6UvtQT1Ex4jZ6T+hRD+I2zk8RWVENUHhRylBPUQxQ ZVRRUE9RF+IdaU/oURbibp1PEV1RFVBuUXVQT1EUURNRUVBPURJR4VL7UE9REOJ6YE/oUW7ienZP 6FFt4jZNT+hRbOI2e0/oUWjieNFP6FFn4njOT+xRZlB4UcpQT1F54h0iT+xRdFB6UlFQT1Fz4nr7 T+hRT+I2eU/oUU7iNhVP6FFL4njRTxFZUUNQblF1UE9RQlBuVFFQT1FB4np5T+hRQOJ6cE/uUVtQ NlHKUE9RWlB2UcrmT60dIk+rbuhRBuJPqhDoWFHiT6d46FhR5k+8HTJPux3oVFHiT7oQ6FL75k+P HSJPjm7oUvsQW0+MerRPizZyT5p66FRREEtPmXp+T5N2KU/oeOtP4x1OT+E2eU/gNjJP/zboVFHi T/526FL74k/4eOhSURBbT/A2HE/IentPx3boUcrmT8I2eU/XEOhS+xBLT9V6KU/SdtFPJR3DTyQd 2U8jek1PIHgOTzp46FRREEdPOXoCTzh6cE83NnlPNTY3TzF6w08wZehYUeZPDnqdTwNl6FhR4k8b NuhRBuJPGW7oWFHmTxg2Ak8WduhSUeJPbzboUQYQW09rNmRPYnrDT35l61RRUE9QfVET451PBWfs Un9QV1HQUFdRIhB+V+1XLlcyVwRXEld/V3dXdVdxV05XRFhCWEBYXlhcWFpYWFhWWFRYUlhQWFBS ROivsBB7UFBRUERWQFBQUVBWVFBQUVBUQFBQUVBAUlBQUVBSUFBQUVBQUlFYUlAaUOBDUxtSGwMS 4Gd7G+hXrwLgaHsb4FcACwjhUVHeCVEb4JAzUBsycOCmA3PoUVoBCuBVcxJR4EIbUBsEEkjgaHvg UtjoUVAECOhRr+FRUd7VS+BCEwjpUFFRfNXdS+lQUVEW1d0JCVBGJm9Ib0JuQWkWFG5BaRYUbkFp FhRuQWkWFG5BaRYwFG5BaRYwFBUUe3t7e3t7e3t7e3tIe3t7e3t7e3t7e3t7e0h7TeDGGwMI4PpN CeBiGwMI4K9NCRvgeQNwDAjpUjxSOhUU6VI7UjoVFAkI6VE4UjwVAgjpUjxROBQJCRvgawNwDAjp UG5SOxUU6VAdUjsVFAkI6VIMUG4VAgjpUG5SDBQJCRvgawNwDAjpUeFQbhUU4W5uFRQJCOlSH1Hh FQII6VHhUh8UCQkb4AoDcAwI6VETUG4VFOFubhUUCQjpU9tRExUCCOlRE1PbFAkJG+DOA3AMCOlQ elI8FRTpUBBSPBUUCQjpVTxQehUCCOlQelU8FAkJG+BIA3AMCOF2dhUU4TZ2FRQJCOFidhUCCOF2 YhQJCRvgAQNwDAjhdnYVFOF4dhUUCQjh/XYVAgjhdv0UCQkb6FFRA3AMCOF2dhUU4WV2FRQJCOlS eFB2FQII6VB2UngUCQl7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7NRJ7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7e3t7e3t7e3t7e3t7e3tR420mPggVNXMVMHMVNTBzFTDg2yY4SODQMnBw4T4mFTVzFXDg U3YwMjM4cOBTdjE14CZzNRTgPnMUcOFtCBU1cxVw4FN2MDIzOHDgU3YxNeAIczUU4G1zFOFQCBUE COEIEDUU4m0QbRVzMRQJ4x7RaCEVNXMVMHMVNTBzFTDg2SY4SODQMnBw4WjRFTVzFXDgU3YwMjM4 cOBTdjE14NFzNRTgaHMUcOEeIRU1cxVw4FN2MDIzOHDgU3YxNeAhczUU4B5zFOFQIRUECOEhEDUU 4h4QHhVzMRQJGwISURsACOFYUBIJEwwI4VhQEgnjUltaQhMIMEtxCRJGQCBu4EITCOlrcUguS+pU UFH4UFt7CeBccxLgXXMS4EITCOl9EX0RS+pUUFRQUFt7CeBecxLgX3MS4EITCOlILmtxS+pR+FRQ UFt7CeBAcxLgQXMSUCRIFTkUFTkUIyMjIyQkJSUlJXt7eyMje3t7e3t7SBU5FCMjIyR7FRQjIyMj IyQkJBUUIyQkJCQkJCUlJRUUIyUVFCMjJCQVFCMjIyMjJCQkJFAlJSUlJSUlJSUlJXt7JCQkJCQk UCN7EwjhHR0VSDkUS+ivkOMdS2piewkjUHt7JSUle3t7e3tQIyN7EwwI6K+Q4ldGY+ivkBBbVkZj hR21HaUdU5ARXFFBUIBRQVCwUUFQU1CQUUBQgFFAULBRQBBOU5BugG6wblOQHYAdsB1TkI6AjrCO U5B9gH2wfVNneyQkJCQkJCNQe3sJUSMjJCMkIyQjJCMkIyQleyMlI1B7e3tQUBAQEG9ubWxramlo Z2VkY2JhYH9+fXx7enl4d3Z1dHNycXBPTk1MS0pJSEdGRURDQkFAX15dXFtaWVhXVlVUU1JRUHwV cxYwcOB2MOBUdnMYGH18FXMWczFw4HYx4FR2cxgYfXwVcxYw4HAxcOAWMOBUdnMYGH18FXMWczHg cDBw4HYx4HAx4FR2cxgYfXwVcxYw4BAxcOA2MOBUdnMYGH18FXMWczHgEDBw4HYx4BAx4FR2cxgY fXxRQHBsUGx9fHAVc3DgnRRzcOhRCgEIc3Dg3RRzCXDgvQEIc3DgHRRzCXDgwAEIc3DgXRRzCXFx fXxwcBVIOBRw4FEwcBXgFiY42hUwFH18UeFbWhNzEzVafXxQ4VpbE3MTW318UOBHcyDhUUduUeBH cyDhUkcVauFSUFhdfXwV4EpzFBXgSXMUfXxwFeBTdRUxNOAAAQgVFEtxcQl9fOBREzNzMuBQcxLg X3t9fHAV4FATMBR9fFHgVhPgVxM1Wn18cDngEDHgUNtw4XyQ2tzoQFAyMHtcNHM0MQwI4FMxCX18 FeBBe+BHcxTgRyq0SH18FeBBe+BHcxR9fOBCEwjXFeBBe+BHcxTgRyq0S1PaFUg5cOBHcxTa2tdw 4PABCOBBe+BHcxTgRyq0S3HgRyq0CQlIfXx9fOBSdRYw2hbgEDHcGH18GwNwDAjgUtUJCOBR1Ql9 fHDgU3UV4ElzFBXgSnMUFTVzFXDgU3UwOnDgWXMSczjaOjAxcOBK2uBQAilx4kpKEOmvsFBKFXDa BAhzceBvS3MJMRRM4URQ2gIp40kQcEkVcNoECHNx4G9LcwkxFH184UBBE3MTW3184V5fE3MTW318 4VxdE3MTW3184VxdE3MTNVt9fOFeXxNzEzVbfXzhQEETcxM1W318GwIIFRRLcXEJfXxRcOBTdXMZ 4BAw4HAzcOBQAghz4FJ1aHPgUnU1aFDaM2hLcXFxcXEJUX18G+A0AQgVOeBZEzDaQGpLcXFxCX18 UeBVdUBzcNqlUOBRMHO9vH18UeBVdUBzcNqlUOBRMXO9vH18UeBWdUClUL28fXxw4FEwUUBwbFBs fXxw4FExUUBwbFBsfXzge3vgenp9fFDgVxPgVhNbfXxu4Hp6fXxlfXwm6FLPcyBAcOhSzxVw4FAA COBRMQlqf0h9fHFxXDRzNNvoEFAyfXxx4NABCFw0czTb6HBQMkviUBB/ewngUjB9fHHgkAEIXDRz NNvoRQUyS+JQ0H97CeBSMH18XDRzNNvoEFAyMHNxfXzkUFFQUFBF4Fh24Fh24Fh24Fh2X0BGQxU4 auBRRn185FBRUFBQReBYduBYduBYduBYdl9ARkMVODVq4FFGfXwbA3MbAQoIcBXaMBRLcXEJfXwb BAhwFdowFEtxcQl9fBsDcxsBCghoS3FxCX18GwQIaEtxcQl9fOBDEwhTS1IJfXzgQxMIUktTCX18 GwTgQhMMCghoS3FxCX184EITDAhc4FR14FR1Vlw0czQxNOhXWAEI4FR14FR1UXAW4EAwGHAW4EAw GAlacXFLcXEJfXzgQhMMCFzgVHXgVHVWXDRzNDE06FdYAQjgVHXgVHVRcBbor6AwGHAW6K+gMBgJ WnFxS3FxCX18GwNzGwEKCOBqe0txcQl9fBsDcxsBCgjga3tLcXEJfXwbA3MbAQrgQhMMCghoS3Fx CX18XNpTGwTgVHZSGwQK2tpa4EITDAoIaEtxcQl9fBZzFjDa2hZzcBbaMNox6K/QMnNwQHPa6VN3 U3faIBUwcOBQAAjgUTHor+rbS+AW3AngQDA4UWp9Vd5QT1UcUE9VHFBMU8RQS1BQr7FQUK+0UFCv uK4ar6xVO1BzrjqvsFNDUFBRdFBQUXRQUFBQUFBQUFB1UNRQdFC4UMZQ71ANUJtSU1AVUX5QCFBU UUhQSVBSUWlQG1FAUEdQVVFaUHhQc1AbUABQRVAaULVRXVD/UGFQulEWUNFRdVAfUMxQclAeUEZQ EVDBUPBRF6+5UNFQg1E5UPtQR1D4URBQd1AcURivj1ABUACv51F+UFBQa1DHUMpRXlBPUBxRWlFz r45QclAjUNdQ6lCGUK9QClDIVfCvuVAAUAJQPq/nUAxQgVEKUQuvTFAZUD5QLlDIUPFQ7VC0UdhR kFRVrzBQZVAyUCJRV1FDUXhT0q/4UGhViFnlr5SvgFBAUD5Q8VDqULxSe1QWr75QEFC4VFGvOFBT UENQY1BjUD5Q8lDmUIxRSFFlUxNQXlBkUAxQDVAsUP9TeFBrUBhQ2VDMUOpRK1H/U16v9FBHUGdQ M1AvULBRKFGQUnFViFWgrypQQlB3UGRQAlDaUPRQkVCTULtRSFEWUQRTPa5vrx5QUVBYUHtQFVA+ UNRQ1lD+UP9QklCSUJRRX1FxURlRK1GRUY5RsVM+U7ZQM1D3UL1QplCoUXhROVEuUm9S0lVirdGv 5VB2UGVQEFAVUBlQB1A8UPxRdlEQUQtRK1HMUidSLlIvU+ZTjFR4VL+vaK+TUFZQf1AQUNJQ+lDm UJ5Qg1CHULVRFlEdUYZSLlPjVdavK1BCUH9QOFAvUNRQ9VDpUKVRVVFZUVxRRFFwUWNRZ1EoUStR kFGxUk1Sc1IIUzJT/1Xcrymv3VBxUHRQDVA1UDhQOlDTUNVQ51CfULJQu1C9UUpRcFF/UWdRb1EA Ud1R31GUUp9TB1MMU8ZUEFTGVPtUklSsVUFVkq6BrrBQQ1BxUHRQYFAdUB1QDVA2UCpQLFDoUOhQ k1CKUVNRS1FOUX9RbVEaUQBRD1E2USxRwFHFUfNR9lHmUZdRgFG5Ub9RqVJIUtxSxFLrUpVSn1KA U01TelMUU89TnFRxVIpUq1cxrU2u766/r1uve69jr8CvzK+Lr71QUVBYUExQdVBvUBNQClA7UNBQ 1FDAUMVQzVD3UORQnVCFUIZQj1CPUI9QtFCgUKZQq1FWUUNRSVFLUXJRc1F3UXxRb1EHUQhRJ1Ha UcNR9FGWUbFRtFGsUlBSXFJyUnJSelJmUhpSDFLSUrxSrFNaU3NTEVMoU8dTglOqVClVYlViVftV 5VWgVrRXdVicrMutjq5Qrjmuxq7Lr2VQU1BWUF5QQ1BJUGRQElAYUBpQB1A0UCFQIVAiUCZQJ1Aq UCpQ01DMUP9Q/1DiUOtQmFCcUJ9Qn1CLUIxQj1C0ULRQtFC5ULtQpFCtUK5RUlFVUVVRWFFYUUtR clFzUWBRZ1ETUQtRMFE1UShRKFEoUShRK1HSUdlRyFHIUctRzlHxUfZRgVGCUYNRj1GzUaVSUFJQ Un1SEVIXUhpSAFILUg1SDVIPUjNS0VLbUuRS5FKeUoZSi1KyUqpTQFNBU09Td1MVUzdT2FPaU+BT 5FOEU4VUdlQRVBhUO1SXVIFVYlUYVRlVD1UzVdtV8VXzVZJVmlW0Va9Ww1byVuhWuFdaV2ZXAFcE V9lX+VfrV4xXr1h3UXBRHVFLUXlQUFBQUFBQUFBQUMNRC1R/UsBRr1LoUItQ7lIkU5tSxFH7UFBQ UFBQUFBQUFBQVdpT2lM0UA9S6FPtUs0swFOyU/xS0lBQVBRQUFBQUG1RWlCcUOxQnFWDVEVVuFCX UkpQvlBQUcRTMVLuUslSSFFmU2tU1VScUABQKVXzVfNSj1JXUv9QUFG7UDRQD1AFUUlQolQGUL9Q mFCfVdpRE1EWUo5R+1KWUhpQDVCIUPRS61DJUPBQNVFnUiRTNFDlUKpQwVHpU3BR5lB1UC9QgFC8 ULBQUFBQUFBQUFBQVH+tElJvVkhSJlZqUWdR6VEBr5dSea+7Um9SsVHVUItTqlHAUQZRHlF/UPZQ s1DrUIVRZFFPVK5US1CBULRRTlDLUJ1Qt1DjULJQmlR0UOhQpVDpU2RQClSwUXNRf62ZrhRVJFPT UaZSEVBSUEdQAFBFUB9QR1D4UAFQyFACUBlQPlBeUP9RK1ErUcxQOlDTULtQnVFyUFBVg1aKUMpQ 31DqU0VQdVP1UtBSr1OYVHBQwlCwUxxQy1AtUKhRTFFkUPhQPVA5UFBWaVFMUFBQUFJQUFBSUFBQ UvpQ/1QhUOBUUFB4VFBQH1hQUN5W+lACUmlQ3FL6UAJS+lBJVFBQIlTfUHhSUFASUvpQYlJQUApS aVBSVFBQGlRQUNdUUFBiVFBQcVRQUGNUUFAVVFBQHFRQUBVUUFAYVFBQb1L6UP9S+lDIVN9QeVTf UHhU31B5VFBQLVchUAxVl1BAVQZQe1WXUAFVl1BLVQZQeVSzUH5WaVADVmlQe1NNUHlUUFBGVmlQ flUGUHZX3VB5VZdQTVZpUABUs1BkVmlQAFWXUHZUI1A6VQZQGlWXUGBVl1BAWFBQQlWXUF5Vl1BC VQZQcVL6UIZSaVBSUvpQE1T2UMNUUK+9UvpQdlRQUAxUI1B7U91QHlQjUB9T3VAfUvpQElRQUB1U I1AWUmlQelL6r5dUI1AUUmlQe1b6UBxUI1AWVFBQGlQjUHdUI1AeU91QG1NNUAFS+lB2VCNQb1RQ UENVl1BBVFBQf1RQUEFT3VBFU3dQ9VGTUM9Td1ALVHlQXFWXUEBVl1BBVZdQAVUGUHlVl1BNVmlQ AFWXUBdUUFAMVFBQDFRQUAxUUFAMVFBQDFRQUAxT3VAeU91QH1PdUB9T3VAfU91QH1JpUHtSaa+h UmmvjVJpr7NUI1AWVFBQGVRQUBlUUFAZVFBQGVRQUBlUI1BvVCNQb1QjUG9UI1BvVFBQM1NjUGtU UFDQVFBQc1RQUAxSnVAdVAJQUVQjUGpVqlBrVapQa1hQr61S+lC0UvpQRlhQr7lWaVABVDRQX1RQ UFBUzFAfUjZQflL0UGhVl1AKVFBQFFRQUCNS+lD/VN9QeVRQr69UUFB0VFBQdlhQUP9Vl1BAVZdQ QFZpUABYUFAaVZdQFlRQr79YUK+8VFBQAVRQUANS+lDIUvpQyFQ0UEBUUFBCVZdQQVRQUEVS+lAN UvpQD1RQUD5SUFAJUvpQyFRQUANYUFBrVZdQQFUGUHlVl1BAVQZQeVUGUHlTTVB5U01QeVNNUHlT TVB4VmlQAFZpUABWaVAAVZdQF1WXUBdVl1AXUmlQelL6UEVS+lBEUvpQ1FL6UMFS+lBFVCNQO1NN UBVVBlByU91QRVGTUM9Vl1BzVFBQGlWXUEFUUFBBVLNQeVQjUHdU31DKUjZQGlI2UEhSNlBfVlBQ GFZQUBhWUFBdVFCvvVRQr7lQUFBIUFBQsFtcWVBTU1RWVlZaWVNUVFZWU1RTU1ZWVlZWVlZWVlZU VFZWVlZaWFhZWFZWWVlUVlhXWlhaV1pYV1ZYWFxXWFdUU1RWVlRWVlVWVlRWV1RUV1RaV1ZWVlVV VFdVWFZWVlRTVFZYWFlWWFpYVlZWVlZWVVZWVlZUVFRUV1ZWVlZWV1dXV1VUVlZWVVZWWFhbVFVb WVZWVlNUWFZWVFZWVlZbWFhaW1hWW1ZWVFRWVlhWVFRVU1RWW1hWWFZWVFRUVFpaWlhYWFRUU1RU VFdVV1ZTWFZYVldWVlNTU1hYWFZWXF1ZUFNTVFdWVltaU1RUVldTVFNTVlZWVlZWVlZWVlRUV1dX VltYWFlZV1dZWVRWWVdbWVpXWlhYWFhYW1hYV1RTVFdWVFZWVVZWVFZXVFRXVFpXVlZWVVVUV1VY VlZWVVNVVlhYWVdZWlhWVlZWVlZVVlZWVlRUVFRXVlZWVlZXV1dXVVVWVlZVVldZWV1UVVxZV1ZX VFRZVlZUV1ZWVlxYWFpcWVZcVlZUVFdWWFZUVFVTVFZbWFdYV1dUVFRUWlpaWFhYVFRUVFRUWFVX VlNZVlhWV1dXVFRUWVlZVlZdX1pQU1NUV1dXX1tUVFRXV1NUU1RXV1dXV1dXV1dXVFRXV1dXXFlZ WVlXV1lZVFdZWFtZWlhaWVhYWFldWVhYVFRUWFdUVlZWVlZUV1dUVFhUWldWVlZWVlRXVVhWVlZV U1VXWVlZV1laWFZWVlZWVlZWVlZWVFRUVFdWVlZWVldXV1dVVVdXV1ZXV1paXlRVXVpXV1dUVFlW V1RXV1dXXVlZWl1ZV11XV1RUV1ZYV1RUV1NUV11ZV1lXV1RUVFRaWlpYWFhUVFRUVFRYVlhWU1lW WFZYV1dUVFRaWlpXV19AXFBUVFVYWFhfXVRVVVhZVFVUVFhYWFhYWFhYWFhVVVlZWVheW1tbW1pZ W1xWWFxaX1tcWVxbWFpbWl5aWllVVFVZWFVXWFdYWFRYWFRUWVRcWFhYWFZXVVhYWlhXVlZTVlhb W1taW1xbV1dXV1dXV1hYWFhUVFRUWFhYWFhYWFhYWFlWWFhYVlhYW1tfVVVfXFhYWVVVW1hYVFlY WFhfW1tcX1tYX1hYVVVYV1pYVVVZU1VYQFtaW1paVlZWVlxcXFtbW1RVVVVVVVhXWVZTW1haV1lY WVVVVVtbW1hYQEBcUFRUVVlYWEBdVFVVWFlUVVRUWFhYWFhYWFhYWFVVWVlZWF9bW1tcWllcXFZY XFpAXFxZXFxZWltbX1taWVVUVVlYVVhYV1hYVVhYVFRZVFxYWFhYVldVWFhaWFhWVlNWWFtbW1pc XFtYWFhYWFhXWFhYWFRUVFRYWFhYWFhYWFhYWVZYWFhWWVlcXEBVVUBcWVhZVVVcWFhUWVhYWEBb W1xAXFhAWFhVVVlYWlhVVVlTVVhAW1pbWlpWVlZWXFxcW1tbVFVVVVVVWVdZVlNcWFpYWllZVVVV XFxcWFhBQV1QVFRVWVlZQF5VVlZZWlRWVFVZWVlZWVlZWVlZVlZaWlpZQFtcXFxbW15dVllcW0Bc XVtdXFlaXFtAXFtaVlVWWllWWFlYWVhVWVlWVVlWXllZWVlYV1ZZWF1YWFZXU1dZW1tcW1xdXFhY WFhYWFhYWFhYVlZWVllZWVlZWVlZWVlZV1lZWVdZWV1dQVZVQV1ZWVpVVlxZWVRaWVlZQVtbXUFc WUFZWVZWWVhbWVZWWVNWWUFbW1tbW1ZWVlZdXV1cXFxWVlVWVlZZV1pWU1xZW1haWVpVVVVdXV1Z WUNEX1BVVVVbWlpCQFVWVlpbVVZVVVpaWlpaWlpaWlpVVVtbW1pCXV1eXl1cX15XWl5cQl5fXF9e W11dXUNdXVxWVVZbWlZaWllaWVZaWlVWW1VfWlpaWlhYVlpZXllZWFdTV1pdXV5dXl9dWlpaWlpa WVlZWVlVVVVVWlpaWlpaWlpaWltYWlpaV1pbXl5EVlhDX1paW1ZWXlpaVVtaWlpDXV1fQ15aQ1pa VlZaWV1aVlZbVVZaQV1dXV1dV1dXV19fX11dXVVWV1ZWVltYXFhTXlpdWVxbW1ZWVl5eXlpaRUVA UFVVV1xbW0RCVldXW1xVV1VWW1tbW1tbW1tbW1dXXFxcW0RfX19fXl5AQFdbQV5DX0BeQF9cXV9f RF9fXVdWV1xbV1tbWltaV1tbVVZbVUFbW1tbWFhXW1tfWlpZWFVYW19fX15fQF9bW1tbW1taWlpa WlVVVVVbW1tbW1tbW1tbW1hbW1tYW1xAQEVXWEVAXFtcVldfW1tXXFtbW0VfX0BFX1tFW1tXV1xa X1tXV1tVV1tBX15fXl5XV1dXQEBAX19fVVdYV1dXXFhdWVVfW19aXVxcVlZWQEBAW1tISUNQVlZX XVxcSURXWFhcXlZYVldcXFxcXFxcXFxcWFheXl5cRkFAQUFAX0JDWVxDQEdBQ19DQV1fQUFHQEFf WFdYXlxYXF1bXVtXXF1XWF1XQ11cXV1bWVhdW0FcXFlZVllcQUFBQEFDQVxcXFxcXFtbW1tbV1dX V11cXFxcXF1dXV1bWlxcXFldXUJCSFhYSENdXF5XWEFcXFdeXFxcSEFBQ0hBXEhcXFhYXVxBXFhY XVVYXElBQEFAQFlZWVlDQ0NBQUFXWFlYWFhdWV9ZVkFcQVxfXV5XV1dCQkJcXEtMRVBXV1lfXl5K RlhZWV5fV1lXWF5eXl5eXl5eXl5ZWV9fX15JQ0JEREJBRUVaXkVCSURFQUVEX0JEQ0xDREBZWFlA XlleX1xfXFldX1hZX1hGX15fX1xbWV9eQ11dW1tWW15DQ0RCREVEXl5eXl5eXFxcXFxYWFhYX15e Xl5eX19fX11bXl5eWV9fRERLWVpLRV9eQFhZRF5eWF9eXl5LQ0NFS0ReS15eWVlfXUReWVldVlle S0NCQ0JCWlpaWkVFRURERFhZWVlZWV9bQFtWRF5EXUFfX1hYWERERF5eTU9HUFdXWUBfX09IWFpa X0FXWldYX19fX19fX19fX1paQUFBX0tEREVFQ0JGR1pfSENMRUdCRkVAQkVES0VFQVpYWkFfWl5A XUBdWl9AWFpfWEhAXkBAXFtaQF5EXl5cW1ZbX0RERUNFR0VeXl5eXl5dXV1dXVhYWFhAXl5eXl5A QEBAXVxfX19aQEBGRk1aW01HQF9BWVpFX19YQV9fX01EREdNRV9NX19aWkBeRV9aWl9WWl9MRENE Q0NaWlpaR0dHRUVFWFpaWlpaQFtBXFZFX0VeQkBBWVlZRkZGX19wcklQWFhbQkBAcUtZW1tAQlhb WFlAQEBAQEBAQEBAW1tCQkJATkdGR0dFREhJW0BKRU9HSURJR0JFR0dwR0dFW1lbQ0BbQEJeQl5c QEJZW0FZS0JAQkJeXFtCQEdAX11dVl1BR0dHRUdJR0BAQEBAQF5eXl5eWVlZWUJAQEBAQEJCQkJf XUBAQFtBQkhIcFtdcElCQEJaW0dAQFtCQEBAcEdHSXBHQHBAQFtbQl9HQFtbX1hbQHJHRUdFRVtb W1tJSUlHR0dZW1tbW1tCXEVdVkdAR19EQkJaWlpISEhAQHFySlBYWFtCQUFyS1lbW0FDWFtYWUFB QUFBQUFBQUFbW0NDQ0FPR0ZISEZESUpdQUpGcEhKRElIQkZIR3BISEZbWVtDQVtAQl9CX1tBQllb QVlLQkFCQl9dW0JBRkBAXl1WXUFHR0hGSEpIQEBAQEBAX19fX19ZWVlZQkFBQUFBQkJCQkFdQUFB W0JCSUlxW11xSkJBQ1pbSEFBW0NBQUFxR0dKcUhBcUFBW1tCQEhBW1tCWFtBckdGR0ZGXV1dXUpK SkhISFlbW1tbW0JdRl5WSEFIQERCQ1paWklJSUFBdXdNUFlZW0VDQ3dPWlxcQ0VZXFlaQ0NDQ0ND Q0NDQ1xcRUVFQ3JLSUtLSUdNTV1DTUl0S01HTUtFSUtLdUtLSFxaXEZDXENFQEVAXUNFWlxDWk1F QkVFQF5cRUJKQkJeX1hfQ0tLS0lLTUtDQ0NDQ0NAQEBAQFpaWlpFQkJCQkJFRUVFQ19DQ0NdREVM THVcXXVNRENFW1xLQ0NbRUNDQ3VLS011S0N1Q0NcXERCS0NcXENYXENyS0lLSUldXV1dTU1NS0tL WlxdXFxcRV5IXlhLQ0tCR0VFW1tbTExMQ0N6fHFQW1teR0VFe3NcXl5FSFteW1xFRUVFRUVFRUVF Xl5ISEhFd05NTk5MSXFxQEVxTHhOcUlyTkdMTk56Tk9MXlxeSEVeRUdDR0NeRUdcXkhcckdER0dD QF5GRE5ERUNBWUFGTk5OTE5xTkVFRUVFRUNDQ0NDXFxcXEdEREREREZGRkZFQUVFRV5HR09Pel5f enFHRUhdXk5FRV9IRUVFek5OcXpORXpFRV5eR0VPRV5eRVpeRXxOTE5MTEBAQEBxcXFOTk5cXl5e Xl5HQExDWU5FT0VKR0hdXV1wcHBFRX5gdFBcXF9KR0dgdl1fX0dKXF9cXUdHR0dHR0dHR0dfX0pK Skd7cU9xcU9LdHRCR3RPe3F0S3RxSk9xcX5ycU5fXV9LR19GSURJRF5HSFxfSFx0SEdJSURCX0hH cUZHQ0JZQkhxcXFPcXRxRkZGRkZGRERERERdXV1dSEdHR0dHSEhISEdCR0dHX0lKcnJ+X19+dElH S15fcUdHX0pHR0d+cXF0fnFHfkdHX19JR3FHX19HW19HfXFPcU9PQkJCQnR0dHFxcV1fX19fX0pC TkNZcUdxR0xKSl5eXnNzc0dHYmN3UF1dQUxJSWF6XkFBSUxdQV1eSUlJSUlJSUlJSUFBTExMSX90 cnR0cU53d0NJeHFgdHdOd3RMcXR0YnR0cEFeQU1JQUlMRkxGQElMXkFLXXlMSUxMRUNBTEl0SElF RFtESnR0dHF0d3RJSUlJSUlGRkZGRl5eXl5MSUlJSUlMTExMR0RJSUlBS0x1dWJBQmJ3S0lNX0F0 SUlATElJSWJ0dHdidEliSUlBQUtJdElBQUlcQUljdHF0cXFDQ0NDd3d3dHR0XkFBQUFBTENwRVt0 SXRJT0xMX19fdnZ2SUlmZnpQXl5CTktLZX1fQkJLT15CXl9LS0tLS0tLS0tLQkJPT09LYnd0d3d0 cXl6RUt6dGN3enF6d050d3dld3dzQl9CT0tCS01ITUhBS01fQk1fe01KTU1IRUJNS3ZKS0dFXEVM d3d3dHd6d0tLS0tLS0hISEhIX19fX01KSkpKSk1NTU1LRktLS0NNTnh4ZkJDZnpOS09AQndLS0NP S0tLZnd3emZ3S2ZLS0JCTkt3S0JCTV1CS2V3dHd0dEVFRUV6enp3d3dfQkNCQkJORXNHXHdLd0tx Tk9AQEB5eXlLS2psfVBfX0NwTU1qYEBDQ01xX0NfQE1NTU1NTU1NTU1DQ3FxcU1mend6end0fX1H TX13aHp9dH16cHd6emp6enZDQENyTUNNcEpwSkRNT0BDT0BgT0xwcEpHQ09NeUxNSEdcR056enp3 en16TU1NTU1NSkpKSkpAQEBAT0xMTExMT09PT01HTU1NRE9we3tqQ0VqfXBNcUFDek1NQ3FNTU1q enp9anpNak1NQ0NwTXpNQ0NOXkNNbHp3end3R0dHR319fXp6ekBDRENDQ3BHdkhcek16TXNwcUFB QXx8fE1NExRkUEFBR3VychJoQ0ZGcnZBRkFDcnJycnJycnJyckZGdnZ2cm5gfWBgfXlkZEpyZH1v YGR5ZGB1fWBgEn9gfEZDRndyRnJ1TnVOR3J1Q0ZzQ2Z1cnV1TkpGdXFhcXJOSl5Kc2BgYH1gZGBy cnJycnJOTk5OTkNDQ0N1cnJycnJ1dXV1T0tycnJHdHViYhNGSBNkdXJ3REZgcnJHdnJychNgYGQT YHITcnJGRnVyYHJGRnFBRnIUYH1gfX1KSkpKZGRkYGBgQ0ZHRkZGdUp8Tl5gcmByeXV2REREYmJi cnIbHWpQQ0NJenZ2GW5FSUl2e0NJQ0V2dnZ2dnZ2dnZ2SUl7e3t2FmZjZmZifmpqTXZrYhhman5r ZnpiZmUaZWZhSUVJfHZJdXlxeXFJdnlFSXhFbHl1eXlxTUl5dWh3dnFOQU53ZmZmYmZqZnV1dXV1 dXFxcXFxRUVFRXl1dXV1dXl5eXlzTnZ2dkl5emhoG0lKG2p5dntGSWZ2dkh7dnZ2G2Zmahtmdht2 dklJeXZmdklJdUJJdh1mYmZiYk1NTU1qampmZmZFSUpJSUl6TWFxQWZ2ZnZ+entGRkZoaGh2dgME EVBFRUt+enoDFUdMTHp/RUxFR3p6enp6enp6enpMTH9/f3odbGhsbGdjEBFwehFnAGwRYxBsfmds bANsbGVMR0xgekx6fnV+dUx6fkdMfUcTfnp+fnVwTH56bXl6dXFBcXtsbGxnbBFsenp6enp6dXV1 dXVHR0dHfnp6enp6fn5+fnhxenp6TX1+bm4DTEwDEX56YElLbHp6S396enoDbGwRA2x6A3p6TEx+ emx6TEx7REx6BGxnbGdncHBwcBEREWxsbEdMTExMTH5wZXVBbHpsemN+f0lJSW5ubnp6DA8YUEdH T2N+fgsdSk9PfmRHT0dKfn5+fn5+fn5+fk9PZGRkfgYSbhISbWkXGHR+GG0HEhhpGBJjbRISDBIT bE9KT2V+T35jeWN5cH5jSk9jSh1jfmNjeXRPY34UfX54dER0YBISEm0SGBJ+fn5+fn55eXl5eUpK Skpjfn5+fn5jY2NjfHV+fn5PYmMVFQxPcgwYY35lTE4Sfn5PZH5+fgwSEhgMEn4Mfn5PT2N+E35P T39HT34PEm0SbW10dHR0GBgYEhISSk9wT09PY3RseEQSfhN+aGNkTExMFRUVfn40NR5QSUlxaGJi NQNMcXFiaUlxSUxiYmJiYmJiYmJicXFpaWliDRgTGBgTbB0ed2IdEw4YHmweGGgTGBg0GBgScUxx amJxYmh8aHxyYmhMcWhMAmhiaGh8d3FoYhliYnx3RXdkGBgYExgeGGJiYmJiYnx8fHx8TExMTGhi YmJiYmhoaGhieGJiYnJmaBsbNHF0NB5nYmpOcRhiYnJpYmJiNBgYHjQYYjRiYnFxZ2IYYnFxY0hx YjAYExgTE3d3d3ceHh4YGBhMcXJxcXFodxJ8RRhiGGJtaGlOTk4bGxtiYlBSUVBQUFVQVVBQU1BX UBLkUlGTVlfoU1gQQ1BVVJNTUFpXVJNRUElYVlWTUlPsURFQWVF1UQZQSHtApmytbB5ApGwdrWxQ b2ytbECsbK1sYWBxQXFBdXFBcVFQVFCscFOQrBBVUKtQcFSQUFBSUP+vtVGsVTtQQFBMUC7tUuBQ TVBKUsNQTlLC401ZUVDoU0kQSkEZR1vATvBOUk5HR0pcRBlKUBBJT2RQklFR6K+QEEJJT2RRXF9K T0pSSnxfXE9cUlzoUUMQWe9WUVZJTYifSHseQKQNHb0NtA1CaXt/vXtAvR5AFTUUtg1Qbx2ttm9h YFEWFBYUGRRRc3Z3d3ZlZGZjYkZFRFdXVlNiRkVEVnNydmVkZlE8fFd3ZH8MGhgPYmVMchMPDxMT Dw5R6SLyipQFHQ4PGRyAiiSugQ8UEw8PExMwUFJQ4FKBU+pVO1BcUElQDxBLUlhCRGRSWEtNZFBR WlRdXkdBUFFXVl5GXlJe6FEqEElERFdRQdc/R89HUkdKS1rXcFRRVElKiJ9Iex5ApA0dvR5Apg0d rVBvbEC9IUFpaVFBQmlpQUJpaWFgUXt7UXNTdmVkZmNiRkVEV1FzU3ZlZGZjYkZFRFdRDWE4RAdt Fh5IUdBiNUgJbhcbSlKBUdEbaW4HC2V9Dq7RUdAIYGoIDmFzOFBQUlB4r7RTh1U4UEtQT1E/EJFb VVtOS1VLTlRRUFlSRVRQWVNEVVBZVkFYUFlXQFtLWldAXEhdV0BfR15XQEJHXlZBQ0deU0RGR15S RUlIXVJFSktaUkVMS1pTRE1IXVNETkhdVkFPS1pWQVpLS29QWURQUFldSEhvR15ER0deQUJCTk5P T1VVVm9XV1hYW1tcXF9fQFZeXV1aWllQU1RUTExNTUNDRG9FRUZGSUlKSlIQUVFRS0hIR0dQWkVE REFBQBBfSWRfQE9Af0BTQGNeVlNS6K+QEHxfSWRwUlFSY1BI/0fWXf9vXlFeSnFa1ktZ1kv/f1C/ UFJQEF9CZFBJcD/ZSHseQKR7DR29tEC0HkCmDR29pL1ApA17bGxApA17bEBsQGxQb2xAbEBsfw1s bEBsQGxAbECtbEBsQGxAbEBsb2xAbEBsb2xAbEBsQGxAbECtbEBsQGxAbEBs11V+ey1AlNd+SHst QJRfX19fX19fX19fX19fX19fYWBRDUdDc2VjQ3NlY0NjU3FDY1NjRXNTY0VzU3NDcVNDcUNxCgbY 8muNpwfUCFF3BtQI3PVssaoG1QaujQokUXZqropMUfjVUXTSUeGuH1Hhrh/SrozVrghR+K4IUn1R dFBTUB+vJlPvVSFQdlB+UGVRBRByXVFbfU1RS32ZQVVlRWRYTFBMWH1RfktZfVFEWUtFZFF9fehT WRB3RWRERUVkfVFFZFRKWmRFYkdRfVR7T09NcHFxWk1dXUNaX15eSlhZ6FKY4lpMS+5RSlBKUH9R yFBXUENRyORXgVpddutRyFBNUHdRyONNSlRx6FHF4nBwT+tRSlBUUF9RxeReXl2BR+hSpOV7EEFE ZHvtUqNQS1BUUqRQYq+Q40FEZGLoUqMQTVhYV1d/f2VlUFB2dk1NTFlaWkNDRER+fnd3SkpM6FEM EEBLcEtgSzBLIEtUS2dmpaFIe0FCaQ1/vWxAbEBsQGxAbEBsQGxAbEBsQGxAbEBsQGxAbECme71A pnutpGxAvUCkbEC9UG9svUC9b7S9QL1ArGxArGxCaX9sQUJpf0FCaX9sQml/UUFCaWlBQmlpUEFC R2nXXn57Xi1AlF9fX19hYFANUUZHRkVEVldFc2V2dndBY05SR0F2dmVkZmdlY0VGR0FzdnZ3dnd3 VldWRURGR0NmZmVkdndSZr8SCIDpBzr0OnpEBtMxoc+YmAf6/HdNARBhAAcZfBYRKgcGABcPUxPH HTjdyoVAJT5ST3lREz7YFVhRvsflKNKXSX9/XA2ujzIufXFGU1ZyZRt+DgGs5EQxGW8+FlBQVVDe r5dXIlU7UFNQX1B2UGJQGVEA5ZNQk1NSe+ivqONKTWRY6K+o40pNZH/or6gQXkpNZF5YSkxkYUhC RGR/6K+440JEZHvor7gQXkJEZHlIQkRkXkhCRGRY6K+440JEZFzor7gQWUJEZFZIQkRkG+ivkBBf QkRkUFFR/1JTRFJSU1JR6FNB5n13bCBjUWPoUmQQX25sfH59XVBTVFpsL0tRS+hSZBBAQGxVX1RV G0dHSoB6sHpSeuhSnecUh4BosGhSaOhSneQQkGBRYOhRFuZwUP+QU1FT6FJk5FdR/xBS6FEW5nCA V7BXUlfoUp3ncYeARbBFUkXoUp0QWZBdgF1SXUkaG+xRh1BxUCpRSFBIe3sepA0drSKmrSJKrUpI vUCmDUitSq0NSkitIqatIh4VNRS2UG9sbB2tpg29QGxsb2xsraYNvUCkbNdVfnstQJRhYFF7UHt7 e3t7e3t7e3t7e1ENUVFzUXFiRkVEVnNydmVkZkdyV1ZWRURHRkdGY2JnZmdmZWR3dnd2UWJGRURW c3J2ZWRmR3JXVlZFREdGR0ZjYmdmZ2ZlZHd2d3ZWdaxt1lOSrBDek5TB3+2S3kZeSUlBWkhfREZd R1tBQFtJXFR6wZOW3NuT7sFEXkhKX1tKXUVDXElcQUBcSFxVO6oMVfSZz/OblPD1nWVdRyHh3R18 Rl1cRX8c2fgbZEhbrTmX8fOcnPDxmmRcRj3K9BhjR1xbR2QZxMwYZEVbUFBTUAKvsVYBVTtQYFBt UBpRahAryVbFS8YU9RP0FOQUlGJXeFz4TFLlFJIUlRVTKUPSFFJoVjVfJl9Tb1FvUmpUU39/f2B3 GVN4XH99f35Tf1B/UX9SU3t5YVZhVlZuRE1ERERNYXl7VlRca01uGURUe3BWe3lhVGhZRBluTVRz FlKSUWCSUVBQQWj4c1EW6FKs4kdbWuhSrRBZQVtgD1A/UFJQ6FNxEERcUg9RP1FSUXxckl9dT11S Xe9KdupSqVBkr5AQWUJEZG9kH2RSZOhR7xBbf2tvax9rU09rUWvoUqoQXUBw8HBScOJfEk8SUhLo UqvlSgYbP9lIe0CmvQ2kDb0NDaQNe71ArQ2tpA1sQKQNbFBvvW+9b71CaX9svUC9QUJHaUFCR2lR QUJHaUFCR2nXXn57Xi1AlNdelJRhYFENDQ0NDQ0NUA0NUXFFXlJXRkdGY2JnR1ZXVnNydndWVnNy dmVkZmd2dmVkZmNiRkVEVldGR2ZlZHZ3dWZmZWR3dnNyVkVERlNWV1ZFREZGY2JmZ3ZU3lHwFgDQ JDYQfXsabHkCDRcLHt01LYwn7rCGnEpKsf/d9fnnIYrDamiuIjkYa3dpfxNw5ABxfz3KHXYPaKFT e3dab7beDHRJMUbxFGMTDAQbntvGjgERLGrwhd0OIfETl7b1JnprVjN3CW8gHWMab2EgroNydmgV Duo2cXGnUFBRUNxSglHjVTtQXFB241BaVFHoUSrkV1Fa11TsUWpQXVAqUUhQSHtApr1Qb71RQUJp YWBRc1N2ZWRmY2JGRURXUWlgOUQFbhcdR1KCUS4XbBEHDGZ9C1BQUVACrjZSwlU7UEJQABB4117n X1JnVMhSxFn4UvVZVVGSUFNckl1DXVxcUFBRYERfV09Xf1dTV+hSxRBZEEBRQAZDP8ZIe0CmDb0N QKZsQGxAbFBvvW+9YWBQDVENUUVWV1ZXVkFAQkdGR0V2UEFAUFLCOGEUdmAHG2QNoa7hUR5VO34U EQrd/66Wroiu6DUWZWIBUaNRFFEQUb1QUVBJrjZSCVU7UEJQAhByZlTXVdhf6F9UxlLJWfZS+VlU UZJQQ1ySXVNQV0BXcFdTV+hSxRBBH0BRQAZEUFFRXFxdYEMC2Uh7QKRsQGxAbECmDb0NUG+9b71h YFANUQ1DZWZnZmdmQUBSd3Z3ZUZQQUBQSThhE3dgBxtkDaFRH67hrjZ+FREK3OBRalF4URc1FmVi Aa5druyuka5DUFBRUCJSNVPeVTtQG1C5EF1aSFkSa0hrElRwQ1FD6FIq5klJT3AXURftUipQEVNB UGxQeFNB5VBkQGRSZOhRFuRsgFdRV+hRPxBEXlBP9n72UJIvbFGPbFFsV7BaUVror5AQSV1BZFoR Xr9UUVQQXUFkVBFQRhBqZUatXhTor5AQX2plFK1QEF72UPZPkmySdeivkOZ8fmTAdVF16FESEFln EHx+ZM9nUWfvURJQcFB+UnpQHFCEUWNQSHtJQKZKvSJ7vSJ7vb29vUhKQL17QL17QLR7IUC0eyFQ byINvUmltUBsSL0iQK0NtECkvSFAbEC9IWFgUCFRflJlZGZjYkZFRFZWV2ZmZ2ZjYkZFRFZzcnd2 c3JXTlJHRkVEVnNydnd2dndWVldWVnNydmVkblJnd3JXVnNydmVkZmNiRkdGUb1TQRERd3tvbkFV aGB/b2p8bBprRGNITHUbe2AmSkNqeXsVXVhDT3FGWF0SfHlrfSl+fDtMSWtGaRhrfW8kQUhTsGps LnN+FhFkeSRtbEdyYhNqeHsSU1FUYXVsckl3e2sXC2tmZGVqZgsUaHd4bxNyfFRRVBB8eWsoXUFQ UFFQeFDYVD1UmFBbUAnjcFJRUuhRRBBbUf9aV/9U/3BaUVroUUTkWXBVUVXoUUTnU1hvUnBZUVno UUQQQD9Q/1C/UFMQUFFQSVwCM0h7HkCkIQ0dpA1srWy0DVB/pA2tvUCttA1hYENxQWNBcUVxQXNB cXhRsdNRsa5P065PUrhRsK5w1K50UYxQUFFQEq7JUe1RY1BHUGcQQalSUVdZVFGSUJxCGVxaVBtF 6FEWEFtRY09fUV8RSP3dSHtApA2krb1Qb72kvVFBaWlhYFENQ2VmZmVkd3ZzcldWc3J2ZWRmY2JG RURWNiQ5V1dXVlxNe2sHNBcGKv2uyXxizwNBWVhXQQxuEjTVJN+OUFBRUGJRP1IpUm5QU1BKEFxS i1BQSlVRSVT93Uh7HkC0QLZQfx29YWBRcWVxUimt6VIXUT+fUFBRUAqvt1H3UWRQW1By5FAZVltT 6FFDEFtwWWBZUllJXD/ZSHseQKwNHb1Qb71hYFFiRkVEVnNydmVkZlFQFjEyFRUxMVFkMhUVMTEV FTJQUFFQUq+xUm9VO1BTUGYQTVBRUW9SU0RSUlNQU1FRUltT/1BKVVH/UnxU7BVIe0CkvR5Aph29 UG9sb2zXVX57LUCUYWBRUXNRUm+uE9BR71U7qiZV2lBQUlAar7RT5VU4UEZQe1EaEElZS1ZPVnVZ eUdXSEtFcEV1SHlZV1hRJ1hN6FFa4kJVd+hRWuNWXUJH6FNaEHVQEHR2ZFAQe35kUBBjZmRQEGtt ZBBQAFDwUFNQSn1CX3JPclJy6FNaEF7fXVFdEENFZF1JfKWhSHseQKZ7Ih29DRMIEEdyEHR3ZHIQ e35kchBjZmRyEGttZD9yUSF7e3t7CR5ApiF7e3t7Hb0TCOlQR6+Q43R3ZEfor5Dje35kR+ivkONj ZmRH6K+Q5WttZDBHUSF7e3t7CVBvvW+9YWATKRAyUXpwcU9xUlZfXkBeUlZ0c3VzUlZbXFpcWVxY XFRWRUZERlJWSUhKSEtIU1ZSUVNRVFFTVnp7eXtSVk5BcjJQdldyMlBMQ0cyUXhVRzJRcV5NMlFz XHcyUEhGTTJRe1F3MlB7e3t7UXt7e3t6enp6enp6etFQIVEhUURXXlJzcnZ3dnd2ZWRnZmZjYkZH RlVAd3Z3dnNyV1ZWQUBHRkZjYmdmZ1PlaXIjwgYyzm18cXtuY4AkJp1gE66cVFp2SWh7SXVKRF9o fmJJelZS9pvgPNoBNA0UIcnzjenJ8/HY64xRNGvbYXBIc+Gtv66wMhdgcGglUFBRUNdQUFMzVThQ R1DT7FBeUf1RZVBYUfXmcg9XP1dSURFdUf1RZVBXUalQc1BGUfVQX1GnUEVRZVBGUlIQXl9YUFVY V1xQX1FPUVJR6FNZEEBeXgBfP1//X1NAX1FfSUhe7lJQUFhSllBIUkdRj1BIe0CmtB5ApA0NbB1A rQ1sUG9sb0Jppb2sUaV7UQ17YWBRQURGRmNjRXFlY2JmZmVBZHZ2c3JXd3VSy0YWHU+tZnQHGkpC YXBjGUJRo1U4q/stFXx1dXgW0FLvDn9xcHS0UFBRUGJQUFPMVThQTFC4EHTYUv5S/FNTd1zFU1Ja W1pbUVBVS0LwRuRGUkZMUlJHUVpbWEzoUTDmQn9H4EdSR+hRcuJRQljor5DjW11kWOhTdOReVVFc U+hRpBBLUFVAVVJVjEKDX0xR70xRTEpOX1FR71FRUUlN6lEIUcBQSHseQLQNIUCmDSEdpK0NtFBv b717EwwIEENYEEZdb1gQR15vWBBJX29YEF1pe3t7ewlArQ0TDAjpUEevkONGXW9H6K+Q40deb0fo r5DjS0BvR+ivkOJMQW97e3t7CbRBaWlBQmlRQUJpDUFpQmlBaWlAmWFgUQ1QDXFxZVBCZWR2c3JX d2ZmY2JGRkVEV1ZRcWJmZmdjUwCsslE/zdIOygV1ZozAN/owGjWu/FF1PBF6cnRGUeVRfsA528pd kOgw9xnV2emu5UJ7FVBQUVBxr7NT2lU4UHtQnxBPV19HXzh7KXvVRdVGy0PFRvlC9kbqQ1t9TG9M UkRYUehRxRBZUFBAUFJQUHFbEVlRMFBYUHFSnFB2Up5QSlBYr5DjXUFkWOivkONCRWRY6FKe5hBe VUpdUEToUkPkcFFRVVrqUcVQW1FK5k5QVUBVUlXoU1rnQYNQeUB5UnnoU1oQQV9HUUdKfV9OUU4Q Q0VkTkl86lEIUcBQSHseQLR7IUCmIR29DaS9DUCkrUFpf0lKvWxQSG9vSr17e0CttEC0Qml/Db1C aWFgUQ1QDVFlblJlZHZzcld3ZmZjYkZFRFZXRkZFRFBxcnd2ZWRmY2JHRkZjYmZlZHZRfyIIECkK 3DJ1GLHa3ecFCyUrrp2urvwfaRJ7cU1AkwUaOpBS+HNxaSVsAyfEXff4/CMb22Vp9y6ErodpeG9+ EV5YzyUK2bdQUlBjUFBT/VU4UFpQXVDJEEhvXVFjUVFTUFRSV1laVVhdXFBUWF1dW1voUQwQQFBR RFBQUVtQUVdYW11RVFDrUaxQVVBaUkAQXFhRVVhcXVBYQFhSWOtTWVBSUFdRMBBIf1RvVFJfVE9U UlRKX1AQQ0VkUElepaFIex5AtHtApg0NHaRsrQ1sUG9vQKRspmxBaWlRQUJpQmnXfntULUCUX19f YWBRDVANQ1FjQWNFc0FxQXFncUFjUtQqLCyuva5FMVHaUa9TOazHn66AUWCfUkdQUVAVr7RT41Uc UHJRABB+XlZRWVpJWnhQeFNURFpFS0VMU2hWGVbnVVNbVVFKS1pMVE1AS1pMTVRRSlRTU+hRDBBA UHJEUFByQl9yUVByQHJScuhTWeRCUFRRVOhRv+ZCcFPvU1JT6FFy41FQVEroUcoQWl9DT0NSQ4xc XVLoUpjjUYFYUOtSVlByUE1RpRBKEFgAWPBYU1hKdECB33JRchBDRWRySXOloUh7HkCkeyIdtECm Ib1AtECktFBvvQ29b2ytDRMMCBBEUxBMQW9TEEtAb1MQR15vUxBGXW97e3t7Ca4hEwwI6VBUr5Dj TEFvVOivkONLQG9U6K+Q40deb1Tor5DjRl1vVOivkOJEXG97e3t7ewm9DSETDAgQTnIQTEFvchBL QG9yEEdeb3IQRl1vchBEXG9yEEJbb3t7e3t7ewnXVX57LUCUUEFCR2lRQUJHaWFgUCENUSINIVFx U3FXVEdGRURWVHNyd3ZlZGZjYkZHRkdGY2JmZWR0cXJXUWhSKzWtumNRCerJ3q6uyvYJbhF7dwAx bXxPdwIjrvCupEtmVRyurtddz9OTLb/RbnxoexJwFHpAXCgE4IxRUFJQHK+0U5JVOFBHUHdQnxBZ RFNRNkYmRlJa6K+oEEVCRGR6U3RFl0VTb1hVckhIT1VZdkXtUppQUVHFUFBQWVHK5XZ2QFBVT+hR WuRAXXKMXOhRseNQSnlI6FKZ5V9KT0pSSuhTWhBbRBBDRWRESXiloUh7HkCkex29Db0eQKYdpr1Q b71vQml/vUC9tEFCaUJpUUFCaWFgEykQfkt1WkN0dkxLTUtSVkJ1XnZ1WnIyUU5BSjJQcF9yMlFz W3YyUUtDTzJQcV1PMlBQe3t7UXt7e3t7envR0VANe1ENDVFFXlJXZmdmY2JGRURWVnNydlJlZEJ0 UVZFREJHRmNiZmVAd3ZzclOS5Ysvc3xNERLImz6aIy2EJ4tRw66ZWGV+cX1+GBN7GXhVOEx+wZ/J TllEje/WsCrZUVjLtFHZua0+2hDarq5kdTv0UUQ5FFBRUBWvtFOfVRxQWlDGEFtQWUlVUlZYV1la WuhRzhBfUFFEUFBRWlFQU1lXUVhX6FGkEFxCcFLvUlJQUkBSUlLoUXLmWVlYVFBcVuhSmxBaWUpc wFdRV6ZbpelRwVBIe0C2DR5Aph20UG9vbECtDQ0TDAgQRFIQTEFvUhBLQG9SEEdeb1IQRl1ve3t7 ewm0QmlRQUJHadd+ey1AlFFBaWlhYFENVVFxcldWV3NDcVFRO1Ehrrf1A2p2djJTeK5pTFQPe04D UfWqyFBQU1AYr7RT6FUzUEdQdFBiUVoQB1NcVENBXERDFVw4dil2V3VRZ0cGYidU01LUScpdy3T6 Xfp06FjmRFx7UG9QZFxTA1wAdTNcI1zTUFV1XF1dYkh0dFBcX0h1YXJQRUt1SFxQVFZCYlF0dOhT WRBFXWJEXV1iUXRTcmJdYV9ddFFiVFZP6FFa4kJVfuhRWuJWXUvor5DjW11kS+hTUBBNRWBhjBBT AFPwU1NTSmRfck9yUnKMX2B6EFldZHroU1AQXt9ZUVkQQ0VkWUljpaFIe0CmeyK9e6S9DUCmIb2k rXtQb71vvUJHaVFBQmlpQUJpaddefnvXXi2UUEFCR2lRQUJpQUJpaUJpV15AbNdeQJSUUA1RDWFg UA1RDVFGRkVEVnNydmVkZmd2dmVkZmNiRkVEVldmZmVkd3ZzclZFREZTVldWVkVERkZjYmZlZFLq 3z+nhJmML8TxC7eZkoEhk3V0aHoaEw45fU9dRHBgCX8ZNFKuOeUl9LOW3z30FCvMN9if59Aww1hi LBrSFWUxGBnNrphMR3PWGQ4vaDsNklBSUG+vtFPnVThQRlB4UJAQS1pTSlN6U1PIWfhZ6FmYXFQU WFVHc1VYR093UetRxVBQUFhRyuN3d1BP6FFaEFxfVVBdR4FQSUBJUknoU1oQQkNKenOMW4FREENF ZFFJeaWhSHseQKR7HaS9HkCmHa0NtFBvb71CaX+9QL1BQmlCaVFBQmlhYBMpEGJKdllCcXVddkF1 S0pMSk1KU1Z1dnBeczJQTkBJMlF2WXMyUHJcTzJRSkJPMlF0WncyUFB7e3tRe3t7e3p7e3vR0VAN UQ1HZW5SZ1ZWc3J2ZWRmZmNiRkJFRFJUUWZlZHd2d3ZzcldWRUBHRmNib/a310tuB2DKnT+ePyeE Lp2uOlF5WnpIf0l4Ykx3EnsZd0xMdsSK3nBJjpHWjyvYrq71hq4ovVLYIAXmzQd5Rntr9q67ORRQ UFJQ/6+3UaxTklBbUEdQYulQSa+QEElCQ2RWGVBXXBlCW19TGVl870VRRUlIiJ9Iex5ApA0dpK1s UG+9b71hYFF7UWJGRURWc3J2ZWRmQ2JGRURWc3J2ZWRmUQYVMTEVFTExFBYxMhUVMTFTkjEVFTEx FRUxrSIyFRUxMRUVMlBQUlDIrslSQ1OSUFtQc1AJ6VB1r5AQcEJDZKleUUNFQF1WGVBXQVpdklyc ThlIWlMZWWBLQBtx6FEWEF9dY19LT0vvS1NLSXQqykh7HkCkDR2krb1ApL1Qb72kvW9vvVFBQmlp YWBRDXtRYkZFRFZzcnZlZGZTZWZmZWR3dnNyV1ZzcnZlZGZjYkZFRFZRBRUwMRQVMTADJDlXV1dW XE17awc0FwYq/VOSMBUVMTEVFTCqh3xizwNBWVhXQQxuEjTVJN+OUFFQeVDpVD1U21BWUNgQdkZV ZlUHVVNWVVVvUVBEUVVUUVBUVVVvUlNEUlVWUlNUU1BTWFZT6FF75FKSUZJV6FF753BQVFNTUFBW 6K+QEENZXWQQVlFWSlhREFJRUklXAjNIex5ApCFsQKYhe2xAbEBsUH9JSh2tvb29UUFCR2nXWH5I e1QtQJTXWH5Ie1QtQJRhYFENdVFlUUVRUVQ9q+xUFKzjUx3pUe4BUZPars+u9VBSUHhR71Q+U9hQ U1BXUBoQWlRXUFVWWVFXb1ToU3XmUG9TEFFRUeivkBBEWV1kUUpZEFBRUBBDSWRQSVgCM0h7HkC0 eyFAtnshUH8dvaa9UUFCaWlCaWlhYENxRXFFcUVxeFQWq+pUFqvqU9jSldJQUVB5UOlUPVTbUFZQ whB0aFUIVVJWVVVvUVBEUVVUUVBUVVVvUlNEUlVWUlNUU1BTV1ZQ6FF75FKSUZJV6FF753BTVFNT UFBW6K+QEFpeQmRWR0dKV1FS6K+QEFtZQmRSR0dJWAIzSHseQBU1FKZ7bEAVNRSke2xAbEBsUH9J Sh2tvb29UUFCR2nXWH5Ie1QtQJTXWH5Ie1QtQJRhYFENQ1FFUWVRUXlUFKvsUx2s41TbrhMCrm3b UTBRC1BSUC2vtVPdVTtQclB+UNQQQldLR0tSx11RWf5KUfBEUURWUepTSVBzURTmeVtQklFRfOhR FBBGUHZAdlJQdkB2cHbQdlR21lBWQFZSVuhRFBBdT01/TW9NsE1UTahgQehRc+VQR0BHUkfsUWpQ f1CEUWNQSHtApiG9QKYNvQ2kDSGtaX+9UG+ttm8Nb71hYFENUA1Rc3ZuUmVkdnNyV1ZFREdGRURW c3J2ZWRmY2JGRURWV1ZWV2JGRURWc3J2ZWRmUbZ5Ukk5cTgXZnVMQ3sTYmgcnOeSmzjFNG9CEw4O ExMODlHqPz6RJQbVLk1GSEByHWZhEh8RJuLp0w/xMhI3rA4TEw8PExMOUFJQDK4WVxRVO1ATUAZR xxBrVVFAX0BEQE1AcgdL+33rfVhPQEBDQkdCSnJu20tWGks4SypLU/xYE2BgUGB+UBMDUVtUSEl3 YBMUHVDqU0FQUVNCEEQQXjBzURQwEFdMbEBFUUUvVzB7SehTTRBfHcJmZk97UXtaEpIDKH5R6lH4 UFBRMxBLVMhAflF+fgcIeP5a/ncRSUoIYxEfqBrVaeJC6FFn5U9JBz8zSOhRfNV7HkCkHb2krba0 HkCmHaStvUFCaX8NvaS9QKS1UG8NbECttUCtpA29b71vvUCktEFCaWlRQUJpQUJpQmlpQWnXQF5s YWATKRBpFRxnb1V9GBkXGRYZU1ZramxqbWpualRWeXZZdUB1cXZ1dRVvGi5QHGcacVBWfFRxUFh6 W+1RRE1C6FHQ41BGS0joUdDnUUpJR0hfckLoUdAQTVBddFvtURlqFC5RG2gdcVBVfVdxUFp4V+1Q Q05F6FHQ41BHSkXoUdDjUEFwXuhR0OVRXHZe7VFQe3t7e3t7e3tRe3tAbEBse3t7e3t7e3t7e3t6 etHR0VANDVENUWdTVkVERmNiZkJlQFBxclRSRUBQcXBQZ2NSUHFwUEFAQnRxYlRCRURSVHNydmVk Z1ZXVldWc3J2ZWRuUmdmY2JGR3dyV1ZXVkVERmNiZ25SZWR3dlTLpOdPf3IVi9+uza6zpq4+vFHp UQVRSVHuDW0ormWugK4vrlyoUZBRQI1RG/bjrqXKMzhIA35vbnhjFzERIMMMf2ZoGV0ldnViaTZ1 RkN0YyQaSkNTzVqt3DhkcH/PUXf3UURRM7euGKyu9q4XUX6proqul1GhUS1RVlHvouGukOKfrvrz Mh1mB9plF3FFIT0gh+3GYUoWBwV6adW/wXxgTHfqszAVdEtQUFJQQFBQVeBVOFBxUHRRYBDDckBb Qm82QCZAJ3PXQNZz+l3nQFfGXeNdUlF0c1JQcnNzcVpeW01aR3FITUdbWVFZUlhNWUZBRU1GUXRa UHJGI3NfQHBzUHFAcVJxc1JxfUFAREFBQHNSc3FSeF5fRF5eX1ImXlFeWipBUXFBQF9URnNxQV5S VFFHc19ydHhQUFFRUbRAEEBfU0dGRlpaWVhfRlFG6lHSUHNRfhBzcFpJYHYgdtB28HaAdrB2VnVA dnB2EHYAdtB2wHbgdlffPUh7HiFADaRJSh2tvQ1QSG9sQGxAbG9sSkCtDWytbEFpQUJHaVFBQkdp DUJpDWnXXn57WC1AlNdefkh7WC1ADZR7QWlpQWlpSFBAvVFAkFBAvVFAkA1QQL1RQJBQQL1RQJBX QGxsV2xsYWBQDVENUXtRcVdWRURHRkdFcWVmZmdRY1FGR0ZHRXFlY2JnZmVkd3Z3d1NTUwSucWlM fks6rm0ZDhVRtUNRuRZ9cm6tIEsfcEZWUkw6moBR0tQSe2lLQFh1dVszy1Rqq/jOeU9VdXVGQE5C Q1kSo1GDrn1QU1B7UFBVXlUcUEtQdFBhUQUQwchHUUI1SyZSJmD3SPt86k7qfJxXjH2pf1p4UWhR GFEZSwVSCUs1UtZS1GD4UZd8hHy2Trhypk6ocqhgQRhYdnVMdHR3XnBNWXJyX3BNRHJzYHVOU3RQ fnBgYXpQdU50TFBQWURMfnV1WUR0fkVFRFJ6flhYWVhQcEBwUnCOSc1CVEpjdGFfd093Und9X15J YmPoUVTjcW0ISHt7HqRsHa0NtB5Aph0TCOZQfkB+Un4duQ1L4X4dvQmkvQ1Qb2xAvW9sQL1BQml/ vUlBQml/QUJpQmlBQmlRQUJpQkdpSHt7V0BebGxsYWATKRBie31xc0ZIVVdHdXJ2R3VWdnx1c0Zw f1FyRnB/UXtXfn9RcUh0f1FxSHN/UXJzfVV6f1BQe0Bse3tRe3t7e3t7e3vR0dHRUA1RDRMMCBBC KmC5fVJ2fHtgaXIJfNZ8hldWUA1RDQlQDVFGR0ZFRFdWcXFlYmZmZUFkdnZzZXFiRkZFRFZVYmZm ZWR2dldBQVdERmNiZmZlZHZ2U9+RHiArx66wrR8OE0tLFA1S2rmSIN6tsd7XGBfUwlFnZgDXGAjK Up99EAvByTQpdXNoPlMgPmlydQP1DTLJQhAkCgojbFGtzK4dYmZnF9cDD8dsUFBRUAGvsVUHVTtQ dFFx6VBGr9DjWVpkTOiv0ONZWmRW6K/Q41laZF3or9AQDVlaZFxKWUtmQx1K1kbbSt9L2UxYO0E7 QilBKULZQfdW+F31R5dHm0taVkZQdhNGEUzQRtVH1kvUTOdU605af3Y4TydWJl0mS9ZDyEf5R+pf WWdeQUJ0TVAKUk1RUehRRBBNUApx+UFCXlU6TVNeOkVZUQ9/QVFBSiB2UXZCdT7pUWJQSHseQBMI EFlfWk9aUlodSUmkHbkNS+NaHUlJpB29CR5ADaYNHbRQb71vvUFpabykvVFAvaS9UECZYWAbAynh YlgTKRB0RkxWXVx2R3VYWVdZUlZLdl1GWnVQVkxadVBbSF51UFlKVXVRe3tRe3t7ent70dFRDSFQ DSFRe3t7e1FBc3Z2c3JWV1ZFREJGY2JmZ0VWVnNydFJlZEJ0Y2JHRmNiZmdVB3d8oMgvhGFvDJTM 0IUmIqf1ia7/55tRCZLfzwxJcH9XVTuueuiUwibH6eauhckg2SUnO/5RFuiSUQyQbnR/Y1BQUlBL UFBVIVUcUEtQe1FbEAxK0FlaZHPQWVpkQNBZWmR70FlaZDdDOEg3dcp56HhVN0E5QzhIx0HIRvRD VjNeV3BNUHJyWHBNXnJzTH5fXlJyZUtLUFhCfUxfTU9NUk1uWGBXUQBXUVctfG3lSHseQKQNIWwd rQ1sHUATCBBAUHZAdlJ2HVBEQERgRFNEZqYNHbkNS+Z2HWBEUURmpg0dvQlQb2xAvW9svXt7YWAb AynhDlgTKRAac3tASkJDQUNSVnh3eXd6d1NWQkNBQ1JWeHd5d1JWRkVHRUhFSUVUVnR1e0B2dVF6 QHZ1UXNKdnVRd0NMdVF3Q3t1UXp7dUVydVB7QGx7e1F7e3t7enp6enrR0VANUQ17e3t7Y2VjYmZn ZmVBZHZ2c3NlcWJHRkJFRF5SV1ZzU0FERkdGY2JnZkFAd3Z3dkt9a29fWUYTaX1SD6PE5esMwu/a bdMKQENLY/cIKAIRNhh1dXBFOVMsOGR3dRIBruif36HND0pcVK+rjgR2Wl8iylEUUVXMKnxPUFFQ eVBQVKpVHFBhUR4QvUZUSVlScGNgYyBjwGP4R4dEh0e2R6dHWSlaJEUsftlTwkRV2VrIU8haw0X4 U/haVnBEFUUQYwBjKVNVWlNaWlJjEERcb8RUzFn0VP5Z9kRVXFFQVwFcXJtYTVdwcE1IcnJ7AWFh sXxNe1YBUVGbVU1WcXBNeXJzUVZQXFddUEVARVJFRntERUZTR1dHRuNCfkhheHlRflxcSHlSSFhW V19XH1dSb1cfV99X/1efV49XVl9XP1dSV2Jj/3vve1J/e297H3sPez97L3vfe897WHvTQEYgRsBG U0ZKEGNRY1BfXU9dUl1ucXBJYm3lSHseQKRsHa0NbB5ADaYNHbQNIUFCaQ0hIn9sUG9vQml/vUC9 QL29bEFCR2lRQUJpDUFCaUFCaXtRQL28UECtUUC9vFBArXtRQL28UECtU0BVbGxhYFANUXshDQ0N DVAhUUFjYmZnY0FzflJzQURGRmNjYmZnY1NxZWNiZ2ZnZmVBZHd2d3Zzc2VxQXN2dnd2c1J+S9Ek QHZ2XB02MUNkagHutWJ1bas8fWt0Sl5bVVpLdhJ9VD92TTkwaMpUrq2I8s6taiTEY67SIGJw4OSu AXVFXnJINlMsDEVzQ0x1rj/D0E5CUFFQflBQVPZVHFB8UXEQHVdUWVp8U3JbGltVVlVWWnZSdlN2 VHZadlt2XB9TFlofWzZaJlrWWl4qecB+5VTlWpZUllq2VLZaplWmWlpecE1EcnNNcE1FcnJ2AXx8 6FJ4EDp3TXZfWFFYAVxcm1lNWFBXUVcBUlKbVk1XTnBNdHJzWFdXdlJcH11SH1F273VRdUrgflF+ UFFdX15PXlJebk1fUE9QUlBuTk5NSX1ERXx4dFJ4UXhcXV10RF5NaURFfHh1UHh1dFJFWH1+7FFS UHFQbVFXUEh7e1Bvb2y9QL1AbKRsQUJpf2y9vUC9QGxRHkCkbB1AvQ1ArQ1sbGweQA2mDWwdQLZA tkFCaX9se1FAvbxQQKUNUUC9vFBApQ1RQL28UECle3thYFENIVAhUUFjYmZmZ2NBc3Z2c3NBREZG Y2NFcWVjYmdmZ2ZlQWR2dnNzZXFBc3Z2d3ZzUmN3CiIfXHNzQ/k7d0cTaX2ta31rdEpeW0YTaX1U KHleIz1s8lSurYNm0D2tB5ErrjE4ZHd1dUVeckg2Uyw4ZHd1rivZ1EtfUFFQA6+wVnRVPFBjUTwQ RlpAVXRTdV55KE/YT9R01HXdedh6WnPor9DjWVpkXOiv0ONZWmRW6K/Q41laZHror9AQE1laZDhX OFsnWyd06VPuVOhW53Tndud6WhRzFnkQetd51npVyXbHevdW81f4W5V1m3lXGl5IEEtAbyBIUU6Y TUgMckfor5AQREtAby9HUUGYTUdyc2NNUApSTVFR6FFEEHJQCmD5e05PUUBPXUdISHJVZXtTXWVy WVBBQEFSQW5RTkpl6K+QEFlcQGRlQnhJZGXsUQNQcVA+UbBQSHt7HqQdEwjmX1lPWVJZHbkNS+FZ Hb0JHkB7pmwdvQ1Qb71vvUJpf2xCaWlRQmlpUEC8pL1RQL2kvXtRDXt7UQ17YWBQGwMp4RVYEykQ YnB6Vl9bdnZ3dXd0d1NWV3Vcc1l1UF5xQBJRcE9fQFZ6WXVQWndddVBfcF0SUFh5VXVRe3t7UXtA bEBse3t7envR0VANUSENe3t7e1AhUUFzdnRzclZSRURCRmNiZmdBZHZ2c3NlcUVWVldWRUFWVHNy dnZ3dmVAUHFiR0ZGY2JmZ1XVdROupM/ImgQMnd1hN2ZGFWFzUsMba0BZ0q63x5Gvk2cWUf5RFjUB fJVCTGBEVTuucpSc+66e8ZOuitpFRFFKAH92dXVVT3RDGq62ams5+zva+1FiUfZAWBt5aVBQUVB7 UFBWRFUcUBNRbxBCE3JzUHFwQHBNWHJySBBCW29I6K+QEF5nTG9QSEBI8EhTcHBNSOhSiedyYnBN enJyauivkBBDQltvahBnTG9fak9q/2pTEnBNauhSieZyVxBCW29X6K+QEF5nTG9QV0BX8FdTUXBN V+hSiedzQXBNR3JzeeivkBBDQltveRBnTG9feU95/3lTc3BNeehSiRAOc2NwTWlyc3JxeBNQX1BP UG9QU1BXenl5SEhHUmppaVhYV1hzUBJAElISbmJfY1FfY1EPY1FjLVAVMBVSEBUAFfAV4BVUFXBf UU9RUlFuQVBAUVBAUQBAUUAtFG0mSHseQKQNISJsHa0NbB1ADSGmDSEibB2tDWxQb2xAbEBsb2xA bEBsQmkif2ytbHt7UQ17e3t7UQ17e3tRDXt7e3tRDXt7e1NAVWxsQGxsYWBRQURGRmNjRXFlY2Jn ZmdmZUFkdnZzc2VxRXNyV1ZXVkVBcUFkdnZzc2VxRXNyV1ZXVkVBREZGY2NFcWVjYmdmZ2ZlQVJg RxNpfa1rfWt0Sl5bRhNpfVKVfWt0Sl9bUY9GFGl8UpR8bHNKX1tGFGl8rWx8bHNKX1tS3K4MOGR3 dXVFXnJINlMsOGR3dXVFXnJINq7QUdA4ZHd1dUVeckg2rNQ4ZHd1dUVeckg2UfRQUFFQeVBQUr5V HFBPUNoQfXEQZ0xvWnBNUnJySnBNQnJyS3BNUXJzW3BNQXJzQkFSUlFYSl9LT0tSS25bWuivkBBI FnNvsFpRYFoQWiBakFpUD1qQWlJaSXBx6K+QEEtLTWSwcVEgcZBxUmBxEHEPcdBx4HGQcVZtJkh7 Hg0hIntApA0hIntsHa0NbFBvbG9se3t7e2FgUXt1RXFlY2JnZmdmZUFkdnZzc2VxRXNyV1ZXVkVB REZGY1K+rWt9a3RKXltGE2l9UpV9a3RKX1tHE2l1dXVFXnJINlMsOGR3dXVFXnJINqzUOGR3UFFQ Rq+xU6RVHFB6UAcQWlpwTVJycnZwTVHoUoQQSHNFRV9SUVJxZV9ZdlB1QHVSdW5az1tRW+hRMuN8 TU1I6FE240Ife9/pUbBQSHtApr1pf0CmDWytDWxQb71vbEJpf3t7YWBRZXFFc3JXVldWRUFEVlZz cnZlZGZjYkZFRFdWVkVER0ZjYmZmZUFkdnZzUXNSgXxsdElfWx6X3PuDBm5tA1dUZ0p2bXtoR0cT aVV3dXVFXnJINq04k+En5D0WBx5pTEVaAUFKQ0x8DYRShThkd1BQUVB+UFBWAFUcUGtRMelQba+Q 43J4ZG3or5AQzEBBZFhRWl1bf1trGVEZXT5dJlDXUMpRyl3wbehR7VzoXedr4G2sUELwbVFXfkd+ a1FuXQN/BGs6UTd+WFBea2tfX19rfn5/fV9XUVddWE1XTnBNRnJyfXBNdgxyZ2toTWdWUVVNVkBw TUUMc09wTXVyc19mUWZ/ZU1ml39Rf36Va1F+eF9rRF9fa1FQUFBAUFJQfV5dRF5eXVBrXeivkOMW c29r6K+QEGgWc29rf35fXl1RUFhtQGt/fl9eXVFQWEZnZnZ1UkZFV1ZYVkoQbVFtfV9AT0BSQG5P 8E5RTklsbexSBFBxUG1RSVBIe3sepCFsHa0NbB5ADbZQb2xsbG9sbGxCR2lRQUJHaXt7WNcdfnsN Xi1AlFTXfkh7DV4tQJQNSFBAvVFAkA17e0C9UUCQUEC9UUCQe3tAvVFAkA1AWGxYbFdAXmxsYWBQ DVEhDXt7UVFGR0ZjRXFlZmZlZHdRV0FERkZjRXFlY2JnZmdmZUFkdnZzc2VxRXJXVldWRUFRZmVk d3Z3ZXFFVlZXUwVRjTUZZWutbhN3DK6ZYkgUG60EfWt0Sl5bRhNpfVLzFXRKX1xRpzl7RgdSQRcB wlMVrfsufXB1dVZORnokUdd6rt46ZHV1dUVeckg2Uyw4ZHd1dURecUk3rgpRxwVjdkZbU3V1VXkm UFFQdlBQVV1VHFB1UN8QZjJRJ1ErcyB3VMBzwHT2dFNacE1ScnJKcE1CHHJbcE1BcnN0c3JTS3N0 UFB1QHUgddB18HVVdehR6RBAcHF4UkJBUlFYUlh1glDNUehS/xBGSl9LT0tSS25bWkl2YHcQd/B3 U20ISHseDUCkbB2tDWykpK1Qb29vbECtbKQNbGlpUUFHaXt7e2FgUA1RDVFTcWVjYmdmZ2ZlQWR2 dnNzZXFFc3JXVldWRUFERkdGY2NiZmZnVV1jqxx9a3RKXltGE2l9UoNra3RKX1tIc0kwITzAOX9R jK50dUVeckg2Uyw4ZHd1dUVeckg2rPA4aV5ZHPTwUFFQeVBQVzhVHFBmUR8QIk5AW0JvW05RWU4r TlJgaBVmAGj3UJhQVXVMZlEnUCdMJ03WUNdM103JTfhNuk2qTVwgaLBoUk9CT0NPREB0QHVVX0Jf Q19EUHRQdVlmVlpwTVJyckpwTUJycn5qTXZycltwTUFyc09qTXVyc39wTWVyc+iv2BATUE1McFFQ UHhMS0RMTEtQZmZQUH1NTkRNTU5QUWZNTFNPUUpQZmVSUVJ2dU1MQkFYUFBnaEtASlFKblqfW49b UltKaOivkBBZTE5kIGiwaFJo6K/QEFlFRmRoTk94f37or5AQQUxOZCB+sH5SkH6AflJ+SWdo6FEE 43FtJkjoUXzVe3sepA0ie2wdrWweQHsie6YNbB2tDWxJQUJpf0hQb2xsbGxsb2xsbFFBQmlCR2lY 1357VS1AlFjXfkh7VS1AlHtIe3t7e3t7YWBRDQ0iDSFQDVAhe1FRcUVzcldWV1ZFQURGRmNjRXFl Y2JnZmdmZUFRc1FBREdGRmNFcWVjRmZmZ2ZlQWR2dnNzZXFTgFEgUnh8bHRJX1tGFGl8rWx8bHRJ X1utqEitoFVdBw2uYF59HnhbUkYUaXtSelGeUy51RV5xSDWs0jhkd3V1RV5ySDZTvat7VJysFTRH Ym91dVFPZH9bC1MKN2N3dVBQUVBNr7FVx1UcUHFRIeJCQnHor6jiXWlx6K+oECdcaUBMTF9ATE1N X11qTVhycktwTUdyclJqTVdyc0FwTUYcc1BxQHFScU1wTXFATEdRX01NblBRRFBQUU1LclBBX15R UU1HcVhYV1dQUkdGWF9ZUVJ4Xl9dUQ9dUV0tAHNRc0BBeExQS1EAS1FQSz9LUkstcm0mSHseQKQh DSJsHa1sHUANpg0ibB2tbFBvb2xvbEBsQGxCaWlRQUJpQmlBQmnXXn5711QtlFBCaWlIQL1RQJAN e3t7e9dAbC2U10CUUXt7YWATCOlQUK/gEHtDZVBfQF9nUCJwIHHQcNBxwVDAX8BwwHHkUORxXVRw VHF6VHdbckN6SlZA6K8L4kNlQOiv9hBDQmVUUVBARFFAQMBR8EzgQOBMWFANe3tRIQ17CRMMCOVA WERLb0Dor7AQWUJIb1BYXkNvUOivoBBZQkhvUFhfRG9f6K+340RLb1/or4riXkdvUXt7e3t7UHt7 CVFRQWR3dldlcUVeUkVBc1FBREZjY0VxZWZmZUF3dnZ3ZVGuUs1zYCFRkAZrcXKsOzsVcK5PIAhN exJuVRys51IXKntqUnV1W3MfMKvHVDms8iUCdXVRCjxT7XRmclJ1UFJQAK+xVaBVO1BdUE5R+xBj OEA4Q8hah0KHSYhKiEyHTbdCWVdIV05HUkhcR0pHTHdAd0N3RHhKWk7QWVpkR9BZWmRF6K/Q41la ZF/or9DjWVpkXeiv0ONZWmRY6K/QEDRZWmRW0FlaZFHQWVpkQsdRxlLJVslYxlzHXfZS9lyXVZdZ lk2HUYddXVJUV1hWWVZaR1FHUkdcR11GTVk2STZMKFUnXCZJJk3HX+ZI5k2HS6BYWwZeXmVQU0Zl V1lCW0lPPghIex5ApB0TCBBJUEtAS1JLHRBTUVNKf3BvcFJwX0JPQlJCHbkNHkANpiEduQ1LEF9L HRBTUVNKf3BvcFJwQh29HkANpiEdvQlQb71vvWFgGwMp4QFYEykQbFFOQHVNdkR2WXVVdklKSEpS Vl9dQnVQTlFLdVFFWEJ1UEdWS3VRQVxedVFdTFJedVFRQ1pGdVBKVEZ1UHt7bHtse1F7e3t7ent7 e3t70VENUCENEwwI5FhWQmlV6K+kEFtCaVJIQmlcSEJpUuivuOJBaVzor7ziQWlV6K+44l1pWeiv vOFdaVB7e3t7e3t7ewlRe3t7e3t7e3tRIQ1RdFBBQFdScXB3dkFAUFVyV1ZBQEdGY2JnZkJlQFJ2 U0dRFFHFx5iuw67CmM5Ry1Fo6jEfKgXJNxUIMjTLVQ9crj6ugq6ulK6sqJRRXVF+UcMc7syujK71 9iRiEFFJslFdUVs+UFBSUGRQUFT1VRxQSlB0UJ/pUHCvqOJcaXDor6gQDFtpH3ZRx0imR6ZwqXJU elhMUFFccE1XcnJRcE1WcnNdcE1CcnNLfkJQfkxMVkNCUldWWEBxUXGOMEbQRs9GU0baf3ZRdktf UU9RUlF9XVBcQFxSAFwwXFJcLXV27FFSUHFQbVFXUEh7ex6kDSJsHa0NbB1ADaYNHb0NUG9sb2xC aX+9QL17e3tTQFVsbGFgEykQTk9zREpIR0lHUlZzRHF/UU9KcX9RckV0f1FwR05/UFB7e1F7e3rR 0VANUQ1Qe3tRQURGRmNFcWViZmZlQWR2dnNlcXBGRURWV1ZTQUZjYmZlZHZzUnlLFQytHw4TS0sU DVIfUXSu9MAxt3FBKtTU01I2rtg+aXJ1dXNoPlMgPmlydYDM1OxySFLIreZSwcjH3FBQUlAArt5V oVU7UEZQdlGZEBVUWzhJOEw3dVRCW19aQxlfGUPXXdtf2UDZQttD10VaFFETWjhyN3XJXcdAx0LJ RfZI+nD0dppfmkNdRtBZWmRw0FlaZFzor9DjWVpkTuiv0ONZWmRA6K/Q41laZEjor9AQb1laZHbQ WVpkQtBZWmRQUFlZWlpcW1VcVkBaQlpGEUAaQtZf2ENcJ1wnQChGJ3Imddtax0iWUZZaWQFe7lpR UOiviBBIX0FkW3hfQWT2ULNQvFtTUFtzS0dlQVNX6K+Q43V8ZFfoUWbkU2FWZVXoUTUQQVtPglBY VgdCXkl3eDxxPghIe3sepB0TCBBdUHNAc1JzHURKkHhReOivkBBbXUJkeF9LT0tSSx25DR5Aew2m HbkNS+dzHURKkHhReOivkOVdQmR4Sx29HkB7DaYdvQm0UG+9bKa9pL17b71RQUJpaQ17ew1hYBsD KeEcWBMpEGZcdnF1TXZJdXV2cEZzdVFOXEt1UEhAS3VQdkJzdVFyRU91UEZQTF1PdVBcW0pfR3VR dENHdVFQe3tAbHtAbHtRe3t7e3t7e3vRUQ0he3t7e3t7e3tQDSETDAgQQF1AQWlFQEFpX0hCaUNI QmlQe3t7ewlRDVVGRmNiZ0VWc3J0d3ZQQUBQcXBQQUBQUXJXVkFAR0ZjYmdmQUB3dlODfpLCeH3H J+quixqmroNRyFFqUWlRxq6Srj7kMgIrBsfIBSsdMFzV1lhtdubgZFEqUVZRYFHDrjyuga6oripV VevNro6u9PglI/VRG1EWwuhQUlB2UFBViVUcUHNQfVEoEG8FSiJKyEVTWHNIcxtKF0wXcjFMM3JX QlBVUFZAVUBWVGB/N0snSydy2HOcS5tzgH9YyUaESqlIq0mrSlV/WFzoUoXkTVdyclHoUoXkTVZy c13oUoUQaU1CcnNMS1BLQEtSS31zckRzc3Ivc9tzUnNQekxxS9BytHKkclNAcgBygHJTgHJRckd6 THJzdnV+S+hRshBHc1BQVnR9fkNDQlJwgnFxcnJWVldYcHHoUVUQWVxQekB6UnqOR+hTUhBGXHR1 dVBQX1FPUVJRfVxcAF1RXS1+belRSVBIe0CmDWxArQ1sQGxAbECtvQ1ArWxQb2xAbEBsQL1vbECt bEJpf2y9rWxBQmlRQUJpISINaUFpQUJpDddefnsNXi1AlEh7e3thYBMpEHB3fERKRXVJdnh1fER6 f1F3Snp/UXtGfX9ReUh2f1BKS0Bse3tRe3t7e3vR0VANUQ0NEwwI6VB4r6gQW1xpe1hcaUxIQ0Vu UXtQe3sJUQ1QDVFBREZGY0VxZWJmZmVBZHZ2c2VxYkZGRURXVldRRkdGR0VxUVNBY2JmZmVkdnNS cEsUDa0aDhNLSxQNUiamtMA8FSxRFhBLeWauBa4bCWnb2h/B8VI6rtQ+aXJ1dXNoPlMgPmlydRTn K8Yybk+uZQlGT1N1UjpSya3+Y9U7y8RQUFFQOq+wVHFVO1BpUVEQaUhgB3kncVNWXlFZX1d7VmBI X0d7fV97QHlBf3Jwe3R8Znpmezd52XnZevlk6HrqZENpTVAKUk1RUehRGRBFUApfZk9mUmb5YU1N TgpwTU9wT1FP6FEoEBZOClBKQEpSSvlFeXtfWHZfW19fTFtMX1QmXyZ5y1/1W+VblF9We3lfW1Rz VWVhU3NlRVkfUQ9RP1EvUd9RVVEHUHZAdlJ26FFAEF5CSmsQW11ka19YT1hSWOhRQORPYX5JauhR aeEISHseQKQdtL0NHkB7ph29DbQNUG+9b71BR2kNIVFBQmlpaVBAvA2kvQ1RQL2kvVBAvA2kvVFA vaS9YWBQDSFRDVFDc3Z2c3JWRURHRkdGR0ZHRkVEVHNydnd2c3JWV3NBY0ZGY2JmZWR2dnd+UmVk ZmNiR0ZGY2JmZ1OSW3lNs9Q2J0VNEH/6vgMCrqecECIGYE9KakJ1dXyrwSDVYzjU6fIHvuUSbn/X S0pOXVU7rmz6nz0XfXN/fnEEJTg41vqlSnREeHlSUIizKgFgCgERC9DOD/K0QFwRcG1QUFFQGlBQ VVxVHFBwUPzpUHKvkONISmRy6K+QEGtAQmRwchByAHKQclRgchByUlGNV1esUk1RSHBNQHJyWXBN X3JzT41KSqxOTU9XSnhQcFJAX1hQIFFRUehRehByWF9ZT1lSWW5JQEhRcEgASMBIU0hwQE9RcE8A Ty9PwE9UT+pRelBIUv7jcT4ISHtApqQNIWxADSFsrQ1spA1sUG9sb2ytbFFAvbxQQK17e1FAvbxQ QK1hYFEhDXt7UUFzdnZ3dnNzQURGRmNjRXFlY2JnZmdmZUFzcldWV3NBVVx0cB4Udg81RxNqfa1q fWt0Sl9bMtluB0d2VRyuwS8/cUKrujhkd3V1RV5ySDZURmoBxlE/UFBRUGCvsFX0VRxQflFTEPFI X0lyUkhad3J6cytz3V7ec/9znXOvc1lQUVBSUFNAUUBSQFMgUSBSL0YvR+lemHiIeLh4XlVzRV5A cnBxdnNhcQpyV5JxpXNS9l7mXlJjWFdwTVFyck9wTUhycnpwfk1QcnRBcE1HcnNIR0dRUVBSXDp0 WUBBeHAvT1EPT69PUk8tYGAQYABgIGDwYFVgWF9XT1dSV255eQB6UXotf20mSHseQKQNbB1ArQ1s HUANpg0hbB2tbFBvvW9sQGxAbHt7e3thYBMpEHJxeFlfWnZ2dV51W3VYf1B3eF1zQH9RcnFZd1x/ UF9yXH9Qe3tRQGx7QGx7e3t70dFQDSEiUQ0hIkNxRXNyVlZFQURGRmNiZmZlQWR2d3ZzZXFFc3JW V1ZFQURWVnNyd3Z2ZUFkdnZXYFLscx9rSWcuMD7LHXZNfQJRhUxpHEFdb6SD4DDTPEoQBlUcdXFq JK045iYeM/6IUnkLHl9HdXV+fnADra2/hOJ/EJj5UsglaXJRUFBRUECvsVXiVRxQcVFa6VBzr5AQ akp0ZIBzUWNUx0VSQHNRaEdRaUc5R/lH6EdURkdHRUhJSUdQVVFNUEldUV1FXk1dXFhbTVxxSXBN cRDor9wQZkdXVnBYUFdAV1JXV31HRURHR0VVVlZ4R0lER0dJRVhXVlRcVUlHSUdFWFVVV3FdXFBS V1ZZc+ivkOd9GWRzR0dKUOpRflBHUdIQQnBcEH0ZZDBcUVxJcnM8cd89SOhRfNV7ex6kDXtKSR2t rUgeFTUUtntQb2xvbGxsQkdpUUJpaUFHadcdfnteLUCUVdd+SHteLUANlHtKSFBAvVFAkFBAvVFA kFBAvVFAkA1QQL1RQJDXQF5s10BebGFgUCEiUSINIXtRRVZXVldRc1F2dndlcUVzcldWRURGR1FR ZmZlZHZ3dnNlVeIaanoDrn1xrn8EaR9S2kYIcEdAflFxUVxgRnBPexdVHHVcE2Lpq6RUZpMUWXV1 Rl9NQmE7rQ1SCT0aSk5+XEF1UFFQQq+xV75VHFBhUaMQ499ZqHlSGUg5SflI6EiYSblJuXlXaUhR V3xHUHVQZlAfYg9iAGM7UFhfYkBjEGMAYyBj0GPAY/Bj4GNZklGfYrNQo1CvYlUjWSNJJHjVWdNJ 8FD3ReBQk1BZSEl5UHd4f2NpUBlwFmEiUCJRWVBAS0Bv0FBRWUlJV1lZWklJSEpKWFtQS1BSULVU UU1QUEFAQVJBR0JNQXB4cU1wUEBRQFxfTUBPSk5NT2F6YE1hEFR5VFBb6K/U40hbWnDorysQOXlY V3BKUFhAWFJYWH15eER5eXhcUFtAW1JbW31IR0RISEdZWllYWnhISURISElWV1d4eXpEeXl6R1xb WlRAeEpJWVhXVkhWBXpRenl6eXhKSUhHXFlWWlthcE9BQFBSW1pYV1ljR0dKUBFaUe1QcFB5UmxQ EFBIUm9QcFBAr5DmQEFkQEliY+hSN+Nx3z1I6FF81Xt7HqR7SkkdrUpIrUpJrUgeFTUUtlBvbGxs b2xsbGxsQkdpUUJpImlBR2lCR2nXHX57Xi1AlFXXfkh7WC1AlFXXfkh7Xi1ADZRV135Ie14tQA2U e3tQQUJpUUFpSkhQQL1RQJBQQL1RQJBQQL1RQJANUEC9UUCQUEC9UUCQDVBAvVFApQ3XQFhsWC2U 10BsUQ17YWBRDQ0NISFQIiENUUVWVldWV1FzUVFzUXZ2d2VxRVZWRURHUUN3flJzZXFFVldWVkVE R0NDZmZlZHZ3ZVe+dmREVmmuB3eu4K7eda4SFGYQUhwXf2FRWoVofmIRb1LBFU5FSH2njXNAaB9V HHVTdHVc36vxUzqsxlQD9xZWdXVSd012K60+UlLAJh9ydXVRWldxRUcmrS5SFQoSTHl/UnVQUVBe UFBV6VUcUG9RwRCXQhldGEAZThpP11GpbVZ5Z3loGlE3UTZ+KnAqcSh/xnz5cOdS6XDvcep+6mDq b6ARQURARE5JYFNfUVl3X39PUUtUT39WYH9RYU5PcF5hTl9wXm9AUH9Rb0BWXldNVklOSk1JwHdR d394TXdpb2pNaVVRVE1VUEhRSEBHTUh2cHVNdmhhZ01oYE9fUFRVYE9fUFR2SW9AQHhOYUROTmFR f9xeUX9ucF5EcHBeb2F/cE5AXlFYVW9hf3BOQF5RWHZJEUdHSlUPae5Se1BQUdJQdlJ7UE9SexBf SUkQaWh3dlJJSFZVWBAR6FGF43HfPUjoUXrVe3tQb2xsbG9sbGxRHkCkHaSkraSkHhU1FLZQQUJH aVFCR2nXXh1+ew0tQJTXXn5Iey1AlFBBQkdpUUJHaUhQQL1RQJBQQL1RQJBQQL1RQJANUEC9UUCQ UEC9UUCQUEC9UUCQUQ1QQL1RQJBQQL1RQJBfX19fYWBRDQ0NUA0TDAgQRE9ASV9vXkBJX29eeF5D b1FwQkhvUXt7e3sJUVFGRkdFcWVmZmVkd3Z3U1dWRURGR0ZjRXFlZmdmZ1FRdnd2dndlcUVzclZF REdHQ2dmZWR2dnNlcUVWVldWV1MxUSYNH2atOx9+V15olp8NYH9FEa2nCWMTKFFdrvcFXEtkflLx cmp+VxX43z5Pam1Ro2sYeUo4U0uthdprVnV1VnRKQl5OAlF1rSN5TWJbVnV1XXN+wlEYUastXnFM V3V1dUxGQDivUP/XZkt+SnV1UUt1SC1QUFFQQlBQVeBVHFB9UQvpUHSvuONEcW9z6K+gEPhdaU91 fEd8SHp0e3VVREhESU90OnZU2nb1VfJ05lXoSOZ06Hbgf7d0WWlJFnMQfzdONHMncyZ0KXdYdVR0 VXR2dnx2fWZQZlFiVFhFdHtIIH9TUFVRTVBGcE1eHHJ7TVFNdE5NTVdwTV0cc0BMUUxIS01MQH1R fXZ8TX10dV91UXV9R0hER3V2R0h2dXV4VlVEVnV0VlV1dVZHUH19TU1MUl1eWGB2UXboUWbjEFVR VehSXRBZVnQkT0gfSFJI6FF2EEVHVldHX1dPV1JXblBGEEYgRuBGVEbqUrhQf6+QEF1fQmSwf1F+ fzxx3z1Ie3sNe6YNvQ1sQGxApA29QKQNvQ1Qb2xvbEBsQGxRSUFCaX/XWH5Ie14tQJTXWH5Iew1e LUCUSFBAvVFAkA1QQL1RQJANe0C9UUCQDXtAvVFAkGFgUSENDQ0NUA17e1FFVldWV1FBREZGY2NF cWVjYmdmZ2ZlQVF2dndlcUVzclZFREdDQ2ZlZHd2d2VV4BN0YjyuikYRZhytVxdsc0pfW66RDx4R UtpNa38ApaQLSnILVRx1WU56665Frug5Y3d1dUVeckg2UUBSFfxtUXV1ckN0wa5vUcnGYUtCSVV1 UFBRUHFQUFViVRxQRFCwEFtRQEJOb1B2QkhvRuivkBAzQk5kXVFbVVBbTVFBW1X/VflW90CkWVQw ViZW11XVVsVVxVb3VflA5lXgVuxA60FcV1hCQ1tDXFFYUltQUVFSQUxvUX1aW0RaWltRUltcP0ZR RkdHShBYAFgwWCBY0FhVWAdQ6FKMEEpEWOBYUVhaUFx4RERQUlJ4WlhED0PTWklFRupRA1BxUWTh PUh7ex6kHaS0UG+9b2xAvUFCaQ1/UUCupA0eFTUUtiFQQGxAbNdVHX57e9ctlFBBQmlBQmlRQJlA mWFgUA1RDQ17e3tRUXFiZ2ZmZ2NTcVFzcldeUldzQ1SyrLNRUucZJ/xxd2erdlNOmSV1FisBR3V1 VRyrUEd0kfKuRlVSV10d0DJR3VBQUVCGrtpSOFUcUEBQOu1S4FBBUFFSw1BCUsIQT0FY6mRSLHJZ 6mRALHNSUVJAUEJYWRBbXWRfWU9ZUlnoUqIQX1BQUFFRUFFAUTBRIFFUUexR8lBBUfRR3FBIex5A pA0hbB1ArQ17bFBvbG9se3thYFEWFBYUGRRDQXFFc3JWVkVBREdGRmNjRYZRwn0SfUdUWWEYfa7a VpJ6S2U1qqUwXnRydFBRUFKvsVJvVTtQU1BoEExTUlFRb1BTRFBQU1FQUVJTW1P/UnxVUf9QfFTs 6VNbUEh7QKS9QKStUG9sb2zXVX571y2UYWBDY1FzUi5R79FVO6omUFBRUBOu2lGFVRxQQFAFEERY 6mRSLHJZ6mRALHNSUUJAUFJZWOivkBBZW11kUFhAWFJY6FKiEF5QX1FRX1FPUT9RL1FUUexR8lBC UP1R3VBIe0CmDSFsrQ17bFBvbG9se3thYFFBcWVjYmZmZUFkd3Z2c3NlUYWuPn0SfUdUWWEYfVUc qW52SmY0VVwwXnNzeFBRUMNSylREVThQVlAhEEMZVQlVOVVTuFG2UlJSUVNUVlBV6K+Q5091ZFX/ UVRQ6FEt41FU/1PoU3EQXF9ST1J/Um9SVFIGUehTcRBDVv9wUBBQAFDAUI9QVVBJVyrKSHseQKQN Hb2kpg2kvVB/rGxAvXtAbEBsQGxhYFENUA1DUWNRc1FRw1HLAlHEz66Jro5SylKerWJSUK5QUFBR r72uFlRDrplQU1BKEFxQb1NRSlVQSVQaFUh7HkC0QLZQfx29YWBTcUVxQ1R2q4qumdNQUVB2VE9R l1UqUFNQaRBcX1JRUVBSX1BPUFJQ6FEW5i9TUVNSKFHoURTjUElUAulR3VBIex5ApB2ttFB/Db0N bEBsYWBRDUNxQ3N2UX0kBVUqrvVQUlAMr6NTjlOTUGFQbFJrEEVWQEBpVHBAaWIQbBRk22XDV8tl U27or5AQMRtl5mlRLlf2ffxs532WfYhxh32IZbZ9WWVXFVcaQxpHGWUIRzZYxVDLZfVR5lHmWFxj V1HQbslUyn3MYVRQbgBuM0YwbiJHxkX/UfVq71GwblpYRgBuJGtTGFhSRUJFUmvor5AQlEdpv2tR YmNYWVhXe3x4e3x1e3x5bGP7Y+tjU1RjbWMdYy1j3WPPY/1j7WOeY41jvWNbIGNRY2tEWHFYNVgl WFRSWGtYHFgqWNlYz1j2WJhYiVhZW1hLWCBYU0RCWFNIXXZPe3t8eXk2f2sYUmLHUA1/f1JIEHl7 ZF9IT0gPSD9Iz0j/SO9IV49IvEisSFNISBBeQGRIUk9XUltffE98f3xvfFR8FHkTX3VPdVJ1ulBQ f1lvWS9Z71lUcFkvWVJQWUBZUlnoUesQQBBu0G5SEG4wblJu+EVRRUvor5AQeAB4b69LUUt7UGdA Z1JnYlUQc3VkP1WgVVJgVRBVAFUwVVRVSW1oBUjoUWHVex5ApA0hex29IaQhe5ENQA0hpA0NImxA rQ2mtA1Qb29CaXt/DSF7QGxApL1AvUCtpLRAvUFHaQ0hIkJpDSEiQWlpUUFCaWlAmVhAbF5sbFAN e1EiYWATKRBiaGpMc1pAU1RfdU12cXVbdml2Xk5BTlBccFlOUXJzalNnTlBATF1OUVpyXU5RaFRr TlBQe3t7UXtAbHt7e3t7e3vR0dHRUSIhDVAiIQ1RIXtQIXt7e3VWc3J2ZWRmdWVkdnZzcldWRURH RkVEVnNydmVkZmZjYkZHRkVBREZGY2JnR1ZWc3J2d0FWV1ZFREdGY2JSGfvYADroUWVHEHgRekpM dhlrbwUinD7Vy0deWkRdSktOYjsUAApaKWt3cUl9YtrHOR87+94OOmd5TUJIRU97eGEVHGMY0xYh EnrHrsUQcUB1SBoTG8VRaRcBZmd+c0tQUlB7r7RUS1UcUEdQd1EBEF9CFlhQR0BHUlFISUF0T0fo Ub4QS3N21FNXTnZbW14iX19AW0dQUEByUXIQV0pCeeivkOIbZXnor5AQaGttZAB5gHlSYHkQeQB5 IHnweeB5kHlXeV5eUF9JT0lSSXpBQhBAUWBAEEAAQJBAgEBVQEl4HiFIe0CmDSETDAjpUECvkONJ cW9A6K+Q40hwb0Dor5DiR09ve3t7CWytDWxpf0ANInt7EwwI6VB5r5DjSXFveeivkONIcG956K+Q 4kdPb3t7ewmmvQ1Qb2xvbEC0b71vvXtTXkBsbFENYWATKRBiSnVUXVV1dHZLSkxKUlZZdnB1dVRy d1FNXElOUF1eT1pyd1FzVnZ3UUpdTk5QcVhOd1BQe3t7UXtAbHt7e3t6e3vR0RMIEHMtVSBZIHAv dMZY91X2WOdUWNJY1VlSL1QvWi9PL3XGVcd0VlENUCENCVFBZmNiRkZFRFZWc3J2d1dzQWR3dnZ3 ZVFBREdGRmNiZmZlZHd2c3JR/ybcMPowKpzTHCZpy3JXWntjUdRWWhxrYxlhZncSBlUcra0qIYDY yarTYGY1VPUBQ0xLUnWt9K4wL3NrGWr8sIcAalBQUVAer7RTD1OTUHNQoRA9pVZRdFlRCVn2TpVS lXOIUbpRslJXWlhRfFJ6RAdPNlk3TyZZJloiTsdD/EP8ROhS6kTmTupzlU6fdUFQUUVDUFNeTIBQ sFBSUIBRsFFSVFFEUVJRcUNFSElIoEFRQbtIdltXcRhUW19eUV57UeivkONiSW9R6K+QEEtZQWRf UVHwUeBRUlFK/3W/dVJ1X0xPTFJMYlfor5DjYklvV+ivkOZ4e2SAV1FX6K+QEFlcXmRXSXRo3kh7 HkCkew17ex29DR5ADaYNIXt7HbQiUG+9b729IUBsQWlpQWkNIWkhUUFCR2lAmWFgUQ1QIQ1RIiF1 R1ZWc3JSZWRnZmNiRkVEVnNydnd2d3ZzcldWRURGR0ZjYmZTEE8SlT/rsDYriMH7FWhrHVlWR0dP YHJkBBlnG2EIoUgsKVFKlu/B/8IKaRQeNG9JSWMdz9Sha3t+UFBSUB+vtFQVVRxQTlB9USoQc8hd +F3pXedGVEJCZ1hQTkBOUkdPfVlYSPJPTpVzX1dPV1JX6FG+5FHyVk9X6FEL51h71FxcWFtP6FEP EElHKXF2RFdQTlBQUFhAWFJYelBIQEhSSHpR6K+QEF5iSW9fUR9RUuBRUVFKf+ivkOIbZX/or5Dj a21kf+ivkBBEXF5kAH+Af1Igf/B/Un9PdlF2EEDor5AQRWJJb19AUWBAEEAAQIBAVEBJfmjRSHse QKQNIXsdvQ0eQA0ie3t7pg0hex29Db0NbFBvbG+9pL1vbEC9QKW9rFGlDXtTXkBsbGxsUQ1hYBMp EHhyel1DdHVzdVJWQnZ4d3l3UlZedXJDdndQel12d1B1QXF3UXdfe3dQUHt7UXt7e3p7etHREwgQ fyBdIEMgciB64H+Qf1YgXi9CJkcvcyB5K33WR9p9yF3HRst89kb7fOp8XtBf2UFSUCENUQ0JEwwI 6VB/r5DjSXFvf+ivkONIcG9/6K+Q4kdPb1F7e3sJUA1RQURHRkZHRVVlVlZzcnd2ZWRmZmNiRkdB ZHd2dnNlQ3ZzcldWVkVERkdGY2JnU4JWWH1oriUXPxbjOAQ45TgTOGtZXGAS1xo7dUh1f2R9R3gI HlUcq5w9RHFwVHEdxAZu8NLtx78qZBFRSjtGTUx6rdbeRE/M8eH6dkPaUFJQH6+0Uw1Tk1BFUHBR ZRAIVkIbRA1EP0Q4RTVIKURXdVr3UpZSmUGBUoFTiF2IRaNTqF1aL0VRchBDRWQGUzZTP3InUy9y 01PWXrpduEVZelivRlFYWVl7UFhAWHBYU1gNVXBGUFEWRuhReORLdkNXVehRTuNcW1lG6K+QEFti SW9GEElyZEY5UOivkOZiSW9fUFFQ6K+Q41teZFDor5AQSEFlUEp/cm9yD3K/clRycHlfUU9RUlFi QOivkONiSW9A6K+Q405Cb0Dor5DjdmBkQOivkBBcXF5kgEBRQElxaN5Iex5ApA17e3t7Ha0NtB5A DaZ7eyF7Hb17e2xQb71vvaStbEBsQKQNtFFAmSFhYBMpEE5BTk11SEdJR1JWTEJPTlBKREZOUU5B S05RR0VLTlFQe3tRe3t6e9FRDXtQIQ1RIVFxRkdGY2JmZ0dWVnNyd3ZlZEJjYkZXZHZ3dnNyV1ZF RVMNra9ZChUxbDJochzoKYA7Bq363oG+c3VFc2Rxa1Gl6jwDEwdGy9Hw0e+6UUW58vEoT0JjCctz UFFQElBQUxJVO1B9UXsQDBB/UVZDT3RSX1ZQV09WQFdUentQUVF5QUBdXFxCUF1ee0BfXHRPV5Vy UXRPVpVzX0tPS29LU/9LUUtidtJFUX1e03x7QF9WV1ZafxBHXm9ff09/j39Tf0dHSlFI6K+QEGBJ S2RITnlyEElLZHLAeX+Kj31RfYZQUHl5X1FPUVJRelyAX1FfhoBeUV6GXV1CeVzor5DjR15vXOiv kBB/eWJkcFyAXFJQXHBcYFzQXMBc8FxWUFxAXDBcwFzwXIBcoFxXXElwf2B/Un5/mnHqUTRRVlBI e3shHqQNISJ7ex20bEC0IbQhQK0NtGxAtCG2QKZ7pJF7HkAVNRS2DXtQb2xvbGxsHa1sb729DSF7 e0BebGxAbGxXQF5sbGxXQF5sbGxRDWFgUA1RDVFBREdGZ0VxZW5SZUFzZWNld2RmY2JGRURWc3J2 ZWRnZmVkd3ZzclZFR0VjRVGPRHAGrYlvZUTY2FGD5CsnGm1kbVZUXEBHTXdS2lMVrScOSHVTdHRR S2AcUtkyFX/AkAxofRJmcVlMQV9FWl9gZf8nMlBQU1AdrhZTi1OTUGBQbVAcUfQQAXVAW19vfHXX Wdh9w3nlVOlZ4nnmfqB0pRRaWmNZZVZpVmtwHlVYdUh1eVl5T2hPGE/cWNV6y1n3ffcTWxAYdBJx XXlIQFBTald0RG55XX9cbuivkBBKTkJvbhBCaW4QdndkbhBOT2RuEEVIZGBuUW7or5DjQkhkbuhT VBBFREQQQ0VkRE1nx1xcTX9SUxB/YWRT6FNMEFxRUHthx39XFXZNXxjor5DjW0JvGOivkBBaW19v cBhRGBhIauivgBBFYklvXWpRamJIIldSUSJPV1F/V1FX6FNWEHl8EhBbQm8SEFtfb38SUV8STxJS EhhxQBBbQm9AEFtfb39AUV9AT0BSQOhTVRBEdmRgYklvUmRRX2RPZFJkEHF2e3zor5AQT2JJb3wQ eHlkfBBzdWRffD9833xTAHyAfFJ8Jx1oBUh7QKYNIXt7e7RsvQ0he0C9DQ17e0C9DQ17e0CtDSGs bEC0vSF7QL0Ne3tQb71vvaRsrXtsQUJpf71CaXt/vXsNe3t7e3tBQmlpQUJpUUFCaWlBQmlpQUJp QWlhYFANUSENUHtRcUVzRkdGRURWVnNyd3JWRURGY2diR0ZFRFZXVnNydnZlZGZndmVkZmd2dmVk ZmNiV3JWRURGY2JmZWR3dlNyV1ZFREZjYmZlZHd2dlLNUWvjYUNIP+8aViJ9bWdu/YIfITgF0fgu gAoVDtI6I9YosOANGmoAH2ZsAH1wJTZxaSbz289fSz1TzD5heGZrNMMDVWt5dH5SfhDVBdtxYWEH YH4ZSRAiFdJgYfA52ZluJejFPz7P4xFgq6FBT2VjAxoTSUFORlBQUVAWUFBUaFUcUHxRj+lQVq+g 4ltpfuivkBB/G2VkVRZSUgB+gH5SV1VVVkZWdlZUX11QclB8T11AckB8VkL/Xu9eUktRUEN0T17o UosQQXJ3dE9yc3JZdE9dc3NMdE9x6FKKEDNzeHRPfHNzUUtyUHxQSDZUV3JxcV5eXVpYT1lRWXpE QxBxEW9DEBUXZEMQbWVDEBNlQxBpamRDEGBhZEMQd3hkQxB7fWRDEHJ0ZEMQTk9kQxBAQWSfQ1Ff Q1FwQ59DUkBDUUPoUesQQpB+UU9+4H5Sf34gflJ+EG5lfuivkONpamR+6K+Q42BhZH7or5Djd3hk fuivkONOT2R+6K+Q43x+ZH7or5AQXkNFZH5QX0xPTFJMenh36K+QEF5xEW+gd1F/d5B3gHdTd+iv kONnamR36K+Q439hZHfor5DjcnRkd+ivkBBZTXFkd0l9HtFIex5ApHt7e3sNIXtsHa0NbEB7e3t7 e3t7DSEipA0NISJ7e3t7e3t7e3t7e2ytDWxQb2xAbEBsb71vbEFpaXt7e3t7U0BebGxRDRMMCOlQ ca+Q40Jbb3Hor5AQWURcb14QRFxvceivkBBDRl1vXhBHXm9eEElfb14QS0BvXuivkOJxRG97e3t7 e3t7ewlRDWFgUQ0iUA1Re1B7UUFmZmNiRkZFQURGR0VxZWZnZmVBZHZ2c3JWV0FER0ZHRXFlZmdm ZUFkdndlUZMd0BUILXl4ba52YklCQntLeBx8X0NrrnZrSUF3blUcrbMBEzTX8K7DO2VXdHRXcUo1 UfEka3FnFa5bNElyWHR0VnBGO1PmOmRYdVBSUHpQUFJzVTxQW1BMUIsQRk7QQUdvX0FQQlBMT0FA QkBMVkd0T0LoUb7kcl10T0HoUb7kc0h0T0zrUb5Qc1BWr5AQQWRmZP9WUVYQUFFcTFZCQVpZ6K+Q EExkZmRQWUBZUlkQU3lcXF9dT11SXXpIRxBBR29H6K+Q4mplR+ivkONwc2RH6K+Q40NHZEfor5AQ f31gZOBHUd9HUVBHQEdSRysQTgBOUk9OME7wTuBOVH9Ob07fTuBOkE6wTlZNHpBIe0ANISKmDQ0h e3t7e3tsrQ1sQKS9DXtQb2xvbG+9DXt7e3tRDWFgUXtRYkZFRFZzcnZlZGZDQURGR0VxZWZnZmVB ZHZ3ZVF2EQoLEBAKCpx+E65Xbk5EfhJVPAsQEAoKEBALrmutSzNnVHR0UnJHM1JyM2dUdVBSr5eu FlGtVTtQW1BhUI3pUECvoBBORkhkUGNRNmA2YSRgJGHaRNJg0mHgYOBhkGOwY1tj6K+QEFxeQWRQ YUBhUnx0T2HoUb4QXnNIunLHQl9hXFb/VlFW6K+Q52RmZFYQUFFF6FNTEERQS0BLcEtgSxBLAEsw SyBL0EtZS+hTV+N2e3tZ6K+QEEdkZmRQWUBZUlkQU3lcXF9dT11SXbp8e+ivkBBBXkBkUHtR73uw e1JQe0B7UnvsUoZQYlK1UVZQSHtApg0NIXtsrQ1sQKS9DXtAtK4hvVBvvXsNb2xvvb17UQ1hYFF7 DSFQe1FiRkVEVnNydmVkZkNBRFdWVnNydmVkZmNiRkVEV1ZFREdGY2JmZWR3dnd3QWdkdndlUTQQ CQpvbwoJnEFJxSorJW15dnxRUkBASUdxVlpRU1F7FVU7CW8QCgoQbwmubKxo2BEOIjQXfBF9fVxA RVhzQUF4dURtP0e9UhJkb39XdVBRUBRQUFTWVRxQflH2EOZScEVp6VLtXohSuVKqXVVNWUpbdkxy cnJzZ0wFXTRdI10nQdBd3UvBXcZfxkD5SuJd5F+IQLhARFJfU0BZSkpCeEJVUHRQfkB0QH5gc1Vf X0BNTUxOTl5RUVJOTl5PWl5bT1pGTEdPRnl0T3RzcllSWE9ZRUBET0VPdE9zc3N6dE9+c3NTVZFS UVJRkF5RURZOXkROTl5AX18OTUxETU1MX11OTUxAX15SUVhgT1B+UFpZVl4iX+hRTuJNC07oUXgQ SHR0c0ZFWo9gv2BSL2BRYEdHSkUUWlGKWehRION5WlFa6FH/4l4iQOpRXlBfUU4QRkwAX01PTVJN J05OT19QT1BSUHp6ennor5AQQE1xZH95kHmAebB5VHlJf2DsUVNQcVAeUbRQSHt7HqQNe2wdQK0N bGxApg20rbSkpA2ttkCkHhU1FLYhDVBvbGxsSR1ApKRIrbRvbG9sUUFCR2lY1357Xi1AlFTXfkh7 DV4tQJQNUEFpSHt7QL1RQJBQQL1RQJB7QL1RQJBQQL1RQJBAWGxYbNdAWGxYbFENYWBRIQ1QDXtR QWdmZmVkdndlcUVWVldXQ0ZHRkdFcWViZmVkd1NXRURGR0VxZWZnZmVBZHZ3ZVGRiRNxfBBR82wK 0zaM1UlyZK5NcE166Wx4bq5Na0lBd25VHKzUhRFqS0t0WHV1U2PQNK7ulEhyVHR0SF5HblFfa/g7 ZVd0dFZwRjtT5jpkWHVQUFFQe1BQUnRVHFBAUJAQTELQQUdvMEJR4EJRX1VQVlBAT1VAVkBAVlt0 T1boUb7kclF0T1XoUb7kc1x0T0DoUb4QRnNQQFBWVVpQX1FPUVJRelxbEEFHb1vor5DiamVb6K+Q 431kZFvor5DjcHNkW+ivkBBzQ0dk4FtR31tRUFtAW1JbK09C8ELgQlN/Qm9C30KQQrBCVULor5Dj YWRkQuivkOZ9fmRBHpBIe0B7ew0hpg0NIXt7e3t7bK0NbFBvbG9se3t7UQ1hYFENIXtRQURGR0Vx ZWZnZmVBZHZ3ZVHjfhOuV25ORH4SVRyrJjNnVHR0UnJHM1OYMmdUdVBQUVAcUFBWJVOTUBZSHhBP F1JRQkJPEFpOZ1hfQ1BsUBZPQ0BsQBZWUWZnSXRPROhSh+RyfXRPeOhShxBEchF0T2xzcl90T0Nz cxB3UXJ0T3foUojncxBrUWd0T2voUogQenMSdE8Wc3NXcn1mcVdRVE5sYjZUTjZaWlRXUBZWbGt4 d0RDWhgQYklvGOivkBAFTnJkUBjwGOAYkBhUGEdHSl5fX09fUl96SkkQbWVJEHt9ZM9J70mfSVMQ Sd9JUkm5cXJ6fn0QbWV9EHt9ZM99732ffVMQfd99Un25UF9nT2dSZ3oSEeivkBBKTXJkMBGwEVLw EeARkBFTfxGQEYARUxFJFxjoUgPjcR7RSHt7HqQNISJ7bB2tDWymDSF7e2ytbKYNIXt7bK0NbB4V NRS2IXt7UG9sbGxsbG9sb2wdQL1AvUFCR2lRQUJpe3tRDXtRDXt7e3tTQF5sbFENYWATKRB0f2FL TVtdVVZgdkx2YVV+TlFWV01bSk5RXF1/VmJOUUtcTk5RUHt7UUBse0Bse3t70dHR0VAZBCkQQk9w WFlwWE53VU9ZcXdQcHFYV1FAbEBse1B70dETCBB0MBiwGFJWXHRcZFwQGIZbVR9VH1geWR9bkBhV aFIfVh9cqlZUUA1RDSEiCRMMCOlQGK+Q40ZNbxjor5DjQEVvVuivqONEXG9W6K+o40Jbb1zor6Dj QltvXOivoONBXW9W6K+o40Fdb1zor6DjX1tvVuivqONfW29c6K+g40Bcb1bor6jjQFxvXOivoOFb aVB7e3t7e3t7e3t7UXt7CVANUUVmZmNiRkdmZmNiRkZFQURGR0VxZWZnZmVBZHZ2c3JWV0FER0ZH RXFlblJlQWR2dnNyV1ZXQURGR0VxZWZnZmVBZHZ3ZVGZHdMeCipxAMMAMSN9d26uTWlLQkR7TXsI fUFHEa5Md31fRH9LeHF/ZXdurk5rSUF3blP3KwQTBAYKAAnZxq7RPGRYdHRVd0sxUcItFHFvb65a NUp1VHR0UnNhAlHCLxB0RU8brlozb1Z0dFZwRjxSQDpkWHVQUVAWUFBUZ1OTUHtSVOlQVq+45Vtp WVZRfeivkBBoG2UAfVFVVVVWdVZTiVKGU4VKU0VWZVUWUlOGUY9LUkJfXlBxUHtPXkBxQHv/X+9f WFFLTER0T1/oUosQQXJ2dE9xc3JadE9ec3NMdE9w6FKKEEVzd3RPe3NzcXBwX19eWkk2VVNUV0vo UQ/jgFFRUeiv5RAGSGVRKVBQe1ZaT1lRWXpFRUQQcRFvRBBtZV9EUXBEn0RSRBAVF2REEBNlRBBp amREEGVmZEQQYGFkRBB7fWREEHd4ZEQQcnRkRBBOT2REEEBBZEBEUUToUesQX0994H1Sf30gfVJ9 EG5lfeivkONpamR96K+Q42VmZH3or5DjYGFkfeivkON8fmR96K+Q43d4ZH3or5DjTk9kfeivkBBf Q0VkfUxfUE9QUlB6d3d26K+QEF5xEW+gdlF/dpB2gHZTduivkONnamR26K+Q439hZHbor5AQWU10 ZHZJfB7RSHseQKR7e3sNIXtsHUCtDWxAe3t7e3t7e3sNIaQNe3t7e3t7e3t7ew0he3tsQK0NbFBv bECkeyG9b2xsvW9sQGxAbHt7e3t7U0BebGxRDRMMCOlQcK+Q40Jbb3Dor5AQWURcb18QRFxvcOiv kBBDRl1vXxBHXm9fEElfb18QS0BvX+ivkOJxRG97e3t7e3t7ewlhYFAiDVEhUQ0ie1Ahe1FFZmZj YkZHRkVBREZHRXFlZmdmZUFkdnZzcldBREZHRXFlZmdmZUFkdndlUZMY1BwLKERAd26ud2VHQEJ7 SgYad2Wud2tJQXduU/cpHhc1G2nyrsQ8ZVd0dFd1STNR8CNscSuuWzloV3R0VnBGPFJAOmRYdVBQ UlAar7RT51OTUF1QcVEEEEiXSlF3XFFCB1hedl1RUFdHdldZWFtNEFTor5AQXmJJb1QQdntkX1RR VEpz6K+Q4htlc+ivkOIXZXPor5Dib2Vz6K+Q42ltZHPor5AQdHh7ZJBzgHNSUHMQczBzkHOAc1UQ c89zUnNfQk9CUkIQgFtRW+ivkONiSW9b6K+Q43Z7ZFvor5DmXF5kW0lyc+iv0OR3ZWghSHt7HkCk e3t7DR29DR5ADSEie3t7e3umIXt7Hb1Qb2xsvW9sbL1hYBMpEBRRcUB1UnVPTnBOUlZEQ0VDUlZW dktMSkxJTFNWX11Cd1BxUU1OUUZZQk5QSFdNd1FBXF53UU5TXk5RQ1pHTlBMVUd3UHt7e3tRe3t7 e3p7enp7e9ETCBBheFFpURlRGUApXFUgVi9cL0AgSdBW31zfQNBJmFKWT1ovVyBdIF8vSN9X0F3Q X99IWFENUA0hCVEhDVFiRkZFRFdWc3JSZWRCR3JWVkVER0ZGY2JnZmdmQWR2d3ZRriqCPTUqh4O0 uZ9jGUdeWxh+fU53XUR2dUpTky642pfW8lF4k5lRexcds5o7DRcaSXJtD1Fx+i9NRVBQUlB3rhpU SlOTUHJQf1EkEElCf1hfVlBXUEFPVkBXQEFWQ39zUFFcdE9X6FG+EFtyUXRPVpVzXXRPQehRvhBL c33UR1dBQlZCQVZ1dk9bVldeQHlReRBLSkJh6K+Q4htlYeivkONrbWRh6K+QEGBDRWQAYYBhUmBh EGEAYSBhVGFCX1FPUVJRel1CEFxRYFwQXABckFyAXFVcSWAeIUh7QKYNIRMMCOlQXK+Q40lxb1zo r5DjSHBvXOivkOJHT297e3sJbK0NbB5ADSJ7e3sTDAjpUGGvkONJcW9h6K+Q40hwb2Hor5DiR09v e3t7CaYdvQ1Qb2xvvW9sb2xvvXt7e1NeQGxsbGxRDWFgEykQcHZ8SE5JdXt2TXZ3dXxIeXdRdk55 d1F6Sn13UXhMdXdQUHt7UXt7e3t7e9HREwgQa3QQbxdkcxBvF2QvSC9OL3YvfFQkRC9JIE0scyB3 L3vVRNxzxkTHSMlOyXLLdPZE+XL6dOZE7HRCFEVRUCENUQ1Qe3sJdUFERkZjRXFlZmdmZUFkdndl cUVmZ2ZjYkZGRURWVnNyd3Z3RmNiZ2ZlZHd2c3JXUf9HYBatu25ORH4SUdhhYxkGN/kIC/06HRNi ZwYyZnNkaXYQNREPrvQYZEh1dVJxRzBTizNnVHUrGHB/0rXU3rsrckr0KmkEvKIJa8JQUFJQHq4a VBpTk1BNUH5RORBEQkIWWF9HUEhPR0BIVE5QTUJ0T0foUb4QdnNNlk9IlXJ0dlxXfNRUW0hHXl8i QEBBV19fQU9PUE1ATVJNekFC6K+QEF5iSW9fQh9CUuBCUUJKYOivkOIbZWDor5Dja21kYOivkBBE XF5kAGCAYFIgYPBgUmBPeFF4EFjor5AQWmJJb19YUYBYUVjor5AQWVxeZFhJf2jRSHseQKR7DSF7 Hb0NHkANInt7e6YNIXtsHa0NbEFCaX9Qb2xAtG9sb71vvXt7U15AbGxRDWFgEykQYnB7VV52dVp2 cXBycFJWenZWdXVbeHdQc11PTlFeX3tVeHdQd1l0d1FwXnROUXlXfHdQUHt7e1F7QGx7e3t7ent7 0dETCBB6IFUgWyB1IHvgYJBgViBWL1ovdiB6K37ZfshRyVXMfvhV/37oVe9+mX5eUA1RDQkTDAjp UGCvkONJcW9g6K+Q40hwb2Dor5DiR09vUXt7ewl1VldWc3J3dmVkZmZjYkZHZ2NBREdGR0VxZWJm ZmVBQWR2d3ZzcldWQURHRmNiZlLpbWUWHOA2ASuHKAAtfc1yQEofrbRuaEVzf0h1HHoSaXdudAsy EEp0zS3+wa/XZmc9qxUMR3VRdXVMfhdR7VHR8Th2QxM3rriHB2tiUFBRUBtQUFM+U5NQeVF3EFpb dltpW0RcQG9b6K+Q43J0ZFvor7fjS09ke+ivkONhZGR76K/Q4k9le+ivkONNTmR76K+Q419AZHvo r5AQd0RGZEB7UcZbwHtSW0ldQWRfTVBOUHlPTUBOQHlWUUVGR0dQcvJPTuhRvuRyR5ZPTehRvuRz c3RPeehRvhBNc1piXxBObG9fEExnb183VVNUV1B5Vk5NWl8NUFrqUQ9QVFEP58BXgFewV1NX6FHq EFtQeV9HT0dSR3pzcuivkOIbZXLor5DjYGRkcuivkONLcGRy6K+QEERCRmSQclEgclFQckByUnKK eh4FSHtApg0NIXt7e3tsrQ2kpA29vUC0UG9sb2xvbGy9e3u9e3t7V15AbGxsUQ1hYFB7UQ0he3t7 e3t7e1B7e1FFZmZjYkZFRFZzcnZ3dnNyV1ZXVkVFR0RHRkZHRXFlZmZlQWR3dnZ3ZVGZDdwRaBMR fmUeV1pdTUp5RXBRV1x/aK5XbXtYWnZgU/eEwQ8VbxMaFFRWRnJvMSWHaGlAS0lTdHRVaSpSVQBG TEpVdVBRUAGvtFKEU5NQYlLXEAxbYEVAb1RAXXlEQE15VFZERkSWdZZ2iUC6QKlAV3lAdXpoQGZ6 11vFc8V0+Vvzc+hb5HNbVVxVXVh5RVwXWxtcVhBbEFxSQmJPUMtST1FREERcb1EQW0Jvz1FRUehR FRBDUMtCfxBbQmR/o3tIT0nLS09KSuivkOZbQm/ASlFK6FE7EHNJy0ajQkJVdntXQk52QltCX1FP UVJREEJFZFELQlBxQHFSceivkBBbW19kUHFAcVJxcl7or5AQfmJJb09eUV5KX2RRf2QfZA9kP2Qv ZP9kVmRCX1hPWFJYEFtfZF9YT1hSWHJKeXjor5DmYklvX3hReOivkBBZXF5keEljaCFIex5ApHsh ex20vQ17IRMMCOVYcEtAb1jor5AQR2JJb1gQRHFvWGxFc29YbEZ1b1gQW0Jve3t7e3t7CR5ADSGm InsdvQ17IRMMCOVxcERcb3Hor7AQWUtAb3EOYklvceivkONEcW9x6K+Q40Vzb3Hor5DjRnVvceiv kOJbQm97e3t7e3t7CbR7IRMMCBBJURB4SG9REExBb1EQQEtvURBeR29REF1Gb3t7e3t7CVBvvRMM COVOTk5fb07or7LjXERvTuivsuNdRm9O6K+y4l5Hb3t7e3sJb70TDAjpUFWv5RBCTl9vVU5cRG9V Tl1Gb1VEXkdve3t7ewlAvKS9DXtRQL2kvVBAvHsTDAgQX38QWkFvfxBZX29/EERcb3t7ewmkvQ17 e1FAvaS9EwwI5XV9TEFvW+ivgONMQW9b6K+wEFlJX291fUdeb1vor4MQWUdeb3V9Rl1vdeivoeNH T2916K+050hwb1xMSXFvUHt7e3t7e3t7ewlQIWFgUCENUQ0NUHtRQ3N2dnNyVkVER0ZURkVEVlZz cnd2c3JXc1NjRkZjYmZlZHZ3dnd2ZWRmY2JHRmNiZmdSxF9ybdMReWpEcFF2DR7eBhMgTltxRnFA cn3NFmBtbDjJfRLF3RwXS0FCRkhTka6R3jhndEtJeZfbBh7GAHpbYlEA1NRremAWFzpoAjM8/3Vf X3NQUVB2r6NSxlStUElQyBBe31vfXFLfW99cUltcUEnoUeYQSVFURERTRdNSUVZwW2BbEFtTWyJZ NV5bUlPoUV4QTVVb5lxKS1FUVFBfVU9VUlV6Q0ZFKUREQxBcRG9D6K+QEEBNcmR/Q5BDgENTQ0lK HgVIex5ApA17e2wdQKRsQK0NbGxAbB5Aph29QKRsUG+ttA1vbK1sbEBsQKRsUUCZYWBRIVAhUUFj RXNBREZGY2JnR1ZzcnZ3dmVBc2VmZmdR6I6OX3ZAEWpOAeYJK0FaKi7hElStrvozre8Bf00zRpAz bXLGUalzCZQpUFBRUG+vtFRhU/dQclHC6VB0r5AQ9htlAHSAdFJZXEtcelwZXFRpXMpM+UzoTFS/ V75YUnIQW11kcRBbXWRfVVBDT1VAQ1SPV1GvV1FRdE9Vc3NfdE9Dc3NOdE9yc3NVVlVaSTVZW1pb UHJyRERDVlBWel9RT1FSUXpOVhAVF2RWEG1lVhATZVYQaWpkVhBgYWRWEHd4ZFYQcnRkVhB7fWRW EE5PZFYQQEFkn1ZRX1ZRcFafVlJQVkBWUlboUesQWnQQcRFvdBBuZXTor5DjaWpkdOivkONgYWR0 6K+Q43x+ZHTor5DiemV06K+Q43d4ZHTor5DjTk9kdOivkBBJQ0VkkHRRT3TgdFJ/dCB0UnRET0VR RXpfXuivkONxEW9e6K+Q42dqZF7or5Djf2FkXuivkOJ6ZV7or5AQQ010ZKBeUX9ekF6AXlNeSXMe 0Uh7HkCkDSF7e3t7e2wdrQ1sQA0hInt7e3t7e3t7e6QNDSEie3t7e3t7e3t7e2ytDb1sUG9sQGxA bG9sbL1vQGx7e3sNIVENYWBRe3tQIQ1RDSJ7UUFERkdFcWVWVnNydnZlQWR2d2VxQURGRmNiZ2Zn QWR2d2VTnHhtrtMT1gMfK3p3blEtQ3lLdE14aHduU/etdDtlV3QtABkx0vJRIzpkWHWt0TRqTkNK H1GkOmRYdVBRUEOvtFO+U/dQTFHUEEpCUlBSUUJQQlFUYE4JRwlIAE7nXLBOoE5XTuiv0OJdZU7o r5AQdkxPZG9GH0YGVlNXXlhPV1RHUUdLSE9HUFZAVlJWUVVPVkZARU9G6K/ZEDpfUExwS0xMFl9A RF9fQFFQUA5fXkRfX15MXlFQVFZAcEZdb0BwRFxvYEAQQFJAS0dfS0BfXlFVTEdGRldXVlZMUFtL p0ApYF8QXwBfU18NXrpREEZdb1EQRFxvcFHwUVJfUU9Rn1FTUQBO6K+Q42wfZE7or5AQS3N3ZE4Q XV9kQE4wTvBOsE5UQE5R4E6gTlJNTuhRU+NxkQVIe3sNISJ7e3ukIQ17e61JpA2kSL1Qb2xvbEBs QGxCR2lRQUJpaQ17e0JHadd+e14tQJTXVX5Ie14tQJR7SFBAvVFAkFBAvVFAkA1QQL1RQJANUEC9 UUCQDWFgUXt7DQ0TDAgQRU4QRl1vThBEXG9SQEFMb1FAQUxvXuivsOJEaV7or7DiRWle6K+o4ltf b1F7e3t7e3t7CVVRdnd2d2VxRXJXVkVER0NDZmVkdndlcUVWVldRUbuulWlwR31RoX9BSHzKK2V9 aVFifGhorphMUoXTc0pZdXVBRk51Nq7xUX/SZk93UnV1VmbUrXJQUFFQQa+0VeJT91B8UgfkQlBB UXzor6gQ90JEZFBTUFRbRltHQFBAU0BUV39Ef0Z/R29Eb0ZvRx9EH0YfRwhVCEIGTj1VNlo0WzhC O0Y7RzRONk8mQCpCLUYsRyNOKXAod99+yHuIVrhQtl66fKhQpVqlW6Zeq3x2VlpWW1ZeVEBVQVRO EH4AfjB+WVFRUkJCQUNDUFpAW09aSE5JT0hUd1F3e3hPd1BZQFlSWVRYT1lHQ3BCRGRDRk9HdnB1 T3YQ6K8m40FTUnDoryMQOU9QfHB7fHwWT3BET09wQ1BZUFZPUlAOT05ET09OVFNZU1FTDkFAREFB QFFSUVBSFkFCREFBQkBUU1JUWXxOQ0JRUFZBW3BRu3CrcFJwe3dPe3BPTkNCQUBUUVp8d3ZIR1pZ VnxTUlBbfuiv0OJ8ZX7or5DjZ2hkfuivkONwcWR+6K+QEEhJSmR+EFteZFB+MH5S/35RfkdHSncl cE/oUX3mEDBBIEFSQetRfVBwUFmvkBBFYklvX1kvWa9ZU2BZEFkAWVNZSX1+6FIG43GRBUjoUXzV e3sepA0he0pJHa0NSkitSkmtSB4VNRS2DSJ7e3t7e1BvbGxsb2xsbGxsQkdpUUFCaWkNIUJHaUFH adcdfntYLUCUVdd+SHshXi1AlFXXfkh7IV4tQJRV135Ie14tQJR7e0pIUEC9UUCQUEC9UUB7kFBA vVFAkA1QQL1RQJANUEC9UUCQUEC9UUCQ10BYbFhsYWBRIQ0Ne1AhEwwI6VBOr7DjW0JvQOivsONb Qm9A6K+oEFpBaUZYRGlHWERpUXt7e3t7CVVRU3NTdnd2d2VxRXJWRURHQ0N3dnZ3ZXFFVlZFREdD Q2ZlZHZ3ZXFFVlZXUVO0r1CrZKlod0ljUYhgdHDZ1FpOfX9Rj2hOTdQoSnZnUUV+ZnuuqkxS/q0C UvbLf3BedXVMQkEFrsNRPUgbeVh1dVNJR0YbrsNRABhKd3RUdXVWZSytSVBQUVB/UFBTj1P3UGpS 8hAbd03JT1JKTEBqUkL3TlFqXShg6WpTQl5ET3ZPJ1LGXsphmVGPbFhAV0BYQEdASFRIR1hXEEde b09XAFegV1NXV1ZJZGV2dUB0UXR06K+Q5ltfb3Rmc1bor5AQ0ENJb8pm6mZSfn1Rf01OT11/TV5P XWpfUH1Ral9XXVhPV0lNSk9JdH11T3RmamdPZupWUVZRVU9WSF9HT0hzT3JPc2V/ZE9lfk5eUFRW fk5eUFRzSc9//H9SDH/cf+x/U39Nx1/8auxqUwxq3GqnX1MHX9dfz2pTTRZfakRfX2p96K+Q42JJ b33or5gQ1kJFZLN9UQN90H38fYN9VH1RQl14QkRkVVFFUXVRIlHUUVXZXZNPp09TBE/TT8NP+E9U 812MXaZdU9tRyVHrUVOJUVFRDl1PRF1dT2oQQnNvX1FfXV9/X2pUT1FPXU9/T2pUan99T01fXVFY Vmp/fU9NX11RWElmZXRzVklIV1Za8GyQbFJs6K+Q519BZGxHR0pW6K+Q5k5fb59WUVbqUV5QUVFO 4n/ATe1RTlB9UidQa1BsUhbjcaIFSHt7pL2mraQNex4VNRS2ew1Qb2xsbG9sbGxCR2lRQUdpISF7 114dfnsNDQ0NDSF7EwwI6VBRr7DjR15vUeivsONHfW9R6K+w40R4b1Hor7DjX05vUeivsOJcRG97 e3t7ewktQJQNDXt7115+SHsNDQ0tQJQNDVBBQkdpUUJHaUhQQL1RQJBQQL1RQJBQQL1RQJBQQL1R QJBRDVBAvVFAkFBAvVFAkFBAvVFAkFBAvVFAkF9fX18Ne2FgUUFCaXstfw1IbGyObEFCaSx/DXtI bI5sUQ0NIVANEwwIEEplexV7UjpQOVs3Tjp+91H8T/xw6U+bXbldWlENIQlRDVANUUNGR0ZHRXFl ZmZlZHd3V1ZXVkVERkZjRXFlYmZnZ1N2dndlcUVXV1ZFREdGR0dnZmVkdndlcUVWVldSPvIEYUt/ radtTXABFX9WWENxfK7CFCE8HfEfHmBSVktkWFVTSRl2AHN9URttOhJSba6c8XtHUnR0VUZDTGzI NRVdQ19HT190dBvPIlF6whJUdXVRQldAX0BXf9hmPnxFTVV1dVIXNlBQUVBBrhZTvVP3UH9RM+Vf XU9dUlzor7AQ/kNFblRRRFEaUBpdGEoJSgpLCH46SjpLOH7ZS+hLmEteeEN4RGhQaEoWUBZdN1Y3 VzdcyH/4UPhKh0ldUFBRXX9dXH9eVlxXT1ZFSUZPRUBVUVVRVE9VRF5DT0R6RXd4dHtef38WSklE SkpJXF1dSF1Gb10OUFFEUF1eUFFRcX9KSV5dXFBXRXd/UHRJXl1cUVVVSnS6e8BOX3S6TkVERFZW VVZKUFswYbBhoGFTYeivkBBdRHhkYUdHSl9Ff0VSRehRUxBHVXl5cHdkdxR3U3eZcXtQVYBVUlVJ YGHoUVPjcZEFSHt7HqQNHaStDbRArQ0eFTUUtnsiUG9sb2xAbEBsHUC9b729QUJHaUFCaVFBQkdp QmnXWH57e14tQJTXXn5Ie14tQJRQQUJpUUFCaUhQQL1RQJBQQL1RQJANUEC9UUCQUEC9UUCQV1hA bFhsYWBRDQ17UA1VUXZ2d2VxRVZWRURHQ0NmZWR2d2VxRVZWV1FSV1ZzcnZlZGZjYkZHRkdGY2Jn ZmdRoq6CFBF+UaFheGLwPWthblFpfmoUrqU1YRU4AzcXZGJtUVFYWF9IS3hmdlLlzRhedXVSckh2 IK7CUUvHa3V8UnV1VW3hrRuurGwEDxNqHBATdltbTXrGUFBRUEVQUFM8U/dQQlG1EFtCUFNGU7lT q1NUXeivuBBZc3VkU3BKTWRd6K+4405wZF3or6AQHElLZGpSGlI4Uy9TJVzaUtxTxl2rU6hdWhtT FlwUXQtTBlzrU5pTV1JAc3VkJVyiUlJ/WH9ZcEFwQgZch1y3XKdcWFtSVFxLUkRcVELor5AQaUFa b1hZQUJBQlBTXF1CNF0kXdRdxF30XeRdll20XaZdWV0OUlNEUlJTUlFTXVBZXERbUl5RUxZbWehT dhBdW1pQQkBCUkJCUVpWQuhTdhB4XRZQUuZQUVpEEGJJb1BEUUQQW15kREdHSltY5llZWgtRUyVb eUJ7UOivkBBARGlQEEJEZG9Qr1BSP1BRUOhSdeJdJVHor5AQWmJJb19RUVFJQ0ToURvjcZEFSHt7 HqQhex2tpA0he3ukpL1ApGxAvR5AFTUUtnshe1BvbB29QL2+b0Jpfw1AbL5AvUFCaVFBQmlBQmlp QmnXfnsiEwwI6VBdr7DjXUZvXeivsONcRG9d6K/q41tCb13or7DjQEVvXeivsONfRG9d6K+w4l5D b3t7e3t7ewnXLZRRQUJpQJlAmVB7YWBQDQ0he1EiIXt7e3tRDRMMCOlQU6+w41lfb1zor6AQWUFM b1JIQUxvXeivvuFHaXt7UHtRewlxcWVRc3JWVldzQXFFUWNiZmdjUxOsglJSxjEEZExzU0OuUhCQ +ntMRlMEcx0zUUBLrOQ+wlBRUPWuMVKAVTtQYVCFEGh0WHRZUnNfa1ljXxtZFV8JWQRfOVk0XylZ J18nRSdL2kvFfvV+QFx1bHR0UEdsSFFsUFNQUVFIR+hRMxBcRFQQW11kX1RPVFJU6FKiEF58fE1X EFtdZF9XT1dSV+hSohBdeHhBEFtdZF9BT0FSQehSohBccUQQW11kX0RPRFJE6FKiEE1xEEFJZHFj TRdc/nVQdEB0cHSwdKB0VXRJYojZSHseQKQNbB29pLR7vQ17QL0Ne2xAvQ17QKS9DXtApGxsQGxQ b71/vUJpf71pYWBQDVENUUVWVkVERkVEVldWV0ZHRkZFRFZFREZHRXNWdnZlZGdmZWR2d2VmZmVk d3ZlZGZmZ2ZSgDQPYAEcZSQsaBoaYQs3czbnDU9HNDAwNEZPHiYWZlU7fUM3EhOXGhTdYnNPd3Zj 2m5smBoXN0R/UTDHFxUoCRYfP0BtQCQDFAUnbhHWBENfUFBRUM+uFlFxVTtQU1BzEEJSUVFTUFU7 UlNvUFBRO1Qqykh7QKZsQK1stlB/bG9sYWBDQWNBz9KuFld1qItQUFFQC64yUtZVPVBhULsQb3lf fEBSdFlkWWxfFFkcXwZZCV82WTlfJ1MmWSlfJ3/ZfsVL9EvnS5dLQlx0bM91UXV1SFFsUEdsSFNR UFBIR+tRM1BEUEGvkBBZW11kUEFAQVJB6FKi43FxeETor5AQWVtdZFBEQERSROhSouNNfHxX6K+Q EFlbXWRQV0BXUlfqUqJQeK+Q5UFJZHhjVOivkBBZW11kUFRAVFJU6FKiEEZ8F1z+dF91T3V/db91 r3VVdUpjP8pIex5Apg1sHb2kvQ17pHu9DXtApL0Ne0BsQL0Ne0CkbGxAbFBvvX+9Qml/Ib1pYWBQ DVENQ2VmZmVkdmVkZmdmZ3Z3dnZlZGZlZHZ3ZWdmRkZFRFdWRURGR0VWVkVER0ZFRFZWV1YLMzBg AB1lJCxoGxphCjdzNegNT0czMTEzRk4dJhZmrjJ+QzcSEpcaFd1icnB3dmPabmyYGRg2RX5RUTDH GBQoCRYfIF9tQCQDFAUnbhLVBENfUFBRUHdR0lQ4UpZQSlAH5VtAQ0dkSuivoORDR2RRUOhTQeJA /1noU07iVFxd6FNBEFlI/1Rc/l1Q/lHor5AQXFlCZFFKTF1JS4AVSHseQLRApnsdvUC9UH+9pGxA rK2kbGFgUHt7UWNWVnNydnd2c3JWV3NmZmNiR0ZHRkdGY2JmVH9pVsk+ZSebwhEUC0FqWMM5ZWM1 4jBjTnMXMVKVz/RyBW0DMPTPXk0cel5YDq+vUEBQUFXgVoxSdlB0UFBRV1DeUdxR1FBxEEBTUvB+ 4H5SfkBzGHtSU1J76lLJUHlRfNVQe1F7DWVlUK+vUEBQUFXgVupSdlB0UFBRV1CXUcpRTVB94lNS Z+ivkONJcmRn6K+Q5FlBZGdA6K+m5xh7UlNSZ1N56FF81VB7UXt7e2VlUK+vUAGuLlUHVTtSdlB2 UFBRV1CYUZlQUFBz5lFQdUB1UnXor5DkXEFkdUXor73mGHtRUXVYeVB7UXt7DWVQr69QeVBQVKpX S1J2UHhQUFFXUN1RBVHxUEvlUUBlUWV66K5E5Bh7UVFj6VLJUHlQe1F7DWVQr69QTa+xVcdWjFJ2 UGFQUFFXUJZR1VHSUEYQWlFQf3VLXhBRUXjpUslQeVB7UXtlr69QAK+xVaBWjFJ2UGJQUFFXUN5R m1HUUHQQRVNSD3hRf3hveD94U3hQGBh7UlNSdelSyVB5UHtRew0hZWWvr1Bgr7BV9FaMUnZQaFBQ UVdQ3lHcUdRQTBBcUlFQFGJ6TxBRUlJl6lLJUHlRfNVQe1F7ZWWvr1AMr6NTjlUqUnZQFFBQUVdQ 3VD6UFBQcOdScBCgEFIQT+ivtOQYe1JRbupSylB5UWHVUHtReyFlr69QDK+jU45VKlJ2UBRQUFFX UBNQ+lBQUHcQXVJuEElLZG4QRUZkbk/or7TkGHtSURDqUspQeVFh1VB7UXt7e2VQr69QDK+jU45V w1J2UBRQUFFXUJVQ+FBQUErjUlEQT+ivvOQ4d1JRbupSylB5UWHVUHtRe6+vUAyvo1OOVQlSdlAU UFBRV1DeUPxQUVBxEEBTUl8WTxZSFk9OGHtSU1IT6lLKUHlRYdVQe1F7DWVlUK+vUAyvo1OOVQxS dlAUUFBRV1CWUPVQUlB0EENSP21RcG0Aba9tU21Pvxh7UlET6lLKUHlRYdVQe1F7DSFlr69QDK+j U45VzVJ2UBRQUFFXUJdQ+lBQUEzkUlNSE0/or7TlGHdSU1IT6lLKUHlRYdVQe1F7r69QHq4uUw9T k1J2UBZQUFFXUJhQ2VBQUHMQX1GPYr9iUs9i/2LvYlNiVOivvOYYe1FRdFh5UHtRew0NZVCvr1Af r7RTDVUqUnZQGFBQUVZQ3SVQUEfiUnRD6K+05Bh7UlFy6VLKUHlQe1F7ZVCvr1Afr7RTDVUqUnZQ GFBQUVdQE1DNUFBQTuFScuivkBBbW11kckNaGHtSUXTpUspQeVB7UXt7Za+vUB+vtFMNVcNSdlAY UFBRVlCVI1BQR+JSdEPor7TkOHtSUXLpUspQeVB7UXtlUK+vUB+vtFMNVQlSdlAYUFBRV1DeUN9Q UVB0EEVTUh96D3pSX3pPelJ6Q3QYe1JTUnfpUspQeVB7UXsNIWVlr69QelBQUgBVKlJ2UJRQUFFW UN2bUFBFEFlRRFzUGHtRUULpUspQeVB7UXtlUK+vr6FQUFJzVSpSdlCUUFBRVlATm1BQR+JRQlLo ryDkGHtRUUTpUspQeVB7UXtlUK+vr41QUFIPVcNSdlCUUFBRVlCVmFBQexBaUVBEv0RSH0RRROiv kORZXGREUeivMOQ4e1FRQulSylB5UHtRe3sNIWVQr6+vslBQUjJVCVJ2UJRQUFFWUN6cUVBz4lJR SuivkORZW2RKUOiv9uUYe1FSUkfpUspQeVB7UXt7ZWVQr69QFlBQVGdVDFJ2UAFQUFFXUJZQilBS UH/hUXzor5AQQV1AZG98UVB8QHxwfI98VHxQ6FHA5Bh7UVFi6VLKUHlQe1F7DSF7ZVCvr1Aar7RT 51UqUnZQAlBQUVdQ3VD6UFBQcxBEUnUQW11kcHVR33VRdVBQGHtSUXPpUspQeVB7UXsNIXtlUK+v UBqvtFPnVSpSdlACUFBRV1ATUPlQUFBPEEFSf3NRUHNAc1JzXkwYe1JRdelSylB5UHtRew0hZVCv r1Aar7RT51XDUnZQAlBQUVdQlVD3UFBQRRBaUlF1UFg4d1JRc+lSylB5UHtRe1Cvr1Aar7RT51UJ UnZQAlBQUVdQ3lD7UFFQeBBJU1J7EE1PZF97T3sPez97VHtQEhh7UlNSeOlSylB5UHtRew17ZWWv r1Aar7RT51UMUnZQAlBQUVdQllD0UFJQYhBIUq9yUdByn3JScHIAclIQclFwcgByUnJQ6FFy5Bh7 UlF46VLKUHlQe1F7ISENDQ1lr69Qb6+0VGFVKlJ2UAhQUFFXUN1QsFBQUE8QQVF1EEZIZN91UXVE UBh7UVF06VLKUHlQe1F7DXtlUK+vUG+vtFRhVSpSdlAIUFBRV1ATUI1QUFB04VF16K+QEEBGSGRf ddB1UnVOUBh7UVF26VLKUHlQe1F7DXtlr69Qb6+0VGFVw1J2UAhQUFFXUJVQjlBQUEsQXlF2EExP ZHZKUDh7UVF46VLKUHlQe1F7e2VQr69Qb6+0VGFVCVJ2UAhQUFFXUN5QslBRUH7iUlFi6K+QEF1e QWRPYm9iUhBiUWJO6K8C5Rh7UVJSeelSylB5UHtReyEie2VlUFFQM64/U8xVHFAQUMnlcFhOcGRO 6K+g405wZGjor6gQR0NKZBltCG1SbGJyVkFQUXJMbFZWUFFe6FNB5GVHeFll6FLj4mqSeOxS41BE U0FQf1NP5k9QanhZRxLoUT7iYtZy6FLj5XiSR0HWR+hS4+VM4hGE2Uh7QKS0tECtpLS2QGxAbFBv pLSkrbRsQGxAtH9saX9sUUFCaWlCaUFCaWFgUSF7e3tRc2VAd3Z3ZmZnVldWVnNydmVkZmNiRkd2 d3Z2ZWRmY2JGRURWVldWV2ZmZ2ZnZmNiRkVEVnNyd3Z2d0ZHVldWQVJFYXNFYmFhWH1Hcit4YhYV f3jOF1d/TkAaYmQcQGxdWVV/ZxB8W0ZJZRYVYUpJX9YZXw1sRUuuPwpRLb/F3Hs5A1VYWxYUYWES BFoJNBJoTm8fHBJyaSd9cGZUQ3VJVFYUYmASWFUaVsgf4c6crt5QUlBrUuRSv1U4UF1QSVDbEHBa W3pbv1O/W1TKQMVCxUbKSFT2UfZW+lj4XVRtWEQbV+hRLuZeG1BRRxtU6FJo50EbWklK/d1Iex5A pB29rb1Qb72tvWFgEykQflFJXHZSdV9dQXFQSVFHcVFDWEFxUEVWR3FRQFtecVFIU15xUUJZRHFQ RlVEcVB7e3t7UXt7e3t7e9FRDVANIVFiRkZFRFZzcnZlZGZmR3JWRURGY2JmZWR2UcUH9g2b39+b DfYHCi0uCQkuLlU4CfcK35ub3wr3CdIuCQkuLgkJLlBQUlDQrtdTwFUUUHFQelESEJIGTcdNUotD i0SgeVNbdzV69XlTQFB5UNVOx3r3Uvdxm1CIULlQWSF61nrFelMWTaJ4onlTdkByeHJ5U0J3QnhC eVNnWBxMHHL2cqdNVct6UcpMy03KclNQUVtMW3JTSlhDQ0RMTVVVVFZWQkByelhYWVdXQVBRUVBw S0xzSUJWVhZXQURXV0EAQVFMS1BTenlGeEJBUEm7dHZfXV5XcBhSVFNbVldQeFEPeFFfeE94UngT ekZ7UUp8erpQWwBbUltJe+pRy1HfUEh7HkCkDR29HkCmHbRApg0iIVB/bG9sbL1vbGy9vW9sUUFC aWlHaQ3XfnstQJRQQUJpaUJpaVFAmddAWGxebGxVbNdAWJRebGxYbGFgSBMpEEB1d1xddnV1XXhO UHdcdE5RUHtRe3vR0VENDQ0NISEhUCINISFRInVHVnNyd1NzQ3Z2ZWRCY2JHQ2NTRkZFRFZzcnZ3 U0ZGY2JTdnNyV1ZFREdTIHDWqQcByRX0Bwi/6ndnxhjOCQMUZmITRM99NxM+7HB4f3NkcaNHqHuu KFH/GIAqnlF5VFHZrjNyP29oFWBprg4BHFKTZ2Qb3zjZUFBSUHOvtFOGVSBQFFAAUI8QSRpGCUYl fVNyeHVXUFVWU3pRUFB4ePB3UXfoUpQQW3ZSU1N1dXZ2fkIY6lNyUE9TReJaX17oU0zmcFpRf1pR WuhRcuJCWx7oU0oQWUlbZI9vMH5VYehRchBfZxBBRGRnOxJSURBcXmRR6FKTEEFTEhJTend2fExf UyBTn1NTU+hSvxBEenoCAV6S8F9RXzQCGz9MNAECM0h7QKa9QKYNvUFCaX+9DUCkbEFCaX9ApHts QKZ7vVBvvb1vvW+tDSGkbECkvUFCaX9sQGxAbECtDWxAbEBsUUFCR2lhYFANUWNFc0ZFRFdGRmNi Z2ZnY0RWc3J2d1ZXVnNydmVkZmNiRkd2d3dzZWN2ZWRnZmNiRkVEVnNydmVkZ2ZlZHd2c3JWRURC U3Z2c3JWRURGY2JmUkaLnlJhZT1oOml4RHnh0248A3t5aBAANiAzRmJMVVsXielfDSDi0v8Zam0Z UlFFRnZzYGSReGJNf2RidHYWU1/IY0rCxFxccUdl4ZR/FWpJcTQSGDtYWW58scg/bPItx8sMbhwc blp5Q19hR0dqbhmupK0TTUN/cU9+Y1BSUAyuFlP0VTtQFFADUfsQ2lsUSxR3dscD6UzoTeht627o GlnZGtMb2QNTNhA3GdMZUwgDN0w5b1MVchRsFRtTJhAmGSUaU2kCaQM4TFN5EGgQaRVTdlh3dnl6 U1tvWxpbAksa0xtV+RT6GfcBU8gT+Uv4E1PSAdMC1ANT1xDYG9IAUydMJgPVblMmUSVKI0tTFVBQ ARtxGXEZGehShRBZEG1EEBBtS0xM6FKFEGoBUEQBAVBtEGoSGXQXTEtOSAEeU3EbFVBUVngbcRd0 FVAeU1B+QH5Sfl9cT1wPXFNcZzB4X0UwVlVf6FKu5FlZBQRq6FKvEFp00HTAdFJ0BQRI6FKvEFpT 31PPU1JTBQRh6FKuEF97EHsAe1LQe8B7UnsFBB7oUq8QWlBOQE5STk4FBBfoUq8QXF8STxJSEhIF BD/ZSHtBQml/Db1BQml/Db1BQmkNIX+9QUJpDX+9QUJpDX+9QUJpf71Qb71vvX8Nfw1RQUJpaUFC aWlQQUJHaVFBQmlBQmlpQUJpQUJpaddefnteLUCU115+SHteLUCUV15s115AlGFgUA0NDQ0NDQ1R DQ0NDQ0NDQ0NUXZ2ZWRmY2JGRURWc3J2ZWRmZWR2c3JWRURHRkdURURWV0ZGRURWVnNydmVkZmNi RkVEVkVERmNiZmVkd3Z3dnd2ZWRmZ1ZFREZHVWZmZWR3dnd2UWICFp3yx+kRYmFuXG9tGzZ5eMVR ODAnCG8G+j/O+hRiYBFJbG8IMXF9weU6BTD8D2oVUUJlfEd1GXNTdxkvFyrryQlmFG57Q2tDeGcO ZxBlZg6PsAnFAgUrGQPZAMIPYxcQd0cXR0t+BmoTfGsIPy42DwfxYwILYTVonGEDen95EGlMUFBR UB1R1lLYU5JQW1B2EENWxFBXXUdHSlPEWUlcXb1xP91Ie3serB2tHhU1FL5Qbx29YWBRYkZFRFZz cnZlZGZROyf29yYn9/ZTkvcnJvj4Jif3UFBRUFGuFlQFVRxQSVAF4lFSSOpSE1BTUdMQWUn+X0CS X15QX+hRM+VGRkcgSUjoUV0QWlBRIFNQUkBSUlLoUZHlV0lKgJ9Iex5ApB2kDWytbKZsrWxApFBv bL1Ava20aWlhYFFBc0F+UmVkblJnZmNxRXNyVldWRUFzQVIvNOq3KWI9IhowsVHofGtsX1szVVCp FlM3WDyN2TbVKRJdQnx0ckk8qaFW6lBRUGqvplRdVTtQFVC7EAhWWKVkUrhbt2RS1UPVZFIlZNVC UnVcJ0NSh02HclLTcvVyUlZH+Vf3R1NBYmxWQVFBZ3ZmZkkRx1pRgE9REE9RT3fHSVpS5lBRWlFS IlUwe1Hwe1G/e1F76K+QEFlbXWRAe1F7wHPoUW0QZBBMUUyUUGZnKUBsUWxiIF3QXVJdC0BhUWG6 UEVRRUoXFV9QT1BSULpWEFUgVdBVU1VJFh7pUd9QSHseQKQhbB2tDWweQKYNHb0NpA2tDaRsQKYN rbYNew0hIkCkbFBvbL1vvX8NIW+9Qml/rWkNUUFCaWFgUQ0hUCENDQ0NDXFxZWZmZUFkZmZjYkZF RFdWV05SRURWVnNydmVkZmNiRkZFV0RHRmNiZmVkd3Z3dmVlZHZ2d2ViZmdmZWR3dnNyV1ZWRVHi rthnfTCYJ4GVFWImNyQcA8gKDjhlfE1ycVdfX0NDc3RCUlVJFBhqZFpURnEfeUt1THRXbDRTTt3O B/jSKBJ/REUK6j7YmjUMb35mQn5WClVcXHhLSDtnXHBq3yIbfVRtfH5IOdt8EENKGCpQUFRQa6+x VZZVO1BfUE9QEFAaUcsQ209mq3apd1NXFVFGXkRCREZMSkxOT3lPf3d3+nn6YOl56mBcWVJZVlRC VEZcSlxOX3lff0lSSVZGWltPcE9nT2hPEFQRZtl65EHkR+pJ6k+IFbkVqXmpf1p/cHBlcGZ/Z39o fxBhZWFmEWVZWHhQfVhg2WD4efl/VnlwW19vYHBFR2R/cHl7ZGzxTWfoU27lcm3xEE1w6FNuEF50 fn55fU1+0GZRYvFNZuhTbuNzeXh46FLpEEtgf0RgYH94eX9gVHVieX14YWBhEmERgnBhUWHor5AQ dltCb/9hUWFhZhqCcHFnfn5mZlBQcUBxUnFxWED4UFFI+Fhbfs0W6FLpEF+gdVFQdVF1GhERYWFi bWLoUukQTGx1X3XQdVJ1VGxfbFFsXEz4VEocRPhcSRv93Uh7HkCkHb0eQKYdvUJpIX9BaSF/QL1s QGxAbEBsQCENvbRQb71vvUJpfw1BaX9sQGxAbL1CaX8hew2ttEBsQmlBaVFBQkdp115+ey1AlEh7 USFQQL1RQJB/e3thYFF7e3shDQ0NDQ1QIQ1RYlRCRURSVHNydFJlZEJ0R3JUUkVEQlRjYnRCZWRS dFVxYkdGRURWV0dGR0ZHRXNTc0VERkdFcWViZ2ZlQWR2d1FGY2JmZWR2c3NTUONRBO/srv7o6K7/ 7O9RBOLMrof39FF48PFRd/T2roetuFE65xc1CQrZTnBfTKKdfn0brgluQklzZlFPckcRDQcKdlU7 56776eiu/uvrUQLo6VEF5wnwroXx8a6J9PRRd/HxUXvwgHxvIBc/SapmS11VclEglgVgU3JyRU0G UYgCfVauzFUyAgQHUFBTUGuvsVWWVTtQX1BPUG1QmxAQJ0X6ZeNB40fqSepPVkNGS0pLTnllJ0NV W1JbVlRCVEZcSlxOSVJJVkNCWVB9QH18cX1ycX0pZFYafVF9fm1kcOhRw+NyZHFx6lJbUHBRw+Vq EFxeZGroUbblfX57dWxm6FFd5kD4UFF7bGDoU3UQXEj4WFt+YH9xb3FScehREedM+FRKb3jIY+hR XedE+FxJbv3dSOhREtV7HkCkHa2mvR5Aph2tpg20UG+tpr1vraa9QWlpvHukvVFAvaS9UECZYWBQ IQ1RDQ0NUWJUQkVEUlRzcnRSZWRCdEdyVFJFREJUY2J0QmVkUnRHQXN2dnNyVkVERmNiZ0VWc3J2 ZWRmY2JHRmNiZmdTUONRBO/srv7o6K7/7O9RBOLMrof39FF48PFRd/T2rofidkTXCz7EwTzEISmV 7Lmq7gY/cF5CSVNVO+eu++norv7r61EC6OlRBecJ8K6F8fGuifT0UXfx8VF78JCuqDUj/+2a/NoW L7Pk76h4XEhLUFBSr61SdVhbVRxQSVAUUTvpUEavoBDyRktklkuXTFL/FuVLUm8WHxbXYFMCYAdh MGBTYGAQYAdLU9l/52KXYlNJEFlbZFIQWVtkUixWVupTZFJDtmRez3JYtmRdz3NJLEVF6khkSXO2 ZE7Pcn62ZHrPcm+2ZGrPchC2FGRKz3R0tmR5z3NjtmRpz3NLTEy5YWJEYUxNYWJNTEzaYH9EYExL YH9Mf2JTS2FMf2B5enpgYWFpaWpqXV1e6FIREE9QVldXRERFk1BOTU1LS0pKUVFQUk1/c3S5f36c YPZh6FE452Jj2hBwb1Fv6FLhEEVYUVOSUtZXWLlEQ9ZIklBJ9hWA2Uh7QKVsvaRsrWykvWxApg1s rWymvaRsrWxAbFBvbEBsQGxAbEBsQK1sQGxAbECtbEBsQGxAbEBsbEBsUUFCaVBBQkdp11h+e1Ut QJTXWH5Ie1UtQJRIe3t7e3t7UUC9vFBApXt7UUC9vFBApXt7YWBQDVENDQ0NDXtTcUVzdnZzc0FE R0ZjRXFlblJlQXNyVldzdXFDQ3FFclZWRUFER0ZHRXFlZmZlQVFzUUFER0ZGR0VxZW5SZUFkdnZz U1NZc1QKNHZCRm+uamtNX3MwC1dxUydRILe1UQtgdEFfSG6uYxl5rpBIrpJWWH5nrrdpdEFDdGdV HLIIBq3lBUVMcnJUQHobUhgCDLKuQVG/dkR4Gq54HERNVHJyUnwDUaqtM1LNrloUQEZKUXJyU0N6 F1GEF3lEUFFQtFRPUtVVKlBTUGoQXFBSUVJRU19QT1BSUOhRFuQvUVFRUOhRFORTKFJJVOhRr+Ez SHseQKQdpK1Qfw0drQ1sQGxhYFENUVFzQ1LVruUGJFUqrvVRC1BSUEZUHlLGVQhQW1BHUGYQTFbV UELVXFxQUElHR0pT1V9ZUVmoX9VFSUgCxkh7HkCkHa2mDa0eFTUUtlBvbB1AvUC9YWBRYkZFRFZz cnZlZGZxYkZFRFZzcnZlZGZSQWgdHmdnHh6ukWgdHmdnHh5VCB5nZx4eZ2ceHmdnHh5nZx5QUq+5 UFBX9FUcUBJQFVHG6VByr6AQakNIZFZyUVd9V2pIandTZlNnfWdqKUItTtlCWk1xBU41TiVbIHAg cdZbxlvJQcVP9lv6QvZPXVdSUXHor9DjXl9kcOiv0ONeX2Rw6K+gEAlZXWRFWFd7E3wVFBR9cHFe AUVFCV9NXnpwTXPDcmZqZ01mXQFYWAlcTV1lfWRNZRJrEU0Sa2pqeH0URH19FGtqfVN6Fk5wcVNy XnJx40x+c99RUVEQW19kUehRduVWVld+El7rUXZQRVBdUXYQFVh+RUVzElASZmVlc3x+FRVzElJz WF1fXk9eUl4PXj9eUl4XRlEQW0JkUdMgccBxUnFKF1dfRk9GUkZuFHpgelF6F2ZJFuhRwuHlSHse QLRCaQ1/bB2tDWweQKYNHbR7QUJpDX8NbFBvb0Jpf71AbEBsQGxBQml/rbRAtECtbEC0ew1Avb1s QUJHaVFBQkdp115+ey1AlEhQQL1RQJBQQL1RQJBAvbxQQK1AvVFAkHtRQL28UECtUUCZ10AtlGxT bGxAbGxQe3t7UQ1hYFANUQ0he1FBc35Sc3NBY2JmZ2NBc3Z3dnZzc0FER0ZGY2NiZmZnY1NxZWNi ZmdmZUFxU1ZXVkVERkdFcWVmZmdRZmVkdnZzZVFBUVcUd0o1xPY6dA4rSXNzXnhLNG10VVhlBAAx 4zR2dm6rChwIElpUrhnvfVdbFwuuGGYLGFJ1FE9oDlFuriZVHK4+1NlmrYvV6a1qJwJnEa4zCENP cAvaLK4FdX93QDNRCa6fF0RMSnZoUnV1VhMjUzo8S0h7QnWtFVI8rcRQUFNQAa/jVb9V3FBHUHJQ f1HREFoWchp/BnIJf1RN6K/QEFlZWmR30FlaZEPor9AQxFlaZFbQWVpkxVLFVclC9lL2VId6Vl9O 2FrHUshUllWaQlZuWFBbc3N0f398WlpRR1xycnFISEldXUYQUUZRRl1aXVpBUVFGU11dWkBGWkZa fHREdklxVntwUFFaW1xdRkdYU0Byc0h/VHtwfHRwe0lxVnZMUFFaW1xdRkdYV0Ryc0h/VHZMZURT dmVXWUJASWA+CEh7HkCkHRMIEEFQe0B7UnsdU0phX3BPcFJwHbkNHkCmHbkNS+Z7HVNKYXAdvR5A ph29CVBvvW+9QUdpQUJHaUFCR2lRQUJHaUFCR2lBQkdpbVF/f1B/f0hBQmlRaUFCaVBpGwEI4ApK CVZeQJ1WXkCdSldAWGxYbF5sbFdAWGxYbF5sbGFgEykQelZDd3pNT0FDVFZOdUJ2VXZ5enh6UlZN Q3B1UHdWe3VRT0FMdVF6VHZ1UFB7e1F7e3p7e3vR0dHRUX9/UA1RDXt7e3tQDVFXRkFEUlRzcnZ3 V3dndlJlZEJ0Y3BHZ1F2d3ZzcldWQURHR0ZGY2JmZ2ZlZHd2d1XkyoWRrvrhO6UwzWfMPSHrUQKW UVPqyq6CZWwAPMYNI3JMa9g2PM1kd1dVQVUL4oCun52u4vwUEeNh4zVRSsSQUR3kweKu9C9/by3L rsbPzgItNC/0Kpk/GmULUFBRUF9Q2FQFVJhQX1DYEF9fUFtdVlVYWm9/Wa9ZUlnoUTznVm9/Va9V UlXoUUTnU1NwUqBSUlLoUUTnUG9wX6BfUl/oUTwQWVxvW3BZoFlSWehRRBBbU3xYb1JwXaBdUl3o UUQQWb9bUVtJQIDGSHseQKQNHaQNbK20tA1Qf62mDa2kDWxApA2tpg29UUJpaUFCaWlhYENxQWNB cUVxQ3FFcXdxQXFAUbHTUbGuT1FRsKvrUVGyrk9SuFGwrnDUrvjU01EJUFBRUFBQUFOuVRxQalHe EBRIcU93F38XajdxNn1WT3xPffd9U1BAX0FAQE9BVGZlFmUGZTdlJmVVZX9kZGV2cnVkdspm+Wbp ZlNmamdkZnd8eGR3WRFaUXBQZFBAUa1Qc1BHUXBQZFBBUa3kcnB+fHzoUXQQD3JwRHJycH9qUFAD fn9Efn5/SktLVVVWA1dXWFhISH9JUUnWQVJTU01NTgNPT3BwflFQUH5ffk9+f35vfh9+/35WfkB3 ZmVld3d2UkBBWlFSUlZWV+JYT05OSkpJ4khq6FENEFp9f1F/+35bclFy6FES5X18bXxSfOhRbxBF fn5UTFRVVVhYWXpHTEtLSEgAR1FH6FE+42uAxkh7QKYNbEBsQGxArWxAbEBsSUFCaX+mIUi9DUlA pA1IvUCkbEBsQGxApGxAbEBsUG9sb2xAbEBsQUJpDX9sQGxAbEBsHUCtbEBsQGxApA1sQGxAbECt bEBsQGzXVX57114tlNdefkh711UtlEh7e0C9UUCQUEC9UUCQDVBAvVFAkFBAvVFAkA0NYWBRDQ1R cUVxV0VxRXFFREdGRmNjRXFlY2JmZmVlcWVxZXdxZXFTdnd2d2VxRVZWRURHQ0NmZWR2d2VxRVZW V1LtURGu9F1ROa7HWF4QHHStanIDG0uuwFEgXq7OURfnfHRGelG9bXZNl/R3cm5RdX5veFI5HHjY HHwLS3x+dXV4ETt4HNh4HFGtKXZHVHx8UUxBRQCtjFGLI39NS1J8fF0WI1BRUB+uF1QpU/dQflDv EH/gYFF8fnlxc09PUnl8enJxVHZPVUZXSVhRVl4YRlU2TExGW3ZfX3NRcylSeRR+Q+hRXhBwWV9a T1pSWrpYVxBydWRvV1HfV1EQV1FXuVFPUlFSYn7or5DjZ2pkfuivkON/YWR+6K+Q4nplfuivkBBB TXRkoH5RkH6AflJ+SX8eBUh7HkCkDSF7e3t7Ha0NbKYNDSF7bK0NbKRAtEC0DVBvb2xAvUC9b2xp aUFCaUJHaVFBQmlBQmlBQmlhYA1DcUFGRmNiZ0FxQUdERmNiZ2ZnY1ZWc3J2d1ZWc3J2d0RGRkVE VnNydmVkZ2ZmZchRRlF7eQobUUVRd01HQktYe1TDOxg3SRvaHnhsYVtgEmViakhwQVP3rRofZSlS ka3fZQFlSHQE3cocAQMaRXNtF/tybhZtaHwOLcH/UFBSUH5TTlImVThQYFBqUXsQbRxYDFg8WCZy 21jMWPtYVxlTGmpSj3G/caxxU9VyxHL0cudyl3KHclZ9SE12ZB9JD0k/SS9J30nPSf9JV0noU00Q XmIQXEBvYpJZWXB+YZJQ6K+Q419Eb1Dor5DjXkNvUOivkONdQW9Q6K+Q41xAb1DtU01QaVB7U0JQ fFNB5Hkwfn5p6lKYUFJRlRBdXmxwUXv2fBF0L3VRdehRXRBEUFpZWWJiUFAfYVFfYS9hUmH0VUbo UV3nTGBmEFxAb2boUV3lVc5rAhVIe0CmvXukvUCkDSFsQGxAbEBsQK0NbKS9UG+9rb1sQK2ktECl e3t7e71BQml/vXu1DWFgURvgTwMb4HgBCgjpUGGvsOFRcGhQaAlRG+BJAxvgcQEKCOFCcGgJUXsN IVAhDVFWc3J2ZWRnZmdlZHZ2c3JXVkVER0ZFRFZzcnZlZGdmY2JGRkVFREZGY2JnR1ZzcnZ3ZVZX VkVERmNiUT4+CGcTe2iNXnlNeUxAQ0h+d3tlawIvAzxOVl1ZQUFEbwRlaVcfdkl1TXJTKQsRYGR9 aw5ob3FKQ1peXENKR056f09ofG5pFw+Kd0NaRl4FfQrremJPT0x3UFJQaFNFUiJVOFBbUEtQaOJE bFboUZXnXGxQUS9TUVPoUV3lSeIvQVFB6FFdEFnPWVFZzkz93Uh7QKYNvQ2kvQ1Qb72tvWFgUWJG RURWc3J2ZWRmR3JWV1ZFREZjYmZnZmVkdlEDLfLPLS7w8S5PfVdeZXlOfFhdYlU49dTW9PXS1Ph7 dHVs/y0ednJq+dkbUFNQCq+0VdxTk1BoUBVQAVE0EBlDeFtCZEJ4W0Jk01OFH7YfU3ZGlh9Sm16L XrhepVJUd1jHZ1IJWPp1UVZXFhxHTHleH1EWH15mWld7UFZAVnBWU1YNVFBRFhVp6FF45G92ZldU 6FFOEGFaW3l5EF5AZF95UXlBTHZ/VxwYQVsVeV9RT1FSUWJIRxYWRFdfaU9pr2lTaTmQUFFQ6K+Q 40BDZFDor5AQRFxeZFBQQFBSUEoDdXx7UBlRGWJE6K+QEFlcXmRESQJo3kh7HkCkex29IaSRHkCm DXt7DR29IWxCaX9sbK0NtFBvvW+9Qmkhe39vvW+9pGytbECkDbRBQmlpUUFCaWlQQUJpQmlRQJlR DWFgEykQEWwUfWhJTxMUEhQRFFNWbXZOdWF1SnYQZRVOUGRuZ2tOUU1+cE5QS2BITlFiYxRkb05T bGhvTlFPfUxOUUliTE5TUHt7e3tRQGx7e3tse3t7e3t60dHRUA0NUQ0Ne3tRcUZGY2JnR1ZWc3J3 dndWVnNydmVkZnVlZHZ2c3JXVkVERkdGRURXVnNydmVkdGNiR0ZHZmZjYkZXZmVkd3ZzcldWV1ZX VVZWRURGY2JmZ3Z2VdyttEXLMN0OcQnn3jsEb2c5lQsyJPVRNUsCZWt5TlhJdHJ/amgCUVDBNQJh YGojAPGbu1FjcmhySntHT1Gup8gOG2NyCWdPS1GjnP7JR/AnYXQcAAE8GAnp8R0zGGFPR0lXXkp1 fn1OeQBmP892R2ZtZrD+cUDOGWFEcxIIKHg1PBdgF05OEd5QUFNQFK+0U+1TjVBKUHVQYVEE6VBd r5DjWUBkXuivkBBLWUBkShBZQGRQEFlAZFBLUGFAS0BhaEsYS1Zd6K+Q41lAZF7or5AQJVlAZEoQ WUBkUBBZQGRsWFBhdl1cXFFKS3VeX19JT3lOf3NcXV5fSUpQUVhVQ0t1dmFUf3N/c3lOXF1eX0lK UFFYWUZLdXZhVHlOdkdFRld5dlhaWVt/EFVKEGNRY19zT3NScxBgQxBDAEPAQ4BDVUNJYmghSHse QKQNHb0NHkANph29UG9sbL1vbGytQUdpQUJHaUFCaWlRQUJHaUFCR2lBQmlpGwEIEFoQUUlRSV9c X1wKSlZeQJ1WXkCdSgnXQF5sVC2UlF5s10BebFQtlJRebGFgSBMpEHx6fk9yREVWWHFycHJSVld2 fX58fnt+U1ZPRXNOUHpYf05RckROTlF+VnlOUFB7e1F7e3p7etHR0dFQe3t7ew1Re3t7e1FXRkdG RURWVnNydndXd2d2d3ZlZEJjYkZHZ1N2dnNyV1ZWV1ZXRUZGY2JnZmdmZWR3U+0hEUVLO54oCNcf O38/Y0NItoEDLBM/q1oWf3pHcHlXUVJVHmV9SXNCSFNT4dMJbgE8wL0pZxQrfNIBbgEOmFF7f2fQ ro89A19GD9BysA/YNERMbQH7Wu9QUFJQI64WU9NTnFBbUH5QwhBDWXhZe2h7GHtUf3BRcEX+dl9d XOhTSeN/VlFW6FEUEF1QXJJfXU9dUl1dc3lT6FEUEEhfWU9ZUl9ZT1l/Wd9Zv1lVWdZfQk9CUkLo URQQW0B5cHlgeVN5qH9N6FFz5V9zT3NSc+pRalBgUcvhkEh7QKYhvUCmDb0NpA0hvUFCaX8NvVB/ rQ2mbG+9fw1hYFANUWJGRURWc3J2ZWRmQ2NGXlJFREZjYmdmZWR3dmVkZmNiRkVEVnNydmVkZmdm ZlJ1Ew4PEhMPDml5Uko4cTgXZnVMQ3sTYmcdnOeSmzfGNG5TnA4TEw4OExMOrns+PpElBtUuTUZI QHIdZ2ESHxEn4+rTD/AzEjdQUFJQ/64WUaxTnVBbUExQJea1RqZEUl1c6lNJUFZRFhBcUEVfwE7w TlJO+0Jc6K+QEFxJT2Rckl0QSU9kXVnoURYQQVNdXUhQU0BTUlN8X0JPQlJC6FEW58BI8EhSSPtN 6lHlUY5QSHtApA2tDbQNQml/QL1Ae717QLQNUG9/raZsYWBRDVFiRkVEVnNydmVkZkNjRkdHRkVE VnNydmVkZ2dmUQQUDg8TEw8Pfn1Wd2R/DBoYD2JlTFOdDxQTDw8TFA+ufCLyipQFHQ8wGRuBiiRQ UFFQeVHvVD9T1lBVUBTiVW9Q6FEkEFtTVG9RUVNvEFJRUuivkBBFWV1kUkpXVRBQUVAQQ0lkUElW AjNIex5ApHshbECmeyEdvWxAvVB/rb1hYENxQXNBVXlUFtGsa1PWrmlRGVJQUFGvr64WVFFVPFAT UVIQe8d26FHqdVPIUvhR+VJT2FHYUthwU0pYSERCQFRbRnURbWdldlR/EF94ZH/oUV7ladJ5URNy 6FEPEFkRUHNAc1JzVlvor5AQbkRHZFBbUVsNRnZVX2Z7fDd/Ym9iUmKUbHlve1ARDRJ7Ew1fUE9Q UlC6cV9RT1FSUbpwc3tyDXEicHtLX3lY6FFOEERCwEl5P0tR30uvS1JwS2BLv0tTS+pR4FAUUkHh kEh7QKYNDSG0pr20QKSkpLRAvQ1ArQ2kpLRApKSmDb20UG+ttA17bw1srWxvrbR7R2lBaUFCR2lh YBMpEEBqa3Z4anhsTlB3dmt3aU5Re1FAbHvR0VENDQ1RU1JWVnNydmVkZmNiR0ZFRFdWRURGY2Jm ZWR3dmVkZmdDc2diZkJnZmNiRkVEVnNydmVkZ2ZlZHZzclZFREZFRFdjV1KXNRU65zEaAmx7ek1G VFlAXUxhVlNdSz3eSTI0OxkYNx4Dbn52YktVQFt1alleykhTQK5crv6iwhd9d2xJQ3JdW0hWWF5u bUocfHYePtZSSCoAUXBpaRlnYhBicUVmWlZYXRcUdztKfh4qUFBSUHRQWFOLU89QVVBbUI8QQs9Q z1b8UPxW61DrVlaZUZlXUu1S4FBcUFdSw1BdUsIQGlx6V+RWUnlQelF5VlP0UPRW5FBTdlbEUMRW U0lSSVh2UFNZUllYUmdUZ1oXVBdalVSXV5VaV8hRyFeXUVNSWFZQVlpQ/lVVU/5S6K+QEFlbXWSQ UlFSO1ToUXPjwFFRUehRXedaVv5bW1n+WOivkBBZW11kkFhRWDta6FFzEFnAV1FXNFwCM0h7HkCk DR2tpg17rWxAvUCmDa2mDXutbECtUG9sb2xhYFENDVEhISEhISEWFBYUGRRQDVEhdVFRY1NDcVFR Y1NDU96uDVH4GLu7raCuCVH3H7+/WFGdUZquZq5jUZ1Rmq5rrn5QUlB2UFhTjVPPUFVQW1DcEHZo VGhaGFQYWsdSx1iZVJpaWHZSdlhSVlFWV0ZSRlhUUlhaUFZWV+hRcxBFWlj+WVlb/lYQW11kn1ZR VjvAWlFa7FFdUFFRc1BUr5AQRFtdZJBUUVQ7UP5VVVP+X1JRUihc6lJqUYpQSHtApA2tbECtpg17 raYNpg17rWxAvUCtUG9sb2xhYFEhIQ1DUVFzQ1NxUVFzQ1MjUfKuCRi6ulJAUfeuCR++vlPPrmOu ZlGaUZ2uY65mUZVRglBQU1D/r7VXAVFkUFtQR1BzUBHlSBlOXBlC6FNB405QGVboU0HkTltLGXHo UTziXxlF6FE851MZWUl0iJ9Iex5ApB2tpq2mvVBvpL1ApL1AvWFgUVFiRkVEVnNydmVkZlViRkVE VnNydmVkZlViRkVEVnNydmVkZlEFFjEyFRUxMVKgFTExFRUxMVKgFjAxFRUxMVFkMhUVMTEVFTJR MRUVMTEVFTFSMRUVMTEVFTGvr1BAUFBV4FdLUnZQdFBQUVdQE1HaUfFQeeZSdhBJS2R26K+Q5Flf ZHZA6K+45Bh7UlF46lLJUHlRfNVQe1F7e3tlUK+vUEBQUFXgVopSdlB0UFBRV1CWUdZR0FBu4VJ1 6K/Q4l5ldeivkONfQWR16K+Q41ldZHXor5AQXUpl4HVRdUCmGHtSUXvqUslQeVF81VB7UXsNe3t7 e2Wvr1AAr7FVoFaMUnZQYlBQUVdQllGUUdJQdhBfUnBPYE9SEE8AT9BPU09Q6FF95Bh7UlF16VLJ UHlQe1F7DQ1lUFJQGq++V85VD1BkUBZRpxAgN08kT99DyFPEXc5DyXnGf/Rd/UP1T/d/82z8EulT 6lTiT5Z6mX5DXV1SQ1lEe1tzRFV6VGlUPFw8Qy5UL1wvRClP2lTfXNxd20PYcshPyXrJfvlu+xDp EJZymRCKVIxPiHmIf4ttixG2crgQpnJOcuivoONJT2R46K/Q41laZBLor9DjWVpkbOiv0ONZWmR/ 6K/QEHRZWmRjWEZYV3BxWEBXRkFHcHJxUd9Rz1H/UVNREFtfZE9RUVHoUXYQX1dBEEFDZEEQW19k T0FRQetRdlBGUECvkONBQ2RA6K+Q5ltfZEBAUUDoUXbnWHLQcYBxUnHor5DjXF9kcehSLhABTH5z V3hkWH5GRmRzWGRSazpgUxNld1lfgkBCgkBBX0FRX0FPQVJBFxhSglEQW0JkUdMgccBxUnFKGFdf R09HUkduZRZgFlEWFxhCfEkXPuVIex5ApB0TCOZfb09vUm8duQ1L4W8dvQlBQmkNf2ytDWweQKYN HaR7vUFCaQ0hf2y9QL1Qb71vvW9vQml/vUC9QL29ew1sQLQNe3tAtA17e0C0DXsNUUFCaWlBQmlB QmlAmUBsbFBhYBMpEHRsEnh/bXV+dhF2ent5e1JWbH9vdVASeG91UG59a3VREHsTdVBQe3tRe3t6 e3t70dFRe3t7e3sNUCENUUFzflJzc0FjYmduUmdjQXN2dnNzQURGR0ZjY2JmZ2NTcXJXVnNyd3ZS ZUBnZnFiR0ZjU2R3dnd2c3JXVkFAR0ZjYmZlV2x4QzLGNfFwfmB2Y3lXdnZPJwFwQUNLGG30s3p2 bq1fThvZLpLa4ejw7lFsKdBlA/hVW3VjHt8GID0G3DcFVRyuPCbeb62JSUMTKgeta+svrvnHZVtA 5vyuA1ZcGA1RBe5RWJa7XlWu5zxNZ056Kcyu066WwCIPwVBQU1AWr7RV3lOTUHFQZFAQUXsQbtRT 1UfIcfhxlUeWSLZHpkdYJ0fVQ1I3RydDUjZSN0NSBkMGR1J3WVFgWFdYWHtwV1FQV0BXUlcNVFBR FhBl6FF4EF5PcnZJanZPV0lXfHZBVOhRThBtW0FbW1teXlFMTGAQeVEQYEBg0GBSEGDgYFJwYGBg UmBFL2VRZRBJTGTPZf9lUmU5WFBQQFAgUNBQ8FBVUOivkBBeXF5kUEoSX3dPd1J3EEXor5AQWVxe ZEVJEWjeSHseQKR7Hb0NHkCmew1sHb0NeyFCaQ0NIX+ttEJpf0Fpf1Bvb0C9QL1vb71AvUCkbK1s QKQNDbRRQJlhYBMpEHJob01xbm9tb2xvU1ZrThBOUE1MaXBnTlFvTWpOU2hxak5RUHt7UXtAbHt6 0dFQDVENDQ0NDVFxRkZjYmZnR1ZWc3J2d1ZWc3J3dmVkZmZjYkZHZmZjYkZ1cldWVkVERkdGY2Jm ZmVkdnd2UWZlZHZzcldWV1ZFVd6uRELCBGs1ZHAA4SMfIBAZJga4Kw0hhikL1xBrKx/Bn6wrfU13 fHl0Sn1kEHd3dUxSN1EYfU5LdEBKUb+Z/hcER8stZhUXZPzR6ty60hMYGBOg+khx+LmUwk1FZfGv kNhOR67naETEOEZNZwPbUFBRr79RzVRAUkZQU1BLEF1Sb1CuUEpVUUlUGhVIex5AtEC2UG8dvWFg UXFlcVRAq49UcVHNKVBRr7xRzFhDUkZQU1BLEF1Sb1CuUEpVUUlUGhVIex5AtEC2UG8dvWFgUXFl cVhDp4lYd1HMKlBSUAFSn1P9VTtQR1B/UCwQQaZSpkpSV1lRVE9xSUxRklBC6FEW51ycUFFJkkh6 6FEW5nScSFFfY1HoURYQWlQbX0VRRah3Y0noURYQRUwbfRBFSWTffVFffU99Un0GYCrZSHseQKQN DXsdva2kpg29raRQbx2kvUC9b6S9QL1RQUJpaUFCaWlhYFENUUVWVkVER0ZjYmdmY2JGRURWc3J2 ZWRmdUVWVkVER0ZjYmdmY2JGRURWc3J2ZWRmU9s4JlZUVVVacGFpCDUYBCr2roI4JlZUVVVacGFp CDUYBCr2VTthdvMIQ1lWV0cNEBM22iTXhhFhdvMIQ1lWV0cNEBM22iTXhlBQUlADUp9T/1U7UEdQ f1AkEHCpUqlKUnFPTElXWVRRSZJInHQZelFRklCcXBlCUUwbfehRFhBaSWNfd1F3qFQbRehRFhBD UWNfEEVJZN9fUV9fT19SXwZgP+lRi1BIex5ApA0Nex2krb2mDaStvVBvraS9b62kvVFBQmlpQUJp aWFgUQ1DZWZmZWR3dnNyV1ZzcnZlZGZjYkZFRFZVZWZmZWR3dnNyV1ZzcnZlZGZjYkZFRFYlNyZW U1VVW3Bgagc0GQMr9lF+NyZWU1VVW3Bgagc0GQMr9lKfYnbzCENZVlhHDRAUNdkk14YSYnbzCENZ VlhHDRAUNdkk14ZQUVDIUoFSQ1U7UEdQF+emUlFXWVFUQuhRFBBZXJxRklBRX2NR6FEWEEJUG0UQ QEhkX0VPRVJFSUgqykh7HkCkDXsdva2kUG8dvaS9UUFCaWlhYFENUUVWVkVER0ZjYmdmY2JGRURW c3J2ZWRmUb8kOVdXV1ZcTXtrBzQXBir9VTt8Ys8DQVhZV0EMbhI01STfjlBRUMhSgVJDVTtQR1AS EEGqUlFXWVRRklCcXBlCUVQbRehRFhBCUWNfEEBIZF9fT19SX0lIKspIex5ApA17HaStvVBvHa2k vVFBaWlhYFENQ2VmZmVkd3ZzcldWc3J2ZWRmY2JGRURW7CQ5V1dXVlxNe2sHNBcGKv1SgXxizwRA WVhXQQxuEjTVJN+OUFNQQFCoVAVUDFBbUF9QS1AH61BQU3VQVlNJ4lz/X+pTSVBAU3UQWUYgXtBe Ul4vQ+hR8hBZSSBd0F1SXS9T6FHyEF9ZfCBJ0ElSSS9fZ0yAxkh7QKakDaSttA1ArbQNUH+tpq2m vWFgUWJGRURWc3J2ZWRmUXFFcVViRkVEVnNydmVkZlJke2xse3psbK5WVBWr61Jze2xse3ptbFQM bHp6bGx6emyu3NTObXp7bGx7em1Qr69QQa4WU71VCVJ2UAxQUFFXUN5QlVBRUGriUlFv6K+QEEdw cmRvEEBBZB9vUW9vP2+/b1Ovb1FvV+ivm+UYe1FSUmbpUspQeVB7UXsNISJ7e2Vlr69QQlBQVeBW jFJ2UGxQUFFXUN5R61HUUHUQXFJRQGdRZxBdQGRnVuiv4OUYe1FSUmTpUslQeVB7UXt7DWVkUFBS UEVQ71O+VNpQTlB6UPsQEchO+E7oTrVQulO1V7pau0C1Q7pItUtbllCWS4dQh0tUeER5cXxzaXFs c+B8VpdTmFqaSIZbVFhjUmN4G1cRUxFV6FF/EEtyG0JjSWNDEUgREEUARSBFwEVURQZ7WWNBY1rq U0VQQFNF4nUbXehRf+RRY0pjUOpTRVBLU0XmTxtNVwLGSHtQb728vLS0rb28vLS0UUCmDby8tLS9 rby8vbS0YWBRIQ1QIQ1RZ0dXRkVEV0dXd1ZWc3J2d1d3Z3ZlZGZnd2dHZmNiV3JWRURGY2JmZWR2 U1vaCdwHB9EM0gAhFholGNUI0wh8fNgN1SzZ1tTS5+jR0ufnVFPXB9wq2tfS0AvRYnN2f9EL0CXA Ftxm1wzXCtLn0dLn59LR51BQUVANUFdSHFPOUFVQLO1S4FBWUFFSw1BXUsIQTlZnVBZUyFGVVFRZ UUlReFEpUFRSVlBaUP5VVVP+UuivkBBZW11kkFJRUjtU6FFz5VEQc3VkUeivkBBDXUBkUFFRwFHw UYBRU1EGVj/ZSHseQKQNIXt7Ha2mDXutbECtUG9vYWBRIQ0WFBYUGRR1UVFjU0NSUK4NUfgXurpX UZxRm65lrmRQUVAPUFdSHlPOUFVQDxB5VlFGUXZRJVBUaFQaVMZRnFRUU1JaVVBWUv5TU1X+n1BR UBBbXWRQO1ToUXMQRVEQXUBkX1FRz1H/UY9RU1EGVz/ZSHsdQKYNIXsdraZ7Da1sQL1Qb2xvbGFg UQ0hQ1FRc0NT+1HzrggXurpTzq5krmVRm1GcUFBRUD6uOlPBVRxQJFFrEF7JbclumG2YbohtiG5W buivihB8XkNvVUBeQ29nWENKZJdRhm2mbVPZVtRt1G7WElQSERBvbm1WVVRTUlFcBlfor5DjXUFv V+ivkBB9XEBvV1A4DGwQXUFvbBBcQG9sExwGV99sUWw/bC9s32xTbBlQ0BOAE1ITExll6lNBUF6v kONbQm9e6FLj5GlaknlK6FLj5H9E9HMZ6lNBUDtS4+QWIpIDMOpS41AfU0EQSDT0CVBaSpJpeXkW QXw4cHwMdnwGYnwcJuhTceI41gzoUuPkIjCSFgPoUuPiHNYG7FEYUCVQhFFjUEh7QKa0pGytbKS0 tkC0QLRAtEC0QGxAbK1sUG+ktKRsrWyktH+kbKRsrWyke7RBaX8hbEFpDX8hbFFBQmlpe3tBQmlp e3tCR2lhYFEhDXt7e1AhUVZWRURHRkdWVlduUmNiRkVEVnNyd3Z3dndGR0ZHRkVEVnNydmVkZmdW V1ZXVnNydmVkZmNiRkZHdnZ3ZmdmZWR2d2ZmZ1ZWc3J2ZWRmY2JGRkd2dmVkZmNiRkVEVlZXblJj YkdGRURWc3J3dnd2dndGRlLXbH5MRGpteFkY0HlIYm1sYWAdZk5EdlZXW012bWJjbh9bdUJLZgRl YWxueUh/wBBbe2lqRk1+b2ZhWG76fn5sb3tJYtsQWwQSfmARXhBZeWTbT3x3TWxhS0Zbfm5lfVV+ UrVnOgvSEn96aBNiWWxcaXt8aXRJWVVTe0dybQB8Ymxtf3z7GFNVWEl1aXp6bl4QVWsUfnx+bjQo IGV5HWZUH216eG1eb1Vt4GBiFRFgSmLBFlRAEXRLe3poVlJFTEBXZxpQUVAJUa5R+FMdUFtQeudQ GVZdR0dKU+hRQ+NZSVxd6FFD43E/2Uh7ex6kHa0eFTUUtlB/Hb1hYFFiRkVEVnNydmVkZlFRFTIy FRYyMlMdMhYVMjIVFjJQUFFQyK7JUkNRY1BHUBIQQalSUVdZVFGSUJxCGVxaVBtF6FEWEEJRY18Q QEhkX19PX1JfSUgqykh7HkCkDXsdpK29UG8dvaS9UUFpaWFgUQ1DZWZmZWR3dnNyV1ZzcnZlZGZj YkZFRFbsJDlXV1dWXE17awc0FwYq/a7JfGLPA0FZWFdBDG4SNNUk345QUlADrslT/1FlUEdQf1Ak EHCpUqlKUnFPTElXWVRRSZJInHoZdFpRklCcQhlcWkwbfehRFhBaSWNfd1F3qFQbRehRFhBDUWNf EEVJZN9fUV9fT19SXwZgP+lRi1BIex5ApA0Nex2krb2mDaStvVBvvaS9b72kvVFBQmlpQUJpaWFg UQ1DZWZmZWR3dnNyV1ZzcnZlZGZjYkZFRFZVZWZmZWR3dnNyV1ZzcnZlZGZjYkZFRFYlNyZWU1VV W3Bgagc0GQMr9lF+NyZWU1VVW3Bgagc0GQMr9q7JYXbzCENZVldHDRATNtok1ocRYXbzCENZVldH DRATNtok1odQV1Brr5dXlFU7UFNQQVB5UGdQH1ANUCVSTBBaV1FHUVJoXxhfUuhRXhBBWFBRUf9S U0RSUlM6bAcObADqUS5QB1NB5lEUbGFobHroUS4QW2FQU1NUTmxbQmxU6FEu5F9bUVth6FNB5FFR Ulwn6K+Q515JZCdHR0oE7FFvUCBRalA0UW/iCgZ+7FFvUBpRalBuUW8QTGQQQUVkZNBoZWTQZWZk b2QfZFIfZFFkNFhQ/1PoUu8QXFhR/wBSMFJSUhFeWOxRb1B0UWpQSFFvEFteEFtdZF5JJv3dSHse QKR7Ha2mvUCkIr1Apr1Apg0he3t7raatpq2mrR4VNRS2e1BvbB1AtH8Nrb1AvUBsQGxArb1AvUCk rb1AvddVfnstQJRhYEgTKRCOVSUCdSIhIyFSVj4/PT9SVjIzMTMwM1NWDHY2NTc1ODVTVnx1HBsd G1JWbG1rbWptU1ZmdnJzcXNSVkZHRUdER1NWQHZKSUtJTElTVhBvEW8Sb1NWGBkXGRYZU1ZWdXZ1 d3V4dVNWJAEgcVE8BiBxUQ8NNHFQOQg0cVAeexpxUWlnbnFQcFp0cVFDQUhxUE1cSHFQE2JucVAV YBpxUXlVdHFRIQMlcVE/BTtxUDMLDnFRNQk6cVAbfR9xUW1laHFRc1lPcVBHX0JxUUldTnFQb2MU cVAZfxRxUHVXQnFRUHt7e3t7e3t7e3t7e1F7e3t7e3t7e3t7e3t6e3p6ent6ent6ent6e3p6envR UCFRDVFRc1FxYkZGRURWc3J2ZWRmZkdyV1ZXVkVER0ZHRmNiZ2ZnZmVkd3Z3dlFiRkZFRFZzcnZl ZGZmR3JXVldWRURHRkdGY2JnZmdmZWR3dnd2dWJGRkVEVnNydmVkZmZHcldWV1ZFREdGR0ZjYmdm Z2ZlZHd2d3ZUmqwC11PhrXkewhzg0C3jBMcXQF5HVl5fWEdbQ0BaRlZcXFdFW1I8AcEf7SI9lB/F HENbRFVBXVdDXERDXERWXV9WQ1tSxgHCHZM8Iu0A3wBCXEVVX19XQ1tERFpDVV9eV0RaVTuqDFX0 Cvgz4ZGW9zj8BmJdRnk2nClvc0VaWkR3F/jkF3tDW602C/g05Ozm5zz6BGBaQnYhyM0bd0FbW0R2 CercA3RCWX4J9DSU4Oz/OfsGf1tDdTT2wQh1QVtaQXci9t0AdEJar69QQFBQVeBXS1J2UHRQUFFX UJVR2FHYUE7lUuB4UXhA6K+85Dh7UlF66lLJUHlRfNVQe1F7DWWvr1B5UFBUqldLUnZQeFBQUVdQ lVEDUdhQTedRYGUfZVJleuiuTOQ4e1FRZ+lSyVB5UHtRew1lUK+vUEBQUFXgV0tSdlB0UFBRV1Dd UdpR8VBOEF5SeBBAQ2R4X1AYe1JRdupSyVB5UXzVUHtRe3tlr69QeVBQVKpWjFJ2UHhQUFFXUN5R B1HUUHsQTFJRMBdRYBcQF9AXwBeAF7AXVlAXZXF6EFFSUmjpUslQeVB7UXsNIWVlUK+vUHlQUFSq V0tSdlB4UFBRV1ATUQVR8VBH41FRY3rorkDkGHdRUWXpUslQeVB7UXtQr69QeVBQUr5XS1J2UHxQ UFFXUN1QZVHxUEUQWVFyW0QYe1FRcelSyVB5UHtRe2VQr69QeVBQUr5XS1J2UHxQUFFXUJVQY1HY UEYQWlFQdXFbShBRUXXpUslQeVB7UXtlr69QeVBQUr5WjFJ2UHxQUFFXUN5QZ1HUUGcQS1JR739R fxB6fmR/EHF0ZH8QSEtkfxBeQWR/SuivdOUYe1FSUnbpUslQeVB7UXt7e3t7ImVlUK+vUHlQUFK+ V0tSdlB8UFBRV1ATUGRR8VBH4lFySuivvOQYe1FRc+lSyVB5UHtRe2VQr69QAK+xVaBXS1J2UGJQ UFFXUN1RmVHxUHAQWlJfcg9y33JTclDor6zkGHtSUXDpUslQeVB7UXsNZa+vUACvsVWgV0tSdlBi UFBRV1CVUZdR2FBFEFpSUXJQWjh3UlF06VLJUHlQe1F7UK+vUACvsVWgV0tSdlBiUFBRV1ATUZlR 8VBFEFpSUXBQeBh3UlFy6VLJUHlQe1F7UK+vUGCvsFX0V0tSdlBoUFBRV1DdUSNR8VB6EEhRYhBF R2RiEExPZGIQXEFkYltOGHtRUWDqUslQeVF81VB7UXt7e3tlr69QYK+wVfRXS1J2UGhQUFFXUJVR +VHYUGQQcFFiEEtPZGIQW0Bk72JR32LvYlKPYq9iUmJbUDh7UVFg6lLJUHlRfNVQe1F7DQ0he3tl r69QYK+wVfRXS1J2UGhQUFFXUBNR9VHxUHIQQVFPYH9gUi9gUWBbfBh7UVFi6lLJUHlRfNVQe1F7 DSFlUFFQelBQUnNT91BAUMkQRI9CUV9VUFZQQE9VQFZAQFZbdE9W6FG+5HJRdE9V6FG+5HNcdE9A 6FG+EExzUEBWVlVaUF9RT1FSUXpcMFsgW1LgW1HfW1Fb6K+Q43ByZFvor5AQW0NGZFBbQFtSWytC 6K+QEEVERmRPQjBC4EJTf0JvQt9CU0EekEh7QA0he6YNe3sNISJsrQ1sUG9sb2x7e3tRDWFgUQ1R QURGR0VxZWZnZmVBZHZ3ZVHifhOuV25ORH4SU/etSzNnVHR0UnJHM1JyM2dUdVBRUEVURVLHVcNQ VlBm4xhTUVHsU09QVVNPUFNRTxBfVlNTEFFRUb74VUlXAsZIex5ApB0mrQ1JaX9IUH+9vLxhYFAN UUNzd1dzQ1Gcmx2+pQKFVcOu0p6YUShQUFFQRFQSUstVClBIUALkUVBcXVDoU0HjQEbCVu1TQVBd UEBRT1BZU0UQSl1QklR8X1FPUVJRZ0pc/l58XUlJSr5xAsZIe3sepB2kvUCmDaS9UH+svUCkvUC0 QGxAbGFgUWNGRURWc3J2c3JWV3N2ZmNiR0ZHRmNiZlI1ZVEsCBGVcU54WGpULw1OREwUN3xGeFUI RF4+1g54ZNLEVlhwf3RQUFJQ1FOqUndVzVBbUEdQCOdbVUtVUlYwQuhTc+VfX09fUl/oU3PlXDBQ UzBF6FFq51Z8UEJAQlJC6FFq4l8wWeivkOZbXWRZSUgq6VFIUEh7HkCkex2tpg20pq1Qfx2tpg2m vWFgUQ1RYkZFRFZzcnZlZGZHclZFREZjYmZlZHZRBQgqKwcGKyoIaB0eZ2YeHVXNKgcHKysHByod HWdnHR1nZx1QUVDBri5RtVBcUEFQBRBAQUhZXWTLQVFAQV5bUv5QWehTQRBcW2xaUFpS9lBb+15R 6FG351BV8F5gUElC6lHlUdtQSHseQKQdpL1ArR1AtEC1UG9/vbRAvVFBQmlpYWBRDXt1Y1dGRkVE VldWd2VmZmVkdnNRBxJ/bG9uYBzKNBd/fFwZWh1qZAZBSVF/VGliTnhQUFFQRVRFUsdVw1BWUGvj F1NRUe5TT1BRU3BQVVNPUFNRTxBfVlNTEFVRVb74UUlXAsZIex5ApB0mvQ1JaX9IUH+9vL28YWBQ DUNTY0dnY1OPmhy/pQKGVEVRLp6YrthQr69QOq+wVHFXcVJ2UGZQUFFXUJlQjlHeUE8QQlFfbU9t D20/bVRtYWI4e1FREOlSyVB5UHtRew1lUK+vUBWvtFKEVcNSdlAGUFBRVlCZYFBQcRBDUWYQQ01k f2ZvZlJme144e1FRaelSylB5UHtRew17ZVCvr1BxUFBVYldxUnZQbVBQUVdQmVEEUd5QTedREEiv SFJIROhRpOQ4e1FRS+lSyVB5UHtRew1lUK+vUEVQUFM8VcNSdlANUFBRV1CZUMdQUFByEFtRsEag RlJ/RlFGWuhROOQ4e1FRSelSylB5UHtRew0NZVBSUM+uFlFxVTtQU1BXUBbhVlXoUS7iVFNQ6FEu EEtRV1ReUlFRWTtSU1NWVldvVFFQUFVUO1gqykh7QKRsbEBsQK1sQGxAbLZQb2xvbECtbECtbGFg Q0FjQVNBY0HP0tLSUsFSiq12q+VSi611UFJQc1BQVSlVHFBPUGNRThAkN0U4TMdFykroYFVwcnBz N332R/ZKVU7QWVpke9BZWmRE0FlaZGPQWVpkM15XcE1QcnJccE1CcnNyWnhzWUBZEFkgWdBZVFl6 cGNlQ0NCUnplT09QWFofZHNzZGVCSEplcF91T3VSdW5ckFeAV1JXSWRtCEh7HkCkDWwdrQ1sHkCm HRMI5lB+QH5Sfh25DUvhfh29CUFCaX9AtlBvbEC9b2xAvUFCaQ1/bK1se3thYBsDKeEOWBMpEBp7 Y0RORkdFR1JWYH9hf2J/U1ZGR0VHUlZgf2F/UlZKSUtJTElNSVRWfHVjRH51UWJEfnVRe05+dVF/ R3B1UX9HY3VRYmN9SXp1UHtAbHt7UXt7e3t6enp6etHRUXt7e3sNUA1jZWNiZmdmZUFzZWNBZHZ2 c3NlcWJHRkJFRF5SV1ZzU1NxRXFDREZHRmNiZ2ZBQHd2d3ZzfWtvX1qQkEcTaX1SMKPE5eoLw+/a bNMKUVF9roNRQEJMYvcJJwIQNhh1dXBGOFHuGlEkOGR3dRIBruif36HND0pcVK+toRquZwR2Wl8i ylEUUVXMKnxPUFBSUBqvtFPnVTtQT1BhUIfnX1VXWUdZU0Xor6gQKF5AZEFYXkBkU1NVWVlXWlpS UFxcXVtbUVNWUFJaVVZVVkdOTVxZUFV+dE1wXFlVUFRaS1tRW1pRFkJSUlpRUlFSdEdaW19+W1JR U1pLVlFaUXB2S1Z5dkNbfhBfShBjUWNfdE90UnQQYEcQR1IAR4BHUkdJYmghSHseQKQNDR29DR5A DaYdrVBvvW+9b29BQkdpUUFCaWlBQmlpWNd+e1gtQJRQQUJHaUJpUUFCR2lCaWlQQJlfV0BYbF5s V0BYbFhsYWBRe3tQDVFXd2d2d2dGRkdnR1dGQkVEUlZzcnZ2ZWRnZmNiR3Z2V3JWVkVAR0ZGY2Jm Z2ZBZHZ2UYercaAYIkcfOR68T4Hp5jie0C6eOwM4km0GcWNVfRB1Q1wUfHwSXkNyblQm3GnXHQFz Tmhm1Wokxq7jl/Wur9LQsNrh0vJNBQyIYSv/rrsDamlnbQJRUJIuYK+vUEJQUFXgV0tSdlBsUFBR V1DdUedR8VB1EFtRUGFRYRBbQWRhdeiv6OQYe1FRf+pSyVB5UXnVUHtRe3shZVCvr1BBrhZTvVUq UnZQDFBQUVdQ3VC2UFBQchBFUV9hL2HfYe9hn2FVUGFhVUUQUVFh6VLKUHlQe1F7DWVQUlB5UFBU zVUcUH1QaVDdEGHIVPlU9lhTD2r4YflmU1B+f1tcTHBNRHJyfXBNdXJyXHBNQ3JzTXBNdHJzf35f WlFa6FF25kRpflBRUVHoUXYQSXV0Q0R0UkRYZI5WSmt9X1xPXFJcfU1MLWroUQrhCEh7QKZsrQ1s HkCmHb1Qb29AbEBspA29QKQNvXt7e3tTQFVsbGxsYWBRDVANUWNiR0ZGRURWVnNzRURGR0ZjY0Vx ZWNiZ2ZnZmVBZHZ3dnNzZXFFc3JXVldWRUVBYmZnZmVkdnd2c1JOGOkz0MsghqIXREx1aHutA2Fv dElaVUVKdWt9Uv19EHNJWlXcN0t0F2t8PFROSXHo0DvkCm4nYkBHdXVLQnVCCVMmJ2VfRnNzSUJ1 RDrbreFjZBkrOttLRFBQUlB3rhZUSlU7UHJQf1CzEHrLdPt063RTx0jJTlJ/WEN/c1BRX1ZQV1BB T1ZAV0BBVlF0T1aVc1x0T1foUb7kcl10T0HoUb4QWnN9NkdIRkZHV3/qUQ9QQ1KOEH5CQkFQc6dQ KXXoT3BOTk9bV1ZeQHlReRBLSmFCX1FPUVJRelxcgF1RXUlgHiFIex5ApA1sHUCtDWweQKYdvQ1Q b2xvbEBsQL2kvW9sQKS9b2xAbEC9e3t7UQ1TXkBsbGxsYWATKRBwdnxITkl1e3ZNdnd1fEh5d1F2 Tnl3UXpKfXdReEx1d1BQe3tRe3t7e3t70dFQDQ11QURGRmNFcWVmZ2ZlQWR2d2VxQWZnZmNiRkZF RFZWc3J3dndGY2JnZmVkd3ZzcldR/0dgFq27bk5EfhJR2GFjGQY3+QgL/TodE2JnBjJmc2RpdhA1 EQ+u9BplSHZ2UnFHM1XwM2ZUda2RGHB/0rXU3rsrckr0KmkEvKIJa8JQUFFQylCmU6xUCFBbUIAQ d1RQVVNYUVBVUllXWFNbVlpbVllSUnxWU3xVWFNQfFhbfFlWW1JZWeivsBBMSH1kWW9YU0RYWFNQ VVVwSH1kVW9WW0RWVltZVehTReJWUlDrU0VQU1BbUm7jWFZZW+hSbuRSVhFVU+hSbhBdcFBQWMBY UlBYcFhSWOivkONBRWRY6FKd41wqykh7SUCmew0hSGxKSa1IbEmkbK1IbFB/bEmtbK1IbElArUhs 115+e3teLUCU115+SHt7Xi1AlFFYQLBAsFhAsECwX19fX2FgQ1FRR1FRV1FRd1FRp1EEUQQMrv1R BA2u/K7+DFEBrvxUCK78UQMMrvyu/A1RBK7/DFEBUQVQUFFQGlLIUkRVOFBKUCHjQelkWehRTeRy UelkWO1RTVBzUElRTVBCUpLiSGRJ6FL6EF5KSlFBSFhJSkZZUFhRWOhRLuRKUFVQUehRM+RC0EFR QexR8lBLUD9R3lBIe0CmDWytbFBvbB2tDWxBQmlCaVFBQmlQQKW9rFGle3thYFFBREdGRmNjRXFl Y2JnZmdmZUFkdnZzcld3dVHOV1Vxe06uEnFkRF1VWVhGQUxjQlFhVTitkxJDXEJwcFpXW0USUTd+ Rl5ETylQUVBIUshSZVU4UEtQ6xBwmVJRUFDpU5FEU5REg0SzQ7NEoFBV4UPhRJRDU0RQUVvoU0IQ W1paUVhKEEsAS1JL61NFUEVQUlNN51FE/0XvRVJF6FIj5FFQUFFQ6FEuEF5YG15VUGNKkl9LUUtj VepRM1BBUXsQXlqSW2BR/1JRUmdMAt1Ie0CmDWykva29pCG9tFBvva0NbK0NbEC9QKQNbEFCaX+0 UUFCaWFgURvgTAMb4HwBCgjrUESvnlBDr55oaAlRDQ0hUA1RcWVmZmVkdnNyV3dmZmNiRkVEVldj YmZnZmdjUleuQbMCFGQFYXpw1gw40DeQyBl0QlVTflLIQrvGEGMVAl01NSIVbffyQnJaVFBQUVBf UtlSelU4UHhQhBBFd0L3X+h4mHiNeL14VldCR0JSQlBb6FNCEF9aWhBdQGRaR1hRklBQXU7oUTMQ WXPSR1gbUEdRR+hRLhBdXVVQUVFbcFVRIFVRVehRqOVAQHBAUkDoUoIQS0Rakg9bz1v/W49bv1tV f1tRW2BLcHZRIHZRduhRqBByYEQQRCBEz0RUf0RvRFJESno/S1FfS59LUk9LUUtJeYDdSHtAtiIh DR5ApiENHb0NIUCkIQ29QKQhrQ0hQWl/bFBvvQ29QL29Qml/vUFCaXt/tEFjUQ1hYFENQ2VmZ2Zl ZHZzcld3ZmNiRkVEV0ZFRFZzcnd2ZWRmY2JHRkZjYmZlZHb/B0d+bmMcankK4w4/Mdbm8SBicnxy RUZbPX93ZztTpUtFRHZkeGofXuQPawNkbyU58XFHcEl2WVQfaXsTI1BQU1AYr5VVnVU4UEpQTlBq URMQTlBPlmKUY1MwY+BjkGKQY4VitWKgT6RipGNZX1hRSepRTVBCUpLiSGRJ6FL65EpB6WRZ6FFN EH1yUelkWM9zTktMTP9NTkRNTU5IWUlGSkpCUEtOYHpMTVFBS05VTE1dWVBYUVjoUS7jUEpVeuhT QhBZeXlwd/9ffVF96FEu509qEGkAaVJp6FNF5mP/ZO9kUmTrUiNQT1BxU00QXE9wY2NwT3BxYHmS eupRe1B0UTMQQVBgUWBjaZJqY19PUU+obFBR61EzUEJQQVHy42s/3Uh7QKZsrWxApiGkvaQhva29 pGxBQml/UH9svUCtDWykDWxArQ2tQWl/tG9srQ1sb2xvbFFBQmlpQUJpaUFCaVBBQmlBaddVfnvX LZRIe3tApb2sUaUNYWBRG+BMAxvgfAEKCOtQYq+eUGOvnmhoCVENIVFBREdGRmNjRXFlY2JnZmdm ZUFkdnZzcld3dXFRc1FRcWVmZmVkdnNyV3dmZmNiRkVEVldjYmZnZmdjUcxXVXF7Tq4ScWREXVVZ WEZBTGNCUWFT+6xt2VOUUVOuQbMCFGQFYnlw1gw40DeQyBl0QlVTflU4rZMSQ1xCcHBaV1tFElE3 fkZeRE8pqg1V86o5Q7vFEGQUAl40NSEVbfjyQnNaVFBQVFAYr5VVh1U4UEpQTlB5UHxRaRBIX1hR dXR5dnFyc3p2cXt8d3pzeHd8eXRJ6lFNUEJSkuJIZEnoUvrkSkHpZFnoUU0QEHJR6WRYz3NOS0xM /01ORE1NTnp8fANwT0RwcE98enBIWUlKRnp4T3BxfEpCUE55S3xxTE1RQUtOVUxNcV9wUXDoUS4Q THdzcnJ7e096IHl5eHR1de94UXgXd3d2WVBYUVjoUS4QXUpQVU959Hh8e3t4eHfoUTMQX3ZzdBF1 cXJ1dqh+UFFCUepRM1BBUfLjfT8zSHtApr1sQGxApmxsbECkbECtbEBsQGxApGxQb2ytDWx/bECk DWxAbEBsQK1sbEBsQGxArQ1sf2xvbFFBQmlpQUJpQWlBQmlBQmlBQmlQQUJpQmlBQmnXfntVLUCU 135Ie9ctlEh7e0ClvaxRpV9fX18NYWBRQURHRkZjY0VxZWNiZ2ZnZmVBZHZ2c3JXd3VxUXNZUmNB Y0VzRXNlcWdjZVHMV1Vxe06uEnFkRF1VWVhGQUxjQlFhU5OsbdRT766tUdELGhrkrogDhVU4rZMS Q1xCcHBaV1tFElE3fkZeRE8pqg1V86slUZauaiHLyyGpUFBUUF2vlVWHVThQeFB8UGdQalHMEEP3 X7x4UnZCi3hS5UFRd1hARWRc6K+oEDBfQmRUQkRCUkJQYGR/YWhjZH9nYmZlamdiaWhhZWp8eXp6 /3t8RHt7fGpoaBZ9fkR9fX5qaH5oaX18Z3l/antLekR2fn9qentbeXxVWh9aD1o/Wi9aVFpHWH1o f19+UX7oUS4QS2VhYGBpaWggZ2dmYmNj72ZRZhdkZVHmUFBdTuhRM+Vz0lBHUUfoUS4QXlg1XVV9 Z/RlamlpZmZl6FEzEEtkYWIRZH9gYGNkwGxQUVFVWuZQW0BbUp9bUVvoUXvmcFVRIFVRVehRqBBZ QGNwdlEgdlF26FGoEF9fRFF/RG9EH0QvRN9EVUToUZAQWe9LUUvMa5HeSHtApg2tIQ29DSGkvQ0h rSENvUJpf2xApmxsQGxApGxArWxAbEBsQKRsUG+9rQ29vUJpf71/bKQNbEBsQGxArWxAbEBsQK0N bEBsQUJpDX9vbG9sUUFCaUFCaUJpQUJpQmlBQmlQQUJp11V+e1QtQJTXVX5Ie9ctlF9fX19QQWNR DWFgUHt7USENDUNlZmdmZWR2c3JXd2ZjYkZFRFdGRURWc3J3dmVkZmNiR0ZGY2JmZWR2UVFzWVJj QWNFc0VzZXFnY2X9B0d+bmMcankK4w4/Mdbm8SBicnxyRUZbPX93ZztUTKxt1FPvrq1R0QsaGuSu iAOFU6VLRUR2ZHhqH17kD2sDZG8lOfFxR3BJdllUH2l7EyNR2qoNVfOrJVGWrmohy8shqVBRr71V 5lRDVmlQU1Bw6VBQUaPmU1FKVVBJVOpRwlFJUEh7HkC0QLZQfx2tYWBTcUVxQ1R2q4pWadNQUa+5 r7RTj1U4UGBRDRBN135R13BRUVd9UURXQlF4Ulh9SH1SaVFFVhBIU1Por5DjSXRkU+ivkBBpWVxk U1FOfxBLWFFIURhRCFFUXlBRUXtYdnJ4eBBZX2RYeEh4eHhTQVB4ezoQclVYXUhdUmVSXVxc6K+Q 40ZMZFzor5DjYWRkXOivkBB5XkFkV1xHXFL3XOdcp1xTV1xHXHdcU1lQXFhYEBllWDpBXVVUUGBg U3joUcXlEHddXF1d6K+QEF9ZTmRdYn9WWFNIU1JZUFPoU1oQcEkQWE5ITlJHU0VOSVhJUWFQSRBD RWRJSWFGTEdNpaFIe39sjWxAtHtRDw4NQWNjDw4NSkhAHa0PDg2VlECWe1FBY0hAhkodvUJpf52G nVBvvXtQSECWDw4NISJ7e3tQQWMPDg1Ib0odrZYPDg17UEFCaUFCaUh/Dw4NbEqNbECWe3tQQGxK SI1sYWAPDg0PDg1RDg0PDQ1RcVZFcVdxQmNiZ2ZnR1ZXVnNyd3Z3c2djZWRnc2djZmdmY2JHRkdB c3Z2c3JXVldxUwKuf1NR7keuC0K9Ihx3HX4AbDr2vdY/QzVHGlIzRwRywPK3PQJID3db1DwtHW1F UbJSsXp5Hq5SGXUsc95mMZHwqx5ATnUet/DiTllhroXc9c8vmVBQUlBQUFBQUK9xUJNQUFBQUFBQ UFBQUFBQUFBQUFBQUFCOUFBRUlFTUFNQVFBVUFZQV1BYUFlQWlBbUFxQXVBeUF9QQFBBUEJQQ1BE UEVQRlBHUEhQSVBKUEtQTFBNUE5QT1BwUHFQclBzUHRQdVB2UHdQeFB5UHpQe1B8UH1QflB/UGBQ YVBiUGNQZFBlUGZQZ1BoUGlQalBrUGxQbVBuUG9QEFARUBJQE1AUUBVQFlAXUBhQGVAaUBtQHFAd UB5QH1AAUAFQAlADUARQBVAGUAdQCFAJUApQC1AMUA1QDlAPUDBQMVAyUDNQNFA1UDZQN1A4UDlQ OlA7UDxQPVA+UD9QIFAhUCJQI1AkUCVQJlAnUChQKVAqUCtQLFAtUC5QL1DQUNFQ0lDTUNRQ1VDW UNdQ2FDZUNpQ21DcUN1Q3lDAUMFQw1DGUVRQzVDOUPBQ8VDyUPNQ9FD2UPlQ+lD7UP1Q/lD/UOBQ 4VDiUONQ5FDlUOZQ51DoUOpQ61DtUO5Q71CSUJNQlFCVUJZQl1CYUJlQmlCbUJxQnVCeUJ9QgFCB UINQhFCFUIZQh1CIUIlQjVCOULFQtFC1ULZQt1C4ULlQulC7ULxQvVC+UKBQoVCiUKNQpFClUKZQ ilFVVX4+JTw8QD4/Pj0xIjs5PjciNSQlIj5TPSVhVyU+OWJgERNQUFBQUFBRUFBSplBRUCxR0FBW UThQU1B0r99QU1Bnr4tQU1Bpr4tQU1Bqr4tQU1Bsr+RQRFBEr99QdFBTr99QdFBnrzhQdFBprqhQ dFBqr01QdFBsrxRQdFAJrzhQdFAKrzhQdFAMrzhQdFD5rzhQeVBTr+RQeVBfrxRQeVBBrxRQeVB0 rzhQf1BTr99Qf1BnrxRQf1BprxRQf1BqrxRQf1BsrxRQf1AMr99Qf1D5rxRQY1BTr99QY1BfrxRQ Y1BBrxRQY1B0rzhQZVBnr+hQZVBpr+hQZVBqr+hQZVBsr+hQZVAMr+hQZ1BTr4tQZ1BfrzhQZ1BA rxRQZ1BBrzhQZ1BNrzhQZ1BOrzhQZ1B0rzhQZ1Bir4tQZ1AUrxRQZ1AWrxRQZ1AYrxRQZ1Acr4tQ Z1ACrxRQZ1AFrzhQZ1AGrxRQZ1AIrxRQZ1AKrzhQZ1AMrzhQaVBTr4tQaVBfrqhQaVBArzhQaVBB rqhQaVBNrxRQaVBOrxRQaVB0rqhQaVBir4dQaVAUrxRQaVAYrxRQaVAcr+RQaVACrxRQaVAFrzhQ aVAIrxRQaVAMrxRQalBTr4tQalBfrxRQalBAr+RQalBBrxRQalBNr99QalBOr99QalB0r01QalAU r99QalAYr99QalAcr4tQalACr99QalAFr4tQalAIr4tQalAMr+RQbFBTr+RQbFBfrxRQbFBArxRQ bFBBrxRQbFBNrxRQbFBOrxRQbFB0rxRQbFAUr01QbFAYr01QbFAcr+RQbFACr01QbFADrxRQbFAE r01QbFAIrxRQbFAJr01QGVAZUFBQGVD5UCFQBVBTr4tQBVBfrxRQBVBAr+RQBVBBrxRQBVAWr4tQ BVAYr4tQBVAbUFBQBVACr4tQBVAEr4tQBVAHUFBQBVAKUFBQBVALUFBQBVAMUFBQBVANUFBQBVD5 UHVQCVBfr99QCVBBr99QClBfr99QClBBr99QDFBfr99QDFBBr99Q+FD4rzhQ+VBTrzhQ+VAGr+RQ +VD5rzhQUFBQUFJQUVBQUFBQRFBTUFFQUFFMUFBRVlBQUVBQUFBQUFBRUlBQUFJQUFBQUFBQUFBQ UFBQUFBRUFBTVFVWV1hZWltcXV5fQEFCQ0RFRkdISUpLTE1OT3BxcnN0dXZ3eHl6e3x9fn9gYWJj ZGVmZ2hpamtsbW5vEBESExQVFhcYGRobHB0eHwABAgMEBQYHCAkKCwwNDg8wMVAyMzQ1Njc4OTo7 PD0+PyAhIiMkJSYnKCkqKywtLi/Q0dLT1NXW19jZ2tvc3d5Q38BQwVBQwsNQUFBQUMTFUMbHyMnK UMtQUMzNzlPP8PHy8/T19vf4+fpQ+/xQ/f7/UFDg4eLj5OXm5+jp6uvs7e7vUJCRkpOUlZZQUFCX mFBQmVBQUFRR0lBQUHhQcFBUUFhQLlCvUQNRMVEoUS5RwlKWUoxwRHBKcE5wcnB2cGBwanD8cXJy Sa+vUFBQcFDwUQJRMFEoUS1RwlKWUoxwQ3BIcExwcHB2cGBwaXD8cXJySa+vr7NQUK8ArzqvZK8f r1mtr626sMFQUFBQUFCwKLDUsCWwYY86jshQUVBQUHZQUFBQUFBQUFBQUFBQUFBQUIRQiFCMUFBQ UFBQUFBQUFBQUFBQU1DJUNRQ1VD9UMJQnlDWUN5Q21DEUMxQylBAUNpQjFDTUMFQh1CIUN1Qw1DY UOFQmFCGUMVQzVCKUIlQi1DIUM9Q51DlUPBQMlAzUN9QNFDpUDVQ5lDoUO1Q6lDrUOxQn1A2UJBQ 7lDvUPFQN1CFUMBQk1CRUJJQOFCBUINQ2VA6UDlQO1A9UDxQPlDGUD9QIVAgUCJQI1AlUCRQJlAn UIBQKFAqUClQK1AtUCxQ+lDHUC9QLlDQUNFQglCEUPtQ+FD5UOJQ9lD3UONQ0lDgUNdQUFBQUFFQ UVBRUFBQUVBQRFRQUFBEUFBQUFBQQ6xg0kOoVll61hjWp11RV1Lw0kO5YNJDtVJRUWFeYFxWWHrW GNanXVJVVVBgMVZae1ZRVFHSZ1JRVPADYAFgfFZae1ZRVFHSZ1JRTPJO0ExQbFBsUGxQH1AyUCNQ P1A8UDVQJFA1UG5QblBuYHFgWVZVe15TUkpVUFREKoBcykDl6lHaismiCXRJUQsOcsjw0l+CYNJS kGDSUnlSREPZ5IHauPeU7WWXy93Ymk+aAwbBYF1WWXrWGNanXVFRVFVQYNHOYU9gTVZTBVRaQ0YG NSI5Azk3PnAEIiUjJHAeNSQnPyI7YUdgRVZTBVRbQ14GNSI5Azk3PnxwGT4zfmF8YHpWUwVUW0Nz BjUiOQM5Nz5wBDk9NXADJDE9IDk+N3ADNSImOTM1cAI/PyRhZGBiVlMFVFtDex4fcBwZERIZHBkE CXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58cBk+M35gTkddaWdgZWFiYGdgYGBgCkddaWlhYmNh YGdgYGBgCmDRzmFPYE1WUwVUWkNGBjUiOQM5Nz5wBCIlIyRwHjUkJz8iO2FHYEVWUwVUW0NeBjUi OQM5Nz58cBk+M35hfGB6VlMFVFtDcwY1IjkDOTc+cAQ5PTVwAyQxPSA5PjdwAzUiJjkzNXACPz8k YWRgYlZTBVRbQ3seH3AcGRESGRwZBAlwERMTFQAEFRR8cHgzeWlncAY1IjkDOTc+fHAZPjN+YNHP YF1WWXrWGNanXVFRUVVQU9HdUGDR2VLR0VCDfnCgOCx8fX7RTOFW4vdb50FdB4oDiCWzmWN64oSm WQtko7nArllcgItLCumdt6bY4c2Q13W7LQhAIzoomyFFrZYIpnn7CA7GVK19MkEI0UyaIcSFcgh/ hZxEVdRm6sT65B0aub5rcv0GyS5xzDzWkBoXxzrk9maFrFl9g+Rpy1JTUVBRYF1WWXrWGNanXVFR VFVQU9HRUGpBzNVVboK50Ksrhfmk/CmsVazFbSFz+Xt4j9xDNdmufNdR3wrKMppB99Ck5+5E54EG yTtYMhWW8vWKZS9Vco4ifVTWVfcsWUbDRBOgp0Ydhlfey0A8CK5aZcea2c+PVCDMei0x3pG4WyHK +Jc2MhJtxcRyYshy2dqqNFh0pYKqYNJSnWDSUmZSRVDtQcqKE71xqxYI1NmaFtjAdb5EMGBdVll6 1hjWp11RUVRVUGDRzmFPYE1WUwVUWkNGBjUiOQM5Nz5wBCIlIyRwHjUkJz8iO2FHYEVWUwVUW0Ne BjUiOQM5Nz58cBk+M35hfGB6VlMFVFtDcwY1IjkDOTc+cAQ5PTVwAyQxPSA5PjdwAzUiJjkzNXAC Pz8kYWRgYlZTBVRbQ3seH3AcGRESGRwZBAlwERMTFQAEFRR8cHgzeWlncAY1IjkDOTc+fHAZPjN+ YE5HXWlnYGVhYmBnYGBgYApHXWlpYWJjYWBnYGBgYApg0fxhd2B1VlMFVFtDTgY1IjkDOTc+cAQ5 PTVwAyQxPSA5PjdwAzUiJjkzNWFPYE1WUwVUW0NGBjUiOQM5Nz5wBCIlIyRwHjUkJz8iO2FkYGJW UwVUW0N7Hh9wHBkREhkcGQQJcBETExUABBUUfHB4M3lpZ3AGNSI5Azk3PnxwGT4zfmFHYEVWUwVU WkNeBjUiOQM5Nz58cBk+M35hQWBfVlMFVFdDWBk+JDUiPjUkYNHNYF1WWXrWGNanXVFRUVVQU9Hb UGDR11LR0VD7Mb3k/d3AF8CM5EEOOYxaLzLAVmGdnq/YwRaHGWrEuYRWb8398igKvKmsMxUf6Fs+ YL/yZvt9WY+hP3f7XQEwVWUfL54EH4DnfBKIW4Dd6A6v5tCAs8bkL3IZEkA8g8jgUQbzk59+z2qk L/gI9odyNbXc+yjM7IkXEjgLfS2t5VJRU2BdVll61hjWp11RUVRVUFPR0VA9MKvJD/Q544MrIHsy c04UcAH/c0WXJFKpGaJ3Sgz81iFlWHum346w5ca42/cbsyOYGFnN4IrbikXCmlO1WXUGVrce9Bf1 gQcWhGgGpXGdk3ZrfXVinsuy7xAXuog9Fya1kGDzX9CeL4hrLvCpxXphe0WqmES9jeC5BREgFn18 LmDSWmlg0lny8FNSUVJSQB5u1D4HsMCAidscnHLTCR1gXVZZetYY1qddUVFSVVBgMWFBYF9WUwVU V0NYGT4kNSI+NSRhR2BFVlMFVFpDXgY1IjkDOTc+fHAZPjN+YWNgYVZTBVRbQ3oGNSI5Azk3PnAT Pz09NSIzOTE8cAM/NiQnMSI1cAAlMjw5Izg1IiNwExFgTkddaWdgZmBkYGBgYGBgCkddaWhgZmBk YmNlaWVpCmDSURVhQWBfVlMFVFdDWBk+JDUiPjUkYUdgRVZTBVRaQ14GNSI5Azk3PnxwGT4zfmFj YGFWUwVUW0N6BjUiOQM5Nz5wEz89PTUiMzkxPHADPzYkJzEiNXAAJTI8OSM4NSIjcBMRYRZgFFZT BVRbQ20nJyd+JjUiOSM5Nz5+Mz89fyI1ID8jOSQ/Iil/EwADcBk+Mz8iIH5wMilwAjU2fnwcGRES fhwEFHgzeWlmYWtgaVZTBVRbQ2IUOTc5JDE8cBkUcBM8MSMjcGNwfXAdOTMiPyM/NiRwAz82JCcx IjVwBjE8OTQxJDk/PmFbYFlWUwVUVkNSBQNhQWBfVlMFVFhDWBk8PDk+PzkjYUpgSFZTBVRXQ0EV PDtwFyI/JjVwBjk8PDE3NWFxYE9WUwVUU0RIHT8+PyQpIDVwBCkgPzciMSA4KXxwGT4zYAxgXVZZ etYY1qddUVFRVVBTG1BgGFIRUPJ1DhADo6cjbagWN8hLhgiatxj/k4icYudmzZTgpSnyrjbS5DRr +31dW/GZLoQTma5QwP0Ss4IIRPypeJiBPzVSU1FQUfPSVx5g0lcaYFlWUwVNQ1RSYFBgW1ZTBU1f VFRTUlXwYNHYVlMFTVFU0dBgLtBAK8a0gROtOMijaJw+a6Jb0vEzYDFhQWBfVlMFVFdDWBk+JDUi PjUkYUdgRVZTBVRaQ14GNSI5Azk3PnxwGT4zfmFjYGFWUwVUW0N6BjUiOQM5Nz5wEz89PTUiMzkx PHADPzYkJzEiNXAAJTI8OSM4NSIjcBMR0lVS5FBQUWBxVlMFTVRRUa9UR2BEYF5gXFZae1ZRVFHS Z1JRRlNSV9BQYF1WUwVNWlRWYFRTUlYQYNJUZlZae1ZRVFHSZ1JRWlFRr1TSVHNg0lRP8HnQdzgk JCAjan9/JycnfiY1IjkjOTc+fjM/PX8iNSA/IzkkPyIpfxMAA/HSU+jR0lPkBDg5I3AzNSIkOTY5 MzEkNXA5PjM/IiA/IjEkNSNwMilwIjU2NSI1PjM1fHAxPjRwOSQjcCUjNXA5I3AjJCI5MyQ8KVoj JTI6NTMkcCQ/fHAkODVwBjUiOQM5Nz5wEzUiJDk2OTMxJDk/PnAAIjEzJDkzNXADJDEkNT01PiRw eBMAA3laJjUiIzk/PnBhfmB8cDEmMTk8MTI8NXA5PnAkODVwBjUiOQM5Nz5wIjUgPyM5JD8iKXAx JGpaOCQkICNqf38nJyd+JjUiOSM5Nz5+Mz89a3AyKXAVfT0xOTxwMSRwEwADfSI1ISU1IyQjECY1 IjkjOTc+fjM/PWtwPyJaMilwPTE5PHAxJHAGNSI5Azk3PnxwGT4zfnxwYmVpY3ATPzEjJHARJjV+ fHAdPyU+JDE5PnAGOTUnfHATEXBpZGBkY1oFAxFwEz8gKSI5NzgkcHgzeWFpaWZwBjUiOQM5Nz58 cBk+M35wcBE8PHACOTc4JCNwAjUjNSImNTR+cBMVAgQRGR5aBxECAhEeBBkVA3AUGQMTHBEZHRUU cBEeFHAcGRESGRwZBAlwHBkdGQQVFH5aWgcRAh4ZHhdqcAQYFXAFAxVwHxZwBBgZA3ATFQIEGRYZ ExEEFXAZA3ADBAIZEwQcCXADBRIaFRMEcAQfcAQYFVoGFQIZAxkXHnATFQIEGRYZExEEGR8ecAAC ERMEGRMVcAMEEQQVHRUeBH5wcAQYFXAZAwMFGR4XcBEFBBgfAhkECVoUGQMTHBEZHQNwExUCBBEZ HnAZHQAcGRUUcBEeFHAVCAACFQMDcAcRAgIRHgQZFQN8cBkeExwFFBkeF3AHEQICER4EGRUDWh8W cB0VAhMYER4EERIZHBkECXAfAnAWGQQeFQMDcBYfAnARcAARAgQZEwUcEQJwAAUCAB8DFXxwER4U cAcZHBxwHh8EWhIVcBwZERIcFXAWHwJwEx8eAxUBBRUeBBkRHHxwAAUeGQQZBhV8cBEeFHATFQIE ERkecB8EGBUCcBQRHREXFQN+cAMVFVoEGBVwEwADcBYfAnAUFQQRGRwDflpaEz8+JDU+JCNwPzZw JDg1cAY1IjkDOTc+cCI1NzkjJDUiNTRwPj8+JjUiOTY5NTQDJTI6NTMkESQkIjkyJSQ1I1o1KCQ1 PiM5Pz5wJjE8JTVwIzgxPDxwPj8kcDI1cDM/PiM5NDUiNTRwMSNwMTMzJSIxJDVwOT42PyI9MSQ5 Pz5aJjE8OTQxJDU0cDIpcCQ4NXAZEX5a82bQZDgkJCAjan9/JycnfiY1IjkjOTc+fjM/PX8iNSA/ IzkkPyIpfyY1IjkjOTc+PD83P343OTZg0lJPVlMFTVNU0lJGYNJSQmDSUl5g0lJaVlsw1hhR1qgV UVdRUWDSUalG0lH3BDg5I3AzNSIkOTY5MzEkNXA5PjM/IiA/IjEkNSNwMilwIjU2NSI1PjM1fHAx PjRwOSQjcCUjNXA5I3AjJCI5MyQ8KXAjJTI6NTMkcCQ/fHAkODVwBjUiOQM5Nz5wEzUiJDk2OTMx JDk/PnAAIjEzJDkzNXADJDEkNT01PiRweBMAA3l8cDEmMTk8MTI8NXAxJGpwOCQkICNqf38nJyd+ JjUiOSM5Nz5+Mz89fxMAA2twMilwFX09MTk8cDEkcBMAA30iNSElNSMkIxAmNSI5Izk3Pn4zPz1r cD8icDIpcD0xOTxwMSRwBjUiOQM5Nz58cBk+M358cGJlaWNwEz8xIyRwESY1fnxwHT8lPiQxOT5w Bjk1J3xwExFwaWRgZGNwBQMRcAQ1PH5we2FweGRhZXlwaWZhfWhoY2BwEz8gKSI5NzgkcHgzeXBh aWlmcAY1IjkDOTc+fHAZPjN+cHARPDxwAjk3OCQjcAI1IzUiJjU0fnATFQIEERkecAcRAgIRHgQZ FQNwFBkDExwRGR0VFHAxPjRwHBkREhkcGQQJcBwZHRkEFRR+8F5WXDDWGFHWqBVRV1FRUfFeVlww 1hhR1qgVUVdRUVJgfGB6Rng4JCQgI2p/fycnJ34mNSI5Izk3Pn4zPz1/IjUgPyM5JD8iKX8TAANw YEZWWntWUVRR0mdSUUtUWGBWUVGvUVGvYF1WWXrWGNanXVFRUlVQU9HRUNClDjfKHbYJTl6b64ye Ja1mt/bHsC4XKMxVU/TDRnJH7IeXybMUqnWp+1IPXYY+rISIlo5eKLO/KXKBRqTTeJi4Fq0qbG7j uOl+hbSLvRLLpaiD57QtiPi/M3zVwFWeQhVphzLaVk6tLZUYrQo7gBMMf57BLGq+Cn1kIfGAyHTS YdJTxWDSU8FSUVFgJWAxYUFgX1ZTBVRXQ1gZPiQ1Ij41JGFHYEVWUwVUWkNeBjUiOQM5Nz58cBk+ M35hY2BhVlMFVFtDegY1IjkDOTc+cBM/PT01IjM5MTxwAz82JCcxIjVwACUyPDkjODUiI3ATEVJA Hm7UPgewwICJ2xycctMJHWBcVlh61hjWp11SVVVQ8NGxYElWWXrWGNanXVFZU2FcVlp7VlFUUdJn UlFUYExWWntWUVRR0mdSUVthXmBcVlp7VlFUUdJnUlFGYE9WWXrWGNanXVFZVGFCVECJKx4G0geT sBor8baTsSnnYNHUVlp7VlFUUdJnUlFcYSZgJPAG0ARQBFA5UD1QNVAjUHBQElA/UDxQNFBwUB9Q IFA1UD5QBFApUCBQNVBwUDZQP1A+UCRQcFAHUDlQPlBwUBFQHlADUBlQcFAzUDhQMVAiUHBQI1A1 UCTxStBIOCQkIGp/fycnJ349Pz4/JCkgNX4zPz1wYF1WWXrWGNanXVFRUVVQVBALAFvwjnsnTqLp ynpkNxg9FyAZvFPMyd5Umj9mEZ/v4IjSm8vQwD+bqjgFJaibh45lWYm1H5rTe8B2F5hF1bJh8dJR gGDSUZxWWXrWGNanXVFZVmHSUe1g0lHpUlFRYNHoYNHOYU9gTVZTBVRaQ0YGNSI5Azk3PnAEIiUj JHAeNSQnPyI7YUdgRVZTBVRbQ14GNSI5Azk3PnxwGT4zfmF8YHpWUwVUW0NzBjUiOQM5Nz5wBDk9 NXADJDE9IDk+N3ADNSImOTM1cAI/PyRhZGBiVlMFVFtDex4fcBwZERIZHBkECXARExMVAAQVFHxw eDN5aWdwBjUiOQM5Nz58cBk+M35SRVDtQcqKE71xqxYI1NmaFtjAdb5EMGBcVlh61hjWp11SVVVQ 8AlgSFZZetYY1qddUVlTYVtWWXrWGNanXVFXUWBMVll61hjWp11RWVVhX0ddaWdgaGJmYmNhZmRm CmBPVll61hjWp11RWVRhQlRAhumRM7GBw8TSSdT9+E803mBdVll61hjWp11RUVFVUFTR0EkIXKYH krO977kYAueTj9Btku3WbBEEysYS0tt+2XIcKFuXbhtMTWYbebWI60jHSHKqhDHAuUeZLXCuyur5 Ezi6G4LDCxojNYBPwd8+tx1OSPnOhx4EJ1brP6V3L76eBCDecC7dqp5FKj5lkhrh60pXNcz8i0i/ FCBW71o6975RIAC4D85SAQDOUgEA+FEBAAEAAgAAAAAQAgIFAwUEBQkDBAD/kAEAAAAATFADAAAA AAAAAAAAAAAAAAAAAQAAAAAAAABJ2KAHAAAAAAAAAAAAAAAAAAAAAAAAIABUAGkAbQBlAHMAIABO AGUAdwAgAFIAbwBtAGEAbgAAAAAADgBJAHQAYQBsAGkAYwAAAAAAGABWAGUAcgBzAGkAbwBuACAA MgAuADQANQAAACwAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AIABJAHQAYQBsAGkAYwAA AAAAUFFQUFBDUVBQVFBgFAMZF8awRwtQUW2MUFBETBwEAxgm+sP7UFBGfFBQULIfA39iw7jfH1BQ UehQUFAGBhQdCB5MONZQUEdAUFBBxDM9MSB9+rFSUFFrbFBQUvAzJiRwrivMIlBQaFxQUFcgNiA3 PegB4ZBQUGKcUFBVbTcxIyBQS1BZUFBSQFBQUEA3PCk2+K2esFBQB6xQUI4GODQ9KGbNVddQUBKk UFBFWDg1MTSQq3WxUFBRbFBQUGY4ODUxXiJV/1BQUSRQUFB0OD0kKN3HaIpQUG8sUFBTKDs1Ij6v j1Q3UFFoCFBQUrI8PzMxUDx1jlBQQuBQUFMsPTEoIFUkWqRQUFHIUFBQcD4xPTWAfaZPUFBScFBQ QN0gPyMkauFxuVBRZgRQUFJRICI1IK8KCvpQUHj0UFBad1BRUFBQUtBQV/CIGQ9fbKVYSVhQUFBQ UPNP6O1QUFBQ4Hjyha7PrhZXtFdaUFJQWVBRUFFQUFBQUFFQUFdxrhVQB1hQrsuuJFgFUEhQV1BQ UFBQUFBQUFBQUFCOUFFQUFCOUA9QV1AFUFRQUlBAUEZQEVBQVGdad1BSUFFQUVNnUcBQVVBQVcpV Y1B8UXVVylVjUBxT8FA2UkJRVVJSVVNVVFVZU1RQUFBTUFBQUFBQUFBQUFBQHT8+P1BRUHBySVXe rhZRY1dxUetQUFBRUFBQUFBQUFBQU1BYUFJQRFBRr69QU1BQUBNTelBRUFBQUFBQUC9QUFBRUFBQ UFBRUF9QL1BRUFBQUFBSUFZRVFBRUFBQUFBTUGhQu1BRUFBQUFBUUEZQpFBRUFBQUFBVUFxRW1BR UFBQUFBWUEhRc1BRUFBQUFBXUDxQL1BTUFFUU1BSUF5RC1BTUFFUU1BUUH5Ra1BTUFFUVVBSUF5R 2VBTUFFUVVBUUH5ROVBTUFFUVlBSUFxR51BTUFFUVlBUUHxRx1BTUFFUV1BSUFxRs1BTUFFUV1BU UHxRk1BTUFFUWFBSUFxSR1BTUFFUWFBUUHxRp1BTUFFUWVBQUK5Sc1BTUFFUWVBRUE5TcVBTUFFU WVBSUFxUe1BTUFFUWVBTUCBTqVBTUFFUWVBUUHxUW1BTUFFUWVBVUEhUaVBTUFFUWVBWUGBUOVBT UFFUWVBXUIhTcVBTUFFUWVBYUHZUyVBTUFFUWVBZUNZU71BTUFFUWVBaVQZVFVBTUFFUWVBbUCJa y1BTUFFUWVBcUDZbXVBTUFFUWlBSUF5bw1BTUFFUWlBUUH5bI1BTUFFUW1BSUERRs1BTUFFUW1BU UGRRk1BTUFFUXFBSUEBbkVBTUFFUXFBUUGBb8VBTUFFUXlBSUFhboVBTUFFUXlBUUHhbgVBTUFFU QFBSUF5cSVBTUFFUQFBUUH5bqVBTUFFUQ1BSUF5cF1BTUFFUQ1BUUH5cd1BTUFFURFBSUFxRs1BT UFFURFBUUHxRk1BTUFFURVBSUF5cJVBTUFFURVBUUH5cBVBTUFFURlBSUF5c81BTUFFURlBUUH5c 01BTUFFUSVBSUFxcgVBTUFFUSVBUUHxc4VBTUFFUS1BSUF5crVBTUFFUS1BUUH5cjVBTUFFUTVBS UFxRs1BTUFFUTVBUUHxRk1BTUFFUT1BSUFxde1BTUFFUT1BUUHxdW1BTUFFUfVBSUFxdB1BTUFFU fVBUUHxdZ1BTUFFYWlBSUF5bw1BTUFFYWlBUUH5bI1BTUFFYRlBSUF5c81BTUFFYRlBUUH5c01BT UFFcWlBSUF5bw1BTUFFcWlBUUH5bI1BTUFFcXFBSUEBbkVBTUFFcXFBUUGBb8QQpIDU2MTM1cPlw BDg1cB0/Pj8kKSA1cBM/IiA/IjEkOT8+cCA8M35wFDEkMXD5cAQ4NXAdPz4/JCkgNXATPyIgPyIx JDk/PnAgPDN/BCkgNXADPzwlJDk/PiNwGT4zfnBhaWlgfWFpaWJ+cBE8PHACOTc4JCNwAjUjNSIm NTQEOT01I3AeNSdwAj89MT74cAQiMTQ1PTEiO3A/NnAEODVwHT8+PyQpIDVwEz8iID8iMSQ5Pz5w IDwzcCI1NzkjJDUiNTRwOT5wJDg1cAUDcAAxJHB2cAQdcB82Nn5wMT40cDU8IzUnODUiNX4dPz4/ JCkgNWoEOT01I3AeNSdwAj89MT5wGSQxPDkzagY1IiM5Pz5wYn5kZXB4HTkzIj8jPzYkeQQ5PTUj HjUnAj89MT4AA30ZJDE8OTMdBFAEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlBwUDNQJVAi UCNQOVAmUDFQBFA5UD1QNVAjUHBQHlA1UCdQcFACUD9QPVAxUD5QcFA7UCVQIlAqUL1QJlAxUARQ OVA9UDVQI1BwUB5QNVAnUHBQAlA/UD1QMVA+UHBQO1AlUCJQI1A5UCZQBFA5UD1QNVAjUHBQHlA1 UCdQcFACUD9QPVAxUD5QcFAbUCVQIlAjUDlQJlA/UDlQJFAlUARQOVA9UDVQI1BwUB5QNVAnUHBQ AlA/UD1QMVA+UHBT8FPrU/xT41PpU+FQBFApUCBQNVA2UDFQM1A1UHBQ+VBwUARQOFA1UHBQHVA/ UD5QP1AkUClQIFA1UHBQE1A/UCJQIFA/UCJQMVAkUDlQP1A+UHBQIFA8UDNQflBwUBRQMVAkUDFQ cFD5UHBQBFA4UDVQcFAdUD9QPlA/UCRQKVAgUDVQcFATUD9QIlAgUD9QIlAxUCRQOVA/UD5QcFAg UDxQM1B/UARQKVAgUDVQcFADUD9QPFAlUCRQOVA/UD5QI1BwUBlQPlAzUH5QcFBhUGlQaVBgUH1Q YVBpUGlQYlB+UHBQEVA8UDxQcFACUDlQN1A4UCRQI1BwUAJQNVAjUDVQIlAmUDVQNFAEUDlQPVA1 UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlD+UHBQBFAiUDFQNFA1UD1QMVAiUDtQcFA/UDZQcFAEUDhQ NVBwUB1QP1A+UD9QJFApUCBQNVBwUBNQP1AiUCBQP1AiUDFQJFA5UD9QPlBwUCBQPFAzUHBQIlA1 UDdQOVAjUCRQNVAiUDVQNFBwUDlQPlBwUCRQOFA1UHBQBVADUHBQAFAxUCRQcFB2UHBQBFAdUHBQ H1A2UDZQflBwUDFQPlA0UHBQNVA8UCNQNVAnUDhQNVAiUDVQflAdUD9QPlA/UCRQKVAgUDVQalAE UDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlBwUBlQJFAxUDxQOVAzUGpQBlA1UCJQI1A5UD9Q PlBwUGJQflBkUGVQcFB4UB1QOVAzUCJQP1AjUD9QNlAkUHlQBFA5UD1QNVAjUB5QNVAnUAJQP1A9 UDFQPlAAUANQfVAZUCRQMVA8UDlQM1AdUARQHVA/UD5QP1AkUClQIFA1UHBQBFApUCBQP1A3UCJQ MVAgUDhQKVAdUD9QPlA/UCRQKVAgUDVQcFAEUClQIFA1UHBQFFAiUDFQJ1A5UD5QN1BwUB9QNlA2 UDlQM1A1UHBQfVBwUANQJFAxUD5QPFA1UClQcFAdUD9QIlA5UCNQP1A+UHxQcFAGUDlQM1AkUD9Q IlBwUBxQMVAiUDRQNVA+UCRQcFBhUGlQY1BiUARQOFA5UCNQcFAiUDVQPVAxUCJQO1AxUDJQPFA1 UHBQJFApUCBQNVA2UDFQM1A1UHBQNlA5UCJQI1AkUHBQMVAgUCBQNVAxUCJQNVA0UHBQOVA+UHBQ YVBpUGNQYlBwUDlQPlBwUARQOFA1UHBQBFA5UD1QNVAjUHBQP1A2UHBQHFA/UD5QNFA/UD5QcFA+ UDVQJ1AjUCBQMVAgUDVQIlB8UHBQNlA/UCJQcFAnUDhQOVAzUDhQcFA5UCRQcFAnUDFQI1BwUDRQ NVAjUDlQN1A+UDVQNFB+UHBQcFAZUCRQcFA4UDFQI1BwUCNQJVAyUCNQNVAhUCVQNVA+UCRQPFAp UHBQMlA1UDNQP1A9UDVQcFA/UD5QNVBwUD9QNlBwUCRQOFA1UHBQJ1A/UCJQPFA0UCNQcFA9UD9Q I1AkUHBQI1AlUDNQM1A1UCNQI1A2UCVQPFBwUCRQKVAgUDVQcFAzUCJQNVAxUCRQOVA/UD5QI1B+ UHBQcFAEUDhQNVBwUD9QIlA5UDdQOVA+UDFQPFBwUDRQIlAxUCdQOVA+UDdQI1BwUCdQNVAiUDVQ cFA9UDFQNFA1UHBQJVA+UDRQNVAiUHBQA1AkUDFQPlA8UDVQKVBwUB1QP1AiUDlQI1A/UD5Qd1Aj UHBQNFA5UCJQNVAzUCRQOVA/UD5QcFAyUClQcFAGUDlQM1AkUD9QIlBwUBxQMVAiUDRQNVA+UCRQ cFAxUCRQcFAEUDhQNVBwUARQOVA9UDVQI1B+UHBQcFAZUCRQcFAkUDhQNVA+UHBQJ1A1UD5QJFBw UCRQOFAiUD9QJVA3UDhQcFAxUD5QcFA1UChQJFA1UD5QI1A5UCZQNVBwUDlQJFA1UCJQMVAkUDlQ JlA1UHBQIFAiUD9QM1A1UCNQI1BwUDlQPlAmUD9QPFAmUDlQPlA3UHBQNlAlUCJQJFA4UDVQIlBw UCdQP1AiUDtQcFA5UD5QcFAdUD9QPlA/UCRQKVAgUDVQd1AjUHBQBFApUCBQNVBwUBRQIlAxUCdQ OVA+UDdQcFAfUDZQNlA5UDNQNVB+UHBQcFASUDFQI1A1UDRQcFA/UD5QcFA1UChQIFA1UCJQOVA9 UDVQPlAkUCNQcFAdUD9QIlA5UCNQP1A+UHBQOFAxUDRQcFAzUD9QPlA0UCVQM1AkUDVQNFBwUCVQ I1A5UD5QN1BwUABQNVAiUCBQNVAkUCVQMVBwUDFQPlA0UHBQAFA8UDFQPlAkUDlQPlB8UHBQOVAk UHBQOFAxUCNQcFA9UDFQPlApUHBQP1A8UDRQcFAjUCRQKVA8UDVQcFAzUDhQMVAiUDFQM1AkUDVQ IlA5UCNQJFA5UDNQI1BwUDJQJVAkUHBQJ1AxUCNQcFAxUDRQMVAgUCRQNVA0UHBQJFA/UHBQN1A5 UCZQNVBwUDVQKFAzUDVQPFA8UDVQPlAkUHBQPFA1UDdQOVAyUDlQPFA5UCRQKVBwUDNQP1AlUCBQ PFA1UDRQcFAnUDlQJFA4UHBQN1A/UD9QNFBwUDVQM1A/UD5QP1A9UClQflBwUHBQB1A5UDRQNVA8 UClQcFAlUCNQNVA0UHBQOVA+UHBQMlA/UD9QO1AjUHBQMVA+UDRQcFA9UDFQN1AxUCpQOVA+UDVQ I1B8UHBQNlA/UCJQcFAiUDVQIFA/UCJQJFAjUHxQcFA/UDZQNlA5UDNQNVBwUDRQP1AzUCVQPVA1 UD5QJFAjUHBQMVA+UDRQcFAxUDxQI1A/UHBQNlA/UCJQcFA0UDlQI1AgUDxQMVApUHBQMVA+UDRQ cFAxUDRQJlA1UCJQJFA5UCNQOVA+UDdQflA4UCRQJFAgUGpQf1B/UCdQJ1AnUH5QPVA/UD5QP1Ak UClQIFA1UH5QM1A/UD1Qf1A4UCRQPVA8UH9QPVAkUD5QMVA9UDVQf1A9UCNQD1AkUDlQPVA1UCNQ PlA1UCdQIlA/UD1QMVA+UH5QOFAkUD1QPFA4UCRQJFAgUGpQf1B/UCdQJ1AnUH5QPVA/UD5QP1Ak UClQIFA1UH5QM1A/UD1Qf1A4UCRQPVA8UH9QPVAkUD5QMVA9UDVQf1A9UCNQD1AnUDVQPFAzUD9Q PVA1UH5QOFAkUD1QPFAEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlBwUBNQJVAiUCNQOVAm UDFQBFA5UD1QNVAjUHBQHlA1UCdQcFACUD9QPVAxUD5QcFAZUCRQMVA8UDlQIVAlUDVQBFA5UD1Q NVAjUHBQHlA1UCdQcFACUD9QPVAxUD5QcFAUUQFQPFAkUARQOVA9UDVQI1BwUB5QNVAnUHBQAlA/ UD1QMVA+UHBQE1A/UCJQI1A5UCZQP1AEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlBwUBNQ JVAiUCNQOVA1UDZQBFA5UD1QNVAjUHBQHlA1UCdQcFACUD9QPVAxUD5QcFA7UCVQIlAjUClQJ1Ax UARQOVA9UDVQI1BwUB5QNVAnUHBQAlA/UD1QMVA+UHBQGVAkULFQPFA5UDNQP1AEUDlQPVA1UCNQ cFAeUDVQJ1BwUAJQP1A9UDFQPlBwVEpUE1QQVBFUaFRiUARQOVA9UDVQI1BwUB5QNVAnUHBQAlA/ UD1QMVA+UHBQAFA/UMpQNVAmUD5QP1AEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlBwUWBQ JFAxUDxQOVA7UARQOVA9UDVQI1BwUB5QNVAnUHBQAlA/UD1QMVA+UHBQNVAkUCpQMVA+UDFQUFBQ UFBQUFBQOFBQUDhQUFA4UFBQOFBQUUZQUFGuUFBUXFBQVg5QUFe8UFBZzFBQWl5QUFreUFBbRlBQ XLhQUF0MUFBdgFBQXlhQUF4CUFBe6FBQX+5QUEC6UFBBvlBQQxJQUESCUFBGUFBQR2hQUEheUFBJ MlBQSs5QUEtyUFBLglBQTNZQUEywUFBNzlBQTohQUHF8UFBzEFBQddZQUHbAUFB4VlBQeghQUHxk UFB98lBQYN5QUGLaUFBjolBQZsRQUGhOUFBqwlBQbCZQUG3GUFBvHFBQEXRQUBMeUFAVHlBQFrZQ UBjmUFAaJFBQHVBQUB9+UFABElBQAvRQUAM6UFAD5lBQBPpQUAVCUFAFGFBQBehQUAhkUFAJ4FBQ C2RQUA38UFAPcFBQMVxQUDKkUFA0ulBQNt5QUDhYUFA6cFBQO/pQUD60UFAhSFBQIk5QUCRcUFAl vFBQJzpQUCj+UFAqSlBQLDRQUC2KUFAvlFBQ0c5QUNMOUFDUoFBQ1aBQUNZ8UFDXalBQ17JQUNhG UFDYGFBQ2CZQUNj+UFDYtlBQ2UhQUNkAUFDZ0FBQ2eBQUNmwUFDaQlBQ2hZQUNoqUFDa+FBQ2oZQ UNtaUFDbalBQ2zpQUNvKUFDbmlBQ3FZQUNxmUFDcIFBQ3PBQUNyAUFDdUFBQ3WRQUN06UFDdzFBQ 3ZxQUN2uUFDeYFBQ3zJQUN+6UFDBOlBQw1pQUMQoUFDEtlBQxcxQUMfYUFDJwlBQy25QUM2cUFDO elBQzupQUPHKUFDzCFBQ86hQUPY0UFD3plBQ+QpQUPmCUFD76lBQ/SxQUP4+UFD/alBQ/9RQUOFo UFDiTFBQ4qZQUOPOUFDjgFBQ5FBQUORgUFDm0lBQ6GZQUOg8UFDo9FBQ6S5QUOoEUFDq7lBQ62BQ UOuwUFDsQFBQ7BpQUO3AUFDtolBQ7h5QUJBMUFCQMlBQkIZQUJH6UFCTilBQlFpQUJRuUFCUPlBQ lPJQUJSOUFCVQFBQlRBQUJUuUFCV4lBQlbJQUJZMUFCWHFBQli5QUJboUFCWvlBQl7JQUJgCUFCY vFBQmSpQUJpwUFCawFBQmpJQUJqiUFCbdFBQmwZQUJvqUFCdblBQnuJQUJ64UFCfTFBQgOJQUIJs UFCDRFBQhGpQUIVyUFCGTlBQiGBQUIomUFCM7FBQjKZQUI4GUFBQjldRUVGttTNalpSmprVaWFhZ WFpaWlpaWlpaWlpaWVlYWFhaY0lBWEFaa1pBSll0WFpYQWtBQVpYWmvdWuNYrVqvWlrHWk90dndj WlpMeEZLQFpEWlpJWkpaQWtBWVpaWFpaWlpYWlhaWlpaWlpaWllZWVlZWlpaWlpaWlpaWlpaXVpa WlpaWllaWjUyCqqsVVpaWllYWlhEk6JYM1paVVpaWlpYWlVYWFlZWllYM1lZWlhZWKZaWlpaWllZ WVlaWlpaWlpaWVlRWVFaWlFRWFpaWFlapFhar69aWlpaWlBQUFBQU1BTUVFRUVFVU1NRUlFRUEhV vFuQUKhYr1BYUFevrlBZUFivrlBaUFqvrlBbUFuvrVBcUFyvrVBdUFyvrVBeUF2vrVBfUF2vrFBA UF+vrFBBUF+vrFBCUECvrFBDUECvq1BEUEGvq1BFUEKvq1BGUESvq1BHUESvqlBIUEWvqlBJUEev qlBKUEevqlBLUEivqVBMUEqvqVBNUEuvqVBOUEyvqVBPUE2vqVBwUE2vqFBxUE6vqFByUHCvqFBz UHGvqFB0UHGvp1B1UHKvp1B2UHOvp1B3UHOvp1B4UHWvplB5UHavplB6UHavplB7UHevplB8UHiv pVB9UHmvpVB+UHqvpVB/UHqvpVBgUHuvpFBhUHuvpFBiUH2vpFBjUH6vpFBkUH+vo1BlUGCvo1Bm UGCvo1BnUGGvo1BoUGKvolBpUGOvolBqUGSvolBrUGWvolBsUGavolBtUGavoVBuUGevoVBvUGiv oVAQUGqvoVARUGqvoFASUGuvoFATUGyvoFAUUG2voFAVUG2vv1AWUG+vv1AXUBCvv1AYUBCvv1AZ UBGvvlAaUBKvvlAbUBOvvlAcUBSvvlAdUBWvvVAeUBavvVAfUBevvVAAUBevvVABUBivvFACUBqv vFADUBqvvFAEUBuvvFAFUByvu1AGUB2vu1AHUB2vu1AIUB+vu1AJUACvu1AKUAGvulALUAGvulAM UAKvulANUAOvulAOUASvuVAPUAWvuVAwUAavuVAxUAevuVAyUAevuFAzUAivuFA0UAqvuFA1UAuv uFA2UAuvt1A3UAyvt1A4UA2vt1A5UA2vt1A6UA+vtlA7UDCvtlA8UDGvtlA9UDGvtlA+UDKvtVA/ UDOvtVAgUDSvtVAhUDWvtVAiUDavtFAjUDevtFAkUDevtFAlUDivtFAmUDmvtFAnUDuvs1AoUDuv s1ApUDyvs1AqUD2vs1ArUD6vslAsUD6vslAtUCCvslAuUCGvslAvUCGvsVDQUCKvsVDRUCOvsVDS UCSvsVDTUCWvsFDUUCavsFDVUCevsFDWUCivsFDXUCivj1DYUCmvj1DZUCuvj1DaUCuvj1DbUCyv jlDcUC2vjlDdUC6vjlDeUC6vjlDfUNCvjVDAUNGvjVDBUNKvjVDCUNKvjVDDUNOvjVDEUNSvjFDF UNWvjFDGUNavjFDHUNevjlDIUNivjVDJUNivjVDKUNmvjVDLUNuvjVDMUNyvjFDNUNyvjFDOUN2v jFDPUN6vjFDwUN6vi1DxUMCvi1DyUMGvi1DzUMKvi1D0UMKvilD1UMOvilD2UMSvilD3UMavilD4 UMaviVD5UMeviVD6UMiviVD7UMmvilD8UMmvilD9UMuviVD+UMyviVD/UMyviVDgUM2viVDhUM6v iFDiUM+viFDjUPCviFDkUPGviFDlUPKviFDmUPOviFDnUPOviFDoUPSviFDpUPaviFDqUPaviFDr UPevh1DsUPivh1DtUPmvhlDuUPmvh1DvUPuvhlCQUPyvh1CRUP2vhlCSUP2vhlCTUP6vhlCUUP+v hlCVUOCvhVCWUOGvhFCXUOKvhFCYUOOvhFCZUOOvhFCaUOSvg1CbUOavg1CcUOevg1CdUOevg1Ce UOivglCfUOmvglCAUOmvglCBUOuvglCCUOyvgVCDUO2vgVCEUO2vgVCFUO6vglCGUO+vgVCHUJCv gVCIUJGvgVCJUJKvgVCKUJOvgFCLUJOvgFCMUJSvgFCNUJWvgFCOUJevn1CPUJevn1CwUJivn1Cx UJmvn1CyUJqvnlCzUJqvnlC0UJyvnlC1UJ2vnlC2UJ2vnlC3UJ6vnVC4UJ+vnVC5UICvnVC6UIGv nFC7UIKvm1C8UIOvm1C9UISvm1C+UISvm1C/UIWvm1CgUIevm1ChUIevm1CiUIivnFCjUImvm1Ck UIqvm1ClUIqvm1CmUIyvm1CnUI2vmlCoUI6vmlCpUI6vmVCqUI+vmlCrULCvmVCsULGvmVCtULKv mVCuULOvmVCvULSvmFCoWK9QWFBXr65QWVBYr65QWlBar65QW1Bbr61QXFBcr61QXVBcr61QXlBd r61QX1Bdr6xQQFBfr6xQQVBfr6xQQlBAr6xQQ1BAr6tQRFBBr6tQRVBCr6tQRlBEr6tQR1BEr6pQ SFBFr6pQSVBHr6pQSlBHr6pQS1BIr6lQTFBKr6lQTVBLr6lQTlBMr6lQT1BNr6lQcFBNr6hQcVBO r6hQclBwr6hQc1Bxr6hQdFBxr6dQdVByr6dQdlBzr6dQd1Bzr6dQeFB1r6ZQeVB2r6ZQelB2r6ZQ e1B3r6ZQfFB4r6VQfVB5r6VQflB6r6VQf1B6r6VQYFB7r6RQYVB7r6RQYlB9r6RQY1B+r6RQZFB/ r6NQZVBgr6NQZlBgr6NQZ1Bhr6NQaFBir6JQaVBjr6JQalBkr6JQa1Blr6JQbFBmr6JQbVBmr6FQ blBnr6FQb1Bor6FQEFBqr6FQEVBqr6BQElBrr6BQE1Bsr6BQFFBtr6BQFVBtr79QFlBvr79QF1AQ r79QGFAQr79QGVARr75QGlASr75QG1ATr75QHFAUr75QHVAVr71QHlAWr71QH1AXr71QAFAXr71Q AVAYr7xQAlAar7xQA1Aar7xQBFAbr7xQBVAcr7tQBlAdr7tQB1Adr7tQCFAfr7tQCVAAr7tQClAB r7pQC1ABr7pQDFACr7tQDVADr7tQDlAEr7pQD1AFr7pQMFAGr7pQMVAHr7pQMlAHr7lQM1AIr7lQ NFAKr7lQNVALr7lQNlALr7lQN1AMr7lQOFANr7lQOVANr7lQOlAPr7hQO1Awr7hQPFAxr7hQPVAx r7hQPlAyr7dQP1Azr7dQIFA0r7dQIVA1r7dQIlA2r7ZQI1A3r7ZQJFA3r7ZQJVA4r7ZQJlA5r7ZQ J1A7r7VQKFA7r7VQKVA8r7VQKlA9r7VQK1A+r7RQLFA+r7RQLVAgr7RQLlAhr7RQL1Ahr7NQ0FAi r7NQ0VAjr7NQ0lAkr7NQ01Alr7JQ1FAmr7JQ1VAnr7JQ1lAor7JQ11Aor7FQ2FApr7FQ2VArr7FQ 2lArr7FQ21Asr7BQ3FAtr7BQ3VAur7BQ3lAur7BQ31DQr49QwFDRr49QwVDSr49QwlDSr49Qw1DT r49QxFDUr45QxVDVr45QxlDWr45Qx1DXr45QyFDYr41QyVDYr41QylDZr41Qy1Dbr41QzFDcr4xQ zVDcr4xQzlDdr4xQz1Der4xQ8FDer4tQ8VDAr4tQ8lDBr4tQ81DCr4tQ9FDCr4pQ9VDDr4pQ9lDE r4pQ91DGr4pQ+FDGr4lQ+VDHr4lQ+lDIr4lQ+1DIr4pQ/FDJr4lQ/VDLr4lQ/lDMr4lQ/1DMr4lQ 4FDNr4lQ4VDOr4hQ4lDPr4hQ41Dwr4hQ5FDxr4hQ5VDyr4hQ5lDzr4hQ51Dzr4hQ6FD0r4hQ6VD2 r4hQ6lD2r4hQ61D3r4dQ7FD4r4dQ7VD5r4ZQ7lD5r4dQ71D7r4ZQkFD8r4dQkVD9r4ZQklD9r4ZQ k1D+r4ZQlFD/r4ZQlVDgr4VQllDhr4RQl1Dir4RQmFDjr4RQmVDjr4RQmlDkr4NQm1Dmr4NQnFDn r4NQnVDnr4NQnlDor4JQn1Dpr4JQgFDpr4JQgVDrr4JQglDsr4FQg1Dtr4FQhFDtr4FQhVDur4JQ hlDvr4FQh1CQr4FQiFCRr4FQiVCSr4FQilCTr4BQi1CTr4BQjFCUr4BQjVCVr4BQjlCXr59Qj1CX r59QsFCYr59QsVCZr59QslCar55Qs1Car55QtFCcr55QtVCdr55QtlCdr55Qt1Cer51QuFCfr51Q uVCAr51QulCBr5xQu1CCr5tQvFCDr5tQvVCEr5tQvlCEr5tQv1CFr5tQoFCHr5tQoVCHr5tQolCI r5xQo1CJr5tQpFCKr5tQpVCKr5tQplCMr5tQp1CNr5pQqFCOr5pQqVCOr5lQqlCPr5pQq1Cwr5lQ rFCxr5lQrVCyr5lQrlCzr5lQr1C0r5hQqFivUFhQV6+uUFlQWK+uUFpQWq+uUFtQW6+tUFxQXK+t UF1QXK+tUF5QXa+tUF9QXa+sUEBQX6+sUEFQX6+sUEJQQK+sUENQQK+rUERQQa+rUEVQQq+rUEZQ RK+rUEdQRK+qUEhQRa+qUElQR6+qUEpQR6+qUEtQSK+pUExQSq+pUE1QS6+pUE5QTK+pUE9QTa+p UHBQTa+oUHFQTq+oUHJQcK+oUHNQca+oUHRQca+nUHVQcq+nUHZQc6+nUHdQc6+nUHhQda+mUHlQ dq+mUHpQdq+mUHtQd6+mUHxQeK+lUH1Qea+lUH5Qe6+lUH9Qeq+lUGBQe6+kUGFQe6+kUGJQfa+k UGNQfq+kUGRQf6+jUGVQYK+jUGZQYK+jUGdQYa+jUGhQYq+iUGlQY6+iUGpQZK+iUGtQZa+iUGxQ Zq+iUG1QZq+hUG5QZ6+hUG9QaK+hUBBQaq+hUBFQaq+gUBJQa6+gUBNQbK+gUBRQba+gUBVQba+/ UBZQb6+/UBdQEK+/UBhQEK+/UBlQEa++UBpQEq++UBtQE6++UBxQFK++UB1QFa+9UB5QFq+9UB9Q F6+9UABQF6+9UAFQGK+8UAJQGq+8UANQGq+8UARQG6+8UAVQHK+7UAZQHa+7UAdQHa+7UAhQH6+7 UAlQAK+7UApQAa+6UAtQAa+6UAxQAq+7UA1QA6+7UA5QBK+6UA9QBa+6UDBQBq+6UDFQB6+6UDJQ B6+5UDNQCK+5UDRQCq+5UDVQC6+5UDZQC6+5UDdQDK+5UDhQDa+5UDlQDa+5UDpQD6+4UDtQMK+4 UDxQMa+4UD1QMa+4UD5QMq+3UD9QM6+3UCBQNK+3UCFQNa+3UCJQNq+2UCNQN6+2UCRQN6+2UCVQ OK+2UCZQOa+2UCdQO6+1UChQO6+1UClQPK+1UCpQPa+1UCtQPq+0UCxQPq+0UC1QIK+0UC5QIa+0 UC9QIa+zUNBQIq+zUNFQI6+zUNJQJK+zUNNQJa+yUNRQJq+yUNVQJ6+yUNZQKK+yUNdQKK+xUNhQ Ka+xUNlQK6+xUNpQK6+xUNtQLK+wUNxQLa+wUN1QLq+wUN5QLq+wUN9Q0K+PUMBQ0a+PUMFQ0q+P UMJQ0q+PUMNQ06+PUMRQ1K+OUMVQ1a+OUMZQ1q+OUMdQ16+OUMhQ2K+NUMlQ2K+NUMpQ2a+NUMtQ 26+NUMxQ3K+MUM1Q3K+MUM5Q3a+MUM9Q3q+MUPBQ3q+LUPFQwK+LUPJQwa+LUPNQwq+LUPRQwq+K UPVQw6+KUPZQxK+KUPdQxq+KUPhQxq+JUPlQx6+JUPpQyK+JUPtQya+KUPxQya+JUP1Qy6+JUP5Q zK+JUP9QzK+JUOBQza+JUOFQzq+IUOJQz6+IUONQ8K+IUORQ8a+IUOVQ8q+HUOZQ86+IUOdQ86+I UOhQ9K+IUOlQ9q+IUOpQ9q+IUOtQ96+HUOxQ+K+HUO1Q+a+GUO5Q+a+HUO9Q+6+GUJBQ/K+HUJFQ /a+GUJJQ/a+GUJNQ/q+GUJRQ/6+GUJVQ4K+FUJZQ4a+EUJdQ4q+EUJhQ46+EUJlQ46+EUJpQ5K+D UJtQ5q+DUJxQ56+DUJ1Q56+DUJ5Q6K+CUJ9Q6a+CUIBQ6a+CUIFQ66+CUIJQ7K+BUINQ7a+BUIRQ 7a+BUIVQ7q+CUIZQ76+BUIdQkK+BUIhQka+BUIlQkq+BUIpQk6+AUItQk6+AUIxQlK+AUI1Qla+A UI5Ql6+fUI9Ql6+fULBQmK+fULFQma+fULJQmq+eULNQmq+eULRQnK+eULVQna+eULZQna+eULdQ nq+dULhQn6+dULlQgK+dULpQga+cULtQgq+bULxQg6+bUL1QhK+bUL5QhK+bUL9Qha+bUKBQh6+b UKFQh6+bUKJQiK+cUKNQia+bUKRQiq+bUKVQiq+bUKZQjK+bUKdQja+aUKhQjq+aUKlQjq+ZUKpQ j6+aUKtQsK+ZUKxQsa+ZUK1Qsq+ZUK5Qs6+ZUK9QtK+YEVlQUFPnUFFT51BTWFBQT1PmU9Hiak9f EUdT41BAU+JQcFPiUABT4lAgU+JQsFPiUFZQn1PjUI9T41C/U+NQr1PjUFRQQlP44rLZT+5Tz1E7 UcpQT1PIUMNYURBcTy9UL1VSL1IvU1IP61LgUFGvkFFH4kk2YuivkOM1SjZi6a/QUSPiSTZi7VPU UUdYUFBPr5BS/+JhYxDoUv/ifmMQ6FL/43h5YhDoUv/jdndiEOhS/+NxdWIQ6FL/40xwYhDoUv/i c2MQ6FL/4klj8OxS/1DgUv9QsFL/5VMQU3F5YuivouNqdm1i7FPSU9JT0lBqWFDlTxB1DGNO6FPR 4gw0YuivvuN1fmNE6FPR43t+YjnuU9FQUVDaU9FQUVBeU9Hje39iQOhT0eMBC2Jc6FPR4x4BYnLo U9HjFx1iXuhT0eIWY1roU9EQWXYXYkJ1EwhiXOhT0eJiY0DoU9HiemNC6FPR42dtYkLrU9FQbVBj r6QQRXVtY0h1ZQtiQHV2ZGJWdXpjXHV+Y+ivrhB0dX1jXGp/Y2LJdfp16nWZdVRVdWZjXHViaGJJ anlqaGpTSHVH6FPR5Hh1aHVU7FPRU9FT0VB1WFAQQE9fT3t+YjlPKE9SW09gY2Lor6HjT3ZtYuxT 0FPQU9BQT1hQEEVPZw9X/1dSD1b/VlJy/Ht+Yln8f2Por4wQWvxPcmJyc3sCYl7oUy/ieWNe6FMv 4nJjROhTL+JOcGLor7fnTntjYk57f2Lpr5BTL+YcH2JidnxjEVqvvlMvUGlQY6+oUy9Qe1Bjr7pT L+JqY3DoUy/jbxZiTuhTL+N/amJC6FMv4n5jTuhTL+N6fWJe6FMv4nZjVOhTL+MZGmRU6FMv4hZj VOhTL+JxY0joUy8QXE1jcnZgYmJydmNoYuivqBBadnt/Yll2S3Fi2u5TL1BRUy9TL1MvUHZYUBB+ T2dPVn9Wb1ZTz1L/Uu9Sn1JUz1P/U+9Tn1NUP1MvU99TU09Tf1NvUx9TD1NVXxFlUr1QUVAPUr1Q z1K9UI9SvVBTUH9SvVBvUr1QP1K9UFNQ/1L/UFFQH1L/UM9S/1BSUH9S/1BvUv9QUlBvUuBQUVAf Uv9QD1L/UFJQf1L/UG9S/1BSUCBT4lBRU+JT4lK9Ur1S4FLgUv9S/xBKZ1FQYFEQUVJRUVBZUVJQ WFBHR1BQUEJBWBARW1IrUnNQZFBdUW1QZFBdUWdQZFBdUUsQSmRd32Rd1GRdOGRdCWRdBGRdGGRd fGRdeGRdEUBSZVBwUF1SS1BwUF1RrFBwUF1Rk1BwUF1RAFBwUF1RfBBKcF2gcF3ucF3EcF0pcF06 cF0xcF0PcF0UcF0RXVFuUWhQXVBtUWhQXVBgUWhQXVBNUWhQXVGt5F8dX1BZ71GtUB1QXVPhUy9Q RVBPUkXidmRP6FJE4nZvT+hSWOJO608RSVJWUE5YUVBPUlVQT1L7UE9SVFBPUvtQT1JTUE9UUVBP UlFQYVHKUE9Rq1BzUQZQT1H+4nZ6T+hR/eJ2ek/oUfvidmRPEUVR+FB2UvtQT1H1UE5RdVBPUfRQ +1L7UE9R8lBhUvtQT1HxUGFS+1BPUc3iczxP6FHM4nM8TxFZUctQc1RRUE9RylBjUcpQT1Em4nZ+ T+hRPOJhIk8RQVE7UHNRylBPUThQdFRRUE9RFVB2WFFQT1FvUHNUUVBPUXPiTs5P7FFxUE5SUVBP UVDkdilPrU/oUXXiT6pj6FhR4k+pdOhS++JPuHboUVHiT7VP6FHK4k+0YehRURBbT7NhtE+yYdlP gnboUlHmT4B2nU+ddehUUeJP52HoUcriT/526FhR4k/8TuhUURBbT85hDk/Hds5Pw2PoWFHiT9p0 6FHK4k/TT+hS+xBDT9JzPE8lc7RPIHadTzRzIk8OdehUUeJPDXPoUvviTwW26FRR4k8DdOhSUeJP H2PoUvviTx526FRREENPF2E3TxZ2+08TYZ1PbnMOT2pP6FRR5k9pdLRPZ3PoWFHiT35z6FRR4k96 TuhRdRBbT3lz+093YftPBWfsUZZQV1HaUFdRexB+Vy9XIVc5VzZXG1cQV2hXZld9V3JXcVdEWEJY QFheWFxYWlhYWFZYVFhSWFBYROivsBB7UFBRUERWQFBQUVBWVFBQUVBUQFBQUVBAUlBQUVBSUFBQ UVBQUlFYUlAaUOBDUxtSGwMS4Gd7G+hXrwLgaHsb4FkACwjhUVHeCVEb4JAzUBsycOCmA3PoUVoB CuBVcxJR4EIbUBsEEkjgaHvgUtjoUVAECOhRr+FRUd7VS+BCEwjpUFFRENXdS+lQUVEJ1d0JCVBG Jm9Ib0JuQWkWFG5BaRYUbkFpFhRuQWkWFG5BaRYwFG5BaRYwFHt7e3t7e3t7e3t7SHt7e3t7e3t7 e3t7e3t7e0hN4MYbAwjg+k0J4GIbAwjgr00JG+AXA3AMCOlSLVIrFRTpUixSKxUUCQjpURZSLRUC COlSLVEWFAkJG+AXA3AMCOlQTlIsFRTpUHZSLBUUCQjpUS9QThUCCOlQTlEvFAkJG+AOA3AMCOlQ T1ItFRTpUHVSLRUUCQjpUfhQTxUCCOlQT1H4FAkJG+hRUQNwDAjh+08VFOFPTxUUCQjpVCBQ+xUC COlQ+1QgFAkJG+hRdQNwDAjhtk8VFOFPTxUUCQjpVUBQthUCCOlQtlVAFAkJG+BHA3AMCOF0dBUU 4WF0FRQJCOFydBUCCOF0chQJCRvgAQNwDAjhdHQVFOFzdBUUCQjhLXQVAgjhdC0UCQkb4D4DcAwI 4XR0FRThY3QVFAkI4fp0FQII4XT6FAkJe3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7NRJ7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7e3t7e3t7e3t7exU5AxJRGwAI4VhQEgkTDAjhWFASCUZAIG7gQhMI6UHlbdBL6lFMU4lQ W3sJ4FpzEuBbcxJQb29Ie0BsUX8NVlzgVnMS4FdzEuBCEwjpa3FILkvqVFBR+FBbewngXHMS4F1z EuBCEwjpfRF9EUvqVFBUUFBbewngXnMS4F9zEuBCEwjpSC5rcUvqUfhUUFBbewngQHMS4EFzElB7 G+B+AwjoUTsV4How6FE7cxQJUEgVORQVORRIFTkUFTkUIyMjIyUlJSMjJCUlJSUlexvgdgMb4G0B CgjhdnYV4EkwFAl7FUg5FCR7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3tQG+B6AxvgbwEKCOFX VxXgEDAUCSMje3sVSDkUe3sle3sVSDkUJSV7eyV7e3t7e3t7e3t7e3t7e3t7e3skJXt7e3t7FUg5 FHtQeyN7e3t7e3t7e3tRe3t7UCMjI3t7e1ETDAjor47jTkxjSOhTL+V7Y0h2e2Ppr6BT0eFCY3t7 e3sJUSMke1B7I1AQEBBvbm1sa2ppaGdlZGNiYWB/fn18e3p5eHd2dXRzcnFwT05NTEtKSUhHRkVE Q0JBQF9eXVxbWllYV1ZVVFNSUVB8FXMWMHDgdjDgVHZzGBh9fBVzFnMxcOB2MeBUdnMYGH18FXMW MOBwMXDgFjDgVHZzGBh9fBVzFnMx4HAwcOB2MeBwMeBUdnMYGH18FXMWMOAQMXDgNjDgVHZzGBh9 fBVzFnMx4BAwcOB2MeAQMeBUdnMYGH18UUBwbFBsfXxwFXNw4J0Uc3DoUQoBCHNw4N0Ucwlw4L0B CHNw4B0Ucwlw4MABCHNw4F0UcwlxcX18cHAVSDgUcOBRMHAV4BYmONoVMBR9fFHhW1oTcxM1Wn18 UOFaWxNzE1t9fFDgR3Mg4VFHblHgR3Mg4VJHFWrhUlBYXX18FeBKcxQV4ElzFH18cBXgU3UVMTTg AAEIFRRLcXEJfXzgURMzczLgUHMS4F97fXxwFeBQEzAUfXxR4FYT4FcTNVp9fHA54BAx4FDbcOF8 kNrc6EBQMjB7XDRzNDEMCOBTMQl9fBXgQXvgR3MU4EcqtEh9fBXgQXvgR3MUfXzgQhMI1xXgQXvg R3MU4EcqtEtT2hVIOXDgR3MU2trXcODwAQjgQXvgR3MU4EcqtEtx4EcqtAkJSH18fXzgUnUWMNoW 4BAx3Bh9fFFIf318cOBTdRXgSXMUFeBKcxQVNXMVcOBTdTA6cOBZcxJzONo6MDFw4Era4FACKXHi SkoQ6a+wUEoVcNoECHNx4G9LcwkxFEzhRFDaAinjSRBwSRVw2gQIc3Hgb0tzCTEUfXzhQEETcxNb fXzhXl8TcxNbfXzhXF0TcxNbfXzhXF0TcxM1W3184V5fE3MTNVt9fOFAQRNzEzVbfXwbAggVFEtx cQl9fFFw4FN1cxngEDDgcDNw4FACCHPgUnVoc+BSdTVoUNozaEtxcXFxcQlRfXwb4DQBCBU54FkT MNpAaktxcXEJfXxR4FV1QHNw2qVQ4FEwc728fXxR4FV1QHNw2qVQ4FExc728fXxR4FZ1QKVQvbx9 fHDgUTBRQHBsUGx9fHDgUTFRQHBsUGx9fOB7e+B6en18UOBXE+BWE1t9fG7genp9fGV9fCboUr5z IEBw6FK+FXDgUAAI4FExCWp/SH18cXFcNHM02+gQUDJ9fHHg0AEIXDRzNNvocFAyS+JQEH97CeBS MH18ceCQAQhcNHM02+hFBTJL4lDQf3sJ4FIwfXxcNHM02+gQUDIwc3F9fORQUVBQUEXgWHbgWHbg WHbgWHZfQEZDFThq4FFGfXzkUFFQUFBF4Fh24Fh24Fh24Fh2X0BGQxU4NWrgUUZ9fBsDcxsBCghw FdowFEtxcQl9fBsECHAV2jAUS3FxCX18GwNzGwEKCGhLcXEJfXwbBAhoS3FxCX184EMTCFNLUgl9 fOBDEwhSS1MJfXwbBOBCEwwKCGhLcXEJfXzgQhMMCFzgVHXgVHVWXDRzNDE06FdYAQjgVHXgVHVR cBbgQDAYcBbgQDAYCVpxcUtxcQl9fOBCEwwIXOBUdeBUdVZcNHM0MTToV1gBCOBUdeBUdVFwFuiv oDAYcBbor6AwGAlacXFLcXEJfXwbA3MbAQoI4Gp7S3FxCX18GwNzGwEKCOBre0txcQl9fBsDcxsB CuBCEwwKCGhLcXEJfXxc2lMbBOBUdlIbBAra2lrgQhMMCghoS3FxCX18FnMWMNraFnNwFtow2jHo r9Ayc3BAc9rpU+BT4NogFTBw4FAACOBRMeiv6ttL4BbcCeBAMDhRan1QUFBV3lBQVRxQT1UcUExT IVBIUFCvsVBQr7hQUK+4rhqvrFU7UHOuOK+yU25QUFDFUFBQxVBQUFBQUFBQUHVQ+FDeUVtQLVDS UBVQYlD0UJpQO1AgUAFQ/1BsUKBRh1AXUFRQdVAnUHlQEFCtUEZRMVAWUWdQeVDeUEevmlB1UAuv uVK2UFJQyVDRUKJQJVCGUDNQllBWUMpRY1B0UGhQnFBtrzdQQ1WIUGZQ1lDFr4tQV1RkUPVQiK+M r65QGFDyUIhRbFEDU9BVblAHUCpQLFDcUUdRelFoUSxQdlBsUChQ7VCQUkBZ5VBcUB1QHlAEUAhQ N1DkVFFQUlBVUABQ/1GFUxNQdFAIUNtRZVGQr/xQcFB1UHZQfVARUWZSe6/qUE5QelBkUGtQb1DV UMRQyFCHUX5RbVNhVOlQR1AQUDFQ6VFeUUZRclHvr8xQT1BPUB1QDFDWUNxQxlD6UJtQm1FPUQRS f1MwVfmuuFBeUD9QLFAtUNtQhVChUVpRB1EoUuhT/a5vrzqv46+UUE9QZ1BvUBRQGlAoUC1Qx1Dy UPdQ5lCQUJFQllCIUU1RAFHHUb5UJFVirdGuga6wr0avoVBfUH1QBVA4UD5QL1DZUMVQzlCSUIpQ tFCoUVRRWFFBUZJSYFKKU15UzlVHr1Cv11BQUHBQf1ARUAdQKFDXUNhQ2FDpUJJQlVFwUXhRY1Ek UYZSXlJfUjxSLlL7UrxT2VPhU7NUt68Tr/ivk6+Mr7lQV1BzUHNQdlACUCdQLVDRUN9QyVD8UP5Q 5VDoUJhQulCgUKRRZVE6UdtR4VHlUadSRFL9UoVUrFWIVaCvza+sUFtQdFB1UHxQYFBgUGNQEFAX UBlQB1A+UMpQ7VCZUJ1QjFCqUKpRS1FpUS5R11HaUd5RxVHGUY9RplLWUp9SjlPGU/lT4FOYVFFU YlQ6VdtVsFYBVzGuxq7Krxuv11BDUHVQZFBoUG5QGlA1UDtQI1AqUMxQ8lDiUOdQ71CgUKdQq1FU UUNRcFF0UWtRAlEoUSxR0VHfUfBRiVIYUjpSP1IgU1FTTVNzU3dT2FRPVPtUgVSKVSpV2652rgmv flBRUFJQWlBrUGtQF1AIUAhQD1A2UDtQKlAqUNtQyVD/UOxQkFCXUJxQuVCiUKVQq1CrUVJRWlFb UUVRcVF3URVRFVEFUQdRCFEOUTFROFEtUfNR+1GKUb5SQFJIUnJS31LEUvNSglK3UyFTw1PLU+NT g1OuVK9VW1ViVWJVG1UJVdtV+1WiVgVW2VcSVzJX91icrXqtmK2OrlyuRa53rgOu1K7rrwivJq8n r/Gv96/9r/+vkFBQUFBQU1DEUE1QT1BwUHBQd1B+UBhQG1AcUA5QD1A7UCFQLFDaUMBQwVDBUPdQ /1DjUORQlFCWUIFQglCOUI9Qj1C2ULhQulC7UKJQpVClUKxRUlFIUXNRYVFjUWdRDFEyUTZRIFEq USpRKlHSUchRyVHLUeBR71GQUZpRg1GHUYhRsFGwUaZRp1GoUkJSQ1J/UmdSFFIXUh9SAlIzUjVS IFIvUshSy1L2UudS6lKVUp9ShlKHUrVSrlNMU01TFVMYUw1TDlMhUylT0VPxU+dThFOFU4hTsVOo U65UVFRPVHFUc1R1VGpUN1TTVLBVeFUbVTRVOlXPVc9VklZbVjpW/1bjVptWuFdWV3hXGFcAV/ZX 4levUMVQ/1DCUMZQUFBQUFBQUFBQUFBRLlH4UXlSC1JCUlNRk1LkUcNRnVLiVL1SXlEJUSpTUFJ9 VHxQmFAdULZS2VN1UW5TKFFLUKFR3VAZUlNQLFBeUs1SF1B0UFBQUFACUBRQY1BoUARVg1RFUfdQ UFLWUThQAFCfUFJQG1B0UNhQ6lB1r4hQQVDBrztQ5VFHUHZQNa/JUBlQ0FEbUZBQpFE3UiFSulSs U0BRLFGxU4lRBVG2Ub5UZFHGVptQDFJ7UMlQbVDPUEZQaVB3UI5QKVFwUn5QClDJU9hQxFBxUElQ elQ8VbhQUFGiU+JQ+lLGUtlS5K+ZUlBQvFBVUApUF1FQVLBQUFV6UE9Ru1D+UThQmlKDUtlR5VRW UfFRH1EbUUxTWFAOUJdQdFLNUDVTJVFUUtBSo1SIUIlSaVIKU3xRolRhU1NQAFK1UtNQCVG7UVhQ /FHGUqhRcVDFUdBQFFC1UbtStVAkUKNRr1KtU99SOFGYUZdRRlJ7URJTYFCuUrFRMlJQUHRQvlVH UVhSZ1A2UFZRUlG2UvpTNlHLUINVklOMVB1T5lBUUe5RZ1KsU3BSFFEdU2ivvVB1VqhTXa6FrxNQ FFKvr8JUW62/UQVRIVCJr5RTfVQxVBqr5aufUkdRwlM9VQivoq4tVdNSblA2VblXbVApUhNQdVCf UK1Q/1B6Ub9SSlB2UE9QdVBqUFBRR1TAq6tSAVBNUqBRpVAoUd9QD1B0UBRQBFDvUP9QN1H4UHZQ VVBWUG9QyFCqUvtQklAdUyVQGlDmUJRR71EsUD9QQ1IzUFxQOFECUFJRflFUUE9QT1DKUFBQoVQ5 UClQ0FAAUO1VO1ZpUUxQUFBQUlBQUFJQUFBS+lDKUwxRdlRQUMNUUFAGVvpQwFZpUDJR5lFdUvpQ 3FL6r3FUUFFyVTZQ7lJQr7tS+lBmUlBQFVJpr+tUUFAqVFBQLVRQUHBUUFAUVFBQEFRQUBlUUFDR VFBQuFRQUB5UUFBrUvpQKlL6UHRVNlDGVTZQmFU2UMZUUFCWVwxQMVSzr8xUs6+BVQZQ2lWXr5NU s6+CVLOvnlWXUN5Vl6+aUvqvkFPdr+pVBq+ZVCOv7lb6r+1VBq+XVZdQKlSzr59Vl1AxVLOvgVRQ UF5UI1DfVZdQilSzUVBW+lCpVLOvJ1QjUOhUI6+sU01QXVJpUIpTTa9jUzBQaFRQr79S+lE4VFBQ YFRQUGZT3VBoVFBQd1PdUBBSaa7LVFCvmVRQUHlSaVAIUmmu8FPdUERSaVAfVZdQc1RQUHdUUFBs VFCvTlRQUH1TTVB6U02vvVJpUARUUFBsU91QfFUGUHNT3a/oU92vDFNNr5dTY1DdUmNQvVNjrzdU BFBEVLOvzFSzr85VBlDaVLOvglUGr5dVl1AqVZdQilRQUGBUUFBgVFBQYFRQUGBUUFBgVFBQYFPd UGxT3VAQU91QEFPdUBBT3VAQUmlQCFJpUAhSaVAIUmlQCFRQUHdUUFBsVFBQbFRQUGxUUFBsVFBQ bFRQUGxUUFBsVFBQbFRQUGxUUFCNU2NQhFRQUCJUUFBhVFCvrFKdUP1Uf1A8VFCu51ZEUNtWRFDb V4dQ7lL6UclS+lFcV02vxFWXUBhUNFBlVFCvolTMr4JSZVDiUitQtFUGUH1UUFBVVFBQGVNNUMBV NlDGVFBQUlRQUARUUFB1V01RWlSzr8xUs6/MVZdQKlfdUH1VBlBmVFCvvldNr71UI1HaVCNRJVL6 UeJS+lHBVDRQZVPdrzBUI1DnVFBQClL6UCRS+lB+VFCvs1JQUMFS+lARVCNQTlhQUC9Us6/MVLOv glSzr8xUs6+CVLOvglL6r5BS+q+QUvqvkFL6r5BVl1AqVZdQKlWXUCpVl1CKVZdQilWXUIpSaVAI UvpQrlL6UJZS+lEtUvqvi1L6UQJUUFBeU02voFQjr6xTTa/9UmNQvVWXr4BUUFBnVCNQ51PdrzBU s6+fVFCvTlU2USpSNlDzUjZQP1I2UNRWUFDxVlBQ8VZQUNJUUFCVVFBQQVBQUEhQUFCwW1xZUFNT VFRWVlpZUlRUVldTVFNTVlZWVlZWVlZWVlRUV1dXVlpXV1dYV1dYWFRVV1ZZV1hXWFdWVlhWWFdW VlNTVVVWVFZWVVZVU1ZWU1NVU1lWVlZWVFRTVlVXVVVUVFNUVldXV1dXWFhWVlZWVlZVVVVVVVNT U1NWVlZWVlZWVlZWVlRWVlZUVlZZWFxUVFpYVlZWU1NXVlZVV1ZWVlpXV1haV1ZaVlZUVFZVVlVU VFZTVFZcV1dXV1dUVFRUWFhYWFhYU1RUVFRUVlRWVFNYVlZVV1VXU1NTWFhYVlZcXFlQU1NUVlZW W1lTVFRWWFNUU1NWVlZWVlZWVlZWVFRYWFhWW1dXWFlXV1lZVFVYV1pYWVdZV1ZXWVdaV1ZXVFNV VVZUVlZVVlVTVlZTU1ZTWVZWVlZVVVNWVlhVVVVVU1VXV1dYV1hZWVZWVlZWVlVVVVVVU1NTU1ZW VlZWVlZWVlZWVVZWVlRWVlhYXFRUW1lXVldTVFhWVlVYVlZWW1dXWVtYVltXV1RUV1VWVlRUVlNU V1xXV1dXV1RUVFRZWVlZWVlTVFRUVFRWVVdVU1lWVlVXVlhUVFNZWVlWVl1dWlBTU1RWV1dbW1NV VVdZU1RTVFdXV1dXV1dXV1dUVFlZWVdcWFhZWVhYWVlUVllXW1lZWFlYV1dZWFpYV1dVVFZVV1RX V1ZXVlNXV1RTV1RZV1dXV1VVVFdWWVZWVVVUVVdYWFlYWVlZV1dXV1dXVlZWVlZUVFRUV1dXV1dX V1dXV1dVV1dXVVdXW1ldVFRcWVdXV1RUWVdWVVlWV1dcWFhZXFlXXFdXVFRXVldWVFRXU1RXXFhY WFhYVFRUVFlZWVlZWVRUVFRUVFdVV1VUWVdXVlhWWVRUU1paWldXX0BcUFRUVFdXWF1cU1VVWFpU VVRUWFhYWFhYWFhYWFVVWlpaWF5ZWVpbWVlbW1VXWlhdWltZW1lYWFtZXFlYWFZUVlZYVVhYV1hX VVhYVFVYVFpYWFhYVlZUWFdaV1dWVlRWWFlZWllaW1tYWFhYWFhXV1dXV1RUVFRYWFhYWFhYWFhY WFZYWFhVWFhbWl5VVF1bWFhZVFVaWFhVWlhYWF1ZWVteWlhdWFhVVVhXWFdVVVhUVVhAWVlZWVlV VVVVW1tbW1tbVFVVVVVVWFZYVlRbWFhXWVhaVVRVW1tbWFhAQFxQVFRUWFhYXVxTVVVYW1RVVFRY WFhYWFhYWFhYVVVbW1tYX1pZW1taWlxbVVdbWV1bW1pbWVhZXFpdWlhZV1RXV1hVWFhXWFdVWFhU VVhUXFhYWFhWVlVYWFtYV1ZWVFZZWlpbWltbXFhYWFhYWFdXV1dXVFRUVFhYWFhYWFhYWFhYVlhY WFZYWFxbQFZUXlxZWFlUVVtYWFVbWFhYXlpaW19bWF5ZWVVVWVdYWFVVWFRVWUBaWlpaWlVVVVVb W1tcXFxUVVVVVVVYVllWVFxYWFdaWFtVVVZcXFxYWEFAXVBUVFVXWFleXVNVVVlbVFZUVVlZWVlZ WVlZWVlWVltbW1lfWlpbXFpaXFxVWFtZXltcWlxaWVlcWl5aWVlXVVdXWVVZWVdZWFVZWVVVWFVc WVlZWVdXVVlYW1hYV1dVV1laWltaW1xcWVlZWVlZV1hYWFhVVVVVWVlZWVlZWVlZWVlXWVlZVllZ XVxAVVRfXFlZWlVVW1lZVltYWVlfWlpcQFtZX1lZVlZZWFlYVlZZVFZZQFpaWlpaVVVVVVxcXFxc XFVWVlZWVllXWVdVXFlZWFpYW1VVVl1dXVlZQ0NfUFVVVldaWl9fVFZXWl1VVlVVWlpaWlpaWlpa WlZWXV1dWkFbXF1eXFxeXlZYXVtAXV5cXlxaW15cQFxaW1dVV1haVVpaWFpYVVpaVVVYVV5aWVpa V1dVWlhdWFhXWFVYWltbXVxdXl5aWlpaWlpYWFhYWFVVVVVaWVlZWVlaWlpaWlhaWlpXWlpfXUNV VkFeWlpbVVZdWVlXXVpaWkFbW15CXVpBW1tWVlpYWllWVlpVVltAW1xbXFxWVlZWXl5eXl5eVVZW VlZWWldbV1VeWlpYXFhdVlZWXl5eWlpFRUBQVVVXWVtbQUBVVldbXlVXVVZbW1tbW1tbW1tbV1de Xl5bQ1xdXl9dXV9fV1leXEJeX11fXVtcX11BXVtcWFZZWVtXW1tZW1lWW1tWVlpWX1tbW1tYWFZb WV5ZWVhYVlhbXFxeXV5fX1tbW1tbW1lZWVlZVlZWVltbW1tbW1tbW1tbWFtbW1dbW0BARVZXQ19c W1xWV15bWlheWltbQ1xcX0ReW0NcXFdXXFlbWldXW1VXXERcXVxdXVdXV1dfX19fX19WV1dXV1db WFxYVl9bW1ldWl5WV1dAQEBbW0hIQ1BWVldaXFxBQlVYWFxAVlhWV1xcXFxcXFxcXFxYWEBAQFxG Xl9AQV9fQUFYW0BdREBBX0FfXF1BX0RfXV1aV1paXFdcXFtcW1hcXFdXW1dBXFxcXFpZV1xbX1tb WVpXWl1eXkBfQEFBXFxcXFxcW1tbW1tXV1dXXFxcXFxcXFxcXFxaXFxcWF1cQ0JIV1dFQV1cXldX QFxcWUBcXFxFXl5BR0BcRV1dWFhdW11bWFhcVlhdRF5fXl9fWFhYWEFBQUFBQVdYWFhYWFxZXVlX QVxdW19cQFdXV0JCQlxcS0tFUFdXWFteXkZEVllZXkJXWVdYXl5eXl5eXl5eXllZQkJCXklBQUJE QUBERFlcQV9GQkRAREFeX0RARUFfX1tYXFteWV5eXF5cWF5eWVdcWEReXl5eW1tYXlxBXFxbW1db X0FBQkFCREReXl5eXl5cXFxcXFhYWFheXl5eXl5eXl5eXlteXl5ZXl5GREpYV0hEX15AV1hCXl1a Ql1eXkhBQURJQl5IX19ZWV9cX15ZWV5XWV9LQUFBQUFZWVlZREREREREWFlZWVlZXltfW1dEXl9c QV5CWFlZREREXl5NTUdQV1dZXV5fSUZXWlpfRFdaV1hfX19fX19fX19fWlpERERfS0JCQ0VCQUVF Wl1CQEhDRUFFQl9ARUFIQl9AW1hcXF9ZX15dX11YX19YV11YRV9fX19bW1hfXUNdXVtcWFxAQkJD QkNFRV9fX19fX11dXV1dWFhYWF9fX19fX19fX19fXF9fX1pfX0ZFTVhYSkVAX0FYWUNfXVpEXl9f SkJCRUtDX0pAQFpaQF1fX1paX1daQE1CQkJCQlpaWlpFRUVFRUVYWlpaWlpfW0BbWEVfX11CXkRZ WVlGRkZfX3BwSVBYWFpeQUBLR1daW0BGWFtYWUBAQEBAQEBAQEBbW0ZGRkBNRERFR0RDR0dbXkRC S0VHQ0dEQEJHQ0lEQUJdWV1eQFpAQF5AXllAQFlYXllHQEBAQFxcWUBeRF5eXF1ZXUFEREVERUdH QEBAQEBAXl5eXl5ZWVlZQEBAQEBAQEBAQEBdQEBAW0FASUdwWVpMR0JAQllaRUBeXEZAQEBMRERH TkVATEJCW1tCXkFAW1tAWFtCcEREREREW1tbW0dHR0dHR1lbW1tbW0BcQlxZR0BBXkRfRlpaWkhI SEBAcXFKUFhYWl5BQUxHV1pbQUZYW1hZQUFBQUFBQUFBQVtbRkZGQU5EREZIRENISFtfRUJLRkhD SERBQkhDSkRBQlxZXl5BWkFBX0FfWUFBWVhfWUhBQUFBXV1ZQV9FX19dXVldQkRERkRGSEhBQUFB QUFfX19fX1lZWVlBQUFBQUFBQUFBQV1BQUFcQUFKSHBZWk1IQkFDWVpGQUBcRkBBQU1EREhPRkFN QkJbW0JfQUFbW0FYW0JxRERERERbW1tbSEhISEhIWVtbW1tbQV1CXVlIQUFfREBGWlpaSUlJQUF1 dk1QWVlbQENDTktYXFxDSVlcWVpDQ0NDQ0NDQ0NDXFxJSUlDckdHSUtHRktLXEBJRU9JS0ZLR0NF S0dOR0VFXlpAQENbQ0NAREBaQ0NaWUBaS0NDQ0NeXlpDQEhAQF5fWl9ER0dJR0lLS0NDQ0NDQ0BA QEBAWlpaWkNDQ0NDQ0NDQ0NDX0NDQ11DQ01LdltbcUtEQ0VaW0lDQ15JQ0NDcUdHS3NJQ3FFRVxc REBFQlxcQ1lcRXRHR0dHR1xcXFxLS0tLS0taXFxcXFxDXkVeWktDRUBHQklbW1pMTExDQ3p4cVBb W15BRUVwT1ldXUVMW15bXEVFRUVFRUVFRUVeXkxMTEV3SkpMTkpJTk5eQ0xHc0xOSU5KRUdOSXJK R0dBXEJCRVxFRUNFQ1xFRVxcQ1xORUVFRUBAXEVDSkNDQEFcQUdKSkxKTE5ORUVFRUVFQ0NDQ0Nc XFxcRUVFRUVFRUVFRUVBRUVFX0ZFcU53XVt1TkdFSFxdTEVGQExFRUV1SkpOeExFdUdHXl5HQ0dF Xl5FW15HdUpKSkpKXl5eXk5OTk5OTlxeXl5eXkVAR0BcTkVHQ0pFTF1cXHBwcEVFfn90UFxcXkRI R3ZxWl9AR09cX1xdR0dHR0dHR0dHR19fT09PR3pMTE9xTEtxcV9ET0p2T3FLcUxHSnFLd0xJSkNd Q0NHXkdHREdEXUdHXV1EXXFHR0dHQkJdR0RNRERCQl1CSUxMT0xPcXFHR0dHR0dERERERF1dXV1H R0dHR0dHR0dHR0JHR0dASEdycnxeXXlxSUdLXV5PR0hBT0dHR3lMTHF7T0d5SkpfX0lESUdfX0dc X0p/TExMTExfX19fcXFxcXFxXV9fX19fR0JKQl1xR0lETEdPXl5ec3NzR0diYndQXV1ARUpJenRb QEFJcl1BXV5JSUlJSUlJSUlJQUFycnJJfU9PcXRPTnR0QUZxTHpxdE50T0lMdE55T0tMRF5ERUlA SUlGSUZfSUleXkZedElJSUlDQ15JRk9GRkNEXkRLT09xT3F0dElJSUlJSUZGRkZGXl5eXklJSUlJ SUlJSUlJRElJSUJKSXZ1YF9ffHRLSU1eQHFJSUJySUlJfE9PdH9xSXxMTEFBS0ZLSUFBSV1BTGJP T09PT0FBQUF0dHR0dHReQUFBQUFJQ0xDXnRJS0ZPSHJfX0B2dnZJSWZnelBeXkFHS0t8eVxCQkt0 XkJeX0tLS0tLS0tLS0tCQnR0dEticXF0d3Fwd3dCSHROfXR3cHdxS053cH1xTU5FX0RHS0JLS0hL SF9LS19fSF93S0tLS0VFX0tIckhIRUZfRk1xcXRxdHd3S0tLS0tLSEhISEhfX19fS0tLS0tLS0tL S0tGS0tLQ0xLendnQ19gd05LT19BdEtLRHRLS0tgcXF3Y3RLYE5OQkJOSE1LQkJLXkJOZXFxcXFx QkJCQnd3d3d3d19CQkJCQktFTkVfd0tNSHFLdEBBQHl5eUtLamt9UF9fQUdOTX16XUJDTXdfQ19A TU1NTU1NTU1NTUNDd3d3TWVzc3d6c3J6ekNKd3Bgd3pyenNNcHpyf3NPcEdAR0hNRE1NSk1KQE1N QEBKQHpNTU1NR0dATUp1SkpHR0BHT3Nzd3N3enpNTU1NTU1KSkpKSkBAQEBNTU1NTU1NTU1NTUdN TU1ETk19emtEQWR6cE1xQEJ3TU1Fd01NTWRzc3pnd01kcHBDQ3BKT0xDQ01fQ3Blc3Nzc3NDQ0ND enp6enp6QENDQ0NDTUdwR0B6TU9Kc013QUJBfHx8TU0TE2RQQUFFTXJyZ2JfRkZyfUFGQUNycnJy cnJycnJyRkZ9fX1ybnl5fWB5eWBgRk59dWh9YHlgeXJ1YHloeXR1S0NKTHJHcnJOck5DcnJDQ05D YHJycnJKSkNyTn1OTkpLQkt0eXl9eX1gYHJycnJyck5OTk5OQ0NDQ3JycnJycnJycnJyS3Jyckdz cmRgE0dFbGB1cndCRX1ycUl9cXJybHl5YG99cmx1dUZGdU50cUZGckFGdRJ5eXl5eUZGRkZgYGBg YGBDRkZGRkZySnVKQmBydE55cX1ERURiYmJychsYalBDQ0hwdnZraEFISXZjQ0lDRXZ2dnZ2dnZ2 dnZJSWNjY3YVfn5iZn5+ZmZJcWJ6bmJmfmZ+dnpmfm5+enpMRXBwdkp2dnF2cUV2dkVFcUVmdnZ2 dk1NRXZxYnFxTU5FTnl+fmJ+YmZmdnZ2dnZ2cXFxcXFFRUVFdnZ2dnZ2dnZ2dnZOdnZ2Snd2aWYY SkYTZnl2e0VHYnZ0TGN1dnYTfn5mF2J2E3p6SUl5cXp0SUl2Q0l6Fn5+fn5+SUlJSWZmZmZmZkVJ SUlJSXZNek1FZnZ6cX50Y0ZGRmhoaHZ2AwERUEVFTHR7ehVtQktLemhFTEVHenp6enp6enp6ekxM aGhoehxjY2dsY2NsbEx1Z34VZ2xjbGN6fmxjFGN+fnFHdHN6Tnp6dXp1R3p6R0d1R2x6enp6cHBH enVndXVwcUdxfWNjZ2NnbGx6enp6enp1dXV1dUdHR0d6enp6enp6enp6enF6enpNe3ptbQFMSBps fnpgR0pnenpwaHl6ehpjY2weZ3oafn5MTH51fnlMTHpFTH4BY2NjY2NMTExMbGxsbGxsR0xMTExM enB+cEdsen51Y3loSUlJbm5uenoMChhQR0dOd39+GRVETk5+bkdPR0p+fn5+fn5+fn5+T09ubm5+ BGhobRJoaBIST3ltYx1tEmgSaH5jEmgbaGRjdUp3d35wfn55fnlKfn5KSnlKEn5+fn50dEp+eW15 eXR1SXViaGhtaG0SEn5+fn5+fnl5eXl5SkpKSn5+fn5+fn5+fn5+dX5+fnBgfhUUCk9MAhJjfmVJ TW1+fXRufn5+AmhoEgdtfgJjY09PY3lkfU9PfkdPYwVoaGhoaE9PT08SEhISEhJKT09PT09+dGN0 SRJ+ZHlofm5MTEsVFRV+fjQzHlBJSXJ7Y2IDGkZwcGITSXFJTGJiYmJiYmJiYmJxcRMTE2IMbW0T GG1tGBhxfBNoAxMYbRhtYmgYbQFtaWh3THx6YnNiYnxifExiYkxMfEwYYmJiYnd3TGJ8E3x8d3hL eGZtbRNtExgYYmJiYmJifHx8fHxMTExMYmJiYmJiYmJiYmJ4YmJic2RiGRwyck0JGGdiakxPE2Jj eBNiYmIJbW0YDhNiCWhocXFnfGlhcXFiSXFoM21tbW1tcXFxcRgYGBgYGExxcXFxcWJ3aHdLGGJp fG1hE05PThsbG2JiUFJRUFBQVVBVUFBTUFdQb+RSUahWV+hSNhBDUFVUqFNQWldUqFFQSVhWVahS U+hRGuNZ8oxIe0CmbK1sHkCkbB2tbFBvbK1sQKxsrWxhYHFBcUF1cUFxUVBUUKxwU5CsEFVQq1Bw VJBQUlDKr49S2lU7UERQcFAS41pTUFHoU/8QWUUeS1lyR0dKXepRFVBWUXLiUPZR6FE/50geTklx EgtIex5ApB29pL2krR4VNRS2UG8draZsb2FgUXNmZmdCZ2ZnZmNiRkVEV1ZTVldWU2JGRURWc3J2 ZWRmURN2YXhJYltEfUV1THdDeSlqVkPSe2xse3psbFEa5e/KUW5lCn9HfHV5b9qulcVBaK7NbHt6 bGx6e2xQUlF2U3NTzlU7UEBQT1ApEHcqX1FbQFtPS0BLT1RwUHBByED5QFRpVmlOHFYUXhNfVUBb UE9KQVDoUdTiWFhB6FHUEF1HU3FHR0pbvVCaSr1B6K+Q4mNlQeiv0Od8ZUFJcPKXSHseQKR7ex2t pq0eFTUUtlBvHb1sQL1RQUJpQUJpYWAhDQ1QDVFDZmdmZ2ZmY2JGRURXVldTcUNmZ2ZmY2JGRURX VldTUsVNXFReREBtc3N3XnZJ3a4yT11dQxd6c3laXmvbU3NRdCJEEHJJc3ZPSng5Y66LUXgvfG5n eE5ITXosrolQUFJQda+0U4tVO1BLUE9RzhD5SFRITVJRUFlSRVRQWVNEVVBZVkFYUFlXQFtLWldA XEhdV0BfR15XQEJHXlZBQ0deU0RGR15SRUlIXVJFSktaUkVMS1pTRE1IXVNETkhdVkFPS1pWQVpL S3lQWURQUFleR0d5SF1ESEhdQUJCTk5PT1VVVnlXV1hYW1tcXF9fQFZeXV1aWllQU1RUTExNTUND RHlFRUZGSUlKSlJRS0hIR0dQWl4NQF1RXehTWuJaDVnoUnDjV18NXOhTWhBdWw1Y8VdXVkBBn0IN TuhTWuJPDVXoUqvnVlZSU59UDUzoU1riTQ1D6FKr5URERVENSuhTWuRJDUbxRehScOVHDUBIUUjo U1oQW0sNUBBCSWRQmnBx6FID43HApkh7e6Z7raYNraSkra69QGxApK2uraRsbECkra6tpGxAbECk ra69QKStpg29UG9sQGxAbH9sbEBsQGxAbECtbEBsQGxAbEBsb2xAbEBsb2xAbEBsQGxAbECtbEBs QGxAbEBs11V+ey1AlNd+SHstQJRfX19fX19fX19fX19fX19fYWBRDUdDc2VjQ3FlcUNjU3FDY1Nj RXNTY0VxU3NDcVNDcUNxIw376xWvUFFDCwMLUQExAw/66RavrqANAQuu/Q8+UQMYrvtMUZcCUQcA UZeuaVGXrmkArvkCrmlRl65pUklRB1BTUAavKVO5VcpQfFBlUG9R3xAE42Tpb1JYXlhLxFD0UOlA 6WZWSEsmUSpu1FBUWWZvUVBycXFaXEZHZX1PcHFaWqpbcERbW3BbWlxZRmZHb2VRfVBPcnBxQHdf ck9QZVFHb0ZWZn126lLPUHVS8+JycXARW1GqUHhQclHIUE9QUFHIUH1ROFBPUcfkf6lNVUDvUs5Q X1LzUFxQZlHIUEZRq+JcW1roUT7leFxZXVtb6FE44llaWuhTKuNsWXFx6FE44llwcOhTKeJiWXfo UTjnD3Y/di92U3bqUapQdVNd51X7X2xPbFJs6FJ/4mL7SupRPlBBUTgQX9BAwEDwQFMAQDBAIEBT QOhRqhBEH18PX/9fU19JWxB4cEBbR1sQWpjpUUZQSHt7QGx7e2x7QJBRHqQNHaQNDb2kvaQNraSk Db17KkCiUUh/eyqxUUh/eypAolFIf3sqsVFIf1BvbHukbFBArbVArb1vvaSttUC1e6xsUECtvUFC R2lCaVFBQkdp1357LUCUQGxsXpRslGzXXkBsbGxsVZSUYWBRDQ1QDVFTRkdGRURWVndXc2d2dndD Y1ZFREZHQ3Z2ZWRmY2JHZ2NXRkZHV3NmZWR3dnd2c3JWRURGR1NGY2JmZmVkdndTXNvMb3zRhPRw EnMAO28CeVsFHP7WOo/ScWhHEEoVAmYSeVR3RyR9SQYsbgf+Tl8UyQMdNlVUrnArOxwPIII1UiUl QGBhUUsQex0qSlI0OfsxxuVWHgdEf2ChfkwEEXZiV9ExaDsdrIpTHNweEtMIUFBVUMCvmVbZVTtQ U1BfUE9QfFBsUJ7kbtBrZVbor44QXmJlZGgQW15kSxBbXmRg6K+Q41teZEPor5AQRVteZEdDSEtH YEhoVFNQVVJRW0hpWuhRYeZAaVRVfWlw6FFhEF9laXddbhBJZW5HR0pzE2roUXrmYhN6U7IQUOtR 11BwUHpRGuRXUbIQUuhR1+NwVxNN6FF64kUTXeiv0BBcSkxkcF1RXUltEgtIex5ApA17Ha2mrUlK rUhKvUCmSUqtSEq9QK2mrR4VNRS2e1BvHb2tvW+9rb1vbG9sYWBRDXt7e3t7e1FRc1FxYkZFRFJz cnZlZEJHcldWUkVERmNiZ2ZCZWR2UWJGRURWVnNydmVkQkdyV1ZSRURGY2JnZkJlZHZW2ao2D1XK q6MO2qTZNdyrwmF5GDpsentwFydrUxwx3CPnBDTbqcNjdhQha3hgchciaVU7qg9V8cYq6q6kySjl UUB7dxKuiC1mEU4SUXfUaBKtDcctIoYoxCTpUUN5dG+ugilnEnETUXolbRNQUFNQMq+xVY1VO1B/ UGxQGFCI4wp7UVHoUf8QclVSbVFQ5nx/bVBgTG14VF9yFnpXf1J8VkJQUVFfZx9yU0LrU8lQRVBc URAQSFluXxNuRUVfWRrQa21kGkdHSlFrXPYQW+hR0eNX9nB66FEh5XgBYEL2FuhRdeVtAUx1E2Ts URpQYFJYUExT+uJqDk/oUVgQWxAeSBBrbWRISRkm6VFlUEh7HkCkex29pL2kraa9QKWktUClSaZK rUimSq20HhU1FLZ7UG9sHUC9QK20QLRvvUJpf2xCR2lBQkdpQL1RQKVQQL1RQKVhYFENUXFFVlZX VldGY2JnY1ZWc3J2d1ZWc3J2ZWRnZnV2dmVkZmNiRkVEVldCR2ZlZHZ3dWZnZmVkdnNyVkVERldW VkVERmNiZmd2UlRlUcUIPhszESfaBRV9bNYMMNwVP5kq5ZXHM1FgVVWGxzYn/I4YOct2Y69QyGUZ FmgYNFrFkfrx0RchMxAnUpd2XBg8wAWZGQIZFwQDGOzH49gIN3YTTJy8IQU7lBiuhpnrIEhwU50R awIxEBouwXIF4hiBIC71exY0URJQUFFRXVNzUkdVO1BeUGcQWlteS15wUFNeWVDoUdTmVlNAR0dK WehR4OVQSV/sq0h7HkCkHa0eFTUUtlBvHb1RQWlhYFENUUNmZ2ZmY2JGRURXVldTUV1PXV1DFXt0 elpdbdpTc1F4LnxvZ3hPR0x20a6JUFFQ3K4aU9pV3lBAUGznV1hRUUNZQULoUdHjX1D2UehRFeNV WmtZ6FEG5V8TVUlBEulSQFBIex5ApB29rbRArb1AtlBvb2FgUQ1RV3Z3dmVAZ0JRR1ZXVlJFRFHR cidkeMXnUcpI6SXC6q4KQLP+2NpREq9RaFF4c9n6hK34puxQUa9xrhpST1XeUEBQE+dZWFFRQVlD QehR0eNfUPZR6FEV41Vaa1noUQYQWl8TX1VPVVJVSkLoUbjhAEh7HkCmDR29rbRArb1AtlBvb2Fg UQ1RZ0ZHRkVAV1JRd2ZnZkJlZFF6cidjecXorjdI6SXC6lUrQ7L+2Nqu7a6ul66IT9r5hFIJpuxQ UFFQwVIAUyBV3lACULXmqWRRWWRRTOivjuNAQ2QU6K+OEF5AQ2RIckBDZBhyQENkTuivjuN1d2RV 6K+O40xNZGDor47jen1kVeivjuN6fWRV6K+OEHRyd2QBGRNpVGIcZBZmVEp7d3RNR0BUT1pdUHdm YlRae1RPb37oUXLmclBsQGxSbOxR01BCU/pQH1Fy5FdQUPZd7FP5UEVT+lBPUS3id/Zm6FP55W9v XxxRHOhRGuMD8itIe0CmDWxAra2tpK29UG+kpK0NbLRRQUJHaUFCaWlBQkdpQUJpQUJpaUFCR2lh YFF7e3t7e1B7e3t7USIhUXZ3dmVkZmNiRkVEVldmZ2ZmY2JGRURWV1ZXRkdGRkVEVnNydnd2d0ZH RkVEVnNyd3ZlZGZmZ1ZXVldWc3J2ZWRmZ2ZnZmd2d3Z3dmVkZmNiRkZRvlRIcmF0T35lVmd8FBJy cX0S1B1jZBspG31OThlueW1SRXRgS3VORX5cVWt8GXVKTHJgeXlLMG5rZhsrTX19TnEaPlREFRQy dWRmZmJ98RRzYh92fU91ak1BRkteRhJ3Tnx6GWF7aRMme3hnTUV+YNdjYndgAkZAfkxJZ0JcRF1J S19KRXF/S316L1BRUHVQ3VQLVJNQW1ATEHZWh1cNWodbW1BYeVmHUFWHVA1Rh1BYh1ZbeVVQhy9S UVJJXM+mSHseQKQNHaRsrWy0UH+krbRApL1AbECkrbRhYHVBcWVxQWNBcUVxQVJGrl9RoQJRo65d 3VGjAlGhrl8Crl1QUFGvu66vUUBQ5FBEUH8QXFBERL9vXlEvXlFeQepRJFBUUuXnUG5bSUU9pUh7 HkCkHby0vVB/DSG9QJlhYFdmZ2ZlZHd2dnd2ZWRmY2JGRURWV0Ubf3RWVGBTV2t4eW/c1bFyZHh1 Ql9YYFlBRntuEmIJ5mJQUVBmUSpSNVGvUFNQTONQ01JR6FNB5lVSSVQ93kh7HkC0HUC0UH+tYWBR V3FnUjV5rap5Ua/V1VBRUBWvuVFAUONQW1BO6VBQU8HiVltT6FEk5VlJXD2lSHseQKQdvVBvrWFg Z2JGRURWc3J2ZWRm+ntrbHp6a2vja3p6a2t6emtQUFGv66+xU11V3lBTUBYQcjdQKFP3UFNTUFFR eVJTRFJSU1NQUVJRW1MNUEpVUQ1SSVTqUbxRJFBIex5ApB29HkCmHb1Qb2xvbNdVfnvXLZRhYFEN UVFzUVNdrVYIUq9V3qoDVf1QUFJQKq+4U6NVOFBCUHRQ3BAeZUZrcBhWGlcZTh9PHHAERwpwNEY0 Rz5OPk87cCZfI0YkRy5PK3DSRtVH3XDFRsFHznDzRfRG8Uf7Tv9w6VLkReJG5EftTu9wdEOpUFVM 6FE3EEpaXUn70F1RXUl1cvvQU59Tj1O/U69TVVNKdupRTVFGUEh7HkCmDR29HkCkDR29UG+9b71h YFENUWJGRURSV1ZXVnNydmVkZ0JnZkdyVlJXUkVERmNiZ2ZDQkFkdlKU0P/SJg43bB/S/wg38DnT aicvahsKEG17IwLVClU4hreWrjTHJ2VOhri1t1Fe3AxkC66ws66HgTg3eDxRVVH7UVs/OVBRUC1Q UFMHVThQS1CaEEpXSlEGUjdSJlIkU+1dVVhQWEBHUUdfVFhfWehRaONYV1FWEVtRaFBXUEpR81BA Ul5QeFBJUWhQSlGtEENQQF9RU1BYeEBfX7ZRUERRUVBJ6lGkUEpTXRBZS0tQVVhXXFBR61N4UEBQ SlJb409fUV/oU3cQW0BRTHhQQFFHUUxa6lJ4UbNQSHt7QGx7e2x7QJBRe6YNtGylbFBvbG9sQKS9 115+ey1AlHtBQkdpSFBApb17rFGlUEC9UUCQUEC9UUCQYWBRDQ1QIVFRVkVERkdXcWdmZ2ZnZmdD ZmdmZWR2c3JXd3VTB67uTGMOWq2tXgJKekVxcrhFUlN2cUpnXVEBVTirzzN8dXdXdXVSW0JOfidT dRlbRENzeFx0DlBRUHBQUFOQVThQTVDxEHHfWNZbzFjGWvxY+1zvWOpcnlieSFq/U7pUu0a/R1Rb XE3tUfNQSVBJUSdQTFFoEEVNU0dIVEZVUkVEQ1NCVlNHVEZUUVvoUlIQXFn7X1VJSLZQUFFcXO9S R1BSUadQTlBWUXFQTVJS4kJKT+pRplG/UEh7HkCmHbS9QKa0UG9sQK1sb620QkdpUUFCR2lCR2l+ vbxQQK1RQJlhYFANUQ1xcWVQQ2ZlZHZzcld3ZmZjYkZFRFdWV1ZRcWJmZ2NSk60NUlT2HdA23Qtz Y5Qi0eBPYNGUrulRBAI6R3h1UZRRUSfTONPXQNHf4S4IGyXBjq6PFGlQUFFQFK+4U/FVOFB+UJ3p UESvkBAWQUxvDX09fSR2LX3efcp99Vr5SP9961LrV+Va6UjvfV4OUA9RUjVEJURSVVJZX1x5U1ZT RlN0RM19+n3ufaVFV1RERERSROpT3lBQUaTjUVFecupTXlB4UTziS11b7FHHUFpSUlBYUTziXlV7 7FFxUEdTXVBVUXHmEEFRf0FRQe9RzlBgUFpRpFBbU19QUVJH439PUU/sUw1Qf1CYUwxQSHtApg2k pL1Apg0hvaS9UG+tpLRvvb1CaX+9tA1hYFANISFRIQ17UWVmZ2ZlZHZzcld3ZmZjYkZFRFZXRkZF RFZWc3J3dmVkZmNiR05SY2JmZWR2dlFpoicGNBcgB3Vk8zEmwtn3ODrAq9ouEXtjdUpKQC0WdQol H/pStU11Oxw5HzfbWyQn3TwM+hN78SEtq9l8TnhzYlhVFkeBJjDGDVBSUBCvuFO1VRxQWlBdUR4Q e15bUStbUV9SWFxjUGZUZ1sjWtdV11abU4tTWllbWVw1WiVaVARaUTZaUVXor47jR0lkVuivjhBs R0lkUVxSUFVUWFNQVVdYU1tWXVxSW1ZQVVW2VltEVlZbWllZqlxbRFxZWFxbWFlaW1xdV1RTUlFb X15Z61HIUFJQXFLz5VNYWFVQW+hSzxBaWnhaUFRWeFVdU+tS91BSUFJSUuNQWVpa6FGq5ltZUFBZ VVXoU3jlWVZWW1lZ6lNfUFhSUeVcXV1cW1vrU3lQWVBcUlsQW1ZeeFtAVkdWXlqY6VG7UEh7e0Bs e3tse0CQUaR7KrBRSH9CaX9ArbR7QGxRf3sqoVFIf3tsUX97KkCwUUh/eypAoFFIf7RQb3tsUG9s e0C9UEFCaX9srWy1UUFCR2nXWH57VS1AlNd+SHstQJRfX19fYWBRe3siISENUA0hUVFjV3NTc0Nx Z1FTUXFTta6t8nT0OcM6rkZ6U3/CrelRwVUcrNQsrsRRPNxTPK6urdZQUVAZr7hThVUcUHJQkRA/ VnJCaVRyQmlxV3twYFdscABVAlYAVzFVMlYyVyFUIVYjV9JU0lbUV8FUwVbwVPNW5VTpcEYuVFFY TEhMFFfyVqVWVXFIRlNOQlFSdFhIS3FyRVNUVKpyUERyclByVFNQVE5CVFNycl5SU7ZRUFRL6FE8 515dQklzTvtY7FJZUHRQmFFGUEh7QKa9HkC0UG8dvW9srWxCaX9CaVFBQkdp115+e1UtQJRQQUJp QmlRQUJpaUFCR2lhYFENIVANe3tRcVdxV0ZHRkVEVlZXVnNyd3ZlZGZjYkdGR0ZjYmZlZHZ2d1JA UZV+rjkb8grbN8UFJCY1a3hkdmUReEpFTSHuNczSVRz190obJYLbsch8bHxOfnRjZXFbWbHkLeAY XlBSUNGvuFRkVThQRFByUJLlWEJIQlJI6K+OEBxHaU5yR2lyRWZTY0USUxJFOkwqTNJb0EnfT8Jb xEnKTvRT/13xRvtO5FPjV+VG7EyURUZYS0dFSEtTFFQJQVJRUFRFR0VKVHBTUlBW6FHL43BwXFHo UTfmUFVKqVxdTehRcRBbf1lvWVJfWU9ZUlnoUlIQWZ9RUVFKdEf7X+xSUFBzUU1RbFBIe0CmvR5A pg0dpA0NvVBvvW+9Qml/rUFpaUFpQmlRQWNjUECZYWBRIQ0Ne3tQDVFFVlBXZmNiRkVEUHNydmVk QlBnZlFSRURGY2JCZWR2c3JWVGT7ru4pPBQv466c4vL37lEV/ziuU988FiOXJAJzb1U4d3iur5l+ 6My/rv6/zZ1R31FOFHit8a6fnzsrUR+NJtBHUFBRULivuFRgVRxQWlD06VBUr5DjbgBkVeivkONu AGRU6K+Q43NtZFXor5AQXXNtZGlSalVSWVpVVFToUc0QXFNSRFNTUlRTWlJQWuhSUhBZVVa2UVBU U11Q6lN4UFlROOZPWlFaSVtU7FGrUFNTdlBVUyvkUU9SUVLsU19QXFJCUWxQSHtApA1svaS9HkCk DR29tFBvb2ytbLRCaUFCaddefntVLUCUUUCZYWBRDXt7e3tRcUVRd1FxclZXc1HdUvOtWABSya7u 1TEQeVUccqrudVTwfwtQU1Aer7hTuVU4UEdQdFBgUJXpUHWvjhA5QGlXQTtc1UfVSVRJVWpdaXcZ XRp3BFE0USBVJXQrYNNR1UjTdNV62nzPW8tdykzLdsV6zmD6QPtM83T5df9g4FHsXOxd6kDvTLt8 cHVIXFBUU191SFxQVHtOqUJVe6lWXXH7UF9AX1Jf6lJQUHhR8hBbX1lPWVJZSWF++1PqUaJQS1Hy EF1vRTBF0EWwRVRFSmKY6VFGUEh7HkCmDR2tpr0eQKQNHa2mDb1Qb71vvUFHaVFBQkdpYWBRDVAN e1FGRkVEVnNydmVkZmd2dmVkZmNiRkVEVldmZmVkdnNyVkVER0ZXVlZFREZjYmZlZHZS4zAJqObz nfe4CW+Xx8Dmw5o8JyMNCT5Nek3Fydc+IswLUqc45gvzo5bUIYo1Pd4W1ZD2Pz7kQHX4PTYlIAkT aQS0brvXPdXwPwTpUFJQa6+4U71VOFBHUHVQkelQca+OEB1HaUtyR2lUchNlalTuW5pJU1dOSEhG TlNrVRtVNk8sSCZP2kvScs1Iy0vEcvxV/Fv6QftI+0z2cutV5U9CBURRUVBWSEpITVZzVVRQWehR y+dzc1BNqV9VUehRNxBCUF1K+z9CsEJSQkp3X1FPUVJw6FFx47BcUVzoUlLlP1FRUUl26lHJUUZQ SHseQKQNHaQNvQ0eQKYNHa1Qb71vvUJpf61BaWlBaUJpUUFjY1BAmWFgUSENDQ17e3tHZWZnZmZn VlZzcnZlZFBjYkZFRFJQV1ZRQmVkdnNyUkVERmNiZms3HNeHBG0UesfwUWf/z/rsru7hOVGt3TsX JpM/BHYQSHBGehqKwE5Cntm/UQa/8JuuJK6yFXlSCVFOsT0oruazKCtHUFBSUCqvvVJJU9pQW1BH UGfpUFZTweJQV1zoU8HiQltT6FEk4lkjX+hRJBBbX0VPRVJFSUg+AEh7HkCkDR2tpr1Qb71vvWFg UWJGRURWc3J2ZWRmU2JGRURWc3J2ZWRmUeN6bGx6emxs+npqa3l6a2tT2mt6emxsenprrXxrenlr a3l6a1BSUHSur1JMU9hQW1BxUBTiXHFW6FPBEFlQV3G/L0lRSVPoUSTiWSNM6lEkUF9S5RBdXG5f Rk9GUkZJcj4ASHseQKQNHby0raa9UH8NvW+9QJlhYFFiRkVEVnNydmVkZlFmZmVkd3Z2d3ZlZGZj YkZFRFZXVldR5npsbHp6bGuuyTliV1N9VFhsd3puGxJIPVPYa3t6bGx6e2urymwTcERfWWNbQUR6 bhJlE9FkQmhQUFFQd1DrVAtUxFBWUNkQeWdTJ1NSR1N3U1JUU1N5VlVEVlNSVlVSU1N5UFFEUFNU UFFSUVVTWFRR7lNLUFBT9VBWU/5QU1NLEElwVVO1Vl9QUVBJV1RVVVJSX1FRUUpYEgBIex5Apg1s QGxAbECkDWwdvVB/SUqtvb29UUFCR2nXWH5Ie1QtQJTXWH5Ie1QtQJRhYFEhDUNRRVFRRVF3VGSs MlPOq5xSklGCB64+rjoKUYZQUFJQdVGLVAxTI1BTUFdQZOVRUFJQDVPoU8oQXlVUDVZXUVZKWVBX SVjq6VFlUEh7HkCkbECmbFB/bB2tbKa9bEBsYWBDcUVxRXFFcXVUZ6uZVGermVMjAqQCUFFQdVDr VAlUxFBWUMMQfJpTUXhTKFOYU1N4U1FTUlNUUnlRUERRUVBTVFNSVHlVVkRVVVZUVVFTV1JV7lNL UFZT/lBQU/VQU1NLEE5wUVO1UFBfVk9WUlZKWFFSUlRUX1VPVVJVSVcSAEh7HkCkDWxAbEBsQKYN bB1AvVB/SUqtvb29UUFCR2nXVH5Ie1gtQJTXVH5Ie1gtQJRhYFEhDSJRUWVRUWVRVAmrnFPPrDFU ZFLdrn4GUcJRxguuelBSUJavsVP7VTtQclB+UP8QQVdJV0tHS55YiUtVVXxeQGRT6K+E40BBZHLo r4TjQEJkcuivjhB2REhk71SKVYlPU8xU91P8WfZyVElwDFM2cdtZVHBXTUTxWmlKU1HoUSEQRXMe eVlXDn9Nb00fTVNNSmBBlV4TR+hREON8UPZR6FE/EFt2Hn98H3xSfEl/z+lRZVBIex5ApA0dvaS9 QKSttB5Apg0dvVBvrbZvrbRRQUJpYWBRDQ0Ne3t7e1ANUXNmZlBnZmVkdnNyV1ZFREZFRFZzcnZl ZGZjYkZFRFdWVFZTYkZFRFZzcnZlZGZROHZeDlFCfE8gCAVlTnFgc3Nh+8TK7XxqruwqC3psbHp6 bGtRHS/oUXMJbxMfPXRETUQWR3J+YnkIwP0/CRIGj/quh2t7emtrentrUFJQMa4WV3xV3lASUARR HhAk9lD2EbwRU1dFR0UmRlNRQFB47QCERrhQuhGmFVXVQtNG9kX2Ru9g72HtY1cDQQJNAxUFFwsA NEA0RVd0QntMdBdrXRtdFEEURVc4UDVSN03XUFQpUNpQqxFTERISYxJQHwJhEhFSUFRbVEp6HxFj UlQTS1DsUu5QblKwUBNS7uZQEkASUhJf6FKP5HZQEldM6FLu5ElQS1FLEVxSjlAcUrJQZlBOUo9Q R1KFUFdSj1B+UufiZloC6lLuUFRSi+RhYQUGW+xSj1B6UuhQSlKPEEBfS1FLSgZpdV8Z0BnwGVMZ 6lKKUENSj+ZfclFySQUG7VKIUHFSlFLtUEhRZ9V7ex6kDR29rQ29HkCmDR29pL1BQml/rbVQb6St pL1ArbYNQLVvb71ADaWttUFCR2lRQmlBQkdpQUJpQJnXQF5sYWBRIQ0NDQ0NaGhQDSFRU1ZWRURG Y2JmQmVkUnRzclRSRURCVGNwUENjUlBxcnRSZUBCUGNiVEJFRFJWc3J2ZWRnVlZzcnZlZEJnZmNi RkdnV3JXVldWRURGY2JmZmdmZWR2VdAlEUx7cBmdwvWug+a3riS3m1EghFFXUfkkagqudq6Bvq44 sqhR76ufUR3+86zZHB1CxOIUFz7tzCMLEwlAcZIbHSEAaxd8atDccGgZU+6uIbAodHB8wlEY4vtR csulrmSotq7YkVFKUV+uvq78sVHNqFFYUZlRUfuu5+nnrsn0GBFoC+M6LzrBUTghAxUVPkMfJJXA CG8fCOcMzzQSHlBQUq/MUFBUMFU7UHJQdVHBENFTRVBGVEhTcVhyWnNWdFdcc1F/c29zH3MPcz9z LnPec8pz63O3cKZwW1VxVXNVdGBxY3JgdBVNFXIFcj1NNHI2dCZEJXL4coRFhXGHc4Z0Q3ZyYERg RWFNVHlQfEt/TH9NVHcQSWpkdhBDamRDdXNCRHRzc0VxcnJwWkJbTVpNcXHoUksQGnJxTk1NWVFY TVlMRUtNTHNFRXNxckRxcXJzQnNFQk5RUERRUVB0dUR1c0NDWXJQU01MTFpaWVhTckFyUnJQc3FF RHRUQnZgRVFF6K+Q41tqZEXoUxLncy5yEElLZHLor5DjW2pkcuhTbuVQEElLZFDor5DjW2pkUOhR EhBdURBAamRfUX9RH1FTUehTHuV223NyUHDqUwpTC1BIe3tApA17pHt7pnt7pLZ7DUFCR2lBQmkN UG9sQGxAbG9sQml/vWxAbNdefntYLUCU115+SHtULUCUSFBAvVFAkFBAvVFAkFBAvVi8UUCQUEC9 UUCQV15AbFdVQGxsV2xsYWBRe3sNDQ1QDVAhUSFRU1ZFREdGRmNXcWdjYmdmZ2ZnZ3FXVlZFREZH V3FnZmZnUVNRcVRPN1hfQxEdW626W0cReU1AW1pArizaf0hkbFuuP1saISBTevOuJ1EFVTuryB9J eEVNTHV1TEN8TyP8629nSHB+UnV1Uw3IVB6u4625UFOvgVBQVOlVHFBxUHxQZ1HLECZXVEZUUkJ8 YG91b2AfYAtkOmMrYyBp3GDFWs14z2D0Wv55+2DjVOVa7HXvYEMGfJRUUnJnfX18Q0pETUNRS1BN UXx9fU5KS0RKSktZZXR/fkN6flFnfnJ0Y2V+f3LfclJyckNRUkNYcmd8fUpoeEtKQFlZd31i6FMv 429cUVzqURJQd1Mv5VYQQUJkVuivkONASGRW6FFH5Wl87X2zS+hTFRBeQkoQSUtk4EqQSoBKU0ro r5DlQWVgSlFK6FEj5mhZSkdKaFrqUSNRRVBIe3tAbHt7HkCkDXsNexMMCOlQSq+Q40xBb0ror5Dj dkdvSuiv0ON4SG9K6K+Q5n1Hb0oQQWl7e3t7ewlRHbSttB5Apnt7HbmkIblJQUJpf3tAbHtAkFFB QmlpUEhvb0Jpfw2tvUC9QL1AvUFCaddVfnstQJRIUEC9UUCQUEC9UUCQV0BsbGFgUQ0b4HgDG+Al AQoI4mRJdeivt2hoCVAb4HsDG+BuAQoI5XR4c3hyeGhoaAlRDRMMCBBcYHJFaWJycWl3cnFpe3t7 CVENUWdxYkZGRURWV0ZGRURWVldWc3FnZmdmZ2ZnQ2ZlZHZzckNGY2JmZWR2c3JXUUZjYmZlZHZz cldRf15RtCrvD/nvKyQ48yMC/q5fXR5MeEFIeKNPZx1B7BFNgJss2HRorvI8bcyhxfZwflV3dRzY HCXtfX7ICzXoNkhBdVJdQUx22FNlOHp1e62eUuXYNyNcqwte7PEr2lNQUFFQ2q+xVfFVO1B3UN8Q dHRAE1sTQAxWN1skWiZbJ07WQMZA91DmUORcXfZClkJSVl9RUuhRHRBZWHTCWGN3cFNF6FJD50E0 SFlQRVFF6FNO4lLYUehREuJ32FDor5DkRGlQpF7oUy8QQkwQFxtkTBBEac9MUUw1eDUtSHseQKQN e3sdua17vaS9tA1Qb620b2y9vEC0YWBQDSFRDVFTc3d+U3NyV1ZXVkVERmNiZmdjVlRzcnR2ZWRC dGNiR0ZjYmZnVfE1dFRVdBg+E+PW+zEAtujbiQ1/Pq6k6/avUNa+Uc+DMytmSEh0elU7rhk+bA4V dzIttOyRlbss0f/126zBjlH0oH9ERH9QUq+TUFBV81UcUEpQfVCP6VBMr7gQY0Fpf3sHSyl3Knvb d+VOVl1EXk1dUUVQTVFLTExOREVERERFc35dfH5RUl1YRH54RURAeepTL1BWr5DjdkdvVupRR1B/ r5AQWUNpIH9Rf0uETOpTUVBFUxXkQl9EUUToUSPmfllER0R+WupRI1FFUEh7e0Bse3seQKQhEwwI 6VBEr9DjdkdvROiv0ON4SG9E6K/QEFt9R29EEEhpRBBBaXt7e3t7CVEdtK20HkANe6Z7Hbl7QGx7 QJBQb2+9QL3XXn57VS1AlEhQQL1RQJBQQL1RQJBhYFENe1FncXBUQkVEXlJUc3FnZmdmZ2ZnQ2Zl ZHZzVVFWRURGR0ZjYnRnZkJlZHZzclF8XFHhUUNRWc4LI76uuoCtkl0fS3hDTXSgTGQcUR2uinFF QkpqzVFdBirCsIdlVXd1Lq6hy9Wrx+YHdVJcQU16L1NkMWd3enasWSJLQE5VWREQDVEWgLu1UFBR r4JQUFVfVRxQZ1H5EPYQSeRJUtVJxUn1SVPXTNZ3xkzHffdL933rVOVC5UznfVo3TCZM1lBTVV9E XxlJU2MQS2lUckVpSXJDRW5KS1FfX1BRX0BAUFd8Xl4PWE1XTXROTU1+ZGdn7n9NflYYUlIxVU1W S9RHR6BKTUtUfFF8dXtNfFBAQE50dUR0dHVnfnxSfl5fX0V8Ukd+TVh0aHh1dEBW+VcQc0Jvf1dR V0z5SxBHSGRL6K+Q500XZEvCfsJ96K+QEEZKTGTPfb99Un1KaVL6UX9e+l/5UMlA6lNRUHVTFeRC X3RRdOivkBBbREdkdBBBadB0UXToUSPmaFl0R3RoWupRI1FqUEh7e0Bse3seQKQNe3shEwwI6VB0 r5DjTEFvdOiv0ON2R2906K/Q43hIb3Tor9DmfUdvdBBIaXt7e3t7CVEdtK20pLakth5Apg17HaSs e3u0fw17tHtAbHtAkFBvvW9CaX9svUC9115+e1UtQJRIUEC9UUCQDX69vFBApVF+vbxQQKVRfr28 UEClQL1RQJB+vbxQQKVXVUBsbNctQJRRQJlhYFF7e3sNDQ1QDQ1RU2NiZmdjU3NmZWR2dnNzU1ZF REdGY2NiZmdjU3FnZmdmZ2ZnQ2ZlZHZzc2dxU3NmZWR3dnd2c1LHyy/YKnx123hCc20y0dNDSUEU KJO7DXXQq7hdHkt4Qkt1vkxlHUVcU54EdVdKchFg/VVTrbgDIK5Ebnx7ZEmubxFySkRe2vuu13VS XEJMedNTYjNkdnt1rul+T2V0fkhCUFBRr55QUFUJVRxQf1EY5UVyX0FuYeivkBDTSWpkVV5FXsd2 93btVOVB53ZXUV5eUFFeX19QV3xdXQ9YTVdGTUdNRnc4f38xeE13VhhSUjFVTVZFX0RNRVR1UXVO dE11UF9fTk1ORE1NTn9+dVJ+XV5eRXVSRkVYTWB4Tk1AVvlQVxBXUp9Xj1dSV3fCUHZgdhB2AHYg dlV2SmFQhF/qU1FQTlMVEFxCX01PTX9NU9BNUU3oUSPmYFlNR01gWuhRI+GsSHt7QGx7ex5ApA0h EwwI6VBNr9DjdkdvTeiv0ON4SG9N6K/QEFt9R29NEEhpTRBBaXt7e3t7CVEdtK20HkCmIR20fw0h tHtAbHtAkFBvbG9CaX9svUC9115+e1UtQJRIUEC9UUCQDVBAvVFAkH69vFBApVF+vbxQQKVAvVFA kH69vFBApddVQGwtlFdAbGFgUQ17e1FTY2JmZ2NTc2ZlZHZzc1NWRURGR1dxZ2ZnZmdmZ0NmZWR2 dnNncVNzZmVkdnd2c1LK8OIoJ2923XhfAT/kJnBnO1ytuF0eSnhDS3W/TUpjHFxUTDR2WxlpeNtV VK23GimuQmx3bROuNz10dXhXdXVSXEFNedBTYTNoSnVCda75bngSHUBaUFFQ3q+wVZxVO1BmUJMQ HEMQRGl0XWlEaWEZYQpCNk8kWSRdKXome9Rcxk/mUOVZ6kWKWoZ4QUtxTE1LSkJJTUpgYlJbQkFB TnJxRHJBX3JxS0pKf3VfUk9SUlLoU1IQXFdjY8Jmf1NeNHVZS+hREuJS2FHoURLiZthQ61FHUGhQ W1MvEF95EERpeRAXG2R5NWc1DEh7HkCke3sduUCmvaS9tFBvvW9svK22DUFCaX9s11h+e14tQJRR QUJpaUhQQL1RQJBQQL1RQJBhYFBRDXtRU3NmZWR2c3BTVkFEQmNiZmdDZmVkd3Zzc2dxV1ZWV1ZX U1ZWc3J0UmVkQmZnZmNiR0ZjYmZnVZI1dln9yK6Zlc2SmmIJCjNFSnoOTFtSZFodFklBdjTZ+A2G rqYvxI3S45XBJX9GSXNMVTuuBRt0MseujLeusu6uvEJPUQ0Ye3RDTXd3UXJ5S9Ku+Wt38VFZ0+BR bYtvB2BDR3xQUFGvmlBQVi1VHFARUksQXEJIcl9DbnlyX0NuX+ivjuNfQ25v6K+OEN5fQ25EckRp 5nW3YlLWWuVE5kpTA28mWiZ5UwRfIBNSUXFwcFJQchERc1laUVpBW01aSXBKTUl6YXtNellqUWoR a01qWVJYTVlIQkdNSHlzeE15aWJoTWlBQkJOcFJEcHBSEXNzTmFiRGFhYlFQcnFzf1BRUFBIamlp WlpZUnp5eUlJSFhhcBJ4UnBiYUBCEVxTUVBSUkNQcFHZUHNTUVBiUxVQQlBhr5DnY2ZkYRB1ZWHo r5Dje35kYeivkON4eWRh6K+QEEVzZWEQSUtk0GHgYZBhgGGwYaBhVmHoUSMQWhJZcEdhR3BhElro USPhP0h7e0BsbHt7ex5ApA17e3t7e3sTDAjlYRBGdW9h6K+QEFlMQW9hEE5Cb2Hor9DjdkdvYeiv 0ON4SG9h6K+QEFlfTm9h0F9Jb2Hor9DnfUdvYdBIaWHor5DjW0JvYeivkOZCQ25hEEFpe3t7e3t7 e3t7e3t7CVEdtL2ktL17QGxAbHtAkJBQb2xAbEBsb2xAbEBsQml/Da1sQGzXXn57Xi1AlNdefkh7 Xi1AlEhQQL1RQJBQQL1RQJBQQL1RQJBQQL1RQJBQQL1RQJANUEC9UUCQUEC9UUCQUEC9UUCQDVdA bGzXLUCUlGFgUQ0NDQ1Re3t7e3sTDAjpUF+vjuJAaW/or47iQGlb6K+O4UNpe3t7CVFxQ2ZlZHZ2 c2dxV3ZXVldWV1NWRURGR1dxZ2ZnZmdmZ0NxU1ZFREZHV3FnZmdmZ2ZnQ2ZlZHZ2c2dxV3ZXVldW V1GpUiIzTElkHFpSclwVcmBHcXK/TmU0W62gXh5KeEJKdiqt2ytNZDRYrbxdH0p4Q0p2oE1JZR1c UkdbE3B/Rk50Ur9RHzJmSnVCdXVRX0VxfyasnTZ8dndXdXVSXEJMd9NRz64xNH52d1d1dVJcQkx5 0VNjNGRKdUJ1dVFfRHF8KlBRr5BQUFMYVRxQTlHD5FFyX2lG6K+OEBBfQ25QT19wUgVHyUPjS1PQ cFFSWVNNUllCUUJIQ01CUUlQTVFBWkBNQUhJSU5ZWkRZWVpCQVJSUVhZT3haWUBI7FJDUElTUVBa UkMQQUJfWU9Zf1kvWd9ZVVnQSGlZ6K+Q4ntlWeivkOdjZVkQdndkWeivkBBHeGXQWZBZgFmwWaBZ VVkQQWlZEF9BblnoUSPmT1lZR1lPWupRI1FDUEh7e0Bse3seQKR7ew17e3t7eyETDAgQRVkQQltv WRBEXG9ZEEZdb1kQR15vWeivkBBZTEFvWRBOQm9Z6K+Q43BDb1nor9DjdkdvWeiv0ON4SG9Z6K+Q 419Ob1nor5Did2lZ6K+QEFlFc29Z0F9Jb1nor5DjW0JvWeivkONbQm5Z6K+Q43NCb1nor9AQWX1H b1kQeERvWeivkOFEaXt7e3t7e3t7e3t7e3t7e3t7e3sJUR20rbR7QGx7QJBQb2xvbNdefnteLUCU SFBAvVFAkFBAvVFAkFBAvVFAkA1QQL1RQJBhYFENDSF7e3VXcWdmZ2ZnZmdDZmVkdnZzZ3FXdldW VldTVkVERkZRqVutgl4ES3xFcXO8TkplHVxSXFsQT31/dbtwSWd1dXVSXEFOfylTYjZkSnRDdXVR X0QaL6yeIU9Jc0NQUa/qr7FUMFUcUHdQvelQUK+Q41xAb3for5DjXEBvVOivkBAEQEFuVVBVd0hU SHTNTc1163VXKk/TWMhcU3h0aHQ5T1NxcnJwSFFRUVVSTVFAUFFQcndNUFVWVk5wckRwcHJHS0Hg W1FQUktjW1lweHhycEBVLlZy6FEWEFpWgnBwMHAgcFNw6FMWEFteWUTCSPxeEF9pXuivkBBfTGpk H15RXkl4cEdweFps6VMaUEh7e0Bsex5ApA17ex2ttHtApA1RvbRAtHtAbHtAkFBvvW9sQL1Badde fnteLUCUSFBAvVFAkA1QQL1RQJANV15AbGFgUQ0NDXt7e1FxV1ZWV1NWV1ZWc3J2ZWRmY2JGRURX VkVERmNiblJnZ0NmZWR2d1IaUkZbNwR+/GFiE7PdJCwbZH1pSnF2cH4zBxFyYcVxbDFVHHVRGc+t +/kJKN47HGwAZndwTnZeRXJ8Ci49/VJSIUx2YFZQUa+ZUFBVhFUcUG5RhulQfq+Q40xnb37or5Di W2l+6K+OEHVdX24oUClfJX7VfvN/VQN8BmzcWs5iwWv4UP5a7VrkQ7hfWkJ76K+O419DbhDor5AQ HktzZFZeV01WR05ITUd3fXhNd2huaU1oVVFUTVVGQEVNRnZPdU12Z39mTWdQUVFOXl9EXl5fblBQ c35/RH5QUX5/Xn9uUFFVEH9uUFN2X+hTFBB7flp+dlVfX15+fn99QH1AQE5OT0ROTk9oZ2d3d3ZS R0ZGVlZVWE5veE9AQOhTURBDQk4QdXdkX05PTn9OU7BOoE5STuhRIxBab1lOR05vWjesSHt7QGx7 e0CkDSF7EwwI6VBOr9DjdkdvTuiv0ON4SG9O6K/Q531Hb07QSGlO6K+Q4kRpTuivkOFDaXt7e3t7 ewlRvXtse0CQUG9sQGxAbG9sQGxAbNdefnteLUCU11iUWJRQQUJpe0hAvVBCR2lRQkdp11h+e14t QJTXXn5Ie14tQJRIUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQUEC9 UUCQYWBRe3sTDAjkf3JAaVDor5DjTmxvUeivjuJOaVDor47iTmlA6K+O4UFpe3t7e3sJDVANe3t7 UVFGRmNXcWdmZmVkd3Z3UVNWRURGR1dxZ2ZnZmdmZ0NmZWR2c3NncVd2V1ZWV1NRZmdmZWR2d2dx V1ZWV1ZXUt5RAAomMFut7lkVaVpYYq691XFoPkCtuF0eS3hDSna/S2MaRFxRrVpvT3t4dzlRsjBO QnV2WlHiWRcxY1/kU1OtqdoddXVXZHFOTEQeUf+ubzx1dnhXdXVSXEJMedFTYw5peHp1dVFfRRLU rvRROxh6SkVCclV1dVx3clraUFBRr+5QUFR/VRxQeFFZEGNZQ0h4UkIFRt9223fbePRQ51DmS1d3 eFFYUk1RQkhDTUJBWUBNQUhJSU5YWURYWFlzcHjoUVYQcXB+UUJBUlFYeHdzUFR6WHl4WVhAUPlQ eEB4cHhTeJR6Se1TUVBZUxVQQlBYUSPmeVlYR1h5WuhRI+GUSHt7QGx7ex5ApBMMCOlQWK/Q43ZH b1jor5DjeEhvWOiv0OZ9R29Y0Ehpe3t7ewlRHbS9HkCmIR20e0Bse0CQUUJHaVBvb2xAvb1Badde fnteLUCUSFBAvVFAkFBAvVFAkFBAvVFAkECZYWBRDRMMCOV0EEFEbknor7jiQWlF6K+O419Dbkbo r47iX0Nue3t7ewlRDXFxZ2ZnZmdmZ0NmZWR2c3J3Z3FXclZXVldTVkVER0ZjY2JnZmdmZ2djU/us Q14AS3pET3O/TmccQVpcUnlYDR5KQnm7S0tBbNPfBG5kTBdKdXVSW0JNfihTaTZgdnpRdXV0eUvd rIUMdEhGX3RLZk4nfVBQUa/tUFBXNFUcUGFRnuNJUlFR6K+QEPVEXG8GUQpOUkJyWGVNF0sWTQhM B003UORxh02nTVp3TJZNUjZN1k3mTVN2TVF9ckBBblBgQEFuTnJAQW5hfWBNYVNZVE1TQ0pETUN2 fHdNdkJaQU1CdU90TXVQUVFOTU5ETVFSTU5ZWlpOSktESkpLUlFRc0xLRExMS318fHNPTkRPT05C Q0NMdnV1TU1MWGFQU1JSUFJNTFFTSk9KYnhLSk5PQFroUfTkShBBaUror9DjE/dkSuivkONITWRK 6K/Q405qZEror5DiRGVK6K+QEFteQWRwSi9K8EpTSu1S21BjUFBRHVB8USMQW08QQEFkTxBcXWRP 6K+Q40hNZE/or9DjE/dkT+iv0BBBTmpkTy5iSkdPR0pPYlpsP0h7e0BsbHt7QK17e3t7e720QKQN e3t7e3t7vXtAbEBse0CQkFFBR2lQb2xAbEBsb2xAbEBsQGxAbNdefnteLUCU11R+SHtVLUCU115+ SHteLUCU11h+SHtVLUCUSFBAvVFAkFBAvVFAkFBAvVFAkFBAvVFAkFBAvVFAkFBAvVFAkGFgUXt7 ew0NDQ0TDAgQX0xIRFxvTXJEXG9QckRcb3t7ewlQDXtRDVFDUXFFVldWVldTVkVER0ZjY1dxZ2Ni Z2ZmZ0NRc1NTVkVERkdXcWdjYmdmZ1F2dndnUtktU0NRGzxDcWdwq0ZLdgJIWa2VWksceE9hfLCs uXgvok9mOFuuEVtLM3xwc1F3cWwBWlUcq+xUFHVXV10eP6z0G3t3RE11dUZACclTQqvhVB+s6Tt1 dXdXdXVidChTo3JIV3VQUFGvl6+xVkhVHFB5UQMQJVdDR0J4RGZCanYWUBVCF0U4UilS9EhbBEMm SORIU9NRUVtCXE1bTXROTU15dXhNeVpSWU1aTEZLTUxQUVFOREVERFFSREVSUVFzQ0JEQ1FQQ0J1 dHRzRkVERkZFeVtbWlpQUk1MWERDWUZDenhCQ0VGQFF/Q+hTbhBERBBnTG9EEGJJbxBEIETQRPBE VEToU33jWVDJdOhRIxBbRhBnTG9GEGJJb0bor5DiQ2lG6K+Q43l9ZEbor5DjTXRkRuivkBBJSmVv Rh9GL0bfRv9GVUYuellDR0ZHQ0Z6WuhRI+GUSHt7QGxse3t7QKQNe3t7e3t7Ub20e6YNe3tRrrR7 QGxAbHtAkJBQb2xvbG9sQGxAbNdefnteLUCU11h+SHteLUCU11h+SHtVLUCUSFBAvVFAkFBAvVFA kFBAvVFAkFBAvVFAkFBAvVFAkGFgUA1RDQ1RUUNmZWR2c3J3Z3FXdldWV1ZXUXNRU1ZFREZHV3Fn ZmdmZ2ZnUXZ2d2dSG1Hzs0xkF1xdW1HkXBRxf0dwca6RdK5toUthDFquBl4AS3lETXRRXXcJDltV HKuJU0oyZnV6UXV1UV9FcX8lq/JUKKzjMGN2d1d1dVJcQk18LlP/bH1TdVBSUCqvsVXuVTtQQFBy UP7lcHJOQm9H6K+OEBhOQm9kSWpManIUSRhMG3IEUgdeA0QFRQpNDk41RTpMOk8mQypMLE/VRN5N x1bEQ8xMyk3kRe9N7U5LV15YQ1JBY1BTSmNYWUfoUy8QQVwQRGlcEAxlXBAXNGRcNXNw6FMvEEhU EHERb1QQRXNvVBAMZVQQFzRkVBBJZVToUUfmIHRRdDUMSHtADaZ7e3t7e7lApnt7e7lQb71vvWFg USENe3tRYkZGRURSVHNydnZlZEJmdEdyVlZXVkVERmNiZmdmQmVkdlOh14Amra44is2DNeeuUXDQ NO/sGwzCxwv/DyfywlU7JbUriq5xrNu0O+5RI6nWEDOx5rCX3osKPdlR+ejYgVBSr59QUFSoVRxQ TFB4UWQQSVZSRlIXcdh1xHHLdfVX9nDmV+VxWlZaUXror5AQD0lqZFhIeXFrcRZVB3grdfNS+3Hm Xepx7nVbRnJAaUFyX0BuTXhaWk14eFtCRkNNQlBHTE1QQVtATUF4W1tORkdERkZHWlhNT3Z+UFhj T09BUFJCQVhaTXNGeXhHRkBz6lMvUFRRR+N6eIRb6lNRUEdSQ+RC0EZRRuhRI+Z5WUZHRnla6FEj 4dFIe3tAbHt7HkCkDRMMCOlQRq/Q43ZHb0bor5DjeEhvRuiv0Od9R29GEEhpRuivkOVCaUYQQWl7 e3t7e3sJUR20rbQeQKYduXtAbHtAkFFCaWlQb2xvQml/vUC9QWlCaddefntVLUCUSFBAvVFAkFBA vVFAkFBAvVFAkFdeQGxsV15sYWBRe3sNe1AhDVFxYkZFRFZUc3J3U1ZFREZHV3FnYmZnQ2ZlZHZ3 Q0ZjYmZmZWR2c3JXURBSRoKA1K6sxw7BPHZmNlqttVs6A2CweGkxliEVPeM1LC4UMVUc5dI3kily rt7UenB6VnV1GfVTVNt/c35Vrf1NCuQxNSZBUFBSUDGuAFXtVTtQdVBnUXQQHmRGE1UTZylA20DK QPlA7UBYeVFlUGVRaWFqZxV+GWEfZwVMA3AEeQV6AX4MYgtjNHowfjpkJngsZNV53mLEeMth5nrq YuxjS2VyTkJvfOivjhBZTkJvKUBRWltF61FIUEJQUVMU4lOzQuhTTuNeW39a6FPCEFlX515fdmNO U0foUxQQRH9+UFlRUEZHTUdzUFFEUEdIUFFH6FHM51BQZXxb+XJG6lFIUHxTLxBdShAMZUoQFzRk SjVoZehTLxBIchBxEW9yEEVzb3IQDGVyEBc0ZHIQE2Vy6FFH5iBpUWk1DEh7QA2me3t7e3u5QKZ7 e7m0QLRBQml/vddYfnt7LUCUUUFpUEhvvbVvvW+tpLRApK21QLRRQJlhYFANUXt7DVANVVVmY2JG VGNiZmdHVlRzcnd2c3JWV3dRdlJlZFBQY2JGRkVEUFRDclZWV1ZFREZjYmZnZkJlZHZSB66ubWRi BVFHOD/LGXE3rrjNB8e3DHN8fEdRyu6UUVlRzZfEgSKuqq4rzDTv7BsLwscK4A4o8sJPgVtcbx0K QMTTcmNaQ0tRFEpRSvCLUYRRUSi1KLaueKNVFjOx5rCX3osKPNpR+ufXglBQUq+BUFBU8lUcUHZQ YVHaEC1YRll3bHoYUBx6GnsKUDpQK1AnTyl9xlbKffp66Ufveu9+QfZW5FdSVkxGTNl9U1N3YWFU XENdTVxbVFpNW0pESU1KdnJ1TXZhVFROQ0REQ0NEcXJyTlBRRFBQUXFReX9+Snl+UVFQSlJ2XFxb W1BYcnFRUFR8Q2J4RENAfOpTL1BOr5DjeH1kTuivkONMTmRO6K+Q40NIZE7oUUfmIGNRY2GEVOpT UVBEUkPlQxBCW29D6K/Q43ZHb0Por9AQWXhIb0MQX0luQ+ivkONbQm5D6K/Q531Hb0MRSGlD6K+Q 5kJpQxBBaUPor5DjeH1kQ+ivkONMTmRD6K+Q5kNIZNBDUUPoUSPmYllDR0NiWuhRI+GUSHt7QGx7 ex5ApA17e3t7e3t7e3t7e3tRHbSttB5ADaZ7e3sduXtAbHtAkFFCR2lQb2xAbEBsb0Jpf71AvUFC addefnteLUCU115+SHtVLUCUSFBAvVFAkFBAvVFAkFBAvVFAkFBAvVFAkNdAbC2UYWBQDVENDXFT VndTVkVER0ZHV3FnZmdmZ2ZnQ2ZlZHZXZ3FiRkVEVldDRkZHV1FGY2JmZWR2c3JXUwOJHAAlR01G Mlmto1saSnlDcHO9SBsWXFHqjpSZ/9RgMDtbrQgQYvyYLS1wfFLDUUCuNgBnekhCWHV1U1xBTX8n U2MCfX4QUXX42dOJTa4jwghWdVKLWe/ePyZYUFBRUF6vsVQGVTtQa1EFENXVfNF/Ug5dDl4OXzpd P14/Xz9ALV0vXi9fK0DQfdB+zF3NXsxfQHhQel1kfQR9N3E0fSxYK14iftlY1nrWfctcyl7KQMVj +FD9XP9e/1/8QPV++X/pUe5c7F7vQON+5n+kfk5GfgFbAFwDXQt9BH9WVkRHRBpcGF4aQNR+Vl99 XX5UV3hN6FNOEFp4NEVzv3FxRVNS61F+UFBQaVNOEEFXY2RkUFlAe0Ja/HBgYGBSYOhTTuVz2HJw 2HLoURLlT3GwcVJx6K+Q4kNpceivkONJS2Rx6K+QEEtyd2R/cW9x0HFTcUpte/xCEH5lQpxS2FFr 2FHoURLlz1CwUFJQ6K+Q53J3ZFAQR2VQ6lFmUGxRZuEtSHseQKR7ew0dtL1AvaR7vR5Apg17e3sN HbS9QL2kDb1BQmlQb2xAvbxAvW9sQL1AvbxBQkdpYWBQDSJRDVAhUSFHQ2NWRURGY2JmZWR3dnd2 d3ZlZGZjYkdGR0ZHRmNiZmdjU3NmZWR2c3JWRURGUEZFRFZWc3J2d3ZzcldeIHJX/93T2E9/nDNM foT2aGJPAmpWXkFNekx2OHJU8NM40gNRewg9nClsOCJ3SmtxT1GnGWDZ/PE5FGgDgTRhAQnemltW ckdSU05hrm5sdSnKKgAWL66x8Qs3kTpGe18AUFFQ31BQVWJVHFBxUXsQc1MQQltvXXJAaeVdUUNK RE1DQltBTUJVU9hScNhxUkBRVlFR61NYUFpQca+QEFtBaXFAUGBQIFBSUOhTWBBAS0BaW1tOSktE SkpLWUxaS+hRzBBEUFJx7VFQUlpDQlhKcnhLQFuCQkror5DjY2RkSuivkON7fmRK6K+Q43N5ZEro r5DjTnBkSuivkBBbSEpkL0rPSv9KU0roUk7ncllKR0pyWjfpUxpQSHt7QGx7e0CmDXt7e3t7EwwI 5UoQRFxvSuivkOJHaUror5Djc0JvSuivkOdCQ25KEGJJb3t7e3t7CVG9e2x7QJBQb2x7b2ysbECt bGxs115+e1UtQJR7KkCgDVFIf3uUeypAsFFIf2h7lFFAvUCtaVBAvVFAkFBAvVFAkGFgUQ17e1Fx U3NmZWR3dnNzUVZFREZjY1dxZ2NiZ2ZmZ1FzclZWV3NRfFRWP3ZDfXLdO66kYxABflyt4ltKHnpN f3pRSQEl3whMdVUcrsgfbhl1TKwK4Hl2YXV1SUEJwFOTbCI5UFFQiq+xVtNVHFBiUWLpUE+vjuNf Q25V6K+OED1fQ27Fc+Rc5V3rRlQDVQJPI13Vc1RYflh/aUJrd1RZTHt3UlFWUk1RS3BMTUtQfWJN UEpESU1KVllZTnp9RHp6fXBycnNCRERCQkRLSkpRUVBSXjR1WV9AQXRzVUJ6QmN4fXpEQHLYQhB4 SG9C6K+Q40NJbkLor5AQXUFpYEIQQgBCU0BCUULsUx5QWVNRUHqvkOJJZXror5DjTnhkeuivkON7 fWR66K+QEEJhamRwelF6KGNZekdCR3pCY1roU2/hP0h7e0BsbHt7e0CmDXt7e3tRvaQNDXt7e717 bEBse0CQkFFBR2lQb71vbEBsQGzXXn57Xi1AlNdefkh7Xi1AlEhQQL1RQJBQQL1RQJBQQL1RQJBQ QL1RQJBhYFENDQ0Ne3tRcVdeUldTVldWRURGY2JuUmdDZmVkdndncVdyVlZXU15Sc3J2ZWRnZmdD ZmVkdndRXFJtWwgbZU3bdVdc5MczzD8Mcyh9bQ1bUf9bHBNiT8MXLr/hnKpbWE/WTGkjVRx1Uk0a NK5w0HgQZyn3G9e3JlHOy39xf1V1dU0bPK5ZpbnNt8VrE3w8UZ00f3V5VlBQUVFQr7FVmVUcUHFR GRAQUFlQWlpBWERYS1ZxVkVBEEBSQmhBbUVrSWlwaXEYQBxBLUEsQ95B30XNRMxF7UVeNU80cFLM Qf5B7EFTcHNRc+ivkONwcmRz6K+Q4k1lc+ivkONKS2Rz6K+Q435qZHPor5AQfHplWV9aTVlKcEtN SlhRV01YSUFITUlfQEBOUFFEUEBBUFFBQEBzcXBEcXFw6K8mEEJAUHFwSklJWVlYUnFQWX9BUUHo UtriQC5x6lNuUFFREuVQEHhIb1Dor5AQQElqZF9QSVBgUNBQVFBJclnoUwHhkkh7ex5ApA17e1Ed tKaktA1Qb2xvbEBsQGx711R+e14tQJTXWH5Ie14tQJRIUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQ YWBRe3t7e3sNDQ0NEwwI6VBPr47iSWlw6K+O4klpTuivkOFEaXt7ewlQDVENVUNmZWR2c3NncVdW VldWV1NRZmdmZWR2d2dxV1ZXVlZXUVFnIFgTGHRaUkdbBxFDWlsAUkEGRl9+b1xRyFphTWc9Jq1U T1Q5Bk59bHV1UXJ5Rjesh1KCJX5PR0t4VHV1VF9KOvGrolBRUKmvsVfdVRxQYVGwEEFWfFFdVFtf XUFeQ19EVn5WXeivkONCW29O6K+Q41tfZF3or5AQQVtfZFFdUWByXF9kXhBcX2RZ6K+Q4ltlWOiv kBC9W2VDEFtfZEQQW19kWE5ZT1lwX3VafVV+VWF/dVhFfkVhH3Efch93H3sffQ5PDn0pXity2kPa RM5DzkTEe+J7QW99H08fcFNvd297b3xTb3JvdW92U29Pb3BvcVN+fX5gUkdMf15+T1NfRE9EUkRe Q01EQFhRWFxZTVhARVFFS0ZNRXd9eE13V1FWTVdfdn92UnZPdU12T05Oc359RH5+fUtOTk5/YER/ Tk9/YF5dXXNhYERhYWBcXV1OUFFEUF1eUFFRXF1gXktMTU5PfVtQd3Z2RUVERFhYV1Jhf35QWWBe TktPfVZ/UVxdU1Bj6FMG4n7Yf+hS2OJh2FDor5AQW0l5ZF9QT1BSUEli6lEoUxpQSHseQKQNex29 pL20QUdjQUdjUG9sbGxvbEBsQGxAbEBsQkdp11h+ey1AVZTXVH5Iey1AVZTXWH5Iey1AVZTXVH5I ey1AVZRIUEC9UUCQDVBAvVFAkFBAvVFAkFBAvVFAkA1QQL1RQJANUEC9UUCQDWFgUQ0NDQ0NDQ0N e3t7e3t7UCF7e3tRIVANVUNmZWR2d2dxV3ZWV1NRZmVkdndncVdWV1ZWV1ZSU1FmZmVkdndncVdW VldWV1FzQ1FRRSVXEgZbUaxbNhteG1JTURI9WFJ1Ww9xSHFaU3t7Uf0WdGBqWFHCWmUCaHA0rQd1 Pq0HT1Q6EXNqbFJ1dVEbwq10U0tEXmhsV3V1UV9bYWtBrgKu3lLcOwZOTHtWdXVUfG50yqu2VEqr tlBQUa8nUFBVvVUcUG9RDRBK2VTLVPtUU0hGBkA9cfdj5WNVWFhYRmdIU2Xor44QFl9pERBJYGQQ EElgZFZWV0dHRkhIVUdHSHh4d3l5RlZWVVdmZmdlZVl4eHlmZmVnZ3dRVVJNUV9GQE1ffmV/TX5f UE9QUlDoUUsQM2lvTVBeWV1NXnFIcE1xUH1RfXl8TX1pZnh1R1ZWERBpZnhHVlVQcmVZWU5GeURG RnlVZ3d3c0hVREhIVWdleUlIRllVWBEQZ2V5SEZZVVdQcnX5c39yfn1RUFJz2HJycV9eWOpRulJJ UEh7UG9sbGxAvW9sbGxRf6S0UEFCR2lRQUJHaddefnvXXi2U115+SHstQJRQQUJHaVFBQkdpSFBA vVFAkA1QQL1RQJBQQL1RQJBQQL1RQKUNUEC9UUCQUEC9UUCQUEC9UUCQV0BYbFhs10BYLZRelFhs 10BYlFhs10BYbFiUYWBRe3t7DQ1QDVFRcVdWVldRQ0ZHTlJHV3FnZmdmZWR3U1FWV1ZFREdGR1dx Z2ZnZmdRU3Z2d2dxV3JWVkVER0NnZmdmZWR3dndUclGbWzHBLa7wM152SGAZGlutvFsCdEtKD66S DUJbTl4XWq5tWwVmH9tR2jxhGQtaUbVcE39JSAyFLn9BQ0saVRx1XgnVrsiuxWQ9FmpPU3V1U0xE cEwPUQWu7w9OQkFOQ1hZdXVYT3/cUdxR1+QDVnV1QXNGSAiu4oQuHUtFR11CU1BQUVDoUFBVBlUc UGBRIOlQfq+OEJVDaV1RX1JcU1xXXFhfXF9dX15dX9xR3FPcV9xY3F3cX1/PUc9Sz1PPVs9Xz1jN Ws9bz1zPXc9ez1/DQ11iEElqZFhy+nD2fetS40TlflbLU/tT8FlT2VHaU8Z+UxhROVE9UlNYX1lN WEpxS01KeGB5TXhXUVZNV0lBSE1Jd3N2TXdxQUBQVHJKeEBBQU5xckRxcXJfUVBQc0BfREBAX1Bg YFBQTnJzRHJyc1BRYHNfUVRiYWBzUVNXcnJJeHdYV1JKSVhQYuhSweZAWUGCcllx6K+Q40lqZHHo UtYQWXFheHJAcXFhWupRI1F2UEh7e0BsUX97bHtAkFGme3uUUa17lFG2SX9IUG9sb2xsbElCaX9C R2lRQUJHaVjXfkh7Xi1AlFjXfkh7114tlNdefkh7LUCUe0FCR2lIUEC9UUCQUEC9UUCQUEC9UUCQ UEC9UUCQUEC9UUCQUEC9UUCQYWBRDQ0NDXtRIiF7UVFmZWR2d2dxV1ZXVldWV1FTVkVERkdGR1dx Z2ZnZmdmZ0NTdnZ3Z3FXVldWVkVER1KcUVI0ezVaUfpYbkd0c38JruQ0dUdNdh5arZVcBUx9RnJ0 J8F3EQFaUaVcDl1GTE1SgVE53XdGTVZ1dVhZX3B6K65mruEuYE9wWlxRdXVSXEJOfidR3FGELGxX dXVXVVd6THkzUFGvrFBQVLNVHFBDUUcQc0JoXRldKF3PVs9XxVr1WuVal1CXQYdQh0FcUnJ2R29Z OFVV6FF8EGlYTVlDfF9fMUJNQ1RTXVJTU05cXURcXF1cU1tSXV9zUVBSVXNbU1R+WltYX0BCQF1Q UFpSU11FREPqURZQXFFm5ERZWS5S6K+Q4nNpUuivkOJKZVLor5DjSWpkUuivkOVcQWRSrEXoUWbh rEh7HkCme3t7ex20ex5ApFEdtEFCaWlCaWlBQmlBaWlQb2ytbEC9b2ytbGlBQmnXVX571y2UUl5A bEhRfr28UEClUX69vFBApWFgUXsNEwwIEEZcck5pXXJyaVxycmlTckhpXHJISW5S6K+O5kdpXE5H aVPor7LhRWl7e3t7e3t7ewlRcUVRY2JmZmdjU3FlUXFyVlZXc1FmU/2sQc2ugdt/diWsYVO/rrfo xjt1c1UcdatKYiwirs9NVLZxNTZQUFFQXa44U5VVO1BXUMrtUq1QWFBQUvlQWVL4EHhYe1J+VlJT VldXUlRVVdNQUURQUFFTVGd4UlFAVlVneFdQQllHR0pS6FJ841FRQFfqUnxQUK+QEF58ZVBJUFh4 UUBQUFhazOlRIlBIe3tAbFF/e2x7QJBRHqR7Hb57bFFArh4VNRS2UG9sex2tUGxvbHutUGxV1357 LUCUV0BsbGFgUQ1RFhQWFBkUQ1FxV3FRcVddUl5R+kauua5MUUZErjhXUxWp2hhQUFFQiq+xUYpV 3lBTUH8QRFhTUVNQUVJRW1INUUpVUA1TSVTq6VFlUEh7HkCkHb0eQKYdvVBvbG9sYWBRDVFDc1NR ceka5lXeqgNV/VBRr2OuOFK7VTtQV1CXEHF2UXVUUlRVVdNQUURQUFFTVGdRUXhSQlZVZ1BQeFdA WVnor5DiEWVZ6K/Q42MTZFnor5Djf2JkWeivkBBbfGUgWdBZUlBZUVnoUnzjUVlQUOtSfFBZUFdR WOJSUVHrUnxQWVBSr5AQQmVmZF9SUVJJUFh4UUBQR1BYWuhRuOELSHt7QGx7e2x7QJBRHqQNe3sq HbJRSH9ApHsqslFIf3sqQLINDXt7e3tRSH9Qb3tsQK1QbG97bECtUGzXVX57LUCUYWBRDVFRcWdx UXFnUrutoq4GRVFIUbOuu0RVO6itFVYmGFBQUVBoUs9T/lU7UFZQbBBbU1ZSVVZTtVBVUFTrU11Q VVBSU10QXFGGUNlWhlVJVz2rSHseQKQdpK6kvUC9UH9/QL1sQGxRQmlhYFFRc1FRc1FSVVH5DK7y rvIOUf9VO61kUhqt5lKcUFBRr7+uFlRCrspQU1BKEFxSeVBQSlVRSVRvZUh7HkC0QKZQfx29YWBR cWVxVEKrjVRzrhYEUFBRUThUclLiVSpQU1AB5ihSUVFSUFLoUS3iU1BV6K+Q52dlVZpQUvZR7FE/ UFBSRVBTr5DiEGVT6K+Q5RITZFNJVOhR7OErSHseQKR7ex2tpL1AtntQb71sQGxhYFENUUNzUVIV PXCuhlUqrvhRCFBQUlBgr7hTkVPZUHZQZVGJEEhZcFhxZVHUUdR6xVHIS8N6yH78Y+Z7W2Dor44Q R1xEb/RG9GFSZnoacFJcckllXF5yeGRe6K+OEGlyeGRvRx9HD0dTbWBRXBByeGRcEEll6UaJdrh2 U1FSVFRQRkZHdXZ2RVxdRnd/YnZ1RlRhRXxjTXboU8UQQ1B3dHJyUFd4UFRUT0V2REVFdn/or4zj TkJvf+hTfhBdSkpAW0VmeHZFQF3aXO1RE1BUUlNQRVBQUlPndv1FEE5Cb0Xor5AQXnN1ZFBFQEVg RVPARVFF6K/Q4gNlRe1SxVB8U9FQQlBNr5DjfmRkTeivkBBHdndkTdADZc9Nv01STWJmRUdFZlpi k0h7e0Bsex5ApA17e3sTDAjpUE2vkOMAeG9N6K+Q42JJb03or5DjSHhvTeivkONFc29N6K+Q419J b03or5DjTkJvTeivkONDSW9N6K+Q4Udpe3t7e3t7e3sJHbmkew0he3ukvUCtpr17QGx7QJBQb2xA vXvXXn57Xi1AlHtIb1BsQL1AtFFBaUFCaUFpaUFpUEFCaVFAmddeLUCUWGzXXkCUlGFgUQ1Qe3sN IlF7e3sNUBvgegMb4GoBCgjvUGWvhFBkr4RQeK+4UHevuGhoaGgJUA17UQ1RU1dWRURHRmNiZ2Zn R1ZWc3J2ZWRnZ1ZXVnNydmVkQmdmY2JGR2dXcldWUkVERmNiZ2ZlZHZTkZNGU1pYXF1FdxFyFcJu e3tGRdM+HxwZOu/DIzZtAUV0lRAYNs8UfD3Q+xJT2a0KC11ZQFxZQE0LSDg9e3lhABv7FGEpOs9R MToEEBoiTGwFruLXFB/xhrEFHFBQUlBmr7hTkVXeUEdQdFFVEEALS1FYWlFXWQFQB1XrTFR26K+Q 40xOZHbor5AQEElKZEFVUVFzdEhIUEcVXrp4RmBHHUhdUXFKUV5QUHhQSFBHSE9dXkRdXV5xdE5p cXdUV120SnRbW111eF5dQE7oU9EQX1fQA2XfV59XUk9XUVcySOxSU1BHUXRQXa+Q43pgZF3or5Di eGVd6K+Q4nZlXeivkONMTmRd6K+QEFtJSmSQXYBdoF1TXehRa+V1XUdddVroUk/hk0h7e0Bse0Cm DXt7e3t7tL2tDQ17uXtAbHtAkFBvvb1vvXvXXn57WC1AlHtIb1FCaVBBQmlCaaW9e6xRpddeQGxs LZRhYFEhe3sNUA0iUVNmZmNiRkVEUlRzcndRZmVkd3ZzcldlU0ZjYmZCZWR2c3JWV1IflTDfHj7c 6K6618fPUWBzQEd9RXt5NBwI7dsLbg3idlXerR00GsIt8a6R4iFURylFSl1CV3aqqGfRUWLMDDjF 1VBRUGyvuFM8U9lQeFFdEBZQEEdeb3gQR15vflB8UXt3fnhuUG5RalVud2543FLbcdl3+1L0dOVP 43RAT1BKUkpUSVVKd094VtV2USp32nf2cVNGVVF66K+Q4kFleuivkOJGZXror5AQXnNlz3j/eFJ4 UFB4XUlB6FFU5E10Wld16K+O40tAb3Xor4wQck5pdXdTW1CZRCBJd13QA2V/XW9dH10PXVRfXU9d Ul1KenLoU9EQTlbQA2VvVh9WD1Y/VlTQVvBW4FaQVoBWVVZJeXsGSHseQKQNIXsduR5Arg0hex29 vbRQb717e2+9vVFBQmlpQJkNYWBRe3t7IQ1QG+BxAxvgfgEKCOtQT6+4UE6vuGhoCVAhUSENe3t1 VlZzcnZlZEJ0Y2JGRURXVnNydmVkblJlZHd2c3JWV1ZFREZjYmZnU0s4hCbez/tRcds9PHZMeU95 X39aQ01lMpAUAiQ0HccOii0l8NfJUXjpCxJufHJ4TkNwfURbRV5E2i/KyjYnHTVQUlB3r7hUBFXe UH9Qa1GSEM5XTlFEcklfb1sQSWVaEEllWxBmbGRaEGZsZFtIZGVkWxBiY2RaEGJlZEtaSls5Wjlb j1qOW1ZvRR9FD0UFY1RbEEllWhBJZVsQcmpkZmUZThlrBX7XZcZRy0TKRfZQ5lHoWuVN5GTjZV4E UFF2UVGjZVFcSHJqZFoQcmpkWxByamRtEHVlbRBzdGRtEExlRERFc3R2dkM8WlFaW3+uduhRoxB2 eH5gfx1zRGNpYHZLamZzRFNDUFB4UFNQf1NPQ3ZEQ0N2Y3RwV2nor4riTmlp6FN+EFtISF5bQ2x4 dkNAUOhTU+N2/0Nb6K+QEFpmZVsQYs5kW9pa6K+Q52ZlWhATzmRa6FETEFpTtH/FUENAQ1JD6K/Q 4gNlQ+pSxVBmU9EQXkvQA2VLEHVlSxBNdGRL6K+Q4nhlS+ivkBBBfmRkv0tRS0lsQ0dDbFpi90h7 e0Bse0CmDXt7e3t7uaR7IbStpnt7vXt7QKS9e0Bse0CQUG9sQL17b73XXn57WC1AlHtIb1FBQmlp QmlBQmlQQUJpaaW9e6xRpUCZDddeQGxsWC2UYWBRe3t7e3t7IQ0NDVB7e3siUSJ7e3t7e3t7e1AN UVFWRURGY2JnZmdHVlZzcnZlZGdnVldWc3J2ZWRCZ2ZjYkZHQ2ZnZmVkd3ZzcldlU2R2c3JQRURG Y2JQVASu+ExBWV1CcgByGMMQcnxOd8EnAhscIe7MKzdmHnYyW1dcX0VxR2VLGmkurr8SfjhRalXe qzQwTlpCXUgwRTQsYHxpMCywBmvXJMVRAjoFfGNRDHVGeEpFXkFXda0jEB6uMO4bH1GSUFBSUBCv uFMhU9lQSlB1UK4QZl9AW3VIQEh1VFBYQFhSQgNYAVlSeFl6dWhZa04YVxlYGVkYWgtYB0AFdcNU 8lT1Q+JU5nVAd+ivkBBtdmVZckxBb1hyQltvWFlYWVVLUFhZRXBQ2ksQWFpuXUtNS39LU0tLW3N0 QldVd1tbcGpfRU9FUkVKd1AZUuhT0RBHXtADZV7QeABvXhBMQW/PXlFeSXZ7k0h7HkCkDXt7ex2p tB5Apg0dvVBvvW+9Qml/DXu9UUFCaWlCaVBBaWlAmWFgUXt7ew1QDRMMCOlQWa+O40Jbb1nor47j QVpvWOivjuNBWm9X6K+O41lcbljor47iWVxue3t7e3sJUA1RDUNWRURGY2JmZ0dWc3J2ZWRCdGNi RkVEV1ZXVndmZ2ZmZWR2c3JWpFcuChjV00W9h8LE6FFGwzo2Egf5IJTEDSsrZWE2tVEpYnEJLWs1 TbvoP8VRaP0GawMcM215SkF5Z8kVemSJUFBRrs+uFlOZVd5QE1F36VBTr47jCn1vU+ivkBBDBXtv VhBHEUcSaVBUQhUQeHlkc+ivkBBKSXNkUBBJc2QVEGJlFRBGZRUQSGUVEF5AZBXor5AQfV1lcXJ3 d09TUhMSVHN0VE9SE3cSVFRPT3dET093QMVLY8VtdH1QUXMQBXtvc+hROxBDdHRQVkt0WV9PFHh3 T0BmamlhYOhSruJHYV3oUlMQQGBDEENSQ/0UT0dPFFpii0h7e0Bse0CkDa29rb29e0Bse0CQUG+9 b2xArXtsb620QLTXXn57Xi1AlFFBaWlBQmlp15SUXpTXVUCUXmxhYFF7e3t7e3t7exMMCOlQVK+O 4wV7b1Lor44QSwV7b1RybE5vUhBsRG9ycn0Kb3FyfQpvFRBDaXt7e3t7e3sJUQ17e1FXc1NSV1ZX VnNyd3ZlZGZjYkZFRFdWRURHRmNiZmZnZmdDc2diZmZnZmdmZmNiRkVEVnNydmVkZmVkd3ZzcldW V1ZXUjNCwj4ZGjkpDAxsek9jdUt1RUBXWUN7DxpxXm3+/l4DEmd8a2Ya8xgcDH50T3dKWV1Jb2IT ZUsYUyESrhuuj86PBRF0SXhwf3JGRkNeV1lVV2Y7NXq7UvUSRxEJKBIJCR19c2B0SUB/WF5XWnhl IWu6UFBTr5muFlR7U9lQf1BtUBxRWhBpwhPxQvpD+0bzE/0X4ELvTutP4xNaQjpAOhspQCkbyhv8 G1ZBX19PbhpEbm4aX0FuGlRucUh2adpY6FNj4nxQUuhTwxBPf5ZjdHxXFXRIX0JBRBhSf1RYdmBm bnFcc1HFVBhhRO1TYlBMUGBT0VBUU2EQWXlcanM8eRFqTOxRdFBmU9FQea+Q4npleeivkBBfdnhk QHlRgHlReekdmxxIe0CmDSF7e7mkvUCkvUCtuUCtvUC0QUJpaUFCaWlBaWlBQmlpUG+9b72kvWxA rb1pQmlpR2nXXn57Xi1AlGFgUA0TDAjlG3JdRm9f6K+O411Gb1/or47jX0BuQOivjuJfQG57e3t7 CVENUVdzRkVEV1ZXVldWRURGR0dGR0ZFRFZWc3J2dmVkZmdmZ3ZlZGZndnZlZGZjYkZHV2R2c3JW RURGY2JuUlFWVkVER0ZjYmZlZHZ3dlR7TfdDICGVOmVEdBmS8WRjKbndLJwIaXtLLn4B0z7RqZ8b MH0dCRghww4TZTMUeK5xAQNsBvbfmxs8a1MbOGZ/1Dc3W3B8QEFEcUF9dmRlFQLYHWs0ZXsNTkMX dHt4CmZF3gfesE5wzQAMsysdMmo2zq0ldSRoEntuMR13FkZcUFFQea+4U/xV3lBmUR8QPUIEVwZ5 83lTOVY5WTtOPHcpWSlOK3Yrd1gDUDt2UgNlUURySWVDckllUVFSent8fFBDRGYVfgp4ZWBmHVFz fVF+UFBXXFxPS3BES0twUHxQZnxPfX5EfX1+c2FUV318WkhbS2d4cEt+fUBE2kPoURPjXFd1cOhR dOJcdUvqUsVQfFJT4maDfeivkONJSmR96K+Q4kdpfeivkOJMZX3or5Djc3RkfeivkON6ZGR96K+Q EEJqZb99UX1JZ0tHfUdLZ1pi1kh7e0Bse3seQKQNe3t7e3t7HbS9pL2kvUCmvXtAbEBse0CQUG9v bG+911V+e1gtQJTXXn5Iey1AlFBIb1FCaVBBQmmlvXusUaVAmddAXi2UlFhsYWBRe3sNDQ0b4GID G+BmAQoI4XByaAlRDRMMCBBZUUhcaX5IXGla6K+O5kNEbkRyQ2l7e3t7CVFRQmZjYkZFRFdTVkVE RmNiZ2ZnR15Sc3J2ZWRnQ2ZlZHZzcldWV1ZXVldXc1FnZHZzcldXZVIJrrfmnA1gEEwqR0FbXUFp aE9yKQdydX9zI0ZJRE11FAlI2HpLEMZRGXN7T0J1RVXerGVRQuQSZxIOrg0cWF5CXXweQ2UvYX91 fChRwBt7REhGeiJPixYDnVQoLEp4VlN3UFBSUAivuFJ+VUZQW1B5UXQQd0c+amVGJmplQnsQQmV7 EElLZAlcUUlzUUZHeRVxCnh4YHkdXFAgVuhTzBBKXFd4XF9ceV9PTnFETk5xS1tOenhxTkBH2kbo URPkX1kgU1zoURfiUzBf6FFz53k8Qk4QS2VO6K+Q42prZE7or5DjemRkTuivkBBZc3RkThBPcGRO 6K+QEENDRmRgTt9OUk5Jek5HTnpaJ9ZIe3tAbHseQKQNe3t7e3t7EwwIEFtOEExBb04QXUFvTuiv kONGXW9O6K+Q4Udpe3t7ewkdtK20tkC9QKa9e0Bse0CQUG/XXn57WC1AlHtIb1CmvUClvXusUaVA mWFgUSENe3sTDAjlRxBcRG9d6K+O5kNpR3JDaV3or47lX2lHEF9pe3t7e3sJUXt7UWJGRURWc3J2 ZWRmQ1NWRURGY2JnZmdHVldWc3J2ZWRnQ2ZlZHZzcldlUZp6amt5eWtqZ5ZEQ11fRWlqcxQMFG55 ZEnScE9LRhVVRmp6eWtreXpqriOtExdeQERAfQNHOBdlYXV1BlGQPkxGTFt3UFBSrvSuFlJuVUVQ W1BgULfmQmIQX0BkYuivkONLd2Ri6K+QEE1dZQ9dD3ULdgt3w2BVSnlRYBV2Cnh/YGAdXFAgVuhT zBBxXFdcXVxgXU91dkR1dXZG6HJ0QF91EF9pdWF4dnVAWSBT6K+QEF56ZcBTURBTAFNSUwdiXOhT e+MfdlF26FHP5XZOtENqSuhTZRBbdrthdUd1YVpi1kh7e0Bse0Cmpq29QLQNvUCkDSF7vXtAbHtA kHtQb620115+e1gtQJRQSG+mvUClvXusUaVhYFEhDXt7exMMCBBEXRBfaV4QX2l1EF9pXBBfaXYQ X2l7e3t7ewlRYkZFRFZzcnZlZGZDUVZWc3J2ZWRmY2JHRkVEV1ZFR0ZGY2JmZ0NmZWR2c3JXVldl UYl6a2t6emtraq6tFaHcbxFhcE1GQkleUlNcXAEjfbBxe3FdQV1JVUVrenpra3p6a64krNGghGp4 T39DX0NKQ1tXVVRUN8pTUCFcSHZTUlRzUFBRUEivuFO7Vd5QY1EjEAdcckRpZRBdX2RlEEVlZRBA ZVpbWlxIW0lcAlDVQfVAV2dHb2UWRwZHVEt1SXZKfVNTUlRUUUNEREh2d3Z0d0FRUVR3eHdBeFBO T11BXmBdXFRbYFxjrnvoUUwQRXhiYGMdUERISE90dkR0dHZRVFFQVOhROxBiQXdEQUF3UXd2RFRc d1F4UFBQeFBjeE95e0R5eXtdXFZ5eFpOxUp3clt7eUBdSmVO2k/oUenmSLR06ES0du5Tf1BQUt1Q eFJTUHtR6+Jig3nor5DjSUtkeeivkOJMZXnor5DjeHlkeeivkON6ZGR56K+QEFpqZXlJZHlHYvdI e3seQKR7e3t7ex20tK22pr2kva29HkC2e0BsUG8drbRvbG9s11V+e1gtQJRQSG9RQmlpUEFHadde fntYLUCU115+SHteLUCUSFBApb17rFGlUEC9UUCQUEC9UUCQQJlXWEBsWGzXWEBsWC2UXpTXXkCU lGFgUSENDXt7e3tRUWdmZ2ZlZHZ2c3NncVdWVldWV1dGR0ZHRmNiZ2ZnR1ZWc3J3dlNXU3NRZ2Zl ZHZzcldlUh6utCLraEJcc3xzW1HlWhs9YzVwBkZwZkNDREFHZGtzPSRgekd4Ddk3zFEcTFV1c0di Vd6seTHOHEldWUBadnZUd3YbTRwY0YZ4eEF2A0nZB3FrUcYnrs1UJTFJQ0hwWnNQUFFQH6+4UjFV 3lBNUXkQGllQUUJQT1FPEEplBFAETL9PqUdUWnBbYFsQWwBbVFtNFUUKeExgTR1QUFBTUE1TT0JF REJCRV9bQk54RUJAcFtgWxBbAFtUWzxa6lHrUE1RdBBcU3VCUEJRkEKAQlJC6FFrEFpOWUJHQk5a JxxIe3tAbHt7QKYNIRMMCOlQQq+Q40deb0Lor5AQWWJJb0IQeERvQuivkON1Rm9C6K+QEENzRW9C EHFEb0IQR15vQhBAS29C6K+Q419Jb0Lor5AQWV5Hb0IQXUZvQuivkOVIaUIQRml7e3t7e3t7e3t7 e3t7CVG9tKS8DXtAbHtAkFBv115+e1gtQJRQSG+lvXusUaVQQA2ZYWBRDXtRIRMMCBBbWxBHXm9a EEdeb1Hor47hc2l7e3sJUQ1RUVZFREZjYmdmZ0dWV1ZzcnZlZGdRZmVkdnNyV2VSMa76SUNeQ0Zk aU4PAGtldmNwUV9xdnhHf1XeqwoJRF9EQXkGT9ZldmRydCBT+iNBSE9XdVBRUHOvuFU+U9lQA1IV ENRJUVFCaH1RCVkLXA9dB0QMaA1qDWsObAUCOEM5Rjp8KVwpRip8KGzZU9t822zZE81Ty17LZs0T 91H7XfFn+Wj/af9q/2v+bPoU8xXlaOZq5hh1O2Y4ZzoUUwJQCRQCAlPZZtgUyBVTNWkqZiVqKxQm GPNpVnhRdWl3F38FPwRVcXIDrhvoUUwQBHgCYAMdUF1qV1EZEV1aalFQG2RhQUERYVdXA5ZQV0RJ SU95YER5eWBaampPa25Ea2tuUBhQAxhPGRtEGRkbdlsZGBhra2paeQR4YHluaxsZQHLacehRE+NJ RHVg6FF0EFxJdXkQXmUweY95UnnoUmTmP2pR/2pRauhSUxBFaxBzZWsQS0xkP2tRawBaUVp1bv1r 6lGQUBhSU+Qb/QKZGeivkOJHaRnor5Dic2UZ6K+Q4k9lGeivkONLTGQZ6K+Q4kllGeivkON6fGQZ 6K+QEEd/ZGQ/Gb8ZUhlJBHlHa0cZR3kEWmLWSHt7QGx7e3seQKQNe3t7e3t7ex20tL2kpL0NQCF7 e70NIaQNe72kvUCmvXtAbEBsQGx7QJBQb2xAbEBsb9dVfntYLUCU11V+SHteLUCU115+SHstQJRQ SG+0bEC9bEC9UUFCaUFCaVBBQmlBQmlApb17rFGlQJlhYFENDQ0NDQ1RIRMMCBBBXUhcaWxIXGlQ clxpGkhcaWbor5DiX2lf6K+O4l9pVOivjuJfaVDor5DiX2kD6K+Q4l9pR+ivjuZDRG5yckNpe3t7 e3t7e3t7e3sJUA1RU2ZnZmdmY2JGRURXV0JnZmNiRkVEV1NWRURHRmNiZ2ZnR15Sc3J2ZWRnQ2Zn ZmVkd3ZzcldWV1ZXc0NmZWR2c3JXVlJXVlNzQ2dmZWR2c3JXd1Hs0gdtDwplamISRxfzwgEffmtC PnRZVlpaSWlicUkvCnZzf3kLT1JTW1xfen/aKB8Vx/tMRkBxdWztZEkOxOlIV3hPXWtZU9mubc8A LGhwEGJhH65RYSsUbxJqEa4rL15eWldDfBhFeNxiYHNgwVERP1xDQkleXnsvtce8Ug0ycUtKSHev UCVnroZS2ARDWUZzXHVQUVB3r7hT/VPZUGZR3xBZUUhcaX1IXGla6K+OEMxDRG5EckNpWH9GUEtS S39UAVcCWQJOAXApUSt92U72d/R46lLqdlsMUQx471FTClkKTgpwUzlWOVk6TilZKU4rdlYGegFl PHZTAlBRRHJJZUNySWVRUVJ6e3tQQ0RmFX0KeGVgZh1QUXN8UVB9z3NRc2FUVFBXV1xcT0twREtL cFB7UGZ7T3x9RHx8fXx7WkhbS2d4cEt9fEBE2kPoURPjXFd1cOhRdOJcdUvor5DiDGVL6FLF4mWZ fexRdFB7UlNQfK+Q4kdpfOivkOIMZXzor5DiamV86K+Q43pkZHzor5Djc3RkfOivkOJMZXzor5AQ Q0lKZL98UXxJZ0tHfEdLZ1pi1kh7e0Bse3seQKQNe3t7e3t7ex29tLSke72kvUCmvXtAbEBse0CQ UG9vbNdVfntYLUCU115+SHstQJRQSG9sQL0iUUFCaVBBQmlApb17rFGlQJnXQF4tlFhsYWBRe3sN DQ0b4GIDG+BmAQoI4XByaAlRDVANUQ0he3t7e1FTQmZjYkZFRFdTVkVERmNiZ2ZnR1ZXVnNydmVk Z0NmZWR2c3JXVlZXVldXc0NmZWR2c3JXV3dRlNXrlwxiEU0qRUBZXEFlb08NA2p+dXxyJEZKQ0x3 GvAJf09ixuZwc0pcTnZWU9muaVFH4BJlbDSuCxlAXkNdegZD1Wl3fXZgJVHCG3pESUh9n/EFNfVS IiFHRnFUVnRQUlBsr7hT41PZUF1QSVD9EBFYUllTVlpT9EP+SPBL4kLiRu5IVgtICUnVQ9xIxUPN SPVCV2ZDakkXQxlJB1gGQgRDV1pcXEF0W1dTVVVHdFRbROhT0RBCV9AbA2RX0BNl31fPV1JXSUpe 6FPREHdQEEdeb1AQGwNkUBATZVAQYmVQEE5lUFBwUGBQEFDwUFVQk0t7k0h7HkCmDXt7e3t7Hbke QKQNe3sduVBvvWxAbG+9bEBsYWBRDQ0NUA1RRFJUc3J2ZWRCdGNiRldkdnNyUkVERmNiQlPjz660 1tn9+VFL1NT79gsYw6cwGd2nUgDGror8/9vDUXj8/hYNM64LgA83UfNQUFKvTq4aU5hT2VBzUGJR AxAbBVHdXM1c/VzsXVVpRRtQFl4WRRh6BVY1XiVeKUr8eOlY7HnpeplKXhNyAFAGXlNgUGRyEFBT UV10YWJeXlBGSkdgRkVeRGBFcxVL6FH3EF54cmBzHVB0UX92UVBLf+hT3RByVFRQV3hQXlBzXk9K S0RKSkt2dFpbRkVeX0pRSmN4S0pAfOpT0VBXr5DifmVX6K+Q4nllV+ivkOJ3ZVfor5AQRXBlVxBP ZR9XURBXAFcgV/BXkFdVV+pTa1BQU3vkS3Nz6Eror5DnYmVKEE5Cb0ror5AQQkxlShBLTWS/SlFL SWNKR0pjWuhTauEGSHt7QGx7QKQNe3t7eyq4SH9Ava0NIXt7e3t7uXtAbHtAkCFQb2xvvddefntY LUCUe0hvUGxAvVFBQmlQQUJpaUClvXusUaVQQL1RQJBQQL1RQJDXXkBsbGxsLZRhYFENDQ1QDVFX ZmZjYkZFRFBzcnZ3U1ZFREZGY1dxZ2ZmZ0NmZWR2c3JXZUNGY2JuU2VkdnNyVldRlRU9+wkJLq7K vmIdYBlGR2QdWa55Wg0RdK1HT3BNZD5uOWQ8NwIRGWE8g2FT2bbQNt0hjK5pRkyurhxHRk9BdXVU aC9TPANES05Xd61DGmoixZozAAWo9lBQUlB9rhpTm1PZUHFQf1EWEFpWS1ZMbX0afVR36K+QEA1A S29YS2RSJlH6QflC/XL2dvR3+n37fuV3W8V2zH77S1M2UdF23H5TGEkaSwZRU2l9a38WUVN9Wn1/ ZndTx1BRf3BxQFpAW2BaWVFYYFlBcHV7cEFAcnFIfn1AeHHoU8UQQ1B1dE1NUFd4UFFRT0BxREBA cXvoU34QXEVbWlleQGB4cUBAUOxSU1BxUdhQeFPREEPvQL9AUkDQA2VAEHZlQBBPcmRA6K+Q4kxl QOivkBBwSmVAEEpNZL9IUUgQTkJvSBBKZUgQS2VIPGBAR0BgWmLpUbZQSHt7QGx7QKZ7e3sNe3t7 e3t7DbmkvXtAbHtAkFBvbG+9115+e14tQJR7SG9QbEC9QLRRQUJpaUFCaUFpaVBBQmlpQL1RQJBQ QL1RQJDXXmwtlGFgUSENDQ0NDQ17UA1RUVZFREZHRmNXcWdmZ2ZmZ0NWV1ZzcnZlZEJnZmNiRkdn V2R2c3JQRURGY2JnZkJTm67pRkdET2JarnFaMkh2YU7a1CIBFjQ26sgmMBcMR08XHmkqrqITYG0d Jc1T2avGHkZHcVhcdXVYWV8UPVG9kR5n8w/HURw6AxUcIPIQAq4M6hseFDdRE1BQUVB2UFBTaVPZ UHlQqRARUkhcaXFIXGkBUQVTDlkOWgJ5+lP8X/pI9UpZ1UrFSq97U9lUyVRSTk9PUVAVcbp4eWBQ HVFSRHBST1JRcX9dUV3oUc8QckR1VlZRV3hRT1FQT09wcURwcHFwT1p4cXBAYFkQWQBZU1nqUhBQ T1JT4nmZcOivkBB+R2lwEGRtZHAQfGVwEHRlcBByZXAQT3BkcBBMTWRQcFFQcM9w73CAcL9wr3BW cOhR2OV7cEdiHEh7e0CkDSF7e3t7e3t7tK20DXtAbHtvbNdVfntYLUCUe0hvUGxArbQNUUFCaUFp UEFCaUClvXusUaXXXi1AlGFgUA1RDQ17e0N1U0JnZmNiRkVEV1ZzcnZ3dnd2c3JXVldWV1ZXVldX c0NmZWR3dnNyVzdRCcD/3wFjcXZySH1HcVRSV1hbQV9KZQMxek56VnDJ6XBfRHFFaFMBaK5KUXsn FHd1Emx9Tk9DVlhYXhAyzBIDIkcuUj08fkJcQFlQUFGvva+4UrdT2VBgUOcQdGJRUUdyS0BvWFtU X0hbRV9qd1V4W3NfyVNTf1FvUR9RD1FUUehRVBBafpZQYFdVdHlXSehR5RBkRZZIR1tNdEFbUtpQ llEQQltvAFFRUZleaoBwsHCgcFMvcN9wz3CQcFRw8FhqdsVK2kmWSOivkBBDZGVIEGBlSBBxcmTw SJBIUkgsYepRFFE0UEh7QKUNe3t7pL2kvaQNDa2kDXu0vVBvvW9stL1vvW9stL0NYWBRDQ17UA1R U3N2dnNyVkVERkdGRkVEVnNyd3ZzcldzQ2NGRmNiZmVkd35SZWRmY2JHRkZjYmdSt211VTgdbhlN YdIc/dQYDnFCfUd1bXVWIjMcCUBM42PdP3BKXjdBe01T2a6d1ioUYHFsZt7AEDjxclx+URTILgVu eHJshDplMdZVU3d/UFFQB6+4UjZU0VBOUVbpUFWvjhAhX2lfEF9p9FW/UqteUwVL2lCmUVN0TWpQ C15TX3BNcFIvcL9wUk5QXl9RVFVXV1BNTE5LUUpMTU5IVUlUUVhQRkpJSVRUU8NQ8FJRVkNbUFdX T0ZJREZGSUZPeElGQFIZX1NPU1KvU1FTPHBQ/1df2l7qUVFQV1JTEFxCRhBmaWSQRoBGUkboUWsQ Wk9ZRkdGT1onHEh7e0Bse3tApg17EwwIEF9GEHhEb0YQTEFvRhBOQm97e3sJUa2mvUC0QKQNIbR7 QGx7QJDXXn57VS1AlFBIb29stK1sQGxAbFFBQkdpUEFCaUFpaddeLUCUVWxsUUCZQJlhYFENIQ0N DXt7UVNjV3NTVkVERmNiZ2ZnR1ZXVnNydmVkZ0NzZ2ZmZ1JHHs1BzPxMQFtJeUgDcQwCaGl8aHD3 x1o+wgpU0a6gb63iD0xBQnNEN0nWZ3Zne2Y/UhN3TifDUFBRUGyvuFOUU9lQbFHHENRYaklqUkJl YRdhBGw6RilFKkb8RZVQqkVZBX4EazpZUxtFBFAKRVNmUGxFUnF4eWlS+1lRaXZveB94D3ilRaZG pWlXRGtsbENZWnZ3aGlqRkdVY0VsQ3Z3S21+Y2NPS3BES0twe1dsUFZQU1NPQ2xEQ0NsSF5bS0Nt eHBLbENAWtpZMFPoUlMQS2z9QxATZUMQSElkQxBFZU9DH0MPQ99Dz0NVQ+hSZBBcY3VLEH5RfnVw xUJL6K+Q4mplS+ivkONISWRL6K+Q40RFZEvor5DjfGRkS+ivkBBJc3hkYEsQS/BLU0tJbVlLR0NH S0NtWieTSHt7QGxse3t7HkCkDXt7e3t7EwwI5UsQc0JvS+ivkONCW29L6K+Q4UZpe3t7CVEdpL0N QL2kDXt7e7S9pL17QGxAbHtAkJBQb2zXXn57VS1AlFBIb2xv115+e14tQJRRQUJpaUFCaUJHaUCZ QJnXXkBslGFgUA1RIQ0NDQ0NEwwIEEhFSFtpRUhcaVByXGlrclxpYHJcaU5yXGl7e3t7e3sJUQ1R U1ZFREZjYmZnR1ZXVnNydmVkZ2ZnUlZzcnZlZGdDZmVkdnNyVld3ZmdmY2JGRURXU1ZFREZjYm5S Z2dTlP53XVtBeQNOHwNnY3d8XUAb+rUyfhB8B3BBWkV6Gk8bBBBmdX94DndJRXE64SMRRlMhrfzV c0JBTzxHLWt2fHNyaBqorrmEEGEby1FlP0tcQU4wRiRne391Ztuu7dRzQ0cSs5eJHFBQUVB8r7hT 2lPZUHZQqxAR51FReBBAZXgQXGV4EF5lCVIIU+ZUiXFUeUxrTBlSU2hyUVhZWlFcXV5XSFdXUXB0 2lCWRVFXT3BbT0J/Qm9CU0LoUc/nX3dIEEdeb0jor5DiemVI6K+QEEt2Zb9Ir0hScEgQSNBIwEif SFVISnhP2nBQGXbor5AQXERlb3Yfdg9273ZUduxTc1BXUlNQcK+Q43x+ZHDor5DiemVw6K+QEEl1 eWRwEEdebwBw0HDAcPBwVHBwYHAQcFNw6FJM43dijkh7QKYNDXt7e3u9pg17tEC9HkCmDQ17e3sd rbQNUG9sb2ykvUlBQml/UUJHaWFgUSENDXt7e1ANQ3VGR0ZHRkdmZ2ZnZmdmZWR2ZWRmY2JGRURX VlZXVldzUnd2c3JXfFFxT0NLQVheLUjURHFdWw1jc3oQQErezkSadUgcSWpJflMbbhodIcserNpx 409leE5LShR6cGIVY2N/HIvoR4FSKc1jWVBRUHOvuFUbU9lQe1EJEFtIRUlLUlhFWUtSeuivjhB3 XF1uB0oDejVKMHqwSlV6RX9LbEYYSw9LDHo+SzxPOXv1d+R7W0J96K+Q42BqZH3or5DifmV96K+Q 4nplfeivkOJPZX3or5DjTmpkfeivkBBgR0xkSnqZUVFIUHLadZZ7dnZeXlBXTEtLSUlIW1JTVFVW VUFJS3tKTE9bf1tvW1Nb6FHP5VXSX0FRQehTZxBcUbVJ2kjSSnvaULVK6FLeEFpL2kx1H3QPdFJ0 6FN/4nq1TOivkON4RG9M6K+Q4ntlTOivkBBffmZkTBBxZWBMEEwATFNM6lNzUHxTaOGOSHtApg17 e3t7vaYNbEC9ra29QK2tva0NrbQNQUJpaUFCR2lQb2xAbEBsb2xAbEBspL1JQUJpf7RIf2FgUXt7 e3t7exMMCORLclxpR+ivjuJBaUjor47lQWlKcl9pe3t7ewkNUA17UQ0NUUNmZ2ZlZHd+UmVkZmNi RkVEV1ZXVlJXc1NRc1J3dnd2c3JXZXVGQ0ZHUVMKFf44bVpUZ0Z+dHlpX04HOrFndRGuM3xXdF9z SWNNfVFPbEJWVFHLU9mtQpzjOX9GQVlzdUVPe21jZH0G2POuuWhS5K0cUfunN3BHVnQT967203JS 9lBQUa/sr7hT1FPZUBZRWBAzXRBCW29XUFd6UG1RbkRQRlF0UHNRGksGUdlJ81H5Sfp6+G3/b0AY EEBlQEczcSNxmUmbcVVZc1x6AnNTVElKSlJ6entuEG5sEHhxclJKSk94EER4eBBueklUVEFlEtoW llBB6FPFEE9FalpaUFdllml3fn52W1R6SW5x2s9yn3JScpldUrQV6lEXUBBRdOJK0njoUc8QTUm0 bhBrG2RuEE1lbm4XcF0QXd9d/11UXUoYYkkX6FFE4Y5Iex5AtEC2DUJpf3t7Hb2kvaS2vUCkDb1B QmlpUG9sQK20b2xArbRApL1BQkdp115+e14tQJRRQJlXWEBsWGzXXkCUlGFgUA0NUXsNe1FGR0ZH Z2ZmZ2ZjYkZFRFdWc3J3dnNyV1ZXQ0ZGY2JnZmdHVldWc3J3dlNSV1Zzcnd2ZWRmY2JHRmNiZ2Zm Z3Z3dnZzcldlUTdhSUJ5CHM0dkhNe2NfTHRFSH9ASHFuBgJDSl1FTGd3c28xZ3ZocUUSzA5taXhx SHxwcHRKXlxDf/JJblVHGhhHTlPZZGR0ydRgB0BafnF2XklZQExkxa74H09HfhpCJh58b3dRea6h HmJNRnVxfHBHQHasaKNeEWZSdFBQUa8wrhZT1lPZUGhRQxALy2FRYUhqZVlJSkl5SW1J9lLkUupK 5HjoYpZTllSaSZpKXRlLCUs5S1NUYWB/f1VNe05KYUpBVGB/fn17eExLWHFhVVZXWFlaW1xYR1Rl 2miWRFBXdJl7d05fcehRkBBnYUEQW0JkX0FPQVJBeFwlRxBHXm/AR/BHUgBH0EfgR1NwR2BHEEdT RxlqaBnvZ1FvZx9nD2dTZ+hTcxBdVLVhEExBb2EQTkJvYeivkBBHdXlkwGHwYb9hUwBh0GFScGFg YRBhU2HoUkzjaWKOSHtApg0NDXt7e72mDQ20QKQNDQ17rbQNe0C0UG+tvG9spL1RQUJHaUFCR2lB QmlQQmlBQmnXXi1AlFSUbGFgUQ0Ne1EiUUZGR0NmZ2ZnZmdmZWR+UmVkZmNiRkVEVlBXVlZzcnZl ZGZjYkdGRkdGY2JnZmdmZ1N2dnNyV3dRG3JKXXxsImcBYVtWXmt3YHR8bjyunIvHwmRPfxF2RF1Y Q1hVV1ZfZxkwfmheaBJFZllT2Wo1xK5EGMwc0wBwQEFbXkNjcXliGRAfm64MqPsJf093EFlVf1hV WnIaMm5SKs0UVnVQUFGvk1BQU3NTIVBEURThQl3or7IQQnJqZFwQQltvU05yamRdVnFlU+ivvBAQ cWVmUptRn1KbU4pTqlNWfFNrUxldCFwIXTlSNlMoUiZTzVzNXfVS8VNdWa5UVLxYYFlEFV5evENg RF1CXk9QUuhRSRBZUVFQVlRCU09c6FFJ41pbWl3oUXMQXlnoUlEZRkTFUxBCW29T6FFzEFxcWxBL cGRvW1Fbw0XoUUTh5Uh7QK0Ne2y9e7RApGy0vVBvbLatEwwI6VBTr5Djc0JvU+ivkONEXG9T6K+Q 40Jbb1Por5DneERvUxBBRG57e3t7ewlsb2xAtkCtEwwIEEVeEHNCb14QRFxvXhBCW29eEHhEb17o r5DiQURue3t7e3sJbFF+vbxQQKVRfr28UEClYWBRIQ17e3t7exMMCBBCUxBfaVMQTXNuUxBFc25T EERpe3t7ewlDcUVRcWJmZmdjU3FlUXFyV1ZWV3P4UiutHFF1OGh/TXUHrSVS5K6wC0NMZ012UyFJ rWBAZBSuoE1SgFVWY2tQUFFQsK4WVE9V3lB0UNUQR9lCUVhTWEhIU5ZAVAZJNkklSVNFRkNb6lP1 UFpT9eRwTExRROhT/uJDUFDoU/4QW1FfTFdfQElIVFtD6FFYEF9RxnJPtZBXUVfGcrVUa1voU/ri WsZ16FF44ZdIe0CktKS9pA29QKS0QUdpQmlQb71vvUlCaX9KvbVCaWlhYFENDVANUVd2dmVkQmVk dndnZmZnZkJmZmdXVlZXVlJWVldGRkVEUkVERlJDW9PDywcGXDfETkRAPqfBWiHccEZfF+/ENjjM HK45c0PyIDZRdGkQDFx5XTwVf1FFgPpDc0o8G2SurfL1f3vABgeuixMRClBRUPGuFlCkVd5QU1By 6VBSUibnU1BQUXlSUlPoURnjVBIASHtApmxArWxQb71hYENBc0GkA1XeqOhXGFBRr+quFlKpVd5Q dVDAEElXU0ZTmkBTCUk7SStJU9dA2UnEQFNFRkNb6lP1UFpT9eRwTU1RROhT/uJDX1DoU/4QW1FQ TVdfQEpIVFtD6FGSEEBRcLWfV1FXxlRRxnO1VGta6FP65V9bT1tSW+pRXFB2UzXhpUh7QKQNpKSt tECkDb1AvUFHaUJpUG+9b71JQml/Sr21QmlpYWBRIQ0NUWdGRkVEUkVERkdXVlZXVlJWVldnZmZn ZkJnZmZndnZlZEJlZHZRllrTxMwIBlw2xE9EQD+mwVoh3HBGX093kMQ2OMwcVTtzQvIgN66NaRAM XHldPBV+rrmA+kNzSzsbZVFTFgv1YHrBBgdRdRISClBRUHxR3lQHUvZQR1AJ5FRAUV1F6FLl41QR XVnoUuUQSEARX1BPUH9QU1C9XVkjQEUBVFD2UVz2UehRDOdvXc9dUl3ZSOhSGeELSHtApg29vUC9 QLVAtlB/rQ2kvUCkvVFBQmlpYWBRY1ZWc3J2d3ZzclZXc2ZmY2JHRlRjYmZUen1U3DV+Oo3KERYw RHxW2Ax8fjhRAxUbNlLz0sNPChAGMdffXk7BMK+vr8xQUFUKVuBSdlB0UFBRV1DeUkRRJFBJEFxT UlBlf3NQEFJTUnzpUv9QeVB7UXtlZVCvr6/MUFBUiVbpUnZQdFBQUVdQl1GyUXxQRxBcUlNSfHJn GHdSU1Jo6VPnUHlQe1F7UK+vUNqu3lXxVTtSdlB2UFBRV1CYUY5QUFBE41FRaEHor/bmGHdRUW1Y eVB7UXuvr6+CUFBVX1daUnZQeFBQUVdQ3VFwUcBQTRBfUVBrUbBrUWtQiRh7UVFq6VL/UHlQe1F7 DSFlUK+vr5evsVZIVpdSdlBhUFBRV1CWUZJRIVBN51FQZ3BnUmdR6K7I5Bh7UVFm6VL/UHlQe1F7 DWVQr69QKq+xVe5W4FJ2UGJQUFFXUN5SQlEkUEcQXFJTUnxQ2xh3UlNSeelS/1B5UHtRe1Cvr1CK r7FW01bgUnZQaFBQUVdQ3lGMUSRQTuZSUdBsUWx16FHo5Rh7UVJSaelS/1B5UHtRew1lZa+vUGCv uFORVSpSdlAUUFBRV1DdUPtQUFBFEFpSUWlyNBh3UlFo6VLgUHlQe1F7UK+vUGCvuFORVSpSdlAU UFBRV1ATUMJQUFBFEFpSUWZySBh3UlFn6VLgUHlQe1F7UK+vUGCvuFORVTtSdlAUUFBRV1CVUPpQ UFBFEFpSUWdQUBh3UlFr6VLgUHlQe1F7UK+vUGCvuFOkVWxSdlAUUFBRV1DeUP5QUFBHEFxSU1Jv d+wYd1JTUmzpUuBQeVB7UXtQr69QYK+4U6FVBlJ2UBRQUFFXUJZQ+1BQUEkQXFJwE1ETfxYYe1JR EulS4FB5UHtRew1lUK+vUGCvuFORVd1SdlAUUFBRV1CXUPpQUFBJ5FJTUm936K8r5Rh3UlNSbOlS 4FB5UHtRe1Cvr1Bsrt5TPFPZUnZQFlBQUVdQmFCQUFBQRONRUWl16K/k5hh3UVFuWHlQe1F7r69Q EK+4UyFVKlJ2UBhQUFFWUN0lUFBFEFpSUXlCRBh3UlF46VLgUHlQe1F7UK+vUBCvuFMhVSpSdlAY UFBRVlATMFBQS+VSIHZRdkLor5TkGHtSUXfpUuBQeVB7UXsNZVCvr1AQr7hT21U7UnZQGFBQUVZQ lSVQUEfjUlF3ReivsuQYd1JRe+lS4FB5UHtRe1Cvr1AQr7hT7lVsUnZQGFBQUVZQ3ihQUEcQXFJT Un9CFRh3UlNSfOlS4FB5UHtRe1Cvr1AIr7hS/FUqUnZQlFBQUVZQ3ZtQUEfjUVFxUOivhuQYd1FR cOlS4FB5UHtRe1Cvr1AIr7hSZVUqUnZQlFBQUVZQE9NQUEfjUVFOUOiv7+QYd1FRT+lS4FB5UHtR e1Cvr1AIr7hS7FU7UnZQlFBQUVZQlfZQUHQQR1FQc3BzYHMQcwBz8HNWUHNPRVAQUVFz6VLgUHlQ e1F7DWWvr1AIr7hSoFVsUnZQlFBQUVZQ3vpQUEcQXFFSUndQSBh3UVJSdOlS4FB5UHtRe1Cvr1B3 r7hToVUGUnZQAVBQUVdQllD7UFBQcBBaUQAUMBTQFFMUUeivsuQYe1FRE+lS4FB5UHtRew1lr69Q bK+4U+NVKlJ2UAJQUFFXUN1Q+1BQUEUQWlJRTVtsGHdSUUzpUuBQeVB7UXtQr69QbK+4U+NVKlJ2 UAJQUFFXUBNQklBQUEYQWlJQTUtBQRBSUUvpUuBQeVB7UXtlr69QbK+4U5BVO1J2UAJQUFFXUJVQ +lBQUEUQWVJLUFAYe1JRT+lS4FB5UHtRe2VQr69QbK+4U6RVbFJ2UAJQUFFXUN5Q/lBQUEkQXFNS UHlzW1sQUlNScOlS4FB5UHtRe2VlUK+vUGyvuFOhVQZSdlACUFBRV1CWUPtQUFBL5VIwd1F3VOiv nuQYe1JRdulS4FB5UHtRew1lUK+vUGyvuFOUVSpSdlAIUFBRV1DdUPtQUFBH41FREGzor9jkGHdR UW/pUuBQeVB7UXtQr69QbK+4U5RVKlJ2UAhQUFFXUBNQ3FBQUEUQWlFRbWauGHdRUW7pUuBQeVB7 UXtQr69QbK+4U5RVO1J2UAhQUFFWUJU+UFBKEF1RkBJRUBJufmsQUVES6VLgUHlQe1F7DWWvr1Bs r7hTjFVsUnZQCFBQUVdQ3lDGUFBQSBBbUlEcaVAYe1FSUhPpUuBQeVB7UXtlZVBRUI2uMVR8VTtQ a1DQEEtmUWZWB1EFUgRVNFGoV1dXaFRMc3lTVFpoSWjoU/UQSXl5fl0RZEQRZA5+hnBQVPZThlBr aHOfeWHrUQFQaFBBUQHnWnn2SQFo9lroUm7jbOqwSHtApr2lvUC9QL1AtECkpL1Qb6S9tEC0Qml/ vWxAbH9sUUFCaUFCaWFgUQ1RVlJTc0JBd2ZmZ1ZWc3J3dmVkZmNiR0ZGR2Zld2RnZmNiRkVEV15S V2ZmZ2ZjYkZFRFZzcnZ2d1ZFRFL+CcTgdrtRaBdJGup1fXFJamJ/A2liEUNUe09gdmNdQiBwXW17 YDFhfWhpfExixAJbUvDPrtitiFKOUW9yYzwaWB9NRnN0Y01EWlMTMdYXZHVle3ZwfcVne1RYQHFj c3NlXhFaEHYQUFBSUDJTU1KZVTpQW1BHUGsQWpZelkCZRJtGVELsU8BQVlHXUFxTwORQU0UmU+hR 1+JfJlnoU0fjSOorSHtApr2tvVBvva29YWBRIVFiRkVEVnNydmVkZkdyVkVERmNiZmVkdlHF0ePk 0C/k49AN0tINDNPSVTrk0C/k5C/Q5ATSDQzT0wwN0lBQUlAirtdT8FVHUHVQf1C2EBMbXRpeUmZf URxbGXkKW1NfcXJTVFReXHd2VlVeVFQDVV1EVVVdXV5UVVZTdnJxd1pZSUpLTE1OT1dIQndFcXZQ clVU6FHr4lNeXetSdFB4UEVS1+VccXRfV3LoU8cQR1DFc3dWVlNbSHV/Qm9CH0JTQplPUFFQ6FFR EElhfHVQWR9ZD1lTWUlVYHhdQFVHVWBam9ZIe3tAbHt7bHtAkFEepA0dvUCmDaQNvVBvbECttKRv vWy9e61sQKRsUEFCaUFCaVFBQkdpQkdp1357LUCUQGxelJRs11VAlJSUlGFgUA1RDSF1VlZXU3ND dnZlZFBnQ2NTYkZFRFZzcnZlZGZmZWR3dnZzU0diZ1VDVldWVkVER0ZTAgeW1TxqOynaUW2JKGgk JTdueXF3QGhZXX1vvHn4zK4NtQppMjlySo0oIluuz1ExXcwqj1EpdlHeriIJGWwadU5FcGxEW1pA Xqy5U+T0Uq53ZQ2lLwNnd1BQUlBhr7FUYlU4UGtQF1CdEAtZVEpU/2PjUFTNZPNQ/3ZT3WTCU8R6 UzVQJFDTU1NWUFxyXHVRaVBrVVhASUB6RGpEVHJ1dnZwXV5sdXRzcnBEVVJTUVBhZF5eEkRsQW9V cFpNUXR5UnNzQXl/6FF15GYfeVVe6FEQ41pNbm/oU80QQVoFQRVpR0dBWxIfSkkYXfZe6FE/5XxK GcCwSHseQKYdpL0eQKQdvVBvbEC9QK2mvUC8b620QUJpf2ytbEFCaWlBQmlpUUFCR2lAmdctQJSU YWBQDVEhDQ0NDVFxV3FWV0ZHRkZjYmZnY1ZWc3J2d1ZWc3J2ZWRmY2JGR2ZDc2djQmdmY2JGRURW c3J3dnZ3dnNyV1ZXVlF2dnNyVkVERmNiZlIQUV5JrqdnAXdpCzZ6exxwfGnMM28hOHwLf2UWIQRf d0dET7dJiwTcIc0HOmJ0eExfS1pGTXZPf3pCrvJNf0J3aHZKcRFStgWk7F9JeUx4eCEiYgISEhNl EzZSUzpRegVRLMElMG95Y09BPVxJcGDZbawoQEBldE56aVBSr6yuMFREVSdQEVAeUMYQXeUXpnlS WVhWeUlYU3HoU/XiGGlP6FHWEFtffVF93GRpdxJpUOpT9VAQUdblUF1AXVJd6FFTEFxDaVZQH3EP cVJxsmfoU3HidOsb6FNx4lmfTOtRlVBtUEZTceRQslPreupRdVAVU3HlbUkf6mVIex5ApB29tKS9 vUCttL2kvb0NUG+9vQ2ktb1/vb0NpL21YWBRIQ1RdnZlZGZjYkZFRFdWc3J2dnd2c3JWRURGRkdG RURWc3J3RkZFRFZzcnZlZGZjYkZHRkdGY2JmZWR2d3Z2ZWRmY2JXclZFREZjYmZlZHZ2UnAQf5bc I85JQE5OdEdxYm8G0mqJeUzAN3pnF2GZw9T2eklMf1tefn0WDtdmG8EV3CBzfG8KhztoBjTCUq4G LBfHmdoYT0xDeNxKd9IKHyqhDhEbIcNGMy4TwJrDCHR/YBEHd3fQCxQuCPjfBiPdcwdq07cHbQfi DlBRUCFR+lI3U/BQW1AR6VBWUmPiUFdT6FEDEHJZEEBGZFkQSEpkWRBMZVkQemVZEFtdZF9ZT1lS WUlcPqZIex5ApA17e3t7ex29UG+tYWBRYkZFRFZzcnZlZGZRPDjDwzg4w8JT8MM4OMPDODjDUFGv oq4WU/NVHFBCUCUQXlJVUVZWVVVRUl9CVGdX6FNFEFpAQEFSVg1QVVFV6FJa41BUUVToUlrjU1NS VuhT+RBZUmdQX1FPUVJR6FE/EFxfQVFBSkRbSUM+C0h7HkC0QKYhHaQNbL29QGxAviGmIa1Qb2xA va1sb2xsQGxBQmlpYWBRQXNBc0FzQX5SZWRnZmZjcUVTThjrGe/tNHtqkcxRv1VFqWFWn6lhVENY BeE+PhYwM2dQUa7nrhZTrFXeUAlQohAQVgJGAlJHWnkCaW1qAlRcXV1bent7eQlQdE1xehIKXXlv SltWe3hycE5TSnUbHwkIZ3pUUBVbXV1PeXtEeXl7FehRVBByb1CZe0pKQ29WdH9Qe1cfdG9bdXRD X2JqU9prdc0S/RJSEuhRHxBBXAlRPAlRCYPPBVEF/wtHtE3oUVEQXXkKeHtAz3lReXkKWpvpUTVQ SHt7QGxRfw17bHtAkFGmvUCkDbQNIbQNra29UG+9b71vb71BQml/QLRAvddefnstQJRQQUJHaUJp QUJHaXtBQmlBQmlpUUFCaUFCaVBAmddAXpTXQF6UYWBRDVANUWJmZWR2c3JWV1ZXU1NWV15Sc3J3 dmVkZmNiRkVEV1ZFREdGY2JnZmdDQ25SY2JGRURWV1ZXTlJFRFZWc3J2ZWRmY2JGRURXVkVERmNi Z2ZnZmVkd3Z3Ul306whuaw59TWnvLHBKdDg1fWB2SnpOR3BdWlZYQHd1Y2fB3hQ44DzUzjoOEig3 OhMunAMWC39zTXdHQU1FdU0ZfWsaZTJTbbvdFw4TB2qUrTyu0zN/bzt/ckd5cHpPQ15HQFhYVFd2 ZexSRlG8vP08ySQzyGBxRUsc1x0vvcEwAGhmd01Pf3JfREtKECnL2yMcaF9QVFAVr7FVgFU7UF9Q T1ASUBxRRxBkXHZTY1NkQ2NDZFWbeJN/UlJ2XHhfflsYw3L0dv14+Rjsd+x4Wnl3e3htd214bxRV bClNZuhRS+VybSkSTXDoUUvmdH14fE19YetTE1BNUGVRS+Nzd3h46FHzEGZ+f0R+fn9+f3d4VHRh fmVlfWaEWBr1cHGEUH8T2HBgUWBgZXFAY1BTSGNYWR5HR0pMY7BUUVToU1jiF/x06FJs4mwcYetS VFBtUGxTWOJEY1zor5AQXnVlXBBBRWR/XFFcSR0e6FGG43GxlEh7ex6kDXt7Hb2kbK1sQK29pA29 HhU1FLZQbx29b71BQml/Db1sQKRsvUCkbGxAbFFBQkdp115+e14tQJRIe0C9UUCQe3thYFEiIQ1Q DVFiVEJFRFJUc3J0UmVkQnRHclRSRURCVGNidEJlZFJ0VXFiRkVEVldDRkdGR0VzUXNBRkZjRXFl YmZnZmVBZHd2dnNDYmZmZWR2c3JXU1rjUQTv7K7+6Oiu/+zvUQTi866a/vtRZPj4UWX7/q6arYRR 0sHINyeBdk5DcuiuihxWfROuwWB4WVdTV3V9vSY9aiEIdn5VO+eu++norv7r61EC6OlRBedt+K6Z +fiunPz8UWT4+VFn+ITTDRwjT66GZURcU3FRxa6bcU5xcUdGQB1SWxpdR0mu034DZQE+QFBQU1AV r7FVgFU7UF9QT1ARUIoQEvRi4EftSe1/VBFGH0ofTfRhVGVGaUpvThlTVFdSWVZZWldefnF+chxC HE4ecR5y8mtbcxBeQGRoEBNlYGFxT3JRcuhT9BBNdWlpUGBAYFJgxn4fY2NIaWlIQB9QSB9YUFNY WU/oUljmcGty9nFrYehTQxBFTHsOZmFhRGZmTEQTR0dKTB9fVFFU6FEO5EQfXEkS6FPP4StIex5A pB29rQ29HhU1FLZBQml/QWl/HUC9QKakvaS9UG9vQL1ArUFpf0Fpf620DUCtpA1sUUCZYWBQe3sN UQ0NDVFiVEJFRFJUc3J0UmVkQnRHclRSRURCVGNidEJlZFJ0R0NzdnZzclZXVlZFREZjYmdHVnNy UGVkUGNiRkdGY2JmZ1Na41EE7+yu/ujorv/s71EE4vOumv77UWT4+FFl+/6umutEd3TNPgLQeU54 5sWTJXXbpJiuqVFIin5tHklcQEZbVTvnrvvp6K7+6+tRAujpUQXnbfiumfn4rpz8/FFk+PlRZ/iQ rrgnJRRpe94fhJnyQ5tRU+mQUV9cSlhBTFBSUE5SdVflVRxQR1ASUZgQbRTQYRZkO39RcFJwR2BS YEcQUhBHAFIARzBSMEcrf9p/XHJIGn0LfTp8OX09flYKfAt+OUhTY0gafBx+U0nor44QWXV7ZDdJ On5SfeivvOJ+REjor6gQTHCebUvmcm2ebRLmc3GebXXmc3uebXbmcmCebWboUU4QdnNsnm1n5nJB nm1d5nJYnm1c5nNESX59cEhJYEpwfElHZnx/Q1J061P+UHVQd1P+53V2dmZ9fn5l6FP+4mZmaOhT /hBeZ2dcXVZXV0JCQ2dQU1LoU/HiUUZH6FPx41BIEkzoU/7iS0sR6FP+5xISUUpRUFJ96FP+EF9+ DUlJbEJBV1htbHx7cBTor5AQR2FlFEdHSnudcRBJSmRxEEZlcRBzemRx6FGa421gZ2zoU1AQQlhT 9lJG9kdrUFJrUfFYnVDxQetTWlATUBRSJeNxzABIe3umtK2ktECkvUC9QKa9bK17e3u9HhU1FLZ7 bEBsQGxAbEBsQml/Ha29UG9sbEBsQL1sQL1AbECubECubECtbEBsQGx/bGxAvWxAvWxAbEBsQGy9 QL1BQmlpQUJpUUFCaUFCaXt7e3t7e3t7e2FgUWhoaCF7DQ0NUA0hUXtDcUdzdnZzc0FERkdFcWVm ZmVBc3JWV3N1UVFxRV5SRUFERkdFcWVuUmVBUXNRQURGRmNjRXFlYmZmZUFkdnZzZWNSiEZyWgUz G3gSrtoRcxwPAF9yVDZRQVFZUUdodUJ2Ga4ia3lDrp1wrpxBdXd0rp5od0JBeGhVHJkYFa3tBH1T dHRWewJSFG8ema2UUmx1UUR8Fq58BXpUdHRRRnoRUbytPlLZrk4UeUZ0dER6FVGCHHhFdVBRUclU c1KxVSpQU1Bv5idRUVNQUVDoUS3jUlH2UuhRP+VTVUdHSlDsUkVQU1KmUFRRHuGXSHtApq0eFTUU th1ApL1Qf71sQGxhYFENUVFzQ1KxropyN1UqrvlRB1BQUlFcVDVTFlVsUFtQR1AT5EkQbWVc6FKh 4kJCUOhSoeVWSUdHSlPoUqHiWRpf6FKh40VJSOzpUSBQSHseQKQdraatHhU1FLZQfx29bEC9YWBR e1FiRkVEVnNydmVkZnFiRkVEVnNydmVkZlKLfW5ufXxvbq6ZfW9vfXxvb1Vsb318b298fW9vfXxv b3x9b1BQUq/EUFBXFlUcUBVQGFGsEA+gbKBtUnRydXVwenYXdhgVWwZbN1smW9VbyljEW8Z7+lj2 W/Z76VjkW+tw5Hu5F6xYr3avYqRuqBdK+RfqaukXUxp1OXI5F1NfYkkXUlBnZmZRQhYXQUMYFxdE WtRXV+hRkxAgWU1abnwVFQ9vTW5QbVFtGGhoMWxNbXxkZWXufU18XEFdTVxNcU5NTUxES01M/3pR MHogetB6U3pyeU16cnFxc0QXREREF2ZRUU5BF0RBQRcYFkMWfkJQQkBCUkJcemh+FVBgUBBQUlBQ QFBSUFx6TOhTPBBwTU1bW1d+XFgXZXh7ZX56Um2cX25RX25/bh9uU25b+VroU04QSHzCX3t/ex97 D3ufe1V7ShpwRFFE0ERRROhTFhBaWRcXQVlmZllRUehTURBCWUHQQVFBSVlBGXgXQEFHQRla6lMK UWpQSHt7QGx7e2x7QJBReyoeoCFRSH97Kh2hUUh/e2xRf3tAbFF/eyqwIVFIfw0eQKYNHaSktH8N IbRQb71se0BsUG+9bEBsUUC9UEFCaQ0Nf2y9QUJpDX+9bEBs115+e1UtQJTXXn5Ie14tQJRIUEC9 UUCQDSFQQL1RQJBQQL1RQJBQQL1RQJB+vbxQQKVRfr28UEClDVF+vbxQQKVRfr28UEClV1VAbGzX LZRsV0BsbGFgUSENDQ1QDVFTVkVERmNjcENjU3FnYmdmZ0NxV1ZXVkVERkdXcWdmZmdRZmZlZHZ2 c2dxU3NmZWR3dnd2c3NTY2JnZmdjU3NmZWR3dnNVQ1FUG9dCe30oUQnId9OsSVoIeWlzHK4PwR5G XmIQW64+Wm42IlKXZEhCdmJeU4sDellJchJizN3MMyxpH3Z8wHlCY3EjroKAreJS965jEUdFdlFj rtZ1TXgmUVPjMXpLTE94UnV1VRHeUyUQYERfSF51ru1hcWFyfklErbV0YT2uQxV6EHFEKFKKrXZQ UFNQGK/oVbZV01BIUHVQf1FNEJRWV1ZJVnZWfFRZV1hbWl9WR0hTSVdIW0lfRkd4W3ZIW1lCV3FZ fEZTRnFJfHpDdkgXSBZ2A3EPfCNxLnzUcdp8zXz7fONx73xEV1NmdhdTU3h8ZlNnSFN3U3hfdXFT VnFVclt8Wn3VcdBy3nzffVhbdndTXFxSUF5JdV1dUVteQXd2dUlUc1BTVX53dnVJXltTUFhNeVJc XHNdUURdXVFdYFxzQVFVflJFUVNNY0VTXVl5Y1lZc3ZfQU9Bf0FTQUlgfnZV6FFH42E10Uh7QKa9 HkCkDR29UG+9b2+9b0FpUUFCaUFCaUJp115+ey1AlFBBQkdpUUFCaWlCR2lBaWlXQF5sbGxs10Be bJRUbF6UYWBRIQ0NDQ1QDVENUWdHV0ZFRFBQc3J3V3dndnZlZFB0Y2JHRld2d3ZzcldWVlJFREdR UUZjYmZmQmVkVXvVZtgxrq+uDpvh2chnzGhgUVlRyZs8Cm1zdGMWDjIAPZXPQlPZrMQA+Q38n/pU qdpn2sLKia52rq4hymDyH90Fs1GfrnNIzhlxfXlptq4gmGccU2+sIsIIv1H1kn9QUVBHUN1UHlST UF9QNRBaVFVSUFpbXV95XuhT3BBbW3lah1hYV4dVeVToU9wQXFF5UF6HWF15V1KHUOivkONwemRQ 6K+QEFlKTmRQSUA9K0h7HkCke3sdpGytbLRQf62mraRsQKStpr1RQmlpQUJpaWFgZ2VxQXFlcUFj QXFFcUFxV0dRoq5eUaIAUaSuXFGlUd0BUfICUaGuXwKuDgFQUFGvolBQVKtVHFBqUfwQ3OlDUftI 6VTqQVM5Szt4OGZTZmlqamVLSEhMUFNUVGpHRENDSGFlYm1hXENdbVxxd3JtcWB5f21gW1RabVtw TE9tcGpUVJ1DSERDQ0hlampneHlEeHh5TEhInXh3RHh4d3l3ZUxTRFBHDVBEQERSRGlIeGZmSw1I SFtxcHBhYWBSXFtYeHhqSGVwZVFl6FF1EENqWWZmlWpZaWkRallLS5VIWUxM6FKrEENIWVBrU1NU WUdrRERDWWpqWVRU6FJY5kNZSEhZQ0PoURoQXFlDa3hIQENHQ2taPelRtFBIe3tAbHt7bHtAkFF7 KqJRSH97KpBRSH97KkChUUh/eyqQUUh/eypAgFFIf7R7QGxRf7R7KkCwUUh/eypAsFFIf3sqQLBR SH97KkCwUUh/eypAsA1RSH9JQUJpf1BIb2xvbEBsQGxCaX+tbEBsQGx/Da1sQGxRQUJpadd+e14t QJTXXn5Ie14tQJTXXn5Ie14tQJRIUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQ V0BsbFdAbGzXLUCUV0BsbGFgUQ0NDVFxV3FXVkVER0ZHV3FnZmdmZ2ZnZ3FncWdxZ3FTdnZ3Z3FX clZFREdDUWZlZHd2d2dxV1ZWV1FxV3FXUg9RlEWubU5wSE8yXq2tWgRHdkhBdXSuAERR4W+ua0NR 8Ct0bGdZUe1aCGxJIlFDCkRMAllR0ltqMgKuhFHbRK4IXVHrEjQ8ZHNCR1R1dVVbQ3VJLCcSgRNR wyUVWnZ2f3Z6Ba4tUSsuekFeQlN2dlYWIa42E0JQUa+CrhdUdlMhUGpQsxB02kNRCkI6QypDU1hA b10ZXQh6KV3ZXZdRlmaoUahfWkpLX0ND6FJWEFlzXkRzc15RVVXoUlYQeWpQRGpqUHNeWF9eXlFR UFZGd05Yd3Z2TltgX3pVanNreF5zUGpAS9pK6FFR4l/9Q+hSU+VzEFxBZHPsU21QVVJTUGqvkBBB W2pkQGpRaklrc0dqR3Nqa1rqUldRuVBIe3tAbGx7ex5ApA17Hb2te620pr17QGxAbHtAkJBRQWlQ b29sQL1AvW9sQGxAbEFCaddefntVLUCU115+SHtVLUCUUUCZYWBRDSEhUWNTVlZFREZjYmZnZmdD Y1NXVkVERmNiZ2ZnY1ZWc3J2ZWRnVlZzcnd2d1ZWV1ZWc3J3dmVkZmdmZmdRPcjDcVlmfHvCNEdw P8f3TFVxSUxLdH10TON+Zh1VHv8VbXxMTUxFXVlreXFBSENqcWphUyGuUiN7SGxrPPJiP1Esre4P TUt4d0ZOCgfIHxROYSIgTkRqDSHHMRdDSnFIZCAQzflQUlDiU25TU1U7UHJQf1CGEBpXTVFYUVlc dXUWURV1qUNWUVNTUH1xcnJCWltTQnpyUHN4ckJCF1NQRFNTUHNpTlNQU3ofR0dWH11ycrJQWVsB WlokU1lQUFlTU+iv0BBZYWVTSmFZd3dK6K+QEElhZXBKYEpSUEpASlJKSVNgeFBAU0dTYFrP6lEk UEhR0dV7e0Bse3tse0CQUR6kDQ17Hb17KkCge1FIf3tsUX97KkCiUUh/vXsqQLFRSH9Qf71sQL1v b73XXn57LUCUe0FCaUJpaVFAmddAXmyU10BelGFgUQ1QIVFTVkVERmNiZ2ZnR1ZzcnZlZGdnVldW c3J2ZWRmZmNiRkdnV3JXVkVERmNiZmVkdlNTLkBaV1pfSHpHDAhMTF5eBhVlYGIUJ/0SemNARywa HCB7TxiTe1U7rjljRFdcW0FmXtBLRk9gfTd4ThpvC4IndH4UXTDd1nlhu9JgYFBSULRTblN1VTtQ W1BHUHwQQ19pWVNFaVNFXLJQSklCslZJSOrpUSBQSHseQKQdvR5Aph29UG+9b71hYFFEVnNydmVk ZmNiRldkdnNyVkVERmNiZlN1tsILPrvfCT48amEwz21iCvFU48OyOwHatzl5Z2yvKmhvq1BTUH2v uFVoU9lQfFBrUBVRRxAI0FH0UlJ2ckJbb2xyQltvFXJCW29YFXZYCUQPSg5LC0wMYQ9iDGMJFTlE JBXFZvxI/En9Svth9Wf1FexS7UjrSuth5WfhFUlbTVFQQ0BDcENTQ0REQ0BbfOpTxVBQU8cQXFNb 2l9sT2xSbGxwe+hRdBB7eBJ0U1NldHhXQHdHR31hcFtEQ1ZvW2xRU1BdRJlvat9WUVZKF1C0EHzF XehSU+dMfDx72mKZTOivkOZwcWQQTFFM6FMnEEFwaHVzEExyZL9zUXNJFmIGSHseQKQNex29Skmt IXukrbRAvaRKSL0eQKYNHb20QUJHaUFCaWlQb71sQL1vvWxAvUC0Qml/Db1ApLRBQmlpQJkNYWBR IQ17e3tQDVFXZmNiRkVEXlJXVkVERmNiZmdHVlZzcnZlZGdWV1ZzcnZlZEJnZmNiRkdnUWJnZkJl ZHZzclBFREdGUWZmZWR2c3JWVlPFSNEuBjYc0Y0rXAwfFNkKSgiFDj/dVNlrMjkbOZbCPzETH1py rnNnHzrOaWMvrqN3S1JfhpZodGDTMFMpMSEHa2otDgVCFX4JMhgPTiIs3j5Ne5Z/Hyk+ylE3OQAA MdysqRAEUQfYGBKuZfdqYHFRH36WB3VoA/ZQUFNQVa/nU7lTlVBHUHNQflF4EONWUlZbUl5aX1pH U0hZTkpWRUJZV1JbWlVGVkcUThJPG3sJWwpeAE4ETwx7NFY0TyRWI08nddRS3F7QT957xVLLXsBP zXvzTvNP/XvgTuRP7nuKe3BndCdeUmZWal1SdFZ5QlJWT1t7Rk9Ke1RSW3R1XFxRXkdIc11QW15A dXRzSFRxUkdUfXV0c0hHXltSWEt4UF1dA1xRRFxcUVBRYFRQ2nBRV0t0RFd4dFhbXNpdW1GWfehT 0RBcT1RRVErwYFFgXZZx6FPREFvfQM9AUkBJf3uTSHseQKQNHb20HkANpg0dvbRQb71vvW+9SW9K vVFBQmlp115+SHstQJRQQUJHaVFBQmlpQkdpQWlp11RsXpRslNdAXpRUlF6UbGFgUSENDQ0NUA1R R1dGRURSVHNydndXd2d2ZWRCdGNiRkdXdnZzcldWV1ZFREdRUUZGY2JmZkJlZFOReCoV+6672GoJ Yyp3Khb/UXDWYwNkGnRtYgMcORhqUVJ9rbN1EWRkNSkiU5V40TM6yK6D8nJ5LHosMjDAUX78TXYf Z3YUDenFLFxIUaCtnG56aMtReC5YUFJQGa4WU35TgVBbUGBQMhBEWXZIdlK2Rbd6Un9xUXHwR3R4 X13oURPmVhZ/UFFQYuhRFxBAU1zaXNpd6FkWU5l0E0uVTuhReeVEdXv4YXvpUcNQSHtApq2mpK2k vaS9vUC2UH8NrbZvrbQNYWBRDVANUWJGRURWc3J2ZWRmU2NWVldWV1ZFREZjYmdmZWR2ZWRmY2JG RURWVnNydmVkZ2Z0ZlKYe2tsenpsbEJ2Xg7FLXxPIAgFZU5xYHNzYRnFMcrtfGpRFCpTgWt7emtr entrrsQv6M/VCG8THz10RExEF0dyfWJ4ZjwX/j8JEgaP+VBQUlDArhZS0FODUFtQcFAPEEdZXwlA CU3ZQNlNyl7JQMlNynBZX0ZRRu1SMFBcUF1RIVBWURXlUHFHR0lJ6lEVUEJRcuJc9l3oUT/nWR5T SnISAEh7HkCmHb2kvaStHhU1FLRQfx2tpmy0DWFgUQ1RYkZFRFZzcnZlZGZTY1ZWV1JXVldWc3J2 ZWRnZkNmZ2ZSSnpsbHp7bGxIdmF4SWJbRH1GdUt3Q3ooaVZDU4Nse3psbHp7bK7E5e7KrpJlCmBH fHV7b91RZ8RBZVBQUVB0UYhUDFM+UFVQeeJVeVDoUQEQX1NUU3lSUlFKV1BJVhIASHseQLRApmwd QK1sUH+tvWFgQ3FBc0FxdFRoH6xHUz6uOlEVUFBRUFKuAVO3VTtQElCgEBVPcHFyck5QU1QSEVVI QkZ6eHZ0U1JQV1FzbGlmRUdfSXZ4dGpoelNtYxFVVU9OckROTnJOQhFyVVNRVU5fcnRzEWNtdGPo UXPifVF06FE75FJzc31f6FNTEEJJdFl9U1leZmppdy9gUZ9gUWDoUUkQRlFKFFBzkHNSc0kTQjxG YVBcUVwHExTsUVlQcVJPUblQSHt7pg2ttB5AtA1Ath2mDSK9vVBvb0C9vUJpf2ytbEC9vUFpQUJp QmlpUUJHaUJp115+ey1AlFBBQkdpQmlpQUJpaVFBQmlBQkdpQUJp115slFWUlNdAXpSUbGFgUWNX c1JTUldWc3J2ZWRmY2JGRURXVkVERmNiZ2ZmZ2ZDZkNzZ2ZmZ2ZnZmdmY2JGRURWc3J2ZWRmZWR3 dnNyV1ZXVlL/4kH+ZCgOPwQJaBJ/Tkp3XlpeW0RBTmpPVgBXJOFfM2NBSnIZExIBbht4TEp1RllZ QXBKc1tLUzsSrqOuGa77PANtfHdidERGQFxXWF1aQQ7SRlHZc1GPEldBR3I0hGxrEn5zenNFQHVY W1hXSHFjKVBQUlAEr7FTjFPIUFVQW1DzEBAqUCpSKlYqWFQHUAdSN1A3UlR3UHdSZ1BnUhdQF1JW V1BXUkdQR1JUVltbUFBVV1hZWVJSU1tWDVBbQFtwW1Nb6FEh5Fj2WSRX6lJYUFpSWhBbUVANUFVA VXBVU1XoUSHkUvZTJFHoUljlf1RRVCRc6lHmUWVQSHtApg2tSaZIraYNvUCmrUmmSK2mDb1Qb2xA bEBsb2xAbEBsYWBRDQ0NIVFRQ3NTUXFRQ3NTUVIOrvw9fKdRhVHjrvw/fKhRg1PIrnKud1GJUY6u cq53UYlRjlBQUlB1r7FT/VPIUFVQW1DKEG58UHxVe1Z7WwtQCVI7UDtSWGhSGFAYUlN8UHhSaFBT WFBYUkhQSFJUVltbUFBVW1hZWVJSU1dWDV9bT1tSW+hRIeRY9lkkV+pSWFBaUloQWVFQDV9VT1VS VehRIeRS9lMkUehSWONUJF0m6VG3UEh7QKatSaZIraYNvUCmrUmmSK2mDb1Qb2xAbEBsb2xAbEBs YWBRDQ0NDVVRU2NDUXFRU2NDUVHyUQU+fKiue64dUQM+fKiufE9RjVGKrnauc1GNUYqudq5zUFBT UVqvtFZaUJJQW1BHUHNQbRBBUMdWXMdCSMdOTkJCVltLx3HoUXniX8dF6FF551PHWUl07IxIex5A pB2tpq2mvVBvbEBsQL1AvUC9YWB1YkZFRFZzcnZlZGZxYkZFRFZzcnZlZGZxYkZFRFZzcnZlZGZR KX8QEX5+ERFSb38QEX5+ERFSb38QEX5+ERGSEX5+ERF+fxARfn4REX5/EBF+fhERfn8QUK+vr8xQ UFT7V1pSdlB0UFBRV1ATUalRwFBH41JRdlDor4jkGHdSUXfpUv9QeVB7UXtQr6+vzFBQVQhWl1J2 UHRQUFFXUJZSQlEhUEYQWlJQY3dzWBBSUWLpUv9QeVB7UXtlr69QKq+xVe5Wl1J2UGJQUFFXUJZS RlEhUEYQWlJQYHRQQRBSUX/pUv9QeVB7UXtlUFJQfa+iV5FVCFBpUBpRJRA5WBFJEVJkFhdRHFwT fRttExYEUQtWC20LGTdRP1Y9bTsZJVEkfiV/1VHHUcVDz2fEEfZR8kP9Z+ZR5kPqcOV/7Gfvbe9u 5RO1fbhsv227EnV8TUxMfURkS0sxRU1EdHx7ew91TXRQ1GRk6FGTEHNpTVBzGE5O7nJNc0x9fU4a akQaGmp8TX1MTn57fHxSQm9+XuhT9xBdQ0t+QlJRZH5SWBd+VehTP+Vz+XRR+VDoU04QRUTCX0Nv Q1IfQ79Dr0NTQ0ocTH1qfehTURBEUBpAGnAaYBoQGgAaMBogGrAaWRroUz0QTFkUdlkQRGlZEAxl WRAXNGRZNRobeGpAGkcaG1rqUUpRalBIe3tAbHt7bHtAkFEepHt7ex29e6QNtWxAbFEeQKYNIR2k pLR/tFBvvW+9bG+9bKS9QUJpf2y9UUFCaWnXXn57VS1AlEhRfr28UEClUX69vFBApVF+vbxQQKVR fr28UEClV1VAbGxhYFENUA1RU3FyV1dydnZlZEJmdGNiR0ZjcVNzZmVkdnZzc1NjYmZmZ2NTc2Zl ZHZzV3NTVkVERkZjY2JnZmZnUWZlZHZzcldWUkVERmNiZmdXQS+tNss+vNqLIf+qUWUmWwrdwlLs B3ZXbTHCm8sAJCAbdHXAdUMWbWfRLUpHcho8JhY3y2WtMnMwMf/R9on8zN7aalEnrtlUWi20JOdR BaTBVVeu535OYgh3rbhyHASuRB9wZBJRrgcJSURyW0dw3ztSNidmYx8LJq5/jM/iIphQUFNQZq+3 VWBT2VB3UGdQEFCnEApvVm9XalpvQ295GVEcehVjCVE5Udlp1BDPVcRFwW/AEP56/3vwEO9V7Hqk WEZ5UWJDaXpTVVhDWFL0ROBEUlBQQFBSUFFRUHRP2l9oT2h/aFNoaFRudCBEUUToUXQQWUZGf3RB V3R3VOhTx+U/Vy9XUlfoUXQQeHh0WVtoT29RUVFQSWtPGXHDRLR8lmBXUVdXXFGZa2rwSeBJUklK EmXoU9EQQdBcwFzwXOBckFxVXEkRewZIex5ApA0dvR5Apg0dvbRJQml/DaRIva20QUJpaQ1CaVBv vbQNpL1vvWxAtA29Qml/Da1BaWlAmQ1hYFANUSENDXVHVlZzcnZ3VnNydmVkblJjYkZHZmNiRkVE V15SV1ZFREZjYmdmVWJnQmVkdnNyV1ZXVkVERlFmZmVkdnNyVlSeSjiLHho2QsPnKM0j8+ofDdBA zv0eBU57y48CWDETZX4SrKrTPNYfampnHB8zGlJWkZh7cQjxoE0mJQgI4frZLLr6DzMA4x5uaWUb IgNZanAKPEhxK49RQ+AZBn5v+oTsGQFRwnidMXhghVBRr75RlVRBUl5QU1BKEFxSZ1BQSlVRSVRv ZUh7HkC0QKZQfx29YWBRcWVxVEGrjVRzUZUZUFBRr71RlFdgUl9QU1BKEFxSZ1BQSlVRSVRvZUh7 HkC0QKZQfx29YWBRdWVVV2Co7VcTUZRRGlFQUFJR2lPhVClVO1BGUHpQBRBdR3pQRnS/ehFev0ZT R+hREOcfSg9KP0pTShFBUuVQcVEkUHdRGVBQURBQVFLlUFtRJFBBUdFQe1JtUY9QSHtApq20vKat tA28UG+9pL1AmUCZYWBRVldWRURHRkZHRkVEVnNydmVkZmdmZ1VWVkVER0ZGR0ZFRFZzcnZlZGZn Uv4cZkpVU31WV2x6eWtubXo4UbI1aFdTfVVXbHp6ayzFVRxPbk57RF1XZV1BQXpvEWVrLGNzZ09o GXJFX1hkWkFCfG9vZgb0FFBQUlElU+FUNFU8UEZQeVADEF5HeVBGeb90Rr9eEXRTUBFDURBQVFLl UFtQR1EQUEpS5VBxUEFRJFBbURlQd1EkUHFSfFB6UhnhK0h7QKatpr1AtLxAtLxQb6S9QL1AmUCZ YWBRZmdmZWR3dnZ3dmVkZmNiRkVEVldWV3VmZmVkd3Z2d3ZlZGZjYkZFRFVTEBtmS1ZSfVZYbXp5 a25tejmuTzVoV1N9VVdseXtrrr9Th05uTnlEXVdkXEFCeW4RZWwsYnNodWcYckRfWGRaQEJ7bm9n lS5QUFFR4lPmUodVO1BDUHXnUF2/Q1RQblPqUuVQWlEk5UBJRNWwSHseQKQdrbS8UG+9mWFgUVZW RURHRkZHRkVEVnNydmVkZmdShxwCVlNgVFdsd3lv3NVVHHENdENfWGBZQUZ8bhJiCeZiUFBRUcFT 5lLmVTtQRFB65lBERL9eVEHqUSRQVFLl4lBuW+pTUFBFUhbhjEh7QKa8tL1Qb71AmWFgUWZnZmVk d3Z2d3ZlZGZjYkZFRFZXUcEbf3RWVGBTV2t4eW/c1VOGcWV4dENfWGBZQEd7bhJiCeZiUFBTUEdR R1QdVGNQW1BfUEtQA+JQDlboU/HiXg1d6FPxEERADkZfXPNDDklf81MOWVlJXknzXeivkBBfTmV/ XQ9dP11TXUlMPStIex5ApA17HbRsQGxArbRAraRsUH+tpq2mvWFgUWJGRURWc3J2ZWRmUXFlcVFi RkVEVnNydmVkZlJidGNjdXRjY1IQq5pUZq21dWNkdHRkY1RjY3R0Y2N0dGOuHQKupWR0dGRkdHRk r6+vMK4WU8pVbFJ2UAxQUFFWUN4EUFBHEFxRUlISVgMYd1FSUm/pUuBQeVB7UXtQr69Q6FBQVQZW 4FJ2UGxQUFFXUN5RYVEkUHAQQlJRT2o/ai9qU2pQjBh7UVJSZ+lS/1B5UHtRew1lZVBSUEtQllOz VNlQTlB7UO8QBOxR5lLqWeNA6kfiSJxRllKdWZNAm0eSSI5Ri1lefFt8XnVKdk51cHx0fHZ1emxb bF5iSmROYnBsdGx2ZHpAzVL9UopSgViDQYxHVlnYQNha5l/mdepT31BcU84QWVHYSNhQ5knmT+pT 31BMUzcQW1jYUth4mFfmU+ZV6FNCEENymEHYR9hC5kbmb0SARFJEJHx96FEK43EmsEh7e6YNtLS0 tL2ttLS9tLRQb720tLS0rb20tLS0YWBQIQ1RIVFnR1dGRURXR1d3VnNydndXd2d2ZWRnd2dHZmZj YkZXclZFREZjYmZlZHZ2U0rfasA3N8Bq39bYCPd4wmjANjbAaMJk8BkVybDHg4TFxYYy/FOr3mnd 1MXK0sFn3zdtet9nwSX1zS7dad59aWRNhcbDhIbDC+AOUFFQJK+xUi5TyFBVUGsQXFBVV1JTW1AN cFVRVehRIeRS9lMkUehSWOV/VFFUJFbqUexRZVBIe0CmDa1Jpkitpg29UG9sb2xhYFFRQ3NTUVIu rvs/e6lRg1PIrnOudlGKUY1QUVB+r7FSaFPIUFVQZxBcUFVbUlNXUA19VVFV6FEh5FL2UyRR6FJY 41QkVybpUTJQSHtApq1Jpkitpg29UG9sb2xhYFFHUVNjQ1F+UQQ+e6mufE9RjlGJrneuclBRr7Ou FlRYVd5QDlCbEEQIU9lRx1H3UVRVYlJlVFBgaAsUC+hT/ucfHwgCV3xEfOhT/hBbT09zeRFacxFa BUDoUnAQWUlrEQgREQgFAuhScBBCGVBga3xQawsWDhzGH/YUAWgF61JyUAtQblP5EEQL9kBocGhS aNx8RPZPRg5Mxk8BduhScBBefF2FV/ZffFF8hQ9vK0h7QKQNrbRAtKWkvUC9QK0Nvb1AvUClraS9 QLRApFBvpL20QLR/pL20QKRBaX+9bEBsQUJpf71sQGxRQUJHaWFgUQ1RVlZFREdWV2ZmY2JGRURW c3J3dndWV1ZWc3J2ZWRmZ1ZXVnNydmVkZmNiRkdmZWR3ZmZlZHdmZmdWVnNydmVkZmNiRkdmZWRm Y2JGRURWV2ZmY2JGRURWc3J2d1ZFRFLkCD9EMn4J3nVPfnxOcwcRMUZSU295SHwuTwYCbXdOfX5M d8kMX3gLIERha3YCxnlNfn9wdssISRB6SXsvcgPCeU5hf3B4zgNAUqcXpiN7EAPZVWJ8T097cUlV DjTUBX9NbpEAWU5GfExNf2ZSa3RvbhWmKHxsdwYwVWJ+Tk19alMKJCQGfEsV7ABXY39MTH1lUxN5 ZFBRUMFSZ1E/U0VQW1BIEFtQx1ZT/llJXBIASHseQKQdvVB/vWFgUWJGRURWc3J2ZWRmUVB/EBF+ fhERU0URfn4REX5+EVBQUVARrq9RNlDkUERQfuVQRES/XkHqUSRQVFLlEFlQbk9bUVtJRRLpUbdQ SHseQKQNHby0vVB/vUCZYWBHZmdmZWR3dnZ3dmVkZmNiRkVEVlcRG390VlRgU1dreHlv3NWxcmR4 dUJfWGBZQUZ7bhJiCeZiUFBSUE6uqlNdUOVQRlB5UAMQXUd5UEZ5v3RGv15edFARX1EQUFRS5VBb UEdREFBKUuVQcVBBUSRQW1EZUHdRJOJxmnrqUm1RMlBIe0Cmraa9QLS8QLS8UH9sQL1AvUCZQJlh YFVmZ2ZlZHd2dnd2ZWRmY2JGRURWV1ZXdWZmZWR3dnZ3dmVkZmNiRkVEVVG5G2ZLVlJ9Vlhtenlr bmx7Oa5PNWhXU31VV2x5e2uuv7BObk55RF1XZFxBQnluEWVsK2NzaHVnGHJEQFdkWkBCe28QZ5Uu UFdQL6+aV7RVO1BTUEBQcFB8UGxQGVAKUU0QQAVyQENkBXJbXmRoclteZB3or47jW15kYOivjhBZ W15kTHJbXmRE6K+OEHFbXmRMUE5TQ0RLTENgS2hDHUsFF1AYUlpTUFVSUVtJaVroUWHmQWlUVRpp behRYeYCaRRdfWlx6FFhEEZlaXddQAxRDNBrZQzQSWUMR0dKEBMH6FF65h8TFyR0E2roUXrmYhN6 U7IQUOhR1+dweg1XUbIQUuhR1+NwVxNO6FF650YTXdBrbGRF6K+Q4m1lXeiv0OJ8ZV3or9AQXUpM ZF3QSWVdSQs+C0h7HkCke3t7e3sdraatSUqtSEq9QK1JSq1ISr1Araatpq2mrR4VNRS2e3shUG8d va29b72tvW+9rb1vbG9sYWBRDXt7e3t7e3tRUXNRcWJGRURSc3J2ZWRmZkdyV1ZSRURGY2JnZkJl ZHZRYkZFRFJzcnZlZEJHcldWUkVERmNiZ2ZCZWR2dWJGRURWVnNydmVkQkdyV1ZSRURGY2JnZkJl ZHd2VX2r+QdUCq1hDN2j3TjWJ+8FfnUaIGt3YXAVJ21SVTTdpdg23ajFYXgVPmh4YnMVJWtS2jLY JuEGNNupxGJ0ESZseX5NENBySVU7qg9V8coo6K6kwygmjCl6dBWui9BnEk5vUX/TZROtDcYo6q6k xCXpUUJ5dhGugyZpEHBvUXcqbhV4xC4mhyTGJuZRQXlxa66C02QRSmtRfy5qeE6vr6/MUFBUp1a4 UnZQdFBQUVdQlVGxUS1QRRBaUlF3UOMYd1JRe+lS/1B5UHtRe1Cvr6+CUFBVX1a4UnZQeFBQUVdQ lVEAUS1QSRBcUf9uUWllCRh7UVFt6VL/UHlQe1F7DWVQr6+vzFBQVKJXWlJ2UHRQUFFXUN1SQVHA UEYQWlJQeHZzUBBSUXjpUv9QeVB7UXtlr6+vglBQVV9W4FJ2UHhQUFFXUN5RAFEkUEkQXFJRUBcR QH0QUVJSbulS/1B5UHtRe2VlUK+vr4JQUFVfV1pSdlB4UFBRV1ATUWhRwFBxEENRX2hRcGjQaPBo U2hnThh7UVFp6VL/UHlQe1F7DSFlUK+vr5BQUFMYV1pSdlB8UFBRV1DdUDBRwFBH41FRckXor8zk GHdRUXHpUv9QeVB7UXtQr6+vkFBQUw5WuFJ2UHxQUFFXUJVQGFEtUEUQWVFwQ2QYe1FRdOlS/1B5 UHtRe2VQr6+vkFBQU8JW4FJ2UHxQUFFXUN5QHFEkUHMQRFJRL37fflIvflFQfnhISBBRUlJ16VL/ UHlQe1F7DSFlZVCvr6+QUFBTGFdaUnZQfFBQUVdQE1AEUcBQSRBcUXBPUU9IThh7UVFw6VL/UHlQ e1F7DWVQr69QKq+xVe5XWlJ2UGJQUFFXUN1SY1HAUEUQWlJRdlBSGHdSUXXpUv9QeVB7UXtQr69Q Kq+xVe5WuFJ2UGJQUFFXUJVRp1EtUHAQQ1JAeHB4AHjweFRQeHRQQRBSUXjpUv9QeVB7UXsNZa+v UCqvsVXuV1pSdlBiUFBRV1ATUl9RwFBFEFpSUXNQfRh3UlF06VL/UHlQe1F7UK+vUIqvsVbTV1pS dlBoUFBRV1DdUaFRwFBH41FRZl7oUcDkGHdRUWXpUv9QeVB7UXtQr69Qiq+xVtNWuFJ2UGhQUFFX UJVRiFEtUE8QQlFfZE9kf2QPZFRkSlAYe1FRaOlS/1B5UHtRew1lUK+vUIqvsVbTV1pSdlBoUFBR V1ATUl5RwFBL5VFwY1FjXuhRTuQYe1FRZOlS/1B5UHtRew1lUFBRUAivuFGHU9lQTVDFEH1kTBRM UlxHUVpbTRVFCnhMYE0dUFd4UFNQTVNPQkVEQkJFX1tCTnhFQkBb2lrtUetQQlBQURdQU1Fz4k08 QuivkBBMamVAQlHwQlFgQvBCkEKAQlRCSU5CR0JOWifWSHt7QGx7HkCkDSEiex20rbZApL17QGx7 QJBQb9defntYLUCUe0hvUKW9e6xRpUCZYWBRIQ1RU1ZFREZjYmdmZ0dWV1ZzcnZlZGdDZmVkdnNy V2VRh5ZEQ11fRWlqcxQMFG55ZEnScE9LRhVT2a0TF15AREB9A0c4F2VhdXUGUZA+TEZMW3dQUVCu VH9TRlU7UFZQGRBDV1ZHVlJTs1BVVFRSUlFWT1BRUOhT++VRVfZUh1DoURDiUgFR7FNNUFdReFHw UEh7QKS9tKS9UH+sDWxAbEBsQGxAvWFgUQ1RQ3N3VXNRUpsbRfmukUtRZ1U7rpSamlFsUFFQllQe UxZVBlBGUB4QQltGRVpUUFxdEVwRVFBREVkTQOhTyRBEUENRQxNUXGldSUdRaXBQUVCaSM/pUSBQ SHtApg29HkCkHa1Qf60NpL2kbEC0tFFBQkdpYWBRY0ZWc3J2d3ZzclZXc2ZmY2JGY2JnZlN1TlMg GxnvRkFGdX1ecFc6GxmDd3NGTVUELtgqWlhkBNwo3EpxUFBSUS1UQ1KnVd1QW1BHUBHiVh9C6FPb 419fUV/oU9vmXB9QUFMfRehRP+NQVlFW6FE/4l8fWepRL1BIUe3hq0h7QKatpA2kvVBvraYNpr1h YFFiRkVEVnNydmVkZkdyVkVERmNiZmVkdlJqHz4/Hh4/PgBkGRlkYxkYVd0+Hx4/Px4fPhAZZGMZ GWNkGVBQUa+Lrt5RAlBOUEVQDRByVVtEW3lYd11/XlVERVpbWkNERkVRUFNUQFpYW0RYaV3xROhT +OdRlUZFUFQFQOxSWlBGUOpRxFBIe0CmvVB/bECkvaS9QmlCaVFBQkdpQmlpUECZV15sYWBQDXVX RkZFRFdWc3J3Z0ZjYmZlZHd2d2dRVH1rEGgcNmcGXGJ0EBdFTGg+ThxdHmcTYG9GcVxte3VCR1H+ UFFRAlR/UzpVO1BWUBkQQ1hWSFZSU7NQVVRUUlJRVk9RUVHoU/vlUFX2VIdQ6FEQ5FIBUUlX6lHm USRQSHseQKQdvbSkvVB/vA1sQGxAbEBsQL1hYFENUVNjR3VjUVHNG0X5UW9LrplUf1FsmpqulK+v UF6vsVQOVrhSdlBmUFBRV1CZUKRRLVBH41FRbEXor67kGHdRURLpUv9QeVB7UXtQr6+vva+4UxtV O1J2UAZQUFFWUJmxUFBH41FRYXnor4LkGHdRUWfpUuBQeVB7UXtQr6+vrFBQVLNWuFJ2UG1QUFFX UJlQrlEtUEfjUVFEUOhRNeQYd1FRSulS/1B5UHtRe1Cvr6+TUFBTG1U7UnZQDVBQUVZQmbFQUEkQ XFFgRVFFUL8Ye1FRS+lS4FB5UHtRew1lUFBSUPGuFlCkVd5QU1BXUGvtUFJT81BXUQZQVlImEF9T UFNSUFFRVVVUeVZXV1LoURnjWBIASHtApmxAbK1sQGxAbEBsUG+trbZhYENBc0FDQXNBpAMDA1Xe rUpStqvOrUpStlBQUq+AUFBV4VUcUHBQZ1CCEBlYcS1hKmVTcnV2dnFdWlleUFlRTVBEXkNNRHF2 dk5ZXkRZWV5zXHN0W2BbEFtSUFtAW1JbUGZ+RFJ9flBYWWh4XllAY3ZJSml07FEdUHJRSFB1URLm dl9bUVsuXepRSFBaURLjWXGEdupTUVBeUxUQWVlJaFlZR1loWupRI1FFUEh7e0Bse3seQKRRHbSt tECktLQNQKS0tB5Aph29e0Bse0CQUG+9b71CaQ0Nf2ytbNdefntVLUCUSFBAvVFAkFBAvVFAkFds bFdAbGxhYFENc2dmZ2ZnZmdmZ0NzZ2NDZmVkdndncXBUQkVEVlZXVlRzQ1NxV3FTVkVERkdGY2J0 Z2ZCZWR2c3JgWhdbTExFX0VxKeNH4TNNbQ5aUehRRlFX8Q0hNNautYTfy1EiRK7dJ3JFQUprzVFf ByrDtotlcVZSWERAS3ciUcwaUQE0d3hgUncurr3H063FHTgKVVOtvBquNCZIXk5VWBARDVERmr69 UFJQZ6+4U4pV2lBOUH5QjBDeVlFaQFZHVkh/VX9We1f/Vf9WWXBWE3IeeglfBUcHcQVyD3kMejJS 8lXpV1xUUXRSAlFTU1hYVllZUlBQTVtaWlFVVlhTUFN0W3xMTE93W1hVU1BVVklZUllaUgNRWkRR UVpSUVFSTHRZWmBeWllSUVRJVlBPdElXd3RCW3R1RUl/TBl8dU9eUV5KYHuTSHseQKYNHa20HkCk Hb1Qb71vvW9CR2lRQUJpaUFCaWlY1357WC1AlFBBQkdpQUJpUUFCaUJHaVBAmVdAXmxYbFdAWGxe bGFgUQ0NUA1RV3dndndnRkdnR1dGQkVEUlRzcnZlZEJ0Y2JGR3Z2V3JXVlJFREZjYmdmQmVkdlLo jEyPfWJNHmiMS4QMBf6uu9jS4/pRSz1hFXdUcC0YGjHFMRccGzXaMFTMJ2EoCxJPHBwpYyLIrqXe kK7p9ube1lF34HF7OMCxbACu6vIPOBIJUTHRCDZQr69Q6FBQVQZXWlJ2UGxQUFFXUN1RIFHAUEsQ XlE/ZC9kUmRQqhh7UVFj6VL/UHlQe1F7DWVQr6+vMK4WU9ZVKlJ2UAxQUFFXUN1Q0VBQUEkQXFEv bFFsVO4Ye1FRa+lS4FB5UHtRew1lUFBSr59QUFSIVRxQeVBjUKQQHzJJUVNyU3NpQWx8GUETdyp8 L2DrRO1grVdbJli/V1JQemNPUUlPSk1JWUBaTVlYUVdNWEhBR01IUUB+WUFJT3hBQEBOUU9EUVFP YmN+cE/oUSoQSUh4SthJSUhSeVB7en5fUFFQyVlZWFh+dnXor5AQcklxZJB1gHVS4HVRdUplUWR4 T0BQUYBRUl9RUVFRZFpsDEh7e0BsUX8NIXtse0CQUR5Apg0hex29UG9sQKQNrWxAbG9sQL17QK1Q bK1s115+ey1AlHtBQmlBQmlpSFBAvVFAkFBAvVFAkFBAvVFAkFBAvVFAkNctlGxsYWBRDQ0hUVdW RURGRmNXcWdmZ2ZnZmdDZmVkdnZXZ3FXdlZXVldjYkdGRkVEVlZxd2NwZmVkd3Zzc1HQW3BLbBRa rblZHk16REt0v09Mbm5bUkJZABxKRHmMLmk705i4rrMo31FZiQJmKJRRYXciTkl1R3V1UVxDTXgs U2k5dEl4R1F5eVF4fXHFQU/PINuPbxOS4NlteFBQUq9OrhZTmFXeUHJQYFChEGDvYlFlRhVdCFAF XQhKNl3pdld5Q2ZdUlFzXFxQUVxzYF1dUEVJRmBFRF1DYERyFUroUfcQFXhxYHIdUH9zXFFUeWFd SVpFSlBUeFxaf3NRU3x1SklJT11QRF1dUFBQfCVUV3V0WltFRF5iEF5Db2IQXUFvYkdHSld1eehS HhBZXWF4UEBdXWFa6FEU4QZIe3tAbFF/e2x7QJBRpq0eFTUUtnt7UG9sbx29b71v115+ey1AlFBB QkdpQml7QUJpQUJpaVFBQkdpSFBApb17rFGlUEC9UUCQUEC9UUCQ10BebGxsLZRXQF5sbGFgUQ0N DVFTZmZjYkZFRFBzcndTVkVERkZjV3FnZmZnUWZlZHZzcldlU0ZjYmZCZWR2c3JXVldSC4s9+wkJ Lq7KvgkGGUZHZB1ZrnlaDBF1UcJIcE9NZHhuORvkyxlhBwzRbFXerUXQNt0hjK5pYq6uHEhHTkF4 eFNp0FUiAkVLTlh4q10a3VEUzQAFCCqcUFFQ9VFeU4pUE1BbUMQQRVFUV1pUWVtRVFdaVFJQWA1Z UA1bWepScFBbUnDnWlYNVVINU1XsUnBQU1JwUFpT+OdUWc1YVc1WWOpScFBWUnAQWleyUVvNUFPN UlDsUnBQUlJwUFFTcONc8oxIe0lAprS0SEC0QLRArUm0tEhAtEC0UEl/SL1JtLRIQL1AvUlAtLRI QL1AvUFCR2lRQUJHaWFgQ1FRZ1FRR1FRV1FR9VExrvBqUTBRMGiu8FEyaa7Ors9RGFExUTBqrvBR MGmu8K7OalEyrs9QUFFQ81LGUj9VOFBJUJ0QGldJRklSL0cvSC9JU11bXVxESERJdUhgSBpQG0Ep UCtCL0faQlwZUAtCUltAXG1bWlFZbVpCQ0RFRkdWSEFQUVBJURdAQURAQEFB61PNUHhQSFP+40nN UFHoU/XkQLV4WlvoUWHjUFVRUOhTfhBMREFRQX9Ab0BST0BRQCRZQEp4QUBAR0BKWtUrSHt7QGx7 e2x7QJBRe6YNDYQNpZRQb61se621UECkrXu2115+e1gtQJRQQUJHaUhAvVFAkFBAvVFAkGFgUQ0N UA0hUVNWRURHRkdiR1dxZ2ZnZmdDZmVkdnNyV3dSP5FAWl11WkJarudeFkFKStlfQF9eel1VOK3m f0VCV1pRUU9PUV5EH1HLfEJeXldOUFFQP1LGUvtVOFBLUN8QW2VTA0ZSS0rNSEhH6lP4UFJT/uJR UVDtUWFQX1BbURBQWVP44l9VUOtREFBLUEdRIRBFf0hvSD9I/0jvSFVfSE9IUkiaSvZL6FEQEEVN R0dKQhNWW/ZcyFbzUlJRSUw+l0h7HkCkbB1ApKS9QK0eFTUUth2kraYNDbZAtFBvrbRArWxAva1s QKRsYWBQDVFxZXRnZmVkdnNyV3dmZmNiRkVEVlZXV2NiZ2NSQ64MUWYPexJnAGd3TyoaBTtwIg3l 4QhLYFLGS7rTam9jERlAFgAzFHIe0x7DEFBRUNRS2VLIVThQelAvEERWREZHcEVgRVRUREtEUkRr T1BRUOhT/hBBUX9Rb1EvUd9RVFFdcBN0H0noUQYQRF1bEVq1WB9dVXxHR0pVE0DNRhN46FJwEF1N W/ZazVHGTUl7PrBIex5ApB2kpL1ApK2kvR4VNRS2UG8dva20QK29vUJpDX+9DbQNYWBRDVFlZmdm ZWR2c3JXd2ZjYkZFRFdWV0ZFRFZzcnd2ZWRmY2JHRmNiZ2ZlZHZRRcYVfGJ3a2R6E9MeCnF7CyDp 3wF6SnNOTX4SdnROeTZUQUpDZ3Rhd2EZW9QAZ312YnJmPTf3S0FFRE5GcHdkFhgOUFBTUPGvmVXR VThQU1BNUGpRBxA0502xTLFNsXVUXl9cQH9VekB/RGtVakBrROlU6EWGcIJxhGWGZrVwtXG/dL91 tWW1Zqxor2mvakdfREBtX15VXW1eRUREF1VURFVVVFFQUGdTUkRTU1JSUVNQVGxre3d6cE9meuxR EFB3U/hQflFh5U9qac1mZ+hT+ORPRLVfVehRP+J4X17qUZhQRVFy4lR4TehT/hBB4ExRTA1UUFNT VFV4Tk8RUlHoUqXlZrVPafZO6lEQUGpREBBCYU9w83R69nvIdBNhSmxUVVlF6FJYEEFURLJV81Vr eFRAVVVrWhKmSHt7QGxRf3tse0CQUaS9QL17QJRRHkCmHa2kvUCkbECktL1AvVBvbKRse29QbEBs QK0NvXtAtFCkbHu0QL1QQK1spGxAra20QUJpQUJpUUFCR2nXfnstQJTXXn5Iey1AlEhQQL1RQJBQ QL1RQJBhYFENUA1RUXNRcVNWRURHRkdiR1dxZ2ZnZmdDZmVkdnNyV3dRcWV0Z2ZlZHZzclZXd2Zm Y2JGRURWVldXY2JnY1VQrAkJU/etlpFAWl11WkJarudeFkFKStlfQF9eel1TK64MUWYwehFofG5N dk8pGgU7cCIM5uEJS39VOKoxVc+t5n9FQldaUVFPT1FeRB9Ry3xCXl5XTqryS7rTam9jEXJ3QBYA MxRyHtMewxBQUFRQ8a+ZVclVOFBTUE1QeFB7UfsQxudNs0mwSrBLskywTVZdX11AWHdLd3tVekB7 RGpVakBqRAZM6lTpRF1ydnFOc3V2cXl0T3pwTnN7enB5dF9EQG1fXlVdbV5FREQXVVREVVVUUVBQ Z1NSRFNOUk5TUlNSeHd3Z3p5RHp6eXNOThd5dER5eXRSUVNQVH18dXt0T3BycVRzTkhHRlNFS0pJ U0xNeXhwenF2d+hT9eJ6Z3brU/FQdFBNU/4QWuBMUUwNVES1X1XoUT/ieF9e6lGYUEVRchBaVHhQ U1NUVU54eOhRYeZzUlFRc3N06FKlEER4Tllzsnl0dll3DV96UXqadPN9RehSWBBFVFlEslXzeVV8 eFRVdHlAVXlVeXxa6lHmUWVQSHt7QGxsUX9/e0BsQGx7QJCQUaS9e4RRvUCkpg2te5RAlFGte4R7 b2xQQGxAbECte2xvUGxAbHtAtFCkbHu0QL1QQK0NvUCmrbVAbEBsQmlBQkdpQUdpUUFCR2lBaWlB Qkdp1357LUCU115+SHtVLUCU1w1+SHstQJTXXn5Iey1AlEhQQL1RQJBQQL1RQJBfX19fYWBRDVAN UVFzUXFTVkVER0ZHYkdXcWdmZ2ZnQ2ZlZHZzcld3UVNjV3NXc2dxZ1FXUWNVYKwKClP4rcWRQFpd dVpCWq7nXhZBSkrZX0BfXnpdVHvxOEoxbjhurolMUbUPrpiFVTiqMVXPreZ/RUJXWlFRT09RXkQf Uct8Ql5eV06tNK5lGunpAFGV8q6HUFRQ0q+ZVclVOFB6UH5QaVBsUdYQ3SZC1ELAQvRC4kKVRIBP gHCDcrBxs3K4eaJEXQBEUVhoSWBJaJREiHlVAERRRER0RGREU2NnYmR/ZmdiZWpsa2FlalpbaWho Z2tqRGtran9kZBdlakRlZWp+fX1nfHtEfHx7bGZlYWJgY1Rkf0RVW1pRUFRNeHx+e1NufURaUWpp a3x9Z2VoSWFrYmtnZ+pT8VBpUWHmZGVlfHh8fehSpeR7fn5dUehT/hBEAFAwUFJQO0lwzXRatV10 H0lYH0noUQYQTl1Vf1lksmplZ1loDV9rUWuaZfNueBNGzVUTX0BRQOhRkhBATUltfX1uZW14akBl ZW1aPulRMlBIe3tAbFF/e2x7QJBRQml/HkCkHa0NvaStQKSmDa17lECUUa17hFBvvb1AvUC9QLRA pA29QGxAbG9se0BsQGxQvaa9bEBsQWlBQmlpQUJpQUJpUUFCR2lBQkdpQmlBQkdpQWlp1357LUCU 135Iey1AlNdefkh7VS1AlFFAmV9fX1ANYWBRIg1QIg1RZWZnZmVkdnNyV3dmY2JGRURXVldGRURW c3J3dmVkZmNiR0ZjYmdmZWR2UVFzUUNTY1dzV3NncWdRV1FjUUPGFXxid2tkehPTHgpxewsg6d8B ekpzTk1+EnZ0Tnk2U/msCgpT+J3xOEowbzhurolMUbUPrpiFVEFKQ2d0YXdhGVvUAGd9dmJyZj03 90tBRURORnB3ZBYYDlELqjFVz61/rmUa6ekAUZXyrodQUFGvv1XmVEJWWlBTUE4QWVJzUFBKVVFJ VOpRI1F2UEh7HkC0QKZQfx2tYWBRcWVxVEKrjVRzVeYEUFBRUEGvuFThVThQYVCY6VBZr7DjQkRk duivkBALQEFkdnR4eBBZW2R4eHxPX0NeXkhaYU8QUE5OEFlcZE5JVUhUSUlafGN0U1o0Q1lWU1Fg VFhVVFRYUGFhWHZ42BB3X15fXxBZXGRfY+twUUdKTXBUWEVOT0hJWOhTL+dFEEUQWVtkRX97UUpI QB29hJ2GnUFCR2kNQJZ7UUFjSECGSh29Y0Fpf51BaX+dQUdpUG+9b71BaX9sjWxAlntQQGxKSI1s QUJpf0JpQUJpf3tQQUJpe2FgUXtRcVZXcVdxVkVAY2JnZmdHVldWc3BBZGdzZ2NnZmdzZ2NmZ2Zj YkdTc2ZlZHNyV1ZXcVMqrbZfXFJORq20T5/WPhIkSS0H3vGu5UkORgpVWF0MRjU2/Ja1+98Fd1uM ztw9AVJEUrF6eR4qOq6wFXkjRNhqD1EtNSYeQE51Hr3K4giuhWlgiPfSnlBQUFBSUFCvv/qRr3FQ NFBQUFBQUFBQUFBQUFBQUFBQUFBQUI5QUFFSUVNQU1BUUFVQVlBXUFhQWVBaUFtQXFBdUF5QX1BA UEFQQlBDUERQRVBGUEdQSFBJUEpQS1BMUE1QTlBPUHBQcVByUHNQdFB1UHZQd1B4UHlQelB7UHxQ fVB+UH9QYFBhUGJQY1BkUGVQZlBnUGhQaVBqUGtQbFBtUG5Qb1AQUBFQElATUBRQFVAWUBdQGFAZ UBpQG1AcUB1QHlAfUABQAVACUANQBFAFUAZQB1AIUAlQClALUAxQDVAOUA9QMFAxUDJQM1A0UDVQ NlA3UDhQOVA6UDtQPFA9UD5QP1AgUCFQIlAjUCRQJVAmUCdQKFApUCpQK1AsUC1QLlAvUNBQ0VDS UNNQ1FDVUNZQ11DYUNlQ2lDbUNxQ3VDeUMBQwVDDUMZRVFDNUM5Q8FDxUPJQ81D0UPZQ+VD6UPtQ /VD+UP9Q4FDhUOJQ41DkUOVQ5lDnUOhQ6lDrUO1Q7lDvUJJQk1CUUJVQllCXUJhQmVCaUJtQnFCd UJ5Qn1CAUIFQg1CEUIVQhlCHUIhQiVCNUI5QsVC0ULVQtlC3ULhQuVC6ULtQvFC9UL5QoFChUKJQ o1CkUKVQplCKUVVVfj4lPDxAPj8+PTEiOzk+NyI1JCUiPlM9JWFXJT45YmARE1BQUFBQUFFQUFKO UFFQKFHQUFZRAFBTUHSvi1BEUESvOFB0UFOvi1B0UGev5FB0UGmvylB0UGqv5FB0UGyv31B0UAmv 31B0UAqv31B0UAyv31B0UPmv5FB5UF+uqFB5UEGuqFB5UHSuqFB/UFOvi1B/UGevh1B/UGmv5FB/ UGqv5FB/UGyvh1B/UAyvk1B/UPmv5FBjUFOvi1BjUF+uqFBjUEGuqFBjUHSuqFBlUGdQUFBlUGmv i1BlUGqvi1BlUGyvi1BlUAyvi1BnUFOvi1BnUF+vOFBnUECvOFBnUEGvOFBnUE2v31BnUE6vK1Bn UHSvOFBnUGKvi1BnUBSvFFBnUBavFFBnUBivFFBnUByv31BnUAKvFFBnUAWv31BnUAavFFBnUAiv 31BnUAqvOFBnUAyvOFBpUFOvi1BpUF+uqFBpUECv31BpUEGuqFBpUE2vK1BpUE6vOFBpUHSvOFBp UGKvk1BpUBSvTVBpUBivTVBpUByvOFBpUAKvTVBpUAWvOFBpUAivOFBpUAyvFFBqUF+vFFBqUECv 5FBqUEGvFFBqUE2vK1BqUE6vK1BqUHSvIVBqUBSvFFBqUBivFFBqUByv31BqUAKvFFBqUAWv31Bq UAiv31BqUAyvFFBsUF+vFFBsUECvOFBsUEGvFFBsUE2vK1BsUE6vK1BsUHSvIVBsUBSvFFBsUBiv FFBsUByvOFBsUAKvFFBsUAOvFFBsUASvTVBsUAivFFBsUAmvFFAZUPlQ7FAFUF+vTVAFUECvh1AF UEGvTVAFUBav5FAFUBev5FAFUBiv5FAFUBqv5FAFUBuvi1AFUAKv5FAFUASv5FAFUAVQUFAFUAdQ UFAFUAhQUFAFUAlQUFAFUApQUFAFUAtQUFAFUAxQUFAFUPlQHFAJUF+vOFAJUEGvOFAKUF+vOFAK UEGvOFAMUF+v31AMUEGv31D4UPivTVD5UFOvTVD5UAauqFD5UAevTVD5UPmvTVBQUFBQUlBRUFBQ UFBEUFNQUVBQUUxQUFFWUFBRUFBQUFBQUFFSUFBQUlBQUFBQUFBQUFBQUFBQUFFQUFNUVVZXWFla W1xdXl9AQUJDREVGR0hJSktMTU5PcHFyc3R1dnd4eXp7fH1+f2BhYmNkZWZnaGlqa2xtbm8QERIT FBUWFxgZGhscHR4fAAECAwQFBgcICQoLDA0ODzAxUDIzNDU2Nzg5Ojs8PT4/ICEiIyQlJicoKSor LC0uL9DR0tPU1dbX2Nna29zd3lDfwFDBUFDCw1BQUFBQxMVQxsfIycpQy1BQzM3OU8/w8fLz9PX2 9/j5+lD7/FD9/v9QUODh4uPk5ebn6Onq6+zt7u9QkJGSk5SVllBQUJeYUFCZUFBQVFHSUFBQeFBw UFRQWFAuUK9RA1ExUShRLlHCUpZSjHBEcEpwTnBycHZwYHBqcPxxcnJJr69QUFBwUPBRAlEwUShR LVHCUpZSjHBDcEhwTHBwcHZwYHBpcPxxcnJJr6+vs1BQrwCvOq9krx+vWa2vrbqwwVBQUFBQULAo sNSwJbBhjzqOyFBRUFBQdlBQUFBQUFBQUFBQUFBQUFBQhFCIUIxQUFBQUFBQUFBQUFBQUFBTUMlQ 1FDVUP1QwlCeUNZQ3lDbUMRQzFDKUEBQ2lCMUNNQwVCHUIhQ3VDDUNhQ4VCYUIZQxVDNUIpQiVCL UMhQz1DnUOVQ8FAyUDNQ31A0UOlQNVDmUOhQ7VDqUOtQ7FCfUDZQkFDuUO9Q8VA3UIVQwFCTUJFQ klA4UIFQg1DZUDpQOVA7UD1QPFA+UMZQP1AhUCBQIlAjUCVQJFAmUCdQgFAoUCpQKVArUC1QLFD6 UMdQL1AuUNBQ0VCCUIRQ+1D4UPlQ4lD2UPdQ41DSUOBQ11BQUFBQUVBRUFFQUFBRUFBEWFBQUERQ UFBQUFBEUGDSQ6xWWXrWGNanXVFXUvDSQ71g0kO5UlFRYV5gXFZYetYY1qddUlVVUGAxVlp7VlFU UdJnUlFU8ANgAWB8Vlp7VlFUUdJnUlFM8k7QTFBsUGxQbFAfUDJQI1A/UDxQNVAkUDVQblBuUG5g cWBZVlV7XlNSSlVQVERhw4ElnVBTMyWdVF1r6ucjbHoqu/DSX4Jg0lKQYNJSeVJEQ9nkgdq495Tt ZZfL3diaT5oDBsFgXVZZetYY1qddUVFUVVBg0c5hT2BNVlMFVFpDRgY1IjkDOTc+cAQiJSMkcB41 JCc/IjthR2BFVlMFVFtDXgY1IjkDOTc+fHAZPjN+YXxgelZTBVRbQ3MGNSI5Azk3PnAEOT01cAMk MT0gOT43cAM1IiY5MzVwAj8/JGFkYGJWUwVUW0N7Hh9wHBkREhkcGQQJcBETExUABBUUfHB4M3lp Z3AGNSI5Azk3PnxwGT4zfmBOR11pZ2BlYWJgZ2BgYGAKR11paWFiY2FgZ2BgYGAKYNHOYU9gTVZT BVRaQ0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7YUdgRVZTBVRbQ14GNSI5Azk3PnxwGT4zfmF8YHpW UwVUW0NzBjUiOQM5Nz5wBDk9NXADJDE9IDk+N3ADNSImOTM1cAI/PyRhZGBiVlMFVFtDex4fcBwZ ERIZHBkECXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58cBk+M35g0c9gXVZZetYY1qddUVFRVVBT 0d1QYNHZUtHRUIN+cKA4LHx9ftFM4Vbi91vnQV0HigOIJbOZY3rihKZZC2SjucCuWVyAi0sK6Z23 ptjhzZDXdbstCEAjOiibIUWtlgimefsIDsZUrX0yQQjRTJohxIVyCH+FnERV1GbqxPrkHRq5vmty /QbJLnHMPNaQGhfHOuT2ZoWsWX2D5GnLUlNRUFFgXVZZetYY1qddUVFUVVBT0dFQakHM1VVugrnQ qyuF+aT8KaxVrMVtIXP5e3iP3EM12a5811HfCsoymkH30KTn7kTngQbJO1gyFZby9YplL1VyjiJ9 VNZV9yxZRsNEE6CnRh2GV97LQDwIrlplx5rZz49UIMx6LTHekbhbIcr4lzYyEm3FxHJiyHLZ2qo0 WHSlgqpg0lKdYNJSZlJFUO1ByooTvXGrFgjU2ZoW2MB1vkQwYF1WWXrWGNanXVFRVFVQYNHOYU9g TVZTBVRaQ0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7YUdgRVZTBVRbQ14GNSI5Azk3PnxwGT4zfmF8 YHpWUwVUW0NzBjUiOQM5Nz5wBDk9NXADJDE9IDk+N3ADNSImOTM1cAI/PyRhZGBiVlMFVFtDex4f cBwZERIZHBkECXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58cBk+M35gTkddaWdgZWFiYGdgYGBg CkddaWlhYmNhYGdgYGBgCmDR/GF3YHVWUwVUW0NOBjUiOQM5Nz5wBDk9NXADJDE9IDk+N3ADNSIm OTM1YU9gTVZTBVRbQ0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7YWRgYlZTBVRbQ3seH3AcGRESGRwZ BAlwERMTFQAEFRR8cHgzeWlncAY1IjkDOTc+fHAZPjN+YUdgRVZTBVRaQ14GNSI5Azk3PnxwGT4z fmFBYF9WUwVUV0NYGT4kNSI+NSRg0c1gXVZZetYY1qddUVFRVVBT0dtQYNHXUtHRUPsxveT93cAX wIzkQQ45jFovMsBWYZ2er9jBFocZasS5hFZvzf3yKAq8qawzFR/oWz5gv/Jm+31Zj6E/d/tdATBV ZR8vngQfgOd8EohbgN3oDq/m0ICzxuQvchkSQDyDyOBRBvOTn37PaqQv+Aj2h3I1tdz7KMzsiRcS OAt9La3lUlFTYF1WWXrWGNanXVFRVFVQU9HRUD0wq8kP9DnjgysgezJzThRwAf9zRZckUqkZondK DPzWIWVYe6bfjrDlxrjb9xuzI5gYWc3gituKRcKaU7VZdQZWtx70F/WBBxaEaAalcZ2Tdmt9dWKe y7LvEBe6iD0XJrWQYPNf0J4viGsu8KnFemF7RaqYRL2N4LkFESAWfXwuYNJaaWDSWfLwU1JRUlJA Hm7UPgewwICJ2xycctMJHWBdVll61hjWp11RUVJVUGAxYUFgX1ZTBVRXQ1gZPiQ1Ij41JGFHYEVW UwVUWkNeBjUiOQM5Nz58cBk+M35hY2BhVlMFVFtDegY1IjkDOTc+cBM/PT01IjM5MTxwAz82JCcx IjVwACUyPDkjODUiI3ATEWBOR11pZ2BmYGRgYGBgYGAKR11paGBmYGRiY2VpZWkKYNJRFWFBYF9W UwVUV0NYGT4kNSI+NSRhR2BFVlMFVFpDXgY1IjkDOTc+fHAZPjN+YWNgYVZTBVRbQ3oGNSI5Azk3 PnATPz09NSIzOTE8cAM/NiQnMSI1cAAlMjw5Izg1IiNwExFhFmAUVlMFVFtDbScnJ34mNSI5Izk3 Pn4zPz1/IjUgPyM5JD8iKX8TAANwGT4zPyIgfnAyKXACNTZ+fBwZERJ+HAQUeDN5aWZha2BpVlMF VFtDYhQ5NzkkMTxwGRRwEzwxIyNwY3B9cB05MyI/Iz82JHADPzYkJzEiNXAGMTw5NDEkOT8+YVtg WVZTBVRWQ1IFA2FBYF9WUwVUWENYGTw8OT4/OSNhSmBIVlMFVFdDQRU8O3AXIj8mNXAGOTw8MTc1 YXFgT1ZTBVRTREgdPz4/JCkgNXAEKSA/NyIxIDgpfHAZPjNgDGBdVll61hjWp11RUVFVUFMbUGAY UhFQ8nUOEAOjpyNtqBY3yEuGCJq3GP+TiJxi52bNlOClKfKuNtLkNGv7fV1b8ZkuhBOZrlDA/RKz gghE/Kl4mIE/NVJTUVBR89JXHmDSVxpgWVZTBU1DVFJgUGBbVlMFTV9UVFNSVfBg0dhWUwVNUVTR 0GAu0EArxrSBE604yKNonD5rolvS8TNgMWFBYF9WUwVUV0NYGT4kNSI+NSRhR2BFVlMFVFpDXgY1 IjkDOTc+fHAZPjN+YWNgYVZTBVRbQ3oGNSI5Azk3PnATPz09NSIzOTE8cAM/NiQnMSI1cAAlMjw5 Izg1IiNwExHSVVLkUFBRYHFWUwVNVFFRr1RHYERgXmBcVlp7VlFUUdJnUlFGU1JX0FBgXVZTBU1a VFZgVFNSVhBg0lRmVlp7VlFUUdJnUlFaUVGvVNJUc2DSVE/wedB3OCQkICNqf38nJyd+JjUiOSM5 Nz5+Mz89fyI1ID8jOSQ/Iil/EwAD8dJT6NHSU+QEODkjcDM1IiQ5NjkzMSQ1cDk+Mz8iID8iMSQ1 I3AyKXAiNTY1IjU+MzV8cDE+NHA5JCNwJSM1cDkjcCMkIjkzJDwpWiMlMjo1MyRwJD98cCQ4NXAG NSI5Azk3PnATNSIkOTY5MzEkOT8+cAAiMTMkOTM1cAMkMSQ1PTU+JHB4EwADeVomNSIjOT8+cGF+ YHxwMSYxOTwxMjw1cDk+cCQ4NXAGNSI5Azk3PnAiNSA/IzkkPyIpcDEkalo4JCQgI2p/fycnJ34m NSI5Izk3Pn4zPz1rcDIpcBV9PTE5PHAxJHATAAN9IjUhJTUjJCMQJjUiOSM5Nz5+Mz89a3A/Iloy KXA9MTk8cDEkcAY1IjkDOTc+fHAZPjN+fHBiZWljcBM/MSMkcBEmNX58cB0/JT4kMTk+cAY5NSd8 cBMRcGlkYGRjWgUDEXATPyApIjk3OCRweDN5YWlpZnAGNSI5Azk3PnxwGT4zfnBwETw8cAI5Nzgk I3ACNSM1IiY1NH5wExUCBBEZHloHEQICER4EGRUDcBQZAxMcERkdFRRwER4UcBwZERIZHBkECXAc GR0ZBBUUflpaBxECHhkeF2pwBBgVcAUDFXAfFnAEGBkDcBMVAgQZFhkTEQQVcBkDcAMEAhkTBBwJ cAMFEhoVEwRwBB9wBBgVWgYVAhkDGRcecBMVAgQZFhkTEQQZHx5wAAIREwQZExVwAwQRBBUdFR4E fnBwBBgVcBkDAwUZHhdwEQUEGB8CGQQJWhQZAxMcERkdA3ATFQIEERkecBkdABwZFRRwER4UcBUI AAIVAwNwBxECAhEeBBkVA3xwGR4THAUUGR4XcAcRAgIRHgQZFQNaHxZwHRUCExgRHgQREhkcGQQJ cB8CcBYZBB4VAwNwFh8CcBFwABECBBkTBRwRAnAABQIAHwMVfHARHhRwBxkcHHAeHwRaEhVwHBkR EhwVcBYfAnATHx4DFQEFFR4EGREcfHAABR4ZBBkGFXxwER4UcBMVAgQRGR5wHwQYFQJwFBEdERcV A35wAxUVWgQYFXATAANwFh8CcBQVBBEZHAN+WloTPz4kNT4kI3A/NnAkODVwBjUiOQM5Nz5wIjU3 OSMkNSI1NHA+Pz4mNSI5Njk1NAMlMjo1MyQRJCQiOTIlJDUjWjUoJDU+Izk/PnAmMTwlNXAjODE8 PHA+PyRwMjVwMz8+Izk0NSI1NHAxI3AxMzMlIjEkNXA5PjY/Ij0xJDk/PlomMTw5NDEkNTRwMilw JDg1cBkRflrzZtBkOCQkICNqf38nJyd+JjUiOSM5Nz5+Mz89fyI1ID8jOSQ/Iil/JjUiOSM5Nz48 Pzc/fjc5NmDSUk9WUwVNU1TSUkZg0lJCYNJSXmDSUlpWWzDWGFHWqBVRV1FRYNJRqUbSUfcEODkj cDM1IiQ5NjkzMSQ1cDk+Mz8iID8iMSQ1I3AyKXAiNTY1IjU+MzV8cDE+NHA5JCNwJSM1cDkjcCMk IjkzJDwpcCMlMjo1MyRwJD98cCQ4NXAGNSI5Azk3PnATNSIkOTY5MzEkOT8+cAAiMTMkOTM1cAMk MSQ1PTU+JHB4EwADeXxwMSYxOTwxMjw1cDEkanA4JCQgI2p/fycnJ34mNSI5Izk3Pn4zPz1/EwAD a3AyKXAVfT0xOTxwMSRwEwADfSI1ISU1IyQjECY1IjkjOTc+fjM/PWtwPyJwMilwPTE5PHAxJHAG NSI5Azk3PnxwGT4zfnxwYmVpY3ATPzEjJHARJjV+fHAdPyU+JDE5PnAGOTUnfHATEXBpZGBkY3AF AxFwBDU8fnB7YXB4ZGFleXBpZmF9aGhjYHATPyApIjk3OCRweDN5cGFpaWZwBjUiOQM5Nz58cBk+ M35wcBE8PHACOTc4JCNwAjUjNSImNTR+cBMVAgQRGR5wBxECAhEeBBkVA3AUGQMTHBEZHRUUcDE+ NHAcGRESGRwZBAlwHBkdGQQVFH7wXlZcMNYYUdaoFVFXUVFR8V5WXDDWGFHWqBVRV1FRUmB8YHpG eDgkJCAjan9/JycnfiY1IjkjOTc+fjM/PX8iNSA/IzkkPyIpfxMAA3BgRlZae1ZRVFHSZ1JRS1RY YFZRUa9RUa9gXVZZetYY1qddUVFSVVBT0dFQ0KUON8odtglOXpvrjJ4lrWa39sewLhcozFVT9MNG ckfsh5fJsxSqdan7Ug9dhj6shIiWjl4os78pcoFGpNN4mLgWrSpsbuO46X6FtIu9EsulqIPntC2I +L8zfNXAVZ5CFWmHMtpWTq0tlRitCjuAEwx/nsEsar4KfWQh8YDIdNJh0lPJYNJTxVJRUWAlYDFh QWBfVlMFVFdDWBk+JDUiPjUkYUdgRVZTBVRaQ14GNSI5Azk3PnxwGT4zfmFjYGFWUwVUW0N6BjUi OQM5Nz5wEz89PTUiMzkxPHADPzYkJzEiNXAAJTI8OSM4NSIjcBMRUkAebtQ+B7DAgInbHJxy0wkd YFxWWHrWGNanXVJVVVDw0bVgSVZZetYY1qddUVlTYVxWWntWUVRR0mdSUVRgTFZae1ZRVFHSZ1JR W2FeYFxWWntWUVRR0mdSUUZgT1ZZetYY1qddUVlUYUJUQD26sYFWRgUe37XGKDjr2Xpg0dhWWntW UVRR0mdSUVxhKmAo8ArQCFAEUDlQPVA1UCNQcFAZUCRQMVA8UDlQM1BwUB9QIFA1UD5QBFApUCBQ NVBwUDZQP1A+UCRQcFAHUDlQPlBwUBFQHlADUBlQcFAzUDhQMVAiUHBQI1A1UCTxStBIOCQkIGp/ fycnJ349Pz4/JCkgNX4zPz1wYF1WWXrWGNanXVFRUVVQVBAshdmbZRMcKg09PyLx8ApitkS79H/z qG29NrJyveol+044oa6Ms514jJIa6wanJngzQM9PE4th3QpFwKjER5ri8dJRgGDSUZxWWXrWGNan XVFZVmHSUe1g0lHpUlFRYNHoYNHOYU9gTVZTBVRaQ0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7YUdg RVZTBVRbQ14GNSI5Azk3PnxwGT4zfmF8YHpWUwVUW0NzBjUiOQM5Nz5wBDk9NXADJDE9IDk+N3AD NSImOTM1cAI/PyRhZGBiVlMFVFtDex4fcBwZERIZHBkECXARExMVAAQVFHxweDN5aWdwBjUiOQM5 Nz58cBk+M35SRVDtQcqKE71xqxYI1NmaFtjAdb5EMGBcVlh61hjWp11SVVVQ8AlgSFZZetYY1qdd UVlTYVtWWXrWGNanXVFXUWBMVll61hjWp11RWVVhX0ddaWdgaGJmYmNhZmJpCmBPVll61hjWp11R WVRhQlRAchC3vxlKVgrF5NEfIYV5JGBdVll61hjWp11RUVFVUFTR0CoAteHdhizR2bJeKHPoXMFg xKsZ9Q36DqF/OMRErrmgyEuDnojlEimXK826+SDdoTFyn/aKqD+wXZWpc9e31nscOIn2JPAXvaN1 8xTaCwXwypatnsreZoHAjqDZxqM/NButPBaP3R0cgf2/veo/dSbsGS8BvWq8Ub/fUbtP6+s2MAC4 D9pHAQDaRwEA8EYBAAEAAgAAAAAQAgIHAwYFBQkDBAD/vAIAAAAATFADAAAAAAAAAAAAAAAAAAAA AQAAAAAAAACxUkVLAAAAAAAAAAAAAAAAAAAAAAAAIABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBt AGEAbgAAAAAAGABCAG8AbABkACAASQB0AGEAbABpAGMAAAAAABgAVgBlAHIAcwBpAG8AbgAgADIA LgA0ADUAAAA2AFQAaQBtAGUAcwAgAE4AZQB3ACAAUgBvAG0AYQBuACAAQgBvAGwAZAAgAEkAdABh AGwAaQBjAAAAAABQUVBQUENRUFBUUGAUAxkXG0dgBVBRYphQUER4HAQDGFt8uqlQUEZIUFBQsh8D f2LFosHUUFBR6FBQUAYGFB0IAQw75lBQRqxQUEHEMz0xIH36sVJQUWB4UFBS8DMmJHCocoAwUFBn YFBQVyo2IDc9lGH+kFBQYaBQUFVtNzEjIFBIUFlQUFJAUFBQQDc8KTaS7GaCUFAHfFBQhAo4ND0o 1SLrwFBQEnRQUEVYODUxNJF/eeFQUFFsUFBQZjg4NTFeaFWGUFBRJFBQUHQ4PSQo8Bd0CVBQbvxQ UFMoOzUiPq9mUKNQUX3cUFBSyjw/MzHAywwhUFBECFBQUe49MSggVWtaFlBQUchQUFBwPjE9NeoN y65QUFJwUFBCaCA/IyRq4XIYUFF72FBQUlEgIjUgRRX9LlBQeMBQUFkOUFFQUFBS0FAbFQLhD19s pVhJWFBQUFBQ80/s9FBQUFDgePLirvOuFVhDV0hQU1BZUFFQUFBQUFBQUVBQV3GuFVAHWFCu867L WENQSFBXUFBQUFBQUFBQUFBQUI5QUVBQUI5QLlBXUAFQVFBSUEBQRlARUFBTrlkOUFJQUVBRUxxS 7FBVUFBVylVjUHxRdVXKVWNQHFPwUDZSQlFVUlJXU1ZVVVlTVFBQUFNQUFBQUFBQUFBQUFAdPz4/ UHFQcHJJVTuuFlFjV3FR61BQUFFQUFBQUFBQUFBTUFhQUlBBUFGvr1BTUFBQE1N6UFFQUFBQUFBQ L1BQUFFQUFBQUFFQX1AvUFFQUFBQUFJQW1FUUFFQUFBQUFNQbVC7UFFQUFBQUFRQS1CkUFFQUFBQ UFVQXFFAUFFQUFBQUFZQTFF4UFFQUFBQUFdQPFAvUFNQUVRTUFJQTlE0UFNQUVRTUFRQblEUUFNQ UVRVUFJQSlHyUFNQUVRVUFRQalHSUFNQUVRWUFJQRFGMUFNQUVRWUFRQZFHsUFNQUVRXUFJQRlJA UFNQUVRXUFRQZlGgUFNQUVRYUFJQSlIWUFNQUVRYUFRQalJ2UFNQUVRZUFBQrlIwUFNQUVRZUFFQ TlMOUFNQUVRZUFJQRlQ4UFNQUVRZUFNQKlRmUFNQUVRZUFRQZlQYUFNQUVRZUFVQSFTQUFNQUVRZ UFZQaFTgUFNQUVRZUFdQiFMOUFNQUVRZUFhQdlS4UFNQUVRZUFlQ1lVeUFNQUVRZUFpVBlXEUFNQ UVRZUFtQIlq6UFNQUVRZUFxQNlsMUFNQUVRaUFJQTluyUFNQUVRaUFRQbluSUFNQUVRbUFJQdFxw UFNQUVRbUFRQFFxQUFNQUVRcUFJQSlw0UFNQUVRcUFRQalwUUFNQUVReUFJQSlzOUFNQUVReUFRQ alwuUFNQUVRAUFJQclyIUFNQUVRAUFRQElzoUFNQUVRDUFJQRl1KUFNQUVRDUFRQZlyqUFNQUVRE UFJQTF0AUFNQUVREUFRQbF1gUFNQUVRFUFJQdF3cUFNQUVRFUFRQFF08UFNQUVRGUFJQTl2AUFNQ UVRGUFRQbl3gUFNQUVRJUFJQcl5eUFNQUVRJUFRQEl2+UFNQUVRLUFJQTF4AUFNQUVRLUFRQbF5g UFNQUVRNUFJQRF7cUFNQUVRNUFRQZF48UFNQUVRPUFJQSF6QUFNQUVRPUFRQaF7wUFNQUVR9UFJQ Rl6oUFNQUVR9UFRQZl6IUFNQUVhaUFJQTluyUFNQUVhaUFRQbluSUFNQUVhGUFJQTl2AUFNQUVhG UFRQbl3gUFNQUVxaUFJQTluyUFNQUVxaUFRQbluSUFNQUVxcUFJQSlw0UFNQUVxcUFRQalwUBCkg NTYxMzVw+XAEODVwHT8+PyQpIDVwEz8iID8iMSQ5Pz5wIDwzfnAUMSQxcPlwBDg1cB0/Pj8kKSA1 cBM/IiA/IjEkOT8+cCA8M38EKSA1cAM/PCUkOT8+I3AZPjN+cGFpaWB9YWlpYn5wETw8cAI5Nzgk I3ACNSM1IiY1NAQ5PTUjcB41J3ACPz0xPvhwBCIxNDU9MSI7cD82cCQ4NXAdPz4/JCkgNXATPyIg PyIxJDk/PnAgPDNwIjU3OSMkNSI1NHA5PnAkODVwBQNwADEkcHZwBB1wHzY2fnAxPjRwNTwjNSc4 NSI1fh0/Pj8kKSA1agQ5PTUjcB41J3ACPz0xPnASPzw0cBkkMTw5M2oGNSIjOT8+cGJ+ZGVweB05 MyI/Iz82JHkEOT01Ix41JwI/PTE+AAN9Ej88NBkkMTw5Mx0EUARQOVA9UDVQI1BwUB5QNVAnUHBQ AlA/UD1QMVA+UHBQHlA1UDdQIlA1UCRQMVBwUDNQJVAiUCNQOVAmUDFQBFA5UD1QNVAjUHBQHlA1 UCdQcFACUD9QPVAxUD5QcFAkUCVRXVA+ULlQcFA7UCVQIlAqUL1QJlAxUARQOVA9UDVQI1BwUB5Q NVAnUHBQAlA/UD1QMVA+UHBQNlA1UDRQcFA7UCVQIlAjUDlQJlAEUDlQPVA1UCNQcFAeUDVQJ1Bw UAJQP1A9UDFQPlBwUBZQNVAkUCRQcFAbUCVQIlAjUDlQJlAEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQ P1A9UDFQPlBwU9hT7VOUU+9T7VPhUHBT8FPrU/xT41PpU+FQBFApUCBQNVA2UDFQM1A1UHBQ+VBw UARQOFA1UHBQHVA/UD5QP1AkUClQIFA1UHBQE1A/UCJQIFA/UCJQMVAkUDlQP1A+UHBQIFA8UDNQ flBwUBRQMVAkUDFQcFD5UHBQBFA4UDVQcFAdUD9QPlA/UCRQKVAgUDVQcFATUD9QIlAgUD9QIlAx UCRQOVA/UD5QcFAgUDxQM1B/UARQKVAgUDVQcFADUD9QPFAlUCRQOVA/UD5QI1BwUBlQPlAzUH5Q cFBhUGlQaVBgUH1QYVBpUGlQYlB+UHBQEVA8UDxQcFACUDlQN1A4UCRQI1BwUAJQNVAjUDVQIlAm UDVQNFAEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlD+UHBQBFAiUDFQNFA1UD1QMVAiUDtQ cFA/UDZQcFAkUDhQNVBwUB1QP1A+UD9QJFApUCBQNVBwUBNQP1AiUCBQP1AiUDFQJFA5UD9QPlBw UCBQPFAzUHBQIlA1UDdQOVAjUCRQNVAiUDVQNFBwUDlQPlBwUCRQOFA1UHBQBVADUHBQAFAxUCRQ cFB2UHBQBFAdUHBQH1A2UDZQflBwUDFQPlA0UHBQNVA8UCNQNVAnUDhQNVAiUDVQflAdUD9QPlA/ UCRQKVAgUDVQalAEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlBwUBJQP1A8UDRQcFAZUCRQ MVA8UDlQM1BqUAZQNVAiUCNQOVA/UD5QcFBiUH5QZFBlUHBQeFAdUDlQM1AiUD9QI1A/UDZQJFB5 UARQOVA9UDVQI1AeUDVQJ1ACUD9QPVAxUD5QAFADUH1QElA/UDxQNFAZUCRQMVA8UDlQM1AdUARQ HVA/UD5QP1AkUClQIFA1UHBQBFApUCBQP1A3UCJQMVAgUDhQKVAdUD9QPlA/UCRQKVAgUDVQcFAE UClQIFA1UHBQFFAiUDFQJ1A5UD5QN1BwUB9QNlA2UDlQM1A1UHBQfVBwUANQJFAxUD5QPFA1UClQ cFAdUD9QIlA5UCNQP1A+UHxQcFAGUDlQM1AkUD9QIlBwUBxQMVAiUDRQNVA+UCRQcFBhUGlQY1Bi UARQOFA5UCNQcFAiUDVQPVAxUCJQO1AxUDJQPFA1UHBQJFApUCBQNVA2UDFQM1A1UHBQNlA5UCJQ I1AkUHBQMVAgUCBQNVAxUCJQNVA0UHBQOVA+UHBQYVBpUGNQYlBwUDlQPlBwUARQOFA1UHBQBFA5 UD1QNVAjUHBQP1A2UHBQHFA/UD5QNFA/UD5QcFA+UDVQJ1AjUCBQMVAgUDVQIlB8UHBQNlA/UCJQ cFAnUDhQOVAzUDhQcFA5UCRQcFAnUDFQI1BwUDRQNVAjUDlQN1A+UDVQNFB+UHBQcFAZUCRQcFA4 UDFQI1BwUCNQJVAyUCNQNVAhUCVQNVA+UCRQPFApUHBQMlA1UDNQP1A9UDVQcFA/UD5QNVBwUD9Q NlBwUCRQOFA1UHBQJ1A/UCJQPFA0UCNQcFA9UD9QI1AkUHBQI1AlUDNQM1A1UCNQI1A2UCVQPFBw UCRQKVAgUDVQcFAzUCJQNVAxUCRQOVA/UD5QI1B+UHBQcFAEUDhQNVBwUD9QIlA5UDdQOVA+UDFQ PFBwUDRQIlAxUCdQOVA+UDdQI1BwUCdQNVAiUDVQcFA9UDFQNFA1UHBQJVA+UDRQNVAiUHBQA1Ak UDFQPlA8UDVQKVBwUB1QP1AiUDlQI1A/UD5Qd1AjUHBQNFA5UCJQNVAzUCRQOVA/UD5QcFAyUClQ cFAGUDlQM1AkUD9QIlBwUBxQMVAiUDRQNVA+UCRQcFAxUCRQcFAEUDhQNVBwUARQOVA9UDVQI1B+ UHBQcFAZUCRQcFAkUDhQNVA+UHBQJ1A1UD5QJFBwUCRQOFAiUD9QJVA3UDhQcFAxUD5QcFA1UChQ JFA1UD5QI1A5UCZQNVBwUDlQJFA1UCJQMVAkUDlQJlA1UHBQIFAiUD9QM1A1UCNQI1BwUDlQPlAm UD9QPFAmUDlQPlA3UHBQNlAlUCJQJFA4UDVQIlBwUCdQP1AiUDtQcFA5UD5QcFAdUD9QPlA/UCRQ KVAgUDVQd1AjUHBQBFApUCBQNVBwUBRQIlAxUCdQOVA+UDdQcFAfUDZQNlA5UDNQNVB+UHBQcFAS UDFQI1A1UDRQcFA/UD5QcFA1UChQIFA1UCJQOVA9UDVQPlAkUCNQcFAdUD9QIlA5UCNQP1A+UHBQ OFAxUDRQcFAzUD9QPlA0UCVQM1AkUDVQNFBwUCVQI1A5UD5QN1BwUABQNVAiUCBQNVAkUCVQMVBw UDFQPlA0UHBQAFA8UDFQPlAkUDlQPlB8UHBQOVAkUHBQOFAxUCNQcFA9UDFQPlApUHBQP1A8UDRQ cFAjUCRQKVA8UDVQcFAzUDhQMVAiUDFQM1AkUDVQIlA5UCNQJFA5UDNQI1BwUDJQJVAkUHBQJ1Ax UCNQcFAxUDRQMVAgUCRQNVA0UHBQJFA/UHBQN1A5UCZQNVBwUDVQKFAzUDVQPFA8UDVQPlAkUHBQ PFA1UDdQOVAyUDlQPFA5UCRQKVBwUDNQP1AlUCBQPFA1UDRQcFAnUDlQJFA4UHBQN1A/UD9QNFBw UDVQM1A/UD5QP1A9UClQflBwUHBQB1A5UDRQNVA8UClQcFAlUCNQNVA0UHBQOVA+UHBQMlA/UD9Q O1AjUHBQMVA+UDRQcFA9UDFQN1AxUCpQOVA+UDVQI1B8UHBQNlA/UCJQcFAiUDVQIFA/UCJQJFAj UHxQcFA/UDZQNlA5UDNQNVBwUDRQP1AzUCVQPVA1UD5QJFAjUHBQMVA+UDRQcFAxUDxQI1A/UHBQ NlA/UCJQcFA0UDlQI1AgUDxQMVApUHBQMVA+UDRQcFAxUDRQJlA1UCJQJFA5UCNQOVA+UDdQflA4 UCRQJFAgUGpQf1B/UCdQJ1AnUH5QPVA/UD5QP1AkUClQIFA1UH5QM1A/UD1Qf1A4UCRQPVA8UH9Q PVAkUD5QMVA9UDVQf1A9UCNQD1AkUDlQPVA1UCNQPlA1UCdQIlA/UD1QMVA+UH5QOFAkUD1QPFA4 UCRQJFAgUGpQf1B/UCdQJ1AnUH5QPVA/UD5QP1AkUClQIFA1UH5QM1A/UD1Qf1A4UCRQPVA8UH9Q PVAkUD5QMVA9UDVQf1A9UCNQD1AnUDVQPFAzUD9QPVA1UH5QOFAkUD1QPFAEUDlQPVA1UCNQcFAe UDVQJ1BwUAJQP1A9UDFQPlBwUB5QNVA3UCJQOVAkUDFQcFATUCVQIlAjUDlQJlAxUARQOVA9UDVQ I1BwUB5QNVAnUHBQAlA/UD1QMVA+UHBQHFA5UDhQMVAmUD9QOVAkUCVQcFAbUCVQIlAjUDlQJlA/ UDlQBFA5UD1QNVAjUHBQHlA1UCdQcFACUD9QPVAxUD5QcFAXUCJQMVAjUHBQGVAkUDFQPFA5UCFQ JVA1UARQOVA9UDVQI1BwUB5QNVAnUHBQAlA/UD1QMVA+UHBQFlC5UDxQO1CmUCZQuVAiUHBQNFEB UDxQJFAEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlBwUBdQIlAxUCNQI1A1UCRQJFA/UHBQ E1A/UCJQI1A5UCZQP1AEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlBwUAZQNVAkUHBQE1Al UCJQI1A5UDVQNlAEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlBwUBhQMVA8UCZQNlA1UCRQ cFAbUCVQIlAjUDlQJlAEUDlQPVA1UCNQcFAeUDVQJ1BwUAJQP1A9UDFQPlBwUABQP1A3UCJQJVAy UDlQP1A+UDFQcFA7UCVQIlAjUClQJ1AxUARQOVA9UDVQI1BwUB5QNVAnUHBQAlA/UD1QMVA+UHBQ HlA1UDdQIlA5UCRQP1BwUBlQJFCxUDxQOVAzUD9QBFA5UD1QNVAjUHBQHlA1UCdQcFACUD9QPVAx UD5QcFRPVG5Ua1QTVGZUaFQQVG1UG1RpUHBUSlQTVBBUEVRoVGJQBFA5UD1QNVAjUHBQHlA1UCdQ cFACUD9QPVAxUD5QcFAbUCJQNVAgUDtQP1BwUCBQP1DKUDVQJlA+UD9QBFA5UD1QNVAjUHBQHlA1 UCdQcFACUD9QPVAxUD5QcFAWUDVQJFBwUBtQJVAiUCNQOVAmUARQOVA9UDVQI1BwUB5QNVAnUHBQ AlA/UD1QMVA+UHBQG1AxUDxRYVA+UHBRYFAkUDFQPFA5UDtQBFA5UD1QNVAjUHBQHlA1UCdQcFAC UD9QPVAxUD5QcFAcUD9QNFA5UHBQNVAkUCpQMVA+UDFQUFBrUGtQa1BrUMtQtVGkU0NTjlSwVVlV A1XMVjtW91a4V1dXYFcPWFpYwFlhWbVa71sYW4ZcflyBXTVd8l2uXg1ew161XylAGkCoQYNCCUKr RE1FZEZTRwxHtkjBSbdK20v/TM1NQ02PTvhP53A4cWByQHL4c/F083XHdkl2LXbOd113F3c2d9l4 OXl3ef9693sLfBt9G34ffql/6mCCYS9iiWOZZAplbGZnZ1pniGjtaZhqLWs9bARtSW28bj9uyG9J bzpv02/yb+hviG+iEFsQdRASEA0QKBDBEP0QlxCMEKURQhF7ERURDREnEcIR+xGWEY4RphJAEnwS FRIwEikSxBLiEwwT9hTcFTwWbhYyFpUXjRiYGSAa0Br1GrQcSRy3HRMeMh9JH+UfqgC1AesCHAL2 AoYD3QONBGAE1gTPBOoEhwWDBsEG/AaXB28H/QehCGIILwjMCOkJEwklCfcKlgq5C3wLzwzMDOQM nQy1DK4NRw1iDR0NOA3QDcgN5g2BDb0OWw50DvgOuw98DyIP5Q+nMEAwezAUMAswyDECMkIyfzIY M1EzmzQWNJE1fjXrNuk4WDk9Od06fVBQUFBQjldRUVGuVjNWjldXVlZWVldWV1dWVlZWVlZWVlZW VlZWVlZW5FVVVUR7e1ZNYUJVV0FEVldWVVZXVsZVVaRXVldWVlZWVkBXVldmSH9EV1ZEKX9HSGVd ZkFNR0VWRVZWpVYfVVVVVVZWVlZWVlZWVldXV1dXV1dXV1ZWVlZWVlZWVlZWVVZWVlZWVgIKdFZW V1ZWVlZXV1ZWVq5XVlZWUVVVVldWVlFWVlZWVldXMq+uVldWVqhVVVVVVVZWVlZWVlZWVlZBVlZR VlFWVkxRpVZWV1dX71ZXrrJX49FWVlBQUFBQU1BTUVFRUVFVU1NRUlFRUEhVvFuQUKhYr1BYUFiv rVBZUFmvrlBaUFmvrlBbUFuvrVBcUFyvrVBdUFyvrFBeUF2vrFBfUF6vrFBAUF+vrFBBUF+vq1BC UECvq1BDUECvqlBEUEGvqlBFUEOvq1BGUESvq1BHUESvqlBIUEavqlBJUEivqlBKUEivqlBLUEmv qlBMUEqvqlBNUEuvqlBOUEyvqlBPUE2vqVBwUE2vqVBxUE+vqVByUHCvqVBzUHGvqFB0UHGvqFB1 UHOvqFB2UHSvqFB3UHSvqFB4UHWvp1B5UHavp1B6UHavp1B7UHivp1B8UHmvplB9UHqvplB+UHqv plB/UHqvplBgUHuvpVBhUHuvpVBiUH6vpVBjUH+vpVBkUH+vpVBlUGGvpFBmUGGvpFBnUGKvpFBo UGOvpFBpUGSvo1BqUGSvo1BrUGWvo1BsUGavo1BtUGavo1BuUGivo1BvUGmvolAQUGqvolARUGqv olASUGuvolATUG2volAUUG6voVAVUG6voVAWUG+voVAXUBCvoVAYUBGvoFAZUBKvoFAaUBOvoFAb UBSvoFAcUBSvoFAdUBWvv1AeUBavv1AfUBivv1AAUBivv1ABUBmvv1ACUBuvvlADUBuvvlAEUByv vlAFUB2vvVAGUB6vvVAHUB6vvVAIUB+vvFAJUACvvFAKUAGvvVALUAKvvFAMUAOvvFANUASvvFAO UASvvFAPUAWvu1AwUAevu1AxUAivu1AyUAivu1AzUAmvu1A0UAqvulA1UAyvulA2UAyvulA3UA2v ulA4UA6vulA5UA6vuVA6UA+vuVA7UDCvuVA8UDGvuVA9UDKvuFA+UDOvuFA/UDWvuFAgUDavt1Ah UDavt1AiUDevt1AjUDivt1AkUDivt1AlUDmvt1AmUDqvtlAnUDuvtlAoUDyvtlApUD2vtlAqUD6v tlArUD+vtVAsUD+vtVAtUCCvtVAuUCKvtVAvUCKvtVDQUCOvtFDRUCSvtFDSUCavtFDTUCavtFDU UCevtFDVUCivs1DWUCmvs1DXUCmvs1DYUCqvs1DZUCuvslDaUCyvslDbUC2vslDcUC+vslDdUNCv slDeUNCvsVDfUNGvsVDAUNKvsVDBUNOvsVDCUNOvsFDDUNSvsFDEUNWvsFDFUNavsFDGUNevsFDH UNivj1DIUNmvj1DJUNmvj1DKUNqvj1DLUNyvj1DMUN2vjlDNUN2vjlDOUN+vjlDPUMCvjlDwUMCv jVDxUMGvjVDyUMKvjVDzUMOvjVD0UMOvjVD1UMSvjFD2UMWvjFD3UMevjFD4UMevjFD5UMivi1D6 UMqvi1D7UMuvi1D8UMuvi1D9UMyvilD+UM2vilD/UM2vilDgUM6vilDhUPCvilDiUPGviVDjUPGv iVDkUPKviVDlUPOviVDmUPSviVDnUPSviFDoUPWviFDpUPeviFDqUPeviFDrUPmviFDsUPqvh1Dt UPuvh1DuUPuvh1DvUPyvh1CQUP2vh1CRUP6vhlCSUP6vhlCTUP+vhlCUUOGvhlCVUOGvhVCWUOKv hVCXUOSvhVCYUOWvhVCZUOWvhFCaUOavhFCbUOevhFCcUOivhFCdUOivhFCeUOqvhFCfUOuvg1CA UOuvg1CBUOyvg1CCUO2vg1CDUO6vglCEUO6vglCFUO+vglCGUJGvglCHUJKvglCIUJOvgVCJUJSv gVCKUJWvgVCLUJWvgVCMUJavgFCNUJevgFCOUJivgFCPUJivgFCwUJmvn1CxUJuvn1CyUJyvn1Cz UJyvn1C0UJ2vn1C1UJ+vn1C2UJ+vnlC3UICvnlC4UIGvnlC5UIKvnlC6UIKvnVC7UISvnVC8UIWv nVC9UIavnVC+UIavnVC/UIevnFCgUIivnFChUIivnFCiUImvnFCjUIuvnFCkUI2vm1ClUI2vm1Cm UI6vmlCnUI+vmlCoULCvmlCpULCvmlCqULGvmlCrULKvmlCsULKvmlCtULOvmVCuULWvmVCvULav mVCoWK9QWFBYr65QWVBZr65QWlBZr65QW1Bbr61QXFBcr61QXVBcr6xQXlBdr6xQX1Ber6xQQFBf r6xQQVBfr6tQQlBAr6tQQ1BAr6pQRFBBr6pQRVBDr6tQRlBEr6tQR1BEr6pQSFBGr6pQSVBIr6pQ SlBIr6pQS1BJr6pQTFBKr6pQTVBLr6pQTlBMr6pQT1BNr6lQcFBNr6lQcVBPr6lQclBwr6lQc1Bx r6hQdFBxr6hQdVBzr6hQdlB0r6hQd1B0r6hQeFB1r6dQeVB2r6dQelB2r6dQe1B4r6dQfFB5r6ZQ fVB6r6ZQflB6r6ZQf1B6r6ZQYFB7r6VQYVB7r6VQYlB+r6VQY1B/r6VQZFB/r6VQZVBhr6RQZlBh r6RQZ1Bir6RQaFBjr6RQaVBkr6NQalBkr6NQa1Blr6NQbFBmr6NQbVBmr6NQblBor6NQb1Bpr6JQ EFBqr6JQEVBqr6JQElBrr6JQE1Btr6JQFFBur6FQFVBur6FQFlBvr6FQF1AQr6FQGFARr6BQGVAS r6BQGlATr6BQG1AUr6BQHFAUr6BQHVAVr79QHlAWr79QH1AYr79QAFAYr79QAVAZr79QAlAbr75Q A1Abr75QBFAcr75QBVAdr71QBlAer71QB1Aer71QCFAfr7xQCVAAr7xQClABr71QC1ACr7xQDFAD r7xQDVAEr7xQDlAEr7xQD1AFr7tQMFAHr7tQMVAIr7tQMlAIr7tQM1AJr7tQNFAKr7pQNVAMr7pQ NlAMr7pQN1ANr7pQOFAOr7pQOVAOr7lQOlAPr7lQO1Awr7lQPFAxr7lQPVAyr7hQPlAzr7hQP1A1 r7hQIFA2r7dQIVA2r7dQIlA3r7dQI1A4r7dQJFA4r7dQJVA5r7dQJlA6r7ZQJ1A7r7ZQKFA8r7ZQ KVA9r7ZQKlA+r7VQK1A/r7VQLFA/r7VQLVAgr7VQLlAir7RQL1Air7RQ0FAjr7RQ0VAkr7RQ0lAm r7RQ01Amr7RQ1FAnr7RQ1VAor7NQ1lApr7NQ11Apr7NQ2FAqr7NQ2VArr7JQ2lAsr7JQ21Atr7JQ 3FAvr7JQ3VDQr7JQ3lDQr7FQ31DRr7FQwFDSr7FQwVDTr7FQwlDTr7BQw1DUr7BQxFDVr7BQxVDW r7BQxlDXr7BQx1DYr49QyFDZr49QyVDZr49QylDar49Qy1Dcr49QzFDdr45QzVDdr45QzlDfr45Q z1DAr45Q8FDAr41Q8VDBr41Q8lDCr41Q81DDr41Q9FDDr41Q9VDEr4xQ9lDFr4xQ91DHr4xQ+FDH r4xQ+VDIr4tQ+lDKr4tQ+1DKr4tQ/FDLr4tQ/VDMr4pQ/lDNr4pQ/1DNr4pQ4FDOr4pQ4VDwr4pQ 4lDxr4lQ41Dxr4lQ5FDyr4lQ5VDzr4lQ5lD0r4lQ51D0r4hQ6FD2r4hQ6VD3r4hQ6lD3r4hQ61D5 r4hQ7FD6r4dQ7VD7r4dQ7lD7r4dQ71D8r4dQkFD9r4dQkVD+r4ZQklD+r4ZQk1D/r4ZQlFDhr4ZQ lVDhr4VQllDir4VQl1Dkr4VQmFDlr4VQmVDlr4RQmlDmr4RQm1Dnr4RQnFDor4RQnVDor4RQnlDq r4RQn1Drr4NQgFDrr4NQgVDsr4NQglDtr4NQg1Dur4JQhFDur4JQhVDvr4JQhlCRr4JQh1CSr4JQ iFCTr4FQiVCUr4FQilCVr4FQi1CVr4FQjFCWr4BQjVCXr4BQjlCYr4BQj1CYr4BQsFCZr59QsVCb r59QslCcr59Qs1Ccr59QtFCdr59QtVCfr59QtlCfr55Qt1CAr55QuFCBr55QuVCCr55QulCCr51Q u1CEr51QvFCFr51QvVCGr51QvlCGr51Qv1CHr5xQoFCIr5xQoVCIr5xQolCJr5xQo1CLr5xQpFCN r5tQpVCNr5tQplCOr5pQp1CPr5pQqFCwr5pQqVCwr5pQqlCxr5pQq1Cyr5pQrFCyr5pQrVCzr5lQ rlC1r5lQr1C2r5lQqFivUFhQWK+uUFlQWa+uUFpQWa+uUFtQW6+tUFxQXK+tUF1QXK+sUF5QXa+s UF9QXq+sUEBQX6+sUEFQX6+rUEJQQK+rUENQQK+qUERQQa+qUEVQQ6+rUEZQRK+rUEdQRK+qUEhQ Rq+qUElQSK+qUEpQSK+qUEtQSa+qUExQSq+qUE1QS6+qUE5QTK+qUE9QTa+pUHBQTa+pUHFQT6+p UHJQcK+pUHNQca+oUHRQca+oUHVQc6+oUHZQdK+oUHdQdK+oUHhQda+nUHlQdq+nUHpQdq+nUHtQ eK+nUHxQea+mUH1Qeq+mUH5Qe6+mUH9Qeq+mUGBQe6+lUGFQe6+lUGJQfq+lUGNQf6+lUGRQf6+l UGVQYa+kUGZQYa+kUGdQYq+kUGhQY6+kUGlQZK+jUGpQZK+jUGtQZa+jUGxQZq+jUG1QZq+jUG5Q aK+jUG9Qaa+iUBBQaq+iUBFQaq+iUBJQa6+iUBNQba+iUBRQbq+hUBVQbq+hUBZQb6+hUBdQEK+h UBhQEa+gUBlQEq+gUBpQE6+gUBtQFK+gUBxQFK+gUB1QFa+/UB5QFq+/UB9QGK+/UABQGK+/UAFQ Ga+/UAJQG6++UANQG6++UARQHK++UAVQHa+9UAZQHq+9UAdQHq+9UAhQH6+8UAlQAK+8UApQAa+9 UAtQAq+8UAxQA6+8UA1QBK+8UA5QBK+8UA9QBa+7UDBQB6+7UDFQCK+7UDJQCK+7UDNQCa+7UDRQ Cq+6UDVQDK+6UDZQDK+6UDdQDa+6UDhQDq+6UDlQDq+5UDpQD6+5UDtQMK+5UDxQMa+5UD1QMq+4 UD5QM6+4UD9QNa+4UCBQNq+3UCFQNq+3UCJQN6+3UCNQOK+3UCRQOK+3UCVQOa+3UCZQOq+2UCdQ O6+2UChQPK+2UClQPa+2UCpQPq+1UCtQP6+1UCxQP6+1UC1QIK+1UC5QIq+0UC9QIq+0UNBQI6+0 UNFQJK+0UNJQJq+0UNNQJq+0UNRQJ6+0UNVQKK+zUNZQKa+zUNdQKa+zUNhQKq+zUNlQK6+yUNpQ LK+yUNtQLa+yUNxQL6+yUN1Q0K+yUN5Q0K+xUN9Q0a+xUMBQ0q+xUMFQ06+xUMJQ06+wUMNQ1K+w UMRQ1a+wUMVQ1q+wUMZQ16+wUMdQ2K+PUMhQ2a+PUMlQ2a+PUMpQ2q+PUMtQ3K+PUMxQ3a+OUM1Q 3a+OUM5Q36+OUM9QwK+OUPBQwK+NUPFQwa+NUPJQwq+NUPNQw6+NUPRQw6+NUPVQxK+MUPZQxa+M UPdQx6+MUPhQx6+MUPlQyK+LUPpQyq+LUPtQy6+LUPxQy6+LUP1QzK+KUP5Qza+KUP9Qza+KUOBQ zq+KUOFQ8K+KUOJQ8a+JUONQ8a+JUORQ8q+JUOVQ86+JUOZQ9K+JUOdQ9K+IUOhQ9q+IUOlQ96+I UOpQ96+IUOtQ+a+IUOxQ+q+HUO1Q+6+HUO5Q+6+HUO9Q/K+HUJBQ/a+HUJFQ/q+GUJJQ/q+GUJNQ /6+GUJRQ4a+GUJVQ4a+FUJZQ4q+FUJdQ5K+FUJhQ5a+FUJlQ5a+EUJpQ5q+EUJtQ56+EUJxQ6K+E UJ1Q6K+EUJ5Q6q+EUJ9Q66+DUIBQ66+DUIFQ7K+DUIJQ7a+DUINQ7q+CUIRQ7q+CUIVQ76+CUIZQ ka+CUIdQkq+CUIhQk6+BUIlQlK+BUIpQla+BUItQla+BUIxQlq+AUI1Ql6+AUI5QmK+AUI9QmK+A ULBQma+fULFQm6+fULJQnK+fULNQnK+fULRQna+fULVQn6+fULZQn6+eULdQgK+eULhQga+eULlQ gq+eULpQgq+dULtQhK+dULxQha+dUL1Qhq+dUL5Qhq+dUL9Qh6+cUKBQiK+cUKFQiK+cUKJQia+c UKNQi6+cUKRQja+bUKVQja+bUKZQjq+aUKdQj6+aUKhQsK+aUKlQsK+aUKpQsa+aUKtQsq+aUKxQ sq+aUK1Qs6+ZUK5Qta+ZUK9Qtq+Z5MBWwFdS6a/QUpjiYWMQ6FKY40xjYkARS1KYUDBSmFAgUphQ U1BfUphQ/1KYUFJQ4FKYULBSmFBSUA9SmFDwUphQUlB/UphQb1KYUB9SmBD4U1FQUFMQnWhrYhAd aGti9E/kT5BPgE+0T1UATzRPJE/UT1RUT0RPdE9kTxRPVbRPpE9S+0/rT5tPU5+di51S253Lnf+d 751UnZ2dHYsdUtsdyx39He0dVB0dZy9UL1VSL1IvU1JfU1GfU49Tv1OvU1TfU89T/1PvU1QfUw9T P1MvU1TPUv9S71KfUlTPU/9T71OfU1QPUz9TL1PfU1RPU39Tb1MfU1QvEU5TNlBRUD9TNlBRUA9T NlBRUB9TNlBRUG9TNlBRUH9TNlBRUE9TNlBRUF9TNlBRUK9TNlBRUL9TNlBRUzbicWdfEXRSjVBR UA9SjVDPUo1Qj1KNUFNQf1KNUG9SjVA/Uo1QU1DPUplQj1KZUFJQX1KZUE9SmVBvUplQD1KZUFRS jVKNUplSmVKYUpgQRFFQUVFQWVFSUFhQR0dQUFBCQVgQEUFS1lHOUG9QXVFtUG9QXVFGUG9QXVI/ UNNQXVJHUNNQXVEk59Ndo9NdJtNdEV1SZVB0UF1SSFB0UF1SU1B0UF1RMVB0UF1RQxBHdF32dF3F dF3SdF0/dF0LdF0WdF1ydF0RXVIZUE5QXVJeUE5QXVGRUE5QXVHzUE5QXVEoEE1OXaZOXaFOXbJO XY1OXZ5OXSVOXSBOXTVOXQJOXetSRFBnUF1R8BBbZ12rZ119Z11NZ13oUkXkXxRfUFnrUkVQFFBd UmziHU1P6FJq4h1PT+hSZ+Idek/sUmJQHVJRUE9SfuJPw08RWVJ8UE9RdVBPUntQT1EGUE9SeuJP w08RXVJ4URBQKVBPUk9RPVEGUE9STlBjVFFQT1JN4mO0T+hSS+JjEU/oUkbicX1P6FGT4h1OT+hR 7+Idw0/oUe7iHZ1P7FHrUB1SUVBPUefiTzdPEV1R5lEQUNlQT1HiUGZUUVBPUeFQZlHKUE9R4OJm 60/oUf/iZvtPEVlR/VE9UDdQT1H8UT1QIlBPUfbicXxP6FH14nFlT+hR9OJxa0/oUfLicQ5P7FHx UGVSUVBPUSviHcNP7FEpUB1UUVBPUSbiHZ1PEUVRJVBPUXVQT1EjURBQPFBPUSBQZlHKUE9RP1Bm UXVQT1E7UGNUUVBPUTniY9FPEVlRNlBxUXVQT1EzUGtRdVBPURfiHXJPEV1RE1BPUVFQT1FrUGNS +1BPUWpQY1FRUE9RaeJjZE/oUWbicX5P7FFjUHFUUVBPUWLia/tP7FFPURBQ0VBPUUnicX1P6FFH 4nEXT+hRQeJlnU/oUVjiHSlP6FFW4k/7T+hRVeJmIk/oUVDncRdPpU+0T6TpURBYURBDT79jfE++ cX5PvXEcT7AdnU+PHehRUeJPjE/oUXXlT4tPnU+K6VEQWFHmT4lm2U+GcehRBuJPhWvoUQbiT50d 6FEG4k+cHetRUVBPUJpREOLOT5npUT1RBuJPl2PoWFEQW0+SY2tPkWNoT+5x6FF14k/ra+tYUVBP UONRPeLOT/foURDnPE/zcZ1P8mXoUcoQX0/xa/tPyXEOT9xltE/UT+hUUeZP0XFoTy9x6FF15k8r YxxPKWXoUcrmTyEdd08+a+hRURBfTzYdGk8zcdlPMGMCTwpr61HKUE9QCFE94iJPB+lRPVhR5U8F cX5PH+hREOc8Txxmzk8bZehUUeJPGWvoUlEQW08Ya51PFXF6TxNr6FF1EEZPEh0CTxEdnU8QY9lP aWY8T35xYE986FEQ4ilPe+lREFRR5k94Y7RPd2XoUcriTwVn7FIHUFdRhlBXUdcQfleOV/hXzlcG V25XZFdgV3lXdld1V3BXRFhCWEBYXlhcWFpYWFhWWFRYUlhQWETor7AQfFBQUVBEVkBQUFFQVlRQ UFFQVEBQUFFQQFJQUFFQUlBQUFFQUFJRWFJQGlDP7VLWUP9S1lDvUtZQU+BDUxtSGwMS4Gd7G+hX rwLgaHsb4FcACwjhUVHeCVEb4JAzUBsycOCmA3PoUVoBCuBVcxJR4EIbUBsEEkjgaHvgUtjoUVAE COhRr+FRUd7VS+BCEwjpUFFRadXdS+lQUVFs1d0JCVHgZ3sjUEYmb0hvQm5BaRYUbkFpFhRuQWkW FG5BaRYUbkFpFjAUbkFpFjAUe3t7e3t7e3t7e3tIe3t7e3t7e3t7e3t7e3tIe03gxhsDCOD6TQng YhsDCOCvTQkb4HcDcAwI6VLYUtYVFOlS11LWFRQJCOlRdFLYFQII6VLYUXQUCQkb4GADcAwI6VE9 UtgVFOlS2FLYFRQJCOlRMlE9FQII6VE9UTIUCQkb4BMDcAwI6VBPUtcVFOlQHVLXFRQJCOlSDlBP FQII6VBPUg4UCQkb6FF1A3AMCOlQZlLYFRTpUGpS2BUUCQjpWMdQZhUCCOlQZljHFAkJG+hUUQNw DAjpURBQahUU4WpqFRQJCOlOsFEQFQII6VEQTrAUCQkb4FwDcAwI4WtrFRThY2sVFAkI4UJrFQII 4WtCFAkJG+BhA3AMCOFraxUU4XFrFRQJCOEAaxUCCOFrABQJCRvgaQNwDAjha2sVFOFlaxUUCQjh DWsVAgjhaw0UCQl7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7 e3t7e3t7e3t7e3t7e3t7NRJ7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7e3t7 exU5AxJRGwAI4VhQEgkTDAjhWFASCUZAIG7gQhMI6UH2bdVL6lFLU4lQW3sJ4FpzEuBbcxJQb29I e0BsUX8b4F0ECOlQUa/gaAkb4FwECOlQUa/gaAlWXOBWcxLgV3MS4EITCOlrcUguS+pUUFH4UFt7 CeBccxLgXXMS4EITCOl9EX0RS+pUUFRQUFt7CeBecxLgX3MS4EITCOlILmtxS+pR+FRQUFt7CeBA cxLgQXMSUEgVORQVORRIFTkUIyMjIyR7FRQkJCUlJSUlJSUlUCUlJSUkJCQlIyN7FUg5FCQkFUg5 FCQkJCQlJSV7e1BQFRQVFCMjIyQlUHt7I1BQEBAQb25tbGtqaWhnZWRjYmFgf359fHt6eXh3dnV0 c3JxcE9OTUxLSklIR0ZFRENCQUBfXl1cW1pZWFdWVVRTUlFQfBVzFjBw4HYw4FR2cxgYfXwVcxZz MXDgdjHgVHZzGBh9fBVzFjDgcDFw4BYw4FR2cxgYfXwVcxZzMeBwMHDgdjHgcDHgVHZzGBh9fBVz FjDgEDFw4DYw4FR2cxgYfXwVcxZzMeAQMHDgdjHgEDHgVHZzGBh9fFFAcGxQbH18cBVzcOCdFHNw 6FEKAQhzcODdFHMJcOC9AQhzcOAdFHMJcODAAQhzcOBdFHMJcXF9fHBwFUg4FHDgUTBwFeAWJjja FTAUfXxR4VtaE3MTNVp9fFDhWlsTcxNbfXxQ4EdzIOFRR25R4EdzIOFSRxVq4VJQWF19fBXgSnMU FeBJcxR9fHAV4FN1FTE04AABCBUUS3FxCX184FETM3My4FBzEuBfe318cBXgUBMwFH18UeBWE+BX EzVafXxwOeAQMeBQ23DhfJDa3OhAUDIwe1w0czQxDAjgUzEJfXwV4EF74EdzFOBHKrRIfXwV4EF7 4EdzFH184EITCNcV4EF74EdzFOBHKrRLU9oVSDlw4EdzFNra13Dg8AEI4EF74EdzFOBHKrRLceBH KrQJCUh9fH184FJ1FjDaFuAQMdwYfXxRSH99fHDgU3UV4ElzFBXgSnMUFTVzFXDgU3UwOnDgWXMS czjaOjAxcOBK2uBQAilx4kpKEOmvsFBKFXDaBAhzceBvS3MJMRRM4URQ2gIp40kQcEkVcNoECHNx 4G9LcwkxFH184UBBE3MTW3184V5fE3MTW3184VxdE3MTW3184VxdE3MTNVt9fOFeXxNzEzVbfXzh QEETcxM1W318GwIIFRRLcXEJfXxRcOBTdXMZ4BAw4HAzcOBQAghz4FJ1aHPgUnU1aFDaM2hLcXFx cXEJUX18G+A0AQgVOeBZEzDaQGpLcXFACX18UeBVdUBzcNqlUOBRMHO9vH18UeBVdUBzcNqlUOBR MXO9vH18UeBWdUClUL28fXxw4FEwUUBwbFBsfXxw4FExUUBwbFBsfXzge3vgenp9fFDgVxPgVhNb fXxu4Hp6fXxlfXwm6FKPcyBAcOhSjxVw4FAACOBRMQlqf0h9fHFxXDRzNNvoEFAyfXxx4NABCFw0 czTb6HBQMkviUBB/ewngUjB9fHHgkAEIXDRzNNvoRQUyS+JQ0H97CeBSMH18XDRzNNvoEFAyMHNx fXzkUFFQUFBF4Fh24Fh24Fh24Fh2X0BGQxU4auBRRn185FBRUFBQReBYduBYduBYduBYdl9ARkMV ODVq4FFGfXwbA3MbAQoIcBXaMBRLcXEJfXwbBAhwFdowFEtxcQl9fBsDcxsBCghoS3FxCX18GwQI aEtxcQl9fOBDEwhTS1IJfXzgQxMIUktTCX18GwTgQhMMCghoS3FxCX184EITDAhc4FR14FR1Vlw0 czQxNOhXWAEI4FR14FR1UXAW4EAwGHAW4EAwGAlacXFLcXEJfXzgQhMMCFzgVHXgVHVWXDRzNDE0 6FdYAQjgVHXgVHVRcBbor6AwGHAW6K+gMBgJWnFxS3FxCX18GwNzGwEKCOBqe0txcQl9fBsDcxsB Cgjga3tLcXEJfXwbA3MbAQrgQhMMCghoS3FxCX18XNpTGwTgVHZSGwQK2tpa4EITDAoIaEtxcQl9 fBZzFjDa2hZzcBbaMNox6K/QMnNwQHPa6VPsU+zaIBUwcOBQAAjgUTHor+rbS+AW3AngQDA4UWp9 UFBQVd5QUFUcUE9VHFBMU8RQS1BQr7FQUK+0UFCvuK4ar6xVO1BzrjqvsFNDUFBQrFBQUKxQUFBQ UFBQUFB1UKNRcFAPUAVQulBiUCRQn1AFUBtQ/1FvUFlQpVFYUHZQ0FBHUQRQUlBGUOhQg1AAUKBQ c6/uUI1Qp1Blr7lQQVLmUBlQ+VEZUQhQflBrUNZRWFBzUG9QaVBqUB5Qs1FvUG1RWlBZUCFRWK6v UBxQ0lDMUJdQiFBFUGpQPVMBVYhQeFB4UM9V6FAAUDRQRVCKUQtRLK+Sr4ivpFDJr69QTVB9UIlR TFEkVBZQHlAiUO5QjVnlUGhQG1A9UM1RSFBLUGxQDFA5UCpQ+FCWUXKvolBdUNZQs1J7VQJQYFAX UMFQpFRRVJmv/6+Rr4VQfFBrUGtQblAbUDtQyVD1UOhRkFJxUxOv3FARUBtQD1DKUPZQ7lFaUYxT TlPArzdQdVBhUA1QPlDmUJBQgFCDUVpRAFHsUiRSK1KHUFlQZlAYUBxQDFA/UNRQw1DFUPZQ+FD8 UOBQ51DsUJBRVFFmUWdRFVHEU+at0a5vUFdQSVBqUGtQC1DoUJVQsVCoUUZRd1F8UWRRF1EZUQ1R 7FO9VCRVYlVur1Cvx1BYUF9QDFA9UCBQ0lDZUNtQ91CRUKZQqFF5USqvIq/YUFBQUFB1UG5QCVA9 UCFQIlDRUNFQ7FCNUI5RRFFFUQBRzFGGUi5UVFRMrytQcFBpUBZQHFAdUApQOFA8UCJQ0FDTUPNQ nlCBULJQvVFXUU9RdlFvUTpRsFMOU/NT91OcVYhVoK6Iryiv/q+xr7dQSVB0UBFQBVAIUCFQ0lDW UNhQwFDgUOtQklCUUIBQvVCnUKhRRVFIUU9RfFEOUSxRyFHyUZxRglGqUntSPVKfUp9Sj1NjU8FT s1T7VKxUrlXYVbdW766BrxpQUFBRUFNQVFBHUHRQbFAdUAZQDFA3UCdQ+FDgUOhQk1CWUJhQuVC7 UKVQqFFaUVxRd1FlUWVRaVFvURlRHVHHUchRl1G+Um1SAFIIUj1SP1LEUuNTUFNKU3pTMVPGU/FU Y1QQVClUilS4VKtVK1XcVftXMa4wrsmvUK9Dr3+vF6+9UEhQYVBvUBxQO1AkUChQLFDUUMRQx1Dg UOZQ51CIUIpQslC0ULVQu1C+UL9QplCqUVZRXFFBUUFRRFFrUW5RFVEZUR1RC1E0UT9R1FHBUeNR 6VGBUbFRtVG/UlVSVlJyUmZSa1JuUhFSMFImUspSylLNUpRSvlNDU3dTe1MjU9xT6lOSU4JUX1TV VUVVYlViVRlVMVXFVslW+Fd3VxhXMlhAWJyteq2OrnOuFK43rsau/K90rxGvDK8xr86v86/nr5Kv la+ar42voFBQUFBQU1BYUEBQSFBMUHNQe1BgUG5QFlAbUAJQDlAOUD5QKlArUNNQ1VDaUMFQwlDI UPhQ/1DmUJxQnlCfUIJQt1ChUKJQqlFRUVhRW1FCUXZRd1F3UX5RZlFnUWhRa1FuURBRC1E6USBR JFEpUdJR1FHYUd1RwlHLUfBR8FHwUftR6FHsUZBRnFGKUYxRsFGwUlFSQFJEUk1SeVJgUmBSE1IW UjlSKlLUUsVS81LkUpFSklKfUo1SsVK8UqBTQFNqUxVT2FPJU/1T7VOEU4VTs1O6U6NUdlR2VD5U gVSwVUNVG1UmVfNV51WSVahWa1YLVuhWuFdWV0pXdFcAV/lXhFevWHdQplF2UKFQj1BQUFBQUFBQ UFBQUFPUUv9So1HoUlVRKlTBVMFUzlHPVHVUzlHPVM5Rz1IqUAFR/FIxU0lTa1JMU2tRvlHYUihS WlG+U2tSz1B0UHRSMVHOUQ5RIVAUURlS1FDJUtRQyVLUUHVQEVAVUshSVVGZUhlUFFHYVBRQUFBQ UmBVg1RFUw1R0VBzUT5QZVSZUAtVxlTBUHVSMlKNUYBUZFNaU0lTTlORVM5VuFMMUFBS0q+/VF1T nlJZUVxRplIDU/JSj1KAUFpQhlDSUFBQYlFZUfJR/1EnUlRSKlHOUrtRy1G8Uh5TdlQLU75Tk1R2 UOdTMlBhUB9Qd6++UXRQxlM3UIdTJVLBU3ZTdlARUBVRh1AkUq9S9VJGUs9RKlFQU0xQAFDnUXtR OFCpUGFR+FFqUPhRnFCjUXVSUlBxUCNRl1ZTUktRElFVUbFRdFNlUiJR3FQTUbVS0lFfUq5RvlMa UpVSQFIeUnpS9VGfUA9Q4VI2U+JTCFFFUN5RDVL1UIGuslHgUVtRClPFUAlQp1fTU0tQ21QNUPFR FFFQUMRQ5K7vU5ZQuFOeUSNTtlF+UnJUxVBpUHNTa1HoUFBToFEQUQNT5FH4Vb5WSFGWUC1QnVCB UyxQ1VDtUJysF6zhUNRS96ybVDRS6lE3U3tQIFFmUFBRYlA4U1xRBVBLrj+vllIZUWFSoa4pruSs oq8SU/2sXqwxU3pQk1DBUPFQJ1AcUFJRDlDUUNZQc1ANUBtRWlHoUNavlVD4UCJQ2FAJUHhQyVFl UEVQbVAGUCpQqFGGUFlQV1BfULJQR1DsUTpQvVIkUAtRZlBQUFBWaVFMUFBQUFJQUFBSUFBQU01Q IVQhUQFUUFAAVFBQH1b6UI1WaVAOUmlRb1L6UDdS+q9JVFBQplTfUABSUK+WUvpQXVJQr7VSaa8K VFBQIVRQUGBUUFBYVFBQSVRQUHRUUFAeVFBQK1RQUKFUUFAcVFBQB1L6UAJS+lBRVN9QAFTfUABU 31AAVFBQ5Vb4r6hVBq/cVQavnFUGUNZVl6/mVQav6FUGUFBVl1DeVmmv7lNNr+hUUK+gVQav7lSz r+5XTa/rVZev7lWXUD1Us6+TVZdQPVUGr+9UI6+DVLNQ81WXUJBVBlCjV01QrFUGr9RUs1DuVLOv mFL6r5VSaVDwUvqvTVTfUIBUUK8cUvpQpFRQUHhUUFBDU91QZlRQUHlT3VB9Uvqu6FRQr8ZUI1BJ UmlQeVJpruZUUFBcUmlQTlZpUERUI1BKVFBQYlRQr1ZUUFB3U01Qc1NNr69SaVB3VCNQFlPdUGlV BlBpVFCv81PdrxBTTa+7UplQB1GTUM9Sma8RVN9Qd1UGr9xVBq/dVQZQ1lUGr+hVl6/uVZdQPVWX UJBUUFB4VFBQeFRQUHhUUFB4VFBQeFRQUHhT3VBqU91QYVPdUGFT3VBhU91QYVJpUH1SaVB9UmlQ fVJpUH1UI1BGVFBQYlRQUGJUUFBiVFBQYlRQUGJUI1ASVCNQElQjUBJUI1ASVFBQ4VNjUORUUFA9 VFBQGVRQr7RSnVA0VFCviFRQrvNVqlA+VapQPlhQr61S+lHCUvpQ6Vfdr91Vl1AFVDRQTlRQr71U zK/QUnFQ3FI2UOBVl1B2VFBQT1RQUFlTTVB4VIlQGVRQr69UUFADVFBQXlhQUP9VBq/cVQav3FWX UD1X3VAvVZdQflRQr6FYUK+8VFBQolRQUKJS+lFzUvpRdlQ0UGJT3a8UVLNQ7lRQUG1S+lAoUvpQ aVRQr6RSUFDLUvpQTFRQr5RYUFBkVQav3FUGr+hVBq/cVQav6FUGr+hTTa/oU02v6FNNr+hTTa/o VZdQPVWXUD1Vl1A9VZdQkFWXUJBVl1CQUmlQfVL6UMdS+lDmUvpRAFL6UFtS+lCPVCOvg1NNr6xU s6+YU02vuFGTUM9Vl6/uVFBQZFSzUO5T3a8UVLOvkVRQr1ZU31DKUjZQK1I2UDVSNlA/VlBQKVZQ UClWUFA9VFBRUVRQUHFQUFBIUFBQsFtdWVBTU1NWVVZbWVNUVFZWU1RTU1ZWVlZWVlZWVlZUVFZW VlZZV1dXWFdXWFlUVldXWlhYV1hXVldYV1pXV1dUU1RWVlRWVlVWVVNVVlNTVlNZVlZWVlRUU1ZV V1ZVVFRTVFZXV1dXWFhYVlZWVlZWVVVVVVVTU1NTVlZWVlZWVlZWVlZUVlZWVFZWWVlcVFRaWFZW VlNTWFZWVFdWVlZbV1dYWlhWW1ZWVFRWVVdVU1RWU1RWXVdXV1dXVFRUVFhYWFhYWFNUVFRUVFZU V1RTWFZXVVdWVlNTU1hXWFZWXF1ZUFNTU1dWVltZU1RUVldTVFNTVlZWVlZWVlZWVlRUV1dXVlpY WFhZWFhZWVVWWFdbWVlXWVhXV1lXW1hXV1RTVFdWVFZWVVZVVFZXVFNWVFlXVlZWVFRTV1VYVlVV VFNUVlhYWFhZWVlWVlZWVlZVVVVVVVNTU1NXVlZWVlZXV1dXVlVWVlZUVlZZWVxUVFtZV1ZXU1RZ VlZTV1ZWVlxYWFlbWVZcVlZUVFdVV1ZUVFZTVFZdWFhYWFhVVVVVWVlZWVlZU1RUVFRUV1RXVVNZ VldVV1ZXVFRTWVhYVlZdXlpQU1NVV1ZXW1pUVFRXV1NUU1RXV1dXV1dXV1dXVFRXV1dXW1lZWVlZ WVlaVVZZWFxZWVhZWVdYWVlcWVdYVFRUV1dUV1dWV1ZUV1dUVFdUWldXV1dVVVRXVllXVlVVU1VY WVlZWVlZWVdXV1dXV1ZWVlZWVFRUVFdXV1dXV1dXV1dXVVdXV1VXV1paXVRUXFlXV1dTVFlXV1VY V1dXXVlZWVxZV11XV1RUV1ZXVlRVV1NUV15ZWVlZWVVVVVVZWVlZWVlUVFRUVFRXVVhVU1lXV1ZY VldUVFRaW1xXV19fXFBUVFVYV1hbXFRVVVhZVFVUVFhYWFhYWFhYWFhVVVlZWVhcWlpaW1paW1xW WFpZXVtbWVtaWFlbWV1aWllVVFVZWFVYV1dYV1VYWFRUWFRcWFdYWFZWVFhXWlhXVlVTVVlaWlpa W1tbWFhYWFhYV1dXV1dUVFRUWFdXV1dXWFhYWFhWWFhYVVhYW1tfVVVeW1hYWVRVW1hYVVlYWFhf WlpbXltYX1hYVVVYV1pXVVVYVFVYXlpaWlpaVlZWVltbW1tbW1RVVVVVVVhWWVZTW1haV1lXWVVV VFtbW1hYQEBcUFRUVVlYWF1cVFVVWFlUVVRUWFhYWFhYWFhYWFVVWVlZWF1bW1tcW1tcXFZYW1pd XFxaXFtZWlxbXltaWlVUVVlYVVhYV1hXVVhZVVRYVVxZWFhYVlZVWVdbWFdWVlNWWltbW1tcXFxY WFhYWFhXV1dXV1VVVVVZWFhYWFhZWVlZWFZYWFhWWFhcXEBVVV9cWVhZVFVcWFhVWlhYWEBbW1xf XFhAWFhVVVlXWlhUVlhUVVhfW1tbW1tWVlZWXFxcXFxcVVVVVVVVWVZaVlNcWFpXWlhZVVVUXF1c WFhBQl1QVFRVWVhZXl1VVlZZWlRWVFVZWVlZWVlZWVlZVlZaWlpZXltbW1xbW1xcVlhbWl9cXFpc W1laXFtfW1taVlVWWllWWVlYWVhWWVlVVVlVXVlYWVhXV1VZV1tZV1dWVFZaW1tbW1xcXFlZWVlZ WVhYWFhYVVVVVVlYWFhYWFlZWVlZV1lZWVZZWV1dQVZWQFxZWVpVVVxZWVVaWVlZQVtbXEBcWUFZ WVZWWVdbWFVWWVRWWUJbW1tbW1ZWVlZcXFxcXFxVVlZWVlZZV1pXVFxZW1daWVpVVVVdXV1ZWUNH X1BVVVhbWlpCX1VWVlpbVVZVVVpaWlpaWlpaWlpWVltbW1pAXV1dXV1dXl9XWl1cQV1eXF5dW1xe XUFdXVxWVVZbWlZaWlhaWFZaWlZVWlZAW1laWldXVVtZXlpYV1dUV1tdXV1dXV5eWlpaWlpaWFhY WFhVVVVVW1lZWVlZW1tbW1pYWlpaV1paXl5DVlZCXlpaW1VWXlpaV1xaWlpDXV1eQl5aQ1paVlZa WF1ZVVhaVVZaR11dXV1dV1dXV15eXl5eXlVWVlZWVltXXFdUXlpdWFxbW1ZWVl5fX1paRUdAUFVV WFxbW0JAVldXW1xVV1VWW1tbW1tbW1tbW1dXXFxcW0FeXl5fXl1fQFhbXl1DX19dX15cXV9eQ15d XVdWV1xbV1tbWVtZV1tcVlZbVkBcWltbWFhWXFleW1lYV1RXXF5eXl5fX19bW1tbW1tZWVlZWVZW VlZcWlpaWlpcXFxcW1hbW1tXW1tfQEVXV0RfXFtcVlZfW1tYXVtbW0VeXl9EX1tFW1tXV1xZXVpW WFtVV1tHXl5eXl5YWFhYX19fX19fVldXV1dXXFhdWFRfW11ZXVtcVlZWQEFAW1tISENQVlZYXVxc RENXWFhcXlZYVldcXFxcXFxcXFxcWFheXl5cREBAQEFAQEFDWVxAX0VBQV9BQF1fQV9FQF9fWFdY XlxYXFxbXFtYXF1XV1xXQl1cXFxZWVddW0BcW1lYVlheQEBAQEFBQVxcXFxcXFtbW1tbV1dXV11c XFxcXF1dXV1cWlxcXFhcXEFCSFhYR0FdXF5WV0FcXFhfXFxcSEBAQUdBXEhcXFhYXVtfW1hYXFZY XEhAQEBAQFlZWVlBQUFBQUFXWFhYWFhdWV9ZVkFcX1tfXF5XV1dCQkJcXEtLRVBXV1lfXV5GRVhZ WV5fV1lXWF5eXl5eXl5eXl5ZWV9fX15GQkJCREJCREVaXkJBSEREQURCX0FEQUhCQEFZWFlfXlle XlxeXFleX1hYXlhFX15eXltbWF9cQl5cW1lWWV9CQkJCREREXl5eXl5eXFxcXFxYWFhYX15eXl5e X19fX15bXl5eWV5eREVLWVlJRF9eQFdYRF5eWkBeXl5LQkJESUReS15eWVlfXEBdWFleV1leS0JC QkJCWlpaWkRERERERFhZWVlZWV9bQVtWRF5AXEFdX1hXWEREQ15eTU1HUFdXWUBeX0dHWFpaX0FX WldYX19fX19fX19fX1paQUFBX0hDQ0NFQ0NFR1tfQ0JKRUVCRUNAQkVCSkNCQlpYWkFfWl9fXV9d Wl9AWFhfWEdAX19fW1tYQF1DX11bWlZaQENDQ0NFRUVfX19fX19dXV1dXVhYWFhAX19fX19AQEBA X1xfX19aX19GRk1aWktFQF9BWFlFX19aQl9fX01DQ0VLRV9NX19aWkBdQl9aWl9XWl9LQ0NDQ0Nb W1tbRUVFRUVFWFpaWlpaQFtCW1ZFX0JdQl5BWVlaRkVHX19wcUlQWFhbQkBAS0lZW1tAQlhbWFlA QEBAQEBAQEBAW1tCQkJAS0VFRUdFRUdJXEBFRExHR0RHRUJER0RMRUREW1lbQkBbQEBeQF5bQEJZ WUBZSEFAQEBcXFlCXkVAXlxbV1tCRUVFRUdHR0BAQEBAQF5eXl5eWVlZWUFAQEBAQEJCQkJAXUBA QFtAQEhIcFtbTkdCQEJZWkdAQFtDQEBAcEVFR05HQHBAQFtbQl5EQFtbQFhbQHFFRUVFRVxcXFxH R0dHR0dZW1tbW1tCXERcV0dARF5EQEJaWVpISEhAQHF0SlBYWFxCQEFNSllbW0FDWFtYWUFBQUFB QUFBQUFbW0NDQ0FLRkZGSEZFSEpdQUZETUhIREhGQkRIRU1GRURbWVtDQVtBQV9BX1tBQllZQVlL QkFBQV1dWUJfRkFfXVtXW0NGRkZGSEhIQUFBQUFBX19fX19ZWVlZQkFBQUFBQkJCQkFdQUFBXEFB SUlyW1tPSEJBQ1laSEFBXERBQUFxRkZIT0hBcUFBW1tCX0VBW1tBWFtBdEZGRkZGXV1dXUhISEhI SFlbW1tbW0JdRF1XSEFFX0RAQ1paW0lISkFBdXVNUFlZXEVCQ05NWlxcQ0VZXFlaQ0NDQ0NDQ0ND Q1xcRUVFQ09JSUlLSUlLTV5DSUdxS0tHS0lFR0tIcUlGR1xaXEVDXENDQENAXENFWlpDWk1FQ0ND Xl5aRUBJQ0BeXVhdRUlJSUlLS0tDQ0NDQ0NAQEBAQFpaWlpFQ0NDQ0NFRUVFQ19DQ0NdQ0NLTHVc XHNLRENFWltLQ0NdRkNDQ3VJSUtzS0N1Q0NcXERARkNcXENZXEN0SUlJSUleXl5eS0tLS0tLWlxc XFxcRV5HXlhLQ0ZAR0JFW1pbTExMQ0N6f3FQW1tAR0VFdnFcXl5FSFteW1xFRUVFRUVFRUVFXl5I SEhFc0xMTE5LS05xQEVMSnVOTkpOTEdKTkt1TEpKXlxeSEVeRUVDRUNeRUdcXEVccUdFRUVAQFxH Q0xFQ0BfWV9ITExMS05OTkVFRUVFRUNDQ0NDXFxcXEdFRUVFRUdHR0dFQUVFRV9FRU9wel5eeE5H RUhbXU5FRUBJRUVFekxMTnhORXpFRV5eR0NKRV5eRVteRX9MS0xLS0BAQEBOTk5OTk5cXl5eXl5H QEpAWU5FSkNKREhdXF1wcHFFRX5/dFBcXEFKR0d2dF1fX0dKXF9cXUdHR0dHR0dHR0dfX0pKSkd2 T09PcU9PcXRCR09MeXFxTHFPSkxxTXlPTExfXV9KR19HR0RHRF9HSV1dR11zSUdHR0JCXUpET0dE QkBaQEtPT09PcXFxR0dHR0dHRERERERdXV1dSUdHR0dHSkpKSkdCR0dHQEdHcnN+X197cUlHS1xe cUdHQUxHR0d+T09xe3FHfkdHX19JRExHQV5HXF9Hf09PT09PQkJCQnFxcXFxcV1fX19fX0pCTEJa cUdMRExGSl5eXnNzdEdHYmJ3UF1dQkxISXl3XkFBSUxdQV1eSUlJSUlJSUlJSUFBTExMSXpxcXF0 cXF0d0NJcU98dHRPdHFMT3RxfHFPT0FeQUxJQUlJRklGQUlMXl5JXnhMSUlJQ0NeTEZxSUZDQVpB TXFxcXF0dHRJSUlJSUlGRkZGRl5eXl5MSUlJSUlMTExMSURJSUlCSUl1dmJBQX90S0lNXV90SUlD TklJSWJxcXR/dEliSUlBQUtGT0lBQEldQUlhcXFxcXFDQ0NDdHR0dHR0XkFBQUFBTENPQ1p0SU9G T0lMX0BAdnV2SUlmanpQXl5ETktLYHpfQkJLT15CXl9LS0tLS0tLS0tLQkJPT09LfXR0dHd0dHd6 RUt0cWB3d3F3dE5xd3JgdHJxQl9CT0tCS0tIS0hCS05fX0tfek5LS0tFRV9OSHRLSEVDXENPdHR0 dHd3d0tLS0tLS0hISEhIX19fX05LS0tLS05OTk5LRktLS0NLS3h4ZkJCY3dOS09eQHdLS0RxS0tL ZnR0d2N3S2ZLS0JCTkhyS0RBS15CS2p0dHR0dEVFRUV3d3d3d3dfQkJCQkJORXFFXHdLckhxS09A QUF5eXpLS2prfVBfX0VwTU1hfUBDQ01xX0NfQE1NTU1NTU1NTU1DQ3FxcU1gd3d3end3en1HTXdz ZHp6c3p3cHN6dmR3dHNDQENxTUNNTUpNSkNNcEBATUB+cE1NTUdHQHBKd01KR0RdRHF3d3d3enp6 TU1NTU1NSkpKSkpAQEBAcE1NTU1NcHBwcE1HTU1NRE1Ne3xrQ0NnenBNcV9Bek1NRXNNTU1qd3d6 Z3pNak1NQ0NwSnRNQ0RNX0NNa3d3d3d3R0dHR3p6enp6ekBDQ0NDQ3BHc0ddek10SnNNcUFCQnx8 fE1NExNkUEFBSXVxcmlkQ0ZGcnZBRkFDcnJycnJycnJyckZGdnZ2cmh9fX1gfX1gZEpyfXlsYGB5 YH11eWB7bH15eUZDRnZyRnJyTnJORnJ1Q0NyQ2Z1cnJySkpDdU59ck5KR15Hd319fX1gYGBycnJy cnJOTk5OTkNDQ0N1cnJycnJ1dXV1cktycnJHcnJiYhNGRm9gdXJ3QkRgcnJJeXJychN9fWBvYHIT cnJGRnVOeXFGR3JBRnITfX19fX1KSkpKYGBgYGBgQ0ZGRkZGdUp5Sl5gcnlOeXF2REREYmRjcnIb G2pQQ0NMenV2b2pFSUl2e0NJQ0V2dnZ2dnZ2dnZ2SUl7e3t2bmJiYmZiYmZqTXZifhNmZn5mYnp+ ZmITYn5+SUVJe3ZJdnZxdnFJdnpFRXZFbHp2dnZNTUV6cWJ2cU1KQEp7YmJiYmZmZnZ2dnZ2dnFx cXFxRUVFRXp2dnZ2dnp6enp2TnZ2dkp2dmdpG0lJF2Z5dntERmZ2dk19dnZ2G2JiZhdmdht2dklJ eXF+dUlKdkNJdhtiYmJiYk1NTU1mZmZmZmZFSUlJSUl6TX5NQGZ2fnF+dXtGR0hoaGp2dgMEEVBF RU9+eXoWEUdMTHp/RUxFR3p6enp6enp6enpMTH9/f3oVZ2dnbGdnbBFwemdjGmxsY2xnfmNsZxpn Y2NMR0x/ekx6enV6dUx6fkdHekcSfnp6enBwR351Z3p1cE1CTX9nZ2dnbGxsenp6enp6dXV1dXVH R0dHfnp6enp6fn5+fnpxenp6TXp6bW8DTEwebH56YEZJbHp6cGJ6enoDZ2dsHmx6A3p6TEx+dWN5 S0x6RUx6BGdnZ2dncHBwcGxsbGxsbEdMTExMTH5wY3BCbHpjdWN6f0lJSm5ub3p6DA0YUEdHc2N+ fh8YSk9PfmRHT0dKfn5+fn5+fn5+fk9PZGRkfh1tbW0SbW0SGHR+bWgCEhJoEm1jaBJsAm1paE9K T2R+T35+eX55T35jSkp+Shljfn5+dHRKY3ltfnl0cERwZW1tbW0SEhJ+fn5+fn55eXl5eUpKSkpj fn5+fn5jY2NjfnV+fn5wfn4UFgxPTwcSY35lSEwSfn50aH5+fgxtbRIHEn4Mfn5PT2N5aX5NcH5H T34NbW1tbW10dHR0EhISEhISSk9PT09PY3RodEQSfml5aH5kTExMFRUWfn40NR5QSUl3aGJiAh5M cXFiaUlxSUxiYmJiYmJiYmJicXFpaWliAxMTExgTExged2ITbQkYGG0YE2htGBEJE25tcUxxaWJx YmJ8YnxxYmhMTGJMH2hiYmJ3d0xofBNifHdzRnNpExMTExgYGGJiYmJiYnx8fHx8TExMTGhiYmJi YmhoaGhieGJiYnNiYhobNXFxDhhnYmpLThhiYndtYmJiNBMTGA4YYjRiYnFxZ3xuYXFyYklxYjET ExMTE3d3d3cYGBgYGBhMcXFxcXFod213RhhibnxtYWlOTk8bGxxiYlBSUVBQUFVQVVBQU1BXUB3h UlHrUV9QVlBXUiLiUFVU6FFf5FNQWldU6FFf5VFQSVhWVe9RX1BSUFNRFFBZUXBRe1BIe0CmbK1s HkCkbB2tbFBvbK1sQKxsrWxhYHFBcUF1cUFxUVBUUKxwU5CsEFVQq1BwVJBQUlAhr7RSgFU7UFxQ SFA77VK+UElQRlKWUEpSlRBkSXNRY1HXVFNTUVBTRlpYQFNaVVNcUUxRfFFTUa1dsENbSkdHSnBY YFhSWCxAsEZJSQHCSHseQKQdraQNHhU1FLZQbx2ttg1vaWlRQUJpQkdpYWBRDVEWFBYUGRRRc0JC ZmNiRkVEVldSU2JGRURWc3J2ZWRmUSB2YWA1AXsUcgjC4BQPMBMUDw9R01FYUnPtHGZ8Oueunq6Q MBMUDw8UEzBQUlEBUoFUKVU7UF5QSVBq4VFf6FGF5kREV1NanFHoU8nkUspHnEHoU8njb0BRQOpR 2VBLUXLhYkh7QKQNpK2mtL1Qb2xArWxhYFFzQ2ZnZmZjYkZFRFdWV1FzQ2ZmY2JGRURXUzRhWFNC Sjprf2tYXWKtAGFWUyoHf20VUoFR0Dl9bBhrfE1Hcwyu0FHR39preWgvUFJQeK+0U4dVOFBLUE9R 4RADUVBZUkVUUFlTRFVQWVZBWFBZV0BbS1pXQFxIXVdAX0deV0BCR15WQUNHXlNERkdeUkVJSF1S RUpLWlJFTEtaU0RNSF1TRE5IXVZBT0taVkFaS0voUVEQWVBZRFBQWV1ISOhRURBAR15ER0deQUJC Tk5PT1VVVuhRURBNV1dYWFtbXFxfX0BWXl1dWlpZU1NUVExMTU1DQ0ToUVEQQkVFRkZJSUpKUlFL SEhHR1BaXuxRUVBdURRQWlFR41nlV1/uUVFQXFEUUFtRUVBYURHmV1dWQEHdQu5RUVBOURRQT1FR UFVSvOVWVlJT3VTuUVFQTFEUUE1RUVBDUrzjRERFUe5RUVBKURRQSVFRUEZREeJF5UfsUVFQSFEU UEtRURBecFDfUFJQSXBxz3EBwkh7ex6kDR2tpq2kpK2uvUBsQKStrq2kbGxApK2uraRsQGxApK2u vUCkraa9UG9sQGxAbH9sbEBsQGxAbECtbEBsQGxAbEBsb2xAbEBsb2xAbEBsQGxAbECtbEBsQGxA bEBs11V+ey1AlNd+SHstQJRfX19fX19fX19fX19fX19fYWBHQ3NlY0NzZWNDY1NxQ2NTY0VzU2NF c1NzQ3FTQ3FDcQoG2PJrjacH1AhRdwbUCNz1bLGqBtUGro0KJFF2aq6KTFH41VF00lHhrh9R4a4f 0q6M1a4IUfiuCFJ9UXRQU1AfrzVTr1XyUHtQYlBrUdQQb31QfWJScGImQ5lxU1xERU58Yk9PW1BZ e2NrcXBaXFdfREFle3R8cX1OeXR8YlBFa1RtbGJQRWtUV3N0THBaWuhRQudbT0RbW09AQehR7eJl dXTsUe9QfFEwUH1RY+JMcE/qU05QTlEw4kxVY+tRMFBlUFlRMOJXWlvqUThQZVFj4lddcOxRQlBP U25QWlFCEFs/W1FwW2Bb4FtTW+hTdBBZW2x4T1tAX1lA6lJYUEFScuNsc1l16FJYEF5/dG90H3QP dC90z3RWdOhTbxBebWiKEFRRH1QPVM9UU1TrU29QbVBgUVUQXR9IURBIAEgwSKBIVEjoU3PlbFtH W2xa6lJ0Ua5QSHt7QGx7QKYNIb1ApA0hvUCkDb17lFFApK17bHtAbHtAkFGmDSG9pL1Qb72kbEC0 QLRvpKxsQK2krWxApGzXVX57LUCUUEFCaUJHaVFBQkdpUEFCaUFCaUFCaUFCaWlCaVdebGxVbF5s VWxebFdAXmxVbGxebGxsYWBQDVENUUZHRkVEVHNyd1dzZ3Z2d0NjRkZHQ3Z2ZWRmZmNiR2djV0ZH U3NmZWR3dnd3dldWRURHU0ZjYmZlZHZ3UtDsc2+uvphGenUdeBIACQ12V20RyNw2NZA8RnxBHUTY DQ52W3dLERgxbW409k9DB9dqGVMZ7GYzJuywUi/aXUx9URPFK3hSXtXsMQ79MFNqFU5srosSeRVp eXFCVGprCjw4rOdU3DMTJBlQUFVQja+WVm5VO1BTUEBQdlBiUBVQ7hBPxxFRZlFmUgZRBlIzUTNS 2BH6YulQ6VPqYppiXFNSUuhTNhBEUVBEUVFQU1JRUFQXFlJRYXduGX3oUR/iYxl36FPY4kEZVOhR HxBFTBlbU1NQUxdHR0pglS9r32vAa1Nr6FEU4hOVeuhTKBBaXpUvSd9JwElTSehRFOd0lSBXUVdJ FuhRS+GoSHseQKQNHa2mDa2mraYNrR4VNRS2UG9sbx29rb1vva29QKRsUUFCR2nXfnstQJRhYFEN UA1RUXNRUXJ2ZWRnZmNiRkVEUndiZ2ZnZmdmZWR2c3JXVldWV1ZFREZRcnZlZEJjYkZFRFJ3Ymdm Z2ZnZmVkdnNyVldWRURGVmurcihUiqxVNtHUO8Q91KXCckVORVoUdnZLcEJxSEEQc3ZSrjLSpN86 2a3fT0ZwSF8SdHtNdGp+G3NVO6oOVfKtTtovlMQp2CmYrr9lQUhlSqDYZXJ5XklpebksaXF4rVje L+5RQdwkk663akFKaXK1LWdzfBXFqARydlBTUA6vsVX3VTtQZVAUUABRRBBudl9wQGRfZE9mGlUY dRh36h9TFR5QfGZqEh5ATlMbFXZmXVBTbkn8RvxHR3luKRBWU3ZQdkB2cHYQdgB2VXbuU/xQMFBy UxVQeVAbUxXnf395W0l/SEboU8kQSkdISHb8EFB1UXXlMEMeEEdQR0BHcEdgR1RH6FFsEEVdMFBO QE5wTmBOVE78UEBAQGBAU0DoUqIQQF2LUBilf2JvYu9iU2JJAVDoUeDjElkIauhRbBBcU5oScBJR EgECMvtIe0FCaQ1/vaa9QL0eQKQNHb1Ava0NvQ1KKkCqDUh/SrxKrA1KrWx/QLRAtFBvbEC9QK1K KrgNSH9vSr1CaX+9vUJHaUJpQkdpUUFCaWlCaWlhYFENDVF2dmVkQmNiRkVEV1ZXRkZHZmZlZHZ3 Z3FXVlZXVldGR0ZjYmZnY1ZWc3J2d1ZWc3J2ZWRmZnVmZ2ZlZHd2c3JXVkVERlNWVkVERmNiZmd2 UlIBV1io+TzTEA+BE2J6aWJ2e1xR0F9mGjQXFgASemZPfnFwYM40BNYbN4E6yuYeilGaA3ZlTkh1 fUp2XbMjM98IdgxmbSFSvGYHcZhRWSoFOx0kCYcuGm8ndnBgW3R0XW7WMBk/ekxETDc4EwAZGvwk DMD0gWtuBTAYd010ZiFjJ66qb9cOI81ycQxRSFBRUW9SglLUVTtQWlB06VBRUYXkVVNYnFLoU8ni UUlb6FFy4TlIex5ApB2kvVBvvWFgUXNDZmZjYkZFRFdRP2BVUSwGYG0UUoJRLt/ca3toLFBQUVA3 ripTKlU7UEBQHxBERFR9WGRUU1FYWVBBWUNRf2BQUVDuUYlQW1BYUTVQVlBZUSMQW1YHD1s/W1Jb SUEB6VE8UEh7HkCkDR29vUC0QK0NtFBvb0JpaWFgUQ1RV1ZXVlJBREdXUEFkZ2ZnZlMqQt8OwOUf Qa6jCjqAz1U7ZzbXgK37rqr3kWpROFE2npq859xQUFGvSa4qUnxVO1BBUBsQX0tUc1lrVFNZUVpQ Q1pBWetRNVBXUFpRI+ZcUX9vUFFQ6FIy51cHH1xRXN1D6lGdUaBQSHtApA29rQ20QL1AtFBvb0Jp aWFgUQ1TZ2ZmQmdCZWR3Z1BBRFdWV1a3QiPP+GUUH0BRXQo5gc+uKmcClFELllFRsPeSaa7Irsuf mrvn3FBQUVCmUjVUQlU7UBtQmhBme35rfm5tbm9uEG4RbhJXZFJqXFJwR38Tb1JvU29Ub1VhWWFa YVtgR+RS61xcQxcXUFd4YWR46FFY5k9QZEBkUmTtUVhQbFBdUVhQUVFY5FdTXlBP6lP7UH5T++ZQ /F9sUWxaEVpRNVBeUFRRNVBQUEZSZ1BeUBRSZxBAUBBeCVAJT/xs/HWLZ4twfuhR1eMc3mJIe0lA pEq9vb29vb1ISkC9QL1AtEC0UH8NvUmltUBsSG+9vUC9DUC9QLRBQml/bGFgUQ0hUA1RflJlZGZj YkZFRFZWV2ZmZ2ZjYkZFRFZzcnd2c3JXTlJHRkVEVnNydnd2dndWVldWVnNydmVkblJnd3JXVnNy dmVkZmNiRkdGUiFTQRERd3tvbkFVaGB/b2p8bBlsQ2JITHUbe2AlSUNqeXsVXVhDT3FGWF0SfHlr fSl+fDtMSWtGaRhrfW8kQUhTsGpsLnN+FhFkeSRtbEdyYhNqeHsSU1FUYXVsckl3e2sXC2tmZGVq ZgsUaHd4bxNyfFRRVBB8eWsoXUFQUVB4UNhUPVSYUFtQF+FTUuhRdOJRUVTrU8tQV1BaUXTiWVZV 6FF05FNYkFJZ6FF0EFpbT1BRUElcMmJIex5ApA1sHaRsrWykbFB/pGytbECkbGFgQ3FBY0FxRXFB c0FxeFGx01Gxrk/Trk9SuFGwrnDUrnRRjFBQUa+WrudROFFhUEJQERBA4lLgU1KVQlFR/FDn0F1R XehT2uVQf3BRUVHoUTUQW1pVVUARWg9DDvtIe0CmvWl/QKQNtFBvDa29YWBRDVAhU3dmZ2ZlZHZ3 dmVkZmNiRkVEVnNHyXVNN0FdMRUTM++u53oHfXNzdw9xSXcRDjofLaJQUFFQXVEJUsRSeVBTUHMQ WVDiU1EeUlAeUuhT2eVTSVTW1Uh7HkCkHb20QLRQf71hYENxV3EeUhZuredSeYBQUa+1r7RRflF8 UFtQdhBCUBFWW1OwX1lRP1kvWVJZSVxs6VHLUEh7HkCkDSEdvVBvvWFgQ2JGRURWc3J2ZWRm2RUw MRQUMDBRfDAUFDAwFBQwUFGvCq+xUwFVOFBTUG7iUFFR6FJEEF9SU0RSUlNSUVtTUFVQv1PoU1jk Ub9SSVTqUapR6VBIex5ApB29pL1Qb2xvbNdVfnstQJRhYFFRc1FTAazH3lM6VTiqKVXXUFBSUCGv tFOtVThQRFB8UJYQQHhwWVpkdnBZWmR3ZFlaZEjor7DjWVpkS+ivsONZWmRK6K+cEGJZWmR0VnpB dUh0SXZLfHZ5d2VIYUliSmVLb3ZsdxpKFXcKTAd4J0soeENNS3Z4VHpPRehRYuJQVXLoUWIQXVtd TxBEXG9PEEJbb0/oUTzjX0l9duxSclB4U05Qeq+Q40Rcb3ror5DjQltveuhRPOJUSn7oUWXhuUh7 HkCmHa1Re3uktB5ApB2tUXt7UG+9b71RQUJHaWFgUQ17e3t7e3tRYkZGRURSUldWVnNydnZlZGdm QmZHclZWV1ZTVldWRURGY2JnZmdmQ2ZlZHZShTHabQPECmnzBR/RGgMVnfkNTnxjdhcGEl1DZXd5 SmVzAi1nZVU4IewMz67+rrQwbAIw6Dm2t5BRRw8URxYigK6EtxENFmFoRn07q1Hokj9jalBRUGBQ UFPfVThQSlD9EE5KcFlcZBhQFlFSdknnSVJfQ15ZXlqrWVhRV6tYEEnrUTBQSFBIUnAQW0MwQ15R U1l4UFFR6FEQ5l5DRF5eQ0jqUlhQSVE4EEtKSlBVeFlYXF5LeENAT15/Xt9e/15UXkdeS1rqU8ZR o1BIe3tAbHsNe2x7QJBQb2x7b1BsQKS9115+e1UtQJR7QUdpUUoqQKpIf7RKUEC9UUCQUEC9UUCQ 114tlGFgUA1RDXtRUVZFREZGR1dxZ25SZ0NmZ2ZlZHZzcld3dVPfruVKdXs8W60FWzYAY3CUfVJW Z2NJGlhRrVU4q94JSEhjX1Z1dVJOFD1S9MpZSkd9ZVh1K1BQUVBYUFBTjVU4UE5QjRBillSRSVJ2 XGBUY1xlXWBHYEkYVBhVFFwUXRhGGEcaTRhON1DFUMZcQVRcRFxERlNcXU7rUfhQSlBKUewQR02r X05PTlJOXVxTU1dSXVxTU1pKSUdH6FE3EEJUUkRUVFJUSVJHRFdSUUdJWkror5DiX2lK61E/UFFQ WlPE5UFVUVxRUuhSVhBdT1eKcEQQRDBEU0RKcOpRYFJRUEh7HkCmDR29QKZsUG9vvUC9e0FpaUFp UUFCaUJpaddefntVLUCUUEFCR2lRQUJHaUh+Db28UEClUUCZYWBRDQ0hcXFlUGdmZmVkdnNyV3dm Z2ZjYkZFRFZXVlFxYmZnY1KIrWBRSZHyAyMG2zN1ZAMjy8DtDMA+ruBRVS41fH91UVSK5e8xCyLJ QcQdOuIlN5nIJK6xaQZQUFFQSa+0U5JVOFBjUIAQenliZHpoYlN/UXdBcU1xfnliZkZtchhIFk4Y Ylp6e3RUSFZgend8VEhZUOhSWOZRb3fAd1J36FE/5XBRUXBAXOpRMFBdUTjj8FlRWehR9+JAVXzo U87lcFm/UFFQ6lNOUFxSWORwXVFddOhSVhBdZBBgUWCKf0xRUExRTOhTxxBfEFZRVopwQ29DD0NT Q0pl6lFgUa5QSHseQKYNHb0hpCENvSFAtn8NvbQNUG+9b60NpLRBQml/QL0NQL1BaWlBQmlRQUJp aUJpaWFgDVANUWdmZ2ZmZWR2c3JWV3dmZmNiRkVEVldWV0ZHRkVEV1Zzcnd2ZWRmY2JHRkZjYmdm ZWR2dlFVXdsFIjgOFmcOZ3gE+TnU9AAeaSo/fROc+7EobXoQf0hGdshibn8VCNpSsXtEd2LWHRIO ahhELjzFOAIqfXFyYGwJLrzK0n1PY35sWkA3bw3cPfQfUFJQdK+0VFRVOFBaUF1RIhA0BVJRblxR VlN1XWBTYVRmVWpWbldnXGBdFlIaUxxWHFcYXAdU1lzWXcRSz1b+Vv1X71bvV+pc5l2XUpVdhVKF XbZStlO8VrxXtl1yUFFXWlxVXVZZVFhRV1lUW11WWlxcXVxaXehRUBBcUlNEUlJTXFxdVFlZ6FEQ 5lpcRFpaXFzoUe/lVHhTVF1W6FNxEFpXUFFRsFGgUVJR6FNw5VpaeFlcVuhTThBZD1dRf1fPV1JX 6FNKEEJfU3BTEFMwUyBT0FOQU7BTV1PoUkYQWllUVFlZWFhZWVnoUT8QWlpZXFxZWrtaUVrrU09Q WVBSU04QX39RUVFJWl54XEBaR1peWupRYFGkUEh7e0Bse3tse0CQUR6kDR20eyqgDVFJf3sqkVFI f3sqQKFRSX97KpBRSH97KkCAUUh/eyqxDVFIf0CkDSG0UG97bFBApg0hbK1sb3tsvddVfnvXWC2U 11V+SHtYLUCUX19fX2FgUQ1QDSFRcWdRY1FjV3NTc0NDUVGPrhVhU3zTrqDNZckMs973ra5RTvhT 8qwO+K6WUbJSAa3/UFBRUB6vs1RYVRxQcVD2EHVLTnpTflR+cWlQaVNvXWVGb05ZdE9RUXNFR0xf UnNYRUJIU1RU6FFBEFpxUERxcVBvQlFC6FE/EF9ccXFcUlMQX2nPU/9TUlPoUT/jUVBUSOhTzhBc XF1/X1FfSXKPTFFM7FFVUFhSSVBzUULhuUh7QKa9DR5AtA1Qbx29b2ytDXtsQml/QL0N115+e1Ut QJRQQUJpUUFCaUFCaWlBY2FgUA1RDVFxV3FXTlJFRFJUc3J2ZWRmY2JHRkdGY2JnZmVkdnd2d1JY UlATrnVswO0ky668yj85b3t0TEEFZmkcZBYkNB0qVRy6Kkc8nSjArqLPA2V8b1xYFXwSBtUonWV5 U1BQUlArr7RURVUjUEZQeVDHEHh7VHhVYXIXRVRxVXVYclxxSGJVZ1hpQmVHZkhZVFRbQ1RIW3JL Q1VQ6FHqEERTUatQVFVRVUdJU1p0R05VeFNQeOhRYxBJV1BVTqxeXUmKH0FRQUl6dIpQWg9aL1pT WupSX1B7UWXhuUh7QKYNvR5ApCEdvVBvvW9/vUJpQmlBaVFBQmlCaWkNUEC9UUCtYWBRDQ1QDVFF VldWV2ZjYkZFRFdWc3J2ZWRCUGdmUVZXVkVERmNiZ2ZnZmVkd3ZzclRFyCbCOQ0UIccg2rTMkOtR cPXRrj8UfE4RYXdPY3wVeXB8c1Ujd3o+2LtP+cuY9pqGlIRR2lFfFmet3eLqLgMcGkx+2orBGmJ3 UFBRUKGvtFQ+VRxQWlAtEEZ/VVFzUlFVVFQLU1JEU1NSVFpTUlBa6FE45VVWEF9pVuhRP+VRUFRT XVnqUlhQUFNK41pJW1TsU0lQU1NIUFVRP+RRcFJRUuxTx1BcUnRSQ1BIe0CkDWy9pL0eQKQdtL1Q b29srXtstEJpQUJp115+e1UtQJRhYFANUQ1RcUVRd1FxclZXc1H4UpastABS3a7p0ytjdlUcfaqV fVQaZRJQUFNQHK+0U71VOFBLUHlQaFDOEHN7aGd5UndXbFFkXm96aGRpaJhXV1B6d39eTHBmekxe UFRic+hRM+JWVWLoUWLkRF1mikHqUThQcFFVEElZEEJbb39Zb1kfWVNZSmp3ijBTIFPAU1NT6lJy UH9RVRBcT0d/R29HH0dUR0lp6lFCUc1QSHseQKQNHb2kDb0eQKYNUXsdvaStUG+9b71BR2lRQUJp aUFCaWlhYFENUA1RdnZlZGZjYkZFRFZXVldGRkVEVnNydmVkZmdmdWZnZmVkdnNyV1ZFREZXVldW VkVERmNiZ2ZlZHZR9W9vnfnM5BwXfg8kaauR/ZUHBW5RPWVBdm15ZUxhZMJjRXBnGWsYZBkUUpQE zxvJnfspANJicHLILx7nruncD/ARf8R2eg/OMgF3FCYYLb98cmOZIQ4JEgvQBMBQUlAHr7NToVUi UEVQeFD4EGBxU2dTZ1RnRBhEVVZCRkJ4U39Ue1d/W39Gb1NpVGlcb0Y/VPhIiUepSF96VHpGUlDo UhIQQVNRq1BGVFNTSnNTUFRWRk1W6FPOEHVfd093Unc/d1F3UE2sXVVQXXOKWUl5SopPQBBA70BT L0BRQEp66lH7Uc1QSHseQKYNIR29HkCkHa1Qb2+9QmkNfw29QmlCaUFpUUFCR2lQQL1RQK1hYFEh DVANR2VmdGdWc3J2ZWRnZmNiRkVEUlBXVlFmZ2ZlZHZzcldWV1ZFREdGY2IHyVFXOg4TIcgh2bXM 7+uusPTRUcAUfU0RYXZPZHwVek99c015eqW6cPrLmPaahpWErieuoRZnUiPi6i4DGxtMftqKwRpi d1BSUAKvtFIAU81QW1BHUH0QW1YRUFdcEUJbUxFZ6FFTEF1fEX9Fb0VSRQRIMsFIe0CmDb2kvVBv vW+9YWBRYkZFRFZzcnZlZGZTYkZFRFZzcnZlZGZR/BQwMBUUMDAhFTAxFBQwMFPNMRQUMDAUFDGt 3zAUFDAwFBQwUFJQUa7nUgZTzlBbUE5QBRBdF0MHQ1KVTlFd/FznSehT2hBeVhFQV0FBTEZcf3Bd UV3oUTXiTBFG6FFT5VMRf1lRWehSoONPMsFIe0CmDb2kvaQNtEFCaX9Qb71vrb1hYFENUA1RYkZF RFZzcnZlZGZRd2ZnZmVkdnd2ZWRmY2JGRURWUf8WMTIVFDIxrv5HyXVNN0FdMRUTM+9TzjIVFDIy FBUyq0l6B31zc3cPcUl3EQ46Hy2iUFBRUHlQ6VQ9VNtQVlDD50ZVUXhUGFRS6lKWUFhSleNXVlVV 6FFREFtRUERRVVRRUFRVVehRURBfUlNEUlVWUlNUU1BTWFZT6FGY5FL8UfxV6FGY5nDQUFFQVFPo UpLlUVIEV1BW6FPJ41gyYkh7QKZsQKZsrGxQfw1JSq29vb1RQUJHaddYfkh7VC1AlNdYfkh7VC1A lGFgURYUFhRQDVENdVFlUUVRUVQ9q+xUFKzjUx3pUe4BUZPars+u9VBQUlB4Ue9UPlPYUFNQV1AW EFlQU1dRUllWVlfoU8sQWVVQVFFU5VBSU+hTy+ZRUFZXBFhW6FPJ41kyYkh7QLZAtlBvbK1sQKQN bK1sUUFCaWlCaWlhYENxRXFFcUVxeFQWq+pUFqvqU9jSldJQUVB5UOlUPVTbUFZQKRBbCFWbVVJ4 VVFWVVXoUVEQW1FQRFFVVFFQVFVV6FFREFlSU0RSVVZSU1DoUZjkUfxS/FXoUZjmcNBTUVNRUuhT yRBbWFNUVFBWBFcyYkh7QKRsbEBsQKRsUH8NSUqtvb2911h+SHtULUCU11h+SHtULUCUYWBRIQ1D UUVRZVFReVQUq+xTHazjVNuuEwKubdtRMFELUFBSUOWvs1OfVTtQdFBgUMsQYl5VTlV+VXtJd011 c2hUa1VqScdy9nLlcplVlXK2XrVypl5BVVheSEJzclVTVFFfQVtF6FEYEElbPktTUa11EXtbb0If QlJCixBIwEjwSFNI6FMsEEVYmg9PP08vT/BPVE9KYngRft1QPlHoU8rjYeA5SHtApr2kvR5Apg0d va0NrSFQb62+b729QWlpQUdpUUFCaUJpYWBRDVFzZGZnZmdmZWR2c3JWRURHRkVEVnNydmVkZmNi RkZFRFdWVFZXYkZFRFZzcnZlZGZR0XkVwzl5SwFse2NCcx9oagGZ1D/5BWMXrs4zZxQPMBMUMA9R LjvI/iwwbxcFC31LQ09vf2IdBRcmLxjTFzYfPosq5w8UFDAwFBQPUFJQDK4WVxRVO1ATUAZQxBBO VEBUdURARHVzRGZSa1loXWRfZhgZXVtgExQdUGFR6FPlEEEQXhlzURQpEFdFGUxfVyl7SehT+xBd HRBmZntaWxkIR0dKSepRNVB3UbrjT1QIfuhRL+IammnoUSznQtBPSQds1Uh7HkCkHb2kvaS9QK20 HhU1FLYdvVBvbECttUC9b71vvW+9QKSkQUJpaWFgUQ1RZ1NWRURGY2JmQmVAUHFyVFJFQFBxcFBn Y1JQcXBQQUBCdHFiVEJFRFJUc3J2ZWRnVldWV1ZzcnZlZG5SZ2ZjYkZHd3JXVldWRURGY2JnblJl ZHd2VMuk509/chWL367NrrOmrj68UelRBVFJUe4NbSiuZa6Ari+uXKhRkFFAjVEb9uOupcozOEgD fm9ueGMXMREgwwx/ZmgZXSV2dWJpNnVGQ3RjJBpKQ1PNWq3cOGRwf89Rd/dRRFEzt64YrK72rhdR fqmuiq6XUaFRLVFWUe+i4a6Q4p+u+vMyHWYH2mUXcUUhPSCH7cZhShYHBXpp1b/BfGBMd+qzMBV0 S1BSr9xQUFScVTtQcVB0UIsQE3taa1ppSWZKGloZXQpaO1o9XSla2Fr6SlxRUnRzc1NcQV1NXHEC TUv2cltTWk1bRSVNSgtzU0FRS1F0dVBycXNCQUHoUzbnU3NEU1NzcnToUzbnUFFwUVFRW3PoUhAQ QkJTS0pKXFxbWEZPcUIXQ09zQepTz1BTU2AQXHMAcgB/cW9xL3FTcehTf+N18LdIe0CmDaSkpr1A rb1AvVBvbEBsQGxvvUJpDX9srWzXXn5711QtlFFBQmlCaWlQQUJpaUh7QL1RQJB7QL1RQJDXQC2U XmxVlGFgUQ1RcVdXVldWRURGR0VxZ2ZnZmdRY1NWRURGR1dxZ2ZnZmZnZ0NRU26uDAQwTF1aY2uu O1pmemg5U5F9fVNnEFqt5VsHXUx+VVlKrtdR5TgjdU5HR0h5U3V1WU14LVQrq/oHQhRuVXV1WFZe CT6vUequFlBTr5xQUFV5VRxQTVB2UGBRSBDWQklwa0prdlN7EFlcZH9kWVxkQxBDRWRQEF9EZE53 eHh2QkdDTUJQSE1NUEd4d3pIdnhaTndOd0haf312eHhPR0hESBBEXG9HR0h6d0J0AHZ3UHhOd1B3 QHdSd3dCUFJCWEdheEhHQH0dXf5yHVYQTmJkUFbPVu9WU1ZKYkdHR2FaaMNIUUfor6DnT0d/R29H U0dBDWhne3tAbHseQKYNex25pLl7QGx7QJBQb29CaX8NvXtArVC0QL3XVX5Re3stQJRRQWlpQWlp UEFCaXtBaUFCaWlIUEC9UUCQUEC9UUCQ1y1AlGxhYFF7e3t7DVETDAjpUHivuONdQW946K+441xA b1Dor5DiX2lK6K+84V9pe3t7ewlRcWJHRkZFRFZWV0ZGRURWVnFxZ2JmZmdDZmVkdndRblJlZHZX V1NTRmNiZmVkdnZRbVJI4x01Pwj/5ezCwL6uk62cXQIXe02idWszUW3YzQ8yAmfh/WJJj/4TOlUc Q0jbCBjGMXll9j43mQ11Tm80UxIve3N+VK2eUgLrAx4yUlKt9631UqneFDl5UFBRUNavsVWUVTtQ cVDw5V9wWlxkV+ivhhBNWVxkeV96SWZRi3FUaliXcFJfQV1NTk9wVFVLUVLoUZblUHFxVWVL6K+Q 5k19ZEtTQEHoUVTmXdBEWUAXQehRVBBMUFodEEdRR0lyUlIXUVFAcRdgUBBQUlBKcyrvSHseQKYh Hb17KoBRSH8quUh/HkCkIR25QKS9UG+tpGxve71sQGytbEFCR2lBQmlhYFANUQ17e1FTc3Z2c3JU V1ZFREZjYmZnY1ZWc3JQZWRCdGNiR0ZjYmdVlDR3V8/Q2q6+Dx35wyeUNGAsreelroW+Ue+NBC0Q SWJjVTuuAeD9vKOVkPzlOCXqxlF5v7BRx6t0QmZQUq/mUFBVzVUcUERQdVCUENlXSF1Bb0hIW19v dV10QmlXaVtoRWdGbE5pTxdUGVcaWxdGClcMWzlaOVsnVddV8He3VURREEJHZFsQQENkW05bc0tO S3NUWVddT01PU1BUUU1QW1VaTVtFRkZPVFVEVRBEXG9UVFVMd1BFd1tSUFhUdnhVVEBxnVBfz1/v X1NfSndUR1R2WmjDSHt7QGx7HkCmDR25e0Bse0CQUG9vvUC9115+UXt7VS1AlEhQQL1RQJBQQL1R QJBhYFENDXt7DVF7e3NnYmZnQ2ZlZHZ3Z3FwUEFEV1ZUcVFRVkVER0ZjYmdmQmVkdnd2GlwyNXGm SGgjXFGAUT9RFRvDrjyuk1FHroZFR05r3T/exQYKb3UBP1MHBGZ+fFd1roeupO3QqrBUrKusF09M QUcIIVEu7NiaZXRQUa/oUFBVIFUcUGBR/OlQca+iEDlcQG9Dcltfb3BVcFZ/V39YAFUAVg9XD1hY QGJRR3IpVVJ/d394aVBpdGh3b3gXQR93H3gKdA93D3g8dzx4J3LXcpdyuVC6VLdyuXSmV0Z4FkBE ZEl3T3hSWVBZdFl3X3hUX1dPVz9XU1foUnMQXEBYTVdQVkBWMFZTVuhScxBcUVVNVhBJS0F4AHd3 6FFn5HJNAE5O6FFUEEVxMFdgV1FXf1ZvVt9Wz1aPVr9WVlboU2EQR1FAUUBBUFBBQU9xckRyEERc b3Fxcnt66FM543l5eEsRXFJoUE1Qd1PNUHhQTlPNUEdTNlBNUGBTNuR4X0BSQOhTNhB2UX9Rj1G/ UVNfUU9Rv1FTUU14Uk1YcWF4cnF5QHsXehBCW296/kzoUWcQQkoXwEvwS1JLkGJxR3FhWmgtSHt7 QGx7QKYNvbSkUXu9e5RAbHtAkFBvb0JpIQ1/vWxAbEC9QL29QL1AvUBsQK5s115+UXt7VS1AlFds bHtIQKQNbA1Rf0oqQKhIf7QqQKhIf7RBQmlKfr1QQKUNUX69UEClDWFgUQ0New0hIlANUXt7UVNj YmZnY1NzZmVkdnd2c3NTVkVER0ZjYnRnY1NxZ2JmZ0NmZWR2d2dxU3N2d3Z2c1NWx37m92p1yHNZ EWRyOx7SQUZwCftRfih53asoXDYOdq9FZjBbVGkHdFRLetvMVVGtojAqraBlcWcWX1quaWxNR15E wcOu3HUd01M5GXp2eVd1rv00eRBrUFGv7lBQVdZVHFB7Uc4QO0JwVnBXf1h/WQFWAVcNWA1ZWEB9 UVlWYH3QfVNqUGpwb3NvdBhQF0Afcx90CFQHVgpwDHMMdDNHM0g/cz90IkciSCdOLHMsdNZD1k/H T/tJ/0qQfblVsH1OdBZBRGRZUFlwUl9YT1g/WFNY6FJzEFxfWU1YUFdAVzBXU1foUnPnUVZNV0gA R0foUWflQBB0AHNz6FFn5E5JAEpK6FFUEEVNMFhgWFFYf1dvV99Xz1ePV79XVlfoU2EQR1FAUV9A UFBAQE9NTkROEERcb01NTnd2EVpTOVB1UHNTzVB1UHtTNlB0UF9TNuVRUUh0UkfrU81QSFBKU80Q RklJSFhNfHhOTXVAdxd2EEJbb2B2UXboUzIQWX1NR018Wmj9SHt7QGx7QKYhUXu9e5RAbHtAkFBv bEC9QL1vQml/vUC9bL1ArmzXXn5Re3tVLUCU12yUe0hApA1sDVF/SipAqEh/tCpAoEh/tEoqQKhI f7R+vVBApQ1Rfr1QQKUNYWBRDXsNISJQDVFREwwIEF5Dcl1Bb0NyW19vR0RfaXt7ewlRU2ZnZmZn Y1NzZmVkdnZ3U1dWRURGRkdXcWdiZmdDZmd2dndncVNzflJzU1TGyX4bKnl3y3haYwDkKkhVS2wE W60LWzIKdKJ2UlJsDVpUBAt1VmrVwlVQrlBSWl8xBq25ZE9uGktUrgkFSUhzeEdRdXUZK1Nu03Vz YVR1rsogPW1QUFFQ3q+xVapVO1B/UVYQfnJReEZ7dXh2Z1FoU2ZYal9oRmpMG14YXxhMGU3HRl9W V0RXRltTdVp2dZZ9U1ror7AQfk17ZEZMR01GRV9ETUVeRlx4eHl6e3x9fldVd0xNTU9eX0ReTU5e X0VGRk93UlHoUhTmUFB/f1Vld+ivkBBfTX1kd1NcZU9ZXmB4X0BN6FJ841BeUV7oUgEQcFFSUhdR Uf5/F1BQcFAgUFNQF2FZHXNJYF5HXmBa18NIe3tAbHseQKQduUCtDb0qoEh/KrlIf0CtDb17bHtA kFBvvW97vWxAbECsbEFCaX9s11h+e14tQJRQQUJHaXtBQmlIUEC9UUCQUEC9UUCQUHthYFANUQ0N UVNzdnZzclRSRURGY2JnQ2ZlZHZzZ3FXVlZXVldTVnNydlJlQHV0cWJHRkdGY2JnVaoOdljL3MCu sJvkKWMZOEpvHVpSGVlka0FaRSuCuOOr9VEFUVtRA2tidQ1sRnx3VTuuHe73m64JuZiDTVE2Ckx1 Y3Z2U3FwQx+uDwDSUUrkUdCpkVZVR19hUFGv7lBQVrVVHFBkUlkQg0JrVGh7GVQXXhdNGHsJVAlX D1gJewl/OFgmWiRFJHMned9Y1VrTRdVz13nYftdh0GbMWMJZw0XJRsNzxnnKf8ZgxmH7WPFZ913x RPtH8nL5dfZ5+X/yYOJZ6kbkYJd5iUC3emFZWVlgUllTWXtSYGZRS1FKSlJQTGRkTVldWk1ZRkpH TUZ0eHVNdGBkYU1gWFJXTVhFXkRNRXNNck1zf3l+TX9dXl5PSlJEQkrfUlF/Um9S/1JTSlLfSlF/ Sm9K/0pTZE1NT3h5RHkQRFxveHh5UVDoUzYQZktMTEVgf39ZWVhSdHNzRkZFWHhKZXhSSnl4QEoQ QVpvSkd4EEFab09KUU94UXhHSnhlWmjLSHt7QGxsew0NUXt7e3tAbEBse0CQkFBvbEBsQGxvbEBs QGxCaX9srWzXXn5Re3teLUCUDSHXDSFeflETDAjlUhBEXG9K6K+Q43NCb0ror5DjXERvSuivkONF c29K6K+Q4l9Eb3t7e3t7CUh7Xi1AlEhQQL1RQJBQQL1RQJBQQL1RQJBQQL1RQJBQQL1RQJBQQL1R QJBQQL1RQJBQQL1RQJDXQGwtlFdAbGxhYFEhDQ0NURMMCBBbQEhbX29PSFtfb1zor7ziX2lj6K+8 EFtfaVREQGl7REBpTeivoRBbQGlERF9pckRfaXPor5ThQ2l7e3t7e3t7e3t7CVFxQ2ZlZHZ3Z3FX clZXU1ZFREdGR1dxZ2JmZ0NxU1ZFREZHV3FnYmZnQ2ZlZHZ3Z3FXclZXUjFRoD5GZjdbUvJbMzZ0 rElLcwxarTtfMAt2Ja5CJEltClqtJFswCXasRmU0W1LHXwwOd1KMUSseeXh6V3V1BCyszAV1dUNK UnV1G9NRxK48A3h0fVJ1dRvTUzQbe3l6V3V1H9FQUFGv6FBQU+xVHFBIUO3kXk5faVHor4gQTl9p cEoASlIgSlFQSmtWbEQXVxdEGUUaRgBK0EpZXuivsBAXX0FkUXBfQWRSVlNNUl9DQE1fUURQTVFe V11NXkRDV1ZUUV94VldXT0NEREQQRFxvQ0NEUlFSX15YQ0l4REAAQ1FDR0NJWmjpUwlQSHt7QGx7 DXtse0CQUG9sb2zXXn5Re3teLUCUe0FCR2lIUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQYWBRe3sN IiFRe3tRZ3FXclZXU1ZFREdGR1dxZ2JmZ0NmZWR2UUtbUsZdCg90qEtMdDRarQ9bNQ52qkdoVXd1 dQAvrMwMT3RESlJ1dR3SUzQAeXV6UFGvoK+xVJhVHFB0ULEQO2pWbFhlWWBDYERjRWRGbE9qcGly EHYIWAtZC045XShRKV3bXdB2yl35XfND8ETxRfZG+XKqXa1yTFJWU01SUXBQTVFPTk5wV1hWcE9X VlRReEZHQUxZWE5GREhWWFhPTnBEcBBEXG9OTnBB6FMcEEJbUlFSTGVbWU51eHBOQBBEUUTqU2VQ XlEO5XVOR051WupSUlFMUEh7e0Bse0ClvQ17QGx7QJBQb71vbEC9115+UXt7Xi1AlFFBQmlBQmlQ QUJpaXtBR2lXXmxXXkBsSFBAvVFAkFBAvVFAkGFgUQ1RZ3FXclZXU1JWVnNydmVkZmNiRkVEV1ZF REdGY2JmQ0NmZWR2UnNbUspbDDVywR8ni/nZ1gtqZBd7Sl5IT2o0D+JHaFV3dXUDJq5Urr2MwiMI GTESYHxjcENAW0LIURNSDgBzdXpQUFGv7lBQValVHFBrUb4QIEJ1WHZ1BnYGZ1R6UXlSelh2dXt2 e3x7fX9+e2V/ZnpnblVoWGZZZkVqSGhnamlsaxlXF1kXRQlXCUgITAp2CmY6fSdG10bPTMZNy335 UvVe8l/5QflM9E3zTvZ9+WvvQe9M5E3kTppBl0aVTYxAYl/or4TjX0JkXuivhBBuX0JkS1JETURO U1tRW1JZSEtRVFFXUk1RQEVBTUBNdE5NTX9mYE1/UGhrTVBfWV5NX0xGS01MfnZ9TX5mZ2foUzYQ ZXV2RHVnaHV2Z2hnZmhPV1hEV1dYV3ZmZ2hVbXZmZ1NMaFd1WHVMUFpYWFd1dXZ0WXRZRUZZ6K+w EHROemRZT0VGREYQRFxvRUVGf35+TU1MUkBfX1FRUFhFbHhGQFnoUnwQX09FUUX+bFlFR0VsWtfL SHt7QGx7e0CkDVG9e2x7QJBQb2xAbEBsb2xAbEBs115+UXt7UXvXXi1AlFdYbFhse0FCaWlQQmlp QUdpUUFHaddefkh7WC1AlNdYfkh7Xi1AlEhQQL1RQJBQQL1RQJBQQL1RQJBQQL1RQJBQQL1RQJBQ QL1RQJBQQL1RQJBQQL1RQJBhYFENDXt7DVANURMMCOVIXlxAb0Xor6IQR1xAb1tIW19vUBBEXG9S EERcb1EQRFxve3t7e3t7CXFxZ2ZmZWR3U1NWRURGR1dxZ25SZ0NmZWR2d2dxV3JXVldWV1NRZmdm ZWR2d2dxV1ZXVlZfUkNGRkdUuK3lW2poT8DfSBIGW609Wx8efnC0d28IW1IuWxByfUxDcQxRMTdc QHtlW1GvW2t1YS4RDYfwHgYVdVVpen0yUZ6uQQN1emNRdXVSdgAhU0XYdXJiU3V1Q0picSiu7FEU D0NJTE58V3V1VVxAHWQGka5cpwpUUFGvmFBQVMlVHFBLULoQM0J1SVF4SmlYaUkYVhlYGVwKWAlc J1bXVtdBx1bJXMhd+lL2Vvpc+ErqUppSl1aOUkZZWFldWUlJSRZV11VWUVVSTVFdQV5NXVxWW01c QUJCT1VWRFYQRFxvVVVWR3dRXVxSS+hSaBBeUFBRWFVMeFZPVVFVQFDoUWcQXkoXUEtRS0pNVUdV TFpo6VF9UEh7e0Bsex5Apg0dvbR7QA1se0CQUG9sQLxvbEC9115+UXt7Xi1AlEhQQL1RQJBQQL1R QJBQQL1RQJBhYFENDVANURMMCBBaREhbX29YREBpQOivvOFfaXt7ewlxcWdiZmdDZmVkdndncVdW VldTVkVERmNidGdjVFOrlVsxCXasRWwIW1LbWw4NdLZ8fWL2UWU7enUb01M3GHl4YFR1dVIAK6yz yHFEc8jHUFBRr+tQUFebVRxQeVHm40lEUXnor4gQwl9pe1J/XX9AbFJsV2xdbEBsRGNFZUZodR1S GFcbXRtfH0AaRBZFGXU3UDtSJVArUidFIHvbUvlS5VBMSUNRRlBLXUlFSUZUWVFZUltdWUZUU1dU TVNfQ0BNX090cE1PXlhdTV5OSE1NTnV0SEdEQ1hXWHhPeHh5dUhQUVFPRkdERlFSRkdXWFhPQ0RE Q0NEUlFR6FM2EF5FREREEERcb0VFRHV0dOhTNhBeSEdERxBEXG9ISEdRT3joU80QclBTUlJQUk9O TkZGRUVfX15YSEN6eERDR09If0gfSFNIQFjrUnxQEFBDr5DmQltvT0NRQ+hSaOVRWUUXcFHoUeHn f0ZvRh9GU0boU2AQWXpDR0hHQ0h6WuhSd+HLSHt7QGxse3tJQKYNSL1KSb17QKQNUXtRSki9e0AN bEBse0CQkFBvbEBsQGxAbEBsb2xAbEC9QWnXXn5Re3teLUCU11R+UXtIe1UtQJTXXn5Ie14tQJTX WH5Ie1UtQJRRQUJpaXtBQkdpSFBAvVFAkFBAvVFAkFBAvVFAkFBAvVFAkFBAvVFAkGFgUQ0NDQ1R e1ANUUNRcVdyVldTVkVERkdXcWdiZmdDUXNTUVZFREZHV3FnZmdmZ1F2dnNnU1c0UtVRi1wyNnSq SGwIWa0LXD04dK+sqHkqrq1AFQNarhBZAXscclF1ehMfXFUcrAxT9HUELKzMAnh1fVJ1dQMrUz+r zlQorCtndWJtU3V1U09oJFO6fkx1UFGv7q+hVi1VHFBzUQwQAl9RBlFSFEBRel9/cn9zaVBsUmtV al1mQWZOa09scmxzGVQXQRdOHXJAX1FZVG9RU09QR1pzAHJyh08wWV1aTVlITklNSFhSV01YR0FG TUdSUVHoUzYQTF5dRF0QRFxvXlFQXl1QUVFPX0BEX1FSX0BPTk7oUzYQXEFAREAQRFxvQUFAcuhT zRBLc3NQWVhYUFJIR1hfXlhBXnR4XV5AQUBfF15Q61KpUEFQUVFAEFkQXlEfXg9eUl7oUp3k8HVR dU7oU88QSn9Bb0EfQS9B30FVQZV0WV5HQUdeQXRaaMxIe3tAbGx7e3tApA1RvUANpg0hUUm0SEC0 QL17QGxAbHtAkJBQb2xvbG9sQGxAbEC9115+UXt7Xi1AlNdYfkh7VS1AlNdYflF7SHteLUCUSFBA vVFAkFBAvVFAkFBAvVFAkFBAvVFAkEoqQKhIf7R7QUJpYWBRDQ1QIQ1RUUNmZWR2d2dxV1ZWV1Fz UVFWRURGY1dxZ2JnZmZnUXZ2d2dSilH4719vHVtR/loCO3Wu5XatsK6pXRceWa4WWWlIegBJUU9l GBhbVRysKFLAZnpibFV1dVUCLKvNVNSsK391ZhF1dVpACwZTiWtyUXVQUlA9r7BV71U8UEBQcVAr EFtNelpcZEx6WlxkReivoONbXGRE6K+cEElaXGQIWghEOFIoXddOVUFlWFNKZVBZRx1U6K+QEF9E cW8QVFFUSXJPHRBcUVzor5DjSktkXOivkBBZR0hkXEpzKjxIex5Apnt7IR25HkCkIVF7HblQb71v vWFgUQ17e3t7VXJ2dmVkQlBjYkZGRURQV1ZDcl5SUkVERmNiZ2ZCZWR2UhD0mjWuUf+CK40rru6Z yP8fPygsPToDPh3JkTdw1rg+jlGTUV8sjiGtrlMiBVVqadaprgTfKi0ZwVJhi9krUFBSr5NQUFV2 VRxQTlB5UUMQM3laXEBvV0RfaXNLc0xoQWtyaHkXURlMGHI3VzhFKUXcRcxZzEX9Wf1F6VmbWY1Z Q1BPeXlRWF5ZTVhXUVZNV0VfRE1FUV5NWF95d094UHFNUE9feVFRT15fRF8QRFxvXl5fd+1TNlBF UE9RD1BNUzYQYnFxV0VSWFdYXnp4X15AdB1KEERcb0oQQltvShBOYmRwSlFQSnBKYEoQSiBK8Eqw SldK6FPPEFp7AF5RXkdeelpo6VJAUEh7e0BseyJArQ0he1F7e7l7QGx7QJBQb2xvQml/vbZAvdde flF7e1UtQJRRQWlpUEFCaXtBQmlpQUJpaUhQQL1RQJBQQL1RQJBQQL1RQJBXQGxsYWBRDVF7e1FT VkVERkdXcWdmZmdmZ0NmZWR2d2dxYkdGRURQc3J3RmNiZmVkdnNyV1IVPkdsOl2tOlsEFkdBcqtK EgdbUkmNMcauha0cCRF72s42CkNMUj+u1gBxfn9SdXVRT3NHJlMNBnV1Y1J1aAjg+q6tDVis2Q03 UlBSUD2uBlXuVTtQd1BoUI0QW2N6WlxkZHpaXGR86K+g41tcZHvor5wQHlpcZH9Yf1x/QGpf1kPX RMZDxkRYWltEQ0BDSl9VVFN+WltyZlpTUFFRcURFRERERURKRVFQU2Z+UVtDU1NeeGVOU2F3RUEQ QUNkQZdTVuivkBBZQUNkVpf/XlFe6lNlUFNT8hBERUVQWX4dEEpRSklpZh1ySmoqPEh7HkCmHbke QKQhHalQb2xApK0NvXtAvXtAvW+9QUJHaVFBQkdpQmnXfnstQJRQQWlRQUJpaUJHaUFpaVBAmVFA mWFgUA1Re3t7e1VXZmNiVGNiZ2ZnR1ZUc3J0c3JXd1F2d3Z2ZWRCUGNiRkZFRFJQV1ZDcl5SUkVE RmNiZ2ZCZWR2UjTgM28HUWwLNAVlaE41rr6AJa6YDBkDQ1Eh0hUOOK9R/YMqjir+rofHNrEfPygs PToDPh3JkTdP8EQEdEZlTCvTE0ZJURVGYBCPJo5Rk1FeKo8o467Xrrhve1V+adaprgTfKi0ZwVJh i9krUFBSr+9QUFVNVRxQdFB/UdgQKEK+cqpyUnNJckppX2FJYUpoTGhxaH8XURhxGH8JXwhxCXg5 XzhDOEs6TD1xKUPaQ89D+1n7Q/p46lmaWUtQdX9/UVhcWU1YV1FWTVdDXUJNQ3BMT01wUVxzcV1/ fXhQc3V9d3V0UFNyUUtMTE9xckRxcXJ/UVxdUeivsBBHTnpkUU9cXURdEERcb1xcXUxxS3J3c33r UzZQQ1B3U1MQY3NwcwBzMHNTc1dDUnFwcFhYV1hycUtTYExHelxgeF1cQHodRxBCW29HEE5iZM9H 70dSR+hTMhBcYQBcUVxHXGBa18NIe3tAbHsiQKYNe1F7qXtAbHtAkFFBQmlCR2lQb2xAbEBsb0Jp DX+9QL1BQmlpQmnXXn5Re3tRe9dVLUCU115+SHteLUCUUUFCR2lQQUJpQml7QmlpQUJpaUhQQL1R QJBQQL1RQJBQQL1RQJBQQL1RQJDXLUCUbGFgUQ0hURMMCOlQUa+i41xAb1zor6LjXEBvUeivpuJB aV/or7zhX2l7e3t7CVFTVkVERkdXcWdiZmdDZmVkdndncWJGRURXVldDRkZHRXFTV3J3RmNiZmVk dnNyV1IcKEpuMl6tI1wyC3asRWQPWlJioZQiGOcqYRkFrgqQcVtZc0jC7DQCREtSxq41B3l2flJ1 dRzUUzYZenh6V3X41NsgFmOuNfUUU3VSxlJuUpjyMDRRUFGvg6+xVPtVO1BkUJUQFmRcb3ZSW3Zb d0t2U3xUcEZ9dn14eX8YfxhjDnY7djl/1l3WXph/XVZCd1B1UXJPeHh2Y2RQZVFsS5l2mndbSk1L r01NTEzoUu8QSEupUEdRR6xEZE1Qr1JNb1GfUVJRT1FRUehS7xBPUKlhrHZxd11cU01XZX1TcWVE S0VFRFl01EBKZlrUeuhSeeNl7adIe0CmvR5Aph29UG9sQGxAvW+9QUdpQmm8pL0NUUANvaS9UEC8 DaS9UUC9pL1hYFENUA0NDVFTc3Z3dnZzclZFREZHRkZFRFZWc3J0c3JWV3NDY05SY2JmZWR2UHd2 ZWRmY2JHRmNiZmdU+yFxW0x62wEeJQHHKQMkjdwGrqt7cmZ4dyl2XQTMNDPVG66lY3W+kAfeA3JN fk9VO65kPBEONicbGt/AI/YxPeg1Y0VOUlXY7zvTCBvaUVg4HQfHjHdHSXVQUFFQ81BQVdtVHFBJ UWMQaUJbWGpSb1ZqWGpFGVgZRQdZN1s3XydaJF7XW/dRXkBEQU1AX1leTV9YWVlPREVERRBEXG9E REVSSehSaBASUFhF7lBSQF9YREp4RURAUxdS/kJvUZBRgFGvUVRwUWBRD1HQUe9RVS9Rz1G/UVNR UP5IF0kQZ0xvMElR0EnASVJJ6K+Q5EpNZElZ6lJ8UERSZOZKWURHREpa6FFK4ctIe3tAbHt7QKZR vX97ISJRe72kfw0hIlETDAgQX1EQRFxvURBCW29REGdMb3t7ewmkvXtAbHtAkFBvbG+tbECsbNde flF7e1UtQJRIUEC9UUCQUEC9UUCQYWBRDVETDAjpUFivouNbQm9E6K+4411Bb0Tor7gQRVxAb1tI W19vWGZAaUVmQGlfRF9Abnt7e3t7e3sJUXFTc2ZlZHZ3UVZFREZHV3FnYmZnUVZWV3NRGFQTN3RS KsGugkluD1mtD1w3DndRfsyCB3dVHK7DTUY4I1isUwV5dn1SdXUd1lOtVS7DUFBRUJCvsVYoVRxQ f1F5EAtZRFZxWXtmcVR5Vn5ceUJ5TXt5a1BqRGhIZ3FsfBxQFl4aRBZxGXsMUAhECkgLezpIJ0LX QthI2HbLSPZC+0iXQrZDTVFWUk1RSU1KTUlQeX9NUEhCR01IVldX6FM2EHJ4eUR5EERcb3h4eU1O Tk9BQkRCEERcb0FBQklISFFRUFJz6FE3EFxaWXhBYHh5eEJBQFfoU88QQX9433jPeP94n3hVf3jA eFJ46lNgUE5SfBBJn0FRb0EQQQBBMEFUQSNgWXhHQUd4QWBa4elTCVBIe3tAbGx7e3tApg0hUa2m DSG9e0BsQGx7QJCQUG+9b2xAbEBs115+UXt7Xi1AlNdeflF7SHteLUCUSFBAvVFAkFBAvVFAkFBA vVFAkFBAvVFAkGFgUQ0NUXFXVldWV1NSVHNyflJlZGdDZmVkdndncVdyVldTVkVERmNiZmdmZ0Nm ZWR3dnNU/VGbWR97FXLkBK6wji6QCmB4/EdpOFtS9FwyN3P9e9QmPMdiEmThX3xPMVUcdVZwYyWt wq6NtxgK1X0X21ICAHd2eld1dQQqrf7FCgIqHxcP4VI3ZXNucUdQUVCjr7FWZlUcUExQmRBgQnhe ekB7QX1LF0QKQQpL5kbmR1lcAk1Y0nJGS0dNRlKhTVcLc0VeRE1FUVJQXl1d6FM2EE1MS0RMTEtM XUxSUF5OXEteXVNMRkVFWFhXUkxZTuhSDhBZXNtdT1LbUElN6lM4UUxQSHseQKQdtK20tFBvb2xA bEBsQkdpUUFCaUFCaUJp11R+e14tQJRRQUJpSFBAvVFAkHtAvVFAkHthYFENURMMCBBJTFpzQm9M WkRcb0xaQltvTFpBWm9MWl9Zb3t7e3t7CVVDZmVkdndncVdyVldTUWZmZWR2d2dxRVZXVldRURB8 U2UXXFJqWxkbVnBSQTdgfG5eUSZgTnwMrFxPVD4zVWdkVXV1CNqtbVI2JwxySXdadXVcR3E7qzlQ UFFQrK+xWFRVHFB/UQEQaUJ5TX1Of3Z/e2Z0Z38ZXxpNGk4fexp+CkMJRQhGCEcLTQtxDHQNdQt7 C3xFU6FNVwtzXTVNWNJyQuhR8xBETUYLc0s1TUfScnYge3dNdk+hTXXoUUMQWXNMXl1ee09NTehS sONfT01N6FKx5l9ffkBfXl7oUzYQXn9+RH9/fn5ffUxeQFBR6FFh5F17XUtA6FFUEF5GdnVHRlhX Unx9f1BZTOhR7hBff31Rff5LT0IAb0AEQFJA7lKdUF1QXlEpUFBQXVJ8EF5TAFH+T1AQUABQU1Dk YOpRklHjUEh7QKQNpLS9QL1Apg20vaQNvVBvbGxsb2xsbGxsQKRsbGxAtkFCaWlRQWlpVNd+ey1A lFBCaWlIQLRBY1FAtEFjY1hSQGxQe0C9UUCte3t7e2FgUQ1REwwIEER8WkFab39aQVpvfFpfWW9/ Wl9Zb3t7e3sJVUNmZWR2d2dxV3NyVldTUWdmZWR2d2dxV3JWV1NRZmdmZWR2d2dxV1ZXVldRc0NR UVsMVGFuX1J0W0tmE1dlUclaVGVtWlJ4WxkWWGRR2jVIQX0QWlE6WWFwfRis82sVrTVPVNhjcWVi U3V1FzGtAFJ/0XhIYWRTdXUXMa0AUk7bYnJIR3VXdXVZSXMzqzJTw6w9UFGv1FBQVktVHFBoURwQ 2HhQeF10RWhQZkUYURlUGVUdVhdzGGEJUgtUK3deRl1nXTddOE1URF0UXVJdTU5NTE5cUFBoenl6 e3lRTE1NTnp7e0tQUFFdaF1caF5WXFdNVkdLSE1Hc3l0TXNjaGRNY1VRVE1VRl5FTUZyTnFNcmJ7 YU1iZnpNXVBUamlnZnpNXVBWVWNLe3voUzYQY2heRGhoXlxOTk95UUR5eVFoe3lOXlxRV2ppaHt5 TkteXFFYY0dGRlZWVVJjYmJzc3JY8OlRTFBIe1BvbEBsQGxvbEBsQGxCR2lRQUJHaddefnteLUCU 115+SHteLUCUUEFCR2lRQUJHaWNIUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQ UEC9UUCQUEC9UUCQV1hAbFhs114tQJRYbF5sV1hAbFhsV1hAbF5sYWBQIQ1RDVFTdnZ3ZXFXVlZF REdDZ2ZnZmVkdndncVdWV1ZXUUNGRkdXcWdmZmVkd3dXVlZFREZHV3FnZmdmZ1I4g2gVGlIHW298 cyj33HdHYWZcUetZYnoTza7DnRcXFlqt91xvamg+qid3aBBcrnpaZXYN2FIjUbzSb1d1dVV4cXcD rrTJL291Tkt8U3V1WUt7wK7hrnPzFl51dVFhdGHQr7k+E05OflJ1dVpHaC5QUFFQ7lBQVexVHFB7 UQgQA3hCeEtqSxl2H301UTRYNV05QiZRJF3GW8Zdyl/LQ8pFykbPR8lI41tEGVAZTFJXXVhNV0dL SE1HdXt2TXVWUVVNVkZfRU1GdE1zTXRNe1Z1X15e6FM2EBhMS0RMXl1LEEJbb0xLXV5eT1BRRFBe X1BRTUxMT1B7RFAQX1lvUFB7UFFmUVJdUVBTXnxMS19eXVFQV3VHRkZXV1ZSdXRYTU3oUnwQXFlQ e0B7Unt7UFlMTOhSfOJQWX3rU/FQXlBeUeHnWVAQUMBQUlDoUp3ifFnh6VFMUEh7eypAog1RSH97 KqFRSX+0eypAsVFIf3tAbFF/DXsqsVFIf1BvbG9sQGxAbEJHaVFBQkdpDddeflF7ey1AlNdYfkh7 Xi1AlNdRe1h+SHteLUCUUEFCaWlIQL1RQJBQQL1RQJBQQL1RQJBQQL1RQJBQQL1RQJBQQL1RQJBh YFEhDVFTdnd2d2dxV3JWRURHQ0NmZmVkdndncUVWVldRU1ZFREZjY1dxZ0ZmZ2ZnUk4iTXlPAltS 21wPB0IIiwR6ZmxbUcdnACSuLwpNEh52W60aWhwMR0BPUgdRvtB/dF91dR1lcQKuP1F+JA90dGZX dXVWbPCtvq6WMUB7aHV1UXtySDhQUa+YUFBVPlUcUEFQ7RB8Y1RReFV4Vnldfl5kXWRf9lH5Wlhd W19aUFFRT1laRFlZWllYUVZSUFpAW1btUmFQUlM2UFhQX1Pw41ta21DoU83iQUFb6FM25UBSWFhY UehSEBBdb1lRX1l/We9Zv1lUWepSslBaUhDiUFBB6K+QEFtKTWRQQXBBsEFTQexRZ1BDUGhTAlBI e0CkDXtsQK2kDSG9bFBvb71sQK20QLRArbRBQmlpQUJpQmnXVX571y2UUEFCaWFgUQ1QDVFRY2J0 Z2NTcWVRc3JWV3NDcVU+q6MBo1F2LXreq7RUXC+kvAR4JFRRVXerc9/1rtJ1VIkpwVEIUFBRr5Wu 11M+VRxQQ1AvEH58UXtSelhnUGhRaFhnWZ9Sn1OfQ1pYWVmJUFFEUFBRU/xSUlFSeEL8Q0NQQnhS 6FKi41FRQEPoUqIQXh9QUVBJUER4UUBQUERa6lPzUTxQSHt7QGxRf3tse0CQUR6kDR29e2xRQL17 b1BsQL17b1BsQL3XXn57LUCUYWBRDVNRcVdzclZWV1FWRURHRkdGY2NXa1GoUeFbcRkWYUuu3U9Y W0ZAZG1brtdWlXVPFAyrWjxyXlteWVZ3UFFQ8K+xUfBVOFBTUHQQXVNQVVJRW1OQUN1RkFLoURTj VDv7SHtApq2kvVBvbG9sYWBRQ3NTUUjYKtZVOKopVddQUFGvTa7XUpZVHFBDUMMQGnhReFhmUGhR b1NoWBpQHFEdUh1THlccWBpZIkIiQ8la+FD7WehQ6FmQUpBTkEKQQ0hYWVmJUFFEUFBRU/xSUlFC eEL8Q0NQUnhQ7FKiUENRm1BRUqIQW1JJUER4UUBQUERa6FGo4WJIe3tAbFF/e2x7QJBRHqQdvaSt e29QbEC9e29QbEC9115+ey1AlGFgUQ1RUXFnY2JmZmdRZmVkd3Z3dnNzZ1KWrliuH1txGRZhS1Ej T1hbRkBkbVtVHKlrd08TDFSmO3NeW19YV3VQUFFQgFLKVAFVOFBWUBrpUFVST+JRVFDrUrpQUVBT UTnnEFQsUvxVcFDoUTnmEFYsUfxwVepR1VBXUUvhwkh7SUCkSr2kSEq9SUpAvaRISr1Qf6xsQL1h YENRY1FzUVGAUcsCUcTPromujlLKUp6tYlJQrlBQUa+7rhZUQa6ZUFNQdBFcUFBRUVBTUFNROVBU UFJTKFBVUahRXlBIe0C0QLVQf61hYFNxRXFFVHariq6Z01BRUKRUQFLVVTtQU1B64VFT6FEW5lBQ i1BRUVHoUUXkU9xSD1XoUVvhgUh7QKa9pA2tUH+9bGFgQ3FDc6RRdjseVTuu9VBQUlB4r7RThVPP UHVQZ1FHEAtSZlFsdGt+G3Tmc1RZZ1F6UHtbeFx7dHp2bVBtdW92bmcaUBtRHnY5Wzlc2EXYZsh1 xWTJZvpO+U9FZnZ0RVR1QnRxSVxXVF9aXIPgW1Fb9FBUVHtCdURCQnV16FPh5lBWehhxV2LoUxUQ QklJX1sQW1Fb9xBfW0JoeHVAde1RIVBUUeJQcFBCr5DlQ2n/QlFC6FIaEEZMWX98QmBMUaBMUUxz aEJHQmhaczhIe3tAbHseQKQNIRMMCOlQTK+Q405fb0zor5DmSV9vTBBfaXt7ewkdvXtApA17Sr20 e2x7QJBQSG9KKrkNSH9AbEC9b71vtNdefntVLUCUUUimDb17QmlQaWlBQmlRQUJHaWFgUQ0hUA0h UVNXVkVERmNiZ2ZnR1ZWc3J2ZWRnZ1ZXVnNydmVkQmdmY2JGR2dXZHd2c3JXVlJFREZjYmdmZ2ZT hZJEU0FZRXVfaXMX8Q1pbHBIJDtuFgwC/NwjNWgUQHQDSUJPT3ETy3NFfX4SZQ5Twa03AV9XXEJw XR9C0idrfXc6AZcDYMcP3VE9PwwRBivgAXRJTm6u1dplf2QaO+xQUFJQQ6+0U5BVO1BGUHZQrBAP XUBRaVBpQG5EbkUZUBZVGV8bQDB40ETQRclewETARfhe8ETwReBE4EVDWVBZQFJfXl1dQFF2R0dQ UVBHUVRHcklFekREJEBHUFB7QF1EQBBEXG9AQF1Eg0UuRkZQUHLoUxUQYFRWSWtbW113eEBdQE98 VxBEXG9XEEJbb49Xr1dScFdgVw9Xz1f/V+9Xj1dXV0p4QOpSf1BHUeIQW11Jd11HXXdaNDhIe3tA bHseQKQdvbQeQKYNIVF7ex29e0Bse0CQUG+9b71vbECkvddVflF7e14tQJRRKkCqSH+0UEFCaUFp UUFCaVdeQGxs114tQJSUYWBRDQ1RIVFTZmZjYkZFQFdWc3J3UWZlZHd2V2d1UUZjYmduUmVkdnNy V1ZXUtf9HzpuKCeU/o716FFiRkRMaVtRHq7sf3ZldGktBBB6FmRzeVU7rfUGaf0hrqKE6zFUdRtM SF5EU3hrqoBORXLirC0XGhR831BQUVBqr7RT0FPPUHhQxhBKBVxRUVBVSE5DSkZAQ0NdVVBQ91Uw ThNdV3boUWgQQVVbUINREFtdZFG7H0ZRRmpA6K+Q43hEb0Dor5AQQFtdZM9A/0DvQFNASnpzfFno r5AQXnhEb+9ZkFlSWUl5czpIex5ApA1Rex29HkCmDXtRex29DaR7vVBvvW+9SipAuUh/QUJpf1FB QmlQQUJpQUJpYWBRDXVHVldWc3J2dmVkQnRjYkZFRFZzcnZlZGdmZWR3dnNyV1ZSRURGY2JmU1VO MQ4t1grbEuJRdN0hIgZlfm1mdV9EcAQaMjg6GRDFoUskZhgd2xn0UW3pNBoTDmx5ZnhMRUJbQBQK rrwsMiUSUFBSUHmvtFQNVTtQfFBsUWgQx3lEeWttZOxk6GpVdlF0W3h9a1BmUW91b3pvexhQF1EZ dTlQ10XSetJ72GvZbMB6wHvBavZR+UPwevB7+WroUedS6UPgeuB76WuaQ4pAul+9QHNcdVFZbFFz ckJCdVNaW1ZaXWx9fkNUdUJbg99aUeBaUVr0U3t6enokdVNQUHt1QkR1EERcb3V1QnqDey58fFBQ YBNPV2joUxUQRkdHWhBEXG9vWhBaUlr3XVtCbXh1QHXoURLiU+NC6K+Q5UNp/0JRQuhSGhBGSlll fEoQX2mgSlFKc21CR0JtWnM4SHt7QGx7HkCkDXsdvXtApA17vbR7bHtAkFBvvQ1Re1BsQL1vvW9s QKS911V+UXt7Xi1AlFEqQKpIf7RApg0hvUFCR2lQQUJpaXtp114tQJSUYWBRDSENUA1RUVZFREZj YmdmZ0dWc3J2ZWRnZ1ZXVnNydmVkQmZmY2JGR2dmZWR2c3JXZ3VRZHZzcldWUkVERmNiZ2ZCVA2u 609AWUFGdWV03flsEUpOLQwWEhs31P3NHHdtdxpLdE5eRVpRGa7UYHBwdRfLckVzcwX1VTur8TlG W0BBTB5Dpm9hfwc2jRlmKiXFUXKSA3B8qQx4SHJTd22t1m1ocRCuLdRgfnAcUSNQUlBhr7RT2VPP UExQeFC6EGxsTwtPB3iGeFRbXVdEW3BTVk9RdldzWHNZY1hjWRpAVlJYUllCWEJZVFlYXE1yUk2F UGBQEFCAUFNQXHXoUuTnEENXWFj3MFXoUWgQRVxbWINZEFtdZFm7XHJRcmlC0EZRRuivkBBZW11k Rjp6Unxf6K+Q43FEb1/or5AQX3hEb+9fUbBfUV9zeXM6SHseQKQhDVF7ex29HkCmew1REwwI6VBG r5AQXnFEb0YQRFxvRhBCW29G6K+Q4nhEb3t7e3sJHb0hpHu9UG+9Siq5SH9vSr1CaQ1/vVFBQmlQ QUJpYWBQDQ0hUSENUVZFREZjYmZnR1ZWc3J2ZWRCdGNiRkVEV1ZWV1Z3blNlZHZzcldWURRZBxkW 3Q1OI4rU99DvURn2BAZ6auA9GSIIMQ0UT0hgbD5RJxF6GwoUBUvbJvA59FEYlgBtGRUOI05Eel19 M8cSTHATKlBQUa7orhZUX1U7UGhRahADkGpRWEtNT01wd1B3ZhtwVnRndGhwamhRa1NrSGhLF1EV ZxVoCEsEZwRoM2jVV9BY117JUMlL+EuAakVSZUJlUlBSUVFmQV5YTUxLSF5KdmMQfHzoUrUQWmZo ZlBnQGdSZ2foUUjjZjBMTOhRSBBIS2ZRUWZKS0RLEERcb0pKS3n1YhNzUGhM6FE4EElNZ2ZmTVZQ W1FwW1Fb9UQTVV9KaXhLSkBQ6FFI5lFL4kpYaV7oUxDjSmb1UehTHBBJb0ofSlLbSsBK8ErvSlRK SWlKR0ppWhoDSHt7QGx7HkCkDSEdrUm0SECmvUC0QLR7QGx7QJBQb620DSFvbEBsQK1sb620115+ UXt7VS1AlFEqQLhIf0oqQLhIfw1CaSpAokh/Sr1BQmlBQmlBQmlXXkBsVWxhYFENDSEiUVNSUlZz cnZlZGZjYkZFRFZFR0ZjYmdmZ2ZnQ3NnRmZnZmZjYkZFRFZzcnZlZGZlZHZzcldWV2NXUkglAsyB 1wUAEmZ9YE5VVlhORWVKQmOc23EbFHY+pMYwB2p7eGRxX1xrbjZuwXNTXq5irumuit0RfHlsfnNw T1VXVUN/E36VU08lUXgWm+Aaa2RtYnNJaFpbXhklrSVQU6/GrhZUclPPUGRQFFACUUHpUEavvBBu W2kBRF9paVxreVJZH1oBUnAEZkb0V7AEVFZXVkZGV0JGcEZVFXMbXHptWRVAd1BTVRJZa29tH21S bW1zYVPoUTgQcVEuZRNhV3NbG2tMXxUAAHtFQ0RFRUMeaUlRPVK7b0lRSehRSBB3EmpVEERcb1UQ QltvX1VPVW9VEFUPVVVwVQ9VsFWvVVRVSgQ/GFEY61FsUHBQQFFsEE53ampgd993/3dTdy5w4l99 T31ScH0QfVJ9JAO8uEh7QKYNIbS0Db1AvUC9DR5Apg0hUXt7Hb20DaS0QL3XXn57Xi1AlFBIb71v b72kvUFCaX8NvVFBQmlpQUJpUEFCaWlBQmlhYFENDVAhDVF7UHtRcVdzRkVEVlZzcnZ3VldWRURH RkdGR0ZGRURWc3J3dmVkZmd2d3ZlZGZndnZlZGZmY2JHRldyV1ZWRURGY2JnZmZlZHZRVlZFREZj YmZlZHZ3dlNIUVpw2nAzkSZPG3wSQVxfSmOcEQkLtqGjIwM9421FTTsuMgc5ndUFEnL0YXJmAWl6 eU5pBGau0A8V2cYtIDfCFFMyPmtlC8oMWVhyRF5fQl1HW3xLdSQCLesAagBtOHhyTHZ5EzZidysC B80yQ1pEcGG2N2FpTGehMnxmrDh1BmIROQttZhR1QlBRUEWvpFRSVTtQZVEwEJtmcW56AnAzcClU 2FhWV3FRBnoFewBnU1BIW3FASHRId0l4cWlQa39vY29kG1AZcBd6FXwafQpZOXI7cypxKHLYW9tx 0GPQZMtbyHDLccl9wGPAZPlQ91H6cfpy+X3xZ+de4GPgZLBneFdRWXFYfV1/YGf2UOBnV359fHx/ ent7UFFRUHtBXlpIS0iD4EdRR/ReZHpjYyR/WV5eZk5zRHMQRFxvTk5ze1BQZn98RH8QRFxvf398 Y4NkLmVlUFB2Y1ZXfHtaR29HEEdSR+hRSBBeQUtbTmZ4c05/fEBe907qU3pQe1HiEF1/sXxJZk5H fEd8Zlo06VMZUEh7e0Bse3seQKQdtL2kvXtAbEBse0CQUG8qQLANSH9vbG+9b2xApL3XVX5Re3st QJTXXn5Re0h7Xi1AlFEqQKpIf7RApg29UEJpe2lQaUFCaVFp114tQJTXXkCUlGFgUSENIlAhDVFR ZmdmZmNiRkVEV1NWRURGY2JnZmdmZ0dWVnNydmVkZ0NmZWR2c3JXVlNTc1FmZWR3dldndVLNrqzX bQvTbGMZSC9BXllcXHB0WUR3BsoVbhZILFxBW3Rv0tIJqFEYRERKZldRHVU7rCuXFjUXHRBmAa4G aENZX1pJZ15MRt46EGB8AVH6fERbQWwrrqmuh1Q6GE9JXkNTeGtQUlB9r7RSM1U7UFtQeFCE5Fxa QWld6K+mEGVAQW5TR0NHc0dvehdPJ08veshc+lzwRvBH/3rmT6pOXkdCX0ZJWlOMwFlRWVlfTEeD wEZRRuhTEBBhX3d6dnYkcV9cXHtxTERxEERcb3FxTFaMUBBfaf9QUVBQdoN3LnhGb0YQRsBG8EZU RuhSexBFSVt4XFdMeXhxQABMUUxHTHlaczhIe3tAbHshe2x7QJBQb2xvKrkNSH9ApL1vDXu911V+ UXt7Xi1AlFEqQKpIf7RApg29QUJpfw29e0FCaVBpaWFgUQ1Re3tRYkZFRFZzcnZlZGZDU1ZFREZj YmdmZ0dSc3J2ZWRnQ2ZlZHZzcldndVGAbgUGbWwGBSudQUJaQUF9b3LH+hEdQdtEdnFfRV1RA1U7 Bm1tBgZtbQauZK1pbUNbQ191MUSuqRlodWlRjhVzRnJReGdQUFKu6q4WUjVVO1BbUGBQoBDac112 QHN2fH9jXWN2HFwWSxp3GXkcfhx/BEs5XDt1OXk/fj9/LHXcddd3RV1eXlxOcEhydEtfXnZxS09/ en5+JHleXFx7eXZEeRBEXG95eXZWjFAQX2n/UFFQUH6Dfy5gYFxXUEhRSONyE0JfdmF4eXZATz1F 40v0dlOMWXBZYFnvWZ9ZVFkueeJe6FHiEFsQdlF24nl2R3ZhWuhRf+EDSHt7QGx7QKQNvaQqqA1I f71Arr20e0Bse0CQUG+9vSFvbECkvW8Ne73XVX5Re3teLUCUUSpAqkh/tEFCaUFCaUJpUEFCaWlX XkBsYWBRDVFiRkVEVnNydmVkZkNTVldWVnNydmVkZmNiRkVEV1ZFREZjYmdmZ0NmZWR2c3JXZ3VR gW4GB21uBwfChRICae81BAETZHh+S1tdXXxwRmicRnx0W19bUQFVOwdubQcHbW4HrmSsvaHcMjcS enoRe05NTVxWV1ticYdTUgNFRHVRdmdQUVBcr6JUS1U7UGJR2RCDeXdtdwd26XdUWnNYdVh6WnxU e0t7TXtOf2B/YWhQYERoem9gb2EYUBdRGUQWdxh6HGAcYQlGDWANYTxgPGEtYC1hxXbkROdG5nXn eE1fYF9hT2BPYVR6eXl8U1JSUURERXZ3d0FRUVJ3eHdBeFBBRFpyelBceHZSUU5JTVNacnZQelNc W0hQd3ZSUVRkY1JRUTJ3QUR3UVB3QWF6YGC7fDBQeHh7eXxEfBBEXG95eXx3UlFTW3Jgg2EuUFB4 XYNcXFqDEFtWeXhaeE1QTUBNcE1TTehRSBBfSTByW3x5QE6DTRBdelxN6lESUFxSEeJbelroUqMQ WzB493lJY3lHNG1Ie3seQKQdrUqupL28QLRKQL17QGxQb0oqQLgNSH97b2xQb0q9bEC9e29QpL1B Qkdp11V+UXt7LUCUUUoqQKhIf7TXWH57Xi1AlFFBQkdpQWlBQmlBQmlQQUJpQmlpQUJpe0FCaVBB Qmlp11hAbFiU115AbFiU115AlNdeQJRhYFENDSFQDVFRZ2dmZ2ZlZHZ3Z3FXVldWV1ZXV0NGR0Zj YmdmZ0dWV1ZzcnZ3d1dTc1FmZWR2dnNndVLLrry1HHFdWHgdW1HHWhh9c2MccXxtc0FbX3NgV1x1 Gw5vY2MUcmI+NK9RHEVEc2RZUQRVO6wehBRySF9dRUxVdnZBRkF3a3B5rrzwSV8CW0RH3BlhGcuz Mq75VDkYSUdNXnVqUFBRUHGvtFLbVTtQTVClEBRQEEFMb+lBUVlHUVBbWUZAW0BcdVtyXGpQZ1Fq R21LbUxvTxpQGFEXRBlFJ0UvT/tQ90X/T+pQ5lLnU0hTWltWX1uDWuivkBBHQkhkWhBfRG9aEFxE bxBawFrwWuBaVFroUxAQF1NMektLJEdTUFB7R0JERxBEXG9HR0JLg0wuTU1QUFpvWhBawFrwWuBa VVr3X1tCTnhHQFP3WgBCUUJOeABCUUJHQk5aczhIe3tAbHshHntAgCF7Hb17bHtAkFBvKrkNSH9v bECkvddVflF7e14tQJRRKkCqSH+0QKYNUXt7e71QQmlpe2lhYFENIVANUXtRUVZFREZjYmdmZ0dW V1ZzcnZlZGdRZmVkd3ZXZ3VS267lTUFaQkBga3cPDG8XEh5IUV5GRUxpW1EBVTuryjRJXUJedw1C yBF8F2J1AlPKHElIXkRTdmtQUVBHr6VVnlPPUABRmBD9Qm4VKl9SCX0HfglsBRa/AlVfAo8CUlB0 QHR2dHZ1Z0hmZ2cYF0gWdBZoFhUXGAhFDR4NHydcKGzXadcU3wLFWMVEx2vKbMAC9Fj5XPZE+X35 bOdJqmyoFnEVFhZQXFFQF3RNSnN3WlxnWWpRUBZ0g1RzUZRzhHNSc/RFSkpmen9EfxBEXG96en9Z amp7a25EbhBEXG9ra25QFhZ7FxpEGhBEXG8XFxoegx8uAGPrU1BQQlARU1AQeUJWAFZQVxcWFmtr alp4c29zEHPAc/Bz4HNVc/d3W3oBeH96bmsaF0AC6FMZEFtK91R6UZB6hHpSeuhTehBZavdUa1GQ a1Fr6FN6EEYW9xcfeh67GuIXSQF6R2tHF0d6AVo06VMZUEh7e0Bse3t7HkCkHaSktEC9pA0hvaQN Ia2se0BsQGxAbHtAkFBvKrkNSH97b2xAbEBsb1BsbEBsvUC9QKS911V+UXt7LUCU135Re0h7Xi1A lNdeflF7SHteLUCUUUimDSG9QUJpQUJpaXtBQmlQaWlBQmlp114tQJRhYFENISJQDVETDAgQXX1a QWltTkFpGkRAaRfor7ziQGlI6K+I4l9Bbnt7e3t7CVFTZmdmZmNiRkVEV1dmZ2ZnZmNiRkVEV1NW RURGY2JnZmdmZ0dWVnNydmVkZ0NmZWR2c3JXXlNXV3NDZmVkdnNyV1ZXU3NDZmVkdnZzZ3VSc9DR awchaRFqS33SaQgRfWNlF04/SV1YW1h0eFlCchX1Fm0aSSFHXlddXUMfxGlMba3rX11XdQAqNAGv 7ExAdGNaUQVTz64ClhU1bh5/YQ/xmBI2dEoXaRA2rtsDSFheV01oXElG0SgTfXsHUdYBRFddVloE iSoxnlLdZURXXDHGg66xUtMPeEBHXXZrUFBRUEavpFRTU89QZFFuEMdCbXkpVFIIcAN6AGZTW3Bb fGBmIGZUdUhnXBdcFnkMYgxjN1jGWMl89lj6fOdesGZdVEhESFJ5enpQfXx7e35eR0paUXlReVB6 SINH9FleXmZNckRyEERcb01NcnpQUGZ+e0R+EERcb35+e3VjVlZQYoNjLmRkUFd7elpHb0cQR8BH 8EdUR/dKW01leHJNfntAXveUTVFN6FN6EEJ7Y3piu37ie0llTUd7R01lWjTpUxlQSHt7QGx7ex5A pB2kpLRApA29e0BsQGx7QJBQbyq5DUh/b2xvbECkvUBsQL3XVX5Re3stQJTXXn5IUXt7Xi1AlFFI pr1BQmlpUGlpe0FCaddeLUCUlNdeQJRhYFENDSEiUA1REwwI6VBcr7LjX0FuT+ivvBBfX0FucU5B aX1OQGl8Tl9pe3t7e3sJUVNmZ2ZmY2JGRURXU1ZFREZjYmdmZ2ZnR1ZzcnZlZGdDZmVkdnNyV1ZT U3NDZmVkdnZzZ3VSTywtbgvUamQaSNBAX1haW3N0WUR2w/JuFkgtXUJcdmba0QKv60tAdGJbUQFT z64D7BU0GB1uaACuBWhBWkBYTWVeTEenEGB6A1H7ekRbQWTUrquuh1LSD3hBR112a1BSUGKvtFOS U89QX1BwUOcQcWRDa0xSMHLQcvBykHKAclVAa1BXSGtYW05qQlQQYmVkVOivkONfQGRU6K+QEE5b XWTPVO9UUlQ4ckVqQlsQY2Vkz1vvW1Jbc3FzOEh7HkCkDXtREwwI5VsQQltvW+ivkONxRG9b6K+Q 43hEb1vor5Dic0Jve3t7ewkdvR5Apg17e3tREwwI5VQQQltvVOivkONxRG9U6K+Q43hEb1Tor5Di c0Jve3t7ewkdvVBvvW+9YWBRDQ1RYkZGRURSVHNydmVkblJHcldWUkVERmNiZ2ZmQmVkdlLxH9sX 5a6IxtjFP/uOHmVzFuBodndOfNACYlPPGdIf8q7s6/Il26PlIWVPb65h6n5sSHSrUX8uZGlQUFKv Vq4aU5tTz1BzUGRRdORGEF9pc+ivkBAIX2kbU1EWQwZDBkYARydM10TGQ1dTdGRAQFJTQHRkQUFS ZGN0U1Rgd2R0QFNUUkFHekZGu0FIeklJmExQenNzu01SQUFmTE1ETRBEXG9MTE1zg1AuUVFSYOhT FeRWVlJXQOhT4hBmdxNdW0mDSEaDSEdeTGV4TUxAfXxZEERcb1kQQltvz1lRcFlgWRBZMFkgWc9Z /1nvWVhZOGZS6lHrUE1TGOVlTEdMZVroUxjhOEh7e0Bsex5ApB29HkCmDSFRe3sdvXtAbHtAkFBv bL1AvW+ttW9sQL1AbECkvddeflF7e1UtQJRRKkCoSH+0KkCoSH+0KkCoSH+0QUJHaVBBQkdp115A bGxsLZRXXkBsbGxhYFENUA1Re3tDdWNXZmZjYkZFQFdWc3J2d1dWRURGR1dxZ2ZmZ0NmZWR2dnND RkZjYm5TZWR2c3JXVlcsURtsfTnWEg42l+CAdWR/ZEx8AVmttloQBXWkS0BwaPdOYHBwbQoDYmd3 c099bVM3aPMwE8E5rrGOlF5I5DJjcHVddXVSHtFTGQ53QUdarXdhcXM69oMwHRZCShdQUlB3rhpT jlPPUHNQZVEcECdZEF9pfEJ8YXRiHHL1Q1XgZ1FwWXBae2FoUGVTZlViWWJaYFtlX2d4aGIYUBRT F1UQWRBaCFI4UilRKVLDYMBn9njoQeZg6WG7XrBnTQpBCmENY1MLXz1eLV7fXvpA+nNWQHJzQXJz c0FBckVydH5BY3NAWnpZWehRSBBPU1t6XFyYQFBTU2ZAc0RzEERcb0BAc3QYT1dzUFZ4fuhTFRBD RVtcXINbWVmDW1peQGZ4c0BAU+tR4lBfUECvkBBcXkdvT0BRT0CPQFJA6FN1EEBnWdBnUXp8SXNm QEdAZlpz6VHIUEh7e0Bsex5ApB29DXtAtA0hUXtRQL17QGx7QJBQb2wquUh/KkC5SH9vvXtvUGxv vddeflF7e1UtQJRRKkCoSH+0KkCoSH+0QUJpaVBBQmlBQmlXXkBs115sLZRRIWFgUSENIlANUXtR UVZXVkVER0ZHV3FnblJnQ1ZXVnNyd3ZlZEJmZ2ZjYkZHZ1dyV1ZXVkVER0ZjYmdmQmVkdlOOrolO VllJcRdbrb9aa2l8TNUgMBoZGXxrJ5MzYm9uHV9293R1EhQCRkBJc3ME8WdT06xdOEt8Tk9ES1Z1 dVl1BzhRlZAXZmYYK9FRS4ljShgCLnRxa/6GK2RNRXAbUQ49FRZQUFFQc1BQU2hTz1BxUWoQFUJ4 WlFwT2BzCFMHSThTNkQ2RjZJKFMnRehSk1CTcV1GR1BRUUdKS0xTSVBHR2ZISURJEERcb0hISXFX UFdPXH9cb1xTXOhTexB+QGpVT4NfcE9wwHBTcHBQSHFVV0haSUhAQs9YUQ9Y71iPWK9YVFixUFEu WVDiR+hR4hBESHB6YE8QT1JPu0n1SElySEc0bUh7e0CktKQNtECttHu0UUC0DSFREwwIEERYEH1H b1gQQ3BvWBBeR29YEE1Pbnt7e3sJe0BsUG9vbEFCaX8NvUC9vQ1vb9dVflF7ey1AlFFBR2lBaVBp 116UYWBRDSFREwwI6VBQr7jjdkdvUOivuONzQm9Q6K+Q419Jb1Dor5DjXkdvUOivkONbQm9Q6K+Q 40Rcb1Dor5DmQ2lLEF9Abnt7e3t7e3t7CVFTQmdmY2JGRURXVnNydnZzcldeU1dzQ2ZlZHZ2c2d1 UbXH6g5nbXpkf051eHhAWVpbRhc4amSi9UJDcWRZUX5Tz62eUcsPaG1oMRJ6Gl1WXA2Kx4RSxxpI S05eTRJQUa+rr7RSplPPUGNRVhDaVltWXVp4VntUf1J6VHZcemFsVGt1bGEbVBthDFQMYTtUO2Es VCxhxWH1YeVhpWFDkGVRSXZzU3ZAfHxqfGBlGnz3UFh3dVpcVHBLYVFhVX1GcEJ3WHpcXnNJQktM UExATHBMU0x9UVJSQmNVa31XcBNCW2ODUC5fUk9Sf1JTUoNRLnNpQF4fXlJe6FGcEHx6SYNKLkyD UEtAS1JLu1hpX3qfelJfeq96Ul96T3pgehB673qfeo96V3pJZOpT9lF8UEh7HkCkDSEiHb2kDb2k vUCtDb2svQ2kvVBvvW+9bEJpf2xBaQ1/bEBsUUFCaUFCaVBBQmlBQmkNQUdpYWBRDSJQDSFRU3N2 dnNyVkVERkdGRkVEVlZzcnd2c3JWV3NDY05SY2JmZWR2d3Z3dmVkZmNiR0ZjYmdSpnx1WNMbfmxK fc4UAM8GagVoTElMQXVhcHNtNn9nGH8FJXVKzd5uCn1Ld0hTz66bKNpmdnBoYPrQGR/dBUdAX0hR HSk3bRVgfwgNLxViEDzARltxUFFQeq+0UtFUw1BNUTfpUFWvsuJDaVXor7IQ119peUpmSlJwUnBT cl5wX3JAdEx0TWBSYFNnQBBSEFMUXxNAH0kfShJNB1AISAtJC0oHTTZQNVI1Uz9JP0owTDZNJFIk UytJK0ovT9RS1FPVX9tJ20rAUsBTx1XKSvpT/0nmUuZTllCUU5ZNg1CDTbNSs1NmUVRXV1BfWl5C S1BKSUhNUEVJSehRSBBfSDBTAF9RX4MQw17wXlJe6FMQEE5XMFdQUHtIRURIEERcb0hIRW9eEF7A XvBeVF73QknqUThQU1E44lFNUOhREhBAUUJbUVZFTnhIRUBUmFf3ReivkONCTm9F6K+w42ZnZEXo r7AQX05hZEXqTllFR0VOWnM4SHt7QGx7e0Cme3tRe1GttHtAbHtAkFBvb0CkbEC9vUC9DddVflF7 e14tQJRRSkhArg1KrQ1iSipAuEh/QUJpQUJpQmlQQUJpaddVLUCUlGFgUQ1QDVF7e1FTY1dzU1ZF REZjYmdmZ0dWVnNydmVkZ0NzZ2ZmZ1IeANNz0fdAQltBQn5tcxX2ABQbSs7YRNDgLFTDrqAjrexm TF1DXnMHRiggFWVqC1JNGn8u3FBQUVASr7RUcFPPUGNRKBDWQhJHUQRRCVxSclF0XnNIcntpW2Rl F1EXXgpaCnA6WjpwK1orcMlQy1rGXvlQ+lr2Xvl36kzne4ZehEC5W7RfS2BlUVtaUEhNWkBIVEhD QEdKU1xXcFBKWnBOT1tUXE1Ig0f0QGJ6YQ9hP2FSYS57XUBAZk1cRFwQRFxvTU1cU1BQe3t4RHvo r6EQTkZdb3tIRFxve3t4R29HwEfwR1NH90phg2IuY2NQXOhT4RBHXVBXXVZXmHV1Slt4TWR4XE17 eEBA903oU3oQQFP3eOpkTUd4R014ZFpzuEh7e0BsbHt7QKa9pL17QGxAbHtAkJBQb2xAvW9vQLRA bECkvSpAuQ1If9dVflF7e3teLUCU115+UXtIe1UtQJRRKkCoDUh/tECmvUFCR2l7QUJpQUJpQUJp UGlpYWBRDSENIlANURMMCOVwSEZdb3Lor7LjQ0RuQOivsuJDaVHor7zjX0BueuivsuNfQG5e6K+y 4l9Bbnt7e3t7ewlRU1ZFREdGY2JnZmdDZ1NWRURGY2JnZmdHVnNydmVkZ2dWV1ZWc3J2ZWRnQ2Zl ZHZ2c2d1UkySXldYW34dPikLrZBIX1heXXRrctv3bhdJYdJrCitoZR1JIUxAdWJaUQVTz60If0JZ VVgCJ49RYlmtPARcWEFcTQhIq29jZgP57RIzEh5sYwZRwDJyX0dddmtQUVBtr7RT3lPPUHNQqBAY QntCe3EaQhpw0HX/depV4HWAdVlzRURTWlFAXlBzR1BAUUNHTl9eXlFeQEB7UVZEUUBBUVZcg127 Sl5XUVswTlEQTlFOahBH6K+QEEJEXG/QR8BH8EfgR79HVVBHUUfoUxDlQF0vXFFc6FE+4lYuQOhR 4hBHcABRUQBRUWBREFEAUSBRkFGAUbBRV1HqUx9QdFJ24TpIe0CmDSEiSkm9SLSmDWxJQKYhDVF7 Ski9DSJQb29spL3XWH57Xi1AlFFCaUJpQUJpQUJpQWlQQUJpQUJHaWFgUQ1REwwIEERQXnhEb1AQ RFxvUBBCW29QEEFab3t7e3sJVXNmZWRSd3Z3dnNyV2V1QlNmZmVkdnZlZGZjYkdGRURWVldWUU50 U3NGQUxDTkFIUR00U8M/FUEUZGdOemEnGdZMAnoiUf8YZUhAVHQJrr+uBtz+an4PeEhkFnNhExXV 5RrYUFBRUGmvtFUeU89QelEFEDhCS0ZEeVJbQ1tGVHlTcEZ2cnB5ZHnQefB5VnlSeUN7R35IfXF9 cn16YUdrehtTG0MWchV5HXoKeQ56OXopetVH23rIUspDz3z4VPlC/3zseu98TFt6UXlIelZXVFRB Wt1GelBwekZHR+hTMhB4SHpESEh6RkVGR0V7UVBEUVFQR3lKelBGUF1XcYNyu3NXSEdHRFtycehR PhBBSBBBUUFqWiBaUcBaUR9aUVror5DjQkhkWuhTEBBaUS5Q40UuEEZRRuhSDBBbfHdqIErQSvBK U0roUT4QWnBIIEjQSPBIVEjoUT7jexo6SHtAtg2mDb1ApA20raQqonsiDSFIf70NQKZsUG9sQGxv pL1vbFFBQmlBQmnXfntYLUCU11V+SHvXLZR7QUJpQmlp11SUYWBRDQ1QDQ0NURMMCOlQea+QEF1E XG9HEERcb0QQRFxve3tQewlRQ2ZmZWR2dnd2ZWRmY2JHRkVEUlFzU1FzQmVkd3Z2c3JXZXVGR0ZF RFdRUyEaxwxEbFRXFmVlT3yErtZ4bq4Ae19BWmNOQElRCExaQVRR01PPrRLF/WpGfB5aQ0tjF3Rk FD+uyK7oUjatylFGos4WeXpUdQseFTrdYjZSclBRr/OvtFRBU89QEFFA6VBqr7gQIl1Bb210G3cf aMdQzHbNavp2+WjsduxomXaaalxGUGdQUkt3ZHRsd2xnGEUbdB12HWkMdgh3CGgMaQhq2XbZaMhq yWzqRpdqmGuJR0VXRUZFUmp2amh2e0VTREV2d0VTU0VqdlRRcmxqY3ZfRVNRWFtQQepTUFBeUVQQ XFhYURCDUFAuUVdNTe9RSFBJUfdQclBgUVRQZFNQEF56enJbb30vfVJ9mBB6UOhTOhBEW02DTi5b EEJbb3BbEFsgW1NbShLoUazhbUh7HkCmDVF7HaS9QK2ktCFQb2xAvb1ArSq4SH9vKqBIf71AbEC9 vVFBQkdpUEFCR2nXWH57WC1AlGFgUSENUCENUXtDdUZHZmdmZmNiRkVEVnNydnNyV1ZXQkdGY2Jn ZmdHVldWc3J2dndeUnNydmVkZmNiR0ZjYmdmZ2ZnUnd2c3JXDVEND3cyYhMHYWdra3xwA0B6dmQc BWNOT0pDTWx0CAQQbhAFEn0l1QhiZG0SY0tyYkZNR05+TBswZnJkS3dTM2zF48FqHn9sY2BtR055 1q6EEnddRQRF3mp9adHexdl6bGBjEkBIXF9iTzVRNBZ9WFBRrxSuFlPeU89QaFCwEGVySFF6WXtI allqSGlKaX4dSBZ3ClgKSDlINXcpSNBq4GpfWV9FfXlXSFF1aINQu0JRV3X3eehR9xBPT19JV1tF X3d4cn1RUlNUVVZWYWB/flRXYhBFUUV8X+ivkBBGRFxvb18AX1JvX99fwF/wX+BfkF9WX+hTEORX H3JRcuhSphBJfXpiUGj0V/dfYv9iUmBiP2IgYtBi8GJVYuhRPuNpczpIe0CmDSG9pmxApLQNQKYN IVF7vQ1BQkdpR2lBQmlpQUJpQmlQb729b2ykvUFCaWlCaVFBQmlhYFENUA1DdUZHRkdGQ2ZnZmVk dnZlZGZjYkZFRFZXUldWVldWc3J2ZWRmY2JHRmNiZ2ZnZmVkd1N2d3ZzcldoUWR1X0tbRVg72nox SBlkZwEb2uH6PdYYe3ppARlhbWNyRkdGTmZWWEFZdEx9QUVTFQp+eRctpq653bgWbncWd09iGgRp E+GHrr2Z0CFxQwBnZxwQe11Aai0QBsxRLTl+clNQUa+3rwJTeVPTUHdRfORQEERpcOivkBBtREVu CEYHScZf5FNUX1tfXFlfDHdUdVF3VHVwdXZoUB9QF1QfcRV2DFAMcQF1DHc1dDV1Oncqd8Bw+ndD duhRRuVycqN1fXbor47jRFxvduivjhA4QltvdlVbSlddcFRBTXdPSlN4SFVUU15RcXBwMlFQRFFR EEJbb89R+1HrUVNRUFFBcVByVxNH9UpBkk1yEF9Eb3Ljd3dQVk1acFpKWlFeeM9xUXFaXmlaaUQQ RFxvRBBCW2/PRP9EUkTor5DlW11kRCh56FF/4W1Ie0Cmew1Re3u9vUJpDUFCaVBvb29vbEC9UHtA vUCkvUFCaUJp11UNUXt+ey1AlFFBQkdpQkdpUEFCaUJpQUJpaUhRflF7e728UEClYWBRDSFQDVF7 e1FRRkdOUmNiZmVkd3ZlZGZjYkZFRFZzcnd2d3ZzcldzUXNyVldzQ1N5rZgQT3h0fkhATFxYF2J9 bcg/0CtiT0JMSE0QUhSACR9zewNT060xQ3Zil2VNQkN7TUtoHBNmA9gmf0FZQVLgfBBRb1BRUNiu MVOHVTtQeFDREHB1VmZTZlYbdlRacdxwcFBE/EVCUfxQU1qGcFB/USxUVehR4eJ0f1ToUeHndSxx RX9E3UHtUT1QSlBeUT1QTVFTEF1Kf3F/EHBRUHAQcFJw7FMoUHlQO1E6UEh7QKYNIbSkpL1AraS0 QKS9pL1ApLRAvVBvvW+9Qml/vWlhYFENUVdeUlJWVldWV0ZHRkVEUkVERkdXVnd2dmVkQmVkdndn blJCblJTh10MKWRfEC0baSUpYBvxbgNdMmQGD/sWG0EGLBBdbMXpVTt9QQUorr/dKXZMTnl+Fzkf rocaaBZBf1FCTSsFA1FjAmkcXG1eCdxRStTbFVBQUVDPrhZRcVU7UFNQZxBdU1BfUlFTVUdHSlJS U+hT9uVQUFFJVFXoUWbjcTv7SHt7HqRsHUCtbB5AFTUUtlBvbG9sYWBDQWNBz9KuFld1qItQUFGv Iq4yUpFVPFB4UC4QcHhTeVZoU2hWVFpw3HFxUET8RVNR/FBCWoZwUH9RLFRV7FHhUHRTyVBUUeHn dSxxRX9E3UHtUT1QSlBeUT1QTVFTEFpKf3F/b3AfcFJw7FP3UHpTKVMmUEh7QKYNtKSkvUCtpLRA pL2kvUCktEC9UG+9b71CaX+taWFgUQ1TZ25SQmZmZ2Zndnd2ZWRCZWR2d2dmR0ZGRURSRURGR1de UlJeUt5dDClkXxAtG2klKWAb8W4DXTJkBg/7FhtBBiwQXG3F6a4yfkEEKVFB3Sh3TE55fhc4H1F6 GmgWQX5RQU0rBQOunQJpHFxtXgndrrfU2xVQUFFQd1HSVDhSllBKUBrpUEhRUeNUYV1Z6FFR5kBw XdBdUl3oUegQREBhUExHR0pQ3FFc3FEiXUlLDjlIex5ApB29vUC9HhU1FLZQfx20vVANQL1ApL1h YFFjVlZzcnZ3dnNyVldzZmZjYkdGR0ZHRmNiZlR/aVbJPmUnm8IRFAtBaljDOWVjNeIwY05zFzFS lc/0cgVtAzD0z15NHHpeWA5Qr6+v3FBQVZVWn1J2UHRQUFFXUN5S31HcUEcQXFJTUmp2zhh3UlNS aOlSmFB5UHtRe1Cvr6/cUFBVElaRUnZQdFBQUVdQl1ICUX9QdBBfU1IfZA9kP2QvZN9kVWRC6K/g 5xh7UlNSZ1B5UHtRew1lZa+vUNau2FWUVTtSdlB2UFBRV1CYUT9QUFBCEFxRUXddbBh3UVFzWHlQ e1F7r6+v6FBQVSBWq1J2UHhQUFFXUN1R6FHAUHYQQFF/YW9hH2E/Ye9hr2FWYXnorljkGHtRUWTp UphQeVB7UXsNZa+vr+6voVYtVuxSdlBhUFBRV1CWUaRRIFBJEFxRb39Rf1DGGHtRUXjpUphQeVB7 UXsNZVCvr1A9r7BV71bmUnZQYlBQUVdQ3lJDUSNQRxBcUlNSZ1gEGHdSU1Jk6VKYUHlQe1F7UK+v UJCvsVYoVuZSdlBoUFBRV1DeUYxRI1BJ5FFSUhVN6FGS5Rh3UlFSEulSmFB5UHtRe1Cvr1B4r7RT jVU7UnZQFFBQUVdQ3VDwUFBQcBBZUh9oUX9oUWh16K+55Bh7UlFr6VKZUHlQe1F7IQ1lr69QeK+0 U4VVO1J2UBRQUFFXUBNQ51BQUEvlUh9pUWl16K+45Bh7UlFr6VKZUHlQe1F7DWVQr69QeK+0U4VV O1J2UBRQUFFXUJVQ+lBQUEsQXlIfac9pUml1NBh7UlFt6VKZUHlQe1F7DWVQr69QeK+0U7RVE1J2 UBRQUFFXUN5Q/lBQUEcQXFJTUh11TBh3UlNSGulSmVB5UHtRe1Cvr1B4r7RTilUcUnZQFFBQUVdQ llD7UFBQTedSHxMPE1ITeuivLuQYe1JRbOlSmVB5UHtRew1lUK+vUHivtFOFVcJSdlAUUFBRV1CX UPpQUFBJ5FJTUhFx6K/v5Rh3UlNSbulSmVB5UHtRe1Cvr1BqrthT0FPPUnZQFlBQUVZQmG9QUEIQ XFFRfnOqGHdRUXpYeVB7UXuvr1Bhr7RUGlU7UnZQGFBQUVdQ3VFdUFBQR+NSUXlD6K+C5Bh3UlF8 6VKZUHlQe1F7UK+vUGGvtFPZVTtSdlAYUFBRV1ATUN5QUFBwEFlSX3pRb3pRekPor9bkGHtSUXzp UplQeVB7UXsNIWWvr1Bhr7RT2VU7UnZQGFBQUVZQlSVQUEkQXFIgelF6QygYe1JRfulSmVB5UHtR ew1lUK+vUGGvtFP/VRNSdlAYUFBRVlDeKVBQTBBeU1KQblFuQ1oYe1JTUmvpUplQeVB7UXsNZWWv r1B9r7RStFU7UnZQlFBQUVZQ3fdQUEfjUVFNUOivhOQYd1FRcOlSmVB5UHtRe1Cvr1B9r7RSfFU7 UnZQlFBQUVZQE/dQUEvlURBOUU5Q6K/c5Bh7UVFw6VKZUHlQe1F7DWVQr69Qfa+0UuhVO1J2UJRQ UFFWUJX2UFBN51EfTiBOUk5D6FHA5Bh7UVFy6VKZUHlQe1F7DWVQr69Qfa+0UrBVE1J2UJRQUFFW UN76UFBJ5FFSUmJQ6K+I5Rh3UlFSf+lSmVB5UHtRe1Cvr1BGr6RUU1UcUnZQAVBQUVdQllD6UFBQ SxBeUW9uH25SEHr6GHtRUWnpUplQeVB7UXsNZVCvr1Bir7RUUlU7UnZQAlBQUVdQ3VCVUFBQRRBa UlFzUEQYd1JRc+lSmVB5UHtRe1Cvr1Bir7RTklU7UnZQAlBQUVdQE1D8UFBQRRBaUlFzUHQYd1JR c+lSmVB5UHtRe1Cvr1Bir7RTklU7UnZQAlBQUVdQlVD6UFBQSRBcUm90UXRQ+hh7UlF06VKZUHlQ e1F7DWVQr69QYq+0U7RVE1J2UAJQUFFXUN5Q/lBQUE4QQFNSf2ZvZlJmUHgYe1JTUmPpUplQeVB7 UXsNZWWvr1Bir7RTilUcUnZQAlBQUVdQllD7UFBQR+NSUX1Q6K645Bh3UlF16VKZUHlQe1F7UK+v UBKvtFRwVTtSdlAIUFBRV1DdUPZQUFBL5VHfZFFkW+ivt+QYe1FRZ+lSmVB5UHtRew1lUK+vUBKv tFRwVTtSdlAIUFBRV1ATUO1QUFBH4lFlXOivKOQYe1FRZ+lSmVB5UHtRe2VQr69QEq+0VHBVO1J2 UAhQUFFXUJVQ6lBQUEvlUXBlUWVa6FFy5Bh7UVFp6VKZUHlQe1F7DWVQr69QEq+0VHBVE1J2UAhQ UFFXUN5QxlBQUHIQQ1FSLxnfGVJvGVEZULUYe1JRUhbpUplQeVB7UXsNImVlUFFQ4a4aVERVPFBt UM8QElBqVG1Aan9Te319Z2ZSb1Vsfm9nYmplbVwzalFgQGB5YHpTUFFBWVFQVF1DWFZTU0VHSnVq ZXlhb3BgYVplVvx1RehT/eZgWlFaCHpA6FFZEFtNUGUJZwlHmnCaSupRU1BdUW/mU1Nub5ZiSHtB Qml/tKStrbW9UG+kbL0NpGytbEC0UUFCaWlCaWlBQmlCR2lBR2lAmWFgUA0hUQ1Rc0JDZmZnXlJz cnZlZGZjYkdGRkdmZWR2ZWRmY2JGRURWV1ZXZmdmZmNiRkVEVnNydnd2d1ZFREZHVldSUVV1/1ke Fk9pfPRgemcRe3MLEW5uXV4FbWNv9lleSmZHQPFkeGZuYGH5V0VmVkhzPjfUrhpSxFHDfQQHVl0a Z35kE3VLQVgAeUwqfgs1bX4EiF9GEVdXVRZofmluG1JXWmFxeBRk/quu61BSUORS5FM4VThQW1BH UBjpUFZRUeNPQlFC6lICUFxRUeJQVUXoUVEQWfBT4FNSU0pJX+hRURBbcFkQWVJZSUjghEh7HkCk DR29HkCmDR29UG+9pA29YWBRYkZFRFZzcnZlZGZHclZFREZjYmZlZHZSXsCam9/fm5rACi0uCQku LlU4msDfm5vfwJrSLgkJLi4JCS5QUlA9rtNT41V3UH1QZVF0EAkZSxlMUnlQe3V2eXp9dmEYUBh9 DEUMfjhFOH4pRSl+XVFFRnBxcVBzfH5lfX1yRkt4ZUh+XlxTRVhfW1Vlc3JxVGNQcXEycn1En3JR cnJ9TIMQS0v3cDBQfehSbOZReFhYcFFF6FPhEFtDhXx8UVdysXN4SOhRaBAQc3BbcmZ4fXJASz1M uw9bUX9bH1sPW89bn1uPW1ZbanBVEFVSEFWQVVJVSmdj93B3YHcQd1N3SWZyR3JmWrw4SHt7QGx7 HkCkDR29HkCmIQ0dvQ0hpLR7QGx7QJBQb2y9e0C0b1BsQK20QUJpf3tArWxQSipAqUh/Sr3XVX4h ey1AlFFBR2NBQmlQQUJHaUJpe0FpV15AbGxsbFdVQGxebFVsbGFgUQ1QDVFTRkdGRURWc3J2ZWRn ZmVkd3ZzcldTRmNiZmdHXlJXU3NDflJlZEJnZmdDU1ZXVlZFREdTaCYjZRkHZX1taHNeRHBeRrBt TnnOFE0B2C4KOhY8DQ1p8NsJ2yfea3MQCn9Vd64oUnVkBhENa3hoekpGQVpAU61ERhEWTg0zelOu zFE0RBPRFvJRfDYRdVHYrnh2fAChKxQAUFJQGa+0VGNVOFBpUBRQqRARcklgSQx5DXpUdmhvUWhJ b3BvcRRoDXoPfAZoWWpKb0FTT1BMQWoSVUpsf2FkeFFOoFJNTV5weGB4UnilZBlyVVvoU/wQXlhg ShBKUlBKQEpSSphs6FPMEEcSYFgQWFJYmF4SGUREXlta/FvddWB/fOhR/hBeEHWQdVLwdVF1ShZS HlHoUrwQXFBVVUxTf1CLTE4eTehRU+JMf0roUW/nbylHSRUyhEh7HkCkHb2kpKS0QK20QWl/QKS0 HkCmDSEdrbxApL1Qb2xAvUC9IUCmvQ0hQLxvvb0NQml/bK1sQUJpaUFCaUJpaVFBQmlCaUFCaWFg UQ1QDVFjV3NWV0ZGY2JnY1ZWc3J2d1ZWc3J2ZWRmZ2Znc2djQkJjYkZFRFZzcnd2ZWRnZmVkd3Zz cldWV1ZRdnNyVkVERmNiZlI9hn6ba2ljumxje3Zn9TprPQ1MGHtrBSooU1zlfcRurpM9IRdgf3RM WV9dXUd/TUJ2Yq7MZk9FcXFISE5Sp8Ph2kMib9codmh/fwYSCSFRBpfDURxRdQ9vYhdxSnxHQk5Y WltbYHDkua1tdnFJTHJJUFBSr7SuFlRtVTtQFVAEUOgQElkDSQN5EFNuaGsdGBv6EVR5GxgRPhA6 ETobLBYoG9dM0hvbAlp3dHEdegN8BFRjZX9pAh0aFhBzTUxQWW9AQkZcf+hRGONpKXlc6FEY50Yp VlBmf2JJ6FFsEElTDxgQbxNRE9xiCHwJBV8Ib1lRWQhD3HBs6FFsEF12DwAQcHBRcAQGAYRIe0Cm Da2mvUCtrQ29QKWtrQ2tpr1AtFBvvb1/vb1BQmlpQkdpQUJpaWFgUSENUA0NUXZ2ZWRmY2JGRURW c3J2ZWRnZmVkdnNyVkVER0ZUR0ZFRFZXRkZFRFZzcnZlZGZjYkZFRFdWRURGY2JmZWR3dnR3dmVk ZmdWRURGR0ZHZmZlZHZ3dlEjTk+N4/meEWBibVVZHhwzJHR0UV9netHUS0uy4PKbEmB+blZaHhoz I3JzrqdoedPOKRjRBgIZbB/eClMJfwp6wJ/jP2IUbmhKSnxAeRM9FxFpaYo2HQcjlwxkCXXRm/41 ZxQQZUlKfkF2ETgWE2hogjUbBSicezwhEywjHAlsN2sY0SUaUFBRUABR1lLbU5FQW1BKEFxQ2VZZ SVxTSl0BOUh7HkC2QLRQfx29YWBRYkZFRFZzcnZlZGZRPif29yYn9/ZTkfcmJvj3Jyb3UFBRUFGu FlQFVRxQSVAiEFpRUkhHSEhSUV9T6FF3EFpJ3F9A/F9eUl9A6FFT4kZGR+hT0+RJcEhRSOtREVBL UFFT0xBeUwBSoFJSQFJwUgBSU1LoUh/lV0lKbPtIex5ApB2kDSFsvUCkDWytbECkbFBvbL1Avb1v bGxAbEFpaWFgUUFzQX5SZWRuUmdmY3FFc3JWV1ZFQXNBUi806rcpYj0iGjCxUeh8a2xfWzNVUKkW UzdYPI3ZNtUpEl1CfHRySTypoVbqUFBRrvOuFlRcVTtQC1F6ECRSW3NiZmJmZhddGgQKegh/lVxZ BBcRaVBRfH17QG8GbWdWZB0UGnBFTF9dd3lMewIEGgZcXV1me31Ee3t9F/cRUINRURFZE2FQABMR W0jjdBNCX3sMeH17QGmFUHpR8FFRD1FRUVZcHxQPFJ8UUw8UzxRSFOhR+BBCGvQGafBtr21ST22v bVIvbVFt6FFIEEJWaWQQQltvz2T/ZO9kU2RKDUXoU1DjcExRTOpSS1BdUmzne0kMe0d7DFroUlTh bUh7e0Bsex5ApB29pg29HkCmDVF7Hb2kIiENraa9IQ1BQmkhDX+kvXtAbHtAkFBvvb1vvW+9Qml/ vUC9115+e14tQJRRQUJpaUFCaWlCaUFCaUFCaUFCaUFCaXtBQmlQQUJpQUJpYWBRDVFnZmdmZmVk dnNyVldTUldWVnNydmVkZmNiR0ZFRFdWRURHRmNiZmdmZ2ZnQ0NCZmZjYkZFRFZXVldOUkVEV1Zz cnZlZGZjYkZFRFZFREZjYmdmZ0JlZHd2d3ZSEFwbcmQcZHRjAhDyDmMXjdceHWxheEJHXUNWWFlD T1pHRFx+HvEeJpgp38A8DhDRPzkT3TraHAdndEpyTF5bQllFfxhBW0lAUqN1SHJjmCASbC+krciu yj/G/xJ7dWdBR09DQEhYVVVWX1xLfkvKUVZSD1F5gi3XITf0fnBBRRXWHYL4LgURZG53cHQZRFpe WkXgUV0xZGBOQ1xQUFRQa6+xVZZVO1BfUE9QEFAaULsQQPV9835SbKFNZwtybaEQTXDoUUMQX3R+ eX1NfmKhTWZ0c3l4eOhROxBGYH9EYGB/eHl/YFR1Ynl9eGFgYRIAEehTzeNhYWYa6FPNEElwcWd+ fmZmUFBxQHFScXFYQC9QU0gvWFl+6lFAUBZROxBZdRoREWFhYm1i6FE7EEJsdXVUbGxcTC9UShxE L1xJGxzoUcPjcSo8SHt7HqQdvR5Aph29Qml/QWl/QL1sQGxAbEBsQL20UG+9b71CaX8NQWl/bEBs QGy9Qml/rbRAbEJpQWlRQUJHaddefnstQJRIe0C9UUCQe3thYFENUWJUQkVEUlRzcnRSZWRCdEdy VFJFREJUY2J0QmVkUnRVcWJHRkVEVldHRkdGR0VzU3NFREZHRXFlYmdmZUFkdndRRmNiZmVkdnNz U1DjUQTv7K7+6Oiu/+zvUQTizK6H9/RRePDxUXf09q6HrbhROucXNQkK2U5wX0yinX59G64JbkJJ c2ZRT3JHEQ0HCnZVO+eu++norv7r61EC6OlRBecJ8K6F8fGuifT0UXfx8VF78IB8byAXP0mqZktd VXJRIJYFYFNyckVNBlGIAn1WrsxVMgIEB1BQU1Brr7FVllU7UF9QT1BtUMAQXFB9QH05fCl8VG1n cOhRDeNyZ3Fx7FJ4UHBRDVBqUTLldT4vZlFm6FFs5kAvUFN+3H3oU8XlexkgYFFg6FFs50gvWFt9 fn9x6FEU50wvVEpveAhj6FFs5UQvXElub+hRxONxAdVIe3sepB2tpr0eQKYdraakbFBvraYNraS9 b62mDb28pL1RQL2kvWFgUA1RYlRCRURSVHNydFJlZEJ0R3JUUkVEQlRjYnRCZWRSdEdBc3Z2c3JW RURGY2JnRVZzcnZlZGZjYkdGY2JmZ1NQ41EE7+yu/ujorv/s71EE4syuh/f0UXjw8VF39Pauh+J2 RNcLPsTBPMQhKZXsuaruBj9wXkJJU1U756776eiu/uvrUQLo6VEF5wnwroXx8a6J9PRRd/HxUXvw kK6oNSP/7Zr82hYvs+TvqHhcSEtQUq+tUnVYW1UcUElQFFEEED5LTFF0S2BLb2FTVktbYU9hf2FU akxqYGphEksaYVVNel1EZF9ST1JSUpNWVthTZ1JDlGde/3JYlGdd/3NfSU9JUkmTRUXYSGdJc5Rn Tv9yfpRnev9yb5Rnav9yEJQUZ0r/dHSUZ3n/c2OUZ2n/c+iv2BAFTGFgcE1MTOtgf0RgTEtgf0xL TE1LpGJhRGJiYUthYFNjTX5MamlpYWFgYHp6eUtKSk5OTVBWRetRUFBeXX9+pHNvdB90UnRKFmJj 6xBPb39vb29Tb+hTZxBdWFFSLFdYpERDUEksQ+tSoFAVUBZS0uNx1sFIe3umpGxAbK1spGxApg1s rWweQKYNbB2tbFB/bG9srWxvbEBsQGx/bEBsQGxAbEBsUUFCaUJHadd+e1gtQJTXWH5Ie1UtQJR7 SHt7e3t7e1FAvbxQQKUNe3tRQL28UEClDWFgUXsNDQ1QDVNxRXN2dnNzQURHRmNFcWVuUmVBc3JW V3N1cUNDcUVyVlZFQURHRkdFcWVmZmVBUXNRQURHRkZHRXFlblJlQWR2dnNTU1lzVAo0dkJGb65q a01fczALV3FTJ1Egt7VRC2B0QV9Ibq5jGXmukEiuklZYfmeut2l0QUN0Z1UcsggGreUFRUxyclRA ehtSGAIMsq5BUb92RHgarngcRE1UcnJSfANRqq0zUs2uWhRARkpRcnJTQ3oXUYQXeURQUFFRwlRd U21VO1BTUHzhUVPoURbmUFGcX1BRUOhRReRShlNJVOhRLeGgSHseQKQdvaQNvVB/vWxhYFFxUXNS WVFkrv8KVTuu8lBQUlDpVGlTZlUTUFtQR1BgEERQmlZhXJpCX5pfRVFFrlOaWUlIRehRReNJ4KBI e0C0HkCkHa2mDb1Qf72kvWFgUWJGRURWc3J2ZWRmVWJGRURWc3J2ZWRmUW5nHh5nZx4eUftnHR5m Zx0dVRMeZ2ceHmdnHlEeZmcdHWdmHlBQUq/dUFBX+1UcUG5QEVHMEBVqEBh/Un1Xb1dqQ2hOaRAK QwpOC3IJECly2RDJELhzXRZ0FXVSEVFSUhBPfn9/Tm9Qbm4QWV5aTVlQdEB0cHQAdDB0VXToUnMQ QE9zTXRfdU91f3UPdT91VXXoUnMQTX52TXVYUldNWEdfRk1HZmh/EVFSEnV1n3S/dFJ06FNh4k9A a+hRVORuXxBSUuhTNhBBXl9EXl5fTn9/T24QRG5uEBDor7DjEE14a+1TzVBoUmhQalBJUzniSEhN 61M2UEdQEVM25VBQUVFYT+hTNuV+flhHUmToUzYQR2pqWVlYWG4SeBBuSEBKF09JUUn+Zxdp6FFn 42iQE17sUUlQUlNjUG5T1BBZEm5HbhJa8C1Ie3tAbHtApqa9QKa0vaQNvXuUQGx7QJBQb2xAbEC9 b0Jpf71CaX9sQL1AvWxAvkC9vXtAbFBo115+e1UtQJTXXn5Ie9deLZRRSEC8e0CkDWxRf0FCaWlB QmlQQL1RQJBQQL1RQJB+vVBApQ1Rfr1QQKUNQL1RQJDXLUCUlFdAbGzXQJRsYWBRIQ1QDVFxV1ZF REZHRXFnZmdmZ1FmZ2ZlZHZ3Z3FTc2R2c3NTY2JmZ2NTc2ZlZHd2dnNzU1ZFREZjYnRnY1NxZ2Jm Z0NDUVMDrgTUPXoTrjpbaHlsClKUbVhdZyFfVM8Ed82AMsx//fRqdsl0WU1GAi5uKEt+apFRTi14 2qv9WwoefQyHrfhRn8/TFktxVnV1XU97IFM6G0BKSU10UnWu+9DZrb8PKq2ieEdkYnZOrjgKc0pz 38Gu33UR3VF8UrGtT1BQU1AFr7BVgFU7UEpQc1B8UVEQTGpaGUkYSypJ6klVUXRRXER8Wnh0Y3Bq c2p0VnLor7DjW1xkVuivsBBZWltkenBaXGRx6K+wEAtZXGRDcFpbZHR8UVtcXFBRXV1QW0lKSlxe S3NJSl1eW11cVEFzdEtKSVFQVVR8fHRzS0leW1FYTndKXV1xXFBEXFxQXX1cdEFKVHxdd1xQTmVK RVN3ZVwAWFl06FEp40FJfXzoUSnlVEp+KjxIex5Aph29HkCkHb1Qb7S9b2y9aUFCaVFBQmlBQmlC addefnstQJRQQUJHaVFBQkdpQmlBR2nXXmxUbJRebNdAXpSU10BelFdAXmxsVGxebGFgUXt7e3t7 DVAiDVFXRkZFRFBQc3J2d1d3Z3Z2ZWRCUGNiR0ZHZ1F2dnNyV1ZSU0VGRmNiZ2ZCQ1WAKWh+rqOu DIIO3B8nZStmfKtRzoI3BBEBJq6PXQ4fMRIphHRADx40by+JRlVkKQHSG7OuZa6hZxQqZC0B0wK2 UZJRW09JESmuiSkPYAiuTq6QOicOYzRRrlFGUFFQX1DYVAVUmFBfUCrhU1LoUXTmUFVUVFFRUOhR UeZfVldXXl5f6FEW5lxZWGFdXVzoUVHkW1VWVlnvUXRQU1PJUFhRUVBSUF1RdORbUF9fXOhTyeVb SUAO1Uh7HkCkHbRsQGxApGyttKRsQGxQf61sQKRsQKZsQGxAbECtbEBsQGxApGxhYENxQWNBcUVx Q3FFcXdxQXFAUbHTUbGuT1FRsKvrUVGyrk9SuFGwrnDUrvjU01EJUFBRr71QUFS6VRxQaVHVEPB0 X39Bf0J/Q2xObHxsf2tkbGkYThl/GWIJTgt9C2k1czZ7Kk/KTkNwQ3VEUk5NUUpPS0pPTFJQVGlN UVNUaUxSVVlUSFZYWVRHV0lFSkhWRkVKR1d1e3ZndWRpZWdkQUVCZ0F0T3NndGN9YmdjQFlfZ0B8 VHxNeH1QaVN0WUVHQVNSVkpMSHhUWVmkRUpERUVKe3x8pE5PRE58fU5PfXx86FM2EFlQaURQfHtQ aVHoUzbiUlJN6FM25jBMIExSTEfoUzbiSEhX6FM2EHRvVt9Wj1ZTVmRjY3V1dFJAQVhRf1IeVn8f V1FXTX9MHkh/R1nuUSNQRVEnUGpQMlFNUEh7QKa9f6SktH8NpKS0UG9sb2xAbEBsfw29bEC9fw29 bEC911h+e14tQJTXWH5Ie14tQJTXXn5Ie14tQJR7QUJpQUJpQUJpaVBCR2l7QGxRQGxIUEC9UUCQ UEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQUEC9UUCQX19fX19fX19hYFANUQ1RcVdxV1dxV3FXVkVE RkZjV3FnYmZnZ3FncWd3cWdxU3Z3dndncVdWVkVER0NDZmVkdndncVdWV1ZXU1BRHkauy3l3UdpG rilLSXFpGlqtKlw8DXJyrtRFUStnUq4sRVEyBEdPRWVcUlNaAGdfHL4KfmZaUQJbT0dPZlL9E23e EzIKcUZ9R3V1GSklE5FaE1HsKHZKVnV1VmJ8eQOuNlE92RFIeFN1dVJBRgJQUa/QrhVUbFPTUGhQ lBAkFEAIUAhROUIpQvhC5kJXU0lDSRNJFkoVS1VoQF1UVHhySklcVFBZX0BAe11eRF1dXlFUVHto UERoaFBfXlF4UFZFvU1ZFXZ2TVthX0qDSUlqcHgkfHp9aWTRaXBwamhdaXheQFBdUV1daVpQQGho aVoaA0h7e0BsUX97bHtAbFF/DXtse0CQkFFCaX9Ara2ktkFCaX+9UG9vbEC9QL1ve2xsbNdefntV LUCU115+SHtVLUCUUEFCR2l7R2lhYFANUQ1RY1NWV1ZFREZjYmdmZ0NjU1ZFREZjYmdmZ0dWVnNy dmVkZ1ZXVnNyd3Z3XlJXVlZzcnZlZGZmZ1Fgr/FIUld5TWkVDBU7r+NxT0NCRHh0dHvbBBwLVyEG Eh9qeUlNSURZW18QdHhpw2B6U9OtgwNXdElweRkxvlElrcg/cEdxRHUDQys+Cxp0Y81lekleYRw/ 6nJ/YW1/EKAg31BQUlDcU3tSv1U4UHBQf1D5EGp9Sn1LbEpsS+l8hHu1e1dcQlxDfkJ+Q1R7T0NB QlVwQHxDcXlbVlNaXXxwWwlaWq5TcGFQVXE+TFV56FP15EZGXVpa71P0UF1TLlBQUTlQcFBTUTkQ XnDdQNNAUUBhdRBQSVFJ7FMoUGBQO1E8UEh7QKYNrUFpDX+0vUC9UG8quUh/QGxAvW+9b7RRKkCq SH+9QWNQQUJpaWlBQmlpUUFCR2lhYFEiDVFTVkVERmNiZ2ZnR1ZzcnZlZGdnVlZzcnZlZEJjYkZH Z1dyVlZFREdGY2JmZWR3dlK/LEBbV1lZSHlHCiR7el5FADBjYW++OHZ6WkUyTGI8X1hfatlAW1UP riRiXVdbV0FiXcR3TEd8EC0ZGRLyUUB1YhZEe64TTUNcqjJ4Rl5QUlDgU3tTUFU4UF1QTVB64lc+ RuhSHxBBXj5QU0MQWklOUxBLCU+WoEh7QKW9HkCkHb1Qb72kvWFgUWJGRURWVnNydmVkZmZHcldW UkVERmNiZ2ZCZWR2UhMHNiCVDwkzIZUUdEd7I3RLTERlO09VODAcCpQjDhwNlSFwRHauvyBNdUNh UVMjcHNQU1B2r7RV61PPUHxQb1AaUKcQalYaSV9GGlN+bGRzZnRralRwV3BYc1lhV2FYZFlldGUS WFhXW19qUGdxFxBqZHFyUmwQc3RTFFBfbHLqU+FQc1PhEEdOEIVQYFAQUFJQW30YThcYdxB3TldX V+5Se1AwUFVRaFBbUGdTFRBxRUVbW1eDWLtdFFEUaXB6YHpSenocUHrQUsBS8FLgUlRS6FNQEERs X2xRcGyPbFJsGxxkfEhJG3M6SHseQKQdvUFCaQ0hf60NtECkDb0hpLRQb2xAvUC9Siq5SH9vbEpA vUC9QmkNf71ApLRRQWNBQkdpQUJpaUJpUEFCaUFCaWlBQmlhYFANUQ0NUVZFREZjYmdHVlZzcnZ2 d1ZXVldWc3J2ZWRCZmdmY2JGR2dnV2ZmY2JGRURUUXJXVlZXVkVERmNiZ2ZCZWR3dkNuUmVkdnNy V1ZTMVcyGs/KTiaNLD/ebFQHZRYQe2YdO8GVA2hvEBpEfYVyMt4ADwiusa2TckVpI2VKekxOfQrL cEO7LNo2dUtjED9RJmd1BDT1T9spHi460WgZT0UrPsRRZJd4SxEJLl06FWQdbduqUYNfd5voBwJl Y3cfUQEkGHxLrhpBB+UVcnkWJ1BTUE+vtFOxU89QSFB0UGBRXxDBYHRsdRhyGHQZYMRG90bmRlhc YFFaVFRyUnNaf1xgVWByYHNgdGt/FHIdfzZzxVH3UeZRWlt1YGB/UVxcUFFeXV1QR0l0dHNeSEhd W15AZHRRYHV0U0l3UUdTS2F0UWB1dElHXltRWE56UEhdXQpcUERcXFBdYVx3QEhLUGJTXXpXUEhO a0RXSFd6a12FXFdbSehR4hBGcFNgUxBTMFMgU9BTVlMoYndqQChhNOlRflBIe0CmvUCmDb1Qb2y9 vW9vvUFpQUJpUUFCaUJpQUJpQmnXXn57114tlFBBQkdpDVFBQmlpQUJHaQ1CaWnXQF5sWJRUbF5s 10BelJRXQF5sWGxUbF5sYWBRDSFQIQ1RV0ZFRFJUc3J3dndXd2d2ZWRCdGNiRkdnV2ZlZHZzclZW V1ZTV1ZFREZjYmdmZ2ZDU7Eae+eui8htf3R/E30UYeNRYMNjM2AVvFZjdnYRCXNXAF9SZ3d7cxNm TRlTOhcAHPWu7etAXHQQfhMECPNREOt0dRO4fE1kanfZNUauvztPR2VsT2wsFlFcUFJQWa4WU3NT n1BbUGBQwxBg53mZeVJEQXR1eXl7fXh+fH9nQGJBYnUnQeBB5EJceX5RQURKTnRfQX9+VF1LTUdx 6FEYEHVHPnddrVYRUFkRU91cPnBdUV0eYE4QTlJOi3REmh90z3T/dFN06FMs43tJYdbpUctQSHse QKQdvQ29QL0hpA29pL1Qf62+f729QWlpQUdpUUFCaUFpYWBRIQ1QDVFiRkVEVnNydmVkZkNjRFZX VldWRURGY2JmZWR3dmVkZmNiRkVEVnNydnZlZGdmdGZS0BQPMBMUMA9NeBTEOHlLAGx7Y0JzH2hq AZjVP/kFYxhRMTNTnzAUFDAwFBQwrjU7yP4sMBAWBQt9S0Jwb35jHQUYJi8Z0xc2Hz6LKlBQUlB4 rhZS11OeUFtQSFAOEGx6XXtef0N/RH1Ge0hsXWxeGV44XShdW11cX1NTR0RZX0ZBUF1AXXFdU12t VhFQV0kPb0RRRCxZEVPKSjLpUaJQSHtApq2kDbZQb622DX9paVFBQmlCR2lhYFBRDVFiRkVEVnNy dmVkZlNjUlJWc3J2ZWRmZ0JRtBQPDxQTMA9IdmFgNQF8E3IIwlOeDxQTMDATFA+uMa6orY3uHWZ8 OudRYlBQUVAZUe9U31PWUFVQb+dwUnBTUlRhVetRUVBQUFNRLhBZUVFQVlUeVlRT61FRUFFQUlE1 41cywUh7QKRsrWxAtFBvbEC9QK20YWBQDUNxQXNBVRlUFtGsa1PWrmlRGVJQUa+vrhZUUVU8UBNQ 4RB4W1JPTX9NbFNsSVV2dXRTb3JIREJAVFtGdRFtZ2V3dlV/mGkTeVETcuhT/hBwEXNWW/VGGFVf Zj18Y2LIdtFsem89UBH1Ej0T9VBzPXLrUUhQcVBYU1AQWUF6X8hJekt6TehStecUULtR93G7cOxS Y1AUUmBRfFBIe0CmtK20QKakpK6kvUCktECkpLRApKS9rr20UG+ttG9srWxvrbRHaUFpQUJHaVFB QkdpYWBRDVFTUlZWc3J2ZWRmY2JHRkVEV1ZFREZjYmZlZHd2ZWRmZ0NzZ2JmQmdmY2JGRURWc3J2 ZWRnZmVkdnNyVkVERkVEV2NXUpc1FTrnMRoCbHt6TUZUWUBdTGFWU11LPd5JMjQ7GRg3HgNufnZi S1VAW3VqWV7KSFNArlyu/qLCF313bElDcl1bSFZYXm5tShx8dh4+1lJIKgBRcGlpGWdiEGJxRWZa VlhdFxR3O0p+HipQUlADr6ZTolPfUFVQW1AwEEJnUmhVZ1hoW1RbVVZZU1pY3FnqURFQV1Hg5VpW 3FvmWuhRWeNUUtxT6lERUFFRIxBAVFDcVeYQVABUUlRJXDLVSHseQKQNHaS9QL2kvUCkpL1AvaS9 UG9sb2xhYFENUVFDc1NRcVFDc1NRUh2ur2trqVHqUbWvUBAQplHpU9+uY65kUZxRna5jrmRRnFGd UFJQXq+mU/1T31BVUFtQNhBCaFJnVWhYZ1tUW1VaWVNWWNxZ6lERUFdR4OVaVtxb5lroUVnjVFLc U+pREVBRUSMQXVRQ3FXmb1QfVA9UU1TsU/dQXVPAU8FQSHtApg2kvUC9pL1ApKS9QL2kvVBvbG9s YWBRDVVRU2NDUXFRU2NDUVHjUVFra6muFa5MUVAQEKauF1pRnVGcrmSuY1GdUZyuZK5jUFBTUP+v tVcBUWRQW1BHUHNQbhBBSBFOXBFCYU5QEVZhTltLEXHoU8riXxFF6FPK5VMRWUl0lulRDFBIex5A pB2tpq2mvVBvpL1ApL1AvWFgUWJGRURWc3J2ZWRmVWJGRURWc3J2ZWRmVWJGRURWc3J2ZWRmUQUW MTIVFTExUqAVMTEVFTExUqAWMDEVFTExUWQyFRUxMRUVMlExFRUxMRUVMVIxFRUxMRUVMVCvr6/c UFBUrVdAUnZQdFBQUVdQE1IoUfVQR+NSUXZD6K/65Bh3UlF46VKYUHlQe1F7UK+vr9xQUFX4VrNS dlB0UFBRV1CWUilRx1BL5VIfYFFgQ+ivQOQYe1JReelSmFB5UHtRew1lUK+vUD2vsFXvVuxSdlBi UFBRV1CWUkZRIFBwEFpSf30Pfd99U31Y6K905Bh7UlF26VKYUHlQe1F7DWVQUlAvr6VX+1UHUH9Q EVFjEGVQaFBpQGhAaVR/eHlka3NrZGBpGnMaZAlxDWQlUypYL3EpZPVTXll3UV95T3l/eQ95P3lV eehScxBAUHpNeVB4QHhweAB4MHhVeOhScxBEdHdNeFhaUXlgeVF5b3j/eJ94U3joUSoQSnRAdFBR c3NRUU8RYUQREWFyd0tmZUhSSkxQ6FM2EFl0f3RRdF5LT07oUzkQWU1NTExLUlZ3WuhSaBBHXABe WG5lQFgREnhhEU1ATxdPTlFO/lvoUWcQRVkXWpATa9RESRJQEVERRxESWtctSHt7QGx7DR5ApB29 QKa9tKQNvXuUQGx7QJBQb71vpL29b2xAbECubEFCaQ1/vUBsb71AvddefntVLUCUV2xse0hApA1s DVF/QUJpfr1QQKUNUX69UEClDWFgUSENDVFTVkVERmNidGdjU3FyV1ZzcnZ2ZWRCdGNiR0ZjcVNz ZHZzc1NmZmdjU3NmZWR2dnVnZmVkdnNyV1ZSRURGY2JmZ1VRIHJ2dN1RdSN63q3t7WiPVt6PIaRR 94oaIWf5UkwGdszlfMrPyRN1yXNZfTqu5nxZGm8wEca8MDYI2WVS+a4tJnZFcsLdrt5SWSyK1bVR +qhXVK79K92to1IJLa2jf3NhEXi2ynl9ERpo0K2NqwzG0OdQU1B+r7RV7VPPUHdQaFATUOEQfGR8 a2RSd1kWWRZNH08eElVZWFxAZFVOExBQQGRmfhNpTlBUbVJYcFgQWFJY6FJ7EEdcMGmFUBBQUVBc eGtLEBhxcUtXYWtEVehRaBBORFxbWINZu3R+akdJFG1pdOoVH1JRUpJmZhQVczpIe0FCaX+9DUCm vR5ApB29QKS9UG9svUC9b2xAvUC9QmkNf71KKkC5DUh/UUFCR2lBQmlpUEFCaWlCaWlBQmlhYFAN UQ1RVkVERmNiZmdHVlZzcnd2d1ZXVnNydmVkQnRjYkZHZmZjYkZFRFZWUXJXVldSRURGY2JnZkJl ZHZDblJlZHZzcldWUylAMxYX3gZyJY0uMBFiYG9oCTbFw+dRcsA0PHo88A82C9C1rkZ5fBkeD2l6 ZGYawWW7LNQHTEhiFztRKG12FjgYBU3cJ3VMGxVLfPIs81Fs7hUEBxIfbQDuIFGBeBGBr1DzZGxv BlGMPmRqrhBOD+UaTk0fJlBRr6FRzVRCUkZQU1BL6VBSUVEQWlBSCVRTf1VsYkh7QLRApVB/vWFg UXFlcVRCq49UcVHNKVBRr7xRzFhDUkZQU1BL6VBSUVEQWlBSCVRTf1VsYkh7QLRApVB/vWFgUXFl cVhDp4lYd1HMKlBSUKJSvVQfVTtQQ1B2UCgQf+tS60PrRut163ZVmUOZdlJXdVFw50Rd51BF/ERT UfxQU0lJTXNVVUBaRH9/RVFF6FE1EFtNEXPmQFB/f1FRUehRNeJaEUDsUU5Qd1IEU95QSHtApq2k DbRApK2kDbRBQml/QUJpf1BvvW+9QL1AvWFgUSENUCFRR1ZXVkVERkdGRURWc3J2ZWRnZnVHVldW RURHRkVEVnNydmVkZ2ZSLUjcYXA3Ql0wFxYPHDVSw0nffU9nHTESFDYEOlU7eRpqd3NzMHNJcRMw NwAsM9IyfBtmdnd0YhUTEzM9Hyw62FBSUKJSvVQAVTtQQlB2UDQQcZVBlXVSRPxD53BR/FDnXHBT XFNISHNNVVVfWUN/cERRROhRNRBbcxFN5llQf3BRUVHoUTXiXxFZ6FEn43fe7Eh7QKa9pA20QKS9 pA20QUJpf0FCaX9Qb29Arb1Arb1hYFENUXdmZ2ZlZHd2ZWRmY2JGRURXVkd3ZmdmZWR2d3ZlZGZj YkZFRFdWUVtJ331waB0yEhM3BDq8SNthcDZCXTAWFjAdNVK/ehtmdnZ1YhUTEzM9His61wd5Gmp3 c3Mwc0lyEzA3ASwy01BQUVFzUqFSlVU7UENQExBM7VLtQ5lSmUNUm0NRXedR/FBTVVVAWlB/f1FR UehRNeRAsFoERepRW1PcUEh7QKa9pA20QUJpf1Bvvb1hYFENUCFRR1ZXVkVERkdGRURWc3J2ZWRn ZlL+R8l1TTdBXTEVEzMEO1U7eQd+cnR3DnJJdhIOOgAtOtdQUFFRdlKhUphVO1BCUBAQSOFS4UJS lkJRUfxQ511TVVVAWlB/cFFRUehRNeJAEVrqUXNQQ1Fx4WJIe0CmvaQNtEFCaX9Qb629YWBRDVAh UXdmZ2ZlZHZ3dmVkZmNiRkVEVlFtR8l1TTdBXTEVEzPvUqF6Bn5ydHcPcUl3EQ46Hy2iUFBTUEBQ qFQFVAxQW1BfUEtQbeJQB1bsU/lQXFFRUF9T+RBdQAdGXuZDB0ld5lMHWehTyedJ5l8PTMZiSHtA pqSkrbRArbRQf62mraatYWBRYkZFRFZzcnZlZGZRcUVxVWJGRURWc3J2ZWRmUmR7bGx7emxsrlZU FavrUnN7bGx7em1sVAxsenpsbHp6bK7c1M5tentsbHt6bVCvr68UrhZT3lUTUnZQDFBQUVZQ3gRQ UHIQQ1FSYB8QH1LgH1EfX1AYe1JRUhzpUplQeVB7UXsNIWVlr69Q7lBQVexWn1J2UGxQUFFXUN5R 5lHcUHAQQVFSHxFRHxFREV6YGHtRUlJu6VKYUHlQe1F7IQ1lZVBSUEVQ71O+VNpQTlB6UMAQXMhQ +VDpUFNYDlIOeBFZUVFQV1NTUFNTU1BVU1FQclFR5EIOSQ5D6lNTUEhTU+NFrntZEUpT+FBBU/hQ WlNTUEBTU1B1UVFQXVNRUFFT+FBKU/hQUFNTUEtTU1BPUVFQTVMDUHtQfFF443HGYkh7e1BvvbS0 tLStvbS0tLRRQKa0tLS0va20tL20tGFgUA1RZ0dXRkVEV0dXd1ZWc3J2d1d3Z3ZlZGZnd2dHZmNi V3JWRURGY2JmZWR2U1vaCdwHB9EM0gAhFholGNUI0wh8fNgN1SzZ1tTS5+jR0ufnVFPXB9wq2tfS 0AvRYnN2f9EL0CXAFtxm1wzXCtLn0dLn59LR51BRUCivpVIiU8BQVVBtEFpoU1FTUlpVUFZX6FIC 5VRS3FNTVOpRI1BRUWziVdxQ6FPp41YBwkh7QK2tpr1sQL1AtFBvbG9sYWBRDVFRQ3NTUVIirq5t bahR61PArmOuYlGeUZ1QUVBpr6VSY1PAUFVQbxBDZlNRU1JWVVBaV0dHSlRS3FNTVOpRI1BRUWzn VdxQSVbGqEh7HkCkHa2mvWxAvR5AFTUUtlBvbG9sYWBRDUdRU2NDUWlRUm5uqK4VW1GdUZ6uYq5j UFGvpK4WVEBVO1AtULUQZnVbek97HWZba09rHRtLGk8VDTRVM1shVSFbK07bTvldQBZbHVVUZwBQ Dz9UJwh9TRFeVEZnW+tT+1AWUB1T+xBdVVV2FhY3dgUIYAtRC+hT/RBdAPwPUPwPPyoIYCRRJOpT /VA/UZjiN1B26FF0EFpNEfx9aghvY1Fj6FP95319XvxgTVFN6FP950MIb0lRSVsI7VI0UCdQRlI0 UCdRXeNnbGJIe3+9vUC9UG8NvaQNvWxApA29QL1AtG+tpA29QGy9QL2kDb1JQUJpf0Fpf0i1QLVR QUJHaUFCR2lBR2lhYFENUVZFREZHVlZFREZHVlZXZmZnZmNiRkVEVnNydnZ3VkVER0ZFRFZzcnZl ZGZmZ1ZXVldWc3J3dmVkZmNiR0ZGR0ZHZmVkdndmZ2ZlZHZ3ZmZnVlZXVnNydmVkZmNiRkZHZmVk dmVkZmNiRkVEXlJXZmZnZmNiRkVEVnNydnZS0FpxYDQfeGQDHntpb2wAenxtFGN02hFvW1lcCmV9 E0suZGpIXQx8cmVySmhhTnNCJldFalZPfg92YnpjDRxPPi5dQEhhEG1+Y81gZl5FCmt+bk08fU5l YmEVYWdva2F/0mdTDn5NdhB6fzFvfBh8dRoCVEFMdW9+e29pQVhvcXBoHWAXMhF/d23IIltXVXZD T0d+ZmpZVWhSVld6THgQfHx8aRN8Fnd7HB1dFFRWEH99bhVfVhZzTtFgHjIQf3UU1hgSV0FKdW1g YGwSQlBRUMtSVVG0Ux5QW1BIEFtQEVZTsFlJXDs5SHseQKQdvVB/vWFgUWJGRURWc3J2ZWRmURAU MDAUFTAwUx4xFBQwMBQUMVBQUVBMrudR7lFhUEJQFhBA4FLiQlKVQlFR/FDn0F1RXehT2uVQf3BR UVHoUTXlWlVVQBFa7FMoUENQAVHKUEh7QKa9aX9ApA20UG8Nrb1hYFENUCFDd2ZnZmVkdnd2ZWRm Y2JGRURWY0fJdU03QV0xFRMz767negd9c3N3D3FJdxEOOh8tolBSr5Su5VNyUWRQQlB2UCAQQ5VB lXVSGEZRRPxD53BR/FDnXHDqU9pQXFPaEF5ISHNNVVVfWUN/cERRROhRNRBbcxFN5llQf3BRUVHo UTXlXxFZSXcO6VHLUEh7HkCkHb2kDbRApL2kDbRBQml/QUJpf1Bvb0CtvUCtvWFgUSENU3dmZ2Zl ZHd2ZWRmY2JGRURXVkd3ZmdmZWR2d3ZlZGZjYkZFRFdWc0nffXBoHTISEzcEOrxI3GBwNkJdMBYW MB01ruh6GmZ2d3RiFRMUMz0fKzrXB3kbaXdzczBzSXETMDcALDLTUFdQZK+YV4tVO1BTUF9QcVB+ UBFQHVAwUIYQSidcJk0meyZtKRMmGsgM91n6XvYW+xxbUFFR6FM2EERSU0RSUlNTUlFQVDIxUlFh cgkZGOhRH+UeGRJqGXnoUR/jfxkScuhT2OJAGVToUR8QQkoZWmFTU1BTMn8bld8GwAZSBuhRFBBc DpUVBHyV32fAZ1Jn6FEUEENvlR91L3XfdVN1hl2V30fAR1JH6FEU4k+VV+hTKOMxOzlIex5ApB2t pg2trQ2tpg2tpq2mDa28UG9sHUCkva29b2y9rb1Ava29QKRsUUFCR2nXfnstQJRhYFANUVFzUVFy dmVkQmNiRkVEUndiZ2ZmZ2ZlZHZzclZXUkVERlFydmVkZ2ZjYkZFRFJ3YmdmZ2ZnZmVkdnNyVldW RURGVXJ2ZWRCY2JGRURSd2JnZmdmZ2ZlZHZzclZXVkVERlXbq3EoVIysPTfTpt851qPHSkZxfmZ5 d0t0E3QAd1J9MNbXIN462a3eTUZwSUIQcXxOTm97HXRSgzXVpN8716XGcUROSUIQc3pNc2x8HHJV O6oPVfGtcdsvklFA3CiXrr9lQks7ksJldXwcJq6oMk54rVfAJJHJLtwlk664aEFJa3uyJ2hyfRvd rgJxd2jaKZZRQtoql66gaF9Hanu0KWhzexjCrgJwdFCvr6/cUFBVK1dRUnZQdFBQUVdQlVI5UcZQ RRBaUlF2Q8YYd1JReulSmFB5UHtRe1Cvr6/oUFBVIFdRUnZQeFBQUVdQlVHkUcZQR+NRUWJ56K9W 5Bh3UVFj6VKYUHlQe1F7UK+vr9xQUFW2VqtSdlB0UFBRV1DdUvlRwFBFEFpSUXVCRBh3UlF46VKY UHlQe1F7UK+vr+hQUFUgVp9SdlB4UFBRV1DeUZFR3FBHEFxRUlIWULYYd1JRUhPpUphQeVB7UXtQ r6+v6FBQVSBXQFJ2UHhQUFFXUBNR1lH1UEfjUVFieeiuaOQYd1FRZOlSmFB5UHtRe1Cvr6/oUFBU ZVarUnZQfFBQUVdQ3VCoUcBQS+VRf0lRSUToUX/kGHtRUUzpUphQeVB7UXsNZVCvr6/oUFBT71dR UnZQfFBQUVdQlVD9UcZQS+VRb0pRSlLor+/kGHtRUU7pUphQeVB7UXsNZVCvr6/oUFBTtFafUnZQ fFBQUVdQ3lD+UdxQTBBeUVIfflF+Vl8Ye1FSUnvpUphQeVB7UXshZWWvr6/oUFBT7FdAUnZQfFBQ UVdQE1DzUfVQRRBaUVFKVkQYd1FRTOlSmFB5UHtRe1Cvr1A9r7BV71dIUnZQYlBQUVdQ3VGxUf1Q RRBaUlFyQQoYd1JRdelSmFB5UHtRe1Cvr1A9r7BV71a4UnZQYlBQUVdQlVGnUS1QchBbUh9zUR9z D3NSc1zor1vkGHtSUXfpUphQeVB7UXsNIWWvr1A9r7BV71dAUnZQYlBQUVdQE1G8UfVQSxBeUm9z H3NSc1hMGHtSUXXpUphQeVB7UXsNZVCvr1CQr7FWKFdIUnZQaFBQUVdQ3VGYUf1QTedRb2AfYFJg eOivOOQYe1FRY+lSmFB5UHtRew1lUK+vUJCvsVYoVrhSdlBoUFBRV1CVUYhRLVByEFtRf2FRb2Ef YVJhTehSduQYe1FRZelSmFB5UHtRew0hZa+vUJCvsVYoV0BSdlBoUFBRV1ATUadR9VBH41FRYXjo r5TkGHdRUWPpUphQeVB7UXtQUFFQfa+0Ul5Tz1BMUPkQdxJaUVRbRFt0W2hQZFtrRWhKGFAXUS9O 50NbW1dTXVpbg8Ba8FpSWuhTEBBGU0mDSiREU1BQe0RAREREQMBa8FpSWuhSexBBXVtKg0suTExQ V0BNeERAQFDoUesQQURT90T1QOpNWUBHQE1acwNIe3tAbHt7QKZRtL1ArXtAbHtAkFBvbECkvW+9 DddVfnteLUCUUUhApr1Apg29e0JpUGlpYWBRDVANUVNWRURGY2JnZmdHUnNydmVkZ0NmZWR2c3JX Z3VSXp1BQlpBQX1vcsf6ER1B20R2cV9FXVEDU8+taW1DW0NfdTFErqkZaHVpUY4Vc0ZyUXhnUFFQ x1RHU0JVO1BWUDIQRllUSVRpVFNQUXhTdVVTUVCgVFJTU1ToUrwQW1VVVlRUU1VQm1ZR6FFF5VLQ YFNRU+hS8eVV0FZJVzvpUTdQSHseQKQdraYNrbRAtEFCaX9Qf2xAtGxAbECtbGFgUQ1QDVFjQ3N3 VXNRmbM2NtauijlVO678m5tQUVDmVGZTf1UcUEVQaulQQ1P951BQEF/QVGFY6FP95VtQGRBR6OhR UOdbGVxJRuCgSHseQKQdvUqtSr1Qf7y0So1KbEC8YWBRY1ZWc3J3dnNyVldzZmZjYkdGY2JmUqBv UiUZFt5rTEx5VxJYJhsf1WhJTnhVHNrcEUt6YcDVEEp5UFJRAFOiUqBVwlBbUEdQEOdCKXBWYFZS VuhRGBBBXCl/UG9QUlBQXylwWWBZUlnoURjkRSlTSknoUXLh7Eh7HkCmHb2tDb1Qbw29rQ29YWBR YkZFRFZzcnZlZGZHclZFREZjYmZlZHZScAcpKQcGKikHZx4eZ2geHlXCKgYGKioGBiobHmdnHh5n Zx5QUVBbrthRglBQUEZQbRBIFlQGVDVUJlRUXT4QWNBYwFjwWFRYQ4ZS6FP85FFaQAdV7FFaUEdR cVELUEh7QKS9UG+kvX8NvWFgUQ1xY1dGRkVEVnNyd2dGY2JmZWR2c3JXd1F6HBUCHy3ZPwJcG3UT GH5ORnFdZFsDahY2Tk9ebXpzf1hOUFBRUI9URFMJVTtQVlANEERWVUZVZlVTX1J3VHhWU1NUVFZW UOhSvBBfVaBRUZtQVVVUUNBgVlFW6FLx4lTQUuhRReJTSVfqUUtROlBIex5ApB20raYNvUJpf0Ck UH+tpGxAbEBsYWBRDVANUVFxU2NHZ1MJrqiuqTso3aVVO675UQeenq+vr4OvsVT7V1RSdlBmUFBR V1CZUKNRyVBH41FRZ1for8zkGHdRUWbpUphQeVB7UXtQr6+vq6+0U2pVO1J2UAZQUFFWUJmxUFBN EEBRb2UPZZBlU2VVNBh7UVFl6VKZUHlQe1F7DWVQr6+vmFBQVT5XVFJ2UG1QUFFXUJlRIFHJUEfj UVFEQOhRGuQYd1FRQ+lSmFB5UHtRe1Cvr6+3rwJTCVU7UnZQDVBQUVZQmVBQUEUQWlFRenf6GHdR UXnpUplQeVB7UXtQUFJQz64WUXFVO1BTUFdQAuxQVVEfUFRQUFEfEEJRVF9RU1FQWUdHSlJSU1NX V1boU/bmVFVVUElYWehRZuNxO/tIe3sepGxAbB2tbEBsQGweQBU1FLZAbFBvbx1AvUC9YWBDQWNB U0FjQc/S0tJSwVKKrXar5VKLrXVQUq/uUFBV+lUcUEhQeVC2EC1/eVFZRFl1WXlJdUl5VXFLcUxq RWpJZUtlTGt0a3VteRdeGEkWTlxAQUFaX0JDQ15KTU5OSUpBS01JWl5bTVpQQ0hNUE1MS0JBQF9X d3pZSU5OT15DRF5eQ3N3Wkl3UEtBcUxAQFpQUlpYXnp4Q15Ad51QVD9Uz1RTVEp7TuhSfBBbUF5R Xkl6XkdeelroUUrhw0h7e0Bsex5ApA0dvR5Apg0dvXtAbHtAkFBvb0Jpf2ytbEC9QL3XXn57VS1A lHtBQkdpSFBAvVFAkFBAvVFAkF9XQGxs10BsLZRXQGxhYFENDQ1RcXBQQURXVlRxcWdiZmdDc2dj Q2ZlZHZ3VVNxV3FTVkVERmNiQ2ZBZHZRd1GaUSFRGB3Frjqukq2aWjEPcS7gRuMPTxIxUbvKUWRH rp4tQ2cRt/Pek1UcroWupu7Qqo92HCJRkBxRHjt6dmFRfK2hHK4DEk1xfFFXs1FOiodQUlBkr7RT tFU7UE9QYVC1EMNbUUtQS1F6UXpSalFqUmRZGVEbUgtRC1JceVloXGZ0a30UUhRbAlIzUu1dtFFa U1lZV1paUlBQTlxcXVtbUVZXV1ZTUFR/dllcXk1NcFxZU1BUS1ZXWltRW1pRClJaRFJSWlFSUVJ/ dlpNW2NeW1JRU1pLV1BaUHBrS1Z5a0RbdmpHSWJNg398T14PXlJeSmNzOEh7HkCmDR2ttR5ApB29 UG+9b71vb0FCR2lRQUJpQmlBQmlpWNd+e1gtQJRQQUJpQkdpQWlRQUJpaUFCR2lAmddAWJRYbFdA WGxebGFgUQ1QDVFXd2d2dndnRkdnR1dGQURXXlJzcnZlZEJ0Y2JHZHZXcldWV1ZFREZjYmdmZ0Jl ZHZS5oVNjXBPT00VHoNOmv0ZaOSfNd7M81FANhgWXw9kdxMaDWV5e3odEA5iVCUjaSkUY3dJZgYj ajuorqD3wyLgNcjU8lF+430MI4dybJivzmlqdRXmUVjMaGqvr1DuUFBV7FarUnZQbFBQUVdQ3VJY UcBQcBBaUX98b3wffFN8Ruiv6uQYe1FRf+lSmFB5UHtRew1lr6+vFK4WU+5VO1J2UAxQUFFXUN1Q 0VBQUEfjUVFqWOhRcuQYd1FRa+lSmVB5UHtRe1BQUq+RUFBUglUcUHRQf1CJEB9feU95f3loSmh0 b3lWdXZcXFBQXHV2dHRdREhFTURwdHFNcENdQk1DT0lOTU92dVxQVHtgXUhcREl0T1F4dF1dT0hJ REhISXV3UFFAUVJR6FEVEFxwcE9SdndfXE9cUlzoURUQRUREQ1h7HVdKYUhgeElASEhgWmjDSHt7 QGxRf3tse0CQUR5Aph29UG9sQKQNvW9sQKQNvddefnstQJR7QUJpaUFCaWlRQUJHaUhQQL1RQJBQ QL1RQJBQQL1RQJBQQL1RQJBXQGxebFVsbFdAbF5sYWBRDVFjYkdOUkVEVlRxc1dWRURGR1dxZ2Zm Z0NmZWR2d2dxV3ZWV1dTYmdmZmVkdnd2Uux8K2Mz2AHfr1Cujm5aT2gPWa0pWzIMc6dPawxbUtdb DTBzf/rHZwItbmlwVEtYXx7WHiifO3Q8dnJ7WHV1URopUwQ7fnR7UnV1URslza3kRU+b1xkPQ1tQ UFKvVq4WU5tVO1BxUGFQpBAuG1NRW3hLeHVQe0VqUWZBa0RsSxlREVYUQBdHFkkZSzdBJUH2REFS cmFRXlFSXnJhX19RRkpHfUZFX0R9RVBvSyZ4cX1QFFFhYHJeUlV6Yl9KW0ZLUVV4XlthYHJSVH11 S0pKZl9RRF9fUVFQfRVVV3UTW1tGRV5jR0dKWHx66FIMEFlfYnhRQF9fYlroUnbhOEh7e0BsUX97 bHtAkFGkrR4VNRS2UG9sbx29b71v115+ey1AlFBBQkdpQml7QUJpQUJpaVFBQkdpSFBApb17rFGl UEC9UUCQUEC9UUCQ10BebGwtlGzXQF5slGxhYFENUA1DdVNmZmNiRkVAUHNydndXVkVERkdXcWdm ZmdRZmVkdnZXQ0ZGY2JnZkJlZHZzcldWV6pR3+M51hIONq7YgXZkfmJMfQBZrbZaEAR2USpKQE9l Tk5gcGRsDCBnd3NPfW1VY2itwTATwTmusa4OXkjkN2JOdlx3d1Id1FVGC3lCR1pRqwthcWwLUWjH HRZCShdQUVDKUKZTrFQIUFtQ4xBNJlQqWlKEUYpXtFG6V1RaUVRXVFZYWlFUV1RbWVXrU+pQVlBZ U+rmWFblWOVXU+tT6lBSUFtT6uVQUuVQ5VfuU/RQUVBWUTVQVVBSUTXlU1XlU+VU7lE5UFpQWFE1 UFlQUFE1EEBbj1m/WVJZ5Y9bv1tSW+Va6lK0UFxRS+GoSHtAprQNtA1AtEC0QK20tEC0QLRQf720 tEC9QL1AtLRAvUC9QUJHaVFBQkdpYWBQDVEiQ1FRR1FRV1FRd1FRp1EEUQQMrv1RBA2u/K7+DFEB rvxUCK78UQMMrvyu/A1RBK7/DFEBUQVQUVArUshSxVU4UEhQzxB1JFBRR0hbX1xnW1pRWWdaQF9f klFQRFFRUF9RQFNQXPxbWfxbWupRH1BIU/wQX1BTUFBRWUBAWV9fkllRUehSvBBbWVFJeFBAUUdR SVroUXDh+0h7e0Bse3tse0CQUXsqoFFIf3sqoVFIf3sqkFFIf3sqQJBRSH9Qb7SkbL1ArUFHadde fnstQJRIUEC9UUCQUEC9UUCQUECZYWBRDVFTVkVERkdGY0dXcWdmZmdDZmVkdnNyV3dSxZdeX1pf dXRbrgVbBGBHJE5ISUJkWFU4reF6XFtGU1ZST09ScBZRCglAREdVT1BQUVA1UshSkFU4UEpQ1BBG IFskXVJFUkRCVlxbWVJRRURTU1lKSe1T/FBGUWhQUFBRUR8QW1mvX1NLR0dJUVFS6FFZEEtW/0rv Sp9Kv0qvSlVKHlYQYEIwQiBCU0JKTAHpUURQSHseQKYNHb20DUCkbB5AFTUUtFBvHb2tbK2kbEJH aUJpQmlpUUFCaUJpYWBQDVFxZXRnZmVkdnNyV3dmZmNiRkVEVldjYmZnY1JzrhJRfwF4amEca3h0 0gUwIsah0xljS2RSyEuiI2oQfmcBQAgKM20C+eNLflBRUD9S2VLgVThQYFDbEEraUdldkFtTUVB/ e3h2VHFGVX1GUVFYRvxQW+hT5eZcoF9QUF916FH44nkpTehRHxBcWC9fU2JHR0pCXH9R6FPJEFpQ 3XFKEH0eQhBV6FEs5XFJYQHsSHseQKQdpL2kvUCktLQeQBU1FLZQbx29rb29Qml/QK20QL1CaUJp UUFCaUJHaWlpYWBQDUNnZmdmZWR2c3JWV3dmZmNiRkVEV1ZXRkdGRURWc3J3dmVkZ2ZjYkdGY2Jn ZmVkd3apW8AVfn92TmRyemQ4FQc0eGUPbkd0mfICd0pBSnNxb35MTkpzb3lUQXFBZ3VgcH1OeEIU bARjaHZlX01Of2s3+ktCS0leRXZLcX0SCmJwUFBTUCmvlVXcVThQU1BNUGhRGRB0J1S/T75wumNU IHkge9xnU0xNQERBZ0BfVV5nX2JgY3B0U1JS6FN3EHVRUERRUVBFRESRVVREVVVUUlFTUFRqaXl6 d3BkT0RVRVNUQWNk6FFo4053r33oUR/nTkH8QF78QF/qUR9QTVP85lRUeFBTTk/oU+PlUlJRU1JR 61GvUE9QcFFZEHF0/2jvaJ9ov2ivaFVPaH9oUmgedBBgSmpUVFVZRUVZREToUTniWVVV6FK8EFtZ VWl4VEBVR1VpWuhRneGoSHt7QGx7e2x7QJBReyqgUUh/eyqhUUh/eyqQUUh/eypAkFFIfx5Aph29 tCENQKRsUG9vQGxApmxAbHtsUEC0pGy9QL1Arb1ArWxBQkdpQUJpQWlpUUFCR2nXXn57LUCU11V+ SHstQJRRQUJpQmlIUEC9UUCQUEC9UUCQUECZYWBQDVENUVFzUXFTVkVERkdGY2JHV3FnZmZnQ2Zl ZHZzcld3UXFlZmdmZWR2c3JXd2ZmY2JGRURWV2NiZmdjVXSsbdRT762nl15fWl91UXNbrgVbBGBH JE5ISUJkWFPtrhGtORNqYRxreHPSBjAixqLTGWNMY1U4qg1V863helxbRlNWUk9PUnAWUQoJQERH VU+q/EuaKx4dfWgCQQgJMm4B+uJLflBQVFApr5VV9FU4UFNQTFB3UHpSVRATb05tTyZU3XRUc09k TxZPUxZPUXJ1dnZxeE13d3l1dE52cXJxdnN6TU50d3l4eXdzektMX0NAZ19eVV1nXk9Oek9wcOhR ZBBDeXpEeXl6cXZ2kXd5RHd3eVNSUuhTdxB8UVBEUVFQRENDkVVURFVVVFJRU1BUfHtDVURTVEB5 enR1dXVNTU5xeF9wUXDoUR/kd3N4eHrqUkFQTlMEEF92dnd3UnhSUUD8X138X17qUR9QTFP851RU U3hTUFJR61GvUHxQfFKgEEtxWXBwhnFZX09PTx9PD08/T1VPhnp6zHdZcXHoUTkQXll5eXdZdna/ WXcfd1F36FNCEFpZVFRVWUREWUND6FE54llVVehSvBBGWXdVe3jAeVF5d1RVQHdHVUd3VXtaAelR plBIe3tAbGx7e3tAbEBsDXtAkJBReyqgUUh/eyqhUUh/eyqQUUh/eypAgFFIf3sqog1RSH97KrFR SH97KkCBUUh/eyqxUUh/eypAolFIf70NeypAsVFIf3sqQLJRSH9Qb29se0BsUEC0pGy9QL1AbHtA bEBsUECkrWxAbECtDXtsUEBsQGxsQGxBaUFCR2lRQUJHaddefnstQJTXVX5Iey1AlNd+SHstQJTX fkh7Xi1AlFBBQmlIQL1RQJBQQL1RQJBQQJlfX19f10BVbC2U10BslGFgUCENUQ1RUXNRcVNWRURG R0ZjR1dxZ2ZmZ0NmZWR2c3JXd1FxZ1FjU2NXc1dzZ0NRVQSsbdRT762Xl15fWl91dFuuBVsEYEck TkhJQmRYU0iupHBRtDLwDHMKZ8gIBK6hVTiqDVXzreF6XFtGU1ZST09ScBZRCglAREdVT6tuDlGw rnAO8K5RXq6iUFRQPa+VVfNVOFBTUGRQb1ASUaUQMX1mfWduZm5naWscZwpnO2Y7Zyhr3Wtba19r QBhBCl8KQQdnOEHZVdpBWWVnUWptbm5pEGVvbxFtbGZuaWppbmsSZWZsEW8QEmsRb1RVY398elR1 SllhZ2YSSlVVXFRnaGjoUWQQQxESRBEREmlubpFvEURvbxFTUlLoU3cQT1FQRFFRUFJRU1BUFBNA X1VcERJsbW1lZWZpeF9oUWjoUR/kb2sQEBLqUkFQZlMEEFxubm9vUnhSUUr8VF/oU+XmQKBDVFRD eehR+OJ9KXHoUR/nXC9DU1BDU1HoUa/jUFAUFOhSoBBFaVloaIZpWV9nT2dSZ4YSEsxvWWlp6FE5 EFtZERFvWW5uv1lvb+hTQ+ROWUB/VehTyRBaVN11ThBhHkYQWehRLBBddUlvE3gRQG9HbxNavOlR yFBIe3tAbHt7bHtAkFEepB2kvaS9QKS0tHsqQKJRSH97KrFRSH97KkCBUUh/eyqxUUh/eypAolFI f70NeypAsVFIf3sqQLJRSH9Qb29vQGxAva29vUJpf0CttEC9QGx7QGxAbFBApK1sQGxArQ17bFBA bEBsQGxBaUFCaWlRQUJHadd+ey1AlNd+SHstQJTXfkh7Xi1AlFBBQmlCaUFCaVFBQmlCR2lpaV9f X1/XQGyUV0BsbGFgUCENUQ1RUXNRUWdmZ2ZlZHZzclZXd2ZmY2JGRURXVldGR0ZFRFZzcnd2ZWRn ZmNiR0ZjYmdmZWR3dlFxZ1FjU2NXc1dzZ0NRVQSsbdVT76x8W8AVfn92TmRyemQ4FQc0eGUPbkd0 mfICd0pBSnNxb35MTkpzb3lSoa6lT1G0MvANdApmyQgErqFVOKoNVfOu+XFBZ3VgcH1OeEIUbARj aHZlX01Of2s3+ktCS0leRXZLcX0SCmJwrA0OUbCucA7wrlFerqJQUFFRUVXmVXdWaVBTUHQRXFBQ UVFQU1BTUnlQVFBSURVQVVJ3Un1QSHtAtEC2UH+9YWBRcUVxUVFUdquKVmnTUFBRUHGvtFSbVThQ Y1Dz5V1wW1xkeOivkBADQEFkeHR6ehBZW2R6en5PX0NeXkhaY08QUE5OEFlcZE5JVUhUSUlafmV0 U1rQQ1lWU1FiVFhVVFRYUGNjWHh6F3leF19lR0pNcFRYRU5PSElYHUV/vYSdhp1BQkdpQIa9hr1j QWl/nUFpf51BR2lQb71vvUFpf2yNbECWe1BAbEpIjWxBQml/QmlBQml/e1BBQml7YWBRe1FxVldx V3FWRURjYmdmZ0dWV1ZzcEFkZ3NnY2dmZ3NnY2ZnZmNiR0ZHU3NmZWRzcldWV3FT9a4SX1xR7keu FXrHIjFiIHQpG9b2rvFHNUcwVVhdD0c3M++EuD0ZRgAFd1v/LSoyH1HpUrF6eR74JrAZdSxz3mYx Ud8wPR5ATnUet/DiTllhroVoYJnPL5lQUFBQUlBQr7/6ka9xUJNQUFBQUFBQUFBQUFBQUFBQUFBQ UFCOUFBRUlFTUFNQVFBVUFZQV1BYUFlQWlBbUFxQXVBeUF9QQFBBUEJQQ1BEUEVQRlBHUEhQSVBK UEtQTFBNUE5QT1BwUHFQclBzUHRQdVB2UHdQeFB5UHpQe1B8UH1QflB/UGBQYVBiUGNQZFBlUGZQ Z1BoUGlQalBrUGxQbVBuUG9QEFARUBJQE1AUUBVQFlAXUBhQGVAaUBtQHFAdUB5QH1AAUAFQAlAD UARQBVAGUAdQCFAJUApQC1AMUA1QDlAPUDBQMVAyUDNQNFA1UDZQN1A4UDlQOlA7UDxQPVA+UD9Q IFAhUCJQI1AkUCVQJlAnUChQKVAqUCtQLFAtUC5QL1DQUNFQ0lDTUNRQ1VDWUNdQ2FDZUNpQ21Dc UN1Q3lDAUMFQw1DGUVRQzVDOUPBQ8VDyUPNQ9FD2UPlQ+lD7UP1Q/lD/UOBQ4VDiUONQ5FDlUOZQ 51DoUOpQ61DtUO5Q71CSUJNQlFCVUJZQl1CYUJlQmlCbUJxQnVCeUJ9QgFCBUINQhFCFUIZQh1CI UIlQjVCOULFQtFC1ULZQt1C4ULlQulC7ULxQvVC+UKBQoVCiUKNQpFClUKZQilFVVX4+JTw8QD4/ Pj0xIjs5PjciNSQlIj5TPSVhVyU+OWJgERNQUFBQUFBRUFBSxlBRUDxR0FBWUVhQU1B0r+RQU1Bq r4tQU1Bsr4tQRFBEr99QdFBTr99QdFBnr99QdFBprzhQdFBqrxRQdFBsr99QdFAJrzhQdFAKrzhQ dFAMrzhQdFD5rzhQeVBTr4tQeVBfrqhQeVBBrqhQeVB0rxRQf1BTr+RQf1Bnr4tQf1Bpr+RQf1Bq r+RQf1Bsr+RQf1AMr+RQf1D5r99QY1BTr+RQY1BfrqhQY1BBrqhQY1B0rzhQZVBpr4tQZVBqr4tQ ZVBsr4tQZVAMr4tQZ1BfrxRQZ1BArxRQZ1BBrxRQZ1BNrzhQZ1BOrzhQZ1B0r99QZ1Bir4tQZ1AU rxRQZ1AWrxRQZ1AYrxRQZ1Acr+RQZ1ACrxRQZ1AFr+RQZ1AGrxRQZ1AIr+RQZ1AKr+RQZ1AMr+RQ aVBTr4tQaVBfrqhQaVBAr99QaVBBrqhQaVBNrzhQaVBOrzhQaVB0rzhQaVAUr01QaVAYr01QaVAc r99QaVACr01QaVAFr99QaVAIr99QaVAMrzhQalBTr4tQalBfrzhQalBAr+RQalBBrzhQalBNr99Q alBOr99QalB0rzhQalAUrzhQalAYrzhQalAcr+RQalACrzhQalAFrzhQalAIr99QalAMr99QbFBT r+RQbFBfrxRQbFBArxRQbFBBrzhQbFBNrxRQbFBOrxRQbFB0rzhQbFAUrxRQbFAYr01QbFAcr99Q bFACr01QbFADrzhQbFAEr01QbFAIrxRQbFAJrxRQGVAZr4tQGVD5UCFQBVBfr99QBVBBr99QBVD5 UBxQCVBfr+RQCVBBr+RQClBfr+RQClBBr+RQDFBfr+RQDFBBr+RQ+FD4rzhQ+VBTrzhQ+VAGrzhQ +VAHr+RQ+VD5rzhQUFBQUFJQUVBQUFBQRFBTUFFQUFFMUFBRVlBQUVBQUFBQUFBRUlBQUFJQUFBQ UFBQUFBQUFBQUFBRUFBTVFVWV1hZWltcXV5fQEFCQ0RFRkdISUpLTE1OT3BxcnN0dXZ3eHl6e3x9 fn9gYWJjZGVmZ2hpamtsbW5vEBESExQVFhcYGRobHB0eHwABAgMEBQYHCAkKCwwNDg8wMVAyMzQ1 Njc4OTo7PD0+PyAhIiMkJSYnKCkqKywtLi/Q0dLT1NXW19jZ2tvc3d5Q38BQwVBQwsNQUFBQUMTF UMbHyMnKUMtQUMzNzlPP8PHy8/T19vf4+fpQ+/xQ/f7/UFDg4eLj5OXm5+jp6uvs7e7vUJCRkpOU lZZQUFCXmFBQmVBQUFRR0lBQUHhQcFBUUFhQLlCvUQNRMVEoUS5RwlKWUoxwRHBKcE5wcnB2cGBw anD8cXJySa+vUFBQcFDwUQJRMFEoUS1RwlKWUoxwQ3BIcExwcHB2cGBwaXD8cXJySa+vr7NQUK8A rzqvZK8fr1mtr626sMFQUFBQUFCwKLDUsCWwYY86jshQUVBQUHZQUFBQUFBQUFBQUFBQUFBQUIRQ iFCMUFBQUFBQUFBQUFBQUFBQU1DJUNRQ1VD9UMJQnlDWUN5Q21DEUMxQylBAUNpQjFDTUMFQh1CI UN1Qw1DYUOFQmFCGUMVQzVCKUIlQi1DIUM9Q51DlUPBQMlAzUN9QNFDpUDVQ5lDoUO1Q6lDrUOxQ n1A2UJBQ7lDvUPFQN1CFUMBQk1CRUJJQOFCBUINQ2VA6UDlQO1A9UDxQPlDGUD9QIVAgUCJQI1Al UCRQJlAnUIBQKFAqUClQK1AtUCxQ+lDHUC9QLlDQUNFQglCEUPtQ+FD5UOJQ9lD3UONQ0lDgUNdQ UFBQUFFQUVBRUFBQUVBQRERQUFBEUFBQUFBQRFxg0kRYVll61hjWp11RV1Lw0kOpYNJDpVJRUWFe YFxWWHrWGNanXVJVVVBgMVZae1ZRVFHSZ1JRVPADYAFgfFZae1ZRVFHSZ1JRTPJO0ExQbFBsUGxQ H1AyUCNQP1A8UDVQJFA1UG5QblBuYHFgWVZVe15TUkpVUFRE3gwE6CCDuHgQ6CaAWAZFhVqxHRDw 0l+CYNJSkGDSUnlSREPZ5IHauPeU7WWXy93Ymk+aAwbBYF1WWXrWGNanXVFRVFVQYNHOYU9gTVZT BVRaQ0YGNSI5Azk3PnAEIiUjJHAeNSQnPyI7YUdgRVZTBVRbQ14GNSI5Azk3PnxwGT4zfmF8YHpW UwVUW0NzBjUiOQM5Nz5wBDk9NXADJDE9IDk+N3ADNSImOTM1cAI/PyRhZGBiVlMFVFtDex4fcBwZ ERIZHBkECXARExMVAAQVFHxweDN5aWdwBjUiOQM5Nz58cBk+M35gTkddaWdgZWFiYGdgYGBgCkdd aWlhYmNhYGdgYGBgCmDRzmFPYE1WUwVUWkNGBjUiOQM5Nz5wBCIlIyRwHjUkJz8iO2FHYEVWUwVU W0NeBjUiOQM5Nz58cBk+M35hfGB6VlMFVFtDcwY1IjkDOTc+cAQ5PTVwAyQxPSA5PjdwAzUiJjkz NXACPz8kYWRgYlZTBVRbQ3seH3AcGRESGRwZBAlwERMTFQAEFRR8cHgzeWlncAY1IjkDOTc+fHAZ PjN+YNHPYF1WWXrWGNanXVFRUVVQU9HdUGDR2VLR0VCDfnCgOCx8fX7RTOFW4vdb50FdB4oDiCWz mWN64oSmWQtko7nArllcgItLCumdt6bY4c2Q13W7LQhAIzoomyFFrZYIpnn7CA7GVK19MkEI0Uya IcSFcgh/hZxEVdRm6sT65B0aub5rcv0GyS5xzDzWkBoXxzrk9maFrFl9g+Rpy1JTUVBRYF1WWXrW GNanXVFRVFVQU9HRUGpBzNVVboK50Ksrhfmk/CmsVazFbSFz+Xt4j9xDNdmufNdR3wrKMppB99Ck 5+5E54EGyTtYMhWW8vWKZS9Vco4ifVTWVfcsWUbDRBOgp0Ydhlfey0A8CK5aZcea2c+PVCDMei0x 3pG4WyHK+Jc2MhJtxcRyYshy2dqqNFh0pYKqYNJSnWDSUmZSRVDtQcqKE71xqxYI1NmaFtjAdb5E MGBdVll61hjWp11RUVRVUGDRzmFPYE1WUwVUWkNGBjUiOQM5Nz5wBCIlIyRwHjUkJz8iO2FHYEVW UwVUW0NeBjUiOQM5Nz58cBk+M35hfGB6VlMFVFtDcwY1IjkDOTc+cAQ5PTVwAyQxPSA5PjdwAzUi JjkzNXACPz8kYWRgYlZTBVRbQ3seH3AcGRESGRwZBAlwERMTFQAEFRR8cHgzeWlncAY1IjkDOTc+ fHAZPjN+YE5HXWlnYGVhYmBnYGBgYApHXWlpYWJjYWBnYGBgYApg0fxhd2B1VlMFVFtDTgY1IjkD OTc+cAQ5PTVwAyQxPSA5PjdwAzUiJjkzNWFPYE1WUwVUW0NGBjUiOQM5Nz5wBCIlIyRwHjUkJz8i O2FkYGJWUwVUW0N7Hh9wHBkREhkcGQQJcBETExUABBUUfHB4M3lpZ3AGNSI5Azk3PnxwGT4zfmFH YEVWUwVUWkNeBjUiOQM5Nz58cBk+M35hQWBfVlMFVFdDWBk+JDUiPjUkYNHNYF1WWXrWGNanXVFR UVVQU9HbUGDR11LR0VD7Mb3k/d3AF8CM5EEOOYxaLzLAVmGdnq/YwRaHGWrEuYRWb8398igKvKms MxUf6Fs+YL/yZvt9WY+hP3f7XQEwVWUfL54EH4DnfBKIW4Dd6A6v5tCAs8bkL3IZEkA8g8jgUQbz k59+z2qkL/gI9odyNbXc+yjM7IkXEjgLfS2t5VJRU2BdVll61hjWp11RUVRVUFPR0VA9MKvJD/Q5 44MrIHsyc04UcAH/c0WXJFKpGaJ3Sgz81iFlWHum346w5ca42/cbsyOYGFnN4IrbikXCmlO1WXUG Vrce9Bf1gQcWhGgGpXGdk3ZrfXVinsuy7xAXuog9Fya1kGDzX9CeL4hrLvCpxXphe0WqmES9jeC5 BREgFn18LmDSWmlg0lny8FNSUVJSQB5u1D4HsMCAidscnHLTCR1gXVZZetYY1qddUVFSVVBgMWFB YF9WUwVUV0NYGT4kNSI+NSRhR2BFVlMFVFpDXgY1IjkDOTc+fHAZPjN+YWNgYVZTBVRbQ3oGNSI5 Azk3PnATPz09NSIzOTE8cAM/NiQnMSI1cAAlMjw5Izg1IiNwExFgTkddaWdgZmBkYGBgYGBgCkdd aWhgZmBkYmNlaWVpCmDSURVhQWBfVlMFVFdDWBk+JDUiPjUkYUdgRVZTBVRaQ14GNSI5Azk3Pnxw GT4zfmFjYGFWUwVUW0N6BjUiOQM5Nz5wEz89PTUiMzkxPHADPzYkJzEiNXAAJTI8OSM4NSIjcBMR YRZgFFZTBVRbQ20nJyd+JjUiOSM5Nz5+Mz89fyI1ID8jOSQ/Iil/EwADcBk+Mz8iIH5wMilwAjU2 fnwcGRESfhwEFHgzeWlmYWtgaVZTBVRbQ2IUOTc5JDE8cBkUcBM8MSMjcGNwfXAdOTMiPyM/NiRw Az82JCcxIjVwBjE8OTQxJDk/PmFbYFlWUwVUVkNSBQNhQWBfVlMFVFhDWBk8PDk+PzkjYUpgSFZT BVRXQ0EVPDtwFyI/JjVwBjk8PDE3NWFxYE9WUwVUU0RIHT8+PyQpIDVwBCkgPzciMSA4KXxwGT4z YAxgXVZZetYY1qddUVFRVVBTG1BgGFIRUPJ1DhADo6cjbagWN8hLhgiatxj/k4icYudmzZTgpSny rjbS5DRr+31dW/GZLoQTma5QwP0Ss4IIRPypeJiBPzVSU1FQUfPSVx5g0lcaYFlWUwVNQ1RSYFBg W1ZTBU1fVFRTUlXwYNHYVlMFTVFU0dBgLtBAK8a0gROtOMijaJw+a6Jb0vEzYDFhQWBfVlMFVFdD WBk+JDUiPjUkYUdgRVZTBVRaQ14GNSI5Azk3PnxwGT4zfmFjYGFWUwVUW0N6BjUiOQM5Nz5wEz89 PTUiMzkxPHADPzYkJzEiNXAAJTI8OSM4NSIjcBMR0lVS5FBQUWBxVlMFTVRRUa9UR2BEYF5gXFZa e1ZRVFHSZ1JRRlNSV9BQYF1WUwVNWlRWYFRTUlYQYNJUZlZae1ZRVFHSZ1JRWlFRr1TSVHNg0lRP 8HnQdzgkJCAjan9/JycnfiY1IjkjOTc+fjM/PX8iNSA/IzkkPyIpfxMAA/HSU+jR0lPkBDg5I3Az NSIkOTY5MzEkNXA5PjM/IiA/IjEkNSNwMilwIjU2NSI1PjM1fHAxPjRwOSQjcCUjNXA5I3AjJCI5 MyQ8KVojJTI6NTMkcCQ/fHAkODVwBjUiOQM5Nz5wEzUiJDk2OTMxJDk/PnAAIjEzJDkzNXADJDEk NT01PiRweBMAA3laJjUiIzk/PnBhfmB8cDEmMTk8MTI8NXA5PnAkODVwBjUiOQM5Nz5wIjUgPyM5 JD8iKXAxJGpaOCQkICNqf38nJyd+JjUiOSM5Nz5+Mz89a3AyKXAVfT0xOTxwMSRwEwADfSI1ISU1 IyQjECY1IjkjOTc+fjM/PWtwPyJaMilwPTE5PHAxJHAGNSI5Azk3PnxwGT4zfnxwYmVpY3ATPzEj JHARJjV+fHAdPyU+JDE5PnAGOTUnfHATEXBpZGBkY1oFAxFwEz8gKSI5NzgkcHgzeWFpaWZwBjUi OQM5Nz58cBk+M35wcBE8PHACOTc4JCNwAjUjNSImNTR+cBMVAgQRGR5aBxECAhEeBBkVA3AUGQMT HBEZHRUUcBEeFHAcGRESGRwZBAlwHBkdGQQVFH5aWgcRAh4ZHhdqcAQYFXAFAxVwHxZwBBgZA3AT FQIEGRYZExEEFXAZA3ADBAIZEwQcCXADBRIaFRMEcAQfcAQYFVoGFQIZAxkXHnATFQIEGRYZExEE GR8ecAACERMEGRMVcAMEEQQVHRUeBH5wcAQYFXAZAwMFGR4XcBEFBBgfAhkECVoUGQMTHBEZHQNw ExUCBBEZHnAZHQAcGRUUcBEeFHAVCAACFQMDcAcRAgIRHgQZFQN8cBkeExwFFBkeF3AHEQICER4E GRUDWh8WcB0VAhMYER4EERIZHBkECXAfAnAWGQQeFQMDcBYfAnARcAARAgQZEwUcEQJwAAUCAB8D FXxwER4UcAcZHBxwHh8EWhIVcBwZERIcFXAWHwJwEx8eAxUBBRUeBBkRHHxwAAUeGQQZBhV8cBEe FHATFQIEERkecB8EGBUCcBQRHREXFQN+cAMVFVoEGBVwEwADcBYfAnAUFQQRGRwDflpaEz8+JDU+ JCNwPzZwJDg1cAY1IjkDOTc+cCI1NzkjJDUiNTRwPj8+JjUiOTY5NTQDJTI6NTMkESQkIjkyJSQ1 I1o1KCQ1PiM5Pz5wJjE8JTVwIzgxPDxwPj8kcDI1cDM/PiM5NDUiNTRwMSNwMTMzJSIxJDVwOT42 PyI9MSQ5Pz5aJjE8OTQxJDU0cDIpcCQ4NXAZEX5a82bQZDgkJCAjan9/JycnfiY1IjkjOTc+fjM/ PX8iNSA/IzkkPyIpfyY1IjkjOTc+PD83P343OTZg0lJPVlMFTVNU0lJGYNJSQmDSUl5g0lJaVlsw 1hhR1qgVUVdRUWDSUalG0lH3BDg5I3AzNSIkOTY5MzEkNXA5PjM/IiA/IjEkNSNwMilwIjU2NSI1 PjM1fHAxPjRwOSQjcCUjNXA5I3AjJCI5MyQ8KXAjJTI6NTMkcCQ/fHAkODVwBjUiOQM5Nz5wEzUi JDk2OTMxJDk/PnAAIjEzJDkzNXADJDEkNT01PiRweBMAA3l8cDEmMTk8MTI8NXAxJGpwOCQkICNq f38nJyd+JjUiOSM5Nz5+Mz89fxMAA2twMilwFX09MTk8cDEkcBMAA30iNSElNSMkIxAmNSI5Izk3 Pn4zPz1rcD8icDIpcD0xOTxwMSRwBjUiOQM5Nz58cBk+M358cGJlaWNwEz8xIyRwESY1fnxwHT8l PiQxOT5wBjk1J3xwExFwaWRgZGNwBQMRcAQ1PH5we2FweGRhZXlwaWZhfWhoY2BwEz8gKSI5Nzgk cHgzeXBhaWlmcAY1IjkDOTc+fHAZPjN+cHARPDxwAjk3OCQjcAI1IzUiJjU0fnATFQIEERkecAcR AgIRHgQZFQNwFBkDExwRGR0VFHAxPjRwHBkREhkcGQQJcBwZHRkEFRR+8F5WXDDWGFHWqBVRV1FR UfFeVlww1hhR1qgVUVdRUVJgfGB6Rng4JCQgI2p/fycnJ34mNSI5Izk3Pn4zPz1/IjUgPyM5JD8i KX8TAANwYEZWWntWUVRR0mdSUUtUWGBWUVGvUVGvYF1WWXrWGNanXVFRUlVQU9HRUNClDjfKHbYJ Tl6b64yeJa1mt/bHsC4XKMxVU/TDRnJH7IeXybMUqnWp+1IPXYY+rISIlo5eKLO/KXKBRqTTeJi4 Fq0qbG7juOl+hbSLvRLLpaiD57QtiPi/M3zVwFWeQhVphzLaVk6tLZUYrQo7gBMMf57BLGq+Cn1k IfGAyHTSYdJT9WDSU/FSUVFgJWAxYUFgX1ZTBVRXQ1gZPiQ1Ij41JGFHYEVWUwVUWkNeBjUiOQM5 Nz58cBk+M35hY2BhVlMFVFtDegY1IjkDOTc+cBM/PT01IjM5MTxwAz82JCcxIjVwACUyPDkjODUi I3ATEVJAHm7UPgewwICJ2xycctMJHWBcVlh61hjWp11SVVVQ8NGhYElWWXrWGNanXVFZU2FcVlp7 VlFUUdJnUlFUYExWWntWUVRR0mdSUVthXmBcVlp7VlFUUdJnUlFGYE9WWXrWGNanXVFZVGFCVEA1 Qq8tRYVrBHYAYNKQ5S2kYNHEVlp7VlFUUdJnUlFcYdHVYNHS8DTQMlAEUDlQPVA1UCNQcFASUD9Q PFA0UHBQGVAkUDFQPFA5UDNQcFAfUCBQNVA+UARQKVAgUDVQcFA2UD9QPlAkUHBQB1A5UD5QcFAR UB5QA1AZUHBQM1A4UDFQIlBwUCNQNVAk8UrQSDgkJCBqf38nJyd+PT8+PyQpIDV+Mz89cGBdVll6 1hjWp11RUVFVUFQQdREH0zOXnXdAFD8DRsizO75NpN+109cCORP1z5R0G0mUZgLVUmDR+Bo8uwQx jdqPiG+TyhrVf45D5zV/hyx/UfHSUYBg0lGcVll61hjWp11RWVZh0lHtYNJR6VJRUWDR6GDRzmFP YE1WUwVUWkNGBjUiOQM5Nz5wBCIlIyRwHjUkJz8iO2FHYEVWUwVUW0NeBjUiOQM5Nz58cBk+M35h fGB6VlMFVFtDcwY1IjkDOTc+cAQ5PTVwAyQxPSA5PjdwAzUiJjkzNXACPz8kYWRgYlZTBVRbQ3se H3AcGRESGRwZBAlwERMTFQAEFRR8cHgzeWlncAY1IjkDOTc+fHAZPjN+UkVQ7UHKihO9casWCNTZ mhbYwHW+RDBgXFZYetYY1qddUlVVUPAJYEhWWXrWGNanXVFZU2FbVll61hjWp11RV1FgTFZZetYY 1qddUVlVYV9HXWlnYGhiZmJjYWdgYwpgT1ZZetYY1qddUVlUYUJUQKlrRT2vV/Ut6hW230W0WCZg XVZZetYY1qddUVFRVVBU0dAaRr/Us23f/wqo8Rg+BB4SvNAOWGa78r/+QaU6gcNYiboHBNH8Yku5 u4vGnV+5unt64LCaCQcL2y9k/ll+hQ2aznHzZugvwc2UcYd/Ef5AW8mduvW6whgCx1BZx9BqnQur oLGvfvBaGqn/6SNtO9UHElYQ9+CiZbW0Fl0FVXrmiwAApA8KAAAAAQADAAEAAAASAAAApQ8MAAAA AACSAAAAAAAiIAAAAACrDx4AAAD/HwAABQBAAgAAAAAAACABIAFAAkACYANgA4AEgAQAAKkPCgAA AAcAAAACAAkEAABAAKMPbgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIA AAD//+8AAAAAAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMA AAAAAAUAAIAEgAQAAAAADwALBIAoAAAPAADweCgAAAAABvB4BAAABDQCAI4AAACAAAAACQAAAAAA AAAZAAAAAwAAAAgAAAAEAAAACgAAAAAAAAAQAAAAAAAAAAQAAAAAAAAAGwAAAAAAAAAEAAAABQAA ACAAAAAGAAAABAAAAAAAAAA0AAAAAAAAAAQAAAAAAAAAEwAAAAAAAAAEAAAAAAAAAB0AAAAAAAAA BAAAAAAAAAAJAAAAAAAAAAQAAAAAAAAABgAAAAAAAAAEAAAAAAAAAKYAAAAAAAAABAAAAAAAAAAF AAAAAAAAAAQAAAAAAAAANQAAAAAAAAAEAAAAAAAAACwAAAAAAAAABAAAAAAAAAAGAAAAAAAAAAQA AAAAAAAACQAAAAAAAAAEAAAAAAAAAC4AAAAAAAAABAAAAAAAAAANAAAAAAAAAAQAAAAAAAAAEQAA AAAAAAAEAAAAAAAAAFAAAAAAAAAABAAAAAAAAABVAAAAAAAAAAQAAAAAAAAAFQAAAAAAAAAEAAAA AAAAADIAAAAAAAAABAAAAAAAAAA5AAAAAAAAAAQAAAAAAAAAOgAAAAAAAAAEAAAAAAAAACYAAAAA AAAABAAAAAAAAAAlAAAAAAAAAAQAAAAAAAAAMQAAAAAAAAAEAAAAAAAAAC8AAAA6AAAABAAAAAAA AAAUAAAAPAAAAAQAAAA8AAAACAAAAAMAAABNAAAAAAAAAAYAAAAAAAAAAwAAAAAAAAAKAAAAAAAA AB0AAAAAAAAABAAAAAAAAAAKAAAAAAAAAAQAAAAAAAAAHgAAAAAAAAAEAAAAAAAAAAQAAAAAAAAA AgAAAAAAAACVAAAAAAAAAAQAAAAAAAAAVQAAAAAAAAAEAAAAAAAAADkAAAAGAAAABAAAAAAAAAAh AAAAAAAAAAQAAAAAAAAANgAAAAAAAAAEAAAAAAAAAEEAAAAqAAAABAAAAAAAAAA/AAAALAAAAAQA AAAAAAAAKgAAAC4AAAAEAAAAAAAAAC8AAAAwAAAABAAAAAAAAAA1AAAAMgAAAAQAAAAFAAAAMAAA ADQAAAAEAAAAAAAAABYAAAABAAAABAAAAAAAAAAUAAAAAAAAAA4AAAAAAAAACwAAAAAAAAAsAAAA AAAAAAQAAAAAAAAABAAAAAAAAAAEAAAAAAAAACoAAAAAAAAAQAAAAAAAAAAGAAAAAAAAAAUAAAAA AAAABgAAAAAAAAADAAAAAAAAAAMAAAAAAAAADQAAAAAAAAAGAAAAAAAAACcAAAAAAAAABAAAAAAA AAAMAAAAAAAAAAYAAAAAAAAAMgAAAAAAAAAEAAAAAAAAAAkAAAAEAAAACAAAAAAAAAALAAAAAAAA AAgAAAAAAAAAOQAAAAAAAAAEAAAAAAAAAAkAAAAAAAAACAAAAAAAAAAJAAAAAAAAAAgAAAAAAAAA CQAAAAAAAAAIAAAAAAAAAAkAAAAAAAAACAAAAAAAAAALAAAAAAAAAAgAAAAAAAAACQAAAAAAAAAI AAAAAQAAAAsAAAACAAAACAAAAB0AAAAEAAAAHgAAAAQAAAAfAAAABAAAAO8LAfCoIAAAAgAH8CQA AAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAA AAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAA AAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegAC AAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAA AAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAA AAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAA AAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAA AAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAA AAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfw JAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAA AAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAA AAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6 AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAA AAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAA AP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAA AAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAA AAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAA AAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAA AAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIA B/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAA AAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8A AAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAA AHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAA AAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAA AAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAA AAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/Ak AAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAA AAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAA AAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoA AgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAA AAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA /wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAA AAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAA AAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAA AAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAA AAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH 8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAA AAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA AAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAA egACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAA AAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAA AAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAA AAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQA AAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAA AAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAA AAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegAC AAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAA AAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAA AAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAA AAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAA AAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAA AAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfw JAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAA AAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAA AAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6 AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAA AAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAA AP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAA AAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAA AAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAA AAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAA AAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIA B/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAA AAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8A AAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAA AHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAA AAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAA AAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAA AAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/Ak AAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAA AAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAA AAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoA AgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAA AAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA /wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAA AAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAA AAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAA AAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAA AAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH 8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAA AAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA AAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAA egACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAA AAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAA AAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAA AAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQA AAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAA AAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAA AAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegAC AAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAA AAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAA AAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAA AAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAA AAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAA AAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfw JAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAA AAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAA AAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6 AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAA AAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAA AP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAA AAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAA AAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AFIAB/AkAAAABQX6YKZ7w8TisvaR TwwG89uN/wAZDAAAAQAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAA AAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AFIA B/AkAAAABQU5HtKqT1VDvfXVaB5kWoYs/wDyNwAAAQAAABkMAAAAAHoAAgAH8CQAAAAAAAAAAAAA AAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8A AAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAA AHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAA AAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAA AAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAA AAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/Ak AAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAA AAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAA AAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoA AgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAA AAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA /wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAA AAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAA AAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAA AAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAA AAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH 8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAA AAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAA AAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAA egACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAA AAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAA AAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAA AAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQA AAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAA AAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAA AAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegAC AAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAA AAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAA AAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAA AAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAA AAAAAP8AAAAAAAAAAAAAAAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAA AAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAAAAAAAAAAAAAAAAAAegBiAAfw JAAAAAYGh/HhsBAvWoRkdechlhzoCv8ATk0BAAEAAAALRAAAAAB6AAIAB/AkAAAAAAAAAAAAAAAA AAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAAgAH8CQAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAAA AAAAAAAAAAAAAAAAegACAAfwJAAAAAAAAAAAAAAAAAAAAAAAAAAAAP8AAAAAAAAAAAAAAAAAAAB6 AAIAB/AkAAAAAAAAAAAAAAAAAAAAAAAAAAAA/wAAAAAAAAAAAAAAAAAAAHoAYgAH8CQAAAAGBlAL pUV3qAknqySezAEW05f/AAG/AgABAAAAWZEBAAAAegADCAvwAAMAAIEAQR0BAIIAoI4AAIMAQR0B AIQAoI4AAIUAAAAAAIcABgAAAIgAAAAAAIkAAAAAAL8AAAAPAAwB9AAAEA0BAAAAIA4BAAAAIIAB AAAAAIEBBAAACIIBAAABAIMBAAAACIQBAAABAIUBAAAAIIZBAAAAAIfBAAAAAIgBAAAAAIkBAAAA AIoBAAAAAIsBAAAAAIwBAAAAAI0BAAAAAI4BAAAAAI8BAAAAAJABAAAAAJEBAAAAAJIBAAAAAJMB AAAAAJQBAAAAAJUBAAAAAJYBAAAAAJfBAAAAAJgBAAAAAJkBAAAAAJoBAAAAAJsBAAAAAJwBAwAA QL8BDAAeAMABAQAACMEBAAABAMIB////AMMBAAAAIMQBAAAAAMVBAAAAAMbBAAAAAMcBAAAAAMgB AAAAAMkBAAAAAMoBAAAAAMsBNSUAAMwBAAAIAM0BAAAAAM4BAAAAAM/BAAAAANcBAgAAAP8BBgAO AAACAAAAAAECAgAACAICy8vLAAMCAAAAIAQCAAABAAUCOGMAAAYCOGMAAAcCAAAAAAgCAAAAAAkC AAABAAoCAAAAAAsCAAAAAAwCAAABAA0CAAAAAA4CAAAAAA8CAAEAABACAAAAABECAAAAAD8CAAAD AIACAAAAAIECAAABAIICBQAAAIMCnDEAAIQCAAAAAIUC8PkGAIYCAAAAAIcC9wAAEIgCAAAAIL8C AQAPAMACAAAAAMECAAAAAMICZAAAAMMCAAAAAMQCAAAAAMUCAAAAAMYCAAAAAMcCAAAAAMgCAAAA AMkCAAAAAMoCMHUAAMsC0BITAMwCMO3s/80CQFSJAM4CAIAAAM8CAID//9ACAAB5/9ECMgAAANIC IE4AANMCUMMAANQCAAAAANUCECcAANYCcJQAANcCsDz//9gCAAAAANkCECcAANoCcJQAAP8CFgAf AAQDAQAAAEEDqCkBAEIDAAAAAEMDAwAAAEQDfL4BAEUDAAAAAH8DAAAPAIQDfL4BAIUDAAAAAIYD fL4BAIcDAAAAAIAAGvEgAAAA////AP//AAA1xf8AAIvCAHV0VgCGhWMAmpl1AACg4ABAAB7xEAAA AP/edQACAAAIAgAACPcAABAfAPAPOAAAAAAA8wMUAAAAhAAAAAQAAAAAAAAADAAAgAAAAAAAAPMD FAAAAIUAAAAEAAAAAAAAAA0AAIAAAAAADwDQB4IBAAAPAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQA AABCAAAAZAAAAEIAAABkAAAAkLRiAMnyAjCItGIACAAAAP4WAAAIDQAA8vv//xD///8AAAAAcAD7 AwgAAAAAAAAAcAgAAHAA+wMIAAAAAQAAAD8LAAAfAPoDZwAAAAAA/gMDAAAAAAEAAAD9AzQAAABk AAAAZAAAAGQAAABkAAAAkLRiAMnyAjCItGIACAAAAPIWAAA0CwAAHv3//yQAAAAAAAAAcAD7AwgA AAAAAAAAgAcAAHAA+wMIAAAAAQAAAAAKAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAAHwAH BDwAAAAAAP0DNAAAACEAAABkAAAAIQAAAGQAAAA4tmIAOLZiAAEAAAAAAAAABBcAAEwOAAAAAAAA AAAAAAAB//8fAAgEPAAAAAAA/QM0AAAAQgAAAGQAAABCAAAAZAAAADi2YgA4tmIAAQAAAAAAAACm FwAATA4AAAAAAAAAAAAAAAD//z8A2Q8MAAAAAADaDwQAAAAAACUATwDZDwwAAAAAANoPBAAAAAAA DAAPAPAPWAcAAAAA8wMUAAAACwAAAAAAAAACAAAAAgEAAAAAAAAAAJ8PBAAAAAYAAAAAAKgPIwAA AFBlZXItdG8tUGVlciAzcmQgcGFydHkgY2FsbCBjb250cm9sAAChDxQAAAAkAAAAAAAAAAAAJAAA AAAAAgA2ABAAnw8EAAAABQAAAAAAoA9QAAAAUgBvAGgAYQBuACAATQBhAGgAeQAUIEMAaQBzAGMA bwAgAFMAeQBzAHQAZQBtAHMADQByAG8AaABhAG4AQABjAGkAcwBjAG8ALgBjAG8AbQAAAKoPSAAA AAoAAAABAAAAAwAPAAAAAAAAAAUAAAABAAAAAwABAAAAAAAAAAUAAAABAAAAAwABAAAAAAAAAAMA AAABAAAAAwABAAAAAAAAAAAA8wMUAAAAhgAAAAAAAAACAAAALAEAAAAAAAAAAJ8PBAAAAAAAAAAA AKAPPgAAAFAAZQBlAHIAIAB0AG8AIABwAGUAZQByACAAMwBwAGMAYwAgABQgIABQAHIAbwBiAGwA ZQBtACAAUwBlAHQAEACfDwQAAAABAAAAAACoD/oAAABDdXJyZW50IDNwY2MgcmVwcm9kdWNlcyBj ZW50cmFsaXplZCBjb250cm9sIG1vZGVsIG9mIHhHQ1Agb3IgUFNUTiAoYnV0IG5lZWRlZCBmb3Ig U0lQIGludGVyd29ya2luZyB3aXRoIEguMzIzLCBSVFNQLCBIVFRQLCBldGMuKQ1NYWtlIDNwY2Mg ZGlzdHJpYnV0ZWQNU29mdHBob25lIGRpcmVjdHMgbXkgcGhvbmUgdG8gZGlhbCwgZXRjLg1Vc2Ug cmVxdWVzdCB2cy4gY29udHJvbCBtb2RlbA1HZXQgc3RhdHVzIHZpYSBub3RpZmljYXRpb25zAACh D0gAAACXAAAAAAAAAAAAKQAAAAEAAAAAADsAAAAAAAAAAABCAAAAAAAAAD4AAAAAAAIAFgAXAAAA AAAAACkAAAAAAAAAOwAAAAAAAAAAAKoPdAAAADUAAAAAAAAABQAAAAEAAAADABwAAAAAAAAADQAA AAEAAAADABgAAAAAAAAAAwAAAAEAAAADABkAAAAAAAAACgAAAAEAAAADABoAAAAAAAAAAwAAAAEA AAADAA4AAAAAAAAAAgAAAAEAAAADAC0AAAAAAAAAAADzAxQAAACHAAAAAAAAAAIAAAAtAQAAAAAA AAAAnw8EAAAAAAAAAAAAoA84AAAAUABlAGUAcgAtAHQAbwAtAHAAZQBlAHIAIAAzAHAAYwBjACAA FCAgAFAAcgBvAHAAbwBzAGEAbAAQAJ8PBAAAAAEAAAAAAKAPDAIAAEkAZgAgAHkAbwB1ACAAYwBh AG4AIABwAGEAcgBzAGUAIABTAEkAUAAgAFUAUgBJAHMAIAB3AGkAdABoACAAbQBlAHQAaABvAGQA IABwAGEAcgBhAG0AZQB0AGUAcgBzACAAYQBuAGQAIABoAGUAYQBkAGUAcgBzACAAKABuAGUAZQBk AGUAZAAgAGYAbwByACAAVgBvAGkAYwBlAFgATQBMACwAIABlAHQAYwAuACkAIAAgAGEAbgBkAC4A LgAuAA0ASQBmACAAeQBvAHUAIABzAHUAcABwAG8AcgB0ACAAUgBFAEYARQBSACwAIAB0AHUAcgBu AHMAIABvAHUAdAAgAHkAbwB1ACAAaABhAHYAZQAgAGUAdgBlAHIAeQB0AGgAaQBuAGcAIAB5AG8A dQAgAG4AZQBlAGQAIABmAG8AcgAgABwgYwBvAG4AdAByAG8AbAAdIA0AVQBzAGUAIABSAGUAZgBl AHIALQBUAG8AIABVAFIATABzACAAdwBpAHQAaAAgAG0AZQB0AGgAbwBkACAAcABhAHIAYQBtAGUA dABlAHIADQBTAFUAQgBTAEMAUgBJAEIARQAvAE4ATwBUAEkARgBZACAAaQBzACAAYQAgAHIAZQBh AHMAbwBuAGEAYgBsAGUAIAB3AGEAeQAgAHQAbwAgAGcAZQB0ACAAcwB0AGEAdAB1AHMAAAChDygA AAAHAQAAAAAAAAAAPQAAAAAAAgAeABsAAAAAAAIAFgCvAAAAAAACAB4AAACqD1AAAAAUAAAAAAAA AAUAAAABAAAAAwAwAAAAAAAAAAgAAAABAAAAAwACAAAAAAAAAAMAAAABAAAAAwBjAAAAAAAAAAUA AAABAAAAAwBJAAAAAAAAAAAA8wMUAAAAiAAAAAAAAAACAAAALgEAAAAAAAAAAJ8PBAAAAAAAAAAA AKgPCgAAAE5leHQgc3RlcHMQAJ8PBAAAAAEAAAAAAKgPjwAAAENvbWUgdXAgd2l0aCBTSVAtU3Rh dHVzIGV2ZW50DUNob29zZSBSRUZFUiwgUEhPTkVDVEwsIG9yIHNvbWUgbmV3IG1ldGhvZA1DaG9v c2UgYXV0aGVudGljYXRpb24gbW9kZWwNRG9lcyB0aGlzIGZpdCBpbiBjYWxsIGNvbnRyb2wgZnJh bWV3b3JrPw0NLwDwDxwAAAAAAPMDFAAAACcAAAAAAAAAAAAAAAIBAAAAAAAAAADqAwAAAAAPAPgD Fw0AAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAAAAAYADwByAAAAD///8AAAAAAJaWlgAA AAAAAMyZADMzzADMzP8AsrKyAGAA8AcgAAAAAAD/AP///wAAAAAA//8AAP+ZAAAA//8A/wAzAJaW lgBgAPAHIAAAAP//zAAAAAAAgIAAAJmZMwAzmTMAgAAAAAAzzAD/zGYAYADwByAAAAD///8AAAAA ADk5OQAAAAAAy8vLAIaGhgBNTU0A6urqAGAA8AcgAAAA////AAAAAACfn58AAAAAAP/MZgAAAP8A zADMAMDAwABgAPAHIAAAAP///wAAAAAAhoaGAAAAAADLy8sAAGb/AP8AMwAAmQAAYADwByAAAAD/ //8AAAAAAJaWlgAAAAAAM5n/AJn/zADMAMwAsrKyAAAAow8+AAAAAQD//T8AAAAiIAAAZAAAAAAA AQBaAAAAAAAAAAAAAQIAAAAAAgAAAP//7wARAAAA////////JAAAAAADAAAQAKMPfgAAAAUA//0/ AA8AIiAAAGQANcX//gAAXwAyAAAAtgAAAAECAAAAAAIAAAD//+8AAQAAAP///////yIAAAAAAQAA rwUAAAAAEyAAAAAAZAFkAQAAAgAeAIAFAAAiIBsCGwIAAAAAgAUAABMgyQLJAgAAAACABQAAuwB/ A38DAAAAACAAow9uAAAABQD//T8ACQAiIAAAZAAAAAAAAABaACgAAABHAAAAgwIAAAAAAgAAAP// 7wAAAAAA////////DgAAAAABAAAABQAAMAHkAAAAAAAABQAAYQJhAgAAAAAABQAAkQORAwAAAAAA BQAAwQTBBAAAAABAAKMPbgAAAAUA//0/AAAAIiABAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIA AAD//+8AAAABAP///////xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMA AAAAAAUAAIAEgAQAAAAAUACjD0wAAAAFAAAAAQkAAA4AAQAAABAABgARACgAAAAAAwEAAAkAAAEA IAEAAAAAAgAACAAAAQAAAAAAAwAACAAAAQAAAAAABAAACAAAAQAAAAAAYACjDw4AAAABAAAAAAAA AAAAAgAwAHAAow8+AAAABQAAAAAAAAAAAAIAHgABAAAAAAAAAAIAGgACAAAAAAAAAAIAGgADAAAA AAAAAAIAGgAEAAAAAAAAAAIAGgCAAKMPPgAAAAUAAAAAAAAAAAACABkAAQAAAAAAAAACABUAAgAA AAAAAAACABUAAwAAAAAAAAACABUABAAAAAAAAAACABUADwAMBOEIAAAPAALw2QgAABAACPAIAAAA CgAAAAokAgAPAAPwcQgAAA8ABPAoAAAAAQAJ8BAAAAAHAAAACgAAAAgAAAAIAAAAAgAK8AgAAAAA JAIABQAAAA8AA/BAAgAADwAE8EYAAAABAAnwEAAAAG0JAAAkEAAAHw0AAJUQAAACAArwCAAAAAIk AgABAgAAEwAL8AYAAACIAwAAAAAAABDwCAAAACQQbQkfDZUQDwAE8PQAAACyBArwCAAAAAMkAgAC CgAAQwAL8MQAAAB/AIAAgAAEQYoAAAAFwawAAAAGAQEAAABcAFwAQgB1AGMAawB3AGgAZQBhAHQA XABjAGwAaQBlAG4AdABzAFwAQwBpAHMAYwBvAFwAOQA5AC0AMgAwADMAIAAwADgANAA1AFwAagBv AGUAcABfAGYAaQBsAGUAcwBcAEEAcgB0AFwAagBwAGcAXABjAGkAcwBjAG8AXwB1AHIAbABfAHMA YQBiAG8AbgBiAG8AbABkADEANgBfADkANgAuAGoAcABnAAAAAAAP8BAAAACZCQAALRAAAPMMAACN EAAADwAE8O4AAACyBArwCAAAAAQkAgACCgAAQwAL8L4AAAB/AIAAgAAEQY0AAAAFwaYAAAAGAQEA AABcAFwAQgB1AGMAawB3AGgAZQBhAHQAXABjAGwAaQBlAG4AdABzAFwAQwBpAHMAYwBvAFwAOQA5 AC0AMgAwADMAIAAwADgANAA1AFwAagBvAGUAcABfAGYAaQBsAGUAcwBcAEEAcgB0AFwAagBwAGcA XABjAGkAcwBjAG8AXwB1AHIAbABfAHMAYQBiAG8AbgBiAG8AbABkADEANgAuAGoAcABnAAAAAAAP 8BAAAABtCQAAJBAAAB8NAACVEAAADwAE8NgAAACyBArwCAAAAAUkAgAACgAAUwAL8LAAAAB/AIAA gAAAAc4mAAAEQbkAAAAFwZIAAAAGAQEAAABDADoAXABEAGEAdABhAFwARABhAHQAYQAgAGYAcgBv AG0AIABEACAARAByAGkAdgBlAFwAUwBCAEMAUwB0AHUAZgBmAFwAQgBhAGMAawBVAHAAUwBlAHAA dAAyADgAXABDAGkAcwBjAG8AQgB1AGwAbABlAHQAQwByAG8AcABwAGUAZABXAGgALgB0AGkAZgAA AAAAEPAIAAAAAAAAAIMWXgMPAATw+QAAABIACvAIAAAABiQCAAAKAAAzAQvwcgAAAH8AAQABAIAA 1CN2AIEAzEABAIIAZaAAAIMAzEABAIQAZaAAAIcAAQAAAL8AEAAfAIEBBAAACIMBAAAACL8BAQAR AMABAQAACP8BAQAJAAECAgAACAUCnDEAAAYCnDEAAAcCyJz//wgCyJz//z8CAAACAAAAEPAIAAAA MADjAaUUAAMPABHwEAAAAAAAwwsIAAAAAAAAAAEAdgAPAA3wPwAAAAAAnw8EAAAAAAAAAAAAqA8L AAAAU2xpZGUgVGl0bGUAAKIPBgAAAAwAAAAAAAAAqg8KAAAADAAAAAEAAAAAAA8ABPApAQAAEgAK 8AgAAAAHJAIAAAoAAPMAC/BaAAAAfwABAAEAgAA0JHYAgQDMQAEAggBloAAAgwDMQAEAhABloAAA hwAEAAAAvwAQAB8AgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIPwIAAAIAAAAQ 8AgAAACmBR8BXBVwDg8AEfAQAAAAAADDCwgAAAABAAAAAgB2AA8ADfCHAAAAAACfDwQAAAABAAAA AACoDzsAAABCb2R5IFRleHQNU2Vjb25kIExldmVsDVRoaXJkIExldmVsDUZvdXJ0aCBMZXZlbA1G aWZ0aCBMZXZlbAAAog8eAAAACgAAAAAADQAAAAEADAAAAAIADQAAAAMADAAAAAQAAACqDwoAAAA8 AAAAAQAAAAAADwAE8OkAAAASAArwCAAAAAgkAgAACgAA8wAL8FoAAACAAJQkdgCBAMxAAQCCAGWg AACDAMxAAQCEAGWgAACFAAIAAACHAAUAAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/ AQAACAABAgIAAAg/AgAAAgAAABDwCAAAAEAQLxXvFcoQDwAN8F8AAAAAAJ8PBAAAAAQAAAAAAKgP AQAAACoAAKEPGAAAAAIAAAAAAAAAAAACAAAAAAAGAAkAgICA/gAA2A8EAAAAAAAAAAAApg8WAAAA 8R4AAAECAAEAAQECAQICAwIDAwQDBA8ABPDsAAAAEgAK8AgAAAAJJAIAAAoAAPMAC/BaAAAAgABU JXYAgQDMQAEAggBloAAAgwDMQAEAhABloAAAhQACAAAAhwAFAAAAvwASAB8AgQEEAAAIgwEAAAAI vwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAADqDyIAjgLKEA8ADfBiAAAAAACf DwQAAAAEAAAAAACoDxAAAAANUHJlc2VudGF0aW9uX0lEAAChDxgAAAARAAAAAAAAAAAAEQAAAAAA BgAJAICAgP4AAKYPFgAAAPEeAAABAgABAAEBAgECAgMCAwMEAwQPAATw+gAAABIACvAIAAAACiQC AAAKAADzAAvwWgAAAIAAFCZ2AIEAzEABAIIAZaAAAIMAzEABAIQAZaAAAIUAAgAAAIcABQAAAL8A EgAfAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAEPAIAAAAUxCj Av8FyhAPAA3wcAAAAAAAnw8EAAAABAAAAAAAqA8cAAAAqSAxOTk5LCBDaXNjbyBTeXN0ZW1zLCBJ bmMuIAAAoQ8aAAAAHQAAAAAAAAAAAB0AAAABAAYAAQAHAICAgP4AAKYPFgAAAPEeAAABAgABAAEB AgECAgMCAwMEAwQPAATwSAAAABIACvAIAAAAASQCAAAMAACDAAvwMAAAAIEBAAAACJMBjp+LAJQB 3r1oAL8BHgAfAP8BAAAIAD8CAAACAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAAAAAAAA//// AABsiADQDi4AIIa+AALI/gAgALoPGAAAAHQAZQBtAHAAbABhAHQAZQAuAHAAbwB0AA8A7gPTBgAA AgDvAxgAAAACAAAAAwQHCQgAAAAMAACAAAAAAAAAAAAPAAwEgwYAAA8AAvB7BgAAIAAI8AgAAAAH AAAABygCAA8AA/ATBgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAABgAAAAAAAAACAArwCAAAAAAo AgAFAAAADwAE8L4AAACyBArwCAAAAAIoAgAACgAAQwAL8JYAAAB/AIAAgAAEQb4AAAAFwX4AAAAG AQEAAABDADoAXABEAGEAdABhAFwARABhAHQAYQAgAGYAcgBvAG0AIABEACAARAByAGkAdgBlAFwA UwBCAEMAUwB0AHUAZgBmAFwAQgBhAGMAawBVAHAAUwBlAHAAdAAyADgAXABnAHUAeQBtAGEAaQBu AEkATgBEAC4AdABpAGYAAAAAABDwCAAAAAAAAACEFuMQDwAE8A4BAAASAArwCAAAAAMoAgAACgAA MwEL8HIAAAB/AAEAAQCAAOQysgCBAMxAAQCCAGWgAACDAMxAAQCEAGWgAACHAAEAAAC/ABAAHwCB AQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgFApwxAAAGApwxAAAHAsic//8IAsic //8/AgAAAgAAABDwCAAAAIoG4wEUFUgJDwAR8BAAAAAAAMMLCAAAAAAAAAADAHYADwAN8FQAAAAA AJ8PBAAAAAYAAAAAAKgPIAAAAENsaWNrIHRvIEVkaXQgTWFzdGVyIFRpdGxlIFN0eWxlAACiDwYA AAAhAAAAAAAAAKoPCgAAACEAAAABAAAAAAAPAATwCwEAABIACvAIAAAABCgCAAAKAAAjAQvwbAAA AH8AAQABAIAApDOyAIEAzEABAIIAZaAAAIMAzEABAIQAZaAAAL8AEAAfAIEBBAAACIMBAAAACL8B AQARAMABAQAACP8BAQAJAAECAQAACAUCAAAAAAYCAAAAAAcCkDn//wgCkDn//z8CAAACAAAAEPAI AAAAdgr6AIAV4w4PABHwEAAAAAAAwwsIAAAAAQAAAAQAdgAPAA3wVwAAAAAAnw8EAAAABQAAAAAA qA8jAAAAQ2xpY2sgdG8gRWRpdCBNYXN0ZXIgU3VidGl0bGUgU3R5bGUAAKIPBgAAACQAAAAAAAAA qg8KAAAAJAAAAAEAAAAAAA8ABPDpAAAAEgAK8AgAAAAFKAIAAAoAAPMAC/BaAAAAgAAENLIAgQDM QAEAggBloAAAgwDMQAEAhABloAAAhQACAAAAhwAFAAAAvwASAB8AgQEEAAAIgwEAAAAIvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAABAEC8V7xXKEA8ADfBfAAAAAACfDwQAAAAE AAAAAACoDwEAAAAqAAChDxgAAAACAAAAAAAAAAAAAgAAAAAABgAJAICAgP4AANgPBAAAAAAAAAAA AKYPFgAAAPEeAAABAgABAAEBAgECAgMCAwMEAwQPAATw+gAAABIACvAIAAAABigCAAAKAADzAAvw WgAAAIAAxDSyAIEAzEABAIIAZaAAAIMAzEABAIQAZaAAAIUAAgAAAIcABQAAAL8AEgAfAIEBBAAA CIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAEPAIAAAAUxCjAv8FyhAPAA3w cAAAAAAAnw8EAAAABAAAAAAAqA8cAAAAqSAxOTk5LCBDaXNjbyBTeXN0ZW1zLCBJbmMuIAAAoQ8a AAAAHQAAAAAAAAAAAB0AAAABAAYAAQAHAICAgP4AAKYPFgAAAPEeAAABAgABAAEBAgECAgMCAwME AwQPAATw+QAAABIACvAIAAAABygCAAAKAADzAAvwWgAAAIAAhDWyAIEAzEABAIIAZaAAAIMAzEAB AIQAZaAAAIUAAgAAAIcABQAAAL8AEgAfAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAEC AgAACD8CAAACAAAAEPAIAAAA6g8iAI4CyhAPAA3wbwAAAAAAnw8EAAAABAAAAAAAqA8dAAAAQ291 cnNlIE51bWJlcg1QcmVzZW50YXRpb25fSUQAAKEPGAAAAB4AAAAAAAAAAAAeAAAAAAAGAAkAgICA /gAApg8WAAAA8R4AAAECAAEAAQECAQICAwIDAwQDBA8ABPBIAAAAEgAK8AgAAAABKAIAAAwAAIMA C/AwAAAAgQEAAAAIkwGOn4sAlAHevWgAvwEeAB8A/wEAAAgAPwIAAAIABAMJAAAAPwMBAAEAEADw ByAAAAD///8AAAAAAAAAAAD///8AAGyIANAOLgAghr4AAsj+AA8A8AOIBQAAAQDxAwgAAAAMAACA AAALMA8ADARIBQAADwAC8EAFAAAwAAjwCAAAAAcAAAAHCAAADwAD8NgEAAAPAATwKAAAAAEACfAQ AAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAAAgAAAUAAAAPAATwcAAAABIACvAIAAAAAggAAAAK AACDAAvwMAAAAH8ABAAEAIcAAQAAAH8BAAABAL8BAQARAMABAQAACMsBnDEAAP8BCAAJAD8CAQAD AAAAEPAIAAAAnQAQAmUPnQoPABHwEAAAAAAAwwsIAAAAAgAAAAUAdgAPAATwIwEAABIACvAIAAAA AwgAAAAKAADjAAvwVAAAAH8AAQABAIAA5DWyAIEALnoBAIIAY8YAAIMALnoBAIQAY8YAAL8AEAAf AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACD8CAAACAAAAEPAIAAAA+AoAAR4Q oBUPABHwEAAAAAAAwwsIAAAAAwAAAAYCdgAPAA3whwAAAAAAnw8EAAAAAgAAAAAAqA87AAAAQm9k eSBUZXh0DVNlY29uZCBMZXZlbA1UaGlyZCBMZXZlbA1Gb3VydGggTGV2ZWwNRmlmdGggTGV2ZWwA AKIPHgAAAAoAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8KAAAAPAAAAAEAAAAAAA8A BPBeAAAAEgAK8AgAAAAECAAAAAoAAJMAC/A2AAAAhQACAAAAhwABAAAAgQEEAAAIgwEAAAAIvwEA ABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAACRFXAPjBAaFg8ABPAiAQAAEgAK8AgA AAAFCAAAAAoAANMAC/BOAAAAgABENrIAgQAuegEAggBjxgAAgwAuegEAhABjxgAAvwASAB8AgQEE AAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAAADFiQA9xDdFg8A DfCkAAAAAACfDwQAAAAEAAAAAACoDzAAAACpIDE5OTksIENpc2NvIFN5c3RlbXMsIEluYy4gDVBy ZXNlbnRhdGlvbl9JRC5zY3IAAKEPFgAAADEAAAAAAAAAAAAxAAAAAQACAAEACAAAAKoPEgAAAC0A AAAAAAAABAAAAAEAAAADAAAApg8gAAAA9R4AAIYBAgDyBQAACAwAAKcBMAFvA28DuwO7A8EEwQQP AATwcAAAAEIBCvAIAAAABggAAAAKAADDAAvwSAAAAIUAAgAAAIcAAQAAAL8BAAAQAMABAQAACMsB nDEAANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8BCAAIAAECAgAACD8CAAACAAAAEPAIAAAADBZh AM4QDBYPAATw9QAAABIACvAIAAAABwgAAAAKAADzAAvwWgAAAH8AAQABAIAApDayAIEAZUoAAIIA AAAAAIMAZUoAAIQAAAAAAIcAAgAAAL8AEAAfAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJ AAECAgAACD8CAAACAAAAEPAIAAAAvxWkDqcQeBYPABHwEAAAAAAAwwsIAAAABQAAAAgCdgAPAA3w UwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8WAAAAAgAAAAAAAAgAAAIAAgAAAAAAAgAIAAAA 2A8EAAAAAAAAAAAApg8MAAAAUAoAAB8BHwFfA18DDwAE8EgAAAASAArwCAAAAAEIAAAADAAAgwAL 8DAAAACBAQAAAAiTAfatagCUAaaPjQC/ARIAEgD/AQAACAA/AgAAAgAEAwkAAAA/AwEAAQAQAPAH IAAAAP///wAAAAAAAAAAAAAAAAAq/48A/yo1AP///wD/5ZsADwDJD2QHAAAPAAwENAcAAA8AAvAs BwAAQAAI8AgAAAAJAAAACQwAAA8AA/DEBgAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAA AAACAArwCAAAAAAMAAAFAAAADwAE8GQAAAASAArwCAAAAAIMAAAACgAAowAL8DwAAACFAAIAAACH AAEAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAjLAZwxAAD/AQgACAABAgIAAAg/AgAAAgAAABDw CAAAADwCBAM0DqsKDwAE8GQAAAASAArwCAAAAAMMAAAACgAAowAL8DwAAACFAAIAAACHAAEAAACB AQQAAAiDAQAAAAi/AQAAEADAAQEAAAjLAZwxAAD/AQgACAABAgIAAAg/AgAAAgAAABDwCAAAACwM BAM0DpoUDwAE8FABAAASAArwCAAAAAQMAAAACgAA0wAL8E4AAACAAAQ3sgCBAC56AQCCAGPGAACD AC56AQCEAGPGAAC/ABIAHwCBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAA AgAAABDwCAAAAAMWJAD3EN0WDwAN8NIAAAAAAJ8PBAAAAAQAAAAAAKgPXgAAAENvcHlyaWdodCCp IDE5OTgsIENpc2NvIFN5c3RlbXMsIEluYy4gQWxsIHJpZ2h0cyByZXNlcnZlZC4gUHJpbnRlZCBp biBVU0EuC1ByZXNlbnRhdGlvbl9JRC5zY3IAAKEPFgAAAF8AAAAAAAAAAABfAAAAAQACAAEACAAA AKoPEgAAAFsAAAAAAAAABAAAAAEAAAADAAAApg8gAAAA9R4AAIYBAgDyBQAACAwAAKcBMAFvA28D uwO7A8EEwQQPAATwcAAAAEIBCvAIAAAABQwAAAAKAADDAAvwSAAAAIUAAgAAAIcAAQAAAL8BAAAQ AMABAQAACMsBnDEAANIBAAAAANMBAAAAANQBAAAAANUBAAAAAP8BCAAIAAECAgAACD8CAAACAAAA EPAIAAAADBZhAM4QDBYPAATw8QAAABIACvAIAAAABgwAAAAKAADjAAvwVAAAAH8AAQABAIAAZDey AIEAZUoAAIIAAAAAAIMAZUoAAIQAAAAAAL8AEAAfAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8B AQAJAAECAgAACD8CAAACAAAAEPAIAAAA+/+4CTgRGwEPABHwEAAAAAAAwwsIAAAAAQAAAAcCdgAP AA3wVQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8YAAAAAgAAAAAAAAgAAAIAAgAAAAIAAgAC AAoAAAD4DwQAAAAAAAAAAACmDwwAAABQCgAAHwEfAV8DXwMPAATw9wAAABIACvAIAAAABwwAAAAK AADzAAvwWgAAAH8AAQABAIAAxDeyAIEAZUoAAIIAAAAAAIMAZUoAAIQAAAAAAIcAAgAAAL8AEAAf AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACD8CAAACAAAAEPAIAAAAtBW4CTgR 1BYPABHwEAAAAAAAwwsIAAAAAwAAAAgCdgAPAA3wVQAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAA oQ8YAAAAAgAAAAAAAAgAAAIAAgAAAAIAAgACAAoAAADYDwQAAAAAAAAAAACmDwwAAABQCgAAHwEf AV8DXwMPAATw9QAAABIACvAIAAAACAwAAAAKAADzAAvwWgAAAH8AAQABAIAAJDiyAIEAZUoAAIIA AAAAAIMAZUoAAIQAAAAAAIcAAgAAAL8AEAAfAIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJ AAECAgAACD8CAAACAAAAEPAIAAAAtBX4/3gH1BYPABHwEAAAAAAAwwsIAAAAAgAAAAkCdgAPAA3w UwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8WAAAAAgAAAAAAAAAAAAIAAAACAAIAAgAKAAAA +g8EAAAAAAAAAAAApg8MAAAAUAoAAB8BHwFfA18DDwAE8O8AAAASAArwCAAAAAkMAAAACgAA4wAL 8FQAAAB/AAEAAQCAAIQ4sgCBAGVKAACCAAAAAACDAGVKAACEAAAAAAC/ABAAHwCBAQQAAAiDAQAA AAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAg/AgAAAgAAABDwCAAAAPv/+P94BxsBDwAR8BAAAAAA AMMLCAAAAAAAAAAKAnYADwAN8FMAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPFgAAAAIAAAAA AAAAAAACAAAAAgACAAIACgAAAPkPBAAAAAAAAAAAAKYPDAAAAFAKAAAfAR8BXwNfAw8ABPBIAAAA EgAK8AgAAAABDAAAAAwAAIMAC/AwAAAAgQEAAAAIkwH2rWoAlAGmj40AvwESABIA/wEAAAgAPwIA AAIABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAJGRkQAAAAAAYY/9AACuAAD8ASgAzs7OAA8A 7gMgAgAAAgDvAxgAAAAAAAAADxAAAAAAAAANAACAAgEAAAcAAAAAAPkDEAAAAAAAAAAAAAAAAAsB AAIAAAAPANkPDAAAAAAA2g8EAAAAAAAlAA8ADASkAQAADwAC8JwBAABQAAjwCAAAAAMAAAAfIAAA IAAY8QgAAAABAAAAAgABAA8AA/AkAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAABgAAAAAAAAAC AArwCAAAAAAgAAAFAAAADwAE8HIAAAASAArwCAAAAAkgAAAgAgAAUwAL8B4AAAAEAAAAAACAAOQ4 sgC/AQAAAQD/AQAAAQABAwMoAgAAABDwCAAAAIoG4wEUFUgJDwAR8BAAAAAAAMMLCAAAAAAAAAAP AHYADwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwcgAAABIACvAIAAAACiAAACACAABTAAvwHgAAAAQA AAAAAIAARDmyAL8BAAABAP8BAAABAAEDBCgCAAAAEPAIAAAAdgr6AIAV4w4PABHwEAAAAAAAwwsI AAAAAQAAABAAdgAPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABIAAAAAwAAIMA C/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADw ByAAAAD///8AAAAAAAAAAAAAAAAAAGyIAM8OMAD///8A/+WbAA8A7gPYAQAAAgDvAxgAAAABAAAA DQ4AAAAAAAAMAACAAAAAAAcAAAAPAAwEiAEAAA8AAvCAAQAA0AEI8AgAAAADAAAAAywCAA8AA/AY AQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAQAAAACAArwCAAAAAAsAgAFAAAADwAE8GwA AAASAArwCAAAAAIsAgAgAgAAQwAL8BgAAACAAMQpQQG/AQAAAQD/AQAAAQABAwYkAgAAABDwCAAA ADAA4wGlFAADDwAR8BAAAAAAAMMLCAAAAAAAAAANAEEBDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATw bAAAABIACvAIAAAAAywCACACAABDAAvwGAAAAIAAZClBAb8BAAABAP8BAAABAAEDByQCAAAAEPAI AAAApgUfAVwVcA4PABHwEAAAAAAAwwsIAAAAAQAAAA4AQQEPAA3wDAAAAAAAng8EAAAAAQAAAA8A BPBIAAAAEgAK8AgAAAABLAIAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwES ABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAAAAAAD///8AAGyIANAOLgAghr4A Asj+AA8A7gPYAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAMAACAAAAAAAcAAAAPAAwEiAEAAA8AAvCA AQAA4AEI8AgAAAADAAAAAzACAA8AA/AYAQAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAA AAACAArwCAAAAAAwAgAFAAAADwAE8GwAAAASAArwCAAAAAIwAgAgAgAAQwAL8BgAAACAAAQsQQG/ AQAAAQD/AQAAAQABAwYkAgAAABDwCAAAADAA4wGlFAADDwAR8BAAAAAAAMMLCAAAAAAAAAANAEEB DwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwbAAAABIACvAIAAAAAzACACACAABDAAvwGAAAAIAA5CpB Ab8BAAABAP8BAAABAAEDByQCAAAAEPAIAAAAFgUwAFAQ4A0PABHwEAAAAAAAwwsIAAAAAQAAAA4A QQEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK8AgAAAABMAIAAAwAAIMAC/AwAAAAgQEA AAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgABAMJAAAAPwMBAAEAEADwByAAAAD///8A AAAAAAAAAAD///8AAGyIANAOLgAghr4AAsj+AA8A7gPYAQAAAgDvAxgAAAABAAAADQ4AAAAAAAAM AACAAAAAAAcAAAAPAAwEiAEAAA8AAvCAAQAA8AEI8AgAAAADAAAAAzQCAA8AA/AYAQAADwAE8CgA AAABAAnwEAAAAAAAAAAAAAAA/////wACAAACAArwCAAAAAA0AgAFAAAADwAE8GwAAAASAArwCAAA AAI0AgAgAgAAQwAL8BgAAACAAIQtQQG/AQAAAQD/AQAAAQABAwYkAgAAABDwCAAAADAA4wGlFAAD DwAR8BAAAAAAAMMLCAAAAAAAAAANAL8BDwAN8AwAAAAAAJ4PBAAAAAAAAAAPAATwbAAAABIACvAI AAAAAzQCACACAABDAAvwGAAAAIAAZCxBAb8BAAABAP8BAAABAAEDByQCAAAAEPAIAAAApgUfAVwV cA4PABHwEAAAAAAAwwsIAAAAAQAAAA4AvwEPAA3wDAAAAAAAng8EAAAAAQAAAA8ABPBIAAAAEgAK 8AgAAAABNAIAAAwAAIMAC/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwESABIA/wEAAAgA BAMJAAAAPwMBAAEAEADwByAAAAD///8AAAAAAAAAAAD///8AAGyIANAOLgAghr4AAsj+AA8A8ANq AgAAAQDxAwgAAAACAQAABwALMA8ADAQqAgAADwAC8CICAABgAAjwCAAAAAMAAAADJAAADwAD8LoB AAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAACQAAAUAAAAPAATw8gAA ABIACvAIAAAAAiQAACACAAAjAQvwbAAAAAQAAAAAAIAApDmyAIEALnoBAIIAY8YAAIMALnoBAIQA Y8YAAIUAAAAAAIYAAAAAAIcAAAAAAIgAAAAAAIkAAAAAAIoAAAAAAIsAAAAAAL8AEAAfAL8BAQAR AP8BAQAJAD8CAAACAAEDAwgAAAAAEPAIAAAA+AoAAR4QoBUPABHwEAAAAAAAwwsIAAAAAQAAAAwA dgAPAA3wPgAAAAAAnw8EAAAAAgAAAAAAqg8KAAAAAQAAAAEAAAAAAAAApg8YAAAA+R4AAEACSABo ASABiAJAAqgDYAPIBIAEDwAE8IgAAAASAArwCAAAAAMkAAAgAgAAwwAL8EgAAAAEAAAAAAC/AQEA EQDAAQEAAAjBAQAAAQDEAQAAAADLAZwxAADNAQAAAADOAQAAAADXAQIAAAD/AQkACQA/AgAAAgAB AwIIAAAAABDwCAAAAJ0AEAJlD50KDwAR8BAAAAAAAMMLCAAAAAAAAAALAHYADwAE8EgAAAASAArw CAAAAAEkAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAfatagCUAaaPjQC/ARIAEgD/AQAACAAE AwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAAAAAAAAAAAAq/48A/yo1AP///wD/5ZsAAAByFzgA AAABADAAAAAAAIQ4CgAUPgoACwAQAIBFCgAnABAASE0KAIQAUACKJAoAqTEKAKhHCgCISQoAaEsK AAAA9Q8cAAAALgEAALwNAAMAAAAAuk8KAAEAAACIAAAAAQBiAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAQAAAOCFn/L5T2gQq5EIACsns9kwAAAAnFIA ABEAAAABAAAAkAAAAAIAAACYAAAAAwAAAMQAAAAEAAAA+AAAAAUAAAAIAQAABgAAABQBAAAHAAAA IAEAAAgAAABkAQAACQAAAHQBAAASAAAAgAEAAAoAAACkAQAACwAAALABAAAMAAAAvAEAAA0AAADI AQAADgAAANQBAAAPAAAA3AEAABEAAADkAQAAAgAAAOQEAAAeAAAAJAAAAFBlZXItdG8tUGVlciAz cmQgcGFydHkgY2FsbCBjb250cm9sAB4AAAAsAAAAR3VpZGUgZm9yIENyZWF0aW5nIFBvd2VycG9p bnQgUHJlc2VudGF0aW9ucwAeAAAABgAAAHJtYWh5AGZvHgAAAAEAAAAAbWFoHgAAAAEAAAAAbWFo HgAAADkAAABDOlxQcm9ncmFtIEZpbGVzXE1pY3Jvc29mdCBPZmZpY2VcVGVtcGxhdGVzXHRlbXBs YXRlLnBvdABQb2keAAAABgAAAHJtYWh5AGdyHgAAAAIAAAAxAGFoHgAAABkAAABNaWNyb3NvZnQg UG93ZXJQb2ludCA0LjAAdCBPQAAAAGDiRM8DAAAAQAAAAMAxbunWnL4BQAAAAMBj5y0PZMABQAAA AKD/Vv0SZMABAwAAABwAAAADAAAApgAAAEcAAACwUAAA/////wMAAAAIAG8QTQwAAAEACQAAA1Ao AAACAKEnAAAAABEAAAAmBg8AGAD/////AAAQAAAAAAAAAAAAugMAAMoCAAAJAAAAJgYPAAgA//// /wIAAAAXAAAAJgYPACMA/////wQAGwBUTlBQFACw6wAwAAAAABQAAABEDXYAAAAAAAAACgAAACYG DwAKAFROUFAAAAIA9AMJAAAAJgYPAAgA/////wMAAAAPAAAAJgYPABQAVE5QUAQADAABAAAAAQAA AAAAAAAFAAAACwIAAAAABQAAAAwCygK6AwUAAAAJAgAAAAIFAAAAAQL///8CBAAAAAQBDQAEAAAA BwEDAKEnAABBCyAAzAB4AKAAAAAAAMoCugMAAAAAKAAAAKAAAAB4AAAAAQAIAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAwNzAAPDKpgAEBAQA CAgIAAwMDAAREREAFhYWABwcHAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQCAfP8AUFD/AJMA1gD/ 7MwAxtbvANbn5wCQqa0AAAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAzmQAAM8wAADP/AABm AAAAZjMAAGZmAABmmQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/AADMAAAAzDMAAMxm AADMmQAAzMwAAMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwAMwD/ADMzAAAzMzMA MzNmADMzmQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZAAAzmTMAM5lmADOZmQAz mcwAM5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YAM/+ZADP/zAAz//8AZgAAAGYA MwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYzzABmM/8AZmYAAGZmMwBmZmYAZmaZ AGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBmzAAAZswzAGbMmQBmzMwAZsz/AGb/AABm/zMA Zv+ZAGb/zADMAP8A/wDMAJmZAACZM5kAmQCZAJkAzACZAAAAmTMzAJkAZgCZM8wAmQD/AJlmAACZ ZjMAmTNmAJlmmQCZZswAmTP/AJmZMwCZmWYAmZmZAJmZzACZmf8AmcwAAJnMMwBmzGYAmcyZAJnM zACZzP8Amf8AAJn/MwCZzGYAmf+ZAJn/zACZ//8AzAAAAJkAMwDMAGYAzACZAMwAzACZMwAAzDMz AMwzZgDMM5kAzDPMAMwz/wDMZgAAzGYzAJlmZgDMZpkAzGbMAJlm/wDMmQAAzJkzAMyZZgDMmZkA zJnMAMyZ/wDMzAAAzMwzAMzMZgDMzJkAzMzMAMzM/wDM/wAAzP8zAJn/ZgDM/5kAzP/MAMz//wDM ADMA/wBmAP8AmQDMMwAA/zMzAP8zZgD/M5kA/zPMAP8z/wD/ZgAA/2YzAMxmZgD/ZpkA/2bMAMxm /wD/mQAA/5kzAP+ZZgD/mZkA/5nMAP+Z/wD/zAAA/8wzAP/MZgD/zJkA/8zMAP/M/wD//zMAzP9m AP//mQD//8wAZmb/AGb/ZgBm//8A/2ZmAP9m/wD//2YAIQClAF9fXwB3d3cAhoaGAJaWlgDLy8sA srKyANfX1wDd3d0A4+PjAOrq6gDx8fEA+Pj4APD7/wCkoKAAgICAAAAA/wAA/wAAAP//AP8AAAD/ AP8A//8AAP///wAiADwAIT0ADQAdDQ0NHQ0NIQAdACIADQ0NQh0hHQANDQ0NHQANDR0hAB0NDR0h HQ0NIh08HSEdIh0hPSIdHRAdDR0iPCIdQh0QECI9IhA8IjwNQg0ADQANAA0AITwhPB0ADQ0NDQ0A DQ0NDQ0NDTwADQ0dPB0AQgAdIR0AIR0ADQ0NDQ0NDR0hADwdDQ0APB0ADQ0AIjwhAA0NDQANDQ0A AB0AIR0AIQ0dIQAdAA0NAB0NDQAADQ0dAB0NAA0NHQ0ADQANAAANHTwhHQ0NDQ0dDR0hHQ0dPB0h HR0hHSEdIT0iPCI9IT0iPCI8IjwiHUIAHQAAQgA8AA0ADQAADQAhPAANAA0ADQ0ADQANAB0hDQ0A IQANAB0NAA0ADQANDQANAA0ADQ0AHQAhAAAdDQAhDQ0NDQAdAA0NAD0hAA0ADQAhHQD4+Pj4+Pj4 +Pj4+PgNAAAN+B34+PgADfgdIQ0A+CH4HfhCHSEAHTwdIR0NIgANDR0hHSEdHSEdDQ0dDR0hHRAd IT0hPSI8IhAdQg0dITwADQAAIQANQgAADQA8AAAAIQANAA0AIQAdACEAHQAADQAdAA0AAA0ADQ0d AAANAB0hAA0AAA0NAA0NIQANAAAdAAANAA0NACEAAB0ADQAAAAANAA0ADQ0NAB0ADQANACIAAAA8 IgAAIgANAB0ADQ0AHSEAHQANHSEdDR0NDR0NHQ0NHR0dIR0dIR0iDSI9IR0hPRAdQiJCHUIdQh1C DQAdITwADQAAAAAADQAhAA0ADQAAAA0APAANAA0AAA0ADQ0AACENDQ0ADQAhAA0NDQ0AAB0NDQAN AA0AHQANAA0NAA0hDQANAA0AHQ0ADQAdDR34+A34+PgA+PgA+Pj4HQAADQAhHQANDQANHQ0NACIA DQANDQ0dDQ0dIQ0NHQ0NHSEdHSEdIR0iAB0iAD0AIgA9EB0hEB0QHRAdQh0NDR0hPAANAAANAA0A DQA8AAANPAANADwhAAANAA0ADQ0ADQ0ADQ0AAB0ADQAdAA0NAA0ADQ0AIQANAB0ADQANAA0NAA0A HQA8AB0ADQAAIQANAAAAACEAHSEdACENDQAdAA0ADQ0NHQANAB0NDQAAHQ0AAB0NAB0AIR0NAB0N HSEdDR0NHSEdHQ0dIT0iPCIdIT0hHSE9IjwiPCI8Ij0hPSE8DQ0AITwAADwAACEADQAAIQAAAA0A AA0AAA0ADQANDQ0AHQANHQ0AIQ0NAA0AHSEAHQANDQA8HSEADQANAA0NAB0hPA0AHSENAA0NDQAd DQAADQAdAAAAAA0AHQANAA0ADR0AAAAhHQ0NIR0NDQ0ADQ0NAA0NHQ0NDR08IgANHSEdIR0NHQ0i PB0dIR0hPQ0iPSE9IjwiEA0iPSENDQ0NAAAAAAAAAAAAAA08AAANAAAADQAADQAAAA0ADQ0dIR0A IQA9ACEADR0ADQ0NAA0ADQANDQAdIQANDQ0NDQ0dAA0NAB0AIQAdADwhHQANAA0AAAANAAANDQAd DQANAB0hDQAAIgANDQAAHQANAB0AIR0NHSEdDSEdDQAiAB0NHQ0dDR0NHSEdHSEiPB0QHSEdQh0Q DRA9IT0itZKTkuyT7O8H7Oy1c5LvkkMAAA0AAA0AAAANAAANDQANAA0APAANAB0AIR08DQ0ADQ0d AA0NHQ0NDQ0NAA0dAA0AHQAhDQ0ADQ0NAB0NDQAdAA0NDQ0NDQAiAAANHQANIQANHSEAHQANAAAN HQAdDQ0NDQAhHQANAA0ADR08HQ0NHSEdDQ0NHSEdDSIdACI8HR0hHQ0NEB0hPSINIj0hDbz/9O/v vOL/9P8HvO8H//9JAA0AAEIADQANADwhAAA8AA0AIQANDQ0NDQANAB0hPB0ADQ0NDQANDQAdAD0h AA0NDQ0NAD0ADQ0dAA0NDQANDQ0NDQAdDQ0AAAANACEAHQANAAANAA0AHQ0NACENDQAdAA0NHQ0A HSEdDQAiACEdDR0NACIdDR0dDR0hHUIdIg0NIjwiPSE9IT0hPSE9Ij3C//+87//2/////7yS//// QwAADQAAAAA8AA0AADwAIQANDQAdAA0ADQ09AA0NAB0hDQ0AHQ0NDQ0NDQANHTwdDQANDQ0AIgAN DQ0NAD0hHQ0NDQ0NDQ0NAAANAAAdAA0ADQ0NACIADQAhAA0AHQANDSEdAAANDQ0ADQ0NDR0NHQ0N DR0dIR0hHSEdHQ0dHSE9EB0hPSEdEB0hPSI9IT0hvP///7z/////////vP///xQAQgAADQANACEA DQANAAAADQA8AA0NDQ0AIQANDQ0APB0NDQANDQ0AHQBCHQANAA09IR0NDTwdDQ0APSEdPA0NHQ0N HQ0NHQANACIAACEAHQANAB0AAB0NAB0NDQANAB0ADQ0dACEdDR0NHQ0NDR0NHSEdPB0dHQ0dQh0h HUIdIR08Ih1CHUIdPSEQECI8It32///0//////////////9DAAAADQAADQA8AAAhAA0NAA0AIQAN AA0NDQAdDQ0NDQANAD0NDQ0NDQ0AHQ0NDQ0NAB08DR0NIT0hHQ0NDSEdQg08IjwNHUIAAAAADQA8 HQANHQ0ADQ0NAAANAA0dIQANHSEADQAdPCIADSEdDR0hHQ0dHSEdIR0hHSEdPSEdDR1CHSI8HSId QiIQPSE9EB3x////////////////////ZwAADQAAPAAhAAANAA0AAA0APAANAEIADQA8IQAADQAN DQ0AIR0ADQ0AIjwADQ0dDQ0NAB0hPB0APCI8HQ0dPB0NHQ0iHUIdAAANAA0AHSEAIQANDQAADQ0A HSEAAB0NAAAdDQAiAAAdPB0NACIAHQ0dIR0dDR0NHQ0dQh0iPCI9IR1CHUIdQh09IR0QIjwiZkNK Q2ZsABQQQ0MQQ0NmQyEADQA8IQAADQANADwAPCEAAA0AAA0AAA0ADQA8DQ0hAA0NDQANAA0dDQAd IQANDQAdQh0NDR0hPQ0dITwiPCIAPSE9PBA9IQANAB0AIQAdPB0AHQAdIR0ADQAADQ0NAAANAA0A DR0hDR0AIjwdDR0hHQ0dIR0NIjwiHSEdQh0hHUIdHUIdIT0iQh1DIT0hPXNtbettkw0SbW2SbXJE vOtDAAANAAAADQA8AA0AIQAAPCEADQ0ADQ0NDQANAA0APAANAA0ADQ0NAA0NAA0NHTwhHQANDQ08 HQANDTwdDR08DSI8HSEdIT0AAAAAAB0AIQAADQ0hDQAAIR0NAB0AACINHSEdDQ0AHQ0AIgAdIR0d DR0hHR0hHR0hHTwiDR0QPSEdQh0NIj0hHRAQPCIQPSGSZ0NDSRIA6xJDbGdDQ2xDHQBCAAANAA0A ACENAA0ADQAADQAhPAAAACE8ACEADQANAA0NDQAdDQ0ADQ0NACEdADwNDQ0dITwiAB0hDQ0NIgA9 IT0NPQ0QAAANAA0ADQAdIR0AAB0ADR0ADQAADQ0AAAAADQ0AHQ0NDR0NHQ0dIR0NHSI8HQAiPB0i PB1CHSEdPCI9IT0hPSI8IhAdECE9IQ0NDTwADTwADQAADQAAAEIAAAANAEIAAA0AADwADQANDQA8 AAANITwADQANDQAADQ0hAA0ADQANDQ0AHQ0NDQ0dIR0ADQAdAA0NDR08HTwNDR0NDSEdAAAAHQ0A IgANDQANDQ0ADQAAIQ0NHQANDQ0NDR0hHTwdIR0hHR0hHQ0NHSEdHSE9IR0hPSINHUIdQh0hHRAi PCI8IjwiQh0QDQ0NDQANAAAhADwNACE8DQAAAA0AAAAADQAhPAAhADwhADwhAA0AADwAIQA8AABC AA0APB0NDQ0NAB0hHTwAHQANDQANDQ0NDQ0NHQ0NIR0hHTwhPR08DSINAAAhAAAdAA0ADR0ADQ0A DQAdAAAhHQ0AHQANHQAhHQAdDR0hHR0iHQ0dIR0NIh1CHSEdQh1CHQ0iPBAdQh0QECI9EB0HBwcH Bw0hAA0AAA0hAAAAAAAADQBCAA0ADQA8AAANAA0AAA0AAA0ADQ0ADQANAA0NAA0NAAANAA0AHSEA PQAhHTwiAA0NHQ0NHQ0NHQBCHQAdPA0AHSEAIR0AAAANAA0NACEdAA0AIQAdAA0AAA0NAAAhHQAN DQAdDQ0dDR0NHQAiAB0iDR1CHQ0NHRAdQh0QHSE9Ih0hPSEQHUIdQiL//////wAHBwA8DQA8AA0A DQ0ADQAAAAAAPCEADQAAPA0ADQANAA0APAANACE8ACE8AA0AQh0NDQ0NDQ0NHSEdPB0hHTwdDQ0N DQ0NDQ09ACE9IR0hPQ0dDT0hPQAADQANAB08AA0NAB0AIQAADR0hHQANHQAhHQ0NHQ0dQh0AIh0h PR0hPQchHQAHBwcdQgchHSEHIQcHBxAHEBAdBx3/HSEHBwf//wAHByEABw0ABwcHAA0ABwcNAA0H BwcNAAcABwchPAAHBwchPAcNAAcADQcADQA8IQANDR0NHTwNDR0hPB0NIT0hHQ0NHQ0dIR0NHTwd PCIAPSEdDR0AAB0NAB0hAB0ADQANAB0ADQAAAAANDQANHQ0AHSEdAB0dIR0NHR0hHf8HPCL///8d B/8HIjz/B////wf/Bx0Q/wf/ByL/////Qgf//wAH/wcA////IQcA//8hBw3///9CB/8A//88BwD/ //8AB/8HAP8HAP8HDQ0NADw9ITwNDQ0iAD0hPR0hPR0hPQ0NHUIdQh08Ig0iDR0hPSE9IT0hAAAN ACEAHQANHSEdAAAAIgANAA0NAB0hHTwAIgANHSEdIR0NHSEdIR3/ByH/ById/wf/Bzwi//89B/8H /wc9If8H/wf/Bw3/B///BwD/PP8HPAAAB/88/wcA/wD/BwAA/wcA/wch/w3/BwAA/wf/Bzz/ByH/ BzwNPB0hAA0NHUIdPCI8HUIdQh1CHQ0NIhAdPCIdIT0QHTwiPR1CHQ0QHQAAAB0ADQAhAA0AAA0A DQAAHSEAHQANAB0hHQ0dDQ0dDR0NHQ0dDR0h/wcN/wc9AP8H/wcdQv8H////B/8HHRD/B/8H/wcd /wdC/wcAAAf/ByEA//8NAP8HAAAH/wcNDf8HAP8HAA0H/wcdIf8H/wcA/wc8/wcNACE8DQ0dQgA9 IR08Ig0dIR0QHTwiPQ0dQh08Ij0hHRAiPCI8Ij0iPSEADQANAA0dAB0ADR0hHQAADQAADSEdDQ0N AB0ADR0dACIdIR0hHSE9AP8HB/8dBwf/Pf8HBwf/HQcH/zz/BwcH/z3/Hf8dB/8HB/8HB/8A/wcA /wAHBwf/AAf/Df8ABwf/QgD/PAf/PP8NBwf/AP8HB/9CB/8NIR08DQ08ITwiDQ09IR08IjwNPSE9 IjwiPCI9Ij0NIjwQPSI9Ij0iPCI9AB0NACIAAA0hDQAAAAANAB0NAB0ADQAdACINDSIAIgAdDR0N HQ0NHSH///88////Qh3/////EP///xAi/////xAhPf8H/////w3///8APP8NAAD///8hPP//IQA8 ////AAANAP//DQAN////HTz///8A//8NPABCDSE9ITwNPCE9IR1CHQ0iDSI8IjwiPSI8IjwiPT0i PSE9Ij0QIj1DIgAhAAAADQ0AHQANAA0ADQAhAAAADR0hHQ0AHQAdDR0dIR0NHSE9IR0NHSE9IR09 IR0h/wcdIR1CHSEdQh1CHSE9Ijz//yEHBwf/PAANACEABwA8IQANAAANADwADQANAA0ADQ0APAAh PAANPCENDQA8IjwNDQ1CHTwNDTwiPCI8DQ1CHTwiPA0NPSEdDSI8Ij0iPCIQECI9QxAiPUMQHUMA AA0dDQAhHQ0AAB0ADQAdAA0ADQ0ADQAiHQ0dDR0hHQ0NHSEdDR1CHSEdHSE9IT0QPf8dPSE9Ijwi PSI8Ij0hPSE9ACL/////IQAhDQA8/yENAAA8AA0NDQANAA0ADQANPCEADQ0NAA0NDQ0APCI8ITwh PA08ITwhPEINPCENDRANDQ0hHSEdIR1CHUIdPCIhPSI9IjwiPSE9EEMdQ0M9DR0AIQAAHQAADQAA DQAhAA0AHSEAHQ0dAA0dIR0NHQ0dDR0NDR0hHQ09IQ0QHSEdIR0hPSEdDQ0dQh0hPSI8Ij0hHUIA PQAhAA0AADwAAA0APAANAA0AAABCACEAPA08IQANPA0APA0NDTwNDSE8ITwAPSE9IT0hPSE9ITwN PUIAPSEdDQ09ITwdIR0NDSIAPSE9IT0iPSI9QyI9Q0MdQwAAPB0NAA0NAAAiAAAdAAAAHQ0AHSEA HQ0dIR0NHSEdIR0hHUIdDQ0hHRAdIT0hPSI8HSE9IT0iPCI9IT0hPSE9IT0hHSE8AA0ADQ0ADSEA DQANAA0NIQ0NAB08DQAhAD0ADQ0AQh0hPA0hPA09DTwiPCE8ITw8ITw8ITwiQgAQHSENDSEdIR0h HUIAIg0NIg0dIT0hPSFDIj0hQx1DQ0MAIR0ADQ0AHQ0AAA0hAAANDQANDQ0dDQ0NHQ0dDR0NHQ0d DQ0dDSINHRAAIjwdEB08Ih1CHRAdIT0hPSI8IhAdQh0NDTwADQ0AITwADQA8AA0NAA0NAAA8ADwA IQAADTwAIQ0NDQ08AEIdPCI8ITwhPCI8DQ0NIjwiQh1CPB1CDQ0hPSEdDQAiPCEdQh1CHUIdQg0i IR0iEDwiPSJCIhAQAB0AIQAdIQAADR0AAAANAB0hAB0NAB0iAB0NHSEdIT0AIg0dIR08Ig0dIT0h HUIdIT0hHUIdQh0iPCI8Ij0hPSI8Ig0NDQA8AA0AIQ0NAAANACE8ITwNACENADwdQgANDTwNPA0N IT0hPCE8DTwiPCE8EEI8QjxCDTwhPCJCHUIdQh0hPCINIR0hHSEdIQAdIR0hPSE9IR0iIR1CHUMi ECEADQAdAAANIgAAAA0dACEAHQANACIADR0hHQ0dDR0AIjwdIT0hHSEdQh0iPCIdIT0hHUIdIjwi PCIQHUIdQiI8IjwNDQANDQANADwAAA1CADwAAAANAA0APA0hPAAdQgANDSENQgA8ITwdQh1CPCE9 QgANQh1CHUJCPUJDPBAhPSEdDSIAIjwiPCIADSINIg0QDSIdIR0hDSI9IhAhHSEAHQAiAA0NAAAN AA0AAAAdDQAiAB0NHQ0dHQ0iAB0hDR0hHTwdIT0AIg0dQh08IjwiPQ0dQh0QHUIiPCIQIj0hPSEd ITwNAA0NDQ0ADQ0AAA0NDQ08DQ0NDQ0APCEdQgA9ITwNPB1CPQ08ITwhPCI8ITxDQg1CPBA8Ijwh PSE9ECI8Ig0hPSEdIR0hPSI8IkIdIR1CHUIiDSI8IiEdQyI9AA0NAA0AHQANHQAADQANAA0ADR0h HQ0dACIAHSEdDR0NDQ0iDR0NIgA9IR0NIg0QHSEdQh0hHUIdPSI9IT0hPSI8BwchHSE8AA0AQg0A DQ0NAEIAHQAhPA0NDSI8ADwhDTwhPSE8ITwhDUINPUINQgcHPCI8Qh1CQhBCPUIQECE9ISI8IiEd DSI8IhAhHSEdIR1CHSEdIT0hHSE9IR0hIgAdAA0AIgAAACEADQAhHQ0AHQ0AHQ0dIR0NDQ0dPCI8 HSEdDQ0hHTwiDR1CHUIdIT0hPSI8Ij0hIkIdEBAiPSE8//8NBzwADSE8DQAAQgA8DQ0APCE8DQBC ADw8IT0NPCI8DQ08IjwiPEIdQiE8EP//PAc8QhBCPSE9Qh1CPSE9IT0hHUIdQiINHSEdIkIdIhAi IR1CHSINIkIdIiI8Ig0ADSEdAA0ADQAdAAAdAA0AHSEdBx0hHQcdBwcHHSEHIR0NB0IHBwcNByE9 IQcNPSI8Bx0HHQciPQcHBz0HPSE9Bzwi/wcNITwADQANDQ0NDQ0NBwcHDQcNHQcHBzwhBwc8DUIH BwdCPCE9QjwHB0I8Qv8HIT0HBwc8QwcHQiIHBwciByIdBx0NBw0HBwchPSEdIT0iISI8IhAdISI8 Ig0iAB0AAA0ADQANAA0AAAAhHSE9/wcNHf8d////HQf/Bx0h/wf///8H/wc9If8HIjwi/wf/B/8H PP///wf/B0Md/wdCAP8NBzwNDQ0NDQ08DQBC////If8HPP///zwH//8NByL///9CByE8ITz//0IH IT3/PAf///8QB///Qh3///8i/wc8/wcN/wf///8NBw0iQh0hHUIdIiEdQh0QIiEQIgANDQ0NHQAd ACEADQ0dPAAdAP8HHf8H/wcNHf8H/wc9If//HQf/B/8HIR3/Bx0iPP8H/wf/B/8QB/8H/wcdEP8H PP8H/wcdBwcHBwcHBwcH/wcNDf//BwA9Qgf//wcN/xD/BxA8/wdCPUL/QhD/B0L/B/8HHUIH/z3/ Bx3/BwcHB/8HIv8HIv8HDSIH/yINIh0hPSIdIiE9ISIdIR0QHSIAAB0AIQANAA0AHQAhAB0NHSH/ Bwf/B/8HDQ3/B/8HHQ3/B////wf/Bx1C/wchPSL/B/8i/wcQ////B/8HQiL/Bzz/B/8H//////// ////Hf8HPCI8/wcNDf//Qv8HPSEH/wcQQv8HHUIQQkIH/0I9/wf/B0L//xBC/wdC/////wf/Bz3/ ByL/Bw3//yI8IiI8IiEiQh0iEB1CIiIQISI8HQ0hAB0ADR0AAAANAB0AIR0A/////yH/DQcH/yH/ BwcH/yEHB/8d/wcHB/88Ij0h//8H//8HEAcH/z3/BwcH/zwi/wD/DQchDQ1CHTwiPA3/BzwhPP8H Df88Bwf/Qgf/Qv88Bwf/QkJCPEP//zxCEP9D/xD/HQcHB/8HB/8dB/8d/wcH/yIH/zz/IgcHBzwi IiI9Ih1CHSEiIj0hHSI9IgAAHQANACEADQ0AAB0hHQ0dDf8HAB3/B////x08/////x3///88Iv// //89IjwiPf//B///B////0MQ/////z0h/yE9AP8NPA0NPCE8ITwi/wdCDTz/Qj0h////If//PCI8 ////PUI9QkP/B0NCB/9DECL/Iv///////yEi//8hIv///yL//yIiDf///yIiIjwiISIQIiI9IR0Q IkIiIiEADQ0AIgAAHQAADQ0ADR0AIgD/BwcH/wAdDQ0NIv8HPB0hPSEdDR0iPSIdQiI9IhD//x3/ /wdDIkMiQ/8HPCI9Qh0NQgBCHTwhPSE8IT0hPP8NBwf/PAdCPEIdQhBCHUJCEDxCPUJDQkJC/0IH /0JDQj1CQxAQEB0h/wciPSIhHSJDISIdIj0hPSIiIj0iPCINIj0hIj0hIhAhIhAdIT0iAB0NAA0A DQAhAB0NHQ0AHQ0d/////zwiPB0NHSH/ACIdDR0iPCINQh1CIj0iEEMd/yI9Q/8iPUNDPUP/QyI8 ECE8EDwiPA0hPEINEA08IT0h////Qv9CQh1CPEM8EEI8Q0JCQ0I8Qj1CPUL//0NCEBBDIj0iECIQ Iv8iPCIhPSIhHUMhECIhIiI8IhAiIhAiIhAiIj0hIj0iECIiECIQIgAhAA0dAA0AHQAhACEdIR0N HSEdHSEdACEdITwdIT0iPCINDSI9Ih1DHUMQHRAdQz0iQyJDQyJDIkMiQxAQECE9ITwhPA1CPSE9 ITxCEA1CDUI8QhA8IT1CQhA8QkJCQzxCPUI8Q0JDQkJCQ0JDQkMQEBAQISIQISI9IiIQIiI9IhAi HSIiIj0iIiIQIhAiECIQIhAiECIQIiI8IhAiECIAHQANACEAHQAAHQA9AB0NHSEdDQAdDQ0dDR0i DR0hHRAdIj0hPSFDHUMQIkNDIkMiQx1DIkNDQ0NDQ0MiPUI8Qh1CHUI8ITwhPCE9ITxCPUIdQj0h Qj1CPENCQzxDPENCQ0JDQjxDPENCQzxDEEM9ECIQIj0iHSI9ISI9IhAiIiIiQyJDIkMiIkMiIiIi ECIiECIiECIiIhAiIiIiECIQAA0ADQAdAA0NDQ0dIR0hHQ0dPB0NDQ0dDQ0iABAdIj0hHUIdIj0i PSIQHUM9Ij0iPUNEQ0NDRCJDQyI9QkMdQh1CQjwiQg1CPUI9Qj1CHUINQhBCPEM8QkM8QjxDQkM8 QjxDPEJmQkNCPUJDQ0JDIkIiECIiQiJCIiJDIiIiIiJDIiIiIiIiQyIiIiJDIiJDIiIiQyIiQyIi QyJDIhAiIgAdIR0NAA0AAB0NAB0dHQ0dIR0hHQ0dIR0QDT0hHUIdIj0iEBAiPSI9QyJDIkNDIkMi Q0MiQ0NDQ0NDQyI8EEI8IjwhPBBCHUIhPCFCEEI8Q0I8Q0JCQj1CQ0JDQjxCQ2VDQkNCPENCQ0JD EEMdQyI9IkIdQyIdIiIQIiJDIiJDIiJDIkMiIiJDIiJDIiJDIiJDIiIiQyIiQyIiIkMiQxAADQAA DQ0AHSEdDSIAHSEdDR0dDR0AIjwdIR0iHRAdIj0hHRAdQyJDIkMiPUQdQ0NDQyJDRENDQ0RDEEM9 QkM8IjxCPUIQPEI9Qj1CPUI8QzxDQkI9Qj1CQkNCPENCQ0I9QkJgQkNDQkNDEENCQyJCIhAiIhAi IkMiIkMiIkMiIiJDIiIiIkMiIkMiIkMiIiJDIiJDIiJDIiJDIkMiIiIiAB0NDQAdIQAdAB0dDR0N HQ0NDR0hPQAiHTwiPCIdQh0iPSIQIj0iPSI+IkMiQ0MiQ0RDQ0NDRENDQ0NDQiI8IUI9ITwQEEIQ QjxCQ0I8Q0JCPEM8QkNCQzxCPUJCPUJDQkNCQ0JDQkNCQxBDIhAiQyIiQyIiIkMiIkMiIkMiIkMi IkMiQyMiQyIiQyIiQyIiQyJDIiJDIiJDIiIiQyJDIgANAB0hAB0NDQ0NDR0iHQ0iHR0NACINDQ0i HSI8IiI9Ij0iPR1DIkNDQ0NDQyJDRCJDQ0NKQ0MUQ0NDQz1CPUI9QkJDQjxDPENCQzxCQ0JCPUJD QkNCPENCQ0JDQmZCQmZCQ0JDQkNDQ0MiQyIiQyIiQyIiQyIiQyIiQyIiQyIiQyIiIiJDIiJDIiJD IiJDIyIiIkMiIkMiIkMiQyJDIiIADQ0NHQ0AIh0dIh0NHQ0dHUIdIj0NHSI9IT0iHRA9Ih1DIiJD Qx1DIkMiQyJEQ0NDRENDRENEQ0NDQz1CQ0JDQj1CPENCQkI8Q0JDPEI9QkJDPEJDQkNCZUNCZkJD Q0JDQkNDQ0MiQ0MiQ0MiQyJDIiJDIiJDIiJDIiIiQyIiQyJDIkMiIkMiIkMoI0MiIkMiQyIiQyMi QyIiQyIiIkMiHSEdAA0NHTwdIR08Ih0iHSEdDR0hHSI8IhAdIj0iIh1DIj1DHUMiRENDRENDQyJE Q0NEQwcHBwdDQ0MHBwcHBwcHQkMHBz1CQ0I8BwcHB0M8QwcHBwdDQgcHQ0IHB0JDQgcHQwcHQ0Mi BwcHByIiIgcHIkMiIkMiIkMiQyIiQyIiRCIiQyMiSSMiQyIiRCJDKCIjQyIiQyIiQyIiRCJDIgAN HSEdACIdHR0dIh0NHSE9HSINDR0hHRAdIj0iPSJDHUMiI0NDQyJDIkMiRENJQ0RDFP////8HB0P/ ////////B0P//wdCQzxD/////wcHZv////8HB///B0L//wdDQ///Q///B0Mi/////wcHIv//ByIi QyMoQyMiQyMoQyJKIiIoQyMoQyJDIiNDKCJDI0MiQyIiQygiRCIoQyIiQyINHQANHTwdACIdIh0d Ij0dIh1CHSI9Ij0iIj0iQx1DHUMiQ0NDIkNEQ0NEQyJEQ0RDFP//B0n//0P//wdD/////wdC//8H Q2VD//8HQv//Q///B0P//wf//wdl//8HQ///B0P//wci//8HQ///B0P//wdDI0MiQyJJIiJDIkQi IkMiRCJDIkMiKUMoQyNDIyhDIihEIkQiQyJDI0MiQyIiDQ0dDQ0iHSI9HSI9Ih0iDR1CHR1CHSId Qz0iPSJDIkMiPSJDQ0RDKEMjQ0NEQ0NEFET//wdEQxRD//8HB/////8HQ///B0NCQ///B0NCQ2X/ /wdC//8H//8HQ///B0P//wci//8HIv//ByP//wci//8HIiIoRCIiRCJKIiJDKEQiIkMoI0MjIkMi I0kiKEMiI0MiIkkiIkQiKEMiIkQoQx0NDSIdAB0dIh0iHR0QHT0iHSIQIj0iQx0iIkMiPiI9IkRD I0MiRENEQ0NEQ0QURElE//8HShQUQ0P//wf/////B0P//wdDQmb//wdDZUNC//8HQv//B///B0L/ /wdD//8HKf//Byj//wco//8HSf//ByhEIkkjQygiQyNJI0MiKUMjIkMiSSJEKEMiI0MjSSJDKUMi I0kiIkQiKUMiQyIAHQ0AIj0iHR0iPSIdIh0iHUIdEB0iPSI9Qx5DIkMiQ0QiQ0NDRENDRENEQ0QU SkNESv//B2dDBwdlB////////wdl//8HZUNC//8HQkMHB///B0P//wf//wcH//8HRP//ByL//wci //8HIv//ByP//wdDIkoiIkoiRCgiQyIpQyJDKEMjKEMjIkMpQygiQyMoRCJDKUMiRChDIkMjSSND IgAiPR0iHT0iHR0iHSI9Ij0iHRAiPSJDIiJDHUMdRCIiQ0NEQ0RDRENKQxRJRENnSRT//wcH//9D /0MHB/////8HQ///B0NCbP//Bwf//2X//wcH//9C////FP//Q0n//wcH//8HB///Bwf//0ki//8H IilDKUMiSiIiSiIpQyIpQyMoQyMiQylDIiNDI0kjQygjSSIjSSIjSSMoQyJDIgA9IR0dIh0iHUMd Ih1DHSIdQyIdQyI9Ij1DIkQiQ0NDREMjQ0RDSkNEQ0RERElESkRnSf////9mQ0L/////Q///B2b/ /wdDZUNC/////2ZDQv////9mZv//Q///SkP/////Q/////8o/////0oiSv//B0oiKUMpQykiSiJE IkoiQylDIkQoQyMiSiJDKCNDKCNDKCNDKEMjSSJDRCJKQ0MiHQ0dQx0dRB0dIj0dIj0iPSI9Ij0j QyJDI0MiQ0QiRCJDRENJRENEFERJRElEbURsSm1EEhRsQ0NmQkNlQ0L//wdC//8HZUNlQ2VJZUNl SWVmQ2VmSGVDZkNJQ0NEIv//BylDKEQoRChKIkoiSiL//wciSiJKIilDKUMpQykiSSMoQyMoQyMo QyIpQyNJIiNJIkQoRCJKIkRDKUNJQ0NmACIdIh0iHSIdQx4iHUMdIkMdQx5DIj1DI0MiREMiQ0RD RENERBRESURERBJESUQSRBJEbERDFENmQkNlQ0Jm//9lQ///ZkJmQmZDZWZDZWZCZmtDZmZDbENs Q0RJQ0oi/yJEKEoiSiJKIkooRChK//8iSiJKIkoiSiJKIilDKSJEIilDIkoiRChEIihEIkoiRCgj QygjQyhEKENEQ0NsQz0hHT0iPR1DHiIdQx0iHUMdIkMiPSJDIyJEIkMjQyNDRElESURJRBRESURJ REpnShJKEkpnSWZJQmZCQ0NrQ2VDZUNlQ0JmQ2VJZWZJZUNma0NmZUllbENmRENJI0kjSSNJKUMp QyhKRChEKUpDKUooRChKI0kjSSMpQylDKUMpQylDIyhEIilDIyhEKEQiSiIjSSNJI0kjSUNEbENs QmYdHR0iHSIdIx1DHiI9IkMdQx1DIkMjQ0NDQ0RDQ0RJRERDRBRERElESkRKZ0pnSm1EbURsQxRm Q2ZCbEJlQ2ZCZkNrQ2ZrQ2tDZmVDZWZlSWZlbENmZkNsFENKQ0oiSiJKIkopREojSSlKSSNJKUMp RCgpQykHByJKKCNJI0kjKEQoI0kjIkoiRCgHBwcoI0kjSSNJI0oiSkNEbENmZmxmIT0iHSI+Ij0j HSI9IiM9IkMiPSJEQ0MjQyNDI0MjQ0RDSkRKZkpESkRtREpKbURtShJKZ0pmQ0llQ2VDZkJmSGZC ZmZlQ2VmZkhmZUlmSWVmSGZlbENsZ0NKQylDSkMpSkoiSkkpSSlJI0kpRClEKEojSiL//wcjSSNK IkojSSNKIkoiRChEIin///8HB0QoRCgjSSNJRElESURsFGxDZh0iHT0iHSMdIj4iHUMdIj0iRCJE BwdDRENEQ0RDBwcHB0RmSgcHBwdEBwdtRG1LbWdKZwcHSWYHBwcHQmZmQmZmBwdlQ2xCZmVmBwcH B2VsZgcHBwdsQwcHRElEKUMpQwcHBwcjBwdKI0opBwdKBwciSSNJ//8HSgcHI0ooBwcHBwcoBwci SiIHB0T//wcHQylESSNJI0lESURsZmxmbG1DHR0iHiI+Ij4iHUQdQyJDHUMi//8HQyNDI0NE//// /wcHSv////8H//8HbUptRG1Kbf//FGb/////BwdIZmZI//8HbGVmbEJs/////wcHbP////8HB/// B0RJI0kpSv////8H//8HKEpJ//9K//8HKUopSv//B///BwdJ//////8H//8HKET//yhE////ByhE KCNJRElESkQSbWZsbktSHR1DHkMeIh4iHkMdIkMdRCJEQ///B0lEQ0RE//8HFP//Z///B0r///// B0RuSgcHB///B0n//wdl//8HZgcHB///B2VJZWZs//8HZf//bP//B2z//2b//wdKKUMpRP//Sin/ ////B0oj//8H////ByNJI0n///9K//8H//8HIv//B///ByL//wdJI////wcHRElKREpKFBJtZkpL UlJSUkMdIh0iHkMeIj4iIj4iQx1DIkT//wcHBwcHRP//BwcHBwf//wcHBwf//wdtSv///0r//wdD //8HSf//B////2X//wcHBwcHZv//BwcHBwf//wcHBwcH//8HSURKKEopSilK/////wcpSv//B0r/ /wdKKUop//8HKP//B///Bwf//wf//wcp//8HI///B///B0lKREoSbW1tS1FLS1JSUjEdIj4iPiIe Ij0jHUMiPSJDIkRD////////Bwf///////8H//////////8HS21Kbm1t//8HbP//B0L//wdma2Zs ////////Bwf///////8H////////B///B0RKQ0ojSUojSf////8HKUr//wcj//8HKUkpRP//B0r/ /wdK//8H//8H//8HIv//B0r//wf//wcjSm0SbUtRUlJSUitMMVNSQx0dIx0jPSMeIkQdIkQdRCJD I///B0oj//8H//8HRP//B///B0T/////B21ubUptbf//B0n//wdm//8HSWZCbP//B2xm//8H//8H bP//B///B2b//wf//wdJSkpKSkpKSgf/////BylK//8HSf//BylEKUn//wcH//8HKQf/////B/// Byn//wcp//9E//8HBxJLUVJSUlJTMVNSTDFYUh0iPSMeRCMdRB1DI0MdQyJEQ0T//wdDRP//B/// Bwf//2j//wcH/////wcHB21ubRL//wcH//8HB///ZmVsZmb//wdlbP//B///Bwf//2z//wcH//9m //8HBwdKSkpKSv///wf//wcHB///B////wdKSkpK////Kf//Sv8pBwf//0r//wcH//8H//8HKUr/ /wdSUlJSUlJSWFJSMVJMUzFDHh1EHiMdRB4jQyM9IkNEIkMj//8HSkT//wdE/////21Kbf////9t /////0ttbW3/////bGb/////ZWZsZmtm//8HZmz//wds/////2xma/////9sbP////8SbRISEgcH Sv///////0pK//9K//8HSkpKSv//Sv//KUop/////0op////////////SipR//9SMVJSU1I3U1JT N1NMK1hTIh0jHUQjHiNDHkQiREMjQ0REQ///BwcH//9KREpnSm1FbURtSkptS21Kbm1tbm1tbf// B2xmbGZsZWxlZmtmbP//BwcH//9sZWxmbGZsi2ZshmxmbIZsbGxsZ2xtbf//Bwf//0pKREpKSkpK Sv//B0pKSkpKSkpKSilKKUpKKUpKKUopSin//wcqUlIxUjFSU1hSMlJSU1I3UlNSMVJTWD0iPiMj HkQjHkQiRCJEIkQiRCn///////9ESkRKSkVtSkptS2dLbUpubW5tbm1tbW1m/2xmbGZrZmxmbGZs Zmz///////9sZmxsi2yLZmyLbGxsi2xshmxmrmxtbGZt/////21tbW1tEhJtSmz//xJnbRISbUpK SkpKSkopSilKKUopSylLS/8xUlIxUjFSUlIyUlhZMVJZUlNSWCtTUlMdIh5EHkQjHkQjQ0QiRENE RENEREpEREpEREpnSmdKbUVtSkptSm5tS3JubW7rbW1mbYtmbGxli2ZrZmtma2ZrZmxlbIZsZWyG bGZsbItmbIZshmxmi2xsi2xmi22LbIxsrmZsbWZtbG1tbGdtZ2xtbWxtbW1tSlFKS0pKMEovS0oq UUtSMVJSMVIxU1JSMlgxU1JTUlNYUlNYU0xMU1hSPSI+IyMeRSMeI0QjQ0QjQ0pEI0pEI0pESkRK REtKbkptSmdLbUttS21ubW5tbW1tbWxmbIpmbGxmbGxmbGZsZmxmbGxmbGyLbGyLbIZsbItsbGyL bGxmi2aLbItsi2yLbItsrmyubG1mbWyubGxsi2yLbWxtbW1tSkowSkpLSypRUlIxUlgxUllSMVJZ MVJTUlhTMVhTWFNYU1IrUlhSWSIdIx5EIyM+I0RERCJEQ0QjREpEREpERERKRG1EbURtS21LbUpu bXNtbm5ybm1tbWZsbGZsZmxmbItlbGxrZmtma4Zsa4ZshmyGbGyLbItmi2yLZotsi2yLbItsi2yL bItsi2yLbItsi2yGbGyubG2LbYttrm1tbUtRS1ExUlJSMVIxUlIxUlMxUlNSMVIyWDJSUllSUlNY U1hMUlNYU1I9HiNEHiQ+IyMjRCJERClEREpEREpEREpESkRKSm5KbkRtSm5KbkpubnJubW5tbWxs bGZsZopsi2tmbIZsZotsZmxmbGZsbGxsbItsi2aLbItmi2yLbGyLbIuLbK6Li2yLi2yLi2yLbIts bItmi2yLbK5srm1tbnNRUlJSUjFSMVJSUlNSUllSWFMxWFJZUlJSU1hTUllSWVJMK1lSWVJYIkMe I0UjI0UeREQjQ0REREpEREpEREpEREpEbWhKbUttS21LbW5ubXNubnJtbW1tbGaLbGxmbGaLbGxs bItmbItsbItsi2aLZotshmyLbItsi2yLbIuLi2yLbItsi2yLrmyLbIZsi2aLZotsbGxsbYttbnNz UlJSUlJSUlJSUlJSU1JYU1hTUlNSWFMxU1JZMVJSWVJSU1hMK3pSUlNYUx0dRB4jHkUeIyNEQyNK REpEREpESkRESkRKRUpKSm5KbkpuSm5Lcm5ucm5ubW1tZm1sZmxmi2yLbGaLZotmbItsZotmbGaL bItsi2yLbYtsi2yLi2yLbItsrmyLbIuLbItsi4uLbItsbGxsZmxmZm1Mc1J0UnRSUlJSUlJYUlJS UlhSU1hTUlJYUzFTUlgxUlNYU1JYU1grTFNYUnpSWVIiQx4jRCQjRR5FRCNDRERKREpESmdKRERK Z0pnS21LbUttS21uc25uc25tcm5tEm1sZmxsi2ZsZmyLbGyLbItmi2xsi2yLbGyLbItsi4tsi4tt i2yLi4tsi4uLi4tsrotsi21sbGxmbGZDQkMQQyJLc1JSUlJYUlNSUlJTUlNSU1hTWFNSWFNYU1hS UlNSWVJSUlJZUlJMTFh0WVJSWFJSPUo+Iz8jPiQjIyNDRERKRG1FSkRFSkRKREpLSm5KbkpLbUtu bW5ybnJuc25tSm1EbG1mbGZsi2yLbIZsi2ZsbItsi2yLbIuLbItsi2yLbItsi2yLi2yui3Gui22u rotyi22LbGZmQxAQPUMhPUI9UVJSUlJSUlJYUlJSUlhSWFJSWFNYUllSWVJTWFNYUlJSWVJZUlIr TFJSWVJZUnpSeiJEIyMjJEUeRR5EI0RESkRKREpLSkRKREtnSm5KbkpuSm5tS25zbnNubm1LSm1K bWxnbGxsi2Zsi2xsi2yLi2yLbYtsrmxsi2yubIuLbIuLbIuLbYuubK6ui22LbW1tbm5uS0o9Q0I9 Qg0NPB0iQ1JSUlJTUlJSUlJYU1JSU1JZUll0WVJSWVJSWFJSU1hTUlJSUlIrTFNYdVh0WHRSWFJD RCM+JD4kRCREI0RKREpFSkpoSmdKRUptS21KbkpuSm5KS25ybm1uc21zbm1KSkpESW1sZ2yLbIts rmyLbWyLi2yLrmxtrm2ubK5yi22LbYuubYuuba6RbXNzdHN0dFJzUlFuQkM9IT0iPB0hPEtSUlJS UlhSWFNSUlhSUlJYdFNYU1JZUlJYUnVYU1hSUlhSWEwlUnlSdFhSUnVYelJ0REREIx5FJB8jHyNE REtESkRLSkpFSkRKbkpubkpubUtubnJubnNuc25uSkpKSkpKSm0SbW1sbWxtbYttbYttbW1tbW3r bXNtbm1tba5trq5yrnJzc3NSdHRSdFJSUlhSUnRSUT1DPBA8EA0NDQ1SUlJSWFJSU1JSWFNSdVhS WVJZdFhSdFlSdVhSUlJSU3lTUkwlUnpSWHVSeXlSdFJ5UkpKRCNEHiREJEQeREpESkRuREpoSkRK bkpuS3JuS25uSm5uc25uc25tc25KSkpKSkpKSkptbW1tbW1tbW1tbXJtbW1tUW1LSlFKc0tzc3Rz UnRSdHRSdFJSUlJYdFJTeVJSUlJLQj0hPSE9ITxLUlJYUnRTWHRZUlh0WFJ0WVJ5UlJZUll0WFJT WFJ6UnlSSyVMeVJ0UnRYdHRSeXR5dFJEREREI0UkH0UkHkRLREpFSkttSkRLbUtucm5ubXNtS25z bnNuc25zbm5KUEspSilKSkpKSkpQbkpzSkpQbkpLSnNLUUtRUXRSdFJ0UnRSUnRSUlJYdFJ6UnRY U1JYdFJZUlJ5Uj1CPTwQAD0dWFJTUlNYUlJSeVJTUlJYUlh1WHpSeVJ0WXRYdFJ0WHRSRStSdFJY dHlSeXRYdHRYdHl0REpESkQfI0UfRCQeRG1LSm1LbUtESkttbm5uc3NuS3Nubm5zkm+SbnNzS0pK SkpLSilKSkpLSkpKS0pzS1FRc1JRUnRSdFJSUlhSUlJSeVJ0UnlSdFlSUlhTUnlSUllSUnlTUlFM SkpESm1zmZNYUnlYdFh0WVJ0WFJYdXl1WHRSeVJ6UnlSdFh0WHRLJUx0UnR5dFh0dFJ5dHR5dHR5 dEpESkVKHkUkJCRFHiNFSm5LbUtESktubnNuc25ubm5LknOSbnNzc3RubkpRSilLL0tLUVFLUVJS UlFSUlJSUlJSUlJSWFJSUlJSUlJYUlNSWFJTWFJSeVN5UllSWHVYUnpSWHRMUXR0eZOak0x6dFJS UlJSUnlSelJ1eVJ5UnlTeVJ0eVJ6Unl0Um8kK0t0WHRYdHR0eVJ0dHl0dHl0dHREREtESkUeRSRF H0UjREtuSm5LSkVubnNubnNuc1FubnNudI1zk26Sc3NMUUxRUktSUVJMUlJRUlFSUlJSUlJSUnlS UlJSUlJSUlJYdVJYUlJYUlN5UlN5U1h0WHVYU3lSWXRSUXN0dJOZRiV0dFJYdFJSeVJSUnRSWHRY dHp0eXV5Unp0eXR0UkslTHRSeXR0dHR5dHR5dHl0dHl0dHl0SkVKZ0tKRB9FH0UkH0REbnNLbUVK c3Nuc5Juc25uS3OTc5J0knOTc3RRUktSTFFSTFFSUVJSUlJSWFJSdFJSUlJTUnlSWFJSWHRSUlJY dFJ6UnRYUlJYUnlSWXRYUnlSWXRSUW90dJmTTEaTmVhSdFJYUnRSeVJYdHR5dXl0eXR5dHl0eXR5 SyVGUXR0eXR0eXR5dHR5dJN5dHl0c3R0dERKSktES0UkRSQkRSQ/I0tubkpLbm5ujXNvc5NLbkuN c410knOTc5NRTFFSUVJSUVJRUlJSUVJSUnRSUlJYUlJSeVJSUnVYdFNYUlh0UllSUlJYUlN5U3lT eVJ6UnpSelh0S0xzdHSZdCWZmVJ0UlhSdFJ5UlJ0dHl6dHl0enR5dHl0dHlMJEZMeXR0eXR0eXR0 dHR5c3R5dHR0dHRzdHNES0RLbUttIx9FJEUfJEVFbktFSm5zc3NzjXNzS25zdJJzkpNzkpNzUlJS UlFSUVJSUlFSUVJSUlJSUXRYUlJ5UlJZdFhSUlh0UnpSU1h0WHVYdVh5Ulh0WHRZdFh0WHR0TFF0 dHSZmkWTmpl0UnRSdFJRdHl0WHR0dHl5dHl0eXR0eUtGJUx0dHR0eZN0mXR5dHmTdHR0dHN0c3Rz b3N0REtES0RLS0REJB9FJEUfI0RLSkRzdG6Sb3Nzbm5LknOTc5NzHHSSdFJRUlFSUlJSUVJSUlJS UVJSUlhSUlJ5UlJ5UnRYdVh0U1hSeVJ5WXRYdFh0Unp0elJ6dFh5dXl6S0tRdHSZmZNvmb2ZTEt0 UnlSdHRSdHR0eXl0dHR5dHl0UkUlRnN0eXSZdHl0eXR5dJNzdHRzdHN0c3R0c3N0c0RKbkpLSkRE SkUkRSVFJUUfREtuc25zc26Sk0tLbpMcknQcHJKTdFFSUlJSUlFSUlJSUnRSUlJ0UVJ0UlJ0UlJ5 UnlSdFh0WHR5U3lSdFJ5U3l1WHp0WHl0eXR6dHl0dFF0dHSZmplvmZqZmXRzS0t0dHlSdHR5eZN0 eZl0eXRvJEZGdHSZdJl0eHSTdJN0c3RzdHN0c3RzdJJzc250bnNLREtEbktESkRuRSQ/JEUfRR5F c25zb5JzdHNLbnNzk3OTHJOTc3RSUnRRUlJ0UlJRdFFSWHRSWFJSUlJSUnlSUlJSUlh0WHR6UnRY dXl6dFJ5Unl0eXRSmnp0dHl1eXR0dHR0mZmTTJmak5mTdHR0S3RSdHN5k3R0eXR0dG4kRkZ0dHh0 dHN0dJN0dHN0c3RzdHNvc3Rzb3N0dHRzc3RzSktLSktKRERKc0tFJEUlRSVFJERzdJJ0kpNzS26T kxyTc5Nzk5lSUVJSUlJzUlJ0UlJSdFJSdFJ0UlJ5UnRSUnRSeVF0UlJ5Unl5dFh0Unl6dHR5dXl0 eXR5dHl5dHl0dHl0dHR0mZl5dHl0eZl5UipudHR5dHlzdJl0S0UlRlJzdHSTeZN0k3N0knRzdG6T c29zdHN0knN0jXNzbnSNc0VKaEpuRUpEbktuS0UkRSBFJD8kRXOSdJJ0b0t0mZJ0mJOTmZNzUnlS dFJ0UlJSUlJSeVJ5Unl0WHRSUlJ0WHRYUnRSUnlSdFJSdFJ5dHl5dHlSdHl0eXR5k3l0k3mUmZN0 dEpMK1JSk3l0mXR0dFJMUnSZdHR0mXRFRSUlb3OTdJOSdJJ0dHN0c3Rzk3N0c3N0c5Jzb3OTc3Nu knSSc3NLS0tLS0pERHRuc250RSRGJUYkRR9FdJOTc0tzk3OTk5NzmZOTUnRSUlJSeVJ0UnlSdFJS dFJSUlJSUnRRUlJSdFJYdFJ0UnlRdFJ5dHl0dHR5dHR5dHR0dHl0eXR5mZmZmXQjS1JSUnmTeXRz eXRYTEt0eZOZb0UlRiR0knSTc3RzdHNvc5J0knRzk3N0knRzk3N0knOSbpNzknONc5KNbkRLbUtE REpRbktuc29LRSQkQCVFH0VLmXNvbpmTk3iTHJOYk1FSUnl0UVJSWHRSUVJ0UlJ0WHRSdFFSUnRR dFJSdFJ0WHR0Unl0dFJ0Unl0eHR5dHN5mXR5dJlzk5qZk3RLPCNSUnR0mZN5k3R0dFJMmZNvJEUl RXSTk3STc3SSdHN0knN0c250knRvknSSdJJvknPsdJJzkm5zkm6Sc0tLS0tLREpub3NLc25zbks/ RiRGJUUkP0VLc3SSk5mTk5mTk1JSdHlSUVJ0dFFSdFJSeVJ0UnNSUXRYdFJ0Unl0eXR0UnR0WHR0 UXl0dHRRdHR0dHN0dHRzdHR0eXSZmXRRS0NEKlGTmXR5k3mTc3RSS0tGJEZGdJJ0c5Nzc5NzbnSN c3NvknSSdJKSc5J0ko1zknOTbpJukm7sjXONco1zS25LREpEblFuS25vc25LS0tFJUUlQCRFJEWT mZOTk5iTHHR0UVJSdFJ0UlJYdFJ5UnR5UnlSdFJ0UlJzWHRSdFJ5UXR5dHR0dHR0dHRzdHR0UXRz dHRzdHSSeZN5k5l0K0xSmZN0eZOZk5OSmXRLTEtLRW90k3OTdI10knRzk3OSc5NzknOSbpJzk3OT knOTkpNukm6Skuxz7HOuc42SS25Lc0RESktubnNzc25LS250bkUlRiVGJD8kRW6Zk5mTmZN5UlJ0 UlF5UnRRdFJzdFJzUnR0dHlSdHN0eXR0eXRzdHR0dHN5dHN0UXR0eXRzdJNzdHRzdHNzdHSSdByZ UlJSS1KTmZN0k3mTeZNzS1FuUpNzdJJ0knN0knSSbpJvc5NzjXSNc5JzjXOSk3OTknOSkpKSbpKN ko2RjZLsrm5LS25EI25Lc0tLb250Sktuc3STS0UkQCVGJD8kRW6Tk5OTdFF5c1J0UnR0UnRSdFJ0 Unl0eXR0eXR0dHR0dHN0dHR0eHR0dHR0dHN0k3N5c3R0c3Rzk3N0dG5zdHR0c3R0UlJSTHSZk5iT k5Mck5NzmZOSHBwcdJJ0knOSjXSSc5KSbpKSc5JukpKNc42SkpKNko2SjZKSko2Sko2SrpJLbktL REpudG5zbnNzS0Vuc5Nzkxx0biRGRiVGJD8kRW6ZdFJ0UnR5dHRRdHR5dHR4dHR0c3R0eHR0eHR0 c3R0dHN0eXR0c3lzk3SYdHRzk3Rzk3RzdHN0knN0c5Juk3OTc3R0UlJSTHR0k5mSk5mSk5OTmZOT kpOSkpNuknOSbpKSbpJzjZJu7JJukpKSko2SkpKSkpKNko2Rko2Rja6SS0tLSkREdHNudG5udG5K S5Nzk3QcdJNMRSUkRiVGJUUkP0tRdHRSc1J0UXl0c3R0dHR5k3R5dHR0dHR0eXRzdHOTdHSTc3Qc dHh0dHQcdHN0bnSSdHOTc3STc250knSTc5Nzk5J0UVFLTHOSkxyTk5OYk5KTku+T75OSkpONkpKN c5KNknKNkpKNkpKSjZKNko2Sko2SkpKSjZKukpGRrktuS0RKbm50dHN0bnNLbnOTdJNzk5lzb3OT byBFJUYlRSU+H0VLdHR0dHR0dHR5c3R0c3R5c3SZc3RzdHN0dHN0eXN0c3QcdHSTc5lzdJNzk3Nz dJJ0knSSdI10knRzknOTknNuRUVES3N0k5Pv75KTk++T75OT75KTku+SkpKNko2Sko3skpKukpKN kZKSkpKSkY20kq6Sz5Guka6urpFLS0tERXN0dG5zb3NuS0t0mXOTmZOTS3N0k5mZb0YfRiVGJUYk PyRFS3N0dHRzdHSZdHR0dHR0dHN0c3STdHN0c5NzdJJ0dJNzHHSTdJNzk3OSdJJ0knSSc5NzknOS kpNuS0UfJCVFdHR0k5IHkpO1k5iTtZmSku+Tku+TjZKStZKSkq6SjZGNko2SrpKNkZKukY2RjZGu ka6RrpGukZGuS25LREtzb3N0dHOTS25uk3STdJOZdG9umZOZk5mTk0w/JUYlRiVAJD8kPktLdHRz dHSZdHOZc5N0dJJ0c3SSdHOTc5N0knSSdJNzkxxzk3OTdJJ0kpNzk5KSdJJvbkUeRSRGRW+NkpOS k5KTkpOSk5O1k5O1k++Tte+StpGStZKSr5KStZKRjZGSkY2Rta6SrpGutJGuka6RrpGLtK6ukEtM SkRLS3R0dG50dG5LdHOTc5mTk1FudJmUvJmTvJOZeW9MRkYlRkYlRiU/JB5FRUtucxx0k3Rzk3N0 knQcdJJ0c5N0c5Nzk3OTk3OTk3OTc5IckpJzkm5uRURFJCQlRkVvjpKSk5KSk5KTkraSk7WSkraS kraStZKTtZKRtZKStJK1kbWutZG1ka+Rka6RtK60ka6RrrSRz5DPkYvPkK5LbkREc29zbnN0c25L S5NzdByTc5ludHS8mZOZk5mZk3SZc3RuTEUlRiVGRiVGJCQ/JD8kREVLbm9zdJJ0kpOTknSSk5Jz k3SSc5OTkm6Sbm5uRUVFRR9FJSUlQEVubpOSkpKStpKSkpKSkpOStZKStZK1krWStZK1krWStZK0 krWStJK0kbWSz5G0ks+Rr5Guka60rpGLrouRrpCukK6LbkspRG50S3Ruk3RuS3STkpN0mZN0S3S8 k5m8lJmTmZMcdHRzdHN0c29LRSVGJUZGJUYlRiRAJUUkPyQ/JEUkRSNFREtFRUVERURFI0UkPyQ/ JUZGJUYlRkVujZKSjbWSkrWStZKSjZKNkpKSku+StZK1kbWStZG1krWutJK0jbSRr5HPkq+RtJK0 jbSStJGRtZHPkYuRi66QrouLrouRi0tEREtRbnRudHN0REuSdHSZk5OZS250k5mTmZO8mZNzdHOT dHOTc5NzdJNzb25FRkUlQCVGJUYlRiVGJUYlRUVGRkUlRSVGJEYlRkYlJUYlRiVFRW5uko2StZK1 kpKSkrWSkZKNkpKSkpGNtI21tJK1krWStZK1krSNtJK0krSStJG1kZG0ka60kbSRz5K0z5G0kbSu ka2Ri4uRi66Qi65LSkRubnRuc3Nvc0tudJIcdByTk29LmbyUmbyZmZOTc3STc5N0knRzk3N0knOT c3Nzk3NuS29LRkUlRkUlQCUgJSUlIEYkRiVFRkZLaW5uc42SkrWSkpK1kpKSkpK1krWukrWSrq6S kY2SjZKSkpLPkrWRtZG1tJKRtbWRta60kbWRta60ka+RtK60kZG0kZG0rrSutK6RrrSui7SLi66L S0REdEt0bnSTdERLbpN5k5OZdHNLdJOZmZOatpmZk3OTc5Nzk3SSdHONc5Nuc5OSk3OSk5KTc5OS knOT7JKTko2TkpOSk42SkpKSkpKSkrWSkrWSkrWSkrSStJK1krSStJKSrpKSka+RtJKRz5G1krS1 krS1krW0tZG0kbW0ks+RtZG0rpG0ka60rrSutK60tJGRrpGLtIuRrpGukYuukEpES3Nvc29zdHNL S3N0k3N0k5lLbpOZtpO8mZmTmZN0knSSdJJzk42Sc5OSdJJzkm6Sk3Nzk5KTkpONkpOSkpKTkpOS jZKSkpLvkpOStZKStZKStZK1krWStZK0kpK1tZGSrrSRta6SkZLPkq61kbWRtZG1rrSRtZG1kbWu tJG1rpG0krSukc+QrpGutJG0ka6Rz5DPka6us66Qz4uRra5ES0tvdHN0k3RuS26TdJOZkpN0S3SZ mZmavJO9mZJzk5OSc5Nuc5J0bZKTc41zk41zk5KSjZKSk5KSkpKSk5OSkpKSkpKSku+StpK17++S tZK1krWStZG1krW1krW0kq61rrSSrpG0rrWukbSRtK60kbW0kbWRta60kbWRtJK0kbS1rrSutJGR z5Gus66RrrSukYuRrpDPkK6LrpCui5GLI0Ruc3Nvc29zbktzc5Nzk3STmZOTmbeZtpqZmZOTdJJz dJJzk41zk5KTc5OSk5JzkpKNkpKTko2SkpKNkpKukpKSkpKS77a1krSStZK1tZK1kbWStJK1tZG1 krS1kbWRtJGRz5G0rrSRtJHPka6RtJK0krW0kbWRtbWRr5G0rrSukbSRtJGutK60ka60i7SRi7Su i7SLkYuRi5CukIuRi0RKdG90c3R0dEtudJN0k5mTmZOZmZOZmZm8k5mTkpKTkpOSkpJzkpKT7JKS kpKSjZKSkpKSkpKSkpKukpKSkpK1krW177WStZK1krS1krW1kbW1kbW0krS1kbS1krSRz5G0rpG0 kbSRrrSRtJG0rrSRtbSRtZG0tJG0kbSRtJK0rpDPkZHPka6QrrSRrpGutK6Ri5Gui66Lrouui66L rosEAAAABwEBAAkAAAD6AgUAAAAAAP///wAiAAQAAAAtAQAABwAAAPwCAQAAAAAAAAAEAAAALQEB AA8AAAAmBg8AFABUTlBQBAAMAAAAAAAAAAAAAAAAAAkAAAAmBg8ACAD/////AQAAAAMAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAA/v8AAAQKAgAAAAAAAAAAAAAAAAAAAAAAAgAAAALVzdWcLhsQ k5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rmgCAAAkAgAAEAAAAAEAAACIAAAAAwAAAJAAAAAP AAAAqAAAAAQAAAC4AAAABgAAAMAAAAAHAAAAyAAAAAgAAADQAAAACQAAANgAAAAKAAAA4AAAABcA AADoAAAACwAAAPAAAAAQAAAA+AAAABMAAAAAAQAAFgAAAAgBAAANAAAAEAEAAAwAAADDAQAAAgAA AOQEAAAeAAAADwAAAE9uLXNjcmVlbiBTaG93AAAeAAAABgAAAENpc2NvAGVlAwAAAHigDgADAAAA EwAAAAMAAAAEAAAAAwAAAAEAAAADAAAAAAAAAAMAAAAAAAAAAwAAAOgQCAALAAAAAAAAAAsAAAAA AAAACwAAAAAAAAALAAAAAAAAAB4QAAAHAAAABgAAAEFyaWFsABAAAABUaW1lcyBOZXcgUm9tYW4A DQAAAHRlbXBsYXRlLnBvdAAkAAAAUGVlci10by1QZWVyIDNyZCBwYXJ0eSBjYWxsIGNvbnRyb2wA IAAAAFBlZXIgdG8gcGVlciAzcGNjIJcgUHJvYmxlbSBTZXQAHQAAAFBlZXItdG8tcGVlciAzcGNj IJcgUHJvcG9zYWwACwAAAE5leHQgc3RlcHMADBAAAAYAAAAeAAAACwAAAEZvbnRzIFVzZWQAAwAA AAIAAAAeAAAAEAAAAERlc2lnbiBUZW1wbGF0ZQADAAAAAQAAAB4AAAANAAAAU2xpZGUgVGl0bGVz AAMAAAAEAAAAAJgBAAAEAAAAAAAAACgAAAABAAAAUgAAAAIAAABaAAAAAwAAALIAAAACAAAAAgAA AAoAAABfUElEX0dVSUQAAwAAAAwAAABfUElEX0hMSU5LUwACAAAA5AQAAEEAAABOAAAAewAyAEMA QwBEADIAMAA0ADAALQBDAEYAQwAzAC0AMQAxAEQANAAtAEIAOAAyAEIALQAwADAANAAwADkANgAz ADgAMwAxADYANgB9AAAAAABBAAAA3AAAAAwAAAADAAAABwAAAAMAAAAGAAAAAwAAAAAAAAADAAAA BwAAAB8AAAAWAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGMAaQBzAGMAbwAuAGMAbwBtAC8AAAAf AAAADgAAAHcAdwB3AC4AYwBpAHMAYwBvAC4AYwBvAG0AAAADAAAABwAAAAMAAAAGAAAAAwAAAAAA AAADAAAABwAAAB8AAAAWAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGMAaQBzAGMAbwAuAGMAbwBt AC8AAAAfAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAA9g8dAAAAFAAAAF/AkeP6TwoABQD0AwMAYgBybWFoeQgAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAABAAAAAgAAAAMAAAAEAAAABQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAA DgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABgAAAAZAAAAGgAAABsAAAAc AAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAAlAAAAJgAAACcAAAAoAAAAKQAAACoA AAArAAAALAAAAC0AAAAuAAAALwAAADAAAAAxAAAAMgAAADMAAAA0AAAANQAAADYAAAA3AAAAOAAA ADkAAAA6AAAAOwAAADwAAAA9AAAAPgAAAD8AAABAAAAAQQAAAEIAAABDAAAARAAAAEUAAABGAAAA RwAAAEgAAABJAAAASgAAAEsAAABMAAAATQAAAE4AAABPAAAAUAAAAFEAAABSAAAAUwAAAFQAAABV AAAAVgAAAFcAAABYAAAAWQAAAFoAAABbAAAAXAAAAF0AAABeAAAAXwAAAGAAAABhAAAAYgAAAGMA AABkAAAAZQAAAGYAAABnAAAAaAAAAGkAAABqAAAAawAAAGwAAABtAAAAbgAAAG8AAABwAAAAcQAA AHIAAABzAAAAdAAAAHUAAAB2AAAAdwAAAHgAAAB5AAAAegAAAHsAAAB8AAAAfQAAAH4AAAB/AAAA gAAAAIEAAACCAAAAgwAAAIQAAACFAAAAhgAAAIcAAACIAAAAiQAAAIoAAACLAAAAjAAAAI0AAACO AAAAjwAAAJAAAACRAAAAkgAAAJMAAACUAAAAlQAAAJYAAACXAAAAmAAAAJkAAACaAAAAmwAAAJwA AACdAAAAngAAAJ8AAACgAAAAoQAAAKIAAACjAAAApAAAAKUAAACmAAAApwAAAKgAAACpAAAAqgAA AKsAAACsAAAArQAAAK4AAACvAAAAsAAAALEAAACyAAAAswAAALQAAAC1AAAAtgAAALcAAAC4AAAA uQAAALoAAAC7AAAAvAAAAL0AAAC+AAAAvwAAAMAAAADBAAAAwgAAAMMAAADEAAAAxQAAAMYAAADH AAAAyAAAAMkAAADKAAAAywAAAMwAAADNAAAAzgAAAM8AAADQAAAA0QAAANIAAADTAAAA1AAAANUA AADWAAAA1wAAANgAAADZAAAA2gAAANsAAADcAAAA3QAAAN4AAADfAAAA4AAAAOEAAADiAAAA4wAA AOQAAADlAAAA5gAAAOcAAADoAAAA6QAAAOoAAADrAAAA7AAAAO0AAADuAAAA7wAAAPAAAADxAAAA 8gAAAPMAAAD0AAAA9QAAAPYAAAD3AAAA+AAAAPkAAAD6AAAA+wAAAPwAAAD9AAAA/gAAAP8AAAAA AQAAAQEAAAIBAAADAQAABAEAAAUBAAAGAQAABwEAAAgBAAAJAQAACgEAAAsBAAAMAQAADQEAAA4B AAAPAQAAEAEAABEBAAASAQAAEwEAABQBAAAVAQAAFgEAABcBAAAYAQAAGQEAABoBAAAbAQAAHAEA AB0BAAAeAQAAHwEAACABAAAhAQAAIgEAACMBAAAkAQAAJQEAACYBAAAnAQAAKAEAACkBAAAqAQAA KwEAACwBAAAtAQAALgEAAC8BAAAwAQAAMQEAADIBAAAzAQAANAEAADUBAAA2AQAANwEAADgBAAA5 AQAAOgEAADsBAAA8AQAAPQEAAD4BAAA/AQAAQAEAAEEBAABCAQAAQwEAAEQBAABFAQAARgEAAEcB AABIAQAASQEAAEoBAABLAQAATAEAAE0BAABOAQAATwEAAFABAABRAQAAUgEAAFMBAABUAQAAVQEA AFYBAABXAQAAWAEAAFkBAABaAQAAWwEAAFwBAABdAQAAXgEAAF8BAABgAQAAYQEAAGIBAABjAQAA ZAEAAGUBAABmAQAAZwEAAGgBAABpAQAAagEAAGsBAABsAQAAbQEAAG4BAABvAQAAcAEAAHEBAABy AQAAcwEAAHQBAAB1AQAAdgEAAHcBAAB4AQAAeQEAAHoBAAB7AQAAfAEAAH0BAAB+AQAAfwEAAIAB AACBAQAAggEAAIMBAACEAQAAhQEAAIYBAACHAQAAiAEAAIkBAACKAQAAiwEAAIwBAACNAQAAjgEA AI8BAACQAQAAkQEAAJIBAACTAQAAlAEAAJUBAACWAQAAlwEAAJgBAACZAQAAmgEAAJsBAACcAQAA nQEAAJ4BAACfAQAAoAEAAKEBAACiAQAAowEAAKQBAAClAQAApgEAAKcBAACoAQAAqQEAAKoBAACr AQAArAEAAK0BAACuAQAArwEAALABAACxAQAAsgEAALMBAAC0AQAAtQEAALYBAAC3AQAAuAEAALkB AAC6AQAAuwEAALwBAAC9AQAAvgEAAL8BAADAAQAAwQEAAMIBAADDAQAAxAEAAMUBAADGAQAAxwEA AMgBAADJAQAAygEAAMsBAADMAQAAzQEAAM4BAADPAQAA0AEAANEBAADSAQAA0wEAANQBAADVAQAA 1gEAANcBAADYAQAA2QEAANoBAADbAQAA3AEAAN0BAADeAQAA3wEAAOABAADhAQAA4gEAAOMBAADk AQAA5QEAAOYBAADnAQAA6AEAAOkBAADqAQAA6wEAAOwBAADtAQAA7gEAAO8BAADwAQAA8QEAAPIB AADzAQAA9AEAAPUBAAD2AQAA9wEAAPgBAAD5AQAA+gEAAPsBAAD8AQAA/QEAAP4BAAD/AQAAAAIA AAECAAACAgAAAwIAAAQCAAAFAgAABgIAAAcCAAAIAgAACQIAAAoCAAALAgAADAIAAA0CAAAOAgAA DwIAABACAAARAgAAEgIAABMCAAAUAgAAFQIAABYCAAAXAgAAGAIAABkCAAAaAgAAGwIAABwCAAAd AgAAHgIAAB8CAAAgAgAAIQIAACICAAAjAgAAJAIAACUCAAAmAgAAJwIAACgCAAD+////KgIAACsC AAAsAgAALQIAAC4CAAAvAgAAMAIAADECAAAyAgAAMwIAADQCAAA1AgAANgIAADcCAAA4AgAAOQIA ADoCAAA7AgAAPAIAAD0CAAA+AgAAPwIAAEACAABBAgAAQgIAAEMCAABEAgAARQIAAEYCAABHAgAA SAIAAEkCAABKAgAASwIAAEwCAABNAgAATgIAAE8CAABQAgAAUQIAAFICAABTAgAAVAIAAFUCAABW AgAAVwIAAFgCAABZAgAAWgIAAFsCAABcAgAAXQIAAF4CAABfAgAAYAIAAGECAABiAgAAYwIAAGQC AABlAgAAZgIAAGcCAABoAgAAaQIAAGoCAABrAgAAbAIAAG0CAABuAgAAbwIAAHACAABxAgAAcgIA AHMCAAB0AgAAdQIAAHYCAAB3AgAAeAIAAHkCAAB6AgAAewIAAHwCAAB9AgAAfgIAAH8CAACAAgAA gQIAAIICAACDAgAAhAIAAIUCAACGAgAAhwIAAIgCAACJAgAAigIAAIsCAACMAgAAjQIAAI4CAACP AgAAkAIAAJECAACSAgAAkwIAAJQCAACVAgAAlgIAAJcCAACYAgAAmQIAAJoCAACbAgAAnAIAAJ0C AACeAgAAnwIAAKACAAChAgAAogIAAKMCAACkAgAApQIAAKYCAACnAgAAqAIAAKkCAACqAgAAqwIA AKwCAACtAgAArgIAAK8CAACwAgAAsQIAALICAACzAgAAtAIAALUCAAC2AgAAtwIAALgCAAC5AgAA ugIAALsCAAC8AgAAvQIAAL4CAAC/AgAAwAIAAMECAADCAgAAwwIAAMQCAADFAgAAxgIAAMcCAADI AgAAyQIAAMoCAADLAgAAzAIAAM0CAADOAgAAzwIAANACAADRAgAA0gIAANMCAADUAgAA1QIAANYC AADXAgAA2AIAANkCAADaAgAA2wIAANwCAADdAgAA3gIAAN8CAADgAgAA4QIAAOICAADjAgAA5AIA AOUCAADmAgAA5wIAAOgCAADpAgAA6gIAAOsCAADsAgAA7QIAAO4CAADvAgAA8AIAAPECAADyAgAA 8wIAAPQCAAD1AgAA9gIAAPcCAAD4AgAA+QIAAPoCAAD7AgAA/AIAAP0CAAD+AgAA/wIAAAADAAAB AwAAAgMAAAMDAAAEAwAABQMAAAYDAAAHAwAACAMAAAkDAAAKAwAACwMAAAwDAAANAwAADgMAAA8D AAAQAwAAEQMAABIDAAATAwAAFAMAABUDAAAWAwAAFwMAABgDAAAZAwAAGgMAABsDAAAcAwAAHQMA AB4DAAAfAwAAIAMAACEDAAAiAwAAIwMAACQDAAAlAwAAJgMAACcDAAAoAwAAKQMAACoDAAArAwAA LAMAAC0DAAAuAwAALwMAADADAAAxAwAAMgMAADMDAAA0AwAANQMAADYDAAA3AwAAOAMAADkDAAA6 AwAAOwMAADwDAAA9AwAAPgMAAD8DAABAAwAAQQMAAEIDAABDAwAARAMAAEUDAABGAwAARwMAAEgD AABJAwAASgMAAEsDAABMAwAATQMAAE4DAABPAwAAUAMAAFEDAABSAwAAUwMAAFQDAABVAwAAVgMA AFcDAABYAwAAWQMAAFoDAABbAwAAXAMAAF0DAABeAwAAXwMAAGADAABhAwAAYgMAAGMDAABkAwAA ZQMAAGYDAABnAwAAaAMAAGkDAABqAwAAawMAAGwDAABtAwAAbgMAAG8DAABwAwAAcQMAAHIDAABz AwAAdAMAAHUDAAB2AwAAdwMAAHgDAAB5AwAAegMAAHsDAAB8AwAAfQMAAH4DAAB/AwAAgAMAAIED AACCAwAAgwMAAIQDAACFAwAAhgMAAIcDAACIAwAAiQMAAIoDAACLAwAAjAMAAI0DAACOAwAAjwMA AJADAACRAwAAkgMAAJMDAACUAwAAlQMAAJYDAACXAwAAmAMAAJkDAACaAwAAmwMAAJwDAACdAwAA ngMAAJ8DAACgAwAAoQMAAKIDAACjAwAApAMAAKUDAACmAwAApwMAAKgDAACpAwAAqgMAAKsDAACs AwAArQMAAK4DAACvAwAAsAMAALEDAACyAwAAswMAALQDAAC1AwAAtgMAALcDAAC4AwAAuQMAALoD AAC7AwAAvAMAAL0DAAC+AwAAvwMAAMADAADBAwAAwgMAAMMDAADEAwAAxQMAAMYDAADHAwAAyAMA AMkDAADKAwAAywMAAMwDAADNAwAAzgMAAM8DAADQAwAA0QMAANIDAADTAwAA1AMAANUDAADWAwAA 1wMAANgDAADZAwAA2gMAANsDAADcAwAA3QMAAN4DAADfAwAA4AMAAOEDAADiAwAA4wMAAOQDAADl AwAA5gMAAOcDAADoAwAA6QMAAOoDAADrAwAA7AMAAO0DAADuAwAA7wMAAPADAADxAwAA8gMAAPMD AAD0AwAA9QMAAPYDAAD3AwAA+AMAAPkDAAD6AwAA+wMAAPwDAAD9AwAA/gMAAP8DAAAABAAAAQQA AAIEAAADBAAABAQAAAUEAAAGBAAABwQAAAgEAAAJBAAACgQAAAsEAAAMBAAADQQAAA4EAAAPBAAA EAQAABEEAAASBAAAEwQAABQEAAAVBAAAFgQAABcEAAAYBAAAGQQAABoEAAAbBAAAHAQAAB0EAAAe BAAAHwQAACAEAAAhBAAAIgQAACMEAAAkBAAAJQQAACYEAAAnBAAAKAQAACkEAAAqBAAAKwQAACwE AAAtBAAALgQAAC8EAAAwBAAAMQQAADIEAAAzBAAANAQAADUEAAA2BAAANwQAADgEAAA5BAAAOgQA ADsEAAA8BAAAPQQAAD4EAAA/BAAAQAQAAEEEAABCBAAAQwQAAEQEAABFBAAARgQAAEcEAABIBAAA SQQAAEoEAABLBAAATAQAAE0EAABOBAAATwQAAFAEAABRBAAAUgQAAFMEAABUBAAAVQQAAFYEAABX BAAAWAQAAFkEAABaBAAAWwQAAFwEAABdBAAAXgQAAF8EAABgBAAAYQQAAGIEAABjBAAAZAQAAGUE AABmBAAAZwQAAGgEAABpBAAAagQAAGsEAABsBAAAbQQAAG4EAABvBAAAcAQAAHEEAAByBAAAcwQA AHQEAAB1BAAAdgQAAHcEAAB4BAAAeQQAAHoEAAB7BAAAfAQAAH0EAAB+BAAAfwQAAIAEAACBBAAA ggQAAIMEAACEBAAAhQQAAIYEAACHBAAAiAQAAIkEAACKBAAAiwQAAIwEAACNBAAAjgQAAI8EAACQ BAAAkQQAAJIEAACTBAAAlAQAAJUEAACWBAAAlwQAAJgEAACZBAAAmgQAAJsEAACcBAAAnQQAAJ4E AACfBAAAoAQAAKEEAACiBAAAowQAAKQEAAClBAAApgQAAKcEAACoBAAAqQQAAKoEAACrBAAArAQA AK0EAACuBAAArwQAALAEAACxBAAAsgQAALMEAAC0BAAAtQQAALYEAAC3BAAAuAQAALkEAAC6BAAA uwQAALwEAAC9BAAAvgQAAL8EAADABAAAwQQAAMIEAADDBAAAxAQAAMUEAADGBAAAxwQAAMgEAADJ BAAAygQAAMsEAADMBAAAzQQAAM4EAADPBAAA0AQAANEEAADSBAAA0wQAANQEAADVBAAA1gQAANcE AADYBAAA2QQAANoEAADbBAAA3AQAAN0EAADeBAAA3wQAAOAEAADhBAAA4gQAAOMEAADkBAAA5QQA AOYEAADnBAAA6AQAAOkEAADqBAAA6wQAAOwEAADtBAAA7gQAAO8EAADwBAAA8QQAAPIEAADzBAAA 9AQAAPUEAAD2BAAA9wQAAPgEAAD5BAAA+gQAAPsEAAD8BAAA/QQAAP4EAAD/BAAAAAUAAAEFAAAC BQAAAwUAAAQFAAAFBQAABgUAAAcFAAAIBQAACQUAAAoFAAALBQAADAUAAA0FAAAOBQAADwUAABAF AAARBQAAEgUAABMFAAAUBQAAFQUAABYFAAAXBQAAGAUAABkFAAAaBQAAGwUAABwFAAAdBQAAHgUA AB8FAAAgBQAAIQUAACIFAAAjBQAAJAUAACUFAAAmBQAAJwUAACgFAAApBQAAKgUAACsFAAAsBQAA LQUAAC4FAAAvBQAAMAUAADEFAAAyBQAAMwUAADQFAAA1BQAANgUAADcFAAA4BQAAOQUAADoFAAA7 BQAAPAUAAD0FAAA+BQAAPwUAAEAFAABBBQAAQgUAAEMFAABEBQAARQUAAEYFAABHBQAASAUAAEkF AABKBQAASwUAAEwFAABNBQAATgUAAE8FAABQBQAAUQUAAFIFAABTBQAAVAUAAFUFAABWBQAAVwUA AFgFAABZBQAAWgUAAFsFAABcBQAAXQUAAF4FAABfBQAAYAUAAGEFAABiBQAAYwUAAGQFAABlBQAA ZgUAAGcFAABoBQAAaQUAAGoFAABrBQAAbAUAAG0FAABuBQAAbwUAAHAFAABxBQAAcgUAAHMFAAB0 BQAAdQUAAHYFAAB3BQAAeAUAAHkFAAB6BQAAewUAAHwFAAB9BQAAfgUAAH8FAACABQAAgQUAAIIF AACDBQAAhAUAAIUFAACGBQAAhwUAAIgFAACJBQAAigUAAIsFAACMBQAAjQUAAI4FAACPBQAAkAUA AJEFAACSBQAAkwUAAJQFAACVBQAAlgUAAJcFAACYBQAAmQUAAJoFAACbBQAAnAUAAJ0FAACeBQAA nwUAAKAFAAChBQAAogUAAKMFAACkBQAApQUAAKYFAACnBQAAqAUAAKkFAACqBQAAqwUAAKwFAACt BQAArgUAAK8FAACwBQAAsQUAALIFAACzBQAAtAUAALUFAAC2BQAAtwUAALgFAAC5BQAAugUAALsF AAC8BQAAvQUAAL4FAAC/BQAAwAUAAMEFAADCBQAAwwUAAMQFAADFBQAAxgUAAMcFAADIBQAAyQUA AMoFAADLBQAAzAUAAM0FAADOBQAAzwUAANAFAADRBQAA0gUAANMFAADUBQAA1QUAANYFAADXBQAA 2AUAANkFAADaBQAA2wUAANwFAADdBQAA3gUAAN8FAADgBQAA4QUAAOIFAADjBQAA5AUAAOUFAADm BQAA5wUAAOgFAADpBQAA6gUAAOsFAADsBQAA7QUAAO4FAADvBQAA8AUAAPEFAADyBQAA8wUAAPQF AAD1BQAA9gUAAPcFAAD4BQAA+QUAAPoFAAD7BQAA/AUAAP0FAAD+BQAA/wUAAAAGAAABBgAAAgYA AAMGAAAEBgAABQYAAAYGAAAHBgAACAYAAAkGAAAKBgAACwYAAAwGAAANBgAADgYAAA8GAAAQBgAA EQYAABIGAAATBgAAFAYAABUGAAAWBgAAFwYAABgGAAAZBgAAGgYAABsGAAAcBgAAHQYAAB4GAAAf BgAAIAYAACEGAAAiBgAAIwYAACQGAAAlBgAAJgYAACcGAAAoBgAAKQYAACoGAAArBgAALAYAAC0G AAAuBgAALwYAADAGAAAxBgAAMgYAADMGAAA0BgAANQYAADYGAAA3BgAAOAYAADkGAAA6BgAAOwYA ADwGAAA9BgAAPgYAAD8GAABABgAAQQYAAEIGAABDBgAARAYAAEUGAABGBgAARwYAAEgGAABJBgAA SgYAAEsGAABMBgAATQYAAE4GAABPBgAAUAYAAFEGAABSBgAAUwYAAFQGAABVBgAAVgYAAFcGAABY BgAAWQYAAFoGAABbBgAAXAYAAF0GAABeBgAAXwYAAGAGAABhBgAAYgYAAGMGAABkBgAAZQYAAGYG AABnBgAAaAYAAGkGAABqBgAAawYAAGwGAABtBgAAbgYAAG8GAABwBgAAcQYAAHIGAABzBgAAdAYA AHUGAAB2BgAAdwYAAHgGAAB5BgAAegYAAHsGAAB8BgAAfQYAAH4GAAB/BgAAgAYAAIEGAACCBgAA gwYAAIQGAACFBgAAhgYAAIcGAACIBgAAiQYAAIoGAACLBgAAjAYAAI0GAACOBgAAjwYAAJAGAACR BgAAkgYAAJMGAACUBgAAlQYAAJYGAACXBgAAmAYAAJkGAACaBgAAmwYAAJwGAACdBgAAngYAAJ8G AACgBgAAoQYAAKIGAACjBgAApAYAAKUGAACmBgAApwYAAKgGAACpBgAAqgYAAKsGAACsBgAArQYA AK4GAACvBgAAsAYAALEGAACyBgAAswYAALQGAAC1BgAAtgYAALcGAAC4BgAAuQYAALoGAAC7BgAA vAYAAL0GAAC+BgAAvwYAAMAGAADBBgAAwgYAAMMGAADEBgAAxQYAAMYGAADHBgAAyAYAAMkGAADK BgAAywYAAMwGAADNBgAAzgYAAM8GAADQBgAA0QYAANIGAADTBgAA1AYAANUGAADWBgAA1wYAANgG AADZBgAA2gYAANsGAADcBgAA3QYAAN4GAADfBgAA4AYAAOEGAADiBgAA4wYAAOQGAADlBgAA5gYA AOcGAADoBgAA6QYAAOoGAADrBgAA7AYAAO0GAADuBgAA7wYAAPAGAADxBgAA8gYAAPMGAAD0BgAA 9QYAAPYGAAD3BgAA+AYAAPkGAAD6BgAA+wYAAPwGAAD9BgAA/gYAAP8GAAAABwAAAQcAAAIHAAAD BwAABAcAAAUHAAAGBwAABwcAAAgHAAAJBwAACgcAAAsHAAAMBwAADQcAAA4HAAAPBwAAEAcAABEH AAASBwAAEwcAABQHAAAVBwAAFgcAABcHAAAYBwAAGQcAABoHAAAbBwAAHAcAAB0HAAAeBwAAHwcA ACAHAAAhBwAAIgcAACMHAAAkBwAAJQcAACYHAAAnBwAAKAcAACkHAAAqBwAAKwcAACwHAAAtBwAA LgcAAC8HAAAwBwAAMQcAADIHAAAzBwAANAcAADUHAAA2BwAANwcAADgHAAA5BwAAOgcAADsHAAA8 BwAAPQcAAD4HAAA/BwAAQAcAAEEHAABCBwAAQwcAAEQHAABFBwAARgcAAEcHAABIBwAASQcAAEoH AABLBwAATAcAAE0HAABOBwAATwcAAFAHAABRBwAA/v///1MHAABUBwAAVQcAAFYHAABXBwAAWAcA AFkHAABaBwAAWwcAAFwHAABdBwAAXgcAAF8HAABgBwAAYQcAAGIHAABjBwAAZAcAAGUHAABmBwAA ZwcAAGgHAABpBwAAagcAAGsHAABsBwAAbQcAAG4HAABvBwAAcAcAAHEHAAByBwAAcwcAAHQHAAB1 BwAAdgcAAHcHAAB4BwAAeQcAAHoHAAB7BwAA/v///30HAAB+BwAAfwcAAIAHAACBBwAAggcAAIMH AAD+////hQcAAIYHAACHBwAAiAcAAIkHAACKBwAAiwcAAP7////9/////f////3////9/////f// //3////9/////f////3////9/////f////3////9/////f////3////9////nQcAAP7///////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////1IAbwBvAHQAIABF AG4AdAByAHkAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAWAAUB //////////8DAAAAEI2BZJtPzxGG6gCqALkp6AAAAAAAAAAAAAAAAAAAAAAAAAAA/v///wAAAAAA AAAAUABpAGMAdAB1AHIAZQBzAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAABIAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAWlAEAAAAAABDAHUAcgByAGUAbgB0ACAAVQBzAGUAcgAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGgACAQEAAAD//////////wAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAIQHAAAAEAAAAAAAAAUAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIBAgAAAAUAAAD/////AAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUgcAAMxSAAAAAAAAUABvAHcAZQByAFAA bwBpAG4AdAAgAEQAbwBjAHUAbQBlAG4AdAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgAAgH/ //////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAApAgAAHlAKAAAA AAAFAEQAbwBjAHUAbQBlAG4AdABTAHUAbQBtAGEAcgB5AEkAbgBmAG8AcgBtAGEAdABpAG8AbgAA AAAAAAAAAAAAOAACAQQAAAD//////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAHwHAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= --=====================_352329970==_-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 12 13:32:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA15005 for ; Tue, 12 Dec 2000 13:32:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 331D144357; Tue, 12 Dec 2000 12:32:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by lists.bell-labs.com (Postfix) with ESMTP id EC5E244351 for ; Tue, 12 Dec 2000 12:31:23 -0500 (EST) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id eBCIVD506273; Tue, 12 Dec 2000 13:31:13 -0500 (EST) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id NAA13047; Tue, 12 Dec 2000 13:30:10 -0500 (EST) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Tue, 12 Dec 2000 13:31:03 -0500 Message-ID: From: "Roy, Radhika R, ALCOO" To: dean.willis@softarmor.com, brian.rosen@marconi.com, sip-h323@egroups.com Cc: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C06469.AA30EA50" Subject: [SIP] SIP-H.323 Presentation VGs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 12 Dec 2000 13:30:55 -0500 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_01C06469.AA30EA50 Content-Type: text/plain; charset="iso-8859-1" Folks, I am enclosing the VGs of the SIP-H.323 Interworking presentation. Alan Johnston will be presenting this as I am away for vacation. Best regards, Radhika R. Roy AT&T ------_=_NextPart_000_01C06469.AA30EA50 Content-Type: application/octet-stream; name="Roy_SIP_H.323_Int_Reqrmts_Dec3.zip" Content-Disposition: attachment; filename="Roy_SIP_H.323_Int_Reqrmts_Dec3.zip" Content-Transfer-Encoding: base64 UEsDBBQAAAAIAA9OhCnSFQkMnhgAAABwAAAiAAAAUm95X1NJUF9ILjMyM19JbnRfUmVxcm10c19E ZWMzLnBwdOw7C3Qc1XX3zexPq13tWsi28I/xF9NYZmzRlkASy8h/YluVBOQ0Teu1NPYuXu0uuysZ 0w8ihkBDT2oCJXVLwUChxEnAIeRT0tTikJ4ANcVJcUtPD6lzCCfEpxDxayAQpvfe9+azu1ohr+0e 0pPR2Xlv3rx3//e++94bHX1m2vG7vzrrR1B1fQx0eM9ugpCvTeDvN52HJOB726aqU16AP/vX16/U lYCX9IcSpNuf6ktRf6MzAI4n5Y/qQWyL4k/Dn65sgIoEvKZ3YeP58ETiBDaY8INEQPUDeDRBsNqN OUbEbjMvtj9pR8yoGTNbzKT5oh2wF8FS+CT8HvwhbLd/ZCex//0E1NTMmN1iv2POsmfb59jC/mvz DvOX5nvm35h3mkHzXfNsY67RZE83P2p/ym4ym824mTCnmYfANFYanYY+/7gdtFeb3eZac7250Rww 95o3mDeanzPvNu817zP/zvyi+bj5gvmi+RPzFfNN83/M+bAYzoNlsBwugothFXwK/hhS9oA9aFv2 TjttZ+wr7V121h6yc3beLth32nehxI6F/5K5/GZiDd77IQNDYEEJDNiC5W4seyGPbSnI4fsLv7Gd f2se3g5v/atuprGMYDuVf/KsbgIE0JkcWClIq7HQEKzQAoAvJeaRJ55D2uuSCgFDGKJL69K26dv0 0cAoquqLCdJrmHXWhM9dcG+CcATB/uUqLBcYAINysFuCgkc32/4Zt0g7aqeq4OGMi18Fqb+iAOvb ELdTH2UaABLQHPgzQSWMX8+jQuPjhKEMMBfL+fiLKNBEb0D9CJAmQTEPEfVjCKr8ID5TnegPq1JT pS6ax7dhOcoyuE5gW2Qv1SOHRRLtY0zgQ+QxQZL4Lvf5Z3HHCoCnuf4vfD/K9+/z/d8F60hEEKvQ sB5ZpRG2JMx6lfBRwO6Cea8mJf4IQadeP8fIfg6MJ+Ywxa/rbeDJXF2jdEvA0fDNWJ4DNvfBsYGY 14f5SsAv9J389J7OiifKfqnTNLEZpFE5ZVkZcFYZ9P0zAQ7FAf7tXdu+H82LRhbgHd0RaSHiPdO7 rmZCN57YRjaiyCbTcEOSilsAd3GYkip5ILEQ730bezo2LO9c2WlszJWt4u58cVcmt9Pota4azhSt IStXLgHcnZiFXRc5ULgmEIyAOQr8Qe7RpN7HFU4dWlRLUqEO8tNB9j4BHmWS6NnqiYhuriJaXg8k zoepEG2sKaZ2lI2+cqo8zAxgNMcw7VxUE4hGMlCP+FmqxSFeKBJWY8WPa5BxLeWiI7WzmNqdynaU MoWONJLYkfGR2FG0rip1mOby8tXl8+I96VTJMlZcZFySKmUGjIFUNmtYpXJqezZTSjPkVG7QwNFD mVyqnMnnjN513WrUyouMrQVqS2WXGanBkVRuwBo0dljIb9EqLeORJas4khmwSjzsknw5bRRobMlI p0Yso5w3hiyrbJTTlrHTylnFVNYo+tQer2WxgKDxCRFlcsZ2Arhxbf86xrWx/7KO/nh3fojHIqAB KzPCHQfyxUK+mFKjCBsDI6VQxF3jKuUuV8Sdbtsyt20NOCprh6xbb3OtSMBKX2unr/cyXzspuwfv Zyv4YXCUHVUtMbfFMcCA2+LYoe62eK4lLXiOeiILjtWx4Avxvg41ms1cI7Wa32FM1aIdU/6wC49q 1abscOeZ8lmqpdKUDyR+LGjeTeNsa0AR7yM4n5ewHMTnQWxJwQ4oY303tmfxz4Dt3LcEw1gbwtYy /sn+eZylDdjEs/Uw3ouwB842TFiBdHwcn0sMaQBrElIZRzjwCCvBlJAyDImgD0JHHYgbsW0HQihy flDGvoQ/xZB7YR10Y0mjhhhDsQpfCevDsBM5J5okl04vKY1sDcVxV1KZKeCeisQkRQ7GjQj/MuS3 H+t9sB65/C2sSTwGy2ByzKuxlkNIV7sS3IC5XSf6BXmDtJvXXbt53bUbyl6k9c5V78h648LpWWm9 i6Fu/MVomxtMFQcrTXWJO3gJ1Jqq43aeqSZUS7WpvoZU9bCRZjnpzDDjZBKVpprhZHQY3w4qlRZ4 VIF7e0KLY0ihvgPYl4wvowxYjt+JT4RhpytMR019qKgeTP0tVFGRzaig1DNYoTiLVZRh1ZBSCljL K5ri2C/PibN8l8I6va90hRL2uwyp7GEeUkjpLmwto4kQtdcoM80oo/I4K/nMhjjfyTDLFdyTu+6A SnMvYk+qV7qN7Ce5JmqJz4KSTplxbWcdeGZ8BbpArQkaKJlLmXMJw5GuA1/y6dBdKe2OCjheCCmx PEgDFwE5QDdiMDCIlbA3UbIFLme3Wot4tyqYRZbrWtaIhbAqnVHaSolpLFdwlVMhIo+uvculvo8l T/yQ/KrDZqXlSOek9s3cewDbZTgj+GuRTpIbWYXFeiIM5EWX4H2P60Vfdn3iMrdtD3jO/GW33so9 PCc/mPgY3tepMSFwPO57qkVzW5aqFm8yXKFazq9Kj1UKLS/hFCLQo6qYvl4Lp+Xajr8TnEkn4C39 01Gi92c68UVohRZucvJj59oG42EDeJHGz6Ojo/LFkf3Q2XkEjhyx4eGHH3b70cLA6UuFvV9WqOX2 22/3wTvCfXbs6AQC2bm/U64LEKZ9ZEcN3s5OmdA8//zzTMPmzZvhxIkTdekjGEQLUghjY2N1+9E7 2CHpg/31+e3cb8N++wjDI34BF7tkCaJmsSsmWewKtdildIoynyRC+SNwlsxNVUtmso3nJoFiSHQw iiuCs4xnhSGo1xx+XmAc5YWzhlYr34/z4llDqPT8bUgG5QLamHTZPk/Vqmlwlu0xRcPJLtt7EGuv bALRREtbZfhk+epZQtPcZwlRd58l1ID7LCFvQ8iOzzlXQWkr6LaQnIRbbwfNrbeB7tZbXb+k+ugE UNp9UNp8UFp9UJI+KEn0vFjgeIg8UBt/LkQ2EBl3Nh9oGyUB+vgIvw+MUwwR0DSehNpLgyiPI+BE EfV/F8tW1a4R0qi3MXAtSRZ5eGP+CFwHV6cEfBru+QrAXq5fz/UbmZvDSNM5VVsIAqapLQS5bWBj valiYwA5Ybyj4pA42tYTSMA0RffjzU5UETivJCA+3s9PlUmRgffubGZgF62qrMFM2dicKmFmZJQz 5axllMp7shbAPQmKufPVKLkIng+OtkkGXcKTga5k8Do0j/8ueDLoX1BfBqfG/fEAcQ+Jau4JkKa4 v5PbK9fDvXW5t64uS+ZL8T5rII/rxKw1YmXj/elM0amvyw8XcSWpHjI7nDrJa54rL5kfxpgSqutc JyqkHPvAL8dPYHmJkHIMKDnuRTnSuv8G5lhZiwDeXgqydC4cmGjTyJHOIfH34om2Q4Lgg09PwSo9 jULbwvoaktgP4+hqPYG70eXoCepQ8h0c+VD0HkH6GGGepT6kRT7A83OdFH19MT9coJyC+jjpvqzp uBimRW8rNQTr74qEVQvJ4Wnw5BCqkUP5DMshlXi19am2WJLk0M00VcqBIktvb2/HbzhLEe88R9Z0 ZVLPucOIqbd8TIVrmLpg0Zll6h/hqpZvt93Lys1NwBRNrM7eUpe1k/RZWj6QH3KUOt3lkWoaqkur q1Rv98OZFoj/r2N5T0zy36T4fxz53wDE/23Iv+NCJMXDWNca5raQGGt6ptlkFX6UKajkliikPaaO Cz7sbEN6WZ6MTbQNyduMQSL+EvCURzSRfktIPNoAEkmDbhWfu+tmuE388Dtp9P9W7C3JC+gkllU6 RdnkFDPHBIzrt2lExavO7ix2jJk0T/Zrcp78OJZdap6keZU60jx5QpzEPBnx5skrwTdP0i3qcXgt Ci6gYtu1guAeFtMw/jtqiKDqV2mC6ZAKeEQ8q8Va5kSrYz6pKMgxv2pWUhirZ6VHlp6pWelQtEs7 0HK0rZpC4iGk1c5KGtc/iLNShW3SbQLbJKu8jS301G3zycRTjDkW+CuQtvh5oL1vaYuEUMSkLZpQ a4t/KqGyk38WfLYY82yxgqMYnHGOXtHnhYgSue6jK+G5zSixJGent3W/N2muDmKBbwSlJB4MUh4v JUHchJJSEuuCJ+GVSU8Sg+DzShqE6r8XJfERqMw4Gg2U2xKHxLbQaJJwjflwBRCXgd0WYqZM2+I4 65432QRF12f4Lum5ietS15/l+818lz5LFHrRAzh6sDx1ztAdD+W8cTQ8UdacgH3sofJ47E43ayY+ VvviSlDJzJtoA1v3ndGJ9uVQR+i6aV8LE3XfZJoqpx46aDrJIx1nDq48aHISKzlJUWjYAF4u0tgJ hNdCgrxF86VhNYIcPMOCnBvdDZEZu1pIkGGOvlVzOI7cYA2lcmVjtZSk0WGsz+a3W32FVA7z04Fl Rm9qMJ3ZlTJ6lxu9+T34fnX/kv5l8cszhUzO6EllcVQZW7cWhku76fBqi1Um+Zd4dHx1FuFsyqdz pXI+h902d280rsgXs4Pd+aFlRnc6VcRYj8i359MKNdLQb2Wtvj04IwzJrHhZfE1qJDNoXJHCPLnD 2DJsFVMGHWgN5zIDfFCjsF06nBtEfH2o/DSffW2wcjne/x5ID2evKWZyOQsBdOezw0PbMynjslxm xCqWMuU9cTIQiixhqdkI7xhIjUYCXKOzaMGql0nbwcQjeG9x1S1nN7lvLlucI6faPk1uy4KaFicF DNW0NLstbTV9nJZao21zW9zIjIZJhu7OD2SYMW8dJueHvbz2Or052Sv6c8KbJQhN3DmH5vxM0k+z wU1CzgajgvZefDlaWs4G7aJ2NnBc0Lnc2SDtzQYUid3ZIC0jdDfy3c4ErPmdfRxZBXMpqqJpUqNo enzCPYj4JNHUj1Ovwfm3NTh1H85CkHDum3Dl3zIBTgET6BdxfpD1W/DrN1tfv9WXq99sHf1mq2V9 fc9k+u1i/SaDp6TfGpyLanD69WuGRsWBtkLLKemXCPgA69fw67cwuX6XCheep99CHf0WqmXdtmRk Ev0e5z3EQ3X8d2Rq+q3BWa7B6ddvF/vv0Tr6rcU5oX4R5/+Nfsf1qwJEg1ozC9KnXDOvCEh9nhcg nqU+SdfhNqnPx/SJ9Ukz1M2q7uqzrU52TlPVac7OAfY1HU8avDf4jA+XrnB5ydh399VPxm5UyVjt avkk1gnTiZLRGaTxtUxZZTJGAFc4+2EqUYhQTdY1zj7l4pVapJ9UizBwBkS4bTouyMJEeCWu4BlR F+GS6rrNhyvUJt3uBcRF2/xSaKMshOvoKFNtp4xxy2PsiPW+R3S+QWzyL5oYubPxckxrnmDjha5m DsmB8R/4aAsr2ryF3qJbJsvr6XIWenTdxPf6Cz3hW+gJH826j+ZDdbZiiOGYmkbkoZt/K6b6a7+a wNMGkwSe07d9AFCcaTIVPfx69SyA5+fQl8wAD80l60nC8Hn0FaIJxxYCfH0xwF+cSz3f5FUdfc+1 dzrPL/BKh+RmrsvVr69fves9NJhAVKtpJ40ev+Gu197emk5+6ZYIfOjcr/0HWc4bM7zVeRqkfdOs SbZ+B3AghW+BXGY9C8ALuOOgPnIScmlFVkQwKDWhLcNFgjwCUzRBWy0AFwoJ98cIlHxpEUztI13q S1/5uSvpVO5KXKXiahoy7/eOTHqFCWmq06nB5sxAMV/K7ygbPfndVrEnn8mVAfF14bvrl3x+jGBR Hf7LXn3fm4cF1cd+/sOvxl6X9a67z10jfn9MENwX8bcefw9Pl8fu1BaBfHJzjKdwRP79KE3g8gMT ksCSUAIXkTa7s5eQP4oDn9KkbKlHhHuQpGaqloXcEkD/7d/S09MGT4zLjRgKL2viIwpOVPWOci+S 9Rt6JUyiMKFa2rhXADXmxS+ZVjRrTi2mPaU9ytlYQMQ5XXlXc6IRtXYISfUvNHnKQm8WqDeiosfc 0HwYh6PamPo4QL6phAHu5cDQWEpE7QwlNZL3Ovxdg3AudSEJlzaKik6r3FMKCTnzL0I+NuL4jbAJ duv0W6/eCxebn65xHB9R2EOM3cHiyMqPxaFhdmA9PCkMtKFKHuUm+juVDin8cAIs8SbqwdJs475J HvWSDP/wDw7uBf2pdH4o5YwNKoodGCgFHwx6t1y0c6khneQHK6MfQTmQ3F0PpGUH4ouib0ewTp9E yJFCjdSmBH22gv495rjCrSkZBrLPFowX07mWwLZEg5iSClNOUJIst7rCNPfWod5f1urtQe1qfZ+2 VK/W20SUSK2MK63scwyiSisBpZXghJqt5oaktTJ6n7aSKaDD3SjQX6iObCaH1qSgXa4TcSvw+eSk sR5GdAPS2sTSqMRdaaP7xOm00aJGnLinwmg3QbSeCP7i/DejIctpVdBf0IhbddTM8JoU3OaG4MYV 3AtZh3R2HUZIcYy1Jyf9R7S3xa3aATGx9CtpIEm9o73sRghQV39myCoZW6zdOBkOpXIYzCWUaquc iqQOageF/7w6jDzF8C+E8oqeJG+PadPEPm0DVPM2ce/VYo/+BNT2ru+V/1ktifexQ5jUj6QdniWG q2JlO0qmHTHORSnMxFp7HXuZHPpsBf23RW2sbGYMCYSehPl8n4lt7Xg/FUwXa4ypIr9qxrczmYtm xrIQvYp4O+skNbtJ/Le2VETqWG0lfVJXL7/PvHZytirng1ViGs8H8oArhrGiGemjT58mlttU7H+V WM/2r47LEKKEOw1/9eLz5HBnKLi3CsravPM3+owhxNDJvySeRuCfreC/yWfX/lO9kKI9wtQTniDj agRLk8KSZ/11NEhrXEHZzbMNHTpGmPPayHIy0A7Iucs0l0tojekppqD9k0aJKx2EStlVw/KXtZ6R 1r6iHxJtqnUqUeyl0xrFaI2/MnpEXM9HaZUnlq0cY1o4GwujTcisbDq2hOtIbHJcUYVrs6DXRke4 7lw6OZwZCs4fsId4p6qU4cmcsYXv9bPHyeGvUPB/Ikg6k53VyqyV1j+Eu4WzyzCXJK+IkhrJS0qw BSNnokHpyTj9U3GC7bjikJixJpl3Klu4Rnqq5yeTY4oqTH9+inqaruDcTd97g3uOzbIiScU402/B v0agz1HQF2tkuZWH4xJD1F1JxMDTVCO4FjGukDaPdxQmOHlH3Tp6j6k1RowxUwvNMtOZ38alGNJa pRSdI36EeTavlsIKX2OzvwP9Cwzd/W6ALTrJthRlDI3RnlTQbbkO448RpE807p0OxX2c/7ufNigf cyJAo17WrqB/S6N9K9/3Egy3xY0vMV6rNibzVoVjk05zgPoQA5z1qYwhjcCVM/tC7QWem/wfdrSy 7UdYKu2ufBrz6qTC8hmpU/5kRPqbXL83AnOxgnmMt8Un+gAlrGx8ppKP3C2Q2vC8u16WMRWOVmlD fKQmv3SZpjTR0qCVqixOe5KjqffdDFEccTXQuBcsVvA3SIlN8DVOGGOVMyM52OLqOa5kl2xQX0sd 7BrxOfF3P9IfkyDnpJlctoC0lLDKKijfjCI11TT4S2+/UFcZEHFAl8yAhKYtUC6q+nlrg9odTf9V uQNKearzL0D/n696+/+s8mNPH7tj+ezkrV+IwIeWvf3gGmwLVrXdgR0/ocndYpLZKEi50Vkbyf0A yKPpB0AeYx+CyjOCMZD70U+A3MU+CvKMgP5xjvR7HOS+/Uv4I+saB3lmQP+hQPp7s+qsgOjYmuso DRQtK2f0pfO7JT2blsuS8gQqA6r069lfrpgeYTroqlfOS0qeiM7qXRRqV5k4kfS/7Z3PSgJRFMZP hrsg2xS0KKMQpRSzKFeBORZuSjDXYjlFYBlaq2jRpl2L1r1Bb9CuN+gh2kTraBd1vvtnsBprlDbC +cnk1Tsz1zkzUc75zncdd7921jiNOm778OA4cEYjHWi9r04fcEPo21sh1n3Ab6XtIxF9YqdMQDaa ML2otN26il/IdEXUweOg+a/n0Umjdup6cUc/zmW5cVh3ozuoE2t7J4eBy5I9J1GzzYrZ95p5jTau n2qp6FQ3K0XHuxpy/LzFyzlHJEsbtEwZ/l8+xzFNUp7fy3M7ye8sksN9SV5nifee4VaaHwVesN2q KrnO0Dq3L0gQBEEQBEEQBGGQeRtFqSruG1Ufbp5iKWj2XoeHaddHK2fVuYIgCIIgCIIgCIIgDBI2 h2rTrlB5IK2L/DW+7SNHj/yqqtsjna+Fwg5JbeR2Ua0GBRNy9LiHAD0W8vTI5WNeKKiQYFkHvaI1 XETed5p0TneGUMVFNGvWh5IFSWgUnUJXkuAF9yfmTX+Sn1MEE2btLKTUmaTnS0D/Oy8rpi38DWYX aipD7oKy92512GwHYZzCQ3ZfuIYi15f12+3HsasXuqP7xLPfNna+MJCnMx6z5ZmNV5TxeMtvM18m KeSN/9Gx399YwA9TVhmmsrJ6PyJtpO8/p0J34koBZe2Ug40PVeHchG6XlJk6jrjkGcpHyeH2nvpc Oi7diStllP7dDTo+gB4GhH+M1Vs8sn3EH+oXG///oNfx/5tBHv8TUEsBAhQAFAAAAAgAD06EKdIV CQyeGAAAAHAAACIAAAAAAAAAAAAgALaBAAAAAFJveV9TSVBfSC4zMjNfSW50X1JlcXJtdHNfRGVj My5wcHRQSwUGAAAAAAEAAQBQAAAA3hgAAAAA ------_=_NextPart_000_01C06469.AA30EA50-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 12 14:05:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22001 for ; Tue, 12 Dec 2000 14:05:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1591D4434B; Tue, 12 Dec 2000 13:05:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from awacs.vtel.com (vnat-096-aus.vtel.com [192.246.191.96]) by lists.bell-labs.com (Postfix) with ESMTP id 9ED5744339 for ; Tue, 12 Dec 2000 13:04:53 -0500 (EST) Received: from ausexch01.vtel.com (ausexch01 [10.10.1.4]) by awacs.vtel.com (8.10.2/8.10.2) with ESMTP id eBCJ4X907189; Tue, 12 Dec 2000 13:04:33 -0600 (CST) Received: by ausexch01.vtel.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 13:04:33 -0600 Message-ID: From: Joon Maeng To: "'sip-h323@egroups.com'" , dean.willis@softarmor.com, brian.rosen@marconi.com Cc: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] RE: [sip-h323] SIP-H.323 Presentation VGs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 12 Dec 2000 13:04:22 -0600 Alan made the presentation about an hour ago and there were no comments. We can proceed with what we presented in the slides (revise it in January and make a final call). Thanks Alan. Regards, Joon > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: Tuesday, December 12, 2000 12:31 PM > To: dean.willis@softarmor.com; brian.rosen@marconi.com; > sip-h323@egroups.com > Cc: sip@lists.bell-labs.com > Subject: [sip-h323] SIP-H.323 Presentation VGs > > > Folks, > > I am enclosing the VGs of the SIP-H.323 Interworking > presentation. Alan > Johnston will be presenting this as I am away for vacation. > > Best regards, > Radhika R. Roy > AT&T > > > > -------------------------- eGroups Sponsor > -------------------------~-~> > eLerts > It's Easy. It's Fun. Best of All, it's Free! > http://click.egroups.com/1/9699/0/_/302437/_/976645878/ > -------------------------------------------------------------- > -------_-> > > To Post a message, send it to: sip-h323@eGroups.com > > To Unsubscribe, send a blank message to: > sip-h323-unsubscribe@eGroups.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 12 21:58:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18164 for ; Tue, 12 Dec 2000 21:58:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B1ECE44337; Tue, 12 Dec 2000 20:58:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D3B6D44336 for ; Tue, 12 Dec 2000 20:57:40 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA19640; Tue, 12 Dec 2000 22:00:05 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 12 Dec 2000 21:55:15 -0500 Message-ID: From: Jonathan Rosenberg To: "'sip@lists.bell-labs.com'" , "'impp@iastate.edu'" , "'sip-events@egroups.com'" , "'confctrl@isi.edu'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP for Presence Mailing List Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 12 Dec 2000 21:55:06 -0500 Folks, We've set up a mailing list for the SIP for Presence group (SIMPLE) that met today at IETF: Post message: ietf-simple@egroups.com Subscribe: ietf-simple-subscribe@egroups.com Unsubscribe: ietf-simple-unsubscribe@egroups.com List owner: ietf-simple-owner@egroups.com URL to this page: http://www.egroups.com/group/ietf-simple I'd encourage everyone to subscribe. Thanks, Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 12 23:41:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA01285 for ; Tue, 12 Dec 2000 23:41:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C0EBB4433C; Tue, 12 Dec 2000 22:41:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4BAC844336 for ; Tue, 12 Dec 2000 22:40:46 -0500 (EST) Received: from dynamicsoft.com (1Cust22.tnt2.dub2.ie.uudial.net [213.116.42.22] (may be forged)) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA20075; Tue, 12 Dec 2000 23:42:50 -0500 (EST) Message-ID: <3A36FD9A.E5541986@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: jainsip@sun.com, jain_community@sun.com, discussion@sipforum.org, jainteam@sun.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] New forum for JAIN SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 13 Dec 2000 04:39:54 +0000 Content-Transfer-Encoding: 7bit Dear SIP Community, Until now the only forum available for discussing the JAIN SIP Specification among the whole SIP Community was the SIP WG alias. Of course this has not been the ideal place, given the already vast number of emails daily. Those of you not interested in JAIN SIP have tolerated the extra mails and I appreciate it a lot, but I don't want to abuse the privilege indefinitely. So I have created an eGroup that will now become the place for such discussions. If you are in anyway interested in the progress of the JAIN SIP Specification I recommend subscribing to the group. I will also be posting the most recent versions of the JAIN SIP specification on this site before it gets to first public release on java.sun.com Main Page URL: http://www.egroups.com/group/jainsip Posting address: jainsip@egroups.com Regards, Chris Harris JAIN SIP Specification Lead _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 13 08:46:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10078 for ; Wed, 13 Dec 2000 08:46:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A3A1C44339; Wed, 13 Dec 2000 07:46:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from calxch01.clarent.com (64-60-54-195-cust.telepacific.net [64.60.54.195]) by lists.bell-labs.com (Postfix) with ESMTP id 2A98B44351 for ; Tue, 12 Dec 2000 12:27:05 -0500 (EST) Received: by CALXCH01 with Internet Mail Service (5.5.2653.19) id ; Tue, 12 Dec 2000 10:26:53 -0800 Received: from rwcjfmule01 (ietf.207.137.73.88.tx.verio.net [207.137.73.88]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WV1DCQ0M; Tue, 12 Dec 2000 10:24:33 -0800 Reply-To: From: "Jean-Francois Mule" To: , "'Alan Johnston'" Subject: [SIP] 1 quick editorial comment on draft-ietf-sip-call-flows-02.txt Message-ID: <002301c06468$afbc3f20$584989cf@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: <4.1.20001212100548.02464b90@imop.cisco.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 12 Dec 2000 10:23:54 -0800 Content-Transfer-Encoding: 7bit In the section "General Assumptions", the wording of the paragraphs seems to imply hard requirements on gws and proxies beyond these call flow examples: 1/ "No authentication of Gateways is shown, since it is *assumed* that:..." 2/ "Two types of Gateways are *described* in this document 3/ "Gateways provide tones (ringing, busy, etc) and announcements. ..." --- Suggestions: - It would be approprieate to add ... for the purpose of these examples... to those paragraphs (each of them). - Another suggestion would be to use *may* instead of will... , Something like: For the purpose of these call flow examples, it is assumed that no gateway authentication is required (Gateways *may* only accept calls routed ..., proxies *may* perform client authentication, etc.) or like: Gateways *may* provide tones (ringing, busy, etc) and announcements to the PSTN side based on SIP response messages, or may pass along audio in-band tones (ringing, busy tone, etc.) in an early media stream to the SIP side. I believe this goes along the comment Jonathan made at the meeting today to add a general disclaimer. Jean-Francois Clarent _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 13 08:48:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA10540 for ; Wed, 13 Dec 2000 08:48:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6C63C44342; Wed, 13 Dec 2000 07:46:33 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id 6190B44336 for ; Wed, 13 Dec 2000 03:05:18 -0500 (EST) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id OAA06052 for ; Wed, 13 Dec 2000 14:44:28 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA6FBB; Wed, 13 Dec 2000 14:33:05 +0000 Message-ID: <026c01c064e4$1c86eee0$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: "Robert Sparks" , References: Subject: Re: [SIP] Solving the REFER retransmit issue 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 13 Dec 2000 14:37:25 +0530 Content-Transfer-Encoding: 7bit Well, I go back to my suggestion(rather a question I posed for Rohan) of forwarding provisionals received for INVITES initiated by the UA that is processing the INVITE :-) instead of using an explicit SUBSCRIBE/NOTIFY mechanism. With this approach all the UA would do have to do is to forward any message that it receives in response to an INVITE it issued (after suitably modifying the callID/From and To fields to match the one for the REFER request which triggered this INVITE). Any UA that doesn't want to about what happened to a REFER request it issues could explicitely specify so using the Request-Disposition header (caller preferences). Any repercussions with this ? Venkatesh ----- Original Message ----- From: "Robert Sparks" To: Sent: Tuesday, December 12, 2000 11:23 PM Subject: [SIP] Solving the REFER retransmit issue > The presentation of status of REFER and the discussion of the > REFER timeout issue is at > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-cc-transfe > r-02.htm > > Rohan Mahy also proposed an optimization of 2 where the REFER > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > of the REFERed action would just happen and could be ignored/481'ed > if the the REFERing agent didn't care. > > Jonathan R. stated that 2) requires any agent accepting a REFER to > implement being an event server (must implement accepting and > managing subscriptions), and this is asking too much. > > Discussion? > > RjS > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 13 12:35:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17790 for ; Wed, 13 Dec 2000 12:35:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D317044337; Wed, 13 Dec 2000 11:35:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A3EA144336 for ; Wed, 13 Dec 2000 11:34:19 -0500 (EST) Received: from CINQUECENTO (ietf.207.137.73.73.tx.verio.net [207.137.73.73]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id MAA24057; Wed, 13 Dec 2000 12:35:51 -0500 (EST) From: "Robert Sparks" To: "Venkatesh Venkataramanan" , Subject: RE: [SIP] Solving the REFER retransmit issue 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.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 In-reply-to: <026c01c064e4$1c86eee0$0c47a8c0@wipro.com> Importance: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 13 Dec 2000 11:31:35 -0600 Content-Transfer-Encoding: 7bit The problem is that the REFER transaction itself will timeout if the referred action (INVITE for example) takes longer than the run of REFER retransmits to complete. RjS > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Venkatesh > Venkataramanan > Sent: Wednesday, December 13, 2000 3:07 AM > To: Robert Sparks; sip@lists.bell-labs.com > Subject: Re: [SIP] Solving the REFER retransmit issue > > > Well, I go back to my suggestion(rather a question I posed for Rohan) of > forwarding provisionals received for INVITES initiated by the UA that is > processing the INVITE :-) instead of using an explicit SUBSCRIBE/NOTIFY > mechanism. With this approach all the UA would do have to do is to forward > any message that it receives in response to an INVITE it issued (after > suitably modifying the callID/From and To fields to match the one for the > REFER request which triggered this INVITE). Any UA that doesn't want to > about what happened to a REFER request it issues could explicitely specify > so using the Request-Disposition header (caller preferences). > Any repercussions with this ? > Venkatesh > ----- Original Message ----- > From: "Robert Sparks" > To: > Sent: Tuesday, December 12, 2000 11:23 PM > Subject: [SIP] Solving the REFER retransmit issue > > > > The presentation of status of REFER and the discussion of the > > REFER timeout issue is at > > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip- cc-transfe > r-02.htm > > Rohan Mahy also proposed an optimization of 2 where the REFER > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > of the REFERed action would just happen and could be ignored/481'ed > if the the REFERing agent didn't care. > > Jonathan R. stated that 2) requires any agent accepting a REFER to > implement being an event server (must implement accepting and > managing subscriptions), and this is asking too much. > > Discussion? > > RjS > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 13 20:56:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA18687 for ; Wed, 13 Dec 2000 20:56:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 37E244433D; Wed, 13 Dec 2000 19:56:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from extmx.itri.org.tw (extmx.itri.org.tw [140.96.158.1]) by lists.bell-labs.com (Postfix) with ESMTP id 82D6B4433C for ; Wed, 13 Dec 2000 19:55:17 -0500 (EST) Received: from mail3.itri.org.tw (mail3.itri.org.tw [140.96.157.3]) by extmx.itri.org.tw (8.8.8/8.8.8) with ESMTP id JAA24977 for ; Thu, 14 Dec 2000 09:58:38 +0800 (CST) Received: from nti.itri.org.tw (nti.itri.org.tw [140.96.157.2]) by mail3.itri.org.tw (8.9.3+Sun/8.9.1) with ESMTP id JAA07343 for ; Thu, 14 Dec 2000 09:59:27 +0800 (CST) Received: from cclmail.ccl.itri.org.tw (cclmail.ccl.itri.org.tw [140.96.90.193]) by nti.itri.org.tw (8.8.8/8.8.8) with ESMTP id JAA20026 for ; Thu, 14 Dec 2000 09:39:44 +0800 (CST) Received: from spring ([140.96.102.174]) by cclmail.ccl.itri.org.tw (Lotus Domino Release 5.0.2a (Intl)) with SMTP id 2000121409401543:5569 ; Thu, 14 Dec 2000 09:40:15 +0800 Reply-To: From: "Acer" To: Message-ID: <000201c0656e$b42f71b0$ae66608c@ccl.itri.org.tw> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2377.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-MIMETrack: Itemize by SMTP Server on CCLMAIL/ITRI(Release 5.0.2a (Intl)|23 November 1999) at 2000/12/14 09:40:15 AM, Serialize by Router on CCLMAIL/ITRI(Release 5.0.2a (Intl)|23 November 1999) at 2000/12/14 09:41:36 AM, Serialize complete at 2000/12/14 09:41:36 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="big5" Subject: [SIP] What relationship between Call leg and CSeq header? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 14 Dec 2000 09:39:30 +0800 Content-Transfer-Encoding: 7bit Hi! Advanced: From the document: draft-ietf-sip-call-flow-01.txt section 3.1.1 wrote: User A --------INVITE--------> User B (step1) UserA <-------100 Trying------ User B (step2) From step1 to step, I think that Call-ID should not change, but the document wrote Call-ID from 12345600@here.com change to 12345601@here.com Is it correcnt? To make clear: What relationship is between call leg and CSeq header? A "call" life is defined when client send the first INVITE to the final response. (It would contain more than one transaction.) So, when the "call" create, it should use the same Call-ID except re-INVITE happen. Is this correct? Who can help me to make clear those points? Thanks ! Acer Hsu _1_0_0111_0010_11_000_10_0111_111_10_1_0_111_ Hsu, Hung-Chi - Call me "Acer"... Mailto:hchsu@itri.org.tw Tel : 886-3-5914494 Fax : 886-3-5820310 Internet Telecommunication Dept. K200 CCL/ITRI Bldg. 51, 195-11 Sec. 4, Chung Hsing Rd., Chutung, Hsinchu, Taiwan 310, R.O.C. _101_11000_1_0_101_00_1_010_001101_0101_111_11_ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 13 21:50:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA28898 for ; Wed, 13 Dec 2000 21:50:10 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 903F94433B; Wed, 13 Dec 2000 20:50:15 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from extmx.itri.org.tw (extmx.itri.org.tw [140.96.158.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6B0F944336 for ; Wed, 13 Dec 2000 20:49:27 -0500 (EST) Received: from mail3.itri.org.tw (mail3.itri.org.tw [140.96.157.3]) by extmx.itri.org.tw (8.8.8/8.8.8) with ESMTP id KAA16186 for ; Thu, 14 Dec 2000 10:52:46 +0800 (CST) Received: from nti.itri.org.tw (nti.itri.org.tw [140.96.157.2]) by mail3.itri.org.tw (8.9.3+Sun/8.9.1) with ESMTP id KAA09247 for ; Thu, 14 Dec 2000 10:53:41 +0800 (CST) Received: from galant.ccl.itri.org.tw (galant.ccl.itri.org.tw [140.96.102.150]) by nti.itri.org.tw (8.8.8/8.8.8) with ESMTP id KAA27762 for ; Thu, 14 Dec 2000 10:49:59 +0800 (CST) Received: by GALANT with Internet Mail Service (5.5.2650.21) id ; Thu, 14 Dec 2000 10:50:06 +0800 Message-ID: <6992543692AAD211BA1C0000F87AAA3041AB73@GALANT> From: =?big5?B?s1zCRbDyKGhjaHN1KQ==?= To: SIP@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06578.8C31750A" Subject: [SIP] What relationship between Call leg and CSeq header? Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 12 Dec 2000 10:11:53 +0800 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_01C06578.8C31750A Content-Type: text/plain; charset="big5" Hi! Each Advanced: From the document: draft-ietf-sip-call-flow-01.txt section 3.1.1 wrote: User A --------INVITE--------> User B (step1) UserA <-------100 Trying------ User B (step2) From step1 to step, I think that Call-ID should not change, but the document wrote Call-ID from 12345600@here.com change to 12345601@here.com Is it correcnt? To make clear: What relationship is between call leg and CSeq header? A "call" life is defined when client send the first INVITE to the final response. (It would contain more than one transaction.) So, when the "call" create, it should use the same Call-ID except re-INVITE happen. Is this correct? Who can help me to make clear those points? Thanks ! Acer Hsu _1_0_0111_0010_11_000_10_0111_111_10_1_0_111_ Hsu, Hung-Chi - Call me "Acer"... Mailto:hchsu@itri.org.tw Tel : 886-3-5914494 Fax : 886-3-5820310 Internet Telecommunication Dept. K200 CCL/ITRI Bldg. 51, 195-11 Sec. 4, Chung Hsing Rd., Chutung, Hsinchu, Taiwan 310, R.O.C. _101_11000_1_0_101_00_1_010_001101_0101_111_11_ ------_=_NextPart_001_01C06578.8C31750A Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable What relationship between Call leg and CSeq header?

Hi! Each Advanced:

     
      From = the document: draft-ietf-sip-call-flow-01.txt section 3.1.1 = wrote:

        User A   --------INVITE--------> User = B  (step1)
        UserA   <-------100 Trying------ User B = (step2)
       =20
        From step1 to step, I think that Call-ID should not = change, but the document wrote
         &nb= sp;     Call-ID from 12345600@here.com change to = 12345601@here.com

        Is it correcnt?

      To make = clear:

        What relationship is between call  leg and CSeq = header?
        A "call" life is defined  when  = client send the first INVITE to the final response.
        (It would contain more than one transaction.)
        So, when the "call" create, it should use the = same Call-ID except re-INVITE happen.

        Is this correct?

      &nbs= p; Who can help me to make clear = those points?

        Thanks !

Acer Hsu
_1_0_0111_0010_11_000_10_0111_111_10_1_0_111_
       Hsu, = Hung-Chi - Call me "Acer"...
           = ;   Mailto:hchsu@itri.org.tw
         Tel : 886-3-5914494 Fax : 886-3-5820310      =20
         Internet = Telecommunication Dept.
   = K200 = CCL/ITRI Bldg. 51, 195-11 Sec. 4, Chung Hsing = Rd.,
   = Chutung, = Hsinchu, Taiwan 310, R.O.C.
_101_11000_1_0_101_00_1_010_001101_0101_111_11_




------_=_NextPart_001_01C06578.8C31750A-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 00:02:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA06718 for ; Thu, 14 Dec 2000 00:02:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D95F4433B; Wed, 13 Dec 2000 23:02:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 220F944336 for ; Wed, 13 Dec 2000 23:01:57 -0500 (EST) Received: from athletics (ietf.207.137.73.58.tx.verio.net [207.137.73.58]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id AAA29471; Thu, 14 Dec 2000 00:04:21 -0500 (EST) From: "Steve Donovan" To: "Robert Sparks" , Subject: RE: [SIP] Solving the REFER retransmit issue 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.2416 (9.0.2910.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 13 Dec 2000 22:59:39 -0600 Content-Transfer-Encoding: 7bit It seems to me that we have another alternative that I believe has been presented previously and maybe prematurely dismissed. Part of the problem is that we have two state machines upon which to base new methods. One is modeled after the INVITE transaction and the other modeled after the BYE transaction. The first allows for indefinite wait periods before a final response. The second does not. Option number three from the SIP WG meeting was - "Use the current mechanism if the requested action completes within ~1/2 the UDP timer retransmission runout, otherwise use solution 2." This implies the creation of a REFER specific state machine, with the addition of sending something like a 202 final response if the real final response is not known. If we are entertaining adding a new state machine, why not add the one that solves the real problem and create a third transaction model that is a mix of the two existing models. This would be a request, response transaction that allows for indefinite wait periods between the request and the final response. I suspect the knee jerk reaction will be against this proposal. But before reacting, please consider the probability that the most viable solution that does not require a new state machine is mandating that user agents supporting REFER also implement SIP Events. This will likely either slow down the implementation of REFER or result in many clients that do not support it at all (something that would not be good). I would rather have the flexibility of a third transaction state machine model then to increase the complexity of user agents supporting REFER. Regards, Steve > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Robert Sparks > Sent: Tuesday, December 12, 2000 11:53 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Solving the REFER retransmit issue > > > The presentation of status of REFER and the discussion of the > REFER timeout issue is at > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip- > cc-transfe > r-02.htm > > Rohan Mahy also proposed an optimization of 2 where the REFER > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > of the REFERed action would just happen and could be ignored/481'ed > if the the REFERing agent didn't care. > > Jonathan R. stated that 2) requires any agent accepting a REFER to > implement being an event server (must implement accepting and > managing subscriptions), and this is asking too much. > > Discussion? > > RjS > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 00:38:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA21501 for ; Thu, 14 Dec 2000 00:38:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DBED044338; Wed, 13 Dec 2000 23:38:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 68E9F44336 for ; Wed, 13 Dec 2000 23:37:13 -0500 (EST) Received: from athletics (ietf.207.137.73.58.tx.verio.net [207.137.73.58]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id AAA29651; Thu, 14 Dec 2000 00:39:18 -0500 (EST) From: "Steve Donovan" To: , Subject: RE: [SIP] What relationship between Call leg and CSeq header? Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <000201c0656e$b42f71b0$ae66608c@ccl.itri.org.tw> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 13 Dec 2000 23:34:36 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Acer > Sent: Wednesday, December 13, 2000 7:40 PM > To: SIP@lists.bell-labs.com > Subject: [SIP] What relationship between Call leg and CSeq header? > > > Hi! Advanced: > > > > From the document: draft-ietf-sip-call-flow-01.txt section 3.1.1 > wrote: > > User A --------INVITE--------> User B (step1) > UserA <-------100 Trying------ User B (step2) > > From step1 to step, I think that Call-ID should not change, but the > document wrote > Call-ID from 12345600@here.com change to 12345601@here.com > > Is it correcnt? No, this is not correct. This is a good catch on your part. The document will need to be changed. > > To make clear: > > What relationship is between call leg and CSeq header? > A "call" life is defined when client send the first > INVITE to the final > response. > (It would contain more than one transaction.) > So, when the "call" create, it should use the same Call-ID except > re-INVITE happen. The call-id should remain the same for all transactions associated with that call. As such, it will remain the same between INVITEs and re-INVITEs (in addition to INFO, BYE and any other transactions associated with the call). The CSeq, however, will change for each transaction, including re-INVITEs. > > Is this correct? > > Who can help me to make clear those points? > > Thanks ! > > Acer Hsu > _1_0_0111_0010_11_000_10_0111_111_10_1_0_111_ > Hsu, Hung-Chi - Call me "Acer"... > Mailto:hchsu@itri.org.tw > Tel : 886-3-5914494 Fax : 886-3-5820310 > Internet Telecommunication Dept. > K200 CCL/ITRI Bldg. 51, 195-11 Sec. 4, Chung Hsing Rd., > Chutung, Hsinchu, Taiwan 310, R.O.C. > _101_11000_1_0_101_00_1_010_001101_0101_111_11_ > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 05:29:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA21701 for ; Thu, 14 Dec 2000 05:29:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D63B644338; Thu, 14 Dec 2000 04:29:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from chiara.dei.unipd.it (chiara.dei.unipd.it [147.162.2.19]) by lists.bell-labs.com (Postfix) with ESMTP id 0915744336 for ; Thu, 14 Dec 2000 04:28:45 -0500 (EST) Received: by chiara.dei.unipd.it (Postfix, from userid 1935) id E4DF843F1B; Thu, 14 Dec 2000 11:29:44 +0100 (CET) Delivered-To: gremlin@mail.sctrade.it Received: from kara.sctrade.it by localhost with POP3 (fetchmail-5.3.3) for gremlin@localhost (single-drop); Thu, 14 Dec 2000 11:29:44 +0100 (CET) Received: from smtp.wineasy.se (smtp.wineasy.se [195.42.198.20]) by mail.sctrade.it (Postfix on SuSE Linux 7.0 (i386)) with ESMTP id 9BB5011376 for ; Wed, 13 Dec 2000 06:38:12 +0100 (CET) Received: from listserver.wineasy.se (listserver.wineasy.se [195.42.198.161]) by smtp.wineasy.se with ESMTP id eBD4gjC06515; Wed, 13 Dec 2000 05:42:45 +0100 Received: from localhost (daemon@localhost) by listserver.wineasy.se (8.9.3/8.9.3) with SMTP id FAA02195; Wed, 13 Dec 2000 05:42:44 +0100 Received: by listserver.wineasy.se (bulk_mailer v1.12); Wed, 13 Dec 2000 05:40:42 +0100 Received: (from majordomo@localhost) by listserver.wineasy.se (8.9.3/8.9.3) id FAA02123 for discussion-outgoing; Wed, 13 Dec 2000 05:40:42 +0100 Message-ID: <3A36FD9A.E5541986@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Cc: jainsip@sun.com, jain_community@sun.com, discussion@sipforum.org, jainteam@sun.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: discussion@sipforum.org X-UIDL: 7569a172c645f2adb79eaeffa4465314 Status: RO Subject: [SIP] [SIPFORUM] New forum for JAIN SIP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 13 Dec 2000 04:39:54 +0000 Content-Transfer-Encoding: 7bit Dear SIP Community, Until now the only forum available for discussing the JAIN SIP Specification among the whole SIP Community was the SIP WG alias. Of course this has not been the ideal place, given the already vast number of emails daily. Those of you not interested in JAIN SIP have tolerated the extra mails and I appreciate it a lot, but I don't want to abuse the privilege indefinitely. So I have created an eGroup that will now become the place for such discussions. If you are in anyway interested in the progress of the JAIN SIP Specification I recommend subscribing to the group. I will also be posting the most recent versions of the JAIN SIP specification on this site before it gets to first public release on java.sun.com Main Page URL: http://www.egroups.com/group/jainsip Posting address: jainsip@egroups.com Regards, Chris Harris JAIN SIP Specification Lead _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 08:25:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18474 for ; Thu, 14 Dec 2000 08:25:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D0E5344338; Thu, 14 Dec 2000 07:25:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id C275D44336 for ; Wed, 13 Dec 2000 23:50:02 -0500 (EST) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id LAA17314 for ; Thu, 14 Dec 2000 11:29:14 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA6240; Thu, 14 Dec 2000 11:19:46 +0000 Message-ID: <00d401c06592$3e4ae460$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: "Robert Sparks" , , "Venkatesh Venkataramanan" Cc: References: Subject: Re: [SIP] Solving the REFER retransmit issue 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 14 Dec 2000 11:23:54 +0530 Content-Transfer-Encoding: 7bit Steve: I was essentially suggesting the same thing to Robert Spark in an email I sent him earlier today except that I missed out mentioning that we don't need the "ACK" for the final response received for a REFER !! Venkatesh ----- Original Message ----- From: "Robert Sparks" To: "Venkatesh Venkataramanan" Sent: Thursday, December 14, 2000 10:22 AM Subject: RE: [SIP] Solving the REFER retransmit issue > This has been brought up before and was not well received. Why do you > need a three phase transaction for this? Do we want to introduce a > whole new state machine to do the first two phases of invite without > the third? > > The opinions I have been hearing to date are to try _very_ hard to > find a solution that worked within the existing non-INVITE transaction > model. If a good solution can't be found within that constraint, then > we start discussing the other options. > > > -----Original Message----- > > From: Venkatesh Venkataramanan > > [mailto:Venkatesh.Venkataramanan@sylantro.com] > > Sent: Wednesday, December 13, 2000 10:10 PM > > To: 'Robert Sparks ' > > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > > > Robert: > > I am probably missing out something here. Let me try to explain what I was > > proposing and get your thoughts on this one. > > Instead of processing REFER like a BYE request, we should modify the REFER > > to be processed like an INVITE. The rationale being if REFER is being used > > for initiating "requests" to make calls and the initiator of the > > call wants > > to see "call progress", REFER is "like" a 3pcc INVITE. > > Use provisionals received by the Invoker of INVITE to be forwarded to the > > initiator of REFER. The arrival of a provisional stops the timer > > (as we have > > now modified REFER to be processed like an INVITE). > > Venkatesh > > > > -----Original Message----- > > From: Robert Sparks > > To: Venkatesh Venkataramanan; sip@lists.bell-labs.com > > Sent: 12/13/00 9:31 AM > > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > The problem is that the REFER transaction itself will timeout > > if the referred action (INVITE for example) takes longer than > > the run of REFER retransmits to complete. > > > > RjS > > > > > -----Original Message----- > > > From: sip-admin@lists.bell-labs.com > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Venkatesh > > > Venkataramanan > > > Sent: Wednesday, December 13, 2000 3:07 AM > > > To: Robert Sparks; sip@lists.bell-labs.com > > > Subject: Re: [SIP] Solving the REFER retransmit issue > > > > > > > > > Well, I go back to my suggestion(rather a question I posed for Rohan) > > of > > > forwarding provisionals received for INVITES initiated by the UA that > > is > > > processing the INVITE :-) instead of using an explicit > > SUBSCRIBE/NOTIFY > > > mechanism. With this approach all the UA would do have to do is to > > forward > > > any message that it receives in response to an INVITE it issued (after > > > suitably modifying the callID/From and To fields to match the one for > > the > > > REFER request which triggered this INVITE). Any UA that doesn't want > > to > > > about what happened to a REFER request it issues could explicitely > > specify > > > so using the Request-Disposition header (caller preferences). > > > Any repercussions with this ? > > > Venkatesh > > > ----- Original Message ----- > > > From: "Robert Sparks" > > > To: > > > Sent: Tuesday, December 12, 2000 11:23 PM > > > Subject: [SIP] Solving the REFER retransmit issue > > > > > > > > > > The presentation of status of REFER and the discussion of the > > > > REFER timeout issue is at > > > > > > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip- > > cc-transfe > > > r-02.htm > > > > > > Rohan Mahy also proposed an optimization of 2 where the REFER > > > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > > > of the REFERed action would just happen and could be ignored/481'ed > > > if the the REFERing agent didn't care. > > > > > > Jonathan R. stated that 2) requires any agent accepting a REFER to > > > implement being an event server (must implement accepting and > > > managing subscriptions), and this is asking too much. > > > > > > Discussion? > > > > > > RjS > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 08:26:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18795 for ; Thu, 14 Dec 2000 08:26:38 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9C3D84434E; Thu, 14 Dec 2000 07:25:34 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id 3C6E944336 for ; Wed, 13 Dec 2000 23:59:20 -0500 (EST) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id LAA18716 for ; Thu, 14 Dec 2000 11:38:32 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA307; Thu, 14 Dec 2000 11:29:02 +0000 Message-ID: <00e901c06593$89aa2140$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: "Steve Donovan" , "Robert Sparks" , Cc: "Venkatesh Venkataramanan" References: Subject: Re: [SIP] Solving the REFER retransmit issue 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 14 Dec 2000 11:33:09 +0530 Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Steve Donovan" To: "Robert Sparks" ; Sent: Thursday, December 14, 2000 10:29 AM Subject: RE: [SIP] Solving the REFER retransmit issue > It seems to me that we have another alternative that I believe has been > presented previously and maybe prematurely dismissed. > > Part of the problem is that we have two state machines upon which to base > new methods. One is modeled after the INVITE transaction and the other > modeled after the BYE transaction. The first allows for indefinite wait > periods before a final response. The second does not. > > Option number three from the SIP WG meeting was - > > "Use the current mechanism if the requested action completes within ~1/2 the > UDP timer retransmission runout, otherwise use solution 2." > > This implies the creation of a REFER specific state machine, with the > addition of sending something like a 202 final response if the real final > response is not known. > > If we are entertaining adding a new state machine, why not add the one that > solves the real problem and create a third transaction model that is a mix > of the two existing models. This would be a request, response transaction > that allows for indefinite wait periods between the request and the final > response. If I interpret this correctly, this new state machine removes any timer restrictions for receiving a final response. The retransmission of the REFER continues until the final response is received to ensure reliability of the final response? > > I suspect the knee jerk reaction will be against this proposal. But before > reacting, please consider the probability that the most viable solution that > does not require a new state machine is mandating that user agents > supporting REFER also implement SIP Events. This will likely either slow > down the implementation of REFER or result in many clients that do not > support it at all (something that would not be good). > > I would rather have the flexibility of a third transaction state machine > model then to increase the complexity of user agents supporting REFER. > > Regards, > > Steve > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Robert Sparks > > Sent: Tuesday, December 12, 2000 11:53 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Solving the REFER retransmit issue > > > > > > The presentation of status of REFER and the discussion of the > > REFER timeout issue is at > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip- > > cc-transfe > > r-02.htm > > > > Rohan Mahy also proposed an optimization of 2 where the REFER > > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > > of the REFERed action would just happen and could be ignored/481'ed > > if the the REFERing agent didn't care. > > > > Jonathan R. stated that 2) requires any agent accepting a REFER to > > implement being an event server (must implement accepting and > > managing subscriptions), and this is asking too much. > > > > Discussion? > > > > RjS > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 12:07:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01849 for ; Thu, 14 Dec 2000 12:07:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0380244338; Thu, 14 Dec 2000 11:07:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 74D0444336 for ; Thu, 14 Dec 2000 11:06:51 -0500 (EST) Received: from CINQUECENTO (ietf.207.137.75.124.tx.verio.net [207.137.75.124]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id MAA02881; Thu, 14 Dec 2000 12:08:33 -0500 (EST) From: "Robert Sparks" To: "Venkatesh Venkataramanan" Cc: Subject: RE: [SIP] Solving the REFER retransmit issue 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.2416 (9.0.2910.0) In-Reply-To: <00d401c06592$3e4ae460$0c47a8c0@wipro.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 14 Dec 2000 11:04:13 -0600 Content-Transfer-Encoding: 7bit If we wanted to use the first two phases of invite, we must take the third (ACK) with it. The ACK provides recovery from a lost final response. RjS > -----Original Message----- > From: Venkatesh Venkataramanan > [mailto:venkatesh.venkataramanan@wipro.com] > Sent: Wednesday, December 13, 2000 11:54 PM > To: Robert Sparks; sdonovan@dynamicsoft.com; Venkatesh Venkataramanan > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Solving the REFER retransmit issue > > > Steve: > I was essentially suggesting the same thing to Robert Spark in an email I > sent him earlier today except that I missed out mentioning that we don't > need the "ACK" for the final response received for a REFER !! > Venkatesh > ----- Original Message ----- > From: "Robert Sparks" > To: "Venkatesh Venkataramanan" > Sent: Thursday, December 14, 2000 10:22 AM > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > This has been brought up before and was not well received. Why do you > > need a three phase transaction for this? Do we want to introduce a > > whole new state machine to do the first two phases of invite without > > the third? > > > > The opinions I have been hearing to date are to try _very_ hard to > > find a solution that worked within the existing non-INVITE transaction > > model. If a good solution can't be found within that constraint, then > > we start discussing the other options. > > > > > -----Original Message----- > > > From: Venkatesh Venkataramanan > > > [mailto:Venkatesh.Venkataramanan@sylantro.com] > > > Sent: Wednesday, December 13, 2000 10:10 PM > > > To: 'Robert Sparks ' > > > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > > > > > > Robert: > > > I am probably missing out something here. Let me try to explain what I > was > > > proposing and get your thoughts on this one. > > > Instead of processing REFER like a BYE request, we should modify the > REFER > > > to be processed like an INVITE. The rationale being if REFER is being > used > > > for initiating "requests" to make calls and the initiator of the > > > call wants > > > to see "call progress", REFER is "like" a 3pcc INVITE. > > > Use provisionals received by the Invoker of INVITE to be forwarded to > the > > > initiator of REFER. The arrival of a provisional stops the timer > > > (as we have > > > now modified REFER to be processed like an INVITE). > > > Venkatesh > > > > > > -----Original Message----- > > > From: Robert Sparks > > > To: Venkatesh Venkataramanan; sip@lists.bell-labs.com > > > Sent: 12/13/00 9:31 AM > > > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > > > The problem is that the REFER transaction itself will timeout > > > if the referred action (INVITE for example) takes longer than > > > the run of REFER retransmits to complete. > > > > > > RjS > > > > > > > -----Original Message----- > > > > From: sip-admin@lists.bell-labs.com > > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Venkatesh > > > > Venkataramanan > > > > Sent: Wednesday, December 13, 2000 3:07 AM > > > > To: Robert Sparks; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Solving the REFER retransmit issue > > > > > > > > > > > > Well, I go back to my suggestion(rather a question I posed > for Rohan) > > > of > > > > forwarding provisionals received for INVITES initiated by > the UA that > > > is > > > > processing the INVITE :-) instead of using an explicit > > > SUBSCRIBE/NOTIFY > > > > mechanism. With this approach all the UA would do have to do is to > > > forward > > > > any message that it receives in response to an INVITE it > issued (after > > > > suitably modifying the callID/From and To fields to match > the one for > > > the > > > > REFER request which triggered this INVITE). Any UA that doesn't want > > > to > > > > about what happened to a REFER request it issues could explicitely > > > specify > > > > so using the Request-Disposition header (caller preferences). > > > > Any repercussions with this ? > > > > Venkatesh > > > > ----- Original Message ----- > > > > From: "Robert Sparks" > > > > To: > > > > Sent: Tuesday, December 12, 2000 11:23 PM > > > > Subject: [SIP] Solving the REFER retransmit issue > > > > > > > > > > > > > The presentation of status of REFER and the discussion of the > > > > > REFER timeout issue is at > > > > > > > > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip- > > > cc-transfe > > > > r-02.htm > > > > > > > > Rohan Mahy also proposed an optimization of 2 where the REFER > > > > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > > > > of the REFERed action would just happen and could be ignored/481'ed > > > > if the the REFERing agent didn't care. > > > > > > > > Jonathan R. stated that 2) requires any agent accepting a REFER to > > > > implement being an event server (must implement accepting and > > > > managing subscriptions), and this is asking too much. > > > > > > > > Discussion? > > > > > > > > RjS > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 12:10:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02297 for ; Thu, 14 Dec 2000 12:10:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9307544341; Thu, 14 Dec 2000 11:10:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D4BCD44351 for ; Thu, 14 Dec 2000 11:09:02 -0500 (EST) Received: from athletics (ietf.207.137.75.142.tx.verio.net [207.137.75.142]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id MAA02901; Thu, 14 Dec 2000 12:11:13 -0500 (EST) From: "Steve Donovan" To: "Venkatesh Venkataramanan" , "Robert Sparks" , Subject: RE: [SIP] Solving the REFER retransmit issue 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.2416 (9.0.2910.0) In-Reply-To: <00e901c06593$89aa2140$0c47a8c0@wipro.com> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 14 Dec 2000 11:06:42 -0600 Content-Transfer-Encoding: 7bit > > If we are entertaining adding a new state machine, why not add the one > that > > solves the real problem and create a third transaction model > that is a mix > > of the two existing models. This would be a request, response > transaction > > that allows for indefinite wait periods between the request and > the final > > response. > > If I interpret this correctly, this new state machine removes any timer > restrictions for receiving a final response. The retransmission > of the REFER > continues until the final response is received to ensure > reliability of the > final response? > Yes, this is the wart associated with this solution. If we do away with the ACK as a method of confirming receipt of the final response then we need to periodically retry the request. This would need to be done frequently enough that the UAS will receive it before it deletes the transaction. This would likely be every 16 seconds. The solution to this would be to use the INVITE transaction model and have an ACK to the final response to a REFER request. --- Steven R. Donovan Architect dynamicsoft mailto:sdonovan@dynamicsoft.com 5100 Tennyson Parkway sip:sdonovan@sip.dynamicsoft.com Plano, Texas 75025 tel:+1-972-473-5469 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 12:14:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA02783 for ; Thu, 14 Dec 2000 12:14:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A96E544354; Thu, 14 Dec 2000 11:14:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id ED7F344353 for ; Thu, 14 Dec 2000 11:13:24 -0500 (EST) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eBEHDEG04856; Thu, 14 Dec 2000 18:13:14 +0100 (MET) Received: from lmf.ericsson.se (EWUpcp003371pcs.sd.us.am.ericsson.se [142.133.141.80]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id SAA12428; Thu, 14 Dec 2000 18:13:10 +0100 (MET) Message-ID: <3A38FFCB.1F199531@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Steve Donovan Cc: Robert Sparks , sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 14 Dec 2000 19:13:47 +0200 Content-Transfer-Encoding: 7bit Hello, If we go for the immediate complexion of the REFER transaction, a UA implementing REFER but not SUBSCRIBE/NOTIFY can still make blind transfer (the UA will not be aware of the result of the REFER). Thus, it works for simple implementations. They can get the basic service. If you want a more advanced implementation, you will have to implement SUBSCRIBE/NOTIFY to get a report of the result of the REFER. If we go for a third state machine, we have to update all the SIP server in order to uderstand REFER. I do not like this idea. I would argue that if you want to create a new state machine for REFER, there will be folks that want to create a new state machine for PRACK (no 200 OK), and so on... I would go for the first solucion: The REFER transaction is finished as soon as possible and the status report is sent using NOTIFY. Regards, Gonzalo Steve Donovan wrote: > > It seems to me that we have another alternative that I believe has been > presented previously and maybe prematurely dismissed. > > Part of the problem is that we have two state machines upon which to base > new methods. One is modeled after the INVITE transaction and the other > modeled after the BYE transaction. The first allows for indefinite wait > periods before a final response. The second does not. > > Option number three from the SIP WG meeting was - > > "Use the current mechanism if the requested action completes within ~1/2 the > UDP timer retransmission runout, otherwise use solution 2." > > This implies the creation of a REFER specific state machine, with the > addition of sending something like a 202 final response if the real final > response is not known. > > If we are entertaining adding a new state machine, why not add the one that > solves the real problem and create a third transaction model that is a mix > of the two existing models. This would be a request, response transaction > that allows for indefinite wait periods between the request and the final > response. > > I suspect the knee jerk reaction will be against this proposal. But before > reacting, please consider the probability that the most viable solution that > does not require a new state machine is mandating that user agents > supporting REFER also implement SIP Events. This will likely either slow > down the implementation of REFER or result in many clients that do not > support it at all (something that would not be good). > > I would rather have the flexibility of a third transaction state machine > model then to increase the complexity of user agents supporting REFER. > > Regards, > > Steve > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Robert Sparks > > Sent: Tuesday, December 12, 2000 11:53 AM > > To: sip@lists.bell-labs.com > > Subject: [SIP] Solving the REFER retransmit issue > > > > > > The presentation of status of REFER and the discussion of the > > REFER timeout issue is at > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip- > > cc-transfe > > r-02.htm > > > > Rohan Mahy also proposed an optimization of 2 where the REFER > > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > > of the REFERed action would just happen and could be ignored/481'ed > > if the the REFERing agent didn't care. > > > > Jonathan R. stated that 2) requires any agent accepting a REFER to > > implement being an event server (must implement accepting and > > managing subscriptions), and this is asking too much. > > > > Discussion? > > > > RjS > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 12:35:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05282 for ; Thu, 14 Dec 2000 12:35:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9C31044338; Thu, 14 Dec 2000 11:35:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 4801844336 for ; Thu, 14 Dec 2000 11:34:04 -0500 (EST) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eBEHXsG15552; Thu, 14 Dec 2000 18:33:54 +0100 (MET) Received: from lmf.ericsson.se (EWUpcp003371pcs.sd.us.am.ericsson.se [142.133.141.80]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id SAA14705; Thu, 14 Dec 2000 18:33:51 +0100 (MET) Message-ID: <3A3904A4.53AC7AD1@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Robert Sparks , sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] Changin local RTP port without a good reason Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 14 Dec 2000 19:34:28 +0200 Content-Transfer-Encoding: 7bit Hello, The issue of implementations changing local RTP ports upone reception of a re-INVITE has great importance. It has influence is some of the drafts that are currently out there (such as 3pcc). A SIP implementation would not have to change the local RTP port when a re-INVITE changing the remote RTP port arrives. However, it seems that some frameworks (such as Java) change it. A SIP UA using this media framework does not have control over this change. I would like to fully understand the problem. I have a question: How can these implementations re-INVITE? I change my local RTP port and re-INVITE. I will receive a 200 OK with an updated remote RTP port. Since I cannot change the the remote RTP port without changing my local RTP port, I will have to send an updated SDP in the ACK... is this correct? Thanks, Gonzalo -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 12:53:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA07581 for ; Thu, 14 Dec 2000 12:53:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5BDC344351; Thu, 14 Dec 2000 11:53:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3C3F744344 for ; Thu, 14 Dec 2000 11:52:43 -0500 (EST) Received: from CINQUECENTO (ietf.207.137.75.124.tx.verio.net [207.137.75.124]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id MAA03408; Thu, 14 Dec 2000 12:55:03 -0500 (EST) From: "Robert Sparks" To: "Gonzalo Camarillo" , "Steve Donovan" Cc: Subject: RE: [SIP] Solving the REFER retransmit issue Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A38FFCB.1F199531@lmf.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 14 Dec 2000 11:50:44 -0600 Content-Transfer-Encoding: 7bit > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Gonzalo Camarillo > Hello, > > If we go for the immediate complexion of the REFER transaction, a UA > implementing REFER but not SUBSCRIBE/NOTIFY can still make blind > transfer (the UA will not be aware of the result of the REFER). Thus, it > works for simple implementations. They can get the basic service. Since you say the UA will not be aware of the result of the REFER, I assume you are talking about the UA that issued the REFER. What about the UA that receives and responds to the REFER? What breaks if we go with option 2) from the slide and this UA chooses not to implement SUBSCRIBE/NOTIFY? Certainly any application that relies on getting the final result of the referred action back to the referror. Does the referror need know ahead of time that there's no way to get this information so that it doesn't offer those applications? If so, can that need be met using Require:? RjS _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 13:35:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA12632 for ; Thu, 14 Dec 2000 13:35:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 09F8F44338; Thu, 14 Dec 2000 12:35:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3C78144336 for ; Thu, 14 Dec 2000 12:34:26 -0500 (EST) Received: from CINQUECENTO (ietf.207.137.75.124.tx.verio.net [207.137.75.124]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id NAA03927; Thu, 14 Dec 2000 13:36:32 -0500 (EST) From: "Robert Sparks" To: "Gonzalo Camarillo" , "sip" Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <3A3904A4.53AC7AD1@lmf.ericsson.se> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [SIP] RE: Changin local RTP port without a good reason Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 14 Dec 2000 12:32:12 -0600 Content-Transfer-Encoding: 7bit > Hello, > > The issue of implementations changing local RTP ports upone reception of > a re-INVITE has great importance. It has influence is some of the drafts > that are currently out there (such as 3pcc). > > A SIP implementation would not have to change the local RTP port when a > re-INVITE changing the remote RTP port arrives. However, it seems that > some frameworks (such as Java) change it. A SIP UA using this media > framework does not have control over this change. > > I would like to fully understand the problem. I have a question: > > How can these implementations re-INVITE? > I change my local RTP port and re-INVITE. I will receive a 200 OK with > an updated remote RTP port. > Since I cannot change the the remote RTP > port without changing my local RTP port, I'm not aware of any applications that have run into that particular problem. > I will have to send an updated > SDP in the ACK... is this correct? The problem that early users of JMF ran into was being able to change codecs (this was one of the major motiviations for reINVITE yes?) in the object that was receiving/rendering media and keep the same local port. I have heard that this has been addressed in more recent versions of the JMF. Someone speak up if this is not true or if they still have this kind of problem in another environment. Even if this has been addressed, I'm uncomfortable with the idea that an implementation should be forced to keep the same local port across reinvites. Do I have to do this if I'm fundamentally changing media types? What if I'm adding/removing media lines? This was why we have a full-state reINVITE and not a HOLD method yes? RjS _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 16:14:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18319 for ; Thu, 14 Dec 2000 16:14:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A44A24433D; Thu, 14 Dec 2000 15:14:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail15b.boca15-verio.com (unknown [208.55.91.59]) by lists.bell-labs.com (Postfix) with SMTP id 09BB744336 for ; Thu, 14 Dec 2000 15:13:46 -0500 (EST) Received: from www.snowshore.com (128.241.144.247) by mail15b.boca15-verio.com (RS ver 1.0.58s) with SMTP id 07636097; Thu, 14 Dec 2000 16:13:18 -0500 (EST) From: "Eric Burger" To: "sip" Cc: "Robert Sparks" , "Gonzalo Camarillo" Subject: RE: [SIP] RE: Changin local RTP port without a good reason 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.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 In-Reply-To: X-Loop-Detect: 1 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 14 Dec 2000 16:13:08 -0500 Content-Transfer-Encoding: 7bit Agreed. The "alternate codec" may be physically somewhere else. > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Robert Sparks > Sent: Thursday, December 14, 2000 1:32 PM > To: Gonzalo Camarillo; sip > Subject: [SIP] RE: Changin local RTP port without a good reason [snip] > Even if this has been addressed, I'm uncomfortable with the idea that > an implementation should be forced to keep the same local port across > reinvites. Do I have to do this if I'm fundamentally changing media > types? What if I'm adding/removing media lines? This was why we have > a full-state reINVITE and not a HOLD method yes? _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 19:04:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA25035 for ; Thu, 14 Dec 2000 19:04:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A987D4433D; Thu, 14 Dec 2000 18:04:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id A213F44336 for ; Thu, 14 Dec 2000 18:03:44 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 713011E05F for ; Thu, 14 Dec 2000 19:03:35 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id TAA14743 for ; Thu, 14 Dec 2000 19:03:34 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id TAA91443 for sip@lists.bell-labs.com; Thu, 14 Dec 2000 19:04:05 -0500 (EST) Message-Id: <200012150004.TAA91443@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 14 Dec 2000 19:04:05 -0500 (EST) I think there is a definite simplification possible here, if the three-phase-procedure can be dissaciated with INVITE. That is, to allow the three-phase-procedure for all methods. SIP defined two mechanisms for retransmission/reliability. One (currently used for INVITE) involves a three-way handshake (INVITE, 200-OK, ACK); and the other (currently used for all other methods) is a two-way handshake (INVITE, 200-OK). The major difference, in my opinion, is that the three-way handshake allows a provisional response, which is not allowed for such methods as BYE, INFO, SUBSCRIBE, REGISTER, etc (even though it might be useful). I think the changes are relatively simple. All are currently implemented in the handling of INVITE, and just need to be made non-INVITE-specific. UAC/UAS behavior changes: (1) A UAC that receives a 1xx response to any method, MUST send an ACK when it receives a final response. (2) A UAS MUST send a response within some short time limit of receiving a request, either a final response or a provisional response. (3) If a UAS sends a provisional response, it MUST re-transmit any final response until receiving an ACK. Proxy behavior changes: (1) A Proxy MUST forward an ACK to the UAS, regardless of original request. (2) Proxy MUST forward a 100 provisional responses back to the UAC, except when the proxy generated its own 100 response for the same request. REFER, of course, is the first example of a method that could use the three-way-handshake other than INVITE. The only reason the situation didn't arise before (with the Also/Replaces version of call control) because they were headers added to an INVITE method. The main issue is whether this is toooo incompatible with RFC2543. Proxy point (2) is the only point that is not backwards compatible with existing devices that conform to RFC2543 and that handle only existing methods. Would this involve significant implementation changes in UAs? Regardless, I think the contortions needed for REFER are more complex. Bill Marshall wtm@research.att.com -----original message----- From: "Robert Sparks" To: "Venkatesh Venkataramanan" Cc: Subject: RE: [SIP] Solving the REFER retransmit issue Date: Thu, 14 Dec 2000 11:04:13 -0600 If we wanted to use the first two phases of invite, we must take the third (ACK) with it. The ACK provides recovery from a lost final response. RjS > -----Original Message----- > From: Venkatesh Venkataramanan > [mailto:venkatesh.venkataramanan@wipro.com] > Sent: Wednesday, December 13, 2000 11:54 PM > To: Robert Sparks; sdonovan@dynamicsoft.com; Venkatesh Venkataramanan > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Solving the REFER retransmit issue > > > Steve: > I was essentially suggesting the same thing to Robert Spark in an email I > sent him earlier today except that I missed out mentioning that we don't > need the "ACK" for the final response received for a REFER !! > Venkatesh > ----- Original Message ----- > From: "Robert Sparks" > To: "Venkatesh Venkataramanan" > Sent: Thursday, December 14, 2000 10:22 AM > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > This has been brought up before and was not well received. Why do you > > need a three phase transaction for this? Do we want to introduce a > > whole new state machine to do the first two phases of invite without > > the third? > > > > The opinions I have been hearing to date are to try _very_ hard to > > find a solution that worked within the existing non-INVITE transaction > > model. If a good solution can't be found within that constraint, then > > we start discussing the other options. > > > > > -----Original Message----- > > > From: Venkatesh Venkataramanan > > > [mailto:Venkatesh.Venkataramanan@sylantro.com] > > > Sent: Wednesday, December 13, 2000 10:10 PM > > > To: 'Robert Sparks ' > > > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > > > > > > Robert: > > > I am probably missing out something here. Let me try to explain what I > was > > > proposing and get your thoughts on this one. > > > Instead of processing REFER like a BYE request, we should modify the > REFER > > > to be processed like an INVITE. The rationale being if REFER is being > used > > > for initiating "requests" to make calls and the initiator of the > > > call wants > > > to see "call progress", REFER is "like" a 3pcc INVITE. > > > Use provisionals received by the Invoker of INVITE to be forwarded to > the > > > initiator of REFER. The arrival of a provisional stops the timer > > > (as we have > > > now modified REFER to be processed like an INVITE). > > > Venkatesh > > > > > > -----Original Message----- > > > From: Robert Sparks > > > To: Venkatesh Venkataramanan; sip@lists.bell-labs.com > > > Sent: 12/13/00 9:31 AM > > > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > > > The problem is that the REFER transaction itself will timeout > > > if the referred action (INVITE for example) takes longer than > > > the run of REFER retransmits to complete. > > > > > > RjS > > > > > > > -----Original Message----- > > > > From: sip-admin@lists.bell-labs.com > > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Venkatesh > > > > Venkataramanan > > > > Sent: Wednesday, December 13, 2000 3:07 AM > > > > To: Robert Sparks; sip@lists.bell-labs.com > > > > Subject: Re: [SIP] Solving the REFER retransmit issue > > > > > > > > > > > > Well, I go back to my suggestion(rather a question I posed > for Rohan) > > > of > > > > forwarding provisionals received for INVITES initiated by > the UA that > > > is > > > > processing the INVITE :-) instead of using an explicit > > > SUBSCRIBE/NOTIFY > > > > mechanism. With this approach all the UA would do have to do is to > > > forward > > > > any message that it receives in response to an INVITE it > issued (after > > > > suitably modifying the callID/From and To fields to match > the one for > > > the > > > > REFER request which triggered this INVITE). Any UA that doesn't want > > > to > > > > about what happened to a REFER request it issues could explicitely > > > specify > > > > so using the Request-Disposition header (caller preferences). > > > > Any repercussions with this ? > > > > Venkatesh > > > > ----- Original Message ----- > > > > From: "Robert Sparks" > > > > To: > > > > Sent: Tuesday, December 12, 2000 11:23 PM > > > > Subject: [SIP] Solving the REFER retransmit issue > > > > > > > > > > > > > The presentation of status of REFER and the discussion of the > > > > > REFER timeout issue is at > > > > > > > > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip- > > > cc-transfe > > > > r-02.htm > > > > > > > > Rohan Mahy also proposed an optimization of 2 where the REFER > > > > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > > > > of the REFERed action would just happen and could be ignored/481'ed > > > > if the the REFERing agent didn't care. > > > > > > > > Jonathan R. stated that 2) requires any agent accepting a REFER to > > > > implement being an event server (must implement accepting and > > > > managing subscriptions), and this is asking too much. > > > > > > > > Discussion? > > > > > > > > RjS > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 14 22:03:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA23259 for ; Thu, 14 Dec 2000 22:03:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E1274433D; Thu, 14 Dec 2000 21:03:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 2AC3544336 for ; Thu, 14 Dec 2000 21:02:16 -0500 (EST) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eBF325G00729; Fri, 15 Dec 2000 04:02:05 +0100 (MET) Received: from lmf.ericsson.se (EWUpcp003344pcs.sd.us.am.ericsson.se [142.133.141.53]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id EAA13724; Fri, 15 Dec 2000 04:01:58 +0100 (MET) Message-ID: <3A3989CA.8F5E7117@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Eric Burger Cc: sip , Robert Sparks Subject: Re: [SIP] RE: Changin local RTP port without a good reason References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 05:02:34 +0200 Content-Transfer-Encoding: 7bit Hello, Of course that sometimes you have to change your local configuration if the remote configuration changes... but there has to be a good reason (like a change of codecs). We have to have certain limits on when the local configuration cannot change in the 200 OK for a re-INVITE. Then, 3pcc will work without problems. If an application can, whenever there is a change in the remote side, change its local configuration, it would be impossible to establish even a simple session. If my local configuration is too dependant on the other party's configuration the negotiation ends up in an infinite loop. A re-INVITEs B. Since A has changed its configuration, B does so and returns an updated SDP in the 200 OK. A sent the re-INVITE taking into consideration B's previous SDP. Since B has now changed, A wants to change again. B will return again a new SDP, and this loop can go on for ever. Thus, I understand that under certain circumstances an application can decide to change its local configuration upon reception of an INVITE, but this is not a general situation. I do not find sensible to change my local port just because the remote port has changed. This is acutally what it is written in the 3pcc draft. It is recommended that an application does not change its local configuration without a "good" reason. We could define what a good reason is... Best regards, Gonzalo Eric Burger wrote: > > Agreed. The "alternate codec" may be physically somewhere else. > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Robert Sparks > > Sent: Thursday, December 14, 2000 1:32 PM > > To: Gonzalo Camarillo; sip > > Subject: [SIP] RE: Changin local RTP port without a good reason > > [snip] > > Even if this has been addressed, I'm uncomfortable with the idea that > > an implementation should be forced to keep the same local port across > > reinvites. Do I have to do this if I'm fundamentally changing media > > types? What if I'm adding/removing media lines? This was why we have > > a full-state reINVITE and not a HOLD method yes? > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 01:46:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA18467 for ; Fri, 15 Dec 2000 01:46:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5779E4433D; Fri, 15 Dec 2000 00:46:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id B0AC344336 for ; Fri, 15 Dec 2000 00:45:50 -0500 (EST) Received: from testmachine1 (ietf.207.137.71.72.tx.verio.net [207.137.71.72]) by broadsoft.com (8.8.8) id BAA04803; Fri, 15 Dec 2000 01:45:41 -0500 (EST) Message-ID: <000e01c06649$48408e90$484789cf@testmachine1> From: "Brett Tate" To: "Sip Mail List" References: Subject: Re: [SIP] Solving the REFER retransmit issue 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 14 Dec 2000 22:44:08 -0500 Content-Transfer-Encoding: 7bit How about including a parameter or header in REFER which would indicate an ordered request preference for when to send 200 response? Refer-Response-Disposition: 1#refer-response-param refer-response-param = "refer" | "18x-final" | "final" | "notify" | "notify-failure" | token "refer" means send 200 when get REFER. "18x-final" means send final response when get 18x or final response for method request. "final" means send final response when success or failure of method request is determined. "notify" send 200 when get REFER and send NOTIFY with method final response. "notify-failure" send 200 when get REFER and send NOTIFY when a failure of the method request is determined. The 200 response could contain the same header to indicate the meaning of the 200. Notice that the new header would only be a preference in request. If the receiver does not support or want to perform "notify", it could try the next list preference. If it doesn't support the header or it is not present, it defaults to acting like header with "refer". ----- Original Message ----- From: "Robert Sparks" To: Sent: Tuesday, December 12, 2000 12:53 PM Subject: [SIP] Solving the REFER retransmit issue > The presentation of status of REFER and the discussion of the > REFER timeout issue is at > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-cc-transfe > r-02.htm > > Rohan Mahy also proposed an optimization of 2 where the REFER > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > of the REFERed action would just happen and could be ignored/481'ed > if the the REFERing agent didn't care. > > Jonathan R. stated that 2) requires any agent accepting a REFER to > implement being an event server (must implement accepting and > managing subscriptions), and this is asking too much. > > Discussion? > > RjS > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 09:45:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14405 for ; Fri, 15 Dec 2000 09:45:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5EADC44341; Fri, 15 Dec 2000 08:45:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (law2-f47.hotmail.com [216.32.181.47]) by lists.bell-labs.com (Postfix) with ESMTP id CFA9944336 for ; Thu, 14 Dec 2000 19:14:52 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 14 Dec 2000 17:14:43 -0800 Received: from 207.137.73.101 by lw2fd.hotmail.msn.com with HTTP; Fri, 15 Dec 2000 01:14:43 GMT X-Originating-IP: [207.137.73.101] From: "James Undery" To: wtm@research.att.com, sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Dec 2000 01:14:43.0370 (UTC) FILETIME=[67E3F8A0:01C06634] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 01:14:43 -0000 >From: William Marshall >I think there is a definite simplification possible here, >if the three-phase-procedure can be dissaciated with INVITE. >That is, to allow the three-phase-procedure for all methods. > >SIP defined two mechanisms for retransmission/reliability. One >(currently used for INVITE) involves a three-way handshake >(INVITE, 200-OK, ACK); and the other (currently used for all >other methods) is a two-way handshake (INVITE, 200-OK). >The major difference, in my opinion, is that the three-way >handshake allows a provisional response, which is not allowed >for such methods as BYE, INFO, SUBSCRIBE, REGISTER, etc (even >though it might be useful). You can and should send provisional responces to all requests that you can't process in a specific time (200ms IIRC). >I think the changes are relatively simple. All are currently >implemented in the handling of INVITE, and just need to be >made non-INVITE-specific. > >UAC/UAS behavior changes: > >(1) A UAC that receives a 1xx response to any method, MUST send >an ACK when it receives a final response. > >(2) A UAS MUST send a response within some short time limit of >receiving a request, either a final response or a provisional >response. > >(3) If a UAS sends a provisional response, it MUST re-transmit any >final response until receiving an ACK. > >Proxy behavior changes: > >(1) A Proxy MUST forward an ACK to the UAS, regardless of original >request. > >(2) Proxy MUST forward a 100 provisional responses back to the UAC, >except when the proxy generated its own 100 response for the same >request. > >REFER, of course, is the first example of a method that could use >the three-way-handshake other than INVITE. The only reason the >situation didn't arise before (with the Also/Replaces version of >call control) because they were headers added to an INVITE method. > >The main issue is whether this is toooo incompatible with RFC2543. >Proxy point (2) is the only point that is not backwards compatible >with existing devices that conform to RFC2543 and that handle only >existing methods. > >Would this involve significant implementation changes in UAs? >Regardless, I think the contortions needed for REFER are more complex. > All this is very well for UAs, however, as a proxy implementor I and not going to be to happy about retaining state indefinitely and cancel your requests to prevent DOS attacks. James Undery jundery@ubiquity.net _____________________________________________________________________________________ Get more from the Web. FREE MSN Explorer download : http://explorer.msn.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 09:47:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA14639 for ; Fri, 15 Dec 2000 09:47:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 97D8F4434A; Fri, 15 Dec 2000 08:45:31 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id 3E90144336 for ; Thu, 14 Dec 2000 22:20:07 -0500 (EST) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id JAA14191 for ; Fri, 15 Dec 2000 09:59:19 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAAB81; Fri, 15 Dec 2000 09:49:50 +0000 Message-ID: <028a01c0664e$dacca1e0$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: "Robert Sparks" Cc: References: Subject: Re: [SIP] Solving the REFER retransmit issue 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 09:54:02 +0530 Content-Transfer-Encoding: 7bit Unless we re-transmit REFER until a final response has been received to ensure reliability of the final response like we mentioned in a previous posting. ----- Original Message ----- From: "Robert Sparks" To: "Venkatesh Venkataramanan" Cc: Sent: Thursday, December 14, 2000 10:34 PM Subject: RE: [SIP] Solving the REFER retransmit issue > > If we wanted to use the first two phases of invite, we > must take the third (ACK) with it. The ACK provides > recovery from a lost final response. > > RjS > > > -----Original Message----- > > From: Venkatesh Venkataramanan > > [mailto:venkatesh.venkataramanan@wipro.com] > > Sent: Wednesday, December 13, 2000 11:54 PM > > To: Robert Sparks; sdonovan@dynamicsoft.com; Venkatesh Venkataramanan > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] Solving the REFER retransmit issue > > > > > > Steve: > > I was essentially suggesting the same thing to Robert Spark in an email I > > sent him earlier today except that I missed out mentioning that we don't > > need the "ACK" for the final response received for a REFER !! > > Venkatesh > > ----- Original Message ----- > > From: "Robert Sparks" > > To: "Venkatesh Venkataramanan" > > Sent: Thursday, December 14, 2000 10:22 AM > > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > > > > This has been brought up before and was not well received. Why do you > > > need a three phase transaction for this? Do we want to introduce a > > > whole new state machine to do the first two phases of invite without > > > the third? > > > > > > The opinions I have been hearing to date are to try _very_ hard to > > > find a solution that worked within the existing non-INVITE transaction > > > model. If a good solution can't be found within that constraint, then > > > we start discussing the other options. > > > > > > > -----Original Message----- > > > > From: Venkatesh Venkataramanan > > > > [mailto:Venkatesh.Venkataramanan@sylantro.com] > > > > Sent: Wednesday, December 13, 2000 10:10 PM > > > > To: 'Robert Sparks ' > > > > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > > > > > > > > > Robert: > > > > I am probably missing out something here. Let me try to explain what I > > was > > > > proposing and get your thoughts on this one. > > > > Instead of processing REFER like a BYE request, we should modify the > > REFER > > > > to be processed like an INVITE. The rationale being if REFER is being > > used > > > > for initiating "requests" to make calls and the initiator of the > > > > call wants > > > > to see "call progress", REFER is "like" a 3pcc INVITE. > > > > Use provisionals received by the Invoker of INVITE to be forwarded to > > the > > > > initiator of REFER. The arrival of a provisional stops the timer > > > > (as we have > > > > now modified REFER to be processed like an INVITE). > > > > Venkatesh > > > > > > > > -----Original Message----- > > > > From: Robert Sparks > > > > To: Venkatesh Venkataramanan; sip@lists.bell-labs.com > > > > Sent: 12/13/00 9:31 AM > > > > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > > > > > The problem is that the REFER transaction itself will timeout > > > > if the referred action (INVITE for example) takes longer than > > > > the run of REFER retransmits to complete. > > > > > > > > RjS > > > > > > > > > -----Original Message----- > > > > > From: sip-admin@lists.bell-labs.com > > > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Venkatesh > > > > > Venkataramanan > > > > > Sent: Wednesday, December 13, 2000 3:07 AM > > > > > To: Robert Sparks; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Solving the REFER retransmit issue > > > > > > > > > > > > > > > Well, I go back to my suggestion(rather a question I posed > > for Rohan) > > > > of > > > > > forwarding provisionals received for INVITES initiated by > > the UA that > > > > is > > > > > processing the INVITE :-) instead of using an explicit > > > > SUBSCRIBE/NOTIFY > > > > > mechanism. With this approach all the UA would do have to do is to > > > > forward > > > > > any message that it receives in response to an INVITE it > > issued (after > > > > > suitably modifying the callID/From and To fields to match > > the one for > > > > the > > > > > REFER request which triggered this INVITE). Any UA that doesn't want > > > > to > > > > > about what happened to a REFER request it issues could explicitely > > > > specify > > > > > so using the Request-Disposition header (caller preferences). > > > > > Any repercussions with this ? > > > > > Venkatesh > > > > > ----- Original Message ----- > > > > > From: "Robert Sparks" > > > > > To: > > > > > Sent: Tuesday, December 12, 2000 11:23 PM > > > > > Subject: [SIP] Solving the REFER retransmit issue > > > > > > > > > > > > > > > > The presentation of status of REFER and the discussion of the > > > > > > REFER timeout issue is at > > > > > > > > > > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip- > > > > cc-transfe > > > > > r-02.htm > > > > > > > > > > Rohan Mahy also proposed an optimization of 2 where the REFER > > > > > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > > > > > of the REFERed action would just happen and could be ignored/481'ed > > > > > if the the REFERing agent didn't care. > > > > > > > > > > Jonathan R. stated that 2) requires any agent accepting a REFER to > > > > > implement being an event server (must implement accepting and > > > > > managing subscriptions), and this is asking too much. > > > > > > > > > > Discussion? > > > > > > > > > > RjS > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 09:50:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA15102 for ; Fri, 15 Dec 2000 09:50:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6042C44350; Fri, 15 Dec 2000 08:45:50 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wiproecmx2.wipro.com (wiproecmx2.wipro.com [164.164.31.6]) by lists.bell-labs.com (Postfix) with ESMTP id AC0D344336 for ; Fri, 15 Dec 2000 02:34:09 -0500 (EST) Received: from ecvwall1.wipro.com (ecvwall1.wipro.com [192.168.181.23]) by wiproecmx2.wipro.com (8.9.3/8.9.3) with SMTP id OAA23660 for ; Fri, 15 Dec 2000 14:13:15 GMT Received: from soma ([192.168.178.31]) by ecmail.mail.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA26DF; Fri, 15 Dec 2000 14:03:46 +0000 Message-ID: <042d01c06672$54760720$0c47a8c0@wipro.com> Reply-To: "Venkatesh Venkataramanan" From: "Venkatesh Venkataramanan" To: "Brett Tate" , "Sip Mail List" References: <000e01c06649$48408e90$484789cf@testmachine1> Subject: Re: [SIP] Solving the REFER retransmit issue 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 14:07:58 +0530 Content-Transfer-Encoding: 7bit I am kind of lost here. How does one provide reliability of final responses with this scheme? Say I initiated a refer with refer-disposition-response as "final" or "notify" or "notify-failure". I am assuming that "final" in the refer-disposition-response will automatically trigger a 200 OK for the initial refer so as to prevent the REFER request from timing out (so a "refer" in the refer-response-disposition is implied or should be added explicitly to avoid timeouts which we are trying to address). But at a later time, say the recipient of REFER wants to send a 200 OK to indicate successful completion of the request (or alternatively failure of completion). How would reliability of this response be assured? ----- Original Message ----- From: "Brett Tate" To: "Sip Mail List" Sent: Friday, December 15, 2000 9:14 AM Subject: Re: [SIP] Solving the REFER retransmit issue > How about including a parameter or header in REFER > which would indicate an ordered request preference for > when to send 200 response? > > Refer-Response-Disposition: 1#refer-response-param > refer-response-param = > "refer" | "18x-final" | "final" | "notify" | "notify-failure" | token > > "refer" means send 200 when get REFER. > > "18x-final" means send final response when get 18x or final > response for method request. > > "final" means send final response when success or failure > of method request is determined. > > "notify" send 200 when get REFER and send NOTIFY > with method final response. > > "notify-failure" send 200 when get REFER and send > NOTIFY when a failure of the method request is > determined. > > The 200 response could contain the same header to indicate > the meaning of the 200. Notice that the new header would > only be a preference in request. If the receiver does not > support or want to perform "notify", it could try the > next list preference. If it doesn't support the header or it is > not present, it defaults to acting like header with "refer". > > ----- Original Message ----- > From: "Robert Sparks" > To: > Sent: Tuesday, December 12, 2000 12:53 PM > Subject: [SIP] Solving the REFER retransmit issue > > > > The presentation of status of REFER and the discussion of the > > REFER timeout issue is at > > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-cc-transfe > > r-02.htm > > > > Rohan Mahy also proposed an optimization of 2 where the REFER > > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > > of the REFERed action would just happen and could be ignored/481'ed > > if the the REFERing agent didn't care. > > > > Jonathan R. stated that 2) requires any agent accepting a REFER to > > implement being an event server (must implement accepting and > > managing subscriptions), and this is asking too much. > > > > Discussion? > > > > RjS > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 11:56:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25540 for ; Fri, 15 Dec 2000 11:56:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2DF594433E; Fri, 15 Dec 2000 10:56:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by lists.bell-labs.com (Postfix) with ESMTP id 5D21244336 for ; Fri, 15 Dec 2000 10:55:53 -0500 (EST) Received: from alpha.hut.fi (bhoeneis@alpha.hut.fi [130.233.224.50]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id SAA30564 for ; Fri, 15 Dec 2000 18:55:43 +0200 (EET) From: Bernie Hoeneisen To: sip@lists.bell-labs.com Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: [SIP] Proxies modifying SDP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 18:55:43 +0200 (EET) Hi! I have question concerning the case, when SIP proxies modify SDP, which is AFAIK against SIP principles, isn't it? In the concrete case, proxies would be able to remove certain codecs from the INVITE messages, depending on the current policy in the network. (The UAS gets a subset of the codecs, which were originally sent by the UAC.) What impact does such a proxy behavior have to SIP? I can think of problems with authentication and message integrity checking (UAC signs message with its private key). Are there any other problems? Any comments are appreciated. cheers, Bernie _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 12:15:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01607 for ; Fri, 15 Dec 2000 12:15:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 68E9A4434B; Fri, 15 Dec 2000 11:15:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from broadsoft.com (broadsoft.com [161.58.239.68]) by lists.bell-labs.com (Postfix) with ESMTP id CFB2044336 for ; Fri, 15 Dec 2000 11:14:46 -0500 (EST) Received: from testmachine1 (ietf.207.137.71.72.tx.verio.net [207.137.71.72]) by broadsoft.com (8.8.8) id MAA13908; Fri, 15 Dec 2000 12:13:59 -0500 (EST) Message-ID: <002501c066a1$0f395fc0$484789cf@testmachine1> From: "Brett Tate" To: "Venkatesh Venkataramanan" , "Sip Mail List" References: <000e01c06649$48408e90$484789cf@testmachine1> <042d01c06672$54760720$0c47a8c0@wipro.com> Subject: Re: [SIP] Solving the REFER retransmit issue 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 09:12:28 -0500 Content-Transfer-Encoding: 7bit The choice of "final" would act as it does today and thus would not be the most desirable choice unless the request is expected to finish within 10 retries of the REFER and the NOTIFY is not supported. This would be idle when triggering a BYE or CANCEL. It also accommodates Jonathan's concern about requiring support of NOTIFY. Notice that header would also be include in the response to explicitly state how the 200 should be interpreted. The choice of "notify" would basically get a 200 REFER immediately and a NOTIFY once a final response has be determined for the REFER triggered method. This would be ideal when triggering an INVITE. The choice of "notify-failure" would act like "notify" but the NOTIFY would only be sent only in failure situations. This would be useful in many situations but especially useful for failed call transfer attempts. ----- Original Message ----- From: "Venkatesh Venkataramanan" To: "Brett Tate" ; "Sip Mail List" Sent: Friday, December 15, 2000 3:37 AM Subject: Re: [SIP] Solving the REFER retransmit issue > I am kind of lost here. How does one provide reliability of final responses > with this scheme? Say I initiated a refer with refer-disposition-response > as "final" or "notify" or "notify-failure". I am assuming that "final" in > the refer-disposition-response will automatically trigger a 200 OK for the > initial refer so as to prevent the REFER request from timing out (so a > "refer" in the refer-response-disposition is implied or should be added > explicitly to avoid timeouts which we are trying to address). But at a later > time, say the recipient of REFER wants to send a 200 OK to indicate > successful completion of the request (or alternatively failure of > completion). How would reliability of this response be assured? > ----- Original Message ----- > From: "Brett Tate" > To: "Sip Mail List" > Sent: Friday, December 15, 2000 9:14 AM > Subject: Re: [SIP] Solving the REFER retransmit issue > > > > How about including a parameter or header in REFER > > which would indicate an ordered request preference for > > when to send 200 response? > > > > Refer-Response-Disposition: 1#refer-response-param > > refer-response-param = > > "refer" | "18x-final" | "final" | "notify" | "notify-failure" | token > > > > "refer" means send 200 when get REFER. > > > > "18x-final" means send final response when get 18x or final > > response for method request. > > > > "final" means send final response when success or failure > > of method request is determined. > > > > "notify" send 200 when get REFER and send NOTIFY > > with method final response. > > > > "notify-failure" send 200 when get REFER and send > > NOTIFY when a failure of the method request is > > determined. > > > > The 200 response could contain the same header to indicate > > the meaning of the 200. Notice that the new header would > > only be a preference in request. If the receiver does not > > support or want to perform "notify", it could try the > > next list preference. If it doesn't support the header or it is > > not present, it defaults to acting like header with "refer". > > > > ----- Original Message ----- > > From: "Robert Sparks" > > To: > > Sent: Tuesday, December 12, 2000 12:53 PM > > Subject: [SIP] Solving the REFER retransmit issue > > > > > > > The presentation of status of REFER and the discussion of the > > > REFER timeout issue is at > > > > > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-cc-transfe > > > r-02.htm > > > > > > Rohan Mahy also proposed an optimization of 2 where the REFER > > > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > > > of the REFERed action would just happen and could be ignored/481'ed > > > if the the REFERing agent didn't care. > > > > > > Jonathan R. stated that 2) requires any agent accepting a REFER to > > > implement being an event server (must implement accepting and > > > managing subscriptions), and this is asking too much. > > > > > > Discussion? > > > > > > RjS > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 12:31:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05293 for ; Fri, 15 Dec 2000 12:31:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2C28644354; Fri, 15 Dec 2000 11:31:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from rwcxch02.clarent.com (unknown [208.205.112.2]) by lists.bell-labs.com (Postfix) with ESMTP id ECFD944336 for ; Fri, 15 Dec 2000 11:30:45 -0500 (EST) Received: by rwcxch02.clarent.com with Internet Mail Service (5.5.2650.21) id ; Fri, 15 Dec 2000 09:30:20 -0800 Received: from rwcjfmule01 (10.1.1.2 [10.1.1.2]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WV1DD24B; Fri, 15 Dec 2000 09:30:10 -0800 From: Jean-Francois Mule Reply-To: Jean-Francois Mule To: "'Bernie Hoeneisen'" , sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP Message-ID: <000b01c066bc$94a833f0$e54b010a@rwcjfmule01> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 09:29:29 -0800 Content-Transfer-Encoding: 7bit Bernie Hoeneisen wrote: > I have question concerning the case, when SIP proxies modify SDP, > which is AFAIK against SIP principles, isn't it? I do not think so. Why is that *against* SIP principles? What principles?' > In the concrete case, proxies would be able to remove certain codecs > from the INVITE messages, depending on the current policy in the > network. (The UAS gets a subset of the codecs, which were originally > sent by the UAC.) > What impact does such a proxy behavior have to SIP? I can think of > problems with authentication and message integrity checking (UAC signs > message with its private key). It certainly depends on the security mechanism used. For e.g., with the simple basic md5, it does not cause any issue. Jean-Francois _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 13:06:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16353 for ; Fri, 15 Dec 2000 13:06:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 78E8E44352; Fri, 15 Dec 2000 12:06:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 3FB4F44349 for ; Fri, 15 Dec 2000 12:05:49 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA18013 for ; Fri, 15 Dec 2000 10:05:43 -0800 (PST) Received: from sony-laptop (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with SMTP id AAB05840; Fri, 15 Dec 2000 10:05:34 -0800 (PST) Message-Id: <4.1.20001215092137.00c80100@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: sip@lists.bell-labs.com From: Rohan Mahy Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: [SIP] REFER open issues Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 10:08:50 -0800 Hi, I'd like to summarize ALL the open issues that we have with REFER. In the interest of coming to consensus, I'd like to invite interested implementers who have comments to meet in person before Minneapolis to close REFER open issues. If folks think this is a good idea, we would certainly post the minutes and partial consensus back to the list for comments/changes. As a strawman, I will suggest sometime in the last week of January. A few plausible locations are: Dallas, New York, San Jose... I volunteer to organize this if necessary. A short summary of the issues are below in no particular order: 1) Retransmission problem: Robert Sparks already summarized this problem in his recent post. (a) REFER completes early, use explicit SUBSCRIBE for more info (b) REFER completes early and implicitly SUBSCRIBEs to more info (c) REFER completes after 16 secs and provides URL for SUBSCRIBE (d) send new REFER (new CSeq same call ID) after 32 seconds. 2) Cancellation: If REFER returns a final response before a long INVITE transaction completes, how do you cancel that INVITE? (a) send same REFER with ;method=CANCEL (b) send REFERCANCEL method 3) Call-leg matching: Should you include call-id's in Refer-to URLs? If not, what do you use for matching (Replaces or similar)? (a) match call-ids (b) use a Replaces header (c) use the mesh-id to setup mesh, then say BYE (d) use a new header 4) If we choose Replaces or the like, how do we express that we want to *join* 2 legs via REFER? (a) Join header (b) Associate header (c) new method (d) something else 5) If Refer-To contains parameters (method, transport), or potentially contradictory headers, what do we do with them? (a) allow all of them if authorized (b) allow a subset of methods/headers (c) send an error mesage (d) ignore the headers/parameters (e) ignore the whole message 6) If we don't allow ;method=BYE, how do we solve the problem described in the Music on Hold flow? (a) method=BYE (b) ??? 7) How do we ask devices to do stuff for us? [probably defer this issue] (a) REFER with parameters/headers (b) PHONECTL (c) some NEWMETHOD (d) Mbus (e) other Any other REFER open issues I missed? thanks, -rohan _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 13:08:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA17132 for ; Fri, 15 Dec 2000 13:08:30 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DAC3C44363; Fri, 15 Dec 2000 12:06:29 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id B888644349 for ; Fri, 15 Dec 2000 12:05:50 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA18083; Fri, 15 Dec 2000 10:05:48 -0800 (PST) Received: from sony-laptop (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with SMTP id AAB05841; Fri, 15 Dec 2000 10:05:35 -0800 (PST) Message-Id: <4.1.20001215092253.00c90c70@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: William Marshall , sip@lists.bell-labs.com From: Rohan Mahy Subject: Re: [SIP] Solving the REFER retransmit issue In-Reply-To: <200012150004.TAA91443@fish-ha.research.att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 09:34:51 -0800 Hi, If we were to build SIP again from scratch, then I agree that we should allow the 3-way handshake to be more general, or switch to a 4-way handshake as Jonathan proposed. However, the changes to add 3-way to REFER that Bill Marshall and others propose, isn't backward compatible with baseline SIP. We had a variation of this theme during the discussion of 200 resonses to PRACK. following the KISS principal, I'd like to propose that REFER responds immediately once the Referred-to message is sent. (Note: this is backwards compatible with implementations of REFER that just want to do blind transfer). I further propose that the provisional and final progress of the REFER is sent back via either an unsolicited NOTIFY or a REFERSTATUS (for example), either of which can be ignored, or 481ed if they are not needed. I would further propose that if we use a separate method, that the separate method should be identical in format to an unsolicited NOTIFY, except for the method name. That way, an implementation that already supports NOTIFY can easily handle/parse the message. thanks, -rohan At 04:04 PM 12/14/00 , William Marshall wrote: >I think there is a definite simplification possible here, >if the three-phase-procedure can be dissaciated with INVITE. >That is, to allow the three-phase-procedure for all methods. > >SIP defined two mechanisms for retransmission/reliability. One >(currently used for INVITE) involves a three-way handshake >(INVITE, 200-OK, ACK); and the other (currently used for all >other methods) is a two-way handshake (INVITE, 200-OK). >The major difference, in my opinion, is that the three-way >handshake allows a provisional response, which is not allowed >for such methods as BYE, INFO, SUBSCRIBE, REGISTER, etc (even >though it might be useful). > >I think the changes are relatively simple. All are currently >implemented in the handling of INVITE, and just need to be >made non-INVITE-specific. > >UAC/UAS behavior changes: > >(1) A UAC that receives a 1xx response to any method, MUST send >an ACK when it receives a final response. > >(2) A UAS MUST send a response within some short time limit of >receiving a request, either a final response or a provisional >response. > >(3) If a UAS sends a provisional response, it MUST re-transmit any >final response until receiving an ACK. > >Proxy behavior changes: > >(1) A Proxy MUST forward an ACK to the UAS, regardless of original >request. > >(2) Proxy MUST forward a 100 provisional responses back to the UAC, >except when the proxy generated its own 100 response for the same >request. > >REFER, of course, is the first example of a method that could use >the three-way-handshake other than INVITE. The only reason the >situation didn't arise before (with the Also/Replaces version of >call control) because they were headers added to an INVITE method. > >The main issue is whether this is toooo incompatible with RFC2543. >Proxy point (2) is the only point that is not backwards compatible >with existing devices that conform to RFC2543 and that handle only >existing methods. > >Would this involve significant implementation changes in UAs? >Regardless, I think the contortions needed for REFER are more complex. > >Bill Marshall >wtm@research.att.com > >-----original message----- >From: "Robert Sparks" >To: "Venkatesh Venkataramanan" >Cc: >Subject: RE: [SIP] Solving the REFER retransmit issue >Date: Thu, 14 Dec 2000 11:04:13 -0600 > > >If we wanted to use the first two phases of invite, we >must take the third (ACK) with it. The ACK provides >recovery from a lost final response. > >RjS > >> -----Original Message----- >> From: Venkatesh Venkataramanan >> [mailto:venkatesh.venkataramanan@wipro.com] >> Sent: Wednesday, December 13, 2000 11:54 PM >> To: Robert Sparks; sdonovan@dynamicsoft.com; Venkatesh Venkataramanan >> Cc: sip@lists.bell-labs.com >> Subject: Re: [SIP] Solving the REFER retransmit issue >> >> >> Steve: >> I was essentially suggesting the same thing to Robert Spark in an email I >> sent him earlier today except that I missed out mentioning that we don't >> need the "ACK" for the final response received for a REFER !! >> Venkatesh >> ----- Original Message ----- >> From: "Robert Sparks" >> To: "Venkatesh Venkataramanan" >> Sent: Thursday, December 14, 2000 10:22 AM >> Subject: RE: [SIP] Solving the REFER retransmit issue >> >> >> > This has been brought up before and was not well received. Why do you >> > need a three phase transaction for this? Do we want to introduce a >> > whole new state machine to do the first two phases of invite without >> > the third? >> > >> > The opinions I have been hearing to date are to try _very_ hard to >> > find a solution that worked within the existing non-INVITE transaction >> > model. If a good solution can't be found within that constraint, then >> > we start discussing the other options. >> > >> > > -----Original Message----- >> > > From: Venkatesh Venkataramanan >> > > [mailto:Venkatesh.Venkataramanan@sylantro.com] >> > > Sent: Wednesday, December 13, 2000 10:10 PM >> > > To: 'Robert Sparks ' >> > > Subject: RE: [SIP] Solving the REFER retransmit issue >> > > >> > > >> > > Robert: >> > > I am probably missing out something here. Let me try to explain what I >> was >> > > proposing and get your thoughts on this one. >> > > Instead of processing REFER like a BYE request, we should modify the >> REFER >> > > to be processed like an INVITE. The rationale being if REFER is being >> used >> > > for initiating "requests" to make calls and the initiator of the >> > > call wants >> > > to see "call progress", REFER is "like" a 3pcc INVITE. >> > > Use provisionals received by the Invoker of INVITE to be forwarded to >> the >> > > initiator of REFER. The arrival of a provisional stops the timer >> > > (as we have >> > > now modified REFER to be processed like an INVITE). >> > > Venkatesh >> > > >> > > -----Original Message----- >> > > From: Robert Sparks >> > > To: Venkatesh Venkataramanan; sip@lists.bell-labs.com >> > > Sent: 12/13/00 9:31 AM >> > > Subject: RE: [SIP] Solving the REFER retransmit issue >> > > >> > > The problem is that the REFER transaction itself will timeout >> > > if the referred action (INVITE for example) takes longer than >> > > the run of REFER retransmits to complete. >> > > >> > > RjS >> > > >> > > > -----Original Message----- >> > > > From: sip-admin@lists.bell-labs.com >> > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Venkatesh >> > > > Venkataramanan >> > > > Sent: Wednesday, December 13, 2000 3:07 AM >> > > > To: Robert Sparks; sip@lists.bell-labs.com >> > > > Subject: Re: [SIP] Solving the REFER retransmit issue >> > > > >> > > > >> > > > Well, I go back to my suggestion(rather a question I posed >> for Rohan) >> > > of >> > > > forwarding provisionals received for INVITES initiated by >> the UA that >> > > is >> > > > processing the INVITE :-) instead of using an explicit >> > > SUBSCRIBE/NOTIFY >> > > > mechanism. With this approach all the UA would do have to do is to >> > > forward >> > > > any message that it receives in response to an INVITE it >> issued (after >> > > > suitably modifying the callID/From and To fields to match >> the one for >> > > the >> > > > REFER request which triggered this INVITE). Any UA that doesn't want >> > > to >> > > > about what happened to a REFER request it issues could explicitely >> > > specify >> > > > so using the Request-Disposition header (caller preferences). >> > > > Any repercussions with this ? >> > > > Venkatesh >> > > > ----- Original Message ----- >> > > > From: "Robert Sparks" >> > > > To: >> > > > Sent: Tuesday, December 12, 2000 11:23 PM >> > > > Subject: [SIP] Solving the REFER retransmit issue >> > > > >> > > > >> > > > > The presentation of status of REFER and the discussion of the >> > > > > REFER timeout issue is at >> > > > > >> > > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip- >> > > cc-transfe >> > > > r-02.htm >> > > > >> > > > Rohan Mahy also proposed an optimization of 2 where the REFER >> > > > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress >> > > > of the REFERed action would just happen and could be ignored/481'ed >> > > > if the the REFERing agent didn't care. >> > > > >> > > > Jonathan R. stated that 2) requires any agent accepting a REFER to >> > > > implement being an event server (must implement accepting and >> > > > managing subscriptions), and this is asking too much. >> > > > >> > > > Discussion? >> > > > >> > > > RjS >> > > > >> > > > >> > > > _______________________________________________ >> > > > SIP mailing list >> > > > SIP@lists.bell-labs.com >> > > > http://lists.bell-labs.com/mailman/listinfo/sip >> > > > >> > > > >> > > >> > > >> > > _______________________________________________ >> > > SIP mailing list >> > > SIP@lists.bell-labs.com >> > > http://lists.bell-labs.com/mailman/listinfo/sip >> > > >> > > >> > > _______________________________________________ >> > > SIP mailing list >> > > SIP@lists.bell-labs.com >> > > http://lists.bell-labs.com/mailman/listinfo/sip >> > > >> > > >> > >> > >> > >> >> > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 13:18:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20379 for ; Fri, 15 Dec 2000 13:18:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E44E74436C; Fri, 15 Dec 2000 12:18:10 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 58D1B4436B for ; Fri, 15 Dec 2000 12:17:41 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id KAA18063 for ; Fri, 15 Dec 2000 10:17:31 -0800 (PST) Received: from sony-laptop (ssh-sj1.cisco.com [171.68.225.134]) by imop.cisco.com (Mirapoint) with SMTP id AAB05998; Fri, 15 Dec 2000 10:17:25 -0800 (PST) Message-Id: <4.1.20001215101913.00c93e30@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: sip@lists.bell-labs.com From: Rohan Mahy Subject: Re: [SIP] REFER open issues In-Reply-To: <4.1.20001215092137.00c80100@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 10:20:42 -0800 One minor addition below... At 10:08 AM 12/15/00 , Rohan Mahy wrote: >Hi, > >I'd like to summarize ALL the open issues that we have with REFER. In the >interest of coming to consensus, I'd like to invite interested implementers >who have comments to meet in person before Minneapolis to close REFER open >issues. If folks think this is a good idea, we would certainly post the >minutes and partial consensus back to the list for comments/changes. As a >strawman, I will suggest sometime in the last week of January. A few >plausible locations are: Dallas, New York, San Jose... I volunteer to >organize this if necessary. > >A short summary of the issues are below in no particular order: > >1) Retransmission problem: >Robert Sparks already summarized this problem in his recent post. >(a) REFER completes early, use explicit SUBSCRIBE for more info >(b) REFER completes early and implicitly SUBSCRIBEs to more info >(c) REFER completes after 16 secs and provides URL for SUBSCRIBE >(d) send new REFER (new CSeq same call ID) after 32 seconds. (e) REFER completes early; use separate REFERDONE or similar message >2) Cancellation: >If REFER returns a final response before a long INVITE transaction >completes, how do you cancel that INVITE? >(a) send same REFER with ;method=CANCEL >(b) send REFERCANCEL method > >3) Call-leg matching: >Should you include call-id's in Refer-to URLs? If not, what do you use for >matching (Replaces or similar)? >(a) match call-ids >(b) use a Replaces header >(c) use the mesh-id to setup mesh, then say BYE >(d) use a new header > >4) If we choose Replaces or the like, how do we express that we want to >*join* 2 legs via REFER? >(a) Join header >(b) Associate header >(c) new method >(d) something else > >5) If Refer-To contains parameters (method, transport), or potentially >contradictory headers, what do we do with them? >(a) allow all of them if authorized >(b) allow a subset of methods/headers >(c) send an error mesage >(d) ignore the headers/parameters >(e) ignore the whole message > >6) If we don't allow ;method=BYE, how do we solve the problem described in >the Music on >Hold flow? >(a) method=BYE >(b) ??? > >7) How do we ask devices to do stuff for us? [probably defer this issue] >(a) REFER with parameters/headers >(b) PHONECTL >(c) some NEWMETHOD >(d) Mbus >(e) other > >Any other REFER open issues I missed? > >thanks, >-rohan > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 13:39:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA28155 for ; Fri, 15 Dec 2000 13:39:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7F4F04434F; Fri, 15 Dec 2000 12:39:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from valhalla.marko.net (cx851333-b.irvn1.occa.home.com [24.21.59.175]) by lists.bell-labs.com (Postfix) with ESMTP id 78ECB4434C for ; Fri, 15 Dec 2000 12:38:30 -0500 (EST) Received: (from tsearle@localhost) by valhalla.marko.net (8.10.0/8.10.0) id eBFIcKf10928 for sip@lists.bell-labs.com; Fri, 15 Dec 2000 10:38:20 -0800 From: tsearle@valhalla.marko.net To: sip@lists.bell-labs.com Message-ID: <20001215103820.A10881@valhalla.marko.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2i Subject: [SIP] Inteligent Codec Selection Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 10:38:20 -0800 I would like to set up a SIP solution that would negotiate to use G.711 if there is sufficient bandwith between the two endpoints to do so, and would negotiate G.723.1 otherwise. Is there any way to do codec negotiation in such a manner? Torrey _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 13:43:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA29611 for ; Fri, 15 Dec 2000 13:43:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 423A144373; Fri, 15 Dec 2000 12:40:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web1103.mail.yahoo.com (web1103.mail.yahoo.com [128.11.23.123]) by lists.bell-labs.com (Postfix) with SMTP id 05A2744372 for ; Fri, 15 Dec 2000 12:39:46 -0500 (EST) Received: (qmail 19765 invoked by uid 60001); 15 Dec 2000 18:39:35 -0000 Message-ID: <20001215183935.19764.qmail@web1103.mail.yahoo.com> Received: from [132.208.135.60] by web1103.mail.yahoo.com; Fri, 15 Dec 2000 19:39:35 CET From: =?iso-8859-1?q?rufin=20soh?= To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Re: SIP digest, Vol 1 #616 - 4 msgs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 19:39:35 +0100 (CET) Content-Transfer-Encoding: 8bit If proxy try to send a 200 ok to UAS but receives a 5xx (next proxy down). It means according to the draft that it can't contact this server through proxy B, the best thing for UAS is to have a checking process, or to have more detailed sdp. Plese send more details on this topic I think I will have such a problem in my Project. --- sip-request@lists.bell-labs.com a écrit : > Send SIP mailing list submissions to > sip@lists.bell-labs.com > > To subscribe or unsubscribe via the World Wide Web, > visit > http://lists.bell-labs.com/mailman/listinfo/sip > or, via email, send a message with subject or body > 'help' to > sip-request@lists.bell-labs.com > > You can reach the person managing the list at > sip-admin@lists.bell-labs.com > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of SIP digest..." > > > Today's Topics: > > 1. Re: Solving the REFER retransmit issue > (Venkatesh Venkataramanan) > 2. Proxies modifying SDP (Bernie Hoeneisen) > 3. Re: Solving the REFER retransmit issue (Brett > Tate) > 4. RE: Proxies modifying SDP (Jean-Francois Mule) > > ATTACHMENT part 3.1 message/rfc822 > Répondre à: "Venkatesh Venkataramanan" > > De: "Venkatesh Venkataramanan" > > À: "Brett Tate" , > "Sip Mail List" > Objet: Re: [SIP] Solving the REFER retransmit issue > Date: Fri, 15 Dec 2000 14:07:58 +0530 > > I am kind of lost here. How does one provide > reliability of final responses > with this scheme? Say I initiated a refer with > refer-disposition-response > as "final" or "notify" or "notify-failure". I am > assuming that "final" in > the refer-disposition-response will automatically > trigger a 200 OK for the > initial refer so as to prevent the REFER request > from timing out (so a > "refer" in the refer-response-disposition is implied > or should be added > explicitly to avoid timeouts which we are trying to > address). But at a later > time, say the recipient of REFER wants to send a 200 > OK to indicate > successful completion of the request (or > alternatively failure of > completion). How would reliability of this response > be assured? > ----- Original Message ----- > From: "Brett Tate" > To: "Sip Mail List" > Sent: Friday, December 15, 2000 9:14 AM > Subject: Re: [SIP] Solving the REFER retransmit > issue > > > > How about including a parameter or header in REFER > > which would indicate an ordered request preference > for > > when to send 200 response? > > > > Refer-Response-Disposition: 1#refer-response-param > > refer-response-param = > > "refer" | "18x-final" | "final" | "notify" | > "notify-failure" | token > > > > "refer" means send 200 when get REFER. > > > > "18x-final" means send final response when get 18x > or final > > response for method request. > > > > "final" means send final response when success or > failure > > of method request is determined. > > > > "notify" send 200 when get REFER and send NOTIFY > > with method final response. > > > > "notify-failure" send 200 when get REFER and send > > NOTIFY when a failure of the method request is > > determined. > > > > The 200 response could contain the same header to > indicate > > the meaning of the 200. Notice that the new > header would > > only be a preference in request. If the receiver > does not > > support or want to perform "notify", it could try > the > > next list preference. If it doesn't support the > header or it is > > not present, it defaults to acting like header > with "refer". > > > > ----- Original Message ----- > > From: "Robert Sparks" > > To: > > Sent: Tuesday, December 12, 2000 12:53 PM > > Subject: [SIP] Solving the REFER retransmit issue > > > > > > > The presentation of status of REFER and the > discussion of the > > > REFER timeout issue is at > > > > > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-cc-transfe > > > r-02.htm > > > > > > Rohan Mahy also proposed an optimization of 2 > where the REFER > > > was overloaded to also mean SUBSCRIBE - NOTIFYs > for the progress > > > of the REFERed action would just happen and > could be ignored/481'ed > > > if the the REFERing agent didn't care. > > > > > > Jonathan R. stated that 2) requires any agent > accepting a REFER to > > > implement being an event server (must implement > accepting and > > > managing subscriptions), and this is asking too > much. > > > > > > Discussion? > > > > > > RjS > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > ATTACHMENT part 3.2 message/rfc822 > Date: Fri, 15 Dec 2000 18:55:43 +0200 (EET) > De: Bernie Hoeneisen > À: sip@lists.bell-labs.com > Objet: [SIP] Proxies modifying SDP > > Hi! > > I have question concerning the case, when SIP > proxies modify SDP, > which is AFAIK against SIP principles, isn't it? > > In the concrete case, proxies would be able to > remove certain codecs > from the INVITE messages, depending on the current > policy in the > network. (The UAS gets a subset of the codecs, which > were originally > sent by the UAC.) > > What impact does such a proxy behavior have to SIP? > I can think of > problems with authentication and message integrity > checking (UAC signs > message with its private key). > > Are there any other problems? Any comments are > appreciated. > > cheers, > Bernie > > > > > ATTACHMENT part 3.3 message/rfc822 > De: "Brett Tate" > À: "Venkatesh Venkataramanan" > , > "Sip Mail List" > Objet: Re: [SIP] Solving the REFER retransmit issue > Date: Fri, 15 Dec 2000 09:12:28 -0500 > > The choice of "final" would act as it does today and > thus would not be the most desirable choice unless > the request is expected to finish within 10 retries > of > the REFER and the NOTIFY is not supported. > This would be idle when triggering a BYE or CANCEL. > It also accommodates Jonathan's concern about > requiring support of NOTIFY. Notice that header > would also be include in the response to explicitly > state how the 200 should be interpreted. > > The choice of "notify" would basically get a 200 > REFER > immediately and a NOTIFY once a final response has > be determined for the REFER triggered method. > This would be ideal when triggering an INVITE. > > The choice of "notify-failure" would act like > "notify" > but the NOTIFY would only be sent only in failure > situations. This would be useful in many situations > but especially useful for failed call transfer > attempts. > > ----- Original Message ----- > From: "Venkatesh Venkataramanan" > > To: "Brett Tate" ; "Sip Mail > List" > > Sent: Friday, December 15, 2000 3:37 AM > Subject: Re: [SIP] Solving the REFER retransmit > issue > > > > I am kind of lost here. How does one provide > reliability of final > responses > > with this scheme? Say I initiated a refer with > refer-disposition-response > > as "final" or "notify" or "notify-failure". I am > assuming that "final" in > > the refer-disposition-response will automatically > trigger a 200 OK for the > > initial refer so as to prevent the REFER request > from timing out (so a > > "refer" in the refer-response-disposition is > implied or should be added > > explicitly to avoid timeouts which we are trying > to address). But at a > later > > time, say the recipient of REFER wants to send a > 200 OK to indicate > > successful completion of the request (or > alternatively failure of > > completion). How would reliability of this > response be assured? > > ----- Original Message ----- > > From: "Brett Tate" > > To: "Sip Mail List" > > Sent: Friday, December 15, 2000 9:14 AM > > Subject: Re: [SIP] Solving the REFER retransmit > issue > > > > > > > How about including a parameter or header in > REFER > > > which would indicate an ordered request > preference for > > > when to send 200 response? > > > > > > Refer-Response-Disposition: > 1#refer-response-param > > > refer-response-param = > > > "refer" | "18x-final" | "final" | "notify" | > "notify-failure" | token > > > > > > "refer" means send 200 when get REFER. > > > > > > "18x-final" means send final response when get > 18x or final > > > response for method request. > > > > > > "final" means send final response when success > or failure > > > of method request is determined. > > > > > > "notify" send 200 when get REFER and send NOTIFY > > > with method final response. > > > > > > "notify-failure" send 200 when get REFER and > send > > > NOTIFY when a failure of the method request is > > > determined. > > > > > > The 200 response could contain the same header > to indicate > > > the meaning of the 200. Notice that the new > header would > > > only be a preference in request. If the > receiver does not > > > support or want to perform "notify", it could > try the > > > next list preference. If it doesn't support the > header or it is > > > not present, it defaults to acting like header > with "refer". > > > > > > ----- Original Message ----- > > > From: "Robert Sparks" > > > To: > > > Sent: Tuesday, December 12, 2000 12:53 PM > > > Subject: [SIP] Solving the REFER retransmit > issue > > > > > > > > > > The presentation of status of REFER and the > discussion of the > > > > REFER timeout issue is at > > > > > > > > > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip-cc-transfe > > > > r-02.htm > > > > > > > > Rohan Mahy also proposed an optimization of 2 > where the REFER > > > > was overloaded to also mean SUBSCRIBE - > NOTIFYs for the progress > > > > of the REFERed action would just happen and > could be ignored/481'ed > > > > if the the REFERing agent didn't care. > > > > > > > > Jonathan R. stated that 2) requires any agent > accepting a REFER to > > > > implement being an event server (must > implement accepting and > > > > managing subscriptions), and this is asking > too much. > > > > > > > > Discussion? > > > > > > > > RjS > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > ATTACHMENT part 3.4 message/rfc822 > De: Jean-Francois Mule > Répondre à: Jean-Francois Mule > À: 'Bernie Hoeneisen' , > sip@lists.bell-labs.com > Objet: RE: [SIP] Proxies modifying SDP > Date: Fri, 15 Dec 2000 09:29:29 -0800 > > Bernie Hoeneisen wrote: > > I have question concerning the case, when SIP > proxies modify SDP, > > which is AFAIK against SIP principles, isn't it? > I do not think so. > Why is that *against* SIP principles? What > principles?' > > > In the concrete case, proxies would be able to > remove certain codecs > > from the INVITE messages, depending on the current > policy in the > > network. (The UAS gets a subset of the codecs, > which were originally > > sent by the UAC.) > > What impact does such a proxy behavior have to > SIP? I can think of > > problems with authentication and message integrity > checking (UAC signs > > message with its private key). > It certainly depends on the security mechanism used. > For e.g., with the > simple basic md5, it does not cause any issue. > > Jean-Francois > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > ___________________________________________________________ Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, Yahoo! Messenger : http://fr.messenger.yahoo.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 13:55:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03776 for ; Fri, 15 Dec 2000 13:55:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CB0194436A; Fri, 15 Dec 2000 12:55:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hotmail.com (f200.law3.hotmail.com [209.185.241.200]) by lists.bell-labs.com (Postfix) with ESMTP id 07EDA44365 for ; Fri, 15 Dec 2000 12:30:05 -0500 (EST) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 15 Dec 2000 10:29:55 -0800 Received: from 207.137.73.222 by lw3fd.law3.hotmail.msn.com with HTTP; Fri, 15 Dec 2000 18:29:55 GMT X-Originating-IP: [207.137.73.222] From: "Neil Deason" To: jfmule@clarent.com, bhoeneis@cc.hut.fi, sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 15 Dec 2000 18:29:55.0481 (UTC) FILETIME=[0597F890:01C066C5] Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 18:29:55 -0000 >Bernie Hoeneisen wrote: > > I have question concerning the case, when SIP proxies modify SDP, > > which is AFAIK against SIP principles, isn't it? >I do not think so. >Why is that *against* SIP principles? What principles?' The fundamental concept that payloads are opaque to SIP Proxy Servers. To do this sort of thing you probably want to use a back to back UA. Cheers, Neil. -- Ubiquity Software, UK www.ubiquity.net > > In the concrete case, proxies would be able to remove certain codecs > > from the INVITE messages, depending on the current policy in the > > network. (The UAS gets a subset of the codecs, which were originally > > sent by the UAC.) > > What impact does such a proxy behavior have to SIP? I can think of > > problems with authentication and message integrity checking (UAC signs > > message with its private key). >It certainly depends on the security mechanism used. For e.g., with the >simple basic md5, it does not cause any issue. > >Jean-Francois _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 14:37:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18256 for ; Fri, 15 Dec 2000 14:37:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 173DB44340; Fri, 15 Dec 2000 13:37:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from calxch01.clarent.com (64-60-54-195-cust.telepacific.net [64.60.54.195]) by lists.bell-labs.com (Postfix) with ESMTP id 03D2C44339 for ; Fri, 15 Dec 2000 13:36:33 -0500 (EST) Received: by CALXCH01 with Internet Mail Service (5.5.2653.19) id ; Fri, 15 Dec 2000 11:36:13 -0800 Received: from rwcjfmule01 (10.1.1.2 [10.1.1.2]) by rwcxch02.clarent.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id WV1DDJ5M; Fri, 15 Dec 2000 11:35:53 -0800 Reply-To: From: "Jean-Francois Mule" To: Message-ID: <002601c066ce$24bdab80$e54b010a@rwcjfmule01> 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 CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Subject: [SIP] Bug in 2543bis-02 re: Record-Route Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 11:35:11 -0800 Content-Transfer-Encoding: 7bit Independently of the Record-Route discussions, the 2543bis-02 (dated 11-24-00) has a small issue: In the same section 6.35.1 of 2543bis-02, it is stated: "a request route, once established, persists until the end of the call leg, *regardless of whether the Record-Route header is present in subsequent requests.*" ... "Note that proxy servers have to add Record-Route headers to each request *as long as* they want to be "visited" by the next request for the call leg." The persistence of the record-route is confusing. The suggestion is to just remove the note. Comments? Jean-Francois. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 14:51:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21919 for ; Fri, 15 Dec 2000 14:51:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 50D124434C; Fri, 15 Dec 2000 13:51:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id 5565444336 for ; Fri, 15 Dec 2000 13:50:56 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id MAA15297 for ; Fri, 15 Dec 2000 12:50:46 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id MAA24213 for ; Fri, 15 Dec 2000 12:50:46 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Fri, 15 Dec 2000 13:50:46 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8866@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'Neil Deason'" , jfmule@clarent.com, bhoeneis@cc.hut.fi, sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 13:50:44 -0600 I see it as the requested way of forcing the media stream to go via an 'IP switch' (like the H323 MCU). If a proxy server is not allowed or if it is not appropriate for it to touch the SDP element, then is there any other way to make sure the media stream goes via our MCU gateway. (There could be various of reasons why we would want to have such a gateway) What do u think? Uri -----Original Message----- From: Neil Deason [mailto:neil_deason@hotmail.com] Sent: Friday, December 15, 2000 12:30 PM To: jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP >Bernie Hoeneisen wrote: > > I have question concerning the case, when SIP proxies modify SDP, > > which is AFAIK against SIP principles, isn't it? >I do not think so. >Why is that *against* SIP principles? What principles?' The fundamental concept that payloads are opaque to SIP Proxy Servers. To do this sort of thing you probably want to use a back to back UA. Cheers, Neil. -- Ubiquity Software, UK www.ubiquity.net > > In the concrete case, proxies would be able to remove certain codecs > > from the INVITE messages, depending on the current policy in the > > network. (The UAS gets a subset of the codecs, which were originally > > sent by the UAC.) > > What impact does such a proxy behavior have to SIP? I can think of > > problems with authentication and message integrity checking (UAC signs > > message with its private key). >It certainly depends on the security mechanism used. For e.g., with the >simple basic md5, it does not cause any issue. > >Jean-Francois _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 14:53:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22416 for ; Fri, 15 Dec 2000 14:53:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 083AA44371; Fri, 15 Dec 2000 13:53:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id 1856F44370 for ; Fri, 15 Dec 2000 13:52:25 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 15 Dec 2000 13:52:14 -0600 (CST) From: Billy Biggs To: Jean-Francois Mule Cc: Billy Biggs Subject: Re: [SIP] Bug in 2543bis-02 re: Record-Route Message-ID: <20001215135213.A21463@div8.net> References: <002601c066ce$24bdab80$e54b010a@rwcjfmule01> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i In-Reply-To: <002601c066ce$24bdab80$e54b010a@rwcjfmule01>; from jfmule@clarent.com on Fri, Dec 15, 2000 at 11:35:11AM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 13:52:14 -0600 Jean-Francois Mule (jfmule@clarent.com): > Independently of the Record-Route discussions, the 2543bis-02 (dated > 11-24-00) has a small issue: > > In the same section 6.35.1 of 2543bis-02, it is stated: > "a request route, once established, persists until the end of the call > leg, *regardless of whether the Record-Route header is present in > subsequent requests.*" > ... > "Note that proxy servers have to add Record-Route headers to each > request *as long as* they want to be "visited" by the next request for > the call leg." The persistence of the record-route is confusing. The > suggestion is to just remove the note. The statement is correct: The Route persists until the end of the call leg regardless. Proxies may not ever leave the Route for a call-leg. The only thing that can be updated is the Contact address at the far end. That said, proxies must still add a Record-Route header, just to make the protocol more explicit. Is there some other statement in the bis which makes this confusing? Hopefully when this is re-written it will all become clearer. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 15:27:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA02594 for ; Fri, 15 Dec 2000 15:27:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A687444349; Fri, 15 Dec 2000 14:27:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id B8F1544336 for ; Fri, 15 Dec 2000 14:26:58 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 15 Dec 2000 14:26:49 -0600 (CST) From: Billy Biggs To: SIP List Message-ID: <20001215142649.A21485@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii User-Agent: Mutt/1.0.1i Subject: [SIP] Proxy Routing Logic Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 14:26:49 -0600 If a proxy at proxy.com receives a request with a Request-URI of: sip:abc@someone-else.com;maddr=proxy.com Should the proxy: 1. Return a 404. 2. Proxy the message to abc@someone-else.com, ditching the maddr parameter. Now say there is a populated Route header. Should the proxy: 1. Replace the Request-URI with the first Route and proxy. 2. Return a 404. 3. Proxy the message to abc@someone-else.com, ditching the maddr parameter (and not popping the Route). I think it should do 1 for each case. Thoughts? -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 16:12:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17164 for ; Fri, 15 Dec 2000 16:12:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 47EC744339; Fri, 15 Dec 2000 15:12:12 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 30B6144336 for ; Fri, 15 Dec 2000 15:11:16 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Dec 15 16:09:27 EST 2000 Received: by lists.bell-labs.com (Postfix) id F031B44380; Fri, 15 Dec 2000 15:57:19 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id AB1874437D for ; Fri, 15 Dec 2000 15:57:18 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA08842; Fri, 15 Dec 2000 14:57:14 -0600 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA08833; Fri, 15 Dec 2000 14:57:12 -0600 Message-ID: <3A3A8598.76A88C4D@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: jfmule@clarent.com Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Bug in 2543bis-02 re: Record-Route References: <002601c066ce$24bdab80$e54b010a@rwcjfmule01> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 14:56:56 -0600 Content-Transfer-Encoding: 7bit Jean-Francois Mule wrote: > > Independently of the Record-Route discussions, the 2543bis-02 (dated > 11-24-00) has a small issue: > > In the same section 6.35.1 of 2543bis-02, it is stated: > "a request route, once established, persists until the end of the call > leg, *regardless of whether the Record-Route header is present in > subsequent requests.*" Right. > "Note that proxy servers have to add Record-Route headers to each request > *as long as* they want to be "visited" by the next request for the call > leg." > The persistence of the record-route is confusing. The suggestion is to > just remove the note. > > Comments? If I recall correctly, it was done to make the protocol resiliant to UA failures; doing so would insulate a proxy against a UA that may crash and reboot between different requests in the same call. If each proxy adds a R-R header to all requests, the rebooted UA can resurrect the Route list from the R-R's in the request it got after it rebooted. Assuming none of the UA's crash, the route will be established after a successful INVITE transaction; R-R in subsequent requests will be a no-op. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 17:40:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15016 for ; Fri, 15 Dec 2000 17:40:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3BA0944339; Fri, 15 Dec 2000 16:40:12 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 3716F44336 for ; Fri, 15 Dec 2000 16:39:13 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Dec 15 17:37:20 EST 2000 Received: by lists.bell-labs.com (Postfix) id 3F1AB44380; Fri, 15 Dec 2000 17:25:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id E6A4E4437D for ; Fri, 15 Dec 2000 17:25:11 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA03040; Fri, 15 Dec 2000 16:25:09 -0600 Cc: SIP List Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id QAA03032; Fri, 15 Dec 2000 16:25:08 -0600 Message-ID: <3A3A9A32.FEC08328@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Original-CC: SIP List Subject: Re: [SIP] Proxy Routing Logic References: <20001215142649.A21485@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 16:24:50 -0600 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > If a proxy at proxy.com receives a request with a Request-URI of: > > sip:abc@someone-else.com;maddr=proxy.com > > Should the proxy: > > 1. Return a 404. > 2. Proxy the message to abc@someone-else.com, ditching the maddr > parameter. I suppose that if the proxy is reasonably sure that DNS resolution of proxy.com will not resolve to another proxy in that domain, it should do (1). > Now say there is a populated Route header. Should the proxy: > > 1. Replace the Request-URI with the first Route and proxy. > 2. Return a 404. > 3. Proxy the message to abc@someone-else.com, ditching the maddr > parameter (and not popping the Route). Isn't (1) the normal behavior? If a proxy gets a new request with Route headers, it pops the top one off and uses it as the R-URI of the next hop downstream server. Or am I missing something in your question? - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 15 18:25:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25112 for ; Fri, 15 Dec 2000 18:25:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B1CCF44339; Fri, 15 Dec 2000 17:25:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 4893544336 for ; Fri, 15 Dec 2000 17:24:40 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA27011; Fri, 15 Dec 2000 18:24:28 -0500 (EST) Message-ID: <3A3AA82C.BED4E112@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Vijay Gurbani Cc: Billy Biggs , SIP List Subject: Re: [SIP] Proxy Routing Logic References: <20001215142649.A21485@div8.net> <3A3A9A32.FEC08328@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 18:24:28 -0500 Content-Transfer-Encoding: 7bit Vijay Gurbani wrote: > > Billy Biggs wrote: > > > > If a proxy at proxy.com receives a request with a Request-URI of: > > > > sip:abc@someone-else.com;maddr=proxy.com > > > > Should the proxy: > > > > 1. Return a 404. > > 2. Proxy the message to abc@someone-else.com, ditching the maddr > > parameter. > > I suppose that if the proxy is reasonably sure that DNS resolution of > proxy.com will not resolve to another proxy in that domain, it should do (1). As before, it's up to the proxy. If there's some weird reason that a proxy publishes these addresses, it might handle this. An outbound proxy, for example, would be represented by something like that. If the proxy has no intent of proxying random requests, it has the right to send back 404 Huh? > > > Now say there is a populated Route header. Should the proxy: > > > > 1. Replace the Request-URI with the first Route and proxy. > > 2. Return a 404. > > 3. Proxy the message to abc@someone-else.com, ditching the maddr > > parameter (and not popping the Route). > > Isn't (1) the normal behavior? If a proxy gets a new request with Route > headers, it pops the top one off and uses it as the R-URI of the next hop > downstream server. Or am I missing something in your question? I suspect this is about having "weird" URIs in the Route, such as the one above. Again, an outbound proxy could actually see something like that (more reasonable than above). In that case, (1) is the right behavior. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 16 09:22:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18371 for ; Sat, 16 Dec 2000 09:22:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4D0964433F; Sat, 16 Dec 2000 08:22:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lists.bell-labs.com (Postfix) with ESMTP id AF5FA44336 for ; Sat, 16 Dec 2000 08:21:40 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate.mot.com (motgate 2.1) with ESMTP id HAA18530 for ; Sat, 16 Dec 2000 07:21:31 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id HAA01653 for ; Sat, 16 Dec 2000 07:21:31 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Sat, 16 Dec 2000 08:21:30 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8870@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain Subject: [SIP] 8 bit clean channel Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 16 Dec 2000 08:21:28 -0600 Hi What is exactly an 8 bit clean channel? What is a 7 bit channel? Thanjs Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 16 17:28:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA01816 for ; Sat, 16 Dec 2000 17:28:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E89454433D; Sat, 16 Dec 2000 16:28:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1884D44336 for ; Sat, 16 Dec 2000 16:27:06 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA20977; Sat, 16 Dec 2000 17:26:51 -0500 (EST) Message-ID: <3A3BEC2C.1C3607C8@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: William Marshall Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue References: <200012150004.TAA91443@fish-ha.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 16 Dec 2000 17:26:52 -0500 Content-Transfer-Encoding: 7bit While I have some sympathy for allowing the 3-way handshake for REFER, I'm very concerned about the proxy backward compatibility issue. An "old" proxy that thinks REFER is just another non-INVITE and a new UAS that retransmits 200s until it gets an ACK will get not be happy together. (A UAS that doesn't know REFER is likely to respond immediately with a 400 and will likely just dump the ACK, so that variation seems less of a concern.) Thus, we at least need a Proxy-Require An implied SUBSCRIBE (i.e., NOTIFY on state changes) seems like the solution we might have chosen even for INVITE. It requires the least amount of changes, particularly if we just carry the response from the "remote-control" request in the notification as a message/sip. William Marshall wrote: > > I think there is a definite simplification possible here, > if the three-phase-procedure can be dissaciated with INVITE. > That is, to allow the three-phase-procedure for all methods. > > SIP defined two mechanisms for retransmission/reliability. One > (currently used for INVITE) involves a three-way handshake > (INVITE, 200-OK, ACK); and the other (currently used for all > other methods) is a two-way handshake (INVITE, 200-OK). > The major difference, in my opinion, is that the three-way > handshake allows a provisional response, which is not allowed > for such methods as BYE, INFO, SUBSCRIBE, REGISTER, etc (even > though it might be useful). > > I think the changes are relatively simple. All are currently > implemented in the handling of INVITE, and just need to be > made non-INVITE-specific. > > UAC/UAS behavior changes: > > (1) A UAC that receives a 1xx response to any method, MUST send > an ACK when it receives a final response. > > (2) A UAS MUST send a response within some short time limit of > receiving a request, either a final response or a provisional > response. > > (3) If a UAS sends a provisional response, it MUST re-transmit any > final response until receiving an ACK. > > Proxy behavior changes: > > (1) A Proxy MUST forward an ACK to the UAS, regardless of original > request. > > (2) Proxy MUST forward a 100 provisional responses back to the UAC, > except when the proxy generated its own 100 response for the same > request. > > REFER, of course, is the first example of a method that could use > the three-way-handshake other than INVITE. The only reason the > situation didn't arise before (with the Also/Replaces version of > call control) because they were headers added to an INVITE method. > > The main issue is whether this is toooo incompatible with RFC2543. > Proxy point (2) is the only point that is not backwards compatible > with existing devices that conform to RFC2543 and that handle only > existing methods. > > Would this involve significant implementation changes in UAs? > Regardless, I think the contortions needed for REFER are more complex. > > Bill Marshall > wtm@research.att.com > > -----original message----- > From: "Robert Sparks" > To: "Venkatesh Venkataramanan" > Cc: > Subject: RE: [SIP] Solving the REFER retransmit issue > Date: Thu, 14 Dec 2000 11:04:13 -0600 > > If we wanted to use the first two phases of invite, we > must take the third (ACK) with it. The ACK provides > recovery from a lost final response. > > RjS > > > -----Original Message----- > > From: Venkatesh Venkataramanan > > [mailto:venkatesh.venkataramanan@wipro.com] > > Sent: Wednesday, December 13, 2000 11:54 PM > > To: Robert Sparks; sdonovan@dynamicsoft.com; Venkatesh Venkataramanan > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] Solving the REFER retransmit issue > > > > > > Steve: > > I was essentially suggesting the same thing to Robert Spark in an email I > > sent him earlier today except that I missed out mentioning that we don't > > need the "ACK" for the final response received for a REFER !! > > Venkatesh > > ----- Original Message ----- > > From: "Robert Sparks" > > To: "Venkatesh Venkataramanan" > > Sent: Thursday, December 14, 2000 10:22 AM > > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > > > > This has been brought up before and was not well received. Why do you > > > need a three phase transaction for this? Do we want to introduce a > > > whole new state machine to do the first two phases of invite without > > > the third? > > > > > > The opinions I have been hearing to date are to try _very_ hard to > > > find a solution that worked within the existing non-INVITE transaction > > > model. If a good solution can't be found within that constraint, then > > > we start discussing the other options. > > > > > > > -----Original Message----- > > > > From: Venkatesh Venkataramanan > > > > [mailto:Venkatesh.Venkataramanan@sylantro.com] > > > > Sent: Wednesday, December 13, 2000 10:10 PM > > > > To: 'Robert Sparks ' > > > > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > > > > > > > > > Robert: > > > > I am probably missing out something here. Let me try to explain what I > > was > > > > proposing and get your thoughts on this one. > > > > Instead of processing REFER like a BYE request, we should modify the > > REFER > > > > to be processed like an INVITE. The rationale being if REFER is being > > used > > > > for initiating "requests" to make calls and the initiator of the > > > > call wants > > > > to see "call progress", REFER is "like" a 3pcc INVITE. > > > > Use provisionals received by the Invoker of INVITE to be forwarded to > > the > > > > initiator of REFER. The arrival of a provisional stops the timer > > > > (as we have > > > > now modified REFER to be processed like an INVITE). > > > > Venkatesh > > > > > > > > -----Original Message----- > > > > From: Robert Sparks > > > > To: Venkatesh Venkataramanan; sip@lists.bell-labs.com > > > > Sent: 12/13/00 9:31 AM > > > > Subject: RE: [SIP] Solving the REFER retransmit issue > > > > > > > > The problem is that the REFER transaction itself will timeout > > > > if the referred action (INVITE for example) takes longer than > > > > the run of REFER retransmits to complete. > > > > > > > > RjS > > > > > > > > > -----Original Message----- > > > > > From: sip-admin@lists.bell-labs.com > > > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Venkatesh > > > > > Venkataramanan > > > > > Sent: Wednesday, December 13, 2000 3:07 AM > > > > > To: Robert Sparks; sip@lists.bell-labs.com > > > > > Subject: Re: [SIP] Solving the REFER retransmit issue > > > > > > > > > > > > > > > Well, I go back to my suggestion(rather a question I posed > > for Rohan) > > > > of > > > > > forwarding provisionals received for INVITES initiated by > > the UA that > > > > is > > > > > processing the INVITE :-) instead of using an explicit > > > > SUBSCRIBE/NOTIFY > > > > > mechanism. With this approach all the UA would do have to do is to > > > > forward > > > > > any message that it receives in response to an INVITE it > > issued (after > > > > > suitably modifying the callID/From and To fields to match > > the one for > > > > the > > > > > REFER request which triggered this INVITE). Any UA that doesn't want > > > > to > > > > > about what happened to a REFER request it issues could explicitely > > > > specify > > > > > so using the Request-Disposition header (caller preferences). > > > > > Any repercussions with this ? > > > > > Venkatesh > > > > > ----- Original Message ----- > > > > > From: "Robert Sparks" > > > > > To: > > > > > Sent: Tuesday, December 12, 2000 11:23 PM > > > > > Subject: [SIP] Solving the REFER retransmit issue > > > > > > > > > > > > > > > > The presentation of status of REFER and the discussion of the > > > > > > REFER timeout issue is at > > > > > > > > > > > http://www.softarmor.com/sipwg/meets/ietf49/slides/draft-ietf-sip- > > > > cc-transfe > > > > > r-02.htm > > > > > > > > > > Rohan Mahy also proposed an optimization of 2 where the REFER > > > > > was overloaded to also mean SUBSCRIBE - NOTIFYs for the progress > > > > > of the REFERed action would just happen and could be ignored/481'ed > > > > > if the the REFERing agent didn't care. > > > > > > > > > > Jonathan R. stated that 2) requires any agent accepting a REFER to > > > > > implement being an event server (must implement accepting and > > > > > managing subscriptions), and this is asking too much. > > > > > > > > > > Discussion? > > > > > > > > > > RjS > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 17 15:31:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA05540 for ; Sun, 17 Dec 2000 15:31:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E4AE14433D; Sun, 17 Dec 2000 14:31:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 03EE344336 for ; Fri, 15 Dec 2000 18:17:48 -0500 (EST) Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id QAA19650; Fri, 15 Dec 2000 16:17:41 -0800 (PST) Received: from cisco.com (sunithak-lnx.cisco.com [128.107.140.122]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AED02090 (AUTH sunithak); Fri, 15 Dec 2000 16:17:38 -0800 (PST) Message-ID: <3A3AB4A2.1259F4C8@cisco.com> From: Sunitha Kumar Organization: Cisco Systems X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14 i686) X-Accept-Language: en MIME-Version: 1.0 To: tsearle@valhalla.marko.net Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Inteligent Codec Selection References: <20001215103820.A10881@valhalla.marko.net> Content-Type: multipart/alternative; boundary="------------2FD462268425A1800A835DB4" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 15 Dec 2000 16:17:38 -0800 --------------2FD462268425A1800A835DB4 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit check out draft-manyfolks-sip-resource-01.txt. it talks about resource reservation. tsearle@valhalla.marko.net wrote: > I would like to set up a SIP solution that would negotiate to use G.711 > if there is sufficient bandwith between the two endpoints to do so, and would > negotiate G.723.1 otherwise. > > Is there any way to do codec negotiation in such a manner? > > Torrey > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Sunitha Kumar http://www.cisco.com --------------2FD462268425A1800A835DB4 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit check out draft-manyfolks-sip-resource-01.txt.
it talks about resource reservation.
 
 
 

tsearle@valhalla.marko.net wrote:

I would like to set up a SIP solution that would negotiate to use G.711
if there is sufficient bandwith between the two endpoints to do so, and would
negotiate G.723.1 otherwise.

Is there any way to do codec negotiation in such a manner?

Torrey

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Sunitha Kumar
http://www.cisco.com
  --------------2FD462268425A1800A835DB4-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 17 15:47:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA07244 for ; Sun, 17 Dec 2000 15:47:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D77644351; Sun, 17 Dec 2000 14:47:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.202.49]) by lists.bell-labs.com (Postfix) with ESMTP id D40C24434E for ; Sun, 17 Dec 2000 14:46:31 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id MAA07847 for ; Sun, 17 Dec 2000 12:55:08 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 From: David Shrader To: SIP List Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [SIP] Record-Route and REGISTER Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 17 Dec 2000 15:40:27 -0500 Content-Transfer-Encoding: 7bit I've been reading the record-route material and am considering its general application to SIP requests and find that there it is not as general as we think. The mechanism described in the bis-02 relies on the interpretation of the Contact header only for some messages. That is, the text states that the Contact header, if included, is appended to the Route list. This assumes that the Contact header is used only to represent the party to which a subsequent request along that route would be sent. When using the REGISTER method, however, the Contact header is NOT used for that purpose. The Contact header in the Response to a REGISTER is simply a list of registered contacts and does not in fact identify the recipient of a subsequent request. Scenario that generated this problem: 1. REGISTER is sent from UAC to an outbound proxy, addressed to a service provider (i.e., sip:provider.net) 2. The proxy inserts a Record-Route header into the REGISTER message and routes it to the host for sip:provider.net. 3. The server then echoes the Record-Route header in the response and several registered Contact headers. 4. The UAC then receives the Record-Route. When it attempts to refresh its reservation, it cannot follow the rules in the bis-02 spec because the Contact header cannot be used as a Route header in this case. The message will never get to the registrar server because the Request-URI would indicate the received record-route header and there is no header to include the sip:provider.net URI. Any thoughts on a solution? I've thought it strange that the UAC is expected to add the received Contact header to the Route list. Perhaps the solution is really that the UAS receiving the Record-Route header should add its own Contact as the final Record-Route. In that way, the UAC doesn't have to do anything at all and there is no ambiguity due to the overloading of Contact header that we have done in the spec. ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 17 18:01:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA25614 for ; Sun, 17 Dec 2000 18:01:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9535A4433D; Sun, 17 Dec 2000 17:01:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from elektron.elka.pw.edu.pl (elektron.elka.pw.edu.pl [194.29.160.2]) by lists.bell-labs.com (Postfix) with ESMTP id 6970244336 for ; Sun, 17 Dec 2000 17:00:09 -0500 (EST) Received: from po155.warszawa.cvx.ppp.tpnet.pl ([213.76.110.155]:2877 "EHLO elka.pw.edu.pl") by elektron.elka.pw.edu.pl with ESMTP id ; Sun, 17 Dec 2000 23:59:44 +0100 Message-ID: <3A3D4559.B16BF398@elka.pw.edu.pl> From: "Piotr S. Kossowski" Organization: Warsaw University of Technology - Institute of Telecommunications X-Mailer: Mozilla 4.7 [pl] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: SIP discussion list Content-Type: text/plain; charset=iso-8859-2 Content-Transfer-Encoding: 7bit Subject: [SIP] State transition diagram for INVITE Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 17 Dec 2000 23:59:37 +0100 Content-Transfer-Encoding: 7bit Dear All, I'm a bit confused after long studying of Figure 12 of the 2543 spec. There is State Machine for INVITE method there. I'm especially interested in two states: CONFIRMED and COMPLETED. Please, correct me if I am wrong: Being in FAILURE or SUCCESS we can proceed to COMPLETED under one condition: 32 second of inactivity (no requests from UAC). Within 32 s. the state machine is waiting for ACK. If no ACK, it probably means that something must have happend to UAC, and "for sure" the Call is lost. So, COMPLETED state is common for FAILURE and SUCCESS and simply means "forget this call". Hovewer, if ACK for SUCCESS call (200 OK was sent) appears State Machine procceds to CONFIRMED state and then ALWAYS after 32 s. to the COMPLETED (call established, transaction successfully finalized) Thus, My question is: 1. Does COMPLETED mean realy two states: either COMPLETED_SUCCESS or COMPLETED_FAILURE? If yes, Maybe lack of ACK witihin 32s in SUCCESS state allows machine to procceed to COMPLETED_SUCCESS ?! 2. What for is CONFIRMED state in fact ? No action is generated on ACK in this state, and no (?) "call specific variables" are changed on "32s" transtition to COMPLETED. And my last issue. Let's consider the following scenario: We are currently in SUCCCESS state. So, we are waiting for ACK. Sometimes, we can receive a lost INVITE - we treat it as a retransmission and we send, what we have just sent - 200 OK. But, according to 4.2.1 (INVITE description), we must regard this transaction as COMPLETED or, at least, we are not allowed to response with "400 Bad Request" if we have just received another INVITE (re-INVITE). If this is true, such re-INVITE should invoke new instance of state machine. (or something else should happend, correct me) For one call, we have now two state machines. Let the second machine work. Meanwhile, 32s timeout expired and the first machine transited to COMPLETED. Beacause I don't know (as mentioned above) what COMPLETED really means, my question is: what may (should, must) happen then: - Behaviour the first machine is irrelevant ("the newest" machine "hide" all the previous) - The second machine should be stopped, because the call was broken down. The call is being destroyed. - something else ? Thanks in advance for your ideas, Piotr _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 17 21:03:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA18758 for ; Sun, 17 Dec 2000 21:03:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E67D74433D; Sun, 17 Dec 2000 20:03:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtp-out1.bellatlantic.net (unknown [199.45.40.143]) by lists.bell-labs.com (Postfix) with ESMTP id BCCFE44336 for ; Sun, 17 Dec 2000 20:02:16 -0500 (EST) Received: from cs.columbia.edu (adsl-151-198-20-48.nnj.adsl.bellatlantic.net [151.198.20.48]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id VAA00686; Sun, 17 Dec 2000 21:00:39 -0500 (EST) Message-ID: <3A3D6FB1.7B704827@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] 8 bit clean channel References: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8870@il27exm02.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 17 Dec 2000 21:00:18 -0500 Content-Transfer-Encoding: 7bit Baniel Uri-CUB001 wrote: > > Hi > > What is exactly an 8 bit clean channel? What is a 7 bit channel? TCP. Email. > > Thanjs > > Uri > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 17 22:15:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA20107 for ; Sun, 17 Dec 2000 22:15:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D1A414433D; Sun, 17 Dec 2000 21:15:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4B94E44336 for ; Sun, 17 Dec 2000 21:14:14 -0500 (EST) Received: from athletics (cf9e4162.dfw53.dsl.airmail.net [207.158.65.98]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id WAA01324; Sun, 17 Dec 2000 22:16:22 -0500 (EST) From: "Steve Donovan" To: "Baniel Uri-CUB001" , "'Neil Deason'" , , , Subject: RE: [SIP] Proxies modifying SDP 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.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8866@il27exm02.cig.mot.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 17 Dec 2000 21:11:56 -0600 Content-Transfer-Encoding: 7bit Although I am having a hard time understanding why it would be necessary to modify the SDP to cause the call to go through a specific gateway, as Neil correctly points out, this is likely to be a function of a back-to-back UA. Why is it not enough to have the proxy route the call to the gateway in question by changing the request-URI to point to the gateway? Steve > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Baniel Uri-CUB001 > Sent: Friday, December 15, 2000 1:51 PM > To: 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; > sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > I see it as the requested way of forcing the media stream to go > via an 'IP switch' (like the H323 MCU). > If a proxy server is not allowed or if it is not appropriate for > it to touch the SDP element, then is there any other way to make > sure the media stream goes via our MCU gateway. (There could be > various of reasons why we would want to have such a gateway) > > What do u think? > > Uri > > -----Original Message----- > From: Neil Deason [mailto:neil_deason@hotmail.com] > Sent: Friday, December 15, 2000 12:30 PM > To: jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > > >Bernie Hoeneisen wrote: > > > I have question concerning the case, when SIP proxies modify SDP, > > > which is AFAIK against SIP principles, isn't it? > >I do not think so. > >Why is that *against* SIP principles? What principles?' > > The fundamental concept that payloads are opaque to SIP Proxy > Servers. To do this sort of thing you probably want to use a > back to back UA. > > Cheers, > Neil. > -- > Ubiquity Software, UK www.ubiquity.net > > > > In the concrete case, proxies would be able to remove certain codecs > > > from the INVITE messages, depending on the current policy in the > > > network. (The UAS gets a subset of the codecs, which were originally > > > sent by the UAC.) > > > What impact does such a proxy behavior have to SIP? I can think of > > > problems with authentication and message integrity checking (UAC signs > > > message with its private key). > >It certainly depends on the security mechanism used. For e.g., with the > >simple basic md5, it does not cause any issue. > > > >Jean-Francois > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 03:29:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06436 for ; Mon, 18 Dec 2000 03:29:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5D5784433D; Mon, 18 Dec 2000 02:29:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mgw-x3.nokia.com (mgw-x3.nokia.com [131.228.20.26]) by lists.bell-labs.com (Postfix) with ESMTP id 76DB544336 for ; Mon, 18 Dec 2000 02:28:40 -0500 (EST) Received: from esvir10nok.nokia.com (esvir10nokt.ntc.nokia.com [172.21.143.42]) by mgw-x3.nokia.com (8.10.2/8.10.2/Nokia) with ESMTP id eBI8SJB15357 for ; Mon, 18 Dec 2000 10:28:19 +0200 (EET) Received: from esebh11nok.ntc.nokia.com (unverified) by esvir10nok.nokia.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 18 Dec 2000 10:28:19 +0200 Received: from loki.research.nokia.com ([172.21.33.76]) by esebh11nok.ntc.nokia.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.78) id Y7MQTKGX; Mon, 18 Dec 2000 10:28:19 +0200 Received: from kurma.research.nokia.com (IDENT:root@kurma.research.nokia.com [172.21.40.103]) by loki.research.nokia.com (8.9.3/8.9.3) with ESMTP id KAA28296; Mon, 18 Dec 2000 10:28:18 +0200 (EET) Received: (from ppessi@localhost) by kurma.research.nokia.com (8.9.3/8.9.3) id KAA05049; Mon, 18 Dec 2000 10:29:42 +0200 X-Authentication-Warning: kurma.research.nokia.com: ppessi set sender to Pekka.Pessi@nokia.com using -f To: Cc: Gonzalo Camarillo Subject: Re: [SIP] RE: Changin local RTP port without a good reason References: <3A3989CA.8F5E7117@lmf.ericsson.se> <3A3989CA.8F5E7117@lmf.ericsson.se> X-face: #V(jdpv[lI!TNUU=2*oh:="#suS*ponXW"yr6G;~L}uZ\JfD\"IG#G{j`hZI;=DmT\H pfDMyJ`i=:M;BM3R.`[>P^ER8+]i From: Pekka Pessi In-Reply-To: "Gonzalo Camarillo"'s message of "Fri, 15 Dec 2000 05:02:34 +0200" Message-ID: Lines: 17 User-Agent: Gnus/5.0806 (Gnus v5.8.6) XEmacs/21.1 (Capitol Reef) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 18 Dec 2000 10:29:42 +0200 In message <3A3989CA.8F5E7117@lmf.ericsson.se> "ext Gonzalo Camarillo" writes: >Of course that sometimes you have to change your local configuration if >the remote configuration changes... but there has to be a good reason >(like a change of codecs). When you issue a re-INVITE with a new local port number, you are proposing a new RTP session. The remote end can not distinguish between packets in the old session and new session, unless it changes its RTP port, too. >If my local configuration is too dependant on the other party's >configuration the negotiation ends up in an infinite loop. There is always a request and a corresponsing response. Depending on previous response is not sensible, in my opinion. Pekka _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 05:14:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07160 for ; Mon, 18 Dec 2000 05:14:37 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 78F444433D; Mon, 18 Dec 2000 04:12:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis29.marconicomms.com (cvis29.marconicomms.com [195.99.244.61]) by lists.bell-labs.com (Postfix) with ESMTP id 2A12C44336 for ; Mon, 18 Dec 2000 04:11:24 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis29.marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 18 Dec 2000 10:09:03 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id KAA00363; Mon, 18 Dec 2000 10:09:03 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569B9.0037C429 ; Mon, 18 Dec 2000 10:09:06 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Billy Biggs Cc: Jean-Francois Mule , Billy Biggs Message-ID: <802569B9.0037C376.00@marconicomms.com> Subject: Re: [SIP] Bug in 2543bis-02 re: Record-Route Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 10:08:47 +0000 I believe that the way the text on the construction of the Route headers is worded will lead to faulty behaviour as follows: In 6.35.2 (construction of Route header) the text says "A UA builds the Route header field for subsequent requests from the Record-Route header fields received in either a response or a request" This implies that a UA will build a new Route every time a Record-Route header is present in a request or a response, not just for the initial INVITE. Therefore, coupled with the prior text about a proxy adding itself to every request is only SHOULD not MUST, a proxy which assumes that the Route will persist until the end of call leg and doesn't add itself to subsequent requests will be excluded from the path if other proxies do add themselves on subsequent requests thereby causing a UA to reconstruct the Route header, which would break the rule that the path is persistent until the end of the call leg. That said, I have read other memos on the list (can't remember which, but they are there) where the author has implied that a proxy can take itself out of the path, which in the above scenario would be by excluding itself on subsequent requests. Perhaps there are two interpretations out there, one where a proxy stays in for good and one where a proxy stays in until it excludes itself; whichever is correct, the spec is ambiguous as it seems to try and support both at the same time. It can't, its one or the other. Regards, K. Robinson Billy Biggs on 15/12/2000 19:52:14 To: Jean-Francois Mule cc: Billy Biggs (bcc: Keith Robinson/MAIN/MC1) Subject: Re: [SIP] Bug in 2543bis-02 re: Record-Route Jean-Francois Mule (jfmule@clarent.com): > Independently of the Record-Route discussions, the 2543bis-02 (dated > 11-24-00) has a small issue: > > In the same section 6.35.1 of 2543bis-02, it is stated: > "a request route, once established, persists until the end of the call > leg, *regardless of whether the Record-Route header is present in > subsequent requests.*" > ... > "Note that proxy servers have to add Record-Route headers to each > request *as long as* they want to be "visited" by the next request for > the call leg." The persistence of the record-route is confusing. The > suggestion is to just remove the note. The statement is correct: The Route persists until the end of the call leg regardless. Proxies may not ever leave the Route for a call-leg. The only thing that can be updated is the Contact address at the far end. That said, proxies must still add a Record-Route header, just to make the protocol more explicit. Is there some other statement in the bis which makes this confusing? Hopefully when this is re-written it will all become clearer. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 05:24:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07209 for ; Mon, 18 Dec 2000 05:24:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A72944351; Mon, 18 Dec 2000 04:24:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id E1C4644350 for ; Mon, 18 Dec 2000 04:23:59 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 18 Dec 2000 10:23:50 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA15643; Mon, 18 Dec 2000 10:22:24 GMT Message-ID: <3A3DE55E.E4D2991C@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Keith Robinson Cc: Billy Biggs , Jean-Francois Mule , sip@lists.bell-labs.com Subject: Re: [SIP] Bug in 2543bis-02 re: Record-Route References: <802569B9.0037C376.00@marconicomms.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 10:22:22 +0000 Content-Transfer-Encoding: 7bit I wouldn't pay too much attention to the present Record-Route text. This problem area was discussed in some detail at the recent bakeoff + IETF. There should shortly be revised text from Jonathan R which will be simpler, cleaner and work. Cheers, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net Keith Robinson wrote: > > I believe that the way the text on the construction of the Route headers is > worded will lead to > faulty behaviour as follows: > > In 6.35.2 (construction of Route header) the text says > > "A UA builds the Route header field for subsequent requests from the > Record-Route header fields > received in either a response or a request" > > This implies that a UA will build a new Route every time a Record-Route header > is present in > a request or a response, not just for the initial INVITE. Therefore, coupled > with the prior text > about a proxy adding itself to every request is only SHOULD not MUST, a proxy > which assumes that > the Route will persist until the end of call leg and doesn't add itself to > subsequent requests will be > excluded from the path if other proxies do add themselves on subsequent requests > thereby causing > a UA to reconstruct the Route header, which would break the rule that the path > is persistent until the > end of the call leg. > > That said, I have read other memos on the list (can't remember which, but they > are there) where the author > has implied that a proxy can take itself out of the path, which in the above > scenario would be by excluding > itself on subsequent requests. > > Perhaps there are two interpretations out there, one where a proxy stays in for > good and one where a > proxy stays in until it excludes itself; whichever is correct, the spec is > ambiguous as it seems to try and > support both at the same time. It can't, its one or the other. > > Regards, > > K. Robinson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 06:02:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07382 for ; Mon, 18 Dec 2000 06:02:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 20E334434F; Mon, 18 Dec 2000 05:02:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by lists.bell-labs.com (Postfix) with ESMTP id B8D9B44336 for ; Mon, 18 Dec 2000 05:01:46 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Mon, 18 Dec 2000 11:02:54 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id LAA24611; Mon, 18 Dec 2000 11:01:33 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569B9.003C94BC ; Mon, 18 Dec 2000 11:01:42 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Billy Biggs Cc: SIP List Message-ID: <802569B9.003C9277.00@marconicomms.com> Subject: Re: [SIP] Proxy Routing Logic Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 11:01:19 +0000 For the first case, couldn't this be the result of a roaming UA using source routing to get the initial INVITE to its home domain proxy to do the actual routing (perhaps the user has originating call features registered that they wish to use); in which case I would expect the behaviour in 2 to take place. Regards, K. Robinson. Billy Biggs on 15/12/2000 20:26:49 To: SIP List cc: (bcc: Keith Robinson/MAIN/MC1) Subject: [SIP] Proxy Routing Logic If a proxy at proxy.com receives a request with a Request-URI of: sip:abc@someone-else.com;maddr=proxy.com Should the proxy: 1. Return a 404. 2. Proxy the message to abc@someone-else.com, ditching the maddr parameter. Now say there is a populated Route header. Should the proxy: 1. Replace the Request-URI with the first Route and proxy. 2. Return a 404. 3. Proxy the message to abc@someone-else.com, ditching the maddr parameter (and not popping the Route). I think it should do 1 for each case. Thoughts? -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 09:21:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA08904 for ; Mon, 18 Dec 2000 09:21:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3AE724434E; Mon, 18 Dec 2000 08:21:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3BEA144336 for ; Mon, 18 Dec 2000 08:20:52 -0500 (EST) Received: from redball.dynamicsoft.com (dsl081-162-189-sea1.dsl-isp.net [64.81.162.189]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id JAA02842; Mon, 18 Dec 2000 09:22:39 -0500 (EST) From: bcampbell@dynamicsoft.com Message-Id: <200012181422.JAA02842@redball.dynamicsoft.com> To: "Steve Donovan" , "Baniel Uri-CUB001" , "Neil Deason" , , , Subject: RE: [SIP] Proxies modifying SDP MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_unique-boundary-1" Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 14:18 -0000 ------=_unique-boundary-1 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7BIT I suspect the original writer refers to some sort of media gateway that is not SIP enabled. Therefore one could not simply proxy the call to the gateway. ----Original Message----- >From: Steve Donovan >To: Baniel Uri-CUB001 ; 'Neil Deason' ; ; ; >Cc: >Subj: RE: [SIP] Proxies modifying SDP >Reply To: >Sent: Sunday, December 17, 2000 9:13 PM > >Although I am having a hard time understanding why it would be necessary to >modify the SDP to cause the call to go through a specific gateway, as Neil >correctly points out, this is likely to be a function of a back-to-back UA. > >Why is it not enough to have the proxy route the call to the gateway in >question by changing the request-URI to point to the gateway? > >Steve > >> -----Original Message----- >> From: sip-admin@lists.bell-labs.com >> [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Baniel Uri-CUB001 >> Sent: Friday, December 15, 2000 1:51 PM >> To: 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; >> sip@lists.bell-labs.com >> Subject: RE: [SIP] Proxies modifying SDP >> >> >> I see it as the requested way of forcing the media stream to go >> via an 'IP switch' (like the H323 MCU). >> If a proxy server is not allowed or if it is not appropriate for >> it to touch the SDP element, then is there any other way to make >> sure the media stream goes via our MCU gateway. (There could be >> various of reasons why we would want to have such a gateway) >> >> What do u think? >> >> Uri >> >> -----Original Message----- >> From: Neil Deason [mailto:neil_deason@hotmail.com] >> Sent: Friday, December 15, 2000 12:30 PM >> To: jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com >> Subject: RE: [SIP] Proxies modifying SDP >> >> >> >> >Bernie Hoeneisen wrote: >> > > I have question concerning the case, when SIP proxies modify SDP, >> > > which is AFAIK against SIP principles, isn't it? >> >I do not think so. >> >Why is that *against* SIP principles? What principles?' >> >> The fundamental concept that payloads are opaque to SIP Proxy >> Servers. To do this sort of thing you probably want to use a >> back to back UA. >> >> Cheers, >> Neil. >> -- >> Ubiquity Software, UK www.ubiquity.net >> >> > > In the concrete case, proxies would be able to remove certain codecs >> > > from the INVITE messages, depending on the current policy in the >> > > network. (The UAS gets a subset of the codecs, which were originally >> > > sent by the UAC.) >> > > What impact does such a proxy behavior have to SIP? I can think of >> > > problems with authentication and message integrity checking (UAC signs >> > > message with its private key). >> >It certainly depends on the security mechanism used. For e.g., with the >> >simple basic md5, it does not cause any issue. >> > >> >Jean-Francois >> >> _______________________________________________________________________ __ >> Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. >> >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip >> > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > ------=_unique-boundary-1-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 10:23:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09671 for ; Mon, 18 Dec 2000 10:23:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 239C64433D; Mon, 18 Dec 2000 09:23:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (bounty.cisco.com [161.44.3.204]) by lists.bell-labs.com (Postfix) with ESMTP id AC76544336 for ; Mon, 18 Dec 2000 09:22:02 -0500 (EST) Received: from cisco.com (rtp-xdm1.cisco.com [161.44.3.80]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA18709; Mon, 18 Dec 2000 10:21:16 -0500 (EST) Message-ID: <3A3E2B80.F4A5E230@cisco.com> From: Manoj Bhatia Organization: Cisco Systems, RTP, NC, USA. X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Sunitha Kumar Cc: tsearle@valhalla.marko.net, sip@lists.bell-labs.com Subject: Re: [SIP] Inteligent Codec Selection References: <20001215103820.A10881@valhalla.marko.net> <3A3AB4A2.1259F4C8@cisco.com> Content-Type: multipart/alternative; boundary="------------9FAD26426004946BB0893E39" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 10:21:36 -0500 --------------9FAD26426004946BB0893E39 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Even if you use , manyfolks draft for SIP /QOS reservations and figure out that you need to switch to G.723 from G.711 , you would still need a re-INVITE/mid-call INVITE mechanism to trigger the event. Sunitha Kumar wrote: > check out draft-manyfolks-sip-resource-01.txt. > it talks about resource reservation. > > > > > tsearle@valhalla.marko.net wrote: > >> I would like to set up a SIP solution that would negotiate to use >> G.711 >> if there is sufficient bandwith between the two endpoints to do so, >> and would >> negotiate G.723.1 otherwise. >> >> Is there any way to do codec negotiation in such a manner? >> >> Torrey >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Sunitha Kumar > http://www.cisco.com > > -- Manoj Bhatia | | | manojb@cisco.com | :|: :|: 7025 Kit Creek Road, RTP, NC - 27709 | :|||||: :|||||: Ph: 919-392-3873 Fax:919-392-6801 | C i s c o S y s t e m s --------------9FAD26426004946BB0893E39 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Even if you use , manyfolks draft for SIP /QOS reservations and figure
out that you need to switch to G.723 from G.711 , you would still
need a re-INVITE/mid-call INVITE mechanism to trigger
the event.
 

Sunitha Kumar wrote:

check out draft-manyfolks-sip-resource-01.txt.
it talks about resource reservation.
 
 
 

tsearle@valhalla.marko.net wrote:

I would like to set up a SIP solution that would negotiate to use G.711
if there is sufficient bandwith between the two endpoints to do so, and would
negotiate G.723.1 otherwise.

Is there any way to do codec negotiation in such a manner?

Torrey

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

-- 
Sunitha Kumar
http://www.cisco.com
 
-- 
Manoj Bhatia                           |        |         |
manojb@cisco.com                       |       :|:       :|:
7025 Kit Creek Road, RTP, NC - 27709   |     :|||||:   :|||||:
Ph: 919-392-3873  Fax:919-392-6801     |  C i s c o S y s t e m s
  --------------9FAD26426004946BB0893E39-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 11:31:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10586 for ; Mon, 18 Dec 2000 11:31:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A962A4433D; Mon, 18 Dec 2000 10:31:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zcars04f.ca.nortel.com (h57s242a129n47.user.nortelnetworks.com [47.129.242.57]) by lists.bell-labs.com (Postfix) with ESMTP id E4A0344336 for ; Mon, 18 Dec 2000 10:30:22 -0500 (EST) Received: from zcard015.ca.nortel.com by zcars04f.ca.nortel.com; Mon, 18 Dec 2000 11:23:59 -0500 Received: by zcard015.ca.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 18 Dec 2000 11:24:01 -0500 Message-ID: <28560036253BD41191A10000F8BCBD11032E6292@zcard00g.ca.nortel.com> From: "Tom-PT Taylor" To: Henning Schulzrinne , Baniel Uri-CUB001 Cc: "'sip@lists.bell-labs.com'" Subject: RE: [SIP] 8 bit clean channel MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0690E.ED313EA0" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 11:23:59 -0500 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_01C0690E.ED313EA0 Content-Type: text/plain; charset="iso-8859-1" Henning, no one can accuse you of being a Bell-head! The terminology comes from the TDM network, where sometimes the user gets to use all 64000 bits/second (8 bits x 8000 samples per second), and sometimes network equipment steals the low-order bit for low-level signalling (hence the user only gets 7 bits per sample). In ISDN signalling it is at least possible to ask for 64 kbit/s clear channel (8 bit clean channel), but you won't necessarily get it. > -----Original Message----- > From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] > Sent: Sunday, December 17, 2000 9:00 PM > To: Baniel Uri-CUB001 > Cc: 'sip@lists.bell-labs.com' > Subject: Re: [SIP] 8 bit clean channel > > > > > Baniel Uri-CUB001 wrote: > > > > Hi > > > > What is exactly an 8 bit clean channel? What is a 7 bit channel? > > TCP. Email. > > > > > Thanjs > > > > Uri > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > ------_=_NextPart_001_01C0690E.ED313EA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] 8 bit clean channel

Henning, no one can accuse you of being a = Bell-head!  The terminology comes from the TDM network, where = sometimes the user gets to use all 64000 bits/second (8 bits x 8000 = samples per second), and sometimes network equipment steals the = low-order bit for low-level signalling (hence the user only gets 7 bits = per sample).  In ISDN signalling it is at least possible to ask = for 64 kbit/s clear channel (8 bit clean channel), but you won't = necessarily get it.

> -----Original Message-----
> From: Henning Schulzrinne [mailto:schulzrinne@cs.columb= ia.edu]
> Sent: Sunday, December 17, 2000 9:00 PM
> To: Baniel Uri-CUB001
> Cc: 'sip@lists.bell-labs.com'
> Subject: Re: [SIP] 8 bit clean channel
>
>
>
>
> Baniel Uri-CUB001 wrote:
> >
> > Hi
> >
> > What is exactly an 8 bit clean channel? = What is a 7 bit channel?
>
> TCP. Email.
>
> >
> > Thanjs
> >
> > Uri
> >
> > = _______________________________________________
> > SIP mailing list
> > SIP@lists.bell-labs.com
> > http://lists.bell-labs.com/mailman/listinfo/sip
>
> = _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

------_=_NextPart_001_01C0690E.ED313EA0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 12:18:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11490 for ; Mon, 18 Dec 2000 12:18:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AA36144364; Mon, 18 Dec 2000 11:18:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from smtp4.cluster.oleane.net (smtp4.cluster.oleane.net [195.25.12.62]) by lists.bell-labs.com (Postfix) with ESMTP id C524E4435D for ; Mon, 18 Dec 2000 11:17:43 -0500 (EST) Received: from oleane (dyn-1-1-242.Vin.dialup.oleane.fr [195.25.4.242]) by smtp4.cluster.oleane.net with SMTP id eBIHHk582959 for ; Mon, 18 Dec 2000 18:17:46 +0100 (CET) Message-ID: <00a701c06916$ac3ab720$8001a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A4_01C0691F.0DAB32C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: [SIP] International SIP 2001 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 18:19:25 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_00A4_01C0691F.0DAB32C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The International SIP 2001 programme is online. The event will take = place next February 20 to 23, in Paris. Visit the first SIP Exhibition. Please get more details at: http://www.upperside.fr/baintersip.htm =20 ------=_NextPart_000_00A4_01C0691F.0DAB32C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The International SIP 2001=20 programme is online. The event will take place next February 20 = to 23,=20 in Paris.
Visit the first SIP = Exhibition.
Please get more details = at:
http://www.upperside.fr/b= aintersip.htm
 
 
------=_NextPart_000_00A4_01C0691F.0DAB32C0-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 12:23:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA11608 for ; Mon, 18 Dec 2000 12:23:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BE1EA4436D; Mon, 18 Dec 2000 11:23:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.comdial.com (temp.comdial.com [198.232.235.241]) by lists.bell-labs.com (Postfix) with SMTP id E6BDC4436C for ; Mon, 18 Dec 2000 11:22:22 -0500 (EST) Received: FROM MAIL_1 BY mail.comdial.com ; Mon Dec 18 12:22:12 2000 -0500 Received: by MAIL_1 with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 12:19:18 -0500 Message-ID: <1D2D2C552C4CD4118BC50006293834D72411E6@MAIL_1> From: "Wamorkar, Vivek" To: "'sip@lists.bell-labs.com'" Cc: "Zenone, Bruce" , "Wamorkar, Vivek" , "Rigaldies, Bertrand" , "Lancaster, Cary" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Recovery mechanism for UA Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 12:19:17 -0500 What is the defined recovery mechanism for a User Agent if UA reboots and wants to rejoin the existing session. Assuming that UA fails to successfully log the session details. Given that proxy is stateful, can UA query the proxy for its existing session. -Comdial Research team. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 14:08:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA13296 for ; Mon, 18 Dec 2000 14:08:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C3C994433D; Mon, 18 Dec 2000 13:08:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web1102.mail.yahoo.com (web1102.mail.yahoo.com [128.11.23.122]) by lists.bell-labs.com (Postfix) with SMTP id 4BFF144336 for ; Mon, 18 Dec 2000 13:07:40 -0500 (EST) Received: (qmail 3352 invoked by uid 60001); 18 Dec 2000 19:07:30 -0000 Message-ID: <20001218190730.3351.qmail@web1102.mail.yahoo.com> Received: from [132.208.135.60] by web1102.mail.yahoo.com; Mon, 18 Dec 2000 20:07:30 CET From: =?iso-8859-1?q?rufin=20soh?= To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Re: SIP digest, Vol 1 #620 - 10 msgs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 20:07:30 +0100 (CET) Content-Transfer-Encoding: 8bit I think for my own that, since proxies and sip servers are not completely implemented, after a 200 proxy response, a UAS, instead of using codecs, should better choose a well known (by proxy)frequency, to send medias. If not, proxy will remain in a waiting state, or all the responses could be handled as "UNKNOWN RESPONSE".According to my fsm implementation, such responses are removed or just forwarded without any further process, untill timeout. --- sip-request@lists.bell-labs.com a écrit : > Send SIP mailing list submissions to > sip@lists.bell-labs.com > > To subscribe or unsubscribe via the World Wide Web, > visit > http://lists.bell-labs.com/mailman/listinfo/sip > or, via email, send a message with subject or body > 'help' to > sip-request@lists.bell-labs.com > > You can reach the person managing the list at > sip-admin@lists.bell-labs.com > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of SIP digest..." > > > Today's Topics: > > 1. Re: Inteligent Codec Selection (Sunitha Kumar) > 2. Record-Route and REGISTER (David Shrader) > 3. State transition diagram for INVITE (Piotr S. > Kossowski) > 4. Re: 8 bit clean channel (Henning Schulzrinne) > 5. RE: Proxies modifying SDP (Steve Donovan) > 6. Re: RE: Changin local RTP port without a good > reason (Pekka Pessi) > 7. Re: Bug in 2543bis-02 re: Record-Route (Keith > Robinson) > 8. Re: Bug in 2543bis-02 re: Record-Route (Neil > Deason) > 9. Re: Proxy Routing Logic (Keith Robinson) > 10. RE: Proxies modifying SDP > (bcampbell@dynamicsoft.com) > > ATTACHMENT part 3.1 message/rfc822 > Date: Fri, 15 Dec 2000 16:17:38 -0800 > De: Sunitha Kumar > Affiliation: Cisco Systems > À: tsearle@valhalla.marko.net > CC: sip@lists.bell-labs.com > Objet: Re: [SIP] Inteligent Codec Selection > > check out draft-manyfolks-sip-resource-01.txt. > it talks about resource reservation. > > > > > tsearle@valhalla.marko.net wrote: > > > I would like to set up a SIP solution that would > negotiate to use G.711 > > if there is sufficient bandwith between the two > endpoints to do so, and would > > negotiate G.723.1 otherwise. > > > > Is there any way to do codec negotiation in such a > manner? > > > > Torrey > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Sunitha Kumar > http://www.cisco.com > > > > ATTACHMENT part 3.2 message/rfc822 > Date: Sun, 17 Dec 2000 15:40:27 -0500 > De: David Shrader > À: SIP List > Objet: [SIP] Record-Route and REGISTER > > I've been reading the record-route material and am > considering its general > application to SIP requests and find that there it > is not as general as we > think. > > The mechanism described in the bis-02 relies on the > interpretation of the > Contact header only for some messages. That is, the > text states that the > Contact header, if included, is appended to the > Route list. This assumes > that the Contact header is used only to represent > the party to which a > subsequent request along that route would be sent. > > When using the REGISTER method, however, the Contact > header is NOT used for > that purpose. The Contact header in the Response to > a REGISTER is simply a > list of registered contacts and does not in fact > identify the recipient of a > subsequent request. > > Scenario that generated this problem: > 1. REGISTER is sent from UAC to an outbound > proxy, addressed to a > service provider (i.e., sip:provider.net) > 2. The proxy inserts a Record-Route header into > the REGISTER message and > routes it to the host for sip:provider.net. > 3. The server then echoes the Record-Route > header in the response and > several registered Contact headers. > 4. The UAC then receives the Record-Route. When > it attempts to refresh > its reservation, it cannot follow the rules > in the bis-02 spec > because the Contact header cannot be used as > a Route header in this > case. The message will never get to the > registrar server because the > Request-URI would indicate the received > record-route header and > there is no header to include the > sip:provider.net URI. > > Any thoughts on a solution? > > I've thought it strange that the UAC is expected to > add the received Contact > header to the Route list. Perhaps the solution is > really that the UAS > receiving the Record-Route header should add its own > Contact as the final > Record-Route. In that way, the UAC doesn't have to > do anything at all and > there is no ambiguity due to the overloading of > Contact header that we have > done in the spec. > > > ---------------------------- > David Shrader > Master Consultant, Inc. > dshrader@master-consultant.com > http://www.EyeForTheFuture.com > > > > ATTACHMENT part 3.3 message/rfc822 > Date: Sun, 17 Dec 2000 23:59:37 +0100 > De: "Piotr S. Kossowski" > > Affiliation: Warsaw University of Technology - > Institute of Telecommunications > À: SIP discussion list > Objet: [SIP] State transition diagram for INVITE > > Dear All, > > I'm a bit confused after long studying of Figure 12 > of the 2543 spec. > There is State Machine for INVITE method there. > I'm especially interested in two states: CONFIRMED > and COMPLETED. > > Please, correct me if I am wrong: > Being in FAILURE or SUCCESS we can proceed to > COMPLETED under one > condition: 32 second of inactivity (no requests from > UAC). > Within 32 s. the state machine is waiting for ACK. > If no ACK, it probably > means that something must have happend to UAC, and > "for sure" the Call is > lost. So, COMPLETED state is common for FAILURE and > SUCCESS and simply > means "forget this call". Hovewer, if ACK for > SUCCESS call (200 OK was > sent) > appears State Machine procceds to CONFIRMED state > and then ALWAYS after > 32 s. to the COMPLETED (call established, > transaction successfully > finalized) > Thus, My question is: > > 1. Does COMPLETED mean realy two states: either > COMPLETED_SUCCESS or > COMPLETED_FAILURE? > If yes, Maybe lack of ACK witihin 32s in SUCCESS > state allows machine to > procceed to COMPLETED_SUCCESS ?! > > 2. What for is CONFIRMED state in fact ? No action > is generated on ACK > in this state, and no (?) "call specific > variables" are changed on > "32s" transtition to COMPLETED. > > > And my last issue. Let's consider the following > scenario: > > We are currently in SUCCCESS state. So, we are > waiting for ACK. Sometimes, > we can receive a lost INVITE - we treat it as a > retransmission and we > send, what we have just sent - 200 OK. > But, according to 4.2.1 (INVITE description), we > must regard this > transaction as COMPLETED or, at least, we are not > allowed to response with > "400 Bad Request" if we have just received another > INVITE (re-INVITE). > If this is true, such re-INVITE should invoke new > instance of state > machine. > (or something else should happend, correct me) > For one call, we have now two state machines. Let > the second machine > work. Meanwhile, 32s timeout expired and the first > machine transited > to COMPLETED. Beacause I don't know (as mentioned > above) what COMPLETED > really means, my question is: what may (should, > must) happen then: > - Behaviour the first machine is irrelevant ("the > newest" machine > "hide" all the previous) > - The second machine should be stopped, because the > call was broken down. > The call is being destroyed. > - something else ? > > Thanks in advance for your ideas, > Piotr > > > > ATTACHMENT part 3.4 message/rfc822 > Date: Sun, 17 Dec 2000 21:00:18 -0500 > De: Henning Schulzrinne > > À: Baniel Uri-CUB001 > CC: "'sip@lists.bell-labs.com'" > > Objet: Re: [SIP] 8 bit clean channel > > > > Baniel Uri-CUB001 wrote: > > > > Hi > > > > What is exactly an 8 bit clean channel? What is a > 7 bit channel? > > TCP. Email. > > > > > Thanjs > > > > Uri > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > ATTACHMENT part 3.5 message/rfc822 > De: "Steve Donovan" > À: "Baniel Uri-CUB001" , > "'Neil Deason'" , > , > , > Objet: RE: [SIP] Proxies modifying SDP > Date: Sun, 17 Dec 2000 21:11:56 -0600 > > Although I am having a hard time understanding why > it would be necessary to > modify the SDP to cause the call to go through a > specific gateway, as Neil > correctly points out, this is likely to be a > function of a back-to-back UA. > > Why is it not enough to have the proxy route the > call to the gateway in > question by changing the request-URI to point to the > gateway? > > Steve > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > Baniel Uri-CUB001 > > Sent: Friday, December 15, 2000 1:51 PM > > To: 'Neil Deason'; jfmule@clarent.com; > bhoeneis@cc.hut.fi; > > sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > I see it as the requested way of forcing the media > stream to go > > via an 'IP switch' (like the H323 MCU). > > If a proxy server is not allowed or if it is not > appropriate for > > it to touch the SDP element, then is there any > other way to make > > sure the media stream goes via our MCU gateway. > (There could be > > various of reasons why we would want to have such > a gateway) > > > > What do u think? > > > > Uri > > > > -----Original Message----- > > From: Neil Deason [mailto:neil_deason@hotmail.com] > > Sent: Friday, December 15, 2000 12:30 PM > > To: jfmule@clarent.com; bhoeneis@cc.hut.fi; > sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > > > >Bernie Hoeneisen wrote: > > > > I have question concerning the case, when SIP > proxies modify SDP, > > > > which is AFAIK against SIP principles, isn't > it? > > >I do not think so. > > >Why is that *against* SIP principles? What > principles?' > > > > The fundamental concept that payloads are opaque > to SIP Proxy > > Servers. To do this sort of thing you probably > want to use a > > back to back UA. > > > > Cheers, > > Neil. > > -- > > Ubiquity Software, UK > www.ubiquity.net > > > > > > In the concrete case, proxies would be able to > remove certain codecs > > > > from the INVITE messages, depending on the > current policy in the > > > > network. (The UAS gets a subset of the codecs, > which were originally > > > > sent by the UAC.) > > > > What impact does such a proxy behavior have to > SIP? I can think of > > > > problems with authentication and message > integrity checking (UAC signs > > > > message with its private key). > > >It certainly depends on the security mechanism > used. For e.g., with the > > >simple basic md5, it does not cause any issue. > > > > > >Jean-Francois > > > > > _________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com. > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > ATTACHMENT part 3.6 message/rfc822 > À: > CC: Gonzalo Camarillo > > Objet: Re: [SIP] RE: Changin local RTP port without > a good reason > De: Pekka Pessi > Date: 18 Dec 2000 10:29:42 +0200 > > In message <3A3989CA.8F5E7117@lmf.ericsson.se> "ext > Gonzalo Camarillo" > writes: > >Of course that sometimes you have to change your > local configuration if > >the remote configuration changes... but there has > to be a good reason > >(like a change of codecs). > > When you issue a re-INVITE with a new local port > number, you are > proposing a new RTP session. The remote end > can not distinguish > between packets in the old session and new > session, unless it > changes its RTP port, too. > > >If my local configuration is too dependant on the > other party's > >configuration the negotiation ends up in an > infinite loop. > > There is always a request and a > corresponsing response. Depending > on previous response is not sensible, in my > opinion. > > Pekka > > > ATTACHMENT part 3.7 message/rfc822 > De: "Keith Robinson" > À: Billy Biggs > CC: Jean-Francois Mule , > Billy Biggs > Date: Mon, 18 Dec 2000 10:08:47 +0000 > Objet: Re: [SIP] Bug in 2543bis-02 re: Record-Route > > > > I believe that the way the text on the construction > of the Route headers is > worded will lead to > faulty behaviour as follows: > > In 6.35.2 (construction of Route header) the text > says > > "A UA builds the Route header field for subsequent > requests from the > Record-Route header fields > received in either a response or a request" > > This implies that a UA will build a new Route every > time a Record-Route header > is present in > a request or a response, not just for the initial > INVITE. Therefore, coupled > with the prior text > about a proxy adding itself to every request is only > SHOULD not MUST, a proxy > which assumes that > the Route will persist until the end of call leg > and doesn't add itself to > subsequent requests will be > excluded from the path if other proxies do add > themselves on subsequent requests > thereby causing > a UA to reconstruct the Route header, which would > break the rule that the path > is persistent until the > end of the call leg. > > That said, I have read other memos on the list > (can't remember which, but they > are there) where the author > has implied that a proxy can take itself out of the > path, which in the above > scenario would be by excluding > itself on subsequent requests. > > Perhaps there are two interpretations out there, one > where a proxy stays in for > good and one where a > proxy stays in until it excludes itself; whichever > is correct, the spec is > ambiguous as it seems to try and > support both at the same time. It can't, its one or > the other. > > Regards, > > K. Robinson > > > > > > > > Billy Biggs on 15/12/2000 > 19:52:14 > > > > > > > > > > > > > > > To: Jean-Francois Mule > > > > cc: Billy Biggs (bcc: > Keith > Robinson/MAIN/MC1) > > > > > > > > Subject: Re: [SIP] Bug in 2543bis-02 re: > Record-Route > > > > > > > > > > Jean-Francois Mule (jfmule@clarent.com): > > > Independently of the Record-Route discussions, the > 2543bis-02 (dated > > 11-24-00) has a small issue: > > > > In the same section 6.35.1 of 2543bis-02, it is > stated: > > "a request route, once established, persists until > the end of the call > > leg, *regardless of whether the Record-Route > header is present in > > subsequent requests.*" > > ... > > "Note that proxy servers have to add Record-Route > headers to each > > request *as long as* they want to be "visited" by > the next request for > > the call leg." The persistence of the record-route > is confusing. The > > suggestion is to just remove the note. > > The statement is correct: The Route persists until > the end of the call > leg regardless. Proxies may not ever leave the > Route for a call-leg. > The only thing that can be updated is the Contact > address at the far > end. > > That said, proxies must still add a Record-Route > header, just to make > the protocol more explicit. > > Is there some other statement in the bis which > makes this confusing? > Hopefully when this is re-written it will all become > clearer. > > -- > Billy Biggs, 3Com Email: > Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: > Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > ATTACHMENT part 3.8 message/rfc822 > Date: Mon, 18 Dec 2000 10:22:22 +0000 > De: Neil Deason > Affiliation: Ubiquity Software Corporation Limited > À: Keith Robinson > CC: Billy Biggs , > Jean-Francois Mule , > sip@lists.bell-labs.com > Objet: Re: [SIP] Bug in 2543bis-02 re: Record-Route > > I wouldn't pay too much attention to the present > Record-Route > text. > This problem area was discussed in some detail at > the recent > bakeoff > + IETF. There should shortly be revised text from > Jonathan R > which will be simpler, cleaner and work. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK > http://www.ubiquity.net > > Keith Robinson wrote: > > > > I believe that the way the text on the > construction of the Route headers is > > worded will lead to > > faulty behaviour as follows: > > > > In 6.35.2 (construction of Route header) the text > says > > > > "A UA builds the Route header field for subsequent > requests from the > > Record-Route header fields > > received in either a response or a request" > > > > This implies that a UA will build a new Route > every time a Record-Route header > > is present in > > a request or a response, not just for the initial > INVITE. Therefore, coupled > > with the prior text > > about a proxy adding itself to every request is > only SHOULD not MUST, a proxy > > which assumes that > > the Route will persist until the end of call leg > and doesn't add itself to > > subsequent requests will be > > excluded from the path if other proxies do add > themselves on subsequent requests > > thereby causing > > a UA to reconstruct the Route header, which would > break the rule that the path > > is persistent until the > > end of the call leg. > > > > That said, I have read other memos on the list > (can't remember which, but they > > are there) where the author > > has implied that a proxy can take itself out of > the path, which in the above > > scenario would be by excluding > > itself on subsequent requests. > > > > Perhaps there are two interpretations out there, > one where a proxy stays in for > > good and one where a > > proxy stays in until it excludes itself; whichever > is correct, the spec is > > ambiguous as it seems to try and > > support both at the same time. It can't, its one > or the other. > > > > Regards, > > > > K. Robinson > > > ATTACHMENT part 3.9 message/rfc822 > De: "Keith Robinson" > À: Billy Biggs > CC: SIP List > Date: Mon, 18 Dec 2000 11:01:19 +0000 > Objet: Re: [SIP] Proxy Routing Logic > > > > For the first case, couldn't this be the result of a > roaming UA using source > routing to get the > initial INVITE to its home domain proxy to do the > actual routing (perhaps the > user has > originating call features registered that they wish > to use); in which case I > would expect the > behaviour in 2 to take place. > > Regards, > > K. Robinson. > > > > > > > > Billy Biggs on 15/12/2000 > 20:26:49 > > > > > > > > > > > > > > > To: SIP List > > > > cc: (bcc: Keith Robinson/MAIN/MC1) > > > > > > > > Subject: [SIP] Proxy Routing Logic > > > > > > > > > > > If a proxy at proxy.com receives a request with a > Request-URI of: > > > sip:abc@someone-else.com;maddr=proxy.com > > > Should the proxy: > > 1. Return a 404. > 2. Proxy the message to abc@someone-else.com, > ditching the maddr > parameter. > > > Now say there is a populated Route header. Should > the proxy: > > 1. Replace the Request-URI with the first Route > and proxy. > 2. Return a 404. > 3. Proxy the message to abc@someone-else.com, > ditching the maddr > parameter (and not popping the Route). > > > I think it should do 1 for each case. Thoughts? > > -- > Billy Biggs, 3Com Email: > Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: > Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > ATTACHMENT part 3.10 message/rfc822 > De: bcampbell@dynamicsoft.com > Date: Mon, 18 Dec 2000 14:18 -0000 > À: "Steve Donovan" , > "Baniel Uri-CUB001" , > "Neil Deason" , > , > , > Objet: RE: [SIP] Proxies modifying SDP > > I suspect the original writer refers to some sort of > media gateway > that is not SIP enabled. Therefore one could not > simply proxy the > call to the gateway. > > ----Original Message----- > >From: Steve Donovan > > >To: Baniel Uri-CUB001 > ; 'Neil > Deason' ; > ; > ; > >Cc: > >Subj: RE: [SIP] Proxies modifying SDP > >Reply To: > >Sent: Sunday, December 17, 2000 9:13 PM > > > >Although I am having a hard time understanding > why it would be > necessary to > >modify the SDP to cause the call to go through a > specific gateway, > as Neil > >correctly points out, this is likely to be a > function of a > back-to-back UA. > > > >Why is it not enough to have the proxy route the > call to the > gateway in > >question by changing the request-URI to point to > the gateway? > > > >Steve > > > >> -----Original Message----- > >> From: sip-admin@lists.bell-labs.com > >> [mailto:sip-admin@lists.bell-labs.com]On > Behalf Of Baniel > Uri-CUB001 > >> Sent: Friday, December 15, 2000 1:51 PM > >> To: 'Neil Deason'; jfmule@clarent.com; > bhoeneis@cc.hut.fi; > >> sip@lists.bell-labs.com > >> Subject: RE: [SIP] Proxies modifying SDP > >> > >> > >> I see it as the requested way of forcing the > media stream to go > >> via an 'IP switch' (like the H323 MCU). > >> If a proxy server is not allowed or if it is > not appropriate for > >> it to touch the SDP element, then is there any > other way to make > >> sure the media stream goes via our MCU > gateway. (There could be > >> various of reasons why we would want to have > such a gateway) > >> > >> What do u think? > >> > >> Uri > >> > >> -----Original Message----- > >> From: Neil Deason > [mailto:neil_deason@hotmail.com] > >> Sent: Friday, December 15, 2000 12:30 PM > >> To: jfmule@clarent.com; bhoeneis@cc.hut.fi; > sip@lists.bell-labs.com > >> Subject: RE: [SIP] Proxies modifying SDP > >> > >> > >> > >> >Bernie Hoeneisen wrote: > >> > > I have question concerning the case, when > SIP proxies modify > SDP, > >> > > which is AFAIK against SIP principles, > isn't it? > >> >I do not think so. > >> >Why is that *against* SIP principles? What > principles?' > >> > >> The fundamental concept that payloads are > opaque to SIP Proxy > >> Servers. To do this sort of thing you probably > want to use a > >> back to back UA. > >> > >> Cheers, > >> Neil. > >> -- > >> Ubiquity Software, UK > www.ubiquity.net > >> > >> > > In the concrete case, proxies would be > able to remove > certain codecs > >> > > from the INVITE messages, depending on the > current policy in > the > >> > > network. (The UAS gets a subset of the > codecs, which were > originally > >> > > sent by the UAC.) > >> > > What impact does such a proxy behavior > have to SIP? I can > think of > >> > > problems with authentication and message > integrity checking > (UAC signs > >> > > message with its private key). > >> >It certainly depends on the security > mechanism used. For e.g., > with the > >> >simple basic md5, it does not cause any > issue. > >> > > >> >Jean-Francois > >> > >> > _______________________________________________________________________ > __ > >> Get Your Private, Free E-mail from MSN Hotmail > at > http://www.hotmail.com. > >> > >> > >> > _______________________________________________ > >> SIP mailing list > >> SIP@lists.bell-labs.com > >> > http://lists.bell-labs.com/mailman/listinfo/sip > >> > >> > _______________________________________________ > >> SIP mailing list > >> SIP@lists.bell-labs.com > >> > http://lists.bell-labs.com/mailman/listinfo/sip > >> > > > > > >_______________________________________________ > >SIP mailing list > >SIP@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > ___________________________________________________________ Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, Yahoo! Messenger : http://fr.messenger.yahoo.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 20:07:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19257 for ; Mon, 18 Dec 2000 20:07:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A456A44343; Mon, 18 Dec 2000 19:07:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lists.bell-labs.com (Postfix) with ESMTP id 44E1344336 for ; Mon, 18 Dec 2000 19:06:21 -0500 (EST) Received: [from pobox.mot.com (pobox.mot.com [129.188.137.100]) by motgate.mot.com (motgate 2.1) with ESMTP id SAA15851 for ; Mon, 18 Dec 2000 18:06:10 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox.mot.com (MOT-pobox 2.0) with ESMTP id SAA27246 for ; Mon, 18 Dec 2000 18:05:51 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Mon, 18 Dec 2000 19:05:21 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED888B@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'Steve Donovan'" , Baniel Uri-CUB001 , "'Neil Deason'" , jfmule@clarent.com, bhoeneis@cc.hut.fi, sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 19:05:17 -0600 Hmm... Probably I was not clear and hence the confusion. My intention was to be able to mimic the 'H323 gate keeper mode' functionality, i.e. to have the end points think they talk to each other (in the media streaming phase) but actually the media goes via a gate keeper. In our SIP world this should be just a MG (Media Gateway). The control may still go via a SIP proxy server, that is why I think changing SDP fields (specifically the IP address for receiving media as well as the RTP ports) may easily achieve this goal Uri -----Original Message----- From: Steve Donovan [mailto:sdonovan@dynamicsoft.com] Sent: Sunday, December 17, 2000 9:12 PM To: Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP Although I am having a hard time understanding why it would be necessary to modify the SDP to cause the call to go through a specific gateway, as Neil correctly points out, this is likely to be a function of a back-to-back UA. Why is it not enough to have the proxy route the call to the gateway in question by changing the request-URI to point to the gateway? Steve > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Baniel Uri-CUB001 > Sent: Friday, December 15, 2000 1:51 PM > To: 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; > sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > I see it as the requested way of forcing the media stream to go > via an 'IP switch' (like the H323 MCU). > If a proxy server is not allowed or if it is not appropriate for > it to touch the SDP element, then is there any other way to make > sure the media stream goes via our MCU gateway. (There could be > various of reasons why we would want to have such a gateway) > > What do u think? > > Uri > > -----Original Message----- > From: Neil Deason [mailto:neil_deason@hotmail.com] > Sent: Friday, December 15, 2000 12:30 PM > To: jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > > >Bernie Hoeneisen wrote: > > > I have question concerning the case, when SIP proxies modify SDP, > > > which is AFAIK against SIP principles, isn't it? > >I do not think so. > >Why is that *against* SIP principles? What principles?' > > The fundamental concept that payloads are opaque to SIP Proxy > Servers. To do this sort of thing you probably want to use a > back to back UA. > > Cheers, > Neil. > -- > Ubiquity Software, UK www.ubiquity.net > > > > In the concrete case, proxies would be able to remove certain codecs > > > from the INVITE messages, depending on the current policy in the > > > network. (The UAS gets a subset of the codecs, which were originally > > > sent by the UAC.) > > > What impact does such a proxy behavior have to SIP? I can think of > > > problems with authentication and message integrity checking (UAC signs > > > message with its private key). > >It certainly depends on the security mechanism used. For e.g., with the > >simple basic md5, it does not cause any issue. > > > >Jean-Francois > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 20:22:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA19373 for ; Mon, 18 Dec 2000 20:22:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 82FDD44355; Mon, 18 Dec 2000 19:22:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9A7AA44354 for ; Mon, 18 Dec 2000 19:21:09 -0500 (EST) Received: from athletics (cf9e4162.dfw53.dsl.airmail.net [207.158.65.98]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id UAA10167; Mon, 18 Dec 2000 20:21:53 -0500 (EST) From: "Steve Donovan" To: "Baniel Uri-CUB001" , "'Neil Deason'" , , , Subject: RE: [SIP] Proxies modifying SDP 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.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED888B@il27exm02.cig.mot.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 19:17:25 -0600 Content-Transfer-Encoding: 7bit Baniel, Thanks for the clarification. Keep in mind that I am not an expert on H.323, so I don't fully understand the H323 gate keeper mode you refer to. This said, in order to implement what you refer to, you have a few options, none of which directly involves a proxy. - The easiest way to handle this is to put a SIP user agent directly on the media gateway and have that user agent directly determine the address of and type of media to use for the call. - If you want to have another device "control" the media flow, this is more appropriately done using a Media Gateway Controller (MGC). The MGC would be a SIP end point, not a proxy. It would communicate with the MG using one of the control protocols (MGCP, MEGACO, ...). With it being a SIP end-point, it can do what ever it wants to the SDP, within the bounds of the rules specified in the SIP specification. There may be a proxy (or multiple proxies) between the caller and the MGC/MG, but its job is to route the SIP request. As stated earlier, the message body of the request is opaque. Hope this helps... Steve --- Steven R. Donovan Architect dynamicsoft mailto:sdonovan@dynamicsoft.com 5100 Tennyson Parkway sip:sdonovan@sip.dynamicsoft.com Plano, Texas 75025 tel:+1-972-473-5469 http://www.dynamicsoft.com > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Baniel Uri-CUB001 > Sent: Monday, December 18, 2000 7:05 PM > To: 'Steve Donovan'; Baniel Uri-CUB001; 'Neil Deason'; > jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > Hmm... > Probably I was not clear and hence the confusion. > My intention was to be able to mimic the 'H323 gate keeper mode' > functionality, i.e. to have the end points think they talk to > each other (in > the media streaming phase) but actually the media goes via a gate > keeper. In > our SIP world this should be just a MG (Media Gateway). > The control may still go via a SIP proxy server, that is why I think > changing SDP fields (specifically the IP address for receiving > media as well > as the RTP ports) may easily achieve this goal > > Uri > > -----Original Message----- > From: Steve Donovan [mailto:sdonovan@dynamicsoft.com] > Sent: Sunday, December 17, 2000 9:12 PM > To: Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; > bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > Although I am having a hard time understanding why it would be > necessary to > modify the SDP to cause the call to go through a specific gateway, as Neil > correctly points out, this is likely to be a function of a > back-to-back UA. > > Why is it not enough to have the proxy route the call to the gateway in > question by changing the request-URI to point to the gateway? > > Steve > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Baniel Uri-CUB001 > > Sent: Friday, December 15, 2000 1:51 PM > > To: 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; > > sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > I see it as the requested way of forcing the media stream to go > > via an 'IP switch' (like the H323 MCU). > > If a proxy server is not allowed or if it is not appropriate for > > it to touch the SDP element, then is there any other way to make > > sure the media stream goes via our MCU gateway. (There could be > > various of reasons why we would want to have such a gateway) > > > > What do u think? > > > > Uri > > > > -----Original Message----- > > From: Neil Deason [mailto:neil_deason@hotmail.com] > > Sent: Friday, December 15, 2000 12:30 PM > > To: jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > > > >Bernie Hoeneisen wrote: > > > > I have question concerning the case, when SIP proxies modify SDP, > > > > which is AFAIK against SIP principles, isn't it? > > >I do not think so. > > >Why is that *against* SIP principles? What principles?' > > > > The fundamental concept that payloads are opaque to SIP Proxy > > Servers. To do this sort of thing you probably want to use a > > back to back UA. > > > > Cheers, > > Neil. > > -- > > Ubiquity Software, UK www.ubiquity.net > > > > > > In the concrete case, proxies would be able to remove certain codecs > > > > from the INVITE messages, depending on the current policy in the > > > > network. (The UAS gets a subset of the codecs, which were originally > > > > sent by the UAC.) > > > > What impact does such a proxy behavior have to SIP? I can think of > > > > problems with authentication and message integrity checking > (UAC signs > > > > message with its private key). > > >It certainly depends on the security mechanism used. For > e.g., with the > > >simple basic md5, it does not cause any issue. > > > > > >Jean-Francois > > > > > _________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 21:18:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA20058 for ; Mon, 18 Dec 2000 21:18:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 350F244337; Mon, 18 Dec 2000 20:18:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from king.pbc.com (unknown [63.207.108.70]) by lists.bell-labs.com (Postfix) with ESMTP id 6501F44336 for ; Mon, 18 Dec 2000 20:17:58 -0500 (EST) Received: from pacband.com ([192.168.11.47]) by king.pbc.com (8.9.3/8.9.3) with ESMTP id SAA25223 for ; Mon, 18 Dec 2000 18:18:01 -0800 Message-ID: <3A3EC528.366B3489@pacband.com> From: Burcak Beser Reply-To: Burcak@pbc.com Organization: Pacific Broadband Communications X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: SIP@lists.bell-labs.com Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Comparison of Media Authorization drafts Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 18:17:12 -0800 Content-Transfer-Encoding: 8bit As an author of SIP Extensions for Media Authorization” I tried to compare the draft with the draft “Session setup with media authorization”. All comments/suggestions/questions are welcome. Burcak Beser Pacific Broadband Communications ------------- Draft “SIP Extensions for Media Authorization” defines the Media-Authorization-Token as a hex blob. The draft does not force any meaning to the hex blob; the examples in the draft give two known uses for this field. As described in the draft “Session setup with media authorization”, if there are to be many fields: * All of these fields have to be send to the Edge Router. * The End Host (UAS) does not necessarily know what is the meaning of any of the proposed fields. As a result, we can say that there is no need for SIP defined sub-encoding(s) for the Media-Authorization-Token field. The token can be formatted and populated as PDP and PEP agrees. Since it is impossible to predict from today what kind of information has to exchange will occur between PDP and PEP (for example one possible way is that the information will contain the Credit Card number to be billed) the best way is to threat the information as a byte blob. The draft “SIP Extensions for Media Authorization” does not state in any place (as incorrectly stated in draft “Session setup with media authorization”): * The end-host is connected to a known point in the network. * Same policy server makes decisions related to both service authorization and resource utilization. * Session managers and policy servers know each other’s existence and have a pre-defined trust relationship. The draft “SIP Extensions for Media Authorization” is written such that only the SIP protocol use is focused; the draft clearly defines how each SIP end will behave and how the information will be passed between them using SIP protocol. But it does not impose any other restrictions on any other entities or protocols. It is possible to device many other methods and elements that the creative authorization methods will take place and the draft only covers for all these protocols the question how to deliver the Media-Authorization information to the UAS in a generic way. As a summary it can be said that the draft “SIP Extensions for Media Authorization” includes all the features that draft “Session setup with media authorization” proposes and enables more features/modes. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 18 23:12:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA23201 for ; Mon, 18 Dec 2000 23:12:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 34C3444337; Mon, 18 Dec 2000 22:12:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lists.bell-labs.com (Postfix) with ESMTP id D0E6944336 for ; Mon, 18 Dec 2000 22:11:54 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id VAA21519 for ; Mon, 18 Dec 2000 21:11:45 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id VAA19469 for ; Mon, 18 Dec 2000 21:11:44 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Mon, 18 Dec 2000 22:11:44 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED888E@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'Steve Donovan '" , Baniel Uri-CUB001 , "''Neil Deason' '" , "'jfmule@clarent.com '" , "'bhoeneis@cc.hut.fi '" , "'sip@lists.bell-labs.com '" Subject: RE: [SIP] Proxies modifying SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 22:11:34 -0600 Thanks a lot , Steve, sounds good! Uri -----Original Message----- From: Steve Donovan To: Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com Sent: 12/18/00 7:17 PM Subject: RE: [SIP] Proxies modifying SDP Baniel, Thanks for the clarification. Keep in mind that I am not an expert on H.323, so I don't fully understand the H323 gate keeper mode you refer to. This said, in order to implement what you refer to, you have a few options, none of which directly involves a proxy. - The easiest way to handle this is to put a SIP user agent directly on the media gateway and have that user agent directly determine the address of and type of media to use for the call. - If you want to have another device "control" the media flow, this is more appropriately done using a Media Gateway Controller (MGC). The MGC would be a SIP end point, not a proxy. It would communicate with the MG using one of the control protocols (MGCP, MEGACO, ...). With it being a SIP end-point, it can do what ever it wants to the SDP, within the bounds of the rules specified in the SIP specification. There may be a proxy (or multiple proxies) between the caller and the MGC/MG, but its job is to route the SIP request. As stated earlier, the message body of the request is opaque. Hope this helps... Steve --- Steven R. Donovan Architect dynamicsoft mailto:sdonovan@dynamicsoft.com 5100 Tennyson Parkway sip:sdonovan@sip.dynamicsoft.com Plano, Texas 75025 tel:+1-972-473-5469 http://www.dynamicsoft.com > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Baniel Uri-CUB001 > Sent: Monday, December 18, 2000 7:05 PM > To: 'Steve Donovan'; Baniel Uri-CUB001; 'Neil Deason'; > jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > Hmm... > Probably I was not clear and hence the confusion. > My intention was to be able to mimic the 'H323 gate keeper mode' > functionality, i.e. to have the end points think they talk to > each other (in > the media streaming phase) but actually the media goes via a gate > keeper. In > our SIP world this should be just a MG (Media Gateway). > The control may still go via a SIP proxy server, that is why I think > changing SDP fields (specifically the IP address for receiving > media as well > as the RTP ports) may easily achieve this goal > > Uri > > -----Original Message----- > From: Steve Donovan [mailto:sdonovan@dynamicsoft.com] > Sent: Sunday, December 17, 2000 9:12 PM > To: Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; > bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > Although I am having a hard time understanding why it would be > necessary to > modify the SDP to cause the call to go through a specific gateway, as Neil > correctly points out, this is likely to be a function of a > back-to-back UA. > > Why is it not enough to have the proxy route the call to the gateway in > question by changing the request-URI to point to the gateway? > > Steve > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Baniel Uri-CUB001 > > Sent: Friday, December 15, 2000 1:51 PM > > To: 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; > > sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > I see it as the requested way of forcing the media stream to go > > via an 'IP switch' (like the H323 MCU). > > If a proxy server is not allowed or if it is not appropriate for > > it to touch the SDP element, then is there any other way to make > > sure the media stream goes via our MCU gateway. (There could be > > various of reasons why we would want to have such a gateway) > > > > What do u think? > > > > Uri > > > > -----Original Message----- > > From: Neil Deason [mailto:neil_deason@hotmail.com] > > Sent: Friday, December 15, 2000 12:30 PM > > To: jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > > > >Bernie Hoeneisen wrote: > > > > I have question concerning the case, when SIP proxies modify SDP, > > > > which is AFAIK against SIP principles, isn't it? > > >I do not think so. > > >Why is that *against* SIP principles? What principles?' > > > > The fundamental concept that payloads are opaque to SIP Proxy > > Servers. To do this sort of thing you probably want to use a > > back to back UA. > > > > Cheers, > > Neil. > > -- > > Ubiquity Software, UK www.ubiquity.net > > > > > > In the concrete case, proxies would be able to remove certain codecs > > > > from the INVITE messages, depending on the current policy in the > > > > network. (The UAS gets a subset of the codecs, which were originally > > > > sent by the UAC.) > > > > What impact does such a proxy behavior have to SIP? I can think of > > > > problems with authentication and message integrity checking > (UAC signs > > > > message with its private key). > > >It certainly depends on the security mechanism used. For > e.g., with the > > >simple basic md5, it does not cause any issue. > > > > > >Jean-Francois > > > > > ________________________________________________________________________ _ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 01:29:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28723 for ; Tue, 19 Dec 2000 01:29:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D0BC744337; Tue, 19 Dec 2000 00:29:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8427A44336 for ; Tue, 19 Dec 2000 00:28:02 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11180; Tue, 19 Dec 2000 01:30:27 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 01:25:26 -0500 Message-ID: From: Jonathan Rosenberg To: "'David Shrader'" , SIP List Subject: RE: [SIP] Record-Route and REGISTER MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 01:25:24 -0500 > -----Original Message----- > From: David Shrader [mailto:dshrader@master-consultant.com] > Sent: Sunday, December 17, 2000 3:40 PM > To: SIP List > Subject: [SIP] Record-Route and REGISTER > > When using the REGISTER method, however, the Contact header > is NOT used for > that purpose. The Contact header in the Response to a > REGISTER is simply a > list of registered contacts and does not in fact identify the > recipient of a > subsequent request. Correct. REGISTER is nearly a separate protocol, for all intents and purposes. As specified right now, record-routing for REGISTER is ambigous. In any case, record-routing for transactions outside of INVITE is not clear. What is the the scope of the Route? To which set of messages does it apply? When can the route be purged? These issues must be resolved as well, and they are much harder. The solution to your specific problem is for the UAC and UAC to use RR in REGISTER instead. So: 1. A UAC inserts a REcord-route into the REGISTER pointing to itself, just like the Contact would look in an INVITE 2. proxies can record-route 3. UAS (the registrar, in this case) also adds a RR, and reflects that back in 200 OK 4. Route is constructed normally except COntact is ignored Kind of a pain to have a special procedure for REGISTER, I know. In hindsight, I would have used something instead of Contact here, but at the time rfc2543 was being written, the usages were similar enough and the idea of record-routing REGISTER was not something we considered. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 01:34:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29484 for ; Tue, 19 Dec 2000 01:34:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 15A6C4434B; Tue, 19 Dec 2000 00:34:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B1E094434A for ; Tue, 19 Dec 2000 00:33:16 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11201; Tue, 19 Dec 2000 01:35:41 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 01:30:40 -0500 Message-ID: From: Jonathan Rosenberg To: "'Pekka Pessi'" , sip@lists.bell-labs.com Cc: Gonzalo Camarillo Subject: RE: [SIP] RE: Changin local RTP port without a good reason MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 01:30:38 -0500 > -----Original Message----- > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > Sent: Monday, December 18, 2000 3:30 AM > To: sip@lists.bell-labs.com > Cc: Gonzalo Camarillo > Subject: Re: [SIP] RE: Changin local RTP port without a good reason > > > In message <3A3989CA.8F5E7117@lmf.ericsson.se> "ext Gonzalo > Camarillo" writes: > >Of course that sometimes you have to change your local > configuration if > >the remote configuration changes... but there has to be a good reason > >(like a change of codecs). > > When you issue a re-INVITE with a new local port number, you are > proposing a new RTP session. The remote end can not > distinguish > between packets in the old session and new session, unless it > changes its RTP port, too. Much as I would like to be able to enforce this "don't change ports without good reason", I think there are cases where implementations will want to do this on each re-invite. As such, I think the mechanism in the current 3pcc draft won't work either. An alternative flow has already been proposed which does not suffer from the timeout problem, and which does not have this race condition: > > A Controller B > > | INV SDP held | | time t = 0 > > |<------------------| | > > | | | > > | 200 SDP A1 | | > > |-----------------> | | > > | | | > > | ACK | | > > |<------------------| | > > | | | > > | | INV no SDP | > > | |----------------->| (1) > > | | | > > | | 200 SDP B | > > | |<-----------------| > > | INV SDP B | | > > |<------------------| | > > | | | > > | 200 SDP A2 | | > > |-----------------> | | > > | | | > > | | ACK SDP A2 | > > | ACK |----------------->| > > |<------------------| | > > | | | > > | | RTP | > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > | | | I'd like to start with this one as the basis for continuing discussion/concerns. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 01:37:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA29882 for ; Tue, 19 Dec 2000 01:37:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9B21D44352; Tue, 19 Dec 2000 00:37:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E326244350 for ; Tue, 19 Dec 2000 00:36:59 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11236; Tue, 19 Dec 2000 01:39:17 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 01:34:16 -0500 Message-ID: From: Jonathan Rosenberg To: "'Neil Deason'" , Keith Robinson Cc: Billy Biggs , Jean-Francois Mule , sip@lists.bell-labs.com Subject: RE: [SIP] Bug in 2543bis-02 re: Record-Route MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 01:34:14 -0500 Its pending.... till then, let me be explicit on this one. 1. A UAC/UAS does NOT rebuild the route on each request. As Vijay pointed out, the reconstruction is done on crash-restart, assuming the device is trying to recover on a re-invite. 2. proxies re-insert record-route into every request for robustness, to handle the case above and also the case of "pre-loaded" route headers, where the request starts out with a set of Route headers obtained out of band. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Neil Deason [mailto:ndeason@ubiquity.net] > Sent: Monday, December 18, 2000 5:22 AM > To: Keith Robinson > Cc: Billy Biggs; Jean-Francois Mule; sip@lists.bell-labs.com > Subject: Re: [SIP] Bug in 2543bis-02 re: Record-Route > > > I wouldn't pay too much attention to the present Record-Route > text. > This problem area was discussed in some detail at the recent > bakeoff > + IETF. There should shortly be revised text from Jonathan R > which will be simpler, cleaner and work. > > Cheers, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net > > Keith Robinson wrote: > > > > I believe that the way the text on the construction of the > Route headers is > > worded will lead to > > faulty behaviour as follows: > > > > In 6.35.2 (construction of Route header) the text says > > > > "A UA builds the Route header field for subsequent requests from the > > Record-Route header fields > > received in either a response or a request" > > > > This implies that a UA will build a new Route every time a > Record-Route header > > is present in > > a request or a response, not just for the initial INVITE. > Therefore, coupled > > with the prior text > > about a proxy adding itself to every request is only SHOULD > not MUST, a proxy > > which assumes that > > the Route will persist until the end of call leg and > doesn't add itself to > > subsequent requests will be > > excluded from the path if other proxies do add themselves > on subsequent requests > > thereby causing > > a UA to reconstruct the Route header, which would break the > rule that the path > > is persistent until the > > end of the call leg. > > > > That said, I have read other memos on the list (can't > remember which, but they > > are there) where the author > > has implied that a proxy can take itself out of the path, > which in the above > > scenario would be by excluding > > itself on subsequent requests. > > > > Perhaps there are two interpretations out there, one where > a proxy stays in for > > good and one where a > > proxy stays in until it excludes itself; whichever is > correct, the spec is > > ambiguous as it seems to try and > > support both at the same time. It can't, its one or the other. > > > > Regards, > > > > K. Robinson > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 01:49:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01256 for ; Tue, 19 Dec 2000 01:49:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E8D6F44359; Tue, 19 Dec 2000 00:49:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 472FF44357 for ; Tue, 19 Dec 2000 00:48:30 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11253; Tue, 19 Dec 2000 01:50:55 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 01:45:54 -0500 Message-ID: From: Jonathan Rosenberg To: "'Keith Robinson'" , Billy Biggs Cc: SIP List Subject: RE: [SIP] Proxy Routing Logic MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 01:45:52 -0500 > -----Original Message----- > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > Sent: Monday, December 18, 2000 6:01 AM > To: Billy Biggs > Cc: SIP List > Subject: Re: [SIP] Proxy Routing Logic > > > > > For the first case, couldn't this be the result of a roaming > UA using source > routing to get the > initial INVITE to its home domain proxy to do the actual > routing (perhaps the > user has > originating call features registered that they wish to use); > in which case I > would expect the > behaviour in 2 to take place. In this case, I don't think the roaming user would construct the URI in this fashion. Rather, it would use a Route header to accomplish this task. That aside, there is an important issue here. When using a local outbound proxy, you most definitely do NOT want to set the maddr parameter in the request URI to point to that proxy. This is confusing, since you would want the URL to have the maddr parameter outside of the context of the request URI. Specifically, lets say I want to have a URL in a web page that causes people to call me through some local proxy. That URL in the web page would look like: sip:jdrosen@dynamicsoft.com;maddr=local.proxy.com This URI would not be inserted directly into the request URI, however. That maddr needs to be stripped. So, I propose we add some text to the spec somewhere along these lines: "The maddr parameter should be present in the Request URI only if the server the request is sent to is not the one in the maddr parameter.". Probably this can be better phrased. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 01:52:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA01618 for ; Tue, 19 Dec 2000 01:52:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E2F5D44361; Tue, 19 Dec 2000 00:52:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 731924435E for ; Tue, 19 Dec 2000 00:51:34 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 22:51:10 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: sip@lists.bell-labs.com Subject: RE: [SIP] 3pcc callflow question (Was:Changin local RTP port with out a good reason) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 22:51:05 -0800 > An alternative flow has already been proposed which does not > suffer from the > timeout problem, and which does not have this race condition: > > > > A Controller B > > > | INV SDP held | | time t = 0 > > > |<------------------| | > > > | | | > > > | 200 SDP A1 | | > > > |-----------------> | | > > > | | | > > > | ACK | | > > > |<------------------| | > > > | | | Sorry to go back a bit but can I forget the reason why it was decided not to start with: A Controller INV no SDP <-------- 200 SDP A1 --------> ACK SDP held <-------- This seems simpler as both A and B are behaving in the same manner (rather than A having to realize that it must produce SDP A1 when it receives an initial SDP held). Was it because of crash-restart problems ? Regards, Robert. > > > | | INV no SDP | > > > | |----------------->| (1) > > > | | | > > > | | 200 SDP B | > > > | |<-----------------| > > > | INV SDP B | | > > > |<------------------| | > > > | | | > > > | 200 SDP A2 | | > > > |-----------------> | | > > > | | | > > > | | ACK SDP A2 | > > > | ACK |----------------->| > > > |<------------------| | > > > | | | > > > | | RTP | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > | | | > > > I'd like to start with this one as the basis for continuing > discussion/concerns. > > -Jonathan R. > > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 01:56:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA02091 for ; Tue, 19 Dec 2000 01:56:28 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D6F214436A; Tue, 19 Dec 2000 00:54:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8B0114436A for ; Tue, 19 Dec 2000 00:53:02 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA11285; Tue, 19 Dec 2000 01:55:28 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 01:50:27 -0500 Message-ID: From: Jonathan Rosenberg To: "'Wamorkar, Vivek'" , "'sip@lists.bell-labs.com'" Cc: "Zenone, Bruce" , "Rigaldies, Bertrand" , "Lancaster, Cary" Subject: RE: [SIP] Recovery mechanism for UA MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 01:50:26 -0500 > -----Original Message----- > From: Wamorkar, Vivek [mailto:Vivek.Wamorkar@comdial.com] > Sent: Monday, December 18, 2000 12:19 PM > To: 'sip@lists.bell-labs.com' > Cc: Zenone, Bruce; Wamorkar, Vivek; Rigaldies, Bertrand; > Lancaster, Cary > Subject: [SIP] Recovery mechanism for UA > > > What is the defined recovery mechanism for a User Agent if UA > reboots and > wants to rejoin the existing session. Assuming that UA fails > to successfully > log the session details. Given that proxy is stateful, can UA > query the > proxy for its existing session. No. When session timer is used, the session can be refreshed. Its a non-trivial exercise. Billy Biggs recently posted a mail summarizing some of the requirements: http://lists.bell-labs.com/pipermail/sip/2000q4/004186.html I think it would be nice to see an I-D capturing all this. I don't think we want to burden the sip spec with the details of doing this, and it needs to be explored in more detail. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 02:14:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA08815 for ; Tue, 19 Dec 2000 02:14:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1A8D544348; Tue, 19 Dec 2000 01:14:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9B6FE44337 for ; Tue, 19 Dec 2000 01:13:44 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA11432; Tue, 19 Dec 2000 02:16:10 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 02:11:08 -0500 Message-ID: From: Jonathan Rosenberg To: "'Henning G. Schulzrinne'" , William Marshall Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Solving the REFER retransmit issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 02:11:07 -0500 > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, December 16, 2000 5:27 PM > To: William Marshall > Cc: sip@lists.bell-labs.com > Subject: Re: [SIP] Solving the REFER retransmit issue > > > While I have some sympathy for allowing the 3-way handshake for REFER, > I'm very concerned about the proxy backward compatibility issue. An > "old" proxy that thinks REFER is just another non-INVITE and a new UAS > that retransmits 200s until it gets an ACK will get not be happy > together. (A UAS that doesn't know REFER is likely to respond > immediately with a 400 and will likely just dump the ACK, so that > variation seems less of a concern.) Thus, we at least need a > Proxy-Require Correct. And, according to the guidelines draft: The Proxy-Require header should be avoided at all costs. The failure likelihood in an individual proxy stays constant, but the path failure grows exponentially with the number of hops. On the other hand, the Require header only mandates that a single entity, the UAS, support the extension. Usage of Proxy-Require is thus considered exponentially worse than usage of the Require header. As we have other alternatives (basically, a "four-way" handshake, using a two-way in each direction, works fine), this is simply a no go. So, lets forget about any definitions of new reliability mechanisms or anything of the sort. Brett Tate writes: > How about including a parameter or header in REFER > which would indicate an ordered request preference for > when to send 200 response? > > Refer-Response-Disposition: 1#refer-response-param > refer-response-param = > "refer" | "18x-final" | "final" | "notify" | "notify-failure" | token > > "refer" means send 200 when get REFER. > > "18x-final" means send final response when get 18x or final > response for method request. > > "final" means send final response when success or failure > of method request is determined. > > "notify" send 200 when get REFER and send NOTIFY > with method final response. > > "notify-failure" send 200 when get REFER and send > NOTIFY when a failure of the method request is > determined. There is another axiom of IETF protocol design to consider here, from rfc1958, which i think everyone should read: 3.2 If there are several ways of doing the same thing, choose one. If a previous design, in the Internet context or elsewhere, has successfully solved the same problem, choose the same solution unless there is a good technical reason not to. Duplication of the same protocol functionality should be avoided as far as possible, without of course using this argument to reject improvements. 3.8 Avoid options and parameters whenever possible. Any options and parameters should be configured or negotiated dynamically rather than manually. A solution as Brett has proposed requires a whole lot of things to be implemented, and will likely suffer from interop problems. Lets pick a single solution. Whilst I still kind of like the hybrid "respond within 16 seconds, a 202 if you didn't get a response to the triggered request, 200 if you did", I appreciate that this is also more of the protocol options I have just argued against. So, back to basics. The reason we built in this simple two way handshake into non-INVITE methods was the assumption that they would be responded to immediately, since an automata would answer, not a human. Lets keep with that. REFER should generate an immediate response. I like Rohan's idea of the NOTIFY (or something else) being sent later on when the request is answered. This is easier than needing to support an actual presence server in the UA, which would need to wait for SUBSCRIBE requests. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 03:44:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA09499 for ; Tue, 19 Dec 2000 03:44:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E754A44337; Tue, 19 Dec 2000 02:44:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 91DFA44336 for ; Tue, 19 Dec 2000 02:43:26 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZF96X10X; Tue, 19 Dec 2000 09:39:57 +0100 From: "Hisham Khartabil" To: Subject: RE: [SIP] RE: Changin local RTP port without a good reason 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.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 10:44:12 +0200 Content-Transfer-Encoding: 7bit What was the conclusion about the issue of SDP in ACK. If the decision was to disallow it, then the flow below is breaking that rule already. Regards, Hisham > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > Sent: Tuesday, 19 December 2000 8:31 AM > To: 'Pekka Pessi'; sip@lists.bell-labs.com > Cc: Gonzalo Camarillo > Subject: RE: [SIP] RE: Changin local RTP port without a good reason > > > > > > > > -----Original Message----- > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > Sent: Monday, December 18, 2000 3:30 AM > > To: sip@lists.bell-labs.com > > Cc: Gonzalo Camarillo > > Subject: Re: [SIP] RE: Changin local RTP port without a good reason > > > > > > In message <3A3989CA.8F5E7117@lmf.ericsson.se> "ext Gonzalo > > Camarillo" writes: > > >Of course that sometimes you have to change your local > > configuration if > > >the remote configuration changes... but there has to be a good reason > > >(like a change of codecs). > > > > When you issue a re-INVITE with a new local port number, you are > > proposing a new RTP session. The remote end can not > > distinguish > > between packets in the old session and new session, unless it > > changes its RTP port, too. > > > Much as I would like to be able to enforce this "don't change > ports without > good reason", I think there are cases where implementations will > want to do > this on each re-invite. As such, I think the mechanism in the current 3pcc > draft won't work either. > > An alternative flow has already been proposed which does not > suffer from the > timeout problem, and which does not have this race condition: > > > > A Controller B > > > | INV SDP held | | time t = 0 > > > |<------------------| | > > > | | | > > > | 200 SDP A1 | | > > > |-----------------> | | > > > | | | > > > | ACK | | > > > |<------------------| | > > > | | | > > > | | INV no SDP | > > > | |----------------->| (1) > > > | | | > > > | | 200 SDP B | > > > | |<-----------------| > > > | INV SDP B | | > > > |<------------------| | > > > | | | > > > | 200 SDP A2 | | > > > |-----------------> | | > > > | | | > > > | | ACK SDP A2 | > > > | ACK |----------------->| > > > |<------------------| | > > > | | | > > > | | RTP | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > | | | > > > I'd like to start with this one as the basis for continuing > discussion/concerns. > > -Jonathan R. > > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 07:07:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11443 for ; Tue, 19 Dec 2000 07:07:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 63CC544337; Tue, 19 Dec 2000 06:07:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from tab.pbc.com (unknown [63.207.108.67]) by lists.bell-labs.com (Postfix) with ESMTP id A2F0244336 for ; Mon, 18 Dec 2000 18:46:02 -0500 (EST) Received: from himalaya.pacband.com (himalaya.pacband.com [192.168.10.182]) by tab.pbc.com (8.9.3+Sun/8.9.3) with ESMTP id QAA01693; Mon, 18 Dec 2000 16:35:27 -0800 (PST) Received: by himalaya.pacband.com with Internet Mail Service (5.5.2650.21) id ; Mon, 18 Dec 2000 16:36:08 -0800 Message-ID: <8104DBB8386FD411B8A600D0B76FEAFE02F5B6@himalaya.pacband.com> From: Burcak Beser To: "'Louis-Nicolas Hamer'" , SIP@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06953.ADEDFD92" Subject: [SIP] Comparison of Media Authorization drafts Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 18 Dec 2000 16:36:08 -0800 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_01C06953.ADEDFD92 Content-Type: text/plain; charset="iso-8859-1" As an author of SIP Extensions for Media Authorization" I tried to compare the draft with the draft "Session setup with media authorization". All comments/suggestions/questions are welcome. Burcak Beser Pacific Broadband Communications ------------- Draft "SIP Extensions for Media Authorization" defines the Media-Authorization-Token as a hex blob. The draft does not force any meaning to the hex blob; the examples in the draft give two known uses for this field. As described in the draft "Session setup with media authorization", if there are to be many fields: * All of these fields have to be send to the Edge Router. * The End Host (UAS) does not necessarily know what is the meaning of any of the proposed fields. As a result, we can say that there is no need for SIP defined sub-encoding(s) for the Media-Authorization-Token field. The token can be formatted and populated as PDP and PEP agrees. Since it is impossible to predict from today what kind of information has to exchange will occur between PDP and PEP (for example one possible way is that the information will contain the Credit Card number to be billed) the best way is to threat the information as a byte blob. The draft "SIP Extensions for Media Authorization" does not state in any place (as incorrectly stated in draft "Session setup with media authorization"): * The end-host is connected to a known point in the network. * Same policy server makes decisions related to both service authorization and resource utilization. * Session managers and policy servers know each other's existence and have a pre-defined trust relationship. The draft "SIP Extensions for Media Authorization" is written such that only the SIP protocol use is focused; the draft clearly defines how each SIP end will behave and how the information will be passed between them using SIP protocol. But it does not impose any other restrictions on any other entities or protocols. It is possible to device many other methods and elements that the creative authorization methods will take place and the draft only covers for all these protocols the question how to deliver the Media-Authorization information to the UAS in a generic way. As a summary it can be said that the draft "SIP Extensions for Media Authorization" includes all the features that draft "Session setup with media authorization" proposes and enables more features/modes. ------_=_NextPart_001_01C06953.ADEDFD92 Content-Type: text/html; charset="iso-8859-1" RE: draft-hamer-sip-session-auth-00.txt  

As an author of SIP Extensions for Media Authorization”  I tried to compare the draft with the draft “Session setup with media authorization”.

 

All comments/suggestions/questions are welcome.

 

Burcak Beser

Pacific Broadband Communications

 

-------------

 

Draft “SIP Extensions for Media Authorization” defines the Media-Authorization-Token as a hex blob. The draft does not force any meaning to the hex blob; the examples in the draft give two known uses for this field.

 

As described in the draft “Session setup with media authorization”, if there are to be many fields:

 

* All of these fields have to be send to the Edge Router.

 

* The End Host (UAS) does not necessarily know what is the meaning of any of the proposed fields.

 

As a result, we can say that there is no need for SIP defined sub-encoding(s) for the Media-Authorization-Token field. The token can be formatted and populated as PDP and PEP agrees.

 

Since it is impossible to predict from today what kind of information has to exchange will occur between PDP and PEP (for example one possible way is that the information will contain the Credit Card number to be billed) the best way is to threat the information as a byte blob.

 

The draft  “SIP Extensions for Media Authorization” does not state in any place (as incorrectly stated in draft “Session setup with media authorization”):

 

* The end-host is connected to a known point in the network.

 

*  Same policy server makes decisions related to both service authorization and resource utilization.

 

* Session managers and policy servers know each other’s existence and have a pre-defined trust relationship.

 

 The draft “SIP Extensions for Media Authorization” is written such that only the SIP protocol use is focused; the draft clearly defines how each SIP end will behave and how the information will be passed between them using SIP protocol. But it does not impose any other restrictions on any other entities or protocols. It is possible to device many other methods and elements that the creative authorization methods will take place and the draft only covers for all these protocols the question how to deliver the Media-Authorization information to the UAS in a generic way.

 

 As a summary it can be said that the draft “SIP Extensions for Media Authorization” includes all the features that draft “Session setup with media authorization” proposes and enables more features/modes.

 

 

------_=_NextPart_001_01C06953.ADEDFD92-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 07:09:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11508 for ; Tue, 19 Dec 2000 07:09:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4706E44366; Tue, 19 Dec 2000 06:07:31 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id DFA9444336 for ; Tue, 19 Dec 2000 05:35:10 -0500 (EST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10773; Tue, 19 Dec 2000 06:35:00 -0500 (EST) Message-Id: <200012191135.GAA10773@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: sip@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [SIP] I-D ACTION:draft-ietf-sip-isup-00.txt Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 06:34:59 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : ISUP to SIP Mapping Author(s) : G. Camarillo, A. Roach Filename : draft-ietf-sip-isup-00.txt Pages : 53 Date : 18-Dec-00 This document describes a way to perform the mapping between two signalling protocols: SIP and ISUP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-isup-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-isup-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-isup-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001218121724.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-isup-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-sip-isup-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001218121724.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 07:16:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA11743 for ; Tue, 19 Dec 2000 07:16:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6B18844371; Tue, 19 Dec 2000 06:16:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id 0A4804436F for ; Tue, 19 Dec 2000 06:15:47 -0500 (EST) Received: [from pobox4.mot.com (pobox4.mot.com [10.64.251.243]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id FAA11849 for ; Tue, 19 Dec 2000 05:15:32 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox4.mot.com (MOT-pobox4 2.0) with ESMTP id FAA19039 for ; Tue, 19 Dec 2000 05:15:32 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Tue, 19 Dec 2000 06:15:31 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8892@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "''sip@lists.bell-labs.com ' '" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Reversing TO and FROM fields Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 06:15:30 -0600 First, sorry 4 still being stuck with version 01 of the Bis... Para 16.4 (Terminating a call) talks about callee being able to abourt a call by simply reversing the TO and FROM field.. What does that mean? Any simple example please Thanks! Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 09:18:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA13932 for ; Tue, 19 Dec 2000 09:18:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A733644337; Tue, 19 Dec 2000 08:18:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web1106.mail.yahoo.com (web1106.mail.yahoo.com [128.11.23.126]) by lists.bell-labs.com (Postfix) with SMTP id 06BFC44336 for ; Tue, 19 Dec 2000 08:17:17 -0500 (EST) Received: (qmail 29977 invoked by uid 60001); 19 Dec 2000 14:17:04 -0000 Message-ID: <20001219141704.29976.qmail@web1106.mail.yahoo.com> Received: from [132.208.135.60] by web1106.mail.yahoo.com; Tue, 19 Dec 2000 15:17:04 CET From: =?iso-8859-1?q?rufin=20soh?= To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Re: SIP digest, Vol 1 #622 - 2 msgs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 15:17:04 +0100 (CET) Content-Transfer-Encoding: 8bit May be I am mistaking but I think that, SIP must remain a very light protocol. According to me you are trying to implement a sort of UAS, in proxy, and I don't know if you are working on the first version, if so,it is better to first work with as less codecs as possible. 2. Proxy must not issue, a request of its own other than ACK, or CANCEL, he just have to forward(lets say a 200) response, on receiving an INVITE, and hence, wait for communication to be established. 3. Make your UAS as simple as possible: don't try to make your tests with a UAS running on the same computer with a proxy. According to the draft, After a 200 response, the next step for proxy should be to wait for the communication stream, all other response or request could modify the state of the automate. --- sip-request@lists.bell-labs.com a écrit : > Send SIP mailing list submissions to > sip@lists.bell-labs.com > > To subscribe or unsubscribe via the World Wide Web, > visit > http://lists.bell-labs.com/mailman/listinfo/sip > or, via email, send a message with subject or body > 'help' to > sip-request@lists.bell-labs.com > > You can reach the person managing the list at > sip-admin@lists.bell-labs.com > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of SIP digest..." > > > Today's Topics: > > 1. Re: SIP digest, Vol 1 #620 - 10 msgs > (=?iso-8859-1?q?rufin=20soh?=) > 2. RE: Proxies modifying SDP (Baniel Uri-CUB001) > > ATTACHMENT part 3.1 message/rfc822 > Date: Mon, 18 Dec 2000 20:07:30 +0100 (CET) > De: rufin soh > À: sip@lists.bell-labs.com > Objet: [SIP] Re: SIP digest, Vol 1 #620 - 10 msgs > > I think for my own that, since proxies and sip > servers > are not completely implemented, after a 200 proxy > response, a UAS, instead of using codecs, should > better choose a well known (by proxy)frequency, to > send medias. If not, proxy will remain in a waiting > state, or all the responses could be handled as > "UNKNOWN RESPONSE".According to my fsm > implementation, > such responses are removed or just forwarded without > any further process, untill timeout. > > --- sip-request@lists.bell-labs.com a écrit : > Send > SIP mailing list submissions to > > sip@lists.bell-labs.com > > > > To subscribe or unsubscribe via the World Wide > Web, > > visit > > http://lists.bell-labs.com/mailman/listinfo/sip > > or, via email, send a message with subject or body > > 'help' to > > sip-request@lists.bell-labs.com > > > > You can reach the person managing the list at > > sip-admin@lists.bell-labs.com > > > > When replying, please edit your Subject line so it > > is more specific > > than "Re: Contents of SIP digest..." > > > > > Today's Topics: > > > > 1. Re: Inteligent Codec Selection (Sunitha > Kumar) > > 2. Record-Route and REGISTER (David Shrader) > > 3. State transition diagram for INVITE (Piotr > S. > > Kossowski) > > 4. Re: 8 bit clean channel (Henning > Schulzrinne) > > 5. RE: Proxies modifying SDP (Steve Donovan) > > 6. Re: RE: Changin local RTP port without a > good > > reason (Pekka Pessi) > > 7. Re: Bug in 2543bis-02 re: Record-Route > (Keith > > Robinson) > > 8. Re: Bug in 2543bis-02 re: Record-Route (Neil > > Deason) > > 9. Re: Proxy Routing Logic (Keith Robinson) > > 10. RE: Proxies modifying SDP > > (bcampbell@dynamicsoft.com) > > > > > ATTACHMENT part 3.1 message/rfc822 > > Date: Fri, 15 Dec 2000 16:17:38 -0800 > > De: Sunitha Kumar > > Affiliation: Cisco Systems > > À: tsearle@valhalla.marko.net > > CC: sip@lists.bell-labs.com > > Objet: Re: [SIP] Inteligent Codec Selection > > > > check out draft-manyfolks-sip-resource-01.txt. > > it talks about resource reservation. > > > > > > > > > > tsearle@valhalla.marko.net wrote: > > > > > I would like to set up a SIP solution that would > > negotiate to use G.711 > > > if there is sufficient bandwith between the two > > endpoints to do so, and would > > > negotiate G.723.1 otherwise. > > > > > > Is there any way to do codec negotiation in such > a > > manner? > > > > > > Torrey > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > -- > > Sunitha Kumar > > http://www.cisco.com > > > > > > > > > ATTACHMENT part 3.2 message/rfc822 > > Date: Sun, 17 Dec 2000 15:40:27 -0500 > > De: David Shrader > > À: SIP List > > Objet: [SIP] Record-Route and REGISTER > > > > I've been reading the record-route material and am > > considering its general > > application to SIP requests and find that there it > > is not as general as we > > think. > > > > The mechanism described in the bis-02 relies on > the > > interpretation of the > > Contact header only for some messages. That is, > the > > text states that the > > Contact header, if included, is appended to the > > Route list. This assumes > > that the Contact header is used only to represent > > the party to which a > > subsequent request along that route would be sent. > > > > When using the REGISTER method, however, the > Contact > > header is NOT used for > > that purpose. The Contact header in the Response > to > > a REGISTER is simply a > > list of registered contacts and does not in fact > > identify the recipient of a > > subsequent request. > > > > Scenario that generated this problem: > > 1. REGISTER is sent from UAC to an outbound > > proxy, addressed to a > > service provider (i.e., sip:provider.net) > > 2. The proxy inserts a Record-Route header > into > > the REGISTER message and > > routes it to the host for > sip:provider.net. > > 3. The server then echoes the Record-Route > > header in the response and > > several registered Contact headers. > > 4. The UAC then receives the Record-Route. > When > > it attempts to refresh > > its reservation, it cannot follow the > rules > > in the bis-02 spec > > because the Contact header cannot be used > as > > a Route header in this > > case. The message will never get to the > > registrar server because the > > Request-URI would indicate the received > > record-route header and > > there is no header to include the > > sip:provider.net URI. > > > > Any thoughts on a solution? > > > > I've thought it strange that the UAC is expected > to > > add the received Contact > > header to the Route list. Perhaps the solution is > > really that the UAS > > receiving the Record-Route header should add its > own > > Contact as the final > > Record-Route. In that way, the UAC doesn't have to > > do anything at all and > > there is no ambiguity due to the overloading of > > Contact header that we have > > done in the spec. > > > > > > ---------------------------- > > David Shrader > > Master Consultant, Inc. > > dshrader@master-consultant.com > > http://www.EyeForTheFuture.com > > > > > > > > > ATTACHMENT part 3.3 message/rfc822 > > Date: Sun, 17 Dec 2000 23:59:37 +0100 > > De: "Piotr S. Kossowski" > > > > Affiliation: Warsaw University of Technology - > > Institute of Telecommunications > > À: SIP discussion list > > Objet: [SIP] State transition diagram for INVITE > > > > Dear All, > > > > I'm a bit confused after long studying of Figure > 12 > > of the 2543 spec. > > There is State Machine for INVITE method there. > > I'm especially interested in two states: CONFIRMED > > and COMPLETED. > > > === message truncated === > ATTACHMENT part 3.2 message/rfc822 > De: Baniel Uri-CUB001 > À: "'Steve Donovan'" , > Baniel Uri-CUB001 , > "'Neil Deason'" , > jfmule@clarent.com, > bhoeneis@cc.hut.fi, sip@lists.bell-labs.com > Objet: RE: [SIP] Proxies modifying SDP > Date: Mon, 18 Dec 2000 19:05:17 -0600 > > Hmm... > Probably I was not clear and hence the confusion. > My intention was to be able to mimic the 'H323 gate > keeper mode' > functionality, i.e. to have the end points think > they talk to each other (in > the media streaming phase) but actually the media > goes via a gate keeper. In > our SIP world this should be just a MG (Media > Gateway). > The control may still go via a SIP proxy server, > that is why I think > changing SDP fields (specifically the IP address for > receiving media as well > as the RTP ports) may easily achieve this goal > > Uri > > -----Original Message----- > From: Steve Donovan > [mailto:sdonovan@dynamicsoft.com] > Sent: Sunday, December 17, 2000 9:12 PM > To: Baniel Uri-CUB001; 'Neil Deason'; > jfmule@clarent.com; > bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > Although I am having a hard time understanding why > it would be necessary to > modify the SDP to cause the call to go through a > specific gateway, as Neil > correctly points out, this is likely to be a > function of a back-to-back UA. > > Why is it not enough to have the proxy route the > call to the gateway in > question by changing the request-URI to point to the > gateway? > > Steve > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > Baniel Uri-CUB001 > > Sent: Friday, December 15, 2000 1:51 PM > > To: 'Neil Deason'; jfmule@clarent.com; > bhoeneis@cc.hut.fi; > > sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > I see it as the requested way of forcing the media > stream to go > > via an 'IP switch' (like the H323 MCU). > > If a proxy server is not allowed or if it is not > appropriate for > > it to touch the SDP element, then is there any > other way to make > > sure the media stream goes via our MCU gateway. > (There could be > > various of reasons why we would want to have such > a gateway) > > > > What do u think? > > > > Uri > > > > -----Original Message----- > > From: Neil Deason [mailto:neil_deason@hotmail.com] > > Sent: Friday, December 15, 2000 12:30 PM > > To: jfmule@clarent.com; bhoeneis@cc.hut.fi; > sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > > > >Bernie Hoeneisen wrote: > > > > I have question concerning the case, when SIP > proxies modify SDP, > > > > which is AFAIK against SIP principles, isn't > it? > > >I do not think so. > > >Why is that *against* SIP principles? What > principles?' > > > > The fundamental concept that payloads are opaque > to SIP Proxy > > Servers. To do this sort of thing you probably > want to use a > > back to back UA. > > > > Cheers, > > Neil. > > -- > > Ubiquity Software, UK > www.ubiquity.net > > > > > > In the concrete case, proxies would be able to > remove certain codecs > > > > from the INVITE messages, depending on the > current policy in the > > > > network. (The UAS gets a subset of the codecs, > which were originally > > > > sent by the UAC.) > > > > What impact does such a proxy behavior have to > SIP? I can think of > > > > problems with authentication and message > integrity checking (UAC signs > > > > message with its private key). > > >It certainly depends on the security mechanism > used. For e.g., with the > > >simple basic md5, it does not cause any issue. > > > > > >Jean-Francois > > > > > _________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com. > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > ___________________________________________________________ Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, Yahoo! Messenger : http://fr.messenger.yahoo.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 10:40:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA16283 for ; Tue, 19 Dec 2000 10:40:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C0E3544337; Tue, 19 Dec 2000 09:40:12 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id ECFBA44336 for ; Tue, 19 Dec 2000 09:39:15 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Dec 19 10:36:11 EST 2000 Received: by lists.bell-labs.com (Postfix) id 691E544380; Tue, 19 Dec 2000 10:24:04 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id E15444437D for ; Tue, 19 Dec 2000 10:24:03 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA04414; Tue, 19 Dec 2000 09:24:00 -0600 Cc: "''sip@lists.bell-labs.com ' '" Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA04360; Tue, 19 Dec 2000 09:23:58 -0600 Message-ID: <3A3F7D8E.72425015@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: Baniel Uri-CUB001 Original-CC: "''sip@lists.bell-labs.com ' '" Subject: Re: [SIP] Reversing TO and FROM fields References: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8892@il27exm02.cig.mot.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 09:23:58 -0600 Content-Transfer-Encoding: 7bit Baniel Uri-CUB001 wrote: > > First, sorry 4 still being stuck with version 01 of the Bis... > Para 16.4 (Terminating a call) talks about callee being able to abourt a > call by simply reversing the TO and FROM field.. > > What does that mean? Any simple example please I think the intent of that paragraph is to state that if the callee (and not the caller) wants to end the call, the To and From will be reversed. Assume the following: UAC UAS INVITE ----> To: A From: B <------ 200 OK To: A;tag=ffe1a From: B ACK ---> To: A;tag=ffe1a From: B If the UAC hangs up, the To and From URIs remain the same; if on the other hand, the UAS (callee) hangs up, the To and From will be reversed; i.e. UAC UAS <------ BYE To: B From: A;tag=ffe1a Both the To and From retain the tags (see Section 11.4 in the 01 bis for more info). - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 11:43:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA17828 for ; Tue, 19 Dec 2000 11:43:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 28A5E44344; Tue, 19 Dec 2000 10:43:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from commserver.iperia.com (mailhost.iperia.com [207.31.192.99]) by lists.bell-labs.com (Postfix) with ESMTP id 7DA4B44336 for ; Tue, 19 Dec 2000 10:42:56 -0500 (EST) Received: by commserver.iperia.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 11:43:26 -0500 Message-ID: <5143F854B82ED211B05E00104B235F645AC12C@commserver.iperia.com> From: Steve Gardell To: "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 11:43:25 -0500 If memory serves, a "fully routed" H.323 gatekeepers routes the media negotiation signalling, but does not route the actual RTP traffic. -----Original Message----- From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] Sent: Monday, December 18, 2000 8:05 PM To: 'Steve Donovan'; Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP Hmm... Probably I was not clear and hence the confusion. My intention was to be able to mimic the 'H323 gate keeper mode' functionality, i.e. to have the end points think they talk to each other (in the media streaming phase) but actually the media goes via a gate keeper. In our SIP world this should be just a MG (Media Gateway). The control may still go via a SIP proxy server, that is why I think changing SDP fields (specifically the IP address for receiving media as well as the RTP ports) may easily achieve this goal Uri -----Original Message----- From: Steve Donovan [mailto:sdonovan@dynamicsoft.com] Sent: Sunday, December 17, 2000 9:12 PM To: Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP Although I am having a hard time understanding why it would be necessary to modify the SDP to cause the call to go through a specific gateway, as Neil correctly points out, this is likely to be a function of a back-to-back UA. Why is it not enough to have the proxy route the call to the gateway in question by changing the request-URI to point to the gateway? Steve > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Baniel Uri-CUB001 > Sent: Friday, December 15, 2000 1:51 PM > To: 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; > sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > I see it as the requested way of forcing the media stream to go > via an 'IP switch' (like the H323 MCU). > If a proxy server is not allowed or if it is not appropriate for > it to touch the SDP element, then is there any other way to make > sure the media stream goes via our MCU gateway. (There could be > various of reasons why we would want to have such a gateway) > > What do u think? > > Uri > > -----Original Message----- > From: Neil Deason [mailto:neil_deason@hotmail.com] > Sent: Friday, December 15, 2000 12:30 PM > To: jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > > >Bernie Hoeneisen wrote: > > > I have question concerning the case, when SIP proxies modify SDP, > > > which is AFAIK against SIP principles, isn't it? > >I do not think so. > >Why is that *against* SIP principles? What principles?' > > The fundamental concept that payloads are opaque to SIP Proxy > Servers. To do this sort of thing you probably want to use a > back to back UA. > > Cheers, > Neil. > -- > Ubiquity Software, UK www.ubiquity.net > > > > In the concrete case, proxies would be able to remove certain codecs > > > from the INVITE messages, depending on the current policy in the > > > network. (The UAS gets a subset of the codecs, which were originally > > > sent by the UAC.) > > > What impact does such a proxy behavior have to SIP? I can think of > > > problems with authentication and message integrity checking (UAC signs > > > message with its private key). > >It certainly depends on the security mechanism used. For e.g., with the > >simple basic md5, it does not cause any issue. > > > >Jean-Francois > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 11:57:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA18196 for ; Tue, 19 Dec 2000 11:57:31 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8C4C44355; Tue, 19 Dec 2000 10:57:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from newman.frascone.com (frascone.com [216.62.83.25]) by lists.bell-labs.com (Postfix) with ESMTP id 3AA6744336 for ; Tue, 19 Dec 2000 10:56:34 -0500 (EST) Received: (from chaos@localhost) by newman.frascone.com (8.9.3/8.9.3) id KAA04590; Tue, 19 Dec 2000 10:56:06 -0600 From: David Frascone To: Steve Gardell Cc: "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com Subject: Re: [SIP] Proxies modifying SDP Message-ID: <20001219105603.G4115@newman.frascone.com> Mail-Followup-To: Steve Gardell , 'Baniel Uri-CUB001' , sip@lists.bell-labs.com References: <5143F854B82ED211B05E00104B235F645AC12C@commserver.iperia.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <5143F854B82ED211B05E00104B235F645AC12C@commserver.iperia.com>; from sgardell@iperia.com on Tue, Dec 19, 2000 at 11:43:25AM -0500 X-encrypt-payload: no Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 10:56:04 -0600 This might be a useless response, since I can't find the example document that I'm about to refer too . . but . . . In the documents I read before San Diego, I remember two pictures of a proxied senario. In the first, the SIP requests were proxied, but the RTP was sent normally. In the second, the SIP requests were proxied, *and* the RTP was proxied. In this senario, didn't the SIP proxy have to modify the SDP to get it to work? Please: I know someone else read this document, or saw the slides I'm refering too . . . . Someone help refresh my poor tired memory :) -Dave On Tue, Dec 19, 2000 at 11:43:25AM -0500, Steve Gardell wrote: > If memory serves, a "fully routed" H.323 gatekeepers routes the media > negotiation signalling, but does not route the actual RTP traffic. > > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Monday, December 18, 2000 8:05 PM > To: 'Steve Donovan'; Baniel Uri-CUB001; 'Neil Deason'; > jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > Hmm... > Probably I was not clear and hence the confusion. > My intention was to be able to mimic the 'H323 gate keeper mode' > functionality, i.e. to have the end points think they talk to each other (in > the media streaming phase) but actually the media goes via a gate keeper. In > our SIP world this should be just a MG (Media Gateway). > The control may still go via a SIP proxy server, that is why I think > changing SDP fields (specifically the IP address for receiving media as well > as the RTP ports) may easily achieve this goal > > Uri > > -----Original Message----- > From: Steve Donovan [mailto:sdonovan@dynamicsoft.com] > Sent: Sunday, December 17, 2000 9:12 PM > To: Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; > bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > Although I am having a hard time understanding why it would be necessary to > modify the SDP to cause the call to go through a specific gateway, as Neil > correctly points out, this is likely to be a function of a back-to-back UA. > > Why is it not enough to have the proxy route the call to the gateway in > question by changing the request-URI to point to the gateway? > > Steve > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Baniel Uri-CUB001 > > Sent: Friday, December 15, 2000 1:51 PM > > To: 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; > > sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > I see it as the requested way of forcing the media stream to go > > via an 'IP switch' (like the H323 MCU). > > If a proxy server is not allowed or if it is not appropriate for > > it to touch the SDP element, then is there any other way to make > > sure the media stream goes via our MCU gateway. (There could be > > various of reasons why we would want to have such a gateway) > > > > What do u think? > > > > Uri > > > > -----Original Message----- > > From: Neil Deason [mailto:neil_deason@hotmail.com] > > Sent: Friday, December 15, 2000 12:30 PM > > To: jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > > > >Bernie Hoeneisen wrote: > > > > I have question concerning the case, when SIP proxies modify SDP, > > > > which is AFAIK against SIP principles, isn't it? > > >I do not think so. > > >Why is that *against* SIP principles? What principles?' > > > > The fundamental concept that payloads are opaque to SIP Proxy > > Servers. To do this sort of thing you probably want to use a > > back to back UA. > > > > Cheers, > > Neil. > > -- > > Ubiquity Software, UK www.ubiquity.net > > > > > > In the concrete case, proxies would be able to remove certain codecs > > > > from the INVITE messages, depending on the current policy in the > > > > network. (The UAS gets a subset of the codecs, which were originally > > > > sent by the UAC.) > > > > What impact does such a proxy behavior have to SIP? I can think of > > > > problems with authentication and message integrity checking (UAC signs > > > > message with its private key). > > >It certainly depends on the security mechanism used. For e.g., with the > > >simple basic md5, it does not cause any issue. > > > > > >Jean-Francois > > > > _________________________________________________________________________ > > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 12:01:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18314 for ; Tue, 19 Dec 2000 12:01:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B25CD44359; Tue, 19 Dec 2000 11:01:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 181EE44336 for ; Tue, 19 Dec 2000 11:00:15 -0500 (EST) Received: from CINQUECENTO ([63.110.3.212]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id MAA15345; Tue, 19 Dec 2000 12:02:32 -0500 (EST) From: "Robert Sparks" To: "Fairlie-Cuninghame, Robert" , Subject: RE: [SIP] 3pcc callflow question (Was:Changin local RTP port without a good reason) 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.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 10:57:30 -0600 Content-Transfer-Encoding: 7bit Doesn't matter. Notice that in the original diagram, A1 isn't used in the negotiation with B. If A automatically returns held sdp when it recieves held sdp, things don't break. Out of curiosity, does anyone have a UA deployed that won't accept an initial INVITE to held media? If so, it argues for using the delayed media approach you suggest. RjS > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Fairlie-Cuninghame, > Robert > Sent: Tuesday, December 19, 2000 12:51 AM > To: sip@lists.bell-labs.com > Subject: RE: [SIP] 3pcc callflow question (Was:Changin local RTP port > without a good reason) > > > > An alternative flow has already been proposed which does not > > suffer from the > > timeout problem, and which does not have this race condition: > > > > > > > A Controller B > > > > | INV SDP held | | time t = 0 > > > > |<------------------| | > > > > | | | > > > > | 200 SDP A1 | | > > > > |-----------------> | | > > > > | | | > > > > | ACK | | > > > > |<------------------| | > > > > | | | > > Sorry to go back a bit but can I forget the reason why it was > decided not to > start with: > > A Controller > > INV no SDP > <-------- > > 200 SDP A1 > --------> > > ACK SDP held > <-------- > > This seems simpler as both A and B are behaving in the same manner (rather > than A having to realize that it must produce SDP A1 when it receives an > initial SDP held). > > Was it because of crash-restart problems ? > > Regards, > > Robert. > > > > > > | | INV no SDP | > > > > | |----------------->| (1) > > > > | | | > > > > | | 200 SDP B | > > > > | |<-----------------| > > > > | INV SDP B | | > > > > |<------------------| | > > > > | | | > > > > | 200 SDP A2 | | > > > > |-----------------> | | > > > > | | | > > > > | | ACK SDP A2 | > > > > | ACK |----------------->| > > > > |<------------------| | > > > > | | | > > > > | | RTP | > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > | | | > > > > > > I'd like to start with this one as the basis for continuing > > discussion/concerns. > > > > -Jonathan R. > > > > > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 12:23:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18793 for ; Tue, 19 Dec 2000 12:23:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8AA8344346; Tue, 19 Dec 2000 11:23:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 9C0D044337 for ; Tue, 19 Dec 2000 11:22:06 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 19 Dec 2000 17:21:57 UT Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id RAA06494; Tue, 19 Dec 2000 17:20:25 GMT Message-ID: <3A3F98D9.561E930D@ubiquity.net> From: Neil Deason Organization: Ubiquity Software Corporation Limited X-Mailer: Mozilla 4.51 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: David Frascone Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Proxies modifying SDP References: <5143F854B82ED211B05E00104B235F645AC12C@commserver.iperia.com> <20001219105603.G4115@newman.frascone.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 17:20:25 +0000 Content-Transfer-Encoding: 7bit David Frascone wrote: > > This might be a useless response, since I can't find the example document that > I'm about to refer too . . but . . . In the documents I read before San Diego, > I remember two pictures of a proxied senario. > > In the first, the SIP requests were proxied, but the RTP was sent normally. > > In the second, the SIP requests were proxied, *and* the RTP was proxied. In > this senario, didn't the SIP proxy have to modify the SDP to get it to work? > > Please: I know someone else read this document, or saw the slides I'm > refering too . . . . Someone help refresh my poor tired memory :) This sounds like the sort of ugliness forced upon us by firewalls. Maybe you're thinking of draft-rosenberg-sip-entfw-00.txt hth, Neil. -- Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 12:29:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA18962 for ; Tue, 19 Dec 2000 12:29:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E5F4144359; Tue, 19 Dec 2000 11:29:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by lists.bell-labs.com (Postfix) with ESMTP id C94D344346 for ; Tue, 19 Dec 2000 11:28:17 -0500 (EST) Received: from beta.hut.fi (beta.hut.fi [130.233.224.51]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id TAA30440; Tue, 19 Dec 2000 19:27:58 +0200 (EET) From: Bernie Hoeneisen To: bcampbell@dynamicsoft.com Cc: Steve Donovan , Baniel Uri-CUB001 , Neil Deason , jfmule@clarent.com, bhoeneis@cc.hut.fi, sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP In-Reply-To: <200012181422.JAA02842@redball.dynamicsoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 19:27:57 +0200 (EET) Hi again On Mon, 18 Dec 2000 bcampbell@dynamicsoft.com wrote: > I suspect the original writer refers to some sort of media gateway > that is not SIP enabled. Therefore one could not simply proxy the > call to the gateway. My original question was a bit different one and it is not directly related to media gateways. In the case I was describing, there are SIP proxies, which know about policy in the network and would interact while the INVITE is passing them. Such proxies would remove certain codecs from the SDP. I have some doubts, that it is a good idea... Thus, I am posting my original question again (see below, last line). Hoping for more comments on this... Cheers Bernie PS: Here my original email: On Fri, 15 Dec 2000, Bernie Hoeneisen wrote: > I have question concerning the case, when SIP proxies modify SDP, > which is AFAIK against SIP principles, isn't it? > > In the concrete case, proxies would be able to remove certain codecs > from the INVITE messages, depending on the current policy in the > network. (The UAS gets a subset of the codecs, which were originally > sent by the UAC.) > > What impact does such a proxy behavior have to SIP? I can think of > problems with authentication and message integrity checking (UAC signs > message with its private key). > > Are there any other problems? Any comments are appreciated. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 12:33:20 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19089 for ; Tue, 19 Dec 2000 12:33:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C47124437C; Tue, 19 Dec 2000 11:30:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from zrtps06s.us.nortel.com (h50s48a140n47.user.nortelnetworks.com [47.140.48.50]) by lists.bell-labs.com (Postfix) with ESMTP id B846944346 for ; Tue, 19 Dec 2000 11:29:02 -0500 (EST) Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 19 Dec 2000 12:11:43 -0500 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 19 Dec 2000 12:11:32 -0500 Message-ID: <63E0DAD7784FD21188310000F80824B30545F645@zmpkdx02.us.nortel.com> From: "Francois Audet" To: "'Steve Gardell'" , "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C069DE.6A5CB290" X-Orig: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 12:09:15 -0500 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_01C069DE.6A5CB290 Content-Type: text/plain; charset="iso-8859-1" Indeed. Media never goes through the gatekeeper. -----Original Message----- From: Steve Gardell [mailto:sgardell@iperia.com] Sent: Tuesday, December 19, 2000 08:43 To: 'Baniel Uri-CUB001'; sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP If memory serves, a "fully routed" H.323 gatekeepers routes the media negotiation signalling, but does not route the actual RTP traffic. -----Original Message----- From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] Sent: Monday, December 18, 2000 8:05 PM To: 'Steve Donovan'; Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP Hmm... Probably I was not clear and hence the confusion. My intention was to be able to mimic the 'H323 gate keeper mode' functionality, i.e. to have the end points think they talk to each other (in the media streaming phase) but actually the media goes via a gate keeper. In our SIP world this should be just a MG (Media Gateway). The control may still go via a SIP proxy server, that is why I think changing SDP fields (specifically the IP address for receiving media as well as the RTP ports) may easily achieve this goal Uri -----Original Message----- From: Steve Donovan [mailto:sdonovan@dynamicsoft.com] Sent: Sunday, December 17, 2000 9:12 PM To: Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP Although I am having a hard time understanding why it would be necessary to modify the SDP to cause the call to go through a specific gateway, as Neil correctly points out, this is likely to be a function of a back-to-back UA. Why is it not enough to have the proxy route the call to the gateway in question by changing the request-URI to point to the gateway? Steve > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Baniel Uri-CUB001 > Sent: Friday, December 15, 2000 1:51 PM > To: 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; > sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > I see it as the requested way of forcing the media stream to go > via an 'IP switch' (like the H323 MCU). > If a proxy server is not allowed or if it is not appropriate for > it to touch the SDP element, then is there any other way to make > sure the media stream goes via our MCU gateway. (There could be > various of reasons why we would want to have such a gateway) > > What do u think? > > Uri > > -----Original Message----- > From: Neil Deason [mailto:neil_deason@hotmail.com] > Sent: Friday, December 15, 2000 12:30 PM > To: jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > > >Bernie Hoeneisen wrote: > > > I have question concerning the case, when SIP proxies modify SDP, > > > which is AFAIK against SIP principles, isn't it? > >I do not think so. > >Why is that *against* SIP principles? What principles?' > > The fundamental concept that payloads are opaque to SIP Proxy > Servers. To do this sort of thing you probably want to use a > back to back UA. > > Cheers, > Neil. > -- > Ubiquity Software, UK www.ubiquity.net > > > > In the concrete case, proxies would be able to remove certain codecs > > > from the INVITE messages, depending on the current policy in the > > > network. (The UAS gets a subset of the codecs, which were originally > > > sent by the UAC.) > > > What impact does such a proxy behavior have to SIP? I can think of > > > problems with authentication and message integrity checking (UAC signs > > > message with its private key). > >It certainly depends on the security mechanism used. For e.g., with the > >simple basic md5, it does not cause any issue. > > > >Jean-Francois > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip ------_=_NextPart_001_01C069DE.6A5CB290 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [SIP] Proxies modifying SDP

Indeed. Media never goes through the = gatekeeper.

-----Original Message-----
From: Steve Gardell [mailto:sgardell@iperia.com]
Sent: Tuesday, December 19, 2000 08:43
To: 'Baniel Uri-CUB001'; = sip@lists.bell-labs.com
Subject: RE: [SIP] Proxies modifying SDP


If memory serves, a "fully routed" H.323 = gatekeepers routes the media
negotiation signalling, but does not route the = actual RTP traffic.

-----Original Message-----
From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com]
Sent: Monday, December 18, 2000 8:05 PM
To: 'Steve Donovan'; Baniel Uri-CUB001; 'Neil = Deason';
jfmule@clarent.com; bhoeneis@cc.hut.fi; = sip@lists.bell-labs.com
Subject: RE: [SIP] Proxies modifying SDP


Hmm...
Probably I was not clear and hence the = confusion.
My intention was to be able to mimic the 'H323 gate = keeper mode'
functionality, i.e. to have the end points think = they talk to each other (in
the media streaming phase) but actually the media = goes via a gate keeper. In
our SIP world this should be just a MG (Media = Gateway).
The control may still go via a SIP proxy server, = that is why I think
changing SDP fields (specifically the IP address for = receiving media as well
as the RTP ports) may easily achieve this = goal

Uri

-----Original Message-----
From: Steve Donovan [mailto:sdonovan@dynamicsoft.com= ]
Sent: Sunday, December 17, 2000 9:12 PM
To: Baniel Uri-CUB001; 'Neil Deason'; = jfmule@clarent.com;
bhoeneis@cc.hut.fi; sip@lists.bell-labs.com
Subject: RE: [SIP] Proxies modifying SDP


Although I am having a hard time understanding why it = would be necessary to
modify the SDP to cause the call to go through a = specific gateway, as Neil
correctly points out, this is likely to be a = function of a back-to-back UA.

Why is it not enough to have the proxy route the call = to the gateway in
question by changing the request-URI to point to the = gateway?

Steve

> -----Original Message-----
> From: sip-admin@lists.bell-labs.com
> [mailto:sip-admin@lists.bel= l-labs.com]On Behalf Of Baniel Uri-CUB001
> Sent: Friday, December 15, 2000 1:51 PM
> To: 'Neil Deason'; jfmule@clarent.com; = bhoeneis@cc.hut.fi;
> sip@lists.bell-labs.com
> Subject: RE: [SIP] Proxies modifying SDP
>
>
> I see it as the requested way of forcing the = media stream to go
> via an 'IP switch' (like the H323 MCU).
> If a proxy server is not allowed or if it is = not appropriate for
> it to touch the SDP element, then is there any = other way to make
> sure the media stream goes via our MCU gateway. = (There could be
> various of reasons why we would want to have = such a gateway)
>
> What do u think?
>
> Uri
>
> -----Original Message-----
> From: Neil Deason [mailto:neil_deason@hotmail.com]
> Sent: Friday, December 15, 2000 12:30 PM
> To: jfmule@clarent.com; bhoeneis@cc.hut.fi; = sip@lists.bell-labs.com
> Subject: RE: [SIP] Proxies modifying SDP
>
>
>
> >Bernie Hoeneisen wrote:
> > > I have question concerning the case, = when SIP proxies modify SDP,
> > > which is AFAIK against SIP = principles, isn't it?
> >I do not think so.
> >Why is that *against* SIP principles?  = What principles?'
>
> The fundamental concept that payloads are = opaque to SIP Proxy
> Servers. To do this sort of thing you probably = want to use a
> back to back UA.
>
> Cheers,
> Neil.
> --
> Ubiquity Software, = UK           &nbs= p;        www.ubiquity.net
>
> > > In the concrete case, proxies would = be able to remove certain codecs
> > > from the INVITE messages, depending = on the current policy in the
> > > network. (The UAS gets a subset of = the codecs, which were originally
> > > sent by the UAC.)
> > > What impact does such a proxy = behavior have to SIP? I can think of
> > > problems with authentication and = message integrity checking (UAC signs
> > > message with its private key).
> >It certainly depends on the security = mechanism used.  For e.g., with the
> >simple basic md5, it does not cause any = issue.
> >
> >Jean-Francois
>
> = ________________________________________________________________________= _
> Get Your Private, Free E-mail from MSN Hotmail = at http://www.hotmail.com.
>
>
> = _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>
> = _______________________________________________
> SIP mailing list
> SIP@lists.bell-labs.com
> http://lists.bell-labs.com/mailman/listinfo/sip
>

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
SIP@lists.bell-labs.com
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_001_01C069DE.6A5CB290-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 12:37:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19229 for ; Tue, 19 Dec 2000 12:37:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF23444385; Tue, 19 Dec 2000 11:34:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from newman.frascone.com (frascone.com [216.62.83.25]) by lists.bell-labs.com (Postfix) with ESMTP id 0122A4436C for ; Tue, 19 Dec 2000 11:33:12 -0500 (EST) Received: (from chaos@localhost) by newman.frascone.com (8.9.3/8.9.3) id LAA04859; Tue, 19 Dec 2000 11:32:49 -0600 From: David Frascone To: Neil Deason Cc: David Frascone , sip@lists.bell-labs.com Subject: Re: [SIP] Proxies modifying SDP Message-ID: <20001219113247.H4115@newman.frascone.com> Mail-Followup-To: Neil Deason , David Frascone , sip@lists.bell-labs.com References: <5143F854B82ED211B05E00104B235F645AC12C@commserver.iperia.com> <20001219105603.G4115@newman.frascone.com> <3A3F98D9.561E930D@ubiquity.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.4i In-Reply-To: <3A3F98D9.561E930D@ubiquity.net>; from ndeason@ubiquity.net on Tue, Dec 19, 2000 at 05:20:25PM +0000 X-encrypt-payload: no Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 11:32:48 -0600 That wasn't the one, but it also illustrates it. Is there any way to do such ugliness without modifying SDP? I'm trying to leave a SDP parser out of my SIP proxy, but it looks like I might need to include one :( On Tue, Dec 19, 2000 at 05:20:25PM +0000, Neil Deason wrote: > David Frascone wrote: > > > > This might be a useless response, since I can't find the example document that > > I'm about to refer too . . but . . . In the documents I read before San Diego, > > I remember two pictures of a proxied senario. > > > > In the first, the SIP requests were proxied, but the RTP was sent normally. > > > > In the second, the SIP requests were proxied, *and* the RTP was proxied. In > > this senario, didn't the SIP proxy have to modify the SDP to get it to work? > > > > Please: I know someone else read this document, or saw the slides I'm > > refering too . . . . Someone help refresh my poor tired memory :) > > This sounds like the sort of ugliness forced upon us by > firewalls. Maybe you're thinking of > draft-rosenberg-sip-entfw-00.txt > > hth, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 12:43:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19375 for ; Tue, 19 Dec 2000 12:43:23 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 080DE4437B; Tue, 19 Dec 2000 11:39:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id D273D4436C for ; Tue, 19 Dec 2000 11:38:46 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA13168 for ; Tue, 19 Dec 2000 10:38:36 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA12428 for ; Tue, 19 Dec 2000 10:35:29 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Tue, 19 Dec 2000 11:38:36 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8898@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'Steve Gardell'" , Baniel Uri-CUB001 , sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 11:38:35 -0600 Steve you are definitely right. H323 Gatekeepers can choose have the signaling go via them or go directly between the end points (or between one of them and an end point) , but that has nothing to do with the media. It is true though that when a gate keeper 'advertises' the media information of the end point it represents to the other side, it may actually advertise a MG, but you said it already... Sorry for the mistake Uri -----Original Message----- From: Steve Gardell [mailto:sgardell@iperia.com] Sent: Tuesday, December 19, 2000 10:43 AM To: 'Baniel Uri-CUB001'; sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP If memory serves, a "fully routed" H.323 gatekeepers routes the media negotiation signalling, but does not route the actual RTP traffic. -----Original Message----- From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] Sent: Monday, December 18, 2000 8:05 PM To: 'Steve Donovan'; Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP Hmm... Probably I was not clear and hence the confusion. My intention was to be able to mimic the 'H323 gate keeper mode' functionality, i.e. to have the end points think they talk to each other (in the media streaming phase) but actually the media goes via a gate keeper. In our SIP world this should be just a MG (Media Gateway). The control may still go via a SIP proxy server, that is why I think changing SDP fields (specifically the IP address for receiving media as well as the RTP ports) may easily achieve this goal Uri -----Original Message----- From: Steve Donovan [mailto:sdonovan@dynamicsoft.com] Sent: Sunday, December 17, 2000 9:12 PM To: Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP Although I am having a hard time understanding why it would be necessary to modify the SDP to cause the call to go through a specific gateway, as Neil correctly points out, this is likely to be a function of a back-to-back UA. Why is it not enough to have the proxy route the call to the gateway in question by changing the request-URI to point to the gateway? Steve > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Baniel Uri-CUB001 > Sent: Friday, December 15, 2000 1:51 PM > To: 'Neil Deason'; jfmule@clarent.com; bhoeneis@cc.hut.fi; > sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > I see it as the requested way of forcing the media stream to go > via an 'IP switch' (like the H323 MCU). > If a proxy server is not allowed or if it is not appropriate for > it to touch the SDP element, then is there any other way to make > sure the media stream goes via our MCU gateway. (There could be > various of reasons why we would want to have such a gateway) > > What do u think? > > Uri > > -----Original Message----- > From: Neil Deason [mailto:neil_deason@hotmail.com] > Sent: Friday, December 15, 2000 12:30 PM > To: jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > > >Bernie Hoeneisen wrote: > > > I have question concerning the case, when SIP proxies modify SDP, > > > which is AFAIK against SIP principles, isn't it? > >I do not think so. > >Why is that *against* SIP principles? What principles?' > > The fundamental concept that payloads are opaque to SIP Proxy > Servers. To do this sort of thing you probably want to use a > back to back UA. > > Cheers, > Neil. > -- > Ubiquity Software, UK www.ubiquity.net > > > > In the concrete case, proxies would be able to remove certain codecs > > > from the INVITE messages, depending on the current policy in the > > > network. (The UAS gets a subset of the codecs, which were originally > > > sent by the UAC.) > > > What impact does such a proxy behavior have to SIP? I can think of > > > problems with authentication and message integrity checking (UAC signs > > > message with its private key). > >It certainly depends on the security mechanism used. For e.g., with the > >simple basic md5, it does not cause any issue. > > > >Jean-Francois > > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 12:47:35 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19506 for ; Tue, 19 Dec 2000 12:47:35 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 59FBE4438D; Tue, 19 Dec 2000 11:43:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id AE2C34438B for ; Tue, 19 Dec 2000 11:42:38 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA17889 for ; Tue, 19 Dec 2000 10:42:25 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA29966 for ; Tue, 19 Dec 2000 10:42:25 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Tue, 19 Dec 2000 11:42:25 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8899@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'Bernie Hoeneisen'" , bcampbell@dynamicsoft.com Cc: Steve Donovan , Baniel Uri-CUB001 , Neil Deason , jfmule@clarent.com, sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 11:42:01 -0600 Bernie I do not think it is a bad idea at all. I think that when you run a commercial network, in which subscriber has to pay for capabilities/services etc, you have no choice but to have control over the media he/she is asking to use. E.g. If one paid for using audio service only and all of the sudden asks for video stream as well, you may want to discard the video media from the SDP request Hope that helps Uri -----Original Message----- From: Bernie Hoeneisen [mailto:bhoeneis@cc.hut.fi] Sent: Tuesday, December 19, 2000 11:28 AM To: bcampbell@dynamicsoft.com Cc: Steve Donovan; Baniel Uri-CUB001; Neil Deason; jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP Hi again On Mon, 18 Dec 2000 bcampbell@dynamicsoft.com wrote: > I suspect the original writer refers to some sort of media gateway > that is not SIP enabled. Therefore one could not simply proxy the > call to the gateway. My original question was a bit different one and it is not directly related to media gateways. In the case I was describing, there are SIP proxies, which know about policy in the network and would interact while the INVITE is passing them. Such proxies would remove certain codecs from the SDP. I have some doubts, that it is a good idea... Thus, I am posting my original question again (see below, last line). Hoping for more comments on this... Cheers Bernie PS: Here my original email: On Fri, 15 Dec 2000, Bernie Hoeneisen wrote: > I have question concerning the case, when SIP proxies modify SDP, > which is AFAIK against SIP principles, isn't it? > > In the concrete case, proxies would be able to remove certain codecs > from the INVITE messages, depending on the current policy in the > network. (The UAS gets a subset of the codecs, which were originally > sent by the UAC.) > > What impact does such a proxy behavior have to SIP? I can think of > problems with authentication and message integrity checking (UAC signs > message with its private key). > > Are there any other problems? Any comments are appreciated. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 12:54:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA19746 for ; Tue, 19 Dec 2000 12:54:26 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 834DB4438B; Tue, 19 Dec 2000 11:52:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ftpbox.mot.com (ftpbox.mot.com [129.188.136.101]) by lists.bell-labs.com (Postfix) with ESMTP id CF53544337 for ; Tue, 19 Dec 2000 11:51:29 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by ftpbox.mot.com (ftpbox 2.1) with ESMTP id KAA27803 for ; Tue, 19 Dec 2000 10:51:20 -0700 (MST)] Received: [from il75exm02.cig.mot.com (IL75EXM02.cig.mot.com [136.182.110.102]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA07948 for ; Tue, 19 Dec 2000 10:51:19 -0700 (MST)] Received: by IL75EXM02.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Tue, 19 Dec 2000 11:51:19 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED889E@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'David Frascone'" , Neil Deason Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 11:51:18 -0600 Guys You can not change (IP1,Port1) (for RTP) to (Ip2,Port2) without touching it... We are still just human beings and the proxies are just machines :) Uri -----Original Message----- From: David Frascone [mailto:dave@frascone.com] Sent: Tuesday, December 19, 2000 11:33 AM To: Neil Deason Cc: David Frascone; sip@lists.bell-labs.com Subject: Re: [SIP] Proxies modifying SDP That wasn't the one, but it also illustrates it. Is there any way to do such ugliness without modifying SDP? I'm trying to leave a SDP parser out of my SIP proxy, but it looks like I might need to include one :( On Tue, Dec 19, 2000 at 05:20:25PM +0000, Neil Deason wrote: > David Frascone wrote: > > > > This might be a useless response, since I can't find the example document that > > I'm about to refer too . . but . . . In the documents I read before San Diego, > > I remember two pictures of a proxied senario. > > > > In the first, the SIP requests were proxied, but the RTP was sent normally. > > > > In the second, the SIP requests were proxied, *and* the RTP was proxied. In > > this senario, didn't the SIP proxy have to modify the SDP to get it to work? > > > > Please: I know someone else read this document, or saw the slides I'm > > refering too . . . . Someone help refresh my poor tired memory :) > > This sounds like the sort of ugliness forced upon us by > firewalls. Maybe you're thinking of > draft-rosenberg-sip-entfw-00.txt > > hth, > Neil. > -- > Ubiquity Software Corporation, UK http://www.ubiquity.net _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 13:00:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19901 for ; Tue, 19 Dec 2000 13:00:25 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EBFEF4439B; Tue, 19 Dec 2000 11:56:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from tiku.hut.fi (tiku.hut.fi [130.233.228.86]) by lists.bell-labs.com (Postfix) with ESMTP id 4E9524437B for ; Tue, 19 Dec 2000 11:55:19 -0500 (EST) Received: from beta.hut.fi (beta.hut.fi [130.233.224.51]) by tiku.hut.fi (8.9.3/8.9.3) with ESMTP id TAA16223; Tue, 19 Dec 2000 19:55:01 +0200 (EET) From: Bernie Hoeneisen To: Baniel Uri-CUB001 Cc: "'Bernie Hoeneisen'" , bcampbell@dynamicsoft.com, Steve Donovan , Neil Deason , jfmule@clarent.com, sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP In-Reply-To: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8899@il27exm02.cig.mot.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 19:55:00 +0200 (EET) Uri, I am not against the idea, that such things have to be controled. The example actually concerns a commercial network with limited resources. I am just worried about the possible negative impact to other SIP functionality. I want to ensure: If we solve the mentioned problem by proxies modifying SDP, that we do not cause new problems at some other place. I am trying to figure out, whether there is such negative impact, and if yes, what problems it will cause. cheers, Bernie On Tue, 19 Dec 2000, Baniel Uri-CUB001 wrote: > Bernie > > I do not think it is a bad idea at all. I think that when you run a > commercial network, in which subscriber has to pay for > capabilities/services etc, you have no choice but to have control over > the media he/she is asking to use. E.g. If one paid for using audio > service only and all of the sudden asks for video stream as well, you > may want to discard the video media from the SDP request > > Hope that helps > > Uri > > -----Original Message----- > From: Bernie Hoeneisen [mailto:bhoeneis@cc.hut.fi] > Sent: Tuesday, December 19, 2000 11:28 AM > To: bcampbell@dynamicsoft.com > Cc: Steve Donovan; Baniel Uri-CUB001; Neil Deason; jfmule@clarent.com; > bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > Hi again > > On Mon, 18 Dec 2000 bcampbell@dynamicsoft.com wrote: > > > I suspect the original writer refers to some sort of media gateway > > that is not SIP enabled. Therefore one could not simply proxy the > > call to the gateway. > > My original question was a bit different one and it is not directly > related to media gateways. > In the case I was describing, there are SIP proxies, which know about > policy in the network and would interact while the INVITE is > passing them. Such proxies would remove certain codecs from the SDP. > I have some doubts, that it is a good idea... > > Thus, I am posting my original question again (see below, last line). > > Hoping for more comments on this... > > Cheers > Bernie > > PS: Here my original email: > > > On Fri, 15 Dec 2000, Bernie Hoeneisen wrote: > > > I have question concerning the case, when SIP proxies modify SDP, > > which is AFAIK against SIP principles, isn't it? > > > > In the concrete case, proxies would be able to remove certain codecs > > from the INVITE messages, depending on the current policy in the > > network. (The UAS gets a subset of the codecs, which were originally > > sent by the UAC.) > > > > What impact does such a proxy behavior have to SIP? I can think of > > problems with authentication and message integrity checking (UAC signs > > message with its private key). > > > > Are there any other problems? Any comments are appreciated. > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 13:01:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19977 for ; Tue, 19 Dec 2000 13:01:37 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8189644355; Tue, 19 Dec 2000 12:00:16 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id 7EA6844337 for ; Tue, 19 Dec 2000 11:59:19 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 19 Dec 2000 11:58:56 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Keith Robinson , SIP List Subject: Re: [SIP] Proxy Routing Logic Message-ID: <20001219115856.A7876@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdrosen@dynamicsoft.com on Tue, Dec 19, 2000 at 01:45:52AM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 11:58:56 -0600 Jonathan Rosenberg (jdrosen@dynamicsoft.com): > Specifically, lets say I want to have a URL in a web page that causes > people to call me through some local proxy. That URL in the web page > would look like: > > sip:jdrosen@dynamicsoft.com;maddr=local.proxy.com This hits my question exactly. I like the idea of local.proxy.com proxying the request to jdrosen@dynamicsoft.com without preconfiguring it or performing a visitor registration at it. Agreed? If so, let's revisit the idea of copying the Request-URI into the Route and adding an maddr. Consider an outbound proxy which adds a record-route. An initial request arrives for jdrosen@dynamicsoft.com. The proxy uses an RR URI: sip:jdrosen@dynamicsoft.com;maddr=outbound.proxy.com So, when it sees new requests with this as the request-URI, we have different behavior dependant on if there is a Route. This makes me worried. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 13:40:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21112 for ; Tue, 19 Dec 2000 13:40:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 927BC44344; Tue, 19 Dec 2000 12:40:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from renown.cnchost.com (renown.concentric.net [207.155.248.7]) by lists.bell-labs.com (Postfix) with ESMTP id E93DA44342 for ; Tue, 19 Dec 2000 12:39:08 -0500 (EST) Received: from gamze (hybrid-024-221-180-089.ca.sprintbbd.net [24.221.180.89]) by renown.cnchost.com id NAA29696; Tue, 19 Dec 2000 13:38:42 -0500 (EST) [ConcentricHost SMTP Relay 1.10] Message-ID: <009a01c069e2$c6234720$b200a8c0@luxxon.com> From: "Gamze Seckin" To: References: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED8899@il27exm02.cig.mot.com> 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Subject: [SIP] open source for impp Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 10:40:26 -0700 Content-Transfer-Encoding: 7bit Hi all, I have couple of questions: - Is there an open source implementation for IMPP? (If not, what would be a good start to deploy my own implementation?) - What is the most accepted underlying protocol for IMPP? (I know there is discussion around SIP, IMPX, but what is actually used mostly?) thanks, gamze ================= Gamze Seckin, Ph.D. Research Engineer, Luxxon Corporation (650) 938 1919x2105 www.luxxon.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 13:58:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21492 for ; Tue, 19 Dec 2000 13:58:25 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E7DB044352; Tue, 19 Dec 2000 12:57:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3D5A044346 for ; Tue, 19 Dec 2000 12:56:36 -0500 (EST) Received: from SUPERBEE ([63.110.3.128]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id NAA16744 for ; Tue, 19 Dec 2000 13:59:02 -0500 (EST) From: "Ben Campbell" To: "SIP List" Subject: RE: [SIP] Record-Route and REGISTER Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3B545@DYN-TX-EXCH-001.dynamicsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 12:53:57 -0600 Content-Transfer-Encoding: 7bit > > Correct. REGISTER is nearly a separate protocol, for all intents and > purposes. As specified right now, record-routing for REGISTER > is ambigous. > In any case, record-routing for transactions outside of > INVITE is not clear. > What is the the scope of the Route? To which set of messages > does it apply? > When can the route be purged? These issues must be resolved > as well, and > they are much harder. > > The solution to your specific problem is for the UAC and UAC > to use RR in > REGISTER instead. So: > > 1. A UAC inserts a REcord-route into the REGISTER pointing to > itself, just > like the Contact would look in an INVITE > 2. proxies can record-route > 3. UAS (the registrar, in this case) also adds a RR, and > reflects that back > in 200 OK > 4. Route is constructed normally except COntact is ignored > > > Kind of a pain to have a special procedure for REGISTER, I know. In > hindsight, I would have used something instead of Contact > here, but at the > time rfc2543 was being written, the usages were similar > enough and the idea > of record-routing REGISTER was not something we considered. > I am unclear on what RR even means in the context of a register. If the UAC receives a RR in the response to a register, what is it supposed to do with it? There is no implied session for the route to be scoped to. Ben. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 14:05:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA21728 for ; Tue, 19 Dec 2000 14:05:12 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 171894437B; Tue, 19 Dec 2000 13:01:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A6B6344336 for ; Tue, 19 Dec 2000 13:00:37 -0500 (EST) Received: from CINQUECENTO ([63.110.3.212]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id OAA16812; Tue, 19 Dec 2000 14:03:01 -0500 (EST) From: "Robert Sparks" To: "Jonathan Rosenberg" Cc: Subject: RE: [SIP] Solving the REFER retransmit issue 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.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Importance: Normal In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 12:57:59 -0600 Content-Transfer-Encoding: 7bit > So, back to basics. The reason we built in this simple two way handshake > into non-INVITE methods was the assumption that they would be responded to > immediately, since an automata would answer, not a human. Lets keep with > that. REFER should generate an immediate response. I like Rohan's idea of > the NOTIFY (or something else) being sent later on when the request is > answered. This is easier than needing to support an actual presence server > in the UA, which would need to wait for SUBSCRIBE requests. > > -Jonathan R. I disagree with adding an implicit subscription with REFER. Assuming we pull the events work together quickly (which I have no reason to believe we won't), we have a solid primative in SUBSCRIBE that meets the need. If we pursued the implicit subscribe, I anticipate needing to add parameters, starting with one to let the UA sending the REFER know whether or not it should expect notifications. Further, what would be different between this and REFERPROGRESS/REFERDONE (that would be the "(or something else)" that would get sent later, yes)? I'm leaning strongly towards REFER with a subsequent SUBSCRIBE if you are interested in the results. Something like Require: referstatus could be included in the REFER if the application knows it can't work without status information. UAs that don't want to deal with receiving SUBSCRIBEs can decline REFERs with that header. If the submitting UA wants to proceed without status, it can resubmit the request without the Require:. A UA receiving a REFER without that header can still offer progress information by providing something to subscribe to in the response (A Subscribe-To: header in the response or the like). The originating UA can then choose whether or not SUBSCRIBE. RjS _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 14:12:21 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22003 for ; Tue, 19 Dec 2000 14:12:20 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 86A5A44388; Tue, 19 Dec 2000 13:10:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 66E1144388 for ; Tue, 19 Dec 2000 13:09:34 -0500 (EST) Received: from athletics ([63.110.3.140]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id OAA16925; Tue, 19 Dec 2000 14:11:52 -0500 (EST) From: "Steve Donovan" To: "Jonathan Rosenberg" , "'David Shrader'" , "SIP List" Subject: RE: [SIP] Record-Route and REGISTER 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.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 13:07:28 -0600 Content-Transfer-Encoding: 7bit Why are we worried about record-routing REGISTER messages. Record-Routing is used to ensure that all messages within a session go through interested proxies. This is obviously useful with INVITE and SUBSCRIBE. There is no session created by REGISTER. As such, there are no other messages that need to take the same route. Is the goal to ensure that subsequent REGISTER requests make it to the same instance of a registrar within a domain? If so, is the use of Record-Route the correct solution? Steve > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > Sent: Tuesday, December 19, 2000 12:25 AM > To: 'David Shrader'; SIP List > Subject: RE: [SIP] Record-Route and REGISTER > > > > > > > > -----Original Message----- > > From: David Shrader [mailto:dshrader@master-consultant.com] > > Sent: Sunday, December 17, 2000 3:40 PM > > To: SIP List > > Subject: [SIP] Record-Route and REGISTER > > > > When using the REGISTER method, however, the Contact header > > is NOT used for > > that purpose. The Contact header in the Response to a > > REGISTER is simply a > > list of registered contacts and does not in fact identify the > > recipient of a > > subsequent request. > > Correct. REGISTER is nearly a separate protocol, for all intents and > purposes. As specified right now, record-routing for REGISTER is ambigous. > In any case, record-routing for transactions outside of INVITE is > not clear. > What is the the scope of the Route? To which set of messages does > it apply? > When can the route be purged? These issues must be resolved as well, and > they are much harder. > > The solution to your specific problem is for the UAC and UAC to use RR in > REGISTER instead. So: > > 1. A UAC inserts a REcord-route into the REGISTER pointing to itself, just > like the Contact would look in an INVITE > 2. proxies can record-route > 3. UAS (the registrar, in this case) also adds a RR, and reflects > that back > in 200 OK > 4. Route is constructed normally except COntact is ignored > > > Kind of a pain to have a special procedure for REGISTER, I know. In > hindsight, I would have used something instead of Contact here, but at the > time rfc2543 was being written, the usages were similar enough > and the idea > of record-routing REGISTER was not something we considered. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 14:28:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22480 for ; Tue, 19 Dec 2000 14:28:57 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F36F544346; Tue, 19 Dec 2000 13:25:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 38DD344379 for ; Tue, 19 Dec 2000 13:24:06 -0500 (EST) Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eBJJNqK24415; Tue, 19 Dec 2000 13:23:52 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id eBJJKuV06898; Tue, 19 Dec 2000 13:20:56 -0600 (CST) Received: from ericsson.com (pc050188.exu.ericsson.se [138.85.50.188]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id NAA12974; Tue, 19 Dec 2000 13:23:51 -0600 (CST) Message-ID: <3A3FB453.3DBC358C@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Steve Donovan Cc: Jonathan Rosenberg , "'David Shrader'" , SIP List Subject: Re: [SIP] Record-Route and REGISTER References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 13:17:39 -0600 Content-Transfer-Encoding: 7bit What about subsequent re-registrations? It is conceivable that a stateful proxy might want to know about these re-registrations (perhaps for caching purposes). Of course, this doesn't help with the case where multiple UAs are registering for the same user. Sean Steve Donovan wrote: > > Why are we worried about record-routing REGISTER messages. Record-Routing > is used to ensure that all messages within a session go through interested > proxies. This is obviously useful with INVITE and SUBSCRIBE. > > There is no session created by REGISTER. As such, there are no other > messages that need to take the same route. > > Is the goal to ensure that subsequent REGISTER requests make it to the same > instance of a registrar within a domain? If so, is the use of Record-Route > the correct solution? > > Steve > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > > Sent: Tuesday, December 19, 2000 12:25 AM > > To: 'David Shrader'; SIP List > > Subject: RE: [SIP] Record-Route and REGISTER > > > > > > > > > > > > > > > -----Original Message----- > > > From: David Shrader [mailto:dshrader@master-consultant.com] > > > Sent: Sunday, December 17, 2000 3:40 PM > > > To: SIP List > > > Subject: [SIP] Record-Route and REGISTER > > > > > > When using the REGISTER method, however, the Contact header > > > is NOT used for > > > that purpose. The Contact header in the Response to a > > > REGISTER is simply a > > > list of registered contacts and does not in fact identify the > > > recipient of a > > > subsequent request. > > > > Correct. REGISTER is nearly a separate protocol, for all intents and > > purposes. As specified right now, record-routing for REGISTER is ambigous. > > In any case, record-routing for transactions outside of INVITE is > > not clear. > > What is the the scope of the Route? To which set of messages does > > it apply? > > When can the route be purged? These issues must be resolved as well, and > > they are much harder. > > > > The solution to your specific problem is for the UAC and UAC to use RR in > > REGISTER instead. So: > > > > 1. A UAC inserts a REcord-route into the REGISTER pointing to itself, just > > like the Contact would look in an INVITE > > 2. proxies can record-route > > 3. UAS (the registrar, in this case) also adds a RR, and reflects > > that back > > in 200 OK > > 4. Route is constructed normally except COntact is ignored > > > > > > Kind of a pain to have a special procedure for REGISTER, I know. In > > hindsight, I would have used something instead of Contact here, but at the > > time rfc2543 was being written, the usages were similar enough > > and the idea > > of record-routing REGISTER was not something we considered. > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 16:33:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA25521 for ; Tue, 19 Dec 2000 16:33:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ACC1644337; Tue, 19 Dec 2000 15:33:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id A34A744336 for ; Tue, 19 Dec 2000 15:32:34 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Tue, 19 Dec 2000 15:32:39 -0600 (CST) From: Billy Biggs To: Robert Sparks Cc: Jonathan Rosenberg , SIP List Message-ID: <20001219153239.A7929@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i Subject: [SIP] Simple REFER Solution Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 15:32:39 -0600 Keep REFER simple: Have no REFER-response method and no subscription. We have found the following algorithm to be smallest, simplest, easiest to understand, and least verbose. 1. The REFER is responded to immediately. 2. If the Referred Party wishes to resume the call later (usually if the REFER-spawned call failed), then they send an INVITE with a 'Refer-Response' header containing the response code from the spawned INVITE. 3. If the Referred Party wishes to end the old call (the REFER-spawned call succeeded), then they BYE the referrer. 4. To keep the number of messages down, REFER and its response may contain SDP (such as hold SDP). Rationalle: Avoids queues in either device. A "first send NOTIFY then send BYE to shut down the call" proposal has difficult error cases. Want to keep recovery of the old session from a failed transfer as speedy as possible. Comments appreciated. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 18:20:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27353 for ; Tue, 19 Dec 2000 18:20:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A99744337; Tue, 19 Dec 2000 17:20:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 81F4E44336 for ; Tue, 19 Dec 2000 17:19:26 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA19453; Tue, 19 Dec 2000 18:21:44 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 18:16:41 -0500 Message-ID: From: Jonathan Rosenberg To: "'Sean Olson'" , Steve Donovan Cc: Jonathan Rosenberg , "'David Shrader'" , SIP List Subject: RE: [SIP] Record-Route and REGISTER MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 18:16:31 -0500 This issue is what I meant when I said: >What is the the scope of the Route? To which set of messages does >it apply? When can the route be purged? The obvious generalization of the current Route mechanism is that a UA uses the Routes for all requests with the same To/From/Call-ID. This would then effect refreshes of REGISTER, and is also how we handle record-routing of SUBSCRIBE/NOTIFY and MESSAGE as well. What would you use RR on REGISTER for? Not sure... any ideas? -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Sean Olson [mailto:sean.olson@ericsson.com] > Sent: Tuesday, December 19, 2000 2:18 PM > To: Steve Donovan > Cc: Jonathan Rosenberg; 'David Shrader'; SIP List > Subject: Re: [SIP] Record-Route and REGISTER > > > What about subsequent re-registrations? It is conceivable that > a stateful proxy might want to know about these re-registrations > (perhaps for caching purposes). Of course, this doesn't help > with the case where multiple UAs are registering for the same > user. > > Sean > > Steve Donovan wrote: > > > > Why are we worried about record-routing REGISTER messages. > Record-Routing > > is used to ensure that all messages within a session go > through interested > > proxies. This is obviously useful with INVITE and SUBSCRIBE. > > > > There is no session created by REGISTER. As such, there > are no other > > messages that need to take the same route. > > > > Is the goal to ensure that subsequent REGISTER requests > make it to the same > > instance of a registrar within a domain? If so, is the use > of Record-Route > > the correct solution? > > > > Steve > > > > > -----Original Message----- > > > From: sip-admin@lists.bell-labs.com > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > Jonathan Rosenberg > > > Sent: Tuesday, December 19, 2000 12:25 AM > > > To: 'David Shrader'; SIP List > > > Subject: RE: [SIP] Record-Route and REGISTER > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: David Shrader [mailto:dshrader@master-consultant.com] > > > > Sent: Sunday, December 17, 2000 3:40 PM > > > > To: SIP List > > > > Subject: [SIP] Record-Route and REGISTER > > > > > > > > When using the REGISTER method, however, the Contact header > > > > is NOT used for > > > > that purpose. The Contact header in the Response to a > > > > REGISTER is simply a > > > > list of registered contacts and does not in fact identify the > > > > recipient of a > > > > subsequent request. > > > > > > Correct. REGISTER is nearly a separate protocol, for all > intents and > > > purposes. As specified right now, record-routing for > REGISTER is ambigous. > > > In any case, record-routing for transactions outside of INVITE is > > > not clear. > > > What is the the scope of the Route? To which set of messages does > > > it apply? > > > When can the route be purged? These issues must be > resolved as well, and > > > they are much harder. > > > > > > The solution to your specific problem is for the UAC and > UAC to use RR in > > > REGISTER instead. So: > > > > > > 1. A UAC inserts a REcord-route into the REGISTER > pointing to itself, just > > > like the Contact would look in an INVITE > > > 2. proxies can record-route > > > 3. UAS (the registrar, in this case) also adds a RR, and reflects > > > that back > > > in 200 OK > > > 4. Route is constructed normally except COntact is ignored > > > > > > > > > Kind of a pain to have a special procedure for REGISTER, > I know. In > > > hindsight, I would have used something instead of Contact > here, but at the > > > time rfc2543 was being written, the usages were similar enough > > > and the idea > > > of record-routing REGISTER was not something we considered. > > > > > > -Jonathan R. > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 18:23:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA27393 for ; Tue, 19 Dec 2000 18:23:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2AF9E44340; Tue, 19 Dec 2000 17:23:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D7ED944337 for ; Tue, 19 Dec 2000 17:22:03 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id SAA19473; Tue, 19 Dec 2000 18:24:24 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 18:19:21 -0500 Message-ID: From: Jonathan Rosenberg To: "'Hisham Khartabil'" , sip@lists.bell-labs.com Subject: RE: [SIP] RE: Changin local RTP port without a good reason MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 18:19:14 -0500 > -----Original Message----- > From: Hisham Khartabil [mailto:hisham.khartabil@hotsip.com] > Sent: Tuesday, December 19, 2000 3:44 AM > To: sip@lists.bell-labs.com > Subject: RE: [SIP] RE: Changin local RTP port without a good reason > > > What was the conclusion about the issue of SDP in ACK. If > the decision was > to disallow it, then the flow below is breaking that rule already. > > Regards, > Hisham > The open issues design team concluded that SDP exchanges should be generically offered as a two-pass offer/response, where the initial SDP can be offered in SDP or 200 OK, and the response can be in the 200 OK or ACK, respectively. So, you can have two exchanges: SDP in INVITE, SDP in 200, no SDP in ACK, OR, no SDP in INVITE, SDP in 200, SDP in ACK. In either case, the same rules are applied to how to structure the SDP in the offer and response. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 19 19:10:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA28322 for ; Tue, 19 Dec 2000 19:10:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E5BAB44337; Tue, 19 Dec 2000 18:10:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailsrv02.multitude.com (mailsrv02.firetalk.com [204.178.116.251]) by lists.bell-labs.com (Postfix) with ESMTP id 2CC0544336 for ; Tue, 19 Dec 2000 18:09:22 -0500 (EST) Received: from sbarber2k (s242.firetalk.com [204.178.116.242]) by mailsrv02.multitude.com (Rockliffe SMTPRA 3.4.2) with SMTP id ; Tue, 19 Dec 2000 16:06:23 -0800 Message-ID: <01f801c06a19$99d98530$3a0514ac@sbarber2k> From: "Simon Barber" To: "Jonathan Rosenberg" , "'Sean Olson'" , "Steve Donovan" Cc: "'David Shrader'" , "SIP List" References: Subject: Re: [SIP] Record-Route and REGISTER 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 16:12:55 -0800 Content-Transfer-Encoding: 7bit From: "Jonathan Rosenberg" To: "'Sean Olson'" ; "Steve Donovan" Cc: "Jonathan Rosenberg" ; "'David Shrader'" ; "SIP List" Sent: Tuesday, December 19, 2000 3:16 PM Subject: RE: [SIP] Record-Route and REGISTER > This issue is what I meant when I said: > > >What is the the scope of the Route? To which set of messages does > >it apply? When can the route be purged? > > The obvious generalization of the current Route mechanism is that a UA uses > the Routes for all requests with the same To/From/Call-ID. This would then > effect refreshes of REGISTER, and is also how we handle record-routing of > SUBSCRIBE/NOTIFY and MESSAGE as well. > > What would you use RR on REGISTER for? Not sure... any ideas? A firewall proxy for a large private network might want to keep state for the registration of a UA - and also load-balance. This brings up the further question of keeping the same proxy in the loop for future INVITE and other methods, as well as future REGISTERs. > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Sean Olson [mailto:sean.olson@ericsson.com] > > Sent: Tuesday, December 19, 2000 2:18 PM > > To: Steve Donovan > > Cc: Jonathan Rosenberg; 'David Shrader'; SIP List > > Subject: Re: [SIP] Record-Route and REGISTER > > > > > > What about subsequent re-registrations? It is conceivable that > > a stateful proxy might want to know about these re-registrations > > (perhaps for caching purposes). Of course, this doesn't help > > with the case where multiple UAs are registering for the same > > user. > > > > Sean > > > > Steve Donovan wrote: > > > > > > Why are we worried about record-routing REGISTER messages. > > Record-Routing > > > is used to ensure that all messages within a session go > > through interested > > > proxies. This is obviously useful with INVITE and SUBSCRIBE. > > > > > > There is no session created by REGISTER. As such, there > > are no other > > > messages that need to take the same route. > > > > > > Is the goal to ensure that subsequent REGISTER requests > > make it to the same > > > instance of a registrar within a domain? If so, is the use > > of Record-Route > > > the correct solution? > > > > > > Steve > > > > > > > -----Original Message----- > > > > From: sip-admin@lists.bell-labs.com > > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > > Jonathan Rosenberg > > > > Sent: Tuesday, December 19, 2000 12:25 AM > > > > To: 'David Shrader'; SIP List > > > > Subject: RE: [SIP] Record-Route and REGISTER > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: David Shrader [mailto:dshrader@master-consultant.com] > > > > > Sent: Sunday, December 17, 2000 3:40 PM > > > > > To: SIP List > > > > > Subject: [SIP] Record-Route and REGISTER > > > > > > > > > > When using the REGISTER method, however, the Contact header > > > > > is NOT used for > > > > > that purpose. The Contact header in the Response to a > > > > > REGISTER is simply a > > > > > list of registered contacts and does not in fact identify the > > > > > recipient of a > > > > > subsequent request. > > > > > > > > Correct. REGISTER is nearly a separate protocol, for all > > intents and > > > > purposes. As specified right now, record-routing for > > REGISTER is ambigous. > > > > In any case, record-routing for transactions outside of INVITE is > > > > not clear. > > > > What is the the scope of the Route? To which set of messages does > > > > it apply? > > > > When can the route be purged? These issues must be > > resolved as well, and > > > > they are much harder. > > > > > > > > The solution to your specific problem is for the UAC and > > UAC to use RR in > > > > REGISTER instead. So: > > > > > > > > 1. A UAC inserts a REcord-route into the REGISTER > > pointing to itself, just > > > > like the Contact would look in an INVITE > > > > 2. proxies can record-route > > > > 3. UAS (the registrar, in this case) also adds a RR, and reflects > > > > that back > > > > in 200 OK > > > > 4. Route is constructed normally except COntact is ignored > > > > > > > > > > > > Kind of a pain to have a special procedure for REGISTER, > > I know. In > > > > hindsight, I would have used something instead of Contact > > here, but at the > > > > time rfc2543 was being written, the usages were similar enough > > > > and the idea > > > > of record-routing REGISTER was not something we considered. > > > > > > > > -Jonathan R. > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 01:01:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA05409 for ; Wed, 20 Dec 2000 01:01:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 051BB44337; Wed, 20 Dec 2000 00:01:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id E7A0D44336 for ; Wed, 20 Dec 2000 00:00:16 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Tue, 19 Dec 2000 21:59:51 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Robert Sparks'" , sip@lists.bell-labs.com Subject: RE: [SIP] 3pcc callflow question (Was:Changin local RTP port with out a good reason) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 19 Dec 2000 21:59:42 -0800 > > Doesn't matter. Notice that in the original diagram, A1 > isn't used in the negotiation with B. If A automatically > returns held sdp when it recieves held sdp, things don't > break. > > Out of curiosity, does anyone have a UA deployed that won't > accept an initial INVITE to held media? If so, it argues for > using the delayed media approach you suggest. > Hi Robert, I imagine that some UA's may not be happy with an initial SDP (held) with no vocoders, eg v=0 o=... c=IN IP4 0.0.0.0 m=audio 10000 RTP/AVP [Otherwise the controller would have to know/guess the lowest capabilities of UA A - which is unacceptable.] Placing no SDP in the INVITE also has the advantage that the controller can immediately take action if it detects that the 200 Ok from UA B (containing SDP B) is incompatiable with SDP A1 (rather than the UA A re-INVITE failing ... which adds more chance of strange things happening due to incorrect UA re-INVITE error handling). Regards, Robert. > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > Fairlie-Cuninghame, > > Robert > > Sent: Tuesday, December 19, 2000 12:51 AM > > To: sip@lists.bell-labs.com > > Subject: RE: [SIP] 3pcc callflow question (Was:Changin > local RTP port > > without a good reason) > > > > > > > An alternative flow has already been proposed which does not > > > suffer from the > > > timeout problem, and which does not have this race condition: > > > > > > > > > > A Controller B > > > > > | INV SDP held | | time t = 0 > > > > > |<------------------| | > > > > > | | | > > > > > | 200 SDP A1 | | > > > > > |-----------------> | | > > > > > | | | > > > > > | ACK | | > > > > > |<------------------| | > > > > > | | | > > > > Sorry to go back a bit but can I forget the reason why it was > > decided not to > > start with: > > > > A Controller > > > > INV no SDP > > <-------- > > > > 200 SDP A1 > > --------> > > > > ACK SDP held > > <-------- > > > > This seems simpler as both A and B are behaving in the same > manner (rather > > than A having to realize that it must produce SDP A1 when > it receives an > > initial SDP held). > > > > Was it because of crash-restart problems ? > > > > Regards, > > > > Robert. > > > > > > > > > | | INV no SDP | > > > > > | |----------------->| (1) > > > > > | | | > > > > > | | 200 SDP B | > > > > > | |<-----------------| > > > > > | INV SDP B | | > > > > > |<------------------| | > > > > > | | | > > > > > | 200 SDP A2 | | > > > > > |-----------------> | | > > > > > | | | > > > > > | | ACK SDP A2 | > > > > > | ACK |----------------->| > > > > > |<------------------| | > > > > > | | | > > > > > | | RTP | > > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > > | | | > > > > > > > > > I'd like to start with this one as the basis for continuing > > > discussion/concerns. > > > > > > -Jonathan R. > > > > > > > > > --- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 02:04:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA17412 for ; Wed, 20 Dec 2000 02:04:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2FEAE44337; Wed, 20 Dec 2000 01:04:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by lists.bell-labs.com (Postfix) with ESMTP id E488444336 for ; Wed, 20 Dec 2000 01:03:22 -0500 (EST) Received: from m2hub.wipro.com (m2hub.wipro.com [164.164.27.50]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with ESMTP id MAA24340 for ; Wed, 20 Dec 2000 12:40:07 GMT Received: from m2vwall2.wipro.com ([164.164.27.52]) by m2hub.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA1E55 for ; Wed, 20 Dec 2000 12:29:34 +0530 Received: from wipro.com ([164.164.28.228]) by ace.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA14B7 for ; Wed, 20 Dec 2000 12:28:16 +0530 Message-ID: <3A405CF2.11AACE43@wipro.com> From: "Anuraj Ennai" Organization: Wipro X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com Subject: Re: [SIP] Proxies modifying SDP References: <20001219160200.C671444376@lists.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 12:47:06 +0530 Content-Transfer-Encoding: 7bit Hi all, I believe proxies should be discouraged from prying into SDP contents(or any message body that does not concern them) for scalability, security and privacy reasons. The mechanism for capability negotiation etc. should be implemented at UA, using methods like OPTIONs and/or headers like supported/ Unsupported or Re-INVITEs. It mandates passing 1 or 2 messages more between the UAs, but in the end scales up well. If the proxy needs SDP content negotiation, it can spawn its own call agent which works exactly like the UA. In the end, it is all about KISS!!! Thanks & regards Anuraj Ennai Wipro Technologies -India. Subject: Re: [SIP] Proxies modifying SDP Date: Tue, 19 Dec 2000 10:56:04 -0600 From: David Frascone To: Steve Gardell CC: "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com References: 1 This might be a useless response, since I can't find the example document that I'm about to refer too . . but . . . In the documents I read before San Diego, I remember two pictures of a proxied senario. In the first, the SIP requests were proxied, but the RTP was sent normally. In the second, the SIP requests were proxied, *and* the RTP was proxied. In this senario, didn't the SIP proxy have to modify the SDP to get it to work? Please: I know someone else read this document, or saw the slides I'm refering too . . . . Someone help refresh my poor tired memory :) -Dave On Tue, Dec 19, 2000 at 11:43:25AM -0500, Steve Gardell wrote: > If memory serves, a "fully routed" H.323 gatekeepers routes the media > negotiation signalling, but does not route the actual RTP traffic. > > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Monday, December 18, 2000 8:05 PM > To: 'Steve Donovan'; Baniel Uri-CUB001; 'Neil Deason'; > jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > Hmm... > Probably I was not clear and hence the confusion. > My intention was to be able to mimic the 'H323 gate keeper mode' > functionality, i.e. to have the end points think they talk to each other (in > the media streaming phase) but actually the media goes via a gate keeper. In > our SIP world this should be just a MG (Media Gateway). > The control may still go via a SIP proxy server, that is why I think > changing SDP fields (specifically the IP address for receiving media as well > as the RTP ports) may easily achieve this goal > > Uri > > -----Original Message----- > From: Steve Donovan [mailto:sdonovan@dynamicsoft.com] > Sent: Sunday, December 17, 2000 9:12 PM > To: Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; > bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 03:30:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18830 for ; Wed, 20 Dec 2000 03:30:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 65EA244337; Wed, 20 Dec 2000 02:30:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 9361644336 for ; Wed, 20 Dec 2000 02:29:58 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 00:29:32 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Billy Biggs'" , Jonathan Rosenberg Cc: Keith Robinson , SIP List Subject: RE: [SIP] Proxy Routing Logic MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 00:29:28 -0800 > > If so, let's revisit the idea of copying the Request-URI into the > Route and adding an maddr. > > Consider an outbound proxy which adds a record-route. An initial > request arrives for jdrosen@dynamicsoft.com. The proxy uses > an RR URI: > > sip:jdrosen@dynamicsoft.com;maddr=outbound.proxy.com > > So, when it sees new requests with this as the request-URI, we have > different behavior dependant on if there is a Route. This makes me > worried. > Hi Billy, I beleive under the new Record-Route suggestions the proxy would be recommended to add RR of so that request is always routed to the outbound proxy (to remove ambiguity). [Of course there will be always be different routing behaviour depending on whether the request has a Route or not. If a Route exists it would be followed. If the Route doesn't exist you want to recreate the original routing action (for subsequent requests). This needs to be accomplished by either storing route state local or embedding the imformation in the Record-Route.] I don't see your maddr concerns as a problem - in fact it is darn useful. If a Contact or Record-Route has an maddr it should be acted upon by a UAC - even if the UAC has an outbound proxy configured (I believe). If the outbound proxy wants to have ALL sip requests sent to it (not just the first INVITE) then it should record-route itself!! If a UAC with an outbound proxy configured _wasn't_ to act on the maddr, then a redirect server would be rendered useless (if it was configured as the outbound proxy). Eg: UAC send INVITE sip:555-1220@company.com;user=phone SIP/2.0 to outbound proxy (which is redirect server). Server returns 302 with Contact: If the UAC ignores the maddr then it would simply send the INVITE to the same outbound proxy again. Cheers, Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 04:18:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA19174 for ; Wed, 20 Dec 2000 04:18:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 095FE44337; Wed, 20 Dec 2000 03:18:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by lists.bell-labs.com (Postfix) with ESMTP id D45C444336 for ; Wed, 20 Dec 2000 03:17:39 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 20 Dec 2000 09:18:43 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id JAA12878; Wed, 20 Dec 2000 09:17:28 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569BB.00330A33 ; Wed, 20 Dec 2000 09:17:29 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Keith Robinson" To: Jonathan Rosenberg Cc: "'Neil Deason'" , Billy Biggs , Jean-Francois Mule , sip@lists.bell-labs.com Message-ID: <802569BB.003308A3.00@marconicomms.com> Subject: RE: [SIP] Bug in 2543bis-02 re: Record-Route Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 09:17:07 +0000 Requiring a proxy to add itself to each request for robustness in case the UA crashes is fine but it has to be MUST to be sure it stays in the path as it cant know when the UA is about to crash-reboot. Regards, K. Robinson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 09:12:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25071 for ; Wed, 20 Dec 2000 09:12:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C265C44337; Wed, 20 Dec 2000 08:12:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by lists.bell-labs.com (Postfix) with ESMTP id 8D62044336 for ; Wed, 20 Dec 2000 08:11:45 -0500 (EST) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id eBKEBUG17016; Wed, 20 Dec 2000 15:11:30 +0100 (MET) Received: from lmf.ericsson.se ([159.107.1.23]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id PAA03789; Wed, 20 Dec 2000 15:11:26 +0100 (MET) Message-ID: <3A40BE1B.68248A61@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Pekka Pessi'" , sip@lists.bell-labs.com Subject: Re: [SIP] RE: Changin local RTP port without a good reason References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 16:11:39 +0200 Content-Transfer-Encoding: 7bit Hi, Actually there is nothing new with this flow. This is the delayed ACK solution that was already proposed. Since the INV/200 OK will most likely take little time, it will work. However, when INV-200 OK takes longer we have the same problem. In most of the situations, using the delayed ACK, the flow you just described works. However, if the SDP is not ready and the ACK has to be sent to stop the retransmission timer, we will still have to make up an SDP... we might want to work on this scenario. Best regards, Gonzalo Jonathan Rosenberg wrote: > > > > > -----Original Message----- > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > Sent: Monday, December 18, 2000 3:30 AM > > To: sip@lists.bell-labs.com > > Cc: Gonzalo Camarillo > > Subject: Re: [SIP] RE: Changin local RTP port without a good reason > > > > > > In message <3A3989CA.8F5E7117@lmf.ericsson.se> "ext Gonzalo > > Camarillo" writes: > > >Of course that sometimes you have to change your local > > configuration if > > >the remote configuration changes... but there has to be a good reason > > >(like a change of codecs). > > > > When you issue a re-INVITE with a new local port number, you are > > proposing a new RTP session. The remote end can not > > distinguish > > between packets in the old session and new session, unless it > > changes its RTP port, too. > > Much as I would like to be able to enforce this "don't change ports without > good reason", I think there are cases where implementations will want to do > this on each re-invite. As such, I think the mechanism in the current 3pcc > draft won't work either. > > An alternative flow has already been proposed which does not suffer from the > timeout problem, and which does not have this race condition: > > > > A Controller B > > > | INV SDP held | | time t = 0 > > > |<------------------| | > > > | | | > > > | 200 SDP A1 | | > > > |-----------------> | | > > > | | | > > > | ACK | | > > > |<------------------| | > > > | | | > > > | | INV no SDP | > > > | |----------------->| (1) > > > | | | > > > | | 200 SDP B | > > > | |<-----------------| > > > | INV SDP B | | > > > |<------------------| | > > > | | | > > > | 200 SDP A2 | | > > > |-----------------> | | > > > | | | > > > | | ACK SDP A2 | > > > | ACK |----------------->| > > > |<------------------| | > > > | | | > > > | | RTP | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > | | | > > I'd like to start with this one as the basis for continuing > discussion/concerns. > > -Jonathan R. > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 09:37:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26021 for ; Wed, 20 Dec 2000 09:37:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BD0B744366; Wed, 20 Dec 2000 08:37:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id 6987D44337 for ; Wed, 20 Dec 2000 08:36:18 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA27275; Wed, 20 Dec 2000 09:36:06 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20611; Wed, 20 Dec 2000 09:36:07 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 09:36:06 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EBEA@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Johan Liseborn'" , SIP List MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] RE: SIP Security Mailing List Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 09:36:05 -0500 If you are interested in Security issues in SIP, please subscribe to the sip-security mailing list: Post message: sip-security@egroups.com Subscribe: sip-security-subscribe@egroups.com Unsubscribe: sip-security-unsubscribe@egroups.com List owner: sip-security-owner@egroups.com URL to web page: http://www.egroups.com/group/sip-security Brian _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 10:15:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28029 for ; Wed, 20 Dec 2000 10:15:46 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0ECA444337; Wed, 20 Dec 2000 09:15:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 831FB44337 for ; Wed, 20 Dec 2000 09:14:15 -0500 (EST) Received: from athletics (cf9e4162.dfw53.dsl.airmail.net [207.158.65.98]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id KAA22634; Wed, 20 Dec 2000 10:16:20 -0500 (EST) From: "Steve Donovan" To: "Simon Barber" , "Jonathan Rosenberg" , "'Sean Olson'" Cc: "'David Shrader'" , "SIP List" Subject: RE: [SIP] Record-Route and REGISTER 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.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <01f801c06a19$99d98530$3a0514ac@sbarber2k> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 09:11:58 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Simon Barber [mailto:simon@firetalk.com] > Sent: Tuesday, December 19, 2000 6:13 PM > To: Jonathan Rosenberg; 'Sean Olson'; Steve Donovan > Cc: 'David Shrader'; SIP List > Subject: Re: [SIP] Record-Route and REGISTER > > > From: "Jonathan Rosenberg" > To: "'Sean Olson'" ; "Steve Donovan" > > Cc: "Jonathan Rosenberg" ; "'David Shrader'" > ; "SIP List" > Sent: Tuesday, December 19, 2000 3:16 PM > Subject: RE: [SIP] Record-Route and REGISTER > > > > This issue is what I meant when I said: > > > > >What is the the scope of the Route? To which set of messages does > > >it apply? When can the route be purged? > > > > The obvious generalization of the current Route mechanism is that a UA > uses > > the Routes for all requests with the same To/From/Call-ID. This > would then > > effect refreshes of REGISTER, and is also how we handle > record-routing of > > SUBSCRIBE/NOTIFY and MESSAGE as well. > > > > What would you use RR on REGISTER for? Not sure... any ideas? > > > A firewall proxy for a large private network might want to keep state for > the registration of a UA - and also load-balance. This brings up > the further > question of keeping the same proxy in the loop for future INVITE and other > methods, as well as future REGISTERs. But the can't the firewall proxy use the state that is already in the registrar to which the REGISTER is being sent? I can see that use of record-route would make a more efficient method for routing REGISTERs to the same registrar (after the first is sent). However, there are other methods (for instance, routing based on the to field). As such, is it worth it to create a special way of handling record-routes just for REGISTER messages? This seems to me to break the KISS principle. more below... > > > -----Original Message----- > > > From: Sean Olson [mailto:sean.olson@ericsson.com] > > > Sent: Tuesday, December 19, 2000 2:18 PM > > > To: Steve Donovan > > > Cc: Jonathan Rosenberg; 'David Shrader'; SIP List > > > Subject: Re: [SIP] Record-Route and REGISTER > > > > > > > > > What about subsequent re-registrations? It is conceivable that > > > a stateful proxy might want to know about these re-registrations > > > (perhaps for caching purposes). Of course, this doesn't help > > > with the case where multiple UAs are registering for the same > > > user. Again, shouldn't that stateful proxy use the registrar/location server for it's domain? That's the only way to fix the multiple UA registering problem. > > > > > > Sean > > > > > > Steve Donovan wrote: > > > > > > > > Why are we worried about record-routing REGISTER messages. > > > Record-Routing > > > > is used to ensure that all messages within a session go > > > through interested > > > > proxies. This is obviously useful with INVITE and SUBSCRIBE. > > > > > > > > There is no session created by REGISTER. As such, there > > > are no other > > > > messages that need to take the same route. > > > > > > > > Is the goal to ensure that subsequent REGISTER requests > > > make it to the same > > > > instance of a registrar within a domain? If so, is the use > > > of Record-Route > > > > the correct solution? > > > > > > > > Steve > > > > > > > > > -----Original Message----- > > > > > From: sip-admin@lists.bell-labs.com > > > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > > > Jonathan Rosenberg > > > > > Sent: Tuesday, December 19, 2000 12:25 AM > > > > > To: 'David Shrader'; SIP List > > > > > Subject: RE: [SIP] Record-Route and REGISTER > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: David Shrader [mailto:dshrader@master-consultant.com] > > > > > > Sent: Sunday, December 17, 2000 3:40 PM > > > > > > To: SIP List > > > > > > Subject: [SIP] Record-Route and REGISTER > > > > > > > > > > > > When using the REGISTER method, however, the Contact header > > > > > > is NOT used for > > > > > > that purpose. The Contact header in the Response to a > > > > > > REGISTER is simply a > > > > > > list of registered contacts and does not in fact identify the > > > > > > recipient of a > > > > > > subsequent request. > > > > > > > > > > Correct. REGISTER is nearly a separate protocol, for all > > > intents and > > > > > purposes. As specified right now, record-routing for > > > REGISTER is ambigous. > > > > > In any case, record-routing for transactions outside of INVITE is > > > > > not clear. > > > > > What is the the scope of the Route? To which set of messages does > > > > > it apply? > > > > > When can the route be purged? These issues must be > > > resolved as well, and > > > > > they are much harder. > > > > > > > > > > The solution to your specific problem is for the UAC and > > > UAC to use RR in > > > > > REGISTER instead. So: > > > > > > > > > > 1. A UAC inserts a REcord-route into the REGISTER > > > pointing to itself, just > > > > > like the Contact would look in an INVITE > > > > > 2. proxies can record-route > > > > > 3. UAS (the registrar, in this case) also adds a RR, and reflects > > > > > that back > > > > > in 200 OK > > > > > 4. Route is constructed normally except COntact is ignored > > > > > > > > > > > > > > > Kind of a pain to have a special procedure for REGISTER, > > > I know. In > > > > > hindsight, I would have used something instead of Contact > > > here, but at the > > > > > time rfc2543 was being written, the usages were similar enough > > > > > and the idea > > > > > of record-routing REGISTER was not something we considered. > > > > > > > > > > -Jonathan R. > > > > > --- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East Hanover, NJ 07936 > > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > > http://www.dynamicsoft.com > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 10:20:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA28236 for ; Wed, 20 Dec 2000 10:20:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8961F44337; Wed, 20 Dec 2000 09:20:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 60BC644336 for ; Wed, 20 Dec 2000 09:19:12 -0500 (EST) Received: from athletics (cf9e4162.dfw53.dsl.airmail.net [207.158.65.98]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id KAA22755; Wed, 20 Dec 2000 10:21:34 -0500 (EST) From: "Steve Donovan" To: "Jonathan Rosenberg" , "'Pekka Pessi'" , Cc: "Gonzalo Camarillo" Subject: RE: [SIP] RE: Changin local RTP port without a good reason 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.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 09:17:12 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > Sent: Tuesday, December 19, 2000 12:31 AM > To: 'Pekka Pessi'; sip@lists.bell-labs.com > Cc: Gonzalo Camarillo > Subject: RE: [SIP] RE: Changin local RTP port without a good reason > > > > > > > > -----Original Message----- > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > Sent: Monday, December 18, 2000 3:30 AM > > To: sip@lists.bell-labs.com > > Cc: Gonzalo Camarillo > > Subject: Re: [SIP] RE: Changin local RTP port without a good reason > > > > > > In message <3A3989CA.8F5E7117@lmf.ericsson.se> "ext Gonzalo > > Camarillo" writes: > > >Of course that sometimes you have to change your local > > configuration if > > >the remote configuration changes... but there has to be a good reason > > >(like a change of codecs). > > > > When you issue a re-INVITE with a new local port number, you are > > proposing a new RTP session. The remote end can not > > distinguish > > between packets in the old session and new session, unless it > > changes its RTP port, too. > > > Much as I would like to be able to enforce this "don't change > ports without > good reason", I think there are cases where implementations will > want to do > this on each re-invite. As such, I think the mechanism in the current 3pcc > draft won't work either. > > An alternative flow has already been proposed which does not > suffer from the > timeout problem, and which does not have this race condition: > > > > A Controller B > > > | INV SDP held | | time t = 0 > > > |<------------------| | > > > | | | > > > | 200 SDP A1 | | > > > |-----------------> | | > > > | | | > > > | ACK | | > > > |<------------------| | > > > | | | > > > | | INV no SDP | > > > | |----------------->| (1) > > > | | | > > > | | 200 SDP B | > > > | |<-----------------| > > > | INV SDP B | | > > > |<------------------| | > > > | | | > > > | 200 SDP A2 | | > > > |-----------------> | | > > > | | | > > > | | ACK SDP A2 | > > > | ACK |----------------->| > > > |<------------------| | > > > | | | > > > | | RTP | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > | | | > > > I'd like to start with this one as the basis for continuing > discussion/concerns. What is the end-user experience with this call? What does the user at A do when he gets a call that is on hold and hears silence? Isn't there a high probability that he will hang up while the controller is waiting for B to answer? In order for this to work, isn't it necessary for the controller to play some sort of media telling the user to hold on while the call is being setup? Either that or A needs to understand that it is a 3PCC call and know to either not notify the user or tell the user to wait. --- Steven R. Donovan Architect dynamicsoft mailto:sdonovan@dynamicsoft.com 5100 Tennyson Parkway sip:sdonovan@sip.dynamicsoft.com Plano, Texas 75025 tel:+1-972-473-5469 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 10:42:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29242 for ; Wed, 20 Dec 2000 10:42:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B59224433A; Wed, 20 Dec 2000 09:42:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id C44B344338 for ; Wed, 20 Dec 2000 09:41:45 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id B5D631E016 for ; Wed, 20 Dec 2000 10:41:32 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id KAA23469 for ; Wed, 20 Dec 2000 10:41:32 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id KAA18106 for sip@lists.bell-labs.com; Wed, 20 Dec 2000 10:42:30 -0500 (EST) Message-Id: <200012201542.KAA18106@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 10:42:30 -0500 (EST) My suggestion that REFER use the three-way handshake of INVITE is clearly DOA, but there were a couple of items in the responses that I would like to clarify. > > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > > Sent: Saturday, December 16, 2000 5:27 PM > > To: William Marshall > > Cc: sip@lists.bell-labs.com > > Subject: Re: [SIP] Solving the REFER retransmit issue > > > > > > While I have some sympathy for allowing the 3-way handshake for REFER, > > I'm very concerned about the proxy backward compatibility issue. An > > "old" proxy that thinks REFER is just another non-INVITE and a new UAS > > that retransmits 200s until it gets an ACK will get not be happy > > together. (A UAS that doesn't know REFER is likely to respond > > immediately with a 400 and will likely just dump the ACK, so that > > variation seems less of a concern.) Thus, we at least need a > > Proxy-Require > So what does a proxy do when it receives a 200-OK for a transaction it believes is complete? Consider the case where the UAC sends a request, times out and re-sends the request. Second message crosses the 200-OK in transit on the final link to UAS. So UAS re-transmits the 200-OK. All the proxies in the path now see this re-sent 200, and (I presume) should forward it along the Via chain back to the UAC. Should the proxy remember the number of retransmissions it saw for a request, and only pass that many responses. I hope not. So if a proxy should still forward the 200-OK based on the Vias, I see no backward compatibility issue. > > From: "James Undery" > > To: wtm@research.att.com, sip@lists.bell-labs.com > > Subject: Re: [SIP] Solving the REFER retransmit issue > > Date: Fri, 15 Dec 2000 01:14:43 -0000 > > > > You can and should send provisional responces to all requests that you can't > > process in a specific time (200ms IIRC). Is this true even for non-INVITEs? Doesn't a provisional response turn off the retransmission of the request? How is reliability of the 200-OK response guaranteed> It was my understanding that a proxy only sends a 100-Trying to an INVITE, not to other requests. All other requests do only end-end reliability, not hop-hop. Bill Marshall wtm@research.att.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 11:19:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01229 for ; Wed, 20 Dec 2000 11:19:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0997E44337; Wed, 20 Dec 2000 10:19:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by lists.bell-labs.com (Postfix) with ESMTP id C952644336 for ; Wed, 20 Dec 2000 09:48:38 -0500 (EST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id HAA05625; Wed, 20 Dec 2000 07:47:46 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id HAA16928; Wed, 20 Dec 2000 07:47:41 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14912.54428.985021.320003@thomasm-u1.cisco.com> To: "Steve Donovan" Cc: "Simon Barber" , "Jonathan Rosenberg" , "'Sean Olson'" , "'David Shrader'" , "SIP List" Subject: RE: [SIP] Record-Route and REGISTER In-Reply-To: References: <01f801c06a19$99d98530$3a0514ac@sbarber2k> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 07:47:40 -0800 (PST) Content-Transfer-Encoding: 7bit This is a cheap shot, but is anybody else a little incredulous about trying to squeeze out more semantics for SIP these days? Any more richness, and SIP is going to start suffering from gout... Mike Steve Donovan writes: > > > > -----Original Message----- > > From: Simon Barber [mailto:simon@firetalk.com] > > Sent: Tuesday, December 19, 2000 6:13 PM > > To: Jonathan Rosenberg; 'Sean Olson'; Steve Donovan > > Cc: 'David Shrader'; SIP List > > Subject: Re: [SIP] Record-Route and REGISTER > > > > > > From: "Jonathan Rosenberg" > > To: "'Sean Olson'" ; "Steve Donovan" > > > > Cc: "Jonathan Rosenberg" ; "'David Shrader'" > > ; "SIP List" > > Sent: Tuesday, December 19, 2000 3:16 PM > > Subject: RE: [SIP] Record-Route and REGISTER > > > > > > > This issue is what I meant when I said: > > > > > > >What is the the scope of the Route? To which set of messages does > > > >it apply? When can the route be purged? > > > > > > The obvious generalization of the current Route mechanism is that a UA > > uses > > > the Routes for all requests with the same To/From/Call-ID. This > > would then > > > effect refreshes of REGISTER, and is also how we handle > > record-routing of > > > SUBSCRIBE/NOTIFY and MESSAGE as well. > > > > > > What would you use RR on REGISTER for? Not sure... any ideas? > > > > > > A firewall proxy for a large private network might want to keep state for > > the registration of a UA - and also load-balance. This brings up > > the further > > question of keeping the same proxy in the loop for future INVITE and other > > methods, as well as future REGISTERs. > > But the can't the firewall proxy use the state that is already in the > registrar to which the REGISTER is being sent? > > I can see that use of record-route would make a more efficient method for > routing REGISTERs to the same registrar (after the first is sent). However, > there are other methods (for instance, routing based on the to field). As > such, is it worth it to create a special way of handling record-routes just > for REGISTER messages? This seems to me to break the KISS principle. > > more below... > > > > > -----Original Message----- > > > > From: Sean Olson [mailto:sean.olson@ericsson.com] > > > > Sent: Tuesday, December 19, 2000 2:18 PM > > > > To: Steve Donovan > > > > Cc: Jonathan Rosenberg; 'David Shrader'; SIP List > > > > Subject: Re: [SIP] Record-Route and REGISTER > > > > > > > > > > > > What about subsequent re-registrations? It is conceivable that > > > > a stateful proxy might want to know about these re-registrations > > > > (perhaps for caching purposes). Of course, this doesn't help > > > > with the case where multiple UAs are registering for the same > > > > user. > > Again, shouldn't that stateful proxy use the registrar/location server for > it's domain? That's the only way to fix the multiple UA registering > problem. > > > > > > > > > Sean > > > > > > > > Steve Donovan wrote: > > > > > > > > > > Why are we worried about record-routing REGISTER messages. > > > > Record-Routing > > > > > is used to ensure that all messages within a session go > > > > through interested > > > > > proxies. This is obviously useful with INVITE and SUBSCRIBE. > > > > > > > > > > There is no session created by REGISTER. As such, there > > > > are no other > > > > > messages that need to take the same route. > > > > > > > > > > Is the goal to ensure that subsequent REGISTER requests > > > > make it to the same > > > > > instance of a registrar within a domain? If so, is the use > > > > of Record-Route > > > > > the correct solution? > > > > > > > > > > Steve > > > > > > > > > > > -----Original Message----- > > > > > > From: sip-admin@lists.bell-labs.com > > > > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > > > > Jonathan Rosenberg > > > > > > Sent: Tuesday, December 19, 2000 12:25 AM > > > > > > To: 'David Shrader'; SIP List > > > > > > Subject: RE: [SIP] Record-Route and REGISTER > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: David Shrader [mailto:dshrader@master-consultant.com] > > > > > > > Sent: Sunday, December 17, 2000 3:40 PM > > > > > > > To: SIP List > > > > > > > Subject: [SIP] Record-Route and REGISTER > > > > > > > > > > > > > > When using the REGISTER method, however, the Contact header > > > > > > > is NOT used for > > > > > > > that purpose. The Contact header in the Response to a > > > > > > > REGISTER is simply a > > > > > > > list of registered contacts and does not in fact identify the > > > > > > > recipient of a > > > > > > > subsequent request. > > > > > > > > > > > > Correct. REGISTER is nearly a separate protocol, for all > > > > intents and > > > > > > purposes. As specified right now, record-routing for > > > > REGISTER is ambigous. > > > > > > In any case, record-routing for transactions outside of INVITE is > > > > > > not clear. > > > > > > What is the the scope of the Route? To which set of messages does > > > > > > it apply? > > > > > > When can the route be purged? These issues must be > > > > resolved as well, and > > > > > > they are much harder. > > > > > > > > > > > > The solution to your specific problem is for the UAC and > > > > UAC to use RR in > > > > > > REGISTER instead. So: > > > > > > > > > > > > 1. A UAC inserts a REcord-route into the REGISTER > > > > pointing to itself, just > > > > > > like the Contact would look in an INVITE > > > > > > 2. proxies can record-route > > > > > > 3. UAS (the registrar, in this case) also adds a RR, and reflects > > > > > > that back > > > > > > in 200 OK > > > > > > 4. Route is constructed normally except COntact is ignored > > > > > > > > > > > > > > > > > > Kind of a pain to have a special procedure for REGISTER, > > > > I know. In > > > > > > hindsight, I would have used something instead of Contact > > > > here, but at the > > > > > > time rfc2543 was being written, the usages were similar enough > > > > > > and the idea > > > > > > of record-routing REGISTER was not something we considered. > > > > > > > > > > > > -Jonathan R. > > > > > > --- > > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > > Chief Scientist First Floor > > > > > > dynamicsoft East Hanover, NJ 07936 > > > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > _______________________________________________ > > > > > > SIP mailing list > > > > > > SIP@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 11:26:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01645 for ; Wed, 20 Dec 2000 11:26:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E37DE44342; Wed, 20 Dec 2000 10:26:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 2B84B44337 for ; Wed, 20 Dec 2000 10:25:10 -0500 (EST) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-green.research.att.com (Postfix) with ESMTP id 847821E008 for ; Wed, 20 Dec 2000 11:25:00 -0500 (EST) Received: from fish-ha.research.att.com (fish-ha.research.att.com [135.207.27.137]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id LAA24884 for ; Wed, 20 Dec 2000 11:24:59 -0500 (EST) From: William Marshall Received: (from wtm@localhost) by fish-ha.research.att.com (980427.SGI.8.8.8/8.8.5) id LAA43175 for sip@lists.bell-labs.com; Wed, 20 Dec 2000 11:25:58 -0500 (EST) Message-Id: <200012201625.LAA43175@fish-ha.research.att.com> To: sip@lists.bell-labs.com Subject: Re: [SIP] Inteligent Codec Selection Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 11:25:58 -0500 (EST) tsearle@valhalla.marko.net wrote: > > I would like to set up a SIP solution that would negotiate to use G.711 > if there is sufficient bandwith between the two endpoints to do so, and would > negotiate G.723.1 otherwise. > > Is there any way to do codec negotiation in such a manner? Unfortunately there are limits to what can be said in the language of SDP. But within that, there are at least three possibilities. 1) send an INVITE with only G.711, with qos required. If it fails with the 580-Precondition-Failure, try again with an INVITE with only G.723.1, again with qos required. 2) send an INVITE with two media streams, G.711 with qos optional, and a second media stream for G.723.1 with qos required. After getting the COMET, UAS can decide which media stream to use. The UAC finds this out when the media stream starts, since it indicated its willingness to receive both simultaneously. Alternatively, we could require SDP in the 200-OK (in addition to the 183) which would inform the UAC, and allow it to prepare for only one stream. 3) send an INVITE with two media streams, both with qos optional and requesting a COMET from UAS. When UAC receives the COMET, it decides which codec to use; the COMET it sends to UAS contains the succss/failure indication for each codec, which tells the UAS which to use. The convention in cases (2) and (3) is that the UAC/UAS would not use a codec for which the qos reservation failed, even if it appears in an m= line in the SDP. Bill Marshall wtm@research.att.com -----original message----- From: Manoj Bhatia To: Sunitha Kumar Cc: tsearle@valhalla.marko.net, sip@lists.bell-labs.com Subject: Re: [SIP] Inteligent Codec Selection Date: Mon, 18 Dec 2000 10:21:36 -0500 Even if you use , manyfolks draft for SIP /QOS reservations and figure out that you need to switch to G.723 from G.711 , you would still need a re-INVITE/mid-call INVITE mechanism to trigger the event. Sunitha Kumar wrote: > check out draft-manyfolks-sip-resource-01.txt. > it talks about resource reservation. > > > > > tsearle@valhalla.marko.net wrote: > >> I would like to set up a SIP solution that would negotiate to use >> G.711 >> if there is sufficient bandwith between the two endpoints to do so, >> and would >> negotiate G.723.1 otherwise. >> >> Is there any way to do codec negotiation in such a manner? >> >> Torrey >> >> _______________________________________________ >> SIP mailing list >> SIP@lists.bell-labs.com >> http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Sunitha Kumar > http://www.cisco.com > > -- Manoj Bhatia | | | manojb@cisco.com | :|: :|: 7025 Kit Creek Road, RTP, NC - 27709 | :|||||: :|||||: Ph: 919-392-3873 Fax:919-392-6801 | C i s c o S y s t e m s _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 11:47:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02934 for ; Wed, 20 Dec 2000 11:47:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 92B864433B; Wed, 20 Dec 2000 10:47:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id 8BF7944340 for ; Wed, 20 Dec 2000 10:46:02 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 20 Dec 2000 16:45:53 UT Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id QAA10986; Wed, 20 Dec 2000 16:44:33 GMT Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id QAA03287; Wed, 20 Dec 2000 16:44:34 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs From: James Undery To: William Marshall Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue In-Reply-To: <200012201542.KAA18106@fish-ha.research.att.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 16:44:34 +0000 (GMT) On Wed, 20 Dec 2000, William Marshall wrote: > > > From: "James Undery" > > > To: wtm@research.att.com, sip@lists.bell-labs.com > > > Subject: Re: [SIP] Solving the REFER retransmit issue > > > Date: Fri, 15 Dec 2000 01:14:43 -0000 > > > > > > You can and should send provisional responces to all requests that you can't > > > process in a specific time (200ms IIRC). > > Is this true even for non-INVITEs? Section 7.1 and Section 10.1.2 > Doesn't a provisional response turn off > the retransmission of the request? No it switches from the T1 exponential backoff scheme to T2 retransmission > How is reliability of the 200-OK > response guaranteed> In the normal way, although your next sentence explains this question. > > It was my understanding that a proxy only sends a 100-Trying to an > INVITE, not to other requests. All other requests do only end-end > reliability, not hop-hop. > No to put it bluntly. James Undery _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 11:51:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA03078 for ; Wed, 20 Dec 2000 11:51:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 78C1744350; Wed, 20 Dec 2000 10:51:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cvis21.Marconicomms.com (cvis21.marconicomms.com [195.99.244.53]) by lists.bell-labs.com (Postfix) with ESMTP id 1D0774433B for ; Wed, 20 Dec 2000 10:50:05 -0500 (EST) Received: from cvis01.gpt.co.uk (unverified) by cvis21.Marconicomms.com (Content Technologies SMTPRS 4.1.5) with ESMTP id ; Wed, 20 Dec 2000 16:51:08 +0000 Received: from marconicomms.com by cvis01.gpt.co.uk with SMTP (8.8.8+Sun/cvms-30) id QAA17894; Wed, 20 Dec 2000 16:49:53 GMT Received: by marconicomms.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 802569BB.005C76A2 ; Wed, 20 Dec 2000 16:49:56 +0000 X-Lotus-FromDomain: MCMAIN@MCEXT From: "Wayne Cutler" To: Jonathan Rosenberg Cc: SIP List Message-ID: <802569BB.005C70EA.00@marconicomms.com> Subject: RE: [SIP] Record-Route and REGISTER Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 16:49:15 +0000 >This issue is what I meant when I said: >What is the the scope of the Route? To which set of messages does >it apply? When can the route be purged? >The obvious generalization of the current Route mechanism is that a UA uses >the Routes for all requests with the same To/From/Call-ID. This would then >effect refreshes of REGISTER, and is also how we handle record-routing of >SUBSCRIBE/NOTIFY and MESSAGE as well. >What would you use RR on REGISTER for? Not sure... any ideas? One use could be to force all subsequent signalling to be routed to a specific address - i.e. different from that used in the REGISTER. All future sessions are within the context of this registration and so it (sort of) fits in with how RR is normally used. Wayne. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 12:01:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA03631 for ; Wed, 20 Dec 2000 12:01:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA2BE4434B; Wed, 20 Dec 2000 11:01:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id B5ED844337 for ; Wed, 20 Dec 2000 11:00:20 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 20 Dec 2000 11:00:25 -0600 (CST) From: Billy Biggs To: "Fairlie-Cuninghame, Robert" Cc: Jonathan Rosenberg , Keith Robinson , SIP List Subject: Re: [SIP] Proxy Routing Logic Message-ID: <20001220110025.A9268@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rfairlie@nuera.com on Wed, Dec 20, 2000 at 12:29:28AM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 11:00:25 -0600 Fairlie-Cuninghame, Robert (rfairlie@nuera.com): > [Of course there will be always be different routing behaviour > depending on whether the request has a Route or not. If a Route exists > it would be followed. If the Route doesn't exist you want to recreate > the original routing action (for subsequent requests). This needs to > be accomplished by either storing route state local or embedding the > imformation in the Record-Route.] Right, but this decision should only occur after you've decided if the request is for you. It's very important that proxies don't just assume the request is meant for them if it happens to appear on one of their listening sockets. I just wanted to bring up the issue to raise awareness. > I don't see your maddr concerns as a problem - in fact it is darn > useful. If a Contact or Record-Route has an maddr it should be acted > upon by a UAC - even if the UAC has an outbound proxy configured (I > believe). No. An outbound proxy receives all outgoing requests, regardless of the request-URI (even if it has an maddr). Otherwise, firewall proxies wouldn't work. > If a UAC with an outbound proxy configured _wasn't_ to act on the > maddr, then a redirect server would be rendered useless (if it was > configured as the outbound proxy). > > Eg: > UAC send INVITE sip:555-1220@company.com;user=phone SIP/2.0 to outbound > proxy (which is redirect server). So, the outbound proxy is authoritative for company.com, right? > Server returns 302 with > Contact: > > If the UAC ignores the maddr then it would simply send the INVITE to > the same outbound proxy again. No, the INVITE should go to the outbound proxy, who then decides if the request was destined for it. In this case, the proxy proxies to gateway.com. For interoperability reasons we should be clear on this definition. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 12:24:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA04849 for ; Wed, 20 Dec 2000 12:24:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5303B44338; Wed, 20 Dec 2000 11:24:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by lists.bell-labs.com (Postfix) with ESMTP id 7E28D44336 for ; Wed, 20 Dec 2000 11:23:46 -0500 (EST) Received: from mailserver1.ericsson.se (mailserver1.ericsson.se [136.225.152.91]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id eBKHNZ424747; Wed, 20 Dec 2000 18:23:35 +0100 (MET) Received: from lmf.ericsson.se ([159.107.1.23]) by mailserver1.ericsson.se (8.9.3/8.9.3/eri-1.0) with ESMTP id SAA19276; Wed, 20 Dec 2000 18:23:32 +0100 (MET) Message-ID: <3A40EB22.173B097D@lmf.ericsson.se> From: Gonzalo Camarillo Organization: Oy L M Ericsson Ab X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: Steve Donovan Cc: Jonathan Rosenberg , "'Pekka Pessi'" , sip@lists.bell-labs.com Subject: Re: [SIP] RE: Changin local RTP port without a good reason References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 19:23:46 +0200 Content-Transfer-Encoding: 7bit Hi, Steve Donovan wrote: > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Jonathan Rosenberg > > Sent: Tuesday, December 19, 2000 12:31 AM > > To: 'Pekka Pessi'; sip@lists.bell-labs.com > > Cc: Gonzalo Camarillo > > Subject: RE: [SIP] RE: Changin local RTP port without a good reason > > > > > > > > > > > > > > > -----Original Message----- > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > Sent: Monday, December 18, 2000 3:30 AM > > > To: sip@lists.bell-labs.com > > > Cc: Gonzalo Camarillo > > > Subject: Re: [SIP] RE: Changin local RTP port without a good reason > > > > > > > > > In message <3A3989CA.8F5E7117@lmf.ericsson.se> "ext Gonzalo > > > Camarillo" writes: > > > >Of course that sometimes you have to change your local > > > configuration if > > > >the remote configuration changes... but there has to be a good reason > > > >(like a change of codecs). > > > > > > When you issue a re-INVITE with a new local port number, you are > > > proposing a new RTP session. The remote end can not > > > distinguish > > > between packets in the old session and new session, unless it > > > changes its RTP port, too. > > > > > > Much as I would like to be able to enforce this "don't change > > ports without > > good reason", I think there are cases where implementations will > > want to do > > this on each re-invite. As such, I think the mechanism in the current 3pcc > > draft won't work either. > > > > An alternative flow has already been proposed which does not > > suffer from the > > timeout problem, and which does not have this race condition: > > > > > > A Controller B > > > > | INV SDP held | | time t = 0 > > > > |<------------------| | > > > > | | | > > > > | 200 SDP A1 | | > > > > |-----------------> | | > > > > | | | > > > > | ACK | | > > > > |<------------------| | > > > > | | | > > > > | | INV no SDP | > > > > | |----------------->| (1) > > > > | | | > > > > | | 200 SDP B | > > > > | |<-----------------| > > > > | INV SDP B | | > > > > |<------------------| | > > > > | | | > > > > | 200 SDP A2 | | > > > > |-----------------> | | > > > > | | | > > > > | | ACK SDP A2 | > > > > | ACK |----------------->| > > > > |<------------------| | > > > > | | | > > > > | | RTP | > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > | | | > > > > > > I'd like to start with this one as the basis for continuing > > discussion/concerns. > > What is the end-user experience with this call? What does the > user at A do when he gets a call that is on hold and hears silence? > Isn't there a high probability that he will hang up while the > controller is waiting for B to answer? > > In order for this to work, isn't it necessary for the controller to > play some sort of media telling the user to hold on while the call > is being setup? Either that or A needs to understand that it is > a 3PCC call and know to either not notify the user or tell the user > to wait. > One very common scenario in 3pcc in that where A is a machine and B is a human. The controller is an Application Server that coordinates several APCs in order to provide a service to the end user B. Thus, A will not hang because it is a machine. However, when A and B are both humans we have the problem you have just described. Actually it does not make any difference for the controller send the 1st INVITE on hold or with a real SDP in order to sent a pre-recorded announcement. Let's focus on solving the 3pcc problem. Playing announcement is already taken care of by vanilla SIP. Besides, I do not think interactions between announcements and 3pcc are complicated. I find more challenging QoS provision interactions. Best regards, Gonzalo > --- > Steven R. Donovan > Architect dynamicsoft > mailto:sdonovan@dynamicsoft.com 5100 Tennyson Parkway > sip:sdonovan@sip.dynamicsoft.com Plano, Texas 75025 > tel:+1-972-473-5469 http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip -- Gonzalo Camarillo Phone : +358 9 299 33 71 Oy L M Ericsson Ab Mobile: +358 40 702 35 35 Telecom R&D Fax : +358 9 299 30 52 FIN-02420 Jorvas Email : Gonzalo.Camarillo@ericsson.com Finland http://www.hut.fi/~gonzalo _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 12:31:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05351 for ; Wed, 20 Dec 2000 12:31:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E390744338; Wed, 20 Dec 2000 11:31:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from drago1.ubiquity.net (news.ubiquity.net [194.202.146.92]) by lists.bell-labs.com (Postfix) with SMTP id AC63644337 for ; Wed, 20 Dec 2000 11:30:26 -0500 (EST) Received: from gecko.ubiquity.net by drago1.ubiquity.net via smtpd (for share.research.bell-labs.com [204.178.16.58]) with SMTP; 20 Dec 2000 17:30:17 UT Received: from jhornsby by ubiquity.net with SMTP (8.8.8+Sun/25-eef) id RAA29191; Wed, 20 Dec 2000 17:25:24 GMT From: "Jo Hornsby" To: "Billy Biggs" , "Fairlie-Cuninghame, Robert" Cc: "Jonathan Rosenberg" , "Keith Robinson" , "SIP List" Subject: RE: [SIP] Proxy Routing Logic Message-ID: <000301c06aa9$d5d187f0$4e34c3c1@ubiquity.co.uk> 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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <20001220110025.A9268@div8.net> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 17:25:23 -0000 Content-Transfer-Encoding: 7bit Billy wrote: > > Fairlie-Cuninghame, Robert (rfairlie@nuera.com): > > > [Of course there will be always be different routing behaviour > > depending on whether the request has a Route or not. If a Route exists > > it would be followed. If the Route doesn't exist you want to recreate > > the original routing action (for subsequent requests). This needs to > > be accomplished by either storing route state local or embedding the > > imformation in the Record-Route.] > > Right, but this decision should only occur after you've decided if the > request is for you. It's very important that proxies don't just assume > the request is meant for them if it happens to appear on one of their > listening sockets. I just wanted to bring up the issue to raise > awareness. Maybe I'm not following properly, since I'm jumping in mid-stream, as it were, but if I get a request, I'm going to do my best to honour it. Maybe I won't know anything about the domain in the Request-URI, but I'll SRV and A, and hopefully everything will still be okay. I would see this as highly desirable behaviour. > No. An outbound proxy receives all outgoing requests, regardless of > the request-URI (even if it has an maddr). Otherwise, firewall proxies > wouldn't work. We discussed the definition of an "outbound proxy" a while ago, and while I don't think there was unanimousity (schyeah), I think the general feeling was that an outbound proxy is only used for the initial request; if it wants to stay in the loop, it Record-Route s. Or am I just imagining things again? - Jo. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 12:54:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06767 for ; Wed, 20 Dec 2000 12:54:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8AB1444337; Wed, 20 Dec 2000 11:54:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id 9312C44336 for ; Wed, 20 Dec 2000 11:53:24 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Wed, 20 Dec 2000 11:53:33 -0600 (CST) From: Billy Biggs To: Jo Hornsby Cc: "Fairlie-Cuninghame, Robert" , Jonathan Rosenberg , Keith Robinson , SIP List Subject: Re: [SIP] Proxy Routing Logic Message-ID: <20001220115333.A9367@div8.net> References: <20001220110025.A9268@div8.net> <000301c06aa9$d5d187f0$4e34c3c1@ubiquity.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <000301c06aa9$d5d187f0$4e34c3c1@ubiquity.co.uk>; from jhornsby@ubiquity.net on Wed, Dec 20, 2000 at 05:25:23PM -0000 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 11:53:33 -0600 Jo Hornsby (jhornsby@ubiquity.net): >>> [Of course there will be always be different routing behaviour >>> depending on whether the request has a Route or not. [...] >> >> Right, but this decision should only occur after you've decided if >> the request is for you. It's very important that proxies don't just >> assume the request is meant for them if it happens to appear on one >> of their listening sockets. [...] > > Maybe I'm not following properly, since I'm jumping in mid-stream, as > it were, but if I get a request, I'm going to do my best to honour it. > Maybe I won't know anything about the domain in the Request-URI, but > I'll SRV and A, and hopefully everything will still be okay. By "honour it" you mean proxy it to the destination indicated by the Request-URI (and maybe add a Record-Route), right? I just want to make sure proxies don't replace the request-URI blindly with the next Route unless the request is destined for them. >> No. An outbound proxy receives all outgoing requests, regardless >> of the request-URI (even if it has an maddr). Otherwise, firewall >> proxies wouldn't work. > > We discussed the definition of an "outbound proxy" a while ago, and > while I don't think there was unanimousity (schyeah), I think the > general feeling was that an outbound proxy is only used for the > initial request; if it wants to stay in the loop, it Record-Route s. > Or am I just imagining things again? What would be the benefit? I like the algorithm "all outgoing requests are sent to the outbound proxy". It's simple and it works. Of course, responses should instead just go to the received address. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 13:23:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08695 for ; Wed, 20 Dec 2000 13:23:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 21E6C44337; Wed, 20 Dec 2000 12:23:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj_ntserver3.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62]) by lists.bell-labs.com (Postfix) with ESMTP id 3AD3244336 for ; Wed, 20 Dec 2000 12:22:40 -0500 (EST) Received: by sj_ntserver3.sj.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 10:22:29 -0800 Message-ID: From: "Emami-Nouri, Mohsen" To: "'Steve Donovan'" , Simon Barber , Jonathan Rosenberg , "'Sean Olson'" Cc: "'David Shrader'" , SIP List Subject: RE: [SIP] Record-Route and REGISTER MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 10:22:22 -0800 -----Original Message----- From: Steve Donovan [mailto:sdonovan@dynamicsoft.com] Sent: Wednesday, December 20, 2000 7:12 AM To: Simon Barber; Jonathan Rosenberg; 'Sean Olson' Cc: 'David Shrader'; SIP List Subject: RE: [SIP] Record-Route and REGISTER > -----Original Message----- > From: Simon Barber [mailto:simon@firetalk.com] > Sent: Tuesday, December 19, 2000 6:13 PM > To: Jonathan Rosenberg; 'Sean Olson'; Steve Donovan > Cc: 'David Shrader'; SIP List > Subject: Re: [SIP] Record-Route and REGISTER > > > From: "Jonathan Rosenberg" > To: "'Sean Olson'" ; "Steve Donovan" > > Cc: "Jonathan Rosenberg" ; "'David Shrader'" > ; "SIP List" > Sent: Tuesday, December 19, 2000 3:16 PM > Subject: RE: [SIP] Record-Route and REGISTER > > > > This issue is what I meant when I said: > > > > >What is the the scope of the Route? To which set of messages does > > >it apply? When can the route be purged? > > > > The obvious generalization of the current Route mechanism is that a UA > uses > > the Routes for all requests with the same To/From/Call-ID. This > would then > > effect refreshes of REGISTER, and is also how we handle > record-routing of > > SUBSCRIBE/NOTIFY and MESSAGE as well. > > > > What would you use RR on REGISTER for? Not sure... any ideas? > > > A firewall proxy for a large private network might want to keep state for > the registration of a UA - and also load-balance. This brings up > the further > question of keeping the same proxy in the loop for future INVITE and other > methods, as well as future REGISTERs. But the can't the firewall proxy use the state that is already in the registrar to which the REGISTER is being sent? I can see that use of record-route would make a more efficient method for routing REGISTERs to the same registrar (after the first is sent). However, there are other methods (for instance, routing based on the to field). I do not think this is a good idea no routing decision should be made based on "to" header, can we make a exception for reigsration and do routing based on "to" header?, clearly no such, is it worth it to create a special way of handling record-routes just for REGISTER messages? This seems to me to break the KISS principle. more below... > > > -----Original Message----- > > > From: Sean Olson [mailto:sean.olson@ericsson.com] > > > Sent: Tuesday, December 19, 2000 2:18 PM > > > To: Steve Donovan > > > Cc: Jonathan Rosenberg; 'David Shrader'; SIP List > > > Subject: Re: [SIP] Record-Route and REGISTER > > > > > > > > > What about subsequent re-registrations? It is conceivable that > > > a stateful proxy might want to know about these re-registrations > > > (perhaps for caching purposes). Of course, this doesn't help > > > with the case where multiple UAs are registering for the same > > > user. Again, shouldn't that stateful proxy use the registrar/location server for it's domain? That's the only way to fix the multiple UA registering problem. > > > > > > Sean > > > > > > Steve Donovan wrote: > > > > > > > > Why are we worried about record-routing REGISTER messages. > > > Record-Routing > > > > is used to ensure that all messages within a session go > > > through interested > > > > proxies. This is obviously useful with INVITE and SUBSCRIBE. > > > > > > > > There is no session created by REGISTER. As such, there > > > are no other > > > > messages that need to take the same route. > > > > > > > > Is the goal to ensure that subsequent REGISTER requests > > > make it to the same > > > > instance of a registrar within a domain? If so, is the use > > > of Record-Route > > > > the correct solution? > > > > > > > > Steve > > > > > > > > > -----Original Message----- > > > > > From: sip-admin@lists.bell-labs.com > > > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > > > Jonathan Rosenberg > > > > > Sent: Tuesday, December 19, 2000 12:25 AM > > > > > To: 'David Shrader'; SIP List > > > > > Subject: RE: [SIP] Record-Route and REGISTER > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: David Shrader [mailto:dshrader@master-consultant.com] > > > > > > Sent: Sunday, December 17, 2000 3:40 PM > > > > > > To: SIP List > > > > > > Subject: [SIP] Record-Route and REGISTER > > > > > > > > > > > > When using the REGISTER method, however, the Contact header > > > > > > is NOT used for > > > > > > that purpose. The Contact header in the Response to a > > > > > > REGISTER is simply a > > > > > > list of registered contacts and does not in fact identify the > > > > > > recipient of a > > > > > > subsequent request. > > > > > > > > > > Correct. REGISTER is nearly a separate protocol, for all > > > intents and > > > > > purposes. As specified right now, record-routing for > > > REGISTER is ambigous. > > > > > In any case, record-routing for transactions outside of INVITE is > > > > > not clear. > > > > > What is the the scope of the Route? To which set of messages does > > > > > it apply? > > > > > When can the route be purged? These issues must be > > > resolved as well, and > > > > > they are much harder. > > > > > > > > > > The solution to your specific problem is for the UAC and > > > UAC to use RR in > > > > > REGISTER instead. So: > > > > > > > > > > 1. A UAC inserts a REcord-route into the REGISTER > > > pointing to itself, just > > > > > like the Contact would look in an INVITE > > > > > 2. proxies can record-route > > > > > 3. UAS (the registrar, in this case) also adds a RR, and reflects > > > > > that back > > > > > in 200 OK > > > > > 4. Route is constructed normally except COntact is ignored > > > > > > > > > > > > > > > Kind of a pain to have a special procedure for REGISTER, > > > I know. In > > > > > hindsight, I would have used something instead of Contact > > > here, but at the > > > > > time rfc2543 was being written, the usages were similar enough > > > > > and the idea > > > > > of record-routing REGISTER was not something we considered. > > > > > > > > > > -Jonathan R. > > > > > --- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East Hanover, NJ 07936 > > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > > > > http://www.dynamicsoft.com > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 15:13:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13282 for ; Wed, 20 Dec 2000 15:13:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3CB4544337; Wed, 20 Dec 2000 14:13:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 247E044336 for ; Wed, 20 Dec 2000 14:12:50 -0500 (EST) Received: from athletics ([63.110.3.226]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id PAA29978; Wed, 20 Dec 2000 15:14:49 -0500 (EST) From: "Steve Donovan" To: "Emami-Nouri, Mohsen" , "Simon Barber" , "Jonathan Rosenberg" , "'Sean Olson'" Cc: "'David Shrader'" , "SIP List" Subject: RE: [SIP] Record-Route and REGISTER 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.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 14:09:45 -0600 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: Emami-Nouri, Mohsen [mailto:memami@nuera.com] > Sent: Wednesday, December 20, 2000 12:22 PM > To: 'Steve Donovan'; Simon Barber; Jonathan Rosenberg; 'Sean Olson' > Cc: 'David Shrader'; SIP List > Subject: RE: [SIP] Record-Route and REGISTER > > > > A firewall proxy for a large private network might want to keep > state for > > the registration of a UA - and also load-balance. This brings up > > the further > > question of keeping the same proxy in the loop for future > INVITE and other > > methods, as well as future REGISTERs. > > But the can't the firewall proxy use the state that is already in the > registrar to which the REGISTER is being sent? > > I can see that use of record-route would make a more efficient method for > routing REGISTERs to the same registrar (after the first is > sent). However, > there are other methods (for instance, routing based on the to field). > > I do not think this is a good idea no routing decision should be > made based > on "to" header, can we make a exception for reigsration and do > routing based > on "to" header?, clearly no > In general I agree. However, the example given for use of record-routing registers was to assist in load balancing between multiple registrar's for the same domain. Given that the only information in the request-uri is the domain name, the load balancing decision must be made on something else. The most likely candidate is the To URL, given that this identifies the party to which the registration applies. This is not part of the baseline SIP defined routing behavior, as baseline SIP does not deal with load balancing between registrars. And I agree with your point that this should not be part of the baseline SIP specification. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 15:19:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13452 for ; Wed, 20 Dec 2000 15:19:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 361F044356; Wed, 20 Dec 2000 14:19:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lists.bell-labs.com (Postfix) with ESMTP id EE98D44337 for ; Wed, 20 Dec 2000 14:18:53 -0500 (EST) Received: [from mothost.mot.com (mothost.mot.com [129.188.137.101]) by motgate2.mot.com (motgate2 2.1) with ESMTP id NAA03205 for ; Wed, 20 Dec 2000 13:18:43 -0700 (MST)] Received: [from il27exb01.cig.mot.com (il27exb01.cig.mot.com [136.182.15.100]) by mothost.mot.com (MOT-mothost 2.0) with ESMTP id NAA02239 for ; Wed, 20 Dec 2000 13:18:43 -0700 (MST)] Received: by il27exb01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Wed, 20 Dec 2000 14:18:42 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED88CB@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: "'Anuraj Ennai'" , sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 14:18:24 -0600 Oh well... It all sounds rightful and good, but there may be commercial systems, which will be needing this capability though... Life could be ugly I know... -----Original Message----- From: Anuraj Ennai [mailto:anuraj.ennai@wipro.com] Sent: Wednesday, December 20, 2000 1:17 AM To: sip@lists.bell-labs.com Subject: Re: [SIP] Proxies modifying SDP Hi all, I believe proxies should be discouraged from prying into SDP contents(or any message body that does not concern them) for scalability, security and privacy reasons. The mechanism for capability negotiation etc. should be implemented at UA, using methods like OPTIONs and/or headers like supported/ Unsupported or Re-INVITEs. It mandates passing 1 or 2 messages more between the UAs, but in the end scales up well. If the proxy needs SDP content negotiation, it can spawn its own call agent which works exactly like the UA. In the end, it is all about KISS!!! Thanks & regards Anuraj Ennai Wipro Technologies -India. Subject: Re: [SIP] Proxies modifying SDP Date: Tue, 19 Dec 2000 10:56:04 -0600 From: David Frascone To: Steve Gardell CC: "'Baniel Uri-CUB001'" , sip@lists.bell-labs.com References: 1 This might be a useless response, since I can't find the example document that I'm about to refer too . . but . . . In the documents I read before San Diego, I remember two pictures of a proxied senario. In the first, the SIP requests were proxied, but the RTP was sent normally. In the second, the SIP requests were proxied, *and* the RTP was proxied. In this senario, didn't the SIP proxy have to modify the SDP to get it to work? Please: I know someone else read this document, or saw the slides I'm refering too . . . . Someone help refresh my poor tired memory :) -Dave On Tue, Dec 19, 2000 at 11:43:25AM -0500, Steve Gardell wrote: > If memory serves, a "fully routed" H.323 gatekeepers routes the media > negotiation signalling, but does not route the actual RTP traffic. > > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Monday, December 18, 2000 8:05 PM > To: 'Steve Donovan'; Baniel Uri-CUB001; 'Neil Deason'; > jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > Hmm... > Probably I was not clear and hence the confusion. > My intention was to be able to mimic the 'H323 gate keeper mode' > functionality, i.e. to have the end points think they talk to each other (in > the media streaming phase) but actually the media goes via a gate keeper. In > our SIP world this should be just a MG (Media Gateway). > The control may still go via a SIP proxy server, that is why I think > changing SDP fields (specifically the IP address for receiving media as well > as the RTP ports) may easily achieve this goal > > Uri > > -----Original Message----- > From: Steve Donovan [mailto:sdonovan@dynamicsoft.com] > Sent: Sunday, December 17, 2000 9:12 PM > To: Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; > bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 15:31:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13824 for ; Wed, 20 Dec 2000 15:31:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2674644356; Wed, 20 Dec 2000 14:31:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj_ntserver3.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62]) by lists.bell-labs.com (Postfix) with ESMTP id 77F4544345 for ; Wed, 20 Dec 2000 14:30:20 -0500 (EST) Received: by sj_ntserver3.sj.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 12:30:10 -0800 Message-ID: From: "Emami-Nouri, Mohsen" To: "'Keith Robinson'" , Jonathan Rosenberg Cc: "'Neil Deason'" , Billy Biggs , Jean-Francois Mule , sip@lists.bell-labs.com Subject: RE: [SIP] Bug in 2543bis-02 re: Record-Route MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 12:30:09 -0800 Talking roubestness, proxy adding itself to each requests would only take care of responses going the right route, but not any new request after an UA crashed. For that the route ninformation needs to get persistant, so that the UA also after a crash still has the route information, am I right? -----Original Message----- From: Keith Robinson [mailto:Keith.Robinson@marconi.com] Sent: Wednesday, December 20, 2000 1:17 AM To: Jonathan Rosenberg Cc: 'Neil Deason'; Billy Biggs; Jean-Francois Mule; sip@lists.bell-labs.com Subject: RE: [SIP] Bug in 2543bis-02 re: Record-Route Requiring a proxy to add itself to each request for robustness in case the UA crashes is fine but it has to be MUST to be sure it stays in the path as it cant know when the UA is about to crash-reboot. Regards, K. Robinson _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 15:54:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA14625 for ; Wed, 20 Dec 2000 15:54:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F199B4434E; Wed, 20 Dec 2000 14:54:11 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id E24A144337 for ; Wed, 20 Dec 2000 14:53:17 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Dec 20 15:50:37 EST 2000 Received: by lists.bell-labs.com (Postfix) id AA24C44380; Wed, 20 Dec 2000 15:38:33 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 2DD864437D for ; Wed, 20 Dec 2000 15:38:33 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA16584; Wed, 20 Dec 2000 14:38:30 -0600 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA16577; Wed, 20 Dec 2000 14:38:28 -0600 Message-ID: <3A4118C1.D47BC62C@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Emami-Nouri, Mohsen" Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Bug in 2543bis-02 re: Record-Route References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 14:38:25 -0600 Content-Transfer-Encoding: 7bit "Emami-Nouri, Mohsen" wrote: > > Talking roubestness, proxy adding itself to each requests would only take > care of responses going the right route, but not any new request after an > UA crashed. I suspect not; the responses will follow the Via list, not the Route list. > For that the route ninformation needs to get persistant, so that > the UA also after a crash still has the route information, am I right? Hence the need for every proxy to include a R-R so that a crashed UA can resurrect the Route list from the R-R headers in the request it got after rebooting. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 17:29:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA17823 for ; Wed, 20 Dec 2000 17:29:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 72F7844337; Wed, 20 Dec 2000 16:29:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj_ntserver3.sj.nuera.com (h-207-20-110-62.ncal.verio.net [207.20.110.62]) by lists.bell-labs.com (Postfix) with ESMTP id 5C27744336 for ; Wed, 20 Dec 2000 16:28:31 -0500 (EST) Received: by sj_ntserver3.sj.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 14:28:21 -0800 Message-ID: From: "Emami-Nouri, Mohsen" To: "'Vijay Gurbani'" , "Emami-Nouri, Mohsen" Cc: sip@lists.bell-labs.com Subject: RE: [SIP] Bug in 2543bis-02 re: Record-Route MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 14:28:14 -0800 When a UA crashes after the call is stablished, and then it comes back and wants to cancel or bye the call , since it has not got any route information for that call-leg, so the UA can not send this request through the proxies , which insisted to be visited by any request belonging to the same call. So my question is how this could be solved by proxies adding RR to each request blonging to the same call. -----Original Message----- From: Vijay Gurbani [mailto:vkg@lucent.com] Sent: Wednesday, December 20, 2000 12:38 PM To: Emami-Nouri, Mohsen Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Bug in 2543bis-02 re: Record-Route "Emami-Nouri, Mohsen" wrote: > > Talking roubestness, proxy adding itself to each requests would only take > care of responses going the right route, but not any new request after an > UA crashed. I suspect not; the responses will follow the Via list, not the Route list. > For that the route ninformation needs to get persistant, so that > the UA also after a crash still has the route information, am I right? Hence the need for every proxy to include a R-R so that a crashed UA can resurrect the Route list from the R-R headers in the request it got after rebooting. - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 20 18:53:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA19905 for ; Wed, 20 Dec 2000 18:53:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0905C44337; Wed, 20 Dec 2000 17:53:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id EB34144336 for ; Wed, 20 Dec 2000 17:52:22 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 20 Dec 2000 15:51:56 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jo Hornsby'" , Billy Biggs Cc: Jonathan Rosenberg , Keith Robinson , SIP List Subject: RE: [SIP] Proxy Routing Logic MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 20 Dec 2000 15:51:55 -0800 > > Billy wrote: > > > > Fairlie-Cuninghame, Robert (rfairlie@nuera.com): > > > > > [Of course there will be always be different routing behaviour > > > depending on whether the request has a Route or not. If a > Route exists > > > it would be followed. If the Route doesn't exist you want > to recreate > > > the original routing action (for subsequent requests). > This needs to > > > be accomplished by either storing route state local or > embedding the > > > imformation in the Record-Route.] > > > > Right, but this decision should only occur after you've > decided if the > > request is for you. It's very important that proxies don't > just assume > > the request is meant for them if it happens to appear on > one of their > > listening sockets. I just wanted to bring up the issue to raise > > awareness. > > Maybe I'm not following properly, since I'm jumping in mid-stream, > as it were, but if I get a request, I'm going to do my best to > honour it. Maybe I won't know anything about the domain in the > Request-URI, but I'll SRV and A, and hopefully everything will > still be okay. > > I would see this as highly desirable behaviour. Billy's right on this one. The proxy would do everything to honour the request URI if it does not refer to it's own proxy address. If the proxy can determine that the request-uri is consistent with a previously generated Record-Route then it uses the next Route header or reproduces the previous routing action. > > No. An outbound proxy receives all outgoing requests, > regardless of > > the request-URI (even if it has an maddr). Otherwise, > firewall proxies > > wouldn't work. > > We discussed the definition of an "outbound proxy" a while ago, > and while I don't think there was unanimousity (schyeah), I > think the general feeling was that an outbound proxy is only > used for the initial request; if it wants to stay in the loop, > it Record-Route s. Or am I just imagining things again? > Yeah that's what I thought Jo - an outbound proxy keeps itself in the path using R-R (if required). This is not only more flexible but also fits nicely within the SIP framework. Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 08:54:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA19212 for ; Thu, 21 Dec 2000 08:54:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DC0FA44337; Thu, 21 Dec 2000 07:54:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web1106.mail.yahoo.com (web1106.mail.yahoo.com [128.11.23.126]) by lists.bell-labs.com (Postfix) with SMTP id 65D4944336 for ; Thu, 21 Dec 2000 07:53:09 -0500 (EST) Received: (qmail 2479 invoked by uid 60001); 21 Dec 2000 13:52:59 -0000 Message-ID: <20001221135259.2478.qmail@web1106.mail.yahoo.com> Received: from [132.208.135.60] by web1106.mail.yahoo.com; Thu, 21 Dec 2000 14:52:59 CET From: =?iso-8859-1?q?rufin=20soh?= To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] proxy and RTP Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 14:52:59 +0100 (CET) Content-Transfer-Encoding: 8bit For a proxy to handle UA requests and responses very well, I think we should consider 3 issues: proxy must not support any codecs in RTP or SDP. after a 200 response, the futher state should be nothing other than establishing communication(without codecs, since there is no specifications yet in drafts about the standards to commonly adopt). To make port changing, proxy need to first be registered as all sip servers, so even if a UA don't have a proxy IP, it can just forward a request to all sip servers address. --- sip-request@lists.bell-labs.com a écrit : > Send SIP mailing list submissions to > sip@lists.bell-labs.com > > To subscribe or unsubscribe via the World Wide Web, > visit > http://lists.bell-labs.com/mailman/listinfo/sip > or, via email, send a message with subject or body > 'help' to > sip-request@lists.bell-labs.com > > You can reach the person managing the list at > sip-admin@lists.bell-labs.com > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of SIP digest..." > > > Today's Topics: > > 1. RE: 3pcc callflow question (Was:Changin local > RTP port with > out a good reason) (Fairlie-Cuninghame, > Robert) > 2. Re: Proxies modifying SDP (Anuraj Ennai) > 3. RE: Proxy Routing Logic (Fairlie-Cuninghame, > Robert) > 4. RE: Bug in 2543bis-02 re: Record-Route (Keith > Robinson) > 5. Re: RE: Changin local RTP port without a good > reason (Gonzalo Camarillo) > 6. RE: SIP Security Mailing List (Rosen, Brian) > 7. RE: Record-Route and REGISTER (Steve Donovan) > 8. RE: RE: Changin local RTP port without a good > reason (Steve Donovan) > > ATTACHMENT part 3.1 message/rfc822 > De: "Fairlie-Cuninghame, Robert" > > À: 'Robert Sparks' , > sip@lists.bell-labs.com > Objet: RE: [SIP] 3pcc callflow question (Was:Changin > local RTP port with > out a good reason) > Date: Tue, 19 Dec 2000 21:59:42 -0800 > > > > > Doesn't matter. Notice that in the original > diagram, A1 > > isn't used in the negotiation with B. If A > automatically > > returns held sdp when it recieves held sdp, things > don't > > break. > > > > Out of curiosity, does anyone have a UA deployed > that won't > > accept an initial INVITE to held media? If so, it > argues for > > using the delayed media approach you suggest. > > > Hi Robert, > > I imagine that some UA's may not be happy with an > initial SDP (held) with no > vocoders, eg > > v=0 > o=... > c=IN IP4 0.0.0.0 > m=audio 10000 RTP/AVP > > [Otherwise the controller would have to know/guess > the lowest capabilities > of UA A - which is unacceptable.] > > Placing no SDP in the INVITE also has the advantage > that the controller can > immediately take action if it detects that the 200 > Ok from UA B (containing > SDP B) is incompatiable with SDP A1 (rather than the > UA A re-INVITE failing > ... which adds more chance of strange things > happening due to incorrect UA > re-INVITE error handling). > > Regards, > > Robert. > > > > > > -----Original Message----- > > > From: sip-admin@lists.bell-labs.com > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf > Of > > Fairlie-Cuninghame, > > > Robert > > > Sent: Tuesday, December 19, 2000 12:51 AM > > > To: sip@lists.bell-labs.com > > > Subject: RE: [SIP] 3pcc callflow question > (Was:Changin > > local RTP port > > > without a good reason) > > > > > > > > > > An alternative flow has already been proposed > which does not > > > > suffer from the > > > > timeout problem, and which does not have this > race condition: > > > > > > > > > > > > > A Controller B > > > > > > | INV SDP held | | > time t = 0 > > > > > > |<------------------| | > > > > > > | | | > > > > > > | 200 SDP A1 | | > > > > > > |-----------------> | | > > > > > > | | | > > > > > > | ACK | | > > > > > > |<------------------| | > > > > > > | | | > > > > > > Sorry to go back a bit but can I forget the > reason why it was > > > decided not to > > > start with: > > > > > > A Controller > > > > > > INV no SDP > > > <-------- > > > > > > 200 SDP A1 > > > --------> > > > > > > ACK SDP held > > > <-------- > > > > > > This seems simpler as both A and B are behaving > in the same > > manner (rather > > > than A having to realize that it must produce > SDP A1 when > > it receives an > > > initial SDP held). > > > > > > Was it because of crash-restart problems ? > > > > > > Regards, > > > > > > Robert. > > > > > > > > > > > > | | INV no SDP | > > > > > > | |----------------->| > (1) > > > > > > | | | > > > > > > | | 200 SDP B | > > > > > > | |<-----------------| > > > > > > | INV SDP B | | > > > > > > |<------------------| | > > > > > > | | | > > > > > > | 200 SDP A2 | | > > > > > > |-----------------> | | > > > > > > | | | > > > > > > | | ACK SDP A2 | > > > > > > | ACK |----------------->| > > > > > > |<------------------| | > > > > > > | | | > > > > > > | | RTP | > > > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > > > | | | > > > > > > > > > > > > I'd like to start with this one as the basis > for continuing > > > > discussion/concerns. > > > > > > > > -Jonathan R. > > > > > > > > > > > > --- > > > > Jonathan D. Rosenberg 72 > Eagle Rock Ave. > > > > Chief Scientist > First Floor > > > > dynamicsoft > East Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com > FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen > PHONE: (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > ATTACHMENT part 3.2 message/rfc822 > Date: Wed, 20 Dec 2000 12:47:06 +0530 > De: "Anuraj Ennai" > Affiliation: Wipro > À: sip@lists.bell-labs.com > Objet: Re: [SIP] Proxies modifying SDP > > Hi all, > > I believe proxies should be discouraged from prying > into SDP contents(or any message body that does > not concern them) for scalability, security and > privacy reasons. > > The mechanism for capability negotiation etc. > should be implemented at UA, using methods > like OPTIONs and/or headers like supported/ > Unsupported or Re-INVITEs. It mandates passing > 1 or 2 messages more between the UAs, but in the > end scales up well. If the proxy needs SDP content > negotiation, it can spawn its own call agent which > works exactly like the UA. > > In the end, it is all about KISS!!! > > Thanks & regards > Anuraj Ennai > Wipro Technologies -India. > > Subject: > Re: [SIP] Proxies modifying SDP > Date: > Tue, 19 Dec 2000 10:56:04 -0600 > From: > David Frascone > To: > Steve Gardell > CC: > "'Baniel Uri-CUB001'" > , sip@lists.bell-labs.com > References: > 1 > > > > This might be a useless response, since I can't find > the example document that > I'm about to refer too . . but . . . In the > documents I read before San Diego, > I remember two pictures of a proxied senario. > > In the first, the SIP requests were proxied, but the > RTP was sent normally. > > In the second, the SIP requests were proxied, *and* > the RTP was proxied. In > this senario, didn't the SIP proxy have to modify > the SDP to get it to work? > > Please: I know someone else read this document, or > saw the slides I'm > refering too . . . . Someone help refresh my poor > tired memory :) > > -Dave > > On Tue, Dec 19, 2000 at 11:43:25AM -0500, Steve > Gardell wrote: > > If memory serves, a "fully routed" H.323 > gatekeepers routes the media > > negotiation signalling, but does not route the > actual RTP traffic. > > > > -----Original Message----- > > From: Baniel Uri-CUB001 > [mailto:Uri.Baniel@motorola.com] > > Sent: Monday, December 18, 2000 8:05 PM > > To: 'Steve Donovan'; Baniel Uri-CUB001; 'Neil > Deason'; > > jfmule@clarent.com; bhoeneis@cc.hut.fi; > sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > Hmm... > > Probably I was not clear and hence the confusion. > > My intention was to be able to mimic the 'H323 > gate keeper mode' > > functionality, i.e. to have the end points think > they talk to each other (in > > the media streaming phase) but actually the media > goes via a gate keeper. In > > our SIP world this should be just a MG (Media > Gateway). > > The control may still go via a SIP proxy server, > that is why I think > > changing SDP fields (specifically the IP address > for receiving media as well > > as the RTP ports) may easily achieve this goal > > > > Uri > > > > -----Original Message----- > > From: Steve Donovan > [mailto:sdonovan@dynamicsoft.com] > > Sent: Sunday, December 17, 2000 9:12 PM > > To: Baniel Uri-CUB001; 'Neil Deason'; > jfmule@clarent.com; > > bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > > > ATTACHMENT part 3.3 message/rfc822 > De: "Fairlie-Cuninghame, Robert" > > À: 'Billy Biggs' , > Jonathan Rosenberg > CC: Keith Robinson , > SIP List > Objet: RE: [SIP] Proxy Routing Logic > Date: Wed, 20 Dec 2000 00:29:28 -0800 > > > > > If so, let's revisit the idea of copying the > Request-URI into the > > Route and adding an maddr. > > > > Consider an outbound proxy which adds a > record-route. An initial > > request arrives for jdrosen@dynamicsoft.com. The > proxy uses > > an RR URI: > > > > > sip:jdrosen@dynamicsoft.com;maddr=outbound.proxy.com > > > > So, when it sees new requests with this as the > request-URI, we have > > different behavior dependant on if there is a > Route. This makes me > > worried. > > > Hi Billy, > > I beleive under the new Record-Route suggestions the > proxy would be > recommended to add RR of > so that request > is always routed to the outbound proxy (to remove > ambiguity). > > [Of course there will be always be different routing > behaviour depending on > whether the request has a Route or not. If a Route > exists it would be > followed. If the Route doesn't exist you want to > recreate the original > routing action (for subsequent requests). This needs > to be accomplished by > either storing route state local or embedding the > imformation in the > Record-Route.] > > I don't see your maddr concerns as a problem - in > fact it is darn useful. If > a Contact or Record-Route has an maddr it should be > acted upon by a UAC - > even if the UAC has an outbound proxy configured (I > believe). > > If the outbound proxy wants to have ALL sip requests > sent to it (not just > the first INVITE) then it should record-route > itself!! > > If a UAC with an outbound proxy configured _wasn't_ > to act on the maddr, > then a redirect server would be rendered useless (if > it was configured as > the outbound proxy). > > Eg: > UAC send INVITE sip:555-1220@company.com;user=phone > SIP/2.0 to outbound > proxy (which is redirect server). > > Server returns 302 with > Contact: > > > If the UAC ignores the maddr then it would simply > send the INVITE to the > same outbound proxy again. > > Cheers, > > Robert. > > > ATTACHMENT part 3.4 message/rfc822 > De: "Keith Robinson" > À: Jonathan Rosenberg > CC: "'Neil Deason'" , > Billy Biggs , > Jean-Francois Mule , > sip@lists.bell-labs.com > Date: Wed, 20 Dec 2000 09:17:07 +0000 > Objet: RE: [SIP] Bug in 2543bis-02 re: Record-Route > > > > Requiring a proxy to add itself to each request for > robustness in case the UA > crashes is fine but > it has to be MUST to be sure it stays in the path as > it cant know when the UA is > about to crash-reboot. > > Regards, > > K. Robinson > > > > > ATTACHMENT part 3.5 message/rfc822 > Date: Wed, 20 Dec 2000 16:11:39 +0200 > De: Gonzalo Camarillo > > Affiliation: Oy L M Ericsson Ab > À: Jonathan Rosenberg > CC: "'Pekka Pessi'" , > sip@lists.bell-labs.com > Objet: Re: [SIP] RE: Changin local RTP port without > a good reason > > Hi, > > Actually there is nothing new with this flow. This > is the delayed ACK > solution that was already proposed. Since the > INV/200 OK will most > likely take little time, it will work. However, when > INV-200 OK takes > longer we have the same problem. > > In most of the situations, using the delayed ACK, > the flow you just > described works. However, if the SDP is not ready > and the ACK has to be > sent to stop the retransmission timer, we will still > have to make up an > SDP... we might want to work on this scenario. > > Best regards, > > Gonzalo > > Jonathan Rosenberg wrote: > > > > > > > > > -----Original Message----- > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > Sent: Monday, December 18, 2000 3:30 AM > > > To: sip@lists.bell-labs.com > > > Cc: Gonzalo Camarillo > > > Subject: Re: [SIP] RE: Changin local RTP port > without a good reason > > > > > > > > > In message <3A3989CA.8F5E7117@lmf.ericsson.se> > "ext Gonzalo > > > Camarillo" > writes: > > > >Of course that sometimes you have to change > your local > > > configuration if > > > >the remote configuration changes... but there > has to be a good reason > > > >(like a change of codecs). > > > > > > When you issue a re-INVITE with a new > local port number, you are > > > proposing a new RTP session. The remote > end can not > > > distinguish > > > between packets in the old session and > new session, unless it > > > changes its RTP port, too. > > > > Much as I would like to be able to enforce this > "don't change ports without > > good reason", I think there are cases where > implementations will want to do > > this on each re-invite. As such, I think the > mechanism in the current 3pcc > > draft won't work either. > > > > An alternative flow has already been proposed > which does not suffer from the > > timeout problem, and which does not have this race > condition: > > > > > > A Controller B > > > > | INV SDP held | | time > t = 0 > > > > |<------------------| | > > > > | | | > > > > | 200 SDP A1 | | > > > > |-----------------> | | > > > > | | | > > > > | ACK | | > > > > |<------------------| | > > > > | | | > > > > | | INV no SDP | > > > > | |----------------->| (1) > > > > | | | > > > > | | 200 SDP B | > > > > | |<-----------------| > > > > | INV SDP B | | > > > > |<------------------| | > > > > | | | > > > > | 200 SDP A2 | | > > > > |-----------------> | | > > > > | | | > > > > | | ACK SDP A2 | > > > > | ACK |----------------->| > > > > |<------------------| | > > > > | | | > > > > | | RTP | > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > | | | > > > > I'd like to start with this one as the basis for > continuing > > discussion/concerns. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg 72 > Eagle Rock Ave. > > Chief Scientist First > Floor > > dynamicsoft East > Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: > (973) 952-5000 > > http://www.dynamicsoft.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > -- > Gonzalo Camarillo Phone : +358 9 299 33 71 > Oy L M Ericsson Ab Mobile: +358 40 702 35 35 > Telecom R&D Fax : +358 9 299 30 52 > FIN-02420 Jorvas Email : > Gonzalo.Camarillo@ericsson.com > Finland http://www.hut.fi/~gonzalo > > > ATTACHMENT part 3.6 message/rfc822 > De: "Rosen, Brian" > À: "'Johan Liseborn'" , > SIP List > Date: Wed, 20 Dec 2000 09:36:05 -0500 > Objet: [SIP] RE: SIP Security Mailing List > > If you are interested in Security issues in SIP, > please subscribe to > the sip-security mailing list: > Post message: sip-security@egroups.com > Subscribe: sip-security-subscribe@egroups.com > Unsubscribe: sip-security-unsubscribe@egroups.com > > List owner: sip-security-owner@egroups.com > URL to web page: > http://www.egroups.com/group/sip-security > > Brian > > > > > ATTACHMENT part 3.7 message/rfc822 > De: "Steve Donovan" > À: "Simon Barber" , > "Jonathan Rosenberg" , > "'Sean Olson'" > CC: "'David Shrader'" > , > "SIP List" > Objet: RE: [SIP] Record-Route and REGISTER > Date: Wed, 20 Dec 2000 09:11:58 -0600 > > > > > -----Original Message----- > > From: Simon Barber [mailto:simon@firetalk.com] > > Sent: Tuesday, December 19, 2000 6:13 PM > > To: Jonathan Rosenberg; 'Sean Olson'; Steve > Donovan > > Cc: 'David Shrader'; SIP List > > Subject: Re: [SIP] Record-Route and REGISTER > > > > > > From: "Jonathan Rosenberg" > > > To: "'Sean Olson'" ; > "Steve Donovan" > > > > Cc: "Jonathan Rosenberg" > ; "'David Shrader'" > > ; "SIP List" > > > Sent: Tuesday, December 19, 2000 3:16 PM > > Subject: RE: [SIP] Record-Route and REGISTER > > > > > > > This issue is what I meant when I said: > > > > > > >What is the the scope of the Route? To which > set of messages does > > > >it apply? When can the route be purged? > > > > > > The obvious generalization of the current Route > mechanism is that a UA > > uses > > > the Routes for all requests with the same > To/From/Call-ID. This > > would then > > > effect refreshes of REGISTER, and is also how we > handle > > record-routing of > > > SUBSCRIBE/NOTIFY and MESSAGE as well. > > > > > > What would you use RR on REGISTER for? Not > sure... any ideas? > > > > > > A firewall proxy for a large private network might > want to keep state for > > the registration of a UA - and also load-balance. > This brings up > > the further > > question of keeping the same proxy in the loop for > future INVITE and other > > methods, as well as future REGISTERs. > > But the can't the firewall proxy use the state that > is already in the > registrar to which the REGISTER is being sent? > > I can see that use of record-route would make a more > efficient method for > routing REGISTERs to the same registrar (after the > first is sent). However, > there are other methods (for instance, routing based > on the to field). As > such, is it worth it to create a special way of > handling record-routes just > for REGISTER messages? This seems to me to break > the KISS principle. > > more below... > > > > > -----Original Message----- > > > > From: Sean Olson > [mailto:sean.olson@ericsson.com] > > > > Sent: Tuesday, December 19, 2000 2:18 PM > > > > To: Steve Donovan > > > > Cc: Jonathan Rosenberg; 'David Shrader'; SIP > List > > > > Subject: Re: [SIP] Record-Route and REGISTER > > > > > > > > > > > > What about subsequent re-registrations? It is > conceivable that > > > > a stateful proxy might want to know about > these re-registrations > > > > (perhaps for caching purposes). Of course, > this doesn't help > > > > with the case where multiple UAs are > registering for the same > > > > user. > > Again, shouldn't that stateful proxy use the > registrar/location server for > it's domain? That's the only way to fix the > multiple UA registering > problem. > > > > > > > > > Sean > > > > > > > > Steve Donovan wrote: > > > > > > > > > > Why are we worried about record-routing > REGISTER messages. > > > > Record-Routing > > > > > is used to ensure that all messages within a > session go > > > > through interested > > > > > proxies. This is obviously useful with > INVITE and SUBSCRIBE. > > > > > > > > > > There is no session created by REGISTER. As > such, there > > > > are no other > > > > > messages that need to take the same route. > > > > > > > > > > Is the goal to ensure that subsequent > REGISTER requests > > > > make it to the same > > > > > instance of a registrar within a domain? If > so, is the use > > > > of Record-Route > > > > > the correct solution? > > > > > > > > > > Steve > > > > > > > > > > > -----Original Message----- > > > > > > From: sip-admin@lists.bell-labs.com > > > > > > [mailto:sip-admin@lists.bell-labs.com]On > Behalf Of > > > > Jonathan Rosenberg > > > > > > Sent: Tuesday, December 19, 2000 12:25 AM > > > > > > To: 'David Shrader'; SIP List > > > > > > Subject: RE: [SIP] Record-Route and > REGISTER > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: David Shrader > [mailto:dshrader@master-consultant.com] > > > > > > > Sent: Sunday, December 17, 2000 3:40 PM > > > > > > > To: SIP List > > > > > > > Subject: [SIP] Record-Route and REGISTER > > > > > > > > > > > > > > When using the REGISTER method, however, > the Contact header > > > > > > > is NOT used for > > > > > > > that purpose. The Contact header in the > Response to a > > > > > > > REGISTER is simply a > > > > > > > list of registered contacts and does not > in fact identify the > > > > > > > recipient of a > > > > > > > subsequent request. > > > > > > > > > > > > Correct. REGISTER is nearly a separate > protocol, for all > > > > intents and > > > > > > purposes. As specified right now, > record-routing for > > > > REGISTER is ambigous. > > > > > > In any case, record-routing for > transactions outside of INVITE is > > > > > > not clear. > > > > > > What is the the scope of the Route? To > which set of messages does > > > > > > it apply? > > > > > > When can the route be purged? These issues > must be > > > > resolved as well, and > > > > > > they are much harder. > > > > > > > > > > > > The solution to your specific problem is > for the UAC and > > > > UAC to use RR in > > > > > > REGISTER instead. So: > > > > > > > > > > > > 1. A UAC inserts a REcord-route into the > REGISTER > > > > pointing to itself, just > > > > > > like the Contact would look in an INVITE > > > > > > 2. proxies can record-route > > > > > > 3. UAS (the registrar, in this case) also > adds a RR, and reflects > > > > > > that back > > > > > > in 200 OK > > > > > > 4. Route is constructed normally except > COntact is ignored > > > > > > > > > > > > > > > > > > Kind of a pain to have a special procedure > for REGISTER, > > > > I know. In > > > > > > hindsight, I would have used something > instead of Contact > > > > here, but at the > > > > > > time rfc2543 was being written, the usages > were === message truncated === > ATTACHMENT part 3.8 message/rfc822 > De: "Steve Donovan" > À: "Jonathan Rosenberg" , > "'Pekka Pessi'" , > > CC: "Gonzalo Camarillo" > > Objet: RE: [SIP] RE: Changin local RTP port without > a good reason > Date: Wed, 20 Dec 2000 09:17:12 -0600 > > > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > Jonathan Rosenberg > > Sent: Tuesday, December 19, 2000 12:31 AM > > To: 'Pekka Pessi'; sip@lists.bell-labs.com > > Cc: Gonzalo Camarillo > > Subject: RE: [SIP] RE: Changin local RTP port > without a good reason > > > > > > > > > > > > > > > -----Original Message----- > > > From: Pekka Pessi [mailto:Pekka.Pessi@nokia.com] > > > Sent: Monday, December 18, 2000 3:30 AM > > > To: sip@lists.bell-labs.com > > > Cc: Gonzalo Camarillo > > > Subject: Re: [SIP] RE: Changin local RTP port > without a good reason > > > > > > > > > In message <3A3989CA.8F5E7117@lmf.ericsson.se> > "ext Gonzalo > > > Camarillo" > writes: > > > >Of course that sometimes you have to change > your local > > > configuration if > > > >the remote configuration changes... but there > has to be a good reason > > > >(like a change of codecs). > > > > > > When you issue a re-INVITE with a new local > port number, you are > > > proposing a new RTP session. The remote > end can not > > > distinguish > > > between packets in the old session and > new session, unless it > > > changes its RTP port, too. > > > > > > Much as I would like to be able to enforce this > "don't change > > ports without > > good reason", I think there are cases where > implementations will > > want to do > > this on each re-invite. As such, I think the > mechanism in the current 3pcc > > draft won't work either. > > > > An alternative flow has already been proposed > which does not > > suffer from the > > timeout problem, and which does not have this race > condition: > > > > > > A Controller B > > > > | INV SDP held | | time > t = 0 > > > > |<------------------| | > > > > | | | > > > > | 200 SDP A1 | | > > > > |-----------------> | | > > > > | | | > > > > | ACK | | > > > > |<------------------| | > > > > | | | > > > > | | INV no SDP | > > > > | |----------------->| (1) > > > > | | | > > > > | | 200 SDP B | > > > > | |<-----------------| > > > > | INV SDP B | | > > > > |<------------------| | > > > > | | | > > > > | 200 SDP A2 | | > > > > |-----------------> | | > > > > | | | > > > > | | ACK SDP A2 | > > > > | ACK |----------------->| > > > > |<------------------| | > > > > | | | > > > > | | RTP | > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > |xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx | > > > > | | | > > > > > > I'd like to start with this one as the basis for > continuing > > discussion/concerns. > > What is the end-user experience with this call? > What does the > user at A do when he gets a call that is on hold and > hears silence? > Isn't there a high probability that he will hang up > while the > controller is waiting for B to answer? > > In order for this to work, isn't it necessary for > the controller to > play some sort of media telling the user to hold on > while the call > is being setup? Either that or A needs to > understand that it is > a 3PCC call and know to either not notify the user > or tell the user > to wait. > > --- > Steven R. Donovan > Architect dynamicsoft > mailto:sdonovan@dynamicsoft.com 5100 Tennyson > Parkway > sip:sdonovan@sip.dynamicsoft.com Plano, Texas > 75025 > tel:+1-972-473-5469 > http://www.dynamicsoft.com > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > ___________________________________________________________ Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, Yahoo! Messenger : http://fr.messenger.yahoo.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 11:18:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23131 for ; Thu, 21 Dec 2000 11:18:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A095944337; Thu, 21 Dec 2000 10:18:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from guardian1.tlv.radvision.com (unknown [212.143.185.30]) by lists.bell-labs.com (Postfix) with ESMTP id 45E5044336 for ; Thu, 21 Dec 2000 10:17:11 -0500 (EST) Received: from nt-mail.tlv.radvision.com ([172.20.2.100]) by guardian1.tlv.radvision.com (Post.Office MTA v3.5.3 release 223 ID# 0-0U10L2S100V35) with ESMTP id com; Thu, 21 Dec 2000 19:14:56 +0200 Received: by NT-MAIL with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 18:18:33 +0200 Message-ID: From: Itamar Gilad To: "'Bernie Hoeneisen'" , sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 18:18:32 +0200 Bernie, I agree with you that this is against SIP's definition of what a proxy is supposed to do (even though I'm not sure it's spelled out in the RFC). Another problem I see is that if a proxy removes one or more codecs it might create an m= line which has no codecs (empty format list). AFAIK this is not strictly illegal in SDP, but it might be very confusing for the receiving UA. Note that the proxy can't remove any of the m= lines because according to SIP the calling UA expects to receive the same number of m= lines in the response as were sent in the INVITE. Itamar > -----Original Message----- > From: Bernie Hoeneisen [mailto:bhoeneis@cc.hut.fi] > Sent: Tue, December 19, 2000 7:28 PM > To: bcampbell@dynamicsoft.com > Cc: Steve Donovan; Baniel Uri-CUB001; Neil Deason; jfmule@clarent.com; > bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > Hi again > > On Mon, 18 Dec 2000 bcampbell@dynamicsoft.com wrote: > > > I suspect the original writer refers to some sort of media gateway > > that is not SIP enabled. Therefore one could not simply proxy the > > call to the gateway. > > My original question was a bit different one and it is not directly > related to media gateways. > In the case I was describing, there are SIP proxies, which know about > policy in the network and would interact while the INVITE is > passing them. Such proxies would remove certain codecs from the SDP. > I have some doubts, that it is a good idea... > > Thus, I am posting my original question again (see below, last line). > > Hoping for more comments on this... > > Cheers > Bernie > > PS: Here my original email: > > > On Fri, 15 Dec 2000, Bernie Hoeneisen wrote: > > > I have question concerning the case, when SIP proxies modify SDP, > > which is AFAIK against SIP principles, isn't it? > > > > In the concrete case, proxies would be able to remove certain codecs > > from the INVITE messages, depending on the current policy in the > > network. (The UAS gets a subset of the codecs, which were originally > > sent by the UAC.) > > > > What impact does such a proxy behavior have to SIP? I can think of > > problems with authentication and message integrity checking > (UAC signs > > message with its private key). > > > > Are there any other problems? Any comments are appreciated. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 11:21:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23224 for ; Thu, 21 Dec 2000 11:21:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 55F4E44355; Thu, 21 Dec 2000 10:21:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailweb24.rediffmail.com (unknown [203.199.83.148]) by lists.bell-labs.com (Postfix) with SMTP id F097D44355 for ; Thu, 21 Dec 2000 10:20:00 -0500 (EST) Received: (qmail 32439 invoked by uid 510); 21 Dec 2000 16:18:56 -0000 Message-ID: <20001221161856.32438.qmail@mailweb24.rediffmail.com> MIME-Version: 1.0 To: "sip@lists.bell-labs.com" From: "Vijeth D" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Subject: [SIP] Subscribe Notify Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 21 Dec 2000 16:18:56 -0000 Content-Transfer-Encoding: 7bit Hi, Can anyone tell as to where I can find the details about the subscribe-notify methods. I could not find it in bis-02 _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 11:31:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23497 for ; Thu, 21 Dec 2000 11:31:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2CA1E44368; Thu, 21 Dec 2000 10:31:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from commserver.iperia.com (mailhost.iperia.com [207.31.192.99]) by lists.bell-labs.com (Postfix) with ESMTP id 07AA34435D for ; Thu, 21 Dec 2000 10:30:43 -0500 (EST) Received: by commserver.iperia.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 11:31:29 -0500 Message-ID: <5143F854B82ED211B05E00104B235F642A0F5D@commserver.iperia.com> From: Gordon Ledgard To: "'Vijeth D'" , sip@lists.bell-labs.com Subject: RE: [SIP] Subscribe Notify MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 11:31:28 -0500 try... http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-02.t xt and http://search.ietf.org/internet-drafts/draft-mahy-sip-message-waiting-00.txt Gordon Ledgard Iperia, Inc. -----Original Message----- From: Vijeth D [mailto:vijethd@rediffmail.com] Sent: Thursday, December 21, 2000 11:19 AM To: sip@lists.bell-labs.com Subject: [SIP] Subscribe Notify Hi, Can anyone tell as to where I can find the details about the subscribe-notify methods. I could not find it in bis-02 _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 11:48:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA23974 for ; Thu, 21 Dec 2000 11:48:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6D9AF44357; Thu, 21 Dec 2000 10:48:12 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id B47A944336 for ; Thu, 21 Dec 2000 10:47:16 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Thu Dec 21 11:44:55 EST 2000 Received: by lists.bell-labs.com (Postfix) id A40BC44384; Thu, 21 Dec 2000 11:32:50 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 4D72C4437D for ; Thu, 21 Dec 2000 11:32:50 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA00594; Thu, 21 Dec 2000 10:32:47 -0600 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id KAA00585; Thu, 21 Dec 2000 10:32:46 -0600 Message-ID: <3A4230AA.F80B7A1C@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: "Emami-Nouri, Mohsen" Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Bug in 2543bis-02 re: Record-Route References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 10:32:42 -0600 Content-Transfer-Encoding: 7bit "Emami-Nouri, Mohsen" wrote: > > When a UA crashes after the call is stablished, and then it comes back and > wants to cancel or bye the call , The assumption that a UA after a reboot needs to BYE or CANCEL a call implies that the UA saved state in persistent store before it crashed, right? If that is the case, the UA presumably can also save the Route information as part of the call state, so when it comes back up after a reboot, it knows the Route list? Or am I missing something? > since it has not got any route information for that call-leg, so the UA > can not send this request through the proxies , which insisted to be > visited by any request belonging to the same call. So my question is how > this could be solved by proxies adding RR to each request blonging to the > same call. Adding R-R on every request helps UAS that may crash, reboot, and receive a re-INVITE for the call; the re-INVITE will have R-Rs added by upstream proxies from which the UAS can resurrect the Route list. There are some postings on the SIP mailing list discussing the genesis of this addition in 2000q2 SIP archives. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 12:46:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25634 for ; Thu, 21 Dec 2000 12:46:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CE6C044337; Thu, 21 Dec 2000 11:46:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0538F44336 for ; Thu, 21 Dec 2000 11:45:50 -0500 (EST) Received: from dynamicsoft.com (1Cust225.tnt3.dub2.ie.uudial.net [213.116.44.225] (may be forged)) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA07250; Thu, 21 Dec 2000 12:48:14 -0500 (EST) Message-ID: <3A4241D0.58429FC7@dynamicsoft.com> From: Chris Harris Organization: dynamicsoft X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com, discussion@sipforum.org Content-Type: multipart/alternative; boundary="------------6927359C0438BF6436078E82" Subject: [SIP] JAIN SIP First Public Release submitted Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 17:45:52 +0000 --------------6927359C0438BF6436078E82 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all, The First Public Release of the JAIN SIP specification has been submitted and should be posted here this week: http://java.sun.com/aboutJava/communityprocess/first.html. For those of you who would like to take a look at the latest specification now, you can download a HTML or PDF version if you join the jainsip egroup here: http://www.egroups.com/group/jainsip. Please post comments to jainsip@egroups.com Regards, Chris Harris --------------6927359C0438BF6436078E82 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear all,

The First Public Release of the JAIN SIP specification has been submitted and should be posted here this week: http://java.sun.com/aboutJava/communityprocess/first.html. For those of you who would like to take a look at the latest specification now, you can download a HTML or PDF version if you join the jainsip egroup here: http://www.egroups.com/group/jainsip.

Please post comments to jainsip@egroups.com

Regards,
Chris Harris
  --------------6927359C0438BF6436078E82-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 13:26:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA26633 for ; Thu, 21 Dec 2000 13:26:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F24F644353; Thu, 21 Dec 2000 12:26:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from motgate.mot.com (motgate.mot.com [129.188.136.100]) by lists.bell-labs.com (Postfix) with ESMTP id CD00E44336 for ; Thu, 21 Dec 2000 11:36:15 -0500 (EST) Received: [from pobox3.mot.com (pobox3.mot.com [10.64.251.242]) by motgate.mot.com (motgate 2.1) with ESMTP id KAA17168 for ; Thu, 21 Dec 2000 10:36:05 -0700 (MST)] Received: [from il27exm07.cig.mot.com (IL27EXM07.cig.mot.com [136.182.15.116]) by pobox3.mot.com (MOT-pobox3 2.0) with ESMTP id KAA18961 for ; Thu, 21 Dec 2000 10:32:54 -0700 (MST)] Received: by IL27EXM07.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Thu, 21 Dec 2000 11:36:04 -0600 Message-ID: <61B3FF56AE89D4118F8A009027B0FE99010663D8@IL27EXM07.cig.mot.com> From: Lau Wei-Terk Jason-A13484 To: "Bell-Labs SIP List (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Registration query Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 11:34:49 -0600 Hi, On page 30 of RFC2543bis it states: "CSeq: Registrations with the same Call-ID MUST have increasing CSeq header values. However, the server does not reject out-of-order requests" Does that imply that a REGISTER with same Call-ID but lower CSeq will get a 2xx response but the registration is silently discarded (no updates to registration records) ? Or should the server continue to update regardless of the CSeq ? Would appreciate a clarification from anyone. Thanks ! Regards, Jason _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 14:45:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28561 for ; Thu, 21 Dec 2000 14:45:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F26A54433E; Thu, 21 Dec 2000 13:45:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-4.cisco.com (sj-msg-core-4.cisco.com [171.71.163.10]) by lists.bell-labs.com (Postfix) with ESMTP id 8BB6B44336 for ; Thu, 21 Dec 2000 13:44:20 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-4.cisco.com (8.9.3/8.9.1) with ESMTP id LAA29256; Thu, 21 Dec 2000 11:44:11 -0800 (PST) Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with SMTP id AAF29899; Thu, 21 Dec 2000 11:44:09 -0800 (PST) Message-Id: <4.1.20001221091555.00abbf00@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Gordon Ledgard , "'Vijeth D'" , sip@lists.bell-labs.com From: Rohan Mahy Subject: RE: [SIP] Subscribe Notify In-Reply-To: <5143F854B82ED211B05E00104B235F642A0F5D@commserver.iperia.c om> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 09:18:46 -0800 Hi, Please consult draft-roach-sip-subscribe-notify for SUBSCRIBE/NOTIFY behavior. The message waiting draft by Ilya and I will be updated before Minneapolis to reflect that behvior. thanks, -rohan At 08:31 AM 12/21/00 , Gordon Ledgard wrote: > >try... > > >http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-02.t >xt > >and > >http://search.ietf.org/internet-drafts/draft-mahy-sip-message-waiting-00.txt > > >Gordon Ledgard >Iperia, Inc. > > > >-----Original Message----- >From: Vijeth D [mailto:vijethd@rediffmail.com] >Sent: Thursday, December 21, 2000 11:19 AM >To: sip@lists.bell-labs.com >Subject: [SIP] Subscribe Notify > > >Hi, >Can anyone tell as to where I can find the details about the >subscribe-notify methods. I could not find it in bis-02 > >_____________________________________________________ >Chat with your friends as soon as they come online. Get Rediff Bol at >http://bol.rediff.com > > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 14:46:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA28599 for ; Thu, 21 Dec 2000 14:46:51 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 86D9544379; Thu, 21 Dec 2000 13:46:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 335B844336 for ; Thu, 21 Dec 2000 13:45:04 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id OAA08446; Thu, 21 Dec 2000 14:46:16 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 14:41:10 -0500 Message-ID: From: Igor Slepchin To: Jonathan Rosenberg , "'Sean Olson'" , Steve Donovan Cc: "'David Shrader'" , SIP List Subject: RE: [SIP] Record-Route and REGISTER MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 14:41:04 -0500 One thing I'd like to ensure is that proxies insert Record-Route in all requests, no matter what the request method is (CANCEL and ACK are possible exceptions). It is then up to the endpoints to decide whether there is any use for that Record-Route. If we do that this way, the proxies won't need to know about cryptic things like "Record-Route for INVITEs and SUBSCRIBEs but not for REGISTER". Makes defining new methods much easier. --- Igor Slepchin > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > This issue is what I meant when I said: > > >What is the the scope of the Route? To which set of messages does > >it apply? When can the route be purged? > > The obvious generalization of the current Route mechanism is > that a UA uses > the Routes for all requests with the same To/From/Call-ID. > This would then > effect refreshes of REGISTER, and is also how we handle > record-routing of > SUBSCRIBE/NOTIFY and MESSAGE as well. > > What would you use RR on REGISTER for? Not sure... any ideas? > > -Jonathan R. > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Sean Olson [mailto:sean.olson@ericsson.com] > > Sent: Tuesday, December 19, 2000 2:18 PM > > To: Steve Donovan > > Cc: Jonathan Rosenberg; 'David Shrader'; SIP List > > Subject: Re: [SIP] Record-Route and REGISTER > > > > > > What about subsequent re-registrations? It is conceivable that > > a stateful proxy might want to know about these re-registrations > > (perhaps for caching purposes). Of course, this doesn't help > > with the case where multiple UAs are registering for the same > > user. > > > > Sean > > > > Steve Donovan wrote: > > > > > > Why are we worried about record-routing REGISTER messages. > > Record-Routing > > > is used to ensure that all messages within a session go > > through interested > > > proxies. This is obviously useful with INVITE and SUBSCRIBE. > > > > > > There is no session created by REGISTER. As such, there > > are no other > > > messages that need to take the same route. > > > > > > Is the goal to ensure that subsequent REGISTER requests > > make it to the same > > > instance of a registrar within a domain? If so, is the use > > of Record-Route > > > the correct solution? > > > > > > Steve > > > > > > > -----Original Message----- > > > > From: sip-admin@lists.bell-labs.com > > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > > Jonathan Rosenberg > > > > Sent: Tuesday, December 19, 2000 12:25 AM > > > > To: 'David Shrader'; SIP List > > > > Subject: RE: [SIP] Record-Route and REGISTER > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: David Shrader [mailto:dshrader@master-consultant.com] > > > > > Sent: Sunday, December 17, 2000 3:40 PM > > > > > To: SIP List > > > > > Subject: [SIP] Record-Route and REGISTER > > > > > > > > > > When using the REGISTER method, however, the Contact header > > > > > is NOT used for > > > > > that purpose. The Contact header in the Response to a > > > > > REGISTER is simply a > > > > > list of registered contacts and does not in fact identify the > > > > > recipient of a > > > > > subsequent request. > > > > > > > > Correct. REGISTER is nearly a separate protocol, for all > > intents and > > > > purposes. As specified right now, record-routing for > > REGISTER is ambigous. > > > > In any case, record-routing for transactions outside of > INVITE is > > > > not clear. > > > > What is the the scope of the Route? To which set of > messages does > > > > it apply? > > > > When can the route be purged? These issues must be > > resolved as well, and > > > > they are much harder. > > > > > > > > The solution to your specific problem is for the UAC and > > UAC to use RR in > > > > REGISTER instead. So: > > > > > > > > 1. A UAC inserts a REcord-route into the REGISTER > > pointing to itself, just > > > > like the Contact would look in an INVITE > > > > 2. proxies can record-route > > > > 3. UAS (the registrar, in this case) also adds a RR, > and reflects > > > > that back > > > > in 200 OK > > > > 4. Route is constructed normally except COntact is ignored > > > > > > > > > > > > Kind of a pain to have a special procedure for REGISTER, > > I know. In > > > > hindsight, I would have used something instead of Contact > > here, but at the > > > > time rfc2543 was being written, the usages were similar enough > > > > and the idea > > > > of record-routing REGISTER was not something we considered. > > > > > > > > -Jonathan R. > > > > --- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East > Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > (973) 952-5000 > > > > http://www.dynamicsoft.com > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 15:07:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29155 for ; Thu, 21 Dec 2000 15:07:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 17B4044353; Thu, 21 Dec 2000 14:07:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id E74FD44337 for ; Thu, 21 Dec 2000 14:06:41 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 21 Dec 2000 14:06:50 -0600 (CST) From: Billy Biggs To: Igor Slepchin Cc: Jonathan Rosenberg , Sean Olson , Steve Donovan , David Shrader , SIP List Subject: Re: [SIP] Record-Route and REGISTER Message-ID: <20001221140650.A10730@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ISlepchin@dynamicsoft.com on Thu, Dec 21, 2000 at 02:41:04PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 14:06:50 -0600 Igor Slepchin (ISlepchin@dynamicsoft.com): > One thing I'd like to ensure is that proxies insert Record-Route in > all requests, no matter what the request method is (CANCEL and ACK are > possible exceptions). It is then up to the endpoints to decide whether > there is any use for that Record-Route. > > If we do that this way, the proxies won't need to know about cryptic > things like "Record-Route for INVITEs and SUBSCRIBEs but not for > REGISTER". Makes defining new methods much easier. Please, don't Record-Route unless you need to. If all proxies Record-Route'ed, we get: 1) Huge messages 2) Increased failure probability 3) Increased delay 4) Intelligence in the network 5) ... A call-logger should only Record-Route for INVITE-initiated call legs. Of course, a firewall proxy should Record-Route everything, but that is a very special case. I've heard rumors that some proxies Record-Route unconditionally (!!). -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 15:14:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29341 for ; Thu, 21 Dec 2000 15:14:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB76F44375; Thu, 21 Dec 2000 14:14:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 3664E44375 for ; Thu, 21 Dec 2000 14:13:03 -0500 (EST) Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eBLKC7K01917; Thu, 21 Dec 2000 14:12:07 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id eBLK98G24220; Thu, 21 Dec 2000 14:09:08 -0600 (CST) Received: from ericsson.com (pc050188.exu.ericsson.se [138.85.50.188]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA29036; Thu, 21 Dec 2000 14:12:06 -0600 (CST) Message-ID: <3A4262A0.3DE18A6C@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Igor Slepchin Cc: Jonathan Rosenberg , Steve Donovan , "'David Shrader'" , SIP List Subject: Re: [SIP] Record-Route and REGISTER References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 14:05:53 -0600 Content-Transfer-Encoding: 7bit I'm hoping that proxies are not blindly inserting Record-Route, ie. there is a reason for them to insert it in the first place. I understand the need to insert a RR in the INVITE/CANCEL/ACK/BYE. This is distinct from the need to insert a RR in the SUB/NOT. This is also distinct from the need to insert a RR in the REGISTER. The desire of a proxy to be in the signalling path for each of these scenarios is based on different functions the proxy is hoping to perform. That being said, I believe that once a proxy RR's in one of these situations, it should RR for *all* methods that match that call leg including possibly future unknown methods. RR is well defined for all methods within a call leg. What is up for consideration (I believe -- please correct me if I'm wrong) is whether a RR in the REGISTER should also apply to the INVITE/CANCEL/ACK/BYE and vice-versa. Given that these are two different call legs, this would be new behaviour. I can see value for both sides. But fundamentally, RR is for the benefit of the proxies, not the UAs. The UAs should not be making decisions about whether or not RR is appropriate for a given method. my two cents /sean Igor Slepchin wrote: > > One thing I'd like to ensure is that proxies insert Record-Route in all > requests, no matter what the request method is (CANCEL and ACK are possible > exceptions). It is then up to the endpoints to decide whether there is any > use for that Record-Route. > > If we do that this way, the proxies won't need to know about cryptic things > like "Record-Route for INVITEs and SUBSCRIBEs but not for REGISTER". Makes > defining new methods much easier. > > --- > Igor Slepchin > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > This issue is what I meant when I said: > > > > >What is the the scope of the Route? To which set of messages does > > >it apply? When can the route be purged? > > > > The obvious generalization of the current Route mechanism is > > that a UA uses > > the Routes for all requests with the same To/From/Call-ID. > > This would then > > effect refreshes of REGISTER, and is also how we handle > > record-routing of > > SUBSCRIBE/NOTIFY and MESSAGE as well. > > > > What would you use RR on REGISTER for? Not sure... any ideas? > > > > -Jonathan R. > > --- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > > -----Original Message----- > > > From: Sean Olson [mailto:sean.olson@ericsson.com] > > > Sent: Tuesday, December 19, 2000 2:18 PM > > > To: Steve Donovan > > > Cc: Jonathan Rosenberg; 'David Shrader'; SIP List > > > Subject: Re: [SIP] Record-Route and REGISTER > > > > > > > > > What about subsequent re-registrations? It is conceivable that > > > a stateful proxy might want to know about these re-registrations > > > (perhaps for caching purposes). Of course, this doesn't help > > > with the case where multiple UAs are registering for the same > > > user. > > > > > > Sean > > > > > > Steve Donovan wrote: > > > > > > > > Why are we worried about record-routing REGISTER messages. > > > Record-Routing > > > > is used to ensure that all messages within a session go > > > through interested > > > > proxies. This is obviously useful with INVITE and SUBSCRIBE. > > > > > > > > There is no session created by REGISTER. As such, there > > > are no other > > > > messages that need to take the same route. > > > > > > > > Is the goal to ensure that subsequent REGISTER requests > > > make it to the same > > > > instance of a registrar within a domain? If so, is the use > > > of Record-Route > > > > the correct solution? > > > > > > > > Steve > > > > > > > > > -----Original Message----- > > > > > From: sip-admin@lists.bell-labs.com > > > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > > > Jonathan Rosenberg > > > > > Sent: Tuesday, December 19, 2000 12:25 AM > > > > > To: 'David Shrader'; SIP List > > > > > Subject: RE: [SIP] Record-Route and REGISTER > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: David Shrader [mailto:dshrader@master-consultant.com] > > > > > > Sent: Sunday, December 17, 2000 3:40 PM > > > > > > To: SIP List > > > > > > Subject: [SIP] Record-Route and REGISTER > > > > > > > > > > > > When using the REGISTER method, however, the Contact header > > > > > > is NOT used for > > > > > > that purpose. The Contact header in the Response to a > > > > > > REGISTER is simply a > > > > > > list of registered contacts and does not in fact identify the > > > > > > recipient of a > > > > > > subsequent request. > > > > > > > > > > Correct. REGISTER is nearly a separate protocol, for all > > > intents and > > > > > purposes. As specified right now, record-routing for > > > REGISTER is ambigous. > > > > > In any case, record-routing for transactions outside of > > INVITE is > > > > > not clear. > > > > > What is the the scope of the Route? To which set of > > messages does > > > > > it apply? > > > > > When can the route be purged? These issues must be > > > resolved as well, and > > > > > they are much harder. > > > > > > > > > > The solution to your specific problem is for the UAC and > > > UAC to use RR in > > > > > REGISTER instead. So: > > > > > > > > > > 1. A UAC inserts a REcord-route into the REGISTER > > > pointing to itself, just > > > > > like the Contact would look in an INVITE > > > > > 2. proxies can record-route > > > > > 3. UAS (the registrar, in this case) also adds a RR, > > and reflects > > > > > that back > > > > > in 200 OK > > > > > 4. Route is constructed normally except COntact is ignored > > > > > > > > > > > > > > > Kind of a pain to have a special procedure for REGISTER, > > > I know. In > > > > > hindsight, I would have used something instead of Contact > > > here, but at the > > > > > time rfc2543 was being written, the usages were similar enough > > > > > and the idea > > > > > of record-routing REGISTER was not something we considered. > > > > > > > > > > -Jonathan R. > > > > > --- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East > > Hanover, NJ 07936 > > > > > jdrosen@dynamicsoft.com FAX: > > (973) 952-5050 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > > (973) 952-5000 > > > > > http://www.dynamicsoft.com > > > > > > > > > > _______________________________________________ > > > > > SIP mailing list > > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 15:21:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA29472 for ; Thu, 21 Dec 2000 15:21:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2FE3744386; Thu, 21 Dec 2000 14:21:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9241D4437E for ; Thu, 21 Dec 2000 14:20:19 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA09042; Thu, 21 Dec 2000 15:22:31 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 15:17:25 -0500 Message-ID: From: Igor Slepchin To: "'Billy Biggs'" Cc: Jonathan Rosenberg , Sean Olson , Steve Donovan , David Shrader , SIP List Subject: RE: [SIP] Record-Route and REGISTER MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 15:17:24 -0500 I never suggested that all proxies always Record-Route. What I said is that proxies should not necessarily base the decision about whether to record route based only on the request type. E.g., there is nothing illegal with inserting Record-Route into REGISTER or BYE. Otherwise, proxies won't be able to R-R on new request types like SUBSCRIBE. Of course, if a particular proxy _knows_ that it is only interested in specific types of requests, it is perfectly fine for it to insert the R-R in those messages only. --- Igor Slepchin > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Thursday, December 21, 2000 3:07 PM > To: Igor Slepchin > Cc: Jonathan Rosenberg; Sean Olson; Steve Donovan; David Shrader; SIP > List > Subject: Re: [SIP] Record-Route and REGISTER > > > Igor Slepchin (ISlepchin@dynamicsoft.com): > > > One thing I'd like to ensure is that proxies insert Record-Route in > > all requests, no matter what the request method is (CANCEL > and ACK are > > possible exceptions). It is then up to the endpoints to > decide whether > > there is any use for that Record-Route. > > > > If we do that this way, the proxies won't need to know about cryptic > > things like "Record-Route for INVITEs and SUBSCRIBEs but not for > > REGISTER". Makes defining new methods much easier. > > Please, don't Record-Route unless you need to. > > If all proxies Record-Route'ed, we get: > > 1) Huge messages > 2) Increased failure probability > 3) Increased delay > 4) Intelligence in the network > 5) ... > > A call-logger should only Record-Route for INVITE-initiated > call legs. > Of course, a firewall proxy should Record-Route everything, > but that is > a very special case. > > I've heard rumors that some proxies Record-Route > unconditionally (!!). > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 15:55:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00526 for ; Thu, 21 Dec 2000 15:55:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 74DFC44337; Thu, 21 Dec 2000 14:55:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id DE49F44336 for ; Thu, 21 Dec 2000 14:54:51 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 21 Dec 2000 14:55:04 -0600 (CST) From: Billy Biggs To: Igor Slepchin Cc: Jonathan Rosenberg , Sean Olson , Steve Donovan , David Shrader , SIP List Subject: Re: [SIP] Record-Route and REGISTER Message-ID: <20001221145503.A10794@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from ISlepchin@dynamicsoft.com on Thu, Dec 21, 2000 at 03:17:24PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 14:55:03 -0600 Igor Slepchin (ISlepchin@dynamicsoft.com): > I never suggested that all proxies always Record-Route. What I said is > that proxies should not necessarily base the decision about whether to > record route based only on the request type. I argue that the decision should be based on the request type and the proxy's requirements. Being conservative here is important to avoid all the problems of having packets route through a (disinterested) third party. Of course there is nothing illegal with adding the Record-Route to everything (firewall proxy). But this is the minority. Proxies should not Record-Route without good reason, and only for call-legs they are specifically interested in. Also, remember that Record-Route is a call leg property, not a request property, but whatever. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 18:32:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04558 for ; Thu, 21 Dec 2000 18:32:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6E91B44337; Thu, 21 Dec 2000 17:32:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 453D944336 for ; Thu, 21 Dec 2000 17:31:29 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA15255; Thu, 21 Dec 2000 15:31:24 -0800 (PST) Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with SMTP id AAF32417; Thu, 21 Dec 2000 15:31:16 -0800 (PST) Message-Id: <4.1.20001221091903.009acf00@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Billy Biggs , Robert Sparks From: Rohan Mahy Subject: Re: [SIP] Simple REFER Solution Cc: Jonathan Rosenberg , SIP List In-Reply-To: <20001219153239.A7929@div8.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 15:35:07 -0800 Hi, I must be missing something. If I send the REFER, how do I find out if it is successful? By the absence of a BYE? thanks, -rohan At 01:32 PM 12/19/00 , Billy Biggs wrote: > Keep REFER simple: Have no REFER-response method and no subscription. > > > We have found the following algorithm to be smallest, simplest, >easiest to understand, and least verbose. > > 1. The REFER is responded to immediately. > > 2. If the Referred Party wishes to resume the call later (usually if > the REFER-spawned call failed), then they send an INVITE with a > 'Refer-Response' header containing the response code from the > spawned INVITE. > > 3. If the Referred Party wishes to end the old call (the > REFER-spawned call succeeded), then they BYE the referrer. > > 4. To keep the number of messages down, REFER and its response may > contain SDP (such as hold SDP). > > Rationalle: > > Avoids queues in either device. A "first send NOTIFY then send BYE to >shut down the call" proposal has difficult error cases. Want to keep >recovery of the old session from a failed transfer as speedy as >possible. > > Comments appreciated. > >-- >Billy Biggs, 3Com Email: Billy_Biggs@3com.com >http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 18:33:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04643 for ; Thu, 21 Dec 2000 18:33:41 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1032B4437E; Thu, 21 Dec 2000 17:32:37 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 2529A44336 for ; Thu, 21 Dec 2000 17:31:33 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id PAA15290; Thu, 21 Dec 2000 15:31:28 -0800 (PST) Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with SMTP id AAF32419; Thu, 21 Dec 2000 15:31:18 -0800 (PST) Message-Id: <4.1.20001221130157.00c722f0@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: "Robert Sparks" , "Jonathan Rosenberg" From: Rohan Mahy Subject: RE: [SIP] Solving the REFER retransmit issue Cc: In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 15:31:15 -0800 At 10:57 AM 12/19/00 , Robert Sparks wrote: >> So, back to basics. The reason we built in this simple two way handshake >> into non-INVITE methods was the assumption that they would be responded to >> immediately, since an automata would answer, not a human. Lets keep with >> that. REFER should generate an immediate response. I like Rohan's idea of >> the NOTIFY (or something else) being sent later on when the request is >> answered. This is easier than needing to support an actual presence server >> in the UA, which would need to wait for SUBSCRIBE requests. >> >> -Jonathan R. > >I disagree with adding an implicit subscription with REFER. Assuming >we pull the events work together quickly (which I have no reason to >believe we won't), we have a solid primative in SUBSCRIBE that meets >the need. But it requires a) extra work on behalf of the referrer to send the SUBSCRIBE, b) extra work on behalf of the referred to maintain the subscription, and c) 4 extra unneeded messages (SUB, 200, and then the new immediate NOTIFY/200 that says there is no information yet). If folks don't like unsolicited NOTIFY / implicit SUBSCRIBE, then lets just use a new method (but please make it otherwise look like a NOTIFY). thanks, -rohan >If we pursued the implicit subscribe, I anticipate needing to add >parameters, starting with one to let the UA sending the REFER know >whether or not it should expect notifications. > >Further, what would be different between this and REFERPROGRESS/REFERDONE >(that would be the "(or something else)" that would get sent later, yes)? > >I'm leaning strongly towards REFER with a subsequent SUBSCRIBE if you >are interested in the results. Something like Require: referstatus could >be included in the REFER if the application knows it can't work without >status information. UAs that don't want to deal with receiving SUBSCRIBEs >can decline REFERs with that header. If the submitting UA wants to proceed >without status, it can resubmit the request without the Require:. > >A UA receiving a REFER without that header can still offer progress >information by providing something to subscribe to in the response >(A Subscribe-To: header in the response or the like). The originating >UA can then choose whether or not SUBSCRIBE. > >RjS > > > > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 18:46:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04820 for ; Thu, 21 Dec 2000 18:46:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 237DF4438F; Thu, 21 Dec 2000 17:46:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id 4EB1C4438E for ; Thu, 21 Dec 2000 17:45:58 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 21 Dec 2000 17:46:04 -0600 (CST) From: Billy Biggs To: Rohan Mahy Cc: Robert Sparks , Jonathan Rosenberg , SIP List Subject: Re: [SIP] Simple REFER Solution Message-ID: <20001221174604.A10958@div8.net> References: <20001219153239.A7929@div8.net> <4.1.20001221091903.009acf00@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20001221091903.009acf00@imop.cisco.com>; from rohan@cisco.com on Thu, Dec 21, 2000 at 03:35:07PM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 17:46:04 -0600 Rohan Mahy (rohan@cisco.com): > I must be missing something. If I send the REFER, how do I find out > if it is successful? By the absence of a BYE? If the far end still wants to talk to you, they will re-INVITE with a Refer-Response header containing the response code from the spawned INVITE. This can of course be "200 OK". If you see a BYE it may also mean it's successful, but at that point what do you care? If there is a legitimate requirement, it may justify a Refer-Response header in the BYE too. I really like this algorithm. Thoughts? >> Keep REFER simple: Have no REFER-response method and no >> subscription. >> >> We have found the following algorithm to be smallest, simplest, >> easiest to understand, and least verbose. >> >> 1. The REFER is responded to immediately. >> >> 2. If the Referred Party wishes to resume the call later (usually >> if the REFER-spawned call failed), then they send an INVITE with >> a 'Refer-Response' header containing the response code from the >> spawned INVITE. >> >> 3. If the Referred Party wishes to end the old call (the >> REFER-spawned call succeeded), then they BYE the referrer. >> >> 4. To keep the number of messages down, REFER and its response may >> contain SDP (such as hold SDP). >> >> Rationalle: >> >> Avoids queues in either device. A "first send NOTIFY then send BYE >> to shut down the call" proposal has difficult error cases. Want to >> keep recovery of the old session from a failed transfer as speedy as >> possible. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 18:47:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04835 for ; Thu, 21 Dec 2000 18:47:30 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3464F4439B; Thu, 21 Dec 2000 17:47:15 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 01BF84438E for ; Thu, 21 Dec 2000 17:46:23 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA21363; Thu, 21 Dec 2000 18:46:10 -0500 (EST) Message-ID: <3A429643.E64EA8E2@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Rohan Mahy Cc: Robert Sparks , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue References: <4.1.20001221130157.00c722f0@imop.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 18:46:11 -0500 Content-Transfer-Encoding: 7bit I agree. I'm not exactly sure why it is wrong to allow notifications without SUBSCRIBE. Much of the SUBSCRIBE machinery, such as the ability to do something useful when the UA is off-line, coupling to REGISTER, etc. are not applicable here. Authorization of the subscription isn't relevant since the subscription request has been made already. Thus, is there anything that breaks by allowing NOTIFYs without the explicit subscription? One minor objection is that simple end systems might want to REFER without being bothered by NOTIFYs. However, given the SUBSCRIBE overhead, I suspect that the overall message volume is still lower even if some systems end up ditching NOTIFYs unopened. The first 405 will presumably shut up the notifier. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 18:54:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA04998 for ; Thu, 21 Dec 2000 18:54:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B1480443A3; Thu, 21 Dec 2000 17:54:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id 2C064443A2 for ; Thu, 21 Dec 2000 17:53:45 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 21 Dec 2000 17:53:58 -0600 (CST) From: Billy Biggs To: Rohan Mahy Cc: Robert Sparks , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue Message-ID: <20001221175358.C10958@div8.net> References: <4.1.20001221130157.00c722f0@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20001221130157.00c722f0@imop.cisco.com>; from rohan@cisco.com on Thu, Dec 21, 2000 at 03:31:15PM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 17:53:58 -0600 Rohan Mahy (rohan@cisco.com): > > I disagree with adding an implicit subscription with REFER. Assuming > > we pull the events work together quickly (which I have no reason to > > believe we won't), we have a solid primative in SUBSCRIBE that meets > > the need. > > But it requires a) extra work on behalf of the referrer to send the > SUBSCRIBE, b) extra work on behalf of the referred to maintain the > subscription, and c) 4 extra unneeded messages (SUB, 200, and then the > new immediate NOTIFY/200 that says there is no information yet). > > If folks don't like unsolicited NOTIFY / implicit SUBSCRIBE, then lets > just use a new method (but please make it otherwise look like a > NOTIFY). Sending any other request is added work on behalf of the everybody, and more unneeded messages. In all cases, after the new call is accepted or rejected the referred party will send a re-INVITE to regain the session or a BYE to tear it down. The appropriate optimization is to place the REFER response as a header in the re-INVITE. If you haven't yet, please see my 'Simple REFER Solution' post. We have implemented this and it works cleanly. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 19:00:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05100 for ; Thu, 21 Dec 2000 19:00:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 853134436B; Thu, 21 Dec 2000 18:00:15 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id EA64244336 for ; Thu, 21 Dec 2000 17:59:36 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA21971; Thu, 21 Dec 2000 18:59:17 -0500 (EST) Message-ID: <3A429956.121A952B@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.75 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: Rohan Mahy , Robert Sparks , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue References: <4.1.20001221130157.00c722f0@imop.cisco.com> <20001221175358.C10958@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 18:59:18 -0500 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > Sending any other request is added work on behalf of the everybody, > and more unneeded messages. > > In all cases, after the new call is accepted or rejected the referred > party will send a re-INVITE to regain the session or a BYE to tear it > down. The appropriate optimization is to place the REFER response as a > header in the re-INVITE. > > If you haven't yet, please see my 'Simple REFER Solution' post. We > have implemented this and it works cleanly. > I think part of the problem might be that some of us differ in what we would like to use REFER for. If only for transferring calls, a simple mechanism of "call back if it didn't work out" (which I interpret Billy's method to be) seems to work. It is not clear that this is workable if REFER is treated as a means of executing a generic request somewhere else, not limited to INVITE. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 19:16:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA05343 for ; Thu, 21 Dec 2000 19:16:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 06FB14439A; Thu, 21 Dec 2000 18:16:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 02CD044395 for ; Thu, 21 Dec 2000 18:15:30 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 21 Dec 2000 16:15:13 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Billy Biggs'" , Rohan Mahy Cc: Robert Sparks , Jonathan Rosenberg , SIP List Subject: RE: [SIP] Simple REFER Solution MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 16:15:11 -0800 > > > I must be missing something. If I send the REFER, how do I find out > > if it is successful? By the absence of a BYE? > > If the far end still wants to talk to you, they will > re-INVITE with a > Refer-Response header containing the response code from the spawned > INVITE. This can of course be "200 OK". > > If you see a BYE it may also mean it's successful, but at that point > what do you care? If there is a legitimate requirement, it > may justify > a Refer-Response header in the BYE too. > > > I really like this algorithm. Thoughts? > Hi Billy, What happens when there is not an active SIP (INVITE) session between the referer and referee ? Sending an INVITE in this case may have unwanted effects (like initiating a call). Are you proposing that either a) you would only send the INVITE/BYE if a corresponding SIP (INVITE) sessions exists or b) that REFERS are not allowed outside of a SIP session? Cheers, Robert. > >> Keep REFER simple: Have no REFER-response method and no > >> subscription. > >> > >> We have found the following algorithm to be smallest, simplest, > >> easiest to understand, and least verbose. > >> > >> 1. The REFER is responded to immediately. > >> > >> 2. If the Referred Party wishes to resume the call later (usually > >> if the REFER-spawned call failed), then they send an > INVITE with > >> a 'Refer-Response' header containing the response > code from the > >> spawned INVITE. > >> > >> 3. If the Referred Party wishes to end the old call (the > >> REFER-spawned call succeeded), then they BYE the referrer. > >> > >> 4. To keep the number of messages down, REFER and its > response may > >> contain SDP (such as hold SDP). > >> > >> Rationalle: > >> > >> Avoids queues in either device. A "first send NOTIFY > then send BYE > >> to shut down the call" proposal has difficult error cases. Want to > >> keep recovery of the old session from a failed transfer as > speedy as > >> possible. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 20:23:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA06454 for ; Thu, 21 Dec 2000 20:23:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9788944352; Thu, 21 Dec 2000 19:23:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by lists.bell-labs.com (Postfix) with ESMTP id 28DEB44336 for ; Thu, 21 Dec 2000 19:22:59 -0500 (EST) Received: from imop.cisco.com (imop.cisco.com [171.69.11.44]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id RAA16710; Thu, 21 Dec 2000 17:22:58 -0800 (PST) Received: from sony-laptop (rmahy-dsl4.cisco.com [10.19.53.125]) by imop.cisco.com (Mirapoint) with SMTP id AAF33572; Thu, 21 Dec 2000 17:22:41 -0800 (PST) Message-Id: <4.1.20001221164225.009b7f00@imop.cisco.com> X-Sender: rmahy@imop.cisco.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 To: Billy Biggs From: Rohan Mahy Subject: Re: [SIP] Simple REFER Solution Cc: Robert Sparks , Jonathan Rosenberg , SIP List In-Reply-To: <20001221174604.A10958@div8.net> References: <4.1.20001221091903.009acf00@imop.cisco.com> <20001219153239.A7929@div8.net> <4.1.20001221091903.009acf00@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 17:26:31 -0800 At 03:46 PM 12/21/00 , Billy Biggs wrote: >Rohan Mahy (rohan@cisco.com): > >> I must be missing something. If I send the REFER, how do I find out >> if it is successful? By the absence of a BYE? > > If the far end still wants to talk to you, they will re-INVITE with a >Refer-Response header containing the response code from the spawned >INVITE. This can of course be "200 OK". > > If you see a BYE it may also mean it's successful, but at that point >what do you care? If there is a legitimate requirement, it may justify >a Refer-Response header in the BYE too. > > > I really like this algorithm. Thoughts? OK, So this all hangs together nicely if you use REFER just for transfers, INVITEs with the Members header for full-mesh conferences, PHONECTL for controlling other UAs.... There is still an issue with music on hold (see [6]) >1) Retransmission problem: solved >2) Cancellation: >If REFER returns a final response before a long INVITE transaction >completes, how do you cancel that INVITE? this would only happen in unusual cases (blind transfer to conference bridge that just crashed) if we limit this to transfers, but we still need some solution here. >3) Call-leg matching: >(b) use a Replaces header >4) If we choose Replaces or the like, how do we express that we want to >*join* 2 legs via REFER? some header >5) If Refer-To contains parameters (method, transport), or potentially >contradictory headers, what do we do with them? >(c) send an error mesage >(d) ignore the headers/parameters >(e) ignore the whole message > >6) If we don't allow ;method=BYE, how do we solve the problem described in >the Music on Hold flow? is this what you had in mind here? INVITE (call-id: foo) c=0.0.0.0 -> REFER Refer-to: Music?Join=foo -> INVITE Music (call-id: bar) -> INVITE (call-id: foo) Replaces: bar or Replace: Music ** BYE Music >7) How do we ask devices to do stuff for us? >(b) PHONECTL thanks, -rohan >>> Keep REFER simple: Have no REFER-response method and no >>> subscription. >>> >>> We have found the following algorithm to be smallest, simplest, >>> easiest to understand, and least verbose. >>> >>> 1. The REFER is responded to immediately. >>> >>> 2. If the Referred Party wishes to resume the call later (usually >>> if the REFER-spawned call failed), then they send an INVITE with >>> a 'Refer-Response' header containing the response code from the >>> spawned INVITE. >>> >>> 3. If the Referred Party wishes to end the old call (the >>> REFER-spawned call succeeded), then they BYE the referrer. >>> >>> 4. To keep the number of messages down, REFER and its response may >>> contain SDP (such as hold SDP). >>> >>> Rationalle: >>> >>> Avoids queues in either device. A "first send NOTIFY then send BYE >>> to shut down the call" proposal has difficult error cases. Want to >>> keep recovery of the old session from a failed transfer as speedy as >>> possible. > >-- >Billy Biggs, 3Com Email: Billy_Biggs@3com.com >http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 21:15:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07389 for ; Thu, 21 Dec 2000 21:15:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C1C9F44352; Thu, 21 Dec 2000 20:15:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id CA15844336 for ; Thu, 21 Dec 2000 20:14:50 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 21 Dec 2000 20:15:04 -0600 (CST) From: Billy Biggs To: "Henning G. Schulzrinne" Cc: Rohan Mahy , Robert Sparks , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue Message-ID: <20001221201504.A11101@div8.net> References: <4.1.20001221130157.00c722f0@imop.cisco.com> <20001221175358.C10958@div8.net> <3A429956.121A952B@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A429956.121A952B@cs.columbia.edu>; from hgs@cs.columbia.edu on Thu, Dec 21, 2000 at 06:59:18PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 20:15:04 -0600 Henning G. Schulzrinne (hgs@cs.columbia.edu): > I think part of the problem might be that some of us differ in what we > would like to use REFER for. If only for transferring calls, a simple > mechanism of "call back if it didn't work out" (which I interpret > Billy's method to be) seems to work. Close. My method is re-INVITE if it didn't work out. The session remains until one of the two parties sends a BYE. > It is not clear that this is workable if REFER is treated as a means > of executing a generic request somewhere else, not limited to INVITE. And obfuscate this request in a URI? Is this a specific feature or just for protocol cleanness? Executing a generic request may have dangerous security implications. Regardless, you only need to know the "response" for INVITE requests (for added security, simply 'success' or 'failure'). I like having no implicit response method for the REFER. If the referred party still wants to talk to you, they can re-INVITE. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 21:23:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07503 for ; Thu, 21 Dec 2000 21:23:17 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 84AE344373; Thu, 21 Dec 2000 20:23:25 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id 3725E44352 for ; Thu, 21 Dec 2000 20:22:55 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 21 Dec 2000 20:23:04 -0600 (CST) From: Billy Biggs To: "Fairlie-Cuninghame, Robert" Cc: Rohan Mahy , Robert Sparks , Jonathan Rosenberg , SIP List Subject: Re: [SIP] Simple REFER Solution Message-ID: <20001221202304.B11101@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rfairlie@nuera.com on Thu, Dec 21, 2000 at 04:15:11PM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 20:23:04 -0600 Fairlie-Cuninghame, Robert (rfairlie@nuera.com): > What happens when there is not an active SIP (INVITE) session between > the referer and referee ? Sending an INVITE in this case may have > unwanted effects (like initiating a call). Are you proposing that > either a) you would only send the INVITE/BYE if a corresponding SIP > (INVITE) sessions exists or b) that REFERS are not allowed outside of > a SIP session? What does a REFER outside of a session mean? 1) All user agents at the destination to immediately act upon the request. - evil denial of service - doesn't make sense in many cases (no user may be present, might be a gateway, ...) 2) All user agents to prompt the user (if applicable) to act upon the request (DoS) - Is there an expiry time? - If one UA acts upon it, you can't coordinate the others not to - ?? 3) ?? Most of this seems like pure device control, which is definitely outside of the scope. I think REFER outside of a session should be disallowed. It has a distinct meaning from an in-call REFER. If you want to ask someone to join a session, sounds like an INVITE. If you want something else, then you should probably draft a new method. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 21 21:29:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA07557 for ; Thu, 21 Dec 2000 21:29:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 25A1F44387; Thu, 21 Dec 2000 20:29:15 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id 68E8844384 for ; Thu, 21 Dec 2000 20:28:59 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Thu, 21 Dec 2000 20:29:13 -0600 (CST) From: Billy Biggs To: Rohan Mahy Cc: Robert Sparks , Jonathan Rosenberg , SIP List Subject: Re: [SIP] Simple REFER Solution Message-ID: <20001221202913.C11101@div8.net> References: <4.1.20001221091903.009acf00@imop.cisco.com> <20001219153239.A7929@div8.net> <4.1.20001221091903.009acf00@imop.cisco.com> <20001221174604.A10958@div8.net> <4.1.20001221164225.009b7f00@imop.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <4.1.20001221164225.009b7f00@imop.cisco.com>; from rohan@cisco.com on Thu, Dec 21, 2000 at 05:26:31PM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 21 Dec 2000 20:29:13 -0600 Rohan Mahy (rohan@cisco.com): > > 2) Cancellation: > > If REFER returns a final response before a long INVITE transaction > > completes, how do you cancel that INVITE? > this would only happen in unusual cases (blind transfer to conference > bridge that just crashed) if we limit this to transfers, but we still > need some solution here. I'm ok with having some other request, from the referrer to the referred party, like REFERCANCEL. This I can happily 501 and nobody has a waiting message queue or ugly state or whatever. It's a bit of a security no-no to let a 3rd party stop you from making a call outside of some device control protocol. > There is still an issue with music on hold (see [6]) > > > 6) If we don't allow ;method=BYE, how do we solve the problem > > described in the Music on Hold flow? Is this really a problem? Why do you want to use this method for music on hold? > is this what you had in mind here? > > INVITE (call-id: foo) c=0.0.0.0 -> > REFER Refer-to: Music?Join=foo -> > INVITE Music (call-id: bar) -> > > INVITE (call-id: foo) Replaces: bar or Replace: Music > ** BYE Music That's pretty ugly. If you're trying to orchestrate a remote UA, that's a dangerous road to full device control. I want to keep that out of REFER, otherwise it is too complicated to implement and still protect yourself from the security nightmare. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 01:00:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12657 for ; Fri, 22 Dec 2000 01:00:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1F3E744337; Fri, 22 Dec 2000 00:00:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8150D44336 for ; Thu, 21 Dec 2000 23:59:50 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA12497; Fri, 22 Dec 2000 01:02:13 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Dec 2000 00:57:06 -0500 Message-ID: From: Jonathan Rosenberg To: "'Fairlie-Cuninghame, Robert'" , Robert Sparks , sip@lists.bell-labs.com Subject: RE: [SIP] 3pcc callflow question (Was:Changin local RTP port with out a good reason) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 00:57:05 -0500 > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Wednesday, December 20, 2000 1:00 AM > To: 'Robert Sparks'; sip@lists.bell-labs.com > Subject: RE: [SIP] 3pcc callflow question (Was:Changin local RTP port > with out a good reason) > > > > > > Doesn't matter. Notice that in the original diagram, A1 > > isn't used in the negotiation with B. If A automatically > > returns held sdp when it recieves held sdp, things don't > > break. > > > > Out of curiosity, does anyone have a UA deployed that won't > > accept an initial INVITE to held media? If so, it argues for > > using the delayed media approach you suggest. > > > Hi Robert, > > I imagine that some UA's may not be happy with an initial SDP > (held) with no > vocoders, eg > > v=0 > o=... > c=IN IP4 0.0.0.0 > m=audio 10000 RTP/AVP This is not what "held SDP" looks like. The above SDP is actually invalid. Quoting the BNF from rfc2327: media-field = "m=" media space port ["/" integer] space proto 1*(space fmt) CRLF Thus, you must include at least one codec: v=0 o=... c=IN IP4 0.0.0.0 m=audio 10000 RTP/AVP 0 > > [Otherwise the controller would have to know/guess the lowest > capabilities > of UA A - which is unacceptable.] It doesn't matter. This held SDP is updated anyway with a re-invite later on. The primary problem would only be if there were no codecs in the INVITE that were supported by the recipient. Listing the the most common ones (g.711, g.723.1, g.729) in the held SDP, as a result, should work fine, even if they are not actually supported by A. However, it is simplified if the initial INVITE has no SDP. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 01:03:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA12686 for ; Fri, 22 Dec 2000 01:03:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B745444353; Fri, 22 Dec 2000 00:03:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 36E7E44336 for ; Fri, 22 Dec 2000 00:02:32 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA12509; Fri, 22 Dec 2000 01:04:53 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Dec 2000 00:59:46 -0500 Message-ID: From: Jonathan Rosenberg To: "'William Marshall'" , sip@lists.bell-labs.com Subject: RE: [SIP] Inteligent Codec Selection MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 00:59:45 -0500 > -----Original Message----- > From: William Marshall [mailto:wtm@research.att.com] > Sent: Wednesday, December 20, 2000 11:26 AM > To: sip@lists.bell-labs.com > Subject: Re: [SIP] Inteligent Codec Selection > > > tsearle@valhalla.marko.net wrote: > > > > I would like to set up a SIP solution that would negotiate > to use G.711 > > if there is sufficient bandwith between the two endpoints > to do so, and would > > negotiate G.723.1 otherwise. > > > > Is there any way to do codec negotiation in such a manner? > > Unfortunately there are limits to what can be said in the language > of SDP. But within that, there are at least three possibilities. > > 1) send an INVITE with only G.711, with qos required. If it fails > with the 580-Precondition-Failure, try again with an INVITE with > only G.723.1, again with qos required. > > 2) send an INVITE with two media streams, G.711 with qos optional, > and a second media stream for G.723.1 with qos required. > After getting > the COMET, UAS can decide which media stream to use. The UAC finds > this out when the media stream starts, since it indicated its > willingness > to receive both simultaneously. Alternatively, we could require > SDP in the 200-OK (in addition to the 183) which would inform > the UAC, and > allow it to prepare for only one stream. > > 3) send an INVITE with two media streams, both with qos optional and > requesting a COMET from UAS. When UAC receives the COMET, it decides > which codec to use; the COMET it sends to UAS contains the > succss/failure > indication for each codec, which tells the UAS which to use. > > The convention in cases (2) and (3) is that the UAC/UAS would > not use a > codec for which the qos reservation failed, even if it > appears in an m= > line in the SDP. I think this is not a safe assumption to make. The usage of two media streams, offered as alternatives, is not what is defined by SDP. Multiple media streams in SDP are parallel streams, not alternatives. You would need something like Gonzalo's stream identifier draft. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 01:31:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16059 for ; Fri, 22 Dec 2000 01:31:08 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D7244433E; Fri, 22 Dec 2000 00:31:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 3217544336 for ; Fri, 22 Dec 2000 00:30:08 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA12559; Fri, 22 Dec 2000 01:32:21 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Dec 2000 01:27:14 -0500 Message-ID: From: Jonathan Rosenberg To: "'Billy Biggs'" , Jo Hornsby Cc: "Fairlie-Cuninghame, Robert" , Jonathan Rosenberg , Keith Robinson , SIP List Subject: RE: [SIP] Proxy Routing Logic MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 01:27:11 -0500 > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Wednesday, December 20, 2000 12:54 PM > To: Jo Hornsby > Cc: Fairlie-Cuninghame, Robert; Jonathan Rosenberg; Keith > Robinson; SIP > List > Subject: Re: [SIP] Proxy Routing Logic > > > Jo Hornsby (jhornsby@ubiquity.net): > > >>> [Of course there will be always be different routing behaviour > >>> depending on whether the request has a Route or not. [...] > >> > >> Right, but this decision should only occur after you've > decided if > >> the request is for you. It's very important that proxies > don't just > >> assume the request is meant for them if it happens to appear on one > >> of their listening sockets. [...] > > > > Maybe I'm not following properly, since I'm jumping in > mid-stream, as > > it were, but if I get a request, I'm going to do my best to > honour it. > > Maybe I won't know anything about the domain in the Request-URI, but > > I'll SRV and A, and hopefully everything will still be okay. > > By "honour it" you mean proxy it to the destination indicated by the > Request-URI (and maybe add a Record-Route), right? > > I just want to make sure proxies don't replace the > request-URI blindly > with the next Route unless the request is destined for them. I believe they should do this, in fact. Note that Jo and Robert are correct; consensus was that if a local outbound proxy wants to stay on the path, it should record-route. This results in the most flexibility (enables outbound proxies who want to see only the initial request). The more interesting issue is when a local outbound proxy record routes. As you pointed out, the RR inserted might look like: sip:jdrosen@dynamicsoft.com;maddr=outbound.proxy.com However, as we pointed out before, if that proxy received this exact URI *without* the next Route header, this would result in a loop. Billy indicated he didn't want different routing of the request URI dependent on the presence of Route. I agree completely, and have been arguing for this property in Route all along. A few solutions are possible: 1. If you send a request to a URI that contains an maddr, and you end up sending it to the address in that maddr, strip the maddr out before sending the request. 2. THe proxy should never had inserted this RR in the first place, since using it directly will cause a loop. Rather, something like Robert's suggestion would be used: sip:outbound.proxy.com;uri=jdrosen@dynamicsoft.com. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 01:36:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA16735 for ; Fri, 22 Dec 2000 01:36:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7EECC44372; Fri, 22 Dec 2000 00:36:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id A2E9444371 for ; Fri, 22 Dec 2000 00:35:59 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA12572; Fri, 22 Dec 2000 01:37:13 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Dec 2000 01:32:06 -0500 Message-ID: From: Jonathan Rosenberg To: "'Baniel Uri-CUB001'" , "'Anuraj Ennai'" , sip@lists.bell-labs.com Subject: RE: [SIP] Proxies modifying SDP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 01:32:05 -0500 Since there are no protocol police, we cannot stop people from these things. In fact, it is sometimes needed in the harsh realities of NATs and firewalls. When a network entity does this, however, it really ceases being a logical proxy, and rather looks like a B2BUA. Thats because it will now need to handle call state, deal with re-INVITEs and changing of the session media, session timers, Require headers, and so on. Rather than looking at this as a perverted proxy, viewing it as a B2BUA makes the requirements for its processing clear - the same as a UA. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > Sent: Wednesday, December 20, 2000 3:18 PM > To: 'Anuraj Ennai'; sip@lists.bell-labs.com > Subject: RE: [SIP] Proxies modifying SDP > > > Oh well... It all sounds rightful and good, but there may be > commercial systems, which will be needing this capability > though... Life could be ugly I know... > > -----Original Message----- > From: Anuraj Ennai [mailto:anuraj.ennai@wipro.com] > Sent: Wednesday, December 20, 2000 1:17 AM > To: sip@lists.bell-labs.com > Subject: Re: [SIP] Proxies modifying SDP > > > Hi all, > > I believe proxies should be discouraged from prying > into SDP contents(or any message body that does > not concern them) for scalability, security and > privacy reasons. > > The mechanism for capability negotiation etc. > should be implemented at UA, using methods > like OPTIONs and/or headers like supported/ > Unsupported or Re-INVITEs. It mandates passing > 1 or 2 messages more between the UAs, but in the > end scales up well. If the proxy needs SDP content > negotiation, it can spawn its own call agent which > works exactly like the UA. > > In the end, it is all about KISS!!! > > Thanks & regards > Anuraj Ennai > Wipro Technologies -India. > > Subject: > Re: [SIP] Proxies modifying SDP > Date: > Tue, 19 Dec 2000 10:56:04 -0600 > From: > David Frascone > To: > Steve Gardell > CC: > "'Baniel Uri-CUB001'" , > sip@lists.bell-labs.com > References: > 1 > > > > This might be a useless response, since I can't find the > example document that > I'm about to refer too . . but . . . In the documents I read > before San Diego, > I remember two pictures of a proxied senario. > > In the first, the SIP requests were proxied, but the RTP was > sent normally. > > In the second, the SIP requests were proxied, *and* the RTP > was proxied. In > this senario, didn't the SIP proxy have to modify the SDP to > get it to work? > > Please: I know someone else read this document, or saw the slides I'm > refering too . . . . Someone help refresh my poor tired memory :) > > -Dave > > On Tue, Dec 19, 2000 at 11:43:25AM -0500, Steve Gardell wrote: > > If memory serves, a "fully routed" H.323 gatekeepers routes > the media > > negotiation signalling, but does not route the actual RTP traffic. > > > > -----Original Message----- > > From: Baniel Uri-CUB001 [mailto:Uri.Baniel@motorola.com] > > Sent: Monday, December 18, 2000 8:05 PM > > To: 'Steve Donovan'; Baniel Uri-CUB001; 'Neil Deason'; > > jfmule@clarent.com; bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > Hmm... > > Probably I was not clear and hence the confusion. > > My intention was to be able to mimic the 'H323 gate keeper mode' > > functionality, i.e. to have the end points think they talk > to each other (in > > the media streaming phase) but actually the media goes via > a gate keeper. In > > our SIP world this should be just a MG (Media Gateway). > > The control may still go via a SIP proxy server, that is why I think > > changing SDP fields (specifically the IP address for > receiving media as well > > as the RTP ports) may easily achieve this goal > > > > Uri > > > > -----Original Message----- > > From: Steve Donovan [mailto:sdonovan@dynamicsoft.com] > > Sent: Sunday, December 17, 2000 9:12 PM > > To: Baniel Uri-CUB001; 'Neil Deason'; jfmule@clarent.com; > > bhoeneis@cc.hut.fi; sip@lists.bell-labs.com > > Subject: RE: [SIP] Proxies modifying SDP > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 01:44:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA17726 for ; Fri, 22 Dec 2000 01:44:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AD4A444366; Fri, 22 Dec 2000 00:44:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id 6728744338 for ; Fri, 22 Dec 2000 00:43:54 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 22 Dec 2000 00:44:12 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Jo Hornsby , "Fairlie-Cuninghame, Robert" , Keith Robinson , SIP List Subject: Re: [SIP] Proxy Routing Logic Message-ID: <20001222004412.A11304@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdrosen@dynamicsoft.com on Fri, Dec 22, 2000 at 01:27:11AM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 00:44:12 -0600 Jonathan Rosenberg (jdrosen@dynamicsoft.com): > > I just want to make sure proxies don't replace the request-URI > > blindly with the next Route unless the request is destined for > > them. > > I believe they should do this, in fact. Ouch! Why? Are you sure you meant that? If a request is received, and I'm not represented in the request-URI, and there is a Route, I definitely don't pop the next route! I have to get the request to its next destination first. > The more interesting issue is when a local outbound proxy record > routes. As you pointed out, the RR inserted might look like: > > sip:jdrosen@dynamicsoft.com;maddr=outbound.proxy.com > > However, as we pointed out before, if that proxy received this exact > URI *without* the next Route header, this would result in a loop. > Billy indicated he didn't want different routing of the request URI > dependent on the presence of Route. I agree completely, and have been > arguing for this property in Route all along. > > A few solutions are possible: > > 1. If you send a request to a URI that contains an maddr, and you end > up sending it to the address in that maddr, strip the maddr out > before sending the request. Bad idea. A transparent proxy can snarf the message and it will lose information unless it looks at the IP layer. > 2. THe proxy should never had inserted this RR in the first place, > since using it directly will cause a loop. Rather, something like > Robert's suggestion would be used: > sip:outbound.proxy.com;uri=jdrosen@dynamicsoft.com. This is a much better idea. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 03:30:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA26945 for ; Fri, 22 Dec 2000 03:30:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7A8B544351; Fri, 22 Dec 2000 02:30:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web9807.mail.yahoo.com (web9807.mail.yahoo.com [216.136.129.32]) by lists.bell-labs.com (Postfix) with SMTP id 8E9DC44338 for ; Fri, 22 Dec 2000 02:29:27 -0500 (EST) Message-ID: <20001222082917.90454.qmail@web9807.mail.yahoo.com> Received: from [192.245.102.12] by web9807.mail.yahoo.com; Fri, 22 Dec 2000 00:29:17 PST From: laks hmi To: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] (no subject) Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 00:29:17 -0800 (PST) In Contact, To and From headers, one of the option is SIP-URL| URI of address-spec ending with semicolon and token is conflicting with the semicolon and token in generic-param of the contact-params which is coming immediately after the SIP-URL and URI. i would like to know how to resolve this conflict. lakshmi __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 04:32:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27369 for ; Fri, 22 Dec 2000 04:32:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DD8944433E; Fri, 22 Dec 2000 03:32:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web9806.mail.yahoo.com (web9806.mail.yahoo.com [216.136.129.29]) by lists.bell-labs.com (Postfix) with SMTP id A473544338 for ; Fri, 22 Dec 2000 03:31:30 -0500 (EST) Message-ID: <20001222093120.81027.qmail@web9806.mail.yahoo.com> Received: from [192.245.102.12] by web9806.mail.yahoo.com; Fri, 22 Dec 2000 01:31:20 PST From: laks hmi To: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] conflict in syntax Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 01:31:20 -0800 (PST) In Contact, To and From headers, one of the option is SIP-URL| URI of address-spec ending with semicolon and token is conflicting with the semicolon and token in generic-param of the contact-params which is coming immediately after the SIP-URL and URI. i would like to know how to resolve this conflict. lakshmi __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 04:34:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27393 for ; Fri, 22 Dec 2000 04:34:40 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4F32944356; Fri, 22 Dec 2000 03:33:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web9805.mail.yahoo.com (web9805.mail.yahoo.com [216.136.129.215]) by lists.bell-labs.com (Postfix) with SMTP id C358244354 for ; Fri, 22 Dec 2000 03:32:19 -0500 (EST) Message-ID: <20001222093209.66097.qmail@web9805.mail.yahoo.com> Received: from [192.245.102.12] by web9805.mail.yahoo.com; Fri, 22 Dec 2000 01:32:09 PST From: laks hmi To: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [SIP] conflict in syntax Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 01:32:09 -0800 (PST) In Contact, To and From headers, one of the option is SIP-URL| URI of address-spec ending with semicolon and token is conflicting with the semicolon and token in generic-param of the contact-params which is coming immediately after the SIP-URL and URI. i would like to know how to resolve this conflict. lakshmi __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 04:40:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27448 for ; Fri, 22 Dec 2000 04:40:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 43AAE4437A; Fri, 22 Dec 2000 03:40:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 60FBA44379 for ; Fri, 22 Dec 2000 03:39:23 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZF96XN4F; Fri, 22 Dec 2000 10:35:33 +0100 From: "Hisham Khartabil" To: "laks hmi" , Subject: RE: [SIP] conflict in syntax Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20001222093120.81027.qmail@web9806.mail.yahoo.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 11:40:07 +0200 Content-Transfer-Encoding: 7bit Contact: ;param1=abc Anything inside "<" and ">" belongs to the URI. Anything after ">" belongsto the header Regards, Hisham > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of laks hmi > Sent: Friday, 22 December 2000 11:31 AM > To: SIP@lists.bell-labs.com > Subject: [SIP] conflict in syntax > > > In Contact, To and From headers, one of the option > is SIP-URL| URI of address-spec ending with semicolon > and token is conflicting with the semicolon and token > in generic-param of the contact-params which is coming > > immediately after the SIP-URL and URI. > i would like to know how to resolve this conflict. > > > lakshmi > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of Products. > http://shopping.yahoo.com/ > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 04:51:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27494 for ; Fri, 22 Dec 2000 04:51:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D7B984438A; Fri, 22 Dec 2000 03:51:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web9804.mail.yahoo.com (web9804.mail.yahoo.com [216.136.129.214]) by lists.bell-labs.com (Postfix) with SMTP id 76E1F44372 for ; Fri, 22 Dec 2000 03:50:18 -0500 (EST) Message-ID: <20001222095008.69056.qmail@web9804.mail.yahoo.com> Received: from [192.245.102.12] by web9804.mail.yahoo.com; Fri, 22 Dec 2000 01:50:08 PST From: laks hmi Subject: RE: [SIP] conflict in syntax To: Hisham Khartabil Cc: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 01:50:08 -0800 (PST) what Mr.Hisham has told is correct but as i told only in name-addr they have specified the "<" and ">". what abt the SIP-URL|URI in address-spec. lakshmi __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 04:56:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA27578 for ; Fri, 22 Dec 2000 04:56:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1468144395; Fri, 22 Dec 2000 03:56:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 7EB7C44394 for ; Fri, 22 Dec 2000 03:55:48 -0500 (EST) Received: from Hash (195.238.204.166 [195.238.204.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZF96XNXQ; Fri, 22 Dec 2000 10:51:54 +0100 From: "Hisham Khartabil" To: "laks hmi" Cc: Subject: RE: [SIP] conflict in syntax Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <20001222095008.69056.qmail@web9804.mail.yahoo.com> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 11:56:29 +0200 Content-Transfer-Encoding: 7bit name-addr = [display-name] "<" addr-spec ">" > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of laks hmi > Sent: Friday, 22 December 2000 11:50 AM > To: Hisham Khartabil > Cc: SIP@lists.bell-labs.com > Subject: RE: [SIP] conflict in syntax > > > what Mr.Hisham has told is correct but as i told only > in name-addr they have specified the "<" and ">". > what abt the SIP-URL|URI in address-spec. > > lakshmi > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of Products. > http://shopping.yahoo.com/ > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 05:08:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA27744 for ; Fri, 22 Dec 2000 05:08:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 915EE44352; Fri, 22 Dec 2000 04:08:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web9802.mail.yahoo.com (web9802.mail.yahoo.com [216.136.129.212]) by lists.bell-labs.com (Postfix) with SMTP id 5FD9144343 for ; Fri, 22 Dec 2000 04:07:47 -0500 (EST) Message-ID: <20001222100737.61187.qmail@web9802.mail.yahoo.com> Received: from [192.245.102.12] by web9802.mail.yahoo.com; Fri, 22 Dec 2000 02:07:37 PST From: laks hmi Subject: RE: [SIP] conflict in syntax To: Hisham Khartabil Cc: SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 02:07:37 -0800 (PST) The syntax is as foloows Contact = ( â€Contact†| â€mâ€)â€:†(â€*†| (1# (( name-addr | addr-spec ) *( â€;†contact-params )))) i am telling abt (1# (( name-addr | addr-spec ), where SIP-URL and URI is coming in address-spec and not in the name-adress. Regards lakshmi --- Hisham Khartabil wrote: > name-addr = [display-name] "<" addr-spec ">" > > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > laks hmi > > Sent: Friday, 22 December 2000 11:50 AM > > To: Hisham Khartabil > > Cc: SIP@lists.bell-labs.com > > Subject: RE: [SIP] conflict in syntax > > > > > > what Mr.Hisham has told is correct but as i told > only > > in name-addr they have specified the "<" and ">". > > what abt the SIP-URL|URI in address-spec. > > > > lakshmi > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Shopping - Thousands of Stores. Millions of > Products. > > http://shopping.yahoo.com/ > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 07:25:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA29057 for ; Fri, 22 Dec 2000 07:25:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EF1B144343; Fri, 22 Dec 2000 06:25:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from qnsgs000.nortel.com (qnsgs000.nortelnetworks.com [47.211.0.31]) by lists.bell-labs.com (Postfix) with ESMTP id 22D0344338 for ; Fri, 22 Dec 2000 06:24:11 -0500 (EST) Received: from zhard00e.europe.nortel.com by qnsgs000.nortel.com; Fri, 22 Dec 2000 11:37:02 +0000 Received: by zhard00e.europe.nortel.com with Internet Mail Service (5.5.2652.35) id ; Fri, 22 Dec 2000 11:36:06 -0000 Message-ID: From: "Mark Watson" To: SIP@lists.bell-labs.com Subject: FW: [SIP] I-D ACTION:draft-ietf-sip-privacy-00.txt MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C06C0B.5F750B00" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 11:36:06 -0000 This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_000_01C06C0B.5F750B00 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06C0B.5F750B00" ------_=_NextPart_001_01C06C0B.5F750B00 Content-Type: text/plain; charset="iso-8859-1" All, I notice this draft was discussed at the IETF and it was noted that not many comments had been received. Hopefully I can address that :-) I would like to propose some enhancements to the draft. As it stands it is deficient in a number of aspects. I would propose: 1) to provide full support for European regulatory requirements (which are doubtless duplicated in other markets) relating to Caller Identity 2) to include identity information relating to multiple types of party involved in the session 3) to include multiple types of identity information about each party 4) to make privacy handling more generic 5) to include location information If there are a significant number of people interested in discussing such enhancements, I would be happy to set up an off-line discussion group, or we can have discussions on the main list - I would look to the WG chairs for guidance on this. [[Unfortunately, I won't be able to answer comments on my comments until 15th Jan, as I will be on vacation]] More details are below: 1) Regulatory requirements European Data Protection regulations, and I suspect similar regulations in other markets, place strict controls on what can/cannot be done with users personal information (e.g. their identity) with/without their permission. This gives rise to a requirement to signal whether or not a user has given permission for their identity information to be disclosed to third parties. Further, though, there may be cases where the user's information cannot be divulged to a third party, but where the user has NOT explicitly asked for it to be witheld, for example where the users wishes cannot be ascertained. There is therefore a need for three classifications with regard to privacy: a) Information may be disclosed because the user has consented to this b) Information may not be disclosed because the user has requested non-disclosure c) Information may not be disclosed for reasons other than user request The third category is, of course, something of a 'catch-all' to cover all cases except the explicit user request case. An example of where this level of discrimination is required is the Anonymous Caller Rejection service which is required (by explicit European regulation) to reject those calls where the *caller has requested* that they remain anonymous. A distinction is required between cases where anonymity is due to explicit caller request and those where it is due to some other reason. 2)Types of Party There are many types of party that could be involved in a call/session. We should be capable of providing information about any/all of them. Support for the following types is suggested as a starting point i) Calling Party ii) Called Party (whose terminal is alerting) iii) Connected party (who answers the call) iv) Redirecting Party v) Redirected-to Party 3) Types of identity A party involved in a session may have several kinds of identity. Support should be provided for signalling any/all of them: i) Subscriber identity - who owns the network subscription under which the session is being established ii) User identity iii) Display/Alias identity - the identity that the party wishes to be known as iv) Contact identity - the identity to be used to contact the party (e.g. to establish a return call/session) v) Terminal identity In many partical scenarios one or all of these identities are in fact the same and the same as the User identity, and so all do not need to be signalled separately. In any given application scenario it should be specified what these identities refer to. 4) Handling of privacy requirements Privacy requirements are generaly driven by Data Protection legislation - this is certainly the case here in Europe and I expect in other markets. The requirement is generally that personal information of any party should not be disclosed to other parties without permission. Where permission has been witheld, the requirement can often be met simply by omitting the information in question from any signalling messages. However, sometimes this information is required by entities within Service Provider Networks and so must still be included in messages to these entities, but not in messages to users. The privacy requirement is therefore particular to each piece of Party Information and should be signalled as a parameter to each piece of information. It should be noted that hiding the calling users IP address used for the RTP stream is a service in itself, not just the non-disclosure of personal information. A simple Internet Telephony service cannot, by definition, operate without disclosing this address, so a user who requires this address to be kept secret is effectively electing not to use this simple service. A more advanced service which hides the IP address by routing the RTP stream via an anonymiser would be required, but to my mind this is a separate service in itself and need not be addresses with these privacy requirements. 5) Location Information A further type of Party information is the physical location of the Party. This is useful for calls to emergency service centers and for geographic routing services. Proposal -------- I suggest replacing Remote-Party-ID and Anonymity with a single header, which may be repeated, as follows: Party-id = "Party-ID" ":" party-type party-id-type [display-name] ["<" addr-spec ">"] *(";" pi-parameter ) party-type = "cg" | "cd" | "cn" | "rdir" | "rto" | token party-id-type = "sub" | "user" | "alias" | "contact" | "term" | token pi-parameter = pi-validity-parm | pi-privacy-parm | pi-other-parm pi-other-parm = token [ "=" ( token | quoted-string ) ] pi-validity-parm = "verified" | token pi-privacy-parm = "privacy" "=" ( "none" | "user" | "other" | token ) The values of party-type and party-id-type are as described above. The pi-validity-parm is included by an entity which has verified the user information to be correct, to the best of its ability. Receipt of this parameter means that the information can be trusted to the same level as the entity from which it was received it is trusted. The pi-privacy-parm indicates who has requested that the information be kept secret. If omitted, the default is 'none' - indicating that the information need not be kept secret. If the value is anything other than 'none' the information may not be disclosed. Examples -------- The identity of the calling user could be signalled as follows: Party-ID: cg user "Watson" ; verified The identify of the calling subscriber, which has been explicitly witheld by the caller would be Party-ID: cg sub "Watson" ; verified; privacy=user A call from an Agent at a Call Centre might include: Party-ID: cg user "A Agent" ; privacy=other Party-ID: cg sub "Window World" ; verified Party-ID: cg contact "Window World" Indicating that 'Window World' wish to be contacted by their 1-800 number, that the fact that the call did originate from Window World is vouched for by whomever sent the message (e.g. local proxy), and that the users identity must not be disclosed, for example because the Call Agents have no choice about whether to release their own identity or not. Regards, Mark Watson Nortel Networks mwatson@nortelnetworks.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: 13 November 2000 12:41 To: IETF-Announce Cc: sip@lists.bell-labs.com Subject: [SIP] I-D ACTION:draft-ietf-sip-privacy-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Working Group of the IETF. Title : SIP Extensions for Caller Identity and Privacy Author(s) : W. Marshall et al. Filename : draft-ietf-sip-privacy-00.txt Pages : 16 Date : 10-Nov-00 This document describes two extensions to the Session Initiation Protocol (SIP) [4]. The extensions allow callers and callees to maintain their privacy in an environment where one or more proxies serve as intermediaries which can provide the identity of the parties either directly or indirectly. The extensions allow the parties to be identified either by name or by type, the latter of which can be used to identify some group of callers and callees. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-sip-privacy-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-sip-privacy-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. ------_=_NextPart_001_01C06C0B.5F750B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable FW: [SIP] I-D ACTION:draft-ietf-sip-privacy-00.txt

All,

I notice this draft was discussed at the IETF and it = was noted that not many comments had been received. Hopefully I can = address that :-)

I would like to propose some enhancements to the = draft. As it stands it is deficient in a number of aspects. I would = propose:

1) to provide full support for European regulatory = requirements (which are doubtless duplicated in other markets) relating = to Caller Identity

2) to include identity information relating to = multiple types of party involved in the session
3) to include multiple types of identity information = about each party
4) to make privacy handling more generic
5) to include location information

If there are a significant number of people = interested in discussing such enhancements, I would be happy to set up = an off-line discussion group, or we can have discussions on the main = list - I would look to the WG chairs for guidance on this.

[[Unfortunately, I won't be able to answer comments = on my comments until 15th Jan, as I will be on vacation]]

More details are below:

1) Regulatory requirements

European Data Protection regulations, and I suspect = similar regulations in other markets, place strict controls on what = can/cannot be done with users personal information (e.g. their = identity) with/without their permission.

This gives rise to a requirement to signal whether or = not a user has given permission for their identity information to be = disclosed to third parties.

Further, though, there may be cases where the user's = information cannot be divulged to a third party, but where the user has = NOT explicitly asked for it to be witheld, for example where the users = wishes cannot be ascertained. There is therefore a need for three = classifications with regard to privacy:

a) Information may be disclosed because the user has = consented to this
b) Information may not be disclosed because the user = has requested non-disclosure
c) Information may not be disclosed for reasons = other than user request

The third category is, of course, something of a = 'catch-all' to cover all cases except the explicit user request = case.

An example of where this level of discrimination is = required is the Anonymous Caller Rejection service which is required = (by explicit European regulation) to reject those calls where the = *caller has requested* that they remain anonymous. A distinction is = required between cases where anonymity is due to explicit caller = request and those where it is due to some other reason.

2)Types of Party

There are many types of party that could be involved = in a call/session. We should be capable of providing information about = any/all of them. Support for the following types is suggested as a = starting point

i) Calling Party
ii) Called Party (whose terminal is alerting)
iii) Connected party (who answers the call)
iv) Redirecting Party
v) Redirected-to Party

3) Types of identity

A party involved in a session may have several kinds = of identity. Support should be provided for signalling any/all of = them:

i) Subscriber identity - who owns the network = subscription under which the session is being established
ii) User identity
iii) Display/Alias identity - the identity that the = party wishes to be known as
iv) Contact identity - the identity to be used to = contact the party (e.g. to establish a return call/session)
v) Terminal identity

In many partical scenarios one or all of these = identities are in fact the same and the same as the User identity, and = so all do not need to be signalled separately. In any given application = scenario it should be specified what these identities refer = to.

4) Handling of privacy requirements

Privacy requirements are generaly driven by Data = Protection legislation - this is certainly the case here in Europe and = I expect in other markets.

The requirement is generally that personal = information of any party should not be disclosed to other parties = without permission. Where permission has been witheld, the requirement = can often be met simply by omitting the information in question from = any signalling messages. However, sometimes this information is = required by entities within Service Provider Networks and so must still = be included in messages to these entities, but not in messages to = users.

The privacy requirement is therefore particular to = each piece of Party Information and should be signalled as a parameter = to each piece of information. It should be noted that hiding the = calling users IP address used for the RTP stream is a service in = itself, not just the non-disclosure of personal information.

A simple Internet Telephony service cannot, by = definition, operate without disclosing this address, so a user who = requires this address to be kept secret is effectively electing not to = use this simple service.

A more advanced service which hides the IP address by = routing the RTP stream via an anonymiser would be required, but to my = mind this is a separate service in itself and need not be addresses = with these privacy requirements.

5) Location Information

A further type of Party information is the physical = location of the Party. This is useful for calls to emergency service = centers and for geographic routing services.

Proposal
--------

I suggest replacing Remote-Party-ID and Anonymity = with a single header, which may be repeated, as follows:

Party-id =3D "Party-ID" ":" = party-type party-id-type [display-name]
        =          = ["<" addr-spec ">"] *(";" = pi-parameter )

party-type =3D "cg" | "cd" | = "cn" | "rdir" | "rto" | token
party-id-type =3D "sub" | "user" = | "alias" | "contact" | "term" | = token

pi-parameter =3D pi-validity-parm | pi-privacy-parm | = pi-other-parm
pi-other-parm =3D token [ "=3D" ( token | = quoted-string ) ]

pi-validity-parm =3D "verified" | = token
pi-privacy-parm =3D "privacy" = "=3D" ( "none" | "user" | = "other" | token )

The values of party-type and party-id-type are as = described above.

The pi-validity-parm is included by an entity which = has verified the user information to be correct, to the best of its = ability. Receipt of this parameter means that the information can be = trusted to the same level as the entity from which it was received it = is trusted.

The pi-privacy-parm indicates who has requested that = the information be kept secret. If omitted, the default is 'none' - = indicating that the information need not be kept secret. If the value = is anything other than 'none' the information may not be = disclosed.

Examples
--------

The identity of the calling user could be signalled = as follows:

Party-ID: cg user "Watson" = <sip:441628434456@bell.com>; verified

The identify of the calling subscriber, which has = been explicitly witheld by the caller would be

Party-ID: cg sub "Watson" = <sip:441628434456@bell.com>; verified; privacy=3Duser

A call from an Agent at a Call Centre might = include:

Party-ID: cg user "A Agent" = <sip:17645437654@windows.com>; privacy=3Dother
Party-ID: cg sub "Window World" = <sip:16544322000@windows.com>; verified
Party-ID: cg contact "Window World" = <sip:18002223333@windows.com>

Indicating that 'Window World' wish to be contacted = by their 1-800 number, that the fact that the call did originate from = Window World is vouched for by whomever sent the message (e.g. local = proxy), and that the users identity must not be disclosed, for example = because the Call Agents have no choice about whether to release their = own identity or not.

Regards,

Mark Watson
Nortel Networks
mwatson@nortelnetworks.com

-----Original Message-----
From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org= ]
Sent: 13 November 2000 12:41
To: IETF-Announce
Cc: sip@lists.bell-labs.com
Subject: [SIP] I-D = ACTION:draft-ietf-sip-privacy-00.txt


A New Internet-Draft is available from the on-line = Internet-Drafts directories.
This draft is a work item of the Session Initiation = Protocol Working Group of the IETF.

        Title           : = SIP Extensions for Caller Identity and Privacy
        Author(s)       : W. Marshall et = al.
        Filename        : = draft-ietf-sip-privacy-00.txt
        Pages           : = 16
        Date    =         : 10-Nov-00
       =20
This document describes two extensions to the = Session Initiation
Protocol (SIP) [4]. The extensions allow callers and = callees to
maintain their privacy in an environment where one = or more proxies
serve as intermediaries which can provide the = identity of the
parties either directly or indirectly. The = extensions allow the
parties to be identified either by name or by type, = the latter of
which can be used to identify some group of callers = and callees.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-pri= vacy-00.txt

Internet-Drafts are also available by anonymous FTP. = Login with the username
"anonymous" and a password of your e-mail = address. After logging in,
type "cd internet-drafts" and then
        "get = draft-ietf-sip-privacy-00.txt".

A list of Internet-Drafts directories can be found = in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt


Internet-Drafts can also be obtained by = e-mail.

Send a message to:
        mailserv@ietf.org.
In the body type:
        "FILE = /internet-drafts/draft-ietf-sip-privacy-00.txt".
       =20
NOTE:   The mail server at ietf.org can = return the document in
        MIME-encoded form by using the "mpack" = utility.  To use this
        feature, = insert the command "ENCODING mime" before the = "FILE"
        command.  To decode the response(s), you will need = "munpack" or
        a = MIME-compliant mail reader.  Different MIME-compliant mail = readers
        exhibit = different behavior, especially when dealing with
        "multipart" MIME messages (i.e. documents which have = been split
        up into = multiple messages), so check your local documentation on
        how to = manipulate these messages.
        =        =20
        =        =20
Below is the data which will enable a MIME compliant = mail reader
implementation to automatically retrieve the ASCII = version of the
Internet-Draft.

  ------_=_NextPart_001_01C06C0B.5F750B00-- ------_=_NextPart_000_01C06C0B.5F750B00 Content-Type: message/rfc822 To: Subject: Date: Fri, 22 Dec 2000 11:36:07 -0000 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C06C0B.5F750B00" ------_=_NextPart_002_01C06C0B.5F750B00 Content-Type: multipart/alternative; boundary="----_=_NextPart_003_01C06C0B.5F750B00" ------_=_NextPart_003_01C06C0B.5F750B00 Content-Type: text/plain ------_=_NextPart_003_01C06C0B.5F750B00 Content-Type: text/html

  ------_=_NextPart_003_01C06C0B.5F750B00-- ------_=_NextPart_002_01C06C0B.5F750B00 Content-Type: application/octet-stream; name="ATT83681" Content-Disposition: attachment; filename="ATT83681" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001110140255.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-sip-privacy-00.txt ------_=_NextPart_002_01C06C0B.5F750B00 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-sip-privacy-00.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C06C0B.5F750B00-- ------_=_NextPart_000_01C06C0B.5F750B00-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 10:44:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05833 for ; Fri, 22 Dec 2000 10:44:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9F3F344337; Fri, 22 Dec 2000 09:44:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id E910344336 for ; Fri, 22 Dec 2000 09:43:06 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eBMFgpK18702; Fri, 22 Dec 2000 09:42:52 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id eBMFgpd28199; Fri, 22 Dec 2000 09:42:51 -0600 (CST) Received: from ericsson.com (pc050188.exu.ericsson.se [138.85.50.188]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id JAA05461; Fri, 22 Dec 2000 09:42:50 -0600 (CST) Message-ID: <3A437690.AA2F017D@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue References: <4.1.20001221130157.00c722f0@imop.cisco.com> <20001221175358.C10958@div8.net> <3A429956.121A952B@cs.columbia.edu> <20001221201504.A11101@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 09:43:12 -0600 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > Henning G. Schulzrinne (hgs@cs.columbia.edu): > > It is not clear that this is workable if REFER is treated as a means > > of executing a generic request somewhere else, not limited to INVITE. > > And obfuscate this request in a URI? > > Is this a specific feature or just for protocol cleanness? Executing > a generic request may have dangerous security implications. > This is no more insecure than a REFER with INVITE as the method. I actually like the idea of being able to REFER a SUBSCRIBE or even a REGISTER. I realize the implications of this but I don't think it's much different than receiving a REFER with an INVITE for which you might be billed. /sean > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 11:00:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06116 for ; Fri, 22 Dec 2000 11:00:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6083344337; Fri, 22 Dec 2000 10:00:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.speedventures.com (unknown [212.75.74.99]) by lists.bell-labs.com (Postfix) with ESMTP id 500F244336 for ; Fri, 22 Dec 2000 09:59:32 -0500 (EST) Received: from hotsip2 (213.89.52.166 [213.89.52.166]) by mail.speedventures.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id ZF96X30C; Fri, 22 Dec 2000 16:55:27 +0100 Message-ID: <000f01c06c31$1a0b0120$0564a8c0@sipbakeoff.org> From: "Christian Jansson" To: , "laks hmi" References: <20001222100737.61187.qmail@web9802.mail.yahoo.com> Subject: Re: [SIP] conflict in syntax 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 5.00.2615.200 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 17:06:03 +0100 Content-Transfer-Encoding: 7bit Just a few lines below the Contact syntax there is a sentence that I think will solve your problem: "Even if the "display-name"is empty, the "name-addr" form MUST be used if the "addr-spec" contains a comma, semicolon or question mark." --- Christian Jansson >The syntax is as foloows >Contact = ( "Contact" | "m")":" ("*" >| (1# (( name-addr | addr-spec ) *( ";" >contact-params )))) >i am telling abt (1# (( name-addr | addr-spec ), where >SIP-URL and URI is coming in address-spec and not in >the name-adress. >Regards >lakshmi --- Hisham Khartabil wrote: > name-addr = [display-name] "<" addr-spec ">" > > > > -----Original Message----- > > From: sip-admin@lists.bell-labs.com > > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of > laks hmi > > Sent: Friday, 22 December 2000 11:50 AM > > To: Hisham Khartabil > > Cc: SIP@lists.bell-labs.com > > Subject: RE: [SIP] conflict in syntax > > > > > > what Mr.Hisham has told is correct but as i told > only > > in name-addr they have specified the "<" and ">". > > what abt the SIP-URL|URI in address-spec. > > > > lakshmi > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Shopping - Thousands of Stores. Millions of > Products. > > http://shopping.yahoo.com/ > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 11:30:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA06749 for ; Fri, 22 Dec 2000 11:30:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2A0C54434C; Fri, 22 Dec 2000 10:30:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id BC97144336 for ; Fri, 22 Dec 2000 10:29:58 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 22 Dec 2000 10:29:53 -0600 (CST) From: Billy Biggs To: Sean Olson Cc: "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue Message-ID: <20001222102953.B11838@div8.net> References: <4.1.20001221130157.00c722f0@imop.cisco.com> <20001221175358.C10958@div8.net> <3A429956.121A952B@cs.columbia.edu> <20001221201504.A11101@div8.net> <3A437690.AA2F017D@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A437690.AA2F017D@ericsson.com>; from sean.olson@ericsson.com on Fri, Dec 22, 2000 at 09:43:12AM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 10:29:53 -0600 Sean Olson (sean.olson@ericsson.com): > > > It is not clear that this is workable if REFER is treated as a > > > means of executing a generic request somewhere else, not limited > > > to INVITE. > > > > And obfuscate this request in a URI? > > > > Is this a specific feature or just for protocol cleanness? > > Executing a generic request may have dangerous security > > implications. > > This is no more insecure than a REFER with INVITE as the method. I > actually like the idea of being able to REFER a SUBSCRIBE or even a > REGISTER. I realize the implications of this but I don't think it's > much different than receiving a REFER with an INVITE for which you > might be billed. Do you need to know the response to the SUBSCRIBE/REGISTER? If so, can you live with it as a header in a re-INVITE? It will save alot of trouble, and optimizes the most common case. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 11:57:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07107 for ; Fri, 22 Dec 2000 11:57:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CA2A14434C; Fri, 22 Dec 2000 10:57:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 26F3044338 for ; Fri, 22 Dec 2000 10:56:21 -0500 (EST) Received: from mr5.exu.ericsson.se. (mr5u3.ericy.com [208.237.135.124]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eBMGu6K02055; Fri, 22 Dec 2000 10:56:07 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr5.exu.ericsson.se. (8.10.2/8.10.2) with ESMTP id eBMGr7M07704; Fri, 22 Dec 2000 10:53:07 -0600 (CST) Received: from ericsson.com (pc050188.exu.ericsson.se [138.85.50.188]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id KAA08776; Fri, 22 Dec 2000 10:56:06 -0600 (CST) Message-ID: <3A4387BB.9A4D36E5@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue References: <4.1.20001221130157.00c722f0@imop.cisco.com> <20001221175358.C10958@div8.net> <3A429956.121A952B@cs.columbia.edu> <20001221201504.A11101@div8.net> <3A437690.AA2F017D@ericsson.com> <20001222102953.B11838@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 10:56:27 -0600 Content-Transfer-Encoding: 7bit I have to confess that I prefer the notion of a REFER that is outside of any active (INVITE) session. Separating the REFER and INVITE seems the most natural to me. In this case, there would be no re-INVITE to carry this header (if I understand your suggestion correctly) What I would prefer to see is a NOTIFY sent for responses with the REFER acting as an implicit SUBSCRIBE and a new Refer-Notify: header in the REFER request which would indicate the desire to receive such notifications. Refer-Notify: (name-addr | addr-spec) If the Refer-Notify: header is present in the request, it indicates the desire to receive NOTIFYs for the responses. If the Refer-Notify: header is present in the response, it indicates that the receiver is willing to send NOTIFYs (of course only applicable to a 2xx response to the REFER) I think this will allow for the most common cases without incurring any great overhead or restricting the possibilities. /sean Billy Biggs wrote: > > Sean Olson (sean.olson@ericsson.com): > > > > > It is not clear that this is workable if REFER is treated as a > > > > means of executing a generic request somewhere else, not limited > > > > to INVITE. > > > > > > And obfuscate this request in a URI? > > > > > > Is this a specific feature or just for protocol cleanness? > > > Executing a generic request may have dangerous security > > > implications. > > > > This is no more insecure than a REFER with INVITE as the method. I > > actually like the idea of being able to REFER a SUBSCRIBE or even a > > REGISTER. I realize the implications of this but I don't think it's > > much different than receiving a REFER with an INVITE for which you > > might be billed. > > Do you need to know the response to the SUBSCRIBE/REGISTER? If so, > can you live with it as a header in a re-INVITE? It will save alot of > trouble, and optimizes the most common case. > > -- > Billy Biggs, 3Com Email: Billy_Biggs@3com.com > http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 14:56:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA12283 for ; Fri, 22 Dec 2000 14:56:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6805C44337; Fri, 22 Dec 2000 13:56:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id 0DF8C44336 for ; Fri, 22 Dec 2000 13:55:39 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 22 Dec 2000 13:54:40 -0600 (CST) From: Billy Biggs To: Sean Olson Cc: "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue Message-ID: <20001222135440.B11951@div8.net> References: <4.1.20001221130157.00c722f0@imop.cisco.com> <20001221175358.C10958@div8.net> <3A429956.121A952B@cs.columbia.edu> <20001221201504.A11101@div8.net> <3A437690.AA2F017D@ericsson.com> <20001222102953.B11838@div8.net> <3A4387BB.9A4D36E5@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A4387BB.9A4D36E5@ericsson.com>; from sean.olson@ericsson.com on Fri, Dec 22, 2000 at 10:56:27AM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 13:54:40 -0600 Sean Olson (sean.olson@ericsson.com): > I have to confess that I prefer the notion of a REFER that is outside > of any active (INVITE) session. Separating the REFER and INVITE seems > the most natural to me. In this case, there would be no re-INVITE to > carry this header (if I understand your suggestion correctly) In order to perform transfer, the REFER must be related to an active session. Otherwise you can't simulate PBX transfer where a single line is replaced with a new call to a seperate endpoint. I see REFER as a very point-to-point interaction, and therefore it doesn't make sense with forking. You want to REFER a single endpoint to a URI to avoid spamming the destination with multiple requests. This doesn't make sense to me outside of an active session. > What I would prefer to see is a NOTIFY sent for responses with the > REFER acting as an implicit SUBSCRIBE and a new Refer-Notify: header > in the REFER request which would indicate the desire to receive such > notifications. > > [...] > > I think this will allow for the most common cases without incurring > any great overhead or restricting the possibilities. Maybe if the NOTIFY and the REFER can both contain SDP, and that a BYE infers that no subsequent NOTIFY will be sent. Otherwise you have to keep alot of state in the endpoints, and post-transfer-failure recovery will take quite a while. -- Billy Biggs, 3Com Email: Billy_Biggs@3com.com http://www.div8.net/billy/ Phone: Billy_Biggs@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 15:11:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12771 for ; Fri, 22 Dec 2000 15:11:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 631734434C; Fri, 22 Dec 2000 14:11:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4F78B44337 for ; Fri, 22 Dec 2000 14:10:59 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA17479; Fri, 22 Dec 2000 15:12:39 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Dec 2000 15:07:31 -0500 Message-ID: From: Jonathan Rosenberg To: "'Billy Biggs'" , Igor Slepchin Cc: Jonathan Rosenberg , Sean Olson , Steve Donovan , David Shrader , SIP List Subject: RE: [SIP] Record-Route and REGISTER MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 15:07:30 -0500 > -----Original Message----- > From: Billy Biggs [mailto:Billy_Biggs@3com.com] > Sent: Thursday, December 21, 2000 3:55 PM > To: Igor Slepchin > Cc: Jonathan Rosenberg; Sean Olson; Steve Donovan; David Shrader; SIP > List > Subject: Re: [SIP] Record-Route and REGISTER > > > Igor Slepchin (ISlepchin@dynamicsoft.com): > > > I never suggested that all proxies always Record-Route. > What I said is > > that proxies should not necessarily base the decision about > whether to > > record route based only on the request type. > > I argue that the decision should be based on the request > type and the > proxy's requirements. Being conservative here is important > to avoid all > the problems of having packets route through a (disinterested) third > party. I think the overall statement is that, ultimately, record-routing is at the policy discretion of the server. This will depend on what it wants to do, the request method, etc. No disagreement there, I think. Sean said: > RR is well defined for all methods within a call leg. What is up for > consideration (I believe -- please correct me if I'm wrong) is whether > a RR in the REGISTER should also apply to the INVITE/CANCEL/ACK/BYE > and vice-versa. No, that is not the issue. THis changes the meaning of Route/Record-Route and that is not on the table. So what is the issue? Igor has made the statement that a proxy should be able to record-route for any request method. Indeed, that is the issue. UAs will need to be prepared to handle that. In order to do so, they must know how to do several things that, right now, are not very clear: 1. if some method foo gets record-routed, in which other request should that Route go? 2. when is it safe to destroy that route set? Currently, the answers to these for INVITEs are (1) all requests within the call leg, and (2) when the call leg is over, from BYE or timeout. With REGISTER, for example, what are the answers? Turns out that "call leg", using the more formal local ID/remote ID/Call-ID works well, resulting in routes being established for all refreshes from a single UA. The same is true for IM and SUBSCRIBE. The answer to the second question is more complex, and is very likely method dependent. So, the question is (1) do we want to even specify, in the base spec, record-route semantics for non-INVITE requests, and (2) if so, what are the answers to questions 1 and 2 above. I'm inclined to say no to the first, actually. This doesn't mean that its impossible to record-route for anything else, but rather that the answers to questions 1. and 2., which constitute the primary issue of standardization, are method specific in part. All that we need say in rfc2543 is that processing of Route headers in proxies is not method dependent. I suspect thats the case for most proxies today already. I haven't seen much value yet in Record-routing register. Its not useful for OPTIONS, and everything else is covered. MESSAGE and SUB/NOT will need it, but we can simply specify the meaning for these within those documents. As Mike said, lets try and keep things simple. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 15:33:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13837 for ; Fri, 22 Dec 2000 15:33:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9D01A4434C; Fri, 22 Dec 2000 14:33:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by lists.bell-labs.com (Postfix) with ESMTP id 4E97D44336 for ; Fri, 22 Dec 2000 14:32:37 -0500 (EST) Received: from mr4u3.ericy.com (mr4u3.ericy.com [208.237.135.127]) by imr1.ericy.com (8.10.2/8.10.2) with ESMTP id eBMKWOK18553; Fri, 22 Dec 2000 14:32:24 -0600 (CST) Received: from newman.exu.ericsson.se (newman.exu.ericsson.se [138.85.75.179]) by mr4u3.ericy.com (8.10.2/8.10.2) with ESMTP id eBMKWNR27333; Fri, 22 Dec 2000 14:32:23 -0600 (CST) Received: from ericsson.com (pc050188.exu.ericsson.se [138.85.50.188]) by newman.exu.ericsson.se (8.7.5/8.7.3) with ESMTP id OAA16978; Fri, 22 Dec 2000 14:32:23 -0600 (CST) Message-ID: <3A43BA6A.80723C13@ericsson.com> From: Sean Olson Organization: Ericsson Inc. X-Mailer: Mozilla 4.76 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue References: <4.1.20001221130157.00c722f0@imop.cisco.com> <20001221175358.C10958@div8.net> <3A429956.121A952B@cs.columbia.edu> <20001221201504.A11101@div8.net> <3A437690.AA2F017D@ericsson.com> <20001222102953.B11838@div8.net> <3A4387BB.9A4D36E5@ericsson.com> <20001222135440.B11951@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 14:32:42 -0600 Content-Transfer-Encoding: 7bit Billy Biggs wrote: > > Sean Olson (sean.olson@ericsson.com): > > > I have to confess that I prefer the notion of a REFER that is outside > > of any active (INVITE) session. Separating the REFER and INVITE seems > > the most natural to me. In this case, there would be no re-INVITE to > > carry this header (if I understand your suggestion correctly) > > In order to perform transfer, the REFER must be related to an active > session. Otherwise you can't simulate PBX transfer where a single line > is replaced with a new call to a seperate endpoint. This is of course a very important application of REFER and as you point out requires a way to relate the REFER to an ongoing session. What I am arguing for is simply an independence of the ongoing session and the REFER transaction. The failure or success of the REFER transaction should not imply a BYE. (This is in fact already a requirement in the transfer draft). I think I may have misinterpreted your previous comments. I also like the ability to use REFER for applications other than call transfer. This may be completely out of scope for the REFER mechanism. If this is the consensus of the mailing list, I would like to see it explicitly stated in the transfer draft (it would become a MUST that if the Refer-To: URL was a SIP URL that contained a method parameter other than "INVITE", the REFER would be rejected with a 4xx response). > > I see REFER as a very point-to-point interaction, and therefore it > doesn't make sense with forking. You want to REFER a single endpoint to > a URI to avoid spamming the destination with multiple requests. This > doesn't make sense to me outside of an active session. > I don't agree. But even if you want a point-to-point mode of interaction, you don't necessarily need an active session to accomplish this. There are many ways to determine the Contact: address of a specific UA including "out-of-band" mechanisms that don't require an active session. > > What I would prefer to see is a NOTIFY sent for responses with the > > REFER acting as an implicit SUBSCRIBE and a new Refer-Notify: header > > in the REFER request which would indicate the desire to receive such > > notifications. > > > > [...] > > > > I think this will allow for the most common cases without incurring > > any great overhead or restricting the possibilities. > > Maybe if the NOTIFY and the REFER can both contain SDP, and that a BYE > infers that no subsequent NOTIFY will be sent. Otherwise you have to > keep alot of state in the endpoints, and post-transfer-failure recovery > will take quite a while. > The type of information I envisioned being transferred in the NOTIFYs was zero or more provisional response codes and a single final response code. No SDP and no headers. Literally: NOTIFY SIP/2.0 From: (The To: of the REFER) To: (The From: of the REFER) Call-ID: (The Call-ID: of the REFER) CSeq: ... Event: refer-final-response;response="200 OK" Expires: 0 Content-Length: 0 /sean _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 16:23:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA14707 for ; Fri, 22 Dec 2000 16:23:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 27B0A44337; Fri, 22 Dec 2000 15:23:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1D03744336 for ; Fri, 22 Dec 2000 15:22:02 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA17976; Fri, 22 Dec 2000 16:23:42 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Dec 2000 16:18:34 -0500 Message-ID: From: Jonathan Rosenberg To: "'Sean Olson'" , Billy Biggs Cc: "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , Jonathan Rosenberg , sip@lists.bell-labs.com Subject: RE: [SIP] Solving the REFER retransmit issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 16:18:33 -0500 We have some basic design principals we can use to help us here: 1. design general purpose mechanisms, not services 2. be explicit, not implicit 3. keep things independent so that they can be combined in different ways Sometimes these are at odds with some of our design goals: 1. KISS 2. SIP is not a control protocol However, I do not think we want to have REFER mean ONLY transfer. I'd rather keep it generic with a fairly well defined scope, in particular, keeping it away from the control protocol space. I'd also rather be explicit, in which case REFER means refer, and nothing else; i.e., don't use a header in an INVITE, since INVITE is not a transfer/refer function. There is something in the sip guidelines document that says that headers should not alter the basic functional processing of a request. This was one of the problems with the original Also proposal. So, I still believe that the best solution is REFER that generates an automatic NOTIFY. I think the idea of including a header in the request which tells you whether to send the notify or not is acceptable. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Sean Olson [mailto:sean.olson@ericsson.com] > Sent: Friday, December 22, 2000 3:33 PM > To: Billy Biggs > Cc: Henning G. Schulzrinne; Rohan Mahy; Robert Sparks; Jonathan > Rosenberg; sip@lists.bell-labs.com > Subject: Re: [SIP] Solving the REFER retransmit issue > > > > Billy Biggs wrote: > > > > Sean Olson (sean.olson@ericsson.com): > > > > > I have to confess that I prefer the notion of a REFER > that is outside > > > of any active (INVITE) session. Separating the REFER and > INVITE seems > > > the most natural to me. In this case, there would be no > re-INVITE to > > > carry this header (if I understand your suggestion correctly) > > > > In order to perform transfer, the REFER must be related > to an active > > session. Otherwise you can't simulate PBX transfer where a > single line > > is replaced with a new call to a seperate endpoint. > > This is of course a very important application of REFER and as you > point out requires a way to relate the REFER to an ongoing session. > What I am arguing for is simply an independence of the ongoing session > and the REFER transaction. The failure or success of the REFER > transaction > should not imply a BYE. (This is in fact already a requirement in the > transfer draft). I think I may have misinterpreted your previous > comments. > > I also like the ability to use REFER for applications other than > call transfer. This may be completely out of scope for the REFER > mechanism. > If this is the consensus of the mailing list, I would like to see it > explicitly stated in the transfer draft (it would become a > MUST that if > the Refer-To: > URL was a SIP URL that contained a method parameter other > than "INVITE", > the REFER > would be rejected with a 4xx response). > > > > > I see REFER as a very point-to-point interaction, and therefore it > > doesn't make sense with forking. You want to REFER a > single endpoint to > > a URI to avoid spamming the destination with multiple > requests. This > > doesn't make sense to me outside of an active session. > > > > I don't agree. But even if you want a point-to-point mode of > interaction, > you don't necessarily need an active session to accomplish this. There > are many ways to determine the Contact: address of a specific UA > including > "out-of-band" mechanisms that don't require an active session. > > > > What I would prefer to see is a NOTIFY sent for responses with the > > > REFER acting as an implicit SUBSCRIBE and a new > Refer-Notify: header > > > in the REFER request which would indicate the desire to > receive such > > > notifications. > > > > > > [...] > > > > > > I think this will allow for the most common cases without > incurring > > > any great overhead or restricting the possibilities. > > > > Maybe if the NOTIFY and the REFER can both contain SDP, > and that a BYE > > infers that no subsequent NOTIFY will be sent. Otherwise > you have to > > keep alot of state in the endpoints, and > post-transfer-failure recovery > > will take quite a while. > > > > The type of information I envisioned being transferred in the NOTIFYs > was > zero or more provisional response codes and a single final response > code. > No SDP and no headers. Literally: > > NOTIFY SIP/2.0 > From: (The To: of the REFER) > To: (The From: of the REFER) > Call-ID: (The Call-ID: of the REFER) > CSeq: ... > Event: refer-final-response;response="200 OK" > Expires: 0 > Content-Length: 0 > > /sean > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 16:40:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA15048 for ; Fri, 22 Dec 2000 16:40:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2354044337; Fri, 22 Dec 2000 15:40:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from longmail.lboard.com (mail.lboard.com [204.17.219.203]) by lists.bell-labs.com (Postfix) with ESMTP id 1358E44336 for ; Fri, 22 Dec 2000 15:39:22 -0500 (EST) Received: by longmail.lboard.com with Internet Mail Service (5.5.2650.21) id ; Fri, 22 Dec 2000 13:45:10 -0800 Message-ID: From: Sekhar Banerjee To: SIP List MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Problem with REFER Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 13:45:08 -0800 Hi All, I am having a hard time trying to figure out how to make the Transferee send the Invite to the Transfer Target through the proxy when REFER is used to transfer the call. Could any of you guys shed some light on how this can be achieved. Transferee Transferor Proxy Transfer Target Invite -----------------------------------> <---------------------------------- 100 Trying <--------------- Invite 200 ----------------> <---------------------------------- 200 Ack -----------------------------------> <---------------- Ack Invite(c=0)-------------> <----------------------------------- Invite(c=0) 200 Ok ------------------------------------> <---------------- 200 Ok Ack ----------------> <----------------------------------- Ack Invite(TT)--------------> Invite ----------------------> <--------------------- 200 <----------------- 200 Ack -----------------> Ack -----------------------> Bye ------------------> Bye -----------------------> Refer ------------------> <------------------------------------ Refer <---------------------- 200 Ok <------------------ 200 OK Invite ----------------------------------------------------------------------> <-------------------------------------------------------------------- 200 Ok Ack ----------------------------------------------------------------------> Bye ----------------------------------------------------------------------> <--------------------------------------------------------------------- 200 OK I would like to see the last Invite and Bye go through the proxy too so that the proxy can control that call. Would a Record-Route in the Refer help me achieve this goal ? I cant seem to find anything in the spec to figure this one out. I would appreciate any help on this one. Thanks Sekhar _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 22 17:13:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA15396 for ; Fri, 22 Dec 2000 17:13:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A438344378; Fri, 22 Dec 2000 16:13:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id 703B744336 for ; Fri, 22 Dec 2000 16:12:56 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 22 Dec 2000 16:13:18 -0600 (CST) Resent-Message-Id: From: Billy Biggs To: Jonathan Rosenberg Cc: Sean Olson , "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue Message-ID: <20001222160313.A12149@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdrosen@dynamicsoft.com on Fri, Dec 22, 2000 at 04:18:33PM -0500 Resent-From: vektor@div8.net Resent-Date: Fri, 22 Dec 2000 16:13:18 -0600 Resent-To: sip@lists.bell-labs.com Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 16:03:13 -0600 Resent-Sender: sip-admin@lists.bell-labs.com Jonathan Rosenberg (jdrosen@dynamicsoft.com): > case REFER means refer, and nothing else; i.e., don't use a header in > an INVITE, since INVITE is not a transfer/refer function. There is > something in the sip guidelines document that says that headers should > not alter the basic functional processing of a request. This was one > of the problems with the original Also proposal. In our proposal, the INVITE semantics are preserved. The referred user wishes to renegotiate the old session, and wishes the phone at the far end to ring. The header does not alter the functional processing, but rather indicates that this re-INVITE is because a response arrived to the spawned call. This is both simple and explicit. > So, I still believe that the best solution is REFER that generates an > automatic NOTIFY. I think the idea of including a header in the > request which tells you whether to send the notify or not is > acceptable. This might be alright, but how about: 1) No NOTIFY is sent if the referred party shuts down the call leg with a BYE. 2) The NOTIFY and REFER may contain SDP. I want, for a failed transfer scenario: Referrer Referred Party ---- REFER (hold SDP) --> <--- OK (hold SDP) ------ (after failed INVITE) <- NOTIFY (active SDP) -- -- OK (active SDP) -----> Message Count: 4 I want to avoid this: Referrer Referred Party --- INVITE/OK/ACK (hold) --> ------ REFER --------------> <----- OK ------------------ (after failed INVITE) <-- NOTIFY ----------------- --- OK --------------------> <-- INVITE/OK/ACK (active) - Message Count: 10 Each device has to maintain state for where it is in the sequence, and recovering the old session from a failed transfer now takes alot more time (the NOTIFY and then the INVITE). -- Billy Biggs bbiggs@div8.net http://www.div8.net/billy/ wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Mon Dec 25 23:29:05 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA03814 for ; Mon, 25 Dec 2000 23:29:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 88E5D44337; Mon, 25 Dec 2000 22:29:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web9805.mail.yahoo.com (web9805.mail.yahoo.com [216.136.129.215]) by lists.bell-labs.com (Postfix) with SMTP id 9C5CC44336 for ; Mon, 25 Dec 2000 22:28:17 -0500 (EST) Message-ID: <20001226042807.17215.qmail@web9805.mail.yahoo.com> Received: from [192.245.102.12] by web9805.mail.yahoo.com; Mon, 25 Dec 2000 20:28:07 PST From: laks hmi Subject: [SIP] conflict in syntax To: Christian Jansson , SIP@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Mon, 25 Dec 2000 20:28:07 -0800 (PST) >i have clearly mentioned in first mail where exactly the conflict is coming, once again i am explaining below. > Contact = ( "Contact" | "m")":" ("*" > | (1# (( name-addr | addr-spec ) *( ";" > contact-params )))) In the above syntax, (1# (( name-addr | addr-spec ) is there in the beginning of the header after colon. SIP_URL | URI is coming in addr-spec is the first parameter can end with semicolon and token which is there in the generic-param of the other-params is conflicting with immediate *(";" contact-params ) where again semicolon and token will come. In this both other-param in URL and *( ";" contact-params ) can come zero or multiple times, so we will not be knowing which parameter. Regards lakshmi --- Christian Jansson wrote: > Just a few lines below the Contact syntax there is a > sentence that > I think will solve your problem: > > "Even if the "display-name"is empty, the "name-addr" > form MUST be > used if the "addr-spec" contains a comma, semicolon > or question mark." > > --- > Christian Jansson > > >The syntax is as foloows > >Contact = ( "Contact" | "m")":" ("*" > >| (1# (( name-addr | addr-spec ) *( ";" > >contact-params )))) > > >i am telling abt (1# (( name-addr | addr-spec ), > where > >SIP-URL and URI is coming in address-spec and not > in > >the name-adress. > > >Regards > >lakshmi > > > > --- Hisham Khartabil > wrote: > > name-addr = [display-name] "<" addr-spec ">" > > > > > > > -----Original Message----- > > > From: sip-admin@lists.bell-labs.com > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf > Of > > laks hmi > > > Sent: Friday, 22 December 2000 11:50 AM > > > To: Hisham Khartabil > > > Cc: SIP@lists.bell-labs.com > > > Subject: RE: [SIP] conflict in syntax > > > > > > > > > what Mr.Hisham has told is correct but as i told > > only > > > in name-addr they have specified the "<" and > ">". > > > what abt the SIP-URL|URI in address-spec. > > > > > > lakshmi > > > > > > > __________________________________________________ > > > Do You Yahoo!? > > > Yahoo! Shopping - Thousands of Stores. Millions > of > > Products. > > > http://shopping.yahoo.com/ > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of > Products. > http://shopping.yahoo.com/ > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip __________________________________________________ Do You Yahoo!? Yahoo! Shopping - Thousands of Stores. Millions of Products. http://shopping.yahoo.com/ _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 26 00:31:05 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04613 for ; Tue, 26 Dec 2000 00:31:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 262F64433B; Mon, 25 Dec 2000 23:31:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.in.huawei.com (unknown [203.197.168.165]) by lists.bell-labs.com (Postfix) with ESMTP id 3FC6E44337 for ; Mon, 25 Dec 2000 23:30:00 -0500 (EST) Received: by MAIL with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 11:02:07 +0500 Message-ID: From: "Ford Cheng (Leela)" To: SIP@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C06F01.60961570" Subject: [SIP] Consultation Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 26 Dec 2000 11:01:21 +0500 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_01C06F01.60961570 Content-Type: text/plain; charset="iso-8859-1" Dear All: I have one question to consult, on page 94-95 of RFC2543 bis02, there is no detailed algorithm on the generation of nonce, I read RFC2617, there is no algorithm on the generation of nonce. Could anyone give me some suggestion on the generation of nonce? Thanks in advance! ------_=_NextPart_001_01C06F01.60961570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Consultation

Dear All:
     I have one = question to consult,
on page 94-95 of  RFC2543 bis02, = there is no detailed
algorithm on the generation of nonce, = I read RFC2617,
there is no algorithm on the = generation of nonce. Could
anyone give me some suggestion on the = generation of
nonce?
    Thanks in = advance!
            =             =            =20


------_=_NextPart_001_01C06F01.60961570-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 26 00:47:05 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04671 for ; Tue, 26 Dec 2000 00:47:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 19ECF44342; Mon, 25 Dec 2000 23:47:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailweb2.rediffmail.com (unknown [202.54.124.147]) by lists.bell-labs.com (Postfix) with SMTP id 9C7204433B for ; Mon, 25 Dec 2000 23:46:24 -0500 (EST) Received: (qmail 15420 invoked by uid 510); 26 Dec 2000 05:45:09 -0000 Message-ID: <20001226054509.15419.qmail@mailweb2.rediffmail.com> MIME-Version: 1.0 To: "sip@lists.bell-labs.com" From: "Vijeth D" Content-ID: Content-type: text/plain Content-Transfer-Encoding: 7bit Subject: [SIP] Parser for Sip messages Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 26 Dec 2000 05:45:09 -0000 Content-Transfer-Encoding: 7bit Hi, A parser generating tool normally generates a very huge parser for even simple syntaxes. So is it better to write a hand decoder i.e., a manual decoder for the SIP messages? How safe is it to write a manual decoder say in C using the string library? _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 26 00:56:04 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA04692 for ; Tue, 26 Dec 2000 00:56:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0F90E44349; Mon, 25 Dec 2000 23:56:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id 436F044348 for ; Mon, 25 Dec 2000 23:55:07 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eBQ5uF620945; Tue, 26 Dec 2000 11:26:20 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eBQ63xK13170; Tue, 26 Dec 2000 11:34:04 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652569C1.0020AE37 ; Tue, 26 Dec 2000 11:26:57 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Vijeth D" Cc: "sip@lists.bell-labs.com" Message-ID: <652569C1.0020AE2F.00@sampark.hss.hns.com> Subject: Re: [SIP] Parser for Sip messages Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 26 Dec 2000 11:26:56 +0530 A parser generating tool normally generates a very huge parser for even simple syntaxes. So is it arjun> Not always true. Such tools are especially effective when the grammar is large. If arjun> you want to design a parser that is really as flexible as the ABNF along with doing arjun> a complete parse, a tool may not be a bad idea. However, if your application requirements arjun> are less stringent, you can make a lower foot print hand made parser. What you select arjun> is really upto you. I dont want to open another inconclusive hand vs tool generated arjun> debate. arjun> Note however that *how* you use an automated tool is very important. Ive seen some false arjun> comments floating around about certain tools without the posters having studied them arjun> well. I would suggest that you first do a detailed study of available optimisations before arjun> you conclude. Flex and bison are two very flexible tools you can look at. I think someone arjun> else suggested Lemon, antlr etc - havent tried them. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 26 01:22:05 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA06935 for ; Tue, 26 Dec 2000 01:22:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 966484433F; Tue, 26 Dec 2000 00:22:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id 88A7E4433B for ; Tue, 26 Dec 2000 00:21:33 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eBQ6MfL21900; Tue, 26 Dec 2000 11:52:41 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eBQ6UNK15204; Tue, 26 Dec 2000 12:00:29 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652569C1.00231946 ; Tue, 26 Dec 2000 11:53:22 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: "Ford Cheng (Leela)" Cc: SIP@lists.bell-labs.com Message-ID: <652569C1.0023182B.00@sampark.hss.hns.com> Subject: Re: [SIP] Consultation Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=7dvQXvA6mlN6h4tJQLGrlzwOoP4lgSJVLJ8UWWdDOPPGmyawkTMaQvmm" Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 26 Dec 2000 11:53:18 +0530 --0__=7dvQXvA6mlN6h4tJQLGrlzwOoP4lgSJVLJ8UWWdDOPPGmyawkTMaQvmm Content-type: text/plain; charset=us-ascii Content-Disposition: inline One way is to form a nonce is to form a string using your timestamp and private key and calling encodeBase64(x,y) over it. encodeBase64 source is available from a variety of places, if you dont want to implement it yourself . The algorithm you use really depends on how strong you want your nonce value to be. There is afaik, no one way to do it. The above is one algorithm - can use any other you deem fit. Regds Arjun "Ford Cheng (Leela)" on 12/26/2000 11:31:21 AM To: SIP@lists.bell-labs.com cc: Subject: [SIP] Consultation Dear All: I have one question to consult, on page 94-95 of RFC2543 bis02, there is no detailed algorithm on the generation of nonce, I read RFC2617, there is no algorithm on the generation of nonce. Could anyone give me some suggestion on the generation of nonce? Thanks in advance! --0__=7dvQXvA6mlN6h4tJQLGrlzwOoP4lgSJVLJ8UWWdDOPPGmyawkTMaQvmm Content-type: text/html; name="att-1.htm" Content-Disposition: attachment; filename="att-1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDMuMi8vRU4iPg0KPEhUTUw+ DQo8SEVBRD4NCjxNRVRBIEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9o dG1sOyBjaGFyc2V0PWlzby04ODU5LTEiPg0KPE1FVEEgTkFNRT0iR2VuZXJhdG9yIiBDT05URU5U PSJNUyBFeGNoYW5nZSBTZXJ2ZXIgdmVyc2lvbiA1LjUuMjY1MC4xMiI+DQo8VElUTEU+Q29uc3Vs dGF0aW9uPC9USVRMRT4NCjwvSEVBRD4NCjxCT0RZPg0KDQo8UD48Rk9OVCBTSVpFPTIgRkFDRT0i QXJpYWwiPkRlYXIgQWxsOjwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJIGhhdmUgb25lIHF1ZXN0aW9uIHRvIGNvbnN1bHQsPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+b24gcGFnZSA5NC05NSBvZiZuYnNw OyBSRkMyNTQzIGJpczAyLCB0aGVyZSBpcyBubyBkZXRhaWxlZCA8L0ZPTlQ+DQo8QlI+PEZPTlQg U0laRT0yIEZBQ0U9IkFyaWFsIj5hbGdvcml0aG0gb24gdGhlIGdlbmVyYXRpb24gb2Ygbm9uY2Us IEkgcmVhZCBSRkMyNjE3LDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwiPnRo ZXJlIGlzIG5vIGFsZ29yaXRobSBvbiB0aGUgZ2VuZXJhdGlvbiBvZiBub25jZS4gQ291bGQgPC9G T05UPg0KPEJSPjxGT05UIFNJWkU9MiBGQUNFPSJBcmlhbCI+YW55b25lIGdpdmUgbWUgc29tZSBz dWdnZXN0aW9uIG9uIHRoZSBnZW5lcmF0aW9uIG9mIDwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIg RkFDRT0iQXJpYWwiPm5vbmNlPzwvRk9OVD4NCjxCUj48Rk9OVCBTSVpFPTIgRkFDRT0iQXJpYWwi PiZuYnNwOyZuYnNwOyZuYnNwOyBUaGFua3MgaW4gYWR2YW5jZSE8QlI+DQombmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8L0ZPTlQ+IA0KPC9QPg0KPEJSPg0KDQo8L0JPRFk+ DQo8L0hUTUw+ --0__=7dvQXvA6mlN6h4tJQLGrlzwOoP4lgSJVLJ8UWWdDOPPGmyawkTMaQvmm-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 26 03:30:04 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA17867 for ; Tue, 26 Dec 2000 03:30:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 81FCB4433F; Tue, 26 Dec 2000 02:30:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailweb2.rediffmail.com (unknown [202.54.124.147]) by lists.bell-labs.com (Postfix) with SMTP id 2296344336 for ; Tue, 26 Dec 2000 02:29:03 -0500 (EST) Received: (qmail 9546 invoked by uid 510); 26 Dec 2000 08:27:45 -0000 Message-ID: <20001226082745.9545.qmail@mailweb2.rediffmail.com> MIME-Version: 1.0 To: "sip@lists.bell-labs.com" From: "Divya Nath" Content-ID: Content-type: text/plain Content-Transfer-Encoding: 7bit Subject: [SIP] e-mail divyanath@rediffmail.com Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 26 Dec 2000 08:27:45 -0000 Content-Transfer-Encoding: 7bit my email address is divyanath@rediffmail.com _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 26 04:31:04 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA18027 for ; Tue, 26 Dec 2000 04:31:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 910AA44337; Tue, 26 Dec 2000 03:31:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wiprom2mx1.wipro.com (wiprom2mx1.wipro.com [203.197.164.41]) by lists.bell-labs.com (Postfix) with ESMTP id 8F3F844336 for ; Tue, 26 Dec 2000 03:30:49 -0500 (EST) Received: from m2hub.wipro.com (m2hub.wipro.com [164.164.27.50]) by wiprom2mx1.wipro.com (8.9.3+Sun/8.9.3) with ESMTP id PAA14179 for ; Tue, 26 Dec 2000 15:07:44 GMT Received: from m2vwall2.wipro.com ([164.164.27.52]) by m2hub.wipro.com (Netscape Messaging Server 3.6) with SMTP id AAA384E for ; Tue, 26 Dec 2000 14:57:05 +0530 Received: from wipro.com ([164.164.28.228]) by ace.mail.wipro.com (Netscape Messaging Server 3.6) with ESMTP id AAA2E06 for ; Tue, 26 Dec 2000 14:55:47 +0530 Message-ID: <3A486888.B4C863A@wipro.com> From: "Anuraj Ennai" Organization: Wipro X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sip Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [SIP] CPL and new XML options. Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 26 Dec 2000 15:14:40 +0530 Content-Transfer-Encoding: 7bit Hi all, I know this is not the place to raise issues about CPL. But still, it seems appropriate to discuss it with a wider audience. It is evident that the intent of CPL is not just data representation (pure XML as portable data), but also processing of certain criteria. In the present CPL format, the processing instructions and data represenation are intertwined together, limiting the application scope. (Eg. matching of strings, conditional branches etc provided in the XML doc itself.) I believe it will be beneficial to separate both aspects. Use the XML format for data and XSL/XSLT with emerging XPATH/XPOINTER specs for filtering/ processing. This will make the representation and processing independent providing more flexibility to applications using CPL. Any way, CPL is still evolving and this might be the way to go. And in the end, am I making any sense? Thanks & regards Anuraj Ennai _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 26 09:55:04 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA19511 for ; Tue, 26 Dec 2000 09:55:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3200844337; Tue, 26 Dec 2000 08:55:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailgate.pit.comms.marconi.com (mailgate.pit.comms.marconi.com [169.144.68.6]) by lists.bell-labs.com (Postfix) with ESMTP id D3EA944336 for ; Tue, 26 Dec 2000 08:54:20 -0500 (EST) Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA29465; Tue, 26 Dec 2000 09:54:07 -0500 (EST) Received: from whq-msgrtr-01.pit.comms.marconi.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA18815; Tue, 26 Dec 2000 09:54:08 -0500 (EST) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 26 Dec 2000 09:54:08 -0500 Message-ID: <4FBEA8857476D311A03300204840E1CF01A6EC28@whq-msgusr-02.pit.comms.marconi.com> From: "Rosen, Brian" To: "'Anuraj Ennai'" , sip Subject: RE: [SIP] CPL and new XML options. MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 26 Dec 2000 09:54:07 -0500 You are correct, this is NOT the place to discuss CPL. Please take this discussion to the iptel list. Thanks Brian > -----Original Message----- > From: Anuraj Ennai [mailto:anuraj.ennai@wipro.com] > Sent: Tuesday, December 26, 2000 4:45 AM > To: sip > Subject: [SIP] CPL and new XML options. > > > Hi all, > I know this is not the place to raise issues about CPL. > But still, it seems appropriate to discuss it with a > wider audience. > > It is evident that the intent of CPL is not just data > representation (pure XML as portable data), but also > processing of certain criteria. In the present CPL format, > the processing instructions and data represenation are > intertwined together, limiting the application scope. > (Eg. matching of strings, conditional branches etc provided > in the XML doc itself.) > > I believe it will be beneficial to separate both aspects. > Use the XML format for data and XSL/XSLT with > emerging XPATH/XPOINTER specs for filtering/ > processing. This will make the representation and > processing independent providing more flexibility > to applications using CPL. > > Any way, CPL is still evolving and this might be the way > to go. And in the end, am I making any sense? > > Thanks & regards > Anuraj Ennai > > > > > > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 26 10:21:04 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19736 for ; Tue, 26 Dec 2000 10:21:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CD0A24434D; Tue, 26 Dec 2000 09:21:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id C7E234434C for ; Tue, 26 Dec 2000 09:20:21 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA17783; Tue, 26 Dec 2000 10:20:10 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA09067; Tue, 26 Dec 2000 10:19:57 -0500 (EST) Message-ID: <3A48E240.2DC1FA5B@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Vijeth D Cc: "sip@lists.bell-labs.com" Subject: Re: [SIP] Parser for Sip messages References: <20001226054509.15419.qmail@mailweb2.rediffmail.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Tue, 26 Dec 2000 10:24:00 -0800 Content-Transfer-Encoding: 7bit A hand-crafted parser for the basic SIP (and RTSP and HTTP) structures takes a few hundred lines, with a few more for the specific fields, depending on needs. Not difficult, but does require extensive testing of the corner cases (spacing, line folding). The torture tests are helpful here. Vijeth D wrote: > > Hi, > A parser generating tool normally generates a very huge parser for even simple syntaxes. So is it better to write a hand decoder i.e., a manual decoder for the SIP messages? How safe is it to write a manual decoder say in C using the string library? > > _____________________________________________________ > Chat with your friends as soon as they come online. Get Rediff Bol at > http://bol.rediff.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 26 10:28:03 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA19774 for ; Tue, 26 Dec 2000 10:28:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D389044352; Tue, 26 Dec 2000 09:28:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailweb6.rediffmail.com (unknown [202.54.124.151]) by lists.bell-labs.com (Postfix) with SMTP id ACEF94434D for ; Tue, 26 Dec 2000 09:27:40 -0500 (EST) Received: (qmail 28868 invoked by uid 510); 26 Dec 2000 15:26:22 -0000 Message-ID: <20001226152622.28861.qmail@mailweb6.rediffmail.com> MIME-Version: 1.0 To: "sip@lists.bell-labs.com" From: "Deepak Mohan" Content-ID: Content-type: text/plain Content-Transfer-Encoding: 7bit Subject: [SIP] Encounter error in SDP during parsing Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 26 Dec 2000 15:26:22 -0000 Content-Transfer-Encoding: 7bit If a UAS comes across a protocol error in the SDP while parsing the INVITE/ACK, what is the usual response? -Deepak _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 26 22:39:06 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00935 for ; Tue, 26 Dec 2000 22:39:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6708344337; Tue, 26 Dec 2000 21:39:15 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from web1103.mail.yahoo.com (web1103.mail.yahoo.com [128.11.23.123]) by lists.bell-labs.com (Postfix) with SMTP id 2E6B144336 for ; Tue, 26 Dec 2000 21:38:43 -0500 (EST) Received: (qmail 19507 invoked by uid 60001); 27 Dec 2000 03:38:32 -0000 Message-ID: <20001227033832.19506.qmail@web1103.mail.yahoo.com> Received: from [132.208.135.60] by web1103.mail.yahoo.com; Wed, 27 Dec 2000 04:38:32 CET From: =?iso-8859-1?q?rufin=20soh?= To: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [SIP] Re: SIP digest, Vol 1 #639 - 10 msgs Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 27 Dec 2000 04:38:32 +0100 (CET) Content-Transfer-Encoding: 8bit Dearv All My question today is, when a proxy forwards a 200 response and never receives a bye, nor a cancel after he supposes that communication is already established, how do you handle such a case? It is said in the drafts that every SIP server must support unknown messages, but in this case, I think we can't rely on those messages in our implementation. I have though that It could be possible for proxies also to contact any UAS, as they do with UAC's registered on their directory, do you think that issue possible?(It could solve many message digest problems). Thanks --- sip-request@lists.bell-labs.com a écrit : > Send SIP mailing list submissions to > sip@lists.bell-labs.com > > To subscribe or unsubscribe via the World Wide Web, > visit > http://lists.bell-labs.com/mailman/listinfo/sip > or, via email, send a message with subject or body > 'help' to > sip-request@lists.bell-labs.com > > You can reach the person managing the list at > sip-admin@lists.bell-labs.com > > When replying, please edit your Subject line so it > is more specific > than "Re: Contents of SIP digest..." > > > Today's Topics: > > 1. conflict in syntax (laks hmi) > 2. Consultation (Ford Cheng (Leela)) > 3. Parser for Sip messages (Vijeth D) > 4. Re: Parser for Sip messages > (archow@hss.hns.com) > 5. Re: Consultation (archow@hss.hns.com) > 6. e-mail divyanath@rediffmail.com (Divya Nath) > 7. CPL and new XML options. (Anuraj Ennai) > 8. RE: CPL and new XML options. (Rosen, Brian) > 9. Re: Parser for Sip messages (Henning > Schulzrinne) > 10. Encounter error in SDP during parsing (Deepak > Mohan) > > ATTACHMENT part 3.1 message/rfc822 > Date: Mon, 25 Dec 2000 20:28:07 -0800 (PST) > De: laks hmi > Objet: [SIP] conflict in syntax > À: Christian Jansson , > SIP@lists.bell-labs.com > > >i have clearly mentioned in first mail where > exactly > the conflict is coming, once again i am explaining > below. > > Contact = ( "Contact" | "m")":" ("*" > > | (1# (( name-addr | addr-spec ) *( ";" > > contact-params )))) > > In the above syntax, (1# (( name-addr | addr-spec ) > is > there in the beginning of the header after colon. > SIP_URL | URI is coming in addr-spec is the first > parameter can end with semicolon and token which > is there in the generic-param of the other-params > is conflicting with immediate *(";" contact-params ) > where again semicolon and token will come. > > In this both other-param in URL and *( ";" > contact-params ) can come zero or multiple times, so > we > will not be knowing which parameter. > > Regards > lakshmi > > > --- Christian Jansson wrote: > > Just a few lines below the Contact syntax there is > a > > sentence that > > I think will solve your problem: > > > > "Even if the "display-name"is empty, the > "name-addr" > > form MUST be > > used if the "addr-spec" contains a comma, > semicolon > > or question mark." > > > > --- > > Christian Jansson > > > > >The syntax is as foloows > > >Contact = ( "Contact" | "m")":" ("*" > > >| (1# (( name-addr | addr-spec ) *( ";" > > >contact-params )))) > > > > >i am telling abt (1# (( name-addr | addr-spec ), > > where > > >SIP-URL and URI is coming in address-spec and not > > in > > >the name-adress. > > > > >Regards > > >lakshmi > > > > > > > > --- Hisham Khartabil > > wrote: > > > name-addr = [display-name] "<" addr-spec ">" > > > > > > > > > > -----Original Message----- > > > > From: sip-admin@lists.bell-labs.com > > > > [mailto:sip-admin@lists.bell-labs.com]On > Behalf > > Of > > > laks hmi > > > > Sent: Friday, 22 December 2000 11:50 AM > > > > To: Hisham Khartabil > > > > Cc: SIP@lists.bell-labs.com > > > > Subject: RE: [SIP] conflict in syntax > > > > > > > > > > > > what Mr.Hisham has told is correct but as i > told > > > only > > > > in name-addr they have specified the "<" and > > ">". > > > > what abt the SIP-URL|URI in address-spec. > > > > > > > > lakshmi > > > > > > > > > > __________________________________________________ > > > > Do You Yahoo!? > > > > Yahoo! Shopping - Thousands of Stores. > Millions > > of > > > Products. > > > > http://shopping.yahoo.com/ > > > > > > > > > _______________________________________________ > > > > SIP mailing list > > > > SIP@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > > > SIP mailing list > > > SIP@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Shopping - Thousands of Stores. Millions of > > Products. > > http://shopping.yahoo.com/ > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > __________________________________________________ > Do You Yahoo!? > Yahoo! Shopping - Thousands of Stores. Millions of > Products. > http://shopping.yahoo.com/ > > > ATTACHMENT part 3.2 message/rfc822 > De: "Ford Cheng (Leela)" > À: SIP@lists.bell-labs.com > Date: Tue, 26 Dec 2000 11:01:21 +0500 > Objet: [SIP] Consultation > > Dear All: > I have one question to consult, > on page 94-95 of RFC2543 bis02, there is no > detailed > algorithm on the generation of nonce, I read > RFC2617, > there is no algorithm on the generation of nonce. > Could > anyone give me some suggestion on the generation of > nonce? > Thanks in advance! > > > > > ATTACHMENT part 3.3 message/rfc822 > Date: 26 Dec 2000 05:45:09 -0000 > À: sip@lists.bell-labs.com > De: "Vijeth D" > Objet: [SIP] Parser for Sip messages > > Hi, > A parser generating tool normally generates a very > huge parser for even simple syntaxes. So is it > better to write a hand decoder i.e., a manual > decoder for the SIP messages? How safe is it to > write a manual decoder say in C using the string > library? > > > > > _____________________________________________________ > Chat with your friends as soon as they come online. > Get Rediff Bol at > http://bol.rediff.com > > > > > > > ATTACHMENT part 3.4 message/rfc822 > De: archow@hss.hns.com > À: "Vijeth D" > CC: "sip@lists.bell-labs.com" > > Date: Tue, 26 Dec 2000 11:26:56 +0530 > Objet: Re: [SIP] Parser for Sip messages > > > > > A parser generating tool normally generates a very > huge parser for even > simple syntaxes. So is it > > arjun> Not always true. Such tools are especially > effective when the > grammar is large. If > arjun> you want to design a parser that is really as > flexible as the ABNF > along with doing > arjun> a complete parse, a tool may not be a bad > idea. However, if your > application requirements > arjun> are less stringent, you can make a lower foot > print hand made > parser. What you select > arjun> is really upto you. I dont want to open > another inconclusive hand vs > tool generated > arjun> debate. > arjun> Note however that *how* you use an automated > tool is very important. > Ive seen some false > arjun> comments floating around about certain tools > without the posters > having studied them > arjun> well. I would suggest that you first do a > detailed study of > available optimisations before > arjun> you conclude. Flex and bison are two very > flexible tools you can > look at. I think someone > arjun> else suggested Lemon, antlr etc - havent > tried them. > > > Regds > Arjun > -- > Arjun Roychowdhury @ Hughes Software Systems > > > > > > _____________________________________________________ > Chat with your friends as soon as they come online. > Get Rediff Bol at > http://bol.rediff.com > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > > > ATTACHMENT part 3.5 message/rfc822 > De: archow@hss.hns.com > À: "Ford Cheng (Leela)" > CC: SIP@lists.bell-labs.com > Date: Tue, 26 Dec 2000 11:53:18 +0530 > Objet: Re: [SIP] Consultation > > > > One way is to form a nonce is to form a string using > your timestamp and > private key and calling > encodeBase64(x,y) over it. encodeBase64 source is > available from a variety > of places, if you dont want to implement > it yourself . > > The algorithm you use really depends on how strong > you want your nonce > value to be. There is afaik, no > one way to do it. The above is one algorithm - can > use any other you deem > fit. > > Regds > Arjun > > > > > > > "Ford Cheng (Leela)" on > 12/26/2000 11:31:21 AM > > To: SIP@lists.bell-labs.com > cc: > > Subject: [SIP] Consultation > > > > > Dear All: > I have one question to consult, > on page 94-95 of RFC2543 bis02, there is no > detailed > algorithm on the generation of nonce, I read > RFC2617, > there is no algorithm on the generation of nonce. > Could > anyone give me some suggestion on the generation of > nonce? > Thanks in advance! > > > > >
Consultation

Dear All:
     I have one question to consult,
on page 94-95 of  RFC2543 bis02, there is no detailed
algorithm on the generation of nonce, I read RFC2617,
there is no algorithm on the generation of nonce. Could
anyone give me some suggestion on the generation of
nonce?
    Thanks in advance!
                                   


> ATTACHMENT part 3.6 message/rfc822 > Date: 26 Dec 2000 08:27:45 -0000 > À: sip@lists.bell-labs.com > De: "Divya Nath" > Objet: [SIP] e-mail divyanath@rediffmail.com > > my email address is > > divyanath@rediffmail.com > > _____________________________________________________ > Chat with your friends as soon as they come online. > Get Rediff Bol at > http://bol.rediff.com > > > > > > > ATTACHMENT part 3.7 message/rfc822 > Date: Tue, 26 Dec 2000 15:14:40 +0530 > De: "Anuraj Ennai" > Affiliation: Wipro > À: sip > Objet: [SIP] CPL and new XML options. > > Hi all, > I know this is not the place to raise issues about > CPL. > But still, it seems appropriate to discuss it with a > wider audience. > > It is evident that the intent of CPL is not just > data > representation (pure XML as portable data), but also > processing of certain criteria. In the present CPL > format, > the processing instructions and data represenation > are > intertwined together, limiting the application > scope. > (Eg. matching of strings, conditional branches etc > provided > in the XML doc itself.) > > I believe it will be beneficial to separate both > aspects. > Use the XML format for data and XSL/XSLT with > emerging XPATH/XPOINTER specs for filtering/ > processing. This will make the representation and > processing independent providing more flexibility > to applications using CPL. > > Any way, CPL is still evolving and this might be the > way > to go. And in the end, am I making any sense? > > Thanks & regards > Anuraj Ennai > > > > > > > > > > > > > ATTACHMENT part 3.8 message/rfc822 > De: "Rosen, Brian" > À: "'Anuraj Ennai'" , > sip > Objet: RE: [SIP] CPL and new XML options. > Date: Tue, 26 Dec 2000 09:54:07 -0500 > > You are correct, this is NOT the place to discuss > CPL. > > Please take this discussion to the iptel list. > > Thanks > > Brian > > > -----Original Message----- > > From: Anuraj Ennai [mailto:anuraj.ennai@wipro.com] > > Sent: Tuesday, December 26, 2000 4:45 AM > > To: sip > > Subject: [SIP] CPL and new XML options. > > > > > > Hi all, > > I know this is not the place to raise issues about > CPL. > > But still, it seems appropriate to discuss it with > a > > wider audience. > > > > It is evident that the intent of CPL is not just > data > > representation (pure XML as portable data), but > also > > processing of certain criteria. In the present CPL > format, > > the processing instructions and data represenation > are > > intertwined together, limiting the application > scope. > > (Eg. matching of strings, conditional branches etc > provided > > in the XML doc itself.) > > > > I believe it will be beneficial to separate both > aspects. > > Use the XML format for data and XSL/XSLT with > > emerging XPATH/XPOINTER specs for filtering/ > > processing. This will make the representation and > > processing independent providing more flexibility > > to applications using CPL. > > > > Any way, CPL is still evolving and this might be > the way > > to go. And in the end, am I making any sense? > > > > Thanks & regards > > Anuraj Ennai > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > > ATTACHMENT part 3.9 message/rfc822 > Date: Tue, 26 Dec 2000 10:24:00 -0800 > De: Henning Schulzrinne > Affiliation: Columbia University > À: Vijeth D > CC: "sip@lists.bell-labs.com" > > Objet: Re: [SIP] Parser for Sip messages > > A hand-crafted parser for the basic SIP (and RTSP > and HTTP) structures > takes a few hundred lines, with a few more for the > specific fields, > depending on needs. Not difficult, but does require > extensive testing of > the corner cases (spacing, line folding). The > torture tests are helpful > here. > > Vijeth D wrote: > > > > Hi, > > A parser generating tool normally generates a very > huge parser for even simple syntaxes. So is it > better to write a hand decoder i.e., a manual > decoder for the SIP messages? How safe is it to > write a manual decoder say in C using the string > library? > > > > > _____________________________________________________ > > Chat with your friends as soon as they come > online. Get Rediff Bol at > > http://bol.rediff.com > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > ATTACHMENT part 3.10 message/rfc822 > Date: 26 Dec 2000 15:26:22 -0000 > À: sip@lists.bell-labs.com > De: "Deepak Mohan" > Objet: [SIP] Encounter error in SDP during parsing > > If a UAS comes across a protocol error in the SDP > while parsing the INVITE/ACK, what is the usual > response? > > -Deepak > > _____________________________________________________ > Chat with your friends as soon as they come online. > Get Rediff Bol at > http://bol.rediff.com > > > > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > > ___________________________________________________________ Do You Yahoo!? -- Pour dialoguer en direct avec vos amis, Yahoo! Messenger : http://fr.messenger.yahoo.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Tue Dec 26 22:49:03 2000 Received: from lists.bell-labs.com ([204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA00996 for ; Tue, 26 Dec 2000 22:49:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0084E44352; Tue, 26 Dec 2000 21:49:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from hindon.hss.co.in (unknown [202.54.26.202]) by lists.bell-labs.com (Postfix) with ESMTP id E269144337 for ; Tue, 26 Dec 2000 21:48:00 -0500 (EST) Received: from hsssun01.hss.hns.com (localhost [127.0.0.1]) by hindon.hss.co.in (8.10.0/8.10.0) with ESMTP id eBR3nBA12693; Wed, 27 Dec 2000 09:19:11 +0530 (IST) Received: from sampark.hss.hns.com (sampark [139.85.229.22]) by hsssun01.hss.hns.com (8.10.0/8.10.0) with SMTP id eBR3uvK16534; Wed, 27 Dec 2000 09:27:02 +0530 (IST) Received: by sampark.hss.hns.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 652569C2.00150C1F ; Wed, 27 Dec 2000 09:19:53 +0530 X-Lotus-FromDomain: HSSBLR From: archow@hss.hns.com To: rufin soh Cc: sip@lists.bell-labs.com Message-ID: <652569C2.00150B9C.00@sampark.hss.hns.com> Subject: Re: [SIP] Re: SIP digest, Vol 1 #639 - 10 msgs Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 27 Dec 2000 09:19:52 +0530 My question today is, when a proxy forwards a 200 response and never receives a bye, nor a cancel after he supposes that communication is already established, how do you handle such a case? Arjun> If its a stateless proxy, its no bother, since it does Arjun> not keep transaction state. Arjun> In the case of stateful, typically proxies Arjun> insert a record route to make sure he sees future Arjun> requests. If you are talking about a case where Arjun> due to some error, the termination message never Arjun> reaches the proxy,even though it really terminated, Arjun> I guess the proxy could have Arjun> some local configuration which would purge unfreed Arjun> call records after a defined time interval. That would Arjun> be implementation dependant. It is said in the drafts that every SIP server must support unknown messages, but in this case, I think we can't rely on those messages in our implementation. I have though that It could be possible for proxies also to contact any UAS, as they do with UAC's registered on their directory, do you think that issue possible?(It could solve many message digest problems). Arjun> You lost me here. Regds Arjun -- Arjun Roychowdhury @ Hughes Software Systems _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 27 10:56:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18438 for ; Wed, 27 Dec 2000 10:56:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EFBBB44337; Wed, 27 Dec 2000 09:56:11 -0500 (EST) Delivered-To: sip@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 8D86644336 for ; Wed, 27 Dec 2000 09:55:20 -0500 (EST) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Wed Dec 27 10:53:17 EST 2000 Received: by lists.bell-labs.com (Postfix) id B1E9644380; Wed, 27 Dec 2000 10:41:16 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from ans.ih.lucent.com (ans.ih.lucent.com [135.2.78.5]) by lists.bell-labs.com (Postfix) with SMTP id 16FF34437D for ; Wed, 27 Dec 2000 10:41:16 -0500 (EST) Received: by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA05718; Wed, 27 Dec 2000 09:41:13 -0600 Cc: sip@lists.bell-labs.com Received: from lucent.com by ans.ih.lucent.com (SMI-8.6/EMS-1.5 sol2) id JAA05711; Wed, 27 Dec 2000 09:41:12 -0600 Message-ID: <3A4A0D3F.C706F549@lucent.com> From: Vijay Gurbani Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: rufin soh Original-CC: sip@lists.bell-labs.com Subject: Re: [SIP] Re: SIP digest, Vol 1 #639 - 10 msgs References: <20001227033832.19506.qmail@web1103.mail.yahoo.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 27 Dec 2000 09:39:43 -0600 Content-Transfer-Encoding: 7bit rufin soh wrote: > > Dearv All > My question today is, when a proxy forwards a 200 > response and never receives a bye, nor a cancel after > he supposes that communication is already established, > how do you handle such a case? The answer to your question depends on the statefulness of the proxy. If the proxy is stateless, it will not care after proxying the 200 OK (INVITE) upstream, and furthermore, the ACK to the INVITE will go directly to the UAS, as will the ensuing BYE. If the proxy is call-stateful (and thus included a Record-Route), then it MUST see an ACK. Now, assume that the UAC crashes after receiving the 200 OK but before sending the ACK. The call-stateful proxy is waiting for the ACK, as is the downstream UAS. Since the downstream UAS does not get an ACK, it will retransmit the 200 OK upto to a maximum of 7 times and then give up. Presumably, the proxy can count the number of 200 OKs send upstream and clean state after the 7th retransmission. Note that if a call-stateful proxy forwarded a 200 OK (INVITE) upstream, it WILL expect an ACK for its state machinery. Even if the upstream UAC rejected the call by sending a BYE, it has to send an ACK to complete the INVITE transaction. > It is said in the drafts that every SIP server must > support unknown messages, but in this case, I think we > can't rely on those messages in our implementation. Ummm, which unknown message are you referring to? > I have though that It could be possible for proxies > also to contact any UAS, as they do with UAC's > registered on their directory, do you think that issue > possible?(It could solve many message digest > problems). Proxies do not, on their own, contact UASes. They only contact the UAS on behalf of a request initiated by the UAC. Regards, - vijay -- Vijay K. Gurbani vkg@{lucent.com,research.bell-labs.com,acm.org} Internet Software and eServices Group Lucent Technologies/Bell Labs Innovations 263 Shuman Blvd., Rm 1A-413 Naperville, Illinois 60566 Voice: +1 630 224 0216 Fax: +1 630 713 0184 _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 27 14:29:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA20661 for ; Wed, 27 Dec 2000 14:29:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E3FF944368; Wed, 27 Dec 2000 13:29:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (el05-24-167-175-142.ce.mediaone.net [24.167.175.142]) by lists.bell-labs.com (Postfix) with ESMTP id 25B1B44336 for ; Fri, 22 Dec 2000 16:03:21 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 22 Dec 2000 16:03:13 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Sean Olson , "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , sip@lists.bell-labs.com Subject: Re: [SIP] Solving the REFER retransmit issue Message-ID: <20001222160313.A12149@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdrosen@dynamicsoft.com on Fri, Dec 22, 2000 at 04:18:33PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 22 Dec 2000 16:03:13 -0600 Jonathan Rosenberg (jdrosen@dynamicsoft.com): > case REFER means refer, and nothing else; i.e., don't use a header in > an INVITE, since INVITE is not a transfer/refer function. There is > something in the sip guidelines document that says that headers should > not alter the basic functional processing of a request. This was one > of the problems with the original Also proposal. In our proposal, the INVITE semantics are preserved. The referred user wishes to renegotiate the old session, and wishes the phone at the far end to ring. The header does not alter the functional processing, but rather indicates that this re-INVITE is because a response arrived to the spawned call. This is both simple and explicit. > So, I still believe that the best solution is REFER that generates an > automatic NOTIFY. I think the idea of including a header in the > request which tells you whether to send the notify or not is > acceptable. This might be alright, but how about: 1) No NOTIFY is sent if the referred party shuts down the call leg with a BYE. 2) The NOTIFY and REFER may contain SDP. I want, for a failed transfer scenario: Referrer Referred Party ---- REFER (hold SDP) --> <--- OK (hold SDP) ------ (after failed INVITE) <- NOTIFY (active SDP) -- -- OK (active SDP) -----> Message Count: 4 I want to avoid this: Referrer Referred Party --- INVITE/OK/ACK (hold) --> ------ REFER --------------> <----- OK ------------------ (after failed INVITE) <-- NOTIFY ----------------- --- OK --------------------> <-- INVITE/OK/ACK (active) - Message Count: 10 Each device has to maintain state for where it is in the sequence, and recovering the old session from a failed transfer now takes alot more time (the NOTIFY and then the INVITE). -- Billy Biggs bbiggs@div8.net http://www.div8.net/billy/ wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 27 20:07:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA26996 for ; Wed, 27 Dec 2000 20:07:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7E98344350; Wed, 27 Dec 2000 19:07:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 6EC3644337 for ; Wed, 27 Dec 2000 19:06:06 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Dec 2000 17:05:44 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'Billy Biggs'" , Igor Slepchin Cc: Sean Olson , Steve Donovan , David Shrader , SIP List Subject: RE: [SIP] Record-Routing again (Was: Record-Route and REGISTER) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 27 Dec 2000 17:05:43 -0800 > > 1. if some method foo gets record-routed, in which other > request should that > Route go? > 2. when is it safe to destroy that route set? > ... > > So, the question is (1) do we want to even specify, in the base spec, > record-route semantics for non-INVITE requests, and (2) if > so, what are the > answers to questions 1 and 2 above. > > I'm inclined to say no to the first, actually. This doesn't > mean that its > impossible to record-route for anything else, but rather that > the answers to > questions 1. and 2., which constitute the primary issue of > standardization, > are method specific in part. All that we need say in rfc2543 is that > processing of Route headers in proxies is not method > dependent. I suspect > thats the case for most proxies today already. > > I haven't seen much value yet in Record-routing register. Its > not useful for > OPTIONS, and everything else is covered. MESSAGE and SUB/NOT > will need it, > but we can simply specify the meaning for these within those > documents. As > Mike said, lets try and keep things simple. Jonathan, you question in (1) where the UA should place a Route header. I am unclear whether you are also infering that the UA should not copy the Record-Route headers into a 200 response if the request is an "undefined Record-Route method". Regardless, ... Why not make it work for OPTIONS as well? If you are using OPTIONS to determine the capability set of the UA before making a call (ie sending an INVITE), it would be nice if the OPTIONS and INVITE actually went to the same UA; ditto for failed authorization. What about this suggestion for un-Record-Route-defined or unsuccessful-INVITE requests [methods that have no meaning outside of an INVITE session 481'ed]: a) if a UAS copies the Record-Route into the response of a request, then the UA must be prepared to match subsequent requests with the same To/From/Call-Id. The Request-URI of subsequent requests must be ignored - the original Request-URI is always used instead. Record-Routing does not affect whether or not a Contact is included. b) the UAS and proxies must keep state for the To/From/Call-Id for at least 32 seconds (the same as the retransmit cache period). c) if the UAC receives a Record-Route in a response for a To/From/Call-Id for which it make another request, then it should include a forward Route; otherwise the Record-Route/Route information is discarded. [See below, the Contact is not included in building the Route if it is used for other purposes, eg REGISTER.] This covers OPTIONS, failed INVITES and any other methods that do not specifically define Record-Route. If the UA must place Route headers in subsequent requests then it must have its longevity and Record-ROute use explicitly defined (eg sucessful INVITE & SUB/NOT). For the REGISTER case [or in other cases where the Contact is un-usable], if the UA decides to use the Record-Route header in the response, then the UA MUST ignore the Contact field when building the forward Route. As discussed in the previous Record-Route discussions, the proxies must be able to reproduce the _forward_ call forwarding path in the absence of a (usable) Contact in the Record-Route response. [This also covers Record-Routed non-200 responses where Contacts are not allowed.] I don't think we need to say that record-routing REGISTER, OPTIONS or other "generic"/un-Record-Route-defined method will never have any useful purpose. IMO opinion we should be making R-R as generic as possible. Cheers, Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 27 20:19:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27077 for ; Wed, 27 Dec 2000 20:19:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB7D944367; Wed, 27 Dec 2000 19:19:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 2126A44350 for ; Wed, 27 Dec 2000 19:18:06 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Dec 2000 17:17:44 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , Robert Sparks , sip@lists.bell-labs.com Subject: RE: [SIP] 3pcc callflow question (Was:Changin local RTP port with out a good reason) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 27 Dec 2000 17:17:40 -0800 > > > > [Otherwise the controller would have to know/guess the lowest > > capabilities > > of UA A - which is unacceptable.] > > It doesn't matter. This held SDP is updated anyway with a > re-invite later > on. The primary problem would only be if there were no codecs > in the INVITE > that were supported by the recipient. Listing the the most common ones > (g.711, g.723.1, g.729) in the held SDP, as a result, should > work fine, even > if they are not actually supported by A. > > However, it is simplified if the initial INVITE has no SDP. > What if the UA doesn't support audio m lines? Proposing an SDP with just held audio will probably lead to call refusal. I also imagine that things will get complicated when there are mutiple m lines in the SDP (eg 2 audio + 1 video). What if the The 3pcc may even have to rewrite each SDP unless the UA's are very good at heuristic/adhoc m line matching. Cheers, Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 27 20:24:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27118 for ; Wed, 27 Dec 2000 20:24:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D28784436D; Wed, 27 Dec 2000 19:24:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 281C444367 for ; Wed, 27 Dec 2000 19:23:46 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Dec 2000 17:23:24 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'Billy Biggs'" , Jo Hornsby Cc: Keith Robinson , SIP List Subject: RE: [SIP] Proxy Routing Logic MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 27 Dec 2000 17:23:23 -0800 Jonathan Rosenberg wrote: > > A few solutions are possible: > > 1. If you send a request to a URI that contains an maddr, and > you end up > sending it to the address in that maddr, strip the maddr out > before sending > the request. > 2. THe proxy should never had inserted this RR in the first > place, since > using it directly will cause a loop. Rather, something like Robert's > suggestion would be used: > sip:outbound.proxy.com;uri=jdrosen@dynamicsoft.com. > Although I (and Henning) were suggesting that the Request-URI be base64 encoded; otherwise it becomes brittle. If the Request-URI is simply quoted when included then any escaped reserved characters in the Request-URI content will introduce ambiguity with the escaped reserved characters in the Request-URI string. Regards, Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Wed Dec 27 20:57:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27366 for ; Wed, 27 Dec 2000 20:57:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 936DF44367; Wed, 27 Dec 2000 19:57:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id 3006F44362 for ; Wed, 27 Dec 2000 19:56:57 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Wed, 27 Dec 2000 17:56:35 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'Jonathan Rosenberg'" , "'Billy Biggs'" , Igor Slepchin Cc: Sean Olson , Steve Donovan , David Shrader , SIP List Subject: RE: [SIP] Record-Routing again (Was: Record-Route and REGISTER) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Wed, 27 Dec 2000 17:56:26 -0800 Just a couple of corrections .... > > What about this suggestion for un-Record-Route-defined or > unsuccessful-INVITE requests [methods that have no meaning > outside of an > INVITE session 481'ed]: > a) if a UAS copies the Record-Route into the response of a > request, then the > UA must be prepared to match subsequent requests with the same > To/From/Call-Id. The Request-URI of subsequent requests must > be ignored - > the original Request-URI is always used instead. > Record-Routing does not > affect whether or not a Contact is included. > b) the UAS and proxies must keep state for the > To/From/Call-Id for at least > 32 seconds (the same as the retransmit cache period). > c) if the UAC receives a Record-Route in a response for a > To/From/Call-Id > for which it make another request, then it should include a > forward Route; > otherwise the Record-Route/Route information is discarded. > [See below, the > Contact is not included in building the Route if it is used for other > purposes, eg REGISTER.] > > This covers OPTIONS, failed INVITES and any other methods that do not > specifically define Record-Route. If the UA must place Route ^^^ UAS > headers in > subsequent requests then it must have its longevity and > Record-ROute use > explicitly defined (eg sucessful INVITE & SUB/NOT). > > For the REGISTER case [or in other cases where the Contact is > un-usable], if > the UA decides to use the Record-Route header in the > response, then the UA > MUST ignore the Contact field when building the forward > Route. As discussed > in the previous Record-Route discussions, the proxies must be able to > reproduce the _forward_ call forwarding path in the absence > of a (usable) > Contact in the Record-Route response. [This also covers Record-Routed > non-200 responses where Contacts are not allowed.] Actually, I guess there's also the problem that the longevity of REGISTER is a lot longer than 32 seconds. However, I don't see this as much of a problem because you can be pretty sure that the UA and Registrar will keep state for the required period (otherwise the UA or Registrar should accept/return the Record-Route header). So the onus is on the proxy which record-routed the REGISTER in the first place. For robustness, if a proxy record-routes a REGISTER then it should ensure that it does so in a stateless manner. This is acheived, as previously discussed in the Record-Route thread, by embedding directional and forwarding information in the header. > I don't think we need to say that record-routing REGISTER, > OPTIONS or other > "generic"/un-Record-Route-defined method will never have any > useful purpose. > IMO opinion we should be making R-R as generic as possible. > > Cheers, > > Robert. > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 28 12:41:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA17595 for ; Thu, 28 Dec 2000 12:41:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EB35844337; Thu, 28 Dec 2000 11:41:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from motgate2.mot.com (motgate2.mot.com [136.182.1.10]) by lists.bell-labs.com (Postfix) with ESMTP id 6DD7244336 for ; Thu, 28 Dec 2000 11:40:57 -0500 (EST) Received: [from pobox2.mot.com (pobox2.mot.com [136.182.15.8]) by motgate2.mot.com (motgate2 2.1) with ESMTP id KAA25329 for ; Thu, 28 Dec 2000 10:40:38 -0700 (MST)] Received: [from il35exm01.cig.mot.com (IL35EXM01.cig.mot.com [160.19.16.101]) by pobox2.mot.com (MOT-pobox2 2.0) with ESMTP id KAA25590 for ; Thu, 28 Dec 2000 10:40:37 -0700 (MST)] Received: by IL35EXM01.cig.mot.com with Internet Mail Service (5.5.2651.58) id ; Thu, 28 Dec 2000 11:37:20 -0600 Message-ID: <0DF9920C9AD8D211AB0C0008C7CF1C9A04ED890F@il27exm02.cig.mot.com> From: Baniel Uri-CUB001 To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2651.58) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] SIP features/services Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 28 Dec 2000 11:37:19 -0600 Hello Where can one find good references about SIP services/features beyond what is already in the 2543BIS and in the various drafts? Thanks Uri _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 28 15:04:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18740 for ; Thu, 28 Dec 2000 15:04:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8D05C44341; Thu, 28 Dec 2000 14:04:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cisco.com (jindo.cisco.com [171.69.11.73]) by lists.bell-labs.com (Postfix) with ESMTP id 68ECB44337 for ; Thu, 28 Dec 2000 12:26:52 -0500 (EST) Received: from thomasm-u1.cisco.com (thomasm-u1.cisco.com [128.107.140.53]) by cisco.com (8.8.8/2.5.1/Cisco List Logging/8.8.8) with ESMTP id KAA09433 for ; Thu, 28 Dec 2000 10:26:38 -0800 (PST) Received: (thomasm@localhost) by thomasm-u1.cisco.com (8.8.8-Cisco List Logging/CISCO.WS.1.2) id KAA18958; Thu, 28 Dec 2000 10:26:38 -0800 (PST) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14923.34270.53313.693322@thomasm-u1.cisco.com> To: SIP List X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Subject: [SIP] draft-calhoun-sip-aaa-req Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 28 Dec 2000 10:26:38 -0800 (PST) Content-Transfer-Encoding: 7bit Has this document been discussed in either SIP or the AAA working group? I've been trying to put together a draft for requirements and maybe a way to model the requirements for security for SIP. This document seems to start with a model without any definition of what the requirements are first which seems completely backward to me. Indeed, it seems to gather the requirements based on the model. It also seems to make a huge number of assumptions about the way that SIP will be deployed which are rather service provider centric. It's also not immediately apparent to me how one implements these functions without dragging in a gimongous and complicated AAA infrastructure; IMO, moving AAA to a separate server should be a last choice, not a first or only choice. Mike _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 28 15:54:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19353 for ; Thu, 28 Dec 2000 15:54:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0E8E044341; Thu, 28 Dec 2000 14:54:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from kevlar.softarmor.com (dwillis1.directlink.net [63.64.250.82]) by lists.bell-labs.com (Postfix) with ESMTP id 1A5ED44340 for ; Thu, 28 Dec 2000 14:53:41 -0500 (EST) Received: from cowboys (IDENT:root@localhost [127.0.0.1]) by kevlar.softarmor.com (8.9.3/8.9.3) with SMTP id CAA06672; Fri, 29 Dec 2000 02:59:17 -0600 Message-ID: <005301c0710f$d6023190$ea036e3f@dynamicsoft.com> From: "Dean Willis" To: "Michael Thomas" , "SIP List" References: <14923.34270.53313.693322@thomasm-u1.cisco.com> Subject: Re: [SIP] draft-calhoun-sip-aaa-req 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 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 28 Dec 2000 14:50:38 -0600 Content-Transfer-Encoding: 7bit I have the impression that the authors started from the emerging 3G model and the associated requirements and worked backward into AAA for SIP. -- Dean ----- Original Message ----- From: "Michael Thomas" To: "SIP List" Sent: Thursday, December 28, 2000 12:26 PM Subject: [SIP] draft-calhoun-sip-aaa-req > > Has this document been discussed in either SIP or > the AAA working group? I've been trying to put > together a draft for requirements and maybe a way > to model the requirements for security for SIP. > > This document seems to start with a model without > any definition of what the requirements are first > which seems completely backward to me. Indeed, it > seems to gather the requirements based on the > model. It also seems to make a huge number of > assumptions about the way that SIP will be > deployed which are rather service provider > centric. It's also not immediately apparent to me > how one implements these functions without > dragging in a gimongous and complicated AAA > infrastructure; IMO, moving AAA to a separate > server should be a last choice, not a first or > only choice. > > > Mike > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 28 17:01:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20018 for ; Thu, 28 Dec 2000 17:01:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 62ABF44338; Thu, 28 Dec 2000 16:01:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67]) by lists.bell-labs.com (Postfix) with ESMTP id 6A1A244337 for ; Thu, 28 Dec 2000 16:00:10 -0500 (EST) Received: from matt.ipverse.com (lsanca1-ar5-208-220.dsl.gtei.net [4.33.208.220]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZV8K8A20; Thu, 28 Dec 2000 13:59:59 -0800 Message-Id: <5.0.2.1.2.20001228135229.01ec4ec0@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 To: "Dean Willis" , sip@lists.bell-labs.com From: Matt Holdrege Subject: Re: [SIP] draft-calhoun-sip-aaa-req In-Reply-To: <005301c0710f$d6023190$ea036e3f@dynamicsoft.com> References: <14923.34270.53313.693322@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 28 Dec 2000 13:55:39 -0800 Some of the authors did indeed take 3G requirements into account. Other authors brought in requirements from other areas. Taking all the various requirements in and documenting them is the purpose of the draft. As I stated in the meeting (this should be in the minutes) we need to develop a document that describes the AAA requirements for networks that use SIP. At 12:50 PM 12/28/2000, Dean Willis wrote: >I have the impression that the authors started from the emerging 3G model >and the associated requirements and worked backward into AAA for SIP. > >-- >Dean > >----- Original Message ----- >From: "Michael Thomas" >To: "SIP List" >Sent: Thursday, December 28, 2000 12:26 PM >Subject: [SIP] draft-calhoun-sip-aaa-req > > > > > > Has this document been discussed in either SIP or > > the AAA working group? I've been trying to put > > together a draft for requirements and maybe a way > > to model the requirements for security for SIP. > > > > This document seems to start with a model without > > any definition of what the requirements are first > > which seems completely backward to me. Indeed, it > > seems to gather the requirements based on the > > model. It also seems to make a huge number of > > assumptions about the way that SIP will be > > deployed which are rather service provider > > centric. It's also not immediately apparent to me > > how one implements these functions without > > dragging in a gimongous and complicated AAA > > infrastructure; IMO, moving AAA to a separate > > server should be a last choice, not a first or > > only choice. > > > > > > Mike > > > > _______________________________________________ > > SIP mailing list > > SIP@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/sip > > > > >_______________________________________________ >SIP mailing list >SIP@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 28 17:20:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20204 for ; Thu, 28 Dec 2000 17:20:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 830CB44353; Thu, 28 Dec 2000 16:20:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.202.49]) by lists.bell-labs.com (Postfix) with ESMTP id 9D7764434D for ; Thu, 28 Dec 2000 16:19:16 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id OAA00361 for ; Thu, 28 Dec 2000 14:29:50 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 From: David Shrader To: SIP List Message-ID: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: [SIP] Specification of "maddr" parameter Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 28 Dec 2000 17:13:13 -0500 Content-Transfer-Encoding: 7bit For both the SIP-URL and the Via header, the maddr parameter is specified as a host which could be a hostname, IPv4 address, or IPv6 reference. Does this imply that the maddr parameter could contain a hostname? This would imply that the Request-URI or Via header could contain a hostname;maddr=hostname type of construct. Is this correct? David ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 28 17:38:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA20354 for ; Thu, 28 Dec 2000 17:38:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8548A44345; Thu, 28 Dec 2000 16:38:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from eyeforthefuture.com (eyeforthefuture.com [216.122.202.49]) by lists.bell-labs.com (Postfix) with ESMTP id 718AB44337 for ; Thu, 28 Dec 2000 16:37:29 -0500 (EST) Received: from [208.61.13.129] (adsl-61-13-129.mia.bellsouth.net [208.61.13.129]) by eyeforthefuture.com (8.9.3/8.9.3) with ESMTP id OAA03194; Thu, 28 Dec 2000 14:48:01 -0800 (PST) User-Agent: Microsoft-Outlook-Express-Macintosh-Edition/5.02.2022 Subject: Re: [SIP] Record-Route and REGISTER From: David Shrader To: Jonathan Rosenberg , "'Billy Biggs'" , Igor Slepchin Cc: Sean Olson , Steve Donovan , SIP List Message-ID: In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 28 Dec 2000 17:31:25 -0500 Content-Transfer-Encoding: 7bit The reason I raised this question originally is in the context of a security architecture in which we maintain secure connections to user agents outside of a secure/trusted perimeter. Upon establishment of a secure connection for a user agent to the network, RR could be used to insure that the secure channel is used in both directions for subsequent interactions. The REGISTER message, of course, must be included in the overall structure. Note: the overall solution to this problem might involve pre-loaded Route headers as well which were not under discussion in this email. As such, I think the RR mechanism could be useful as a generic routing mechanism that applies to any SIP call leg (To/From/Call-ID) and whatever requests are a part of that call leg without having to define method specific processing. ---------------------------- David Shrader Master Consultant, Inc. dshrader@master-consultant.com http://www.EyeForTheFuture.com > From: Jonathan Rosenberg > Date: Fri, 22 Dec 2000 15:07:30 -0500 > To: "'Billy Biggs'" , Igor Slepchin > > Cc: Jonathan Rosenberg , Sean Olson > , Steve Donovan , David > Shrader , SIP List > Subject: RE: [SIP] Record-Route and REGISTER > > > > > >> -----Original Message----- >> From: Billy Biggs [mailto:Billy_Biggs@3com.com] >> Sent: Thursday, December 21, 2000 3:55 PM >> To: Igor Slepchin >> Cc: Jonathan Rosenberg; Sean Olson; Steve Donovan; David Shrader; SIP >> List >> Subject: Re: [SIP] Record-Route and REGISTER >> >> >> Igor Slepchin (ISlepchin@dynamicsoft.com): >> >>> I never suggested that all proxies always Record-Route. >> What I said is >>> that proxies should not necessarily base the decision about >> whether to >>> record route based only on the request type. >> >> I argue that the decision should be based on the request >> type and the >> proxy's requirements. Being conservative here is important >> to avoid all >> the problems of having packets route through a (disinterested) third >> party. > > I think the overall statement is that, ultimately, record-routing is at the > policy discretion of the server. This will depend on what it wants to do, > the request method, etc. No disagreement there, I think. > > Sean said: >> RR is well defined for all methods within a call leg. What is up for >> consideration (I believe -- please correct me if I'm wrong) is whether >> a RR in the REGISTER should also apply to the INVITE/CANCEL/ACK/BYE >> and vice-versa. > > No, that is not the issue. THis changes the meaning of Route/Record-Route > and that is not on the table. > > So what is the issue? > > Igor has made the statement that a proxy should be able to record-route for > any request method. Indeed, that is the issue. UAs will need to be prepared > to handle that. In order to do so, they must know how to do several things > that, right now, are not very clear: > > 1. if some method foo gets record-routed, in which other request should that > Route go? > 2. when is it safe to destroy that route set? > > Currently, the answers to these for INVITEs are (1) all requests within the > call leg, and (2) when the call leg is over, from BYE or timeout. With > REGISTER, for example, what are the answers? Turns out that "call leg", > using the more formal local ID/remote ID/Call-ID works well, resulting in > routes being established for all refreshes from a single UA. The same is > true for IM and SUBSCRIBE. The answer to the second question is more > complex, and is very likely method dependent. > > So, the question is (1) do we want to even specify, in the base spec, > record-route semantics for non-INVITE requests, and (2) if so, what are the > answers to questions 1 and 2 above. > > I'm inclined to say no to the first, actually. This doesn't mean that its > impossible to record-route for anything else, but rather that the answers to > questions 1. and 2., which constitute the primary issue of standardization, > are method specific in part. All that we need say in rfc2543 is that > processing of Route headers in proxies is not method dependent. I suspect > thats the case for most proxies today already. > > I haven't seen much value yet in Record-routing register. Its not useful for > OPTIONS, and everything else is covered. MESSAGE and SUB/NOT will need it, > but we can simply specify the meaning for these within those documents. As > Mike said, lets try and keep things simple. > > > -Jonathan R. > > > --- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 28 18:02:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20507 for ; Thu, 28 Dec 2000 18:02:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A072E44359; Thu, 28 Dec 2000 17:02:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from exchange1.nuera.com (igate.nuera.com [204.216.240.98]) by lists.bell-labs.com (Postfix) with ESMTP id D01434434B for ; Thu, 28 Dec 2000 17:01:38 -0500 (EST) Received: by exchange1.nuera.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Dec 2000 15:01:13 -0800 Message-ID: From: "Fairlie-Cuninghame, Robert" To: "'David Shrader'" Cc: SIP List Subject: RE: [SIP] Record-Route and REGISTER MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 28 Dec 2000 15:01:12 -0800 > > The reason I raised this question originally is in the > context of a security > architecture in which we maintain secure connections to user > agents outside > of a secure/trusted perimeter. Upon establishment of a secure > connection for > a user agent to the network, RR could be used to insure that > the secure > channel is used in both directions for subsequent > interactions. The REGISTER > message, of course, must be included in the overall structure. > > Note: the overall solution to this problem might involve > pre-loaded Route > headers as well which were not under discussion in this email. > > As such, I think the RR mechanism could be useful as a generic routing > mechanism that applies to any SIP call leg (To/From/Call-ID) > and whatever > requests are a part of that call leg without having to define method > specific processing. > Hi David, I don't understand. Are you saying that the REGISTER R-R is used for subsequent INVITE transactions? The REGISTER doesn't have the same To/From/Call-Id. Additionally, R-R does not allow you to specify different Request-URI's in subsequent transactions. I guess you could define that the Record-ROute in the REGISTER is used as a pre-loaded Route in INVITE transactions pertaining to this REGISTER. This would definitely require method specific processing (and also assumes that the "local" proxy and registrar must go through the same number of record-routing proxies). It would require all sorts of funky ROute construction (eg putting final request-URI after Contact from register). Is is worth it? Probably not. We want generic methods not method specific cases (as you said). For your problem, can't you place a registrar & proxy outside your "secure zone". Authentication and/or encrytption between the UA and external registrar/proxy can then provide the "secure connection" and the proxy can ensure that the UA uses the correct path (much like secure remote network connection servers work today). Regards, Robert. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 28 19:39:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA20927 for ; Thu, 28 Dec 2000 19:39:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C0AAC4433C; Thu, 28 Dec 2000 18:39:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wehq.winbond.com.tw (wehq.winbond.com.tw [202.39.229.15]) by lists.bell-labs.com (Postfix) with ESMTP id 7666F44338 for ; Thu, 28 Dec 2000 18:38:02 -0500 (EST) Received: from wehqimc.winbond.com.tw (wehqimc [10.2.6.99]) by wehq.winbond.com.tw (8.10.0/8.10.0) with ESMTP id eBT0boq08690 for ; Fri, 29 Dec 2000 08:37:50 +0800 (CST) Received: by wehqimc with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Dec 2000 08:37:45 +0800 Message-ID: <024D43D1894BD111859700A0C989534D01A26E74@WECAML01> From: PD20 Ka Fong Tang To: sip@lists.bell-labs.com MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] Digest Authentication Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 08:40:09 +0800 Hi All, We are developing Digest Authentication and we are interested to know that if anyone already has one? I suspect that we are going to complete it by mid-January. Let me know and we can try to test it by that time. Thanks. Ka-Fong Tang _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 28 20:03:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA20997 for ; Thu, 28 Dec 2000 20:03:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C6B4E44341; Thu, 28 Dec 2000 19:03:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mail.sipcomm.com (mail.sipcomm.com [64.67.24.21]) by lists.bell-labs.com (Postfix) with ESMTP id 358094433C for ; Thu, 28 Dec 2000 19:02:07 -0500 (EST) Received: from cc444799b [24.180.134.92] by mail.sipcomm.com (SMTPD32-6.00) id A371B4390154; Thu, 28 Dec 2000 20:05:53 -0500 Reply-To: From: "Mohammad Vakil" To: "PD20 Ka Fong Tang" , Subject: RE: [SIP] Digest Authentication 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.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Importance: Normal In-Reply-To: <024D43D1894BD111859700A0C989534D01A26E74@WECAML01> Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 28 Dec 2000 20:01:51 -0500 Content-Transfer-Encoding: 7bit I'd do a search on the internet for MD5. I'm positive you should be able to find some source code already implemented. > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of PD20 Ka Fong Tang > Sent: Thursday, December 28, 2000 7:40 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Digest Authentication > > > Hi All, > > We are developing Digest Authentication and we are interested to know that > if anyone already has one? I suspect that we are going to complete it by > mid-January. Let me know and we can try to test it by that time. Thanks. > > Ka-Fong Tang > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 28 20:11:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA21031 for ; Thu, 28 Dec 2000 20:11:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B8E8E44342; Thu, 28 Dec 2000 19:11:11 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from wehq.winbond.com.tw (wehq.winbond.com.tw [202.39.229.15]) by lists.bell-labs.com (Postfix) with ESMTP id 4F5AF4433C for ; Thu, 28 Dec 2000 19:10:47 -0500 (EST) Received: from wehqimc.winbond.com.tw (wehqimc [10.2.6.99]) by wehq.winbond.com.tw (8.10.0/8.10.0) with ESMTP id eBT1ASq13829; Fri, 29 Dec 2000 09:10:30 +0800 (CST) Received: by wehqimc with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Dec 2000 09:10:23 +0800 Message-ID: <024D43D1894BD111859700A0C989534D01A26E7C@WECAML01> From: PD20 Ka Fong Tang To: mvakil@sipcomm.com, sip@lists.bell-labs.com Subject: RE: [SIP] Digest Authentication MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 09:12:45 +0800 There are source codes in RFC 1321 and RFC 2617. We will use them as references and develop our own. -----Original Message----- From: Mohammad Vakil [mailto:mvakil@sipcomm.com] Sent: Thursday, December 28, 2000 5:02 PM To: PD20 Ka Fong Tang; sip@lists.bell-labs.com Subject: RE: [SIP] Digest Authentication I'd do a search on the internet for MD5. I'm positive you should be able to find some source code already implemented. > -----Original Message----- > From: sip-admin@lists.bell-labs.com > [mailto:sip-admin@lists.bell-labs.com]On Behalf Of PD20 Ka Fong Tang > Sent: Thursday, December 28, 2000 7:40 PM > To: sip@lists.bell-labs.com > Subject: [SIP] Digest Authentication > > > Hi All, > > We are developing Digest Authentication and we are interested to know that > if anyone already has one? I suspect that we are going to complete it by > mid-January. Let me know and we can try to test it by that time. Thanks. > > Ka-Fong Tang > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Thu Dec 28 23:50:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA24281 for ; Thu, 28 Dec 2000 23:50:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BCAF244341; Thu, 28 Dec 2000 22:50:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 0E24B44340 for ; Thu, 28 Dec 2000 22:49:47 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA19022; Thu, 28 Dec 2000 23:52:13 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Dec 2000 23:46:52 -0500 Message-ID: From: Jonathan Rosenberg To: "'David Shrader'" , SIP List Subject: RE: [SIP] Specification of "maddr" parameter MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 28 Dec 2000 23:46:45 -0500 > -----Original Message----- > From: David Shrader [mailto:dshrader@master-consultant.com] > Sent: Thursday, December 28, 2000 5:13 PM > To: SIP List > Subject: [SIP] Specification of "maddr" parameter > > > For both the SIP-URL and the Via header, the maddr parameter > is specified as > a host which could be a hostname, IPv4 address, or IPv6 > reference. Does this > imply that the maddr parameter could contain a hostname? This > would imply > that the Request-URI or Via header could contain a > hostname;maddr=hostname > type of construct. Is this correct? Yes. Its useful for things like: sip:dshrader@master-consultant.com;maddr=outboundproxy12.dynamicsoft.com -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 00:03:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24355 for ; Fri, 29 Dec 2000 00:03:31 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3657444367; Thu, 28 Dec 2000 23:03:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 11E144436B for ; Thu, 28 Dec 2000 23:02:42 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA19071; Fri, 29 Dec 2000 00:05:03 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Thu, 28 Dec 2000 23:59:42 -0500 Message-ID: From: Jonathan Rosenberg To: "'Deepak Mohan'" , sip@lists.bell-labs.com Subject: RE: [SIP] Encounter error in SDP during parsing MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Thu, 28 Dec 2000 23:59:40 -0500 THere are no responses to ACK. If you get an ACK with really malformed SDP you should probably hang up the call. For INVITE, generally a 400 response is sent. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com > -----Original Message----- > From: Deepak Mohan [mailto:deepakwarrier@rediffmail.com] > Sent: Tuesday, December 26, 2000 10:26 AM > To: sip@lists.bell-labs.com > Subject: [SIP] Encounter error in SDP during parsing > > > If a UAS comes across a protocol error in the SDP while > parsing the INVITE/ACK, what is the usual response? > > -Deepak > > _____________________________________________________ > Chat with your friends as soon as they come online. Get Rediff Bol at > http://bol.rediff.com > > > > > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 00:10:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA24385 for ; Fri, 29 Dec 2000 00:10:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BCB6F44372; Thu, 28 Dec 2000 23:10:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D48CA4436D for ; Thu, 28 Dec 2000 23:09:20 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA19115; Fri, 29 Dec 2000 00:11:33 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Dec 2000 00:06:12 -0500 Message-ID: From: Jonathan Rosenberg To: "'laks hmi'" , Christian Jansson , SIP@lists.bell-labs.com Subject: RE: [SIP] conflict in syntax MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 00:06:08 -0500 > -----Original Message----- > From: laks hmi [mailto:lakshmiam@yahoo.com] > Sent: Monday, December 25, 2000 11:28 PM > To: Christian Jansson; SIP@lists.bell-labs.com > Subject: [SIP] conflict in syntax > > > >i have clearly mentioned in first mail where exactly > the conflict is coming, once again i am explaining > below. > > Contact = ( "Contact" | "m")":" ("*" > > | (1# (( name-addr | addr-spec ) *( ";" > > contact-params )))) > > In the above syntax, (1# (( name-addr | addr-spec ) is > there in the beginning of the header after colon. > SIP_URL | URI is coming in addr-spec is the first > parameter can end with semicolon and token which > is there in the generic-param of the other-params > is conflicting with immediate *(";" contact-params ) > where again semicolon and token will come. > > In this both other-param in URL and *( ";" > contact-params ) can come zero or multiple times, so > we > will not be knowing which parameter. THe answer given previously addresses your question. The name-addr form is used when there are other-params, so that: Contact: ;param2=val2 param1 is a URL other-param, and param2 is a Contact header parameter. Any parameter outside the angle brackets, or if there are no angle brackets, any parameter at all, is a Contact header parameter. -Jonathan R. > > Regards > lakshmi > > > --- Christian Jansson wrote: > > Just a few lines below the Contact syntax there is a > > sentence that > > I think will solve your problem: > > > > "Even if the "display-name"is empty, the "name-addr" > > form MUST be > > used if the "addr-spec" contains a comma, semicolon > > or question mark." > > > > --- > > Christian Jansson > > > > >The syntax is as foloows > > >Contact = ( "Contact" | "m")":" ("*" > > >| (1# (( name-addr | addr-spec ) *( ";" > > >contact-params )))) > > > > >i am telling abt (1# (( name-addr | addr-spec ), > > where > > >SIP-URL and URI is coming in address-spec and not > > in > > >the name-adress. > > > > >Regards > > >lakshmi > > > > > > > > --- Hisham Khartabil > > wrote: > > > name-addr = [display-name] "<" addr-spec ">" > > > > > > > > > > -----Original Message----- > > > > From: sip-admin@lists.bell-labs.com > > > > [mailto:sip-admin@lists.bell-labs.com]On Behalf > > Of > > > laks hmi > > > > Sent: Friday, 22 December 2000 11:50 AM > > > > To: Hisham Khartabil > > > > Cc: SIP@lists.bell-labs.com > > > > Subject: RE: [SIP] conflict in syntax > > > > > > > > > > > > what Mr.Hisham has told is correct but as i told > > > only > > > > in name-addr they have specified the "<" and > > ">". > > > > what abt the SIP-URL|URI in address-spec. > > > > > > > > lakshmi > > > > --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 04:39:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08474 for ; Fri, 29 Dec 2000 04:39:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6B1D744337; Fri, 29 Dec 2000 03:39:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailweb13.rediffmail.com (unknown [203.199.83.21]) by lists.bell-labs.com (Postfix) with SMTP id 9EE5144336 for ; Fri, 29 Dec 2000 03:38:27 -0500 (EST) Received: (qmail 29027 invoked by uid 510); 29 Dec 2000 09:36:15 -0000 Message-ID: <20001229093615.29026.qmail@mailweb13.rediffmail.com> Received: from unknown (203.195.140.59) by rediffmail.com via HTTP; 29 Dec 2000 09:36:15 -0000 MIME-Version: 1.0 To: "sip@lists.bell-labs.com" From: "Deepak Mohan" Content-ID: Content-type: text/plain Content-Description: Body Content-Transfer-Encoding: 7bit Subject: [SIP] 6xx and 3xx responses from registrar Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 29 Dec 2000 09:36:15 -0000 Content-Transfer-Encoding: 7bit For which request, and under what circumstances will a registrar give a 3xx or 6xx response? Thanks. _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 08:40:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09188 for ; Fri, 29 Dec 2000 08:40:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B316444337; Fri, 29 Dec 2000 07:40:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from aurora.tsm.es (unknown [194.224.100.20]) by lists.bell-labs.com (Postfix) with ESMTP id 9028F44336 for ; Fri, 29 Dec 2000 05:08:51 -0500 (EST) Received: by aurora.tsm.es; (8.8.8/1.3/10May95) id MAA17229; Fri, 29 Dec 2000 12:08:54 +0100 (MET) From: To: sip@lists.bell-labs.com Message-ID: X-MIMETrack: Serialize by Router on abantos/TSM( =?iso-8859-1?q?Versi=F3n_5=2E0=2E5_|Octubre_21=2C_2000=29_at_29=2F12=2F?= =?us-ascii?q?2000?= 12:06:36 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [SIP] 3PCC and REFER method Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 11:59:43 +0100 Hi I would like to open again the issue discussed in http://lists.bell-labs.com/pipermail/sip/2000q4/004739.html >>What happens when there is not an active SIP (INVITE) session between the >>referer and referee ? Sending an INVITE in this case may have unwanted >>effects (like initiating a call). Are you proposing that either a) you would >>only send the INVITE/BYE if a corresponding SIP (INVITE) sessions exists or >>b) that REFERS are not allowed outside of a SIP session? > What does a REFER outside of a session mean? and apply this idea to the scenario proposed in draft-rosenberg-sip-3pcc-01.txt Figure 1 and specifically the example included for Click-to-dial application. In this alternative scenario for Click-to-dial, the controller, after receiving the request via HTTP, do not INVITE both A and B, but rather send a REFER to A, asking A to INVITE the CONTROLER ITSELF. When the controller receives the INVITE SDP A from A, checks in its internal database who is supposed to be contacted by A (in this case B) and sends INVITE SDP A to B. In this case I think the re-INVITE loop could be avoided by applying this scenario which is more similar to a normal INVITE between two parties. In this alternative scenario the referer (i.e. the controller) and the referee (i.e. the web-surfer) are OUTSIDE of a SIP session, but INSIDE an HTTP session. It could also be decided the referee to be the IP phone from the customer service representative, if the web-surfer IP phone either does not support REFER or is a PSTN endpoint. The reason to include as content of Refer-To header not B but the controller itself is to let the controller do its job in a more general way (i.e. imagine click-to-dial + mid-call-announcement) If the scenario is not the one described for Click-to-dial, but for Mid Call AnnouncementCapability, the controller does not either set up the call to A or send the REFER method to A, but rather receive the INVITE from A and act as a "termination and reinitiation point" for control purposes (i.e. disconnect and reconnect A to a media server under certain conditions) as defined in draft-rosenberg-sip-3pcc-01.txt Sorry if someone has already suggested this and I have missed it... Comments? -----------------------------< O >----------------------------------- Javier Ferreiro Garcia Consultant Telefonica Moviles Spain Dpto. de Plataformas de Servicios 3rd Generation Intelligent Network Platforms Telf.: +34 630 00 43 13 -----------------------------< O >----------------------------------- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 10:08:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09745 for ; Fri, 29 Dec 2000 10:08:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2FD4944343; Fri, 29 Dec 2000 09:08:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 59C5044340 for ; Fri, 29 Dec 2000 09:07:47 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA20705; Fri, 29 Dec 2000 10:10:08 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Dec 2000 10:04:46 -0500 Message-ID: From: Jonathan Rosenberg To: "'Fairlie-Cuninghame, Robert'" , Jonathan Rosenberg , "'Billy Biggs'" , Igor Slepchin Cc: Sean Olson , Steve Donovan , David Shrader , SIP List Subject: RE: [SIP] Record-Routing again (Was: Record-Route and REGISTER) MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 10:04:46 -0500 > -----Original Message----- > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com] > Sent: Wednesday, December 27, 2000 8:06 PM > To: 'Jonathan Rosenberg'; 'Billy Biggs'; Igor Slepchin > Cc: Sean Olson; Steve Donovan; David Shrader; SIP List > Subject: RE: [SIP] Record-Routing again (Was: Record-Route > and REGISTER) > > > > > > 1. if some method foo gets record-routed, in which other > > request should that > > Route go? > > 2. when is it safe to destroy that route set? > > > ... > > > > So, the question is (1) do we want to even specify, in the > base spec, > > record-route semantics for non-INVITE requests, and (2) if > > so, what are the > > answers to questions 1 and 2 above. > > > > I'm inclined to say no to the first, actually. This doesn't > > mean that its > > impossible to record-route for anything else, but rather that > > the answers to > > questions 1. and 2., which constitute the primary issue of > > standardization, > > are method specific in part. All that we need say in rfc2543 is that > > processing of Route headers in proxies is not method > > dependent. I suspect > > thats the case for most proxies today already. > > > > I haven't seen much value yet in Record-routing register. Its > > not useful for > > OPTIONS, and everything else is covered. MESSAGE and SUB/NOT > > will need it, > > but we can simply specify the meaning for these within those > > documents. As > > Mike said, lets try and keep things simple. > > Jonathan, you question in (1) where the UA should place a > Route header. I am > unclear whether you are also infering that the UA should not copy the > Record-Route headers into a 200 response if the request is an > "undefined > Record-Route method". Regardless, ... Well, if the request is an unknown method, the response is 405 in any case, so RR is not really relevant. As per REGISTER and OPTIONS (which are known but not currently record-routed), I suspect most, if not all, implementations do not copy RR headers into the response. > > Why not make it work for OPTIONS as well? If you are using OPTIONS to > determine the capability set of the UA before making a call > (ie sending an > INVITE), it would be nice if the OPTIONS and INVITE actually > went to the > same UA; ditto for failed authorization. Well, OPTIONS is a tricky one. In the case you describe, it makes sense. However, there is no way for a proxy, for example, to know whether an OPTIONS will ever be followed by INVITE. As a result, any state created by OPTIONS (which is why the proxy record-routed) can't easily be destroyed. Record-routing for things for which there is no clear notion of a session, in general, is tricky. To handle the case you are considering, one would use caller preferences along with an Accept-Contact to get back to the same UA that the OPTIONS went to. As for failed authorizations, the spec currently does allow for Record-Routes in these responses. However, I am not a big fan of response code specific processing, and at the bakeoff, we discussed removing these and rather not allowing Record-Route in anything but the 200 OK response. Because of the stateless nature of the authentication mechanism, there is not really a need to record-route. > > What about this suggestion for un-Record-Route-defined or > unsuccessful-INVITE requests [methods that have no meaning > outside of an > INVITE session 481'ed]: > a) if a UAS copies the Record-Route into the response of a > request, then the > UA must be prepared to match subsequent requests with the same > To/From/Call-Id. The Request-URI of subsequent requests must > be ignored - > the original Request-URI is always used instead. > Record-Routing does not > affect whether or not a Contact is included. > b) the UAS and proxies must keep state for the > To/From/Call-Id for at least > 32 seconds (the same as the retransmit cache period). > c) if the UAC receives a Record-Route in a response for a > To/From/Call-Id > for which it make another request, then it should include a > forward Route; > otherwise the Record-Route/Route information is discarded. > [See below, the > Contact is not included in building the Route if it is used for other > purposes, eg REGISTER.] > > This covers OPTIONS, failed INVITES and any other methods that do not > specifically define Record-Route. If the UA must place Route > headers in > subsequent requests then it must have its longevity and > Record-ROute use > explicitly defined (eg sucessful INVITE & SUB/NOT). Its all extra work. I am trying to keep a handle on SIP's complexity. There is also a backwards compatibility issue for Record-routing of REGISTER and OPTIONS. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 10:11:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09789 for ; Fri, 29 Dec 2000 10:11:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B340F4434E; Fri, 29 Dec 2000 09:11:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 9CB384434D for ; Fri, 29 Dec 2000 09:10:03 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA20745; Fri, 29 Dec 2000 10:12:16 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Dec 2000 10:06:54 -0500 Message-ID: From: Jonathan Rosenberg To: "'Deepak Mohan'" , sip@lists.bell-labs.com Subject: RE: [SIP] 6xx and 3xx responses from registrar MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 10:06:53 -0500 > -----Original Message----- > From: Deepak Mohan [mailto:deepakwarrier@rediffmail.com] > Sent: Friday, December 29, 2000 4:36 AM > To: sip@lists.bell-labs.com > Subject: [SIP] 6xx and 3xx responses from registrar > > > For which request, and under what circumstances will a > registrar give a 3xx or 6xx response? Well, since we are talking about a registrar, the only request of interest is REGISTER. When to use these things is implementation dependent. THey have well defined results, and one would use them if you wish to have that result. As an example, a registrar might redirect a multicast request to a unicast address, or perhaps might redirect a request to a backup in case of overload conditions. A 6xx might be used if the user is not allowed to register anywhere in the domain. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 10:15:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA09831 for ; Fri, 29 Dec 2000 10:15:07 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1067344355; Fri, 29 Dec 2000 09:15:15 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EED7844354 for ; Fri, 29 Dec 2000 09:14:11 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA20785; Fri, 29 Dec 2000 10:16:02 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Dec 2000 10:10:40 -0500 Message-ID: From: Jonathan Rosenberg To: "'Billy Biggs'" , Jonathan Rosenberg Cc: Sean Olson , "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , sip@lists.bell-labs.com Subject: RE: [SIP] Solving the REFER retransmit issue MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 10:10:40 -0500 > -----Original Message----- > From: Billy Biggs [mailto:billy@billybiggs.com] > Sent: Friday, December 22, 2000 5:03 PM > To: Jonathan Rosenberg > Cc: Sean Olson; Henning G. Schulzrinne; Rohan Mahy; Robert Sparks; > sip@lists.bell-labs.com > Subject: Re: [SIP] Solving the REFER retransmit issue > > > Jonathan Rosenberg (jdrosen@dynamicsoft.com): > > > case REFER means refer, and nothing else; i.e., don't use a > header in > > an INVITE, since INVITE is not a transfer/refer function. There is > > something in the sip guidelines document that says that > headers should > > not alter the basic functional processing of a request. This was one > > of the problems with the original Also proposal. > > In our proposal, the INVITE semantics are preserved. The referred > user wishes to renegotiate the old session, and wishes the > phone at the > far end to ring. The header does not alter the functional processing, > but rather indicates that this re-INVITE is because a response arrived > to the spawned call. > > This is both simple and explicit. > > > So, I still believe that the best solution is REFER that > generates an > > automatic NOTIFY. I think the idea of including a header in the > > request which tells you whether to send the notify or not is > > acceptable. > > This might be alright, but how about: > > 1) No NOTIFY is sent if the referred party shuts down the call leg > with a BYE. > > 2) The NOTIFY and REFER may contain SDP. I really, really don't like this. REFER as defined now has a simple, clean, very specific but broadly useful semantic. You are basically trying to push us towards the approach of defining service specific methods. I don't want to do that. > > > I want, for a failed transfer scenario: > > Referrer Referred Party > ---- REFER (hold SDP) --> > <--- OK (hold SDP) ------ > > (after failed INVITE) > <- NOTIFY (active SDP) -- > -- OK (active SDP) -----> > > Message Count: 4 > > > I want to avoid this: > > Referrer Referred Party > --- INVITE/OK/ACK (hold) --> > ------ REFER --------------> > <----- OK ------------------ > > (after failed INVITE) > <-- NOTIFY ----------------- > --- OK --------------------> > <-- INVITE/OK/ACK (active) - > > Message Count: 10 The aim is not message count reduction. The aim is general purpose tools that we can use to build more than one service. -Jonathan R. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 10:48:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA10043 for ; Fri, 29 Dec 2000 10:48:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BD5BA4434A; Fri, 29 Dec 2000 09:48:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 35AED44343 for ; Fri, 29 Dec 2000 09:47:38 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA27243; Fri, 29 Dec 2000 10:47:26 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA19262; Fri, 29 Dec 2000 10:47:26 -0500 (EST) Message-ID: <3A4CDD33.F04D882E@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'Deepak Mohan'" , sip@lists.bell-labs.com Subject: Re: [SIP] 6xx and 3xx responses from registrar References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 10:51:31 -0800 Content-Transfer-Encoding: 7bit > > As an example, a registrar might redirect a multicast request to a unicast > address, or perhaps might redirect a request to a backup in case of overload > conditions. > Also, there could be front-end registrar that does load distribution or distribution by name (e.g., user names with A-L go to one registrar box, M-Z to another). _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 11:40:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10498 for ; Fri, 29 Dec 2000 11:40:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 371F44436C; Fri, 29 Dec 2000 10:40:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from uucp1.nwnexus.com (uucp1.nwnexus.com [206.63.63.110]) by lists.bell-labs.com (Postfix) with ESMTP id 899104436B for ; Fri, 29 Dec 2000 10:39:44 -0500 (EST) Received: from internaut.com (uucp@localhost) by uucp1.nwnexus.com (8.8.8/8.8.8) with UUCP id IAA11412; Fri, 29 Dec 2000 08:39:33 -0800 (PST) Received: by internaut.com (NX5.67e/NeXT-3.0) id AA00304; Fri, 29 Dec 00 09:04:40 -0800 From: "Bernard D. Aboba" To: Michael Thomas Cc: SIP List Subject: Re: [SIP] draft-calhoun-sip-aaa-req In-Reply-To: <14923.34270.53313.693322@thomasm-u1.cisco.com> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 09:04:40 -0800 (GMT-0800) The document has not been discussed in the AAA WG, because AAA is focused on network access requirements. Thus, it is completely up to the SIP WG to define the security requirements for SIP, which may or may not require AAA functionality as a solution. I'd note that for applications such as telephony, where the client can often be presumed to have Internet access, a wider range of security solutions are available than in network access, where by definition the client does not have network access prior to authentication. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 11:47:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10530 for ; Fri, 29 Dec 2000 11:47:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F419E44368; Fri, 29 Dec 2000 10:47:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (cr288451-a.flfrd1.on.wave.home.com [24.112.91.149]) by lists.bell-labs.com (Postfix) with ESMTP id 81CFC44356 for ; Fri, 29 Dec 2000 10:46:15 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 29 Dec 2000 10:46:14 -0600 (CST) From: Billy Biggs To: Jonathan Rosenberg Cc: Sean Olson , "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , SIP List Subject: Re: [SIP] Solving the REFER retransmit issue Message-ID: <20001229104614.A1321@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdrosen@dynamicsoft.com on Fri, Dec 29, 2000 at 10:10:40AM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 10:46:14 -0600 Jonathan Rosenberg (jdrosen@dynamicsoft.com): >> This might be alright, but how about: >> >> 1) No NOTIFY is sent if the referred party shuts down the call leg >> with a BYE. >> >> 2) The NOTIFY and REFER may contain SDP. > > I really, really don't like this. > > REFER as defined now has a simple, clean, very specific but broadly > useful semantic. You are basically trying to push us towards the > approach of defining service specific methods. I don't want to do > that. Transfer is a fundamental service. There must be an accepted and interoperable transfer scheme which is simple and small enough that everyone will implement it. I also care about performance. If SDP cannot be placed in the REFER, then requesting a transfer will take two transactions (on hold, then refer). I guess you can forget about the hold and hope that the far end will stop sending media when it gets the REFER... Ugh. If you must send a NOTIFY and then a BYE seperately, then the REFER recipient will have to maintain a queue of operations to perform after the transfer is successful. This is alot of work for small implementations. > The aim is not message count reduction. The aim is general purpose tools > that we can use to build more than one service. Please optimize for the primary use. -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 12:31:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA10776 for ; Fri, 29 Dec 2000 12:31:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 699A64433F; Fri, 29 Dec 2000 11:31:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from dgesmtp01.wcom.com (dgesmtp01.wcom.com [199.249.16.16]) by lists.bell-labs.com (Postfix) with ESMTP id E04ED44338 for ; Fri, 29 Dec 2000 11:30:30 -0500 (EST) Received: from CONVERSION-DAEMON by firewall.mcit.com (PMDF V5.2-33 #42260) id <0G6C00H01BAJ8J@firewall.mcit.com> for sip@lists.bell-labs.com; Fri, 29 Dec 2000 17:30:19 +0000 (GMT) Received: from dgismtp03.wcomnet.com ([166.38.58.143]) by firewall.mcit.com (PMDF V5.2-33 #42260) with ESMTP id <0G6C00H2SBAJ29@firewall.mcit.com>; Fri, 29 Dec 2000 17:30:19 +0000 (GMT) Received: from CONVERSION-DAEMON by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) id <0G6C00701BAI5Y@dgismtp03.wcomnet.com>; Fri, 29 Dec 2000 17:30:18 +0000 (GMT) Received: from dgismtp03.wcomnet.com by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G6C00701BAB4P@dgismtp03.wcomnet.com>; Fri, 29 Dec 2000 17:30:18 +0000 (GMT) Received: from hsinnreich ([166.44.57.162]) by dgismtp03.wcomnet.com (PMDF V5.2-33 #42262) with SMTP id <0G6C0061UBA7HD@dgismtp03.wcomnet.com>; Fri, 29 Dec 2000 17:30:08 +0000 (GMT) From: Henry Sinnreich Subject: RE: [SIP] draft-calhoun-sip-aaa-req In-reply-to: To: "Bernard D. Aboba" , Michael Thomas Cc: SIP List Message-id: MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7bit Importance: Normal X-Priority: 3 (Normal) X-MSMail-priority: Normal Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 11:30:14 -0600 Content-Transfer-Encoding: 7bit >The document has not been discussed in the AAA >WG, because AAA is focused on network access >requirements. Thanks for the clarification! Have felt very uncomfortable with Diameter for applications in the case for various reasons, not at least because of the AVP data format (prefer XML). There may be good reasons to extend RADIUS to DIAMETER for legacy dial-up service (the one we all want to move away from), but should be kept confined there. Henry -----Original Message----- From: sip-admin@lists.bell-labs.com [mailto:sip-admin@lists.bell-labs.com]On Behalf Of Bernard D. Aboba Sent: Friday, December 29, 2000 11:05 AM To: Michael Thomas Cc: SIP List Subject: Re: [SIP] draft-calhoun-sip-aaa-req The document has not been discussed in the AAA WG, because AAA is focused on network access requirements. Thus, it is completely up to the SIP WG to define the security requirements for SIP, which may or may not require AAA functionality as a solution. I'd note that for applications such as telephony, where the client can often be presumed to have Internet access, a wider range of security solutions are available than in network access, where by definition the client does not have network access prior to authentication. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 15:20:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA12655 for ; Fri, 29 Dec 2000 15:20:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 21FBF4434F; Fri, 29 Dec 2000 14:20:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 57AD84434C for ; Fri, 29 Dec 2000 14:19:07 -0500 (EST) Received: from SUPERBEE ([63.110.3.128]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id PAA23832; Fri, 29 Dec 2000 15:21:36 -0500 (EST) From: "Ben Campbell" To: "Jonathan Rosenberg" Cc: "Henning G. Schulzrinne" , "Rohan Mahy" , "Robert Sparks" , , "'Sean Olson'" , "Billy Biggs" Subject: RE: [SIP] Solving the REFER retransmit issue Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3B570@DYN-TX-EXCH-001.dynamicsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 14:16:11 -0600 Content-Transfer-Encoding: 7bit > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, December 22, 2000 3:19 PM > To: 'Sean Olson'; Billy Biggs > Cc: Henning G. Schulzrinne; Rohan Mahy; Robert Sparks; Jonathan > Rosenberg; sip@lists.bell-labs.com > Subject: RE: [SIP] Solving the REFER retransmit issue > > > We have some basic design principals we can use to help us here: > > 1. design general purpose mechanisms, not services > 2. be explicit, not implicit > 3. keep things independent so that they can be combined in > different ways These are very good principles which we should try to follow more often. > > Sometimes these are at odds with some of our design goals: > > 1. KISS > 2. SIP is not a control protocol > > However, I do not think we want to have REFER mean ONLY > transfer. I'd rather > keep it generic with a fairly well defined scope, in > particular, keeping it > away from the control protocol space. I'd also rather be > explicit, in which > case REFER means refer, and nothing else; i.e., don't use a > header in an > INVITE, since INVITE is not a transfer/refer function. There > is something in > the sip guidelines document that says that headers should not > alter the > basic functional processing of a request. This was one of the > problems with > the original Also proposal. > > So, I still believe that the best solution is REFER that generates an > automatic NOTIFY. I think the idea of including a header in > the request > which tells you whether to send the notify or not is acceptable. > It seems to me that an automatic NOTIFY is an implied subscription, thus at odds with your design principle number 2. From a software perspective, I find Robert's proposal of an explicit SUBSCRIBE _if_you_care_ to be a very elegant approach. I realize this creates additional message overhead in the case where the REFER-or cares about the results. However, if present day PSTN stuff is an example, I fully expect the vast majority of REFER applications to _not_ care about the results (e.g. blind transfer or similar). In this case, the implied subscription actually creates additional message overhead. If my assumption that the trivial case will be the most common proves correct, then the explicit-subscription-if-one-cares approach becomes the most efficient overall. Also, the explicit subscribe approach is a _good_ example of principle 3, to keep things separate so they can be recombined in new ways. This is in fact a creative combination of the separate mechanism of REFER and SUBSCRIBE. Finally (see, I will get all three principles in here) what we really have here is a transaction model where the results are determined asynchronously. This is a general problem which we are likely to see occur again with other extensions (and in fact we have in SIMPLE, with SUBSCRIBE/QAUTH). If I recall correctly (which is not a given) from early discussions, one of your early ideas for SUBSCRIBE/QAUTH was almost identical to this approach (i.e. explicit subscription for results). I think I opposed it then as too complex, but in light of the REFER issue, I see it's value. Thanks! Ben Campbell. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 16:31:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13247 for ; Fri, 29 Dec 2000 16:31:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A05D44375; Fri, 29 Dec 2000 15:31:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (cr288451-a.flfrd1.on.wave.home.com [24.112.91.149]) by lists.bell-labs.com (Postfix) with ESMTP id 7EB2344372 for ; Fri, 29 Dec 2000 15:30:27 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 29 Dec 2000 15:30:44 -0600 (CST) From: Billy Biggs To: Ben Campbell Cc: Jonathan Rosenberg , "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , SIP List , Sean Olson Subject: Re: [SIP] Solving the REFER retransmit issue Message-ID: <20001229153044.A311@div8.net> References: <9BF66EBF6BEFD942915B4D4D45C051F3B570@DYN-TX-EXCH-001.dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3B570@DYN-TX-EXCH-001.dynamicsoft.com>; from bcampbell@dynamicsoft.com on Fri, Dec 29, 2000 at 02:16:11PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 15:30:44 -0600 Ben Campbell (bcampbell@dynamicsoft.com): > I realize this creates additional message overhead in the case where > the REFER-or cares about the results. However, if present day PSTN > stuff is an example, I fully expect the vast majority of REFER > applications to _not_ care about the results (e.g. blind transfer or > similar). In this case, the implied subscription actually creates > additional message overhead. [...] Attended transfer (call handoff) is the primitve necessary for most advanced phone services. Say B is in a 3-way call: A C \ / B B needs to know when A has successfully contacted C so it can terminate its calls. In any reasonable phone system, the handoff has to be close to instantaneous. This is at odds with suggestions that: - B SUBSCRIBE'ing to A before getting back a response. - A sending a NOTIFY before a re-INVITE or BYE. - ... Please, consider implementation pain and message verbosity. -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 16:58:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA13464 for ; Fri, 29 Dec 2000 16:58:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2B4AE4437B; Fri, 29 Dec 2000 15:58:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 472D74437D for ; Fri, 29 Dec 2000 15:57:36 -0500 (EST) Received: from SUPERBEE ([63.110.3.128]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id RAA24385; Fri, 29 Dec 2000 17:00:04 -0500 (EST) From: "Ben Campbell" To: "'Billy Biggs'" , "Ben Campbell" Cc: "Jonathan Rosenberg" , "Henning G. Schulzrinne" , "Rohan Mahy" , "Robert Sparks" , "SIP List" , "Sean Olson" Subject: RE: [SIP] Solving the REFER retransmit issue Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3B573@DYN-TX-EXCH-001.dynamicsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20001229153044.A311@div8.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 15:54:39 -0600 Content-Transfer-Encoding: 7bit > From: Billy Biggs [mailto:billy@billybiggs.com] > Sent: Friday, December 29, 2000 3:31 PM > To: Ben Campbell > Cc: Jonathan Rosenberg; Henning G. Schulzrinne; Rohan Mahy; Robert > Sparks; SIP List; Sean Olson > Subject: Re: [SIP] Solving the REFER retransmit issue > > > Ben Campbell (bcampbell@dynamicsoft.com): > > > I realize this creates additional message overhead in the case where > > the REFER-or cares about the results. However, if present day PSTN > > stuff is an example, I fully expect the vast majority of REFER > > applications to _not_ care about the results (e.g. blind transfer or > > similar). In this case, the implied subscription actually creates > > additional message overhead. [...] > > Attended transfer (call handoff) is the primitve necessary for most > advanced phone services. Say B is in a 3-way call: I do not suggest that attended transfer is unimportant, merely that blind transfers will probably happen more often in the SIP world at large. While attended transfer is a primitive of advanced services, blind transfer is an extremely commonly used _simple_ service. I prefer to optimize for the simple case, and make the advanced case do a bit more work than the other way around. The timing expectations for an attended transfer may be tight, but they are even tighter for an unattended transfer. > > A C > \ / > B > > B needs to know when A has successfully contacted C so it can > terminate its calls. > > In any reasonable phone system, the handoff has to be close to > instantaneous. This is at odds with suggestions that: > > - B SUBSCRIBE'ing to A before getting back a response. > - A sending a NOTIFY before a re-INVITE or BYE. > - ... > > Please, consider implementation pain and message verbosity. > I did not see any proposal that said B _must_ wait for the notify to send a BYE. I suspect that would be a common implementation, but B _could_ send a bye immediately, then if it later received a NOTIFY indicating failure, it could notify the user, invite A to a new call, or whatever behavior makes the most sense in the situation. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 17:21:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13694 for ; Fri, 29 Dec 2000 17:21:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7108544383; Fri, 29 Dec 2000 16:21:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (cr288451-a.flfrd1.on.wave.home.com [24.112.91.149]) by lists.bell-labs.com (Postfix) with ESMTP id 5598044382 for ; Fri, 29 Dec 2000 16:20:11 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Fri, 29 Dec 2000 16:20:17 -0600 (CST) From: Billy Biggs To: Ben Campbell Cc: Jonathan Rosenberg , "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , SIP List , Sean Olson Subject: Re: [SIP] Solving the REFER retransmit issue Message-ID: <20001229162017.A390@div8.net> References: <20001229153044.A311@div8.net> <9BF66EBF6BEFD942915B4D4D45C051F3B573@DYN-TX-EXCH-001.dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3B573@DYN-TX-EXCH-001.dynamicsoft.com>; from bcampbell@dynamicsoft.com on Fri, Dec 29, 2000 at 03:54:39PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 16:20:17 -0600 Ben Campbell (bcampbell@dynamicsoft.com): > > Attended transfer (call handoff) is the primitve necessary for > > most advanced phone services. Say B is in a 3-way call: > > I do not suggest that attended transfer is unimportant, merely that > blind transfers will probably happen more often in the SIP world at > large. While attended transfer is a primitive of advanced services, > blind transfer is an extremely commonly used _simple_ service. I > prefer to optimize for the simple case, and make the advanced case do > a bit more work than the other way around. The timing expectations for > an attended transfer may be tight, but they are even tighter for an > unattended transfer. I want a BYE to indicate that no indication of success or failure will be sent, and a BYE from the referrer to indicate that no indication should be sent. This solves everything nicely. > I did not see any proposal that said B _must_ wait for the notify to > send a BYE. I suspect that would be a common implementation, but B > _could_ send a bye immediately, then if it later received a NOTIFY > indicating failure, it could notify the user, invite A to a new call, > or whatever behavior makes the most sense in the situation. That seems a little backwards. To me, the referred party should decide if it still wants to talk to the referrer. In my proposal, an INVITE with a 'Refer-Response' header indicates 'I'm done so please re-negotiate this session'. This is both explicit and simple. -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 17:29:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13742 for ; Fri, 29 Dec 2000 17:29:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 152464437F; Fri, 29 Dec 2000 16:29:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 580AE4437F for ; Fri, 29 Dec 2000 16:28:39 -0500 (EST) Received: from SUPERBEE ([63.110.3.128]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id RAA24551; Fri, 29 Dec 2000 17:31:07 -0500 (EST) From: "Ben Campbell" To: "'Billy Biggs'" , "Ben Campbell" Cc: "Jonathan Rosenberg" , "Henning G. Schulzrinne" , "Rohan Mahy" , "Robert Sparks" , "SIP List" , "Sean Olson" Subject: RE: [SIP] Solving the REFER retransmit issue Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3B574@DYN-TX-EXCH-001.dynamicsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20001229162017.A390@div8.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 16:25:43 -0600 Content-Transfer-Encoding: 7bit > > > I did not see any proposal that said B _must_ wait for the notify to > > send a BYE. I suspect that would be a common implementation, but B > > _could_ send a bye immediately, then if it later received a NOTIFY > > indicating failure, it could notify the user, invite A to a > new call, > > or whatever behavior makes the most sense in the situation. > > That seems a little backwards. To me, the referred party should > decide if it still wants to talk to the referrer. > > In my proposal, an INVITE with a 'Refer-Response' header indicates > 'I'm done so please re-negotiate this session'. This is both explicit > and simple. But not general. It seems to me to only make sense if the REFER is for a transfer, or at least as a result of an existing call leg. The SUBSCRIBE approach could be useful for any situation where the results of a request can not be determined in a specific (short) time period. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 17:36:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13800 for ; Fri, 29 Dec 2000 17:36:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3A6BE44378; Fri, 29 Dec 2000 16:36:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C178E44353 for ; Fri, 29 Dec 2000 16:35:35 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA24602 for ; Fri, 29 Dec 2000 17:38:06 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2650.21) id ; Fri, 29 Dec 2000 17:32:44 -0500 Message-ID: From: Jonathan Rosenberg To: "'sip@lists.bell-labs.com'" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: [SIP] new record-route text! Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 17:32:43 -0500 Folks, I took a stab at the new text for record routing. Its much, much more verbose than rfc2543, and hopefully, as a result, will make it much clearer what you need to do. Record-routing remains one of the most oft misimplemnted features. This text incorporates everything in rfc2543 plus all the decisions we've made on the list along the way. As you can see, the structure is much more processing focused, rather than syntactic focused, and much more explicit as well. The text is in latex format. If you don't know latex, you should be able to ignore all the slashes and brackets and still get the idea. Please comment; alternate text related to those comments is requested. -Jonathan R. \section{Record-Routing} \label{sec:rr} Record routing is the process whereby a proxy server can request to receive all messages between two UAs for a particular call leg. The proxy accomplishes this by inserting a header, called \header{Record-Route} into the initial \INVITE request that begins the call leg. The user agents use these headers to construct a set of \header{Route} headers, that gets inserted into subsequent requests in the call leg. The \header{Route} headers contain a set of proxies that the request must visit on its way from one UA to another. Proxies use these to forward the requests, much like strict IP source routing. All user agents \MUST support the processing rules below which apply to them. As such, they \MUST be able to parse and process both \header{Record-Route} and \header{Route} headers. Proxies \MAY support the record routing procedures of Section \ref{sec:rr:proxy}, but they \MUST support the route header procedures of Section{sec:rr:proxy2}. \motivation{This is a change from RFC2543, where all record-route and route processing was optional for user agents.} The syntax for the \header{Route} header is described in Section XXX. The syntax for the \header{Record-Route} header is described in Section XXX. \subsection{UAC Processing for initial \INVITE transaction} \label{sec:rr:uac} The UAC formulates its {\em initial} \INVITE request for the call leg as defined in section XXX. If the final response is a 200 class response, it may contain \header{Record-Route} headers, and may contain a \header{Contact} header. \annotate{Contact was not mandatory in RFC2543. Thus, if the UAC is talking to an older UAS, the UAS might not insert the \header{Contact} header. Thats why this text says that the \header{Contact} may be present in the response. Note also that this may is lower case; it is NOT saying that a UAS can optionally insert the \header{Contact} header into the 200 class response.} The UAC \MUST construct a {\em route set}, defined as a list of URLs, in the following manner: \begin{enumerate} \item The list of URIs present in the \header{Record-Route} headers in the 200 class response are taken, if present, and their order is reversed. \item The URI in the \header{Contact} header from the 200 class response, if present, is taken, and appended to the end of the list from the previous step. \item The list of URIs resulting from the above two operations is referred to as the {\em route set}. \end{enumerate} The UAC \MUST store the route set for the duration of the call leg. NOTE that it is possible for the route set to be empty. This will occur if neither \header{Record-Route} headers nor a \header{Contact} header were present in the 200 class response. NOTE that since there may be multiple 200 OK responses to an \INVITE request, each response constitutes a separate call leg, and thus has a separate route set. The UAC \MUST also remember whether the bottom-most entry in the route set was constructed from a \header{Contact} header or not. This is effectively a boolean value, which we refer to as CONTACT_SET. The \ACK request for the initial \INVITE transaction \MUST be formulated according to the rules of Section XXX, as if it were a subsequent request within the call leg. OPEN-ISSUE: Handling for non-200 responses, including provisionals and certain 400 class responses. Are we supporting record-routing for non-200 class responses? Record-routing for provisional responses is discussed in the 100rel spec. What needs to be said here? \subsection{UAS Processing of initial \INVITE transaction} \label{sec:rr:uas} When a UAS receives an \INVITE for a new call leg, and it responds with a 200 class response, it \MUST copy the contents of the \header{Record-Route} headers from the request to the response. This includes the URIs, URI parameters, and any \header{Record-Route} header parameters, whether they are known or unknown to the UAS. \annotate{Record-Route parameters are very useful for proxies. They allow the proxy to match the record-route entry in the response with the one in the request.} The order of the \header{Record-Route} headers \MUST be preserved in the response. The UAS \MUST construct a {\em route set} in the following manner: \begin{enumerate} \item The list of URIs in the \header{Record-Route} headers in the \INVITE request, if present, are taken, including any URI parameters. \item The URI in the \header{Contact} header from the request, if present, is taken, including any URI parameters. The URI is appended to the bottom of the list of URIs from the previous step. \item The resulting list of URIs is called the {\em route set}. \end{enumerate} The UAS \MUST store the route set for the duration of the call leg. NOTE that it is possible for the route set to be empty. This will occur if neither \header{Record-Route} headers nor a \header{Contact} header were present in the \INVITE request. The UAS \MUST also remember whether the bottom-most entry in the route set was constructed from a \header{Contact} header or not. This is effectively a boolean value, which we refer to as CONTACT_SET. OPEN ISSUE: this new text does not have the record-routes copied into non-200 responses. RFC2543 talks about other failure codes, but is not specific enough. Do we really need them in other response codes? If so, we must list them explicitly. \subsection{Proxy processing of an initial \INVITE transaction} \label{sec:rr:proxy} Each proxy \MAY independently decide to record-route an initial \INVITE transaction. For a proxy, {\em initial} is defined as any \INVITE request that does not contain a \header{Route} header. Generally, the choice about whether to record-route or not is a tradeoff of features vs. performance. Faster call processing and higher scalability is achieved when proxies do not record route. However, provision of certain services may require a proxy to observe all messages for a call leg. It is \RECOMMENDED that proxies do not automatically record route. They should do so only if specifically required. To record-route, the proxy inserts a \header{Record-Route} header into the request before proxying it onwards. A forking proxy \MAY insert a different \header{Record-Route} header into each forked request. The \header{Record-Route} header that it inserts \MUST be inserted as the first \header{Record-Route} header, appearing before any existing ones in the request. The URL in the header \MUST be a SIP URL. \annotate{This is because the URLs in the Record-Route headers are used for forwarding requests by other proxies. Since no other URL but a SIP URL is mandatory, a proxy could not be sure that any other URL is interpretable by other proxies. Thus, SIP URLs are mandatory}. The URL \MUSTNOT contain the transport parameter. \annotate{Thats because only UDP is mandatory. If a proxy inserts a transport parameter in the URL with TCP or TLS as the transport, the proxy that ends up using that URL to forward the request might not support that transport. The result, according to the ``Locating a SIP Server'' procedure, would be for the proxy to give up.} The URL \MUST have the property that when the processing described in Section XXX ``locaing a SIP server'' is followed for that URL, the result of the lookup is an address/port of the proxy server inserting the \header{Record-Route}. The URL and the proxy configuration \SHOULD be such that if a request is received with this URL in the \header{Request-URI}, the proxy's normal request processing will cause it to be forwarded to one of the previous-hop servers that the initial \INVITE request traversed, including the UAS. \annotate{These two properties are important. The first one guarantees that subsequent requests from the called party are routed back to this actually proxy. The second property is there for robustness. It guarantees that the request URI always contain meaningful information, even if there are no \header{Route} headers that tell the proxy where to forward the request to next.} The proxy \MAY insert \header{Record-Route} parameters into the request. These will be returned to the proxy in any 200 class response to the \INVITE, and are useful for pushing state into the message. If a 200 class response arrives for a proxied request, the response will contain the entire list of \header{Record-Route} headers inserted by proxies along the request path. The proxy \MAY modify the \header{Record-Route} value matching the one it inserted into the request. Like the URL in the request, it \MUST be a SIP URL and \MUSTNOT contain a transport parameter. The URL in this \header{Record-Route} header \MUST have the property that when the processing described in Section XXX ``locating a SIP server'' is followed for that URL, the result of the lookup is an address/port of the proxy server that inserted the \header{Record-Route}. The URL in this header, and the proxy configuration \SHOULD be such that if a request is received with this URL in the \header{Request-URI}, the proxy's normal request processing will cause it to be forwarded to the same next hop server that the initial \INVITE request was forwarded to. The four properties (two for the request, two for the response), can be satisfied in a number of ways. One way is that the URI inserted into the \header{Record-Route} in the request is the same as the \header{Contact} header in the \INVITE (if present, else the \header{From} field), but with the maddr and port set to resolve to the proxy. Then, the proxy modifies the URL in the \header{Record-Route} header in the response, setting it to be the URL from the \header{Request-URI} of the initial \INVITE, but with the maddr and port set to resolve to the proxy. As an example, consider a proxy at 10.0.1.1 listening on port 5061 which receives the following request (many headers are omitted for brevity): \begin{verbatim} INVITE sip:user@example.com SIP/2.0 Via: SIP/2.0/UDP callerspc.univ.edu Contact: sip:caller@callerspc.univ.edu \end{verbatim} The proxy forwards this request to \header{sip:j_user@div11.example.com}, and record-routes: \begin{verbatim} INVITE sip:j_user@div11.example.com SIP/2.0 Via: SIP/2.0/UDP 10.0.1.1:5061 Via: SIP/2.0/UDP callerspc.univ.edu Record-Route: Contact: sip:caller@callerspc.univ.edu \end{verbatim} The 200 response will look like, in part: \begin{verbatim} SIP/2.0 200 OK Via: SIP/2.0/UDP 10.0.1.1:5061 Via: SIP/2.0/UDP callerspc.univ.edu Record-Route: Contact: sip:j_user@host32.div11.example.com \end{verbatim} The proxy modifies its \header{Record-Route} header in the response to and forwards the request upstream: \begin{verbatim} SIP/2.0 200 OK Via: SIP/2.0/UDP callerspc.univ.edu Record-Route: ;myparam=9877 Contact: sip:j_user@host32.div11.example.com \end{verbatim} The route set computed by the UAS is: \begin{verbatim} sip:caller@callerspc.univ.edu:5061;maddr=10.0.1.1 sip:caller@callerspc.univ.edu \end{verbatim} and the route set computed by the UAC is: \begin{verbatim} sip:j_user@example.com:5061;maddr=10.0.1.1 sip:j_user@host32.div11.example.com \end{verbatim} There are other ways to meet these requirements. The proxy could construct a URL for the request which encodes all of the needed information, by placing it in the user portion, for example. A call stateful proxy could insert a URL into the request with the form sip:proxy.example.com, and not modify it in the response. This URL clearly satisfies the first required property (of getting routed back to the proxy that inserted it). The second property can be maintained by being call stateful, and extracting the needed parameters from local storage. When a proxy does decide to modify the \header{Record-Route} header in the response, one of the operations it must perform is to locate the \header{Record-Route} that it had inserted. If the request spiraled, and the proxy inserted a \header{Record-Route} in each iteration of the spiral, locating the correct header in the response (which must be the proper iteration in the reverse direction) is tricky. One mechanism that is \RECOMMENDED is for the proxy to insert a \header{Record-Route} parameter into the new \header{Record-Route} header in the request each time the request spirals. This parameter \MUST uniquely identify the proxy. When the 200 class respone arrives, the proxy looks for the topmost \header{Record-Route} header containing this parameter. This header is the one for the current iteration. The proxy \MUST remove this parameter before forwarding the response upstream. Upon the next iteration, the same algorithm (find the topmost \header{Record-Route} header with the parameter) will correctly extract the next \header{Record-Route} header. \subsection{UA Processing of Subsequent Requests in a Call Leg} \label{sec:rr:uasubsequent} When a UA wishes to send another request for the call-leg (such as a \header{BYE} or \header{INVITE}), it follows the procedures defined in this subsection. The procedures here \MUST also be followed for an \ACK request for a 200 response to the initial \INVITE for the call leg. The procedures here \MUSTNOT be followed for a \CANCEL request or an \ACK request for a non-200 response. This implies that \CANCEL never contains a \header{Route} header, nor does an \ACK for a non-200 response. The request is constructed as specified in Section XXX. The UA then takes the list of URI in the route set. The top URI is inserted into the request URI of the request, including all parameters. Any URI parameters not allowed in the request URI \MUST then be stripped. Each of the remaining URIs (if any) from the route set, including any URI parameters, are placed into a \header{Route} header into the request, in order. The procedures of Section XXX ``locating a SIP server'' are then applied to the URI in the request URI, the the request is forwarded to the resulting server. If a UAS has a route set for a call leg, and receives a re-INVITE for that call leg containing \header{Record-Route} headers, it \MUST copy those headers into any 200 class response to that request. If the boolean variable CONTACT_SET is true, the \header{Contact} header in the re-INVITE (if present) replaces the last entry in the route set. If the boolean variable CONTACT_SET is false, the UAS \MUST add the URL in the \header{Contact} header in the re-INVITE to the bottom of the route set, and then set CONTACT_SET to true. If the re-INVITE did not contain a \header{Contact} header, the route-set at the UAS remains unchanged. Similarly, if a UAC has a route set for a call leg, and receives a 200 class response to a re-INVITE it sent, the \header{Contact} header is examined. If not present, the route set remains unchanged. If the re-INVITE response had a \header{Contact} header, and the boolean variable CONTACT_SET is false, the URL in the \header{Contact} header in the response is added to the bottom of the route set, and CONTACT_SET is set to true. If the re-INVITE response had a \header{Contact} header, and CONTACT_SET is true, the URL in the \header{Contact} header of the re-INVITE response replaces the bottom value in the route set. The above two paragraphs allow a UA to update its \header{Contact} address mid-call, but proxies cannot update their route address. Once on the route, a proxy remains on the route for the duration of the call leg. \annotate{Why the different treatment for Contact and Record-Route in a re-INVITE? It has to do with backwards compatibility. RFC2543 did not mandate that a proxy needs to refresh its record-route headers. As a result, the lack of a record-route in a re-INVITE cannot be interpreted to mean that the proxy does not want to be included on the route any longer. Updating of the Contact header mid-call is useful for mobility applications, and is also useful for forms of third party call control}. OPEN-ISSUE: should the UA remove the maddr param, if present, if the request is sent to the server at that maddr? OPEN-ISSUE: should we mention handling of route with local outbound proxies here? RFC2543 has some text on DNS-less UAs, but there are issues with this. \header{Proxy processing of a non-initial request} \label{sec:rr:proxy2} The rules in this section \MUST be followed when a proxy receives a request that contains a \header{Route} header. The \header{Route} header is used to forward the request to the next hop. It \MUST override any other routing decisions that the proxy would otherwise make. Proxies \MAY respond to requests with \header{Route} headers for any reason (in order to perform proxy authorization, for example). But, if the request is proxied, the procedures here \MUST be used to determine where the request is proxied to. The procedures in this section apply indepedent of the request method. They \MUST be followed even if the request method is unknown to the proxy. \annotate{This last sentence is really, really important. It allows for other methods, defined in the future, to have record-routing applied to them. As an example, an instant messaging session run over SIP might begin with a MESSAGE request. That extension can allow for these sessions to be record-routed by proxies that know of this extension. However, the record-routing will only work if proxies that don't know about the extension follow the Route headers properly. As such, supporting \header{Route} headers for all methods, known or unknown, is very important for a robust and future proof proxy implementation.} Since \CANCEL can never contain \header{Route}, these procedures never apply to \CANCEL. However, they do apply to \ACK requests for a 200 OK response, which do contain \header{Route} headers. The proxy \MUST remove the top \header{Route} header from the request. The URI from that \header{Route} \MUST be placed into the \header{Request-URI} of the proxied request, including URI parameters. Any URL parameters present in the top \header{Route} header which are not allowed in the request URI \MUST be removed from the \header{Request-URI} by the proxy. The procedures of section XXX ``Locating a SIP Server'' \MUST be followed to compute the next hop server to forward the request to. If the request is an \INVITE request (thus, a re-INVITE) for a call leg that the proxy wishes to receive messages for (very likely the case, since the request probably arrived at the proxy because the proxy record routed in the initial \INVITE), the proxy \MUST re-insert the \header{Record-Route} header with the same value it placed in the initial request. Similarly, it should modify the \header{Record-Route} header in any 200 class response in the same way the \header{Record-Route} header was modified in the response to the initial \INVITE (which may be no modifications at all). The purpose of this is twofold. First, it allows for proper record-routing in the case of pre-loaded Route headers (see Section XXX). Secondly, it allows for recovery from a UA crash and restart, in which case the UA loses call state, and as a result, its route set as well. The result is that the route set will be re-established through the re-INVITE. When coupled with the Session Timer \cite{RFCXXX}, the result is a robust way to recover from crashes. \subsection{Pre-Loaded Route Headers} Normally, a UA constructs the Route headers in a request from the route set learned through \header{Record-Route} headers. However, in some circumstances, it is useful for a UA to insert \header{Route} headers into an initial \INVITE. These headers may have been learnt by the UA through some out of bands means. When an initial \INVITE (initial as far as the UAC and UAS are concerned) contains \header{Route} headers, this is referred to as a ``pre-loaded Route''. It is equivalent to strict source routing in IP. Proxies will often not be able to distinguish this case from the case described in Section \ref{sec:rr:proxy}, and will therefore properly use these route headers to forward the request. If the proxies are interested in receiving subsequent messages for the call leg, their insertion of \header{Record-Route} as mandated by Section \ref{sec:rr:proxy} will establish a correct route set at both UAC and UAS. This route set may end up being different from the pre-loaded Route used by the UAC. As such, a UAC that inserts a pre-loaded route set \MUST follow the procedures of Section \ref{sec:rr:uac} in processing the response to this initial \INVITE. --- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Fri Dec 29 22:39:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA17100 for ; Fri, 29 Dec 2000 22:39:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8C50444337; Fri, 29 Dec 2000 21:39:14 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id CCB9944336 for ; Fri, 29 Dec 2000 21:38:37 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA26332; Fri, 29 Dec 2000 22:38:26 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA20794; Fri, 29 Dec 2000 22:38:22 -0500 (EST) Message-ID: <3A4D8224.A733BF53@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: "'sip@lists.bell-labs.com'" Subject: Re: [SIP] new record-route text! References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 22:35:16 -0800 Content-Transfer-Encoding: 7bit # Comments are marked thusly; not meant as text. # In general, some of the Route stuff needs to be copied or moved in the general discussion of request routing. I'd like to keep those core rules in one place rather than having to hunt around for all the different decisions on where to send things. > \section{Record-Routing} # This should state what we're trying to accomplish, not the means, e.g., \section{Forcing Request Routes} > \label{sec:rr} # adding motivation and context By default, all but the first request within a call leg are exchanged directly between the UAC and the UAS. However, in some circumstances, some proxies may need to process all requests within a call leg, not just the first one. This is accomplished by a set of SIP header fields and processing rules for proxies, UAS and UAC. We will refer to this set of rules as ``record-routing''. > > Record routing is the process whereby a proxy server can request to > receive all requests between two UAs for a # changed from messages to requests, since responses don't need this mechanism > particular call leg. The proxy accomplishes this by inserting a > header, called header field > \header{Record-Route} into the initial \INVITE request that begins the > call leg. The user agents use these headers to construct a set of > \header{Route} headers, that gets inserted into subsequent requests in that the UAC inserts into > the call leg. The \header{Route} headers contain a set of proxies that header fields list the URLs of proxies > the request must visit on its way from one UA to another. Proxies use > these to forward the requests, much like strict IP source routing. Proxies use these URLs > > All user agents \MUST support the processing rules below which apply > to them. As such, they \MUST be able to parse and process both > \header{Record-Route} and \header{Route} headers. Proxies \MAY support > the record routing procedures of Section \ref{sec:rr:proxy}, but they > \MUST support the route header procedures of Section{sec:rr:proxy2}. > > \motivation{This is a change from RFC2543, where all record-route and > route processing was optional for user agents.} > > The syntax for the \header{Route} header is described in Section > XXX. The syntax for the \header{Record-Route} header is described in > Section XXX. # Something should be said here about non-INVITE requests, if only to answer the obvious question, e.g. The record-routing mechanism only applies to {\INVITE} transactions. Inserting \header{Record-Route} in requests other than {\INVITE} is {\NOTALLOWED}. # Some overview of the cases below, e.g., Below, Section~\ref{sec:rr:uac} discusses how UAC process the first {\INVITE} request within a call leg. Section ... # probably should group sections below into initial and subsequent requests # remainder omitted for later _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 01:48:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22524 for ; Sat, 30 Dec 2000 01:48:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A8D244337; Sat, 30 Dec 2000 00:48:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lists.bell-labs.com (Postfix) with ESMTP id 34DB944338 for ; Fri, 29 Dec 2000 17:31:42 -0500 (EST) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id eBTNTo120382; Fri, 29 Dec 2000 15:29:50 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id eBTNUhb16476; Fri, 29 Dec 2000 15:30:43 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569C4.00814FF2 ; Fri, 29 Dec 2000 15:32:26 -0800 X-Lotus-FromDomain: 3COM From: Jacek_Grabiec@3com.com To: sip@lists.bell-labs.com Cc: billy@billybiggs.com, hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, rfairlie@nuera.com, jhornsby@ubiquity.net, vkg@lucent.com Message-ID: <882569C4.00814F5C.00@hqoutbound.ops.3com.com> Subject: [SIP] Proxy Routing Logic Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 17:33:26 -0600 I'm joining late this discussion, so I've split my comments into several postings. Henning Schlzrinne wrote: >Vijay Gurbani wrote: >> >> Billy Biggs wrote: > > > > > > If a proxy at proxy.com receives a request with a Request-URI of: > > > > > > sip:abc@someone-else.com;maddr=proxy.com > > > > > > Should the proxy: > > > > > > 1. Return a 404. > > > 2. Proxy the message to abc@someone-else.com, ditching the maddr > > > parameter. > > > > I suppose that if the proxy is reasonably sure that DNS resolution of > > proxy.com will not resolve to another proxy in that domain, it should do (1). >As before, it's up to the proxy. If there's some weird reason that a >proxy publishes these addresses, it might handle this. An outbound >proxy, for example, would be represented by something like that. If the >proxy has no intent of proxying random requests, it has the right to >send back > >404 Huh? I would argue that although it is in fact recommended behavior (replying with 404 if the host part of received RURI doesn't match any of the domains served by the proxy - see paragraph 7.4.5) it is not a desired one. 404 implies that such a user doesn't exist - e.g. the address is mistyped or something. Why would a proxy that doesn't serve a particular domain have a say if a user exist or not? I'm not saying however that the Proxy has to forward the message on (in this case to 'someone-else.com' with RURI of sip:abc@someone-else.com) - as pointed by Henning it may not be willing and/or able to do so. But it should return something like 488 Not Acceptable Here (and possibly adding some info where 'here' is). > > > > > Now say there is a populated Route header. Should the proxy: > > > > > > 1. Replace the Request-URI with the first Route and proxy. > > > 2. Return a 404. > > > 3. Proxy the message to abc@someone-else.com, ditching the maddr > > > parameter (and not popping the Route). > > > > Isn't (1) the normal behavior? If a proxy gets a new request with Route > > headers, it pops the top one off and uses it as the R-URI of the next hop > > downstream server. Or am I missing something in your question? > >I suspect this is about having "weird" URIs in the Route, such as the >one above. Again, an outbound proxy could actually see something like >that (more reasonable than above). In that case, (1) is the right >behavior. again, I would argue it is (case 1) not a corect behavior. Here is an example: proxy.com is my outbound proxy and a Route header (let's say sip: route-through-someone-else.com without going into specific syntax) indicates an address that can be reached only through someone-else.com proxy (like non routable IP-address). If proxy.com blindly replaces original RURI with first Route (as also proposed in some of the postings in this thread) and thus forgetting about someone-else.com altogether, the request will never get to the intended destination. Therefore I would think behavior 3 is the correct one. regards, Jacek Grabiec sip:jacek_grabiec@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 01:49:15 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22708 for ; Sat, 30 Dec 2000 01:49:15 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E00D64434D; Sat, 30 Dec 2000 00:48:34 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lists.bell-labs.com (Postfix) with ESMTP id 51F8844338 for ; Fri, 29 Dec 2000 17:36:15 -0500 (EST) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id eBTNYO120579; Fri, 29 Dec 2000 15:34:24 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id eBTNZMb16609; Fri, 29 Dec 2000 15:35:22 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569C4.0081BE37 ; Fri, 29 Dec 2000 15:37:08 -0800 X-Lotus-FromDomain: 3COM From: Jacek_Grabiec@3com.com To: sip@lists.bell-labs.com Cc: billy@billybiggs.com, hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, rfairlie@nuera.com, jhornsby@ubiquity.net, vkg@lucent.com Message-ID: <882569C4.0081BD48.00@hqoutbound.ops.3com.com> Subject: [SIP] Proxy Routing Logic Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 17:38:10 -0600 Jonathan Rosenberg wrote > > -----Original Message----- > > From: Keith Robinson [mailto:Keith.Robinson@marconi.com] > >Sent: Monday, December 18, 2000 6:01 AM > >To: Billy Biggs > >Cc: SIP List > >Subject: Re: [SIP] Proxy Routing Logic >> >> >> >> > >For the first case, couldn't this be the result of a roaming > >UA using source > >routing to get the > >initial INVITE to its home domain proxy to do the actual > >routing (perhaps the > >user has > >originating call features registered that they wish to use); > >in which case I > >would expect the > >behaviour in 2 to take place. >In this case, I don't think the roaming user would construct the URI in this >fashion. Rather, it would use a Route header to accomplish this task. Is that a recommended behavior - using Route versus maddr? That may be a better way but it is not intuitive at all. Check any available SIP User Agent - I have yet to see one that would convert typed in (or clicked on) RURI of sip:jdrosen@dynamicsoft.com;maddr=local.proxy.com into RURI=sip:local.proxy.com, ... Route=sip:jdrosen@dynamicsoft.com (pardon my syntax) which is what is implied (I think). Another problem occurs when jdrosen@dynamicsoft.com registered at the proxy with contact of 'sip:jdrosen@dynamicsoft.com;maddr=local.proxy.com'. If the Proxy gets INVITE with RURI of jdrosen@dynamicsoft.com then it will find the appropriate contact and proxy the message to RURI=sip:local.proxy.com, ... Route=sip:jdrosen@dynamicsoft.com. But according to Table5 of the spec the Proxy is not even allowed to insert Route header on its own. > >That aside, there is an important issue here. When using a local outbound >proxy, you most definitely do NOT want to set the maddr parameter in the >request URI to point to that proxy. This is confusing, since you would want >the URL to have the maddr parameter outside of the context of the request >URI. >Specifically, lets say I want to have a URL in a web page that causes people >to call me through some local proxy. That URL in the web page would look >like: > >sip:jdrosen@dynamicsoft.com;maddr=local.proxy.com > >This URI would not be inserted directly into the request URI, however. That >maddr needs to be stripped. Although it is a valid proposal I think there are some cases where the maddr cannot be stripped. If my UAC cannot resolve domain names and maddr is local.proxy.com and my outbound proxy is always 111.111.111.111 I do not know if 111.111.111.111 and local.proxy.com are the same so I would have to include maddr in the RURI. So the point is proxy can receive a request where maddr of RURI actually does match proxy itself and there has to be a way/rule to process such a message properly. The whole subject of this thread is to make this processing not confusing. > >So, I propose we add some text to the spec somewhere along these lines: "The >maddr parameter should be present in the Request URI only if the server the >request is sent to is not the one in the maddr parameter.". Probably this >can be better phrased. That is certainly a good idea but again, Proxy must be able to deal with RURI that would not follow that rule. >-Jonathan R. regards, Jacek Grabiec sip:jacek_grabiec@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 01:50:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA22962 for ; Sat, 30 Dec 2000 01:50:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F2E7944350; Sat, 30 Dec 2000 00:48:53 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lists.bell-labs.com (Postfix) with ESMTP id 2FC0344338 for ; Fri, 29 Dec 2000 17:40:09 -0500 (EST) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id eBTNcJ120871; Fri, 29 Dec 2000 15:38:19 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id eBTNdHb16753; Fri, 29 Dec 2000 15:39:17 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569C4.00821A41 ; Fri, 29 Dec 2000 15:41:04 -0800 X-Lotus-FromDomain: 3COM From: Jacek_Grabiec@3com.com To: sip@lists.bell-labs.com Cc: billy@billybiggs.com, hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, rfairlie@nuera.com, jhornsby@ubiquity.net, vkg@lucent.com Message-ID: <882569C4.008219F5.00@hqoutbound.ops.3com.com> Subject: [SIP] Proxy Routing Logic Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 17:42:06 -0600 Jonathan Rosenberg wrote: >> -----Original Message----- > >From: Billy Biggs [mailto:Billy_Biggs@3com.com] > >Sent: Wednesday, December 20, 2000 12:54 PM > >To: Jo Hornsby > >Cc: Fairlie-Cuninghame, Robert; Jonathan Rosenberg; Keith > >Robinson; SIP > >List > >Subject: Re: [SIP] Proxy Routing Logic > > > > > >Jo Hornsby (jhornsby@ubiquity.net): > > > >>>> [Of course there will be always be different routing behaviour > >>>> depending on whether the request has a Route or not. [...] > >>> > >>> Right, but this decision should only occur after you've > >decided if > >>> the request is for you. It's very important that proxies > >don't just > >>> assume the request is meant for them if it happens to appear on one > >>> of their listening sockets. [...] > >> > > >Maybe I'm not following properly, since I'm jumping in > >mid-stream, as > >> it were, but if I get a request, I'm going to do my best to > >honour it. > >> Maybe I won't know anything about the domain in the Request-URI, but > > >I'll SRV and A, and hopefully everything will still be okay. > > > > By "honour it" you mean proxy it to the destination indicated by the > >Request-URI (and maybe add a Record-Route), right? > . > > I just want to make sure proxies don't replace the > >request-URI blindly > >with the next Route unless the request is destined for them. >I believe they should do this, in fact. >Note that Jo and Robert are correct; consensus was that if a local outbound >proxy wants to stay on the path, it should record-route. This results in the >most flexibility (enables outbound proxies who want to see only the initial >request). If that is the consensus for what outbound proxy is then the 'outbound proxy' the way I understood it ceases to exist. First, it is UAC who makes a given Proxy its outbound one. that is, 'outbound functionality' is not something you can enable/disable on the Proxy. Moreover, not only there should not be a different behavior for outbound proxies versus non-outbound, there cannot be since the Proxy has no way of knowing if it is being used as outbound one or not (maybe with the exaption of so called firewall proxies that most likely are used as outbound proxies only - but even that may not always be the case). On the side note: you cannot require outbound proxy to insert Record-Route (I think I saw posting recommending this) for that exact reason - since every Proxy can potentially be used as the outbound one every one would have to insert Record-Route. My UAC uses proxy name-resolutions.com for every outgoing request for just that reason: to resolve domain names on my behalf. I have to use for all outgoing requests since the maddr in Record-Route (and therefore in Route as well) may contain domain name. My second UAC uses proxy free-gifts.com as the outbound one for every outgoing request since I can win a gift every time I use it. There are many reasons why I would want to use an outbound Proxy and I expect everything to work regardless of whether my outbound Proxy adds Record-Route or not. regards, Jacek Grabiec sip:jacek_grabiec@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 01:52:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23201 for ; Sat, 30 Dec 2000 01:52:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D8FFA44359; Sat, 30 Dec 2000 00:49:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from topaz.3com.com (topaz.3com.com [192.156.136.158]) by lists.bell-labs.com (Postfix) with ESMTP id C739644338 for ; Fri, 29 Dec 2000 17:42:32 -0500 (EST) Received: from opal.3com.com (opal.3com.com [139.87.50.117]) by topaz.3com.com (Switch-2.0.1/Switch-2.0.1) with ESMTP id eBTNeg120988; Fri, 29 Dec 2000 15:40:42 -0800 (PST) Received: from hqoutbound.ops.3com.com (hqoutbound.OPS.3Com.COM [139.87.48.104]) by opal.3com.com (Switch-2.0.1/Switch-2.0.1) with SMTP id eBTNfeb16862; Fri, 29 Dec 2000 15:41:40 -0800 (PST) Received: by hqoutbound.ops.3com.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 882569C4.00825297 ; Fri, 29 Dec 2000 15:43:28 -0800 X-Lotus-FromDomain: 3COM From: Jacek_Grabiec@3com.com To: sip@lists.bell-labs.com Cc: billy@billybiggs.com, hgs@cs.columbia.edu, jdrosen@dynamicsoft.com, rfairlie@nuera.com, jhornsby@ubiquity.net, vkg@lucent.com Message-ID: <882569C4.008251BE.00@hqoutbound.ops.3com.com> Subject: [SIP] Proxy Routing Logic Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Fri, 29 Dec 2000 17:44:27 -0600 Jonathan Rosenberg wrote: >> -----Original Message----- > >From: Billy Biggs [mailto:Billy_Biggs@3com.com] > >Sent: Wednesday, December 20, 2000 12:54 PM > >To: Jo Hornsby > >Cc: Fairlie-Cuninghame, Robert; Jonathan Rosenberg; Keith > >Robinson; SIP > >List > >Subject: Re: [SIP] Proxy Routing Logic > > > > > >Jo Hornsby (jhornsby@ubiquity.net): > > > >>>> [Of course there will be always be different routing behaviour > >>>> depending on whether the request has a Route or not. [...] > >>> > >>> Right, but this decision should only occur after you've > >decided if > >>> the request is for you. It's very important that proxies > >don't just > >>> assume the request is meant for them if it happens to appear on one > >>> of their listening sockets. [...] > >> > > >Maybe I'm not following properly, since I'm jumping in > >mid-stream, as > >> it were, but if I get a request, I'm going to do my best to > >honour it. > >> Maybe I won't know anything about the domain in the Request-URI, but > > >I'll SRV and A, and hopefully everything will still be okay. > > > > By "honour it" you mean proxy it to the destination indicated by the > >Request-URI (and maybe add a Record-Route), right? > . > > I just want to make sure proxies don't replace the > >request-URI blindly > >with the next Route unless the request is destined for them. >I believe they should do this, in fact. >Note that Jo and Robert are correct; consensus was that if a local outbound >proxy wants to stay on the path, it should record-route. This results in the >most flexibility (enables outbound proxies who want to see only the initial >request). >The more interesting issue is when a local outbound proxy record routes. As >you pointed out, the RR inserted might look like: >sip:jdrosen@dynamicsoft.com;maddr=outbound.proxy.com I'm inclined to agree with Billy: maybe we should revisit the idea of including RURI of received requests in Record-Route. It was a good idea to get around the problem of forwarding requests if no Contact was added by UA. Even then the RURI part was used in one direction only. Now, since all UA are required to add Contact adding RURI to Record-route doesn't seem to be necessary (obviously I may be missing something) and ditching it would simplify a lot, including solving potential loop problems. >However, as we pointed out before, if that proxy received this exact URI >*without* the next Route header, this would result in a loop. Billy >indicated he didn't want different routing of the request URI dependent on >the presence of Route. I agree completely, and have been arguing for this >property in Route all along. >A few solutions are possible: >1. If you send a request to a URI that contains an maddr, and you end up >sending it to the address in that maddr, strip the maddr out before sending >the request. >2. THe proxy should never had inserted this RR in the first place, since >using it directly will cause a loop. Rather, something like Robert's >suggestion would be used: >sip:outbound.proxy.com;uri=jdrosen@dynamicsoft.com. >-Jonathan R. regards, Jacek Grabiec sip:jacek_grabiec@sip.3com.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 09:05:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA01977 for ; Sat, 30 Dec 2000 09:05:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4ED244433F; Sat, 30 Dec 2000 08:05:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailweb7.rediffmail.com (unknown [202.54.124.152]) by lists.bell-labs.com (Postfix) with SMTP id C090244336 for ; Sat, 30 Dec 2000 02:14:53 -0500 (EST) Received: (qmail 14757 invoked by uid 510); 30 Dec 2000 08:13:22 -0000 Message-ID: <20001230081322.14756.qmail@mailweb7.rediffmail.com> Received: from unknown (203.197.21.84) by rediffmail.com via HTTP; 30 Dec 2000 08:13:22 -0000 MIME-Version: 1.0 To: "sip@lists.bell-labs.com." From: "Ashhar Farhan" Content-ID: Content-type: text/plain Content-Transfer-Encoding: 7bit Subject: [SIP] a tiny binary sip proxy protocol Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: 30 Dec 2000 08:13:22 -0000 Content-Transfer-Encoding: 7bit i am proposing a very easily implemented, binary level protocol that can easily translate to and from sip signalling. the protocol is right now called STP (Sip's Tiny Proxy). the protocol has the following features: 1. it can painlessly traverse SOCKS 5 proxies, NAT and other forms of proxy like WinSock. It uses in-band signalling so that a single port on proxies and firewalls is used for both streaming as well as signalling. This is an issue of immense importance currently. Most of the people who have an always on presence on the Net are usually behind a proxy of some sort. 2. the signalling uses binary structures that can be directly read into C structures eliminating the need of costly parsers. This leads to a loss of many facilities inherent in SIP. This is by design. It is a cut down protocol that can easily translate to SIP through a gateway. 3. All the signalling messages are handled uniformly (retransmit until response or time-out). forking is not allowed. INVITE and ACK are replaced with RING and ANSWER (as two separate messages). 4. No call parameter renegotiation is allowed. here is the signalling structure: #define CMD_LOGIN 1 #define CMD_NEWUSER 2 #define CMD_RING 3 #define CMD_ANSWER 4 #define CMD_MSG 5 #define CMD_HANGUP 6 #define CMD_CANCEL 7 #define CMD_LOGOUT 8 #define CMD_REFUSE 9 #pragma pack(1) #define MAX_USERID 64 #define RTP_PORT 5004 struct stp { short version; short command; short response; char to[MAX_USERID]; char from[MAX_USERID]; int session; int msgid; char authenticate[16]; int contactIp; short contactPort; char body[]; }; Notes: 1. Works exclusively on UDP port (randomly chosen). 2. The body field extends to the length of the udp packet. 3. the session id is mapped to the ssrc of rtp. 4. requests have a 0 in the response field. 5. userid consists of userid@host. The port for signalling is same as the port for streaming. 6. If contact Ip and contact port are zero, then use the ip address from where the packet arrived for further communications. 7. current version is 1. 8. responses are as per SIP definitions. 9. Only MD5 authentication is used. 10. msgid should be unique throughout the session. 11. A new registration is created if the email is sent in the data field. 12. the proposed port for STP servers is 5061. I have been off the list for the past few months refining and simplifying the protocol and i believe that it is a sufficient protocol to ensure easy translation to and from sip while at the same time solving the problems of NAT, SOCKS 5 interoperability as well as small footprints. - farhan@hotfoon.com _____________________________________________________ Chat with your friends as soon as they come online. Get Rediff Bol at http://bol.rediff.com _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 10:02:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA02115 for ; Sat, 30 Dec 2000 10:02:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 99BED4433F; Sat, 30 Dec 2000 09:02:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (cr288451-a.flfrd1.on.wave.home.com [24.112.91.149]) by lists.bell-labs.com (Postfix) with ESMTP id 9239644337 for ; Sat, 30 Dec 2000 09:01:25 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sat, 30 Dec 2000 10:01:22 -0500 (EST) From: Billy Biggs To: Ben Campbell Cc: Jonathan Rosenberg , "Henning G. Schulzrinne" , Rohan Mahy , Robert Sparks , SIP List , Sean Olson Subject: Re: [SIP] Solving the REFER retransmit issue Message-ID: <20001230100122.A1269@div8.net> References: <20001229162017.A390@div8.net> <9BF66EBF6BEFD942915B4D4D45C051F3B574@DYN-TX-EXCH-001.dynamicsoft.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <9BF66EBF6BEFD942915B4D4D45C051F3B574@DYN-TX-EXCH-001.dynamicsoft.com>; from bcampbell@dynamicsoft.com on Fri, Dec 29, 2000 at 04:25:43PM -0600 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 30 Dec 2000 10:01:22 -0500 Ben Campbell (bcampbell@dynamicsoft.com): > > In my proposal, an INVITE with a 'Refer-Response' header indicates > > 'I'm done so please re-negotiate this session'. This is both > > explicit and simple. > > But not general. It seems to me to only make sense if the REFER is for > a transfer, or at least as a result of an existing call leg. The > SUBSCRIBE approach could be useful for any situation where the results > of a request can not be determined in a specific (short) time period. Using REFER to do anything other than transfer turns it into a control protocol. Using REFER outside of an existing call leg doesn't make sense. -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 11:12:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA02377 for ; Sat, 30 Dec 2000 11:12:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 346484433F; Sat, 30 Dec 2000 10:12:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E24F044337 for ; Sat, 30 Dec 2000 10:10:59 -0500 (EST) Received: from SUPERBEE (dsl081-162-189-sea1.dsl-isp.net [64.81.162.189]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with SMTP id LAA25759; Sat, 30 Dec 2000 11:13:02 -0500 (EST) From: "Ben Campbell" To: "'Billy Biggs'" , "Ben Campbell" Cc: "Jonathan Rosenberg" , "Henning G. Schulzrinne" , "Rohan Mahy" , "Robert Sparks" , "SIP List" , "Sean Olson" Subject: RE: [SIP] Solving the REFER retransmit issue Message-ID: <9BF66EBF6BEFD942915B4D4D45C051F3B576@DYN-TX-EXCH-001.dynamicsoft.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 CWS, Build 9.0.2416 (9.0.2910.0) Importance: Normal In-Reply-To: <20001230100122.A1269@div8.net> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 30 Dec 2000 10:07:23 -0600 Content-Transfer-Encoding: 7bit The current REFER draft very specifically does not require a call leg context. That is a different argument than this one entirely. If we wish to change that, we can, but until we choose to do so, the solution to the retransmit problem should not restrict this usage. > -----Original Message----- > From: Billy Biggs [mailto:billy@billybiggs.com] > Sent: Saturday, December 30, 2000 9:01 AM > To: Ben Campbell > Cc: Jonathan Rosenberg; Henning G. Schulzrinne; Rohan Mahy; Robert > Sparks; SIP List; Sean Olson > Subject: Re: [SIP] Solving the REFER retransmit issue > > > Ben Campbell (bcampbell@dynamicsoft.com): > > > > In my proposal, an INVITE with a 'Refer-Response' > header indicates > > > 'I'm done so please re-negotiate this session'. This is both > > > explicit and simple. > > > > But not general. It seems to me to only make sense if the > REFER is for > > a transfer, or at least as a result of an existing call leg. The > > SUBSCRIBE approach could be useful for any situation where > the results > > of a request can not be determined in a specific (short) > time period. > > Using REFER to do anything other than transfer turns it > into a control > protocol. Using REFER outside of an existing call leg doesn't make > sense. > > -- > Billy Biggs bbiggs@dumbterm.net > http://www.billybiggs.com/ wbiggs@uwaterloo.ca > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 17:30:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA03498 for ; Sat, 30 Dec 2000 17:30:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8FE0F44351; Sat, 30 Dec 2000 16:30:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 59F954433F for ; Sat, 30 Dec 2000 16:29:05 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA06370; Sat, 30 Dec 2000 17:28:43 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA23444; Sat, 30 Dec 2000 17:28:39 -0500 (EST) Message-ID: <3A4E8CBB.FCA767A0@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jacek_Grabiec@3com.com Cc: sip@lists.bell-labs.com, billy@billybiggs.com, jdrosen@dynamicsoft.com, rfairlie@nuera.com, jhornsby@ubiquity.net, vkg@lucent.com Subject: Re: [SIP] Outbound proxy (was: proxy routing logic) References: <882569C4.008219F5.00@hqoutbound.ops.3com.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 30 Dec 2000 17:32:43 -0800 Content-Transfer-Encoding: 7bit I think it is somewhat simpler to decouple the notion of outbound proxies from the RR functionality. I have a hard time picturing a case where an outbound proxy would only want to be in the path of the first request. It seems simple, and in line with current implementations and the DHCP draft, so An additional complication is that RR is currently being defined for INVITE and BYE only, while outbound proxies generally would be for every request. Basically saying "outbound proxy is for all requests but the requests that are within a call leg" seems a bit odd. However, it does mean that the outbound proxy is the one that actually uses the first Route header. Things could get a bit odd if things are configured so that the outbound proxy is not the one "closest" to the inside party. For example, you could have a call through acme.com and then sales.acme.com reaching Bob@sales.acme.com. If acme.com is the outbound proxy and sales.acme.com record-routes for the inbound call, routing gets strange. There's probably not much one can do here except say "don't do that". Also note, in practice, the species of outbound proxy that we have seen so far (firewall proxies) will almost always have to RR in order to make sure that requests from the outside traverse it. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 20:40:03 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA03936 for ; Sat, 30 Dec 2000 20:40:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5F5504433F; Sat, 30 Dec 2000 19:40:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (cr288451-a.flfrd1.on.wave.home.com [24.112.91.149]) by lists.bell-labs.com (Postfix) with ESMTP id 637DF44337 for ; Sat, 30 Dec 2000 19:39:34 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sat, 30 Dec 2000 20:39:51 -0500 (EST) From: Billy Biggs To: Henning Schulzrinne Cc: Jacek_Grabiec@3com.com, sip@lists.bell-labs.com, jdrosen@dynamicsoft.com, rfairlie@nuera.com, jhornsby@ubiquity.net, vkg@lucent.com Subject: Re: [SIP] Outbound proxy (was: proxy routing logic) Message-ID: <20001230203951.A1491@div8.net> References: <882569C4.008219F5.00@hqoutbound.ops.3com.com> <3A4E8CBB.FCA767A0@cs.columbia.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <3A4E8CBB.FCA767A0@cs.columbia.edu>; from hgs@cs.columbia.edu on Sat, Dec 30, 2000 at 05:32:43PM -0800 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 30 Dec 2000 20:39:51 -0500 Henning, I'm sorry, but I don't quite understand your email. Did it get cut off? Currently, I know of a few shipping implementations where the outbound proxy receives all outgoing requests. Even if an implementation used a different definition, I can't think of a situation where the requests wouldn't go to the correct destination. Henning Schulzrinne (hgs@cs.columbia.edu): > Things could get a bit odd if things are configured so that the > outbound proxy is not the one "closest" to the inside party. For > example, you could have a call through > > acme.com and then > sales.acme.com > > reaching Bob@sales.acme.com. If acme.com is the outbound proxy and > sales.acme.com record-routes for the inbound call, routing gets > strange. There's probably not much one can do here except say "don't > do that". I don't understand how the routing gets strange. If a request for sip:sales.acme.com arrives at acme.com, then it should realize that the request is not for it an proxy it accordingly. > Also note, in practice, the species of outbound proxy that we have > seen so far (firewall proxies) will almost always have to RR in order > to make sure that requests from the outside traverse it. I routinely set the outbound proxy of my phone to the machine under my desk so I can trace its messages easier. The firewall proxy record-routes while the outbound proxy doesn't. Everything works great. -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 21:35:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA04981 for ; Sat, 30 Dec 2000 21:35:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 47DB14433F; Sat, 30 Dec 2000 20:35:15 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from mailserver-ng.cs.umbc.edu (mailserver-ng.cs.umbc.edu [130.85.100.230]) by lists.bell-labs.com (Postfix) with ESMTP id C3B6744337 for ; Sat, 30 Dec 2000 20:34:00 -0500 (EST) Received: from sunserver1.cs.umbc.edu (actaeon.cs.umbc.edu [130.85.99.51]) by mailserver-ng.cs.umbc.edu (8.9.3/8.9.3) with ESMTP id VAA05860; Sat, 30 Dec 2000 21:33:48 -0500 (EST) From: "Dr. Frank Miller" Received: (from fwmiller@localhost) by sunserver1.cs.umbc.edu (8.9.3/8.9.3) id VAA07493; Sat, 30 Dec 2000 21:33:48 -0500 (EST) Message-Id: <200012310233.VAA07493@sunserver1.cs.umbc.edu> To: SIP@lists.bell-labs.com Cc: "Dr. Frank Miller" X-Mailer: ELM [version 2.4ME+ PL60 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Subject: [SIP] SIP implementations Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 30 Dec 2000 21:33:48 -0500 (EST) Content-Transfer-Encoding: 7bit Greetings, I've been lurking on this list for a short time and I've been wondering if its kosher to ask about implementations. If one were to make use of SIP for call control in, say, an access switch, which implementation would be the best. I realize this is sort of a loaded question and I'm performing my own inquiries of different vendors and free implementations but I'd like to hear the opinions of those on this list if anyone has one. Just to add a little more fuel to the fire, I've heard good things about the Vovida and Hughes Network Systems products, any comment? Donning my flame resistant suit, FM -- Frank W. Miller Assistant Professor Department of Computer Science & Electrical Engineering University of Maryland, Baltimore County _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 21:54:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05036 for ; Sat, 30 Dec 2000 21:54:01 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BBE274433F; Sat, 30 Dec 2000 20:54:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 1210644337 for ; Sat, 30 Dec 2000 20:53:05 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA13609; Sat, 30 Dec 2000 21:52:53 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA24016; Sat, 30 Dec 2000 21:52:53 -0500 (EST) Message-ID: <3A4ECAA9.9FA4F60A@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Billy Biggs Cc: sip@lists.bell-labs.com Subject: Re: [SIP] Outbound proxy (was: proxy routing logic) References: <882569C4.008219F5.00@hqoutbound.ops.3com.com> <3A4E8CBB.FCA767A0@cs.columbia.edu> <20001230203951.A1491@div8.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 30 Dec 2000 21:56:57 -0800 Content-Transfer-Encoding: 7bit I haven't worked out the details, but something like the following: - Bob@acme gets a request, through acme.com, which knows him to be in sales.acme.com. For whatever reason, sales.acme.com adds itself to the RR on the incoming call. - The firewall acme.com is configured as the outbound proxy. (It also record-routes, but that doesn't matter here.) - Requests now go to acme.com, which sends them to sales.acme.com because of the Route. Sales.acme sends it back to acme.com as its outbound proxy. This should be a spiral, so it's just extra work. The traditional justification for outbound proxies has been for firewalls that all first requests need to go through. To avoid the spiral, Bob would have to make sure to configure its system with the 'closest' *inbound* system, which in turn would have to use the real firewall as its outbound proxy. This is somewhat annoying as it would mean that the DHCP configuration for the two proxies is different. Again, this is a configuration issue, not as much a protocol issue, but it may out some brittleness if random parties start record-routing. (As long as only acme.com record-routes and is the outbound proxy, sales.acme.com can do its job for inbound requests without harm.) In any event, the new text should clearly state what outbound proxies need to do with Route headers. The 'every host removes top Route' rule implied in 2543/6.33 would not work with outbound proxies, since the UAC already removed the top Route and placed it in the Request-URI. (I scanned the new text and it seems silent on this issue at least in section 'proxy processing of non-initial request'.) Billy Biggs wrote: > > Henning, > > I'm sorry, but I don't quite understand your email. Did it get cut > off? > > Currently, I know of a few shipping implementations where the outbound > proxy receives all outgoing requests. Even if an implementation used a > different definition, I can't think of a situation where the requests > wouldn't go to the correct destination. > > Henning Schulzrinne (hgs@cs.columbia.edu): > > > Things could get a bit odd if things are configured so that the > > outbound proxy is not the one "closest" to the inside party. For > > example, you could have a call through > > > > acme.com and then > > sales.acme.com > > > > reaching Bob@sales.acme.com. If acme.com is the outbound proxy and > > sales.acme.com record-routes for the inbound call, routing gets > > strange. There's probably not much one can do here except say "don't > > do that". > _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 21:55:05 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA05048 for ; Sat, 30 Dec 2000 21:55:05 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1569D44378; Sat, 30 Dec 2000 20:55:16 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id B75A044337 for ; Sat, 30 Dec 2000 20:54:51 -0500 (EST) Received: from bart.cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA13662; Sat, 30 Dec 2000 21:54:39 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.9.3/8.9.3) with ESMTP id VAA24020; Sat, 30 Dec 2000 21:54:40 -0500 (EST) Message-ID: <3A4ECB14.12367232@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Dr. Frank Miller" Cc: SIP@lists.bell-labs.com Subject: Re: [SIP] SIP implementations References: <200012310233.VAA07493@sunserver1.cs.umbc.edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 30 Dec 2000 21:58:44 -0800 Content-Transfer-Encoding: 7bit Questions like this belong on sip-implementors, since they are not protocol issues. (This is the same split as on the RSVP list, btw.) "Dr. Frank Miller" wrote: > > Greetings, > > I've been lurking on this list for a short time and I've been wondering > if its kosher to ask about implementations. If one were to make use of > SIP for call control in, say, an access switch, which implementation > would be the best. I realize this is sort of a loaded question and I'm > performing my own inquiries of different vendors and free implementations > but I'd like to hear the opinions of those on this list if anyone has > one. Just to add a little more fuel to the fire, I've heard good things > about the Vovida and Hughes Network Systems products, any comment? > > Donning my flame resistant suit, > FM > > -- > Frank W. Miller > Assistant Professor > Department of Computer Science & Electrical Engineering > University of Maryland, Baltimore County > > _______________________________________________ > SIP mailing list > SIP@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/sip _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sat Dec 30 23:21:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA06102 for ; Sat, 30 Dec 2000 23:21:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 99D1D44337; Sat, 30 Dec 2000 22:21:12 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (cr288451-a.flfrd1.on.wave.home.com [24.112.91.149]) by lists.bell-labs.com (Postfix) with ESMTP id E072544336 for ; Sat, 30 Dec 2000 22:20:03 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sat, 30 Dec 2000 23:20:27 -0500 (EST) From: Billy Biggs To: Jonathan Rosenberg Cc: SIP List Subject: RR for non-INVITE call legs (was Re: [SIP] new record-route text!) Message-ID: <20001230232027.A1535@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdrosen@dynamicsoft.com on Fri, Dec 29, 2000 at 05:32:43PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sat, 30 Dec 2000 23:20:27 -0500 RR for non-INVITE call legs and non-INVITE requests, part 1: For me, a call-leg is created equally for all requests. The final response completes the leg and establishes the Route and tags. This moves the request from the one-to-many state to a one-on-one call. My implementation of SUBSCRIBE/NOTIFY is no different. NOTIFYs follow the established Route back and use the tags, and NOTIFYs received which do not match the established legs tags are 481'd. Your proposal seems to be that any request other than INVITE cannot create a call leg, and that the NOTIFY be sent strictly to the Contact address, not follow the Route, and reset the tags. That's a big switch. I'm sure everyone who has implemented (at least) SUBSCRIBE/NOTIFY will have to change their code. This also means that any firewall proxy MUST mangle the Contact address for all outgoing requests other than INVITE. (Note that if the Contact address on an INVITE is mangled, it MUST NOT be to a redirect server, since this means we get mid-call redirects, which don't work). RR for non-INVITE call legs and non-INVITE requests, part 2: RR/Route must be allowed for non-INVITE requests within a call, such as REFER. This of course makes the logic really weird, since the behavior for non-INVITE requests outside of a leg is different than those within. -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 31 09:40:04 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA07575 for ; Sun, 31 Dec 2000 09:40:04 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7C99C44337; Sun, 31 Dec 2000 08:40:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from cybertron.div8.net (cr288451-a.flfrd1.on.wave.home.com [24.112.91.149]) by lists.bell-labs.com (Postfix) with ESMTP id E0D0E44336 for ; Sun, 31 Dec 2000 08:39:50 -0500 (EST) Received: by div8.net via sendmail from stdin id (Debian Smail3.2.0.102) for sip@lists.bell-labs.com; Sun, 31 Dec 2000 09:40:18 -0500 (EST) From: Billy Biggs To: Jonathan Rosenberg Cc: SIP List Subject: Re: [SIP] new record-route text! Message-ID: <20001231094018.A6703@div8.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from jdrosen@dynamicsoft.com on Fri, Dec 29, 2000 at 05:32:43PM -0500 Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 31 Dec 2000 09:40:18 -0500 Here's a stab at the "open issues": > OPEN-ISSUE: should the UA remove the maddr param, if present, if the > request is sent to the server at that maddr? No, since the request may be snarfed by a transparent proxy. maddrs should never be stripped from the RURI (unless of course by the host represented in the maddr). > OPEN-ISSUE: should we mention handling of route with local outbound > proxies here? RFC2543 has some text on DNS-less UAs, but there are > issues with this. Route handling does not change if you have a local outbound proxy. With an outbound proxy configured, outgoing messages should be unchanged: all processing remains the same. The difference is that requests are IP'ly sent to a specific address. > OPEN-ISSUE: Handling for non-200 responses, including provisionals and > certain 400 class responses. Are we supporting record-routing for > non-200 class responses? Record-routing for provisional responses is > discussed in the 100rel spec. What needs to be said here? I'm for disallowing RR'ing of non-200s. -- Billy Biggs bbiggs@dumbterm.net http://www.billybiggs.com/ wbiggs@uwaterloo.ca _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 31 13:54:02 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08233 for ; Sun, 31 Dec 2000 13:54:02 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CBE8744337; Sun, 31 Dec 2000 12:54:13 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from sapphire.int.ipverse.com (w067.z208037018.sjc-ca.dsl.cnc.net [208.37.18.67]) by lists.bell-labs.com (Postfix) with ESMTP id 1BE2444336 for ; Sun, 31 Dec 2000 12:53:35 -0500 (EST) Received: from matt.ipverse.com (lsanca1-ar5-208-121.dsl.gtei.net [4.33.208.121]) by sapphire.int.ipverse.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZV8K8A6Q; Sun, 31 Dec 2000 10:53:24 -0800 Message-Id: <5.0.2.1.2.20001231103636.02031d30@pop3.ipverse.com> X-Sender: matt@ipverse.com@pop3.ipverse.com X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 To: "Bernard D. Aboba" From: Matt Holdrege Subject: Re: [SIP] draft-calhoun-sip-aaa-req Cc: SIP List In-Reply-To: References: <14923.34270.53313.693322@thomasm-u1.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 31 Dec 2000 10:53:22 -0800 At 09:04 AM 12/29/2000, Bernard D. Aboba wrote: >The document has not been discussed in the AAA >WG, because AAA is focused on network access >requirements. Not exactly. While the AAA charter formally states network access, always-on is mentioned in the AAA requirements document. Access means different things at different layers. People traditionally associate network access with a PPP session. We are addressing much more than that in the AAA WG. And requirements for SIP networks were added to the AAA WG. >Thus, it is completely up to the SIP WG to >define the security requirements for SIP, >which may or may not require AAA functionality >as a solution. It's up to the SIP WG to define their security requirements, but it's up to the users of SIP to choose an AAA solution. Some builders of SIP networks have chosen the IETF AAA WG DIAMETER protocol already. >I'd note that for applications such as >telephony, where the client can often be >presumed to have Internet access, a wider >range of security solutions are available >than in network access, where by definition >the client does not have network access >prior to authentication. Access still happens on an always-on network. When your SIP phone calls my SIP phone that is a form of access. Same for when a SIP phone "accesses" a SIP proxy or network server. Now I'm not saying that DIAMETER belongs in SIP phones, definitely NOT! But DIAMETER can and will be used between SIP servers and back-end AAA systems. As for the preference for XML, the AAA WG already has at least two proposals for an XML representation including candidate DTD's. _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip From sip-admin@lists.bell-labs.com Sun Dec 31 21:09:50 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA09423 for ; Sun, 31 Dec 2000 21:09:50 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A26D144337; Sun, 31 Dec 2000 20:10:02 -0500 (EST) Delivered-To: sip@lists.bell-labs.com Received: from is1-55.antd.nist.gov (is1-50.antd.nist.gov [129.6.50.251]) by lists.bell-labs.com (Postfix) with ESMTP id E92B944336 for ; Sun, 31 Dec 2000 20:09:20 -0500 (EST) Received: from nist.gov (IDENT:mranga@stinkbug.antd.nist.gov [129.6.55.9]) by is1-55.antd.nist.gov (8.9.3/8.9.3) with ESMTP id VAA25836; Sun, 31 Dec 2000 21:03:44 -0500 (EST) Message-ID: <3A4FE6C4.6A91F528@nist.gov> From: "M. Ranganathan" Reply-To: mranga@nist.gov Organization: NIST advanced networking technologies group X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 To: sip@lists.bell-labs.com, jainsip@egroups.com Cc: dougm@antd.nist.gov, marc.bednarek@nist.gov, tim.hall@nist.gov, muresan@us.ibm.com Content-Type: multipart/alternative; boundary="------------37BEBB0D2075AABF50E04CCA" Subject: [SIP] A free, public domain , JAVA-based SIP/SDP parser Sender: sip-admin@lists.bell-labs.com Errors-To: sip-admin@lists.bell-labs.com X-BeenThere: sip@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: IETF SIP Mailing List List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/sip/ Date: Sun, 31 Dec 2000 21:09:08 -0500 --------------37BEBB0D2075AABF50E04CCA Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: base64 Dear Gentlefolk of the mailing list: There have been several questions in the mailing list connected with SIP syntax and parsing of SIP messages. I have been working on a JAVA-based message parser for SIP/SDP and its associated RFCs which I thought would be of use to the community. The distinguishing features of this parser are (1) It uses a parser generator to build the parser rather than adhoc techniques. This makes the syntax clear, extensible and easy to debug. (2) It incorporates flexible exception handling for bad headers, giving an application fine grained control over how to deal with mal-formed headers and (3) It incorporates an extension mechanism to deal with new header types. The parser handles all headers that are part of SIP RFC 2543 bis02. It is structured to work using either a message stream (TCP) or buffered packets (UDP) and could form the basis of a SIP stack or test tools. It uses an event-oriented structure. The parser is in the public domain and is free. If you would like to download, please visit our project web page at http://www.antd.nist.gov/proj/iptel/ and click on the NIST-SIP download button on the top left of the page. If you would like to browse the javadoc first before you download here is a link: http://www.antd.nist.gov/proj/iptel/src/nist-sip/nist-sip-0.9/doc/index.html I have tested the parser against all the messages in the torture test list of messages as well as several of the headers in the RFC 2543. I hope you will find this a useful piece of work and I look forward to hearing from you about suggested improvements and / or problems that you may encounter. I thought it would make a nice new year gift so Happy New Year to all of you and many thanks for your help and clarifications. Sincerely Ranga. -- M.Ranganathan NIST Advanced Networking Technologies Group, 100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. Tel: 301 975 3664 Fax: 301 590 0932 --------------37BEBB0D2075AABF50E04CCA Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Dear Gentlefolk of the mailing list:

There have been several questions in the mailing list connected with SIP syntax and parsing of SIP messages. I have been working on a JAVA-based  message parser for SIP/SDP and its associated RFCs which I thought would be of use to the community.   The distinguishing features of this parser are (1) It uses  a parser generator  to build the parser rather than adhoc techniques.  This makes the syntax clear, extensible and easy to debug.  (2) It  incorporates flexible exception handling for bad headers, giving an application fine grained control over how to deal with mal-formed headers and (3) It incorporates an extension mechanism to deal with new header types.   The parser  handles all headers that are part of SIP RFC 2543 bis02.  It is structured to work using either a message stream (TCP) or buffered packets (UDP) and could form the basis of  a SIP stack or test tools.  It uses an event-oriented structure.
 

The parser is in the public domain and is free.  If you would like to download,   please visit our  project web page at

http://www.antd.nist.gov/proj/iptel/

and click on the NIST-SIP download button on the top left of the page.

If you would like to browse the javadoc first before you download here is a link:

http://www.antd.nist.gov/proj/iptel/src/nist-sip/nist-sip-0.9/doc/index.html

I have tested the parser against all the messages in the torture test list of messages as well as several of the headers in the RFC 2543.

I hope you will find this a useful piece of work and I look forward to hearing from you about suggested improvements and / or problems that you may encounter.

I thought it would make a nice new year gift so Happy New Year to all of you and many thanks for your help and clarifications.

Sincerely

Ranga.
 
  

--
M.Ranganathan
NIST Advanced Networking Technologies Group,
100 Bureau Drive, Stop 8920, Gaithersburg, MD 20899. 
Tel: 301 975 3664 Fax: 301 590 0932
  --------------37BEBB0D2075AABF50E04CCA-- _______________________________________________ SIP mailing list SIP@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/sip