From mailman-owner@lists.bell-labs.com Tue Aug 1 05:16:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA05970 for ; Tue, 1 Aug 2000 05:16:17 -0400 (EDT) From: mailman-owner@lists.bell-labs.com Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6A512446FD for ; Tue, 1 Aug 2000 05:07:10 -0400 (EDT) Subject: lists.bell-labs.com mailing list memberships reminder To: iptel-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.1 Precedence: bulk List-Id: Message-Id: <20000801090710.6A512446FD@lists.bell-labs.com> Date: Tue, 1 Aug 2000 05:07:10 -0400 (EDT) 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@lists.ietf.org From iptel-admin@lists.bell-labs.com Tue Aug 1 09:12:52 2000 Received: 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 JAA01514 for ; Tue, 1 Aug 2000 09:12:52 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D82E244336; Tue, 1 Aug 2000 09:12:45 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 87E824433B for ; Mon, 31 Jul 2000 22:58:18 -0400 (EDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id DB0881E027 for ; Mon, 31 Jul 2000 22:58:17 -0400 (EDT) Received: from research.att.com ([135.210.107.169]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id WAA14716 for ; Mon, 31 Jul 2000 22:58:15 -0400 (EDT) Message-ID: <39863C70.1C204D72@research.att.com> Date: Mon, 31 Jul 2000 22:56:48 -0400 From: "Gregory W. Bond" Organization: AT&T Labs - Research, Florham Park, NJ X-Mailer: Mozilla 4.72 [en] (Win98; I) 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] IP Telecom Services Workshop 2000: Call for Participation Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit [Please accept our apologies for multiple copies of this call.] ------------- CALL FOR PARTICIPATION --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. We have put together an excellent technical program that includes 8 original research papers, a plenary talk, and a round table discussion. We look forward to the participation from you and your colleagues in the telecom industry and the research community. TECHNICAL PROGRAM Plenary Talk - speaker to be announced DFC as the basis for ECLIPSE, an IP communications software platform Greg Bond, Eric Cheung, Andrew Forrest, Michael Jackson, Hal Purdy, Chris Ramming, and Pamela Zave AT&T Labs Research Experimenting with PARLAY in a SIP Environment: Early Results Stephane Desrochers, Roch H. Glitho, Kindy Sylla Ericsson Research Canada Approach For Services in Converged Networks Sanjiv Kapur, Rakesh Vij Hughes Software Systems Unified Messaging using SIP and RTSP Kundan Singh and Henning Schulzrinne Columbia University SPHINX: A Study in Convergent Telephony Kumar V. Vemuri Lucent Technologies SPHINX: Advanced Scenarios for H.323-SIP Interoperation Kumar V. Vemuri Lucent Technologies Where Should Services Reside in Internet Telephony Systems? Xiaotao Wu and Henning Schulzrinne Columbia University A Transformation Approach for Service Creation in a Hybrid IP-IN Network Cyril Carrez, Elie Najm, Alexandre Tauveron Ecole Nationale Superieure des Telecom Roundtable Discussion - topic to be announced CONFERENCE VENUE AND RELATED EVENTS IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Registration details about Fall 2000 VON can be found at http://pulver.com. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com). WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Aug 1 13:37:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA11350 for ; Tue, 1 Aug 2000 13:37:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C512444401; Tue, 1 Aug 2000 13:37:14 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by lists.bell-labs.com (Postfix) with ESMTP id 912B5443BD for ; Tue, 1 Aug 2000 13:37:02 -0400 (EDT) Received: from tot-wm.proxy.aol.com (tot-wm1-wl.proxy.aol.com [205.188.199.3]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id NAA24493 for ; Tue, 1 Aug 2000 13:37:00 -0400 (EDT) Received: from orit (AC94A1BC.ipt.aol.com [172.148.161.188]) by tot-wm.proxy.aol.com (8.10.0/8.10.0) with SMTP id e71HaNj09628 for ; Tue, 1 Aug 2000 13:36:25 -0400 (EDT) Message-ID: <000001bffbe0$d708fdc0$cca5fea9@orit.us.radvision.com> Reply-To: "Orit Levin" From: "Orit Levin" To: "IPTEL WG" Date: Mon, 31 Jul 2000 21:05:12 -0400 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: multipart/mixed; boundary="----=_NextPart_000_0014_01BFFB33.04851E40" X-Apparently-From: OritOrit@aol.com Subject: [IPTEL] A draft of H323-URL to be presented during the IPTEL session Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_0014_01BFFB33.04851E40 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0015_01BFFB33.04851E40" ------=_NextPart_001_0015_01BFFB33.04851E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello! I have submitted the attached draft 3 weeks ago. Unfortunately, the document doesn't appear on the IETF Drafts site. Since this topic is going to be presented during the IPTEL session on = Thursday morning, I am attaching the draft for you review. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com -----Original Message----- From: Orit Levin To: internet-drafts@ietf.org Date: Tuesday, July 11, 2000 1:59 AM Subject: Request for Draft Submission=20 Hello! I would like to submit the attached paper as the first drafts to become = an Informational RFC. Thank you, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com ------=_NextPart_001_0015_01BFFB33.04851E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello!
I have submitted the attached draft 3 weeks = ago.
Unfortunately, the document doesn't appear on = the IETF=20 Drafts site.
Since this topic is going to be presented during the = IPTEL=20 session on Thursday morning, I am attaching the draft for you=20 review.
Best Regards,
Orit Levin
RADVision Inc.
575 Corporate Drive Suite = 420
Mahwah, NJ=20 07430
Tel: 1 201 529 4300  (230)
Fax: 1 201 529 3516
www.radvision.com
orit@radvision.com
-----Original = Message-----
From:=20 Orit Levin <orit@radvision.com>
To: = internet-drafts@ietf.org = <internet-drafts@ietf.org>=
Date:=20 Tuesday, July 11, 2000 1:59 AM
Subject: Request for Draft=20 Submission

Hello!
I would like to submit the attached paper as the = first drafts=20 to become an Informational RFC.
Thank you,
Orit Levin
RADVision Inc.
575 Corporate Drive = Suite=20 420
Mahwah, NJ 07430
Tel: 1 201 529 4300  (230)
Fax: 1 201 = 529=20 3516
www.radvision.com
orit@radvision.com
------=_NextPart_001_0015_01BFFB33.04851E40-- ------=_NextPart_000_0014_01BFFB33.04851E40 Content-Type: application/msword; name="draft-levin-h323-url-scheme-00.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="draft-levin-h323-url-scheme-00.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAACAAAAoQAAAAAAAAAA EAAAgQAAAAEAAAD+////AAAAAKMAAACiAAAA//////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////+ /wAABAoCAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACYAQAAEgAAAAEA AACYAAAAAgAAAKAAAAADAAAAwAAAAAQAAADMAAAABQAAAOAAAAAGAAAA7AAAAAcAAAD4AAAACAAA AAwBAAAJAAAAIAEAABIAAAAsAQAACgAAAEgBAAALAAAAVAEAAAwAAABgAQAADQAAAGwBAAAOAAAA eAEAAA8AAACAAQAAEAAAAIgBAAATAAAAkAEAAAIAAADkBAAAHgAAABYAAABOZXR3b3JrIFdvcmtp bmcgR3JvdXAAOAAeAAAAAQAAAABldHceAAAADAAAAE1pa2UgR2Focm5zAB4AAAABAAAAAGlrZR4A AAABAAAAAGlrZR4AAAALAAAATm9ybWFsLmRvdAAAHgAAAAsAAABPcml0IExldmluAAAeAAAAAgAA ADkAaXQeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDguMAB1QAAAAADUrfQBAAAAQAAAAADio2hY6L8B QAAAAACmM3bX6b8BQAAAAAAqzXnj6b8BAwAAAAEAAAADAAAAtgMAAAMAAAAsFQAAAwAAAAAAAAAw AAAAAAAAAAAAAABPRkZJQ0UAAAAAAAD5QQCgoElCADwAQAAsCkEAAAAAAMYAAAAAhAAAFAAAAP7/ AAAECgIAAAAAAAAAAAAAAAAAAAAAAAIAAAAC1c3VnC4bEJOXCAArLPmuRAAAAAXVzdWcLhsQk5cI ACss+a5AAQAA/AAAAAwAAAABAAAAaAAAAA8AAABwAAAABQAAAHwAAAAGAAAAhAAAABEAAACMAAAA FwAAAJQAAAALAAAAnAAAABAAAACkAAAAEwAAAKwAAAAWAAAAtAAAAA0AAAC8AAAADAAAAN4AAAAC AAAA5AQAAB4AAAACAAAAIABvAAMAAAAtAAAAAwAAAAoAAAADAAAAABoAAAMAAABqEAgACwAAAAAA AAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAQAAABYAAABOZXR3b3JrIFdvcmtpbmcgR3Jv dXAADBAAAAIAAAAeAAAABgAAAFRpdGxlAAMAAAABAAAAhAEAAAQAAAAAAAAAKAAAAAEAAABSAAAA AgAAAFoAAAADAAAAsgAAAAIAAAACAAAACgAAAF9QSURfR1VJRAADAAAADAAAAF9QSURfSExJTktT AAIAAADkBAAAQQAAAE4AAAB7AEEARAAyADUAOAA1ADMAQQAtADUANQAxAEQALQAxADEARAAwAC0A OABGADcANQAtADAAMABBADAAQwA5ADEANQAzADUANQBCAH0AAAAAAEEAAADIAAAADAAAAAMAB08u IExldmluBwdJbnRlcm5ldCBEcmFmdAdSQURWaXNpb24HB0RvY3VtZW50OiBkcmFmdC1sZXZpbi1o MzIzLXVybC1zY2hlbWUtMDAudHh0PgdKdWx5IDIwMDAHB0NhdGVnb3J5OiBJbmZvcm1hdGlvbmFs BwcHDQ1ILjMyMyBVUkwgc2NoZW1lIGRlZmluaXRpb24NDQ1TdGF0dXMgb2YgdGhpcyBNZW1vDQ1U aGlzIGRvY3VtZW50IGlzIGFuIEludGVybmV0LURyYWZ0IGFuZCBpcyBOT1Qgb2ZmZXJlZCBpbiBh Y2NvcmRhbmNlIHdpdGggU2VjdGlvbiAxMCBvZiBSRkMyMDI2LCBhbmQgdGhlIGF1dGhvciBkb2Vz IG5vdCBwcm92aWRlIHRoZSBJRVRGIHdpdGggYW55IHJpZ2h0cyBvdGhlciB0aGFuIHRvIHB1Ymxp c2ggYXMgYW4gSW50ZXJuZXQtRHJhZnQgDQ1JbnRlcm5ldC1EcmFmdHMgYXJlIHdvcmtpbmcgZG9j dW1lbnRzIG9mIHRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRGKSwgaXRz IGFyZWFzLCBhbmQgaXRzIHdvcmtpbmcgZ3JvdXBzLiBOb3RlIHRoYXQgb3RoZXIgZ3JvdXBzIG1h eSBhbHNvIGRpc3RyaWJ1dGUgd29ya2luZyBkb2N1bWVudHMgYXMgSW50ZXJuZXQtRHJhZnRzLiBJ bnRlcm5ldC1EcmFmdHMgYXJlIGRyYWZ0IGRvY3VtZW50cyB2YWxpZCBmb3IgYSBtYXhpbXVtIG9m IHNpeCBtb250aHMgYW5kIG1heSBiZSB1cGRhdGVkLCByZXBsYWNlZCwgb3Igb2Jzb2xldGVkIGJ5 IG90aGVyIGRvY3VtZW50cyBhdCBhbnkgdGltZS4gSXQgaXMgaW5hcHByb3ByaWF0ZSB0byB1c2Ug SW50ZXJuZXQtIERyYWZ0cyBhcyByZWZlcmVuY2UgbWF0ZXJpYWwgb3IgdG8gY2l0ZSB0aGVtIG90 aGVyIHRoYW4gYXMgIndvcmsgaW4gcHJvZ3Jlc3MuIiANVGhlIGxpc3Qgb2YgY3VycmVudCBJbnRl cm5ldC1EcmFmdHMgY2FuIGJlIGFjY2Vzc2VkIGF0IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaWV0Zi8x aWQtYWJzdHJhY3RzLnR4dCANVGhlIGxpc3Qgb2YgSW50ZXJuZXQtRHJhZnQgU2hhZG93IERpcmVj dG9yaWVzIGNhbiBiZSBhY2Nlc3NlZCBhdCBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1s Lg0NDQ0NDTEuIEFic3RyYWN0DQ1ILjMyMyBTcGVjaWZpY2F0aW9uIFszXSBhbmQgSC4yMjUuMCBb NF0gdG9nZXRoZXIgZGVmaW5lIGEgc3lzdGVtIGFuZCBhIHNldCBvZiBwcm90b2NvbHMgZm9yIG11 bHRpbWVkaWEgY29tbXVuaWNhdGlvbnMgc2VydmljZXMgb3ZlciBQYWNrZXQgQmFzZWQgTmV0d29y a3MgKFBCTikuICAgSC4yMjUuMCBbNF0gbWVzc2FnZXMgZGVmaW5lIG1lYW5zIGZvciBjYXJyeWlu ZyBhbnkgc3RhbmRhcmQgVVJMIChVbmlmb3JtIFJlc291cmNlIExvY2F0b3JzKSBpbiBvcmRlciB0 byBzcGVjaWZ5IHNvdXJjZSBhbmQgZGVzdGluYXRpb24sIGludm9sdmVkIGluIHRoZSBjYWxsLiBT dGFydGluZyBmcm9tIEguMzIzdi40LCBILjMyMyBVUkwgaXMgZGVmaW5lZCBpbiBvcmRlciB0byBz cGVjaWZ5IEguMzIzIHBhcnR5IGludm9sdmVkIGluIHRoZSBjYWxsLiBUaGlzIEgzMjMtVVJMIGRl ZmluaXRpb24gaGFzIGEgZm9ybSBvZiATIEhZUEVSTElOSyBtYWlsdG86dXNlckBob3N0IAEUdXNl ckBob3N0FSB3aGVyZSB1c2VyIGNvcnJlc3BvbmRzIHRvIGVuZHBvaW50knMgYWxpYXMgYW5kIGhv c3QgY29ycmVzcG9uZHMgdG8gaXRzIGRvbWFpbi96b25lL2dhdGVrZWVwZXIgKGluIHRlcm1zIG9m IFszXSkuDVRoZSBwdXJwb3NlIG9mIHRoaXMgZG9jdW1lbnQgaXMgdG8gcmVnaXN0ZXIgdGhlIHNw ZWNpZmllZCAoYW5kIHByZXNlbnRlZCBiZWxvdykgSC4zMjMgVVJMIHNjaGVtZSB3aXRoaW4gSUFO QS4gVGhpcyB3aWxsIGFsbG93IGZvciBpbXByb3ZlZCByZXNvdXJjZXMgdXNlIGFuZCBpbnRlZ3Jh dGlvbiBvdmVyIHRoZSBJbnRlcm5ldC4NDQ0yLiBDb252ZW50aW9ucyB1c2VkIGluIHRoaXMgZG9j dW1lbnQNDQ1UaGUga2V5IHdvcmRzICJNVVNUIiwgIk1VU1QgTk9UIiwgIlJFUVVJUkVEIiwgIlNI QUxMIiwgIlNIQUxMIE5PVCIsICJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNPTU1FTkRFRCIs ICAiTUFZIiwgYW5kICJPUFRJT05BTCIgaW4gdGhpcyBkb2N1bWVudCBhcmUgdG8gYmUgaW50ZXJw cmV0ZWQgYXMgZGVzY3JpYmVkIGluIFJGQy0yMTE5IFsCXS4NDQ0zLiBVUkwgc2NoZW1lIG5hbWUN DVRha2luZyBpbnRvIGNvbnNpZGVyYXRpb24gdGhlIGd1aWRlbGluZXMgb2YgUkZDLTI3MTdbMTJd LCB0aGUgcHJvcG9zYWwgaXMgdG8gcmVnaXN0ZXIgdGhlIEguMzIzIFVSTCBzY2hlbWUsIG5hbWVk IJNIMzIzlCwgd2l0aGluIHRoZSBJRVRGIHRyZWUuIEl0IGlzIGRlc3BpdGUgdGhlIGZhY3QsIHRo YXQgSC4zMjMgaGFzIGJlZW4gZGVmaW5lZCBieSBJVFUtVC4NSC4zMjMgaGFzIGJlZW4gd2lkZWx5 IGRlcGxveWVkIHRvZGF5IGFuZCBpcyB1c2VkIHNpZGUtYnktc2lkZSB3aXRoIG90aGVyIEludGVy bmV0IHByb3RvY29scyBhbmQgdGVjaG5vbG9naWVzLiBXZSB3b3VsZCBsaWtlIHRvIHByZXZlbnQg dGhlIHNlZ21lbnRhdGlvbiBvZiBVUkwgc2NoZW1lIGRlZmluaXRpb25zLCBiZWxvbmdpbmcgdG8g dGhlIHNhbWUgZ3JvdXAgb2YgYXBwbGljYXRpb25zIGFuZCBydW5uaW5nIG9uIHRoZSBzYW1lIE5l dHdvcmtzLiANDQ00LiBVUkwgc2NoZW1lIGZvcm1hbCBzeW50YXggZGVmaW5pdGlvbiBhbmQgY2hh cmFjdGVyIGVuY29kaW5nIGNvbnNpZGVyYXRpb25zDVRoZSBILjMyMyBVUkwgaXMgZGVmaW5lZCBp biBBQk5GIGFzIHNob3duIGJlbG93LiBJdCB1dGlsaXplcyB0aGUgQ29yZSBSdWxlcyBzcGVjaWZp ZWQgaW4gc2VjdGlvbiA2LjEgb2YgUkZDLTIyMzQgWzJdLg0NQXMgaW5kaWNhdGVkIGluIHRoZSBz eW50YXgsIHRoZSB1c2VyIHN0cmluZyBhbmQgdGhlIGhvc3Rwb3J0IHN0cmluZyBhcmUgYm90aCBv cHRpb25hbCwgdGhvdWdoIGF0IGxlYXN0IG9uZSBzaGFsbCBiZSBwcmVzZW50Lg0NVGhlIEguMzIz IFVSTCBpcyBub3QgY2FzZSBzZW5zaXRpdmUuDQ1IMzIzLVVSTCA9ICJIMzIzOiIgWyB1c2VyIF0g WyAiQCIgaG9zdHBvcnQgXQt1c2VyCQkJCT0JdW5yZXNlcnZlZCAvIGVzY2FwZWQNCWhvc3Rwb3J0 CQkJPQlob3N0IFsiOiIgcG9ydF0NaG9zdAkJCQk9CWhvc3RuYW1lIC8gSVB2NGFkZHJlc3MgLyBJ UHY2cmVmZXJlbmNlDWhvc3RuYW1lCQkJPQkqKCBkb21haW5sYWJlbCAiLiIgKSB0b3BsYWJlbCBb ICIuIiBdDWRvbWFpbmxhYmVsCQk9CWFscGhhbnVtIC8gYWxwaGFudW0gKiggYWxwaGFudW0gLyAi LSIgKSBhbHBoYW51bQ10b3BsYWJlbAkJCT0JQUxQSEEgLyBBTFBIQSAqKCBhbHBoYW51bSAvICIt IiApIGFscGhhbnVtDUlQdjRhZGRyZXNzCQk9CTEqM0RJR0lUICIuIiAxKjNESUdJVCAiLiIgMSoz RElHSVQgIi4iIDEqM0RJR0lUDUlQdjZyZWZlcmVuY2UJCT0JIlsiIElQdjZhZGRyZXNzICJdIg1J UFY2YWRkcmVzcwkJPQloZXhwYXJ0IFsgIjoiIElQdjRhZGRyZXNzIF0NaGV4cGFydAkJCT0JaGV4 c2VxIC8gaGV4c2VxICI6OiIgWyBoZXhzZXEgXSAvICI6OiIgWyBoZXhzZXEgXQ1oZXhzZXEJCQk9 CWhleDQgKiggIjoiIGhleDQpC2hleDQJCQkJPQkxKjRIRVhESUcNcG9ydAkJCQk9CTEqRElHSVQN dW5yZXNlcnZlZAkJPQlhbHBoYW51bSAvIG1hcmsNYWxwaGFudW0JCQk9CUFMUEhBIC8gRElHSVQN bWFyawkJCQk9CSItIiAvICJfIiAvICIuIiAvICIhIiAvICJ+IiAvICIqIiAvICInIg0JCQkJLwki KCIgLyAiKSIgLyAiJiIgLyAiPSIgLyAiKyIgLyAiJCIgLyAiLCINZXNjYXBlZAkJCT0JIiUiIEhF WERJRyBIRVhESUcNDQ0NNS4gSW50ZW5kZWQgVXNhZ2UNDU9uZSBvZiB0aGUgYWxpYXMgdHlwZXMg ZGVmaW5lZCBieSBILjMyMyBbM10gaXMgdGhlIHVybC1JRCwgd2hpY2ggaXMgaW50ZW5kZWQgdG8g Y29udGFpbiBzdGFuZGFyZCBVUkwgc2NoZW1lcyB0aGF0IG1heSBiZSB1c2VkIHRvIHJlYWNoIHJl c291cmNlcy4NSW4gYWRkaXRpb24sIFVSTHMgYXJlIHdpdGhpbiBBbm5leCBLL0guMzIzIFsxMV0g YW5kIG1heSBiZSB1c2VkIGluIG90aGVyIHNlcnZpY2VzIGFkZGVkIHRvIEguMzIzIGluIHRoZSBm dXR1cmUuIEFuIEguMzIzIGVudGl0eSBtYXkgYWNjZXB0IGFueSB2YWxpZCBVUkwgdGhhdCBpdCB1 bmRlcnN0YW5kcywgYnV0IHNob3VsZCBzdXBwb3J0IHRoZSBILjMyMyBVUkwgYXMgZGVmaW5lZCBp biB0aGlzIHNlY3Rpb24uDVRoZSBILjMyMyBVUkwgaXMgaW50ZW5kZWQgdG8gaGVscCBhbiBlbnRp dHkgcmVzb2x2ZSB0aGUgYWRkcmVzcyBvZiBhbm90aGVyIEguMzIzIGVudGl0eS4gSXQgaXMgY29t cG9zZWQgb2YgdHdvIHBhcnRzOiB0aGUgdXNlciBhbmQgdGhlIGhvc3Rwb3J0LiBUaGUgdXNlciBz cGVjaWZpZXMgYW4gYWxpYXMgZm9yIHRoZSBlbnRpdHksIHN1Y2ggYXMgYSB1c2VyIG9yIGEgc2Vy dmljZSwgd2l0aG91dCBjYXJyeWluZyBpbmZvcm1hdGlvbiBhYm91dCB0aGUgbG9jYXRpb24gb2Yg dGhlIGVudGl0eS4gVGhlIGhvc3Rwb3J0LCBvbiB0aGUgb3RoZXIgaGFuZCwgbWF5IHNwZWNpZnkg dGhlIHRyYW5zcG9ydCBhZGRyZXNzIG9mIGEgR2F0ZWtlZXBlciwgYSBHYXRla2VlcGVyIElkZW50 aWZpZXIsIG9yIHRoZSBmdWxseSBxdWFsaWZpZWQgZG9tYWluIG5hbWUgb2YgdGhlIEdhdGVrZWVw ZXIsIGFsb25nIHdpdGggYW4gb3B0aW9uYWwgcG9ydCBudW1iZXIgZm9yIFJBUyBjb21tdW5pY2F0 aW9uLg0NDTYuIEFwcGxpY2F0aW9ucyBhbmQvb3IgcHJvdG9jb2xzIHdoaWNoIG1heSB1c2UgdGhp cyBVUkwgc2NoZW1lIG5hbWUNDUguMzIzIFVSTCBtYXkgYmUgY2FycmllZCBieSBhbm90aGVyIHBy b3RvY29scywgc3VjaCBhcyBTSVAgWzZdLiBJdCBpcyBmZWFzaWJsZSB3aGVuIHRoZSBpbmZvcm1h dGlvbiBhYm91dCBkZXN0aW5hdGlvbiAob3Igc291cmNlKSBwcm90b2NvbCBzdXBwb3J0IGlzIGtu b3duIGFzIGEgcGFydCBvZiBpdHMgVVJMLiBGb3IgZXhhbXBsZSwgdGhhdCB3b3VsZCBmYWNpbGl0 YXRlIFNJUC1ILjMyMyBpbnRlcm9wZXJhYmlsaXR5IChkaXNjdXNzZWQgaW4gWzddKSBpbiBtb3Jl IGVmZmljaWVudCBtYW5uZXIuDQ0NNy4gU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNDUguMzIzIFVS TCBkZWZpbml0aW9uIGNvbmNlcHR1YWxseSBoYXMgdGhlIHNhbWUgYXBwcm9hY2ggYXMgYWxyZWFk eSBkZWZpbmVkIGFuZCB3aWRlbHkgdXNlZCBvdGhlciBVUkwgc2NoZW1lcywgc3VjaCBhcyBbN10u DVdoZW4gSC4zMjMgVVJMIGlzIGNhcnJpZWQgd2l0aGluIEguMjI1LjAgWzRdIG1lc3NhZ2VzIHRo ZSBzZWN1cml0eSBpcyBhZGRyZXNzZWQgYnkgSC4zMjMgU2VjdXJpdHkgZnJhbWV3b3JrIFs1XS4g V2hlbiBILjMyMyBVUkwgaXMgY2FycmllZCB3aXRoaW4gb3RoZXIgcHJvdG9jb2xzIChzdWNoIGFz IFNJUCBbNl0pLCB0aGUgc2VjdXJpdHkgaXMgYWRkcmVzc2VkIHdpdGhpbiB0aGUgY29ycmVzcG9u ZGluZyBwcm90b2NvbC4NDQ04LiBSZWZlcmVuY2VzDQ0MDQ0NDQ0NOS4gQWNrbm93bGVkZ21lbnRz DQ1UaGlzIGRvY3VtZW50IGlzIHBvc3RlZCBvbiBiZWhhbGYgb2YgU0ctMTYgSVRVLVQuIFRoZSBh Y2tub3dsZWRnZXMgZ28gdG8gdGhpcyBncm91cCBvZiBkZWRpY2F0ZWQgcGVvcGxlLg0NDTEwLiBB dXRob3IncyBBZGRyZXNzZXMNDU9yaXQgTGV2aW4NUkFEVmlzaW9uIEluYy4sDTU3NSBDb3Jwb3Jh dGUgRHJpdmUgU3VpdGUgNDIwDU1haHdhaCwgTkogMDc0MzANUGhvbmU6ICsxIDIwMSA1MjkgNDMw MA1FbWFpbDogb3JpdEByYWR2aXNpb24uY29tDQ0MDUZ1bGwgQ29weXJpZ2h0IFN0YXRlbWVudA0N IkNvcHlyaWdodCAoQykgVGhlIEludGVybmV0IFNvY2lldHkgKGRhdGUpLiBBbGwgUmlnaHRzIFJl c2VydmVkLiBUaGlzIGRvY3VtZW50IGFuZCB0cmFuc2xhdGlvbnMgb2YgaXQgbWF5IGJlIGNvcGll ZCBhbmQgZnVybmlzaGVkIHRvIG90aGVycywgYW5kIGRlcml2YXRpdmUgd29ya3MgdGhhdCBjb21t ZW50IG9uIG9yIG90aGVyd2lzZSBleHBsYWluIGl0IG9yIGFzc2lzdCBpbiBpdHMgaW1wbG1lbnRh dGlvbiBtYXkgYmUgcHJlcGFyZWQsIGNvcGllZCwgcHVibGlzaGVkIGFuZCBkaXN0cmlidXRlZCwg aW4gd2hvbGUgb3IgaW4gcGFydCwgd2l0aG91dCByZXN0cmljdGlvbiBvZiBhbnkga2luZCwgcHJv dmlkZWQgdGhhdCB0aGUgYWJvdmUgY29weXJpZ2h0IG5vdGljZSBhbmQgdGhpcyBwYXJhZ3JhcGgg YXJlIGluY2x1ZGVkIG9uIGFsbCBzdWNoIGNvcGllcyBhbmQgZGVyaXZhdGl2ZSB3b3Jrcy4gSG93 ZXZlciwgdGhpcyBkb2N1bWVudCBpdHNlbGYgbWF5IG5vdCBiZSBtb2RpZmllZCBpbiBhbnkgd2F5 LCBzdWNoIGFzIGJ5IHJlbW92aW5nIHRoZSBjb3B5cmlnaHQgbm90aWNlIG9yIHJlZmVyZW5jZXMg dG8gdGhlIEludGVybmV0IFNvY2lldHkgb3Igb3RoZXIgSW50ZXJuZXQgb3JnYW5pemF0aW9ucywg ZXhjZXB0IGFzIG5lZWRlZCBmb3IgdGhlIHB1cnBvc2Ugb2YgZGV2ZWxvcGluZyBJbnRlcm5ldCBz dGFuZGFyZHMgaW4gd2hpY2ggY2FzZSB0aGUgcHJvY2VkdXJlcyBmb3IgY29weXJpZ2h0cyBkZWZp bmVkIGluIHRoZSBJbnRlcm5ldCBTdGFuZGFyZHMgcHJvY2VzcyBtdXN0IGJlIGZvbGxvd2VkLCBv ciBhcyByZXF1aXJlZCB0byB0cmFuc2xhdGUgaXQgaW50bxMgSFlQRVJMSU5LIG1haWx0bzptaWtl Z2FAbWljcm9zb2Z0LmNvbSABFBUNDQ0NDQ0NCUguMzIzIFVSTCBzY2hlbWUgZGVmaW5pdGlvbglK dWx5IDIwMDANDQ0NIExldmluCUluZm9ybWF0aW9uYWwgliBFeHBpcmF0aW9uIEphbnVhcnkgMjAw MQkTIFBBR0UgFDIVDQ0gDUxldmluCUluZm9ybWF0aW9uYWwgliBFeHBpcmF0aW9uIEphbnVhcnkg MjAwMQkTIFBBR0UgFDEVDQ0NAiAgQnJhZG5lciwgUy4sICJLZXkgd29yZHMgZm9yIHVzZSBpbiBS RkNzIHRvIEluZGljYXRlIFJlcXVpcmVtZW50IExldmVscyIsIEJDUCAxNCwgUkZDIDIxMTksIE1h cmNoIDE5OTcNDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAABBAAACQQAABoEAAAjBAAALwQAAFIEAABT BAAAXAQAAGgEAAB1BAAAegQAAJUEAADkCQAA5QkAAAEKAAACCgAAAwoAAAwKAAANCgAAFAoAABgK AAA9CgAAQQoAADsLAAA8CwAAJwwAACgMAAAwDAAAPwwAAEEMAAAQDgAAEQ4AABYOAABgDgAA9w4A APsOAAALDwAAEw8AAHoPAAB7DwAAiBIAAIkSAACLEgAAjhIAAJ4SAADREgAA1xIAAJUUAACZFAAA oRQAAKoUAACwFAAAtBQAADgVAABAFQAAFhYAAAkXAACTFwAA/xgAABEZAAASGQAALBkAAJQZAACv GQAAyRkAAMoZAAD4GQAAABoAAA8aAAAQGgAAFxoAACkaAAArGgAALBoAAIcdAACIHQAArx0AAAD9 AP0A/QD9AP0A/QD18eb14PUA3gDeANwA1QD9AP3cAP0A3gDeAM4A/dwA/QDLAN4A3gDeAN4A/QD9 AP0A/QD9AP0A/dwA/QD9AMYAAAAAAAAAAAkDagAAAABVCAEEMEoaAAAMT0oAAFFKAABtSAkEAA0D agAAAAAwShgAVQgBAzUIgQM2CIEKMEoUADUIgTYIgQAVAgiBA2oAAAAABggBNQiBNgiBVQgBBjUI gTYIgQAPA2oAAAAANQiBNgiBVQgBAwwqBwBNAAQAAAEEAAAKBAAACwQAABoEAAAkBAAAJQQAAFME AABdBAAAXgQAAHYEAAB3BAAAeAQAAHkEAAB6BAAAlgQAAJcEAACYBAAArAQAAK0EAAByBQAAcwUA AEIHAAClBwAABwgAAAgIAAAJCAAA/AAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAADraAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAADr5AAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPcA AAAAAAAAAAAAAADraAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPcAAAAAAAAAAAAAAADrAAAAAAAA AAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADmAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAA AOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA5AAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADkAAAA AAAAAAAAAAAA5AAAAAAAAAAAAAAAAOQAAAAAAAAAAAAAAADkAAAAAAAAAAAAAAAA5AAAAAAAAAAA AAAAAOQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEVAAMWAAMkAQABFgAMAAAWJAEXJAEClmwACNYI AAKU/3ocyCgABBYAAyQCFiQBAxYAFiQBABoABAAAAQQAAAoEAAALBAAAGgQAACQEAAAlBAAAUwQA AF0EAABeBAAAdgQAAHcEAAB4BAAAeQQAAHoEAACWBAAAlwQAAJgEAACsBAAArQQAAHIFAABzBQAA QgcAAKUHAAAHCAAACAgAAAkIAAAKCAAACwgAAAwIAAAYCAAAGQgAAH8KAAA7CwAAPAsAAD0LAABi CwAAYwsAAGQLAAArDAAALAwAAC0MAABADAAAQQwAAA8NAAARDgAAEg4AABMOAABgDgAA1g4AANcO AABUDwAAVQ8AAHoPAAB7DwAAxw8AAOUPAAAWEAAASRAAAIkQAADBEAAAABEAACURAABQEQAAjhEA AL8RAADREQAA7xEAAAoSAAA8EgAAahIAAIgSAACJEgAAihIAAIsSAACdEgAAnhIAADATAAAbFAAA ERYAABIWAAATFgAAVxYAAFgWAAB1FwAAdhcAAHcXAACSFwAAkxcAAA4YAAAAGQAAARkAAAIZAAAQ GQAAERkAABIZAAD7+/n7+/n7+/n7+/n39/f39/f19fX19fX19fX19ff19fX19ff19fX19ff19fX1 9ff19fX19fP19fX19fX19fX19fX19fX19fX19ff19fX19fX39fX19ff39fX19ff18AAFAhUACQMD AhkAAwIVAAMCFgACAwEABwIWAAMBBQoAXwkIAAAKCAAACwgAAAwIAAAYCAAAGQgAAH8KAAA7CwAA PAsAAD0LAABiCwAAYwsAAGQLAAArDAAALAwAAC0MAABADAAAQQwAAA8NAAARDgAAEg4AABMOAABg DgAA1g4AANcOAABUDwAAVQ8AAHoPAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAA AAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0A AAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAA AAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAMVAA+EAAAAARYAAAEVAAAbeg8AAHsPAADHDwAA5Q8AABYQAABJEAAAiRAAAMEQAAAA EQAAJREAAFARAACOEQAAvxEAANERAADvEQAAChIAADwSAABqEgAAiBIAAIkSAACKEgAAixIAAJ0S AACeEgAAMBMAABsUAAARFgAAEhYAAPEAAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAA AAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADv AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAA AAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAA AADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAA AAAAAAAAAAAAAO0AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAA AAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEWAAABFQAOGQANxhYK NwJuBKUG3AgTC0oNgQ+4Ee8TJhYAABsSFgAAExYAAFcWAABYFgAAdRcAAHYXAAB3FwAAkhcAAJMX AAAOGAAAABkAAAEZAAACGQAAEBkAABEZAAASGQAAExkAABQZAAAVGQAAFhkAABcZAAAYGQAAKxkA ACwZAACVGQAAlhkAAJcZAACuGQAArxkAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAP0AAAAAAAAAAAAAAAD3AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAA AAD7AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA /QAAAAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAA AAAAAAAAAAD9AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAADFQAPhAAAAAEWAAABFQAAHBIZAAATGQAAFBkAABUZAAAWGQAAFxkAABgZAAArGQAALBkA AJUZAACWGQAAlxkAAK4ZAACvGQAAuhkAAMoZAADoGQAA+RkAABAaAAAqGgAAKxoAAC0aAABGGgAA RxoAALMdAAC0HQAAth0AALgdAADgHQAA4R0AAOIdAADjHQAAHR4AAB4eAAAgHgAAWR4AAFoeAADE HgAAxR4AAMceAAD9/f39/f37/f39/fv9/f39/f39/f37APj29vb28/Pz9vbw9vb27fgAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAUCFwANAQUCEQANAQUCEAAN AQIBAQAFAhUABQADAhYAAwIVAAAnrxkAALoZAADKGQAA6BkAAPkZAAAQGgAAKhoAACsaAAAtGgAA RhoAAEcaAACzHQAAtB0AALUdAAC2HQAAtx0AALgdAAC5HQAA4B0AAOEdAADiHQAA4x0AAB0eAAAe HgAAIB4AAFkeAABaHgAAWx4AAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAA AP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA+wAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA7AAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAAD5 AAAAAAAAAAAAAAAA6gAAAAAAAAAAAAAAAOoAAAAAAAAAAAAAAADqAAAAAAAAAAAAAAAA6gAAAAAA AAAAAAAAAOwAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOwAAAAAAAAAAAAA AAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAAAAAAAAAAEQAAABEQAAChUABiQBE6TwABSkPAAt RAAdQCYAAAEAAAABFgAAARUAABsAAD4ADAADAAAAAwAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAHAAA AG0AYQBpAGwAdABvADoAbQBpAGsAZQBnAGEAQABtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAAAA HwAAAAEAAAAAAAAAAwAAAFAAKQADAAAAAAAAAAMAAAAAAAAAAwAAAAUAAAAfAAAAEQAAAG0AYQBp AGwAdABvADoAdQBzAGUAcgBAAGgAbwBzAHQAAAAAAB8AAAABAAAAAAAAAAAAkAEAAAIAAADkBAAA HgAAABYAAABOZXR3b3JrIFdvcmtpbmcgR3JvdXAAOAAeAAAAAQAAAABldHceAAAADAAAAE1pa2Ug R2Focm5zAB4AAAABAAAAAGlrZR4AAAABAAAAAGlrZR4AAAALAAAATm9ybWFsLmRvdAAAHgAAAAsA AABPcml0IExldmluAAAeAAAAAgAAADkAaXQeAAAAEwAAAE1pY3Jvc29mdCBXb3JkIDguMAB1QAAA AADUrfQBAAAAQAAAAADio2hY6L8BQAAAAACmM3bX6b8BQAAAAAAqzXnj6b8BAwAAAAEAAAADAAAA tgMAAAMAAAAsFQAAAwAAAAAAAAAwAAAAAAAAAAAAAABPRkZJQ0UAAAAAAAD5QQCgoElCADwAQAAs CkEAAAAAAMYAAAAAhAAAFAAAAK8dAACwHQAAsh0AABIeAAATHgAAGR4AABoeAAAbHgAAHB4AAE4e AABPHgAAVR4AAFYeAABXHgAAWB4AAFseAABcHgAAxx4AAKRMAACoTAAAqkwAAKxMAAB+TQAAgE0A AOZYAABGXAAASlwAAExcAABOXAAAiGgAAHJuAAB2bgAAeG4AAHpuAAC0egAAZH8AAGh/AABufwAA iIEAAIyBAACSgQAAqIUAAKyFAACyhQAA9/IA6+jr4+sA6+jr4+sA3AAA4wDcANkAAOMA3AAA4wDc AADjAADjAADjAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABDBK GAAADQNqAAAAADBKGABVCAEIMEoSAG1IAAQABDBKEgAADQNqAAAAADBKEgBVCAEJA2oAAAAAVQgB DwIIgQNqqwAAAAYIAVUIAQAr/FMAANBUAADSVAAA1FQAAIRVAACGVQAAiFUAAH5WAACAVgAAglYA AFJXAABUVwAAVlcAACJYAAAkWAAAJlgAAORYAADmWAAAQlwAAERcAABGXAAATFwAAB5dAAAgXQAA aF4AAGpeAAAiXwAAJF8AAPoAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPoA AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADrAAAA AAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAA AAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD6 AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAAAAAAABFwAAChUABiQBE6TwABSkPAAtRAAdQCYAAAEA AAABFQAFFQAKJgALRhEAABurAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAKAAAA dQBzAGUAcgBAAGgAbwBzAHQAAADgyep5+brOEYyCAKoAS6kLIgAAAG0AYQBpAGwAdABvADoAdQBz AGUAcgBAAGgAbwBzAHQAAADXAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAAVAAAA bQBpAGsAZQBnAGEAQABtAGkAYwByAG8AcwBvAGYAdAAuAGMAbwBtAAAA4Mnqefm6zhGMggCqAEup CzgAAABtAGEAaQBsAHQAbwA6AG0AaQBrAGUAZwBhAEAAbQBpAGMAcgBvAHMAbwBmAHQALgBjAG8A bQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAArx0AALAdAACyHQAAEh4AABMeAAAZHgAAGh4AABseAAAcHgAATh4AAE8eAABVHgAA Vh4AAFceAABYHgAAWx4AAFweAADHHgAApEwAAKhMAACqTAAArEwAAH5NAACATQAA5lgAAEZcAABK XAAATFwAAE5cAACIaAAAcm4AAHZuAAB4bgAAem4AALR6AABkfwAAaH8AAG5/AACIgQAAjIEAAJKB AAD38gDr6Ovj6wDr6Ovj6wDcAADjANwA2QAA4wDcAADjANwAAOMAAOMAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEMEoYAAANA2oAAAAA MEoYAFUIAQgwShIAbUgABAAEMEoSAAANA2oAAAAAMEoSAFUIAQkDagAAAABVCAEPAgiBA2qrAAAA BggBVQgBACjIZwAAhmgAAIhoAAACbgAAbm4AAHBuAABybgAAeG4AAEpvAABMbwAAlHAAAJZwAABO cQAAUHEAAFJxAACGcgAAiHIAAIpyAACQcwAAknMAAJRzAAAGdQAACHUAAAp1AADGdQAAyHUAAMp1 AAD9AAAAAAAAAAAAAAAA8gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAO4AAAAAAAAA AAAAAADuAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA 7AAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOcAAAAA AAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADsAAAAAAAAAAAA AAAA7AAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADsAAAAAAAAAAAAAAAA7AAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAFFQAKJgALRhEAAAEVAAABFwAAARYAAAoVAAYkAROk8AAUpDwALUQAHUAm AAABAAAAGg0AYgB5ACAASAAuADMAMgAzACAAWwAzAF0AIABlAHgAYQBjAHQAbAB5ACAAUgBMAHMA IABhAHIAZQAgAHcAaQB0AGgAaQBuACAAQQBuAG4AZQB4ACAASwAvAEgALgAzADIAMwAgAFsAMQAz AA0ADQANADIAMQANAAIAIAAgAEIAcgBhAGQAbgBlAHIALAAgAFMALgAsACAAIgBLAGUAeQAgAHcA bwByAGQAcwAgAGYAbwByACAAdQBzAGUAIABpAG4AIABSAEYAQwBzACAAdABvACAASQBuAGQAaQBj AGEAdABlACAAUgBlAHEAdQBpAHIAZQBtAGUAbgB0ACAATABlAHYAZQBsAHMAIgAsACAAQgBDAFAA IAAxADQALAAgAFIARgBDACAAMgAxADEAOQAsACAATQBhAHIAYwBoACAAMQA5ADkANwANAA0AMgAg ACAAQwByAG8AYwBrAGUAcgAsACAARAAuACAAYQBuAGQAIABPAHYAZQByAGUAbABsACwAIABQAC4A KABFAGQAaQB0AG8AcgBzACkALAAgACIAQQB1AGcAbQBlAG4AdABlAGQAIABCAE4ARgAgAGYAbwBy ACAAUwB5AG4AdABhAHgAIABTAHAAZQBjAGkAZgBpAGMAYQB0AGkAbwBuAHMAOgAgAEEAQgBOAEYA IgAsACAAUgBGAEMAIAAyADIAMwA0ACwAIABJAG4AdABlAHIAbgBlAHQAIABNAGEAaQBsACAAQwBv AG4AcwBvAHIAdABpAHUAbQAgAGEAbgBkACAARABlAG0AbwBuACAASQBuAHQAZQByAG4AZQB0ACAA TAB0AGQALgAsACAATgBvAHYAZQBtAGIAZQByACAAMQA5ADkANwANAA0ASQBUAFUALQBUACAAUgBl AGMAbwBtAG0AZQBuAGQAYQB0AGkAbwBuACAASAAuADMAMgAzACAAHCBQAGEAYwBrAGUAdAAtAGIA YQBzAGUAZAAgAG0AdQBsAHQAaQBtAGUAZABpAGEAIABjAG8AbQBtAHUAbgBpAGMAYQB0AGkAbwBu AHMAIABzAHkAcwB0AGUAbQBzAB0gLAAgAFMAZQBwAHQAZQBtAGIAZQByACAAMQA5ADkAOQANAA0A DQBJAFQAVQAtAFQAIABSAGUAYwBvAG0AbQBlAG4AZABhAHQAaQBvAG4AIABIAC4AMgAyADUALgAw ACAAHCBDAGEAbABsACAAcwBpAGcAbgBhAGwAbABpAG4AZwAgAHAAcgBvAHQAbwBjAG8AbABzACAA YQBuAGQAIABtAGUAZABpAGEAIABzAHQAcgBlAGEAbQAgAHAAYQBjAGsAZQB0AGkAegBhAHQAaQBv AG4AIABmAG8AcgAgAHAAYQBjAGsAZQB0AC0AYgBhAHMAZQBkACAAbQB1AGwAdABpAG0AZQBkAGkA YQAgAGMAbwBtAG0AdQBuAGkAYwBhAHQAaQBvAG4AIABzAHkAcwB0AGUAbQBzAB0gLAAgAFMAZQBw AHQAZQBtAGIAZQByACAAMQA5ADkAOQANAA0ADQBJAFQAVQAtAFQAIABSAGUAYwBvAG0AbQBlAG4A ZABhAHQAaQBvAG4AIABIAC4AMgAzADUAIAAcIFMAZQBjAHUAcgBpAHQAeQAgAGEAbgBkACAARQBu AGMAcgB5AHAAdABpAG8AbgAgAGYAbwByACAASAAgAFMAZQByAGkAZQBzACAAKABIAC4AMwAyADMA IABhAG4AZAAgAG8AdABoAGUAcgAgAEgALgAyADQANQAgAGIAYQBzAGUAZAApACAAbQB1AGwAdABp AG0AZQBkAGkAYQAgAHQAZQByAG0AaQBuAGEAbABzAB0gLAAgAEoAYQBuAHUAYQByAHkAIAAxADkA OQA4AA0ADQANAE0ALgAgAEgAYQBuAGQAbABlAHkALAAgAEgALgAgAFMAYwBoAHUAbAB6AHIAaQBu AG4AZQAsACAARQAuACAAUwBjAGgAbwBvAGwAZQByACwAIABhAG4AZAAgAEoALgAgAFIAbwBzAGUA bgBiAGUAcgBnACwAIAAiAFMASQBQADoAIABzAGUAcwBzAGkAbwBuACAAaQBuAGkAdABpAGEAdABp AG8AbgAgAHAAcgBvAHQAbwBjAG8AbAAsACIAIABSAGUAcQB1AGUAcwB0ACAAZgBvAHIAIABDAG8A bQBtAGUAbgB0AHMAIAAoAFAAcgBvAHAAbwBzAGUAZAAgAFMAdABhAG4AZABhAHIAZAApACAAMgA1 ADQAMwAsACAASQBuAHQAZQByAG4AZQB0ACAARQBuAGcAaQBuAGUAZQByAGkAbgBnACAAVABhAHMA awAgAEYAbwByAGMAZQAsACAATQBhAHIALgAgADEAOQA5ADkADQANAA0ASwAuACAAUwBpAG4AZwBo ACAAYQBuAGQAIABIAC4AIABTAGMAaAB1AGwAegByAGkAbgBuAGUALAAcIEkAbgB0AGUAcgB3AG8A cgBrAGkAbgBnACAAQgBlAHQAdwBlAGUAbgAgAFMASQBQAC8AUwBEAFAAIABhAG4AZAAgAEgALgAz ADIAMwAdICAASQBuAHQAZQByAG4AZQB0ACAARAByAGEAZgB0ACwAIABNAGEAeQAgADIAMAAwADAA DQANAA0AQgBlAHIAbgBlAHIAcwAtAEwAZQBlACwAIABUAC4ALAAgAE0AYQBzAGkAbgB0AGUAcgAs ACAATAAuACAAYQBuAGQAIABNAC4AIABNAGMAQwBhAGgAaQBsAGwALAAgACIAVQBuAGkAZgBvAHIA bQAgAHIAZQBzAG8AdQByAGMAZQAgAGwAbwBjAGEAdABvAHIAcwAgACgAVQBSAEwAKQAiACwAIABS AEYAQwAgADEANwAzADgALAAgAEQAZQBjAGUAbQBiAGUAcgAgADEAOQA5ADQADQANAA0ASABvAGYA ZgBtAGEAbgAsACAAUAAuACwAIABNAGEAcwBpAG4AdABlAHIALAAgAEwALgAgAGEAbgBkACAASgAu ACAAWgBhAHcAaQBuAHMAawBpACwAIAAiAFQAaABlACAAbQBhAGkAbAB0AG8AIABVAFIATAAgAHMA YwBoAGUAbQBlACIALAAgAFIARgBDACAAMgAzADYAOAAsACAASgB1AGwAeQAgADEAOQA5ADgADQAN AA0AQgBlAHIAbgBlAHIAcwAtAEwAZQBlACwAIABUAC4ALAAgAEYAaQBlAGwAZABpAG4AZwAsACAA UgAuACAAYQBuAGQAIABMAC4AIABNAGEAcwBpAG4AdABlAHIALAAgACIAVQBuAGkAZgBvAHIAbQAg AHIAZQBzAG8AdQByAGMAZQAgAGkAZABlAG4AdABpAGYAaQBlAHIAcwAgACgAVQBSAEkAKQA6ACAA ZwBlAG4AZQByAGkAYwAgAHMAeQBuAHQAYQB4ACIALAAgAFIARgBDACAAMgAzADkANgAsACAAQQB1 AGcAdQBzAHQAIAAxADkAOQA4AA0ADQANAEMAcgBvAGMAawBlAHIALAAgAEQALgAsACAAIgBTAHQA YQBuAGQAYQByAGQAIABmAG8AcgAgAHQAaABlACAAZgBvAHIAbQBhAHQAIABvAGYAIABBAFIAUABB ACAAaQBuAHQAZQByAG4AZQB0ACAAdABlAHgAdAAgAG0AZQBzAHMAYQBnAGUAcwAiACwAIABSAEYA QwAgAFMAVABEACAAMQAxACwAIABSAEYAQwAgADgAMgAyACwAIABBAHUAZwB1AHMAdAAgADEAOQA4 ADIADQANAA0AUgAuACAAUABlAHQAawBlACAAYQBuAGQAIABJAC4AIABLAGkAbgBnACwAIAAcIFIA ZQBnAGkAcwB0AHIAYQB0AGkAbwBuACAAUAByAG8AYwBlAGQAdQByAGUAcwAgAGYAbwByACAAVQBS AEwAIABTAGMAaABlAG0AZQAgAE4AYQBtAGUAcwAdICwAIABSAEYAQwAgADIANwAxADcALAAgAEIA QwBQAC0AMwA1ACwAIABOAG8AdgBlAG0AYgBlAHIAIAAxADkAOQA5AA0ADQANADEAMwAgAEkAVABV AC0AVAAgAFIAZQBjAG8AbQBtAGUAbgBkAGEAdABpAG8AbgAgAEgALgAzADIAMwAgAEEAbgBuAGUA eAAgAEsAIAAcIEgAVABUAFAAIABiAGEAcwBlAGQAIABzAGUAcgB2AGkAYwBlACAAQwBvAG4AdABy AG8AbAAgAFQAcgBhAG4AcwBwAG8AcgB0ACAAQwBoAGEAbgBuAGUAbAAdICwAIABNAGEAeQAgADIA MAAwADAADQANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ynUAAJ52AACgdgAAonYAAFJ3AABUdwAAVncAAEx4AABOeAAAUHgAACB5AAAieQAAJHkAAPB5AADy eQAA9HkAALJ6AAC0egAAAn4AAF5/AABgfwAAYn8AAGR/AABqfwAAbH8AAG5/AAACgAAAXoEAAPoA AAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD4AAAAAAAA AAAAAAAA+AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAA APoAAAAAAAAAAAAAAAD4AAAAAAAAAAAAAAAA+AAAAAAAAAAAAAAAAPoAAAAAAAAAAAAAAAD4AAAA AAAAAAAAAAAA+AAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAADrAAAAAAAAAAAAAAAA6QAAAAAAAAAA AAAAAPgAAAAAAAAAAAAAAAD2AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAPYAAAAAAAAAAAAAAAD2 AAAAAAAAAAAAAAAA9gAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA+AAAAAAA AAAAAAAAAAAAAAABFgAAChUABiQBE6TwABSkPAAtRAAdQCYAAAEAAAABFQAFFQAKJgALRhEAABte gQAAhIEAAIaBAACIgQAAjoEAAJCBAACSgQAAAoQAAH6FAACkhQAApoUAAKiFAACuhQAAsIUAALKF AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAPIAAAAAAAAAAAAAAADwAAAAAAAAAAAAAAAA7gAAAAAAAAAAAAAAAP0AAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA 8gAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAABFQAAARYAAAoVAAYkAROk8AAUpDwALUQAHUAmAAABAAAADg0A VABoAGkAcwAgAGQAbwBjAHUAbQBlAG4AdAAgAGkAcwAgAGEAbgAgAEkAbgB0AGUAcgBuAGUAdAAt AEQAcgBhAGYAdAAgAGEAbgBkACAAaQBzACAAaQBuACAAZgB1AGwAbAAgAGMAbwBuAGYAbwByAG0A YQBuAGMAZQAgAHcAaQB0AGgAIABhAGwAbAAgAHAAcgBvAHYAaQBzAGkAbwBuAHMAIABvAGYAIABT AGUAYwB0AGkAbwBuACAAMQAwACAAbwBmACAAUgBGAEMAMgAwADIANgAgAGUAeABjAGUAcAB0ACAA dABoAGEAdAAgAHQAaABlACAAcgBpAGcAaAB0ACAAdABvACAAcAByAG8AZAB1AGMAZQAgAGQAZQBy AGkAdgBhAHQAaQB2AGUAIAB3AG8AcgBrAHMAIABpAHMAIABuAG8AdAAgACgAYQB1AHQAbwBtAGEA dABpAGMAYQBsAGwAeQApACAAZwByAGEAbgB0AGUAZAAuACAADQBoAGEAcgBhAGMAdABlAHIAIABl AG4AYwBvAGQAaQBuAGcALAANAA0ADQAyADEADQANAA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAb AAoAAQBbAA8AAgAAAAAAAAAkAABA8f8CACQAAAAGAE4AbwByAG0AYQBsAAAAAgAAAAQAbUgJBEgA AUABAAIASAAAAAkASABlAGEAZABpAG4AZwAgADEAAAAQAAEABiQBE6TwABSkPABAJgATADUIgUNK HABLSBwAT0oCAFFKAgAARgACQAEAAgBGAAAACQBIAGUAYQBkAGkAbgBnACAAMgAAABAAAgAGJAET pPAAFKQ8AEAmARIANQiBNgiBQ0oYAE9KAgBRSgIAAAAAAAAAAAAAAAAAAAA8AEFA8v+hADwAAAAW AEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAAaAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAA MABaQAEA8gAwAAAACgBQAGwAYQBpAG4AIABUAGUAeAB0AAAAAgAPAAgAT0oDAFFKAwA+AB9AAQAC AT4AAAAGAEgAZQBhAGQAZQByAAAAEwAQABJkEP8AAA3GCAACsBNgJwECAAwAQ0oYAE9KAwBRSgMA PgAgQAEAEgE+AAAABgBGAG8AbwB0AGUAcgAAABMAEQASZBD/AAANxggAArATYCcBAgAMAENKGABP SgMAUUoDACYAKUCiACEBJgAAAAsAUABhAGcAZQAgAE4AdQBtAGIAZQByAAAAAAA4AFlAAQAyATgA AAAMAEQAbwBjAHUAbQBlAG4AdAAgAE0AYQBwAAAABgATAC1EIAEIAE9KBABRSgQAKABVQKIAQQEo AAAACQBIAHkAcABlAHIAbABpAG4AawAAAAYAPioBQioCOgD+TwEAUgE6AAAACABSAEYAQwAgAFQA ZQB4AHQAAAAMABUAD4SwARJkEP8AAAwAQ0oYAE9KAwBRSgMAPAD+TwEAUgE8AAAACwBSAEYAQwAg AEgAZQBhAGQAaQBuAGcAAAAIABYAEmQQ/wAADABDShgAT0oDAFFKAwA0ACtAUQFyATQAAAAMAEUA bgBkAG4AbwB0AGUAIABUAGUAeAB0AAAACgAXAA+EYAMRhFD+AAA2ACpA8v+BATYAAAARAEUAbgBk AG4AbwB0AGUAIABSAGUAZgBlAHIAZQBuAGMAZQAAAAMASCoAAE4A/m8BAJIBTgAEAAUAQQBTAE4A LgAxAAAAJQAZAA3GIAAKNwJuBKUG3AgTC0oNgQ+4Ee8TJhbAwMDAwMDAwMDAAAwAT0oDAFFKAwBt SAAERAD+b6IAoQFEAAQACQBBAFMATgAxAF8AdwBvAHIAZAAAACEANQiBQioAQ0oWAE9KAABRSgAA a0jkBG1IAARuSAAEdQgBACAIAAB2IAAAAQAAAAAAHgYAACEGAAAAAAAAERUAAHYgAAADAABMAAAA AP////8DAC1MAAAAAP////8AAAAAAQAAAAoAAAALAAAAGgAAACQAAAAlAAAAUwAAAF0AAABeAAAA dgAAAHcAAAB4AAAAeQAAAHoAAACWAAAAlwAAAJgAAACsAAAArQAAAGsBAABsAQAAOwMAAJ4DAAAA BAAAAQQAAAIEAAADBAAABAQAAAUEAAARBAAAEgQAAHgGAAA0BwAANQcAADYHAABbBwAAXAcAAF0H AAAkCAAAJQgAACYIAAA5CAAAOggAAAgJAAAKCgAACwoAAAwKAABKCgAASwoAANYKAADXCgAAVAsA AFULAAB6CwAAewsAAMcLAADkCwAAFQwAAEgMAACIDAAAwAwAAP8MAAAkDQAATw0AAI0NAAC+DQAA 0A0AAO4NAAAJDgAAOw4AAGkOAACHDgAAiA4AAIkOAACKDgAAnA4AAJ0OAAAvDwAAGhAAABASAAAR EgAAEhIAAFcSAABYEgAAdRMAAHYTAAB3EwAAkhMAAJMTAAAOFAAAABUAAAEVAAACFQAAEBUAABEV AAASFQAAExUAACYVAAAnFQAAkBUAAJEVAACSFQAAqRUAAKoVAAC1FQAAxRUAAOMVAAD0FQAACxYA ACUWAAAmFgAAKBYAAEEWAABCFgAArhkAAK8ZAACxGQAAsxkAANsZAADcGQAA3RkAAN4ZAAAYGgAA GRoAABsaAABUGgAAVhoAAL8aAADAGgAAZBsAAGUbAADBGwAAwhsAAMMbAABdHAAAXhwAAF8cAADi HAAA4xwAAOQcAACdHQAAnh0AAJ8dAAD9HQAA/h0AAP8dAABpHgAAah4AAGseAADDHgAAxB4AAMUe AABAHwAAQR8AAEIfAACqHwAAqx8AAKwfAAASIAAAEyAAABQgAABzIAAAdCAAAHcgAACpAAAAFgAA AAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICZAAAAAAAAAAAAAAAAgAAAAICpAAAAFgAAAAAA AAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICZAAAAAAAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAA gAAAAICpAAAAFgAAAAAAAAAAgAAAAICZAAAAAAAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAA AICpAAAAFgAAAAAAAAAAgAAAAICZAAAAAAAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICY AAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAA FgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAIBSAEwAcwAg AGEAcgBlACAAdwBpAHQAaABpAG4AIABBAG4AbgBlAHgAIABLAC8ASAAuADMAMgAzACAAWwAxADMA DQANAA0AMwAxAA0AAgAgACAAQgByAGEAZABuAGUAcgAsACAAUwAuACwAIAAiAEsAZQB5ACAAdwBv AHIAZABzACAAZgBvAHIAIAB1AHMAZQAgAGkAbgAgAFIARgBDAHMAIAB0AG8AIABJAG4AZABpAGMA YQB0AGUAIABSAGUAcQB1AGkAcgBlAG0AZQBuAHQAIABMAGUAdgBlAGwAcwAiACwAIABCAEMAUAAg ADEANAAsACAAUgBGAEMAIAAyADEAMQA5ACwAIABNAGEAcgBjAGgAIAAxADkAOQA3AA0ADQAyACAA IABDAHIAbwBjAGsAZQByACwAIABEAC4AIABhAG4AZAAgAE8AdgBlAHIAZQBsAGwALAAgAFAALgAo AEUAZABpAHQAbwByAHMAKQAsACAAIgBBAHUAZwBtAGUAbgB0AGUAZAAgAEIATgBGACAAZgBvAHIA IABTAHkAbgB0AGEAeAAgAFMAcABlAGMAaQBmAGkAYwBhAHQAaQBvAG4AcwA6ACAAQQBCAE4ARgAi ACwAIABSAEYAQwAgADIAMgAzADQALAAgAEkAbgB0AGUAcgBuAGUAdAAgAE0AYQBpAGwAIABDAG8A bgBzAG8AcgB0AGkAdQBtACAAYQBuAGQAIABEAGUAbQBvAG4AIABJAG4AdABlAHIAbgBlAHQAIABM AHQAZAAuACwAIABOAG8AdgBlAG0AYgBlAHIAIAAxADkAOQA3AA0ADQBJAFQAVQAtAFQAIABSAGUA YwBvAG0AbQBlAG4AZABhAHQAaQBvAG4AIABIAC4AMwAyADMAIAAcIFAAYQBjAGsAZQB0AC0AYgBh AHMAZQBkACAAbQB1AGwAdABpAG0AZQBkAGkAYQAgAGMAbwBtAG0AdQBuAGkAYwBhAHQAaQBvAG4A cwAgAHMAeQBzAHQAZQBtAHMAHSAsACAAUwBlAHAAdABlAG0AYgBlAHIAIAAxADkAOQA5AA0ADQAN AEkAVABVAC0AVAAgAFIAZQBjAG8AbQBtAGUAbgBkAGEAdABpAG8AbgAgAEgALgAyADIANQAuADAA IAAcIEMAYQBsAGwAIABzAGkAZwBuAGEAbABsAGkAbgBnACAAcAByAG8AdABvAGMAbwBsAHMAIABh AG4AZAAgAG0AZQBkAGkAYQAgAHMAdAByAGUAYQBtACAAcABhAGMAawBlAHQAaQB6AGEAdABpAG8A bgAgAGYAbwByACAAcABhAGMAawBlAHQALQBiAGEAcwBlAGQAIABtAHUAbAB0AGkAbQBlAGQAaQBh ACAAYwBvAG0AbQB1AG4AaQBjAGEAdABpAG8AbgAgAHMAeQBzAHQAZQBtAHMAHSAsACAAUwBlAHAA dABlAG0AYgBlAHIAIAAxADkAOQA5AA0ADQANAEkAVABVAC0AVAAgAFIAZQBjAG8AbQBtAGUAbgBk AGEAdABpAG8AbgAgAEgALgAyADMANQAgABwgUwBlAGMAdQByAGkAdAB5ACAAYQBuAGQAIABFAG4A YwByAHkAcAB0AGkAbwBuACAAZgBvAHIAIABIACAAUwBlAHIAaQBlAHMAIAAoAEgALgAzADIAMwAg AGEAbgBkACAAbwB0AGgAZQByACAASAAuADIANAA1ACAAYgBhAHMAZQBkACkAIABtAHUAbAB0AGkA bQBlAGQAaQBhACAAdABlAHIAbQBpAG4AYQBsAHMAHSAsACAASgBhAG4AdQBhAHIAeQAgADEAOQA5 ADgADQANAA0ATQAuACAASABhAG4AZABsAGUAeQAsACAASAAuACAAUwBjAGgAdQBsAHoAcgBpAG4A bgBlACwAIABFAC4AIABTAGMAaABvAG8AbABlAHIALAAgAGEAbgBkACAASgAuACAAUgBvAHMAZQBu AGIAZQByAGcALAAgACIAUwBJAFAAOgAgAHMAZQBzAHMAaQBvAG4AIABpAG4AaQB0AGkAYQB0AGkA bwBuACAAcAByAG8AdABvAGMAbwBsACwAIgAgAFIAZQBxAHUAZQBzAHQAIABmAG8AcgAgAEMAbwBt AG0AZQBuAHQAcwAgACgAUAByAG8AcABvAHMAZQBkACAAUwB0AGEAbgBkAGEAcgBkACkAIAAyADUA NAAzACwAIABJAG4AdABlAHIAbgBlAHQAIABFAG4AZwBpAG4AZQBlAHIAaQBuAGcAIABUAGEAcwBr ACAARgBvAHIAYwBlACwAIABNAGEAcgAuACAAMQA5ADkAOQANAA0ADQBLAC4AIABTAGkAbgBnAGgA IABhAG4AZAAgAEgALgAgAFMAYwBoAHUAbAB6AHIAaQBuAG4AZQAsABwgSQBuAHQAZQByAHcAbwBy AGsAaQBuAGcAIABCAGUAdAB3AGUAZQBuACAAUwBJAFAALwBTAEQAUAAgAGEAbgBkACAASAAuADMA MgAzAB0gIABJAG4AdABlAHIAbgBlAHQAIABEAHIAYQBmAHQALAAgAE0AYQB5ACAAMgAwADAAMAAN AA0ADQBCAGUAcgBuAGUAcgBzAC0ATABlAGUALAAgAFQALgAsACAATQBhAHMAaQBuAHQAZQByACwA IABMAC4AIABhAG4AZAAgAE0ALgAgAE0AYwBDAGEAaABpAGwAbAAsACAAIgBVAG4AaQBmAG8AcgBt ACAAcgBlAHMAbwB1AHIAYwBlACAAbABvAGMAYQB0AG8AcgBzACAAKABVAFIATAApACIALAAgAFIA RgBDACAAMQA3ADMAOAAsACAARABlAGMAZQBtAGIAZQByACAAMQA5ADkANAANAA0ADQBIAG8AZgBm AG0AYQBuACwAIABQAC4ALAAgAE0AYQBzAGkAbgB0AGUAcgAsACAATAAuACAAYQBuAGQAIABKAC4A IABaAGEAdwBpAG4AcwBrAGkALAAgACIAVABoAGUAIABtAGEAaQBsAHQAbwAgAFUAUgBMACAAcwBj AGgAZQBtAGUAIgAsACAAUgBGAEMAIAAyADMANgA4ACwAIABKAHUAbAB5ACAAMQA5ADkAOAANAA0A DQBCAGUAcgBuAGUAcgBzAC0ATABlAGUALAAgAFQALgAsACAARgBpAGUAbABkAGkAbgBnACwAIABS AC4AIABhAG4AZAAgAEwALgAgAE0AYQBzAGkAbgB0AGUAcgAsACAAIgBVAG4AaQBmAG8AcgBtACAA cgBlAHMAbwB1AHIAYwBlACAAaQBkAGUAbgB0AGkAZgBpAGUAcgBzACAAKABVAFIASQApADoAIABn AGUAbgBlAHIAaQBjACAAcwB5AG4AdABhAHgAIgAsACAAUgBGAEMAIAAyADMAOQA2ACwAIABBAHUA ZwB1AHMAdAAgADEAOQA5ADgADQANAA0AQwByAG8AYwBrAGUAcgAsACAARAAuACwAIAAiAFMAdABh AG4AZABhAHIAZAAgAGYAbwByACAAdABoAGUAIABmAG8AcgBtAGEAdAAgAG8AZgAgAEEAUgBQAEEA IABpAG4AdABlAHIAbgBlAHQAIAB0AGUAeAB0ACAAbQBlAHMAcwBhAGcAZQBzACIALAAgAFIARgBD ACAAUwBUAEQAIAAxADEALAAgAFIARgBDACAAOAAyADIALAAgAEEAdQBnAHUAcwB0ACAAMQA5ADgA MgANAA0ADQBSAC4AIABQAGUAdABrAGUAIABhAG4AZAAgAEkALgAgAEsAaQBuAGcALAAgABwgUgBl AGcAaQBzAHQAcgBhAHQAaQBvAG4AIABQAHIAbwBjAGUAZAB1AHIAZQBzACAAZgBvAHIAIABVAFIA TAAgAFMAYwBoAGUAbQBlACAATgBhAG0AZQBzAB0gLAAgAFIARgBDACAAMgA3ADEANwAsACAAQgBD AFAALQAzADUALAAgAE4AbwB2AGUAbQBiAGUAcgAgADEAOQA5ADkADQANAA0AMQAzACAASQBUAFUA LQBUACAAUgBlAGMAbwBtAG0AZQBuAGQAYQB0AGkAbwBuACAASAAuADMAMgAzACAAQQBuAG4AZQB4 ACAASwAgABwgSABUAFQAUAAgAGIAYQBzAGUAZAAgAHMAZQByAHYAaQBjAGUAIABDAG8AbgB0AHIA bwBsACAAVAByAGEAbgBzAHAAbwByAHQAIABDAGgAYQBuAG4AZQBsAB0gLAAgAE0AYQB5ACAAMgAw ADAAMAANAA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACRfAAAmXwAAWmAAAFxg AABeYAAAZGEAAGZhAABoYQAA2mIAANxiAADeYgAAmmMAAJxjAACeYwAAcmQAAHRkAAB2ZAAAJmUA AChlAAAqZQAAIGYAACJmAAAkZgAA9GYAAPZmAAD4ZgAAxGcAAMZnAADIZwAA/QAAAAAAAAAAAAAA APgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAA AAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAA AAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9 AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAA AAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAPgAAAAAAAAAAAAAAAD9AAAAAAAAAAAAAAAA/QAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFFQAKJgALRhEAAAEVAAAcmAAAABUAAAAAAAAAAIAA AACAmAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACA mAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAA ABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABYA AAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAA AAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABYAAAAAAAAA AIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAA AACAmAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABYAAAAAAAAAAIAAAACA mAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAA ABUAAAAAAAAAAIAAAACAmAAAABUAAAAAAAAAAIAAAACAmAAAABYAAAASABsACgABAFsADwACAAAA AAAAACQAAEDx/wIAJAAAAAYATgBvAHIAbQBhAGwAAAACAAAABABtSAkESAABQAEAAgBIAAAACQBI AGUAYQBkAGkAbgBnACAAMQAAABAAAQAGJAETpPAAFKQ8AEAmABMANQiBQ0ocAEtIHABPSgIAUUoC AABGAAJAAQACAEYAAAAJAEgAZQBhAGQAaQBuAGcAIAAyAAAAEAACAAYkAROk8AAUpDwAQCYBEgA1 CIE2CIFDShgAT0oCAFFKAgAAAAAAAAAAAAAAAAAAADwAQUDy/6EAPAAAABYARABlAGYAYQB1AGwA dAAgAFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAAwAFpAAQDyADAAAAAK AFAAbABhAGkAbgAgAFQAZQB4AHQAAAACAA8ACABPSgMAUUoDAD4AH0ABAAIBPgAAAAYASABlAGEA ZABlAHIAAAATABAAEmQQ/wAADcYIAAKwE2AnAQIADABDShgAT0oDAFFKAwA+ACBAAQASAT4AAAAG AEYAbwBvAHQAZQByAAAAEwARABJkEP8AAA3GCAACsBNgJwECAAwAQ0oYAE9KAwBRSgMAJgApQKIA IQEmAAAACwBQAGEAZwBlACAATgB1AG0AYgBlAHIAAAAAADgAWUABADIBOAAAAAwARABvAGMAdQBt AGUAbgB0ACAATQBhAHAAAAAGABMALUQgAQgAT0oEAFFKBAAoAFVAogBBASgAAAAJAEgAeQBwAGUA cgBsAGkAbgBrAAAABgA+KgFCKgI6AP5PAQBSAToAAAAIAFIARgBDACAAVABlAHgAdAAAAAwAFQAP hLABEmQQ/wAADABDShgAT0oDAFFKAwA8AP5PAQBSATwAAAALAFIARgBDACAASABlAGEAZABpAG4A ZwAAAAgAFgASZBD/AAAMAENKGABPSgMAUUoDADQAK0BRAXIBNAAAAAwARQBuAGQAbgBvAHQAZQAg AFQAZQB4AHQAAAAKABcAD4RgAxGEUP4AADYAKkDy/4EBNgAAABEARQBuAGQAbgBvAHQAZQAgAFIA ZQBmAGUAcgBlAG4AYwBlAAAAAwBIKgAATgD+bwEAkgFOAAQABQBBAFMATgAuADEAAAAlABkADcYg AAo3Am4EpQbcCBMLSg2BD7gR7xMmFsDAwMDAwMDAwMAADABPSgMAUUoDAG1IAAREAP5vogChAUQA BAAJAEEAUwBOADEAXwB3AG8AcgBkAAAAIQA1CIFCKgBDShYAT0oAAFFKAABrSOQEbUgABG5IAAR1 CAEAJwgAAHsgAAABAAAAAAAeBgAAIQYAAAAAAAASFQAAeyAAAAcAAEwAAAcA/////wcALUwAAAcA /////wAAAAABAAAACgAAAAsAAAAaAAAAJAAAACUAAABTAAAAXQAAAF4AAAB2AAAAdwAAAHgAAAB5 AAAAegAAAJYAAACXAAAAmAAAAKwAAACtAAAAcgEAAHMBAABCAwAApQMAAAcEAAAIBAAACQQAAAoE AAALBAAADAQAABgEAAAZBAAAfwYAADsHAAA8BwAAPQcAAGIHAABjBwAAZAcAACsIAAAsCAAALQgA AEAIAABBCAAADwkAABEKAAASCgAAEwoAAGAKAADWCgAA1woAAFQLAABVCwAAegsAAHsLAADHCwAA 5QsAABYMAABJDAAAiQwAAMEMAAAADQAAJQ0AAFANAACODQAAvw0AANENAADvDQAACg4AADwOAABq DgAAiA4AAIkOAACKDgAAiw4AAJ0OAACeDgAAMA8AABsQAAAREgAAEhIAABMSAABXEgAAWBIAAHUT AAB2EwAAdxMAAJITAACTEwAADhQAAAAVAAABFQAAAhUAABAVAAARFQAAKxYAAC0WAABGFgAARxYA ALMZAAC0GQAAthkAALgZAADgGQAA4RkAAOIZAADjGQAAHRoAAB4aAAAgGgAAWRoAAFsaAADEGgAA xRoAAGkbAABqGwAAxhsAAMcbAADIGwAAYhwAAGMcAABkHAAA5xwAAOgcAADpHAAAoh0AAKMdAACk HQAAAh4AAAMeAAAEHgAAbh4AAG8eAABwHgAAyB4AAMkeAADKHgAARR8AAEYfAABHHwAArx8AALAf AACxHwAAFyAAABggAAAZIAAAeCAAAHwgAACpAAAAFgAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAA gAAAAICZAAAAAAAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAA AICZAAAAAAAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICZ AAAAAAAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICZAAAA AAAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAA AAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAGQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAA FgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAA gAAAAICYAAAAAAAAAAAAAAAAgAAAAIAIAAAAFQAAAAAAAAAAgAAAAICaQAAAEQAAAAAAAAAAgAAA AICaQAAAEQAAAAAAAAAAgAAAAICaQAAAAAAAAAAAAAAAgAAAAICaQAAAEAAAAAAAAAAAgAAAAICY QAAAEAAAAAAAAAAAgAAAAICYQAAAEAAAAAAAAAAAgAAAAICaQAAAAAAAAAAAAAAAgAAAAICYQAAA EQAAAAAAAAAAgAAAAICaQAAAAAAAAAAAAAAAgAAAAICYQAAAEQAAAAAAAAAAgAAAAICYQAAAEQAA AAAAAAAAgAAAAIAKAAAAAAAAAAAAAAAAAAAAAACaQAAAFwAAAAAAAAAAgAAAAICYQAAAFwAAAAAA AAAAgAAAAICYQAAAFwAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQAAAAAAAAAA gAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQABAAAAAAAAgAAA AICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQACAAAAAAAAgAAAAICY QAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQADAAAAAAAAgAAAAICYQAAA FQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQAEAAAAAAAAgAAAAICYQAAAFQAA AAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQAFAAAAAAAAgAAAAICYQAAAFQAAAAAA AAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQAGAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAA gAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQAHAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAA AICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQAIAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICY QAAAFQAAAAAAAAAAgAAAAICYQBEgFQAJAAAAAAAAgAAAAICaQAAAFQAAAAAAAAAAgAAAAICaQAAA FQAAAAAAAAAAgAAAAICaQAAAFwAAAAAAAAAAgAAAAIAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAgAAAAQAAAAGAAAABgAAADAAAAAwAAAAawAAAGsAAACnAAAApwAAAKcAAACnAAAA pwAAAKcAAACnAAAAqgAAAAAEAACvHQAAiGgAABwAAAAkAAAAAAQAAAkIAAB6DwAAEhYAAK8ZAABb HgAA/FMAACRfAADIZwAAiGgAAB0AAAAfAAAAIAAAACEAAAAjAAAAJQAAAC0AAAA1AAAANgAAAAAE AAASGQAAxx4AAB4AAAAiAAAA//8MAAAABwBVAG4AawBuAG8AdwBuAA0AUABhAHUAbAAgAEUALgAg AEoAbwBuAGUAcwAMAE0AYQByAGsAawB1ACAASwBvAHIAcABpAAoAUgBpAGMAaAAgAEIAbwB3AGUA bgAMAFAAZQB0AGUAIABDAG8AcgBkAGUAbABsAAoATwByAGkAdAAgAEwAZQB2AGkAbgAGAGYAbwBv AGIAYQByAAgASgBpAG0AIABUAG8AZwBhAAoASgBhAG0AZQBzACAAVABvAGcAYQALAFIAaQBjAGsA IABCAG8AaQB2AGkAZQANAE4AYQBuAGMAeQAgAEYAZQBsAGQAbQBhAG4ADQBFAHMAcABlAG4AIABT AGsAagDmAHIAYQBuAOQFAAACBgAADAYAAIcZAACwGQAAsRkAAHsgAAATWBT/FYQTWBT/FYxfAAAA ZgAAAGgAAACbAAAAogAAAKQAAACqAAAAEyH0/5WAEyH0/5WADwAA8DgAAAAAAAbwGAAAAAIIAAAC AAAAAQAAAAEAAAABAAAAAgAAAEAAHvEQAAAA//8AAAAA/wCAgIAA9wAAEAAPAALwkgAAABAACPAI AAAAAQAAAAEEAAAPAAPwMAAAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgA AAAABAAABQAAAA8ABPBCAAAAEgAK8AgAAAABBAAAAA4AAFMAC/AeAAAAvwEAABAAywEAAAAA/wEA AAgABAMJAAAAPwMBAAEAAAAR8AQAAAABAAAA//8BAAAABgBjADEAdABpAHQAZQAJHAAAfCAAAAAA AAAJHAAAfCAAAAAAAACjAgAArAIAAAMGAAAMBgAACwsAABMLAACdCwAApQsAAKIQAACqEAAAOBEA AEARAAAiFwAALxcAALMZAACzGQAAtBkAALQZAAC1GQAAtRkAALYZAAC3GQAAuBkAALkZAABaGgAA WxoAAF4aAABlGgAAgRoAAIUaAADFGgAAxhoAANgaAADfGgAA6xsAAPUbAAARHAAAHhwAAOwcAADz HAAA+BwAAAMdAAAIHQAAEB0AABkdAAAiHQAAtB0AAM0dAAAEHgAACx4AABUeAAAdHgAAKR4AADEe AAB9HgAAhR4AAJEeAACZHgAAyh4AANEeAADvHgAA9x4AALQfAAC5HwAAfCAAAAcAHAAHABwABwAc AAcAHAAHABwABwAcAAcAHAAHAAQABwAEAAIABAAHAAQABwAEAAcAAgAHABwABwAcAAcABAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAAAAAAgwEAAIYBAABMAgAATwIAAHEIAAB2CAAAjgsAAJQLAADICwAA0AsAAOULAADpCwAA FgwAAB4MAABJDAAAVAwAAIkMAACRDAAAPA0AAD8NAABQDQAAVw0AAI4NAACUDQAAvw0AAMMNAADR DQAA2w0AAO8NAAD3DQAACg4AAA4OAABqDgAAcQ4AACoSAABKEgAAXhUAAG4VAAAXFgAAKRYAAIgW AAALGAAADBgAALIZAACzGQAAsxkAALQZAAC0GQAAtRkAALUZAAC2GQAAtxkAALgZAAC5GQAAWhoA AFsaAADFGgAA1BoAAHwgAAAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAEAAcABAAC AAQABwAEAAcABAAHAAIABwAEAAcA//8UAAAACgBPAHIAaQB0ACAATABlAHYAaQBuAEcAQwA6AFwA dwBpAG4AZABvAHcAcwBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2 AGUAIABvAGYAIABkAHIAYQBmAHQALQBsAGUAdgBpAG4ALQBoADMAMgAzAC0AdQByAGwALQBzAGMA aABlAG0AZQAtADAAMAAuAGEAcwBkAAoATwByAGkAdAAgAEwAZQB2AGkAbgA0AEMAOgBcAFMAdABh AG4AZABhAHIAZABzAFwASQBFAFQARgBcAGQAcgBhAGYAdAAtAGwAZQB2AGkAbgAtAGgAMwAyADMA LQB1AHIAbAAtAHMAYwBoAGUAbQBlAC0AMAAwAC4AZABvAGMACgBPAHIAaQB0ACAATABlAHYAaQBu ADQAQwA6AFwAUwB0AGEAbgBkAGEAcgBkAHMAXABJAEUAVABGAFwAZAByAGEAZgB0AC0AbABlAHYA aQBuAC0AaAAzADIAMwAtAHUAcgBsAC0AcwBjAGgAZQBtAGUALQAwADAALgBkAG8AYwAKAE8AcgBp AHQAIABMAGUAdgBpAG4ANABDADoAXABTAHQAYQBuAGQAYQByAGQAcwBcAEkARQBUAEYAXABkAHIA YQBmAHQALQBsAGUAdgBpAG4ALQBoADMAMgAzAC0AdQByAGwALQBzAGMAaABlAG0AZQAtADAAMAAu AGQAbwBjAAoATwByAGkAdAAgAEwAZQB2AGkAbgA0AEMAOgBcAFMAdABhAG4AZABhAHIAZABzAFwA SQBFAFQARgBcAGQAcgBhAGYAdAAtAGwAZQB2AGkAbgAtAGgAMwAyADMALQB1AHIAbAAtAHMAYwBo AGUAbQBlAC0AMAAwAC4AZABvAGMACgBPAHIAaQB0ACAATABlAHYAaQBuAEcAQwA6AFwAdwBpAG4A ZABvAHcAcwBcAFQARQBNAFAAXABBAHUAdABvAFIAZQBjAG8AdgBlAHIAeQAgAHMAYQB2AGUAIABv AGYAIABkAHIAYQBmAHQALQBsAGUAdgBpAG4ALQBoADMAMgAzAC0AdQByAGwALQBzAGMAaABlAG0A ZQAtADAAMAAuAGEAcwBkAAoATwByAGkAdAAgAEwAZQB2AGkAbgA0AEMAOgBcAFMAdABhAG4AZABh AHIAZABzAFwASQBFAFQARgBcAGQAcgBhAGYAdAAtAGwAZQB2AGkAbgAtAGgAMwAyADMALQB1AHIA bAAtAHMAYwBoAGUAbQBlAC0AMAAwAC4AZABvAGMACgBPAHIAaQB0ACAATABlAHYAaQBuADUAQwA6 AFwAUwB0AGEAbgBkAGEAcgBkAHMAXABJAEUAVABGAFwAZABkAHIAYQBmAHQALQBsAGUAdgBpAG4A LQBoADMAMgAzAC0AdQByAGwALQBzAGMAaABlAG0AZQAtADAAMAAuAGQAbwBjAAoATwByAGkAdAAg AEwAZQB2AGkAbgA1AEMAOgBcAFMAdABhAG4AZABhAHIAZABzAFwASQBFAFQARgBcAGQAZAByAGEA ZgB0AC0AbABlAHYAaQBuAC0AaAAzADIAMwAtAHUAcgBsAC0AcwBjAGgAZQBtAGUALQAwADAALgBk AG8AYwAKAE8AcgBpAHQAIABMAGUAdgBpAG4ANQBDADoAXABTAHQAYQBuAGQAYQByAGQAcwBcAEkA RQBUAEYAXABkAGQAcgBhAGYAdAAtAGwAZQB2AGkAbgAtAGgAMwAyADMALQB1AHIAbAAtAHMAYwBo AGUAbQBlAC0AMAAwAC4AZABvAGMAEQDXfzoKkGNmT/8P/w//D/8P/w//D/8P/w//DwAAvA/bDpYR XK3/D/8P/w//D/8P/w//D/8P/w8AAKNMhCIXAAkE/w//D/8P/w//D/8P/w//D/8PAQDZFjQrDwAJ BP8P/w//D/8P/w//D/8P/w//DwEAYyEqMw8ACQT/DwAAAAAAAAAAAAAAAAAAAAABAAdCyzOav5hB /w//D/8P/w//D/8P/w//D/8PAAC1aWlGDwAJBP8P/w//D/8P/w//D/8P/w//DwEA8w5BTJ5w1mj/ D/8P/w//D/8P/w//D/8P/w8BALEbGE/yLMQ7/w//D/8P/w//D/8P/w//D/8PAQD6LeVQAQAJBP8P AAAAAAAAAAAAAAAAAAAAAAEARxzSVaz+qP7/D/8P/w//D/8P/w//D/8P/w8BACZCjlpktWK3/w// D/8P/w//D/8P/w//D/8PAQDoC+xcDwAJBP8P/w//D/8P/w//D/8P/w//DwEANy8PcEQZjCb/D/8P /w//D/8P/w//D/8P/w8BAP53+3nCe85W/w//D/8P/w//D/8P/w//D/8PAQDcB9V6DwAJBP8PAAAA AAAAAAAAAAAAAAAAAAEA9Hj8eg8ACQT/DwArAAowASZQAQAfsNAvILBgNiGwAAAisFAHI5DgASSQ AAAlsAAAF7AAABiwAAAuAAkwAAowASZQAQAfsNAvILBgNiGwAAAisFAHI5DgASSQAAAlsAAAF7AA ABiwAAAAUgBMAHMAIABhAHIAZQAgAHcAaQB0AGgAaQBuACAAQQBuAG4AZQB4ACAASwAvAEgALgAz ADIAMwAgAFsAMQAzAA0ADQANADMAMQANAAIAIAAgAEIAcgBhAGQAbgBlAHIALAAgAFMALgAsACAA IgBLAGUAeQAgAHcAbwByAGQAcwAgAGYAbwByACAAdQBzAGUAIABpAG4AIABSAEYAQwBzACAAdABv ACAASQBuAGQAaQBjAGEAdABlACAAUgBlAHEAdQBpAHIAZQBtAGUAbgB0ACAATABlAHYAZQBsAHMA IgAsACAAQgBDAFAAIAAxADQALAAgAFIARgBDACAAMgAxADEAOQAsACAATQBhAHIAYwBoACAAMQA5 ADkANwANAA0AMgAgACAAQwByAG8AYwBrAGUAcgAsACAARAAuACAAYQBuAGQAIABPAHYAZQByAGUA bABsACwAIABQAC4AKABFAGQAaQB0AG8AcgBzACkALAAgACIAQQB1AGcAbQBlAG4AdABlAGQAIABC AE4ARgAgAGYAbwByACAAUwB5AG4AdABhAHgAIABTAHAAZQBjAGkAZgBpAGMAYQB0AGkAbwBuAHMA OgAgAEEAQgBOAEYAIgAsACAAUgBGAEMAIAAyADIAMwA0ACwAIABJAG4AdABlAHIAbgBlAHQAIABN AGEAaQBsACAAQwBvAG4AcwBvAHIAdABpAHUAbQAgAGEAbgBkACAARABlAG0AbwBuACAASQBuAHQA ZQByAG4AZQB0ACAATAB0AGQALgAsACAATgBvAHYAZQBtAGIAZQByACAAMQA5ADkANwANAA0ASQBU AFUALQBUACAAUgBlAGMAbwBtAG0AZQBuAGQAYQB0AGkAbwBuACAASAAuADMAMgAzACAAHCBQAGEA YwBrAGUAdAAtAGIAYQBzAGUAZAAgAG0AdQBsAHQAaQBtAGUAZABpAGEAIABjAG8AbQBtAHUAbgBp AGMAYQB0AGkAbwBuAHMAIABzAHkAcwB0AGUAbQBzAB0gLAAgAFMAZQBwAHQAZQBtAGIAZQByACAA MQA5ADkAOQANAA0ADQBJAFQAVQAtAFQAIABSAGUAYwBvAG0AbQBlAG4AZABhAHQAaQBvAG4AIABI AC4AMgAyADUALgAwACAAHCBDAGEAbABsACAAcwBpAGcAbgBhAGwAbABpAG4AZwAgAHAAcgBvAHQA bwBjAG8AbABzACAAYQBuAGQAIABtAGUAZABpAGEAIABzAHQAcgBlAGEAbQAgAHAAYQBjAGsAZQB0 AGkAegBhAHQAaQBvAG4AIABmAG8AcgAgAHAAYQBjAGsAZQB0AC0AYgBhAHMAZQBkACAAbQB1AGwA dABpAG0AZQBkAGkAYQAgAGMAbwBtAG0AdQBuAGkAYwBhAHQAaQBvAG4AIABzAHkAcwB0AGUAbQBz AB0gLAAgAFMAZQBwAHQAZQBtAGIAZQByACAAMQA5ADkAOQANAA0ADQBJAFQAVQAtAFQAIABSAGUA YwBvAG0AbQBlAG4AZABhAHQAaQBvAG4AIABIAC4AMgAzADUAIAAcIFMAZQBjAHUAcgBpAHQAeQAg AGEAbgBkACAARQBuAGMAcgB5AHAAdABpAG8AbgAgAGYAbwByACAASAAgAFMAZQByAGkAZQBzACAA KABIAC4AMwAyADMAIABhAG4AZAAgAG8AdABoAGUAcgAgAEgALgAyADQANQAgAGIAYQBzAGUAZAAp ACAAbQB1AGwAdABpAG0AZQBkAGkAYQAgAHQAZQByAG0AaQBuAGEAbABzAB0gLAAgAEoAYQBuAHUA YQByAHkAIAAxADkAOQA4AA0ADQANAE0ALgAgAEgAYQBuAGQAbABlAHkALAAgAEgALgAgAFMAYwBo AHUAbAB6AHIAaQBuAG4AZQAsACAARQAuACAAUwBjAGgAbwBvAGwAZQByACwAIABhAG4AZAAgAEoA LgAgAFIAbwBzAGUAbgBiAGUAcgBnACwAIAAiAFMASQBQADoAIABzAGUAcwBzAGkAbwBuACAAaQBu AGkAdABpAGEAdABpAG8AbgAgAHAAcgBvAHQAbwBjAG8AbAAsACIAIABSAGUAcQB1AGUAcwB0ACAA ZgBvAHIAIABDAG8AbQBtAGUAbgB0AHMAIAAoAFAAcgBvAHAAbwBzAGUAZAAgAFMAdABhAG4AZABh AHIAZAApACAAMgA1ADQAMwAsACAASQBuAHQAZQByAG4AZQB0ACAARQBuAGcAaQBuAGUAZQByAGkA bgBnACAAVABhAHMAawAgAEYAbwByAGMAZQAsACAATQBhAHIALgAgADEAOQA5ADkADQANAA0ASwAu ACAAUwBpAG4AZwBoACAAYQBuAGQAIABIAC4AIABTAGMAaAB1AGwAegByAGkAbgBuAGUALAAcIEkA bgB0AGUAcgB3AG8AcgBrAGkAbgBnACAAQgBlAHQAdwBlAGUAbgAgAFMASQBQAC8AUwBEAFAAIABh AG4AZAAgAEgALgAzADIAMwAdICAASQBuAHQAZQByAG4AZQB0ACAARAByAGEAZgB0ACwAIABNAGEA eQAgADIAMAAwADAADQANAA0AQgBlAHIAbgBlAHIAcwAtAEwAZQBlACwAIABUAC4ALAAgAE0AYQBz AGkAbgB0AGUAcgAsACAATAAuACAAYQBuAGQAIABNAC4AIABNAGMAQwBhAGgAaQBsAGwALAAgACIA VQBuAGkAZgBvAHIAbQAgAHIAZQBzAG8AdQByAGMAZQAgAGwAbwBjAGEAdABvAHIAcwAgACgAVQBS AEwAKQAiACwAIABSAEYAQwAgADEANwAzADgALAAgAEQAZQBjAGUAbQBiAGUAcgAgADEAOQA5ADQA DQANAA0ASABvAGYAZgBtAGEAbgAsACAAUAAuACwAIABNAGEAcwBpAG4AdABlAHIALAAgAEwALgAg AGEAbgBkACAASgAuACAAWgBhAHcAaQBuAHMAawBpACwAIAAiAFQAaABlACAAbQBhAGkAbAB0AG8A IABVAFIATAAgAHMAYwBoAGUAbQBlACIALAAgAFIARgBDACAAMgAzADYAOAAsACAASgB1AGwAeQAg ADEAOQA5ADgADQANAA0AQgBlAHIAbgBlAHIAcwAtAEwAZQBlACwAIABUAC4ALAAgAEYAaQBlAGwA ZABpAG4AZwAsACAAUgAuACAAYQBuAGQAIABMAC4AIABNAGEAcwBpAG4AdABlAHIALAAgACIAVQBu AGkAZgBvAHIAbQAgAHIAZQBzAG8AdQByAGMAZQAgAGkAZABlAG4AdABpAGYAaQBlAHIAcwAgACgA VQBSAEkAKQA6ACAAZwBlAG4AZQByAGkAYwAgAHMAeQBuAHQAYQB4ACIALAAgAFIARgBDACAAMgAz ADkANgAsACAAQQB1AGcAdQBzAHQAIAAxADkAOQA4AA0ADQANAEMAcgBvAGMAawBlAHIALAAgAEQA LgAsACAAIgBTAHQAYQBuAGQAYQByAGQAIABmAG8AcgAgAHQAaABlACAAZgBvAHIAbQBhAHQAIABv AGYAIABBAFIAUABBACAAaQBuAHQAZQByAG4AZQB0ACAAdABlAHgAdAAgAG0AZQBzAHMAYQBnAGUA cwAiACwAIABSAEYAQwAgAFMAVABEACAAMQAxACwAIABSAEYAQwAgADgAMgAyACwAIABBAHUAZwB1 AHMAdAAgADEAOQA4ADIADQANAA0AUgAuACAAUABlAHQAawBlACAAYQBuAGQAIABJAC4AIABLAGkA bgBnACwAIAAcIFIAZQBnAGkAcwB0AHIAYQB0AGkAbwBuACAAUAByAG8AYwBlAGQAdQByAGUAcwAg AGYAbwByACAAVQBSAEwAIABTAGMAaABlAG0AZQAgAE4AYQBtAGUAcwAdICwAIABSAEYAQwAgADIA NwAxADcALAAgAEIAQwBQAC0AMwA1ACwAIABOAG8AdgBlAG0AYgBlAHIAIAAxADkAOQA5AA0ADQAN ADEAMwAgAEkAVABVAC0AVAAgAFIAZQBjAG8AbQBtAGUAbgBkAGEAdABpAG8AbgAgAEgALgAzADIA MwAgAEEAbgBuAGUAeAAgAEsAIAAcIEgAVABUAFAAIABiAGEAcwBlAGQAIABzAGUAcgB2AGkAYwBl ACAAQwBvAG4AdAByAG8AbAAgAFQAcgBhAG4AcwBwAG8AcgB0ACAAQwBoAGEAbgBuAGUAbAAdICwA IABNAGEAeQAgADIAMAAwADAADQANAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAGQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAA AAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAA AICeAAAAAAAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQBbHgAAxB4AAMUeAADGHgAAxx4AAKBMAACiTAAApEwAAKpMAAB8TQAA fk0AAMZOAADITgAAgE8AAIJPAACETwAAuFAAALpQAAC8UAAAwlEAAMRRAADGUQAAOFMAADpTAAA8 UwAA+FMAAPpTAAD8UwAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA8AAA AAAAAAAAAAAAAPsAAAAAAAAAAAAAAAD7AAAAAAAAAAAAAAAA+wAAAAAAAAAAAAAAAPsAAAAAAAAA AAAAAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA 6QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAO4AAAAA AAAAAAAAAADuAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAA AAAA6QAAAAAAAAAAAAAAAO4AAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAO4A AAAAAAAAAAAAAADuAAAAAAAAAAAAAAAAAAAABRUACiYAC0YRAAABFQAAChUABiQBE6TwABSkPAAt RAAdQCYAAAEAAAABFwAAGwAAAAAAAACAAAAAgJgAAAAVAAAAAAAAAACAAAAAgJgAAAAVAAAAAAAA AACAAAAAgJgAAAAVAAAAAAAAAACAAAAAgJgAAAAVAAAAAAAAAACAAAAAgJgAAAAVAAAAAAAAAACA AAAAgJgAAAAVAAAAAAAAAACAAAAAgJgAAAAVAAAAAAAAAACAAAAAgJgAAAAWAAAAAAAAAACAAAAA gJgAAAAAAAAAAAAAAACAAAAAgAgAAAAVAAAAAAAAAACAAAAAgJpAAAARAAAAAAAAAACAAAAAgJpA AAARAAAAAAAAAACAAAAAgJpAAAAAAAAAAAAAAACAAAAAgJpAAAAQAAAAAAAAAACAAAAAgJhAAAAQ AAAAAAAAAACAAAAAgJhAAAAQAAAAAAAAAACAAAAAgJpAAAAAAAAAAAAAAACAAAAAgJpAAAARAAAA AAAAAACAAAAAgJpAAAAAAAAAAAAAAACAAAAAgJhAAAARAAAAAAAAAACAAAAAgJhAAAARAAAAAAAA AACAAAAAgAoAAAAAAAAAAAAAAAAAAAAAAJpAAAAXAAAAAAAAAACAAAAAgJhAAAAXAAAAAAAAAACA AAAAgJhAAAAXAAAAAAAAAACAAAAAgJhAAAAVAAAAAAAAAACAAAAAgJhAESAVAAAAAAAAAACAAAAA gJhAAAAVAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAClBsAHtAC0AIAAEjQAABAAGQBkAAAAGQAAAAUaAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAA//8SAAAAAAAAABUATgBlAHQAdwBvAHIAawAgAFcAbwByAGsAaQBuAGcAIABHAHIA bwB1AHAAAAAAAAAACwBNAGkAawBlACAARwBhAGgAcgBuAHMACgBPAHIAaQB0ACAATABlAHYAaQBu AAAAAAAAAAAAAAAAAAAAAAAAAAAAEgAbAAoAAQBbAA8AAgAAAAAAAAAkAABA8f8CACQAAAAGAE4A bwByAG0AYQBsAAAAAgAAAAQAbUgJBEgAAUABAAIASAAAAAkASABlAGEAZABpAG4AZwAgADEAAAAQ AAEABiQBE6TwABSkPABAJgATADUIgUNKHABLSBwAT0oCAFFKAgAARgACQAEAAgBGAAAACQBIAGUA YQBkAGkAbgBnACAAMgAAABAAAgAGJAETpPAAFKQ8AEAmARIANQiBNgiBQ0oYAE9KAgBRSgIAAAAA AAAAAAAAAAAAAAA8AEFA8v+hADwAAAAWAEQAZQBmAGEAdQBsAHQAIABQAGEAcgBhAGcAcgBhAHAA aAAgAEYAbwBuAHQAAAAAAAAAAAAAAAAAMABaQAEA8gAwAAAACgBQAGwAYQBpAG4AIABUAGUAeAB0 AAAAAgAPAAgAT0oDAFFKAwA+AB9AAQACAT4AAAAGAEgAZQBhAGQAZQByAAAAEwAQABJkEP8AAA3G CAACsBNgJwECAAwAQ0oYAE9KAwBRSgMAPgAgQAEAEgE+AAAABgBGAG8AbwB0AGUAcgAAABMAEQAS ZBD/AAANxggAArATYCcBAgAMAENKGABPSgMAUUoDACYAKUCiACEBJgAAAAsAUABhAGcAZQAgAE4A dQBtAGIAZQByAAAAAAA4AFlAAQAyATgAAAAMAEQAbwBjAHUAbQBlAG4AdAAgAE0AYQBwAAAABgAT AC1EIAEIAE9KBABRSgQAKABVQKIAQQEoAAAACQBIAHkAcABlAHIAbABpAG4AawAAAAYAPioBQioC OgD+TwEAUgE6AAAACABSAEYAQwAgAFQAZQB4AHQAAAAMABUAD4SwARJkEP8AAAwAQ0oYAE9KAwBR SgMAPAD+TwEAUgE8AAAACwBSAEYAQwAgAEgAZQBhAGQAaQBuAGcAAAAIABYAEmQQ/wAADABDShgA T0oDAFFKAwA0ACtAUQFyATQAAAAMAEUAbgBkAG4AbwB0AGUAIABUAGUAeAB0AAAACgAXAA+EYAMR hFD+AAA2ACpA8v+BATYAAAARAEUAbgBkAG4AbwB0AGUAIABSAGUAZgBlAHIAZQBuAGMAZQAAAAMA SCoAAE4A/m8BAJIBTgAEAAUAQQBTAE4ALgAxAAAAJQAZAA3GIAAKNwJuBKUG3AgTC0oNgQ+4Ee8T JhbAwMDAwMDAwMDAAAwAT0oDAFFKAwBtSAAERAD+b6IAoQFEAAQACQBBAFMATgAxAF8AdwBvAHIA ZAAAACEANQiBQioAQ0oWAE9KAABRSgAAa0jkBG1IAARuSAAEdQgBABAIAAB1IAAAAQAAAAAAHgYA ACEGAAAAAAAAEBUAAHUgAAADAABMAAAAAP////8DAC1MAAAAAP////8AAAAAAQAAAAoAAAALAAAA GgAAACQAAAAlAAAAUwAAAF0AAABeAAAAdgAAAHcAAAB4AAAAeQAAAHoAAACWAAAAlwAAAJgAAACs AAAArQAAAFsBAABcAQAAKwMAAI4DAADwAwAA8QMAAPIDAADzAwAA9AMAAPUDAAABBAAAAgQAAGgG AAAkBwAAJQcAACYHAABLBwAATAcAAE0HAAAUCAAAFQgAABYIAAApCAAAKggAAPgIAAD6CQAA+wkA APwJAABJCgAASgoAANUKAADWCgAAUwsAAFQLAAB5CwAAegsAAMYLAADkCwAAFQwAAEgMAACIDAAA wAwAAP8MAAAkDQAATw0AAI0NAAC+DQAA0A0AAO4NAAAJDgAAOw4AAGkOAACHDgAAiA4AAIkOAACK DgAAnA4AAJ0OAAAvDwAAGhAAABASAAAREgAAEhIAAFYSAABXEgAAdBMAAHUTAAB2EwAAkRMAAJIT AAANFAAA/xQAAAAVAAABFQAADxUAABAVAAARFQAAEhUAACUVAAAmFQAAjxUAAJAVAACRFQAAqBUA AKkVAAC0FQAAxBUAAOIVAADzFQAAChYAACQWAAAlFgAAJxYAAEAWAABBFgAArRkAAK4ZAACwGQAA shkAANoZAADbGQAA3BkAAN0ZAAAXGgAAGBoAABoaAABTGgAAVRoAAL4aAAC/GgAAYxsAAGQbAADA GwAAwRsAAMIbAABcHAAAXRwAAF4cAADhHAAA4hwAAOMcAACcHQAAnR0AAJ4dAAD8HQAA/R0AAP4d AABoHgAAaR4AAGoeAADCHgAAwx4AAMQeAAA/HwAAQB8AAEEfAACpHwAAqh8AAKsfAAARIAAAEiAA ABMgAAByIAAAcyAAAHYgAACpAAAAFgAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICZAAAA AAAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICZAAAAAAAA AAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICZAAAAAAAAAAAA AAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICZAAAAAAAAAAAAAAAA gAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAA AICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAGQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAA gAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICe AAAAAAAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICY AAAAAAAAAAAAAAAAgAAAAIAIAAAAFQAAAAAAAAAAgAAAAICaQAAAEQAAAAAAAAAAgAAAAICaQAAA EQAAAAAAAAAAgAAAAICaQAAAAAAAAAAAAAAAgAAAAICaQAAAEAAAAAAAAAAAgAAAAICYQAAAEAAA AAAAAAAAgAAAAICYQAAAEAAAAAAAAAAAgAAAAICaQAAAAAAAAAAAAAAAgAAAAICYQAAAEQAAAAAA AAAAgAAAAICaQAAAAAAAAAAAAAAAgAAAAICYQAAAEQAAAAAAAAAAgAAAAICYQAAAEQAAAAAAAAAA gAAAAIAKAAAAAAAAAAAAAAAAAAAAAACaQAAAFwAAAAAAAAAAgAAAAICYQAAAFwAAAAAAAAAAgAAA AICYQAAAFwAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQAAAAAAAAAAgAAAAICY QAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQABAAAAAAAAgAAAAICYQAAA FQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQACAAAAAAAAgAAAAICYQAAAFQAA AAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQADAAAAAAAAgAAAAICYQAAAFQAAAAAA AAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQAEAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAA gAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQAFAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAA AICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQAGAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICY QAAAFQAAAAAAAAAAgAAAAICYQBEgFQAHAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAA FQAAAAAAAAAAgAAAAICYQBEgFQAIAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAA AAAAAAAAgAAAAICYQBEgFQAJAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAA AAAAgAAAAICYQAAAFwAAAAAAAAAAgAAAAICYQAAAFwAAAAAAAAAAgAAAAIAKAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAQAAAAGAAAABgAAADAAAAAwAAAAawAAAGsAAACnAAAA pwAAAKcAAACnAAAApwAAAKcAAACnAAAAqgAAAAAEAACvHQAAbn8AABwAAAAkAAAAAAQAAAkIAAB6 DwAAEhYAAK8ZAABbHgAA/FMAACRfAADIZwAAynUAAG5/AAAdAAAAHwAAACAAAAAhAAAAIwAAACUA AAAtAAAANQAAADYAAAA+AAAAAAQAABIZAADHHgAAHgAAACIAAAD//wwAAAAHAFUAbgBrAG4AbwB3 AG4ADQBQAGEAdQBsACAARQAuACAASgBvAG4AZQBzAAwATQBhAHIAawBrAHUAIABLAG8AcgBwAGkA CgBSAGkAYwBoACAAQgBvAHcAZQBuAAwAUABlAHQAZQAgAEMAbwByAGQAZQBsAGwACgBPAHIAaQB0 ACAATABlAHYAaQBuAAYAZgBvAG8AYgBhAHIACABKAGkAbQAgAFQAbwBnAGEACgBKAGEAbQBlAHMA IABUAG8AZwBhAAsAUgBpAGMAawAgAEIAbwBpAHYAaQBlAA0ATgBhAG4AYwB5ACAARgBlAGwAZABt AGEAbgANAEUAcwBwAGUAbgAgAFMAawBqAOYAcgBhAG4AzQUAAOsFAAD1BQAAgRkAAKoZAACrGQAA dSAAABNYFP8VhBNYFP8VjF8AAABmAAAAaAAAAJsAAACiAAAApAAAAKoAAAATIfT/lYATIfT/lYAP AADwOAAAAAAABvAYAAAAAggAAAIAAAABAAAAAQAAAAEAAAACAAAAQAAe8RAAAAD//wAAAAD/AICA gAD3AAAQAA8AAvCSAAAAEAAI8AgAAAABAAAAAQQAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAA AAAAAAAAAAAAAAAAAAACAArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL 8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAD//wEAAAAGAGMA MQB0AGkAdABlAAMcAAB2IAAAAAAAAAMcAAB2IAAAAAAAAIwCAACVAgAA7AUAAPUFAAAKCwAAEgsA AJwLAACkCwAAoRAAAKkQAAA3EQAAPxEAABwXAAApFwAArRkAAK0ZAACuGQAArhkAAK8ZAACvGQAA sBkAALEZAACyGQAAsxkAAFQaAABVGgAAWBoAAF8aAAB7GgAAfxoAANIaAADZGgAA5RsAAO8bAAAL HAAAGBwAAOYcAADtHAAA8hwAAP0cAAACHQAACh0AABMdAAAcHQAArh0AAMcdAAD+HQAABR4AAA8e AAAXHgAAIx4AACseAAB3HgAAfx4AAIseAACTHgAAxB4AAMseAADpHgAA8R4AAK4fAACzHwAAdiAA AAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAQABwAEAAIABAAHAAQABwAEAAcAAgAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHAAAAAABsAQAAbwEAADUCAAA4AgAAWggAAF8IAACNCwAAkwsAAMcLAADPCwAA 5AsAAOgLAAAVDAAAHQwAAEgMAABTDAAAiAwAAJAMAAA7DQAAPg0AAE8NAABWDQAAjQ0AAJMNAAC+ DQAAwg0AANANAADaDQAA7g0AAPYNAAAJDgAADQ4AAGkOAABwDgAAKRIAAEkSAABYFQAAaBUAABEW AAAjFgAAghYAAAUYAAAGGAAArBkAAK0ZAACtGQAArhkAAK4ZAACvGQAArxkAALAZAACxGQAAshkA ALMZAABUGgAAVRoAAHYgAAAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAEAAcABAAC AAQABwAEAAcABAAHAAIABwD//xQAAAAKAE8AcgBpAHQAIABMAGUAdgBpAG4ANABDADoAXABTAHQA YQBuAGQAYQByAGQAcwBcAEkARQBUAEYAXABkAHIAYQBmAHQALQBsAGUAdgBpAG4ALQBoADMAMgAz AC0AdQByAGwALQBzAGMAaABlAG0AZQAtADAAMAAuAGQAbwBjAAoATwByAGkAdAAgAEwAZQB2AGkA bgA0AEMAOgBcAFMAdABhAG4AZABhAHIAZABzAFwASQBFAFQARgBcAGQAcgBhAGYAdAAtAGwAZQB2 AGkAbgAtAGgAMwAyADMALQB1AHIAbAAtAHMAYwBoAGUAbQBlAC0AMAAwAC4AZABvAGMACgBPAHIA aQB0ACAATABlAHYAaQBuADQAQwA6AFwAUwB0AGEAbgBkAGEAcgBkAHMAXABJAEUAVABGAFwAZABy AGEAZgB0AC0AbABlAHYAaQBuAC0AaAAzADIAMwAtAHUAcgBsAC0AcwBjAGgAZQBtAGUALQAwADAA LgBkAG8AYwAKAE8AcgBpAHQAIABMAGUAdgBpAG4ARwBDADoAXAB3AGkAbgBkAG8AdwBzAFwAVABF AE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAGQAcgBhAGYA dAAtAGwAZQB2AGkAbgAtAGgAMwAyADMALQB1AHIAbAAtAHMAYwBoAGUAbQBlAC0AMAAwAC4AYQBz AGQACgBPAHIAaQB0ACAATABlAHYAaQBuADQAQwA6AFwAUwB0AGEAbgBkAGEAcgBkAHMAXABJAEUA VABGAFwAZAByAGEAZgB0AC0AbABlAHYAaQBuAC0AaAAzADIAMwAtAHUAcgBsAC0AcwBjAGgAZQBt AGUALQAwADAALgBkAG8AYwAKAE8AcgBpAHQAIABMAGUAdgBpAG4ANQBDADoAXABTAHQAYQBuAGQA YQByAGQAcwBcAEkARQBUAEYAXABkAGQAcgBhAGYAdAAtAGwAZQB2AGkAbgAtAGgAMwAyADMALQB1 AHIAbAAtAHMAYwBoAGUAbQBlAC0AMAAwAC4AZABvAGMACgBPAHIAaQB0ACAATABlAHYAaQBuADUA QwA6AFwAUwB0AGEAbgBkAGEAcgBkAHMAXABJAEUAVABGAFwAZABkAHIAYQBmAHQALQBsAGUAdgBp AG4ALQBoADMAMgAzAC0AdQByAGwALQBzAGMAaABlAG0AZQAtADAAMAAuAGQAbwBjAAoATwByAGkA dAAgAEwAZQB2AGkAbgA1AEMAOgBcAFMAdABhAG4AZABhAHIAZABzAFwASQBFAFQARgBcAGQAZABy AGEAZgB0AC0AbABlAHYAaQBuAC0AaAAzADIAMwAtAHUAcgBsAC0AcwBjAGgAZQBtAGUALQAwADAA LgBkAG8AYwAKAE8AcgBpAHQAIABMAGUAdgBpAG4ASABDADoAXAB3AGkAbgBkAG8AdwBzAFwAVABF AE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAGQAZAByAGEA ZgB0AC0AbABlAHYAaQBuAC0AaAAzADIAMwAtAHUAcgBsAC0AcwBjAGgAZQBtAGUALQAwADAALgBh AHMAZAAKAE8AcgBpAHQAIABMAGUAdgBpAG4ANQBDADoAXABTAHQAYQBuAGQAYQByAGQAcwBcAEkA RQBUAEYAXABkAGQAcgBhAGYAdAAtAGwAZQB2AGkAbgAtAGgAMwAyADMALQB1AHIAbAAtAHMAYwBo AGUAbQBlAC0AMAAwAC4AZABvAGMAEQDXfzoKkGNmT/8P/w//D/8P/w//D/8P/w//DwAAvA/bDpYR XK3/D/8P/w//D/8P/w//D/8P/w8AAKNMhCIXAAkE/w//D/8P/w//D/8P/w//D/8PAQDZFjQrDwAJ BP8P/w//D/8P/w//D/8P/w//DwEAYyEqMw8ACQT/DwAAAAAAAAAAAAAAAAAAAAABAAdCyzOav5hB /w//D/8P/w//D/8P/w//D/8PAAC1aWlGDwAJBP8P/w//D/8P/w//D/8P/w//DwEA8w5BTJ5w1mj/ D/8P/w//D/8P/w//D/8P/w8BALEbGE/yLMQ7/w//D/8P/w//D/8P/w//D/8PAQD6LeVQAQAJBP8P AAAAAAAAAAAAAAAAAAAAAAEARxzSVaz+qP7/D/8P/w//D/8P/w//D/8P/w8BACZCjlpktWK3/w// D/8P/w//D/8P/w//D/8PAQDoC+xcDwAJBP8P/w//D/8P/w//D/8P/w//DwEANy8PcEQZjCb/D/8P /w//D/8P/w//D/8P/w8BAP53+3nCe85W/w//D/8P/w//D/8P/w//D/8PAQDcB9V6DwAJBP8PAAAA AAAAAAAAAAAAAAAAAAEA9Hj8eg8ACQT/DwAAAAAAAAAAAAAAAAAAAAABAAUAAAAAAAEAAAAAAAAA AAAAAAAAAAAAAAMQAAAPhNACEYQw/RXGBQAB0AIGbygAAQAAAAEAAAAAAAEDAAAAAAAAAAAAAAAA AAAAAAMQAAAPhNACEYQw/RXGBQAB0AIGbygAAwAAAC4AAQABAAAAAAABAwUAAAAAAAAAAAAAAAAA AAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAA AAAAAAMQAAAPhDgEEYTI+xXGBQABOAQGbygABwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAA AAAAAAAAAAAAAAMQAAAPhDgEEYTI+xXGBQABOAQGbygACQAAAC4AAQAuAAIALgADAC4ABAABAAAA AAABAwUHCQsAAAAAAAAAAAAAAAADEAAAD4SgBRGEYPoVxgUAAaAFBm8oAAsAAAAuAAEALgACAC4A AwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMQAAAPhAgHEYT4+BXGBQABCAcGbygA DQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAAMQAAAP hAgHEYT4+BXGBQABCAcGbygADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAAAB AwUHCQsNDxEAAAAAAAAAAAADEAAAD4RwCBGEkPcVxgUAAXAIBm8oABEAAAAuAAEALgACAC4AAwAu AAQALgAFAC4ABgAuAAcALgAIAAQAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhGgBEYSY/hXG BQABaAEGbygAAgAAAC4AAQAAAAAEAQMAAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQ AgZvKAAEAAAALgABAC4AAQAAAAAEAQMFAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQ AgZvKAAGAAAALgABAC4AAgAuAAEAAAAABAEDBQcAAAAAAAAAAAAAAAAAAAMQAAAPhDgEEYTI+xXG BQABOAQGbygACAAAAC4AAQAuAAIALgADAC4AAQAAAAAEAQMFBwkAAAAAAAAAAAAAAAAAAxAAAA+E oAURhGD6FcYFAAGgBQZvKAAKAAAALgABAC4AAgAuAAMALgAEAC4AAQAAAAAEAQMFBwkLAAAAAAAA AAAAAAAAAxAAAA+EoAURhGD6FcYFAAGgBQZvKAAMAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAEA AAAABAEDBQcJCw0AAAAAAAAAAAAAAAMQAAAPhAgHEYT4+BXGBQABCAcGbygADgAAAC4AAQAuAAIA LgADAC4ABAAuAAUALgAGAC4AAQAAAAAEAQMFBwkLDQ8AAAAAAAAAAAAAAxAAAA+EcAgRhJD3FcYF AAFwCAZvKAAQAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4AAQAAAAAEAQMFBwkLDQ8R AAAAAAAAAAAAAxAAAA+EcAgRhJD3FcYFAAFwCAZvKAASAAAALgABAC4AAgAuAAMALgAEAC4ABQAu AAYALgAHAC4ACAAuAAEAAAAEAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhGgBEYSY/hXGBQABaAEG bygAAgAAACkAAwAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAAC AAAALgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAUA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhNACEYQw/RXGBQAB0AIGbygAAgAAAC4AAQAAAAAE AQMAAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAAEAAAALgABAC4AAQAAAAAE AQMFAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAAGAAAALgABAC4AAgAuAAEA AAAABAEDBQcAAAAAAAAAAAAAAAAAAAMQAAAPhDgEEYTI+xXGBQABOAQGbygACAAAAC4AAQAuAAIA LgADAC4AAQAAAAAEAQMFBwkAAAAAAAAAAAAAAAAAAxAAAA+EoAURhGD6FcYFAAGgBQZvKAAKAAAA LgABAC4AAgAuAAMALgAEAC4AAQAAAAAEAQMFBwkLAAAAAAAAAAAAAAAAAxAAAA+EoAURhGD6FcYF AAGgBQZvKAAMAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAEAAAAABAEDBQcJCw0AAAAAAAAAAAAA AAMQAAAPhAgHEYT4+BXGBQABCAcGbygADgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4AAQAA AAAEAQMFBwkLDQ8AAAAAAAAAAAAAAxAAAA+EcAgRhJD3FcYFAAFwCAZvKAAQAAAALgABAC4AAgAu AAMALgAEAC4ABQAuAAYALgAHAC4AAQAAAAAEAQMFBwkLDQ8RAAAAAAAAAAAAAxAAAA+EcAgRhJD3 FcYFAAFwCAZvKAASAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAAuAAMAAAAAAAEA AAAAAAAAAAAAAAAAAAAAAAMQAAAPhGgBEYSY/hXGBQABaAEGbygAAgAAAC4AAwAAAAAAAQAAAAAA AAAAAAAAAAAAAAAAAxAAAA+EWAIRhKj9FcYFAAFYAgZvKAACAAAALgABAAAAAAABAAAAAAAAAAAA AAAAAAAAAAADEAAAD4QYAxGEmP4VxgUAARgDBm8oAAIAAAApAAEAAAAXAAAAAAAAAAAAAAAAAAAA AAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAA AAAAAAAAAxAAAA+EYAMRhFD+FcYFAAFgAwZvKAACAAAAKQADAAAAAAABAAAAAAAAAAAAAAAAAAAA AAADEAAAD4RjAxGETf4VxgUAAWMDBm8oAAEAAAAJAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAA D4RoARGEmP4VxgUAAWgBBm8oAAIAAAAuAAYAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhFgC EYSo/RXGBQABWAIGbygAAgAAAC4ACgAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9 FcYFAAHQAgZvKAACAAAALgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUA AWgBBgIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAA AC4AEQAAAKNMhCIAAAAAAAAAAAAAAAD6LeVQAAAAAAAAAAAAAAAA8w5BTAAAAAAAAAAAAAAAADcv D3AAAAAAAAAAAAAAAADZFjQrAAAAAAAAAAAAAAAAtWlpRgAAAAAAAAAAAAAAAAdCyzMAAAAAAAAA AAAAAADXfzoKAAAAAAAAAAAAAAAAvA/bDgAAAAAAAAAAAAAAAP53+3kAAAAAAAAAAAAAAABHHNJV AAAAAAAAAAAAAAAAsRsYTwAAAAAAAAAAAAAAAPR4/HoAAAAAAAAAAAAAAABjISozAAAAAAAAAAAA AAAA3AfVegAAAAAAAAAAAAAAAOgL7FwAAAAAAAAAAAAAAAAmQo5aAAAAAAAAAAAAAAAA//////// //////////////////////////////////////////////////////////////////////////// /////////xEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/0ABgAEArAAAAKwA AAB4bWQAAQABAKwAAAAAAAAAqwAAAAAAAAABCAAARhUAMEoKAAEGADUIgEIqAAEGAAwqADUIgAEL AABGFQAMKgAwSgoAAQYANQiBNgiBAQQAD4QAAAIgCAAAAAAAAAEAAAAKAAAAGgAAACQAAAAlAAAA UwAAAF0AAABeAAAAdgAAAHcAAAB6AAAAlQAAAKsAAACsAAAArQAAAFoBAABbAQAAXAEAAM0FAAD2 BQAAGQgAAPkJAAD6CQAA/wkAAEgKAABJCgAASgoAAGMKAABrCgAAcAoAAHgKAACACgAAhw4AAIgO AACNDgAAnQ4AANAOAADWDgAAPQ8AAF0PAAAVEgAACBMAAJITAAD+FAAADxUAABAVAAARFQAAJhUA ACYWAACsGQAArRkAAK4ZAACvGQAAsBkAALEZAACyGQAAsxkAABQaAAAVGgAAUBoAAFEaAABUGgAA VRoAAJ4aAAC9GgAAvhoAAL8aAADAGgAAwhoAAGIbAABjGwAAZBsAAGobAABrGwAAeBsAAHkbAAB/ GwAAgBsAAK4bAACvGwAAsRsAAL8bAADAGwAAwRsAAMIbAADIGwAAyRsAANYbAADXGwAA3hsAAN8b AADgGwAAShwAAE0cAABbHAAAXBwAAF0cAABeHAAAZBwAAGUcAAByHAAAcxwAAHgcAAB5HAAAehwA ALIcAADRHAAA1BwAAOAcAADhHAAA4hwAAOMcAAB8HQAAmx0AAJwdAACdHQAAnh0AAKEdAACmHQAA qx0AALkdAAC6HQAAux0AAOEdAADiHQAA8x0AAPsdAAD8HQAA/R0AAP4dAABnHgAAaB4AAGkeAABq HgAAwR4AAMIeAADDHgAAxB4AAAMfAAAEHwAAPh8AAD8fAABAHwAAQR8AAKgfAACpHwAAqh8AAKsf AADBHwAA7h8AAO8fAAAQIAAAESAAABIgAAATIAAAFSAAABYgAAAcIAAAHSAAACogAAArIAAAMSAA ADggAAA5IAAAOiAAAFEgAABmIAAAZyAAAGkgAABxIAAAcyAAAHQgAAB1IAAAMAAACABAAAAwAAII AECaADAAFAgAQAAAMAA0CABAmgAwAEgIAEAAADAASggAQJoAMACmCABAmgAwALoIAEAAADAAvAgA QJoAMADsCABAmgAwAO4IAEAAADEA9AgAQJoAMAAqCQBAAAAwAAB+AAAAADAAVgkAQAEAMQACfgAA AAAwAFx/AAAAADAAWAkAQAAAMADmCgBAAAAxAMgTAEADADAAGhQAQAAAMABgGABABQAwACAcAECq gDAAIhwAQAAAMQAsHABAmgAwAABuAAAAADAAvhwAQAcAMQDAHABAAAAxAAJuAAAAADEAEm4AAAAA MQDyHABAAAAxABxuAAAAADAAAh0AQAAAMAAQJQBAmgAwABIlAEAAADAAHCUAQJoAMQA8JQBAAAAx AKIlAEAJADAAriUAQAAAMQAsbgAAAAAwALwmAEAAADAALCwAQJoAMAASLgBAAAAwACYvAECaADAA /jEAQAAAMAAiMgBAAAAwACwyAEALADAALjIAQAAAMABYMgBAmgAwAFg0AEAAADAAjD0AQAAAMABm OwBAAAAwAF5/AAAAADAAajsAQAAAMABgfwAAAAAwAG47AEAAADAAYn8AAAAAMAByOwBAAAAxAGR/ AAAAADAANjwAQAAAMQBmfwAAAAAwAK48AEAAADAAaH8AAAAAMQB4bgAAAAAxAApvAAAAADAASG8A AAAAMABKbwAAAAAxAExvAAAAADEATm8AAAAAMQBSbwAAAAAwAJJwAAAAADAAlHAAAAAAMQCWcAAA AAAxAKJwAAAAADEApHAAAAAAMQC+cAAAAAAxAMBwAAAAADEAzHAAAAAAMQDOcAAAAACAmEAAABUA AAAAAAAAAIAAAACAmEARIBUAAQAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEAAABUAAAAA AAAAAIAAAACAmEARIBUAAgAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEAAABUAAAAAAAAA AIAAAACAmEARIBUAAwAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAA AACAmEARIBUABAAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACA mEARIBUABQAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEAR IBUABgAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEARIBUA BwAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEARIBUACAAA AAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEARIBUACQAAAAAA AIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEAAABUAAAAAAAAAAIAAAACAmEAAABcAAAAAAAAAAIAA AACAmEAAABcAAAAAAAAAAIAAAACACgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIA AAAEAAAABgAAAAYAAAAwAAAAMAAAAGsAAABrAAAApwAAAKcAAACnAAAApwAAAKcAAACnAAAApwAA AKoAAAAABAAArx0AALKFAAAcAAAAJAAAAAAEAAAJCAAAeg8AABIWAACvGQAAWx4AAPxTAAAkXwAA yGcAAMp1AABegQAAsoUAAB0AAAAfAAAAIAAAACEAAAAjAAAAJQAAAC0AAAA1AAAANgAAAD4AAABB AAAAAAQAABIZAADHHgAAHgAAACIAAAD//wwAAAAHAFUAbgBrAG4AbwB3AG4ADQBQAGEAdQBsACAA RQAuACAASgBvAG4AZQBzAAwATQBhAHIAawBrAHUAIABLAG8AcgBwAGkACgBSAGkAYwBoACAAQgBv AHcAZQBuAAwAUABlAHQAZQAgAEMAbwByAGQAZQBsAGwACgBPAHIAaQB0ACAATABlAHYAaQBuAAYA ZgBvAG8AYgBhAHIACABKAGkAbQAgAFQAbwBnAGEACgBKAGEAbQBlAHMAIABUAG8AZwBhAAsAUgBp AGMAawAgAEIAbwBpAHYAaQBlAA0ATgBhAG4AYwB5ACAARgBlAGwAZABtAGEAbgANAEUAcwBwAGUA bgAgAFMAawBqAOYAcgBhAG4A3QUAAPsFAAAFBgAAghkAAKsZAACsGQAAdiAAABNYFP8VhBNYFP8V jF8AAABmAAAAaAAAAJsAAACiAAAApAAAAKoAAAATIfT/lYATIfT/lYAPAADwOAAAAAAABvAYAAAA AggAAAIAAAABAAAAAQAAAAEAAAACAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAA8AAvCSAAAA EAAI8AgAAAABAAAAAQQAAA8AA/AwAAAADwAE8CgAAAABAAnwEAAAAAAAAAAAAAAAAAAAAAAAAAAC AArwCAAAAAAEAAAFAAAADwAE8EIAAAASAArwCAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAA AAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAAAAEAAAD//wEAAAAGAGMAMQB0AGkAdABlAAQcAAB3 IAAAAAAAAAQcAAB3IAAAAAAAAGEBAABoAQAAnAIAAKUCAAD8BQAABQYAAAsLAAATCwAAnQsAAKUL AADHCwAAzwsAAKEQAACpEAAANxEAAD8RAAAdFwAAKhcAAK4ZAACuGQAArxkAAK8ZAACwGQAAsBkA ALEZAACyGQAAsxkAALQZAABVGgAAVhoAAFkaAABgGgAAfBoAAIAaAADTGgAA2hoAAOYbAADwGwAA DBwAABkcAADnHAAA7hwAAPMcAAD+HAAAAx0AAAsdAAAUHQAAHR0AAK8dAADIHQAA/x0AAAYeAAAQ HgAAGB4AACQeAAAsHgAAeB4AAIAeAACMHgAAlB4AAMUeAADMHgAA6h4AAPIeAACvHwAAtB8AAHcg AAAHAAQABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHAAQABwAEAAIABAAHAAQABwAE AAcAAgAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHAAAAAAB8AQAAfwEAAEUCAABIAgAAaggAAG8IAAATCgAAGQoA AI4LAACUCwAAxwsAAM8LAADkCwAA6AsAABUMAAAdDAAASAwAAFMMAACIDAAAkAwAADsNAAA+DQAA Tw0AAFYNAACNDQAAkw0AAL4NAADCDQAA0A0AANoNAADuDQAA9g0AAAkOAAANDgAAaQ4AAHAOAABZ FQAAaRUAABIWAAAkFgAAgxYAAAYYAAAHGAAArRkAAK4ZAACuGQAArxkAAK8ZAACwGQAAsBkAALEZ AACyGQAAsxkAALQZAABVGgAAVhoAAHcgAAAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAa AAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoA BwAEAAcABAACAAQABwAEAAcABAAHAAIABwD//xQAAAAKAE8AcgBpAHQAIABMAGUAdgBpAG4ANABD ADoAXABTAHQAYQBuAGQAYQByAGQAcwBcAEkARQBUAEYAXABkAHIAYQBmAHQALQBsAGUAdgBpAG4A LQBoADMAMgAzAC0AdQByAGwALQBzAGMAaABlAG0AZQAtADAAMAAuAGQAbwBjAAoATwByAGkAdAAg AEwAZQB2AGkAbgA0AEMAOgBcAFMAdABhAG4AZABhAHIAZABzAFwASQBFAFQARgBcAGQAcgBhAGYA dAAtAGwAZQB2AGkAbgAtAGgAMwAyADMALQB1AHIAbAAtAHMAYwBoAGUAbQBlAC0AMAAwAC4AZABv AGMACgBPAHIAaQB0ACAATABlAHYAaQBuADQAQwA6AFwAUwB0AGEAbgBkAGEAcgBkAHMAXABJAEUA VABGAFwAZAByAGEAZgB0AC0AbABlAHYAaQBuAC0AaAAzADIAMwAtAHUAcgBsAC0AcwBjAGgAZQBt AGUALQAwADAALgBkAG8AYwAKAE8AcgBpAHQAIABMAGUAdgBpAG4ARwBDADoAXAB3AGkAbgBkAG8A dwBzAFwAVABFAE0AUABcAEEAdQB0AG8AUgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAg AGQAcgBhAGYAdAAtAGwAZQB2AGkAbgAtAGgAMwAyADMALQB1AHIAbAAtAHMAYwBoAGUAbQBlAC0A MAAwAC4AYQBzAGQACgBPAHIAaQB0ACAATABlAHYAaQBuADQAQwA6AFwAUwB0AGEAbgBkAGEAcgBk AHMAXABJAEUAVABGAFwAZAByAGEAZgB0AC0AbABlAHYAaQBuAC0AaAAzADIAMwAtAHUAcgBsAC0A cwBjAGgAZQBtAGUALQAwADAALgBkAG8AYwAKAE8AcgBpAHQAIABMAGUAdgBpAG4ANQBDADoAXABT AHQAYQBuAGQAYQByAGQAcwBcAEkARQBUAEYAXABkAGQAcgBhAGYAdAAtAGwAZQB2AGkAbgAtAGgA MwAyADMALQB1AHIAbAAtAHMAYwBoAGUAbQBlAC0AMAAwAC4AZABvAGMACgBPAHIAaQB0ACAATABl AHYAaQBuADUAQwA6AFwAUwB0AGEAbgBkAGEAcgBkAHMAXABJAEUAVABGAFwAZABkAHIAYQBmAHQA LQBsAGUAdgBpAG4ALQBoADMAMgAzAC0AdQByAGwALQBzAGMAaABlAG0BAAAA/v///wMAAAAEAAAA BQAAAAYAAAAHAAAACAAAAAkAAAAKAAAACwAAAAwAAAANAAAA/v///w8AAAAQAAAAEQAAABIAAAAT AAAAFAAAABUAAAD+//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////wBlAC0AMAAwAC4AZABvAGMA CgBPAHIAaQB0ACAATABlAHYAaQBuADUAQwA6AFwAUwB0AGEAbgBkAGEAcgBkAHMAXABJAEUAVABG AFwAZABkAHIAYQBmAHQALQBsAGUAdgBpAG4ALQBoADMAMgAzAC0AdQByAGwALQBzAGMAaABlAG0A ZQAtADAAMAAuAGQAbwBjAAoATwByAGkAdAAgAEwAZQB2AGkAbgBIAEMAOgBcAHcAaQBuAGQAbwB3 AHMAXABUAEUATQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAA ZABkAHIAYQBmAHQALQBsAGUAdgBpAG4ALQBoADMAMgAzAC0AdQByAGwALQBzAGMAaABlAG0AZQAt ADAAMAAuAGEAcwBkAAoATwByAGkAdAAgAEwAZQB2AGkAbgA1AEMAOgBcAFMAdABhAG4AZABhAHIA ZABzAFwASQBFAFQARgBcAGQAZAByAGEAZgB0AC0AbABlAHYAaQBuAC0AaAAzADIAMwAtAHUAcgBs AC0AcwBjAGgAZQBtAGUALQAwADAALgBkAG8AYwARANd/OgqQY2ZP/w//D/8P/w//D/8P/w//D/8P AAC8D9sOlhFcrf8P/w//D/8P/w//D/8P/w//DwAAo0yEIhcACQT/D/8P/w//D/8P/w//D/8P/w8B ANkWNCsPAAkE/w//D/8P/w//D/8P/w//D/8PAQBjISozDwAJBP8PAAAAAAAAAAAAAAAAAAAAAAEA B0LLM5q/mEH/D/8P/w//D/8P/w//D/8P/w8AALVpaUYPAAkE/w//D/8P/w//D/8P/w//D/8PAQDz DkFMnnDWaP8P/w//D/8P/w//D/8P/w//DwEAsRsYT/IsxDv/D/8P/w//D/8P/w//D/8P/w8BAPot 5VABAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQBHHNJVrP6o/v8P/w//D/8P/w//D/8P/w//DwEAJkKO WmS1Yrf/D/8P/w//D/8P/w//D/8P/w8BAOgL7FwPAAkE/w//D/8P/w//D/8P/w//D/8PAQA3Lw9w RBmMJv8P/w//D/8P/w//D/8P/w//DwEA/nf7ecJ7zlb/D/8P/w//D/8P/w//D/8P/w8BANwH1XoP AAkE/w8AAAAAAAAAAAAAAAAAAAAAAQD0ePx6DwAJBP8PAAAAAAAAAAAAAAAAAAAAAAEABQAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAABAAAAAQAAAAAAAQMAAAAA AAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAADAAAALgABAAEAAAAAAAEDBQAAAAAA AAAAAAAAAAAAAAMQAAAPhNACEYQw/RXGBQAB0AIGbygABQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAA AAAAAAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYFAAE4BAZvKAAHAAAALgABAC4AAgAuAAMAAQAAAAAA AQMFBwkAAAAAAAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYFAAE4BAZvKAAJAAAALgABAC4AAgAuAAMA LgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAMQAAAPhKAFEYRg+hXGBQABoAUGbygACwAAAC4A AQAuAAIALgADAC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAAxAAAA+ECAcRhPj4FcYF AAEIBwZvKAANAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAA AAAAAxAAAA+ECAcRhPj4FcYFAAEIBwZvKAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAH AAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMQAAAPhHAIEYSQ9xXGBQABcAgGbygAEQAAAC4AAQAu AAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgABAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAEABQAA AAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAABAAAAAQAAAAAAAQMA AAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAADAAAALgABAAEAAAAAAAEDBQAA AAAAAAAAAAAAAAAAAAMQAAAPhNACEYQw/RXGBQAB0AIGbygABQAAAC4AAQAuAAIAAQAAAAAAAQMF BwAAAAAAAAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYFAAE4BAZvKAAHAAAALgABAC4AAgAuAAMAAQAA AAAAAQMFBwkAAAAAAAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYFAAE4BAZvKAAJAAAALgABAC4AAgAu AAMALgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAMQAAAPhKAFEYRg+hXGBQABoAUGbygACwAA AC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAAxAAAA+ECAcRhPj4 FcYFAAEIBwZvKAANAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAA AAAAAAAAAxAAAA+ECAcRhPj4FcYFAAEIBwZvKAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYA LgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMQAAAPhHAIEYSQ9xXGBQABcAgGbygAEQAAAC4A AQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgABAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAA AA+EaAERhJj+FcYFAAFoAQZvKAACAAAALgABAAAAAAQBAwAAAAAAAAAAAAAAAAAAAAADEAAAD4TQ AhGEMP0VxgUAAdACBm8oAAQAAAAuAAEALgABAAAAAAQBAwUAAAAAAAAAAAAAAAAAAAADEAAAD4TQ AhGEMP0VxgUAAdACBm8oAAYAAAAuAAEALgACAC4AAQAAAAAEAQMFBwAAAAAAAAAAAAAAAAAAAxAA AA+EOAQRhMj7FcYFAAE4BAZvKAAIAAAALgABAC4AAgAuAAMALgABAAAAAAQBAwUHCQAAAAAAAAAA AAAAAAADEAAAD4SgBRGEYPoVxgUAAaAFBm8oAAoAAAAuAAEALgACAC4AAwAuAAQALgABAAAAAAQB AwUHCQsAAAAAAAAAAAAAAAADEAAAD4SgBRGEYPoVxgUAAaAFBm8oAAwAAAAuAAEALgACAC4AAwAu AAQALgAFAC4AAQAAAAAEAQMFBwkLDQAAAAAAAAAAAAAAAxAAAA+ECAcRhPj4FcYFAAEIBwZvKAAO AAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgABAAAAAAQBAwUHCQsNDwAAAAAAAAAAAAADEAAA D4RwCBGEkPcVxgUAAXAIBm8oABAAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAA AAQBAwUHCQsNDxEAAAAAAAAAAAADEAAAD4RwCBGEkPcVxgUAAXAIBm8oABIAAAAuAAEALgACAC4A AwAuAAQALgAFAC4ABgAuAAcALgAIAC4AAQAAAAQAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAER hJj+FcYFAAFoAQZvKAACAAAAKQADAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4V xgUAAWgBBm8oAAIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQAB aAEGAgAAAC4ABQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAAC AAAALgABAAAAAAQBAwAAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAQAAAAu AAEALgABAAAAAAQBAwUAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAYAAAAu AAEALgACAC4AAQAAAAAEAQMFBwAAAAAAAAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYFAAE4BAZvKAAI AAAALgABAC4AAgAuAAMALgABAAAAAAQBAwUHCQAAAAAAAAAAAAAAAAADEAAAD4SgBRGEYPoVxgUA AaAFBm8oAAoAAAAuAAEALgACAC4AAwAuAAQALgABAAAAAAQBAwUHCQsAAAAAAAAAAAAAAAADEAAA D4SgBRGEYPoVxgUAAaAFBm8oAAwAAAAuAAEALgACAC4AAwAuAAQALgAFAC4AAQAAAAAEAQMFBwkL DQAAAAAAAAAAAAAAAxAAAA+ECAcRhPj4FcYFAAEIBwZvKAAOAAAALgABAC4AAgAuAAMALgAEAC4A BQAuAAYALgABAAAAAAQBAwUHCQsNDwAAAAAAAAAAAAADEAAAD4RwCBGEkPcVxgUAAXAIBm8oABAA AAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAAAAQBAwUHCQsNDxEAAAAAAAAAAAAD EAAAD4RwCBGEkPcVxgUAAXAIBm8oABIAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAI AC4AAwAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAACAAAALgAD AAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RYAhGEqP0VxgUAAVgCBm8oAAIAAAAuAAEAAAAA AAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhBgDEYSY/hXGBQABGAMGbygAAgAAACkAAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAAB AAAAAAAAAAAAAAAAAAAAAAADEAAAD4RgAxGEUP4VxgUAAWADBm8oAAIAAAApAAMAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAMQAAAPhGMDEYRN/hXGBQABYwMGbygAAQAAAAkAAAAAAAEAAAAAAAAAAAAA AAAAAAAAAAMQAAAPhGgBEYSY/hXGBQABaAEGbygAAgAAAC4ABgAAAAAAAQAAAAAAAAAAAAAAAAAA AAAAAxAAAA+EWAIRhKj9FcYFAAFYAgZvKAACAAAALgAKAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAD EAAAD4TQAhGEMP0VxgUAAdACBm8oAAIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAP hGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+ FcYFAAFoAQYCAAAALgARAAAAo0yEIgAAAAAAAAAAAAAAAPot5VAAAAAAAAAAAAAAAADzDkFMAAAA AAAAAAAAAAAANy8PcAAAAAAAAAAAAAAAANkWNCsAAAAAAAAAAAAAAAC1aWlGAAAAAAAAAAAAAAAA B0LLMwAAAAAAAAAAAAAAANd/OgoAAAAAAAAAAAAAAAC8D9sOAAAAAAAAAAAAAAAA/nf7eQAAAAAA AAAAAAAAAEcc0lUAAAAAAAAAAAAAAACxGxhPAAAAAAAAAAAAAAAA9Hj8egAAAAAAAAAAAAAAAGMh KjMAAAAAAAAAAAAAAADcB9V6AAAAAAAAAAAAAAAA6AvsXAAAAAAAAAAAAAAAACZCjloAAAAAAAAA AAAAAAD///////////////////////////////////////////////////////////////////// ////////////////////////EQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ QAOAAQA8BwAAPAcAADRN7wABAAEAPAcAAAAAAAA8BwAAAAAAAALsBQAAAAAAAD4PAABeDwAAshkA ALMZAAC0GQAAtRkAALYZAAC3GQAAuBkAALkZAAAaGgAAGxoAAFYaAABXGgAAWhoAAFsaAACkGgAA wxoAAMQaAADFGgAAxhoAAMgaAABoGwAAaRsAAGobAABwGwAAcRsAAH4bAAB/GwAAhRsAAIYbAAC0 GwAAtRsAALcbAADFGwAAxhsAAMcbAADIGwAAzhsAAM8bAADcGwAA3RsAAOQbAADlGwAA5hsAAFAc AABTHAAAYRwAAGIcAABjHAAAZBwAAGocAABrHAAAeBwAAHkcAAB+HAAAfxwAAIAcAAC4HAAA1xwA ANocAADmHAAA5xwAAOgcAADpHAAAgh0AAKEdAACiHQAAox0AAKQdAACnHQAArB0AALEdAAC/HQAA wB0AAMEdAADnHQAA6B0AAPkdAAABHgAAAh4AAAMeAAAEHgAAbR4AAG4eAABvHgAAcB4AAMceAADI HgAAyR4AAMoeAAAJHwAACh8AAEQfAABFHwAARh8AAEcfAACuHwAArx8AALAfAACxHwAAxx8AAPQf AAD1HwAAFiAAABcgAAAYIAAAGSAAABsgAAAcIAAAIiAAACMgAAAwIAAAMSAAADcgAAA+IAAAPyAA AEAgAABXIAAAbCAAAG0gAABvIAAAdyAAAHkgAAB6IAAAeyAAAHAAAAgAQAAAcQAAXAAAAABwALwm AEAAAHAAjD0AQAAAcABmOwBAAABwAEBcAAAAAHAAajsAQAAAcABCXAAAAABwAG47AEAAAHAARFwA AAAAcAByOwBAAABxAEZcAAAAAHAANjwAQAAAcQBIXAAAAABwAK48AEAAAHAASlwAAAAAcQBMXAAA AABxAN5cAAAAAHAAHF0AAAAAcAAeXQAAAABxACBdAAAAAHEAIl0AAAAAcQAmXQAAAABwAGZeAAAA AHAAaF4AAAAAcQBqXgAAAABxAHZeAAAAAHEAeF4AAAAAcQCSXgAAAABxAJReAAAAAHEAoF4AAAAA cQCiXgAAAABxAP5eAAAAAHEAAF8AAAAAcQAEXwAAAABwACBfAAAAAHAAIl8AAAAAcAAkXwAAAABx ACZfAAAAAHEAMl8AAAAAcQA0XwAAAABxAE5fAAAAAHEAUF8AAAAAcQBeXwAAAABxAGBfAAAAAHEA Yl8AAAAAcQA2YAAAAABxADxgAAAAAHAAWGAAAAAAcABaYAAAAABwAFxgAAAAAHEAXmAAAAAAcQBq YAAAAABxAGxgAAAAAHEAhmAAAAAAcQCIYAAAAABxAJJgAAAAAHEAlGAAAAAAcQCWYAAAAABxAAZh AAAAAHEARGEAAAAAcQBKYQAAAABwAGJhAAAAAHAAZGEAAAAAcABmYQAAAABxAGhhAAAAAHEAmmIA AAAAcADYYgAAAABwANpiAAAAAHAA3GIAAAAAcQDeYgAAAABxAORiAAAAAHEA7mIAAAAAcQD4YgAA AABxABRjAAAAAHEAFmMAAAAAcQAYYwAAAABxAGRjAAAAAHEAZmMAAAAAcQCIYwAAAABwAJhjAAAA AHAAmmMAAAAAcACcYwAAAABxAJ5jAAAAAHAAcGQAAAAAcAByZAAAAABwAHRkAAAAAHEAdmQAAAAA cAAkZQAAAABwACZlAAAAAHAAKGUAAAAAcQAqZQAAAABxAKhlAAAAAHEAqmUAAAAAcAAeZgAAAABw ACBmAAAAAHAAImYAAAAAcQAkZgAAAABwAPJmAAAAAHAA9GYAAAAAcAD2ZgAAAABxAPhmAAAAAHEA JGcAAAAAcQB+ZwAAAABxAIBnAAAAAHAAwmcAAAAAcADEZwAAAABwAMZnAAAAAHEAyGcAAAAAcQDM ZwAAAABxAM5nAAAAAHEA2mcAAAAAcQDcZwAAAABxAPZnAAAAAHEA+GcAAAAAcQAEaAAAAABxABJo AAAAAHEAFGgAAAAAcQAWaAAAAABxAERoAAAAAHEAbmgAAAAAcQBwaAAAAABxAHRoAAAAAHAAhj0A QAAAcACEaAAAAABwAIw9AEAAAAUAAABHFpABAAACAgYDBQQFAgMEAwAAAAAAAAAAAAAAAAAAAAEA AAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcGAgUHAAAA AAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIEAwAAAAAA AAAAAAAAAAAAAAEAAAAAAAAAQQByAGkAYQBsAAAAPzWQAQAAAgcDCQICBQIEBAMAAAAAAAAAAAAA AAAAAAABAAAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAAADUmkAEAAAILBgQDBQQEAgSHOgAA AAAAAAAAAAAAAAAA/wAAAAAAAABUAGEAaABvAG0AYQAAACIABAAxCIgYAACABAAAaAEAAAAAuUtH BsBLRwZPPEemBAACAAAAtwMAADAVAAABAAoAAAAEAIAQLQAAAAAAAAAAAAAAAQABAAAAAQAAAAAA AACRIwAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQBUAGgAaQBzACAAZABvAGMAdQBtAGUAbgB0ACAA aQBzACAAYQBuACAASQBuAHQAZQByAG4AZQB0AC0ARAByAGEAZgB0ACAAYQBuAGQAIABpAHMAIABp AG4AIABmAHUAbABsACAAYwBvAG4AZgBvAHIAbQBhAG4AYwBlACAAdwBpAHQAaAAgAGEAbABsACAA cAByAG8AdgBpAHMAaQBvAG4AcwAgAG8AZgAgAFMAZQBjAHQAaQBvAG4AIAAxADAAIABvAGYAIABS AEYAQwAyADAAMgA2ACAAZQB4AGMAZQBwAHQAIAB0AGgAYQB0ACAAdABoAGUAIAByAGkAZwBoAHQA IAB0AG8AIABwAHIAbwBkAHUAYwBlACAAZABlAHIAaQB2AGEAdABpAHYAZQAgAHcAbwByAGsAcwAg AGkAcwAgAG4AbwB0ACAAZwByAGEAbgB0AGUAZAAuACAADQANAA0ADQAzADEADQANAA0AAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAxACpxAAAAADEALHEAAAAAMQAwcQAAAAAwAExx AAAAADAATnEAAAAAMABQcQAAAAAxAFJxAAAAADEAXnEAAAAAMQBgcQAAAAAxAHpxAAAAADEAfHEA AAAAMQCKcQAAAAAxAIxxAAAAADEAjnEAAAAAMQBicgAAAAAxAGhyAAAAADAAhHIAAAAAMACGcgAA AAAwAIhyAAAAADEAinIAAAAAMQCWcgAAAAAxAJhyAAAAADEAsnIAAAAAMQC0cgAAAAAxAL5yAAAA ADEAwHIAAAAAMQDCcgAAAAAxADJzAAAAADEAcHMAAAAAMQB2cwAAAAAwAI5zAAAAADAAkHMAAAAA MACScwAAAAAxAJRzAAAAADEAxnQAAAAAMAAEdQAAAAAwAAZ1AAAAADAACHUAAAAAMQAKdQAAAAAx ABB1AAAAADEAGnUAAAAAMQAkdQAAAAAxAEB1AAAAADEAQnUAAAAAMQBEdQAAAAAxAJB1AAAAADEA knUAAAAAMQC0dQAAAAAwAMR1AAAAADAAxnUAAAAAMADIdQAAAAAxAMp1AAAAADAAnHYAAAAAMACe dgAAAAAwAKB2AAAAADEAonYAAAAAMABQdwAAAAAwAFJ3AAAAADAAVHcAAAAAMQBWdwAAAAAxANR3 AAAAADEA1ncAAAAAMABKeAAAAAAwAEx4AAAAADAATngAAAAAMQBQeAAAAAAwAB55AAAAADAAIHkA AAAAMAAieQAAAAAxACR5AAAAADEAUHkAAAAAMQCqeQAAAAAxAKx5AAAAADAA7nkAAAAAMADweQAA AAAwAPJ5AAAAADEA9HkAAAAAMQD4eQAAAAAxAPp5AAAAADEABnoAAAAAMQAIegAAAAAxACJ6AAAA ADEAJHoAAAAAMQAwegAAAAAxAD56AAAAADEAQHoAAAAAMQBCegAAAAAxAHB6AAAAADEAmnoAAAAA MQCcegAAAAAxAKB6AAAAADAAhj0AQAAAMABqfwAAAAAwAIw9AEAAAAUAAABHFpABAAACAgYDBQQF AgMEAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4A AAA1FpABAgAFBQECAQcGAgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAz JpABAAACCwYEAgICAgIEAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAQQByAGkAYQBsAAAAPzWQAQAA AgcDCQICBQIEBAMAAAAAAAAAAAAAAAAAAAABAAAAAAAAAEMAbwB1AHIAaQBlAHIAIABOAGUAdwAA ADUmkAEAAAILBgQDBQQEAgSHOgAAAAAAAAAAAAAAAAAA/wAAAAAAAABUAGEAaABvAG0AYQAAACIA BAAxCIgYAACABAAAaAEAAAAAuUtHBhNMRwZPPEemBgAMAAAAtgMAACwVAAABAAoAAAAEAIAQLQAA AAAAAAAAAAAAAQABAAAAAQAAAAAAAACRIwAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACl BsAHtAC0AIAAEjQAABAAGQBkAAAAGQAAAAAaAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA//8SAAAAAAAAABUATgBl AHQAdwBvAHIAawAgAFcAbwByAGsAaQBuAGcAIABHAHIAbwB1AHAAAAAAAAAACwBNAGkAawBlACAA RwBhAGgAcgBuAHMACgBPAHIAaQB0ACAATABlAHYAaQBuAAAAAAAAAAAAAAAAAAAAAAAAAAAA//// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////wAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZv KAACAAAALgABAAAAAAQBAwAAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAQA AAAuAAEALgABAAAAAAQBAwUAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAYA AAAuAAEALgACAC4AAQAAAAAEAQMFBwAAAAAAAAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYFAAE4BAZv KAAIAAAALgABAC4AAgAuAAMALgABAAAAAAQBAwUHCQAAAAAAAAAAAAAAAAADEAAAD4SgBRGEYPoV xgUAAaAFBm8oAAoAAAAuAAEALgACAC4AAwAuAAQALgABAAAAAAQBAwUHCQsAAAAAAAAAAAAAAAAD EAAAD4SgBRGEYPoVxgUAAaAFBm8oAAwAAAAuAAEALgACAC4AAwAuAAQALgAFAC4AAQAAAAAEAQMF BwkLDQAAAAAAAAAAAAAAAxAAAA+ECAcRhPj4FcYFAAEIBwZvKAAOAAAALgABAC4AAgAuAAMALgAE AC4ABQAuAAYALgABAAAAAAQBAwUHCQsNDwAAAAAAAAAAAAADEAAAD4RwCBGEkPcVxgUAAXAIBm8o ABAAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAAAAQBAwUHCQsNDxEAAAAAAAAA AAADEAAAD4RwCBGEkPcVxgUAAXAIBm8oABIAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcA LgAIAC4AAQAAAAQAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAACAAAA KQADAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAIAAAAuAAEA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4ABQAAAAAAAQAA AAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAACAAAALgABAAAAAAQBAwAAAAAA AAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAQAAAAuAAEALgABAAAAAAQBAwUAAAAA AAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAYAAAAuAAEALgACAC4AAQAAAAAEAQMF BwAAAAAAAAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYFAAE4BAZvKAAIAAAALgABAC4AAgAuAAMALgAB AAAAAAQBAwUHCQAAAAAAAAAAAAAAAAADEAAAD4SgBRGEYPoVxgUAAaAFBm8oAAoAAAAuAAEALgAC AC4AAwAuAAQALgABAAAAAAQBAwUHCQsAAAAAAAAAAAAAAAADEAAAD4SgBRGEYPoVxgUAAaAFBm8o AAwAAAAuAAEALgACAC4AAwAuAAQALgAFAC4AAQAAAAAEAQMFBwkLDQAAAAAAAAAAAAAAAxAAAA+E CAcRhPj4FcYFAAEIBwZvKAAOAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgABAAAAAAQBAwUH CQsNDwAAAAAAAAAAAAADEAAAD4RwCBGEkPcVxgUAAXAIBm8oABAAAAAuAAEALgACAC4AAwAuAAQA LgAFAC4ABgAuAAcALgABAAAAAAQBAwUHCQsNDxEAAAAAAAAAAAADEAAAD4RwCBGEkPcVxgUAAXAI Bm8oABIAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAC4AAwAAAAAAAQAAAAAAAAAA AAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAACAAAALgADAAAAAAABAAAAAAAAAAAAAAAA AAAAAAADEAAAD4RYAhGEqP0VxgUAAVgCBm8oAAIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAA AAMQAAAPhBgDEYSY/hXGBQABGAMGbygAAgAAACkAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAA AA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAD EAAAD4RgAxGEUP4VxgUAAWADBm8oAAIAAAApAAMAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAP hGMDEYRN/hXGBQABYwMGbygAAQAAAAkAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhGgBEYSY /hXGBQABaAEGbygAAgAAAC4ABgAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EWAIRhKj9FcYF AAFYAgZvKAACAAAALgAKAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdAC Bm8oAAIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAA AC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgARAAAA o0yEIgAAAAAAAAAAAAAAAPot5VAAAAAAAAAAAAAAAADzDkFMAAAAAAAAAAAAAAAANy8PcAAAAAAA AAAAAAAAANkWNCsAAAAAAAAAAAAAAAC1aWlGAAAAAAAAAAAAAAAAB0LLMwAAAAAAAAAAAAAAANd/ OgoAAAAAAAAAAAAAAAC8D9sOAAAAAAAAAAAAAAAA/nf7eQAAAAAAAAAAAAAAAEcc0lUAAAAAAAAA AAAAAACxGxhPAAAAAAAAAAAAAAAA9Hj8egAAAAAAAAAAAAAAAGMhKjMAAAAAAAAAAAAAAADcB9V6 AAAAAAAAAAAAAAAA6AvsXAAAAAAAAAAAAAAAACZCjloAAAAAAAAAAAAAAAD///////////////// //////////////////////////////////////////////////////////////////////////// EQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/QAGAAQBhAQAAYQEAAHhtZAAB AAEAYQEAAAAAAABRAQAAAAAAAAEIAABGFQAwSgoAAQYANQiAQioAAQYADCoANQiAAQsAAEYVAAwq ADBKCgABBgA1CIE2CIEBBAAPhAAAAmgIAAAAAAAAAQAAAAoAAAAaAAAAJAAAACUAAABTAAAAXQAA AF4AAAB2AAAAdwAAAHoAAACVAAAAqwAAAKwAAACtAAAAUQEAAGEBAABqAQAAawEAAGwBAADdBQAA BgYAACkIAAAJCgAACgoAAA8KAAA4CgAASQoAAEoKAABLCgAAZAoAAGwKAABxCgAAeQoAAIEKAADH CwAAhw4AAIgOAACNDgAAnQ4AANAOAADWDgAAPQ8AAF0PAAAVEgAAMhIAADMSAAAJEwAAkxMAAP8U AAAQFQAAERUAABIVAAAnFQAAJxYAAK0ZAACuGQAArxkAALAZAACxGQAAshkAALMZAAC0GQAAFRoA ABYaAABRGgAAUhoAAFUaAABWGgAAnxoAAL4aAAC/GgAAwBoAAMEaAADDGgAAYxsAAGQbAABlGwAA axsAAGwbAAB5GwAAehsAAIAbAACBGwAArxsAALAbAACyGwAAwBsAAMEbAADCGwAAwxsAAMkbAADK GwAA1xsAANgbAADfGwAA4BsAAOEbAABLHAAAThwAAFwcAABdHAAAXhwAAF8cAABlHAAAZhwAAHMc AAB0HAAAeRwAAHocAAB7HAAAsxwAANIcAADVHAAA4RwAAOIcAADjHAAA5BwAAH0dAACcHQAAnR0A AJ4dAACfHQAAoh0AAKcdAACsHQAAuh0AALsdAAC8HQAA4h0AAOMdAAD0HQAA/B0AAP0dAAD+HQAA /x0AAGgeAABpHgAAah4AAGseAADCHgAAwx4AAMQeAADFHgAABB8AAAUfAAA/HwAAQB8AAEEfAABC HwAAqR8AAKofAACrHwAArB8AAMIfAADvHwAA8B8AABEgAAASIAAAEyAAABQgAAAWIAAAFyAAAB0g AAAeIAAAKyAAACwgAAAyIAAAOSAAADogAAA7IAAAUiAAAGcgAABoIAAAaiAAAHIgAAB0IAAAdSAA AHYgAAAwAAAIAEAAADAAAggAQJoAMAAUCABAAAAwADQIAECaADAASAgAQAAAMABKCABAmgAwAKYI AECaADAAuggAQAAAMAC8CABAmgAwAOwIAECaADAA7ggAQAAAMQD0CABAmgAwACoJAEAAADAAAIQA AAAAMABWCQBAAQAxAAKEAAAAADEASoUAAAAAMQBqhQAAAAAwAHyFAAAAADAAWAkAQAAAMADmCgBA AAAxAMgTAEADADAAGhQAQAAAMABgGABABQAwACAcAECqgDAAIhwAQAAAMQAsHABAmgAxAH6FAAAA ADAAAG4AAAAAMAC+HABABwAxAMAcAEAAADEAAm4AAAAAMQASbgAAAAAxAPIcAEAAADEAHG4AAAAA MAACHQBAAAAwAJAfAEAAADAAECUAQJoAMAASJQBAAAAwABwlAECaADEAPCUAQAAAMQCiJQBACQAw AK4lAEAAADEALG4AAAAAMAC8JgBAAAAxACwsAECaADEAoIUAAAAAMABmLABAmgAwABIuAEAAADAA Ji8AQJoAMAD+MQBAAAAwACIyAEAAADAALDIAQAsAMAAuMgBAAAAwAFgyAECaADAAWDQAQAAAMACM PQBAAAAwAGY7AEAAADAAooUAAAAAMABqOwBAAAAwAKSFAAAAADAAbjsAQAAAMACmhQAAAAAwAHI7 AEAAADEAqIUAAAAAMAA2PABAAAAxAKqFAAAAADAArjwAQAAAMACshQAAAAAxAHhuAAAAADEACm8A AAAAMABIbwAAAAAwAEpvAAAAADEATG8AAAAAMQBObwAAAAAxAFJvAAAAADAAknAAAAAAMACUcAAA AAAxAJZwAAAAADEAonAAAAAAMQCkcAAAAAAxAL5wAAAAADEAwHAAAAAAMQDMcAAAAAAxAM5wAAAA ADEAKnEAAAAAMQAscQAAAAAxADBxAAAAADAATHEAAAAAMABOcQAAAAAwAFBxAAAAADEAUnEAAAAA MQBecQAAAAAxAGBxAAAAADEAenEAAAAAMQB8cQAAAAAxAIpxAAAAADEAjHEAAAAAMQCOcQAAAAAx AGJyAAAAADEAaHIAAAAAMACEcgAAAAAwAIZyAAAAADAAiHIAAAAAMQCKcgAAAAAxAJZyAAAAADEA mHIAAAAAMQCycgAAAAAxALRyAAAAADEAvnIAAAAAMQDAcgAAAAAxAMJyAAAAADEAMnMAAAAAMQBw cwAAAAAxAHZzAAAAADAAjnMAAAAAMACQcwAAAAAwAJJzAAAAADEAlHMAAAAAMQDGdAAAAAAwAAR1 AAAAADAABnUAAAAAMAAIdQAAAAAxAAp1AAAAADEAEHUAAAAAMQAadQAAAAAxACR1AAAAADEAQHUA AAAAMQBCdQAAAAAxAER1AAAAADEAkHUAAAAAMQCSdQAAAAAxALR1AAAAADAAxHUAAAAAMADGdQAA AAAwAMh1AAAAADEAynUAAAAAMACcdgAAAAAwAJ52AAAAADAAoHYAAAAAMQCidgAAAAAwAFB3AAAA ADAAUncAAAAAMABUdwAAAAAxAFZ3AAAAADEA1HcAAAAAMQDWdwAAAAAwAEp4AAAAADAATHgAAAAA MABOeAAAAAAxAFB4AAAAADAAHnkAAAAAMAAgeQAAAAAwACJ5AAAAADEAJHkAAAAAMQBQeQAAAAAx AKp5AAAAADEArHkAAAAAMADueQAAAAAwAPB5AAAAADAA8nkAAAAAMQD0eQAAAAAxAPh5AAAAADEA +nkAAAAAMQAGegAAAAAxAAh6AAAAADEAInoAAAAAMQAkegAAAAAxADB6AAAAADEAPnoAAAAAMQBA egAAAAAxAEJ6AAAAADEAcHoAAAAAMQCaegAAAAAxAJx6AAAAADEAoHoAAAAAMACGPQBAAAAwAK6F AAAAADAAjD0AQAAABQAAAEcWkAEAAAICBgMFBAUCAwQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABU AGkAbQBlAHMAIABOAGUAdwAgAFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAA AAAAAAAAAAAAgAAAAABTAHkAbQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgQDAAAAAAAAAAAAAAAA AAAAAQAAAAAAAABBAHIAaQBhAGwAAAA/NZABAAACBwMJAgIFAgQEAwAAAAAAAAAAAAAAAAAAAAEA AAAAAAAAQwBvAHUAcgBpAGUAcgAgAE4AZQB3AAAANSaQAQAAAgsGBAMFBAQCBIc6AAAAAAAAAAAA AAAAAAD/AAAAAAAAAFQAYQBoAG8AbQBhAAAAIgAEADEIiBgAAIAEAABoAQAAAAC5S0cGF0xHBk88 R6YJAA4AAAC2AwAALBUAAAEACgAAAAQAgBAtAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAAJEjAAAA BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKUGwAe0ALQAgAASNAAAEAAZAGQAAAAZAAAAABoA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAD//xIAAAAAAAAAFQBOAGUAdAB3AG8AcgBrACAAVwBvAHIAawBpAG4AZwAg AEcAcgBvAHUAcAAAAAAAAAALAE0AaQBrAGUAIABHAGEAaAByAG4AcwAKAE8AcgBpAHQAIABMAGUA dgBpAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAfAADBHwAAwh8AANgfAAAFIAAABiAAACcgAAAoIAAA KSAAACogAAAsIAAALSAAADMgAAA0IAAAQSAAAEIgAABIIAAATyAAAFAgAABRIAAAaCAAAH0gAAB+ IAAAgCAAAIggAADspcEARwAJBAAAbBK/AAAAAAAAEAAAAAAABAAAxx4AAA4AYmpiao7ZjtkAAAAA AAAAAAAAAAAAAAAAAAAJBBYAAIYAAOyzAQDsswEArhkAAAAAAACoAAAAAAAAAAAAAAAfBgAAAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAAAA AAAAAAAA3AMAANwDAAAAAAAA3AMAAAAAAADyAwAAAAAAAPIDAAAAAAAA8gMAACQAAAAAAAAAAAAA ABYEAAAAAAAAMhIAAAAAAAAyEgAAAAAAADISAABQAAAAghIAABQAAACWEgAAXAAAABYEAAAAAAAA /zMAACwBAAAeFAAAKAAAAEYUAAAoAAAAbhQAAAAAAABuFAAAAAAAAG4UAAAAAAAASRUAABQAAABd FQAADAAAAGkVAAAIAAAAMSsAAAIAAAAzKwAAAAAAADMrAAAAAAAAMysAAAAAAAAzKwAAAAAAADMr AAAAAAAAMysAACQAAAArNQAA9AEAAB83AAB+AAAAVysAAKgIAAAAAAAAAAAAAAAAAAAAAAAA8gMA AAAAAABxFQAAAAAAAAAAAAAAAAAAAAAAAAAAAABJFQAAAAAAAEkVAAAAAAAAcRUAAAAAAABxFQAA AAAAAFcrAAAAAAAAYRgAAAAAAADcAwAACgAAAOYDAAAMAAAAbhQAAAAAAAAAAAAAAAAAAG4UAADb AAAABhMAABgBAABhGAAAAAAAAGEYAAAAAAAAYRgAAAAAAABxFQAAlgEAAPIDAAAAAAAAbhQAAAAA AADyAwAAAAAAAG4UAAAAAAAAMSsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFgQAAAAAAAAWBAAAAAAA ANwDAAAAAAAA3AMAAAAAAADyAwAAAAAAAPIDAAAAAAAAcRUAAAAAAAAxKwAAAAAAAGEYAABcBQAA YRgAAAAAAAC9HQAA3gEAALEpAABYAQAA8gMAAAAAAADyAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMSsAAAAAAABuFAAAAAAAAPIS AAAUAAAAoMYFjOPpvwEWBAAAHA4AADISAAAAAAAABxcAAFoBAAAJKwAAKAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAUgBvAG8AdAAgAEUAbgB0AHIAeQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/ AAAAAAAAAAAAAAAAAAAAABYABQH//////////wMAAAAGCQIAAAAAAMAAAAAAAABGAAAAAEBokojX 6b8BoMYFjOPpvwGtAAAAgAUAAAAAAABEAGEAdABhAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACgACAP///////////////wAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABDpBACcAAAAAEAAABAQAADEAVABhAGIAbABlAAAAAAAAAAAA AAAAAAAAAAAAAAAADAAAAAgAAAANAAAAlAgAAAAAAAAAAAAAAAAAAAAAAAAOAAIA//////////// ////AAAAAJQ2Y4IAAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAOwAAAJ03AADoAwAAVwBvAHIA ZABEAG8AYwB1AG0AZQBuAHQAAABBAMhPQQBBAQBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ABoAAgEGAAAABQAAAP////8AAAAAAAAAAAAAAAAAAAAAAAAAADAGAAABAAAALApBAAAAAACfAAAA AIYAABQAAACCAAAA/v///4MAAACEAAAAlAAAAP////////////////////////////////////// //////////////+kAAAA/////////////////////5UAAACWAAAAlwAAAJgAAACZAAAAmgAAAJsA AACcAAAAnQAAAJ4AAAD+////oAAAAAIAAACoAAAA/f////3///85AAAA/////6cAAACpAAAA/v// /6oAAACrAAAArAAAALAAAACuAAAArwAAAP7///+xAAAAsgAAALMAAAC0AAAAtQAAALYAAAC3AAAA uAAAALkAAAC6AAAAuwAAALwAAAC9AAAAvgAAAL8AAADAAAAAwQAAAMIAAADDAAAAxAAAAMUAAAD+ //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////AwAAAAQAAAAFAAAABgAAAAcAAAAIAAAACQAAAAoAAAALAAAADAAAAA0A AAAOAAAADwAAABAAAAARAAAAEgAAABMAAAAUAAAAFQAAABYAAAAXAAAAGAAAABkAAAAaAAAAGwAA ABwAAAAdAAAAHgAAAB8AAAAgAAAAIQAAACIAAAAjAAAAJQAAAP////9gAAAAPwAAACgAAAApAAAA KgAAACsAAAAsAAAALQAAAC4AAAD+/////////zEAAAAyAAAAMwAAADQAAAA1AAAANgAAADcAAAA4 AAAAjwAAADoAAAD+////PAAAAD0AAAA+AAAARwAAAEAAAABBAAAAQgAAAEMAAABEAAAARQAAAEYA AAAwAAAAXgAAAP////////////////////////////////////////////////////////////// /////////////////1gAAABZAAAAWgAAAFsAAABcAAAAXQAAACYAAABfAAAAYQAAAFcAAAB7AAAA //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////3wAAAB9AAAAfgAAAH8A AACAAAAADQBUAGgAaQBzACAAZABvAGMAdQBtAGUAbgB0ACAAaQBzACAAYQBuACAASQBuAHQAZQBy AG4AZQB0AC0ARAByAGEAZgB0ACAAYQBuAGQAIABpAHMAIABpAG4AIABmAHUAbABsACAAYwBvAG4A ZgBvAHIAbQBhAG4AYwBlACAAdwBpAHQAaAAgAGEAbABsACAAcAByAG8AdgBpAHMAaQBvAG4AcwAg AG8AZgAgAFMAZQBjAHQAaQBvAG4AIAAxADAAIABvAGYAIABSAEYAQwAyADAAMgA2ACAAZQB4AGMA ZQBwAHQAIAB0AGgAYQB0ACAAdABoAGUAIAByAGkAZwBoAHQAIAB0AG8AIABwAHIAbwBkAHUAYwBl ACAAZABlAHIAaQB2AGEAdABpAHYAZQAgAHcAbwByAGsAcwAgAGkAcwAgAG4AbwB0ACAAZwByAGEA bgB0AGUAZAAuACAADQBoAGEAcgBhAGMAdABlAHIAIABlAG4AYwBvAGQAaQBuAGcALAANAA0ADQAy ADEADQANAA0AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAABegQAAhIEAAIaBAACIgQAAjoEAAJCBAACSgQAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAA AAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAP0AAAAAAAAAAAAAAADyAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoVAAYkAROk8AAUpDwALUQAHUAmAAAB AAAABhIAGwAKAAEAWwAPAAIAAAAAAAAAJAAAQPH/AgAkAAAABgBOAG8AcgBtAGEAbAAAAAIAAAAE AG1ICQRIAAFAAQACAEgAAAAJAEgAZQBhAGQAaQBuAGcAIAAxAAAAEAABAAYkAROk8AAUpDwAQCYA EwA1CIFDShwAS0gcAE9KAgBRSgIAAEYAAkABAAIARgAAAAkASABlAGEAZABpAG4AZwAgADIAAAAQ AAIABiQBE6TwABSkPABAJgESADUIgTYIgUNKGABPSgIAUUoCAAAAAAAAAAAAAAAAAAAAPABBQPL/ oQA8AAAAFgBEAGUAZgBhAHUAbAB0ACAAUABhAHIAYQBnAHIAYQBwAGgAIABGAG8AbgB0AAAAAAAA AAAAAAAAADAAWkABAPIAMAAAAAoAUABsAGEAaQBuACAAVABlAHgAdAAAAAIADwAIAE9KAwBRSgMA PgAfQAEAAgE+AAAABgBIAGUAYQBkAGUAcgAAABMAEAASZBD/AAANxggAArATYCcBAgAMAENKGABP SgMAUUoDAD4AIEABABIBPgAAAAYARgBvAG8AdABlAHIAAAATABEAEmQQ/wAADcYIAAKwE2AnAQIA DABDShgAT0oDAFFKAwAmAClAogAhASYAAAALAFAAYQBnAGUAIABOAHUAbQBiAGUAcgAAAAAAOABZ QAEAMgE4AAAADABEAG8AYwB1AG0AZQBuAHQAIABNAGEAcAAAAAYAEwAtRCABCABPSgQAUUoEACgA VUCiAEEBKAAAAAkASAB5AHAAZQByAGwAaQBuAGsAAAAGAD4qAUIqAjoA/k8BAFIBOgAAAAgAUgBG AEMAIABUAGUAeAB0AAAADAAVAA+EsAESZBD/AAAMAENKGABPSgMAUUoDADwA/k8BAFIBPAAAAAsA UgBGAEMAIABIAGUAYQBkAGkAbgBnAAAACAAWABJkEP8AAAwAQ0oYAE9KAwBRSgMANAArQFEBcgE0 AAAADABFAG4AZABuAG8AdABlACAAVABlAHgAdAAAAAoAFwAPhGADEYRQ/gAANgAqQPL/gQE2AAAA EQBFAG4AZABuAG8AdABlACAAUgBlAGYAZQByAGUAbgBjAGUAAAADAEgqAABOAP5vAQCSAU4ABAAF AEEAUwBOAC4AMQAAACUAGQANxiAACjcCbgSlBtwIEwtKDYEPuBHvEyYWwMDAwMDAwMDAwAAMAE9K AwBRSgMAbUgABEQA/m+iAKEBRAAEAAkAQQBTAE4AMQBfAHcAbwByAGQAAAAhADUIgUIqAENKFgBP SgAAUUoAAGtI5ARtSAAEbkgABHUIAQAQCAAAZiAAAAEAAAAAAB4GAAAhBgAAAAAAAAEVAABmIAAA AwAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwByAG0AYQB0AGkAbwBuAAAAAAAAAAcAAAAGAAAABAAA AAQAAAD/////KAACAf///////////////wAAAAAAAAD/AAAA/3g3QQABAAAA//////////////// AAAA/w4AAADIAQAAAAAAAAUARABvAGMAdQBtAGUAbgB0AFMAdQBtAG0AYQByAHkASQBuAGYAbwBy AG0AYQB0AGkAbwBuAAAAEAAAAAQAAAA4AAIBBAAAAP//////////AQAAAOokAADiJAAA1iQAAOYk AAD/////////////////////AgAAAMQCAAD/////AQBDAG8AbQBwAE8AYgBqAAAA//////////// //////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABIAAgEHAAAA//////////8AAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAagAAAAAAAAAwAFQAYQBiAGwAZQAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAQEA AAACAAAA/////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKYAAAB5NwAAAAAA AABMAAAAAP////8DAC1MAAAAAP////8AAAAAAQAAAAoAAAALAAAAGgAAACQAAAAlAAAAUwAAAF0A AABeAAAAdgAAAHcAAAB4AAAAeQAAAHoAAACWAAAAlwAAAJgAAACsAAAArQAAAFsBAABcAQAAKwMA AI4DAADwAwAA8QMAAPIDAADzAwAA9AMAAPUDAAABBAAAAgQAAGgGAAAkBwAAJQcAACYHAABLBwAA TAcAAE0HAAAUCAAAFQgAABYIAAApCAAAKggAAPgIAAD6CQAA+wkAAPwJAAA6CgAAOwoAAMYKAADH CgAARAsAAEULAABqCwAAawsAALcLAADUCwAABQwAADgMAAB4DAAAsAwAAO8MAAAUDQAAPw0AAH0N AACuDQAAwA0AAN4NAAD5DQAAKw4AAFkOAAB3DgAAeA4AAHkOAAB6DgAAjA4AAI0OAAAfDwAAChAA AAASAAABEgAAAhIAAEcSAABIEgAAZRMAAGYTAABnEwAAghMAAIMTAAD+EwAA8BQAAPEUAADyFAAA ABUAAAEVAAACFQAAAxUAABYVAAAXFQAAgBUAAIEVAACCFQAAmRUAAJoVAAClFQAAtRUAANMVAADk FQAA+xUAABUWAAAWFgAAGBYAADEWAAAyFgAAnhkAAJ8ZAAChGQAAoxkAAMsZAADMGQAAzRkAAM4Z AAAIGgAACRoAAAsaAABEGgAARhoAAK8aAACwGgAAVBsAAFUbAACxGwAAshsAALMbAABNHAAAThwA AE8cAADSHAAA0xwAANQcAACNHQAAjh0AAI8dAADtHQAA7h0AAO8dAABZHgAAWh4AAFseAACzHgAA tB4AALUeAAAwHwAAMR8AADIfAACaHwAAmx8AAJwfAAACIAAAAyAAAAQgAABjIAAAZCAAAGcgAACp AAAAFgAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICZAAAAAAAAAAAAAAAAgAAAAICpAAAA FgAAAAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICZAAAAAAAAAAAAAAAAgAAAAICpAAAAFgAA AAAAAAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICZAAAAAAAAAAAAAAAAgAAAAICpAAAAFgAAAAAA AAAAgAAAAICpAAAAFgAAAAAAAAAAgAAAAICZAAAAAAAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAA gAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAA AICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAGQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAQD+ /wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNyb3NvZnQgV29yZCBEb2N1bWVudAAKAAAA TVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9DmycQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAAAAAAAAACAAAAAtXN1ZwuGxCTlwgAKyz5rkQA AAAF1c3VnC4bEJOXCAArLPmuQAEAAPwAAAAMAAAAAQAAAGgAAAAPAAAAcAAAAAUAAAB8AAAABgAA AIQAAAARAAAAjAAAABcAAACUAAAACwAAAJwAAAAQAAAApAAAABMAAACsAAAAFgAAALQAAAANAAAA vAAAAAwAAADeAAAAAgAAAOQEAAAeAAAAAgAAACAAbwADAAAALQAAAAMAAAAKAAAAAwAAAAAaAAAD AAAAahAIAAsAAAAAAAAACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAWAAAATmV0d29y ayBXb3JraW5nIEdyb3VwAAwQAAACAAAAHgAAAAYAAABUaXRsZQADAAAAAQAAAIQBAAAEAAAAAAAA ACgAAAABAAAAUgAAAAIAAABaAAAAAwAAALIAAAACAAAAAgAAAAoAAABfUElEX0dVSUQAAwAAAAwA AABfUElEX0hMSU5LUwACAAAA5AQAAEEAAABOAAAAewBBAEQAMgA1ADgANQAzAEEALQA1ADUAMQBE AC0AMQAxAEQAMAAtADgARgA3ADUALQAwADAAQQAwAEMAOQAxADUAMwA1ADUAQgB9AAAAAABBAAAA yAAAAAwAAAADAAAAPgAMAAMAAAADAAAAAwAAAAAAAAADAAAABQAAAB8AAAAcAAAAbQBhAGkAbAB0 AG8AOgBtAGkAawBlAGcAYQBAAG0AaQBjAHIAbwBzAG8AZgB0AC4AYwBvAG0AAAAfAAAAAQAAAAAA AAADAAAAUAApAAMAAAAAAAAAAwAAAAAAAAADAAAABQAAAB8AAAARAAAAbQBhAGkAbAB0AG8AOgB1 AHMAZQByAEAAaABvAHMAdAAAAAAAHwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD+/wAABAoCAAAAAAAAAAAAAAAA AAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAACYAQAAEgAAAAEAAACYAAAAAgAAAKAAAAADAAAA wAAAAAQAAADMAAAABQAAAOAAAAAGAAAA7AAAAAcAAAD4AAAACAAAAAwBAAAJAAAAIAEAABIAAAAs AQAACgAAAEgBAAALAAAAVAEAAAwAAABgAQAADQAAAGwBAAAOAAAAeAEAAA8AAACAAQAAEAAAAIgB AAATAAAAkAEAAAIAAADkBAAAHgAAABYAAABOZXR3b3JrIFdvcmtpbmcgR3JvdXAAOAAeAAAAAQAA AABldHceAAAADAAAAE1pa2UgR2Focm5zAB4AAAABAAAAAGlrZR4AAAABAAAAAGlrZR4AAAALAAAA Tm9ybWFsLmRvdAAAHgAAAAsAAABPcml0IExldmluAAAeAAAAAgAAADkAaXQeAAAAEwAAAE1pY3Jv c29mdCBXb3JkIDguMAB1QAAAAADUrfQBAAAAQAAAAADio2hY6L8BQAAAAACmM3bX6b8BQAAAAAAq zXnj6b8BAwAAAAEAAAADAAAAtgMAAAMAAAAsFQAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAA AAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAA AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICeAAAAAAAAAAAAAAAAgAAAAICYAAAA FQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAA AAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAA AAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAA gAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAA AICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICYAAAAFQAAAAAAAAAAgAAAAICY AAAAFQAAAAAAAAAAgAAAAICYAAAAFgAAAAAAAAAAgAAAAICYAAAAAAAAAAAAAAAAgAAAAIAIAAAA FQAAAAAAAAAAgAAAAICaQAAAEQAAAAAAAAAAgAAAAICaQAAAEQAAAAAAAAAAgAAAAICaQAAAAAAA AAAAAAAAgAAAAICaQAAAEAAAAAAAAAAAgAAAAICYQAAAEAAAAAAAAAAAgAAAAICYQAAAEAAAAAAA AAAAgAAAAICaQAAAAAAAAAAAAAAAgAAAAICaQAAAEQAAAAAAAAAAgAAAAICaQAAAAAAAAAAAAAAA gAAAAICYQAAAEQAAAAAAAAAAgAAAAICaQAAAEQAAAAAAAAAAgAAAAIAKAAAAAAAAAAAAAAAAAAAA AACaQAAAFwAAAAAAAAAAgAAAAICYQAAAFwAAAAAAAAAAgAAAAICYQAAAFwAAAAAAAAAAgAAAAICY QAAAFQAAAAAAAAAAgAAAAICYQBEgFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAA FQAAAAAAAAAAgAAAAICYQBEgFQABAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAA AAAAAAAAgAAAAICYQBEgFQACAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAA AAAAgAAAAICYQBEgFQADAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAA gAAAAICYQBEgFQAEAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAA AICYQBEgFQAFAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICY QBEgFQAGAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEg FQAHAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQAI AAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQBEgFQAJAAAA AAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFQAAAAAAAAAAgAAAAICYQAAAFwAAAAAAAAAA gAAAAICYQAAAFwAAAAAAAAAAgAAAAIAKAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AgAAAAQAAAAGAAAABgAAADAAAAAwAAAAawAAAGsAAACnAAAApwAAAKcAAACnAAAApwAAAKcAAACn AAAAqgAAAAAEAACvHQAAkoEAABwAAAAkAAAAAAQAAAkIAAB6DwAAEhYAAK8ZAABbHgAA/FMAACRf AADIZwAAynUAAF6BAACSgQAAHQAAAB8AAAAgAAAAIQAAACMAAAAlAAAALQAAADUAAAA2AAAAPgAA AEEAAAAABAAAEhkAAMceAAAeAAAAIgAAAP//DAAAAAcAVQBuAGsAbgBvAHcAbgANAFAAYQB1AGwA IABFAC4AIABKAG8AbgBlAHMADABNAGEAcgBrAGsAdQAgAEsAbwByAHAAaQAKAFIAaQBjAGgAIABC AG8AdwBlAG4ADABQAGUAdABlACAAQwBvAHIAZABlAGwAbAAKAE8AcgBpAHQAIABMAGUAdgBpAG4A BgBmAG8AbwBiAGEAcgAIAEoAaQBtACAAVABvAGcAYQAKAEoAYQBtAGUAcwAgAFQAbwBnAGEACwBS AGkAYwBrACAAQgBvAGkAdgBpAGUADQBOAGEAbgBjAHkAIABGAGUAbABkAG0AYQBuAA0ARQBzAHAA ZQBuACAAUwBrAGoA5gByAGEAbgDNBQAA6wUAAPUFAAByGQAAmxkAAJwZAABmIAAAE1gU/xWEE1gU /xWMXwAAAGYAAABoAAAAmwAAAKIAAACkAAAAqgAAABMh9P+VgBMh9P+VgA8AAPA4AAAAAAAG8BgA AAACCAAAAgAAAAEAAAABAAAAAQAAAAIAAABAAB7xEAAAAP//AAAAAP8AgICAAPcAABAADwAC8JIA AAAQAAjwCAAAAAEAAAABBAAADwAD8DAAAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAAAAAAAAAA AAIACvAIAAAAAAQAAAUAAAAPAATwQgAAABIACvAIAAAAAQQAAAAOAABTAAvwHgAAAL8BAAAQAMsB AAAAAP8BAAAIAAQDCQAAAD8DAQABAAAAEfAEAAAAAQAAAP//AQAAAAYAYwAxAHQAaQB0AGUA9BsA AGcgAAAAAAAA9BsAAGcgAAAAAAAAjAIAAJUCAADsBQAA9QUAAPsKAAADCwAAjQsAAJULAAC3CwAA vwsAAJEQAACZEAAAJxEAAC8RAAANFwAAGhcAAJ4ZAACeGQAAnxkAAJ8ZAACgGQAAoBkAAKEZAACi GQAAoxkAAKQZAABFGgAARhoAAEkaAABQGgAAbBoAAHAaAADDGgAAyhoAANYbAADgGwAA/BsAAAkc AADXHAAA3hwAAOMcAADuHAAA8xwAAPscAAAEHQAADR0AAJ8dAAC4HQAA7x0AAPYdAAAAHgAACB4A ABQeAAAcHgAAaB4AAHAeAAB8HgAAhB4AALUeAAC8HgAA2h4AAOIeAACfHwAApB8AAGcgAAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcABAAHAAQAAgAEAAcABAAHAAQABwACAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcA HAAHABwABwAcAAcAAAAAAGwBAABvAQAANQIAADgCAABaCAAAXwgAAAMKAAAJCgAAfgsAAIQLAAC3 CwAAvwsAANQLAADYCwAABQwAAA0MAAA4DAAAQwwAAHgMAACADAAAKw0AAC4NAAA/DQAARg0AAH0N AACDDQAArg0AALINAADADQAAyg0AAN4NAADmDQAA+Q0AAP0NAABZDgAAYA4AAEkVAABZFQAAAhYA ABQWAABzFgAA9hcAAPcXAACdGQAAnhkAAJ4ZAACfGQAAnxkAAKAZAACgGQAAoRkAAKIZAACjGQAA pBkAAEUaAABGGgAAZyAAAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwAaAAcAGgAHAAQABwAEAAIA BAAHAAQABwAEAAcAAgAHAP//FAAAAAoATwByAGkAdAAgAEwAZQB2AGkAbgA0AEMAOgBcAFMAdABh AG4AZABhAHIAZABzAFwASQBFAFQARgBcAGQAcgBhAGYAdAAtAGwAZQB2AGkAbgAtAGgAMwAyADMA LQB1AHIAbAAtAHMAYwBoAGUAbQBlAC0AMAAwAC4AZABvAGMACgBPAHIAaQB0ACAATABlAHYAaQBu ADQAQwA6AFwAUwB0AGEAbgBkAGEAcgBkAHMAXABJAEUAVABGAFwAZAByAGEAZgB0AC0AbABlAHYA aQBuAC0AaAAzADIAMwAtAHUAcgBsAC0AcwBjAGgAZQBtAGUALQAwADAALgBkAG8AYwAKAE8AcgBp AHQAIABMAGUAdgBpAG4ANABDADoAXABTAHQAYQBuAGQAYQByAGQAcwBcAEkARQBUAEYAXABkAHIA YQBmAHQALQBsAGUAdgBpAG4ALQBoADMAMgAzAC0AdQByAGwALQBzAGMAaABlAG0AZQAtADAAMAAu AGQAbwBjAAoATwByAGkAdAAgAEwAZQB2AGkAbgBHAEMAOgBcAHcAaQBuAGQAbwB3AHMAXABUAEUA TQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAZAByAGEAZgB0 AC0AbABlAHYAaQBuAC0AaAAzADIAMwAtAHUAcgBsAC0AcwBjAGgAZQBtAGUALQAwADAALgBhAHMA ZAAKAE8AcgBpAHQAIABMAGUAdgBpAG4ANABDADoAXABTAHQAYQBuAGQAYQByAGQAcwBcAEkARQBU AEYAXABkAHIAYQBmAHQALQBsAGUAdgBpAG4ALQBoADMAMgAzAC0AdQByAGwALQBzAGMAaABlAG0A ZQAtADAAMAAuAGQAbwBjAAoATwByAGkAdAAgAEwAZQB2AGkAbgA1AEMAOgBcAFMAdABhAG4AZABh AHIAZABzAFwASQBFAFQARgBcAGQAZAByAGEAZgB0AC0AbABlAHYAaQBuAC0AaAAzADIAMwAtAHUA cgBsAC0AcwBjAGgAZQBtAGUALQAwADAALgBkAG8AYwAKAE8AcgBpAHQAIABMAGUAdgBpAG4ANQBD ADoAXABTAHQAYQBuAGQAYQByAGQAcwBcAEkARQBUAEYAXABkAGQAcgBhAGYAdAAtAGwAZQB2AGkA bgAtAGgAMwAyADMALQB1AHIAbAAtAHMAYwBoAGUAbQBlAC0AMAAwAC4AZABvAGMACgBPAHIAaQB0 ACAATABlAHYAaQBuADUAQwA6AFwAUwB0AGEAbgBkAGEAcgBkAHMAXABJAEUAVABGAFwAZABkAHIA YQBmAHQALQBsAGUAdgBpAG4ALQBoADMAMgAzAC0AdQByAGwALQBzAGMAaABlAG0AZQAtADAAMAAu AGQAbwBjAAoATwByAGkAdAAgAEwAZQB2AGkAbgBIAEMAOgBcAHcAaQBuAGQAbwB3AHMAXABUAEUA TQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAAZABkAHIAYQBm AHQALQBsAGUAdgBpAG4ALQBoADMAMgAzAC0AdQByAGwALQBzAGMAaABlAG0AZQAtADAAMAAuAGEA cwBkAAoATwByAGkAdAAgAEwAZQB2AGkAbgA1AEMAOgBcAFMAdABhAG4AZABhAHIAZABzAFwASQBF AFQARgBcAGQAZAByAGEAZgB0AC0AbABlAHYAaQBuAC0AaAAzADIAMwAtAHUAcgBsAC0AcwBjAGgA ZQBtAGUALQAwADAALgBkAG8AYwARANd/OgqQY2ZP/w//D/8P/w//D/8P/w//D/8PAAC8D9sOlhFc rf8P/w//D/8P/w//D/8P/w//DwAAo0yEIhcACQT/D/8P/w//D/8P/w//D/8P/w8BANkWNCsPAAkE /w//D/8P/w//D/8P/w//D/8PAQBjISozDwAJBP8PAAAAAAAAAAAAAAAAAAAAAAEAB0LLM5q/mEH/ D/8P/w//D/8P/w//D/8P/w8AALVpaUYPAAkE/w//D/8P/w//D/8P/w//D/8PAQDzDkFMnnDWaP8P /w//D/8P/w//D/8P/w//DwEAsRsYT/IsxDv/D/8P/w//D/8P/w//D/8P/w8BAPot5VABAAkE/w8A AAAAAAAAAAAAAAAAAAAAAQBHHNJVrP6o/v8P/w//D/8P/w//D/8P/w//DwEAJkKOWmS1Yrf/D/8P /w//D/8P/w//D/8P/w8BAOgL7FwPAAkE/w//D/8P/w//D/8P/w//D/8PAQA3Lw9wRBmMJv8P/w// D/8P/w//D/8P/w//DwEA/nf7ecJ7zlb/D/8P/w//D/8P/w//D/8P/w8BANwH1XoPAAkE/w8AAAAA AAAAAAAAAAAAAAAAAQD0ePx6DwAJBP8PAAAAAAAAAAAAAAAAAAAAAAEABQAAAAAAAQAAAAAAAAAA AAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAABAAAAAQAAAAAAAQMAAAAAAAAAAAAAAAAA AAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAADAAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAA AAMQAAAPhNACEYQw/RXGBQAB0AIGbygABQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAAAAAAAAAA AAAAAxAAAA+EOAQRhMj7FcYFAAE4BAZvKAAHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAA AAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYFAAE4BAZvKAAJAAAALgABAC4AAgAuAAMALgAEAAEAAAAA AAEDBQcJCwAAAAAAAAAAAAAAAAMQAAAPhKAFEYRg+hXGBQABoAUGbygACwAAAC4AAQAuAAIALgAD AC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAAxAAAA+ECAcRhPj4FcYFAAEIBwZvKAAN AAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAAxAAAA+E CAcRhPj4FcYFAAEIBwZvKAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAAAAED BQcJCw0PEQAAAAAAAAAAAAMQAAAPhHAIEYSQ9xXGBQABcAgGbygAEQAAAC4AAQAuAAIALgADAC4A BAAuAAUALgAGAC4ABwAuAAgABAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYF AAFoAQZvKAACAAAALgABAAAAAAQBAwAAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdAC Bm8oAAQAAAAuAAEALgABAAAAAAQBAwUAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdAC Bm8oAAYAAAAuAAEALgACAC4AAQAAAAAEAQMFBwAAAAAAAAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYF AAE4BAZvKAAIAAAALgABAC4AAgAuAAMALgABAAAAAAQBAwUHCQAAAAAAAAAAAAAAAAADEAAAD4Sg BRGEYPoVxgUAAaAFBm8oAAoAAAAuAAEALgACAC4AAwAuAAQALgABAAAAAAQBAwUHCQsAAAAAAAAA AAAAAAADEAAAD4SgBRGEYPoVxgUAAaAFBm8oAAwAAAAuAAEALgACAC4AAwAuAAQALgAFAC4AAQAA AAAEAQMFBwkLDQAAAAAAAAAAAAAAAxAAAA+ECAcRhPj4FcYFAAEIBwZvKAAOAAAALgABAC4AAgAu AAMALgAEAC4ABQAuAAYALgABAAAAAAQBAwUHCQsNDwAAAAAAAAAAAAADEAAAD4RwCBGEkPcVxgUA AXAIBm8oABAAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgABAAAAAAQBAwUHCQsNDxEA AAAAAAAAAAADEAAAD4RwCBGEkPcVxgUAAXAIBm8oABIAAAAuAAEALgACAC4AAwAuAAQALgAFAC4A BgAuAAcALgAIAC4AAQAAAAQAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZv KAACAAAAKQADAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAIA AAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4ABQAA AAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAACAAAALgABAAAAAAQB AwAAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAQAAAAuAAEALgABAAAAAAQB AwUAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAYAAAAuAAEALgACAC4AAQAA AAAEAQMFBwAAAAAAAAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYFAAE4BAZvKAAIAAAALgABAC4AAgAu AAMALgABAAAAAAQBAwUHCQAAAAAAAAAAAAAAAAADEAAAD4SgBRGEYPoVxgUAAaAFBm8oAAoAAAAu AAEALgACAC4AAwAuAAQALgABAAAAAAQBAwUHCQsAAAAAAAAAAAAAAAADEAAAD4SgBRGEYPoVxgUA AaAFBm8oAAwAAAAuAAEALgACAC4AAwAuAAQALgAFAC4AAQAAAAAEAQMFBwkLDQAAAAAAAAAAAAAA AxAAAA+ECAcRhPj4FcYFAAEIBwZvKAAOAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgABAAAA AAQBAwUHCQsNDwAAAAAAAAAAAAADEAAAD4RwCBGEkPcVxgUAAXAIBm8oABAAAAAuAAEALgACAC4A AwAuAAQALgAFAC4ABgAuAAcALgABAAAAAAQBAwUHCQsNDxEAAAAAAAAAAAADEAAAD4RwCBGEkPcV xgUAAXAIBm8oABIAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAC4AAwAAAAAAAQAA AAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAACAAAALgADAAAAAAABAAAAAAAA AAAAAAAAAAAAAAADEAAAD4RYAhGEqP0VxgUAAVgCBm8oAAIAAAAuAAEAAAAAAAEAAAAAAAAAAAAA AAAAAAAAAAMQAAAPhBgDEYSY/hXGBQABGAMGbygAAgAAACkAAQAAABcAAAAAAAAAAAAAAAAAAAAA AAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAA AAAAAAADEAAAD4RgAxGEUP4VxgUAAWADBm8oAAIAAAApAAMAAAAAAAEAAAAAAAAAAAAAAAAAAAAA AAMQAAAPhGMDEYRN/hXGBQABYwMGbygAAQAAAAkAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAP hGgBEYSY/hXGBQABaAEGbygAAgAAAC4ABgAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EWAIR hKj9FcYFAAFYAgZvKAACAAAALgAKAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0V xgUAAdACBm8oAAIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQAB aAEGAgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAA LgARAAAAo0yEIgAAAAAAAAAAAAAAAPot5VAAAAAAAAAAAAAAAADzDkFMAAAAAAAAAAAAAAAANy8P cAAAAAAAAAAAAAAAANkWNCsAAAAAAAAAAAAAAAC1aWlGAAAAAAAAAAAAAAAAB0LLMwAAAAAAAAAA AAAAANd/OgoAAAAAAAAAAAAAAAC8D9sOAAAAAAAAAAAAAAAA/nf7eQAAAAAAAAAAAAAAAEcc0lUA AAAAAAAAAAAAAACxGxhPAAAAAAAAAAAAAAAA9Hj8egAAAAAAAAAAAAAAAGMhKjMAAAAAAAAAAAAA AADcB9V6AAAAAAAAAAAAAAAA6AvsXAAAAAAAAAAAAAAAACZCjloAAAAAAAAAAAAAAAD///////// //////////////////////////////////////////////////////////////////////////// ////////EQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/QA+AAQAAAAAAAAAA AHhtZAABAAEAAAAAAAAAAAAAAAAAAAAAAAEIAABGFQAwSgoAAQYANQiAQioAAQYADCoANQiAAQsA AEYVAAwqADBKCgABBgA1CIE2CIEBBAAPhAAAAlAIAAAAAAAAAQAAAAoAAAAaAAAAJAAAACUAAABT AAAAXQAAAF4AAAB2AAAAdwAAAHoAAACVAAAAqwAAAKwAAACtAAAAWgEAAFsBAABcAQAAzQUAAPYF AAAZCAAA+QkAAPoJAAD/CQAAKAoAADkKAAA6CgAAOwoAAFQKAABcCgAAYQoAAGkKAABxCgAAtwsA AHcOAAB4DgAAfQ4AAI0OAADADgAAxg4AAC0PAABNDwAABRIAACISAAAjEgAA+RIAAIMTAADvFAAA ABUAAAEVAAACFQAAFxUAABcWAACdGQAAnhkAAJ8ZAACgGQAAoRkAAKIZAACjGQAApBkAAAUaAAAG GgAAQRoAAEIaAABFGgAARhoAAI8aAACuGgAArxoAALAaAACxGgAAsxoAAFMbAABUGwAAVRsAAFsb AABcGwAAaRsAAGobAABwGwAAcRsAAJ8bAACgGwAAohsAALAbAACxGwAAshsAALMbAAC5GwAAuhsA AMcbAADIGwAAzxsAANAbAADRGwAAOxwAAD4cAABMHAAATRwAAE4cAABPHAAAVRwAAFYcAABjHAAA ZBwAAGkcAABqHAAAaxwAAKMcAADCHAAAxRwAANEcAADSHAAA0xwAANQcAABtHQAAjB0AAI0dAACO HQAAjx0AAJIdAACXHQAAnB0AAKodAACrHQAArB0AANIdAADTHQAA5B0AAOwdAADtHQAA7h0AAO8d AABYHgAAWR4AAFoeAABbHgAAsh4AALMeAAC0HgAAtR4AAPQeAAD1HgAALx8AADAfAAAxHwAAMh8A AJkfAACaHwAAmx8AAJwfAACyHwAA3x8AAOAfAAABIAAAAiAAAAMgAAAEIAAABiAAAAcgAAANIAAA DiAAABsgAAAcIAAAIiAAACkgAAAqIAAAKyAAAEIgAABXIAAAWCAAAFogAABiIAAAZCAAAGUgAABm IAAAMAAACABAAAAwAAIIAECaADAAFAgAQAAAMAA0CABAmgAwAEgIAEAAADAASggAQJoAMACmCABA mgAwALoIAEAAADAAvAgAQJoAMADsCABAmgAwAO4IAEAAADEA9AgAQJoAMAAqCQBAAAAwAACAAAAA ADAAVgkAQAEAMQACgAAAAAAwAFyBAAAAADAAWAkAQAAAMADmCgBAAAAxAMgTAEADADAAGhQAQAAA MABgGABABQAwACAcAECqgDAAIhwAQAAAMQAsHABAmgAxAF6BAAAAADAAAG4AAAAAMAC+HABABwAx AMAcAEAAADEAAm4AAAAAMQASbgAAAAAxAPIcAEAAADEAHG4AAAAAMAACHQBAAAAwAJAfAEAAADAA ECUAQJoAMAASJQBAAAAwABwlAECaADEAPCUAQAAAMQCiJQBACQAwAK4lAEAAADEALG4AAAAAMAC8 JgBAAAAxACwsAECaADEAgIEAAAAAMABmLABAmgAwABIuAEAAADAAJi8AQJoAMAD+MQBAAAAwACIy AEAAADAALDIAQAsAMAAuMgBAAAAwAFgyAECaADAAWDQAQAAAMACMPQBAAAAwAGY7AEAAADAAgoEA AAAAMABqOwBAAAAwAISBAAAAADAAbjsAQAAAMACGgQAAAAAwAHI7AEAAADEAiIEAAAAAMAA2PABA AAAxAIqBAAAAADAArjwAQAAAMACMgQAAAAAxAHhuAAAAADEACm8AAAAAMABIbwAAAAAwAEpvAAAA ADEATG8AAAAAMQBObwAAAAAxAFJvAAAAADAAknAAAAAAMACUcAAAAAAxAJZwAAAAADEAonAAAAAA MQCkcAAAAAAxAL5wAAAAADEAwHAAAAAAMQDMcAAAAAAxAM5wAAAAADEAKnEAAAAAMQAscQAAAAAx ADBxAAAAADAATHEAAAAAMABOcQAAAAAwAFBxAAAAADEAUnEAAAAAMQBecQAAAAAxAGBxAAAAADEA enEAAAAAMQB8cQAAAAAxAIpxAAAAADEAjHEAAAAAMQCOcQAAAAAxAGJyAAAAADEAaHIAAAAAMACE cgAAAAAwAIZyAAAAADAAiHIAAAAAMQCKcgAAAAAxAJZyAAAAADEAmHIAAAAAMQCycgAAAAAxALRy AAAAADEAvnIAAAAAMQDAcgAAAAAxAMJyAAAAADEAMnMAAAAAMQBwcwAAAAAxAHZzAAAAADAAjnMA AAAAMACQcwAAAAAwAJJzAAAAADEAlHMAAAAAMQDGdAAAAAAwAAR1AAAAADAABnUAAAAAMAAIdQAA AAAxAAp1AAAAADEAEHUAAAAAMQAadQAAAAAxACR1AAAAADEAQHUAAAAAMQBCdQAAAAAxAER1AAAA ADEAkHUAAAAAMQCSdQAAAAAxALR1AAAAADAAxHUAAAAAMADGdQAAAAAwAMh1AAAAADEAynUAAAAA MACcdgAAAAAwAJ52AAAAADAAoHYAAAAAMQCidgAAAAAwAFB3AAAAADAAUncAAAAAMABUdwAAAAAx AFZ3AAAAADEA1HcAAAAAMQDWdwAAAAAwAEp4AAAAADAATHgAAAAAMABOeAAAAAAxAFB4AAAAADAA HnkAAAAAMAAgeQAAAAAwACJ5AAAAADEAJHkAAAAAMQBQeQAAAAAxAKp5AAAAADEArHkAAAAAMADu eQAAAAAwAPB5AAAAADAA8nkAAAAAMQD0eQAAAAAxAPh5AAAAADEA+nkAAAAAMQAGegAAAAAxAAh6 AAAAADEAInoAAAAAMQAkegAAAAAxADB6AAAAADEAPnoAAAAAMQBAegAAAAAxAEJ6AAAAADEAcHoA AAAAMQCaegAAAAAxAJx6AAAAADEAoHoAAAAAMACGPQBAAAAwAI6BAAAAADAAjD0AQAAABQAAAEcW kAEAAAICBgMFBAUCAwQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABUAGkAbQBlAHMAIABOAGUAdwAg AFIAbwBtAGEAbgAAADUWkAECAAUFAQIBBwYCBQcAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABTAHkA bQBiAG8AbAAAADMmkAEAAAILBgQCAgICAgQDAAAAAAAAAAAAAAAAAAAAAQAAAAAAAABBAHIAaQBh AGwAAAA/NZABAAACBwMJAgIFAgQEAwAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAQwBvAHUAcgBpAGUA cgAgAE4AZQB3AAAANSaQAQAAAgsGBAMFBAQCBIc6AAAAAAAAAAAAAAAAAAD/AAAAAAAAAFQAYQBo AG8AbQBhAAAAIgAEADEIiBgAAIAEAABoAQAAAAC5S0cGFExHBk88R6YHAA0AAAC0AwAAHxUAAAEA CgAAAAQAgBAtAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAAJEjAAAABAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAKUGwAe0ALQAgAASNAAAEAAZAGQAAAAZAAAA8BkAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//xIA AAAAAAAAFQBOAGUAdAB3AG8AcgBrACAAVwBvAHIAawBpAG4AZwAgAEcAcgBvAHUAcAAAAAAAAAAL AE0AaQBrAGUAIABHAGEAaAByAG4AcwAKAE8AcgBpAHQAIABMAGUAdgBpAG4AAAAAAAAAAAAAAAAA AAAAAAAAAAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAA AAAAAAAAAAMQAAAPhHAIEYSQ9xXGBQABcAgGbygAEQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAG AC4ABwAuAAgABAAAAAAAAQAAAAAAAAAAAAAAAAA= ------=_NextPart_000_0014_01BFFB33.04851E40-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Aug 2 05:17:49 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17994 for ; Wed, 2 Aug 2000 05:17:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C1E2644383; Wed, 2 Aug 2000 05:17:26 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from relay1.alcatel.be (alc119.alcatel.be [195.207.101.119]) by lists.bell-labs.com (Postfix) with ESMTP id AC09F44338 for ; Wed, 2 Aug 2000 05:17:23 -0400 (EDT) Received: from btmq9s.rc.bel.alcatel.be (localhost [127.0.0.1]) by relay1.alcatel.be (8.10.1/8.10.1) with ESMTP id e729HXT10373 for ; Wed, 2 Aug 2000 11:17:33 +0200 (MET DST) Received: from alcatel.be (bt015c [138.203.66.144]) by btmq9s.rc.bel.alcatel.be (8.8.8+Sun/8.8.8/1.1) with ESMTP id LAA07852 for ; Wed, 2 Aug 2000 11:17:12 +0200 (MET DST) Message-ID: <3987E704.203E1E20@alcatel.be> Date: Wed, 02 Aug 2000 11:16:52 +0200 From: Frans Westerhuis Organization: Alcatel Research - http://www.alcatel.com/crc X-Mailer: Mozilla 4.61 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: multipart/mixed; boundary="------------E649E6F5A5CC7D12FFB8274A" Subject: [IPTEL] draft-ietf-iptel-cpl-02.txt Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. --------------E649E6F5A5CC7D12FFB8274A Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have just had a look at the cpl-02 draft and noticed two small inconsitencies: 5.1 Address switches, parameter subfield, asn1 has been removed and a new parameter has been added: alias-type. However the text is still mentioning asn1. 6.3 Location filtering. The first sentence mentions address set, I suppose this should be location set? Regards, Frans Westerhuis Alcatel Research --------------E649E6F5A5CC7D12FFB8274A Content-Type: text/x-vcard; charset=us-ascii; name="Frans.Westerhuis.vcf" Content-Description: Card for Frans Westerhuis Content-Disposition: attachment; filename="Frans.Westerhuis.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Westerhuis;Frans tel;fax:+32 3240 8485 tel;work:+32 3240 9235 x-mozilla-html:TRUE url:http://www.alcatel.com/crc org:Alcatel Research version:2.1 email;internet:Frans.Westerhuis@alcatel.be title:Research Engineer adr;quoted-printable:;;Service Project - DS9=0D=0AFrancis Wellesplein 1;Antwerp;;B-2018;Belgium x-mozilla-cpt:;-1 fn:Frans Westerhuis end:vcard --------------E649E6F5A5CC7D12FFB8274A-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Aug 3 09:50:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04468 for ; Thu, 3 Aug 2000 09:50:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5825C44337; Thu, 3 Aug 2000 09:50:37 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 2A585443DC for ; Tue, 1 Aug 2000 13:44:03 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Tue Aug 1 13:43:38 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 7BC4744368; Tue, 1 Aug 2000 13:30:29 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ihrh1.emsr.lucent.com (ihrh1.emsr.lucent.com [135.1.218.53]) by lists.bell-labs.com (Postfix) with ESMTP id 3750F44347 for ; Tue, 1 Aug 2000 13:30:29 -0400 (EDT) Received: from ihemlsrv.firewall.lucent.com by ihrh1.emsr.lucent.com (8.8.8+Sun/EMS-1.5 Solaris/emsr) id MAA15496 for ; Tue, 1 Aug 2000 12:30:26 -0500 (CDT) Received: from ihemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA06588 for ; Tue, 1 Aug 2000 13:30:28 -0400 (EDT) Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id NAA06582 for ; Tue, 1 Aug 2000 13:30:27 -0400 (EDT) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2650.21) id ; Tue, 1 Aug 2000 19:30:18 +0200 Message-ID: <2413FED0DFE6D111B3F90008C7FA61FB087FC542@nl0006exch002u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: MEGACO@STANDARDS.NORTELNETWORKS.COM, iptel@lists.bell-labs.com, SIGTRAN@STANDARDS.NORTELNETWORKS.COM Date: Tue, 1 Aug 2000 19:30:16 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Subject: [IPTEL] Invitation for JointNM meeting 9-11 August 200 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Hi, Various technical people who normally attend Tiphon, ITU, ETSI, T1M1, have agreed to work together in a series of so called "Joint Network Management" meetings. They have also invited technical contribution from subject matter experts who are active in the IETF and other organisations. The relevant IETF Area Directors do encourage individual participation by subject matter experts, even though these meetings are not to be seen as formal IETF meetings. Individuals that attend should not be seen as speaking for the IETF or for IETF working groups but the ADs feel that anything that improves communication between groups working on simular issues is helpful The next meeting is Aug 9-11 in Torrance, California. Subject matter experts are invited to participate (on personal title). There is no need to register for the meeting, you can just show up at the Torrance Marriott. The proposed agenda and the "scope of activities" is attached. Bert Wijnen & Randy Bush Area Directors Operations and Management Scott Bradner, Area Director Transport -------------------------- ------------------------------------- AGENDA FOR JOINT NM MEETING AUGUST 9-11, 2000 NOTE ON SCOPE OF ACTIVITIES: Ongoing discussions have made it evident that there may some clarification required with respect to the scope of the activities within the Joint-NM Group (JNG). In a nutshell, the scope of the JNG includes all management aspects of IP and hybrid circuit switched/packet networks. At the first joint session it was agreed that priority will be given to VoIP services as several of the standards organizations participating in this effort are focusing on this service. The implications of this priority are that requirements will be analyzed with respect to VoIP and the management infrastructure required to support this service will be defined. However, whenever, it is evident that a particular management activity is useful for other applications it will be generalized to accommodate those services. In addition, at the NE or NM level there may be lots of functionality that is application agnostic, again this functionality will be defined in the appropriate manner. In addition, since the group is driven by contributions, contributions that address the broader problem will also be accepted. August 9, 2000 1. Approval of Agenda 2. Fault Management (for VoIP environment) (1 Day) * Alarm Reporting Requirements VoIP [Build on Results of May Meeting] * Abstract Information Model & Flows for Alarm Reporting Drafting Group to produce first cut of text may be established * Trouble-ticket Requirements for VoIP [Build on Results of May Meeting] * Abstract Information Model & Flows for Trouble Ticketing 3. Performance Management for the VoIP environment (1/2 day) * QoS environment for VoIP [Inpiut required from QoS Experts] * Traffic management requirements for VoIP [Build on Results of May Meeting] * Evaluation of Q,823 for the IP environment 4. Progress of Framework Documents (1/2 day) 5. New Business (IE Additional contributions received on topics) (1/4 day) 6. Work Plan for future meetings (1/4 day) 7. Meeting wrap up and call for contributions for August meeting ------------------------ more information may be available at: http://www.etsi.org/jointnm/jointnm.htm or at: http://list.etsi.fr/archives/jointnm.html _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Aug 4 11:39:52 2000 Received: 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 LAA18120 for ; Fri, 4 Aug 2000 11:39:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2181544376; Fri, 4 Aug 2000 11:38:32 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id AB6384433D for ; Fri, 4 Aug 2000 11:38:28 -0400 (EDT) Received: by dnspri.npac.com; id KAA25415; Fri, 4 Aug 2000 10:38:22 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma025282; Fri, 4 Aug 00 10:37:58 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Fri, 4 Aug 2000 10:37:08 -0500 Message-ID: From: James Yu To: "'hsalama@cisco.com'" Cc: "'iptel@lists.bell-labs.com'" Date: Fri, 4 Aug 2000 10:35:37 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Hussein, Section 5.1.1 of TRIP defines two address families, One for POTS numbers and the other for routing numbers. Since TRIP deals with "routing," it is suggested that only the "routing numbers" address family is used. This will avoid the handling of two address families in TRIP for supporting number portability (NP). The basic rule is: (1) Use the "routing number" for routing (e.g., check against the TRIP routing table) if both the "routing number" and "POTS number" are present. (2) Use the "POTS number" for routing if "routing number" is not present. The reasons are described below. - For countries such as U.S. and Canada that support NP and use routing numbers that overlap with the POTS numbers (e.g., the same format and length), and use the POTS numbers as the routing numbers for non-ported POTS numbers, the "routing number" address family is sufficient for call routing. * For a ported-out number, a location routing number (LRN) is retrieved from the NP database. That LRN (plus the country code if required) is used for routing. * For a non-ported number, that POTS number is used for routing because its prefix (e.g., the first 6 digits of the national number) can identify the donor switch that serves this non-ported number. The POTS numbers in this case are actually treated as the routing numbers! For example, if the POTS number is 202-533-1234 and is not ported, a LRN of 202-533-0000 can be used as the LRN for routing the call. Use of "202-533-1234" or "202-533-0000" does not make any difference because the GSTN switches in the North America routes national calls based on the first 6 digits of the national POTS numbers. That is why the POTS numbers are used for routing for non-ported numbers. So all we need is the "routing number" address family. If the routing number is present, it is used to check against the TRIP routing table. If it is not present, the POTS number is used to check against the TRIP routing table. Only one TRIP routing table is needed. We only need to use the "correct" number to check against the TRIP routing table if both the routing number and POTS number are present. - For countries such as Austria and Belgium that support NP and concatenate a routing prefix (called network routing number) with the POTS number (e.g., Cxxxx+POTS number in Belgium), it does not matter whether we view this "concatenated number" as a routing number or POTS number if we only use "routing numbers" address family. The TRIP table will contain Cxxxx prefixes and also regular POTS prefixes. So if the called party number does not contain the routing prefix, the POTS routing prefixes are checked for routing. But if it contains the routing prefix such as Cxxxx, the Cxxxx prefixes in the same routing table are checked for routing. The key point is that only one TRIP routing table is needed. - For countries that do not support NP, the POTS numbers can be viewed as the routing numbers. So we still have just one TRIP routing table/address family. Please note that the routing number will not contain digit F that was pointed out by Monika Muench in an earlier e-mail discussion (I'm not sure whether it was posted to iptel or sip discussion list). James James Yu Principal Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue, NW, Suite 550 Washington, D.C. 20005 USA +1-202-533-2814 (B) +1-202-533-2976 (Fax) +1-202-256-1200 (Mobile) james.yu@neustar.com http://www.neustar.com _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Aug 8 09:21:25 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15208 for ; Tue, 8 Aug 2000 09:21:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 774224433B; Tue, 8 Aug 2000 06:34:32 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from multitech.co.in (unknown [202.54.39.98]) by lists.bell-labs.com (Postfix) with ESMTP id A008344338 for ; Tue, 8 Aug 2000 06:34:26 -0400 (EDT) Received: from multitech.co.in [192.168.3.146] by multitech.co.in [202.54.39.98] with SMTP (MDaemon.v3.0.2.R) for ; Tue, 08 Aug 2000 16:05:09 +0530 Message-ID: <398FE0F9.8076D3DE@multitech.co.in> Date: Tue, 08 Aug 2000 15:59:13 +0530 From: Pushparaj Reply-To: pushparaja@multitech.co.in Organization: MTSS X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: en,pdf MIME-Version: 1.0 To: iptel@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-MDaemon-Deliver-To: iptel@lists.bell-labs.com X-Return-Path: pushparaja@multitech.co.in X-MDRcpt-To: iptel@lists.bell-labs.com X-MDRemoteIP: 192.168.3.146 Subject: [IPTEL] PreGrantedArq Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, What is the significance of the PreGrantedArq and OverlappedSending in the RAS messages ? Pushparaj _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Aug 8 20:27:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA25649 for ; Tue, 8 Aug 2000 20:27:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5A21344346; Tue, 8 Aug 2000 20:27:43 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id 2C1F044337 for ; Tue, 8 Aug 2000 20:27:40 -0400 (EDT) Received: from fokus.gmd.de (dhcp007 [195.37.78.135]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id CAA09300 for ; Wed, 9 Aug 2000 02:27:39 +0200 (MET DST) Message-ID: <3990A563.4A1DBAED@fokus.gmd.de> Date: Wed, 09 Aug 2000 02:27:16 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; 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] CPL features Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi, some questions on CPL: 1) making string-switch more general - Why are values of parameter 'field' limited to an enumeration of a couple of well-known elements? Though the advantage of the well-known elements is they may be easily interpreted for different call signaling protocols, I do not see a reason why to prohibit arbitrary values. This would allow CPL script writers to refer to any new fields. - Would not it be helpful to support regular expression matching in addition to 'contains' and 'is'? Example: ... 2) authentication support - Could call processing logic depend on the authentication status? E.g., a CPL script installed at a SIP proxy may want to deny calls from unathenticated users to PSTN. Example:
Jiri _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Aug 8 21:46:38 2000 Received: 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 VAA05084 for ; Tue, 8 Aug 2000 21:46:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 25D364435A; Tue, 8 Aug 2000 21:46:33 -0400 (EDT) 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 7AE7544354 for ; Tue, 8 Aug 2000 21:46:30 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id SAA22525; Tue, 8 Aug 2000 18:46:46 -0700 (PDT) Received: from cisco.com (caryfitz-ncd.cisco.com [171.71.147.145]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AEN07468 (AUTH hsalama); Tue, 8 Aug 2000 18:46:35 -0700 (PDT) Message-ID: <3990B742.C9BB53DA@cisco.com> Date: Tue, 08 Aug 2000 18:43:30 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: James Yu Cc: "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit James, We decided to define two address families, and not just one as your suggesting, for the foloowing reasons: - In order to perform aggregation we need to know when we have all possible next characters. Routing numbers have a different character set than other POTS numbers, and hence the need for defining a dedicated address family for routing numbers. - Other reasons concern the nature of routing numbers: * they don't represent destinations * their scope is limited to national boundaries Regarding the digit 'F' are suggesting that we remove it from the character set of routing numbers, because it will never be used? Hussein James Yu wrote: > > Hussein, > > Section 5.1.1 of TRIP defines two address families, One for POTS numbers and > the other for routing numbers. Since TRIP deals with "routing," it is > suggested that only the "routing numbers" address family is used. This will > avoid the handling of two address families in TRIP for supporting number > portability (NP). The basic rule is: > (1) Use the "routing number" for routing (e.g., check against the TRIP > routing table) if both the "routing number" and "POTS number" are present. > (2) Use the "POTS number" for routing if "routing number" is not present. > > The reasons are described below. > > - For countries such as U.S. and Canada that support NP and use routing > numbers that overlap with the POTS numbers (e.g., the same format and > length), and use the POTS numbers as the routing numbers for non-ported POTS > numbers, the "routing number" address family is sufficient for call routing. > > * For a ported-out number, a location routing number (LRN) is retrieved > from the NP database. That LRN (plus the country code if required) is used > for routing. > * For a non-ported number, that POTS number is used for routing because its > prefix (e.g., the first 6 digits of the national number) can identify the > donor switch that serves this non-ported number. The POTS numbers in this > case are actually treated as the routing numbers! For example, if the POTS > number is 202-533-1234 and is not ported, a LRN of 202-533-0000 can be used > as the LRN for routing the call. Use of "202-533-1234" or "202-533-0000" > does not make any difference because the GSTN switches in the North America > routes national calls based on the first 6 digits of the national POTS > numbers. That is why the POTS numbers are used for routing for non-ported > numbers. > So all we need is the "routing number" address family. If the routing > number is present, it is used to check against the TRIP routing table. If > it is not present, the POTS number is used to check against the TRIP routing > table. Only one TRIP routing table is needed. We only need to use the > "correct" number to check against the TRIP routing table if both the routing > number and POTS number are present. > > - For countries such as Austria and Belgium that support NP and concatenate > a routing prefix (called network routing number) with the POTS number (e.g., > Cxxxx+POTS number in Belgium), it does not matter whether we view this > "concatenated number" as a routing number or POTS number if we only use > "routing numbers" address family. The TRIP table will contain Cxxxx > prefixes and also regular POTS prefixes. So if the called party number does > not contain the routing prefix, the POTS routing prefixes are checked for > routing. But if it contains the routing prefix such as Cxxxx, the Cxxxx > prefixes in the same routing table are checked for routing. The key point > is that only one TRIP routing table is needed. > > - For countries that do not support NP, the POTS numbers can be viewed as > the routing numbers. So we still have just one TRIP routing table/address > family. > > Please note that the routing number will not contain digit F that was > pointed out by Monika Muench in an earlier e-mail discussion (I'm not sure > whether it was posted to iptel or sip discussion list). > > James > > James Yu > Principal Technical Industry Liaison > NeuStar Inc. > 1120 Vermont Avenue, NW, > Suite 550 > Washington, D.C. 20005 > USA > +1-202-533-2814 (B) > +1-202-533-2976 (Fax) > +1-202-256-1200 (Mobile) > james.yu@neustar.com > http://www.neustar.com > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Aug 8 21:57:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10948 for ; Tue, 8 Aug 2000 21:57:10 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3EC234436B; Tue, 8 Aug 2000 21:56:40 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EADDC44369 for ; Tue, 8 Aug 2000 21:56:36 -0400 (EDT) Received: from dynamicsoft.com (1Cust172.tnt8.farmingdale.ny.da.uu.net [63.14.113.172]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id VAA15750; Tue, 8 Aug 2000 21:58:05 -0400 (EDT) Message-ID: <3990BB8F.B7B72FD6@dynamicsoft.com> Date: Tue, 08 Aug 2000 22:01:51 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hsalama@cisco.com Cc: James Yu , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 References: <3990B742.C9BB53DA@cisco.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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Hussein F. Salama" wrote: > > James, > > We decided to define two address families, and not just one as your > suggesting, for the foloowing reasons: > - In order to perform aggregation we need to know when we have all > possible next characters. Routing numbers have a different character set > than other POTS numbers, and hence the need for defining a dedicated > address family for routing numbers. > - Other reasons concern the nature of routing numbers: > * they don't represent destinations > * their scope is limited to national boundaries I agree. Also note that TRIP might be used to represent routes to gateways which don't have ss7 access to the PSTN; they are simply connected through PRI or T1 or whatever. For such gateways, the prefixes to which the gateway can route are limited to only pots numbers, as these are the only ones exposed through these interfaces. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Wed Aug 9 09:54:44 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28380 for ; Wed, 9 Aug 2000 09:54:43 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B7CFA4433E; Wed, 9 Aug 2000 09:54:37 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from tpamail2.bdi.gte.com (tpamail2.bdi.gte.com [192.76.82.136]) by lists.bell-labs.com (Postfix) with ESMTP id EE6D044337 for ; Tue, 8 Aug 2000 15:35:56 -0400 (EDT) Received: from tpamail2.bdi.gte.com (localhost [127.0.0.1]) by tpamail2.bdi.gte.com (8.9.3/8.9.3) with ESMTP id PAA07370 for ; Tue, 8 Aug 2000 15:35:56 -0400 (EDT) Received: from smtptpa.interwan.gte.com ([138.83.66.45]) by tpamail2.bdi.gte.com (8.9.3/8.9.3) with ESMTP id PAA07299; Tue, 8 Aug 2000 15:35:46 -0400 (EDT) From: gary.m.sacra@verizon.com Received: from imr02.bellatlantic.com ([141.152.156.15]) by smtptpa.interwan.gte.com (8.9.3/8.9.3) with ESMTP id PAA08043; Tue, 8 Aug 2000 15:35:40 -0400 (EDT) Received: from fhsmtp03.bell-atl.com (is051952.bellatlantic.com [141.152.101.51]) by imr02.bellatlantic.com (8.8.8/8.8.5) with SMTP id PAA05452; Tue, 8 Aug 2000 15:35:39 -0400 (EDT) Received: by fhsmtp03.bell-atl.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256935.006B9D16 ; Tue, 8 Aug 2000 15:35:25 -0400 X-Lotus-FromDomain: BELL-ATL To: "James Yu" Cc: "'hsalama@cisco.com'" , "'iptel@lists.bell-labs.com'" Message-ID: <85256935.006B9BCF.00@fhsmtp03.bell-atl.com> Date: Tue, 8 Aug 2000 15:42:26 -0400 Subject: Re: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Just to clarify the statement in your second bullet below: For NP in the US, calls to non-ported numbers are not routed via an LRN. They are routed based on the dialed digits. In your example, that would be 202-533-1234. Calls to 202-533-1234 would not route via the switch's LRN of 202-533-0000 because the two numbers are not associated with each other in the NP database since 202-533-1234 is not ported. Only ported numbers are in the database and they require routing via an LRN that is unique to the switch that serves the ported number. Gary Sacra Verizon "James Yu" on 08/04/2000 11:35:37 AM To: "'hsalama@cisco.com'" cc: "'iptel@lists.bell-labs.com'" (bcc: GARY M. SACRA/EMPL/MD/Bell-Atl) Subject: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Hussein, Section 5.1.1 of TRIP defines two address families, One for POTS numbers and the other for routing numbers. Since TRIP deals with "routing," it is suggested that only the "routing numbers" address family is used. This will avoid the handling of two address families in TRIP for supporting number portability (NP). The basic rule is: (1) Use the "routing number" for routing (e.g., check against the TRIP routing table) if both the "routing number" and "POTS number" are present. (2) Use the "POTS number" for routing if "routing number" is not present. The reasons are described below. - For countries such as U.S. and Canada that support NP and use routing numbers that overlap with the POTS numbers (e.g., the same format and length), and use the POTS numbers as the routing numbers for non-ported POTS numbers, the "routing number" address family is sufficient for call routing. * For a ported-out number, a location routing number (LRN) is retrieved from the NP database. That LRN (plus the country code if required) is used for routing. * For a non-ported number, that POTS number is used for routing because its prefix (e.g., the first 6 digits of the national number) can identify the donor switch that serves this non-ported number. The POTS numbers in this case are actually treated as the routing numbers! For example, if the POTS number is 202-533-1234 and is not ported, a LRN of 202-533-0000 can be used as the LRN for routing the call. Use of "202-533-1234" or "202-533-0000" does not make any difference because the GSTN switches in the North America routes national calls based on the first 6 digits of the national POTS numbers. That is why the POTS numbers are used for routing for non-ported numbers. So all we need is the "routing number" address family. If the routing number is present, it is used to check against the TRIP routing table. If it is not present, the POTS number is used to check against the TRIP routing table. Only one TRIP routing table is needed. We only need to use the "correct" number to check against the TRIP routing table if both the routing number and POTS number are present. - For countries such as Austria and Belgium that support NP and concatenate a routing prefix (called network routing number) with the POTS number (e.g., Cxxxx+POTS number in Belgium), it does not matter whether we view this "concatenated number" as a routing number or POTS number if we only use "routing numbers" address family. The TRIP table will contain Cxxxx prefixes and also regular POTS prefixes. So if the called party number does not contain the routing prefix, the POTS routing prefixes are checked for routing. But if it contains the routing prefix such as Cxxxx, the Cxxxx prefixes in the same routing table are checked for routing. The key point is that only one TRIP routing table is needed. - For countries that do not support NP, the POTS numbers can be viewed as the routing numbers. So we still have just one TRIP routing table/address family. Please note that the routing number will not contain digit F that was pointed out by Monika Muench in an earlier e-mail discussion (I'm not sure whether it was posted to iptel or sip discussion list). James James Yu Principal Technical Industry Liaison NeuStar Inc. 1120 Vermont Avenue, NW, Suite 550 Washington, D.C. 20005 USA +1-202-533-2814 (B) +1-202-533-2976 (Fax) +1-202-256-1200 (Mobile) james.yu@neustar.com http://www.neustar.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 Wed Aug 9 10:38:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04169 for ; Wed, 9 Aug 2000 10:38:18 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 27C8144358; Wed, 9 Aug 2000 09:56:12 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ain3.knu.ac.kr (ain3.kyungpook.ac.kr [155.230.12.51]) by lists.bell-labs.com (Postfix) with ESMTP id 544D44433A for ; Wed, 9 Aug 2000 04:01:30 -0400 (EDT) Received: from LocalHost (p13_82.kyungpook.ac.kr [155.230.13.82]) by ain3.knu.ac.kr (8.9.1b+Sun/8.9.1) with SMTP id QAA12499 for ; Wed, 9 Aug 2000 16:54:24 +0900 (KST) Message-ID: <001e01c001d7$c3c296c0$520de69b@LocalHost> From: "ejha" To: Date: Wed, 9 Aug 2000 16:59:37 +0900 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001B_01C00223.33763670" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 Subject: [IPTEL] Question of input queueing model of VoIP Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_001B_01C00223.33763670 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 SGkuLg0KTXkgbmFtZSBpcyBFdW5qdSBIYS4gSSBhbSBncmFkdWF0ZWQgc3R1ZGVudCBpbiBrb3Jl YS4NCk5vd2FkYXlzIEkgc3R1ZHkgb2YgVm9JUCByZXNvdXJjZSBtYW5hZ2VtZW50Lg0KQnV0LCBJ IGRvbid0IGtub3cgdGhlIGV4YWN0IHF1ZXVlaW5nIG1vZGVsIGZvciBDQlIgdHJhZmZpYyBvZiBW b0lQLiAoc29tZSBwYXBlcnMgc2hvdyB0aGF0IHRoZSBhY2N1cmF0ZSBxdWV1ZWluZyBtb2RlbCBm b3IgVm9JUCB0cmFmZmljIGlzIEQvRC8xLi4uLm5NL0cvMS4uLi4pDQpBbnlvbmUga25vd3MgdGhp cywgY291bGQgeW91IHRlYWNoIG1lIHRoZSBxdWV1ZWluZyBtb2RlbCBmb3IgQ0JSIHRyYWZmaWMg b2YgVm9JUD8NCkhlbHAgbWUuLi5wbGVhc2UuLg0KVGhhbmsgeW91Lg0KR29kIGJsZXNzIHlvdS4u DQo= ------=_NextPart_000_001B_01C00223.33763670 Content-Type: text/html; charset="ks_c_5601-1987" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgY29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PWtz X2NfNTYwMS0xOTg3IiBodHRwLWVxdWl2PUNvbnRlbnQtVHlwZT4NCjxNRVRBIGNvbnRlbnQ9Ik1T SFRNTCA1LjAwLjI5MjAuMCIgbmFtZT1HRU5FUkFUT1I+DQo8U1RZTEU+PC9TVFlMRT4NCjwvSEVB RD4NCjxCT0RZIGJnQ29sb3I9I2ZmZmZmZj4NCjxESVY+PEZPTlQgc2l6ZT0yPkhpLi48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj5NeSBuYW1lIGlzIEV1bmp1IEhhLiBJIGFtIGdyYWR1 YXRlZCBzdHVkZW50IGluIA0Ka29yZWEuPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+ Tm93YWRheXMgSSBzdHVkeSBvZiBWb0lQIHJlc291cmNlIG1hbmFnZW1lbnQuPC9GT05UPjwvRElW Pg0KPERJVj48Rk9OVCBzaXplPTI+QnV0LCBJIGRvbid0IGtub3cgdGhlIGV4YWN0IHF1ZXVlaW5n IG1vZGVsIGZvciBDQlIgdHJhZmZpYyBvZiANClZvSVAuIChzb21lIHBhcGVycyBzaG93IHRoYXQg dGhlIGFjY3VyYXRlIHF1ZXVlaW5nIG1vZGVsIGZvciBWb0lQIHRyYWZmaWMgaXMgDQpEL0QvMS4u Li5uTS9HLzEuLi4uKTwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkFueW9uZSBrbm93 cyB0aGlzLCBjb3VsZCB5b3UgdGVhY2ggbWUgdGhlIHF1ZXVlaW5nIG1vZGVsIGZvciANCkNCUiB0 cmFmZmljIG9mIFZvSVA/PC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+SGVscCBtZS4u LnBsZWFzZS4uPC9GT05UPjwvRElWPg0KPERJVj48Rk9OVCBzaXplPTI+VGhhbmsgeW91LjwvRk9O VD48L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPkdvZCBibGVzcyB5b3UuLjwvRk9OVD48L0RJVj48 L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_001B_01C00223.33763670-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Aug 9 11:59:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10573 for ; Wed, 9 Aug 2000 11:59:47 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2167844365; Wed, 9 Aug 2000 11:58:23 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from bbnrel4.net.external.hp.com (bbnrel4.net.external.hp.com [155.208.254.68]) by lists.bell-labs.com (Postfix) with ESMTP id 551A74433E for ; Wed, 9 Aug 2000 11:58:21 -0400 (EDT) Received: from mylos.grenoble.hp.com (mylos.grenoble.hp.com [15.128.130.187]) by bbnrel4.net.external.hp.com (Postfix) with ESMTP id 277E01304E for ; Wed, 9 Aug 2000 17:58:19 +0200 (METDST) Received: from mylos.grenoble.hp.com (labpc9.grenoble.hp.com [15.128.132.193]) by mylos.grenoble.hp.com with ESMTP (8.7.6/8.7.3 SMKit7.02) id RAA11977 for ; Wed, 9 Aug 2000 17:54:58 +0200 (METDST) Message-ID: <39917ED2.E6C9F6D3@mylos.grenoble.hp.com> Date: Wed, 09 Aug 2000 17:54:58 +0200 From: Frederic Huve Organization: Hewlett-Packard ( TID) X-Mailer: Mozilla 4.7 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: IPTEL WG Subject: [IPTEL] Service Routing slides 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Hi all, Could somebody tell me where I can get the Service Routing slide set (last point of the WG agenda). Thanks. -- Frederic HUVE 5,Avenue Raymond Chanas - Eybens R&D Engineer 38053 Grenoble Cedex 9 - FRANCE Telecom Infrastructure Division Tel +33 (0)4 76 14 47 43 Hewlett-Packard Fax +33 (0)4 76 14 14 88 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Aug 9 12:14:16 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11603 for ; Wed, 9 Aug 2000 12:14:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 878294436B; Wed, 9 Aug 2000 12:13:37 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id B8F544434B for ; Wed, 9 Aug 2000 12:13:31 -0400 (EDT) Received: by dnspri.npac.com; id LAA02359; Wed, 9 Aug 2000 11:13:31 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma002302; Wed, 9 Aug 00 11:13:24 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Wed, 9 Aug 2000 11:12:31 -0500 Message-ID: From: James Yu To: "'gary.m.sacra@verizon.com'" Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Date: Wed, 9 Aug 2000 11:10:17 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Gary, If a number is not ported, the ISUP Called Party Number (CdPN) parameter will still contain the POTS number, but the Translated Called Number Indicator (TCNI) bit in the ISUP Forward Call Indicator (FCI) parameter is set to imply that NPDB query has already been performed. This is because the NP database today only contains records assoicated with the ported-out numbers. There are no records in the NP databases (in the U.S. and Canada) for those POTS numbers that are not ported out from the "donor switch," the switch that is allocated a block of numbers (e.g., 202-533-xxxx). The way ISUP routing is designed to support NP is so that switches that need not understand NP are not impacted by NP (e.g., backward compatibility). Those switches always analyze the ISUP CdPN parameter to determine call routing. Today, they analyze the first 6 digits of the "national" CdPN to route the call. James > -----Original Message----- > From: gary.m.sacra@verizon.com [mailto:gary.m.sacra@verizon.com] > Sent: Tuesday, August 08, 2000 3:42 PM > To: James Yu > Cc: 'hsalama@cisco.com'; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > > > Just to clarify the statement in your second bullet below: > > For NP in the US, calls to non-ported numbers are not routed > via an LRN. They > are routed based on the dialed digits. In your example, that would be > 202-533-1234. Calls to 202-533-1234 would not route via the > switch's LRN of > 202-533-0000 because the two numbers are not associated with > each other in the > NP database since 202-533-1234 is not ported. Only ported > numbers are in the > database and they require routing via an LRN that is unique > to the switch that > serves the ported number. > > Gary Sacra > Verizon > > > > > > "James Yu" on 08/04/2000 11:35:37 AM > > > > To: "'hsalama@cisco.com'" > > cc: "'iptel@lists.bell-labs.com'" > (bcc: GARY M. > SACRA/EMPL/MD/Bell-Atl) > > > > Subject: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > > > > > Hussein, > > Section 5.1.1 of TRIP defines two address families, One for > POTS numbers and > the other for routing numbers. Since TRIP deals with "routing," it is > suggested that only the "routing numbers" address family is > used. This will > avoid the handling of two address families in TRIP for > supporting number > portability (NP). The basic rule is: > (1) Use the "routing number" for routing (e.g., check against the TRIP > routing table) if both the "routing number" and "POTS number" > are present. > (2) Use the "POTS number" for routing if "routing number" is > not present. > > The reasons are described below. > > - For countries such as U.S. and Canada that support NP and > use routing > numbers that overlap with the POTS numbers (e.g., the same format and > length), and use the POTS numbers as the routing numbers for > non-ported POTS > numbers, the "routing number" address family is sufficient > for call routing. > > * For a ported-out number, a location routing number (LRN) > is retrieved > from the NP database. That LRN (plus the country code if > required) is used > for routing. > * For a non-ported number, that POTS number is used for > routing because its > prefix (e.g., the first 6 digits of the national number) can > identify the > donor switch that serves this non-ported number. The POTS > numbers in this > case are actually treated as the routing numbers! For > example, if the POTS > number is 202-533-1234 and is not ported, a LRN of > 202-533-0000 can be used > as the LRN for routing the call. Use of "202-533-1234" or > "202-533-0000" > does not make any difference because the GSTN switches in the > North America > routes national calls based on the first 6 digits of the national POTS > numbers. That is why the POTS numbers are used for routing > for non-ported > numbers. > So all we need is the "routing number" address family. If > the routing > number is present, it is used to check against the TRIP > routing table. If > it is not present, the POTS number is used to check against > the TRIP routing > table. Only one TRIP routing table is needed. We only need > to use the > "correct" number to check against the TRIP routing table if > both the routing > number and POTS number are present. > > - For countries such as Austria and Belgium that support NP > and concatenate > a routing prefix (called network routing number) with the > POTS number (e.g., > Cxxxx+POTS number in Belgium), it does not matter whether we view this > "concatenated number" as a routing number or POTS number if > we only use > "routing numbers" address family. The TRIP table will contain Cxxxx > prefixes and also regular POTS prefixes. So if the called > party number does > not contain the routing prefix, the POTS routing prefixes are > checked for > routing. But if it contains the routing prefix such as > Cxxxx, the Cxxxx > prefixes in the same routing table are checked for routing. > The key point > is that only one TRIP routing table is needed. > > - For countries that do not support NP, the POTS numbers can > be viewed as > the routing numbers. So we still have just one TRIP routing > table/address > family. > > > Please note that the routing number will not contain digit F that was > pointed out by Monika Muench in an earlier e-mail discussion > (I'm not sure > whether it was posted to iptel or sip discussion list). > > James > > > James Yu > Principal Technical Industry Liaison > NeuStar Inc. > 1120 Vermont Avenue, NW, > Suite 550 > Washington, D.C. 20005 > USA > +1-202-533-2814 (B) > +1-202-533-2976 (Fax) > +1-202-256-1200 (Mobile) > james.yu@neustar.com > http://www.neustar.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 > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Aug 9 15:44:57 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17885 for ; Wed, 9 Aug 2000 15:44:56 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 992CB44378; Wed, 9 Aug 2000 15:44:22 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id DA84C4433A for ; Wed, 9 Aug 2000 15:44:19 -0400 (EDT) Received: by dnspri.npac.com; id OAA16422; Wed, 9 Aug 2000 14:44:16 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma016251; Wed, 9 Aug 00 14:43:41 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Wed, 9 Aug 2000 14:42:48 -0500 Message-ID: From: James Yu To: "'Jonathan Rosenberg'" , hsalama@cisco.com Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Date: Wed, 9 Aug 2000 14:41:21 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Jonathan, Hussein, I agree that there are two types of numbers or address families that exist in the GSTN and are available to the Internet for routing. My argument is about whether there is a need to broadcast both address families in TRIP. My concern is about the use of the "POTS number" address family when the POTS numbers are in countries that support number portability (NP). Right now, service provider portability (e.g., changing the service provider while keeping the same telephone number) is the only one supported. Many years later, location portability (e.g., changing location while keeping the same telephone number) is likely to be supported at least in some countries such as the U.S. This would mean that many more POTS numbers would be ported at that time. The scheme selected by the U.S. and Canada already supports routing to the correct switch that serves a particular ported-out number. Caller confusion (e.g., charging issue) is the main reason that prevents location portability across rate center boundaries (e.g., different call charges) from being offered. If we try to broadcast the reachability to the POTS numbers in countries that support NP, it may not be realistic to do so. For example, if a switch in the U.S. handles +1-202-533-xxxx but 4,000 numbers in that number range have been ported out, it has to broadcast that it can reach +1-202-533 prefix except for the other 3,000 individual POTS numbers. I'll have no problem to broadcast the reachability of those POTS numbers if there is an "efficient" way to broadcast the information. Also the same switch will have ported-in POTS numbers. It has to broadcast those numbers via TRIP. Also, every porting event, ported-out or ported-in, has to be broadcasted to change the reachability to this POTS number by all the gateways that are impacted by the change. So it is not only the number of records to be broadcasted but also the frequency of changes that concern me if we try to broadcast the reachability of the POTS numbers in NP-capable countries via TRIP. Most routing numbers are national routing numbers, but since Internet may not have national boundaries, we can add the country code to a national routing number so that this international routing number can be used in the Internet unambiguously when the involved IP networks are not in the terminating GSTN. For example, if an IP network in the originating country can retrieve the NP information (many mechanisms may be used depending on what may be available, e.g., it can launch a terminating country's NP TCAP query via sigtran), the received information would be in the terminating country's national format. To use the information over the Internet, it may need to add the terminating country's country code to the national numbers. ITU-T has also allocated specific country codes that allows for identifying "networks" (see E.164 Supplement 2). Those can be viewed as "international" routing numbers. Those international routing numbers won't overlap with those national routing numbers plus their country codes. The connection between the GW and GSTN via PRI or T1 has no implication on TRIP. TRIP's role is to get the call to the GW that can reach the GSTN switch/network that serves a particular POTS number. If the routing number for a ported-out POTS number is available, the routing number will get the call to be routed to the correct GW(s). For a non-ported POTS number or a ported POTS number without the routing number (e.g., networks/countries that support Query on Release, Onward Routing or Dropback scheme where the call is routed to the donor network/switch first), the "routing number" in the TRIP "routing number" table will get the call routed to a GW that can reach the donor network/switch that serves that POTS number. In that case, the POTS number is used as the routing number for routing. So if the TRIP "routing number" table contains the special routing prefixes/numbers that contain digits A through E and the regular POTS number ranges/prefixes assigned to the donor network/switch, there won't be a need to broadcast the "POTS number" address family via TRIP. If the GW is connected to the subscribers directly, I assume that the GW will have a routing number assign to it in the NP-capable environment. The GW will broadcast that routing number and any other number ranges that are assigned to it (e.g., the GW is the donor switch of those number ranges) in TRIP. In a non-NP environment, the number ranges assigned to the GW are broadcasted as "routing numbers" in TRIP. So if a GW can reach N GSTN networks/switches, it will broadcast its reachability to all the POTS number ranges that are assigned to those GSTN networks/switches (e.g., as the donor networks/switches) plus the special routing numbers (e.g., with digits A through E) that are assigned to those GSTN networks/switches. If an IP node has both a routing number and POTS number, it uses the routing number to check against the TRIP "routing number" table to determine the routing. If it only has the POTS number, it uses the POTS number to check against the same TRIP "routing number" table to determine the routing. Certainly, when an IP node only sees the POTS number, it may be provisioned to retrieve the NP related information. After that, it may have the routing number in addition to the POTS number and will use the routing number to check against the TRIP table. James > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, August 08, 2000 10:02 PM > To: hsalama@cisco.com > Cc: James Yu; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > > > "Hussein F. Salama" wrote: > > > > James, > > > > We decided to define two address families, and not just one as your > > suggesting, for the foloowing reasons: > > - In order to perform aggregation we need to know when we have all > > possible next characters. Routing numbers have a different > character set > > than other POTS numbers, and hence the need for defining a dedicated > > address family for routing numbers. > > - Other reasons concern the nature of routing numbers: > > * they don't represent destinations > > * their scope is limited to national boundaries > > I agree. Also note that TRIP might be used to represent routes to > gateways which don't have ss7 access to the PSTN; they are simply > connected through PRI or T1 or whatever. For such gateways, > the prefixes > to which the gateway can route are limited to only pots numbers, as > these are the only ones exposed through these interfaces. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 Wed Aug 9 22:47:29 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26976 for ; Wed, 9 Aug 2000 22:47:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BDDAB4433E; Wed, 9 Aug 2000 22:46:57 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 1392F4433A for ; Wed, 9 Aug 2000 22:46:55 -0400 (EDT) Received: from dynamicsoft.com (1Cust197.tnt9.farmingdale.ny.da.uu.net [63.16.92.197]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id WAA23334; Wed, 9 Aug 2000 22:48:28 -0400 (EDT) Message-ID: <399218E1.1401B713@dynamicsoft.com> Date: Wed, 09 Aug 2000 22:52:17 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Yu Cc: hsalama@cisco.com, "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit James, Your argument is predicated on the fact that the gateway knows the ported numbers and/or routing numbers supported by the switch its connected to. This is simply not going to be the case when the gateways are own by normal folks who simply call up the phone company and get a T1 that they plug into their gateway. In this case, the owner of the gateway will choose routing information for the gateway NOT based on PSTN routing, but rather on cost structures in place for reaching certain numbers from that gateway. Yes, this can lead to triangle routing and all, but if you are a USER of the PSTN, not a LEC, you have no information nor control over PSTN routing. -Jonathan R. James Yu wrote: > > Jonathan, Hussein, > > I agree that there are two types of numbers or address families that exist > in the GSTN and are available to the Internet for routing. My argument is > about whether there is a need to broadcast both address families in TRIP. > My concern is about the use of the "POTS number" address family when the > POTS numbers are in countries that support number portability (NP). Right > now, service provider portability (e.g., changing the service provider while > keeping the same telephone number) is the only one supported. Many years > later, location portability (e.g., changing location while keeping the same > telephone number) is likely to be supported at least in some countries such > as the U.S. This would mean that many more POTS numbers would be ported at > that time. The scheme selected by the U.S. and Canada already supports > routing to the correct switch that serves a particular ported-out number. > Caller confusion (e.g., charging issue) is the main reason that prevents > location portability across rate center boundaries (e.g., different call > charges) from being offered. > > If we try to broadcast the reachability to the POTS numbers in countries > that support NP, it may not be realistic to do so. For example, if a switch > in the U.S. handles +1-202-533-xxxx but 4,000 numbers in that number range > have been ported out, it has to broadcast that it can reach +1-202-533 > prefix except for the other 3,000 individual POTS numbers. I'll have no > problem to broadcast the reachability of those POTS numbers if there is an > "efficient" way to broadcast the information. Also the same switch will > have ported-in POTS numbers. It has to broadcast those numbers via TRIP. > Also, every porting event, ported-out or ported-in, has to be broadcasted to > change the reachability to this POTS number by all the gateways that are > impacted by the change. So it is not only the number of records to be > broadcasted but also the frequency of changes that concern me if we try to > broadcast the reachability of the POTS numbers in NP-capable countries via > TRIP. > > Most routing numbers are national routing numbers, but since Internet may > not have national boundaries, we can add the country code to a national > routing number so that this international routing number can be used in the > Internet unambiguously when the involved IP networks are not in the > terminating GSTN. For example, if an IP network in the originating country > can retrieve the NP information (many mechanisms may be used depending on > what may be available, e.g., it can launch a terminating country's NP TCAP > query via sigtran), the received information would be in the terminating > country's national format. To use the information over the Internet, it may > need to add the terminating country's country code to the national numbers. > > ITU-T has also allocated specific country codes that allows for identifying > "networks" (see E.164 Supplement 2). Those can be viewed as "international" > routing numbers. Those international routing numbers won't overlap with > those national routing numbers plus their country codes. > > The connection between the GW and GSTN via PRI or T1 has no implication on > TRIP. TRIP's role is to get the call to the GW that can reach the GSTN > switch/network that serves a particular POTS number. If the routing number > for a ported-out POTS number is available, the routing number will get the > call to be routed to the correct GW(s). > > For a non-ported POTS number or a ported POTS number without the routing > number (e.g., networks/countries that support Query on Release, Onward > Routing or Dropback scheme where the call is routed to the donor > network/switch first), the "routing number" in the TRIP "routing number" > table will get the call routed to a GW that can reach the donor > network/switch that serves that POTS number. In that case, the POTS number > is used as the routing number for routing. So if the TRIP "routing number" > table contains the special routing prefixes/numbers that contain digits A > through E and the regular POTS number ranges/prefixes assigned to the donor > network/switch, there won't be a need to broadcast the "POTS number" address > family via TRIP. > > If the GW is connected to the subscribers directly, I assume that the GW > will have a routing number assign to it in the NP-capable environment. The > GW will broadcast that routing number and any other number ranges that are > assigned to it (e.g., the GW is the donor switch of those number ranges) in > TRIP. In a non-NP environment, the number ranges assigned to the GW are > broadcasted as "routing numbers" in TRIP. > > So if a GW can reach N GSTN networks/switches, it will broadcast its > reachability to all the POTS number ranges that are assigned to those GSTN > networks/switches (e.g., as the donor networks/switches) plus the special > routing numbers (e.g., with digits A through E) that are assigned to those > GSTN networks/switches. If an IP node has both a routing number and POTS > number, it uses the routing number to check against the TRIP "routing > number" table to determine the routing. If it only has the POTS number, it > uses the POTS number to check against the same TRIP "routing number" table > to determine the routing. Certainly, when an IP node only sees the POTS > number, it may be provisioned to retrieve the NP related information. After > that, it may have the routing number in addition to the POTS number and will > use the routing number to check against the TRIP table. > > James > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Tuesday, August 08, 2000 10:02 PM > > To: hsalama@cisco.com > > Cc: James Yu; 'iptel@lists.bell-labs.com' > > Subject: Re: [IPTEL] [TRIP] Address Families in > > draft-ietf-iptel-trip-03 > > > > > > > > > > "Hussein F. Salama" wrote: > > > > > > James, > > > > > > We decided to define two address families, and not just one as your > > > suggesting, for the foloowing reasons: > > > - In order to perform aggregation we need to know when we have all > > > possible next characters. Routing numbers have a different > > character set > > > than other POTS numbers, and hence the need for defining a dedicated > > > address family for routing numbers. > > > - Other reasons concern the nature of routing numbers: > > > * they don't represent destinations > > > * their scope is limited to national boundaries > > > > I agree. Also note that TRIP might be used to represent routes to > > gateways which don't have ss7 access to the PSTN; they are simply > > connected through PRI or T1 or whatever. For such gateways, > > the prefixes > > to which the gateway can route are limited to only pots numbers, as > > these are the only ones exposed through these interfaces. > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Thu Aug 10 02:21:36 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA11661 for ; Thu, 10 Aug 2000 02:21:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id CF08C44357; Thu, 10 Aug 2000 02:21:11 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from june.Broomfield1.level3.net (june.Broomfield1.Level3.net [209.245.18.7]) by lists.bell-labs.com (Postfix) with ESMTP id 9877744338 for ; Thu, 10 Aug 2000 02:21:06 -0400 (EDT) Received: from f1ee40-19.idc1.level3.com (hme0.f1ee40-19.idc1.oss.level3.com [10.1.144.204]) by june.Broomfield1.level3.net (8.9.3/8.9.3) with ESMTP id GAA21247; Thu, 10 Aug 2000 06:21:05 GMT From: Jon.Peterson@Level3.com Received: from n0195idc1.oss.level3.com (localhost [127.0.0.1]) by f1ee40-19.idc1.level3.com (8.8.8+Sun/8.8.8) with ESMTP id AAA17790; Thu, 10 Aug 2000 00:21:05 -0600 (MDT) Received: by n0195idc1.oss.level3.com with Internet Mail Service (5.5.2650.21) id ; Thu, 10 Aug 2000 00:22:49 -0600 Message-ID: <87A245E94948D3118DE30008C716B01301523AB2@c0005v1idc1.oss.level3.com> To: james.yu@neustar.com, jdrosen@dynamicsoft.com, hsalama@cisco.com Cc: iptel@lists.bell-labs.com Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Date: Thu, 10 Aug 2000 00:21:03 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a really confusing issue, but I think I agree with Mr. Yu that only one address family is necessary for telephone-number based routing. Firstly, I suppose nothing prevents a network administrator from using only the "routing number" TRIP address family for both POTS numbers and LRNs; after all, "routing number" seems to be a superset of "POTS number", and these guys provision the GWs that are the roots of propagated routes. I take some exception to the notion that an LRN does not represent a destination. It represents the machine that is the ultimate destination of signaling; I don't think that it should be excluded because it does not represent a subscriber - one might similarly exclude TRIP for service logic. I also do not think that a GWs relationship to this sort of address is substantially different from that of a 'POTS' address - either address is passed in a PSTN call-setup message to a switch that the gateway faces. As Mr. Yu pointed out, it wouldn't be terribly difficult to internationalize "routed numbers" - and in fact, doing so might facilitate aggregation (especially if one is willing to allow the somewhat distasteful notion of allowing different aggregation rules to be associated with different national prefixes - which in practice might not be terrible to implement). Dave Walker's recent proposal for using Carrier ID Codes in TRIP similarly suggested an internationalizing prefix. Finally, I think that the specifics of the VoIP signaling protocol used to set up calls might make some options here more attractive than others. If the VoIP protocol effectively distinguishes between the CPN and the LRN (which I think it must if it hopes to map to SS7), and separate TRIP address families are used for each, then it isn't obvious to me why, as an SS7 GW operator, I would not have to propagate the same set of routes for both address families. Jon Peterson Level(3) Communications -----Original Message----- From: James Yu [mailto:james.yu@neustar.com] Sent: Wednesday, August 09, 2000 1:41 PM To: 'Jonathan Rosenberg'; hsalama@cisco.com Cc: 'iptel@lists.bell-labs.com' Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Jonathan, Hussein, I agree that there are two types of numbers or address families that exist in the GSTN and are available to the Internet for routing. My argument is about whether there is a need to broadcast both address families in TRIP. My concern is about the use of the "POTS number" address family when the POTS numbers are in countries that support number portability (NP). Right now, service provider portability (e.g., changing the service provider while keeping the same telephone number) is the only one supported. Many years later, location portability (e.g., changing location while keeping the same telephone number) is likely to be supported at least in some countries such as the U.S. This would mean that many more POTS numbers would be ported at that time. The scheme selected by the U.S. and Canada already supports routing to the correct switch that serves a particular ported-out number. Caller confusion (e.g., charging issue) is the main reason that prevents location portability across rate center boundaries (e.g., different call charges) from being offered. If we try to broadcast the reachability to the POTS numbers in countries that support NP, it may not be realistic to do so. For example, if a switch in the U.S. handles +1-202-533-xxxx but 4,000 numbers in that number range have been ported out, it has to broadcast that it can reach +1-202-533 prefix except for the other 3,000 individual POTS numbers. I'll have no problem to broadcast the reachability of those POTS numbers if there is an "efficient" way to broadcast the information. Also the same switch will have ported-in POTS numbers. It has to broadcast those numbers via TRIP. Also, every porting event, ported-out or ported-in, has to be broadcasted to change the reachability to this POTS number by all the gateways that are impacted by the change. So it is not only the number of records to be broadcasted but also the frequency of changes that concern me if we try to broadcast the reachability of the POTS numbers in NP-capable countries via TRIP. Most routing numbers are national routing numbers, but since Internet may not have national boundaries, we can add the country code to a national routing number so that this international routing number can be used in the Internet unambiguously when the involved IP networks are not in the terminating GSTN. For example, if an IP network in the originating country can retrieve the NP information (many mechanisms may be used depending on what may be available, e.g., it can launch a terminating country's NP TCAP query via sigtran), the received information would be in the terminating country's national format. To use the information over the Internet, it may need to add the terminating country's country code to the national numbers. ITU-T has also allocated specific country codes that allows for identifying "networks" (see E.164 Supplement 2). Those can be viewed as "international" routing numbers. Those international routing numbers won't overlap with those national routing numbers plus their country codes. The connection between the GW and GSTN via PRI or T1 has no implication on TRIP. TRIP's role is to get the call to the GW that can reach the GSTN switch/network that serves a particular POTS number. If the routing number for a ported-out POTS number is available, the routing number will get the call to be routed to the correct GW(s). For a non-ported POTS number or a ported POTS number without the routing number (e.g., networks/countries that support Query on Release, Onward Routing or Dropback scheme where the call is routed to the donor network/switch first), the "routing number" in the TRIP "routing number" table will get the call routed to a GW that can reach the donor network/switch that serves that POTS number. In that case, the POTS number is used as the routing number for routing. So if the TRIP "routing number" table contains the special routing prefixes/numbers that contain digits A through E and the regular POTS number ranges/prefixes assigned to the donor network/switch, there won't be a need to broadcast the "POTS number" address family via TRIP. If the GW is connected to the subscribers directly, I assume that the GW will have a routing number assign to it in the NP-capable environment. The GW will broadcast that routing number and any other number ranges that are assigned to it (e.g., the GW is the donor switch of those number ranges) in TRIP. In a non-NP environment, the number ranges assigned to the GW are broadcasted as "routing numbers" in TRIP. So if a GW can reach N GSTN networks/switches, it will broadcast its reachability to all the POTS number ranges that are assigned to those GSTN networks/switches (e.g., as the donor networks/switches) plus the special routing numbers (e.g., with digits A through E) that are assigned to those GSTN networks/switches. If an IP node has both a routing number and POTS number, it uses the routing number to check against the TRIP "routing number" table to determine the routing. If it only has the POTS number, it uses the POTS number to check against the same TRIP "routing number" table to determine the routing. Certainly, when an IP node only sees the POTS number, it may be provisioned to retrieve the NP related information. After that, it may have the routing number in addition to the POTS number and will use the routing number to check against the TRIP table. James > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Tuesday, August 08, 2000 10:02 PM > To: hsalama@cisco.com > Cc: James Yu; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > > > "Hussein F. Salama" wrote: > > > > James, > > > > We decided to define two address families, and not just one as your > > suggesting, for the foloowing reasons: > > - In order to perform aggregation we need to know when we have all > > possible next characters. Routing numbers have a different > character set > > than other POTS numbers, and hence the need for defining a dedicated > > address family for routing numbers. > > - Other reasons concern the nature of routing numbers: > > * they don't represent destinations > > * their scope is limited to national boundaries > > I agree. Also note that TRIP might be used to represent routes to > gateways which don't have ss7 access to the PSTN; they are simply > connected through PRI or T1 or whatever. For such gateways, > the prefixes > to which the gateway can route are limited to only pots numbers, as > these are the only ones exposed through these interfaces. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 Thu Aug 10 09:53:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA22914 for ; Thu, 10 Aug 2000 09:53:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 279BA44350; Thu, 10 Aug 2000 09:53:21 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 4C32B44338 for ; Thu, 10 Aug 2000 09:53:18 -0400 (EDT) Received: by dnspri.npac.com; id IAA19313; Thu, 10 Aug 2000 08:53:17 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma019232; Thu, 10 Aug 00 08:53:03 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Aug 2000 08:52:10 -0500 Message-ID: From: James Yu To: "'Jonathan Rosenberg'" Cc: hsalama@cisco.com, "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Date: Thu, 10 Aug 2000 08:50:43 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Jonathan, In the example you gave, the gateway can still announce that it can reach the range of numbers that the user has as "routing numbers." If the call to the user is received at the gateway, it then knows that it has a direct T1 trunk to the user which is a more direct route than the one going through the PSTN. But if that T1 trunk fails, it can set the routing to route the call through the PSTN. Certainly, some other gateways may get the call and route the call through the PSTN to the user. So if the users owns/controls +1-202-533-0000 to +1-202-533-0999, the gateway that the user has direct T1 trunk connection with can advertise that it can reach +1-202-533-0 in addition to others as "routing numbers." If those POTS numbers are not ported, this particular gateway may receive the calls to the user ("may" indicates that other gateways may receive some calls because they can reach those "routing numbers"). If those POTS numbers are ported and if the IP networks do not have the NP routing information (e.g., LRN in the U.S. and Canada), this particular gateway may receive the calls to the user just like the previous case. But if those POTS numbers are ported and if the IP networks do have the NP routing information, I do see one extra effort by the gateway - to get and announce the additional "routing number" of the PSTN switch/network that serves this users' POTS numbers in addition to +1-202-533-0 and others This is to ensure that this gateway an receive calls to the user when routing number for NP is available to the IP networks. But this is considered a minor effort comparing to the effort of announcing the POTS number address family via TRIP. When NP is involved, if we only use one address family, the "routing number" table will get the call routed to the correct gateways whether both routing number and POTS number are present or just POTS number is present. But if both address families are used, there must be a rule about which number has the precedence if both routing number and POTS number are present. If only the POTS number is present, I assume that the rule must be to use the "POTS number" table for routing. This will force "POTS numbers" be announced even if "routing number" table is sufficient for routing. James > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Wednesday, August 09, 2000 10:52 PM > To: James Yu > Cc: hsalama@cisco.com; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > James, > > Your argument is predicated on the fact that the gateway knows the > ported numbers > and/or routing numbers supported by the switch its connected > to. This is > simply > not going to be the case when the gateways are own by normal folks who > simply call > up the phone company and get a T1 that they plug into their > gateway. In > this case, > the owner of the gateway will choose routing information for > the gateway > NOT based > on PSTN routing, but rather on cost structures in place for reaching > certain numbers > from that gateway. > > Yes, this can lead to triangle routing and all, but if you > are a USER of > the PSTN, not > a LEC, you have no information nor control over PSTN routing. > > -Jonathan R. > > James Yu wrote: > > > > Jonathan, Hussein, > > > > I agree that there are two types of numbers or address > families that exist > > in the GSTN and are available to the Internet for routing. > My argument is > > about whether there is a need to broadcast both address > families in TRIP. > > My concern is about the use of the "POTS number" address > family when the > > POTS numbers are in countries that support number > portability (NP). Right > > now, service provider portability (e.g., changing the > service provider while > > keeping the same telephone number) is the only one > supported. Many years > > later, location portability (e.g., changing location while > keeping the same > > telephone number) is likely to be supported at least in > some countries such > > as the U.S. This would mean that many more POTS numbers > would be ported at > > that time. The scheme selected by the U.S. and Canada > already supports > > routing to the correct switch that serves a particular > ported-out number. > > Caller confusion (e.g., charging issue) is the main reason > that prevents > > location portability across rate center boundaries (e.g., > different call > > charges) from being offered. > > > > If we try to broadcast the reachability to the POTS numbers > in countries > > that support NP, it may not be realistic to do so. For > example, if a switch > > in the U.S. handles +1-202-533-xxxx but 4,000 numbers in > that number range > > have been ported out, it has to broadcast that it can reach > +1-202-533 > > prefix except for the other 3,000 individual POTS numbers. > I'll have no > > problem to broadcast the reachability of those POTS numbers > if there is an > > "efficient" way to broadcast the information. Also the > same switch will > > have ported-in POTS numbers. It has to broadcast those > numbers via TRIP. > > Also, every porting event, ported-out or ported-in, has to > be broadcasted to > > change the reachability to this POTS number by all the > gateways that are > > impacted by the change. So it is not only the number of > records to be > > broadcasted but also the frequency of changes that concern > me if we try to > > broadcast the reachability of the POTS numbers in > NP-capable countries via > > TRIP. > > > > Most routing numbers are national routing numbers, but > since Internet may > > not have national boundaries, we can add the country code > to a national > > routing number so that this international routing number > can be used in the > > Internet unambiguously when the involved IP networks are not in the > > terminating GSTN. For example, if an IP network in the > originating country > > can retrieve the NP information (many mechanisms may be > used depending on > > what may be available, e.g., it can launch a terminating > country's NP TCAP > > query via sigtran), the received information would be in > the terminating > > country's national format. To use the information over the > Internet, it may > > need to add the terminating country's country code to the > national numbers. > > > > ITU-T has also allocated specific country codes that allows > for identifying > > "networks" (see E.164 Supplement 2). Those can be viewed > as "international" > > routing numbers. Those international routing numbers won't > overlap with > > those national routing numbers plus their country codes. > > > > The connection between the GW and GSTN via PRI or T1 has no > implication on > > TRIP. TRIP's role is to get the call to the GW that can > reach the GSTN > > switch/network that serves a particular POTS number. If > the routing number > > for a ported-out POTS number is available, the routing > number will get the > > call to be routed to the correct GW(s). > > > > For a non-ported POTS number or a ported POTS number > without the routing > > number (e.g., networks/countries that support Query on > Release, Onward > > Routing or Dropback scheme where the call is routed to the donor > > network/switch first), the "routing number" in the TRIP > "routing number" > > table will get the call routed to a GW that can reach the donor > > network/switch that serves that POTS number. In that case, > the POTS number > > is used as the routing number for routing. So if the TRIP > "routing number" > > table contains the special routing prefixes/numbers that > contain digits A > > through E and the regular POTS number ranges/prefixes > assigned to the donor > > network/switch, there won't be a need to broadcast the > "POTS number" address > > family via TRIP. > > > > If the GW is connected to the subscribers directly, I > assume that the GW > > will have a routing number assign to it in the NP-capable > environment. The > > GW will broadcast that routing number and any other number > ranges that are > > assigned to it (e.g., the GW is the donor switch of those > number ranges) in > > TRIP. In a non-NP environment, the number ranges assigned > to the GW are > > broadcasted as "routing numbers" in TRIP. > > > > So if a GW can reach N GSTN networks/switches, it will broadcast its > > reachability to all the POTS number ranges that are > assigned to those GSTN > > networks/switches (e.g., as the donor networks/switches) > plus the special > > routing numbers (e.g., with digits A through E) that are > assigned to those > > GSTN networks/switches. If an IP node has both a routing > number and POTS > > number, it uses the routing number to check against the > TRIP "routing > > number" table to determine the routing. If it only has the > POTS number, it > > uses the POTS number to check against the same TRIP > "routing number" table > > to determine the routing. Certainly, when an IP node only > sees the POTS > > number, it may be provisioned to retrieve the NP related > information. After > > that, it may have the routing number in addition to the > POTS number and will > > use the routing number to check against the TRIP table. > > > > James > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Tuesday, August 08, 2000 10:02 PM > > > To: hsalama@cisco.com > > > Cc: James Yu; 'iptel@lists.bell-labs.com' > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > "Hussein F. Salama" wrote: > > > > > > > > James, > > > > > > > > We decided to define two address families, and not just > one as your > > > > suggesting, for the foloowing reasons: > > > > - In order to perform aggregation we need to know when > we have all > > > > possible next characters. Routing numbers have a different > > > character set > > > > than other POTS numbers, and hence the need for > defining a dedicated > > > > address family for routing numbers. > > > > - Other reasons concern the nature of routing numbers: > > > > * they don't represent destinations > > > > * their scope is limited to national boundaries > > > > > > I agree. Also note that TRIP might be used to represent routes to > > > gateways which don't have ss7 access to the PSTN; they are simply > > > connected through PRI or T1 or whatever. For such gateways, > > > the prefixes > > > to which the gateway can route are limited to only pots > numbers, as > > > these are the only ones exposed through these interfaces. > > > > > > -Jonathan R. > > > > > > -- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > > http://www.dynamicsoft.com > > > > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 Thu Aug 10 12:32:17 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA04083 for ; Thu, 10 Aug 2000 12:32:17 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id ABBB94438E; Thu, 10 Aug 2000 12:31:23 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 0832D44338 for ; Thu, 10 Aug 2000 12:31:20 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id JAA00032; Thu, 10 Aug 2000 09:31:36 -0700 (PDT) Received: from cisco.com ([10.19.104.245]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AEQ08325 (AUTH hsalama); Thu, 10 Aug 2000 09:31:24 -0700 (PDT) Message-ID: <3992D821.966EA7E7@cisco.com> Date: Thu, 10 Aug 2000 09:28:17 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: James Yu Cc: "'Jonathan Rosenberg'" , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Yu wrote: > > Jonathan, > > In the example you gave, the gateway can still announce that it can reach > the range of numbers that the user has as "routing numbers." If the call to > the user is received at the gateway, it then knows that it has a direct T1 > trunk to the user which is a more direct route than the one going through > the PSTN. But if that T1 trunk fails, it can set the routing to route the > call through the PSTN. Certainly, some other gateways may get the call and > route the call through the PSTN to the user. So if the users owns/controls > +1-202-533-0000 to +1-202-533-0999, the gateway that the user has direct T1 > trunk connection with can advertise that it can reach +1-202-533-0 in > addition to others as "routing numbers." If those POTS numbers are not > ported, this particular gateway may receive the calls to the user ("may" > indicates that other gateways may receive some calls because they can reach > those "routing numbers"). If those POTS numbers are ported and if the IP > networks do not have the NP routing information (e.g., LRN in the U.S. and > Canada), this particular gateway may receive the calls to the user just like > the previous case. But if those POTS numbers are ported and if the IP > networks do have the NP routing information, I do see one extra effort by > the gateway - to get and announce the additional "routing number" of the > PSTN switch/network that serves this users' POTS numbers in addition to > +1-202-533-0 and others This is to ensure that this gateway an receive > calls to the user when routing number for NP is available to the IP > networks. But this is considered a minor effort comparing to the effort of > announcing the POTS number address family via TRIP. > > When NP is involved, if we only use one address family, the "routing number" > table will get the call routed to the correct gateways whether both routing > number and POTS number are present or just POTS number is present. But if > both address families are used, there must be a rule about which number has > the precedence if both routing number and POTS number are present. The rule is: - If the destination number is a ported number, and NPDB lookup has already occured. In this case, we have both the LRN and the destination POTS number. In this case the intermediate signaling server should route the call using the LRN. The intermediate signaling server should specify "address family = routing number" when it queries TRIP for a route to the given LRN. TRIP then searches only those routes with address family = routing number. - If destinatination is not a ported number, or if it is a ported number, but NPDB lookup hasn't occured yet (because e.g. the signaling servers traversed so far do not have access to the appropriate NPDB). In this case, the intermediate signaling server should route the call using the destination number. The intermediate signaling server should specify "address family = POTS number" when it queries TRIP for a route to the given destination. TRIP then searches only those routes with address family = POTS number. My main concern about using a single address family is still the difficulty of aggregation, because of different alphabets. If we define a single address family with the alphabet {'1' .. '9', 'A' .. 'F'}, automatic aggregation will not be easy. For example it will never happen in the US. For example, a TRIP LS receives the following routes: 202530*, 202531*, 202532*, 202533*, ...., 202539* The LS will not aggregate these routes into 20253*, becasue it has not received 20253A*, 20253B*, ..., 20253F*, which do not exist. Hussein _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Aug 10 22:43:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21245 for ; Thu, 10 Aug 2000 22:43:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7AB5E4439D; Thu, 10 Aug 2000 22:42:59 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id D772A44338 for ; Thu, 10 Aug 2000 22:42:56 -0400 (EDT) Received: by dnspri.npac.com; id VAA05518; Thu, 10 Aug 2000 21:42:56 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma005504; Thu, 10 Aug 00 21:42:39 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Thu, 10 Aug 2000 21:41:45 -0500 Message-ID: From: James Yu To: "'hsalama@cisco.com'" Cc: "'Jonathan Rosenberg'" , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Date: Thu, 10 Aug 2000 21:40:11 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Hussein, As indicated earlier, the "POTS number" address family is a subset of "routing number" address family (not in terms of the numbers but in terms of allowable digits). Aggregation needs to be done for the "routing numbers" anyway if digits A through E may appear in the routing numbers. So you are not totally avoiding the problem. If you need to aggregate for the routing numbers and one "routing number" table can do the work, why announcing the additional "POTS numbers" and managing an additional "POTS number table at the LSs just because it is easier to aggregate that address family (this is an "extra" work). Under country code 1, digits A through E are not used. It is then easy to aggregate the "routing numbers" under country code 1. James > -----Original Message----- > From: Hussein F. Salama [mailto:hsalama@cisco.com] > Sent: Thursday, August 10, 2000 12:28 PM > To: James Yu > Cc: 'Jonathan Rosenberg'; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > > > James Yu wrote: > > > > Jonathan, > > > > In the example you gave, the gateway can still announce > that it can reach > > the range of numbers that the user has as "routing > numbers." If the call to > > the user is received at the gateway, it then knows that it > has a direct T1 > > trunk to the user which is a more direct route than the one > going through > > the PSTN. But if that T1 trunk fails, it can set the > routing to route the > > call through the PSTN. Certainly, some other gateways may > get the call and > > route the call through the PSTN to the user. So if the > users owns/controls > > +1-202-533-0000 to +1-202-533-0999, the gateway that the > user has direct T1 > > trunk connection with can advertise that it can reach > +1-202-533-0 in > > addition to others as "routing numbers." If those POTS > numbers are not > > ported, this particular gateway may receive the calls to > the user ("may" > > indicates that other gateways may receive some calls > because they can reach > > those "routing numbers"). If those POTS numbers are ported > and if the IP > > networks do not have the NP routing information (e.g., LRN > in the U.S. and > > Canada), this particular gateway may receive the calls to > the user just like > > the previous case. But if those POTS numbers are ported > and if the IP > > networks do have the NP routing information, I do see one > extra effort by > > the gateway - to get and announce the additional "routing > number" of the > > PSTN switch/network that serves this users' POTS numbers in > addition to > > +1-202-533-0 and others This is to ensure that this > gateway an receive > > calls to the user when routing number for NP is available to the IP > > networks. But this is considered a minor effort comparing > to the effort of > > announcing the POTS number address family via TRIP. > > > > When NP is involved, if we only use one address family, the > "routing number" > > table will get the call routed to the correct gateways > whether both routing > > number and POTS number are present or just POTS number is > present. But if > > both address families are used, there must be a rule about > which number has > > the precedence if both routing number and POTS number are present. > > The rule is: > - If the destination number is a ported number, and NPDB lookup has > already occured. In this case, we have both the LRN and the > destination > POTS number. In this case the intermediate signaling server > should route > the call using the LRN. The intermediate signaling server > should specify > "address family = routing number" when it queries TRIP for a route to > the given LRN. TRIP then searches only those routes with > address family > = routing number. > - If destinatination is not a ported number, or if it is a ported > number, but NPDB lookup hasn't occured yet (because e.g. the signaling > servers traversed so far do not have access to the > appropriate NPDB). In > this case, the intermediate signaling server should route the > call using > the destination number. The intermediate signaling server > should specify > "address family = POTS number" when it queries TRIP for a route to the > given destination. TRIP then searches only those routes with address > family = POTS number. > > My main concern about using a single address family is still the > difficulty of aggregation, because of different alphabets. If > we define > a single address family with the alphabet {'1' .. '9', 'A' .. 'F'}, > automatic aggregation will not be easy. For example it will > never happen > in the US. For example, a TRIP LS receives the following routes: > 202530*, 202531*, 202532*, 202533*, ...., 202539* > The LS will not aggregate these routes into 20253*, becasue it has not > received 20253A*, 20253B*, ..., 20253F*, which do not exist. > > Hussein > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Aug 11 04:14:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07192 for ; Fri, 11 Aug 2000 04:14:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F17514434E; Fri, 11 Aug 2000 04:13:55 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id B047B44338 for ; Fri, 11 Aug 2000 04:13:52 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id BAA21984; Fri, 11 Aug 2000 01:14:09 -0700 (PDT) Received: from cisco.com ([10.19.104.245]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AEQ17912 (AUTH hsalama); Fri, 11 Aug 2000 01:13:58 -0700 (PDT) Message-ID: <3993B50B.1B641508@cisco.com> Date: Fri, 11 Aug 2000 01:10:51 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: James Yu Cc: "'Jonathan Rosenberg'" , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit James, James Yu wrote: > > Hussein, > > As indicated earlier, the "POTS number" address family is a subset of > "routing number" address family (not in terms of the numbers but in terms of > allowable digits). Aggregation needs to be done for the "routing numbers" > anyway if digits A through E may appear in the routing numbers. So you are > not totally avoiding the problem. If you need to aggregate for the routing > numbers and one "routing number" table can do the work, why announcing the > additional "POTS numbers" and managing an additional "POTS number table at > the LSs just because it is easier to aggregate that address family (this is > an "extra" work). Under country code 1, digits A through E are not used. > It is then easy to aggregate the "routing numbers" under country code 1. I prefer having two separate address families to having a single address family with two, or may be more, sets of aggregation rules. Deciding which set of aggregation rules to use based on the first digit of the prefix is too restrictive. For example, I can imagine TRIP applications, with limited scope, local or national, which advertise numbers without prepending the country code to them. Hence we won't have the '1' to decide which aggregation rules to use? Hussein > > James > > > -----Original Message----- > > From: Hussein F. Salama [mailto:hsalama@cisco.com] > > Sent: Thursday, August 10, 2000 12:28 PM > > To: James Yu > > Cc: 'Jonathan Rosenberg'; 'iptel@lists.bell-labs.com' > > Subject: Re: [IPTEL] [TRIP] Address Families in > > draft-ietf-iptel-trip-03 > > > > > > > > > > James Yu wrote: > > > > > > Jonathan, > > > > > > In the example you gave, the gateway can still announce > > that it can reach > > > the range of numbers that the user has as "routing > > numbers." If the call to > > > the user is received at the gateway, it then knows that it > > has a direct T1 > > > trunk to the user which is a more direct route than the one > > going through > > > the PSTN. But if that T1 trunk fails, it can set the > > routing to route the > > > call through the PSTN. Certainly, some other gateways may > > get the call and > > > route the call through the PSTN to the user. So if the > > users owns/controls > > > +1-202-533-0000 to +1-202-533-0999, the gateway that the > > user has direct T1 > > > trunk connection with can advertise that it can reach > > +1-202-533-0 in > > > addition to others as "routing numbers." If those POTS > > numbers are not > > > ported, this particular gateway may receive the calls to > > the user ("may" > > > indicates that other gateways may receive some calls > > because they can reach > > > those "routing numbers"). If those POTS numbers are ported > > and if the IP > > > networks do not have the NP routing information (e.g., LRN > > in the U.S. and > > > Canada), this particular gateway may receive the calls to > > the user just like > > > the previous case. But if those POTS numbers are ported > > and if the IP > > > networks do have the NP routing information, I do see one > > extra effort by > > > the gateway - to get and announce the additional "routing > > number" of the > > > PSTN switch/network that serves this users' POTS numbers in > > addition to > > > +1-202-533-0 and others This is to ensure that this > > gateway an receive > > > calls to the user when routing number for NP is available to the IP > > > networks. But this is considered a minor effort comparing > > to the effort of > > > announcing the POTS number address family via TRIP. > > > > > > When NP is involved, if we only use one address family, the > > "routing number" > > > table will get the call routed to the correct gateways > > whether both routing > > > number and POTS number are present or just POTS number is > > present. But if > > > both address families are used, there must be a rule about > > which number has > > > the precedence if both routing number and POTS number are present. > > > > The rule is: > > - If the destination number is a ported number, and NPDB lookup has > > already occured. In this case, we have both the LRN and the > > destination > > POTS number. In this case the intermediate signaling server > > should route > > the call using the LRN. The intermediate signaling server > > should specify > > "address family = routing number" when it queries TRIP for a route to > > the given LRN. TRIP then searches only those routes with > > address family > > = routing number. > > - If destinatination is not a ported number, or if it is a ported > > number, but NPDB lookup hasn't occured yet (because e.g. the signaling > > servers traversed so far do not have access to the > > appropriate NPDB). In > > this case, the intermediate signaling server should route the > > call using > > the destination number. The intermediate signaling server > > should specify > > "address family = POTS number" when it queries TRIP for a route to the > > given destination. TRIP then searches only those routes with address > > family = POTS number. > > > > My main concern about using a single address family is still the > > difficulty of aggregation, because of different alphabets. If > > we define > > a single address family with the alphabet {'1' .. '9', 'A' .. 'F'}, > > automatic aggregation will not be easy. For example it will > > never happen > > in the US. For example, a TRIP LS receives the following routes: > > 202530*, 202531*, 202532*, 202533*, ...., 202539* > > The LS will not aggregate these routes into 20253*, becasue it has not > > received 20253A*, 20253B*, ..., 20253F*, which do not exist. > > > > Hussein > > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Aug 11 08:26:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11670 for ; Fri, 11 Aug 2000 08:26:54 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2C81B4434A; Fri, 11 Aug 2000 08:26:08 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from irvmail2.bdi.gte.com (irvmail2.bdi.gte.com [192.76.80.130]) by lists.bell-labs.com (Postfix) with ESMTP id 9B39C44338 for ; Thu, 10 Aug 2000 18:08:43 -0400 (EDT) Received: from irvmail2.bdi.gte.com (localhost [127.0.0.1]) by irvmail2.bdi.gte.com (8.9.3/8.9.3) with ESMTP id RAA21530 for ; Thu, 10 Aug 2000 17:08:28 -0500 (EST) Received: from smtpftw.interwan.gte.com ([138.83.130.53]) by irvmail2.bdi.gte.com (8.9.3/8.9.3) with ESMTP id RAA21515; Thu, 10 Aug 2000 17:08:27 -0500 (EST) From: gary.m.sacra@verizon.com Received: from smtpftw.interwan.gte.com (localhost [127.0.0.1]) by smtpftw.interwan.gte.com (8.9.3/8.9.3) with ESMTP id RAA22420; Thu, 10 Aug 2000 17:08:25 -0500 (EST) Received: from imr01.bellatlantic.com ([141.152.156.12]) by smtpftw.interwan.gte.com (8.9.3/8.9.3) with ESMTP id RAA22412; Thu, 10 Aug 2000 17:08:24 -0500 (EST) Received: from fhsmtp03.bell-atl.com (is051952.bellatlantic.com [141.152.101.51]) by imr01.bellatlantic.com (8.8.8/8.8.5) with SMTP id SAA25185; Thu, 10 Aug 2000 18:08:23 -0400 (EDT) Received: by fhsmtp03.bell-atl.com(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id 85256937.0079967F ; Thu, 10 Aug 2000 18:08:03 -0400 X-Lotus-FromDomain: BELL-ATL To: "James Yu" Cc: "'iptel@lists.bell-labs.com'" Message-ID: <85256937.007994A1.00@fhsmtp03.bell-atl.com> Date: Thu, 10 Aug 2000 18:15:09 -0400 Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com James, Perhaps I misinterpreted your statement in your second bullet below, extracted here: "For example, if the POTS number is 202-533-1234 and is not ported, a LRN of 202-533-0000 can be used as the LRN for routing the call." It appeared to me you were saying that an LRN would be used to route a call to a non-ported number. Thanks, Gary "James Yu" on 08/09/2000 12:10:17 PM To: "'gary.m.sacra@verizon.com'" cc: "'iptel@lists.bell-labs.com'" (bcc: GARY M. SACRA/EMPL/MD/Bell-Atl) Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Gary, If a number is not ported, the ISUP Called Party Number (CdPN) parameter will still contain the POTS number, but the Translated Called Number Indicator (TCNI) bit in the ISUP Forward Call Indicator (FCI) parameter is set to imply that NPDB query has already been performed. This is because the NP database today only contains records assoicated with the ported-out numbers. There are no records in the NP databases (in the U.S. and Canada) for those POTS numbers that are not ported out from the "donor switch," the switch that is allocated a block of numbers (e.g., 202-533-xxxx). The way ISUP routing is designed to support NP is so that switches that need not understand NP are not impacted by NP (e.g., backward compatibility). Those switches always analyze the ISUP CdPN parameter to determine call routing. Today, they analyze the first 6 digits of the "national" CdPN to route the call. James > -----Original Message----- > From: gary.m.sacra@verizon.com [mailto:gary.m.sacra@verizon.com] > Sent: Tuesday, August 08, 2000 3:42 PM > To: James Yu > Cc: 'hsalama@cisco.com'; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > > > Just to clarify the statement in your second bullet below: > > For NP in the US, calls to non-ported numbers are not routed > via an LRN. They > are routed based on the dialed digits. In your example, that would be > 202-533-1234. Calls to 202-533-1234 would not route via the > switch's LRN of > 202-533-0000 because the two numbers are not associated with > each other in the > NP database since 202-533-1234 is not ported. Only ported > numbers are in the > database and they require routing via an LRN that is unique > to the switch that > serves the ported number. > > Gary Sacra > Verizon > > > > > > "James Yu" on 08/04/2000 11:35:37 AM > > > > To: "'hsalama@cisco.com'" > > cc: "'iptel@lists.bell-labs.com'" > (bcc: GARY M. > SACRA/EMPL/MD/Bell-Atl) > > > > Subject: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > > > > > Hussein, > > Section 5.1.1 of TRIP defines two address families, One for > POTS numbers and > the other for routing numbers. Since TRIP deals with "routing," it is > suggested that only the "routing numbers" address family is > used. This will > avoid the handling of two address families in TRIP for > supporting number > portability (NP). The basic rule is: > (1) Use the "routing number" for routing (e.g., check against the TRIP > routing table) if both the "routing number" and "POTS number" > are present. > (2) Use the "POTS number" for routing if "routing number" is > not present. > > The reasons are described below. > > - For countries such as U.S. and Canada that support NP and > use routing > numbers that overlap with the POTS numbers (e.g., the same format and > length), and use the POTS numbers as the routing numbers for > non-ported POTS > numbers, the "routing number" address family is sufficient > for call routing. > > * For a ported-out number, a location routing number (LRN) > is retrieved > from the NP database. That LRN (plus the country code if > required) is used > for routing. > * For a non-ported number, that POTS number is used for > routing because its > prefix (e.g., the first 6 digits of the national number) can > identify the > donor switch that serves this non-ported number. The POTS > numbers in this > case are actually treated as the routing numbers! For > example, if the POTS > number is 202-533-1234 and is not ported, a LRN of > 202-533-0000 can be used > as the LRN for routing the call. Use of "202-533-1234" or > "202-533-0000" > does not make any difference because the GSTN switches in the > North America > routes national calls based on the first 6 digits of the national POTS > numbers. That is why the POTS numbers are used for routing > for non-ported > numbers. > So all we need is the "routing number" address family. If > the routing > number is present, it is used to check against the TRIP > routing table. If > it is not present, the POTS number is used to check against > the TRIP routing > table. Only one TRIP routing table is needed. We only need > to use the > "correct" number to check against the TRIP routing table if > both the routing > number and POTS number are present. > > - For countries such as Austria and Belgium that support NP > and concatenate > a routing prefix (called network routing number) with the > POTS number (e.g., > Cxxxx+POTS number in Belgium), it does not matter whether we view this > "concatenated number" as a routing number or POTS number if > we only use > "routing numbers" address family. The TRIP table will contain Cxxxx > prefixes and also regular POTS prefixes. So if the called > party number does > not contain the routing prefix, the POTS routing prefixes are > checked for > routing. But if it contains the routing prefix such as > Cxxxx, the Cxxxx > prefixes in the same routing table are checked for routing. > The key point > is that only one TRIP routing table is needed. > > - For countries that do not support NP, the POTS numbers can > be viewed as > the routing numbers. So we still have just one TRIP routing > table/address > family. > > > Please note that the routing number will not contain digit F that was > pointed out by Monika Muench in an earlier e-mail discussion > (I'm not sure > whether it was posted to iptel or sip discussion list). > > James > > > James Yu > Principal Technical Industry Liaison > NeuStar Inc. > 1120 Vermont Avenue, NW, > Suite 550 > Washington, D.C. 20005 > USA > +1-202-533-2814 (B) > +1-202-533-2976 (Fax) > +1-202-256-1200 (Mobile) > james.yu@neustar.com > http://www.neustar.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 > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Aug 11 12:04:33 2000 Received: 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 MAA23836 for ; Fri, 11 Aug 2000 12:04:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D6E754434E; Fri, 11 Aug 2000 12:04:07 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 5BDBB44336 for ; Fri, 11 Aug 2000 12:04:05 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA02857; Fri, 11 Aug 2000 12:05:34 -0400 (EDT) Message-ID: <3994253B.1F85D2DB@dynamicsoft.com> Date: Fri, 11 Aug 2000 12:09:31 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: hsalama@cisco.com Cc: James Yu , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 References: <3993B50B.1B641508@cisco.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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit "Hussein F. Salama" wrote: > > James, > > James Yu wrote: > > > > Hussein, > > > > As indicated earlier, the "POTS number" address family is a subset of > > "routing number" address family (not in terms of the numbers but in terms of > > allowable digits). Aggregation needs to be done for the "routing numbers" > > anyway if digits A through E may appear in the routing numbers. So you are > > not totally avoiding the problem. If you need to aggregate for the routing > > numbers and one "routing number" table can do the work, why announcing the > > additional "POTS numbers" and managing an additional "POTS number table at > > the LSs just because it is easier to aggregate that address family (this is > > an "extra" work). Under country code 1, digits A through E are not used. > > It is then easy to aggregate the "routing numbers" under country code 1. > > I prefer having two separate address families to having a single address > family with two, or may be more, sets of aggregation rules. Deciding > which set of aggregation rules to use based on the first digit of the > prefix is too restrictive. For example, I can imagine TRIP applications, > with limited scope, local or national, which advertise numbers without > prepending the country code to them. Hence we won't have the '1' to > decide which aggregation rules to use? THe other issue is that you are forced to do semantic based aggregation. We want to allow (but not mandate of course)aggregation of numbers based on syntax ONLY (i.e., I have 11, 12, 13 14, ... 10, and since there are ten digits, I can aggregate to 1). This NECESSITATES knowing the number of digits that exist. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Aug 11 14:11:24 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28789 for ; Fri, 11 Aug 2000 14:11:24 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id DB7D844353; Fri, 11 Aug 2000 14:11:17 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 555F244336 for ; Fri, 11 Aug 2000 12:12:36 -0400 (EDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id AE5091E04A for ; Fri, 11 Aug 2000 12:12:26 -0400 (EDT) Received: from research.att.com ([135.58.126.37]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id MAA04814 for ; Fri, 11 Aug 2000 12:12:22 -0400 (EDT) Message-ID: <399425B9.EF227187@research.att.com> Date: Fri, 11 Aug 2000 12:11:37 -0400 From: "Gregory W. Bond" Organization: AT&T Labs - Research, Florham Park, NJ X-Mailer: Mozilla 4.72 [en] (Win98; I) 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] IP Telecom Services Workshop 2000: Call for Participation Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit [Please accept our apologies for multiple copies of this call.] ------------- CALL FOR PARTICIPATION --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. We have put together an excellent technical program that includes 7 original research papers, two invited speakers, and a round table discussion. We look forward to the participation from you and your colleagues in the telecom industry and the research community. Registration is now open at http://pulver.com/ipts2000/register.html. TECHNICAL PROGRAM Keynote Speaker - Eric Sumner, President and CEO of dynamicsoft Invited Speaker - Joe Rinde, AT&T Labs "Why Service? What Services?" DFC as the basis for ECLIPSE, an IP communications software platform Greg Bond, Eric Cheung, Andrew Forrest, Michael Jackson, Hal Purdy, Chris Ramming, and Pamela Zave AT&T Labs Research Experimenting with PARLAY in a SIP Environment: Early Results Stephane Desrochers, Roch H. Glitho, Kindy Sylla Ericsson Research Canada Approach For Services in Converged Networks Sanjiv Kapur, Rakesh Vij Hughes Software Systems Unified Messaging using SIP and RTSP Kundan Singh and Henning Schulzrinne Columbia University SPHINX: A Study in Convergent Telephony and Advanced Scenarios for H.323-SIP Interoperation Kumar V. Vemuri Lucent Technologies Where Should Services Reside in Internet Telephony Systems? Xiaotao Wu and Henning Schulzrinne Columbia University A Transformation Approach for Service Creation in a Hybrid IP-IN Network Cyril Carrez, Elie Najm, Alexandre Tauveron Ecole Nationale Superieure des Telecom Roundtable Discussion - topic to be announced REGISTRATION IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Registration details for IPTS 2000 can be found at http://www.research.att.com/conf/ipts2000. Hotel information can be found at http://www.pulver.com/von/hotel.html. Registration for IPTS 2000 does not include registration for Fall 2000 VON. Registration details for Fall 2000 VON can be found at http://pulver.com/von. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com). WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Aug 11 15:15:10 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00599 for ; Fri, 11 Aug 2000 15:15:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 562874438F; Fri, 11 Aug 2000 15:13:22 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id C3D8244368 for ; Fri, 11 Aug 2000 15:13:18 -0400 (EDT) Received: from ind.cs.columbia.edu (ind.cs.columbia.edu [128.59.19.27]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id PAA07894; Fri, 11 Aug 2000 15:13:17 -0400 (EDT) Received: (from lennox@localhost) by ind.cs.columbia.edu (8.9.3/8.9.3) id PAA22485; Fri, 11 Aug 2000 15:13:17 -0400 (EDT) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14740.20555.884557.351978@ind.cs.columbia.edu> Date: Fri, 11 Aug 2000 15:13:15 -0400 (EDT) To: Jiri Kuthan Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] CPL features In-Reply-To: <3990A563.4A1DBAED@fokus.gmd.de> References: <3990A563.4A1DBAED@fokus.gmd.de> X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit On Wednesday, August 9 2000, "Jiri Kuthan" wrote to "iptel@lists.bell-labs.com" saying: > Hi, > > some questions on CPL: > > 1) making string-switch more general > - Why are values of parameter 'field' limited to an > enumeration of a couple of well-known elements? > Though the advantage of the well-known elements is > they may be easily interpreted for different > call signaling protocols, I do not see a reason why > to prohibit arbitrary values. This would allow CPL > script writers to refer to any new fields. This was intended; notice that the DTD attribute list for string-switch is I.e., the value of the "field" parameter can be arbitrary character data. I will clarify that this is intended. (Of course, if you upload a CPL with a switch field the server doesn't support, it will reject it.) > - Would not it be helpful to support regular expression > matching in addition to 'contains' and 'is'? Version -00 of the CPL had glob matching (similar to, though weaker than, regex matching) for string switches. It seemed to be the consensus of the working group that this was too complicated for a language designed to be created by naive users, as globs and regular expressions are notoriously hard to express in GUI form. It seemed that most of the uses for pattern matching were covered by the way that address matches now split up addresses into subfields, since I didn't think that any of the non-address forms of pattern matches were particularly useful. > 2) authentication support > - Could call processing logic depend on the authentication > status? E.g., a CPL script installed at a SIP proxy may want > to deny calls from unathenticated users to PSTN. This is reasonable. However, I think it should (at least at first) be defined as an extension to the CPL, as I don't want to get into the complexities of "who authenticated this, how was it authenticated, how do I know I can trust the signer", etc. Just a binary yes/no for authentication seems too weak for general purposes, though it'd be fine for some specific instances. If this is found to be generally useful and these isues are worked out, I think it could be folded into a future version of the CPL. There's enough push to get CPL finished and sent to last call now, though, that I don't want to get into it. -- 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 Aug 11 17:09:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05252 for ; Fri, 11 Aug 2000 17:09:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 212434437A; Fri, 11 Aug 2000 17:09:20 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id E20DB44368 for ; Fri, 11 Aug 2000 17:09:16 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id RAA05365; Fri, 11 Aug 2000 17:08:05 -0400 (EDT) Message-ID: <39946C1F.19E2C6C5@dynamicsoft.com> Date: Fri, 11 Aug 2000 17:11:59 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox Cc: Jiri Kuthan , iptel@lists.bell-labs.com Subject: Re: [IPTEL] CPL features References: <3990A563.4A1DBAED@fokus.gmd.de> <14740.20555.884557.351978@ind.cs.columbia.edu> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Lennox wrote: > > On Wednesday, August 9 2000, "Jiri Kuthan" wrote to "iptel@lists.bell-labs.com" saying: > > > Hi, > > > > some questions on CPL: > > > > 1) making string-switch more general > > - Why are values of parameter 'field' limited to an > > enumeration of a couple of well-known elements? > > Though the advantage of the well-known elements is > > they may be easily interpreted for different > > call signaling protocols, I do not see a reason why > > to prohibit arbitrary values. This would allow CPL > > script writers to refer to any new fields. > > This was intended; notice that the DTD attribute list for string-switch is > > field CDATA #REQUIRED > > > > I.e., the value of the "field" parameter can be arbitrary character data. I > will clarify that this is intended. (Of course, if you upload a CPL with a > switch field the server doesn't support, it will reject it.) Seems like a recipe for interoperability problems. How can the script writer know what fields are supported by the server? Write a script, submit, see if its rejected, and if so, try a different field? I would much prefer to specify specific fields. > > > 2) authentication support > > - Could call processing logic depend on the authentication > > status? E.g., a CPL script installed at a SIP proxy may want > > to deny calls from unathenticated users to PSTN. > > This is reasonable. However, I think it should (at least at first) be > defined as an extension to the CPL, as I don't want to get into the > complexities of "who authenticated this, how was it authenticated, how do I > know I can trust the signer", etc. Just a binary yes/no for authentication > seems too weak for general purposes, though it'd be fine for some specific > instances. > > If this is found to be generally useful and these isues are worked out, I > think it could be folded into a future version of the CPL. There's enough > push to get CPL finished and sent to last call now, though, that I don't > want to get into it. I agree. We have been playing around here far too long. Let us FINISH CPL, based on the current functionality, and then see what our implementation and deployment experience show. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Aug 11 21:34:07 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA10531 for ; Fri, 11 Aug 2000 21:34:07 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 08B4744374; Fri, 11 Aug 2000 21:33:49 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 06BEB44336 for ; Fri, 11 Aug 2000 21:33:47 -0400 (EDT) Received: by dnspri.npac.com; id UAA16851; Fri, 11 Aug 2000 20:33:46 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma016846; Fri, 11 Aug 00 20:33:36 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Aug 2000 20:32:43 -0500 Message-ID: From: James Yu To: "'gary.m.sacra@verizon.com'" Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Date: Fri, 11 Aug 2000 20:31:14 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Gary, I was trying to say that LRN "could" or "can" be used for non-ported number; but in real world, LRN is not used. The non-ported POTS number remains in the ISUP Called Party Number parameter and is used to route the call to the destination (the donor switch) within the U.S. or Canada. James > -----Original Message----- > From: gary.m.sacra@verizon.com [mailto:gary.m.sacra@verizon.com] > Sent: Thursday, August 10, 2000 6:15 PM > To: James Yu > Cc: 'iptel@lists.bell-labs.com' > Subject: RE: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > > > James, > > Perhaps I misinterpreted your statement in your second bullet > below, extracted > here: > "For example, if the POTS number is 202-533-1234 and is > not ported, a LRN > of 202-533-0000 can be used > as the LRN for routing the call." > > It appeared to me you were saying that an LRN would be used > to route a call to > a non-ported number. > > Thanks, > > Gary > > > > > > "James Yu" on 08/09/2000 12:10:17 PM > > > > To: "'gary.m.sacra@verizon.com'" > > > cc: "'iptel@lists.bell-labs.com'" > (bcc: GARY M. > SACRA/EMPL/MD/Bell-Atl) > > > > Subject: RE: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > > > > > Gary, > > If a number is not ported, the ISUP Called Party Number > (CdPN) parameter > will still contain the POTS number, but the Translated Called Number > Indicator (TCNI) bit in the ISUP Forward Call Indicator (FCI) > parameter is > set to imply that NPDB query has already been performed. > This is because > the NP database today only contains records assoicated with > the ported-out > numbers. There are no records in the NP databases (in the > U.S. and Canada) > for those POTS numbers that are not ported out from the > "donor switch," the > switch that is allocated a block of numbers (e.g., 202-533-xxxx). > > The way ISUP routing is designed to support NP is so that > switches that need > not understand NP are not impacted by NP (e.g., backward > compatibility). > Those switches always analyze the ISUP CdPN parameter to > determine call > routing. Today, they analyze the first 6 digits of the > "national" CdPN to > route the call. > > James > > > -----Original Message----- > > From: gary.m.sacra@verizon.com [mailto:gary.m.sacra@verizon.com] > > Sent: Tuesday, August 08, 2000 3:42 PM > > To: James Yu > > Cc: 'hsalama@cisco.com'; 'iptel@lists.bell-labs.com' > > Subject: Re: [IPTEL] [TRIP] Address Families in > > draft-ietf-iptel-trip-03 > > > > > > > > > > Just to clarify the statement in your second bullet below: > > > > For NP in the US, calls to non-ported numbers are not routed > > via an LRN. They > > are routed based on the dialed digits. In your example, > that would be > > 202-533-1234. Calls to 202-533-1234 would not route via the > > switch's LRN of > > 202-533-0000 because the two numbers are not associated with > > each other in the > > NP database since 202-533-1234 is not ported. Only ported > > numbers are in the > > database and they require routing via an LRN that is unique > > to the switch that > > serves the ported number. > > > > Gary Sacra > > Verizon > > > > > > > > > > > > "James Yu" on 08/04/2000 11:35:37 AM > > > > > > > > To: "'hsalama@cisco.com'" > > > > cc: "'iptel@lists.bell-labs.com'" > > (bcc: GARY M. > > SACRA/EMPL/MD/Bell-Atl) > > > > > > > > Subject: [IPTEL] [TRIP] Address Families in > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > Hussein, > > > > Section 5.1.1 of TRIP defines two address families, One for > > POTS numbers and > > the other for routing numbers. Since TRIP deals with > "routing," it is > > suggested that only the "routing numbers" address family is > > used. This will > > avoid the handling of two address families in TRIP for > > supporting number > > portability (NP). The basic rule is: > > (1) Use the "routing number" for routing (e.g., check > against the TRIP > > routing table) if both the "routing number" and "POTS number" > > are present. > > (2) Use the "POTS number" for routing if "routing number" is > > not present. > > > > The reasons are described below. > > > > - For countries such as U.S. and Canada that support NP and > > use routing > > numbers that overlap with the POTS numbers (e.g., the same > format and > > length), and use the POTS numbers as the routing numbers for > > non-ported POTS > > numbers, the "routing number" address family is sufficient > > for call routing. > > > > * For a ported-out number, a location routing number (LRN) > > is retrieved > > from the NP database. That LRN (plus the country code if > > required) is used > > for routing. > > * For a non-ported number, that POTS number is used for > > routing because its > > prefix (e.g., the first 6 digits of the national number) can > > identify the > > donor switch that serves this non-ported number. The POTS > > numbers in this > > case are actually treated as the routing numbers! For > > example, if the POTS > > number is 202-533-1234 and is not ported, a LRN of > > 202-533-0000 can be used > > as the LRN for routing the call. Use of "202-533-1234" or > > "202-533-0000" > > does not make any difference because the GSTN switches in the > > North America > > routes national calls based on the first 6 digits of the > national POTS > > numbers. That is why the POTS numbers are used for routing > > for non-ported > > numbers. > > So all we need is the "routing number" address family. If > > the routing > > number is present, it is used to check against the TRIP > > routing table. If > > it is not present, the POTS number is used to check against > > the TRIP routing > > table. Only one TRIP routing table is needed. We only need > > to use the > > "correct" number to check against the TRIP routing table if > > both the routing > > number and POTS number are present. > > > > - For countries such as Austria and Belgium that support NP > > and concatenate > > a routing prefix (called network routing number) with the > > POTS number (e.g., > > Cxxxx+POTS number in Belgium), it does not matter whether > we view this > > "concatenated number" as a routing number or POTS number if > > we only use > > "routing numbers" address family. The TRIP table will contain Cxxxx > > prefixes and also regular POTS prefixes. So if the called > > party number does > > not contain the routing prefix, the POTS routing prefixes are > > checked for > > routing. But if it contains the routing prefix such as > > Cxxxx, the Cxxxx > > prefixes in the same routing table are checked for routing. > > The key point > > is that only one TRIP routing table is needed. > > > > - For countries that do not support NP, the POTS numbers can > > be viewed as > > the routing numbers. So we still have just one TRIP routing > > table/address > > family. > > > > > > Please note that the routing number will not contain digit > F that was > > pointed out by Monika Muench in an earlier e-mail discussion > > (I'm not sure > > whether it was posted to iptel or sip discussion list). > > > > James > > > > > > James Yu > > Principal Technical Industry Liaison > > NeuStar Inc. > > 1120 Vermont Avenue, NW, > > Suite 550 > > Washington, D.C. 20005 > > USA > > +1-202-533-2814 (B) > > +1-202-533-2976 (Fax) > > +1-202-256-1200 (Mobile) > > james.yu@neustar.com > > http://www.neustar.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 > > > > > > > > > > _______________________________________________ > 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 Aug 11 22:02:01 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA10992 for ; Fri, 11 Aug 2000 22:02:01 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2584A44399; Fri, 11 Aug 2000 22:01:50 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 443DA44336 for ; Fri, 11 Aug 2000 22:01:47 -0400 (EDT) Received: by dnspri.npac.com; id VAA17055; Fri, 11 Aug 2000 21:01:46 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma017048; Fri, 11 Aug 00 21:01:32 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Fri, 11 Aug 2000 21:00:38 -0500 Message-ID: From: James Yu To: "'Jonathan Rosenberg'" , hsalama@cisco.com Cc: "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Date: Fri, 11 Aug 2000 20:59:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com It seems that there may be a need to define the routing numbers in such a way (or by implementation?) that allows easy aggregation of "routing numbers" that contain only digits 0 through 9 for countries that don't use digits A through E in the "routing numbers." James > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Friday, August 11, 2000 12:10 PM > To: hsalama@cisco.com > Cc: James Yu; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > > > "Hussein F. Salama" wrote: > > > > James, > > > > James Yu wrote: > > > > > > Hussein, > > > > > > As indicated earlier, the "POTS number" address family is > a subset of > > > "routing number" address family (not in terms of the > numbers but in terms of > > > allowable digits). Aggregation needs to be done for the > "routing numbers" > > > anyway if digits A through E may appear in the routing > numbers. So you are > > > not totally avoiding the problem. If you need to > aggregate for the routing > > > numbers and one "routing number" table can do the work, > why announcing the > > > additional "POTS numbers" and managing an additional > "POTS number table at > > > the LSs just because it is easier to aggregate that > address family (this is > > > an "extra" work). Under country code 1, digits A through > E are not used. > > > It is then easy to aggregate the "routing numbers" under > country code 1. > > > > I prefer having two separate address families to having a > single address > > family with two, or may be more, sets of aggregation rules. Deciding > > which set of aggregation rules to use based on the first > digit of the > > prefix is too restrictive. For example, I can imagine TRIP > applications, > > with limited scope, local or national, which advertise > numbers without > > prepending the country code to them. Hence we won't have the '1' to > > decide which aggregation rules to use? > > THe other issue is that you are forced to do semantic based > aggregation. > We want to > allow (but not mandate of course)aggregation of numbers based > on syntax > ONLY (i.e., I have 11, 12, 13 14, ... 10, and > since there are ten digits, I can aggregate to 1). This NECESSITATES > knowing the number > of digits that exist. > > -Jonathan R. > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 Mon Aug 14 02:41:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01317 for ; Mon, 14 Aug 2000 02:41:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9B09D4433B; Mon, 14 Aug 2000 02:40:33 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C38C344336 for ; Mon, 14 Aug 2000 02:40:30 -0400 (EDT) Received: from dynamicsoft.com (1Cust54.tnt1.freehold.nj.da.uu.net [63.17.113.54]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id CAA00999; Mon, 14 Aug 2000 02:32:35 -0400 (EDT) Message-ID: <3997937D.BD1E6EAE@dynamicsoft.com> Date: Mon, 14 Aug 2000 02:36:45 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Yu Cc: hsalama@cisco.com, "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Right, and thats called the "POTS Number" address family. -Jonathan R. James Yu wrote: > > It seems that there may be a need to define the routing numbers in such a > way (or by implementation?) that allows easy aggregation of "routing > numbers" that contain only digits 0 through 9 for countries that don't use > digits A through E in the "routing numbers." > > James > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Friday, August 11, 2000 12:10 PM > > To: hsalama@cisco.com > > Cc: James Yu; 'iptel@lists.bell-labs.com' > > Subject: Re: [IPTEL] [TRIP] Address Families in > > draft-ietf-iptel-trip-03 > > > > > > > > > > "Hussein F. Salama" wrote: > > > > > > James, > > > > > > James Yu wrote: > > > > > > > > Hussein, > > > > > > > > As indicated earlier, the "POTS number" address family is > > a subset of > > > > "routing number" address family (not in terms of the > > numbers but in terms of > > > > allowable digits). Aggregation needs to be done for the > > "routing numbers" > > > > anyway if digits A through E may appear in the routing > > numbers. So you are > > > > not totally avoiding the problem. If you need to > > aggregate for the routing > > > > numbers and one "routing number" table can do the work, > > why announcing the > > > > additional "POTS numbers" and managing an additional > > "POTS number table at > > > > the LSs just because it is easier to aggregate that > > address family (this is > > > > an "extra" work). Under country code 1, digits A through > > E are not used. > > > > It is then easy to aggregate the "routing numbers" under > > country code 1. > > > > > > I prefer having two separate address families to having a > > single address > > > family with two, or may be more, sets of aggregation rules. Deciding > > > which set of aggregation rules to use based on the first > > digit of the > > > prefix is too restrictive. For example, I can imagine TRIP > > applications, > > > with limited scope, local or national, which advertise > > numbers without > > > prepending the country code to them. Hence we won't have the '1' to > > > decide which aggregation rules to use? > > > > THe other issue is that you are forced to do semantic based > > aggregation. > > We want to > > allow (but not mandate of course)aggregation of numbers based > > on syntax > > ONLY (i.e., I have 11, 12, 13 14, ... 10, and > > since there are ten digits, I can aggregate to 1). This NECESSITATES > > knowing the number > > of digits that exist. > > > > -Jonathan R. > > > > -- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > > IPTEL mailing list > > IPTEL@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/iptel > > -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Aug 14 09:33:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07485 for ; Mon, 14 Aug 2000 09:33:12 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 8109944341; Mon, 14 Aug 2000 09:32:32 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 7526F44336 for ; Mon, 14 Aug 2000 09:32:29 -0400 (EDT) Received: by dnspri.npac.com; id IAA12283; Mon, 14 Aug 2000 08:32:15 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma012231; Mon, 14 Aug 00 08:32:09 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 14 Aug 2000 08:31:10 -0500 Message-ID: From: James Yu To: "'Jonathan Rosenberg'" Cc: hsalama@cisco.com, "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Date: Mon, 14 Aug 2000 08:29:41 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Jonathan, Under NP, the NPA+NXXs in the U.S. and Canada are the "routing numbers" that are used by the PSTN to route the call. As indicated before, the LRN for ported POTS number and the NPA-NXX of the non-ported POTS numbers are used for routing. Those numbers are viewed as "routing numbers" in the PSTN until the calls reach the destination network/switch. For a ported POTS number, the destination switch/network retrieves the POTS number from the ISUP Generic Address Parameter. Note that the LRN is carried in the ISUP Called Party Number (CdPN) parameter. For a non-ported number, the POTS number is retrieved from the CdPN parameter (e.g., no LRN is used, the "POTS number" is used for routing; therefore, is viewed as the "routing number" before it reaches the destination network/switch). If a switch serves several NPA+NXXs, one of the NPA+NXXs is used as the LRN (note that LRN is a ten-digit number, NPA+NXX+XXXX and more than one LRN can be assigned to a switch). For a gateway that can reach this switch, the "routing numbers" it announces would be those NPA+NXXs assigned to that switch. The "POTS numbers" it announce would be those POTS numbers that are served by that switch. This would include: - All the POTS numbers that begin with those NPA+NXXs assigned to that switch excluding those that have been ported out. - All the ported POTS numbers to that switch from other switches. If a gateway can reach several switches, then aggregation is performed. My understanding of the POTS numbers are that they are the "subscriber telephone numbers." May be I have a misunderstanding of the definition of the "POTS number" address family. James > -----Original Message----- > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > Sent: Monday, August 14, 2000 2:37 AM > To: James Yu > Cc: hsalama@cisco.com; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > Right, and thats called the "POTS Number" address family. > > -Jonathan R. > > James Yu wrote: > > > > It seems that there may be a need to define the routing > numbers in such a > > way (or by implementation?) that allows easy aggregation of "routing > > numbers" that contain only digits 0 through 9 for countries > that don't use > > digits A through E in the "routing numbers." > > > > James > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Friday, August 11, 2000 12:10 PM > > > To: hsalama@cisco.com > > > Cc: James Yu; 'iptel@lists.bell-labs.com' > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > "Hussein F. Salama" wrote: > > > > > > > > James, > > > > > > > > James Yu wrote: > > > > > > > > > > Hussein, > > > > > > > > > > As indicated earlier, the "POTS number" address family is > > > a subset of > > > > > "routing number" address family (not in terms of the > > > numbers but in terms of > > > > > allowable digits). Aggregation needs to be done for the > > > "routing numbers" > > > > > anyway if digits A through E may appear in the routing > > > numbers. So you are > > > > > not totally avoiding the problem. If you need to > > > aggregate for the routing > > > > > numbers and one "routing number" table can do the work, > > > why announcing the > > > > > additional "POTS numbers" and managing an additional > > > "POTS number table at > > > > > the LSs just because it is easier to aggregate that > > > address family (this is > > > > > an "extra" work). Under country code 1, digits A through > > > E are not used. > > > > > It is then easy to aggregate the "routing numbers" under > > > country code 1. > > > > > > > > I prefer having two separate address families to having a > > > single address > > > > family with two, or may be more, sets of aggregation > rules. Deciding > > > > which set of aggregation rules to use based on the first > > > digit of the > > > > prefix is too restrictive. For example, I can imagine TRIP > > > applications, > > > > with limited scope, local or national, which advertise > > > numbers without > > > > prepending the country code to them. Hence we won't > have the '1' to > > > > decide which aggregation rules to use? > > > > > > THe other issue is that you are forced to do semantic based > > > aggregation. > > > We want to > > > allow (but not mandate of course)aggregation of numbers based > > > on syntax > > > ONLY (i.e., I have 11, 12, 13 14, ... 10, and > > > since there are ten digits, I can aggregate to 1). This > NECESSITATES > > > knowing the number > > > of digits that exist. > > > > > > -Jonathan R. > > > > > > -- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > > http://www.dynamicsoft.com > > > > > > > > > _______________________________________________ > > > IPTEL mailing list > > > IPTEL@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/iptel > > > > > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > 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 Aug 14 11:13:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11574 for ; Mon, 14 Aug 2000 11:13:05 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C4C474434B; Mon, 14 Aug 2000 11:12:55 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 494CE4433C for ; Mon, 14 Aug 2000 11:12:53 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id LAA03053 for ; Mon, 14 Aug 2000 11:14:33 -0400 (EDT) Message-ID: <39980DD4.326A372A@dynamicsoft.com> Date: Mon, 14 Aug 2000 11:18:44 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "iptel, list" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] A note from ECMA Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Folks, Here is an invitation from ECMA to take a look at their work. Feel free to respond directly if you are interested in sending comments. -Jonathan R. > Dear Sir, > CSTA is the ECMA and ISO/IEC standard for computer telecommunications > integration (CTI). CSTA is already widely used to integrate enterprise > computing and telephony activity, for applications ranging from call centers > to desktops. Now that the telecom and the IP Telephony (IPT) worlds are > converging, it is valuable to extend the applicability of CSTA into the IPT > world. This will allow development of new IPT-oriented applications and > leverage the investment in CSTA applications already operating in the > telephony environment by applying them in IPT and hybrid environments. > Within ECMA, Task Group TC32-TG11 is developing a working paper evaluating > how CSTA may be used in IPT based networks and determining what changes are > required to CSTA and to IPT standards to support their joint use. It also > identifies possible areas for further standardisation activity. This paper > is available from the section of the ECMA website dealing with CSTA, at > http://www.ecma.ch/ecma1/topics/csta/tg11voip/ipmap15_.htm. > The approach of this paper is to develop a mapping from CSTA to an IPT > system, and to show the interoperation of CSTA and an IPT system in a > variety of common call control scenarios. Although the work is initially > focusing on H.323 IP systems, future work will provide additional scenarios > demonstrating CSTA in other IP environments, such as SIP, MGCP, H.248 > (Megaco), and Packet Cable. > Since your organization has an interest in Internet protocols, ECMA invites > you and your fellow committee members to examine the working draft of this > paper and to send us any comments you may have, whether they address the > work already done or make suggestions for new work. Send comments to: > csta@ecma.ch. > Even if you have no comments at this time, we would welcome your expression > of interest in receiving reports of our progress in this activity. > We would also ask that you kindly inform us of any work which you are doing > in this area. > > With kind regards, > J. van den Beld > Secretary General > > > cc > Dr. J.L. Knight, Convenor ECMA TC32-TG11 -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Aug 14 13:24:37 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15315 for ; Mon, 14 Aug 2000 13:24:36 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A1B0B44349; Mon, 14 Aug 2000 13:23:47 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id C7AC744345 for ; Mon, 14 Aug 2000 13:23:43 -0400 (EDT) Received: by dnspri.npac.com; id MAA25564; Mon, 14 Aug 2000 12:23:41 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma025456; Mon, 14 Aug 00 12:23:11 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 14 Aug 2000 12:22:16 -0500 Message-ID: From: James Yu To: "'Orit Levin'" , IPTEL WG Subject: RE: [IPTEL] A draft of H323-URL to be presented during the IPTEL session Date: Mon, 14 Aug 2000 12:20:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C00614.3087B8CC" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com 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_01C00614.3087B8CC Content-Type: text/plain; charset="iso-8859-1" Orit, Please review the attached draft-yu-tel-url-00.txt, titled "Extensions to the tel and fax URL to support Number Portability." It is intended for the SIP to carry number portability (NP) information in the Request URI field. It may be carried by H.225.0 directly or may be mapped to the proposed H.323 URL to support NP in H.323. There has not been lots of discussion on this I-D. Comments from you and others are welcome. James -----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Monday, July 31, 2000 9:05 PM To: IPTEL WG Subject: [IPTEL] A draft of H323-URL to be presented during the IPTEL session Hello! I have submitted the attached draft 3 weeks ago. Unfortunately, the document doesn't appear on the IETF Drafts site. Since this topic is going to be presented during the IPTEL session on Thursday morning, I am attaching the draft for you review. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com -----Original Message----- From: Orit Levin < orit@radvision.com > To: internet-drafts@ietf.org < internet-drafts@ietf.org > Date: Tuesday, July 11, 2000 1:59 AM Subject: Request for Draft Submission Hello! I would like to submit the attached paper as the first drafts to become an Informational RFC. Thank you, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com ------_=_NextPart_000_01C00614.3087B8CC Content-Type: text/plain; name="draft-yu-tel-url-np-00.txt" Content-Disposition: attachment; filename="draft-yu-tel-url-np-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft James Yu Document: NeuStar, Inc. Category: Informational July 2000 Extensions to the "tel" and "fax" URLs to Support Number Portability Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Informational-Expiration on January 2001 1 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 1. Abstract Number portability (NP) allows the telephone subscribers to keep their telephone numbers when they change service provider, move to a new location, or change the subscribed services. The NP implementations in many countries presently support service provider portability for geographic numbers and non-geographical numbers. It has been identified that NP has impacts on several works-in-progress at the IETF. One of the impacts is to carry the NP related information in the SIP INVITE message. This document proposed the extensions to the "tel" and "fax" Uniform Resource Locators (URLs) to support NP so that they can be used to carry the NP related information in the Session Initiation Protocol (SIP) Request-URI. 2. Introduction This document proposes the extensions to the "tel" and "fax" Uniform Resource Locators (URLs) for supporting number portability (NP). [NP] provides an overview of the NP in the GSTN and points out the impacts of NP in several works-in-progress at the IETF Working Groups. One of the impacts is to be able to carry the NP related information in the Session Initiation Protocol (SIP) INVITE message. The NP related information includes the dialed directory number, a routing number and an indicator that indicates whether a query to the Number Portability Database (NPDB) has been performed. The routing number allows the network, either the Global Switched Telephone Network (GSTN) or the IP-based network, to route the call to the network or switch that currently serves the dialed called party number that has ported out of the donor network. The NPDB dip indicator informs the network entities downstream towards the terminating network (e.g., the network that currently serves the called party number) that NPDB dip has been performed; therefore, there is no need to dip the NPDB again. The dialed called party number is needed at the terminating switch so that the call can be terminated to a correct line card. If the routing number only points to the terminating network, the called party number would be used for another NPDB query to retrieve another routing number that is typically a network-specific routing number for routing the call to the terminating switch. 3. SIP Request-URI The SIP INVITE message contains a "Request-URI" element that is used by the SIP servers for making routing decisions. As indicated in [SIP], SIP servers may support Request-URIs with schemes other than "SIP," for example, the "tel" URI scheme. [TEL] specifies the URL schemes "tel," "fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. By examining the SIP URL and "tel" URL, it seems that the "tel" URL is a better Informational - Expiration in January 2001 2 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 place to carry the NP related information. Since the "fax" URL may be used for fax calls, both the "tel" and "fax" URLs need to be enhanced to support NP. 4. Proposed extensions to the "tel" RUL Scheme The following shows the extensions to the "tel" URL. Only the impacted items/lines are shown below. global-phone-number =3D (no change) (no change) (no change) *1(number-portability) local-phone-number =3D (no change) (no change) (no change) (no change) future-extension) *1(number-portability) number-portability =3D ";" routing-number *1(";" = npdb-dip-indicator) routing-number =3D rn-tag "=3D" *1("+") rn-ident rn-tag =3D "rn" rn-ident =3D *15(hex excluding "F") npdi-dip-indicator =3D npdi-tag "=3D" npdi-ident npdi-tag =3D "npdi" npdi-ident =3D "yes" / "no" It is assumed that national routing number may appear with other global-phone-number information and international routing number may appear with other local-phone-number information. The routing number digit can be any hexadecimal digit except the digit "F." The routing number and the NPDB dip indicator can appear at most once if present. The routing number can contain hexadecimal digits from 0 to E. When the routing number is present, the NPDB dip indicator may or may not be present. This is because that the routing number may be present independent of NP. When the "npdi" parameter is not present, it indicates that either NPDB dip has not been performed (equivalent to npdi=3Dno) or NP is not relevant. If = a SIP server is set to perform the NPDB queries and if a received INVITE message does not contain "yes" in the "npdi" parameter, it will perform the NPDB query. The NPDB query is outside the scope of this document. The routing number received in the response (plus the "+" and the country code when necessary) will replace the routing number in the "rn" parameter if present or will be used by the new "rn" parameter if "rn" parameter is not present. The "npdi" parameter will be set to "yes" in this case. The routing number can be a global routing number (e.g., with "+" and the country code) or a local (e.g., network-specific) routing number. When the "rn" parameter is present, it must be used for making routing decisions (e.g., against the TRIP routing tables)[TRIP]. If the "rn" parameter is not present, the telephone number right after "tel:" is used as the routing number. Informational - Expiration in January 2001 3 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 It is possible that interworking between SIP and Signaling System No. 7 (SS7) Integrated Services Digital Network User Part (ISUP) is required at the border between the Global Switched Telephone Network (GSTN) and the IP-based network. For SIP to GSTN interworking and depending on the ISUP support of NP, the information in the "tel" URL will be mapped/carried in the proper ISUP parameters. For example, for the GSTN in the U.S., the routing number in the "rn" parameter is carried in the ISUP Called Party Number Parameter. The phone number after "tel:" is carried in the ISUP Generic Address Parameter. Only national numbers are carried (e.g., without the "+" and the country code) in the ISUP parameter. The "npdi" parameter that contains "yes" cause the Forward Call Indicator parameter to be properly set to indicate that NPDB has been dipped. If the terminating GSTN supports concatenated routing number and directory number (e.g., in Europe), then the routing number and the phone number are concatenated and put in the ISUP Called Party Number parameter. The NOA value will be set according the terminating GSTN's NP standards. For GSTN to IP interworking, when the ISUP signaling contains the NP related information, the NP related information is mapped to the "tel" URL. This happens for domestic calls where the originating GSTN has performed the NPDB query, or for international calls that have arrived at the terminating country's GSTN where that GSTN has performed the NPDB query. It is assumed that the GSTN routes the call via the IP-based network to the terminating switch or network in the same country, and SIP and ISUP interworking is involved. For the GSTN in the U.S., the interworking is straightforward. The indication in the ISUP Forward Call Indicator parameter that NPDB dip has been performed will set "npdi" to "yes," the number in the Called Party Number parameter plus the "+" and the country code, if a global routing number, is carried in the "rn" parameter, and called party number in the Generic Address Parameter plus the "+" and the country code, if a global phone number, appears after "tel:". For GSTN that supports concatenated routing number and directory number (e.g., in Europe), the IP entity that performs the interworking needs to know the routing number used by the GSTN so that the routing number and the directory number in the concatenated format in the ISUP Called Party Number parameter can be separate out and transported in the "rn" parameter and after "tel:" by adding the "+" and the country code to them if they are global routing number and phone numbers. 5. Proposed extension to the "fax" URL Scheme The following shows the extensions to the "fax" URL. Only the impacted items/lines are shown below. fax-global-phone =3D (no change) (no change) (no change) Informational - Expiration in January 2001 4 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 future extension) *1(number-portability) fax-local-phone =3D (no change) (no change) (no change) (no change) future-extension) *1(number-portability) number-portability =3D ";" routing-number *1(";" = npdb-dip-indicator) routing-number =3D rn-tag "=3D" *1("+") rn-ident rn-tag =3D "rn" rn-ident =3D *15(hex excluding "F") npdi-dip-indicator =3D npdi-tag "=3D" npdi-ident npdi-tag =3D "npdi" npdi-ident =3D "yes" / "no" The same discussions in Section 5 also apply to this section. 6. Examples To simply the example and to focus on the "tel" URL in the Request- URI, only the Request-Line of a complete SIP INVITE message is shown. A SIP server receives an INVITE message as shown below where +1-202-533-1234 is the dialed called party number and has been ported out of the donor network. INVITE tel:+1-202-533-1234 SIP/2.0 Assume that this SIP server is set to perform the NPDB query. Since this INVITE message does not contain the "npdi" parameter, this SIP server will perform a NPDB query. After receiving a response back from a NPDB, it formulates the following SIP INVITE message: INVITE tel:+1-202-533-1234;rn=3D+1-202-544-0000;npdi=3Dyes SIP/2.0 This SIP server then uses the "rn" parameter to make the routing decisions (e.g., using the routing number in the "rn" parameter to check against the TRIP tables to determine the terminating GSTN gateway). If the dialed called party number +1-202-533-1234 is not ported and the dialed called party number can be used as the routing number, the outbound SIP INVITE message may look like INVITE tel:+1-202-533-1234;rn=3D+1-202-533-1234;npdi=3Dyes SIP/2.0 or INVITE tel:+1-202-533-1234;npdi=3Dyes SIP/2.0 The concept is that "rn," if present, is used for making routing decisions, and the phone number after "tel:" is used if "rn" is not present. Informational - Expiration in January 2001 5 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 7. Conclusion This Internet Draft proposes extensions to the "tel" and "fax" URLs described in [TEL] to allow the SIP to carry the NP related information in the "tel" and "fax" URLs. If agreed, it is proposed to incorporate the proposed extensions in the next revision of RFC2806. REFERENCES [NP] M. Foster, T. McGarry and J. Yu, "Number Portability in the GSTN: An Overview," draft-foster-e164-gstn-np-01.txt, July 2000. [TEL] A. Vaha-Sipila, "URLs for Telephone Calls," RFC 2806, April 2000. [SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, "SIP: Session Initiation Protocol," draft--ietf-sip- rfc2543bis-00.ps, May 2000. [TRIP] J. Rosenberg, H. Salama and M. Squire, draft-ietf-iptel-trip- 02.txt, "Telephony Routing Information Protocol (TRIP)," May 2000. Acknowledgement The author would like to thank Jonathan Rosenberg and Henning Schulzrinne for the discussion of SIP support of NP. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. Informational - Expiration in January 2001 6 =0C ------_=_NextPart_000_01C00614.3087B8CC-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Aug 14 16:45:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA18613 for ; Mon, 14 Aug 2000 16:45:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id D54CD4436E; Mon, 14 Aug 2000 16:45:03 -0400 (EDT) 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 ED09C44366 for ; Mon, 14 Aug 2000 16:45:00 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id NAA06569; Mon, 14 Aug 2000 13:45:17 -0700 (PDT) Received: from cisco.com (dhcp-171-71-147-128.cisco.com [171.71.147.128]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AES00992 (AUTH hsalama); Mon, 14 Aug 2000 13:45:07 -0700 (PDT) Message-ID: <39985992.C05B619@cisco.com> Date: Mon, 14 Aug 2000 13:41:54 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: James Yu Cc: "'Jonathan Rosenberg'" , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Yu wrote: > > Jonathan, > > Under NP, the NPA+NXXs in the U.S. and Canada are the "routing numbers" that > are used by the PSTN to route the call. As indicated before, the LRN for > ported POTS number and the NPA-NXX of the non-ported POTS numbers are used > for routing. Those numbers are viewed as "routing numbers" in the PSTN > until the calls reach the destination network/switch. > > For a ported POTS number, the destination switch/network retrieves the POTS > number from the ISUP Generic Address Parameter. Note that the LRN is > carried in the ISUP Called Party Number (CdPN) parameter. For a non-ported > number, the POTS number is retrieved from the CdPN parameter (e.g., no LRN > is used, the "POTS number" is used for routing; therefore, is viewed as the > "routing number" before it reaches the destination network/switch). > > If a switch serves several NPA+NXXs, one of the NPA+NXXs is used as the LRN > (note that LRN is a ten-digit number, NPA+NXX+XXXX and more than one LRN can > be assigned to a switch). For a gateway that can reach this switch, the > "routing numbers" it announces would be those NPA+NXXs assigned to that > switch. The "POTS numbers" it announce would be those POTS numbers that are > served by that switch. This would include: > > - All the POTS numbers that begin with those NPA+NXXs assigned to that > switch excluding those that have been ported out. > - All the ported POTS numbers to that switch from other switches. > > If a gateway can reach several switches, then aggregation is performed. My > understanding of the POTS numbers are that they are the "subscriber > telephone numbers." POTS-Numbers is just an address family. It does not imply that numbers carried in that address family must be subscriber telephone numbers. For example, North American LRNs can be advertised using the POTS-Numbers address family. Hussein May be I have a misunderstanding of the definition of > the "POTS number" address family. > > James > > > -----Original Message----- > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > Sent: Monday, August 14, 2000 2:37 AM > > To: James Yu > > Cc: hsalama@cisco.com; 'iptel@lists.bell-labs.com' > > Subject: Re: [IPTEL] [TRIP] Address Families in > > draft-ietf-iptel-trip-03 > > > > > > Right, and thats called the "POTS Number" address family. > > > > -Jonathan R. > > > > James Yu wrote: > > > > > > It seems that there may be a need to define the routing > > numbers in such a > > > way (or by implementation?) that allows easy aggregation of "routing > > > numbers" that contain only digits 0 through 9 for countries > > that don't use > > > digits A through E in the "routing numbers." > > > > > > James > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Friday, August 11, 2000 12:10 PM > > > > To: hsalama@cisco.com > > > > Cc: James Yu; 'iptel@lists.bell-labs.com' > > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > > > > > > "Hussein F. Salama" wrote: > > > > > > > > > > James, > > > > > > > > > > James Yu wrote: > > > > > > > > > > > > Hussein, > > > > > > > > > > > > As indicated earlier, the "POTS number" address family is > > > > a subset of > > > > > > "routing number" address family (not in terms of the > > > > numbers but in terms of > > > > > > allowable digits). Aggregation needs to be done for the > > > > "routing numbers" > > > > > > anyway if digits A through E may appear in the routing > > > > numbers. So you are > > > > > > not totally avoiding the problem. If you need to > > > > aggregate for the routing > > > > > > numbers and one "routing number" table can do the work, > > > > why announcing the > > > > > > additional "POTS numbers" and managing an additional > > > > "POTS number table at > > > > > > the LSs just because it is easier to aggregate that > > > > address family (this is > > > > > > an "extra" work). Under country code 1, digits A through > > > > E are not used. > > > > > > It is then easy to aggregate the "routing numbers" under > > > > country code 1. > > > > > > > > > > I prefer having two separate address families to having a > > > > single address > > > > > family with two, or may be more, sets of aggregation > > rules. Deciding > > > > > which set of aggregation rules to use based on the first > > > > digit of the > > > > > prefix is too restrictive. For example, I can imagine TRIP > > > > applications, > > > > > with limited scope, local or national, which advertise > > > > numbers without > > > > > prepending the country code to them. Hence we won't > > have the '1' to > > > > > decide which aggregation rules to use? > > > > > > > > THe other issue is that you are forced to do semantic based > > > > aggregation. > > > > We want to > > > > allow (but not mandate of course)aggregation of numbers based > > > > on syntax > > > > ONLY (i.e., I have 11, 12, 13 14, ... 10, and > > > > since there are ten digits, I can aggregate to 1). This > > NECESSITATES > > > > knowing the number > > > > of digits that exist. > > > > > > > > -Jonathan R. > > > > > > > > -- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > > > http://www.dynamicsoft.com > > > > > > > > > > > > _______________________________________________ > > > > IPTEL mailing list > > > > IPTEL@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/iptel > > > > > > > > -- > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > http://www.dynamicsoft.com > > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Aug 14 18:06:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19624 for ; Mon, 14 Aug 2000 18:06:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 93F7144382; Mon, 14 Aug 2000 18:03:23 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 5B73F44338 for ; Mon, 14 Aug 2000 18:03:18 -0400 (EDT) Received: by dnspri.npac.com; id RAA23927; Mon, 14 Aug 2000 17:03:17 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma023669; Mon, 14 Aug 00 17:02:31 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Mon, 14 Aug 2000 17:01:36 -0500 Message-ID: From: James Yu To: "'hsalama@cisco.com'" Cc: "'Jonathan Rosenberg'" , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Date: Mon, 14 Aug 2000 17:00:06 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Hussein, In that case, do we just advertis the "POTS number" address family in the U.S. and Canada and those numbers are all "routing numbers" in the format of +1+NPA+NXX? James > -----Original Message----- > From: Hussein F. Salama [mailto:hsalama@cisco.com] > Sent: Monday, August 14, 2000 4:42 PM > To: James Yu > Cc: 'Jonathan Rosenberg'; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > > > James Yu wrote: > > > > Jonathan, > > > > Under NP, the NPA+NXXs in the U.S. and Canada are the > "routing numbers" that > > are used by the PSTN to route the call. As indicated > before, the LRN for > > ported POTS number and the NPA-NXX of the non-ported POTS > numbers are used > > for routing. Those numbers are viewed as "routing numbers" > in the PSTN > > until the calls reach the destination network/switch. > > > > For a ported POTS number, the destination switch/network > retrieves the POTS > > number from the ISUP Generic Address Parameter. Note that > the LRN is > > carried in the ISUP Called Party Number (CdPN) parameter. > For a non-ported > > number, the POTS number is retrieved from the CdPN > parameter (e.g., no LRN > > is used, the "POTS number" is used for routing; therefore, > is viewed as the > > "routing number" before it reaches the destination network/switch). > > > > If a switch serves several NPA+NXXs, one of the NPA+NXXs is > used as the LRN > > (note that LRN is a ten-digit number, NPA+NXX+XXXX and more > than one LRN can > > be assigned to a switch). For a gateway that can reach > this switch, the > > "routing numbers" it announces would be those NPA+NXXs > assigned to that > > switch. The "POTS numbers" it announce would be those POTS > numbers that are > > served by that switch. This would include: > > > > - All the POTS numbers that begin with those NPA+NXXs > assigned to that > > switch excluding those that have been ported out. > > - All the ported POTS numbers to that switch from other switches. > > > > If a gateway can reach several switches, then aggregation > is performed. My > > understanding of the POTS numbers are that they are the "subscriber > > telephone numbers." > > POTS-Numbers is just an address family. It does not imply that numbers > carried in that address family must be subscriber telephone > numbers. For > example, North American LRNs can be advertised using the POTS-Numbers > address family. > > Hussein > > > May be I have a misunderstanding of the definition of > > the "POTS number" address family. > > > > James > > > > > -----Original Message----- > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > Sent: Monday, August 14, 2000 2:37 AM > > > To: James Yu > > > Cc: hsalama@cisco.com; 'iptel@lists.bell-labs.com' > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > draft-ietf-iptel-trip-03 > > > > > > > > > Right, and thats called the "POTS Number" address family. > > > > > > -Jonathan R. > > > > > > James Yu wrote: > > > > > > > > It seems that there may be a need to define the routing > > > numbers in such a > > > > way (or by implementation?) that allows easy > aggregation of "routing > > > > numbers" that contain only digits 0 through 9 for countries > > > that don't use > > > > digits A through E in the "routing numbers." > > > > > > > > James > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > Sent: Friday, August 11, 2000 12:10 PM > > > > > To: hsalama@cisco.com > > > > > Cc: James Yu; 'iptel@lists.bell-labs.com' > > > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > > > > > > > > > > > "Hussein F. Salama" wrote: > > > > > > > > > > > > James, > > > > > > > > > > > > James Yu wrote: > > > > > > > > > > > > > > Hussein, > > > > > > > > > > > > > > As indicated earlier, the "POTS number" address family is > > > > > a subset of > > > > > > > "routing number" address family (not in terms of the > > > > > numbers but in terms of > > > > > > > allowable digits). Aggregation needs to be done for the > > > > > "routing numbers" > > > > > > > anyway if digits A through E may appear in the routing > > > > > numbers. So you are > > > > > > > not totally avoiding the problem. If you need to > > > > > aggregate for the routing > > > > > > > numbers and one "routing number" table can do the work, > > > > > why announcing the > > > > > > > additional "POTS numbers" and managing an additional > > > > > "POTS number table at > > > > > > > the LSs just because it is easier to aggregate that > > > > > address family (this is > > > > > > > an "extra" work). Under country code 1, digits A through > > > > > E are not used. > > > > > > > It is then easy to aggregate the "routing numbers" under > > > > > country code 1. > > > > > > > > > > > > I prefer having two separate address families to having a > > > > > single address > > > > > > family with two, or may be more, sets of aggregation > > > rules. Deciding > > > > > > which set of aggregation rules to use based on the first > > > > > digit of the > > > > > > prefix is too restrictive. For example, I can imagine TRIP > > > > > applications, > > > > > > with limited scope, local or national, which advertise > > > > > numbers without > > > > > > prepending the country code to them. Hence we won't > > > have the '1' to > > > > > > decide which aggregation rules to use? > > > > > > > > > > THe other issue is that you are forced to do semantic based > > > > > aggregation. > > > > > We want to > > > > > allow (but not mandate of course)aggregation of numbers based > > > > > on syntax > > > > > ONLY (i.e., I have 11, 12, 13 14, ... 10, and > > > > > since there are ten digits, I can aggregate to 1). This > > > NECESSITATES > > > > > knowing the number > > > > > of digits that exist. > > > > > > > > > > -Jonathan R. > > > > > > > > > > -- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East > Hanover, NJ 07936 > > > > > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > (732) 741-7244 > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > > > _______________________________________________ > > > > > IPTEL mailing list > > > > > IPTEL@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/iptel > > > > > > > > > > > -- > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > Chief Scientist First Floor > > > dynamicsoft East Hanover, NJ 07936 > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > > http://www.dynamicsoft.com > > > > > > > _______________________________________________ > > IPTEL mailing list > > IPTEL@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/iptel > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Aug 14 19:17:12 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA20336 for ; Mon, 14 Aug 2000 19:17:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0C6E444343; Mon, 14 Aug 2000 19:17:05 -0400 (EDT) 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 A737E44338 for ; Mon, 14 Aug 2000 19:17:01 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id QAA23350; Mon, 14 Aug 2000 16:16:37 -0700 (PDT) Received: from cisco.com (dhcp-171-71-147-128.cisco.com [171.71.147.128]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AEU00687 (AUTH hsalama); Mon, 14 Aug 2000 16:15:49 -0700 (PDT) Message-ID: <39987CE4.4588D9F0@cisco.com> Date: Mon, 14 Aug 2000 16:12:36 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: James Yu Cc: "'Jonathan Rosenberg'" , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit James, James Yu wrote: > > Hussein, > > In that case, do we just advertis the "POTS number" address family in the Yes, that should be sufficient. In general, TRIP defines two address families and also allows peers to negotiate which address families each peer supports. More address families can be defined in the future, if needed. I think that should be sufficient to satisfy the needs of different applications and regional requirements. Hussein > U.S. and Canada and those numbers are all "routing numbers" in the format of > +1+NPA+NXX? > > James > > > -----Original Message----- > > From: Hussein F. Salama [mailto:hsalama@cisco.com] > > Sent: Monday, August 14, 2000 4:42 PM > > To: James Yu > > Cc: 'Jonathan Rosenberg'; 'iptel@lists.bell-labs.com' > > Subject: Re: [IPTEL] [TRIP] Address Families in > > draft-ietf-iptel-trip-03 > > > > > > > > > > James Yu wrote: > > > > > > Jonathan, > > > > > > Under NP, the NPA+NXXs in the U.S. and Canada are the > > "routing numbers" that > > > are used by the PSTN to route the call. As indicated > > before, the LRN for > > > ported POTS number and the NPA-NXX of the non-ported POTS > > numbers are used > > > for routing. Those numbers are viewed as "routing numbers" > > in the PSTN > > > until the calls reach the destination network/switch. > > > > > > For a ported POTS number, the destination switch/network > > retrieves the POTS > > > number from the ISUP Generic Address Parameter. Note that > > the LRN is > > > carried in the ISUP Called Party Number (CdPN) parameter. > > For a non-ported > > > number, the POTS number is retrieved from the CdPN > > parameter (e.g., no LRN > > > is used, the "POTS number" is used for routing; therefore, > > is viewed as the > > > "routing number" before it reaches the destination network/switch). > > > > > > If a switch serves several NPA+NXXs, one of the NPA+NXXs is > > used as the LRN > > > (note that LRN is a ten-digit number, NPA+NXX+XXXX and more > > than one LRN can > > > be assigned to a switch). For a gateway that can reach > > this switch, the > > > "routing numbers" it announces would be those NPA+NXXs > > assigned to that > > > switch. The "POTS numbers" it announce would be those POTS > > numbers that are > > > served by that switch. This would include: > > > > > > - All the POTS numbers that begin with those NPA+NXXs > > assigned to that > > > switch excluding those that have been ported out. > > > - All the ported POTS numbers to that switch from other switches. > > > > > > If a gateway can reach several switches, then aggregation > > is performed. My > > > understanding of the POTS numbers are that they are the "subscriber > > > telephone numbers." > > > > POTS-Numbers is just an address family. It does not imply that numbers > > carried in that address family must be subscriber telephone > > numbers. For > > example, North American LRNs can be advertised using the POTS-Numbers > > address family. > > > > Hussein > > > > > > May be I have a misunderstanding of the definition of > > > the "POTS number" address family. > > > > > > James > > > > > > > -----Original Message----- > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > Sent: Monday, August 14, 2000 2:37 AM > > > > To: James Yu > > > > Cc: hsalama@cisco.com; 'iptel@lists.bell-labs.com' > > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > Right, and thats called the "POTS Number" address family. > > > > > > > > -Jonathan R. > > > > > > > > James Yu wrote: > > > > > > > > > > It seems that there may be a need to define the routing > > > > numbers in such a > > > > > way (or by implementation?) that allows easy > > aggregation of "routing > > > > > numbers" that contain only digits 0 through 9 for countries > > > > that don't use > > > > > digits A through E in the "routing numbers." > > > > > > > > > > James > > > > > > > > > > > -----Original Message----- > > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > > Sent: Friday, August 11, 2000 12:10 PM > > > > > > To: hsalama@cisco.com > > > > > > Cc: James Yu; 'iptel@lists.bell-labs.com' > > > > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Hussein F. Salama" wrote: > > > > > > > > > > > > > > James, > > > > > > > > > > > > > > James Yu wrote: > > > > > > > > > > > > > > > > Hussein, > > > > > > > > > > > > > > > > As indicated earlier, the "POTS number" address family is > > > > > > a subset of > > > > > > > > "routing number" address family (not in terms of the > > > > > > numbers but in terms of > > > > > > > > allowable digits). Aggregation needs to be done for the > > > > > > "routing numbers" > > > > > > > > anyway if digits A through E may appear in the routing > > > > > > numbers. So you are > > > > > > > > not totally avoiding the problem. If you need to > > > > > > aggregate for the routing > > > > > > > > numbers and one "routing number" table can do the work, > > > > > > why announcing the > > > > > > > > additional "POTS numbers" and managing an additional > > > > > > "POTS number table at > > > > > > > > the LSs just because it is easier to aggregate that > > > > > > address family (this is > > > > > > > > an "extra" work). Under country code 1, digits A through > > > > > > E are not used. > > > > > > > > It is then easy to aggregate the "routing numbers" under > > > > > > country code 1. > > > > > > > > > > > > > > I prefer having two separate address families to having a > > > > > > single address > > > > > > > family with two, or may be more, sets of aggregation > > > > rules. Deciding > > > > > > > which set of aggregation rules to use based on the first > > > > > > digit of the > > > > > > > prefix is too restrictive. For example, I can imagine TRIP > > > > > > applications, > > > > > > > with limited scope, local or national, which advertise > > > > > > numbers without > > > > > > > prepending the country code to them. Hence we won't > > > > have the '1' to > > > > > > > decide which aggregation rules to use? > > > > > > > > > > > > THe other issue is that you are forced to do semantic based > > > > > > aggregation. > > > > > > We want to > > > > > > allow (but not mandate of course)aggregation of numbers based > > > > > > on syntax > > > > > > ONLY (i.e., I have 11, 12, 13 14, ... 10, and > > > > > > since there are ten digits, I can aggregate to 1). This > > > > NECESSITATES > > > > > > knowing the number > > > > > > of digits that exist. > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > -- > > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > > Chief Scientist First Floor > > > > > > dynamicsoft East > > Hanover, NJ 07936 > > > > > > jdrosen@dynamicsoft.com FAX: > > (973) 952-5050 > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > > (732) 741-7244 > > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPTEL mailing list > > > > > > IPTEL@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/iptel > > > > > > > > > > > > > > -- > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > Chief Scientist First Floor > > > > dynamicsoft East Hanover, NJ 07936 > > > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > > > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > > > > http://www.dynamicsoft.com > > > > > > > > > > _______________________________________________ > > > IPTEL mailing list > > > IPTEL@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/iptel > > > > -- > > Hussein F. Salama > > Cisco Systems > > Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 > > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 > > -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Aug 14 21:02:09 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21448 for ; Mon, 14 Aug 2000 21:02:09 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 051D84433C; Mon, 14 Aug 2000 21:01:50 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id D5F0F44338 for ; Mon, 14 Aug 2000 21:01:40 -0400 (EDT) Received: from fokus.gmd.de (dhcp007 [195.37.78.135]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id DAA13674; Tue, 15 Aug 2000 03:01:35 +0200 (MET DST) Message-ID: <39989659.29B626D7@fokus.gmd.de> Date: Tue, 15 Aug 2000 03:01:13 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Jonathan Lennox , iptel@lists.bell-labs.com Subject: Re: [IPTEL] CPL features References: <3990A563.4A1DBAED@fokus.gmd.de> <14740.20555.884557.351978@ind.cs.columbia.edu> <39946C1F.19E2C6C5@dynamicsoft.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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > Jonathan Lennox wrote: > > I.e., the value of the "field" parameter can be arbitrary character data. I > > will clarify that this is intended. (Of course, if you upload a CPL with a > > switch field the server doesn't support, it will reject it.) > > Seems like a recipe for interoperability problems. How can the script > writer know what > fields are supported by the server? Write a script, submit, see if its > rejected, and if so, > try a different field? > > I would much prefer to specify specific fields. Checking the scripts by servers does not seem so helpful to me: 1) support for arbitrary headers accomplishes dealing with fields unknown at the time of writing specification and implementation; checking header fields if they are well-known beats this purpose; 2) the rejection mechanism may be difficult if you use, for example, FTP to upload the CPL scripts. It is responsibility of users and/or their programming tools to write meaningful header names. The server may process both known and unknown header fields. It's a trade-off between CPL's ability to adapt to new SIP extensions and the built-in language ability to eliminate unwanted bugs. I personally prefer the former given SIP development pace. Unwanted bugs may be still prevented by tools used for generating CPL scripts. Jiri _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Aug 14 21:11:32 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA21524 for ; Mon, 14 Aug 2000 21:11:31 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 2EA2344397; Mon, 14 Aug 2000 21:06:33 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from web108.yahoomail.com (web108.yahoomail.com [205.180.60.75]) by lists.bell-labs.com (Postfix) with SMTP id 48CF044385 for ; Mon, 14 Aug 2000 21:06:28 -0400 (EDT) Received: (qmail 14678 invoked by uid 60001); 15 Aug 2000 01:06:08 -0000 Message-ID: <20000815010608.14677.qmail@web108.yahoomail.com> Received: from [206.172.244.115] by web108.yahoomail.com; Mon, 14 Aug 2000 18:06:08 PDT Date: Mon, 14 Aug 2000 18:06:08 -0700 (PDT) From: Tom Gray To: Jiri Kuthan , iptel@lists.bell-labs.com Cc: sip@lists.bell-labs.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [IPTEL] Re: [SIP] CPL, WML, VoiceXML and SIP Features Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com What I see is an endless set of features being added to protocols which were not designed to handle them. What was described below of different services to different classes of users is a type of class of service. Like most call processing, any one portion of it is very simple to describe and probably very simple to implement. Like most call processing, it is only one small part of a total group of services that are very difficult to describe and very difficult to implement. What I am really asking for is a discussion that will delimit the boundaries of what all of these protocols will do so that we will not have an endless succession of small features being added to these protocols. By the time, the exercise of defining all of these small features would be done, the market would have changed and an entirely new set of features would be required. Hence my analogy of painting the Golden Gate Bridge. Tom Gray --- Jiri Kuthan wrote: > Tom Gray wrote: > > An expecially important set of topics would be > > areas in which it would be undesirable for a > protocol > > to be created. > > > > There was a suggestion here previously that CPL be > > extended to encompass switches on authorization. > This > > is coming perilously near the use of CPL to handle > > classes of service. This would be one step on an > > infinite journey of defining a call processing > > architecture which could not be finished. it would > be > > like painting the Golden Gate Bridge. When it is > done, > > it is time to start over. > > The motivation for the CPL authentication extension > is call > processing logic may depend on authentication > status. > Consider, for example, a SIP-2-PSTN gateway. > Operator of > the gateway may want to provide 800 and local calls > for free > to anyone whereas LD calls only to authenticated > users. > Using CPL scripts to specify which calls will be > accepted > and which not seems the most natural way to me. > > Note that the CPL extension does not require > creating > a new protocol. > > If you still see some complexity of "painting the > Golden > Bridge" grade, please be more specific. (And please > use the > iptel mailing list rather than sip.) > > Jiri __________________________________________________ Do You Yahoo!? Yahoo! Mail – Free email you can access from anywhere! http://mail.yahoo.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 Aug 14 23:56:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA24930 for ; Mon, 14 Aug 2000 23:56:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 721814433F; Mon, 14 Aug 2000 23:56:47 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 8DFEA44338 for ; Mon, 14 Aug 2000 23:56:44 -0400 (EDT) Received: from dynamicsoft.com (1Cust69.tnt1.freehold.nj.da.uu.net [63.17.113.69]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id XAA09224; Mon, 14 Aug 2000 23:58:21 -0400 (EDT) Message-ID: <3998C0DB.D0A493B1@dynamicsoft.com> Date: Tue, 15 Aug 2000 00:02:35 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jiri Kuthan Cc: Jonathan Lennox , iptel@lists.bell-labs.com Subject: Re: [IPTEL] CPL features References: <3990A563.4A1DBAED@fokus.gmd.de> <14740.20555.884557.351978@ind.cs.columbia.edu> <39946C1F.19E2C6C5@dynamicsoft.com> <39989659.29B626D7@fokus.gmd.de> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Allowing checking for arbitrary headers and values impacts the ability of a script to work meaningfully for both SIP and H.323. It also makes development of tools to build these things more complex. Remember the objective - a simple tool for building services, aimed primarily at service creation and customization by end users. If you want real flexibility, you need servlets or something like that. -Jonathan R. Jiri Kuthan wrote: > > Jonathan Rosenberg wrote: > > > > Jonathan Lennox wrote: > > > I.e., the value of the "field" parameter can be arbitrary character data. I > > > will clarify that this is intended. (Of course, if you upload a CPL with a > > > switch field the server doesn't support, it will reject it.) > > > > Seems like a recipe for interoperability problems. How can the script > > writer know what > > fields are supported by the server? Write a script, submit, see if its > > rejected, and if so, > > try a different field? > > > > I would much prefer to specify specific fields. > > Checking the scripts by servers does not seem so helpful to me: > 1) support for arbitrary headers accomplishes dealing with fields unknown > at the time of writing specification and implementation; > checking header fields if they are well-known beats this purpose; > 2) the rejection mechanism may be difficult if you use, for example, > FTP to upload the CPL scripts. > It is responsibility of users and/or their programming tools to > write meaningful header names. The server may process both > known and unknown header fields. > > It's a trade-off between CPL's ability to adapt to new SIP extensions > and the built-in language ability to eliminate unwanted bugs. I personally > prefer the former given SIP development pace. Unwanted bugs may be still > prevented by tools used for generating CPL scripts. > > Jiri -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Tue Aug 15 12:51:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19016 for ; Tue, 15 Aug 2000 12:51:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 91EFC4433F; Tue, 15 Aug 2000 12:51:14 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by lists.bell-labs.com (Postfix) with ESMTP id ED01344338 for ; Tue, 15 Aug 2000 12:51:11 -0400 (EDT) Received: from orit ([38.150.216.6]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20000815165111.NYTK17786.hvmta01-stg@orit>; Tue, 15 Aug 2000 12:51:11 -0400 Message-ID: <004601c006db$0c6dc9a0$99d8a8c0@orit.us.radvision.com> Reply-To: "Orit Levin" From: "Orit Levin" To: "James Yu" , "IPTEL WG" , Cc: , , "SIP reflector" Date: Tue, 15 Aug 2000 13:05:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [IPTEL] URL to support Number Portability [was: draft-yu-tel-url-00.txt] Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit James! After reviewing your draft, below are my comments. As in regards to H.323, H.323 doesn't currently have an explicit notion of two different fields carrying the exact meaning of "current destination" and "the final recipient", using SIP language. On the other hand, the definition of H.323 URL potentially allows for cascading of URLs of different kinds. This concept appear in the last draft of "Annex O" to be discussed next week. Therefore, tel url can be placed in the "user" part of H.323 URL. Since, in your proposal, the original "final recipient" information (i.e. the phone number itself) is preserved in the tel url after the NPDB deep is performed, I don't see a technical problem for using the proposed algorithm within H.323. I will bring your work to the attention of H.323 community next week, including the H.323 mobility WG. My question (and that of the H.323 community) would be: what level of consensus does the approach, presented in your draft, currently have within SIP and IPTEL working groups? Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com -----Original Message----- From: James Yu To: 'Orit Levin' ; IPTEL WG Date: Monday, August 14, 2000 1:24 PM Subject: RE: [IPTEL] A draft of H323-URL to be presented during the IPTEL session >Orit, > >Please review the attached draft-yu-tel-url-00.txt, titled "Extensions to >the tel and fax URL to support Number Portability." It is intended for the >SIP to carry number portability (NP) information in the Request URI field. >It may be carried by H.225.0 directly or may be mapped to the proposed H.323 >URL to support NP in H.323. > >There has not been lots of discussion on this I-D. Comments from you and >others are welcome. > >James > > > >-----Original Message----- >From: Orit Levin [mailto:orit@radvision.com] >Sent: Monday, July 31, 2000 9:05 PM >To: IPTEL WG >Subject: [IPTEL] A draft of H323-URL to be presented during the IPTEL >session > > >Hello! >I have submitted the attached draft 3 weeks ago. >Unfortunately, the document doesn't appear on the IETF Drafts site. >Since this topic is going to be presented during the IPTEL session on >Thursday morning, I am attaching the draft for you review. >Best Regards, >Orit Levin >RADVision Inc. >575 Corporate Drive Suite 420 >Mahwah, NJ 07430 >Tel: 1 201 529 4300 (230) >Fax: 1 201 529 3516 >www.radvision.com >orit@radvision.com >-----Original Message----- >From: Orit Levin < orit@radvision.com > >To: internet-drafts@ietf.org < >internet-drafts@ietf.org > >Date: Tuesday, July 11, 2000 1:59 AM >Subject: Request for Draft Submission > > >Hello! >I would like to submit the attached paper as the first drafts to become an >Informational RFC. >Thank you, >Orit Levin >RADVision Inc. >575 Corporate Drive Suite 420 >Mahwah, NJ 07430 >Tel: 1 201 529 4300 (230) >Fax: 1 201 529 3516 >www.radvision.com >orit@radvision.com > > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Aug 15 18:07:31 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA28734 for ; Tue, 15 Aug 2000 18:07:30 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 1130F4438C; Tue, 15 Aug 2000 18:07:25 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 347B444345 for ; Tue, 15 Aug 2000 18:07:22 -0400 (EDT) Received: by dnspri.npac.com; id RAA11252; Tue, 15 Aug 2000 17:07:21 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma011191; Tue, 15 Aug 00 17:06:35 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Tue, 15 Aug 2000 17:05:39 -0500 Message-ID: From: James Yu To: "'hsalama@cisco.com'" Cc: "'Jonathan Rosenberg'" , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Date: Tue, 15 Aug 2000 17:04:09 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Hussein, What needs to be clearly indicated is that it should not happen that some LSs/GWs announce the reachability of subscriber "POTS numbers" and others announce the reachability of "routing" POTS numbers (e.g., LRNs) in the U.S. and Canada. Is the current TRIP document very clear and specific about that? James > -----Original Message----- > From: Hussein F. Salama [mailto:hsalama@cisco.com] > Sent: Monday, August 14, 2000 7:13 PM > To: James Yu > Cc: 'Jonathan Rosenberg'; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > James, > > James Yu wrote: > > > > Hussein, > > > > In that case, do we just advertis the "POTS number" address > family in the > > Yes, that should be sufficient. > > In general, TRIP defines two address families and also allows peers to > negotiate which address families each peer supports. More address > families can be defined in the future, if needed. I think > that should be > sufficient to satisfy the needs of different applications and regional > requirements. > > Hussein > > > > U.S. and Canada and those numbers are all "routing numbers" > in the format of > > +1+NPA+NXX? > > > > James > > > > > -----Original Message----- > > > From: Hussein F. Salama [mailto:hsalama@cisco.com] > > > Sent: Monday, August 14, 2000 4:42 PM > > > To: James Yu > > > Cc: 'Jonathan Rosenberg'; 'iptel@lists.bell-labs.com' > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > James Yu wrote: > > > > > > > > Jonathan, > > > > > > > > Under NP, the NPA+NXXs in the U.S. and Canada are the > > > "routing numbers" that > > > > are used by the PSTN to route the call. As indicated > > > before, the LRN for > > > > ported POTS number and the NPA-NXX of the non-ported POTS > > > numbers are used > > > > for routing. Those numbers are viewed as "routing numbers" > > > in the PSTN > > > > until the calls reach the destination network/switch. > > > > > > > > For a ported POTS number, the destination switch/network > > > retrieves the POTS > > > > number from the ISUP Generic Address Parameter. Note that > > > the LRN is > > > > carried in the ISUP Called Party Number (CdPN) parameter. > > > For a non-ported > > > > number, the POTS number is retrieved from the CdPN > > > parameter (e.g., no LRN > > > > is used, the "POTS number" is used for routing; therefore, > > > is viewed as the > > > > "routing number" before it reaches the destination > network/switch). > > > > > > > > If a switch serves several NPA+NXXs, one of the NPA+NXXs is > > > used as the LRN > > > > (note that LRN is a ten-digit number, NPA+NXX+XXXX and more > > > than one LRN can > > > > be assigned to a switch). For a gateway that can reach > > > this switch, the > > > > "routing numbers" it announces would be those NPA+NXXs > > > assigned to that > > > > switch. The "POTS numbers" it announce would be those POTS > > > numbers that are > > > > served by that switch. This would include: > > > > > > > > - All the POTS numbers that begin with those NPA+NXXs > > > assigned to that > > > > switch excluding those that have been ported out. > > > > - All the ported POTS numbers to that switch from other > switches. > > > > > > > > If a gateway can reach several switches, then aggregation > > > is performed. My > > > > understanding of the POTS numbers are that they are the > "subscriber > > > > telephone numbers." > > > > > > POTS-Numbers is just an address family. It does not imply > that numbers > > > carried in that address family must be subscriber telephone > > > numbers. For > > > example, North American LRNs can be advertised using the > POTS-Numbers > > > address family. > > > > > > Hussein > > > > > > > > > May be I have a misunderstanding of the definition of > > > > the "POTS number" address family. > > > > > > > > James > > > > > > > > > -----Original Message----- > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > Sent: Monday, August 14, 2000 2:37 AM > > > > > To: James Yu > > > > > Cc: hsalama@cisco.com; 'iptel@lists.bell-labs.com' > > > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > Right, and thats called the "POTS Number" address family. > > > > > > > > > > -Jonathan R. > > > > > > > > > > James Yu wrote: > > > > > > > > > > > > It seems that there may be a need to define the routing > > > > > numbers in such a > > > > > > way (or by implementation?) that allows easy > > > aggregation of "routing > > > > > > numbers" that contain only digits 0 through 9 for countries > > > > > that don't use > > > > > > digits A through E in the "routing numbers." > > > > > > > > > > > > James > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > > > Sent: Friday, August 11, 2000 12:10 PM > > > > > > > To: hsalama@cisco.com > > > > > > > Cc: James Yu; 'iptel@lists.bell-labs.com' > > > > > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > > > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Hussein F. Salama" wrote: > > > > > > > > > > > > > > > > James, > > > > > > > > > > > > > > > > James Yu wrote: > > > > > > > > > > > > > > > > > > Hussein, > > > > > > > > > > > > > > > > > > As indicated earlier, the "POTS number" > address family is > > > > > > > a subset of > > > > > > > > > "routing number" address family (not in terms of the > > > > > > > numbers but in terms of > > > > > > > > > allowable digits). Aggregation needs to be > done for the > > > > > > > "routing numbers" > > > > > > > > > anyway if digits A through E may appear in the routing > > > > > > > numbers. So you are > > > > > > > > > not totally avoiding the problem. If you need to > > > > > > > aggregate for the routing > > > > > > > > > numbers and one "routing number" table can do > the work, > > > > > > > why announcing the > > > > > > > > > additional "POTS numbers" and managing an additional > > > > > > > "POTS number table at > > > > > > > > > the LSs just because it is easier to aggregate that > > > > > > > address family (this is > > > > > > > > > an "extra" work). Under country code 1, > digits A through > > > > > > > E are not used. > > > > > > > > > It is then easy to aggregate the "routing > numbers" under > > > > > > > country code 1. > > > > > > > > > > > > > > > > I prefer having two separate address families > to having a > > > > > > > single address > > > > > > > > family with two, or may be more, sets of aggregation > > > > > rules. Deciding > > > > > > > > which set of aggregation rules to use based on the first > > > > > > > digit of the > > > > > > > > prefix is too restrictive. For example, I can > imagine TRIP > > > > > > > applications, > > > > > > > > with limited scope, local or national, which advertise > > > > > > > numbers without > > > > > > > > prepending the country code to them. Hence we won't > > > > > have the '1' to > > > > > > > > decide which aggregation rules to use? > > > > > > > > > > > > > > THe other issue is that you are forced to do > semantic based > > > > > > > aggregation. > > > > > > > We want to > > > > > > > allow (but not mandate of course)aggregation of > numbers based > > > > > > > on syntax > > > > > > > ONLY (i.e., I have 11, 12, 13 14, ... 10, and > > > > > > > since there are ten digits, I can aggregate to 1). This > > > > > NECESSITATES > > > > > > > knowing the number > > > > > > > of digits that exist. > > > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > > > -- > > > > > > > Jonathan D. Rosenberg 72 > Eagle Rock Ave. > > > > > > > Chief Scientist First Floor > > > > > > > dynamicsoft East > > > Hanover, NJ 07936 > > > > > > > jdrosen@dynamicsoft.com FAX: > > > (973) 952-5050 > > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > > > (732) 741-7244 > > > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > IPTEL mailing list > > > > > > > IPTEL@lists.bell-labs.com > > > > > > > http://lists.bell-labs.com/mailman/listinfo/iptel > > > > > > > > > > > > > > > > > -- > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > Chief Scientist First Floor > > > > > dynamicsoft East > Hanover, NJ 07936 > > > > > jdrosen@dynamicsoft.com FAX: > (973) 952-5050 > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > (732) 741-7244 > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > _______________________________________________ > > > > IPTEL mailing list > > > > IPTEL@lists.bell-labs.com > > > > http://lists.bell-labs.com/mailman/listinfo/iptel > > > > > > -- > > > Hussein F. Salama > > > Cisco Systems > > > Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 > > > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 > > > > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 > > > _______________________________________________ > 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 Aug 16 12:50:26 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29962 for ; Wed, 16 Aug 2000 12:50:25 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0648744377; Wed, 16 Aug 2000 12:49:34 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 07D4444371 for ; Wed, 16 Aug 2000 12:49:32 -0400 (EDT) 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 MAA12737 for ; Wed, 16 Aug 2000 12:49:31 -0400 (EDT) Received: (from lennox@localhost) by grandcentral.cs.columbia.edu (8.9.3/8.9.3) id MAA02990; Wed, 16 Aug 2000 12:49:30 -0400 (EDT) From: Jonathan Lennox MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14746.50714.739782.573450@grandcentral.cs.columbia.edu> Date: Wed, 16 Aug 2000 12:49:30 -0400 (EDT) To: iptel@lists.bell-labs.com Subject: Re: [IPTEL] CPL features X-Mailer: VM 6.75 under Emacs 19.34.1 Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit [My e-mail was down for five days...I'm replying based on the web archive, so apologies for any infelicities in formatting and the loss of references headers.] On Tue, 15 Aug 2000, Jiri Kuthan wrote to iptel@lists.bell-labs.com: > Checking the scripts by servers does not seem so helpful to me: > 1) support for arbitrary headers accomplishes dealing with fields unknown > at the time of writing specification and implementation; > checking header fields if they are well-known beats this purpose; > It's a trade-off between CPL's ability to adapt to new SIP extensions > and the built-in language ability to eliminate unwanted bugs. I personally > prefer the former given SIP development pace. Unwanted bugs may be still > prevented by tools used for generating CPL scripts. I'd like to re-iterate Jonathan R.'s point that CPL is *not* just for SIP. The spec is written with a lot of H.323 bindings in it, and I've also heard reports of people using it for PSTN calls. The information in the switches, therefore, doesn't correspond to SIP headers. Instead, it's a textual representation of information in the call setup request. This is often the *same* as how the information is represented in the SIP header, because there's no point in being gratuitously incompatible, but a major design requirement of CPL was to be protocol-neutral in at least its core features. If you want finer-grained control specifically targeted to SIP, SIP-CGI and SIP Servlets are both available. CPL was never intended to be the sole answer to all of IP telephony service creation. > 2) the rejection mechanism may be difficult if you use, for example, > FTP to upload the CPL scripts. Clearly there always has to be *some* point when a server notices that a script is invalid, it ought to have some way of reporting this failure in a more clever way than sending a failure response back to the caller. It seems like good programming practice to notice this, if you can, earlier than at the last minute, so the script owner can fix the problem before he or she loses calls. I'm not recommending some sort of active negotiation of script capabilities. -- 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 Wed Aug 16 17:00:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03883 for ; Wed, 16 Aug 2000 17:00:28 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 83D784434A; Wed, 16 Aug 2000 17:00:19 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id 4CAE944339 for ; Wed, 16 Aug 2000 17:00:16 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA19924; Wed, 16 Aug 2000 14:00:32 -0700 (PDT) Received: from cisco.com (dhcp-171-71-147-128.cisco.com [171.71.147.128]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AEW08630 (AUTH hsalama); Wed, 16 Aug 2000 14:00:21 -0700 (PDT) Message-ID: <399B0021.D9C3BA65@cisco.com> Date: Wed, 16 Aug 2000 13:57:05 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com Organization: Cisco Systems X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: James Yu Cc: "'Jonathan Rosenberg'" , "'iptel@lists.bell-labs.com'" Subject: Re: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Yu wrote: > > Hussein, > > What needs to be clearly indicated is that it should not happen that some > LSs/GWs announce the reachability of subscriber "POTS numbers" and others > announce the reachability of "routing" POTS numbers (e.g., LRNs) in the U.S. > and Canada. Is the current TRIP document very clear and specific about > that? The Route Types Supported capability says: "The Route Types Supported Capability Code lists the route types supported in this peering session by the transmitting LS. An LS MUST NOT use route types that are not supported by the peer LS in any particular peering session. If the route types supported by a peer are not satisfactory, an LS MAY terminate the peering session." I think we should consider replacing the word "MAY" with "SHOULD" or "MUST." The above text is sufficient to prevent peer-to-peer capability mismatch. However, it doesn't prevent mismatches across an entire domain, because TRIP can't prevent that. May be an application note (TRIP applicability) is needed to clarify this issue and othe similar issues which may arise in the future. Hussein > > James > > > -----Original Message----- > > From: Hussein F. Salama [mailto:hsalama@cisco.com] > > Sent: Monday, August 14, 2000 7:13 PM > > To: James Yu > > Cc: 'Jonathan Rosenberg'; 'iptel@lists.bell-labs.com' > > Subject: Re: [IPTEL] [TRIP] Address Families in > > draft-ietf-iptel-trip-03 > > > > > > James, > > > > James Yu wrote: > > > > > > Hussein, > > > > > > In that case, do we just advertis the "POTS number" address > > family in the > > > > Yes, that should be sufficient. > > > > In general, TRIP defines two address families and also allows peers to > > negotiate which address families each peer supports. More address > > families can be defined in the future, if needed. I think > > that should be > > sufficient to satisfy the needs of different applications and regional > > requirements. > > > > Hussein > > > > > > > U.S. and Canada and those numbers are all "routing numbers" > > in the format of > > > +1+NPA+NXX? > > > > > > James > > > > > > > -----Original Message----- > > > > From: Hussein F. Salama [mailto:hsalama@cisco.com] > > > > Sent: Monday, August 14, 2000 4:42 PM > > > > To: James Yu > > > > Cc: 'Jonathan Rosenberg'; 'iptel@lists.bell-labs.com' > > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > > > > > > James Yu wrote: > > > > > > > > > > Jonathan, > > > > > > > > > > Under NP, the NPA+NXXs in the U.S. and Canada are the > > > > "routing numbers" that > > > > > are used by the PSTN to route the call. As indicated > > > > before, the LRN for > > > > > ported POTS number and the NPA-NXX of the non-ported POTS > > > > numbers are used > > > > > for routing. Those numbers are viewed as "routing numbers" > > > > in the PSTN > > > > > until the calls reach the destination network/switch. > > > > > > > > > > For a ported POTS number, the destination switch/network > > > > retrieves the POTS > > > > > number from the ISUP Generic Address Parameter. Note that > > > > the LRN is > > > > > carried in the ISUP Called Party Number (CdPN) parameter. > > > > For a non-ported > > > > > number, the POTS number is retrieved from the CdPN > > > > parameter (e.g., no LRN > > > > > is used, the "POTS number" is used for routing; therefore, > > > > is viewed as the > > > > > "routing number" before it reaches the destination > > network/switch). > > > > > > > > > > If a switch serves several NPA+NXXs, one of the NPA+NXXs is > > > > used as the LRN > > > > > (note that LRN is a ten-digit number, NPA+NXX+XXXX and more > > > > than one LRN can > > > > > be assigned to a switch). For a gateway that can reach > > > > this switch, the > > > > > "routing numbers" it announces would be those NPA+NXXs > > > > assigned to that > > > > > switch. The "POTS numbers" it announce would be those POTS > > > > numbers that are > > > > > served by that switch. This would include: > > > > > > > > > > - All the POTS numbers that begin with those NPA+NXXs > > > > assigned to that > > > > > switch excluding those that have been ported out. > > > > > - All the ported POTS numbers to that switch from other > > switches. > > > > > > > > > > If a gateway can reach several switches, then aggregation > > > > is performed. My > > > > > understanding of the POTS numbers are that they are the > > "subscriber > > > > > telephone numbers." > > > > > > > > POTS-Numbers is just an address family. It does not imply > > that numbers > > > > carried in that address family must be subscriber telephone > > > > numbers. For > > > > example, North American LRNs can be advertised using the > > POTS-Numbers > > > > address family. > > > > > > > > Hussein > > > > > > > > > > > > May be I have a misunderstanding of the definition of > > > > > the "POTS number" address family. > > > > > > > > > > James > > > > > > > > > > > -----Original Message----- > > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > > Sent: Monday, August 14, 2000 2:37 AM > > > > > > To: James Yu > > > > > > Cc: hsalama@cisco.com; 'iptel@lists.bell-labs.com' > > > > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > > > > Right, and thats called the "POTS Number" address family. > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > James Yu wrote: > > > > > > > > > > > > > > It seems that there may be a need to define the routing > > > > > > numbers in such a > > > > > > > way (or by implementation?) that allows easy > > > > aggregation of "routing > > > > > > > numbers" that contain only digits 0 through 9 for countries > > > > > > that don't use > > > > > > > digits A through E in the "routing numbers." > > > > > > > > > > > > > > James > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > > > > Sent: Friday, August 11, 2000 12:10 PM > > > > > > > > To: hsalama@cisco.com > > > > > > > > Cc: James Yu; 'iptel@lists.bell-labs.com' > > > > > > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > > > > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Hussein F. Salama" wrote: > > > > > > > > > > > > > > > > > > James, > > > > > > > > > > > > > > > > > > James Yu wrote: > > > > > > > > > > > > > > > > > > > > Hussein, > > > > > > > > > > > > > > > > > > > > As indicated earlier, the "POTS number" > > address family is > > > > > > > > a subset of > > > > > > > > > > "routing number" address family (not in terms of the > > > > > > > > numbers but in terms of > > > > > > > > > > allowable digits). Aggregation needs to be > > done for the > > > > > > > > "routing numbers" > > > > > > > > > > anyway if digits A through E may appear in the routing > > > > > > > > numbers. So you are > > > > > > > > > > not totally avoiding the problem. If you need to > > > > > > > > aggregate for the routing > > > > > > > > > > numbers and one "routing number" table can do > > the work, > > > > > > > > why announcing the > > > > > > > > > > additional "POTS numbers" and managing an additional > > > > > > > > "POTS number table at > > > > > > > > > > the LSs just because it is easier to aggregate that > > > > > > > > address family (this is > > > > > > > > > > an "extra" work). Under country code 1, > > digits A through > > > > > > > > E are not used. > > > > > > > > > > It is then easy to aggregate the "routing > > numbers" under > > > > > > > > country code 1. > > > > > > > > > > > > > > > > > > I prefer having two separate address families > > to having a > > > > > > > > single address > > > > > > > > > family with two, or may be more, sets of aggregation > > > > > > rules. Deciding > > > > > > > > > which set of aggregation rules to use based on the first > > > > > > > > digit of the > > > > > > > > > prefix is too restrictive. For example, I can > > imagine TRIP > > > > > > > > applications, > > > > > > > > > with limited scope, local or national, which advertise > > > > > > > > numbers without > > > > > > > > > prepending the country code to them. Hence we won't > > > > > > have the '1' to > > > > > > > > > decide which aggregation rules to use? > > > > > > > > > > > > > > > > THe other issue is that you are forced to do > > semantic based > > > > > > > > aggregation. > > > > > > > > We want to > > > > > > > > allow (but not mandate of course)aggregation of > > numbers based > > > > > > > > on syntax > > > > > > > > ONLY (i.e., I have 11, 12, 13 14, ... 10, and > > > > > > > > since there are ten digits, I can aggregate to 1). This > > > > > > NECESSITATES > > > > > > > > knowing the number > > > > > > > > of digits that exist. > > > > > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > > > > > -- > > > > > > > > Jonathan D. Rosenberg 72 > > Eagle Rock Ave. > > > > > > > > Chief Scientist First Floor > > > > > > > > dynamicsoft East > > > > Hanover, NJ 07936 > > > > > > > > jdrosen@dynamicsoft.com FAX: > > > > (973) 952-5050 > > > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > > > > (732) 741-7244 > > > > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > IPTEL mailing list > > > > > > > > IPTEL@lists.bell-labs.com > > > > > > > > http://lists.bell-labs.com/mailman/listinfo/iptel > > > > > > > > > > > > > > > > > > > > -- > > > > > > Jonathan D. Rosenberg 72 Eagle Rock Ave. > > > > > > Chief Scientist First Floor > > > > > > dynamicsoft East > > Hanover, NJ 07936 > > > > > > jdrosen@dynamicsoft.com FAX: > > (973) 952-5050 > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > > (732) 741-7244 > > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > > > > _______________________________________________ > > > > > IPTEL mailing list > > > > > IPTEL@lists.bell-labs.com > > > > > http://lists.bell-labs.com/mailman/listinfo/iptel > > > > > > > > -- > > > > Hussein F. Salama > > > > Cisco Systems > > > > Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 > > > > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 > > > > > > > > -- > > Hussein F. Salama > > Cisco Systems > > Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 > > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 > > > > > > _______________________________________________ > > IPTEL mailing list > > IPTEL@lists.bell-labs.com > > http://lists.bell-labs.com/mailman/listinfo/iptel > > -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Aug 16 17:27:13 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04210 for ; Wed, 16 Aug 2000 17:27:11 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B118944390; Wed, 16 Aug 2000 17:19:53 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id 698284435B; Wed, 16 Aug 2000 17:19:42 -0400 (EDT) Received: by dnspri.npac.com; id QAA15479; Wed, 16 Aug 2000 16:19:35 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma015268; Wed, 16 Aug 00 16:19:09 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Wed, 16 Aug 2000 16:18:09 -0500 Message-ID: From: James Yu To: IPTEL WG , "'sip@lists.bell-labs.com'" Cc: h323implementors@imtc.org, ITU-SG16@mailbag.cps.intel.com, SIP reflector , "'Orit Levin'" , sip-h323@egroups.com Subject: RE: [IPTEL] URL to support Number Portability [was: draft-yu-tel- url-00.txt] Date: Wed, 16 Aug 2000 16:16:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C007C7.7978C77E" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com 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_01C007C7.7978C77E Content-Type: text/plain; charset="iso-8859-1" Would appreciate if people on the iptel and SIP discussion lists can voice their opinions (agree or disagree) on draft-yu-tel-url-00.txt (see attachment). This enhancement to the tel URL is intended to allow SIP to carry number portability related information in the Request-URI field. The information (e.g., routing number and POTS number) in the tel URL may be used by the LSs for call routing. Thanks. James > -----Original Message----- > From: Orit Levin [mailto:orit@radvision.com] > Sent: Tuesday, August 15, 2000 1:06 PM > To: James Yu; IPTEL WG; sip-h323@egroups.com > Cc: h323implementors@imtc.org; ITU-SG16@MAILBAG.INTEL.COM; > SIP reflector > Subject: [IPTEL] URL to support Number Portability [was: > draft-yu-tel-url-00.txt] > > > James! > After reviewing your draft, below are my comments. > As in regards to H.323, H.323 doesn't currently have an > explicit notion of > two different fields carrying the exact meaning of "current > destination" and > "the final recipient", using SIP language. > On the other hand, the definition of H.323 URL potentially allows for > cascading of URLs > of different kinds. This concept appear in the last draft of > "Annex O" to be > discussed next week. Therefore, tel url can be placed in the > "user" part of > H.323 URL. > Since, in your proposal, the original "final recipient" > information (i.e. > the phone number itself) is preserved in the tel url after > the NPDB deep is > performed, I don't see a technical problem for using the > proposed algorithm > within H.323. > > I will bring your work to the attention of H.323 community next week, > including the H.323 mobility WG. My question (and that of the H.323 > community) would be: what level of consensus does the > approach, presented in > your draft, currently have within SIP and IPTEL working groups? > > > Orit Levin > RADVision Inc. > 575 Corporate Drive Suite 420 > Mahwah, NJ 07430 > Tel: 1 201 529 4300 (230) > Fax: 1 201 529 3516 > www.radvision.com > orit@radvision.com > -----Original Message----- > From: James Yu > To: 'Orit Levin' ; IPTEL WG > > Date: Monday, August 14, 2000 1:24 PM > Subject: RE: [IPTEL] A draft of H323-URL to be presented > during the IPTEL > session > > > >Orit, > > > >Please review the attached draft-yu-tel-url-00.txt, titled > "Extensions to > >the tel and fax URL to support Number Portability." It is > intended for the > >SIP to carry number portability (NP) information in the > Request URI field. > >It may be carried by H.225.0 directly or may be mapped to > the proposed > H.323 > >URL to support NP in H.323. > > > >There has not been lots of discussion on this I-D. Comments > from you and > >others are welcome. > > > >James > > > > > > > >-----Original Message----- > >From: Orit Levin [mailto:orit@radvision.com] > >Sent: Monday, July 31, 2000 9:05 PM > >To: IPTEL WG > >Subject: [IPTEL] A draft of H323-URL to be presented during the IPTEL > >session > > > > > >Hello! > >I have submitted the attached draft 3 weeks ago. > >Unfortunately, the document doesn't appear on the IETF Drafts site. > >Since this topic is going to be presented during the IPTEL session on > >Thursday morning, I am attaching the draft for you review. > >Best Regards, > >Orit Levin > >RADVision Inc. > >575 Corporate Drive Suite 420 > >Mahwah, NJ 07430 > >Tel: 1 201 529 4300 (230) > >Fax: 1 201 529 3516 > >www.radvision.com > >orit@radvision.com > >-----Original Message----- > >From: Orit Levin < orit@radvision.com > > >To: internet-drafts@ietf.org < > >internet-drafts@ietf.org > > >Date: Tuesday, July 11, 2000 1:59 AM > >Subject: Request for Draft Submission > > > > > >Hello! > >I would like to submit the attached paper as the first > drafts to become an > >Informational RFC. > >Thank you, > >Orit Levin > >RADVision Inc. > >575 Corporate Drive Suite 420 > >Mahwah, NJ 07430 > >Tel: 1 201 529 4300 (230) > >Fax: 1 201 529 3516 > >www.radvision.com > >orit@radvision.com > > > > > > > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel > ------_=_NextPart_000_01C007C7.7978C77E Content-Type: text/plain; name="draft-yu-tel-url-np-00.txt" Content-Disposition: attachment; filename="draft-yu-tel-url-np-00.txt" Content-Transfer-Encoding: quoted-printable Internet Draft James Yu Document: NeuStar, Inc. Category: Informational July 2000 Extensions to the "tel" and "fax" URLs to Support Number Portability Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [RFC]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. To learn the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). Informational-Expiration on January 2001 1 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 1. Abstract Number portability (NP) allows the telephone subscribers to keep their telephone numbers when they change service provider, move to a new location, or change the subscribed services. The NP implementations in many countries presently support service provider portability for geographic numbers and non-geographical numbers. It has been identified that NP has impacts on several works-in-progress at the IETF. One of the impacts is to carry the NP related information in the SIP INVITE message. This document proposed the extensions to the "tel" and "fax" Uniform Resource Locators (URLs) to support NP so that they can be used to carry the NP related information in the Session Initiation Protocol (SIP) Request-URI. 2. Introduction This document proposes the extensions to the "tel" and "fax" Uniform Resource Locators (URLs) for supporting number portability (NP). [NP] provides an overview of the NP in the GSTN and points out the impacts of NP in several works-in-progress at the IETF Working Groups. One of the impacts is to be able to carry the NP related information in the Session Initiation Protocol (SIP) INVITE message. The NP related information includes the dialed directory number, a routing number and an indicator that indicates whether a query to the Number Portability Database (NPDB) has been performed. The routing number allows the network, either the Global Switched Telephone Network (GSTN) or the IP-based network, to route the call to the network or switch that currently serves the dialed called party number that has ported out of the donor network. The NPDB dip indicator informs the network entities downstream towards the terminating network (e.g., the network that currently serves the called party number) that NPDB dip has been performed; therefore, there is no need to dip the NPDB again. The dialed called party number is needed at the terminating switch so that the call can be terminated to a correct line card. If the routing number only points to the terminating network, the called party number would be used for another NPDB query to retrieve another routing number that is typically a network-specific routing number for routing the call to the terminating switch. 3. SIP Request-URI The SIP INVITE message contains a "Request-URI" element that is used by the SIP servers for making routing decisions. As indicated in [SIP], SIP servers may support Request-URIs with schemes other than "SIP," for example, the "tel" URI scheme. [TEL] specifies the URL schemes "tel," "fax" and "modem" for specifying the location of a terminal in the phone network and the connection types (modes of operation) that can be used to connect to that entity. By examining the SIP URL and "tel" URL, it seems that the "tel" URL is a better Informational - Expiration in January 2001 2 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 place to carry the NP related information. Since the "fax" URL may be used for fax calls, both the "tel" and "fax" URLs need to be enhanced to support NP. 4. Proposed extensions to the "tel" RUL Scheme The following shows the extensions to the "tel" URL. Only the impacted items/lines are shown below. global-phone-number =3D (no change) (no change) (no change) *1(number-portability) local-phone-number =3D (no change) (no change) (no change) (no change) future-extension) *1(number-portability) number-portability =3D ";" routing-number *1(";" = npdb-dip-indicator) routing-number =3D rn-tag "=3D" *1("+") rn-ident rn-tag =3D "rn" rn-ident =3D *15(hex excluding "F") npdi-dip-indicator =3D npdi-tag "=3D" npdi-ident npdi-tag =3D "npdi" npdi-ident =3D "yes" / "no" It is assumed that national routing number may appear with other global-phone-number information and international routing number may appear with other local-phone-number information. The routing number digit can be any hexadecimal digit except the digit "F." The routing number and the NPDB dip indicator can appear at most once if present. The routing number can contain hexadecimal digits from 0 to E. When the routing number is present, the NPDB dip indicator may or may not be present. This is because that the routing number may be present independent of NP. When the "npdi" parameter is not present, it indicates that either NPDB dip has not been performed (equivalent to npdi=3Dno) or NP is not relevant. If = a SIP server is set to perform the NPDB queries and if a received INVITE message does not contain "yes" in the "npdi" parameter, it will perform the NPDB query. The NPDB query is outside the scope of this document. The routing number received in the response (plus the "+" and the country code when necessary) will replace the routing number in the "rn" parameter if present or will be used by the new "rn" parameter if "rn" parameter is not present. The "npdi" parameter will be set to "yes" in this case. The routing number can be a global routing number (e.g., with "+" and the country code) or a local (e.g., network-specific) routing number. When the "rn" parameter is present, it must be used for making routing decisions (e.g., against the TRIP routing tables)[TRIP]. If the "rn" parameter is not present, the telephone number right after "tel:" is used as the routing number. Informational - Expiration in January 2001 3 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 It is possible that interworking between SIP and Signaling System No. 7 (SS7) Integrated Services Digital Network User Part (ISUP) is required at the border between the Global Switched Telephone Network (GSTN) and the IP-based network. For SIP to GSTN interworking and depending on the ISUP support of NP, the information in the "tel" URL will be mapped/carried in the proper ISUP parameters. For example, for the GSTN in the U.S., the routing number in the "rn" parameter is carried in the ISUP Called Party Number Parameter. The phone number after "tel:" is carried in the ISUP Generic Address Parameter. Only national numbers are carried (e.g., without the "+" and the country code) in the ISUP parameter. The "npdi" parameter that contains "yes" cause the Forward Call Indicator parameter to be properly set to indicate that NPDB has been dipped. If the terminating GSTN supports concatenated routing number and directory number (e.g., in Europe), then the routing number and the phone number are concatenated and put in the ISUP Called Party Number parameter. The NOA value will be set according the terminating GSTN's NP standards. For GSTN to IP interworking, when the ISUP signaling contains the NP related information, the NP related information is mapped to the "tel" URL. This happens for domestic calls where the originating GSTN has performed the NPDB query, or for international calls that have arrived at the terminating country's GSTN where that GSTN has performed the NPDB query. It is assumed that the GSTN routes the call via the IP-based network to the terminating switch or network in the same country, and SIP and ISUP interworking is involved. For the GSTN in the U.S., the interworking is straightforward. The indication in the ISUP Forward Call Indicator parameter that NPDB dip has been performed will set "npdi" to "yes," the number in the Called Party Number parameter plus the "+" and the country code, if a global routing number, is carried in the "rn" parameter, and called party number in the Generic Address Parameter plus the "+" and the country code, if a global phone number, appears after "tel:". For GSTN that supports concatenated routing number and directory number (e.g., in Europe), the IP entity that performs the interworking needs to know the routing number used by the GSTN so that the routing number and the directory number in the concatenated format in the ISUP Called Party Number parameter can be separate out and transported in the "rn" parameter and after "tel:" by adding the "+" and the country code to them if they are global routing number and phone numbers. 5. Proposed extension to the "fax" URL Scheme The following shows the extensions to the "fax" URL. Only the impacted items/lines are shown below. fax-global-phone =3D (no change) (no change) (no change) Informational - Expiration in January 2001 4 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 future extension) *1(number-portability) fax-local-phone =3D (no change) (no change) (no change) (no change) future-extension) *1(number-portability) number-portability =3D ";" routing-number *1(";" = npdb-dip-indicator) routing-number =3D rn-tag "=3D" *1("+") rn-ident rn-tag =3D "rn" rn-ident =3D *15(hex excluding "F") npdi-dip-indicator =3D npdi-tag "=3D" npdi-ident npdi-tag =3D "npdi" npdi-ident =3D "yes" / "no" The same discussions in Section 5 also apply to this section. 6. Examples To simply the example and to focus on the "tel" URL in the Request- URI, only the Request-Line of a complete SIP INVITE message is shown. A SIP server receives an INVITE message as shown below where +1-202-533-1234 is the dialed called party number and has been ported out of the donor network. INVITE tel:+1-202-533-1234 SIP/2.0 Assume that this SIP server is set to perform the NPDB query. Since this INVITE message does not contain the "npdi" parameter, this SIP server will perform a NPDB query. After receiving a response back from a NPDB, it formulates the following SIP INVITE message: INVITE tel:+1-202-533-1234;rn=3D+1-202-544-0000;npdi=3Dyes SIP/2.0 This SIP server then uses the "rn" parameter to make the routing decisions (e.g., using the routing number in the "rn" parameter to check against the TRIP tables to determine the terminating GSTN gateway). If the dialed called party number +1-202-533-1234 is not ported and the dialed called party number can be used as the routing number, the outbound SIP INVITE message may look like INVITE tel:+1-202-533-1234;rn=3D+1-202-533-1234;npdi=3Dyes SIP/2.0 or INVITE tel:+1-202-533-1234;npdi=3Dyes SIP/2.0 The concept is that "rn," if present, is used for making routing decisions, and the phone number after "tel:" is used if "rn" is not present. Informational - Expiration in January 2001 5 =0C Extension to the "tel" and "fax" URLs to Support NP July 2000 7. Conclusion This Internet Draft proposes extensions to the "tel" and "fax" URLs described in [TEL] to allow the SIP to carry the NP related information in the "tel" and "fax" URLs. If agreed, it is proposed to incorporate the proposed extensions in the next revision of RFC2806. REFERENCES [NP] M. Foster, T. McGarry and J. Yu, "Number Portability in the GSTN: An Overview," draft-foster-e164-gstn-np-01.txt, July 2000. [TEL] A. Vaha-Sipila, "URLs for Telephone Calls," RFC 2806, April 2000. [SIP] M. Handley, H. Schulzrinne, E. Schooler and J. Rosenberg, "SIP: Session Initiation Protocol," draft--ietf-sip- rfc2543bis-00.ps, May 2000. [TRIP] J. Rosenberg, H. Salama and M. Squire, draft-ietf-iptel-trip- 02.txt, "Telephony Routing Information Protocol (TRIP)," May 2000. Acknowledgement The author would like to thank Jonathan Rosenberg and Henning Schulzrinne for the discussion of SIP support of NP. Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into. Informational - Expiration in January 2001 6 =0C ------_=_NextPart_000_01C007C7.7978C77E-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Aug 18 11:48:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00925 for ; Fri, 18 Aug 2000 11:48:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 21018443A5; Fri, 18 Aug 2000 11:47:54 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from dnspri.npac.com (dnspri.npac.com [208.143.33.66]) by lists.bell-labs.com (Postfix) with ESMTP id E5CE944339 for ; Fri, 18 Aug 2000 11:47:50 -0400 (EDT) Received: by dnspri.npac.com; id KAA25714; Fri, 18 Aug 2000 10:47:49 -0500 (CDT) Received: from unknown(208.143.39.132) by dnspri.npac.com via smap (V5.0) id xma025361; Fri, 18 Aug 00 10:47:12 -0500 Received: by chi02.npac.com with Internet Mail Service (5.5.2448.0) id ; Fri, 18 Aug 2000 10:46:15 -0500 Message-ID: From: James Yu To: "'hsalama@cisco.com'" Cc: "'Jonathan Rosenberg'" , "'iptel@lists.bell-labs.com'" Subject: RE: [IPTEL] [TRIP] Address Families in draft-ietf-iptel-trip-03 Date: Fri, 18 Aug 2000 10:44:44 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Hussein, I checked the I-D. Section 5.1.1.3 seems to imply that "POTS numbers" are used to "identify actual POTS destinations" and that "routing numbers" are used "to identify switches and line cards in the switches." Does the sentence about "POTS numbers" imply that the POTS numbers are the telephony subscriber numbers? --------- 5.1.1.3 Routing Numbers This address family is used to represent Routing Numbers used in conjunction with Number Portability (NP). Unlike POTS Numbers, which are used to identify actual POTS destinations, Routing Numbers are used to identify switches and line cards in the switches. NP and routing Numbers are limited in scope to national boundaries. Different countries/regions define different routing number formats. The Routing Numbers address family defined herein is deemed sufficient to encompass all the different formats. -------- James > -----Original Message----- > From: Hussein F. Salama [mailto:hsalama@cisco.com] > Sent: Wednesday, August 16, 2000 4:57 PM > To: James Yu > Cc: 'Jonathan Rosenberg'; 'iptel@lists.bell-labs.com' > Subject: Re: [IPTEL] [TRIP] Address Families in > draft-ietf-iptel-trip-03 > > > > > James Yu wrote: > > > > Hussein, > > > > What needs to be clearly indicated is that it should not > happen that some > > LSs/GWs announce the reachability of subscriber "POTS > numbers" and others > > announce the reachability of "routing" POTS numbers (e.g., > LRNs) in the U.S. > > and Canada. Is the current TRIP document very clear and > specific about > > that? > > The Route Types Supported capability says: > "The Route Types Supported Capability Code lists the route types > supported in this peering session by the transmitting LS. An LS > MUST NOT use route types that are not supported by the peer LS in > any particular peering session. If the route types supported by a > peer are not satisfactory, an LS MAY terminate the peering session." > > I think we should consider replacing the word "MAY" with "SHOULD" or > "MUST." > > The above text is sufficient to prevent peer-to-peer capability > mismatch. However, it doesn't prevent mismatches across an entire > domain, because TRIP can't prevent that. May be an application note > (TRIP applicability) is needed to clarify this issue and othe similar > issues which may arise in the future. > > Hussein > > > > > > > > James > > > > > -----Original Message----- > > > From: Hussein F. Salama [mailto:hsalama@cisco.com] > > > Sent: Monday, August 14, 2000 7:13 PM > > > To: James Yu > > > Cc: 'Jonathan Rosenberg'; 'iptel@lists.bell-labs.com' > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > draft-ietf-iptel-trip-03 > > > > > > > > > James, > > > > > > James Yu wrote: > > > > > > > > Hussein, > > > > > > > > In that case, do we just advertis the "POTS number" address > > > family in the > > > > > > Yes, that should be sufficient. > > > > > > In general, TRIP defines two address families and also > allows peers to > > > negotiate which address families each peer supports. More address > > > families can be defined in the future, if needed. I think > > > that should be > > > sufficient to satisfy the needs of different applications > and regional > > > requirements. > > > > > > Hussein > > > > > > > > > > U.S. and Canada and those numbers are all "routing numbers" > > > in the format of > > > > +1+NPA+NXX? > > > > > > > > James > > > > > > > > > -----Original Message----- > > > > > From: Hussein F. Salama [mailto:hsalama@cisco.com] > > > > > Sent: Monday, August 14, 2000 4:42 PM > > > > > To: James Yu > > > > > Cc: 'Jonathan Rosenberg'; 'iptel@lists.bell-labs.com' > > > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > > > > > > > > > > > James Yu wrote: > > > > > > > > > > > > Jonathan, > > > > > > > > > > > > Under NP, the NPA+NXXs in the U.S. and Canada are the > > > > > "routing numbers" that > > > > > > are used by the PSTN to route the call. As indicated > > > > > before, the LRN for > > > > > > ported POTS number and the NPA-NXX of the non-ported POTS > > > > > numbers are used > > > > > > for routing. Those numbers are viewed as "routing numbers" > > > > > in the PSTN > > > > > > until the calls reach the destination network/switch. > > > > > > > > > > > > For a ported POTS number, the destination switch/network > > > > > retrieves the POTS > > > > > > number from the ISUP Generic Address Parameter. Note that > > > > > the LRN is > > > > > > carried in the ISUP Called Party Number (CdPN) parameter. > > > > > For a non-ported > > > > > > number, the POTS number is retrieved from the CdPN > > > > > parameter (e.g., no LRN > > > > > > is used, the "POTS number" is used for routing; therefore, > > > > > is viewed as the > > > > > > "routing number" before it reaches the destination > > > network/switch). > > > > > > > > > > > > If a switch serves several NPA+NXXs, one of the NPA+NXXs is > > > > > used as the LRN > > > > > > (note that LRN is a ten-digit number, NPA+NXX+XXXX and more > > > > > than one LRN can > > > > > > be assigned to a switch). For a gateway that can reach > > > > > this switch, the > > > > > > "routing numbers" it announces would be those NPA+NXXs > > > > > assigned to that > > > > > > switch. The "POTS numbers" it announce would be those POTS > > > > > numbers that are > > > > > > served by that switch. This would include: > > > > > > > > > > > > - All the POTS numbers that begin with those NPA+NXXs > > > > > assigned to that > > > > > > switch excluding those that have been ported out. > > > > > > - All the ported POTS numbers to that switch from other > > > switches. > > > > > > > > > > > > If a gateway can reach several switches, then aggregation > > > > > is performed. My > > > > > > understanding of the POTS numbers are that they are the > > > "subscriber > > > > > > telephone numbers." > > > > > > > > > > POTS-Numbers is just an address family. It does not imply > > > that numbers > > > > > carried in that address family must be subscriber telephone > > > > > numbers. For > > > > > example, North American LRNs can be advertised using the > > > POTS-Numbers > > > > > address family. > > > > > > > > > > Hussein > > > > > > > > > > > > > > > May be I have a misunderstanding of the definition of > > > > > > the "POTS number" address family. > > > > > > > > > > > > James > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Jonathan Rosenberg [mailto:jdrosen@dynamicsoft.com] > > > > > > > Sent: Monday, August 14, 2000 2:37 AM > > > > > > > To: James Yu > > > > > > > Cc: hsalama@cisco.com; 'iptel@lists.bell-labs.com' > > > > > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > > > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > > > > > > > Right, and thats called the "POTS Number" address family. > > > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > > > James Yu wrote: > > > > > > > > > > > > > > > > It seems that there may be a need to define the routing > > > > > > > numbers in such a > > > > > > > > way (or by implementation?) that allows easy > > > > > aggregation of "routing > > > > > > > > numbers" that contain only digits 0 through 9 > for countries > > > > > > > that don't use > > > > > > > > digits A through E in the "routing numbers." > > > > > > > > > > > > > > > > James > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: Jonathan Rosenberg > [mailto:jdrosen@dynamicsoft.com] > > > > > > > > > Sent: Friday, August 11, 2000 12:10 PM > > > > > > > > > To: hsalama@cisco.com > > > > > > > > > Cc: James Yu; 'iptel@lists.bell-labs.com' > > > > > > > > > Subject: Re: [IPTEL] [TRIP] Address Families in > > > > > > > > > draft-ietf-iptel-trip-03 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Hussein F. Salama" wrote: > > > > > > > > > > > > > > > > > > > > James, > > > > > > > > > > > > > > > > > > > > James Yu wrote: > > > > > > > > > > > > > > > > > > > > > > Hussein, > > > > > > > > > > > > > > > > > > > > > > As indicated earlier, the "POTS number" > > > address family is > > > > > > > > > a subset of > > > > > > > > > > > "routing number" address family (not in > terms of the > > > > > > > > > numbers but in terms of > > > > > > > > > > > allowable digits). Aggregation needs to be > > > done for the > > > > > > > > > "routing numbers" > > > > > > > > > > > anyway if digits A through E may appear > in the routing > > > > > > > > > numbers. So you are > > > > > > > > > > > not totally avoiding the problem. If you need to > > > > > > > > > aggregate for the routing > > > > > > > > > > > numbers and one "routing number" table can do > > > the work, > > > > > > > > > why announcing the > > > > > > > > > > > additional "POTS numbers" and managing an > additional > > > > > > > > > "POTS number table at > > > > > > > > > > > the LSs just because it is easier to > aggregate that > > > > > > > > > address family (this is > > > > > > > > > > > an "extra" work). Under country code 1, > > > digits A through > > > > > > > > > E are not used. > > > > > > > > > > > It is then easy to aggregate the "routing > > > numbers" under > > > > > > > > > country code 1. > > > > > > > > > > > > > > > > > > > > I prefer having two separate address families > > > to having a > > > > > > > > > single address > > > > > > > > > > family with two, or may be more, sets of aggregation > > > > > > > rules. Deciding > > > > > > > > > > which set of aggregation rules to use based > on the first > > > > > > > > > digit of the > > > > > > > > > > prefix is too restrictive. For example, I can > > > imagine TRIP > > > > > > > > > applications, > > > > > > > > > > with limited scope, local or national, > which advertise > > > > > > > > > numbers without > > > > > > > > > > prepending the country code to them. Hence we won't > > > > > > > have the '1' to > > > > > > > > > > decide which aggregation rules to use? > > > > > > > > > > > > > > > > > > THe other issue is that you are forced to do > > > semantic based > > > > > > > > > aggregation. > > > > > > > > > We want to > > > > > > > > > allow (but not mandate of course)aggregation of > > > numbers based > > > > > > > > > on syntax > > > > > > > > > ONLY (i.e., I have 11, 12, 13 14, ... 10, and > > > > > > > > > since there are ten digits, I can aggregate > to 1). This > > > > > > > NECESSITATES > > > > > > > > > knowing the number > > > > > > > > > of digits that exist. > > > > > > > > > > > > > > > > > > -Jonathan R. > > > > > > > > > > > > > > > > > > -- > > > > > > > > > Jonathan D. Rosenberg 72 > > > Eagle Rock Ave. > > > > > > > > > Chief Scientist > First Floor > > > > > > > > > dynamicsoft East > > > > > Hanover, NJ 07936 > > > > > > > > > jdrosen@dynamicsoft.com FAX: > > > > > (973) 952-5050 > > > > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > > > > > (732) 741-7244 > > > > > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > IPTEL mailing list > > > > > > > > > IPTEL@lists.bell-labs.com > > > > > > > > > http://lists.bell-labs.com/mailman/listinfo/iptel > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Jonathan D. Rosenberg 72 > Eagle Rock Ave. > > > > > > > Chief Scientist First Floor > > > > > > > dynamicsoft East > > > Hanover, NJ 07936 > > > > > > > jdrosen@dynamicsoft.com FAX: > > > (973) 952-5050 > > > > > > > http://www.cs.columbia.edu/~jdrosen PHONE: > > > (732) 741-7244 > > > > > > > http://www.dynamicsoft.com > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > IPTEL mailing list > > > > > > IPTEL@lists.bell-labs.com > > > > > > http://lists.bell-labs.com/mailman/listinfo/iptel > > > > > > > > > > -- > > > > > Hussein F. Salama > > > > > Cisco Systems > > > > > Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 > > > > > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 > > > > > > > > > > > -- > > > Hussein F. Salama > > > Cisco Systems > > > Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 > > > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 > > > > > > > > > _______________________________________________ > > > IPTEL mailing list > > > IPTEL@lists.bell-labs.com > > > http://lists.bell-labs.com/mailman/listinfo/iptel > > > > > -- > Hussein F. Salama > Cisco Systems > Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 > Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 > _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Aug 18 22:05:00 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA13583 for ; Fri, 18 Aug 2000 22:05:00 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BD279443B1; Fri, 18 Aug 2000 22:04:46 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id B1FAD44338 for ; Fri, 18 Aug 2000 22:04:42 -0400 (EDT) Received: from fokus.gmd.de (dhcp007 [195.37.78.135]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id EAA00317; Sat, 19 Aug 2000 04:04:35 +0200 (MET DST) Message-ID: <399DE955.C8CC7899@fokus.gmd.de> Date: Sat, 19 Aug 2000 03:56:37 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Jonathan Lennox , iptel@lists.bell-labs.com References: <3990A563.4A1DBAED@fokus.gmd.de> <14740.20555.884557.351978@ind.cs.columbia.edu> <39946C1F.19E2C6C5@dynamicsoft.com> <39989659.29B626D7@fokus.gmd.de> <3998C0DB.D0A493B1@dynamicsoft.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] CPL @ Clients ? Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit draft-ietf-iptel-cpl-02 states "Implementations of CPL are expected to take place both in ... servers and in ... clients" ... "This document primarily addresses the usage in servers". Does it mean that CPL usage in end-devices is not documented in this I-D but CPL could be used so as is? Or are any CPL extensions anticipated for such usage? -Jiri -- Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sat Aug 19 01:07:33 2000 Received: 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 BAA16345 for ; Sat, 19 Aug 2000 01:07:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 24C3144339; Sat, 19 Aug 2000 01:07:17 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 4202C44338 for ; Sat, 19 Aug 2000 01:07:14 -0400 (EDT) Received: from dynamicsoft.com (1Cust182.tnt1.freehold.nj.da.uu.net [63.17.113.182]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA14153; Sat, 19 Aug 2000 01:08:43 -0400 (EDT) Message-ID: <399E1768.ACB818F3@dynamicsoft.com> Date: Sat, 19 Aug 2000 01:13:12 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jiri Kuthan Cc: Jonathan Lennox , iptel@lists.bell-labs.com Subject: Re: [IPTEL] CPL @ Clients ? References: <3990A563.4A1DBAED@fokus.gmd.de> <14740.20555.884557.351978@ind.cs.columbia.edu> <39946C1F.19E2C6C5@dynamicsoft.com> <39989659.29B626D7@fokus.gmd.de> <3998C0DB.D0A493B1@dynamicsoft.com> <399DE955.C8CC7899@fokus.gmd.de> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jiri Kuthan wrote: > > draft-ietf-iptel-cpl-02 states "Implementations of CPL are expected > to take place both in ... servers and in ... clients" ... > "This document primarily addresses the usage in servers". > > Does it mean that CPL usage in end-devices is not documented in > this I-D but CPL could be used so as is? Yes. Or are any > CPL extensions anticipated for such usage? There are additional things that might make sense in end devices (distinctive ring, for example), but are not covered in CPL as CPL is meant for servers. Currently, there has been no discussion of adding such things to CPL. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Sun Aug 20 11:47:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08601 for ; Sun, 20 Aug 2000 11:47:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B19D644338; Sun, 20 Aug 2000 11:47:34 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net [38.202.36.29]) by lists.bell-labs.com (Postfix) with ESMTP id 324B244336 for ; Sun, 20 Aug 2000 11:47:32 -0400 (EDT) Received: from orit ([172.146.154.128]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20000820154731.VNGX17786.hvmta01-stg@orit>; Sun, 20 Aug 2000 11:47:31 -0400 Message-ID: <001701c00ac0$11b8dba0$beb4fea9@orit.us.radvision.com> Reply-To: "Orit Levin" From: "Orit Levin" To: "IPTEL WG" , Date: Sun, 20 Aug 2000 11:23:07 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000C_01C00A99.03B5E420" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Subject: [IPTEL] [TRIP] The "Application Protocol" field Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. ------=_NextPart_000_000C_01C00A99.03B5E420 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello! Reading through the TRIP specification, I got a feeling that RAS and = Annex G protocols are not, really, good "candidates" for the TRIP = "Application Protocol". (I am sure, we are going to have an interesting = discussion on that, during the ITU meeting in Portland, this week :-) On the other hand, an architecture with "Call Signaling Proxies" = performing translation between SIP and H.323 Signaling Protocols and = being advertised as "NextHopServer", seems to fit very nicely into the = TRIP architecture. Even, having a joined Routing DB, seems to be a = natural thing. Then, reading till the end, I came across an "open issue" listed as a = "mapping of application protocols". My questions would be: - Is it about the same topic? - How difficult it seems to the authors? - How far down the road, this topic has been addressed/thought of? Thanks,=20 Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com ------=_NextPart_000_000C_01C00A99.03B5E420 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello!
Reading through the TRIP specification, I got a = feeling=20 that RAS and Annex G protocols are not, really, good "candidates" for = the TRIP=20 "Application Protocol". (I am sure, we are going to=20 have an interesting discussion on that, during the ITU meeting in=20 Portland, this week :-)
On the other hand, an architecture with "Call = Signaling=20 Proxies" performing translation between SIP and H.323 Signaling = Protocols and=20 being advertised as "NextHopServer", seems to fit very nicely into the = TRIP=20 architecture. Even, having a joined Routing DB, seems to be a natural=20 thing.
Then, reading till the end, I came across an "open = issue"=20 listed as a "mapping of application protocols".
My questions would be:
- Is it about the same topic?
- How difficult it seems to the = authors?
- How far down the road, this topic has=20 been addressed/thought of?
Thanks, 
Orit Levin
RADVision Inc.
575 Corporate Drive = Suite=20 420
Mahwah, NJ 07430
Tel: 1 201 529 4300  (230)
Fax: 1 201 = 529=20 3516
www.radvision.com
orit@radvision.com
------=_NextPart_000_000C_01C00A99.03B5E420-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Sun Aug 20 18:04:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA10660 for ; Sun, 20 Aug 2000 18:04:38 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 84A2844338; Sun, 20 Aug 2000 18:04:18 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from smtp-out1.bellatlantic.net (smtp-out1.bellatlantic.net [199.45.39.156]) by lists.bell-labs.com (Postfix) with ESMTP id 9D49344336 for ; Sun, 20 Aug 2000 18:04:15 -0400 (EDT) Received: from cs.columbia.edu (adsl-151-198-20-48.bellatlantic.net [151.198.20.48]) by smtp-out1.bellatlantic.net (8.9.1/8.9.1) with ESMTP id SAA05741; Sun, 20 Aug 2000 18:04:08 -0400 (EDT) Message-ID: <39A055CA.BB7D14DA@cs.columbia.edu> Date: Sun, 20 Aug 2000 18:03:54 -0400 From: Henning Schulzrinne X-Mailer: Mozilla 4.7 [en]C-CCK-MCD BA45DSL (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Lennox Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] CPL features References: <14746.50714.739782.573450@grandcentral.cs.columbia.edu> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit There are two, I believe, reasonable ways to look at non-standard information: 1) Italian-style ("what isn't illegal is allowed"): A server could simply ignore the switch if it doesn't understand the information/header. All scripts work, but the same call may be processed differently. Also allows better functionality on some ("better") servers. This has been pretty much the HTML approach, so that even a Mosaic 1.0 browser can, in theory, render complex web pages, just without a lot of formatting. 2) German-style ("what isn't allowed explicitly is verboten"): Server rejects scripts that have unknown information/header switches. Opposite trade-offs. It is probably easier to switch later from German-style to Italian, without syntax change. A different, but related discussion is how (or if) we want to handle extensions in the future. I think SIP has shown that thinking about extensions ahead of time is valuable. Should every new 'header' field, for example, require rev'ing the version number of CPL? Jonathan Lennox wrote: > > [My e-mail was down for five days...I'm replying based on the web archive, > so apologies for any infelicities in formatting and the loss of references > headers.] > > On Tue, 15 Aug 2000, Jiri Kuthan wrote to iptel@lists.bell-labs.com: > > > Checking the scripts by servers does not seem so helpful to me: > > 1) support for arbitrary headers accomplishes dealing with fields unknown > > at the time of writing specification and implementation; > > checking header fields if they are well-known beats this purpose; > > > It's a trade-off between CPL's ability to adapt to new SIP extensions > > and the built-in language ability to eliminate unwanted bugs. I personally > > prefer the former given SIP development pace. Unwanted bugs may be still > > prevented by tools used for generating CPL scripts. > > I'd like to re-iterate Jonathan R.'s point that CPL is *not* just for SIP. > The spec is written with a lot of H.323 bindings in it, and I've also heard > reports of people using it for PSTN calls. > > The information in the switches, therefore, doesn't correspond to SIP > headers. Instead, it's a textual representation of information in the call > setup request. This is often the *same* as how the information is > represented in the SIP header, because there's no point in being > gratuitously incompatible, but a major design requirement of CPL was to be > protocol-neutral in at least its core features. > > If you want finer-grained control specifically targeted to SIP, SIP-CGI and > SIP Servlets are both available. CPL was never intended to be the sole > answer to all of IP telephony service creation. > > > 2) the rejection mechanism may be difficult if you use, for example, > > FTP to upload the CPL scripts. > > Clearly there always has to be *some* point when a server notices that a > script is invalid, it ought to have some way of reporting this failure in a > more clever way than sending a failure response back to the caller. It > seems like good programming practice to notice this, if you can, earlier > than at the last minute, so the script owner can fix the problem before he > or she loses calls. I'm not recommending some sort of active negotiation of > script capabilities. > > -- > Jonathan Lennox > lennox@cs.columbia.edu > > _______________________________________________ > 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 Aug 21 08:48:48 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA00057 for ; Mon, 21 Aug 2000 08:48:48 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 981844433D; Mon, 21 Aug 2000 08:48:27 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id 1594644336 for ; Mon, 21 Aug 2000 08:48:24 -0400 (EDT) Received: from fokus.gmd.de (dhcp007 [195.37.78.135]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id OAA28543; Mon, 21 Aug 2000 14:48:14 +0200 (MET DST) Message-ID: <39A12434.E35778D2@fokus.gmd.de> Date: Mon, 21 Aug 2000 14:44:36 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: Jonathan Lennox , iptel@lists.bell-labs.com Subject: Re: [IPTEL] CPL @ Clients ? References: <3990A563.4A1DBAED@fokus.gmd.de> <14740.20555.884557.351978@ind.cs.columbia.edu> <39946C1F.19E2C6C5@dynamicsoft.com> <39989659.29B626D7@fokus.gmd.de> <3998C0DB.D0A493B1@dynamicsoft.com> <399DE955.C8CC7899@fokus.gmd.de> <399E1768.ACB818F3@dynamicsoft.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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: [...] > There are additional things that might make sense in end devices > (distinctive ring, for example), but are not covered in CPL as CPL is > meant for servers. Currently, there has been no discussion of adding > such things to CPL. If we wanted to deploy CPL in end-devices, the missing piece would be a kind of 'ring' command, most likely loosely coupled with user interface. For example:
An alternative would be to define ringing as default action in end-devices. Drawback: cannot be parameterized. Reasons for running CPL in end-devices: - call processing logic works even if signaling does not go through proxies; - call processing overhead distributed to end-devices Jiri -- Jiri Kuthan http://www.fokus.gmd.de/usr/kuthan Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Mon Aug 21 16:11:22 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08341 for ; Mon, 21 Aug 2000 16:11:22 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 0EA36443CC; Mon, 21 Aug 2000 16:10:23 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from sj-msg-core-2.cisco.com (sj-msg-core-2.cisco.com [171.69.43.88]) by lists.bell-labs.com (Postfix) with ESMTP id DF89544370 for ; Mon, 21 Aug 2000 16:10:20 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id NAA01530; Mon, 21 Aug 2000 13:10:38 -0700 (PDT) Received: from cisco.com (dhcp-171-71-147-128.cisco.com [171.71.147.128]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AFH00009 (AUTH hsalama); Mon, 21 Aug 2000 13:10:27 -0700 (PDT) Message-ID: <39A18BE8.334B7285@cisco.com> Date: Mon, 21 Aug 2000 13:07:04 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: Orit Levin Cc: IPTEL WG , sip-h323@egroups.com Subject: Re: [IPTEL] [TRIP] The "Application Protocol" field References: <001701c00ac0$11b8dba0$beb4fea9@orit.us.radvision.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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Orit, > Orit Levin wrote: > > Hello! > Reading through the TRIP specification, I got a feeling that RAS and > Annex G protocols are not, really, good "candidates" for the TRIP > "Application Protocol". (I am sure, we are going to have an > interesting discussion on that, during the ITU meeting in > Portland, this week :-) > On the other hand, an architecture with "Call Signaling Proxies" > performing translation between SIP and H.323 Signaling Protocols and > being advertised as "NextHopServer", seems to fit very nicely into the > TRIP architecture. Even, having a joined Routing DB, seems to be a > natural thing. > Then, reading till the end, I came across an "open issue" listed as a > "mapping of application protocols". > My questions would be: > - Is it about the same topic? Yes, if a TRIP LS translates from one application protocol to another, this necessitates the presence of an proxy that's capable of translating between the two application protocols. > - How difficult it seems to the authors? From TRIP perspective, this is straightforward. Before sending an UPDATE to an external peer, a TRIP LS simply replaces one application protocol with a different application protocol in the ReachableRoutes attribute. Hussein > - How far down the road, this topic has been addressed/thought of? > Thanks, > Orit Levin > RADVision Inc. > 575 Corporate Drive Suite 420 > Mahwah, NJ 07430 > Tel: 1 201 529 4300 (230) > Fax: 1 201 529 3516 > www.radvision.com > orit@radvision.com -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Aug 22 14:33:38 2000 Received: 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 OAA12668 for ; Tue, 22 Aug 2000 14:33:37 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id F3B354438C; Tue, 22 Aug 2000 14:33:13 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id B779344389 for ; Tue, 22 Aug 2000 14:33:10 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id MAA14392; Tue, 22 Aug 2000 12:18:23 -0400 (EDT) Message-ID: <39A2A8EA.9002EDAE@dynamicsoft.com> Date: Tue, 22 Aug 2000 12:23:06 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: sip-h323@egroups.com Cc: IPTEL WG References: <001701c00ac0$11b8dba0$beb4fea9@orit.us.radvision.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] Re: [sip-h323] [TRIP] The "Application Protocol" field Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit > Orit Levin wrote: > > Hello! > Reading through the TRIP specification, I got a feeling that RAS and > Annex G protocols are not, really, good "candidates" for the TRIP > "Application Protocol". (I am sure, we are going to have an > interesting discussion on that, during the ITU meeting in > Portland, this week :-) We have gotten very mixed input from our H.323 experts on this. Nearly a year ago, a number of folks said RAS was not a good candidate. Recently, Paul Jones insisted quite strongly that both RAS and Annex G get added in. Now, you believe they should not be there. I really want to get this resolved. TRIP is nearly finished. Any harm in keeping it in? If it doesn't get used, so be it. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Wed Aug 23 01:01:40 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22939 for ; Wed, 23 Aug 2000 01:01:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 14E084433F; Wed, 23 Aug 2000 01:00:13 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id D1EB644336 for ; Wed, 23 Aug 2000 01:00:09 -0400 (EDT) Received: from dynamicsoft.com (1Cust189.tnt4.freehold.nj.da.uu.net [63.36.112.189]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id BAA20571; Wed, 23 Aug 2000 01:01:43 -0400 (EDT) Message-ID: <39A35BD5.B2FF4293@dynamicsoft.com> Date: Wed, 23 Aug 2000 01:06:29 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jiri Kuthan Cc: Jonathan Lennox , iptel@lists.bell-labs.com Subject: Re: [IPTEL] CPL @ Clients ? References: <3990A563.4A1DBAED@fokus.gmd.de> <14740.20555.884557.351978@ind.cs.columbia.edu> <39946C1F.19E2C6C5@dynamicsoft.com> <39989659.29B626D7@fokus.gmd.de> <3998C0DB.D0A493B1@dynamicsoft.com> <399DE955.C8CC7899@fokus.gmd.de> <399E1768.ACB818F3@dynamicsoft.com> <39A12434.E35778D2@fokus.gmd.de> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit I'm sure there are other things too besides distinctive ring. In any case, we agreed to not worry about that right now. The objective at the moment is to complete the CPL spec along the model and requirements we have defined. -Jonathan R. Jiri Kuthan wrote: > > Jonathan Rosenberg wrote: > [...] > > There are additional things that might make sense in end devices > > (distinctive ring, for example), but are not covered in CPL as CPL is > > meant for servers. Currently, there has been no discussion of adding > > such things to CPL. > > If we wanted to deploy CPL in end-devices, the missing piece would be > a kind of 'ring' command, most likely loosely coupled with user > interface. For example: > >
> > > > > > > > >
> > An alternative would be to define ringing as default action > in end-devices. Drawback: cannot be parameterized. > > Reasons for running CPL in end-devices: > - call processing logic works even if signaling does not go > through proxies; > - call processing overhead distributed to end-devices > > Jiri > > -- > Jiri Kuthan http://www.fokus.gmd.de/usr/kuthan > Internet Telephony: http://www.fokus.gmd.de/glone/projects/ipt > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Wed Aug 23 11:41:18 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15379 for ; Wed, 23 Aug 2000 11:41:15 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id AF37A44344; Wed, 23 Aug 2000 11:40:55 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from rly-ip02.mx.aol.com (rly-ip02.mx.aol.com [152.163.225.160]) by lists.bell-labs.com (Postfix) with ESMTP id D457C44336 for ; Wed, 23 Aug 2000 11:40:52 -0400 (EDT) Received: from tot-ta.proxy.aol.com (tot-ta.proxy.aol.com [152.163.205.1]) by rly-ip02.mx.aol.com (8.8.8/8.8.8/AOL-5.0.0) with ESMTP id LAA20371; Wed, 23 Aug 2000 11:40:03 -0400 (EDT) Received: from orit (ACA56DFD.ipt.aol.com [172.165.109.253]) by tot-ta.proxy.aol.com (8.10.0/8.10.0) with SMTP id e7NFe2W15407; Wed, 23 Aug 2000 11:40:02 -0400 (EDT) Message-ID: <001501c00d1a$8dacd980$8901010a@orit.itudomain> Reply-To: "Orit Levin" From: "Orit Levin" To: Cc: "IPTEL WG" Subject: Re: [IPTEL] Re: [sip-h323] [TRIP] The "Application Protocol" field Date: Wed, 23 Aug 2000 11:55:22 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3110.1 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 X-Apparently-From: OritOrit@aol.com Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Having unused application fields doesn't introduce a real problem. If there are uses of H.225.0 RAS and Annex G protocols, as the application protocols of TRIP, hopefully they will be described in H.323 "Annex O" and published as an informational RFC. The assumption here is that this doesn't affect the TRIP specification itself. On the other hand, a "mapping" between the application protocols by a Location Server, allowing for a common database, may be a useful thing to specify as a part (or a Annex) of TRIP. Any inputs for this direction? Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit@radvision.com -----Original Message----- From: Jonathan Rosenberg To: sip-h323@egroups.com Cc: IPTEL WG Date: Tuesday, August 22, 2000 2:33 PM Subject: [IPTEL] Re: [sip-h323] [TRIP] The "Application Protocol" field > > >> Orit Levin wrote: >> >> Hello! >> Reading through the TRIP specification, I got a feeling that RAS and >> Annex G protocols are not, really, good "candidates" for the TRIP >> "Application Protocol". (I am sure, we are going to have an >> interesting discussion on that, during the ITU meeting in >> Portland, this week :-) > >We have gotten very mixed input from our H.323 experts on this. > >Nearly a year ago, a number of folks said RAS was not a good candidate. > >Recently, Paul Jones insisted quite strongly that both RAS and Annex G >get added in. > >Now, you believe they should not be there. > >I really want to get this resolved. TRIP is nearly finished. Any harm in >keeping it in? If it doesn't get used, so be it. > >-Jonathan R. > >-- >Jonathan D. Rosenberg 72 Eagle Rock Ave. >Chief Scientist First Floor >dynamicsoft East Hanover, NJ 07936 >jdrosen@dynamicsoft.com FAX: (973) 952-5050 >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 >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 Wed Aug 23 13:43:39 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19588 for ; Wed, 23 Aug 2000 13:43:39 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id B9B2444354; Wed, 23 Aug 2000 13:43:09 -0400 (EDT) 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 BCA914433F for ; Wed, 23 Aug 2000 13:43:06 -0400 (EDT) Received: from mira-sjcm-2.cisco.com (mira-sjcm-2.cisco.com [171.69.43.98]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id KAA11764; Wed, 23 Aug 2000 10:43:24 -0700 (PDT) Received: from cisco.com ([10.19.104.245]) by mira-sjcm-2.cisco.com (Mirapoint) with ESMTP id AFH22774 (AUTH hsalama); Wed, 23 Aug 2000 10:43:13 -0700 (PDT) Message-ID: <39A40C63.DD19866F@cisco.com> Date: Wed, 23 Aug 2000 10:39:47 -0700 From: "Hussein F. Salama" Reply-To: hsalama@cisco.com X-Mailer: Mozilla 4.73 [en]C-CCK-MCD (WinNT; U) X-Accept-Language: en,arabic MIME-Version: 1.0 To: Orit Levin Cc: sip-h323@egroups.com, IPTEL WG Subject: Re: [IPTEL] Re: [sip-h323] [TRIP] The "Application Protocol" field References: <001501c00d1a$8dacd980$8901010a@orit.itudomain> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Orit Levin wrote: > > Having unused application fields doesn't introduce a real problem. > If there are uses of H.225.0 RAS and Annex G protocols, as the application > protocols of TRIP, > hopefully they will be described in H.323 "Annex O" and published as an > informational RFC. > The assumption here is that this doesn't affect the TRIP specification > itself. > > On the other hand, a "mapping" between the application protocols by a > Location Server, allowing for a common database, may be a useful thing to > specify as a part (or a Annex) of TRIP. Any inputs for this direction? The TRIP draft will mention that a TRIP LS may map between application protocols. However, it will not discuss applications that will make use of this mapping. Providing a few example applications in Annex O would be helpful. Hussein > > Orit Levin > RADVision Inc. > 575 Corporate Drive Suite 420 > Mahwah, NJ 07430 > Tel: 1 201 529 4300 (230) > Fax: 1 201 529 3516 > www.radvision.com > orit@radvision.com > -----Original Message----- > From: Jonathan Rosenberg > To: sip-h323@egroups.com > Cc: IPTEL WG > Date: Tuesday, August 22, 2000 2:33 PM > Subject: [IPTEL] Re: [sip-h323] [TRIP] The "Application Protocol" field > > > > > > >> Orit Levin wrote: > >> > >> Hello! > >> Reading through the TRIP specification, I got a feeling that RAS and > >> Annex G protocols are not, really, good "candidates" for the TRIP > >> "Application Protocol". (I am sure, we are going to have an > >> interesting discussion on that, during the ITU meeting in > >> Portland, this week :-) > > > >We have gotten very mixed input from our H.323 experts on this. > > > >Nearly a year ago, a number of folks said RAS was not a good candidate. > > > >Recently, Paul Jones insisted quite strongly that both RAS and Annex G > >get added in. > > > >Now, you believe they should not be there. > > > >I really want to get this resolved. TRIP is nearly finished. Any harm in > >keeping it in? If it doesn't get used, so be it. > > > >-Jonathan R. > > > >-- > >Jonathan D. Rosenberg 72 Eagle Rock Ave. > >Chief Scientist First Floor > >dynamicsoft East Hanover, NJ 07936 > >jdrosen@dynamicsoft.com FAX: (973) 952-5050 > >http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > >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 -- Hussein F. Salama Cisco Systems Mail Stop SJC6/3, 170 W. Tasman Drive, San Jose, CA 95134 Voice: +1 (408) 527-7147, Fax: +1 (408) 527-1714 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Aug 23 14:04:46 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20201 for ; Wed, 23 Aug 2000 14:04:46 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 562274434E; Wed, 23 Aug 2000 14:04:29 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from nuplanet.bitscout.com (gnatplanet.bitscout.com [198.137.170.30]) by lists.bell-labs.com (Postfix) with ESMTP id 75BBE4434E for ; Wed, 23 Aug 2000 13:49:15 -0400 (EDT) Received: from wrkplanet ([10.173.17.30]) by nuplanet.bitscout.com (2.0 Build 2119 (Berkeley 8.8.4)/8.8.4) with ESMTP id NAA01282 for ; Wed, 23 Aug 2000 13:40:00 -0400 Message-Id: <4.2.0.58.20000823134736.035b0630@10.173.17.1> X-Sender: jsteer@10.173.17.1 (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 23 Aug 2000 13:49:12 -0400 To: IPTEL@lists.bell-labs.com From: Jon Steer Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [IPTEL] CPL Implementations? Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Hi, Do there currently exist any working implementations of CPL? Layered on a soft-switch or SIP Server? regards, jon Jon Steer -- CTO http://www.tsemantics.com/ T!Semantics ,Inc 40 Berkeley St, Nashua N.H. 03064 phone:(603)889-1185 x203 video: (603)889-1125 fax: (603)-883-9365 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Aug 23 14:20:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20570 for ; Wed, 23 Aug 2000 14:20:45 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 9B9824433F; Wed, 23 Aug 2000 14:18:23 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14]) by lists.bell-labs.com (Postfix) with ESMTP id 781B04433A for ; Wed, 23 Aug 2000 14:18:20 -0400 (EDT) Received: from fokus.gmd.de (dhcp007 [195.37.78.135]) by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id UAA24247; Wed, 23 Aug 2000 20:18:13 +0200 (MET DST) Message-ID: <39A412AE.850D8767@fokus.gmd.de> Date: Wed, 23 Aug 2000 20:06:38 +0200 From: Jiri Kuthan X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon Steer Cc: IPTEL@lists.bell-labs.com Subject: Re: [IPTEL] CPL Implementations? References: <4.2.0.58.20000823134736.035b0630@10.173.17.1> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Check www.indigosw.com. Jiri Jon Steer wrote: > > Hi, > > Do there currently exist any working implementations of CPL? _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Aug 23 15:33:23 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22044 for ; Wed, 23 Aug 2000 15:33:23 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 6F10244354; Wed, 23 Aug 2000 15:33:15 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id CCE2244336 for ; Wed, 23 Aug 2000 15:33:11 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id PAA25536; Wed, 23 Aug 2000 15:34:54 -0400 (EDT) Message-ID: <39A42696.25FA4E6D@dynamicsoft.com> Date: Wed, 23 Aug 2000 15:31:34 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon Steer Cc: IPTEL@lists.bell-labs.com Subject: Re: [IPTEL] CPL Implementations? References: <4.2.0.58.20000823134736.035b0630@10.173.17.1> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit dynamicsoft has one as well, http://www.dynamicsoft.com. -Jonathan R. Jon Steer wrote: > > Hi, > > Do there currently exist any working implementations of CPL? > Layered on a soft-switch or SIP Server? > > regards, > jon > > Jon Steer -- CTO > http://www.tsemantics.com/ > T!Semantics ,Inc 40 Berkeley St, Nashua N.H. 03064 > phone:(603)889-1185 x203 video: (603)889-1125 fax: (603)-883-9365 > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Thu Aug 24 04:06:59 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12858 for ; Thu, 24 Aug 2000 04:06:59 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id EB90344343; Thu, 24 Aug 2000 04:06:36 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 6501244336 for ; Thu, 24 Aug 2000 04:06:06 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id JAA02232; Thu, 24 Aug 2000 09:02:46 +0100 (BST) Message-ID: <39A4D6A7.178B4A5E@ubiquity.net> Date: Thu, 24 Aug 2000 09:02:47 +0100 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jon Steer Cc: IPTEL@lists.bell-labs.com Subject: Re: [IPTEL] CPL Implementations? References: <4.2.0.58.20000823134736.035b0630@10.173.17.1> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Too join the AOL me too club, Ubiquity (http://www.ubiquity.net) support CPL (draft 02) as a module in our Application Services Broker. James Undery Jon Steer wrote: > Hi, > > Do there currently exist any working implementations of CPL? > Layered on a soft-switch or SIP Server? > > regards, > jon > > Jon Steer -- CTO > http://www.tsemantics.com/ > T!Semantics ,Inc 40 Berkeley St, Nashua N.H. 03064 > phone:(603)889-1185 x203 video: (603)889-1125 fax: (603)-883-9365 > > _______________________________________________ > 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 Aug 24 05:55:08 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13608 for ; Thu, 24 Aug 2000 05:55:08 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 7EE6B4436E; Thu, 24 Aug 2000 05:53:42 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ix.netcorps.com (ix.netcorps.com [207.1.125.106]) by lists.bell-labs.com (Postfix) with ESMTP id 827EF44336 for ; Thu, 24 Aug 2000 05:53:39 -0400 (EDT) Received: from indigosw.com (adsl-1561.turboline.skynet.be [194.78.202.25]) by ix.netcorps.com (8.9.0/8.9.0) with ESMTP id CAA12005 for ; Thu, 24 Aug 2000 02:53:30 -0700 (PDT) Message-ID: <39A4F1A6.87F7A386@indigosw.com> Date: Thu, 24 Aug 2000 11:57:58 +0200 From: dENIS Vandersteene Organization: Indigo Software X-Mailer: Mozilla 4.72 [en] (Windows NT 5.0; I) X-Accept-Language: en MIME-Version: 1.0 To: iptel Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: [IPTEL] supporting CPL versions Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 8bit Hi there, Are we supposed to support all the versions of CPL (00,01,02) on the servers side, or, as I guess, do we just have to support the latest version of the draft, and refuse any CPL-script compliant to an older version? (this is important as the time-switch has been completly changed). thanks, dENIS -- Denis Vandersteene Software Engineer Indigo Software 50 Rue Wiertz Brussels, 1050 – Belgium Tel. +32 2 230 35 94 dENIS@indigosw.com http://www.indigosw.com -------------------------------------------- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Aug 24 06:18:19 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA13885 for ; Thu, 24 Aug 2000 06:18:19 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C218E4437B; Thu, 24 Aug 2000 06:17:19 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 4558F44378 for ; Thu, 24 Aug 2000 06:17:16 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id LAA19540; Thu, 24 Aug 2000 11:15:16 +0100 (BST) Message-ID: <39A4F5B4.BD3E3EE2@ubiquity.net> Date: Thu, 24 Aug 2000 11:15:16 +0100 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: dENIS Vandersteene Cc: iptel Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit dENIS Vandersteene wrote: > Hi there, > > Are we supposed to support all the versions of CPL (00,01,02) on the > servers side, or, as I guess, do we just have to support the latest > version of the draft, and refuse any CPL-script compliant to an older > version? (this is important as the time-switch has been completly > changed). > Hopefully this will become irrelevant once the Internet Draft becomes a RFC, however I hope the problem of the complexity of time zones can be resolved. The solution I favour is a far simplified version where the script specifies an offset (say from GMT) and the problem of time zone changes is addressed by re-registering. I think this is acceptable because unlike calendar events where it is reasonable to expect events to be stored for years, I don't see registrations of scripts lasting that long (in the case of users scripts). This would simplify CPL dramatically yet still allow intelligent end points to readjust scripts when time zone changes occur if required. James Undery _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Aug 24 07:51:54 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15264 for ; Thu, 24 Aug 2000 07:51:53 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 58D1C44366; Thu, 24 Aug 2000 07:51:47 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from web117.yahoomail.com (web117.yahoomail.com [205.180.60.91]) by lists.bell-labs.com (Postfix) with SMTP id 48D2F44336 for ; Thu, 24 Aug 2000 07:51:44 -0400 (EDT) Received: (qmail 25022 invoked by uid 60001); 24 Aug 2000 11:51:29 -0000 Message-ID: <20000824115129.25021.qmail@web117.yahoomail.com> Received: from [209.226.172.70] by web117.yahoomail.com; Thu, 24 Aug 2000 04:51:29 PDT Date: Thu, 24 Aug 2000 04:51:29 -0700 (PDT) From: Tom Gray Subject: Re: [IPTEL] supporting CPL versions To: James Undery , tom_gray_intp@yahoo.com, dENIS Vandersteene Cc: iptel 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com --- James Undery wrote: > > > Hopefully this will become irrelevant once the > Internet Draft becomes a RFC, > however I hope the problem of the complexity of time > zones can be resolved. > The solution I favour is a far simplified version > where the script specifies > an offset (say from GMT) and the problem of time > zone changes is addressed > by re-registering. I think this is acceptable > because unlike calendar events > where it is reasonable to expect events to be stored > for years, I don't see > registrations of scripts lasting that long (in the > case of users scripts). > This would simplify CPL dramatically yet still allow > intelligent end points > to readjust scripts when time zone changes occur if > required. This raises the question of the cooperation between a user end point system and a CPL server. Using the discussion above as an example, this seems to be a far more flexible way of providing functionality than trying to provide all possible conditions in a server script. The time zone issue is only the most visible aspect of this. __________________________________________________ Do You Yahoo!? Yahoo! Mail - Free email you can access from anywhere! http://mail.yahoo.com/ _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Thu Aug 24 09:50:14 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17056 for ; Thu, 24 Aug 2000 09:50:13 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E2C9E44368; Thu, 24 Aug 2000 09:49:29 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id EC93844336 for ; Thu, 24 Aug 2000 09:49:26 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id JAA01168; Thu, 24 Aug 2000 09:50:22 -0400 (EDT) Message-ID: <39A5275C.3AADBE1F@dynamicsoft.com> Date: Thu, 24 Aug 2000 09:47:08 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Undery Cc: dENIS Vandersteene , iptel Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Undery wrote: > > dENIS Vandersteene wrote: > > > Hi there, > > > > Are we supposed to support all the versions of CPL (00,01,02) on the > > servers side, or, as I guess, do we just have to support the latest > > version of the draft, and refuse any CPL-script compliant to an older > > version? (this is important as the time-switch has been completly > > changed). > > > > Hopefully this will become irrelevant once the Internet Draft becomes a RFC, > however I hope the problem of the complexity of time zones can be resolved. > The solution I favour is a far simplified version where the script specifies > an offset (say from GMT) and the problem of time zone changes is addressed > by re-registering. I think this is acceptable because unlike calendar events > where it is reasonable to expect events to be stored for years, I don't see > registrations of scripts lasting that long (in the case of users scripts). > This would simplify CPL dramatically yet still allow intelligent end points > to readjust scripts when time zone changes occur if required. There are two major complexities in the current time switch, actually. The timezone issue is one of them, and another is the recurrence rules. Nearly as I can tell, it is pretty much impossible to answer the question "is the current time within the interval of one of the repititions of the event" without computing all of the start times for the event repitions after dtstart, and then checking if the current time is within the duration of each event. This quickly leads to tons of computations as the current time gradually moves farther away from the dtstart value. Maybe I'm wrong (I wish i were).... this is based on the libical implementation which apparently does this kind of thing. I understand the desire to be compatible with iCal, but I fear that no one will implement this thing completely, and even fewer folks will implement it correctly. Is there any way to simplify and retain some level of interoperability with ical? What if we keep the time and duration formats, and allow for repition, but eliminate the "by*" parameters which is most of the nightmare of this thing? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Thu Aug 24 10:54:34 2000 Received: 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 KAA18381 for ; Thu, 24 Aug 2000 10:54:33 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4E4C84439B; Thu, 24 Aug 2000 10:51:53 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id ADCF544344 for ; Thu, 24 Aug 2000 10:51:44 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id PAA13530; Thu, 24 Aug 2000 15:49:22 +0100 (BST) Message-ID: <39A535F1.48928278@ubiquity.net> Date: Thu, 24 Aug 2000 15:49:21 +0100 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: dENIS Vandersteene , iptel Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> <39A5275C.3AADBE1F@dynamicsoft.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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > > There are two major complexities in the current time switch, actually. > The timezone issue is one of them, and another is the recurrence rules. Definitely. > > I understand the desire to be compatible with iCal, but I fear that no > one will implement this thing completely, and even fewer folks will > implement it correctly. Is there any way to simplify and retain some > level of interoperability with ical? What if we keep the time and > duration formats, and allow for repition, but eliminate the "by*" > parameters which is most of the nightmare of this thing? > From a quick first glance this would appear to be a good solution, however, I am less convinced about simplifying recurrence this way, principally because I like the idea of specifying the last concepts like "the last friday of the month". I also understand that compatibility with iCalendar may be nice from a philosophical viewpoint, but, as a CPL implementor it is too complex for my needs and I would prefer to return to something closer to the syntax of draft 01 for time nodes. James Undery _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Aug 25 01:00:51 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00387 for ; Fri, 25 Aug 2000 01:00:51 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3408C44392; Fri, 25 Aug 2000 01:00:28 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 311544433A for ; Fri, 25 Aug 2000 01:00:25 -0400 (EDT) Received: from dynamicsoft.com (1Cust224.tnt1.freehold.nj.da.uu.net [63.17.113.224]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id AAA08996; Fri, 25 Aug 2000 00:58:21 -0400 (EDT) Message-ID: <39A5FC2D.F49020AB@dynamicsoft.com> Date: Fri, 25 Aug 2000 00:55:09 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: James Undery Cc: dENIS Vandersteene , iptel Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> <39A5275C.3AADBE1F@dynamicsoft.com> <39A535F1.48928278@ubiquity.net> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit James Undery wrote: > > > I understand the desire to be compatible with iCal, but I fear that no > > one will implement this thing completely, and even fewer folks will > > implement it correctly. Is there any way to simplify and retain some > > level of interoperability with ical? What if we keep the time and > > duration formats, and allow for repition, but eliminate the "by*" > > parameters which is most of the nightmare of this thing? > > > > >From a quick first glance this would appear to be a good solution, however, I am > less convinced about simplifying recurrence this way, principally because I like > the idea of specifying the last concepts like "the last friday of the month". I > also understand that compatibility with iCalendar may be nice from a philosophical > viewpoint, but, as a CPL implementor it is too complex for my needs and I would > prefer to return to something closer to the syntax of draft 01 for time nodes. I agree, although I'll note that this syntax does not, AFAIK, allow you to say things like "the last Friday of every month". We could always add support for iCal style time switches in the next revision of CPL, which could then support both. This does lead to another interesting question we need to address before finishing CPL - extensibility. What is the means by which we will be able to add new tags later on? Should we have a version number in there? Should servers simply reject scripts with tags or attributes they don't know? Can we make use of XML namespaces to manage these things? -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Aug 25 05:10:55 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14693 for ; Fri, 25 Aug 2000 05:10:55 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id E642E44364; Fri, 25 Aug 2000 05:10:34 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 48B9B4433A for ; Fri, 25 Aug 2000 05:10:30 -0400 (EDT) Received: from ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id KAA26871; Fri, 25 Aug 2000 10:08:41 +0100 (BST) Message-ID: <39A6379C.DCC21EA3@ubiquity.net> Date: Fri, 25 Aug 2000 10:08:44 +0100 From: James Undery X-Mailer: Mozilla 4.73 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Jonathan Rosenberg Cc: iptel@lists.bell-labs.com Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> <39A5275C.3AADBE1F@dynamicsoft.com> <39A535F1.48928278@ubiquity.net> <39A5FC2D.F49020AB@dynamicsoft.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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Jonathan Rosenberg wrote: > James Undery wrote: > > > > > I understand the desire to be compatible with iCal, but I fear that no > > > one will implement this thing completely, and even fewer folks will > > > implement it correctly. Is there any way to simplify and retain some > > > level of interoperability with ical? What if we keep the time and > > > duration formats, and allow for repition, but eliminate the "by*" > > > parameters which is most of the nightmare of this thing? > > > > > > > >From a quick first glance this would appear to be a good solution, however, I am > > less convinced about simplifying recurrence this way, principally because I like > > the idea of specifying the last concepts like "the last friday of the month". I > > also understand that compatibility with iCalendar may be nice from a philosophical > > viewpoint, but, as a CPL implementor it is too complex for my needs and I would > > prefer to return to something closer to the syntax of draft 01 for time nodes. > > I agree, although I'll note that this syntax does not, AFAIK, allow you > to say things like "the last Friday of every month". From what I can recall there was a suggestion in the "implementation notes" about using negative numbers in a similar way to the "by*" parameters in version 02. > > We could always add support for iCal style time switches in the next > revision of CPL, which could then support both. This would be nice as I'd like first CPL RFC to be a simple as it need be and then problems with backward compatibility in future versions would be minimised. (When CPL is in use and we have a better idea of how it is to be used in practise.) > > This does lead to another interesting question we need to address before > finishing CPL - extensibility. What is the means by which we will be > able to add new tags later on? Should we have a version number in there? > Should servers simply reject scripts with tags or attributes they don't > know? Can we make use of XML namespaces to manage these things? This is definitely an important issue that needs to be addressed, firstly I'd like to note we do have a version number in the DOCTYPE tag, however, is it possible to do something similar to HTML where unknown tags (or the tag and all enclosed tags) are ignored. I not sure that this suggestion is a great idea though, currently I reject anything I don't understand which at least means the script should always do what was intended, but could make scripts a pain to generate (until the RFC is out). Before I mention XML namespaces, I must admit I don't really understand them, however, superficially appear to be used to allow tags from multiple documents to be included another document. The problem with using namespaces with CPL is that a lot of knowledge about tags is outside of a schema yet must be provided in order to execute a script containing the tags. (Assuming the tag is reachable via an execution path.) Using namespaces to allow use of tags as they were defined in previous versions would be possible (although this would mean backward compatibility wasn't built-in originally). However, when it comes to unknown tags it would still be impossible to run the script (although now we could at least parse it if the namespace URI pointed to a DTD or schema). I hope these rambling make some sense James Undery _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Aug 25 11:33:45 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22762 for ; Fri, 25 Aug 2000 11:33:44 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3DFB34435A; Fri, 25 Aug 2000 11:33:38 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 9FA484433A for ; Fri, 25 Aug 2000 11:29:14 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id LAA18944; Fri, 25 Aug 2000 11:29:05 -0400 (EDT) Message-ID: <39A690C0.2B93C39E@cs.columbia.edu> Date: Fri, 25 Aug 2000 11:29:04 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: James Undery Cc: Jonathan Rosenberg , iptel@lists.bell-labs.com Subject: Re: [IPTEL] supporting CPL versions References: <39A4F1A6.87F7A386@indigosw.com> <39A4F5B4.BD3E3EE2@ubiquity.net> <39A5275C.3AADBE1F@dynamicsoft.com> <39A535F1.48928278@ubiquity.net> <39A5FC2D.F49020AB@dynamicsoft.com> <39A6379C.DCC21EA3@ubiquity.net> 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit I don't think versioning is sufficient, for the same reason that versioning doesn't work too well on any existing protocol, except as a wholesale replacement (IPv4 to IPv6). For the time problem, this is even harder, since you end up with either two different versions of the CPL (bad) or have both time switches in the CPL, with messy results. One solution would be a tag similar to how frames work in HTML, where you can say something like this feature some older stuff This may be necessary since you may need to compose the missing feature of several nested conditions, for example. -- 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 Fri Aug 25 12:16:43 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23833 for ; Fri, 25 Aug 2000 12:16:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id BF9A8443BA; Fri, 25 Aug 2000 12:16:34 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from ubiquity.net (mail.ubiquity.net [194.128.96.72]) by lists.bell-labs.com (Postfix) with ESMTP id 254A0443B9 for ; Fri, 25 Aug 2000 12:16:31 -0400 (EDT) Received: from jundery.ubiquity.net by ubiquity.net with ESMTP (8.8.8+Sun/25-eef) id RAA26373; Fri, 25 Aug 2000 17:14:45 +0100 (BST) Received: from localhost (jundery@localhost) by jundery.ubiquity.net (8.9.3/8.9.3) with ESMTP id RAA02101; Fri, 25 Aug 2000 17:14:45 GMT X-Authentication-Warning: jundery.ubiquity.net: jundery owned process doing -bs Date: Fri, 25 Aug 2000 17:14:45 +0000 (GMT) From: James Undery To: Henning Schulzrinne Cc: Jonathan Rosenberg , iptel@lists.bell-labs.com Subject: Re: [IPTEL] supporting CPL versions In-Reply-To: <39A690C0.2B93C39E@cs.columbia.edu> Message-ID: 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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com On Fri, 25 Aug 2000, Henning Schulzrinne wrote: > I don't think versioning is sufficient, for the same reason that > versioning doesn't work too well on any existing protocol, except as a > wholesale replacement (IPv4 to IPv6). For the time problem, this is even > harder, since you end up with either two different versions of the CPL > (bad) or have both time switches in the CPL, with messy results. One > solution would be a tag similar to how frames work in HTML, where you > can say something like > > > this feature > > > some older stuff > > > This may be necessary since you may need to compose the missing feature > of several nested conditions, for example. The problem there is that isn't how frames work, although, to use the frames idea how about Old style tags And add the rule similar to HTML that unknown tags and their attributes are ignored, but anything within the tags passed though and parsed. i.e. in the above fragment if you understood "magictag" tags you execute the new code, otherwise you execute the base CPL tags. James Undery _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Aug 25 12:50:58 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24492 for ; Fri, 25 Aug 2000 12:50:58 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C8BD4443CA; Fri, 25 Aug 2000 12:49:17 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id F3230443BE for ; Fri, 25 Aug 2000 11:50:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Aug 25 11:49:37 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 94CE144379; Fri, 25 Aug 2000 11:10:09 -0400 (EDT) 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 5689144347; Fri, 25 Aug 2000 11:10:08 -0400 (EDT) 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 LAA33923866; Fri, 25 Aug 2000 11:10:08 -0400 (EDT) Message-ID: <39A68C4F.6079EBE7@research.bell-labs.com> Date: Fri, 25 Aug 2000 11:10:07 -0400 From: Shaun Erickson Reply-To: listadmins@research.bell-labs.com Organization: Bell Labs (Innovations for Lucent Technologies) X-Mailer: Mozilla 4.61 [en] (X11; I; Linux 2.2.12-20 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, ietf-sin@lists.bell-labs.com, ip-optical@lists.bell-labs.com, iptel@lists.bell-labs.com, irtf-nsm@lists.bell-labs.com, nsbd@lists.bell-labs.com, pint@lists.bell-labs.com, sip@lists.bell-labs.com, spirits@lists.bell-labs.com, wwexptools@lists.bell-labs.com Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] NOTICE: Stripping attachments from list mail. Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Recently, a member of one of the mailing lists had their system infected with a virus, which was then sent to the list server and dutifully resent out to hundreds of people on one of the lists. To help prevent such an occurence in the future, I have begun stripping certain attachments out of mail sent to the lists. In the place of the attachment, there will be a notice that the file was stripped from the mail, and why. File attachments with the following extensions will be automatically stripped from all mail sent to lists distributed from this server: exe, vbs, lnk, pif, wsh, wse, jscript, kix, shs & msi Because they are deemed important to the proper running of some of the lists, Microsoft Word (.doc) and Microsoft Powerpoint (.ppt) files will continue to be allowed as attachments, along with anything else not covered by the above list of file extensions being disallowed. Please send any questions, concerns, or comments regarding this policy, to: listadmins@research.bell-labs.com Your Friendly List Admin, -ste (Shaun Erickson, ste@research.bell-labs.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 Aug 25 14:50:41 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27143 for ; Fri, 25 Aug 2000 14:50:41 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3B1B6443BF; Fri, 25 Aug 2000 14:49:28 -0400 (EDT) Delivered-To: iptel@share.research.bell-labs.com Received: from crufty.research.bell-labs.com (crufty.research.bell-labs.com [204.178.16.49]) by lists.bell-labs.com (Postfix) with SMTP id 95652443BF for ; Fri, 25 Aug 2000 14:46:02 -0400 (EDT) Received: from lists.bell-labs.com ([135.104.27.211]) by crufty; Fri Aug 25 14:45:39 EDT 2000 Received: by lists.bell-labs.com (Postfix) id 3CC0044374; Fri, 25 Aug 2000 14:19:21 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from hotair.hobl.lucent.com (hotair.hobl.lucent.com [199.118.135.2]) by lists.bell-labs.com (Postfix) with SMTP id A09F844347; Fri, 25 Aug 2000 14:19:20 -0400 (EDT) Received: from bell-labs.com by hotair.hobl.lucent.com (SMI-8.6/EMS-1.5 sol2) id OAA10499; Fri, 25 Aug 2000 14:19:19 -0400 Message-ID: <39A6B8A1.19D68E60@bell-labs.com> Date: Fri, 25 Aug 2000 14:19:13 -0400 From: Igor Faynberg Organization: Lucent Technologies X-Mailer: Mozilla 4.73 [en]C-CCK-MCD EMS-1.4 (Win95; U) X-Accept-Language: en MIME-Version: 1.0 To: listadmins@research.bell-labs.com Cc: extest@lists.bell-labs.com, http-state@lists.bell-labs.com, ietf-pin@lists.bell-labs.com, ietf-sin@lists.bell-labs.com, ip-optical@lists.bell-labs.com, iptel@lists.bell-labs.com, irtf-nsm@lists.bell-labs.com, nsbd@lists.bell-labs.com, pint@lists.bell-labs.com, sip@lists.bell-labs.com, spirits@lists.bell-labs.com, wwexptools@lists.bell-labs.com References: <39A68C4F.6079EBE7@research.bell-labs.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] Re: [IETF-PIN] NOTICE: Stripping attachments from list mail. Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Shaun, Many thanks for the information. I believe you have made the right decision. Furthermore, for all IETF lists (PINT, SIN, SPIRITS, IPTEL) you may and should disallow even .doc and .ppt attachments. Those who post to these lists must follow the IETF-required practice of putting documents on their own sites and sending only pointers via the exploders. To summarise, only text files should be admitted to the IETF lists. Please also feel free to impose a reasonable limit on the size of the IETF-related e-mail messages. Igor Shaun Erickson wrote: > > Recently, a member of one of the mailing lists had their system infected > with a virus, which was then sent to the list server and dutifully > resent out to hundreds of people on one of the lists. > > To help prevent such an occurence in the future, I have begun stripping > certain attachments out of mail sent to the lists. In the place of the > attachment, there will be a notice that the file was stripped from the > mail, and why. > > File attachments with the following extensions will be automatically > stripped from all mail sent to lists distributed from this server: > > exe, vbs, lnk, pif, wsh, wse, jscript, kix, shs & msi > > Because they are deemed important to the proper running of some of the > lists, Microsoft Word (.doc) and Microsoft Powerpoint (.ppt) files will > continue to be allowed as attachments, along with anything else not > covered by the above list of file extensions being disallowed. > > Please send any questions, concerns, or comments regarding this policy, > to: > > listadmins@research.bell-labs.com > > Your Friendly List Admin, > > -ste (Shaun Erickson, ste@research.bell-labs.com) > > _______________________________________________ > IETF-PIN mailing list > IETF-PIN@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/ietf-pin _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Fri Aug 25 15:13:27 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27489 for ; Fri, 25 Aug 2000 15:13:27 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 3FA5A443DA; Fri, 25 Aug 2000 14:59:59 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from cs.columbia.edu (cs.columbia.edu [128.59.16.20]) by lists.bell-labs.com (Postfix) with ESMTP id 8D40D44392; Fri, 25 Aug 2000 14:56:58 -0400 (EDT) Received: from cs.columbia.edu (bart.cs.columbia.edu [128.59.19.191]) by cs.columbia.edu (8.9.3/8.9.3) with ESMTP id OAA03453; Fri, 25 Aug 2000 14:56:53 -0400 (EDT) Message-ID: <39A6C175.C94B32A1@cs.columbia.edu> Date: Fri, 25 Aug 2000 14:56:53 -0400 From: Henning Schulzrinne Organization: Columbia University, Dept. of Computer Science X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 To: Igor Faynberg Cc: listadmins@research.bell-labs.com, extest@lists.bell-labs.com, ietf-sin@lists.bell-labs.com, iptel@lists.bell-labs.com, pint@lists.bell-labs.com, sip@lists.bell-labs.com, spirits@lists.bell-labs.com Subject: Re: [IPTEL] Re: [IETF-PIN] NOTICE: Stripping attachments from list mail. References: <39A68C4F.6079EBE7@research.bell-labs.com> <39A6B8A1.19D68E60@bell-labs.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-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Igor Faynberg wrote: > > Shaun, > > Many thanks for the information. I believe you have made the right decision. > Furthermore, for all IETF lists (PINT, SIN, SPIRITS, IPTEL) you may and should > disallow even .doc and .ppt attachments. Those who post to these lists must > follow the IETF-required practice of putting documents on their own sites and > sending only pointers via the exploders. To summarise, only text files should be > admitted to the IETF lists. > > Please also feel free to impose a reasonable limit on the size of the > IETF-related e-mail messages. Actually, those probably shouldn't be sent at all to an open-standards list, as they are proprietary formats that are difficult for a significant fraction (i.e., those not using Microsoft operating systems) to read and are themselves likely to contain viruses. -- 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 Aug 28 16:16:30 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19833 for ; Mon, 28 Aug 2000 16:16:29 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id C2DCA4436D; Mon, 28 Aug 2000 15:03:31 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id 816E744351 for ; Mon, 28 Aug 2000 15:03:18 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id KAA02512 for ; Mon, 28 Aug 2000 10:50:58 -0400 (EDT) Message-ID: <39AA7BA1.E5A603CA@dynamicsoft.com> Date: Mon, 28 Aug 2000 10:48:01 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "iptel, list" Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Subject: [IPTEL] minutes Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit Folks, Enclosed are minutes from the iptel meeting at Pittsburgh IETF in July. Slides should be available soon off the web page; I'll send a note when they are. -Jonathan R. -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 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 Aug 28 16:50:06 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA20373 for ; Mon, 28 Aug 2000 16:50:06 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 5CF94443B7; Mon, 28 Aug 2000 15:27:59 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from redball.dynamicsoft.com (redball.dynamicsoft.com [216.173.40.51]) by lists.bell-labs.com (Postfix) with ESMTP id C467744351 for ; Mon, 28 Aug 2000 15:27:55 -0400 (EDT) Received: from dynamicsoft.com ([216.173.40.50]) by redball.dynamicsoft.com (8.9.3+Sun/8.10.0.Beta12) with ESMTP id QAA06400 for ; Mon, 28 Aug 2000 16:29:41 -0400 (EDT) Message-ID: <39AACB03.8CA73AEA@dynamicsoft.com> Date: Mon, 28 Aug 2000 16:26:43 -0400 From: Jonathan Rosenberg Organization: dynamicsoft X-Mailer: Mozilla 4.7 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: "iptel, list" Subject: Re: [IPTEL] minutes References: <39AA7BA1.E5A603CA@dynamicsoft.com> Content-Type: multipart/mixed; boundary="------------05275C6662E28EEBEC10DE23" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com This is a multi-part message in MIME format. --------------05275C6662E28EEBEC10DE23 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit This time, with the minutes attached. -Jonathan R. Jonathan Rosenberg wrote: > > Folks, > > Enclosed are minutes from the iptel meeting at Pittsburgh IETF in July. > Slides should be available soon off the web page; I'll send a note when > they are. > > -Jonathan R. > -- > Jonathan D. Rosenberg 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 > http://www.dynamicsoft.com > > _______________________________________________ > IPTEL mailing list > IPTEL@lists.bell-labs.com > http://lists.bell-labs.com/mailman/listinfo/iptel -- Jonathan D. Rosenberg 72 Eagle Rock Ave. Chief Scientist First Floor dynamicsoft East Hanover, NJ 07936 jdrosen@dynamicsoft.com FAX: (973) 952-5050 http://www.cs.columbia.edu/~jdrosen PHONE: (732) 741-7244 http://www.dynamicsoft.com --------------05275C6662E28EEBEC10DE23 Content-Type: text/plain; charset=iso-8859-1; name="minutes_ietf48.txt" Content-Disposition: inline; filename="minutes_ietf48.txt" Content-Transfer-Encoding: 8bit IPTEL, IETF 48 -------------- Minutes taken by: Flemming Andreasen Hussein Salama Minutes Edited by: Jonathan Rosenberg IPTEL met for a single 2.5 hour session during IETF 48 in Pittsburgh. Agenda ------ * Agenda bashing * CPL open issues, Jonathan Lennox * TRIP ope issues, Hussein Salama * TRIP-GW update, Jonathan Rosenberg * transit networks in TRIP, Dave Walker * H.323 URL, Orit Levin * Service Routing, Jonathan Rosenberg CPL Open Issues --------------- Jonathan started by describing the changes in revision 2 of the CPL specification. THe main changes were: Changes * Time handling reworked: matches iCal * H.323 mappings * XML and MIME types * New string switches: language , display * Enhancements of Node Time handling was the biggest change: +++++++++++++++++++++++++++++++++++++ * moved from crontab format to iCal (RFC 2445 - Proposed Standard) * makes it easy to create CPL srcitps automatically from calendars * rich syntax * complicated to evaluate (interoperatbility problems reported, some bugs in spec) Jonathan expressed concerns about complexity - was it really worth it? He asked for pseudo-code implementation to see implementation feasibility and ambiguity. Are there translation problems between formats (e.g. calendar to iCal). Long term we probably need the capabilities it provides us with, but really need to implement and see that it works unambigously. Don't want to have lots of different formats (SDP, iCAL, something else) Further time change: time zones. ++++++++++++++++++++++++++++++++ Time zones also derived from 2445. Time-switch nodes have two new attributes: * tzid (time zone identifier: server-local or from a to-be-defined IANA registry) * tzuel (time zone URL: reference to a RFC 2445 VTIMEZONE) VTIMEZONE is basically the same (semantic) rules as new time definition Work is (slowly) in progress to create an IANA iCal timezone registry based on the Olson TZ database. Jonathan Rosenberg (JR): Is this (iCal) really going to happen ? Real problem that people in different tz. wants to upload CPL scripts and if iCal doesn't happen we then don't have nothing. Henning Schulzrinne (HS): We don't have anything else realistically. Even Windows uses something similar. JR: There needs to be pseudo-code to show how to do this. If we get that, then we will continue with this proposal. JR: As for timezone, sync up with iCal people - we need something that works now (consensus on this) Another change: H.323 bindings: address types +++++++++++++++++++++++++++++++++++++++++++++ * Mappings defined for H.323 address types. * H.323 has addresses both in Q.931 part and H.323 UUIE part. Not clear which one takes precedence, but server should use same rules for CPL as it uses for routing. Orit Levin: Complicated issue in H.323 (there are other compl. issues in H.323 as well). Shouldn't this be done in conjunction with the H.323 community. Jonathan Lennox (JL): Tried doing it on the list. Orit: Annex O work to begin in SG-16 in two weeks (looking at Internet). Should submit this to SG-16 and ask for feedback. JR: Prepare a list of questions to SG-16, give to Orit for resolution. Specific H.323 mappings * H.323 alias address have ~8 different possible formats * Define mappings for each of these into CPL address subfields (done) * also define new alias-type address subfield for H.323 servers * Based on H.323v4, to be publishd in November; introduces H.323 URL scheme. Is this a problem for last call ? OL: Once you have H.323 URLs, why would you want to take the URL apart and map into different address subfields JL: Because we still have the old stuff around. OL: Some more comments about mapping concern between H.323 and SIP (addresses and messages) OL: SG-16 should talk about how to use H.323 with CPL (better qualified) JL: Agreed that there should be joint work here. If ITU wants to help then fine; we have been asking for their input for a while. It was agreed that we would not hold up CPL waiting for the H.323v4 or H.323 URL work. Scott confirmed that a proposed RFC cannot have normative references even to other standards work that is not complete. So, H.323 URL and other newer stuff will be relegated into an optional appendix. Another change: Mime Registration +++++++++++++++++++++++++++++++++ Added MIME registration section Media type application/cpl+xml Conforms to format of XML types in draft-murata-xml-06.txt. Another change: Parameters, considereations, file extensions ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Specified XML public identifier "-//IETF Specified XML namespace "http://www.ietf.orginternet-drafts/draft-ietf/iptel-cpl-02.txt" to be "http://www.rfc-editor.org/rfc/rfcxxxx.txt" when we go to RFC New string-switch fields ++++++++++++++++++++++++ New string-switch field: language. This is the language caller wants to receive. display-field: corresponds to Q.931 display IE Changes to location nodes +++++++++++++++++++++++++ Documented attribute clear of location and lookup nodes. * Is this really ncessary, given remove-location location ="*" changes to proxy and reidirect nodes ++++++++++++++++++++++++++++++++++++ added output redirection to proxy nodes Other changes ++++++++++++++ * Weakened server support for scripts that do not conform to the DTD from SHOULD to MAY * Clarifications * More examples * DTD updated Todo and proposed enhancements * Add q parameter to location nodes (needed for priority order) * Draft asserts H.323 has no equivalents * Clarify how extensions should work: XML namespaces. * Complaints about default timeout value for proxy being dependent on whether noanswer output is present or not. Jonathan R. initially raised this concern but has relented, as it makes the most sense. So, we will specify that the default timeout value is dependent on the presence of noanswer. HS: So where are we ? Ongoing implementations, not a lot of operational experience, let people go home and code. Recommend be last IETF presentation before Last Call. May not be the final answer for CPL, but should suffice for version 1.0 HS: Related work: currently non-overlapping, but may change: Voice-XML. Two concepts from vXML to look at (didn't catch what they were, variables (?) ). JR: Agreed. Fix up the H.323 and timezone stuff. No more presentations. Namespaces allow us to add stuff later. OL: Who is going to implement the H.323 stuff and verify it. JR: We can leave it in there. If nobody implements, then can remove before going go Draft Standard. Soliciting input from H.323 community, have done for 1+ year, continue to do, don't know what more we can do. OL: What if it turns out that changes are needed to be suitable for H.323 JR: We'll have to see what the outcome is. Scott Bradner (SB): Can always modify and recycle as Proposed Standard if changes needed JR: Better to get it before going to Proposed. HS: Let's set a deadline for people to move forward JL: what about H.323 URLs SB: can't be a normative reference if still not a standard (H.323v4). Move reference to an appendix. Can always move back when H.323v4 solid. TRIP Open Issues ---------------- Hussein Salama Hussein Salama prsented the recent changes and Open Issues for TRIP. Next Hop Server Format ++++++++++++++++++++++ * Comment from Adelaide: to represent the next hop server by domain name or IP address in DNS format * Open issue: Transport type: UDP/TCP (proxy.ietf.org.transport-tcp).. do what SIP does. * Open issue: Representation of IPv6 addresses in TRIP. JR: Do what SIP does for transport; for IPv6, there is an rfc that defines the representation of IPv6 inside of URLs, which works for us. Capabilities ++++++++++++ * Currently: route types supported and Send Receive Capability * IANA considerations * Reserved capability code 0 * Capability codecs 32768 to 65535 for vendor-specific capabilities * Open Issue: making "route types supported" mandaty E.g. may only be interested in SIP or H.323 routes. * Open Issue: adding "Capability Mismatch" error code Communities Membership Capability ================================ Based on BGP communities Permits an LS (Location Server) to announce to its peer the communities it is interested in. The peer then only advertises to the LS routes of those communities. Attribute Type Codes ==================== Assigned type codes to all attributes. IANA considerations. Reserved type codes 224 to ? Application Protocols ===================== Added two new apl. protocols RAS and H.323 Annex G. Address Families ================ Letters other than 10 digits used in Europe. Had to deviate from IANA's standard set of address families. Define two address families * POTS numbers: private, local, national, and internation (0-9) * routing numbers: mainly for European LNP (0-9, A-F) IANA considerations May want to deifne other address families in the future, e.g. URL. ITAD numbers ============ Reserved ITAD numbers 0 and 65535 ITAD numbers 64512 to 65534 are for private use IANA considerations Proposal: Use domain names instead of ITAD numbers. Issues: * No need for IANA registration * ITAD topology restrictions * Effect on AdvertisementPath and RouterPath attributes (domain name would imply long attribute names) SB: Running into trouble with 16-bit fields for AS. Change to something bigger for ITAD. MED and Tie Breaking Rules ========================== Removed inconsistency * MED usage consistent. Higher MED is preferable * Changed tie breaking rules to favor internal routes over external routes Secuurity considerations ======================== Protection of peer sessions using IPSec * Transparent mode security association * Either AH or ESP Protect route itself over multiple hops: * Sign critical attributes of the route * Include list of signatures in Authentication attribute. If intermedia changes, must remove signature and resign itself * Open Issue: What signature mechanism to use ? UPDATE Rate Limiting ==================== not yet updated (Adelaide issue - check) Application Protocol Manipulation ================================= ex: receive SIP route, want to advertise as Q.931 route. not manipulating an attribute, really chaning the route, not really comfortable with this, what could be the possible side-effects be ? JR: Difference between this and TRIP is that TRIP is an app protocol Jon Peterson: Concern about feature transparency loss due to translation (wouldn't be visible from routing info). JR: Maybe there's another attribute needed to signal whether transparency loss may result. Hussein: Could add an attibute similar to what we do for route aggregation JR: OK, consensus is to add that to the spec. Multiple TRIP Ids per LS ======================== An LS MUST use the same TRIP ID with all internal peers. Question: what's the significance of TRIP ID between external peers. Can we have a different TRIP ID with different external peers? JR: In the interest of KISS, since we can't think of a reason to do it, just keep as single ID (consensus) ITAD boundaries =============== follows BGP model. Two possibilities: * On the link between two LSs * On the LS itself. Splits the LS box into two (or more) virtual LSs. Permits route summarizatioin of TRIP-Lite routes. Allows integrating TRIP-Lite with TRIP. No changes to protocol seems to be required. Seems straightforward - would like to allow it. JR: Work has been going on for a while. Only minor stuff remains. Finish off for next meeting (similar to CPL). TRIP for Gateways (TRIP-LITE) ----------------------------- Jonathan Rosenberg Got mixed feedback in Adelaide, want to convince everybody it's a good idea. Gateway Management Problem: need a way to manage routing of calls to heterogenous gatewasy within service provider * Depends on liveness * Depends on availability (capacity, etc.) * Depends on matching capabilities of call * codecs * extensions * Depends on cost of termination Can TRIP be used ? TRIP provides routing exchange inter-domain Very similar problem * keepalives * prefix propagation * attributes and capabilites Scope of information restricted due to scale Scale issues different intra-domain * Can add additional information needed to support GW management * Can update information more frequently Thus, need a profile of TRIP TRIP-GW Not a new protocol Profile of TRIP * Used particular components * No aggregation or redistribution - that's normal TRIP * Additional attributes for this configuration SB: It really shouldn't be called anything saying TRIP (marketing confusion). Profiles are a way to say that the original protocol was to complicated. Call it something else Jon Peterson: Are you sure you want to disallow aggregation? What if I want to build a complex intra-domain network with routes propagated and aggregated among LS's within the domain? JR: Well, then you are really entering TRIP territory. On the other hand not clear how that would work if you had a single ITAD number. Need to think a little more about it. Sinnreich: Helps avoid provisioning. Benefits of TRIP-GW Information readily exported to normal TRIP interdomain Allows rapid detection of gateway failures and rerouting Supports heterogenous gateway farms Huitema: Defining internal BGP for telephony and that's not a good idea. BGP is lousy for that. Really want to have some kind of special purpose. Doesn't seem like the right tool for the job JR: Has benefits beyond provisioning. HS: Not clear this is a good fit. SLP would seem a much better fit. Service discovery is what you want JR: Disagree - SLP is a pull mechanism. Want a push mecanism. HS: No. can do service advertisement (at a small scale) JR: Not convince SLP the right tool, e.g. keepalives HS: Disagree. May be that a service push protocol is needed, but really not clear that TRIP is the right choice. Sinnreich: Need to differ between architecturally correct solutions versus short term deployable mechanisms that may not be perfect, but are usable. WG proposal JR: Not consensus obviously. Think about the intra-domain routing problem. Two questions 1. Is this problem something we want to address. 2. What are the requirements? Rohan: Go ahead and use TRIP Orit: Really a problem. Hussein: Really two problems. Gateway registration, internal routing, external routing Jon Peterson: May want to have multi-criteria routing Radhika Roy: May not want to use TRIP. JR: Problem can be split into two: * Propagation of information to proxy from a gateway * Propagation of information between proxies JR: Consensus to adopt this problem as a working group item (not using TRIP, but looking at problem)? YES. Transit Networks ---------------- Dave Walker, SS8 TRIP distributes routes based on E.164 numbers Sometimes need to route based on carrier however. Transit network selection indicates (ordered sequence of) preferred carriers * Q.931 setup, ISUP IAM National identification plans * ANSI ISUP: 4 digits (0-9, B,C) administered by NANPA Why should this matter to IPTEL? In the near future, have to allow users access to both IP and PSTN based carriers. Could try to route to gateway nearest destination, then local PSTN call, but want to provide "best" route into the specified network. TRIP based solutions: Proposal 1 - New address family route on TN reagardless of dialed number (excl CAC) new database key value (currently POTS, RoutedNumber) * POTS, RN still advertised separately (useful if TN not selected) issue: call signaling may be sup-optimal * correct route may require both E.164… Proposal 2 - new attribute type TN is an optional attribute of E.164 ReachableRoute * flexible * reachign all E.164 (ie. "*") equivalent to new address family can use existing TRIP DBs with addition of new key issue: complexity * affects E.164 aggregation What's next chose best proposal ensure all national plans satisfied clarify intra- & inter-domain behavioral differences * e.g. does carrier prefer internal gw to TN over own external meet requirements of section 5.12 for new attribute specification describe use of TN is SIP-URLs Hussein: Three questions: * Why always have country-code as part of identifier. Answer: May look into that * Using attributes proposal: problem is you get two routes and TRIP would drop one of them. Answer: draft explains this. route selection would have to change * First proposal with separate AF. We would need to correlate them somehow. JR: This seems a clearcut case of a new attribute (your second proposal). Jon Peterson: Would be nice if you could like at the TRIP-GW problem. Dave: Draft just intended to introduce problem and get discussion going. Henning: Country code poor selection as many providers exist in multiple countries. Think about roaming. Dave: Many scary scenarios. E.g. if going to Europe and carrier is US, then may end up routing calls back to US. Can talk about all this stuff in a future draft. We agreed that the second proposal is better. However, the proposal requires more work, mainly in two areas: - specify how aggregation will work - specify how "searching the RIB" will be affected. Previously the two search keys were address and application protocol. Now the CIC attribute is a third search key. Significant change. H.323 URL --------- Orit Levin draft-levin-h323-url-scheme-00.txt Goals * publish H.323-URL definition as an Informational RFC * Register H.323-URL with IANA H.323-URL use A pointer to H.323 "service" * To be carried in H.323 messages * To be used in web-pages * etc. H.225.0 "Alias" Definition H.323 URL part of H.225.0 Alias H.323v4 to be decided in November. H.323-URL Syntax Have a definition proposed and would like to solicit comments URL can only have a user-part and a host-part. H.323 URL resolution not based on DNS resolution solely (obviously). Commonalties * The H.323 URL host portion is Case Insensitive * The host numbers are defined to be used without square brackets H.323 specific issues * GK identifier as a part of "host" portion (using UNICODE, so will probably have to restrict to ASCII use) Rohan: Any parameters proposed ? Milestones H.323-URL will be included in H.323v4 H.323v4 discussion/decision due by the end of August 2000 H.323-URL will be maintained and developed as a part of H.323 Annex O "Internet Technologies Complementary to H.323" Additional parameters are for consideration Registration of the URL scheme According to BCP-35 (RFC 2717) Two alternatives for registration of the "scheme name" * IETF tree * An alternate (ITU ?) tree Would like to get some guidance on which way to go here. HS: What's the practical implication on having an ITU tree ? Answer: don't know HS: Talk to Patrik Faltstrom for guidance HS: User-name or host-name missing distinction was unclear. Problem is that will mean something different than . SIP will refer to host foo, where as H.323 will refer to user foo. Of course clear within each scheme, but somewhat confusing. OL: Well, the scheme-name makes it clear what it means. Lennox: Conventional to write URL-schemes in lower-case (h323 rather than H.323). Lennox: H.323 has slew of alias addresses. Scheme wouldn't allow all of these to be represented in the URL, e.g. "call this E.164 number". OL: Discussed, but couldn't reach consensus. Lennox: Add text explaining this in draft. Lennox: How do you use it ? Send it to the GK which then goes through the whole 323 enchilada. Should describe that a little in the draft. OL: Annex O describes this. Huitema: IETF or ITU tree question: Should go for the IETF tree. RFC publish will guaranteee IETF review. URL not used only within H.323. Could very well be used in SIP e.g. to place a call to an H.323 gateway. Huitema: Can enter any kind of URL ? OL: Yes. So can easily map between SIP and H.323 URLs. (Not sure I captured this discussion correctly) OL: prefer IETF tree as well. would like IETF review as well. Will contact Patrik and ask for his input. OL: registration process is urgent JR: take what you have, resubmit with lower case, inform IESG that you would like published as Proposed Standard (not Informational), they will look a working group/people to review it. Service Routing Out of time. Will post to the list. Meet at the IETF message board for the security meeting --------------05275C6662E28EEBEC10DE23-- _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Tue Aug 29 10:09:33 2000 Received: 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 KAA18535 for ; Tue, 29 Aug 2000 10:09:32 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id A736A4434D; Tue, 29 Aug 2000 09:07:54 -0400 (EDT) Delivered-To: iptel@lists.bell-labs.com Received: from mail-green.research.att.com (H-135-207-30-103.research.att.com [135.207.30.103]) by lists.bell-labs.com (Postfix) with ESMTP id 4EAB044339 for ; Mon, 28 Aug 2000 16:17:35 -0400 (EDT) Received: from postal.research.att.com (postal.research.att.com [135.207.23.30]) by mail-green.research.att.com (Postfix) with ESMTP id A9B7E1E011 for ; Mon, 28 Aug 2000 13:43:26 -0400 (EDT) Received: from research.att.com ([135.210.111.244]) by postal.research.att.com (8.8.7/8.8.7) with ESMTP id NAA05181 for ; Mon, 28 Aug 2000 13:43:20 -0400 (EDT) Message-ID: <39AAA34F.E193B4C6@research.att.com> Date: Mon, 28 Aug 2000 13:37:19 -0400 From: "Gregory W. Bond" Organization: AT&T Labs - Research, Florham Park, NJ X-Mailer: Mozilla 4.72 [en] (Win98; I) 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] IP Telecom Services Workshop 2000: Final Call for Participation Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com Content-Transfer-Encoding: 7bit [Please accept our apologies for multiple copies of this call.] ------------- FINAL CALL FOR PARTICIPATION --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. We have put together an excellent technical program that includes 7 original research papers, two distinguished invited speakers, and a round table discussion. We look forward to the participation from you and your colleagues in the telecom industry and the research community. Registration is now open at http://pulver.com/ipts2000/register.html. TECHNICAL PROGRAM Keynote Speaker - Eric Sumner President and CEO of dynamicsoft "The End of Telephony" Invited Speaker - Joe Rinde AT&T Labs "Why Service? What Services?" DFC as the basis for ECLIPSE, an IP communications software platform Greg Bond, Eric Cheung, Andrew Forrest, Michael Jackson, Hal Purdy, Chris Ramming, and Pamela Zave AT&T Labs Research Experimenting with PARLAY in a SIP Environment: Early Results Stephane Desrochers, Roch H. Glitho, Kindy Sylla Ericsson Research Canada Approach For Services in Converged Networks Sanjiv Kapur, Rakesh Vij Hughes Software Systems Unified Messaging using SIP and RTSP Kundan Singh and Henning Schulzrinne Columbia University SPHINX: A Study in Convergent Telephony and Advanced Scenarios for H.323-SIP Interoperation Kumar V. Vemuri Lucent Technologies Where Should Services Reside in Internet Telephony Systems? Xiaotao Wu and Henning Schulzrinne Columbia University A Transformation Approach for Service Creation in a Hybrid IP-IN Network Cyril Carrez, Elie Najm, Alexandre Tauveron Ecole Nationale Superieure des Telecom Roundtable Discussion - topic to be announced REGISTRATION IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Registration details for IPTS 2000 can be found at http://www.research.att.com/conf/ipts2000. Hotel information can be found at http://www.pulver.com/von/hotel.html. Registration for IPTS 2000 does not include registration for Fall 2000 VON. Registration details for Fall 2000 VON can be found at http://pulver.com/von. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com). WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000 _______________________________________________ IPTEL mailing list IPTEL@lists.bell-labs.com http://lists.bell-labs.com/mailman/listinfo/iptel From iptel-admin@lists.bell-labs.com Wed Aug 30 08:17:42 2000 Received: from lists.bell-labs.com (share.research.bell-labs.com [204.178.16.58]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25711 for ; Wed, 30 Aug 2000 08:17:42 -0400 (EDT) Received: from share.research.bell-labs.com (localhost.localdomain [127.0.0.1]) by lists.bell-labs.com (Postfix) with ESMTP id 4A4FE4433D; Wed, 30 Aug 2000 07:16:53 -0400 (EDT) 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 320E94437D for ; Tue, 29 Aug 2000 09:31:23 -0400 (EDT) Received: from njb140r1.ems.att.com ([135.65.202.58]) by kcmso1.proxy.att.com (AT&T IPNS/MSO-2.2) with ESMTP id KAA03794 for ; Tue, 29 Aug 2000 10:31:19 -0400 (EDT) Received: from njb140bh1.ems.att.com by njb140r1.ems.att.com (8.8.8+Sun/ATTEMS-1.4.1 sol2) id KAA05099; Tue, 29 Aug 2000 10:29:58 -0400 (EDT) Received: by njb140bh1.ems.att.com with Internet Mail Service (5.5.2652.35) id ; Tue, 29 Aug 2000 10:31:16 -0400 Message-ID: <87B812FE1B00D411A9BE009027927BFB014EC732@njb140po14.ems.att.com> From: "Dilber, Ayse, ALCOO" To: "Gregory W. Bond" , iptel@lists.bell-labs.com Subject: RE: [IPTEL] IP Telecom Services Workshop 2000: Final Call for Par ticipation Date: Tue, 29 Aug 2000 10:31:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: text/plain; charset="iso-8859-1" Sender: iptel-admin@lists.bell-labs.com Errors-To: iptel-admin@lists.bell-labs.com X-Mailman-Version: 1.1 Precedence: bulk List-Id: X-BeenThere: iptel@lists.bell-labs.com A word of caution: If the word "services" is used in conjuction with IP Telecom, we are opening the doors to Regulation! I strongly urge you to use "Applications" as opposed to "Services". Since it is not AT&T's strategy to expedite the regulation of IP Telephony, we need to be very careful when using the word "services" with IP Telephony. Regards, Ayse Dilber Strategic IP Standards and Interoperability -----Original Message----- From: Gregory W. Bond [mailto:bond@research.att.com] Sent: Monday, August 28, 2000 1:37 PM To: iptel@lists.bell-labs.com Subject: [IPTEL] IP Telecom Services Workshop 2000: Final Call for Participation [Please accept our apologies for multiple copies of this call.] ------------- FINAL CALL FOR PARTICIPATION --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. We have put together an excellent technical program that includes 7 original research papers, two distinguished invited speakers, and a round table discussion. We look forward to the participation from you and your colleagues in the telecom industry and the research community. Registration is now open at http://pulver.com/ipts2000/register.html. TECHNICAL PROGRAM Keynote Speaker - Eric Sumner President and CEO of dynamicsoft "The End of Telephony" Invited Speaker - Joe Rinde AT&T Labs "Why Service? What Services?" DFC as the basis for ECLIPSE, an IP communications software platform Greg Bond, Eric Cheung, Andrew Forrest, Michael Jackson, Hal Purdy, Chris Ramming, and Pamela Zave AT&T Labs Research Experimenting with PARLAY in a SIP Environment: Early Results Stephane Desrochers, Roch H. Glitho, Kindy Sylla Ericsson Research Canada Approach For Services in Converged Networks Sanjiv Kapur, Rakesh Vij Hughes Software Systems Unified Messaging using SIP and RTSP Kundan Singh and Henning Schulzrinne Columbia University SPHINX: A Study in Convergent Telephony and Advanced Scenarios for H.323-SIP Interoperation Kumar V. Vemuri Lucent Technologies Where Should Services Reside in Internet Telephony Systems? Xiaotao Wu and Henning Schulzrinne Columbia University A Transformation Approach for Service Creation in a Hybrid IP-IN Network Cyril Carrez, Elie Najm, Alexandre Tauveron Ecole Nationale Superieure des Telecom Roundtable Discussion - topic to be announced REGISTRATION IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Registration details for IPTS 2000 can be found at http://www.research.att.com/conf/ipts2000. Hotel information can be found at http://www.pulver.com/von/hotel.html. Registration for IPTS 2000 does not include registration for Fall 2000 VON. Registration details for Fall 2000 VON can be found at http://pulver.com/von. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com). WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000 _______________________________________________ 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