From http-state-admin@lists.bell-labs.com Sat Dec 1 06:30:27 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA11886 for ; Sat, 1 Dec 2001 06:30: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 5FE19445A9 for ; Sat, 1 Dec 2001 05:14:24 -0500 (EST) Subject: lists.bell-labs.com mailing list memberships reminder From: mailman-owner@lists.bell-labs.com To: iptel-archive@ietf.org X-No-Archive: yes X-Ack: no Sender: http-state-admin@lists.bell-labs.com Errors-To: http-state-admin@lists.bell-labs.com X-BeenThere: http-state@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk Message-Id: <20011201101424.5FE19445A9@lists.bell-labs.com> Date: Sat, 1 Dec 2001 05:14:24 -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, iptel-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 iptel-archive@lists.ietf.org: List Password // URL ---- -------- iptel@lists.bell-labs.com Gfcn http://lists.bell-labs.com/mailman/options/iptel/iptel-archive%40lists.ietf.org From iptel-admin@lists.bell-labs.com Sat Dec 1 15:38:43 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21282 for ; Sat, 1 Dec 2001 15:38: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 834424433D; Sat, 1 Dec 2001 14:27:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lists.bell-labs.com (Postfix) with ESMTP id EC8C744336 for ; Sat, 1 Dec 2001 14:26:56 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fB1KcZD22335; Sat, 1 Dec 2001 12:38:35 -0800 (PST) Received: from cisco.com (sjc-vpn1-547.cisco.com [10.21.98.35]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AAZ07587; Sat, 1 Dec 2001 12:38:33 -0800 (PST) Message-ID: <3C093FA5.4FE39B4A@cisco.com> From: "Hussein F. Salama" X-Mailer: Mozilla 4.76 [en]C-CCK-MCD (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" , iptel@lists.bell-labs.com Subject: Re: [IPTEL] carrier scenario for TRIP References: <70565611B164D511957A001083FCDD56CAACAD@va02.va.neustar.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 01 Dec 2001 12:37:58 -0800 Content-Transfer-Encoding: 7bit "Peterson, Jon" wrote: > > > I suspect that bundling number prefix/address-based routed into trunk groups > is the right way for an MGC to aggregate routes for delivery to an LS. Does the LS know of the eistance of the MGs at all? Or would the MGs, (GW1, 2, and 3) be completely shielded from the LS by the MGC? Thanks. Hussein -- Hussein F. Salama Cisco Systems Mail Stop SJC-24/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 3 03:59:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24484 for ; Mon, 3 Dec 2001 03:59: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 A6E9E44344; Mon, 3 Dec 2001 02:48:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by lists.bell-labs.com (Postfix) with ESMTP id D9EC24433B for ; Mon, 3 Dec 2001 02:47:04 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id fB38wi520294; Mon, 3 Dec 2001 03:58:44 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Dec 2001 03:01:12 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAACB5@va02.va.neustar.com> From: "Peterson, Jon" To: "'Hussein F. Salama'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] carrier scenario for TRIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 3 Dec 2001 03:00:44 -0600 In the model I suspect to be the correct one, the LS would only know of the existence of the trunk groups propagated by the MGC, although of the course the availability of TGs is predicated on the avaibility of one or more gateways. The LS would however have direct knowledge of the availability of the MGC itself; presumably if the MGC somehow became unavailable, so would all of the resources that it controls. In this respect the LS can adopt the same behavior towards an MGC, that controls many trunk groups, that we would expect it to use for a single small smart gateway that might control only one trunk group. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Hussein F. Salama [mailto:hsalama@cisco.com] > Sent: Saturday, December 01, 2001 12:38 PM > To: Peterson, Jon; iptel@lists.bell-labs.com > Subject: Re: [IPTEL] carrier scenario for TRIP > > > > > "Peterson, Jon" wrote: > > > > > > > I suspect that bundling number prefix/address-based routed > into trunk groups > > is the right way for an MGC to aggregate routes for > delivery to an LS. > > Does the LS know of the eistance of the MGs at all? Or would > the MGs, (GW1, 2, > and 3) be completely shielded from the LS by the MGC? > > Thanks. > > Hussein > > > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC-24/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-7147 > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 3 21:12:01 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21395 for ; Mon, 3 Dec 2001 21: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 2A8734434D; Mon, 3 Dec 2001 20:00:03 -0500 (EST) Delivered-To: iptel@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 CDC8644348 for ; Mon, 3 Dec 2001 19:59:09 -0500 (EST) Received: from gab200r1.ems.att.com ([135.37.94.32]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fB42B5n19180; Mon, 3 Dec 2001 21:11:05 -0500 (EST) Received: from njb140bh2.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id VAA17846; Mon, 3 Dec 2001 21:11:30 -0500 (EST) Received: by NJB140BH2 with Internet Mail Service (5.5.2653.19) id ; Mon, 3 Dec 2001 21:10:57 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F96BE385@OCCLUST04EVS1.ugd.att.com> From: "Roy, Radhika R, ALCTA" To: "Peterson, Jon" , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] iptel-gwreg-req open issues MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 3 Dec 2001 21:09:29 -0500 Hi, Jon: It is a good start for discussion via emails as all of us may not participate in the IETF-52 Salt Lake meeting. I appreciate your thoughtful comments. In fact, I am delighted to see that we are almost in full agreement. My comments are inline [RRR]. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, November 30, 2001 3:15 PM To: 'iptel@lists.bell-labs.com' Subject: [IPTEL] iptel-gwreg-req open issues A few comments on the open issues listed in the draft. REQ 6- I think this is a real requirement. I think that in many complex architectures (such as ones in which MGCs are used as gateways), the provisioning of ranges of POTS numbers associated with gateways must be performed in multiple locations (proxy servers and gateways, at least) if there is not some sort of gwreg mechanism that allows you to provision in one place and then automatically propagate the data to any other systems that need it. In my opinion, simplifying provisioning is one of the primary reasons to use gateway registration. If you have to substantially pre-provision proxies then I don't think gateway registration makes your life that much easier. ... [RRR] Yes, I agree with you because it is the intra-ITAD environment where a single carrier/service provider wants to AUTO-provision (not pre-provisioned) in order to avoid error-prone and costly manual configurations. This requires communications between the GWs and the LSs and, registration is one of the important items. A GW can be a SIP-ISUP Interworking Telephony GW (e.g., MGC - signaling entity) or a SIP-H.323 Interworking GW (e.g., IWF - signaling entity). REQ 8- I really think the gwreg protocol should be extensible, even if we aren't sure how we'd like to extend it at the moment. As for whether these attributes are attributed to routes or gateways, I'd actually suggest a third alternative for consideration - trunk groups. My carrier architecture provides a few examples of how such dynamic data depends on trunk groups rather than gateways. [RRR] You are right and protocol MUST be flexible enough to accommodate this (i.e., protocol must NOT be hard-wired for a particular thing). For example, when we say that a GW registers addresses, the addresses can be E.164, email IDs, URL IDs, etc. as appropriate. REQ 11- I'm not sure I entirely understand either the requirement or the open issue here, but I'll take a stab at this. Since we're considering gwreg in the absence of intradomain route propagation, independent routing policies amongst multiple proxies in an ITAD seems like an unlikely issue to address - any system in which there's a possibility that there are independent proxies that could somehow be synchronized requires something like routing policy centralization or intradomain propagation. [RRR] Again, I think that you are right on this issue because the whole point is that it is an intra-ITAD situation and, we are NOT considering, as you have clarified, the intra-ITAD (or intradomain) "route propagation." Therefore, as you have explained, independent routing policies among the multiple proxies does NOT arise. Is the assumption here that if there are multiple proxies in an ITAD, that some gateways register with one proxy, and some gateways register with another, perhaps depending on a POP at which the gateways are located? (Also, is there a latent requirement here about the cardinality of the roles of gateways and proxies?) Clearly if two proxies in an ITAD do not communicate with one another, and each gateway registers with a single proxy at a time (discounting failover), then I don't think it would even be possible for two proxies to return the same decision. If allowing something along these lines is what this requirement signifies, then I definitely support it. [RRR] For all practical purposes, there will be multiple proxies (/location servers) in an ITAD and, we have to develop our protocol keeping this very practical situation in mind. Otherwise, the protocol will NOT be complete and will almost be useless because it will NOT work in a real networking environment where multiple proxies/location servers are a reality. [RRR] The other thing is that the protocol messages that will be used between the GWs and the LSs, the same messages can also be used among the LSs to serve the purpose. It can be seen examining the contributions that have been made addressing this problem. On another angle of this, perhaps support for some sort of load-balancing should be its own requirement, since I'm not sure that's entirely dependent on multiple proxies - I'd suggest that a single proxy should be capable of returning different routes for two calls targeting the same address if it has received multiple gateway registrations matching the parameters of the call that have the same preference. Nor do I understand why a database protocol would preclude load-balancing... [RRR] Yes, I agree with you. REQ 12- I'm not really sure why this sort of 'discovery' would be needed. I agree that static configurations are more likely. Also, I envision that either the gateway or the proxy could initiate the connection. For the sort of architecture I have in mind, it would make more sense to statically configure the gateway with one or more proxies (each probably associated with a preference) to which the gateway would attempt to connect. Cryptographic authentication could let the proxy guarantee that the connection is desirable. [RRR] Jon, I beg to explain a little bit. Like REQ 6, as you have also mentioned, the AUTO-discovery is helpful as opposed to static configurations. However, as Jonathan mentioned (and we have also seen examining the several contributions made in this area), the full-fledged auto-discovery may change the basic characteristics the entire protocol and, some may not like this. [RRR] I may tend to consider the auto-discovery as a separate item from the rest of the protocol development. For example, unicast-schemes (as opposed to multicast schemes) using DNS look-up may also be considered for ease of implementation, if it is considered that the multicast-based discovery mechanism is problematic. [RRR] The bottom line is that I may agree with you and Jonathan now, if we agree that we will visit this issue later once we finish the work of the base protocol that will be used within the intra-ITAD (or intradomain) excluding the discovery. Jon Peterson NeuStar, Inc. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Dec 4 03:03:03 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20582 for ; Tue, 4 Dec 2001 03: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 BA4FE4435A; Tue, 4 Dec 2001 01:51:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by lists.bell-labs.com (Postfix) with ESMTP id 59DF444359 for ; Tue, 4 Dec 2001 01:50:22 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id fB482LS19718; Tue, 4 Dec 2001 02:02:21 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 02:04:49 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAACC1@va02.va.neustar.com> From: "Peterson, Jon" To: "'Roy, Radhika R, ALCTA'" , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] iptel-gwreg-req open issues MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 4 Dec 2001 02:04:25 -0600 While I don't want to comment extensively on matters that aren't in the current scope of the WG, I do agree that we need to be somewhat flexible about how we understand the term 'gateway'. For example, I think most IP PBXs could qualify as gateways - but the H.323-SIP gateway sounds like a tougher case to support. As I understand it, the current restriction in WG scope is intended to prevent us from straying into subjects like service registration. Perhaps we need some sharper way of defining gateways; maybe we could rely on the device having a PSTN circuit switched interface as a litmus test. I would note that if your 'gateways' are propagating information about email addresses and so forth they go beyond the capabilities I commonly associate with a gateway. I also think we agree that there is no obvious reason why the same protocol needs to be used for the discovery and registration. Personally, I would be happy to solve the registration problem prior to investigating discovery - but then again, there may be an overwhelming public sentiment that these two capabilities have an equal priority or that they need to wrapped into the same protocol. If there is any reason why these two features should be tightly coupled, I for one would like to understand it. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Monday, December 03, 2001 6:09 PM > To: Peterson, Jon; 'iptel@lists.bell-labs.com' > Subject: RE: [IPTEL] iptel-gwreg-req open issues > > > Hi, Jon: > > It is a good start for discussion via emails as all of us may not > participate in the IETF-52 Salt Lake meeting. I appreciate > your thoughtful > comments. > > In fact, I am delighted to see that we are almost in full agreement. > > My comments are inline [RRR]. > > Best regards, > > Radhika R. Roy > rrroy@att.com > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Friday, November 30, 2001 3:15 PM > To: 'iptel@lists.bell-labs.com' > Subject: [IPTEL] iptel-gwreg-req open issues > > > > A few comments on the open issues listed in the draft. > > REQ 6- I think this is a real requirement. I think that in > many complex > architectures (such as ones in which MGCs are used as gateways), the > provisioning of ranges of POTS numbers associated with > gateways must be > performed in multiple locations (proxy servers and gateways, > at least) if > there is not some sort of gwreg mechanism that allows you to > provision in > one place and then automatically propagate the data to any > other systems > that need it. In my opinion, simplifying provisioning is one > of the primary > reasons to use gateway registration. If you have to substantially > pre-provision proxies then I don't think gateway registration > makes your > life that much easier. > ... > > [RRR] Yes, I agree with you because it is the intra-ITAD > environment where a > single carrier/service provider wants to AUTO-provision (not > pre-provisioned) in order to avoid error-prone and costly manual > configurations. This requires communications between the GWs > and the LSs > and, registration is one of the important items. A GW can be > a SIP-ISUP > Interworking Telephony GW (e.g., MGC - signaling entity) or a > SIP-H.323 > Interworking GW (e.g., IWF - signaling entity). > > > REQ 8- I really think the gwreg protocol should be > extensible, even if we > aren't sure how we'd like to extend it at the moment. As for > whether these > attributes are attributed to routes or gateways, I'd actually > suggest a > third alternative for consideration - trunk groups. My > carrier architecture > provides a few examples of how such dynamic data depends on > trunk groups > rather than gateways. > > [RRR] You are right and protocol MUST be flexible enough to > accommodate this > (i.e., protocol must NOT be hard-wired for a particular > thing). For example, > when we say that a GW registers addresses, the addresses can > be E.164, email > IDs, URL IDs, etc. as appropriate. > > REQ 11- I'm not sure I entirely understand either the > requirement or the > open issue here, but I'll take a stab at this. Since we're > considering gwreg > in the absence of intradomain route propagation, independent routing > policies amongst multiple proxies in an ITAD seems like an > unlikely issue to > address - any system in which there's a possibility that there are > independent proxies that could somehow be synchronized > requires something > like routing policy centralization or intradomain propagation. > > [RRR] Again, I think that you are right on this issue because > the whole > point is that it is an intra-ITAD situation and, we are NOT > considering, as > you have clarified, the intra-ITAD (or intradomain) "route > propagation." > Therefore, as you have explained, independent routing > policies among the > multiple proxies does NOT arise. > > Is the assumption here that if there are multiple proxies in > an ITAD, that > some gateways register with one proxy, and some gateways register with > another, perhaps depending on a POP at which the gateways are located? > (Also, is there a latent requirement here about the > cardinality of the roles > of gateways and proxies?) Clearly if two proxies in an ITAD do not > communicate with one another, and each gateway registers with > a single proxy > at a time (discounting failover), then I don't think it would even be > possible for two proxies to return the same decision. If > allowing something > along these lines is what this requirement signifies, then I > definitely > support it. > > [RRR] For all practical purposes, there will be multiple > proxies (/location > servers) in an ITAD and, we have to develop our protocol > keeping this very > practical situation in mind. Otherwise, the protocol will NOT > be complete > and will almost be useless because it will NOT work in a real > networking > environment where multiple proxies/location servers are a reality. > > [RRR] The other thing is that the protocol messages that will be used > between the GWs and the LSs, the same messages can also be > used among the > LSs to serve the purpose. It can be seen examining the > contributions that > have been made addressing this problem. > > On another angle of this, perhaps support for some sort of > load-balancing > should be its own requirement, since I'm not sure that's > entirely dependent > on multiple proxies - I'd suggest that a single proxy should > be capable of > returning different routes for two calls targeting the same > address if it > has received multiple gateway registrations matching the > parameters of the > call that have the same preference. Nor do I understand why a database > protocol would preclude load-balancing... > > [RRR] Yes, I agree with you. > > REQ 12- I'm not really sure why this sort of 'discovery' > would be needed. I > agree that static configurations are more likely. Also, I > envision that > either the gateway or the proxy could initiate the > connection. For the sort > of architecture I have in mind, it would make more sense to statically > configure the gateway with one or more proxies (each probably > associated > with a preference) to which the gateway would attempt to connect. > Cryptographic authentication could let the proxy guarantee that the > connection is desirable. > > [RRR] Jon, I beg to explain a little bit. Like REQ 6, as you have also > mentioned, the AUTO-discovery is helpful as opposed to static > configurations. However, as Jonathan mentioned (and we have also seen > examining the several contributions made in this area), the > full-fledged > auto-discovery may change the basic characteristics the > entire protocol and, > some may not like this. > > [RRR] I may tend to consider the auto-discovery as a separate > item from the > rest of the protocol development. For example, > unicast-schemes (as opposed > to multicast schemes) using DNS look-up may also be > considered for ease of > implementation, if it is considered that the multicast-based discovery > mechanism is problematic. > > [RRR] The bottom line is that I may agree with you and > Jonathan now, if we > agree that we will visit this issue later once we finish the > work of the > base protocol that will be used within the intra-ITAD (or intradomain) > excluding the discovery. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Dec 4 08:35:05 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25360 for ; Tue, 4 Dec 2001 08: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 0EB9944369; Tue, 4 Dec 2001 07:23:03 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from usnimo.vocaltec.com (usnimo.vocaltec.com [209.117.177.152]) by lists.bell-labs.com (Postfix) with ESMTP id C7C8844364 for ; Tue, 4 Dec 2001 07:22:54 -0500 (EST) Received: from usnimo.vocaltec.com (usnimo.vocaltec.com [209.117.177.152]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id fB42qxS15622 for <"iptel,_iptel-admin"@neustar.biz>; Mon, 3 Dec 2001 20:53:00 -0600 X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 MIME-Version: 1.0 Subject: RE: [IPTEL] iptel-gwreg-req open issues To: Message-ID: X-MIMETrack: Serialize by Router on USNIMO/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March 2000) at 12/04/2001 08:33:36 AM Content-type: text/plain; charset=us-ascii From: Gur_Kimchi@vocaltec.com Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 4 Dec 2001 08:33:26 -0500 >> EQ 8- I really think the gwreg protocol should be extensible, even if we >> aren't sure how we'd like to extend it at the moment. As for whether these >> attributes are attributed to routes or gateways, I'd actually suggest a >> third alternative for consideration - trunk groups. My carrier architecture >> provides a few examples of how such dynamic data depends on trunk groups >> rather than gateways. >> >> [RRR] You are right and protocol MUST be flexible enough to accommodate this >> (i.e., protocol must NOT be hard-wired for a particular thing). For example, >> when we say that a GW registers addresses, the addresses can be E.164, email >> IDs, URL IDs, etc. as appropriate. Just as a clarification point - there are two alternatives to an iptel-gwreg solution based on the requirements: (A) are we discussion some XML document that the SIP GW will provide it's registrar in REGISTER and other (e.g. INFO) verbs, potentially sending all information when first registering and a delta later when some of the information changes. or (B) a new protocol (e.g. TRIP+ or whatever) used between SIP GWs and their registrars I would strongly recommend option (A) - SIP GWs register with some network element, provide keep-alive etc, and the additional information that needs to be provided can be broken down into three types: 1-Capabilities: * I have 20 T1 trunks running PRI * I can handle G.723.1 and G.711 * ... 2-Status: * I am at 90% now, stop sending me calls * 30 of my 60 lines are about to go down for maintenance in 5 minutes * ... 3-PSTN Termination: * I can terminate to +1212 and +1201 and +1609 with some additional metric (as Henning suggested) that has some private carrier interpretation. all of these can be defined as an XML document, + allowing a subset of the document to be sent when only part of the information changes. XML also allows for adding non-standard capabilities, status elements and termination information pretty easily. and I would recommend that we do not invent a new protocol here. Propagation of this XML should be using SIP and not some "other" protocol. - gur BTY, This reminds me of a discussion I had with Joerg Ott 2 years ago on the need for capabilities exchange mechanism in SIP - I guess we just had to wait :-) _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Dec 4 15:40:07 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11527 for ; Tue, 4 Dec 2001 15:40: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 8B81F44374; Tue, 4 Dec 2001 14:28:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by lists.bell-labs.com (Postfix) with ESMTP id 0595744369 for ; Tue, 4 Dec 2001 14:27:53 -0500 (EST) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id PAA20432; Tue, 4 Dec 2001 15:39:56 -0500 (EST) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id ATZ08479; Tue, 4 Dec 2001 15:40:05 -0500 (EST) Message-Id: <4.3.2.7.2.20011204152508.00b8d7a8@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Peterson, Jon" From: Michael Hammer Subject: Re: [IPTEL] carrier scenario for TRIP Cc: "'iptel@lists.bell-labs.com'" In-Reply-To: <70565611B164D511957A001083FCDD56CAACAD@va02.va.neustar.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 04 Dec 2001 15:45:31 -0500 Jon, A trunk is a single circuit (DS0) between two switching nodes that is shared on a call-by-call basis, as opposed to a local loop that serves only one user (telephone number address, excepting party lines). A trunk group is a bundle of DS0's and the first level of aggregation. (Please don't propagate the confusion that a trunk is more than one circuit.) After that you can address Routes and Route Sets/Lists as higher echelons of aggregation. Those lists may be ordered and unordered. I suspect that H.248 and MGCP are used for communications between the MGC and MGW involving the availability and status of the MGW. The MGC should be able to provide a complete picture of the MGW that it controls. Any suggestion that additional signaling of this nature is needed should be deferred to the Megaco WG rather than addressed here. To distinguish smart and dumb gateways, you might want to stipulate that the signaling endpoint for the gwreg protocol should be capable of terminating session/call signaling (i.e., SIP). Otherwise, this is a great writeup. Furthermore, I agree with the need to have additional attributes like LRN's and Carrier ID's that add context to the indication that a number is "reachable." While this won't completely address the "cost" issue, it can give great clues about where to direct signaling to get sessions setup to the "best" gateways. Mike At 02:06 PM 11/30/2001 -0600, Peterson, Jon wrote: >I'd like to describe a particular scenario for gateway registration, namely, >a case in which it could be used by a large US-based VoIP carrier. > >The sort of carrier network I'm envisioning is composed of entities >responsible for routing call setup requests (like SIP proxy servers) and >entities that generate and receive call setup requests (in the scope of this >problem, PSTN gateways). However, there are many different types of PSTN >gateways; the broad delineation is between media gateway controllers (that >manage 'dumb' gateways) and self-contained 'smart' gateways. The formal >distinction here between smart and dumb gateways is that smart gateways >speak the call setup protocol (like SIP) and presumably the gateway >registration protocol themselves, whereas dumb gateways speak only a device >control protocol (like Megaco), and rely on their MGC to handle call setup >and gateway registration protocols. > >In the field, smart gateways commonly have low capacities (on the order of a >couple of DS1s) whereas the scale of dumb gateways can get very large (many >DS3s). High-density dumb gateways tend to have support for SS7 intermachine >trunks (IMTs), whereas low-density smart gateways often forgo IMT support >for ISDN PRI or MF support; the signaling channels for each PRI and MF >trunks physically terminate on the gateway, but SS7 requires a consolidated >point at which signaling arrives for the trunks associated with multiple >gateways, and hence is conducive to the MGC/dumb gateway model. Some very >low-density residential gateways support POTS lines on the DS0 level, but >I'm not considering them in this architecture. > >For reasons of economics, operation and management, among others, large >carriers are predominantly SS7-based, so I'm going to assume that MGCs and >large dumb gateways constitute the majority of the network in this scenario. >Smaller smart gateways may also be sparing deployed in the network to face >specific resources (mostly PBXs). > > > > > Trunks > Gateway > Registration > IMT > Carrier Architecture +----+ ----> +1 > (H.248)| | > Device +---- | GW1| ----> +1703,+1571... > > Control| | | > | +----+ ----> +1202,+1703... >[TG1] > | > | IMT > | +----+ ----> +1 > (SIP) +-----+ | | | > +----------->| MGC |----+-----| GW2| ----> +1540,+1804... > > | +--+--+ | | | > | | | +----+ ----> +1202,+1703... >[TG1] > | | | > Call +----------+ | | IMT > Setup | | | | +----+ ----> +1 > (SIP) | Routing | | | | | > -------->| Proxy | | +-----| GW3| ----> +1202555, >+122544... > | (LS) | | | | > +----------+ | +----+ ----> +44 > | | | SS7 > | | +------------------------> TO PSTN > | | > | | > | | +----+ PRI (B&D) > | +-------------------------->| GW4| ----> +1202533 > | +----+ > | (SIP) > | +----+ MF > +-------------------------------> GW5| ----> +1703989 > +----+ > >In the above picture, I envision that the gateway registration protocol >would be spoken between all of the entities that speak SIP. > >By way of explanation, the diagram above shows multiple bundles of DS0 >circuits (we'll refer to them as trunks) associated with each of the large >dumb gateways (GW1, GW2 and GW3). One or more E.164 number ranges is >associated with each of these trunks. '+1' indicates that all of the United >States is reachable through this trunk (probably, this is a trunk to an >interexchange carrier). The second trunk on GW1 (pointed to +1703,+1571...) >contains a set of reachable area codes within a rate center, suggesting that >the trunk is associated with a LEC tandem. The second trunk on GW3 (pointed >to +1202555, +1202544...) is associated with a set of specific exchange >codes, and is therefore probably an end office trunk pointing to a class 5 >switch. The smaller gateways (GW4 and GW5) have trunks that are associated >with customers, possibly PBXs. Finally, note that logical 'trunk groups' can >span multiple gateways, as is the case with [TG1], the third trunks on GW1 >and GW2 (each pointing to +1202,+1703...). > >Jonathan noted that the charter permits gateway registration for 'the >exchange of dynamic information' rather than reliability or scalability. I >think it is important to note that the reason why the exchange of dynamic >information is interesting to a carrier network is that it facilitates >provisioning and network management. I don't think that autodiscovery of the >LS by MGCs or vice versa would really make this system substantially easier >to manage or provision in any obvious way. > >To my mind, the fundamental question about gateway registration in this >architecture is 'what are the resources whose availability is advertised by >gateway registration?'. I think it needs to be some combination of the >following: > >- Availability of a gateway itself. In the case in which an MGC performs >gateway registration, it could notify the LS of the availability of any >individual gateway (for example GW1 above). If a standalone gateway (like >GW4) does not go offline gracefully, then of course no gateway >de-registration message could be sent, but the LS would presumably have some >other mechanism (absence of keepalive messages) to determine that the >gateway is unavailable. Since an MGC is not coupled to physical trunk >resources, it can take advantage of reliability mechanisms that a standalone >gateway cannot, and therefore it is well positioned to broker availability >information for gateways. Either way, clearly the availability of gateway >themselves can be made known to the LS. > >- Availability of a number prefix/address. This is the traditional TRIP >model, in which an E.164 range (e.g. '+1303') is propagated from the gateway >to the LS. This model works best, I think, in the case of standalone smart >gateways (like GW4). In the MGC case, it is harder to see what prefixes >should be propagated by the MGC to the LS - merely propagating that '+1' is >available through the MGC doesn't take into account the different policies >that are potentially available on different trunks. In other words, the big >open issue here is whether the MGC should aggregate routes on behalf of its >gateways or not, and if so, how. Also note that in order to allow for more >complex PSTN features, routing by location routing numbers and carrier >identification codes should also be permitted, and that the availability of >particular CICs or LRNs through an MGC should be advertised. > >- Availability of a trunk/PSTN interface on a gateway. Gateways generally >have more than one physical interface capable of supporting a trunk. If a >trunk has been established on a physical interface, it will have one of many >dynamic states (more precisely, the states on a trunk are an aggregate of >the states of its constituent circuts if no trunk-level events are taking >place); trunks can be busy, administratively blocked, idle, and so forth. >Trunks also have many different static attributes (some of which are >detailed below). Clearly, the availability of particular number ranges in a >gateway is dependent on the availability of trunks (i.e. if the third trunk >on GW3 goes off-line, then the +44 country code will no longer be available >in the MGC). For the purposes of scalability, a more useful construct is a >logical set of circuits known as a trunk group which allows multiple trunks >(potentially on different physical interfaces) to be grouped under the same >set of attributes and policies. A trunk group can also span multiple >gateways (as [TG1] spans the third circuits of GW1 and GW2) in order to >provide greater reliability. Consider, for example, that if GW2 were to go >offline, the trunk group consisting of the third trunks of GW1 and GW2 would >still be available (with diminished capacity). Note that these properties of >trunk groups also generally apply to ISDN NFAS trunks. > >I suspect that bundling number prefix/address-based routed into trunk groups >is the right way for an MGC to aggregate routes for delivery to an LS. > >Many static attributes that proxy servers might use for routing decisions >have dependencies on trunk groups. Some that come to mind: > >- A trunk group has directionality. It may be one-way inbound, one-way >outbound, or two-way. > >- The protocol used to establish calls on the trunk. In some instances, VoIP >messages might rely on signaling mechanisms that are specific to a >particular PSTN termination protocol. A good example would be if number >portability information is present in the VoIP signaling data - this >information will be lost if the call terminates on a PRI trunk (possibly >resulting in an error condition). > >Even addresses can usefully be construed as attributes of trunk group: > >- There is one and only one carrier that is responsible for the switch on >the other side of the trunk. One or more carrier identification codes can be >associated with a carrier. Of course, other carriers are also probably >reachable through the remote carrier's network. > >- Trunks to end offices may be associated with a location routing number >(LRN) used to route calls for local number portability. Each NP-compliant >end office switch in the (USA) PSTN is associated with one LRN. > >Note that neither of these forms of address are international in scope, and >therefore the set of all the carrier identification codes in the world is >not reachable by an ISUP signal sent through an American trunk. > >Interestingly, I think most of the dynamic information that would be >exchanged by gateway registration messages are attributes of trunk groups. >For instance: > >- The total capacity of a trunk might seem like a static attribute, but over >the long term it is actually dynamic. Existing trunk groups are augmented. >The total capacity of a trunk group can change over time due to capacity >constraints. Large carriers are constantly in the process of augmenting >exist trunks. The addition of circuits to an existing trunk group is >preferable to creating new trunk groups when the attributes of the trunk >remain the same. > >- Trunk groups fill up with calls. If a trunk group is one-way outbound, >then in some architectures an LS could track the congestion of particular >trunk groups itself without any gateway registration attributes. However, if >the trunk group is two-way, it is much more difficult for an LS to keep an >accurate count of idle circuits in a trunk group without reporting from >gateways. One of the difficult problems with propagating dynamic capacity is >the thresholds for reporting - sending a gateway registration message each >time the state of a single circuit changes is probably not feasible, so >perhaps some fuzzier states for the entire trunk group (e.g. 'almost full') >would be needed. > >- Trunk groups are created and destroyed. Switches associated with major >carriers are in an almost constant state of creating trunk groups as >connections to new switches are required or connections to existing switches >require augmentation with distinct policies. > >- Trunk groups have maintenance conditions - most notably blocking and >unblocking. Sending a block for a trunk group prevents new calls from being >received on the group. Blocking can be used when a hardware failure occurs >that takes a trunk out of service, or as a pre-emptive measure (quiescence) >to empty a trunk gradually. > >That's probably a good start as far as describing the architecture goes. > >Jon Peterson >NeuStar, Inc > > >_______________________________________________ >IPTEL mailing list >IPTEL@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Dec 4 23:03:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25445 for ; Tue, 4 Dec 2001 23: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 1FADE44378; Tue, 4 Dec 2001 21:51:03 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by lists.bell-labs.com (Postfix) with ESMTP id 3903844370 for ; Tue, 4 Dec 2001 21:50:06 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id fB5429S23983; Tue, 4 Dec 2001 22:02:09 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 22:04:37 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAACCD@va02.va.neustar.com> From: "Peterson, Jon" To: "'Michael Hammer'" Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] carrier scenario for TRIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 4 Dec 2001 22:04:07 -0600 Agreed that it's important that we define trunk group precisely if we intend to use it in any meaningful way. I'd suggest we refer to the definitions from SR2275: Trunk: In a network, a communication path connecting two switching systems used in the establishment of an end-to-end connection. It selected applications, it may have both its terminations in the same switching system. Trunk group: A set of trunks, traffic engineered as a unit, for the establishment of connections within or between switching systems in which all of the paths are interchangeable except where subgrouped. I believe since the introduction of ubiquitous digital trunking, since trunks never run over non-digital facilities, it has become common to refer to Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, December 04, 2001 12:46 PM > To: Peterson, Jon > Cc: 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] carrier scenario for TRIP > > > Jon, > > A trunk is a single circuit (DS0) between two switching nodes that is > shared on a call-by-call basis, as opposed to a local loop > that serves only > one user (telephone number address, excepting party lines). > A trunk group > is a bundle of DS0's and the first level of aggregation. > (Please don't > propagate the confusion that a trunk is more than one > circuit.) After that > you can address Routes and Route Sets/Lists as higher echelons of > aggregation. Those lists may be ordered and unordered. > > I suspect that H.248 and MGCP are used for communications > between the MGC > and MGW involving the availability and status of the MGW. > The MGC should > be able to provide a complete picture of the MGW that it > controls. Any > suggestion that additional signaling of this nature is needed > should be > deferred to the Megaco WG rather than addressed here. To > distinguish smart > and dumb gateways, you might want to stipulate that the > signaling endpoint > for the gwreg protocol should be capable of terminating session/call > signaling (i.e., SIP). > > Otherwise, this is a great writeup. Furthermore, I agree > with the need to > have additional attributes like LRN's and Carrier ID's that > add context to > the indication that a number is "reachable." While this > won't completely > address the "cost" issue, it can give great clues about where > to direct > signaling to get sessions setup to the "best" gateways. > > Mike > > > At 02:06 PM 11/30/2001 -0600, Peterson, Jon wrote: > >I'd like to describe a particular scenario for gateway > registration, namely, > >a case in which it could be used by a large US-based VoIP carrier. > > > >The sort of carrier network I'm envisioning is composed of entities > >responsible for routing call setup requests (like SIP proxy > servers) and > >entities that generate and receive call setup requests (in > the scope of this > >problem, PSTN gateways). However, there are many different > types of PSTN > >gateways; the broad delineation is between media gateway > controllers (that > >manage 'dumb' gateways) and self-contained 'smart' gateways. > The formal > >distinction here between smart and dumb gateways is that > smart gateways > >speak the call setup protocol (like SIP) and presumably the gateway > >registration protocol themselves, whereas dumb gateways > speak only a device > >control protocol (like Megaco), and rely on their MGC to > handle call setup > >and gateway registration protocols. > > > >In the field, smart gateways commonly have low capacities > (on the order of a > >couple of DS1s) whereas the scale of dumb gateways can get > very large (many > >DS3s). High-density dumb gateways tend to have support for > SS7 intermachine > >trunks (IMTs), whereas low-density smart gateways often > forgo IMT support > >for ISDN PRI or MF support; the signaling channels for each > PRI and MF > >trunks physically terminate on the gateway, but SS7 requires > a consolidated > >point at which signaling arrives for the trunks associated > with multiple > >gateways, and hence is conducive to the MGC/dumb gateway > model. Some very > >low-density residential gateways support POTS lines on the > DS0 level, but > >I'm not considering them in this architecture. > > > >For reasons of economics, operation and management, among > others, large > >carriers are predominantly SS7-based, so I'm going to assume > that MGCs and > >large dumb gateways constitute the majority of the network > in this scenario. > >Smaller smart gateways may also be sparing deployed in the > network to face > >specific resources (mostly PBXs). > > > > > > > > > > Trunks > > Gateway > > Registration > > IMT > > Carrier Architecture +----+ ----> +1 > > (H.248)| | > > Device +---- | GW1| ----> > +1703,+1571... > > > > Control| | | > > | +----+ ----> > +1202,+1703... > >[TG1] > > | > > | IMT > > | +----+ ----> +1 > > (SIP) +-----+ | | | > > +----------->| MGC |----+-----| GW2| ----> > +1540,+1804... > > > > | +--+--+ | | | > > | | | +----+ ----> > +1202,+1703... > >[TG1] > > | | | > > Call +----------+ | | IMT > > Setup | | | | +----+ ----> +1 > > (SIP) | Routing | | | | | > > -------->| Proxy | | +-----| GW3| ----> > +1202555, > >+122544... > > | (LS) | | | | > > +----------+ | +----+ ----> +44 > > | | | SS7 > > | | +------------------------> > TO PSTN > > | | > > | | > > | | +----+ PRI (B&D) > > | +-------------------------->| GW4| ----> > +1202533 > > | +----+ > > | (SIP) > > | +----+ MF > > +-------------------------------> GW5| ----> > +1703989 > > +----+ > > > >In the above picture, I envision that the gateway > registration protocol > >would be spoken between all of the entities that speak SIP. > > > >By way of explanation, the diagram above shows multiple > bundles of DS0 > >circuits (we'll refer to them as trunks) associated with > each of the large > >dumb gateways (GW1, GW2 and GW3). One or more E.164 number ranges is > >associated with each of these trunks. '+1' indicates that > all of the United > >States is reachable through this trunk (probably, this is a > trunk to an > >interexchange carrier). The second trunk on GW1 (pointed to > +1703,+1571...) > >contains a set of reachable area codes within a rate center, > suggesting that > >the trunk is associated with a LEC tandem. The second trunk > on GW3 (pointed > >to +1202555, +1202544...) is associated with a set of > specific exchange > >codes, and is therefore probably an end office trunk > pointing to a class 5 > >switch. The smaller gateways (GW4 and GW5) have trunks that > are associated > >with customers, possibly PBXs. Finally, note that logical > 'trunk groups' can > >span multiple gateways, as is the case with [TG1], the third > trunks on GW1 > >and GW2 (each pointing to +1202,+1703...). > > > >Jonathan noted that the charter permits gateway registration for 'the > >exchange of dynamic information' rather than reliability or > scalability. I > >think it is important to note that the reason why the > exchange of dynamic > >information is interesting to a carrier network is that it > facilitates > >provisioning and network management. I don't think that > autodiscovery of the > >LS by MGCs or vice versa would really make this system > substantially easier > >to manage or provision in any obvious way. > > > >To my mind, the fundamental question about gateway > registration in this > >architecture is 'what are the resources whose availability > is advertised by > >gateway registration?'. I think it needs to be some > combination of the > >following: > > > >- Availability of a gateway itself. In the case in which an > MGC performs > >gateway registration, it could notify the LS of the > availability of any > >individual gateway (for example GW1 above). If a standalone > gateway (like > >GW4) does not go offline gracefully, then of course no gateway > >de-registration message could be sent, but the LS would > presumably have some > >other mechanism (absence of keepalive messages) to determine that the > >gateway is unavailable. Since an MGC is not coupled to physical trunk > >resources, it can take advantage of reliability mechanisms > that a standalone > >gateway cannot, and therefore it is well positioned to > broker availability > >information for gateways. Either way, clearly the > availability of gateway > >themselves can be made known to the LS. > > > >- Availability of a number prefix/address. This is the > traditional TRIP > >model, in which an E.164 range (e.g. '+1303') is propagated > from the gateway > >to the LS. This model works best, I think, in the case of > standalone smart > >gateways (like GW4). In the MGC case, it is harder to see > what prefixes > >should be propagated by the MGC to the LS - merely > propagating that '+1' is > >available through the MGC doesn't take into account the > different policies > >that are potentially available on different trunks. In other > words, the big > >open issue here is whether the MGC should aggregate routes > on behalf of its > >gateways or not, and if so, how. Also note that in order to > allow for more > >complex PSTN features, routing by location routing numbers > and carrier > >identification codes should also be permitted, and that the > availability of > >particular CICs or LRNs through an MGC should be advertised. > > > >- Availability of a trunk/PSTN interface on a gateway. > Gateways generally > >have more than one physical interface capable of supporting > a trunk. If a > >trunk has been established on a physical interface, it will > have one of many > >dynamic states (more precisely, the states on a trunk are an > aggregate of > >the states of its constituent circuts if no trunk-level > events are taking > >place); trunks can be busy, administratively blocked, idle, > and so forth. > >Trunks also have many different static attributes (some of which are > >detailed below). Clearly, the availability of particular > number ranges in a > >gateway is dependent on the availability of trunks (i.e. if > the third trunk > >on GW3 goes off-line, then the +44 country code will no > longer be available > >in the MGC). For the purposes of scalability, a more useful > construct is a > >logical set of circuits known as a trunk group which allows > multiple trunks > >(potentially on different physical interfaces) to be grouped > under the same > >set of attributes and policies. A trunk group can also span multiple > >gateways (as [TG1] spans the third circuits of GW1 and GW2) > in order to > >provide greater reliability. Consider, for example, that if > GW2 were to go > >offline, the trunk group consisting of the third trunks of > GW1 and GW2 would > >still be available (with diminished capacity). Note that > these properties of > >trunk groups also generally apply to ISDN NFAS trunks. > > > >I suspect that bundling number prefix/address-based routed > into trunk groups > >is the right way for an MGC to aggregate routes for delivery > to an LS. > > > >Many static attributes that proxy servers might use for > routing decisions > >have dependencies on trunk groups. Some that come to mind: > > > >- A trunk group has directionality. It may be one-way > inbound, one-way > >outbound, or two-way. > > > >- The protocol used to establish calls on the trunk. In some > instances, VoIP > >messages might rely on signaling mechanisms that are specific to a > >particular PSTN termination protocol. A good example would > be if number > >portability information is present in the VoIP signaling data - this > >information will be lost if the call terminates on a PRI > trunk (possibly > >resulting in an error condition). > > > >Even addresses can usefully be construed as attributes of > trunk group: > > > >- There is one and only one carrier that is responsible for > the switch on > >the other side of the trunk. One or more carrier > identification codes can be > >associated with a carrier. Of course, other carriers are > also probably > >reachable through the remote carrier's network. > > > >- Trunks to end offices may be associated with a location > routing number > >(LRN) used to route calls for local number portability. Each > NP-compliant > >end office switch in the (USA) PSTN is associated with one LRN. > > > >Note that neither of these forms of address are > international in scope, and > >therefore the set of all the carrier identification codes in > the world is > >not reachable by an ISUP signal sent through an American trunk. > > > >Interestingly, I think most of the dynamic information that would be > >exchanged by gateway registration messages are attributes of > trunk groups. > >For instance: > > > >- The total capacity of a trunk might seem like a static > attribute, but over > >the long term it is actually dynamic. Existing trunk groups > are augmented. > >The total capacity of a trunk group can change over time due > to capacity > >constraints. Large carriers are constantly in the process of > augmenting > >exist trunks. The addition of circuits to an existing trunk group is > >preferable to creating new trunk groups when the attributes > of the trunk > >remain the same. > > > >- Trunk groups fill up with calls. If a trunk group is > one-way outbound, > >then in some architectures an LS could track the congestion > of particular > >trunk groups itself without any gateway registration > attributes. However, if > >the trunk group is two-way, it is much more difficult for an > LS to keep an > >accurate count of idle circuits in a trunk group without > reporting from > >gateways. One of the difficult problems with propagating > dynamic capacity is > >the thresholds for reporting - sending a gateway > registration message each > >time the state of a single circuit changes is probably not > feasible, so > >perhaps some fuzzier states for the entire trunk group (e.g. > 'almost full') > >would be needed. > > > >- Trunk groups are created and destroyed. Switches > associated with major > >carriers are in an almost constant state of creating trunk groups as > >connections to new switches are required or connections to > existing switches > >require augmentation with distinct policies. > > > >- Trunk groups have maintenance conditions - most notably > blocking and > >unblocking. Sending a block for a trunk group prevents new > calls from being > >received on the group. Blocking can be used when a hardware > failure occurs > >that takes a trunk out of service, or as a pre-emptive > measure (quiescence) > >to empty a trunk gradually. > > > >That's probably a good start as far as describing the > architecture goes. > > > >Jon Peterson > >NeuStar, Inc > > > > > >_______________________________________________ > >IPTEL mailing list > >IPTEL@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Dec 4 23:24:09 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25803 for ; Tue, 4 Dec 2001 23:24: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 9FE0B4437F; Tue, 4 Dec 2001 22:12:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by lists.bell-labs.com (Postfix) with ESMTP id 980094437D for ; Tue, 4 Dec 2001 22:11:50 -0500 (EST) Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id fB54Mo522490; Tue, 4 Dec 2001 23:23:14 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Tue, 4 Dec 2001 22:25:02 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAACCE@va02.va.neustar.com> From: "Peterson, Jon" To: "'Michael Hammer'" Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] carrier scenario for TRIP MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 4 Dec 2001 22:24:37 -0600 Whoops - sent an incomplete version of this. Please disregard my preceding mail. ----- Agreed that it's important that we define 'trunk group' precisely if we intend to use it in any meaningful way. I'd suggest we refer to the definitions from SR2275: Trunk: In a network, a communication path connecting two switching systems used in the establishment of an end-to-end connection. In selected applications, it may have both its terminations in the same switching system. Trunk group: A set of trunks, traffic engineered as a unit, for the establishment of connections within or between switching systems in which all of the paths are interchangeable except where subgrouped. I believe that since the introduction of ubiquitous digital trunking, which resulted in the allocation of DS0s between end offices in minimum groups of 24, it has become common to refer to bundles of DS0s as a trunk. You're right that we shouldn't further any confusion about this matter - but provided that we all understand that a TG is a bundle of DS0s between end offices, I think we'll be all right. I was certainly thinking that a protocol like H.248 would be used between an MGC and any gateways it controls. I definitely agree that no new protocol should be required between the MGC and its gateways in support of gateway registration - and that if there is any new package or what have you that's required for the device control protocol that it shouldn't be pursued in the IPTEL WG. I also firmly agree that any endpoint that speaks the call setup protocol (i.e. SIP) should speak the gateway registration protocol - I hope this comes through as my contention in the write-up. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Michael Hammer [mailto:mhammer@cisco.com] > Sent: Tuesday, December 04, 2001 12:46 PM > To: Peterson, Jon > Cc: 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] carrier scenario for TRIP > > > Jon, > > A trunk is a single circuit (DS0) between two switching nodes that is > shared on a call-by-call basis, as opposed to a local loop > that serves only > one user (telephone number address, excepting party lines). > A trunk group > is a bundle of DS0's and the first level of aggregation. > (Please don't > propagate the confusion that a trunk is more than one > circuit.) After that > you can address Routes and Route Sets/Lists as higher echelons of > aggregation. Those lists may be ordered and unordered. > > I suspect that H.248 and MGCP are used for communications > between the MGC > and MGW involving the availability and status of the MGW. > The MGC should > be able to provide a complete picture of the MGW that it > controls. Any > suggestion that additional signaling of this nature is needed > should be > deferred to the Megaco WG rather than addressed here. To > distinguish smart > and dumb gateways, you might want to stipulate that the > signaling endpoint > for the gwreg protocol should be capable of terminating session/call > signaling (i.e., SIP). > > Otherwise, this is a great writeup. Furthermore, I agree > with the need to > have additional attributes like LRN's and Carrier ID's that > add context to > the indication that a number is "reachable." While this > won't completely > address the "cost" issue, it can give great clues about where > to direct > signaling to get sessions setup to the "best" gateways. > > Mike > > > At 02:06 PM 11/30/2001 -0600, Peterson, Jon wrote: > >I'd like to describe a particular scenario for gateway > registration, namely, > >a case in which it could be used by a large US-based VoIP carrier. > > > >The sort of carrier network I'm envisioning is composed of entities > >responsible for routing call setup requests (like SIP proxy > servers) and > >entities that generate and receive call setup requests (in > the scope of this > >problem, PSTN gateways). However, there are many different > types of PSTN > >gateways; the broad delineation is between media gateway > controllers (that > >manage 'dumb' gateways) and self-contained 'smart' gateways. > The formal > >distinction here between smart and dumb gateways is that > smart gateways > >speak the call setup protocol (like SIP) and presumably the gateway > >registration protocol themselves, whereas dumb gateways > speak only a device > >control protocol (like Megaco), and rely on their MGC to > handle call setup > >and gateway registration protocols. > > > >In the field, smart gateways commonly have low capacities > (on the order of a > >couple of DS1s) whereas the scale of dumb gateways can get > very large (many > >DS3s). High-density dumb gateways tend to have support for > SS7 intermachine > >trunks (IMTs), whereas low-density smart gateways often > forgo IMT support > >for ISDN PRI or MF support; the signaling channels for each > PRI and MF > >trunks physically terminate on the gateway, but SS7 requires > a consolidated > >point at which signaling arrives for the trunks associated > with multiple > >gateways, and hence is conducive to the MGC/dumb gateway > model. Some very > >low-density residential gateways support POTS lines on the > DS0 level, but > >I'm not considering them in this architecture. > > > >For reasons of economics, operation and management, among > others, large > >carriers are predominantly SS7-based, so I'm going to assume > that MGCs and > >large dumb gateways constitute the majority of the network > in this scenario. > >Smaller smart gateways may also be sparing deployed in the > network to face > >specific resources (mostly PBXs). > > > > > > > > > > Trunks > > Gateway > > Registration > > IMT > > Carrier Architecture +----+ ----> +1 > > (H.248)| | > > Device +---- | GW1| ----> > +1703,+1571... > > > > Control| | | > > | +----+ ----> > +1202,+1703... > >[TG1] > > | > > | IMT > > | +----+ ----> +1 > > (SIP) +-----+ | | | > > +----------->| MGC |----+-----| GW2| ----> > +1540,+1804... > > > > | +--+--+ | | | > > | | | +----+ ----> > +1202,+1703... > >[TG1] > > | | | > > Call +----------+ | | IMT > > Setup | | | | +----+ ----> +1 > > (SIP) | Routing | | | | | > > -------->| Proxy | | +-----| GW3| ----> > +1202555, > >+122544... > > | (LS) | | | | > > +----------+ | +----+ ----> +44 > > | | | SS7 > > | | +------------------------> > TO PSTN > > | | > > | | > > | | +----+ PRI (B&D) > > | +-------------------------->| GW4| ----> > +1202533 > > | +----+ > > | (SIP) > > | +----+ MF > > +-------------------------------> GW5| ----> > +1703989 > > +----+ > > > >In the above picture, I envision that the gateway > registration protocol > >would be spoken between all of the entities that speak SIP. > > > >By way of explanation, the diagram above shows multiple > bundles of DS0 > >circuits (we'll refer to them as trunks) associated with > each of the large > >dumb gateways (GW1, GW2 and GW3). One or more E.164 number ranges is > >associated with each of these trunks. '+1' indicates that > all of the United > >States is reachable through this trunk (probably, this is a > trunk to an > >interexchange carrier). The second trunk on GW1 (pointed to > +1703,+1571...) > >contains a set of reachable area codes within a rate center, > suggesting that > >the trunk is associated with a LEC tandem. The second trunk > on GW3 (pointed > >to +1202555, +1202544...) is associated with a set of > specific exchange > >codes, and is therefore probably an end office trunk > pointing to a class 5 > >switch. The smaller gateways (GW4 and GW5) have trunks that > are associated > >with customers, possibly PBXs. Finally, note that logical > 'trunk groups' can > >span multiple gateways, as is the case with [TG1], the third > trunks on GW1 > >and GW2 (each pointing to +1202,+1703...). > > > >Jonathan noted that the charter permits gateway registration for 'the > >exchange of dynamic information' rather than reliability or > scalability. I > >think it is important to note that the reason why the > exchange of dynamic > >information is interesting to a carrier network is that it > facilitates > >provisioning and network management. I don't think that > autodiscovery of the > >LS by MGCs or vice versa would really make this system > substantially easier > >to manage or provision in any obvious way. > > > >To my mind, the fundamental question about gateway > registration in this > >architecture is 'what are the resources whose availability > is advertised by > >gateway registration?'. I think it needs to be some > combination of the > >following: > > > >- Availability of a gateway itself. In the case in which an > MGC performs > >gateway registration, it could notify the LS of the > availability of any > >individual gateway (for example GW1 above). If a standalone > gateway (like > >GW4) does not go offline gracefully, then of course no gateway > >de-registration message could be sent, but the LS would > presumably have some > >other mechanism (absence of keepalive messages) to determine that the > >gateway is unavailable. Since an MGC is not coupled to physical trunk > >resources, it can take advantage of reliability mechanisms > that a standalone > >gateway cannot, and therefore it is well positioned to > broker availability > >information for gateways. Either way, clearly the > availability of gateway > >themselves can be made known to the LS. > > > >- Availability of a number prefix/address. This is the > traditional TRIP > >model, in which an E.164 range (e.g. '+1303') is propagated > from the gateway > >to the LS. This model works best, I think, in the case of > standalone smart > >gateways (like GW4). In the MGC case, it is harder to see > what prefixes > >should be propagated by the MGC to the LS - merely > propagating that '+1' is > >available through the MGC doesn't take into account the > different policies > >that are potentially available on different trunks. In other > words, the big > >open issue here is whether the MGC should aggregate routes > on behalf of its > >gateways or not, and if so, how. Also note that in order to > allow for more > >complex PSTN features, routing by location routing numbers > and carrier > >identification codes should also be permitted, and that the > availability of > >particular CICs or LRNs through an MGC should be advertised. > > > >- Availability of a trunk/PSTN interface on a gateway. > Gateways generally > >have more than one physical interface capable of supporting > a trunk. If a > >trunk has been established on a physical interface, it will > have one of many > >dynamic states (more precisely, the states on a trunk are an > aggregate of > >the states of its constituent circuts if no trunk-level > events are taking > >place); trunks can be busy, administratively blocked, idle, > and so forth. > >Trunks also have many different static attributes (some of which are > >detailed below). Clearly, the availability of particular > number ranges in a > >gateway is dependent on the availability of trunks (i.e. if > the third trunk > >on GW3 goes off-line, then the +44 country code will no > longer be available > >in the MGC). For the purposes of scalability, a more useful > construct is a > >logical set of circuits known as a trunk group which allows > multiple trunks > >(potentially on different physical interfaces) to be grouped > under the same > >set of attributes and policies. A trunk group can also span multiple > >gateways (as [TG1] spans the third circuits of GW1 and GW2) > in order to > >provide greater reliability. Consider, for example, that if > GW2 were to go > >offline, the trunk group consisting of the third trunks of > GW1 and GW2 would > >still be available (with diminished capacity). Note that > these properties of > >trunk groups also generally apply to ISDN NFAS trunks. > > > >I suspect that bundling number prefix/address-based routed > into trunk groups > >is the right way for an MGC to aggregate routes for delivery > to an LS. > > > >Many static attributes that proxy servers might use for > routing decisions > >have dependencies on trunk groups. Some that come to mind: > > > >- A trunk group has directionality. It may be one-way > inbound, one-way > >outbound, or two-way. > > > >- The protocol used to establish calls on the trunk. In some > instances, VoIP > >messages might rely on signaling mechanisms that are specific to a > >particular PSTN termination protocol. A good example would > be if number > >portability information is present in the VoIP signaling data - this > >information will be lost if the call terminates on a PRI > trunk (possibly > >resulting in an error condition). > > > >Even addresses can usefully be construed as attributes of > trunk group: > > > >- There is one and only one carrier that is responsible for > the switch on > >the other side of the trunk. One or more carrier > identification codes can be > >associated with a carrier. Of course, other carriers are > also probably > >reachable through the remote carrier's network. > > > >- Trunks to end offices may be associated with a location > routing number > >(LRN) used to route calls for local number portability. Each > NP-compliant > >end office switch in the (USA) PSTN is associated with one LRN. > > > >Note that neither of these forms of address are > international in scope, and > >therefore the set of all the carrier identification codes in > the world is > >not reachable by an ISUP signal sent through an American trunk. > > > >Interestingly, I think most of the dynamic information that would be > >exchanged by gateway registration messages are attributes of > trunk groups. > >For instance: > > > >- The total capacity of a trunk might seem like a static > attribute, but over > >the long term it is actually dynamic. Existing trunk groups > are augmented. > >The total capacity of a trunk group can change over time due > to capacity > >constraints. Large carriers are constantly in the process of > augmenting > >exist trunks. The addition of circuits to an existing trunk group is > >preferable to creating new trunk groups when the attributes > of the trunk > >remain the same. > > > >- Trunk groups fill up with calls. If a trunk group is > one-way outbound, > >then in some architectures an LS could track the congestion > of particular > >trunk groups itself without any gateway registration > attributes. However, if > >the trunk group is two-way, it is much more difficult for an > LS to keep an > >accurate count of idle circuits in a trunk group without > reporting from > >gateways. One of the difficult problems with propagating > dynamic capacity is > >the thresholds for reporting - sending a gateway > registration message each > >time the state of a single circuit changes is probably not > feasible, so > >perhaps some fuzzier states for the entire trunk group (e.g. > 'almost full') > >would be needed. > > > >- Trunk groups are created and destroyed. Switches > associated with major > >carriers are in an almost constant state of creating trunk groups as > >connections to new switches are required or connections to > existing switches > >require augmentation with distinct policies. > > > >- Trunk groups have maintenance conditions - most notably > blocking and > >unblocking. Sending a block for a trunk group prevents new > calls from being > >received on the group. Blocking can be used when a hardware > failure occurs > >that takes a trunk out of service, or as a pre-emptive > measure (quiescence) > >to empty a trunk gradually. > > > >That's probably a good start as far as describing the > architecture goes. > > > >Jon Peterson > >NeuStar, Inc > > > > > >_______________________________________________ > >IPTEL mailing list > >IPTEL@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Dec 5 11:37:55 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA26981 for ; Wed, 5 Dec 2001 11:37: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 14C91443A1; Wed, 5 Dec 2001 10:25:09 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from pentagon.cisco.com (pentagon.cisco.com [161.44.85.169]) by lists.bell-labs.com (Postfix) with ESMTP id 72D6A44396 for ; Wed, 5 Dec 2001 10:24:58 -0500 (EST) Received: from cia.cisco.com (mirapoint@cia.cisco.com [161.44.85.200]) by pentagon.cisco.com (8.8.5-Cisco.1/8.6.5) with ESMTP id LAA01788; Wed, 5 Dec 2001 11:37:09 -0500 (EST) Received: from MHAMMER-W2K.cisco.com (hrn2-dhcp-161-44-87-145.cisco.com [161.44.87.145]) by cia.cisco.com (Mirapoint) with ESMTP id AUB01614; Wed, 5 Dec 2001 11:37:19 -0500 (EST) Message-Id: <4.3.2.7.2.20011205111716.00b3a528@cia.cisco.com> X-Sender: mhammer@cia.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: "Peterson, Jon" From: Michael Hammer Subject: RE: [IPTEL] carrier scenario for TRIP Cc: "'iptel@lists.bell-labs.com'" In-Reply-To: <70565611B164D511957A001083FCDD56CAACCE@va02.va.neustar.com > Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 05 Dec 2001 11:42:45 -0500 Jon, I'm a little uneasy about the wording in that definition for Trunk. We need to maintain the idea that the "communication PATH" is an individual circuit. The reason is that the DS0's need to be managed individually. The use of "path" can be confusing. Looking at ATM, the VCI is a trunk, the VPI (path) is a trunk group, even though the VCI capacity may exceed that of a DS0. On the other hand, a circuit in the packet world may map to a "bundle of DS0s" i.e. trunk group in the TDM world. So, can we stick to trunks (=DS0) and trunk groups (=bundles of DS0) for the TDM (not packet) domain, and use circuits and paths (or other aggregation terms) in the packet domain, and not mix the two? The unifying concept is that the lowest unit serves one user at a time, while the aggregate may be supporting streams from different users. Mike At 10:24 PM 12/4/2001 -0600, Peterson, Jon wrote: >Whoops - sent an incomplete version of this. Please disregard my preceding >mail. > >----- > >Agreed that it's important that we define 'trunk group' precisely if we >intend to use it in any meaningful way. I'd suggest we refer to the >definitions from SR2275: > >Trunk: In a network, a communication path connecting two switching systems >used in the establishment of an end-to-end connection. In selected >applications, it may have both its terminations in the same switching >system. > >Trunk group: A set of trunks, traffic engineered as a unit, for the >establishment of connections within or between switching systems in which >all of the paths are interchangeable except where subgrouped. > >I believe that since the introduction of ubiquitous digital trunking, which >resulted in the allocation of DS0s between end offices in minimum groups of >24, it has become common to refer to bundles of DS0s as a trunk. You're >right that we shouldn't further any confusion about this matter - but >provided that we all understand that a TG is a bundle of DS0s between end >offices, I think we'll be all right. > >I was certainly thinking that a protocol like H.248 would be used between an >MGC and any gateways it controls. I definitely agree that no new protocol >should be required between the MGC and its gateways in support of gateway >registration - and that if there is any new package or what have you that's >required for the device control protocol that it shouldn't be pursued in the >IPTEL WG. I also firmly agree that any endpoint that speaks the call setup >protocol (i.e. SIP) should speak the gateway registration protocol - I hope >this comes through as my contention in the write-up. > >Jon Peterson >NeuStar, Inc. > > > -----Original Message----- > > From: Michael Hammer [mailto:mhammer@cisco.com] > > Sent: Tuesday, December 04, 2001 12:46 PM > > To: Peterson, Jon > > Cc: 'iptel@lists.bell-labs.com' > > Subject: Re: [IPTEL] carrier scenario for TRIP > > > > > > Jon, > > > > A trunk is a single circuit (DS0) between two switching nodes that is > > shared on a call-by-call basis, as opposed to a local loop > > that serves only > > one user (telephone number address, excepting party lines). > > A trunk group > > is a bundle of DS0's and the first level of aggregation. > > (Please don't > > propagate the confusion that a trunk is more than one > > circuit.) After that > > you can address Routes and Route Sets/Lists as higher echelons of > > aggregation. Those lists may be ordered and unordered. > > > > I suspect that H.248 and MGCP are used for communications > > between the MGC > > and MGW involving the availability and status of the MGW. > > The MGC should > > be able to provide a complete picture of the MGW that it > > controls. Any > > suggestion that additional signaling of this nature is needed > > should be > > deferred to the Megaco WG rather than addressed here. To > > distinguish smart > > and dumb gateways, you might want to stipulate that the > > signaling endpoint > > for the gwreg protocol should be capable of terminating session/call > > signaling (i.e., SIP). > > > > Otherwise, this is a great writeup. Furthermore, I agree > > with the need to > > have additional attributes like LRN's and Carrier ID's that > > add context to > > the indication that a number is "reachable." While this > > won't completely > > address the "cost" issue, it can give great clues about where > > to direct > > signaling to get sessions setup to the "best" gateways. > > > > Mike > > > > > > At 02:06 PM 11/30/2001 -0600, Peterson, Jon wrote: > > >I'd like to describe a particular scenario for gateway > > registration, namely, > > >a case in which it could be used by a large US-based VoIP carrier. > > > > > >The sort of carrier network I'm envisioning is composed of entities > > >responsible for routing call setup requests (like SIP proxy > > servers) and > > >entities that generate and receive call setup requests (in > > the scope of this > > >problem, PSTN gateways). However, there are many different > > types of PSTN > > >gateways; the broad delineation is between media gateway > > controllers (that > > >manage 'dumb' gateways) and self-contained 'smart' gateways. > > The formal > > >distinction here between smart and dumb gateways is that > > smart gateways > > >speak the call setup protocol (like SIP) and presumably the gateway > > >registration protocol themselves, whereas dumb gateways > > speak only a device > > >control protocol (like Megaco), and rely on their MGC to > > handle call setup > > >and gateway registration protocols. > > > > > >In the field, smart gateways commonly have low capacities > > (on the order of a > > >couple of DS1s) whereas the scale of dumb gateways can get > > very large (many > > >DS3s). High-density dumb gateways tend to have support for > > SS7 intermachine > > >trunks (IMTs), whereas low-density smart gateways often > > forgo IMT support > > >for ISDN PRI or MF support; the signaling channels for each > > PRI and MF > > >trunks physically terminate on the gateway, but SS7 requires > > a consolidated > > >point at which signaling arrives for the trunks associated > > with multiple > > >gateways, and hence is conducive to the MGC/dumb gateway > > model. Some very > > >low-density residential gateways support POTS lines on the > > DS0 level, but > > >I'm not considering them in this architecture. > > > > > >For reasons of economics, operation and management, among > > others, large > > >carriers are predominantly SS7-based, so I'm going to assume > > that MGCs and > > >large dumb gateways constitute the majority of the network > > in this scenario. > > >Smaller smart gateways may also be sparing deployed in the > > network to face > > >specific resources (mostly PBXs). > > > > > > > > > > > > > > > Trunks > > > Gateway > > > Registration > > > IMT > > > Carrier Architecture +----+ ----> +1 > > > (H.248)| | > > > Device +---- | GW1| ----> > > +1703,+1571... > > > > > > Control| | | > > > | +----+ ----> > > +1202,+1703... > > >[TG1] > > > | > > > | IMT > > > | +----+ ----> +1 > > > (SIP) +-----+ | | | > > > +----------->| MGC |----+-----| GW2| ----> > > +1540,+1804... > > > > > > | +--+--+ | | | > > > | | | +----+ ----> > > +1202,+1703... > > >[TG1] > > > | | | > > > Call +----------+ | | IMT > > > Setup | | | | +----+ ----> +1 > > > (SIP) | Routing | | | | | > > > -------->| Proxy | | +-----| GW3| ----> > > +1202555, > > >+122544... > > > | (LS) | | | | > > > +----------+ | +----+ ----> +44 > > > | | | SS7 > > > | | +------------------------> > > TO PSTN > > > | | > > > | | > > > | | +----+ PRI (B&D) > > > | +-------------------------->| GW4| ----> > > +1202533 > > > | +----+ > > > | (SIP) > > > | +----+ MF > > > +-------------------------------> GW5| ----> > > +1703989 > > > +----+ > > > > > >In the above picture, I envision that the gateway > > registration protocol > > >would be spoken between all of the entities that speak SIP. > > > > > >By way of explanation, the diagram above shows multiple > > bundles of DS0 > > >circuits (we'll refer to them as trunks) associated with > > each of the large > > >dumb gateways (GW1, GW2 and GW3). One or more E.164 number ranges is > > >associated with each of these trunks. '+1' indicates that > > all of the United > > >States is reachable through this trunk (probably, this is a > > trunk to an > > >interexchange carrier). The second trunk on GW1 (pointed to > > +1703,+1571...) > > >contains a set of reachable area codes within a rate center, > > suggesting that > > >the trunk is associated with a LEC tandem. The second trunk > > on GW3 (pointed > > >to +1202555, +1202544...) is associated with a set of > > specific exchange > > >codes, and is therefore probably an end office trunk > > pointing to a class 5 > > >switch. The smaller gateways (GW4 and GW5) have trunks that > > are associated > > >with customers, possibly PBXs. Finally, note that logical > > 'trunk groups' can > > >span multiple gateways, as is the case with [TG1], the third > > trunks on GW1 > > >and GW2 (each pointing to +1202,+1703...). > > > > > >Jonathan noted that the charter permits gateway registration for 'the > > >exchange of dynamic information' rather than reliability or > > scalability. I > > >think it is important to note that the reason why the > > exchange of dynamic > > >information is interesting to a carrier network is that it > > facilitates > > >provisioning and network management. I don't think that > > autodiscovery of the > > >LS by MGCs or vice versa would really make this system > > substantially easier > > >to manage or provision in any obvious way. > > > > > >To my mind, the fundamental question about gateway > > registration in this > > >architecture is 'what are the resources whose availability > > is advertised by > > >gateway registration?'. I think it needs to be some > > combination of the > > >following: > > > > > >- Availability of a gateway itself. In the case in which an > > MGC performs > > >gateway registration, it could notify the LS of the > > availability of any > > >individual gateway (for example GW1 above). If a standalone > > gateway (like > > >GW4) does not go offline gracefully, then of course no gateway > > >de-registration message could be sent, but the LS would > > presumably have some > > >other mechanism (absence of keepalive messages) to determine that the > > >gateway is unavailable. Since an MGC is not coupled to physical trunk > > >resources, it can take advantage of reliability mechanisms > > that a standalone > > >gateway cannot, and therefore it is well positioned to > > broker availability > > >information for gateways. Either way, clearly the > > availability of gateway > > >themselves can be made known to the LS. > > > > > >- Availability of a number prefix/address. This is the > > traditional TRIP > > >model, in which an E.164 range (e.g. '+1303') is propagated > > from the gateway > > >to the LS. This model works best, I think, in the case of > > standalone smart > > >gateways (like GW4). In the MGC case, it is harder to see > > what prefixes > > >should be propagated by the MGC to the LS - merely > > propagating that '+1' is > > >available through the MGC doesn't take into account the > > different policies > > >that are potentially available on different trunks. In other > > words, the big > > >open issue here is whether the MGC should aggregate routes > > on behalf of its > > >gateways or not, and if so, how. Also note that in order to > > allow for more > > >complex PSTN features, routing by location routing numbers > > and carrier > > >identification codes should also be permitted, and that the > > availability of > > >particular CICs or LRNs through an MGC should be advertised. > > > > > >- Availability of a trunk/PSTN interface on a gateway. > > Gateways generally > > >have more than one physical interface capable of supporting > > a trunk. If a > > >trunk has been established on a physical interface, it will > > have one of many > > >dynamic states (more precisely, the states on a trunk are an > > aggregate of > > >the states of its constituent circuts if no trunk-level > > events are taking > > >place); trunks can be busy, administratively blocked, idle, > > and so forth. > > >Trunks also have many different static attributes (some of which are > > >detailed below). Clearly, the availability of particular > > number ranges in a > > >gateway is dependent on the availability of trunks (i.e. if > > the third trunk > > >on GW3 goes off-line, then the +44 country code will no > > longer be available > > >in the MGC). For the purposes of scalability, a more useful > > construct is a > > >logical set of circuits known as a trunk group which allows > > multiple trunks > > >(potentially on different physical interfaces) to be grouped > > under the same > > >set of attributes and policies. A trunk group can also span multiple > > >gateways (as [TG1] spans the third circuits of GW1 and GW2) > > in order to > > >provide greater reliability. Consider, for example, that if > > GW2 were to go > > >offline, the trunk group consisting of the third trunks of > > GW1 and GW2 would > > >still be available (with diminished capacity). Note that > > these properties of > > >trunk groups also generally apply to ISDN NFAS trunks. > > > > > >I suspect that bundling number prefix/address-based routed > > into trunk groups > > >is the right way for an MGC to aggregate routes for delivery > > to an LS. > > > > > >Many static attributes that proxy servers might use for > > routing decisions > > >have dependencies on trunk groups. Some that come to mind: > > > > > >- A trunk group has directionality. It may be one-way > > inbound, one-way > > >outbound, or two-way. > > > > > >- The protocol used to establish calls on the trunk. In some > > instances, VoIP > > >messages might rely on signaling mechanisms that are specific to a > > >particular PSTN termination protocol. A good example would > > be if number > > >portability information is present in the VoIP signaling data - this > > >information will be lost if the call terminates on a PRI > > trunk (possibly > > >resulting in an error condition). > > > > > >Even addresses can usefully be construed as attributes of > > trunk group: > > > > > >- There is one and only one carrier that is responsible for > > the switch on > > >the other side of the trunk. One or more carrier > > identification codes can be > > >associated with a carrier. Of course, other carriers are > > also probably > > >reachable through the remote carrier's network. > > > > > >- Trunks to end offices may be associated with a location > > routing number > > >(LRN) used to route calls for local number portability. Each > > NP-compliant > > >end office switch in the (USA) PSTN is associated with one LRN. > > > > > >Note that neither of these forms of address are > > international in scope, and > > >therefore the set of all the carrier identification codes in > > the world is > > >not reachable by an ISUP signal sent through an American trunk. > > > > > >Interestingly, I think most of the dynamic information that would be > > >exchanged by gateway registration messages are attributes of > > trunk groups. > > >For instance: > > > > > >- The total capacity of a trunk might seem like a static > > attribute, but over > > >the long term it is actually dynamic. Existing trunk groups > > are augmented. > > >The total capacity of a trunk group can change over time due > > to capacity > > >constraints. Large carriers are constantly in the process of > > augmenting > > >exist trunks. The addition of circuits to an existing trunk group is > > >preferable to creating new trunk groups when the attributes > > of the trunk > > >remain the same. > > > > > >- Trunk groups fill up with calls. If a trunk group is > > one-way outbound, > > >then in some architectures an LS could track the congestion > > of particular > > >trunk groups itself without any gateway registration > > attributes. However, if > > >the trunk group is two-way, it is much more difficult for an > > LS to keep an > > >accurate count of idle circuits in a trunk group without > > reporting from > > >gateways. One of the difficult problems with propagating > > dynamic capacity is > > >the thresholds for reporting - sending a gateway > > registration message each > > >time the state of a single circuit changes is probably not > > feasible, so > > >perhaps some fuzzier states for the entire trunk group (e.g. > > 'almost full') > > >would be needed. > > > > > >- Trunk groups are created and destroyed. Switches > > associated with major > > >carriers are in an almost constant state of creating trunk groups as > > >connections to new switches are required or connections to > > existing switches > > >require augmentation with distinct policies. > > > > > >- Trunk groups have maintenance conditions - most notably > > blocking and > > >unblocking. Sending a block for a trunk group prevents new > > calls from being > > >received on the group. Blocking can be used when a hardware > > failure occurs > > >that takes a trunk out of service, or as a pre-emptive > > measure (quiescence) > > >to empty a trunk gradually. > > > > > >That's probably a good start as far as describing the > > architecture goes. > > > > > >Jon Peterson > > >NeuStar, Inc > > > > > > > > >_______________________________________________ > > >IPTEL mailing list > > >IPTEL@lists.bell-labs.com > > >http://lists.bell-labs.com/mailman/listinfo/iptel > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Dec 5 14:51:16 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06865 for ; Wed, 5 Dec 2001 14:51: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 620A8443A9; Wed, 5 Dec 2001 13:39:03 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from ietf.org (odin.ietf.org [132.151.1.176]) by lists.bell-labs.com (Postfix) with ESMTP id 2BD5244337 for ; Mon, 3 Dec 2001 07:25:38 -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 IAA28997; Mon, 3 Dec 2001 08:37:29 -0500 (EST) Message-Id: <200112031337.IAA28997@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: iptel@lists.bell-labs.com From: Internet-Drafts@ietf.org Reply-To: Internet-Drafts@ietf.org Subject: [IPTEL] I-D ACTION:draft-ietf-iptel-cpl-05.txt,.ps Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 03 Dec 2001 08:37:29 -0500 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : CPL: A Language for User Control of Internet Telephony Services Author(s) : J. Lennox, H. Schulzrinne Filename : draft-ietf-iptel-cpl-05.txt,.ps Pages : 68 Date : 30-Nov-01 The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agent servers. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. This document is a product of the IP Telephony (IPTEL) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at iptel@lists.research.bell-labs.com and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-cpl-05.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-iptel-cpl-05.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: <20011130160719.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-cpl-05.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-iptel-cpl-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20011130160719.I-D@ietf.org> --OtherAccess-- --NextPart-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Dec 5 17:19:15 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16223 for ; Wed, 5 Dec 2001 17:19: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 BD0DF443AE; Wed, 5 Dec 2001 16:07:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from Mitel.COM (unknown [216.191.234.70]) by lists.bell-labs.com (Postfix) with ESMTP id 0655D443AA for ; Wed, 5 Dec 2001 16:06:10 -0500 (EST) Received: from Software.Mitel.COM (software [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id RAA05947 for ; Wed, 5 Dec 2001 17:18:25 -0500 (EST) Received: from site.uottawa.ca ([134.199.40.54]) by Software.Mitel.COM (V8/MAIL-HUB-2.0) with ESMTP id RAA12568 for ; Wed, 5 Dec 2001 17:18:16 -0500 (EST) Message-ID: <3C0E9D28.4F03CE1F@site.uottawa.ca> From: Daniel Amyot Organization: Mitel Corporation X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] Negation in CPL Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 05 Dec 2001 17:18:16 -0500 Content-Transfer-Encoding: 7bit Hello, I have been taking a closer look at CPL recently and concluded that it would be difficult to create and maintain a single CPL script for a complex set of rules/policies. Now, if I go with multiple scripts (one per user policy) and assume that they are ordered according to their priority (total ordering), I find myself facing a few other problems. For instance, imagine a rule like: Forward any call to Radiology except if the call is from Jacques. Then, two scripts are created: (priority 1: default action, i.e. lets calls from Jacques go through)
(priority 2: redirect all calls to Radiology) The first rule will cause conflicts with any other rules focusing on Jacques (e.g. forward calls from Jacques to my cell phone), whereas the second will cause many more problems in general. What would be useful to me here is the negation of "contains", something like:
Right now, CPL supports OTHERWISE, but this still creates problems with other rules based on Jacques that have a lower priority (the latter won't get fired, although they should according to the user's expectations):
Is there any good way of representing exceptions in this context? Can we do so without support for negative matching of some witches (does-not-contains, is-not, ...)? Was this discussed in the past? Thank you, Daniel Amyot Mitel Networks _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Dec 6 10:20:22 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27289 for ; Thu, 6 Dec 2001 10:20: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 CB6B9443E9; Thu, 6 Dec 2001 09:08:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id C6C94443D7 for ; Thu, 6 Dec 2001 09:07:36 -0500 (EST) Received: from attrh1i.attrh.att.com ([135.71.62.10]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fB6FJhZ27289 for ; Thu, 6 Dec 2001 10:19:44 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh1i.attrh.att.com (5.5.029) id 3C0BA3A50002CBA0; Thu, 6 Dec 2001 10:18:52 -0500 Subject: RE: [IPTEL] iptel-gwreg-req open issues Message-ID: <62DA45D4963FA747BA1B253E266760F9782858@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] iptel-gwreg-req open issues Thread-Index: AcF8mgHJDxAXCuiJEdWY1QCQJ3s6pwAgNwWwADMeqFA= From: "Roy, Radhika R, ALCTA" content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 To: "Peterson, Jon" , Cc: Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 5 Dec 2001 18:51:42 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA27289 [Re-sending it assuming this did not go through as I did not receive a copy from the reflector. My apologies if anyone gets more that one copy.] -----Original Message----- From: Roy, Radhika R, ALCTA Sent: Tuesday, December 04, 2001 7:34 PM To: 'Peterson, Jon'; 'iptel@lists.bell-labs.com' Subject: RE: [IPTEL] iptel-gwreg-req open issues Please see my comments inline [RRR]. By the way, let me also make a proposal that both ITRP and TRIP-GW draft can be combined to make it a subset of TRIP through modifications that can be used for the intra-ITAD communications. In this case, we get an excellent uniformity in protocol for both intra-ITAD and inter-ITAD [TRIP] that uses the same message formats. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Tuesday, December 04, 2001 3:04 AM To: Roy, Radhika R, ALCTA; 'iptel@lists.bell-labs.com' Subject: RE: [IPTEL] iptel-gwreg-req open issues While I don't want to comment extensively on matters that aren't in the current scope of the WG, I do agree that we need to be somewhat flexible about how we understand the term 'gateway'. [RRR] Let us discuss this in "quantitative" manner for the intra-ITAD communications. In our case, a GW provides protocol conversion between SIP and other protocol (ISUP, H.323, or BICC, etc.) and will have to deal with two important parameters: 1. (Primarily) Addresses and 2. Capacity (if applicable). For example, I think most IP PBXs could qualify as gateways - but the H.323-SIP gateway sounds like a tougher case to support. [RRR] Why do you think that SIP-H.323 GW is a tougher case to support? [RRR] The specifications and characteristics of the SIP-H.323 GW may be a sub-set than those of the SIP-ISUP GW. May be we need to add few more fields in the address space. All we need to do is use a protocol for "registration" of the GWs. I believe that IETF cannot afford to build one "registration" protocol for SIP-ISUP GW, another for SIP-H.323 GW, another for SIP-BICC GW, and so on while the same protocol can be used. That is why, all of us have agreed that the protocol needs to be extensible. As I understand it, the current restriction in WG scope is intended to prevent us from straying into subjects like service registration. [RRR] Yes, "service" registration is completely different from that of the GW registration. (BTW, if you are interested to work on service registration, let us define the scope of work of the service registration and its functional requirements. We can go from there because it has different context. I have some interest to look into it.) Perhaps we need some sharper way of defining gateways; maybe we could rely on the device having a PSTN circuit switched interface as a litmus test. [RRR] I have provided a simpler definition as stated above. We can start to iterate it from there. [RRR] (Per your suggestion, if we take SIP-ISUP GW as a litmus test, it will have the attributes like telephone addresses [only E.164 and their family] and circuit capacity [with many parameters]. A SIP-H.323 GW will have telephone addresses, email IDs, URL IDs, etc. (and may be capacity - as simple as port numbers.) I would note that if your 'gateways' are propagating information about email addresses and so forth they go beyond the capabilities I commonly associate with a gateway. [RRR] A GW provides the association of the addresses when a call comes to it and addresses are provided on the call signaling messages. So, it is the application that decides what kinds of addresses will be there and the location server (in our case) will decide which GWs the calls need to be destined for those destination addresses. So, this is a simple generalized logic. (For example, ITU-T Rec. H.225.0 Annex G can be seen how all kinds of addresses are taken care of. The draft-roy-iptel-itrp-00 can also be seen for this purpose.) I also think we agree that there is no obvious reason why the same protocol needs to be used for the discovery and registration. [RRR] It is always better to use the same protocol. If it is a problem, people need to quantify it. (I have provided contribution draft-roy-iptel-itrp-00 that uses the same protocol. Is that a problem? All I have said that we may keep the "discovery" mechanism away for the sake of making progress for now. We can use this one later either using the same protocol or different protocol.) Personally, I would be happy to solve the registration problem prior to investigating discovery - but then again, there may be an overwhelming public sentiment that these two capabilities have an equal priority or that they need to wrapped into the same protocol. [RRR] The draft-roy-iptel-itrp-00 wrap this two into the same protocol. (Personally, I do not see any problems.) If there is any reason why these two features should be tightly coupled, I for one would like to understand it. [RRR] The only reason that I see that there is a benefit to use the same protocol suit to minimize the protocol development and to make easy for implementation. [RRR] By the way, let me make a proposal that both ITRP and TRIP-GW draft can be combined to make it a subset of TRIP through modifications that can be used for the intra-ITAD communications. In this case, we get an excellent uniformity in protocol for both intra-ITAD and inter-ITAD [TRIP] that uses the same message formats. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Monday, December 03, 2001 6:09 PM > To: Peterson, Jon; 'iptel@lists.bell-labs.com' > Subject: RE: [IPTEL] iptel-gwreg-req open issues > > > Hi, Jon: > > It is a good start for discussion via emails as all of us may not > participate in the IETF-52 Salt Lake meeting. I appreciate > your thoughtful > comments. > > In fact, I am delighted to see that we are almost in full agreement. > > My comments are inline [RRR]. > > Best regards, > > Radhika R. Roy > rrroy@att.com > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Friday, November 30, 2001 3:15 PM > To: 'iptel@lists.bell-labs.com' > Subject: [IPTEL] iptel-gwreg-req open issues > > > > A few comments on the open issues listed in the draft. > > REQ 6- I think this is a real requirement. I think that in > many complex > architectures (such as ones in which MGCs are used as gateways), the > provisioning of ranges of POTS numbers associated with > gateways must be > performed in multiple locations (proxy servers and gateways, > at least) if > there is not some sort of gwreg mechanism that allows you to > provision in > one place and then automatically propagate the data to any > other systems > that need it. In my opinion, simplifying provisioning is one > of the primary > reasons to use gateway registration. If you have to substantially > pre-provision proxies then I don't think gateway registration > makes your > life that much easier. > ... > > [RRR] Yes, I agree with you because it is the intra-ITAD > environment where a > single carrier/service provider wants to AUTO-provision (not > pre-provisioned) in order to avoid error-prone and costly manual > configurations. This requires communications between the GWs > and the LSs > and, registration is one of the important items. A GW can be > a SIP-ISUP > Interworking Telephony GW (e.g., MGC - signaling entity) or a > SIP-H.323 > Interworking GW (e.g., IWF - signaling entity). > > > REQ 8- I really think the gwreg protocol should be > extensible, even if we > aren't sure how we'd like to extend it at the moment. As for > whether these > attributes are attributed to routes or gateways, I'd actually > suggest a > third alternative for consideration - trunk groups. My > carrier architecture > provides a few examples of how such dynamic data depends on > trunk groups > rather than gateways. > > [RRR] You are right and protocol MUST be flexible enough to > accommodate this > (i.e., protocol must NOT be hard-wired for a particular > thing). For example, > when we say that a GW registers addresses, the addresses can > be E.164, email > IDs, URL IDs, etc. as appropriate. > > REQ 11- I'm not sure I entirely understand either the > requirement or the > open issue here, but I'll take a stab at this. Since we're > considering gwreg > in the absence of intradomain route propagation, independent routing > policies amongst multiple proxies in an ITAD seems like an > unlikely issue to > address - any system in which there's a possibility that there are > independent proxies that could somehow be synchronized > requires something > like routing policy centralization or intradomain propagation. > > [RRR] Again, I think that you are right on this issue because > the whole > point is that it is an intra-ITAD situation and, we are NOT > considering, as > you have clarified, the intra-ITAD (or intradomain) "route > propagation." > Therefore, as you have explained, independent routing > policies among the > multiple proxies does NOT arise. > > Is the assumption here that if there are multiple proxies in > an ITAD, that > some gateways register with one proxy, and some gateways register with > another, perhaps depending on a POP at which the gateways are located? > (Also, is there a latent requirement here about the > cardinality of the roles > of gateways and proxies?) Clearly if two proxies in an ITAD do not > communicate with one another, and each gateway registers with > a single proxy > at a time (discounting failover), then I don't think it would even be > possible for two proxies to return the same decision. If > allowing something > along these lines is what this requirement signifies, then I > definitely > support it. > > [RRR] For all practical purposes, there will be multiple > proxies (/location > servers) in an ITAD and, we have to develop our protocol > keeping this very > practical situation in mind. Otherwise, the protocol will NOT > be complete > and will almost be useless because it will NOT work in a real > networking > environment where multiple proxies/location servers are a reality. > > [RRR] The other thing is that the protocol messages that will be used > between the GWs and the LSs, the same messages can also be > used among the > LSs to serve the purpose. It can be seen examining the > contributions that > have been made addressing this problem. > > On another angle of this, perhaps support for some sort of > load-balancing > should be its own requirement, since I'm not sure that's > entirely dependent > on multiple proxies - I'd suggest that a single proxy should > be capable of > returning different routes for two calls targeting the same > address if it > has received multiple gateway registrations matching the > parameters of the > call that have the same preference. Nor do I understand why a database > protocol would preclude load-balancing... > > [RRR] Yes, I agree with you. > > REQ 12- I'm not really sure why this sort of 'discovery' > would be needed. I > agree that static configurations are more likely. Also, I > envision that > either the gateway or the proxy could initiate the > connection. For the sort > of architecture I have in mind, it would make more sense to statically > configure the gateway with one or more proxies (each probably > associated > with a preference) to which the gateway would attempt to connect. > Cryptographic authentication could let the proxy guarantee that the > connection is desirable. > > [RRR] Jon, I beg to explain a little bit. Like REQ 6, as you have also > mentioned, the AUTO-discovery is helpful as opposed to static > configurations. However, as Jonathan mentioned (and we have also seen > examining the several contributions made in this area), the > full-fledged > auto-discovery may change the basic characteristics the > entire protocol and, > some may not like this. > > [RRR] I may tend to consider the auto-discovery as a separate > item from the > rest of the protocol development. For example, > unicast-schemes (as opposed > to multicast schemes) using DNS look-up may also be > considered for ease of > implementation, if it is considered that the multicast-based discovery > mechanism is problematic. > > [RRR] The bottom line is that I may agree with you and > Jonathan now, if we > agree that we will visit this issue later once we finish the > work of the > base protocol that will be used within the intra-ITAD (or intradomain) > excluding the discovery. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Dec 6 17:54:23 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15396 for ; Thu, 6 Dec 2001 17: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 C94654433F; Thu, 6 Dec 2001 16:42:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from usnimo.vocaltec.com (usnimo.vocaltec.com [209.117.177.152]) by lists.bell-labs.com (Postfix) with ESMTP id E19444433E for ; Thu, 6 Dec 2001 16:41:09 -0500 (EST) From: Gur_Kimchi@vocaltec.com To: iptel@lists.bell-labs.com Cc: sob@harvard.edu, jdrosen@dynamicsoft.com X-Mailer: Lotus Notes Release 5.0.3 March 21, 2000 Message-ID: X-MIMETrack: Serialize by Router on USNIMO/Vocaltec_Comm(Release 5.0.3 (Intl)|21 March 2000) at 12/06/2001 05:52:06 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: [IPTEL] more on iptel-gwreg-req Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 6 Dec 2001 17:52:01 -0500 Friends, I think some clarification on my position are in order. 1. I think Jonathan has done a great job nailing down on what the requirements are for GW registrations 2. I think in terms of model there is not such a great difference in terms of presentation between what a pstn-sip, sip-323 or sip-xyz - in all cases some basic building blocks must be communicated - and they are captured in the requirements (e.g. Media/Resource Capabilities, Termination Capabilities, and status). 3. I claim the presentation of this information (the schema) and the means by which it is communicated (the protocol) are two very distinct and separate subjects. My suggestion therefore is: A. that we define a schema, based on XML, that can be used to describe the capabilities/status of a GW, including internal "bundling" (e.g. these 23 trunks are a T1 group running PRI etc) ( I don't differentiate between the GW running out of capacity and the administrator deciding to disable G.723 because it sounds bad - or allowing +1212* while blocking +1900* - all change the presentation of the GW to the network. ) B. that we document how this document is transmitted between network elements (SIP GWs and elements that need to know, including other SIP GWs), I see three ways here: B1: provide the document as part of REGISTER, re-REGISTER when information changes. B2: allow the element that would like to know to SUBSCRIBE to the document, therefore getting NOTIFYied when the document changes (including a first NOTIFY with the document immediately following the SUBSCRIBE). B3: define protocol TRIP+-XYZ that is used to distribute these documents between elements "that need to know". C. Define the rules by which multiple documents are aggregated (probably with hints in the schema) so border elements can provide a "digest" of what multiple elements behind them support. Lastly - I think the work should be prioritized, giving highest priority to A, B1 and C - to solve existing deployment issues that already exist. - gur _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Dec 6 19:36:40 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18960 for ; Thu, 6 Dec 2001 19:36: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 ED4B7443F4; Thu, 6 Dec 2001 18:24:06 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.24.11]) by lists.bell-labs.com (Postfix) with ESMTP id 9C5BC4433E for ; Thu, 6 Dec 2001 18:23:55 -0500 (EST) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.24.14]) by sj-msg-core-2.cisco.com (8.11.3/8.9.1) with ESMTP id fB70aBE10467; Thu, 6 Dec 2001 16:36:16 -0800 (PST) Received: from cisco.com (manjax-ultra5.cisco.com [128.107.138.93]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id ABA41427; Thu, 6 Dec 2001 16:36:09 -0800 (PST) Message-ID: <3C100EF9.6AEFE79C@cisco.com> From: Manjunath Bangalore Organization: Cisco Systems Inc., San Jose, CA X-Mailer: Mozilla 4.51C-CISCOENG [en] (X11; U; SunOS 5.6 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: "Peterson, Jon" Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] carrier scenario for TRIP References: <70565611B164D511957A001083FCDD56CAACAD@va02.va.neustar.com> Content-Type: multipart/mixed; boundary="------------639CE69BEB2BB361FEB9272C" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Thu, 06 Dec 2001 16:36:10 -0800 This is a multi-part message in MIME format. --------------639CE69BEB2BB361FEB9272C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Jon, I am thinking of usage scenarios relavant to the gateway registration problem similar to what you have described. I am not sure if you have had a chance to take a look at the latest TRIP-GW draft. This draft introduces a concept of Carriers and trunk groups which lends itself well into the model that you bring out. It provides a model by which calls can be routed based on Carrier preferences in conjunction with the telephony destination or optionally be even routed at the granularity of a trunk group in an ITAD. The same holds to managing the capacity on the gateways, as regards, its trunk resources. This can be reported as the total number of trunks available for a carrier or as being associated with a Carrier's trunk group. I would like to extend the scenario described by Jon to represent the model of an VoIP based carrier or ITSP for Wholesale VoIP provider environments. The network would be comprised of different entities - Signaling servers like SIP Proxy Servers, Gateways that terminate calls to the PSTN, Location Servers, etc. The PSTN gateways are provisioned with trunk groups that connect to different interexchange carriers. A gateway can have one or more trunk groups connecting to an interexchange carrier. Trunk groups comprise a set of DS0s that have the same signaling charactersitics and are managed as one unit. Trunks connected to a carrier's network can be grouped based on different factors. It could be on a geographical basis, say for example, calls terminating to regions on the West coast, based on grades of service offered, based on pricing (Example: Least cost trunks), etc. The gateways in a provider's network potentially connect to different interexchange carriers, say Carrier A, Carrier B, Carrier X, etc. This interconnect could also be with other ITSPs. and this, I expect will potentially increase in the future as more VoIP providers come into the fray. With this background, I would like to proceed to discussing some deployment scenarios for "Voice wholesalers". Voice wholesalers typically route traffic between multiple ingress carriers or ASPs(Application Service Provider) and multiple egress carriers. A call arriving at the gateway from an ingress carrier will be routed to the appropriate egress carrier. A typical deployment of this type is shown in the enclosure Slide #1 In some cases, the wholesale provider will act as a pure TDM transit network. Customers purchase minutes from the provider and present traffic on a set of ingress trunks, each trunk assigned to a particular customer. The provider also purchases minutes or executes some form of agreement with a set of carriers or partners to terminate traffic. (Often an ingress customer may provide egress services back to the wholesale provider, acting both as a customer and vendor) The Wholesaler for instance, could harbor agreements with the local phone companies in different countries. The wholesaler's task is to route traffic between ingress and egress carriers efficiently and profitably. In some other cases, the customers and partners will present VoIP calls to the wholesaler in effect themselves acting as ITSPs. This is shown in Slide #2 Many wholesalers adopt a hybrid of the above two models, maintaining a set of trunking POPs and handing off traffic to partner ITSPs, or viceversa. This is shown in Slide #3 In all these environments, there would be a set of carrier-based policies provisioned into a policy server in the network that is representative of the ITSP's agreements with different carriers/partners. When a call enters an ITSP's network, either from a PSTN carrier or from another ITSP, the carrier policy server is consulted to determine the egress carrier to be used for the call. The call is then routed to the appropriate PSTN gateway (or Signaling Server) that is connected to that egress carrier. The call could also traverse another ITSP, and terminate calls onto certain prefered egress carriers. This can be enabled through partnerships between ITSPs. The information that is desirable to have here (at a Location Server) is knowledge of the gateway(s) (or ITSPs) that has connection with the different egress carriers. This is where Gateway registration can add value by advertising the Carrier information on the gateways to the Location Server. This information is useful to the different location/signaling servers in the provider's network or ITAD and also in other providers networks (or ITADs) Such carrier information can be shared between different providers subject to agreements. The Carrier information can be made available in the provider's network and to other providers by advertising this information from the first-hop Location Server both in I-TRIP and E-TRIP. Then, as regards to managing an ITSP's network, there is the need for efficient capacity management on the gateways. I envision that the PSTN gateways are going to get larger and carry more trunk groups to meet the demand for high call volume. It is neither feasible not adds value in reporting trunk availability updates for every call or for every few calls. What adds value is to report this availability for significant changes in availability. This is addressed by local thresholding mechanisms on the gateway, and have capacity based updates triggered by these thresholds. The question is, also if trunk availability should be reported as a gateway chacteristic or a prefix characteristic. The way I see is, it is neither. It is best expressed as an attribute of a Carrier/Trunk group. The capacity reported as a property of this combination offers the best value. In an environment driven by Carrier routing, what is desirable to know is the trunk availability on a given Carrier's trunks or in a particular trunk group of a Carrier. This lends itself well into a more scalable capacity management model. The latest TRIP-GW draft describes how to advertise Carrier/TrunkGroup information in TRIP. You can access it from: ftp://ftpeng.cisco.com/ftp/dhaval/draft-rs-trip-gw-03.txt Regards, -Manjax "Peterson, Jon" wrote: > I'd like to describe a particular scenario for gateway registration, namely, > a case in which it could be used by a large US-based VoIP carrier. > > The sort of carrier network I'm envisioning is composed of entities > responsible for routing call setup requests (like SIP proxy servers) and > entities that generate and receive call setup requests (in the scope of this > problem, PSTN gateways). However, there are many different types of PSTN > gateways; the broad delineation is between media gateway controllers (that > manage 'dumb' gateways) and self-contained 'smart' gateways. The formal > distinction here between smart and dumb gateways is that smart gateways > speak the call setup protocol (like SIP) and presumably the gateway > registration protocol themselves, whereas dumb gateways speak only a device > control protocol (like Megaco), and rely on their MGC to handle call setup > and gateway registration protocols. > > In the field, smart gateways commonly have low capacities (on the order of a > couple of DS1s) whereas the scale of dumb gateways can get very large (many > DS3s). High-density dumb gateways tend to have support for SS7 intermachine > trunks (IMTs), whereas low-density smart gateways often forgo IMT support > for ISDN PRI or MF support; the signaling channels for each PRI and MF > trunks physically terminate on the gateway, but SS7 requires a consolidated > point at which signaling arrives for the trunks associated with multiple > gateways, and hence is conducive to the MGC/dumb gateway model. Some very > low-density residential gateways support POTS lines on the DS0 level, but > I'm not considering them in this architecture. > > For reasons of economics, operation and management, among others, large > carriers are predominantly SS7-based, so I'm going to assume that MGCs and > large dumb gateways constitute the majority of the network in this scenario. > Smaller smart gateways may also be sparing deployed in the network to face > specific resources (mostly PBXs). > > > > > Trunks > Gateway > Registration > IMT > Carrier Architecture +----+ ----> +1 > (H.248)| | > Device +---- | GW1| ----> +1703,+1571... > > Control| | | > | +----+ ----> +1202,+1703... > [TG1] > | > | IMT > | +----+ ----> +1 > (SIP) +-----+ | | | > +----------->| MGC |----+-----| GW2| ----> +1540,+1804... > > | +--+--+ | | | > | | | +----+ ----> +1202,+1703... > [TG1] > | | | > Call +----------+ | | IMT > Setup | | | | +----+ ----> +1 > (SIP) | Routing | | | | | > -------->| Proxy | | +-----| GW3| ----> +1202555, > +122544... > | (LS) | | | | > +----------+ | +----+ ----> +44 > | | | SS7 > | | +------------------------> TO PSTN > | | > | | > | | +----+ PRI (B&D) > | +-------------------------->| GW4| ----> +1202533 > | +----+ > | (SIP) > | +----+ MF > +-------------------------------> GW5| ----> +1703989 > +----+ > > In the above picture, I envision that the gateway registration protocol > would be spoken between all of the entities that speak SIP. > > By way of explanation, the diagram above shows multiple bundles of DS0 > circuits (we'll refer to them as trunks) associated with each of the large > dumb gateways (GW1, GW2 and GW3). One or more E.164 number ranges is > associated with each of these trunks. '+1' indicates that all of the United > States is reachable through this trunk (probably, this is a trunk to an > interexchange carrier). The second trunk on GW1 (pointed to +1703,+1571...) > contains a set of reachable area codes within a rate center, suggesting that > the trunk is associated with a LEC tandem. The second trunk on GW3 (pointed > to +1202555, +1202544...) is associated with a set of specific exchange > codes, and is therefore probably an end office trunk pointing to a class 5 > switch. The smaller gateways (GW4 and GW5) have trunks that are associated > with customers, possibly PBXs. Finally, note that logical 'trunk groups' can > span multiple gateways, as is the case with [TG1], the third trunks on GW1 > and GW2 (each pointing to +1202,+1703...). > > Jonathan noted that the charter permits gateway registration for 'the > exchange of dynamic information' rather than reliability or scalability. I > think it is important to note that the reason why the exchange of dynamic > information is interesting to a carrier network is that it facilitates > provisioning and network management. I don't think that autodiscovery of the > LS by MGCs or vice versa would really make this system substantially easier > to manage or provision in any obvious way. > > To my mind, the fundamental question about gateway registration in this > architecture is 'what are the resources whose availability is advertised by > gateway registration?'. I think it needs to be some combination of the > following: > > - Availability of a gateway itself. In the case in which an MGC performs > gateway registration, it could notify the LS of the availability of any > individual gateway (for example GW1 above). If a standalone gateway (like > GW4) does not go offline gracefully, then of course no gateway > de-registration message could be sent, but the LS would presumably have some > other mechanism (absence of keepalive messages) to determine that the > gateway is unavailable. Since an MGC is not coupled to physical trunk > resources, it can take advantage of reliability mechanisms that a standalone > gateway cannot, and therefore it is well positioned to broker availability > information for gateways. Either way, clearly the availability of gateway > themselves can be made known to the LS. > > - Availability of a number prefix/address. This is the traditional TRIP > model, in which an E.164 range (e.g. '+1303') is propagated from the gateway > to the LS. This model works best, I think, in the case of standalone smart > gateways (like GW4). In the MGC case, it is harder to see what prefixes > should be propagated by the MGC to the LS - merely propagating that '+1' is > available through the MGC doesn't take into account the different policies > that are potentially available on different trunks. In other words, the big > open issue here is whether the MGC should aggregate routes on behalf of its > gateways or not, and if so, how. Also note that in order to allow for more > complex PSTN features, routing by location routing numbers and carrier > identification codes should also be permitted, and that the availability of > particular CICs or LRNs through an MGC should be advertised. > > - Availability of a trunk/PSTN interface on a gateway. Gateways generally > have more than one physical interface capable of supporting a trunk. If a > trunk has been established on a physical interface, it will have one of many > dynamic states (more precisely, the states on a trunk are an aggregate of > the states of its constituent circuts if no trunk-level events are taking > place); trunks can be busy, administratively blocked, idle, and so forth. > Trunks also have many different static attributes (some of which are > detailed below). Clearly, the availability of particular number ranges in a > gateway is dependent on the availability of trunks (i.e. if the third trunk > on GW3 goes off-line, then the +44 country code will no longer be available > in the MGC). For the purposes of scalability, a more useful construct is a > logical set of circuits known as a trunk group which allows multiple trunks > (potentially on different physical interfaces) to be grouped under the same > set of attributes and policies. A trunk group can also span multiple > gateways (as [TG1] spans the third circuits of GW1 and GW2) in order to > provide greater reliability. Consider, for example, that if GW2 were to go > offline, the trunk group consisting of the third trunks of GW1 and GW2 would > still be available (with diminished capacity). Note that these properties of > trunk groups also generally apply to ISDN NFAS trunks. > > I suspect that bundling number prefix/address-based routed into trunk groups > is the right way for an MGC to aggregate routes for delivery to an LS. > > Many static attributes that proxy servers might use for routing decisions > have dependencies on trunk groups. Some that come to mind: > > - A trunk group has directionality. It may be one-way inbound, one-way > outbound, or two-way. > > - The protocol used to establish calls on the trunk. In some instances, VoIP > messages might rely on signaling mechanisms that are specific to a > particular PSTN termination protocol. A good example would be if number > portability information is present in the VoIP signaling data - this > information will be lost if the call terminates on a PRI trunk (possibly > resulting in an error condition). > > Even addresses can usefully be construed as attributes of trunk group: > > - There is one and only one carrier that is responsible for the switch on > the other side of the trunk. One or more carrier identification codes can be > associated with a carrier. Of course, other carriers are also probably > reachable through the remote carrier's network. > > - Trunks to end offices may be associated with a location routing number > (LRN) used to route calls for local number portability. Each NP-compliant > end office switch in the (USA) PSTN is associated with one LRN. > > Note that neither of these forms of address are international in scope, and > therefore the set of all the carrier identification codes in the world is > not reachable by an ISUP signal sent through an American trunk. > > Interestingly, I think most of the dynamic information that would be > exchanged by gateway registration messages are attributes of trunk groups. > For instance: > > - The total capacity of a trunk might seem like a static attribute, but over > the long term it is actually dynamic. Existing trunk groups are augmented. > The total capacity of a trunk group can change over time due to capacity > constraints. Large carriers are constantly in the process of augmenting > exist trunks. The addition of circuits to an existing trunk group is > preferable to creating new trunk groups when the attributes of the trunk > remain the same. > > - Trunk groups fill up with calls. If a trunk group is one-way outbound, > then in some architectures an LS could track the congestion of particular > trunk groups itself without any gateway registration attributes. However, if > the trunk group is two-way, it is much more difficult for an LS to keep an > accurate count of idle circuits in a trunk group without reporting from > gateways. One of the difficult problems with propagating dynamic capacity is > the thresholds for reporting - sending a gateway registration message each > time the state of a single circuit changes is probably not feasible, so > perhaps some fuzzier states for the entire trunk group (e.g. 'almost full') > would be needed. > > - Trunk groups are created and destroyed. Switches associated with major > carriers are in an almost constant state of creating trunk groups as > connections to new switches are required or connections to existing switches > require augmentation with distinct policies. > > - Trunk groups have maintenance conditions - most notably blocking and > unblocking. Sending a block for a trunk group prevents new calls from being > received on the group. Blocking can be used when a hardware failure occurs > that takes a trunk out of service, or as a pre-emptive measure (quiescence) > to empty a trunk gradually. > > That's probably a good start as far as describing the architecture goes. > > Jon Peterson > NeuStar, Inc > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel --------------639CE69BEB2BB361FEB9272C Content-Type: application/vnd.ms-powerpoint; name="ietf-snr-slides.ppt" Content-Disposition: inline; filename="ietf-snr-slides.ppt" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAA3gAAAAAA AAAAEAAA/v///wAAAAD+////AAAAANwAAADdAAAA//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////9gIRvwuQEAAKthJe8Wq3tMe/K5XR75VqMsBAAA KgAAALYAAADMAQAAtQEAAJAAUQA4aTEAhwEAAAD+eJyFkjEsA1EYx///15ZWiTBo0yCNQUWQ Goro2mAzIRFDDVgImzSxmaQJia4MGEkkJEdDWCRyEjFoNEwsZoNJJOe966vhnNxLvve9/7v/ /e593zsiBPhahJwQhhoBGWFhoNte1QsL+/TLlZ8NULmPUTsL0naERPUtCsuyJAdoR52cO2sa ZbbUpj3c9mplfEuCcWuqb8joJdSZ8CUCtkNZO/QT2v6oP84lFlHUKs1XlDCp1Tw30MwerbZZ wiDHtDrhGkd4qFUXDZaRZEXN0GSYGa32eMlWDmmV4zo/seqogP9WpToZC77AQBkrjHOZ5/K0 lapqoBq2uFX4rUrY/sgff7VmlT+0KxaMcBgmHpDmGx5l1V5Up9+dusNrzMquFWRHUhz1pDr9 7tQbZGUXTSZ4xif004vq9LtTg7zgBO+Z5R2DTHpSnX53aobP8s6necArtnHAk+r0u1PzTOEd U1jgJppkv7yoTr87dZdzzPMYp8xxnEeeVKff+z+u7ClKgpbls9UPix+eNWAhG/AyAQAAWNiB 2Stp8Xq+0zx1NdDT9kwCAADLAAAAUQEAAGcBAADaAQAAmDoeAGiMGgAAAQAAAP54nIVRS05C QRCsmvFhwN/WlQuDvJUu9Qws38KNO1iw8gQkHMA7yDXkCpJ3AhMOwRZjMlY3vAGN4CQ9Pf2p qp400QZij8ARzmGnkJ2EirW/TsMLXlVTnWfu73jpPpDe0Q4NiiGlhKjXFTq6e60L+WRJP8ey L3XP52/GJ7uVrvTxGQrvsNbrTYU+TzcWqDHgAhVHrPjIAS1eo1oQAfr9+4wKB1HNBLPZNE8Q 3S+JrLuOd5mGYjD7EIvZcK8+DqIa/fH4KeuHjV78pb9lMoYR3/NPLP5f/y+UbeUmRnSUW2me Fba5B+VKzVvu9NWYCDcRxzN/bpS+L9MsmVL06BswBVPIYCEb8PwBAADMK6pmVKrlz8R8Mqso 5KRzPAYAAJUAAAApAQAA2wAAAG8BAAAIkA0ACJANAMoBAAAA/nicpVM9SwNBEJ23d4mI8QMU sbIQUcQPBDshoBJSScBCMcQiKBYSFP+GpUXQRhALNWIlioUgFipWQhBF8iusRThn5/bOi1zO Uw/e7eybfXvzZvdAzURWr0WUoA7ST4LRooZQliilspQlmyMbrTKOoUdGBciKZuWpoBzHId6K eqmF3wPJdkqRo0nzhLNNjA/lzfTeoyBdF72rhHB6cZ/JQOrst5K0QxPYp2HUGE8c7xi0ST4h +SfBBvMbdTnN10S7Knk9r68Ogeq67XVeqXsS7WB+y/EdKL/OMo1jj9WvjCrHZQOvlrC835Pc 146WjG+8c1BZFZRYVapXTj8HanGVlq/Uqlf55oqoq4F6wnLurl5PvtfjnlVS5sGzUtKZHruA G5rBsbkbbkdzOKVJHMnN6VJLOJGoU41wpNWDcJzobruU+yXbvx1eTSlxY1OFT7ZCaZwxdByX P/iBD78tjTsR9L7M/cjhynifwrXxvslRtPdGLq9pjbVF3DN0HJe//IH/j8sCLmiB/1DXZR63 xmUe2390uUuL3H+NInQcn5+L5P/jMosHmsa5cZnBoXGZwcsfXT5SBneCWeg4Pp+O5MNd/ob1 /Fgy+wTUbf2+AG4e8LQNAAAzb+pGqaDm8zXEaywgSeCZ/4lQTkcNChoKAAAADUlIRFIAAAEY AAABvwgCAAAADPVfjQAAAARnQU1BAACxiJWY9KYAAAAJcEhZcwAADmcAAA6JAU90XBMAAA1F SURBVHic7d09ttvWvcbhzSxPwhNIIXepMwg10hDuWnLtXnHvWlorQ5AbDyL17aTiTiDDOLdA Ip9PHgJ4N7A/nqeyXIgkhB//GyABXu7u7gqwzw8HPMbv/z7gQeA0734sf6n9GCpiBnVDUhGT qLi0e1rR+/+t92hwkC9/e+Z/1ppIKmJIz1ZUKoWkIob0UkWlRkgqYkhXKirxkFTEkJ5W9P6X X+//MRmSihjSqxWVYEgqYki3VFRSIamIId1YUYmEpCKGdHtFZX9IKmJIqyoqO0NSEUNaW1HZ E5KKGNKGisrmkFTEkLZVVLaFpCKGtLmisiEkFTGkPRWVtSGpiCHtrKisCklFDGl/ReX2kFTE kCIVlRtDUhFDSlVUbglJRQwpWFF5NSQVMaRsReV6SCpiSPGKypWQVMSQalRUXgpJRQypUkXl 2ZBUxJDqVVSehqQihlS1ovIoJBUxpNoVlfshqYghHVBR+R6SihjSMRWVJSQVMaTDKiql/PDs L69cvzsr9KheRaX27yNBI6pWVITEDGpXVEr5y7sfy/s/vtV+GDjLARWVp7/YJyp69+Xtm+Mf 1NIOAoQEAUKCACFBgJAgQEgQICQIEBIECAkChAQBQoIAIUGAkCBASBAgJAgQEgQICQKEBAGP LzV/1SnX8Q7G9fzjWTeRVATPWj2RCPjX7//5j7+/O/V5ELMxpGNucQS9cLIBAnYt7d78z8fU 85jKt3+a56MxkSBASBAgJAgQEgQICQKEBAFCggAhQYCQIEBIECAkCBASBAgJAoQEAUKCACFB gJAgQEgQICQIEBIEHHRfu3/89ZjHOdo//u/sZ0AbTCQIEBIECAkChAQBQoKAo87aObvF0Ewk CBASBAgJAoQEAUKCACFBgJAgQEgQICQIEBIECAkChAQBQoIAIUGAkCBASBAgJAgQEgQICQJ2 3bPh2z9/TT0P6Nq6kN7/8a2UUv71e5XnAt2ytIOATUu7v79LPw3om4kEAUKCACFBgJAgQEgQ ICQIEBIECAkChAQBQoIAIUGAkCBASBAgJAgQEgQICQKEBAFCggAhQYCQIEBIECAkCBASBAgJ AoQEAUKCACFBgJAgQEgQICQIEBIECAkChAQBQoIAIUGAkCBASBAgJAgQEgQICQKEBAFCggAh QYCQIEBIECAkCBASBAgJAoQEAUKCACFBgJAgQEgQICQIEBIECAkChAQBQoIAIUGAkCBASBAg JAgQEgQICQKEBAFCggAhQYCQIEBIECAkCBASBAgJAoQEAUKCACFBgJAgQEgQICQIEBIECAkC hAQBP9z/w/tffj3reUDM24/HP6aJBAFCggAhQYCQIEBIEPDgrN2X3z6+/+NbKeXL2zcnPR/o kokEAUKCgB+e/b/LAg96dMqBiYkEAUKCACFBgJAgQEgQICQIEBIECAkChAQBQoIAIUGAkCBA SATcfZj9AjYhkXH34c3MOQmJpGlbEhJhc44mIVHFbDkJiYrmaUlI1DXJaBISRxi+JSFxkLFH k5A41KgtCYmjDTmahMQ5BmtJSJxmpNEkJE42Rk5Cogm9tyQkWtH1aBISbem0ped/jeJgnW47 Kln2h8vnnn4S5bSQxMN1dx/edNTSCSFJiBt1NJoOPUbq+miSs3SxzxwXUhebgza1/xZ8xNKu 8U1AL1pe6VWfSCoiq809quJEavMFM4AGR1OtiaQiamtqH8tPpKZeHgNraiKFQ1IRB2gqoUUy JBVRW4MJLZr4rh286nK5/Oe/Pn099Yk8L3aywTiiksvl8mdFpZSffzrvubwoM5HiFT3YcDTv 7u6uxl/74m6wtNTSaGrleqTLQ2c/HU52027Q0mgKTKSd40g2PLJil2hmNO2dSHsqMnx4ZOMu 0cBoOuesnX54ZNcu0cBE2hXStnGkIu7rPaHF9pBUxE5jJLQ4dGmnIhYjJbTYGNKGcaQiyogJ LQ6aSNs3X8PbjrVGrahsC6n6t4Ha3mRsMHBCiyMm0q0bsYftxVrDJ7Ro49vf/WwvbjdJQovq Ib2yNXvbXtxiqoQWq0NyuQRXXD5/2/6FnT4TWtSdSMbRPPZeu9r5znDSMVLnW41HdlU0xM6w LiTrOpKGSGhxxkQaaPOx0XD7QMWQfCeIZwyX0OLwS80H3Y7cZNx//WOXduNuR14x+j/9gSGN vil53hz/7m18RYghzZHQQkhUMFNCi1bua8c45quoVA3pwd03p9y4zMNEggAhQcC6kJr9dRo4 l4kEAXVDqvRrH9Ca1SFZ3cFT1Zd2hhIzcIwEAVtCWru6M5QY3kETyTXqjO24pZ2WGNjGkLad u9MSozr6ZIOWGNL2kDbf2+Tuwxs5MZgdE+nT1z33CZITIzn5cyQ5MYa9IUVuXicnercvpE9f S+5GkHKiX5mbn1wul9TXF7poyTd3eSR2F6FgS+27X/uJUd3+pnP7kzzyjWyk96PdIX36uv2H pYbwfc8babc4xkibLnlfu6mG0lMj7RYHa2TC75E4/X3vVlt+gaI4a7JPp5su9DnSw5bkVOS0 Q4+brtYHslpa9LhPNKKv7ZYL6cm9VLX0XV/7RDs62m7Rm+g/OYM3+emH++4+vDnzMPrRmVV3 kE5LL+2em0tG06Kj99d29LLRKhwjPfduJ6eFQ6ZR1TnZ8MLKQU4LLa3SxbtPtcsoXl6FX/6r 1kP3oP09g1VqXo/02hHt5Z6KT4MhNP7WU/nCvpvPDl2P6nKe6OZ4oPE941UnbM+Gv9VZ/wrZ 9Wdaj9ybNzyZ4PPpvaUN9mzGlj9KOeRS8+E+tQgWNWFLu7Q6lI66Z8NwLS0iOWlpAAfe/OTT Vzlx38aN9vNPDc6lw+8itOQ0YlF7cpp2KA3zBnTe7bgGzYm1VrX05/mGxoZS9EurGywtNbZR 9rhs/Z7uyd9q3W/b2+Io//Rnh7S4/2/Q/5Zd3mJbPlfbkD2rkp9/amdR00ZI912P6sQNV7/w 7ofSxNoL6b5m3m9KefnJvBDY5jUePfIbsru9fNZky4f3s56+652QQl7IaZjTu1wnpCjn9A/W zKkpIVXwMKe1Q8nqrkdCqsZomomQatLSNIRU2dyf979q7f0Ymj15I6T61v/Y7iQfQI10NCik Q2yYS9MMpTG0/c0GBrVtFjW7rismUtMMpX6YSAe5fP420iFBOfxAruVxVEwkiDCRaN21WdTM J3Um0kEGW9fxiJAgQEhtm/vE3Ss3ZmpmXVfaDMkqiNL8abpH2jrZMGpCa19XX/vQOVoaR6Wp iTRqRcygiYkkIe57ZSA3NosW54ekIhZdL2jPDElCz+p6f9pmgJd8WkjzVDTPK73R9myaXNQt Tghpqh1r4Bd79BhpuKJy/Fm7gXespza82AEWOXM6LqS1V+eXMvvn+nTkoKXdbAnFrgBtez1z kB42QvWQplrLLSZ8yVX00M93dUOyS93O0dGfukpoUTGkCSva/JKnrqjDbJ6qEpKEZjRED5vl Q5ptl9r/eqceR6NIhiShDXq5cI3rYiHNUNEMr5FtAiHV2L0mufm1cTSMvd9s8Ca9mUOjkWyf SBKqyDjqzcaJpKKdjKPBrJ5IEtqvx0upuW5dSCraySAa1a0hSWi/myoyjvp0U0gq2unWQaSi bt10suHy+Vvt5zEwFc3g1qXd0pLRtMqKIyIVdW7d6W+j6Uav3P39ERX1b/Xpb6PpOufl5rTx A1mj6al1U+g742gI278itOw0k3y79CV754+KRrE1pP/e5WeSnPILNgmNZX1Iz90o63K5ZFsa /EhDRcNZGdLLt5ubZDTtJaFBrQzp09frt26Mj6ahpCt6fMoncVfNGn/nDNYv7Za9wWhaxSAa 3dYrZF/bMwY/yFlFRRPYcc8Go+lVEprG7pufOGp6Sj/zSdyOy2gq4pld7gaRN+Q0QkuC4Tnp WxZfXeltGU123NvV2Fa2/20q/GLfp6/Xt74Teoyn2k9fvtaSnBhJzd+QvWE0yYkx1P8xZh/d MoFDftXcaGJ0h4S0MJoY14EhFaOJYR0b0sJoYjhnhFReH03Ql5NCWmiJUZwaUjGaGMTZIS3k ROfaCGmhJbrVUkjFaKJXjYW00BK9aTKkYjTRmVZDWmiJTrQdEnRCSBAgJAgQEgQICQKEBAFC ggAhQYCQIEBIECAkCBASBAgJAoQEAUKCACFBgJAgQEgQ8OA3ZN//8utZzwNi3n484EG+/Pbg UUwkWO1RRUVIsNbTioqQYJWnFb37sRQhwe1eqqgICW50paLy6Kzdl98+vv/jWynly9s39Z8Y dON6RcVEgle9WlERElx3S0Xl0dLuu2WBBz0KHpjcWFExkeAlt1dUhATPWlVRERI8tbaiIiR4 ZENFRUhw37aKipDgu80VFSHBYk9FRUhQdldUhAT7KypCYnKRioqQmFmqoiIkphWsqAiJOWUr KkJiQvGKipCYTY2KipCYSqWKipCYR72KipCYRNWKipCYQe2KSimXu7u7y+dv7r/FPOIVFROJ 2dSoqAiJqVSqqHxf2tX66+EkT49W6lVUlpAq/vVwkt///eCPVSsqlnbMoHZFpZT/B67Yi4Z0 mKwpAAAAAElFTkSuQmCCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAA8A6AOpCgAAAQDpAygAAACAFgAA4BAAAOAQAACAFgAABQAAAAoA AAAAAAAAAAAAAAEAAAAAAAABDwAJBBAGAAAAAAoEBAAAAAsAAAAPAMwPkgAAAAAAzQ8IAAAA AAAAAAEAADABAMMPGAAAAAEAAAAAAAAAAQAAAAAAAAADAAAAALMSABAAug8YAAAAQgBpAHQA bQBhAHAAIABJAG0AYQBnAGUAIAC6DxoAAABQAGEAaQBuAHQALgBQAGkAYwB0AHUAcgBlADAA ug8YAAAAQgBpAHQAbQBhAHAAIABJAG0AYQBnAGUADwDMD5IAAAAAAM0PCAAAAAAAAAAB3AAw AQDDDxgAAAABAAAAAAAAAAIAAAAAAAAABAAAAACzEgAQALoPGAAAAEIAaQB0AG0AYQBwACAA SQBtAGEAZwBlACAAug8aAAAAUABhAGkAbgB0AC4AUABpAGMAdAB1AHIAZQAwALoPGAAAAEIA aQB0AG0AYQBwACAASQBtAGEAZwBlAA8AzA+SAAAAAADNDwgAAAAAAAAAAQAAMAEAww8YAAAA AQAAAAAAAAADAAAAAAAAAAUAAAAAsxIAEAC6DxgAAABCAGkAdABtAGEAcAAgAEkAbQBhAGcA ZQAgALoPGgAAAFAAYQBpAG4AdAAuAFAAaQBjAHQAdQByAGUAMAC6DxgAAABCAGkAdABtAGEA cAAgAEkAbQBhAGcAZQAPAMwPkgAAAAAAzQ8IAAAAAAAAAAEAADABAMMPGAAAAAEAAAAAAAAA BAAAAAAAAAAGAAAAALMSABAAug8YAAAAQgBpAHQAbQBhAHAAIABJAG0AYQBnAGUAIAC6DxoA AABQAGEAaQBuAHQALgBQAGkAYwB0AHUAcgBlADAAug8YAAAAQgBpAHQAbQBhAHAAIABJAG0A YQBnAGUADwDMD5IAAAAAAM0PCAAAAAAAAAABAAAwAQDDDxgAAAABAAAAAAAAAAUAAAAAAAAA BwAAAACzEgAQALoPGAAAAEIAaQB0AG0AYQBwACAASQBtAGEAZwBlACAAug8aAAAAUABhAGkA bgB0AC4AUABpAGMAdAB1AHIAZQAwALoPGAAAAEIAaQB0AG0AYQBwACAASQBtAGEAZwBlAA8A zA+SAAAAAADNDwgAAAAAAAAAAQAAMAEAww8YAAAAAQAAAAAAAAAGAAAAAAAAAAgAAAAAsxIA EAC6DxgAAABCAGkAdABtAGEAcAAgAEkAbQBhAGcAZQAgALoPGgAAAFAAYQBpAG4AdAAuAFAA aQBjAHQAdQByAGUAMAC6DxgAAABCAGkAdABtAGEAcAAgAEkAbQBhAGcAZQAPAMwPkgAAAAAA zQ8IAAAAAAAAAAEAADABAMMPGAAAAAEAAAAAAAAABwAAAAAAAAAJAAAAALMSABAAug8YAAAA QgBpAHQAbQBhAHAAIABJAG0AYQBnAGUAIAC6DxoAAABQAGEAaQBuAHQALgBQAGkAYwB0AHUA cgBlADAAug8YAAAAQgBpAHQAbQBhAHAAIABJAG0AYQBnAGUADwDMD5IAAAAAAM0PCAAAAAAA AAABAAAwAQDDDxgAAAABAAAAAAAAAAgAAAAAAAAACgAAAACzEgAQALoPGAAAAEIAaQB0AG0A YQBwACAASQBtAGEAZwBlACAAug8aAAAAUABhAGkAbgB0AC4AUABpAGMAdAB1AHIAZQAwALoP GAAAAEIAaQB0AG0AYQBwACAASQBtAGEAZwBlAA8AzA+SAAAAAADNDwgAAAAAAAAAASwAMAEA ww8YAAAAAQAAAAAAAAAJAAAAAAAAAAsAAAAAsxIAEAC6DxgAAABCAGkAdABtAGEAcAAgAEkA bQBhAGcAZQAgALoPGgAAAFAAYQBpAG4AdAAuAFAAaQBjAHQAdQByAGUAMAC6DxgAAABCAGkA dABtAGEAcAAgAEkAbQBhAGcAZQAPAMwPkgAAAAAAzQ8IAAAAAAAAAAFMADABAMMPGAAAAAEA AAAAAAAACwAAAAAAAAAMAAAAALMSABAAug8YAAAAQgBpAHQAbQBhAHAAIABJAG0AYQBnAGUA IAC6DxoAAABQAGEAaQBuAHQALgBQAGkAYwB0AHUAcgBlADAAug8YAAAAQgBpAHQAbQBhAHAA IABJAG0AYQBnAGUADwDyA/AAAAAvAMgPDAAAADAA0g8EAAAAAAAAAA8A1QdMAAAAAAC3D0QA AABUAGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAAMC3EgDAtxIAzLMSAPjTAzDwsxIA CAAAAPCzEgB+1AMwAAAGEgAAqQ8KAAAABwAAAAIACQQAAEAAow9uAAAABQD//T8AAAAiIAAA ZAAAAAAAAABkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA////////GAAAAAABAAAABQAA IAEgAQAAAAAABQAAQAJAAgAAAAAABQAAYANgAwAAAAAABQAAgASABAAAAAAPAAsERAEAAA8A APA8AQAAAAAG8DgAAACMFAAABgAAAHoBAAAEAAAAAQAAAAcAAAAAAAAAAwAAAAMAAAC+AAAA BAAAAC8AAAAFAAAAjAAAAE8AAfCwAAAAMgAH8CQAAAADBKthJe8Wq3tMe/K5XR75VqP/AMEB AAAIAAAAAAAAAAAACQEyAAfwJAAAAAMEWNiB2Stp8Xq+0zx1NdDT9v8AOgEAAAMAAADBAQAA AAAJATIAB/AkAAAAAwTMK6pmVKrlz8R8Mqso5KRz/wAEAgAAEwAAAPsCAAAAAAkBYgAH8CQA AAAGBjNv6kapoObzNcRrLCBJ4Jn/ALwNAAAKAAAA/wQAAAAACQFjAAvwJAAAAIEBBAAACIMB AAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACEAAHvEQAAAABAAACAEAAAgCAAAI9wAAEB8A 8A8cAAAAAADzAxQAAAACAAAAAAAAAAAAAAAAAACAAAAAAA8A0AfPAAAAHwD/AxQAAAACAAAE DAAAAAAAAAAAAAAAAgAAAA8A+gNnAAAAAAD+AwMAAAAAAQAAAP0DNAAAAEUAAABkAAAARQAA AGQAAAD8sxIAftQDMPSzEgAIAAAAuBQAAFoMAABm/f//pv///wEAAABwAPsDCAAAAAAAAABw CAAAcAD7AwgAAAABAAAAQAsAAB8ACAQ8AAAAAAD9AzQAAABCAAAAZAAAAEIAAABkAAAAYPWv AgAAAADAtxIAAQAAALgUAAD2DAAAAAAAAAAAAAAAAP//PwDZDwwAAAAAANoPBAAAAAAAJQAP APAP/gAAAAAA8wMUAAAADQAAAAQAAAABAAAAAAEAAAAAAAAAAJ8PBAAAAAAAAAAAAKgPGAAA AFdob2xlc2FsZSBWb0lQIHByb3ZpZGVyCwAAqg8aAAAACQAAAAAAAAAFAAAAAQAAAAMACwAA AAAAAAAAAPMDFAAAAA4AAAAEAAAAAQAAAAEBAAAAAAAAAACfDwQAAAAAAAAAAACoDw0AAABJ VFNQLXRvLUlUU1ALAACqDxIAAAANAAAAAAAAAAEAAAABAAAAAAAAAPMDFAAAAA8AAAAEAAAA AQAAAAIBAAAAAAAAAACfDwQAAAAAAAAAAACoDw0AAABIeWJyaWQgbW9kZWwLAADqAwAAAAAP APgDqQgAAAIA7wMYAAAAAQAAAAECBwkIAAAAAAAAAAAAAAAAAAAAYADwByAAAAD///8AAAAA AICAgAAAAAAAAMyZADMzzADMzP8AsrKyAGAA8AcgAAAAAAD/AP///wAAAAAA//8AAP+ZAAAA //8A/wAAAJaWlgBgAPAHIAAAAP//zAAAAAAAZmYzAICAAAAzmTMAgAAAAAAzzAD/zGYAYADw ByAAAAD///8AAAAAADMzMwAAAAAA3d3dAICAgABNTU0A6urqAGAA8AcgAAAA////AAAAAACA gIAAAAAAAP/MZgAAAP8AzADMAMDAwABgAPAHIAAAAP///wAAAAAAgICAAAAAAADAwMAAAGb/ AP8AAAAAmQAAYADwByAAAAD///8AAAAAAICAgAAAAAAAM5n/AJn/zADMAMwAsrKyAAAAow8+ AAAAAQD//T8AAAAiIAAAZAAAAAAAAQBkAAAAAAAAAAAAQAIAAAAAAgAAAP//7wAAAAAA//// ////LAAAAAADAAAQAKMPfAAAAAUA//0/AAEAIiAAAGQAAAAAAAAAZAAUAAAA2AAAAEACAAAA AAIAAAD//+8AAAAAAP///////yAAAAAAAQAAgAUAABMg1AEgAQAAAgAcAIAFAAAiINACQAIA AAIAGACABQAAEyDwA2ADAAACABQAgAUAALsAEAWABAAAAAAgAKMPbgAAAAUA//0/AAAAIiAA AGQAAAAAAAAAZAAeAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP///////wwAAAAAAQAAAAUA ACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAAUACjD1IAAAAF AAAAAQkAAAAAAQAAAAAAAAABAAEJAAAAAAEAIAEAAAAAAgABCQAAAAABAEACAAAAAAMAAQkA AAAAAQBgAwAAAAAEAAEJAAAAAAEAgAQAAAAAYACjDwwAAAABAAAAAAAAAAAAAABwAKMPPgAA AAUAAAAAAAAAAAACABwAAQAAAAAAAAACABgAAgAAAAAAAAACABQAAwAAAAAAAAACABIABAAA AAAAAAACABIAgACjDz4AAAAFAAAAAAAAAAAAAgAYAAEAAAAAAAAAAgAUAAIAAAAAAAAAAgAS AAMAAAAAAAAAAgAQAAQAAAAAAAAAAgAQAA8ADATTBAAADwAC8MsEAAAQAAjwCAAAAAYAAAAG BAAADwAD8GMEAAAPAATwKAAAAAEACfAQAAAA9fX19fX19fX19fX19fX19QIACvAIAAAAAAQA AAUAAAAPAATw0gAAABIACvAIAAAAAgQAAAAKAACTAAvwNgAAAH8AAQABAIAAxJqvAocAAQAA AIEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAgAGwAdAUUAQP ABHwEAAAAAAAwwsIAAAAAAAAAAEAIAIPAA3wVAAAAAAAnw8EAAAAAAAAAAAAqA8gAAAAQ2xp Y2sgdG8gZWRpdCBNYXN0ZXIgdGl0bGUgc3R5bGUAAKIPBgAAACEAAAAAAAAAqg8KAAAAIQAA AAEAAAAAAA8ABPAWAQAAEgAK8AgAAAADBAAAAAoAAIMAC/AwAAAAfwABAAEAgAAkm68CgQEE AAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAADgBLAB0BQADw8AEfAQ AAAAAADDCwgAAAABAAAAAgAgAg8ADfCeAAAAAACfDwQAAAABAAAAAACoD1IAAABDbGljayB0 byBlZGl0IE1hc3RlciB0ZXh0IHN0eWxlcw1TZWNvbmQgbGV2ZWwNVGhpcmQgbGV2ZWwNRm91 cnRoIGxldmVsDUZpZnRoIGxldmVsAACiDx4AAAAhAAAAAAANAAAAAQAMAAAAAgANAAAAAwAM AAAABAAAAKoPCgAAAFMAAAABAAAAAAAPAATwtQAAABIACvAIAAAABAQAAAAKAACDAAvwMAAA AH8AAQABAIAAhJuvAoEBBAAACIMBAAAACL8BAQARAMABAQAACP8BAQAJAAECAgAACAAAEPAI AAAAYA+wAWAGgBAPABHwEAAAAAAAwwsIAAAAAgAAAAcBIAIPAA3wPQAAAAAAnw8EAAAABAAA AAAAqA8BAAAAKgAAoQ8UAAAAAgAAAAAAAAAAAAIAAAAAAAIADgAAAPgPBAAAAAAAAAAPAATw twAAABIACvAIAAAABQQAAAAKAACDAAvwMAAAAH8AAQABAIAApJmvAoEBBAAACIMBAAAACL8B AQARAMABAQAACP8BAQAJAAECAgAACAAAEPAIAAAAYA+wB9AOgBAPABHwEAAAAAAAwwsIAAAA AwAAAAkCIAIPAA3wPwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAKgAAoQ8WAAAAAgAAAAAAAAgA AAEAAgAAAAAAAgAOAAAA+g8EAAAAAAAAAA8ABPC3AAAAEgAK8AgAAAAGBAAAAAoAAIMAC/Aw AAAAfwABAAEAgABkka8CgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ 8AgAAABgDyAQ0BSAEA8AEfAQAAAAAADDCwgAAAAEAAAACAKvAg8ADfA/AAAAAACfDwQAAAAE AAAAAACoDwEAAAAqAAChDxYAAAACAAAAAAAACAAAAgACAAAAAAACAA4AAADYDwQAAAAAAAAA DwAE8EgAAAASAArwCAAAAAEEAAAADAAAgwAL8DAAAACBAQAAAAiDAQUAAAiTAY6fiwCUAd69 aAC/ARIAEgD/AQAACAAEAwkAAAA/AwEAAQAQAPAHIAAAAP///wAAAAAAgICAAAAAAAAAzJkA MzPMAMzM/wCysrIAIAC6DywAAABCAGwAYQBuAGsAIABQAHIAZQBzAGUAbgB0AGEAdABpAG8A bgAuAHAAbwB0AA8A7gPOkQAAAgDvAxgAAAAHAAAADQAAAAAAAAAAAACAAAAAAAcAAAAPAAwE fpEAAA8AAvB2kQAAMAAI8AgAAAC7AAAAvQwAAA8AA/AGjAAADwAE8CgAAAABAAnwEAAAAAAA AAAAAAAAAAAAAAAAAAACAArwCAAAAAAMAAAFAAAADwAE8GoAAACyBArwCAAAAAIMAAAACgAA swAL8EIAAAB/AAAAgACFAAIAAACHAAEAAAAEQQEAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEA AAj/AQAACAABAgIAAAg/AgAAAgAAABDwCAAAAFAHUATgENAODwAE8AsBAACiDArwCAAAAAMM AAAACgAAEwEL8GYAAACAANRjbAGBAMAdAQCCAOCOAACDAMAdAQCEAOCOAACFAAIAAACHAAEA AAC/AAIADwCBAf//ZgC/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYA HwB/AwAADwAAABDwCAAAAAQNNgh2DmYODwAN8HUAAAAAAJ8PBAAAAAQAAAAAAKgPHwAAAFdo b2xlc2FsZSBWb0lQIFByb3ZpZGVyDU5ldHdvcmsAAKEPGAAAACAAAAAAAAAIAAABACAAAAAB AAIAAQAQAAAAqg8aAAAACgAAAAAAAAAEAAAAAQAAAAMAEgAAAAAAAAAPAATwlAAAAEIBCvAI AAAABAwAAAAKAAAjAQvwbAAAAIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAA AL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAAD AL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAQAgRA3EGEAsPAATwlAAAAEIBCvAIAAAABQwA AAAKAAAjAQvwbAAAAIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAAAP AEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAP AP8CFgAfAH8DAAAPAAAAEPAIAAAAEAuxAkEGEAsPAATwlAAAAEIBCvAIAAAABgwAAAAKAAAj AQvwbAAAAIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAA AH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAf AH8DAAAPAAAAEPAIAAAAQAuxAnEGQAsPAATwlAAAAEIBCvAIAAAABwwAAAAKAAAjAQvwbAAA AIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAAB AL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AAAAEPAIAAAAcAuxAnEGcAsPAATwlAAAAEIBCvAIAAAACAwAAIAKAAAjAQvwbAAAAIEAwB0B AIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQ AMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAI AAAAcAuxAnEGgA0PAATwlAAAAEIBCvAIAAAACQwAAIAKAAAjAQvwbAAAAIEAwB0BAIIA4I4A AIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAA CMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAoAvh AnEGsA0PAATwlAAAAEIBCvAIAAAACgwAAIAKAAAjAQvwbAAAAIEAwB0BAIIA4I4AAIMAwB0B AIQA4I4AAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28A AP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAYAlxD0EScAsP AATwlAAAAEIBCvAIAAAACwwAAAAKAAAjAQvwbAAAAIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4A AIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAe AAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAcAtBD9ESMAwPAATwlAAA AEIBCvAIAAAADAwAAAAKAAAjAQvwbAAAAIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAA AIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAA CD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAoAtBD9ESYAwPAATwlAAAAEIBCvAI AAAADQwAAAAKAAAjAQvwbAAAAIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAA AL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAAD AL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAA0AtBD9ESkAwPAATwlAAAAEIBCvAIAAAADgwA AAAKAAAjAQvwbAAAAIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAAAP AEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAP AP8CFgAfAH8DAAAPAAAAEPAIAAAAAAxBD9ESwAwPAATwlAAAAEIBCvAIAAAADwwAAIAKAAAj AQvwbAAAAIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAA AH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAf AH8DAAAPAAAAEPAIAAAAkAlxD0ESoAsPAAPwVBYAAA8ABPBGAAAAAQAJ8BAAAAABAQAARQcA AJADAADQCAAAAgAK8AgAAAAQDAAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ8AgAAABFBwEBkAPQ CA8AA/AWFQAADwAE8E4AAAABAAnwEAAAAA8GAADAAgAAnggAAEsEAAACAArwCAAAABEMAAAD AgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAAEBAABFBwAAkAMAANAIAAAPAATwYAAAADIACvAI AAAAEgwAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAI AAECAgAACD8CAAACAAAAD/AQAAAA7gYAAMACAAALCAAAYgMAAA8ABPBgAAAAMgAK8AgAAAAT DAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQIC AAAIPwIAAAIAAAAP8BAAAABSBgAA6gIAACwHAACMAwAADwAE8GAAAAAyAArwCAAAABQMAAAC CgAAgwAL8DAAAACFAAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/ AgAAAgAAAA/wEAAAAA8GAABMAwAAogYAANADAAAPAATwYAAAADIACvAIAAAAFQwAAAIKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAAC AAAAD/AQAAAAOwYAAIYDAAAZBwAAFQQAAA8ABPBgAAAAMgAK8AgAAAAWDAAAAgoAAIMAC/Aw AAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP 8BAAAADYBgAAnQMAACIIAABHBAAADwAE8GAAAAAyAArwCAAAABcMAAACCgAAgwAL8DAAAACF AAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAA AKoHAADvAgAAfggAAG4DAAAPAATwYAAAADIACvAIAAAAGAwAAAIKAACDAAvwMAAAAIUAAgAA AIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAygcA AEEDAACcCAAAwAMAAA8ABPBgAAAAMgAK8AgAAAAZDAAAAgoAAIMAC/AwAAAAhQACAAAAhwAB AAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAAC3BwAAWwMA AIgIAAAsBAAADwAE8GAAAAAyAArwCAAAABoMAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACB AXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAAAIYGAAAdAwAALggA AO0DAAAPAATw9gAAADIBCvAIAAAAGwwAAAIKAADzAAvwxgAAAIUAAgAAAIcAAQAAAEIBtJ0A AEXBTgAAAEcB7DLHAEgB551RAUkBr08AAFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAA AP8BAAAIAAECAgAACD8CAAACAAkADAAIAE/7//8AAAAAD6QAAMCoAAAAAAAAoTgAALSdAAA/ NAAAT/v//wAAAAAPpAAAwKgAAAAAAAChOAAAtJ0AAD80AACvTwAAYFQAAAMABAAIAAAAAACh OAAAtJ0AAD80AACvTwAAYFQAAAAAD/AQAAAA9wYAAMECAAAECAAAEwMAAA8ABPAaAQAAMgEK 8AgAAAAcDAAAAgoAAFMBC/DqAAAAhQACAAAAhwABAAAAQgG0nQAARcFOAAAARwHsMscASAHn nVEBSQGvTwAAUcEeAAAAgQEEAAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEA AAAA1AEAAAAA1QEAAAAA1wEAAAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgAT/v//wAAAAAP pAAAwKgAAAAAAAChOAAAtJ0AAD80AABP+///AAAAAA+kAADAqAAAAAAAAKE4AAC0nQAAPzQA AK9PAABgVAAAAwAEAAgAAAAAAKE4AAC0nQAAPzQAAK9PAABgVAAAAAAP8BAAAAD3BgAAwQIA AAQIAAATAwAADwAE8NgAAAAyAQrwCAAAAB0MAAACCgAAAwEL8KgAAACFAAIAAACHAAEAAABC AU6AAABDAbtlAABFwSQAAABHASMhqABIAcxfLQFJAWBUAABRwR4AAACBAXiOlgC/ARAAEADA AQEAAAjXAQAAAAD/AQAACAABAgIAAAg/AgAAAgAJAAkA8P8AAAAAwKjAqM4Bu2VOgFYMAAAA AMCowKjOAbtlToBWDGBUYFQDAAQACADOAQAAu2UAAE6AAABWDAAAYFQAAGBUAAAAAA/wEAAA AFMGAADqAgAA+gYAAE0DAAAPAATw/AAAADIBCvAIAAAAHgwAAAIKAABjAQvwzAAAAIUAAgAA AIcAAQAAAEIBToAAAEMBu2UAAEXBJAAAAEcBIyGoAEgBzF8tAUkBYFQAAFHBHgAAAIEBBAAA CIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAAANUBAAAAANcBAAAA AP8BCAAIAAECAgAACD8CAAACAAkACQDw/wAAAADAqMCozgG7ZU6AVgwAAAAAwKjAqM4Bu2VO gFYMYFRgVAMABAAIAM4BAAC7ZQAAToAAAFYMAABgVAAAYFQAAAAAD/AQAAAAUwYAAOoCAAD6 BgAATQMAAA8ABPACAQAAMgEK8AgAAAAfDAAAAgoAABMBC/DSAAAAhQACAAAAhwABAAAAQgF7 fQAAQwHuWAAARcFOAAAARwFx2DwASAEUGLcASQFgVAAASgGOBAAAUcEeAAAAgQF4jpYAvwEQ ABAAwAEBAAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAMAAgAAAAAAC6w///AqAAA7lgA AHt9AAA9TgAAHwAAAAAAAAAAAAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAGBUAACO BAAAAwAEAAgAe30AAD1OAAAfAAAAAAAAAGBUAACOBAAAAAAP8BAAAAA6BgAAywMAAOQGAAAZ BAAADwAE8CYBAAAyAQrwCAAAACAMAAACCgAAcwEL8PYAAACFAAIAAACHAAEAAABCAXt9AABD Ae5YAABFwU4AAABHAXHYPABIARQYtwBJAWBUAABKAY4EAABRwR4AAACBAQQAAAiDAQAAAAi/ AQAAEADAATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAAB AgIAAAg/AgAAAgAJAAwACAAAAAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAAAAAAAu sP//wKgAAO5YAAB7fQAAPU4AAB8AAAAAAAAAYFQAAI4EAAADAAQACAB7fQAAPU4AAB8AAAAA AAAAYFQAAI4EAAAAAA/wEAAAADoGAADLAwAA5AYAABkEAAAPAATw/AAAADIBCvAIAAAAIQwA AAIKAAADAQvwzAAAAIUAAgAAAIcAAQAAAEIBp2UAAEMBFX4AAEXBTgAAAEcBNy8CAUgBCaAd AEkBRxEAAFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAAC AAkADAAIAOe8//8AAAAAp2UAAMCoAAAAAAAAygEAAJ9aAAAVfgAA57z//wAAAACnZQAAwKgA AAAAAADKAQAAn1oAABV+AABHEQAAYFQAAAMABAAIAAAAAADKAQAAn1oAABV+AABHEQAAYFQA AAAAD/AQAAAAAQgAAPACAACBCAAATwMAAA8ABPAgAQAAMgEK8AgAAAAiDAAAAgoAAGMBC/Dw AAAAhQACAAAAhwABAAAAQgGnZQAAQwEVfgAARcFOAAAARwE3LwIBSAEJoB0ASQFHEQAAUcEe AAAAgQEEAAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEA AAAA1wEAAAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgA57z//wAAAACnZQAAwKgAAAAAAADK AQAAn1oAABV+AADnvP//AAAAAKdlAADAqAAAAAAAAMoBAACfWgAAFX4AAEcRAABgVAAAAwAE AAgAAAAAAMoBAACfWgAAFX4AAEcRAABgVAAAAAAP8BAAAAABCAAA8AIAAIEIAABPAwAADwAE 8PYAAAAyAQrwCAAAACMMAAACCgAA8wAL8MYAAACFAAIAAACHAAEAAABDARBzAABFwU4AAABH AQCFNAFIAamKIwBKAQRCAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAAB AgIAAAg/AgAAAgAJAAwACACgq///pO3//2BUAABklgAAjDQAAAAAAACoRAAAEHMAAKCr//+k 7f//YFQAAGSWAACMNAAAAAAAAKhEAAAQcwAAAAAAAARCAAADAAQACACMNAAAAAAAAKhEAAAQ cwAAAAAAAARCAAAAAA/wEAAAACQIAABOAwAAnggAAKwDAAAPAATwGgEAADIBCvAIAAAAJAwA AAIKAABTAQvw6gAAAIUAAgAAAIcAAQAAAEMBEHMAAEXBTgAAAEcBAIU0AUgBqYojAEoBBEIA AFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAA ANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAKCr//+k7f//YFQAAGSWAACM NAAAAAAAAKhEAAAQcwAAoKv//6Tt//9gVAAAZJYAAIw0AAAAAAAAqEQAABBzAAAAAAAABEIA AAMABAAIAIw0AAAAAAAAqEQAABBzAAAAAAAABEIAAAAAD/AQAAAAJAgAAE4DAACeCAAArAMA AA8ABPACAQAAMgEK8AgAAAAlDAAAAgoAABMBC/DSAAAAhQACAAAAhwABAAAAQgHqbwAAQwFy bQAARcFOAAAARwFQt1YBSAHtDG0ASQGKGwAASgESGQAAUcEeAAAAgQF4jpYAvwEQABAAwAEB AAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAMAAgAKsf//7LE///qbwAAcm0AABtsAAAA AAAAAAAAANNoAAAqx///ssT//+pvAABybQAAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAwAE AAgAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAAAP8BAAAAD9BwAAqQMAAIwIAAAxBAAADwAE 8CYBAAAyAQrwCAAAACYMAAACCgAAcwEL8PYAAACFAAIAAACHAAEAAABCAepvAABDAXJtAABF wU4AAABHAVC3VgFIAe0MbQBJAYobAABKARIZAABRwR4AAACBAQQAAAiDAQAAAAi/AQAAEADA ATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAABAgIAAAg/ AgAAAgAJAAwACAAqx///ssT//+pvAABybQAAG2wAAAAAAAAAAAAA02gAACrH//+yxP//6m8A AHJtAAAbbAAAAAAAAAAAAADTaAAAihsAABIZAAADAAQACAAbbAAAAAAAAAAAAADTaAAAihsA ABIZAAAAAA/wEAAAAP0HAACpAwAAjAgAADEEAAAPAATw/AAAADIBCvAIAAAAJwwAAAIKAAAD AQvwzAAAAIUAAgAAAIcAAQAAAEMB8qAAAEXBTgAAAEcBQ45yAEgB71UKAUkBYFQAAEoBNFQA AFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAACAAkADAAI AAAAAADU////wKgAAJSoAABQMQAA8qAAAPxOAAAAAAAAAAAAANT////AqAAAlKgAAFAxAADy oAAA/E4AAAAAAABgVAAANFQAAAMABAAIAFAxAADyoAAA/E4AAAAAAABgVAAANFQAAAAAD/AQ AAAAEAYAAE0DAABeBgAAzgMAAA8ABPAgAQAAMgEK8AgAAAAoDAAAAgoAAGMBC/DwAAAAhQAC AAAAhwABAAAAQwHyoAAARcFOAAAARwFDjnIASAHvVQoBSQFgVAAASgE0VAAAUcEeAAAAgQEE AAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA1wEA AAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgAAAAAANT////AqAAAlKgAAFAxAADyoAAA/E4A AAAAAAAAAAAA1P///8CoAACUqAAAUDEAAPKgAAD8TgAAAAAAAGBUAAA0VAAAAwAEAAgAUDEA APKgAAD8TgAAAAAAAGBUAAA0VAAAAAAP8BAAAAAQBgAATQMAAF4GAADOAwAADwAE8PwAAAAy AQrwCAAAACkMAAACCgAAAwEL8MwAAACFAAIAAACHAAEAAABCAVaYAABFwU4AAABHASWGIgBI Aab7qABJAdJSAABKAQAAAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAAB AgIAAAg/AgAAAgAJAAwACABy/v//oKv//zKnAABgVAAAVpgAANIvAAAAAAAAIBAAAHL+//+g q///MqcAAGBUAABWmAAA0i8AAAAAAAAgEAAA0lIAAAAAAAADAAQACABWmAAA0i8AAAAAAAAg EAAA0lIAAAAAAAAAAA/wEAAAAN4GAAD8AwAAAggAAEsEAAAPAATwIAEAADIBCvAIAAAAKgwA AAIKAABjAQvw8AAAAIUAAgAAAIcAAQAAAEIBVpgAAEXBTgAAAEcBJYYiAEgBpvuoAEkB0lIA AEoBAAAAAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAA ANQBAAAAANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAHL+//+gq///MqcA AGBUAABWmAAA0i8AAAAAAAAgEAAAcv7//6Cr//8ypwAAYFQAAFaYAADSLwAAAAAAACAQAADS UgAAAAAAAAMABAAIAFaYAADSLwAAAAAAACAQAADSUgAAAAAAAAAAD/AQAAAA3gYAAPwDAAAC CAAASwQAAA8ABPDgAAAAogwK8AgAAAArDAAAAgoAABMBC/BmAAAAgACUZGwBgQDAHQEAggDg jgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwACAA8AgQH//2YAvwEMAB4AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAB8AQAAhwcAAHEDAACb CAAADwAN8EIAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFBTVE4NQ2FycmllciBBAAChDxgAAAAP AAAAAAAACAAAAQAPAAAAAQACAAEADAAPAAPwVBYAAA8ABPBGAAAAAQAJ8BAAAAABAQAAdQoA AJADAAAADAAAAgAK8AgAAAAsDAAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ8AgAAAB1CgEBkAMA DA8AA/AWFQAADwAE8E4AAAABAAnwEAAAAA8GAADAAgAAnggAAEsEAAACAArwCAAAAC0MAAAD AgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAAEBAAB1CgAAkAMAAAAMAAAPAATwYAAAADIACvAI AAAALgwAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAI AAECAgAACD8CAAACAAAAD/AQAAAA7gYAAMACAAALCAAAYgMAAA8ABPBgAAAAMgAK8AgAAAAv DAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQIC AAAIPwIAAAIAAAAP8BAAAABSBgAA6gIAACwHAACMAwAADwAE8GAAAAAyAArwCAAAADAMAAAC CgAAgwAL8DAAAACFAAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/ AgAAAgAAAA/wEAAAAA8GAABMAwAAogYAANADAAAPAATwYAAAADIACvAIAAAAMQwAAAIKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAAC AAAAD/AQAAAAOwYAAIYDAAAZBwAAFQQAAA8ABPBgAAAAMgAK8AgAAAAyDAAAAgoAAIMAC/Aw AAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP 8BAAAADYBgAAnQMAACIIAABHBAAADwAE8GAAAAAyAArwCAAAADMMAAACCgAAgwAL8DAAAACF AAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAA AKoHAADvAgAAfggAAG4DAAAPAATwYAAAADIACvAIAAAANAwAAAIKAACDAAvwMAAAAIUAAgAA AIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAygcA AEEDAACcCAAAwAMAAA8ABPBgAAAAMgAK8AgAAAA1DAAAAgoAAIMAC/AwAAAAhQACAAAAhwAB AAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAAC3BwAAWwMA AIgIAAAsBAAADwAE8GAAAAAyAArwCAAAADYMAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACB AXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAAAIYGAAAdAwAALggA AO0DAAAPAATw9gAAADIBCvAIAAAANwwAAAIKAADzAAvwxgAAAIUAAgAAAIcAAQAAAEIBtJ0A AEXBTgAAAEcB7DLHAEgB551RAUkBr08AAFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAA AP8BAAAIAAECAgAACD8CAAACAAkADAAIAE/7//8AAAAAD6QAAMCoAAAAAAAAoTgAALSdAAA/ NAAAT/v//wAAAAAPpAAAwKgAAAAAAAChOAAAtJ0AAD80AACvTwAAYFQAAAMABAAIAAAAAACh OAAAtJ0AAD80AACvTwAAYFQAAAAAD/AQAAAA9wYAAMECAAAECAAAEwMAAA8ABPAaAQAAMgEK 8AgAAAA4DAAAAgoAAFMBC/DqAAAAhQACAAAAhwABAAAAQgG0nQAARcFOAAAARwHsMscASAHn nVEBSQGvTwAAUcEeAAAAgQEEAAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEA AAAA1AEAAAAA1QEAAAAA1wEAAAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgAT/v//wAAAAAP pAAAwKgAAAAAAAChOAAAtJ0AAD80AABP+///AAAAAA+kAADAqAAAAAAAAKE4AAC0nQAAPzQA AK9PAABgVAAAAwAEAAgAAAAAAKE4AAC0nQAAPzQAAK9PAABgVAAAAAAP8BAAAAD3BgAAwQIA AAQIAAATAwAADwAE8NgAAAAyAQrwCAAAADkMAAACCgAAAwEL8KgAAACFAAIAAACHAAEAAABC AU6AAABDAbtlAABFwSQAAABHASMhqABIAcxfLQFJAWBUAABRwR4AAACBAXiOlgC/ARAAEADA AQEAAAjXAQAAAAD/AQAACAABAgIAAAg/AgAAAgAJAAkA8P8AAAAAwKjAqM4Bu2VOgFYMAAAA AMCowKjOAbtlToBWDGBUYFQDAAQACADOAQAAu2UAAE6AAABWDAAAYFQAAGBUAAAAAA/wEAAA AFMGAADqAgAA+gYAAE0DAAAPAATw/AAAADIBCvAIAAAAOgwAAAIKAABjAQvwzAAAAIUAAgAA AIcAAQAAAEIBToAAAEMBu2UAAEXBJAAAAEcBIyGoAEgBzF8tAUkBYFQAAFHBHgAAAIEBBAAA CIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAAANUBAAAAANcBAAAA AP8BCAAIAAECAgAACD8CAAACAAkACQDw/wAAAADAqMCozgG7ZU6AVgwAAAAAwKjAqM4Bu2VO gFYMYFRgVAMABAAIAM4BAAC7ZQAAToAAAFYMAABgVAAAYFQAAAAAD/AQAAAAUwYAAOoCAAD6 BgAATQMAAA8ABPACAQAAMgEK8AgAAAA7DAAAAgoAABMBC/DSAAAAhQACAAAAhwABAAAAQgF7 fQAAQwHuWAAARcFOAAAARwFx2DwASAEUGLcASQFgVAAASgGOBAAAUcEeAAAAgQF4jpYAvwEQ ABAAwAEBAAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAMAAgAAAAAAC6w///AqAAA7lgA AHt9AAA9TgAAHwAAAAAAAAAAAAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAGBUAACO BAAAAwAEAAgAe30AAD1OAAAfAAAAAAAAAGBUAACOBAAAAAAP8BAAAAA6BgAAywMAAOQGAAAZ BAAADwAE8CYBAAAyAQrwCAAAADwMAAACCgAAcwEL8PYAAACFAAIAAACHAAEAAABCAXt9AABD Ae5YAABFwU4AAABHAXHYPABIARQYtwBJAWBUAABKAY4EAABRwR4AAACBAQQAAAiDAQAAAAi/ AQAAEADAATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAAB AgIAAAg/AgAAAgAJAAwACAAAAAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAAAAAAAu sP//wKgAAO5YAAB7fQAAPU4AAB8AAAAAAAAAYFQAAI4EAAADAAQACAB7fQAAPU4AAB8AAAAA AAAAYFQAAI4EAAAAAA/wEAAAADoGAADLAwAA5AYAABkEAAAPAATw/AAAADIBCvAIAAAAPQwA AAIKAAADAQvwzAAAAIUAAgAAAIcAAQAAAEIBp2UAAEMBFX4AAEXBTgAAAEcBNy8CAUgBCaAd AEkBRxEAAFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAAC AAkADAAIAOe8//8AAAAAp2UAAMCoAAAAAAAAygEAAJ9aAAAVfgAA57z//wAAAACnZQAAwKgA AAAAAADKAQAAn1oAABV+AABHEQAAYFQAAAMABAAIAAAAAADKAQAAn1oAABV+AABHEQAAYFQA AAAAD/AQAAAAAQgAAPACAACBCAAATwMAAA8ABPAgAQAAMgEK8AgAAAA+DAAAAgoAAGMBC/Dw AAAAhQACAAAAhwABAAAAQgGnZQAAQwEVfgAARcFOAAAARwE3LwIBSAEJoB0ASQFHEQAAUcEe AAAAgQEEAAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEA AAAA1wEAAAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgA57z//wAAAACnZQAAwKgAAAAAAADK AQAAn1oAABV+AADnvP//AAAAAKdlAADAqAAAAAAAAMoBAACfWgAAFX4AAEcRAABgVAAAAwAE AAgAAAAAAMoBAACfWgAAFX4AAEcRAABgVAAAAAAP8BAAAAABCAAA8AIAAIEIAABPAwAADwAE 8PYAAAAyAQrwCAAAAD8MAAACCgAA8wAL8MYAAACFAAIAAACHAAEAAABDARBzAABFwU4AAABH AQCFNAFIAamKIwBKAQRCAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAAB AgIAAAg/AgAAAgAJAAwACACgq///pO3//2BUAABklgAAjDQAAAAAAACoRAAAEHMAAKCr//+k 7f//YFQAAGSWAACMNAAAAAAAAKhEAAAQcwAAAAAAAARCAAADAAQACACMNAAAAAAAAKhEAAAQ cwAAAAAAAARCAAAAAA/wEAAAACQIAABOAwAAnggAAKwDAAAPAATwGgEAADIBCvAIAAAAQAwA AAIKAABTAQvw6gAAAIUAAgAAAIcAAQAAAEMBEHMAAEXBTgAAAEcBAIU0AUgBqYojAEoBBEIA AFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAA ANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAKCr//+k7f//YFQAAGSWAACM NAAAAAAAAKhEAAAQcwAAoKv//6Tt//9gVAAAZJYAAIw0AAAAAAAAqEQAABBzAAAAAAAABEIA AAMABAAIAIw0AAAAAAAAqEQAABBzAAAAAAAABEIAAAAAD/AQAAAAJAgAAE4DAACeCAAArAMA AA8ABPACAQAAMgEK8AgAAABBDAAAAgoAABMBC/DSAAAAhQACAAAAhwABAAAAQgHqbwAAQwFy bQAARcFOAAAARwFQt1YBSAHtDG0ASQGKGwAASgESGQAAUcEeAAAAgQF4jpYAvwEQABAAwAEB AAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAMAAgAKsf//7LE///qbwAAcm0AABtsAAAA AAAAAAAAANNoAAAqx///ssT//+pvAABybQAAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAwAE AAgAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAAAP8BAAAAD9BwAAqQMAAIwIAAAxBAAADwAE 8CYBAAAyAQrwCAAAAEIMAAACCgAAcwEL8PYAAACFAAIAAACHAAEAAABCAepvAABDAXJtAABF wU4AAABHAVC3VgFIAe0MbQBJAYobAABKARIZAABRwR4AAACBAQQAAAiDAQAAAAi/AQAAEADA ATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAABAgIAAAg/ AgAAAgAJAAwACAAqx///ssT//+pvAABybQAAG2wAAAAAAAAAAAAA02gAACrH//+yxP//6m8A AHJtAAAbbAAAAAAAAAAAAADTaAAAihsAABIZAAADAAQACAAbbAAAAAAAAAAAAADTaAAAihsA ABIZAAAAAA/wEAAAAP0HAACpAwAAjAgAADEEAAAPAATw/AAAADIBCvAIAAAAQwwAAAIKAAAD AQvwzAAAAIUAAgAAAIcAAQAAAEMB8qAAAEXBTgAAAEcBQ45yAEgB71UKAUkBYFQAAEoBNFQA AFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAACAAkADAAI AAAAAADU////wKgAAJSoAABQMQAA8qAAAPxOAAAAAAAAAAAAANT////AqAAAlKgAAFAxAADy oAAA/E4AAAAAAABgVAAANFQAAAMABAAIAFAxAADyoAAA/E4AAAAAAABgVAAANFQAAAAAD/AQ AAAAEAYAAE0DAABeBgAAzgMAAA8ABPAgAQAAMgEK8AgAAABEDAAAAgoAAGMBC/DwAAAAhQAC AAAAhwABAAAAQwHyoAAARcFOAAAARwFDjnIASAHvVQoBSQFgVAAASgE0VAAAUcEeAAAAgQEE AAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA1wEA AAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgAAAAAANT////AqAAAlKgAAFAxAADyoAAA/E4A AAAAAAAAAAAA1P///8CoAACUqAAAUDEAAPKgAAD8TgAAAAAAAGBUAAA0VAAAAwAEAAgAUDEA APKgAAD8TgAAAAAAAGBUAAA0VAAAAAAP8BAAAAAQBgAATQMAAF4GAADOAwAADwAE8PwAAAAy AQrwCAAAAEUMAAACCgAAAwEL8MwAAACFAAIAAACHAAEAAABCAVaYAABFwU4AAABHASWGIgBI Aab7qABJAdJSAABKAQAAAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAAB AgIAAAg/AgAAAgAJAAwACABy/v//oKv//zKnAABgVAAAVpgAANIvAAAAAAAAIBAAAHL+//+g q///MqcAAGBUAABWmAAA0i8AAAAAAAAgEAAA0lIAAAAAAAADAAQACABWmAAA0i8AAAAAAAAg EAAA0lIAAAAAAAAAAA/wEAAAAN4GAAD8AwAAAggAAEsEAAAPAATwIAEAADIBCvAIAAAARgwA AAIKAABjAQvw8AAAAIUAAgAAAIcAAQAAAEIBVpgAAEXBTgAAAEcBJYYiAEgBpvuoAEkB0lIA AEoBAAAAAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAA ANQBAAAAANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAHL+//+gq///MqcA AGBUAABWmAAA0i8AAAAAAAAgEAAAcv7//6Cr//8ypwAAYFQAAFaYAADSLwAAAAAAACAQAADS UgAAAAAAAAMABAAIAFaYAADSLwAAAAAAACAQAADSUgAAAAAAAAAAD/AQAAAA3gYAAPwDAAAC CAAASwQAAA8ABPDgAAAAogwK8AgAAABHDAAAAgoAABMBC/BmAAAAgACkkK8CgQDAHQEAggDg jgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwACAA8AgQH//2YAvwEMAB4AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAABhAQAAsAoAAFYDAADE CwAADwAN8EIAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFBTVE4NQ2FycmllciBCAAChDxgAAAAP AAAAAAAACAAAAQAPAAAAAQACAAEADAAPAAPwVBYAAA8ABPBGAAAAAQAJ8BAAAAASAQAACQ0A AKEDAACUDgAAAgAK8AgAAABIDAAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ8AgAAAAJDRIBoQOU Dg8AA/AWFQAADwAE8E4AAAABAAnwEAAAAA8GAADAAgAAnggAAEsEAAACAArwCAAAAEkMAAAD AgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAABIBAAAJDQAAoQMAAJQOAAAPAATwYAAAADIACvAI AAAASgwAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAI AAECAgAACD8CAAACAAAAD/AQAAAA7gYAAMACAAALCAAAYgMAAA8ABPBgAAAAMgAK8AgAAABL DAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQIC AAAIPwIAAAIAAAAP8BAAAABSBgAA6gIAACwHAACMAwAADwAE8GAAAAAyAArwCAAAAEwMAAAC CgAAgwAL8DAAAACFAAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/ AgAAAgAAAA/wEAAAAA8GAABMAwAAogYAANADAAAPAATwYAAAADIACvAIAAAATQwAAAIKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAAC AAAAD/AQAAAAOwYAAIYDAAAZBwAAFQQAAA8ABPBgAAAAMgAK8AgAAABODAAAAgoAAIMAC/Aw AAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP 8BAAAADYBgAAnQMAACIIAABHBAAADwAE8GAAAAAyAArwCAAAAE8MAAACCgAAgwAL8DAAAACF AAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAA AKoHAADvAgAAfggAAG4DAAAPAATwYAAAADIACvAIAAAAUAwAAAIKAACDAAvwMAAAAIUAAgAA AIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAygcA AEEDAACcCAAAwAMAAA8ABPBgAAAAMgAK8AgAAABRDAAAAgoAAIMAC/AwAAAAhQACAAAAhwAB AAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAAC3BwAAWwMA AIgIAAAsBAAADwAE8GAAAAAyAArwCAAAAFIMAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACB AXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAAAIYGAAAdAwAALggA AO0DAAAPAATw9gAAADIBCvAIAAAAUwwAAAIKAADzAAvwxgAAAIUAAgAAAIcAAQAAAEIBtJ0A AEXBTgAAAEcB7DLHAEgB551RAUkBr08AAFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAA AP8BAAAIAAECAgAACD8CAAACAAkADAAIAE/7//8AAAAAD6QAAMCoAAAAAAAAoTgAALSdAAA/ NAAAT/v//wAAAAAPpAAAwKgAAAAAAAChOAAAtJ0AAD80AACvTwAAYFQAAAMABAAIAAAAAACh OAAAtJ0AAD80AACvTwAAYFQAAAAAD/AQAAAA9wYAAMECAAAECAAAEwMAAA8ABPAaAQAAMgEK 8AgAAABUDAAAAgoAAFMBC/DqAAAAhQACAAAAhwABAAAAQgG0nQAARcFOAAAARwHsMscASAHn nVEBSQGvTwAAUcEeAAAAgQEEAAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEA AAAA1AEAAAAA1QEAAAAA1wEAAAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgAT/v//wAAAAAP pAAAwKgAAAAAAAChOAAAtJ0AAD80AABP+///AAAAAA+kAADAqAAAAAAAAKE4AAC0nQAAPzQA AK9PAABgVAAAAwAEAAgAAAAAAKE4AAC0nQAAPzQAAK9PAABgVAAAAAAP8BAAAAD3BgAAwQIA AAQIAAATAwAADwAE8NgAAAAyAQrwCAAAAFUMAAACCgAAAwEL8KgAAACFAAIAAACHAAEAAABC AU6AAABDAbtlAABFwSQAAABHASMhqABIAcxfLQFJAWBUAABRwR4AAACBAXiOlgC/ARAAEADA AQEAAAjXAQAAAAD/AQAACAABAgIAAAg/AgAAAgAJAAkA8P8AAAAAwKjAqM4Bu2VOgFYMAAAA AMCowKjOAbtlToBWDGBUYFQDAAQACADOAQAAu2UAAE6AAABWDAAAYFQAAGBUAAAAAA/wEAAA AFMGAADqAgAA+gYAAE0DAAAPAATw/AAAADIBCvAIAAAAVgwAAAIKAABjAQvwzAAAAIUAAgAA AIcAAQAAAEIBToAAAEMBu2UAAEXBJAAAAEcBIyGoAEgBzF8tAUkBYFQAAFHBHgAAAIEBBAAA CIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAAANUBAAAAANcBAAAA AP8BCAAIAAECAgAACD8CAAACAAkACQDw/wAAAADAqMCozgG7ZU6AVgwAAAAAwKjAqM4Bu2VO gFYMYFRgVAMABAAIAM4BAAC7ZQAAToAAAFYMAABgVAAAYFQAAAAAD/AQAAAAUwYAAOoCAAD6 BgAATQMAAA8ABPACAQAAMgEK8AgAAABXDAAAAgoAABMBC/DSAAAAhQACAAAAhwABAAAAQgF7 fQAAQwHuWAAARcFOAAAARwFx2DwASAEUGLcASQFgVAAASgGOBAAAUcEeAAAAgQF4jpYAvwEQ ABAAwAEBAAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAMAAgAAAAAAC6w///AqAAA7lgA AHt9AAA9TgAAHwAAAAAAAAAAAAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAGBUAACO BAAAAwAEAAgAe30AAD1OAAAfAAAAAAAAAGBUAACOBAAAAAAP8BAAAAA6BgAAywMAAOQGAAAZ BAAADwAE8CYBAAAyAQrwCAAAAFgMAAACCgAAcwEL8PYAAACFAAIAAACHAAEAAABCAXt9AABD Ae5YAABFwU4AAABHAXHYPABIARQYtwBJAWBUAABKAY4EAABRwR4AAACBAQQAAAiDAQAAAAi/ AQAAEADAATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAAB AgIAAAg/AgAAAgAJAAwACAAAAAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAAAAAAAu sP//wKgAAO5YAAB7fQAAPU4AAB8AAAAAAAAAYFQAAI4EAAADAAQACAB7fQAAPU4AAB8AAAAA AAAAYFQAAI4EAAAAAA/wEAAAADoGAADLAwAA5AYAABkEAAAPAATw/AAAADIBCvAIAAAAWQwA AAIKAAADAQvwzAAAAIUAAgAAAIcAAQAAAEIBp2UAAEMBFX4AAEXBTgAAAEcBNy8CAUgBCaAd AEkBRxEAAFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAAC AAkADAAIAOe8//8AAAAAp2UAAMCoAAAAAAAAygEAAJ9aAAAVfgAA57z//wAAAACnZQAAwKgA AAAAAADKAQAAn1oAABV+AABHEQAAYFQAAAMABAAIAAAAAADKAQAAn1oAABV+AABHEQAAYFQA AAAAD/AQAAAAAQgAAPACAACBCAAATwMAAA8ABPAgAQAAMgEK8AgAAABaDAAAAgoAAGMBC/Dw AAAAhQACAAAAhwABAAAAQgGnZQAAQwEVfgAARcFOAAAARwE3LwIBSAEJoB0ASQFHEQAAUcEe AAAAgQEEAAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEA AAAA1wEAAAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgA57z//wAAAACnZQAAwKgAAAAAAADK AQAAn1oAABV+AADnvP//AAAAAKdlAADAqAAAAAAAAMoBAACfWgAAFX4AAEcRAABgVAAAAwAE AAgAAAAAAMoBAACfWgAAFX4AAEcRAABgVAAAAAAP8BAAAAABCAAA8AIAAIEIAABPAwAADwAE 8PYAAAAyAQrwCAAAAFsMAAACCgAA8wAL8MYAAACFAAIAAACHAAEAAABDARBzAABFwU4AAABH AQCFNAFIAamKIwBKAQRCAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAAB AgIAAAg/AgAAAgAJAAwACACgq///pO3//2BUAABklgAAjDQAAAAAAACoRAAAEHMAAKCr//+k 7f//YFQAAGSWAACMNAAAAAAAAKhEAAAQcwAAAAAAAARCAAADAAQACACMNAAAAAAAAKhEAAAQ cwAAAAAAAARCAAAAAA/wEAAAACQIAABOAwAAnggAAKwDAAAPAATwGgEAADIBCvAIAAAAXAwA AAIKAABTAQvw6gAAAIUAAgAAAIcAAQAAAEMBEHMAAEXBTgAAAEcBAIU0AUgBqYojAEoBBEIA AFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAA ANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAKCr//+k7f//YFQAAGSWAACM NAAAAAAAAKhEAAAQcwAAoKv//6Tt//9gVAAAZJYAAIw0AAAAAAAAqEQAABBzAAAAAAAABEIA AAMABAAIAIw0AAAAAAAAqEQAABBzAAAAAAAABEIAAAAAD/AQAAAAJAgAAE4DAACeCAAArAMA AA8ABPACAQAAMgEK8AgAAABdDAAAAgoAABMBC/DSAAAAhQACAAAAhwABAAAAQgHqbwAAQwFy bQAARcFOAAAARwFQt1YBSAHtDG0ASQGKGwAASgESGQAAUcEeAAAAgQF4jpYAvwEQABAAwAEB AAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAMAAgAKsf//7LE///qbwAAcm0AABtsAAAA AAAAAAAAANNoAAAqx///ssT//+pvAABybQAAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAwAE AAgAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAAAP8BAAAAD9BwAAqQMAAIwIAAAxBAAADwAE 8CYBAAAyAQrwCAAAAF4MAAACCgAAcwEL8PYAAACFAAIAAACHAAEAAABCAepvAABDAXJtAABF wU4AAABHAVC3VgFIAe0MbQBJAYobAABKARIZAABRwR4AAACBAQQAAAiDAQAAAAi/AQAAEADA ATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAABAgIAAAg/ AgAAAgAJAAwACAAqx///ssT//+pvAABybQAAG2wAAAAAAAAAAAAA02gAACrH//+yxP//6m8A AHJtAAAbbAAAAAAAAAAAAADTaAAAihsAABIZAAADAAQACAAbbAAAAAAAAAAAAADTaAAAihsA ABIZAAAAAA/wEAAAAP0HAACpAwAAjAgAADEEAAAPAATw/AAAADIBCvAIAAAAXwwAAAIKAAAD AQvwzAAAAIUAAgAAAIcAAQAAAEMB8qAAAEXBTgAAAEcBQ45yAEgB71UKAUkBYFQAAEoBNFQA AFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAACAAkADAAI AAAAAADU////wKgAAJSoAABQMQAA8qAAAPxOAAAAAAAAAAAAANT////AqAAAlKgAAFAxAADy oAAA/E4AAAAAAABgVAAANFQAAAMABAAIAFAxAADyoAAA/E4AAAAAAABgVAAANFQAAAAAD/AQ AAAAEAYAAE0DAABeBgAAzgMAAA8ABPAgAQAAMgEK8AgAAABgDAAAAgoAAGMBC/DwAAAAhQAC AAAAhwABAAAAQwHyoAAARcFOAAAARwFDjnIASAHvVQoBSQFgVAAASgE0VAAAUcEeAAAAgQEE AAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA1wEA AAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgAAAAAANT////AqAAAlKgAAFAxAADyoAAA/E4A AAAAAAAAAAAA1P///8CoAACUqAAAUDEAAPKgAAD8TgAAAAAAAGBUAAA0VAAAAwAEAAgAUDEA APKgAAD8TgAAAAAAAGBUAAA0VAAAAAAP8BAAAAAQBgAATQMAAF4GAADOAwAADwAE8PwAAAAy AQrwCAAAAGEMAAACCgAAAwEL8MwAAACFAAIAAACHAAEAAABCAVaYAABFwU4AAABHASWGIgBI Aab7qABJAdJSAABKAQAAAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAAB AgIAAAg/AgAAAgAJAAwACABy/v//oKv//zKnAABgVAAAVpgAANIvAAAAAAAAIBAAAHL+//+g q///MqcAAGBUAABWmAAA0i8AAAAAAAAgEAAA0lIAAAAAAAADAAQACABWmAAA0i8AAAAAAAAg EAAA0lIAAAAAAAAAAA/wEAAAAN4GAAD8AwAAAggAAEsEAAAPAATwIAEAADIBCvAIAAAAYgwA AAIKAABjAQvw8AAAAIUAAgAAAIcAAQAAAEIBVpgAAEXBTgAAAEcBJYYiAEgBpvuoAEkB0lIA AEoBAAAAAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAA ANQBAAAAANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAHL+//+gq///MqcA AGBUAABWmAAA0i8AAAAAAAAgEAAAcv7//6Cr//8ypwAAYFQAAFaYAADSLwAAAAAAACAQAADS UgAAAAAAAAMABAAIAFaYAADSLwAAAAAAACAQAADSUgAAAAAAAAAAD/AQAAAA3gYAAPwDAAAC CAAASwQAAA8ABPDgAAAAogwK8AgAAABjDAAAAgoAABMBC/BmAAAAgACEla8CgQDAHQEAggDg jgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwACAA8AgQH//2YAvwEMAB4AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAByAQAAUA0AAGcDAABk DgAADwAN8EIAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFBTVE4NQ2FycmllciBDAAChDxgAAAAP AAAAAAAACAAAAQAPAAAAAQACAAEADAAPAAPwVBYAAA8ABPBGAAAAAQAJ8BAAAADhEQAAoAgA AHAUAAArCgAAAgAK8AgAAABkDAAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ8AgAAACgCOERcBQr Cg8AA/AWFQAADwAE8E4AAAABAAnwEAAAAA8GAADAAgAAnggAAEsEAAACAArwCAAAAGUMAAAD AgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAOERAACgCAAAcBQAACsKAAAPAATwYAAAADIACvAI AAAAZgwAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAI AAECAgAACD8CAAACAAAAD/AQAAAA7gYAAMACAAALCAAAYgMAAA8ABPBgAAAAMgAK8AgAAABn DAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQIC AAAIPwIAAAIAAAAP8BAAAABSBgAA6gIAACwHAACMAwAADwAE8GAAAAAyAArwCAAAAGgMAAAC CgAAgwAL8DAAAACFAAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/ AgAAAgAAAA/wEAAAAA8GAABMAwAAogYAANADAAAPAATwYAAAADIACvAIAAAAaQwAAAIKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAAC AAAAD/AQAAAAOwYAAIYDAAAZBwAAFQQAAA8ABPBgAAAAMgAK8AgAAABqDAAAAgoAAIMAC/Aw AAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP 8BAAAADYBgAAnQMAACIIAABHBAAADwAE8GAAAAAyAArwCAAAAGsMAAACCgAAgwAL8DAAAACF AAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAA AKoHAADvAgAAfggAAG4DAAAPAATwYAAAADIACvAIAAAAbAwAAAIKAACDAAvwMAAAAIUAAgAA AIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAygcA AEEDAACcCAAAwAMAAA8ABPBgAAAAMgAK8AgAAABtDAAAAgoAAIMAC/AwAAAAhQACAAAAhwAB AAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAAC3BwAAWwMA AIgIAAAsBAAADwAE8GAAAAAyAArwCAAAAG4MAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACB AXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAAAIYGAAAdAwAALggA AO0DAAAPAATw9gAAADIBCvAIAAAAbwwAAAIKAADzAAvwxgAAAIUAAgAAAIcAAQAAAEIBtJ0A AEXBTgAAAEcB7DLHAEgB551RAUkBr08AAFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAA AP8BAAAIAAECAgAACD8CAAACAAkADAAIAE/7//8AAAAAD6QAAMCoAAAAAAAAoTgAALSdAAA/ NAAAT/v//wAAAAAPpAAAwKgAAAAAAAChOAAAtJ0AAD80AACvTwAAYFQAAAMABAAIAAAAAACh OAAAtJ0AAD80AACvTwAAYFQAAAAAD/AQAAAA9wYAAMECAAAECAAAEwMAAA8ABPAaAQAAMgEK 8AgAAABwDAAAAgoAAFMBC/DqAAAAhQACAAAAhwABAAAAQgG0nQAARcFOAAAARwHsMscASAHn nVEBSQGvTwAAUcEeAAAAgQEEAAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEA AAAA1AEAAAAA1QEAAAAA1wEAAAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgAT/v//wAAAAAP pAAAwKgAAAAAAAChOAAAtJ0AAD80AABP+///AAAAAA+kAADAqAAAAAAAAKE4AAC0nQAAPzQA AK9PAABgVAAAAwAEAAgAAAAAAKE4AAC0nQAAPzQAAK9PAABgVAAAAAAP8BAAAAD3BgAAwQIA AAQIAAATAwAADwAE8NgAAAAyAQrwCAAAAHEMAAACCgAAAwEL8KgAAACFAAIAAACHAAEAAABC AU6AAABDAbtlAABFwSQAAABHASMhqABIAcxfLQFJAWBUAABRwR4AAACBAXiOlgC/ARAAEADA AQEAAAjXAQAAAAD/AQAACAABAgIAAAg/AgAAAgAJAAkA8P8AAAAAwKjAqM4Bu2VOgFYMAAAA AMCowKjOAbtlToBWDGBUYFQDAAQACADOAQAAu2UAAE6AAABWDAAAYFQAAGBUAAAAAA/wEAAA AFMGAADqAgAA+gYAAE0DAAAPAATw/AAAADIBCvAIAAAAcgwAAAIKAABjAQvwzAAAAIUAAgAA AIcAAQAAAEIBToAAAEMBu2UAAEXBJAAAAEcBIyGoAEgBzF8tAUkBYFQAAFHBHgAAAIEBBAAA CIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAAANUBAAAAANcBAAAA AP8BCAAIAAECAgAACD8CAAACAAkACQDw/wAAAADAqMCozgG7ZU6AVgwAAAAAwKjAqM4Bu2VO gFYMYFRgVAMABAAIAM4BAAC7ZQAAToAAAFYMAABgVAAAYFQAAAAAD/AQAAAAUwYAAOoCAAD6 BgAATQMAAA8ABPACAQAAMgEK8AgAAABzDAAAAgoAABMBC/DSAAAAhQACAAAAhwABAAAAQgF7 fQAAQwHuWAAARcFOAAAARwFx2DwASAEUGLcASQFgVAAASgGOBAAAUcEeAAAAgQF4jpYAvwEQ ABAAwAEBAAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAMAAgAAAAAAC6w///AqAAA7lgA AHt9AAA9TgAAHwAAAAAAAAAAAAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAGBUAACO BAAAAwAEAAgAe30AAD1OAAAfAAAAAAAAAGBUAACOBAAAAAAP8BAAAAA6BgAAywMAAOQGAAAZ BAAADwAE8CYBAAAyAQrwCAAAAHQMAAACCgAAcwEL8PYAAACFAAIAAACHAAEAAABCAXt9AABD Ae5YAABFwU4AAABHAXHYPABIARQYtwBJAWBUAABKAY4EAABRwR4AAACBAQQAAAiDAQAAAAi/ AQAAEADAATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAAB AgIAAAg/AgAAAgAJAAwACAAAAAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAAAAAAAu sP//wKgAAO5YAAB7fQAAPU4AAB8AAAAAAAAAYFQAAI4EAAADAAQACAB7fQAAPU4AAB8AAAAA AAAAYFQAAI4EAAAAAA/wEAAAADoGAADLAwAA5AYAABkEAAAPAATw/AAAADIBCvAIAAAAdQwA AAIKAAADAQvwzAAAAIUAAgAAAIcAAQAAAEIBp2UAAEMBFX4AAEXBTgAAAEcBNy8CAUgBCaAd AEkBRxEAAFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAAC AAkADAAIAOe8//8AAAAAp2UAAMCoAAAAAAAAygEAAJ9aAAAVfgAA57z//wAAAACnZQAAwKgA AAAAAADKAQAAn1oAABV+AABHEQAAYFQAAAMABAAIAAAAAADKAQAAn1oAABV+AABHEQAAYFQA AAAAD/AQAAAAAQgAAPACAACBCAAATwMAAA8ABPAgAQAAMgEK8AgAAAB2DAAAAgoAAGMBC/Dw AAAAhQACAAAAhwABAAAAQgGnZQAAQwEVfgAARcFOAAAARwE3LwIBSAEJoB0ASQFHEQAAUcEe AAAAgQEEAAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEA AAAA1wEAAAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgA57z//wAAAACnZQAAwKgAAAAAAADK AQAAn1oAABV+AADnvP//AAAAAKdlAADAqAAAAAAAAMoBAACfWgAAFX4AAEcRAABgVAAAAwAE AAgAAAAAAMoBAACfWgAAFX4AAEcRAABgVAAAAAAP8BAAAAABCAAA8AIAAIEIAABPAwAADwAE 8PYAAAAyAQrwCAAAAHcMAAACCgAA8wAL8MYAAACFAAIAAACHAAEAAABDARBzAABFwU4AAABH AQCFNAFIAamKIwBKAQRCAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAAB AgIAAAg/AgAAAgAJAAwACACgq///pO3//2BUAABklgAAjDQAAAAAAACoRAAAEHMAAKCr//+k 7f//YFQAAGSWAACMNAAAAAAAAKhEAAAQcwAAAAAAAARCAAADAAQACACMNAAAAAAAAKhEAAAQ cwAAAAAAAARCAAAAAA/wEAAAACQIAABOAwAAnggAAKwDAAAPAATwGgEAADIBCvAIAAAAeAwA AAIKAABTAQvw6gAAAIUAAgAAAIcAAQAAAEMBEHMAAEXBTgAAAEcBAIU0AUgBqYojAEoBBEIA AFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAA ANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAKCr//+k7f//YFQAAGSWAACM NAAAAAAAAKhEAAAQcwAAoKv//6Tt//9gVAAAZJYAAIw0AAAAAAAAqEQAABBzAAAAAAAABEIA AAMABAAIAIw0AAAAAAAAqEQAABBzAAAAAAAABEIAAAAAD/AQAAAAJAgAAE4DAACeCAAArAMA AA8ABPACAQAAMgEK8AgAAAB5DAAAAgoAABMBC/DSAAAAhQACAAAAhwABAAAAQgHqbwAAQwFy bQAARcFOAAAARwFQt1YBSAHtDG0ASQGKGwAASgESGQAAUcEeAAAAgQF4jpYAvwEQABAAwAEB AAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAMAAgAKsf//7LE///qbwAAcm0AABtsAAAA AAAAAAAAANNoAAAqx///ssT//+pvAABybQAAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAwAE AAgAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAAAP8BAAAAD9BwAAqQMAAIwIAAAxBAAADwAE 8CYBAAAyAQrwCAAAAHoMAAACCgAAcwEL8PYAAACFAAIAAACHAAEAAABCAepvAABDAXJtAABF wU4AAABHAVC3VgFIAe0MbQBJAYobAABKARIZAABRwR4AAACBAQQAAAiDAQAAAAi/AQAAEADA ATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAABAgIAAAg/ AgAAAgAJAAwACAAqx///ssT//+pvAABybQAAG2wAAAAAAAAAAAAA02gAACrH//+yxP//6m8A AHJtAAAbbAAAAAAAAAAAAADTaAAAihsAABIZAAADAAQACAAbbAAAAAAAAAAAAADTaAAAihsA ABIZAAAAAA/wEAAAAP0HAACpAwAAjAgAADEEAAAPAATw/AAAADIBCvAIAAAAewwAAAIKAAAD AQvwzAAAAIUAAgAAAIcAAQAAAEMB8qAAAEXBTgAAAEcBQ45yAEgB71UKAUkBYFQAAEoBNFQA AFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAACAAkADAAI AAAAAADU////wKgAAJSoAABQMQAA8qAAAPxOAAAAAAAAAAAAANT////AqAAAlKgAAFAxAADy oAAA/E4AAAAAAABgVAAANFQAAAMABAAIAFAxAADyoAAA/E4AAAAAAABgVAAANFQAAAAAD/AQ AAAAEAYAAE0DAABeBgAAzgMAAA8ABPAgAQAAMgEK8AgAAAB8DAAAAgoAAGMBC/DwAAAAhQAC AAAAhwABAAAAQwHyoAAARcFOAAAARwFDjnIASAHvVQoBSQFgVAAASgE0VAAAUcEeAAAAgQEE AAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA1wEA AAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgAAAAAANT////AqAAAlKgAAFAxAADyoAAA/E4A AAAAAAAAAAAA1P///8CoAACUqAAAUDEAAPKgAAD8TgAAAAAAAGBUAAA0VAAAAwAEAAgAUDEA APKgAAD8TgAAAAAAAGBUAAA0VAAAAAAP8BAAAAAQBgAATQMAAF4GAADOAwAADwAE8PwAAAAy AQrwCAAAAH0MAAACCgAAAwEL8MwAAACFAAIAAACHAAEAAABCAVaYAABFwU4AAABHASWGIgBI Aab7qABJAdJSAABKAQAAAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAAB AgIAAAg/AgAAAgAJAAwACABy/v//oKv//zKnAABgVAAAVpgAANIvAAAAAAAAIBAAAHL+//+g q///MqcAAGBUAABWmAAA0i8AAAAAAAAgEAAA0lIAAAAAAAADAAQACABWmAAA0i8AAAAAAAAg EAAA0lIAAAAAAAAAAA/wEAAAAN4GAAD8AwAAAggAAEsEAAAPAATwIAEAADIBCvAIAAAAfgwA AAIKAABjAQvw8AAAAIUAAgAAAIcAAQAAAEIBVpgAAEXBTgAAAEcBJYYiAEgBpvuoAEkB0lIA AEoBAAAAAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAA ANQBAAAAANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAHL+//+gq///MqcA AGBUAABWmAAA0i8AAAAAAAAgEAAAcv7//6Cr//8ypwAAYFQAAFaYAADSLwAAAAAAACAQAADS UgAAAAAAAAMABAAIAFaYAADSLwAAAAAAACAQAADSUgAAAAAAAAAAD/AQAAAA3gYAAPwDAAAC CAAASwQAAA8ABPDgAAAAogwK8AgAAAB/DAAAAgoAABMBC/BmAAAAgABEma8CgQDAHQEAggDg jgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwACAA8AgQH//2YAvwEMAB4AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAABcEgAA5wgAAFEUAAD7 CQAADwAN8EIAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFBTVE4NQ2FycmllciBCAAChDxgAAAAP AAAAAAAACAAAAQAPAAAAAQACAAEADAAPAAPwVBYAAA8ABPBGAAAAAQAJ8BAAAADCEQAA0AsA AFEUAABbDQAAAgAK8AgAAACADAAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ8AgAAADQC8IRURRb DQ8AA/AWFQAADwAE8E4AAAABAAnwEAAAAA8GAADAAgAAnggAAEsEAAACAArwCAAAAIEMAAAD AgAAEwAL8AYAAACIAwAAAAAAAA/wEAAAAMIRAADQCwAAURQAAFsNAAAPAATwYAAAADIACvAI AAAAggwAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAI AAECAgAACD8CAAACAAAAD/AQAAAA7gYAAMACAAALCAAAYgMAAA8ABPBgAAAAMgAK8AgAAACD DAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQIC AAAIPwIAAAIAAAAP8BAAAABSBgAA6gIAACwHAACMAwAADwAE8GAAAAAyAArwCAAAAIQMAAAC CgAAgwAL8DAAAACFAAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/ AgAAAgAAAA/wEAAAAA8GAABMAwAAogYAANADAAAPAATwYAAAADIACvAIAAAAhQwAAAIKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAAC AAAAD/AQAAAAOwYAAIYDAAAZBwAAFQQAAA8ABPBgAAAAMgAK8AgAAACGDAAAAgoAAIMAC/Aw AAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP 8BAAAADYBgAAnQMAACIIAABHBAAADwAE8GAAAAAyAArwCAAAAIcMAAACCgAAgwAL8DAAAACF AAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAA AKoHAADvAgAAfggAAG4DAAAPAATwYAAAADIACvAIAAAAiAwAAAIKAACDAAvwMAAAAIUAAgAA AIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAygcA AEEDAACcCAAAwAMAAA8ABPBgAAAAMgAK8AgAAACJDAAAAgoAAIMAC/AwAAAAhQACAAAAhwAB AAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAAC3BwAAWwMA AIgIAAAsBAAADwAE8GAAAAAyAArwCAAAAIoMAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACB AXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAAAIYGAAAdAwAALggA AO0DAAAPAATw9gAAADIBCvAIAAAAiwwAAAIKAADzAAvwxgAAAIUAAgAAAIcAAQAAAEIBtJ0A AEXBTgAAAEcB7DLHAEgB551RAUkBr08AAFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAA AP8BAAAIAAECAgAACD8CAAACAAkADAAIAE/7//8AAAAAD6QAAMCoAAAAAAAAoTgAALSdAAA/ NAAAT/v//wAAAAAPpAAAwKgAAAAAAAChOAAAtJ0AAD80AACvTwAAYFQAAAMABAAIAAAAAACh OAAAtJ0AAD80AACvTwAAYFQAAAAAD/AQAAAA9wYAAMECAAAECAAAEwMAAA8ABPAaAQAAMgEK 8AgAAACMDAAAAgoAAFMBC/DqAAAAhQACAAAAhwABAAAAQgG0nQAARcFOAAAARwHsMscASAHn nVEBSQGvTwAAUcEeAAAAgQEEAAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEA AAAA1AEAAAAA1QEAAAAA1wEAAAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgAT/v//wAAAAAP pAAAwKgAAAAAAAChOAAAtJ0AAD80AABP+///AAAAAA+kAADAqAAAAAAAAKE4AAC0nQAAPzQA AK9PAABgVAAAAwAEAAgAAAAAAKE4AAC0nQAAPzQAAK9PAABgVAAAAAAP8BAAAAD3BgAAwQIA AAQIAAATAwAADwAE8NgAAAAyAQrwCAAAAI0MAAACCgAAAwEL8KgAAACFAAIAAACHAAEAAABC AU6AAABDAbtlAABFwSQAAABHASMhqABIAcxfLQFJAWBUAABRwR4AAACBAXiOlgC/ARAAEADA AQEAAAjXAQAAAAD/AQAACAABAgIAAAg/AgAAAgAJAAkA8P8AAAAAwKjAqM4Bu2VOgFYMAAAA AMCowKjOAbtlToBWDGBUYFQDAAQACADOAQAAu2UAAE6AAABWDAAAYFQAAGBUAAAAAA/wEAAA AFMGAADqAgAA+gYAAE0DAAAPAATw/AAAADIBCvAIAAAAjgwAAAIKAABjAQvwzAAAAIUAAgAA AIcAAQAAAEIBToAAAEMBu2UAAEXBJAAAAEcBIyGoAEgBzF8tAUkBYFQAAFHBHgAAAIEBBAAA CIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAAANUBAAAAANcBAAAA AP8BCAAIAAECAgAACD8CAAACAAkACQDw/wAAAADAqMCozgG7ZU6AVgwAAAAAwKjAqM4Bu2VO gFYMYFRgVAMABAAIAM4BAAC7ZQAAToAAAFYMAABgVAAAYFQAAAAAD/AQAAAAUwYAAOoCAAD6 BgAATQMAAA8ABPACAQAAMgEK8AgAAACPDAAAAgoAABMBC/DSAAAAhQACAAAAhwABAAAAQgF7 fQAAQwHuWAAARcFOAAAARwFx2DwASAEUGLcASQFgVAAASgGOBAAAUcEeAAAAgQF4jpYAvwEQ ABAAwAEBAAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAMAAgAAAAAAC6w///AqAAA7lgA AHt9AAA9TgAAHwAAAAAAAAAAAAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAGBUAACO BAAAAwAEAAgAe30AAD1OAAAfAAAAAAAAAGBUAACOBAAAAAAP8BAAAAA6BgAAywMAAOQGAAAZ BAAADwAE8CYBAAAyAQrwCAAAAJAMAAACCgAAcwEL8PYAAACFAAIAAACHAAEAAABCAXt9AABD Ae5YAABFwU4AAABHAXHYPABIARQYtwBJAWBUAABKAY4EAABRwR4AAACBAQQAAAiDAQAAAAi/ AQAAEADAATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAAB AgIAAAg/AgAAAgAJAAwACAAAAAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAAAAAAAu sP//wKgAAO5YAAB7fQAAPU4AAB8AAAAAAAAAYFQAAI4EAAADAAQACAB7fQAAPU4AAB8AAAAA AAAAYFQAAI4EAAAAAA/wEAAAADoGAADLAwAA5AYAABkEAAAPAATw/AAAADIBCvAIAAAAkQwA AAIKAAADAQvwzAAAAIUAAgAAAIcAAQAAAEIBp2UAAEMBFX4AAEXBTgAAAEcBNy8CAUgBCaAd AEkBRxEAAFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAAC AAkADAAIAOe8//8AAAAAp2UAAMCoAAAAAAAAygEAAJ9aAAAVfgAA57z//wAAAACnZQAAwKgA AAAAAADKAQAAn1oAABV+AABHEQAAYFQAAAMABAAIAAAAAADKAQAAn1oAABV+AABHEQAAYFQA AAAAD/AQAAAAAQgAAPACAACBCAAATwMAAA8ABPAgAQAAMgEK8AgAAACSDAAAAgoAAGMBC/Dw AAAAhQACAAAAhwABAAAAQgGnZQAAQwEVfgAARcFOAAAARwE3LwIBSAEJoB0ASQFHEQAAUcEe AAAAgQEEAAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEA AAAA1wEAAAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgA57z//wAAAACnZQAAwKgAAAAAAADK AQAAn1oAABV+AADnvP//AAAAAKdlAADAqAAAAAAAAMoBAACfWgAAFX4AAEcRAABgVAAAAwAE AAgAAAAAAMoBAACfWgAAFX4AAEcRAABgVAAAAAAP8BAAAAABCAAA8AIAAIEIAABPAwAADwAE 8PYAAAAyAQrwCAAAAJMMAAACCgAA8wAL8MYAAACFAAIAAACHAAEAAABDARBzAABFwU4AAABH AQCFNAFIAamKIwBKAQRCAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAAB AgIAAAg/AgAAAgAJAAwACACgq///pO3//2BUAABklgAAjDQAAAAAAACoRAAAEHMAAKCr//+k 7f//YFQAAGSWAACMNAAAAAAAAKhEAAAQcwAAAAAAAARCAAADAAQACACMNAAAAAAAAKhEAAAQ cwAAAAAAAARCAAAAAA/wEAAAACQIAABOAwAAnggAAKwDAAAPAATwGgEAADIBCvAIAAAAlAwA AAIKAABTAQvw6gAAAIUAAgAAAIcAAQAAAEMBEHMAAEXBTgAAAEcBAIU0AUgBqYojAEoBBEIA AFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAA ANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAKCr//+k7f//YFQAAGSWAACM NAAAAAAAAKhEAAAQcwAAoKv//6Tt//9gVAAAZJYAAIw0AAAAAAAAqEQAABBzAAAAAAAABEIA AAMABAAIAIw0AAAAAAAAqEQAABBzAAAAAAAABEIAAAAAD/AQAAAAJAgAAE4DAACeCAAArAMA AA8ABPACAQAAMgEK8AgAAACVDAAAAgoAABMBC/DSAAAAhQACAAAAhwABAAAAQgHqbwAAQwFy bQAARcFOAAAARwFQt1YBSAHtDG0ASQGKGwAASgESGQAAUcEeAAAAgQF4jpYAvwEQABAAwAEB AAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAMAAgAKsf//7LE///qbwAAcm0AABtsAAAA AAAAAAAAANNoAAAqx///ssT//+pvAABybQAAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAwAE AAgAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAAAP8BAAAAD9BwAAqQMAAIwIAAAxBAAADwAE 8CYBAAAyAQrwCAAAAJYMAAACCgAAcwEL8PYAAACFAAIAAACHAAEAAABCAepvAABDAXJtAABF wU4AAABHAVC3VgFIAe0MbQBJAYobAABKARIZAABRwR4AAACBAQQAAAiDAQAAAAi/AQAAEADA ATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAABAgIAAAg/ AgAAAgAJAAwACAAqx///ssT//+pvAABybQAAG2wAAAAAAAAAAAAA02gAACrH//+yxP//6m8A AHJtAAAbbAAAAAAAAAAAAADTaAAAihsAABIZAAADAAQACAAbbAAAAAAAAAAAAADTaAAAihsA ABIZAAAAAA/wEAAAAP0HAACpAwAAjAgAADEEAAAPAATw/AAAADIBCvAIAAAAlwwAAAIKAAAD AQvwzAAAAIUAAgAAAIcAAQAAAEMB8qAAAEXBTgAAAEcBQ45yAEgB71UKAUkBYFQAAEoBNFQA AFHBHgAAAIEBeI6WAL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAACAAkADAAI AAAAAADU////wKgAAJSoAABQMQAA8qAAAPxOAAAAAAAAAAAAANT////AqAAAlKgAAFAxAADy oAAA/E4AAAAAAABgVAAANFQAAAMABAAIAFAxAADyoAAA/E4AAAAAAABgVAAANFQAAAAAD/AQ AAAAEAYAAE0DAABeBgAAzgMAAA8ABPAgAQAAMgEK8AgAAACYDAAAAgoAAGMBC/DwAAAAhQAC AAAAhwABAAAAQwHyoAAARcFOAAAARwFDjnIASAHvVQoBSQFgVAAASgE0VAAAUcEeAAAAgQEE AAAIgwEAAAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA1wEA AAAA/wEIAAgAAQICAAAIPwIAAAIACQAMAAgAAAAAANT////AqAAAlKgAAFAxAADyoAAA/E4A AAAAAAAAAAAA1P///8CoAACUqAAAUDEAAPKgAAD8TgAAAAAAAGBUAAA0VAAAAwAEAAgAUDEA APKgAAD8TgAAAAAAAGBUAAA0VAAAAAAP8BAAAAAQBgAATQMAAF4GAADOAwAADwAE8PwAAAAy AQrwCAAAAJkMAAACCgAAAwEL8MwAAACFAAIAAACHAAEAAABCAVaYAABFwU4AAABHASWGIgBI Aab7qABJAdJSAABKAQAAAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAAB AgIAAAg/AgAAAgAJAAwACABy/v//oKv//zKnAABgVAAAVpgAANIvAAAAAAAAIBAAAHL+//+g q///MqcAAGBUAABWmAAA0i8AAAAAAAAgEAAA0lIAAAAAAAADAAQACABWmAAA0i8AAAAAAAAg EAAA0lIAAAAAAAAAAA/wEAAAAN4GAAD8AwAAAggAAEsEAAAPAATwIAEAADIBCvAIAAAAmgwA AAIKAABjAQvw8AAAAIUAAgAAAIcAAQAAAEIBVpgAAEXBTgAAAEcBJYYiAEgBpvuoAEkB0lIA AEoBAAAAAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAA ANQBAAAAANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAHL+//+gq///MqcA AGBUAABWmAAA0i8AAAAAAAAgEAAAcv7//6Cr//8ypwAAYFQAAFaYAADSLwAAAAAAACAQAADS UgAAAAAAAAMABAAIAFaYAADSLwAAAAAAACAQAADSUgAAAAAAAAAAD/AQAAAA3gYAAPwDAAAC CAAASwQAAA8ABPDgAAAAogwK8AgAAACbDAAAAgoAABMBC/BmAAAAgACk6WwBgQDAHQEAggDg jgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwACAA8AgQH//2YAvwEMAB4AwAEBAAAI/wEG AA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAAAiEgAADAwAABcUAAAg DQAADwAN8EIAAAAAAJ8PBAAAAAQAAAAAAKgPDgAAAFBTVE4NQ2FycmllciBEAAChDxgAAAAP AAAAAAAACAAAAQAPAAAAAQACAAEADAAPAATwjgAAAEIBCvAIAAAAnAwAAIAKAAATAQvwZgAA AIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAAB AL8BAAAQAMABAQAACP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAI AAAAwAmQBkAIQAsPAATwjgAAAEIBCvAIAAAAnQwAAIAKAAATAQvwZgAAAIEAwB0BAIIA4I4A AIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAA CP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAEAUQCxALcAgP AATwjgAAAEIBCvAIAAAAngwAAAAKAAATAQvwZgAAAIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4A AIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BHgAeAAECAgAA CD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAwAlADgAPQAsPAATwlAAAAEIBCvAI AAAAnwwAAAAKAAAjAQvwbAAAAIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAA AL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABAQAACMsBn28AAP8BHgAeAAECAgAACD8CAAAD AL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAcAvABjAPcAsPAAPwpwEAAA8ABPBGAAAAAQAJ 8BAAAADgEAAA8AkAAKAUAAD3CwAAAgAK8AgAAACgDAAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ 8AgAAADwA/AJ8AyQBQ8ABPByAAAAsgQK8AgAAAChDAAAAgoAALMAC/BCAAAAfwAAAIAAhQAC AAAAhwABAAAABEECAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIA AAIAAAAP8BAAAADgEAAA8AkAAKAUAADVCwAADwAE8NcAAACiDArwCAAAAKIMAAACCgAA4wAL 8FQAAAB/AIAAgACAAGTqbAG/AAIAAgCBAQAAAAi/ARAAEADAAQUAAAjLAWpKAADSAQAAAADT AQAAAADUAQAAAADVAQAAAAD/AQgACAABAgEAAAg/AgAAAgAAAA/wEAAAAPgQAACwCgAAQBQA APcLAAAPAA3wSwAAAAAAnw8EAAAABAAAAAAAqA8VAAAAQ2FycmllciBQb2xpY3kgU2VydmVy AAChDxoAAAAWAAAAAAAAKAAAAQAyABYAAAABAAIAAQAKAA8AA/C1AQAADwAE8EYAAAABAAnw EAAAACMMAAAhDQAAOQ0AAFYOAAACAArwCAAAAKMMAAABAgAAEwAL8AYAAACIAwAAAAAAABDw CAAAAOAKsQ7HDxUMDwAE8HIAAACyBArwCAAAAKQMAAACCgAAswAL8EIAAAB/AAAAgACFAAIA AACHAAEAAAAEQQMAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAA AgAAAA/wEAAAACMMAAAhDQAAOQ0AAFYOAAAPAATw5QAAABIACvAIAAAApQwAAAIKAADzAAvw WgAAAIAAxOpsAYEA2hABAIIAoI4AAIMA2hABAIQAoI4AAIUAAgAAAIcAAQAAAL8AEAAfAIEB AAAACL8BEAAQAMABBQAACMsBOGMAAP8BCAAIAAECAgAACD8CAAACAAAAD/AQAAAASwwAANYN AAARDQAAVg4AAA8ADfBTAAAAAACfDwQAAAAEAAAAAACoDwEAAABWAAChDxgAAAACAAAAAAAA CAAAAQACAAAAAQACAAEADgAAAKYPFgAAAPEeAABSAd0A3QC5AbkBlQKVAnEDcQMPAAPwtQEA AA8ABPBGAAAAAQAJ8BAAAAAjDAAAIQ0AADkNAABWDgAAAgAK8AgAAACmDAAAAQIAABMAC/AG AAAAiAMAAAAAAAAQ8AgAAACwChEGJwflCw8ABPByAAAAsgQK8AgAAACnDAAAAgoAALMAC/BC AAAAfwAAAIAAhQACAAAAhwABAAAABEEDAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEA AAgAAQICAAAIPwIAAAIAAAAP8BAAAAAjDAAAIQ0AADkNAABWDgAADwAE8OUAAAASAArwCAAA AKgMAAACCgAA8wAL8FoAAACAACTrbAGBANoQAQCCAKCOAACDANoQAQCEAKCOAACFAAIAAACH AAEAAAC/ABAAHwCBAQAAAAi/ARAAEADAAQUAAAjLAThjAAD/AQgACAABAgIAAAg/AgAAAgAA AA/wEAAAAEsMAADWDQAAEQ0AAFYOAAAPAA3wUwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAVgAA oQ8YAAAAAgAAAAAAAAgAAAEAAgAAAAEAAgABAA4AAACmDxYAAADxHgAAUgHdAN0AuQG5AZUC lQJxA3EDDwAE8KgAAACyBArwCAAAAKkMAAAQCgAAIwEL8GwAAACBAEEdAQCCAKCOAACDAEEd AQCEAKCOAAC/AAAADwAEQQQAAAALAQEAAAA/AQAAAQCBAQQAAAiDAQAAAAi/AQwAHgDAAQEA AAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAEAIAwgkCQkK DwAR8AwAAAAAAMELBAAAAAEAAAAPAATwjgAAAEIBCvAIAAAAqgwAAAAKAAATAQvwZgAAAIEA wB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAAAPAEQBBAAAAH8BAAABAL8B AAAQAMABAQAACP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAA AAkACYANAAkPAAPwtQEAAA8ABPBGAAAAAQAJ8BAAAAAjDAAAIQ0AADkNAABWDgAAAgAK8AgA AACrDAAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ8AgAAAAQC2AGdgdFDA8ABPByAAAAsgQK8AgA AACsDAAAAgoAALMAC/BCAAAAfwAAAIAAhQACAAAAhwABAAAABEEDAAAAgQEEAAAIgwEAAAAI vwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAAAjDAAAIQ0AADkNAABWDgAA DwAE8OUAAAASAArwCAAAAK0MAAACCgAA8wAL8FoAAACAAOTrbAGBANoQAQCCAKCOAACDANoQ AQCEAKCOAACFAAIAAACHAAEAAAC/ABAAHwCBAQAAAAi/ARAAEADAAQUAAAjLAThjAAD/AQgA CAABAgIAAAg/AgAAAgAAAA/wEAAAAEsMAADWDQAAEQ0AAFYOAAAPAA3wUwAAAAAAnw8EAAAA BAAAAAAAqA8BAAAAVgAAoQ8YAAAAAgAAAAAAAAgAAAEAAgAAAAEAAgABAA4AAACmDxYAAADx HgAAUgHdAN0AuQG5AZUClQJxA3EDDwAD8LUBAAAPAATwRgAAAAEACfAQAAAAIwwAACENAAA5 DQAAVg4AAAIACvAIAAAArgwAAAECAAATAAvwBgAAAIgDAAAAAAAAEPAIAAAAiwvABtYHwAwP AATwcgAAALIECvAIAAAArwwAAAIKAACzAAvwQgAAAH8AAACAAIUAAgAAAIcAAQAAAARBAwAA AIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAIwwA ACENAAA5DQAAVg4AAA8ABPDlAAAAEgAK8AgAAACwDAAAAgoAAPMAC/BaAAAAgABE7GwBgQDa EAEAggCgjgAAgwDaEAEAhACgjgAAhQACAAAAhwABAAAAvwAQAB8AgQEAAAAIvwEQABAAwAEF AAAIywE4YwAA/wEIAAgAAQICAAAIPwIAAAIAAAAP8BAAAABLDAAA1g0AABENAABWDgAADwAN 8FMAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAFYAAKEPGAAAAAIAAAAAAAAIAAABAAIAAAABAAIA AQAOAAAApg8WAAAA8R4AAFIB3QDdALkBuQGVApUCcQNxAw8AA/C1AQAADwAE8EYAAAABAAnw EAAAACMMAAAhDQAAOQ0AAFYOAAACAArwCAAAALEMAAABAgAAEwAL8AYAAACIAwAAAAAAABDw CAAAAFsLQA5WD5AMDwAE8HIAAACyBArwCAAAALIMAAACCgAAswAL8EIAAAB/AAAAgACFAAIA AACHAAEAAAAEQQMAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAA AgAAAA/wEAAAACMMAAAhDQAAOQ0AAFYOAAAPAATw5QAAABIACvAIAAAAswwAAAIKAADzAAvw WgAAAIAApOxsAYEA2hABAIIAoI4AAIMA2hABAIQAoI4AAIUAAgAAAIcAAQAAAL8AEAAfAIEB AAAACL8BEAAQAMABBQAACMsBOGMAAP8BCAAIAAECAgAACD8CAAACAAAAD/AQAAAASwwAANYN AAARDQAAVg4AAA8ADfBTAAAAAACfDwQAAAAEAAAAAACoDwEAAABWAAChDxgAAAACAAAAAAAA CAAAAQACAAAAAQACAAEADgAAAKYPFgAAAPEeAABSAd0A3QC5AbkBlQKVAnEDcQMPAATwqAAA ALIECvAIAAAAtAwAABAKAAAjAQvwbAAAAIEAQR0BAIIAoI4AAIMAQR0BAIQAoI4AAL8AAAAP AARBBAAAAAsBAgAAAD8BAAABAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAA CD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAQAhPDXAOCQoPABHwDAAAAAAAwQsE AAAAAgAAAA8ABPCcAAAAEgAK8AgAAAC2DAAAIAoAAMMAC/BIAAAABAAAAAAAfwABAAEAgAA0 RgMIhwABAAAAgQEEAAAIgwEAAAAIvwEAABEAwAEBAAAI/wEAAAkAAQICAAAIAQMCBAAAiAMA AAAAAAAQ8AgAAADwALAB0BTAAw8AEfAQAAAAAADDCwgAAAAAAAAADQBrCA8ADfAMAAAAAACe DwQAAAAAAAAADwAD8LUBAAAPAATwRgAAAAEACfAQAAAAIwwAACENAAA5DQAAVg4AAAIACvAI AAAAuAwAAAECAAATAAvwBgAAAIgDAAAAAAAAEPAIAAAAwAPwALABlQQPAATwcgAAALIECvAI AAAAuQwAAAIKAACzAAvwQgAAAH8AAACAAIUAAgAAAIcAAQAAAARBAwAAAIEBBAAACIMBAAAA CL8BAAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAIwwAACENAAA5DQAAVg4A AA8ABPDlAAAAEgAK8AgAAAC6DAAAAgoAAPMAC/BaAAAAgABURwMIgQDaEAEAggCgjgAAgwDa EAEAhACgjgAAhQACAAAAhwABAAAAvwAQAB8AgQEAAAAIvwEQABAAwAEFAAAIywE4YwAA/wEI AAgAAQICAAAIPwIAAAIAAAAP8BAAAABLDAAA1g0AABENAABWDgAADwAN8FMAAAAAAJ8PBAAA AAQAAAAAAKgPAQAAAFYAAKEPGAAAAAIAAAAAAAAIAAABAAIAAAABAAIAAQAOAAAApg8WAAAA 8R4AAFIB3QDdALkBuQGVApUCcQNxAw8ABPCwAAAAogwK8AgAAAC7DAAAAAoAAKMAC/A8AAAA gAC0RwMIhQACAAAAhwAGAAAAvwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgA AQICAAAIAAAQ8AgAAACoA6YBfgWPBA8ADfBEAAAAAACfDwQAAAAEAAAAAACoDwwAAABQU1RO IGdhdGV3YXkAAKEPHAAAAA0AAAAAAAAAAAAMAAAAAAACABIAAQAAAAAAAAAPAATwqAAAALIE CvAIAAAAvAwAABAKAAAjAQvwbAAAAIEAQR0BAIIAoI4AAIMAQR0BAIQAoI4AAL8AAAAPAARB BAAAAAsBCwAAAD8BAAABAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8C AAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAA4AQIAbAB6QUPABHwDAAAAAAAwQsEAAAA CwAAAA8ABPCwAAAAogwK8AgAAAC9DAAAAAoAAKMAC/A8AAAAgACUQwMIhQACAAAAhwAGAAAA vwACAAIAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAADeBOAB SAXFBQ8ADfBEAAAAAACfDwQAAAAEAAAAAACoDwwAAABQcm94eSBTZXJ2ZXIAAKEPHAAAAA0A AAAAAAAAAAAMAAAAAAACABIAAQAAAAAAAAAPAATwSAAAABIACvAIAAAAAQwAAAAMAACDAAvw MAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BHgAfAP8BAAAIAAQDCQAAAD8DAQABAA8F BfAABQAAAAAU8AgAAAABAAAAGwwAAAAAFPAIAAAAAgAAABwMAAAAABTwCAAAAAMAAAAdDAAA AAAU8AgAAAAEAAAAHgwAAAAAFPAIAAAABQAAAB8MAAAAABTwCAAAAAYAAAAgDAAAAAAU8AgA AAAHAAAAIQwAAAAAFPAIAAAACAAAACIMAAAAABTwCAAAAAkAAAAjDAAAAAAU8AgAAAAKAAAA JAwAAAAAFPAIAAAACwAAACUMAAAAABTwCAAAAAwAAAAmDAAAAAAU8AgAAAANAAAAJwwAAAAA FPAIAAAADgAAACgMAAAAABTwCAAAAA8AAAApDAAAAAAU8AgAAAAQAAAAKgwAAAAAFPAIAAAA EQAAADcMAAAAABTwCAAAABIAAAA4DAAAAAAU8AgAAAATAAAAOQwAAAAAFPAIAAAAFAAAADoM AAAAABTwCAAAABUAAAA7DAAAAAAU8AgAAAAWAAAAPAwAAAAAFPAIAAAAFwAAAD0MAAAAABTw CAAAABgAAAA+DAAAAAAU8AgAAAAZAAAAPwwAAAAAFPAIAAAAGgAAAEAMAAAAABTwCAAAABsA AABBDAAAAAAU8AgAAAAcAAAAQgwAAAAAFPAIAAAAHQAAAEMMAAAAABTwCAAAAB4AAABEDAAA AAAU8AgAAAAfAAAARQwAAAAAFPAIAAAAIAAAAEYMAAAAABTwCAAAACEAAABTDAAAAAAU8AgA AAAiAAAAVAwAAAAAFPAIAAAAIwAAAFUMAAAAABTwCAAAACQAAABWDAAAAAAU8AgAAAAlAAAA VwwAAAAAFPAIAAAAJgAAAFgMAAAAABTwCAAAACcAAABZDAAAAAAU8AgAAAAoAAAAWgwAAAAA FPAIAAAAKQAAAFsMAAAAABTwCAAAACoAAABcDAAAAAAU8AgAAAArAAAAXQwAAAAAFPAIAAAA LAAAAF4MAAAAABTwCAAAAC0AAABfDAAAAAAU8AgAAAAuAAAAYAwAAAAAFPAIAAAALwAAAGEM AAAAABTwCAAAADAAAABiDAAAAAAU8AgAAAAxAAAAbwwAAAAAFPAIAAAAMgAAAHAMAAAAABTw CAAAADMAAABxDAAAAAAU8AgAAAA0AAAAcgwAAAAAFPAIAAAANQAAAHMMAAAAABTwCAAAADYA AAB0DAAAAAAU8AgAAAA3AAAAdQwAAAAAFPAIAAAAOAAAAHYMAAAAABTwCAAAADkAAAB3DAAA AAAU8AgAAAA6AAAAeAwAAAAAFPAIAAAAOwAAAHkMAAAAABTwCAAAADwAAAB6DAAAAAAU8AgA AAA9AAAAewwAAAAAFPAIAAAAPgAAAHwMAAAAABTwCAAAAD8AAAB9DAAAAAAU8AgAAABAAAAA fgwAAAAAFPAIAAAAQQAAAIsMAAAAABTwCAAAAEIAAACMDAAAAAAU8AgAAABDAAAAjQwAAAAA FPAIAAAARAAAAI4MAAAAABTwCAAAAEUAAACPDAAAAAAU8AgAAABGAAAAkAwAAAAAFPAIAAAA RwAAAJEMAAAAABTwCAAAAEgAAACSDAAAAAAU8AgAAABJAAAAkwwAAAAAFPAIAAAASgAAAJQM AAAAABTwCAAAAEsAAACVDAAAAAAU8AgAAABMAAAAlgwAAAAAFPAIAAAATQAAAJcMAAAAABTw CAAAAE4AAACYDAAAAAAU8AgAAABPAAAAmQwAAAAAFPAIAAAAUAAAAJoMAAAQAPAHIAAAAP// /wAAAAAAAAAAAAAAAAAAbIgA0A4uAP///wACyP4ADwDuA+QbAAACAO8DGAAAAAcAAAANAAAA AAAAAAAAAIAAAAAABwAAAA8ADASUGwAADwAC8IwbAABAAAjwCAAAAC4AAAAuEAAADwAD8CQb AAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAAAAIACvAIAAAAABAAAAUAAAAPAATw eAAAABIACvAIAAAAAhAAACACAABjAAvwJAAAAAQAAAAAAIAAhO5sAb8BAAABAP8BAAABAAED AgQAAIgDAAAAAAAAEPAIAAAAgAGwAdAUUAQPABHwEAAAAAAAwwsIAAAAAAAAAA0AbAEPAA3w DAAAAAAAng8EAAAAAAAAAA8ABPBqAAAAsgQK8AgAAAADEAAAAAoAALMAC/BCAAAAfwAAAIAA hQACAAAAhwABAAAABEEBAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI PwIAAAIAAAAQ8AgAAAAABuAHpA3ACQ8ABPBqAAAAsgQK8AgAAAAEEAAAAAoAALMAC/BCAAAA fwAAAIAAhQACAAAAhwABAAAABEEBAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgA AQICAAAIPwIAAAIAAAAQ8AgAAABwCIABAAaQDA8ABPDQAAAAogwK8AgAAAAFEAAAAAoAABMB C/BmAAAAgADk7mwBgQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwACAA8A gQH//2YAvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8A AAAQ8AgAAABfCw4EoAUADA8ADfA6AAAAAACfDwQAAAAEAAAAAACoDwYAAABJVFNQIEEAAKEP GAAAAAcAAAAAAAAIAAABAAcAAAABAAIAAQAMAA8ABPBqAAAAsgQK8AgAAAAGEAAAAAoAALMA C/BCAAAAfwAAAIAAhQACAAAAhwABAAAABEEBAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI /wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAAAADNAIUA0gEA8ABPDQAAAAogwK8AgAAAAHEAAA AAoAABMBC/BmAAAAgABE72wBgQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAA vwACAA8AgQH//2YAvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8A fwMAAA8AAAAQ8AgAAAAwDwkLmwzRDw8ADfA6AAAAAACfDwQAAAAEAAAAAACoDwYAAABJVFNQ IEIAAKEPGAAAAAcAAAAAAAAIAAABAAcAAAABAAIAAQAMAA8ABPBqAAAAsgQK8AgAAAAIEAAA AAoAALMAC/BCAAAAfwAAAIAAhQACAAAAhwABAAAABEEBAAAAgQEEAAAIgwEAAAAIvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAQ8AgAAACgCIAQABXADA8ABPDQAAAAogwK8AgA AAAJEAAAAAoAABMBC/BmAAAAgACk72wBgQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAA hwABAAAAvwACAA8AgQH//2YAvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A /wIWAB8AfwMAAA8AAAAQ8AgAAADQC7kSSxRxDA8ADfA6AAAAAACfDwQAAAAEAAAAAACoDwYA AABJVFNQIEMAAKEPGAAAAAcAAAAAAAAIAAABAAcAAAABAAIAAQAMAA8ABPCUAAAAQgEK8AgA AAAKEAAAAAoAACMBC/BsAAAAgQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAA vwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA/wEeAB4AAQICAAAIPwIAAAMA vwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AgAAAAQC/AAAAMQCw8ABPCUAAAAQgEK8AgAAAALEAAA QAoAACMBC/BsAAAAgQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwAAAA8A RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A /wIWAB8AfwMAAA8AAAAQ8AgAAADQDkAIIArwDw8ABPCUAAAAQgEK8AgAAAAMEAAAAAoAACMB C/BsAAAAgQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwAAAA8ARAEEAAAA fwEAAAEAvwEAABAAwAEBAAAIywGfbwAA/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8A fwMAAA8AAAAQ8AgAAABACxAUIBZACw8ABPCOAAAAQgEK8AgAAAANEAAAgAoAABMBC/BmAAAA gQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEA vwEAABAAwAEBAAAI/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AgA AABgCQADIATgCg8ABPCOAAAAQgEK8AgAAAAOEAAAgAoAABMBC/BmAAAAgQDAHQEAggDgjgAA gwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI /wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AgAAAAQBRALEAsABg8A BPCOAAAAQgEK8AgAAAAPEAAAgAoAABMBC/BmAAAAgQDAHQEAggDgjgAAgwDAHQEAhADgjgAA hQACAAAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEeAB4AAQICAAAI PwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AgAAABQDVAKcAtwDg8ABPCOAAAAQgEK8AgA AAAQEAAAwAoAABMBC/BmAAAAgQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAA vwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A /wIWAB8AfwMAAA8AAAAQ8AgAAADwCQASEBQQCw8ABPCOAAAAQgEK8AgAAAAREAAAgAoAABMB C/BmAAAAgQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwAAAA8ARAEEAAAA fwEAAAEAvwEAABAAwAEBAAAI/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8A AAAQ8AgAAAAgByAEEAtgCQ8ABPCOAAAAQgEK8AgAAAASEAAAwAoAABMBC/BmAAAAgQDAHQEA ggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAA wAEBAAAI/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AgAAACwBxAL QAvADA8ABPCOAAAAQgEK8AgAAAATEAAAwAoAABMBC/BmAAAAgQDAHQEAggDgjgAAgwDAHQEA hADgjgAAhQACAAAAhwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEeAB4A AQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AgAAABQBxALMBIgCg8ABPCUAAAA QgEK8AgAAAAUEAAAAAoAACMBC/BsAAAAgQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAA hwABAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA/wEeAB4AAQICAAAI PwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AgAAABAC9ACIArQDg8ABPCUAAAAQgEK8AgA AAAVEAAAAAoAACMBC/BsAAAAgQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAA vwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA/wEeAB4AAQICAAAIPwIAAAMA vwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AgAAAAQCwAD4BMQCw8ABPCUAAAAQgEK8AgAAAAWEAAA gAoAACMBC/BsAAAAgQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwAAAA8A RAEEAAAAfwEAAAEAvwEAABAAwAEBAAAIywGfbwAA/wEeAB4AAQICAAAIPwIAAAMAvwIBAA8A /wIWAB8AfwMAAA8AAAAQ8AgAAABwC1AKQBTQDg8AA/C1AQAADwAE8EYAAAABAAnwEAAAACMM AAAhDQAAOQ0AAFYOAAACAArwCAAAABcQAAABAgAAEwAL8AYAAACIAwAAAAAAABDwCAAAAIAK cAKGA7ULDwAE8HIAAACyBArwCAAAABgQAAACCgAAswAL8EIAAAB/AAAAgACFAAIAAACHAAEA AAAEQQMAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/w EAAAACMMAAAhDQAAOQ0AAFYOAAAPAATw5QAAABIACvAIAAAAGRAAAAIKAADzAAvwWgAAAIAA BPBsAYEA2hABAIIAoI4AAIMA2hABAIQAoI4AAIUAAgAAAIcAAQAAAL8AEAAfAIEBAAAACL8B EAAQAMABBQAACMsBOGMAAP8BCAAIAAECAgAACD8CAAACAAAAD/AQAAAASwwAANYNAAARDQAA Vg4AAA8ADfBTAAAAAACfDwQAAAAEAAAAAACoDwEAAABWAAChDxgAAAACAAAAAAAACAAAAQAC AAAAAQACAAEADgAAAKYPFgAAAPEeAABSAd0A3QC5AbkBlQKVAnEDcQMPAAPwtQEAAA8ABPBG AAAAAQAJ8BAAAAAjDAAAIQ0AADkNAABWDgAAAgAK8AgAAAAaEAAAAQIAABMAC/AGAAAAiAMA AAAAAAAQ8AgAAAAQDsAJ1gpFDw8ABPByAAAAsgQK8AgAAAAbEAAAAgoAALMAC/BCAAAAfwAA AIAAhQACAAAAhwABAAAABEEDAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQIC AAAIPwIAAAIAAAAP8BAAAAAjDAAAIQ0AADkNAABWDgAADwAE8OUAAAASAArwCAAAABwQAAAC CgAA8wAL8FoAAACAAGTwbAGBANoQAQCCAKCOAACDANoQAQCEAKCOAACFAAIAAACHAAEAAAC/ ABAAHwCBAQAAAAi/ARAAEADAAQUAAAjLAThjAAD/AQgACAABAgIAAAg/AgAAAgAAAA/wEAAA AEsMAADWDQAAEQ0AAFYOAAAPAA3wUwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAVgAAoQ8YAAAA AgAAAAAAAAgAAAEAAgAAAAEAAgABAA4AAACmDxYAAADxHgAAUgHdAN0AuQG5AZUClQJxA3ED DwAD8LUBAAAPAATwRgAAAAEACfAQAAAAIwwAACENAAA5DQAAVg4AAAIACvAIAAAAHRAAAAEC AAATAAvwBgAAAIgDAAAAAAAAEPAIAAAAgAqAE5YUtQsPAATwcgAAALIECvAIAAAAHhAAAAIK AACzAAvwQgAAAH8AAACAAIUAAgAAAIcAAQAAAARBAwAAAIEBBAAACIMBAAAACL8BAAAQAMAB AQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAIwwAACENAAA5DQAAVg4AAA8ABPDlAAAA EgAK8AgAAAAfEAAAAgoAAPMAC/BaAAAAgADE8GwBgQDaEAEAggCgjgAAgwDaEAEAhACgjgAA hQACAAAAhwABAAAAvwAQAB8AgQEAAAAIvwEQABAAwAEFAAAIywE4YwAA/wEIAAgAAQICAAAI PwIAAAIAAAAP8BAAAABLDAAA1g0AABENAABWDgAADwAN8FMAAAAAAJ8PBAAAAAQAAAAAAKgP AQAAAFYAAKEPGAAAAAIAAAAAAAAIAAABAAIAAAABAAIAAQAOAAAApg8WAAAA8R4AAFIB3QDd ALkBuQGVApUCcQNxAw8ABPDaAAAAogwK8AgAAAAgEAAAAAoAABMBC/BmAAAAgACE8WwBgQDA HQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwACAA8AgQH//2YAvwEMAB4AwAEB AAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AgAAAD9B6AIwgo3 CQ8ADfBEAAAAAACfDwQAAAAEAAAAAACoDxAAAABQcm92aWRlcg1OZXR3b3JrAAChDxgAAAAR AAAAAAAACAAAAQARAAAAAQACAAEADgAPAATwqAAAALIECvAIAAAAJBAAABAKAAAjAQvwbAAA AIEAQR0BAIIAoI4AAIMAQR0BAIQAoI4AAL8AAAAPAARBBAAAAAsBAwAAAD8BAAABAIEBBAAA CIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAP AAAAEPAIAAAAYAZ/CqALKQgPABHwDAAAAAAAwQsEAAAAAwAAAA8ABPCoAAAAsgQK8AgAAAAl EAAAEAoAACMBC/BsAAAAgQBBHQEAggCgjgAAgwBBHQEAhACgjgAAvwAAAA8ABEEEAAAACwEE AAAAPwEAAAEAgQEEAAAIgwEAAAAIvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIB AA8A/wIWAB8AfwMAAA8AAAAQ8AgAAABXCF8DgAQgCg8AEfAMAAAAAADBCwQAAAAEAAAADwAE 8KgAAACyBArwCAAAACYQAAAQCgAAIwEL8GwAAACBAEEdAQCCAKCOAACDAEEdAQCEAKCOAAC/ AAAADwAEQQQAAAALAQUAAAA/AQAAAQCBAQQAAAiDAQAAAAi/AQwAHgDAAQEAAAj/AQYADgAB AgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAALcL4AoBDIANDwAR8AwAAAAA AMELBAAAAAUAAAAPAATwqAAAALIECvAIAAAAJxAAABAKAAAjAQvwbAAAAIEAQR0BAIIAoI4A AIMAQR0BAIQAoI4AAL8AAAAPAARBBAAAAAsBBgAAAD8BAAABAIEBBAAACIMBAAAACL8BDAAe AMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAMAnP EfAS+QoPABHwDAAAAAAAwQsEAAAABgAAAA8AA/CnAQAADwAE8EYAAAABAAnwEAAAAOAQAADw CQAAoBQAAPcLAAACAArwCAAAACgQAAABAgAAEwAL8AYAAACIAwAAAAAAABDwCAAAAPAD8Anw DJAFDwAE8HIAAACyBArwCAAAACkQAAACCgAAswAL8EIAAAB/AAAAgACFAAIAAACHAAEAAAAE QQIAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAA AOAQAADwCQAAoBQAANULAAAPAATw1wAAAKIMCvAIAAAAKhAAAAIKAADjAAvwVAAAAH8AgACA AIAApPJsAb8AAgACAIEBAAAACL8BEAAQAMABBQAACMsBakoAANIBAAAAANMBAAAAANQBAAAA ANUBAAAAAP8BCAAIAAECAQAACD8CAAACAAAAD/AQAAAA+BAAALAKAABAFAAA9wsAAA8ADfBL AAAAAACfDwQAAAAEAAAAAACoDxUAAABDYXJyaWVyIFBvbGljeSBTZXJ2ZXIAAKEPGgAAABYA AAAAAAAoAAABADIAFgAAAAEAAgABAAoADwAD8LUBAAAPAATwRgAAAAEACfAQAAAAIwwAACEN AAA5DQAAVg4AAAIACvAIAAAAIRAAAAECAAATAAvwBgAAAIgDAAAAAAAAEPAIAAAAEAh6C5AM RQkPAATwcgAAALIECvAIAAAAIhAAAAIKAACzAAvwQgAAAH8AAACAAIUAAgAAAIcAAQAAAARB AwAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAA IwwAACENAAA5DQAAVg4AAA8ABPDlAAAAEgAK8AgAAAAjEAAAAgoAAPMAC/BaAAAAgADk8WwB gQDaEAEAggCgjgAAgwDaEAEAhACgjgAAhQACAAAAhwABAAAAvwAQAB8AgQEAAAAIvwEQABAA wAEFAAAIywE4YwAA/wEIAAgAAQICAAAIPwIAAAIAAAAP8BAAAABLDAAA1g0AABENAABWDgAA DwAN8FMAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAFYAAKEPGAAAAAIAAAAAAAAIAAABAAIAAAAB AAIAAQAOAAAApg8WAAAA8R4AAFIB3QDdALkBuQGVApUCcQNxAw8ABPBYAAAAQgEK8AgAAAAr EAAAwAoAAIMAC/AwAAAAhQACAAAAhwABAAAARAEEAAAAfwEAAAEAvwEAABAAwAEBAAAI/wEY ABgAAQICAAAIAAAQ8AgAAAAQCHAL0AtwCA8AA/C1AQAADwAE8EYAAAABAAnwEAAAACMMAAAh DQAAOQ0AAFYOAAACAArwCAAAACwQAAABAgAAEwAL8AYAAACIAwAAAAAAABDwCAAAAHAI0Avm DKUJDwAE8HIAAACyBArwCAAAAC0QAAACCgAAswAL8EIAAAB/AAAAgACFAAIAAACHAAEAAAAE QQMAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAA ACMMAAAhDQAAOQ0AAFYOAAAPAATw5QAAABIACvAIAAAALhAAAAIKAADzAAvwWgAAAIAAdEgD CIEA2hABAIIAoI4AAIMA2hABAIQAoI4AAIUAAgAAAIcAAQAAAL8AEAAfAIEBAAAACL8BEAAQ AMABBQAACMsBOGMAAP8BCAAIAAECAgAACD8CAAACAAAAD/AQAAAASwwAANYNAAARDQAAVg4A AA8ADfBTAAAAAACfDwQAAAAEAAAAAACoDwEAAABWAAChDxgAAAACAAAAAAAACAAAAQACAAAA AQACAAEADgAAAKYPFgAAAPEeAABSAd0A3QC5AbkBlQKVAnEDcQMPAATwSAAAABIACvAIAAAA ARAAAAAMAACDAAvwMAAAAIEBAAAACIMBBQAACJMBjp+LAJQB3r1oAL8BHgAfAP8BAAAIAAQD CQAAAD8DAQABABAA8AcgAAAA////AAAAAAAAAAAAAAAAAABsiADQDi4A////AALI/gAPAO4D AGgAAAIA7wMYAAAABwAAAA0AAAAAAAAAAAAAgAAAAAAHAAAADwAMBLBnAAAPAALwqGcAAFAA CPAIAAAAiwAAAIsUAAAPAAPwOGQAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAA AgAK8AgAAAAAFAAABQAAAA8ABPBqAAAAsgQK8AgAAAACFAAAAAoAALMAC/BCAAAAfwAAAIAA hQACAAAAhwABAAAABEEBAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAI PwIAAAIAAAAQ8AgAAADABmEEAA/QDg8ABPD5AAAAogwK8AgAAAADFAAAAAoAABMBC/BmAAAA gABk82wBgQDAHQEAggDgjgAAgwDAHQEAhADgjgAAhQACAAAAhwABAAAAvwACAA8AgQH//2YA vwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AgA AADwDCEJxAxSDg8ADfBjAAAAAACfDwQAAAAEAAAAAACoDxUAAABWb0lQIFByb3ZpZGVyDU5l dHdvcmsAAKEPGAAAABYAAAAAAAAIAAABABYAAAABAAIAAQAQAAAAqg8SAAAABAAAAAEAAAAD ABIAAAAAAAAADwAE8JQAAABCAQrwCAAAAAQUAAAACgAAIwEL8GwAAACBAMAdAQCCAOCOAACD AMAdAQCEAOCOAACFAAIAAACHAAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjL AZ9vAAD/AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAEAIEQNx BhALDwAE8JQAAABCAQrwCAAAAAUUAAAACgAAIwEL8GwAAACBAMAdAQCCAOCOAACDAMAdAQCE AOCOAACFAAIAAACHAAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAAD/ AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAABALsQJBBhALDwAE 8JQAAABCAQrwCAAAAAYUAAAACgAAIwEL8GwAAACBAMAdAQCCAOCOAACDAMAdAQCEAOCOAACF AAIAAACHAAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAAD/AR4AHgAB AgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAEALsQJxBkALDwAE8JQAAABC AQrwCAAAAAcUAAAACgAAIwEL8GwAAACBAMAdAQCCAOCOAACDAMAdAQCEAOCOAACFAAIAAACH AAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAAD/AR4AHgABAgIAAAg/ AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAHALsQJxBnALDwAE8JQAAABCAQrwCAAA AAgUAACACgAAIwEL8GwAAACBAMAdAQCCAOCOAACDAMAdAQCEAOCOAACFAAIAAACHAAEAAAC/ AAAADwBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAAD/AR4AHgABAgIAAAg/AgAAAwC/ AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAHALsQJxBoANDwAE8JQAAABCAQrwCAAAAAkUAACA CgAAIwEL8GwAAACBAMAdAQCCAOCOAACDAMAdAQCEAOCOAACFAAIAAACHAAEAAAC/AAAADwBE AQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAAD/AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/ AhYAHwB/AwAADwAAABDwCAAAAKAL4QJxBrANDwAD8FQWAAAPAATwRgAAAAEACfAQAAAAAQEA AEUHAACQAwAA0AgAAAIACvAIAAAAChQAAAECAAATAAvwBgAAAIgDAAAAAAAAEPAIAAAARQcB AZAD0AgPAAPwFhUAAA8ABPBOAAAAAQAJ8BAAAAAPBgAAwAIAAJ4IAABLBAAAAgAK8AgAAAAL FAAAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAAABAQAARQcAAJADAADQCAAADwAE8GAAAAAy AArwCAAAAAwUAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/ AQAACAABAgIAAAg/AgAAAgAAAA/wEAAAAO4GAADAAgAACwgAAGIDAAAPAATwYAAAADIACvAI AAAADRQAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAI AAECAgAACD8CAAACAAAAD/AQAAAAUgYAAOoCAAAsBwAAjAMAAA8ABPBgAAAAMgAK8AgAAAAO FAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQIC AAAIPwIAAAIAAAAP8BAAAAAPBgAATAMAAKIGAADQAwAADwAE8GAAAAAyAArwCAAAAA8UAAAC CgAAgwAL8DAAAACFAAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/ AgAAAgAAAA/wEAAAADsGAACGAwAAGQcAABUEAAAPAATwYAAAADIACvAIAAAAEBQAAAIKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAAC AAAAD/AQAAAA2AYAAJ0DAAAiCAAARwQAAA8ABPBgAAAAMgAK8AgAAAARFAAAAgoAAIMAC/Aw AAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP 8BAAAACqBwAA7wIAAH4IAABuAwAADwAE8GAAAAAyAArwCAAAABIUAAACCgAAgwAL8DAAAACF AAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAA AMoHAABBAwAAnAgAAMADAAAPAATwYAAAADIACvAIAAAAExQAAAIKAACDAAvwMAAAAIUAAgAA AIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAtwcA AFsDAACICAAALAQAAA8ABPBgAAAAMgAK8AgAAAAUFAAAAgoAAIMAC/AwAAAAhQACAAAAhwAB AAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAACGBgAAHQMA AC4IAADtAwAADwAE8PYAAAAyAQrwCAAAABUUAAACCgAA8wAL8MYAAACFAAIAAACHAAEAAABC AbSdAABFwU4AAABHAewyxwBIAeedUQFJAa9PAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjX AQAAAAD/AQAACAABAgIAAAg/AgAAAgAJAAwACABP+///AAAAAA+kAADAqAAAAAAAAKE4AAC0 nQAAPzQAAE/7//8AAAAAD6QAAMCoAAAAAAAAoTgAALSdAAA/NAAAr08AAGBUAAADAAQACAAA AAAAoTgAALSdAAA/NAAAr08AAGBUAAAAAA/wEAAAAPcGAADBAgAABAgAABMDAAAPAATwGgEA ADIBCvAIAAAAFhQAAAIKAABTAQvw6gAAAIUAAgAAAIcAAQAAAEIBtJ0AAEXBTgAAAEcB7DLH AEgB551RAUkBr08AAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAA ANMBAAAAANQBAAAAANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAE/7//8A AAAAD6QAAMCoAAAAAAAAoTgAALSdAAA/NAAAT/v//wAAAAAPpAAAwKgAAAAAAAChOAAAtJ0A AD80AACvTwAAYFQAAAMABAAIAAAAAAChOAAAtJ0AAD80AACvTwAAYFQAAAAAD/AQAAAA9wYA AMECAAAECAAAEwMAAA8ABPDYAAAAMgEK8AgAAAAXFAAAAgoAAAMBC/CoAAAAhQACAAAAhwAB AAAAQgFOgAAAQwG7ZQAARcEkAAAARwEjIagASAHMXy0BSQFgVAAAUcEeAAAAgQF4jpYAvwEQ ABAAwAEBAAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAJAPD/AAAAAMCowKjOAbtlToBW DAAAAADAqMCozgG7ZU6AVgxgVGBUAwAEAAgAzgEAALtlAABOgAAAVgwAAGBUAABgVAAAAAAP 8BAAAABTBgAA6gIAAPoGAABNAwAADwAE8PwAAAAyAQrwCAAAABgUAAACCgAAYwEL8MwAAACF AAIAAACHAAEAAABCAU6AAABDAbtlAABFwSQAAABHASMhqABIAcxfLQFJAWBUAABRwR4AAACB AQQAAAiDAQAAAAi/AQAAEADAATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADX AQAAAAD/AQgACAABAgIAAAg/AgAAAgAJAAkA8P8AAAAAwKjAqM4Bu2VOgFYMAAAAAMCowKjO AbtlToBWDGBUYFQDAAQACADOAQAAu2UAAE6AAABWDAAAYFQAAGBUAAAAAA/wEAAAAFMGAADq AgAA+gYAAE0DAAAPAATwAgEAADIBCvAIAAAAGRQAAAIKAAATAQvw0gAAAIUAAgAAAIcAAQAA AEIBe30AAEMB7lgAAEXBTgAAAEcBcdg8AEgBFBi3AEkBYFQAAEoBjgQAAFHBHgAAAIEBeI6W AL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAACAAkADAAIAAAAAAAusP//wKgA AO5YAAB7fQAAPU4AAB8AAAAAAAAAAAAAAC6w///AqAAA7lgAAHt9AAA9TgAAHwAAAAAAAABg VAAAjgQAAAMABAAIAHt9AAA9TgAAHwAAAAAAAABgVAAAjgQAAAAAD/AQAAAAOgYAAMsDAADk BgAAGQQAAA8ABPAmAQAAMgEK8AgAAAAaFAAAAgoAAHMBC/D2AAAAhQACAAAAhwABAAAAQgF7 fQAAQwHuWAAARcFOAAAARwFx2DwASAEUGLcASQFgVAAASgGOBAAAUcEeAAAAgQEEAAAIgwEA AAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA1wEAAAAA/wEI AAgAAQICAAAIPwIAAAIACQAMAAgAAAAAAC6w///AqAAA7lgAAHt9AAA9TgAAHwAAAAAAAAAA AAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAGBUAACOBAAAAwAEAAgAe30AAD1OAAAf AAAAAAAAAGBUAACOBAAAAAAP8BAAAAA6BgAAywMAAOQGAAAZBAAADwAE8PwAAAAyAQrwCAAA ABsUAAACCgAAAwEL8MwAAACFAAIAAACHAAEAAABCAadlAABDARV+AABFwU4AAABHATcvAgFI AQmgHQBJAUcRAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAABAgIAAAg/ AgAAAgAJAAwACADnvP//AAAAAKdlAADAqAAAAAAAAMoBAACfWgAAFX4AAOe8//8AAAAAp2UA AMCoAAAAAAAAygEAAJ9aAAAVfgAARxEAAGBUAAADAAQACAAAAAAAygEAAJ9aAAAVfgAARxEA AGBUAAAAAA/wEAAAAAEIAADwAgAAgQgAAE8DAAAPAATwIAEAADIBCvAIAAAAHBQAAAIKAABj AQvw8AAAAIUAAgAAAIcAAQAAAEIBp2UAAEMBFX4AAEXBTgAAAEcBNy8CAUgBCaAdAEkBRxEA AFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAA ANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAOe8//8AAAAAp2UAAMCoAAAA AAAAygEAAJ9aAAAVfgAA57z//wAAAACnZQAAwKgAAAAAAADKAQAAn1oAABV+AABHEQAAYFQA AAMABAAIAAAAAADKAQAAn1oAABV+AABHEQAAYFQAAAAAD/AQAAAAAQgAAPACAACBCAAATwMA AA8ABPD2AAAAMgEK8AgAAAAdFAAAAgoAAPMAC/DGAAAAhQACAAAAhwABAAAAQwEQcwAARcFO AAAARwEAhTQBSAGpiiMASgEEQgAAUcEeAAAAgQF4jpYAvwEQABAAwAEBAAAI1wEAAAAA/wEA AAgAAQICAAAIPwIAAAIACQAMAAgAoKv//6Tt//9gVAAAZJYAAIw0AAAAAAAAqEQAABBzAACg q///pO3//2BUAABklgAAjDQAAAAAAACoRAAAEHMAAAAAAAAEQgAAAwAEAAgAjDQAAAAAAACo RAAAEHMAAAAAAAAEQgAAAAAP8BAAAAAkCAAATgMAAJ4IAACsAwAADwAE8BoBAAAyAQrwCAAA AB4UAAACCgAAUwEL8OoAAACFAAIAAACHAAEAAABDARBzAABFwU4AAABHAQCFNAFIAamKIwBK AQRCAABRwR4AAACBAQQAAAiDAQAAAAi/AQAAEADAATZHSQDLAZwxAADSAQAAAADTAQAAAADU AQAAAADVAQAAAADXAQAAAAD/AQgACAABAgIAAAg/AgAAAgAJAAwACACgq///pO3//2BUAABk lgAAjDQAAAAAAACoRAAAEHMAAKCr//+k7f//YFQAAGSWAACMNAAAAAAAAKhEAAAQcwAAAAAA AARCAAADAAQACACMNAAAAAAAAKhEAAAQcwAAAAAAAARCAAAAAA/wEAAAACQIAABOAwAAnggA AKwDAAAPAATwAgEAADIBCvAIAAAAHxQAAAIKAAATAQvw0gAAAIUAAgAAAIcAAQAAAEIB6m8A AEMBcm0AAEXBTgAAAEcBULdWAUgB7QxtAEkBihsAAEoBEhkAAFHBHgAAAIEBeI6WAL8BEAAQ AMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAACAAkADAAIACrH//+yxP//6m8AAHJtAAAb bAAAAAAAAAAAAADTaAAAKsf//7LE///qbwAAcm0AABtsAAAAAAAAAAAAANNoAACKGwAAEhkA AAMABAAIABtsAAAAAAAAAAAAANNoAACKGwAAEhkAAAAAD/AQAAAA/QcAAKkDAACMCAAAMQQA AA8ABPAmAQAAMgEK8AgAAAAgFAAAAgoAAHMBC/D2AAAAhQACAAAAhwABAAAAQgHqbwAAQwFy bQAARcFOAAAARwFQt1YBSAHtDG0ASQGKGwAASgESGQAAUcEeAAAAgQEEAAAIgwEAAAAIvwEA ABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA1wEAAAAA/wEIAAgAAQIC AAAIPwIAAAIACQAMAAgAKsf//7LE///qbwAAcm0AABtsAAAAAAAAAAAAANNoAAAqx///ssT/ /+pvAABybQAAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAwAEAAgAG2wAAAAAAAAAAAAA02gA AIobAAASGQAAAAAP8BAAAAD9BwAAqQMAAIwIAAAxBAAADwAE8PwAAAAyAQrwCAAAACEUAAAC CgAAAwEL8MwAAACFAAIAAACHAAEAAABDAfKgAABFwU4AAABHAUOOcgBIAe9VCgFJAWBUAABK ATRUAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAABAgIAAAg/AgAAAgAJ AAwACAAAAAAA1P///8CoAACUqAAAUDEAAPKgAAD8TgAAAAAAAAAAAADU////wKgAAJSoAABQ MQAA8qAAAPxOAAAAAAAAYFQAADRUAAADAAQACABQMQAA8qAAAPxOAAAAAAAAYFQAADRUAAAA AA/wEAAAABAGAABNAwAAXgYAAM4DAAAPAATwIAEAADIBCvAIAAAAIhQAAAIKAABjAQvw8AAA AIUAAgAAAIcAAQAAAEMB8qAAAEXBTgAAAEcBQ45yAEgB71UKAUkBYFQAAEoBNFQAAFHBHgAA AIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAAANUBAAAA ANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAAAAAADU////wKgAAJSoAABQMQAA8qAA APxOAAAAAAAAAAAAANT////AqAAAlKgAAFAxAADyoAAA/E4AAAAAAABgVAAANFQAAAMABAAI AFAxAADyoAAA/E4AAAAAAABgVAAANFQAAAAAD/AQAAAAEAYAAE0DAABeBgAAzgMAAA8ABPD8 AAAAMgEK8AgAAAAjFAAAAgoAAAMBC/DMAAAAhQACAAAAhwABAAAAQgFWmAAARcFOAAAARwEl hiIASAGm+6gASQHSUgAASgEAAAAAUcEeAAAAgQF4jpYAvwEQABAAwAEBAAAI1wEAAAAA/wEA AAgAAQICAAAIPwIAAAIACQAMAAgAcv7//6Cr//8ypwAAYFQAAFaYAADSLwAAAAAAACAQAABy /v//oKv//zKnAABgVAAAVpgAANIvAAAAAAAAIBAAANJSAAAAAAAAAwAEAAgAVpgAANIvAAAA AAAAIBAAANJSAAAAAAAAAAAP8BAAAADeBgAA/AMAAAIIAABLBAAADwAE8CABAAAyAQrwCAAA ACQUAAACCgAAYwEL8PAAAACFAAIAAACHAAEAAABCAVaYAABFwU4AAABHASWGIgBIAab7qABJ AdJSAABKAQAAAABRwR4AAACBAQQAAAiDAQAAAAi/AQAAEADAATZHSQDLAZwxAADSAQAAAADT AQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAABAgIAAAg/AgAAAgAJAAwACABy/v//oKv/ /zKnAABgVAAAVpgAANIvAAAAAAAAIBAAAHL+//+gq///MqcAAGBUAABWmAAA0i8AAAAAAAAg EAAA0lIAAAAAAAADAAQACABWmAAA0i8AAAAAAAAgEAAA0lIAAAAAAAAAAA/wEAAAAN4GAAD8 AwAAAggAAEsEAAAPAATw4AAAAKIMCvAIAAAAJRQAAAIKAAATAQvwZgAAAIAAJPRsAYEAwB0B AIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAgAPAIEB//9mAL8BDAAeAMABAQAA CP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAfAEAAIcHAABx AwAAmwgAAA8ADfBCAAAAAACfDwQAAAAEAAAAAACoDw4AAABQU1RODUNhcnJpZXIgQQAAoQ8Y AAAADwAAAAAAAAgAAAEADwAAAAEAAgABAAwADwAD8FQWAAAPAATwRgAAAAEACfAQAAAAAQEA AHUKAACQAwAAAAwAAAIACvAIAAAAJhQAAAECAAATAAvwBgAAAIgDAAAAAAAAEPAIAAAAdQoB AZADAAwPAAPwFhUAAA8ABPBOAAAAAQAJ8BAAAAAPBgAAwAIAAJ4IAABLBAAAAgAK8AgAAAAn FAAAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAAABAQAAdQoAAJADAAAADAAADwAE8GAAAAAy AArwCAAAACgUAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/ AQAACAABAgIAAAg/AgAAAgAAAA/wEAAAAO4GAADAAgAACwgAAGIDAAAPAATwYAAAADIACvAI AAAAKRQAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAI AAECAgAACD8CAAACAAAAD/AQAAAAUgYAAOoCAAAsBwAAjAMAAA8ABPBgAAAAMgAK8AgAAAAq FAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQIC AAAIPwIAAAIAAAAP8BAAAAAPBgAATAMAAKIGAADQAwAADwAE8GAAAAAyAArwCAAAACsUAAAC CgAAgwAL8DAAAACFAAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/ AgAAAgAAAA/wEAAAADsGAACGAwAAGQcAABUEAAAPAATwYAAAADIACvAIAAAALBQAAAIKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAAC AAAAD/AQAAAA2AYAAJ0DAAAiCAAARwQAAA8ABPBgAAAAMgAK8AgAAAAtFAAAAgoAAIMAC/Aw AAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP 8BAAAACqBwAA7wIAAH4IAABuAwAADwAE8GAAAAAyAArwCAAAAC4UAAACCgAAgwAL8DAAAACF AAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAA AMoHAABBAwAAnAgAAMADAAAPAATwYAAAADIACvAIAAAALxQAAAIKAACDAAvwMAAAAIUAAgAA AIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAtwcA AFsDAACICAAALAQAAA8ABPBgAAAAMgAK8AgAAAAwFAAAAgoAAIMAC/AwAAAAhQACAAAAhwAB AAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAACGBgAAHQMA AC4IAADtAwAADwAE8PYAAAAyAQrwCAAAADEUAAACCgAA8wAL8MYAAACFAAIAAACHAAEAAABC AbSdAABFwU4AAABHAewyxwBIAeedUQFJAa9PAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjX AQAAAAD/AQAACAABAgIAAAg/AgAAAgAJAAwACABP+///AAAAAA+kAADAqAAAAAAAAKE4AAC0 nQAAPzQAAE/7//8AAAAAD6QAAMCoAAAAAAAAoTgAALSdAAA/NAAAr08AAGBUAAADAAQACAAA AAAAoTgAALSdAAA/NAAAr08AAGBUAAAAAA/wEAAAAPcGAADBAgAABAgAABMDAAAPAATwGgEA ADIBCvAIAAAAMhQAAAIKAABTAQvw6gAAAIUAAgAAAIcAAQAAAEIBtJ0AAEXBTgAAAEcB7DLH AEgB551RAUkBr08AAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAA ANMBAAAAANQBAAAAANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAE/7//8A AAAAD6QAAMCoAAAAAAAAoTgAALSdAAA/NAAAT/v//wAAAAAPpAAAwKgAAAAAAAChOAAAtJ0A AD80AACvTwAAYFQAAAMABAAIAAAAAAChOAAAtJ0AAD80AACvTwAAYFQAAAAAD/AQAAAA9wYA AMECAAAECAAAEwMAAA8ABPDYAAAAMgEK8AgAAAAzFAAAAgoAAAMBC/CoAAAAhQACAAAAhwAB AAAAQgFOgAAAQwG7ZQAARcEkAAAARwEjIagASAHMXy0BSQFgVAAAUcEeAAAAgQF4jpYAvwEQ ABAAwAEBAAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAJAPD/AAAAAMCowKjOAbtlToBW DAAAAADAqMCozgG7ZU6AVgxgVGBUAwAEAAgAzgEAALtlAABOgAAAVgwAAGBUAABgVAAAAAAP 8BAAAABTBgAA6gIAAPoGAABNAwAADwAE8PwAAAAyAQrwCAAAADQUAAACCgAAYwEL8MwAAACF AAIAAACHAAEAAABCAU6AAABDAbtlAABFwSQAAABHASMhqABIAcxfLQFJAWBUAABRwR4AAACB AQQAAAiDAQAAAAi/AQAAEADAATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADX AQAAAAD/AQgACAABAgIAAAg/AgAAAgAJAAkA8P8AAAAAwKjAqM4Bu2VOgFYMAAAAAMCowKjO AbtlToBWDGBUYFQDAAQACADOAQAAu2UAAE6AAABWDAAAYFQAAGBUAAAAAA/wEAAAAFMGAADq AgAA+gYAAE0DAAAPAATwAgEAADIBCvAIAAAANRQAAAIKAAATAQvw0gAAAIUAAgAAAIcAAQAA AEIBe30AAEMB7lgAAEXBTgAAAEcBcdg8AEgBFBi3AEkBYFQAAEoBjgQAAFHBHgAAAIEBeI6W AL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAACAAkADAAIAAAAAAAusP//wKgA AO5YAAB7fQAAPU4AAB8AAAAAAAAAAAAAAC6w///AqAAA7lgAAHt9AAA9TgAAHwAAAAAAAABg VAAAjgQAAAMABAAIAHt9AAA9TgAAHwAAAAAAAABgVAAAjgQAAAAAD/AQAAAAOgYAAMsDAADk BgAAGQQAAA8ABPAmAQAAMgEK8AgAAAA2FAAAAgoAAHMBC/D2AAAAhQACAAAAhwABAAAAQgF7 fQAAQwHuWAAARcFOAAAARwFx2DwASAEUGLcASQFgVAAASgGOBAAAUcEeAAAAgQEEAAAIgwEA AAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA1wEAAAAA/wEI AAgAAQICAAAIPwIAAAIACQAMAAgAAAAAAC6w///AqAAA7lgAAHt9AAA9TgAAHwAAAAAAAAAA AAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAGBUAACOBAAAAwAEAAgAe30AAD1OAAAf AAAAAAAAAGBUAACOBAAAAAAP8BAAAAA6BgAAywMAAOQGAAAZBAAADwAE8PwAAAAyAQrwCAAA ADcUAAACCgAAAwEL8MwAAACFAAIAAACHAAEAAABCAadlAABDARV+AABFwU4AAABHATcvAgFI AQmgHQBJAUcRAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAABAgIAAAg/ AgAAAgAJAAwACADnvP//AAAAAKdlAADAqAAAAAAAAMoBAACfWgAAFX4AAOe8//8AAAAAp2UA AMCoAAAAAAAAygEAAJ9aAAAVfgAARxEAAGBUAAADAAQACAAAAAAAygEAAJ9aAAAVfgAARxEA AGBUAAAAAA/wEAAAAAEIAADwAgAAgQgAAE8DAAAPAATwIAEAADIBCvAIAAAAOBQAAAIKAABj AQvw8AAAAIUAAgAAAIcAAQAAAEIBp2UAAEMBFX4AAEXBTgAAAEcBNy8CAUgBCaAdAEkBRxEA AFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAA ANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAOe8//8AAAAAp2UAAMCoAAAA AAAAygEAAJ9aAAAVfgAA57z//wAAAACnZQAAwKgAAAAAAADKAQAAn1oAABV+AABHEQAAYFQA AAMABAAIAAAAAADKAQAAn1oAABV+AABHEQAAYFQAAAAAD/AQAAAAAQgAAPACAACBCAAATwMA AA8ABPD2AAAAMgEK8AgAAAA5FAAAAgoAAPMAC/DGAAAAhQACAAAAhwABAAAAQwEQcwAARcFO AAAARwEAhTQBSAGpiiMASgEEQgAAUcEeAAAAgQF4jpYAvwEQABAAwAEBAAAI1wEAAAAA/wEA AAgAAQICAAAIPwIAAAIACQAMAAgAoKv//6Tt//9gVAAAZJYAAIw0AAAAAAAAqEQAABBzAACg q///pO3//2BUAABklgAAjDQAAAAAAACoRAAAEHMAAAAAAAAEQgAAAwAEAAgAjDQAAAAAAACo RAAAEHMAAAAAAAAEQgAAAAAP8BAAAAAkCAAATgMAAJ4IAACsAwAADwAE8BoBAAAyAQrwCAAA ADoUAAACCgAAUwEL8OoAAACFAAIAAACHAAEAAABDARBzAABFwU4AAABHAQCFNAFIAamKIwBK AQRCAABRwR4AAACBAQQAAAiDAQAAAAi/AQAAEADAATZHSQDLAZwxAADSAQAAAADTAQAAAADU AQAAAADVAQAAAADXAQAAAAD/AQgACAABAgIAAAg/AgAAAgAJAAwACACgq///pO3//2BUAABk lgAAjDQAAAAAAACoRAAAEHMAAKCr//+k7f//YFQAAGSWAACMNAAAAAAAAKhEAAAQcwAAAAAA AARCAAADAAQACACMNAAAAAAAAKhEAAAQcwAAAAAAAARCAAAAAA/wEAAAACQIAABOAwAAnggA AKwDAAAPAATwAgEAADIBCvAIAAAAOxQAAAIKAAATAQvw0gAAAIUAAgAAAIcAAQAAAEIB6m8A AEMBcm0AAEXBTgAAAEcBULdWAUgB7QxtAEkBihsAAEoBEhkAAFHBHgAAAIEBeI6WAL8BEAAQ AMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAACAAkADAAIACrH//+yxP//6m8AAHJtAAAb bAAAAAAAAAAAAADTaAAAKsf//7LE///qbwAAcm0AABtsAAAAAAAAAAAAANNoAACKGwAAEhkA AAMABAAIABtsAAAAAAAAAAAAANNoAACKGwAAEhkAAAAAD/AQAAAA/QcAAKkDAACMCAAAMQQA AA8ABPAmAQAAMgEK8AgAAAA8FAAAAgoAAHMBC/D2AAAAhQACAAAAhwABAAAAQgHqbwAAQwFy bQAARcFOAAAARwFQt1YBSAHtDG0ASQGKGwAASgESGQAAUcEeAAAAgQEEAAAIgwEAAAAIvwEA ABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA1wEAAAAA/wEIAAgAAQIC AAAIPwIAAAIACQAMAAgAKsf//7LE///qbwAAcm0AABtsAAAAAAAAAAAAANNoAAAqx///ssT/ /+pvAABybQAAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAwAEAAgAG2wAAAAAAAAAAAAA02gA AIobAAASGQAAAAAP8BAAAAD9BwAAqQMAAIwIAAAxBAAADwAE8PwAAAAyAQrwCAAAAD0UAAAC CgAAAwEL8MwAAACFAAIAAACHAAEAAABDAfKgAABFwU4AAABHAUOOcgBIAe9VCgFJAWBUAABK ATRUAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAABAgIAAAg/AgAAAgAJ AAwACAAAAAAA1P///8CoAACUqAAAUDEAAPKgAAD8TgAAAAAAAAAAAADU////wKgAAJSoAABQ MQAA8qAAAPxOAAAAAAAAYFQAADRUAAADAAQACABQMQAA8qAAAPxOAAAAAAAAYFQAADRUAAAA AA/wEAAAABAGAABNAwAAXgYAAM4DAAAPAATwIAEAADIBCvAIAAAAPhQAAAIKAABjAQvw8AAA AIUAAgAAAIcAAQAAAEMB8qAAAEXBTgAAAEcBQ45yAEgB71UKAUkBYFQAAEoBNFQAAFHBHgAA AIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAAANUBAAAA ANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAAAAAADU////wKgAAJSoAABQMQAA8qAA APxOAAAAAAAAAAAAANT////AqAAAlKgAAFAxAADyoAAA/E4AAAAAAABgVAAANFQAAAMABAAI AFAxAADyoAAA/E4AAAAAAABgVAAANFQAAAAAD/AQAAAAEAYAAE0DAABeBgAAzgMAAA8ABPD8 AAAAMgEK8AgAAAA/FAAAAgoAAAMBC/DMAAAAhQACAAAAhwABAAAAQgFWmAAARcFOAAAARwEl hiIASAGm+6gASQHSUgAASgEAAAAAUcEeAAAAgQF4jpYAvwEQABAAwAEBAAAI1wEAAAAA/wEA AAgAAQICAAAIPwIAAAIACQAMAAgAcv7//6Cr//8ypwAAYFQAAFaYAADSLwAAAAAAACAQAABy /v//oKv//zKnAABgVAAAVpgAANIvAAAAAAAAIBAAANJSAAAAAAAAAwAEAAgAVpgAANIvAAAA AAAAIBAAANJSAAAAAAAAAAAP8BAAAADeBgAA/AMAAAIIAABLBAAADwAE8CABAAAyAQrwCAAA AEAUAAACCgAAYwEL8PAAAACFAAIAAACHAAEAAABCAVaYAABFwU4AAABHASWGIgBIAab7qABJ AdJSAABKAQAAAABRwR4AAACBAQQAAAiDAQAAAAi/AQAAEADAATZHSQDLAZwxAADSAQAAAADT AQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAABAgIAAAg/AgAAAgAJAAwACABy/v//oKv/ /zKnAABgVAAAVpgAANIvAAAAAAAAIBAAAHL+//+gq///MqcAAGBUAABWmAAA0i8AAAAAAAAg EAAA0lIAAAAAAAADAAQACABWmAAA0i8AAAAAAAAgEAAA0lIAAAAAAAAAAA/wEAAAAN4GAAD8 AwAAAggAAEsEAAAPAATw4AAAAKIMCvAIAAAAQRQAAAIKAAATAQvwZgAAAIAA5PRsAYEAwB0B AIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAgAPAIEB//9mAL8BDAAeAMABAQAA CP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAYQEAALAKAABW AwAAxAsAAA8ADfBCAAAAAACfDwQAAAAEAAAAAACoDw4AAABQU1RODUNhcnJpZXIgQgAAoQ8Y AAAADwAAAAAAAAgAAAEADwAAAAEAAgABAAwADwAD8FQWAAAPAATwRgAAAAEACfAQAAAAEgEA AAkNAAChAwAAlA4AAAIACvAIAAAAQhQAAAECAAATAAvwBgAAAIgDAAAAAAAAEPAIAAAACQ0S AaEDlA4PAAPwFhUAAA8ABPBOAAAAAQAJ8BAAAAAPBgAAwAIAAJ4IAABLBAAAAgAK8AgAAABD FAAAAwIAABMAC/AGAAAAiAMAAAAAAAAP8BAAAAASAQAACQ0AAKEDAACUDgAADwAE8GAAAAAy AArwCAAAAEQUAAACCgAAgwAL8DAAAACFAAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/ AQAACAABAgIAAAg/AgAAAgAAAA/wEAAAAO4GAADAAgAACwgAAGIDAAAPAATwYAAAADIACvAI AAAARRQAAAIKAACDAAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAI AAECAgAACD8CAAACAAAAD/AQAAAAUgYAAOoCAAAsBwAAjAMAAA8ABPBgAAAAMgAK8AgAAABG FAAAAgoAAIMAC/AwAAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQIC AAAIPwIAAAIAAAAP8BAAAAAPBgAATAMAAKIGAADQAwAADwAE8GAAAAAyAArwCAAAAEcUAAAC CgAAgwAL8DAAAACFAAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/ AgAAAgAAAA/wEAAAADsGAACGAwAAGQcAABUEAAAPAATwYAAAADIACvAIAAAASBQAAAIKAACD AAvwMAAAAIUAAgAAAIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAAC AAAAD/AQAAAA2AYAAJ0DAAAiCAAARwQAAA8ABPBgAAAAMgAK8AgAAABJFAAAAgoAAIMAC/Aw AAAAhQACAAAAhwABAAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP 8BAAAACqBwAA7wIAAH4IAABuAwAADwAE8GAAAAAyAArwCAAAAEoUAAACCgAAgwAL8DAAAACF AAIAAACHAAEAAACBAXiOlgC/ARAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAA AMoHAABBAwAAnAgAAMADAAAPAATwYAAAADIACvAIAAAASxQAAAIKAACDAAvwMAAAAIUAAgAA AIcAAQAAAIEBeI6WAL8BEAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAtwcA AFsDAACICAAALAQAAA8ABPBgAAAAMgAK8AgAAABMFAAAAgoAAIMAC/AwAAAAhQACAAAAhwAB AAAAgQF4jpYAvwEQABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAACGBgAAHQMA AC4IAADtAwAADwAE8PYAAAAyAQrwCAAAAE0UAAACCgAA8wAL8MYAAACFAAIAAACHAAEAAABC AbSdAABFwU4AAABHAewyxwBIAeedUQFJAa9PAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjX AQAAAAD/AQAACAABAgIAAAg/AgAAAgAJAAwACABP+///AAAAAA+kAADAqAAAAAAAAKE4AAC0 nQAAPzQAAE/7//8AAAAAD6QAAMCoAAAAAAAAoTgAALSdAAA/NAAAr08AAGBUAAADAAQACAAA AAAAoTgAALSdAAA/NAAAr08AAGBUAAAAAA/wEAAAAPcGAADBAgAABAgAABMDAAAPAATwGgEA ADIBCvAIAAAAThQAAAIKAABTAQvw6gAAAIUAAgAAAIcAAQAAAEIBtJ0AAEXBTgAAAEcB7DLH AEgB551RAUkBr08AAFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAA ANMBAAAAANQBAAAAANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAE/7//8A AAAAD6QAAMCoAAAAAAAAoTgAALSdAAA/NAAAT/v//wAAAAAPpAAAwKgAAAAAAAChOAAAtJ0A AD80AACvTwAAYFQAAAMABAAIAAAAAAChOAAAtJ0AAD80AACvTwAAYFQAAAAAD/AQAAAA9wYA AMECAAAECAAAEwMAAA8ABPDYAAAAMgEK8AgAAABPFAAAAgoAAAMBC/CoAAAAhQACAAAAhwAB AAAAQgFOgAAAQwG7ZQAARcEkAAAARwEjIagASAHMXy0BSQFgVAAAUcEeAAAAgQF4jpYAvwEQ ABAAwAEBAAAI1wEAAAAA/wEAAAgAAQICAAAIPwIAAAIACQAJAPD/AAAAAMCowKjOAbtlToBW DAAAAADAqMCozgG7ZU6AVgxgVGBUAwAEAAgAzgEAALtlAABOgAAAVgwAAGBUAABgVAAAAAAP 8BAAAABTBgAA6gIAAPoGAABNAwAADwAE8PwAAAAyAQrwCAAAAFAUAAACCgAAYwEL8MwAAACF AAIAAACHAAEAAABCAU6AAABDAbtlAABFwSQAAABHASMhqABIAcxfLQFJAWBUAABRwR4AAACB AQQAAAiDAQAAAAi/AQAAEADAATZHSQDLAZwxAADSAQAAAADTAQAAAADUAQAAAADVAQAAAADX AQAAAAD/AQgACAABAgIAAAg/AgAAAgAJAAkA8P8AAAAAwKjAqM4Bu2VOgFYMAAAAAMCowKjO AbtlToBWDGBUYFQDAAQACADOAQAAu2UAAE6AAABWDAAAYFQAAGBUAAAAAA/wEAAAAFMGAADq AgAA+gYAAE0DAAAPAATwAgEAADIBCvAIAAAAURQAAAIKAAATAQvw0gAAAIUAAgAAAIcAAQAA AEIBe30AAEMB7lgAAEXBTgAAAEcBcdg8AEgBFBi3AEkBYFQAAEoBjgQAAFHBHgAAAIEBeI6W AL8BEAAQAMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAACAAkADAAIAAAAAAAusP//wKgA AO5YAAB7fQAAPU4AAB8AAAAAAAAAAAAAAC6w///AqAAA7lgAAHt9AAA9TgAAHwAAAAAAAABg VAAAjgQAAAMABAAIAHt9AAA9TgAAHwAAAAAAAABgVAAAjgQAAAAAD/AQAAAAOgYAAMsDAADk BgAAGQQAAA8ABPAmAQAAMgEK8AgAAABSFAAAAgoAAHMBC/D2AAAAhQACAAAAhwABAAAAQgF7 fQAAQwHuWAAARcFOAAAARwFx2DwASAEUGLcASQFgVAAASgGOBAAAUcEeAAAAgQEEAAAIgwEA AAAIvwEAABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA1wEAAAAA/wEI AAgAAQICAAAIPwIAAAIACQAMAAgAAAAAAC6w///AqAAA7lgAAHt9AAA9TgAAHwAAAAAAAAAA AAAALrD//8CoAADuWAAAe30AAD1OAAAfAAAAAAAAAGBUAACOBAAAAwAEAAgAe30AAD1OAAAf AAAAAAAAAGBUAACOBAAAAAAP8BAAAAA6BgAAywMAAOQGAAAZBAAADwAE8PwAAAAyAQrwCAAA AFMUAAACCgAAAwEL8MwAAACFAAIAAACHAAEAAABCAadlAABDARV+AABFwU4AAABHATcvAgFI AQmgHQBJAUcRAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAABAgIAAAg/ AgAAAgAJAAwACADnvP//AAAAAKdlAADAqAAAAAAAAMoBAACfWgAAFX4AAOe8//8AAAAAp2UA AMCoAAAAAAAAygEAAJ9aAAAVfgAARxEAAGBUAAADAAQACAAAAAAAygEAAJ9aAAAVfgAARxEA AGBUAAAAAA/wEAAAAAEIAADwAgAAgQgAAE8DAAAPAATwIAEAADIBCvAIAAAAVBQAAAIKAABj AQvw8AAAAIUAAgAAAIcAAQAAAEIBp2UAAEMBFX4AAEXBTgAAAEcBNy8CAUgBCaAdAEkBRxEA AFHBHgAAAIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAA ANUBAAAAANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAOe8//8AAAAAp2UAAMCoAAAA AAAAygEAAJ9aAAAVfgAA57z//wAAAACnZQAAwKgAAAAAAADKAQAAn1oAABV+AABHEQAAYFQA AAMABAAIAAAAAADKAQAAn1oAABV+AABHEQAAYFQAAAAAD/AQAAAAAQgAAPACAACBCAAATwMA AA8ABPD2AAAAMgEK8AgAAABVFAAAAgoAAPMAC/DGAAAAhQACAAAAhwABAAAAQwEQcwAARcFO AAAARwEAhTQBSAGpiiMASgEEQgAAUcEeAAAAgQF4jpYAvwEQABAAwAEBAAAI1wEAAAAA/wEA AAgAAQICAAAIPwIAAAIACQAMAAgAoKv//6Tt//9gVAAAZJYAAIw0AAAAAAAAqEQAABBzAACg q///pO3//2BUAABklgAAjDQAAAAAAACoRAAAEHMAAAAAAAAEQgAAAwAEAAgAjDQAAAAAAACo RAAAEHMAAAAAAAAEQgAAAAAP8BAAAAAkCAAATgMAAJ4IAACsAwAADwAE8BoBAAAyAQrwCAAA AFYUAAACCgAAUwEL8OoAAACFAAIAAACHAAEAAABDARBzAABFwU4AAABHAQCFNAFIAamKIwBK AQRCAABRwR4AAACBAQQAAAiDAQAAAAi/AQAAEADAATZHSQDLAZwxAADSAQAAAADTAQAAAADU AQAAAADVAQAAAADXAQAAAAD/AQgACAABAgIAAAg/AgAAAgAJAAwACACgq///pO3//2BUAABk lgAAjDQAAAAAAACoRAAAEHMAAKCr//+k7f//YFQAAGSWAACMNAAAAAAAAKhEAAAQcwAAAAAA AARCAAADAAQACACMNAAAAAAAAKhEAAAQcwAAAAAAAARCAAAAAA/wEAAAACQIAABOAwAAnggA AKwDAAAPAATwAgEAADIBCvAIAAAAVxQAAAIKAAATAQvw0gAAAIUAAgAAAIcAAQAAAEIB6m8A AEMBcm0AAEXBTgAAAEcBULdWAUgB7QxtAEkBihsAAEoBEhkAAFHBHgAAAIEBeI6WAL8BEAAQ AMABAQAACNcBAAAAAP8BAAAIAAECAgAACD8CAAACAAkADAAIACrH//+yxP//6m8AAHJtAAAb bAAAAAAAAAAAAADTaAAAKsf//7LE///qbwAAcm0AABtsAAAAAAAAAAAAANNoAACKGwAAEhkA AAMABAAIABtsAAAAAAAAAAAAANNoAACKGwAAEhkAAAAAD/AQAAAA/QcAAKkDAACMCAAAMQQA AA8ABPAmAQAAMgEK8AgAAABYFAAAAgoAAHMBC/D2AAAAhQACAAAAhwABAAAAQgHqbwAAQwFy bQAARcFOAAAARwFQt1YBSAHtDG0ASQGKGwAASgESGQAAUcEeAAAAgQEEAAAIgwEAAAAIvwEA ABAAwAE2R0kAywGcMQAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA1wEAAAAA/wEIAAgAAQIC AAAIPwIAAAIACQAMAAgAKsf//7LE///qbwAAcm0AABtsAAAAAAAAAAAAANNoAAAqx///ssT/ /+pvAABybQAAG2wAAAAAAAAAAAAA02gAAIobAAASGQAAAwAEAAgAG2wAAAAAAAAAAAAA02gA AIobAAASGQAAAAAP8BAAAAD9BwAAqQMAAIwIAAAxBAAADwAE8PwAAAAyAQrwCAAAAFkUAAAC CgAAAwEL8MwAAACFAAIAAACHAAEAAABDAfKgAABFwU4AAABHAUOOcgBIAe9VCgFJAWBUAABK ATRUAABRwR4AAACBAXiOlgC/ARAAEADAAQEAAAjXAQAAAAD/AQAACAABAgIAAAg/AgAAAgAJ AAwACAAAAAAA1P///8CoAACUqAAAUDEAAPKgAAD8TgAAAAAAAAAAAADU////wKgAAJSoAABQ MQAA8qAAAPxOAAAAAAAAYFQAADRUAAADAAQACABQMQAA8qAAAPxOAAAAAAAAYFQAADRUAAAA AA/wEAAAABAGAABNAwAAXgYAAM4DAAAPAATwIAEAADIBCvAIAAAAWhQAAAIKAABjAQvw8AAA AIUAAgAAAIcAAQAAAEMB8qAAAEXBTgAAAEcBQ45yAEgB71UKAUkBYFQAAEoBNFQAAFHBHgAA AIEBBAAACIMBAAAACL8BAAAQAMABNkdJAMsBnDEAANIBAAAAANMBAAAAANQBAAAAANUBAAAA ANcBAAAAAP8BCAAIAAECAgAACD8CAAACAAkADAAIAAAAAADU////wKgAAJSoAABQMQAA8qAA APxOAAAAAAAAAAAAANT////AqAAAlKgAAFAxAADyoAAA/E4AAAAAAABgVAAANFQAAAMABAAI AFAxAADyoAAA/E4AAAAAAABgVAAANFQAAAAAD/AQAAAAEAYAAE0DAABeBgAAzgMAAA8ABPD8 AAAAMgEK8AgAAABbFAAAAgoAAAMBC/DMAAAAhQACAAAAhwABAAAAQgFWmAAARcFOAAAARwEl hiIASAGm+6gASQHSUgAASgEAAAAAUcEeAAAAgQF4jpYAvwEQABAAwAEBAAAI1wEAAAAA/wEA AAgAAQICAAAIPwIAAAIACQAMAAgAcv7//6Cr//8ypwAAYFQAAFaYAADSLwAAAAAAACAQAABy /v//oKv//zKnAABgVAAAVpgAANIvAAAAAAAAIBAAANJSAAAAAAAAAwAEAAgAVpgAANIvAAAA AAAAIBAAANJSAAAAAAAAAAAP8BAAAADeBgAA/AMAAAIIAABLBAAADwAE8CABAAAyAQrwCAAA AFwUAAACCgAAYwEL8PAAAACFAAIAAACHAAEAAABCAVaYAABFwU4AAABHASWGIgBIAab7qABJ AdJSAABKAQAAAABRwR4AAACBAQQAAAiDAQAAAAi/AQAAEADAATZHSQDLAZwxAADSAQAAAADT AQAAAADUAQAAAADVAQAAAADXAQAAAAD/AQgACAABAgIAAAg/AgAAAgAJAAwACABy/v//oKv/ /zKnAABgVAAAVpgAANIvAAAAAAAAIBAAAHL+//+gq///MqcAAGBUAABWmAAA0i8AAAAAAAAg EAAA0lIAAAAAAAADAAQACABWmAAA0i8AAAAAAAAgEAAA0lIAAAAAAAAAAA/wEAAAAN4GAAD8 AwAAAggAAEsEAAAPAATw4AAAAKIMCvAIAAAAXRQAAAIKAAATAQvwZgAAAIAAdD8DCIEAwB0B AIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAgAPAIEB//9mAL8BDAAeAMABAQAA CP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAD/AQAAAAcgEAAFANAABn AwAAZA4AAA8ADfBCAAAAAACfDwQAAAAEAAAAAACoDw4AAABQU1RODUNhcnJpZXIgQwAAoQ8Y AAAADwAAAAAAAAgAAAEADwAAAAEAAgABAAwADwAE8I4AAABCAQrwCAAAAF4UAACACgAAEwEL 8GYAAACBAMAdAQCCAOCOAACDAMAdAQCEAOCOAACFAAIAAACHAAEAAAC/AAAADwBEAQQAAAB/ AQAAAQC/AQAAEADAAQEAAAj/AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAA ABDwCAAAACAKkAYQCEALDwAE8I4AAABCAQrwCAAAAF8UAACACgAAEwEL8GYAAACBAMAdAQCC AOCOAACDAMAdAQCEAOCOAACFAAIAAACHAAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/AQAAEADA AQEAAAj/AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAADAGQAjg EMAJDwAE8I4AAABCAQrwCAAAAGAUAACACgAAEwEL8GYAAACBAMAdAQCCAOCOAACDAMAdAQCE AOCOAACFAAIAAACHAAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/AR4AHgAB AgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAABAFEAsQC7AHDwAE8GoAAACy BArwCAAAAGEUAAAACgAAswAL8EIAAAB/AAAAgACFAAIAAACHAAEAAAAEQQEAAACBAQQAAAiD AQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAABDwCAAAALAEIBCgFNAIDwAE 8NAAAACiDArwCAAAAGIUAAAACgAAEwEL8GYAAACAANQ/AwiBAMAdAQCCAOCOAACDAMAdAQCE AOCOAACFAAIAAACHAAEAAAC/AAIADwCBAf//ZgC/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/ AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAOAHWRLrE4EIDwAN8DoAAAAAAJ8PBAAA AAQAAAAAAKgPBgAAAElUU1AgRAAAoQ8YAAAABwAAAAAAAAgAAAEABwAAAAEAAgABAAwADwAE 8JQAAABCAQrwCAAAAGMUAAAACgAAIwEL8GwAAACBAMAdAQCCAOCOAACDAMAdAQCEAOCOAACF AAIAAACHAAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAAD/AR4AHgAB AgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAFAHsBPAFVAHDwAE8I4AAABC AQrwCAAAAGQUAADACgAAEwEL8GYAAACBAMAdAQCCAOCOAACDAMAdAQCEAOCOAACFAAIAAACH AAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/AR4AHgABAgIAAAg/AgAAAwC/ AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAAAGoBGwEyAHDwAE8GoAAACyBArwCAAAAGUUAAAA CgAAswAL8EIAAAB/AAAAgACFAAIAAACHAAEAAAAEQQEAAACBAQQAAAiDAQAAAAi/AQAAEADA AQEAAAj/AQAACAABAgIAAAg/AgAAAgAAABDwCAAAAEALIBCgFGAPDwAE8NAAAACiDArwCAAA AGYUAAAACgAAEwEL8GYAAACAADRAAwiBAMAdAQCCAOCOAACDAMAdAQCEAOCOAACFAAIAAACH AAEAAAC/AAIADwCBAf//ZgC/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/ AhYAHwB/AwAADwAAABDwCAAAAHAOWxLoExEPDwAN8DoAAAAAAJ8PBAAAAAQAAAAAAKgPBgAA AElUU1AgRQAAoQ8YAAAABwAAAAAAAAgAAAEABwAAAAEAAgABAAwADwAE8JQAAABCAQrwCAAA AGcUAAAACgAAIwEL8GwAAACBAMAdAQCCAOCOAACDAMAdAQCEAOCOAACFAAIAAACHAAEAAAC/ AAAADwBEAQQAAAB/AQAAAQC/AQAAEADAAQEAAAjLAZ9vAAD/AR4AHgABAgIAAAg/AgAAAwC/ AgEADwD/AhYAHwB/AwAADwAAABDwCAAAAOANsBPAFeANDwAE8I4AAABCAQrwCAAAAGgUAADA CgAAEwEL8GYAAACBAMAdAQCCAOCOAACDAMAdAQCEAOCOAACFAAIAAACHAAEAAAC/AAAADwBE AQQAAAB/AQAAAQC/AQAAEADAAQEAAAj/AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/ AwAADwAAABDwCAAAAJAMoBGwE7ANDwAE8JQAAABCAQrwCAAAAGkUAAAACgAAIwEL8GwAAACB AMAdAQCCAOCOAACDAMAdAQCEAOCOAACFAAIAAACHAAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/ AQAAEADAAQEAAAjLAZ9vAAD/AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAA ABDwCAAAAHALwAawE+ANDwAE8JQAAABCAQrwCAAAAGoUAACACgAAIwEL8GwAAACBAMAdAQCC AOCOAACDAMAdAQCEAOCOAACFAAIAAACHAAEAAAC/AAAADwBEAQQAAAB/AQAAAQC/AQAAEADA AQEAAAjLAZ9vAAD/AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAABDwCAAA AFAHwAbgE0ALDwAD8LUBAAAPAATwRgAAAAEACfAQAAAAIwwAACENAAA5DQAAVg4AAAIACvAI AAAAaxQAAAECAAATAAvwBgAAAIgDAAAAAAAAEPAIAAAAsAoRBicH5QsPAATwcgAAALIECvAI AAAAbBQAAAIKAACzAAvwQgAAAH8AAACAAIUAAgAAAIcAAQAAAARBAwAAAIEBBAAACIMBAAAA CL8BAAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAIwwAACENAAA5DQAAVg4A AA8ABPDlAAAAEgAK8AgAAABtFAAAAgoAAPMAC/BaAAAAgACUQAMIgQDaEAEAggCgjgAAgwDa EAEAhACgjgAAhQACAAAAhwABAAAAvwAQAB8AgQEAAAAIvwEQABAAwAEFAAAIywE4YwAA/wEI AAgAAQICAAAIPwIAAAIAAAAP8BAAAABLDAAA1g0AABENAABWDgAADwAN8FMAAAAAAJ8PBAAA AAQAAAAAAKgPAQAAAFYAAKEPGAAAAAIAAAAAAAAIAAABAAIAAAABAAIAAQAOAAAApg8WAAAA 8R4AAFIB3QDdALkBuQGVApUCcQNxAw8AA/C1AQAADwAE8EYAAAABAAnwEAAAACMMAAAhDQAA OQ0AAFYOAAACAArwCAAAAG4UAAABAgAAEwAL8AYAAACIAwAAAAAAABDwCAAAAJAGIBM2FMUH DwAE8HIAAACyBArwCAAAAG8UAAACCgAAswAL8EIAAAB/AAAAgACFAAIAAACHAAEAAAAEQQMA AACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAABAgIAAAg/AgAAAgAAAA/wEAAAACMM AAAhDQAAOQ0AAFYOAAAPAATw5QAAABIACvAIAAAAcBQAAAIKAADzAAvwWgAAAIAA9EADCIEA 2hABAIIAoI4AAIMA2hABAIQAoI4AAIUAAgAAAIcAAQAAAL8AEAAfAIEBAAAACL8BEAAQAMAB BQAACMsBOGMAAP8BCAAIAAECAgAACD8CAAACAAAAD/AQAAAASwwAANYNAAARDQAAVg4AAA8A DfBTAAAAAACfDwQAAAAEAAAAAACoDwEAAABWAAChDxgAAAACAAAAAAAACAAAAQACAAAAAQAC AAEADgAAAKYPFgAAAPEeAABSAd0A3QC5AbkBlQKVAnEDcQMPAAPwtQEAAA8ABPBGAAAAAQAJ 8BAAAAAjDAAAIQ0AADkNAABWDgAAAgAK8AgAAABxFAAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ 8AgAAAAgDSATNhRVDg8ABPByAAAAsgQK8AgAAAByFAAAAgoAALMAC/BCAAAAfwAAAIAAhQAC AAAAhwABAAAABEEDAAAAgQEEAAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIA AAIAAAAP8BAAAAAjDAAAIQ0AADkNAABWDgAADwAE8OUAAAASAArwCAAAAHMUAAACCgAA8wAL 8FoAAACAAFRBAwiBANoQAQCCAKCOAACDANoQAQCEAKCOAACFAAIAAACHAAEAAAC/ABAAHwCB AQAAAAi/ARAAEADAAQUAAAjLAThjAAD/AQgACAABAgIAAAg/AgAAAgAAAA/wEAAAAEsMAADW DQAAEQ0AAFYOAAAPAA3wUwAAAAAAnw8EAAAABAAAAAAAqA8BAAAAVgAAoQ8YAAAAAgAAAAAA AAgAAAEAAgAAAAEAAgABAA4AAACmDxYAAADxHgAAUgHdAN0AuQG5AZUClQJxA3EDDwAD8KcB AAAPAATwRgAAAAEACfAQAAAA4BAAAPAJAACgFAAA9wsAAAIACvAIAAAAdBQAAAECAAATAAvw BgAAAIgDAAAAAAAAEPAIAAAA8APACcAMkAUPAATwcgAAALIECvAIAAAAdRQAAAIKAACzAAvw QgAAAH8AAACAAIUAAgAAAIcAAQAAAARBAgAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8B AAAIAAECAgAACD8CAAACAAAAD/AQAAAA4BAAAPAJAACgFAAA1QsAAA8ABPDXAAAAogwK8AgA AAB2FAAAAgoAAOMAC/BUAAAAfwCAAIAAgAAUQgMIvwACAAIAgQEAAAAIvwEQABAAwAEFAAAI ywFqSgAA0gEAAAAA0wEAAAAA1AEAAAAA1QEAAAAA/wEIAAgAAQIBAAAIPwIAAAIAAAAP8BAA AAD4EAAAsAoAAEAUAAD3CwAADwAN8EsAAAAAAJ8PBAAAAAQAAAAAAKgPFQAAAENhcnJpZXIg UG9saWN5IFNlcnZlcgAAoQ8aAAAAFgAAAAAAACgAAAEAMgAWAAAAAQACAAEACgAPAATwqAAA ALIECvAIAAAAdxQAABAKAAAjAQvwbAAAAIEAQR0BAIIAoI4AAIMAQR0BAIQAoI4AAL8AAAAP AARBBAAAAAsBBwAAAD8BAAABAIEBBAAACIMBAAAACL8BDAAeAMABAQAACP8BBgAOAAECAgAA CD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAcAgPCDAJOQoPABHwDAAAAAAAwQsE AAAABwAAAA8ABPCoAAAAsgQK8AgAAAB4FAAAEAoAACMBC/BsAAAAgQBBHQEAggCgjgAAgwBB HQEAhACgjgAAvwAAAA8ABEEEAAAACwEIAAAAPwEAAAEAgQEEAAAIgwEAAAAIvwEMAB4AwAEB AAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AgAAABABa8Q0BEJ Bw8AEfAMAAAAAADBCwQAAAAIAAAADwAE8KgAAACyBArwCAAAAHkUAAAQCgAAIwEL8GwAAACB AEEdAQCCAKCOAACDAEEdAQCEAKCOAAC/AAAADwAEQQQAAAALAQkAAAA/AQAAAQCBAQQAAAiD AQAAAAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAA ABDwCAAAACcL3xAAEvAMDwAR8AwAAAAAAMELBAAAAAkAAAAPAATwjgAAAEIBCvAIAAAAehQA AAAKAAATAQvwZgAAAIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAAAP AEQBBAAAAH8BAAABAL8BAAAQAMABAQAACP8BHgAeAAECAgAACD8CAAADAL8CAQAPAP8CFgAf AH8DAAAPAAAAEPAIAAAAkAkACRARcAsPAATwwgAAAKIMCvAIAAAAexQAAAAKAAATAQvwZgAA AIAAdEIDCIEAwB0BAIIA4I4AAIMAwB0BAIQA4I4AAIUAAgAAAIcAAQAAAL8AAgAPAIEB//9m AL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAI AAAA8AHiBz4IkQIPAA3wLAAAAAAAnw8EAAAABAAAAAAAoQ8YAAAAAQAAAAAAAAgAAAEAAQAA AAEAAgABAAwADwAE8NgAAAASAArwCAAAAHwUAAAgCgAAYwEL8IQAAAAEAAAAAAB/AAEAAQCA ADRDAwiBAMxAAQCCAGWgAACDAMxAAQCEAGWgAACHAAEAAAC/ABAAHwCBAQQAAAiDAQAAAAi/ AQAAEQDAAQEAAAj/AQAACQABAgIAAAgFApwxAAAGApwxAAAHAsic//8IAsic//8/AgAAAgAB AwIEAACIAwAAAAAAABDwCAAAAIABsAHQFFAEDwAR8BAAAAAAAMMLCAAAAAAAAAANAAMIDwAN 8AwAAAAAAJ4PBAAAAAAAAAAPAAPwtQEAAA8ABPBGAAAAAQAJ8BAAAAAjDAAAIQ0AADkNAABW DgAAAgAK8AgAAAB9FAAAAQIAABMAC/AGAAAAiAMAAAAAAAAQ8AgAAABAC2AGdgd1DA8ABPBy AAAAsgQK8AgAAAB+FAAAAgoAALMAC/BCAAAAfwAAAIAAhQACAAAAhwABAAAABEEDAAAAgQEE AAAIgwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAAAjDAAAIQ0A ADkNAABWDgAADwAE8OUAAAASAArwCAAAAH8UAAACCgAA8wAL8FoAAACAANRFAwiBANoQAQCC AKCOAACDANoQAQCEAKCOAACFAAIAAACHAAEAAAC/ABAAHwCBAQAAAAi/ARAAEADAAQUAAAjL AThjAAD/AQgACAABAgIAAAg/AgAAAgAAAA/wEAAAAEsMAADWDQAAEQ0AAFYOAAAPAA3wUwAA AAAAnw8EAAAABAAAAAAAqA8BAAAAVgAAoQ8YAAAAAgAAAAAAAAgAAAEAAgAAAAEAAgABAA4A AACmDxYAAADxHgAAUgHdAN0AuQG5AZUClQJxA3EDDwAD8LUBAAAPAATwRgAAAAEACfAQAAAA IwwAACENAAA5DQAAVg4AAAIACvAIAAAAgBQAAAECAAATAAvwBgAAAIgDAAAAAAAAEPAIAAAA oAvABtYH1QwPAATwcgAAALIECvAIAAAAgRQAAAIKAACzAAvwQgAAAH8AAACAAIUAAgAAAIcA AQAAAARBAwAAAIEBBAAACIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAA D/AQAAAAIwwAACENAAA5DQAAVg4AAA8ABPDlAAAAEgAK8AgAAACCFAAAAgoAAPMAC/BaAAAA gAA0SQMIgQDaEAEAggCgjgAAgwDaEAEAhACgjgAAhQACAAAAhwABAAAAvwAQAB8AgQEAAAAI vwEQABAAwAEFAAAIywE4YwAA/wEIAAgAAQICAAAIPwIAAAIAAAAP8BAAAABLDAAA1g0AABEN AABWDgAADwAN8FMAAAAAAJ8PBAAAAAQAAAAAAKgPAQAAAFYAAKEPGAAAAAIAAAAAAAAIAAAB AAIAAAABAAIAAQAOAAAApg8WAAAA8R4AAFIB3QDdALkBuQGVApUCcQNxAw8AA/C1AQAADwAE 8EYAAAABAAnwEAAAACMMAAAhDQAAOQ0AAFYOAAACAArwCAAAAIMUAAABAgAAEwAL8AYAAACI AwAAAAAAABDwCAAAAMAMgBOWFPUNDwAE8HIAAACyBArwCAAAAIQUAAACCgAAswAL8EIAAAB/ AAAAgACFAAIAAACHAAEAAAAEQQMAAACBAQQAAAiDAQAAAAi/AQAAEADAAQEAAAj/AQAACAAB AgIAAAg/AgAAAgAAAA/wEAAAACMMAAAhDQAAOQ0AAFYOAAAPAATw5QAAABIACvAIAAAAhRQA AAIKAADzAAvwWgAAAIAAFEUDCIEA2hABAIIAoI4AAIMA2hABAIQAoI4AAIUAAgAAAIcAAQAA AL8AEAAfAIEBAAAACL8BEAAQAMABBQAACMsBOGMAAP8BCAAIAAECAgAACD8CAAACAAAAD/AQ AAAASwwAANYNAAARDQAAVg4AAA8ADfBTAAAAAACfDwQAAAAEAAAAAACoDwEAAABWAAChDxgA AAACAAAAAAAACAAAAQACAAAAAQACAAEADgAAAKYPFgAAAPEeAABSAd0A3QC5AbkBlQKVAnED cQMPAAPwtQEAAA8ABPBGAAAAAQAJ8BAAAAAjDAAAIQ0AADkNAABWDgAAAgAK8AgAAACGFAAA AQIAABMAC/AGAAAAiAMAAAAAAAAQ8AgAAAAABooToBQ1Bw8ABPByAAAAsgQK8AgAAACHFAAA AgoAALMAC/BCAAAAfwAAAIAAhQACAAAAhwABAAAABEEDAAAAgQEEAAAIgwEAAAAIvwEAABAA wAEBAAAI/wEAAAgAAQICAAAIPwIAAAIAAAAP8BAAAAAjDAAAIQ0AADkNAABWDgAADwAE8OUA AAASAArwCAAAAIgUAAACCgAA8wAL8FoAAACAABRIAwiBANoQAQCCAKCOAACDANoQAQCEAKCO AACFAAIAAACHAAEAAAC/ABAAHwCBAQAAAAi/ARAAEADAAQUAAAjLAThjAAD/AQgACAABAgIA AAg/AgAAAgAAAA/wEAAAAEsMAADWDQAAEQ0AAFYOAAAPAA3wUwAAAAAAnw8EAAAABAAAAAAA qA8BAAAAVgAAoQ8YAAAAAgAAAAAAAAgAAAEAAgAAAAEAAgABAA4AAACmDxYAAADxHgAAUgHd AN0AuQG5AZUClQJxA3EDDwAD8LUBAAAPAATwRgAAAAEACfAQAAAAIwwAACENAAA5DQAAVg4A AAIACvAIAAAAiRQAAAECAAATAAvwBgAAAIgDAAAAAAAAEPAIAAAAcAUQFCYVpQYPAATwcgAA ALIECvAIAAAAihQAAAIKAACzAAvwQgAAAH8AAACAAIUAAgAAAIcAAQAAAARBAwAAAIEBBAAA CIMBAAAACL8BAAAQAMABAQAACP8BAAAIAAECAgAACD8CAAACAAAAD/AQAAAAIwwAACENAAA5 DQAAVg4AAA8ABPDlAAAAEgAK8AgAAACLFAAAAgoAAPMAC/BaAAAAgAD0RgMIgQDaEAEAggCg jgAAgwDaEAEAhACgjgAAhQACAAAAhwABAAAAvwAQAB8AgQEAAAAIvwEQABAAwAEFAAAIywE4 YwAA/wEIAAgAAQICAAAIPwIAAAIAAAAP8BAAAABLDAAA1g0AABENAABWDgAADwAN8FMAAAAA AJ8PBAAAAAQAAAAAAKgPAQAAAFYAAKEPGAAAAAIAAAAAAAAIAAABAAIAAAABAAIAAQAOAAAA pg8WAAAA8R4AAFIB3QDdALkBuQGVApUCcQNxAw8ABPBIAAAAEgAK8AgAAAABFAAAAAwAAIMA C/AwAAAAgQEAAAAIgwEFAAAIkwGOn4sAlAHevWgAvwEeAB8A/wEAAAgABAMJAAAAPwMBAAEA DwMF8AADAAAAABTwCAAAAAEAAAAVFAAAAAAU8AgAAAACAAAAFhQAAAAAFPAIAAAAAwAAABcU AAAAABTwCAAAAAQAAAAYFAAAAAAU8AgAAAAFAAAAGRQAAAAAFPAIAAAABgAAABoUAAAAABTw CAAAAAcAAAAbFAAAAAAU8AgAAAAIAAAAHBQAAAAAFPAIAAAACQAAAB0UAAAAABTwCAAAAAoA AAAeFAAAAAAU8AgAAAALAAAAHxQAAAAAFPAIAAAADAAAACAUAAAAABTwCAAAAA0AAAAhFAAA AAAU8AgAAAAOAAAAIhQAAAAAFPAIAAAADwAAACMUAAAAABTwCAAAABAAAAAkFAAAAAAU8AgA AAARAAAAMRQAAAAAFPAIAAAAEgAAADIUAAAAABTwCAAAABMAAAAzFAAAAAAU8AgAAAAUAAAA NBQAAAAAFPAIAAAAFQAAADUUAAAAABTwCAAAABYAAAA2FAAAAAAU8AgAAAAXAAAANxQAAAAA FPAIAAAAGAAAADgUAAAAABTwCAAAABkAAAA5FAAAAAAU8AgAAAAaAAAAOhQAAAAAFPAIAAAA GwAAADsUAAAAABTwCAAAABwAAAA8FAAAAAAU8AgAAAAdAAAAPRQAAAAAFPAIAAAAHgAAAD4U AAAAABTwCAAAAB8AAAA/FAAAAAAU8AgAAAAgAAAAQBQAAAAAFPAIAAAAIQAAAE0UAAAAABTw CAAAACIAAABOFAAAAAAU8AgAAAAjAAAATxQAAAAAFPAIAAAAJAAAAFAUAAAAABTwCAAAACUA AABRFAAAAAAU8AgAAAAmAAAAUhQAAAAAFPAIAAAAJwAAAFMUAAAAABTwCAAAACgAAABUFAAA AAAU8AgAAAApAAAAVRQAAAAAFPAIAAAAKgAAAFYUAAAAABTwCAAAACsAAABXFAAAAAAU8AgA AAAsAAAAWBQAAAAAFPAIAAAALQAAAFkUAAAAABTwCAAAAC4AAABaFAAAAAAU8AgAAAAvAAAA WxQAAAAAFPAIAAAAMAAAAFwUAAAQAPAHIAAAAP///wAAAAAAAAAAAAAAAAAAbIgA0A4uAP// /wACyP4AEAAREHIAAAAABgAAeJy7cF7wwcKNUg8Z0IAdAzPDv/+cDGxIYoxQDAYCDED5//9B TBgNAv9HwZACf4H430A7YhQMGAhiyAfCEgYFBleGPCBdxFCJXhTgBWIMrCh5Hp/ahDmFK7fW HWT8R0AdqYBY+2kFhrL9AAWa93QQABEQcgAAAAAGAAB4nLtwXvDBwo1SDxnQgB0DM8O//5wM bEhijFAMBgIMQPn//0FMGA0C/0fBkAJ/gfjfQDtiFAwYCGLIB8ISBgUGV4Y8IF3EUIleFOAF YgysKHken9qEOYUrt9YdZPxHQB2pgFj7aQWGsv0ABZr3dBAAERBxAAAAAAYAAHicu3Be8MHC jVIPGdCAHQMzw7//nAxsSGKMUAwGAgxA+f//QUwYDQL/R8GQAn+B+N9AO2IUDBgIYsgHwhIG BQZXhjwgXcRQiV4U4AViDKwoeR6vYuXilVvrDjL+I6SOREC0/TQCQ9l+ALKl9p0QABEQcQAA AAAGAAB4nLtwXvDBwo1SDxnQgB0DM8O//5wMbEhijFAMBgIMQPn//0FMGA0C/0fBkAJ/gfjf QDtiFAwYCGLIB8ISBgUGV4Y8IF3EUIleFOAFYgysKHker2Ll4pVb6w4y/iOkjkRAtP00AkPZ fgCypfadEAAREHIAAAAABgAAeJy7cF7wwcKNUg8Z0IAdAzPDv/+cDGxIYoxQDAYCDED5//9B TBgNAv9HwZACf4H430A7YhQMGAhiyAfCEgYFBleGPCBdxFCJXhTgBWIMrCh5Hp/aBStLVm6t O8j4j4A6UgGx9tMKDGX7AYPH98QQABEQcgAAAAAGAAB4nLtwXvDBwo1SDxnQgB0DM8O//5wM bEhijFAMBgIMQPn//0FMGA0C/0fBkAJ/gfjfQDtiFAwYCGLIB8ISBgUGV4Y8IF3EUIleFOAF YgysKHken9oFK0tWbq07yPiPgDpSAbH20woMZfsBg8f3xBAAERByAAAAAAYAAHicu3Be8MHC jVIPGdCAHQMzw7//nAxsSGKMUAwGAgxA+f//QUwYDQL/R8GQAn+B+N9AO2IUDBgIYsgHwhIG BQZXhjwgXcRQiV4U4AViDKwoeR6fWgeDspVb6w4y/iOgjlRArP20AkPZfgAw4fbtEAAREHIA AAAABgAAeJy7cF7wwcKNUg8Z0IAdAzPDv/+cDGxIYoxQDAYCDED5//9BTBgNAv9HwZACf4H4 30A7YhQMGAhiyAfCEgYFBleGPCBdxFCJXhTgBWIMrCh5Hp9aB4OylVvrDjL+I6COVECs/bQC Q9l+ADDh9u0QABEQcgAAAAAGAAB4nLtwXvDBwo1SDxnQgB0DM8O//5wMbEhijFAMBgIMQPn/ /0FMGA0C/0fBkAJ/gfjfQDtiFAwYCGLIB8ISBgUGV4Y8IF3EUIleFOAFYgysKHken1oHg7KV W+sOMv4joI5UQKz9tAJD2X4AMOH27RAAERByAAAAAAYAAHicu3Be8MHCjVIPGdCAHQMzw7// nAxsSGKMUAwGAgxA+f//QUwYDQL/R8GQAn+B+N9AO2IUDBgIYsgHwhIGBQZXhjwgXcRQiV4U 4AViDKwoeR6f2gfbyldurTvI+I+AOlIBsfbTCgxl+wECA/gUAAByF0AAAAABAPAAAAAAALEK AAAsKQEApikBACAqAQCZKgEAEisBAIwrAQAGLAEAgCwBAPosAQB0LQEAYhMAADilAAAkwQAA AAD1DxwAAAACAQAAgxUAAwAAAADuLQEAAQAAAA8AAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA 4IWf8vlPaBCrkQgAKyez2TAAAAAQUgAADAAAAAEAAABoAAAAAgAAAHAAAAAEAAAAlAAAAAcA AACkAAAACAAAAOwAAAAJAAAA/AAAABIAAAAIAQAACgAAACgBAAAMAAAANAEAAA0AAABAAQAA DwAAAEwBAAARAAAAVAEAAAIAAADkBAAAHgAAABkAAABXaG9sZXNhbGUgVm9JUCBwcm92aWRl ciAAAGkAHgAAAAcAAABtYW5qYXgAbB4AAAA+AAAAQzpcUFJPR1JBfjFcTWljcm9zb2Z0IE9m ZmljZVxUZW1wbGF0ZXNcQmxhbmsgUHJlc2VudGF0aW9uLnBvdAB0AB4AAAAHAAAAbWFuamF4 AFIeAAAAAgAAADEAbmoeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50ACBPZkAAAACQ/YZq CAAAAEAAAABQufA+rX7BAUAAAAAgxHqptX7BAQMAAABTAAAARwAAALRQAAD/////AwAAAAgA bxBNDAAAAQAJAAADUigAAAIAoScAAAAAEQAAACYGDwAYAP////8AABAAAAAAAAAAAAC6AwAA ygIAAAkAAAAmBg8ACAD/////AgAAABcAAAAmBg8AIwD/////BAAbAFROUFAUAMjwADAAAAAA FAAAAEQNvAAAAAAAAAAKAAAAJgYPAAoAVE5QUAAAAgD0AwkAAAAmBg8ACAD/////AwAAAA8A AAAmBg8AFABUTlBQBAAMAAEAAAABAAAAAAAAAAUAAAALAgAAAAAFAAAADALKAroDBQAAAAkC AAAAAgUAAAABAv///wIFAAAABAENAAAABQAAAAcBAwAAAKEnAABBCyAAzAB4AKAAAAAAAMoC ugMAAAAAKAAAAKAAAAB4AAAAAQAIAAAAAAAASwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAA AIAAAACAgACAAAAAgACAAICAAADAwMAAwNzAAPDKpgAEBAQACAgIAAwMDAAREREAFhYWABwc HAAiIiIAKSkpAFVVVQBNTU0AQkJCADk5OQCAfP8AUFD/AJMA1gD/7MwAxtbvANbn5wCQqa0A AAAzAAAAZgAAAJkAAADMAAAzAAAAMzMAADNmAAAzmQAAM8wAADP/AABmAAAAZjMAAGZmAABm mQAAZswAAGb/AACZAAAAmTMAAJlmAACZmQAAmcwAAJn/AADMAAAAzDMAAMxmAADMmQAAzMwA AMz/AAD/ZgAA/5kAAP/MADMAAAAzADMAMwBmADMAmQAzAMwAMwD/ADMzAAAzMzMAMzNmADMz mQAzM8wAMzP/ADNmAAAzZjMAM2ZmADNmmQAzZswAM2b/ADOZAAAzmTMAM5lmADOZmQAzmcwA M5n/ADPMAAAzzDMAM8xmADPMmQAzzMwAM8z/ADP/MwAz/2YAM/+ZADP/zAAz//8AZgAAAGYA MwBmAGYAZgCZAGYAzABmAP8AZjMAAGYzMwBmM2YAZjOZAGYzzABmM/8AZmYAAGZmMwBmZmYA ZmaZAGZmzABmmQAAZpkzAGaZZgBmmZkAZpnMAGaZ/wBmzAAAZswzAGbMmQBmzMwAZsz/AGb/ AABm/zMAZv+ZAGb/zADMAP8A/wDMAJmZAACZM5kAmQCZAJkAzACZAAAAmTMzAJkAZgCZM8wA mQD/AJlmAACZZjMAmTNmAJlmmQCZZswAmTP/AJmZMwCZmWYAmZmZAJmZzACZmf8AmcwAAJnM MwBmzGYAmcyZAJnMzACZzP8Amf8AAJn/MwCZzGYAmf+ZAJn/zACZ//8AzAAAAJkAMwDMAGYA zACZAMwAzACZMwAAzDMzAMwzZgDMM5kAzDPMAMwz/wDMZgAAzGYzAJlmZgDMZpkAzGbMAJlm /wDMmQAAzJkzAMyZZgDMmZkAzJnMAMyZ/wDMzAAAzMwzAMzMZgDMzJkAzMzMAMzM/wDM/wAA zP8zAJn/ZgDM/5kAzP/MAMz//wDMADMA/wBmAP8AmQDMMwAA/zMzAP8zZgD/M5kA/zPMAP8z /wD/ZgAA/2YzAMxmZgD/ZpkA/2bMAMxm/wD/mQAA/5kzAP+ZZgD/mZkA/5nMAP+Z/wD/zAAA /8wzAP/MZgD/zJkA/8zMAP/M/wD//zMAzP9mAP//mQD//8wAZmb/AGb/ZgBm//8A/2ZmAP9m /wD//2YAIQClAF9fXwB3d3cAhoaGAJaWlgDLy8sAsrKyANfX1wDd3d0A4+PjAOrq6gDx8fEA +Pj4APD7/wCkoKAAgICAAAAA/wAA/wAAAP//AP8AAAD/AP8A//8AAP///wD///////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////FBQUFP////////////////////////// /////////////////////////////////////////////5GRkZGRkZGRkZGR//////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////8UFG2RrpEUFBQU//////////////////////// /////////////////////////////////////5GRkZH///+7vLu8vP///5GRkZGRkf////// //////////////////////////////////////////////////////////////////////// ////////////////////////////FBQUkpGSkZKRkpGSkRT///////////////////////// //////////////////////////////+RkZG1vLu8u7y7vLW8u7y7vLu8tby7vP+Rkf////// //////////////////////////////////////////////////////////////////////// ////////////////////////FJGukq6RrpKuka6SrpGuFP////////////////////////// /////////////////////////5GRu7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u/+RkZH///// //////////////////////////////////////////////////////////////////////// ////////////////////FJKRAJEAAACRAJEAAJKRkhT///////////////////////////// ////////////////////kZG8u7ySvLu8krwAvJIAALySvAAAAAAAvJK8u7ySvLv/kZH/kZGR kZGR//////////////////////////////////////////////////////////////////// ////////////////FJGukQAArpFtka6RbQAAkW0UFP////////////////////////////// ////////////////kbu8u7y7vLy8u7y7AAC8AAAAAAAAAAAAALu8u7y7vLy8u7z/kf+8vLy7 /5GRkZH///////////////////////////////////////////////////////////////// /////////////xSRkpGSkZKRkpGSkZKRkpGSkRT///////////////////////////////// ////////////kbW8u7y1vLu8tby7vAC8ALy1vLu8tby7ALW8u7y1vLu8tby7vLW8u7y1vLu8 tbz/kf////////////////////////////////////////////////////////////////// ////////////FBSRrpIAkQAArgAAkq6RrhT//////////////////////////////5GRkZGR kZH/////kbu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7 vP+Rkf////////////////////////////////////////////////////////////////// /////////xSSkZKRAAAAAAAAAJGSkZIU/////////////////////////5GRkZG8u7ySvP// kZGRkZK8uwCSvAAAAAAAAAAAAAAAALu8AAAAAAC8uwCSALsAALy7AAAAAACSvLu8kry7vJK8 u/+R//////////////////////////////////////////////////////////////////// ////////FJFtka6RbZGukW2RrpEU////////////////////////kZG7vLu8vLy7vLu8u7y8 vP//uwC7ALwAAAAAAAAAAAAAAAC8AAAAAAAAALwAAAAAAAAAAAAAAAAAALu8u7y8vLu8u7y7 /5H//////////////////////////xQUFBQUFP////////////////////////////////// //////8UFBQUkZKRkpGSFBQU/wAA//////////////////+Rkby7vLW8u7y7vLu8tby7vLu8 u7wAAAAAALy7ALW8u7y7ALu8tQC7ALsAAAC1AAC8u7y7vLUAuwC7vLu8tby7vLu8u7y1vLuR ////////////////////FBQU/xSSkZKRkpEUFBT///////////////////////////////// //////////8UFBQUFP///wAA/wAA//////////////+Ru7y7vLu8u7y7vLu8u7y7vLu8u7y7 vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8/5H/ ////////////////FJKukRSSrpGukq6RrpKuFP////////////////////////////////// /////////////////////wAA/wAA//////////+Rkry7vJK8u7ySvLu8kry7vJK8u7ySvLu8 kry7vJK8u7ySvLu8kry7vJK8u7ySvLu8kry7vJK8u7ySvLu8kry7vJK8u7ySvLu8krz/kf// ////////////FJKRkpGSkZKRkpGSkZKRkpEU//////////////////////////////////// /////////////////////wD//wAA//////+Ru7y7vLu8vLy7vKenp6enp6e8u7y7vLy8u7y7 vLu8vLy7vLu8u7y8vLu8u7y7vLy8u7y7vLu8vLy7vLu8u7y8vLu8u7y7vLy8u7y7vJH///// /////////xQUkQCRAAAAkQCRAAAAka6RFP////////////////////////////////////// ////////////////////AAD//wD/////kby7vLW8u7y1vPyn//////+nu7y1vLu8tby7vLW8 u7y1vLu8tby7vLW8u7y1vLu8tby7vLW8u7y1vLu8tby7vLW8u7y1vLu8tby7vLWR//////// /////xSRkpEAAJKRkpGSkZIAAJGSkRT///////////////////////////////////////// ////////////////////AAD/AAD/kby7vLu8u7y7vLvNp///////p7y7vLu8u7y7vLu8u7y7 vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLunp6enp6enu7y7vLu8kf////////// AAAUka6SrpGukq6RrpKuka6SrpEU//////////////////////////////////////////// ////////////////////AAD/AAC7vJK8u7ySvLu8/6f/AAD//6eSvLu8kry7vJK8u7ySvLu8 kry7vJK8u7ySvLu8kry7vJK8u7ySvLu8kry7vJL8p///////p7y7vJK8u/+R//8AAAAAAP// /xQUkZKRAJEAAJIAAJGSkZIU//////////////////////////////////////////////// ////////////////////AACRAAC8vLy7vLunp82np6enp6envLy8u7y7vLu8vLy7vLu8u7y8 vLu8u7y7vLy8u7y7vLu8vLy7vLu8u7y8vLu8/Kf/AAD//6e7vLu8vLwAAAAA//8AAAAAAAAA FJGukQAAAAAAAACRbZGukRT///////////////////////////////////////////////// /////////////////5G7ALW8AAC7vLvNp//8zf/N/83/x7u8u7y7vLW8u7y7vLu8tby7vLu8 u7y1vLu8u7y7vLW8u7y7vLu8tby7vLu8u/+np6enp6enp6enAAAAvAAAAAAAAAAAAAAA/wAU kpGSFJKRkpGSkZKRkhT///////////////////////////////////////8UFBQUFBQU/xT/ /////////////5G7vLsAALy7AACn/Kf/zfz//838zce8u7y7vLu8u7y7vLu8u7y7vLu8u7y7 vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7z8zf/N/838x///pwAAAAAAAAAAAP///wAAAAD//xQU FJIUka6SrhQUFBT///////////////////////////////////8UFBQUkpGSkZKRkhSSFBT/ /////////5G7vJK8u7wAALvNp/+np/zN/838/PzHkry7vJK8u7ySvLu8kry7vJK8u7ySvLu8 kry7vJK8u7ySvLu8kry7vJK8u7yS/Pz//838//z//6cAAAAAkf//AAAAAAD///////////// /xQUFBT///////////////////////////////////////8UrpFt/66RbZGukW2RrpEU//// /////5G7vLu8vLy7vLsA/Kf8zf/N/M38zfzNx7y7vLu8vLy7vLu8u7y8vLu8u7y7vLy8u7y7 vLu8vLy7vLu8u7y8vLu8u7y7vPzN/838zfys//+nvLu8AAAAAP////////////////////// //////////////////////////////////////////8UkZKRkpGSkZKRkpGSkZKRkhT///// //+RvLW8u7y1vLu8tf+nzfz//+bU1dTm1NW7vLW8u7y1vLu8tby7vLW8u7y1vLu8tby7vLW8 u7y1vLu8tby7vLW8u7y1vLvN/M38zfzNx6enpwAAAP+R//////////////////////////// //////////////////////////////////////8UrpKuAK4AAACuAK4AAACuka4UAAAAAAAA AAAAAAAAAAAAAAD8p/zN/838zfzHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAObV5tTm1Ob8/8cAALy7vJH///////////////////////////// ////////////////////////////////////FJKRkgAAkZKRkpGSkQAAkpGSFAAAAAAAAAAA AAAAAAAAAAAAzfz8/M38/PzN/Ly7vJK8u7ySvLu8kry7vJK8u7ySvLu8kry7vJK8u7ySvLu8 kry7vJK8u7ySvLu8kry7vPz8///8/PzHALwAvJK8kf////////////////////////////// /////////////////////////////////xRtka6RbZGukW2RrpFtka6RbRQAAAAAAAAAAAAA AAAAAAAAAPzN/+bU5tXm1Oa7vLu8vLy7vLu8u7y8vLu8u7y7vLy8u7y7vLu8vLy7vLu8u7y8 vLu8u7y7vLy8u7y7vLvN/P/8zfzNx7wAvAC8u/+R//////////////////////////////// ////////////////////////////////FBSSkZIAkgAAkQAAkpGS/xT///////+Ru7y7vLu8 tby7vLvN/P/8zfzN/Ly7vLW8u7y7vLu8tby7vLu8u7y1vLu8u7y7vLW8u7y7vLu8tby7vLu8 u7y1vLu8u7y7vLW8/M38zfzN/Me7vAC8AAD/kf////////////////////////////////// ////////////////////////////////FJGuAAAAAAAAAK6SrpGuFP///////5G7vLu8u7y7 vLu8/M38zfzN/Ky7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7 vLu8u7y7vLu8u7zU5tXm1ObUvLu8AAC7AJH///////////////////////////////////// //////////////////////////////8UFBQUkZKRkpGSFBQUFP////////+RvLu8kry7vJK8 ALzU1dTm1NXUAJK8u7ySvLu8kry7vJK8u7ySvLu8kry7vJK8u7ySvLu8kry7vJK8u7ySvLu8 kry7vJK8u7ySALu8kry7vJK8u7ySAJEA//////////////////////////////////////// ////////////////////////////////rhRtka4UFP///////////////5G8u7y8vLu8ALy7 vLy8u7y7vLsAvLy7vLu8u7y8vLu8u7y7vLy8u7y7vLu8vLy7vLu8u7y8vLu8u7y7vLy8u7y7 vLu8vLy7ALu8u7y8vLu8u7y7vLwAAAAA//////////////////////////////////////// ////////////////////////////////FBQU//////////////////+8kby7vLW8ALy1vLu8 tby7vLW8uwAAvLu8tby7vLW8u7y1vLu8tby7vLW8u7y1vLu8tby7vLW8u7y1vLu8tby7vLW8 u7y1vAC8tby7vLW8u7y1vLuRkf8A/wD///////////////////////////////////////// /////////////////////////////////////////////////////7yRvLu8ALy7vLu8u7y7 vLu8u7y7vAC8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7 vAC8u7y7vLu8u7y7vLuR/////wAAAP////////////////////////////////////////// /////////////////////////////////////////////////////5EAALySvLu8kry7vJK8 u7ySvLu8ALy7vJK8u7ySvLu8kry7vJK8u7ySvLu8kry7vJK8u7ySvLu8kry7vJK8u7ySvLsA kry7vJK8u7ySvJGR/////////wAAAP//////////FBQUFBQUFP8U//////////////////// //////////////////////////////////////////////////8A//+Rkby8u7y7vLu8vLy7 vLu8u7wAvLu8u7y7vLy8u7y7vLu8vLy7vLu8u7y8vLu8u7y7vLy8u7y7vLu8vLy7vLsAu7y8 vLu8u7z/vLz/////////////AP8A////FBQUFK6RbZGukW0UrhQU//////////////////// //////////////////////////////////////////////8A/////5G8u7y7vLW8u7y7vLu8 tby7s7Kzs7Ozs7u8u7y7vLW8u7y7vLu8tby7vLu8u7y1vLu8u7y7vLWzsrOzs7Ozu7y7vLu8 u7y1vLv/kf////////////8AAAD/FJKRkv+SkZKRkpGSkZKRFP////////////////////// //////////////////////////////////////////8A//////+Ru7y7vLu8u7y7vLu8u7y7 vLKQrLKysrKLu7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8spCssrKysou7vLu8u7y7 vLu8u5H///////////////8AFJKukQCSAAAAkgCRAAAAka4U//////////////////////// //////////////////////////////////////8A////////kby7vJK8u7ySvLu8kry7vJLV u7SRtJGziry7vJK8u7ySvLu8kry7vJK8u7ySvLu8kry7vJK8u9W7tJG0kbOKvJK8u7ySvLu8 krz/kf//////////////FJKRkpEAAJKRkpGSkZIAAJGSFP////////////////////////// /////////////////////////////////wAA/////////5G7vLu8vLy7vLu8u7y8vLu8spCz tbq8u4q7vLu8vLy7vLu8u7y8vLu8u7y7vLy8u7y7vLu8vLyykLO1ury7iru8u7y7vLy8u7y7 vJH//////////////xRtka6RbZGukW2RrpFtka6RbRT///////////////////////////// /////////////////////////////wD/////////////kbW8u7y1vLu8tby7vLW8u7rUs7Ky srKLvLW8u7y1vLu8tby7vLW8u7y1vLu8tby7vLW8u7y1utSzsrKysou8u7y1vLu8tby7vLWR //////////////8UkpGSkZKRkpGSkZKRkpGSkZIU//////////////////////////////// /////////////////////////wD//////////////5G8u7y7vLu8u7y7vLu8u7zbkbSRtLy0 iru8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7y7vNuRtJG0vLSKu7y7vLu8u7y7vLuR//// /////////////xQUrpGukgCRAACuAACSrv8U//////////////////////////////////// /////////////////////wD///////////////+8kbySvLu8kry7vJK8u7ySsrOysrKyswAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACys7KysrKzirySvLu8kry7vJK8kf////// ////////////FJKRkpEAAAAAAAAAkZKRkhT///////////////////////////////////// /xQUFBQU/////////wD//////////////////5G7vLu8u7y8vLu8u7y7vLKystOystOLvLy7 vLu8u7y8vLu8u7y7vLy8u7y7vLu8vLy7vLu8srKy07Ky04u7vLy8u7y7vLu8kf////////// //////////8UkW0UFJFtka6RbRQUFBT//////////////////////////////////////xSR kpGSkRQUFBT/AAD/////////////////////kbu8tby7vLu8u7y1vLuzrLKysrKziry7vLu8 tby7vLu8u7y1vLu8u7y7vLW8u7y7vLu8tbOssrKysrOKvLu8u7y7vLW8kf////////////// /////////xQU/5IUkpGSFBT//////////////////////////////////////xQUFBSuka6S rpGukq6RFP////////////////////////+Rkby7vLu8u7y7vLu82tras7LTsou7vLu8u7y7 vLu8u7y7vLu8u7y7vLu8u7y7vLu8u7za2tqzstOyi7u8u7y7vJGRkf////////////////// /////////////xQUFP///////////////////////////////////////xSSkZKRkpGSkZKR kpGSkRT///////////////////////////+RkZK8u7ySvLu8krPTs9OysrOKvLu8kry7vJK8 u7ySvLsAkry7vJK8u7ySvLu8kry7s9Oz07Kys4q8kryRkZH///////////////////////// /////////////////////////////////////////////////////xSRrpEAkQAAAJEAkQAA AJFtFP////////////////////////////+RkZG7vLy8u7zh2tna2tnas7u8u7y8vLu8u7y7 vLy8ALy7vLu8vLy7vLu8u7y8vOHa2dra2dqzkZGR//////////////////////////////// /////////////////////////////////////////////////xSSkZKRAACSkZKRkpGSkZKR khT/////////////////////////////////kZGRkZGR////////kbu8tby7vLW8u7y1vLu8 tQC7vLW8u7y1vLu8tby7vLW8u5H///////////////////////////////////////////// //////////////////////////////////////////////8UrpKuka6SrpGukq6RrpKuka4U //////////////////////////////////////////////////+Ru7y7vLu8u7y7vLu8u7wA vLu8u7y7vLu8u7y7vLu8u5H///////////////////////////////////////////////// /////////////////////////////////////////////xQU/5GSkQCRAACSAACRkpEU//// /////////////////////////////////////////////////5GRvJK8u7ySvLu8kry7AJK8 u7ySvLu8kry7vJK8u5H///////////////////////////////////////////////////// ////////////////////////////////////////////FK6RbZEAAAAAAAAAka6RbRT///// /////////////////////////////////////////////////5G8u7y7vLy8u7y7vAC8vLy7 vLu8u7y8vLu8kZH///////////////////////////////////////////////////////// //////////////////////////////////////////8UkZKRkpGSkZKRkpGSkRT///////// ////////////////////////////////////////////////kZGRvLu8u7y7vLUAu7y7vLu8 tby7kZGRkf////////////////////////////////////////////////////////////// /////////////////////////////////////////xQUFBSRrpKuka4UFBT///////////// /////////////////////////////////////////////////5GRkZG7vLu8ALy7vJGRkZGR kf////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////FBQUFBT///////////////////// ////////////////////////////////////////////////////kZGRkQCRkZH///////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////8A//////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AP////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////wD///////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////8A//////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////AP////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////wD///////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////8A//////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////AP////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////wD///////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////8A//////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////s7Kzsrr///////////////////////////////////////////////////////////// ////////////////////////////AP////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /7qQtLSK//////////////////////////////////////////////////////////////// //////////////+np6enp6enp6enp6enp6enp6enp/////////////////////////////// //////////////////////////////////////////////////////////////////////+0 s7OzkP//////////////AP////////////////////////////////////////////////// ////////////p////////////////////////6f///////////////////////////////// ////////////////////////////////////////////////////////////////////s7Oz tJD///8A/wD/AAAA/wD//wAAAAAA//8AAAD///////////////////////////////////// /////////6f///////////////////////+nFP////////////////////////////////// /////////////////////////////////////////////////////////////////7KysrKt ////AAAA/wAAAP8AAP8A/wAAAAAAAAAA//////////////////////////////////////// //////+n//////8AAAAAAAD/////////p23///////////////////////////////////// //////////////////////////////////////////////////////////////+z2rKygf// /wAA////////////AAD///////////////////////////////////////////////////// ////p////////////////////////6dt//////////////////////////////////////// ////////////////////////////////////////////////////////////2tTZ1LP///// //////////////////////////////////////////////////////////////////////// /6f///////////////////////+nc/////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////+n //8A/wAAAAAA/wAA//8AAP//p23///////////////////////////////////////////// //////////////////////////////////////////////////////+np6enp/////////// ////////////////////////////////////////////////////////////////////p/// /////////////////////6dt//////////////////////////////////////////////// ////////////////////////////////////////////////////p////6f///////////// /////////////////////////////////////////////////////////////////6enp6en p6enp6enp6enp6enp6enbf////////////////////////////////////////////////// /////////////////////////////////////////////////6f///+n//////////////// AAD///////////8A//////////////////////////////////////////////8UFBQUFBQU FBQUFBQUFBQUFBQUFG3///////////////////////////////////////////////////// //////////////////////////////////////////////+nAACnp/8A/wAAAP//AP///wD/ AP8AAAD//wD/AP//////////////////////////////////////////////FJKZkpmSFJKZ kpmSFJKZkpmSmRRt//////////////////////////////////////////////////////// /////////////////////////////////////////////P///8f/AAAA/wD//wAA//8AAAD/ AAAAAAAA/wAA/////////////////////////////////////////////xQUFBQUFBQUFBQU FBQUFBQUFBQUbf////////////////////////////////////////////////////////// /////////////////////////////////////////838zfzH/wAAAAAAAP8A/wD///////// ////////////////////////////////////////////////////////FBQUFBQUFBQUFBQU FBQUFBQUFBT///////////////////////////////////////////////////////////// ////////////////////////////////////////5tXm1P////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////wAAAP////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////AP////////////////// //////////////////////////////////////////////////////////////////////// ////////////////////////////////////AP//AP8AAAD/AAD/AAD//wAAAP8AAP8AAP// /wAAAAAAAP8AAP////////8A/////wAA//8AAAAAAAD//////wAAAP8AAAD//wAA////AAD/ /wAAAAAAAAD/AAD/AAAA//////////////////////////////////////////////////// ////////////////////////////////AAD//wAA/wD//wD/AP//AP//AP8A//////8A/wD/ AP//AP8A//////////8A/wD//wD//wD//wD//wD///////8A//8A/wD//wD//wD//wAA//// AAD//wD/AP////8A//////////////////////////////////////////////////////// /////////////////////////////wD/AAD/AP8A//8A/wD//wD//wD/AAAA/wAA////AAD/ /wD/AAAA////////AP8A//8A//8A//8A//8AAAD/////AP//AP8A//8A//8A/wD//wD//wAA //8A/wAAAP//AP////////////////////////////////////////////////////////// //////////////////////////8A/wAA/wD/AAD/AP8A//8A//8A/wD/AP8A////AP8A//8A /wD/AP///////wD/AP//AP//AP//AP//AP//AP///wD//wD/AP//AP//AP8A//8A//8AAP// AP8A/wD//wD///////////////////////////////////////////////////////////// //////////////////////8A//8A////AAD/AP///wAA////AP//AP///wAA//8A////AP// AP///////wD///8A//8AAP///wD//wD//wD//wAAAAD/AAAAAP8AAP8AAAD/AAAAAP8AAAD/ /wD//wAAAAD///////////////////////////////////////////////////////////// ////////////////////AP//AP///wAA/////////////wD//////////////////wD///// //////8A////AP////////8A//8A//8A//////////////////////////////////8A//// //////////////////////////////////////////////////////////////////////// ////////////////AAD/AAAA/wAAAP///////////wAA/////////////////wAA//////// //8AAAD//wAA//////8AAAAAAAAA//////////////////////////////8A//8AAP////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////8FAAAABwEBAAAACAAAAPoCBQABAAAAAAAAAAQAAAAtAQAA BwAAAPwCAQAAAAAAAAAEAAAALQEBAA8AAAAmBg8AFABUTlBQBAAMAAAAAAAAAAAAAAAAAAkA AAAmBg8ACAD/////AQAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAACAAAAAAAAAAAA AAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQAAAAF1c3VnC4bEJOXCAArLPmubAIAACgC AAAQAAAAAQAAAIgAAAADAAAAkAAAAA8AAACoAAAABAAAAMAAAAAGAAAAyAAAAAcAAADQAAAA CAAAANgAAAAJAAAA4AAAAAoAAADoAAAAFwAAAPAAAAALAAAA+AAAABAAAAAAAQAAEwAAAAgB AAAWAAAAEAEAAA0AAAAYAQAADAAAAKEBAAACAAAA5AQAAB4AAAAPAAAAT24tc2NyZWVuIFNo b3cAAB4AAAANAAAAY2lzY29TeXN0ZW1zAHcAAAMAAAAVQQEAAwAAADYAAAADAAAAAwAAAAMA AAAAAAAAAwAAAAAAAAADAAAAAAAAAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAA CwAAAAAAAAAeEAAABgAAABAAAABUaW1lcyBOZXcgUm9tYW4AFwAAAEJsYW5rIFByZXNlbnRh dGlvbi5wb3QADQAAAEJpdG1hcCBJbWFnZQAZAAAAV2hvbGVzYWxlIFZvSVAgcHJvdmlkZXIg AA4AAABJVFNQLXRvLUlUU1AgAA4AAABIeWJyaWQgbW9kZWwgAAwQAAAIAAAAHgAAAAsAAABG b250cyBVc2VkAAMAAAABAAAAHgAAABAAAABEZXNpZ24gVGVtcGxhdGUAAwAAAAEAAAAeAAAA FQAAAEVtYmVkZGVkIE9MRSBTZXJ2ZXJzAAMAAAABAAAAHgAAAA0AAABTbGlkZSBUaXRsZXMA AwAAAAMAAAAAAJgAAAADAAAAAAAAACAAAAABAAAANgAAAAIAAAA+AAAAAQAAAAIAAAAKAAAA X1BJRF9HVUlEAAIAAADkBAAAQQAAAE4AAAB7ADIANgBEADIAMQA2ADAAMQAtAEUAOAA0ADYA LQAxADEARAA1AC0AOQBEADQAMgAtADAAMAA0ADAAQwBBADEAMgA4ADAAQgAxAH0AAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2Dx4AAAAUAAAAX8CR4zYuAQAGAPQD AwASAG1hbmpheAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA 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 AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAACAAAAAwAAAAQAAAAFAAAABgAAAAcAAAAIAAAA CQAAAP7///8LAAAADAAAAA0AAAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYA AAAXAAAAGAAAABkAAAAaAAAAGwAAABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAA JAAAACUAAAAmAAAAJwAAACgAAAApAAAAKgAAACsAAAAsAAAALQAAAC4AAAAvAAAAMAAAADEA AAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4AAAAOQAAADoAAAA7AAAAPAAAAD0AAAA+AAAA PwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYAAABHAAAASAAAAEkAAABKAAAASwAAAEwA AABNAAAATgAAAE8AAABQAAAAUQAAAFIAAABTAAAAVAAAAFUAAABWAAAAVwAAAFgAAABZAAAA WgAAAFsAAABcAAAAXQAAAF4AAABfAAAAYAAAAGEAAABiAAAAYwAAAGQAAABlAAAAZgAAAGcA AABoAAAAaQAAAGoAAABrAAAAbAAAAG0AAABuAAAAbwAAAHAAAABxAAAAcgAAAHMAAAB0AAAA dQAAAHYAAAB3AAAAeAAAAHkAAAB6AAAAewAAAHwAAAB9AAAAfgAAAH8AAACAAAAAgQAAAIIA AACDAAAAhAAAAIUAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4AAACPAAAA kAAAAJEAAACSAAAAkwAAAJQAAACVAAAAlgAAAJcAAACYAAAAmQAAAJoAAACbAAAAnAAAAJ0A AACeAAAAnwAAAKAAAAChAAAA/v///6MAAACkAAAApQAAAKYAAACnAAAAqAAAAKkAAACqAAAA qwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAAALUAAAC2AAAAtwAAALgA AAC5AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADCAAAAwwAAAMQAAADFAAAA xgAAAMcAAADIAAAAyQAAAMoAAADLAAAA/v///80AAADOAAAAzwAAANAAAADRAAAA0gAAANMA AAD+////1QAAANYAAADXAAAA2AAAANkAAADaAAAA2wAAAP7////9/////f///98AAAD+//// //////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////// //////////////////////////9SAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgAFAf//////////AwAAABCNgWSbT88R huoAqgC5KegAAAAAAAAAAAAAAAAAAAAAAAAAAP7///8AAAAAAAAAAFAAaQBjAHQAdQByAGUA cwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIB ////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAALsS AAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAABoAAgEBAAAA//////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADUAAAAABAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0A YQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAQIAAAAFAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKIAAABAUgAAAAAAAFAAbwB3AGUA cgBQAG8AaQBuAHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAoAAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA CgAAAFouAQAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIA bQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgEEAAAA//////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAADMAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP////////// /////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA --------------639CE69BEB2BB361FEB9272C-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Dec 7 03:24:28 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA16233 for ; Fri, 7 Dec 2001 03:24: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 5A14844400; Fri, 7 Dec 2001 02:12:03 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by lists.bell-labs.com (Postfix) with ESMTP id 17C6D443F9 for ; Fri, 7 Dec 2001 02:11:06 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB78Lx4I025443 for ; Fri, 7 Dec 2001 03:22:00 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 03:23:30 -0500 Message-ID: From: Jonathan Rosenberg To: "List Iptel (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C17EF8.706FD150" Subject: [IPTEL] FW: I-D ACTION:draft-ietf-iptel-cpl-05.txt,.ps Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 7 Dec 2001 03:23:24 -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_01C17EF8.706FD150 Content-Type: text/plain; charset="iso-8859-1" Folks, As you can see, an updated version of the CPL specification has been published. This incorporates the conclusion of the long-running issue (nearly a YEAR) with iCalendar integration. As you can see, the text is now based on full compliance to rfc2445, with a small exception that is a feature which will be fixed in later revisions of iCalendar itself. There are a few other substantive changes, such as language switch. Because of the scope of these changes, I'd like to initiate a new wg call on this draft, to make sure no one has any issues or further comments on the draft. So, in two weeks time from now, I will send this to iesg. I realize this overlaps with IETF, but I don't think that a review of this amongst interested participants will demand much time. Note that arguing about full compliance to iCalendar is out of scope. Thanks, Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org] Sent: Monday, December 03, 2001 8:37 AM Cc: iptel@lists.bell-labs.com Subject: I-D ACTION:draft-ietf-iptel-cpl-05.txt,.ps A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Telephony Working Group of the IETF. Title : CPL: A Language for User Control of Internet Telephony Services Author(s) : J. Lennox, H. Schulzrinne Filename : draft-ietf-iptel-cpl-05.txt,.ps Pages : 68 Date : 30-Nov-01 The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agent servers. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs. This document is a product of the IP Telephony (IPTEL) working group of the Internet Engineering Task Force. Comments are solicited and should be addressed to the working group's mailing list at iptel@lists.research.bell-labs.com and/or the authors. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-iptel-cpl-05.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-iptel-cpl-05.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-iptel-cpl-05.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_000_01C17EF8.706FD150 Content-Type: message/rfc822 To: Subject: Date: Fri, 7 Dec 2001 03:23:30 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/mixed; boundary="----_=_NextPart_002_01C17EF8.706FD150" ------_=_NextPart_002_01C17EF8.706FD150 Content-Type: text/plain ------_=_NextPart_002_01C17EF8.706FD150 Content-Type: application/octet-stream; name="ATT03257.txt" Content-Disposition: attachment; filename="ATT03257.txt" Content-type: message/external-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20011130160719.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-iptel-cpl-05.txt ------_=_NextPart_002_01C17EF8.706FD150 Content-Type: message/external-body; site="internet-drafts"; dir="draft-ietf-iptel-cpl-05.txt"; mode="ftp.ietf.org"; access-type="anon-ftp" ------_=_NextPart_002_01C17EF8.706FD150-- ------_=_NextPart_000_01C17EF8.706FD150-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Dec 7 04:44:28 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17031 for ; Fri, 7 Dec 2001 04:44: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 AE78F44402; Fri, 7 Dec 2001 03:32:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 5F51A443F9 for ; Fri, 7 Dec 2001 03:31:10 -0500 (EST) Received: from attrh2i.attrh.att.com ([135.37.94.56]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fB79hNZ13731 for ; Fri, 7 Dec 2001 04:43:28 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh2i.attrh.att.com (5.5.029) id 3C06942A001DFACD for iptel@lists.bell-labs.com; Fri, 7 Dec 2001 04:43:18 -0500 Received: from mail pickup service by occlust04evs1.ugd.att.com with Microsoft SMTPSVC; Fri, 7 Dec 2001 04:43:16 -0500 Received: from occlust02evs1.ugd.att.com ([135.71.164.9]) by occlust04evs1.ugd.att.com with Microsoft SMTPSVC(5.0.2195.2966); Wed, 5 Dec 2001 17:52:58 -0500 Received: from attrh0i.attrh.att.com ([135.37.94.54]) by njb140bh1.ems.att.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id X834WYFH; Wed, 5 Dec 2001 17:19:28 -0500 Received: from wsscan.att.com (135.38.12.5) by attrh0i.attrh.att.com (5.5.029) id 3C06930F00130875 for adilber@ems.att.com; Wed, 5 Dec 2001 17:19:28 -0500 Received: by wsscan.att.com; id RAA29191; Wed, 5 Dec 2001 17:23:16 -0600 (CST) Received: from kcmsi1.proxy.att.com(192.168.104.69) by cyrus2.wsscan.att.com via csmap (V4.1) id srcAAATHaqa5; Wed, 5 Dec 01 17:23:16 -0600 Received: from lists.bell-labs.com ([204.178.16.58]) by kcmsi1.proxy.att.com (AT&T IPNS/MSI-3.0) with ESMTP id fB5MJPd16881 for ; Wed, 5 Dec 2001 17:19: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 16BF7443AF; Wed, 5 Dec 2001 16:07:03 -0500 (EST) content-class: urn:content-classes:message MIME-Version: 1.0 Subject: [IPTEL] Negation in CPL Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: binary Message-ID: <3C0E9D28.4F03CE1F@site.uottawa.ca> X-MS-TNEF-Correlator: <3C0E9D28.4F03CE1F@site.uottawa.ca> Thread-Topic: [IPTEL] Negation in CPL Thread-Index: AcF92ue0vCADiunLEdWnAACQJ3s5nw== X-MimeOLE: Produced By Microsoft Exchange V6.0.5716.0 From: "Daniel Amyot" To: X-OriginalArrivalTime: 05 Dec 2001 22:52:58.0025 (UTC) FILETIME=[955E5190:01C17DDF] Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Wed, 5 Dec 2001 17:18:16 -0500 Content-Transfer-Encoding: binary xŸ>"äè€€Ñ  €Ñ 4B €!890320BCCBE9D511A7000090277B399F$04iptel@lists.bell-labs.com0 SMTP04iptel@lists.bell-labs.com0 @:d  0SMTP:IPTEL@LISTS.BELL-LABS.COM :4iptel@lists.bell-labs.com8*T'IPM.NOTE&670[IPTEL] Negation in CPL@9„b¼Ú}Á=p0[IPTEL] Negation in CPLqÁ}Úç´¼ ŠéËÕ§'{9Ÿ Daniel Amyot0[IPTEL] Negation in CPL ­©y LZFuÍ—X rcpg125â2CtexA÷ÿ €¤ä€óPV?U²%Qchá Àset2Ã%ö3F·0,3ï ÷¶;05" `cP3 d36P ¦ Htel°, ¢ „ €IB àve b á k €g a cÏ°À°ok0@PCPL  c ðtäly0ndP `¶u!@tà@i@:w`l 1r€ dfà" @toPÿ `!"À € €÷1l` RõÀAp PÀ%€ 4ofTr" /p'ðàs.°owÒ,"@f g$ð"$Ð#Á %Ñô (k `pu’(³yÖ)!Tau€!ôý"e! 'À !ѿС#`$.1i,Aï°"P!($ ë.Ã))€IT#$²jyl)°fÐf/Ñ1 .@0Ro`emÛ) ZF± €s!€öe)Àg €$ €(aAÀike: 5Ñww !!c@ $Röa#`¡g!À °1)¡.1T8Ã& a ZJÐq P)!T.@n=)€t"€*÷.‚$4d:µZ(0w17àa#ÂÏÐ*  ).e)0%Ð?+Q8Â;|)â"`ug”h)T<ðl> ãñ € < €'D[D9Pd -átÐE:EØ!R%"s="õ;å"Fí/FE;JfF¿JPD¾JPCÒ>_0³27àÿ!0@@A8áA„9C_?DoEw°8À@‚,rl#HÐp:r9V@hí€p"P@.'InPWþ/JìTöL¯M¿ZµAg)0ÿ&±83AQc2àP+À÷V°+ 1ñw4A$PQa]aÿ!a!@^B:¶^²!ÿ`.‘4†6)à ðW{STW""ƒq,f" ds`eÂ;Rf2+ gSU$'Ð "HV")€sûp h7£ZR¿SÏ'EïFÿHdo-ný1 -HUHßGUTÏUßVïÿv×XLvYïIÿKrÏZÿó\rRiC0@u)q9&up(°  OT€HERWISE)€übu.;a60^S$C ÿh‡*#4#'ùp-p!Ñaxï!ô3@°w4S0—]aÏ `@"€n'@i@û&‘PdE@"C.$ÞsŽk/N,' Àç+Ð@pw£s)oopqÿßs¯HOI_~_–4#ñþe{ÞwxyŸz¯{¿|Ï¿˜wšoo€N¬Ifß.‘8‚)ðp"pa`)°ÿ 0p Á9ä‘2i÷…ã–âÁ? ‘Šðt±ÿnqT*"`@„e&£mÿQÀ•Aa3)°n‚*Ðõ‘(tÎsEu)€ê.²°)¬Wf;a#`ÿð,‰"«+±-p«ð\œ»p y`KTDp» A2à1 TM"Pg·ÁÀ<ÑrkbT_ºO»_¼*µPTE pß$á(Ðnó60½9@¾r) ë€- `b) 'T5ƒ tœð/¡P¿m/ÿ½òÁc €¥Ð0T}Ä€5H<3C0E9D28.4F03CE1F@site.uottawa.ca>CpDä, Eè, òó8[IPTEL] Negation in CPL.EML ô õ ö@0 ´çÚ}Á@0…-}ß}ÁÞ?ŸNß?ÿÿÿÿñ?ø?DInternet Mail Service (NJB140BH1)ù?qܧ@ÈÀB´¹+/á‚/O=ATT/OU=EMS/CN=CONFIGURATION/CN=CONNECTIONS/CN=INTERNET MAIL CONNECTOR (NJB140BH1)ú?DInternet Mail Service (NJB140BH1)û?qܧ@ÈÀB´¹+/á‚/O=ATT/OU=EMS/CN=CONFIGURATION/CN=CONNECTIONS/CN=INTERNET MAIL CONNECTOR (NJB140BH1)ý?ÿ@@0@.damyot@site.uottawa.ca1@.damyot@site.uottawa.ca8@HINTERNET MAIL CONNECTOR (NJB140BH1)9@.damyot@site.uottawa.ca ) #$<3C0E9D28.4F03CE1F@site.uottawa.ca> ; _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Dec 7 08:31:30 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20122 for ; Fri, 7 Dec 2001 08:31: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 2201D443D9; Fri, 7 Dec 2001 07:19:03 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id C3B05443D2 for ; Fri, 7 Dec 2001 07:18:32 -0500 (EST) Received: from attrh1i.attrh.att.com ([135.71.62.10]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fB7DUvZ26672 for ; Fri, 7 Dec 2001 08:30:58 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh1i.attrh.att.com (5.5.029) id 3C0BA3A50004FA35; Fri, 7 Dec 2001 08:30:38 -0500 content-class: urn:content-classes:message Subject: RE: [IPTEL] more on iptel-gwreg-req Message-ID: <62DA45D4963FA747BA1B253E266760F9782CD1@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] more on iptel-gwreg-req Thread-Index: AcF+qQB9FNx5MuqcEdWY1QCQJ3s6pwAcEHOg X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 From: "Roy, Radhika R, ALCTA" To: , Cc: , Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 7 Dec 2001 08:30:37 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA20122 Hi, Gur: I agree with your proposal in articulating how we should develop the protocol. In fact, we have also been talking along the same line. "If a SIP call comes to a SIP proxy from a SIP user and the destination address does not reside in the SIP-based VoIP network administered by the same VoIP service provider (e.g., intra-ITAD or intra-domain), the SIP Proxy/Location server needs to find or select a GW to which the SIP call need to be sent." To solve the above problem, it is seen that a protocol is needed in the intra-ITAD (e.g., people have given a code name "Gateway Registration Protocol" or like this). I agree with you that Jonathan has done a great job in formulating the discussion for the requirements. Please see my comments provided inline [RRR]. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Gur_Kimchi@vocaltec.com [mailto:Gur_Kimchi@vocaltec.com] Sent: Thursday, December 06, 2001 5:52 PM To: iptel@lists.bell-labs.com Cc: sob@harvard.edu; jdrosen@dynamicsoft.com Subject: [IPTEL] more on iptel-gwreg-req Friends, I think some clarification on my position are in order. 1. I think Jonathan has done a great job nailing down on what the requirements are for GW registrations [RRR] I agree and, that is why, we are having discussions how the protocol needs to be developed. 2. I think in terms of model there is not such a great difference in terms of presentation between what a pstn-sip, sip-323 or sip-xyz - in all cases some basic building blocks must be communicated - and they are captured in the requirements (e.g. Media/Resource Capabilities, Termination Capabilities, and status). [RRR] You are right. That is, the requirements clearly say that the protocol should not be "hard-wired" for any particular type of GWs or addressing schemes or otherwise. It is rather Media/Resource Capabilities, Termination Capabilities, status, etc. 3. I claim the presentation of this information (the schema) and the means by which it is communicated (the protocol) are two very distinct and separate subjects. [RRR] In TRIP, the protocol has been defined. However, the presentation of the information (the schema) has not been a part of the specifications. It is a good point and let us discuss this. (BTW, in SIP, we could do this. However, SIP's registration message, as suggested by you, could allow to do this, but it needs changes in SIP.) My suggestion therefore is: A. that we define a schema, based on XML, that can be used to describe the capabilities/status of a GW, including internal "bundling" (e.g. these 23 trunks are a T1 group running PRI etc) ( I don't differentiate between the GW running out of capacity and the administrator deciding to disable G.723 because it sounds bad - or allowing +1212* while blocking +1900* - all change the presentation of the GW to the network. ) [RRR] No existing proposal uses XML-based documents. (This can be used if the protocol structure is modified.) B. that we document how this document is transmitted between network elements (SIP GWs and elements that need to know, including other SIP GWs), I see three ways here: B1: provide the document as part of REGISTER, re-REGISTER when information changes. [RRR] Both ITRP and TRIP-GW proposal allow this. (However, TRIP-GW proposal needs to be extended for other addresses like email IDs, url IDs, etc. as well. That is, it should be generic and extensible.) B2: allow the element that would like to know to SUBSCRIBE to the document, therefore getting NOTIFYied when the document changes (including a first NOTIFY with the document immediately following the SUBSCRIBE). [RRR] None of the existing proposals allow this capability unless the protocol structure is changed. B3: define protocol TRIP+-XYZ that is used to distribute these documents between elements "that need to know". [RRR] One suggestion, as I made before, has been to combine ITRP + TRIP-GW proposal. C. Define the rules by which multiple documents are aggregated (probably with hints in the schema) so border elements can provide a "digest" of what multiple elements behind them support. [RRR] It is possible to do so with the existing proposals with messages (e.g., REGISTER-like, or re-REGISTER-like messages). However, they do not use XML documents etc. Lastly - I think the work should be prioritized, giving highest priority to A, B1 and C - to solve existing deployment issues that already exist. [RRR] It is a good proposal. Now we have to see how we can achieve these objectives using the proposed protocol. The only thing is that the use of XML-based document may require a new structure of the protocol. We need to discuss this and I am open to suggestions. - gur _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Dec 7 10:26:31 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21901 for ; Fri, 7 Dec 2001 10: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 6B6084440D; Fri, 7 Dec 2001 09:14:03 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id A712E443D2 for ; Fri, 7 Dec 2001 09:13:22 -0500 (EST) Received: from gab200r1.ems.att.com ([135.37.94.32]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fB7FPOZ03885; Fri, 7 Dec 2001 10:25:27 -0500 (EST) Received: from njb140bh1.ems.att.com by gab200r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA16460; Fri, 7 Dec 2001 10:25:58 -0500 (EST) Received: by NJB140BH1 with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 10:25:22 -0500 Message-ID: <62DA45D4963FA747BA1B253E266760F96BEAC4@OCCLUST04EVS1.ugd.att.com> From: "Roy, Radhika R, ALCTA" To: "Peterson, Jon" , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] iptel-gwreg-req open issues MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 4 Dec 2001 19:34:04 -0500 Please see my comments inline [RRR]. By the way, let me also make a proposal that both ITRP and TRIP-GW draft can be combined to make it a subset of TRIP through modifications that can be used for the intra-ITAD communications. In this case, we get an excellent uniformity in protocol for both intra-ITAD and inter-ITAD [TRIP] that uses the same message formats. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Tuesday, December 04, 2001 3:04 AM To: Roy, Radhika R, ALCTA; 'iptel@lists.bell-labs.com' Subject: RE: [IPTEL] iptel-gwreg-req open issues While I don't want to comment extensively on matters that aren't in the current scope of the WG, I do agree that we need to be somewhat flexible about how we understand the term 'gateway'. [RRR] Let us discuss this in "quantitative" manner for the intra-ITAD communications. In our case, a GW provides protocol conversion between SIP and other protocol (ISUP, H.323, or BICC, etc.) and will have to deal with two important parameters: 1. (Primarily) Addresses and 2. Capacity (if applicable). For example, I think most IP PBXs could qualify as gateways - but the H.323-SIP gateway sounds like a tougher case to support. [RRR] Why do you think that SIP-H.323 GW is a tougher case to support? [RRR] The specifications and characteristics of the SIP-H.323 GW may be a sub-set than those of the SIP-ISUP GW. May be we need to add few more fields in the address space. All we need to do is use a protocol for "registration" of the GWs. I believe that IETF cannot afford to build one "registration" protocol for SIP-ISUP GW, another for SIP-H.323 GW, another for SIP-BICC GW, and so on while the same protocol can be used. That is why, all of us have agreed that the protocol needs to be extensible. As I understand it, the current restriction in WG scope is intended to prevent us from straying into subjects like service registration. [RRR] Yes, "service" registration is completely different from that of the GW registration. (BTW, if you are interested to work on service registration, let us define the scope of work of the service registration and its functional requirements. We can go from there because it has different context. I have some interest to look into it.) Perhaps we need some sharper way of defining gateways; maybe we could rely on the device having a PSTN circuit switched interface as a litmus test. [RRR] I have provided a simpler definition as stated above. We can start to iterate it from there. [RRR] (Per your suggestion, if we take SIP-ISUP GW as a litmus test, it will have the attributes like telephone addresses [only E.164 and their family] and circuit capacity [with many parameters]. A SIP-H.323 GW will have telephone addresses, email IDs, URL IDs, etc. (and may be capacity - as simple as port numbers.) I would note that if your 'gateways' are propagating information about email addresses and so forth they go beyond the capabilities I commonly associate with a gateway. [RRR] A GW provides the association of the addresses when a call comes to it and addresses are provided on the call signaling messages. So, it is the application that decides what kinds of addresses will be there and the location server (in our case) will decide which GWs the calls need to be destined for those destination addresses. So, this is a simple generalized logic. (For example, ITU-T Rec. H.225.0 Annex G can be seen how all kinds of addresses are taken care of. The draft-roy-iptel-itrp-00 can also be seen for this purpose.) I also think we agree that there is no obvious reason why the same protocol needs to be used for the discovery and registration. [RRR] It is always better to use the same protocol. If it is a problem, people need to quantify it. (I have provided contribution draft-roy-iptel-itrp-00 that uses the same protocol. Is that a problem? All I have said that we may keep the "discovery" mechanism away for the sake of making progress for now. We can use this one later either using the same protocol or different protocol.) Personally, I would be happy to solve the registration problem prior to investigating discovery - but then again, there may be an overwhelming public sentiment that these two capabilities have an equal priority or that they need to wrapped into the same protocol. [RRR] The draft-roy-iptel-itrp-00 wrap this two into the same protocol. (Personally, I do not see any problems.) If there is any reason why these two features should be tightly coupled, I for one would like to understand it. [RRR] The only reason that I see that there is a benefit to use the same protocol suit to minimize the protocol development and to make easy for implementation. [RRR] By the way, let me make a proposal that both ITRP and TRIP-GW draft can be combined to make it a subset of TRIP through modifications that can be used for the intra-ITAD communications. In this case, we get an excellent uniformity in protocol for both intra-ITAD and inter-ITAD [TRIP] that uses the same message formats. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Monday, December 03, 2001 6:09 PM > To: Peterson, Jon; 'iptel@lists.bell-labs.com' > Subject: RE: [IPTEL] iptel-gwreg-req open issues > > > Hi, Jon: > > It is a good start for discussion via emails as all of us may not > participate in the IETF-52 Salt Lake meeting. I appreciate > your thoughtful > comments. > > In fact, I am delighted to see that we are almost in full agreement. > > My comments are inline [RRR]. > > Best regards, > > Radhika R. Roy > rrroy@att.com > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Friday, November 30, 2001 3:15 PM > To: 'iptel@lists.bell-labs.com' > Subject: [IPTEL] iptel-gwreg-req open issues > > > > A few comments on the open issues listed in the draft. > > REQ 6- I think this is a real requirement. I think that in > many complex > architectures (such as ones in which MGCs are used as gateways), the > provisioning of ranges of POTS numbers associated with > gateways must be > performed in multiple locations (proxy servers and gateways, > at least) if > there is not some sort of gwreg mechanism that allows you to > provision in > one place and then automatically propagate the data to any > other systems > that need it. In my opinion, simplifying provisioning is one > of the primary > reasons to use gateway registration. If you have to substantially > pre-provision proxies then I don't think gateway registration > makes your > life that much easier. > ... > > [RRR] Yes, I agree with you because it is the intra-ITAD > environment where a > single carrier/service provider wants to AUTO-provision (not > pre-provisioned) in order to avoid error-prone and costly manual > configurations. This requires communications between the GWs > and the LSs > and, registration is one of the important items. A GW can be > a SIP-ISUP > Interworking Telephony GW (e.g., MGC - signaling entity) or a > SIP-H.323 > Interworking GW (e.g., IWF - signaling entity). > > > REQ 8- I really think the gwreg protocol should be > extensible, even if we > aren't sure how we'd like to extend it at the moment. As for > whether these > attributes are attributed to routes or gateways, I'd actually > suggest a > third alternative for consideration - trunk groups. My > carrier architecture > provides a few examples of how such dynamic data depends on > trunk groups > rather than gateways. > > [RRR] You are right and protocol MUST be flexible enough to > accommodate this > (i.e., protocol must NOT be hard-wired for a particular > thing). For example, > when we say that a GW registers addresses, the addresses can > be E.164, email > IDs, URL IDs, etc. as appropriate. > > REQ 11- I'm not sure I entirely understand either the > requirement or the > open issue here, but I'll take a stab at this. Since we're > considering gwreg > in the absence of intradomain route propagation, independent routing > policies amongst multiple proxies in an ITAD seems like an > unlikely issue to > address - any system in which there's a possibility that there are > independent proxies that could somehow be synchronized > requires something > like routing policy centralization or intradomain propagation. > > [RRR] Again, I think that you are right on this issue because > the whole > point is that it is an intra-ITAD situation and, we are NOT > considering, as > you have clarified, the intra-ITAD (or intradomain) "route > propagation." > Therefore, as you have explained, independent routing > policies among the > multiple proxies does NOT arise. > > Is the assumption here that if there are multiple proxies in > an ITAD, that > some gateways register with one proxy, and some gateways register with > another, perhaps depending on a POP at which the gateways are located? > (Also, is there a latent requirement here about the > cardinality of the roles > of gateways and proxies?) Clearly if two proxies in an ITAD do not > communicate with one another, and each gateway registers with > a single proxy > at a time (discounting failover), then I don't think it would even be > possible for two proxies to return the same decision. If > allowing something > along these lines is what this requirement signifies, then I > definitely > support it. > > [RRR] For all practical purposes, there will be multiple > proxies (/location > servers) in an ITAD and, we have to develop our protocol > keeping this very > practical situation in mind. Otherwise, the protocol will NOT > be complete > and will almost be useless because it will NOT work in a real > networking > environment where multiple proxies/location servers are a reality. > > [RRR] The other thing is that the protocol messages that will be used > between the GWs and the LSs, the same messages can also be > used among the > LSs to serve the purpose. It can be seen examining the > contributions that > have been made addressing this problem. > > On another angle of this, perhaps support for some sort of > load-balancing > should be its own requirement, since I'm not sure that's > entirely dependent > on multiple proxies - I'd suggest that a single proxy should > be capable of > returning different routes for two calls targeting the same > address if it > has received multiple gateway registrations matching the > parameters of the > call that have the same preference. Nor do I understand why a database > protocol would preclude load-balancing... > > [RRR] Yes, I agree with you. > > REQ 12- I'm not really sure why this sort of 'discovery' > would be needed. I > agree that static configurations are more likely. Also, I > envision that > either the gateway or the proxy could initiate the > connection. For the sort > of architecture I have in mind, it would make more sense to statically > configure the gateway with one or more proxies (each probably > associated > with a preference) to which the gateway would attempt to connect. > Cryptographic authentication could let the proxy guarantee that the > connection is desirable. > > [RRR] Jon, I beg to explain a little bit. Like REQ 6, as you have also > mentioned, the AUTO-discovery is helpful as opposed to static > configurations. However, as Jonathan mentioned (and we have also seen > examining the several contributions made in this area), the > full-fledged > auto-discovery may change the basic characteristics the > entire protocol and, > some may not like this. > > [RRR] I may tend to consider the auto-discovery as a separate > item from the > rest of the protocol development. For example, > unicast-schemes (as opposed > to multicast schemes) using DNS look-up may also be > considered for ease of > implementation, if it is considered that the multicast-based discovery > mechanism is problematic. > > [RRR] The bottom line is that I may agree with you and > Jonathan now, if we > agree that we will visit this issue later once we finish the > work of the > base protocol that will be used within the intra-ITAD (or intradomain) > excluding the discovery. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Dec 7 22:42:35 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA07397 for ; Fri, 7 Dec 2001 22:42: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 7E63B443FD; Fri, 7 Dec 2001 21:30:03 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by lists.bell-labs.com (Postfix) with ESMTP id 4A3F744342 for ; Fri, 7 Dec 2001 21:29:30 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB83dx4I001676; Fri, 7 Dec 2001 22:39:59 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Fri, 7 Dec 2001 22:41:30 -0500 Message-ID: From: Jonathan Rosenberg To: "'Daniel Amyot'" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] Negation in CPL MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Fri, 7 Dec 2001 22:41:26 -0500 > -----Original Message----- > From: Daniel Amyot [mailto:damyot@site.uottawa.ca] > Sent: Wednesday, December 05, 2001 5:18 PM > To: iptel@lists.bell-labs.com > Subject: [IPTEL] Negation in CPL > > > Hello, > > I have been taking a closer look at CPL recently and > concluded that it would > be difficult to create and maintain a single CPL script for a > complex set of > rules/policies. Since CPL is not a real programming language, there is a lot you can't do... Now, if I go with multiple scripts (one per > user policy) and > assume that they are ordered according to their priority > (total ordering), I > find myself facing a few other problems. The spec makes no mention of the concept of multiple scripts with differing priorities. I don't know how such a thing would work; seems like a feature interaction nightmare. How do you know which scripts are associated with each request? > Right now, CPL supports OTHERWISE, but this still creates > problems with other > rules based on Jacques that have a lower priority (the latter > won't get fired, > although they should according to the user's expectations): I don't understand. If you want a script which forwards all calls from Jacques to my cell phone, and to radiology otherwise, this is trivially done in CPL. What is the specific problem? -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Dec 8 02:42:36 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA25694 for ; Sat, 8 Dec 2001 02:42: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 499FF44416; Sat, 8 Dec 2001 01:30:03 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by lists.bell-labs.com (Postfix) with ESMTP id 936F144342 for ; Sat, 8 Dec 2001 01:29:39 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB87ee4I001972 for ; Sat, 8 Dec 2001 02:40:40 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sat, 8 Dec 2001 02:42:12 -0500 Message-ID: From: Jonathan Rosenberg To: "List Iptel (E-mail)" MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] updated agenda Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 8 Dec 2001 02:42:07 -0500 Folks, Due to an itchy trigger finger, I sent in the agenda to IETF without a list of reading materials. Below is an updated agenda that includes reading materials. IP Telephony Working Group (iptel) Tuesday, December 11 at 1415 - 1515 =================================== CHAIR: Jonathan Rosenberg AGENDA: 1. Agenda Bashing [Rosenberg] 2. CPL, TRIP Updates [Rosenberg] 5m Reading: http://search.ietf.org/internet-drafts/draft-ietf-iptel-cpl-05.txt 3. TRIP MIB [Walker] 10m Reading: http://search.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-00.txt 4. Gateway Registration Scenarios Discussion [Internet2 - hgs] 10m [Carrier - jdr] Requirements Discussion [Rosenberg] 20m Attributes Discussion [Bangalore] 10m Reading: http://search.ietf.org/internet-drafts/draft-rosenberg-iptel-gwreg-req-00.tx t http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-discovery-0 0.txt http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-registratio n-00.txt http://search.ietf.org/internet-drafts/draft-zhao-iptel-gwloc-slp-02.txt http://search.ietf.org/internet-drafts/draft-rs-trip-gw-03.txt --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Dec 8 03:50:36 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA27657 for ; Sat, 8 Dec 2001 03:50: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 BE05944342; Sat, 8 Dec 2001 02:38:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by lists.bell-labs.com (Postfix) with ESMTP id 9750644340 for ; Sat, 8 Dec 2001 02:37:06 -0500 (EST) Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fB88lU4I002074; Sat, 8 Dec 2001 03:47:30 -0500 (EST) Received: by DYN-EXCH-001.dynamicsoft.com with Internet Mail Service (5.5.2653.19) id ; Sat, 8 Dec 2001 03:49:02 -0500 Message-ID: From: Jonathan Rosenberg To: "'Gur_Kimchi@vocaltec.com'" , iptel@lists.bell-labs.com Cc: sob@harvard.edu, Jonathan Rosenberg MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Subject: [IPTEL] RE: more on iptel-gwreg-req Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 8 Dec 2001 03:48:53 -0500 > -----Original Message----- > From: Gur_Kimchi@vocaltec.com [mailto:Gur_Kimchi@vocaltec.com] > Sent: Thursday, December 06, 2001 5:52 PM > To: iptel@lists.bell-labs.com > Cc: sob@harvard.edu; jdrosen@dynamicsoft.com > Subject: more on iptel-gwreg-req > > > Friends, > > I think some clarification on my position are in order. > > 1. I think Jonathan has done a great job nailing down > on what the requirements are for GW registrations Not really, but thanks. > > 2. I think in terms of model there is not such a great > difference in terms of presentation between what a > pstn-sip, sip-323 or sip-xyz - in all cases some > basic building blocks must be communicated - and > they are captured in the requirements > (e.g. Media/Resource Capabilities, Termination > Capabilities, and status). I have no problem if the protocol happens to be flexible enough to support all sorts of gateways; separating attributes from the protocol that communicates them is generally good design and characteristic of all the proposals thusfar. However, to keep the scope reasonably contained, we are focusing on pstn-ish kinds of gateways to help us drive requirements. > > 3. I claim the presentation of this information > (the schema) and the means by which it is communicated > (the protocol) are two very distinct and separate subjects. Surely. > > My suggestion therefore is: > > A. that we define a schema, based on XML, that can be used > to describe the capabilities/status of a GW, including internal > "bundling" (e.g. these 23 trunks are a T1 group running PRI etc) Ahh, XML. Shall we launch into the endless, non-terminating, working-group-destructing debate about XML v. binary v. ASCII text now? I think not. Contributions on the kinds of data that we need to support various gateway registration scenarios is most welcome. Comments like, "we need to support the notion of trunk groups and define capacities measured in units of DS0 on such groups" are useful. Knowing the type of data you have to represent is generally the first thing you do before deciding a format, rather than the other way around. > B. that we document how this document is transmitted between > network elements (SIP GWs and elements that need to know, including > other SIP GWs), I see three ways here: > > B1: provide the document as part of REGISTER, re-REGISTER when > information changes. Well, if you used REGISTER it would not be the REGISTER I know of. The semantics that you are discussing here don't match at all. There is no update of contacts. There is no establishment of bindings. The sip group has elected to move away from pushing data in REGISTER messages. I see little reason to go back there. > > B2: allow the element that would like to know to SUBSCRIBE to the > document, therefore getting NOTIFYied when the document changes > (including a first NOTIFY with the document > immediately following > the SUBSCRIBE). I can think of a million ways to send data between X and Y. A PUB/SUB mecahnism is useful only when the identify of the set of things that wants to know is unknown to the thing which is letting people know. Seems like thats not the case here. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From ventas_canadian_resorts@yahoo.com.mx Sat Dec 8 06:41:51 2001 Received: from mail-52.axtel.net ([200.52.12.134]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28680 for ; Sat, 8 Dec 2001 06:41:51 -0500 (EST) Received: from fam_gorjoux ([200.56.72.37]) by mail-52.axtel.net with Microsoft SMTPSVC(5.5.1877.447.44); Sat, 8 Dec 2001 05:40:28 -0600 From: Relaciones Públicas To: iptel-archive@ietf.org Subject: Oportunidad de Inversión X-Mailer: Mailer Signature Reply-To: agorjoux@yahoo.com.mx Date: Sat, 8 Dec 2001 05:49:46 -0600 Mime-Version: 1.0 Content-Type: text/html; charset=us-ascii Message-ID: <02ab728401108c1ASINMYSWNT52MS@mail-52.axtel.net> Invierte tu aguinaldo y gana reinvirtiendo con los mejores dividendos Conviertete en un microempresario con la única inversión que es rentable y multifuncional. El Adventure Club de Canadian Resorts te abre las puertas del exito empresarial, ofreciendote un plan multidestino, rentable, heredable, transferible y multifuncional. Al adquirir nuestro plan obtienes 4 destinos propios en Cancún, Acapulco Diamante, Nuevo Vallarta y Casitas Veracruz zona esmeralda del golfo, con multiples diversiones con yate a tu servicio, choferes, cheff's internacionales, jardineros, mucamas, bell boy, canchas de tenis, equitación, motociclismo playero, rafting, campo de golf, basquetbol, volibol, juegos infantiles, asadores, multiples habitaciones en un destino o varios a la vez, sin limite en la capacidad de huespedes, agencia de viajes y lo más importante crédito en cada uno de los viajes, se puede usar por día, por semana o por mes. Y tu que quieres??? Que se pague sola, ponla a trabajar, puedes rentar todas las habitaciones que quieras, incluso en varios destinos a la vez, haciendola autopagable. Maravilloso y Fantastico, así es el club Adventure. La puedes usar como tus casas de playa, hacer reservaciones para que descanses los fines de semana, ya que no tienes limite de uso. Puedes invitar a quien quieras en cada ocupación y cada cual usar na habitación privada, tienes descuentos en todos los servicios de la agencia de viajes, por los mismas tarifas preferenciales de socio intercambia las semanas que desees a otros destinos en México o el Extranjero, tu decides que hacer con tu membresia. Como la puedes pagar??? Como quieras, tu dices cuanto puedes pagar mensualmente o en que tiempo la quieres pagar, el financiamiento en una ganga o si lo prefieres paga de contado con super descuentos. No estas soñando, esta es una realidad que garantizamos por escrito, si no cumplimos, pagamos la pena convencional del 50% del valor del contrato. Acercate con los profesionales y empieza a disfrutar tu aguinaldo. Concerté una cita y realice sus sueños y los de su familia o solicite mayor información. A sus órdenes Alejandro Gorjoux Concesionario Autorizado Tel. 55-43-50-69 Telbip 51-29-50-32 Cel. 044-55-25-16-64-09 Mier y Pesado 318-A Col. Del Valle México, D.F. 03100 From iptel-admin@lists.bell-labs.com Sat Dec 8 07:20:38 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA28946 for ; Sat, 8 Dec 2001 07:20: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 99BAD44340; Sat, 8 Dec 2001 06:08:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 1EA184433A for ; Sat, 8 Dec 2001 06:07:12 -0500 (EST) Received: from attrh1i.attrh.att.com ([135.71.62.10]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fB8CJgZ04215 for ; Sat, 8 Dec 2001 07:19:43 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh1i.attrh.att.com (5.5.029) id 3C0BA3A50007D54B; Sat, 8 Dec 2001 07:19:17 -0500 content-class: urn:content-classes:message Subject: RE: [IPTEL] RE: more on iptel-gwreg-req Message-ID: <62DA45D4963FA747BA1B253E266760F978327C@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] RE: more on iptel-gwreg-req X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcF/xWtyje5U3eu2EdWKOACQJ7Zb0gAGXdXw From: "Roy, Radhika R, ALCTA" To: "Jonathan Rosenberg" , , Cc: Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 8 Dec 2001 07:19:18 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id HAA28946 -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Saturday, December 08, 2001 3:49 AM To: 'Gur_Kimchi@vocaltec.com'; iptel@lists.bell-labs.com Cc: sob@harvard.edu; Jonathan Rosenberg Subject: [IPTEL] RE: more on iptel-gwreg-req Comments are inline [RRR] > > 2. I think in terms of model there is not such a great > difference in terms of presentation between what a > pstn-sip, sip-323 or sip-xyz - in all cases some > basic building blocks must be communicated - and > they are captured in the requirements > (e.g. Media/Resource Capabilities, Termination > Capabilities, and status). I have no problem if the protocol happens to be flexible enough to support all sorts of gateways; [RRR] Finally, it is a very good news that we have made an agreement that the protocol will be flexible enough to support all sorts of gateways. This must be our main focus of the protocol. Let us work and develop our protocol meeting this primary requirement without excluding any types of GWs. separating attributes from the protocol that communicates them is generally good design and characteristic of all the proposals thusfar. [RRR] I have seen a concrete proposal yet in this direction. However, to keep the scope reasonably contained, we are focusing on pstn-ish kinds of gateways to help us drive requirements. [RRR] We have provided the contribution (http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-registration-00.txt) that shows other kinds of gateways (e.g., SIP-H.323 IWF) do not need anything extra other than few fields in addresses. So, it proves that it meets scope (by the way, a PSTN-ish kinds of GWs are highly complex so far the capacity attributes are concerned - other Gas have little to do with these kinds of complexities). If anyone has any problems to include other types of gateways, let them put forward technical quantitative arguments without falling back to the subjective explanations. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com __ _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Dec 8 07:56:39 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA29159 for ; Sat, 8 Dec 2001 07:56: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 D001F44424; Sat, 8 Dec 2001 06:44:02 -0500 (EST) Delivered-To: iptel@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 CBF0044422 for ; Sat, 8 Dec 2001 06:43:13 -0500 (EST) Received: from 207.77.231.73 by smtp2.gtsgroup.com (InterScan E-Mail VirusWall NT); Sat, 08 Dec 2001 12:55:01 -0000 Received: by brubhdpnt01.gtsgroup.com with Internet Mail Service (5.5.2653.19) id ; Sat, 8 Dec 2001 13:55:01 +0100 Message-ID: From: "Agboh, Charles" To: "'Roy, Radhika R, ALCTA'" , Jonathan Rosenberg , Gur_Kimchi@vocaltec.com, iptel@lists.bell-labs.com Cc: sob@harvard.edu Subject: RE: [IPTEL] RE: more on iptel-gwreg-req MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 8 Dec 2001 13:55:00 +0100 > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Saturday, December 08, 2001 1:19 PM > To: Jonathan Rosenberg; Gur_Kimchi@vocaltec.com; > iptel@lists.bell-labs.com > Cc: sob@harvard.edu > Subject: RE: [IPTEL] RE: more on iptel-gwreg-req > > > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Saturday, December 08, 2001 3:49 AM > To: 'Gur_Kimchi@vocaltec.com'; iptel@lists.bell-labs.com > Cc: sob@harvard.edu; Jonathan Rosenberg > Subject: [IPTEL] RE: more on iptel-gwreg-req > Comments are inline [RRR] > > > > > 2. I think in terms of model there is not such a great > > difference in terms of presentation between what a > > pstn-sip, sip-323 or sip-xyz - in all cases some > > basic building blocks must be communicated - and > > they are captured in the requirements > > (e.g. Media/Resource Capabilities, Termination > > Capabilities, and status). > > I have no problem if the protocol happens to be flexible > enough to support > all sorts of gateways; > > [RRR] Finally, it is a very good news that we have made an > agreement that the protocol will be flexible enough to > support all sorts of gateways. This must be our main focus of > the protocol. Let us work and develop our protocol meeting > this primary requirement without excluding any types of GWs. > > separating attributes from the protocol that communicates > them is generally good design and characteristic of all the > proposals thusfar. > > [RRR] I have seen a concrete proposal yet in this direction. > > However, to keep the scope reasonably contained, we are > focusing on pstn-ish kinds of gateways to help us drive requirements. PSTN-ish gatweays would help start requirements. If the information about the capability of other gateway types already exist then why not use those as drivers as well (at least it would help to cover gatways in that category; i.e. SIP-Layer 5 gateways)? > [RRR] We have provided the contribution > (http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-ser ver-registration-00.txt) that shows other kinds of gateways (e.g., SIP-H.323 IWF) do not need anything extra other than few fields in addresses. So, it proves that it meets scope (by the way, a PSTN-ish kinds of GWs are highly complex so far the capacity attributes are concerned - other Gas have little to do with these kinds of complexities). If anyone has any problems to include other types of gateways, let them put forward technical quantitative arguments without falling back to the subjective explanations. -Jonathan R. --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com __ _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Dec 8 14:30:40 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02929 for ; Sat, 8 Dec 2001 14:30: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 D8AAB4433A; Sat, 8 Dec 2001 13:18:02 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from imo-r01.mx.aol.com (imo-r01.mx.aol.com [152.163.225.97]) by lists.bell-labs.com (Postfix) with ESMTP id E627E44337 for ; Sat, 8 Dec 2001 13:17:02 -0500 (EST) Received: from JustMeUnOr@aol.com by imo-r01.mx.aol.com (mail_out_v31_r1.9.) id c.92.1e8b49b0 (4239); Sat, 8 Dec 2001 14:29:31 -0500 (EST) From: JustMeUnOr@aol.com Message-ID: <92.1e8b49b0.2943c41b@aol.com> Subject: Re: [IPTEL] carrier scenario for TRIP To: manjax@cisco.com, jon.peterson@neustar.biz Cc: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_92.1e8b49b0.2943c41b_boundary" X-Mailer: AOL 6.0 for Windows US sub 10540 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 8 Dec 2001 14:29:31 EST --part1_92.1e8b49b0.2943c41b_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Im not for sure if Theese questions of mine have made it to the list, or not, and if they have, and If they've been answerd (If so, could someone please resend the responces to me?), Ive had a few email issues lately... :/ Theese were in reguards to the TRIP-GW draft that Manjunath had on the cisco FTP server Are we no longer routing on ITAD #'s, and now routing on FG-B/D CIC's?? What if someone outpulses digits to a gateway with a FG-D CIC in it, will the gateway route the call on that CIC, or will there be some type of a parameter in either the Voice G/W, or the RouteServ to implicitly deny FG-B/FG-D Dial arrounds?? Also in reguards to trunking, how will TG's be tracked on the RouteServ for traffic sculpting, and billing purposes?? --part1_92.1e8b49b0.2943c41b_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Im not for sure if Theese questions of mine have made it to the list, or not, and if they have, and If they've been answerd (If so, could someone please resend the responces to me?), Ive had a few email issues lately...   :/

Theese were in reguards to the TRIP-GW draft that Manjunath had on the cisco FTP server

Are we no longer routing on ITAD #'s, and now routing on FG-B/D CIC's??
What if someone outpulses digits to a gateway with a FG-D CIC in it, will
the gateway route the call on that CIC, or will there be some type of a
parameter in either the Voice G/W, or the RouteServ to implicitly deny
FG-B/FG-D Dial arrounds??

Also in reguards to trunking, how will TG's be tracked on the RouteServ for
traffic sculpting, and billing purposes??
--part1_92.1e8b49b0.2943c41b_boundary-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Dec 8 14:38:39 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03002 for ; Sat, 8 Dec 2001 14:38: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 EAD464442A; Sat, 8 Dec 2001 13:26:01 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from imo-r03.mx.aol.com (imo-r03.mx.aol.com [152.163.225.99]) by lists.bell-labs.com (Postfix) with ESMTP id 69D1644429 for ; Sat, 8 Dec 2001 13:25:53 -0500 (EST) Received: from JustMeUnOr@aol.com by imo-r03.mx.aol.com (mail_out_v31_r1.9.) id r.14.1ef4e576 (4239); Sat, 8 Dec 2001 14:38:12 -0500 (EST) From: JustMeUnOr@aol.com Message-ID: <14.1ef4e576.2943c62c@aol.com> Subject: Re: [IPTEL] RE: more on iptel-gwreg-req To: jdrosen@dynamicsoft.com, Gur_Kimchi@vocaltec.com, iptel@lists.bell-labs.com Cc: sob@harvard.edu MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_14.1ef4e576.2943c62c_boundary" X-Mailer: AOL 6.0 for Windows US sub 10540 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 8 Dec 2001 14:38:20 EST --part1_14.1ef4e576.2943c62c_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Not for sure if this is the place to pose this question or not, but since this kinda has to do with gateway regestration, I figure why not... With the induction of multiple manufacturers Voice GW's into (a) carrier's network, is there a linearity somewhere either in a RFC somewhere for VoIP, or is there a record formatting contingency in whichever RouteServ a carrier uses, or is this yet to be deceided... AMA Records (and the collection thereof from G/W's, and/or LocServ's), Call completion codes (and the completion of G/W's Onnet SIP Vs. Offnet TRIP) or in general just anything that would have to do with CDR's?? --part1_14.1ef4e576.2943c62c_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Not for sure if this is the place to pose this question or not, but since this kinda has to do with gateway regestration, I figure why not...

With the induction of multiple manufacturers Voice GW's into (a) carrier's network, is there a linearity somewhere either in a RFC somewhere for VoIP, or is there a record formatting contingency in whichever RouteServ a carrier uses, or is this yet to be deceided...

AMA Records (and the collection thereof from G/W's, and/or LocServ's), Call completion codes (and the completion of G/W's Onnet SIP Vs. Offnet TRIP) or in general just anything that would have to do with CDR's?? --part1_14.1ef4e576.2943c62c_boundary-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Dec 8 23:23:43 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA10739 for ; Sat, 8 Dec 2001 23:23: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 88AD34433B; Sat, 8 Dec 2001 22:11:03 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by lists.bell-labs.com (Postfix) with ESMTP id 3D47044337 for ; Sat, 8 Dec 2001 22:10:03 -0500 (EST) Received: from attrh2i.attrh.att.com ([135.37.94.56]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fB94JsW13865 for ; Sat, 8 Dec 2001 23:19:55 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh2i.attrh.att.com (5.5.029) id 3C06942A00285957; Sat, 8 Dec 2001 18:39:06 -0500 Subject: RE: [IPTEL] carrier scenario for TRIP Message-ID: <62DA45D4963FA747BA1B253E266760F97832A3@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] carrier scenario for TRIP Thread-Index: AcGAHtg1VDfM1+wOEdWjbgCQJ60IGQAHdKyQ content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 From: "Roy, Radhika R, ALCTA" To: , , Cc: Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 8 Dec 2001 18:39:04 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA10739 Comments are inline [RRR]. You have made a very important point. I have expanded this point seeing the big danger in the future. -----Original Message----- From: JustMeUnOr@aol.com [mailto:JustMeUnOr@aol.com] Sent: Saturday, December 08, 2001 2:30 PM To: manjax@cisco.com; jon.peterson@neustar.biz Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] carrier scenario for TRIP Im not for sure if Theese questions of mine have made it to the list, or not, and if they have, and If they've been answerd (If so, could someone please resend the responces to me?), Ive had a few email issues lately... :/ Theese were in reguards to the TRIP-GW draft that Manjunath had on the cisco FTP server Are we no longer routing on ITAD #'s, and now routing on FG-B/D CIC's?? [Roy, Radhika R, ALARC] I believe that we need to have ITAD #'s as well to be consistent with the (inter-ITAD) TRIP. We just cannot arbitrarily propose that we will NOT use it. Otherwise it will create a big hole because the whole situation is concerned about a given ITAD. [Roy, Radhika R, ALARC] There are other important issues what I have provided in my earlier email with this proposed protocol. If people want to use a short-cut in the name of so-called "Gateway Registration," we have to pay a heavy price because of INCOMPLETENESS for the sake of so-called "SIMPLICITY." [Roy, Radhika R, ALARC] We need to look into it very carefully for the whole protocol that will be used in an ITAD. In an ITAD, there will not only be many GWs, there will be many types of GWs as well (e.g., SIP-ISUP, SIP-H.323, SIP-BICC, etc.). In addition, there will be many SIP Proxies/Location Servers. [Roy, Radhika R, ALARC] People must NOT be forced to use the so-called I-TRIP between the SIP Proxies/Location Servers as it as been casually been mentioned in the (inter-ITAD) TRIP protocol. TRIP had no "mandate" or "charter" to develop the protocol for the "intra-ITAD" or "intra-Domain." I-TRIP has been mentioned as a place holder in that spec just, by the way, to show how a subset of TRIP can be used within an ITAD. We have accepted this example on "good faith," but NOT as the "standardized" protocol that will be used in an ITAD. The use of I-TRIP in an ITAD is very inefficient as we have analyzed in our contribution (http://www.ietf.org/internet-drafts/draft-roy-iptel-itrp-00.txt) and, if the protocol for communications among the location servers in an ITAD is not standardized, people will be forced to use the so-called "inefficient" I-TRIP protocol. This may be trap. What if someone outpulses digits to a gateway with a FG-D CIC in it, will the gateway route the call on that CIC, or will there be some type of a parameter in either the Voice G/W, or the RouteServ to implicitly deny FG-B/FG-D Dial arrounds?? Also in reguards to trunking, how will TG's be tracked on the RouteServ for traffic sculpting, and billing purposes?? _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Dec 8 23:47:43 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA11359 for ; Sat, 8 Dec 2001 23:47: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 836D54434E; Sat, 8 Dec 2001 22:35:03 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by lists.bell-labs.com (Postfix) with ESMTP id 45B8244337 for ; Sat, 8 Dec 2001 22:34:19 -0500 (EST) Received: from attrh2i.attrh.att.com ([135.37.94.56]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fB94kuW01287 for ; Sat, 8 Dec 2001 23:46:56 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh2i.attrh.att.com (5.5.029) id 3C06942A002808B0 for iptel@lists.bell-labs.com; Sat, 8 Dec 2001 17:45:39 -0500 Subject: RE: [IPTEL] updated agenda Message-ID: <62DA45D4963FA747BA1B253E266760F978329B@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] updated agenda content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcF/u+ylf0UIcOurEdWjbgCQJ60IGQAfPivw From: "Roy, Radhika R, ALCTA" To: "List Iptel (E-mail)" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Sat, 8 Dec 2001 17:45:37 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id XAA11359 Hi, Everyone: I am providing the description of the VGs that have been submitted for the upcoming IETF-52 IPTEL meeting. As many of us including myself will not be able to attend the meeting, I am providing this information for your review and comments (URLs for I-Ds can be found below [in agenda]): A. Discovery Protocol (draft-roy-iptel-gw-server-discovery-00.txt) VG #1: Discovery protocol characteristics (draft-roy-iptel-gw-server-discovery-00.txt): * Provides semantics for discovery for all types of GWs and SIP Server/LS with following attributes - Alternate Peers, Capability Negotiations, and others * Syntax of the protocol - Can be defined as appropriate, for example: - TRIP format and messages with some minor or no modifications - A new format and messages as appropriate * Can provide discovery using either multicast or unicast - Unicast method is used as an alternative with especial DNS-look up procedures if multicast is not used * Can be used for server-to-server communications for the intra-ITAD VG #2: Issues with other proposed protocol: * TRIP-GW (draft-rs-trip-gw-03.txt) - Not extensible for "Discovery" mechanisms as the protocol is "hard-wired" for a given mechanism * SLP (draft-zhao-iptel-gwloc-slp-02.txt) - Not optimized for "Discovery" of limited number (3 or so) of attributes like "SIP-ISUP GW," "SIP-H.323 GW," and "SIP-BICC GW" that are needed in an ITAD - Only optimized for "Discovery" of services where 100s or 1000s of services need advertised for discovery - Requires to implement the whole complex set of SLP protocol that has little or no relevance in the intra-ITAD - Cannot use TRIP format and messages sets, if needed * Server and Registration Protocol (draft-roy-iptel-gw-server-discovery-00.txt) - Optimized to be used in an ITAD and does NOT have any issues as mentioned above for TRIP-GW and SLP protocol B. Registration Protocol (draft-roy-iptel-gw-server-registration-00.txt) VG # 1: Characteristics of Registration Protocol (draft-roy-iptel-gw-server-registration-00.txt) * Provides semantics for registration for all types of GWs and SIP Server/LS with following attributes - Addresses [e.g., Telephone numbers, Email Ids, URL Ids], Alternate Peers, Registration Time, Registration Time Extension, Alternate GW, capability negotiations, Capacity/Performance, Registration Cancellation, and others * Can use any transport protocol (e.g., TCP, UDP) * Syntax of the protocol - Can be defined as appropriate, for example: ->TRIP format and messages with some minor or no modifications -> A new format and messages as appropriate * Same protocol can be used for server-to-server communications within an ITAD VG #2: Issues with other Proposed Protocols * TRIP-GW (draft-rs-trip-gw-03.txt) - Not generalized enough that can be used by other gateways other than the SIP-ISUP gateway - Does not provide any attributes for addresses like email Ids, URL Ids, etc. that may be needed by gateways like SIP-H.323 and others - Uses TRIP's complex message format - Inefficient as it mandates to use TCP as the only transport - Not extensible for "Discovery" mechanisms as the protocol is "hard-wired" for a given mechanism - Inefficient or difficult to use for the server-to-server communications in an ITAD, if needed, as if the protocol is "hardwired" for a given environment - Only optimized for the SIP-ISUP Gateway and will also force, indirectly, to use inefficient I-TRIP protocol for the intra-ITAD communications TRIP protocol (hence violates the spirit of the charter) * SLP (draft-zhao-iptel-gwloc-slp-02.txt) - Only optimized for "Discovery" of services where 100s or 1000s of services need advertised for discovery - Optimized to REGISTER attributes that differentiate one service from another and not designed to transfer data related to each service - Only limited number (3 or so) of services attributes like "SIP-ISUP GW," "SIP-H.323 GW," and "SIP-BICC GW" are needed in an ITAD, but a huge amount of data needs to be transferred for each GW service - Requires to implement the whole complex set of SLP protocol that has little or no relevance in an ITAD - Cannot use TRIP format and messages sets, if needed * Server and Registration Protocol (draft-roy-iptel-gw-server-registration-00.txt) - Optimized to be used in an ITAD and does NOT have any issues as mentioned above for TRIP-GW and SLP protocol Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Saturday, December 08, 2001 2:42 AM To: List Iptel (E-mail) Subject: [IPTEL] updated agenda Folks, Due to an itchy trigger finger, I sent in the agenda to IETF without a list of reading materials. Below is an updated agenda that includes reading materials. IP Telephony Working Group (iptel) Tuesday, December 11 at 1415 - 1515 =================================== CHAIR: Jonathan Rosenberg AGENDA: 1. Agenda Bashing [Rosenberg] 2. CPL, TRIP Updates [Rosenberg] 5m Reading: http://search.ietf.org/internet-drafts/draft-ietf-iptel-cpl-05.txt 3. TRIP MIB [Walker] 10m Reading: http://search.ietf.org/internet-drafts/draft-ietf-iptel-trip-mib-00.txt 4. Gateway Registration Scenarios Discussion [Internet2 - hgs] 10m [Carrier - jdr] Requirements Discussion [Rosenberg] 20m Attributes Discussion [Bangalore] 10m Reading: http://search.ietf.org/internet-drafts/draft-rosenberg-iptel-gwreg-req-00.tx t http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-discovery-0 0.txt http://search.ietf.org/internet-drafts/draft-roy-iptel-gw-server-registratio n-00.txt http://search.ietf.org/internet-drafts/draft-zhao-iptel-gwloc-slp-02.txt http://search.ietf.org/internet-drafts/draft-rs-trip-gw-03.txt --- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Dec 9 12:08:49 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02275 for ; Sun, 9 Dec 2001 12:08: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 0DC4E4434F; Sun, 9 Dec 2001 10:56:06 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from ckmso1.proxy.att.com (ckmso1.att.com [12.20.58.69]) by lists.bell-labs.com (Postfix) with ESMTP id 6666E44337 for ; Sun, 9 Dec 2001 10:55:35 -0500 (EST) Received: from attrh2i.attrh.att.com ([135.37.94.56]) by ckmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fB9H8CZ18575 for ; Sun, 9 Dec 2001 12:08:12 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.13) by attrh2i.attrh.att.com (5.5.029) id 3C06942A002B4E8C; Sun, 9 Dec 2001 12:07:50 -0500 content-class: urn:content-classes:message Subject: RE: [IPTEL] iptel-gwreg-req open issues Message-ID: <62DA45D4963FA747BA1B253E266760F96BEAC4@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] iptel-gwreg-req open issues X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcF8mgHJDxAXCuiJEdWY1QCQJ3s6pwAgNwWw From: "Roy, Radhika R, ALCTA" To: "Peterson, Jon" , Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Tue, 4 Dec 2001 19:34:04 -0500 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id MAA02275 Please see my comments inline [RRR]. By the way, let me also make a proposal that both ITRP and TRIP-GW draft can be combined to make it a subset of TRIP through modifications that can be used for the intra-ITAD communications. In this case, we get an excellent uniformity in protocol for both intra-ITAD and inter-ITAD [TRIP] that uses the same message formats. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Tuesday, December 04, 2001 3:04 AM To: Roy, Radhika R, ALCTA; 'iptel@lists.bell-labs.com' Subject: RE: [IPTEL] iptel-gwreg-req open issues While I don't want to comment extensively on matters that aren't in the current scope of the WG, I do agree that we need to be somewhat flexible about how we understand the term 'gateway'. [RRR] Let us discuss this in "quantitative" manner for the intra-ITAD communications. In our case, a GW provides protocol conversion between SIP and other protocol (ISUP, H.323, or BICC, etc.) and will have to deal with two important parameters: 1. (Primarily) Addresses and 2. Capacity (if applicable). For example, I think most IP PBXs could qualify as gateways - but the H.323-SIP gateway sounds like a tougher case to support. [RRR] Why do you think that SIP-H.323 GW is a tougher case to support? [RRR] The specifications and characteristics of the SIP-H.323 GW may be a sub-set than those of the SIP-ISUP GW. May be we need to add few more fields in the address space. All we need to do is use a protocol for "registration" of the GWs. I believe that IETF cannot afford to build one "registration" protocol for SIP-ISUP GW, another for SIP-H.323 GW, another for SIP-BICC GW, and so on while the same protocol can be used. That is why, all of us have agreed that the protocol needs to be extensible. As I understand it, the current restriction in WG scope is intended to prevent us from straying into subjects like service registration. [RRR] Yes, "service" registration is completely different from that of the GW registration. (BTW, if you are interested to work on service registration, let us define the scope of work of the service registration and its functional requirements. We can go from there because it has different context. I have some interest to look into it.) Perhaps we need some sharper way of defining gateways; maybe we could rely on the device having a PSTN circuit switched interface as a litmus test. [RRR] I have provided a simpler definition as stated above. We can start to iterate it from there. [RRR] (Per your suggestion, if we take SIP-ISUP GW as a litmus test, it will have the attributes like telephone addresses [only E.164 and their family] and circuit capacity [with many parameters]. A SIP-H.323 GW will have telephone addresses, email IDs, URL IDs, etc. (and may be capacity - as simple as port numbers.) I would note that if your 'gateways' are propagating information about email addresses and so forth they go beyond the capabilities I commonly associate with a gateway. [RRR] A GW provides the association of the addresses when a call comes to it and addresses are provided on the call signaling messages. So, it is the application that decides what kinds of addresses will be there and the location server (in our case) will decide which GWs the calls need to be destined for those destination addresses. So, this is a simple generalized logic. (For example, ITU-T Rec. H.225.0 Annex G can be seen how all kinds of addresses are taken care of. The draft-roy-iptel-itrp-00 can also be seen for this purpose.) I also think we agree that there is no obvious reason why the same protocol needs to be used for the discovery and registration. [RRR] It is always better to use the same protocol. If it is a problem, people need to quantify it. (I have provided contribution draft-roy-iptel-itrp-00 that uses the same protocol. Is that a problem? All I have said that we may keep the "discovery" mechanism away for the sake of making progress for now. We can use this one later either using the same protocol or different protocol.) Personally, I would be happy to solve the registration problem prior to investigating discovery - but then again, there may be an overwhelming public sentiment that these two capabilities have an equal priority or that they need to wrapped into the same protocol. [RRR] The draft-roy-iptel-itrp-00 wrap this two into the same protocol. (Personally, I do not see any problems.) If there is any reason why these two features should be tightly coupled, I for one would like to understand it. [RRR] The only reason that I see that there is a benefit to use the same protocol suit to minimize the protocol development and to make easy for implementation. [RRR] By the way, let me make a proposal that both ITRP and TRIP-GW draft can be combined to make it a subset of TRIP through modifications that can be used for the intra-ITAD communications. In this case, we get an excellent uniformity in protocol for both intra-ITAD and inter-ITAD [TRIP] that uses the same message formats. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Monday, December 03, 2001 6:09 PM > To: Peterson, Jon; 'iptel@lists.bell-labs.com' > Subject: RE: [IPTEL] iptel-gwreg-req open issues > > > Hi, Jon: > > It is a good start for discussion via emails as all of us may not > participate in the IETF-52 Salt Lake meeting. I appreciate > your thoughtful > comments. > > In fact, I am delighted to see that we are almost in full agreement. > > My comments are inline [RRR]. > > Best regards, > > Radhika R. Roy > rrroy@att.com > > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Friday, November 30, 2001 3:15 PM > To: 'iptel@lists.bell-labs.com' > Subject: [IPTEL] iptel-gwreg-req open issues > > > > A few comments on the open issues listed in the draft. > > REQ 6- I think this is a real requirement. I think that in > many complex > architectures (such as ones in which MGCs are used as gateways), the > provisioning of ranges of POTS numbers associated with > gateways must be > performed in multiple locations (proxy servers and gateways, > at least) if > there is not some sort of gwreg mechanism that allows you to > provision in > one place and then automatically propagate the data to any > other systems > that need it. In my opinion, simplifying provisioning is one > of the primary > reasons to use gateway registration. If you have to substantially > pre-provision proxies then I don't think gateway registration > makes your > life that much easier. > ... > > [RRR] Yes, I agree with you because it is the intra-ITAD > environment where a > single carrier/service provider wants to AUTO-provision (not > pre-provisioned) in order to avoid error-prone and costly manual > configurations. This requires communications between the GWs > and the LSs > and, registration is one of the important items. A GW can be > a SIP-ISUP > Interworking Telephony GW (e.g., MGC - signaling entity) or a > SIP-H.323 > Interworking GW (e.g., IWF - signaling entity). > > > REQ 8- I really think the gwreg protocol should be > extensible, even if we > aren't sure how we'd like to extend it at the moment. As for > whether these > attributes are attributed to routes or gateways, I'd actually > suggest a > third alternative for consideration - trunk groups. My > carrier architecture > provides a few examples of how such dynamic data depends on > trunk groups > rather than gateways. > > [RRR] You are right and protocol MUST be flexible enough to > accommodate this > (i.e., protocol must NOT be hard-wired for a particular > thing). For example, > when we say that a GW registers addresses, the addresses can > be E.164, email > IDs, URL IDs, etc. as appropriate. > > REQ 11- I'm not sure I entirely understand either the > requirement or the > open issue here, but I'll take a stab at this. Since we're > considering gwreg > in the absence of intradomain route propagation, independent routing > policies amongst multiple proxies in an ITAD seems like an > unlikely issue to > address - any system in which there's a possibility that there are > independent proxies that could somehow be synchronized > requires something > like routing policy centralization or intradomain propagation. > > [RRR] Again, I think that you are right on this issue because > the whole > point is that it is an intra-ITAD situation and, we are NOT > considering, as > you have clarified, the intra-ITAD (or intradomain) "route > propagation." > Therefore, as you have explained, independent routing > policies among the > multiple proxies does NOT arise. > > Is the assumption here that if there are multiple proxies in > an ITAD, that > some gateways register with one proxy, and some gateways register with > another, perhaps depending on a POP at which the gateways are located? > (Also, is there a latent requirement here about the > cardinality of the roles > of gateways and proxies?) Clearly if two proxies in an ITAD do not > communicate with one another, and each gateway registers with > a single proxy > at a time (discounting failover), then I don't think it would even be > possible for two proxies to return the same decision. If > allowing something > along these lines is what this requirement signifies, then I > definitely > support it. > > [RRR] For all practical purposes, there will be multiple > proxies (/location > servers) in an ITAD and, we have to develop our protocol > keeping this very > practical situation in mind. Otherwise, the protocol will NOT > be complete > and will almost be useless because it will NOT work in a real > networking > environment where multiple proxies/location servers are a reality. > > [RRR] The other thing is that the protocol messages that will be used > between the GWs and the LSs, the same messages can also be > used among the > LSs to serve the purpose. It can be seen examining the > contributions that > have been made addressing this problem. > > On another angle of this, perhaps support for some sort of > load-balancing > should be its own requirement, since I'm not sure that's > entirely dependent > on multiple proxies - I'd suggest that a single proxy should > be capable of > returning different routes for two calls targeting the same > address if it > has received multiple gateway registrations matching the > parameters of the > call that have the same preference. Nor do I understand why a database > protocol would preclude load-balancing... > > [RRR] Yes, I agree with you. > > REQ 12- I'm not really sure why this sort of 'discovery' > would be needed. I > agree that static configurations are more likely. Also, I > envision that > either the gateway or the proxy could initiate the > connection. For the sort > of architecture I have in mind, it would make more sense to statically > configure the gateway with one or more proxies (each probably > associated > with a preference) to which the gateway would attempt to connect. > Cryptographic authentication could let the proxy guarantee that the > connection is desirable. > > [RRR] Jon, I beg to explain a little bit. Like REQ 6, as you have also > mentioned, the AUTO-discovery is helpful as opposed to static > configurations. However, as Jonathan mentioned (and we have also seen > examining the several contributions made in this area), the > full-fledged > auto-discovery may change the basic characteristics the > entire protocol and, > some may not like this. > > [RRR] I may tend to consider the auto-discovery as a separate > item from the > rest of the protocol development. For example, > unicast-schemes (as opposed > to multicast schemes) using DNS look-up may also be > considered for ease of > implementation, if it is considered that the multicast-based discovery > mechanism is problematic. > > [RRR] The bottom line is that I may agree with you and > Jonathan now, if we > agree that we will visit this issue later once we finish the > work of the > base protocol that will be used within the intra-ITAD (or intradomain) > excluding the discovery. > > Jon Peterson > NeuStar, Inc. > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 10 08:33:54 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA01617 for ; Mon, 10 Dec 2001 08:33: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 735664435D; Mon, 10 Dec 2001 07:21:02 -0500 (EST) Delivered-To: iptel@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 73EB644356 for ; Mon, 10 Dec 2001 07:20:25 -0500 (EST) Received: from oleane (upper-side.rain.fr [194.250.212.114]) by smtp4.cluster.oleane.net with SMTP id fBADXFt43788 for ; Mon, 10 Dec 2001 14:33:15 +0100 (CET) Message-ID: <004501c1817f$0e1a0320$0601a8c0@oleane.com> From: "Peter Lewis" To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0042_01C18187.6F582420" 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: [IPTEL] The third annual MGC (Media Gateway Control) 2002 Conference Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 10 Dec 2001 14:32:03 +0100 This is a multi-part message in MIME format. ------=_NextPart_000_0042_01C18187.6F582420 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable The third annual MGC (Media Gateway Control) 2002 Conference, scheduled = to take place next May 21 to 24 in Paris, will serve as an occasion for operators, cable operators, = standardization bodies and vendors to bring accurate technical answers = to these questions.=20 The Conference program will be articulated around four major themes:=20 A) MGC and softswitch architectures=20 B) MGCP and voice over cable=20 C) MGCP versus H.248?=20 D) Interworking with Voice over IP protocols=20 A call for papers is online at: http://www.upperside.fr/mgcp2002/mgcp2002intro.htm ------=_NextPart_000_0042_01C18187.6F582420 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
The third annual MGC (Media = Gateway=20 Control) 2002 Conference, scheduled to take place next May 21 to 24
in Paris, will=20 serve as an occasion for operators, cable operators, standardization = bodies and=20 vendors to bring accurate technical answers to these questions. =
The Conference program will be articulated around four = major=20 themes:
A) MGC and softswitch architectures
B) MGCP and voice = over cable=20
C) MGCP versus H.248?
D) Interworking with Voice over IP = protocols=20
 
A call for papers is online at:
http://www.up= perside.fr/mgcp2002/mgcp2002intro.htm
 
------=_NextPart_000_0042_01C18187.6F582420-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 10 09:59:53 2001 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02765 for ; Mon, 10 Dec 2001 09:59:53 -0500 (EST) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A696144356; Mon, 10 Dec 2001 08:47:02 -0500 (EST) Delivered-To: iptel@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 3D92544338 for ; Mon, 10 Dec 2001 08:46:49 -0500 (EST) Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBAEtkV21918; Mon, 10 Dec 2001 06:55:46 -0800 (PST) Received: from oranlt (sjc-vpn1-469.cisco.com [10.21.97.213]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ABP38161; Mon, 10 Dec 2001 06:55:51 -0800 (PST) From: "David R. Oran" To: "'Roy, Radhika R, ALCTA'" , "'Jonathan Rosenberg'" , , Cc: Subject: RE: [IPTEL] RE: more on iptel-gwreg-req Organization: Cisco Systems Message-ID: <000201c1818a$2f628420$b4c8830c@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <62DA45D4963FA747BA1B253E266760F978327C@OCCLUST04EVS1.ugd.att.com> Importance: Normal Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0beta6 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: http://lists.bell-labs.com/pipermail/iptel/ Date: Mon, 10 Dec 2001 09:51:34 -0500 Content-Transfer-Encoding: 7bit > -----Original Message----- > From: iptel-admin@lists.bell-labs.com > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Roy, > Radhika R, ALCTA > Sent: Saturday, December 08, 2001 7:19 AM > To: Jonathan Rosenberg; Gur_Kimchi@vocaltec.com; > iptel@lists.bell-labs.com > Cc: sob@harvard.edu > Subject: RE: [IPTEL] RE: more on iptel-gwreg-req > > > > > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Saturday, December 08, 2001 3:49 AM > To: 'Gur_Kimchi@vocaltec.com'; iptel@lists.bell-labs.com > Cc: sob@harvard.edu; Jonathan Rosenberg > Subject: [IPTEL] RE: more on iptel-gwreg-req > Comments are inline [RRR] > > > > > 2. I think in terms of model there is not such a great > difference in > > terms of presentation between what a pstn-sip, sip-323 or > sip-xyz - in > > all cases some basic building blocks must be communicated - and > > they are captured in the requirements > > (e.g. Media/Resource Capabilities, Termination > > Capabilities, and status). > > I have no problem if the protocol happens to be flexible > enough to support all sorts of gateways; > > [RRR] Finally, it is a very good news that we have made an > agreement that the protocol will be flexible enough to > support all sorts of gateways. This must be our main focus of > the protocol. Let us work and develop our protocol meeting > this primary requirement without excluding any types of GWs. > Actually, this is *not* how I read what Jonathan wrote. I interpret his suggestion that we not make flexibility across any kind of gateway a goal for the protocol (where do you stop?), but rather that he would not find it objectionable if such flexibility happened to fall out of a design optimized for straightforward PSTN gateways. On this point I am inclined to agree with Jonathan. To try to deal with IP-IP Protocol conversions boxes like SIP<->H323 we would be treading into very dangerous water, IMHO. Not only does this introduce the possibility of combinatoric explosion of routing information (i.e. the need to represent routes for each combination of protocol P and protocol Q for all values of P and Q), but if you actually want to make use of this information it also leads inexorably to a route computation which is equivalent to solving boolean satisfiability problems (e.g.find me the best route by between two gateways which minimizes administrative cost and number of protocol conversions in between). Beyond this, there are two further dangers: - creeping into representing which PSTN signaling protocols a gateway supports in order to be sure that you don't lose features when crossing into the PSTN (e.g. prefer an ISUP speaker to a Q.931 speaker, and I'd really like Q.Sig while I'm at it). - creeping into trying to solve most if not all of the middlebox control problem. Dave. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Dec 13 14:40:33 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28024 for ; Thu, 13 Dec 2001 14:40:33 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBDJcG001008; Thu, 13 Dec 2001 14:38:16 -0500 Received: from Mitel.COM ([216.191.234.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBDJbA000980 for ; Thu, 13 Dec 2001 14:37:10 -0500 Received: from Software.Mitel.COM (software [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id KAA13941; Tue, 11 Dec 2001 10:11:57 -0500 (EST) Received: from site.uottawa.ca ([134.199.40.54]) by Software.Mitel.COM (V8/MAIL-HUB-2.0) with ESMTP id KAA23497; Tue, 11 Dec 2001 10:11:56 -0500 (EST) Message-ID: <3C16223C.CE9EDA06@site.uottawa.ca> From: Daniel Amyot Organization: Mitel Corporation X-Mailer: Mozilla 4.74 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg CC: iptel@lists.bell-labs.com Subject: Re: [IPTEL] Negation in CPL References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 11 Dec 2001 10:11:56 -0500 Content-Transfer-Encoding: 7bit Hello, Jonathan Rosenberg wrote: > Now, if I go with multiple scripts (one per > > user policy) and > > assume that they are ordered according to their priority > > (total ordering), I > > find myself facing a few other problems. > > The spec makes no mention of the concept of multiple scripts with differing > priorities. I don't know how such a thing would work; seems like a feature > interaction nightmare. How do you know which scripts are associated with > each request? Indeed, having multiple scripts is not an option discussed in the standard, and it causes interaction problems. However, the issue with a single CPL script is one of usability and maintenance. It is difficult for a user to add/remove individual policies from a single script where existing policies are tightly integrated together. But thinking more about it, this is probably more of a UI or front-end problem than a problem with CPL itself. Thanks, Daniel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Dec 13 14:53:29 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28221 for ; Thu, 13 Dec 2001 14:53:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBDJr4001347; Thu, 13 Dec 2001 14:53:04 -0500 Received: from sj-msg-core-1.cisco.com (sj-msg-core-1.cisco.com [171.71.163.11]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBDJn2001241 for ; Thu, 13 Dec 2001 14:49:03 -0500 Received: from mira-sjc5-9.cisco.com (mira-sjc5-9.cisco.com [171.71.163.32]) by sj-msg-core-1.cisco.com (8.11.3/8.9.1) with ESMTP id fBAG1vV18281; Mon, 10 Dec 2001 08:01:57 -0800 (PST) Received: from oranlt (sjc-vpn3-538.cisco.com [10.21.66.26]) by mira-sjc5-9.cisco.com (Mirapoint) with ESMTP id ABP38945; Mon, 10 Dec 2001 08:02:01 -0800 (PST) From: "David R. Oran" To: "'Roy, Radhika R, ALCTA'" , "'Jonathan Rosenberg'" , , Cc: Subject: RE: [IPTEL] RE: more on iptel-gwreg-req Organization: Cisco Systems Message-ID: <004101c18193$6df01230$b4c8830c@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3311 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <62DA45D4963FA747BA1B253E266760F9783516@OCCLUST04EVS1.ugd.att.com> Importance: Normal Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 10 Dec 2001 10:57:53 -0500 Content-Transfer-Encoding: 7bit OK, I'm now lost. I thought we were designing a registration protocol that allows the routing system to DO SOMETHING with the data. If not, then we could use just about any extensible AVP-based description scheme and not worry about the semantics of the data. Hell, we could even register the color of the cable sockets so that you could route from yellow to yellow. The unstated point behind my note (unstated because I thought it was too obvious to bother stating) was that anything we registered in the GW registration protocol had to have a reasonable projection into at least the intra-ITAD routing scheme. If I'm wrong here, I apologize. Dave. > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Monday, December 10, 2001 10:34 AM > To: David R. Oran; Jonathan Rosenberg; > Gur_Kimchi@vocaltec.com; iptel@lists.bell-labs.com > Cc: sob@harvard.edu > Subject: RE: [IPTEL] RE: more on iptel-gwreg-req > > > > > -----Original Message----- > From: David R. Oran [mailto:oran@cisco.com] > Sent: Monday, December 10, 2001 9:52 AM > To: Roy, Radhika R, ALCTA; 'Jonathan Rosenberg'; > Gur_Kimchi@vocaltec.com; iptel@lists.bell-labs.com > Cc: sob@harvard.edu > Subject: RE: [IPTEL] RE: more on iptel-gwreg-req > > > > -----Original Message----- > > From: iptel-admin@lists.bell-labs.com > > [mailto:iptel-admin@lists.bell-labs.com] On Behalf Of Roy, > > Radhika R, ALCTA > > Sent: Saturday, December 08, 2001 7:19 AM > > To: Jonathan Rosenberg; Gur_Kimchi@vocaltec.com; > > iptel@lists.bell-labs.com > > Cc: sob@harvard.edu > > Subject: RE: [IPTEL] RE: more on iptel-gwreg-req > > > > > > > > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Saturday, December 08, 2001 3:49 AM > > To: 'Gur_Kimchi@vocaltec.com'; iptel@lists.bell-labs.com > > Cc: sob@harvard.edu; Jonathan Rosenberg > > Subject: [IPTEL] RE: more on iptel-gwreg-req > > Comments are inline [RRR] > > > > > > > > 2. I think in terms of model there is not such a great > > difference in > > > terms of presentation between what a pstn-sip, sip-323 or > > sip-xyz - in > > > all cases some basic building blocks must be communicated > - and they > > > are captured in the requirements (e.g. Media/Resource > Capabilities, > > > Termination Capabilities, and status). > > > > I have no problem if the protocol happens to be flexible > > enough to support all sorts of gateways; > > > > [RRR] Finally, it is a very good news that we have made an > > agreement that the protocol will be flexible enough to > > support all sorts of gateways. This must be our main focus of > > the protocol. Let us work and develop our protocol meeting > > this primary requirement without excluding any types of GWs. > > > Actually, this is *not* how I read what Jonathan wrote. I > interpret his suggestion that we not make flexibility across > any kind of gateway a goal for the protocol (where do you > stop?), but rather that he would not find it objectionable if > such flexibility happened to fall out of a design optimized > for straightforward PSTN gateways. > > [RRR] We are talking about the registration protocol for GWs > and a GW is characterized by some attributes by the keeper of > some destiantion addresses, capacities, etc. We are > generalizing these features. By the way, in an ITAD, we are > NOT talking about rotuing or route propagation etc. like > this. We are talking about registration of all attributes > that a GW might have. We are NOT for standardizing the > SIP-ISUP GW registation protocol per se. > > On this point I am inclined to agree with Jonathan. To try to > deal with IP-IP > Protocol conversions boxes like SIP<->H323 we would be > treading into very dangerous water, IMHO. Not only does this > introduce the possibility of combinatoric explosion of > routing information (i.e. the need to represent routes for > each combination of protocol P and protocol Q for all values > of P and Q), but if you actually want to make use of this > information it also leads inexorably to a route computation > which is equivalent to solving boolean satisfiability > problems (e.g.find me the best route by between two gateways > which minimizes administrative cost and number of protocol > conversions in between). > > [RRR] By the way, we are not considering anything like > protocol conversion or routing or progation of routes or > route aggregation in registartion. So, the points that are > being raised from the protocol "CONVERSION" point of view are > out of question. The characteristics of the SIP-ISUP GW is > generalized enough to falsh out the requirements for > development of the registration protocol that is good for all > types of GWs. The SIP-ISUP GW is highly complex especillay > its capacity attributes while the other GWs are very simple. > So, the GW registration protocol that we are developing will > be good enough for all types of GWs if it can satisfies the > requirements for the SIP-ISUP GW - all we need to do is to > add additional field in the address space that include email > IDs, URL IDs, etc. > > [RRR] Again, please note that we are NOT considering routing, > routing propagation or route aggression that are required for > inter-ITAD or inter-Domain protocol. That is why, inter-ITAD > protocol like TRIP is so complex. We are considering the > "registration" of addresses, capacitiy attributes, etc only. > > Beyond this, there are two further dangers: > > - creeping into representing which PSTN signaling protocols a > gateway supports in order to be sure that you don't lose > features when crossing into the PSTN (e.g. prefer an ISUP > speaker to a Q.931 speaker, and I'd really like Q.Sig while > I'm at it). > > [RRR] We considering registration protocol of the GW, not the > inter-doamin protocol TRIP. The registration protocol will be > able identify whether it is a SIP-ISUP GW, SIP-H.323 GW, etc. > Once it is identified, each will deal with the corresponding > GW accordingly. The protocol will have the capability to > satisfy the requirements as appropriate. > > [RRR] Again, please note that we are NOT develoiping the > "SIP-ISUP GW Registration" protocol. We are rather developing > the GW registration protocol where each type of GW will be > able to register their attributes as appropriate. > > - creeping into trying to solve most if not all of the > middlebox control problem. > > [RRR] It is a separate issue and is the same all types of GWs > including the SIP-ISUP GW. > > > Dave. > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Dec 14 12:16:25 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA03223 for ; Fri, 14 Dec 2001 12:16:24 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBEGnv011468; Fri, 14 Dec 2001 11:49:57 -0500 Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by share.research.bell-labs.com (8.11.6/8.11.6) with SMTP id fBEG8i010940 for ; Fri, 14 Dec 2001 11:08:44 -0500 Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Dec 14 11:03:06 EST 2001 Received: by lists.bell-labs.com (Postfix) id AC089443A5; Fri, 14 Dec 2001 10:28:20 -0500 (EST) Delivered-To: iptel@lists.bell-labs.com Received: from nslocum.cs.bell-labs.com (nslocum.cs.bell-labs.com [135.104.8.38]) by lists.bell-labs.com (Postfix) with ESMTP id E19BB4439D; Fri, 14 Dec 2001 10:28:18 -0500 (EST) Received: from research.bell-labs.com (ste-pcmh.research.bell-labs.com [135.104.53.76]) by nslocum.cs.bell-labs.com (8.9.3/8.9.3) with ESMTP id KAA256700263; Fri, 14 Dec 2001 10:28:18 -0500 (EST) Message-ID: <3C1A1AE8.6CE56515@research.bell-labs.com> From: Shaun Erickson Reply-To: listadmins@research.bell-labs.com Organization: Bell Labs (Innovations for Lucent Technologies) X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.4.9-13 i686) X-Accept-Language: en MIME-Version: 1.0 To: extest@lists.bell-labs.com, http-state@lists.bell-labs.com, ietf-pin@lists.bell-labs.com, ip-optical@lists.bell-labs.com, iptel@lists.bell-labs.com, nsbd@lists.bell-labs.com, pint@lists.bell-labs.com, spirits@lists.bell-labs.com, wwexptools@lists.bell-labs.com, irtf-nsm@lists.bell-labs.com, ietf-sin@lists.bell-labs.com, galax@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] LIST SERVER DIED Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 14 Dec 2001 10:29:44 -0500 Content-Transfer-Encoding: 7bit Last Monday, December 10th, around 9:00 AM, the lists.bell-labs.com listserver abruptly went down, never to come up again. I immediately began construction of a replacement server, which went online Thursday, December 13th, around 2:30 PM. It immediately started receiving and processing the email that was queued up for it on the Internet, and it is now caught up. However, it's possible that many systems bounced the mail, rather than queue it for that long, so if you haven't seen a post that should have gone out by now, you probably should resubmit it. I was able to get a lot of information about the lists, out of backups. I was not able to get everything, however. For instance, while I was able to retrieve the subscriber lists and resubscribe everyone, I was not able to retrieve their individual settings, such as whether or not they should get list mail in digest form, and any other per-subscriber settings. Everyone's list passwords have changed, as well. You'll get the new ones at the first of the month, when the reminders are sent out. If you need to change your settings before then, or if your list isn't configured to send out reminders, then please go to: http://lists-out.bell-labs.com/mailman/subscribe/YOUR_LIST_HERE and click on the "Email My Password To Me" button, to have it sent to you. If you have any trouble, please email listadmins@research.bell-labs.com, telling me what setting[s] on what list[s] you need changed, and I will be glad to assist you. List Admins: Your list's admin password has changed too. Please contact me for the new one. Once you have it, please check the configuration of your list. They are all back to their default settings, so you may find you need to tweak a few of them. If you have any trouble, please contact me at listadmins@research.bell-labs.com. I am working to ensure that should this happen again - which it someday surely will - that I will be able to retrieve more (preferably all) of the list and subscriber settings, so that recovery will be more complete. By the way, the list's archives have not yet been restored. I will get to that soon, and merge them with the archives that have been getting built since the new server went online. -ste -- Office: (908) 582-7629 Cell: (908) 672-6456 Pager: (888) 290-2057 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Dec 14 17:17:51 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA08721 for ; Fri, 14 Dec 2001 17:17:51 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBELvD014020; Fri, 14 Dec 2001 16:57:14 -0500 Received: from Mitel.COM ([216.191.234.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBELua014007 for ; Fri, 14 Dec 2001 16:56:37 -0500 Received: from Software.Mitel.COM (software [134.199.30.49]) by Mitel.COM (V8/MAIL-RELAY-2.1) with ESMTP id QAA12733; Fri, 14 Dec 2001 16:48:59 -0500 (EST) Received: from site.uottawa.ca ([134.199.40.54]) by Software.Mitel.COM (V8/MAIL-HUB-2.0) with ESMTP id QAA15262; Fri, 14 Dec 2001 16:48:58 -0500 (EST) Message-ID: <3C1A73CA.7A26ACF2@site.uottawa.ca> From: Daniel Amyot Organization: Mitel Corporation X-Mailer: Mozilla 4.79 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com, Jonathan Rosenberg , Jacques Sincennes Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [IPTEL] CPL DTD and switches Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 14 Dec 2001 16:48:58 -0500 Content-Transfer-Encoding: 8bit Hello, now that the IPTEL list server is back, here is a comment related to the latest CPL Document Type Definition. In draft 05, the switch elements have the following form (I am using the address-switch here, but the problem is the same for time, priotiry, language, and string switches): It is said that all switches can have an ’otherwise’ output and a 'not-present' output. However, the expression above creates a few problems: 1) multiple items: 2) A standalone 3) An empty switch I can see how one can have a alone or accompanied by an (especially if the switch makes it to the standard), but having multiple , a standalone , or en empty switch do not make much sense to me. What could be a better alternative is something of the following form (thanks to Jacques Sincennes' suggestion): This would ensure that: 1) there would be at most one 2) would be preceeded by at least one
or one 3) the switch would contain at least one
or one This form could be used for the other switches as well. Also, it would be nice to have examples in the standard that male use of the . Regards, Daniel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Dec 14 18:41:03 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09531 for ; Fri, 14 Dec 2001 18:41:03 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBENKE015089; Fri, 14 Dec 2001 18:20:14 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBENJj015071 for ; Fri, 14 Dec 2001 18:19:45 -0500 Received: from grandcentral.cs.columbia.edu (grandcentral.cs.columbia.edu [128.59.19.196]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id SAA23890; Fri, 14 Dec 2001 18:19:40 -0500 (EST) Received: from grandcentral.cs.columbia.edu (localhost [127.0.0.1]) by grandcentral.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id fBENJdo4027139; Fri, 14 Dec 2001 18:19:40 -0500 (EST) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.12.1/8.12.1/Submit) id fBENJUNq027136; Fri, 14 Dec 2001 18:19:31 -0500 (EST) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <15386.35074.110971.641142@grandcentral.cs.columbia.edu> To: Daniel Amyot Cc: iptel@lists.bell-labs.com, Jonathan Rosenberg , Jacques Sincennes Subject: Re: [IPTEL] CPL DTD and switches In-Reply-To: <3C1A73CA.7A26ACF2@site.uottawa.ca> References: <3C1A73CA.7A26ACF2@site.uottawa.ca> X-Mailer: VM 6.98 under Emacs 20.7.1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by share.research.bell-labs.com id fBENJj015072 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 14 Dec 2001 18:19:30 -0500 Content-Transfer-Encoding: 8bit On Friday, December 14 2001, "Daniel Amyot" wrote to "iptel@lists.bell-labs.com, Jonathan Rosenberg, Jacques Sincennes" saying: > Hello, > > now that the IPTEL list server is back, here is a comment related to the > latest CPL Document Type Definition. In draft 05, the switch elements have the > following form (I am using the address-switch here, but the problem is the > same for time, priotiry, language, and string switches): > > > > It is said that all switches can have an ’otherwise’ output and a > 'not-present' output. However, the expression above creates a few problems: > > 1) multiple items: This is illegal. However, I didn't want to dictate any ordering of items with respect to other switch output nodes. ('The output "not-present", which MAY occur anywhere in the list of outputs....') Thus, there's no (pretty) way to state this restriction in DTD syntax. (I feel that any regex where you have to specify "address*" twice is fairly ugly, since there's not actually any semantic difference between the two times the term appears.) Remeber this paragraph from the start of Appendix C: Note that compliance with this DTD is not a sufficient condition for correctness of a CPL script, as many of the conditions described in this specification are not expressible in DTD syntax. I should maybe add "or not expressible conveniently" there. > 2) A standalone > 3) An empty switch These aren't useful, but they're clearly well-defined, and I don't see any reason to forbid them. I actually changed the Draft-05 DTD syntax to *allow* these possibilities. Many (if not most) CPL scripts are going to be machine-generated, and it's a lot cleaner for generating utilities not to have to special-case the degenerate case of switches. (This will allow a generating utility to create a CPL script from a template, for instance.) I don't think this imposes any burden to speak of on a CPL server. > What could be a better alternative > is something of the following form (thanks to Jacques Sincennes' suggestion): > > In addition to failing my "ugly" criterion above, this also constrains the position of to follow all the
nodes, contrary to the text of the spec. > Also, it would be nice to have examples in the standard that male use of the > . Yes, I agree. If you'd like to write one up, I'll be happy to stick it in the spec for final IESG submission. (This applies for any CPL features people think are inadequately covered in the examples section.) Thanks for your comments! -- Jonathan Lennox lennox@cs.columbia.edu _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Dec 14 18:52:19 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA09615 for ; Fri, 14 Dec 2001 18:52:18 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBENY1015343; Fri, 14 Dec 2001 18:34:01 -0500 Received: from atlas.raviant.com (atlas.raviant.com [63.173.107.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBEN0A014873 for ; Fri, 14 Dec 2001 18:00:11 -0500 Received: (from mail@localhost) by atlas.raviant.com (8.9.3+Sun/8.9.3) id QAA26019; Fri, 14 Dec 2001 16:57:28 -0600 (CST) Received: from inservercr.raviant.com(172.22.1.58) by atlas.raviant.com via smap (V2.1) id xma026015; Fri, 14 Dec 01 16:57:23 -0600 Received: from moo.Raviant.com (MOO [172.22.1.143]) by inservercr.raviant.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VZ0T7MA9; Fri, 14 Dec 2001 16:58:38 -0600 Message-Id: <5.1.0.14.2.20011214163910.0235ddd0@INserverCR.Raviant.com> X-Sender: RGumpert@INserverCR.Raviant.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Daniel Amyot From: "Richard H. Gumpertz" Subject: Re: [IPTEL] CPL DTD and switches Cc: iptel@lists.bell-labs.com, Jonathan Rosenberg , Jacques Sincennes In-Reply-To: <3C1A73CA.7A26ACF2@site.uottawa.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 14 Dec 2001 16:59:02 -0600 Comments in line, marked [RHG]. At 16:48 12/14/2001 -0500, Daniel Amyot wrote: >Hello, > >now that the IPTEL list server is back, here is a comment related to the >latest CPL Document Type Definition. In draft 05, the switch elements have the >following form (I am using the address-switch here, but the problem is the >same for time, priotiry, language, and string switches): > > > >It is said that all switches can have an ’otherwise’ output and a >'not-present' output. However, the expression above creates a few problems: > > >1) multiple items: > > > > > > > > > [RHG] Indeed, the syntax allows multiple items BUT the associated text then prohibits them. Your suggested change to the syntax is probably a good idea, but with some modifications (see below). I have always been bothered by having syntax rules that required modification by the text. >2) A standalone > > > > > > [RHG] What is wrong with a standalone ? The meaning is clear: always use this output. Note that this might result from mechanically-generated CPL. >3) An empty switch > > > [RHG] What is wrong with an empty switch? The meaning is clear: always use the "default behavior" described in section 11. Again, this might result from mechanically-generated CPL. >I can see how one can have a alone or accompanied by an > (especially if the switch makes it to the >standard), but having multiple , a standalone , or en >empty switch do not make much sense to me. What could be a better alternative >is something of the following form (thanks to Jacques Sincennes' suggestion): > > > >This would ensure that: >1) there would be at most one >2) would be preceeded by at least one
or one > >3) the switch would contain at least one
or one [RHG] For your case, where you want at least one address or not-present, the following would be more correct: This allows
to follow which your syntax does not. [RHG] If, on the other hand, we accept empty and -only switches, then this can be simplified to: [RHG] I hereby propose this latter syntax. [RHG] An aside for the purists who want an unambiguous syntax, this could also be expressed as: >This form could be used for the other switches as well. [RHG] Agreed, all switches should use the same general syntax form. >Also, it would be nice to have examples in the standard that male use of the >. [RHG] To be a bit snide, but, more importantly, also fair to the authors: why don't you propose a specific example for possible inclusion? If nothing else, you might include something that they might not think of... >Regards, > >Daniel >_______________________________________________ >IPTEL mailing list >IPTEL@lists.bell-labs.com >http://lists.bell-labs.com/mailman/listinfo/iptel [RHG] I very much like your idea of getting the syntax to stand on its own. Thanks! Rick -- Richard H. Gumpertz, Ph.D. Raviant Networks, Inc. office: +1 (913) 266-5137 mobile: +1 (913) 484-8777 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 17 09:21:56 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02596 for ; Mon, 17 Dec 2001 09:21:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBHE5MZ22175; Mon, 17 Dec 2001 09:05:22 -0500 Received: from mail.site.uottawa.ca (mailn.site.uottawa.ca [137.122.89.142]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBF0Om016616 for ; Fri, 14 Dec 2001 19:24:48 -0500 Received: from prg2.csi.uottawa.ca (mail@prg2.csi.uottawa.ca [137.122.24.118]) by mail.site.uottawa.ca (8.9.3/8.9.3) with ESMTP id TAA42312; Fri, 14 Dec 2001 19:24:35 -0500 (EST) Received: from jack by prg2.csi.uottawa.ca with local (Exim 3.12 #1 (Debian)) id 16F2d1-0003aK-00; Fri, 14 Dec 2001 19:24:35 -0500 To: "Richard H. Gumpertz" Cc: Daniel Amyot , iptel@lists.bell-labs.com, Jonathan Rosenberg Subject: Re: [IPTEL] CPL DTD and switches Message-ID: <20011214192435.A12621@site.uottawa.ca> References: <3C1A73CA.7A26ACF2@site.uottawa.ca> <5.1.0.14.2.20011214163910.0235ddd0@INserverCR.Raviant.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.2.20011214163910.0235ddd0@INserverCR.Raviant.com>; from RGumpertz@Raviant.com on Fri, Dec 14, 2001 at 04:59:02PM -0600 From: Jacques Sincennes Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 14 Dec 2001 19:24:35 -0500 Content-Transfer-Encoding: 8bit Hello, Comments in line, marked [JS]. On Fri, Dec 14, 2001 at 04:59:02PM -0600, Richard H. Gumpertz wrote: > Comments in line, marked [RHG]. > > At 16:48 12/14/2001 -0500, Daniel Amyot wrote: > >Hello, > > > >now that the IPTEL list server is back, here is a comment related to the > >latest CPL Document Type Definition. In draft 05, the switch elements have the > >following form (I am using the address-switch here, but the problem is the > >same for time, priotiry, language, and string switches): > > > > > > > >It is said that all switches can have an ’otherwise’ output and a > >'not-present' output. However, the expression above creates a few problems: > > > > > >1) multiple items: > > > > > > > > > > > > > > > > > > > > [RHG] Indeed, the syntax allows multiple items BUT the associated text then prohibits them. Your suggested change to the syntax is probably a good idea, but with some modifications (see below). I have always been bothered by having syntax rules that required modification by the text. > > > > >2) A standalone > > > > > > > > > > > > > > [RHG] What is wrong with a standalone ? The meaning is clear: always use this output. Note that this might result from mechanically-generated CPL. A standalone is not sound. Since there is no initial condition to begin with, how could there be an otherwise? This is demonstrated by the fact that: would be semantically the same as: and, for that matter, identical to: > >3) An empty switch > > > > > > > > [RHG] What is wrong with an empty switch? The meaning is clear: always use the "default behavior" described in section 11. Again, this might result from mechanically-generated CPL. What is right about a completely useless statement? The mechanically-generated CPL could be fixed by removing that address-switch node altogether. It's pretty strange to define unsound syntax for sole purpose of accomodating some ill-conceived CPL generator. > >I can see how one can have a alone or accompanied by an > > (especially if the switch makes it to the > >standard), but having multiple , a standalone , or en > >empty switch do not make much sense to me. What could be a better alternative > >is something of the following form (thanks to Jacques Sincennes' suggestion): > > > > > > > >This would ensure that: > >1) there would be at most one > >2) would be preceeded by at least one
or one > > > >3) the switch would contain at least one
or one > > [RHG] For your case, where you want at least one address or not-present, the following would be more correct: > > This allows
to follow which your syntax does not. Given that the location of is already fixed, why not also fix the location of ? The benefits of having a more precise syntax appears to overweight the capability of putting at any given location. > [RHG] If, on the other hand, we accept empty and -only switches, then this can be simplified to: > > [RHG] I hereby propose this latter syntax. > > [RHG] An aside for the purists who want an unambiguous syntax, this could also be expressed as: > > > > >This form could be used for the other switches as well. > > [RHG] Agreed, all switches should use the same general syntax form. > > > >Also, it would be nice to have examples in the standard that male use of the > >. > > [RHG] To be a bit snide, but, more importantly, also fair to the authors: why don't you propose a specific example for possible inclusion? If nothing else, you might include something that they might not think of... With spammers in mind, here's one: > > >Regards, > > > >Daniel > >_______________________________________________ > >IPTEL mailing list > >IPTEL@lists.bell-labs.com > >http://lists.bell-labs.com/mailman/listinfo/iptel > > [RHG] I very much like your idea of getting the syntax to stand on its own. Thanks! > > Rick > -- > Richard H. Gumpertz, Ph.D. > Raviant Networks, Inc. > office: +1 (913) 266-5137 > mobile: +1 (913) 484-8777 Best regards, Jacques -- Jacques Sincennes, System Analyst | / email: jack@site.uottawa.ca LOTOS Group, University of Ottawa | \ phone: +1 613 562 5800 x6724 MCD #406, Ottawa, Ontario, Canada \| / fax: +1 613 562 5187 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 17 09:36:39 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03136 for ; Mon, 17 Dec 2001 09:36:39 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBHEM2Z22480; Mon, 17 Dec 2001 09:22:02 -0500 Received: from atlas.raviant.com (atlas.raviant.com [63.173.107.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBF1we017102 for ; Fri, 14 Dec 2001 20:58:40 -0500 Received: (from mail@localhost) by atlas.raviant.com (8.9.3+Sun/8.9.3) id TAA26377; Fri, 14 Dec 2001 19:56:40 -0600 (CST) Received: from inservercr.raviant.com(172.22.1.58) by atlas.raviant.com via smap (V2.1) id xma026375; Fri, 14 Dec 01 19:56:21 -0600 Received: from moo.Raviant.com (10.1.1.127 [10.1.1.127]) by inservercr.raviant.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VZ0T7MD2; Fri, 14 Dec 2001 19:57:37 -0600 Message-Id: <5.1.0.14.2.20011214195105.01d5fd20@INserverCR.Raviant.com> X-Sender: RGumpert@INserverCR.Raviant.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Jacques Sincennes From: "Richard H. Gumpertz" Subject: Re: [IPTEL] CPL DTD and switches Cc: Daniel Amyot , iptel@lists.bell-labs.com, Jonathan Rosenberg , Brett Johnson In-Reply-To: <20011214192435.A12621@site.uottawa.ca> References: <5.1.0.14.2.20011214163910.0235ddd0@INserverCR.Raviant.com> <3C1A73CA.7A26ACF2@site.uottawa.ca> <5.1.0.14.2.20011214163910.0235ddd0@INserverCR.Raviant.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 14 Dec 2001 19:57:45 -0600 Further comments in-line, marked [RHG2]: At 19:24 12/14/2001 -0500, Jacques Sincennes wrote: >Hello, > >Comments in line, marked [JS]. > >On Fri, Dec 14, 2001 at 04:59:02PM -0600, Richard H. Gumpertz wrote: >> Comments in line, marked [RHG]. >> >> At 16:48 12/14/2001 -0500, Daniel Amyot wrote: >> >Hello, >> > >> >now that the IPTEL list server is back, here is a comment related to the >> >latest CPL Document Type Definition. In draft 05, the switch elements have the >> >following form (I am using the address-switch here, but the problem is the >> >same for time, priotiry, language, and string switches): >> > >> > >> > >> >It is said that all switches can have an ’otherwise’ output and a >> >'not-present' output. However, the expression above creates a few problems: >> > >> > >> >1) multiple items: >> > >> > >> > >> > >> > >> > >> > >> > >> > >> >> [RHG] Indeed, the syntax allows multiple items BUT the associated text then prohibits them. Your suggested change to the syntax is probably a good idea, but with some modifications (see below). I have always been bothered by having syntax rules that required modification by the text. >> >> >> >> >2) A standalone >> > >> > >> > >> > >> > >> > >> >> [RHG] What is wrong with a standalone ? The meaning is clear: always use this output. Note that this might result from mechanically-generated CPL. > >A standalone is not sound. Since there is no initial >condition to begin with, how could there be an otherwise? This is >demonstrated by the fact that: > > > > > > > >would be semantically the same as: > > > > > >and, for that matter, identical to: > > [RHG2] The C language allows switch statements with just a "default:" case; this is identical except for semantics that might be tied to the English meaning of the otherwise. >> >3) An empty switch >> > >> > >> > >> >> [RHG] What is wrong with an empty switch? The meaning is clear: always use the "default behavior" described in section 11. Again, this might result from mechanically-generated CPL. > >What is right about a completely useless statement? The >mechanically-generated CPL could be fixed by removing that address-switch >node altogether. > >It's pretty strange to define unsound syntax for sole purpose of >accomodating some ill-conceived CPL generator. [RHG2] Then why haven't you complained about other empty nodes? Why should switches be any different than any other tags? >> >I can see how one can have a alone or accompanied by an >> > (especially if the switch makes it to the >> >standard), but having multiple , a standalone , or en >> >empty switch do not make much sense to me. What could be a better alternative >> >is something of the following form (thanks to Jacques Sincennes' suggestion): >> > >> > >> > >> >This would ensure that: >> >1) there would be at most one >> >2) would be preceeded by at least one
or one >> > >> >3) the switch would contain at least one
or one >> >> [RHG] For your case, where you want at least one address or not-present, the following would be more correct: >> >> This allows
to follow which your syntax does not. > >Given that the location of is already fixed, why not also fix >the location of ? The benefits of having a more precise >syntax appears to overweight the capability of putting >at any given location. [RHG2] The location of allows a simple-minded script-processor to process the correctly (and without surprise to the script-writer) without looking forward past the . There is no such requirement for : it can be processed first, last, or anywhere else. >> [RHG] If, on the other hand, we accept empty and -only switches, then this can be simplified to: >> >> [RHG] I hereby propose this latter syntax. >> >> [RHG] An aside for the purists who want an unambiguous syntax, this could also be expressed as: >> >> >> >> >This form could be used for the other switches as well. >> >> [RHG] Agreed, all switches should use the same general syntax form. >> >> >> >Also, it would be nice to have examples in the standard that male use of the >> >. >> >> [RHG] To be a bit snide, but, more importantly, also fair to the authors: why don't you propose a specific example for possible inclusion? If nothing else, you might include something that they might not think of... > >With spammers in mind, here's one: > > > > > > > >> >> >Regards, >> > >> >Daniel >> >_______________________________________________ >> >IPTEL mailing list >> >IPTEL@lists.bell-labs.com >> >http://lists.bell-labs.com/mailman/listinfo/iptel >> >> [RHG] I very much like your idea of getting the syntax to stand on its own. Thanks! >> >> Rick >> -- >> Richard H. Gumpertz, Ph.D. >> Raviant Networks, Inc. >> office: +1 (913) 266-5137 >> mobile: +1 (913) 484-8777 > > >Best regards, > >Jacques >-- >Jacques Sincennes, System Analyst | / email: jack@site.uottawa.ca >LOTOS Group, University of Ottawa | \ phone: +1 613 562 5800 x6724 >MCD #406, Ottawa, Ontario, Canada \| / fax: +1 613 562 5187 -- Richard H. Gumpertz, Ph.D. Raviant Networks, Inc. office: +1 (913) 266-5137 mobile: +1 (913) 484-8777 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 17 09:45:39 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03375 for ; Mon, 17 Dec 2001 09:45:39 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBHEQVZ22689; Mon, 17 Dec 2001 09:26:31 -0500 Received: from mail.site.uottawa.ca (mailn.site.uottawa.ca [137.122.89.142]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBF3Ui017448 for ; Fri, 14 Dec 2001 22:30:44 -0500 Received: from prg2.csi.uottawa.ca (mail@prg2.csi.uottawa.ca [137.122.24.118]) by mail.site.uottawa.ca (8.9.3/8.9.3) with ESMTP id WAA47217; Fri, 14 Dec 2001 22:30:41 -0500 (EST) Received: from jack by prg2.csi.uottawa.ca with local (Exim 3.12 #1 (Debian)) id 16F5X7-0004MU-00; Fri, 14 Dec 2001 22:30:41 -0500 To: "Richard H. Gumpertz" Cc: Daniel Amyot , iptel@lists.bell-labs.com, Jonathan Rosenberg , Brett Johnson Subject: Re: [IPTEL] CPL DTD and switches Message-ID: <20011214223041.B12621@site.uottawa.ca> References: <5.1.0.14.2.20011214163910.0235ddd0@INserverCR.Raviant.com> <3C1A73CA.7A26ACF2@site.uottawa.ca> <5.1.0.14.2.20011214163910.0235ddd0@INserverCR.Raviant.com> <20011214192435.A12621@site.uottawa.ca> <5.1.0.14.2.20011214195105.01d5fd20@INserverCR.Raviant.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.2.5i In-Reply-To: <5.1.0.14.2.20011214195105.01d5fd20@INserverCR.Raviant.com>; from RGumpertz@Raviant.com on Fri, Dec 14, 2001 at 07:57:45PM -0600 From: Jacques Sincennes Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 14 Dec 2001 22:30:41 -0500 Content-Transfer-Encoding: 8bit Hello, Comments in-line. *This time*, I've marked them [JS] On Fri, Dec 14, 2001 at 07:57:45PM -0600, Richard H. Gumpertz wrote: > Further comments in-line, marked [RHG2]: > > At 19:24 12/14/2001 -0500, Jacques Sincennes wrote: > >Hello, > > > >Comments in line, marked [JS]. > > > >On Fri, Dec 14, 2001 at 04:59:02PM -0600, Richard H. Gumpertz wrote: > >> Comments in line, marked [RHG]. > >> > >> At 16:48 12/14/2001 -0500, Daniel Amyot wrote: > >> >Hello, > >> > > >> >now that the IPTEL list server is back, here is a comment related to the > >> >latest CPL Document Type Definition. In draft 05, the switch elements have the > >> >following form (I am using the address-switch here, but the problem is the > >> >same for time, priotiry, language, and string switches): > >> > > >> > > >> > > >> >It is said that all switches can have an ’otherwise’ output and a > >> >'not-present' output. However, the expression above creates a few problems: > >> > > >> > > >> >1) multiple items: > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> [RHG] Indeed, the syntax allows multiple items BUT the associated text then prohibits them. Your suggested change to the syntax is probably a good idea, but with some modifications (see below). I have always been bothered by having syntax rules that required modification by the text. > >> > >> > >> > >> >2) A standalone > >> > > >> > > >> > > >> > > >> > > >> > > >> > >> [RHG] What is wrong with a standalone ? The meaning is clear: always use this output. Note that this might result from mechanically-generated CPL. > > > >A standalone is not sound. Since there is no initial > >condition to begin with, how could there be an otherwise? This is > >demonstrated by the fact that: > > > > > > > > > > > > > > > >would be semantically the same as: > > > > > > > > > > > >and, for that matter, identical to: > > > > > > [RHG2] The C language allows switch statements with just a "default:" case; this is identical except for semantics that might be tied to the English meaning of the otherwise. [JS] My point exactly! The switch statement with just a "default:" serves no purpose but to obfuscate the code. The "default body" will be executed each and every time, regardless of the expression it pretends switching upon: the "default body" does NOT require a switch statement to begin with! Note that I make no claim on the sanity of the C language. > >> >3) An empty switch > >> > > >> > > >> > > >> > >> [RHG] What is wrong with an empty switch? The meaning is clear: always use the "default behavior" described in section 11. Again, this might result from mechanically-generated CPL. > > > >What is right about a completely useless statement? The > >mechanically-generated CPL could be fixed by removing that address-switch > >node altogether. > > > >It's pretty strange to define unsound syntax for sole purpose of > >accomodating some ill-conceived CPL generator. > > [RHG2] Then why haven't you complained about other empty nodes? Why should switches be any different than any other tags? [JS] Because empty switches bear no meaning, contrary to other empty nodes. The address-switch without an address makes no sense; nor does the time-switch without a time specification, nor a string-switch without a string. [JS] is an exception mechanism that addresses the case where the condition cannot be evaluated. This provides for a 'valid condition' that can be used on its own or in conjuction with other 'conditions' (e.g. specific addresses, for address-switches). [JS] To illustrate this using the C language, an empty switch is similar to an "if" statement withtout a condition; a switch with just the part is similar to an "if-then-else", without condition nor "then body". Even if such a construct was accepted by the C language, that wouldn't make it any more right. > >> >I can see how one can have a alone or accompanied by an > >> > (especially if the switch makes it to the > >> >standard), but having multiple , a standalone , or en > >> >empty switch do not make much sense to me. What could be a better alternative > >> >is something of the following form (thanks to Jacques Sincennes' suggestion): > >> > > >> > > >> > > >> >This would ensure that: > >> >1) there would be at most one > >> >2) would be preceeded by at least one
or one > >> > > >> >3) the switch would contain at least one
or one > >> > >> [RHG] For your case, where you want at least one address or not-present, the following would be more correct: > >> > >> This allows
to follow which your syntax does not. > > > >Given that the location of is already fixed, why not also fix > >the location of ? The benefits of having a more precise > >syntax appears to overweight the capability of putting > >at any given location. > > [RHG2] The location of allows a simple-minded script-processor to process the correctly (and without surprise to the script-writer) without looking forward past the . There is no such requirement for : it can be processed first, last, or anywhere else. [JS] I did not claim that there was a requirement to put anywhere specific. I merely suggested that it might as well have a speficic position. But in the light of your reply, there is a legitimate reason to request to have it first. [JS] For the sake of a similar simple-minded script-processor as the one mentionned above, it should prove necessary to have the statement come in first. In instances where the data is indeed not found, having as the first condition processed will be necessary for the simple-minded script-processor to avoid "evaluation errors" (e.g. by comparing addresses which are not there). On top of that, the syntax will be consistent in both the DTD and the body text. [JS] NB: when you say "processed last", I assume you mean "last before ". > >> [RHG] If, on the other hand, we accept empty and -only switches, then this can be simplified to: > >> > >> [RHG] I hereby propose this latter syntax. > >> > >> [RHG] An aside for the purists who want an unambiguous syntax, this could also be expressed as: > >> > >> > >> > >> >This form could be used for the other switches as well. > >> > >> [RHG] Agreed, all switches should use the same general syntax form. > >> > >> > >> >Also, it would be nice to have examples in the standard that male use of the > >> >. > >> > >> [RHG] To be a bit snide, but, more importantly, also fair to the authors: why don't you propose a specific example for possible inclusion? If nothing else, you might include something that they might not think of... > > > >With spammers in mind, here's one: > > > > > > > > > > > > > > > >> > >> >Regards, > >> > > >> >Daniel > >> >_______________________________________________ > >> >IPTEL mailing list > >> >IPTEL@lists.bell-labs.com > >> >http://lists.bell-labs.com/mailman/listinfo/iptel > >> > >> [RHG] I very much like your idea of getting the syntax to stand on its own. Thanks! > >> > >> Rick > >> -- > >> Richard H. Gumpertz, Ph.D. > >> Raviant Networks, Inc. > >> office: +1 (913) 266-5137 > >> mobile: +1 (913) 484-8777 > > > > > >Best regards, > > > >Jacques > >-- > >Jacques Sincennes, System Analyst | / email: jack@site.uottawa.ca > >LOTOS Group, University of Ottawa | \ phone: +1 613 562 5800 x6724 > >MCD #406, Ottawa, Ontario, Canada \| / fax: +1 613 562 5187 > > -- > Richard H. Gumpertz, Ph.D. > Raviant Networks, Inc. > office: +1 (913) 266-5137 > mobile: +1 (913) 484-8777 Best regards, Jacques -- Jacques Sincennes, System Analyst | / email: jack@site.uottawa.ca LOTOS Group, University of Ottawa | \ phone: +1 613 562 5800 x6724 MCD #406, Ottawa, Ontario, Canada \| / fax: +1 613 562 5187 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 17 09:48:25 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03475 for ; Mon, 17 Dec 2001 09:48:25 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBHEV3Z22914; Mon, 17 Dec 2001 09:31:03 -0500 Received: from atlas.raviant.com (atlas.raviant.com [63.173.107.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBFBsk019670 for ; Sat, 15 Dec 2001 06:54:46 -0500 Received: (from mail@localhost) by atlas.raviant.com (8.9.3+Sun/8.9.3) id FAA26802; Sat, 15 Dec 2001 05:52:49 -0600 (CST) Received: from inservercr.raviant.com(172.22.1.58) by atlas.raviant.com via smap (V2.1) id xma026800; Sat, 15 Dec 01 05:52:22 -0600 Received: from moo.Raviant.com (10.1.1.127 [10.1.1.127]) by inservercr.raviant.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id VZ0T7MGB; Sat, 15 Dec 2001 05:53:38 -0600 Message-Id: <5.1.0.14.2.20011215055032.01d60978@INserverCR.Raviant.com> X-Sender: RGumpert@INserverCR.Raviant.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 To: Jacques Sincennes From: "Richard H. Gumpertz" Subject: Re: [IPTEL] CPL DTD and switches Cc: Daniel Amyot , iptel@lists.bell-labs.com, Jonathan Rosenberg , Brett Johnson In-Reply-To: <20011214223041.B12621@site.uottawa.ca> References: <5.1.0.14.2.20011214195105.01d5fd20@INserverCR.Raviant.com> <5.1.0.14.2.20011214163910.0235ddd0@INserverCR.Raviant.com> <3C1A73CA.7A26ACF2@site.uottawa.ca> <5.1.0.14.2.20011214163910.0235ddd0@INserverCR.Raviant.com> <20011214192435.A12621@site.uottawa.ca> <5.1.0.14.2.20011214195105.01d5fd20@INserverCR.Raviant.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 15 Dec 2001 05:53:47 -0600 Unless you make the both first and MANDATORY, the simple-minded script processor will still have to avoid "evaluation errors" because it may encounter a
without a preceding . Rick At 22:30 12/14/2001 -0500, Jacques Sincennes wrote: >[JS] For the sake of a similar simple-minded script-processor as the one mentionned above, it should prove necessary to have the statement come in first. In instances where the data is indeed not found, having as the first condition processed will be necessary for the simple-minded script-processor to avoid "evaluation errors" (e.g. by comparing addresses which are not there). On top of that, the syntax will be consistent in both the DTD and the body text. -- Richard H. Gumpertz, Ph.D. Raviant Networks, Inc. office: +1 (913) 266-5137 mobile: +1 (913) 484-8777 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Dec 19 12:25:46 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02072 for ; Wed, 19 Dec 2001 12:25:46 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBJHK9M10827; Wed, 19 Dec 2001 12:20:09 -0500 Received: from smtp2.libero.it (smtp2.libero.it [193.70.192.52]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBJHJfM10805 for ; Wed, 19 Dec 2001 12:19:41 -0500 Received: from libero.it (193.70.192.44) by smtp2.libero.it (6.0.032) id 3BEFF16100EB5169 for iptel@lists.bell-labs.com; Wed, 19 Dec 2001 18:19:37 +0100 Message-Id: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 From: "=?iso-8859-1?Q??=" To: iptel@lists.bell-labs.com X-XaM3-API-Version: 2.5 X-type: 0 X-SenderIP: 193.205.164.67 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by share.research.bell-labs.com id fBJHJfM10806 Subject: [IPTEL] =?iso-8859-1?Q?report_on_IPTEL_session_in_52_IETF?= Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 18:19:37 +0100 Content-Transfer-Encoding: 8bit Hi all, i'm interesting on the Gateway Registration. is it possible to have the ppresentation of Henning Schulzrinne and that of the Jonathan Rosemberg at the 52 IETF meeting. Where is it possible to find the report and the slide on the last session at IETF? thanks in advance Salvatore Loreto _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Dec 19 13:55:51 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04139 for ; Wed, 19 Dec 2001 13:55:51 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBJIY5M11652; Wed, 19 Dec 2001 13:34:05 -0500 Received: from mail1.dynamicsoft.com (mail1.dynamicsoft.com [63.113.40.10]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBJIXhM11639 for ; Wed, 19 Dec 2001 13:33:43 -0500 Received: from DYN-EXCH-001.dynamicsoft.com (dyn-exch-001 [63.113.44.7]) by mail1.dynamicsoft.com (8.12.0.Beta7/8.12.0.Beta7) with ESMTP id fBJIW3ES018407; Wed, 19 Dec 2001 13:32:04 -0500 (EST) Received: from dynamicsoft.com (POPE1 [63.113.46.82]) by DYN-EXCH-001.dynamicsoft.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id ZDFR1M41; Wed, 19 Dec 2001 13:33:40 -0500 Message-ID: <3C20DD83.1010600@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: salvatore.loreto@libero.it CC: iptel@lists.bell-labs.com Subject: Re: [IPTEL] report on IPTEL session in 52 IETF References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 19 Dec 2001 13:33:39 -0500 Content-Transfer-Encoding: 7bit I've posted slides from all the presentations at: http://www.jdrosen.net/ietf/52/index.html Thanks, Jonathan R. salvatore.loreto@libero.it wrote: > Hi all, > > i'm interesting on the Gateway Registration. > is it possible to have the ppresentation of Henning > Schulzrinne and that of the Jonathan Rosemberg at > the 52 IETF meeting. > Where is it possible to find the report and the slide > on the last session at IETF? > > thanks in advance > Salvatore Loreto > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > > -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Dec 22 17:36:00 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02921 for ; Sat, 22 Dec 2001 17:35:56 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBMMBbo32517; Sat, 22 Dec 2001 17:11:47 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBMM24o32463 for ; Sat, 22 Dec 2001 17:02:14 -0500 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA20252 for ; Sat, 22 Dec 2001 17:01:49 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id fBMM1jJ1016426 for ; Sat, 22 Dec 2001 17:01:49 -0500 (EST) Message-ID: <3C2502C9.B812452@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] RFC 2806bis: phone-context, and other issues Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 22 Dec 2001 17:01:45 -0500 Content-Transfer-Encoding: 7bit (I vaguely recall that we agreed in London that discussion should take place on the iptel list. My apologies if my memory is faulty.) I'm finally fulfilling my promise to edit RFC 2806bis ('tel' URL). Since this presumably is to go eventually to Draft, I'd like to know how widely some of the more esoteric features are implemented. Feedback is most welcome. - RFC 2806 allows several 'area-specifier's, as in tel:7042;phone-context=+1-212-70;phone-context=+1-212-71 Is this an "OR" match? Do clients *have* to support this? - RFC 2806 allows several service providers, identified by a domain name. Since there is no current data base that maps domain name to, say, 1010xxxx prefixes (US example), it is not clear how implementable this is. It is also not clear what the client should do if it doesn't recognize any of them. Try anyway, using some other carrier? Not try? Is a URL the right mechanism for conveying this information? - RFC 2806 allows private dial-plan identifiers (e.g., X-COMPANY-NET), with a registration scheme left for future definition. That's a bit too vague for my taste. I propose ditching this or, say, making it a domain name. All of these seem like features that should be added later, as extensions, once we understand how they can be useful. Unless we have two interoperable implementations, they'll have to be dropped in any event. Thus, please let me know if you either have implemented these or plan to implement these. Also, this would be a good opportunity to remind me of any other issues or extensions that should go into the 2806bis draft. Thanks. Henning -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Dec 22 20:39:09 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA03751 for ; Sat, 22 Dec 2001 20:39:09 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBN1Jno01057; Sat, 22 Dec 2001 20:19:59 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBMMe9o32651 for ; Sat, 22 Dec 2001 17:40:19 -0500 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id RAA22249 for ; Sat, 22 Dec 2001 17:39:54 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id fBMMdrJ1017292 for ; Sat, 22 Dec 2001 17:39:53 -0500 (EST) Message-ID: <3C250BB9.43DD3EDD@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] RFC 2806bis: modem type Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 22 Dec 2001 17:39:53 -0500 Content-Transfer-Encoding: 7bit Is anybody using the modem type negotiation mechanism? (Recall that 2806 allows the URL to specify a list of possible and preferred modem types.) -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Dec 22 23:33:16 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06889 for ; Sat, 22 Dec 2001 23:33:16 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBN4FQo02947; Sat, 22 Dec 2001 23:15:36 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBN3veo02674 for ; Sat, 22 Dec 2001 22:57:50 -0500 Received: from metroliner.cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id WAA06518 for ; Sat, 22 Dec 2001 22:57:25 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by metroliner.cs.columbia.edu (8.11.6/8.9.3) with ESMTP id fBN3vOs23107 for ; Sat, 22 Dec 2001 22:57:25 -0500 Message-ID: <3C25572B.859A6005@cs.columbia.edu> From: Henning Schulzrinne X-Mailer: Mozilla 4.78 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] New draft RFC 2806bis Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 22 Dec 2001 23:01:47 -0500 Content-Transfer-Encoding: 7bit I will submit the draft below after the holidays, when the I-D editor returns: http://www.cs.columbia.edu/~hgs/sip/drafts/draft-schulzrinne-rfc2806bis-00.txt Comments are much appreciated. Much of the text has been rewritten, but the document is meant to be backwards-compatible except for the omission of the private context name. Henning _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Dec 23 03:14:55 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24419 for ; Sun, 23 Dec 2001 03:14:55 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBN7U4o04542; Sun, 23 Dec 2001 02:30:14 -0500 Received: from broadsof.temp.veriohosting.com (broadsof.temp.veriohosting.com [161.58.239.68]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBN1Tho01122 for ; Sat, 22 Dec 2001 20:29:53 -0500 Received: from tate ([64.243.180.244]) by broadsof.temp.veriohosting.com (8.11.6) id fBN1TOX74256; Sat, 22 Dec 2001 20:29:24 -0500 (EST) Reply-To: From: "Brett Tate" To: Subject: RE: [IPTEL] RFC 2806bis: phone-context, and other issues Message-ID: <000001c18b51$85678390$2b01a8c0@broadsoft.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.2911.0) Importance: Normal In-Reply-To: <3C2502C9.B812452@cs.columbia.edu> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 22 Dec 2001 20:31:17 -0500 Content-Transfer-Encoding: 7bit > I'd like to know how widely some of the more > esoteric features are implemented. Feedback is > most welcome. > - RFC 2806 allows private dial-plan > identifiers (e.g., X-COMPANY-NET), > with a registration scheme left for > future definition. That's a bit too > vague for my taste. I propose ditching > this or, say, making it a domain name. We are currently making use of the private dial-plan functionality. > Also, this would be a good opportunity > to remind me of any other issues > or extensions that should go into the > 2806bis draft. Section 1.2 rfc2806bis-00 discusses escaping not unreserved characters. It would be helpful to add a sentence clarifying that "+", ";", "=", etcetera do not need to be escaped if they are explicitly presented in non-escaped form as part of the syntax. This would explain why "+" does not require escaping when used within a global-network-prefix; however it would require escaping when present within a private-prefix. _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Dec 23 10:46:21 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26780 for ; Sun, 23 Dec 2001 10:46:21 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBNFNVo11296; Sun, 23 Dec 2001 10:23:41 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBNFEZo11259 for ; Sun, 23 Dec 2001 10:14:45 -0500 Received: from opus.cs.columbia.edu (opus.cs.columbia.edu [128.59.20.100]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id KAA17562; Sun, 23 Dec 2001 10:14:13 -0500 (EST) Received: from cs.columbia.edu (metroliner.cs.columbia.edu [128.59.19.252]) by opus.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id fBNFEDJ1011874; Sun, 23 Dec 2001 10:14:13 -0500 (EST) Message-ID: <3C25F4C5.79BFD233@cs.columbia.edu> From: "Henning G. Schulzrinne" Organization: Dept. of Computer Science, Columbia University X-Mailer: Mozilla 4.78 [en] (X11; U; Linux 2.2.19-3cucs i686) X-Accept-Language: en MIME-Version: 1.0 To: brett@broadsoft.com CC: iptel@lists.bell-labs.com Subject: Re: [IPTEL] RFC 2806bis: phone-context, and other issues References: <000001c18b51$85678390$2b01a8c0@broadsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sun, 23 Dec 2001 10:14:13 -0500 Content-Transfer-Encoding: 7bit Brett Tate wrote: > > Section 1.2 rfc2806bis-00 discusses escaping > not unreserved characters. It would be > helpful to add a sentence clarifying that > "+", ";", "=", etcetera do not need to > be escaped if they are explicitly > presented in non-escaped form as part of > the syntax. This would explain why "+" > does not require escaping when used within > a global-network-prefix; however it would > require escaping when present within a > private-prefix. Added: Note that the reserved characters ``+'', ``;'', ``='', and ``?'' {\MUSTNOT} be escaped if shown in the grammar definitions below as they are delimiters for the tel/fax/modem URI schemes. These reserved characters {\MUST} be escaped if they appear in parameter values. Let me know if this is not sufficiently clear. -- Henning Schulzrinne http://www.cs.columbia.edu/~hgs _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 24 21:21:37 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA26759 for ; Mon, 24 Dec 2001 21:21:37 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBP21Fo18897; Mon, 24 Dec 2001 21:01:15 -0500 Received: from imo-d07.mx.aol.com (imo-d07.mx.aol.com [205.188.157.39]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBP208o18882 for ; Mon, 24 Dec 2001 21:00:08 -0500 Received: from JustMeUnOr@aol.com by imo-d07.mx.aol.com (mail_out_v31_r1.9.) id r.fb.1f0cbf9c (4328) for ; Mon, 24 Dec 2001 21:00:00 -0500 (EST) From: JustMeUnOr@aol.com Message-ID: To: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="part1_fb.1f0cbf9c.2959379f_boundary" X-Mailer: AOL 6.0 for Windows US sub 10552 Subject: [IPTEL] Inter-domain Call processing Queries Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 24 Dec 2001 20:59:59 EST --part1_fb.1f0cbf9c.2959379f_boundary Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Had a sudden curiosioty come to me whilst wrapping some of the final boxes... In TRIP, (or any existing technology for that matter) is there any ability to Query either another G/W's, L/S's, or R/S's call processing logic (I Would assume that the most appropiate place in a network to query this would be either in a L/S, or R/S...) in someone else's network, as to see how a call will be processed, such as Weather it will hit a Intercept, or not?? (E.G. Traver on a DMS, or Vfy:Ofc on a 5E) Thanks, Darby --part1_fb.1f0cbf9c.2959379f_boundary Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: 7bit Had a sudden curiosioty come to me whilst wrapping some of the final boxes...

In TRIP, (or any existing technology for that matter) is there any ability to Query either another G/W's, L/S's, or R/S's call processing logic (I Would assume that the most appropiate place in a network to query this would be either in a L/S, or R/S...) in someone else's network, as to see how a call will be processed, such as Weather it will hit a Intercept, or not??   (E.G. Traver on a DMS, or Vfy:Ofc on a 5E)

Thanks,
Darby --part1_fb.1f0cbf9c.2959379f_boundary-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Dec 26 02:09:14 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11348 for ; Wed, 26 Dec 2001 02:09:13 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBQ6qQo25245; Wed, 26 Dec 2001 01:52:31 -0500 Received: from sj-msg-core-3.cisco.com (sj-msg-core-3.cisco.com [171.70.157.152]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBQ6poo25232 for ; Wed, 26 Dec 2001 01:51:50 -0500 Received: from mira-sjc5-5.cisco.com (mira-sjc5-5.cisco.com [171.71.163.22]) by sj-msg-core-3.cisco.com (8.11.3/8.9.1) with ESMTP id fBQ6pRH07878; Tue, 25 Dec 2001 22:51:27 -0800 (PST) Received: from DHAVAL-W2K1.cisco.com (shinjuku-equant-dynamic25.cisco.com [64.104.42.25]) by mira-sjc5-5.cisco.com (Mirapoint) with ESMTP id AAN13609; Tue, 25 Dec 2001 22:50:42 -0800 (PST) Message-Id: <4.3.2.7.2.20011225225255.00b165d8@mira-sjc5-5.cisco.com> X-Sender: dhaval@mira-sjc5-5.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 To: JustMeUnOr@aol.com From: Dhaval Shah Subject: Re: [IPTEL] Inter-domain Call processing Queries Cc: iptel@lists.bell-labs.com In-Reply-To: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_6811975==_.ALT" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Tue, 25 Dec 2001 22:53:09 -0800 --=====================_6811975==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi Darby, Not in TRIP. Thanx, Dhaval At 08:59 PM 12/24/2001 -0500, JustMeUnOr@aol.com wrote: >Had a sudden curiosioty come to me whilst wrapping some of the final boxes... > >In TRIP, (or any existing technology for that matter) is there any ability >to Query either another G/W's, L/S's, or R/S's call processing logic (I >Would assume that the most appropiate place in a network to query this >would be either in a L/S, or R/S...) in someone else's network, as to see >how a call will be processed, such as Weather it will hit a Intercept, or >not?? (E.G. Traver on a DMS, or Vfy:Ofc on a 5E) > >Thanks, >Darby --=====================_6811975==_.ALT Content-Type: text/html; charset="us-ascii" Hi Darby,

Not in TRIP.

Thanx,
Dhaval

At 08:59 PM 12/24/2001 -0500, JustMeUnOr@aol.com wrote:
Had a sudden curiosioty come to me whilst wrapping some of the final boxes...

In TRIP, (or any existing technology for that matter) is there any ability to Query either another G/W's, L/S's, or R/S's call processing logic (I Would assume that the most appropiate place in a network to query this would be either in a L/S, or R/S...) in someone else's network, as to see how a call will be processed, such as Weather it will hit a Intercept, or not??   (E.G. Traver on a DMS, or Vfy:Ofc on a 5E)

Thanks,
Darby
--=====================_6811975==_.ALT-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Dec 26 16:41:14 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20910 for ; Wed, 26 Dec 2001 16:41:14 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBQLKAo28593; Wed, 26 Dec 2001 16:20:10 -0500 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBQLJYo28573 for ; Wed, 26 Dec 2001 16:19:34 -0500 Received: from dynamicsoft.com ([63.113.46.89]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id fBQLJqVZ002847 for ; Wed, 26 Dec 2001 16:19:52 -0500 (EST) Message-ID: <3C2A3EDE.4010203@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: iptel Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPTEL] draft meeting minutes Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Wed, 26 Dec 2001 16:19:26 -0500 Content-Transfer-Encoding: 7bit Folks, Enclosed are the first draft of meeting minutes for the iptel group at IETF 52. Please let me know if there are any corrections or omissions. Thanks to Mary Barnes for taking notes. -Jonathan R. Minutes of the IPTEL WG meeting IETF 52 December 2001 Salt Lake City, UT Minutes taken by: Mary Barnes Minutes prepared by: Jonathan Rosenberg The IP Telephony (iptel) working group met for a single one-hour session at IETF 52. Agenda Bashing -------------- First up was agenda bashing. The proposed agenda was: Agenda Bash [Rosenberg] 2m CPL/TRIP Updates [Rosenberg] 5m TRIP MIB [Walker] 10m Gateway Registration Scenarios: Internet2 [Schulzrinne] 5m Scenarios: Carrier [Peterson] 5m Requirements [Rosenberg] 20m Attributes [Bangalore] 10m The agenda was agreed to. CPL and TRIP Status (Rosenberg) ------------------------------- Jonathan presented the status of CPL. -05 has been issued, finally resolving the year-plus-long dispute with calsch on the level of compliance to rfc2445. Finally, the agreement was to be fully compliant. Performance and security issues were resolvable by doing off-line expansion of recurrence rules. Other changes include the addition of a language-switch and minor fixes. A new WGLC was issued, ending 12/21/01. People were requested to send comments to the list asap. TRIP -09 approved as an RFC 9/13/01. Its getting close to top of editors queue, maybe 3-4 weeks. TRIP MIB Open Issues (Walker) ----------------------------- Lots of comments on -00 (draft-ietf-iptel-trip-mib-00.txt). Most related to SNMP types of things. There were a few open issues. The main one was that one can't easily differentiate TRIBs (Adj-TRIB-IN, Ext-TRIB, Adj-TRIB-Out) in the MIB. Proposed solutions: extrapolation, separate tables, bitfield (set). * Extrapolation - this demands a lot of network manager * Separate tables - TRIBs can appear in multiple tables * Bitfield - seems preferable - appears as an extension of existing mechanism which is a boolean During the discussion, using a pointer was suggested. The response was that the editors understanding was that pointers don't work well with SNMP. Consensus: bit field is agreed solution (no objections). Other open issues: o TripPeerRemotePort (added to peer index table) - issue is configured versus learned - multiple servers can share the same IP address. Had been proposed to add a new field RemoteField, however, this has issues with port. Proposed solution: new object (tripPeerLearned) to indicate which is configured vs learned dynamically in protocol. o Use of TimeInterval (SNMPv2-TC, hundredths of sec) for timers - MIB uses Integer32 seconds. Proposal to use text rather than integer for this field. Proposed solution: seconds used by protocol, marginally easier to configure. o Oversights: * Add tripRouteTypeTable to config table (similar to tripPeerRouteTypeTable) * Add timestamp to route table, will also timestamp last change of peer state. Conclusion: Will post above on mailing list and new draft will be available soon. Gateway Registration --------------------- Precursor: Jonathan highlighted the issue of previous WGs that have had multiple proposals for which there were lots of opinions. This ends up being time consuming as WG often has to backtrack. A plea for being open-minded and focus on progress. The approach we will take is to first be sure we all are solving the same problem, since its not clear we are. So, there will be presentations on scenarios that the gateway registration is solving. Scenarios: Internet2 (Schulzrinne) ++++++++++++++++++++++++++++++++++ Intradomain Gateway Discovery Requirements Organizational assumptions: Not a typical carrier setup * Possibly "mutual aid" * Loosely affiliated, with different administrators o Different university campuses o Different branches of enterprise Example Diagram * Magic in the middle to manage 2 networks Jonathan asked whether the scenario was gateways as columbia, for example, propagating their information to other university campuses so that those gateways can be used as a communal resource? Henning replied that this is yes, although it could be through an intermediary, he is not proposing a mechanism in this slide. Jonathan commented that it seemed like this was more like the old wide area service discovery work that was done back when, and whilst its an interesting problem [and indeed, part of Jonathan's PhD dissertation], its not really the problem of this charter item, which is an element in front of a farm of gateways managing the resources of those gateways. Henning continued with his presentation: Dynamic configuration * New gateways or gateway capacity changes * For university Policy changes * New area codes * Time of day, etc. Coordination * May have loose central administrator * Avoid manual updates and configuration * Reflect changes rapidly (minutes) Status updates * Want to have reasonably accurate picture * But occasional failure+retry acceptable * Charging not an issue Additional considerations * Multicast may be available * Gateways are not competitors Discussion: Is this what people had in mind for Gateway Registration Protocol? Henning said that this may be a slightly different problem, thus perhaps a different protocol may be applicable. Jonathan replied that this doesn't seem to be intra-domain - it appears to be inter-domain. Columbia owns the policy. From a carrier's perspective, the "Gateways are not competitors isn't applicable" and points to this being a different problem. Thus, the requirements introduced by this scenario don't seem to apply. Henning replied that the requirements are looser, but that doesn't mean the same protocol wouldn't apply. Cullen Jennings asked whether this would be delivering availability information. Henning responded yes. Update frequency is a protocol parameter that depends on the size of the network. A question was made as to whether, in the model, you expect capacity updates to be sent to all proxies out there? If you expand connectivity, you don't want this data to go to all servers. Not scaleable. Henning replied that you have the scalability problem regardless. This solution (SLP) might do better as it assumes multicast is available. Another question was about the loosely maintained central admin point - you need much more clear boundaries. Henning replied that it doesn't matter where the information resides; it matters who controls the information. Separate administration from policy control. The gateway is the one with the ultimate decision. Jonathan said that if you want the gateway to register with lots of proxies, then you need multicast. But, for a single service provider, this is NOT a problem. Henning said that you can pick longer intervals if there are lots of updates. It's more of a protocol tuning issue as to how many messages you can tolerate. Unless protocol has a built in restriction on message frequency. Only really difference is per message overhead (eg. TCP connection setup). Not an issue. Jonathan said that if you're concerned with lots of elements, then certainly multicast is desireable. For a smaller amount of elements, TCP is fine. Henning said that his proposal supports any mechanism. Jonathan said that TRIP doesn't support UDP. Thus, if you need lots of updates, then you are adding an additional requirement. You've got to limit scenarios and limit scope of solution. Jonathan said that he doesn't think this is the problem that needs to be solved. This doesn't match the charter, although it is an interesting problem. Then, he posed the question to Group: Is this a scenario that needs to be taken into consideration? Dave Oran replied that this is an interesting problem in the discovery domain and not in route optimization. Finding gateways is not a problem - among a set of known gateways, which is the right one to use. This is an example of a service discovery problem. Henning replied that there are some attributes independent of protocol choice. Conclusion: Agreement to hear the next scenario and then continue discussion. Scenarios: Carrier (Peterson) +++++++++++++++++++++++++++++ Jon Peterson put up a diagram of his Carrier architecture proposal that was posted to IPTEL WG mailing list. A type of architecture that he believes will exist (versus one he believes is being deployed) * Attributes: 1. Has a proxy server 2. Two types of resources - media gateway controllers and standalone (dumb) gateways * 2 points: 1. Large gateways that are dumb that have physical resources pointing to elements in PSTN. 2. Gateways that terminate to VoIP. Trunk groups are an important concept here, and represent the finest degree of granularity for policy decisions. Trunk groups can span physical gateways (typical carrier setup for reliability). Comments on the model: Brian Rosen: Mostly he likes. It used to be that this was the picture that everyone had in mind that were big carrier types. Are MGs fading away? Always was the argument that you didn't want to put so much into Gateways, thus the separation. But, Moore's law makes this less meaningful. So, perhaps the trend is to combine. Jon replied that you still need signaling gateways to be separate, since you only have a single point code. Dave Oran said that he thinks that the MGC decomposition is orthogonal. When we talking about IPTEL GWs - MGC is the gateway. Why does this decomposition impact the discussion? Dave also pointed out that an element that's missing from the diagram - show prefixes and trunk groups but don't show carriers. Don't show TGs spanning multiple MGCs. Is that precluded? Jon replied that his next slide deals with Dave's first point on why the decomposition has an impact. As for the second point, in SS7, a signaling switch is limited to a single point code. Dave said that everyone's gotten around that. There may be a case where TGs can't span GWs, but this shouldn't be the model. This is a low level point that might lead people to the wrong conclusion. Back to Jon's presentation. Why does the decomposition impact this? It has to do with attributes availability. An MGC advertises its GWs availability, but smart GWs availability known directly. o Route availability * Are all MGC routes for '+'? Why express preference? * Also other address families o Trunk group availability * Trunks associated with physical interfaces * CSI states (blocked locally/remotely, idle, etc.) * Availability of routes predicted on trunk groups, but often not on a single GW Jon said he really believes that trunk group availability vs. Gateway availability is the true problem to solve. Jonathan asked whether the group believes that this is the problem that is being solved? Discussion: Dave Oran believes this is the problem. Does have some concerns with the attributes and hierarchy. Jon said he's just trying to describe what needs to be done. Dave Oran responded that we need to work through this. He believes that this is the model - need to be able to find routes to resources (described as a PSTN resource). Jonathan added one caveat: believes that this is the problem we're solving, but don't get consumed with large carrier model. We need to worry about smaller gateways as well, were there are no trunk groups, where the gateway itself, or routes, are the things to which attributes are associated. However, we need to derive requirements from this general problem. Jonathan also pointed out that we're not solving SIP to H.323 problem. Took a hum vote: Is this the problem? * Yes? Majority hum * No? No hums! Further discussion: Jon said that he believes this should always be about TGs - believes should treat PRI as a trunk. Cullen asked whether there would ever be more than one carrier on a single trunk? Jon said that there are a number of carriers for virtually every trunk. Due to EA. Dave Oran responded that this has nothing to do with it, as the EA concept user experience doesn't necessarily relate. Take it to the list. Jonathan stopped discussion at this point. Time had run out, and we were not able to cover the last two agenda items: * Requirements (Rosenberg) * Attributes (Bangalore) Conclusion/Actions: * Agreement to use Jon Peterson's model as the basis for the problem to be solved. * Take further discussion of Jon's proposal to the list -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Dec 28 11:23:54 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09301 for ; Fri, 28 Dec 2001 11:23:54 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBSGLho05415; Fri, 28 Dec 2001 11:21:44 -0500 Received: from almso1.proxy.att.com (almso1.att.com [192.128.167.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBSGKco05402 for ; Fri, 28 Dec 2001 11:20:38 -0500 Received: from attrh3i.attrh.att.com ([135.71.62.12]) by almso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fBSGKSW26316 for ; Fri, 28 Dec 2001 11:20:28 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh3i.attrh.att.com (5.5.029) id 3C06950500647053; Fri, 28 Dec 2001 11:19:48 -0500 content-class: urn:content-classes:message Subject: RE: [IPTEL] draft meeting minutes Message-ID: <62DA45D4963FA747BA1B253E266760F9F212E4@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] draft meeting minutes X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 Thread-Index: AcGOVZQBgi81fvpFEdWSygAAwCUaDwBZLmYw From: "Roy, Radhika R, ALCTA" To: "Jonathan Rosenberg" , "iptel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by share.research.bell-labs.com id fBSGKco05403 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 28 Dec 2001 11:20:16 -0500 Content-Transfer-Encoding: 8bit Hi, Everyone: In addition to the scenarios presented by Jon Peterson, I will add that there can be different types of GWs: SIP-ISUP, SIP-H.323, SIP-BICC, etc. The GW registration scenarios MUST not exclude any types of GWs. That is, we must NOT develop the SIP-ISUP GW registration protocol per se. It must be the GW registration protocol that includes all types of GWs. If anyone has any comments, please let us know. Best regards, Radhika R. Roy rrroy@att.com -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Wednesday, December 26, 2001 4:19 PM To: iptel Subject: [IPTEL] draft meeting minutes Folks, Enclosed are the first draft of meeting minutes for the iptel group at IETF 52. Please let me know if there are any corrections or omissions. Thanks to Mary Barnes for taking notes. -Jonathan R. Minutes of the IPTEL WG meeting IETF 52 December 2001 Salt Lake City, UT Minutes taken by: Mary Barnes Minutes prepared by: Jonathan Rosenberg The IP Telephony (iptel) working group met for a single one-hour session at IETF 52. Agenda Bashing -------------- First up was agenda bashing. The proposed agenda was: Agenda Bash [Rosenberg] 2m CPL/TRIP Updates [Rosenberg] 5m TRIP MIB [Walker] 10m Gateway Registration Scenarios: Internet2 [Schulzrinne] 5m Scenarios: Carrier [Peterson] 5m Requirements [Rosenberg] 20m Attributes [Bangalore] 10m The agenda was agreed to. CPL and TRIP Status (Rosenberg) ------------------------------- Jonathan presented the status of CPL. -05 has been issued, finally resolving the year-plus-long dispute with calsch on the level of compliance to rfc2445. Finally, the agreement was to be fully compliant. Performance and security issues were resolvable by doing off-line expansion of recurrence rules. Other changes include the addition of a language-switch and minor fixes. A new WGLC was issued, ending 12/21/01. People were requested to send comments to the list asap. TRIP -09 approved as an RFC 9/13/01. Its getting close to top of editors queue, maybe 3-4 weeks. TRIP MIB Open Issues (Walker) ----------------------------- Lots of comments on -00 (draft-ietf-iptel-trip-mib-00.txt). Most related to SNMP types of things. There were a few open issues. The main one was that one can't easily differentiate TRIBs (Adj-TRIB-IN, Ext-TRIB, Adj-TRIB-Out) in the MIB. Proposed solutions: extrapolation, separate tables, bitfield (set). * Extrapolation - this demands a lot of network manager * Separate tables - TRIBs can appear in multiple tables * Bitfield - seems preferable - appears as an extension of existing mechanism which is a boolean During the discussion, using a pointer was suggested. The response was that the editors understanding was that pointers don't work well with SNMP. Consensus: bit field is agreed solution (no objections). Other open issues: o TripPeerRemotePort (added to peer index table) - issue is configured versus learned - multiple servers can share the same IP address. Had been proposed to add a new field RemoteField, however, this has issues with port. Proposed solution: new object (tripPeerLearned) to indicate which is configured vs learned dynamically in protocol. o Use of TimeInterval (SNMPv2-TC, hundredths of sec) for timers - MIB uses Integer32 seconds. Proposal to use text rather than integer for this field. Proposed solution: seconds used by protocol, marginally easier to configure. o Oversights: * Add tripRouteTypeTable to config table (similar to tripPeerRouteTypeTable) * Add timestamp to route table, will also timestamp last change of peer state. Conclusion: Will post above on mailing list and new draft will be available soon. Gateway Registration --------------------- Precursor: Jonathan highlighted the issue of previous WGs that have had multiple proposals for which there were lots of opinions. This ends up being time consuming as WG often has to backtrack. A plea for being open-minded and focus on progress. The approach we will take is to first be sure we all are solving the same problem, since its not clear we are. So, there will be presentations on scenarios that the gateway registration is solving. Scenarios: Internet2 (Schulzrinne) ++++++++++++++++++++++++++++++++++ Intradomain Gateway Discovery Requirements Organizational assumptions: Not a typical carrier setup * Possibly "mutual aid" * Loosely affiliated, with different administrators o Different university campuses o Different branches of enterprise Example Diagram * Magic in the middle to manage 2 networks Jonathan asked whether the scenario was gateways as columbia, for example, propagating their information to other university campuses so that those gateways can be used as a communal resource? Henning replied that this is yes, although it could be through an intermediary, he is not proposing a mechanism in this slide. Jonathan commented that it seemed like this was more like the old wide area service discovery work that was done back when, and whilst its an interesting problem [and indeed, part of Jonathan's PhD dissertation], its not really the problem of this charter item, which is an element in front of a farm of gateways managing the resources of those gateways. Henning continued with his presentation: Dynamic configuration * New gateways or gateway capacity changes * For university Policy changes * New area codes * Time of day, etc. Coordination * May have loose central administrator * Avoid manual updates and configuration * Reflect changes rapidly (minutes) Status updates * Want to have reasonably accurate picture * But occasional failure+retry acceptable * Charging not an issue Additional considerations * Multicast may be available * Gateways are not competitors Discussion: Is this what people had in mind for Gateway Registration Protocol? Henning said that this may be a slightly different problem, thus perhaps a different protocol may be applicable. Jonathan replied that this doesn't seem to be intra-domain - it appears to be inter-domain. Columbia owns the policy. From a carrier's perspective, the "Gateways are not competitors isn't applicable" and points to this being a different problem. Thus, the requirements introduced by this scenario don't seem to apply. Henning replied that the requirements are looser, but that doesn't mean the same protocol wouldn't apply. Cullen Jennings asked whether this would be delivering availability information. Henning responded yes. Update frequency is a protocol parameter that depends on the size of the network. A question was made as to whether, in the model, you expect capacity updates to be sent to all proxies out there? If you expand connectivity, you don't want this data to go to all servers. Not scaleable. Henning replied that you have the scalability problem regardless. This solution (SLP) might do better as it assumes multicast is available. Another question was about the loosely maintained central admin point - you need much more clear boundaries. Henning replied that it doesn't matter where the information resides; it matters who controls the information. Separate administration from policy control. The gateway is the one with the ultimate decision. Jonathan said that if you want the gateway to register with lots of proxies, then you need multicast. But, for a single service provider, this is NOT a problem. Henning said that you can pick longer intervals if there are lots of updates. It's more of a protocol tuning issue as to how many messages you can tolerate. Unless protocol has a built in restriction on message frequency. Only really difference is per message overhead (eg. TCP connection setup). Not an issue. Jonathan said that if you're concerned with lots of elements, then certainly multicast is desireable. For a smaller amount of elements, TCP is fine. Henning said that his proposal supports any mechanism. Jonathan said that TRIP doesn't support UDP. Thus, if you need lots of updates, then you are adding an additional requirement. You've got to limit scenarios and limit scope of solution. Jonathan said that he doesn't think this is the problem that needs to be solved. This doesn't match the charter, although it is an interesting problem. Then, he posed the question to Group: Is this a scenario that needs to be taken into consideration? Dave Oran replied that this is an interesting problem in the discovery domain and not in route optimization. Finding gateways is not a problem - among a set of known gateways, which is the right one to use. This is an example of a service discovery problem. Henning replied that there are some attributes independent of protocol choice. Conclusion: Agreement to hear the next scenario and then continue discussion. Scenarios: Carrier (Peterson) +++++++++++++++++++++++++++++ Jon Peterson put up a diagram of his Carrier architecture proposal that was posted to IPTEL WG mailing list. A type of architecture that he believes will exist (versus one he believes is being deployed) * Attributes: 1. Has a proxy server 2. Two types of resources - media gateway controllers and standalone (dumb) gateways * 2 points: 1. Large gateways that are dumb that have physical resources pointing to elements in PSTN. 2. Gateways that terminate to VoIP. Trunk groups are an important concept here, and represent the finest degree of granularity for policy decisions. Trunk groups can span physical gateways (typical carrier setup for reliability). Comments on the model: Brian Rosen: Mostly he likes. It used to be that this was the picture that everyone had in mind that were big carrier types. Are MGs fading away? Always was the argument that you didn't want to put so much into Gateways, thus the separation. But, Moore's law makes this less meaningful. So, perhaps the trend is to combine. Jon replied that you still need signaling gateways to be separate, since you only have a single point code. Dave Oran said that he thinks that the MGC decomposition is orthogonal. When we talking about IPTEL GWs - MGC is the gateway. Why does this decomposition impact the discussion? Dave also pointed out that an element that's missing from the diagram - show prefixes and trunk groups but don't show carriers. Don't show TGs spanning multiple MGCs. Is that precluded? Jon replied that his next slide deals with Dave's first point on why the decomposition has an impact. As for the second point, in SS7, a signaling switch is limited to a single point code. Dave said that everyone's gotten around that. There may be a case where TGs can't span GWs, but this shouldn't be the model. This is a low level point that might lead people to the wrong conclusion. Back to Jon's presentation. Why does the decomposition impact this? It has to do with attributes availability. An MGC advertises its GWs availability, but smart GWs availability known directly. o Route availability * Are all MGC routes for '+'? Why express preference? * Also other address families o Trunk group availability * Trunks associated with physical interfaces * CSI states (blocked locally/remotely, idle, etc.) * Availability of routes predicted on trunk groups, but often not on a single GW Jon said he really believes that trunk group availability vs. Gateway availability is the true problem to solve. Jonathan asked whether the group believes that this is the problem that is being solved? Discussion: Dave Oran believes this is the problem. Does have some concerns with the attributes and hierarchy. Jon said he's just trying to describe what needs to be done. Dave Oran responded that we need to work through this. He believes that this is the model - need to be able to find routes to resources (described as a PSTN resource). Jonathan added one caveat: believes that this is the problem we're solving, but don't get consumed with large carrier model. We need to worry about smaller gateways as well, were there are no trunk groups, where the gateway itself, or routes, are the things to which attributes are associated. However, we need to derive requirements from this general problem. Jonathan also pointed out that we're not solving SIP to H.323 problem. Took a hum vote: Is this the problem? * Yes? Majority hum * No? No hums! Further discussion: Jon said that he believes this should always be about TGs - believes should treat PRI as a trunk. Cullen asked whether there would ever be more than one carrier on a single trunk? Jon said that there are a number of carriers for virtually every trunk. Due to EA. Dave Oran responded that this has nothing to do with it, as the EA concept user experience doesn't necessarily relate. Take it to the list. Jonathan stopped discussion at this point. Time had run out, and we were not able to cover the last two agenda items: * Requirements (Rosenberg) * Attributes (Bangalore) Conclusion/Actions: * Agreement to use Jon Peterson's model as the basis for the problem to be solved. * Take further discussion of Jon's proposal to the list -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Dec 28 11:42:36 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09449 for ; Fri, 28 Dec 2001 11:42:36 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBSGfBo05538; Fri, 28 Dec 2001 11:41:11 -0500 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBSGPio05431 for ; Fri, 28 Dec 2001 11:25:44 -0500 Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id fBSGPqVZ003638; Fri, 28 Dec 2001 11:25:55 -0500 (EST) Message-ID: <3C2C9CF8.6000900@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Roy, Radhika R, ALCTA" CC: iptel Subject: Re: [IPTEL] draft meeting minutes References: <62DA45D4963FA747BA1B253E266760F9F212E4@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 28 Dec 2001 11:25:28 -0500 Content-Transfer-Encoding: 7bit Roy, Radhika R, ALCTA wrote: > Hi, Everyone: > > In addition to the scenarios presented by Jon Peterson, I will add that > there can be different types of GWs: SIP-ISUP, SIP-H.323, SIP-BICC, etc. > > The GW registration scenarios MUST not exclude any types of GWs. That > is, we must NOT develop the SIP-ISUP GW registration protocol per se. Radhika, this has been discussed on the list, and there was a consensus hum taken on this subject at IETF 52. The consensus was that non-PSTN gateways are OUT OF SCOPE. Now, it may be that the protocol that is developed will work for them anyway, but we are not considering requirements to deal with SIP-H.323 gateways. Let us move on. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Dec 28 11:51:06 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09506 for ; Fri, 28 Dec 2001 11:51:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBSGoDo05651; Fri, 28 Dec 2001 11:50:13 -0500 Received: from kcmso1.proxy.att.com (kcmso1.att.com [192.128.133.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBSGkCo05574 for ; Fri, 28 Dec 2001 11:46:13 -0500 Received: from attrh1i.attrh.att.com ([135.71.62.10]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-3.0) with ESMTP id fBSGk7n00369 for ; Fri, 28 Dec 2001 11:46:07 -0500 (EST) Received: from occlust04evs1.ugd.att.com (135.71.164.12) by attrh1i.attrh.att.com (5.5.029) id 3C0BA3A50015CB3E; Fri, 28 Dec 2001 11:45:55 -0500 content-class: urn:content-classes:message Subject: RE: [IPTEL] draft meeting minutes Message-ID: <62DA45D4963FA747BA1B253E266760F9F21309@OCCLUST04EVS1.ugd.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Thread-Topic: [IPTEL] draft meeting minutes Thread-Index: AcGPvEtfpeMkIPuuEdWnAgCQJ3s5nwAAC/uw X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 From: "Roy, Radhika R, ALCTA" To: "Jonathan Rosenberg" Cc: "iptel" Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by share.research.bell-labs.com id fBSGkDo05575 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Fri, 28 Dec 2001 11:45:54 -0500 Content-Transfer-Encoding: 8bit Comments inline [RRR] -----Original Message----- From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] Sent: Friday, December 28, 2001 11:25 AM To: Roy, Radhika R, ALCTA Cc: iptel Subject: Re: [IPTEL] draft meeting minutes Roy, Radhika R, ALCTA wrote: > Hi, Everyone: > > In addition to the scenarios presented by Jon Peterson, I will add that > there can be different types of GWs: SIP-ISUP, SIP-H.323, SIP-BICC, etc. > > The GW registration scenarios MUST not exclude any types of GWs. That > is, we must NOT develop the SIP-ISUP GW registration protocol per se. Radhika, this has been discussed on the list, and there was a consensus hum taken on this subject at IETF 52. The consensus was that non-PSTN gateways are OUT OF SCOPE. [RRR] I would appreciate if the technical reasons would have been documented. (I have not seen in the meeting minutes.) Now, it may be that the protocol that is developed will work for them anyway, [RRR] Could you please clarify this? Do you mean that the registration protocol can be used/extended for any types of GWs? but we are not considering requirements to deal with SIP-H.323 gateways. [RRR] What are the additional requirements for the SIP-H.323 GWs that the registration protocol will not work? Let us move on. [RRR] Definitely, I would like to move on. [RRR] I am assuming that we will develop the registration protocol considering the SIP-ISUP GW first while the protocol can be extended for other GWs as well. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Dec 29 06:04:33 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26783 for ; Sat, 29 Dec 2001 06:04:33 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBTB38o10516; Sat, 29 Dec 2001 06:03:08 -0500 Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBTB2Co10503 for ; Sat, 29 Dec 2001 06:02:12 -0500 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 GAA03275; Sat, 29 Dec 2001 06:02:11 -0500 (EST) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by bart.cs.columbia.edu (8.12.1/8.12.1) with ESMTP id fBTB25pg028367; Sat, 29 Dec 2001 06:02:06 -0500 (EST) Message-ID: <3C2DA160.677137A7@cs.columbia.edu> From: Henning Schulzrinne Organization: Columbia University X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: "Richard H. Gumpertz" CC: iptel@lists.bell-labs.com Subject: Re: [IPTEL] New draft RFC 2806bis References: <5.1.0.14.2.20011228075140.02681c08@INserverCR.Raviant.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sat, 29 Dec 2001 03:56:32 -0700 Content-Transfer-Encoding: 7bit I don't think this has been discussed in the past. I agree with your analysis - there is no technical reason why %20 (space) couldn't be allowed as a visual separator and since visual separators are exchangeable, there's no reason you'd have to put tel:+1%20212%20555%1234 on a bus or business card. (%20 is not uncommon in mailto and http URLs, as file names commonly allow spaces and mailto permits headers.) In terms of backwards-compatibility: Implementations MUST understand %-escapes anywhere. Thus, tel:+1%32%31%32-%35%35%35-%31%32%33%34 (for tel:+1212-555-1234) is a perfectly valid URL, albeit a bit unusual. Unfortunately, I have only heard from one tel implementor so far. Since having space-separators is common in everyday usage of telephone numbers and E.123 even recommends it, I'm inclined to allow it barring objections from implementors. "Richard H. Gumpertz" wrote: > > I apologize if I am reopening something that has already been beat to death... > > Why is space prohibited as a visual-separator in telephone numbers? Yes, it has to be escaped, which can be ugly, but the end-user may not see that escaping. End users may be dealing with User Interfaces rather than raw URIs and so enhanced readability of the URI is NOT the issue; enhanced readability at the UI level is. Why not allow space as a visual-separator so that such information can be preserved? > > A sentence in 6.1.2 discouraging use of space (due to the ugliness of escaping) as a visual separator seems more appropriate than prohibition. > > On the other hand, I understand that allowing escaped spaces as visual separators might break existing implementations, which could be more costly than any benefit to be gained at this point in time by allowing them. > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Dec 30 23:56:22 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22847 for ; Sun, 30 Dec 2001 23:56:22 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBV4sMo23524; Sun, 30 Dec 2001 23:54:22 -0500 Received: from mail3.dynamicsoft.com ([63.113.44.69]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBV4rio23511 for ; Sun, 30 Dec 2001 23:53:44 -0500 Received: from dynamicsoft.com ([63.113.46.52]) by mail3.dynamicsoft.com (8.12.1/8.12.1) with ESMTP id fBV4rsVZ004306; Sun, 30 Dec 2001 23:53:54 -0500 (EST) Message-ID: <3C2FEF48.1020607@dynamicsoft.com> From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4) Gecko/20011128 Netscape6/6.2.1 X-Accept-Language: en-us MIME-Version: 1.0 To: "Roy, Radhika R, ALCTA" CC: iptel Subject: Re: [IPTEL] draft meeting minutes References: <62DA45D4963FA747BA1B253E266760F9F21309@OCCLUST04EVS1.ugd.att.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Sun, 30 Dec 2001 23:53:28 -0500 Content-Transfer-Encoding: 7bit Roy, Radhika R, ALCTA wrote: > Comments inline [RRR] > >>The GW registration scenarios MUST not exclude any types of GWs. That >>is, we must NOT develop the SIP-ISUP GW registration protocol per se. >> > > > Radhika, this has been discussed on the list, and there was a consensus > hum taken on this subject at IETF 52. The consensus was that non-PSTN > gateways are OUT OF SCOPE. > > [RRR] I would appreciate if the technical reasons would have been > documented. (I have not seen in the meeting minutes.) Its an issue of scope and what problem people agree we are trying to solve. The problem we were chartered to solve, and the problem people want to solve, is managing the resources of a set of PSTN gateways fronted by a proxy. Thus, this is the problem that will drive requirements for the protocol. > Now, it may be that the protocol that is > developed will work for them anyway, > > [RRR] Could you please clarify this? Do you mean that the registration > protocol can be used/extended for any types of GWs? No, I am saying exactly what it says above. The protocol will be driven by requirements to handle the case where a proxy fronts a set of PSTN gateways whose resources it wishes to manage. If, when we are done, it turns out that such a protocol can in fact be used for something that is not a PSTN gateway, well thats fine. But it doesn't drive requirements. > > but we are not considering > requirements to deal with SIP-H.323 gateways. > > [RRR] What are the additional requirements for the SIP-H.323 GWs that > the registration protocol will not work? You have asked for things like address families that are in the form of domain names. We will not consider that as a requirement. In any case, I don't think it makes any sense at all, since if you know the domain name, sounds like DNS is what you want. I fought against the inclusion of domain-name based address families in TRIP in the first place for the same reasons. > [RRR] I am assuming that we will develop the registration protocol > considering the SIP-ISUP GW first while the protocol can be extended for > other GWs as well. You are fixated on protocol conversions. That is not the problem at hand. The type of SS7 protocol is not the primary point; the primary point is that these are PSTN gateways, possibly large ones, with attributes that reflect the fact that there is PSTN connectivity. That means its things like ASR and PDD that need to be conveyed. -Jonathan R. -- Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Avenue Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.jdrosen.net PH: (973) 952-5000 http://www.dynamicsoft.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 31 06:40:00 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA03261 for ; Mon, 31 Dec 2001 06:40:00 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBVBc7o25356; Mon, 31 Dec 2001 06:38:07 -0500 Received: from oak.neustar.com (oak.neustar.com [209.173.53.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBVBbEo25343 for ; Mon, 31 Dec 2001 06:37:14 -0500 Received: from chiimc01.il.neustar.com (dmz1.va.neustar.com [209.173.53.65]) by oak.neustar.com (8.11.0/8.11.0) with ESMTP id fBVBbEb05473 for ; Mon, 31 Dec 2001 06:37:14 -0500 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Dec 2001 05:37:13 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAD48@va02.va.neustar.com> From: "Peterson, Jon" To: iptel Subject: RE: [IPTEL] draft meeting minutes MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 31 Dec 2001 05:37:10 -0600 I wanted to speak a bit to the issue from the minutes below regarding the ubiquitous availability of carriers through trunks in the PSTN, and the relevance of the 'equal access' concept - especially since this a matter on which Dave and I have differed for some time. There are a number of ways (thanks to equal access provisions) that a user can directly or indirectly select a carrier, for example: - Having an entry in the LIDB for their address corresponding to the Carrier Identification Code of their chosen carrier, so that inter-exchange calls generated from their address always pick up this CIC (i.e. PIC LD). - Using a dial-around (101+XXX+address) to override the default CIC for their line. - Dialing a freephone number whose SMS/800 dip returns a CIC code - presumably once the call has been routed to the administrative domain of the carrier, a further internal dip will be performed to translate the freephone number into a geographic number. Dave is certainly correct that a CIC does not necessarily correspond to some physical network - that is, the concept of a 'carrier' chosen by a user is largely a matter of who issues your bill, not what physical infrastructure your call crosses. For example, there are resellers of long-distance service whose CICs are really just aliases for the CIC of a major carrier. Large carriers may own several CICs they use to target their services. It's certainly not some kind of one-to-one mapping from CICs to physical infrastructure. HOWEVER, this doesn't mean that a decision isn't made, in some places in the telephone network, about how a call is routed based on the CIC. In SS7, when a CIC has been selected for a call, it is carried within the TNS or (ANSIfied) CIC parameter of the Initial Address Message. The presence of this parameter modifies how a call is routed through the telephone network, especially at tandems. So, to bring this matter back to trunk groups, one view might be that a given trunk group may be considered to be a route to a CIC if, when an SS7 IAM message carrying this CIC is sent over the trunk group, this call will (eventually) be routed to the administrative domain responsible for the CIC (and presumably get delivered appropriately). One might contend, as an opposing position, that only the carrier that owns the switch on the far side of the trunk should be considered to be reachable through a trunk - but I suspect that in an overflow situation most network would be content to send calls for some other carrier through such a trunk group, even if it introduced a middle-man network, complicating routing and potentially settlement. The correct position is probably somewhere in the middle. One or more CICs may be 'preferred' for a particular trunk by some switch in the network, largely because of who happens to own the equipment on the other side, but in addition all CICs are usually 'available' through such trunks. Something similar, I think, is true of E.164 numbers; certain ranges may be preferred (due to settlement concerns) for particular trunk groups, but all number ranges are usually available. Finally, it's important to note that CICs are national in scope, and that therefore trunk groups are most likely only routes to the set of CICs within a particular nationality. There have been suggestions in the past that identifiers for CICs in the gw reg mechanism should be concatenated with some sort of country code to provide a scope of a CIC - I would agree that this is probably necessary. Then we could refine our characterization of trunk group CIC routes to one in which all carriers for a given nationality could be 'available' through a trunk group. Jon Peterson NeuStar, Inc. > Further discussion: > > Jon said that he believes this should always be about TGs - believes > should treat PRI as a trunk. Cullen asked whether there would ever be > more than one carrier on a single trunk? Jon said that there are a > number of carriers for virtually every trunk. Due to EA. Dave Oran > responded that this has nothing to do with it, as the EA concept user > experience doesn't necessarily relate. Take it to the list. > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 31 07:12:06 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03432 for ; Mon, 31 Dec 2001 07:12:06 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBVBm2o25433; Mon, 31 Dec 2001 06:48:02 -0500 Received: from pine.neustar.com (pine.neustar.com [209.173.57.70]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBVBdEo25368 for ; Mon, 31 Dec 2001 06:39:14 -0500 Received: from chiimc01.il.neustar.com (dmz1.il.neustar.com [209.173.57.65]) by pine.neustar.com (8.11.0/8.11.0) with ESMTP id fBVBdDb11132; Mon, 31 Dec 2001 05:39:13 -0600 Received: by chiimc01.il.neustar.com with Internet Mail Service (5.5.2653.19) id ; Mon, 31 Dec 2001 05:39:13 -0600 Message-ID: <70565611B164D511957A001083FCDD56CAAD49@va02.va.neustar.com> From: "Peterson, Jon" To: iptel , "'hgs@cs.columbia.edu'" Subject: RE: [IPTEL] RFC 2806bis: phone-context, and other issues MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 31 Dec 2001 05:39:09 -0600 A couple of notes on this inline below. Jon Peterson NeuStar, Inc. > -----Original Message----- > From: Henning G. Schulzrinne [mailto:hgs@cs.columbia.edu] > Sent: Saturday, December 22, 2001 2:02 PM > To: iptel@lists.bell-labs.com > Subject: [IPTEL] RFC 2806bis: phone-context, and other issues > > > (I vaguely recall that we agreed in London that discussion should take > place on the iptel list. My apologies if my memory is faulty.) > > I'm finally fulfilling my promise to edit RFC 2806bis ('tel' > URL). Since > this presumably is to go eventually to Draft, I'd like to know how > widely some of the more esoteric features are implemented. Feedback is > most welcome. > > - RFC 2806 allows several 'area-specifier's, as in > > tel:7042;phone-context=+1-212-70;phone-context=+1-212-71 > > Is this an "OR" match? > > Do clients *have* to support this? I've never really understood phone-context. FWIW, I think it's an OR match, yes. 6.1.5 says that if multiple phone-contexts are present, the number is valid in all of the contexts named. Only when a private dialing plan or special national number (like '911') outside the scope of E.164 is in use should a tel URL not be in E.164 format. In these cases, unfortunately, the value of an explicit 'context' in signaling isn't really clear. In an enterprise, for example, where '85062' is a valid number for a station, a 'context' parameter really isn't needed - the '8' is already a context. I'm not sure why 'tel:85062' wouldn't be a better way of representing this number than 'tel:5062;phone-context=8'. After all, this context will never be meaningful outside the enterprise anyway. While some people out there may be implementing phone-context, I wouldn't have high hopes for interoperable versions of it. > > - RFC 2806 allows several service providers, identified by a domain > name. Since there is no current data base that maps domain > name to, say, > 1010xxxx prefixes (US example), it is not clear how implementable this > is. It is also not clear what the client should do if it doesn't > recognize any of them. Try anyway, using some other carrier? > Not try? Is > a URL the right mechanism for conveying this information? Even if there were a database that mapped TSP domains onto Carrier Identification Codes (the XXXX part of 101+XXXX) or vice versa, by itself that might not be all that useful for routing calls. Routing on both the CIC and the TSP have their place. Translating between TSPs and CICs would almost always require some policy decisions; many ITADs with domain names will not even have any associated CICs. I think the right way to think about the TSP is as a destination domain. If the tel URL is used as the userinfo portion of a SIP URI, it should never have the TSP parameter - that should be the host portion of the SIP URI. When converting a tel URL into a SIP URI, the 'tsp' parameter should map directly on to the host portion of the SIP URI. A CIC parameter (and one has been proposed as an extension to the tel URL) on the other hand is relevant primarily to SIP-PSTN interworking (find a gateway where you can reach that CIC). Mapping between these two parameters, or determining which should be used in a given instance, is probably a policy decision. > > - RFC 2806 allows private dial-plan identifiers (e.g., X-COMPANY-NET), > with a registration scheme left for future definition. That's > a bit too > vague for my taste. I propose ditching this or, say, making > it a domain > name. My vote would be to ditch it. Juggling multiple private dial-plans in the PSTN is a huge, proprietary hassle, and I don't think providing a standard way to do it would actually grant anyone leverage on any problem I can imagine. I suspect that the only use of a dial-plan identifier is to provide further 'context' in which a telephone number can be understood so that some other entity, elsewhere in the network, can combine the partial number with the context to get a complete, E.164-ish number. Again, wouldn't be clear to me why, if the entity creating the tel URL knows its context, it wouldn't use the context to create a global number to start with - or why any entity receiving the URL would get any advantage from being able to process the dialing plan itself. I'm a little surprised to hear it's being used. > > All of these seem like features that should be added later, as > extensions, once we understand how they can be useful. Unless we have > two interoperable implementations, they'll have to be dropped in any > event. Thus, please let me know if you either have > implemented these or > plan to implement these. > > Also, this would be a good opportunity to remind me of any > other issues > or extensions that should go into the 2806bis draft. > > Thanks. > > Henning > -- > Henning Schulzrinne http://www.cs.columbia.edu/~hgs > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 31 14:14:43 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06108 for ; Mon, 31 Dec 2001 14:14:43 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBVJD3o27345; Mon, 31 Dec 2001 14:13:03 -0500 Received: from imo-r01.mx.aol.com (imo-r01.mx.aol.com [152.163.225.97]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBVJCdo27332 for ; Mon, 31 Dec 2001 14:12:39 -0500 Received: from Mpierce1@aol.com by imo-r01.mx.aol.com (mail_out_v31_r1.9.) id r.128.a2462df (24897) for ; Mon, 31 Dec 2001 14:12:31 -0500 (EST) From: Mpierce1@aol.com Message-ID: <128.a2462df.2962129b@aol.com> To: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Subject: [IPTEL] Definition of "trunk group" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 31 Dec 2001 14:12:27 EST Content-Transfer-Encoding: 7bit I have the following comments concerning the use of the term "trunk groups" based on the presentation in SLC and the discussion on the list: I believe that a lot of the disagreement is related to the definition and concept of what a "trunk group" is. There was mention of a "trunk group" being those facilities through which one could get to a specific destination or reach a specific set of carriers. Also, the presentation showed a trunk group split across multiple Gateways. For reference, the following 2 definitions come from American National Standard T1.523-2001: trunk: 1. In a communications network, a single transmission channel between two points that are switching centers or nodes, or both. 2. [A] circuit between switchboards or other switching equipment, as distinguished from circuits which extend between central office switching equipment and information origination/termination equipment. [47 CFR Pt.36-A] Note: Trunks may be used to interconnect switches, such as major, minor, public and private switches, to form networks. trunk group: Two or more trunks of the same type between two given points. The definition of "trunk group" in telephony does not include where you can get to by going through it. As noted in SLC, in many cases, all destinations can be reached through a specific trunk group due to the routing which the next switch may do. Basic requirements in the US are that all carriers can be reached by the end user, so, in some cases, when talking about a trunk group from a Gateway which serves as the user's originating end office, that trunk group can reach every carrier and every destination. In others, if the trunk group in question connects to a specific carrier (the termination "point" of the trunk group), then it is likely that it can only reach that one carrier. When talking about a trunk group terminating at an end office (or a Gateway) then it can probably only reach destination connected to that end office. It is not correct to depict a trunk group split between two Gateways unless the 2 Gateways are simply 2 physical devices which act as a single switching "point" controlled by a single MGC. In this case, the 2 physical devices are really 1 single Gateway for purposes of architecture and signaling with other MG/MGCs. This issue in IPTEL can be simplified if the definition for "trunk group" in T1.523 (which is consistent with the usage in ITU-T) is accepted. A further definition in T1.523 is: route list: A specific list of trunk groups. [After T1.667-1999] This is more similar to the term "trunk group" as being used in the IPTEL discussions. The function of "routing" a specific destination address in any switching element results in the determination of a "route list", which points to a list of trunk groups (alternate routes). Mike Pierce Artel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Dec 31 17:27:29 2001 Received: from share.research.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07539 for ; Mon, 31 Dec 2001 17:27:29 -0500 (EST) Received: from share.research.bell-labs.com (localhost [127.0.0.1]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBVM48o28252; Mon, 31 Dec 2001 17:04:08 -0500 Received: from imo-d07.mx.aol.com (imo-d07.mx.aol.com [205.188.157.39]) by share.research.bell-labs.com (8.11.6/8.11.6) with ESMTP id fBVM3wo28239 for ; Mon, 31 Dec 2001 17:03:58 -0500 Received: from Mpierce1@aol.com by imo-d07.mx.aol.com (mail_out_v31_r1.9.) id r.e5.1186c851 (24899) for ; Mon, 31 Dec 2001 17:03:47 -0500 (EST) From: Mpierce1@aol.com Message-ID: To: iptel@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: AOL 5.0 for Windows sub 138 Subject: [IPTEL] Comments on RFC 2806 revision (tel url) Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-BeenThere: iptel@lists.bell-labs.com X-Mailman-Version: 2.0.8 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: List-Unsubscribe: , List-Archive: Date: Mon, 31 Dec 2001 17:03:43 EST Content-Transfer-Encoding: 7bit To all, I believe that mention of this RFC in Minneapolis in the March 2001 meeting indicated that there was a general feeling that there were significant problems with the current text and a rewrite was required. Based on this, I will make some rather substantial comments on the current text, with the understanding that they propose some significant changes to the concept and details described. The text of RFC 2806 seems to confuse the controls that might be needed between a controller and the device doing outgoing dialing (e.g., MGC and MG) with what is required in the url to designate the destination (location). For example, it takes the AT modem commands for pauses and waits for dial tone and includes them with the url. While there may be cases in which one specific network element (e.g., a MG) needs to apply these techniques in order to send digits (DTMF or dial pulse) to another element (e.g., a circuit switched PBX), the originator of the call knows nothing about this, so this information should not be a part of the url. In fact, due to alternate routing, two calls with the same url might be treated differently because they are routed differently. This type of dialing in which the originator needed to know the routing in order to formulate the digit string was eliminated from most telephony switching environments long ago. The definition of specific "tel", "fax", and "modem" urls ignores the existence of customer premise devices currently in use which allow the connection of telephones, faxs, and modems on the same telephone line (using the same telephone number). In reality, there is no difference in the urls needed for the 3 cases mentioned. The current telephony network is based on there being no difference within the network for these different uses. If other information needs to be carried (e.g., to specify the type of modem supported) this should be separate from the url and may be ignored by some equipment. This type information should not be a part of the url, since it does not provide an identification of the "resource location". If it did, this would then imply, for example, that the following define different locations, that is, must be routed differently: modem:+1-410-555-1234;type=v32b modem:+1-410-555-1234;type=v21 modem:+1-410-555-1234;type=x75 "Post dial" should not be a part of the url. The example given in Section 2.2 of accessing a voice mailbox shows the mistake. The digits to be dialed by the caller when accessing a voice mailbox depend on the voice prompt from that mailbox system after setup of the initial call. For this reason, the possible post-dialing digits can not be a part of the url. There is a fundamental problem in that the urls being described in this RFC serve both as a user visible address (like on a letterhead or on a web page) and as the inter-network element signaling protocol (e.g., part of SIP). It is noted that E.123, which is referenced, only addresses the representation of numbers, for example, on letterhead. This dual purpose of the url being defined leads to confusion in the description. For example, while some signaling relationships may need to be able to code the extra preliminary prefix digits needed to do special things (like the "0w00" in the 5th example in Section 2.6), this would never be a part of the url as printed or visible on a web page, since it is dependent on the location and equipment of the originator. In the telephony world, the digits 0-9 are represented in signaling only by those numbers, However, the user may see the address with these numbers replaced by letters. Since the url being defined here is intended to be seen by the user (as also defined in E.123), it is essential that it be allowed to include letters (not the A, B, C, D that are used to designate the extra 4 codes possible on a DTMF key pad). As E.123 states, "diallable symbols ... can be digits, letters, or other signs." Of course, this causes a problem if one tries to incorporate the 4 extra DTMF codes into the same address string. However, in the ITU-T E.164 numbering plan, these extra DTMF codes can not be part of the address. The international number is limited to 15 digits, each being a numeral 0-9. So, in the tel: url beginning with +, there is no problem with allowing letters a-z. Of course, this depends on the association between letters and numbers being as recommended in E.161. For this reason, users are advised to avoid using letters to specify telephone numbers in international service, but they may. The 1st, 2nd, and 3rd examples in Section 2.6 show a problem with this scheme of treating tel, fax, and modem separately. The three examples use the same number, which can really occur. As shown, the three identical numbers must all result in exactly the same call setup regardless of the extra parameters. Whether it is treated as a telephone or fax or modem call depends on the kinds of equipment connected and the in-band signals which occur. The 4th example in Section 2.6 show the problem with the post-dial logic. While there may be valid case to support the extra digits needed to directly dial into a PBX at the destination in order to directly reach an extension, that capability needs to be under control of the destination. Only the destination knows whether DTMF or dial-pulse or something else is needed to signal to the final entity. The originating entity does not even need to know that there is an extension number present if it is a part of the complete number (as happens in the US all the time with DID). If the extension number is in addition to the regular international number (which is limited to 15 digits), then the originating entity might know that there are additional digits, but still has no knowledge of how the destination is going to signal them (e.g., to a PBX). The other example of the origination entity needing of enter DTMF to invoke a particular service would require an audible response returned from the destination after call set before these additional DTMF digits are sent. Therefore, they can not be part of the url in this case. The text of the 5th example indicates the problem with this form of the url. It states "this kind of phone umber MUST NOT be used in an environment where all users of this URL might not be able to successfully dial out by using this number directly." Since such a phone number contained on a "company intranet" or printed material would be accessible by many people in various places, this will not work. The method used, and the format of the url, should follow the procedures developed over many decades of such situations in the telephony world. The telephone number needs to be shown in a standard local or international format and the user needs to understand how to dial it from their location (e.g., by dialing "0", waiting for dial tone, and then dialling "00" for international access because the local telephone book says to do this). Clearly, when the originating user has a computerized user agent (SIP phone), it can do this thinking for the person based on dialing rules that it has been provisioned with, so the human doesn't have to worry about it. That means that the url on a web page must be in one of the standard formats (no extra prefix digits). In some environments, there may in fact be multiple ways to dial a specific destination. Today the user may decide which to use and the new user agent (SIP phone) can also do so, so it should not be a part of the url. Since the 6th example shows a telephone number in country code 1, it should be following by a legitimate 10-digit number so as to not confuse. Further, the idea should be represented with a better example. It is unknown of any case in which an E.164 telephone number (in North America) would be specified, but it is only "usable" within that area code. Perhaps the example would be better if it were to specify a number usable only within a specific country. I suggest that this RFC be pared down to simply defining the url for a "telephone" number and that additional parameters that might control call setup, such as modem capabilities, should be a part of SIP or a supplementary draft that specifically describes additions to SIP for fax and modem calls. Mike Pierce Artel _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel