From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 01:23:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21299 for ; Mon, 2 Oct 2000 01:23:50 -0400 (EDT) Received: from standards (47.234.32.16:2766) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A9EF@standards.nortelnetworks.com>; Mon, 2 Oct 2000 1:07:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9149 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 01:07:37 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A9E7@standards.nortelnetworks.com>; Mon, 2 Oct 2000 0:57:36 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e925Brt27700; Mon, 2 Oct 2000 07:11:53 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id HAA05754; Mon, 2 Oct 2000 07:11:52 +0200 (MET DST) Received: from ericsson.com (mcdh98.epa.ericsson.se [146.11.81.98]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA21515; Mon, 2 Oct 2000 07:11:49 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480DCD@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39D7DEA5.8CD0C793@ericsson.com> Date: Mon, 2 Oct 2000 12:02:29 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: FW: IPPhone Profile Last Call X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, A comment regarding the naming of this draft. I thought that there was a common thread in this group that we would not 'do' profiles on the Megaco list. Therefore I think that the draft name "ietf-megaco-..." is misleading. Cheers, Christian Tom-PT Taylor wrote: > > Resend -- looks like the first try didn't make it. > > -----Original Message----- > From: Taylor, Tom-PT [NORSE:B901:EXCH] > Sent: Friday, September 22, 2000 9:29 AM > To: megaco > Subject: IPPhone Profile Last Call > > draft-ietf-megaco-ipphone-03.txt has been out for a couple of weeks. Peter > Blatherwick has just reminded me that this is the draft we were waiting for > to take to Last Call. > > I hereby announce WG Last Call on draft-ietf-megaco-ipphone-03.txt, which is > proposed as an Informational RFC. Assuming no major problems, WG Last Call > will expire October 6. > > Tom Taylor From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 01:23:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21305 for ; Mon, 2 Oct 2000 01:23:52 -0400 (EDT) Received: from standards (47.234.32.16:2766) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A9FC@standards.nortelnetworks.com>; Mon, 2 Oct 2000 1:08:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9150 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 01:08:43 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A9E8@standards.nortelnetworks.com>; Mon, 2 Oct 2000 0:58:38 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e925CuZ12830; Mon, 2 Oct 2000 07:12:56 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id HAA05812; Mon, 2 Oct 2000 07:12:56 +0200 (MET DST) Received: from ericsson.com (mcdh98.epa.ericsson.se [146.11.81.98]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA21553; Mon, 2 Oct 2000 07:12:50 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E70D@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39D80235.C73B114A@ericsson.com> Date: Mon, 2 Oct 2000 14:34:13 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Wildcard command with CHOOSE X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, Can you elaborate on the example below? To me if you do a ADD(termination = "?", naming pattern) you'll only get back one instance. Cheers, Christian "Rosen, Brian" wrote: > > I think we do. I think the most interesting cases of wildcard > response is on a set of terminations that have common > characteristics (like all the physical terminations in a > trunk GW). The "Name Pattern" mechanism will be helpful for > this. > > Restricting it to "whole gateway only" is not acceptable, I think. > > Brian > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > > Sent: Sunday, September 24, 2000 12:14 PM > > To: Rosen, Brian > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Wildcard command with CHOOSE > > > > > > G'Day Brian, > > > > Do we really need to specify this? If you do a w- TermID=? you're only > > going to get back one set of values whether or not you have w-. > > > > Below is the text I intend on adding to the implementors > > guide based on > > one of your previous examples. > > > > Does this help at all? > > > > Cheers, Christian > > ============================================================= > > 9.3 Audit Response with and without wilcard response (w-) > > > > Description: There is some confusion on what should be sent in the > > response to an Audit in the cases where you have wilcarded the context > > or termination and have specified wildcarded response. > > Reference: Subject: RE: Audit of Packages > > Date: Wed, 13 Sep 2000 09:42:31 -0400 > > From: "Rosen, Brian" > > To: "'Christian Groves'" > > CC: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > [Begin Clarification] > > Assume the gateway has 4 terminations : t1/1, t1/2, t2/1 and t2/2 > > Assume terminations t1/* has implemented packages aaa and bbb and > > terminations t2/* has implemented packages ccc and ddd. > > Assume context 1 has t1/1 and t2/1 in it, and context 2 has t1/2 and > > t2/2 in it. > > The command: > > Context=1{Audit=t1/1{Audit{Packages}} > > Returns: > > Context=1{Audit=t1/1{Packages{aaa,bbb}}}} > > The command: > > Context=*{Audit=t2/*{Audit{Packages}} > > Returns: > > Context=1{Audit=t2/1{Packages{ccc,ddd}}}, > > Context=2{Audit=t2/2{Packages{ccc,ddd}}} > > The command: > > Context=*{W-Audit=*{Audit{Packages}} > > Returns: > > Context=*{W-Audit=*{Packages{aaa,bbb,ccc,ddd}} > > [End Clarification] > > ============================================================= > > > > > > "Rosen, Brian" wrote: > > > > > > The text currently states: > > > When ALL is used in the TerminationID of a command, the effect is > > > identical to repeating the command with each of the matching > > > TerminationIDs. Since each of these commands may generate a > > > response, the size of the entire response may be large. If > > > individual responses are not required, a wildcard response may be > > > requested. In such a case, a single response is generated, which > > > contains the UNION of all of the individual responses which > > > otherwise would have been generated, with duplicate values > > > suppressed. > > > > > > Notice that this seems to imply that wildcard response can > > > only be used with ALL. I think this is incorrect, and it > > > can be used with CHOOSE as in W-Audit=term/*{Audit{... > > > > > > This is grist for the Implementer's Guide. > > > > > > Brian > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 01:23:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21316 for ; Mon, 2 Oct 2000 01:23:52 -0400 (EDT) Received: from standards (47.234.32.16:2766) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AA01@standards.nortelnetworks.com>; Mon, 2 Oct 2000 1:08:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9151 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 01:08:46 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9A9E9@standards.nortelnetworks.com>; Mon, 2 Oct 2000 0:58:45 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e925D2t27887; Mon, 2 Oct 2000 07:13:02 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id HAA05820; Mon, 2 Oct 2000 07:13:01 +0200 (MET DST) Received: from ericsson.com (mcdh98.epa.ericsson.se [146.11.81.98]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA21557; Mon, 2 Oct 2000 07:12:58 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <28560036253BD41191A10000F8BCBD11480E05@zcard00g.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39D803A2.D2E00154@ericsson.com> Date: Mon, 2 Oct 2000 14:40:18 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Property value retainment in case of LocalControlDescriptor. X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, With regards to (1): I don't think that defining these incompatibilities is something that we should be doing. With regards to (2) I don't think we even have a protocol mechanism to assign packages to a termination. What packages a termination supports is provisioned. We can via the protocol assign/delete properties and values from any termination. Through auditing the MGC can find out what is current assigned to a terminations (AuditValue) and audit the possible properties/values (Audit Capability). Cheers, Christian Tom-PT Taylor wrote: > > Good question. It is complicated by the fact that it is crucial (I think) > to be able to say whether a given property is even present on a given > termination. This is tied to the broader question of package support. I > would like to make these propositions, which are consistent with the > protocol as it stands but are very much open to discussion: > (1) Some packages are mutually exclusive (cannot simultaneously be supported > on the same termination), for example, RTP and TDMC. > (2) Once a given package has been assigned to a termination, the protocol > provides no way of getting rid of it. > > If (1) is true we should be documenting the incompatibilities in the package > definitions and implementations should check for valid combinations. If (2) > is true each termination acquires a state composed of packages provisioned > against it, plus all additional packages invoked on it by the MGC and > accepted by the MG. Packages with no known incompatibilities and no > associated properties can be ignored in composing this state. The MG has to > check each new package invocation from the MGC against the accrued > termination package state. > > Now: how does this relate to your question? If the above propositions are > accepted, we can reason that properties are persistent -- once they have > been attributed to a termination they never go away. It is a short step to > suggest that they will typically require explicit action to change them, and > you can assume they stay unchanged otherwise. Therefore properties don't > have to be respecified in TerminationState and LocalControl unless you want > them to change. > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Friday, September 15, 2000 10:21 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Property value retainment in case of LocalControlDescriptor. > > > > > > In Section 7.1.7 paragraph 9 indicates that a new local > > control descriptor > > replaces the previous setting of that descriptor is this true > > in case of > > properties also. or is it that MGC will always have to send > > these properties > > every time it sends a local control descriptor. > > Regards. > > -Madhubabu > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 03:58:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03540 for ; Mon, 2 Oct 2000 03:58:21 -0400 (EDT) Received: from standards (47.234.32.16:3905) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AB23@standards.nortelnetworks.com>; Mon, 2 Oct 2000 3:42:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9591 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 03:42:28 -0400 Received: from mink.ecitele.com (mailhost.ecitele.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AB22@standards.nortelnetworks.com>; Mon, 2 Oct 2000 3:42:26 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id KAA15127 for ; Mon, 2 Oct 2000 10:55:48 +0300 (IDT) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3 (Intl)|21 March 2000) at 02/10/2000 10:57:16 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Mon, 2 Oct 2000 10:52:04 +0300 Reply-To: Shlomo.Kabaz@ECITELE.COM Sender: "Media Gateway Control (megaco)" From: Shlomo Kabaz ECItelecom Subject: Audit with Wilcard To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi , all . I am Asking again about auditing with wildcard , i do not know what to do in the next cases : 1. In Media descriptor , how do i report for instance , multiple values in the terminationState descriptor , do i include in the reply more than one "AuditReturnParameter" to Media descriptor . 2. When auditing events , again each event descriptor for a termination has "reauestId" , so in order to include all events i have to reply with "AuditReturnParameter" for each evant that resides in a termination is it true ?? Regards , Shlomo ECI From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 07:26:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05498 for ; Mon, 2 Oct 2000 07:26:41 -0400 (EDT) Received: from standards (47.234.32.16:2468) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AB84@standards.nortelnetworks.com>; Mon, 2 Oct 2000 7:10:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9722 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 07:10:44 -0400 Received: from smtp4.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AB83@standards.nortelnetworks.com>; Mon, 2 Oct 2000 7:10:44 -0400 Received: from oleane (dyn-1-1-224.Vin.dialup.oleane.fr [195.25.4.224]) by smtp4.cluster.oleane.net with SMTP id NAA65943 for ; Mon, 2 Oct 2000 13:25:04 +0200 (CEST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_004E_01C02C74.046AA3E0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <005101c02c63$411bcfa0$0401a8c0@oleane.com> Date: Mon, 2 Oct 2000 13:23:56 +0200 Reply-To: Peter Lewis Sender: "Media Gateway Control (megaco)" From: Peter Lewis Subject: MGC 2000 To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_004E_01C02C74.046AA3E0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MGC 2000, second edition: Paris, 14-17 November. Megaco/MGCP developments, test results, real case studies reports. More details at: http://www.upperside.fr/bamgc2yk.htm =20 ------=_NextPart_000_004E_01C02C74.046AA3E0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
MGC 2000, second edition: Paris, = 14-17=20 November.
Megaco/MGCP developments, test = results, real=20 case studies reports.
More details at:
http://www.upperside.fr/bam= gc2yk.htm
 
------=_NextPart_000_004E_01C02C74.046AA3E0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 10:06:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08197 for ; Mon, 2 Oct 2000 10:06:11 -0400 (EDT) Received: from standards (47.234.32.16:1936) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9ABF7@standards.nortelnetworks.com>; Mon, 2 Oct 2000 9:49:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9869 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 09:49:52 -0400 Received: from qhars002.nortel.com (47.101.112.102:43332) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9ABF6@standards.nortelnetworks.com>; Mon, 2 Oct 2000 9:49:52 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Mon, 2 Oct 2000 15:03:31 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 2 Oct 2000 10:02:54 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 2 Oct 2000 10:02:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02C79.5AC44110" Message-ID: <353093573B82D411889E0000F808216648E3AE@zcard00q.ca.nortel.com> Date: Mon, 2 Oct 2000 10:02:09 -0400 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: FW: IPPhone Profile Last Call X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C02C79.5AC44110 Content-Type: text/plain; charset="iso-8859-1" Megaco IP Phone has been a work item of the Megaco WG since before its initial posting under current naming as 00 version, June 99. (Before that it was a private submission "draft-blatherwick-...".) This was discussed extensively on the list, and agreed. The draft has since undergone lots of review and re-work as a result of list feedback. It was agreed it could proceed to Last Call under current naming as of IETF 47, Adelaide, pending closure of issues, all of which are now complete. Not sure what the value of changing names would be. IETF bodies can certainly define profiles. If not worked through Megaco WG, then just where would they be looked at? -- Peter Blatherwick -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] Sent: Sunday, October 01, 2000 21:02 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: FW: IPPhone Profile Last Call G'Day Tom, A comment regarding the naming of this draft. I thought that there was a common thread in this group that we would not 'do' profiles on the Megaco list. Therefore I think that the draft name "ietf-megaco-..." is misleading. Cheers, Christian Tom-PT Taylor wrote: > > Resend -- looks like the first try didn't make it. > > -----Original Message----- > From: Taylor, Tom-PT [NORSE:B901:EXCH] > Sent: Friday, September 22, 2000 9:29 AM > To: megaco > Subject: IPPhone Profile Last Call > > draft-ietf-megaco-ipphone-03.txt has been out for a couple of weeks. Peter > Blatherwick has just reminded me that this is the draft we were waiting for > to take to Last Call. > > I hereby announce WG Last Call on draft-ietf-megaco-ipphone-03.txt, which is > proposed as an Informational RFC. Assuming no major problems, WG Last Call > will expire October 6. > > Tom Taylor ------_=_NextPart_001_01C02C79.5AC44110 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: IPPhone Profile Last Call

Megaco IP Phone has been a work item of the Megaco WG = since before its initial posting under current naming as 00 version, = June 99.  (Before that it was a private submission = "draft-blatherwick-...".)  This was discussed = extensively on the list, and agreed.  The draft has since = undergone lots of review and re-work as a result of list = feedback.  It was agreed it could proceed to Last Call under = current naming as of IETF 47, Adelaide, pending closure of issues, all = of which are now complete. 

Not sure what the value of changing names would = be.  IETF bodies can certainly define profiles.  If not = worked through Megaco WG, then just where would they be looked = at?

-- Peter Blatherwick

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@ER= ICSSON.COM]
Sent: Sunday, October 01, 2000 21:02
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: FW: IPPhone Profile Last Call


G'Day Tom,

A comment regarding the naming of this draft. I = thought that there was a
common thread in this group that we would not 'do' = profiles on the
Megaco list. Therefore I think that the draft name = "ietf-megaco-..." is
misleading.

Cheers, Christian

Tom-PT Taylor wrote:
>
> Resend -- looks like the first try didn't make = it.
>
> -----Original Message-----
> From: Taylor, Tom-PT [NORSE:B901:EXCH]
> Sent: Friday, September 22, 2000 9:29 AM
> To: megaco
> Subject: IPPhone Profile Last Call
>
> draft-ietf-megaco-ipphone-03.txt has been out = for a couple of weeks.  Peter
> Blatherwick has just reminded me that this is = the draft we were waiting for
> to take to Last Call.
>
> I hereby announce WG Last Call on = draft-ietf-megaco-ipphone-03.txt, which is
> proposed as an Informational RFC.  = Assuming no major problems, WG Last Call
> will expire October 6.
>
> Tom Taylor

------_=_NextPart_001_01C02C79.5AC44110-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 10:41:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08496 for ; Mon, 2 Oct 2000 10:41:18 -0400 (EDT) Received: from standards (47.234.32.16:3660) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AC30@standards.nortelnetworks.com>; Mon, 2 Oct 2000 10:25:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9948 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 10:25:16 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AC2F@standards.nortelnetworks.com>; Mon, 2 Oct 2000 10:25:16 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18452; Mon, 2 Oct 2000 10:39:31 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18450; Mon, 2 Oct 2000 10:39:31 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Oct 2000 10:39:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E734@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 2 Oct 2000 10:39:29 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Wildcard command with CHOOSE X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM If you did something like Add=ff1/?{... you would get one response. I don't think you can do AuditValue=ff1/?{... But you can do AuditValue=ff1/*{... If ff1/0, ff1/1 and ff1/2 exist, you get 3 responses If you did W-AuditValue=ff1/*{... you would get only one response. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Sunday, October 01, 2000 11:34 PM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Wildcard command with CHOOSE > > > G'Day Brian, > > Can you elaborate on the example below? To me if you do a > ADD(termination = "?", naming pattern) you'll only get back one > instance. > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > I think we do. I think the most interesting cases of wildcard > > response is on a set of terminations that have common > > characteristics (like all the physical terminations in a > > trunk GW). The "Name Pattern" mechanism will be helpful for > > this. > > > > Restricting it to "whole gateway only" is not acceptable, I think. > > > > Brian > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > > > Sent: Sunday, September 24, 2000 12:14 PM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Wildcard command with CHOOSE > > > > > > > > > G'Day Brian, > > > > > > Do we really need to specify this? If you do a w- > TermID=? you're only > > > going to get back one set of values whether or not you have w-. > > > > > > Below is the text I intend on adding to the implementors > > > guide based on > > > one of your previous examples. > > > > > > Does this help at all? > > > > > > Cheers, Christian > > > ============================================================= > > > 9.3 Audit Response with and without wilcard response (w-) > > > > > > Description: There is some confusion on what should be > sent in the > > > response to an Audit in the cases where you have > wilcarded the context > > > or termination and have specified wildcarded response. > > > Reference: Subject: RE: Audit of Packages > > > Date: Wed, 13 Sep 2000 09:42:31 -0400 > > > From: "Rosen, Brian" > > > To: "'Christian Groves'" > > > CC: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > [Begin Clarification] > > > Assume the gateway has 4 terminations : t1/1, t1/2, t2/1 and t2/2 > > > Assume terminations t1/* has implemented packages aaa and bbb and > > > terminations t2/* has implemented packages ccc and ddd. > > > Assume context 1 has t1/1 and t2/1 in it, and context 2 > has t1/2 and > > > t2/2 in it. > > > The command: > > > Context=1{Audit=t1/1{Audit{Packages}} > > > Returns: > > > Context=1{Audit=t1/1{Packages{aaa,bbb}}}} > > > The command: > > > Context=*{Audit=t2/*{Audit{Packages}} > > > Returns: > > > Context=1{Audit=t2/1{Packages{ccc,ddd}}}, > > > Context=2{Audit=t2/2{Packages{ccc,ddd}}} > > > The command: > > > Context=*{W-Audit=*{Audit{Packages}} > > > Returns: > > > Context=*{W-Audit=*{Packages{aaa,bbb,ccc,ddd}} > > > [End Clarification] > > > ============================================================= > > > > > > > > > "Rosen, Brian" wrote: > > > > > > > > The text currently states: > > > > When ALL is used in the TerminationID of a command, the > effect is > > > > identical to repeating the command with each of the matching > > > > TerminationIDs. Since each of these commands may generate a > > > > response, the size of the entire response may be large. If > > > > individual responses are not required, a wildcard > response may be > > > > requested. In such a case, a single response is > generated, which > > > > contains the UNION of all of the individual responses which > > > > otherwise would have been generated, with duplicate values > > > > suppressed. > > > > > > > > Notice that this seems to imply that wildcard response can > > > > only be used with ALL. I think this is incorrect, and it > > > > can be used with CHOOSE as in W-Audit=term/*{Audit{... > > > > > > > > This is grist for the Implementer's Guide. > > > > > > > > Brian > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 17:15:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14278 for ; Mon, 2 Oct 2000 17:15:36 -0400 (EDT) Received: from standards (47.234.32.16:2875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AF15@standards.nortelnetworks.com>; Mon, 2 Oct 2000 16:55:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10780 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 16:55:00 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AEBC@standards.nortelnetworks.com>; Mon, 2 Oct 2000 16:44:59 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e92KxJt14353; Mon, 2 Oct 2000 22:59:20 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id WAA09821; Mon, 2 Oct 2000 22:59:19 +0200 (MET DST) Received: from ericsson.com (7-150.epa.ericsson.se [146.11.7.150]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id WAA26407; Mon, 2 Oct 2000 22:59:15 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E734@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39D8F71D.582F2595@ericsson.com> Date: Tue, 3 Oct 2000 07:59:09 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Wildcard command with CHOOSE X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, OK I was worried that you were talking about "?". I think what you're asking for is that text below that I proposed for the implementors guide be updated as> The command: Context=*{W-Audit=t1/*{Audit{Packages}} ^^^ addition Returns: Context=*{W-Audit=t1/*{Packages{aaa,bbb,ccc,ddd}} ^^^ addition To show that the w- is appropriate for a wilcard in a termination ID structure. Are you happy with the proposed clarification? Cheers, Christian "Rosen, Brian" wrote: > > If you did something like > Add=ff1/?{... > you would get one response. > > I don't think you can do > AuditValue=ff1/?{... > > But you can do > AuditValue=ff1/*{... > > If ff1/0, ff1/1 and ff1/2 exist, you get 3 responses > > If you did > W-AuditValue=ff1/*{... > you would get only one response. > > Brian > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > > Sent: Sunday, October 01, 2000 11:34 PM > > To: Rosen, Brian > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Wildcard command with CHOOSE > > > > > > G'Day Brian, > > > > Can you elaborate on the example below? To me if you do a > > ADD(termination = "?", naming pattern) you'll only get back one > > instance. > > > > Cheers, Christian > > > > "Rosen, Brian" wrote: > > > > > > I think we do. I think the most interesting cases of wildcard > > > response is on a set of terminations that have common > > > characteristics (like all the physical terminations in a > > > trunk GW). The "Name Pattern" mechanism will be helpful for > > > this. > > > > > > Restricting it to "whole gateway only" is not acceptable, I think. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > > > > Sent: Sunday, September 24, 2000 12:14 PM > > > > To: Rosen, Brian > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Wildcard command with CHOOSE > > > > > > > > > > > > G'Day Brian, > > > > > > > > Do we really need to specify this? If you do a w- > > TermID=? you're only > > > > going to get back one set of values whether or not you have w-. > > > > > > > > Below is the text I intend on adding to the implementors > > > > guide based on > > > > one of your previous examples. > > > > > > > > Does this help at all? > > > > > > > > Cheers, Christian > > > > ============================================================= > > > > 9.3 Audit Response with and without wilcard response (w-) > > > > > > > > Description: There is some confusion on what should be > > sent in the > > > > response to an Audit in the cases where you have > > wilcarded the context > > > > or termination and have specified wildcarded response. > > > > Reference: Subject: RE: Audit of Packages > > > > Date: Wed, 13 Sep 2000 09:42:31 -0400 > > > > From: "Rosen, Brian" > > > > To: "'Christian Groves'" > > > > CC: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > > > [Begin Clarification] > > > > Assume the gateway has 4 terminations : t1/1, t1/2, t2/1 and t2/2 > > > > Assume terminations t1/* has implemented packages aaa and bbb and > > > > terminations t2/* has implemented packages ccc and ddd. > > > > Assume context 1 has t1/1 and t2/1 in it, and context 2 > > has t1/2 and > > > > t2/2 in it. > > > > The command: > > > > Context=1{Audit=t1/1{Audit{Packages}} > > > > Returns: > > > > Context=1{Audit=t1/1{Packages{aaa,bbb}}}} > > > > The command: > > > > Context=*{Audit=t2/*{Audit{Packages}} > > > > Returns: > > > > Context=1{Audit=t2/1{Packages{ccc,ddd}}}, > > > > Context=2{Audit=t2/2{Packages{ccc,ddd}}} > > > > The command: > > > > Context=*{W-Audit=*{Audit{Packages}} > > > > Returns: > > > > Context=*{W-Audit=*{Packages{aaa,bbb,ccc,ddd}} > > > > [End Clarification] > > > > ============================================================= > > > > > > > > > > > > "Rosen, Brian" wrote: > > > > > > > > > > The text currently states: > > > > > When ALL is used in the TerminationID of a command, the > > effect is > > > > > identical to repeating the command with each of the matching > > > > > TerminationIDs. Since each of these commands may generate a > > > > > response, the size of the entire response may be large. If > > > > > individual responses are not required, a wildcard > > response may be > > > > > requested. In such a case, a single response is > > generated, which > > > > > contains the UNION of all of the individual responses which > > > > > otherwise would have been generated, with duplicate values > > > > > suppressed. > > > > > > > > > > Notice that this seems to imply that wildcard response can > > > > > only be used with ALL. I think this is incorrect, and it > > > > > can be used with CHOOSE as in W-Audit=term/*{Audit{... > > > > > > > > > > This is grist for the Implementer's Guide. > > > > > > > > > > Brian > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 2 17:15:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14283 for ; Mon, 2 Oct 2000 17:15:37 -0400 (EDT) Received: from standards (47.234.32.16:2875) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AF3C@standards.nortelnetworks.com>; Mon, 2 Oct 2000 16:58:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 10946 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 2 Oct 2000 16:58:06 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9AF3B@standards.nortelnetworks.com>; Mon, 2 Oct 2000 16:58:05 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA24846; Mon, 2 Oct 2000 17:12:24 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id RAA01120; Mon, 2 Oct 2000 17:12:23 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Mon, 2 Oct 2000 17:12:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E73D@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 2 Oct 2000 17:12:17 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Wildcard command with CHOOSE X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM G'Day Christian Yes, I think that is fine. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Monday, October 02, 2000 4:59 PM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Wildcard command with CHOOSE > > > G'Day Brian, > > OK I was worried that you were talking about "?". > I think what you're asking for is that text below that I proposed for > the implementors guide be updated as> > The command: > Context=*{W-Audit=t1/*{Audit{Packages}} > ^^^ addition > Returns: > Context=*{W-Audit=t1/*{Packages{aaa,bbb,ccc,ddd}} > ^^^ addition > > To show that the w- is appropriate for a wilcard in a termination ID > structure. > Are you happy with the proposed clarification? > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > If you did something like > > Add=ff1/?{... > > you would get one response. > > > > I don't think you can do > > AuditValue=ff1/?{... > > > > But you can do > > AuditValue=ff1/*{... > > > > If ff1/0, ff1/1 and ff1/2 exist, you get 3 responses > > > > If you did > > W-AuditValue=ff1/*{... > > you would get only one response. > > > > Brian > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > > > Sent: Sunday, October 01, 2000 11:34 PM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Wildcard command with CHOOSE > > > > > > > > > G'Day Brian, > > > > > > Can you elaborate on the example below? To me if you do a > > > ADD(termination = "?", naming pattern) you'll only get back one > > > instance. > > > > > > Cheers, Christian > > > > > > "Rosen, Brian" wrote: > > > > > > > > I think we do. I think the most interesting cases of wildcard > > > > response is on a set of terminations that have common > > > > characteristics (like all the physical terminations in a > > > > trunk GW). The "Name Pattern" mechanism will be helpful for > > > > this. > > > > > > > > Restricting it to "whole gateway only" is not > acceptable, I think. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > > > > > Sent: Sunday, September 24, 2000 12:14 PM > > > > > To: Rosen, Brian > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Wildcard command with CHOOSE > > > > > > > > > > > > > > > G'Day Brian, > > > > > > > > > > Do we really need to specify this? If you do a w- > > > TermID=? you're only > > > > > going to get back one set of values whether or not > you have w-. > > > > > > > > > > Below is the text I intend on adding to the implementors > > > > > guide based on > > > > > one of your previous examples. > > > > > > > > > > Does this help at all? > > > > > > > > > > Cheers, Christian > > > > > ============================================================= > > > > > 9.3 Audit Response with and without wilcard response (w-) > > > > > > > > > > Description: There is some confusion on what should be > > > sent in the > > > > > response to an Audit in the cases where you have > > > wilcarded the context > > > > > or termination and have specified wildcarded response. > > > > > Reference: Subject: RE: Audit of Packages > > > > > Date: Wed, 13 Sep 2000 09:42:31 -0400 > > > > > From: "Rosen, Brian" > > > > > To: "'Christian Groves'" > > > > > CC: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > > > > > [Begin Clarification] > > > > > Assume the gateway has 4 terminations : t1/1, t1/2, > t2/1 and t2/2 > > > > > Assume terminations t1/* has implemented packages aaa > and bbb and > > > > > terminations t2/* has implemented packages ccc and ddd. > > > > > Assume context 1 has t1/1 and t2/1 in it, and context 2 > > > has t1/2 and > > > > > t2/2 in it. > > > > > The command: > > > > > Context=1{Audit=t1/1{Audit{Packages}} > > > > > Returns: > > > > > Context=1{Audit=t1/1{Packages{aaa,bbb}}}} > > > > > The command: > > > > > Context=*{Audit=t2/*{Audit{Packages}} > > > > > Returns: > > > > > Context=1{Audit=t2/1{Packages{ccc,ddd}}}, > > > > > Context=2{Audit=t2/2{Packages{ccc,ddd}}} > > > > > The command: > > > > > Context=*{W-Audit=*{Audit{Packages}} > > > > > Returns: > > > > > Context=*{W-Audit=*{Packages{aaa,bbb,ccc,ddd}} > > > > > [End Clarification] > > > > > ============================================================= > > > > > > > > > > > > > > > "Rosen, Brian" wrote: > > > > > > > > > > > > The text currently states: > > > > > > When ALL is used in the TerminationID of a command, the > > > effect is > > > > > > identical to repeating the command with each of > the matching > > > > > > TerminationIDs. Since each of these commands > may generate a > > > > > > response, the size of the entire response may be > large. If > > > > > > individual responses are not required, a wildcard > > > response may be > > > > > > requested. In such a case, a single response is > > > generated, which > > > > > > contains the UNION of all of the individual > responses which > > > > > > otherwise would have been generated, with > duplicate values > > > > > > suppressed. > > > > > > > > > > > > Notice that this seems to imply that wildcard response can > > > > > > only be used with ALL. I think this is incorrect, and it > > > > > > can be used with CHOOSE as in W-Audit=term/*{Audit{... > > > > > > > > > > > > This is grist for the Implementer's Guide. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 01:39:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA25351 for ; Tue, 3 Oct 2000 01:39:14 -0400 (EDT) Received: from standards (47.234.32.16:1705) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B136@standards.nortelnetworks.com>; Tue, 3 Oct 2000 1:23:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11637 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 01:23:00 -0400 Received: from qhars002.nortel.com (47.101.112.102:44244) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B135@standards.nortelnetworks.com>; Tue, 3 Oct 2000 1:23:00 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Tue, 3 Oct 2000 06:36:52 +0100 Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Tue, 3 Oct 2000 01:35:18 -0400 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Tue, 3 Oct 2000 01:35:09 -0400 Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id IAA06123 for ; Tue, 3 Oct 2000 08:37:08 +0300 (IDT) Received: from tsyspc13 by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id IAA22097; Tue, 3 Oct 2000 08:37:08 +0300 (IDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0028_01C02D14.BF73B140" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Orig: Message-ID: <002b01c02d03$fc0c7300$6f0de28d@elex.co.il> Date: Tue, 3 Oct 2000 08:34:30 +0200 Reply-To: "Bentov, Kohava" Sender: "Media Gateway Control (megaco)" From: "Bentov, Kohava" Organization: Telrad Subject: mId field in the Message header To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0028_01C02D14.BF73B140 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, 1. Can we assume that each MG will use a unique mId in its message = header when it=20 sends messages to the same MGC ? =20 If yes, is there a mistake in the example (section A.1.1) ? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =20 1. An MG registers with an MGC using the ServiceChange command: MG1 to MGC: MEGACO/1 [124.124.124.222] ----------------- 4. The MG1 accepts the Modify with this reply: MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =20 2. Is it obvious that the mId of a virtual MG will always consist of = IP address + Port ?=20 =20 3. Is it possible that the mId in one message will be in a = domainAddress format and in=20 another message (from the same source) it will be in an = mtpAddress format ?=20 =20 I ask these questions because we need unique mIds for managing=20 the transaction database. =20 Best regards, Kohava Bentov=20 Telrad Networks E-mail: kohava.bentov@telrad.co.il Tel: (972)-8-9134353 ------=_NextPart_000_0028_01C02D14.BF73B140 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Hi,
 
  1.  Can we assume that = each MG=20 will use a unique mId in its message header = when it=20
      =20 sends messages to the same MGC ? 
       If = yes, is=20 there a mistake in the example (section A.1.1) ?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D 

1. An MG registers with an MGC using the ServiceChange=20 command:

MG1 to MGC:

MEGACO/1 [124.124.124.222]

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

4. The MG1 accepts the Modify with this reply:

MG1 to MGC:

MEGACO/1=20 [124.124.124.222]:55555

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D 
 
  2.  Is it obvious that the = mId of a=20 virtual MG will always consist of IP address + Port = ?=20
 
  3.  Is it possible that the = mId in one=20 message will be in a domainAddress format and in
       = another=20 message (from the same source) it will be in an mtpAddress format ?=20
 
  I ask these questions because we = need=20 unique mIds for managing
the transaction=20 database.  
 
Best regards,
    Kohava Bentov=20
    Telrad Networks
    E-mail: kohava.bentov@telrad.co.il=
   =20 Tel: (972)-8-9134353
------=_NextPart_000_0028_01C02D14.BF73B140-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 07:01:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA05629 for ; Tue, 3 Oct 2000 07:01:16 -0400 (EDT) Received: from standards (47.234.32.16:1848) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B260@standards.nortelnetworks.com>; Tue, 3 Oct 2000 6:45:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12005 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 06:45:12 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B24B@standards.nortelnetworks.com>; Tue, 3 Oct 2000 6:35:11 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05401; Tue, 3 Oct 2000 06:49:35 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200010031049.GAA05401@ietf.org> Date: Tue, 3 Oct 2000 06:49:34 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-levy-megaco-mgdiscovery-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Megaco/H.248 Media Gateway Resources Discovery Author(s) : T. Levy, L. Anquetil Filename : draft-levy-megaco-mgdiscovery-00.txt Pages : 8 Date : 02-Oct-00 This document addresses the need for a Media Gateway Controller (MGC) to be informed from the media resources of its Media Gateways (MG) in the context of the Megaco/H.248 protocol. The draft discusses alternative solutions for an effective media gateway resources discovery mechanism. The document is provided as an informational draft for discussion within the Megaco Working Group. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-levy-megaco-mgdiscovery-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-levy-megaco-mgdiscovery-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-levy-megaco-mgdiscovery-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001002120612.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-levy-megaco-mgdiscovery-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-levy-megaco-mgdiscovery-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001002120612.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 08:06:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA07280 for ; Tue, 3 Oct 2000 08:06:44 -0400 (EDT) Received: from standards (47.234.32.16:3141) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B34C@standards.nortelnetworks.com>; Tue, 3 Oct 2000 7:50:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12355 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 07:50:26 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B34B@standards.nortelnetworks.com>; Tue, 3 Oct 2000 7:50:25 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA01210; Tue, 3 Oct 2000 08:04:48 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA25329; Tue, 3 Oct 2000 08:04:48 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Tue, 3 Oct 2000 08:04:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E73F@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 3 Oct 2000 08:04:47 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: mId field in the Message header X-To: "Bentov, Kohava" To: MEGACO@STANDARDS.NORTELNETWORKS.COM 1. Yes, an MG uses a unique mId in it's header. Unique means there is no duplicate from another MG 2. The mId could be address, address+port, FQDN, NSAP, or something else, as long as it's unique 3. On formats, I'll fall on the usual dictum - senders should be strict in the mId and always send the same thing. Receivers should be tolerant in what they accept. The example was with or without port; the sender should have been consistent, the receiver should tolerate either. Brian -----Original Message----- From: Bentov, Kohava [mailto:kohava.bentov@telrad.co.il] Sent: Tuesday, October 03, 2000 2:35 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: mId field in the Message header Hi, 1. Can we assume that each MG will use a unique mId in its message header when it sends messages to the same MGC ? If yes, is there a mistake in the example (section A.1.1) ? ============================ 1. An MG registers with an MGC using the ServiceChange command: MG1 to MGC: MEGACO/1 [124.124.124.222] ----------------- 4. The MG1 accepts the Modify with this reply: MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 ============================ 2. Is it obvious that the mId of a virtual MG will always consist of IP address + Port ? 3. Is it possible that the mId in one message will be in a domainAddress format and in another message (from the same source) it will be in an mtpAddress format ? I ask these questions because we need unique mIds for managing the transaction database. Best regards, Kohava Bentov Telrad Networks E-mail: kohava.bentov@telrad.co.il Tel: (972)-8-9134353 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 09:28:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10216 for ; Tue, 3 Oct 2000 09:28:52 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B37A@standards.nortelnetworks.com>; Tue, 3 Oct 2000 9:12:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 12413 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 09:12:40 -0400 Received: from ss3000e.cselt.it by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B377@standards.nortelnetworks.com>; Tue, 3 Oct 2000 9:02:35 -0400 Received: from rabadan.cselt.it (rabadan.cselt.it [163.162.4.12]) by ss3000e.cselt.it (PMDF V5.2-31 #43137) with ESMTP id <0G1U00BHGVIWQW@ss3000e.cselt.it> for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 15:16:08 +0200 (MET DST) Received: by rabadan.cselt.it with Internet Mail Service (5.5.2650.21) id ; Tue, 03 Oct 2000 15:18:50 +0200 Content-return: allowed MIME-version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-type: text/plain Message-ID: Date: Tue, 3 Oct 2000 15:16:42 +0200 Reply-To: Pellegrino Paolo Sender: "Media Gateway Control (megaco)" From: Pellegrino Paolo Subject: Media Gateway MIB To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all, I'm looking for standard MIBs for Media Gateway and Telephony over IP devices in general. I read in the Megaco working group web page that one of the planned output is a standard track RFC for the MG and MC MIBs. Moreover a initial draft of MG and MC MIBs is signed as "Done" in the Goals and Milestones sections. However I wasn't able to find documents about these MIBs. Can someone help me? Thank you in advance bye Paolo Pellegrino Paolo Pellegrino Infrastructures Switching Platform Architectures and Systems CSELT Centro Studi e Laboratori Telecomunicazioni S.p.A. 10148 Torino (Italy) - Via Guglielmo Reiss Romoli, 274 Tel. +39 011 2287164 - Fax +39 011 2287003 E_Mail Internet: Paolo.Pellegrino@cselt.it From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 12:13:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA15549 for ; Tue, 3 Oct 2000 12:13:41 -0400 (EDT) Received: from standards (47.234.32.16:4846) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B7F3@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:55:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 13913 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 11:55:12 -0400 Received: from mel.alcatel.fr (mail2.alcatel.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9B7F1@standards.nortelnetworks.com>; Tue, 3 Oct 2000 11:55:12 -0400 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id SAA13272 for ; Tue, 3 Oct 2000 18:09:15 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id SAA15361 for ; Tue, 3 Oct 2000 18:07:01 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id SAA19487 for ; Tue, 3 Oct 2000 18:09:34 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.247.87]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id SAA14176 for ; Tue, 3 Oct 2000 18:09:32 +0200 (MET DST) X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 References: <200010031049.GAA05401@ietf.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <39DA04F3.4602D3E0@ms.alcatel.fr> Date: Tue, 3 Oct 2000 18:10:27 +0200 Reply-To: Thomas LEVY Sender: "Media Gateway Control (megaco)" From: Thomas LEVY Organization: Alcatel Subject: Re: I-D ACTION:draft-levy-megaco-mgdiscovery-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hello All, This draft is intended to discuss 2 alternative solutions to fill the Megaco requirement (RFC 2805) expressed in the section "6.1. Resource Status Management". Especially : " d. Provide an MG Resource Discovery mechanism which must allow an MGC to discover what resources the MG has. Expressing resources can be an arbitrarily difficult problem and the initial release of the protocol may have a simplistic view of resource discovery." The first solution makes use of the ServiceChangeProfile. The second solution makes use of the AuditValue command to audit the media resources of an MG. There are may be other solutions to suggest? Concerning the second solution: A comment that I received from Brian Rosen is that the media resources (or capabilities) description is also in the scope of future SDP. It should be interesting if SDP could integrate "media capabilities" from both terminal and media gateway. It would allow to factorize all the media part into SDP. Any concordant (or discordant !!!) opinion? Thomas, Internet-Drafts@ietf.org a écrit : > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : Megaco/H.248 Media Gateway Resources Discovery > Author(s) : T. Levy, L. Anquetil > Filename : draft-levy-megaco-mgdiscovery-00.txt > Pages : 8 > Date : 02-Oct-00 > > This document addresses the need for a Media Gateway Controller > (MGC) to be informed from the media resources of its Media Gateways > (MG) in the context of the Megaco/H.248 protocol. The draft > discusses alternative solutions for an effective media gateway > resources discovery mechanism. > The document is provided as an informational draft for discussion > within the Megaco Working Group. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-levy-megaco-mgdiscovery-00.txt > > Internet-Drafts are also available by anonymous FTP. Login with the username > "anonymous" and a password of your e-mail address. After logging in, > type "cd internet-drafts" and then > "get draft-levy-megaco-mgdiscovery-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-levy-megaco-mgdiscovery-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > ------------------------------------------------------------------------ > Content-Type: text/plain > Content-ID: <20001002120612.I-D@ietf.org> From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 3 21:08:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25498 for ; Tue, 3 Oct 2000 21:08:41 -0400 (EDT) Received: from standards (47.234.32.16:3714) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BCD7@standards.nortelnetworks.com>; Tue, 3 Oct 2000 19:39:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15545 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 3 Oct 2000 19:39:43 -0400 Received: from ind.alcatel.com (postal.xylan.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9BCD2@standards.nortelnetworks.com>; Tue, 3 Oct 2000 19:29:42 -0400 Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id QAA22413 for ; Tue, 3 Oct 2000 16:44:05 -0700 (PDT) X-Origination-Site: Received: from newman.xylan.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.1 [HUB])) with ESMTP id QAA07943 for ; Tue, 3 Oct 2000 16:43:48 -0700 (PDT) X-InterScan: Passed Received: from ind.alcatel.com ([127.0.0.1]) by newman.xylan.com (Netscape Messaging Server 3.6) with ESMTP id AAA29FB for ; Tue, 3 Oct 2000 16:43:43 -0700 X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DA6F59.C8C90206@ind.alcatel.com> Date: Tue, 3 Oct 2000 16:44:25 -0700 Reply-To: Isabelle Cnudde Sender: "Media Gateway Control (megaco)" From: Isabelle Cnudde Organization: Alcatel Subject: Subtract from MG to MGC? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, When resources associated to a connection is lost, shall the MG send a Subtract command to the MGC to inform the connection is released? like it is the case with MGCP and the DeleteConnection command? Or is a ServiceChange with method=forced is enough? Thanks for your help! Isabelle From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 07:07:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15210 for ; Wed, 4 Oct 2000 07:07:23 -0400 (EDT) Received: from standards (47.234.32.16:3380) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C0D0@standards.nortelnetworks.com>; Wed, 4 Oct 2000 6:51:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16812 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 06:51:12 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C09F@standards.nortelnetworks.com>; Wed, 4 Oct 2000 6:41:12 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14985; Wed, 4 Oct 2000 06:55:38 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200010041055.GAA14985@ietf.org> Date: Wed, 4 Oct 2000 06:55:37 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-boyle-megaco-alerting-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Enhanced Alerting Packages for Megaco/H.248 Author(s) : K. Boyle, C. Brown Filename : draft-boyle-megaco-alerting-00.txt Pages : 7 Date : 03-Oct-00 This document provides proposed definitions for several supplemental packages for Megaco/H.248. These packages address support of functionality for enhanced telephony services, specifically CLASS signaling services. This document is the updated version of the alerting and CLASS packages presented originally in draft-brown- megaco-supplpkgs-00.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boyle-megaco-alerting-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-boyle-megaco-alerting-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-boyle-megaco-alerting-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001003150250.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-boyle-megaco-alerting-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-boyle-megaco-alerting-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001003150250.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 07:07:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15219 for ; Wed, 4 Oct 2000 07:07:27 -0400 (EDT) Received: from standards (47.234.32.16:3380) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C0D9@standards.nortelnetworks.com>; Wed, 4 Oct 2000 6:51:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16813 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 06:51:22 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C0A0@standards.nortelnetworks.com>; Wed, 4 Oct 2000 6:41:22 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15016; Wed, 4 Oct 2000 06:55:48 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200010041055.GAA15016@ietf.org> Date: Wed, 4 Oct 2000 06:55:48 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-boyle-megaco-tonepkgs-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Supplemental Tones Packages for Megaco/H.248 Author(s) : K. Boyle, C. Brown, S. Cornel, S. Doyle, M. Kumar Filename : draft-boyle-megaco-tonepkgs-00.txt Pages : 16 Date : 03-Oct-00 This document provides proposed definitions for several supplemental packages for Megaco/H.248. These packages address support of functionality for basic and enhanced telephony services. This document is the updated version of the tones packages presented originally in draft-brown-megaco-supplpkgs-00.txt. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-boyle-megaco-tonepkgs-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-boyle-megaco-tonepkgs-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-boyle-megaco-tonepkgs-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001003150353.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-boyle-megaco-tonepkgs-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-boyle-megaco-tonepkgs-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001003150353.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 07:44:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA16006 for ; Wed, 4 Oct 2000 07:44:09 -0400 (EDT) Received: from standards (47.234.32.16:1321) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C134@standards.nortelnetworks.com>; Wed, 4 Oct 2000 7:26:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17003 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 07:26:05 -0400 Received: from qhars002.nortel.com (47.101.112.102:59274) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C133@standards.nortelnetworks.com>; Wed, 4 Oct 2000 7:26:05 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Wed, 4 Oct 2000 12:39:23 +0100 Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Wed, 4 Oct 2000 07:36:44 -0400 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Wed, 4 Oct 2000 07:36:39 -0400 Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA17285 for ; Wed, 4 Oct 2000 14:38:46 +0300 (IDT) Received: from tsyspc13 by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id OAA08295; Wed, 4 Oct 2000 14:38:46 +0300 (IDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0037_01C02E10.745732C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Orig: Message-ID: <003a01c02dff$b0e6ccc0$6f0de28d@elex.co.il> Date: Wed, 4 Oct 2000 14:36:17 +0200 Reply-To: "Bentov, Kohava" Sender: "Media Gateway Control (megaco)" From: "Bentov, Kohava" Organization: Telrad Subject: Test To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0037_01C02E10.745732C0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Kohava Bentov=20 Telrad Networks E-mail: kohava.bentov@telrad.co.il Tel: (972)-8-9134353 ------=_NextPart_000_0037_01C02E10.745732C0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
 
    Kohava Bentov=20
    Telrad Networks
    E-mail: kohava.bentov@telrad.co.il=
   =20 Tel: (972)-8-9134353
------=_NextPart_000_0037_01C02E10.745732C0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 08:52:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18002 for ; Wed, 4 Oct 2000 08:52:06 -0400 (EDT) Received: from standards (47.234.32.16:1321) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C26E@standards.nortelnetworks.com>; Wed, 4 Oct 2000 8:35:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17388 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 08:35:57 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C26D@standards.nortelnetworks.com>; Wed, 4 Oct 2000 8:35:57 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA02821; Wed, 4 Oct 2000 08:50:22 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00263; Wed, 4 Oct 2000 08:50:23 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 08:50:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E750@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 4 Oct 2000 08:50:22 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Subtract from MG to MGC? X-To: Isabelle Cnudde To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subtract cannot be sent from the MG to the MGC. ServiceChange is the appropriate command. The MGC should then send Subtract. Brian > -----Original Message----- > From: Isabelle Cnudde [mailto:Isabelle.Cnudde@IND.ALCATEL.COM] > Sent: Tuesday, October 03, 2000 7:44 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Subtract from MG to MGC? > > > Hi, > > When resources associated to a connection is lost, shall the MG send a > Subtract command to the MGC to inform the connection is released? like > it is the case with MGCP and the DeleteConnection command? > Or is a ServiceChange with method=forced is enough? > > Thanks for your help! > Isabelle > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 11:08:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22084 for ; Wed, 4 Oct 2000 11:08:41 -0400 (EDT) Received: from standards (47.234.32.16:1770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C448@standards.nortelnetworks.com>; Wed, 4 Oct 2000 10:47:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17944 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 10:47:05 -0400 Received: from qhars002.nortel.com (47.101.112.102:46482) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C42F@standards.nortelnetworks.com>; Wed, 4 Oct 2000 10:37:05 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Wed, 4 Oct 2000 15:51:14 +0100 Received: from zcard015.ca.nortel.com (actually zcard015) by ertpg14e1.nortelnetworks.com; Wed, 4 Oct 2000 10:51:03 -0400 Received: from ztcfd004.ca.nortel.com ([47.211.192.106]) by zcard015.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id TT34WT57; Wed, 4 Oct 2000 10:51:00 -0400 Received: from americasm10.nt.com (PMERY0H8 [47.72.81.63]) by ztcfd004.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id T7RN0G2A; Wed, 4 Oct 2000 10:50:57 -0400 X-Sybari-Space: 00000000 00000000 00000000 X-Mailer: Mozilla 4.72 [en] (Win95; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E750@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DB4540.B72FD85E@americasm10.nt.com> Date: Wed, 4 Oct 2000 10:57:04 -0400 Reply-To: Michael Brown Sender: "Media Gateway Control (megaco)" From: Michael Brown Organization: Nortel Networks Subject: Re: Subtract from MG to MGC? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I think that a better approach than ServiceChange would be for the MG to report an event indicating the loss of resources. The event in the Base Generic package could be used or if there is a specific event defined in a package for the specific termination involved in the connection then that could be used. This would be the trigger for the MGC to send the SUBRACT (s) as needed to clean up the context or perhaps retry on setting up the connection ... up to the MGC as to what to do. Mike "Rosen, Brian" wrote: > Subtract cannot be sent from the MG to the MGC. > ServiceChange is the appropriate command. > The MGC should then send Subtract. > > Brian > > > -----Original Message----- > > From: Isabelle Cnudde [mailto:Isabelle.Cnudde@IND.ALCATEL.COM] > > Sent: Tuesday, October 03, 2000 7:44 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Subtract from MG to MGC? > > > > > > Hi, > > > > When resources associated to a connection is lost, shall the MG send a > > Subtract command to the MGC to inform the connection is released? like > > it is the case with MGCP and the DeleteConnection command? > > Or is a ServiceChange with method=forced is enough? > > > > Thanks for your help! > > Isabelle > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 11:22:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA22551 for ; Wed, 4 Oct 2000 11:21:59 -0400 (EDT) Received: from standards (47.234.32.16:1770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C4C2@standards.nortelnetworks.com>; Wed, 4 Oct 2000 10:59:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18135 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 10:59:34 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C4C1@standards.nortelnetworks.com>; Wed, 4 Oct 2000 10:59:34 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA19151; Wed, 4 Oct 2000 11:13:59 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09639; Wed, 4 Oct 2000 11:13:59 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Wed, 4 Oct 2000 11:14:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E75B@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 4 Oct 2000 11:13:57 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Subtract from MG to MGC? X-To: Michael Brown To: MEGACO@STANDARDS.NORTELNETWORKS.COM Depends on what the "resource" is, but in general, I'd prefer to see the MG's behavior for a "loss of service" type event to be ServiceChange. If there was some sort of less catastrophic event, then maybe a Notify would be appropriate, but if a Subtract is warranted, then I think a ServiceChange is warranted. Note that IF POSSIBLE, the MG should NOT use "forced", as the MGC may be able to take the call down more gracefully than the MG can. Brian > -----Original Message----- > From: Michael Brown [mailto:C.Michael.Brown@NORTELNETWORKS.COM] > Sent: Wednesday, October 04, 2000 10:57 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Subtract from MG to MGC? > > > I think that a better approach than ServiceChange would be > for the MG to > report an event indicating the loss of resources. The event > in the Base > Generic package could be used or if there is a specific event > defined in a > package for the specific termination involved in the > connection then that > could be used. This would be the trigger for the MGC to send > the SUBRACT (s) > as needed to clean up the context or perhaps retry on setting up the > connection ... up to the MGC as to what to do. > > Mike > > "Rosen, Brian" wrote: > > > Subtract cannot be sent from the MG to the MGC. > > ServiceChange is the appropriate command. > > The MGC should then send Subtract. > > > > Brian > > > > > -----Original Message----- > > > From: Isabelle Cnudde [mailto:Isabelle.Cnudde@IND.ALCATEL.COM] > > > Sent: Tuesday, October 03, 2000 7:44 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Subtract from MG to MGC? > > > > > > > > > Hi, > > > > > > When resources associated to a connection is lost, shall > the MG send a > > > Subtract command to the MGC to inform the connection is > released? like > > > it is the case with MGCP and the DeleteConnection command? > > > Or is a ServiceChange with method=forced is enough? > > > > > > Thanks for your help! > > > Isabelle > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 12:32:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA25319 for ; Wed, 4 Oct 2000 12:32:43 -0400 (EDT) Received: from standards (47.234.32.16:1770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C69C@standards.nortelnetworks.com>; Wed, 4 Oct 2000 12:16:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18756 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 12:16:35 -0400 Received: from qhars002.nortel.com (47.101.112.102:54569) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9C696@standards.nortelnetworks.com>; Wed, 4 Oct 2000 12:16:34 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Wed, 4 Oct 2000 17:14:00 +0100 Received: from zmers013 (actually zmers013.ca.nortel.com) by zrtps06s.us.nortel.com; Wed, 4 Oct 2000 12:13:50 -0400 Received: from tlhuph12.elex.co.il (actually ertpg1e0.us.nortel.com) by zmers013; Thu, 28 Sep 2000 07:15:10 -0400 Received: from tmx100.elex.co.il (tmx100.elex.co.il [141.226.8.254]) by tlhuph12.elex.co.il (8.8.6 (PHNE_14041)/8.8.6) with ESMTP id OAA25270 for ; Thu, 28 Sep 2000 14:17:27 +0300 (IDT) Received: from tsyspc13 by tmx100.elex.co.il (8.8.8+Sun/SMI-SVR4) id OAA16560; Thu, 28 Sep 2000 14:17:26 +0300 (IDT) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0065_01C02956.71C472C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-Orig: Message-ID: <006801c02945$ae5d3480$6f0de28d@elex.co.il> Date: Thu, 28 Sep 2000 14:14:41 +0200 Reply-To: "Bentov, Kohava" Sender: "Media Gateway Control (megaco)" From: "Bentov, Kohava" Organization: Telrad Subject: mId field in the Message header To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_0065_01C02956.71C472C0 Content-Type: text/plain; charset="windows-1255" Content-Transfer-Encoding: quoted-printable Hi, 1. Can we assume that each MG will use a unique mId in its message = header when it=20 sends messages to the same MGC ? =20 If yes, is there a mistake in the example (section A.1.1) ? =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =20 1. An MG registers with an MGC using the ServiceChange command: MG1 to MGC: MEGACO/1 [124.124.124.222] ----------------- 4. The MG1 accepts the Modify with this reply: MG1 to MGC: MEGACO/1 [124.124.124.222]:55555 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D =20 2. Is it obvious that the mId of a virtual MG will always consist of = IP address + Port ?=20 =20 3. Is it possible that the mId in one message will be in a = domainAddress format and in=20 another message (from the same source) it will be in an = mtpAddress format ?=20 =20 I ask these questions because we need unique mIds for managing=20 the transaction database. =20 Best regards, Kohava Bentov=20 Telrad Networks E-mail: kohava.bentov@telrad.co.il Tel: (972)-8-9134353 ------=_NextPart_000_0065_01C02956.71C472C0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable
Hi,
 
  1.  Can we assume that = each MG=20 will use a unique mId in its message header = when it=20
      =20 sends messages to the same MGC ? 
       If = yes, is=20 there a mistake in the example (section A.1.1) ?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D 

1. An MG registers with an MGC using the ServiceChange=20 command:

MG1 to MGC:

MEGACO/1 [124.124.124.222]

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

4. The MG1 accepts the Modify with this reply:

MG1 to MGC:

MEGACO/1=20 [124.124.124.222]:55555

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D 
 
  2.  Is it obvious that the = mId of a=20 virtual MG will always consist of IP address + Port = ?=20
 
  3.  Is it possible that the = mId in one=20 message will be in a domainAddress format and in
       = another=20 message (from the same source) it will be in an mtpAddress format ?=20
 
  I ask these questions because we = need=20 unique mIds for managing
the transaction=20 database.  
 
Best regards,
    Kohava Bentov=20
    Telrad Networks
    E-mail: kohava.bentov@telrad.co.il=
   =20 Tel: (972)-8-9134353
------=_NextPart_000_0065_01C02956.71C472C0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 18:54:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA03518 for ; Wed, 4 Oct 2000 18:54:42 -0400 (EDT) Received: from standards (47.234.32.16:3418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CCFB@standards.nortelnetworks.com>; Wed, 4 Oct 2000 18:38:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20861 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 18:38:45 -0400 Received: from mail-gw.NetergyNet.COM (mail-gw.8x8.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CCF2@standards.nortelnetworks.com>; Wed, 4 Oct 2000 18:28:45 -0400 Received: from mail.8x8.COM (mail.8x8.com [192.84.19.130]) by mail-gw.NetergyNet.COM (8.9.3+Sun/8.9.3) with ESMTP id PAA20617 for ; Wed, 4 Oct 2000 15:43:12 -0700 (PDT) Received: from 8x8.com (ronin.8x8.com [207.82.37.57]) by mail.8x8.COM (8.9.1b+Sun/8.9.1) with ESMTP id PAA16035 for ; Wed, 4 Oct 2000 15:43:11 -0700 (PDT) X-Mailer: Mozilla 4.75 [en] (X11; U; Linux 2.2.17 i686) X-Accept-Language: fr-FR, fr, en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DBB27F.FD3F0914@8x8.com> Date: Wed, 4 Oct 2000 15:43:11 -0700 Reply-To: petithug@NETERGYNET.COM Sender: "Media Gateway Control (megaco)" From: Marc Petit-Huguenin Organization: Netergy Networks Inc. Subject: Next interop To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, Do you know if a bakeoff for megaco is planned soon? Thanks. -- Marc Petit-Huguenin Home: mailto:petithug@cyberservices.com Work: mailto:petithug@netergynet.com "So much to do and so little time" The Joker - Batman (The Movie) From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 19:51:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA04706 for ; Wed, 4 Oct 2000 19:51:22 -0400 (EDT) Received: from standards (47.234.32.16:3418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CDA4@standards.nortelnetworks.com>; Wed, 4 Oct 2000 19:35:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21084 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 19:35:27 -0400 Received: from ind.alcatel.com (postal.xylan.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CD9D@standards.nortelnetworks.com>; Wed, 4 Oct 2000 19:25:21 -0400 Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id QAA18598 for ; Wed, 4 Oct 2000 16:39:47 -0700 (PDT) X-Origination-Site: Received: from newman.xylan.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.1 [HUB])) with ESMTP id QAA10076 for ; Wed, 4 Oct 2000 16:39:29 -0700 (PDT) X-InterScan: Passed Received: from ind.alcatel.com ([127.0.0.1]) by newman.xylan.com (Netscape Messaging Server 3.6) with ESMTP id AAA645F for ; Wed, 4 Oct 2000 16:39:24 -0700 X-Mailer: Mozilla 4.72 [en] (X11; U; Linux 2.2.14-5.0 i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DBC030.4771EF2B@ind.alcatel.com> Date: Wed, 4 Oct 2000 16:41:36 -0700 Reply-To: Rashi Arya Sender: "Media Gateway Control (megaco)" From: Rashi Arya Organization: Alcatel Subject: Order of ADD commands ! To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, Is the ordering of ADD commands from the MGC significant in the Megaco protocol ? I need to know if the Media Gateway can receive an RTP ADD from the MGC before receiving an ADD for the TDM termination ? I assume they can come in any order, but just need a clarification. Thanks in advance, Rashi. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 4 20:04:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA04897 for ; Wed, 4 Oct 2000 20:04:27 -0400 (EDT) Received: from standards (47.234.32.16:3418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CDDA@standards.nortelnetworks.com>; Wed, 4 Oct 2000 19:48:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21139 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 4 Oct 2000 19:48:35 -0400 Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CDC5@standards.nortelnetworks.com>; Wed, 4 Oct 2000 19:38:35 -0400 Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by turin.trillium.com (8.11.0/8.11.0) with ESMTP id e94Nvh113343 for ; Wed, 4 Oct 2000 16:57:44 -0700 (PDT) Received: from aega.trillium.com ([10.242.100.206]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id QAA25918 for ; Wed, 4 Oct 2000 16:52:42 -0700 (PDT) Received: by AEGA with Internet Mail Service (5.5.2650.21) id <4C335AC3>; Wed, 4 Oct 2000 16:43:01 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8BBD33A986C5D311804000902719FF5D31BBCC@AEGA> Date: Wed, 4 Oct 2000 16:43:00 -0700 Reply-To: Yuyong Zhang Sender: "Media Gateway Control (megaco)" From: Yuyong Zhang Subject: Inconsistent between ABNF and text about audit reply parameter. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi All, There is inconsistency between ABNF and the text desciption about audit reply value. 1. In the ABNF, there is contextTerminationAudit to return just a list of termination IDs for a context, but it is not clear "contextTerminationAudit" is a reply to which combination of ContxtId and TerminationID in the table of section 7.2.5. 2. In the last entry of the table in section 7.2.5 indicates that audit reply shall return a list of contextIds for audit request with ContxtId=ALL and TerminationId=Root. However there is not such contextId list in the auditReply defines in ABNF. Would you please clarify this, which one shall I follow, the ABNF or the text? Regards, Yuyong From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 01:12:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA11163 for ; Thu, 5 Oct 2000 01:12:21 -0400 (EDT) Received: from standards (47.234.32.16:4527) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CF08@standards.nortelnetworks.com>; Thu, 5 Oct 2000 0:56:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21564 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 00:56:03 -0400 Received: from viggen.broadcom.com (dns.broadcom.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CF07@standards.nortelnetworks.com>; Thu, 5 Oct 2000 0:56:03 -0400 Received: from mail-irva-1.broadcom.com (mail-irva-1.broadcom.com [10.4.10.10]) by viggen.broadcom.com (8.9.3/8.9.3/FW03) with ESMTP id WAA21249 for ; Wed, 4 Oct 2000 22:10:31 -0700 (PDT) Received: from dashaus.hothaus.com ([10.136.20.22]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-67550U3000L400S0V35) with ESMTP id com for ; Wed, 4 Oct 2000 22:10:29 -0700 Received: by DASHAUS with Internet Mail Service (5.5.2650.21) id <4C00HK8K>; Wed, 4 Oct 2000 22:09:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02E8A.785DDD00" Message-ID: <5713E3714F03D4118AB9009027D5B3A23D0A5B@NT-RMNA-EXCH> Date: Wed, 4 Oct 2000 22:09:54 -0700 Reply-To: Bob Lukas Sender: "Media Gateway Control (megaco)" From: Bob Lukas Subject: Issues with draft-ietf-megaco-ipphone-03.txt To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C02E8A.785DDD00 Content-Type: text/plain; charset="iso-8859-1" We've been looking at implementing draft-ietf-megaco-ipphone-03.txt and a few thorny issues have come up that I haven't seen discussed. Keypad and hookswitch are extensions of the basic annex G key package in the UI termination - this means: 1. There is no "current state" property value of these switches, only keyup and keydown events that are generated. e.g. the event reported is key/ku{keyid=kh} for an off-hook event. Not normally an issue for momentary push-buttons, but it means an MGC cannot audit for whether the phone is currently off-hook. Kind of a problem for an MGC that is trying to recover state at startup... 2. At times, I'm only interested in events from a subset of the possible keys. How can I set an event descriptor to only monitor hookswitch (for example), and not random other button presses? Is this syntax legal? ...modify = ui { events =1 { key/ku { keyid = kh }, key/kd { keyid = f001} } If it was, it would help overcome the audit issue, by getting an immediate event if currently off-hook. 3. The audio transducers are separate terminations from the UI. This has great impact on wanting to automatically stop call progress tones immediately when keys are pressed. As far as I understand, an event occuring in one termination must not affect the signals active in another termination (which would be a huge problem for a multiple line device for example). For example, I cannot have dialtone automatically stop when I press a key - the MGC must send down a signal to explicitly stop it. Even worse, if I choose to implement a digitmap on my keypad, the MGC has no way of knowing when to stop dialtone, because it gets no event until after the entire dial string is entered. Saying the IP Phone should know and understand the implicit interactions between the terminations is also problematic and against the general Megaco philosophy of centralized control. _____________________________________________________ Bob Lukas Broadcom Canada Richmond B.C. blukas@broadcom.com 604-233-8665 ------_=_NextPart_001_01C02E8A.785DDD00 Content-Type: text/html; charset="iso-8859-1"

We've been looking at implementing draft-ietf-megaco-ipphone-03.txt and a few thorny issues have come up that I haven't seen discussed. Keypad and hookswitch are extensions of the basic annex G key package in the UI termination - this means:

1. There is no "current state" property value of these switches, only keyup and keydown events that are generated. e.g. the event reported is key/ku{keyid=kh} for an off-hook event. Not normally an issue for momentary push-buttons, but it means an MGC cannot audit for whether the phone is currently off-hook. Kind of a problem for an MGC that is trying to recover state at startup...

2. At times, I'm only interested in events from a subset of the possible keys. How can I set an event descriptor to only monitor hookswitch (for example), and not random other button presses?
Is this syntax legal? ...modify = ui { events =1 { key/ku { keyid = kh }, key/kd { keyid = f001} }
If it was, it would help overcome the audit issue, by getting an immediate event if currently off-hook.

3. The audio transducers are separate terminations from the UI. This has great impact on wanting to automatically stop call progress tones immediately when keys are pressed. As far as I understand, an event occuring in one termination must not affect the signals active in another termination (which would be a huge problem for a multiple line device for example). For example, I cannot have dialtone automatically stop when I press a key - the MGC must send down a signal to explicitly stop it. Even worse, if I choose to implement a digitmap on my keypad, the MGC has no way of knowing when to stop dialtone, because it gets no event until after the entire dial string is entered. Saying the IP Phone should know and understand the implicit interactions between the terminations is also problematic and against the general Megaco philosophy of centralized control.

_____________________________________________________
Bob Lukas
Broadcom Canada
Richmond B.C.
blukas@broadcom.com
604-233-8665


------_=_NextPart_001_01C02E8A.785DDD00-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 01:42:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA15036 for ; Thu, 5 Oct 2000 01:42:03 -0400 (EDT) Received: from standards (47.234.32.16:4399) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CF5B@standards.nortelnetworks.com>; Thu, 5 Oct 2000 1:26:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21662 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 01:26:01 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9CF55@standards.nortelnetworks.com>; Thu, 5 Oct 2000 1:16:01 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e955UTZ28345 for ; Thu, 5 Oct 2000 07:30:29 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id HAA20737 for ; Thu, 5 Oct 2000 07:30:27 +0200 (MET DST) Received: from ericsson.com (mcdh98.epa.ericsson.se [146.11.81.98]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA08486 for ; Thu, 5 Oct 2000 07:30:25 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <39DBD3D5.6A5F7720@ericsson.com> Date: Thu, 5 Oct 2000 12:05:25 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Priority Clarification in Implementors' Guide To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit G'Day all, I've had a couple of question on context priority and what values mean what (ie. is 15 highest or 0?). I propose to add the following to Implementors' Guide to clarify the situation. Does any one have problems with the proposed text? 9.4 Context Priorities Description: It is unclear in the recommendation on what the values of the priorities represent. Reference: Editor [Begin Clarification] 6.1.1 Context Attributes and Descriptors … The priority is used for a context in order to provide the MG with information about a certain precedence handling for a context. The MGC can also use the priority to control autonomously the traffic precedence in the MG in a smooth way in certain situations (e.g. restart), when a lot of contexts must be handled simultaneously. >>>>>>> Priority 0 represents no priority, priority 1 is the lowest priority and a priority of 15 is the highest priority. <<<<<<< [End Clarification] Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 09:02:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28146 for ; Thu, 5 Oct 2000 09:02:20 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D401@standards.nortelnetworks.com>; Thu, 5 Oct 2000 8:46:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23259 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 08:46:07 -0400 Received: from mink.ecitele.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D400@standards.nortelnetworks.com>; Thu, 5 Oct 2000 8:46:06 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id PAA06536 for ; Thu, 5 Oct 2000 15:59:34 +0300 (IDT) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3 (Intl)|21 March 2000) at 05/10/2000 04:01:06 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Thu, 5 Oct 2000 15:55:57 +0300 Reply-To: Shlomo.Kabaz@ECITELE.COM Sender: "Media Gateway Control (megaco)" From: Shlomo Kabaz ECItelecom Subject: provisioning To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi , all ! I wanted to ask what are the sources for provisioning ? Shlomo From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 09:06:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28272 for ; Thu, 5 Oct 2000 09:06:51 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D424@standards.nortelnetworks.com>; Thu, 5 Oct 2000 8:50:17 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23307 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 08:50:17 -0400 Received: from mink.ecitele.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D423@standards.nortelnetworks.com>; Thu, 5 Oct 2000 8:50:14 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id QAA06892 for ; Thu, 5 Oct 2000 16:03:46 +0300 (IDT) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3 (Intl)|21 March 2000) at 05/10/2000 04:05:17 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Thu, 5 Oct 2000 16:00:10 +0300 Reply-To: Shlomo.Kabaz@ECITELE.COM Sender: "Media Gateway Control (megaco)" From: Shlomo Kabaz ECItelecom Subject: auditing when everything is in th NULL context To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi , all . I wonder , when all terminations are in the NULL context what should be replied in the localControlDescriptor in the StreamMode , is it just not present in this descriptor ? Secondly , i wonder what are the properties that are replied in the local control descriptor ? regards , Shlomo . From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 09:46:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28949 for ; Thu, 5 Oct 2000 09:46:51 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D4FE@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:30:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23590 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 09:30:46 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D4FD@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:30:46 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA16573; Thu, 5 Oct 2000 09:45:14 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06323; Thu, 5 Oct 2000 09:45:16 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 09:45:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E765@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 5 Oct 2000 09:45:13 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Next interop X-To: "petithug@NETERGYNET.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I've been thinking of around the end of January. I'll announce it to the list when we get it more organized. Brian > -----Original Message----- > From: Marc Petit-Huguenin [mailto:petithug@NETERGYNET.COM] > Sent: Wednesday, October 04, 2000 6:43 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Next interop > > > Hi, > > Do you know if a bakeoff for megaco is planned soon? > > Thanks. > > -- > Marc Petit-Huguenin > Home: mailto:petithug@cyberservices.com > Work: mailto:petithug@netergynet.com > "So much to do and so little time" The Joker - Batman (The Movie) > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 09:53:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29134 for ; Thu, 5 Oct 2000 09:53:46 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D53F@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:36:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23672 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 09:36:44 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D53D@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:36:44 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA17154; Thu, 5 Oct 2000 09:51:12 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07780; Thu, 5 Oct 2000 09:51:14 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 09:51:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E766@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 5 Oct 2000 09:51:12 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Order of ADD commands ! X-To: Rashi Arya To: MEGACO@STANDARDS.NORTELNETWORKS.COM The MG executes commands in a transaction in order. The MG can execute transactions in any order. There are procedures detailed that illustrate how the MGC can control the order transactions are executed when it cares. In general the MG should be able to add ephemeral (RTP for example) and physical (analog line for example) terminations in any order. How it occurs is up to the MGC. I'll give you a couple of example of how this might work. Some MGCs may treat dialed digit collection as events that happen in the Null context. It can instruct the MG to apply dial tone, program a DigitMap, and wait for the terminal digit without creating a new context. It then might create a new context for the RTP termination, and then put the physical termination in the context, or it could put the physical one in first, and then the ephemeral. On the other hand, it could create a context as soon as off hook was detected, in which case the physical termination would be first in the context always. YMMV, the MG has to be able to deal with all of this, and maybe more! Brian > -----Original Message----- > From: Rashi Arya [mailto:rashi.arya@IND.ALCATEL.COM] > Sent: Wednesday, October 04, 2000 7:42 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Order of ADD commands ! > > > Hi, > > Is the ordering of ADD commands from the MGC significant in the Megaco > protocol ? > > I need to know if the Media Gateway can receive an RTP ADD > from the MGC > before receiving an ADD for the TDM termination ? I assume they can > come in any order, but just need a clarification. > > Thanks in advance, > Rashi. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 10:10:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29547 for ; Thu, 5 Oct 2000 10:10:47 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D591@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:54:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23777 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 09:54:46 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D590@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:54:46 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19018; Thu, 5 Oct 2000 10:09:14 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA11976; Thu, 5 Oct 2000 10:09:16 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 10:09:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E767@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 5 Oct 2000 10:09:14 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: auditing when everything is in th NULL context X-To: "Shlomo.Kabaz@ECITELE.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM > I wonder , when all terminations are in the NULL context > what should be > replied in the localControlDescriptor in the > StreamMode , is it just not present in this descriptor ? > Secondly , i wonder what are the properties that are replied > in the local > control descriptor ? Hmmm, excellent question. The root of the question is, "are there any streams active for a termination in Null Context?" There is a somewhat wider question which is "do streams have to be explicitly created before any stream-dependent properties/events/signals can be audited?" The latter leads to the question "when is a stream created?" I just posted an answer to a list question that used an example of applying a signal (dialtone) to a termination which was in the null context. If that is legal, then streams CAN be active on a termination in the null context. We get back to when is the stream created? I don't recall any discussion on this point. I think there are two possibilities: The first action that creates media (be it a Media/Local/Remote descriptor, or a signal, creates a media stream, and a Subtract, or a properly constructed Media/Local/Remote descriptor deletes streams. This implies that there are no streams active on a termination in null context after boot, or after a subtract, but you create one by putting media on the termination. There is always a default StreamId=1 stream, others are created by a Media descriptor, and deleted by a Media Descriptor or Subtract. I'd favor the former, but don't think there is very much practical difference except the exact question you asked. If there are no streams at some times then if you audited, you would never get a LocalControl, nor a StreamMode when there was not a stream, and you would when there was. If there are always streams with StreamId=1, then you do get StreamMode, and you also get a LocalControl descriptor. The second question you ask is easier to answer. If there are any properties defined in LocalControl for packages implemented on a termination, then those values are returned in LocalControl for active streams. "Active" is the issue, as discussed above. Need more opinions I think. Maybe this was settled, and I just don't remember how. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 10:14:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29598 for ; Thu, 5 Oct 2000 10:14:47 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D5A2@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:56:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23800 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 09:56:26 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D5A1@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:56:26 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA19163; Thu, 5 Oct 2000 10:10:54 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA12237; Thu, 5 Oct 2000 10:10:56 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 10:10:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E768@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 5 Oct 2000 10:10:53 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: provisioning X-To: "Shlomo.Kabaz@ECITELE.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Not defined in the protocol. Could be a MIB, could be some database the element has access to (via LDAP for example). Could be completely proprietary. The Megaco/H.248 protocol doesn't know, doesn't care. Now, a profile could define such a thing! Brian > -----Original Message----- > From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM] > Sent: Thursday, October 05, 2000 8:56 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: provisioning > > > Hi , all ! > I wanted to ask what are the sources for provisioning ? > > Shlomo > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 10:14:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29601 for ; Thu, 5 Oct 2000 10:14:48 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D5CB@standards.nortelnetworks.com>; Thu, 5 Oct 2000 10:00:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23773 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 10:00:02 -0400 Received: from o2ogate.one2one.co.uk (193.131.126.162:40939) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D58E@standards.nortelnetworks.com>; Thu, 5 Oct 2000 9:50:02 -0400 Received: from kitts.one2one.co.uk (kitts.one2one.co.uk [149.254.76.208]) by o2ogate.one2one.co.uk (8.9.3/8.9.3) with ESMTP id PAA26481 for ; Thu, 5 Oct 2000 15:04:31 +0100 (BST) Received: from mailhost.one2one.co.uk (localhost [127.0.0.1]) by kitts.one2one.co.uk (8.9.3/8.9.3) with ESMTP id PAA02301 for ; Thu, 5 Oct 2000 15:04:30 +0100 (BST) Received: from imp01ims.One2One.co.uk (imp01ims [149.254.72.7]) by mailhost.one2one.co.uk (8.9.3/8.9.3) with ESMTP id PAA27017 for ; Thu, 5 Oct 2000 15:04:30 +0100 (BST) Received: by imp01ims.one2one.co.uk with Internet Mail Service (5.5.2448.0) id ; Thu, 5 Oct 2000 15:02:13 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <402DD461F109D411977E0008C791C312026C80CB@imp02mbx.one2one.co.uk> Date: Thu, 5 Oct 2000 15:02:07 +0100 Reply-To: Saayman Ahmed Sender: "Media Gateway Control (megaco)" From: Saayman Ahmed Subject: Megaco &Mgcp To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello there, Can you please direct me to where I find information about the difference between MEGACO & MGCP. "Why is the Megaco preferred choice for the UMTS release 2000 architecture?" Thanks Saayman Saayman Ahmed one2one Technology Strategy 020 8214 5273 NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 10:31:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29829 for ; Thu, 5 Oct 2000 10:31:35 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D609@standards.nortelnetworks.com>; Thu, 5 Oct 2000 10:14:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23940 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 10:14:02 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D608@standards.nortelnetworks.com>; Thu, 5 Oct 2000 10:14:01 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20975; Thu, 5 Oct 2000 10:28:29 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA17309; Thu, 5 Oct 2000 10:28:32 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 10:28:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E76B@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 5 Oct 2000 10:28:30 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Megaco &Mgcp X-To: Saayman Ahmed To: MEGACO@STANDARDS.NORTELNETWORKS.COM There is an excellent comparison of technical differences in a talk delivered by Flemming Andreasen of Cisco at the last VON Developers conference. There is also the issue that MGCP is an ad-hoc standard, although the IETF has published an Informational RFC (2705)that is commonly used as the reference. The Megaco/H.248 protocol is the official standard of both the IETF and the ITU. That may have some influence on why the UMTS is leaning towards it. Organizations like the Multiservice Switching Forum have also chosen Megaco as their preferred standard for media device control. Several carriers are also now specifying Megaco for future direction. Lots of folks don't care, and lots of vendors are implementing both. Brian > -----Original Message----- > From: Saayman Ahmed [mailto:Saayman.Ahmed@ONE2ONE.CO.UK] > Sent: Thursday, October 05, 2000 10:02 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Megaco &Mgcp > > > Hello there, > Can you please direct me to where I find information about > the difference > between MEGACO & MGCP. "Why is the Megaco preferred choice > for the UMTS > release 2000 architecture?" > > Thanks > Saayman > > Saayman Ahmed > one2one > Technology Strategy > 020 8214 5273 > > > > > NOTICE AND DISCLAIMER: > This email (including attachments) is confidential. If you > have received > this email in error please notify the sender immediately and > delete this > email from your system without copying or disseminating it or > placing any > reliance upon its contents. We cannot accept liability for > any breaches of > confidence arising through use of email. Any opinions > expressed in this > email (including attachments) are those of the author and do > not necessarily > reflect our opinions. We will not accept responsibility for > any commitments > made by our employees outside the scope of our business. We > do not warrant > the accuracy or completeness of such information. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 10:31:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA29839 for ; Thu, 5 Oct 2000 10:31:37 -0400 (EDT) Received: from standards (47.234.32.16:2087) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D613@standards.nortelnetworks.com>; Thu, 5 Oct 2000 10:14:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23920 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 10:14:54 -0400 Received: from email2.chelmsford.castlenetworks.com (mailhost2.castlenetworks.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9D5F8@standards.nortelnetworks.com>; Thu, 5 Oct 2000 10:04:51 -0400 Received: by email2.chelmsford.castlenetworks.com with Internet Mail Service (5.5.2650.21) id ; Thu, 5 Oct 2000 10:23:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/mixed; boundary="----_=_NextPart_000_01C02ED7.DB10C6D0" Message-ID: <9DCB6C9DC7C3D311B835009027DE069F012BE21D@email2.chelmsford.castlenetworks.com> Date: Thu, 5 Oct 2000 10:23:39 -0400 Reply-To: "Greenberg, Gary" Sender: "Media Gateway Control (megaco)" From: "Greenberg, Gary" Subject: Re: Megaco &Mgcp X-To: Saayman Ahmed To: MEGACO@STANDARDS.NORTELNETWORKS.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_01C02ED7.DB10C6D0 Content-Type: text/plain; charset="iso-8859-1" -----Original Message----- From: Saayman Ahmed [mailto:Saayman.Ahmed@ONE2ONE.CO.UK] Sent: Thursday, October 05, 2000 10:02 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Megaco &Mgcp Hello there, Can you please direct me to where I find information about the difference between MEGACO & MGCP. "Why is the Megaco preferred choice for the UMTS release 2000 architecture?" Thanks Saayman Saayman Ahmed one2one Technology Strategy 020 8214 5273 NOTICE AND DISCLAIMER: This email (including attachments) is confidential. If you have received this email in error please notify the sender immediately and delete this email from your system without copying or disseminating it or placing any reliance upon its contents. We cannot accept liability for any breaches of confidence arising through use of email. Any opinions expressed in this email (including attachments) are those of the author and do not necessarily reflect our opinions. We will not accept responsibility for any commitments made by our employees outside the scope of our business. We do not warrant the accuracy or completeness of such information. ------_=_NextPart_000_01C02ED7.DB10C6D0 Content-Type: application/octet-stream; name="MegacovsMGCPv1.pdf" Content-Disposition: attachment; filename="MegacovsMGCPv1.pdf" Content-Transfer-Encoding: base64 JVBERi0xLjIgDQol4uPP0w0KIA0KNyAwIG9iag0KPDwNCi9MZW5ndGggOCAwIFINCi9GaWx0ZXIg L0xaV0RlY29kZSANCj4+DQpzdHJlYW0NCoAQioDRyMBANxgORcNBoIBAVCIDYNExAcjOIAaLyNBh iMRcMIbDzMDRaMI+OBsOIcVDGIJMMhhKZWdxAKCGbzacDCcjSbouICaZTOYTGbxAYTcZKARyGUBT DzVEhALRiMxcMpWRKnJhjDBrK5bLxsNK/D5oKCCdToaDech0ICdSDGeRARzkZTKbjKLBBPrveTKQ DdbToZTZejod7aazmLqKbaeVKiVBVW4+MxuObBLhcMRrmZnNSIYcLbymZTgdBAMhmLxyOcjUYMLR nChtWctVZjm5eNd3ZpqVDQZRAdDCYjYZTmIDFhjfNMfOrvxeHQKFRKMcDkbzob6KbBAWxiXb5a+J ijka57FzJ3jqbbzqjeZupxKDQ6KICuR75sQaGgYhszrboMh6tJKzqqs0h6wtCFCkDI/wWwBAUAqm qqrtxBCOhgsqWM41kOwcJqmCg8IZBYGYuhch7juSEAYqOMgyLuOY5uUEA5jgMoxjSMw0paoo3DG1 A6Dmvg7jQNMXuM5DiKwM40jtHAwhAx42wg5i6SvCD/NnDCsQMyyEhhMMPwKKizuinY0jmN43BdLy phlASQog3Kqw8sKrhmGcPLO4TiDON4wvA+b6uLFziTa4qjSUM40DYNNINUOY0jbJc2DoNMqKSEAy R8MwyrvIccUO8yjjg7VCDG4bGoe6sSKbOSqKtM0Dq4GQYzNPYZQBM01DeNj3jcECe0RJsXjuMLlu 01CdjKpVjv8zwbhcmU0Vwj6ETtPYYoLOyziandWr5b7X2NYrvjY462tINM3hAO40rWEAhjQng502 pAQCQOt6DLLE4qgklq2ulQWzohcNK4GocBu3irhvh8HCCN0tpw+A3SNRtjJy7cphAOo4XitdGWS4 loXkwzHjLFgoOTZjiRvTzzDbRtaTBhkBhliEGJdBy/LwvTBMIwzEPQxjHJxWmFTtbQYhgG+fTOq+ e6os4nCeKgiuo0jqUZRmtCoo8rJwODksLRMnBBQ9CvAu443+u+NY5LK2JpVFVu674QSmOVLTeOec 1tnddhxbsQBpxEHTWu8WOFRl9SW8C9Wi5buuY4j2r1gbJKlhM68MGteaA4AUCkMtRVJInB4JL/Cz FBEOoTiIYoRBc0pq8QuhBaiVWzMYbBrxKuBx4kHCNFghjrUY7DevghRYJHKL4J0WLtoa93t6d/sL LC+CDzyopgj3GeD2YaBmlWfq4G31wcEApDCPI0KR6MWCkN+aL4JUWH+BytZbDOyEp6RAZ5Bxpwzq jSOCAERQVQJVCOaQMqyw8oSBka8FzpELuxTu7MHIMX2NVV1CJxqbw6HbPA3s7ywgQBcBQfc7ALwk FXcWFwFIIi+BXMWesEARD3N1bafRVASQihUCMdY/BRj9l8B4jQMIZg6AtU4HQMwLXCIZdkSYhKu2 IwlWATU+ESwWwsO+SUGgLg6B4DoD6F4KC2ggikHAHQLwXr6QgTsMhjTBhyMKYcMpiTFmNMeC+McM z2hjDmC9dhhV9SGOuUWLDBDKJjcWbxBwaFfA4C+f5noLgZoEgIDV27tgbyldPGZYQLg4BkPpC8FJ fDTmpRga82DBEJg1lAbdWsWoPxcN87lbzuEHBbBk7137pk7xcBuz1iJIAbgzRG/9ghnlrzKW0DBx DxSrkgXCTUIIcikKDfDNRz8pJrvoi4DQGCMX2oDnag4IgdShhuL4ElFgRQ2KSO4HQvgQ3usAfACA Kc5ioldjSDmUUWyPg0gC7YG1D3ThQSAGuQM/oHKyRMVyHQIInziikC0ND3mAhhkm59hKu0Bwdl9N kG0GXbA4pg6eQ8kg2hnDGHAFodgYByBiSWXUa42l8XGXRc8t6UQml6rdMcwZMOnC2iqZLwZmTOnf NCaTpwm0GAbNahcvyTkMi/N5is4ifPQBA+J3zBJ0VfmzOydzVUAzxdPPOes958z7XgHSjFAF+0ko HQWtbn6EAuoVNiS1Eq5URawTWigY6LV8L5A9EqMCP0do/FGKdI6BUmgxSpC1S4CNTm4t8G83wUU1 DeC2m9Oad0/TLGqNgPnwz0DqvqWpr0JVKadARPxt53meBrcB3QKAqKKsG+Raz53DNSmEiBnruSzo xJu38MMC4ho5R2j1H5LU2hzebItISRDUuupRJ9xkvQc1MhBAh9qDgko2eaC91Lcg0l3izexhoNGq K9tPY21J8UZI0OUjdCLBGpwbKwzqhjUSuxfV1aiGR+XeSeJiC4HDwICAwqzXI1iI7KzGPIeGqTBI jgNcYn1OrwAXTNM5i46ZI8UyhIXizFxJsYHExlGnF2KsakHQFjYrGMaug2I9BzH0l8cFYyWRXHWR QZQ2BBkklRMHRZNyJKEHC1yG5UxfkzFuQ8nyhIVKHKeNJLwiy2hbLGTwamfwVmfFeX86ZEzetbJG aMhZ1yfilqJJ86W9yIgHI5WAZ5/m1oF0WWSU5cynojPegs3ZwyRpDRTC8iECIIQaDOW4RkRdmn7D qDXT3xvAGUj1+XR1WQ+CgIjqier0XgG68xUcEwcwZWAhJoGfgoI8FRUamA3LvTeDrVVDGpPvM2Ci k5USrVuBARpGJHaGkrJGmglu1E+u1dPcmrsaSGvBI0RwjxINrEki4DgHOo0QEJw6Wcoim3BJWX4c 1T+sC9LSWKlUOYYyeS0hhv3f6Rtj1gV3tyEk7LpE1O4cMOTXliqgSiapLAcDlmDNUHmQK6QQSqDZ Di3bCNczZBvsq97p9mgN2fYjaSMNyp22uZvbQM+EFn28V1he4iN8u2qSLdBnQZPIner7oVxbwKqa MUoMqU2NnLSypYM+ww2dOOmGTfC0eCzZBrYe4JmbiFnDEXRVCNz5H0J1ZC66OC1tfXojlkbJI/GN 5DSy/S2+TJnQdynlfOtp8v3Ptjnm2+Fgo5vuDlnO9qbm58huUN/UQXDwB0s+PTgxqbDtBQpXYeOr sR6T4+rN1jlI6yniU8XzMVxLOEXpiRtX8CDSamOPoVihBRm23h4TQ3qgDNBeXFSuRpj5LuxNBZ+9 TpNxy3xPMCpM/5nzUmvhec/H8R37xczAcVxW8Dn66DjpKbDGHVdnDz4QRjKdt1qlvPKrR3H5TmtX Qe/dmw655XGJ+DVPsEnuxFihmjilX7pID8AnbeifYo6/CSgyp9LMy4J97r4mpZhNxHrzBeRegNBs r/7778Lm4GTKIsaxBDZOiAz4YmpIQwqNgJLA6pKdjRy0TZD4LZb4raD5D6gKjmL5gjzwR+Jajwzn TcjnsGjn5XcDroYGkIS4oILjoNAPJSwMZQo4r/DYbeRdRfgMoPBNo1RY48z0ZDZXb7BEAGZXRoL8 A8EEkKg+QtRSzqxssJifbucFjXUFzk64sGDw7vsH0GpD75rwb6DcL6UHrxUH5Da9ZiLQ6MItBYo1 A4Y+CcQ8A/x97oEDwribSbkDZxh04woOTYT/Q5ZRjfwMrzBCURyL0NxqAzB0o3rFx05JIvIvovDq zpQFwM5FhfgKQKhE0S8TMKJ8arrDLDAlR24jy4grT5DdLv4zZhLDBMsQrbwihAwjL6cO0IESSp64 ojwIopJkgnoOjYx17ui0bu4lrZg/zvb6UOsP8O7bMG7mkPUHT6JMTcbnkc0IAjsUxPiLx07eLWY5 cJhYrezqxH7fLjjfjfz14OkLSLgHKS7oYrqEYs7gMga8pto8zh7tbiJSbtriri47gEDjUgsA5PAH D4RPkkBBxY7jzkD3rkSDzkkb6ZT4kcT40dwI0cr5TwEPMHKasHcPseD5SEDQ6L4qr1Amro7uAwrp T1bpxT0fDeZaEgwzpxaEZXolMhgmsfwnpaJLRRAvIMkbBjY4oPJHaN4IgKYGAFg/ySrxgzCL4Gst Me7qQN4M4vhIR1YvJIiHAo5TzzTsbjY+cs0BCLhOjxwrkIjADs4NbtJzB+0K5Srt4wjuUlEbsFsl kEUcJgkccmMmcYsGyUEdUm6wknMmMP0ngrkL8SZ0i1DyTpoo7ypKUCQnsppqJqcaZrI7hHxID/S+ q8MjqpMlKlr4Elkyhz8yxO8GUaEmsdL5zwkdkPk0Enbc52YHDRLoYGE6K4sC8AL8RaINKkxVb849 cpohLdcn88KVI7b9ZTZUw+kKca4N8bKOT/svqSy4hbwG0BoFE60DMNY8BlUB4707UosCZeoMM+CL h28EIzpMpP4ms+8AQ/wsiXcSAzskD4SE4NwvU1ZN8E8UAqzM0Uc3zdk4DZ0mE4cmU5rn040zc5EP bw80M5zdL7SsdF508fYEEKkKxtsM4NMNJKs/MNr38YbQFE0YzKM6EDczoqLE7FIhNB7JrNqOTFDH jQ1JTMzkrDDPlJzQjOMdVJbMNKwkZALKJXzKdKQ27KznNLjRjLcDtLTM1JlM7MaiNB9NY27NSldJ okbO9LNMbOlO1J4ED7VOtLiEpDLQbIzONP7NlQLajMVJzLTR1Q5AlRIj1RdO7SgrFR7QNRTJ1JzT QgoEAlEXorIBs5MbhbMZ1Fj6qhqEKiFVTUq+QMrKIh8r45Q/zW7JiAhh8egmEVC4rKLYETD/MKNA ECoJg70Jr1sh47oOTCzILDUy5GEYlIJn8Y9IkZROVUsd75NFpBMqEL0qYFDKMa0rc9krpeZeoJgt 4/xxCwzaCLgmMLsyY6QMINr91JAhqAIhbcNLlPldTF1e6sVKjPdQjQtPxaysVNrHNK6l7KVfwhtM tfNhAkdRsDthlPdN1RlODM1ilOlRFiABtPCDlilg9SdPtdVMLJpnTIhxkkDONkVTTHdTwqyDlltl NKFmDONgFLrItgdkth7BZwtgTONldmVfVi1L1hVMNoQrFh1nNiQhtnjOllFN9NNp1mLMDG9orlVj A29pJGEXljlkdj4rFp9k9n7SbPFsVqtitjtsNm1odq9jogINCmVuZHN0cmVhbQ0KZW5kb2JqDQo4 IDAgb2JqDQozNjU4DQplbmRvYmoNCjQgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0KL1BhcmVudCA1 IDAgUg0KL1Jlc291cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCi9GMSA5IDAgUiANCj4+ DQovUHJvY1NldCAyIDAgUg0KPj4NCi9Db250ZW50cyA3IDAgUg0KPj4NCmVuZG9iag0KMTEgMCBv YmoNCjw8DQovTGVuZ3RoIDEyIDAgUg0KL0ZpbHRlciAvTFpXRGVjb2RlIA0KPj4NCnN0cmVhbQ0K gBCKgNHIwEA3GA4Fw3GQgEBUIgNg0TEByM4gBovI0GGIxFwwGkOKhmBotGAuGI1HENh5jEEGh53E AoN5mFMPNUSEAtGIzF0siE7k4xGgyG0ilwoOhlORtNJuMJ0NJvNwvMpum5UnJUFVCj45Go5pEvn8 psUxmZkOBvp50OYsEBhNxkrNbrsmj43Gg3scwKkyFBhOZzN5jNNRp5nuoNrlekAzoFJOBhORhNpl pZyOeLxt4GI2G98ltkGQ40MiwB3NJ0NAg1hlNouxehFw1ho2o8PImOG42Gd91EzFuLn1Hv27jQxE Edj8hh8kv0u5gzGYws9/mYgxdEF0h44gjUcj0gkUkvEJG3K0cnGQw9PBFBzMuTytL11Mp1QqVUEB 3NCrhA1cAjmuI3BAKQqCgxaDJ4nygN2873OcKiXL8wC1jkOjFp4HCdp6n6RQgk4YN637RhQ4acAa 4qXxC8AjOU5jyOenTRum6rrsA7UVO470XPC5bxwm80RhwGLRQo0gYSO+D5PoqIyvupqnsQ/g6vkM gQDMN45BANAwjSOQ4KeFkFw9B0XPO6jrwqlAahnHKZy3LogioJsNhjDsGxA3TeN84C0RQ4gXONH8 YSC5ryxrJMbus+Edq0BsexbPsgRlIaSqGGaVL6n4a05QK5DzKT8yrAw2jDUcvjtKK5TNPcHscGwc TYsk81o+Ai1YNy3CIMo5jGOQ0jgOkuLgxcjJQhrvvO3D1SSoYcPfQIpjSM6oDYOdfWBYViS4ncN2 SGKG1hNKhhkHLItIGl0vgNA3juMtWDkuDX1GykojcN46BANwyjHX45soNI2VHK4yjMOo2VfD9YvO HCE069uI0C/i5QPBNSSo/Y3NlHgcIVkAQXS7tzLzP71vhFNIxY77k0RGaR0W6SPOpR1A0gnNJ5cj eYUwzwa3ZiS9TiFF9BBJzKSgECrrUtleP6/8DPkMaqLpFUGYbk0SZjNoYoLCbAaata2wHAuMCgEE MQ1FUOTPPigvPEtAOxQUVZbQ0YyFRTo0Rm2i5zSQaZLnjxUTGjzhzkT1rLxe66S+so7Hp9+LWwY0 jENkoznhk0T684aBrJGvBt0V3TBMUyS1b86zvFQioGHCQhvr6fw6k6GLJ3I5c2BvZIP2rS91ZaFo b3ktd9wfc9oHPbIOGwXdv4qK96z6PNt4Hm+F3Hid36obBkn/Z+DDr2+g73p+OkgZ1nQnx+16Xc+5 6nkfZ5v2ez51bpQ43096p8G5tSGvMec/N+b6gGwAgE/l7b04Du9d+ek4r8SGgxBgDVQj9CSPWgXB JQkFDlwXgzAh9hCgbEhg8rN4cIYMFHgRAp7EKYQQWhbBoBpAiCEGBsDB8KEyIsvgsR9DqNG+gtfC xAGRQEdJmOORlnql1FJqTe3QwASTBh1DKT5zrcERJuNA0OL6gQkFyDIGwxIICamcLuUOC6tULEzL aUxbEajeNfLGCh3hhA6hyYAZtFRtHsJwgypVQ8QWKMyiLEeHkSjsxMRDE5wzMUiFfBnENaBZZKnw J8CAM4cg3h1TGG4i8cQ5LYepHqPiv0AoGDCCBqqvAyh4bYpFrLnm4ojbmylQLKyct4kI3pw8iCxq NcAdtwaPpCSRZ/LgGSJpLtfmafBi8pJTR5k/KmVzFwxJRDo7xKCWTBFxi2w5IrKJLvmmcYAzKpWO FwDKC4M4LgQBETsEY1xVEohnKuUwqKxo6GeSWbmc4MjPnwW+gIMc2lWsaP0VNAxT0Cr7P+l0JoR5 /pFKIxJJbYThNMnhPJi8sQ4RmMMvwJIVgpNIKYvNeqX1+UJQNNui5KD3A1YkUamygaRUkNWwUEDB 0shiXugaioQ08J6a05+XE5kKsqUGoWX7Pm+TDZqjhR8xnCKGmVFEoYNKmGkNxOkmcrZXlLlkCCbb VTLoErIVQMxTCrsArQsIMk+pxsmgtJlxkSa9N1mtHuuQLUA0vYuqtKNZZYyzLsV6CyE02xJo4ChJ 5lzMoENYVGlS/F3kyDCHUMhU40JdDsGkMgZQ30zXGStiQNLVKBDTZYN9aEolODwGUMk8lfBms6Gx flry42etAVRgtqAauljBTluttIzhirpPonZcQ2Bst/Z+2NtLbT3n0a8OVR23zkZPM6psu6nqUKDE BvcRKqAub/VdHkx7yHIifedmRnmvujNInBJBgK2ywrPTBLwYVWJak8G05c9wQKoDcHmu9Sk3AwvA aQhFYilH4Y3Q5AlgozFOt6gQNIbXLXXqEa4/9M0lgyvtG8FFFTtsgeih1I5HqBXwRikWqZo4jPRk XeyWl75IVScQppm85wa5BMBJuTsnw4XXohSEubZFeYLlvd+Khwrxs8mBJJmbfqrM4qxMi8t8ZgyT OsSliRHbkX6ivWvEVmAyhhDGa1ybZUv1sszlCLsF08qdxfJYwBNQQAir/KkOYIs129sI1OUDa2PK RM6UNoNyLHl6zOTMKgaLfW+tKGYp+IFRmvNcHnJMaAzYiDLiRdMbiyroPhnFqAXAUBECmDAuBcgw hsDeGdMqKtGkoBmR1iQNdfKBlfW93gbmABcPaDULhN4yVo06f9tWbg1hhn1H7Rka4hAysckrbR8L L6GaRolLhbgQaunfPFAq+g67GNgVcOmudrmOBhkG8Lj1grDDpsvRZOW3LlwYiSr7dmWQZytj6YSN qq5Ekbe2rMyeDSTKJX2x5vs+EzDOlAO6qUCKoVGU8MYbLPJRs+GbYm7s7WMJ7pC+6m9vaglVn7Vh bp3UfbPTsNNJdTTRr2uPCVJ6UnyDlSzQs2aYuSDxSPm9PcFa62we492emIUCMBUDZzZ6i77Aa7B5 IID0vhBy/1+T/nkOyen10F3X3nvRhXAiDkMVx9n7A914z33w7d7N2h8zhOxPrfbCfrnb+0QG72is Gz9yj93KO/ugsD3kQwNv4DuPa4IEhKKQrxb008uDQ72w9MC/Kv8hX5ntUJO++UNL6B+fovNv/dF5 70/l3c+qhtDggoIAaGfxbI+IGNL0Y2kVEnHROSKG6x7FDH5H1N4PxRFYOcWHB8naBGGc5vb8kzjG XOM0otRXEinLpx61lsfZMVH+AL2CjMlqjIaSx0Cx43iRIwFDgfhkQ+LfLiBPWJHUPg4MEC1Vrtav xPoKlvlKnG7uCG8uHsspiPgnBOGsvqtvjkSPbs9AcwJlAgoCmNogxg1jMGkPwQAIzvms3i4kCAou ztekBwBNeILtfwWKdOjqeA6KfJPl+M/FgA3ski4HeIzOXisOmLGHZQCFAgRDFnBjIL3rGMHJLLHp muKj4lrJui5NCE5wPP/roozjFgcoAgaMvM7vbqBN6jAAxNpEvmFOsCeHajerumtpckkuBJewDv0v 7QFOEpiuGQukXwIL5tHAZOVD2CGNJgUAglsNbkCksghgggpwqvwozkvvsLbQVCOtuq9jILIjWJPA 6gzs4FdnKtpNqFfwzs8t/MouAQhG6peEVw4svsrlMG+wFsuQ7wkFLQ5jPFNsTlPHTFAxBtOsKKGj +L/LDJxGsQ1sGK8lnwmQUFqQPlsltt7lvEuozA5ipPtNPA5xlrLMRwfjPAaElmJIdlnp1RelTGzK RF/ilkslimmMNOsH9mRIaJBxVoQohMakkv3McxYMdomxZswlMiUP8RKMJP+P/RGJRQVRSspw3xUq oR4vjODlGQ6wGGdqtQEm5H8HGGvyLG6wMEujJwNwOxrQrPxNwwRpwwTActexIsTNtj2C9rIrfObK SwZg6watRwbwcnqQeECCqLUQgyEQiEVQjFlq8QlKbq+jASQQog3QplvyQSCCLwswtw8HQKCvvQxQ yLdxQw0ijxRs7w2ikxUJfSGQ5xXSIR8GdL3HCyKQ+Q/CfxAD4RBtaxCtmxERFSmwQPtRHIyxIRhy uOURJpzxKtvA0RMRNGmROQNNptqxQqkJbSuqvsUSwRVMZQEyyL1Mtm6nAyJOHSGuIPpLHjTS3sEm mMmnKOiLZJOA0ldxFtatrPhRiMoiiEjRvTZFAtPOYxyOjxzLrx0jYDVp5NXApgdMSSvLyDANljFu tHfiiyooVvGCSOyHczljunZnoIQPOHriGzpQuTmvBjPu6vTTmO8n0HvH6vSvbMTTpzuTyO+PDTzz mPFPIoXvWnsTtTxu5IbHfjqoTT7EgmQobO2iGz9H3PQk8vRneoS0B0BO/PU0CvVvGz50AiE0B0GT /IEPaCDF0IAyMofpCveSHCXR7PgSzCdR9MwMsIpRTIqorgyoMSDCjRbiiPpDAAptxEMvtxtERsHQ wTiiZluN8TWgGpACGvzofEXsZx5vex6vfv4P5MeR9ssER0dsUUWy+KkxSTiSEywzJzOQ6TLOFP4s uxZUTJlqaAcPlCfjSsJApxnF+GzDBSmzdrYsmGnGykrjExIjTq9wtTBEojtoMHflmI2IVK9ijQnF dN3FtFf02KDpWEDAggyEskuE8U/iQy+jPUpD4Amg3uRullIt+0rTHMH0szJUjTKL0r10RzNQHy1C 8ncyLwtP4VDleVE0fRnroNbA7kCQqQxxrAxyUunq9xuOpUe02IzrdDDIzA6FRg4JPLRrPvtLPgzj VrUCiF1D2AZiippAxgxg6g2mFRxtXVokBFUA4NlxDHqAzHNA8SeActUEcGis3GONyiaF/AQHNFWL pOYA2pt1IDEt9LuVLQByETIyF0tyx1TzLolxYy00uPoxjsIFpm6giFrDVgmgwg4GzLSnNRzuqj5C 5ozgyF4JWQVNtR/pLn2WTDAF/CZJ8JVtSHAnSoCmtmg2Hihi9RwCZ2J1pA6WLWMRmlulirtm22Yn hWAiPlnSENXGqg5HeAxg6Afzjm2xRVQE/VRWCUxRWR6GaUvQ7FI1VL4Q9OIM8KbtgD4WdWK2LkCL /Jtm1Qdg3gwrSgyNZi5tSQfMd2jCiFQJznSwnA1Erl+HeOSt2EsqINPQsifH8VAohESSEVZFe1FW gVJWpDpyt2qG5OA2ruC0uTK1UTMUw2GRaERyT1rJMP4Wz2eW0i4g4KRtOrYtPJ1sKj+XJW73LFzw 1Vg3bnHwOs/XYRfA3RsNS0cJKUpJMVhtX2KXUA4Wft8KDkCWPQakDNXA0tRjXtTAby2KCXrtvRxV 5LfNPApAngngqKWkAEBWLukFfsVmQnyjmFYvd0kUPid0lwGP50OWwiJWjyEUqXaTG2qo73MwEXN2 EUvzMy0SJ2Go2C9qb4FFqU2CHLfU3vwU4uazSC2yUzQVg4MG607PtDFvzvFyh08loD4AnF93publ TApAyg4osRpENwuPQWjSDkT4AQ5R+XOWEuF2vYDTN3QivlpMy4gFA4SipNNKE15YVYWFfl+A5g8l eAwg8Vbl4UgJaouDHQKyViyztlA1djBObmkVivtVjmCDV1l1mrSU73hCOnHLHpKwnVxF+M3VuVvA 2VwAUY4MD2L1zIyLUFZwljSGQQnXA11C42nKHV52W17gy18ibXhD2yqYRqdV9rbVngz1/2pTGYrX 3pDv2PfMcURXPHXnYiQjqoAl2vBT1nknp5SuzoBzqvJHkUAAQZWZToHTunwHxZZkSZWgQTxZYO+T 95dZTT7znPCT25aIKsWPYO50Hvy0I5hz1ZmTniQ0zIFn5rIGSoEHfiVu1ZUZpOt5uIQZizoCG5wu 0zrHvzsAQZqnsZrttZs50oF5zZvT/5cNu5zZfZi0EO/Z2T75sCQvSZg555bZUn7L1Cj5zT4ZfoE0 IZ1ifZ2np5/obPHZ1oj5o6J6G6Buw5UiAg0KZW5kc3RyZWFtDQplbmRvYmoNCjEyIDAgb2JqDQo0 MzAwDQplbmRvYmoNCjEwIDAgb2JqDQo8PA0KL1R5cGUgL1BhZ2UNCi9QYXJlbnQgNSAwIFINCi9S ZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAwIFIgDQovRjEgOSAwIFIgDQo+Pg0KL1Byb2NT ZXQgMiAwIFINCj4+DQovQ29udGVudHMgMTEgMCBSDQo+Pg0KZW5kb2JqDQoxNCAwIG9iag0KPDwN Ci9MZW5ndGggMTUgMCBSDQovRmlsdGVyIC9MWldEZWNvZGUgDQo+Pg0Kc3RyZWFtDQqAEIqA0Yjg ai4ajIQDcYDgXDeFCAqEQGjAQRaLHIziAGi8jRYYjEXDAaCCJGYGi0YC4YjIZDiTFQxxcXDIaS+Y ncQCg6G8QHQ0GUQGU3HQ0nKhE0jlwUimJGoGkWBjiSjcYjmazCVxCaVykCCUVSF1es12FVuFV+wj SHwqrVicDcbC6tW0QWqCDaRQmx3C61y0XehSgYjYZTWq2ScDIYXOS4G8DMbQ4bYm/WbMZEbVjJX2 ywWHYXM4MGjUajeEW7FX+z3a8abUXy32XA5DSWKGXOG5gYjOa4KwXm927GyPWCDe7/NZSq8Xd4Hk 2nSbDUwvncfo8CUQIGjmLZu2TCJRSPDHkSvdyeKzGZi3DjgYS6czsQU4qVCMTHyR/kSKSJilCVJG GYahm9iLvmFAkjmOY6jKub7PwEAWuy8cJpWGIaJvA6VhkyqIionQUCQMI3DINg0jcjYyDSMI2QiB oqBVC6RwK8yJJmiyJREOA2RKOcYBu2KFQ8FySws8rzuNAD1xxCb3vjEERPqp71x0iaOv4kKRyOKk AvQt8OJYHKrwSuYiRaNgQR7EoQDSOYQDCn48jgoQ3jMEA5jGOQ0jgOgWBAMQ6jpN04DREsTjKMkY ItCjfRAIkaBiGobBtMQZLlS0dp2Mo8R6NIxjSOg2DzNw3J+oMqPuBqGSXK9IwEGAahpG6ZQRTYUT QM9RCaMI4CIMs9T5Pw3jlGDermmEKomEEkhi9DxS9JtbPcukowTVUJVfLKQP9LsvpGiFaxzMYZVr EUzjTXdCDbXwQCIHVCziwQzjrHw5KHTykQYNI3jcF1GQnZdYTAHEDSdDAc4NBIuBQItPRRUNCKQM w6jnFyfp9iyhTkEUWYxNg3BFGEZRoGAbr5hEx5TEKdjcN46DCo1/UBFl1hBdo4XkNWLUJOSkXre+ SRnWMyRBHME06OF9jnft/qZGCpAa3FZBczratc262K4hiDs6uS6NG4LCuG62vUtrCvNIwrDpts2r UsxjHbElDJOZt+rrs2zgskzlLa7uDkBw0O0ay4LqNlqu8sBwy1hAGyEoRwqucimC8bI6vIMPSjMc q7QG7sFzK8fyPOMDzzXtPzPS8mhXUNI7jvcfWiyvHLLzWfJb1Su9soPlXFsys/VuP7LkmVjAmD1t K8RQXBoytRgNHN/C0BMLhcnBQId/DMMqkDcMYy6HSQZhzo6djHf3wz9IMhhBIsu0jZ1oSZ3kn2t3 +WhR4L89sjy3XjHqViDUHD50MA3gKgk1AIHtlFU6HR6TA1JA0LEypD0FX9AtBAEEED6Q3Pde++Fe QbwxMxRSopQKpQwhkRYipPIZQ7PeRc+N6xJHlLkJcDR5SIg6PeDailmTTk4E9XnB6HoeA6AuBAE4 nzSmIqihpAcG4OVLg5imgmD0ICiQig8+tQibwQBuDKopRTAEqtyLoTB8roj9LNCM7h+ju0DrVPg/ lKbAVtv/eKf+ASGAZwGJqyxEUCyiBkDgG9FMEEqqNgk9ZAsVILA3fKgmDUHIsvei2UKMEJITRiDJ CmKJLAamNUublBMPQ5Q/DdEGFwc4YQyTVB6MQY2ZhuTgv5VD4kqsletBSQEF0pE7YuG0oUhZDyJj Mqtkr83dLSftHRa7wI8PDj0luPi0lYwFWjDg+K0URMNYep9iRgmKsXTVERjacVTxOVBFCRbAlHxt aLNsmi5pvPofUGVPyppcggKUoAOZPgwpwZeoSIiewysyl1MpoiYAarjJoVeh6CXusyDqV+RMMpaN OBc1BKrUixOQJEWJtJ0jglULtSIuhVVkt0OE6ukZj29ONLy20ktKixRopk2pvhk3RU3ofSszDe26 mbcDTgkpoCWOtc+4ghVSKh00LEaYrCGjMPmSM59zBfKqJGp2QqrBJTl0/BBV2qxgaw1NdVVwGtVa vggrSXh2JFlZuEmpG9JR6ZnRzd9MF/c03/JaW88c9AMwbpdXIpOw6CXnIOIdAxFyL53vTUg+R8yH IsT5fYlVIR1YJTMr0SiZ9fVsWASxNWwcfSRsnhvRFTEOyd2PCHZGCM8XqpgBta15hOwWowN82iNq zrU17SclsGYMwYSQf08FDNWVXxugBNdcB8bdEsh0gljqx6bK3WY0UG6lwY3fVxEaB4SQiAin4E0M oZwwvpQmm5nyDA3qhoUkBKqFLt2UnkehSqmnlksBwpW7AbJzw+iBLVOCKQQTpDMsVeYcAwhyKMGN e2EbavUu7H4vSl1KLnJ2CIMdkb0YNXxe19IdSiopI2ogEAbA3hnV2iqULJwZXKsS+a5SPKLyHlcH NQGJDBUBovCJiwYQzp2VOUApIR5klQl4egGjkExGFykrgKgaIwRgWDK7FNkYVKnwiGJUQcsIqlZi GcFkoSWsshwDSQRO2lhvDsGkMkKAxZmVSUrJpKSCzwwwwRcNubMK4t6lW393H5V4mst9aZM7jXIx yfRY5bDH3BsFAGbCGIdY2nrbnSKCk8ZKn8EcIcYYxhkTgm2QoLSegtkKCDEFkdCqrkZbbDJLFMA1 UuDRlCCc6AiUAqIEAdw3r2k/QihQIF/SaDpK4NieMgaixDgTNWbJ6lc0JP0pQIAyBvWDGFmGpoUK iz2hQmF+rb6Bt1JS30bLn3C0xaJA+j7k2lSrc3SqSNL3SJShgGTnILZuv882L6cMeNNDEGwoURCk BtzkxzAhP8DSrwRheyr1rX67klRQOQbw2xFX9Eegyh1CBiDLi6F0RE5K7hiG7GcBdOW7BReSJF5s 91KcGciAlWd9RwmbvJJ00I7aSnfHnfejFY2synxlXFsraWTkbbjdehN23A57HvRj9t6afuZpTRF0 OsWEJYQ2iCHSX4eBRBzWOBAW6/XlQOgN9IeyfJ7xa/ZLLkS/lHX6WQZaNr+ThkDE2xcUwuURmokM vwZktQTi7GGKk147Dfj2JWV8spwy2UQo2XsZmGkAQXoYKE25hzHmUn+RlAZxznnWT+d5cvjygpjQ b+ilBD3Ln3dGt2T6CezrMqGh936KuH0BW3W97Kr3x1+1G8d+64sXwH57+gk8FTX5PhHCmM7c5OGW HqcdqdQ1toBSa5pS/kvGv6WeCFUMyUDydfxG+VAg5YUTGZ3uYxY1lnTPdICSmmIccZAApMLWLs/8 LsbAOOcuL0OrALACpcbYMQrK52K4p0pcdCdHAYNbAaM0b9Ai/+IUqUNEqINKrWddAlAzBOc+LEBm BwNQ8YOgKsjZASbLBXBbBQvCJEUsrGdHBo1wN5BhByOnBIBBB5BcLtBvBidgIGdksMIOgwP258tC 0afujqr8f40QeI0W7EBgeS9meaQYQcKw7s3S/GvEVse0/Q784ql2oaJGBygovBDeVwoyDklWnOoE 5dDWZMJbDKaQVwKUfaOqjWv80TCgWi+Id6fxCqtMP2ui6yJGv9D6f1DC/Az+ZMLktaBQ98dA3c0s dw+HCk+Mmk3u68+DEa7E8TEgnqj+4GJ2yuKEga5EXk8yy6wIhU/k46DqDg8gTvDE1uN6QIw5GAVw lQlUiC8An4RgBsNQMm6+Vi/GymQIr8Ta22KA/YwioWKgBbGUdE3O6i1wra13HAVwxBDQloUUxGwc Y62mDYBE5ucGjTCGKxEGjdEKfqr5ES+OW0rvFMd3EfC6J3Em1oz8sqtBENCk6FEU6LH27CtU8Y4C sYgdDoYw767+lsg6Ta5MKGDmZi4STeKCDIzTEo4uWgLkUu92aSBcDOiUyAUOKPF0VODg8k8ogZHL DUoYfITKgsoe0+xCVPIyC41y25Fy4UDw2UXwYq4iDJKGU6BAYa4czqxmQKsQu4R4wiDCmIlQo8VW /5CGwCucpmp5AGK5BWbnAPAdAUL5LJK/A0bWMNAhLUJLApBFAsJLLgqjLCdAqMM7LtBAqYdSfdLs pLBTLqMZLWqfCAbHLQIUj+JWrewFB1MJMaMxMfCDMBMLMdMQO3CUIs0hB6sDHqjk6CtJFFIE6NH4 0yQG3qYQsZC+DKdzF6/EITD4J2ga/SiE5fIcv+MZNyREgee9Dq+zD+s4fcfhE6rzIMtHHxNJH0sD NOXAJaj+13OiVwdyIkVTN9IkljJqacB1NhEs94eW3Y0NE46vCzNC+KJEuPNUuW0muc0tOc+aQzNy hwL0r8zqoKzszwKEwgKOBACYvmYwxYCkDK4ch7O8Vic0ymINPsWCT2T6J6DkwSySVSV8ziaWRbQN DyesJa7KlO4nGMX+Rg3NIG7u93ExE0+BONPMuJPQas0hHyIJFJPfIZNQuSr0hwWenuBQChKtKwe8 TgzqDMhOk+wUCmCICgXihWDIaZJDIE9y0AZO+ixu+iR4WK2aUARcDOWKVEDQDax8KGfADkTolqUA WO8WNo7uUmUnH+BQDi8nREQyMvSfO/RO6q+U+E+Y61PTRfOXRjPc31Pgl7TWgsL010ysKClc1hIo wQvRGuxbQBFrQOQwtzKmQ6YMS7N6DaDEDeRY3GzA4klSwOac2HS4wUDC5eSFTY5oiSWPHe5yWeIP HnILHtNFOVPZIVObRpOefzEiREdzNrDSadUk3UQPEzTs+DE9Ty3nT3PWjvFHT+WY+W34aKByuqXN WqQSYelROBUWiETiK+KQy9Ka1zWGWRWsUotg5nO28AUADkxQDc8gDM464+RKzUZPUNN1KCVwmMkQ KK2UUGYyDuwi1QXmjEDo2IDkDWz2yelEBlWsIhXSoSDGDQ1G+1SEjEwS2aMEfCDSzmxlQ0QxOgUu j/XSwgzJR9QjSwRMXkRSxImIk+Tu9fZARq3+ymIhXwREZgKCXw23ZNKu+5R+9vG6/DTpTZRRPJWj Tw35T1RdWa6I+RRlUBV0+bRsnoQ7RyQTR5ZPaBQjYtSGn5SNSQTihZSZWHSjUqTHSozhStS/SzS2 KBS8UAi3TET8o5ThaHEqVjEvaNWPRVE/aZPU65Pa3zaTUCQwlHXwhwa6QTWBIq1SK+xdHWVKzo80 DTSFPzbMQLasJYklR0TkzElXTETcDI/2KnLqLJGZMELwpRLHdQJhLNBEq3MXddLvAEprLfdpLkpp LpCHdpdUNIb6cC8XHkWVHfBCpoqdd7eJdrMGOQsOSMOwzcOVLabKvC0peiIPdtd5etegN5eldteT e5DeOhe+c+rmOQtyz+dvOPVoWpNHVvNLIXRWunT5PCVwsbNcJFbMyrDNR4DGDWyMWDEAL4s+0Ujj RZERCpRgf6tO6PC0BoTIymM27QS3f9gAyODmXjGSQ7cJSgkfZskmVwmGY48Cwc9qCgUAUEUIDuDS ++VXG1g5RJDGsM702wf1IzSDa+wUldZ8+6RgisN+uemysugsuSr8CkCMCG1SRMBewcCCDcjEDxgE vviAIVTmViVo5iqXJyf0iICQMQsfFcK+SCMPfHRLBoymgJDKRFUcRcoCTW46x4YwyACSChREIhe7 iuWggwm4gwRECgDQ2WMER87mTWvbguWDZUk+8EVOCkBlf3HFfsf0whf/gCz2jQ5yc9PLgPEPCmmj fhOZgbcMJYJbFSQ7FWQSS2BBgtgDgyg3ig8IfCmJX8CgR8Dye9SaQlj1EeYVQVl6VwCmCGCcBACs kQfCUAtm4iCg46DOaYIk2Wx8xmfLbQUnDcQSCICoCaCM+0h6loWKUBmxm0/kKIhlQhlyRjDYBgWe uqN7C2QSvUY+gZboT+BACkCoCHhQUDYAoKfHVnPPgTk/WdfjVzfm+aJcNEZUBmVpFYBQBE79kCeC UxB7iFcPhDN0klJ4RKfCwIe8vQDuyxYm7enWRMmOKLRFok8Zl2VkVnTZQse8DoDyajdNecN9JLd+ pOa3A+kkIeb+pbdjMVppp5eZASu2vDpqbiOKrfMhqDptLBe1L0UtqNqFL6pdfDp3qbLZpwrgLYdN AMLgq1qBDcckMwinemp6bvrFq6a5q/L+OrrSqZrLdtfOYMdrgbNBgRk89DCtNNameRPXV6J3fwJa z2s6L5WRfZn/rzIToHlFr6PQVm6mf1sHQGV3I2zIlqRhkwK1RVk5IPffoFlDEZscRquvNXOoMPso TeDpsvWEo/pnWqqFpvLErAN8Nxp8ppdkrhtqrfp+u3tgpzqTAqp8dHt/t5d3qht0qFqpBFeTuLqG a0BAPgrIOgnjdWKqKwsvtkanuuBduzqdMHq9u6LdtvLxtzukdHuprMMJqBrLu9qzvWu3vaSJuDLn uGJLvOreOzqXvluep7A5v5uXeRCFvwN5urMqOrv5u1eTwTu+LwICDQplbmRzdHJlYW0NCmVuZG9i ag0KMTUgMCBvYmoNCjQ2NjMNCmVuZG9iag0KMTMgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0KL1Bh cmVudCA1IDAgUg0KL1Jlc291cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCi9GMSA5IDAg UiANCj4+DQovUHJvY1NldCAyIDAgUg0KPj4NCi9Db250ZW50cyAxNCAwIFINCj4+DQplbmRvYmoN CjE3IDAgb2JqDQo8PA0KL0xlbmd0aCAxOCAwIFINCi9GaWx0ZXIgL0xaV0RlY29kZSANCj4+DQpz dHJlYW0NCoAQioDRyMBANxgOBcNxkIBAVCIDYNExAcjOIAaLyNBhiMRcMBpDioZgaLRhHxwORnIj GIJOMhhKpEdxAKCkZTOaTmdDkYToaTebhAbzMKYeaokIBaMRmLobDyJSpPMRyNZZLqcMarM5qTSO IDuaToaBAYTdRipSCoKqwMBiN6vBofNBRXiHaKQNxuLhrDRkNhdIahUo+NxtK4fLRQLbwDaaNpdI qjGhiII7H8FI6TictHhmM5jXBQIMaMRpgcjg41HI9IJFJJMLreMMhnJfBdqVLoRKCZRAdTmaTdF7 HvsaNr2OYbcohhNMOLjTht0LnNSmZTkdjSYzKQzRZjPvjaZTmczD4caLeQLuVSqZTslztpVttTr/ 9N1NTMcjebRA4oQK8/43v+NDfLsFihjkED9v7Aoysagylqap7mti2itvqGKUvwui7QHB8AiO0ocI VEoQL+1DBwuwzEColrmLoxijscFzIOYyYjMqy7XIekjmJay7PtC6rRtK06QxwEDVs6zDXpKk4Yhk GjqRerEpyo0Q4OwMw3jk8YyQK/g6jOskABEOYyjGOo5LEPIRQi90KPjC7kBy6MNhvO8ijYMI8uxB I5PIOo2DoOYQOEEE0zXNo6DysryjeMY0p8oA3Bc9MNzk+EVqnFq4tFGa0xrG74spJses1IEmyHPb 8yNGjTNRJUmR4zLYSiGLcxgpwZtzDyvjGsyyjcNw3jqNzuURQwQDhQU02TCEaQk98KqjFi3TwgrK yKscxzKEARJunYwjkOlEKFZw3jPZ45zhGi1ucvS4Ns0Qxv6NqzDJTEaCKgYcJCG6tKc6CToYrGD0 FBgG4Ag+BhlgqFuXiSKt8kmAYpgQc4Ig7AYjhOLAbXSPL7h2N4hhGJ5BhddBkp2A4e6CYMBJOKYU klfIUG2YZPj+VIbm7HBtjdfZNjkNoVXWU4rhYahqveS41jmDZ/piSadqCG6llGqaXoOGhsGsKZ8E AbMhoORr4huw7HpezatoWdJDtmp4pt+g6xtWy7FuuD7vkKBIIg2d2sjMdMsqcqx+q4W5cHAYBlCq 6NJabUohwzWSdH0oI+0FXRg0QkvKOoyvfOMJ045qptBekrBQKiejcOY4S8OjGr1vVq1Nw4Y8TJ9V 8aF3H8i0XKVGiiocxVFbolzUrRimvTcr1FrMIGFPs4xbGsfy0cx21vmVXIXPeLI9Z93zNU1wlDM1 4mDMrp2CzdpcwQT7P82uGEAyDKMzhBlDIgkMQdVzhhDYHNAhwDyOnd0p0woNkKq8K1BA0QQQ4BwD YdtSpQQQBMT8dgEARiehtOERcMKh1El2CgiREzMmaO7R275zbwHHOQckTV4xSHkOXVq+BJ6FwcA1 c+lcGEQjRHvBBBaDEGifwcg8/iEMI4Sg6gYnM1TvIZKqcZDV4iRYclJRw8pW0PypwQRdBIHAMkXF 0QI/J2QYQxxNDcC0MUJ4AH/di7N2qzUuJeTBFV1K1ypg1BxGcrBb5CmihOs1cq5yiIhDDBeDKwo5 RUXgWxFhh1QJFVEUh7itHeQ+hmVd8aRFXxfVkkl9Dy4yGyYEfh9wOQYodJqGUPES1JwFDGGtYwdw 2QAPCeMN0jgzFlDYGyQD1TYyzBqtx569l8L6DmCxTJ0HqJ0U9Jp7MnVSPdSXKF5zizOSlVc5N80q orvpeZMshMQyXsQnKTU74bgyQZf1I8KQVAqLETCeddh5Dgh2Wk8dTcykog0U0fUv9CVXqCS2T+OS CSwljIqvo/oaQ9QAMavGZYNEs0KZ2lUuktnaBuDLMNSgbIvl9eFN5C8QpYOWLpHWXZRAzL8VGC0h FLZrwOevNp103JPwwlZKOcZnnyRenPN6Hs4XOJSmc+6hBolBBxdITtisenZHiJ8GMNEJUxLHTLMm bBHzkJVdAt2PMcI5AtDSGSatBay0/kM9pGlQ4rvfqc+KpEppzKxSRUwjdRTNTLBmDR1r7ga2INED MFod0/KHnmGQOZ3w1sWS8CBfIbjzhlmE7Z6cDULK5iNQoGdpVXyPXuHANJ5KcFIKXNa0T3nEEod/ Ft4UNnyuVjDU19VTwbKpfc49+BNUCBPDk/x/JF11Haf4mGidXyhHFrJT5gEEaZE1kjLiDYbpLKjo 5NmutQkbWCr1b+vgLlW27VHKmwU6pWobuwSc0ENwULOTVACk6yg5KEN8GIModA7hlpOCBe6xU1Ry uraM2TTqo3ZBQvcNtm7KTURpbGuVPnsVBe3eWUF53wykr7PFWF7bAygvg5ujrYjon3jXLWW8kyxK KDLVa/dYJHrGJ+/6SilsFyCNkR1XaVwZtKSLVWq8BZ6Agx0GnHl3awpkDRRuTCuZE2myuq/JuT45 KIX2Y1fzDG50sBqjdijXWvmnb9mQyBhqW5oZC2lkrYWXZlaXnBlkEGXt7zqZBmas2bMhZyjbMefc 76BYWr5ohkM6F8Mg0g2WZmVtXae3rRudmu54YuSEGhbiF6SL8DUk50G0A2ZIQ3TpHjDNLBlqKlrQ dBs7BBqnT+rNXakZC3lkutNVtd1bqNuDgSCggBmQUwKVSIqnd7baoyVngvDvtF+HeybBxjxU6uU1 aVXuiDm6RWWP3rIlrqEMoJPA3zIku9YG9jHswngQpO7rt2soohfXm2pCbbmc2fbqpVvDJRilEqp5 22i6bftDFbBldCr12VHXg5uyuAziStOS9hSL3YosI+t3tH3nn244XTckwz+Uq3cpJSmXSdWau3Hf cob9wIXSpTFKJ05aAoUWmxNykN38nUsCALgKAkhQCmEUIYXAU2vJKpqnvCcN8EJreRUu9trRaqPe qpMp6l8Y6nxpyNaErg0ZQkUEQTlCBsBEWUOoZMZ4SwoodYRQsAG/TSmFLocuXpRtPfMpzTr7B0PI T9/UGaBT2oAUOYpXukYY6XkDhS9ZOYd6jw+cF6MRdWr9DjrMq+t1PK1O5XoOcSdvmNAh/b/X/llX CgaRuACfdnDLQKYaiuXcHkDuppy2vbrdO+udACAloWU9QE4N+O1Hk+wMdgOgYThZUOdGrFoNMXgo OF347MBoUTFOKwo76h8dAgwBgUswefmTLORzJggN+a1sDSdpR3PgUFj5T6+k656TQAUOHRAncX+P +pMmH5bdJOr8xDb9KRiXazroyFh4Q6AjpEyojZbfDZolrfaLrrDfx5K3x8LgbCDgygjxbdSoAxTq C8zjIzbibEbipkTE7zTiKp4kDryd7j4mrkLczkhSLeDlBQ5fKC7liYb2cDq2Z6zmJPDmg0Tm5Rr4 sGzniDjn7oLoboro6uMDyTKQx6DhiTzD0B0Fi9K9bfrEx86dMEiww2jFrURX4mrsbsrs4MLtLtaa KejtxYbuKBSuD2igw2TVrB4l4GiZo0Tuo/7v6sDwQMrwg8rwxETpDMJhrWg1zTLRDTZikRZgJjxr zOLUxvUSLQ7SZkTPRKbWbTw1zP5msTTWLTkT8URqrWBoa9QyETDSBpTTQBrXTVEU0TJoBkJhov5j cRhigpkWzPLU7ekXUU4ywGcXxnA6bQkYJJxrsXpuEWUZUXZg8ZpoLYQgzVovbVcC6LDZjqjZyLja JOK3rasFhC7q7pzoB0Z0oGrpBajhDxhDJ1xcZY4OQ7j8ag7rwuosyzqz7eRvRFIzK2kB5xUEsCUb 8FDabgCvcDUKqWcdjDLpkEDp7yEEbzcLbq6v8LydDyTFKwqg8bLjov8j7kAoKkyOLnrA8GiYwNgN 4O5Q4MyX4PANIMSX7u42Sw8F7vcGIFBZ8eZZSzcfb+ZBJBo/yyam0e0O8Pb58pJIp2iSZR7n8nhN kn0fQ8JMIMRR73oI7oxAco4piWUMkr5Ip/j5INKX7/wNz2D/AOUp8nY8kno3ykjGQOgNj8UABTxb SRSY5SQnyO8q5EUJ7xLpUIEKaTZV8ETD8Ekizy7Eri0FUMDzZC4HLIYl7IxV4IMvTHqDjlKAyyAP JQ6hx2qO7/Ev4pUmp66xb3C4r6Rc7lMrIIZAr4w4QsTk48irMt8roGRg6hSxC+yA0lczIoS6KJIM iAJAIN7tQMwPIFwh5AxiqDEuq8DKsm0CEkDUSkQmo80zwsBAz7KSEzDKDboMY7i/TL7C8wUd0D8K hUMicxEirysLkCsjK98MLvEsM6s+wugIMNgOgKyAx0kQw4405gqssBknCNRE5bo7CEiziORQ6fg9 JnankwYqY5R9pK5KU1UlCWxZj0UOTuZEAniOANclUvbv0OkH89Cl83MwoukqMei10KNCaB68c9kL Kvc98i7zCwEL8jc+kO8yqqUyougIoOQ/hBZe5/kODuA3xQQOhNj/s7bAq6hWJEsBQyxgS8rqSLLi Ugq3MCkjCHR7shK9EhaI8dc0zpsiSu8LDqULVHExaVEx1HsyEj0yY6UkUGUkjBMk7crkdEklpBkm EmUmkOtAkm8MknVF0qaziYMoJBg/koiiwMwosu0mw6cMlS8pjc47ctlRSrlRkvsrBA03DUz59UpI or0rc0csb5UsxdEtJL1Tst0qSgYtU6QmJsLFpXTmsuI7YsUulEiSlUMv7o0wK2VFK8VFlNThtNjy TEDfMEzyzElONHhHMjjjQhNAxiE64FEy837KEzYNkzsz4Mp+lE0rlQowYqbsCxLCAu1Y0h7xlNMK ybs9tNzqs+FMEFNaqb9a6p6mDFpPTms/TtSYgECk4Mh2j6afjA1PUkwoIOc0wgrvQGR3q+1Do30O dEAnqXdYMvlE9Wx6zU1C0KtT1eEKVZKbdGtNtG9fFHMxlfcjVa1Hwjs1C01mxV9IlI1htJLA0ONJ jANJ6O4O5Aws9dLhImShQpg0RAAM8vkzpRBQ5Y9g1TwOcRBf4kIv4hUYsWpuBjBg9rS9RrUScWDO Qv0ZFrkRsTRlrPdsNrkUMSjRMZDWVtxqsWDRUVbelrYhsVzUEZzSpktutrrNIECQpvUZhjDXBhZh qNLN7M8RzMVwpx1wcW7NQhtxo6DNxsjUsYFwxktxFARuFs1yVxxg9ssTgkNzBFA2jQEUdud1Iptz 8XlxJuEUl0hslu8VRot1VvtuLSjedzxqpDd0JvFwFy9ydtUY0WN4129yhhYgIA0KZW5kc3RyZWFt DQplbmRvYmoNCjE4IDAgb2JqDQozODAxDQplbmRvYmoNCjE2IDAgb2JqDQo8PA0KL1R5cGUgL1Bh Z2UNCi9QYXJlbnQgNSAwIFINCi9SZXNvdXJjZXMgPDwNCi9Gb250IDw8DQovRjAgNiAwIFIgDQov RjEgOSAwIFIgDQo+Pg0KL1Byb2NTZXQgMiAwIFINCj4+DQovQ29udGVudHMgMTcgMCBSDQo+Pg0K ZW5kb2JqDQoyMCAwIG9iag0KPDwNCi9MZW5ndGggMjEgMCBSDQovRmlsdGVyIC9MWldEZWNvZGUg DQo+Pg0Kc3RyZWFtDQqAEIqA0Yjgai4ajIQDcYDgXDeFCAqEQGjAQRaLHIziAGi8jRYYjEXDAaCC JGYGi0YSMcDIbSYqGOLi4ZDCXTA7iAUGcwnQyncwnkQGk5iA3nU6UYzCA5GU50c5GOnC4UxI1A0i wMcSUbjEczQcTOIWKFU0QSitwuvWCyW2zWgaQ+FV2vjKwjcbC6wyux2+CDaRQm1XW93K3GWz38ZT SuWu7CCa3mS3yy4iUDMbQ4bY3CW3KUzLA3MV/MYO2QWHDGX5+/DUajeEXPHYWx6zQ67YYK6WzP7b E2mGXmG20YjOaaDE6rA3MYcLaQri8e/ZjNVzmyzicbK4ncbGF9fh5/o9uUQIGjmLDYc3GwxKKR4Y iAYyvhyeKzCZC3FjibREqJyFAQKqKirowmD3o++SRJImCUJUkYZhgHL8IunCdCSOY5jqMrVKoqz7 ha8cDhBB8JByGsKBQIwwjSNg3jsMo5QGq4bty6DtRG+D5Po9oqJQiyJPy/b+wtAMZvvICJo7BKQp Gkr7RKwEUSDCqJQBDsVxbF8YyOi0Qxw90SPovAZxSFsjuM1cciM+MmwY+0kplJoZwjCcrJ1AUPhi uLJzWkEFyfHyUpWGIZT3CiVhkGlDzuFApxiOw0qkIY0DCNwzssOQ3jaEAmiOIYQDoN9OiOEA7xaN kuxJEUwwfPYazsmKZpdWEijONMYVIEAwhANyf1JUFRBAMdNjaOo3UknoyyOKgVTEFzVBvMsqSTAF TjoNEjxCsMvuPVsxhtadZBRM8PzTKqJhBHU3UDH8KTnOsizzAiCT5dAiXVJlAQbQdoBkGcp1lRIa YBIonDfbA00uEA4KaMY2DqMinV2EA5jLYg3DJYCz00NtVW6/18Vc5seplRKXR7AGMDpFlkYXbDED mMI25jlifKGNwzVGMKi5gs40jkOY6WZZz6BiG9ESLTwh20gtVzBdMSzJM00BdNUw3Xfc4XekU6Ql eUjz2F0+6xfUnX5Eqt0DkyaJJQMACCN2N2wntQjCNeJy2OVTDTbCjqTho3jhLkPy9Vmo0IGgc5LW b1ZSnWaDaN45KEMdLBAOuLYpYg2jFhSejSN+5DeM2iWfCQbaRaiaWjIog4jvorDDiDEUtjQpjqMQ 6DkMIxqTzg29tno39NtNDURtvj0aN/dZbigRYeMvLjmNllBcEWwhwh3tPkGeQ3zNseX5OMSSGGT/ QBecC3vJc/7POH34E7FGw79S/r1e/ThzE+k0bLKLkYIyQ+iEvK3HDsiXAuImS5GqtXXS1l+K7kqL wa+o1+zYmyQPbMm9QTIz1vIfPB9RoQUMhvDGGl0DogQBiDKHQO4ZQytyaWCAEyuiiMfgOs84paXV gyBrDw/5OmJBmYUGVjTdWLBjDqHJvpQg2BlRgGwFxJm4lCaW8U+gOU6QgOKuJlTl2WN4KNAEoZS2 +ggUqz0NBiHAuDgEvRZsOgYNOh6oZx4KIkxLiasMprEg3B0hQGxXbGQQAiDIUR3YaQxFIiNFgljR 4QRzdVEGPAeWhBlDaHMESwwwhwDC54NkewuR4ZYGKJ8jiCqLf7JRyLkw8hcBSh5ei22nrecQSNqa VIGLmas/mCEHIJKygorF9LYV7JJXwR590wF+oSBowFtihpnuuhkp9UKlSkxhbzGRa4aG/w4ahAha EXYQJ0i8TqNqMQQStcpJxuTmXayoYIf6aK4X0E6c454N0KXRlLdfIcpLtpUI1VjNEHIN5iE6CIGW J5PghuiV8750LcngPCVC8RD8cXjHxh6TajklHmMsYU896L03qk+eukcrIDTgAwIOaU3phi/FbMMQ yl5Ly8P4N8Sg5R3qbAupgYanZijGHfpuZA65k6ZGhOo1Y61R6Yl9qYeqoFOKXVVPk9paBq6lncNf T6q9QTa1dLgCAGoNC8g5q4WMGMP2xnIp4YA71Z601rOhW4kp0zM1OrNWgF1ajiV4rgA07pgq6V/r sfKwRfjzHorMwBqyPUEPhfmoJ8h+i9JEgsqqZD7UFQRmaXhtZMyvGbSKhhDSHDYAgCCGyQTk5wS2 nEV5Qsq0ABuYQGhhQZ5UAzjo/KH1v0ABlDwxcpFEylK7lRHaECi47sWiY3l0tGVnKuBw/xaiRaKs ZDmkdGtcz9prsofWyyFLMH8fO2Bwr7JlWfmYiWCr8lC0JBQ0eKYVHeBuZlRJ0V3b1sgRG1JcNtid LlXoueZD4L3LtPvBNrq8bNp6mOn7BbaFCA1trD0rs9wUBNDqGyQAcInrDWLRYMJZnZouhexqbrCr YvfZGZmEDKEiuiMQ7tS1+5AQqCSUtXl22NBmRYGwOYLJrrLupDoGQN3GMDyYkUprQmcTXbqzRDIY VMN8tcr1hEK8kRwuq4nJ92VGsYDmGliUfZZFXlpgBb8uMBy6wMVfBF4sKtbwdUDCElIL4TbLMvBm MbRsntMo0JAb4XwByMzAsxRGKFAKEsJ4Icg13Kv/DlEp656KzT3hzICuyiuCx3PuQRT8qFJb6UXI SLYl5fKvRpQj3poKzISwFayqFd2u0RiQNrwbuK7DMT5vcZ1hNC1xCyVBm9ZrVJ1cS4xPgyNNgNOF 08uVx5zNFL3BMv8GPkmHepekGJfQb0DFkvEXNzqNofr12xoA5hwv6xPdqMVNNBV2U3F+AYs6FuAa pt5Oimh0iWr5jVI2fY4v073UZoMRB52lLV7663xZ4VleezWfEjmRL0WFV9sk8WcQPZ5dmFloFdgU rMHJxUi32BAEVzsRmJMayBf5ejhtqYC5PsyXeB9tZ25HxROWD74zFwlW/be5OSGqMFD0g2HOXQsD JIdhfM6LgghihrFFrt85vaOc2EB6CXvLb3bhhLC9nRK4W6TI7HoBtOzdLcGG1mTJF2xnVsqbWtXl zy16+mfejYU5/B1QkWtl1AOLrbZoeMRKSjPJjqHUiN9qZ9kDrfcCu+Ftp4iPCo26OAxPmdhap8tx EkI0LE9AWM0DyaTRxaRWhOCuT47mERtea+Y1GmeVB4QHqkmgCFkMWGKa3gxbaKH6VlpsOooz1ZKW FxLH8krkBTDnJrlYav3yqonkqJ8r6FSDJfTMvXu033fs2DNHVj7pqKt/gsJV/6xefsVC+YWkGYOD YFpPFYs0P9P7L++WqkN+JK/qNgtq/Kpm+cIVAG/8pyOesGp6MFAU/wMMraIcryNDAfAS/7AK/lAA riMW+VAUtq40qVA6NE/FAE/7AkrY/0MSqatNBCIVAMqmNIJfBgqyNSsSNa/dAy/vBIrvAqsGsLB4 /9Bkq8RsBBBtCKPKIGscYAUI7CSUZGBxCgmiLtCgQACok+xGBkB0U6DKJ4WIkGY0aWChC6c4k8iY Ken69qeEtiBy4iTYR2sqmCSEsyvSwi5qvY6QSgPoz27mUatQQ2LW8qtmrQ9WJcxkzKdEiIDOj0YW dIt6UYYESK2EDac+1GDmBehikcQkIMi5E8UaDI3gYUDo1UtgySQeUM+UzIlYiMhRE4Bmi0RSDCDI k6Zsomu9COBtCgmTDiPnDmwa4qfMw4fsQMPc5E7yR+fjD+kpEG0u5ugSaol4gdF67wtA286E76mM 7+z+zu8EWgme0GJoBsrOSKCqYsKK4yOM3OwS0yo+miJCSKCYhMdmBMCkkwYQDKoWDmDGiYDgVE3s VEW0X+IeJe7etmBgvJCqvIQAZ4KehOWUV2DokSkWJ8KKm6yOxIDcoi1HEIyUoKVmcUSLIchMhQ2g b4WwkG6sYzFGj+RIyOc0bCBqOM/w30JGnJFZIa3w7bJmL0JLIOh0Pm02USQiw5DQZmKKpGCC6iho U6DekODMDyinHOKdI8VcX/KGMYe9HlHoDYoej+U0kEWEcCUiYkBAkOYckARgeGyOdND6rawIw6CO zWJS7c0xGizkga3HGsmZGwz06G4+6KgzF60A6Sxoh7EMSLK/EYiWn4uSV5ErEuuQDIxtKsUIOa8K fPHISKcyt3KdKgDyyMDKBcDOimcsbkYsoCVCRjEsn3I7FQTHFAvkcW80Z0b2DqBaeqJycmV3NyDC JzM6YWbCIabGL3JsIa35GYQBHmctK8dEd2DeVS7bOIBo2m49FS7i5OBQiIoY+K3Cq0e4OLDgvGR7 DofLDtGI5BGOva8DGUg5OUJ1GdDzKAVct9Co1oNU7oBBKpHSXMYGfyVccVJA51OZHrHuckocogYv NelmQiqLPoR43SuA7jCuJ0UeQyuRH3H6DTH+onLZJJIgJ9MsWgJJPuZOrRJHImiZIqYnIw8nQUv4 blRBJMkbNgWgBqdShALw96J1IwcuhjFEDfFJJeZhJiT0OvK3HaaMi2dWi6nOBQxOMQguLrQAPocV HetIPUo+QBKOkyZwaah8O9QgJGBk5TLiCGKaWUBeTQJExlSVHAuu93TiUaCbKeDTKjK/I4onKnHQ W0t8si4hJs8PRMJoNdQqBRQLOdI3QWomCfQ6hVLGU1LK1cRBLunGyWnLUxFCaBUZLW6qZ8U9Loji 4lGAsvGG3AfWs7PZGSmaMzHENQ3+XI1y1M4ygLOM64JtEOfOjuCLJZSEj/MWDTEad44WiUDkKaj+ DY4cgGJc43UCzeIbMypdM4+I6rNScxN9N2b2DDWypUK1AEr9AaqG/pXC/++0poLGBnXLAY/ZAxCR XLCU+3XA+lBG/ZBdXmp1A4+0/ONLXU+k/VPyqHCFXe+lXjYHX9XyrHBKLSJrTaOImeOlAu+qIVYa 21AnYhX3BOqRYcPFYxCDB3Y3YsrZY8sZCYJAPQqAZCSXPIfGvNVPDxVS5DVWtARLD8XQQBECDKUN Lo5tOucTESuBF2juYxMYiZEeumzAh0t80HEpNZMkv7E0DdE5NpE+81SDFJFMje1ezDRvJnLizODO 1IlCUvFyvAfw7vDkvJPM4tDu4wvXVVD2stGXZuJ1Z3RHQpO07q57bRPbGC6DL/G1ME3HMLD4X9a9 MRcOkoighjFLQ1H9IAynKWY1N5TrNAJMng5ofXTGPmK8xnc6UaCJWEb6Cak7cdQ5cgWEiGiKYokO VuaHRsJChEuBFjVieCDhDEYqcGhPO4jVSklCyk7VcWj+jUJ7Ei5zUK5UUaDmm8w+Y0hZLOhbQW9o 3bRmWVO9a2dOrO2XJHRiDnLozahzVJbVb9POvRPSQ+40e4oQ48SNbfZlbjPdaYUaJrZ5We8szi2v L06PL426a5cBVQXrG4g1cJG+QkVqh6ravoYOkAiIcs1HHuDiQ2ylNtJUbCIKIRGoh0yaSLSBJbde lmJCIdRxfstm06nKBow5cwBACJC7gpdajPdtdw3eYvTuDTKrGfZ8Wg/rUIh9CmSLd+KTeCRheG1O YreYDZecMQYkJ8d9RraSalKyK8w5eohLRDene7e/Ls2pfFPLfJbZfOXo+OJKJqJWe5XjXRYpITWd XYqHXdjJWdXiNVA/jHjUe5XqqHXuqRjLXE+ZX4JfjfPCq1YC+ZYHkBj5YWJKPnArAbDereL9XdkV OKLbkbAtBbY1kjOrkmMXkqJRYHkxkZk2sGsaIsoOtkAbfbDzbhgIQdD6vjPgBRZzbthwxgUIBxSw w7TtKit3bKMFfDF84m71GFPRgBGMSVZmveizSY37mUQBZ3M/TvWWXpfTVug1ZY6BfK4u6JlTfflW IrbnmBmaJEgvYLUFF3RMaVlyDzTzUYdEaa+lKBi5ZaSpi/gBjER2NhHZX0sHjRnvIKIXYK+Zkg7j n9jiBtjnn63Pjvj7kvoHnzYVYzBpoQJfYBByNvZAPnnwsTXGJLlsqwM/Wbk4+aBAP4r5jPo4JWtN pMMNpItNjZoDYnpGa6sTpBAdphpZB9XboMqLpu+86NoWOrpjo8MNpor1qBp5Xjj9pHpRkTkForCM O9o6rFYo+/B1CPqPn1qrqhqXXMsGICANCmVuZHN0cmVhbQ0KZW5kb2JqDQoyMSAwIG9iag0KNDM5 OA0KZW5kb2JqDQoxOSAwIG9iag0KPDwNCi9UeXBlIC9QYWdlDQovUGFyZW50IDUgMCBSDQovUmVz b3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYgMCBSIA0KL0YxIDkgMCBSIA0KPj4NCi9Qcm9jU2V0 IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDIwIDAgUg0KPj4NCmVuZG9iag0KMjMgMCBvYmoNCjw8DQov TGVuZ3RoIDI0IDAgUg0KL0ZpbHRlciAvTFpXRGVjb2RlIA0KPj4NCnN0cmVhbQ0KgBCKgNHIwEA3 GA4Fw3GQgEBUIgNg0TEByM4gBovI0GGIxFwwGkOKhmBotGEfHA1kMPMYgk4yGEqkR3EAoOByN5wM pyOhpMpzEBvMwph5qiQgFoxGYuhsPIlIk9KGMrKktg0PmgoOk7NppNxhnpvNxzF5lN1EKlGKgqqA ujo5kUtFBkOBvrx0OdooxFgY4kI3GI5pg4l0LhsnhkVMogkl+g+BweFxOIhpyxeNGmGx+CGWEG42 F2EymKxgNGI2jw1huAzmizWjy2l04ypl/yGdEEw0Eh2GXBozG0KG221uSw+a2Mk4GC4GbyIxHEK0 /G0kkGo1G4u1XO3Gj3ul6/Z7esyPe5G+xw2G+C4PUGfs6um1Hahvq9muxPvFw2+PA4SQvs/b8Ia/ T+OSBrwvoEEAva0cCvigSCIMGzghcqiIo0GIQBik6EpEkirqqpDaBwGAZKaKishAvSjxDDCNw2jy QQ+ksOhmGC4JYlyZpqJI5jmOoyxOF0WIMpKlxQp6TI+HL+R0l7pqwmowjmNavIuJojhAOg3xYta2 hghEnREqKCzGrIwjgOA2DyEAwhAOY0jOr42RYG7xIaGTdpEp8Mw3DrCIfEC4xG0MTRRFUix2pyMx gjqPqpEFIUJQEeBRIcVqK+TQ0WiEwBsmUn0sKc5ToOYiJ+MY5DSOEuDlFiktAwkjqZPkwM+GdCBQ FsWKW/kXBBP1HxnQSjx1R4ZxvHMUprTK0tMzLeVsjSORlSMarcGbP0opjsTOms4zmMI2KANg0jmr YyBAO40joNEtjQxcWSbCzRVtJYYVAqirVHUtx1PVNV1aN9X00Ft6BpWalVqpy2o6HENSepgZ4hSw wtiMaxXQOQwq8Mt1DFNt3MWOAwjGNYwjOxavBAOo5sWsVFVpJOHI7XOJBkGalUtkYQSzWDoKRhea XxXFKUtXlNV9Ts+iNDVh2vEKW2RZVLWcoypwtplg0da0aSWpVQzJbuxKzlQ3J2sA0rEoIzThf1yB Bc8tzkNA6TYEGMjrNeP5lod7qi1GI7GzqO0tdl3BAMgyq2MawjdtoQDKOyzLxIlNOghTowXMem6f Sti6lQsSxPq1FRdRtq0n0KP3yGtuZt18pUu2gQCmHW/SRwCP6NUXZ6TZ+l2BYWvdDQmqRx03MWjr dqRj1aR2wpQZX2woZNUqis3DUwQXNdGP3Xdt3572/u49NzLdzhlPbAzsxqs2ocW+FGMrGOmOY9kG RXiEGS5OyllbkGXMwLOppL7YGbLcZyzt2bPWfsGaCzN3aYQbM3TI0hXp+3mtOeesR6LonkLLUS8t rTw2uvQJI+0HLsnCA0hWpZs7aXHuRe2v9uRQCehnbsmx9TRHAr5gUiV+bem+LqcQu9xbjYZlCck5 QNzlkWF8AaekG5CkmnUO+ZgzR6orH8M+pyLJ8jUn1iqC6K55jEoHNmbVBcZYrm6hKec0p/j9oAjc r818cjlA2OYfyLkZj+OZLdHiNJvkEnbj/GePMhTSmOBqDkwS2zRnrVrGo+Z25HyRkIaszh/UKnDB BJkhcmyDydQPIchsopJGakoZU3yESCyhOivVPijXPkoRo6IFqJFDvKWeRRRjzmoNfRs8l3yzAUI+ SAkIpcPXdlTlAzhCj2SaleDIGkMbam2FCS8WxJaJ3rtHdm5Nyqdk8G5T2w1YToIPqEl2oZ0rs2ro tlrMJ4r0V8R8hY/A6EL3Zs5BcCAJwbyehmDzM6dUHEOS4eMjqd7pFELNdPPWE8HoUlRYoDeBQNQc Uad+UENwYzFpvK2HIrpX4ZtzJuG8Oy521toiM+JN0BZftCd0w1sAMAY0ecIDKnalgixOLwqgOaql WKuBY3IOjeQwuQhixwrcTXKlAC4CgMoLgzuXWfAdwIN4LL8dmUIMwLQ0BvDeGsLgKUWRwc2g+hMt 0PUNRFQ+Xs8qJzBoqtefM/mxz9hYVmgFAqCBpoNQhT066GTtodLyeMyJ5xSkdJBScaJXSNMyYmUS M4voDPiaeMcobJIzspZ0GxtHqWgMEjOOBvI9G/k+SGzNrDJ2tOWC45tsUNyzOnGGVFqLJyLsqZiU INDQWnNGapTklrPkquLbKVKJJPH/uHc06lyDCSnOwgq5kbLj3QQPLAgwNQZmZiuowFE85gEQdTB2 vUxVl1gmRMpIL1KtFGSM3+nFGKOK6CGWJtDjqXlkm6mCSE+yav1K2HgvE5kFJ6a1W9P9iVB2LnhR G89d71T2hQtgkD1XAzUUuZkEAQQyBkqSFMOoYn7smDpUkJob5r2FU1fem77EOu9gu7+DKv1p0Knv hNEUIZfNYeZCZ1VFnpEgfe9Z6j88SLqBam7EpQKSFcK9NpyCXE3N5LFgnFthklIdSaoFwhp8yFZX YGwNjeTLFgpHlyJ4ZcFNybcu2G68DLhpDkujAbYAaAxRQ/BPWgGeZWpRS9uWWX+YIzkHRoDCsa5h d5BWcUyHgFGeFj1p+P1jZBI8smY1jkWNZWlQnI97S3UczJoKKuZya4vxim3KIZmCN5DRU0M6VwQB txgzBtwYcwMORO4PQQNKfaFpNldx9SamrqnJE/Kgbl1Q1XJn3G4MqeT8BzthSzi6isCVcHPZm0ig sjDk/0nBOieE+KBEzYEBpvUYBnoFTpWaS0nyxo+mz69JQUq+TXS5v4NQm03huEGn2q12hJqWw9eZ iJM2y9an7s8UYqY444pCWw3mK145TLe99laIDMTgNuwV8SQ1XxIHOrgUJv0ZnPZr/Q61LzsGJkwa 9E54BAG4OuatrO8Ow7CFdPCs8vxaCDmzJ+NVKKA4sMwYee1LpXuonpP9Ryzc29NWyHcPWJsBiLUa smtvtnDMcrIQ82lbv6G6/7j2gdiglfmQaFFdawsIHntfbaX8mKiDjsqIgUKoDY4wMveQy4AZipqy FsAaA1QVaNA5fjNEq8cePsUYbPXa8b4+4FpLTeM8qnlfMcZGR7ul5Tzls/S2uj7cP0NuTpSkuxOf 1B2/IHoJCDQGBJ95nUKn464MYkFe694ccxPv5Km+jpKD4ltvjEN+R8G3vzfemj+ihAgcsWKWpQvh zhPgL5JC8d3wty+eIgoCk4wOocg3JX5+VNPSuuQaHLEWWmhat4/l2JkxwZWS6C7Inult3qtv8kcO uqfMQOnOoA2KllekSF7O5DoNCOzMDixAzE5EWAaDMpQLrOtlIFtmJEwrTp/vHHbMUsVnHPyN/NKi suAtMsIJhq5GpuENQoRlntSINtTuHkcOVoFDAuWORgyifk3M1DFA5g3v1qRMqEfg3gxg0s3KYnEm RvyClKvKNwrHZujKkuOtdGev5ssOkObuNP3kON6CXkbsLGeueQiujM6KlM7k3g4A0A8k4psk6t4G HKdMliXqfH5wvtligtzkWD1FalgOyP9iXtjP+ianFvBi8Q3lxkuGVNzQ3M7FzlYRCCGu4sbFsuJn CAaxPE0HIAyw5Ayg2m0s1w/qXr6iSoIr8ROQVwKFdsdoNuCskODrbPvwbMiISsewdFimwD3xEFug cxFgUArl4nIMqtkv6KnA3whukucMtQ1Oew7qaxNtJEOO/IFDOsLQtOdEswjFXQhxTprwBv8FbrSu hR1HZqVwlE4g3CLiwH7g0gxOZwhxpl4s9HFAyunuoufl8ryscpkA7Fxkgg5xWCktIN+R0t/xZmlO BtNL2JcnjwaIRKJOFwcyJxgCoqfRhnqHDHZu7KDM7oBl1MtDLGXqlmetqC8sZt9ofNJt/kQisqqx aRDCoyPoLHtG4GANvqjmCK0qZl1DLA4yDl0qpNoFYGlxsSGwWCaybSIMeQIthoFRFFLNnqhmAygA 5ShMtOnH8gQSCg2SDxWDoPgDCAYqOMHlPEOw9iPn5wStRiPDupnu/MDSaCavBPCPDPEP7xWy6SFy YxYvAQXSIwYNORcNQSLsLyMsjSNp8MxGcwfTJnZwgwhlxs1yUwkA5QlE3QmQnQoHwl3QqIKr3nrA cD3meNFr/PDnHyExXNIynRZTDSpuGxbGoyKxcwayMQbsixfTIKLlsj1KNziHZy9iex4wiM1n6u9G NTPwjzQl0wqGKKNuWMtKmnJNpC6i7xxGCDFxywnyADPwzC3EmsLR3Cfx4R5A6R6R7CtocONmRx9w FR/w8K9w9lLSxyyt9SmmitKEdSHngzDzbzgtOwZzdzGJ5wcTHwYzIvyx2Ke0IisqBqCpsMsP0yjC fuaCgSTOlyUnGQqNsSZjawsJkSWSeyhjFUNHvtnKhT4k3P3ouIgoqtux+ywz9qrooi+iQj3j4Pbr LDNUfINLNjqLlEFUhpSPMLSo2UkjcvRrnLoo6gQUnUgI9vW0nJBLdrWre0qvOvIiQkTrOKdiPEDD fPMjt0xPfDAINEDvl0wjujNUyU2pDLs0004vj02UzDSrwDcjTjNK8K4MyMgCWq6LGxdp6K8Rf0Hg YPvr4CsvwsHQqPdOUiXgbK4pkMXqWzlRzgGquC3NjT8oGtDMsP7P3wNIFJopkP/zuuRg3uSz7iog alQIFDPq/iaixDFgRQ7A2ARQx1Yv9SZmLA3KCF4mClnk7kFO6QYJ2VCHRq6tRSXnUMNMkOT1lsy1 rrADQGfKWAywVMcVHuASbyJUHVnMhOFTfRetTUDGwUAHCTUlLUPMtOOs3xVG2VXA2qQVvSXz/MxM /wfV/wssutGwBViNzTYTBIJ1wN61xSpRa0DTFRdTexeOGGm1FzhGH1KmJnNnZgqmXgzOejGNa1eA Wg7mOzkgzqkl3DLDF2TE21eP3IIWE1mMJUD1n1D2JgGq2DCQOmGzGqa1puHSOEmVrtBDTn5sHVuH KVv13Vw0BNMUCHPWITdTFshloV1OG2LiJCPxhyQ1MgjghgoDCgYiTHXgtgZE7DMnNycEmRtmcDoM LAuiHJrl1AnAngqAQNbuPVOgWgb21WZxONAWOIW3Bis16MuA2g2tmqAks2wkNiPgQAtgZ25AyRny XRrxXxsqvTygZAcvenZ29ICUdPFUeDctsDy0vvcDNETjsjcUi0lrP3WXUPVPgo1rT3ZDcLV0jPlL X3TXWrOIwrajm3cS0rdPZU6pz3iIsLWjHCpiFEPJJpTUzpLvoGEpcXovko53e3nXrpWXpDwU7Xq3 nrOJWvsEJENjgFOFGF8VHWGJkkfr5jswVK+C5P0wjwk19wCGajm0AuoJr2UMGU0p0xYAcmEldXTg gg63/grSDX8r7SYJnkcS3kTyBQWzlg3g7sqYFF2tdImV7CxqkujXLijWd30SGOuFuVMLADs0FvLp nltTTy8gUYE3/giztwANHIIO4XMmHKOSHYaF2y+u3XSIpiQipjsjm0rYi05AaYkIvPLrW00Xq4nX lvV3bYjYmrbD+XdXg3t4s4k3U3tPW4j4tPYJB3d3wJz4yYwXaD43mkwpRj3D4UjjtkODspVj8453 eLpY7Y4kHY9Y0kFY+48ECZACSU+mEMyCI32NQi5VIiFX5sDP0CfzOKRYAvoTZYUQQuWDOqAuwowW FKOyn4Z4Ng6Ahk0gwgxA0lzOq4RjTCC3rwPIPH4YVCa5O4W5QQIs/4JjUH51iXEXFNyNaNzl3Fzx WPFk/jsrRYwotPj44LNYoYrXqZkrf42pLPP5qLVUoY0PTUp4+5l5rXeYx5n4jXjZuEEXw5s0oowj HES0pjRsHCQ0wJSozPn5zjHJKNt4qvgvJDE58jV5o3a5p53JQZ4E946JOZ659vPI2Z/0nk94urpa CUo540pJQaHYlXhIvDBZ9UtXj5Ajt6JjqaKvZkFaMZmZ0Jz6T5wjSiAgDQplbmRzdHJlYW0NCmVu ZG9iag0KMjQgMCBvYmoNCjQzMjYNCmVuZG9iag0KMjIgMCBvYmoNCjw8DQovVHlwZSAvUGFnZQ0K L1BhcmVudCA1IDAgUg0KL1Jlc291cmNlcyA8PA0KL0ZvbnQgPDwNCi9GMCA2IDAgUiANCi9GMSA5 IDAgUiANCj4+DQovUHJvY1NldCAyIDAgUg0KPj4NCi9Db250ZW50cyAyMyAwIFINCj4+DQplbmRv YmoNCjI3IDAgb2JqDQo8PA0KL0xlbmd0aCAyOCAwIFINCi9GaWx0ZXIgL0xaV0RlY29kZSANCj4+ DQpzdHJlYW0NCoAQioDRyMBANxgOBcNxkIBAVCIDYNExAcjOIAaLyNBhiMRcMBpDioZgaLRhH4QM ZEYxBBoedxAKDGYTgYTEaTYaToaTyKYeaokIBaMRmLobDyJQpPHRmNpXMTCdTJOjSbjPPipQCLAx xIRuMRzRhxLYXDZPDIqZRBJK7B7BYrJaLPDTlarYNLLbrCMrGNxsLrHc7TawaMRtHhrDa/e8DecF dcJhhlRq9b74IBkML/IcfdgbTYUNsrjLjZrzkJJTbDTb1cBiOIVhtLg5INRqNxdidbl8FncJttxu sXcN7p89bRsOcnsNmMs3tMLh9zDeTy8baOcLpDqM+NtDIergOvDez289wOmIPDzMF5ehAoJBu9Hq dSJLJxgMxgOaeKCSOY5jqMoZLCrCgIMoaiqOiClI+2AZv6IY3jcOg5DeNkDAaKgVQaGAbhoG7+jD AA3jGNIwp3CcMw3BoYhoGqQoeliTudGCRJgFAxDKOg7jKMo3BAJojiHFcOJMlAZxiKkZhcsEkxuq A3DJIIjwyG7goaxLAJEpL8SVJiEygFECBcEEMsNLaXQZI6iBxBcZzEKYyjkOw0jGMohjQMKrDLM6 CwclsuLIkD+zJDMEKIo1BTYoinxoGcIJemIiDKNgyjPFAyymOg3hAOg0LUOYyjGOo5J0PIQRGOcS xPFI3SLDoazdR0xDYMI8zmF0Mq2BrkOVJqnOKtDuK6vLwtkv00uMyLpN1Y9gsdZaSMkyj1V+2TMu e3zUu8FzRWsybZWEujPNUFzWWeEDXtjaFhvO2703TcboOQ7NxWMpzuMMxDqXtdrqXzctu2+G1/Nm G2At/eFnYMwWEPegaCvVFzxS4+6Pv0/kZJi/8AjK/VdJ+oME0UpEWhpb+NxphElRwqqppnVwQDeM 1YTYGAYzfQNJBQuoxDeN46StLDMOfk0vUdQGeZBM2RTQwNFqWGdZ5VOM5zrO88z2M8+6dP8wzVLq Py/Qax6Wk+mqy6M06ij8CJVqueCkMo5joMI5DoJI3ChCwzrrAFdq48AZBq7TOWjdzCWKtGC8KGiv L+8boX3ePCcM2dtuiyYZcHxyQ2y7TZu40Fvc7y959G5NzqdxvL3XYHRXfonW8fzFpV6kNZcKtrBB msOEruEHdSa0y5dutvh5z23EruvPksVyPY2ZfnhBx3fDrR31vcnZss+t4nl3JZnN9z7/ldB7HxW4 7/q+u2fteA7v2ef8LoXM1n6dfe/mAa9DdPDd4Xl+B0H/PecK8p1Dsj0v0gSYQgINCmVuZHN0cmVh bQ0KZW5kb2JqDQoyOCAwIG9iag0KOTQ5DQplbmRvYmoNCjI1IDAgb2JqDQo8PA0KL1R5cGUgL1Bh Z2UNCi9QYXJlbnQgMjYgMCBSDQovUmVzb3VyY2VzIDw8DQovRm9udCA8PA0KL0YwIDYgMCBSIA0K Pj4NCi9Qcm9jU2V0IDIgMCBSDQo+Pg0KL0NvbnRlbnRzIDI3IDAgUg0KPj4NCmVuZG9iag0KNiAw IG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHJ1ZVR5cGUNCi9OYW1lIC9GMA0KL0Jh c2VGb250IC9UaW1lc05ld1JvbWFuDQovRW5jb2RpbmcgL1dpbkFuc2lFbmNvZGluZw0KPj4NCmVu ZG9iag0KOSAwIG9iag0KPDwNCi9UeXBlIC9Gb250DQovU3VidHlwZSAvVHJ1ZVR5cGUNCi9OYW1l IC9GMQ0KL0Jhc2VGb250IC9BcmlhbA0KL0VuY29kaW5nIC9XaW5BbnNpRW5jb2RpbmcNCj4+DQpl bmRvYmoNCjIgMCBvYmoNClsgL1BERiAvVGV4dCAgXQ0KZW5kb2JqDQo1IDAgb2JqDQo8PA0KL0tp ZHMgWzQgMCBSIDEwIDAgUiAxMyAwIFIgMTYgMCBSIDE5IDAgUiAyMiAwIFIgXQ0KL0NvdW50IDYN Ci9UeXBlIC9QYWdlcw0KL1BhcmVudCAyOSAwIFINCj4+DQplbmRvYmoNCjI2IDAgb2JqDQo8PA0K L0tpZHMgWzI1IDAgUiBdDQovQ291bnQgMQ0KL1R5cGUgL1BhZ2VzDQovUGFyZW50IDI5IDAgUg0K Pj4NCmVuZG9iag0KMjkgMCBvYmoNCjw8DQovS2lkcyBbNSAwIFIgMjYgMCBSIF0NCi9Db3VudCA3 DQovVHlwZSAvUGFnZXMNCi9NZWRpYUJveCBbIDAgMCA2MTIgNzkyIF0NCj4+DQplbmRvYmoNCjEg MCBvYmoNCjw8DQovQ3JlYXRvciAoTWljcm9zb2Z0IFdvcmQgKQ0KL0NyZWF0aW9uRGF0ZSAoVGh1 cnNkYXksIFNlcHRlbWJlciAyMywgMTk5OSAxMDozOTo1NyBBTSkNCi9UaXRsZSAoTWVnYWNvdnNN R0NQdjEuUERGKQ0KL0F1dGhvciAoVW5rbm93bikNCi9Qcm9kdWNlciAoQWNyb2JhdCBQREZXcml0 ZXIgMy4wMiBmb3IgV2luZG93cykNCi9LZXl3b3JkcyAoKQ0KL1N1YmplY3QgKCkNCj4+DQplbmRv YmoNCjMgMCBvYmoNCjw8DQovUGFnZXMgMjkgMCBSDQovVHlwZSAvQ2F0YWxvZw0KL0RlZmF1bHRH cmF5IDMwIDAgUg0KL0RlZmF1bHRSR0IgIDMxIDAgUg0KPj4NCmVuZG9iag0KMzAgMCBvYmoNClsv Q2FsR3JheQ0KPDwNCi9XaGl0ZVBvaW50IFswLjk2NDMgMSAwLjgyNTEgXQ0KL0dhbW1hIDEuOSAN Cj4+DQpdDQplbmRvYmoNCjMxIDAgb2JqDQpbL0NhbFJHQg0KPDwNCi9XaGl0ZVBvaW50IFswLjk2 NDMgMSAwLjgyNTEgXQ0KL0dhbW1hIFsxLjkgMS45IDEuOSBdDQovTWF0cml4IFswLjUxMSAwLjI5 MDMgMC4wMjczIDAuMzI2NCAwLjY0OTkgMC4xMjc5IDAuMTI2OCAwLjA1OTggMC42Njk5IF0NCj4+ DQpdDQplbmRvYmoNCnhyZWYNCjAgMzINCjAwMDAwMDAwMDAgNjU1MzUgZg0KMDAwMDAyODQ0MSAw MDAwMCBuDQowMDAwMDI4MTA4IDAwMDAwIG4NCjAwMDAwMjg2NzUgMDAwMDAgbg0KMDAwMDAwMzc4 NCAwMDAwMCBuDQowMDAwMDI4MTQyIDAwMDAwIG4NCjAwMDAwMjc4NzAgMDAwMDAgbg0KMDAwMDAw MDAyMSAwMDAwMCBuDQowMDAwMDAzNzYxIDAwMDAwIG4NCjAwMDAwMjc5OTMgMDAwMDAgbg0KMDAw MDAwODMzNSAwMDAwMCBuDQowMDAwMDAzOTI3IDAwMDAwIG4NCjAwMDAwMDgzMTEgMDAwMDAgbg0K MDAwMDAxMzI1MSAwMDAwMCBuDQowMDAwMDA4NDgwIDAwMDAwIG4NCjAwMDAwMTMyMjcgMDAwMDAg bg0KMDAwMDAxNzMwNSAwMDAwMCBuDQowMDAwMDEzMzk2IDAwMDAwIG4NCjAwMDAwMTcyODEgMDAw MDAgbg0KMDAwMDAyMTk1NiAwMDAwMCBuDQowMDAwMDE3NDUwIDAwMDAwIG4NCjAwMDAwMjE5MzIg MDAwMDAgbg0KMDAwMDAyNjUzNSAwMDAwMCBuDQowMDAwMDIyMTAxIDAwMDAwIG4NCjAwMDAwMjY1 MTEgMDAwMDAgbg0KMDAwMDAyNzczNiAwMDAwMCBuDQowMDAwMDI4MjU4IDAwMDAwIG4NCjAwMDAw MjY2ODAgMDAwMDAgbg0KMDAwMDAyNzcxMyAwMDAwMCBuDQowMDAwMDI4MzQxIDAwMDAwIG4NCjAw MDAwMjg3NzMgMDAwMDAgbg0KMDAwMDAyODg1OCAwMDAwMCBuDQp0cmFpbGVyDQo8PA0KL1NpemUg MzINCi9Sb290IDMgMCBSDQovSW5mbyAxIDAgUg0KL0lEIFs8Y2M4YWFmYWI1MTQxZTMxNmQ5OTA3 YjcwOTE0M2U1MzE+PGNjOGFhZmFiNTE0MWUzMTZkOTkwN2I3MDkxNDNlNTMxPl0NCj4+DQpzdGFy dHhyZWYNCjI5MDI2DQolJUVPRg0K ------_=_NextPart_000_01C02ED7.DB10C6D0 Content-Type: application/msword; name="MEGACOvsMGCP_v3.doc" Content-Disposition: attachment; filename="MEGACOvsMGCP_v3.doc" Content-Transfer-Encoding: base64 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAADAAAAaQAAAAAAAAAA EAAAawAAAAEAAAD+////AAAAAGgAAABuAAAA/QAAAP////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ///////////////////////////////////////////////////////////////////////////s pcEAWQAJBAAACBK/AAAAAAAAEAAAAAAABAAAMncAAA4AYmpiavNX81cAAAAAAAAAAAAAAAAAAAAA AAAJBBYAvL8AAJE9AQCRPQEA8G8AAAAAAABBAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAD//w8AAAAA AAAAAAD//w8AAAAAAAAAAAD//w8AAAAAAAAAAAAAAAAAAAAAAF0AAAAAAKYVAAAAAAAAphUAAKYV AAAAAAAAphUAAAAAAACmFQAAAAAAAKYVAAAAAAAAphUAAEQAAAAAAAAAAAAAAOoVAAAAAAAA6hUA AAAAAADqFQAAAAAAAOoVAACAAAAAahYAACQAAACOFgAAdAAAAOoVAAAAAAAAHbMBAGYCAAAuFwAA OgAAAGgXAAAAAAAAaBcAAAAAAABoFwAAAAAAAGgXAAAAAAAA3h0AAB4AAAD8HQAADAAAAAgeAAAI AAAAA6oBAAIAAAAFqgEAAAAAAAWqAQAAAAAABaoBADcAAAA8qgEAVAQAAJCuAQBUBAAA5LIBACQA AACDtQEA9AEAAHe3AQBwAAAACLMBABUAAAAAAAAAAAAAAAAAAAAAAAAAphUAAAAAAAAQHgAAAAAA AAAAAAAAAAAAAAAAAAAAAADmHAAAQAAAACYdAAC4AAAAEB4AAAAAAAAQHgAAAAAAAAizAQAAAAAA lCAAAAAAAACmFQAAAAAAAKYVAAAAAAAAaBcAAAAAAAAAAAAAAAAAAGgXAAB+BQAALhcAAAAAAACU IAAAAAAAAJQgAAAAAAAAlCAAAAAAAAAQHgAAwAEAAKYVAAAAAAAAaBcAAAAAAACmFQAAAAAAAGgX AAAAAAAAA6oBAAAAAAAAAAAAAAAAAAAAAAAAAAAA6hUAAAAAAADqFQAAAAAAAKYVAAAAAAAAphUA AAAAAACmFQAAAAAAAKYVAAAAAAAAEB4AAAAAAAADqgEAAAAAAJQgAACOBQAAlCAAAAAAAAAiJgAA gjQAAJPrAACqugAAphUAAAAAAACmFQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA6oBAAAAAABoFwAAAAAAAAIXAAAsAAAA8Cx2xy0l vwHqFQAAAAAAAOoVAAAAAAAA0B8AAMQAAAA9pgEAxgMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADVVz ZSBvZiBNRUdBQ08gdmlzLeAtdmlzIE1HQ1AgdG8gYnVpbGQgYSBHYXRld2F5IFNvbHV0aW9uDVdo aXRlIFBhcGVyIGZyb20gSHVnaGVzIFNvZnR3YXJlIFN5c3RlbXMgDUNvbXBhcmVzIE1FR0FDTyB3 aXRoIE1HQ1AgYW5kIHByZXNlbnRzIGFuIHVuYmlhc2VkIHZpZXcgb2YgIGluZHVzdHJ5ICB0cmVu ZHMNDQgNDQxFU1RJIChUSVBIT04pIGhhcyBwcm9wb3NlZCBhIGRpc3RyaWJ1dGVkIGFyY2hpdGVj dHVyZSBmb3IgdGhlIEdhdGV3YXkgaW1wbGVtZW50YXRpb24gdGhhdCBpcyBiYXNlZCBvbiB0aHJl ZSBjb21wb25lbnRzIJYgTWVkaWEgR2F0ZXdheSwgTWVkaWEgR2F0ZXdheSBDb250cm9sbGVyIGFu ZCB0aGUgU2lnbmFsbGluZyBHYXRld2F5LiBBbGwgc3RhbmRhcmRpemF0aW9uIGJvZGllcyBoYXZl IGFjY2VwdGVkIHRoaXMgYXJjaGl0ZWN0dXJlIGFuZCBib3RoIElUVS1UIGFuZCBJRVRGIGhhdmUg YmVlbiB3b3JraW5nIG9uIHRoZSBpbnRlcmZhY2UgZGVmaW5pdGlvbiBiZXR3ZWVuIHRoZSB0aHJl ZSBHYXRld2F5IGNvbXBvbmVudHMuIA1JVFUtVCBTRzE2IGFuZCBJRVRGIFdHIE1FR0FDTyBoYXZl IGJlZW4gbG9va2luZyBhdCB0aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIE1lZGlhIEdhdGV3YXkg KE1HKSBhbmQgdGhlIE1lZGlhIEdhdGV3YXkgQ29udHJvbGxlciAoTUdDKSB0byBzdXBwb3J0IHRo ZSBNRy1NR0MgY29tbXVuaWNhdGlvbi4gSUVURiBpbml0aWFsbHkgZGVmaW5lZCB0aGUgaW50ZXJm YWNlIGluIHRoZSBNR0NQIHNwZWNpZmljYXRpb24gYW5kIHRoZW4gcHJvcG9zZWQgYSBuZXcgaW50 ZXJmYWNlIGRlZmluaXRpb24gaW4gdGhlIE1FR0FDTyBzcGVjaWZpY2F0aW9uLiBJVFUtVCBoYXMg aW4gcGFyYWxsZWwgcHVibGlzaGVkIGl0cyBvd24gc3BlY2lmaWNhdGlvbiBhcyBILjI0OCBwcm90 b2NvbCAoYWxzbyByZWZlcnJlZCBhcyBIL0dDUCkuDRNFTUJFRCBQb3dlclBvaW50LlNsaWRlLjgU ARUMDVRoaXMgcGFwZXIgZmlyc3QgZGVsdmVzIG9uIHRoZSBuZWVkIGFuZCBldm9sdXRpb24gb2Yg R2F0ZXdheSBDb250cm9sIFByb3RvY29scyBhbmQgdGhlbiBjYXB0dXJlcyB0aGUgZGlmZmVyZW5j ZXMgaW4gTUVHQUNPIHZlcnNpb24gMC41IGFuZCBNR0NQIHByb3RvY29sIHZlcnNpb24gMS4wIChS RkMgMjcwNSkuIEZ1cnRoZXIsIGl0IGRpc2N1c3NlcyB0aGUgc3RhdHVzIG9mIGVhY2ggb2YgdGhl c2UgcHJvdG9jb2xzIGFuZCB0aGVpciBhY2NlcHRhbmNlIGluIHRoZSBtYXJrZXQgdG9kYXkuIE5v dGUgdGhhdCB0aGUgZGlmZmVyZW5jZXMgd2l0aCBJVFUtVCBTRzE2IGFyZSBub3QgcHJlc2VudGVk LCBhcyBNRUdBQ08gYW5kIEguMjQ4IGFyZSB0aGUgc2FtZS4NTmVlZCBmb3IgYSBHYXRld2F5IENv bnRyb2wgUHJvdG9jb2wNVGhlIGRlY29tcG9zZWQgR2F0ZXdheSBhcmNoaXRlY3R1cmUgZGVwaWN0 ZWQgYWJvdmUgZGlzdHJpYnV0ZXMgdGhlIENhbGwgY29udHJvbCBmdW5jdGlvbmFsaXR5IGFuZCB0 aGUgTWVkaWEgcHJvY2Vzc2luZyBmdW5jdGlvbmFsaXR5IG92ZXIgZGlmZmVyZW50IG5ldHdvcmsg ZWxlbWVudHMgdml6LiB0aGUgTWVkaWEgR2F0ZXdheSBDb250cm9sbGVyIGFuZCB0aGUgTWVkaWEg R2F0ZXdheSByZXNwZWN0aXZlbHkuIENvbnNlcXVlbnRseSwgdGhlcmUgYXJpc2VzIHRoZSBuZWVk IG9mIGEgY29udHJvbCBwcm90b2NvbCBiZXR3ZWVuIHRoZXNlIGVudGl0aWVzIHRoYXQgcGVybWl0 cyB0aGUgQ2FsbCBDb250cm9sIHRvIHNldCB1cCBtZWRpYSBjb25uZWN0aW9ucyBhbmQgbWVkaWEg cHJvcGVydGllcyBiYXNlZCBvbiB0aGUgY2FsbCByZXF1aXJlbWVudHMuIFRvIGZvcm0gYSBzdWl0 YWJsZSBiYXNpcyBmb3IgdGhlIGNvbXBhcmlzb24gb2YgdGhlIE1HQ1AgYW5kIE1FR0FDTyBwcm90 b2NvbHMgaW4gbGF0ZXIgc2VjdGlvbnMsIHRoaXMgc2VjdGlvbiBzdW1tYXJpemVzIHRoZSBmdW5j dGlvbmFsIHJlcXVpcmVtZW50cyBvZiB0aGUgR2F0ZXdheSBDb250cm9sIHByb3RvY29sLg0NUmVz b3VyY2UgQ29udHJvbCANVGhlIEdhdGV3YXkgQ29udHJvbCBQcm90b2NvbCBwZXJtaXRzIHRoZSBN R0MgdG8gYWxsb2NhdGUgYW5kIGRlYWxsb2NhdGUgYmVhcmVyIHRlcm1pbmF0aW9ucyBhbmQgbWVk aWEgcmVzb3VyY2VzIGZvciB1c2UgYnkgYSBwYXJ0aWN1bGFyIGNhbGwuDVRoZSBwcm90b2NvbCBw cm92aWRlcyB0aGUgZmxleGliaWxpdHkgdGhhdCBhbGxvd3MgdGhlIHJlc291cmNlcyByZXF1aXJl ZCBmb3IgYSBjYWxsIHRvIGJlIHNwZWNpZmllZCBieSB0aGUgTUdDIG9yIHNlbGVjdGVkIGFuZCBp bmZvcm1lZCB0byB0aGUgTUdDIGJ5IHRoZSBNRyBmcm9tIGEgcmVzb3VyY2UgcG9vbC4gDVRoZSBj b250cm9sIHByb3RvY29sIHBlcm1pdHMgdGhlIE1HQyB0byBnZXQgdGhlIHN0YXR1cyBvZiByZXNv dXJjZXMgaW4gdGhlIE1HLg0NQ29ubmVjdGlvbiBNYW5hZ2VtZW50DVRoZSBHYXRld2F5IENvbnRy b2wgcHJvdG9jb2wgcGVybWl0cyB0aGUgTUdDIHRvIGNyZWF0ZSBjb25uZWN0aW9ucyBpbnZvbHZp bmcgcGFja2V0IGFuZCBjaXJjdWl0IGJlYXJlciB0ZXJtaW5hdGlvbnMgaW4gYW55IGNvbWJpbmF0 aW9ucy4gVGhlIGJlYXJlciB0ZXJtaW5hdGlvbnMgbWF5IGJlIFRETSwgYW5hbG9ndWUsIEV0aGVy bmV0LCBBVE0gb3IgRnJhbWUgUmVsYXkuDVRoZSBwcm90b2NvbCBzdXBwb3J0cyBlc3RhYmxpc2ht ZW50IG9mIHVuaWRpcmVjdGlvbmFsLCBzeW1tZXRyaWMgYmktZGlyZWN0aW9uYWwsIGFzeW1tZXRy aWMgYmktZGlyZWN0aW9uYWwsIHB0LXRvLXB0IGFzIHdlbGwgYXMgcHQtdG8tbXVsdGlwb2ludCBm bG93cyBvZiBkaWZmZXJlbnQgbWVkaWEgdHlwZXMgc3VjaCBhcyBhdWRpbywgdGV4dCwgdmlkZW8g ZXRjLg1UaGUgcHJvdG9jb2wgcGVybWl0cyB0aGUgTUdDIGFkZGl0aW9uIG9mIHN1YnRyYWN0aW9u IG9mIG9uZSBvciBtb3JlIG1lZGlhIHN0cmVhbXMgdG8gYSBjb25uZWN0aW9uIGFzIHJlcXVpcmVk IGR1cmluZyBhIGNhbGwuDQ1NZWRpYSBQcm9jZXNzaW5nIENvbnRyb2wNVGhlIEdhdGV3YXkgQ29u dHJvbCBwcm90b2NvbCBwZXJtaXRzIHRoZSBNR0MgdG8gc3BlY2lmeSB0aGUgbWVkaWEgdHJhbnNm b3JtYXRpb24gcGFyYW1ldGVycyBmb3IgZWFjaCBtZWRpYSBzdHJlYW0gdGhhdCBpcyBwYXJ0IG9m IGEgY2FsbC4gVGhpcyBpbmNsdWRlcyB0cmFuc2Zvcm1hdGlvbiBzdWNoIGFzIGFkYXB0YXRpb24g b2YgZmxvd3MgYmV0d2VlbiBkaWZmZXJlbnQgdHlwZXMgb2YgdHJhbnNwb3J0LCBtZWRpYXRpb24g b2YgZmxvd3MgYmV0d2VlbiBkaWZmZXJlbnQgc3RyZWFtIGNvbnRlbnRzIGV0Yy4NVGhlIHByb3Rv Y29sIHBlcm1pdHMgdGhlIE1HQyB0byBzcGVjaWZ5IHNwZWNpYWxpemVkIG1lZGlhIHByb2Nlc3Np bmcgc3VjaCBhcyBlY2hvIGNhbmNlbGxhdGlvbiwgdG9uZSBkZXRlY3Rpb24sIHNpbGVuY2Ugc3Vw cHJlc3Npb24sIHUtbGF3L0EtbGF3IGNvbXBhbmRpbmcgZXRjIHRvIGJlIGRvbmUgb24gbWVkaWEg c3RyZWFtcy4NVGhlIHByb3RvY29sIHBlcm1pdHMgdGhlIE1HQyB0byBzcGVjaWZ5IGFueSBtZWRp YSBpbnNlcnRpb24gc3VjaCBhcyBwbGF5aW5nIGFubm91bmNlbWVudHMgZXRjIG9yIG1lZGlhIGV4 dHJhY3Rpb24gb3BlcmF0aW9ucyBzdWNoIGFzIERUTUYgZGV0ZWN0aW9uIGFuZCBleHRyYWN0aW9u LCBtb2RlbSB0ZXJtaW5hdGlvbiwgZmF4IHRlcm1pbmF0aW9uIGV0YyB0byBiZSBleGVjdXRlZCBv biBhIG1lZGlhIHN0cmVhbS4NDVNpZ25hbCBhbmQgRXZlbnQgUHJvY2Vzc2luZw1UaGUgR2F0ZXdh eSBDb250cm9sIHByb3RvY29sIHBlcm1pdHMgdGhlIE1HQyB0byBzcGVjaWZ5IHRoZSBldmVudHMg dG8gYmUgbW9uaXRvcmVkIG9yIHRoZSBzaWduYWxzIHRvIGJlIGFwcGxpZWQgYnkgdGhlIE1lZGlh IEdhdGV3YXkgb24gYSBwYXJ0aWN1bGFyIG1lZGlhIHN0cmVhbSBvZiBhIGNhbGwuDVRoZSBwcm90 b2NvbCBwcm92aWRlcyBhIG1lY2hhbmlzbSBieSB3aGljaCB0aGUgZXZlbnRzIGRldGVjdGVkIGJ5 IHRoZSBNZWRpYSBHYXRld2F5IGFyZSByZXBvcnRlZCB0byB0aGUgTUdDLg1UaGUgcHJvdG9jb2wg cGVybWl0cyB0aGUgTUdDIHRvIHNwZWNpZnkgdGhlIGFjdGlvbnMgKGUuZy4gcmVwb3J0IGV2ZW50 IHRvIE1HQywgYXBwbHkgYW5vdGhlciBzaWduYWwsIGFjY3VtdWxhdGUgZXZlbnQgdGlsbCByZXF1 ZXN0ZWQgZXRjKSB0byBiZSB0YWtlbiBieSB0aGUgTUcgd2hlbiBhbiBldmVudCBvY2N1cnMuIFNp bWlsYXJseSwgaXQgcGVybWl0cyB0aGUgTUdDIHRvIHNwZWNpZnkgd2hlbiBhIHNpZ25hbCBhcHBs aWVkIHRvIGEgc3RyZWFtIG5lZWRzIHRvIGJlIHJlbW92ZWQgKGUuZy4gYWZ0ZXIgdGltZW91dCwg b24gb2NjdXJyZW5jZSBvZiBhbiBldmVudCwgb24gcmVxdWVzdCB0byBhcHBseSBhbm90aGVyIHNp Z25hbCBldGMpLiANVGhlIHByb3RvY29sIHBlcm1pdHMgdGhlIE1HQyB0byBzcGVjaWZ5IHRoZSBj b2xsZWN0aW9uIG9mIGRpYWxlZCBkaWdpdHMgYXMgYSBwZXIgYSBkaWFsIHBsYW4uDQ1TdGF0aXN0 aWNzIFJlcG9ydGluZw1UaGUgR2F0ZXdheSBDb250cm9sIHByb3RvY29sIHByb3ZpZGVzIGEgbWVj aGFuaXNtIGJ5IHdoaWNoIHRoZSBNZWRpYSBHYXRld2F5IGNhbiByZXBvcnQgc3RhdGlzdGljcyBz dWNoIGFzIHZvbHVtZSBvZiBjb250ZW50IGNhcnJpZWQsIFFPUyBzdGF0aXN0aWNzLCBkdXJhdGlv biBmb3Igd2hpY2ggdGhlIG1lZGlhIHN0cmVhbSB3YXMgYWN0aXZlIGV0YyBjb2xsZWN0ZWQgZHVy aW5nIGEgY2FsbC4NVGhlIHByb3RvY29sIHN1cHBvcnRzIGEgbWVjaGFuaXNtIGJ5IHdoaWNoIHRo ZSBNR0MgY2FuIHJlcXVlc3QgdGhlc2Ugc3RhdGlzdGljcyBhbnl0aW1lIGR1cmluZyB0aGUgY2Fs bC4NDUFzc29jaWF0aW9uIE1hbmFnZW1lbnQNVGhlIEdhdGV3YXkgQ29udHJvbCBwcm90b2NvbCBz dXBwb3J0cyB0aGUgZXN0YWJsaXNobWVudCBvZiBhIGNvbnRyb2wgcmVsYXRpb25zaGlwIGJldHdl ZW4gdGhlIE1HQyBhbmQgTUcuDUl0IHBlcm1pdHMgYSBzaW5nbGUgTUdDIHRvIGhhdmUgYXNzb2Np YXRpb25zIHRvIG11bHRpcGxlIE1HcyBhbmQgdmljZSB2ZXJzYSBpLmUuIGl0IGlzIHBvc3NpYmxl IGZvciBtdWx0aXBsZSBNR0NzIHRvIGNvbnRyb2wgdGVybWluYXRpb25zIG9uIGEgc2luZ2xlIE1H Lg0NVHJhbnNwb3J0DVRoZSBHYXRld2F5IENvbnRyb2wgcHJvdG9jb2wgcHJvdmlkZXMgYSByZWxp YWJsZSB0cmFuc3BvcnQgbWVjaGFuaXNtIGZvciBleGNoYW5nZSBvZiBtZXNzYWdlcyBiZXR3ZWVu IHRoZSBNRyBhbmQgdGhlIE1HQy4gVGhlIHRyYW5zcG9ydCBtZWNoYW5pc20gcGVybWl0cyBkZXRl Y3Rpb24gb2YgdHJhbnNwb3J0IGZhaWx1cmUgYW5kIHN1cHBvcnRzIGEgbGFyZ2UgbnVtYmVyIG9m IGNvbnRyb2wgYXNzb2NpYXRpb25zLg1UaGUgVHJhbnNwb3J0IG1lY2hhbmlzbSBwcm92aWRlcyBh IG1lY2hhbmlzbSBmb3Igb25lIGVudGl0eSB0byBjb3JyZWxhdGUgY29tbWFuZHMgYW5kIHJlc3Bv bnNlcyBmcm9tIHRoZSBvdGhlciBlbnRpdHkgYXMgd2VsbCBhcyB0byBkZXRlY3QgYW5kIHJlamVj dCBkdXBsaWNhdGUgY29tbWFuZHMgYW5kIHJlc3BvbnNlcy4NDVNlY3VyaXR5DVRoZSBHYXRld2F5 IENvbnRyb2wgcHJvdG9jb2wgYWxsb3dzIHNlY3VyZSBjb21tdW5pY2F0aW9uIGJldHdlZW4gdGhl IE1HIGFuZCB0aGUgTUdDLiBJdCBhbGxvd3MgZm9yIG11dHVhbCBhdXRoZW50aWNhdGlvbiBiZXR3 ZWVuIHRoZSBNRyBhbmQgdGhlIE1HQywgY29uZmlkZW50aWFsaXR5IHByb3RlY3Rpb24gb2YgY29u dHJvbCBtZXNzYWdlcyBleGNoYW5nZWQgYmV0d2VlbiB0aGUgdHdvIGVudGl0aWVzIGFuZCBtaXRp Z2F0ZXMgZGVuaWFsIG9mIHNlcnZpY2UgYXR0YWNrcy4gDQ1BcHBsaWNhdGlvbiBTdXBwb3J0DVRo ZSBHYXRld2F5IENvbnRyb2wgcHJvdG9jb2wgcGVybWl0cyB0aGUgTUdDIHRvIHByb3ZpZGUgc3Bl Y2lhbGl6ZWQgc2VydmljZXMgc3VjaCBhcyBOQVMgc2VydmljZXMsIFJlYWwtdGltZSBmYXggc2Vy dmljZXMsIGNvbmZlcmVuY2luZyBzZXJ2aWNlcyBhbmQgSVZSIHNlcnZpY2VzIGJ5IHVzaW5nIHRo ZSBzaWduYWwgcHJvY2Vzc2luZyByZXNvdXJjZXMgYXZhaWxhYmxlIGF0IHRoZSBNRy4NDUV2b2x1 dGlvbiBvZiBHYXRld2F5IENvbnRyb2wgUHJvdG9jb2xzDVRoZSBJUERDIChJUCBEZXZpY2UgQ29u dHJvbCBQcm90b2NvbCkgYW5kIHRoZSBTR0NQIChTaW1wbGUgR2F0ZXdheSBDb250cm9sIFByb3Rv Y29sKSBwcm90b2NvbCBzcGVjaWZpY2F0aW9ucyB3ZXJlIHRoZSBmaXJzdCBjb21wZXRpbmcgY2Fu ZGlkYXRlcyBmb3IgdGhlIEdhdGV3YXkgQ29udHJvbCBQcm90b2NvbCBkZXNjcmliZWQgaW4gdGhl IHNlY3Rpb24gYWJvdmUuIE1HQ1AsIE1FR0FDTyBhbmQgSC4yNDggKGVhcmxpZXIgcmVmZXJyZWQg YXMgSC5HQ1ApIGFyZSBzdWNjZXNzb3JzIHRvIHRoZXNlIHByb3RvY29scy4gQWxsIGRlZmluZSB0 aGUgaW50ZXJmYWNlIGJldHdlZW4gdGhlIE1lZGlhIEdhdGV3YXkgKE1HKSBhbmQgdGhlIE1lZGlh IEdhdGV3YXkgQ29udHJvbGxlciAoTUdDKSBpZGVudGlmaWVkIGluIHRoZSBkaXN0cmlidXRlZCBH YXRld2F5IEFyY2hpdGVjdHVyZSBwcm9wb3NlZCBieSBFVFNJLVRJUEhPTi4gVGhlIGV2b2x1dGlv biBvZiB0aGVzZSBjb21wZXRpbmcgc3RhbmRhcmRzIGNhcHR1cmVzIHRoZSB0cmVuZCBpbiB0aGUg aW5kdXN0cnkgdG9kYXkuDVRoZSBNR0NQIHByb3RvY29sIGNhbWUgaW50byBleGlzdGVuY2UgYXMg YSBjb25zZXF1ZW5jZSBvZiB0aGUgZnVzaW9uIG9mIFNHQ1AgYW5kIElQREMgcHJvdG9jb2xzIGFu ZCB3YXMgZGVyaXZlZCBvdXQgb2YgdGhlIHZlcnNpb24gMS4xIG9mIHRoZSBTR0NQIHByb3RvY29s IGRvY3VtZW50Lg1UaGUgSUVURiBNRUdBQ08gV29ya2luZyBHcm91cCAoYXBwcm92ZWQgYnkgSUVT RyBpbiBKYW51YXJ5IJI5OSksIHJlc3BvbnNpYmxlIGZvciB0aGUgc3RhbmRhcmRpemF0aW9uIG9m IHRoZSBjb250cm9sIGludGVyZmFjZSBiZXR3ZWVuIHRoZSBNZWRpYSBHYXRld2F5IGFuZCBNZWRp YSBHYXRld2F5IENvbnRyb2xsZXIgYWRvcHRlZCBNR0NQIHZlcnNpb24gMC4xIGFzIHRoZSBmaXJz dCBzb2x1dGlvbi4gDVRoZSBNRUdBQ08gZ3JvdXAgd29ya2VkIG9uIHRoZSBldm9sdXRpb24gb2Yg dGhlIE1HQ1AgcHJvdG9jb2wgdGlsbCB0aGUgcmV2aXNpb24gMyBvZiB0aGlzIHByb3RvY29sLCB3 aGljaCB3YXMgcmVsZWFzZWQgb24gMXN0IEZlYiAxOTk5LCBidXQgYWJhbmRvbmVkIHRoZSBlZmZv cnQgZHVlIHRvIHNvbWUgc2hvcnRjb21pbmdzIG9mIHRoZSBwcm90b2NvbCBhbmQgbW9yZSBhY2Nl cHRhbmNlIG9mIGFub3RoZXIgY29tcGV0aW5nIHByb3RvY29sIChNRENQKSBieSBJVFUtVC4NTWVh bndoaWxlLCBNR0NQIGV2b2x1dGlvbiBjb250aW51ZWQgYW5kIGl0IHdhcyBmaW5hbGx5IGNvbnZl cnRlZCBpbnRvIEluZm9ybWF0aW9uYWwgUkZDIDI3MDUgaW4gT2N0b2JlciCSOTkgYWZ0ZXIgdGhl IGZpZnRoIHJldmlzaW9uIG9mIGl0cyBkcmFmdC4NSUVURiBNRUdBQ08gV0cgdGhlbiBzdGFydGVk IHdvcmtpbmcgb24gYSBjb21wcm9taXNlIHByb3RvY29sIGJldHdlZW4gTUdDUCBhbmQgTURDUCwg d2hpY2ggd2FzIGxhdGVyIG5hbWVkIGFzIE1FR0FDTyBwcm90b2NvbC4gVGhlIGZpcnN0IGRyYWZ0 IG9mIE1FR0FDTyBhcHBlYXJlZCBpbiBNYXJjaCCROTkNUGFyYWxsZWwgdG8gTUVHQUNPIGFuZCBN R0NQIGVmZm9ydHMgYnkgSUVURiwgSVRVLVQgd2FzIGV2YWx1YXRpbmcgbXVsdGlwbGUgb3B0aW9u cyBhbmQgaW4gQXByaWwgMTk5OSBJVFUtVCBTRzE2IGFkb3B0ZWQgTUVHQUNPIHZlcnNpb24gMC4x IGFzIHRoZSBzdGFydGluZyBzcGVjaWZpY2F0aW9uIGZvciBJVFUtVCBwcm90b2NvbCwgYW5kIG5h bWVkIGl0IGluaXRpYWxseSBhcyBILkdDUCBhbmQgbGF0ZXIgYXMgSC4yNDggKEgtc2VyaWVzIEdh dGV3YXkgQ29udHJvbCBQcm90b2NvbCkuICANSVRVLVQgU0cxNiBpbnRyb2R1Y2VkIG11bHRpbWVk aWEgY29udGV4dCBpbnRvIHRoZSBwcm90b2NvbCBpbiBNYXkvSnVuZSBhbmQgSUVURiBNRUdBQ08g V0cgc3RhcnRlZCB0aGUgZGViYXRlIHRvIGFjY2VwdCBpdCBvciBub3QuDU1FR0FDTyBXRyBmaW5h bGx5IGRlY2lkZWQgdG8gZW5oYW5jZSB0aGUgcHJvdG9jb2wgZm9yIHN1cHBvcnQgb2YgTXVsdGlt ZWRpYS4gQW4gYWdyZWVtZW50IHdhcyByZWFjaGVkIGluIEp1bmUgOTkgYmV0d2VlbiBJRVRGIE1F R0FDTyBhbmQgSVRVLVQgdG8gY29tZSBvdXQgd2l0aCBhIHNpbmdsZSBwcm90b2NvbCBkb2N1bWVu dC4gQXMgYSBjb25zZXF1ZW5jZSBhbGwgc3Vic2VxdWVudCByZXZpc2lvbnMgb2YgdGhlIHByb3Rv Y29sIGRvY3VtZW50IHdlcmUgdGhlIHNhbWUgZm9yIElFVEYgTUVHQUNPIGFuZCBJVFUtVC4NVGhl IElFVEYgbWVldGluZ3MgaW4gT3NsbyBhbmQgV2FzaGluZ3RvbiwgdGhlIElUVS1UIG1lZXRpbmcg aW4gQmVybGluIGFuZCBoZWN0aWMgYWN0aXZpdHkgb24gdGhlIE1FR0FDTyBtYWlsaW5nIGxpc3Qg cmVzb2x2ZWQgbWFueSBpc3N1ZXMgcGVydGFpbmluZyB0byB0aGUgcHJvdG9jb2wuIEl0IGlzIG5v dyBpbiBnb29kIHNoYXBlIGFuZCB0aGUgY3VycmVudCB2ZXJzaW9uIHYxMSAod2hpY2ggaXMgdGhl IHNhbWUgYXMgSW50ZXJuZXQgRHJhZnQgdmVyc2lvbiAwNSkgaXMgYmVpbmcgcHJlc2VudGVkIGF0 IHRoZSBJVFUtVCBSZWQgQmFuayBtZWV0aW5nIGZvciAoT2N0b2JlciAxOCCWIE9jdG9iZXIgMjIp IGZpbmFsIHJhdGlmaWNhdGlvbi4gVGhlIG91dHB1dCBvZiB0aGUgUmVkIEJhbmsgbWVldGluZyB3 aWxsIGJlIHRoZSCTd2hpdGUgZG9jdW1lbnSUIGZvciBILjI0OCwgd2hpY2ggd2lsbCBiZSwgY2ly Y3VsYXRlZCB0byBhbGwgSVRVLVQgbWVtYmVyIGNvdW50cmllcyBmb3IgZmluYWwgYXBwcm92YWwu IFRoZSByZXN1bHRzIG9mIHRoZSBiYWxsb3Rpbmcgd2lsbCBnbyB0byB0aGUgSVRVLVQgbWVldGlu ZyBpbiBGZWJydWFyeSCRMjAwMCBmb3IgZnJlZXppbmcgYXMgYSBzdGFuZGFyZC4gVGhlIElFVEYg d2lsbCBzaW11bHRhbmVvdXNseSByZWxlYXNlIGEgUkZDLg0NDQ0NV2hhdCBNRUdBQ08gRGVyaXZl cyBmcm9tIE1HQ1A/DVNpbmNlIE1HQ1AgaGFzIGJlZW4gdGhlIGltbWVkaWF0ZSBwcmVkZWNlc3Nv ciBvZiBNRUdBQ08sIG1hbnkgY29uY2VwdHMgcHJvcG9zZWQgaW4gTUdDUCBoYXZlIGZvdW5kIHRo ZXJlIHdheSBpbnRvIHRoZSBNRUdBQ08gc3BlY2lmaWNhdGlvbi4gVGhpcyBzZWN0aW9uIHRyaWVz IHRvIGxpc3QgZG93biB0aGUgY29uY2VwdHMgZm91bmQgaW4gYm90aCBNRUdBQ08gYW5kIE1HQ1Au IA1BbHRob3VnaCB0aGUgbW9kZWxpbmcgb2YgdGhlIE1lZGlhIEdhdGV3YXkgZGlmZmVycyBpbiBN RUdBQ08gd2hlbiBjb21wYXJlZCB0byBNR0NQLCB0aGVyZSBpcyBhIHNpbWlsYXJpdHkgYmV0d2Vl biB0aGUgc2VtYW50aWNzIG9mIHRoZSBjb21tYW5kcyBpbiB0aGUgdHdvIHNwZWNpZmljYXRpb25z LiBUaGVyZSBpcyBhbG1vc3QgYSBvbmUgdG8gb25lIG1hcHBpbmcgYmV0d2VlbiB0aGUgY29tbWFu ZHMgb2YgTUVHQUNPIGFuZCBNR0NQLiBGb3IgZXhhbXBsZSB0aGUgQ3JlYXRlIGNvbm5lY3Rpb24g Y29tbWFuZCBpbiBNR0NQIGhhcyBhbiBlcXVpdmFsZW50IEFERCB0ZXJtaW5hdGlvbiBjb21tYW5k IGluIE1FR0FDTywgdGhlIE1vZGlmeSBjb25uZWN0aW9uIGNvbW1hbmQgaW4gTUdDUCBlcXVhdGVz IHRvIHRoZSBNT0RJRlkgdGVybWluYXRpb24gY29tbWFuZCBvZiBNRUdBQ08gYW5kIHRoZSBEZWxl dGUgY29ubmVjdGlvbiBjb21tYW5kIGVxdWF0ZXMgdG8gdGhlIFNVQlRSQUNUIHRlcm1pbmF0aW9u IGNvbW1hbmQgb2YgTUVHQUNPLg1UaGUgY29uY2VwdCBvZiB1bmRlcnNwZWNpZmllZCwgdW5zcGVj aWZpZWQgYW5kIGZ1bGx5IHNwZWNpZmllZCB0ZXJtaW5hdGlvbiBpZHMgaXMgZGVyaXZlZCBmcm9t IE1HQ1Agd2hlcmUgdGhlIHNhbWUgY29uY2VwdCBpcyB1c2VkIHRvIHBlcm1pdCB0aGUgZmxleGli aWxpdHkgb2YgZWl0aGVyIHRoZSBNRyBvciBNR0MgY2hvb3NpbmcgcmVzb3VyY2VzIGZvciBhIGNh bGwuDVRoZSB1c2Ugb2YgQUJORiBncmFtbWFyIGZvciBzeW50YXggc3BlY2lmaWNhdGlvbiBhbmQg dGhlIFNlc3Npb24gRGVzY3JpcHRpb24gUHJvdG9jb2wgKFNEUCkgdG8gc3BlY2lmeSBtZWRpYSBz dHJlYW0gcHJvcGVydGllcyBpcyB0aGUgc2FtZSBhcyBpbiBNR0NQLg1UaGUgQXVkaXQgY29tbWFu ZHMgKEF1ZGl0IFZhbHVlIGFuZCBBdWRpdCBDYXBhYmlsaXRpZXMpIGFuZCBOb3RpZnkgY29tbWFu ZCBpbiBNRUdBQ08gYXJlIGRlcml2ZWQgZnJvbSBzaW1pbGFyIGNvbW1hbmRzIGluIE1HQ1AuDVRo ZSBTZXJ2aWNlIENoYW5nZSBjb21tYW5kIGluIE1FR0FDTyBoYXMgaXRzIGdlbmVzaXMgaW4gdGhl IFJlc3RhcnRJblByb2dyZXNzIGNvbW1hbmQgc3BlY2lmaWVkIGluIE1HQ1AuDVRoZSBwcm9jZXNz aW5nIG9mIHNpZ25hbHMgYW5kIGV2ZW50cyBpbiBtZWRpYSBzdHJlYW1zIGlzIHRoZSBzYW1lIGlu IE1FR0FDTyBhcyBpbiBNR0NQLiBUaGUgdXNlIG9mIHRoZSBldmVudCBkZXNjcmlwdG9yLCB0aGUg c2lnbmFsIGRlc2NyaXB0b3IgYW5kIHRoZSBlbWJlZGRlZCAoc2lnbmFsIG9yIGV2ZW50KSBkZXNj cmlwdG9yIGlzIHRoZSBzYW1lIGFzIGluIE1HQ1AuIA1UaGUgY29uY2VwdCBvZiBkaWdpdCBtYXAg ZG93bmxvYWQgdG8gaW5kaWNhdGUgdG8gdGhlIE1HIHRoZSBkaWFsIHBsYW4gd2hpbGUgY29sbGVj dGluZyBkaWdpdHMgaXMgYSBzY2hlbWUgdGhhdCBoYXMgYmVlbiBhZG9wdGVkIGZyb20gTUdDUC4N VGhlIGNvbmNlcHQgb2YgcGFja2FnZXMgY29udGFpbmluZyBldmVudCBhbmQgc2lnbmFsIGRlZmlu aXRpb25zIHRoYXQgcGVybWl0cyBlYXN5IGV4dGVuc2lvbiB0byB0aGUgcHJvdG9jb2wgaXMgYm9y cm93ZWQgZnJvbSBNR0NQLiANVGhlIE1FR0FDTyBzcGVjaWZpY2F0aW9uIGZvciB0cmFuc3BvcnQg b2YgbWVzc2FnZXMgb3ZlciBVRFAgaXMgdGhlIHNhbWUgYXMgc3BlY2lmaWVkIGluIE1HQ1AuIFRo ZSB0aHJlZS13YXktaGFuZHNoYWtlLCBjb21wdXRhdGlvbiBvZiByZXRyYW5zbWlzc2lvbiB0aW1l cnMgYW5kIG1lY2hhbmlzbSB0byBmaWdodCB0aGUgcmVzdGFydCBhdmFsYW5jaGUgZGVzY3JpYmVk IGluIE1HQ1AgZmluZCB0aGVpciB3YXkgaW50byB0aGUgQUxGIGRlZmluaXRpb24gc3BlY2lmaWVk IGluIEFubmV4IEUgb2YgTUVHQUNPLg1UaGUgY29uY2VwdCBvZiBhIHByb3Zpc2lvbmFsIHJlc3Bv bnNlIHRvIGEgY29tbWFuZCB0aGF0IGlzIGxpa2VseSB0byB0YWtlIGEgbG9uZyB0aW1lIHRvIGV4 ZWN1dGUgd2FzIGNhcnJpZWQgb3ZlciBmcm9tIE1HQ1AgdG8gTUVHQUNPLgwNTUVHQUNPIHZlcnNp b24gMC41IHZzIE1HQ1AgdmVyc2lvbiAxLjANVGhpcyBzZWN0aW9uIGF0dGVtcHRzIHRvIGNhcHR1 cmUgdGhlIGRpZmZlcmVuY2VzIGJldHdlZW4gdGhlIGxhdGVzdCB2ZXJzaW9ucyBvZiB0aGUgTUdD UCBhbmQgTUVHQUNPIGJhc2VkIG9uIHNvbWUga2V5IGF0dHJpYnV0ZXMgc3VjaCBhcyB0aGUgYmFz aWMgcHJvdG9jb2wgbW9kZWwsIHByb3RvY29sIGRlZmluaXRpb24sIHBlcmZvcm1hbmNlLCBleHRl bnNpYmlsaXR5IGFuZCBhcHBsaWNhdGlvbiBzdXBwb3J0LiANUHJvdG9jb2wgTW9kZWwgDUJvdGgg dGhlIHByb3RvY29scyBhc3N1bWUgc29tZSBjb25uZWN0aW9uIG1vZGVsIHdpdGhpbiB0aGUgTWVk aWEgR2F0ZXdheSBhbmQgcHJvdmlkZSBpbnRlcmZhY2UgZnVuY3Rpb25zIGZvciB0aGUgY29udHJv bCBvZiBjb25uZWN0aW9ucyB3aXRoaW4gdGhlIE1lZGlhIEdhdGV3YXkuIFRoZSBwcm90b2NvbCBt b2RlbHMgYXJlIHZhc3RseSBkaWZmZXJlbnQgYW5kIGFuIGF1dG9tYXRpYyBtaWdyYXRpb24gcGF0 aCBmcm9tIE1HQ1AgdG8gTUVHQUNPIGlzIG5vdCBwb3NzaWJsZS4gDVRoZSBNRUdBQ08gcHJvdG9j b2wgaGFzIGJlZW4gZGVmaW5lZCBrZWVwaW5nIGluIHZpZXcgYSBNZWRpYSBHYXRld2F5IGNvbm5l Y3Rpb24gbW9kZWwgdGhhdCBoYXMgdGhlIGZvbGxvd2luZyB0d28gZW50aXRpZXM6DVRlcm1pbmF0 aW9ucyAtIFRoZXNlIHNvdXJjZSBvciBzaW5rIG9uZSBvciBtb3JlIG1lZGlhIHN0cmVhbXMuIFRl cm1pbmF0aW9ucyBtYXkgYmUgcGh5c2ljYWwgb3IgZXBoZW1lcmFsIGRlcGVuZGluZyBvbiB3aGV0 aGVyIHRoZXkgaGF2ZSBwZXJtYW5lbnQgKGUuZy4gRFMwcykgb3IgdGVtcG9yYXJ5IChpLmUuIG9u bHkgZm9yIHRoZSBkdXJhdGlvbiBvZiBhIGNhbGwpIGV4aXN0ZW5jZS4NIENvbnRleHRzIJYgVGhl c2UgYXJlIHN0YXIgY29ubmVjdGlvbnMgY3JlYXRlZCBieSBhc3NvY2lhdGluZyBtdWx0aXBsZSB0 ZXJtaW5hdGlvbnMuIEEgTlVMTCBjb250ZXh0IGNvbnRhaW5zIGFsbCBub24tYXNzb2NpYXRlZCB0 ZXJtaW5hdGlvbnMuIA1BIHR5cGljYWwgdHdvLXBhcnR5IGNhbGwgaW4gTUVHQUNPIGNvbnRhaW5z IHR3byB0ZXJtaW5hdGlvbnMsIG9uZSBwaHlzaWNhbCB0ZXJtaW5hdGlvbiByZXByZXNlbnRlZCBi eSBhIFBTVE4gdHJ1bmsgKERTMCB0ZXJtaW5hdGlvbikgYW5kIHRoZSBvdGhlciBhbiBlcGhlbWVy YWwgdGVybWluYXRpb24gcmVwcmVzZW50ZWQgYnkgYSBSVFAgU3RyZWFtIFRlcm1pbmF0aW9uIGNv bm5lY3RlZCB0b2dldGhlciBpbiBhIHNpbmdsZSBjb250ZXh0IGlkZW50aWZpZWQgYnkgYSBjb250 ZXh0IGlkLiBCb3RoIHRlcm1pbmF0aW9ucyBhcmUgZXhwbGljaXRseSBhZGRlZCB0byB0aGUgY29u dGV4dCBieSB1c2Ugb2YgTUVHQUNPIGNvbW1hbmRzLiBUaHVzLCBhIENvbnRleHQgaXMgZXNzZW50 aWFsbHkgYSBncm91cGluZyBvZiB0ZXJtaW5hdGlvbnMgY29ubmVjdGVkIGZvciBhIGNhbGwuIEFs bCBhY2NvdW50aW5nIGFuZCByZXNvdXJjZSB1c2FnZSBsb2dnaW5nIGlzIGRvbmUgZm9yIGEgY29u dGV4dC4gDSBNR0NQIGhhcyBiZWVuIGRlZmluZWQga2VlcGluZyBpbiB2aWV3IGEgTWVkaWEgR2F0 ZXdheSBjb25uZWN0aW9uIG1vZGVsIHRoYXQgaGFzIHRoZSBmb2xsb3dpbmcgdHdvIGVudGl0aWVz Og1FbmRwb2ludHMgliBFbmRwb2ludHMgYXJlIHNvdXJjZXMgb3Igc2lua3Mgb2YgZGF0YSBhbmQg Y291bGQgYmUgcGh5c2ljYWwgb3IgdmlydHVhbC4gQSBNZWRpYSBHYXRld2F5IGlzIGFzc3VtZWQg dG8gYmUgYSBjb2xsZWN0aW9uIG9mIGVuZHBvaW50cyBvZiB2YXJpb3VzIHR5cGVzIHN1Y2ggYXMg RFMwcywgQW5hbG9nIGxpbmUsIEFubm91bmNlbWVudCBzZXJ2ZXIgYWNjZXNzIHBvaW50IGV0Yy4N Q29ubmVjdGlvbnMgLSBBIGNvbm5lY3Rpb24gaXMgYW4gYXNzb2NpYXRpb24gYmV0d2VlbiB0d28g ZW5kcG9pbnRzLCB3aGljaCBtYXkgcmVzaWRlIGluIHRoZSBzYW1lIG9yIGRpZmZlcmVudCBNZWRp YSBHYXRld2F5cywgd2l0aCB0aGUgcHVycG9zZSBvZiB0cmFuc21pdHRpbmcgZGF0YSBiZXR3ZWVu IHRoZXNlIGVuZHBvaW50cy4gQ29ubmVjdGlvbnMgbWF5IGJlIGVpdGhlciBwb2ludC10by1wb2lu dCBvciBwb2ludC10by1tdWx0aXBvaW50Lg1UaHVzLCBhIHR3by1wYXJ0eSBjYWxsIGluIE1HQ1Ag aXMgZXN0YWJsaXNoZWQgYnkgY3JlYXRpbmcgYSBjb25uZWN0aW9uIHRvIGEgRFMwIGVuZHBvaW50 IGx5aW5nIHdpdGhpbiB0aGUgTWVkaWEgR2F0ZXdheSB1c2luZyB0aGUgQ3JlYXRlIENvbm5lY3Rp b24gY29tbWFuZC4gQSBjYWxsLWlkIGFzc2lnbmVkIGJ5IHRoZSBNR0MgaXMgYXNzb2NpYXRlZCB0 byBjb25uZWN0aW9ucyBmb3IgYWNjb3VudGluZyBhbmQgbG9nZ2luZyBwdXJwb3Nlcy4NVGhlIE1F R0FDTyBtb2RlbCBjb25zaWRlcmFibHkgc2ltcGxpZmllcyBjb25uZWN0aW9uIHNldHVwIHdpdGhp biB0aGUgTUcgYW5kIHRvIGVudGl0aWVzIG91dHNpZGUgdGhlIE1HLiBJdCBzaW1wbGlmaWVzIHRo ZSBtZWNoYW5pc20gYnkgd2hpY2ggdGhlIE1HQyBjYW4gc3BlY2lmeSBhc3NvY2lhdGVkIG1lZGlh IHN0cmVhbXMgYXMgd2VsbCBhcyBzcGVjaWZ5IHRoZSBkaXJlY3Rpb24gb2YgbWVkaWEgZmxvdy4g TUVHQUNPIGlzIHRoZXJlZm9yZSBhYmxlIHRvIHByb3ZpZGUgZ3JlYXRlciBhcHBsaWNhdGlvbiBs ZXZlbCBzdXBwb3J0IHRoYW4gTUdDUC4gRm9yIGV4YW1wbGUsIHNldHRpbmcgdXAgYSBtdWx0aS1w YXJ0eSBjb25mZXJlbmNlIHVzaW5nIE1FR0FDTyBtZXJlbHkgaW52b2x2ZXMgYWRkaW5nIHNldmVy YWwgdGVybWluYXRpb25zIHRvIGEgY29udGV4dC4gSW4gY2FzZSBvZiBNR0NQIGhvd2V2ZXIsIHRo ZSBNR0MgbmVlZHMgdG8gZXN0YWJsaXNoIHNldmVyYWwgY29ubmVjdGlvbnMgdG8gYSBzcGVjaWFs IHR5cGUgb2YgZW5kcG9pbnQgY2FsbGVkIHRoZSBjb25mZXJlbmNlIGJyaWRnZS4gDVRoZSBNRUdB Q08gbW9kZWwgaW50cm9kdWNlcyB0aGUgY29uY2VwdCBvZiBhbiBFcGhlbWVyYWwgdGVybWluYXRp b24gdG8gYWNjb21tb2RhdGUgUlRQIHN0cmVhbXMgd2hlcmVhcyBpbiBjYXNlIG9mIHRoZSBNR0NQ IG1vZGVsIHRoZSBSVFAgc3RyZWFtIGlzIGltcGxpY2l0IGluIHRoZSBjb25uZWN0aW9uIGFuZCBn ZXRzIGF1dG9tYXRpY2FsbHkgY3JlYXRlZC4gDVRoZSBjb25jZXB0IG9mIEVwaGVtZXJhbCB0ZXJt aW5hdGlvbnMgYnJpbmdzIGFib3V0IHVuaWZvcm1pdHkgaW4gcmVwcmVzZW50YXRpb24gaW4gdGhl IHNlbnNlIHRoYXQgdGhlIFJUUCBzdHJlYW0gY2FuIGJlIG9wZXJhdGVkIHVwb24gaW4gYSBtYW5u ZXIgc2ltaWxhciB0byBhbnkgb3RoZXIgdGVybWluYXRpb24gaW4gdGhlIE1HLiBUaHVzLCBhZGRp bmcgYSBQYWNrZXQgRGF0YSBOZXR3b3JrIChQRE4pIHN1YnNjcmliZXIgaW4gYSBjb25mZXJlbmNl IGlzIG5vdCBkaWZmZXJlbnQgdGhhbiBhZGRpbmcgYSBTd2l0Y2hlZCBDaXJjdWl0IE5ldHdvcmsg KFNDTikgc3Vic2NyaWJlciB0byBhIGNvbmZlcmVuY2UuIFRoZSBNRUdBQ08gbW9kZWwgYWxzbyBo YXMgdGhlIGFkdmFudGFnZSB0aGF0IGludGVybmFsIGNvbm5lY3Rpb25zICh3aXRoaW4gdGhlIE1H KSBhcmUgbm8gZGlmZmVyZW50IHRoYW4gZXh0ZXJuYWwgY29ubmVjdGlvbnMgKHRvIGFub3RoZXIg TWVkaWEgR2F0ZXdheSBvciBUZXJtaW5hbCkuIEluIE1HQ1AsIGV4dGVybmFsIGNvbm5lY3Rpb25z IGFyZSByZWFsbHkgaGFsZiBjb25uZWN0aW9ucyBydW5uaW5nIGZyb20gYW4gZW5kcG9pbnQgb3V0 IHRvd2FyZHMgYSBuZXR3b3JrLiBUaHVzIHR3byBjb25uZWN0aW9ucyB3aWxsIG5lZWQgdG8gYmUg ZXN0YWJsaXNoZWQgZm9yIGEgZnVsbC1kdXBsZXggY29tbXVuaWNhdGlvbi4gSW50ZXJuYWwgY29u bmVjdGlvbnMgbWF5IGJlIGhhbGYtZHVwbGV4IG9yIGZ1bGwgZHVwbGV4LiANVGhlIE1FR0FDTyBt b2RlbCBpbnRyb2R1Y2VzIHRoZSBjb25jZXB0IG9mIGEgTXVsdGlwbGV4IFRlcm1pbmF0aW9uIGFu ZCBTdHJlYW1zIHdpdGhpbiBhIHRlcm1pbmF0aW9uIHdoZXJlIGEgc2luZ2xlIHRlcm1pbmF0aW9u IG1heSBoYXZlIG11bHRpcGxlIG1lZGlhIHN0cmVhbXMgdGhhdCBtYXkgYmUgdHJhbnNtaXR0ZWQg b3IgcmVjZWl2ZWQgb24gZGlmZmVyZW50IGJlYXJlciBjaGFubmVscy4gVGhpcyBlbmFibGVzIHRo ZSBzdXBwb3J0IG9mIEguMzIwIG11bHRpbWVkaWEgdGVybWluYWxzLiANUHJvdG9jb2wgRGVmaW5p dGlvbg1UaGUgcHJvdG9jb2wgZGVmaW5pdGlvbiBmb3IgTUVHQUNPIGFuZCBNR0NQIGlzIGRyaXZl biBieSB0aGUgZGlmZmVyZW5jZXMgaW4gdGhlIHByb3RvY29sIG1vZGVscy4gU29tZSBvZiB0aGUg a2V5IGRpZmZlcmVuY2VzIGFyZSBzdW1tYXJpemVkIGJlbG93LiANDUNvbW1hbmRzDU1FR0FDTyBz dXBwb3J0cyBhbiBhdWdtZW50ZWQgY29tbWFuZCBzZXQgd2l0aCBuZXcgY29tbWFuZHMgc3VjaCBh cyBBdWRpdCBDYXBhYmlsaXRpZXMgdGhhdCBwZXJtaXRzIHRoZSBNR0MgdG8gQXVkaXQgdGhlIGNh cGFiaWxpdGllcyBvZiBhIE1lZGlhIEdhdGV3YXkgdGhlcmVieSBpbmNyZWFzaW5nIHRoZSBmbGV4 aWJpbGl0eSBvZiB0aGUgcHJvdG9jb2wuDQ1NRUdBQ08gU3VwcG9ydHMHTUdDUCBTdXBwb3J0cwcH QUREIHRlcm1pbmF0aW9uIChFcXVpdmFsZW50IHRvIENyZWF0ZSBjb25uZWN0aW9uKQ0NU3VidHJh Y3QgdGVybWluYXRpb24gIChFcXVpdmFsZW50IHRvIGRlbGV0ZSBjb25uZWN0aW9uKQ0NTW9kaWZ5 IHRlcm1pbmF0aW9uIChFcXVpdmFsZW50IHRvIE1vZGlmeSwgTm90aWZpY2F0aW9uIFJlcXVlc3Qg JiBFbmRwb2ludCBDb25maWd1cmF0aW9uKQ0NDVNlcnZpY2UgY2hhbmdlIChFcXVpdmFsZW50IHRv IFJlc3RhcnQgaW4gcHJvZ3Jlc3MgYnV0IGluY2x1ZGVzIG90aGVyIGZ1bmN0aW9ucyBhcyB3ZWxs KQ0NTm90aWZ5DQ1BdWRpdFZhbHVlIChFcXVpdmFsZW50IHRvIEF1ZGl0RW5kcG9pbnQgYW5kIEF1 ZGl0Q29ubmVjdGlvbikNDU1vdmUgDQ1BdWRpdCBDYXBhYmlsaXRpZXMgKE5ldyBDb21tYW5kKQdD cmVhdGUgY29ubmVjdGlvbg0NRGVsZXRlIENvbm5lY3Rpb24NDU1vZGlmeSBjb25uZWN0aW9uDU5v dGlmaWNhdGlvbiBSZXF1ZXN0DUVuZHBvaW50IENvbmZpZ3VyYXRpb24NDVJlc3RhcnQgaW4gcHJv Z3Jlc3MNDQ1Ob3RpZnkNDUF1ZGl0RW5kcG9pbnQNQXVkaXRDb25uZWN0aW9uDQ1Nb3ZlDQ1Ob3Qg c3VwcG9ydGVkBwcNSW4gTUdDUCBtb3N0IG9mIHRoZSBjb21tYW5kcyBhZnRlciB0aGUgY29ubmVj dGlvbiBlc3RhYmxpc2htZW50IGFwcGx5IHRvIGVuZHBvaW50cyBkaXJlY3RseSB3aXRob3V0IHJl ZmVycmluZyB0byBjb25uZWN0aW9uIGlkLCB3aGVyZWFzIGluIE1FR0FDTyBtb3N0IG9mIHRoZSBj b21tYW5kcyBhcHBsaWVzIHRvIHRlcm1pbmF0aW9ucyB3aXRoaW4gY29udGV4dHMuIA1Nb2RlIGlu IE1HQ1AgYXBwbGllcyB0byBjb25uZWN0aW9uLCAgd2hlcmVhcyBNb2RlIGluIE1FR0FDTyBhcHBs aWVzIHRvIHRlcm1pbmF0aW9ucw1UaGVyZSBhcmUgbWFueSBtb3JlIG90aGVyIGZpbmVyIGRpZmZl cmVuY2VzLCB3aGljaCBhcmUgbm90IGxpc3RlZCBoZXJlIGxpa2UgdGhlIE1HQ1AgYXVkaXQgY29t bWFuZCBhcHBsaWVzIHRvIGVuZHBvaW50LCBjb25uZWN0aW9ucyB3aGVyZWFzIE1FR0NPUCBhdWRp dCBjb21tYW5kIGFwcGxpZXMgdG8gdGVybWluYXRpb25zIG9ubHkuDURlbGV0ZSBjb25uZWN0aW9u IGluIE1HQ1AgZGVsZXRlcyB0aGUgbWVkaWEgc3RyZWFtIGF1dG9tYXRpY2FsbHkuIE1FR0FDTyB1 c2VzIFN1YnRyYWN0IHRoYXQgZGVsZXRlcyBhIHRlcm1pbmF0aW9uIG9ubHksIGFuZCB0aGUgbGFz dCBzdWJ0cmFjdCBkZWxldGVzIGNvbnRleHQuDU1HQ1AgcmV0dXJucyBzdGF0aXN0aWNzIHdpdGgg dGhlIGRlbGV0ZSBjb25uZWN0aW9uIGNvbW1hbmQsIHdoZXJlYXMgTUVHQUNPIHJldHVybnMgc3Rh dGlzdGljcyB3aXRoIHN1YnRyYWN0IHRlcm1pbmF0aW9uIGNvbW1hbmQuDVRoZSBBdWRpdCBDYXBh YmlsaXRpZXMgY29tbWFuZCBwZXJtaXRzIHRoZSBNR0MgdG8gYXVkaXQgdGhlIGNhcGFiaWxpdGll cyBvZiB0aGUgTWVkaWEgR2F0ZXdheS4gRm9yIGV4YW1wbGUsIGJ5IHRoZSB1c2Ugb2YgdGhlIEF1 ZGl0IENhcGFiaWxpdGllcyBjb21tYW5kIHRoZSBNR0MgY2FuIGRldGVybWluZSB0aGUgcGFja2Fn ZXMgc3VwcG9ydGVkIGJ5IGEgcGFydGljdWxhciBNRy4gVGhlIGF2YWlsYWJpbGl0eSBvZiB0aGlz IGNvbW1hbmQgaW50cm9kdWNlcyBhIGZsZXhpYmlsaXR5IHRoYXQgcGVybWl0cyBkZXNpZ24gb2Yg TWVkaWEgR2F0ZXdheXMgd2l0aCB2YXJ5aW5nIGNvbXBsZXhpdHkuIE1HQ3MgY2FuIGludGVyb3Bl cmF0ZSB3aXRoIGFsbCB0eXBlcyBvZiBNZWRpYSBHYXRld2F5cyBieSBmaXJzdCBkZXRlcm1pbmlu ZyB0aGVpciBjYXBhYmlsaXRpZXMgYW5kIHRoZW4gaW50ZXJmYWNpbmcgYWNjb3JkaW5nbHkuIFRo aXMgY29tbWFuZCBpcyBub3Qgc3VwcG9ydGVkIGluIE1HQ1AuICANUGFyYW1ldGVycyBhcmUgc3lu dGFjdGljYWxseSBkaWZmZXJlbnQgaW4gdGhlIHR3byBwcm90b2NvbHMuIE1FR0FDTyBoYXMgbWFu eSBtb3JlIHBhcmFtZXRlciBkZXNjcmlwdG9ycyBjb21wYXJlZCB0byBNR0NQIHRoYXQgcGVybWl0 IHdpZGVyIGFwcGxpY2F0aW9uIHN1cHBvcnQuDU1FR0FDTyBpbnRyb2R1Y2VzIHRoZSBjb25jZXB0 IG9mIHRyYW5zYWN0aW9ucyB1c2luZyB3aGljaCBtdWx0aXBsZSBjb21tYW5kcyBhbmQgdGhlaXIg cmVzcG9uc2VzIGNhbiBiZSBjbHViYmVkIHRvZ2V0aGVyLiBUcmFuc2FjdGlvbnMgZW5mb3JjZSBl eGVjdXRpb24gc2VxdWVuY2UuIE11bHRpcGxlIHRyYW5zYWN0aW9ucyBjYW4gZ28gaW4gYSBzaW5n bGUgTUVHQUNPIG1lc3NhZ2UuDU1HQ1AgZG9lcyBub3QgYWxsb3cgY29tbWFuZHMgdG8gYmUgY2x1 YmJlZCB0b2dldGhlciBpbnRvIGEgc2luZ2xlIHRyYW5zYWN0aW9uIGFuZCBzdXBwb3J0cyBvbmx5 IG9uZSBjb21tYW5kIHRvIGJlIGNvbW11bmljYXRlZCBpbiBhIHNpbmdsZSBtZXNzYWdlLiBFYWNo IGNvbW1hbmQgY29udGFpbnMgaGVhZGVyLCBwYXJhbWV0ZXJzIGFuZCBzZXNzaW9uIGRlc2NyaXB0 b3IuDUJ1bmRsaW5nIG9mIGNvbW1hbmRzIGludG8gdHJhbnNhY3Rpb25zIGluIGEgc2luZ2xlIGNv bW1hbmQgaXMgYW4gaW1wb3J0YW50IGZlYXR1cmUgdGhhdCBpcyBsaWtlbHkgdG8gcmVkdWNlIHRo ZSBsb2FkIG9mIE1HLU1HQyBjb21tdW5pY2F0aW9uIGFzIHdlbGwgYXMgcmVkdWNlIGNhbGwgc2V0 dXAgdGltZXMuDQ1NZWRpYSBTdHJlYW0gcHJvcGVydGllcyAMQWxsIHRoZSBtb2RpZmljYXRpb25z IHRvIHRoZSBtZWRpYSBzdHJlYW0gcHJvcGVydGllcyBhcmUgc3BlY2lmaWVkIGFzIHBhcnQgb2Yg Y29ubmVjdGlvbiBwYXJhbWV0ZXJzIGluIE1HQ1AsIHdoZXJlYXMgTUVHQ08gdXNlcyB0ZXJtaW5h dGlvbiBkZXNjcmlwdG9yIHRvIHNwZWNpZnkgdGhlIHByb3BlcnRpZXMuDU1FR0FDTyBzcGVjaWZp ZXMgdGhhdCB0aGUgbWVkaWEgcHJvY2Vzc2luZyBhdHRyaWJ1dGVzIG9mIHRlcm1pbmF0aW9ucyBi ZSByZXN0b3JlZCB0byB0aGVpciBkZWZhdWx0IHZhbHVlcyB3aGVuIGEgdGVybWluYXRpb24gZ29l cyBiYWNrIHRvIE5VTEwgY29udGV4dCBpbiBNRUdBQ08uIEFzIHBlciBNR0NQIHNwZWNpZmljYXRp b24sIGRlbGV0aW5nIGFsbCBjb25uZWN0aW9ucyB0byBhbiBlbmRwb2ludCByZXN0b3JlcyBtZWRp YSBwcm9jZXNzaW5nIGF0dHJpYnV0ZXMgdG8gdGhlaXIgZGVmYXVsdCB2YWx1ZXMuDQ1TaWduYWxz LCBFdmVudHMgYW5kIERpZ2l0IE1hcHMNTUVHQUNPIGFjdGl2YXRlcyBldmVudCBub3RpZmljYXRp b25zIGFuZCBzaWduYWxzIGJ5IHBhc3NpbmcgdGhlIEV2ZW50IERlc2NyaXB0b3IsIFNpZ25hbHMg RGVzY3JpcHRvciBhbmQgRGlnaXQgTWFwIERlc2NyaXB0b3IgaW4gYW4gQWRkLCBNb2RpZnkgb3Ig U3VidHJhY3QgY29tbWFuZC4gTUdDUCBhY3RpdmF0ZXMgZXZlbnQgbm90aWZpY2F0aW9ucyBhbmQg c2lnbmFscyBieSBtZWFucyBvZiBhbiBleHBsaWNpdCBOb3RpZmljYXRpb24gUmVxdWVzdCBvciBh IE5vdGlmaWNhdGlvbiBSZXF1ZXN0IGVtYmVkZGVkIGluIGEgQ3JlYXRlIENvbm5lY3Rpb24sIE1v ZGlmeSBDb25uZWN0aW9uIG9yIERlbGV0ZSBDb25uZWN0aW9uLg1NR0NQIGV4cGxhaW5zIGhhbmRs aW5nIG9mIFF1YXJhbnRpbmUgZXZlbnRzIHdoaWxlIE1FR0FDTyBkb2VzIG5vdCB0cmVhdCBRdWFy YW50aW5lIGV2ZW50cy4NTUVHQUNPIHBlcm1pdHMgcmVmZXJlbmNpbmcgb2YgcHJlbG9hZGVkIGRp Z2l0IG1hcHMgaW4gdGhlIEV2ZW50IGRlc2NyaXB0b3IuIEFsc28sIGEgZGlnaXQgbWFwIGhhcyBh IHNjb3BlIHRoYXQgZGVmaW5lcyB0aGUgdGVybWluYXRpb24gb3Igc2V0IG9mIHRlcm1pbmF0aW9u cyB0byB3aGljaCB0aGUgRGlnaXQgbWFwIGFwcGxpZXMuIFN1Y2ggYSBmZWF0dXJlIGRvZXMgbm90 IGV4aXN0IGluIE1HQ1AuIFRoaXMgZmVhdHVyZSByZWR1Y2VzIHRoZSBzaXplIG9mIG1lc3NhZ2Vz IHRoYXQgbmVlZCB0byBiZSBleGNoYW5nZWQgYmV0d2VlbiB0aGUgTUcgYW5kIHRoZSBNR0MgYXMg dGhlIGNvbXBsZXRlIGRpZ2l0IG1hcCBuZWVkIG5vdCBiZSBkb3dubG9hZGVkIGV2ZXJ5IHRpbWUg YSBjYWxsIHdpdGggYSBuZXcgZGlhbCBwbGFuIG5lZWRzIHRvIGJlIHRlcm1pbmF0ZWQuDSANUGFj a2FnZXMgYW5kIFRlcm1pbmF0aW9uIFR5cGVzIA1NRUdBQ08gcHJvdmlkZXMgYSBzaW1wbGVyIHNl dCBvZiBlbmRwb2ludCB0eXBlcyBhbmQgc3VwcG9ydHMgdGVybWluYXRpb24gcHJvcGVydGllcyBh bmQgcGFja2FnZXMgdG8gc3VwcG9ydCBhIHdpZGVyIHNldC4NTUdDUCBkZWZpbmVzIGVhY2ggZW5k cG9pbnQgdHlwZSBhcyBhIHNlcGFyYXRlIGVudGl0eSwgd2l0aCBhZGRpdGlvbmFsIHR5cGVzIHN1 Y2ggYXMgQW5ub3VuY2VtZW50IHNlcnZlciBlbmRwb2ludCwgSVZSIGFjY2VzcyBlbmRwb2ludCwg Q29uZmVyZW5jZSBicmlkZ2UgZW5kcG9pbnQsIFBhY2tldCByZWxheSBlbmRwb2ludCwgYW5kIFdp cmV0YXAgZW5kcG9pbnQuDVBhY2thZ2VzIHN1cHBvcnRlZCBieSBNR0MgYXJlIGJ1bmRsZWQgaW50 byB0aGUgbWFpbiBwcm90b2NvbCBkb2N1bWVudCB3aGVyZWFzIGluIE1FR0FDTyB0aGV5IHdpbGwg YmUgZGVmaW5lZCBpbiBzZXBhcmF0ZSBSRkNzIGFuZC9vciBBbm5leGVzLiBUaGUgY29uY2VwdCBv ZiBwYWNrYWdlcyBpcyB0aGUga2V5IHRvIHRoZSBleHRlbnNpYmlsaXR5IG9mIGJvdGggTUVHQUNP IGFuZCBNR0NQLiBUaGUgc2VwYXJhdGlvbiBvZiBwYWNrYWdlcyBmcm9tIHRoZSBtYWluIE1FR0FD TyBwcm90b2NvbCBkb2N1bWVudCBwZXJtaXRzIGVhc3kgZXh0ZW5zaW9uIG9mIHRoZSBwcm90b2Nv bC4gTmV3IHZlcnNpb25zIG9mIHRoZSBwcm90b2NvbCBhcmUgbm90IHJlcXVpcmVkIGZvciBldmVy eSBuZXcgcGFja2FnZSB0aGF0IGlzIGFkZGVkIHdoaWNoIGlzIHdoYXQgd2lsbCBuZWVkIHRvIGJl IGRvbmUgZm9yIE1HQ1AuIA0NTUctTUdDIENvbnRyb2wgQXNzb2NpYXRpb24NTUctTUdDIGNvbnRy b2wgYXNzb2NpYXRpb24gaXMgZXN0YWJsaXNoZWQgdXNpbmcgdGhlIFNlcnZpY2UgQ2hhbmdlIG1l c3NhZ2UgaW4gTUVHQUNPLiBJbiBNR0NQIHRoaXMgaXMgZXN0YWJsaXNoZWQgdGhyb3VnaCB0aGUg k3NlY3VyaXR5lCBsYXllciBhbmQgaGVuY2UgcmVzdWx0cyBpbiBhIHNlY3VyaXR5IGFzc29jaWF0 aW9uLg1JbiBNRUdBQ08sIHdoZW4gTUdDIGZhaWxzLCBoYW5kb3ZlciBpcyBpbml0aWF0ZWQgYnkg dGhlIE1HQyBpc3N1aW5nIGEgU2VydmljZSBDaGFuZ2UgY29tbWFuZCB0byB0aGUgTUcgaW5kaWNh dGluZyB0aGUgbmV3IE1HQyBJZCB0byBjb21tdW5pY2F0ZSB3aXRoLiBJbiBjYXNlIG9mIE1HQ1As IGFzc29jaWF0aW9uIGJldHdlZW4gTUdDICYgTUcgaXMgZGVmaW5lZCBhdCBTZWN1cml0eSBsZXZl bC4gQW55IE1HQyBjYW4gdGFrZSBvdmVyIGlmIGl0IGhhcyB0aGUgcHJvcGVyIHNlY3VyaXR5IGNy ZWRlbnRpYWxzLiAgDU1HIHJlYm9vdCBpbiBNRUdBQ08gaXMgY29tbXVuaWNhdGVkIGJ5IG1lYW5z IG9mIFNlcnZpY2UgQ2hhbmdlIGNvbW1hbmQgd2hpbGUgTUdDUCB1c2VzIFJlc3RhcnQgSW4gUHJv Z3Jlc3MgZm9yIHRoYXQgcHVycG9zZS4gIA0NU2VjdXJpdHkgIA1Cb3RoIE1FR0FDTyBhbmQgTUdD UCBhZGRyZXNzIHNlY3VyaXR5LiBIb3dldmVyLCBNR0NQIG9ubHkgdGFsa3Mgb2YgSVBTRUMgYXMg dGhlIHVuZGVybHlpbmcgc2VjdXJpdHkgbWVjaGFuaXNtLiBNRUdBQ08gb24gdGhlIG90aGVyIGhh bmQgcHJvdmlkZXMgYW4gYWRkaXRpb25hbCBvcHRpb24gb2YgaW5jbHVkaW5nIGFuIGF1dGhlbnRp Y2F0aW9uIGhlYWRlciB0aGF0IHByb3ZpZGVzIHNlY3VyaXR5IHdoZW4gSVBTRUMgaXMgbm90IGF2 YWlsYWJsZS4NDVByb3RvY29sIEFwcGxpY2F0aW9uIFN1cHBvcnQNVGhlIGNvbmNlcHQgb2YgY29u dGV4dHMgaXMgYSBwb3dlcmZ1bCB0b29sIHRvIHJlcHJlc2VudCBjb25mZXJlbmNlcy4gQXMgY29u dGV4dCBkZWZpbml0aW9uIGlzIG5vdCBkZXBlbmRlbnQgb24gdGhlIG9yZGVyIGluIHdoaWNoIHRl cm1pbmF0aW9ucyBhcmUgYWRkZWQgb3Igc3VidHJhY3RlZCwgdGhlIGNvbnRleHQgcHJvdmlkZXMg YSBmcmFtZXdvcmsgd2hlcmUgbm8gc3BlY2lhbCBvcGVyYXRpb25zIGFyZSByZXF1aXJlZCB3aGVu IGEgcGFydGljaXBhbnQgaW4gYSBjb25mZXJlbmNlIGRyb3BzIG91dC4gVGhlIHRlcm1pbmF0aW9u cyBjYW4gYmUgc3VidHJhY3RlZCB3aXRob3V0IGFmZmVjdGluZyB0aGUgY29ubmVjdGl2aXR5IG9m IHRoZSB0ZXJtaW5hdGlvbnMgcmVtYWluaW5nIGluIHRoZSBjb25mZXJlbmNlLiANQ29uZmVyZW5j ZXMgdXNpbmcgTUdDUCBhcmUgYWNoaWV2ZWQgYnkgdGVybWluYXRpbmcgc2V2ZXJhbCBjb25uZWN0 aW9ucyBvbiBhIGNvbmZlcmVuY2UgZW5kcG9pbnQuDU1FR0FDTyBpcyBtdWx0aW1lZGlhIHJlYWR5 LiBJdCBoYXMgZGVmaW5lZCB3YXkgdG8gc2V0IG1peGluZyBwYXJhbWV0ZXJzIGZvciBhdWRpbywg dmlkZW8uIFRoaXMgaXMgYWNoaWV2ZWQgYnkgdGhlIHN1cHBvcnQgb2YgbXVsdGlwbGUgbWVkaWEg c3RyZWFtcyBwZXIgdGVybWluYXRpb24gYW5kIHRoZSBhYmlsaXR5IHRvIHN5bmNocm9uaXplIHN0 cmVhbXMgYnkgc2V0dGluZyBjb250ZXh0IHByb3BlcnRpZXMuDU1HQ1AgZG9lcyBub3QgaGF2ZSB0 aGUgY2FwYWJpbGl0eSB0byBzZXQgbWl4aW5nIHBhcmFtZXRlcnMuIEhlbmNlLCBpdCBpcyBkb2Vz IG5vdCBwcm92aWRlIGFueSBleHBsaWNpdCBzdXBwb3J0IGZvciBtdWx0aW1lZGlhLg1NRUdBQ08g c3VwcG9ydHMgdGhlIE1PVkUgY29tbWFuZCB0aGF0IGFsbG93cyB0aGUgTUdDIHRvIG1vdmUgdGVy bWluYXRpb25zIGZyb20gb25lIGNvbnRleHQgdG8gYW5vdGhlciB1c2luZyBvbmUgY29tbWFuZC4g VGhpcyBlYXNlcyBpbXBsZW1lbnRhdGlvbiBvZiBzdXBwbGVtZW50YXJ5IHNlcnZpY2VzIGxpa2Ug Q2FsbCBXYWl0aW5nLCBjYWxsIGhvbGQgZXRjIGluIHdoaWNoIHRoZSBtZWRpYSBzdHJlYW0gZnJv bSB0aGUgc2FtZSBzdWJzY3JpYmVyIG5lZWRzIHRvIGJlIGNvbm5lY3RlZCB0byBtZWRpYSBzdHJl YW1zIGluIHR3byBkaWZmZXJlbnQgY29udGV4dHMgYWx0ZXJuYXRlbHkuDU1FR0FDTyBzdXBwb3J0 cyBhIE11eCBUZXJtaW5hdGlvbiBjb25zdHJ1Y3QgdGhhdCBmYWNpbGl0YXRlcyBpbnRlcndvcmtp bmcgd2l0aCBILjMyMCBtdWx0aW1lZGlhIHRlcm1pbmFscy4gIE1HQ1AgZG9lcyBub3QgcHJvdmlk ZSB0aGlzIGNvbnN0cnVjdC4NTUVHQUNPIHByb3ZpZGVzIGEgaGlnaCBkZWdyZWUgb2YgY29udHJv bCBvbiB0aGUgbWVkaWEgc3RyZWFtcyBjb250YWluZWQgaW4gYSBjb250ZXh0LiBJdCBhbGxvd3Mg dHJhbnNtaXQgYW5kIHJlY2VpdmUgb2YgZWFjaCB0ZXJtaW5hdGlvbiB0byBiZSBpbmRpdmlkdWFs bHkgY29udHJvbGxlZCBhcyB3ZWxsIGFzIHRoZSBjb25uZWN0aW9ucyBiZXR3ZWVuIGluZGl2aWR1 YWwgc3RyZWFtcyBjYW4gYmUgY29udHJvbGxlZC4gVGhpcyBwZXJtaXRzIGVhc3kgaW1wbGVtZW50 YXRpb24gb2YgbmV3IHNlcnZpY2VzIHN1Y2ggYXMgbXV0aW5nIG9mIG9uZSBvZiB0aGUgcGFydGlj aXBhbnRzLCB3aXJlIHRhcHBpbmcsIHNwZWVjaCB0byB0ZXh0IGNvbnZlcnNpb24gZXRjLg1BZGRp bmcgbmV3IHBhY2thZ2VzIHRvIE1FR0FDTyBwcm90b2NvbCBpcyBlYXN5IGJlY2F1c2UgcGFja2Fn ZSBkZWZpbml0aW9ucyBhcmUgbm90IHBhcnQgb2YgdGhlIG1haW4gcHJvdG9jb2wgdGV4dC4gQWRk aW5nIG5ldyBwYWNrYWdlcyBpcyBhbiBpbmRlcGVuZGVudCBwcm9jZWR1cmUgdGhhdCBtZXJlbHkg cmVxdWlyZXMgcmVnaXN0cmF0aW9uIG9mIHRoZSBuZXcgcGFja2FnZSB3aXRoIElBTkEuIEJ1aWxk aW5nIG5ldyBhcHBsaWNhdGlvbnMgYnkgaW50cm9kdWNpbmcgbmV3IHBhY2thZ2VzIGlzIHRoZXJl Zm9yZSBlYXNpZXIgdGhhbiBmb3IgTUdDUCB0aGF0IHJlcXVpcmVzIGEgbmV3IHByb3RvY29sIHJl dmlzaW9uIHRvIGludHJvZHVjZSBhIG5ldyBwYWNrYWdlLg1NRUdBQ08gaGFzIGEgbW9yZSBnZW5l cmFsIGNhbGwgbW9kZWwgdGhhbiBNR0NQLiBUaHVzIGl0IGlzIG1vcmUgZWZmaWNpZW50IGZvciBU RE0gdG8gVERNIGNhbGxzLCBURE0gdG8gQVRNIGNhbGxzIGFzIHdlbGwgYXMgZm9yIFRETSB0byBJ UCBjYWxscy4NDVN0YW5kYXJkcyCWIFN0YXR1cyBhbmQgQWNjZXB0YW5jZSANDVN0YW5kYXJkB1Zl cnNpb25zB01hcmtldCBBY2NlcHRhYmlsaXR5BwdJRVRGIE1HQ1ANB0N1cnJlbnQgVmVyc2lvbiA9 IDEuMA1SRkMgMjcwNQ1bTm8gdXBkYXRlcyBwbGFubmVkXQdDYWJsZUxhYnMgDUNhYmxlIExhYnMg aGFzIGFkb3B0ZWQgYW5kIG1vZGlmaWVkIE1HQ1AgdmVyc2lvbiAwLjEgZm9yIHRoZWlyIHByb3Rv Y29sIHNwZWNpZmljYXRpb24uDVNhbXBsZSBDb21wYW5pZXMgliBBY2Nlc3MgQ29tbXVuaWNhdGlv bnMsIEFUJlQgQnJvYWRiYW5kICYgSW50ZXJuZXQgU2VydmljZXMsIENhYmxlIE9uZSwgQ2FibGUg VFYgZXRjLgcHBwdTb2Z0c3dpdGNoIENvbnNvcnRpdW0NU29mdHN3aXRjaCBoYXMgYWRvcHRlZCBN R0NQIGFzIHRoZWlyIHN0YW5kYXJkLCBidXQgdGhleSBhcmUgb3BlbiB0byBhZG9wdCBNRUdBQ08g b3IgSC4yNDggYWZ0ZXIgdGhlIGRlZmluaXRpb24gZm9yIHRoZXNlIHN0YW5kYXJkcyBhcmUgZnJv emVuLg1CYWNrZXJzOiBDaXNjbywgRW5yb24sIEhQLCBMZXZlbDMsIEx1Y2VudCwgTm9ydGVsLCBO b3J0aFBvaW50LCBQdWx2ZXIsIFJoeXRobSwgVGVsZWNvcmRpYSwgVm92aWRhLiBOb3RlIHRoYXQg bW9zdCBvZiB0aGVzZSBjb21wYW5pZXMgYXJlIG1lbWJlcnMgb2YgSUVURiBNRUdBQ08gV0cgYXMg d2VsbCBhbmQgYXJlIGNvbW1pdHRlZCB0byBhZG9wdCBNRUdBQ08gYWZ0ZXIgaXQgYmVjb21lcyBz dGFuZGFyZC4HBwcHT3RoZXIgdmVuZG9ycyBhcmUgYnVpbGRpbmcgdGhlaXIgcHJvZHVjdHMgYmFz ZWQgb24gTUdDUCB0aWxsIE1FR0FDTyBpcyBwdWJsaXNoZWQgYXMgc3RhbmRhcmQuBwdJRVRGIE1F R0FDTy8NSVRVLVQgU0cxNg1ILjI0OAdEcmFmdCAwLjUxIA1bSC4yNDggRmluYWwgUmVsZWFzZSBQ bGFubmVkIGluIEZlYiAyMDAwIF0yB05vIGNvbW1lcmNpYWwgaW1wbGVtZW50YXRpb24gYXZhaWxh YmxlIGJ1dCBleHBlY3RlZCBvbmx5IGFmdGVyIGl0IGlzIHN1Ym1pdHRlZCBhcyBSRkMuIA1UaGVy ZSBtYXkgYmUgc29tZSBsYWIgaW1wbGVtZW50YXRpb25zIGF2YWlsYWJsZS4HBw0xICBFeHBlY3Rl ZCB0byBiZSBhY2NlcHRlZCBhcyBhbiBSRkMuDTIgIFNpbmNlIG1pZC1KdW5lIDE5OTksIE1FR0FD TyBXRyBhbmQgSVRVLVQgU0cxNiBoYXZlIGFncmVlZCB0byBwdWJsaXNoIGEgc2luZ2xlIGRvY3Vt ZW50Lg0NSXQgaXMgZXZpZGVudCBmcm9tIHRoZSBhYm92ZSBjb21wYXJpc29uIHRoYXQgTUVHQUNP IGNvdmVycyBhIGJyb2FkZXIgc2V0IG9mIHJlcXVpcmVtZW50cywgaXMgZWFzaWx5IGV4dGVuc2li bGUsIHByb3ZpZGVzIGdyZWF0ZXIgYXBwbGljYXRpb24gbGV2ZWwgc3VwcG9ydCBhbmQgY2FuIHBy b3ZpZGUgYSBiZXR0ZXIgcGVyZm9ybWFuY2UgaW4gY29tcGFyaXNvbiB0byBNR0NQLiBNRUdBQ08g aW5jbHVkZXMgYWxtb3N0IGFsbCB0aGUgZ29vZCBmZWF0dXJlcyBvZiBNR0NQIChlLmcuIFRyYW5z cG9ydCwgUGFja2FnZXMsIGV2ZW50cywgc2lnbmFscyBldGMpIGFuZCBhZGRzIG5ldyBmZWF0dXJl cyB0aGF0IHBlcm1pdCBmYWJyaWNhdGlvbiBvZiBHYXRld2F5cyB3aXRoIG1vcmUgY2FwYWJpbGl0 aWVzLiBJdCBpcyB0aGVyZWZvcmUgZW1lcmdpbmcgYXMgdGhlIGZpbmFsIHNvbHV0aW9uIGZvciB0 aGUgTUctTUdDIGludGVyZmFjZS4gDQwNQ29uY2x1c2lvbjogV2h5IE1FR0FDTz8NTUVHQUNPIGlu dHJvZHVjZXMgc2V2ZXJhbCBuZXcgY29uY2VwdHMgKHN1Y2ggYXMgY29udGV4dHMsIGVwaGVtZXJh bCB0ZXJtaW5hdGlvbnMsIHRyYW5zYWN0aW9ucyBldGMuKSB0aGF0IHByb3ZpZGUgYSBwb3dlcmZ1 bCBtZWNoYW5pc20gZm9yIHN1cHBsZW1lbnRhcnkgc2VydmljZXMgKGxpa2UgY2FsbCB3YWl0aW5n KSwgbXVsdGktcGFydHkgY29uZmVyZW5jaW5nIGFuZCBtdWx0aW1lZGlhIHN1cHBvcnQuIA1Db25j bHVzaW9uOiBNRUdBQ08gaXMgZmVhdHVyZS1yaWNoIGFuZCBwcm92aWRlcyBhIGJldHRlciBvcHRp b24gdG8gbWFudWZhY3R1cmVycyB0byBidWlsZCB2YWx1ZS1hZGRlZCBwcm9kdWN0cyB3aXRoIGRp ZmZlcmVudGlhdGVkIGZlYXR1cmVzLg1JRVRGIChNRUdBQ08gV0cpIGFuZCBJVFUtVCAoU0cxNikg aGF2ZSBqb2luZWQgaGFuZHMgYW5kIGFncmVlZCB0byBwdWJsaXNoIGEgY29tYmluZWQgZG9jdW1l bnQgbm93IG9ud2FyZHMuIFRoaXMgaXMgYSBzaWduaWZpY2FudCBkZXZlbG9wbWVudCBhbmQgc2hv dWxkIGxlYWQgdG8gdGhlIGRlZmluaXRpb24gb2YgYSBjb21tb24gcHJvdG9jb2wgZm9yIHRoZSBj b252ZXJnZW50IG5ldHdvcmtzIHRoYXQgaXMgYWNjZXB0YWJsZSB0byBib3RoIHRoZSB0ZWxlY29t IHN0YW5kYXJkaXNhdGlvbiBib2RpZXMgKElUVS1UIGFuZCBFVFNJKSBhbmQgZGF0YWNvbSBzdGFu ZGFyZGl6YXRpb24gb3JnYW5pemF0aW9ucyAoSUVURikuIA1NRUdBQ08gKHdoaWNoIHdpbGwgZXZv bHZlIGludG8gSC4yNDgpIGhhcyBhIGhpZ2hlciBjaGFuY2Ugb2YgYmVpbmcgYWNjZXB0ZWQgaW4g dGhlIG1hcmtldC4NQ29uY2x1c2lvbjogIFRoZSBlZmZvcnQgaXMgYmVpbmcgZHJpdmVuIGJ5IG1h am9yIGRhdGFjb20gYW5kIHRlbGVjb20gdmVuZG9ycyBhbmQgaXQgaXMgaW4gdGhlIGludGVyZXN0 IG9mIGJvdGggcGFydGllcyB0byBlbnN1cmUgaW50ZXJvcGVyYWJpbGl0eSBpbiB0aGUgY29udmVy Z2VkIG5ldHdvcmtzLiBUaGlzIHdpbGwgaGVscCB0byBvdmVyY29tZSB0aGUgdmFzdGx5IGRpc3Np bWlsYXIgYmFja2dyb3VuZHMgb2YgdGhlIHN0YW5kYXJkaXNhdGlvbiBib2RpZXMuICANTUdDUCBp cyBvbmx5IGFuIGluZm9ybWF0aW9uYWwgUkZDLiBIZW5jZSwgdGhlcmUgd2lsbCBub3QgYmUgYW55 IGZ1cnRoZXIgc3VwcG9ydCBmcm9tIElFVEYgZm9yIE1HQ1AuDUNvbmNsdXNpb246IFRoZSBldm9s dXRpb24gb2YgTUdDUCBoYXMgdmlydHVhbGx5IHN0b3BwZWQgYW5kIGFueSBlbmhhbmNlbWVudHMg b2Ygc2VydmljZXMgY2FycmllZCBieSB2ZW5kb3JzIGFyZSBsaWtlbHkgdG8gYmUgcHJvcHJpZXRh cnkgaW4gbmF0dXJlLiANQ2FibGVMYWJzIGhhcyBhbHNvIGFkb3B0ZWQgYW5kIG1vZGlmaWVkIE1H Q1AgcHJvdG9jb2wgZm9yIHRlbGVwaG9ueSBzdXBwb3J0IG9uIGNhYmxlIHN5c3RlbXMsIHRoZXkg YXJlIGdvaW5nIHRvIHN1cHBvcnQgdGhlIHByb3RvY29sIGZvciB0aGVpciBpbXBsZW1lbnRhdGlv biBvciBkZWZpbml0aW9uLg1Nb3N0IG9mIHRoZXNlIE1HQ1AgdmVuZG9ycyBoYXZlIGNvbW1pdHRl ZCB0byBtb3ZpbmcgdG8gTUVHQUNPIGluIGZ1dHVyZS4NQ29uY2x1c2lvbjogRXZlbiB0aG91Z2gg TUVHQUNPIGlzIHN0aWxsIGV2b2x2aW5nIHRoZXJlIGFyZSBubyBjb21tZXJjaWFsIGltcGxlbWVu dGF0aW9ucyBhbmQgIHZlbmRvcnMgdG9kYXkgaGF2ZSBqb2luZWQgdG8gZm9ybSBpbmR1c3RyeSBm b3J1bXMgKFNvZnRTd2l0Y2gpIGFuZCBzdXBwb3J0IGluaXRpYWwgaW1wbGVtZW50YXRpb25zIGJh c2VkIG9uIE1HQ1AsIG1vc3Qgb2YgdGhlIGxhcmdlIHZlbmRvcnMgYXJlIGZ1bGx5IHN1cHBvcnRp bmcgTUVHQUNPIGFuZCBoYXZlIHJvYWRtYXBzIHRvIGRlbGl2ZXIgTUVHQUNPIGluIHRoZSB5ZWFy IDIwMDAuIA1NRUdBQ08gaXMgcG93ZXJmdWwgYW5kIGxlbmRzIGl0c2VsZiB0byBtZWV0aW5nIGFs bCB0aGUgcmVxdWlyZW1lbnRzIG9mIGV4aXN0aW5nIHRlbGVjb20gYXBwbGljYXRpb25zIHdoaWxl IGNyZWF0aW5nIG5ldyBvcHBvcnR1bml0aWVzIGZvciBmdXR1cmlzdGljIG11bHRpLW1lZGlhIGJh c2VkIHNlcnZpY2VzLg1BY2tub3dsZWRnZW1lbnRzDVRoZSBhdXRob3JzIHdpc2ggdG8gYWNrbm93 bGVkZ2UgdGhlIGNvbnRyaWJ1dGlvbiBvZiBOYW5jeSBHcmVlbmUgb2YgTm9ydGVsIE5ldHdvcmtz IGluIHRoZSBtYWtpbmcgb2YgdGhpcyB3aGl0ZSBwYXBlci4gTmFuY3mScyBtYWlsIGluIHRoZSBN RUdBQ08gbWFpbGluZyBsaXN0LCBjaXRpbmcgZGlmZmVyZW5jZXMgYmV0d2VlbiB0aGUgTUdDUCBh bmQgTUVHQUNPIHByb3RvY29scywgcHJvdmlkZWQgc2lnbmlmaWNhbnQgaW5wdXRzIGZvciB0aGlz IHBhcGVyLg1SZWZlcmVuY2VzDVsxXSBNLiBBcmFuZ28sIEEuRHVnYW4sIEkuIEVsbGlvdCwgQy5I dWl0ZW1hLCBTLlBpY2tldHQsIJNNZWRpYSBHYXRld2F5IENvbnRyb2wgUHJvdG9jb2wgKE1HQ1Ap lCwgUkZDIDI3MDUNWzJdIEIuIEhpbGwsIE4uR3JlZW5lLCBDLkh1aXRlbWEsIEEuUmF5aGFuLCBC LlJvc2VuLCBKLlNlZ2Vycywgk2RyYWZ0LWlldGYtbWVnYWNvLXByb3RvY29sLTA1LnR4dJQsIJNX b3JrLWluLXByb2dyZXNzlA1bM10gIE4uR3JlZW5lLCBNLkEuUmFtYWxobywgQi5Sb3Nlbiwgk2Ry YWZ0LWlldGYtbWVnYWNvLXJlcXMtMDgudHh0lA0NCA1Gb3IgIG1vcmUgaW5mb3JtYXRpb246DUh1 Z2hlcyBTb2Z0d2FyZSBTeXN0ZW1zLCBFbGVjdHJvbmljIENpdHksIFBsb3QgTm8uIDMxLCBTZWN0 b3IgMTgsIEd1cmdhb24gljEyMjAxNSwgSGFyeWFuYSAoSU5ESUEpDVBoLiArOTEtMTI0LTM0Mzcw MyAgRmF4OiAgKzkxLTEyNC0zNDI4MTAgIGUtbWFpbDogEyBIWVBFUkxJTksgbWFpbHRvOmluZm9A aHNzd29ybGQuY29tIAEUaW5mb0Boc3N3b3JsZC5jb20VLCB3ZWI6IBMgSFlQRVJMSU5LIGh0dHA6 Ly93d3cuaHNzd29ybGQuY29tIAEUd3d3Lmhzc3dvcmxkLmNvbRUNCAhNRUdBQ08gdnMgTUdDUAkJ CQ0NCCggQ29weXJpZ2h0IEh1Z2hlcyBTb2Z0d2FyZSBTeXN0ZW1zIEx0ZC4sIDE5OTkNQWxsIHJp Z2h0cyByZXNlcnZlZC4gVGhpcyBwdWJsaWNhdGlvbiBhbmQgaXRzIGNvbnRlbnRzIGFyZSBwcm9w cmlldGFyeSB0byBIdWdoZXMgU29mdHdhcmUgU3lzdGVtcyBMdGQuIE5vIHBhcnQgb2YgdGhpcyBw dWJsaWNhdGlvbiBtYXkgYmUgcmVwcm9kdWNlZCBpbiBhbnkgZm9ybSBvciBieSBhbnkgbWVhbnMs IGV4Y2VwdCBmb3IgdGhlIHB1cnBvc2VzIG9mIHRoaXMgcHJvcG9zYWwsIHdpdGhvdXQgdGhlIHdy aXR0ZW4gcGVybWlzc2lvbiBvZiBIdWdoZXMgU29mdHdhcmUgU3lzdGVtcyBMVEQgR3VyZ2Fvbiwg SW5kaWEuIEFsbCB0cmFkZW1hcmtzIGJlbG9uZyB0byB0aGUgcmVzcGVjdGl2ZSBvd25lcnMgDQ0I CE1FR0FDTyB2cyBNR0NQCQkJDQ0IKCBDb3B5cmlnaHQgSHVnaGVzIFNvZnR3YXJlIFN5c3RlbXMg THRkLiwgMTk5OQ1BbGwgcmlnaHRzIHJlc2VydmVkLiBUaGlzIHB1YmxpY2F0aW9uIGFuZCBpdHMg Y29udGVudHMgYXJlIHByb3ByaWV0YXJ5IHRvIEh1Z2hlcyBTb2Z0d2FyZSBTeXN0ZW1zIEx0ZC4g Tm8gcGFydCBvZiB0aGlzIHB1YmxpY2F0aW9uIG1heSBiZSByZXByb2R1Y2VkIGluIGFueSBmb3Jt IG9yIGJ5IGFueSBtZWFucywgZXhjZXB0IGZvciB0aGUgcHVycG9zZXMgb2YgdGhpcyBwcm9wb3Nh bCwgd2l0aG91dCB0aGUgd3JpdHRlbiBwZXJtaXNzaW9uIG9mIEh1Z2hlcyBTb2Z0d2FyZSBTeXN0 ZW1zIExURCBHdXJnYW9uLCBJbmRpYS4gQWxsIHRyYWRlbWFya3MgYmVsb25nIHRvIHRoZSByZXNw ZWN0aXZlIG93bmVycyANDQ0NAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAEE AAA6BAAAsQQAALIEAACzBAAAtAQAALYEAACyBwAAswcAAMsHAADMBwAAzQcAAM4HAADPBwAARgkA AGoJAADLCwAA3QsAAG8NAACFDQAAqA8AAMEPAADjEAAA5BAAAKARAAChEQAAjRIAAI8SAACrEgAA kxUAAKgVAAD0FgAACxcAAHQXAAB1FwAADhgAABAYAAAaGAAAkxgAAJQYAAAHGQAACBkAAL8ZAADB GQAAyhkAANoaAADcGgAA8BoAANEbAAD4GwAAJyAAACkgAABUJwAAWCcAAPnx+eng2dHJxACyq8QA 0aEAnwCfAJ8AnQCdAJ2fAJ8AnwCdAJ2fAJ0AnQCdnwCdnwCh+ZX5iwAAAAASNQiBPioBQ0oUAE9K AABRSgAAAA9DShQASCoBT0oAAFFKAAADNQiBAzYIgRI1CIE+KgFDShgAT0oAAFFKAAAADQNqAAAA AENKFABVCAEjA2qdr7U7CggBQ0oUAE9KAABRSgAAVQgBVggBbUgABG5IAAQJA2oAAAAAVQgBDzYI gUNKEABPSgAAUUoAAA82CIFDShQAT0oAAFFKAAAMQ0oQAE9KAABRSgAAABEDagAAAABVCAFtSAAE bkgABA81CIFDShAAT0oAAFFKAAAPNQiBQ0ocAE9KAABRSgAADENKFABPSgAAUUoAADYABAAAAQQA ADoEAABkBAAAsQQAALIEAAC0BAAAtQQAALYEAAAbBgAAsgcAAM8HAADQBwAARgkAAGoJAADKCwAA ywsAAN0LAAD5AAAAAAAAAAAAAAAA7wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADnAAAAAAAAAAAA AAAA3wAAAAAAAAAAAAAAAOcAAAAAAAAAAAAAAADVAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAAMsA AAAAAAAAAAAAAAC/AAAAAAAAAAAAAAAAtwAAAAAAAAAAAAAAALEAAAAAAAAAAAAAAACxAAAAAAAA AAAAAAAApwAAAAAAAAAAAAAAAKEAAAAAAAAAAAAAAAChAAAAAAAAAAAAAAAAoQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAVUABOkAAAUpAAAChsAE6Q8ABSkPAANxgYC 4BDAIQAABQAAE6Q8ABSkPAAABwAADoRaABOkPAAUpDwAAAsAAA6EWgATpDwAFKQ8AA3GBQABMgoA AAkAABOkPAAUpDwADcYFAAEyCgAACQAADoQcAg+EHAITpDwAFKQ8AAAHGwADJAINxgYC4BDAIQAA BxsAAyQBDcYGAuAQwCEAAAkbAAMkARSkeAANxgYC4BDAIQAGGwANxgYC4BDAIQAAEQAEAAABBAAA OgQAAGQEAACxBAAAsgQAALQEAAC1BAAAtgQAABsGAACyBwAAzwcAANAHAABGCQAAagkAAMoLAADL CwAA3QsAAGsMAAAfDQAAbg0AAG8NAACFDQAAWg4AACoPAACnDwAAqA8AAMEPAADkEAAAoREAAI4S AACPEgAAqxIAAFgTAADFEwAANBUAAJIVAACTFQAAqBUAAIoWAADzFgAA9BYAAAsXAAB1FwAADxgA ABAYAAAaGAAACBkAAMAZAADBGQAAyhkAAP39/f39/QD7AAD5AAD99/f38uvk9/ff2NH398zFvvf3 ubKrpPf3n5j395OM9/eHgPf3AAANAlQACL4DCQEKAQAAAAgCVAAIvgMJAQANAlQACLwDCQEKAQAA AAgCVAAIvAMJAQANAlQACLsDCQEKAQAAAAgCVAAIuwMJAQANAlQACLoDCQEKAwAAAA0CVAAIugMJ AQoCAAAADQJUAAi6AwkBCgEAAAAIAlQACLoDCQEADQJUAAi5AwkBCgIAAAANAlQACLkDCQEKAQAA AAgCVAAIuQMJAQANAlQACLgDCQEKAgAAAA0CVAAIuAMJAQoBAAAACAJUAAi4AwkBAA0CVAAItQMJ AQoCAAAADQJUAAi1AwkBCgEAAAAIAlQACLUDCQEAAwJUAAIJAgACCQMAAwIbAAAy3QsAAGsMAAAf DQAAbg0AAG8NAACFDQAAWg4AACoPAACnDwAAqA8AAMEPAADkEAAAoREAAI4SAACPEgAAqxIAAFgT AADFEwAANBUAAJIVAACTFQAAqBUAAO8AAAAAAAAAAAAAAADvAAAAAAAAAAAAAAAA7wAAAAAAAAAA AAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA2QAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADZ AAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADJAAAAAAAAAAAAAAAAyQAAAAAA AAAAAAAAAMkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAALkAAAAAAAAAAAAA AAC5AAAAAAAAAAAAAAAAuQAAAAAAAAAAAAAAALkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAA AAAAAAAAAAAAAAAAAAAAAAAAABBUAAomAAtGugMPhDgEE6QAABSkAAANxgcBaAEBOAQGEFQACiYA C0a5Aw+EOAQTpAAAFKQAAA3GBwFoAQE4BAYQVAAKJgALRrgDD4Q4BBOkAAAUpAAADcYHAWgBASoD BgAFVAATpAAAFKQAABBUAAomAAtGtQMPhDgEE6QAABSkAAANxgcBaAEBOAQGABWoFQAAihYAAPMW AAD0FgAACxcAAHUXAAAPGAAAEBgAABoYAAAIGQAAwBkAAMEZAADKGQAA2xoAANwaAADwGgAA0BsA ANEbAAD4GwAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAA6QAAAAAAAAAA AAAAANkAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA6QAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADJ AAAAAAAAAAAAAAAAyQAAAAAAAAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAAuQAAAAAA AAAAAAAAAOkAAAAAAAAAAAAAAADpAAAAAAAAAAAAAAAAqQAAAAAAAAAAAAAAAOkAAAAAAAAAAAAA AACfAAAAAAAAAAAAAAAAAAAAAAAAAAAKGwATpDwAFKQ8AA3GBgLgEMAhABBUAAomAAtGwAMPhDgE E6QAABSkAAANxgcBaAEBOAQGEFQACiYAC0a/Aw+EOAQTpAAAFKQAAA3GBwFoAQE4BAYQVAAKJgAL Rr4DD4Q4BBOkAAAUpAAADcYHAWgBATgEBhBUAAomAAtGvAMPhDgEE6QAABSkAAANxgcBaAEBOAQG AAVUABOkAAAUpAAAEFQACiYAC0a7Aw+EOAQTpAAAFKQAAA3GBwFoAQE4BAYAEsoZAADbGgAA3BoA APAaAADQGwAA0RsAAPgbAAAgHgAAxh4AAKwfAAC5IAAATCEAAPohAAARIwAAkyMAALskAABUJwAA VScAAFYnAABXJwAAWCcAAHcnAABQKAAAYyoAADcrAADOKwAATiwAALcsAACNLQAAGC4AAJwuAAC+ LwAARjAAAG0wAABaMQAAajEAAHsyAAD2MgAA0zMAAGI0AABcNgAAyTYAAKs3AAD7+fn0+fIA7ebf 2NHMxb63AAAAAAAAtK6oopyWkIqEfgAAfHp3dHH5AG4AAAAAAAAFCK0DCQEFCLADCQEFCK8DCQEF CJwDCQEDAjkAAwIhAAoIxAMJAQoJAAAAAAoIxAMJAQoIAAAAAAoIxAMJAQoHAAAAAAoIxAMJAQoG AAAAAAoIxAMJAQoFAAAAAAoIxAMJAQoEAAAAAAoIxAMJAQoDAAAAAAoIxAMJAQoCAAAAAAoIxAMJ AQoBAAAAAAUIxAMJAQ0CGwAIZgMJAQoDAAAADQIbAAhmAwkBCgIAAAANAhsACGYDCQEKAQAAAAgC GwAIZgMJAQANAhsACGUDCQEKBAAAAA0CGwAIZQMJAQoDAAAADQIbAAhlAwkBCgIAAAANAhsACGUD CQEKAQAAAAgCGwAIZQMJAQADAhsACAJUAAjAAwkBAAMCVAAIAlQACL8DCQEq+BsAACAeAADGHgAA rB8AALkgAABMIQAA+iEAABEjAACTIwAAuyQAAFQnAABVJwAAVicAAFcnAABYJwAAdycAAFAoAABj KgAANysAAM4rAABOLAAAtywAAI0tAAD5AAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAA AAAAAADrAAAAAAAAAAAAAAAA6wAAAAAAAAAAAAAAAOsAAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA 3QAAAAAAAAAAAAAAAN0AAAAAAAAAAAAAAADdAAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAAPkAAAAA AAAAAAAAAAD5AAAAAAAAAAAAAAAA+QAAAAAAAAAAAAAAANQAAAAAAAAAAAAAAADNAAAAAAAAAAAA AAAAwgAAAAAAAAAAAAAAAMIAAAAAAAAAAAAAAADCAAAAAAAAAAAAAAAAwgAAAAAAAAAAAAAAAMIA AAAAAAAAAAAAAADCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAADJAAKJgALRsQDE6Q8ABSkPAAH AAADJAATpDwAFKQ8AAAIAAADJAAHJAETpDwAFKQ8AAANGwAKJgALRmYDE6Q8ABSkPAANxgYC4BDA IQAADRsACiYAC0ZlAxOkPAAUpDwADcYGAuAQwCEAAAUAABOkPAAUpDwAABZYJwAAdScAAHcnAABi KgAAYyoAADYrAAA3KwAAzSsAAM4rAABNLAAATiwAALYsAAC3LAAAjC0AAI0tAAAXLgAAGC4AAJsu AACcLgAAvS8AAL4vAABEMAAARTAAAG0wAABZMQAAWjEAAGoxAAB7MgAAYjQAAFw2AAC9QAAA0UAA AGZBAABvQQAAPEIAAFtCAAAgQwAAIUMAAOhDAADpQwAAkUQAAJ5EAACfRAAAoEQAABtGAAAgRgAA okwAAKRMAAC7TAAAvEwAAL1MAACSTgAAk04AALJOAAAlUgAAJ1IAAEZSAABHUgAAWVUAAFpVAAB0 VQAAdVUAANZXAADfVwAA4VcAAOJYAAD27OX25fbl9uX25fbl9uX25fbl9uXs9uXd1dDlAOXV0Mjl 3eXQ5QDl0MLd5d3l3biwrOXQuOXQuLDlpris5biw5QAAAAo1CIE+KgFDShQAAAc2CIFDShQADzYI gUNKFABPSgAAUUoAABI1CIE2CIFDShQAT0oAAFFKAAAACzUIgU9KAABRSgAADjUIgTYIgU9KAABR SgAAAAhPSgAAUUoAAAAPNQiBQ0oYAE9KAABRSgAADzUIgUNKFABPSgAAUUoAAAxDShQAT0oAAFFK AAAAEjUIgT4qAUNKFABPSgAAUUoAAAASNQiBPioBQ0oYAE9KAABRSgAAQY0tAAAYLgAAnC4AAL4v AABGMAAAbTAAAFoxAABqMQAAezIAAPYyAADTMwAAYjQAAFw2AADJNgAAqzcAAKk4AACmOQAA9AAA AAAAAAAAAAAAAPQAAAAAAAAAAAAAAAD0AAAAAAAAAAAAAAAA9AAAAAAAAAAAAAAAAO0AAAAAAAAA AAAAAADnAAAAAAAAAAAAAAAA3QAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADOAAAAAAAAAAAAAAAA vgAAAAAAAAAAAAAAAK4AAAAAAAAAAAAAAACqAAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAJIAAAAA AAAAAAAAAACSAAAAAAAAAAAAAAAAogAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQAAAKJgAL Rq0DD4TQAhOkPAAUpDwADcYHAWgBAdACBgAHAAAPhGgBE6Q8ABSkPAAAA1QAD4RoARAAAAomAAtG sAMPhNACE6Q8ABSkPAANxgcBaAEB0AIGEAAACiYAC0avAw+E0AITpDwAFKQ8AA3GBwFoAQHQAgYJ AAAKJgALRpwDE6Q8ABSkPAAABTkAE6Q8ABSkPAAACSEAD4QAABGEAAATpDwAFKQ8AAAFAAATpDwA FKQ8AAcAAAMkABOkPAAUpDwAAAoAAAMkAAomAAtGxAMTpDwAFKQ8AAAQqzcAAKk4AACmOQAA3jsA AK08AACjPwAAvUAAANFAAABlQQAAZkEAAG9BAAA7QgAAPEIAAExCAABaQgAAW0IAAI1CAACOQgAA xkIAAMdCAAAgQwAAIUMAACJDAAB6QwAAe0MAAIJDAACDQwAAwEMAAMFDAADHQwAAyEMAAOlDAAD7 QwAA/EMAAA5EAAAPRAAAIUQAADZEAABNRAAATkQAAGJEAABjRAAAZEQAAGtEAABsRAAAekQAAIpE AACLRAAAkEQAAJFEAACfRAAAoEQAAKFEAAByRQAAxkUAAIVGAAAkRwAApUcAAKJJAABCSgAAHUsA APJLAACjTAAApEwAAL1MAABvTQAA+gAA9ADuAOzs7Ofl4eHf3Nzc3NzY3Nzc3Nzc3Nzc3Nzc3Nzc 3Nzc3Nzc3Nzc3Nzc3Njf5dLNyMHlu7Su5eXlrKYAAAAKCKADCQEKBgAAAAACCQIACgigAwkBCgUA AAAADQIhAAigAwkBCgQAAAAKCKADCQEKAwAAAAANAiEACKADCQEKAgAAAAgCIQAIswMJAQAIAiEA CJMDCQEACgigAwkBCgEAAAAABwI5AAMBBQoEAwEFCgACAwEABwIhAAMBBQoDAiEACAIhAAigAwkB AAMCOQAKCJwDCQEKAgAAAAAKCJwDCQEKAQAAAAAKCK0DCQEKAQAAAEGmOQAA3jsAAK08AACjPwAA vUAAANFAAABlQQAAZkEAAG9BAAA7QgAAPEIAAExCAABaQgAAW0IAAI1CAACOQgAAxkIAAMdCAAAg QwAAIUMAAPcAAAAAAAAAAAAAAADuAAAAAAAAAAAAAAAA9wAAAAAAAAAAAAAAAO4AAAAAAAAAAAAA AADoAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAOIAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA2QAA AAAAAAAAAAAAAM8AAAAAAAAAAAAAAADEAAAAAAAAAAAAAAAAxAAAAAAAAAAAAAAAAKoUCQAAAAAA AAAAAACnAAAAAAAAAAAAAAAApwAAAAAAAAAAAAAAAKcAAAAAAAAAAAAAAACnAAAAAAAAAAAAAAAA pwAAAAAAAAAAAAAAAKQAAAAAAAAAAAAAAAAAAzkAFiQBAwAAFiQBABkAABYkARckAQKWbAAF1hgE AQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1ggAAtACJhYMIQshAA+EAAARhAAAE6Q8ABSkPAAWJAEA CSEAD4QAABGEAAATpDwAFKQ8AAkhAAomAAtGoAMTpDwAFKQ8AAAFOQATpDwAFKQ8AAAFAAATpDwA FKQ8AAkAAAomAAtGnAMTpDwAFKQ8AAAHAAAPhGgBE6Q8ABSkPAAAEyFDAAAiQwAAekMAAHtDAACC QwAAg0MAAMBDAADBQwAAx0MAAMhDAADpQwAA+0MAAPxDAAAORAAAD0QAACFEAAA2RAAATUQAAE5E AABiRAAAY0QAAGREAABrRAAAbEQAAHpEAACKRAAAi0QAAJBEAACRRAAAn0QAAPwAAAAAAAAAAAAA AAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAA AAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAA AAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA /AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAA AAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAA AAAA/AAAAAAAAAAAAAAAAPwAAAAAAAAAAAAAAAD8AAAAAAAAAAAAAAAA/AAAAAAAAAAAAAAAAPwA AAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAAAM5ABYkAQMAABYkAQAdn0QAAKBEAAChRAAAckUAAMZF AACFRgAAJEcAAKVHAACiSQAAQkoAAB1LAADySwAAo0wAAKRMAAC9TAAAb00AAJJOAACTTgAA5QAA AAAAAAAAAAAAANsAAAAAAAAAAAAAAADSAAAAAAAAAAAAAAAAwgAAAAAAAAAAAAAAALIAAAAAAAAA AAAAAACpAAAAAAAAAAAAAAAAoQAAAAAAAAAAAAAAAJwAAAAAAAAAAAAAAACpAAAAAAAAAAAAAAAA 0gAAAAAAAAAAAAAAAKEAAAAAAAAAAAAAAAChAAAAAAAAAAAAAAAAoQAAAAAAAAAAAAAAAJkAAAAA AAAAAAAAAADSAAAAAAAAAAAAAAAA0gAAAAAAAAAAAAAAAJMAAAAAAAAAAAAAAAAAAAU5ABOkPAAU pDwAAwAAAyQABQAACiYAC0agAwAHIQARhAAAE6Q8ABSkPAAJIQAKJgALRqADE6Q8ABSkPAAQIQAK JgALRrMDD4TQAhOkPAAUpDwADcYHAWgBAdACBhAhAAomAAtGkwMPhNACE6Q8ABSkPAANxgcBaAEB 0AIGCQAACiYAC0agAxOkPAAUpDwAAAkhAA+EAAARhAAAE6Q8ABSkPAAAGQAAFiQBFyQBApZsAAXW GAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWCAAC0AImFgwhABFvTQAAkk4AAJNOAACyTgAAFlAA AHFQAAAlUgAAJ1IAAEdSAADAUgAAkFMAAFlVAABaVQAAdVUAADFWAABWVwAA1VcAANZXAADhVwAA 4VgAAOJYAAD/WAAAl1oAAPhaAADiWwAAYVwAALBdAABCXgAAu18AADhhAADJYQAAymEAAO1hAADu YQAA92EAAABiAAAVYgAAFmIAACBiAAAhYgAAN2IAAEBiAABVYgAAYGIAALdiAAAeYwAAH2MAACBj AAAhYwAAN2MAAMZjAACuZAAAr2QAALBkAACxZAAAD2UAABBlAAAdZQAAKGUAAC5lAAA6ZQAAZmUA AL5lAADvZQAA8GUAAPFlAAD6+ADyAOz4AOXj3AAA1tAAAADKAADHAMcAxMTHx8fCwsK+vr68vr6+ vr61vr68vr61vr68vq2mvL6+vr6+vr68wgAAAAwCGwADAQUKCFQDCQEADgIbAAMBBQoIVAMJAQwB AAwCGwADAQUKCFEDCQEAAgMBAAcCGwADAQUKAwIbAAUItAMJAQUImwMJAQoIoAMJAQoOAAAAAAoI oAMJAQoNAAAAAAoIoAMJAQoMAAAAAA0CIQAIoAMJAQoLAAAAAwIhAA0CIQAIoAMJAQoKAAAACgig AwkBCgkAAAAACgigAwkBCggAAAAAAwI5AAoIoAMJAQoHAAAAQZNOAACyTgAAFlAAAHFQAAAlUgAA J1IAAEdSAADAUgAAkFMAAFlVAABaVQAAdVUAADFWAABWVwAA1VcAANZXAADhVwAA4VgAAOJYAAD/ WAAAl1oAAPhaAAD5AAAAAAAAAAAAAAAA8AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAADwAAAAAAAA AAAAAAAA4gAAAAAAAAAAAAAAAPkAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA0QAAAAAAAAAAAAAA ANkAAAAAAAAAAAAAAADPAAAAAAAAAAAAAAAAzwAAAAAAAAAAAAAAAPAAAAAAAAAAAAAAAADwAAAA AAAAAAAAAAAA6AAAAAAAAAAAAAAAAOgAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAA8AAAAAAAAAAA AAAAAPkAAAAAAAAAAAAAAAD5AAAAAAAAAAAAAAAAvwAAAAAAAAAAAAAAALcAAAAAAAAAAAAAAAAA AAAAAAAHAAAPhNACE6Q8ABSkPAAQAAAKJgALRpsDD4TQAhOkPAAUpDwADcYHAWgBAdACBgABAAAA ByEAEYQAABOkPAAUpDwACSEACiYAC0agAxOkPAAUpDwAAAU5ABOkPAAUpDwAAAcAAA+EaAETpDwA FKQ8AAkAAAomAAtGoAMTpDwAFKQ8AAAFAAATpDwAFKQ8AAAV4lgAAP9YAADJYQAA7WEAAO5hAAAV YgAAFmIAACBiAAAeYwAAH2MAACBjAABmYwAAxGMAAK5kAACvZAAAsWQAAA5lAAAPZQAAEGUAAC5l AAA3ZQAAOWUAAGJlAABjZQAAZGUAAGVlAADvZQAA8GUAAPNlAAAXZgAAGWYAAHJmAABLaAAATWgA AFFoAABSaAAAV2gAAGVoAABOaQAAWGkAAJhrAACiawAAo2sAAKRrAAAHbQAAEW0AAJJuAACcbgAA gHAAAJFwAACXcQAAonEAAMlyAADKcgAAy3IAAMxyAAD38Pfm3tTezdTezcPN1LnNudTezbHNsc2x zdSxzbHN8ADmqeal8J3wnfCd8J3wnfDm8OaY8I/wAAAAAAAAABEDagAAAABVCAFtSAAEbkgABAhP SgAAUUoAAAAPPioBQ0oUAE9KAABRSgAABjUIgT4qAQAPPioBQ0oYAE9KAABRSgAAD0NKEABIKgFP SgAAUUoAABI1CIE+KgFDShAAT0oAAFFKAAAAEjUIgTYIgUNKEABPSgAAUUoAAAAMQ0oQAE9KAABR SgAAABI1CIE+KgFDShQAT0oAAFFKAAAADzUIgUNKEABPSgAAUUoAABI1CIE+KgFDShgAT0oAAFFK AAAADENKFABPSgAAUUoAAAAPNQiBQ0oYAE9KAABRSgAAADf4WgAA4lsAAGFcAACwXQAAQl4AALtf AAA4YQAAyWEAAMphAADtYQAA7mEAAPdhAAAAYgAAFWIAABZiAAAgYgAAIWIAADdiAABAYgAAVWIA AO8AAAAAAAAAAAAAAADnAAAAAAAAAAAAAAAA1wAAAAAAAAAAAAAAANcAAAAAAAAAAAAAAADvAAAA AAAAAAAAAAAA7wAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADNAAAAAAAAAAAAAAAAzQAAAAAAAAAA AAAAAM0AAAAAAAAAAAAAAADBAAAAAAAAAAAAAAAAwQAAAAAAAAAAAAAAAMEAAAAAAAAAAAAAAACm JAQAAAAAAAAAAAAAwQAAAAAAAAAAAAAAAMEAAAAAAAAAAAAAAADBAAAAAAAAAAAAAAAAwQAAAAAA AAAAAAAAAMEAAAAAAAAAAAAAAAAAAAAAAAAaAAAWJAEXJAEClmwABdYYBAEAAAQBAAAEAQAABAEA AAQBAAAEAQAACNYKAAMAAEYFAg3AIQALGwATpBQAFKQUABYkAQ3GBgLgEMAhAAobABOkPAAUpHgA DcYGAuAQwCEAEAAACiYAC0a0Aw+E0AITpDwAFKQ8AA3GBwFoAQHQAgYABwAAD4TQAhOkPAAUpDwA EAAACiYAC0abAw+E0AITpDwAFKQ8AA3GBwFoAQHQAgYAE1ViAABgYgAAt2IAAB5jAAAfYwAAIGMA ACFjAAA3YwAAxmMAAK5kAACvZAAAsGQAAPAAAAAAAAAAAAAAAADiAAAAAAAAAAAAAAAA4gAAAAAA AAAAAAAAALJABgAAAAAAAAAAAACmAAAAAAAAAAAAAAAA4gAAAAAAAAAAAAAAAPAAAAAAAAAAAAAA AACYAAAAAAAAAAAAAAAAmAAAAAAAAAAAAAAAAGiEAQAAAAAAAAAAAACmAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAwAAAWJAEXJAEClmwAAzQBBdYYBAEAAAQBAAAEAQAABAEAAAQBAAAEAQAA CNYyAAMAAEYFAg3AISAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAADRsA D4RWAROkFAAUpBQAFiQBDcYGAuAQwCEAAAsbABOkFAAUpBQAFiQBDcYGAuAQwCEAMAAAFiQBFyQB ApZsAAM0AQXWGAQBAAAEAQAABAEAAAQBAAAEAQAABAEAAAjWMgADAABGBQINwCFgAAAAAAAAAAAA AAAAAAAAAAAAAGAAAAAAAAAAAAAAAAAAAAAAAAAAAA0bAA+EaAETpBQAFKQUABYkAQ3GBgLgEMAh AA8bAAomAAtGUQMTpBQAFKQUABYkAQ3GBgLgEMAhAAALsGQAALFkAAAPZQAAEGUAAB1lAAAoZQAA LmUAADplAABmZQAAvmUAAO9lAADwZQAA8WUAABdmAAByZgAAc2YAAEtoAADwAAAAAAAAAAAAAAAA 8AAAAAAAAAAAAAAAAMCAAwAAAAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAA AAAAAAAAAAC0AAAAAAAAAAAAAAAAtAAAAAAAAAAAAAAAALQAAAAAAAAAAAAAAAC0AAAAAAAAAAAA AAAAmQAAAAAAAAAAAAAAAJEAAAAAAAAAAAAAAACRAAAAAAAAAAAAAAAAkQAAAAAAAAAAAAAAAIsA AAAAAAAAAAAAAACLAAAAAAAAAAAAAAAAAAAABQAAE6Q8ABSkPAAIGwAPhKAFDcYGAuAQwCEAABoA ABYkARckAQKWbAAF1hgEAQAABAEAAAQBAAAEAQAABAEAAAQBAAAI1goAAwAARgUCDcAhAAsbABOk FAAUpBQAFiQBDcYGAuAQwCEAMAAAFiQBFyQBApZsAAM0AQXWGAQBAAAEAQAABAEAAAQBAAAEAQAA BAEAAAjWMgADAABGBQINwCEgAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAA DxsACiYAC0ZUAxOkFAAUpBQAFiQBDcYGAuAQwCEAABDxZQAAF2YAAHJmAABzZgAAS2gAAE1oAABl aAAATmkAANtpAAA9awAAmGsAAKNsAAAHbQAAnG0AAEluAACSbgAAz28AAIBwAACRcAAAl3EAAKJx AAANcgAAhHIAAMlyAADKcgAAzHIAAONyAABGcwAA8HMAAJB1AACkdQAApXUAANV1AAAvdwAAMHcA ADF3AAAydwAA/f0AAAAA+P34/f3z/f3u/f39/f3s7Oz9/f39/er96gDo6ur9AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMCHAACAQEAAwI5AAgCGwAI lwMJAQAIAhsACFoDCQEACAIbAAhYAwkBAAMCGwAAJEtoAABNaAAAZWgAAE5pAADbaQAAPWsAAJhr AACjbAAAB20AAJxtAABJbgAAkm4AAM9vAACAcAAAkXAAAJdxAACicQAADXIAAIRyAADJcgAAynIA AMxyAAD9AAAAAAAAAAAAAAAA/QAAAAAAAAAAAAAAAO8AAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA 7wAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAADjAAAAAAAAAAAAAAAA1QAAAAAAAAAAAAAAAOMAAAAA AAAAAAAAAADjAAAAAAAAAAAAAAAAxwAAAAAAAAAAAAAAAOMAAAAAAAAAAAAAAAC9AAAAAAAAAAAA AAAAvQAAAAAAAAAAAAAAAL0AAAAAAAAAAAAAAAC9AAAAAAAAAAAAAAAAuwAAAAAAAAAAAAAAALsA AAAAAAAAAAAAAAC7AAAAAAAAAAAAAAAAvQAAAAAAAAAAAAAAAL0AAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAE5AAobABOkPAAUpDwADcYGAuAQwCEAAA0bAAomAAtGlwMTpDwAFKQ8AA3GBgLgEMAh AAANGwAKJgALRloDE6Q8ABSkPAANxgYC4BDAIQAMGwAPhGgBE6Q8ABSkPAANxgYC4BDAIQAADRsA CiYAC0ZYAxOkPAAUpDwADcYGAuAQwCEAAAEAAAAVzHIAAONyAABGcwAA8HMAAAR0AAAFdAAANXQA AI91AACQdQAApHUAAKV1AADVdQAAL3cAADB3AAAxdwAAMncAAPUAAAAAAAAAAAAAAADtAAAAAAAA AAAAAAAA4wAAAAAAAAAAAAAAANsAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA1gAAAAAAAAAAAAAA ANQAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA2wAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADWAAAA AAAAAAAAAAAA1AAAAAAAAAAAAAAAANkAAAAAAAAAAAAAAADZAAAAAAAAAAAAAAAA4wAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAB HAADAAADJAEAAQAACBsADcYKAeAQAhAOgBYBAAAJGwADJAERhNACDcYGAuAQwCEAAAcbAAMkAQ3G BgLgEMAhAAAJGwADJAEUpDwADcYGAuAQwCEAAA/McgAA43IAAHhzAAB5cwAAnXMAAJ5zAACfcwAA sHMAALFzAAC4cwAAuXMAANxzAADdcwAA3nMAAO5zAADvcwAA8HMAAPJzAAAEdAAABXQAAAZ0AAAH dAAACHQAADR0AAA1dAAAjXUAAI51AACQdQAAknUAAKR1AACldQAApnUAAKd1AACodQAA1HUAANV1 AAAtdwAALncAAC93AAAxdwAAMncAAPfw5fDX5c7l8OXwwOXO5fC1rwC1qKSepJqXALWvALWopJ6k mpORAPAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANCKg8HQioPbUgABARtSAAEAAdCKg9D ShAACjUIgUIqD0NKEAAAB0IqD0NKHAANCWoBANPwQioPQ0ocAAo1CIFCKg9DSiAAABQDagAAAABC Kg9VCAFtSAAEbkgABAAbAgiBA2p+EQAABggBQ0oUAE9KAABRSgAAVQgBEDBKSABDShAAT0oAAFFK AAAAGwIIgQNqshAAAAYIAUNKFABPSgAAUUoAAFUIARUDagAAAABDShAAT0oAAFFKAABVCAEMQ0oQ AE9KAABRSgAAAA8+KgFDShAAT0oAAFFKAAAAKPcAHFABAB+w0C8gsOA9IbAIByKwCAcjkKAFJJCg BSWwAAAC0tQAAAEIAAABgAAAAQBoAQAABAABCAAAAYAAAAEAaAEAAAIAAQgAAAGAAAABAGgBAAAE AAEIAAABgAAAAQDQAgAAAAEBCAAAAYAAAAEA0AIAAAQBAQgAAAGAAAABANACAAACAQEIAAABgAAA AQDQAgAABAEBCAAAAYAAAAEA0AIAAAIBAQgAAAGAAAABANACAAAAAAAALgAuACkAKQAoACkAKAAp ACgAKQAoACkAKAApAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADkACTAAHFAB AB+w0C8gsOA9IbAIByKwCAcjkKAFJJCgBSWwAAALUAEABTAAA/IAHg8E8gDQAgPyAdIPIwAJMAAc UAEAH7DQLyCw4D0hsAgHIrAIByOQoAUkkKAFJbAAACMACTAAHFABAB+w0C8gsOA9IbAIByKwCAcj kKAFJJCgBSWwAABAPRrwNhQAAON85VC9PDX2Fa2ZEc6BISJASgEAAAAAAAAAAAB/AgAA6QAAAF3e XAB5vyEABBQAAAD+eJztXb+PHEd27tVZHB2547sVz8YZcCAJPljAScDh+nIf7mgJ5x+AHUhy5sDG /AsyuAkJOFBwgaFIk1DJMZEdOCATbsJNxKRjR5bhyAYcCAZsGBMQaL/uru6u7no/q6unh2S/2m93 puvVq/fqzeuvqncpnWVZ9reA/ynLssI/vJZl/5f18i9/k2Uf/kGWvfXHf/5Blp1lP/+Ts+w9uP6d bChvwYW/grE/P8uy/x713QR8H/CgmgfwXff+70H/v+DnDwDngC0AJsneBfw+4MM7v/olqGRfAv4X 8DbM8a9njc23AW8AfteNreSH3uvfc68hpOzCva70b7m574Hh/3DXq/evObS+ttL6+u8w7z/Bzx/1 c9xrX2/gtTRu3N+OfR3G/lnW5KD14T58+09Pt7Xx9mBl7/0R/hqXP3Tr45avXhffj+r677jXVW7/ EnD44Iz0aezbXwDe/a0s+zvAvV80s7yVFV3/u57uWZ2JXq8W9zIH7AB7QOEu5IAdYA8oAKVTygE7 wB5QAEo3MAfsAHtAASidsRywA+wBBaCsrsEy7AB7QFE2E1ZtB9gDCkDpnMgBO8AeUABK51gO2AH2 gAJQOmdzwA6wBxSA0gWQA3aAPaAAlC6oHLAD7AEFoHSBVt5UbQ8oAKULPgfsAHtAASjdguSAHWAP KAClW6QcsAPsAQWgdAuXA3aAPaAAlG4xc8AOsAcUgNItcF57sq9bASjdoueAHWAPKAClS0QO2AH2 gAJQuuTkgB1gDygApUtYDtgB9oACULok5oAdYA8oAKVLbF6vSlF7U7XSJTsH7AB7QAEo3QcgB+wA e0ABKN2HIgfsAHtAASjdByUH7AB7QAEo3YcnB+wAe0ABKMvm07KrV6SsPak+YDlgB9gDCkDpPnQ5 YAfYAwpA6T6IOWAH2AMKQOk+nDlgB9gDCkBZXYM63gH2gKKu6Yv2K7u4qL6/035l77xTfb/TfmV3 7lTfP2q/so8+qr5/2n5ln35aff+s/co++6z6/lX7lX31VfX9qv3Krq6q79+0X9k331Tfv22/sm+/ /ba597hvpXtRujdlA1YOvTCd6HXWJGkseI1aHL713+EjuSiwgEj/EoyhPerejlaCGs7GohJ2bciu FzS/giJ6NWIM7VH39jB8ZZjQJuzi0F383ETnwE5gYXQBeUeMZENgo1X5HTFm7BES1WH4yjChTWhX +JnYqQnHBnYCm9RKBJ34QM2CsMFSficd0709DF8ZnLRJsOJoXzgTOzPh18BhwuRh8A7tGw/Ur4en gOrS12xj7PnFP+dp82uaiZ+az6+/WGQBY52EdfUqcMFqrhnzS7pQDsJnlmF6goN1U84Uk99BTsP8 Dm3OnV+aOKePmZ5f0Y5WBgYsM8n55W/QB//NsPtA9uHWJ+QXS+b0McnqVx8aJZz7XO4n5fdQovnl thZifjWroMsVkz/tGHp1Wm0vRDG/0xiYdpWdiZ05fX79VYjOr+ijZGl6ftuecX6JSZPmd7yo8flV bLDqH1KCcYtcn1rCGWRL6BjaDneD9mMUPgyJ8hsu6vBtyvwe2PyiFvouNvdKwT5BUlTsGLUdQ36p CSPkcECMIfmld0OYPXSWcpxfPFN4fvEJWVe00XodpjFMfslF9Zci/JQL89mFXbehEhkCZhGdhw2t Hyfk8BDYVa8Ho0pa4MyzloIxB2IRDvRwIR5R+HWjwmAXlVkJ/qPbXcB7GD+VC8IqUh2scXHEIfyg hrdpOiAuGo3QtobXRgr8mtLLN6ReNPoDZmA0X2wBs2rsOpC2yfjRUYcwfC4eLhad0LaGV0cq/JrS 9oS9RXuBiNmbGQ1BWhNeCe+VDJPxowOHKaVVpEjUIsVLhcE6wCU9yC9WwEx+Q4/1i8EuHJeRyFjZ SUo+v5p4FCIGTOjFxxwEGCqF4/0rU/PLdpqXOza/oyljwtHIpPzyCSauafNLW5wzv+ZPjy2/I5I/ bn7HhufJr3/HC61gEat8EeIMBgaTED6xY9hY+QIeviNWdnqqxfxKyyFaDQb4Idnyy92gpUDHmuSy MtaT53f8Voo0QjQhYzMlzC+eYNoi5ycvniZtZNTDjBEu0h5w+RU/UDbh3BfzoDCKDDiM5wyHcisW 9Fvzi0Yk5JdYBfYi48GIa6hwEuTX38TRiy12Bf4Gg/AE0YYFN8PPIeqmOljaJ3IMHas4D5dfNiN2 YY3RfYQTYcyDHl/He40Z5t3U+GKK1n8/6qPG0LHq84uFq49GJaw1uksZGZJfYYsoOzLu5vrYaMeX sTfSGNUqhIOo9+FoLhqdcMbILmVkqvxi0bHTsa7wK4LrYUFIYww36HAMH642GLVwphJOcxoSs3Ap F1s/4RHnW2WVVVZZZZVVVllllVVWWWWVVVZZZZVVVllllVVWWWWVVVZZZZVVVlllFU/Ob7Wtk6Vd WkUp57e99maNUbtVI2gXg5a37X1ADt8Bn+RLB/eqyfb2dnte49zHeYc3h4A0DlFVsFfFnVwA8ibN NwHvQYIb5Pl7n/wU2seuLb0CL5vc3jLtvAZSwWgVIxX85rh6b3XVm39SA5onl9DuV7is292HSy/P CylQn1sOQTuvMZJbNQYNr10nN6GGb7r6vQmV2zWo3kENX7btbtPuAx7e/fLu0st24rL15PYA2tq9 jdUtwcAXAwYe1O/7Dfs2DFy3n0Lpftzg8uP7FS4hrVC/dQ1fPmzw5cMHFZ49fPZg6bU8HdlsleKl fMS+W5p9Awa+VWNcxRcdA+cNA7/fM3BYvX0F3/eq92HVHjTtWY26Lb2+C4mQQlUjK9jCvgED5z4D fzJg4EtAzb5VY6rX4TfPnj37usPSK34c2d7YbhBIjMsy8DnNwEGj2fdWzb4XLfveHLHve1j9Xg7q 98uufh/29fvg2VMf1y/prXuzrdq2g+F2bN89pzv/dvX7cYvLEQN39RvWsF+/T2tcOzy9fnq9dEYS CVatfdVGpHvh86+iep/51fsbwNfDCq5w3eCL6ydLJyhWmor1myKd0xn4yOffvnLvNpU7qN4hA/sV fH391GtPXqg0b270bbvZ0PXb17GNgU/0/IuyL8LAXe3W9dvi6ourJ0++WDp3gkA6Nw2Iprwlv+jn X5SBvdp95tduXb9Vu6oBbek0YgJZveFjuxGrV82+AQO/OOffhn2/RtnXMXCfXqjgFo+uHp3OPZuu 1yOz7wmff8d76Gusgts01+1RjUfLpvbGhmlbPQO/MuffUe12uHIMDPgcatfh0eePGiyS3I5tMcSz r7KWreffxMFPPP8SDHzl12/XHtd4fMwsuxrd4FCw71zn3yOuASGm82/LwFc+A1fs6/CoxuMGzyvM H4CGb4/EwPMHm0TE86+2gusGaX48m6ss4wYMnPz8O1tcxxXi/Fuzr8fAT3oGrvDrGs9bpC/l/tbL MG/q82/yKE5ORudftHav+tp93rd/fp6ukvEajWdgNtXJvH7xJGDgxz4DP/fxHBLcYOqkmuqczr4p luelEr+KHw8Z2KvhtkVPY+HciPNvwgV5ieXzIfvWDPzr5wHshoNbrsS+2vNv+jV4ReQ5Vr1eM5ji azSOfWeL+xWUjoEDaEbX6epkMgPPHewrLfZKPovjXeT8e6QQV6lFx8jcbVfPvkcNbJWhcHtrZY0y DLxAQKvgEiS4T1UM+y4TxCpa2VTM28LYlvZ9FVGkQw/Fukv7vYpKDFXbp39pp1dRSli5IgMv7fIq ejnbnJnYd2l/VzEJeeBBGXhpb1cximHPvLSrq9gFq1qUfZd2dJUo2Zx1jWPgpd1cJU5o5vXYd2kn V4kVzb55aR9XiReqcjtZ2sFVpsiZwL5L+7fKNIF0Muy7pvcFl0Hlrrz70gn16/qVeV8O2ZxtKAZe 2rVVEsgZUb/HT+8sv1Me/q46ldXjied/pIFT2DcTm7s5bE62ezzBfI8wIlSv9a+szH+VNcPfdGn+ Mlvvj9V/U3zUOPOKHA7dj0P3bcS/fR3346x7apv+DL+xki3ytgMt63yx/ujHYG4Q+b2Bn3+9qcZ/ cSWFa9Ef6+IQZhxNr7NJ+xfoSDMK+mpfLDGEbvT5PVQyqt8R+3rjrOxl0CeoYQJjau1xG0nrRtNs T/RDpT92g8gvfv4d+GfjIz2DanlJz8Mmi2Q8xrkle3Y/olbEz28Z1O+IgQf+JeYjUs/OOUNheZaz Ldmxzqv3i4gQ81FakS6/h7aE6wv4+XeQB+PfOyv1ebaNYGENu6oYOPWOw74TINePYWEiv/j5d+Ce 8Qym08dZhdURppXtUXojjdQ7johdBlFqwZp4HV5+yzbNI1O4iyJfjT1Q6SsYpRL1zEp7oc1Qz8i/ dntUw6JRrwiVX+n8G7KBEK7AE7hN0q5yZplVGd2oCPT2FJ4F86jXrrtK5bfEf//r2bMyoUZfcQ7t YjfqhKwVaAu6Fltz2Cv79RHnqy8cOmm3zWWf3xL//a9vTma14fSiPvKR0tnDNXTM2xsU5jb4Nou9 foxivuoCn1+kejebwW4uLR+VKFtysUpzm6xFnFj5eJPb68cQnZZslOTfP7fdemZT6xvYcmwR81/J 5aS+sX9ue90YqtOSjdoY/whMy5SdNVF/AsNhvcYdQqA/VpCf9prsifNhwuoZ2bxEGbj7/ASpl6yJ +mZG4pjVyL6lvENY2l47hu60nM9xFzY9CafmIytfDkdwfXZrqM3UOw6rvVq4OOzWSubvOFLzkfgs lbc53ZrE/ql3HFZ7skRYox6bzfAEOnz6KrunZze5fhd/Ai05KIr1PN24EVZC25KeB5GPkuwcyV5m 9o14Ynxke6IYdy/IsE6aT8jMfKQ/EYbWzN5hY4z9c9sz+q8fqPwvcIhWjHykPhEi1szeYWOM/XPb M/pvGjq6lWw3yH/7SrAh6dsZs/EMZeDAlorM+flT7zii4qXFmo+hSOw7/TwY9UTWYzF2LmX9Jn1i nNqeMFvMeTpwx2Pg1Pwbx0e4tt07xfwnzb9REY9E4N9l+AjVtu8OsFFSf+odh8JFSrB8xJnpGXjM cIs8kfVYbHAxho3MO4Qj26MFiTfyds8xsOgEr2+150ZhDGvfHTQOpH1iPMcTaNU8wXoYzW3Q86/E IPPwEco3cWwkjUm945jOmKiVSdYaYViYHjQP/5bYzGn490V4Ah2VCYXE/Lef5zkPovpxbCSNCWJN bE/j40DoHCR4nI3f9RkmmeeJLHp+jGOj1DuEeXYcnTDrb7aFCXnnJ9hzHj5CZ4xjo85Ooh2CpG+1 J4yeYAsV5t4fxTeRDILxNeLNhEBJqxP1lfa0f1+WOl7u7o+d6WY6D2L6iC9Toy2P8ARav6OxrHt8 vDwDtI9C+nBmOQ9i+ogfCeLV/6shAmPPI8eh8aVm31JkgIAN5uGjXp/1LEXA+niJFmnP7keKaBH+ oNhgewP997aiPZsX3sVZ+Ff9r3bJFmmPjFg5T6QEd/3m6pgN/Mae0aR+yo1WH7u2SclIOrbUs6J2 3Dhgo36s0Hf9/tp20/+/QyWWiGQR7IyrPZPbZBr7KnYcqnGifoJIG+H5xcwSkSyC6oezTYqUtGpr pOeWcUfh3lrk+37PwJuGhW18ZPTCuyizWIwo+TIhk4brYJthWrjjOz+hhrNvqK+0NxL0nDgPK2Ex mCDZw+PabNQ+JAiyF8OdH2fg0a0nkkk6fdZWoicc0xhYsjfRhwQh+mLluEDfSaw9JyjzyOwXIVau k/RjuJNm3siguLlsd/+ALaqaboH1W73g5kry6TbaNPOvwoWjMG8719QnstuhWO05qyj7zMLA1h3C DDsOHbOnkYABrPpN9W7rRAOs9pxV9Jwos1+EWBlP0o9gUJR5Y+OR5krBR379xp3l1OfEmBh5mxP1 IzxEmDc2GnkuIwcw+nUdR3IKzoZzMLDVoqQf4eEMUdFiZAGJNYL+27o/vMDtzcFSY5uCuvkJtMKD ozBvO9mYCSbqB/2D8xMlBMPOwcCTdxwT7YXn3+hQNDI7H21vt01lVbA2nYGT7Dgm2AtGREeikuPw 0TnUsANuluLrkKumrofVnqRv9y9tPNJkYzaYqC/0bwk+7vSp68nYymrPvONQuGBY76lyAufBSvT2 pq6IldEl/YgdwvHYtzwFPhqOEufTMxauOfuOQ+FXwv2EJMvz0XBU0BV9CiY0j7PjED07Ev+eyn+V gjk/BgxneKqNBnBaT6BxlWTMPGa3458Hm2EMu8b9npTSO4Edh2J90jxtL0+Ff8kTMG5Tf8rkZlqK fzUMbNln8DI3H1m9UM2p9hLpsu4QJP2Y3YGkb9lnCGJ9gjrDE9mSfALdd4cszJuj2fAUdhySvpbJ VVPN/ARa68aGOz/afmfKsuGxdxzodZ6xkz1tL0+Dj0rib7CwfpmFBR0rl0v6qGeityqLgmcqOYHz YCWyfsjBqLbIrnPzL9kYP6kewTWVBMxm1B93C/2UVVk/PAcH/mL9sh3BNWl9KL9sT677hUj8dDpg ton6VntulOb8iLGwCCSAmXccBES7ijERMjsf6dzQ8bWW6zj+t+4QJP1oTxRjpFVTyOx8pHMjmv/5 prFgnTHWo4hYBNc0EjDFRH2rPSd6fR3b0cw6+xNoCvZYpKVQifEJasASxn7KrEVfwVxMHFN3HKNu /W6Aj3sW9i3HvyfV8BH9TtPPW7U/sTYz1+jfSSh2HPQ7Z0HXTJEITr0SMh9rHVdsEfwoy7JzwOtZ du+v4efPAK+5n5n3M3v7rH2VwbDudTu+GvMD93oL+DHgh41urfxvMPwf4ee7TufMG7uBudvXIPd+ 4l5/D17/Kfz8vpvrdW/8a974zBtf2XrHva7m/sD59Qbgwzu/+uV3XF9r04/hDc9OtR6/7cZmTr96 /f+5gi8TAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACyEAAARABkAAAAAAAAAAIAAAAAAAAAAQAAAAAApBO3DhYD7gIAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA8ABPBCAAAAsgQK8AgAAAABBAAAAAoAAFMAC/Ae AAAABEEBAAAAPwEAAAYAgQERAAAQvwEMAB8A/wEAAAgAAAAQ8AQAAAAAAACAMgAH8BwQAAADBP9E a111fcUCsrATPpb+Nlv/APgPAAABAAAARAAAAAAA/wFgIRvw8A8AAP9Ea111fcUCsrATPpb+Nlso SAAAAAAAAAAAAADbBwAA4wUAAKC2MACIgCQAvg8AAAD+eJy9nA9wVMUdx/ftu5cN+SMhhASExEsC ChUwUaZilSINDlj+CnHAgkCIl3CS3NG7YAQVq4z/QMERCyIIFvFPYaiKlQoI1igIWGgrMhYcsK5l FKZYncKMVqX97e+9t3cJm92EC72ZN+/tZj/7/e3ue7v7vrnEIp0IsfN6EzhfQ8SnCxyXpnUm3cl/ 4UNIDvE/HzNCPnNESbdEOpagkCrwckoxJ0B6ksqx48fnkT1fkTJB5sHxj4I7vXoyvNIZWIoQSk7b zeu0IdXZy8nDUgGSRSzIsbw6IAySSf2rLPqZ8zETVwErm7gxCzbfa4P/+RRacAKKpXs/T/N+LtL/ oY6sPQDHAEhAcfI9bZ5roSKzRCoN67kUWuDmBixBuBQhv33/v5KiED8hve0A1sSZOHIw0kR+DuZx FoTrYFJ+EPM4uwKur0jKvwLzOBsK10Ol6ktJqjaev2qmPhQJzsbB9bgEtS85Vpeyk6hxSHA2Ha6n J+VPxzzOInAdScqPYB5nC+B6gVR5ca8+tgVIcLYErpck5S/BPM7WwPUaWdsLe/Uxr0GCs01wvSlB 7dHHsAkJznbA9Q5JPb9Hr7UDCc72w/X+BPWeXms/Epwdheujklr/nl7rKBKcnYLrUwlqt17rFBKc fS/KS+q53Xqt75HgLAsegizLp9bt0mtlWYLgrBdQvRLUu3qtXkhw1h+o/pL6zbt6rf5IcHYtUNdK 6tl39FrXIsHZKKBGSWptk15rFBKcTQFqiqTWvK3XmoIEZ7OBmm0l8mdjHmfzIX++rG31H/UxzEeC s0VALUpQb+ljWIQEZ08D9bSkVu3Uaz2NBGcbgNogqZU79FobkOBsG1DbJPXUm3qtbUhwtheovZJa sV2vtRcJzg4DdVhSy7fptQ4jwdkJoE5I6smteq0TSHD2LVDfSmrZG3qtb5HgLB3KplOfemKLXiud CoKz7lC2u6Qef12v1R0JzvpC2b6SWvp7vVZfJDgbDGUHS+qxzXqtwUhwNhLKjpTU4lf1WiOR4GwS lJ0kqUWv6LUmIcFZLZStldTDv9Nr1SLBWSOUbZTUg5v0Wo1IcPYQlH1IUg9s1Gs9hARny8XdJ6mF G/Ray5Hg7AWxLknqvpf0Wi8gwdkWKLtFUve+qNfaggRnu6Hsbknd87xeazcSnB2Csockddd6vdYh JDg7DmWPS2reOr3WcSQ4OwNlz0iq8Vm91hkkOHNg0+jYPtWwRq/l2ILgrBtQ3SQVe0av1Q0Jznrb Isen5qzSa/VGgrNBQA2SVP1KvdYgJDgbDtRwSdWt0GsNR4KzSqAqJRX+tV6rEgnOqoGqllTtk3qt aiQ4iwMVl1ToCb1WHAnOFgK1UFIzH9drLUSCs2VALZPUjKV6rWVIcLYOqHWSmvaYXmsdEpxtBmqz pKYs1mttRoKzJqCaJDX5Eb1WExKcfQDUB5Ka9LBe6wMkOONAcUlVPqjX4khw9jVQX0tqwgN6ra+R 4PjCYwV8atxCvZYVEARnXSDRRVJj7tNrdUGCs2JIFEtq1K/0WsVIcFYGiTJJjVyg1ypDgrPrIXG9 pG64R691PRKcwQspGS+pirv0WuOR4GwGJGZIath8vdYMJDiLQiIqqZ/eqdeKIsHZvZC4V1LXNeq1 7kWCs6WQWCqpn9yh11qKBGdrIbFWUlfP1WutRYKzlyHxsqQGxfVaLyPB2U5I7JTUVXG91k4kODsA iQOSKvulXusAEpwdg8QxSQ2Yo9c6hgRnX0LiS0n1j+q1vkSCsx8g8YOk+kX0Wj8gwVm2Q0i241OX RfRa2Y4gOCsEqlBSfer1WoVIcDYAqAGSKqnTaw1AgrMhQA2RVHC2XmsIEpyNBmq0pIpu12uNRoKz qUBNlVSv2/VaU5HgrA6oOkn1COu16pDg7G6g7pZUwSy91t1IcLYYqMWS6jZLr7UYCc5WAbVKUl1r 9VqrkOBsI1AbJZVTq9faiARn24HaLqmsGr3WdiQ42wfUPkll1Oi19iHB2RGgjkjKMWgdQYKzk0Cd lBRRaiWcOd+ls3LEtev0EfwI689Xc927TOL6iZemCQsx2bETvuGnTByE5GIJmnMxnC3LIf7HIolP QpN6Giq3MJuQZpHKNuHH5QKyJ5J5UbJn4KQjnMTmdeh9SLtZq/5fPqSjGE2zD+mPpnNBfUhVbOfv Q6piNvuQqhjMPqRKy+xDqrTMPqRKy+xDqrTMPqRKy+xDqrTMPqRKy+xDqrTMPqRKy+xDqrTMPqRK 6/x9SFUMZh9SFYPZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZ h1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1Rp mX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1I lZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZ h1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1Rp mX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh1RpmX1IlZbZh0xoJXxAy/uZJWtMeIDJ riRJ0vbrdr/E6Nftfv/QIi2/x2idk275PcjlkK4C/Dqoc88534O0SC9If5cUR/KnOxzTMjJ2/Pzh U40T4fhL7b8aRVp8n9ONLA0j6yR4Kq7ysCZxRS1x2TKaV6gbTbmjjkZfW3Jv+t/V7Bn4mLzr3EEu p8njIHpSVZfbWjQR4PO4tG8rw/WheHBsqDE4IVpfFSF+a8vTM4oTrWXeOMpWX7WyRZwDre4yYlH5 IDiuzHibDKVFcDWiqiHUWDUvOCFUE4qFItWh4LBY9axwQ6i6YW4sVE4KSVdSRMrgKCFdSH84F0Be AZyL4SiCvDLMKYFyuZiTC9f5cHa1rWa9Zeq3o4GzgcbAwdb67Zy2taW9PbG9TYHLbHGPT6wYG7wx 0hCK1VRVh0gfMoCUQxvyIeZcbJuIvLDN0ftPjHezUv8OdFszmpY7y6xXz2mNacTa3qpPrJ7YqjGh 28JVQW8syXU4OmLccqB1RdiycsxrrVVtUcxHxTJaa4tvTldEIw2xaF1dKDYA6hWj7/ahUM3vkN47 ZGemFdo3By5E73XGtoTtIwHH772kXkull3Kx5q32Vty7eCPiNH+OOqJ3Dti/sPPt9daF6J1u2IaZ 9llLfB9+Yrg2UlUXjtTG+kAbSvC574pPeWr3k9tTr9muC3g+PdVyJr8FMvfD29xMOM8PkJY9KNeH 5B7uY1Mynf7Znk4bA356CqSnQLpln/p9bVrfekKIB4UnAufJ7Yij2DlkFzs3yzgKIV3o3HzecQwE /c+g8z6C5f+fVtvjKHNOWB+mnbAS6eOQPm6dbxzpoD/VduMI2W2PIyNtpv0hHIn0NEhPs9sah3qN seHtfTR9J60j15gcvJdX0L+liZ3W+Krq2aGGPrgaluD9nMpz4j6NX0Dd4mmUa1csH2fdQm/NEqtW +56WaZB5IxwXw4gU26RZL7X87a87n6RhPf4OtLs9lnazR9EZtJddTS+x3RIWab5nTexC04z3SUPA jajUOb+I5gVG0TsCY2mRcwk8R706IKJKSFdBBfvELt5ubdeSaWfQKquStOWOcnd7B9u824O97a7k va0bOWt1V6petVdYs/DvnYaHasKRcEM4GgmSPFgFs+Hn2dB/4lygu0uNOiWo8znoiHn9hkhDuEFs KuNzopF4eGZdqCfUL3SEUibcrXmw6ypA1S5eFHkp6V+G+oV0Fj4vNdFYsNrbocDKFXRXeDGuOaCe h7pZkHZjysJIMklf+InISS2SYoxkIkQi/obN31/HQvHo3Fh1KB4SPS9aG8Q4RBR5uAMtwCtxnYp6 H1R/BNTFX7tVRW4Lhr0ZQ/RDY7hhltv6TNnrnT1dvxeC3iil3gdveX0gdxD+DjXUw1PLS+r9YozB 7ZfU7kW3D854fYD3QlVdXXBOLAr9H4c4BibuhDy8AzIxne/1fy62X4xN+2bUfpB5CArvgvN3ra63 LDGf/WmlzE3H50b8FmU1/cZaTb+yLsfjE7gWx0dWE/28xQrMWsxn6e1+E68QMwTMazsg2led1ua3 zU7cyrcrWpvfzhmPts9Lo+3JF3heclfm+0FHrMzuvJQ8F6VSd3es+w9Qt/jGViwx2VWJJyoX76GO mt+yUOsUaNnuPX3avYdTqTPfq/MxHINg3H9MM72YC7ynI9UxcPupNOD2E8xG9eFIlRjsKnf+KcU5 oGO03PfiW0BLvBeL+a8hVhWBkYk1kMTM1xmv3RESd1sqihmouBQURZFojagx9VFZGrinxahkdfCo 9EKdXRD3RUTsK+GeqsdRCTZEO3vzoRib5Dk61SfGfe/+DjRFnrsq98WxSPX5cN8my53JJOltkjRf a1MflVrHna8S7kdRi71EXoqj7/bQM47bQ33HjKjoB3l9oQVFmprV69EQKDgPpos34Ly21fcu03r0 lLXafsp60h6Kx0K4Fsdd9uvWo3ZHr0c3QWO22O5fyD/nnNuiAEzib8LPfwbncKtv1qYWDU37wi7H oyaQh8cXdhocJWk7290i9Yq53uGsJnCT0/Er5upAjXNhV8xrUOcU6IhdnLeTT1rcgmJDVR8F8WgM piXSfGfvr3xivkisfJn4fHSGc6n3vGR7M29Bis/l1RhtqVPjBIk73yfv++vRFw1FbpsThW1wvL+/ ArR8A/D3e6VyLvLL5GNaHLmQl0qkAzDSWyDSHnDlRibfCoIicsxrFkOiN8VVV4whz5uLSzvkbcVd m5dAVGJthr6LhKrFXRWP+e3PS1oBcg0zkOn5boIHoRIKTgGks+oN/6rE8+q+4zZ/wz8dWEg/Dyyh /Zy/0x87h6hbwl+Fe9s2Yc6d9P3ArfRwYDX187o5J+lNjmNXOLup2glgbXyuL7FfSxtN2/VcG/2d bByB+2kN1goT/nh3tu+hG9c2OlK7oFax7x1zw4hhFeP6wrMahPeswhSdW3eN6mTXOCJv5MArBw2G ejO99/n2rVFbAQAAAAIAAAADAAAABAAAAAUAAAAGAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAA DQAAAA4AAAAPAAAAEAAAABEAAAASAAAAEwAAABQAAAAVAAAAFgAAABcAAAAYAAAAGQAAABoAAAAb AAAAHAAAAB0AAAAeAAAAHwAAACAAAAAhAAAAIgAAACMAAAAkAAAAJQAAACYAAAAnAAAAKAAAACkA AAAqAAAAKwAAACwAAAAtAAAALgAAAC8AAAAwAAAAMQAAADIAAAAzAAAANAAAADUAAAA2AAAANwAA ADgAAAA5AAAAOgAAADsAAAA8AAAAPQAAAD4AAAA/AAAAQAAAAEEAAABCAAAAQwAAAEQAAABFAAAA RgAAAEcAAABIAAAASQAAAEoAAABLAAAATAAAAE0AAABOAAAATwAAAFAAAABRAAAAUgAAAFMAAABU AAAAVQAAAFYAAABXAAAAWAAAAFkAAABaAAAAWwAAAFwAAABdAAAAXgAAAF8AAAD+////YQAAAGIA AABjAAAAZAAAAGUAAABmAAAAZwAAAJcAAAD9////agAAAG0AAAD+////lgAAAJUAAAD9////cAAA AHEAAAByAAAAcwAAAHQAAAB1AAAAdgAAAHcAAAB4AAAAeQAAAHoAAAB7AAAAfAAAAH0AAAB+AAAA fwAAAIAAAABSAG8AbwB0ACAARQBuAHQAcgB5AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAFgAFAf//////////DgAAAAYJAgAAAAAAwAAAAAAAAEYAAAAA4PY/xi0l vwEwb4XHLSW/AWwAAACACAAAAAAAAEQAYQB0AGEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAAIB////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAYAAAAEoSAAAAAAAAVwBvAHIAZABEAG8AYwB1AG0AZQBu AHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgENAAAA//////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAvL8AAAAAAABPAGIAagBl AGMAdABQAG8AbwBsAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA FgABARAAAAD/////BAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAkElfxy0lvwEwb4XHLSW/AQAAAAAA AAAAAAAAAF8AMQAwADAAMQA3ADYAMgA3ADEANwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAYAAEB//////////8IAAAAEY2BZJtPzxGG6gCqALkp6AAAAACQSV/HLSW/ AZBJX8ctJb8BAAAAAAAAAAAAAAAAAQBPAGwAZQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAgH///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAAAAAAAABAEMAbwBtAHAATwBiAGoAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEgACAAUAAAAHAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAB1AAAAAAAAAAMATwBiAGoA SQBuAGYAbwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAS AAIB////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAwAAAAQA AAAAAAAA/v///wIAAAD+/////v////7///8GAAAABwAAAAgAAAAJAAAACgAAAAsAAAAMAAAA/v// /w4AAAAPAAAAEAAAABEAAAASAAAAEwAAAP7///8VAAAAFgAAABcAAAAYAAAAGQAAABoAAAAbAAAA HAAAAB0AAAAeAAAAHwAAAP7///8hAAAA/v////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////8BAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAQD+/wMKAAD/////EY2BZJtPzxGG6gCqALkp6BsAAABNaWNyb3NvZnQgUG93 ZXJQb2ludCBTbGlkZQAPAAAATVNQcmVzZW50YXRpb24AEwAAAFBvd2VyUG9pbnQuU2xpZGUuOAD0 ObJxAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD2DyMAAAAUAAAAX8CR4/cgAAALAPQD AwASAFZpa2FzIEJhamFqCAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAP7/AAAEAAIAAAAAAAAAAAAA AAAAAAAAAAEAAAAC1c3VnC4bEJOXCAArLPmuMAAAAMQBAAAQAAAAAQAAAIgAAAADAAAAkAAAAA8A AACoAAAABAAAAMgAAAAGAAAA0AAAAAcAAADYAAAACAAAAOAAAAAJAAAA6AAAAAoAAADwAAAAFwAA APgAAAALAAAAAAEAABAAAAAIAQAAEwAAABABAAAWAAAAGAEAAA0AAAAgAQAADAAAAGIBAAACAAAA 5AQAAFAAaQBjAHQAdQByAGUAcwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAASAAIBBgAAAAoAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA/v///wAAAAAAAAAAQwB1AHIAcgBlAG4AdAAgAFUAcwBlAHIAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABoAAgH///////////////8AAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAKwAAAAAAAAAFAFMAdQBtAG0AYQByAHkASQBuAGYAbwBy AG0AYQB0AGkAbwBuAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAKAACAAkAAAALAAAA/////wAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAG8AAAAYKQAAAAAAAFAAbwB3AGUAcgBQ AG8AaQBuAHQAIABEAG8AYwB1AG0AZQBuAHQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAoAAIB /////wwAAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAhAAAABshAAAA AAAAgQAAAIIAAACDAAAA/v///4UAAACGAAAAhwAAAIgAAACJAAAAigAAAIsAAACMAAAAjQAAAI4A AACPAAAAkAAAAJEAAACSAAAAkwAAAJQAAAD+////eAEAABcBAACYAAAA/v///6UAAACbAAAAnAAA AJ0AAACeAAAAnwAAAKAAAAChAAAAogAAAKMAAACkAAAAmQAAAKYAAACnAAAAqAAAAKkAAACqAAAA qwAAAKwAAACtAAAArgAAAK8AAACwAAAAsQAAALIAAACzAAAAtAAAALUAAAC2AAAAtwAAALgAAAC5 AAAAugAAALsAAAC8AAAAvQAAAL4AAAC/AAAAwAAAAMEAAADCAAAAwwAAAMQAAADFAAAAxgAAAMcA AADIAAAAyQAAAMoAAADLAAAAzAAAAM0AAADOAAAAzwAAANAAAADRAAAA0gAAANMAAADUAAAA1QAA ANYAAADXAAAA2AAAANkAAADaAAAA2wAAANwAAADdAAAA3gAAAN8AAADgAAAA4QAAAOIAAADjAAAA 5AAAAOUAAADmAAAA5wAAAOgAAADpAAAA6gAAAOsAAADsAAAA7QAAAO4AAADvAAAA8AAAAPEAAADy AAAA8wAAAPQAAAD1AAAA9gAAAPcAAAD4AAAA+QAAAPoAAAD7AAAA/AAAAP4AAAD9/////wAAAAAB AAD+/wAABAACAAAAAAAAAAAAAAAAAAAAAAABAAAA4IWf8vlPaBCrkQgAKyez2TAAAADoKAAACwAA AAEAAABgAAAAAgAAAGgAAAAEAAAAgAAAAAgAAACUAAAACQAAAKgAAAASAAAAtAAAAAoAAADUAAAA DAAAAOAAAAANAAAA7AAAAA8AAAD4AAAAEQAAAAABAAACAAAA5AQAAB4AAAAPAAAATm8gU2xpZGUg VGl0bGUAAB4AAAAMAAAAQXJ0aSBLaGFubmEAHgAAAAwAAABWaWthcyBCYWphagAeAAAAAgAAADkA a2EeAAAAFQAAAE1pY3Jvc29mdCBQb3dlclBvaW50AABQAEAAAACAF8GAAwAAAEAAAADQWUNWwpG+ AUAAAACAzAjJSBm/AQMAAABBAAAARwAAAOAnAAD/////AwAAAAgAbxBNDAAAAQAJAAAD6BMAAAkA OQAAAAAAEQAAACYGDwAYAP////8AABAAAAAAAAAAAAC6AwAAygIAAAkAAAAmBg8ACAD/////AgAA ABcAAAAmBg8AIwD/////BAAbAFROUFAUAMjwADAAAAAAFAAAAOQXeAAAAAAAAAAKAAAAJgYPAAoA VE5QUAAAAgD0AwkAAAAmBg8ACAD/////AwAAAA8AAAAmBg8AFABUTlBQBAAMAAEAAAABAAAAAAAA AAUAAAALAgAAAAAFAAAADALKAroDBQAAAAQBDQAAABAAAAAmBg8AFgD/////AAAAAAAAAAAAAMAD AADQAgAACAAAACYGDwAGAP////8AAAgAAAD6AgUAAQAAAAAAAAAEAAAALQEAAAcAAAD8AgEAAAAA AAAABAAAAC0BAQAFAAAABwEEAAAABgAAACYGJgACAAEABQAAAAQBBwAAAAcAAAD8AgAAqcv/AAAA BAAAAC0BAgAMAAAAJAMEAAAAAADAAwAAwAMtAAAALQAHAAAA/AIAAKfJ/wAAAAQAAAAtAQMABAAA APABAgAMAAAAJAMEAAAALQDAAy0AwANaAAAAWgAHAAAA/AIAAKTH/wAAAAQAAAAtAQIABAAAAPAB AwAMAAAAJAMEAAAAWgDAA1oAwAOHAAAAhwAHAAAA/AIAAKDD/wAAAAQAAAAtAQMABAAAAPABAgAM AAAAJAMEAAAAhwDAA4cAwAO0AAAAtAAHAAAA/AIAAJq+/wAAAAQAAAAtAQIABAAAAPABAwAMAAAA JAMEAAAAtADAA7QAwAPhAAAA4QAHAAAA/AIAAJO3/wAAAAQAAAAtAQMABAAAAPABAgAMAAAAJAME AAAA4QDAA+EAwAMOAQAADgEHAAAA/AIAAImv/wAAAAQAAAAtAQIABAAAAPABAwAMAAAAJAMEAAAA DgHAAw4BwAM7AQAAOwEHAAAA/AIAAH6m/wAAAAQAAAAtAQMABAAAAPABAgAMAAAAJAMEAAAAOwHA AzsBwANoAQAAaAEHAAAA/AIAAHKc/wAAAAQAAAAtAQIABAAAAPABAwAMAAAAJAMEAAAAaAHAA2gB wAOVAQAAlQEHAAAA/AIAAGSR/wAAAAQAAAAtAQMABAAAAPABAgAMAAAAJAMEAAAAlQHAA5UBwAPC AQAAwgEHAAAA/AIAAFaH/wAAAAQAAAAtAQIABAAAAPABAwAMAAAAJAMEAAAAwgHAA8IBwAPvAQAA 7wEHAAAA/AIAAEd+/wAAAAQAAAAtAQMABAAAAPABAgAMAAAAJAMEAAAA7wHAA+8BwAMcAgAAHAIH AAAA/AIAADl2/wAAAAQAAAAtAQIABAAAAPABAwAMAAAAJAMEAAAAHALAAxwCwANJAgAASQIHAAAA /AIAACtv/wAAAAQAAAAtAQMABAAAAPABAgAMAAAAJAMEAAAASQLAA0kCwAN2AgAAdgIHAAAA/AIA AB1q/wAAAAQAAAAtAQIABAAAAPABAwAMAAAAJAMEAAAAdgLAA3YCwAOjAgAAowIHAAAA/AIAAA9n /wAAAAQAAAAtAQMABAAAAPABAgAMAAAAJAMEAAAAowLAA6MCwAPQAgAA0AIGAAAAJgYmAAIAAAAG AAAAJgYBEAIAAAAIAAAA+gIAAAAAAAD///8ABAAAAC0BAgAFAAAABAELAAAABQAAACYGABAAAAwA AAAkAwQAAAAAAAAA0ALAA9ACwAMAABIAAAAmBgIQGgAAAAEBBQAAAAAAAAAAAAEAAAAAAAAAAAAA AAYAAAAmBgEQAgACAAQAAAAtAQAABgAAACYGJgACAAEABQAAAAQBDQAAAAYAAAAmBiYAAgAAAAcA AAD8AgAAAAAAAAAABAAAAC0BBAAEAAAA8AEDAAYAAAAmBiYAAgABAAcAAAAbBNECwQMAAAAABgAA ACYGJgACAAAABQAAAAQBBwAAAAcAAAD8AgAAqcv/AAAABAAAAC0BAwAMAAAAJAMEAAAAAADAAwAA wAMtAAAALQAHAAAA/AIAAKfJ/wAAAAQAAAAtAQUABAAAAPABAwAMAAAAJAMEAAAALQDAAy0AwANa AAAAWgAHAAAA/AIAAKTH/wAAAAQAAAAtAQMABAAAAPABBQAMAAAAJAMEAAAAWgDAA1oAwAOHAAAA hwAHAAAA/AIAAKDD/wAAAAQAAAAtAQUABAAAAPABAwAMAAAAJAMEAAAAhwDAA4cAwAO0AAAAtAAH AAAA/AIAAJq+/wAAAAQAAAAtAQMABAAAAPABBQAMAAAAJAMEAAAAtADAA7QAwAPhAAAA4QAHAAAA /AIAAJO3/wAAAAQAAAAtAQUABAAAAPABAwAMAAAAJAMEAAAA4QDAA+EAwAMOAQAADgEHAAAA/AIA AImv/wAAAAQAAAAtAQMABAAAAPABBQAMAAAAJAMEAAAADgHAAw4BwAM7AQAAOwEHAAAA/AIAAH6m /wAAAAQAAAAtAQUABAAAAPABAwAMAAAAJAMEAAAAOwHAAzsBwANoAQAAaAEHAAAA/AIAAHKc/wAA AAQAAAAtAQMABAAAAPABBQAMAAAAJAMEAAAAaAHAA2gBwAOVAQAAlQEHAAAA/AIAAGSR/wAAAAQA AAAtAQUABAAAAPABAwAMAAAAJAMEAAAAlQHAA5UBwAPCAQAAwgEHAAAA/AIAAFaH/wAAAAQAAAAt AQMABAAAAPABBQAMAAAAJAMEAAAAwgHAA8IBwAPvAQAA7wEHAAAA/AIAAEd+/wAAAAQAAAAtAQUA BAAAAPABAwAMAAAAJAMEAAAA7wHAA+8BwAMcAgAAHAIHAAAA/AIAADl2/wAAAAQAAAAtAQMABAAA APABBQAMAAAAJAMEAAAAHALAAxwCwANJAgAASQIHAAAA/AIAACtv/wAAAAQAAAAtAQUABAAAAPAB AwAMAAAAJAMEAAAASQLAA0kCwAN2AgAAdgIHAAAA/AIAAB1q/wAAAAQAAAAtAQMABAAAAPABBQAM AAAAJAMEAAAAdgLAA3YCwAOjAgAAowIHAAAA/AIAAA9n/wAAAAQAAAAtAQUABAAAAPABAwAMAAAA JAMEAAAAowLAA6MCwAPQAgAA0AIGAAAAJgYBEAIAAQAEAAAALQEBAAQAAADwAQUABQAAAAQBDQAA AAgAAAD6AgAAAAAAAAAAAAAEAAAALQEDAAcAAAD8AgAA////AAAABAAAAC0BBQAFAAAABwEBAAAA CAAAACYGDwAGAP////8BAAgAAAAmBg8ABgD/////AQAQAAAAJgYPABYA/////wAARwAAAI8CAAAR AQAAwQIAAAgAAAAmBg8ABgD/////AQAcAAAA+wIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAGAAAABwI CrhKiO13U4jtd9Bn73ccCAq4AAAKAAQAAAAtAQYABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAAAgEC AAAAEAAAACYGDwAWAP////8AAEcBAACPAgAAeQIAAMECAAAIAAAAJgYPAAYA/////wEABQAAAAkC AAAAAgUAAAAUAgAAAAAFAAAAAgECAAAABAAAAC0BAQAEAAAALQEAAAcAAAAbBGkAvwI4AAgBBAAA AC0BBQAEAAAALQEDAAUAAAAJAgAAAAIFAAAAFAIAAAAAHAAAAPsC4P8AAAAAAACQAQAAAAAAAAAA VGltZXMgTmV3IFJvbWFuAFOI7XfQZ+93HAoKIwAACgAEAAAALQEHAAQAAADwAQYABQAAAAkCADOZ AgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAADQAAAAyClwAEgEeAAAAR2F0ZXdheSBSZWZl cmVuY2UgQXJjaGl0ZWN0dXJlFwAOAAkADgAYAA4AEAAIABUADgALAA4ACwAOABAADgAOAAgAFwAL AA4AEAAJAAkADgAOAAkAEAALAA4ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAABAAAAC0B AQAEAAAALQEAAAcAAAAbBFECYQIgAlgBBAAAAC0BBQAEAAAALQEDAAUAAAAJAgAzmQIFAAAAFAIA AAAABQAAAAkCADOZAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABsAAAAyCkQCgAENAAAA U0NOIEludGVyZmFjZQASABUAFwAIAAsAEAAJAA4ACwAKAA8ADgAOAAUAAAAuAQEAAAAFAAAAAgEC AAAABQAAAAIBAgAAAAQAAAAtAQEACAAAAPoCAAABAAAAAAAAAgQAAAAtAQYABwAAABsEGAF5AsAA SAEEAAAALQEFAAQAAAAtAQMABAAAAPABBgAFAAAACQIAM5kCBQAAABQCAAAAAAUAAAAJAgAzmQIF AAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAbAAAAMgrkAHoBDQAAAE1lZGlhIEdhdGV3YXkA HQAOABAACQAOAAgAFwAOAAkADgAXAA4AEAAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAzmQIF AAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAWAAAAMgoLAZ4BCgAAAENvbnRyb2xsZXIVABAA EAAJAAsAEAAJAAkADgAKAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAAAQAAAAtAQEACAAA APoCAAABAAAAAAAAAgQAAAAtAQYABwAAABsE1AHhAnsBEAIEAAAALQEFAAQAAAAtAQMABAAAAPAB BgAFAAAACQIAM5kCBQAAABQCAAAAAAUAAAAJAgAzmQIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAAC AQEAAAAPAAAAMgqfAU8CBQAAAE1lZGlhAB0ADgAQAAkADgAFAAAALgEBAAAABQAAAAIBAgAAAAUA AAAJAgAzmQIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAASAAAAMgrGAT8CBwAAAEdhdGV3 YXkCFwAOAAkADgAYAA4AEAAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAACAQIAAAAEAAAALQEBAAgA AAD6AgAAAQAAAAAAAAIEAAAALQEGAAcAAAAbBNABmQF4AcgABAAAAC0BBQAEAAAALQEDAAQAAADw AQYABQAAAAkCADOZAgUAAAAUAgAAAAAFAAAACQIAM5kCBQAAABQCAAAAAAUAAAAuARgAAAAFAAAA AgEBAAAAFQAAADIKnAHzAAkAAABTaWduYWxpbmdyEgAJABAAEAAOAAkACQAQABAABQAAAC4BAQAA AAUAAAACAQIAAAAFAAAACQIAM5kCBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAEgAAADIK wwH3AAcAAABHYXRld2F5AhcADgAJAA4AGAAOABAABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgEC AAAAEAAAACYGDwAWAP////8AAB4BAADPAQAAIwEAACICAAAIAAAA+gIAAAEAAAAAAAAABAAAAC0B BgAEAAAALQEBAAgAAAAlAwIAIQHQASEBIAIIAAAAJQMCAB8B0AEfASACBAAAAC0BAwAEAAAA8AEG AAQAAAAtAQUACAAAACYGDwAGAP////8BABAAAAAmBg8AFgD/////AABuAgAA0gEAAHMCAAASAgAA CAAAAPoCAAABAAAAAAAAAAQAAAAtAQYABAAAAC0BAQAIAAAAJQMCAHEC0wFxAhACCAAAACUDAgBv AtMBbwIQAgQAAAAtAQMABAAAAPABBgAEAAAALQEFAAgAAAAmBg8ABgD/////AQAQAAAAJgYPABYA /////wAAdwIAAOYAAABCAwAA6wAAAAgAAAD6AgAAAQAAAAAAAAAEAAAALQEGAAQAAAAtAQEACAAA ACUDAgB4AukAQAPpAAgAAAAlAwIAeALnAEAD5wAEAAAALQEDAAQAAADwAQYABAAAAC0BBQAIAAAA JgYPAAYA/////wEAEAAAACYGDwAWAP////8AAN8CAACZAQAAQgMAAJ4BAAAIAAAA+gIAAAEAAAAA AAAABAAAAC0BBgAEAAAALQEBAAgAAAAlAwIA4AKcAUADnAEIAAAAJQMCAOACmgFAA5oBBAAAAC0B AwAEAAAA8AEGAAQAAAAtAQUACAAAACYGDwAGAP////8BAAQAAAAtAQEABAAAAC0BAAAHAAAAGwRv AcEDGAE4AwQAAAAtAQUABAAAAC0BAwAFAAAACQIAM5kCBQAAABQCAAAAAAUAAAAJAgAzmQIFAAAA FAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAQAAAAMgo8AUIDBgAAAFBhY2tldBIADgAOABAADgAJ AAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkCADOZAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIB AQAAABUAAAAyCmIBQgMJAAAASW50ZXJmYWNlcgsAEAAJAA4ACgALAA4ADgAPAAUAAAAuAQEAAAAF AAAAAgECAAAABQAAAAIBAgAAABAAAAAmBg8AFgD/////AAAgAQAAFgEAAHsBAAB+AQAABAAAAC0B AAAHAAAA/AIAAAAAAAAAAAQAAAAtAQYABQAAAAYBAgAAAAwAAAAkAwQAeQEZAXgBFwEiAXoBIwF8 AQUAAAAGAQEAAAAEAAAALQEDAAQAAAAtAQUABAAAAPABBgAIAAAAJgYPAAYA/////wEAEAAAACYG DwAWAP////8AAB4CAAAWAQAAcwIAAH4BAAAEAAAALQEAAAcAAAD8AgAAAAAAAAAABAAAAC0BBgAF AAAABgECAAAADAAAACQDBAAhAhcBIAIZAXACfAFxAnoBBQAAAAYBAQAAAAQAAAAtAQMABAAAAC0B BQAEAAAA8AEGAAgAAAAmBg8ABgD/////AQAQAAAAJgYPABYA/////wAAKAAAAKgAAABUAQAAcgEA AAQAAAAtAQEABAAAAC0BAAAHAAAAGwRzAfkAqAAoAAQAAAAtAQUABAAAAC0BAwAFAAAACQIAM5kC BQAAABQCAAAAABwAAAD7Auv/AAAAAAAAkAEAAAAAAAAAAFRpbWVzIE5ldyBSb21hbgBTiO130Gfv dxwICsAAAAoABAAAAC0BBgAEAAAA8AEHAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUA AAACAQEAAAAWAAAAMgrCADIACgAAAERlZmluaXRpb24PAAoABwAGAAsABgAGAAYACgALAAUAAAAu AQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAACIA AAAyCugAMgASAAAARW50aXR5IFJlc3BvbnNpYmxlDQALAAYABgAGAAoABgAOAAkACQAKAAsACwAI AAYACwAGAAkABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgA AAAFAAAAAgEBAAAAJwAAADIKAgEyABUAAABmb3IgY29udHJvbGxpbmcgTWVkaWEABwALAAcABQAK AAsACgAGAAcACwAGAAYABgALAAoABgATAAkACwAGAAkABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAA CQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAIQAAADIKGwEyABEAAABHYXRld2F5 IHJlc291cmNlc2UPAAoABgAJABAACQALAAUABwAKAAgACwALAAcACQAKAAgABQAAAC4BAQAAAAUA AAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAJQAAADIKNQEy ABQAAABhbmQgaW50ZXJmYWNpbmcgd2l0aAoACgALAAUABgALAAYACQAIAAcACQAKAAYACgALAAUA EAAGAAYACgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAA AAUAAAACAQEAAAAhAAAAMgpPATIAEQAAAFNpZ25hbGluZyBHYXRld2F5ZQwABgALAAoACgAGAAYA CgALAAUAEAAJAAYACgAPAAoACgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIA AAAABQAAAC4BGAAAAAUAAAACAQEAAAAlAAAAMgpoATIAFAAAAGZvciBjYWxsIHByb2Nlc3Npbmcu BwALAAcABQAKAAkABgAGAAYACgAIAAoACgAJAAkACAAGAAsACgAGAAUAAAAuAQEAAAAFAAAAAgEC AAAABQAAAAIBAgAAABAAAAAmBg8AFgD/////AAAHAQAA3wAAAFIBAADyAAAACAAAAPoCAAABAAAA AAAAAAQAAAAtAQcABwAAAPwCAAAAzJkAAAAEAAAALQEIABIAAAAkAwcAPgHwAD4B7AAIAewACAHk AD4B5AA+AeAAUAHoAAQAAAAtAQMABAAAAPABBwAEAAAALQEFAAQAAADwAQgACAAAACYGDwAGAP// //8BAAgAAAAmBg8ABgD/////AQAQAAAAJgYPABYA/////wAAIAAAAHgBAADUAAAAtgIAAAQAAAAt AQEABAAAAC0BAAAHAAAAGwS3ArEAeAEgAAQAAAAtAQUABAAAAC0BAwAFAAAACQIAAAACBQAAABQC AAAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAWAAAAMgqSASoACgAA AERlZmluaXRpb24PAAoABwAGAAsABgAGAAYACgALAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAkC AAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABAAAAAyCqsBKgAGAAAARW50aXR5DQAL AAYABgAGAAoABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgA AAAFAAAAAgEBAAAAGAAAADIKxQEqAAsAAAByZXNwb25zaWJsZWEHAAoACAALAAoACwAIAAYACwAG AAoABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAA AgEBAAAADAAAADIK3wEqAAMAAABmb3IWBwALAAcABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIA AAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAFgAAADIK3wFDAAoAAAAgc2lnbmFsaW5n BQAJAAYACgALAAoABgAGAAoACwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIA AAAABQAAAC4BGAAAAAUAAAACAQEAAAAYAAAAMgr4ASoACwAAAHRlcm1pbmF0aW9uYQYACgAHABAA BgALAAoABgAGAAoACwAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAA AC4BGAAAAAUAAAACAQEAAAAbAAAAMgoSAioADQAAAGFuZCB0cmFuc3BvcnQACgAKAAsABQAGAAcA CgALAAgACwAKAAcABgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAA AC4BGAAAAAUAAAACAQEAAAAKAAAAMgosAioAAgAAAG9mCwAHAAUAAAAuAQEAAAAFAAAAAgECAAAA BQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABYAAAAyCiwCPAAKAAAAIHNp Z25hbGluZwUACQAGAAoACwAJAAYABgALAAsABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAAAAC BQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAHAAAADIKRQIqAA4AAABJbmZvcm1hdGlvbiB0 bwcACwAHAAsABwARAAkABgAGAAsACgAGAAYACgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAA AAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAPAAAAMgpfAioABQAAAE1lZGlhABMACgAK AAYACgAFAAAALgEBAAAABQAAAAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUA AAACAQEAAAASAAAAMgp5AioABwAAAEdhdGV3YXkADwAKAAYACQAQAAkACwAFAAAALgEBAAAABQAA AAIBAgAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAACAQEAAAAWAAAAMgqSAioA CgAAAENvbnRyb2xsZXIOAAsACwAGAAcACgAGAAYACgAHAAUAAAAuAQEAAAAFAAAAAgECAAAABQAA AAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAAA8AAAAyCqwCKgAFAAAAKE1HQykA BwATABAADgAHAAUAAAAuAQEAAAAFAAAAAgECAAAABQAAAAIBAgAAABAAAAAmBg8AFgD/////AACX AAAApwEAANIAAAC6AQAACAAAAPoCAAABAAAAAAAAAAQAAAAtAQcABwAAAPwCAAAAzJkAAAAEAAAA LQEIABIAAAAkAwcAwgC4AcIAtAGYALQBmACsAcIArAHCAKgB0ACwAQQAAAAtAQMABAAAAPABBwAE AAAALQEFAAQAAADwAQgACAAAACYGDwAGAP////8BAAgAAAAmBg8ABgD/////AQAQAAAAJgYPABYA /////wAAiAIAAMQBAADAAwAArwIAABAAAAAmBg8AFgD/////AADdAgAAxwEAAPsCAAAaAgAACAAA APoCAAABAAAAAAAAAAQAAAAtAQcABwAAAPwCAAAAzJkAAAAEAAAALQEIABIAAAAkAwcA+QLcAfIC 3AHyAhgC5QIYAuUC3AHeAtwB6wLIAQQAAAAtAQMABAAAAPABBwAEAAAALQEFAAQAAADwAQgACAAA ACYGDwAGAP////8BAAQAAAAtAQEABAAAAC0BAAAHAAAAGwSwAsEDGAKIAgQAAAAtAQUABAAAAC0B AwAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAJAgAAAAIFAAAAFAIAAAAABQAAAC4BGAAAAAUAAAAC AQEAAAAWAAAAMgoyApICCgAAAERlZmluaXRpb24PAAoABwAGAAsABgAGAAYACgALAAUAAAAuAQEA AAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAADkAAAAy ClgCkgIhAAAARW50aXR5IHJlc3BvbnNpYmxlIGZvciBtb25pdG9yaW5nAA0ACwAGAAYABgAKAAYA BwAJAAkACgALAAsACAAGAAsABgAJAAYABwAKAAgABQARAAoACwAGAAYACwAHAAYACgALAAUAAAAu AQEAAAAFAAAAAgECAAAABQAAAAkCAAAAAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAADcA AAAyCnICkgIgAAAAYW5kIGNvbnRyb2xsaW5nIG1lZGlhIGVuZHBvaW50cywKAAoACwAFAAoACgAL AAYABwALAAYABgAGAAsACgAGABAACgAKAAYACgAFAAoACgALAAsACgAGAAsABgAIAAYABQAAAC4B AQAAAAUAAAACAQIAAAAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAALQAA ADIKiwKSAhkAAABtZWRpYSByZXNvdXJjZXMgYW5kIG1lZGlhABEACQALAAYACQAGAAcACQAJAAoA CwAHAAoACQAJAAUACQALAAsABQARAAkACwAGAAkABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIA AAACBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAGAAAADIKpQKSAgsAAABjb25uZWN0aW9u c3IKAAoACwALAAkACgAGAAYACgALAAgABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAACAAA ACYGDwAGAP////8BABAAAAAmBg8AFgD/////AABDAgAAGwEAAI4CAAB2AQAABAAAAC0BAAAHAAAA /AIAAAAzmQAAAAQAAAAtAQcABQAAAAYBAgAAAAwAAAAkAwQAWgIxAVQCNgF2AmABfAJbAQUAAAAG AQEAAAAKAAAAJAMDAGQCLAFIAiABTwI9AQoAAAAkAwMAbAJkAYgCcAGBAlMBBAAAAC0BAwAEAAAA LQEFAAQAAADwAQcACAAAACYGDwAGAP////8BAAQAAAAtAQEABAAAAC0BAAAHAAAAGwR9ATEDGAGI AgQAAAAtAQUABAAAAC0BAwAFAAAACQIAAAACBQAAABQCAAAAAAUAAAAJAgAzmQIFAAAAFAIAAAAA BQAAAC4BGAAAAAUAAAACAQEAAAANAAAAMgoyAZICBAAAAE1HQ1ATAA8ADwALAAUAAAAuAQEAAAAF AAAAAgECAAAABQAAAAkCADOZAgUAAAAUAgAAAAAFAAAALgEYAAAABQAAAAIBAQAAABAAAAAyClIB kgIGAAAATUVHQUNPEwANAA8AEAAOAA8ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAACQIAM5kCBQAA ABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAADwAAADIKcgGSAgUAAABILjI0OAAPAAYACgALAAsA BQAAAC4BAQAAAAUAAAACAQIAAAAFAAAAAgECAAAAEAAAACYGDwAWAP////8AAEsBAAAbAQAAlgEA AG4BAAAEAAAALQEAAAcAAAD8AgAAADOZAAAABAAAAC0BBwAFAAAABgECAAAADAAAACQDBACDATUB fQEwAV0BVAFjAVkBBQAAAAYBAQAAAAoAAAAkAwMAiAE9AZABIAF0ASsBCgAAACQDAwBYAUsBUAFo AWwBXQEEAAAALQEDAAQAAAAtAQUABAAAAPABBwAIAAAAJgYPAAYA/////wEAEAAAACYGDwAWAP// //8AAGcBAABDAQAAEgIAAGsBAAAIAAAAJgYPAAYA/////wEABQAAAAkCADOZAgUAAAAUAgAAAAAc AAAA+wLr/wAACg4KDpABAAAAAAcAAABUaW1lcyBOZXcgUm9tYW4AU4jtd9Bn73ccCgonAAAKAAQA AAAtAQcABAAAAPABBgAFAAAACQIAM5kCBQAAABQCAAAAAAUAAAAuARgAAAAFAAAAAgEBAAAAEgAA ADIKXQFyAQcAAABTSUdUUkFOAQwABwAPAA0ADwAPAA8ABQAAAC4BAQAAAAUAAAACAQIAAAAFAAAA AgECAAAABAAAAC0BAAAEAAAALQEBABwAAAD7AhAABwAAAAAAvAIAAAAAAQICIlN5c3RlbQB3vgpm 4QcAigEAAAoABgAAAAcAigEAAAoABAAAAC0BBgAEAAAA8AEHAA8AAAAmBg8AFABUTlBQBAAMAAAA AAAAAAAAAAAAAAkAAAAmBg8ACAD/////AQAAAAMAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAPAOgD9wIAAAEA6QMoAAAAgBYA AOAQAADgEAAAgBYAAMEIAAAAGQAAAAAAAAAAAAABAAAAAAAAAQ8A8gPwAAAALwDIDwwAAAAwANIP BAAAAAAAAAAPANUHTAAAAAAAtw9EAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAADo 1BIA6NQSAPTQEgD40wMwGNESAAgAAAAY0RIAftQDMAAABAAAAKkPCgAAAAcAAAACAAkEAABAAKMP bgAAAAUA//0/AAAAIiAAAGQAAAAAAAAAZAAAAAAAAAAAAEACAAAAAAIAAAD//+8AAAAAAP////// /xgAAAAAAQAAAAUAACABIAEAAAAAAAUAAEACQAIAAAAAAAUAAGADYAMAAAAAAAUAAIAEgAQAAAAA DwALBJQAAAAPAADwjAAAAAAABvAgAAAAAgwAAAMAAAAgAAAAAgAAAAEAAAAHAAAAAgAAAD0AAABj AAvwJAAAAIEBBAAACIMBAAAACL8BEAAQAMABAQAACP8BCAAIAAECAgAACGAAGvEYAAAA//+ZAP/M mQD/mTMAAGb/AGbM/wAAM5kAQAAe8RAAAAD/////ADOZAAIAAAj3AAAQHwDwDxwAAAAAAPMDFAAA AAIAAAAAAAAAAAAAAAAAAIAAAAAADwDQB4sAAAAfAP8DFAAAAAIAAAQMAAAAAAAAAAAAAAACAAAA DwD6A2cAAAAAAP4DAwAAAAABAAAA/QM0AAAAGgAAAGQAAAAaAAAAZAAAACTREgB+1AMwHNESAAgA AADiBQAAaAQAAAAAAAAAAAAAAQAAAHAA+wMIAAAAAAAAAMAMAABwAPsDCAAAAAEAAABACwAAPwDZ DwwAAAAAANoPBAAAAAAAJQAPAPAPWAAAAAAA8wMUAAAAAwAAAAQAAAACAAAAAAEAAAAAAAAAAJ8P BAAAAAYAAAAAAKoPCgAAAAEAAAABAAAAAAAQAJ8PBAAAAAUAAAAAAKoPCgAAAAEAAAABAAAAAAAA AOoDAAAAAA8A+AOBCAAAAgDvAxgAAAABAAAAAQIHCQgAAAAAAAAAAAAAAAAABTBgAPAHIAAAAP// /wAAAAAAgICAAAAAAAAAzJkAMzPMAMzM/wCysrIAYADwByAAAAAAAP8A////AAAAAAD//wAA/5kA AAD//wD/AAAAlpaWAGAA8AcgAAAA///MAAAAAABmZjMAgIAAADOZMwCAAAAAADPMAP/MZgBgAPAH IAAAAP///wAAAAAAMzMzAAAAAADd3d0AgICAAE1NTQDq6uoAYADwByAAAAD///8AAAAAAICAgAAA AAAA/8xmAAAA/wDMAMwAwMDAAGAA8AcgAAAA////AAAAAACAgIAAAAAAAMDAwAAAZv8A/wAAAACZ AABgAPAHIAAAAP///wAAAAAAgICAAAAAAAAzmf8Amf/MAMwAzACysrIAAACjDz4AAAABAP/9PwAA ACIgAABkAAAAAAABAGQAAAAAAAAAAABAAgAAAAACAAAA///vAAAAAAD///////8sAAAAAAMAABAA ow98AAAABQD//T8AAQAiIAAAZAAAAAAAAABkABQAAADYAAAAQAIAAAAAAgAAAP//7wAAAAAA//// ////IAAAAAABAACABQAAEyDUASABAAACABwAgAUAACIg0AJAAgAAAgAYAIAFAAATIPADYAMAAAIA FACABQAAuwAQBYAEAAAAACAAow9uAAAABQD//T8AAAAiIAAAZAAAAAAAAABkAB4AAAAAAAAAQAIA AAAAAgAAAP//7wAAAAAA////////DAAAAAABAAAABQAAIAEgAQAAAAAABQAAQAJAAgAAAAAABQAA YANgAwAAAAAABQAAgASABAAAAABQAKMPUgAAAAUAAAABCQAAAAABAAAAAAAAAAEAAQkAAAAAAQAg AQAAAAACAAEJAAAAAAEAQAIAAAAAAwABCQAAAAABAGADAAAAAAQAAQkAAAAAAQCABAAAAABgAKMP DAAAAAEAAAAAAAAAAAAAAHAAow8+AAAABQAAAAAAAAAAAAIAHAABAAAAAAAAAAIAGAACAAAAAAAA AAIAFAADAAAAAAAAAAIAEgAEAAAAAAAAAAIAEgCAAKMPPgAAAAUAAAAAAAAAAAACABgAAQAAAAAA AAACABQAAgAAAAAAAAACABIAAwAAAAAAAAACABAABAAAAAAAAAACABAADwAMBN8EAAAPAALw1wQA ABAACPAIAAAABgAAAAYEAAAPAAPwYwQAAA8ABPAoAAAAAQAJ8BAAAAAKAwAAJQAAAA0DAAAjAAAA AgAK8AgAAAAABAAABQAAAA8ABPDSAAAAEgAK8AgAAAACBAAAAAoAAJMAC/A2AAAAfwABAAEAgABU J3gAhwABAAAAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAACAAbAB 0BRQBA8AEfAQAAAAAADDCwgAAAAAAAAAAQB4AA8ADfBUAAAAAACfDwQAAAAAAAAAAACoDyAAAABD bGljayB0byBlZGl0IE1hc3RlciB0aXRsZSBzdHlsZQAAog8GAAAAIQAAAAAAAACqDwoAAAAhAAAA AQAAAAAADwAE8BYBAAASAArwCAAAAAMEAAAACgAAgwAL8DAAAAB/AAEAAQCAALQneACBAQQAAAiD AQAAAAi/AQEAEQDAAQEAAAj/AQEACQABAgIAAAgAABDwCAAAAOAEsAHQFAAPDwAR8BAAAAAAAMML CAAAAAEAAAACAHgADwAN8J4AAAAAAJ8PBAAAAAEAAAAAAKgPUgAAAENsaWNrIHRvIGVkaXQgTWFz dGVyIHRleHQgc3R5bGVzDVNlY29uZCBsZXZlbA1UaGlyZCBsZXZlbA1Gb3VydGggbGV2ZWwNRmlm dGggbGV2ZWwAAKIPHgAAACEAAAAAAA0AAAABAAwAAAACAA0AAAADAAwAAAAEAAAAqg8KAAAAUwAA AAEAAAAAAA8ABPC1AAAAEgAK8AgAAAAEBAAAAAoAAIMAC/AwAAAAfwABAAEAgAAUKHgAgQEEAAAI gwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABgD7ABYAaAEA8AEfAQAAAAAADD CwgAAAACAAAABwF4AA8ADfA9AAAAAACfDwQAAAAEAAAAAACoDwEAAAAqAAChDxQAAAACAAAAAAAA AAAAAgAAAAAAAgAOAAAA+A8EAAAAAAAAAA8ABPC3AAAAEgAK8AgAAAAFBAAAAAoAAIMAC/AwAAAA fwABAAEAgAB0KHgAgQEEAAAIgwEAAAAIvwEBABEAwAEBAAAI/wEBAAkAAQICAAAIAAAQ8AgAAABg D7AH0A6AEA8AEfAQAAAAAADDCwgAAAADAAAACQJ4AA8ADfA/AAAAAACfDwQAAAAEAAAAAACoDwEA AAAqAAChDxYAAAACAAAAAAAACAAAAQACAAAAAAACAA4AAAD6DwQAAAAAAAAADwAE8LcAAAASAArw CAAAAAYEAAAACgAAgwAL8DAAAAB/AAEAAQCAANQoeACBAQQAAAiDAQAAAAi/AQEAEQDAAQEAAAj/ AQEACQABAgIAAAgAABDwCAAAAGAPIBDQFIAQDwAR8BAAAAAAAMMLCAAAAAQAAAAIAngADwAN8D8A AAAAAJ8PBAAAAAQAAAAAAKgPAQAAACoAAKEPFgAAAAIAAAAAAAAIAAACAAIAAAAAAAIADgAAANgP BAAAAAAAAAAPAATwVAAAABIACvAIAAAAAQQAAAAMAACjAAvwPAAAAIABBwAAAIEB/5kzAIMB8AJ0 EJMBjp+LAJQB3r1oAJwBCwAAQL8BHgAfAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAA AACAgIAAAAAAAADMmQAzM8wAzMz/ALKysgAPAO4DTxUAAAIA7wMYAAAAAAAAAA8QAAAAAAAAAAAA gAAAAAADAAUwDwAMBP8UAAAPAALw9xQAACAACPAIAAAAGgAAADwIAAAQABjxBAAAAAEAAAAPAAPw dxQAAA8ABPAoAAAAAQAJ8BAAAAAcAQAAzAcAABkBAADJBwAAAgAK8AgAAAAACAAABQAAAA8ABPC+ AAAAogwK8AgAAAAjCAAAAAoAAKMAC/A8AAAAgACUKXgAhQACAAAAhwAGAAAAvwACAAIAgQEEAAAI gwEAAAAIvwEAABAAwAEBAAAI/wEAAAgAAQICAAAIAAAQ8AgAAABQATAGdRBwAg8ADfBSAAAAAACf DwQAAAAEAAAAAACoDx4AAABHYXRld2F5IFJlZmVyZW5jZSBBcmNoaXRlY3R1cmUAAKEPGAAAAB8A AAAAAAAIAAABAB8AAAAAAAQAADOZ/g8ABPDHAAAAogwK8AgAAAAkCAAAAAoAALMAC/BCAAAAgABU KngAvwACAA8AgQHM/8wAvwEMAB4AwAEBAAAI/wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8A fwMAAA8AAAAQ8AgAAADADBAIQA7gDQ8ADfBVAAAAAACfDwQAAAAEAAAAAACoDw0AAABTQ04gSW50 ZXJmYWNlAAChDxoAAAAOAAAAAAAAKAAAAQAyAA4AAAAAAAQAADOZ/gAAqg8KAAAADgAAAAIAAAAJ CA8ABPD8AAAAEgAK8AgAAAAmCAAAAAoAACMBC/BsAAAAgAAUK3gAhwABAAAAvwACAA8AgAEHAAAA gQFmzP8AgwHwAl0QiwEAAKb/jAFkAAAAnAELAABAvwEMAB4AwAEBAAAI/wEOAA4AAQICAAAIPwIA AAMAvwIBAA8A/wIWAB8AfwMAAA8AiAMBAAAAAAAQ8AgAAACABLAH0A6MBg8ADfBgAAAAAACfDwQA AAAEAAAAAACoDxgAAABNZWRpYSBHYXRld2F5IENvbnRyb2xsZXIAAKEPGgAAABkAAAAAAAAoAAAB ADIAGQAAAAAABAAAM5n+AACqDwoAAAAZAAAAAgAAAAkIDwAE8PEAAAASAArwCAAAACcIAAAACgAA IwEL8GwAAACAANQreACHAAEAAAC/AAIADwCAAQcAAACBAWbM/wCDAfACXRCLAQAApv+MAWQAAACc AQsAAEC/AQwAHgDAAQEAAAj/AQ4ADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCIAwEA AAAAABDwCAAAAOMIYAxAEe8KDwAN8FUAAAAAAJ8PBAAAAAQAAAAAAKgPDQAAAE1lZGlhIEdhdGV3 YXkAAKEPGgAAAA4AAAAAAAAoAAABADIADgAAAAAABAAAM5n+AACqDwoAAAAOAAAAAgAAAAkIDwAE 8P0AAAASAArwCAAAACgIAAAACgAAIwEL8GwAAACAAJQseACHAAEAAAC/AAIADwCAAQcAAACBAWbM /wCDAfACXRCLAQAApv+MAWQAAACcAQsAAEC/AQwAHgDAAQEAAAj/AQ4ADgABAgIAAAg/AgAAAwC/ AgEADwD/AhYAHwB/AwAADwCIAwEAAAAAABDwCAAAANAIsASQCdwKDwAN8GEAAAAAAJ8PBAAAAAQA AAAAAKgPEQAAAFNpZ25hbGluZyBHYXRld2F5AAChDyIAAAASAAAAAAAAKAAAAQAyABEAAAAAAAQA ADOZ/gEAAAAAAAAAAACqDwoAAAASAAAAAgAAAAkIDwAE8KwAAABCAQrwCAAAACkIAAAACgAAYwEL 8IQAAACFAAIAAACHAAEAAAC/AAIADwBEAQQAAAB/AQAAAQCAAQcAAACBAWbM/wCDAfACXRCLAQAA pv+MAWQAAACcAQsAAEC/ARAAEADAAQEAAAjLAdSUAADNAQEAAAD/AR4AHgABAgIAAAg/AgAAAwC/ AgEADwD/AhYAHwB/AwAADwCIAwEAAAAAABDwCAAAAOAKwAbABsAMDwAE8KYAAABCAQrwCAAAACoI AAAACgAAUwEL8H4AAACHAAEAAAC/AAIADwBEAQQAAAB/AQAAAQCAAQcAAACBAWbM/wCDAfACXRCL AQAApv+MAWQAAACcAQsAAEC/ARAAEADAAQEAAAjLAdSUAADNAQEAAAD/AR4AHgABAgIAAAg/AgAA AwC/AgEADwD/AhYAHwB/AwAADwCIAwEAAAAAABDwCAAAAPMKoA6gDmAMDwAE8KwAAABCAQrwCAAA ACsIAAAACgAAYwEL8IQAAACFAAIAAACHAAEAAAC/AAIADwBEAQQAAAB/AQAAAQCAAQcAAACBAWbM /wCDAfACXRCLAQAApv+MAWQAAACcAQsAAEC/ARAAEADAAQEAAAjLAdSUAADNAQEAAAD/AR4AHgAB AgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCIAwEAAAAAABDwCAAAAHAF0A6AE3AFDwAE8KwA AABCAQrwCAAAACwIAAAACgAAYwEL8IQAAACFAAIAAACHAAEAAAC/AAIADwBEAQQAAAB/AQAAAQCA AQcAAACBAWbM/wCDAfACXRCLAQAApv+MAWQAAACcAQsAAEC/ARAAEADAAQEAAAjLAdSUAADNAQEA AAD/AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCIAwEAAAAAABDwCAAAAKMJQBGA E6MJDwAE8PQAAACiDArwCAAAAC0IAAAACgAAEwEL8GYAAACAAFQteAC/AAIADwCAAQcAAACBAWbM /wCDAfACXRCLAQAApv+MAWQAAACcAQsAAEC/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/ AgEADwD/AhYAHwB/AwAADwCIAwEAAAAAABDwCAAAAJAGUBOAFpYIDwAN8F4AAAAAAJ8PBAAAAAQA AAAAAKgPEAAAAFBhY2tldCBJbnRlcmZhY2UAAKEPIAAAABEAAAAAAAAgAAAyABAAAAAAAAQAADOZ /gEAAAAAAAAAAACqDwoAAAARAAAAAgAAAAkIDwAE8KAAAABCAQrwCAAAAC4IAABACgAAQwEL8HgA AACHAAEAAAC/AAIADwBEAQQAAAB/AQAAAQCAAQcAAACBAWbM/wCDAfACXRCLAQAApv+MAWQAAACc AQsAAEC/ARAAEADAAQEAAAjLAWpKAAD/AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAA DwCIAwEAAAAAABDwCAAAAJAGzAbQCOMIDwAE8KAAAABCAQrwCAAAAC8IAAAACgAAQwEL8HgAAACH AAEAAAC/AAIADwBEAQQAAAB/AQAAAQCAAQcAAACBAWbM/wCDAfACXRCLAQAApv+MAWQAAACcAQsA AEC/ARAAEADAAQEAAAjLAWpKAAD/AR4AHgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwCI AwEAAAAAABDwCAAAAJAGwAygDuMIDwAD8KsCAAAPAATwegAAAAEACfAQAAAA8AAAAIAEAADgBwAA PQkAAAIACvAIAAAAMAgAAAECAAATAAvwBgAAAIgDAAAAAAAAEPAIAAAA8APwAOAHrQgPABHwLAAA AA8AFBAkAAAAAQDxDxwAAAAAAAAHAEQAAAAAAAAAAAAAAQABAAEMAAIAAA0wDwAE8KEBAACiDArw CAAAADEIAAACCgAAswAL8EIAAACAALQteAC/AAIADwCBAQYAAAi/AQwAHgDAAQEAAAj/AQYADgAB AgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAAAPAAAACABAAA0AUAAD0JAAAPABHw LAAAAA8AFBAkAAAAAQDxDxwAAAAAAAAHAEQAAAAAAAAAAAAAAQABAAEMAAIAAA0wDwAN8PMAAAAA AJ8PBAAAAAQAAAAAAKgPgQAAAERlZmluaXRpb24NRW50aXR5IFJlc3BvbnNpYmxlIGZvciBjb250 cm9sbGluZyBNZWRpYSBHYXRld2F5IHJlc291cmNlcyBhbmQgaW50ZXJmYWNpbmcgd2l0aCBTaWdu YWxpbmcgR2F0ZXdheSBmb3IgY2FsbCBwcm9jZXNzaW5nLgAAoQ88AAAAggAAAAAAACAAADIACgAA AAAAAgAQAAEAAAAAAAYAEAAAAAAFdgAAAAAAAgAQAAEAAAAAAAYAEAAAAAAAAACqDxIAAACBAAAA AgAAAAkIAQAAAAAAAAAPAATweAAAACIECvAIAAAAMggAAAIKAADDAAvwSAAAAAQAAAC0AIcAAQAA AL8AAgAPAIEBBAAACL8BHAAeAMABAQAACP8BDgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8D AAAPAAAAD/AQAAAAMAYAANAFAADgBwAAMAYAAA8AA/CkAgAADwAE8HoAAAABAAnwEAAAAMAAAADQ CAAA4AQAAEIQAAACAArwCAAAADMIAAABAgAAEwAL8AYAAACIAwAAAAAAABDwCAAAANAIwADgBEIQ DwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwBEAAAAAAAAAAAAAAIAAQABDAACAAANMA8ABPCa AQAAogwK8AgAAAA0CAAAAgoAALMAC/BCAAAAgAAULngAvwACAA8AgQEGAAAIvwEMAB4AwAEBAAAI /wEGAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAADAAAAA0AgAACAEAABC EAAADwAN8CABAAAAAJ8PBAAAAAQAAAAAAKgPgAAAAERlZmluaXRpb24NRW50aXR5IHJlc3BvbnNp YmxlIGZvciBzaWduYWxpbmcgdGVybWluYXRpb24gYW5kIHRyYW5zcG9ydCBvZiBzaWduYWxpbmcg SW5mb3JtYXRpb24gdG8gTWVkaWEgR2F0ZXdheSBDb250cm9sbGVyIChNR0MpAAChD0YAAAALAAAA AAAAIAAAMgB2AAAAAAAAAAAACgAAAAAAAgAQAAEAAAAAAAYAEAAAAAAFdQAAAAAAAgAQAAEAAAAA AAYAEAAAAAAFAACqDzYAAAAhAAAAAgAAAAkICgAAAAMAAAADAAkIHQAAAAIAAAAJCAoAAAADAAAA AwAJCC8AAAACAAAACQgPAATweAAAACIECvAIAAAANQgAAAIKAADDAAvwSAAAAAQAAAC0AIcAAQAA AL8AAgAPAIEBBAAACL8BHAAeAMABAQAACP8BDgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8D AAAPAAAAD/AQAAAAkAMAAPAJAADgBAAAUAoAAA8AA/BpAgAADwAE8HoAAAABAAnwEAAAADAPAACw CgAAoBQAABkQAAACAArwCAAAADYIAAABAgAAEwAL8AYAAACIAwAAAAAAABDwCAAAALAKMA+AFhkQ DwAR8CwAAAAPABQQJAAAAAEA8Q8cAAAAAAAABwBEAAAAAAAAAAAAAAMAAQABDAcCAAANMA8ABPB4 AAAAIgQK8AgAAAA3CAAAAgoAAMMAC/BIAAAABAAAAFoAhwABAAAAvwACAA8AgQEEAAAIvwEcAB4A wAEBAAAI/wEOAA4AAQICAAAIPwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAP8BAAAACwEAAAsAoA ACgRAACQDAAADwAE8F8BAACiDArwCAAAADgIAAACCgAAswAL8EIAAACAAHQueAC/AAIADwCBAQYA AAi/AQwAHgDAAQEAAAj/AQYADgABAgIAAAg/AgAAAwC/AgEADwD/AhYAHwB/AwAADwAAAA/wEAAA ADAPAACQDAAAoBQAABkQAAAPAA3w5QAAAAAAnw8EAAAABAAAAAAAqA9zAAAARGVmaW5pdGlvbg1F bnRpdHkgcmVzcG9uc2libGUgZm9yIG1vbml0b3JpbmcgYW5kIGNvbnRyb2xsaW5nIG1lZGlhIGVu ZHBvaW50cywgbWVkaWEgcmVzb3VyY2VzIGFuZCBtZWRpYSBjb25uZWN0aW9ucwAAoQ88AAAAdAAA AAAAACAAADIACgAAAAAAAgAQAAEAAAAAAAYAEAAAAAAFaAAAAAAAAgAQAAEAAAAAAAYAEAAAAAAA AACqDxIAAAALAAAAAgAAAAkIaQAAAAAAAAAPAATwagAAAEIBCvAIAAAAOQgAAAAKAACzAAvwQgAA AIUAAgAAAIcAAQAAAEQBBAAAAH8BAAABAL8BAAAQAMABADOZAMsBqCkBANABAQAAANEBAQAAAP8B GAAYAAECAgAACAAAEPAIAAAAwAawDTAPoAgPAATw8QAAAKIMCvAIAAAAOggAAAAKAAADAQvwYAAA AIAANC94AL8AAgAPAIABBwAAAIEBZsz/AIMB8AJdEIsBAACm/4wBZAAAAJwBCwAAQL8BDAAeAMAB AQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAIAAAAkAYwDyAT5ggP AA3wYQAAAAAAnw8EAAAABAAAAAAAqA8RAAAATUdDUA1NRUdBQ08NSC4yNDgAAKEPIgAAABIAAAAA AAAgAAAZABEAAAAAAAYAEAAAM5n+AQAAAAAAAAAAAKoPCgAAABIAAAACAAAACQgPAATwagAAAEIB CvAIAAAAOwgAAEAKAACzAAvwQgAAAIUAAgAAAIcAAQAAAEQBBAAAAH8BAAABAL8BAAAQAMABADOZ AMsBqCkBANABAQAAANEBAQAAAP8BGAAYAAECAgAACAAAEPAIAAAAwAbgB2AJcAgPAATw5QAAAKIM CvAIAAAAPAgAAAAKAAATAQvwZgAAAAQA+psAAIAAlC94AL8AAgAPAIABBwAAAIEBZsz/AIMB8AJd EIsBAACm/4wBZAAAAJwBCwAAQL8BDAAeAMABAQAACP8BBgAOAAECAgAACD8CAAADAL8CAQAPAP8C FgAfAH8DAAAPAAAAEPAIAAAAnAdwCGAMcAgPAA3wTwAAAAAAnw8EAAAABAAAAAAAqA8HAAAAU0lH VFJBTgAAoQ8aAAAACAAAAAAAACAAABkACAAAAAAABgAQAAAzmf4AAKoPCgAAAAgAAAACAAAACQgP AATwVAAAABIACvAIAAAAAQgAAAAMAACjAAvwPAAAAIABBwAAAIEBAGb/AIMB8AJVEJMBjp+LAJQB 3r1oAJwBCwAAQL8BHgAfAP8BAAAIAAQDCQAAAD8DAQABABAA8AcgAAAA////AAAAAACAgIAAAAAA AADMmQAzM8wAzMz/ALKysgAAAHIXEAAAAAEAMAAAAAAA/wIAAIgLAAAAAPUPHAAAAAAAAACDFQAD AAAAAN8gAAABAAAAAwAAAAAACTAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4A ZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAADgAAgD///////////////8AAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFAAAA9AEAAAAAAAAxAFQAYQBiAGwAZQAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADgACAAEAAAADAAAA//// /wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJoAAADntwEAAAAAAAUAUwB1AG0A bQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBvAG4AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAo AAIBAgAAAA8AAAD/////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQAAAMAB AAAAAAAABQBEAG8AYwB1AG0AZQBuAHQAUwB1AG0AbQBhAHIAeQBJAG4AZgBvAHIAbQBhAHQAaQBv AG4AAAAAAAAAAAAAADgAAgH///////////////8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAUAAAA2AIAAAAAAAAeAAAADwAAAE9uLXNjcmVlbiBTaG93AAAeAAAAGAAAAEh1Z2hl cyBTb2Z0d2FyZSBTeXN0ZW1zAAMAAAAbIQAAAwAAABAAAAADAAAAAQAAAAMAAAAAAAAAAwAAAAAA AAADAAAAAAAAAAMAAAAxFQgACwAAAAAAAAALAAAAAAAAAAsAAAAAAAAACwAAAAAAAAAeEAAAAwAA ABAAAABUaW1lcyBOZXcgUm9tYW4ADwAAAERlZmF1bHQgRGVzaWduAA8AAABObyBTbGlkZSBUaXRs ZQAMEAAABgAAAB4AAAALAAAARm9udHMgVXNlZAADAAAAAQAAAB4AAAAQAAAARGVzaWduIFRlbXBs YXRlAAMAAAABAAAAHgAAAA0AAABTbGlkZSBUaXRsZXMAAwAAAAEAAAAAAAAAAAAAAAAAAAAAAP7/ AAAEAAIAAAAAAAAAAAAAAAAAAAAAAAEAAADghZ/y+U9oEKuRCAArJ7PZMAAAAJABAAASAAAAAQAA AJgAAAACAAAAoAAAAAMAAAC0AAAABAAAAMAAAAAFAAAA2AAAAAYAAADkAAAABwAAAPAAAAAIAAAA AAEAAAkAAAAYAQAAEgAAACQBAAAKAAAAQAEAAAsAAABMAQAADAAAAFgBAAANAAAAZAEAAA4AAABw AQAADwAAAHgBAAAQAAAAgAEAAKl7R0yAu+Esbf8d8SP7UVpk30c/pbvpKfpXxR0x2F5NR9q30ix7 rrwjDtLXaRM9Tc/So22+I1pG/m8I40XqOrzf0FZ/b9iK+5NxUcZFrvsjWqr5XV+fVH7X5+6KjtFO +P2miTeOqJwwbCztASMYhHuhCO8G/Xj54+E/D24LcjBqWItR2aK0ZOK8eEOonjTuzKiJMyK+jZ2B b1z+dUv/6tz/q5P8af5/eERsNub/D7fCKDvMAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAA ABcAAAASAAAAaQBuAGYAbwBAAGgAcwBzAHcAbwByAGwAZAAuAGMAbwBtAAAA4Mnqefm6zhGMggCq AEupCzIAAABtAGEAaQBsAHQAbwA6AGkAbgBmAG8AQABoAHMAcwB3AG8AcgBsAGQALgBjAG8AbQAA AADMAAAARAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAADQyep5+brOEYyCAKoAS6kLAgAAABcAAAARAAAAdwB3AHcALgBoAHMAcwB3 AG8AcgBsAGQALgBjAG8AbQAAAODJ6nn5us4RjIIAqgBLqQsyAAAAaAB0AHQAcAA6AC8ALwB3AHcA dwAuAGgAcwBzAHcAbwByAGwAZAAuAGMAbwBtAC8AAAAA//8AAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFQAAABUAAACgAQAAoAEAAKABAACgAQAAtQEAALUB AABAAwAAQAMAAEADAABAAwAAQAMAAEADAABAAwAAQAMAAEADAABAAwAAQAMAAEADAABAAwAAQAMA AEADAABDAwAAAAQAAFgnAADiWAAAzHIAADJ3AAA+AAAARQAAAE0AAABUAAAAAAQAAN0LAACoFQAA +BsAAI0tAACmOQAAIUMAAJ9EAACTTgAA+FoAAFViAACwZAAAS2gAAMxyAAAydwAAPwAAAEEAAABC AAAARAAAAEYAAABIAAAASQAAAEoAAABMAAAATgAAAE8AAABQAAAAUgAAAFMAAAAABAAAyhkAAKs3 AABvTQAA8WUAADJ3AABAAAAAQwAAAEcAAABLAAAAUQAAALIDAADLAwAAzQMAAHhvAACebwAAsG8A ALhvAADdbwAA7m8AADJzAAATOpT/lYATWJT/lYQTWJT/lYQPAADwdAAAAAAABvAgAAAAAgwAAAMA AAASAAAAAgAAAAEAAAAKAAAAAgAAAAkAAAAfAAHwLAAAACIAB/AkAAAAAgTjfOVQvTw19hWtmRHO gSEi/wA+FAAAAwAAAH6rAAAAAAAAQAAe8RAAAAD//wAAAAD/AICAgAD3AAAQAQ8AAvBkAwAAIAAI 8AgAAAAJAAAACAgAAA8AAxIAVQAKAAEAWwAPAAIAAAAAAAAAOgAAQPH/AgA6AAAABgBOAG8AcgBt AGEAbAAAAAgAAAADJAMxJAAUAENKFgBPSgIAUUoCAG1ICQRuSAkEegABAAEAAgB6AAAAHgBIAGUA YQBkAGkAbgBnACAAMQAsADEALABIADEALABoADEALAAxAHMAdAAgAGwAZQB2AGUAbAAsAGwAMQAA ACAAAQAGJAEHJAEKJgALRh8AE6TwABSkPAAmZAQBAAFAJgALADUIgUNKIABLSBwAAHIAAgABAAIA cgAAAB8ASABlAGEAZABpAG4AZwAgADIALAAyACwAaAAgADIALABoADIALAAyAG4AZAAgAGwAZQB2 AGUAbAAsAGwAMgAAABcAAgAGJAEKJgELRh8AE6TwABSkPABAJgEACgA1CIE2CIFDShwAUAADAAEA AgBQAAAAEQBIAGUAYQBkAGkAbgBnACAAMwAsADMALABIADMALABoADMAAAAXAAMABiQBCiYCC0Yf ABOk8AAUpDwAQCYCAAMANQiBAFIABAABAAIAUgAAABEASABlAGEAZABpAG4AZwAgADQALAA0ACwA SAA0ACwAaAA0AAAAFwAEAAYkAQomAwtGHwATpPAAFKQ8AEAmAwAGADUIgTYIgUIABQABAAIAQgAA AA4ASABlAGEAZABpAG4AZwAgADUALAA1ACwAaAA1AAAAFAAFAAomBAtGHwATpPAAFKQ8AEAmBAAA PAAGAAEAAgA8AAAACQBIAGUAYQBkAGkAbgBnACAANgAAABQABgAKJgULRh8AE6TwABSkPABAJgUD ADYIgQA8AAcAAQACADwAAAAJAEgAZQBhAGQAaQBuAGcAIAA3AAAAFAAHAAomBgtGHwATpPAAFKQ8 AEAmBgQAQ0oUAEAACAABAAIAQAAAAAkASABlAGEAZABpAG4AZwAgADgAAAAUAAgACiYHC0YfABOk 8AAUpDwAQCYHBwA2CIFDShQAAEAACQABAAIAQAAAAAkASABlAGEAZABpAG4AZwAgADkAAAAUAAkA CiYIC0YfABOk8AAUpDwAQCYIBwA2CIFDShIAADwAQUDy/6EAPAAAABYARABlAGYAYQB1AGwAdAAg AFAAYQByAGEAZwByAGEAcABoACAARgBvAG4AdAAAAAAAAAAAAAAAAAA8ABMAAQACADwAAQAFAFQA TwBDACAAMQAAAA0ADwADJAATpGgBFKRoAQARADUIgTsIgT4qAU9KAABRSgAAADAAFAABAAIAMAAB AAUAVABPAEMAIAAyAAAABQAQAAMkAAAOADUIgToIgU9KAABRSgAALgAVAAEAAgAuAAEABQBUAE8A QwAgADMAAAAFABEAAyQAAAsAOgiBT0oAAFFKAAAAKgAWAAEAAgAqAAEABQBUAE8AQwAgADQAAAAF ABIAAyQAAAgAT0oAAFFKAAAqABcAAQACACoAAQAFAFQATwBDACAANQAAAAUAEwADJAAACABPSgAA UUoAACoAGAABAAIAKgABAAUAVABPAEMAIAA2AAAABQAUAAMkAAAIAE9KAABRSgAAKgAZAAEAAgAq AAEABQBUAE8AQwAgADcAAAAFABUAAyQAAAgAT0oAAFFKAAAqABoAAQACACoAAQAFAFQATwBDACAA OAAAAAUAFgADJAAACABPSgAAUUoAACoAGwABAAIAKgABAAUAVABPAEMAIAA5AAAABQAXAAMkAAAI AE9KAABRSgAANgA+AAEAggE2AAAABQBUAGkAdABsAGUAAAANABgAAyQBE6TwABSkPAAACwA1CIFD SiAAS0gcAAA2ACdAogCRATYAAAARAEMAbwBtAG0AZQBuAHQAIABSAGUAZgBlAHIAZQBuAGMAZQAA AAQAQ0oQACYAKUCiAKEBJgAAAAsAUABhAGcAZQAgAE4AdQBtAGIAZQByAAAAAAAsAB9AAQCyASwA AAAGAEgAZQBhAGQAZQByAAAADQAbAA3GCAAC4BDAIQECAAAALAAgQAEAwgEsAAAABgBGAG8AbwB0 AGUAcgAAAA0AHAANxggAAuAQwCEBAgAAACwAHgDhAdIBLAAAAAwAQwBvAG0AbQBlAG4AdAAgAFQA ZQB4AHQAAAACAB0AAABAAP4PAQDiAUAAAAANAEYAbwBvAHQAbgBvAHQAZQAgAEIAYQBzAGUAAAAL AB4ABSQBEmTcAAEAAAgAQ0oSAG1ICQgqAEIAAQDyASoAAAAJAEIAbwBkAHkAIABUAGUAeAB0AAAA BgAfABSkoAAAADYAMAARAgICNgABAAsATABpAHMAdAAgAEIAdQBsAGwAZQB0AAAADgAgAA+EAAAR hAAAFKSgAAAAJAAvQAEAEgIkAAAABABMAGkAcwB0AAAACgAhAA+EaAERhJj+AAA4AFkAAQAiAjgA AAAMAEQAbwBjAHUAbQBlAG4AdAAgAE0AYQBwAAAABgAiAC1EIAEIAE9KAwBRSgMAPgAiAAEAAgA+ AAAABwBDAGEAcAB0AGkAbwBuAAAAEAAjAAMkAQUkAROkeAAUpPAADgA1CIE+KgFPSgQAUUoEAGQA QwABAEICZAAAABAAQgBvAGQAeQAgAFQAZQB4AHQAIABJAG4AZABlAG4AdAAAACYAJAAxJAEPhGgB EYRoARJkGAEAABOkZAAUpHgADcYIAAJ2AioDAAAMAENKGABPSgAAUUoAADAAVAABAFICMAAAAAoA QgBsAG8AYwBrACAAVABlAHgAdAAAAAoAJQAOhMD9D4SEAwAAOgAKAAEAAgA6AAEABwBJAG4AZABl AHgAIAAxAAAAFQAmAAMkAA+E3AARhCT/DcYFAAF4DwIABABDShIAOgALAAEAAgA6AAEABwBJAG4A ZABlAHgAIAAyAAAAFQAnAAMkAA+EuAERhCT/DcYFAAF4DwIABABDShIAOgAMAAEAAgA6AAEABwBJ AG4AZABlAHgAIAAzAAAAFQAoAAMkAA+ElAIRhCT/DcYFAAF4DwIABABDShIAOgANAAEAAgA6AAEA BwBJAG4AZABlAHgAIAA0AAAAFQApAAMkAA+EcAMRhCT/DcYFAAF4DwIABABDShIAOgAOAAEAAgA6 AAEABwBJAG4AZABlAHgAIAA1AAAAFQAqAAMkAA+ETAQRhCT/DcYFAAF4DwIABABDShIAOgAPAAEA AgA6AAEABwBJAG4AZABlAHgAIAA2AAAAFQArAAMkAA+EKAURhCT/DcYFAAF4DwIABABDShIAOgAQ AAEAAgA6AAEABwBJAG4AZABlAHgAIAA3AAAAFQAsAAMkAA+EBAYRhCT/DcYFAAF4DwIABABDShIA OgARAAEAAgA6AAEABwBJAG4AZABlAHgAIAA4AAAAFQAtAAMkAA+E4AYRhCT/DcYFAAF4DwIABABD ShIAOgASAAEAAgA6AAEABwBJAG4AZABlAHgAIAA5AAAAFQAuAAMkAA+EvAcRhCT/DcYFAAF4DwIA BABDShIAQgAhAAEAYgJCAAAADQBJAG4AZABlAHgAIABIAGUAYQBkAGkAbgBnAAAADQAvAAMkAROk 8AAUpHgAAAcANQiBQ0oaAABOAP4PAQACA04AAQALAGIAdQBsAGwAZQB0ACAAbABpAHMAdAAAACIA MAAKJgALRjcDMSQBDoRaABSkPAANxgsAA3YCKgPAIQAAAAQAQ0oYACQA/g8BABIDJAAAAAQAYgBv AGwAZAAAAAYAMQATpHgAAwA1CIEAQAD+DwEAIgNAAAAACQBoAGUAYQBkADoAYwBoAGEAcAAAABsA MgAKJgALRh4AD4SwARGEUP4NxgcBaAEBsAEGAAAAKAD+DwEAMgMoAAAACABOAG8AcgBtAGEAbABf ADgAAAACADMABABDShAAQAD+DwEAQgNAAAAACQBoAGUAYQBkADoAcwBlAGMAMQAAABsANAAKJgEL Rh4AD4TQAhGEMP0NxgcBaAEB0AIGAAAAQAD+DwEAUgNAAAAACQBoAGUAYQBkADoAcwBlAGMAMgAA ABsANQAKJgILRh4AD4TQAhGEMP0NxgcBaAEB0AIGAAAAQAD+DwEAYgNAAAAACQBoAGUAYQBkADoA cwBlAGMAMwAAABsANgAKJgMLRh4AD4RgAxGEoPwNxgcBaAEBOAQGAAAAQAD+DwEAcgNAAAAACQBo AGUAYQBkADoAcwBlAGMANAAAABsANwAKJgQLRh4AD4TwAxGEEPwNxgcBaAEBoAUGAAAALgBRAAEA ggMuAAAACwBCAG8AZAB5ACAAVABlAHgAdAAgADMAAAAGADgADoTA/QAAMgAdQAEAkgMyAAAADQBG AG8AbwB0AG4AbwB0AGUAIABUAGUAeAB0AAAAAgA5AAQAQ0oUADgAJkCiAKEDOAAAABIARgBvAG8A dABuAG8AdABlACAAUgBlAGYAZQByAGUAbgBjAGUAAAADAEgqAQBMAP4PMQKyA0wAAAAFAFQASQBU AEwARQAAAB8AOwADJAMFJAAPhNACEYQw/RSkeAANxggAAnYCKgMAAAAPAD4qAENKKABPSgAAUUoA AABSAP4P8QHyAVIAAAAJAHMAdQBiAF8AVABJAFQATABFAAAAHgA8ADEkARJkGAEAABOkZAAUpHgA DcYIAAJ2AioDAAAPADUIgUNKHABPSgAAUUoAAABgAP4PAQACAGAAAAAMAEgAZQBhAGQAaQBuAGcA IABCAGEAcwBlAAAAIQA9AAUkAQYkAQ+EOAQSZNwAAQATpIwADcYIAAJ2AioDAAAAEwBAiPz/Q0oY AEtIHABoCABtSAkIAEQA/g8BADICRAAAAAcAUABpAGMAdAB1AHIAZQAAABQAPgAGJAEPhDgEDcYI AAJ2AioDAAAPAECI+/9DShQAaAgAbUgJCABYAFIAAQDyA1gAAAASAEIAbwBkAHkAIABUAGUAeAB0 ACAASQBuAGQAZQBuAHQAIAAyAAAAEQA/AA+EOAQNxggAAnYCKgMAAAAPAECI+/9DShgAaAgAbUgJ CABcAP4PAQACAFwAAAAFAGwAaQBuAGUAbAAAAC4AQAAxJAEOhDwAD4Q8ABJkPAAAABSktAAmZAYB AAAoZAYBAAANxggAAnYCKgMAABIANQiBNgiBQ0oIAE9KAABRSgAAJgD+D7EDEgQmAAAACQBUAEkA VABMAEUAXwB0AG8AYwAAAAIAQQAAAHAA/g/x/yIEcAAAAAgAZQBuAG0AOgBsAGUAdgAxAAAANgBC AAMkAzEkAA6EaAEPhNACEYSY/hJk/wAAABOkFwAUpDoADcYRAAXQAqAFcAgQDrATAAAAAAAXAENK FgBPSgUAUUoFAGgIAG1ICQhuSAkEAGAA/g/x/zIEYAAAAAYAZgBpAGcAcwB0AGQAAAAqAEMAAyQD BSQBBiQBMSQAEmT/AAAAE6RCABSkZQANxgsAA5j+8B7AIQAAABcAQ0oWAE9KBQBRSgUAaAgAbUgJ CG5ICQQAYgD+D/H/QgRiAAAABwBuAGUAdwBwAGEAZwBlAAAAKgBEAAMkAwckATEkABJk/wAAABOk FwAUpDoADcYOAAQAAKAFQAvgEAAAAAAXAENKFgBPSgUAUUoFAGgIAG1ICQhuSAkEAFoA/g/x/1IE WgAAAAQAcABhAHIAYQAAACcARQADJAMxJAASZP8AAAATpBcAFKQ6AA3GDgAEAACgBUAL4BAAAAAA ABcAQ0oWAE9KBQBRSgUAaAgAbUgJCG5ICQQARgD+D/EBYgRGAAAADgBCAG8AZAB5ACAAVABlAHgA dAAgAEsAZQBlAHAAAAAIAEYAAyQABiQBDwBDShQAT0oGAFFKBgBoCAAAZAD+D9EDcgRkAAAADwBT AGUAYwB0AGkAbwBuACAASABlAGEAZABpAG4AZwAAACMARwADJAAFJAAPhAAAEmTwAAEAE6R4ABSk oAANxgYCdgIqAwAADwA1CIFAiAAAQ0ocAG1ICQQAKABVQKIAgQQoAAAACQBIAHkAcABlAHIAbABp AG4AawAAAAYAPioBQioCQABTAAEAkgRAAAAAEgBCAG8AZAB5ACAAVABlAHgAdAAgAEkAbgBkAGUA bgB0ACAAMwAAAAoASQAPhGgBEYSY/gAAIAD+DwEDogQgAAAABgBiAHUAbABsAGUAdAAAAAIASgAA AEwA/g/BBLIETAABAAsAUgBlAHEAdQBpAHIAZQBtAGUAbgB0AAAAFABLAAMkAwomAAtGlgATpDwA FKQ8AA8ANgiBQ0oWAE9KAgBRSgIAADgA/g/x/8IEOAAAAAQAQgBvAGQAeQAAAAkATAAqJAEUpHgA ABQAS0gQAE9KBwBRSgcAbUgJBG5ICQRMAP4PAQDyAUwAAAAIAEEAcABwAGUAbgBkAGkAeAAAACEA TQADJAEKJgALRgwBMSQBD4RoARGEuP8NxgcBaAEBKAgGAAcANQiBQ0ocAABYAP4P8QTiBFgAAAAT AFIAZQBxAHUAaQByAGUAbQBlAG4AdABzAC0ATABlAHYAZQBsADEAAAAfAE4ACiYAC0b+AQ+EoAUR hDD9FKTwAA3GBwFoAQHQAgYAAABWAP4PAQDyBFYAAAAJAGIAbwBkAHkAIAB0AGUAeAB0AAAAIQBP AAMkADEkAROkUAAUpFAADcYOAATQAqAFcAhACwAAAAAADwBCKgFPSgAAUUoAAG1IAAQA2AD+DwEA AgXYAAEADABSAEYAUAAgAFEAdQBlAHMAdABpAG8AbgAAAJMAUAADJAAxJAEPhNACEYQw/UXGgAAA AACG0iomBAAAAAAAAAAAAAAAAAAAAAAAAABoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAFAFsAUQAuAAAAXQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAABkANQiBNgiBQ0oUAEtIEABPSgAAUUoAAGgIAABqAP4PEQDyAWoAAAAPAEgA ZQBhAGQAaQBuAGcAVwBPAE4AdQBtAGIAZQByAAAAJgBRAAomAAtGAAAxJAESZOABAAATpBQAFKTw ACRkBgEAASZkBgEAARQAQ0osAEtIAABPSgUAUUoFAG1IAARiAP4PAQAiBWIAAAAJAEEAcABwAHIA bwB2AGEAbABzAAAAKQBSAAMkAQUkAQYkAQckATEkASRkBgEAISVkBgEAJCZkBgEAISdkBgEAJAAT ADUIgUNKHABPSgUAUUoFAG1IAAQAOABWQKIAMQU4AAAAEQBGAG8AbABsAG8AdwBlAGQASAB5AHAA ZQByAGwAaQBuAGsAAAAGAD4qAUIqDD4AUEABAEIFPgAAAAsAQgBvAGQAeQAgAFQAZQB4AHQAIAAy AAAACgBUABOkPAAUpDwADABDShQAT0oAAFFKAAAAAAAAtgAAAM8DAAC9SAAAMnMAAAsAAKoAAAAA /////wsA+aoAAAAA/////wsANKsAAAAA/////wsAWasAAAAA/////wAAAAAAAAAAAAAAAAAAAAAA AAAAAADwTAMAAA8ABPAoAAAAAQAJ8BAAAAAAAAAAAAAAAAAAAAAAAAAAAgAK8AgAAAAACAAABQAA AA8ABPByAAAAQgEK8AgAAAABCAAAAAoAALMAC/BCAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAA wAEAMwAAywFqSgAA/wEeAB4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AQAAAAAAAAAAAAR 8AQAAAACAAAADwAE8DYAAACyBArwCAAAAAIIAAAACgAAEwAL8AYAAAAEQQEAAAAAABDwBAAAAAEA AAAAABHwBAAAAAIAAAAPAATwcgAAAEIBCvAIAAAAAwgAAAAKAACzAAvwQgAAAL8AAAAPAEQBBAAA AH8BAAABAL8BAAAQAMABADMAAMsBakoAAP8BHgAeAD8CAAADAL8CAQAPAP8CFgAfAH8DAAAPAAAA EPAEAAAAAgAAAAAAEfAEAAAAAgAAAA8ABPByAAAAQgEK8AgAAAAECAAAAAoAALMAC/BCAAAAvwAA AA8ARAEEAAAAfwEAAAEAvwEAABAAwAEAMwAAywFqSgAA/wEeAB4APwIAAAMAvwIBAA8A/wIWAB8A fwMAAA8AAAAQ8AQAAAADAAAAAAAR8AQAAAACAAAADwAE8DYAAACyBArwCAAAAAUIAAAACgAAEwAL 8AYAAAAEQQEAAAAAABDwBAAAAAQAAAAAABHwBAAAAAIAAAAPAATwcgAAAEIBCvAIAAAABggAAAAK AACzAAvwQgAAAL8AAAAPAEQBBAAAAH8BAAABAL8BAAAQAMABADMAAMsBakoAAP8BHgAeAD8CAAAD AL8CAQAPAP8CFgAfAH8DAAAPAAAAEPAEAAAABQAAAAAAEfAEAAAAAgAAAA8ABPByAAAAQgEK8AgA AAAHCAAAAAoAALMAC/BCAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEAMwAAywFqSgAA/wEe AB4APwIAAAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AQAAAAGAAAAAAAR8AQAAAAAAAAADwAE8DYA AACyBArwCAAAAAgIAAAACgAAEwAL8AYAAAAEQQEAAAAAABDwBAAAAAcAAAAAABHwBAAAAAAAAAAA DwAC8IwBAAAQAAjwCAAAAAMAAAAJBAAADwAD8CoBAAAPAATwKAAAAAEACfAQAAAAAAAAAAAAAAAA AAAAAAAAAAIACvAIAAAAAAQAAAUAAAAPAATwcgAAAEIBCvAIAAAABQQAAAAKAACzAAvwQgAAAL8A AAAPAEQBBAAAAH8BAAABAL8BAAAQAMABADMAAMsBakoAAP8BHgAeAD8CAAADAL8CAQAPAP8CFgAf AH8DAAAPAAAAEPAEAAAAAAAAAAAAEfAEAAAAAQAAAA8ABPB4AAAAQgEK8AgAAAAJBAAAAAoAAMMA C/BIAAAAvwAAAA8ARAEEAAAAfwEAAAEAvwEAABAAwAEAMwAAywHUlAAAzQEBAAAA/wEeAB4APwIA AAMAvwIBAA8A/wIWAB8AfwMAAA8AAAAQ8AQAAAABAAAAAAAR8AQAAAABAAAADwAE8EIAAAASAArw CAAAAAEEAAAADgAAUwAL8B4AAAC/AQAAEADLAQAAAAD/AQAACAAEAwkAAAA/AwEAAQAAABHwBAAA AAEAAACyAAAAym4AADJzAAAFBAAASAAAAKgAAACYIgAAqAAAAHQAAAAAAAkEAAC4////QwAAAHgh AABDAAAAdAAAAAAAAAAAAAEAAAAVAAAAoAEAAKEBAAC1AQAAQwMAAAEIAAC4////QAIAAAgiAABA AgAAdQAAAAAAAggAAGgcAAAAAAAA6CAAALABAAA0AAAAAAADCAAAuP///zoAAAAIIgAAOgAAAHUA AAAAAAQIAAC4////QAIAAAgiAABAAgAAdQAAAAAABQgAAGgcAAAAAAAA6CAAALABAAA0AAAAAAAG CAAAuP///zoAAAAIIgAAOgAAAHUAAAAAAP//AQAAAAsAXwAxADAAMAAxADcANgAyADcAMQA3AMsD AAAzcwAAAAAAQMsDAAAzcwAAAAAAALIDAADOAwAA0AMAANQDAADVAwAA2gMAAOAKAADqCgAAdQ0A AH8NAADiEwAA5hMAAFksAABbLAAAnTQAAKc0AACDPwAAjT8AAPhEAAD8RAAACVAAAA1QAABMUgAA VFIAAMJZAADFWQAA+V8AAANgAAAFYAAAC2AAABVgAAAfYAAAIWAAACdgAAAOZwAAFWcAAMlnAADQ ZwAAqW0AAK9tAACxbQAAuG0AAMVtAADObQAA0G0AANltAAAabgAAIm4AACRuAAAtbgAAL24AADdu AAA5bgAAQG4AAEJuAABKbgAAiW4AAJFuAACTbgAAnm4AAKBuAACnbgAANm8AAD1vAABGbwAASG8A AO9vAADwbwAA+W8AAPtvAACZcQAAm3EAADBzAAAzcwAABwADAAcAAwAHAAMABwAcAAcAHAAHABwA BwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAH ABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwAcAAcAHAAHABwABwACAAcA HAAHABwABwACAAAAAACcAAAAqAAAALIDAADPAwAA90IAAPxCAACMTAAAjkwAACJNAAAlTQAAsU0A ALRNAAAhYAAAKGAAAPFhAAD8YQAAF2IAAB9iAADragAA92oAABZsAAAebAAAhm4AAJFuAADMbgAA 1W4AAFJvAABdbwAA728AAPBvAAAwcwAAM3MAAAcAGgAHAAMABwAaAAcAGgAHABoABwAaAAcAGgAH ABoABwAaAAcAGgAHABoABwAaAAcAGgAHABoABwACAAcAAgD//xQAAAALAFYAaQBrAGEAcwAgAEIA YQBqAGEAagA3AEMAOgBcAEcAYQB0AGUAdwBhAHkAXABkAG8AYwBzAFwAaABzAHMAXABXAGgAaQB0 AGUAIABwAGEAcABlAHIAcwBcAE0ARQBHAEEAQwBPAHYAcwBNAEcAQwBQAF8ATwBjAHQAMwAxAC4A ZABvAGMACwBWAGkAawBhAHMAIABCAGEAagBhAGoAMwBDADoAXABUAEUATQBQAFwAQQB1AHQAbwBS AGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAATQBFAEcAQQBDAE8AdgBzAE0ARwBDAFAA XwBPAGMAdAAzADEALgBhAHMAZAALAFYAaQBrAGEAcwAgAEIAYQBqAGEAagA3AEMAOgBcAEcAYQB0 AGUAdwBhAHkAXABkAG8AYwBzAFwAaABzAHMAXABXAGgAaQB0AGUAIABwAGEAcABlAHIAcwBcAE0A RQBHAEEAQwBPAHYAcwBNAEcAQwBQAF8ATwBjAHQAMwAxAC4AZABvAGMACwBWAGkAawBhAHMAIABC AGEAagBhAGoANwBDADoAXABHAGEAdABlAHcAYQB5AFwAZABvAGMAcwBcAGgAcwBzAFwAVwBoAGkA dABlACAAcABhAHAAZQByAHMAXABNAEUARwBBAEMATwB2AHMATQBHAEMAUABfAE8AYwB0ADMAMQAu AGQAbwBjAAsAVgBpAGsAYQBzACAAQgBhAGoAYQBqADMAQwA6AFwAVABFAE0AUABcAEEAdQB0AG8A UgBlAGMAbwB2AGUAcgB5ACAAcwBhAHYAZQAgAG8AZgAgAE0ARQBHAEEAQwBPAHYAcwBNAEcAQwBQ AF8ATwBjAHQAMwAxAC4AYQBzAGQACwBWAGkAawBhAHMAIABCAGEAagBhAGoAMwBDADoAXABUAEUA TQBQAFwAQQB1AHQAbwBSAGUAYwBvAHYAZQByAHkAIABzAGEAdgBlACAAbwBmACAATQBFAEcAQQBD AE8AdgBzAE0ARwBDAFAAXwBPAGMAdAAzADEALgBhAHMAZAALAEEAcgB0AGkAIABLAGgAYQBuAG4A YQA2AEQAOgBcAGEAcgB0AGkAXABnAGEAdABlAHcAYQB5AHMAXABwAHIAbwBkAHUAYwB0AFwAYgBy AG8AYwBoAHUAcgBlAHMAXABNAEUARwBBAEMATwB2AHMATQBHAEMAUABfAHYAMwAuAGQAbwBjAAsA VgBpAGsAYQBzACAAQgBhAGoAYQBqADQAQwA6AFwARwBhAHQAZQB3AGEAeQBcAGQAbwBjAHMAXABo AHMAcwBcAFcAaABpAHQAZQAgAHAAYQBwAGUAcgBzAFwATQBFAEcAQQBDAE8AdgBzAE0ARwBDAFAA XwB2ADMALgBkAG8AYwALAFYAaQBrAGEAcwAgAEIAYQBqAGEAagA0AEMAOgBcAEcAYQB0AGUAdwBh AHkAXABkAG8AYwBzAFwAaABzAHMAXABXAGgAaQB0AGUAIABwAGEAcABlAHIAcwBcAE0ARQBHAEEA QwBPAHYAcwBNAEcAQwBQAF8AdgAzAC4AZABvAGMADgBHAGEAcgB5ACAARwByAGUAZQBuAGIAZQBy AGcAYwBDADoAXABXAEkATgBOAFQAXABQAHIAbwBmAGkAbABlAHMAXABnAGcAcgBlAGUAbgBiAGUA cgBnAFwARABlAHMAawB0AG8AcABcAEMAYQBzAHQAbABlACAAVgBPAEkAUABcAEEAcgBjAGgAaQB0 AGUAYwB0AHUAcgBlACAAYQBuAGQAIABQAGwAYQBuAG4AaQBuAGcAXABNAEcAQwBQAFwATQBFAEcA QQBDAE8AdgBzAE0ARwBDAFAAXwB2ADMALgBkAG8AYwDgAXz////utnbV/w//D/8P/w//D/8P/w// D/8PAQCI////hnYkzf8P/w//D/8P/w//D/8P/w//DwEAif///7LLQL3/D/8P/w//D/8P/w//D/8P /w8BAPv///8Ykqw1/w//D/8P/w//D/8P/w//D/8PAAD+////1g7qOf8P/w//D/8P/w//D/8P/w// DwEAEms6AAEACQT/D/8P/w//D/8P/w//D/8P/w8BAJw2yAAPAAkE/w//D/8P/w//D/8P/w//D/8P AQD6TQUBLHE8Zv8P/w//D/8P/w//D/8P/w//DwEApx5RAQEACQT/DwAAAAAAAAAAAAAAAAAAAAAB AGstUQEBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQA3RVUBAQAJBP8P/w//D/8P/w//D/8P/w//DwEA vQZ/AW7Xcgn/D/8P/w//D/8P/w//D/8P/w8BAPYSiQEBAAkE/w//D/8P/w//D/8P/w//D/8PAQCl C8gBAwAJBP8PAAAAAAAAAAAAAAAAAAAAAAEAiT5CApypjrj/D/8P/w//D/8P/w//D/8P/w8BAFIe cwLEp9JX/w//D/8P/w//D/8P/w//D/8PAQAre78CAQAJBP8P/w//D/8P/w//D/8P/w//DwEAdE/z Ag8ACQT/D/8P/w//D/8P/w//D/8P/w8BAF1Q8wIBAAkE/w//D/8P/w//D/8P/w//D/8PAQBccgQD AQAJBP8P/w//D/8P/w//D/8P/w//DwEAJhgqAwEACQT/D/8P/w//D/8P/w//D/8P/w8BAIsXTAMB AAkE/w//D/8P/w//D/8P/w//D/8PAQDlBMoDQk4gRf8P/w//D/8P/w//D/8P/w//DwEA10XtA4aZ 2NP/D/8P/w//D/8P/w//D/8P/w8AAL88GwQBAAkI/w//D/8P/w//D/8P/w//D/8PAQC0MdMEDwAJ BP8P/w//D/8P/w//D/8P/w//DwEAyyQ6BUJOIEX/D/8P/w//D/8P/w//D/8P/w8BALt78AXEp9JX /w//D/8P/w//D/8P/w//D/8PAQCqVvkFAQAJBP8P/w//D/8P/w//D/8P/w//DwEA+UsaBgEACQj/ D/8P/w//D/8P/w//D/8P/w8BAL4W6wYesDBT/w//D/8P/w//D/8P/w//D/8PAQBDWSIHDwAJBP8P /w//D/8P/w//D/8P/w//DwEANhJtBw8ACQT/D/8P/w//D/8P/w//D/8P/w8BAMFjxgcBAAkE/w// D/8P/w//D/8P/w//D/8PAQByDdEHAQAJBP8P/w//D/8P/w//D/8P/w//DwEArl3WByxxPGb/D/8P /w//D/8P/w//D/8P/w8BAP1YQQgFAAkE/w//D/8P/w//D/8P/w//D/8PAQDrZlUI5APmfP8P/w// D/8P/w//D/8P/w//DwEAUB5yCAEACQT/D/8P/w//D/8P/w//D/8P/w8BAKhpdwgscTxm/w//D/8P /w//D/8P/w//D/8PAQALKoMIAQAJBP8P/w//D/8P/w//D/8P/w//DwEAaSeGCAsACQT/D/8P/w// D/8P/w//D/8P/w8BABYtjQgBAAkE/w//D/8P/w//D/8P/w//D/8PAQCZBrcIAQAJBP8P/w//D/8P /w//D/8P/w//DwEA+0/KCADFem7/D/8P/w//D/8P/w//D/8P/w8BAKIF4ggPAAkE/w//D/8P/w// D/8P/w//D/8PAQBbfxgJAQAJBP8P/w//D/8P/w//D/8P/w//DwEACHkyCR6wMFP/D/8P/w//D/8P /w//D/8P/w8BAF4RQwkBAAkE/w//D/8P/w//D/8P/w//D/8PAQBTax8KxKfSV/8P/w//D/8P/w// D/8P/w//DwEAzVFNCiC3eiH/D/8P/w//D/8P/w//D/8P/w8BAKgQcApCTiBF/w//D/8P/w//D/8P /w//D/8PAQBNI+gKEQAJCP8P/w//D/8P/w//D/8P/w//DwEAzx/BCw8ACQT/D/8P/w//D/8P/w// D/8P/w8BAI5I2QvEp9JX/w//D/8P/w//D/8P/w//D/8PAQB3SOoLAQAJBP8P/w//D/8P/w//D/8P /w//DwEA21QWDCJ0XFn/D/8P/w//D/8P/w//D/8P/w8BAKJyPwxCTiBF/w//D/8P/w//D/8P/w// D/8PAQAfchgNnGqed/8P/w//D/8P/w//D/8P/w//DwAAkVGmDUJOIEX/D/8P/w//D/8P/w//D/8P /w8BAHBsqg3OsSpV/w//D/8P/w//D/8P/w//D/8PAQA5aAEODwAJBP8P/w//D/8P/w//D/8P/w// DwEAQCNgDsSn0lf/D/8P/w//D/8P/w//D/8P/w8BACcnew4BAAkE/w//D/8P/w//D/8P/w//D/8P AQAOGogOBQAJBP8P/w//D/8P/w//D/8P/w//DwEANTGgDsSn0lf/D/8P/w//D/8P/w//D/8P/w8B AGFmtQ7ieTZ+/w//D/8P/w//D/8P/w//D/8PAQDTY8wOAQAJCP8P/w//D/8P/w//D/8P/w//DwEA 02TTDgEACQT/D/8P/w//D/8P/w//D/8P/w8BAG8KgQ8BAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQBB FrgQ/Hl+pf8P/w//D/8P/w//D/8P/w//DwEAZzs0EQEACQT/D/8P/w//D/8P/w//D/8P/w8BAK8l PhEFAAkE/w//D/8P/w//D/8P/w//D/8PAQA+Y10RyO68b/8P/w//D/8P/w//D/8P/w//DwEAVxal EQEACQT/D/8P/w//D/8P/w//D/8P/w8BADheGBIscTxm/w//D/8P/w//D/8P/w//D/8PAQDEKB0S AQAJBP8P/w//D/8P/w//D/8P/w//DwEADmJREgUACQT/D/8P/w//D/8P/w//D/8P/w8BAP4V4hIB AAkE/w//D/8P/w//D/8P/w//D/8PAQAOYDcTAQAJBP8P/w//D/8P/w//D/8P/w//DwEAyhM/EwEA CQT/D/8P/w//D/8P/w//D/8P/w8BAMY6RBNCTiBF/w//D/8P/w//D/8P/w//D/8PAQAcR6UTBQAJ BP8P/w//D/8P/w//D/8P/w//DwEAHwW3Ew8ACQT/DwAAAAAAAAAAAAAAAAAAAAABAJQGQxQBAAkE /w//D/8P/w//D/8P/w//D/8PAQBeM0gUAQAJBP8P/w//D/8P/w//D/8P/w//DwEAh3RaFAEACQT/ D/8P/w//D/8P/w//D/8P/w8BAKcSXhQBAAkE/w//D/8P/w//D/8P/w//D/8PAQAnHHkUAQAJCP8P /w//D/8P/w//D/8P/w//DwEArz+VFAUACQT/D/8P/w//D/8P/w//D/8P/w8BAN1BMhUBAAkE/w// D/8P/w//D/8P/w//D/8PAQDtJk8Vrrsk9/8P/w//D/8P/w//D/8P/w//DwEAqBBuFwEACQT/D/8P /w//D/8P/w//D/8P/w8BAIgOfxcBAAkE/w//D/8P/w//D/8P/w//D/8PAQA6U6UXbtdyCf8P/w// D/8P/w//D/8P/w//DwEAvQRSGWBcksv/D/8P/w//D/8P/w//D/8P/w8BAAEzyxkBAAkE/w//D/8P /w//D/8P/w//D/8PAQDHCO8ZAQAJBP8P/w//D/8P/w//D/8P/w//DwEA6T33GSxxPGb/D/8P/w// D/8P/w//D/8P/w8BADACMRoBAAkE/w//D/8P/w//D/8P/w//D/8PAQDFEU8aAQAJBP8P/w//D/8P /w//D/8P/w//DwEAbXRPGhEACQj/D/8P/w//D/8P/w//D/8P/w8BANNQkRoBAAkE/w//D/8P/w// D/8P/w//D/8PAQA+cfUaDwAJBP8P/w//D/8P/w//D/8P/w//DwEAbFsMG0JOIEX/D/8P/w//D/8P /w//D/8P/w8BAKoVLxsPAAkE/w//D/8P/w//D/8P/w//D/8PAQA3bnsbAQAJBP8P/w//D/8P/w// D/8P/w//DwEA4HWIGwEACQT/D/8P/w//D/8P/w//D/8P/w8BAApRABwPAAkE/w//D/8P/w//D/8P /w//D/8PAQCUOmAcxKfSV/8P/w//D/8P/w//D/8P/w//DwEAN0/mHCxxPGb/D/8P/w//D/8P/w// D/8P/w8BAOgJ9RwBAAkE/w//D/8P/w//D/8P/w//D/8PAQAGafocEP820v8P/w//D/8P/w//D/8P /w//DwEAU2cpHQEACQj/D/8P/w//D/8P/w//D/8P/w8BAA4KcB0esDBT/w//D/8P/w//D/8P/w// D/8PAQBSClAeAQAJBP8P/w//D/8P/w//D/8P/w//DwEA9SvFHixxPGb/D/8P/w//D/8P/w//D/8P /w8BAL0bBB8BAAkE/w//D/8P/w//D/8P/w//D/8PAQAzPXMfAQAJBP8P/w//D/8P/w//D/8P/w// DwEA+Fd7HwEACQT/D/8P/w//D/8P/w//D/8P/w8BAHIPiR/Ep9JX/w//D/8P/w//D/8P/w//D/8P AQCTHbgfxKfSV/8P/w//D/8P/w//D/8P/w//DwEAQnzqHwEACQT/D/8P/w//D/8P/w//D/8P/w8B AAcQASABAAkE/w//D/8P/w//D/8P/w//D/8PAQBEOysgAQAJBP8P/w//D/8P/w//D/8P/w//DwEA MF0sIOJ5Nn7/D/8P/w//D/8P/w//D/8P/w8BAD8bjiABAAkE/w//D/8P/w//D/8P/w//D/8PAQCk O7cgwgtkdf8P/w//D/8P/w//D/8P/w//DwAA4BT4IIz7HAn/D/8P/w//D/8P/w//D/8P/w8AAJ56 JyJMPyJ+/w//D/8P/w//D/8P/w//D/8PAQCmNzYiLHE8Zv8P/w//D/8P/w//D/8P/w//DwEACW2m IhEACQj/D/8P/w//D/8P/w//D/8P/w8BAHZZ9SIFAAkE/w//D/8P/w//D/8P/w//D/8PAQBoeUAj xKfSV/8P/w//D/8P/w//D/8P/w//DwEAggahI4jlHu//D/8P/w//D/8P/w//D/8P/w8BAHwTqCMP AAkE/w//D/8P/w//D/8P/w//D/8PAQC+QugjAQAJBP8PAAAAAAAAAAAAAAAAAAAAAAEAv3UcJGIN Vvz/D/8P/w//D/8P/w//D/8P/w8BAEsu8yQBAAkI/w//D/8P/w//D/8P/w//D/8PAQAsV2klAQAJ BP8P/w//D/8P/w//D/8P/w//DwEAw2tsJSAdUPn/D/8P/w//D/8P/w//D/8P/w8BAPVqwyULAAkE /w//D/8P/w//D/8P/w//D/8PAQAPSsklBQAJBP8P/w//D/8P/w//D/8P/w//DwEAgVvhJUzwtA8y ADQANQA2ADcA/w//D/8P/w8AAC1b5yUBAAkE/w//D/8P/w//D/8P/w//D/8PAQDWdS4mAQAJBP8P /w//D/8P/w//D/8P/w//DwEA31AxJkJOIEX/D/8P/w//D/8P/w//D/8P/w8BANQeWyYPAAkE/w// D/8P/w//D/8P/w//D/8PAQB5CLgmAQAJBP8P/w//D/8P/w//D/8P/w//DwEAiTG/JgEACQT/D/8P /w//D/8P/w//D/8P/w8BAJRJ6CZCTiBF/w//D/8P/w//D/8P/w//D/8PAQBNIDonDwAJBP8P/w// D/8P/w//D/8P/w//DwEAyWtGJwEACQT/DwAAAAAAAAAAAAAAAAAAAAABANAgwycPAAkE/w//D/8P /w//D/8P/w//D/8PAQBeRD8oAQAJBP8P/w//D/8P/w//D/8P/w//DwEAGApmKA8ACQT/D/8P/w// D/8P/w//D/8P/w8BALJCIikFAAkE/w//D/8P/w//D/8P/w//D/8PAQA0HTkpQk4gRf8PAAAAAAAA AAAAAAAAAAAAAAEA0x5aKSxxPGb/D/8P/w//D/8P/w//D/8P/w8BAAdG0ykPAAkE/w//D/8P/w// D/8P/w//D/8PAQA6a6MqDwAJBP8P/w//D/8P/w//D/8P/w//DwEAew6xKsSn0lf/D/8P/w//D/8P /w//D/8P/w8BAJsEuCoRAAkI/w//D/8P/w//D/8P/w//D/8PAQAQKvEqDwAJBP8P/w//D/8P/w// D/8P/w//DwEAVmW+K0JOIEX/D/8P/w//D/8P/w//D/8P/w8BAEcJvytMPyJ+/w//D/8P/w//D/8P /w//D/8PAQDkVMUrAQAJBP8P/w//D/8P/w//D/8P/w//DwEAyQX1KwEACQj/D/8P/w//D/8P/w// D/8P/w8BAI0h9SsBAAkE/w//D/8P/w//D/8P/w//D/8PAQC3QmQsAQAJCP8P/w//D/8P/w//D/8P /w//DwEA93JwLAEACQT/DwAAAAAAAAAAAAAAAAAAAAABAMswjyzEp9JX/w//D/8P/w//D/8P/w// D/8PAQAdERQtAQAJBP8P/w//D/8P/w//D/8P/w//DwEAFDBRLQEACQT/D/8P/w//D/8P/w//D/8P /w8BALIfZC0gHVD5/w//D/8P/w//D/8P/w//D/8PAQAPWLMtQk4gRf8P/w//D/8P/w//D/8P/w// DwEAOHUlLgEACQT/D/8P/w//D/8P/w//D/8P/w8BAEULaC4BAAkE/w//D/8P/w//D/8P/w//D/8P AQApNH0uAQAJBP8P/w//D/8P/w//D/8P/w//DwEAASHXLuJ5Nn7/D/8P/w//D/8P/w//D/8P/w8B AKZsGC8BAAkE/w//D/8P/w//D/8P/w//D/8PAQCQCyYvAQAJBP8P/w//D/8P/w//D/8P/w//DwEA hSBcLwEACQj/D/8P/w//D/8P/w//D/8P/w8BAKp4vy8BAAkE/w//D/8P/w//D/8P/w//D/8PAQDy fxAwbtdyCf8P/w//D/8P/w//D/8P/w//DwEAtCtuMCxxPGb/D/8P/w//D/8P/w//D/8P/w8BAE9F fDABAAkE/w//D/8P/w//D/8P/w//D/8PAQA9DYgwAQAJBP8P/w//D/8P/w//D/8P/w//DwEACVT1 MHyVJjD/D/8P/w//D/8P/w//D/8P/w8AAJ5+NTEBAAkE/w//D/8P/w//D/8P/w//D/8PAQA7YtQx XMKCN/8P/w//D/8P/w//D/8P/w//DwAA5l39MgUACQT/D/8P/w//D/8P/w//D/8P/w8BAIFZEjTE p9JX/w//D/8P/w//D/8P/w//D/8PAQBqbFk0YFy6w/8P/w//D/8P/w//D/8P/w//DwEAFSxaNA8A CQT/D/8P/w//D/8P/w//D/8P/w8BAE9hdjQBAAkE/w//D/8P/w//D/8P/w//D/8PAQBlLlE1su18 P/8P/w//D/8P/w//D/8P/w//DwAAMnpbNgEACQT/D/8P/w//D/8P/w//D/8P/w8BAAVGXTbEp9JX /w//D/8P/w//D/8P/w//D/8PAQBRNcQ2HrAwU/8P/w//D/8P/w//D/8P/w//DwEAmCPoNgEACQT/ DwAAAAAAAAAAAAAAAAAAAAABAHYPQjdATpbH/w//D/8P/w//D/8P/w//D/8PAQBhark3AwAJCP8P /w//D/8P/w//D/8P/w//DwEA5RK6NyxxPGb/D/8P/w//D/8P/w//D/8P/w8BAD838zeU7nxd/w// D/8P/w//D/8P/w//D/8PAADSQOQ4BQAJBP8P/w//D/8P/w//D/8P/w//DwEAYzrnOA8ACQT/D/8P /w//D/8P/w//D/8P/w8BAKZV/DgPAAkE/w//D/8P/w//D/8P/w//D/8PAQAEaAM5BQAJBP8P/w// D/8P/w//D/8P/w//DwEASDI+OQEACQT/D/8P/w//D/8P/w//D/8P/w8BAMs7hznEp9JX/w//D/8P /w//D/8P/w//D/8PAQAwBpc5AQAJCP8P/w//D/8P/w//D/8P/w//DwEADyTDOQEACQT/D/8P/w// D/8P/w//D/8P/w8BANxVxDkBAAkE/w//D/8P/w//D/8P/w//D/8PAQBLStE5AQAJBP8P/w//D/8P /w//D/8P/w//DwEAsGb3OQEACQT/DwAAAAAAAAAAAAAAAAAAAAABAF9aIjoBAAkE/w//D/8P/w// D/8P/w//D/8PAQC2Cl86AQAJBP8P/w//D/8P/w//D/8P/w//DwEA3xDUOgEACQT/DwAAAAAAAAAA AAAAAAAAAAABAEcxUDuY38hf/w//D/8P/w//D/8P/w//D/8PAQDzfNQ7AQAJBP8P/w//D/8P/w// D/8P/w//DwEAYQLeO0JOIEX/D/8P/w//D/8P/w//D/8P/w8BAC9jPjwBAAkE/w//D/8P/w//D/8P /w//D/8PAQBFVUs8DwAJBP8P/w//D/8P/w//D/8P/w//DwEA1hh4PAEACQT/D/8P/w//D/8P/w// D/8P/w8BAHpQ6DwBAAkE/w//D/8P/w//D/8P/w//D/8PAQA1d4M+HqCeAv8P/w//D/8P/w//D/8P /w//DwEAh020PgEACQT/D/8P/w//D/8P/w//D/8P/w8BAHkW2z7Ep9JX/w//D/8P/w//D/8P/w// D/8PAQA/FOU+AQAJCP8P/w//D/8P/w//D/8P/w//DwEACUkBPw8ACQT/D/8P/w//D/8P/w//D/8P /w8BAPsYUD8PAAkE/w//D/8P/w//D/8P/w//D/8PAQBbIl0/rG8KRv8P/w//D/8P/w//D/8P/w// DwAAZwKfPwEACQT/D/8P/w//D/8P/w//D/8P/w8BAMcIQ0DEp9JX/w//D/8P/w//D/8P/w//D/8P AQCtRb5B4nk2fv8P/w//D/8P/w//D/8P/w//DwEA+GzZQUJOIEX/D/8P/w//D/8P/w//D/8P/w8B APlH+0JmHyo7SwD/D/8P/w//D/8P/w//D/8PAQBWYndDDwAJBP8P/w//D/8P/w//D/8P/w//DwEA lB6qQw8ACQT/D/8P/w//D/8P/w//D/8P/w8BAJwFt0MBAAkI/w//D/8P/w//D/8P/w//D/8PAQAK X7lDkt/8pP8P/w//D/8P/w//D/8P/w//DwEAuCHFQ4xWpp3/D/8P/w//D/8P/w//D/8P/w8BAE8S 8ENCTiBF/w//D/8P/w//D/8P/w//D/8PAQDpdRdEAQAJBP8P/w//D/8P/w//D/8P/w//DwEA2gNy RAEACQT/D/8P/w//D/8P/w//D/8P/w8BAIBqfkR08T5//w//D/8P/w//D/8P/w//D/8PAQCxF41E Dmc+PDAA/w//D/8P/w//D/8P/w//DwEAwz69RAUACQT/D/8P/w//D/8P/w//D/8P/w8BANkLv0QB AAkI/w//D/8P/w//D/8P/w//D/8PAQB5QO9EIB1Q+f8P/w//D/8P/w//D/8P/w//DwEA9kPORQ8A CQj/D/8P/w//D/8P/w//D/8P/w8BAKZz1kUBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQARfPhFAQAJ BP8P/w//D/8P/w//D/8P/w//DwEAcQBLRgUACQT/D/8P/w//D/8P/w//D/8P/w8BAIIu+ka4AdYK /w//D/8P/w//D/8P/w//D/8PAQCdUPtGQk4gRf8P/w//D/8P/w//D/8P/w//DwEAcG4NR0JOIEX/ D/8P/w//D/8P/w//D/8P/w8BABFkJEe2X+4y/w//D/8P/w//D/8P/w//D/8PAQDfAD9HxKfSV/8P /w//D/8P/w//D/8P/w//DwEAUReJRwEACQT/D/8P/w//D/8P/w//D/8P/w8BACw2yUcBAAkI/w// D/8P/w//D/8P/w//D/8PAQD9b0pIAQAJBP8P/w//D/8P/w//D/8P/w//DwEAvkGSSAEACQT/D/8P /w//D/8P/w//D/8P/w8BADgpXUkBAAkE/w//D/8P/w//D/8P/w//D/8PAQBZF3NJDwAJBP8P/w// D/8P/w//D/8P/w//DwEA+kzMSdSChv//D/8P/w//D/8P/w//D/8P/w8BALcV2EkBAAkI/w//D/8P /w//D/8P/w//D/8PAQAXT/5JLHE8Zv8P/w//D/8P/w//D/8P/w//DwEA7AxCSlbfmPH/D/8P/w// D/8P/w//D/8P/w8BAP4vV0oPAAkE/w//D/8P/w//D/8P/w//D/8PAQA0RF5KqvKod/8P/w//D/8P /w//D/8P/w//DwEAolKRSkJOIEX/D/8P/w//D/8P/w//D/8P/w8BALkXB0tMPyJ+/w//D/8P/w// D/8P/w//D/8PAQD4WSpLAQAJBP8P/w//D/8P/w//D/8P/w//DwEALB5bSxEACQj/D/8P/w//D/8P /w//D/8P/w8BALx1dEsFAAkE/w//D/8P/w//D/8P/w//D/8PAQBOZndLBQAJBP8P/w//D/8P/w// D/8P/w//DwEAzUWYSxEACQj/D/8P/w//D/8P/w//D/8P/w8BAKNa3ksBAAkE/w//D/8P/w//D/8P /w//D/8PAQBLD/tLAQAJBP8P/w//D/8P/w//D/8P/w//DwEAn3FoTAEACQT/D/8P/w//D/8P/w// D/8P/w8BAEw8gUzEp9JX/w//D/8P/w//D/8P/w//D/8PAQCAEahMsrdKEf8P/w//D/8P/w//D/8P /w//DwEAzBP8TIraZMT/D/8P/w//D/8P/w//D/8P/w8BAC85mk6Ayzb4/w//D/8P/w//D/8P/w// D/8PAQC7HadOQk4gRf8P/w//D/8P/w//D/8P/w//DwEAs22wTixxPGb/D/8P/w//D/8P/w//D/8P /w8BAA4VFU8PAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQBBAyxPDwAJBP8P/w//D/8P/w//D/8P/w// DwEAIBCNTyxxPGb/D/8P/w//D/8P/w//D/8P/w8BAHBGQlABAAkE/w8AAAAAAAAAAAAAAAAAAAAA AQCdC0RQbtdyCf8P/w//D/8P/w//D/8P/w//DwEAvwxYUJAkevv/D/8P/w//D/8P/w//D/8P/w8A ABYbbVABAAkE/w//D/8P/w//D/8P/w//D/8PAQC5ArJQDwAJBP8P/w//D/8P/w//D/8P/w//DwEA iiTvUBEACQT/D/8P/w//D/8P/w//D/8P/w8BANIsOVEPAAkE/w//D/8P/w//D/8P/w//D/8PAQDA VmhRAQAJCP8P/w//D/8P/w//D/8P/w//DwEANFpoUQEACQT/D/8P/w//D/8P/w//D/8P/w8BAAQR 2FEscTxm/w//D/8P/w//D/8P/w//D/8PAQBVfX5SxKfSV/8P/w//D/8P/w//D/8P/w//DwEAtV7y UgEACQT/D/8P/w//D/8P/w//D/8P/w8BAOhNMVOOSbRK/w//D/8P/w//D/8P/w//D/8PAQCseU1T DwAJBP8P/w//D/8P/w//D/8P/w//DwEAFDCHUw8ACQT/D/8P/w//D/8P/w//D/8P/w8BAM4tZ1QB AAkE/w//D/8P/w//D/8P/w//D/8PAQCeV3VUAQAJBP8P/w//D/8P/w//D/8P/w//DwEAJkPIVAEA CQT/D/8P/w//D/8P/w//D/8P/w8BAFdz2lQFAAkE/w//D/8P/w//D/8P/w//D/8PAQAgfztVAQAJ BP8P/w//D/8P/w//D/8P/w//DwEAaGfKVQEACQT/D/8P/w//D/8P/w//D/8P/w8BACoUzlUAEOD6 /w//D/8P/w//D/8P/w//D/8PAADoQ+BVorWGvv8P/w//D/8P/w//D/8P/w//DwEAH2kDVgEACQT/ D/8P/w//D/8P/w//D/8P/w8BAPUvCFYBAAkI/w//D/8P/w//D/8P/w//D/8PAQBIYiRWAQAJBP8P /w//D/8P/w//D/8P/w//DwEA4VFjVkJOIEX/D/8P/w//D/8P/w//D/8P/w8BAP9ImFYPAAkE/w// D/8P/w//D/8P/w//D/8PAQDnBqRWDwAJBP8P/w//D/8P/w//D/8P/w//DwEAlQnZVjDxXqb/D/8P /w//D/8P/w//D/8P/w8BAPEARFcBAAkE/w//D/8P/w//D/8P/w//D/8PAQBRd1tXIB1Q+f8P/w// D/8P/w//D/8P/w//DwEAHQqGVwEACQj/D/8P/w//D/8P/w//D/8P/w8BAMFj91dCTiBF/w8AAAAA AAAAAAAAAAAAAAAAAQD4NBdY4nk2fv8P/w//D/8P/w//D/8P/w//DwEADzkXWEw/In7/D/8P/w// D/8P/w//D/8P/w8BADwuxFgidFxZ/w//D/8P/w//D/8P/w//D/8PAQCADwNZQk4gRf8P/w//D/8P /w//D/8P/w//DwEA5lwaWgUACQT/D/8P/w//D/8P/w//D/8P/w8BAMJiGlpqQjD+/w//D/8P/w// D/8P/w//D/8PAQD/L1FaDwAJBP8P/w//D/8P/w//D/8P/w//DwEAfwpeWgEACQT/D/8P/w//D/8P /w//D/8P/w8BAJJagVoBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQD6Y4xaAQAJBP8P/w//D/8P/w// D/8P/w//DwEACB7WWgEACQT/D/8P/w//D/8P/w//D/8P/w8BAJ4jRVsBAAkE/w//D/8P/w//D/8P /w//D/8PAQC/W7Rb1IKG//8P/w//D/8P/w//D/8P/w//DwEAwzbYWwEACQT/D/8P/w//D/8P/w// D/8P/w8BAHswP1wFAAkE/w//D/8P/w//D/8P/w//D/8PAQDdKJJcAQAJCP8P/w//D/8P/w//D/8P /w//DwEAGyzBXAEACQT/D/8P/w//D/8P/w//D/8P/w8BACYVfF0BAAkE/w//D/8P/w//D/8P/w// D/8PAQDtFdldiOUe7/8P/w//D/8P/w//D/8P/w//DwEAxnTvXUJOIEX/D/8P/w//D/8P/w//D/8P /w8BANhH9V0BAAkE/w//D/8P/w//D/8P/w//D/8PAQDoNi1exKfSV/8P/w//D/8P/w//D/8P/w// DwEAvD4xXgEACQT/DwAAAAAAAAAAAAAAAAAAAAABAMpIi14BAAkE/w//D/8P/w//D/8P/w//D/8P AQDeONdeAwAJBP8PAAAAAAAAAAAAAAAAAAAAAAEAAVsOXwEACQT/D/8P/w//D/8P/w//D/8P/w8B AEcHGV9cRtgP/w//D/8P/w//D/8P/w//D/8PAQAwYptgAQAJBP8PAAAAAAAAAAAAAAAAAAAAAAEA k2LUYBEACQj/D/8P/w//D/8P/w//D/8P/w8BAFU752APAAkE/w//D/8P/w//D/8P/w//D/8PAQC3 SPtgQk4gRf8P/w//D/8P/w//D/8P/w//DwEATiUsYaDtoMf/D/8P/w//D/8P/w//D/8P/w8BACk3 h2G+olxh/w//D/8P/w//D/8P/w//D/8PAQCaUr1hhnhObP8P/w//D/8P/w//D/8P/w//DwAAoQYI YiSNGur/D/8P/w//D/8P/w//D/8P/w8AADEbOmK+olxh/w//D/8P/w//D/8P/w//D/8PAQDhR3di btdyCf8P/w//D/8P/w//D/8P/w//DwEAEEuVYgEACQT/D/8P/w//D/8P/w//D/8P/w8BALYjE2MB AAkE/w//D/8P/w//D/8P/w//D/8PAQA5dzBjLHE8Zv8P/w//D/8P/w//D/8P/w//DwEA2ztJY0JO IEX/D/8P/w//D/8P/w//D/8P/w8BAIVtnmMBAAkE/w//D/8P/w//D/8P/w//D/8PAQA4N+ZjQk4g Rf8P/w//D/8P/w//D/8P/w//DwEAwzMbZCC3eiH/D/8P/w//D/8P/w//D/8P/w8BAAV3kmQ8drhf /w//D/8P/w//D/8P/w//D/8PAACsHKpkAQAJBP8P/w//D/8P/w//D/8P/w//DwEA0nPsZAEACQT/ D/8P/w//D/8P/w//D/8P/w8BADQSg2UBAAkE/w//D/8P/w//D/8P/w//D/8PAQANcYVlbtdyCf8P /w//D/8P/w//D/8P/w//DwEAwB+rZcSn0lf/D/8P/w//D/8P/w//D/8P/w8BANJ3YmYFAAkE/w// D/8P/w//D/8P/w//D/8PAQABDAlnIB1Q+f8P/w//D/8P/w//D/8P/w//DwEAUiG6Zw8ACQT/D/8P /w//D/8P/w//D/8P/w8BACYa6WfUtdje/w//D/8P/w//D/8P/w//D/8PAQDMFy9oAQAJBP8P/w// D/8P/w//D/8P/w//DwEArGXHaAEACQT/D/8P/w//D/8P/w//D/8P/w8BAIFVymgBAAkE/w//D/8P /w//D/8P/w//D/8PAQBSXThpBQAJBP8P/w//D/8P/w//D/8P/w//DwEAfXL3aQEACQT/D/8P/w// D/8P/w//D/8P/w8BAMAHAWoBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQBCMBNqHrAwU/8P/w//D/8P /w//D/8P/w//DwEAm0U4asSn0lf/D/8P/w//D/8P/w//D/8P/w8BABtzgGo0SW5L/w//D/8P/w// D/8P/w//D/8PAABZacJqAQAJBP8P/w//D/8P/w//D/8P/w//DwEA6kQpaxEACQj/D/8P/w//D/8P /w//D/8P/w8BAN0uXWsBAAkE/w//D/8P/w//D/8P/w//D/8PAQBtNWhrAQAJBP8P/w//D/8P/w// D/8P/w//DwEALlV8a0JOIEX/D/8P/w//D/8P/w//D/8P/w8BACN71GsBAAkE/w//D/8P/w//D/8P /w//D/8PAQDTA9hrDwAJBP8P/w//D/8P/w//D/8P/w//DwEAAV1CbAEACQT/D/8P/w//D/8P/w// D/8P/w8BAMMJU2wPAAkE/w//D/8P/w//D/8P/w//D/8PAQDmRFVsAQAJBP8PAAAAAAAAAAAAAAAA AAAAAAEAOzrxbAEACQT/D/8P/w//D/8P/w//D/8P/w8BAHBZMm0idFxZ/w//D/8P/w//D/8P/w// D/8PAQB8NcdtxKfSV/8P/w//D/8P/w//D/8P/w//DwEAzkjHbQEACQT/DwAAAAAAAAAAAAAAAAAA AAABAEBsJm4PAAkE/w//D/8P/w//D/8P/w//D/8PAQBsN2duvqJcYf8P/w//D/8P/w//D/8P/w// DwEACXmXbgEACQT/D/8P/w//D/8P/w//D/8P/w8BAE4+nW4BAAkI/w//D/8P/w//D/8P/w//D/8P AQC/QBVvAQAJBP8P/w//D/8P/w//D/8P/w//DwEAVlsWbwUACQT/D/8P/w//D/8P/w//D/8P/w8B AANXH2/2TDql/w//D/8P/w//D/8P/w//D/8PAAAfR1hvAQAJBP8P/w//D/8P/w//D/8P/w//DwEA GmZpbwUACQT/D/8P/w//D/8P/w//D/8P/w8BAL8fk28PAAkE/w//D/8P/w//D/8P/w//D/8PAQA8 Tp5vEQAJCP8P/w//D/8P/w//D/8P/w//DwEAAEa8bw8ACQT/D/8P/w//D/8P/w//D/8P/w8BAFMu EnABAAkE/w//D/8P/w//D/8P/w//D/8PAQBfAXVwDwAJBP8P/w//D/8P/w//D/8P/w//DwEAVDd6 cAEACQT/D/8P/w//D/8P/w//D/8P/w8BACcPmnAidFxZ/w//D/8P/w//D/8P/w//D/8PAQDMXalw AQAJBP8P/w//D/8P/w//D/8P/w//DwEAA2+6cCxxPGb/D/8P/w//D/8P/w//D/8P/w8BAFBR93EB AAkE/w//D/8P/w//D/8P/w//D/8PAQD+QQRyBQAJBP8P/w//D/8P/w//D/8P/w//DwEAfBHOcnpN TFT/D/8P/w//D/8P/w//D/8P/w8BAGN34XIPAAkE/w//D/8P/w//D/8P/w//D/8PAQBZPhVzIB1Q +f8P/w//D/8P/w//D/8P/w//DwEA4kgVc0JOIEX/D/8P/w//D/8P/w//D/8P/w8BACRDM3MBAAkI /w//D/8P/w//D/8P/w//D/8PAQA2a5VzBQAJBP8P/w//D/8P/w//D/8P/w//DwEAp0/ec0JOIEX/ D/8P/w//D/8P/w//D/8P/w8BALRH4XMBAAkE/w//D/8P/w//D/8P/w//D/8PAQAqNe5zDwAJBP8P /w//D/8P/w//D/8P/w//DwEAjBqkdBEACQj/D/8P/w//D/8P/w//D/8P/w8BAJxp6XQFAAkE/w// D/8P/w//D/8P/w//D/8PAQBwf3N1AQAJBP8P/w//D/8P/w//D/8P/w//DwEAGmWQdQ8ACQT/DwAA AAAAAAAAAAAAAAAAAAABAKRJmXUscTxm/w//D/8P/w//D/8P/w//D/8PAQB8PMR1LHE8Zv8P/w// D/8P/w//D/8P/w//DwEAC3TudQEACQT/D/8P/w//D/8P/w//D/8P/w8BAOBRPXbEp9JX/w//D/8P /w//D/8P/w//D/8PAQAXJXt2esKMuf8P/w//D/8P/w//D/8P/w//DwEAiAXbdvwrkq3/D/8P/w// D/8P/w//D/8P/w8BAHIuxncPAAkE/w//D/8P/w//D/8P/w//D/8PAQDrWsp3AQAJCP8P/w//D/8P /w//D/8P/w//DwEAfwHSd0JOIEX/D/8P/w//D/8P/w//D/8P/w8BADQ3+HcBAAkE/w//D/8P/w// D/8P/w//D/8PAQDVEjN4LHE8Zv8P/w//D/8P/w//D/8P/w//DwEABVBneAEACQT/D/8P/w//D/8P /w//D/8P/w8BAAVM33gBAAkE/w//D/8P/w//D/8P/w//D/8PAQAIHfx4CwAJBP8P/w//D/8P/w// D/8P/w//DwEA/BWBeSxxPGb/D/8P/w//D/8P/w//D/8P/w8BAFg9rXkPAAkE/w//D/8P/w//D/8P /w//D/8PAQAHd/t5AQAJBP8P/w//D/8P/w//D/8P/w//DwEAxCMAeg8ACQT/D/8P/w//D/8P/w// D/8P/w8BAAZTCHoBAAkE/w8AAAAAAAAAAAAAAAAAAAAAAQChFlZ6Qk4gRf8PAAAAAAAAAAAAAAAA AAAAAAEAtyOdem7lOub/D/8P/w//D/8P/w//D/8P/w8AAGYzrnoBAAkI/w//D/8P/w//D/8P/w// D/8PAQCMc8R6AQAJBP8P/w//D/8P/w//D/8P/w//DwEA2V40ewEACQT/D/8P/w//D/8P/w//D/8P /w8BACQQ+3sBAAkE/w//D/8P/w//D/8P/w//D/8PAQAkbkN8BQAJBP8P/w//D/8P/w//D/8P/w// DwEAmQ1ffNS12N7/D/8P/w//D/8P/w//D/8P/w8BAGVnYXwBAAkE/w//D/8P/w//D/8P/w//D/8P AQCucG98Yi2MJv8P/w//D/8P/w//D/8P/w//DwEAdHFvfB6wMFP/D/8P/w//D/8P/w//D/8P/w8B AOFm5nwBAAkI/w//D/8P/w//D/8P/w//D/8PAQC4Z1V9LHE8Zv8P/w//D/8P/w//D/8P/w//DwEA sheEfcSn0lf/D/8P/w//D/8P/w//D/8P/w8BACsyEX4BAAkE/w//D/8P/w//D/8P/w//D/8PAQCD Mx9+AQAJCP8P/w//D/8P/w//D/8P/w//DwEApk9sfkJOIEX/D/8P/w//D/8P/w//D/8P/w8BAFg3 fH4BAAkE/w//D/8P/w//D/8P/w//D/8PAQD8QsZ+DwAJBP8PAAAAAAAAAAAAAAAAAAAAAAEATwTi fgEACQj/D/8P/w//D/8P/w//D/8P/w8BADt8a3/I7rxv/w//D/8P/w//D/8P/w//D/8PAQAUV49/ AQAJBP8P/w//D/8P/w//D/8P/w//DwEAk2qmf27Xcgn/D/8P/w//D/8P/w//D/8P/w8BADsNuH8B AAkE/w//D/8P/w//D/8P/w//D/8PAQBEXcF//Hl+pf8P/w//D/8P/w//D/8P/w//DwEAyEzefwEA CQT/D/8P/w//D/8P/w//D/8P/w8BAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhAgHEYSY /hXGBQABCAcGAgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFo AQYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBR SgEAbygAAQC38AEAAAAAQAEAAAAAAAAAAACQAAAAAAAAAAAAAAACAAAALgABAAAAAEABAwAAAAAA AAAAkAAAAAAAAAAAAAAAAwAAAC4AAQABAAAAAEABAwUAAAAAAAAAkAAAAAAAAAAAAAAABQAAAC4A AQAuAAIAAQAAAABAAQMFBwAAAAAAAJAAAAAAAAAAAAAAAAcAAAAuAAEALgACAC4AAwABAAAAAEAB AwUHCQAAAAAAkAAAAAAAAAAAAAAACQAAAC4AAQAuAAIALgADAC4ABAABAAAAAEABAwUHCQsAAAAA kAAAAAAAAAAAAAAACwAAAC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAABAAQMFBwkLDQAAAJAAAAAA AAAAAAAAAA0AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAAAEABAwUHCQsNDwAAkAAAAAAA AAAAAAAADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAEABAwUHCQsNDxEAkAAA AAAAAAAAAAAAEQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAEAKgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4V xgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY /hXGBQABaAEGAgAAAC4AAQAAAABAAQAAAAAAAAAAAAAAAABoAQAAAAgAAA+EaAERhJj+AgAAAC4A AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEA t/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygA AQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBv KAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoB AG8oAAEAK/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBR SgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oB AFFKAQBvKAABAKjwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZv KAABAGHwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oB AFFKAQBvKAABAC3wAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZP SgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgB BgIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFK AQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEA UUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9K AQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEG T0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADhAAAA+EaAERhJj+FcYFAAFo AQZCKgBPSgEAUUoBAG8oAAEAt/ABAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAVEAAAD4TQAhGEMP0V xgUAAdACBjUIATYIAENKFgBPSgAAUUoAAG8oAAMAUgAtAAAAAQAAAAAAAQMAAAAAAAAAAAAAAAAA AAAAABAAAA+EGAMRhFD+FcYFAAEYAwYEAAAALgABAC4AAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAA ABAAAA+EyAQRhAj+FcYFAAHIBAYGAAAALgABAC4AAgAuAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAA AAAQAAAPhMAGEYR4/RXGBQABwAYGCAAAAC4AAQAuAAIALgADAC4AAQAAAAAAAQMFBwkAAAAAAAAA AAAAAAAAABAAAA+EuAgRhOj8FcYFAAG4CAYKAAAALgABAC4AAgAuAAMALgAEAC4AAQAAAAAAAQMF BwkLAAAAAAAAAAAAAAAAABAAAA+EsAoRhFj8FcYFAAGwCgYMAAAALgABAC4AAgAuAAMALgAEAC4A BQAuAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAAQAAAPhKgMEYTI+xXGBQABqAwGDgAAAC4AAQAu AAIALgADAC4ABAAuAAUALgAGAC4AAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAABAAAA+EoA4RhDj7 FcYFAAGgDgYQAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4AAQAAAAAAAQMFBwkLDQ8R AAAAAAAAAAAAABAAAA+E4BARhGD6FcYFAAHgEAYSAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYA LgAHAC4ACAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oB AFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYC AAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBR SgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8QAAAPhGgBEYSY/hXGBQABaAEGQ0oQ AE9KAQBRSgEAbygAAQAt8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQAB aAEGT0oBAFFKAQBvKAABALfwBwAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYF AAFoAQZPSgEAUUoBAG8oAAEAt/BYAgAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4TQAhGEMP0V xgUAAdACBk9KCABRSggAbygAAQDw8AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY /hXGBQABaAEGAgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFo AQYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBR SgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oB AFFKAQBvKAABALfwAQAAAABAAQAAAAAAAAAAAAAAAABoAQAAAAgAAA+EaAERhJj+AgAAAC4AAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSggAUUoIAG8oAAEAp/AB AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAEAYfABAAAAFwAA AAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAA QAEAAAAAAAAAAAAAAAAAaAEAAAAIAAAPhGgBEYSY/gIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAA AAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAA AAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSggAUUoIAG8oAAEA2PABAAAAFwAAAAAAAAAAAAAA AAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAA AAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAAAMACgAAAAAA AAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAEIBwYKAEEAcABwAGUAbgBkAGkAeAAgAAAAAQAA AAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38FgCAAAXAAAA AAAAAAAAAAAAAAAAAAAAAAsQAAAPhNACEYQw/RXGBQAB0AIGT0oIAFFKCABvKAABAPDwAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAAPEAAAD4RoARGEmP4VxgUAAWgBBkNKEABPSgEAUUoBAG8oAAEA LfABAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4SIAhGEUP4VxgUAAYgCBgMAWwAAAF0AAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAADhAAAA+EaAERhJj+FcYFAAFoAQZCKgBPSgEAUUoBAG8oAAEA t/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAApAAEAAAAA AAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAA AAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oBAFFKAQBvKAABAC3wAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQCu 8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA4QAAAPhGgBEYSY/hXGBQABaAEGQioAT0oBAFFKAQBv KAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAACAAAA LgABAAAAAAQBAwAAAAAAAAAAAAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAMAAAAuAAEA AQAAAAAEAQMFAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAAFAAAALgABAC4A AgABAAAAAAQBAwUHAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAcAAAAuAAEA LgACAC4AAwABAAAAAAQBAwUHCQAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAkA AAAuAAEALgACAC4AAwAuAAQAAQAAAAAEAQMFBwkLAAAAAAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYF AAE4BAZvKAALAAAALgABAC4AAgAuAAMALgAEAC4ABQABAAAAAAQBAwUHCQsNAAAAAAAAAAAAAAAD EAAAD4Q4BBGEyPsVxgUAATgEBm8oAA0AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAAAAQB AwUHCQsNDwAAAAAAAAAAAAADEAAAD4SgBRGEYPoVxgUAAaAFBm8oAA8AAAAuAAEALgACAC4AAwAu AAQALgAFAC4ABgAuAAcAAQAAAAAEAQMFBwkLDQ8RAAAAAAAAAAAAAxAAAA+EoAURhGD6FcYFAAGg BQZvKAARAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAABAAAAFwAAAAAAAAAAAAAA AAAAAAAAAAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQC38AEAAAAAAAEAAAAA AAAAAAAAAAAAAAAAAAAQAAAPhNgAEYQo/xXGBQABaAEGAgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAA AAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAP EAAAD4RoARGEmP4VxgUAAWgBBkNKEABPSgEAUUoBAG8oAAEALfABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oIAFFKCABvKAABAKfwAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oBAFFKAQBvKAABAC3wAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgkAUUoJAG8oAAEAYfABAAAAFwAA AAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AB AAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgMAWwAAAF0AAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KCABRSggAbygAAQCn8AEA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhNACEYSY/hXGBQAB0AIGbygAAgAAACkAAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAA AEABAAAAAAAAAAAAAAAAAGgBAAAACAAAD4RoARGEmP4CAAAALgABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oIAFFKCABvKAABAKfwAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAA AAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAA AAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAADhAAAA+EaAERhJj+FcYFAAFoAQZCKgBPSgEAUUoBAG8oAAEAt/ABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KCABRSggAbygAAQCn8AEA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAA AAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AB AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC3 8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oIAFFKCABvKAAB AKfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8o AAEAt/ADAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAGEAAAD4QMAxGEmP4VxgUAAQwDBjUIAW8oAAEA AAABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygA AQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBv KAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoB AG8oAAEAK/ABAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAdACBgUAUgAx AC0AAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFK AQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEA UUoBAG8oAAEAt/ABAAAAAEABAAAAAAAAAAAAAAAAAGgBAAAACAAAD4RoARGEmP4CAAAALgABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEA AAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfw AQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAACAAAAKQABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAADhAAAA+EaAERhJj+FcYFAAFoAQZCKgBPSgEAUUoBAG8oAAEAt/ABAAAA AAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAXAAAAAAAA AAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAAB AAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAXAAAAAAAAAAAA AAAAAAAAAAAAAA8QAAAPhGgBEYSY/hXGBQABaAEGQ0oQAE9KAQBRSgEAbygAAQAt8AEAAAAAQAEA AAAAAAAAAAAAAAAAaAEAAAAIAAAPhGgBEYSY/gIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA AAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAgAAABcAAAAAAAAAAAAAAAAAAAAA AAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38FgCAAAXAAAAAAAAAAAAAAAA AAAAAAAAAAsQAAAPhNACEYQw/RXGBQAB0AIGT0oIAFFKCABvKAABAPDwAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAEABAAAAAAAA AAAAAAAAAGgBAAAACAAAD4RoARGEmP4CAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAA D4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQ AAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA CxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAA AAAPEAAAD4RoARGEmP4VxgUAAWgBBkNKEABPSgEAUUoBAG8oAAEALfABAAAAFwAAAAAAAAAAAAAA AAAAAAAAAAAPEAAAD4RoARGEmP4VxgUAAWgBBkNKEABPSgEAUUoBAG8oAAEALfABAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAA AAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KCQBRSgkAbygAAQBh8AEA AAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfw AQAAAAAACQAAAAAAAAAAAQAAAAAAAAAAAAAAAAkAQwBoAGEAcAB0AGUAcgAgAAAAAQAAAAAAAQMA AAAAAAAAAgAAAAAAAAAAAAAAAAMAAAAuAAEAAQAAAAAAAQMFAAAAAAAAAgAAAAAAAAAAAAAAAAUA AAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAIAAAAAAAAAAAAAAAAHAAAALgABAC4AAgAuAAMAAQAA AAAAAQMFBwkAAAAAAgAAAAAAAAAAAAAAAAkAAAAuAAEALgACAC4AAwAuAAQAAQAAAP8AAAAAAAAA AAAAAgAAAAAAAAAAAAAAAAAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAQAAAP8AAAAA AAAAAAAAAgAAAAAAAAAAAAAAAAAAAQAAAP8AAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAABAAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAABAAAAAgAAAAAAAQMAAAAA AAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAADAAAALgABAAIAAAAAAAEDBQAAAAAA AAAAAAAAAAAAAAMQAAAPhNACEYQw/RXGBQAB0AIGbygABQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAA AAAAAAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAAHAAAALgABAC4AAgAuAAMAAQAAAAAA AQMFBwkAAAAAAAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYFAAE4BAZvKAAJAAAALgABAC4AAgAuAAMA LgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAMQAAAPhDgEEYTI+xXGBQABOAQGbygACwAAAC4A AQAuAAIALgADAC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAAxAAAA+EoAURhGD6FcYF AAGgBQZvKAANAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAA AAAAAxAAAA+EoAURhGD6FcYFAAGgBQZvKAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAH AAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAMQAAAPhAgHEYT4+BXGBQABCAcGbygAEQAAAC4AAQAu AAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgAAQAAAARAAQAAAAAAAAAAAAAAAABoAQAAAAgAAA+E ggQRhJj+AgAAACkAAQAAAABAAQAAAAAAAAAAAAAAAABoAQAAAAgAAA+EaAERhJj+AgAAAC4AAQAA AAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAACAAAAKQABAAAAFwAA AAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KCABRSggAbygAAQCn8AEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAA8QAAAPhGgBEYSY/hXGBQABaAEGQ0oQAE9KAQBRSgEAbygAAQAt 8AEAAAAAAAMAAAAAAAAAAAAAAAAAAAAAAAYQAAAPhGgBEYSY/hXGBQAB0AIGNQgANggBBABbAFIA AABdAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AB AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC3 8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAAB ALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8o AAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBR SgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oI AFFKCABvKAABANjwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZP SggAUUoIAG8oAAEAp/ABAAAAAAAJAAAAAAAAAAABAAAAAAAAAAAKAAAANQgBNggAQ0ogAAkAQwBo AGEAcAB0AGUAcgAgAAAAAQAAAAAEAQMAAAAAAAAAAQAAAAAAAAAACgAAADUIATYIAENKGAADAAAA LgABAAEAAAAABAEDBQAAAAAAAAEAAAAAAAAAAAoAAAA1CAE2CABDShgABQAAAC4AAQAuAAIAAQAA AAAEAQMFBwAAAAAAAQAAAAAAAAAACgAAADUIATYIAENKGAAHAAAALgABAC4AAgAuAAMAAQAAAAAE AQMFBwkAAAAAAQAAAAAAAAAACgAAADUIATYIAENKGAAJAAAALgABAC4AAgAuAAMALgAEAAEAAAD/ AAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAEAAAD/AAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAEA AAD/AAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAEAAAD/AAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAA AAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAAB ALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8o AAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBR SgEAbygAAQC38AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAA AC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8o AAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEA bygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA4QAAAPhGgBEYSY/hXGBQABaAEGQioAT0oB AFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYC AAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEA bygAAQC38AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4A AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEA t/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oIAFFKCABvKAABAKfwAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAADhAAAA+EaAERhJj+FcYFAAFoAQZCKgBPSgEAUUoBAG8oAAEA t/ABAAAAAEABAAAAAAAAAAAAAAAAAGgBAAAACAAAD4RoARGEmP4CAAAALgABAAAAAAABAAAAAAAA AAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAA AA+EaAERhJj+FcYFAAFoAQZDShAAT0oBAFFKAQBvKAABAC3wAQAAAAAAAQAAAAAAAAAAAAAAAAAA AAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAAKQABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAA D4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA4QAAAPhGgBEYSY /hXGBQABaAEGQioAT0oBAFFKAQBvKAABALfwAQAAAARAAQAAAAAAAAAAAAAAAABoAQAAAAgAAA+E ggQRhJj+AgAAACkAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZP SgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgB Bk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQAB aAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYF AAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4V xgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8QAAAPhGgBEYSY /hXGBQABaAEGQ0oQAE9KAQBRSgEAbygAAQAt8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAP hGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAA AA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAO EAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAA AAAAAA4QAAAPhGgBEYSY/hXGBQABaAEGQioAT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAA AAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAA AAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgkAUUoJAG8oAAEAYfABAAAAFwAA AAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AB AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC3 8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAAB ACvwAQAAAABAAQAAAAAAAAAAAAAAAABoAQAAAAgAAA+EaAERhJj+AgAAAC4AAQAAABcAAAAAAAAA AAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AQAAAAAAAEA AAAAAAAAAAAAAAAAAAAAAAMQAAAPhNACEYQw/RXGBQAB0AIGbygAAQAAAAIAAAAAAAEDAAAAAAAA AAAAAAAAAAAAAAMQAAAPhNACEYQw/RXGBQAB0AIGbygAAwAAAC4AAQABAAAAAAABAwUAAAAAAAAA AAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAA AAAAAAAAAAAAAAMQAAAPhNACEYQw/RXGBQAB0AIGbygABwAAAC4AAQAuAAIALgADAAEAAAAAAAED BQcJAAAAAAAAAAAAAAAAAAMQAAAPhDgEEYTI+xXGBQABOAQGbygACQAAAC4AAQAuAAIALgADAC4A BAABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAADEAAAD4Q4BBGEyPsVxgUAATgEBm8oAAsAAAAuAAEA LgACAC4AAwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMQAAAPhKAFEYRg+hXGBQAB oAUGbygADQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAA AAMQAAAPhKAFEYRg+hXGBQABoAUGbygADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAB AAAAAAABAwUHCQsNDxEAAAAAAAAAAAADEAAAD4QIBxGE+PgVxgUAAQgHBm8oABEAAAAuAAEALgAC AC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgB EYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+E sAERhFD+FcYFAAGwAQYBAAAAAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAABAAAA+EQAIRhMD9FcYF AAFAAgYDAAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAAQAAAPhNACEYQw/RXGBQAB0AIG BQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAABAAAA+EYAMRhKD8FcYFAAFgAwYH AAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAABAAAA+E8AMRhBD8FcYFAAHw AwYJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAAQAAAPhIAEEYSA +xXGBQABgAQGCwAAAC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAA ABAAAA+EEAURhPD6FcYFAAEQBQYNAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMF BwkLDQ8AAAAAAAAAAAAAABAAAA+EoAURhGD6FcYFAAGgBQYPAAAALgABAC4AAgAuAAMALgAEAC4A BQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAAQAAAPhDAGEYTQ+RXGBQABMAYGEQAA AC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA CxAAAA+EaAERhJj+FcYFAAFoAQZPSggAUUoIAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAA AAAPEAAAD4RoARGEmP4VxgUAAWgBBkNKEABPSgEAUUoBAG8oAAEALfACAAAAFwAAAAAAAAAAAAAA AAAAAAAAAAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAEALQABAAAAAAABAAAAAAAAAAAAAAAAAAAA AAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQ AAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwBAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAA AxAAAA+E0AIRhDD9FcYFAAHQAgZvKAABAAAAAgAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAAxAAAA+E 0AIRhDD9FcYFAAHQAgZvKAADAAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAMQAAAPhNAC EYQw/RXGBQAB0AIGbygABQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAAxAAAA+E 0AIRhDD9FcYFAAHQAgZvKAAHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAA AxAAAA+EOAQRhMj7FcYFAAE4BAZvKAAJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAAAEDBQcJCwAA AAAAAAAAAAAAAAMQAAAPhDgEEYTI+xXGBQABOAQGbygACwAAAC4AAQAuAAIALgADAC4ABAAuAAUA AQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAAxAAAA+EoAURhGD6FcYFAAGgBQZvKAANAAAALgABAC4A AgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAAxAAAA+EoAURhGD6FcYF AAGgBQZvKAAPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAA AAAAAAAAAAMQAAAPhAgHEYT4+BXGBQABCAcGbygAEQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAG AC4ABwAuAAgAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEA UUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAPEAAAD4RoARGEmP4VxgUAAWgBBkNK EABPSgEAUUoBAG8oAAEALfBYAgAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4TQAhGEMP0VxgUA AdACBk9KCABRSggAbygAAQDw8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXG BQABaAEGT0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EOAQRhJj+ FcYFAAE4BAZvKAACAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUA AWgBBk9KAQBRSgEAbygAAQCo8AEAAAAAQAEAAAAAAAAAAAAAAAAAaAEAAAAIAAAPhGgBEYSY/gIA AAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhGgBEYSY/hXGBQABaAEGbygAAgAAAC4A AQAAAAAEAQMAAAAAAAAAAAAAAAAAAAAAAxAAAA+EMAMRhDj+FcYFAAEwAwZvKAADAAAALgABAAEA AAAABAEDBQAAAAAAAAAAAAAAAAAAAAMQAAAPhKAFEYQw/RXGBQABoAUGbygABQAAAC4AAQAuAAIA AQAAAAAEAQMFBwAAAAAAAAAAAAAAAAAAAxAAAA+EcAgRhMj7FcYFAAFwCAZvKAAHAAAALgABAC4A AgAuAAMAAQAAAAAEAQMFBwkAAAAAAAAAAAAAAAAAAxAAAA+E2AkRhMj7FcYFAAHYCQZvKAAJAAAA LgABAC4AAgAuAAMALgAEAAEAAAAABAEDBQcJCwAAAAAAAAAAAAAAAAMQAAAPhKgMEYRg+hXGBQAB qAwGbygACwAAAC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAAAEAQMFBwkLDQAAAAAAAAAAAAAAAxAA AA+EEA4RhGD6FcYFAAEQDgZvKAANAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYAAQAAAAAEAQMF BwkLDQ8AAAAAAAAAAAAAAxAAAA+E4BARhPj4FcYFAAHgEAZvKAAPAAAALgABAC4AAgAuAAMALgAE AC4ABQAuAAYALgAHAAEAAAAABAEDBQcJCw0PEQAAAAAAAAAAAAMQAAAPhEgSEYT4+BXGBQABSBIG bygAEQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgAAQAAABcAAAAAAAAAAAAAAAAA AAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSggAUUoIAG8oAAEAp/ABAAAAAAABAAAAAAAAAAAA AAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAA AAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+E aAERhJj+FcYFAAFoAQZPSggAUUoIAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAA D4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8Q AAAPhGgBEYSY/hXGBQABaAEGQ0oQAE9KAQBRSgEAbygAAQAt8AEAAAAXAAAAAAAAAAAAAAAAAAAA AAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAA AAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAA AAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAA AAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAA AAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAA AAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAA AAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4TuAhGEev4VxgUAAe4CBm8oAAIAAAApAAEAAAAXAAAA AAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAADhAAAA+EaAERhJj+FcYFAAFoAQZCKgBPSgEAUUoBAG8oAAEAt/AB AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC3 8AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEA AAD/QAAAAAAAAAAAAAAAAAAAsAEAAAYIAAAPhIAEEYRQ/jUIATYIAAMAWwBSAF0AAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAA AAAAAAAAAAAAAAAAAAAAAAAPEAAAD4RoARGEmP4VxgUAAWgBBkNKEABPSgEAUUoBAG8oAAEALfAH AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC3 8AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAAAAA AQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgAEAAAAAAABAAAAAAAA AAAAAAAAAAAAAAADEAAAD4QMAxGE9PwVxgUAAQwDBm8oAAEAAAACAAAAAAABAwAAAAAAAAAAAAAA AAAAAAADEAAAD4QMAxGE9PwVxgUAAQwDBm8oAAMAAAAuAAEAAQAAAAAAAQMFAAAAAAAAAAAAAAAA AAAAAxAAAA+EDAMRhPT8FcYFAAEMAwZvKAAFAAAALgABAC4AAgACAAAAAAABAwUHAAAAAAAAAAAA AAAAAAADEAAAD4QMAxGE9PwVxgUAAQwDBm8oAAcAAAAuAAEALgACAC4AAwABAAAAAAABAwUHCQAA AAAAAAAAAAAAAAADEAAAD4Q4BBGEyPsVxgUAATgEBm8oAAkAAAAuAAEALgACAC4AAwAuAAQAAQAA AAAAAQMFBwkLAAAAAAAAAAAAAAAAAxAAAA+EOAQRhMj7FcYFAAE4BAZvKAALAAAALgABAC4AAgAu AAMALgAEAC4ABQABAAAAAAABAwUHCQsNAAAAAAAAAAAAAAADEAAAD4SgBRGEYPoVxgUAAaAFBm8o AA0AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgABAAAAAAABAwUHCQsNDwAAAAAAAAAAAAADEAAA D4SgBRGEYPoVxgUAAaAFBm8oAA8AAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcAAQAAAAAA AQMFBwkLDQ8RAAAAAAAAAAAAAxAAAA+ECAcRhPj4FcYFAAEIBwZvKAARAAAALgABAC4AAgAuAAMA LgAEAC4ABQAuAAYALgAHAC4ACAABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4V xgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA8QAAAPhGgBEYSY /hXGBQABaAEGQ0oQAE9KAQBRSgEAbygAAQAt8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAP hGgBEYSY/hXGBQABaAEGT0oJAFFKCQBvKAABAGHwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADhAA AA+EaAERhJj+FcYFAAFoAQZCKgBPSgEAUUoBAG8oAAEAt/ABAAAAAAADAAAAAAAAAAAAAAAAAAAA AAAGEAAAD4QYAxGE6PwVxgUAARgDBjUIADYIAQQAWwBSAAAAXQABAAAAAAABAAAAAAAAAAAAAAAA AAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQ AAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAER hJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AEAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4TQ AhGEMP0VxgUAAdACBm8oAAIAAAAuAAMAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhNACEYQw /RXGBQAB0AIGbygAAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADhAAAA+EaAERhJj+FcYF AAFoAQZCKgBPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGE mP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgB EYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+E aAERhJj+FcYFAAFoAQYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAASEAAAD4RoARGEmP4V xgUAAWgBBkIqAENKHABPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAA D4RoARGEmP4VxgUAAWgBBk9KCABRSggAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQ AAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA DhAAAA+EaAERhJj+FcYFAAFoAQZCKgBPSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAA AAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQ AAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA CxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAA AAALEAAAD4RoARGEmP4VxgUAAWgBBk9KCABRSggAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAA AAAAABIQAAAPhGgBEYSY/hXGBQABaAEGQioAQ0ocAE9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAA AAAAAAAAAAAAAAAAAA4QAAAPhGgBEYSY/hXGBQABaAEGQioAT0oBAFFKAQBvKAABALfwAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAADhAAAA+EaAERhJj+FcYFAAFoAQZCKgBPSgEAUUoBAG8oAAEAt/AB AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAASEAAAD4RoARGEmP4VxgUAAWgBBkIqAENKHABPSgEAUUoB AG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAPEAAAD4RoARGEmP4VxgUAAWgBBkNKEABP SgEAUUoBAG8oAAEALfABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgB Bk9KAQBRSgEAbygAAQC38AIAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQAB aAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYF AAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4V xgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY /hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAER hJj+FcYFAAFoAQYCAAAALgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUA AWgBBgIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oB AFFKAQBvKAABALfwAQAAAABAAQAAAAAAAAAAAAAAAABoAQAAAAgAAA+EaAERhJj+AgAAAC4AFAAA ABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSggAUUoIAG8oAAEA8PAB AAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAIAAAAXAAAA AAAAAAAAAAAAAAAAAAAAAAsQAAAPhFYEEYSY/hXGBQABVgQGT0oAAFFKAABvKAABAC0AAQAAABcA AAAAAAAAAAAAAAAAAAAAAAAADhAAAA+EaAERhJj+FcYFAAFoAQZCKgBPSgEAUUoBAG8oAAEAt/AB AAAABEABAAAAAAAAAAAAAAAAAGgBAAAACAAAD4SCBBGEmP4CAAAAKQABAAAAFwAAAAAAAAAAAAAA AAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAAAAEAAAAAAAAA AAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAACkAAQAAABcAAAAAAAAAAAAAAAAAAAAA AAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSggAUUoIAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KCABRSggAbygAAQCn8AEAAAAAAAEAAAAAAAAAAAAA AAAAAAAAAAMQAAAPhGgBEYSY/hXGBQABaAEGbygAAgAAACkAAQAAABcAAAAAAAAAAAAAAAAAAAAA AAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oBAFFKAQBvKAABAC3wAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAAFQwAAA+EaAEVxgUAAdACBjUIADYIAENKFgBPSgEAUUoBAG8oAAEAt/AB AAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAdACBgUAUgAzAC0AAAAuAAEA AAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAwBbAAAAXQABAAAAFwAA AAAAAAAAAAAAAAAAAAAAAAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQC38AEA AAAAQAEAAAAAAAAAAAAAAAAAaAEAAAAIAAAPhGgBEYSY/gIAAAAuAAEAAAAAAAEAAAAAAAAAAAAA AAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAA ABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAAAEABAAAAAAAAAAAAAAAAAGgBAAAACAAAD4Ro ARGEmP4CAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9K AQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEG T0oBAFFKAQBvKAABACvwAQAAAAMACgAAAAAAAAAAAAAAAAAAAAAAFRAAAA+EaAERhLj/FcYFAAEo CAY1CAE2CABDShwAT0oCAFFKAgBvKAALAEEAcABwAGUAbgBkAGkAeAAgAAAALgABAAAAAAABAwAA AAAAAAAAAAAAAAAAAAAVEAAAD4QYAxGEUP4VxgUAARgDBjUIATYIAENKGABPSgAAUUoAAG8oAAQA AAAuAAEALgABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAAAEAAAD4TIBBGECP4VxgUAAaAFBgYAAAAu AAEALgACAC4AAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAABAAAA+EwAYRhHj9FcYFAAEIBwYIAAAA LgABAC4AAgAuAAMALgABAAAAAAABAwUHCQAAAAAAAAAAAAAAAAAAEAAAD4S4CBGE6PwVxgUAAdgJ BgoAAAAuAAEALgACAC4AAwAuAAQALgABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAAAEAAAD4SwChGE WPwVxgUAAUALBgwAAAAuAAEALgACAC4AAwAuAAQALgAFAC4AAQAAAAAAAQMFBwkLDQAAAAAAAAAA AAAAABAAAA+EqAwRhMj7FcYFAAEQDgYOAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgABAAAA AAABAwUHCQsNDwAAAAAAAAAAAAAAEAAAD4SgDhGEOPsVxgUAAXgPBhAAAAAuAAEALgACAC4AAwAu AAQALgAFAC4ABgAuAAcALgABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAAAEAAAD4TgEBGEYPoVxgUA AeAQBhIAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAC4AAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAA AAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAA AAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAACkAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAA AA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGE mP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgB EYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAAABAAQAAAAAAAAAAAAAAAABoAQAAAAgAAA+E aAERhJj+AgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZD ShAAT0oBAFFKAQBvKAABAC3wAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYF AAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAADAAAAAAAAAAAAAAAAAAAAAAAVEAAAD4QYAxGE6PwV xgUAARgDBjUIADYIAUNKFgBPSgIAUUoCAG8oAAQAWwBSAAAAXQABAAAAAAABAAAAAAAAAAAAAAAA AAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQ AAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAER hJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4Ro ARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAP hGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAA AA+EaAERhJj+FcYFAAFoAQZPSggAUUoIAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAL EAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAA AAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAA AAAAABAAAA+EsAERhFD+FcYFAAGwAQYBAAAAAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAABAAAA+E 0AIRhDD9FcYFAAHQAgYDAAAALgABAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAAQAAAPhNACEYQw /RXGBQAB0AIGBQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAAAAAAAAAAAAAAABAAAA+EYAMRhKD8 FcYFAAE4BAYHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAABAAAA+E8AMR hBD8FcYFAAGgBQYJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAAAEDBQcJCwAAAAAAAAAAAAAAAAAQ AAAPhIAEEYSA+xXGBQABCAcGCwAAAC4AAQAuAAIALgADAC4ABAAuAAUAAQAAAAAAAQMFBwkLDQAA AAAAAAAAAAAAABAAAA+EEAURhPD6FcYFAAEQBQYNAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYA AQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAABAAAA+EoAURhGD6FcYFAAFwCAYPAAAALgABAC4AAgAu AAMALgAEAC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAAAAAQAAAPhDAGEYTQ+RXG BQABMAYGEQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgAAgAAAAAAAQAAAAAAAAAA AAAAAAAAAAAAAxAAAA+E0AIRhDD9FcYFAAHQAgZvKAACAAAALgABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAA AAAAAAAAAAAAAAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQC38AEAAAAAAAEA AAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAAAAAAQAAAAAAAAAA AAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAAAAABAAAAAAAAAAAAAAAAAAAA AAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAEAAAABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAA D4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA4Q AAAPhGgBEYSY/hXGBQABaAEGQioAT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAA AAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAA AAAAAAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAA AAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oJAFFKCQBvKAABAGHwAQAAAARAAQAAAAAA AAAAAAAAAABoAQAAAAgAAA+EggQRhJj+AgAAACkAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADhAA AA+EaAERhJj+FcYFAAFoAQZCKgBPSgEAUUoBAG8oAAEArvABAAAAFwAAAAAAAAAAAAAAAAAAAAAA AAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oIAFFKCABvKAABAKfwAAAAABcAAAAAAAAAAAAA AAAAAAAAAAAACxAAAA+EvgURhJj+FcYFAAG+BQZPSgAAUUoAAG8oAAEALQABAAAAAAABAAAAAAAA AAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAA AAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAA AAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAA AAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAA AAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAA AAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAA AAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSggAUUoIAG8oAAEAp/ABAAAAFwAAAAAAAAAA AAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAA AAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAAD AAAAAAAAAAAAAAAAAAAAAAAGEAAAD4RoARGEmP4VxgUAAdACBjUIADYIAQQAWwBSAAAAXQABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQC3 8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAAB ALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oBAFFK AQBvKAABAC3wAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEA UUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9K AQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEG T0oBAFFKAQBvKAABAKjwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFo AQZPSgEAUUoBAG8oAAEAt/ABAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUA AWgBBgIAUgAAAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oB AFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZv KAACAAAAKQABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAu AAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA4QAAAPhGgBEYSY/hXGBQABaAEGQioAT0oBAFFKAQBv KAABALfwAQAAAAAABAAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAHQAgYFAFIAMgAt AAAALgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAUA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhGgBEYSY/hXGBQABaAEGbygAAQAAAAUAAAAAAAED AAAAAAAAAAAAAAAAAAAAAAMQAAAPhNACEYSY/hXGBQAB0AIGbygAAwAAAC4AAQABAAAAAAABAwUA AAAAAAAAAAAAAAAAAAADEAAAD4SgBRGEMP0VxgUAAaAFBm8oAAUAAAAuAAEALgACAAEAAAAAAAED BQcAAAAAAAAAAAAAAAAAAAMQAAAPhHAIEYTI+xXGBQABcAgGbygABwAAAC4AAQAuAAIALgADAAEA AAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMQAAAPhNgJEYTI+xXGBQAB2AkGbygACQAAAC4AAQAuAAIA LgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAADEAAAD4SoDBGEYPoVxgUAAagMBm8oAAsA AAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMQAAAPhBAOEYRg +hXGBQABEA4GbygADQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAA AAAAAAAAAAMQAAAPhOAQEYT4+BXGBQAB4BAGbygADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAG AC4ABwABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAADEAAAD4RIEhGE+PgVxgUAAUgSBm8oABEAAAAu AAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAQAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQ AAAPhNACEYQw/RXGBQAB0AIGbygAAQAAAAIAAAAAAAEDAAAAAAAAAAAAAAAAAAAAAAMQAAAPhNAC EYQw/RXGBQAB0AIGbygAAwAAAC4AAQABAAAAAAABAwUAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGE MP0VxgUAAdACBm8oAAUAAAAuAAEALgACAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAMQAAAPhNAC EYQw/RXGBQAB0AIGbygABwAAAC4AAQAuAAIALgADAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMQ AAAPhDgEEYTI+xXGBQABOAQGbygACQAAAC4AAQAuAAIALgADAC4ABAABAAAAAAABAwUHCQsAAAAA AAAAAAAAAAADEAAAD4Q4BBGEyPsVxgUAATgEBm8oAAsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEA AAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMQAAAPhKAFEYRg+hXGBQABoAUGbygADQAAAC4AAQAuAAIA LgADAC4ABAAuAAUALgAGAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAAMQAAAPhKAFEYRg+hXGBQAB oAUGbygADwAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwABAAAAAAABAwUHCQsNDxEAAAAA AAAAAAADEAAAD4QIBxGE+PgVxgUAAQgHBm8oABEAAAEBAAACAQAAAwEAAAQBAAAFAQAABgEAAAcB AAAIAQAACQEAAAoBAAALAQAADAEAAA0BAAAOAQAADwEAABABAAARAQAAEgEAABMBAAAUAQAAFQEA ABYBAAAZAQAAGAEAAHkBAAAaAQAAGwEAABwBAAAdAQAAHgEAAB8BAAAgAQAAIQEAACIBAAAjAQAA JAEAACUBAAAmAQAAJwEAACgBAAApAQAAKgEAACsBAAAsAQAALQEAAC4BAAAvAQAAMAEAADEBAAAy AQAAMwEAADQBAAA1AQAANgEAADcBAAA4AQAAOQEAADoBAAA7AQAAPAEAAD0BAAA+AQAAPwEAAEAB AABBAQAAQgEAAEMBAABEAQAARQEAAEYBAABHAQAASAEAAEkBAABKAQAASwEAAEwBAABNAQAATgEA AE8BAABQAQAAUQEAAFIBAABTAQAAVAEAAFUBAABWAQAAVwEAAFgBAABZAQAAWgEAAFsBAABcAQAA XQEAAF4BAABfAQAAYAEAAGEBAABiAQAAYwEAAGQBAABlAQAAZgEAAGcBAABoAQAAaQEAAGoBAABr AQAAbAEAAG0BAABuAQAAbwEAAHABAABxAQAAcgEAAHMBAAB0AQAAdQEAAHYBAAB3AQAA/v////7/ ///+////////////////////////////////////AC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4A BwAuAAgAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgAB AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQAr 8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAAB ALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8o AAEAt/ABAAAAAEABAAAAAAAAAAAAAAAAAGgBAAAACAAAD4RoARGEmP4CAAAALgABAAAAFwAAAAAA AAAAAAAAAAAAAAAAAAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQC38AEAAAAX AAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAADhAAAA+EaAERhJj+FcYFAAFoAQZCKgBPSgEAUUoBAG8oAAEA t/ABAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4SIAhGEUP4VxgUAAYgCBgMAWwAAAF0AAQAA AAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EsAERhFD+FcYFAAGwAQYBAAAAAQAAAAAAAQMAAAAA AAAAAAAAAAAAAAAAABAAAA+EQAIRhMD9FcYFAAFAAgYDAAAALgABAAEAAAAAAAEDBQAAAAAAAAAA AAAAAAAAAAAQAAAPhNACEYQw/RXGBQAB0AIGBQAAAC4AAQAuAAIAAQAAAAAAAQMFBwAAAAAAAAAA AAAAAAAAABAAAA+EYAMRhKD8FcYFAAFgAwYHAAAALgABAC4AAgAuAAMAAQAAAAAAAQMFBwkAAAAA AAAAAAAAAAAAABAAAA+E8AMRhBD8FcYFAAHwAwYJAAAALgABAC4AAgAuAAMALgAEAAEAAAAAAAED BQcJCwAAAAAAAAAAAAAAAAAQAAAPhIAEEYSA+xXGBQABgAQGCwAAAC4AAQAuAAIALgADAC4ABAAu AAUAAQAAAAAAAQMFBwkLDQAAAAAAAAAAAAAAABAAAA+EEAURhPD6FcYFAAEQBQYNAAAALgABAC4A AgAuAAMALgAEAC4ABQAuAAYAAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAABAAAA+EoAURhGD6FcYF AAGgBQYPAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAAEAAAAAAAEDBQcJCw0PEQAAAAAA AAAAAAAQAAAPhDAGEYTQ+RXGBQABMAYGEQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAu AAgAAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8o AAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEA bygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFK AQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEA UUoBAG8oAAEAK/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAPEAAAD4RoARGEmP4VxgUAAWgBBkNK EABPSgEAUUoBAG8oAAEALfABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUA AWgBBk9KCABRSggAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA4QAAAPhGgBEYSY/hXG BQABaAEGQioAT0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAER hJj+FcYFAAFoAQYCAAAALgABAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4SIAhGEUP4VxgUA AYgCBgMAWwAAAF0AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZP SgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgB Bk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQAB aAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYF AAFoAQZPSggAUUoIAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4V xgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY /hXGBQABaAEGT0oBAFFKAQBvKAABALfwWAIAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+E0AIR hDD9FcYFAAHQAgZPSggAUUoIAG8oAAEA8PABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAPEAAAD4Ro ARGEmP4VxgUAAWgBBkNKEABPSgEAUUoBAG8oAAEALfABAAAAAwAKAAAAAAAAAAAAAAAAAAAAAAAV EAAAD4RoARGEuP8VxgUAASgIBjUIATYIAENKHABPSgIAUUoCAG8oAAsAQQBwAHAAZQBuAGQAaQB4 ACAAAAAuAAEAAAAAAAEDAAAAAAAAAAAAAAAAAAAAABUQAAAPhBgDEYRQ/hXGBQABGAMGNQgBNggA Q0oYAE9KAABRSgAAbygABAAAAC4AAQAuAAEAAAAAAAEDBQAAAAAAAAAAAAAAAAAAAAAQAAAPhMgE EYQI/hXGBQABoAUGBgAAAC4AAQAuAAIALgABAAAAAAABAwUHAAAAAAAAAAAAAAAAAAAAEAAAD4TA BhGEeP0VxgUAAXAIBggAAAAuAAEALgACAC4AAwAuAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAAAQ AAAPhLgIEYTo/BXGBQAB2AkGCgAAAC4AAQAuAAIALgADAC4ABAAuAAEAAAAAAAEDBQcJCwAAAAAA AAAAAAAAAAAQAAAPhLAKEYRY/BXGBQABQAsGDAAAAC4AAQAuAAIALgADAC4ABAAuAAUALgABAAAA AAABAwUHCQsNAAAAAAAAAAAAAAAAEAAAD4SoDBGEyPsVxgUAARAOBg4AAAAuAAEALgACAC4AAwAu AAQALgAFAC4ABgAuAAEAAAAAAAEDBQcJCw0PAAAAAAAAAAAAAAAQAAAPhKAOEYQ4+xXGBQABeA8G EAAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAEAAAAAAAEDBQcJCw0PEQAAAAAAAAAA AAAQAAAPhOAQEYRg+hXGBQAB4BAGEgAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAC4ABwAuAAgA LgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygA AQC38AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAACkAAQAA ABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/AB AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC3 8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA4QAAAPhGgBEYSY/hXGBQABaAEGQioAT0oBAFFKAQBv KAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoB AG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAu AAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAAB ALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAA FwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEA AAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfw AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADhAAAA+EaAERhJj+FcYFAAFoAQZCKgBPSgEAUUoBAG8o AAEArvABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAPEAAAD4RoARGEmP4VxgUAAWgBBkNKEABPSgEA UUoBAG8oAAEALfABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9K AQBRSgEAbygAAQC38AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEG AgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgAB AAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC3 8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAAB ALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8o AAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KCABRSggA bygAAQCn8AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAMQAAAPhMgBEYQ4/hXGBQAByAEGbygAAQAA AAEAAAAAAAEDAAAAAAAAAAAAAAAAAAAAAAMQAAAPhMgBEYQ4/hXGBQAByAEGbygAAwAAAC4AAQAB AAAAAAABAwUAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEMP0VxgUAAdACBm8oAAUAAAAuAAEALgAC AAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAMQAAAPhNACEYQw/RXGBQAB0AIGbygABwAAAC4AAQAu AAIALgADAAEAAAAAAAEDBQcJAAAAAAAAAAAAAAAAAAMQAAAPhNACEYQw/RXGBQAB0AIGbygACQAA AC4AAQAuAAIALgADAC4ABAABAAAAAAABAwUHCQsAAAAAAAAAAAAAAAADEAAAD4Q4BBGEyPsVxgUA ATgEBm8oAAsAAAAuAAEALgACAC4AAwAuAAQALgAFAAEAAAAAAAEDBQcJCw0AAAAAAAAAAAAAAAMQ AAAPhDgEEYTI+xXGBQABOAQGbygADQAAAC4AAQAuAAIALgADAC4ABAAuAAUALgAGAAEAAAAAAAED BQcJCw0PAAAAAAAAAAAAAAMQAAAPhKAFEYRg+hXGBQABoAUGbygADwAAAC4AAQAuAAIALgADAC4A BAAuAAUALgAGAC4ABwABAAAAAAABAwUHCQsNDxEAAAAAAAAAAAADEAAAD4SgBRGEYPoVxgUAAaAF Bm8oABEAAAAuAAEALgACAC4AAwAuAAQALgAFAC4ABgAuAAcALgAIAAEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSggAUUoIAG8oAAEAp/ABAAAAAAABAAAAAAAA AAAAAAAAAAAAAAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAAAAEAAAAAAAAAAAAAAAAA AAAAAAMQAAAPhGgBEYSY/hXGBQABaAEGbygAAgAAACkAAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAA ABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4Ro ARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAP hGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+ FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAOEAAAD4RoARGE mP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQCu8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAP hGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAAABAAQAAAAAAAAAAAAAAAABoAQAAAAgA AA+EaAERhJj+AgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFo AQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUA AWgBBk9KCABRSggAbygAAQCn8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAABIQAAAPhGgBEYSY/hXG BQABaAEGQioAQ0ocAE9KAQBRSgEAbygAAQC38AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAP hGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADhAAAA+EaAERhJj+ FcYFAAFoAQZCKgBPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAOEAAAD4Ro ARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQ AAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA CxAAAA+EaAERhJj+FcYFAAFoAQZPSggAUUoIAG8oAAEAp/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAA AAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAA AAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAA AAAAAAAAAAAAABAAAA+EaAERhJj+FcYFAAFoAQYCAAAALgABAAAAAAABAAAAAAAAAAAAAAAAAAAA AAADEAAAD4RoARGEmP4VxgUAAWgBBm8oAAIAAAApAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQ AAAPhGgBEYSY/hXGBQABaAEGT0oIAFFKCABvKAABAKfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAA CxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAAAAAA AAAAEAAAD4RoARGEmP4VxgUAAWgBBgIAAAAuAAEAAAAAQAEAAAAAAAAAAAAAAAAAaAEAAAAIAAAP hGgBEYSY/gIAAAAuAAEAAAAAQAEAAAAAAAAAAAAAAAAAaAEAAAAIAAAPhGgBEYSY/gIAAAAuAAEA AAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfw AQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oBAFFKAQBv KAABAC3wAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+EaAERhJj+FcYFAAFoAQZvKAACAAAA LgABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAADEAAAD4TQAhGEmP4VxgUAAdACBm8oAAIAAAApAAEA AAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQAAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAA AAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAA AAAAAAAAAAAAAAAAAAAAAAAOEAAAD4RoARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQC38AEA AAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAABALfw AQAAAABAAQAAAAAAAAAAAAAAAABoAQAAAAgAAA+EaAERhJj+AgAAAC4AAQAAABcAAAAAAAAAAAAA AAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAA AAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAA AAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oIAFFKCABvKAABANjwAQAAAABAAQAA AAAAAAAAAAAAAABoAQAAAAgAAA+EaAERhJj+AgAAAC4AAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAA AxAAAA+EaAERhJj+FcYFAAFoAQZvKAACAAAALgABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAA D4RoARGEmP4VxgUAAWgBBk9KAQBRSgEAbygAAQC38AEAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAQ AAAPhGgBEYSY/hXGBQABaAEGAgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAER hJj+FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAAOEAAAD4Ro ARGEmP4VxgUAAWgBBkIqAE9KAQBRSgEAbygAAQC38AEAAAADAAoAAAAAAAAAAAAAAAAAAAAAABUQ AAAPhGgBEYS4/xXGBQABKAgGNQgBNggAQ0ocAE9KAgBRSgIAbygACwBBAHAAcABlAG4AZABpAHgA IAAAAC4AAQAAAAAAAQMAAAAAAAAAAAAAAAAAAAAAFRAAAA+EGAMRhFD+FcYFAAEYAwY1CAE2CABD ShgAT0oAAFFKAABvKAAEAAAALgABAC4AAQAAAAAAAQMFAAAAAAAAAAAAAAAAAAAAABAAAA+EyAQR hAj+FcYFAAGgBQYGAAAALgABAC4AAgAuAAEAAAAAAAEDBQcAAAAAAAAAAAAAAAAAAAAQAAAPhMAG EYR4/RXGBQABcAgGCAAAAC4AAQAuAAIALgADAC4AAQAAAAAAAQMFBwkAAAAAAAAAAAAAAAAAABAA AA+EuAgRhOj8FcYFAAHYCQYKAAAALgABAC4AAgAuAAMALgAEAC4AAQAAAAAAAQMFBwkLAAAAAAAA AAAAAAAAABAAAA+EsAoRhFj8FcYFAAFACwYMAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAEAAAAA AAEDBQcJCw0AAAAAAAAAAAAAAAAQAAAPhKgMEYTI+xXGBQABEA4GDgAAAC4AAQAuAAIALgADAC4A BAAuAAUALgAGAC4AAQAAAAAAAQMFBwkLDQ8AAAAAAAAAAAAAABAAAA+EoA4RhDj7FcYFAAF4DwYQ AAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4AAQAAAAAAAQMFBwkLDQ8RAAAAAAAAAAAA ABAAAA+E4BARhGD6FcYFAAHgEAYSAAAALgABAC4AAgAuAAMALgAEAC4ABQAuAAYALgAHAC4ACAAu AAcAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFKAQBvKAAB ALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoBAG8o AAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgBBk9KAQBRSgEA bygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQABaAEGT0oBAFFK AQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSggA UUoIAG8oAAEAp/ABAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4SIAhGEUP4VxgUAAYgCBgMA WwAAAF0AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZPSgEAUUoB AG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAASEAAAD4RoARGEmP4VxgUAAWgBBkIqAENK HABPSgEAUUoBAG8oAAEAt/BYAgAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4TQAhGEMP0VxgUA AdACBk9KCABRSggAbygAAQDw8AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXG BQABaAEGT0oBAFFKAQBvKAABALfwAQAAAABAAQAAAAAAAAAAAAAAAABoAQAAAAgAAA+EaAERhJj+ AgAAAC4AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAADxAAAA+EaAERhJj+FcYFAAFoAQZDShAAT0oB AFFKAQBvKAABAC3wAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFoAQZP SgEAUUoBAG8oAAEAt/ABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgB Bk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAA4QAAAPhGgBEYSY/hXGBQAB aAEGQioAT0oBAFFKAQBvKAABALfwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+ FcYFAAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAABAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGE mP4VxgUAAWgBBgIAAAAuAAEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQAB aAEGT0oBAFFKAQBvKAABALfwAQAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAxAAAA+E0AIRhJj+FcYF AAHQAgZvKAACAAAAKQABAAAAFwAAAAAAAAAAAAAAAAAAAAAAAAALEAAAD4RoARGEmP4VxgUAAWgB Bk9KAQBRSgEAbygAAQC38AEAAAAXAAAAAAAAAAAAAAAAAAAAAAAAAAsQAAAPhGgBEYSY/hXGBQAB aAEGT0oBAFFKAQBvKAABACvwAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYF AAFoAQZPSgEAUUoBAG8oAAEAt/ABAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAEAAAD4RoARGEmP4V xgUAAWgBBgMAWwAAAF0AAQAAABcAAAAAAAAAAAAAAAAAAAAAAAAACxAAAA+EaAERhJj+FcYFAAFo AQZPSgEAUUoBAG8oAAEAt/DEAwAAif///wAAAAAAAAAAAAAAAP7///8AAAAAVPOfBwEAAAD+//// AAAAALDznwcBAAAArl3WBwAAAAAAAAAAAAAAAKY3NiIAAAAAAAAAAAAAAADTHlopAAAAAAAAAAAA AAAAuGdVfQAAAAAAAAAAAAAAANUSM3gAAAAAAAAAAAAAAAA4XhgSAAAAAAAAAAAAAAAA5RK6NwAA AAAAAAAAAAAAAANvunAAAAAAAAAAAAAAAAA5dzBjAAAAAAAAAAAAAAAApEmZdQAAAAAAAAAAAAAA APpNBQEAAAAAAAAAAAAAAAB8PMR1AAAAAAAAAAAAAAAABBHYUQAAAAAAAAAAAAAAACAQjU8AAAAA AAAAAAAAAACzbbBOAAAAAAAAAAAAAAAAN0/mHAAAAAAAAAAAAAAAAOk99xkAAAAAAAAAAAAAAAAX T/5JAAAAAAAAAAAAAAAAtCtuMAAAAAAAAAAAAAAAAPwVgXkAAAAAAAAAAAAAAAD1K8UeAAAAAAAA AAAAAAAAqGl3CAAAAAAAAAAAAAAAAGpsWTQAAAAAAAAAAAAAAADgFPggAAAAAAAAAAAAAAAA+/// /wAAAAAAAAAAAAAAAIARqEwAAAAAAAAAAAAAAAChBghiAAAAAAAAAAAAAAAAKhTOVQAAAAAAAAAA AAAAAAlU9TAAAAAAAAAAAAAAAAAqFM5VAAAAAAAAAAAAAAAACl+5QwAAAAAAAAAAAAAAAFsiXT8A AAAAAAAAAAAAAAAqFM5VAAAAAAAAAAAAAAAAZS5RNQAAAAAAAAAAAAAAALghxUMAAAAAAAAAAAAA AADoQ+BVAAAAAAAAAAAAAAAAFyV7dgAAAAAAAAAAAAAAAL91HCQAAAAAAAAAAAAAAADhZuZ8AAAA AAAAAAAAAAAA3SiSXAAAAAAAAAAAAAAAAE4+nW4AAAAAAAAAAAAAAAAkQzNzAAAAAAAAAAAAAAAA vzwbBAAAAAAAAAAAAAAAAMkF9SsAAAAAAAAAAAAAAAAnHHkUAAAAAAAAAAAAAAAAhSBcLwAAAAAA AAAAAAAAAB0KhlcAAAAAAAAAAAAAAABLLvMkAAAAAAAAAAAAAAAAYWq5NwAAAAAAAAAAAAAAAP7/ //8AAAAADPSfBwEAAABLStE5AAAAAAAAAAAAAAAAZzs0EQAAAAAAAAAAAAAAAFQ3enAAAAAAAAAA AAAAAAB8////AAAAAAAAAAAAAAAA/v///wAAAABo9J8HAQAAALdCZCwAAAAAAAAAAAAAAACDMx9+ AAAAAAAAAAAAAAAABmn6HAAAAAAAAAAAAAAAACw2yUcAAAAAAAAAAAAAAAA7fGt/AAAAAAAAAAAA AAAAiAXbdgAAAAAAAAAAAAAAADxOnm8AAAAAAAAAAAAAAAAJbaYiAAAAAAAAAAAAAAAAzUWYSwAA AAAAAAAAAAAAAG10TxoAAAAAAAAAAAAAAABHMVA7AAAAAAAAAAAAAAAAiP///wAAAAAAAAAAAAAA AP7///8AAAAAxPSfBwEAAAD+////AAAAACD1nwcBAAAA/v///wAAAAB89Z8HAQAAAP7///8AAAAA 2PWfBwEAAAD+////AAAAADT2nwcBAAAA/v///wAAAACQ9p8HAQAAAP7///8AAAAA7PafBwEAAAD+ ////AAAAAEj3nwcBAAAA7SZPFQAAAAAAAAAAAAAAADREXkoAAAAAAAAAAAAAAACTYtRgAAAAAAAA AAAAAAAAU2cpHQAAAAAAAAAAAAAAALcV2EkAAAAAAAAAAAAAAADAVmhRAAAAAAAAAAAAAAAAMAaX OQAAAAAAAAAAAAAAANNjzA4AAAAAAAAAAAAAAACcBbdDAAAAAAAAAAAAAAAA9S8IVgAAAAAAAAAA AAAAAE8E4n4AAAAAAAAAAAAAAADrWsp3AAAAAAAAAAAAAAAAwmIaWgAAAAAAAAAAAAAAAP7///8A AAAApPefBwEAAAD+////AAAAAAD4nwcBAAAA/v///wAAAABc+J8HAQAAAP7///8AAAAAuPifBwEA AAD+////AAAAABT5nwcBAAAA/v///wAAAABw+Z8HAQAAAP7///8AAAAAzPmfBwEAAAD+////AAAA ACj6nwcBAAAA/v///wAAAACE+p8HAQAAAP7///8AAAAA4PqfBwEAAAD+////AAAAADz7nwcBAAAA /v///wAAAACY+58HAQAAAL0bBB8AAAAAAAAAAAAAAAARfPhFAAAAAAAAAAAAAAAACXmXbgAAAAAA AAAAAAAAAPZDzkUAAAAAAAAAAAAAAAD+////AAAAAPT7nwcBAAAA/v///wAAAABQ/J8HAQAAAP7/ //8AAAAArPyfBwEAAAD+////AAAAAAj9nwcBAAAA/v///wAAAABk/Z8HAQAAAP7///8AAAAAwP2f BwEAAAD+////AAAAABz+nwcBAAAA/v///wAAAAB4/p8HAQAAAP7///8AAAAA1P6fBwEAAAD+//// AAAAADD/nwcBAAAA/v///wAAAACM/58HAQAAAP7///8AAAAA6P+fBwEAAABRNcQ2AAAAAAAAAAAA AAAACHkyCQAAAAAAAAAAAAAAAEIwE2oAAAAAAAAAAAAAAAC+FusGAAAAAAAAAAAAAAAADgpwHQAA AAAAAAAAAAAAAHRxb3wAAAAAAAAAAAAAAADZC79EAAAAAAAAAAAAAAAA/v///wAAAABQ8JYHAQAA AP7///8AAAAArPCWBwEAAAD+////AAAAAAjxlgcBAAAA/v///wAAAABk8ZYHAQAAAP7///8AAAAA wPGWBwEAAAD+////AAAAABzylgcBAAAA/v///wAAAAB48pYHAQAAAP7///8AAAAA1PKWBwEAAAD+ ////AAAAADDzlgcBAAAA/v///wAAAACM85YHAQAAAP7///8AAAAA6POWBwEAAAD+////AAAAAET0 lgcBAAAAPxTlPgAAAAAAAAAAAAAAAGYzrnoAAAAAAAAAAAAAAAD5SxoGAAAAAAAAAAAAAAAAPmNd EQAAAAAAAAAAAAAAACweW0sAAAAAAAAAAAAAAACbBLgqAAAAAAAAAAAAAAAA6kQpawAAAAAAAAAA AAAAAE0j6AoAAAAAAAAAAAAAAACMGqR0AAAAAAAAAAAAAAAA6E0xUwAAAAAAAAAAAAAAAOhNMVMA AAAAAAAAAAAAAADoTTFTAAAAAAAAAAAAAAAAvkGSSAAAAAAAAAAAAAAAABAq8SoAAAAAAAAAAAAA AAAQS5ViAAAAAAAAAAAAAAAArGXHaAAAAAAAAAAAAAAAABYbbVAAAAAAAAAAAAAAAAC1XvJSAAAA AAAAAAAAAAAA/hXiEgAAAAAAAAAAAAAAAGN34XIAAAAAAAAAAAAAAABtNWhrAAAAAAAAAAAAAAAA lB6qQwAAAAAAAAAAAAAAAOcGpFYAAAAAAAAAAAAAAAASazoAAAAAAAAAAAAAAAAAhW2eYwAAAAAA AAAAAAAAADQSg2UAAAAAAAAAAAAAAAA0N/h3AAAAAAAAAAAAAAAAh3RaFAAAAAAAAAAAAAAAAAEz yxkAAAAAAAAAAAAAAAByDdEHAAAAAAAAAAAAAAAAv0AVbwAAAAAAAAAAAAAAABQwUS0AAAAAAAAA AAAAAADFEU8aAAAAAAAAAAAAAAAASw/7SwAAAAAAAAAAAAAAAMxdqXAAAAAAAAAAAAAAAACoEG4X AAAAAAAAAAAAAAAA83zUOwAAAAAAAAAAAAAAAP7///8AAAAAoPSWBwEAAAD+////AAAAAPz0lgcB AAAA/v///wAAAABY9ZYHAQAAAP7///8AAAAAtPWWBwEAAAD+////AAAAABD2lgcBAAAA/v///wAA AABs9pYHAQAAAP7///8AAAAAyPaWBwEAAAD+////AAAAACT3lgcBAAAA/v///wAAAACA95YHAQAA AP7///8AAAAA3PeWBwEAAAD+////AAAAADj4lgcBAAAA/v///wAAAACU+JYHAQAAAP7///8AAAAA 8PiWBwEAAAD+////AAAAAEz5lgcBAAAA/v///wAAAACo+ZYHAQAAAP7///8AAAAABPqWBwEAAAD+ ////AAAAAGD6lgcBAAAA/v///wAAAAC8+pYHAQAAAP7///8AAAAAGPuWBwEAAAD+////AAAAAHT7 lgcBAAAA/v///wAAAADQ+5YHAQAAAP7///8AAAAALPyWBwEAAAD+////AAAAAIj8lgcBAAAA/v// /wAAAADk/JYHAQAAAP7///8AAAAAQP2WBwEAAAD+////AAAAAJz9lgcBAAAA/v///wAAAAD4/ZYH AQAAAP7///8AAAAAVP6WBwEAAAD+////AAAAALD+lgcBAAAA/v///wAAAAAM/5YHAQAAAP7///8A AAAAaP+WBwEAAAD+////AAAAAMT/lgcBAAAA/v///wAAAAAoAKQHAQAAAP7///8AAAAAhACkBwEA AAD+////AAAAAOAApAcBAAAA/v///wAAAAA8AaQHAQAAAP7///8AAAAAmAGkBwEAAAD+////AAAA APQBpAcBAAAA/v///wAAAABQAqQHAQAAAP7///8AAAAArAKkBwEAAAD+////AAAAAAgDpAcBAAAA /v///wAAAABkA6QHAQAAAP7///8AAAAAwAOkBwEAAAD+////AAAAABwEpAcBAAAA/v///wAAAAB4 BKQHAQAAAP7///8AAAAA1ASkBwEAAAD+////AAAAADAFpAcBAAAA/v///wAAAACMBaQHAQAAADV3 gz4AAAAAAAAAAAAAAAD6Y4xaAAAAAAAAAAAAAAAAfwpeWgAAAAAAAAAAAAAAAMM22FsAAAAAAAAA AAAAAADoTTFTAAAAAAAAAAAAAAAABXeSZAAAAAAAAAAAAAAAAC85mk4AAAAAAAAAAAAAAADDMxtk AAAAAAATAAAAiAEAAAIAAADkBAAAHgAAAAkAAABwcm9wb3NhbAAAIAAeAAAAAQAAAAByb3AeAAAA DgAAAE1haGVzaCBiYWx1bmkAbwAeAAAAAQAAAABhaGUeAAAAAQAAAABhaGUeAAAABwAAAE5vcm1h bABiHgAAAA8AAABHYXJ5IEdyZWVuYmVyZwAAHgAAAAIAAAAyAHJ5HgAAABMAAABNaWNyb3NvZnQg V29yZCA4LjAAAEAAAAAAAAAAAAAAAEAAAAAA3Jz5iPi+AUAAAAAAyDSzLSW/AUAAAAAAyDSzLSW/ AQMAAAABAAAAAwAAADEQAAADAAAATFwAAAMAAAAAAAAA/v8AAAQAAgAAAAAAAAAAAAAAAAAAAAAA AgAAAALVzdWcLhsQk5cIACss+a5EAAAABdXN1ZwuGxCTlwgAKyz5rkgBAAAEAQAADAAAAAEAAABo AAAADwAAAHAAAAAFAAAAkAAAAAYAAACYAAAAEQAAAKAAAAAXAAAAqAAAAAsAAACwAAAAEAAAALgA AAATAAAAwAAAABYAAADIAAAADQAAANAAAAAMAAAA5QAAAAIAAADkBAAAHgAAABgAAABIdWdoZXMg U29mdHdhcmUgU3lzdGVtcwADAAAAxAAAAAMAAAAvAAAAAwAAAFhxAAADAAAA6BAIAAsAAAAAAAAA CwAAAAAAAAALAAAAAAAAAAsAAAAAAAAAHhAAAAEAAAAJAAAAcHJvcG9zYWwADBAAAAIAAAAeAAAA BgAAAFRpdGxlAAMAAAABAAAAAJABAAAEAAAAAAAAACgAAAABAAAAUgAAAAIAAABaAAAAAwAAALIA AAACAAAAAgAAAAoAAABfUElEX0dVSUQAAwAAAAwAAABfUElEX0hMSU5LUwACAAAA5AQAAEEAAABO AAAAewA2ADEANQBBADkAQQBBADEALQA2ADQANQAyAC0AMQAxAEQAMwAtAEIARQA4ADMALQAwADAA MAAwAEMAMAA4ADIAMAAzAEUANAB9AAAAAABBAAAA1AAAAAwAAAADAAAATABdAAMAAAAGAAAAAwAA AAAAAAADAAAABQAAAB8AAAAZAAAAaAB0AHQAcAA6AC8ALwB3AHcAdwAuAGgAcwBzAHcAbwByAGwA ZAAuAGMAbwBtAC8AAAAAAB8AAAABAAAAAAAAAAMAAAASADEAAwAAAAMAAAADAAAAAAAAAAMAAAAF AAAAHwAAABkAAABtAGEAaQBsAHQAbwA6AGkAbgBmAG8AQABoAHMAcwB3AG8AcgBsAGQALgBjAG8A bQAAAAAAHwAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAM1RTQoAAAAAAAAAAAAAAACZDV98AAAAAAAAAAAAAAAAJhrpZwAAAAAAAAAAAAAA ADdFVQEAAAAAAAAAAAAAAAB6UOg8AAAAAAAAAAAAAAAA0kDkOAAAAAAAAAAAAAAAAF8BdXAAAAAA AAAAAAAAAABOZndLAAAAAAAAAAAAAAAA/VhBCAAAAAAAAAAAAAAAALJCIikAAAAAAAAAAAAAAABS XThpAAAAAAAAAAAAAAAAdln1IgAAAAAAAAAAAAAAAOZcGloAAAAAAAAAAAAAAADoCfUcAAAAAAAA AAAAAAAAI3vUawAAAAAAAAAAAAAAAL0EUhkAAAAAAAAAAAAAAABOJSxhAAAAAAAAAAAAAAAAzBP8 TAAAAAAAAAAAAAAAAP7///8AAAAA6AWkBwEAAAD+////AAAAAEQGpAcBAAAA/v///wAAAACgBqQH AQAAALkXB0sAAAAAAAAAAAAAAAAPORdYAAAAAAAAAAAAAAAAnnonIgAAAAAAAAAAAAAAAEcJvysA AAAAAAAAAAAAAAD+////AAAAAPwGpAcBAAAA/v///wAAAABYB6QHAQAAAP7///8AAAAAtAekBwEA AAD7T8oIAAAAAAAAAAAAAAAAtyOdegAAAAAAAAAAAAAAAL8MWFAAAAAAAAAAAAAAAACvJT4RAAAA AAAAAAAAAAAAnGnpdAAAAAAAAAAAAAAAAMM+vUQAAAAAAAAAAAAAAAD+QQRyAAAAAAAAAAAAAAAA GmZpbwAAAAAAAAAAAAAAAARoAzkAAAAAAAAAAAAAAAAbc4BqAAAAAAAAAAAAAAAAVlsWbwAAAAAA AAAAAAAAAHEAS0YAAAAAAAAAAAAAAACvP5UUAAAAAAAAAAAAAAAAezA/XAAAAAAAAAAAAAAAABxH pRMAAAAAAAAAAAAAAAC8dXRLAAAAAAAAAAAAAAAA/v///wAAAAAQCKQHAQAAAP7///8AAAAAbAik BwEAAAD+////AAAAAMgIpAcBAAAA/v///wAAAAAkCaQHAQAAAP7///8AAAAAgAmkBwEAAAD+//// AAAAANwJpAcBAAAA/v///wAAAAA4CqQHAQAAAP7///8AAAAAlAqkBwEAAAD+////AAAAAPAKpAcB AAAA/v///wAAAABMC6QHAQAAAP7///8AAAAAqAukBwEAAAD+////AAAAAAQMpAcBAAAA/v///wAA AABgDKQHAQAAAP7///8AAAAAvAykBwEAAAD+////AAAAABgNpAcBAAAA/v///wAAAAB0DaQHAQAA AP7///8AAAAA0A2kBwEAAAD+////AAAAACwOpAcBAAAAlAZDFAAAAAAAAAAAAAAAAP7///8AAAAA iA6kBwEAAAD+////AAAAAOQOpAcBAAAA/v///wAAAABAD6QHAQAAAP7///8AAAAAnA+kBwEAAAD+ ////AAAAAPgPpAcBAAAA/v///wAAAABUEKQHAQAAAP7///8AAAAAsBCkBwEAAAD+////AAAAAAwR pAcBAAAA/v///wAAAABoEaQHAQAAAP7///8AAAAAxBGkBwEAAAD+////AAAAACASpAcBAAAA/v// /wAAAAB8EqQHAQAAAP7///8AAAAA2BKkBwEAAAD+////AAAAADQTpAcBAAAA/v///wAAAACQE6QH AQAAAP7///8AAAAA7BOkBwEAAAD+////AAAAAEgUpAcBAAAA/v///wAAAACkFKQHAQAAAP7///8A AAAAABWkBwEAAAD+////AAAAAFwVpAcBAAAA/v///wAAAAC4FaQHAQAAAP7///8AAAAAFBakBwEA AAD+////AAAAAHAWpAcBAAAA/v///wAAAADMFqQHAQAAAORUxSsAAAAAAAAAAAAAAABQHnIIAAAA AAAAAAAAAAAAOzrxbAAAAAAAAAAAAAAAACxXaSUAAAAAAAAAAAAAAAALKoMIAAAAAAAAAAAAAAAA XkQ/KAAAAAAAAAAAAAAAAHB/c3UAAAAAAAAAAAAAAABBAyxPAAAAAAAAAAAAAAAAXhFDCQAAAAAA AAAAAAAAAKpW+QUAAAAAAAAAAAAAAAAFTN94AAAAAAAAAAAAAAAAjSH1KwAAAAAAAAAAAAAAAHYP QjcAAAAAAAAAAAAAAABHBxlfAAAAAAAAAAAAAAAAlQnZVgAAAAAAAAAAAAAAAPYSiQEAAAAAAAAA AAAAAADgdYgbAAAAAAAAAAAAAAAArByqZAAAAAAAAAAAAAAAAFZid0MAAAAAAAAAAAAAAABCfOof AAAAAAAAAAAAAAAAnDbIAAAAAAAAAAAAAAAAAIBqfkQAAAAAAAAAAAAAAAD6TMxJAAAAAAAAAAAA AAAAv1u0WwAAAAAAAAAAAAAAAMQoHRIAAAAAAAAAAAAAAAA2a5VzAAAAAAAAAAAAAAAADmJREgAA AAAAAAAAAAAAAEBsJm4AAAAAAAAAAAAAAAC0MdMEAAAAAAAAAAAAAAAA0ndiZgAAAAAAAAAAAAAA ADproyoAAAAAAAAAAAAAAAAPSsklAAAAAAAAAAAAAAAAV3PaVAAAAAAAAAAAAAAAAA4aiA4AAAAA AAAAAAAAAADmXf0yAAAAAAAAAAAAAAAAJG5DfAAAAAAAAAAAAAAAAFkXc0kAAAAAAAAAAAAAAAD+ L1dKAAAAAAAAAAAAAAAAxCMAegAAAAAAAAAAAAAAAKx5TVMAAAAAAAAAAAAAAAA+cfUaAAAAAAAA AAAAAAAAUFH3cQAAAAAAAAAAAAAAANxVxDkAAAAAAAAAAAAAAAAHRtMpAAAAAAAAAAAAAAAA/v// /wAAAAAoF6QHAQAAAP7///8AAAAAhBekBwEAAAD+////AAAAAOAXpAcBAAAA/v///wAAAAA8GKQH AQAAAP7///8AAAAAmBikBwEAAAD+////AAAAAPQYpAcBAAAA/v///wAAAABQGaQHAQAAAP7///8A AAAArBmkBwEAAAD+////AAAAAAgapAcBAAAA/v///wAAAABkGqQHAQAAAP7///8AAAAAwBqkBwEA AAD+////AAAAABwbpAcBAAAA/v///wAAAAB4G6QHAQAAAP7///8AAAAA1BukBwEAAAD+////AAAA ADAcpAcBAAAA/v///wAAAACMHKQHAQAAAP7///8AAAAA6BykBwEAAAD+////AAAAAEQdpAcBAAAA /v///wAAAACgHaQHAQAAAP7///8AAAAA/B2kBwEAAAD+////AAAAAFgepAcBAAAA/v///wAAAAC0 HqQHAQAAAP7///8AAAAAEB+kBwEAAAD+////AAAAAGwfpAcBAAAA/v///wAAAADIH6QHAQAAAP7/ //8AAAAAJCCkBwEAAAD+////AAAAAIAgpAcBAAAA/v///wAAAADcIKQHAQAAAP7///8AAAAAOCGk BwEAAAD+////AAAAAJQhpAcBAAAA/v///wAAAADwIaQHAQAAAP7///8AAAAATCKkBwEAAAD+//// AAAAAKgipAcBAAAA/v///wAAAAAEI6QHAQAAAP7///8AAAAAYCOkBwEAAAD+////AAAAALwjpAcB AAAA/v///wAAAAAYJKQHAQAAAP7///8AAAAAdCSkBwEAAAD+////AAAAANAkpAcBAAAA/v///wAA AAAsJaQHAQAAAP7///8AAAAAiCWkBwEAAAD+////AAAAAOQlpAcBAAAA/v///wAAAABAJqQHAQAA AP7///8AAAAAnCakBwEAAAD+////AAAAAPgmpAcBAAAA/v///wAAAABUJ6QHAQAAAP7///8AAAAA sCekBwEAAAD+////AAAAAAwopAcBAAAAYzrnOAAAAAAAAAAAAAAAAApRABwAAAAAAAAAAAAAAABN IDonAAAAAAAAAAAAAAAAKjXucwAAAAAAAAAAAAAAADYSbQcAAAAAAAAAAAAAAAAfaQNWAAAAAAAA AAAAAAAAAEa8bwAAAAAAAAAAAAAAAGw3Z24AAAAAAAAAAAAAAAAxGzpiAAAAAAAAAAAAAAAAKTeH YQAAAAAAAAAAAAAAAEEWuBAAAAAAAAAAAAAAAABEXcF/AAAAAAAAAAAAAAAAiiTvUAAAAAAAAAAA AAAAAL8fk28AAAAAAAAAAAAAAABDWSIHAAAAAAAAAAAAAAAAjHPEegAAAAAAAAAAAAAAAMcI7xkA AAAAAAAAAAAAAABYPa15AAAAAAAAAAAAAAAAH3IYDQAAAAAAAAAAAAAAAEULaC4AAAAAAAAAAAAA AACiBeIIAAAAAAAAAAAAAAAA/0iYVgAAAAAAAAAAAAAAAJ4jRVsAAAAAAAAAAAAAAADKEz8TAAAA AAAAAAAAAAAAH0dYbwAAAAAAAAAAAAAAAEhiJFYAAAAAAAAAAAAAAAAVLFo0AAAAAAAAAAAAAAAA uQKyUAAAAAAAAAAAAAAAAKoVLxsAAAAAAAAAAAAAAABSClAeAAAAAAAAAAAAAAAAC3TudQAAAAAA AAAAAAAAAFcWpREAAAAAAAAAAAAAAAA4KV1JAAAAAAAAAAAAAAAAFFePfwAAAAAAAAAAAAAAAAge 1loAAAAAAAAAAAAAAAAmFXxdAAAAAAAAAAAAAAAAK3u/AgAAAAAAAAAAAAAAAGVnYXwAAAAAAAAA AAAAAACmVfw4AAAAAAAAAAAAAAAAzx/BCwAAAAAAAAAAAAAAAPsYUD8AAAAAAAAAAAAAAAA5aAEO AAAAAAAAAAAAAAAA+Fd7HwAAAAAAAAAAAAAAACYYKgMAAAAAAAAAAAAAAADTA9hrAAAAAAAAAAAA AAAAfXL3aQAAAAAAAAAAAAAAAAd3+3kAAAAAAAAAAAAAAADWdS4mAAAAAAAAAAAAAAAAtiMTYwAA AAAAAAAAAAAAAC1b5yUAAAAAAAAAAAAAAADxAERXAAAAAAAAAAAAAAAAAVsOXwAAAAAAAAAAAAAA AHdI6gsAAAAAAAAAAAAAAAA9DYgwAAAAAAAAAAAAAAAA2Ef1XQAAAAAAAAAAAAAAANJz7GQAAAAA AAAAAAAAAAAOYDcTAAAAAAAAAAAAAAAAnld1VAAAAAAAAAAAAAAAAFEXiUcAAAAAAAAAAAAAAAAw AjEaAAAAAAAAAAAAAAAAHREULQAAAAAAAAAAAAAAAE9FfDAAAAAAAAAAAAAAAAAHEAEgAAAAAAAA AAAAAAAA01CRGgAAAAAAAAAAAAAAAF1Q8wIAAAAAAAAAAAAAAAD4WSpLAAAAAAAAAAAAAAAAJyd7 DgAAAAAAAAAAAAAAAIsXTAMAAAAAAAAAAAAAAADTZNMOAAAAAAAAAAAAAAAA2gNyRAAAAAAAAAAA AAAAAFlpwmoAAAAAAAAAAAAAAACZBrcIAAAAAAAAAAAAAAAASDI+OQAAAAAAAAAAAAAAAKZsGC8A AAAAAAAAAAAAAACIDn8XAAAAAAAAAAAAAAAAL2M+PAAAAAAAAAAAAAAAAP7///8AAAAAaCikBwEA AAAbLMFcAAAAAAAAAAAAAAAAIH87VQAAAAAAAAAAAAAAADJ6WzYAAAAAAAAAAAAAAACefjUxAAAA AAAAAAAAAAAAiTG/JgAAAAAAAAAAAAAAAMFjxgcAAAAAAAAAAAAAAAApNH0uAAAAAAAAAAAAAAAA zi1nVAAAAAAAAAAAAAAAAFxyBAMAAAAAAAAAAAAAAACHTbQ+AAAAAAAAAAAAAAAABVBneAAAAAAA AAAAAAAAAFt/GAkAAAAAAAAAAAAAAAB5CLgmAAAAAAAAAAAAAAAANFpoUQAAAAAAAAAAAAAAAOl1 F0QAAAAAAAAAAAAAAAADVx9vAAAAAAAAAAAAAAAABXeSZAAAAADEKKQHBAAAAEVVSzwAAAAAAAAA AAAAAAA7YtQxAAAAAAAAAAAAAAAARDsrIAAAAAAAAAAAAAAAAFMuEnAAAAAAAAAAAAAAAACjWt5L AAAAAAAAAAAAAAAAAV1CbAAAAAAAAAAAAAAAANdF7QMAAAAAAAAAAAAAAABoZ8pVAAAAAAAAAAAA AAAAykiLXgAAAAAAAAAAAAAAAJALJi8AAAAAAAAAAAAAAABfWiI6AAAAAAAAAAAAAAAAqni/LwAA AAAAAAAAAAAAAIFVymgAAAAAAAAAAAAAAAArMhF+AAAAAAAAAAAAAAAAPzfzNwAAAAAAAAAAAAAA AKcSXhQAAAAAAAAAAAAAAABPYXY0AAAAAAAAAAAAAAAAn3FoTAAAAAAAAAAAAAAAAJpSvWEAAAAA AAAAAAAAAAC0R+FzAAAAAAAAAAAAAAAA/v///wAAAADoKKQHAQAAAP7///8AAAAARCmkBwEAAAD+ ////AAAAAKAppAcBAAAA/v///wAAAAD8KaQHAQAAAP7///8AAAAAWCqkBwEAAAD+////AAAAALQq pAcBAAAA/v///wAAAAAQK6QHAQAAAP7///8AAAAAbCukBwEAAAD+////AAAAAMgrpAcBAAAA/v// /wAAAAAkLKQHAQAAAP7///8AAAAAgCykBwEAAAD+////AAAAANwspAcBAAAA/v///wAAAAA4LaQH AQAAAP7///8AAAAAlC2kBwEAAAD+////AAAAAPAtpAcBAAAA/v///wAAAABMLqQHAQAAAP7///8A AAAAqC6kBwEAAAD+////AAAAAAQvpAcBAAAA/v///wAAAABgL6QHAQAAAP7///8AAAAAvC+kBwEA AAD+////AAAAABgwpAcBAAAA/v///wAAAAB0MKQHAQAAAP7///8AAAAA0DCkBwEAAAD+////AAAA ACwxpAcBAAAA/v///wAAAACIMaQHAQAAAP7///8AAAAA5DGkBwEAAAD+////AAAAAEAypAcBAAAA /v///wAAAACcMqQHAQAAAP7///8AAAAA+DKkBwEAAAD+////AAAAAFQzpAcBAAAA/v///wAAAACw M6QHAQAAAP7///8AAAAADDSkBwEAAAD+////AAAAAGg0pAcBAAAA/v///wAAAADENKQHAQAAAP7/ //8AAAAAIDWkBwEAAAD+////AAAAAHw1pAcBAAAA/v///wAAAADYNaQHAQAAAP7///8AAAAANDak BwEAAAD+////AAAAAJA2pAcBAAAA/v///wAAAADsNqQHAQAAAP7///8AAAAASDekBwEAAAD+//// AAAAAKQ3pAcBAAAA/v///wAAAAAAOKQHAQAAAP7///8AAAAAXDikBwEAAAD+////AAAAALg4pAcB AAAA/v///wAAAAAUOaQHAQAAAP7///8AAAAAcDmkBwEAAAD+////AAAAAMw5pAcBAAAAZwKfPwAA AAAAAAAAAAAAADh1JS4AAAAAAAAAAAAAAAB8Ec5yAAAAAAAAAAAAAAAAEWQkRwAAAAAAAAAAAAAA AK5wb3wAAAAAAAAAAAAAAACCLvpGAAAAAAAAAAAAAAAAif///wAAAAAAAAAAAAAAAP7///8AAAAA KDqkBwEAAAD+////AAAAAIQ6pAcBAAAA/v///wAAAADgOqQHAQAAAP7///8AAAAAPDukBwEAAAD+ ////AAAAAJg7pAcBAAAA/v///wAAAAD0O6QHAQAAAP7///8AAAAAUDykBwEAAAD+////AAAAAKw8 pAcBAAAA/v///wAAAAAIPaQHAQAAAP7///8AAAAAZD2kBwEAAAD+////AAAAAMA9pAcBAAAA/v// /wAAAAAcPqQHAQAAAP7///8AAAAAeD6kBwEAAAD+////AAAAANQ+pAcBAAAA/v///wAAAAAwP6QH AQAAAP7///8AAAAAjD+kBwEAAAD+////AAAAAOg/pAcBAAAA/v///wAAAABEQKQHAQAAAP7///8A AAAAoECkBwEAAAD+////AAAAAPxApAcBAAAA/v///wAAAABYQaQHAQAAAP7///8AAAAAtEGkBwEA AAD+////AAAAABBCpAcBAAAA/v///wAAAABsQqQHAQAAAP7///8AAAAAyEKkBwEAAAD+////AAAA ACRDpAcBAAAA/v///wAAAACAQ6QHAQAAAP7///8AAAAA3EOkBwEAAAD+////AAAAADhEpAcBAAAA /v///wAAAACURKQHAQAAAP7///8AAAAA8ESkBwEAAAD+////AAAAAExFpAcBAAAA/v///wAAAACo RaQHAQAAAP7///8AAAAABEakBwEAAAD+////AAAAAGBGpAcBAAAA/v///wAAAAC8RqQHAQAAAP7/ //8AAAAAGEekBwEAAAD+////AAAAAHRHpAcBAAAA/v///wAAAADQR6QHAQAAAP7///8AAAAALEik BwEAAAD+////AAAAAIhIpAcBAAAA/v///wAAAADkSKQHAQAAAP7///8AAAAAQEmkBwEAAAD+//// AAAAAJxJpAcBAAAA/v///wAAAAD4SaQHAQAAAP7///8AAAAAVEqkBwEAAAD+////AAAAALBKpAcB AAAA/v///wAAAAAMS6QHAQAAAP7///8AAAAAaEukBwEAAAD+////AAAAAMRLpAcBAAAA/v///wAA AAAgTKQHAQAAAP7///8AAAAAfEykBwEAAAD+////AAAAANhMpAcBAAAA/v///wAAAAA0TaQHAQAA AP7///8AAAAAkE2kBwEAAAD+////AAAAAOxNpAcBAAAA/v///wAAAABITqQHAQAAAP7///8AAAAA pE6kBwEAAAD+////AAAAAABPpAcBAAAA/v///wAAAABcT6QHAQAAAP7///8AAAAAuE+kBwEAAAD+ ////AAAAABRQpAcBAAAA/v///wAAAABwUKQHAQAAAP7///8AAAAAzFCkBwEAAAD+////AAAAAChR pAcBAAAA/v///wAAAACEUaQHAQAAAP7///8AAAAA4FGkBwEAAAD+////AAAAADxSpAcBAAAA/v// /wAAAACYUqQHAQAAAP7///8AAAAA9FKkBwEAAAD+////AAAAAFBTpAcBAAAA/v///wAAAACsU6QH AQAAAP7///8AAAAACFSkBwEAAAD+////AAAAAGRUpAcBAAAA/v///wAAAADAVKQHAQAAAP7///8A AAAAHFWkBwEAAAD+////AAAAAHhVpAcBAAAA/v///wAAAADUVaQHAQAAAP7///8AAAAAMFakBwEA AAD+////AAAAAIxWpAcBAAAA/v///wAAAADoVqQHAQAAAP7///8AAAAARFekBwEAAAD+////AAAA AKBXpAcBAAAA/v///wAAAAD8V6QHAQAAAP7///8AAAAAWFikBwEAAAD+////AAAAALRYpAcBAAAA /v///wAAAAAQWaQHAQAAAP7///8AAAAAbFmkBwEAAAD+////AAAAAMhZpAcBAAAA/v///wAAAAAk WqQHAQAAAP7///8AAAAAgFqkBwEAAAD+////AAAAANxapAcBAAAA/v///wAAAAA4W6QHAQAAAP7/ //8AAAAAlFukBwEAAAD+////AAAAAPBbpAcBAAAA/v///wAAAABMXKQHAQAAAP7///8AAAAAqFyk BwEAAAD+////AAAAAARdpAcBAAAA/v///wAAAABgXaQHAQAAAP7///8AAAAAvF2kBwEAAAD+//// AAAAABhepAcBAAAA/v///wAAAAB0XqQHAQAAAP7///8AAAAA0F6kBwEAAAD+////AAAAACxfpAcB AAAA/v///wAAAACIX6QHAQAAAP7///8AAAAA5F+kBwEAAAD+////AAAAAEBgpAcBAAAA/v///wAA AACcYKQHAQAAAP7///8AAAAA+GCkBwEAAAD+////AAAAAFRhpAcBAAAA/v///wAAAACwYaQHAQAA AP7///8AAAAADGKkBwEAAAD+////AAAAAGhipAcBAAAA/v///wAAAADEYqQHAQAAAP7///8AAAAA IGOkBwEAAAD+////AAAAAHxjpAcBAAAA/v///wAAAADYY6QHAQAAAP7///8AAAAANGSkBwEAAAD+ ////AAAAAJBkpAcBAAAA/v///wAAAADsZKQHAQAAAP7///8AAAAASGWkBwEAAAD+////AAAAAKRl pAcBAAAA/v///wAAAAAAZqQHAQAAAP7///8AAAAAXGakBwEAAAD+////AAAAALhmpAcBAAAA/v// /wAAAAAUZ6QHAQAAAP7///8AAAAAcGekBwEAAAD+////AAAAAMxnpAcBAAAA/v///wAAAAAoaKQH AQAAAP7///8AAAAAhGikBwEAAAD+////AAAAAOBopAcBAAAA/v///wAAAAA8aaQHAQAAAP7///8A AAAAmGmkBwEAAAD+////AAAAAPRppAcBAAAA/v///wAAAABQaqQHAQAAAP7///8AAAAArGqkBwEA AAD+////AAAAAAhrpAcBAAAA/v///wAAAABka6QHAQAAAP7///8AAAAAwGukBwEAAAD+////AAAA ABxspAcBAAAA/v///wAAAAB4bKQHAQAAAP7///8AAAAA1GykBwEAAAD+////AAAAADBtpAcBAAAA /v///wAAAACMbaQHAQAAAP7///8AAAAA6G2kBwEAAAD+////AAAAAERupAcBAAAA/v///wAAAACg bqQHAQAAAP7///8AAAAA/G6kBwEAAAD+////AAAAAFhvpAcBAAAA/v///wAAAAC0b6QHAQAAAP7/ //8AAAAAEHCkBwEAAAD+////AAAAAGxwpAcBAAAA/v///wAAAADIcKQHAQAAAP7///8AAAAAJHGk BwEAAAD+////AAAAAIBxpAcBAAAA/v///wAAAADccaQHAQAAAP7///8AAAAAOHKkBwEAAAD+//// AAAAAJRypAcBAAAA/v///wAAAADwcqQHAQAAAP7///8AAAAATHOkBwEAAAD+////AAAAAKhzpAcB AAAA/v///wAAAAAEdKQHAQAAAP7///8AAAAAYHSkBwEAAAD+////AAAAALx0pAcBAAAA/v///wAA AAAYdaQHAQAAAP7///8AAAAAdHWkBwEAAAD+////AAAAANB1pAcBAAAA/v///wAAAAAsdqQHAQAA AP7///8AAAAAiHakBwEAAAD+////AAAAAOR2pAcBAAAA/v///wAAAABAd6QHAQAAAP7///8AAAAA nHekBwEAAAD+////AAAAAPh3pAcBAAAA/v///wAAAABUeKQHAQAAAP7///8AAAAAsHikBwEAAAD+ ////AAAAAAx5pAcBAAAA/v///wAAAABoeaQHAQAAAP7///8AAAAAxHmkBwEAAAD+////AAAAACB6 pAcBAAAA/v///wAAAAB8eqQHAQAAAP7///8AAAAA2HqkBwEAAAD+////AAAAADR7pAcBAAAA/v// /wAAAACQe6QHAQAAAP7///8AAAAA7HukBwEAAAD+////AAAAAEh8pAcBAAAA/v///wAAAACkfKQH AQAAAP7///8AAAAAAH2kBwEAAAD+////AAAAAFx9pAcBAAAA/v///wAAAAC4faQHAQAAAP7///8A AAAAFH6kBwEAAAD+////AAAAAHB+pAcBAAAA/v///wAAAADMfqQHAQAAAP7///8AAAAAKH+kBwEA AAAFd5JkAAAAAIR/pAcEAAAA/v///wAAAACof6QHAQAAAP7///8AAAAABICkBwEAAAD+////AAAA AGCApAcBAAAA/v///wAAAAC8gKQHAQAAAP7///8AAAAAGIGkBwEAAAD+////AAAAAHSBpAcBAAAA /v///wAAAADQgaQHAQAAAP7///8AAAAALIKkBwEAAAD+////AAAAAIiCpAcBAAAA/v///wAAAADk gqQHAQAAAP7///8AAAAAQIOkBwEAAAD+////AAAAAJyDpAcBAAAA/v///wAAAAD4g6QHAQAAAP7/ //8AAAAAVISkBwEAAAD+////AAAAALCEpAcBAAAA/v///wAAAAAMhaQHAQAAAP7///8AAAAAaIWk BwEAAAD+////AAAAAMSFpAcBAAAA/v///wAAAAAghqQHAQAAAP7///8AAAAAfIakBwEAAAD+//// AAAAANiGpAcBAAAA/v///wAAAAA0h6QHAQAAAP7///8AAAAAkIekBwEAAAD+////AAAAAOyHpAcB AAAA/v///wAAAABIiKQHAQAAAP7///8AAAAApIikBwEAAAD+////AAAAAACJpAcBAAAA/v///wAA AABciaQHAQAAAP7///8AAAAAuImkBwEAAAD+////AAAAABSKpAcBAAAA/v///wAAAABwiqQHAQAA AP7///8AAAAAzIqkBwEAAAD+////AAAAACiLpAcBAAAA/v///wAAAACEi6QHAQAAAP7///8AAAAA 4IukBwEAAAD+////AAAAADyMpAcBAAAA/v///wAAAACYjKQHAQAAAP7///8AAAAA9IykBwEAAAD+ ////AAAAAFCNpAcBAAAA/v///wAAAACsjaQHAQAAAP7///8AAAAACI6kBwEAAAD+////AAAAAGSO pAcBAAAA/v///wAAAADAjqQHAQAAAP7///8AAAAAHI+kBwEAAAD+////AAAAAHiPpAcBAAAA/v// /wAAAADUj6QHAQAAAP7///8AAAAAMJCkBwEAAAD+////AAAAAIyQpAcBAAAA7AxCSgAAAAAAAAAA AAAAALEXjUQAAAAAAAAAAAAAAAAzPXMfAAAAAAAAAAAAAAAAN257GwAAAAAAAAAAAAAAADsNuH8A AAAAAAAAAAAAAAAmQ8hUAAAAAAAAAAAAAAAADyTDOQAAAAAAAAAAAAAAAN1BMhUAAAAAAAAAAAAA AAAWLY0IAAAAAAAAAAAAAAAAzBcvaAAAAAAAAAAAAAAAAN0uXWsAAAAAAAAAAAAAAADITN5/AAAA AAAAAAAAAAAAWDd8fgAAAAAAAAAAAAAAACQQ+3sAAAAAAAAAAAAAAADZXjR7AAAAAAAAAAAAAAAA aSeGCAAAAAAAAAAAAAAAAPVqwyUAAAAAAAAAAAAAAAAIHfx4AAAAAAAAAAAAAAAA62ZVCAAAAAAA AAAAAAAAAIk+QgIAAAAAAAAAAAAAAAABIdcuAAAAAAAAAAAAAAAA/y9RWgAAAAAAAAAAAAAAAGFm tQ4AAAAAAAAAAAAAAAD4NBdYAAAAAAAAAAAAAAAArUW+QQAAAAAAAAAAAAAAANIsOVEAAAAAAAAA AAAAAAAwXSwgAAAAAAAAAAAAAAAAUXdbVwAAAAAAAAAAAAAAAMNrbCUAAAAAAAAAAAAAAAABDAln AAAAAAAAAAAAAAAAsh9kLQAAAAAAAAAAAAAAAFk+FXMAAAAAAAAAAAAAAABAI2AOAAAAAAAAAAAA AAAAOlOlFwAAAAAAAAAAAAAAAPJ/EDAAAAAAAAAAAAAAAACBWRI0AAAAAAAAAAAAAAAADXGFZQAA AAAAAAAAAAAAAJ0LRFAAAAAAAAAAAAAAAAAFRl02AAAAAAAAAAAAAAAAk2qmfwAAAAAAAAAAAAAA AFV9flIAAAAAAAAAAAAAAACyF4R9AAAAAAAAAAAAAAAAxwhDQAAAAAAAAAAAAAAAAOFHd2IAAAAA AAAAAAAAAADLO4c5AAAAAAAAAAAAAAAAew6xKgAAAAAAAAAAAAAAAHlA70QAAAAAAAAAAAAAAABw WTJtAAAAAAAAAAAAAAAAJw+acAAAAAAAAAAAAAAAANtUFgwAAAAAAAAAAAAAAAA8LsRYAAAAAAAA AAAAAAAAt0j7YAAAAAAAAAAAAAAAAJ1Q+0YAAAAAAAAAAAAAAAB8NcdtAAAAAAAAAAAAAAAAaHlA IwAAAAAAAAAAAAAAAIAPA1kAAAAAAAAAAAAAAADoNi1eAAAAAAAAAAAAAAAAGApmKAAAAAAAAAAA AAAAAFU752AAAAAAAAAAAAAAAABSIbpnAAAAAAAAAAAAAAAAjkjZCwAAAAAAAAAAAAAAANAgwycA AAAAAAAAAAAAAABeM0gUAAAAAAAAAAAAAAAA/W9KSAAAAAAAAAAAAAAAAJMduB8AAAAAAAAAAAAA AADWGHg8AAAAAAAAAAAAAAAAu3vwBQAAAAAAAAAAAAAAAFIecwIAAAAAAAAAAAAAAADGdO9dAAAA AAAAAAAAAAAAlDpgHAAAAAAAAAAAAAAAAKdP3nMAAAAAAAAAAAAAAACmT2x+AAAAAAAAAAAAAAAA TDyBTAAAAAAAAAAAAAAAAMAfq2UAAAAAAAAAAAAAAACiUpFKAAAAAAAAAAAAAAAAm0U4agAAAAAA AAAAAAAAAHIPiR8AAAAAAAAAAAAAAABPEvBDAAAAAAAAAAAAAAAAbFsMGwAAAAAAAAAAAAAAAFNr HwoAAAAAAAAAAAAAAADfUDEmAAAAAAAAAAAAAAAA3wA/RwAAAAAAAAAAAAAAAMY6RBMAAAAAAAAA AAAAAADgUT12AAAAAAAAAAAAAAAAeRbbPgAAAAAAAAAAAAAAALsdp04AAAAAAAAAAAAAAAD4bNlB AAAAAAAAAAAAAAAA2ztJYwAAAAAAAAAAAAAAAKgQcAoAAAAAAAAAAAAAAAAJSQE/AAAAAAAAAAAA AAAAPxuOIAAAAAAAAAAAAAAAADg35mMAAAAAAAAAAAAAAABwbKoNAAAAAAAAAAAAAAAAcG4NRwAA AAAAAAAAAAAAAOUEygMAAAAAAAAAAAAAAAAuVXxrAAAAAAAAAAAAAAAAkVGmDQAAAAAAAAAAAAAA AL0GfwEAAAAAAAAAAAAAAAC2Cl86AAAAAAAAAAAAAAAAyzCPLAAAAAAAAAAAAAAAADUxoA4AAAAA AAAAAAAAAADLJDoFAAAAAAAAAAAAAAAA1B5bJgAAAAAAAAAAAAAAAOFRY1YAAAAAAAAAAAAAAAB/ AdJ3AAAAAAAAAAAAAAAAlEnoJgAAAAAAAAAAAAAAAPxCxn4AAAAAAAAAAAAAAACicj8MAAAAAAAA AAAAAAAA4kgVcwAAAAAAAAAAAAAAAGEC3jsAAAAAAAAAAAAAAAB0T/MCAAAAAAAAAAAAAAAAFDCH UwAAAAAAAAAAAAAAAHwTqCMAAAAAAAAAAAAAAABWZb4rAAAAAAAAAAAAAAAAwwlTbAAAAAAAAAAA AAAAAA9Ysy0AAAAAAAAAAAAAAAByLsZ3AAAAAAAAAAAAAAAApQvIAQAAAAAAAAAAAAAAAN44114A AAAAAAAAAAAAAADmRFVsAAAAAAAAAAAAAAAAoRZWegAAAAAAAAAAAAAAAHBGQlAAAAAAAAAAAAAA AADOSMdtAAAAAAAAAAAAAAAADhUVTwAAAAAAAAAAAAAAABplkHUAAAAAAAAAAAAAAADBY/dXAAAA AAAAAAAAAAAANB05KQAAAAAAAAAAAAAAALBm9zkAAAAAAAAAAAAAAADfENQ6AAAAAAAAAAAAAAAA ay1RAQAAAAAAAAAAAAAAAG8KgQ8AAAAAAAAAAAAAAAAGUwh6AAAAAAAAAAAAAAAAklqBWgAAAAAA AAAAAAAAALw+MV4AAAAAAAAAAAAAAAAwYptgAAAAAAAAAAAAAAAAyWtGJwAAAAAAAAAAAAAAAKZz 1kUAAAAAAAAAAAAAAADABwFqAAAAAAAAAAAAAAAApx5RAQAAAAAAAAAAAAAAAB8FtxMAAAAAAAAA AAAAAAC+QugjAAAAAAAAAAAAAAAAmCPoNgAAAAAAAAAAAAAAAPdycCwAAAAAAAAAAAAAAAD///// /////2DznwcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBv KAABALfw/////7zznwcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oB AFFKAQBvKAABAC3w//////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////8Y9J8HIAAAAAEAAAAXQAAA AAAAAAAAAAAAAAAAaAEAAAsIAAAPhKAFEYSY/k9KAQBRSgEAbygAAQC38P////////////////// ////////dPSfByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGEmP5PSgEAUUoB AG8oAAEAt/D///////////////////////////////////////////////////////////////// ////0PSfByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4RoARGEmP5PSgEAUUoBAG8o AAEAt/D/////LPWfByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4TQAhGEmP5PSgEA UUoBAG8oAAEALfD/////iPWfByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4SgBRGE mP5PSgEAUUoBAG8oAAEAt/D/////5PWfByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAA D4QIBxGEmP5PSgEAUUoBAG8oAAEAt/D/////QPafByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgB AAALCAAAD4RoARGEmP5PSgEAUUoBAG8oAAEAt/D/////nPafByAAAAABAAAAF0AAAAAAAAAAAAAA AAAAAGgBAAALCAAAD4TQAhGEmP5PSgEAUUoBAG8oAAEALfD/////+PafByAAAAABAAAAF0AAAAAA AAAAAAAAAAAAAGgBAAALCAAAD4SgBRGEmP5PSgEAUUoBAG8oAAEAt/D/////VPefByAAAAABAAAA F0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGEmP5PSgEAUUoBAG8oAAEAt/D///////////// /////////////////////////////////////////////////////////////7D3nwcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////wz4nwcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w//// /2j4nwcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAAB ALfw/////8T4nwcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFK AQBvKAABALfw/////yD5nwcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+ T0oBAFFKAQBvKAABALfw/////3z5nwcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E 0AIRhJj+T0oBAFFKAQBvKAABAC3w/////9j5nwcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////zT6nwcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////5D6nwcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////+z6nwcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////0j7nwcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////6T7 nwcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw //////////////////////////8A/J8HIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAP hGgBEYSY/k9KAQBRSgEAbygAAQC38P////9c/J8HIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEA AAsIAAAPhNACEYSY/k9KAQBRSgEAbygAAQAt8P////+4/J8HIAAAAAEAAAAXQAAAAAAAAAAAAAAA AAAAaAEAAAsIAAAPhKAFEYSY/k9KAQBRSgEAbygAAQC38P////8U/Z8HIAAAAAEAAAAXQAAAAAAA AAAAAAAAAAAAaAEAAAsIAAAPhAgHEYSY/k9KAQBRSgEAbygAAQC38P////9w/Z8HIAAAAAEAAAAX QAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhGgBEYSY/k9KAQBRSgEAbygAAQC38P/////M/Z8HIAAA AAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhNACEYSY/k9KAQBRSgEAbygAAQAt8P////8o /p8HIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhKAFEYSY/k9KAQBRSgEAbygAAQC3 8P////+E/p8HIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhAgHEYSY/k9KAQBRSgEA bygAAQC38P/////g/p8HIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhGgBEYSY/k9K AQBRSgEAbygAAQC38P////88/58HIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhNAC EYSY/k9KAQBRSgEAbygAAQAt8P////+Y/58HIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsI AAAPhKAFEYSY/k9KAQBRSgEAbygAAQC38P////8A8JYHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAA aAEAAAsIAAAPhAgHEYSY/k9KAQBRSgEAbygAAQC38P////////////////////////////////// ////////XPCWByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4RoARGEmP5PSgEAUUoB AG8oAAEAt/D/////uPCWByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4TQAhGEmP5P SgEAUUoBAG8oAAEALfD/////FPGWByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Sg BRGEmP5PSgEAUUoBAG8oAAEAt/D/////cPGWByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAAL CAAAD4QIBxGEmP5PSgEAUUoBAG8oAAEAt/D/////zPGWByAAAAABAAAAF0AAAAAAAAAAAAAAAAAA AGgBAAALCAAAD4RoARGEmP5PSgEAUUoBAG8oAAEAt/D/////KPKWByAAAAABAAAAF0AAAAAAAAAA AAAAAAAAAGgBAAALCAAAD4TQAhGEmP5PSgEAUUoBAG8oAAEALfD/////hPKWByAAAAABAAAAF0AA AAAAAAAAAAAAAAAAAGgBAAALCAAAD4SgBRGEmP5PSgEAUUoBAG8oAAEAt/D/////4PKWByAAAAAB AAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGEmP5PSgEAUUoBAG8oAAEAt/D/////PPOW ByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4RoARGEmP5PSgEAUUoBAG8oAAEAt/D/ ////mPOWByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4TQAhGEmP5PSgEAUUoBAG8o AAEALfD/////9POWByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4SgBRGEmP5PSgEA UUoBAG8oAAEAt/D/////UPSWByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGE mP5PSgEAUUoBAG8oAAEAt/D///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////////////////////////////6z0 lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw /////wj1lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBv KAABAC3w/////2T1lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oB AFFKAQBvKAABALfw/////8D1lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcR hJj+T0oBAFFKAQBvKAABALfw/////xz2lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////3j2lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////9T2lgcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////zD3lgcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////4z3lgcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////+j3lgcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w//// /0T4lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAAB ALfw/////6D4lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFK AQBvKAABALfw//////z4lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+ T0oBAFFKAQBvKAABALfw/////1j5lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E 0AIRhJj+T0oBAFFKAQBvKAABAC3w/////7T5lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////xD6lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////2z6lgcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////8j6lgcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////yT7lgcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////4D7 lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw /////9z7lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBv KAABALfw/////zj8lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oB AFFKAQBvKAABAC3w/////5T8lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAUR hJj+T0oBAFFKAQBvKAABALfw//////D8lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////0z9lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////6j9lgcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////wT+lgcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////2D+lgcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////7z+lgcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw//// /xj/lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAAB AC3w/////3T/lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFK AQBvKAABALfw/////9D/lgcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+ T0oBAFFKAQBvKAABALfw/////zQApAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E aAERhJj+T0oBAFFKAQBvKAABALfw/////5AApAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////+wApAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////0gBpAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////6QBpAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////wACpAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////1wC pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw /////7gCpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBv KAABALfw/////xQDpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oB AFFKAQBvKAABALfw/////3ADpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIR hJj+T0oBAFFKAQBvKAABAC3w/////8wDpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////ygEpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////4QEpAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////+AEpAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////zwFpAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////5gFpAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw//// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////9AWkByAAAAAB AAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/////UAak ByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/ ////rAakByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8o AAEAt/D//////////////////////////wgHpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////2QHpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABAODw/////8AHpAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw//////////////////////// //////////////////////////////////////////////////////////////////8cCKQHIAAA AAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////94 CKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC3 8P/////UCKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEA bygAAQC38P////8wCaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9K AQBRSgEAbygAAQC38P////+MCaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhAgH EYSY/k9KAQBRSgEAbygAAQDg8P/////oCaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsI AAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////9ECqQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAA aAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////+gCqQHIAAAAAEAAAAXQAAAAAAAAAAA AAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P/////8CqQHIAAAAAEAAAAXQAAA AAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////9YC6QHIAAAAAEA AAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////+0C6QH IAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhAgHEYSY/k9KAQBRSgEAbygAAQDg8P// //8QDKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygA AQC38P////9sDKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBR SgEAbygAAQC38P/////IDKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY /k9KAQBRSgEAbygAAQC38P////8kDaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAP hDgEEYSY/k9KAQBRSgEAbygAAQC38P////+ADaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEA AAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P/////cDaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAA AAAAaAEAAAsIAAAPhAgHEYSY/k9KAQBRSgEAbygAAQDg8P////84DqQHIAAAAAEAAAAXQAAAAAAA AAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P//////////lA6kByAAAAAB AAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/////8A6k ByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/ ////TA+kByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8o AAEAt/D/////qA+kByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEA UUoBAG8oAAEAt/D/////BBCkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGE mP5PSgEAUUoBAG8oAAEA4PD/////YBCkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAA D4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/////vBCkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgB AAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/////GBGkByAAAAABAAAAF0AAAAAAAAAAAAAA AAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/////dBGkByAAAAABAAAAF0AAAAAA AAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/////0BGkByAAAAABAAAA F0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/////LBKkByAA AAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGEmP5PSgEAUUoBAG8oAAEA4PD///// iBKkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEA t/D/////5BKkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoB AG8oAAEAt/D/////QBOkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5P SgEAUUoBAG8oAAEAt/D/////nBOkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4 BBGEmP5PSgEAUUoBAG8oAAEAt/D/////+BOkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAAL CAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/////VBSkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAA AGgBAAALCAAAD4QIBxGEmP5PSgEAUUoBAG8oAAEA4PD/////sBSkByAAAAABAAAAF0AAAAAAAAAA AAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/////DBWkByAAAAABAAAAF0AA AAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/////aBWkByAAAAAB AAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/////xBWk ByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8oAAEAt/D/ ////IBakByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGEmP5PSgEAUUoBAG8o AAEAt/D/////fBakByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGEmP5PSgEA UUoBAG8oAAEA4PD/////2BakByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Q4BBGE mP5PSgEAUUoBAG8oAAEAt/D///////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////80F6QHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEA AAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////+QF6QHIAAAAAEAAAAXQAAAAAAAAAAAAAAA AAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P/////sF6QHIAAAAAEAAAAXQAAAAAAA AAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////9IGKQHIAAAAAEAAAAX QAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////+kGKQHIAAA AAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhAgHEYSY/k9KAQBRSgEAbygAAQDg8P////8A GaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC3 8P////9cGaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEA bygAAQC38P////+4GaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9K AQBRSgEAbygAAQC38P////8UGqQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgE EYSY/k9KAQBRSgEAbygAAQC38P////9wGqQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsI AAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P/////MGqQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAA aAEAAAsIAAAPhAgHEYSY/k9KAQBRSgEAbygAAQDg8P////8oG6QHIAAAAAEAAAAXQAAAAAAAAAAA AAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////+EG6QHIAAAAAEAAAAXQAAA AAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P/////gG6QHIAAAAAEA AAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////88HKQH IAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P// //+YHKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygA AQC38P/////0HKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhAgHEYSY/k9KAQBR SgEAbygAAQDg8P////9QHaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY /k9KAQBRSgEAbygAAQC38P////+sHaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAP hDgEEYSY/k9KAQBRSgEAbygAAQC38P////8IHqQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEA AAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////9kHqQHIAAAAAEAAAAXQAAAAAAAAAAAAAAA AAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P/////AHqQHIAAAAAEAAAAXQAAAAAAA AAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////8cH6QHIAAAAAEAAAAX QAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhAgHEYSY/k9KAQBRSgEAbygAAQDg8P////94H6QHIAAA AAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P/////U H6QHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC3 8P////8wIKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEA bygAAQC38P////+MIKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9K AQBRSgEAbygAAQC38P/////oIKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgE EYSY/k9KAQBRSgEAbygAAQC38P////9EIaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsI AAAPhAgHEYSY/k9KAQBRSgEAbygAAQDg8P////+gIaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAA aAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P/////8IaQHIAAAAAEAAAAXQAAAAAAAAAAA AAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////9YIqQHIAAAAAEAAAAXQAAA AAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////+0IqQHIAAAAAEA AAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////8QI6QH IAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P// //9sI6QHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhAgHEYSY/k9KAQBRSgEAbygA AQDg8P/////II6QHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBR SgEAbygAAQC38P////8kJKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY /k9KAQBRSgEAbygAAQC38P////+AJKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAP hDgEEYSY/k9KAQBRSgEAbygAAQC38P/////cJKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEA AAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////84JaQHIAAAAAEAAAAXQAAAAAAAAAAAAAAA AAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////+UJaQHIAAAAAEAAAAXQAAAAAAA AAAAAAAAAAAAaAEAAAsIAAAPhAgHEYSY/k9KAQBRSgEAbygAAQDg8P/////wJaQHIAAAAAEAAAAX QAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////9MJqQHIAAA AAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////+o JqQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEAbygAAQC3 8P////8EJ6QHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9KAQBRSgEA bygAAQC38P////9gJ6QHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhDgEEYSY/k9K AQBRSgEAbygAAQC38P////+8J6QHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsIAAAPhAgH EYSY/k9KAQBRSgEAbygAAQDg8P////8YKKQHIAAAAAEAAAAXQAAAAAAAAAAAAAAAAAAAaAEAAAsI AAAPhDgEEYSY/k9KAQBRSgEAbygAAQC38P////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////////////////////////////////////////////////////////////dCikByAAAAAB AAAAF0AAAAAAAAAAAAAAAAAAABsBAAALCAAAD4Q3AhGE5f5PSgEAUUoBAG8oAAEAt/D///////// //////////////////////////////////////////////////////////////////////////// /////wIAAAAQAAAAAwAAABEAAAABAAAAEgAAAAUAAAATAAAA//////////////////////////// //////////////////////////////////////////////////////////////////////////// ////////9CikByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4RoARGEmP5PSgEAUUoB AG8oAAEAt/D/////UCmkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4TQAhGEmP5P SgEAUUoBAG8oAAEALfD/////rCmkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Sg BRGEmP5PSgEAUUoBAG8oAAEAt/D/////CCqkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAAL CAAAD4QIBxGEmP5PSgEAUUoBAG8oAAEAt/D/////ZCqkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAA AGgBAAALCAAAD4RoARGEmP5PSgEAUUoBAG8oAAEAt/D/////wCqkByAAAAABAAAAF0AAAAAAAAAA AAAAAAAAAGgBAAALCAAAD4TQAhGEmP5PSgEAUUoBAG8oAAEALfD/////HCukByAAAAABAAAAF0AA AAAAAAAAAAAAAAAAAGgBAAALCAAAD4SgBRGEmP5PSgEAUUoBAG8oAAEAt/D/////eCukByAAAAAB AAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGEmP5PSgEAUUoBAG8oAAEAt/D/////1Cuk ByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4RoARGEmP5PSgEAUUoBAG8oAAEAt/D/ ////MCykByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4TQAhGEmP5PSgEAUUoBAG8o AAEALfD/////jCykByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4SgBRGEmP5PSgEA UUoBAG8oAAEAt/D/////6CykByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGE mP5PSgEAUUoBAG8oAAEAt/D/////RC2kByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAA D4RoARGEmP5PSgEAUUoBAG8oAAEAt/D/////oC2kByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgB AAALCAAAD4TQAhGEmP5PSgEAUUoBAG8oAAEALfD//////C2kByAAAAABAAAAF0AAAAAAAAAAAAAA AAAAAGgBAAALCAAAD4SgBRGEmP5PSgEAUUoBAG8oAAEAt/D/////WC6kByAAAAABAAAAF0AAAAAA AAAAAAAAAAAAAGgBAAALCAAAD4QIBxGEmP5PSgEAUUoBAG8oAAEAt/D/////tC6kByAAAAABAAAA F0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4RoARGEmP5PSgEAUUoBAG8oAAEAt/D/////EC+kByAA AAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4TQAhGEmP5PSgEAUUoBAG8oAAEALfD///// bC+kByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4SgBRGEmP5PSgEAUUoBAG8oAAEA t/D/////yC+kByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGEmP5PSgEAUUoB AG8oAAEAt/D/////JDCkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4RoARGEmP5P SgEAUUoBAG8oAAEAt/D/////gDCkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4TQ AhGEmP5PSgEAUUoBAG8oAAEALfD/////3DCkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAAL CAAAD4SgBRGEmP5PSgEAUUoBAG8oAAEAt/D/////ODGkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAA AGgBAAALCAAAD4QIBxGEmP5PSgEAUUoBAG8oAAEAt/D/////lDGkByAAAAABAAAAF0AAAAAAAAAA AAAAAAAAAGgBAAALCAAAD4RoARGEmP5PSgEAUUoBAG8oAAEAt/D/////8DGkByAAAAABAAAAF0AA AAAAAAAAAAAAAAAAAGgBAAALCAAAD4TQAhGEmP5PSgEAUUoBAG8oAAEALfD/////TDKkByAAAAAB AAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4SgBRGEmP5PSgEAUUoBAG8oAAEAt/D/////qDKk ByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGEmP5PSgEAUUoBAG8oAAEAt/D/ ////BDOkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4RoARGEmP5PSgEAUUoBAG8o AAEAt/D/////YDOkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4TQAhGEmP5PSgEA UUoBAG8oAAEALfD/////vDOkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4SgBRGE mP5PSgEAUUoBAG8oAAEAt/D/////GDSkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAA D4QIBxGEmP5PSgEAUUoBAG8oAAEAt/D/////dDSkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgB AAALCAAAD4RoARGEmP5PSgEAUUoBAG8oAAEAt/D/////0DSkByAAAAABAAAAF0AAAAAAAAAAAAAA AAAAAGgBAAALCAAAD4TQAhGEmP5PSgEAUUoBAG8oAAEALfD/////LDWkByAAAAABAAAAF0AAAAAA AAAAAAAAAAAAAGgBAAALCAAAD4SgBRGEmP5PSgEAUUoBAG8oAAEAt/D/////iDWkByAAAAABAAAA F0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGEmP5PSgEAUUoBAG8oAAEAt/D/////5DWkByAA AAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4RoARGEmP5PSgEAUUoBAG8oAAEAt/D///// QDakByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4TQAhGEmP5PSgEAUUoBAG8oAAEA LfD/////nDakByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4SgBRGEmP5PSgEAUUoB AG8oAAEAt/D/////+DakByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGEmP5P SgEAUUoBAG8oAAEAt/D/////VDekByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4Ro ARGEmP5PSgEAUUoBAG8oAAEAt/D/////sDekByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAAL CAAAD4TQAhGEmP5PSgEAUUoBAG8oAAEALfD/////DDikByAAAAABAAAAF0AAAAAAAAAAAAAAAAAA AGgBAAALCAAAD4SgBRGEmP5PSgEAUUoBAG8oAAEAt/D/////aDikByAAAAABAAAAF0AAAAAAAAAA AAAAAAAAAGgBAAALCAAAD4QIBxGEmP5PSgEAUUoBAG8oAAEAt/D/////xDikByAAAAABAAAAF0AA AAAAAAAAAAAAAAAAAGgBAAALCAAAD4RoARGEmP5PSgEAUUoBAG8oAAEAt/D/////IDmkByAAAAAB AAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4TQAhGEmP5PSgEAUUoBAG8oAAEALfD/////fDmk ByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4SgBRGEmP5PSgEAUUoBAG8oAAEAt/D/ ////2DmkByAAAAABAAAAF0AAAAAAAAAAAAAAAAAAAGgBAAALCAAAD4QIBxGEmP5PSgEAUUoBAG8o AAEAt/D//////////////////////////////////////////zQ6pAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////5A6pAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////+w6pAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////0g7 pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw /////6Q7pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBv KAABALfw/////wA8pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oB AFFKAQBvKAABAC3w/////1w8pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAUR hJj+T0oBAFFKAQBvKAABALfw/////7g8pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////xQ9pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////3A9pAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////8w9pAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////yg+pAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////4Q+pAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw//// /+A+pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAAB AC3w/////zw/pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFK AQBvKAABALfw/////5g/pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+ T0oBAFFKAQBvKAABALfw//////Q/pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E aAERhJj+T0oBAFFKAQBvKAABALfw/////1BApAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////6xApAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////whBpAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////2RBpAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////8BBpAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////xxC pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw /////3hCpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBv KAABALfw/////9RCpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oB AFFKAQBvKAABALfw/////zBDpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIR hJj+T0oBAFFKAQBvKAABAC3w/////4xDpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////+hDpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////0REpAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////6BEpAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w//////xEpAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////1hFpAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw//// /7RFpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAAB ALfw/////xBGpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFK AQBvKAABAC3w/////2xGpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+ T0oBAFFKAQBvKAABALfw/////8hGpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E CAcRhJj+T0oBAFFKAQBvKAABALfw/////yRHpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////4BHpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////9xHpAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////zhIpAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////5RIpAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw//////BI pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w /////0xJpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBv KAABALfw/////6hJpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oB AFFKAQBvKAABALfw/////wRKpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAER hJj+T0oBAFFKAQBvKAABALfw/////2BKpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////7xKpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////xhLpAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////3RLpAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////9BLpAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////yxMpAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw//// /4hMpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAAB ALfw/////+RMpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFK AQBvKAABALfw/////0BNpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+ T0oBAFFKAQBvKAABAC3w/////5xNpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E oAURhJj+T0oBAFFKAQBvKAABALfw//////hNpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////1ROpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////7BOpAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////wxPpAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////2hPpAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////8RP pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw /////yBQpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBv KAABAC3w/////3xQpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oB AFFKAQBvKAABALfw/////9hQpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcR hJj+T0oBAFFKAQBvKAABALfw/////zRRpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////5BRpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////+xRpAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////0hSpAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////6RSpAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////wBTpAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w//// /1xTpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAAB ALfw/////7hTpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFK AQBvKAABALfw/////xRUpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+ T0oBAFFKAQBvKAABALfw/////3BUpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E 0AIRhJj+T0oBAFFKAQBvKAABAC3w/////8xUpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////yhVpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////4RVpAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////+BVpAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////zxWpAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////5hW pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw //////RWpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBv KAABALfw/////1BXpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oB AFFKAQBvKAABAC3w/////6xXpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAUR hJj+T0oBAFFKAQBvKAABALfw/////whYpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////2RYpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////8BYpAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////xxZpAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////3hZpAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////9RZpAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw//// /zBapAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAAB AC3w/////4xapAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFK AQBvKAABALfw/////+hapAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+ T0oBAFFKAQBvKAABALfw/////0RbpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E aAERhJj+T0oBAFFKAQBvKAABALfw/////6BbpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w//////xbpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////1hcpAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////7RcpAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////xBdpAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////2xd pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw /////8hdpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBv KAABALfw/////yRepAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oB AFFKAQBvKAABAODw/////4BepAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQR hJj+T0oBAFFKAQBvKAABALfw/////9xepAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////zhfpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////5RfpAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw//////BfpAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////0xgpAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABAODw/////6hgpAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw//// /wRhpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAAB ALfw/////2BhpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFK AQBvKAABALfw/////7xhpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+ T0oBAFFKAQBvKAABALfw/////xhipAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E OAQRhJj+T0oBAFFKAQBvKAABALfw/////3RipAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABAODw/////9BipAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////yxjpAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////4hjpAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////+RjpAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////0Bk pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw /////5xkpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBv KAABAODw//////hkpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oB AFFKAQBvKAABALfw/////1RlpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQR hJj+T0oBAFFKAQBvKAABALfw/////7BlpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////wxmpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////2hmpAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////8RmpAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABAODw/////yBnpAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////3xnpAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw//// /9hnpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAAB ALfw/////zRopAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFK AQBvKAABALfw/////5BopAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+ T0oBAFFKAQBvKAABALfw/////+xopAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E CAcRhJj+T0oBAFFKAQBvKAABAODw/////0hppAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////6RppAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////wBqpAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////1xqpAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////7hqpAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////xRr pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABAODw /////3BrpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBv KAABALfw/////8xrpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oB AFFKAQBvKAABALfw/////yhspAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQR hJj+T0oBAFFKAQBvKAABALfw/////4RspAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////+BspAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////zxtpAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABAODw/////5htpAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw//////RtpAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////1BupAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw//// /6xupAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAAB ALfw/////whvpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFK AQBvKAABALfw/////2RvpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+ T0oBAFFKAQBvKAABAODw/////8BvpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E OAQRhJj+T0oBAFFKAQBvKAABALfw/////xxwpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////3hwpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////9RwpAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////zBxpAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////4xxpAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABAODw/////+hx pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw /////0RypAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBv KAABALfw/////6BypAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oB AFFKAQBvKAABALfw//////xypAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQR hJj+T0oBAFFKAQBvKAABALfw/////1hzpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////7RzpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABAODw/////xB0pAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////2x0pAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////8h0pAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////yR1pAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw//// /4B1pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAAB ALfw/////9x1pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFK AQBvKAABAODw/////zh2pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+ T0oBAFFKAQBvKAABALfw/////5R2pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E OAQRhJj+T0oBAFFKAQBvKAABALfw//////B2pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////0x3pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////6h3pAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////wR4pAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABAODw/////2B4pAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////7x4 pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw /////xh5pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBv KAABALfw/////3R5pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oB AFFKAQBvKAABALfw/////9B5pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQR hJj+T0oBAFFKAQBvKAABALfw/////yx6pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+ECAcRhJj+T0oBAFFKAQBvKAABAODw/////4h6pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////+R6pAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////0B7pAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////5x7pAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw//////h7pAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw//// /1R8pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAAB AODw/////7B8pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFK AQBvKAABALfw/////wx9pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+ T0oBAFFKAQBvKAABALfw/////2h9pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E OAQRhJj+T0oBAFFKAQBvKAABALfw/////8R9pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////yB+pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////3x+pAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABAODw/////9h+pAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+EOAQRhJj+T0oBAFFKAQBvKAABALfw/////zR/pAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAAAbAQAACwgAAA+ENwIRhOX+T0oBAFFKAQBvKAABALfw/////wIA AAAQAAAAAwAAABEAAAABAAAAEgAAAAUAAAATAAAA/////7R/pAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////xCApAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////2yApAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////8iApAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw//// /ySBpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAAB ALfw/////4CBpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFK AQBvKAABAC3w/////9yBpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+ T0oBAFFKAQBvKAABALfw/////ziCpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E CAcRhJj+T0oBAFFKAQBvKAABALfw/////5SCpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw//////CCpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////0yDpAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////6iDpAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////wSEpAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////2CE pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w /////7yEpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBv KAABALfw/////xiFpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oB AFFKAQBvKAABALfw/////3SFpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAER hJj+T0oBAFFKAQBvKAABALfw/////9CFpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////yyGpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////4iGpAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////+SGpAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////0CHpAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////5yHpAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw//// //iHpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAAB ALfw/////1SIpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFK AQBvKAABALfw/////7CIpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+ T0oBAFFKAQBvKAABAC3w/////wyJpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E oAURhJj+T0oBAFFKAQBvKAABALfw/////2iJpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////8SJpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////yCKpAcgAAAAAQAAABdAAAAAAAAA AAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////3yKpAcgAAAAAQAAABdA AAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////9iKpAcgAAAA AQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////zSL pAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw /////5CLpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBv KAABAC3w/////+yLpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oB AFFKAQBvKAABALfw/////0iMpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcR hJj+T0oBAFFKAQBvKAABALfw/////6SMpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgA AA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////wCNpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABo AQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w/////1yNpAcgAAAAAQAAABdAAAAAAAAAAAAA AAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////7iNpAcgAAAAAQAAABdAAAAA AAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw/////xSOpAcgAAAAAQAA ABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+T0oBAFFKAQBvKAABALfw/////3COpAcg AAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E0AIRhJj+T0oBAFFKAQBvKAABAC3w//// /8yOpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EoAURhJj+T0oBAFFKAQBvKAAB ALfw/////yiPpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+ECAcRhJj+T0oBAFFK AQBvKAABALfw/////4SPpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+EaAERhJj+ T0oBAFFKAQBvKAABALfw/////+CPpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAACwgAAA+E 0AIRhJj+T0oBAFFKAQBvKAABAC3w/////zyQpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAAAABoAQAA CwgAAA+EoAURhJj+T0oBAFFKAQBvKAABALfw/////5iQpAcgAAAAAQAAABdAAAAAAAAAAAAAAAAA AABoAQAACwgAAA+ECAcRhJj+T0oBAFFKAQBvKAABALfw//////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// //////////////////////////////////////////////////////////////////////////// /////////////////////////////////////////////////+ABAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/QFxcREMxXEhQIDgwMDAgLSBQQ0wATmUw MDoAd2luc3Bvb2wAXFxEQzFcSFAgODAwMCAtIFBDTABcXERDMVxIUCA4MDAwIC0gUENMAAAAAAAA AAAAAAAAAAEEEwCcALgDA78BAAEAAQAAAAAAAAABAAcAWAICAAEAWAIAAAEATGV0dGVyAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAACUBAAAVAAAAEgAUAAgAEwAYQBzAGUAcgBKAGUAdAAgADgAMAAwADAA IABTAGUAcgBpAGUAcwAgAFAAQwBMACAANQBlAAAAAAAAAAAABAAAADAAAADvAgAAXAMAAB0NxqOA UXC2MQUMxsMAUMRkNRtD4pChmCoHBYPCYWNhpD4iN4rFRzGBuNovCIUMhzFxyMovCpkCocXC7A5R G5WNRqCpfH5nCprN5PKY5LInL57QYpNpxRpWOYNL4nTKHT50CpZH5fIqZKaJOZVWhzIpfBq/B7DU LJCpfJaZCqdRazLBlPhnDrjaqxYxkOJ7Lb3V4JIrGMxvcIjaJHF77HBmOLvLZjI7vc7FkBxbhnQJ HhJPWcjLhnS8+ChEIptmLYMo9eKrp9YCrrGpbXpGMZLc9DfhtnMZM4dqdnvtJcNzu6JvaONsmNL1 p+JRBrhsgML1EeRM8ddMOMLcNLvVr53uvz8rwvLmYsMJcNM96tX1OtUaXruj3JN1dENJlAWuXtd2 PRZ8E+DRsXyWt/WBDRuIJXN/GHeJIHOblWkmexC4FDkNHbRRhIZZ1gQ1flI3zRl9YaTFrnpRSAl0 f1XA1eOFnFZANIji1QlqicN3MRZoQ5TyFnDaqCmHj5PkaUxlxdXJ1EGYeFUQYmFl5hhrQ2YFUpEe trYNT4OYeTONk7TF2IljuZVaiRD3YXtH5rRF43YjSCYDVoNFodiOlNkdRw1TJ2Hxiaf07UB2Gmnd 5krkkMXYgihZ4DIN57DCDofWqWF1lWjwwcGmZyDilpjn6kw4Xp4JpqajFaDZcHgXunpepyqUQl2c g3nQMZ9k+kw3oIMaEmShlaDhXngoqobFfCu6RQoLa+q1f6wDGmEKYZy0TWN8K2qCO3TQOP7GrupZ Fby21HDiiAyqu57aXV0JuDJg2okZA7HbRY6BUsMAynZFL4umO6PTCmWpkUMW6DGURdXO+b7DFVb+ sNJg4wNNLzaaRcJbq9I8UTEEcoGyGuhbAlZqmlMHCLHVKyCKLxYqqJWpth7/vOpUNiBbAzwaj5XU zO60zeiAzrLMGFaJf0gZvNaTDbEwzr3RHNshna4sVrp7aXWdVStDdNwCxLSRqUoruuFkKpN/NAs+ fpPk9AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA XFxEQzFcSFAgODAwMCAtIFBDTAAAAAAAAAAAAAAAAAABBBMAnAC4AwO/AQABAAEAAAAAAAAAAQAH AFgCAgABAFgCAAABAExldHRlcgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAlAQAAFQAAABIAFAAIABM AGEAcwBlAHIASgBlAHQAIAA4ADAAMAAwACAAUwBlAHIAaQBlAHMAIABQAEMATAAgADUAZQAAAAAA AAAAAAQAAAAwAAAA7wIAAFwDAAAdDcajgFFwtjEFDMbDAFDEZDUbQ+KQoZgqBwWDwmFjYaQ+IjeK xUcxgbjaLwiFDIcxccjKLwqZAqHFwuwOURuVjUagqXx+ZwqazeTymOSyJy+e0GKTacUaVjmDS+J0 yh0+dAqWR+XyKmSmiTmVVocyKXwavwew1CyQqXyWmQqnUWsywZT4Zw642qsWMZDiey291eCSKxjM b3CI2iRxe+xwZji7y2YyO73OxZAcW4Z0CR4ST1nIy4Z0vPgoRCKbZi2DKPXiq6fWAq6xqW16RjGS 3PQ34bZzGTOHanZ77SXDc7uib2jjbJjS9afiUQa4bIDC9RHkTPHXTDjC3DS71a+d7r8/K8Ly5mLD CXDTPerV9TrVGl67o9yTdXRDSZQFrl7Xdj0WfBPg0bF8lrf1gQ0biCVzfxh3iSBzm5VpJnsQuBQ5 DR20UYSGWdYENX5SN80ZfWGkxa56UUgJdH9VwNXjhZxWQDSI4tUJaonDdzEWaEOU8hZw2qgph4+T 5GlMZcXVydRBmHhVEGJhZeYYa0NmBVKRHra2DU+DmHkzjZO0xdiJY7mVWokQ92F7R+a0ReN2I0gm A1aDRaHYjpTZHUcNUydh8Ymn9O1Adhpp3eZK5JDF2IIoWeAyDeewwg6H1qlhdZVo8MHBpmcg4paY 5+pMOF6eCaamoxWg2XB4F7p6XqcqlEJdnIN50DGfZPpMN6CDGhJkoZWg4V54KKqGxXwrukUKC2vq tX+sAxphCmGctE1jfCtqgjt00Dj+xq7qWRW8ttRw4ogMqrue2l1dCbgyYNqJGQOx20WOgVLDAMp2 RS+Lpjuj0wplqZFDFugxlEXVzvm+wxVW/rDSYOMDTS82mkXCW6vSPFExBHKBshroWwJWappTBwix 1Ssgii8WKqiVqbYe/7zqVDYgWwM8Go+V1MzutM3ogM6yzBhWiX9IGbzWkw2xMM690RzbIZ2uLFa6 e2l1nVUrQ3TcAsS0kalKK7rhZCqTfzQLPn6T5PQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAOAAQDsGQAA7BkAAGhQBwUBAAAA7BkAAAAAAADsGQAA AAAAAAIQAAAAAAAAADJzAACwAAAIAEAAAAoAAABHFpABAAACAgYDBQQFAgMEhwIAAAAAAAAAAAAA AAAAAJ8AAAAAAAAAVABpAG0AZQBzACAATgBlAHcAIABSAG8AbQBhAG4AAAA1FpABAgAFBQECAQcG AgUHAAAAAAAAABAAAAAAAAAAAAAAAIAAAAAAUwB5AG0AYgBvAGwAAAAzJpABAAACCwYEAgICAgIE hwIAAAAAAAAAAAAAAAAAAJ8AAAAAAAAAQQByAGkAYQBsAAAANSaQAQAAAgsGBAMFBAQCBIcCAAAA AAAAAAAAAAAAAACfAAAAAAAAAFQAYQBoAG8AbQBhAAAAQSKQAQAAAAAAAAAAAAAAAAMAAAAAAAAA AAAAAAAAAAABAAAAAAAAAEcAaQBsAGwAIABTAGEAbgBzACAATQBUAAAAMxKQAQAAAgIGAwUEBQID BAMAAAAAAAAAAAAAAAAAAAABAAAAAAAAAFQAaQBtAGUAcwAAADsikAEAAAAAAAAAAAAAAAADAAAA AAAAAAAAAAAAAAAAAQAAAAAAAABIAGUAbAB2AGUAdABpAGMAYQAAAFMWkAEADQIEBgIFAwUDAwQD AAAAAAAAAAAAAAAAAAAAAQAAAAAAAABCAG8AbwBrACAAQQBuAHQAaQBxAHUAYQAAAFAAYQBsAGEA dABpAG4AbwAAADsGkAECAAUAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABXAGkAbgBn AGQAaQBuAGcAcwAAADcG9AECAAAAAAAAAAAAAAAAAAAAAAAAEAAAAAAAAAAAAAAAgAAAAABNAGEA cgBsAGUAdAB0AAAAIgAEAAEAiBgAANACAABoAQAAAADcETtG3BE7RvoyOSYCAAAAAAAxEAAATFwA AAEALwAAAAQAAxDEAAAAAAAAAAAAAAABAAEAAAABAAAAAAAAACEDAAAAgAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASMAAAAAAAAAAAAAAAAAAAWHEAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAAAAAD/ /xIAAAAAAAAACABwAHIAbwBwAG8AcwBhAGwAAAAAAAAADQBNAGEAaABlAHMAaAAgAGIAYQBsAHUA bgBpAA4ARwBhAHIAeQAgAEcAcgBlAGUAbgBiAGUAcgBnAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAQwBvAG0AcABPAGIAagAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAASAAIA////////////////AAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGoAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD///////////// //8AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAP///////////////wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA////////////////AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAQD+/wMKAAD/////BgkCAAAAAADAAAAAAAAARhgAAABNaWNy b3NvZnQgV29yZCBEb2N1bWVudAAKAAAATVNXb3JkRG9jABAAAABXb3JkLkRvY3VtZW50LjgA9Dmy cQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAA= ------_=_NextPart_000_01C02ED7.DB10C6D0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 13:31:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03638 for ; Thu, 5 Oct 2000 13:31:06 -0400 (EDT) Received: from standards (47.234.32.16:4336) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DB03@standards.nortelnetworks.com>; Thu, 5 Oct 2000 13:12:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25576 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 13:12:44 -0400 Received: from zrtps06u.us.nortel.com (47.140.48.52:33037) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9DB02@standards.nortelnetworks.com>; Thu, 5 Oct 2000 13:12:44 -0400 Received: from qhars002.nortel.com (zhars00t.europe.nortel.com [47.101.112.102]) by zrtps06u.us.nortel.com (8.11.0/8.11.0) with ESMTP id e95HRFf02047 for ; Thu, 5 Oct 2000 13:27:15 -0400 (EDT) Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 5 Oct 2000 18:27:01 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 5 Oct 2000 12:23:40 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 5 Oct 2000 12:23:31 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C02EF0.F510EDD0" Message-ID: <353093573B82D411889E0000F808216648E3C4@zcard00q.ca.nortel.com> Date: Thu, 5 Oct 2000 12:23:20 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt X-To: Bob Lukas To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C02EF0.F510EDD0 Content-Type: text/plain; charset="iso-8859-1" Bob: I believe your comments below do not actually affect the Megaco IP Phone draft itself. However, I agree with some of the issues you raise. Since the Megaco IP Phone draft is currently in last call, its important to identify where the issues reside. See [pb] comments below. -- Peter Blatherwick -----Original Message----- From: Bob Lukas [mailto:blukas@BROADCOM.COM] Sent: Thursday, October 05, 2000 01:10 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Issues with draft-ietf-megaco-ipphone-03.txt We've been looking at implementing draft-ietf-megaco-ipphone-03.txt and a few thorny issues have come up that I haven't seen discussed. Keypad and hookswitch are extensions of the basic annex G key package in the UI termination - this means: [pb] A quick clarification: all the UI packages used by IP Phone are Annex G packages, no extensions to Annex G are proposed. Your statement above is correct, but wanted to make sure all understood it. 1. There is no "current state" property value of these switches, only keyup and keydown events that are generated. e.g. the event reported is key/ku{keyid=kh} for an off-hook event. Not normally an issue for momentary push-buttons, but it means an MGC cannot audit for whether the phone is currently off-hook. Kind of a problem for an MGC that is trying to recover state at startup... [pb} True, there is no current state property. I like the general approach you suggest below to time 0 state problem. I personally think the MGC side of things must be responsible for recovering state if their is a failure cut-over (not sure if that's the scenario you are concerned about) since there's a heck of a lot more than hookswitch state involved in call state. At device startup, the worst that can happen is the user will get bored and hang up, generating the event anyway. [pb] Since this is a limitation of what is specified in Annex G, this does not directly affect the Megaco IP Phone draft. I don't think this is serious though. 2. At times, I'm only interested in events from a subset of the possible keys. How can I set an event descriptor to only monitor hookswitch (for example), and not random other button presses? Is this syntax legal? ...modify = ui { events =1 { key/ku { keyid = kh }, key/kd { keyid = f001} } If it was, it would help overcome the audit issue, by getting an immediate event if currently off-hook. [pb] I like it, even though I personally favour the all events on all the time approach. But I am personally unclear if this syntax is valid or not (its been a while). Unless someone on the list can clarify, I'll look into it. Even if suggested syntax is not valid, immediate Events could be returned indicating key states at the time the EventsDescriptor is received at the MG. [pb] This is an issue related to Megaco/H.248 Protocol overall, not specifically Megaco IP Phone. Useful for Implementer's Guide? 3. The audio transducers are separate terminations from the UI. This has great impact on wanting to automatically stop call progress tones immediately when keys are pressed. As far as I understand, an event occurring in one termination must not affect the signals active in another termination (which would be a huge problem for a multiple line device for example). For example, I cannot have dialtone automatically stop when I press a key - the MGC must send down a signal to explicitly stop it. Even worse, if I choose to implement a digitmap on my keypad, the MGC has no way of knowing when to stop dialtone, because it gets no event until after the entire dial string is entered. Saying the IP Phone should know and understand the implicit interactions between the terminations is also problematic and against the general Megaco philosophy of centralized control. [pb] The issue of Termination organization has been picked apart at length several times before, resulting in the current organization. While I certainly understand there is a tradeoff around causing reflex actions to occur as a result of Events, grouping of all termination functionality into a single termination (the implied solution) would result in drastically reduced flexibility for the model overall, and make several powerful applications non-intuitive at best. For example, applications like group listening (talker on a handset while others listen on handsfree) require individual control over the audio input/outputs, hence separate Transducer Terminations to allow them to be freely manipulated. Paging while on a call, IP-radio and several other applications would also be awkward without separate terminations. Since the MGC can control everything, albeit with some extra load, the flexible model is favoured, with the intent to open up new applications well beyond what "phones" can do today. [pb] I strongly agree with you statement that MGs should have no knowledge of call-related interactions (or any other application-level knowledge for that matter), and it would indeed break the Megaco/H.248 master/slave model. I think we all agree we don't go there. [pb] Since this topic has been visited several times, and good agreement achieved that this flexibility is important, I would not favour opening the issues again. I believe the general issue of inter-termination interaction may be a useful area for work in future versions of Megaco/H.248, as I can see several other example where it might be helpful. -- PB _____________________________________________________ Bob Lukas Broadcom Canada Richmond B.C. blukas@broadcom.com 604-233-8665 ------_=_NextPart_001_01C02EF0.F510EDD0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Issues with draft-ietf-megaco-ipphone-03.txt

Bob: 

I believe your comments below do not actually affect = the Megaco IP Phone draft itself.  However, I agree with some of = the issues you raise.  Since the Megaco IP Phone draft is = currently in last call, its important to identify where the issues = reside.  See [pb] comments below. 

-- Peter Blatherwick

-----Original Message-----
From: Bob Lukas [mailto:blukas@BROADCOM.COM]
Sent: Thursday, October 05, 2000 01:10
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Issues with = draft-ietf-megaco-ipphone-03.txt




We've been looking at implementing = draft-ietf-megaco-ipphone-03.txt and a few thorny issues have come up = that I haven't seen discussed. Keypad and hookswitch are extensions of = the basic annex G key package in the UI termination - this = means:

[pb] A quick clarification: all the UI packages used = by IP Phone are Annex G packages, no extensions to Annex G are = proposed.  Your statement above is correct, but wanted to make = sure all understood it. 

1. There is no "current state" property = value of these switches, only keyup and keydown events that are = generated. e.g. the event reported is key/ku{keyid=3Dkh} for an = off-hook event. Not normally an issue for momentary push-buttons, but = it means an MGC cannot audit for whether the phone is currently = off-hook. Kind of a problem for an MGC that is trying to recover state = at startup...

[pb} True, there is no current state property.  = I like the general approach you suggest below to time 0 state = problem.  I personally think the MGC side of things must be = responsible for recovering state if their is a failure cut-over (not = sure if that's the scenario you are concerned about) since there's a = heck of a lot more than hookswitch state involved in call state.  = At device startup, the worst that can happen is the user will get bored = and hang up, generating the event anyway. 

[pb] Since this is a limitation of what is specified = in Annex G, this does not directly affect the Megaco IP Phone = draft.  I don't think this is serious though. 

2. At times, I'm only interested in events from a = subset of the possible keys. How can I set an event descriptor to only = monitor hookswitch (for example), and not random other button = presses?

Is this syntax legal? ...modify =3D ui { events =3D1 = { key/ku { keyid =3D kh }, key/kd { keyid =3D f001} }
If it was, it would help overcome the audit issue, = by getting an immediate event if currently off-hook.

[pb] I like it, even though I personally favour the = all events on all the time approach.  But I am personally unclear = if this syntax is valid or not (its been a while).  Unless someone = on the list can clarify, I'll look into it.  Even if suggested = syntax is not valid, immediate Events could be returned indicating key = states at the time the EventsDescriptor is received at the MG.  =

[pb] This is an issue related to Megaco/H.248 = Protocol overall, not specifically Megaco IP Phone.  Useful for = Implementer's Guide? 

3. The audio transducers are separate terminations = from the UI. This has great impact on wanting to automatically stop = call progress tones immediately when keys are pressed. As far as I = understand, an event occurring in one termination must not affect the = signals active in another termination (which would be a huge problem = for a multiple line device for example). For example, I cannot have = dialtone automatically stop when I press a key - the MGC must send down = a signal to explicitly stop it. Even worse, if I choose to implement a = digitmap on my keypad, the MGC has no way of knowing when to stop = dialtone, because it gets no event until after the entire dial string = is entered. Saying the IP Phone should know and understand the implicit = interactions between the terminations is also problematic and against = the general Megaco philosophy of centralized control.

[pb] The issue of Termination organization has been = picked apart at length several times before, resulting in the current = organization. While I certainly understand there is a tradeoff around = causing reflex actions to occur as a result of Events, grouping of all = termination functionality into a single termination (the implied = solution) would result in drastically reduced flexibility for the model = overall, and make several powerful applications non-intuitive at = best.  For example, applications like group listening (talker on a = handset while others listen on handsfree) require individual control = over the audio input/outputs, hence separate Transducer Terminations to = allow them to be freely manipulated.  Paging while on a call, = IP-radio and several other applications would also be awkward without = separate terminations.  Since the MGC can control everything, = albeit with some extra load, the flexible model is favoured, with the = intent to open up new applications well beyond what "phones" = can do today. 

[pb] I strongly agree with you statement that MGs = should have no knowledge of call-related interactions (or any other = application-level knowledge for that matter), and it would indeed break = the Megaco/H.248 master/slave model.  I think we all agree we = don't go there. 

[pb] Since this topic has been visited several times, = and good agreement achieved that this flexibility is important, I would = not favour opening the issues again.  I believe the general issue = of inter-termination interaction may be a useful area for work in = future versions of Megaco/H.248, as I can see several other example = where it might be helpful. 

-- PB
_____________________________________________________
Bob Lukas
Broadcom Canada
Richmond B.C.
blukas@broadcom.com
604-233-8665

------_=_NextPart_001_01C02EF0.F510EDD0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 5 19:35:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA08861 for ; Thu, 5 Oct 2000 19:35:42 -0400 (EDT) Received: from standards (47.234.32.16:2093) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E220@standards.nortelnetworks.com>; Thu, 5 Oct 2000 19:16:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27963 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 5 Oct 2000 19:16:07 -0400 Received: from turin.trillium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E21F@standards.nortelnetworks.com>; Thu, 5 Oct 2000 19:16:07 -0400 Received: from aiglos.trillium.com (smtp.trillium.com [192.168.3.20]) by turin.trillium.com (8.11.0/8.11.0) with ESMTP id e95NZK127006 for ; Thu, 5 Oct 2000 16:35:20 -0700 (PDT) Received: from aega.trillium.com ([10.242.100.206]) by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id QAA03174 for ; Thu, 5 Oct 2000 16:30:18 -0700 (PDT) Received: by AEGA with Internet Mail Service (5.5.2650.21) id <4C335AVW>; Thu, 5 Oct 2000 16:20:32 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <8BBD33A986C5D311804000902719FF5D31BBCE@AEGA> Date: Thu, 5 Oct 2000 16:20:24 -0700 Reply-To: Yuyong Zhang Sender: "Media Gateway Control (megaco)" From: Yuyong Zhang Subject: FW: Inconsistent between ABNF and text about audit reply paramete r. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi All, I sent this mail before, there is no response so far. Would somebody please give your take on this? Regards, Yuyong Subject: Inconsistent between ABNF and text about audit reply parameter. Hi All, There is inconsistency between ABNF and the text desciption about audit reply value. 1. In the ABNF, there is contextTerminationAudit to return just a list of termination IDs for a context, but it is not clear "contextTerminationAudit" is a reply to which combination of ContxtId and TerminationID in the table of section 7.2.5. 2. In the last entry of the table in section 7.2.5 indicates that audit reply shall return a list of contextIds for audit request with ContxtId=ALL and TerminationId=Root. However there is not such contextId list in the auditReply defines in ABNF. Would you please clarify this, which one shall I follow, the ABNF or the text? Regards, Yuyong From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 06:42:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA27860 for ; Fri, 6 Oct 2000 06:42:42 -0400 (EDT) Received: from standards (47.234.32.16:3144) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E6B0@standards.nortelnetworks.com>; Fri, 6 Oct 2000 6:26:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29395 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 06:26:16 -0400 Received: from ietf.org (odin.ietf.org) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9E63E@standards.nortelnetworks.com>; Fri, 6 Oct 2000 6:16:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27425; Fri, 6 Oct 2000 06:30:47 -0400 (EDT) Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" Message-ID: <200010061030.GAA27425@ietf.org> Date: Fri, 6 Oct 2000 06:30:46 -0400 Reply-To: Internet-Drafts@ietf.org Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-rosen-megaco-interop-1-report-00.txt To: MEGACO@STANDARDS.NORTELNETWORKS.COM --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Report of the First Megaco/H.248 Interop Event Author(s) : B. Rosen Filename : draft-rosen-megaco-interop-1-report-00.txt Pages : 8 Date : 05-Oct-00 An interoperability test of the Megaco (RFC2885/6) protocol was held on August 28-31 in Durham, NH. An excellent turnout of many different independently developed implementations were present, and a great many of the tests were quite successful, including media flow in many cases, and several cases of testing a Media Gateway controller from one organization with two Media Gateways from different organizations. The primary purpose of the event was to assess the ability of independent development teams to create interoperable devices from the recent Proposed Standard RFCs 2885 [1] and 2886 [2]. While several discrepancies were found that resulted from differing interpretations of the documents, the level of compatibility exhibited at this first test was excellent. A secondary purpose of the event was to begin the process of moving the RFCs to draft standard status, which requires documentation of at least two implementations of each protocol element/feature. While this first event only used a subset of the protocol, quite a few of the elements and features were demonstrated by all implementations. This I-D describes the event and summarized the results. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-rosen-megaco-interop-1-report-00.txt Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-rosen-megaco-interop-1-report-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-rosen-megaco-interop-1-report-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20001005145848.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-rosen-megaco-interop-1-report-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-rosen-megaco-interop-1-report-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20001005145848.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 6 17:24:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA13207 for ; Fri, 6 Oct 2000 17:24:41 -0400 (EDT) Received: from standards (47.234.32.16:1487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F1BB@standards.nortelnetworks.com>; Fri, 6 Oct 2000 17:08:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33179 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 6 Oct 2000 17:08:34 -0400 Received: from sj-msg-core-2.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F1BA@standards.nortelnetworks.com>; Fri, 6 Oct 2000 17:08:33 -0400 Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-2.cisco.com (8.9.3/8.9.1) with ESMTP id OAA08003; Fri, 6 Oct 2000 14:23:10 -0700 (PDT) Received: from cisco.com (dhcp-128-107-133-58.cisco.com [128.107.133.58]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AFU06796 (AUTH pmelanah); Fri, 6 Oct 2000 14:23:07 -0700 (PDT) X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39DE4269.E4D13488@cisco.com> Date: Fri, 6 Oct 2000 14:21:45 -0700 Reply-To: Paddu Melanahalli Sender: "Media Gateway Control (megaco)" From: Paddu Melanahalli Organization: NSSU (Cisco's call agent "VSC" development Team), Cisco Systems, Inc Subject: MG implementation To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, Is there any MGs already implemented and interop-ed Megaco. If so can you pls point me towards more info. Thanks in advance, Paddu -- Enthusiasm You can do anything... if you have Enthusiasm. Enthusiasm is the yeast makes your hopes rise to the stars. Enthusiasm is the sparkle in your eyes. Enthusiasm with it there is accomplishment, without it there are only alibis --- Henry Ford's motto ________________________________________________________ Paddu Melanahalli, Cisco Systems, NSSU Voice:(408)525 5236 Fax: (408)527 1568 Pgr:(408)788 8275 Email: pmelanah@cisco.com ________________________________________________________ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Oct 7 01:31:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA23869 for ; Sat, 7 Oct 2000 01:30:59 -0400 (EDT) Received: from standards (47.234.32.16:3840) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F500@standards.nortelnetworks.com>; Sat, 7 Oct 2000 1:14:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34303 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 7 Oct 2000 01:14:51 -0400 Received: from nwcst313.netaddress.usa.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F4FF@standards.nortelnetworks.com>; Sat, 7 Oct 2000 1:14:51 -0400 Received: (qmail 20130 invoked by uid 60001); 7 Oct 2000 05:29:25 -0000 Received: from 204.68.23.58 by nwcst313 for [208.220.245.72] via web-mailer(34FM.0700.4.03) on Sat Oct 7 05:29:25 GMT 2000 X-Mailer: USANET web-mailer (34FM.0700.4.03) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Message-ID: <20001007052925.20129.qmail@nwcst313.netaddress.usa.net> Date: Fri, 6 Oct 2000 23:29:25 MDT Reply-To: sadiq rehman Sender: "Media Gateway Control (megaco)" From: sadiq rehman Subject: modification in ASN structure for ABNF X-To: Yuyong Zhang To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id BAA23869 Hai all, we are working in h248 protocol implementation. I have the following quaries. 1.We instead of using the data structure produced by the ASN1C compiler we are using our own data structure , which is optimised from the ASN1C compiler generated header file .for ABNF ie text encoding and decoding. we are following the asn syntax to decode and encode from our user data structure . can it be effected while decoding by the other MGC/GC 2. CAN IT BE POSSIBLE TO CHANGE THE ANS SYNTAX ITSELF AND GET THE CORRESPONDING C AND HEADER FILE FOR ENCODING AND DECODING FOR BER CAN WE DO THIS , IF IT IS EFFECTING WHILE DECODING, SO HOW IT WILL BE EFFECTED FOR BER . AS U KNOW THIS WILL BE IN THE FORMAT TLV T-TYPE, L-LENGTH, V-VALUE PLEASE GIVE YOUR SUGGESTION ON MY QUARIES . ADVANCED THANKS SADIQ REHMAN ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Oct 7 03:07:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA03294 for ; Sat, 7 Oct 2000 03:07:03 -0400 (EDT) Received: from standards (47.234.32.16:1733) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F585@standards.nortelnetworks.com>; Sat, 7 Oct 2000 2:50:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34494 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 7 Oct 2000 02:50:59 -0400 Received: from qhars002.nortel.com (47.101.112.102:52960) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F584@standards.nortelnetworks.com>; Sat, 7 Oct 2000 2:50:58 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Sat, 7 Oct 2000 08:04:49 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Sat, 7 Oct 2000 03:04:36 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Sat, 7 Oct 2000 03:04:36 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD110250C588@zcard00g.ca.nortel.com> Date: Sat, 7 Oct 2000 03:04:31 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Megaco &Mgcp X-To: "Greenberg, Gary" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I wish you had sent this straight to the person requesting the information. Think about us poor souls on dial-up connections paying a fortune to receive it, not to mention the list server. Tom Taylor > -----Original Message----- > From: Greenberg, Gary [mailto:GGreenberg@UNISPHERENETWORKS.COM] > Sent: Thursday, October 05, 2000 10:24 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Megaco &Mgcp > > > > > -----Original Message----- > From: Saayman Ahmed [mailto:Saayman.Ahmed@ONE2ONE.CO.UK] > Sent: Thursday, October 05, 2000 10:02 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Megaco &Mgcp > > > Hello there, > Can you please direct me to where I find information about > the difference > between MEGACO & MGCP. "Why is the Megaco preferred choice > for the UMTS > release 2000 architecture?" > > Thanks > Saayman > > Saayman Ahmed > one2one > Technology Strategy > 020 8214 5273 > > > > > NOTICE AND DISCLAIMER: > This email (including attachments) is confidential. If you > have received > this email in error please notify the sender immediately and > delete this > email from your system without copying or disseminating it or > placing any > reliance upon its contents. We cannot accept liability for > any breaches of > confidence arising through use of email. Any opinions > expressed in this > email (including attachments) are those of the author and do > not necessarily > reflect our opinions. We will not accept responsibility for > any commitments > made by our employees outside the scope of our business. We > do not warrant > the accuracy or completeness of such information. > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Oct 7 09:50:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05261 for ; Sat, 7 Oct 2000 09:50:47 -0400 (EDT) Received: from standards (47.234.32.16:1857) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F62B@standards.nortelnetworks.com>; Sat, 7 Oct 2000 9:34:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34713 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 7 Oct 2000 09:34:30 -0400 Received: from email2.chelmsford.castlenetworks.com (mailhost2.castlenetworks.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F62A@standards.nortelnetworks.com>; Sat, 7 Oct 2000 9:24:28 -0400 Received: by email2.chelmsford.castlenetworks.com with Internet Mail Service (5.5.2650.21) id ; Sat, 7 Oct 2000 09:43:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <9DCB6C9DC7C3D311B835009027DE069F012BE261@email2.chelmsford.castlenetworks.com> Date: Sat, 7 Oct 2000 09:43:16 -0400 Reply-To: "Greenberg, Gary" Sender: "Media Gateway Control (megaco)" From: "Greenberg, Gary" Subject: Re: Megaco &Mgcp X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM tom and list members, please accept my sincere apologies. my mistake, while trying to be helpful. best regards, gary -----Original Message----- From: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Sent: 10/7/00 3:04 AM Subject: Re: Megaco &Mgcp I wish you had sent this straight to the person requesting the information. Think about us poor souls on dial-up connections paying a fortune to receive it, not to mention the list server. Tom Taylor > -----Original Message----- > From: Greenberg, Gary [mailto:GGreenberg@UNISPHERENETWORKS.COM] > Sent: Thursday, October 05, 2000 10:24 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Megaco &Mgcp > > > > > -----Original Message----- > From: Saayman Ahmed [mailto:Saayman.Ahmed@ONE2ONE.CO.UK] > Sent: Thursday, October 05, 2000 10:02 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Megaco &Mgcp > > > Hello there, > Can you please direct me to where I find information about > the difference > between MEGACO & MGCP. "Why is the Megaco preferred choice > for the UMTS > release 2000 architecture?" > > Thanks > Saayman > > Saayman Ahmed > one2one > Technology Strategy > 020 8214 5273 > > > > > NOTICE AND DISCLAIMER: > This email (including attachments) is confidential. If you > have received > this email in error please notify the sender immediately and > delete this > email from your system without copying or disseminating it or > placing any > reliance upon its contents. We cannot accept liability for > any breaches of > confidence arising through use of email. Any opinions > expressed in this > email (including attachments) are those of the author and do > not necessarily > reflect our opinions. We will not accept responsibility for > any commitments > made by our employees outside the scope of our business. We > do not warrant > the accuracy or completeness of such information. > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Oct 7 20:24:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA08559 for ; Sat, 7 Oct 2000 20:24:11 -0400 (EDT) Received: from standards (47.234.32.16:3872) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F782@standards.nortelnetworks.com>; Sat, 7 Oct 2000 20:07:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 35183 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 7 Oct 2000 20:07:55 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9F781@standards.nortelnetworks.com>; Sat, 7 Oct 2000 20:07:54 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA01150; Sat, 7 Oct 2000 20:22:28 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id UAA19985; Sat, 7 Oct 2000 20:22:33 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4LSZD8RY>; Sat, 7 Oct 2000 20:22:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E78C@whq-msgusr-02.pit.comms.marconi.com> Date: Sat, 7 Oct 2000 20:22:28 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: modification in ASN structure for ABNF X-To: sadiq rehman To: MEGACO@STANDARDS.NORTELNETWORKS.COM You may have to be more clear in explaining your question, as I'm not sure I understand what you are trying to do. One of the confusions is: >we are using our own data structure , which is optimised from the ASN1C >compiler generated header file .for ABNF ie text encoding and decoding. In general, the ABNF syntax for text encoding is not the same as the ASN.1 syntax for binary encoding, so you could not use the output from an ASN.1 compiler on the ASN.1 syntax in Annex A to create a text encoder/decoder. There are several groups who are using the output of the ASN.1 compiler to produce a BER encoder/decoder for the binary encoding. I would say that we would not recommend changing the ASN.1 syntax as documented in Annex A to create a BER encoded binary. I do not think it is possible to write an ASN.1 description of the text encoding format represented by the Annex B ABNF. Is that an answer to your question, or have I misunderstood? Brian Brian -----Original Message----- From: sadiq rehman To: MEGACO@STANDARDS.NORTELNETWORKS.COM Sent: 10/7/00 1:29 AM Subject: modification in ASN structure for ABNF all, we are working in h248 protocol implementation. I have the following quaries. 1.We instead of using the data structure produced by the ASN1C compiler we are using our own data structure , which is optimised from the ASN1C compiler generated header file .for ABNF ie text encoding and decoding. we are following the asn syntax to decode and encode from our user data structure . can it be effected while decoding by the other MGC/GC 2. CAN IT BE POSSIBLE TO CHANGE THE ANS SYNTAX ITSELF AND GET THE CORRESPONDING C AND HEADER FILE FOR ENCODING AND DECODING FOR BER CAN WE DO THIS , IF IT IS EFFECTING WHILE DECODING, SO HOW IT WILL BE EFFECTED FOR BER . AS U KNOW THIS WILL BE IN THE FORMAT TLV T-TYPE, L-LENGTH, V-VALUE PLEASE GIVE YOUR SUGGESTION ON MY QUARIES . ADVANCED THANKS SADIQ REHMAN ____________________________________________________________________ Get free email and a permanent address at http://www.netaddress.com/?N=1 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Oct 8 15:40:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA10957 for ; Sun, 8 Oct 2000 15:40:41 -0400 (EDT) Received: from standards (47.234.32.16:1107) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FAD0@standards.nortelnetworks.com>; 8 Oct 2000 15:24:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36330 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 8 Oct 2000 15:24:20 -0400 Received: from mail0.mia.bellsouth.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FAC3@standards.nortelnetworks.com>; 8 Oct 2000 15:14:19 -0400 Received: from www.goldendeckcasino.com (adsl-61-143-206.mia.bellsouth.net [208.61.143.206]) by mail0.mia.bellsouth.net (3.3.5alt/0.75.2) with SMTP id PAA13099; Sun, 8 Oct 2000 15:28:20 -0400 (EDT) X-Sender: bubblehead32@hotmail.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-Type: text/plain; charset="us-ascii" X-Priority: 3 X-MSMail-Priority: Normal Message-ID: <200010081928.PAA13099@mail0.mia.bellsouth.net> Date: Sun, 8 Oct 2000 15:19:08 -0400 Reply-To: bubblehead32@HOTMAIL.COM Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. From: bubblehead32@HOTMAIL.COM Subject: WOW!!! Highest Payouts Around!!!!!!!! To: MEGACO@STANDARDS.NORTELNETWORKS.COM Its just like being there. Go to www.goldendeckcasino.com/goldendeckcasino/links/2769.html. If you would like to be removed from these mailings in the future please mailto:bubblehead32@hotmail.com?subject=remove From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Oct 8 18:09:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11643 for ; Sun, 8 Oct 2000 18:09:19 -0400 (EDT) Received: from standards (47.234.32.16:3343) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FB0C@standards.nortelnetworks.com>; 8 Oct 2000 17:53:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36430 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 8 Oct 2000 17:53:02 -0400 Received: from nt.weis-cons.com (195.76.202.140:1079) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FB0A@standards.nortelnetworks.com>; 8 Oct 2000 17:43:01 -0400 Received: from pavilion ([206.214.131.49]) by nt.weis-cons.com (Netscape Mail Server v2.02) with SMTP id AJE195; Sun, 8 Oct 2000 23:45:54 +0200 Message-ID: Date: Sun, 8 Oct 2000 17:53:02 -0400 Reply-To: rsb@DOCSJ.DE Sender: "Media Gateway Control (megaco)" From: rsb@DOCSJ.DE Subject: At last, HERBAL V the all natural alternative! To: MEGACO@STANDARDS.NORTELNETWORKS.COM Herbal V: An Incredible All-Natural Healthy Alternative Herbal V is the All Natural Approach to Male Virility, Vitality and Pleasure. Available N o w ! Welcome to the New Sexual Revolution. It's the all natural male potency and pleasure pill that men everywhere are buzzing about. Herbal V is safe, natural and specifically formulated to help support male sexual function and pleasure. You just take two easy-to-swallow tablets one hour before sex. And there's more great news - you can get Herbal V for less than $1 a pill. Amazing word of mouth praise on Herbal V has been spreading like wildfire-already over 1,500,000 men have chosen Herbal V. Since it is 100% natural you will never have to worry about safety. Try doctor-recommended Herbal V today and have the greatest night of your life! Herbal V... Bringing Back the Magic! 1,585,000 men can't be wrong. To date over 1 million men have tried the super supplement Herbal V. Here is why: No Doctor Visit Required Available Over the Counter Not a Drug 100% Natural Safe, No Worries Highest Quality Pharmaceutical-Grade Pure Nutriceuticals Guaranteed Potency & Purity Be a Real Man Again! Questions and Answers What is Herbal V? Herbal V is a proprietary blend that was specifically developed as a safe alternative for men who prefer an all-natural approach to address impotence and boost sexual performance. This amazing formula first became popular with Hollywood insiders and the wealthy elite. They were maximizing their sex lives, long before it was available to the general public. How does Herbal V work? Developed by a team whose goal was to create the perfect all-natural aphrodisiac. Herbal V is the result of that remarkable effort. The Herbal V formula contains a precise blend of cutting edge pro-sexual nutrients from around the world that provide nutritional support, making it possible for a man to have a pleasurable sexual experience. What can Herbal V do for me? Herbal V helps support male sexual function and pleasure in a safe and natural manner. Simply put, it can make your sex life incredible. Is Herbal V Safe? One of the great things about Herbal V is that it is not a drug. It is an incredible herbal dietary supplement that provides nutritional support for male sexual function and pleasure. One of the most comforting features of Herbal V is that you never have to worry about safety. Herbal V: Safe - Natural - Exciting Many have speculated that because Herbal V is so popular with men, it must contain prescription drugs or chemical components. Herbal V does not contain any elements or traces of any prescription drug. Herbal V is made using the world's most technologically advanced state-of-the-art cold processing equipment to ensure maximum purity. Herbal V has been independently analyzed by the nation's premier testing facility to ensure purity, quality and to end the rumors that, because it is so popular, it must somehow be chemical. It is not. Herbal V is natural - just as it says on the label. Herbal V is simply fantastic! Herbal V: Ingredients Yohimbe, saw palmetto, avena sativa, androstenedione, guarana, taurine, siberian ginseng, tribulus terrestris. Tribulus Terrestis is certified to enhanced testosterone levels by increasing Luteinzing hormone (LH) levels. Androstenedione which is a precursor to testosterone unlocks bound testosterone and makes it biologically active again quickly. This means a dramatic surge in desire. Avena Sativa Stimulates the neurotransmitter pleasure centers to maximum capacity. This greatly intensifies pleasure. Just listen to what Herbal V has done for the sex lives of people like you! “On a scale of 1 to 10, it's a 15. Electrifying. It's like a wonder pill!” — Justin Q B., New Haven, Texas “I haven't had sexual relations in 11 years. Then with Herbal V it was... wow! It works again!” — Sid R., Lakeland, Florida “I had sex four times in one night. It made me feel like a 19-year-old again.” — Chip S, Beech Mountain, North Carolina “Herbal V has turned my husband into a Sexual Superman! I like the fact that it's all natural and has no side effects. It's bringing back the good old days.” — Jennifer B, Beverly Hills, California The above testimonials are from product literature, and we have not independently verified them. However, the following testimonial is from a "senior" gentleman who has purchased his second bottle of Herbal V. When we heard his words with our own ears, we asked his permission to print them here. “Man! I'm wild as I can be! I feel like I'm 25 years old again! I'm not believing this!” — Mr. Murphy, age 64, Lampart, IL. Risk Free: Double Your Money Back Guarantee If Herbal V does not give the desired results as stated above, simply return the unused portion for a double-your money back refund. No questions asked ! Order Now: Safe, Fast, Secure, Private Herbal V with its DOUBLE YOUR MONEY BACK GUARANTEE is available only through this special promotional offer. Herbal V arrives in plain packaging for your privacy. Any and all information is kept strictly confidential. Payment Methods You may FAX or Postal Mail Checks, MasterCard, Visa, & American Express.payments. Money Orders are accepted only by Postal Mail. Each bottle of Herbal V contains 30 tablets, approximately a 1 month supply. Step 1: Place a check by your desired quanity. ______ 1 Bottle of Herbal V $24 ______ 2 Bottles of Herbal V $44 ______ 3 Bottles of Herbal V $59 Please add $6 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$30, 2 bottles=$50, 3 bottles=$65 ] International Orders Please add $16 shipping and handling for any size order. [ Total cost including shipping & handling, 1 bottle=$40, 2 bottles=$60, 3 bottles=$75 ] Step 2: Place a check by your desired payment method and complete fields if necessary. _____Check or CHECK-BY-FAX [details below] _____Money Order _____American Express Account Number__________________ Exp____/____ _____Visa Account Number__________________ Exp____/____ _____MasterCard Account Number__________________ Exp____/____ Please make your check or money order payable to "Lion Sciences National". Step 3: Please complete and print the following fields clearly. Name ___________________________________________________ Address _________________________________________________ City ____________________________________________________ State ___________________________________________________ Zip _____________________________________________________ E-mail __________________________________________________ Signature _________________________________________________ [ required for check and credit card orders] Toll Free FAX Order Line: 1-800-940-6590 If faxing in your order, please state whether you require a fax, email, or no confirmation at all. Allow up to one day for confirmation, if requested. FAX orders are processed immediately. Or, print & mail to: LSN 3502 N. Powerline Rd. #525 Pompano Beach, FL 33069 ______________________________________________________ *CHECK BY FAX ORDERS: Complete the check as normal. Tape the check in the area below. Below the check, clearly write the check number, all numbers at the bottom of the check, & your name. Tape the check below and fax the check to the toll free FAX number above. Void the check. Our merchant will electronically debit your account for the amount of the check; your reference number for this transaction will be your check number. Nothing could be safer & easier ! TAPE CHECK BELOW _____________________________________________________________ This is a one time mailing: Removal is automatic and no further contact is necessary. Please Note: Herbal V is not intended to diagnose, treat, cure or prevent any disease. As individuals differ, so will results. Herbal V helps provide herbal and nutritional support for male sexual performance. The FDA has not evaluated these statements. For details about our double your money back guarantee, please write to the above address, attention consumer affairs department; enclose a self addressed stamped envelope for this and any requested contact information. Thank You. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 04:24:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA29713 for ; Mon, 9 Oct 2000 04:24:01 -0400 (EDT) Received: from standards (47.234.32.16:1937) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FC76@standards.nortelnetworks.com>; Mon, 9 Oct 2000 4:04:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36933 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 04:04:28 -0400 Received: from mars.hss.co.in (202.54.26.197:42528) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FC75@standards.nortelnetworks.com>; Mon, 9 Oct 2000 4:04:22 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e998JUC08300 for ; Mon, 9 Oct 2000 13:49:35 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256973.002CB18A ; Mon, 9 Oct 2000 13:38:10 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256973.002CB015.00@sandesh.hss.hns.com> Date: Mon, 9 Oct 2000 13:43:28 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Add with wildcard termination ID To: MEGACO@STANDARDS.NORTELNETWORKS.COM Suppose there are two terminations in MG named "abcd" and "abce" and MGC sends an ADD as CtxID=$ ADD TermID=abc* Now MG is able to create a Context and successfully ADD "abcd" in it, but ADDing of "abce" fails (say because of "abce" being "outofservice") What ContextID will be used in the response for the termination "abce": 1. $ 2. The allocated ContextID for "abcd" Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 05:02:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29933 for ; Mon, 9 Oct 2000 05:02:30 -0400 (EDT) Received: from standards (47.234.32.16:3491) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FC9E@standards.nortelnetworks.com>; Mon, 9 Oct 2000 4:46:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36988 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 04:46:14 -0400 Received: from mars.hss.co.in (202.54.26.197:43094) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FC9D@standards.nortelnetworks.com>; Mon, 9 Oct 2000 4:46:08 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9991BC09320 for ; Mon, 9 Oct 2000 14:31:17 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256973.00308356 ; Mon, 9 Oct 2000 14:19:53 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256973.0030828E.00@sandesh.hss.hns.com> Date: Mon, 9 Oct 2000 14:25:20 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Duplicate Modify To: MEGACO@STANDARDS.NORTELNETWORKS.COM If a Modify with Signals descriptor is repeated with a new transactionId, is it a NOP from MGC ? It looks like that even though the end state (after command execution) of MG is same as that before command execution, the same signals will be stopped and then restarted on MG (keepactive flag is absent). Thus this is not a NOP. If the defintion of NOP is that the state of MG should not change after execution of command, then ALL audits will be NOPs. Other examples: ADD command failure is a NOP. Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 05:19:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA29977 for ; Mon, 9 Oct 2000 05:19:39 -0400 (EDT) Received: from standards (47.234.32.16:3491) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FCBE@standards.nortelnetworks.com>; Mon, 9 Oct 2000 5:03:22 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37031 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 05:03:22 -0400 Received: from mars.hss.co.in (202.54.26.197:43474) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FCBD@standards.nortelnetworks.com>; Mon, 9 Oct 2000 5:03:09 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e999IIC10029 for ; Mon, 9 Oct 2000 14:48:23 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256973.00320C6B ; Mon, 9 Oct 2000 14:36:39 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256973.003209E1.00@sandesh.hss.hns.com> Date: Mon, 9 Oct 2000 14:42:00 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Audit of packages To: MEGACO@STANDARDS.NORTELNETWORKS.COM Say a termination abc implements the following packages: 1. pkg1 2. pkg2 where pkg2 extends pkg3 and pkg1 doesn't extend any other package If this termination is audited for packages implemented on it, should the reply include pkg3 with pkg1 and pkg2 (base package names are included) Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 08:07:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA02156 for ; Mon, 9 Oct 2000 08:07:03 -0400 (EDT) Received: from standards (47.234.32.16:4519) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FDFD@standards.nortelnetworks.com>; Mon, 9 Oct 2000 7:50:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 37436 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 07:50:50 -0400 Received: from mars.hss.co.in (202.54.26.197:46935) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFB9FDFC@standards.nortelnetworks.com>; Mon, 9 Oct 2000 7:50:42 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e99C5iC16673 for ; Mon, 9 Oct 2000 17:35:50 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256973.004166EF ; Mon, 9 Oct 2000 17:24:21 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256973.004164E3.00@sandesh.hss.hns.com> Date: Mon, 9 Oct 2000 17:29:45 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Audit descriptor processing in Move. To: MEGACO@STANDARDS.NORTELNETWORKS.COM In Section on Move command its mentioned that In Audit descriptor if Statistics token is present, Statistics are reported, that were collected in the old context. Does this indicates the irrespective of the descriptor sequence given for the command MG will always process audit descriptor before moving the termination from its original context? And is it assumed that the remaining descriptor are processing according to the sequence after the termination is moved to the new context? Regards -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 12:00:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA05895 for ; Mon, 9 Oct 2000 12:00:37 -0400 (EDT) Received: from standards (47.234.32.16:2682) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0049@standards.nortelnetworks.com>; Mon, 9 Oct 2000 11:44:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38215 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 11:44:11 -0400 Received: from harrier.prod.itd.earthlink.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA003D@standards.nortelnetworks.com>; Mon, 9 Oct 2000 11:34:10 -0400 Received: from mail.earthlink.net (1Cust43.tnt2.panama-city.fl.da.uu.net [63.25.165.43]) by harrier.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with SMTP id IAA27650; Mon, 9 Oct 2000 08:47:51 -0700 (PDT) Received: from cashgrants3@bigfoot.com by cashgrants30@bigfoot.com (8.8.5/8.6.5) with SMTP id GAA06371 for ; Mon, 09 Oct 2000 07:09:20 -0600 (EST) Message-ID: <> Date: Mon, 9 Oct 2000 07:09:20 EST Reply-To: cashgrants3@BIGFOOT.COM Sender: "Media Gateway Control (megaco)" From: cashgrants3@BIGFOOT.COM Subject: CASH FREE GRANTS X-To: cashgrats30@bigfoot.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Dear Consumer Every day millions of dollars are given away!!! Our Government spends billions of tax dollars on government grants. Do you know that private foundations, trust and corporations are required to give away a portion of their assets. It does'nt matter, where you live, your employment status, or if you are broke, retired or living on a fixed income. There may be a grant for you! CASHING IN ON FREE GOVERNMENT GRANTS FOR PERSONAL NEEDS, BUSINESS, MEDICAL BILLS, EDUCATION, DEBTS AND MORE.... How would you like to get $125.000.00 to start your business? You can use the money to expand, finance equipment, pay salaries, rent and more. How about $8,000.00 spending money for your personal needs such as car payments, rent, clothing, credit card debts, home repair, groceries. Do you need $12,000.00 for education for yourself, or your children? You can get money for private, secondary and primary school. There are grants for undergraduate, graduate, professional and foreign studies and more. THE BEST PART IS THAT YOU NEVER HAVE TO PAY IT BACK! IT IS INTEREST FREE AND NON TAXABLE! NO CREDIT CHECKS, COSIGNERS, SECURITY DEPOSITS OR COLLATERAL REQUIRED. There are no strict requirements to meet. If you have a genuine need, the money can be yours. IT'S TIME FOR YOU TO TAKE ADVANTAGE OF THIS COUNTRY'S BEST KEPT SECRET! We have made the process easy. We have researched and compiled a manual that will help you find a grant. OUR MANUAL" HOW TO OBTAIN FREE CASH GRANTS" will provide you with 45 pages of grant sources. We list the foundations name, address, phone number, contact person and the type of grant they issue. QUESTIONS AND ANSWERS Q: Is obtaining a cash grant legal? A: It is 100% legal and yours for the asking. The Government wants you to take advantage of their grant program and our manual will show you how. Q: How do I get paid? A: The Government agency will send you an acceptance letter with your award amount. Q: Will bad credit interfere with obtaining a free cash grant? A: NO, In fact grants are not based on your credit. It is not a loan, even the unemployed receive grants. Q: What is the average grant amount awarded? A: $1,000.00 to 10,000.00 is average, but it depends on what the grant will be used for. Businesses that benefit the communities have been awarded $100,000 to millions in grant money. Q: If I obtain your publication manual, am I guaranteed to find a grant? A: The US Federal Trade Commission warns consumers that no one can guarantee you a grant, you must apply to the grant offering foundations, corporations etc.. They will review your request and supply your grant if your needs meet the requirements of the grant. We do provide you with a 60 day money back guarantee! This will give you time to apply for some grants and get a response. ACT IN THE NEXT 14 DAYS AND RECEIVE THE "HOW TO OBTAIN FREE CASH GRANT'S "MANUAL AND A FREE BONUS, "HOW TO WRITE A WINNING GRANT PROPOSAL". This guide will list the secrets on getting your grant proposal accepted. RECEIVE ALL THIS FOR THE UNBELIEVABLE LOW PRICE OF $24.95! ACT NOW!! ORDER INFORMATION SIMPLY SEND $24.95, CHECK, MONEY ORDER, OR CREDIT CARD INFORMATION INCLUDE YOUR NAME, ACCOUNT NUMBER, EXPIRATION DATE, ADDRESS AND PHONE NUMBER. TO: INFORMATION PLUS PO BOX 9889 PANAMA CITY BEACH, FL 32417 This mailing is done by an independent marketing co. We apologize if this message has reached you in error. Save the Planet, Save the Trees! Advertise via E mail. No wasted paper! Delete with one simple keystroke! Less refuse in our Dumps! This is the new way of the new millennium! To be removed francis@dcemail.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 16:00:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09507 for ; Mon, 9 Oct 2000 16:00:27 -0400 (EDT) Received: from standards (47.234.32.16:3063) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0335@standards.nortelnetworks.com>; Mon, 9 Oct 2000 15:44:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39241 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 15:44:10 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0334@standards.nortelnetworks.com>; Mon, 9 Oct 2000 15:44:10 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA25424; Mon, 9 Oct 2000 15:58:50 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA24532; Mon, 9 Oct 2000 15:58:32 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4MDPM517>; Mon, 9 Oct 2000 15:58:25 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E78F@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 9 Oct 2000 15:58:23 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Add with wildcard termination ID X-To: "samittal@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM First of all, an Add only can add one termination per command, so Add=abc* would only add abcd. Pressing on, if, for example, abcd was already in a context, then the error would be in $ context, and would indicate no terminations matched, I suppose. We might want to think about whether outofservice really causes a no terminations matched situation. On the one hand, adding an out of service termination makes no sense. On the other hand auditing one does. So does the matching logic work differently for Audit than it does for Add? I would think it shouldn't, thus we have a quandry. Brian -----Original Message----- From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] Sent: Monday, October 09, 2000 4:13 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Add with wildcard termination ID Suppose there are two terminations in MG named "abcd" and "abce" and MGC sends an ADD as CtxID=$ ADD TermID=abc* Now MG is able to create a Context and successfully ADD "abcd" in it, but ADDing of "abce" fails (say because of "abce" being "outofservice") What ContextID will be used in the response for the termination "abce": 1. $ 2. The allocated ContextID for "abcd" Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 16:04:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09569 for ; Mon, 9 Oct 2000 16:04:46 -0400 (EDT) Received: from standards (47.234.32.16:3063) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA034B@standards.nortelnetworks.com>; Mon, 9 Oct 2000 15:46:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39270 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 15:46:40 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA034A@standards.nortelnetworks.com>; Mon, 9 Oct 2000 15:46:40 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25614; Mon, 9 Oct 2000 16:01:16 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA24914; Mon, 9 Oct 2000 16:01:17 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4LSZ17W3>; Mon, 9 Oct 2000 16:01:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E790@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 9 Oct 2000 16:01:16 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Duplicate Modify X-To: "samittal@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM No, the signal starts again, so it is not a NOP. There are lots of NOPs. If you want to call anything that doesn't change state as a NOP, fine. I'd use a different definition, but I can't see that it matters. -----Original Message----- From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] Sent: Monday, October 09, 2000 4:55 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Duplicate Modify If a Modify with Signals descriptor is repeated with a new transactionId, is it a NOP from MGC ? It looks like that even though the end state (after command execution) of MG is same as that before command execution, the same signals will be stopped and then restarted on MG (keepactive flag is absent). Thus this is not a NOP. If the defintion of NOP is that the state of MG should not change after execution of command, then ALL audits will be NOPs. Other examples: ADD command failure is a NOP. Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 16:04:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09573 for ; Mon, 9 Oct 2000 16:04:47 -0400 (EDT) Received: from standards (47.234.32.16:3063) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA036B@standards.nortelnetworks.com>; Mon, 9 Oct 2000 15:49:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39312 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 15:49:45 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA036A@standards.nortelnetworks.com>; Mon, 9 Oct 2000 15:49:45 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25730; Mon, 9 Oct 2000 16:03:05 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25147; Mon, 9 Oct 2000 16:02:56 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4LSZ17XM>; Mon, 9 Oct 2000 16:02:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E791@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 9 Oct 2000 16:02:53 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Audit of packages X-To: "samittal@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM We've been around this and basically, it is up to the MG. It does not HAVE to report pkg3, but it could. Maybe SHOULD is a good word, and I wonder if text to that effect should go in the implementor's guide? Brian -----Original Message----- From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] Sent: Monday, October 09, 2000 5:12 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Audit of packages Say a termination abc implements the following packages: 1. pkg1 2. pkg2 where pkg2 extends pkg3 and pkg1 doesn't extend any other package If this termination is audited for packages implemented on it, should the reply include pkg3 with pkg1 and pkg2 (base package names are included) Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 16:08:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09615 for ; Mon, 9 Oct 2000 16:08:09 -0400 (EDT) Received: from standards (47.234.32.16:3063) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0388@standards.nortelnetworks.com>; Mon, 9 Oct 2000 15:52:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39350 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 15:52:08 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0387@standards.nortelnetworks.com>; Mon, 9 Oct 2000 15:52:08 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25954; Mon, 9 Oct 2000 16:06:19 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA25695; Mon, 9 Oct 2000 16:06:20 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4MDPM5GS>; Mon, 9 Oct 2000 16:06:19 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E792@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 9 Oct 2000 16:06:14 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Audit descriptor processing in Move. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hmmm, very good question. I'd say that PROCESSING the descriptor is done in the order of the occurence in the command, including Audit. That you get the statistics of the prior Context is independent of the order executed, although I see why you would be concerned. Brian -----Original Message----- From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] Sent: Monday, October 09, 2000 8:00 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Audit descriptor processing in Move. In Section on Move command its mentioned that In Audit descriptor if Statistics token is present, Statistics are reported, that were collected in the old context. Does this indicates the irrespective of the descriptor sequence given for the command MG will always process audit descriptor before moving the termination from its original context? And is it assumed that the remaining descriptor are processing according to the sequence after the termination is moved to the new context? Regards -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 16:32:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA09801 for ; Mon, 9 Oct 2000 16:32:46 -0400 (EDT) Received: from standards (47.234.32.16:3063) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA03C6@standards.nortelnetworks.com>; Mon, 9 Oct 2000 16:16:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39435 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 16:16:28 -0400 Received: from qhars002.nortel.com (47.101.112.102:43086) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA03C5@standards.nortelnetworks.com>; Mon, 9 Oct 2000 16:16:28 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Mon, 9 Oct 2000 21:30:51 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Mon, 9 Oct 2000 15:30:15 -0500 Received: from zrtpd00x.us.nortel.com ([47.140.202.32]) by zrchb200.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id T21X2AWD; Mon, 9 Oct 2000 15:30:05 -0500 Received: from americasm01.nt.com (brtphe34.us.nortel.com [47.202.35.89]) by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4L9BLLKW; Mon, 9 Oct 2000 16:30:04 -0400 X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/778) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E78F@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E22AC7.DD8C08D9@americasm01.nt.com> Date: Mon, 9 Oct 2000 16:30:03 -0400 Reply-To: Kevin Boyle Sender: "Media Gateway Control (megaco)" From: Kevin Boyle Organization: Nortel Networks Subject: Re: Add with wildcard termination ID X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit It seems to me that if you can only add one termination per command, then use of the ALL (*) wildcard is not allowed for Add. CHOOSE ($), however, would be acceptable. There are other commands where these kinds of restrictions are already expressed, so why not add one for Add in the Implementer's Guide? It would also seem to me that if a termination is OOS, then adding it is not allowed. Once again, somthing for the Implementer's Guide? Kevin "Rosen, Brian" wrote: > First of all, an Add only can add one termination per command, > so Add=abc* would only add abcd. Pressing on, if, for > example, abcd was already in a context, then the > error would be in $ context, and would indicate no terminations > matched, I suppose. > > We might want to think about whether outofservice really causes > a no terminations matched situation. On the one hand, adding > an out of service termination makes no sense. On the other hand > auditing one does. So does the matching logic work differently > for Audit than it does for Add? I would think it shouldn't, > thus we have a quandry. > > Brian > > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Monday, October 09, 2000 4:13 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Add with wildcard termination ID > > Suppose there are two terminations in MG named "abcd" and "abce" > and MGC sends an ADD as > CtxID=$ ADD TermID=abc* > Now MG is able to create a Context and successfully ADD "abcd" in it, but > ADDing of "abce" fails (say because of "abce" being "outofservice") > > What ContextID will be used in the response for the termination "abce": > 1. $ > 2. The allocated ContextID for "abcd" > > Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 9 22:35:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA14671 for ; Mon, 9 Oct 2000 22:35:40 -0400 (EDT) Received: from standards (47.234.32.16:4021) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA06A1@standards.nortelnetworks.com>; Mon, 9 Oct 2000 22:19:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40398 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 9 Oct 2000 22:19:25 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:57358) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0694@standards.nortelnetworks.com>; Mon, 9 Oct 2000 22:09:24 -0400 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id MAA24016; Tue, 10 Oct 2000 12:21:16 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id NAA29039; Tue, 10 Oct 2000 13:23:32 +1100 (EST) Received: from ericsson.com.au (brdhcp202-028.epa.ericsson.se [146.11.202.28]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id TKN3NB5Q; Tue, 10 Oct 2000 13:23:41 +1100 X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E78F@whq-msgusr-02.pit.comms.marconi.com> Content-Type: multipart/mixed; boundary="------------6EFE892FC8605E7BC2E3796F" Message-ID: <39E27DAB.8AD6F138@ericsson.com.au> Date: Tue, 10 Oct 2000 13:23:39 +1100 Reply-To: Paul Hollis Sender: "Media Gateway Control (megaco)" From: Paul Hollis Organization: Ericsson Australia Subject: Re: Add with wildcard termination ID X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------6EFE892FC8605E7BC2E3796F Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit G'day Brian, I would have thought that you could ADD more than one termination based on the sentence that follows the ADD command in H248: "If the wildcard matches more than one TerminationID, all possible matches are attempted, with results reported for each one. " Regards Paul. "Rosen, Brian" wrote: > First of all, an Add only can add one termination per command, > so Add=abc* would only add abcd. Pressing on, if, for > example, abcd was already in a context, then the > error would be in $ context, and would indicate no terminations > matched, I suppose. > > We might want to think about whether outofservice really causes > a no terminations matched situation. On the one hand, adding > an out of service termination makes no sense. On the other hand > auditing one does. So does the matching logic work differently > for Audit than it does for Add? I would think it shouldn't, > thus we have a quandry. > > Brian > > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Monday, October 09, 2000 4:13 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Add with wildcard termination ID > > Suppose there are two terminations in MG named "abcd" and "abce" > and MGC sends an ADD as > CtxID=$ ADD TermID=abc* > Now MG is able to create a Context and successfully ADD "abcd" in it, but > ADDing of "abce" fails (say because of "abce" being "outofservice") > > What ContextID will be used in the response for the termination "abce": > 1. $ > 2. The allocated ContextID for "abcd" > > Sachin --------------6EFE892FC8605E7BC2E3796F Content-Type: text/x-vcard; charset=us-ascii; name="paul.hollis.vcf" Content-Description: Card for Paul Hollis Content-Disposition: attachment; filename="paul.hollis.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Hollis;Paul tel;fax:9301 1139 tel;work:9301 2326 x-mozilla-html:FALSE org:Ericsson Australia. adr:;;;Melbourne;Victoria;;Australia version:2.1 email;internet:Paul.Hollis@ericsson.com.au title:Software Designer (Signalling) x-mozilla-cpt:;17264 fn:Paul Hollis end:vcard --------------6EFE892FC8605E7BC2E3796F-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 06:32:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00545 for ; Tue, 10 Oct 2000 06:32:54 -0400 (EDT) Received: from standards (47.234.32.16:3305) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA08D3@standards.nortelnetworks.com>; Tue, 10 Oct 2000 6:11:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41156 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 06:11:53 -0400 Received: from mink.ecitele.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA08D2@standards.nortelnetworks.com>; Tue, 10 Oct 2000 6:11:52 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id MAA00390 for ; Tue, 10 Oct 2000 12:25:32 +0200 (IST) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3 (Intl)|21 March 2000) at 10/10/2000 12:27:08 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Tue, 10 Oct 2000 12:21:24 +0300 Reply-To: Shlomo.Kabaz@ECITELE.COM Sender: "Media Gateway Control (megaco)" From: Shlomo Kabaz ECItelecom Subject: physical and ephemeral terminations To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi , all ! Does the physical termination have properties , because in the examples in the Rfc all the properties of the "connection" is given in the ephemeral termination and the elements that are given to physical is events and signals . Thanks , Shlomo From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 06:32:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA00548 for ; Tue, 10 Oct 2000 06:32:54 -0400 (EDT) Received: from standards (47.234.32.16:3305) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA08F7@standards.nortelnetworks.com>; Tue, 10 Oct 2000 6:16:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41205 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 06:16:02 -0400 Received: from mink.ecitele.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA08F6@standards.nortelnetworks.com>; Tue, 10 Oct 2000 6:16:00 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id MAA00689 for ; Tue, 10 Oct 2000 12:29:46 +0200 (IST) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3 (Intl)|21 March 2000) at 10/10/2000 12:31:21 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Tue, 10 Oct 2000 12:25:39 +0300 Reply-To: Shlomo.Kabaz@ECITELE.COM Sender: "Media Gateway Control (megaco)" From: Shlomo Kabaz ECItelecom Subject: the Audit command To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi , all ! When the Mg is being Audited then : A. If the Audit is on the Null context only , meaning physical terminations only , does that mean the the reply will include elements such as Signals and Events only . B. If the Audit is for context = "All" , termination = "All" and the reply should be wilcarded . What structure should the reply have ? Will it be under context = "All" ? Thanks , Shlomo ! From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 07:45:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01822 for ; Tue, 10 Oct 2000 07:45:35 -0400 (EDT) Received: from standards (47.234.32.16:3305) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0A07@standards.nortelnetworks.com>; Tue, 10 Oct 2000 7:29:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41545 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 07:29:09 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0A06@standards.nortelnetworks.com>; Tue, 10 Oct 2000 7:29:08 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA00792; Tue, 10 Oct 2000 07:43:51 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA25791; Tue, 10 Oct 2000 07:43:53 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4LSZFLQ1>; Tue, 10 Oct 2000 07:43:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E797@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 10 Oct 2000 07:43:51 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: physical and ephemeral terminations X-To: "Shlomo.Kabaz@ECITELE.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Any termination can have properties, defined by the packages implemented on it. Look at the IPPhone packages for example. Brian -----Original Message----- From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM] Sent: Tuesday, October 10, 2000 5:21 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: physical and ephemeral terminations Hi , all ! Does the physical termination have properties , because in the examples in the Rfc all the properties of the "connection" is given in the ephemeral termination and the elements that are given to physical is events and signals . Thanks , Shlomo From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 07:50:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA01903 for ; Tue, 10 Oct 2000 07:50:03 -0400 (EDT) Received: from standards (47.234.32.16:3305) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0A21@standards.nortelnetworks.com>; Tue, 10 Oct 2000 7:32:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41581 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 07:32:19 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0A20@standards.nortelnetworks.com>; Tue, 10 Oct 2000 7:32:19 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA00890; Tue, 10 Oct 2000 07:47:01 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA25988; Tue, 10 Oct 2000 07:47:03 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4MDPM7B7>; Tue, 10 Oct 2000 07:47:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E798@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 10 Oct 2000 07:46:57 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: the Audit command X-To: "Shlomo.Kabaz@ECITELE.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM When the Mg is being Audited then : A. If the Audit is on the Null context only , meaning physical terminations only , does that mean the the reply will include elements such as Signals and Events only . It includes all the state of the terminations. You get what you ask for, even if the descriptor is empty. Ask for Media, and you will get a Media descriptor, uninteresting though it may be. Packages is interesting :) B. If the Audit is for context = "All" , termination = "All" and the reply should be wilcarded . What structure should the reply have ? Will it be under context = "All" ? Yes, if you ask for a wildcard response, I think the ContextId and TerminationId you get back is what you sent. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 13:19:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA08640 for ; Tue, 10 Oct 2000 13:19:31 -0400 (EDT) Received: from standards (47.234.32.16:2843) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0E38@standards.nortelnetworks.com>; Tue, 10 Oct 2000 13:03:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42965 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 13:03:11 -0400 Received: from qhars002.nortel.com (47.101.112.102:41872) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0E37@standards.nortelnetworks.com>; Tue, 10 Oct 2000 13:03:11 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Tue, 10 Oct 2000 18:17:41 +0100 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 10 Oct 2000 13:13:30 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Tue, 10 Oct 2000 13:13:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C032DD.3E9C8460" X-Orig: Message-ID: <353093573B82D411889E0000F808216648E3D0@zcard00q.ca.nortel.com> Date: Tue, 10 Oct 2000 13:12:18 -0400 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Audit of packages X-cc: Christian Groves , "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C032DD.3E9C8460 Content-Type: text/plain; charset="iso-8859-1" I agree in general, since "extends" basically means "clone the base package and add some more functionality" (no subsetting, over-riding etc allowed). In example below pkg2 by definition implements pkg3. (Not the case with re-versioning of Packages though!) One clarification however. It does not always make sense for a base package to be published as implemented by an MG. There are examples where the base package is defined such that it acts similar to a virtual class, and has no function on its own, simply defining interface for one or more derived packages. Annex E ToneGen and ToneDet as well as a few packages in Annex G are examples. Therefore, implementer's guide MUST not make a hard and fast rule on this, but SHOULD say "SHOULD" with some words to describe where its inappropriate. -- Peter -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Monday, October 09, 2000 16:03 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages We've been around this and basically, it is up to the MG. It does not HAVE to report pkg3, but it could. Maybe SHOULD is a good word, and I wonder if text to that effect should go in the implementor's guide? Brian -----Original Message----- From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] Sent: Monday, October 09, 2000 5:12 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Audit of packages Say a termination abc implements the following packages: 1. pkg1 2. pkg2 where pkg2 extends pkg3 and pkg1 doesn't extend any other package If this termination is audited for packages implemented on it, should the reply include pkg3 with pkg1 and pkg2 (base package names are included) Sachin ------_=_NextPart_001_01C032DD.3E9C8460 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Audit of packages

I agree in general, since "extends" = basically means "clone the base package and add some more = functionality" (no subsetting, over-riding etc allowed).  In = example below pkg2 by definition implements pkg3.  (Not the case = with re-versioning of Packages though!)  

One clarification however.  It does not always = make sense for a base package to be published as implemented by an = MG.  There are examples where the base package is defined such = that it acts similar to a virtual class, and has no function on its = own, simply defining interface for one or more derived packages.  = Annex E ToneGen and ToneDet as well as a few packages in Annex G are = examples.  Therefore, implementer's guide MUST not make a hard and = fast rule on this, but SHOULD say "SHOULD" with some words to = describe where its inappropriate. 

-- Peter


-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Monday, October 09, 2000 16:03
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Audit of packages


We've been around this and basically, it is up to the = MG.
It does not HAVE to report pkg3, but it could.  = Maybe SHOULD
is a good word, and I wonder if text to that = effect
should go in the implementor's guide?

Brian

-----Original Message-----
From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
Sent: Monday, October 09, 2000 5:12 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Audit of packages


Say a termination abc implements the following = packages:
1. pkg1
2. pkg2
where pkg2 extends pkg3 and pkg1 doesn't extend any = other package

If this termination is audited for packages = implemented on it,
should the reply include pkg3 with pkg1 and pkg2 = (base package names
are included)

Sachin

------_=_NextPart_001_01C032DD.3E9C8460-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 10 14:38:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA10095 for ; Tue, 10 Oct 2000 14:38:48 -0400 (EDT) Received: from standards (47.234.32.16:4544) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0F00@standards.nortelnetworks.com>; Tue, 10 Oct 2000 14:22:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 43226 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 10 Oct 2000 14:22:23 -0400 Received: from netmail2.alcatel.com (hosta833.alcatel.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA0EFB@standards.nortelnetworks.com>; Tue, 10 Oct 2000 14:12:23 -0400 Received: from relay2.usa.alcatel.com (relay2.usa.alcatel.com [143.209.238.7]) by netmail2.alcatel.com (8.9.1/8.9.1) with ESMTP id NAA03880 for ; Tue, 10 Oct 2000 13:26:17 -0500 (CDT) Received: from ssd.usa.alcatel.com (localhost [127.0.0.1]) by relay2.usa.alcatel.com (8.9.3/8.9.3) with ESMTP id NAA29416 for ; Tue, 10 Oct 2000 13:27:06 -0500 (CDT) Received: from sun1654.ssd.usa.alcatel.com (sun1654.ssd.usa.alcatel.com [143.209.153.117]) by ssd.usa.alcatel.com (8.8.8+Sun/8.8.8) with ESMTP id NAA01209 for ; Tue, 10 Oct 2000 13:26:25 -0500 (CDT) Received: from usa.alcatel.com (localhost [127.0.0.1]) by sun1654.ssd.usa.alcatel.com (8.9.3+Sun/8.9.1) with ESMTP id NAA19824 for ; Tue, 10 Oct 2000 13:26:24 -0500 (CDT) X-Mailer: Mozilla 4.72 [en] (X11; U; SunOS 5.7 sun4u) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E78F@whq-msgusr-02.pit.comms.marconi.com> <39E22AC7.DD8C08D9@americasm01.nt.com> Content-Type: multipart/alternative; boundary="------------4E8E5099A4857B2780E16983" Message-ID: <39E35F50.BED42E17@usa.alcatel.com> Date: Tue, 10 Oct 2000 13:26:24 -0500 Reply-To: Chuong Nguyen Sender: "Media Gateway Control (megaco)" From: Chuong Nguyen Subject: Re: Add with wildcard termination ID To: MEGACO@STANDARDS.NORTELNETWORKS.COM --------------4E8E5099A4857B2780E16983 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Section 7.2.1 there is the following statement: "Add SHALL NOT be used on a Termination with a serviceState of "OutofService"." So I assume that MG should return an error on this ADD. Chuong Kevin Boyle wrote: > It seems to me that if you can only add one termination per command, then > use of the ALL (*) wildcard is not allowed for Add. CHOOSE ($), however, > would be acceptable. There are other commands where these kinds of > restrictions are already expressed, so why not add one for Add in the > Implementer's Guide? > > It would also seem to me that if a termination is OOS, then adding it is not > allowed. Once again, somthing for the Implementer's Guide? > > Kevin > > "Rosen, Brian" wrote: > > > First of all, an Add only can add one termination per command, > > so Add=abc* would only add abcd. Pressing on, if, for > > example, abcd was already in a context, then the > > error would be in $ context, and would indicate no terminations > > matched, I suppose. > > > > We might want to think about whether outofservice really causes > > a no terminations matched situation. On the one hand, adding > > an out of service termination makes no sense. On the other hand > > auditing one does. So does the matching logic work differently > > for Audit than it does for Add? I would think it shouldn't, > > thus we have a quandry. > > > > Brian > > > > -----Original Message----- > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > Sent: Monday, October 09, 2000 4:13 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Add with wildcard termination ID > > > > Suppose there are two terminations in MG named "abcd" and "abce" > > and MGC sends an ADD as > > CtxID=$ ADD TermID=abc* > > Now MG is able to create a Context and successfully ADD "abcd" in it, but > > ADDing of "abce" fails (say because of "abce" being "outofservice") > > > > What ContextID will be used in the response for the termination "abce": > > 1. $ > > 2. The allocated ContextID for "abcd" > > > > Sachin -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --------------4E8E5099A4857B2780E16983 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Section 7.2.1 there is the following statement:

"Add SHALL NOT be used on a Termination with a serviceState of "OutofService"."

So I assume that MG should return an error on this ADD.

Chuong
 
 

Kevin Boyle wrote:

It seems to me that if you can only add one termination per command, then
use of the ALL (*) wildcard is not allowed for Add.  CHOOSE ($), however,
would be acceptable.  There are other commands where these kinds of
restrictions are already expressed, so why not add one for Add in the
Implementer's Guide?

It would also seem to me that if a termination is OOS, then adding it is not
allowed.  Once again, somthing for the Implementer's Guide?

Kevin

"Rosen, Brian" wrote:

> First of all, an Add only can add one termination per command,
> so Add=abc* would only add abcd.  Pressing on, if, for
> example, abcd was already in a context, then the
> error would be in $ context, and would indicate no terminations
> matched, I suppose.
>
> We might want to think about whether outofservice really causes
> a no terminations matched situation.  On the one hand, adding
> an out of service termination makes no sense.  On the other hand
> auditing one does.  So does the matching logic work differently
> for Audit than it does for Add?  I would think it shouldn't,
> thus we have a quandry.
>
> Brian
>
> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> Sent: Monday, October 09, 2000 4:13 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Add with wildcard termination ID
>
> Suppose there are two terminations in MG named "abcd" and "abce"
> and MGC sends an ADD as
> CtxID=$ ADD TermID=abc*
> Now MG is able to create a Context and successfully ADD "abcd" in it, but
> ADDing of "abce" fails (say because of "abce" being "outofservice")
>
> What ContextID will be used in the response for the termination "abce":
> 1. $
> 2. The allocated ContextID for "abcd"
>
> Sachin

-- 
  Alcatel USA, Inc             Internet: Chuong.Nguyen@usa.alcatel.com
  1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
  **** The opinions expressed are not those of Alcatel USA, Inc ****
  --------------4E8E5099A4857B2780E16983-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 01:00:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA20493 for ; Wed, 11 Oct 2000 01:00:22 -0400 (EDT) Received: from standards (47.234.32.16:1238) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1294@standards.nortelnetworks.com>; Wed, 11 Oct 2000 0:44:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44455 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 00:43:59 -0400 Received: from mars.hss.co.in (202.54.26.197:63978) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1293@standards.nortelnetworks.com>; Wed, 11 Oct 2000 0:43:53 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9B4xCC20512 for ; Wed, 11 Oct 2000 10:29:16 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256975.001A5A8E ; Wed, 11 Oct 2000 10:17:51 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=AtYkKsTS3y7PuNYvMTnpPvxh0SnRB3LF18I4k7hDSRe8V3fhGyQ6ag8t" Content-Disposition: inline Message-ID: <65256975.001A58FC.00@sandesh.hss.hns.com> Date: Wed, 11 Oct 2000 10:23:15 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Re: Add with wildcard termination ID To: MEGACO@STANDARDS.NORTELNETWORKS.COM --0__=AtYkKsTS3y7PuNYvMTnpPvxh0SnRB3LF18I4k7hDSRe8V3fhGyQ6ag8t Content-type: text/plain; charset=us-ascii Content-Disposition: inline Now that it is understood that abc* may Add more than one termination and an "outofservice" termination can't be Added, what should an MG do when it receives ADD with termination abc* and CtxID = $ and MG is able to add abcd in CtxID say 1 but fails to Add other termination say abce ? Should MG send the response of Add of abce using CtxID = $ or using CtxID that is allocated. Sachin Chuong Nguyen on 10/10/2000 11:56:24 PM Please respond to Chuong Nguyen To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Sachin Mittal/HSS) Subject: Re: Add with wildcard termination ID Section 7.2.1 there is the following statement: "Add SHALL NOT be used on a Termination with a serviceState of "OutofService"." So I assume that MG should return an error on this ADD. Chuong Kevin Boyle wrote: > It seems to me that if you can only add one termination per command, then > use of the ALL (*) wildcard is not allowed for Add. CHOOSE ($), however, > would be acceptable. There are other commands where these kinds of > restrictions are already expressed, so why not add one for Add in the > Implementer's Guide? > > It would also seem to me that if a termination is OOS, then adding it is not > allowed. Once again, somthing for the Implementer's Guide? > > Kevin > > "Rosen, Brian" wrote: > > > First of all, an Add only can add one termination per command, > > so Add=abc* would only add abcd. Pressing on, if, for > > example, abcd was already in a context, then the > > error would be in $ context, and would indicate no terminations > > matched, I suppose. > > > > We might want to think about whether outofservice really causes > > a no terminations matched situation. On the one hand, adding > > an out of service termination makes no sense. On the other hand > > auditing one does. So does the matching logic work differently > > for Audit than it does for Add? I would think it shouldn't, > > thus we have a quandry. > > > > Brian > > > > -----Original Message----- > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > Sent: Monday, October 09, 2000 4:13 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Add with wildcard termination ID > > > > Suppose there are two terminations in MG named "abcd" and "abce" > > and MGC sends an ADD as > > CtxID=$ ADD TermID=abc* > > Now MG is able to create a Context and successfully ADD "abcd" in it, but > > ADDing of "abce" fails (say because of "abce" being "outofservice") > > > > What ContextID will be used in the response for the termination "abce": > > 1. $ > > 2. The allocated ContextID for "abcd" > > > > Sachin -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** --0__=AtYkKsTS3y7PuNYvMTnpPvxh0SnRB3LF18I4k7hDSRe8V3fhGyQ6ag8t Content-type: text/html; name="att1.htm" Content-Disposition: attachment; filename="att1.htm" Content-Description: Internet HTML Content-Transfer-Encoding: base64 PCFkb2N0eXBlIGh0bWwgcHVibGljICItLy93M2MvL2R0ZCBodG1sIDQuMCB0cmFuc2l0aW9uYWwv L2VuIj4NCjxodG1sPg0KU2VjdGlvbiA3LjIuMSB0aGVyZSBpcyB0aGUgZm9sbG93aW5nIHN0YXRl bWVudDoNCjxwPiJBZGQgU0hBTEwmbmJzcDtOT1QgYmUgdXNlZCBvbiBhIFRlcm1pbmF0aW9uIHdp dGggYSBzZXJ2aWNlU3RhdGUgb2YNCiJPdXRvZlNlcnZpY2UiLiINCjxwPlNvIEkgYXNzdW1lIHRo YXQgTUcmbmJzcDtzaG91bGQgcmV0dXJuIGFuIGVycm9yIG9uIHRoaXMgQURELg0KPHA+Q2h1b25n DQo8YnI+Jm5ic3A7DQo8YnI+Jm5ic3A7DQo8cD5LZXZpbiBCb3lsZSB3cm90ZToNCjxibG9ja3F1 b3RlIFRZUEU9Q0lURT5JdCBzZWVtcyB0byBtZSB0aGF0IGlmIHlvdSBjYW4gb25seSBhZGQgb25l IHRlcm1pbmF0aW9uDQpwZXIgY29tbWFuZCwgdGhlbg0KPGJyPnVzZSBvZiB0aGUgQUxMICgqKSB3 aWxkY2FyZCBpcyBub3QgYWxsb3dlZCBmb3IgQWRkLiZuYnNwOyBDSE9PU0UgKCQpLA0KaG93ZXZl ciwNCjxicj53b3VsZCBiZSBhY2NlcHRhYmxlLiZuYnNwOyBUaGVyZSBhcmUgb3RoZXIgY29tbWFu ZHMgd2hlcmUgdGhlc2Uga2luZHMNCm9mDQo8YnI+cmVzdHJpY3Rpb25zIGFyZSBhbHJlYWR5IGV4 cHJlc3NlZCwgc28gd2h5IG5vdCBhZGQgb25lIGZvciBBZGQgaW4gdGhlDQo8YnI+SW1wbGVtZW50 ZXIncyBHdWlkZT8NCjxwPkl0IHdvdWxkIGFsc28gc2VlbSB0byBtZSB0aGF0IGlmIGEgdGVybWlu YXRpb24gaXMgT09TLCB0aGVuIGFkZGluZyBpdA0KaXMgbm90DQo8YnI+YWxsb3dlZC4mbmJzcDsg T25jZSBhZ2Fpbiwgc29tdGhpbmcgZm9yIHRoZSBJbXBsZW1lbnRlcidzIEd1aWRlPw0KPHA+S2V2 aW4NCjxwPiJSb3NlbiwgQnJpYW4iIHdyb3RlOg0KPHA+PiBGaXJzdCBvZiBhbGwsIGFuIEFkZCBv bmx5IGNhbiBhZGQgb25lIHRlcm1pbmF0aW9uIHBlciBjb21tYW5kLA0KPGJyPj4gc28gQWRkPWFi Yyogd291bGQgb25seSBhZGQgYWJjZC4mbmJzcDsgUHJlc3Npbmcgb24sIGlmLCBmb3INCjxicj4+ IGV4YW1wbGUsIGFiY2Qgd2FzIGFscmVhZHkgaW4gYSBjb250ZXh0LCB0aGVuIHRoZQ0KPGJyPj4g ZXJyb3Igd291bGQgYmUgaW4gJCBjb250ZXh0LCBhbmQgd291bGQgaW5kaWNhdGUgbm8gdGVybWlu YXRpb25zDQo8YnI+PiBtYXRjaGVkLCBJIHN1cHBvc2UuDQo8YnI+Pg0KPGJyPj4gV2UgbWlnaHQg d2FudCB0byB0aGluayBhYm91dCB3aGV0aGVyIG91dG9mc2VydmljZSByZWFsbHkgY2F1c2VzDQo8 YnI+PiBhIG5vIHRlcm1pbmF0aW9ucyBtYXRjaGVkIHNpdHVhdGlvbi4mbmJzcDsgT24gdGhlIG9u ZSBoYW5kLCBhZGRpbmcNCjxicj4+IGFuIG91dCBvZiBzZXJ2aWNlIHRlcm1pbmF0aW9uIG1ha2Vz IG5vIHNlbnNlLiZuYnNwOyBPbiB0aGUgb3RoZXINCmhhbmQNCjxicj4+IGF1ZGl0aW5nIG9uZSBk b2VzLiZuYnNwOyBTbyBkb2VzIHRoZSBtYXRjaGluZyBsb2dpYyB3b3JrIGRpZmZlcmVudGx5DQo8 YnI+PiBmb3IgQXVkaXQgdGhhbiBpdCBkb2VzIGZvciBBZGQ/Jm5ic3A7IEkgd291bGQgdGhpbmsg aXQgc2hvdWxkbid0LA0KPGJyPj4gdGh1cyB3ZSBoYXZlIGEgcXVhbmRyeS4NCjxicj4+DQo8YnI+ PiBCcmlhbg0KPGJyPj4NCjxicj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo8YnI+PiBG cm9tOiBTYWNoaW4gTWl0dGFsIFs8YSBocmVmPSJtYWlsdG86c2FtaXR0YWxASFNTLkhOUy5DT00i Pm1haWx0bzpzYW1pdHRhbEBIU1MuSE5TLkNPTTwvYT5dDQo8YnI+PiBTZW50OiBNb25kYXksIE9j dG9iZXIgMDksIDIwMDAgNDoxMyBBTQ0KPGJyPj4gVG86IE1FR0FDT0BTVEFOREFSRFMuTk9SVEVM TkVUV09SS1MuQ09NDQo8YnI+PiBTdWJqZWN0OiBBZGQgd2l0aCB3aWxkY2FyZCB0ZXJtaW5hdGlv biBJRA0KPGJyPj4NCjxicj4+IFN1cHBvc2UgdGhlcmUgYXJlIHR3byB0ZXJtaW5hdGlvbnMgaW4g TUcgbmFtZWQgImFiY2QiIGFuZCAiYWJjZSINCjxicj4+IGFuZCBNR0Mgc2VuZHMgYW4gQUREIGFz DQo8YnI+PiBDdHhJRD0kIEFERCBUZXJtSUQ9YWJjKg0KPGJyPj4gTm93IE1HIGlzIGFibGUgdG8g Y3JlYXRlIGEgQ29udGV4dCBhbmQgc3VjY2Vzc2Z1bGx5IEFERCAiYWJjZCIgaW4NCml0LCBidXQN Cjxicj4+IEFERGluZyBvZiAiYWJjZSIgZmFpbHMgKHNheSBiZWNhdXNlIG9mICJhYmNlIiBiZWlu ZyAib3V0b2ZzZXJ2aWNlIikNCjxicj4+DQo8YnI+PiBXaGF0IENvbnRleHRJRCB3aWxsIGJlIHVz ZWQgaW4gdGhlIHJlc3BvbnNlIGZvciB0aGUgdGVybWluYXRpb24gImFiY2UiOg0KPGJyPj4gMS4g JA0KPGJyPj4gMi4gVGhlIGFsbG9jYXRlZCBDb250ZXh0SUQgZm9yICJhYmNkIg0KPGJyPj4NCjxi cj4+IFNhY2hpbjwvYmxvY2txdW90ZT4NCg0KPHByZT4tLSZuYnNwOw0KJm5ic3A7IEFsY2F0ZWwg VVNBLCBJbmMmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW50ZXJuZXQ6IENodW9uZy5OZ3V5ZW5AdXNhLmFsY2F0 ZWwuY29tDQombmJzcDsgMTAwMCBDb2l0IFJvYWQgUGxhbm8sIFRleGFzIDc1MDc1Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IFBob25l OiZuYnNwOyZuYnNwOyZuYnNwOyAoOTcyKSA1MTktNDYxMw0KJm5ic3A7ICoqKiogVGhlIG9waW5p b25zIGV4cHJlc3NlZCBhcmUgbm90IHRob3NlIG9mIEFsY2F0ZWwgVVNBLCBJbmMgKioqKjwvcHJl Pg0KJm5ic3A7PC9odG1sPg0KDQo= --0__=AtYkKsTS3y7PuNYvMTnpPvxh0SnRB3LF18I4k7hDSRe8V3fhGyQ6ag8t-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 01:34:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24712 for ; Wed, 11 Oct 2000 01:34:29 -0400 (EDT) Received: from standards (47.234.32.16:2618) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA12D9@standards.nortelnetworks.com>; Wed, 11 Oct 2000 1:16:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44505 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 01:16:52 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA12B8@standards.nortelnetworks.com>; Wed, 11 Oct 2000 1:06:52 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9B5Ldt17864 for ; Wed, 11 Oct 2000 07:21:39 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id HAA17779 for ; Wed, 11 Oct 2000 07:21:38 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA08179 for ; Wed, 11 Oct 2000 07:21:36 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E3E161.1C40DD45@ericsson.com> Date: Wed, 11 Oct 2000 14:41:21 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Error Descriptor omitted from Command Responses To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, It was pointed out to me that despite the fact that we can in the ASN1 (and ABNF? I haven't checked) return an ErrorDescriptor in a command response we don't actually show this fact in section 7.2. We do talk about error descriptors being returned in 8.2.2 ie. "Each of the Response parameters represents a return value as mentioned in section 7.2, or an error descriptor if the command execution encountered an error. Commands after the point of failure are not processed and, therefore, Responses are not issued for them." Is this enough or do people feel that a change to the implementors' guide in warrented? Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 01:34:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24719 for ; Wed, 11 Oct 2000 01:34:30 -0400 (EDT) Received: from standards (47.234.32.16:2618) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA12EE@standards.nortelnetworks.com>; Wed, 11 Oct 2000 1:17:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44566 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 01:17:33 -0400 Received: from mars.hss.co.in (202.54.26.197:64675) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA12E5@standards.nortelnetworks.com>; Wed, 11 Oct 2000 1:17:27 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9B5WgC21754 for ; Wed, 11 Oct 2000 11:02:47 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256975.001D6951 ; Wed, 11 Oct 2000 10:51:15 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256975.001D67D7.00@sandesh.hss.hns.com> Date: Wed, 11 Oct 2000 10:56:40 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: Notify and Modify on OOS Termination To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello, Please clarify the following regarding validity of commands on OOS (out-of-service) termination. a) Is it possible for MG to detect events and hence generate NOTIFY on an OOS (Out of Service) termination ? b) Also, it has not been stated clearly in the protocol as to whether MG should apply MODIFY command to an OOS termination or it should generate a Protocol Error. Thanks for your time. Chanchal From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 05:05:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA04955 for ; Wed, 11 Oct 2000 05:05:31 -0400 (EDT) Received: from standards (47.234.32.16:1868) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA14A2@standards.nortelnetworks.com>; Wed, 11 Oct 2000 4:48:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45125 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 04:48:42 -0400 Received: from mink.ecitele.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA14A1@standards.nortelnetworks.com>; Wed, 11 Oct 2000 4:48:38 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id LAA11739 for ; Wed, 11 Oct 2000 11:02:08 +0200 (IST) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3 (Intl)|21 March 2000) at 11/10/2000 11:03:45 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Wed, 11 Oct 2000 10:58:03 +0300 Reply-To: Shlomo.Kabaz@ECITELE.COM Sender: "Media Gateway Control (megaco)" From: Shlomo Kabaz ECItelecom Subject: adding property to continuity test package To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi , all ! I wonder , if i would like to add the following things to the package , how will i do it : 1. Time to wait for incoming tone from central office. 2. If Mg initiates the test , time to wait for the returned tone. 3. In some test , it would be needed to send other tone that the one received , if we would like to tell the mg in what tone to respond , how will we do it . Regards , Sholomo From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 06:35:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA05764 for ; Wed, 11 Oct 2000 06:35:43 -0400 (EDT) Received: from standards (47.234.32.16:1553) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1532@standards.nortelnetworks.com>; Wed, 11 Oct 2000 6:18:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45313 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 06:18:47 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA152C@standards.nortelnetworks.com>; Wed, 11 Oct 2000 6:08:46 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA26305 for ; Wed, 11 Oct 2000 06:23:31 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id GAA01661 for ; Wed, 11 Oct 2000 06:23:33 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4MDPNMY7>; Wed, 11 Oct 2000 06:23:31 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C0336C.CD0698A0" Message-ID: <2557DAF4C884D411B16600B0D03ED99E01E1E6@dl-msgusr-02.eu.fore.com> Date: Wed, 11 Oct 2000 06:19:55 -0400 Reply-To: "Mackey, Michael" Sender: "Media Gateway Control (megaco)" From: "Mackey, Michael" Subject: Megaco/H.323 interworking X-cc: "Ries (E-mail)" , "msomers@fore.com (E-mail)" To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C0336C.CD0698A0 Content-Type: text/plain; charset="iso-8859-1" Hi, I wonder if somebody could help me, I have a question about Interworking Megaco/SDP and H.323. In FastStart a sequence of Open Logical Channels are sent as part of a FastStart Element in a H.225.0 Setup. Each of these OLC's has a forwardLogicalChannelNumber. Those that correspond to a channel from the called to the calling endpoint can be ignored (as they are reassigned by the called endpoint). Those that correspond to a channel from the calling to the called must be stored and returned in the FastStart response with the appropriate Open Logical Channel to indicate acceptance of that channel. If we assume one Sdp Descriptor for each Open Logical Channel is sent from an MGC to an MG, and the MG returns a subset of these descriptors ... there is no easy way to quickly correlate the returned Sdp descriptors with the original Open Logical Channels. My initial thought was that maybe the session description (s=) line might be used .... Has anybody else encountered this problem ? Michael Mackey, Marconi Communications, Tel: +353 1 6638407 - www.marconi.com - ------_=_NextPart_001_01C0336C.CD0698A0 Content-Type: text/html; charset="iso-8859-1"
Hi,
    I wonder if somebody could help me, I have a question about Interworking Megaco/SDP and H.323. In FastStart a sequence of Open Logical Channels are sent as part of a FastStart Element in a H.225.0 Setup. Each of these OLC's has a forwardLogicalChannelNumber. Those that correspond to a channel from the called to the calling endpoint can be ignored (as they are reassigned by the called endpoint). Those that correspond to a channel from the calling to the called must be stored and returned in the FastStart response with the appropriate Open Logical Channel to indicate acceptance of that channel.
 
    If we assume one Sdp Descriptor for each Open Logical Channel is sent from an MGC to an MG, and the MG returns a subset of these descriptors ... there is no easy way to quickly correlate the returned Sdp descriptors with the original Open Logical Channels. My initial thought was that maybe the session description (s=) line might be used .... Has anybody else encountered this problem ?
 
Michael Mackey,
Marconi Communications,
Tel: +353 1 6638407
 
------_=_NextPart_001_01C0336C.CD0698A0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 07:34:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA06994 for ; Wed, 11 Oct 2000 07:34:49 -0400 (EDT) Received: from standards (47.234.32.16:1553) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA15F2@standards.nortelnetworks.com>; Wed, 11 Oct 2000 7:17:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45573 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 07:17:48 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA15F1@standards.nortelnetworks.com>; Wed, 11 Oct 2000 7:17:47 -0400 Received: from ms.uab.ericsson.se (ms.uab.ericsson.se [134.138.201.16]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9BBWZZ26763 for ; Wed, 11 Oct 2000 13:32:35 +0200 (MEST) Received: from uabs28 (uabs28 [134.138.228.5]) by ms.uab.ericsson.se (8.10.0/8.10.0/uab-2.26) with ESMTP id e9BBWZn23316 for ; Wed, 11 Oct 2000 13:32:35 +0200 (MET DST) Received: from uab.ericsson.se by uabs28 (8.8.8+Sun/client-1.3uab2) id NAA24115; Wed, 11 Oct 2000 13:32:34 +0200 (MET DST) X-Mailer: Mozilla 4.05 [en] (Win95; I) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------5944B1BE6BA9EAA67203DE9B" Message-ID: <39E44FD2.5CB0BD0E@uab.ericsson.se> Date: Wed, 11 Oct 2000 13:32:34 +0200 Reply-To: Alf Heidermark Sender: "Media Gateway Control (megaco)" From: Alf Heidermark Organization: Ericsson Utvecklings AB Subject: Proper reply To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------5944B1BE6BA9EAA67203DE9B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello In the case eg after a recovery action in the MGC where it lost all contexts and wants to release all fixed termination. If I then send a Subtract request with a wildcarded terminationID, identifying eg a 30 terminations. In this case I use contextID All, since i lost the correct one. What is proper answer from the MG if all the terminations are in the Null context. Will I get a subtract reply with no terminatiom in it ?. Will I get an error descriptor? --------------5944B1BE6BA9EAA67203DE9B Content-Type: text/x-vcard; charset=us-ascii; name="vcard.vcf" Content-Description: Card for Alf Heidermark Content-Disposition: attachment; filename="vcard.vcf" Content-Transfer-Encoding: 7bit begin: vcard fn: Alf Heidermark n: Heidermark;Alf org: Ericsson Core Network product email;internet: Alf.Heidermark@uab.ericsson.se note;quoted-printable:Telphone number +4687273894=0D=0A= Mobile: +46703997883=0D=0A= Address: Armborstv=E4gen 14=0D=0A= =C4lvsj=F6 x-mozilla-cpt: ;0 x-mozilla-html: FALSE version: 2.1 end: vcard --------------5944B1BE6BA9EAA67203DE9B-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 07:57:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07626 for ; Wed, 11 Oct 2000 07:57:42 -0400 (EDT) Received: from standards (47.234.32.16:3668) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA161A@standards.nortelnetworks.com>; Wed, 11 Oct 2000 7:41:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45627 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 07:41:16 -0400 Received: from mink.ecitele.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1619@standards.nortelnetworks.com>; Wed, 11 Oct 2000 7:41:15 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id NAA27811 for ; Wed, 11 Oct 2000 13:54:21 +0200 (IST) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3 (Intl)|21 March 2000) at 11/10/2000 01:55:58 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Wed, 11 Oct 2000 13:50:16 +0300 Reply-To: Shlomo.Kabaz@ECITELE.COM Sender: "Media Gateway Control (megaco)" From: Shlomo Kabaz ECItelecom Subject: packages for terminations To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi , all ! We are developping a trunking gateway . I wonder if someone can tell me what pckages are supposed to be supported on physical terminations and what packages are supposed to be supported on an ephemeral termination in a trunking gateway? Regards , Shlomo . From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 09:26:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10109 for ; Wed, 11 Oct 2000 09:26:31 -0400 (EDT) Received: from standards (47.234.32.16:1181) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1650@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:10:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45699 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 09:10:06 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA164F@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:10:06 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07239; Wed, 11 Oct 2000 09:24:51 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA28910; Wed, 11 Oct 2000 09:24:53 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4MDPNPVC>; Wed, 11 Oct 2000 09:24:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7A7@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 11 Oct 2000 09:24:52 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Add with wildcard termination ID X-To: Chuong Nguyen To: MEGACO@STANDARDS.NORTELNETWORKS.COM I think we have a significant issue to discuss and we might want to think about changing some direction we have already given, although I'm not sure how much text. Up to now, I, and others, have said that you can use a partially wildcarded terminationId in a command such as Add using the ALL construct, thus "abc*". This thread has caused me to wonder if this is wrong, and we should really use CHOOSE, as others have suggested. Here is my thinking: If we interpret ALL as the text states - equivalent to separate commands with each matched terminationID, then "Add=abc*" where abcd and abce existed would be equivalent to "Add=abcd{..., Add=abce{...." If we interpret CHOOSE as the text states - the MG chooses ONE terminationId, then "Add=abc?" could be interpreted by the MG as "Add=abcd" OR "Add=abce", but only one, MG's choice. Given the issues on the thread: You CAN get more than one Add out of a wildcard using ALL You would get an error if one of those matched terminations was OOS You CAN get only one Add of a wildcard using CHOOSE The MG would choose an MG that was In Service if, say, abce was OOS, it would choose abcd if asked to Add=abc? This allows the MGC to decide exactly how it wants partial wildcarded commands to be done. ALL might work well with Audit, CHOOSE might be more appropriate with Add (in most cases anyway). Brian -----Original Message----- From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM] Sent: Tuesday, October 10, 2000 2:26 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Add with wildcard termination ID Section 7.2.1 there is the following statement: "Add SHALL NOT be used on a Termination with a serviceState of "OutofService"." So I assume that MG should return an error on this ADD. Chuong Kevin Boyle wrote: It seems to me that if you can only add one termination per command, then use of the ALL (*) wildcard is not allowed for Add. CHOOSE ($), however, would be acceptable. There are other commands where these kinds of restrictions are already expressed, so why not add one for Add in the Implementer's Guide? It would also seem to me that if a termination is OOS, then adding it is not allowed. Once again, somthing for the Implementer's Guide? Kevin "Rosen, Brian" wrote: > First of all, an Add only can add one termination per command, > so Add=abc* would only add abcd. Pressing on, if, for > example, abcd was already in a context, then the > error would be in $ context, and would indicate no terminations > matched, I suppose. > > We might want to think about whether outofservice really causes > a no terminations matched situation. On the one hand, adding > an out of service termination makes no sense. On the other hand > auditing one does. So does the matching logic work differently > for Audit than it does for Add? I would think it shouldn't, > thus we have a quandry. > > Brian > > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Monday, October 09, 2000 4:13 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Add with wildcard termination ID > > Suppose there are two terminations in MG named "abcd" and "abce" > and MGC sends an ADD as > CtxID=$ ADD TermID=abc* > Now MG is able to create a Context and successfully ADD "abcd" in it, but > ADDing of "abce" fails (say because of "abce" being "outofservice") > > What ContextID will be used in the response for the termination "abce": > 1. $ > 2. The allocated ContextID for "abcd" > > Sachin -- Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 **** The opinions expressed are not those of Alcatel USA, Inc **** From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 09:32:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10325 for ; Wed, 11 Oct 2000 09:32:17 -0400 (EDT) Received: from standards (47.234.32.16:1181) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1672@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:15:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45747 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 09:15:22 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1671@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:15:22 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA07869; Wed, 11 Oct 2000 09:30:07 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA00400; Wed, 11 Oct 2000 09:30:09 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4MDPNPZ6>; Wed, 11 Oct 2000 09:30:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7A8@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 11 Oct 2000 09:30:07 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Notify and Modify on OOS Termination X-To: "chassija@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM >a) Is it possible for MG to detect events and hence generate NOTIFY on an OOS >(Out of Service) termination ? >b) Also, it has not been stated clearly in the protocol as to whether MG should >apply MODIFY command to an OOS termination or it should generate a Protocol >Error. I'd say it is generally okay, and won't generate an error unless the actual request that is being made can't be done (that is, if the MG in fact can detect the event, then why not allow it to do so?). Thus the PROTOCOL should not prohibit it, but an implementation might, or more likely, would under some circumstances. The MGC would have to be prepared to get an error if the MG couldn't do what was asked. Of course it doesn't make much sense to me WHY you would want to do this, but I don't see any reason to prohibit you from trying :) Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 09:36:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10423 for ; Wed, 11 Oct 2000 09:36:30 -0400 (EDT) Received: from standards (47.234.32.16:1181) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1686@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:18:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45774 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 09:18:02 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1685@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:18:01 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08113; Wed, 11 Oct 2000 09:32:46 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01041; Wed, 11 Oct 2000 09:32:47 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4MDPNP7K>; Wed, 11 Oct 2000 09:32:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7A9@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 11 Oct 2000 09:32:43 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Proper reply X-To: Alf Heidermark To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'd think you would get the "no terminations matched" error. Brian > -----Original Message----- > From: Alf Heidermark [mailto:Alf.Heidermark@UAB.ERICSSON.SE] > Sent: Wednesday, October 11, 2000 7:33 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Proper reply > > > Hello > > In the case eg after a recovery action in the MGC where it lost all > contexts and wants to release all fixed termination. If I then send a > Subtract request with a wildcarded terminationID, identifying eg a 30 > terminations. In this case I use contextID All, since i lost > the correct > one. What is proper answer from the MG if all the terminations are in > the Null context. Will I get a subtract reply with no > terminatiom in it > ?. Will I get an error descriptor? > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 09:36:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA10427 for ; Wed, 11 Oct 2000 09:36:31 -0400 (EDT) Received: from standards (47.234.32.16:1181) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA169A@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:20:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45800 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 09:20:58 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1699@standards.nortelnetworks.com>; Wed, 11 Oct 2000 9:20:57 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08359; Wed, 11 Oct 2000 09:35:42 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01799; Wed, 11 Oct 2000 09:35:44 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <440Q8VLT>; Wed, 11 Oct 2000 09:35:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7AA@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 11 Oct 2000 09:35:44 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: packages for terminations X-To: "Shlomo.Kabaz@ECITELE.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM There is nothing in the protocol that defines a trunk gateway, or the packages that one should implement. A profile might do that. As an example, consider: http://www.msforum.org/MSF-MEDIA-002.00-DRAFT_IA.doc Brian > -----Original Message----- > From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM] > Sent: Wednesday, October 11, 2000 6:50 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: packages for terminations > > > Hi , all ! > We are developping a trunking gateway . > I wonder if someone can tell me what pckages are supposed to > be supported > on physical terminations > and what packages are supposed to be supported on an > ephemeral termination > in a trunking gateway? > Regards , Shlomo . > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 10:50:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12129 for ; Wed, 11 Oct 2000 10:50:31 -0400 (EDT) Received: from standards (47.234.32.16:1135) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA17EC@standards.nortelnetworks.com>; Wed, 11 Oct 2000 10:34:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0201 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 10:34:04 -0400 Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA17EA@standards.nortelnetworks.com>; Wed, 11 Oct 2000 10:34:03 -0400 Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id <44ASGM9J>; Wed, 11 Oct 2000 16:47:31 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Message-ID: <81C3E8FE6C0AD4119D49009027C3AAB25DABF2@MAIL-IN> Date: Wed, 11 Oct 2000 16:47:31 +0200 Reply-To: Nurit Shenhar Sender: "Media Gateway Control (megaco)" From: Nurit Shenhar Subject: Duplicate Token To: MEGACO@STANDARDS.NORTELNETWORKS.COM My problem is: I have bumped into the following old problem : > -----Original Message----- > From: Shiv Kumar [mailto:svkumar@HSS.HNS.COM] > Sent: Thursday, July 06, 2000 3:03 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Duplicate Token > > > Hi, > > A small correction in the abbreviated tokens list. > > The token "EB" is used for both EmbedToken and EventBufferToken. > Pls correct it. ........... > > Regards, > Shiv > Brain Rosen answered: "I can't see why this was done, but assuming there is a good reason, the best idea I have is to make Emergency "EMG" and then make Embed "EM" " ************************************************************* Anyway , the problem wasn't fixed in the August 2000 RFC, & I think that a better solution would be to make Embed "ED" , because none of the tokens has 3 letters. Thanks in advance, -- Rakefet Prozan, Team Manager, S/W Development ATS SBU Telrad Networks ESN 828-3043 Email:rakefet.prozan@telrad.co.il """ -(o o)- +---------------------------------oOO--(_)--OOo--------------+ .oooO Oooo. -------------------------------( )---------( )------------ \ ( ) / \_) (_/ Have fun !!! From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 12:12:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14098 for ; Wed, 11 Oct 2000 12:12:32 -0400 (EDT) Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1853@standards.nortelnetworks.com>; Wed, 11 Oct 2000 11:56:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0164 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 11:56:03 -0400 Received: from mink.ecitele.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1852@standards.nortelnetworks.com>; Wed, 11 Oct 2000 11:56:02 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id SAA24354 for ; Wed, 11 Oct 2000 18:09:51 +0200 (IST) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3 (Intl)|21 March 2000) at 11/10/2000 06:11:27 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Wed, 11 Oct 2000 18:05:49 +0300 Reply-To: Shlomo.Kabaz@ECITELE.COM Sender: "Media Gateway Control (megaco)" From: Shlomo Kabaz ECItelecom Subject: audit value command To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi , all ! If in auditValue command i am giving context=All and termination=wildcard , am i getting in the reply only ephemeral terminations in their contexts or that physical terminations in these contexts will be reported tow? Thanks , Shlomo . From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 12:16:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14213 for ; Wed, 11 Oct 2000 12:16:49 -0400 (EDT) Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA186A@standards.nortelnetworks.com>; Wed, 11 Oct 2000 12:00:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0115 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 12:00:07 -0400 Received: from mail.tduk.com (195.13.87.121:1365) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1829@standards.nortelnetworks.com>; Wed, 11 Oct 2000 11:49:56 -0400 Received: from Holly (ci85.32.reading.uk.psi.net [154.32.32.85] (may be forged)) by mail.tduk.com (8.9.3/8.9.3) with SMTP id PAA06050 for ; Wed, 11 Oct 2000 15:31:45 GMT MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: Date: Wed, 11 Oct 2000 17:06:13 +0100 Reply-To: Peter Grant Sender: "Media Gateway Control (megaco)" From: Peter Grant Subject: M3UA Common Message Header To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear All, I have a query regarding the latest version (4) of M3UA. There is a discrepancy between the definition of the Message Length in the Common Message Header. Version 3 describes the Message Length as being: Message Length: 32-bits (unsigned integer) The Message Length defines the length of the message in octets, not including the header. However, Version 4 describe the Message Length thus: Message Length: 32-bits (unsigned integer) The Message Length defines the length of the message in octets, including the header. Is it just a typing error, or has the definition of the Message Length actually changed? Having recently written decode for the entire protocol (just before the latest version came out) I would appreciate it if you could confirm my fears that my decode is now slightly wrong. Peter Grant Software Engineer, Test Tools Division, Telesoft Technologies Ltd. Phone: +44 (0)1258 480880 Direct: +44 (0)1258 486574 email: pgrant@telesoft-technologies.com www: www.telesoft-technologies.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 12:48:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA14905 for ; Wed, 11 Oct 2000 12:48:09 -0400 (EDT) Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA18AA@standards.nortelnetworks.com>; Wed, 11 Oct 2000 12:31:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0272 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 12:31:39 -0400 Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA18A5@standards.nortelnetworks.com>; Wed, 11 Oct 2000 12:21:39 -0400 Message-ID: Date: Wed, 11 Oct 2000 12:21:39 -0400 Reply-To: M Kottanipral Sender: "Media Gateway Control (megaco)" From: M Kottanipral Subject: ISDN PRI To: MEGACO@STANDARDS.NORTELNETWORKS.COM Are they any MEGACO Call Flows for ISDN PRI available ? Thanks M Kottanipral From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 13:41:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16033 for ; Wed, 11 Oct 2000 13:41:22 -0400 (EDT) Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA18F5@standards.nortelnetworks.com>; Wed, 11 Oct 2000 13:24:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0372 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 13:24:44 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA18F4@standards.nortelnetworks.com>; Wed, 11 Oct 2000 13:24:44 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04303; Wed, 11 Oct 2000 13:39:31 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08014; Wed, 11 Oct 2000 13:39:32 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4MDPNX06>; Wed, 11 Oct 2000 13:39:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7BB@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 11 Oct 2000 13:39:31 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ISDN PRI X-To: M Kottanipral To: MEGACO@STANDARDS.NORTELNETWORKS.COM Not that I know of. Of course, from the Megaco point of view, they would not look much different from any other call flow, as the signalling mechanism is outside of the scope of Megaco, so all you see in the Megaco signalling is the Add, Modify,... Subtract. You would not see any hookswitch events, and you would not see much of the signalling (announcements would be done the same way as an analog line, as would ringback, for example, but ring would not be visible at the Megaco level. We should do this, of course. Brian > -----Original Message----- > From: M Kottanipral [mailto:mkottanipral@HOTMAIL.COM] > Sent: Wednesday, October 11, 2000 12:22 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ISDN PRI > > > Are they any MEGACO Call Flows for ISDN PRI available ? > > Thanks > M Kottanipral > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 13:41:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16037 for ; Wed, 11 Oct 2000 13:41:23 -0400 (EDT) Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1901@standards.nortelnetworks.com>; Wed, 11 Oct 2000 13:25:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0387 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 13:25:38 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1900@standards.nortelnetworks.com>; Wed, 11 Oct 2000 13:25:37 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04426; Wed, 11 Oct 2000 13:40:24 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08198; Wed, 11 Oct 2000 13:40:25 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4MDPNYAQ>; Wed, 11 Oct 2000 13:40:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7BC@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 11 Oct 2000 13:40:24 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: M3UA Common Message Header X-To: Peter Grant To: MEGACO@STANDARDS.NORTELNETWORKS.COM Wong email list! You wanted sigtran@standards.nortelnetworks.com, not megaco@standards.nortelnetworks.com > -----Original Message----- > From: Peter Grant [mailto:pgrant@TELESOFT-TECHNOLOGIES.COM] > Sent: Wednesday, October 11, 2000 12:06 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: M3UA Common Message Header > > > Dear All, > > I have a query regarding the latest version (4) of M3UA. There is a > discrepancy between the definition of the Message Length in the Common > Message Header. > > Version 3 describes the Message Length as being: > > Message Length: 32-bits (unsigned integer) > > The Message Length defines the length of the > message in octets, not > including the header. > > > However, Version 4 describe the Message Length thus: > > Message Length: 32-bits (unsigned integer) > > The Message Length defines the length of the > message in octets, > including the header. > > > Is it just a typing error, or has the definition of the Message Length > actually changed? > > Having recently written decode for the entire protocol (just > before the > latest version came out) I would appreciate it if you could > confirm my fears > that my decode is now slightly wrong. > > Peter Grant > Software Engineer, > Test Tools Division, > Telesoft Technologies Ltd. > > Phone: +44 (0)1258 480880 > Direct: +44 (0)1258 486574 > email: pgrant@telesoft-technologies.com > www: www.telesoft-technologies.com > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 13:41:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16046 for ; Wed, 11 Oct 2000 13:41:24 -0400 (EDT) Received: from standards (47.234.32.16:1176) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA190B@standards.nortelnetworks.com>; Wed, 11 Oct 2000 13:26:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0400 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 13:26:33 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA190A@standards.nortelnetworks.com>; Wed, 11 Oct 2000 13:26:33 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA04558; Wed, 11 Oct 2000 13:41:20 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08357; Wed, 11 Oct 2000 13:41:21 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <440Q87MR>; Wed, 11 Oct 2000 13:41:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7BD@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 11 Oct 2000 13:41:21 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: audit value command X-To: "Shlomo.Kabaz@ECITELE.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM You get all terminations, except those in NULL context. Brian > -----Original Message----- > From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM] > Sent: Wednesday, October 11, 2000 11:06 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: audit value command > > > Hi , all ! > > If in auditValue command i am giving context=All and > termination=wildcard , > am i getting in the reply only ephemeral terminations in > their contexts or > that physical > terminations in these contexts will be reported tow? > > Thanks , Shlomo . > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 14:42:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA17748 for ; Wed, 11 Oct 2000 14:42:00 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1B24@standards.nortelnetworks.com>; Wed, 11 Oct 2000 14:23:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 0599 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 14:23:40 -0400 Received: from qhars002.nortel.com (47.101.112.102:40115) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1B23@standards.nortelnetworks.com>; Wed, 11 Oct 2000 14:23:40 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Wed, 11 Oct 2000 19:38:02 +0100 Received: from zrchb200.us.nortel.com (actually zrchb200) by smtprch1.nortel.com; Wed, 11 Oct 2000 13:05:49 -0500 Received: from zrtpd00x.us.nortel.com ([47.140.202.32]) by zrchb200.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4VMC8MT3; Wed, 11 Oct 2000 13:05:37 -0500 Received: from americasm01.nt.com (brtphe34.us.nortel.com [47.202.35.89]) by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id 4L9BLPKL; Wed, 11 Oct 2000 14:05:35 -0400 X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/778) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E7BD@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E4ABEF.7020B7A@americasm01.nt.com> Date: Wed, 11 Oct 2000 14:05:36 -0400 Reply-To: Kevin Boyle Sender: "Media Gateway Control (megaco)" From: Kevin Boyle Organization: Nortel Networks Subject: Re: audit value command X-To: Shlomo.Kabaz@ECITELE.COM, Brian.Rosen@MARCONI.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Well, you'd get all the terminations that match the wildcard that aren't in the NULL context. I would like to point out, at the expense of possibly stating the obvious, that there are TWO wildcards: ALL (*) and CHOOSE ($). From many of the questions I've seen float by, there does seem to be some misunderstanding or unawareness of this. If you say you're wildcarding a termination name, there could be two outcomes: abc* matches any termination name that starts with abc abc$ matches ONE termination name that starts with abc -- which one is at the GW's discretion. I think it is very important to highlight this fact. The question posed below is a case in point. The question seems to imply that the wildcard in question is ALL, but it is not stated that way -- which could lead to confusion in the understanding of the question, and the statement of the answer. I just thought I'd try to clarify this for those new to these constructs. I can see all kinds of confusion possibly coming out of this, and that really wouldn't be terribly constructive for anyone -- or for Megaco, for that matter. Kevin "Rosen, Brian" wrote: > You get all terminations, except those in NULL context. > > Brian > > > -----Original Message----- > > From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM] > > Sent: Wednesday, October 11, 2000 11:06 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: audit value command > > > > > > Hi , all ! > > > > If in auditValue command i am giving context=All and > > termination=wildcard , > > am i getting in the reply only ephemeral terminations in > > their contexts or > > that physical > > terminations in these contexts will be reported tow? > > > > Thanks , Shlomo . > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 16:54:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA21530 for ; Wed, 11 Oct 2000 16:54:54 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1E75@standards.nortelnetworks.com>; Wed, 11 Oct 2000 16:38:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1470 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 16:38:13 -0400 Received: from sesame.sitemaker.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1DD7@standards.nortelnetworks.com>; Wed, 11 Oct 2000 16:28:12 -0400 Received: by sesame.sitemaker.com (5.65/DEC-Ultrix/4.3) id AA25601; Wed, 11 Oct 2000 13:36:49 -0700 Received: from 63.22.138.65 by datastre-5o7vdq with ESMTP; Wed, 11 Oct 2000 16:31:48 -0400 Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-Msmail-Priority: Normal Message-ID: <0000255235da$00006b0d$00000309@63.22.138.65> Date: Wed, 11 Oct 2000 16:31:48 -0400 Reply-To: gutdr509@EARTHLINK.NET Sender: "Media Gateway Control (megaco)" From: gutdr509@EARTHLINK.NET Subject: Check out the latest Wall Street Merger 777 X-To: "Undisclosed Recipients"@earthlink.net To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: quoted-printable The stock GOLX has penetrated the Telecommunications a= nd Internet market of India. This newly trading Company is the world's fir= st digital conglomerate with its high-speed broadband network, it is the m= ost comprehensive set of services available on the Internet today. Find ou= t why Global Crossing, Seimans, Nokia, MCI Worldcom, Phillips, has an inte= rest in GOLX...

Come Learn More
http://www.golx3.com4.ws/golx/




You were se= nt this message because your address is in our subscriber database. If you= wish to be removed, please reply here; http://www.golx3.com4.ws/golx/response.html and we will rem= ove you from our subscriber list. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 11 17:54:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA22633 for ; Wed, 11 Oct 2000 17:54:21 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1F52@standards.nortelnetworks.com>; Wed, 11 Oct 2000 17:38:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 1939 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 11 Oct 2000 17:38:12 -0400 Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA1F47@standards.nortelnetworks.com>; Wed, 11 Oct 2000 17:28:11 -0400 Message-ID: Date: Wed, 11 Oct 2000 17:28:11 -0400 Reply-To: M Kottanipral Sender: "Media Gateway Control (megaco)" From: M Kottanipral Subject: Re: ISDN PRI X-To: Brian.Rosen@MARCONI.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello - Is there any ISDN Package defined for MEGACO ? Probably similar to other packages defined in MEGACO like Analog line package . Any pointers to something similar would be appreciated Thanks From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 02:09:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA13166 for ; Thu, 12 Oct 2000 02:09:15 -0400 (EDT) Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA22A9@standards.nortelnetworks.com>; Thu, 12 Oct 2000 1:52:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3058 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 01:52:03 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA22A0@standards.nortelnetworks.com>; Thu, 12 Oct 2000 1:42:02 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9C5upt25925; Thu, 12 Oct 2000 07:56:51 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id HAA26827; Thu, 12 Oct 2000 07:56:51 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA15069; Thu, 12 Oct 2000 07:56:48 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E767@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E52058.E91465E7@ericsson.com> Date: Thu, 12 Oct 2000 13:22:16 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: auditing when everything is in th NULL context X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, I think its a mix of your first possibility and provisioning. Typically the first actions will create the stream unless it is previously provisioned on the MG. Cheers, Christian Cheers, Christian "Rosen, Brian" wrote: > > > I wonder , when all terminations are in the NULL context > > what should be > > replied in the localControlDescriptor in the > > StreamMode , is it just not present in this descriptor ? > > Secondly , i wonder what are the properties that are replied > > in the local > > control descriptor ? > > Hmmm, excellent question. The root of the question is, "are there > any streams active for a termination in Null Context?" There is a > somewhat wider question which is "do streams have to be explicitly > created before any stream-dependent properties/events/signals can > be audited?" The latter leads to the question "when is a stream > created?" > > I just posted an answer to a list question that used an example of > applying a signal (dialtone) to a termination which was in the > null context. If that is legal, then streams CAN be active on > a termination in the null context. We get back to when is the > stream created? I don't recall any discussion on this point. > > I think there are two possibilities: > The first action that creates media (be it a Media/Local/Remote > descriptor, or a signal, creates a media stream, and > a Subtract, or a properly constructed Media/Local/Remote > descriptor deletes streams. This implies that there > are no streams active on a termination in null context > after boot, or after a subtract, but you create one by > putting media on the termination. > There is always a default StreamId=1 stream, others are created > by a Media descriptor, and deleted by a Media Descriptor > or Subtract. > > I'd favor the former, but don't think there is very much practical > difference except the exact question you asked. If there are no streams > at some times then if you audited, you would never get a LocalControl, > nor a StreamMode when there was not a stream, and you would when there > was. If there are always streams with StreamId=1, then you do get > StreamMode, and you also get a LocalControl descriptor. > > The second question you ask is easier to answer. If there are any > properties defined in LocalControl for packages implemented on a > termination, then those values are returned in LocalControl for active > streams. "Active" is the issue, as discussed above. > > Need more opinions I think. Maybe this was settled, and I just > don't remember how. > > Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 02:09:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA13169 for ; Thu, 12 Oct 2000 02:09:15 -0400 (EDT) Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA22AF@standards.nortelnetworks.com>; Thu, 12 Oct 2000 1:52:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3059 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 01:52:10 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA22A1@standards.nortelnetworks.com>; Thu, 12 Oct 2000 1:42:10 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9C5uvZ08341; Thu, 12 Oct 2000 07:56:57 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id HAA26831; Thu, 12 Oct 2000 07:56:56 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA15073; Thu, 12 Oct 2000 07:56:53 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <353093573B82D411889E0000F808216648E3D0@zcard00q.ca.nortel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E520E6.59CA4342@ericsson.com> Date: Thu, 12 Oct 2000 13:24:38 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Audit of packages X-To: Peter Blatherwick X-cc: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Perhaps we "should" say "SHALL", I can't think of a case of when it is inappropriate and we have the rule saying that you can address properties by pkg3. But, I'm happy with Should if you can provide the text when it is inappropriate. Cheers, Christian Peter Blatherwick wrote: > > I agree in general, since "extends" basically means "clone the base > package and add some more functionality" (no subsetting, over-riding > etc allowed). In example below pkg2 by definition implements pkg3. > (Not the case with re-versioning of Packages though!) > > One clarification however. It does not always make sense for a base > package to be published as implemented by an MG. There are examples > where the base package is defined such that it acts similar to a > virtual class, and has no function on its own, simply defining > interface for one or more derived packages. Annex E ToneGen and > ToneDet as well as a few packages in Annex G are examples. Therefore, > implementer's guide MUST not make a hard and fast rule on this, but > SHOULD say "SHOULD" with some words to describe where its > inappropriate. > > -- Peter > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Monday, October 09, 2000 16:03 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > We've been around this and basically, it is up to the MG. > It does not HAVE to report pkg3, but it could. Maybe SHOULD > is a good word, and I wonder if text to that effect > should go in the implementor's guide? > > Brian > > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Monday, October 09, 2000 5:12 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Audit of packages > > Say a termination abc implements the following packages: > 1. pkg1 > 2. pkg2 > where pkg2 extends pkg3 and pkg1 doesn't extend any other package > > If this termination is audited for packages implemented on it, > should the reply include pkg3 with pkg1 and pkg2 (base package names > are included) > > Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 02:09:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA13179 for ; Thu, 12 Oct 2000 02:09:16 -0400 (EDT) Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA22B9@standards.nortelnetworks.com>; Thu, 12 Oct 2000 1:52:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3060 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 01:52:55 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA22A2@standards.nortelnetworks.com>; Thu, 12 Oct 2000 1:42:54 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9C5vht26087; Thu, 12 Oct 2000 07:57:43 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id HAA26864; Thu, 12 Oct 2000 07:57:42 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id HAA15105; Thu, 12 Oct 2000 07:57:39 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E7A7@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E535E0.E00888F8@ericsson.com> Date: Thu, 12 Oct 2000 14:54:08 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Add with wildcard termination ID X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day All, I believe currently in the specification we have with reference to the terminationID: o Add with Choose "?" is valid and return 1 termination o Add with Specific is valid as it adds a specific termination. o Add with * is allowed as it adds per 7.2.1 1st para. o In the other commands then only specific or * is allowed. Given the current text it states that all matching terminations are attempted and results for each one are reported. That result could be OOS, termination ID is already in a context etc. Choung provided the clarification that OOS terminations can't be added. I must be missing something, where is the problem? What do we gain/loose if we remove the possibility of ADD with *? (To effect this change then I see we only need to update 7.2.1 1st paragraph). Cheers, Christian "Rosen, Brian" wrote: > > I think we have a significant issue to discuss and we might want > to think about changing some direction we have already given, > although I'm not sure how much text. > > Up to now, I, and others, have said that you can use a partially > wildcarded terminationId in a command such as Add using the ALL > construct, thus "abc*". > > This thread has caused me to wonder if this is wrong, and we > should really use CHOOSE, as others have suggested. Here is my thinking: > > If we interpret ALL as the text states - equivalent to separate commands > with each matched terminationID, then "Add=abc*" where abcd and abce existed > would be equivalent to "Add=abcd{..., Add=abce{...." > > If we interpret CHOOSE as the text states - the MG chooses ONE > terminationId, > then "Add=abc?" could be interpreted by the MG as "Add=abcd" OR "Add=abce", > but only one, MG's choice. > > Given the issues on the thread: > > You CAN get more than one Add out of a wildcard using ALL > You would get an error if one of those matched terminations was OOS > You CAN get only one Add of a wildcard using CHOOSE > The MG would choose an MG that was In Service if, say, abce was OOS, it > would choose abcd if asked to Add=abc? > > This allows the MGC to decide exactly how it wants partial wildcarded > commands to be done. ALL might work well with Audit, CHOOSE might be > more appropriate with Add (in most cases anyway). > > Brian > > -----Original Message----- > From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM] > Sent: Tuesday, October 10, 2000 2:26 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Add with wildcard termination ID > > Section 7.2.1 there is the following statement: > "Add SHALL NOT be used on a Termination with a serviceState of > "OutofService"." > So I assume that MG should return an error on this ADD. > Chuong > > Kevin Boyle wrote: > It seems to me that if you can only add one termination per command, then > use of the ALL (*) wildcard is not allowed for Add. CHOOSE ($), however, > would be acceptable. There are other commands where these kinds of > restrictions are already expressed, so why not add one for Add in the > Implementer's Guide? > It would also seem to me that if a termination is OOS, then adding it is not > > allowed. Once again, somthing for the Implementer's Guide? > Kevin > "Rosen, Brian" wrote: > > First of all, an Add only can add one termination per command, > > so Add=abc* would only add abcd. Pressing on, if, for > > example, abcd was already in a context, then the > > error would be in $ context, and would indicate no terminations > > matched, I suppose. > > > > We might want to think about whether outofservice really causes > > a no terminations matched situation. On the one hand, adding > > an out of service termination makes no sense. On the other hand > > auditing one does. So does the matching logic work differently > > for Audit than it does for Add? I would think it shouldn't, > > thus we have a quandry. > > > > Brian > > > > -----Original Message----- > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > Sent: Monday, October 09, 2000 4:13 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Add with wildcard termination ID > > > > Suppose there are two terminations in MG named "abcd" and "abce" > > and MGC sends an ADD as > > CtxID=$ ADD TermID=abc* > > Now MG is able to create a Context and successfully ADD "abcd" in it, but > > ADDing of "abce" fails (say because of "abce" being "outofservice") > > > > What ContextID will be used in the response for the termination "abce": > > 1. $ > > 2. The allocated ContextID for "abcd" > > > > Sachin > -- > Alcatel USA, Inc Internet: Chuong.Nguyen@usa.alcatel.com > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > **** The opinions expressed are not those of Alcatel USA, Inc **** From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 03:30:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA13659 for ; Thu, 12 Oct 2000 03:30:01 -0400 (EDT) Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2428@standards.nortelnetworks.com>; Thu, 12 Oct 2000 3:13:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3569 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 03:13:03 -0400 Received: from mars.hss.co.in (202.54.26.197:45270) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2427@standards.nortelnetworks.com>; Thu, 12 Oct 2000 3:13:01 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9C7SVC16689 for ; Thu, 12 Oct 2000 12:58:32 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256976.00280526 ; Thu, 12 Oct 2000 12:47:07 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256976.002802FA.00@sandesh.hss.hns.com> Date: Thu, 12 Oct 2000 12:52:31 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: ServiceState of a termination To: MEGACO@STANDARDS.NORTELNETWORKS.COM Is the changing of ServiceState of a termination directly from inservice to outofservice and vice-versa allowed in say a Modify. Is this equivalent in functional operation to a ServiceChange on that termination. I believe that the ServiceState values outofservice and inservice are not settable directly my MGC and only indicate the current state that can be modified using SerivceChange. This seems to make ServiceState property as "read-only" type for these two values. But then what about "test" value ? Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 04:21:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA13986 for ; Thu, 12 Oct 2000 04:21:35 -0400 (EDT) Received: from standards (47.234.32.16:2406) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA24C1@standards.nortelnetworks.com>; Thu, 12 Oct 2000 4:05:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3759 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 04:05:08 -0400 Received: from mailgate.sbell.com.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA24BB@standards.nortelnetworks.com>; Thu, 12 Oct 2000 3:55:06 -0400 Received: from bellnet-mail3.sbell.com.cn (bellnet-mail3.sbell.com.cn [202.96.203.172]) by mailgate.sbell.com.cn (8.9.2/8.9.2) with ESMTP id QAA22608 for ; Thu, 12 Oct 2000 16:01:44 +0800 (CST) Received: by bellnet-mail3.sbell.com.cn with Internet Mail Service (5.5.2650.21) id <4BG6C8G6>; Thu, 12 Oct 2000 16:10:24 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="GB2312" Message-ID: <77D4835D5290D111B8CC00805FE6AAD504803D8C@bellnet-mail1.sbell.com.cn> Date: Thu, 12 Oct 2000 16:06:15 +0800 Reply-To: SRD Tian YaMin Sender: "Media Gateway Control (megaco)" From: SRD Tian YaMin Subject: ROOT termination To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA13986 Hello, I need someone to verify my understandings: When an unknown MG first registers to a MGC, in principle , it must register each termination with a ServiceChange to make the MGC be aware of their existence, But to reduce the network traffic, wildcard TerminationId is necessary, and the wildcards must be carefully constructed to let the MGC know the exact termination set on the MG, and it¡¯s not right to use Root termination in this case. Am I right? Thanks a lot if somebody can help me. Best regards Tian Yamin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 05:50:46 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17205 for ; Thu, 12 Oct 2000 05:50:45 -0400 (EDT) Received: from standards (47.234.32.16:1896) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2521@standards.nortelnetworks.com>; Thu, 12 Oct 2000 5:33:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 3890 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 05:33:19 -0400 Received: from mars.hss.co.in (202.54.26.197:47298) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2520@standards.nortelnetworks.com>; Thu, 12 Oct 2000 5:33:16 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9C9meC20320 for ; Thu, 12 Oct 2000 15:18:41 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256976.0034DB00 ; Thu, 12 Oct 2000 15:07:19 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256976.0034D9A1.00@sandesh.hss.hns.com> Date: Thu, 12 Oct 2000 15:12:43 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Digitmap definition override To: MEGACO@STANDARDS.NORTELNETWORKS.COM The text says that a digitmap once defined can be overriden with a new definition. But if the digitmap is defined by management action outside the scope of MGC, can MGC override that with a definition of it's own. Also say there are terminations: 1. aaab 2. aaac 3. aabd 4. aabe And the same digitmap name is used to define digitmaps on aaa* and aab* with different definitions. Is it allowed ? What if some terminations belong to both the wildcarded names used in such definitions. Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 07:04:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19808 for ; Thu, 12 Oct 2000 07:04:30 -0400 (EDT) Received: from standards (47.234.32.16:4434) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA25F0@standards.nortelnetworks.com>; Thu, 12 Oct 2000 6:47:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4131 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 06:47:52 -0400 Received: from tama5.ecl.ntt.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA25E1@standards.nortelnetworks.com>; Thu, 12 Oct 2000 6:37:51 -0400 Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id TAA25791 for ; Thu, 12 Oct 2000 19:52:41 +0900 (JST) (envelope-from yamamoto.susumu@lab.ntt.co.jp) Received: from imb.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id TAA03208 for ; Thu, 12 Oct 2000 19:52:40 +0900 (JST) (envelope-from yamamoto.susumu@lab.ntt.co.jp) Received: from nesoug-host26 ([129.60.11.38]) by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id TAA22206 for ; Thu, 12 Oct 2000 19:52:39 +0900 (JST) X-Sender: sy001@imb.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.0.58.J.20001012193528.00bad740@imb.m.ecl.ntt.co.jp> Date: Thu, 12 Oct 2000 20:00:48 +0900 Reply-To: yamamoto.susumu@lab.ntt.co.jp Sender: "Media Gateway Control (megaco)" From: Susumu YAMAMOTO Subject: heart beat message in the megaco protocol To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all, Is there a heart beat message from MG to MGC in the megaco protocol? If not, how do you think about a heart beat message? I think MG always should be able to detect a failure of MGC and restore the service by failover method, because the case of restart of MGC, MGC may lost which MG is now in service and cannot send a handoff message properly. Thanks in advance, -*-*-* YAMAMOTO SUSUMU Mega-media Network Systems Project NTT Network Service Systems Laboratories mailto: yamamoto.susumu@lab.ntt.co.jp TEL:+81 422 59 2744 FAX:+81 422 37 7467 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 10:18:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA26481 for ; Thu, 12 Oct 2000 10:18:47 -0400 (EDT) Received: from standards (47.234.32.16:2166) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA287D@standards.nortelnetworks.com>; Thu, 12 Oct 2000 10:02:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 4944 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 10:02:08 -0400 Received: from slink12.ss7-link.com (mail.ss7-link.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA287C@standards.nortelnetworks.com>; Thu, 12 Oct 2000 10:02:06 -0400 Received: by SLINK12 with Internet Mail Service (5.5.2650.21) id <4KWBWWS8>; Thu, 12 Oct 2000 10:14:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 12 Oct 2000 10:14:17 -0400 Reply-To: Dave Sclarsky Sender: "Media Gateway Control (megaco)" From: Dave Sclarsky Subject: Re: Audit of packages X-To: Christian Groves X-cc: img To: MEGACO@STANDARDS.NORTELNETWORKS.COM What do you think about the case where an MG can support pkg2 but NOT pkg3? Take the case of the Tone Detection Package and the DTMF Detection Package that extends it. There are most certainly 'intelligent' devices that are capable of reporting DTMF digits, but do not offer the granularity to report 'Start tone' or 'End tone' detected. I would have assumed that an MG with such a device would (should!) publish dd but not tonedet, because it really cannot notify tonedet/std or tonedet/etd. DaveS. -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Wednesday, October 11, 2000 10:25 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > Perhaps we "should" say "SHALL", I can't think of a case of when it is > inappropriate and we have the rule saying that you can address > properties by pkg3. > > But, I'm happy with Should if you can provide the text when it is > inappropriate. > > Cheers, Christian > > Peter Blatherwick wrote: -------------------------- > > I agree in general, since "extends" basically means "clone the base > package and add some more functionality" (no subsetting, over-riding > etc allowed). In example below pkg2 by definition implements pkg3. > (Not the case with re-versioning of Packages though!) > > One clarification however. It does not always make sense for a base > package to be published as implemented by an MG. There are examples > where the base package is defined such that it acts similar to a > virtual class, and has no function on its own, simply defining > interface for one or more derived packages. Annex E ToneGen and > ToneDet as well as a few packages in Annex G are examples. Therefore, > implementer's guide MUST not make a hard and fast rule on this, but > SHOULD say "SHOULD" with some words to describe where its > inappropriate. > > -- Peter > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Monday, October 09, 2000 16:03 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > We've been around this and basically, it is up to the MG. > It does not HAVE to report pkg3, but it could. Maybe SHOULD > is a good word, and I wonder if text to that effect > should go in the implementor's guide? > > Brian > > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Monday, October 09, 2000 5:12 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Audit of packages > > Say a termination abc implements the following packages: > 1. pkg1 > 2. pkg2 > where pkg2 extends pkg3 and pkg1 doesn't extend any other package > > If this termination is audited for packages implemented on it, > should the reply include pkg3 with pkg1 and pkg2 (base package names > are included) > > Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 10:48:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA27374 for ; Thu, 12 Oct 2000 10:48:42 -0400 (EDT) Received: from standards (47.234.32.16:2166) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA28EC@standards.nortelnetworks.com>; Thu, 12 Oct 2000 10:25:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5084 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 10:25:30 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA28EB@standards.nortelnetworks.com>; Thu, 12 Oct 2000 10:25:29 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA21481; Thu, 12 Oct 2000 10:40:19 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18079; Thu, 12 Oct 2000 10:40:21 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <440Q93S0>; Thu, 12 Oct 2000 10:40:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7CC@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 12 Oct 2000 10:40:19 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Add with wildcard termination ID X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Maybe I was the dense one. I didn't think we needed to update the text, just the nonsense I was spouting. I don't think Add=abc* is all that useful. Maybe we should leave it as it is and change in in CS2, but I could also support removing the restriction. Some more explanations, possibly with examples in the Implementer's Guide would be nice. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Wednesday, October 11, 2000 11:54 PM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Add with wildcard termination ID > > > G'Day All, > > I believe currently in the specification we have with reference to the > terminationID: > o Add with Choose "?" is valid and return 1 termination > o Add with Specific is valid as it adds a specific termination. > o Add with * is allowed as it adds per 7.2.1 1st para. > o In the other commands then only specific or * is allowed. > > Given the current text it states that all matching terminations are > attempted and results for each one are reported. That result could be > OOS, termination ID is already in a context etc. > Choung provided the clarification that OOS terminations can't > be added. > > I must be missing something, where is the problem? > > What do we gain/loose if we remove the possibility of ADD with *? (To > effect this change then I see we only need to update 7.2.1 1st > paragraph). > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > I think we have a significant issue to discuss and we might want > > to think about changing some direction we have already given, > > although I'm not sure how much text. > > > > Up to now, I, and others, have said that you can use a partially > > wildcarded terminationId in a command such as Add using the ALL > > construct, thus "abc*". > > > > This thread has caused me to wonder if this is wrong, and we > > should really use CHOOSE, as others have suggested. Here > is my thinking: > > > > If we interpret ALL as the text states - equivalent to > separate commands > > with each matched terminationID, then "Add=abc*" where abcd > and abce existed > > would be equivalent to "Add=abcd{..., Add=abce{...." > > > > If we interpret CHOOSE as the text states - the MG chooses ONE > > terminationId, > > then "Add=abc?" could be interpreted by the MG as > "Add=abcd" OR "Add=abce", > > but only one, MG's choice. > > > > Given the issues on the thread: > > > > You CAN get more than one Add out of a wildcard using ALL > > You would get an error if one of those matched > terminations was OOS > > You CAN get only one Add of a wildcard using CHOOSE > > The MG would choose an MG that was In Service if, say, > abce was OOS, it > > would choose abcd if asked to Add=abc? > > > > This allows the MGC to decide exactly how it wants partial > wildcarded > > commands to be done. ALL might work well with Audit, > CHOOSE might be > > more appropriate with Add (in most cases anyway). > > > > Brian > > > > -----Original Message----- > > From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM] > > Sent: Tuesday, October 10, 2000 2:26 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Add with wildcard termination ID > > > > Section 7.2.1 there is the following statement: > > "Add SHALL NOT be used on a Termination with a serviceState of > > "OutofService"." > > So I assume that MG should return an error on this ADD. > > Chuong > > > > Kevin Boyle wrote: > > It seems to me that if you can only add one termination per > command, then > > use of the ALL (*) wildcard is not allowed for Add. CHOOSE > ($), however, > > would be acceptable. There are other commands where these kinds of > > restrictions are already expressed, so why not add one for > Add in the > > Implementer's Guide? > > It would also seem to me that if a termination is OOS, then > adding it is not > > > > allowed. Once again, somthing for the Implementer's Guide? > > Kevin > > "Rosen, Brian" wrote: > > > First of all, an Add only can add one termination per command, > > > so Add=abc* would only add abcd. Pressing on, if, for > > > example, abcd was already in a context, then the > > > error would be in $ context, and would indicate no terminations > > > matched, I suppose. > > > > > > We might want to think about whether outofservice really causes > > > a no terminations matched situation. On the one hand, adding > > > an out of service termination makes no sense. On the other hand > > > auditing one does. So does the matching logic work differently > > > for Audit than it does for Add? I would think it shouldn't, > > > thus we have a quandry. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > > Sent: Monday, October 09, 2000 4:13 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Add with wildcard termination ID > > > > > > Suppose there are two terminations in MG named "abcd" and "abce" > > > and MGC sends an ADD as > > > CtxID=$ ADD TermID=abc* > > > Now MG is able to create a Context and successfully ADD > "abcd" in it, but > > > ADDing of "abce" fails (say because of "abce" being > "outofservice") > > > > > > What ContextID will be used in the response for the > termination "abce": > > > 1. $ > > > 2. The allocated ContextID for "abcd" > > > > > > Sachin > > -- > > Alcatel USA, Inc Internet: > Chuong.Nguyen@usa.alcatel.com > > 1000 Coit Road Plano, Texas 75075 Phone: > (972) 519-4613 > > **** The opinions expressed are not those of Alcatel USA, Inc **** > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 11:59:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA00881 for ; Thu, 12 Oct 2000 11:59:36 -0400 (EDT) Received: from standards (47.234.32.16:1103) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2B16@standards.nortelnetworks.com>; Thu, 12 Oct 2000 11:43:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5672 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 11:43:09 -0400 Received: from ind.alcatel.com (postal.xylan.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2B0F@standards.nortelnetworks.com>; Thu, 12 Oct 2000 11:33:09 -0400 Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id IAA08305 for ; Thu, 12 Oct 2000 08:48:03 -0700 (PDT) X-Origination-Site: Received: from newman.xylan.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.1 [HUB])) with ESMTP id IAA27566 for ; Thu, 12 Oct 2000 08:47:45 -0700 (PDT) X-InterScan: Passed Received: from ind.alcatel.com ([127.0.0.1]) by newman.xylan.com (Netscape Messaging Server 3.6) with ESMTP id AAA6808 for ; Thu, 12 Oct 2000 08:47:44 -0700 X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39E5DD22.4607D3F5@ind.alcatel.com> Date: Thu, 12 Oct 2000 08:47:46 -0700 Reply-To: Isabelle Cnudde Sender: "Media Gateway Control (megaco)" From: Isabelle Cnudde Organization: Alcatel Subject: Audit & Events To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, Could someone explain me what are the difference between all the *event* descriptors? and what should be returned to the commands AuditCapabilities and AuditValue? Here is my understanding and open points: EventsDescriptor ---------------- . AuditCapabilities Return the list of possible events on the Termination together with the list of all possible values for the EventsDescriptor Parameters. . AuditValue What should be returned? ObservedEventsDescriptor ------------------------ . AuditCapabilities Return the names of active events on the termination. What is an "active event"? Is that a list of events that has to be observed on a termination? . AuditValue Returns a list of events in the EventBuffer. Is that a list of events that has been observed on a termination? EventBufferDescriptor --------------------- . AuditCapabilities The appropriate descriptors, with the possible values for the Termination are returned from AuditCapabilities. What should be returned? . AuditValue Return content of the EventBufferDescriptor = all events that has been observed? Then, what's the difference with the ObservedEventsDescriptor? Thanks for any clarification on the topic! Isabelle From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 12:04:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01024 for ; Thu, 12 Oct 2000 12:04:18 -0400 (EDT) Received: from standards (47.234.32.16:1103) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2B30@standards.nortelnetworks.com>; Thu, 12 Oct 2000 11:45:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5710 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 11:45:42 -0400 Received: from mars.hss.co.in (202.54.26.197:51543) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2B2E@standards.nortelnetworks.com>; Thu, 12 Oct 2000 11:45:40 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9CG1CC27801 for ; Thu, 12 Oct 2000 21:31:14 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256976.0056F6B9 ; Thu, 12 Oct 2000 21:19:52 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256976.0056F5FC.00@sandesh.hss.hns.com> Date: Thu, 12 Oct 2000 21:25:18 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Re: Audit of packages To: MEGACO@STANDARDS.NORTELNETWORKS.COM The idea of supporting extending package but not supporting base package is not the basic philosophy of extension of packages which says that extended package inherits the behaviour of base package. So do we need to change the basic understanding of package extensions. Dave Sclarsky on 10/12/2000 07:44:17 PM Please respond to Dave Sclarsky To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Sachin Mittal/HSS) Subject: Re: Audit of packages What do you think about the case where an MG can support pkg2 but NOT pkg3? Take the case of the Tone Detection Package and the DTMF Detection Package that extends it. There are most certainly 'intelligent' devices that are capable of reporting DTMF digits, but do not offer the granularity to report 'Start tone' or 'End tone' detected. I would have assumed that an MG with such a device would (should!) publish dd but not tonedet, because it really cannot notify tonedet/std or tonedet/etd. DaveS. -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Wednesday, October 11, 2000 10:25 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > Perhaps we "should" say "SHALL", I can't think of a case of when it is > inappropriate and we have the rule saying that you can address > properties by pkg3. > > But, I'm happy with Should if you can provide the text when it is > inappropriate. > > Cheers, Christian > > Peter Blatherwick wrote: -------------------------- > > I agree in general, since "extends" basically means "clone the base > package and add some more functionality" (no subsetting, over-riding > etc allowed). In example below pkg2 by definition implements pkg3. > (Not the case with re-versioning of Packages though!) > > One clarification however. It does not always make sense for a base > package to be published as implemented by an MG. There are examples > where the base package is defined such that it acts similar to a > virtual class, and has no function on its own, simply defining > interface for one or more derived packages. Annex E ToneGen and > ToneDet as well as a few packages in Annex G are examples. Therefore, > implementer's guide MUST not make a hard and fast rule on this, but > SHOULD say "SHOULD" with some words to describe where its > inappropriate. > > -- Peter > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Monday, October 09, 2000 16:03 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > We've been around this and basically, it is up to the MG. > It does not HAVE to report pkg3, but it could. Maybe SHOULD > is a good word, and I wonder if text to that effect > should go in the implementor's guide? > > Brian > > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Monday, October 09, 2000 5:12 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Audit of packages > > Say a termination abc implements the following packages: > 1. pkg1 > 2. pkg2 > where pkg2 extends pkg3 and pkg1 doesn't extend any other package > > If this termination is audited for packages implemented on it, > should the reply include pkg3 with pkg1 and pkg2 (base package names > are included) > > Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 12:13:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA01204 for ; Thu, 12 Oct 2000 12:13:26 -0400 (EDT) Received: from standards (47.234.32.16:1103) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2B8F@standards.nortelnetworks.com>; Thu, 12 Oct 2000 11:56:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 5830 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 11:56:58 -0400 Received: from mars.hss.co.in (202.54.26.197:51605) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2B8E@standards.nortelnetworks.com>; Thu, 12 Oct 2000 11:56:57 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9CFUgC27544 for ; Thu, 12 Oct 2000 21:00:42 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256976.00542BBD ; Thu, 12 Oct 2000 20:49:22 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256976.00542A1F.00@sandesh.hss.hns.com> Date: Thu, 12 Oct 2000 20:54:46 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Topology Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Descriptor processing sequence is determined by the order sent by MGC. When does the topology descriptor processed? After processing all the commands pertained to the action? 1. If there are no ADDs in the action 2. If there is only single ADD in the action 3. If there are more than one ADD in the Action What if the action also have one or two MOVEs in it. Regards -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 15:38:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA04760 for ; Thu, 12 Oct 2000 15:38:39 -0400 (EDT) Received: from standards (47.234.32.16:3145) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2E5D@standards.nortelnetworks.com>; Thu, 12 Oct 2000 15:22:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6763 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 15:22:10 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2E5C@standards.nortelnetworks.com>; Thu, 12 Oct 2000 15:22:09 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA18809; Thu, 12 Oct 2000 15:36:59 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA29798; Thu, 12 Oct 2000 15:37:01 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <440Q9WYS>; Thu, 12 Oct 2000 15:37:00 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="gb2312" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7CE@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 12 Oct 2000 15:36:59 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ROOT termination X-To: SRD Tian YaMin To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA04760 Actually, no. You need not do a ServiceChange of every termination (interesting idea however!) after Registration. The ServiceChange of service state is a CHANGE of service state, not the initial one. Brian > -----Original Message----- > From: SRD Tian YaMin [mailto:SRDTYM@SBELL.COM.CN] > Sent: Thursday, October 12, 2000 4:06 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ROOT termination > > > Hello, I need someone to verify my understandings: > When an unknown MG first registers to a MGC, in principle , > it must register > > each termination with a ServiceChange to make the MGC be > aware of their > existence, > But to reduce the network traffic, wildcard TerminationId is > necessary, and > the wildcards must be > carefully constructed to let the MGC know the exact > termination set on the > MG, and it¡¯s not right to > use Root termination in this case. > Am I right? Thanks a lot if somebody can help me. > > Best regards > Tian Yamin > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 16:04:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA05097 for ; Thu, 12 Oct 2000 16:04:04 -0400 (EDT) Received: from standards (47.234.32.16:1275) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2E80@standards.nortelnetworks.com>; Thu, 12 Oct 2000 15:47:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 6806 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 15:47:32 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA2E7F@standards.nortelnetworks.com>; Thu, 12 Oct 2000 15:47:32 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA21249; Thu, 12 Oct 2000 16:02:21 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA06359; Thu, 12 Oct 2000 16:02:24 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4MDP34FD>; Thu, 12 Oct 2000 16:02:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7D0@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 12 Oct 2000 16:02:21 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Audit of packages X-To: "samittal@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I don't think there is any change to the base understanding. Suppose Package A defines Event e1 Suppose Package B extends Package A. Now, you can talk about A/e1 or B/e1. If you "expose" package A, then you would include A in the list of packages reported on an audit, and A/e1 as well as B/e1 would be legal. If you don't expose package A, then you can only use B/e1. In both cases the extended package inherits the behavior of the base package. Brian > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Thursday, October 12, 2000 11:55 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > The idea of supporting extending package but not supporting > base package > is not the basic philosophy of extension of packages which says that > extended package inherits the behaviour of base package. > > So do we need to change the basic understanding of package extensions. > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > Please respond to Dave Sclarsky > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Sachin Mittal/HSS) > > Subject: Re: Audit of packages > > > > > What do you think about the case where an MG can support pkg2 > but NOT pkg3? > > Take the case of the Tone Detection Package and the DTMF > Detection Package > that extends it. There are most certainly 'intelligent' > devices that are > capable of reporting DTMF digits, but do not offer the > granularity to report > 'Start tone' or 'End tone' detected. > > I would have assumed that an MG with such a device would > (should!) publish > dd but not tonedet, because it really cannot notify tonedet/std or > tonedet/etd. > > DaveS. > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > Sent: Wednesday, October 11, 2000 10:25 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Audit of packages > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > when it is > > inappropriate and we have the rule saying that you can address > > properties by pkg3. > > > > But, I'm happy with Should if you can provide the text when it is > > inappropriate. > > > > Cheers, Christian > > > > Peter Blatherwick wrote: > -------------------------- > > > > I agree in general, since "extends" basically means "clone the base > > package and add some more functionality" (no subsetting, over-riding > > etc allowed). In example below pkg2 by definition implements pkg3. > > (Not the case with re-versioning of Packages though!) > > > > One clarification however. It does not always make sense for a base > > package to be published as implemented by an MG. There are examples > > where the base package is defined such that it acts similar to a > > virtual class, and has no function on its own, simply defining > > interface for one or more derived packages. Annex E ToneGen and > > ToneDet as well as a few packages in Annex G are examples. > Therefore, > > implementer's guide MUST not make a hard and fast rule on this, but > > SHOULD say "SHOULD" with some words to describe where its > > inappropriate. > > > > -- Peter > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > Sent: Monday, October 09, 2000 16:03 > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Audit of packages > > > > We've been around this and basically, it is up to the MG. > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > is a good word, and I wonder if text to that effect > > should go in the implementor's guide? > > > > Brian > > > > -----Original Message----- > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > Sent: Monday, October 09, 2000 5:12 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Audit of packages > > > > Say a termination abc implements the following packages: > > 1. pkg1 > > 2. pkg2 > > where pkg2 extends pkg3 and pkg1 doesn't extend any other package > > > > If this termination is audited for packages implemented on it, > > should the reply include pkg3 with pkg1 and pkg2 (base package names > > are included) > > > > Sachin > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 12 21:31:41 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA10286 for ; Thu, 12 Oct 2000 21:31:41 -0400 (EDT) Received: from standards (47.234.32.16:2023) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA302D@standards.nortelnetworks.com>; Thu, 12 Oct 2000 21:15:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7343 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 12 Oct 2000 21:15:13 -0400 Received: from mailgate.sbell.com.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA302C@standards.nortelnetworks.com>; Thu, 12 Oct 2000 21:15:11 -0400 Received: from bellnet-mail3.sbell.com.cn (bellnet-mail3.sbell.com.cn [202.96.203.172]) by mailgate.sbell.com.cn (8.9.2/8.9.2) with ESMTP id JAA00385 for ; Fri, 13 Oct 2000 09:22:12 +0800 (CST) Received: by bellnet-mail3.sbell.com.cn with Internet Mail Service (5.5.2650.21) id <4BG6D16H>; Fri, 13 Oct 2000 09:30:51 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <77D4835D5290D111B8CC00805FE6AAD504803D8F@bellnet-mail1.sbell.com.cn> Date: Fri, 13 Oct 2000 09:26:39 +0800 Reply-To: SRD Tian YaMin Sender: "Media Gateway Control (megaco)" From: SRD Tian YaMin Subject: Re: ROOT termination To: MEGACO@STANDARDS.NORTELNETWORKS.COM So, how the MG do a registration? How to set the default service state initially? >Actually, no. You need not do a ServiceChange of every termination >(interesting idea however!) after Registration. The ServiceChange >of service state is a CHANGE of service state, not the initial one. > >Brian > >> -----Original Message----- >> From: SRD Tian YaMin [mailto:SRDTYM@SBELL.COM.CN] >> Sent: Thursday, October 12, 2000 4:06 AM >> To: MEGACO@STANDARDS.NORTELNETWORKS.COM >> Subject: ROOT termination >> >> >> Hello, I need someone to verify my understandings: >> When an unknown MG first registers to a MGC, in principle , >> it must register >> >> each termination with a ServiceChange to make the MGC be >> aware of their >> existence, >> But to reduce the network traffic, wildcard TerminationId is >> necessary, and >> the wildcards must be >> carefully constructed to let the MGC know the exact >> termination set on the >> MG, and it is not right to >> use Root termination in this case. >> Am I right? Thanks a lot if somebody can help me. >> >> Best regards From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 00:35:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15768 for ; Fri, 13 Oct 2000 00:35:31 -0400 (EDT) Received: from standards (47.234.32.16:2894) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3158@standards.nortelnetworks.com>; Fri, 13 Oct 2000 0:19:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7716 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 00:19:09 -0400 Received: from mars.hss.co.in (202.54.26.197:54560) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3157@standards.nortelnetworks.com>; Fri, 13 Oct 2000 0:19:07 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9D4YZC04045; Fri, 13 Oct 2000 10:04:35 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256977.00181A22 ; Fri, 13 Oct 2000 09:53:15 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256977.001819AA.00@sandesh.hss.hns.com> Date: Fri, 13 Oct 2000 09:58:42 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: Re: Audit of packages X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello Brian, If this is the case as you are pointing out, then it should be clearly mentioned in the protocol. Because the protocol says only the following --- in context of Package B extending Package A -- Sec 12.1.1 - " When a package extends another package it shall only add additional Properties, Events, Signals, Statistics and new possible values for an existing parameter described in the original package. An extended package shall not redefine or overload a name defined in the original package." This seems to imply that Package B has to support all the events supported on Package A...... What is your opinion on this.... Chanchal.... "Rosen, Brian" on 10/13/2000 01:32:21 AM Please respond to "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Chanchal Hassija/HSS) Subject: Re: Audit of packages I don't think there is any change to the base understanding. Suppose Package A defines Event e1 Suppose Package B extends Package A. Now, you can talk about A/e1 or B/e1. If you "expose" package A, then you would include A in the list of packages reported on an audit, and A/e1 as well as B/e1 would be legal. If you don't expose package A, then you can only use B/e1. In both cases the extended package inherits the behavior of the base package. Brian > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Thursday, October 12, 2000 11:55 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > The idea of supporting extending package but not supporting > base package > is not the basic philosophy of extension of packages which says that > extended package inherits the behaviour of base package. > > So do we need to change the basic understanding of package extensions. > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > Please respond to Dave Sclarsky > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Sachin Mittal/HSS) > > Subject: Re: Audit of packages > > > > > What do you think about the case where an MG can support pkg2 > but NOT pkg3? > > Take the case of the Tone Detection Package and the DTMF > Detection Package > that extends it. There are most certainly 'intelligent' > devices that are > capable of reporting DTMF digits, but do not offer the > granularity to report > 'Start tone' or 'End tone' detected. > > I would have assumed that an MG with such a device would > (should!) publish > dd but not tonedet, because it really cannot notify tonedet/std or > tonedet/etd. > > DaveS. > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > Sent: Wednesday, October 11, 2000 10:25 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Audit of packages > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > when it is > > inappropriate and we have the rule saying that you can address > > properties by pkg3. > > > > But, I'm happy with Should if you can provide the text when it is > > inappropriate. > > > > Cheers, Christian > > > > Peter Blatherwick wrote: > -------------------------- > > > > I agree in general, since "extends" basically means "clone the base > > package and add some more functionality" (no subsetting, over-riding > > etc allowed). In example below pkg2 by definition implements pkg3. > > (Not the case with re-versioning of Packages though!) > > > > One clarification however. It does not always make sense for a base > > package to be published as implemented by an MG. There are examples > > where the base package is defined such that it acts similar to a > > virtual class, and has no function on its own, simply defining > > interface for one or more derived packages. Annex E ToneGen and > > ToneDet as well as a few packages in Annex G are examples. > Therefore, > > implementer's guide MUST not make a hard and fast rule on this, but > > SHOULD say "SHOULD" with some words to describe where its > > inappropriate. > > > > -- Peter > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > Sent: Monday, October 09, 2000 16:03 > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Audit of packages > > > > We've been around this and basically, it is up to the MG. > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > is a good word, and I wonder if text to that effect > > should go in the implementor's guide? > > > > Brian > > > > -----Original Message----- > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > Sent: Monday, October 09, 2000 5:12 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Audit of packages > > > > Say a termination abc implements the following packages: > > 1. pkg1 > > 2. pkg2 > > where pkg2 extends pkg3 and pkg1 doesn't extend any other package > > > > If this termination is audited for packages implemented on it, > > should the reply include pkg3 with pkg1 and pkg2 (base package names > > are included) > > > > Sachin > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 00:35:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15771 for ; Fri, 13 Oct 2000 00:35:32 -0400 (EDT) Received: from standards (47.234.32.16:2894) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA316A@standards.nortelnetworks.com>; Fri, 13 Oct 2000 0:20:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 7739 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 00:20:31 -0400 Received: from viggen.broadcom.com (dns.broadcom.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3169@standards.nortelnetworks.com>; Fri, 13 Oct 2000 0:20:31 -0400 Received: from mail-irva-1.broadcom.com (mail-irva-1.broadcom.com [10.4.10.10]) by viggen.broadcom.com (8.9.3/8.9.3/FW03) with ESMTP id VAA11023; Thu, 12 Oct 2000 21:35:21 -0700 (PDT) Received: from dashaus.hothaus.com ([10.136.20.22]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-69195U3100L500S0V35) with ESMTP id com; Thu, 12 Oct 2000 21:35:19 -0700 Received: by DASHAUS with Internet Mail Service (5.5.2650.21) id <4XK9HL4H>; Thu, 12 Oct 2000 21:34:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C034CE.E3981480" Message-ID: <5713E3714F03D4118AB9009027D5B3A23D0A85@NT-RMNA-EXCH> Date: Thu, 12 Oct 2000 21:34:48 -0700 Reply-To: Bob Lukas Sender: "Media Gateway Control (megaco)" From: Bob Lukas Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C034CE.E3981480 Content-Type: text/plain; charset="iso-8859-1" Peter, I have been considering your comments and hoping for additional feedback from MGC vendors. I agree my issues are not really specific to the ipphone draft, but with the Annex G packages used by the IPPhone profile. And I concede that most things work fine for MGCs that want "raw" event reporting, ie. not using digitmaps or event descriptors for filtering. It would be useful for an MGC vendor that is planning to support IP Phones to express an opinion here. Maybe these are issues for the implementors guide or for version 2 update of Megaco annexes. One issue that I am stuck on, however, is that I can't find a way to audit the current value of the hookswitch (or any persistent-state key, for that matter). Even if the MGC is hot-standby/auto-failover, there will be times where it is conceivable that the current state of a particular IP Phone will be unknown. e.g. powering up a phone while the handset is knocked off the cradle. I would like to be able to apply off-hook warning tone in this case. Relying on user-behaviour to jiggle the hookswitch a few times, or have the phone possibly ring while off-hook is not optimal. You make reference to having the Phone generate immediate events for each key on event descriptor download - I'm not aware how to make the phone do that w.r.t. the key package. On the issue of multiple terminations, I absolutely agree that it is a good architecture to separate the terminations. But until we can find a way to allow reflex operations between terminations, we will have to admit that we either avoid reflex operations or make the device have some implicit knowledge of local interactions. -----Original Message----- From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM] Sent: Thursday, October 05, 2000 10:23 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt Bob: I believe your comments below do not actually affect the Megaco IP Phone draft itself. However, I agree with some of the issues you raise. Since the Megaco IP Phone draft is currently in last call, its important to identify where the issues reside. See [pb] comments below. -- Peter Blatherwick -----Original Message----- From: Bob Lukas [ mailto:blukas@BROADCOM.COM ] Sent: Thursday, October 05, 2000 01:10 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Issues with draft-ietf-megaco-ipphone-03.txt We've been looking at implementing draft-ietf-megaco-ipphone-03.txt and a few thorny issues have come up that I haven't seen discussed. Keypad and hookswitch are extensions of the basic annex G key package in the UI termination - this means: [pb] A quick clarification: all the UI packages used by IP Phone are Annex G packages, no extensions to Annex G are proposed. Your statement above is correct, but wanted to make sure all understood it. 1. There is no "current state" property value of these switches, only keyup and keydown events that are generated. e.g. the event reported is key/ku{keyid=kh} for an off-hook event. Not normally an issue for momentary push-buttons, but it means an MGC cannot audit for whether the phone is currently off-hook. Kind of a problem for an MGC that is trying to recover state at startup... [pb} True, there is no current state property. I like the general approach you suggest below to time 0 state problem. I personally think the MGC side of things must be responsible for recovering state if their is a failure cut-over (not sure if that's the scenario you are concerned about) since there's a heck of a lot more than hookswitch state involved in call state. At device startup, the worst that can happen is the user will get bored and hang up, generating the event anyway. [pb] Since this is a limitation of what is specified in Annex G, this does not directly affect the Megaco IP Phone draft. I don't think this is serious though. 2. At times, I'm only interested in events from a subset of the possible keys. How can I set an event descriptor to only monitor hookswitch (for example), and not random other button presses? Is this syntax legal? ...modify = ui { events =1 { key/ku { keyid = kh }, key/kd { keyid = f001} } If it was, it would help overcome the audit issue, by getting an immediate event if currently off-hook. [pb] I like it, even though I personally favour the all events on all the time approach. But I am personally unclear if this syntax is valid or not (its been a while). Unless someone on the list can clarify, I'll look into it. Even if suggested syntax is not valid, immediate Events could be returned indicating key states at the time the EventsDescriptor is received at the MG. [pb] This is an issue related to Megaco/H.248 Protocol overall, not specifically Megaco IP Phone. Useful for Implementer's Guide? 3. The audio transducers are separate terminations from the UI. This has great impact on wanting to automatically stop call progress tones immediately when keys are pressed. As far as I understand, an event occurring in one termination must not affect the signals active in another termination (which would be a huge problem for a multiple line device for example). For example, I cannot have dialtone automatically stop when I press a key - the MGC must send down a signal to explicitly stop it. Even worse, if I choose to implement a digitmap on my keypad, the MGC has no way of knowing when to stop dialtone, because it gets no event until after the entire dial string is entered. Saying the IP Phone should know and understand the implicit interactions between the terminations is also problematic and against the general Megaco philosophy of centralized control. [pb] The issue of Termination organization has been picked apart at length several times before, resulting in the current organization. While I certainly understand there is a tradeoff around causing reflex actions to occur as a result of Events, grouping of all termination functionality into a single termination (the implied solution) would result in drastically reduced flexibility for the model overall, and make several powerful applications non-intuitive at best. For example, applications like group listening (talker on a handset while others listen on handsfree) require individual control over the audio input/outputs, hence separate Transducer Terminations to allow them to be freely manipulated. Paging while on a call, IP-radio and several other applications would also be awkward without separate terminations. Since the MGC can control everything, albeit with some extra load, the flexible model is favoured, with the intent to open up new applications well beyond what "phones" can do today. [pb] I strongly agree with you statement that MGs should have no knowledge of call-related interactions (or any other application-level knowledge for that matter), and it would indeed break the Megaco/H.248 master/slave model. I think we all agree we don't go there. [pb] Since this topic has been visited several times, and good agreement achieved that this flexibility is important, I would not favour opening the issues again. I believe the general issue of inter-termination interaction may be a useful area for work in future versions of Megaco/H.248, as I can see several other example where it might be helpful. -- PB _____________________________________________________ Bob Lukas Broadcom Canada Richmond B.C. blukas@broadcom.com 604-233-8665 ------_=_NextPart_001_01C034CE.E3981480 Content-Type: text/html; charset="iso-8859-1" RE: Issues with draft-ietf-megaco-ipphone-03.txt
Peter,
I have been considering your comments and hoping for additional feedback from MGC vendors.
I agree my issues are not really specific to the ipphone draft, but with the Annex G packages used by the IPPhone profile.  And I concede that most things work fine for MGCs that want "raw" event reporting, ie. not using digitmaps or event descriptors for filtering. It would be useful for an MGC vendor that is planning to support IP Phones to express an opinion here.
 
Maybe these are issues for the implementors guide or for version 2 update of Megaco annexes.
 
One issue that I am stuck on, however, is that I can't find a way to audit the current value of the hookswitch (or any persistent-state key, for that matter). Even if the MGC is hot-standby/auto-failover, there will be times where it is conceivable that the current state of a particular IP Phone will be unknown. e.g. powering up a phone while the handset is knocked off the cradle. I would like to be able to apply off-hook warning tone in this case. Relying on user-behaviour to jiggle the hookswitch a few times, or have the phone possibly ring while off-hook is not optimal. You make reference to having the Phone generate immediate events for each key on event descriptor download - I'm not aware how to make the phone do that w.r.t. the key package.
 
On the issue of multiple terminations, I absolutely agree that it is a good architecture to separate the terminations. But until we can find a way to allow reflex operations between terminations, we will have to admit that we either avoid reflex operations or make the device have some implicit knowledge of local interactions.
-----Original Message-----
From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM]
Sent: Thursday, October 05, 2000 10:23 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt

Bob: 

I believe your comments below do not actually affect the Megaco IP Phone draft itself.  However, I agree with some of the issues you raise.  Since the Megaco IP Phone draft is currently in last call, its important to identify where the issues reside.  See [pb] comments below. 

-- Peter Blatherwick

-----Original Message-----
From: Bob Lukas [mailto:blukas@BROADCOM.COM]
Sent: Thursday, October 05, 2000 01:10
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Issues with draft-ietf-megaco-ipphone-03.txt




We've been looking at implementing draft-ietf-megaco-ipphone-03.txt and a few thorny issues have come up that I haven't seen discussed. Keypad and hookswitch are extensions of the basic annex G key package in the UI termination - this means:

[pb] A quick clarification: all the UI packages used by IP Phone are Annex G packages, no extensions to Annex G are proposed.  Your statement above is correct, but wanted to make sure all understood it. 

1. There is no "current state" property value of these switches, only keyup and keydown events that are generated. e.g. the event reported is key/ku{keyid=kh} for an off-hook event. Not normally an issue for momentary push-buttons, but it means an MGC cannot audit for whether the phone is currently off-hook. Kind of a problem for an MGC that is trying to recover state at startup...

[pb} True, there is no current state property.  I like the general approach you suggest below to time 0 state problem.  I personally think the MGC side of things must be responsible for recovering state if their is a failure cut-over (not sure if that's the scenario you are concerned about) since there's a heck of a lot more than hookswitch state involved in call state.  At device startup, the worst that can happen is the user will get bored and hang up, generating the event anyway. 

[pb] Since this is a limitation of what is specified in Annex G, this does not directly affect the Megaco IP Phone draft.  I don't think this is serious though. 

2. At times, I'm only interested in events from a subset of the possible keys. How can I set an event descriptor to only monitor hookswitch (for example), and not random other button presses?

Is this syntax legal? ...modify = ui { events =1 { key/ku { keyid = kh }, key/kd { keyid = f001} }
If it was, it would help overcome the audit issue, by getting an immediate event if currently off-hook.

[pb] I like it, even though I personally favour the all events on all the time approach.  But I am personally unclear if this syntax is valid or not (its been a while).  Unless someone on the list can clarify, I'll look into it.  Even if suggested syntax is not valid, immediate Events could be returned indicating key states at the time the EventsDescriptor is received at the MG. 

[pb] This is an issue related to Megaco/H.248 Protocol overall, not specifically Megaco IP Phone.  Useful for Implementer's Guide? 

3. The audio transducers are separate terminations from the UI. This has great impact on wanting to automatically stop call progress tones immediately when keys are pressed. As far as I understand, an event occurring in one termination must not affect the signals active in another termination (which would be a huge problem for a multiple line device for example). For example, I cannot have dialtone automatically stop when I press a key - the MGC must send down a signal to explicitly stop it. Even worse, if I choose to implement a digitmap on my keypad, the MGC has no way of knowing when to stop dialtone, because it gets no event until after the entire dial string is entered. Saying the IP Phone should know and understand the implicit interactions between the terminations is also problematic and against the general Megaco philosophy of centralized control.

[pb] The issue of Termination organization has been picked apart at length several times before, resulting in the current organization. While I certainly understand there is a tradeoff around causing reflex actions to occur as a result of Events, grouping of all termination functionality into a single termination (the implied solution) would result in drastically reduced flexibility for the model overall, and make several powerful applications non-intuitive at best.  For example, applications like group listening (talker on a handset while others listen on handsfree) require individual control over the audio input/outputs, hence separate Transducer Terminations to allow them to be freely manipulated.  Paging while on a call, IP-radio and several other applications would also be awkward without separate terminations.  Since the MGC can control everything, albeit with some extra load, the flexible model is favoured, with the intent to open up new applications well beyond what "phones" can do today. 

[pb] I strongly agree with you statement that MGs should have no knowledge of call-related interactions (or any other application-level knowledge for that matter), and it would indeed break the Megaco/H.248 master/slave model.  I think we all agree we don't go there. 

[pb] Since this topic has been visited several times, and good agreement achieved that this flexibility is important, I would not favour opening the issues again.  I believe the general issue of inter-termination interaction may be a useful area for work in future versions of Megaco/H.248, as I can see several other example where it might be helpful. 

-- PB
_____________________________________________________
Bob Lukas
Broadcom Canada
Richmond B.C.
blukas@broadcom.com
604-233-8665

------_=_NextPart_001_01C034CE.E3981480-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 01:39:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA21049 for ; Fri, 13 Oct 2000 01:39:11 -0400 (EDT) Received: from standards (47.234.32.16:3085) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3279@standards.nortelnetworks.com>; Fri, 13 Oct 2000 1:23:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 8102 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 01:23:44 -0400 Received: from mars.hss.co.in (202.54.26.197:55786) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3276@standards.nortelnetworks.com>; Fri, 13 Oct 2000 1:23:39 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9D5d5C06092 for ; Fri, 13 Oct 2000 11:09:08 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256977.001E01A7 ; Fri, 13 Oct 2000 10:57:45 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256977.001E00F7.00@sandesh.hss.hns.com> Date: Fri, 13 Oct 2000 11:03:13 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: Packages....Extension To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello All, Consider a scenario Base Package A - property p1 Package B and Package C extends Package A Termination T1 supports Package B as well as C.... Case 1) If I get a command to modify B/p1 on T1...... shall it modify C/p1 also on T1 ? Case 2) If I get a command to modify A/p1 on T1, shall it modify B/p1 or C/p1 or both......? Thanks for your time... Chanchal.... From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 07:54:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA03415 for ; Fri, 13 Oct 2000 07:54:30 -0400 (EDT) Received: from standards (47.234.32.16:1241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA357B@standards.nortelnetworks.com>; Fri, 13 Oct 2000 7:37:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9097 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 07:37:38 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA357A@standards.nortelnetworks.com>; Fri, 13 Oct 2000 7:37:38 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA00363; Fri, 13 Oct 2000 07:52:28 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA09887; Fri, 13 Oct 2000 07:52:31 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <440Q907Z>; Fri, 13 Oct 2000 07:52:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7D8@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 13 Oct 2000 07:52:29 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ROOT termination X-To: SRD Tian YaMin To: MEGACO@STANDARDS.NORTELNETWORKS.COM The MG uses ServiceChange to register with an MGC The MGC audits the MG. Note that if this is the initial registration for the MG (the MG booted), then there is no relevant state - the MGC programs the state it wants. The audits are to discover capability. If the registration is due to a failover, then the MGC does have to audit state, but the audit commands are sufficient. There is a hole, which I'm supposed to have an I-D out on. The hole is - how does the MGC know how to construct a finite number of audit requests if it doesn't know the "naming pattern" of the terminations in the MG. The current answer is - provisioning. The I-D I owe is a package that defines a property the MGC can read which describes the naming pattern. Brian > -----Original Message----- > From: SRD Tian YaMin [mailto:SRDTYM@SBELL.COM.CN] > Sent: Thursday, October 12, 2000 9:27 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: ROOT termination > > > So, how the MG do a registration? > How to set the default service state initially? > > >Actually, no. You need not do a ServiceChange of every termination > >(interesting idea however!) after Registration. The ServiceChange > >of service state is a CHANGE of service state, not the initial one. > > > >Brian > > > >> -----Original Message----- > >> From: SRD Tian YaMin [mailto:SRDTYM@SBELL.COM.CN] > >> Sent: Thursday, October 12, 2000 4:06 AM > >> To: MEGACO@STANDARDS.NORTELNETWORKS.COM > >> Subject: ROOT termination > >> > >> > >> Hello, I need someone to verify my understandings: > >> When an unknown MG first registers to a MGC, in principle , > >> it must register > >> > >> each termination with a ServiceChange to make the MGC be > >> aware of their > >> existence, > >> But to reduce the network traffic, wildcard TerminationId is > >> necessary, and > >> the wildcards must be > >> carefully constructed to let the MGC know the exact > >> termination set on the > >> MG, and it is not right to > >> use Root termination in this case. > >> Am I right? Thanks a lot if somebody can help me. > >> > >> Best regards > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 08:00:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03538 for ; Fri, 13 Oct 2000 08:00:09 -0400 (EDT) Received: from standards (47.234.32.16:1241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA35A9@standards.nortelnetworks.com>; Fri, 13 Oct 2000 7:43:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9152 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 07:43:19 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA35A8@standards.nortelnetworks.com>; Fri, 13 Oct 2000 7:43:19 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA00592; Fri, 13 Oct 2000 07:58:10 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA10434; Fri, 13 Oct 2000 07:58:14 -0400 (EDT) Received: by whq-msgrtr-01.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <440Q909Q>; Fri, 13 Oct 2000 07:58:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7D9@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 13 Oct 2000 07:58:12 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Audit of packages X-To: "chassija@hss.hns.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM We probably need some words in the Implementer's Guide, I agree. How about something like: When packages are extended, the properties, events, signals and statistics defined in the base package can be referred to using the extended package name. For example, if Package A defines event e1, and Package B extends Package A, then B/e1 is an event for a termination implementing Package B. The MG MAY also "implement" the base Package. If it does, then A would be reported on the Package Descriptor in AuditValue as well as B, and event A/e1 would be available on a termination. If the MG does not implement A, then only B/e1 would be available. Of course, if implemented, A/e1 and B/e1 are the same event. Brian > -----Original Message----- > From: chassija@hss.hns.com [mailto:chassija@hss.hns.com] > Sent: Friday, October 13, 2000 12:29 AM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > > > Hello Brian, > > If this is the case as you are pointing out, then it should > be clearly mentioned > in the protocol. Because the protocol says only the following > --- in context of > Package B extending Package A -- > > Sec 12.1.1 - " When a package > extends another package it shall only add additional Properties, > Events, Signals, Statistics and new possible values for an > existing parameter described in the original package. An extended > package shall not redefine or overload a name defined in the > original package." > > This seems to imply that Package B has to support all the > events supported on > Package A...... > > What is your opinion on this.... > Chanchal.... > > > > > > "Rosen, Brian" on 10/13/2000 01:32:21 AM > > Please respond to "Rosen, Brian" > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Chanchal Hassija/HSS) > > Subject: Re: Audit of packages > > > > > I don't think there is any change to the base understanding. > > Suppose Package A defines Event e1 > Suppose Package B extends Package A. > > Now, you can talk about A/e1 or B/e1. > > If you "expose" package A, then you would include A in the > list of packages reported on an audit, and A/e1 as well as B/e1 > would be legal. > > If you don't expose package A, then you can only use B/e1. > > In both cases the extended package inherits the behavior of the > base package. > > Brian > > > -----Original Message----- > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > Sent: Thursday, October 12, 2000 11:55 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Audit of packages > > > > > > The idea of supporting extending package but not supporting > > base package > > is not the basic philosophy of extension of packages which says that > > extended package inherits the behaviour of base package. > > > > So do we need to change the basic understanding of package > extensions. > > > > > > > > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > > > Please respond to Dave Sclarsky > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Sachin Mittal/HSS) > > > > Subject: Re: Audit of packages > > > > > > > > > > What do you think about the case where an MG can support pkg2 > > but NOT pkg3? > > > > Take the case of the Tone Detection Package and the DTMF > > Detection Package > > that extends it. There are most certainly 'intelligent' > > devices that are > > capable of reporting DTMF digits, but do not offer the > > granularity to report > > 'Start tone' or 'End tone' detected. > > > > I would have assumed that an MG with such a device would > > (should!) publish > > dd but not tonedet, because it really cannot notify tonedet/std or > > tonedet/etd. > > > > DaveS. > > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > Sent: Wednesday, October 11, 2000 10:25 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > > when it is > > > inappropriate and we have the rule saying that you can address > > > properties by pkg3. > > > > > > But, I'm happy with Should if you can provide the text when it is > > > inappropriate. > > > > > > Cheers, Christian > > > > > > Peter Blatherwick wrote: > > -------------------------- > > > > > > I agree in general, since "extends" basically means > "clone the base > > > package and add some more functionality" (no subsetting, > over-riding > > > etc allowed). In example below pkg2 by definition > implements pkg3. > > > (Not the case with re-versioning of Packages though!) > > > > > > One clarification however. It does not always make sense > for a base > > > package to be published as implemented by an MG. There > are examples > > > where the base package is defined such that it acts similar to a > > > virtual class, and has no function on its own, simply defining > > > interface for one or more derived packages. Annex E ToneGen and > > > ToneDet as well as a few packages in Annex G are examples. > > Therefore, > > > implementer's guide MUST not make a hard and fast rule on > this, but > > > SHOULD say "SHOULD" with some words to describe where its > > > inappropriate. > > > > > > -- Peter > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > Sent: Monday, October 09, 2000 16:03 > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > We've been around this and basically, it is up to the MG. > > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > > is a good word, and I wonder if text to that effect > > > should go in the implementor's guide? > > > > > > Brian > > > > > > -----Original Message----- > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > > Sent: Monday, October 09, 2000 5:12 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Audit of packages > > > > > > Say a termination abc implements the following packages: > > > 1. pkg1 > > > 2. pkg2 > > > where pkg2 extends pkg3 and pkg1 doesn't extend any other package > > > > > > If this termination is audited for packages implemented on it, > > > should the reply include pkg3 with pkg1 and pkg2 (base > package names > > > are included) > > > > > > Sachin > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 08:04:52 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03649 for ; Fri, 13 Oct 2000 08:04:52 -0400 (EDT) Received: from standards (47.234.32.16:1241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA35C5@standards.nortelnetworks.com>; Fri, 13 Oct 2000 7:47:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9188 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 07:47:21 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA35C4@standards.nortelnetworks.com>; Fri, 13 Oct 2000 7:47:21 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00823; Fri, 13 Oct 2000 08:02:11 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA11056; Fri, 13 Oct 2000 08:02:15 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4MDP38HY>; Fri, 13 Oct 2000 08:02:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7DA@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 13 Oct 2000 08:02:10 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Packages....Extension X-To: "chassija@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM > -----Original Message----- > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > Sent: Friday, October 13, 2000 1:33 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Consider a scenario > > Base Package A - property p1 > > Package B and Package C extends Package A > > > > Termination T1 supports Package B as well as C.... > > Case 1) If I get a command to modify B/p1 on T1...... shall > it modify C/p1 > also on T1 ? Yes, although I would state this as "A change to C/p1 is visible as a change to B/p1, if the MG implements both A and B on a termination." > > Case 2) If I get a command to modify A/p1 on T1, shall it > modify B/p1 or C/p1 or > both......? Both if the MG implements A (see prior email) Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 08:39:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA04451 for ; Fri, 13 Oct 2000 08:39:54 -0400 (EDT) Received: from standards (47.234.32.16:1241) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA36D7@standards.nortelnetworks.com>; Fri, 13 Oct 2000 8:19:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9537 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 08:19:44 -0400 Received: from mel.alcatel.fr (mail2.alcatel.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA36D5@standards.nortelnetworks.com>; Fri, 13 Oct 2000 8:19:43 -0400 Received: from aifhs2.alcatel.fr (mailhub.alcatel.fr [155.132.180.80]) by mel.alcatel.fr (ALCANET/SMTP) with ESMTP id OAA25099; Fri, 13 Oct 2000 14:33:50 +0200 Received: from medine.ms.alcatel.fr (medine.ms.alcatel.fr [193.105.117.1]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id OAA10278; Fri, 13 Oct 2000 14:31:51 +0200 (MET DST) Received: from ms.ms.alcatel.fr (aar.ms.alcatel.fr [188.9.12.93]) by medine.ms.alcatel.fr (8.8.8/8.8.8/aar-1.2) with ESMTP id OAA28858; Fri, 13 Oct 2000 14:34:33 +0200 (MET DST) Received: from ms.alcatel.fr ([188.9.247.87]) by ms.ms.alcatel.fr (8.8.7/8.8.7/aar-1.0) with ESMTP id OAA03565; Fri, 13 Oct 2000 14:34:32 +0200 (MET DST) X-Mailer: Mozilla 4.5 [fr] (WinNT; I) X-Accept-Language: en,fr MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E7D8@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <39E70157.9A9C4533@ms.alcatel.fr> Date: Fri, 13 Oct 2000 14:34:31 +0200 Reply-To: Thomas LEVY Sender: "Media Gateway Control (megaco)" From: Thomas LEVY Organization: Alcatel Subject: Re: ROOT termination X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit I don't quiet understand the problem. I guess you talk about permanent Termination. Why wouldn't be possible for the MGC to Audit with wildcard in order to have all the TerminationID from the MG? Is it a too heavy procedure? Thomas, "Rosen, Brian" a écrit : > The MG uses ServiceChange to register with an MGC > The MGC audits the MG. > > Note that if this is the initial registration for the MG (the MG booted), > then there is no relevant state - the MGC programs the state it wants. > The audits are to discover capability. > > If the registration is due to a failover, then the MGC does have to > audit state, but the audit commands are sufficient. > > There is a hole, which I'm supposed to have an I-D out on. The hole > is - how does the MGC know how to construct a finite number of > audit requests if it doesn't know the "naming pattern" of the terminations > in the MG. The current answer is - provisioning. > > The I-D I owe is a package that defines a property the MGC can read > which describes the naming pattern. > > Brian > > > -----Original Message----- > > From: SRD Tian YaMin [mailto:SRDTYM@SBELL.COM.CN] > > Sent: Thursday, October 12, 2000 9:27 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: ROOT termination > > > > > > So, how the MG do a registration? > > How to set the default service state initially? > > > > >Actually, no. You need not do a ServiceChange of every termination > > >(interesting idea however!) after Registration. The ServiceChange > > >of service state is a CHANGE of service state, not the initial one. > > > > > >Brian > > > > > >> -----Original Message----- > > >> From: SRD Tian YaMin [mailto:SRDTYM@SBELL.COM.CN] > > >> Sent: Thursday, October 12, 2000 4:06 AM > > >> To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > >> Subject: ROOT termination > > >> > > >> > > >> Hello, I need someone to verify my understandings: > > >> When an unknown MG first registers to a MGC, in principle , > > >> it must register > > >> > > >> each termination with a ServiceChange to make the MGC be > > >> aware of their > > >> existence, > > >> But to reduce the network traffic, wildcard TerminationId is > > >> necessary, and > > >> the wildcards must be > > >> carefully constructed to let the MGC know the exact > > >> termination set on the > > >> MG, and it is not right to > > >> use Root termination in this case. > > >> Am I right? Thanks a lot if somebody can help me. > > >> > > >> Best regards > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 09:15:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA05022 for ; Fri, 13 Oct 2000 09:15:23 -0400 (EDT) Received: from standards (47.234.32.16:1303) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA37A8@standards.nortelnetworks.com>; Fri, 13 Oct 2000 8:58:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 9789 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 08:58:46 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA37A7@standards.nortelnetworks.com>; Fri, 13 Oct 2000 8:58:46 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA05840; Fri, 13 Oct 2000 09:13:36 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA25268; Fri, 13 Oct 2000 09:13:39 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <4MDP39ZW>; Fri, 13 Oct 2000 09:13:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7DC@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 13 Oct 2000 09:13:37 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ROOT termination X-To: Thomas LEVY To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA05022 The issue is that many MGs have large numbers of terminations. Ill-formed wildcard audits will generate huge numbers of responses, or will generate responses that are ambiguous. Ambiguous responses occur when the MG realizes different kinds of terminations. A simple example - suppose a gateway had 10,001 physical terminations. 10,000 of them implement package A, 1 of them implements package B. An AuditValue=*{Audit{Package}} will return 10,000 versions of AuditValue=termA/000{Package{A}}} AuditValue=termA/001{Package{A}}} ... and one case of AuditValue=termB/000{Package{B}}} W-AuditValue=*{Audit{Package}} would return AuditValue=*{Package{A,B}}} this is interesting, but not very helpful. What you want to do is: W-AuditValue=termA/*{Audit{Package}} and W-AuditValue=termB/*{Audit{Package}} which would return W-AuditValue=termA/*{Package{A}} and W-AuditValue=termB/*{Package{B}} the question is, how did you know that the gateway has two sets of terminations termA/000 - termA/999 and termB/000? There is no way, with the current protocol and packages, to find that out. Brian > -----Original Message----- > From: Thomas LEVY [mailto:thomas.levy@ms.alcatel.fr] > Sent: Friday, October 13, 2000 8:35 AM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: ROOT termination > > > I don't quiet understand the problem. > I guess you talk about permanent Termination. > Why wouldn't be possible for the MGC to Audit with wildcard > in order to have > all the TerminationID from the MG? > Is it a too heavy procedure? > > Thomas, > > "Rosen, Brian" a écrit : > > > The MG uses ServiceChange to register with an MGC > > The MGC audits the MG. > > > > Note that if this is the initial registration for the MG > (the MG booted), > > then there is no relevant state - the MGC programs the > state it wants. > > The audits are to discover capability. > > > > If the registration is due to a failover, then the MGC does have to > > audit state, but the audit commands are sufficient. > > > > There is a hole, which I'm supposed to have an I-D out on. The hole > > is - how does the MGC know how to construct a finite number of > > audit requests if it doesn't know the "naming pattern" of > the terminations > > in the MG. The current answer is - provisioning. > > > > The I-D I owe is a package that defines a property the MGC can read > > which describes the naming pattern. > > > > Brian > > > > > -----Original Message----- > > > From: SRD Tian YaMin [mailto:SRDTYM@SBELL.COM.CN] > > > Sent: Thursday, October 12, 2000 9:27 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: ROOT termination > > > > > > > > > So, how the MG do a registration? > > > How to set the default service state initially? > > > > > > >Actually, no. You need not do a ServiceChange of every > termination > > > >(interesting idea however!) after Registration. The > ServiceChange > > > >of service state is a CHANGE of service state, not the > initial one. > > > > > > > >Brian > > > > > > > >> -----Original Message----- > > > >> From: SRD Tian YaMin [mailto:SRDTYM@SBELL.COM.CN] > > > >> Sent: Thursday, October 12, 2000 4:06 AM > > > >> To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > >> Subject: ROOT termination > > > >> > > > >> > > > >> Hello, I need someone to verify my understandings: > > > >> When an unknown MG first registers to a MGC, in principle , > > > >> it must register > > > >> > > > >> each termination with a ServiceChange to make the MGC be > > > >> aware of their > > > >> existence, > > > >> But to reduce the network traffic, wildcard TerminationId is > > > >> necessary, and > > > >> the wildcards must be > > > >> carefully constructed to let the MGC know the exact > > > >> termination set on the > > > >> MG, and it is not right to > > > >> use Root termination in this case. > > > >> Am I right? Thanks a lot if somebody can help me. > > > >> > > > >> Best regards > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 14:02:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA09937 for ; Fri, 13 Oct 2000 14:02:21 -0400 (EDT) Received: from standards (47.234.32.16:1303) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3C72@standards.nortelnetworks.com>; Fri, 13 Oct 2000 13:45:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11349 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 13:45:36 -0400 Received: from thalia.fm.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3C71@standards.nortelnetworks.com>; Fri, 13 Oct 2000 13:45:35 -0400 Received: from SMTP (fmsmsxvs02-1.fm.intel.com [132.233.42.202]) by thalia.fm.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id SAA28075 for ; Fri, 13 Oct 2000 18:01:44 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.48.29]) by 132.233.48.202 (Norton AntiVirus for Internet Email Gateways 1.0) ; Fri, 13 Oct 2000 18:00:29 0000 (GMT) Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2650.21) id <4YTT19G4>; Fri, 13 Oct 2000 11:00:28 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 13 Oct 2000 11:00:18 -0700 Reply-To: "Tulpule, Naren" Sender: "Media Gateway Control (megaco)" From: "Tulpule, Naren" Subject: ABNF for topologyDescriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi list, in the implementor's guide (B.2), topology descriptor is given as topologyDescriptor = TopologyToken LBRKT *(terminationA COMMA terminationB COMMA topologyDirection) RBRKT What's the seperator between topologyDirection and terminationA? How about COMMA if we haven't agreed on one? And what exactly are the short-form tokens for EventBufferToken, EmergencyToken and EmbedToken? Again, if not decided yet, can we go with EB, EMG and EM? -- Naren. These views and opinions are mine alone, not those of Intel (yet ;-) Narendra C. Tulpule SMTS, Trillium (an Intel company) Ph: +1-310-442-9222 Fax: +1-310-442-1162 12100 Wilshire Bl #1800 Los Angeles, CA 90025 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 16:18:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11562 for ; Fri, 13 Oct 2000 16:18:22 -0400 (EDT) Received: from standards (47.234.32.16:2266) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3D1C@standards.nortelnetworks.com>; Fri, 13 Oct 2000 16:01:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11569 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 16:01:41 -0400 Received: from qhars002.nortel.com (47.101.112.102:53543) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3D1B@standards.nortelnetworks.com>; Fri, 13 Oct 2000 16:01:40 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Fri, 13 Oct 2000 21:15:45 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Fri, 13 Oct 2000 15:11:23 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VN508AW>; Fri, 13 Oct 2000 15:15:20 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03552.4BD5B120" X-Orig: Message-ID: <353093573B82D411889E0000F808216648E3EB@zcard00q.ca.nortel.com> Date: Fri, 13 Oct 2000 15:15:14 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Audit of packages X-To: Christian Groves X-cc: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03552.4BD5B120 Content-Type: text/plain; charset="iso-8859-1" I believe in SHOULD for this, at most. Reason is to not require publishing of packages which are not intended to be directly controlled. Some examples exist now (for example tonedet and tonegen, a few in Annex G). I can certainly see others defined in the future, some of which could actually be functional but still intended to be used as base package only, and might be nonsensical on their own. Can't think of any good examples right now, but we should allow for it. The effect of having no rule at all is some MGs would not publish base Packages and could suffer some non-backward compatibility problems with some MGCs that only know about the base Packages -- that's the MG implementer's decision really. Possible starter text: MG SHOULD publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived. An exception to this is in cases where the base Packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own. (Steal some of Brian's words about valid addressing of A or B, depending on what's published.) -- Peter -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ericsson.com] Sent: Wednesday, October 11, 2000 22:25 To: Blatherwick, Peter [CAR:AT14:EXCH] Cc: megaco@standards.nortelnetworks.com; 'Rosen, Brian' Subject: Re: Audit of packages Perhaps we "should" say "SHALL", I can't think of a case of when it is inappropriate and we have the rule saying that you can address properties by pkg3. But, I'm happy with Should if you can provide the text when it is inappropriate. Cheers, Christian Peter Blatherwick wrote: > > I agree in general, since "extends" basically means "clone the base > package and add some more functionality" (no subsetting, over-riding > etc allowed). In example below pkg2 by definition implements pkg3. > (Not the case with re-versioning of Packages though!) > > One clarification however. It does not always make sense for a base > package to be published as implemented by an MG. There are examples > where the base package is defined such that it acts similar to a > virtual class, and has no function on its own, simply defining > interface for one or more derived packages. Annex E ToneGen and > ToneDet as well as a few packages in Annex G are examples. Therefore, > implementer's guide MUST not make a hard and fast rule on this, but > SHOULD say "SHOULD" with some words to describe where its > inappropriate. > > -- Peter > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Monday, October 09, 2000 16:03 > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > We've been around this and basically, it is up to the MG. > It does not HAVE to report pkg3, but it could. Maybe SHOULD > is a good word, and I wonder if text to that effect > should go in the implementor's guide? > > Brian > > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Monday, October 09, 2000 5:12 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Audit of packages > > Say a termination abc implements the following packages: > 1. pkg1 > 2. pkg2 > where pkg2 extends pkg3 and pkg1 doesn't extend any other package > > If this termination is audited for packages implemented on it, > should the reply include pkg3 with pkg1 and pkg2 (base package names > are included) > > Sachin ------_=_NextPart_001_01C03552.4BD5B120 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Audit of packages

I believe in SHOULD for this, at most.  Reason = is to not require publishing of packages which are not intended to be = directly controlled.  Some examples exist now (for example tonedet = and tonegen, a few in Annex G).  I can certainly see others = defined in the future, some of which could actually be functional but = still intended to be used as base package only, and might be = nonsensical on their own.  Can't think of any good examples right = now, but we should allow for it.  The effect of having no rule at = all is some MGs would not publish base Packages and could suffer some = non-backward compatibility problems with some MGCs that only know about = the base Packages -- that's the MG implementer's decision really.  =

Possible starter text:
MG SHOULD publish all Packages supported by its = Terminations, including base Packages from which extended Packages are = derived.  An exception to this is in cases where the base Packages = are expressly designed to be extended by others, not directly = controlled, and may not have any function on their own or be = nonsensical on their own.  (Steal some of Brian's words about = valid addressing of A or B, depending on what's published.)  =

-- Peter

-----Original Message-----
From: Christian Groves [mailto:Christian.Groves@er= icsson.com]
Sent: Wednesday, October 11, 2000 22:25
To: Blatherwick, Peter [CAR:AT14:EXCH]
Cc: megaco@standards.nortelnetworks.com; 'Rosen, = Brian'
Subject: Re: Audit of packages


Perhaps we "should" say "SHALL", = I can't think of a case of when it is
inappropriate and we have the rule saying that you = can address
properties by pkg3.

But, I'm happy with Should if you can provide the = text when it is
inappropriate.

Cheers, Christian

Peter Blatherwick wrote:
>
> I agree in general, since "extends" = basically means "clone the base
> package and add some more functionality" = (no subsetting, over-riding
> etc allowed).  In example below pkg2 by = definition implements pkg3.
> (Not the case with re-versioning of Packages = though!)
>
> One clarification however.  It does not = always make sense for a base
> package to be published as implemented by an = MG.  There are examples
> where the base package is defined such that it = acts similar to a
> virtual class, and has no function on its own, = simply defining
> interface for one or more derived = packages.  Annex E ToneGen and
> ToneDet as well as a few packages in Annex G = are examples.  Therefore,
> implementer's guide MUST not make a hard and = fast rule on this, but
> SHOULD say "SHOULD" with some words = to describe where its
> inappropriate.
>
> -- Peter
>
> -----Original Message-----
> From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> Sent: Monday, October 09, 2000 16:03
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Audit of packages
>
> We've been around this and basically, it is up = to the MG.
> It does not HAVE to report pkg3, but it = could.  Maybe SHOULD
> is a good word, and I wonder if text to that = effect
> should go in the implementor's guide?
>
> Brian
>
> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> Sent: Monday, October 09, 2000 5:12 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Audit of packages
>
> Say a termination abc implements the following = packages:
> 1. pkg1
> 2. pkg2
> where pkg2 extends pkg3 and pkg1 doesn't extend = any other package
>
> If this termination is audited for packages = implemented on it,
> should the reply include pkg3 with pkg1 and = pkg2 (base package names
> are included)
>
> Sachin


------_=_NextPart_001_01C03552.4BD5B120-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 13 16:45:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA11735 for ; Fri, 13 Oct 2000 16:45:20 -0400 (EDT) Received: from standards (47.234.32.16:3578) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3D6B@standards.nortelnetworks.com>; Fri, 13 Oct 2000 16:28:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 11665 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 13 Oct 2000 16:28:44 -0400 Received: from qhars002.nortel.com (47.101.112.102:53975) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA3D6A@standards.nortelnetworks.com>; Fri, 13 Oct 2000 16:28:44 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Fri, 13 Oct 2000 21:39:51 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Fri, 13 Oct 2000 15:02:35 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4VN507R1>; Fri, 13 Oct 2000 15:02:18 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03550.63861000" Message-ID: <353093573B82D411889E0000F808216648E3EA@zcard00q.ca.nortel.com> Date: Fri, 13 Oct 2000 15:01:34 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Audit of packages To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03550.63861000 Content-Type: text/plain; charset="iso-8859-1" Below is correct. The reason to publish both A and B in this example is to allow an MGC that only understands the base package (A) to be able to make use of its capabilities. In the previous example, further below, publishing dtmf tone detect (dd) but not basic tone detect (tonedet) is also valid, but the description of the result is not. In this case, an MG publishing dd is required to support *all* aspects of the base tonedet package from which dd is derived, including start tone detected and end tone detected. If it does not, it is either a different package or incorrectly implemented. In this case, it does not make sense to publish support of tonedet since it has no functionality on its own, just defines interface, and is intended specifically as a base package from which other functional ones are derived (even says so in the description). -- Peter -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Thursday, October 12, 2000 16:02 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages I don't think there is any change to the base understanding. Suppose Package A defines Event e1 Suppose Package B extends Package A. Now, you can talk about A/e1 or B/e1. If you "expose" package A, then you would include A in the list of packages reported on an audit, and A/e1 as well as B/e1 would be legal. If you don't expose package A, then you can only use B/e1. In both cases the extended package inherits the behavior of the base package. Brian > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Thursday, October 12, 2000 11:55 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > The idea of supporting extending package but not supporting > base package > is not the basic philosophy of extension of packages which says that > extended package inherits the behaviour of base package. > > So do we need to change the basic understanding of package extensions. > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > Please respond to Dave Sclarsky > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Sachin Mittal/HSS) > > Subject: Re: Audit of packages > > > > > What do you think about the case where an MG can support pkg2 > but NOT pkg3? > > Take the case of the Tone Detection Package and the DTMF > Detection Package > that extends it. There are most certainly 'intelligent' > devices that are > capable of reporting DTMF digits, but do not offer the > granularity to report > 'Start tone' or 'End tone' detected. > > I would have assumed that an MG with such a device would > (should!) publish > dd but not tonedet, because it really cannot notify tonedet/std or > tonedet/etd. > > DaveS. > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > Sent: Wednesday, October 11, 2000 10:25 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Audit of packages > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > when it is > > inappropriate and we have the rule saying that you can address > > properties by pkg3. > > > > But, I'm happy with Should if you can provide the text when it is > > inappropriate. > > > > Cheers, Christian > > > > Peter Blatherwick wrote: > -------------------------- > > > > I agree in general, since "extends" basically means "clone the base > > package and add some more functionality" (no subsetting, over-riding > > etc allowed). In example below pkg2 by definition implements pkg3. > > (Not the case with re-versioning of Packages though!) > > > > One clarification however. It does not always make sense for a base > > package to be published as implemented by an MG. There are examples > > where the base package is defined such that it acts similar to a > > virtual class, and has no function on its own, simply defining > > interface for one or more derived packages. Annex E ToneGen and > > ToneDet as well as a few packages in Annex G are examples. > Therefore, > > implementer's guide MUST not make a hard and fast rule on this, but > > SHOULD say "SHOULD" with some words to describe where its > > inappropriate. > > > > -- Peter > > > > -----Original Message----- > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > Sent: Monday, October 09, 2000 16:03 > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Audit of packages > > > > We've been around this and basically, it is up to the MG. > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > is a good word, and I wonder if text to that effect > > should go in the implementor's guide? > > > > Brian > > > > -----Original Message----- > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > Sent: Monday, October 09, 2000 5:12 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Audit of packages > > > > Say a termination abc implements the following packages: > > 1. pkg1 > > 2. pkg2 > > where pkg2 extends pkg3 and pkg1 doesn't extend any other package > > > > If this termination is audited for packages implemented on it, > > should the reply include pkg3 with pkg1 and pkg2 (base package names > > are included) > > > > Sachin > ------_=_NextPart_001_01C03550.63861000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Audit of packages

Below is correct.  The reason to publish both A = and B in this example is to allow an MGC that only understands the base = package (A) to be able to make use of its capabilities.  =

In the previous example, further below, publishing = dtmf tone detect (dd) but not basic tone detect (tonedet) is also = valid, but the description of the result is not.  In this case, an = MG publishing dd is required to support *all* aspects of the base = tonedet package from which dd is derived, including start tone detected = and end tone detected.  If it does not, it is either a different = package or incorrectly implemented.  In this case, it does not = make sense to publish support of tonedet since it has no functionality = on its own, just defines interface, and is intended specifically as a = base package from which other functional ones are derived (even says so = in the description). 

-- Peter

-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Thursday, October 12, 2000 16:02
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Audit of packages


I don't think there is any change to the base = understanding.

Suppose Package A defines Event e1
Suppose Package B extends Package A.

Now, you can talk about A/e1 or B/e1.

If you "expose" package A, then you would = include A in the
list of packages reported on an audit, and A/e1 as = well as B/e1
would be legal.

If you don't expose package A, then you can only use = B/e1.

In both cases the extended package inherits the = behavior of the
base package.

Brian

> -----Original Message-----
> From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> Sent: Thursday, October 12, 2000 11:55 = AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Audit of packages
>
>
> The idea of supporting extending package but = not supporting
> base package
> is not the basic philosophy of extension of = packages which says that
> extended package inherits the behaviour of base = package.
>
> So do we need to change the basic understanding = of package extensions.
>
>
>
>
>
>
> Dave Sclarsky <dsclarsky@SS7-LINK.COM> on = 10/12/2000 07:44:17 PM
>
> Please respond to Dave Sclarsky = <dsclarsky@SS7-LINK.COM>
>
> To:   = MEGACO@STANDARDS.NORTELNETWORKS.COM
> cc:    (bcc: Sachin = Mittal/HSS)
>
> Subject:  Re: Audit of packages
>
>
>
>
> What do you think about the case where an MG = can support pkg2
> but NOT pkg3?
>
> Take the case of the Tone Detection Package and = the DTMF
> Detection Package
> that extends it.  There are most certainly = 'intelligent'
> devices that are
> capable of reporting DTMF digits, but do not = offer the
> granularity to report
> 'Start tone' or 'End tone' detected.
>
> I would have assumed that an MG with such a = device would
> (should!) publish
> dd but not tonedet, because it really cannot = notify tonedet/std or
> tonedet/etd.
>
> DaveS.
>
>
> -----Original Message-----
> > From: Christian Groves [mailto:Christian.Groves@ER= ICSSON.COM]
> > Sent: Wednesday, October 11, 2000 10:25 = PM
> > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Audit of packages
> >
> >
> > Perhaps we "should" say = "SHALL", I can't think of a case of
> when it is
> > inappropriate and we have the rule saying = that you can address
> > properties by pkg3.
> >
> > But, I'm happy with Should if you can = provide the text when it is
> > inappropriate.
> >
> > Cheers, Christian
> >
> > Peter Blatherwick wrote:
> --------------------------
> >
> > I agree in general, since = "extends" basically means "clone the base
> > package and add some more = functionality" (no subsetting, over-riding
> > etc allowed).  In example below pkg2 = by definition implements pkg3.
> > (Not the case with re-versioning of = Packages though!)
> >
> > One clarification however.  It does = not always make sense for a base
> > package to be published as implemented by = an MG.  There are examples
> > where the base package is defined such = that it acts similar to a
> > virtual class, and has no function on its = own, simply defining
> > interface for one or more derived = packages.  Annex E ToneGen and
> > ToneDet as well as a few packages in Annex = G are examples.
> Therefore,
> > implementer's guide MUST not make a hard = and fast rule on this, but
> > SHOULD say "SHOULD" with some = words to describe where its
> > inappropriate.
> >
> > -- Peter
> >
> > -----Original Message-----
> > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > Sent: Monday, October 09, 2000 = 16:03
> > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Re: Audit of packages
> >
> > We've been around this and basically, it = is up to the MG.
> > It does not HAVE to report pkg3, but it = could.  Maybe SHOULD
> > is a good word, and I wonder if text to = that effect
> > should go in the implementor's = guide?
> >
> > Brian
> >
> > -----Original Message-----
> > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> > Sent: Monday, October 09, 2000 5:12 = AM
> > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > Subject: Audit of packages
> >
> > Say a termination abc implements the = following packages:
> > 1. pkg1
> > 2. pkg2
> > where pkg2 extends pkg3 and pkg1 doesn't = extend any other package
> >
> > If this termination is audited for = packages implemented on it,
> > should the reply include pkg3 with pkg1 = and pkg2 (base package names
> > are included)
> >
> > Sachin
>

------_=_NextPart_001_01C03550.63861000-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Oct 15 08:02:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08106 for ; Sun, 15 Oct 2000 08:02:37 -0400 (EDT) Received: from standards (47.234.32.16:4855) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA452B@standards.nortelnetworks.com>; 15 Oct 2000 7:45:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 14373 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 15 Oct 2000 07:45:55 -0400 Received: from mink.ecitele.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA452A@standards.nortelnetworks.com>; 15 Oct 2000 7:45:54 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id NAA22834 for ; Sun, 15 Oct 2000 13:59:52 +0200 (IST) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3 (Intl)|21 March 2000) at 15/10/2000 02:01:32 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Sun, 15 Oct 2000 13:55:46 +0300 Reply-To: Shlomo.Kabaz@ECITELE.COM Sender: "Media Gateway Control (megaco)" From: Shlomo Kabaz ECItelecom Subject: binary encode/decode in iterOp To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello , everyone ! We are implementing a "trunking gateway" . We would like to know if there is someone , that implements MGC and will have the ability to "talk" binary in the next interOp in january ? and furter more , if you are implementing it , do you have intentions to check it in the next interOp ? Thanks , Shlomo . From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 00:49:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA15359 for ; Mon, 16 Oct 2000 00:49:25 -0400 (EDT) Received: from standards (47.234.32.16:2436) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA47AA@standards.nortelnetworks.com>; Mon, 16 Oct 2000 0:32:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15251 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 00:32:52 -0400 Received: from mars.hss.co.in (202.54.26.197:49953) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA47A8@standards.nortelnetworks.com>; Mon, 16 Oct 2000 0:32:46 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9G4mGC04054; Mon, 16 Oct 2000 10:18:16 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697A.00195947 ; Mon, 16 Oct 2000 10:06:52 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697A.001958B6.00@sandesh.hss.hns.com> Date: Mon, 16 Oct 2000 10:12:20 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: Re: ABNF for topologyDescriptor X-To: "Tulpule, Naren" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Naren, As given in implementor's guide, the tokens are Embed - EM Emergency - EG EventBuffer - EB ( as given in protocol) Chanchal... "Tulpule, Naren" on 10/13/2000 11:30:18 PM Please respond to "Tulpule, Naren" To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Chanchal Hassija/HSS) Subject: ABNF for topologyDescriptor Hi list, in the implementor's guide (B.2), topology descriptor is given as topologyDescriptor = TopologyToken LBRKT *(terminationA COMMA terminationB COMMA topologyDirection) RBRKT What's the seperator between topologyDirection and terminationA? How about COMMA if we haven't agreed on one? And what exactly are the short-form tokens for EventBufferToken, EmergencyToken and EmbedToken? Again, if not decided yet, can we go with EB, EMG and EM? -- Naren. These views and opinions are mine alone, not those of Intel (yet ;-) Narendra C. Tulpule SMTS, Trillium (an Intel company) Ph: +1-310-442-9222 Fax: +1-310-442-1162 12100 Wilshire Bl #1800 Los Angeles, CA 90025 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 02:46:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29783 for ; Mon, 16 Oct 2000 02:46:26 -0400 (EDT) Received: from standards (47.234.32.16:2795) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA47FA@standards.nortelnetworks.com>; Mon, 16 Oct 2000 2:29:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15359 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 02:29:21 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA47F8@standards.nortelnetworks.com>; Mon, 16 Oct 2000 2:19:21 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9G6YLt19232; Mon, 16 Oct 2000 08:34:21 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id IAA27545; Mon, 16 Oct 2000 08:34:21 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id IAA09120; Mon, 16 Oct 2000 08:34:18 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E7D9@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EA9CB2.7E3D63DD@ericsson.com> Date: Mon, 16 Oct 2000 17:14:10 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Audit of packages X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, Below is the text which I propose to put into the implementor's guide. Its a mix of Brian and Pete's proposed words. I note that I changed Brian's MAY to Pete's SHOULD. 9.5 Package Extension and Referencing Description: The current text in H.248 Section 12.1 is ambiguous about the usage of package names when referencing properties, events, signals and statistics in a base package and an extended package. Reference: Subject: Re: Audit of packages Date: Fri, 13 Oct 2000 07:58:12 -0400 From: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: RE: Audit of packages Date: Fri, 13 Oct 2000 15:15:14 -0500 From: "Peter Blatherwick" To: "'Christian Groves'" CC: megaco@standards.nortelnetworks.com, "'Rosen, Brian'" [Begin Clarification] Section 12.1 When packages are extended, the properties, events, signals and statistics defined in the base package can be referred to using the extended package name. For example, if Package A defines event e1, and Package B extends Package A, then B/e1 is an event for a termination implementing Package B. The MG SHOULD also "implement" the base Package. If it does, then A would be reported on the Package Descriptor in AuditValue as well as B, and event A/e1 would be available on a termination. If the MG does not implement A, then only B/e1 would be available. If implemented, A/e1 and B/e1 are the same event. An MG SHOULD publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived. An exception to this is in cases where the base Packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own. [End Clarification] Any problems with the text? Cheers, Christian "Rosen, Brian" wrote: > > We probably need some words in the Implementer's Guide, I agree. > > How about something like: > When packages are extended, the properties, events, signals and statistics > defined in the base package can be referred to using the extended package > name. For example, if Package A defines event e1, and Package B extends > Package A, then B/e1 is an event for a termination implementing Package B. > The MG MAY also "implement" the base Package. If it does, then A would > be reported on the Package Descriptor in AuditValue as well as B, and > event A/e1 would be available on a termination. If the MG does not > implement A, then only B/e1 would be available. Of course, if implemented, > A/e1 and B/e1 are the same event. > > Brian > > > -----Original Message----- > > From: chassija@hss.hns.com [mailto:chassija@hss.hns.com] > > Sent: Friday, October 13, 2000 12:29 AM > > To: Rosen, Brian > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Audit of packages > > > > > > > > > > Hello Brian, > > > > If this is the case as you are pointing out, then it should > > be clearly mentioned > > in the protocol. Because the protocol says only the following > > --- in context of > > Package B extending Package A -- > > > > Sec 12.1.1 - " When a package > > extends another package it shall only add additional Properties, > > Events, Signals, Statistics and new possible values for an > > existing parameter described in the original package. An extended > > package shall not redefine or overload a name defined in the > > original package." > > > > This seems to imply that Package B has to support all the > > events supported on > > Package A...... > > > > What is your opinion on this.... > > Chanchal.... > > > > > > > > > > > > "Rosen, Brian" on 10/13/2000 01:32:21 AM > > > > Please respond to "Rosen, Brian" > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Chanchal Hassija/HSS) > > > > Subject: Re: Audit of packages > > > > > > > > > > I don't think there is any change to the base understanding. > > > > Suppose Package A defines Event e1 > > Suppose Package B extends Package A. > > > > Now, you can talk about A/e1 or B/e1. > > > > If you "expose" package A, then you would include A in the > > list of packages reported on an audit, and A/e1 as well as B/e1 > > would be legal. > > > > If you don't expose package A, then you can only use B/e1. > > > > In both cases the extended package inherits the behavior of the > > base package. > > > > Brian > > > > > -----Original Message----- > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > > Sent: Thursday, October 12, 2000 11:55 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > > > > The idea of supporting extending package but not supporting > > > base package > > > is not the basic philosophy of extension of packages which says that > > > extended package inherits the behaviour of base package. > > > > > > So do we need to change the basic understanding of package > > extensions. > > > > > > > > > > > > > > > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > > > > > Please respond to Dave Sclarsky > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > What do you think about the case where an MG can support pkg2 > > > but NOT pkg3? > > > > > > Take the case of the Tone Detection Package and the DTMF > > > Detection Package > > > that extends it. There are most certainly 'intelligent' > > > devices that are > > > capable of reporting DTMF digits, but do not offer the > > > granularity to report > > > 'Start tone' or 'End tone' detected. > > > > > > I would have assumed that an MG with such a device would > > > (should!) publish > > > dd but not tonedet, because it really cannot notify tonedet/std or > > > tonedet/etd. > > > > > > DaveS. > > > > > > > > > -----Original Message----- > > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > > Sent: Wednesday, October 11, 2000 10:25 PM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Audit of packages > > > > > > > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > > > when it is > > > > inappropriate and we have the rule saying that you can address > > > > properties by pkg3. > > > > > > > > But, I'm happy with Should if you can provide the text when it is > > > > inappropriate. > > > > > > > > Cheers, Christian > > > > > > > > Peter Blatherwick wrote: > > > -------------------------- > > > > > > > > I agree in general, since "extends" basically means > > "clone the base > > > > package and add some more functionality" (no subsetting, > > over-riding > > > > etc allowed). In example below pkg2 by definition > > implements pkg3. > > > > (Not the case with re-versioning of Packages though!) > > > > > > > > One clarification however. It does not always make sense > > for a base > > > > package to be published as implemented by an MG. There > > are examples > > > > where the base package is defined such that it acts similar to a > > > > virtual class, and has no function on its own, simply defining > > > > interface for one or more derived packages. Annex E ToneGen and > > > > ToneDet as well as a few packages in Annex G are examples. > > > Therefore, > > > > implementer's guide MUST not make a hard and fast rule on > > this, but > > > > SHOULD say "SHOULD" with some words to describe where its > > > > inappropriate. > > > > > > > > -- Peter > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > > Sent: Monday, October 09, 2000 16:03 > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Audit of packages > > > > > > > > We've been around this and basically, it is up to the MG. > > > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > > > is a good word, and I wonder if text to that effect > > > > should go in the implementor's guide? > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > > > Sent: Monday, October 09, 2000 5:12 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Audit of packages > > > > > > > > Say a termination abc implements the following packages: > > > > 1. pkg1 > > > > 2. pkg2 > > > > where pkg2 extends pkg3 and pkg1 doesn't extend any other package > > > > > > > > If this termination is audited for packages implemented on it, > > > > should the reply include pkg3 with pkg1 and pkg2 (base > > package names > > > > are included) > > > > > > > > Sachin > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 02:46:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA29786 for ; Mon, 16 Oct 2000 02:46:27 -0400 (EDT) Received: from standards (47.234.32.16:2795) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA47FF@standards.nortelnetworks.com>; Mon, 16 Oct 2000 2:29:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15360 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 02:29:23 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA47F9@standards.nortelnetworks.com>; Mon, 16 Oct 2000 2:19:22 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9G6YDt19154; Mon, 16 Oct 2000 08:34:13 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id IAA27537; Mon, 16 Oct 2000 08:34:13 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id IAA09112; Mon, 16 Oct 2000 08:34:10 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4.2.0.58.J.20001012193528.00bad740@imb.m.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EA95EA.F4989069@ericsson.com> Date: Mon, 16 Oct 2000 16:45:14 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: heart beat message in the megaco protocol X-To: yamamoto.susumu@lab.ntt.co.jp To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Susumu San, Currently there is no mechanism for this in H.248. I thought one way to achieve this would be to send a signal on the Root Termination of the MG that would be an on/off signal which would generate a heartbeart message periodically. But unfortunately we can't a signal (events are OK though)on the root termination. This may be something we want to change. I guess you could always provision some mechanism outside of H.248 also. Cheers, Christian Susumu YAMAMOTO wrote: > > Hi all, > > Is there a heart beat message from MG to MGC in the megaco > protocol? > > If not, how do you think about a heart beat message? > > I think MG always should be able to detect a failure of MGC and > restore the service by failover method, because the case of > restart of MGC, MGC may lost which MG is now in service and > cannot send a handoff message properly. > > Thanks in advance, > -*-*-* > YAMAMOTO SUSUMU > Mega-media Network Systems Project > NTT Network Service Systems Laboratories > mailto: yamamoto.susumu@lab.ntt.co.jp > TEL:+81 422 59 2744 FAX:+81 422 37 7467 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 05:20:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00976 for ; Mon, 16 Oct 2000 05:20:13 -0400 (EDT) Received: from standards (47.234.32.16:2889) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA48D5@standards.nortelnetworks.com>; Mon, 16 Oct 2000 5:03:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15645 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 05:03:23 -0400 Received: from cms1.etri.re.kr by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA48D0@standards.nortelnetworks.com>; Mon, 16 Oct 2000 4:53:22 -0400 Received: by cms1.etri.re.kr with Internet Mail Service (5.5.2650.21) id <46A8384F>; Mon, 16 Oct 2000 18:08:25 +0900 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <49B3518CF9D9D3119246009027A128BB053EA095@cms1.etri.re.kr> Date: Mon, 16 Oct 2000 18:08:24 +0900 Reply-To: =?euc-kr?B?wMzAwLW3?= Sender: "Media Gateway Control (megaco)" From: =?euc-kr?B?wMzAwLW3?= Subject: MEGACO & SIP To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello there, Can you explain the difference between MEGACO & SIP/H.323? I don't know whether MEGACO is a signaling protocol or not. Is MEGACO alway necessary to implement a SIP gateway or H.323 gateway, If that is not a signaling protocol? If MEGACO is not alway necessary, what's their purpose(Reason for using MEGACO)? Thanks. from Eungdon Lee ------------------------------------------------------------------ Eungdon Lee ETRI(Electronics & Telecommunications Research Institute) Tel : 82-42-860-3904 E-mail : edlee@etri.re.kr From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 05:59:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01195 for ; Mon, 16 Oct 2000 05:59:37 -0400 (EDT) Received: from standards (47.234.32.16:4466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA48F8@standards.nortelnetworks.com>; Mon, 16 Oct 2000 5:42:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15693 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 05:42:50 -0400 Received: from euler.ece.iisc.ernet.in by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA48F5@standards.nortelnetworks.com>; Mon, 16 Oct 2000 5:32:31 -0400 Received: from localhost (vijay@localhost) by euler.ece.iisc.ernet.in (8.9.3/8.9.3) with ESMTP id PAA22941; Mon, 16 Oct 2000 15:20:27 +0530 MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Message-ID: Date: Mon, 16 Oct 2000 15:20:26 +0530 Reply-To: Vijayapal Reddy Patil Sender: "Media Gateway Control (megaco)" From: Vijayapal Reddy Patil Subject: Re: MEGACO & SIP X-To: =?euc-kr?B?wMzAwLW3?= To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <49B3518CF9D9D3119246009027A128BB053EA095@cms1.etri.re.kr> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by ietf.org id FAA01195 SIP is used b/w call agents(CA's) while MEGACO is used b/w Gateway and Call Agent. Please let me correct if I am worng. --Vijay On Mon, 16 Oct 2000, [euc-kr] ÀÌÀÀµ· wrote: > Hello there, > Can you explain the difference between MEGACO & SIP/H.323? > > I don't know whether MEGACO is a signaling protocol or not. > Is MEGACO alway necessary to implement a SIP gateway or H.323 gateway, If > that is not a signaling protocol? > > If MEGACO is not alway necessary, what's their purpose(Reason for using > MEGACO)? > > Thanks. > > from Eungdon Lee > > ------------------------------------------------------------------ > Eungdon Lee > ETRI(Electronics & Telecommunications Research Institute) > Tel : 82-42-860-3904 > E-mail : edlee@etri.re.kr > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 06:08:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA01199 for ; Mon, 16 Oct 2000 05:59:38 -0400 (EDT) Received: from standards (47.234.32.16:4466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4900@standards.nortelnetworks.com>; Mon, 16 Oct 2000 5:43:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15706 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 05:43:02 -0400 Received: from mink.ecitele.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA48FF@standards.nortelnetworks.com>; Mon, 16 Oct 2000 5:43:00 -0400 Received: from olive.ecitele.com (ilsmtp04.ecitele.com [147.234.8.125]) by mink.ecitele.com (8.9.1a/8.9.1) with ESMTP id LAA12589 for ; Mon, 16 Oct 2000 11:57:01 +0200 (IST) X-Mailer: Lotus Notes Release 5.0.2b (Intl) 16 December 1999 X-MIMETrack: Serialize by Router on ILSMTP04/ECI Telecom(Release 5.0.3 (Intl)|21 March 2000) at 16/10/2000 11:58:41 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Message-ID: Date: Mon, 16 Oct 2000 11:52:57 +0300 Reply-To: Shlomo.Kabaz@ECITELE.COM Sender: "Media Gateway Control (megaco)" From: Shlomo Kabaz ECItelecom Subject: continuity test To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello all ! Are the tones in the continuity test permanent or do they change ? Thanks , Shlomo . From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 06:10:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01302 for ; Mon, 16 Oct 2000 06:10:13 -0400 (EDT) Received: from standards (47.234.32.16:4466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4932@standards.nortelnetworks.com>; Mon, 16 Oct 2000 5:53:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15770 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 05:53:27 -0400 Received: from smtp1b.mail.yahoo.com (smtp3.mail.yahoo.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4931@standards.nortelnetworks.com>; Mon, 16 Oct 2000 5:53:26 -0400 Received: from ppp-182-150.bng.vsnl.net.in (HELO viswa) (203.197.182.150) by smtp.mail.vip.suc.yahoo.com with SMTP; 16 Oct 2000 10:08:28 -0000 X-Apparently-From: References: <49B3518CF9D9D3119246009027A128BB053EA095@cms1.etri.re.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <002301c03759$6ef99000$8300a8c0@zygox.com> Date: Mon, 16 Oct 2000 15:41:05 +0530 Reply-To: S Viswanatha Sender: "Media Gateway Control (megaco)" From: S Viswanatha Organization: Zygox Subject: Re: MEGACO & SIP To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Check out this site http://www.tradespeak.com/htmldocs/1859.html Brief description of the related protocols has been beautifully described in this white paper. -Viswa ----- Original Message ----- From: ÀÌÀÀµ· To: Sent: Monday, October 16, 2000 2:38 PM Subject: MEGACO & SIP > Hello there, > Can you explain the difference between MEGACO & SIP/H.323? > > I don't know whether MEGACO is a signaling protocol or not. > Is MEGACO alway necessary to implement a SIP gateway or H.323 gateway, If > that is not a signaling protocol? > > If MEGACO is not alway necessary, what's their purpose(Reason for using > MEGACO)? > > Thanks. > > from Eungdon Lee > > ------------------------------------------------------------------ > Eungdon Lee > ETRI(Electronics & Telecommunications Research Institute) > Tel : 82-42-860-3904 > E-mail : edlee@etri.re.kr _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 06:27:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01364 for ; Mon, 16 Oct 2000 06:27:16 -0400 (EDT) Received: from standards (47.234.32.16:4466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA495A@standards.nortelnetworks.com>; Mon, 16 Oct 2000 6:10:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15820 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 06:10:39 -0400 Received: from mars.hss.co.in (202.54.26.197:55148) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4959@standards.nortelnetworks.com>; Mon, 16 Oct 2000 6:10:37 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9GAQHC12660 for ; Mon, 16 Oct 2000 15:56:18 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697A.003849CD ; Mon, 16 Oct 2000 15:44:49 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697A.00384944.00@sandesh.hss.hns.com> Date: Mon, 16 Oct 2000 15:50:19 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Digit map completion event and other events. To: MEGACO@STANDARDS.NORTELNETWORKS.COM In section 7.1.14.7 its mentioned that "While the digit map is activated, detection is enabled for all events defined in the package containing the specified digit map completion event" and "the events in the package containing the specified digit map completion event other than the completion event itself are not individually notified". In next section 7.1.14.8 if item identifier is wildcard, then its mentioned that "Regardless of whether a digit map is activated, if the package also contains the digit events themselves, this form of event specification will cause the individual events to be reported to the MGC as they are detected" These two sections seems to be in conflict with each other. what should be the MG behaviour. -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 06:31:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01408 for ; Mon, 16 Oct 2000 06:31:52 -0400 (EDT) Received: from standards (47.234.32.16:4466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4970@standards.nortelnetworks.com>; Mon, 16 Oct 2000 6:12:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15848 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 06:12:24 -0400 Received: from mars.hss.co.in (202.54.26.197:55168) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA496F@standards.nortelnetworks.com>; Mon, 16 Oct 2000 6:12:22 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9GAS9C12707 for ; Mon, 16 Oct 2000 15:58:09 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697A.003874D6 ; Mon, 16 Oct 2000 15:46:39 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697A.0038732B.00@sandesh.hss.hns.com> Date: Mon, 16 Oct 2000 15:51:20 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Multiple digit maps on a given termination? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Is it possible to define more than one digit map on a given termination. -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 06:31:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA01411 for ; Mon, 16 Oct 2000 06:31:53 -0400 (EDT) Received: from standards (47.234.32.16:4466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4978@standards.nortelnetworks.com>; Mon, 16 Oct 2000 6:13:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 15858 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 06:13:26 -0400 Received: from mars.hss.co.in (202.54.26.197:55179) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4977@standards.nortelnetworks.com>; Mon, 16 Oct 2000 6:13:24 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9GATBC12729 for ; Mon, 16 Oct 2000 15:59:11 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697A.00388C87 ; Mon, 16 Oct 2000 15:47:39 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697A.00388B47.00@sandesh.hss.hns.com> Date: Mon, 16 Oct 2000 15:53:07 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Audit of digit map. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Digit map with name "abc" is defined on a given termination T1. If the digit map is active and MGC overwrites the definition of "abc", its mentioned in protocol that this new definition will be applied only after deactivation of the digit map. If at this momment MGC audits the termination with digit map token, which definition of the digit map "abc" is sent in response. The one that is active or the one that will be applied after digit map deactivation? -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 08:21:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03433 for ; Mon, 16 Oct 2000 08:21:50 -0400 (EDT) Received: from standards (47.234.32.16:1520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA49F8@standards.nortelnetworks.com>; Mon, 16 Oct 2000 8:04:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16031 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 08:04:59 -0400 Received: from mars.hss.co.in (202.54.26.197:56829) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA49F7@standards.nortelnetworks.com>; Mon, 16 Oct 2000 8:04:57 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9GCKhC15958 for ; Mon, 16 Oct 2000 17:50:44 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697A.0042C4DC ; Mon, 16 Oct 2000 17:39:17 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697A.0042C40A.00@sandesh.hss.hns.com> Date: Mon, 16 Oct 2000 17:44:44 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Parameters for properties/statistics. To: MEGACO@STANDARDS.NORTELNETWORKS.COM In a package definition can properties/statistics have parameters? -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 08:26:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03560 for ; Mon, 16 Oct 2000 08:26:27 -0400 (EDT) Received: from standards (47.234.32.16:1520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4A14@standards.nortelnetworks.com>; Mon, 16 Oct 2000 8:08:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16068 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 08:08:15 -0400 Received: from mars.hss.co.in (202.54.26.197:56865) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4A12@standards.nortelnetworks.com>; Mon, 16 Oct 2000 8:08:13 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9GCO1C16015 for ; Mon, 16 Oct 2000 17:54:01 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697A.00431324 ; Mon, 16 Oct 2000 17:42:38 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697A.004312B6.00@sandesh.hss.hns.com> Date: Mon, 16 Oct 2000 17:48:05 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Audit of Event parameters To: MEGACO@STANDARDS.NORTELNETWORKS.COM When MGC issues Audit Value/capability command with Event descriptor token, does MG generates list of events with parameters or without parameters. -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 08:39:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA03861 for ; Mon, 16 Oct 2000 08:39:32 -0400 (EDT) Received: from standards (47.234.32.16:1520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4A8A@standards.nortelnetworks.com>; Mon, 16 Oct 2000 8:22:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16221 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 08:22:49 -0400 Received: from mars.hss.co.in (202.54.26.197:57078) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4A89@standards.nortelnetworks.com>; Mon, 16 Oct 2000 8:22:43 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9GCcGC16419 for ; Mon, 16 Oct 2000 18:08:19 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697A.00445CB0 ; Mon, 16 Oct 2000 17:56:41 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697A.00445B23.00@sandesh.hss.hns.com> Date: Mon, 16 Oct 2000 18:02:07 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Notify command generation. To: MEGACO@STANDARDS.NORTELNETWORKS.COM In section 9.1 its mentioned that "On a given Termination, there should normally be at most one outstanding Notify command at any time." Is this a suggestion for an MG implementation? When MGC enabled multiple events then why to restrict multiple notify generations in case multiple events are reported (with a very small time difference)? -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 09:12:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04632 for ; Mon, 16 Oct 2000 09:12:36 -0400 (EDT) Received: from standards (47.234.32.16:1520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4ACB@standards.nortelnetworks.com>; Mon, 16 Oct 2000 8:55:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16307 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 08:55:58 -0400 Received: from globespan.net (216.6.89.98:4839) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4ACA@standards.nortelnetworks.com>; Mon, 16 Oct 2000 8:55:56 -0400 Received: from hemantag (hemantag.india.ficon-tech.com [172.25.1.135]) by globespan.net (8.9.3/8.9.3) with SMTP id SAA65038 for ; Mon, 16 Oct 2000 18:38:46 +0530 (IST) (envelope-from hemantag@globespan.net) MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <02bc01c03772$401ebe90$870119ac@india.ficontech.com> Date: Mon, 16 Oct 2000 18:38:56 +0530 Reply-To: Hemant Agrawal Sender: "Media Gateway Control (megaco)" From: Hemant Agrawal Organization: GlobeSpan Inc Subject: Selection of Termination To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Tom, Brian & list, w.r.t a old mails of your for choosing termination on the basis on Local or Remote Descriptor " you mentioned (1) If the MGC provides too little information in an Add command for the MG to select the bearer type for that termination, the MG must reject the command with [appropriate error]. In practice, this means either that the terminationID in the command provides the necessary information, or else that at least one instance of a Local or Remote descriptor must be present, containing a c= line with a specified nettype (or the Annex C equivalent)." Is the following command a valid one? what should be the response of this command? As clear from this command, it is asking for selecting a termination? And the SDP desc is having two different types of Network AAL2 and AAL5. Should MG select the termination on first SDP desc. In a command ADD = ${ Media{ Stream= 1 { LocalControl { Mode = SendReceive, ReservedGroup = ON, ReservedValue = ON }, Local{ v=0 c =ATM NSAP $ m= audio $ AAL2/ITU 8 . . v = 0 c =ATM NSAP $ m= audio $ AAL5/ITU 0 . . }}} } As this command gives two choices in the SDP descriptor, either AAL2 type of AAL1 type termination. While processing the media descriptor, the value of RG an RV are ON. that means for both the descriptor, MG has to reserve the resources, Is it meaningful to reserve the resources for second sdp desc, If MG have already chosen the termination of type AAL2. Please comment! Thanks! Hemant Agrawal __________________________________________________ Hemant Agrawal GlobeSpan Inc. Email: hemantag@globespan.net Web: www.globespan.net Tel: +91 575 4544028 x 121 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 09:24:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA04874 for ; Mon, 16 Oct 2000 09:24:36 -0400 (EDT) Received: from standards (47.234.32.16:1520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4B10@standards.nortelnetworks.com>; Mon, 16 Oct 2000 9:07:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16390 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 09:07:44 -0400 Received: from globespan.net (216.6.89.98:1637) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4B0F@standards.nortelnetworks.com>; Mon, 16 Oct 2000 9:07:42 -0400 Received: from hemantag (hemantag.india.ficon-tech.com [172.25.1.135]) by globespan.net (8.9.3/8.9.3) with SMTP id SAA66264; Mon, 16 Oct 2000 18:49:40 +0530 (IST) (envelope-from hemantag@globespan.net) References: <6525697A.0038732B.00@sandesh.hss.hns.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <02f701c03773$c6498e90$870119ac@india.ficontech.com> Date: Mon, 16 Oct 2000 18:49:51 +0530 Reply-To: Hemant Agrawal Sender: "Media Gateway Control (megaco)" From: Hemant Agrawal Organization: GlobeSpan Inc Subject: Re: Multiple digit maps on a given termination? X-To: bmbabu@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit Hi Madhu, A termination can have any number of digitmap defined on it. However only one can be active at a time for digit collection on a termination. Ref. from H.248 "When a DigitMap is defined dynamically in a DigitMap Descriptor: § A new DigitMap is created by specifying a name that is not yet defined. The value shall be present. § A DigitMap value is updated by supplying a new value for a name that is already defined. Terminations presently using the digitmap shall continue to use the old definition; subsequent EventsDescriptors specifying the name, including any EventsDescriptor in the command containing the DigitMap descriptor, shall use the new one. § A DigitMap is deleted by supplying an empty value for a name that is already defined. Terminations presently using the digitmap shall continue to use the old definition" Thanks Hemant ----- Original Message ----- From: Madhu Babu To: Sent: Monday, October 16, 2000 3:51 PM Subject: Multiple digit maps on a given termination? > Is it possible to define more than one digit map on a given termination. > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 10:13:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06114 for ; Mon, 16 Oct 2000 10:13:19 -0400 (EDT) Received: from standards (47.234.32.16:1520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4B65@standards.nortelnetworks.com>; Mon, 16 Oct 2000 9:56:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16507 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 09:56:43 -0400 Received: from mars.hss.co.in (202.54.26.197:57851) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4B64@standards.nortelnetworks.com>; Mon, 16 Oct 2000 9:56:41 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9GECRC17788 for ; Mon, 16 Oct 2000 19:42:28 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697A.004CFD4D ; Mon, 16 Oct 2000 19:30:55 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697A.004CFCAC.00@sandesh.hss.hns.com> Date: Mon, 16 Oct 2000 19:34:11 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Re: ServiceState of a termination To: MEGACO@STANDARDS.NORTELNETWORKS.COM Another question. Is it possible to MODIFY a termination that is "out-of-service"? -Madhubabu Sachin Mittal on 10/12/2000 12:52:31 PM Please respond to samittal@hss.hns.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Madhu B Babu/HSS) Subject: ServiceState of a termination Is the changing of ServiceState of a termination directly from inservice to outofservice and vice-versa allowed in say a Modify. Is this equivalent in functional operation to a ServiceChange on that termination. I believe that the ServiceState values outofservice and inservice are not settable directly my MGC and only indicate the current state that can be modified using SerivceChange. This seems to make ServiceState property as "read-only" type for these two values. But then what about "test" value ? Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 10:39:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06535 for ; Mon, 16 Oct 2000 10:39:02 -0400 (EDT) Received: from standards (47.234.32.16:1520) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4BA4@standards.nortelnetworks.com>; Mon, 16 Oct 2000 10:22:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16595 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 10:22:21 -0400 Received: from smtp4.cluster.oleane.net by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4BA3@standards.nortelnetworks.com>; Mon, 16 Oct 2000 10:22:20 -0400 Received: from oleane (dyn-1-1-025.Vin.dialup.oleane.fr [195.25.4.25]) by smtp4.cluster.oleane.net with SMTP id QAA80089 for ; Mon, 16 Oct 2000 16:37:23 +0200 (CEST) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02A2_01C0378F.2856C4C0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Message-ID: <02a501c0377e$65298240$0401a8c0@oleane.com> Date: Mon, 16 Oct 2000 16:35:56 +0200 Reply-To: Peter Lewis Sender: "Media Gateway Control (megaco)" From: Peter Lewis Subject: VoDSL Europe : the Deployment Scenario To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_02A2_01C0378F.2856C4C0 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable VoDSL Europe : the Deployment Scenario Paris, 16-19 January 2001, second edition Network design, deployments, standardization, softswitch evolution, = management, marketing issues. Get more details on: http://www.upperside.fr/bavodsl2001.htm ------=_NextPart_000_02A2_01C0378F.2856C4C0 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
VoDSL Europe : the Deployment=20 Scenario
Paris, 16-19 January 2001, second = edition
Network design, deployments, standardization, = softswitch=20 evolution, management, marketing issues.
Get more details on:
http://www.upperside.fr/= bavodsl2001.htm
 
 
------=_NextPart_000_02A2_01C0378F.2856C4C0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 11:37:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA07950 for ; Mon, 16 Oct 2000 11:37:42 -0400 (EDT) Received: from standards (47.234.32.16:2232) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4C88@standards.nortelnetworks.com>; Mon, 16 Oct 2000 11:21:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16889 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 11:21:01 -0400 Received: from hvmta03-stg.us.psimail.psi.net (hvmta03-ext.us.psimail.psi.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4C83@standards.nortelnetworks.com>; Mon, 16 Oct 2000 11:11:01 -0400 Received: from dev_4 ([38.150.216.6]) by hvmta03-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001016152601.FKUN24415.hvmta03-stg@dev_4> for ; Mon, 16 Oct 2000 11:26:01 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <003201c03785$7fa4f8f0$70d8a8c0@dev_4.us.radvision.com> Date: Mon, 16 Oct 2000 11:26:47 -0400 Reply-To: delbert@radvision.com Sender: "Media Gateway Control (megaco)" From: Dan Elbert Subject: events on connection To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all in MGCP is possible to apply signals and detect events on a connection as opposed to on an endpoint. What is the equivalent in MEGACO ? Applying the signals/events on an ephemeral termination ? Or is this not possible ? Thanks Dan Elbert RADVISION From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 11:44:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA08203 for ; Mon, 16 Oct 2000 11:44:46 -0400 (EDT) Received: from standards (47.234.32.16:2232) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4CB4@standards.nortelnetworks.com>; Mon, 16 Oct 2000 11:28:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 16890 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 11:28:00 -0400 Received: from ind.alcatel.com (postal.xylan.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4C84@standards.nortelnetworks.com>; Mon, 16 Oct 2000 11:18:00 -0400 Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id IAA10357 for ; Mon, 16 Oct 2000 08:33:06 -0700 (PDT) X-Origination-Site: Received: from newman.xylan.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.1 [HUB])) with ESMTP id IAA11155 for ; Mon, 16 Oct 2000 08:32:46 -0700 (PDT) X-InterScan: Passed Received: from ind.alcatel.com ([127.0.0.1]) by newman.xylan.com (Netscape Messaging Server 3.6) with ESMTP id AAA15F2 for ; Mon, 16 Oct 2000 08:32:45 -0700 X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 References: <6525697A.001958B6.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EB1F8F.F0F440F7@ind.alcatel.com> Date: Mon, 16 Oct 2000 08:32:31 -0700 Reply-To: Isabelle Cnudde Sender: "Media Gateway Control (megaco)" From: Isabelle Cnudde Organization: Alcatel Subject: implementor's guide To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, In several mails, an "implementor's guide" is mentionned. Could you tell me where to find this document? Thanks, Isabelle From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 12:38:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA09596 for ; Mon, 16 Oct 2000 12:38:43 -0400 (EDT) Received: from standards (47.234.32.16:4884) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4D41@standards.nortelnetworks.com>; Mon, 16 Oct 2000 12:22:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17120 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 12:22:05 -0400 Received: from ns1.cirilium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4D34@standards.nortelnetworks.com>; Mon, 16 Oct 2000 12:12:04 -0400 Received: from cirilium1.cirilium.com (mailserver.cirilium.com [207.13.202.13]) by ns1.cirilium.com (8.9.3/8.8.7) with ESMTP id JAA19747; Mon, 16 Oct 2000 09:20:07 -0700 Received: from MRAO ([10.40.3.154]) by cirilium1.cirilium.com (Lotus Domino Release 5.0.3) with SMTP id 2000101609263927:3260 ; Mon, 16 Oct 2000 09:26:39 -0700 References: <4.2.0.58.J.20001012193528.00bad740@imb.m.ecl.ntt.co.jp> <39EA95EA.F4989069@ericsson.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on Cirilium1/Cirilium(Release 5.0.3 |March 21, 2000) at 10/16/2000 09:26:39 AM, Serialize by Router on Cirilium1/Cirilium(Release 5.0.3 |March 21, 2000) at 10/16/2000 09:27:09 AM, Serialize complete at 10/16/2000 09:27:09 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Message-ID: <01d101c0378d$9a063b70$9a03280a@MRAO> Date: Mon, 16 Oct 2000 09:24:47 -0700 Reply-To: Manish Rao Sender: "Media Gateway Control (megaco)" From: Manish Rao Subject: Re: heart beat message in the megaco protocol X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit In my current implementation, I am using audits as a means of acheiving heart beats. The MGC audits the gateways periodically requesting connection ids. This way, the MGC can also say if it is out of sequence perhaps, with the MG (say, the MG returns a connection id, and the MGC does not have one for that endpoint). ----- Original Message ----- From: "Christian Groves" To: Sent: Sunday, October 15, 2000 10:45 PM Subject: Re: heart beat message in the megaco protocol > Hello Susumu San, > > Currently there is no mechanism for this in H.248. I thought one way to > achieve this would be to send a signal on the Root Termination of the MG > that would be an on/off signal which would generate a heartbeart message > periodically. But unfortunately we can't a signal (events are OK > though)on the root termination. This may be something we want to change. > > I guess you could always provision some mechanism outside of H.248 also. > > Cheers, Christian > > Susumu YAMAMOTO wrote: > > > > Hi all, > > > > Is there a heart beat message from MG to MGC in the megaco > > protocol? > > > > If not, how do you think about a heart beat message? > > > > I think MG always should be able to detect a failure of MGC and > > restore the service by failover method, because the case of > > restart of MGC, MGC may lost which MG is now in service and > > cannot send a handoff message properly. > > > > Thanks in advance, > > -*-*-* > > YAMAMOTO SUSUMU > > Mega-media Network Systems Project > > NTT Network Service Systems Laboratories > > mailto: yamamoto.susumu@lab.ntt.co.jp > > TEL:+81 422 59 2744 FAX:+81 422 37 7467 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 13:05:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA10694 for ; Mon, 16 Oct 2000 13:05:42 -0400 (EDT) Received: from standards (47.234.32.16:4884) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4DB1@standards.nortelnetworks.com>; Mon, 16 Oct 2000 12:44:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 17281 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 12:44:09 -0400 Received: from qhars002.nortel.com (47.101.112.102:44689) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA4DB0@standards.nortelnetworks.com>; Mon, 16 Oct 2000 12:44:09 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Mon, 16 Oct 2000 17:58:55 +0100 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 16 Oct 2000 12:55:44 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WQ0Q1K>; Mon, 16 Oct 2000 12:55:44 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03791.E8E17850" X-Orig: Message-ID: <353093573B82D411889E0000F808216648E3FA@zcard00q.ca.nortel.com> Date: Mon, 16 Oct 2000 12:55:38 -0400 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: MEGACO & SIP X-To: "edlee@ETRI.RE.KR" To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03791.E8E17850 Content-Type: text/plain; charset="KS_C_5601-1987" Megaco/H.248 and peer-to-peer protocols such as SIP or H.323 are orthogonal. They solve different aspects of the overall problem of Internet communication systems. Megaco/H.248 is a master/slave protocol for control of gateway functions at the edge of packet networks, for example to control interface functions on IP-PSTN trunking gateways, analog lines gateways, etc. Megaco Protocol (IETF name) and H.248 (ITU-T name) are a single identical protocol solution jointly developed by both ITU and IETF as a single international open standard. The main function of Megaco/H.248 is to allow gateway functions to be decomposed into a call agent part (master), known as Media Gateway Controllers (MGC), containing all call control intelligence, and an gateway interface part (slave), known as Media Gateways (MG), which have no call control intelligence and simply handle making of connection, simple configuration, and possibly user interface. The MGC slave part is dumb from an application perspective, and can therefore be highly optimized for its interface function, and can be physically located separately from the call control intelligence. On the other hand, both SIP and H.323 are peer-to-peer protocols for call control, or more generally multi-media session control. They compete with each other in this space. They both operate at a different level (call control layer) from Megaco/H.248 in a decomposed network, and are thus unaware of whether or not Megaco/H.248 is being used underneath for master/slave control. While Megaco/H.248 is not absolutely necessary in a system to support SIP or H.323 gateway functions, it does allow some very important properties when used (see next). Megaco/H.248 and peer protocols (SIP or H.323) are complementary in nature and entirely compatible within the same system. At a system level, Megaco/H.248 allows for overall network cost and performance optimization, protection of investment by isolation of changes at the call control layer, freedom to geographically distribute both call function and gateway function, and adaptation of legacy equipment. Megaco/H.248 also has a lot of potential for interesting applications in the area of end-user device control, such as master/slave based Internet telephone control. I hope that helps, Peter Blatherwick -----Original Message----- From: edlee@ETRI.RE.KR [mailto:edlee@ETRI.RE.KR] Sent: Monday, October 16, 2000 05:08 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: MEGACO & SIP Hello there, Can you explain the difference between MEGACO & SIP/H.323? I don't know whether MEGACO is a signaling protocol or not. Is MEGACO alway necessary to implement a SIP gateway or H.323 gateway, If that is not a signaling protocol? If MEGACO is not alway necessary, what's their purpose(Reason for using MEGACO)? Thanks. from Eungdon Lee ------------------------------------------------------------------ Eungdon Lee ETRI(Electronics & Telecommunications Research Institute) Tel : 82-42-860-3904 E-mail : edlee@etri.re.kr ------_=_NextPart_001_01C03791.E8E17850 Content-Type: text/html; charset="KS_C_5601-1987" Content-Transfer-Encoding: quoted-printable RE: MEGACO & SIP

Megaco/H.248 and peer-to-peer protocols such as SIP = or H.323 are orthogonal.  They solve different aspects of the = overall problem of Internet communication systems. 

Megaco/H.248 is a master/slave protocol for control = of gateway functions at the edge of packet networks, for example to = control interface functions on IP-PSTN trunking gateways, analog lines = gateways, etc.  Megaco Protocol (IETF name) and H.248 (ITU-T name) = are a single identical protocol solution jointly developed by both ITU = and IETF as a single international open standard.  The main = function of Megaco/H.248 is to allow gateway functions to be decomposed = into a call agent part (master), known as Media Gateway Controllers = (MGC),  containing all call control intelligence, and an gateway = interface part (slave), known as Media Gateways (MG), which have no = call control intelligence and simply handle making of connection, = simple configuration, and possibly user interface.  The MGC slave = part is dumb from an application perspective, and can therefore be = highly optimized for its interface function, and can be physically = located separately from the call control intelligence.   =

On the other hand, both SIP and H.323 are = peer-to-peer protocols for call control, or more generally multi-media = session control.  They compete with each other in this = space.  They both operate at a different level (call control = layer) from Megaco/H.248 in a decomposed network, and are thus unaware = of whether or not Megaco/H.248 is being used underneath for = master/slave control.   While Megaco/H.248 is not absolutely = necessary in a system to support SIP or H.323 gateway functions, it = does allow some very important properties when used (see next).  =

Megaco/H.248 and peer protocols (SIP or H.323) are = complementary in nature and entirely compatible within the same = system.  At a system level, Megaco/H.248 allows for overall = network cost and performance optimization, protection of investment by = isolation of changes at the call control layer, freedom to = geographically distribute both call function and gateway function, and = adaptation of legacy equipment.  Megaco/H.248 also has a lot of = potential for interesting applications in the area of end-user device = control, such as master/slave based Internet telephone control.  =

I hope that helps,
Peter Blatherwick

-----Original Message-----
From: edlee@ETRI.RE.KR [mailto:edlee@ETRI.RE.KR]
Sent: Monday, October 16, 2000 05:08
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: MEGACO & SIP


Hello there,
Can you explain the difference between MEGACO & = SIP/H.323?

I don't know whether MEGACO is a signaling protocol = or not.
Is MEGACO alway necessary to implement a SIP gateway = or H.323 gateway, If
that is not a signaling protocol?

If MEGACO is not alway necessary, what's their = purpose(Reason for using
MEGACO)?

Thanks.

from Eungdon Lee

---------------------------------------------------------------= ---
Eungdon Lee
ETRI(Electronics & Telecommunications Research = Institute)
Tel : 82-42-860-3904
E-mail : edlee@etri.re.kr

------_=_NextPart_001_01C03791.E8E17850-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 17:33:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA16671 for ; Mon, 16 Oct 2000 17:33:16 -0400 (EDT) Received: from standards (47.234.32.16:1088) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5010@standards.nortelnetworks.com>; Mon, 16 Oct 2000 17:16:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18073 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 17:16:36 -0400 Received: from gateway.assuredaccess.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5007@standards.nortelnetworks.com>; Mon, 16 Oct 2000 17:06:35 -0400 Received: from assuredaccess.com ([10.193.100.19]) by gateway.assuredaccess.com (Netscape Mail Server v2.0) with ESMTP id AAA232 for ; Mon, 16 Oct 2000 14:24:06 -0700 X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i686) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EB7287.9A7A0F04@assuredaccess.com> Date: Mon, 16 Oct 2000 14:26:31 -0700 Reply-To: Undetermined origin c/o LISTSERV administrator Sender: "Media Gateway Control (megaco)" Comments: RFC822 error: Incorrect or incomplete address field found and ignored. Comments: RFC822 error: Incorrect or incomplete address field found and ignored. Comments: RFC822 error: Mail origin cannot be determined. Comments: RFC822 error: Original tag data was -> lanc From: Undetermined origin c/o LISTSERV administrator Subject: more info for emergency and priority To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Re: 6.1.1 Context Attributes and Descriptors Can someone provide more info regarding how the emergency and priority context attributes should be implemented ?? Is there any relationship between priority and IP TOs ?? Scheduling of contexts ?? Or is this up to the implementer ?? I found a few notes in the archive, should these be used as guidelines? 1. emergency * connection should be preserved * attempt to re-establish if broken 2. priority * guide allocation of resources (during times of shortage) * calls of lower priority can be cleared if necc to accomodate higher priority calls * highest priority is 15 Thanks in advance for your help, Lan From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 19:15:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA17418 for ; Mon, 16 Oct 2000 19:15:43 -0400 (EDT) Received: from standards (47.234.32.16:3101) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA509F@standards.nortelnetworks.com>; Mon, 16 Oct 2000 18:58:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18266 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 18:58:58 -0400 Received: from gateway.assuredaccess.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA509C@standards.nortelnetworks.com>; Mon, 16 Oct 2000 18:48:58 -0400 Received: from assuredaccess.com ([10.193.6.246]) by gateway.assuredaccess.com (Netscape Mail Server v2.0) with ESMTP id AAA231 for ; Mon, 16 Oct 2000 16:06:29 -0700 X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EB8B47.4B19DEE7@assuredaccess.com> Date: Mon, 16 Oct 2000 16:12:07 -0700 Reply-To: njain@assuredaccess.com Sender: "Media Gateway Control (megaco)" From: Nitin Jain Organization: Assured Access Subject: Manipulating and Auditing Context Attributes. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, The section 8 of RFC 2885, specifies that "Transactions guarantee ordered Command processing. That is, Commands within a Transaction are executed sequentially." However, in section 7.2.9 the RFC says... "If a MG receives an action which contains both a request to audit context attributes and a request to manipulate those attributes, the response SHALL include the values of the attributes after processing the manipulation request." Does that mean that the gateway has to order the commands in an action and process the audits at the very end? In my opinion, it is the responsibility of the gateway controller to send the commands in the order as it desires the response. If the audit command is before the modify, the gateway should return the value before modifying that attribute. Thanks in advance for your input. Nitin Jain From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 16 21:33:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19112 for ; Mon, 16 Oct 2000 21:33:52 -0400 (EDT) Received: from standards (47.234.32.16:1139) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA50F9@standards.nortelnetworks.com>; Mon, 16 Oct 2000 21:17:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 18376 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 16 Oct 2000 21:17:14 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA50F6@standards.nortelnetworks.com>; Mon, 16 Oct 2000 21:07:14 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9H1MIZ08151 for ; Tue, 17 Oct 2000 03:22:18 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA03854; Tue, 17 Oct 2000 03:22:17 +0200 (MET DST) Received: from ericsson.com (7-157.epa.ericsson.se [146.11.7.157]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA14485; Tue, 17 Oct 2000 03:22:14 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EBA9B8.E9FA0633@ericsson.com> Date: Tue, 17 Oct 2000 12:22:00 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Draft H.248 Annex L v2 X-cc: Alf Heidermark To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day All, H.248 Annex L has been updated by the editor Alf Heidermark. Some new text has been added for Service Change Reasons. This document is up for determination at the November SG16. Comment appreciated. It can be found at: ftp://standard.pictel.com/avc-site/Incoming/H248_Annex_L_Draft_v2.pdf Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 01:54:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA28651 for ; Tue, 17 Oct 2000 01:54:28 -0400 (EDT) Received: from standards (47.234.32.16:2619) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA52DF@standards.nortelnetworks.com>; Tue, 17 Oct 2000 1:37:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19033 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 01:37:38 -0400 Received: from tama5.ecl.ntt.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA52DE@standards.nortelnetworks.com>; Tue, 17 Oct 2000 1:37:37 -0400 Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id OAA17581 for ; Tue, 17 Oct 2000 14:52:41 +0900 (JST) (envelope-from yamamoto.susumu@lab.ntt.co.jp) Received: from imb.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id OAA28193 for ; Tue, 17 Oct 2000 14:52:41 +0900 (JST) (envelope-from yamamoto.susumu@lab.ntt.co.jp) Received: from nesoug-host26 ([129.60.11.38]) by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id OAA18764 for ; Tue, 17 Oct 2000 14:52:40 +0900 (JST) X-Sender: sy001@imb.m.ecl.ntt.co.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58.J References: <4.2.0.58.J.20001012193528.00bad740@imb.m.ecl.ntt.co.jp> <39EA95EA.F4989069@ericsson.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: <4.2.0.58.J.20001017111101.00ba9900@imb.m.ecl.ntt.co.jp> Date: Tue, 17 Oct 2000 15:01:11 +0900 Reply-To: yamamoto.susumu@lab.ntt.co.jp Sender: "Media Gateway Control (megaco)" From: Susumu YAMAMOTO Subject: Re: heart beat message in the megaco protocol To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <01d101c0378d$9a063b70$9a03280a@MRAO> Hi all, Please let me correct, if I am wrong. I think heart beat messages are sent rather from MG than from MGC, because in the case of fault of network or MGC only MG can trigger the failover operation to change the MGC and restore the service. I would find some mechanism outside of the H248 for heart beat message from MG, it may be Ping or something. (MGC can audit as heart beat messages as below, but there is no mechanism for MG to send in the H.248.) ... and any other implementation is there ? >In my current implementation, I am using audits as a means of acheiving >heart beats. The MGC audits the gateways periodically requesting connection >ids. This way, the MGC can also say if it is out of sequence perhaps, with >the MG (say, the MG returns a connection id, and the MGC does not have one >for that endpoint). > >----- Original Message ----- >From: "Christian Groves" >To: >Sent: Sunday, October 15, 2000 10:45 PM >Subject: Re: heart beat message in the megaco protocol > > > > Hello Susumu San, > > > > Currently there is no mechanism for this in H.248. I thought one way to > > achieve this would be to send a signal on the Root Termination of the MG > > that would be an on/off signal which would generate a heartbeart message > > periodically. But unfortunately we can't a signal (events are OK > > though)on the root termination. This may be something we want to change. > > > > I guess you could always provision some mechanism outside of H.248 also. > > > > Cheers, Christian > > > > Susumu YAMAMOTO wrote: > > > > > > Hi all, > > > > > > Is there a heart beat message from MG to MGC in the megaco > > > protocol? > > > > > > If not, how do you think about a heart beat message? > > > > > > I think MG always should be able to detect a failure of MGC and > > > restore the service by failover method, because the case of > > > restart of MGC, MGC may lost which MG is now in service and > > > cannot send a handoff message properly. > > > > > > Thanks in advance, > > > -*-*-* > > > YAMAMOTO SUSUMU > > > Mega-media Network Systems Project > > > NTT Network Service Systems Laboratories > > > mailto: yamamoto.susumu@lab.ntt.co.jp > > > TEL:+81 422 59 2744 FAX:+81 422 37 7467 -*-*-* SUSUMU YAMAMOTO Mega-media Network Systems Project NTT Network Service Systems Laboratories mailto: yamamoto.susumu@lab.ntt.co.jp TEL:+81 422 59 2744 FAX:+81 422 37 7467 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 05:58:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA06482 for ; Tue, 17 Oct 2000 05:58:57 -0400 (EDT) Received: from standards (47.234.32.16:4468) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA54F6@standards.nortelnetworks.com>; Tue, 17 Oct 2000 5:42:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19765 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 05:42:10 -0400 Received: from mars.hss.co.in (202.54.26.197:33013) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA54F5@standards.nortelnetworks.com>; Tue, 17 Oct 2000 5:42:07 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9H9vsC03564 for ; Tue, 17 Oct 2000 15:27:55 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697B.0035AD73 ; Tue, 17 Oct 2000 15:16:18 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697B.0035AAC5.00@sandesh.hss.hns.com> Date: Tue, 17 Oct 2000 15:21:40 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: wildcarded termination in Move To: MEGACO@STANDARDS.NORTELNETWORKS.COM If there are three terminations in an MG abcd abce xyz. Say abcd is in Context ID = 1 and both abce and xyz is in NULL Context. If MGC says Move with ContextID = $ and termination as abc*, what should the MG do 1. Consider abce while resolving wildcarded abc* - Move is valid for abcd (it's in non-NULL context) and invalid for abce (move is not allowed to move from and to a NULL Context) 2. Don't consider terminations in NULL Context for resolving wildcard since the basic idea is not to Move to or from NULL Context. The first option has an impact on further commands in the transaction since a failure with one command can cause the side effect of other commands being not executed. Sachin From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 06:56:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA07323 for ; Tue, 17 Oct 2000 06:56:21 -0400 (EDT) Received: from standards (47.234.32.16:4468) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA555F@standards.nortelnetworks.com>; Tue, 17 Oct 2000 6:39:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 19871 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 06:39:27 -0400 Received: from tama5.ecl.ntt.co.jp by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5551@standards.nortelnetworks.com>; Tue, 17 Oct 2000 6:29:27 -0400 Received: from nttmail3.ecl.ntt.co.jp (nttmail3.ecl.ntt.co.jp [129.60.39.100]) by tama5.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/01/21/00) with ESMTP id TAA24003 for ; Tue, 17 Oct 2000 19:44:32 +0900 (JST) (envelope-from sunaga.satoshi@lab.ntt.co.jp) Received: from imb.m.ecl.ntt.co.jp by nttmail3.ecl.ntt.co.jp (8.9.3+3.2W/3.7W/10/05/00) with ESMTP id TAA23277 for ; Tue, 17 Oct 2000 19:44:31 +0900 (JST) (envelope-from sunaga.satoshi@lab.ntt.co.jp) Received: from localhost (fermat.nslab.ecl.ntt.co.jp [129.60.13.78]) by imb.m.ecl.ntt.co.jp (8.9.3/3.7W) with ESMTP id TAA19223 for ; Tue, 17 Oct 2000 19:44:31 +0900 (JST) X-fingerprint: 4E 19 54 2A BE 9F 92 FF 0C E0 08 D7 43 1F 33 E6 X-Mailer: Mew version 1.95b43 on XEmacs 21.1 (Channel Islands) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <20001017.194328.46115365.sunaga.satoshi@fermat.nslab.ecl.ntt.co.jp> Date: Tue, 17 Oct 2000 19:43:28 +0900 Reply-To: Satoshi SUNAGA Sender: "Media Gateway Control (megaco)" From: Satoshi SUNAGA Subject: "Local" part of SDP to the binary data To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Dear Sir, We have a question about H.248(06/00) APPENDIX A EXAMPLE CALL FLOWS(INFORMATIVE) Clause 3 of ITU-T recommendation. Please let me know how we convert the text sample data of "Local" part of SDP(Session Description Protocol) to the binary data. Please advise; (1)How do we convert the "(?)" part of sample data to binary data? For example,we have converted the "V=0" of sample data of SDP to "(2)" part as following. ////ITU-T H.248(06/00) APPENDIX A EXAMPLE CALL FLOWS (INFORMATIVE) Clause 3. sample data 3. The MGC programs a Termination in the NULL context. The terminationId is A4444, the streamId is 1, the requestId in the Events descriptor is 2222. The mId is the identifier of the sender of this message, in this case, it is the IP address and port [123.123.123.4]:55555. Mode for this stream is set to SendReceive. "al" is the analog line supervision package. MGC to MG1: MEGACO/1 [123.123.123.4]:55555 Transaction = 9999 { Context = - { Modify = A4444 { Media { Stream = 1 { LocalControl { Mode = SendReceive, tdmc/gain=2, ; in dB, tdmc/ec=on }, --------------------------------------------- Local { (?)v=0 (?)c=IN IP4 $ (?)m=audio $ RTP/AVP 0 (?)a=fmtp:PCMU VAD=X-NNVAD ; special voice activity ; detection algorithm } --------------------------------------------- (1)How do we convert the "(?)" part of sample data to binary data? } }, Events = 2222 {al/of} } } } ///////////////////// /////////// This is the result that we have edited of the sample data to the binary data. H248_APPENDIX_A.1.1_3.vmd ASN.1(BER): + ASN.1(BER): 250 Bytes : + MegacoMessage + mess ::= Message + version : 1 + mId ::= MId : ip4Address | + ip4Address ::= IP4Address | + address : 123.123.123.4 | + portNumber : 55555 + messageBody : transactions : 1 components + [0] Transaction : transactionRequest + transactionRequest ::= TransactionRequest + transactionId ::= TransactionId : 9999 + actions : 1 components + [0] ActionRequest + contextId ::= ContextID : 0 + commandRequests : 1 components + [0] CommandRequest + command ::= Command : modReq + modReq ::= AmmRequest + terminationID ::= TerminationIDList : 1 components | + [0] TerminationID | + wildcard : 0 components | + id : 3 Bytes | + 0A4444 + descriptors : 2 components + [0] AmmDescriptor : mediaDescriptor | + mediaDescriptor ::= MediaDescriptor | + streams : multiStream : 1 components | + [0] StreamDescriptor | + streamID ::= StreamID : 1 | + streamParms ::= StreamParms | + localControlDescriptor ::= LocalControlDescriptor | | + streamMode ::= StreamMode : sendRecv (2) | | + reserveValue : FALSE | | + reserveGroup : FALSE | | + propertyParms : 2 components | | + [0] PropertyParm | | | + name ::= PkgdName : 4 Bytes | | | | + 000D000A | | | + value : 1 components | | | + [0] OCTET STRING : 2 Bytes | | | + 0002 | | + [1] PropertyParm | | + name ::= PkgdName : 4 Bytes | | | + 000D0008 | | + value : 1 components | | + [0] OCTET STRING : 1 Bytes | | + 01 | + localDescriptor ::= LocalRemoteDescriptor | + propGrps : 1 components | + [0] PropertyGroup : 5 components | + [0] PropertyParm | | + name ::= PkgdName : 4 Bytes | | | + 0000B001 | | + value : 1 components | | + [0] OCTET STRING : 3 Bytes | | + 763D30 (?)We have converted the "V=0" to "763D30",ASCII code. Please advise what we input in this part. | + [1] PropertyParm | | + name ::= PkgdName : 4 Bytes | | | + 0000B008 | | + value : 1 components | | + [0] OCTET STRING : 10 Bytes | | + 633D494E 20495034 2024 | + [2] PropertyParm | | + name ::= PkgdName : 4 Bytes | | | + 00001001 | | + value : 1 components | | + [0] OCTET STRING : 1 Bytes | | + 00 | + [3] PropertyParm | | + name ::= PkgdName : 4 Bytes | | | + 0000100F | | + value : 1 components | | + [0] OCTET STRING : 1 Bytes | | + 00 | + [4] PropertyParm | + name ::= PkgdName : 4 Bytes | | + 0000B00C | + value : 1 components | + [0] OCTET STRING : 21 Bytes | + 666D7470 3A50434D 55205641 443D582D 4E4E5641 44 + [1] AmmDescriptor : eventsDescriptor + eventsDescriptor ::= EventsDescriptor + requestID ::= RequestID : 2222 + eventList : 1 components + [0] RequestedEvent + pkgdName ::= PkgdName : 4 Bytes | + 00090005 + evParList : 0 components Any help you can provide would be appreciated. Thank you. Best regards, Satoshi SUNAGA From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:04:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA08836 for ; Tue, 17 Oct 2000 08:04:14 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA55FD@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:48:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20089 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 07:48:36 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA55FB@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:48:35 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA21949; Tue, 17 Oct 2000 08:03:40 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00556; Tue, 17 Oct 2000 08:03:40 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRQQ68>; Tue, 17 Oct 2000 08:03:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7F8@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 08:03:36 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ABNF for topologyDescriptor X-To: "Tulpule, Naren" To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Hi list, > in the implementor's guide (B.2), topology descriptor is given as > topologyDescriptor = TopologyToken LBRKT *(terminationA COMMA > terminationB COMMA topologyDirection) RBRKT > What's the seperator between topologyDirection and > terminationA? How about > COMMA if we haven't agreed on one? Right, took me a while. The problem occurs when you have more than one topology setting in the descriptor. So the ABNF could be: topologyDescriptor = TopologyToken LBRKT topologyTriple *(COMMA topologyTriple) RBRKT topologyTriple = terminationA COMMA terminationB COMMA topologyDirection Or we can just disallow more than one setting per descriptor Implementor's Guide Note please Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:13:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09037 for ; Tue, 17 Oct 2000 08:13:26 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5660@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:52:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20224 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 07:52:24 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA565F@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:52:24 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22199; Tue, 17 Oct 2000 08:07:29 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA01112; Tue, 17 Oct 2000 08:07:29 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVGBPD>; Tue, 17 Oct 2000 08:07:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7F9@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 08:07:28 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Digit map completion event and other events. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I don't understand the problem. If you just have a digitmap, you don't get NOTIFYied of individual events. If you enable them, you do get the NOTIFYs, and they are used by a digitMap, if enabled. So there are two independent consumers of DTMF digits, they can be enabled separately, or together, MGC choice. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Monday, October 16, 2000 6:20 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Digit map completion event and other events. > > > In section 7.1.14.7 its mentioned that "While the digit map > is activated, detection is enabled for all > events defined in the package containing the > specified digit map completion event" > and "the events in the package containing the specified > digit map completion event other than the > completion event itself are not individually > notified". > > In next section 7.1.14.8 if item identifier is wildcard, then > its mentioned that > "Regardless of whether a digit map is activated, > if the package also contains the digit events > themselves, this form of event specification > will cause the individual events to be > reported to the MGC as they are detected" > > These two sections seems to be in conflict with each other. what > should be the MG behaviour. > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:13:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09041 for ; Tue, 17 Oct 2000 08:13:26 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5672@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:53:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20248 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 07:53:14 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5671@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:53:14 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22247; Tue, 17 Oct 2000 08:08:19 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA01197; Tue, 17 Oct 2000 08:08:19 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVGBPK>; Tue, 17 Oct 2000 08:08:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7FA@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 08:08:18 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Multiple digit maps on a given termination? X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Depends what you mean by "define". You can have multiple digitmaps defined by name, but only one can be active at one time. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Monday, October 16, 2000 6:21 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Multiple digit maps on a given termination? > > > Is it possible to define more than one digit map on a given > termination. > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:13:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09050 for ; Tue, 17 Oct 2000 08:13:27 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5682@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:54:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20270 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 07:54:16 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5681@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:54:16 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22319; Tue, 17 Oct 2000 08:09:21 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA01295; Tue, 17 Oct 2000 08:09:22 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRQQ9N>; Tue, 17 Oct 2000 08:09:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7FB@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 08:09:20 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Audit of digit map. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM The active one. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Monday, October 16, 2000 6:23 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Audit of digit map. > > > Digit map with name "abc" is defined on a given termination > T1. If the digit map > is active and MGC overwrites the definition of "abc", its > mentioned in protocol > that this new definition will be applied only after > deactivation of the digit > map. > If at this momment MGC audits the termination with digit map > token, which > definition of the digit map "abc" is sent in response. The > one that is active or > the > one that will be applied after digit map deactivation? > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:13:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09060 for ; Tue, 17 Oct 2000 08:13:27 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5691@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:54:55 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20288 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 07:54:55 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA568F@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:54:54 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22355; Tue, 17 Oct 2000 08:10:00 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA01375; Tue, 17 Oct 2000 08:10:00 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVGBP9>; Tue, 17 Oct 2000 08:09:58 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7FC@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 08:09:55 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Parameters for properties/statistics. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM No, at least as currently defined. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Monday, October 16, 2000 8:15 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Parameters for properties/statistics. > > > In a package definition can properties/statistics have parameters? > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:13:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09073 for ; Tue, 17 Oct 2000 08:13:28 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA56B3@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:55:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20331 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 07:55:28 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA56B2@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:55:28 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22383; Tue, 17 Oct 2000 08:10:33 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA01435; Tue, 17 Oct 2000 08:10:33 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRQQ9W>; Tue, 17 Oct 2000 08:10:27 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7FD@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 08:10:31 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Audit of Event parameters X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM With Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Monday, October 16, 2000 8:18 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Audit of Event parameters > > > When MGC issues Audit Value/capability command with Event > descriptor token, does > MG generates list of events with parameters or without parameters. > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:23:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09470 for ; Tue, 17 Oct 2000 08:23:04 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA572A@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:58:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20488 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 07:58:39 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5729@standards.nortelnetworks.com>; Tue, 17 Oct 2000 7:58:39 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22556; Tue, 17 Oct 2000 08:13:43 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA02082; Tue, 17 Oct 2000 08:13:43 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVGBTX>; Tue, 17 Oct 2000 08:13:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7FE@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 08:13:40 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Notify command generation. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a suggestion for MG implementation. Perhaps some rewording would be helpful. The intent is to suggest that the MG not send a Notify if it has already sent one, but it has not gotten a reply. A single transaction with multiple Notifies, even on the same termination, is okay. The reason is that with UDP transport, out of order Notifies could cause the MGC to get confused. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Monday, October 16, 2000 8:32 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Notify command generation. > > > In section 9.1 its mentioned that "On a given Termination, > there should normally be at most one > outstanding Notify command at any time." > > > Is this a suggestion for an MG implementation? > When MGC enabled multiple events then why to restrict multiple > notify generations in case multiple events are reported (with a > very small time difference)? > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:23:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09474 for ; Tue, 17 Oct 2000 08:23:05 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5736@standards.nortelnetworks.com>; Tue, 17 Oct 2000 8:01:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20504 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 08:01:08 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5735@standards.nortelnetworks.com>; Tue, 17 Oct 2000 8:01:08 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22756; Tue, 17 Oct 2000 08:16:13 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA02568; Tue, 17 Oct 2000 08:16:13 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRQR14>; Tue, 17 Oct 2000 08:16:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E7FF@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 08:16:07 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ServiceState of a termination X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I say yes in general, but if the termination is "broken" you could get an error if the MG couldn't actually do what you asked it to. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Monday, October 16, 2000 10:04 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: ServiceState of a termination > > > Another question. Is it possible to MODIFY a termination that > is "out-of-service"? > > -Madhubabu > > > > > Sachin Mittal on 10/12/2000 12:52:31 PM > > Please respond to samittal@hss.hns.com > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Madhu B Babu/HSS) > > Subject: ServiceState of a termination > > > > > Is the changing of ServiceState of a termination directly > from inservice to > outofservice and vice-versa allowed > in say a Modify. Is this equivalent in functional operation > to a ServiceChange > on that termination. > > I believe that the ServiceState values outofservice and > inservice are not > settable directly my MGC and only > indicate the current state that can be modified using > SerivceChange. This seems > to make ServiceState property > as "read-only" type for these two values. But then what about > "test" value ? > > Sachin > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:23:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09484 for ; Tue, 17 Oct 2000 08:23:06 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA575A@standards.nortelnetworks.com>; Tue, 17 Oct 2000 8:02:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20547 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 08:02:49 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5759@standards.nortelnetworks.com>; Tue, 17 Oct 2000 8:02:49 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA22845; Tue, 17 Oct 2000 08:17:54 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA02862; Tue, 17 Oct 2000 08:17:54 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRQRF4>; Tue, 17 Oct 2000 08:17:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E800@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 08:17:52 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: events on connection X-To: "delbert@radvision.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM You can get the equivalent in any case I know about. Probably need a specific to really answer your question. All events and statistics are reported on one or more terminations, but you get the right effect AFAIK. Brian > -----Original Message----- > From: Dan Elbert [mailto:delbert@radvision.com] > Sent: Monday, October 16, 2000 11:27 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: events on connection > > > Hi all > in MGCP is possible to apply signals and detect events on a > connection as > opposed to on an endpoint. > What is the equivalent in MEGACO ? Applying the signals/events on an > ephemeral termination ? Or is this not possible ? > > Thanks > > Dan Elbert > RADVISION > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:23:07 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09494 for ; Tue, 17 Oct 2000 08:23:06 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5794@standards.nortelnetworks.com>; Tue, 17 Oct 2000 8:04:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20621 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 08:04:20 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5790@standards.nortelnetworks.com>; Tue, 17 Oct 2000 8:04:19 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA23000; Tue, 17 Oct 2000 08:19:24 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA03124; Tue, 17 Oct 2000 08:19:24 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRQRGN>; Tue, 17 Oct 2000 08:19:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E801@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 08:19:18 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: heart beat message in the megaco protocol X-To: Manish Rao To: MEGACO@STANDARDS.NORTELNETWORKS.COM This sounds like an expensive heartbeat unless the gateway is small. I'd use something else. Brian > -----Original Message----- > From: Manish Rao [mailto:manish_rao@CIRILIUM.COM] > Sent: Monday, October 16, 2000 12:25 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: heart beat message in the megaco protocol > > > In my current implementation, I am using audits as a means of > acheiving > heart beats. The MGC audits the gateways periodically > requesting connection > ids. This way, the MGC can also say if it is out of sequence > perhaps, with > the MG (say, the MG returns a connection id, and the MGC does > not have one > for that endpoint). > > ----- Original Message ----- > From: "Christian Groves" > To: > Sent: Sunday, October 15, 2000 10:45 PM > Subject: Re: heart beat message in the megaco protocol > > > > Hello Susumu San, > > > > Currently there is no mechanism for this in H.248. I > thought one way to > > achieve this would be to send a signal on the Root > Termination of the MG > > that would be an on/off signal which would generate a > heartbeart message > > periodically. But unfortunately we can't a signal (events are OK > > though)on the root termination. This may be something we > want to change. > > > > I guess you could always provision some mechanism outside > of H.248 also. > > > > Cheers, Christian > > > > Susumu YAMAMOTO wrote: > > > > > > Hi all, > > > > > > Is there a heart beat message from MG to MGC in the megaco > > > protocol? > > > > > > If not, how do you think about a heart beat message? > > > > > > I think MG always should be able to detect a failure of MGC and > > > restore the service by failover method, because the case of > > > restart of MGC, MGC may lost which MG is now in service and > > > cannot send a handoff message properly. > > > > > > Thanks in advance, > > > -*-*-* > > > YAMAMOTO SUSUMU > > > Mega-media Network Systems Project > > > NTT Network Service Systems Laboratories > > > mailto: yamamoto.susumu@lab.ntt.co.jp > > > TEL:+81 422 59 2744 FAX:+81 422 37 7467 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:23:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09505 for ; Tue, 17 Oct 2000 08:23:07 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA580F@standards.nortelnetworks.com>; Tue, 17 Oct 2000 8:07:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20786 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 08:07:22 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA580E@standards.nortelnetworks.com>; Tue, 17 Oct 2000 8:07:22 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA23170; Tue, 17 Oct 2000 08:22:27 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA03469; Tue, 17 Oct 2000 08:22:27 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVGBY3>; Tue, 17 Oct 2000 08:22:24 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E802@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 08:22:23 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: heart beat message in the megaco protocol X-To: "yamamoto.susumu@lab.ntt.co.jp" To: MEGACO@STANDARDS.NORTELNETWORKS.COM You can construct a NOP ServiceChange sent from MG to MGC. You can even send an empty NOTIFY I think. Ping is not a really good heartbeat. Brian > -----Original Message----- > From: Susumu YAMAMOTO [mailto:yamamoto.susumu@lab.ntt.co.jp] > Sent: Tuesday, October 17, 2000 2:01 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: heart beat message in the megaco protocol > > > Hi all, > > Please let me correct, if I am wrong. > > I think heart beat messages are sent rather from MG than from > MGC, because > in the case of fault of network or MGC only MG can trigger > the failover > operation > to change the MGC and restore the service. > > I would find some mechanism outside of the H248 for heart > beat message from MG, > it may be Ping or something. > (MGC can audit as heart beat messages as below, but there is > no mechanism for > MG to send in the H.248.) > > ... and any other implementation is there ? > > > >In my current implementation, I am using audits as a means > of acheiving > >heart beats. The MGC audits the gateways periodically > requesting connection > >ids. This way, the MGC can also say if it is out of > sequence perhaps, with > >the MG (say, the MG returns a connection id, and the MGC > does not have one > >for that endpoint). > > > >----- Original Message ----- > >From: "Christian Groves" > >To: > >Sent: Sunday, October 15, 2000 10:45 PM > >Subject: Re: heart beat message in the megaco protocol > > > > > > > Hello Susumu San, > > > > > > Currently there is no mechanism for this in H.248. I > thought one way to > > > achieve this would be to send a signal on the Root > Termination of the MG > > > that would be an on/off signal which would generate a > heartbeart message > > > periodically. But unfortunately we can't a signal (events are OK > > > though)on the root termination. This may be something we > want to change. > > > > > > I guess you could always provision some mechanism outside > of H.248 also. > > > > > > Cheers, Christian > > > > > > Susumu YAMAMOTO wrote: > > > > > > > > Hi all, > > > > > > > > Is there a heart beat message from MG to MGC in the megaco > > > > protocol? > > > > > > > > If not, how do you think about a heart beat message? > > > > > > > > I think MG always should be able to detect a failure of MGC and > > > > restore the service by failover method, because the case of > > > > restart of MGC, MGC may lost which MG is now in service and > > > > cannot send a handoff message properly. > > > > > > > > Thanks in advance, > > > > -*-*-* > > > > YAMAMOTO SUSUMU > > > > Mega-media Network Systems Project > > > > NTT Network Service Systems Laboratories > > > > mailto: yamamoto.susumu@lab.ntt.co.jp > > > > TEL:+81 422 59 2744 FAX:+81 422 37 7467 > > -*-*-* > SUSUMU YAMAMOTO > Mega-media Network Systems Project > NTT Network Service Systems Laboratories > mailto: yamamoto.susumu@lab.ntt.co.jp > TEL:+81 422 59 2744 FAX:+81 422 37 7467 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 08:29:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA09688 for ; Tue, 17 Oct 2000 08:29:40 -0400 (EDT) Received: from standards (47.234.32.16:4386) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5864@standards.nortelnetworks.com>; Tue, 17 Oct 2000 8:12:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 20901 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 08:12:42 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5863@standards.nortelnetworks.com>; Tue, 17 Oct 2000 8:12:41 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA23458; Tue, 17 Oct 2000 08:27:46 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA04437; Tue, 17 Oct 2000 08:27:46 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRQRLB>; Tue, 17 Oct 2000 08:27:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E803@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 08:27:41 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: wildcarded termination in Move X-To: "samittal@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM > If there are three terminations in an MG > abcd > abce > xyz. > Say abcd is in Context ID = 1 and both abce and xyz is in > NULL Context. > If MGC says Move with ContextID = $ and termination as abc*, > what should the > MG do First of all, I think this is illegal, or at least nonsensical. You CAN'T create a new contextId with CHOOSE. So if it is legal, you are asking for Russian Roulette - pick a context where the resulting command would be legal, and do it. If there is more than one, then it's random which one > 1. Consider abce while resolving wildcarded abc* - > Move is valid for abcd (it's in non-NULL context) and invalid for > abce (move is not allowed to move from and to a NULL Context) abcd is valid, abce is not valid > 2. Don't consider terminations in NULL Context for resolving > wildcard since > the basic idea is not to Move to or from NULL Context. This is correct > > The first option has an impact on further commands in the > transaction since a > failure > with one command can cause the side effect of other commands > being not executed. True, but in general if the MGC was foolish enough to do this, it deserves what it gets. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 10:01:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12153 for ; Tue, 17 Oct 2000 10:01:42 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA590B@standards.nortelnetworks.com>; Tue, 17 Oct 2000 9:44:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21118 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 09:44:43 -0400 Received: from hvmta02-stg.us.psimail.psi.net (hvmta02-ext.us.psimail.psi.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA590A@standards.nortelnetworks.com>; Tue, 17 Oct 2000 9:44:43 -0400 Received: from dev_4 ([38.150.216.6]) by hvmta02-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001017135950.FBKB26052.hvmta02-stg@dev_4>; Tue, 17 Oct 2000 09:59:50 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Message-ID: <003601c03842$a2920750$70d8a8c0@dev_4.us.radvision.com> Date: Tue, 17 Oct 2000 10:00:41 -0400 Reply-To: delbert@radvision.com Sender: "Media Gateway Control (megaco)" From: Dan Elbert Subject: Re: events on connection X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM In-Reply-To: <4FBEA8857476D311A03300204840E1CF01A6E800@whq-msgusr-02.pit.comms.marconi.com> Content-Transfer-Encoding: 7bit See the following quote from MGCP spec : "In some cases, Call Agents will request the gateway to generate or detect events on connections rather than on the end point itself. For example, gateways may be asked to provide a ringback tone on a connec- tion. When an event shall be applied on a connection, the name of the connection is added to the name of the event, using an "at" sign (@) as a delimiter, as in: G/rt@0A3F58 " What do you think ? This correspond to MEGACO events in ephemeral terminations, or just regular events on physical terminations ? Dan Elbert RADVISION > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Sent: Tuesday, October 17, 2000 8:18 AM > To: 'delbert@radvision.com'; MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: RE: events on connection > > > You can get the equivalent in any case I know about. Probably need > a specific to really answer your question. All events and statistics > are reported on one or more terminations, but you get the right effect > AFAIK. > > Brian > > > -----Original Message----- > > From: Dan Elbert [mailto:delbert@radvision.com] > > Sent: Monday, October 16, 2000 11:27 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: events on connection > > > > > > Hi all > > in MGCP is possible to apply signals and detect events on a > > connection as > > opposed to on an endpoint. > > What is the equivalent in MEGACO ? Applying the signals/events on an > > ephemeral termination ? Or is this not possible ? > > > > Thanks > > > > Dan Elbert > > RADVISION > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 10:24:13 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA12670 for ; Tue, 17 Oct 2000 10:24:13 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA596C@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:01:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 21239 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 10:01:06 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA596B@standards.nortelnetworks.com>; Tue, 17 Oct 2000 10:01:04 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA05431; Tue, 17 Oct 2000 10:16:08 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA02649; Tue, 17 Oct 2000 10:16:09 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRQ43F>; Tue, 17 Oct 2000 10:16:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E805@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 10:16:07 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: events on connection X-To: "delbert@radvision.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM > "In some cases, Call Agents will request the gateway to generate or > detect events on connections rather than on the end point itself. For > example, gateways may be asked to provide a ringback tone on a connec- > tion. When an event shall be applied on a connection, the name of the > connection is added to the name of the event, using an "at" > sign (@) as > a delimiter, as in: > > G/rt@0A3F58 > " > > What do you think ? > This correspond to MEGACO events in ephemeral terminations, > or just regular > events on physical terminations ? I was always confused my MGCP in this regard. If the originating end is the MG, and the terminating end is across the network, then ringback is provided to the ephemeral (e.g. RTP) termination. I'm not sure that the "connection" is, in all cases, the ephemeral. The ephemeral represents the network side (e,g. RTP) side of the context. If that's what you want the signal/event on, then yes, the ephemeral termination is what you want. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 12:37:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16030 for ; Tue, 17 Oct 2000 12:37:28 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5D39@standards.nortelnetworks.com>; Tue, 17 Oct 2000 12:20:12 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22532 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 12:20:12 -0400 Received: from ns1.cirilium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5D38@standards.nortelnetworks.com>; Tue, 17 Oct 2000 12:20:11 -0400 Received: from cirilium1.cirilium.com (mailserver.cirilium.com [207.13.202.13]) by ns1.cirilium.com (8.9.3/8.8.7) with ESMTP id JAA24620; Tue, 17 Oct 2000 09:28:17 -0700 Received: from MRAO ([10.40.3.154]) by cirilium1.cirilium.com (Lotus Domino Release 5.0.3) with SMTP id 2000101709345382:3802 ; Tue, 17 Oct 2000 09:34:53 -0700 References: <4FBEA8857476D311A03300204840E1CF01A6E801@whq-msgusr-02.pit.comms.marconi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on Cirilium1/Cirilium(Release 5.0.3 |March 21, 2000) at 10/17/2000 09:34:53 AM, Serialize by Router on Cirilium1/Cirilium(Release 5.0.3 |March 21, 2000) at 10/17/2000 09:35:24 AM, Serialize complete at 10/17/2000 09:35:24 AM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Message-ID: <029101c03857$e62c5870$9a03280a@MRAO> Date: Tue, 17 Oct 2000 09:32:54 -0700 Reply-To: Manish Rao Sender: "Media Gateway Control (megaco)" From: Manish Rao Subject: Re: heart beat message in the megaco protocol X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Well, the MGC only sends the heart beat audits out when it hasnt heard from the gateway over a specified period of time. This is usually when all ports on the gateway are idle (in which case it really is not that expensive as no voice/H.248 traffic is going on), or all ports have active calls or are performing operations which do not need communication with the MGC for a long duration--the specified period (in which case I still dont think its that expensive). As for the gateway, I really dont have a heart beat from the MG to the MGC. When a message needs to be delivered from the MG to the MGC--I have a UDP implementation by the way--and my number of retransmits has reached 1/2 MAX_RETRANSMITS, I begin to inquire about alternate MGCs (from the primary MGC), so that as soon as MAX_RETRANSMITS has been reached, the message is immediately transfered over to the alternate MG. This has seemed to work, and the result is that you have at most one or 2 calls that are delayed because of the retransmits. What I do need to implement is for the primary MGC to detect that any one of the MGCs has failed, and then contact that MGs associated with the failed MGC to be transfered over to a new MGC. Well, this is my implementation, and any comments would be appreciated. Hope this helps, Manish Rao Software Engineer Cirilium Corporation manish_rao@cirilium.com ----- Original Message ----- From: "Rosen, Brian" To: Sent: Tuesday, October 17, 2000 5:19 AM Subject: Re: heart beat message in the megaco protocol > This sounds like an expensive heartbeat unless the gateway is small. > I'd use something else. > > Brian > > > -----Original Message----- > > From: Manish Rao [mailto:manish_rao@CIRILIUM.COM] > > Sent: Monday, October 16, 2000 12:25 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: heart beat message in the megaco protocol > > > > > > In my current implementation, I am using audits as a means of > > acheiving > > heart beats. The MGC audits the gateways periodically > > requesting connection > > ids. This way, the MGC can also say if it is out of sequence > > perhaps, with > > the MG (say, the MG returns a connection id, and the MGC does > > not have one > > for that endpoint). > > > > ----- Original Message ----- > > From: "Christian Groves" > > To: > > Sent: Sunday, October 15, 2000 10:45 PM > > Subject: Re: heart beat message in the megaco protocol > > > > > > > Hello Susumu San, > > > > > > Currently there is no mechanism for this in H.248. I > > thought one way to > > > achieve this would be to send a signal on the Root > > Termination of the MG > > > that would be an on/off signal which would generate a > > heartbeart message > > > periodically. But unfortunately we can't a signal (events are OK > > > though)on the root termination. This may be something we > > want to change. > > > > > > I guess you could always provision some mechanism outside > > of H.248 also. > > > > > > Cheers, Christian > > > > > > Susumu YAMAMOTO wrote: > > > > > > > > Hi all, > > > > > > > > Is there a heart beat message from MG to MGC in the megaco > > > > protocol? > > > > > > > > If not, how do you think about a heart beat message? > > > > > > > > I think MG always should be able to detect a failure of MGC and > > > > restore the service by failover method, because the case of > > > > restart of MGC, MGC may lost which MG is now in service and > > > > cannot send a handoff message properly. > > > > > > > > Thanks in advance, > > > > -*-*-* > > > > YAMAMOTO SUSUMU > > > > Mega-media Network Systems Project > > > > NTT Network Service Systems Laboratories > > > > mailto: yamamoto.susumu@lab.ntt.co.jp > > > > TEL:+81 422 59 2744 FAX:+81 422 37 7467 > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 12:58:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA16749 for ; Tue, 17 Oct 2000 12:58:24 -0400 (EDT) Received: from standards (47.234.32.16:1249) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5D7D@standards.nortelnetworks.com>; Tue, 17 Oct 2000 12:34:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 22626 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 12:34:25 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5D7C@standards.nortelnetworks.com>; Tue, 17 Oct 2000 12:34:24 -0400 Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id JAA16598; Tue, 17 Oct 2000 09:49:30 -0700 (PDT) Received: from cisco.com (dhcp-128-107-133-58.cisco.com [128.107.133.58]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AGT06327 (AUTH pmelanah); Tue, 17 Oct 2000 09:49:28 -0700 (PDT) X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E801@whq-msgusr-02.pit.comms.marconi.com> <029101c03857$e62c5870$9a03280a@MRAO> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EC82C9.2D6A6702@cisco.com> Date: Tue, 17 Oct 2000 09:48:09 -0700 Reply-To: Paddu Melanahalli Sender: "Media Gateway Control (megaco)" From: Paddu Melanahalli Organization: NSSU (Cisco's call agent "MGC" development Team), Cisco Systems, Inc Subject: Re: heart beat message in the megaco protocol X-To: Manish Rao To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit What in the case of megaco supporting ip-redundant configuration? In my opinion, sooner we detect the ip connectivity failures better we can service & improve call failure rates. I think we need to run a sort of heartbeat all the times at the provisioned intervals. ~Paddu Manish Rao wrote: > > Well, the MGC only sends the heart beat audits out when it hasnt heard from > the gateway over a specified period of time. This is usually when all ports > on the gateway are idle (in which case it really is not that expensive as no > voice/H.248 traffic is going on), or all ports have active calls or are > performing operations which do not need communication with the MGC for a > long duration--the specified period (in which case I still dont think its > that expensive). As for the gateway, I really dont have a heart beat from > the MG to the MGC. When a message needs to be delivered from the MG to the > MGC--I have a UDP implementation by the way--and my number of retransmits > has reached 1/2 MAX_RETRANSMITS, I begin to inquire about alternate MGCs > (from the primary MGC), so that as soon as MAX_RETRANSMITS has been reached, > the message is immediately transfered over to the alternate MG. This has > seemed to work, and the result is that you have at most one or 2 calls that > are delayed because of the retransmits. What I do need to implement is for > the primary MGC to detect that any one of the MGCs has failed, and then > contact that MGs associated with the failed MGC to be transfered over to a > new MGC. Well, this is my implementation, and any comments would be > appreciated. Hope this helps, > > Manish Rao > Software Engineer > Cirilium Corporation > manish_rao@cirilium.com > > ----- Original Message ----- > From: "Rosen, Brian" > To: > Sent: Tuesday, October 17, 2000 5:19 AM > Subject: Re: heart beat message in the megaco protocol > > > This sounds like an expensive heartbeat unless the gateway is small. > > I'd use something else. > > > > Brian > > > > > -----Original Message----- > > > From: Manish Rao [mailto:manish_rao@CIRILIUM.COM] > > > Sent: Monday, October 16, 2000 12:25 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: heart beat message in the megaco protocol > > > > > > > > > In my current implementation, I am using audits as a means of > > > acheiving > > > heart beats. The MGC audits the gateways periodically > > > requesting connection > > > ids. This way, the MGC can also say if it is out of sequence > > > perhaps, with > > > the MG (say, the MG returns a connection id, and the MGC does > > > not have one > > > for that endpoint). > > > > > > ----- Original Message ----- > > > From: "Christian Groves" > > > To: > > > Sent: Sunday, October 15, 2000 10:45 PM > > > Subject: Re: heart beat message in the megaco protocol > > > > > > > > > > Hello Susumu San, > > > > > > > > Currently there is no mechanism for this in H.248. I > > > thought one way to > > > > achieve this would be to send a signal on the Root > > > Termination of the MG > > > > that would be an on/off signal which would generate a > > > heartbeart message > > > > periodically. But unfortunately we can't a signal (events are OK > > > > though)on the root termination. This may be something we > > > want to change. > > > > > > > > I guess you could always provision some mechanism outside > > > of H.248 also. > > > > > > > > Cheers, Christian > > > > > > > > Susumu YAMAMOTO wrote: > > > > > > > > > > Hi all, > > > > > > > > > > Is there a heart beat message from MG to MGC in the megaco > > > > > protocol? > > > > > > > > > > If not, how do you think about a heart beat message? > > > > > > > > > > I think MG always should be able to detect a failure of MGC and > > > > > restore the service by failover method, because the case of > > > > > restart of MGC, MGC may lost which MG is now in service and > > > > > cannot send a handoff message properly. > > > > > > > > > > Thanks in advance, > > > > > -*-*-* > > > > > YAMAMOTO SUSUMU > > > > > Mega-media Network Systems Project > > > > > NTT Network Service Systems Laboratories > > > > > mailto: yamamoto.susumu@lab.ntt.co.jp > > > > > TEL:+81 422 59 2744 FAX:+81 422 37 7467 > > > -- Enthusiasm You can do anything... if you have Enthusiasm. Enthusiasm is the yeast makes your hopes rise to the stars. Enthusiasm is the sparkle in your eyes. Enthusiasm with it there is accomplishment, without it there are only alibis --- Henry Ford's motto ________________________________________________________ Paddu Melanahalli, Cisco Systems, NSSU Voice:(408)525 5236 Fax: (408)527 1568 Pgr:(408)788 8275 Email: pmelanah@cisco.com ________________________________________________________ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 14:29:11 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA18787 for ; Tue, 17 Oct 2000 14:29:09 -0400 (EDT) Received: from standards (47.234.32.16:3674) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5EE5@standards.nortelnetworks.com>; Tue, 17 Oct 2000 14:12:21 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23074 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 14:12:21 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5EE4@standards.nortelnetworks.com>; Tue, 17 Oct 2000 14:12:20 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA29227; Tue, 17 Oct 2000 14:27:25 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id OAA07571; Tue, 17 Oct 2000 14:27:25 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVGMNH>; Tue, 17 Oct 2000 14:27:22 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E810@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 17 Oct 2000 14:27:20 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: heart beat message in the megaco protocol X-To: Manish Rao To: MEGACO@STANDARDS.NORTELNETWORKS.COM I think this is self defeating - if you are only auditing when there is no traffic, then there is no state to worry about. If there are conditions where there is a lot of state, doing the audit is expensive. I'm not sure what "inquire about alternate MGCs" means. The only way I know to find out about alternate MGCs is a declined initial registration. Brian > -----Original Message----- > From: Manish Rao [mailto:manish_rao@cirilium.com] > Sent: Tuesday, October 17, 2000 12:33 PM > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Re: heart beat message in the megaco protocol > > > Well, the MGC only sends the heart beat audits out when it > hasnt heard from > the gateway over a specified period of time. This is usually > when all ports > on the gateway are idle (in which case it really is not that > expensive as no > voice/H.248 traffic is going on), or all ports have active > calls or are > performing operations which do not need communication with > the MGC for a > long duration--the specified period (in which case I still > dont think its > that expensive). As for the gateway, I really dont have a > heart beat from > the MG to the MGC. When a message needs to be delivered from > the MG to the > MGC--I have a UDP implementation by the way--and my number of > retransmits > has reached 1/2 MAX_RETRANSMITS, I begin to inquire about > alternate MGCs > (from the primary MGC), so that as soon as MAX_RETRANSMITS > has been reached, > the message is immediately transfered over to the alternate > MG. This has > seemed to work, and the result is that you have at most one > or 2 calls that > are delayed because of the retransmits. What I do need to > implement is for > the primary MGC to detect that any one of the MGCs has > failed, and then > contact that MGs associated with the failed MGC to be > transfered over to a > new MGC. Well, this is my implementation, and any comments would be > appreciated. Hope this helps, > > Manish Rao > Software Engineer > Cirilium Corporation > manish_rao@cirilium.com > > ----- Original Message ----- > From: "Rosen, Brian" > To: > Sent: Tuesday, October 17, 2000 5:19 AM > Subject: Re: heart beat message in the megaco protocol > > > > This sounds like an expensive heartbeat unless the gateway is small. > > I'd use something else. > > > > Brian > > > > > -----Original Message----- > > > From: Manish Rao [mailto:manish_rao@CIRILIUM.COM] > > > Sent: Monday, October 16, 2000 12:25 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: heart beat message in the megaco protocol > > > > > > > > > In my current implementation, I am using audits as a means of > > > acheiving > > > heart beats. The MGC audits the gateways periodically > > > requesting connection > > > ids. This way, the MGC can also say if it is out of sequence > > > perhaps, with > > > the MG (say, the MG returns a connection id, and the MGC does > > > not have one > > > for that endpoint). > > > > > > ----- Original Message ----- > > > From: "Christian Groves" > > > To: > > > Sent: Sunday, October 15, 2000 10:45 PM > > > Subject: Re: heart beat message in the megaco protocol > > > > > > > > > > Hello Susumu San, > > > > > > > > Currently there is no mechanism for this in H.248. I > > > thought one way to > > > > achieve this would be to send a signal on the Root > > > Termination of the MG > > > > that would be an on/off signal which would generate a > > > heartbeart message > > > > periodically. But unfortunately we can't a signal (events are OK > > > > though)on the root termination. This may be something we > > > want to change. > > > > > > > > I guess you could always provision some mechanism outside > > > of H.248 also. > > > > > > > > Cheers, Christian > > > > > > > > Susumu YAMAMOTO wrote: > > > > > > > > > > Hi all, > > > > > > > > > > Is there a heart beat message from MG to MGC in the megaco > > > > > protocol? > > > > > > > > > > If not, how do you think about a heart beat message? > > > > > > > > > > I think MG always should be able to detect a failure > of MGC and > > > > > restore the service by failover method, because the case of > > > > > restart of MGC, MGC may lost which MG is now in service and > > > > > cannot send a handoff message properly. > > > > > > > > > > Thanks in advance, > > > > > -*-*-* > > > > > YAMAMOTO SUSUMU > > > > > Mega-media Network Systems Project > > > > > NTT Network Service Systems Laboratories > > > > > mailto: yamamoto.susumu@lab.ntt.co.jp > > > > > TEL:+81 422 59 2744 FAX:+81 422 37 7467 > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 15:25:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19699 for ; Tue, 17 Oct 2000 15:25:59 -0400 (EDT) Received: from standards (47.234.32.16:3674) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5F62@standards.nortelnetworks.com>; Tue, 17 Oct 2000 15:09:19 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23254 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 15:09:18 -0400 Received: from ns1.cirilium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA5F61@standards.nortelnetworks.com>; Tue, 17 Oct 2000 15:09:18 -0400 Received: from cirilium1.cirilium.com (mailserver.cirilium.com [207.13.202.13]) by ns1.cirilium.com (8.9.3/8.8.7) with ESMTP id MAA25674; Tue, 17 Oct 2000 12:17:20 -0700 Received: from MRAO ([10.40.3.154]) by cirilium1.cirilium.com (Lotus Domino Release 5.0.3) with SMTP id 2000101712235807:3932 ; Tue, 17 Oct 2000 12:23:58 -0700 References: <4FBEA8857476D311A03300204840E1CF01A6E810@whq-msgusr-02.pit.comms.marconi.com> MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on Cirilium1/Cirilium(Release 5.0.3 |March 21, 2000) at 10/17/2000 12:23:58 PM, Serialize by Router on Cirilium1/Cirilium(Release 5.0.3 |March 21, 2000) at 10/17/2000 12:24:28 PM, Serialize complete at 10/17/2000 12:24:28 PM Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Message-ID: <02d101c0386f$8407c180$9a03280a@MRAO> Date: Tue, 17 Oct 2000 12:21:57 -0700 Reply-To: Manish Rao Sender: "Media Gateway Control (megaco)" From: Manish Rao Subject: Re: heart beat message in the megaco protocol X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I send audits out when I havent heard from the MG say in over 20 seconds. Suppose my MG supports an E1 (ie 30 channels). Then, if the MGC hasnt heard from any of the 30 channels for over 20 seconds, then it begins auditing the gateway, requesting connection ids. This can happen because a) the MG (all 30 channels) has been idle for 20 seconds b) all channels have active calls that have been running for 20 seconds, in which case it is good to audit, just to make sure the status of the call is ok. I also need to collect RTP stats here (havent done that yet), so may be if there are many packet losses, I can switch to a differenent compression. c) the MG or the LAN/WAN card between the MG and the MGC has failed. If case c applies, then the MGC drops its notion of all active calls and ends any H.323/SIP sessions applicable to the 30 endpoints of the MG, and goes into a state where it waits for a restart message from the MG. This needs to be done to prevent over/under-billing a call etc. I did this coz the Megcao spec did not have a heart beat, and I cant use pings coz the IP interface to my MG is on separate physical card, and the coordination of asking the IP card to send pings on behalf of me is ridiculous. But if Megaco did provide a heart beat mechanism, how would u make it simpler than an audit message? My audit messages request connection ids, which should be maintained in any control blocks allocated (I know im going into implementation details) for calls in the MG, and should be no extra processing really. As far as "inquire about alternate MGCs", the MG sends the same message that it sent to its originally configured MGC (maybe an off-hook), which it thinks it probably cant reach (coz of the 1/2 MAX_RETRANSMITS), to the primary MGC, hoping to obtain another IP address for its notified entity. Once again, what are the other available options? I thought of sending empty notfies as heart beats at one time, but conecptually, a blank notify means "I have detected nothing, although I am still looking for these list of events you have asked me to detect" -- I dont know, seemed more like a hack. Anyway, sorry for this lengthy email, but once again, I would love to receive comments. I am really still not extremely happy with my implementation. Manish Rao Software Engineer Cirilium Corporation manish_rao@cirilium.com ----- Original Message ----- From: "Rosen, Brian" To: "'Manish Rao'" ; Sent: Tuesday, October 17, 2000 11:27 AM Subject: RE: Re: heart beat message in the megaco protocol > I think this is self defeating - if you are only auditing when > there is no traffic, then there is no state to worry about. If > there are conditions where there is a lot of state, doing the audit > is expensive. > > I'm not sure what "inquire about alternate MGCs" means. The only > way I know to find out about alternate MGCs is a declined initial > registration. > > Brian > > > -----Original Message----- > > From: Manish Rao [mailto:manish_rao@cirilium.com] > > Sent: Tuesday, October 17, 2000 12:33 PM > > To: Rosen, Brian; MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Re: heart beat message in the megaco protocol > > > > > > Well, the MGC only sends the heart beat audits out when it > > hasnt heard from > > the gateway over a specified period of time. This is usually > > when all ports > > on the gateway are idle (in which case it really is not that > > expensive as no > > voice/H.248 traffic is going on), or all ports have active > > calls or are > > performing operations which do not need communication with > > the MGC for a > > long duration--the specified period (in which case I still > > dont think its > > that expensive). As for the gateway, I really dont have a > > heart beat from > > the MG to the MGC. When a message needs to be delivered from > > the MG to the > > MGC--I have a UDP implementation by the way--and my number of > > retransmits > > has reached 1/2 MAX_RETRANSMITS, I begin to inquire about > > alternate MGCs > > (from the primary MGC), so that as soon as MAX_RETRANSMITS > > has been reached, > > the message is immediately transfered over to the alternate > > MG. This has > > seemed to work, and the result is that you have at most one > > or 2 calls that > > are delayed because of the retransmits. What I do need to > > implement is for > > the primary MGC to detect that any one of the MGCs has > > failed, and then > > contact that MGs associated with the failed MGC to be > > transfered over to a > > new MGC. Well, this is my implementation, and any comments would be > > appreciated. Hope this helps, > > > > Manish Rao > > Software Engineer > > Cirilium Corporation > > manish_rao@cirilium.com > > > > ----- Original Message ----- > > From: "Rosen, Brian" > > To: > > Sent: Tuesday, October 17, 2000 5:19 AM > > Subject: Re: heart beat message in the megaco protocol > > > > > > > This sounds like an expensive heartbeat unless the gateway is small. > > > I'd use something else. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Manish Rao [mailto:manish_rao@CIRILIUM.COM] > > > > Sent: Monday, October 16, 2000 12:25 PM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: heart beat message in the megaco protocol > > > > > > > > > > > > In my current implementation, I am using audits as a means of > > > > acheiving > > > > heart beats. The MGC audits the gateways periodically > > > > requesting connection > > > > ids. This way, the MGC can also say if it is out of sequence > > > > perhaps, with > > > > the MG (say, the MG returns a connection id, and the MGC does > > > > not have one > > > > for that endpoint). > > > > > > > > ----- Original Message ----- > > > > From: "Christian Groves" > > > > To: > > > > Sent: Sunday, October 15, 2000 10:45 PM > > > > Subject: Re: heart beat message in the megaco protocol > > > > > > > > > > > > > Hello Susumu San, > > > > > > > > > > Currently there is no mechanism for this in H.248. I > > > > thought one way to > > > > > achieve this would be to send a signal on the Root > > > > Termination of the MG > > > > > that would be an on/off signal which would generate a > > > > heartbeart message > > > > > periodically. But unfortunately we can't a signal (events are OK > > > > > though)on the root termination. This may be something we > > > > want to change. > > > > > > > > > > I guess you could always provision some mechanism outside > > > > of H.248 also. > > > > > > > > > > Cheers, Christian > > > > > > > > > > Susumu YAMAMOTO wrote: > > > > > > > > > > > > Hi all, > > > > > > > > > > > > Is there a heart beat message from MG to MGC in the megaco > > > > > > protocol? > > > > > > > > > > > > If not, how do you think about a heart beat message? > > > > > > > > > > > > I think MG always should be able to detect a failure > > of MGC and > > > > > > restore the service by failover method, because the case of > > > > > > restart of MGC, MGC may lost which MG is now in service and > > > > > > cannot send a handoff message properly. > > > > > > > > > > > > Thanks in advance, > > > > > > -*-*-* > > > > > > YAMAMOTO SUSUMU > > > > > > Mega-media Network Systems Project > > > > > > NTT Network Service Systems Laboratories > > > > > > mailto: yamamoto.susumu@lab.ntt.co.jp > > > > > > TEL:+81 422 59 2744 FAX:+81 422 37 7467 > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 19:12:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22383 for ; Tue, 17 Oct 2000 19:12:50 -0400 (EDT) Received: from standards (47.234.32.16:3709) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA60BB@standards.nortelnetworks.com>; Tue, 17 Oct 2000 18:56:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23698 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 18:56:04 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA60B3@standards.nortelnetworks.com>; Tue, 17 Oct 2000 18:46:04 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9HN16Z00711; Wed, 18 Oct 2000 01:01:06 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id BAA08604; Wed, 18 Oct 2000 01:01:05 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id BAA20701; Wed, 18 Oct 2000 01:01:03 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E7FC@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ECB2BD.6353503@ericsson.com> Date: Wed, 18 Oct 2000 07:12:45 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Parameters for properties/statistics. X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Not in the classical sense. You may however construct your property value so that it is structured achieving pretty much the same thing. Cheers, Christian "Rosen, Brian" wrote: > > No, at least as currently defined. > > Brian > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Monday, October 16, 2000 8:15 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Parameters for properties/statistics. > > > > > > In a package definition can properties/statistics have parameters? > > > > -Madhubabu > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 19:12:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA22386 for ; Tue, 17 Oct 2000 19:12:51 -0400 (EDT) Received: from standards (47.234.32.16:3709) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA60C2@standards.nortelnetworks.com>; Tue, 17 Oct 2000 18:56:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23699 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 18:56:09 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA60B4@standards.nortelnetworks.com>; Tue, 17 Oct 2000 18:46:08 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9HN1Et01965; Wed, 18 Oct 2000 01:01:15 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id BAA08613; Wed, 18 Oct 2000 01:01:14 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id BAA20711; Wed, 18 Oct 2000 01:01:12 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E7FE@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39ECB531.1F9DB3AD@ericsson.com> Date: Wed, 18 Oct 2000 07:23:13 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Notify command generation. X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, I agree that this is a little misleading as there may be many events present. Perhaps in the Implementor's Guide we should just strike the sentence? The UDP problem of un-ordered response is described elsewhere. Cheers, Christian "Rosen, Brian" wrote: > > This is a suggestion for MG implementation. Perhaps some rewording > would be helpful. The intent is to suggest that the MG not send > a Notify if it has already sent one, but it has not gotten a reply. > A single transaction with multiple Notifies, even on the same > termination, is okay. The reason is that with UDP transport, out of > order Notifies could cause the MGC to get confused. > > Brian > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Monday, October 16, 2000 8:32 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Notify command generation. > > > > > > In section 9.1 its mentioned that "On a given Termination, > > there should normally be at most one > > outstanding Notify command at any time." > > > > > > Is this a suggestion for an MG implementation? > > When MGC enabled multiple events then why to restrict multiple > > notify generations in case multiple events are reported (with a > > very small time difference)? > > > > -Madhubabu > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 21:47:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25672 for ; Tue, 17 Oct 2000 21:47:25 -0400 (EDT) Received: from standards (47.234.32.16:1765) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA614F@standards.nortelnetworks.com>; Tue, 17 Oct 2000 21:30:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 23905 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 21:30:41 -0400 Received: from mailgate.sbell.com.cn by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA614E@standards.nortelnetworks.com>; Tue, 17 Oct 2000 21:30:40 -0400 Received: from bellnet-mail3.sbell.com.cn (bellnet-mail3.sbell.com.cn [202.96.203.172]) by mailgate.sbell.com.cn (8.9.2/8.9.2) with ESMTP id JAA10112 for ; Wed, 18 Oct 2000 09:37:52 +0800 (CST) Received: by bellnet-mail3.sbell.com.cn with Internet Mail Service (5.5.2650.21) id ; Wed, 18 Oct 2000 09:46:35 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain Message-ID: <77D4835D5290D111B8CC00805FE6AAD504803D97@bellnet-mail1.sbell.com.cn> Date: Wed, 18 Oct 2000 09:42:15 +0800 Reply-To: SRD Tian YaMin Sender: "Media Gateway Control (megaco)" From: SRD Tian YaMin Subject: Re: implementor's guide To: MEGACO@STANDARDS.NORTELNETWORKS.COM > try http://www.packetizer.com/iptel/h248/ > But in my opinion, it's too brief for a implementor. > > Tian Yamin > > >Hi all, > > > >In several mails, an "implementor's guide" is mentionned. > >Could you tell me where to find this document? > > > >Thanks, > >Isabelle > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 17 23:05:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA27707 for ; Tue, 17 Oct 2000 23:05:29 -0400 (EDT) Received: from standards (47.234.32.16:3418) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA619E@standards.nortelnetworks.com>; Tue, 17 Oct 2000 22:48:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24014 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 17 Oct 2000 22:48:50 -0400 Received: from firewall.chttl.com.tw (gate.chttl.com.tw) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA619D@standards.nortelnetworks.com>; Tue, 17 Oct 2000 22:48:48 -0400 Received: from ms.chttl.com.tw (ms.tl.gov.tw. [10.144.2.104]) by firewall.chttl.com.tw (8.9.3/8.9.3) with ESMTP id LAA06744 for ; Wed, 18 Oct 2000 11:03:45 +0800 (CST) Received: from bigmab ([10.144.200.130]) by ms.chttl.com.tw (8.10.2/8.10.2) with SMTP id e9I37eL28241 for ; Wed, 18 Oct 2000 11:07:45 +0800 (CST) References: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.50.4133.2400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Message-ID: <004d01c038af$e2700bc0$82c8900a@chttl.com.tw> Date: Wed, 18 Oct 2000 11:02:38 +0800 Reply-To: "Lien, Yan Tsung" Sender: "Media Gateway Control (megaco)" From: "Lien, Yan Tsung" Subject: How do V.90 modems call each other using MEGACO protocol? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit the scenario is following: PC--modem--PSTN--GW--IP--GW--PSTN--modem--PC From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 00:47:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA29382 for ; Wed, 18 Oct 2000 00:47:09 -0400 (EDT) Received: from standards (47.234.32.16:4367) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA62DC@standards.nortelnetworks.com>; Wed, 18 Oct 2000 0:30:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24439 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 00:30:23 -0400 Received: from mars.hss.co.in (202.54.26.197:39550) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA62DB@standards.nortelnetworks.com>; Wed, 18 Oct 2000 0:30:21 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9I4juC16546; Wed, 18 Oct 2000 10:15:58 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697C.001920F7 ; Wed, 18 Oct 2000 10:04:28 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697C.00192083.00@sandesh.hss.hns.com> Date: Wed, 18 Oct 2000 10:09:58 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: Re: wildcarded termination in Move X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Brian, If you mean to say that Move with ContextID = $ is nonsensical --- I beg to differ...... Consider a simple call scenario -- A is talking to B..... and now A wants to put B on hold and call up C......The simplest way to do it as per my understanding would be -- MGC shall tell MG to Move A to a new context (Move - ContextID=$ and TermID = A) where it shall talk to C, and once it is done, move it back to the context where it was talking to B...... What is your opinion about this.... Thanks Chanchal.... "Rosen, Brian" on 10/17/2000 05:57:41 PM Please respond to "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Chanchal Hassija/HSS) Subject: Re: wildcarded termination in Move > If there are three terminations in an MG > abcd > abce > xyz. > Say abcd is in Context ID = 1 and both abce and xyz is in > NULL Context. > If MGC says Move with ContextID = $ and termination as abc*, > what should the > MG do First of all, I think this is illegal, or at least nonsensical. You CAN'T create a new contextId with CHOOSE. So if it is legal, you are asking for Russian Roulette - pick a context where the resulting command would be legal, and do it. If there is more than one, then it's random which one > 1. Consider abce while resolving wildcarded abc* - > Move is valid for abcd (it's in non-NULL context) and invalid for > abce (move is not allowed to move from and to a NULL Context) abcd is valid, abce is not valid > 2. Don't consider terminations in NULL Context for resolving > wildcard since > the basic idea is not to Move to or from NULL Context. This is correct > > The first option has an impact on further commands in the > transaction since a > failure > with one command can cause the side effect of other commands > being not executed. True, but in general if the MGC was foolish enough to do this, it deserves what it gets. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 02:50:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA12575 for ; Wed, 18 Oct 2000 02:50:21 -0400 (EDT) Received: from standards (47.234.32.16:2427) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6343@standards.nortelnetworks.com>; Wed, 18 Oct 2000 2:33:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24579 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 02:33:24 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6342@standards.nortelnetworks.com>; Wed, 18 Oct 2000 2:23:24 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9I6cVt29883; Wed, 18 Oct 2000 08:38:31 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id IAA14396; Wed, 18 Oct 2000 08:38:30 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id IAA22427; Wed, 18 Oct 2000 08:38:27 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E7F8@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <39ECF450.9283A511@ericsson.com> Date: Wed, 18 Oct 2000 11:52:32 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: ABNF for topologyDescriptor X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit G'Day All, The update I have made is: 6.10 Topology Triples in ABNF Description: In the ABNF (Annex B), the term TopologyDescriptor allows the specification of only one triple. The ASN.1 permits a sequence of such triples. [Begin Correction] B.2 ABNF Specification … topologyDescriptor = TopologyToken LBRKT topologyTriple *(COMMA topologyTriple) RBRKT topologyTriple = terminationA COMMA terminationB COMMA topologyDirection RBRKT [End Correction] Cheers, Christian "Rosen, Brian" wrote: > > > Hi list, > > in the implementor's guide (B.2), topology descriptor is given as > > topologyDescriptor = TopologyToken LBRKT *(terminationA COMMA > > terminationB COMMA topologyDirection) RBRKT > > What's the seperator between topologyDirection and > > terminationA? How about > > COMMA if we haven't agreed on one? > Right, took me a while. The problem occurs when you have more than one > topology setting in the descriptor. > > So the ABNF could be: > topologyDescriptor = TopologyToken LBRKT topologyTriple > *(COMMA topologyTriple) RBRKT > topologyTriple = terminationA COMMA terminationB COMMA topologyDirection > > Or we can just disallow more than one setting per descriptor > > Implementor's Guide Note please Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 07:05:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA15311 for ; Wed, 18 Oct 2000 07:05:00 -0400 (EDT) Received: from standards (47.234.32.16:4674) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6473@standards.nortelnetworks.com>; Wed, 18 Oct 2000 6:48:14 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 24959 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 06:48:14 -0400 Received: from mars.hss.co.in (202.54.26.197:44602) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6472@standards.nortelnetworks.com>; Wed, 18 Oct 2000 6:48:12 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9IB43C25484 for ; Wed, 18 Oct 2000 16:34:04 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697C.003BC034 ; Wed, 18 Oct 2000 16:22:38 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697C.003BC01C.00@sandesh.hss.hns.com> Date: Wed, 18 Oct 2000 16:28:11 +0530 Reply-To: knayar@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Kapil Nayar Subject: Audit Digitmap To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi 7.2.5 AuditValue....specifies the following.... "DigitMapDescriptor returns the name or value of the current DigitMap for the Termination. DigitMap requested in an AuditValue command with TerminationID ALL returns all DigitMaps in the gateway." My questions are: 1. "current" means the "active digit map" or "all the defined digit maps" on the specified termination. 2. If answer to 1 is "all the defined digit maps". Is it that the "global digit maps" defined on the root termination also form part of this group ? 3. If answer to 1 is "current". If terminationId is ALL what do we return: - Only the active digit maps on all the terminations in the gateway. - All the defined digit maps on all the terminations in the gateway. - All the defined digit maps on all the terminations in the gateway including the root termination. If this is the case and we use only the digit map name in Audit response, how does this differentiate between the global digit map and termination specific digit map with the same name. Please clarify. -Kapil Nayar Hughes Software Systems Ltd. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 08:02:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA16854 for ; Wed, 18 Oct 2000 08:02:43 -0400 (EDT) Received: from standards (47.234.32.16:3264) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6541@standards.nortelnetworks.com>; Wed, 18 Oct 2000 7:45:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25209 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 07:45:59 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6540@standards.nortelnetworks.com>; Wed, 18 Oct 2000 7:45:58 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA15971; Wed, 18 Oct 2000 08:01:06 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA19499; Wed, 18 Oct 2000 08:01:08 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVG5N8>; Wed, 18 Oct 2000 08:01:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E815@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 18 Oct 2000 08:01:06 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: wildcarded termination in Move X-To: "chassija@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Only Add can create a new context: "In general, an Add command is used to add Terminations to Contexts. If the MGC does not specify an existing Context to which the Termination is to be added, the MG creates a new Context. " A way to do the consultation hold is to create the new context with C and move A to that Context. I'll note that I was a little surprised to read: "The Termination is either created, or taken from the null Context" (although I may have wrote it!), since this prohibits an Add of a termination already in another context. I'm not sure why we prohibit that. I do think there is little practical difficulty in keeping that restriction. If we did relax that restriction, you could do Context=${Add=A{.... Brian > -----Original Message----- > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > Sent: Wednesday, October 18, 2000 12:40 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: wildcarded termination in Move > > > Hi Brian, > > If you mean to say that Move with ContextID = $ is > nonsensical --- I beg to > differ...... > > Consider a simple call scenario -- A is talking to B..... and > now A wants to put > B on hold and call up C......The simplest way to do it as per > my understanding > would be -- MGC shall tell MG to Move A to a new context > (Move - ContextID=$ and > TermID = A) where it shall talk to C, and once it is done, > move it back to the > context where it was talking to B...... > > What is your opinion about this.... > > Thanks > Chanchal.... > > > > > > > "Rosen, Brian" on 10/17/2000 05:57:41 PM > > Please respond to "Rosen, Brian" > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Chanchal Hassija/HSS) > > Subject: Re: wildcarded termination in Move > > > > > > If there are three terminations in an MG > > abcd > > abce > > xyz. > > Say abcd is in Context ID = 1 and both abce and xyz is in > > NULL Context. > > If MGC says Move with ContextID = $ and termination as abc*, > > what should the > > MG do > First of all, I think this is illegal, or at least nonsensical. > You CAN'T create a new contextId with CHOOSE. > So if it is legal, you are asking for Russian Roulette - pick > a context where the resulting command would be legal, and do it. > If there is more than one, then it's random which one > > > 1. Consider abce while resolving wildcarded abc* - > > Move is valid for abcd (it's in non-NULL context) and invalid for > > abce (move is not allowed to move from and to a NULL Context) > abcd is valid, abce is not valid > > > 2. Don't consider terminations in NULL Context for resolving > > wildcard since > > the basic idea is not to Move to or from NULL Context. > This is correct > > > > > The first option has an impact on further commands in the > > transaction since a > > failure > > with one command can cause the side effect of other commands > > being not executed. > True, but in general if the MGC was foolish enough to do this, > it deserves what it gets. > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 08:31:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA17684 for ; Wed, 18 Oct 2000 08:31:46 -0400 (EDT) Received: from standards (47.234.32.16:3264) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA65AC@standards.nortelnetworks.com>; Wed, 18 Oct 2000 8:14:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25346 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 08:14:54 -0400 Received: from mars.hss.co.in (202.54.26.197:45683) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA65A3@standards.nortelnetworks.com>; Wed, 18 Oct 2000 8:14:50 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9ICTeC27384; Wed, 18 Oct 2000 17:59:44 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697C.00438E7D ; Wed, 18 Oct 2000 17:47:53 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697C.004389B5.00@sandesh.hss.hns.com> Date: Wed, 18 Oct 2000 17:30:32 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: Re: wildcarded termination in Move X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello Brian.... Do we have any logical reasoning to prohibit MOVE of a termination to contextID=$.... apart from the fact that it is stated in the protocol....... Thanks Chanchal..... "Rosen, Brian" on 10/18/2000 05:31:06 PM To: Chanchal Hassija/HSS@HSS, MEGACO@STANDARDS.NORTELNETWORKS.COM cc: Subject: RE: wildcarded termination in Move Only Add can create a new context: "In general, an Add command is used to add Terminations to Contexts. If the MGC does not specify an existing Context to which the Termination is to be added, the MG creates a new Context. " A way to do the consultation hold is to create the new context with C and move A to that Context. I'll note that I was a little surprised to read: "The Termination is either created, or taken from the null Context" (although I may have wrote it!), since this prohibits an Add of a termination already in another context. I'm not sure why we prohibit that. I do think there is little practical difficulty in keeping that restriction. If we did relax that restriction, you could do Context=${Add=A{.... Brian > -----Original Message----- > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > Sent: Wednesday, October 18, 2000 12:40 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: wildcarded termination in Move > > > Hi Brian, > > If you mean to say that Move with ContextID = $ is > nonsensical --- I beg to > differ...... > > Consider a simple call scenario -- A is talking to B..... and > now A wants to put > B on hold and call up C......The simplest way to do it as per > my understanding > would be -- MGC shall tell MG to Move A to a new context > (Move - ContextID=$ and > TermID = A) where it shall talk to C, and once it is done, > move it back to the > context where it was talking to B...... > > What is your opinion about this.... > > Thanks > Chanchal.... > > > > > > > "Rosen, Brian" on 10/17/2000 05:57:41 PM > > Please respond to "Rosen, Brian" > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Chanchal Hassija/HSS) > > Subject: Re: wildcarded termination in Move > > > > > > If there are three terminations in an MG > > abcd > > abce > > xyz. > > Say abcd is in Context ID = 1 and both abce and xyz is in > > NULL Context. > > If MGC says Move with ContextID = $ and termination as abc*, > > what should the > > MG do > First of all, I think this is illegal, or at least nonsensical. > You CAN'T create a new contextId with CHOOSE. > So if it is legal, you are asking for Russian Roulette - pick > a context where the resulting command would be legal, and do it. > If there is more than one, then it's random which one > > > 1. Consider abce while resolving wildcarded abc* - > > Move is valid for abcd (it's in non-NULL context) and invalid for > > abce (move is not allowed to move from and to a NULL Context) > abcd is valid, abce is not valid > > > 2. Don't consider terminations in NULL Context for resolving > > wildcard since > > the basic idea is not to Move to or from NULL Context. > This is correct > > > > > The first option has an impact on further commands in the > > transaction since a > > failure > > with one command can cause the side effect of other commands > > being not executed. > True, but in general if the MGC was foolish enough to do this, > it deserves what it gets. > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 08:45:08 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA18091 for ; Wed, 18 Oct 2000 08:45:08 -0400 (EDT) Received: from standards (47.234.32.16:3264) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA65CC@standards.nortelnetworks.com>; Wed, 18 Oct 2000 8:28:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25387 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 08:28:30 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA65CB@standards.nortelnetworks.com>; Wed, 18 Oct 2000 8:28:30 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA18929; Wed, 18 Oct 2000 08:43:38 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA26746; Wed, 18 Oct 2000 08:43:40 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRRJSF>; Wed, 18 Oct 2000 08:43:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E819@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 18 Oct 2000 08:43:37 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: wildcarded termination in Move X-To: "chassija@hss.hns.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Yes, but it's not all that compelling. Add is a special case of Move - you don't really need Add/Subtract, you could do it all with Move. We tried to keep the functions separate by restricting move to the clear case of from this context to that context, with Add being the command you usually use for creating new contexts or dealing with terminations in null. Like I said, not all that compelling. Brian > -----Original Message----- > From: chassija@hss.hns.com [mailto:chassija@hss.hns.com] > Sent: Wednesday, October 18, 2000 8:01 AM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: RE: wildcarded termination in Move > > > > > Hello Brian.... > > Do we have any logical reasoning to prohibit MOVE of a termination to > contextID=$.... apart from the fact that it is stated in the > protocol....... > > Thanks > Chanchal..... > > > > > > "Rosen, Brian" on 10/18/2000 05:31:06 PM > > To: Chanchal Hassija/HSS@HSS, MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: > > Subject: RE: wildcarded termination in Move > > > > > Only Add can create a new context: > "In general, an Add command is used to add Terminations to Contexts. > If the MGC does not specify an existing Context to which the > Termination is to be added, the MG creates a new Context. " > > A way to do the consultation hold is to create the new context with > C and move A to that Context. > > I'll note that I was a little surprised to read: > "The Termination is either created, or taken from the null Context" > (although I may have wrote it!), since this prohibits an Add of > a termination already in another context. I'm not sure why we > prohibit that. I do think there is little practical difficulty in > keeping that restriction. If we did relax that restriction, you > could do Context=${Add=A{.... > > Brian > > > -----Original Message----- > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > Sent: Wednesday, October 18, 2000 12:40 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: wildcarded termination in Move > > > > > > Hi Brian, > > > > If you mean to say that Move with ContextID = $ is > > nonsensical --- I beg to > > differ...... > > > > Consider a simple call scenario -- A is talking to B..... and > > now A wants to put > > B on hold and call up C......The simplest way to do it as per > > my understanding > > would be -- MGC shall tell MG to Move A to a new context > > (Move - ContextID=$ and > > TermID = A) where it shall talk to C, and once it is done, > > move it back to the > > context where it was talking to B...... > > > > What is your opinion about this.... > > > > Thanks > > Chanchal.... > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 05:57:41 PM > > > > Please respond to "Rosen, Brian" > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Chanchal Hassija/HSS) > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > If there are three terminations in an MG > > > abcd > > > abce > > > xyz. > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > NULL Context. > > > If MGC says Move with ContextID = $ and termination as abc*, > > > what should the > > > MG do > > First of all, I think this is illegal, or at least nonsensical. > > You CAN'T create a new contextId with CHOOSE. > > So if it is legal, you are asking for Russian Roulette - pick > > a context where the resulting command would be legal, and do it. > > If there is more than one, then it's random which one > > > > > 1. Consider abce while resolving wildcarded abc* - > > > Move is valid for abcd (it's in non-NULL context) and invalid for > > > abce (move is not allowed to move from and to a NULL Context) > > abcd is valid, abce is not valid > > > > > 2. Don't consider terminations in NULL Context for resolving > > > wildcard since > > > the basic idea is not to Move to or from NULL Context. > > This is correct > > > > > > > > The first option has an impact on further commands in the > > > transaction since a > > > failure > > > with one command can cause the side effect of other commands > > > being not executed. > > True, but in general if the MGC was foolish enough to do this, > > it deserves what it gets. > > > > Brian > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 09:00:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18621 for ; Wed, 18 Oct 2000 09:00:35 -0400 (EDT) Received: from standards (47.234.32.16:3264) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA65F3@standards.nortelnetworks.com>; Wed, 18 Oct 2000 8:43:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25437 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 08:43:50 -0400 Received: from mars.hss.co.in (202.54.26.197:46093) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA65F2@standards.nortelnetworks.com>; Wed, 18 Oct 2000 8:43:14 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9ICwEC28140; Wed, 18 Oct 2000 18:28:18 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697C.00461538 ; Wed, 18 Oct 2000 18:15:29 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697C.0046124F.00@sandesh.hss.hns.com> Date: Wed, 18 Oct 2000 17:58:55 +0530 Reply-To: knayar@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Kapil Nayar Subject: Re: wildcarded termination in Move X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi If you remove this restriction then why you need Move, i will always use Add to either: 1. Add a termination to a context from null context 2. Move (read it as Add) a termination to a context from a non-NULL context. -Kapil Nayar Hughes Software Systems "Rosen, Brian" on 10/18/2000 05:31:06 PM Please respond to "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Kapil Nayar/HSS) Subject: Re: wildcarded termination in Move Only Add can create a new context: "In general, an Add command is used to add Terminations to Contexts. If the MGC does not specify an existing Context to which the Termination is to be added, the MG creates a new Context. " A way to do the consultation hold is to create the new context with C and move A to that Context. I'll note that I was a little surprised to read: "The Termination is either created, or taken from the null Context" (although I may have wrote it!), since this prohibits an Add of a termination already in another context. I'm not sure why we prohibit that. I do think there is little practical difficulty in keeping that restriction. If we did relax that restriction, you could do Context=${Add=A{.... Brian > -----Original Message----- > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > Sent: Wednesday, October 18, 2000 12:40 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: wildcarded termination in Move > > > Hi Brian, > > If you mean to say that Move with ContextID = $ is > nonsensical --- I beg to > differ...... > > Consider a simple call scenario -- A is talking to B..... and > now A wants to put > B on hold and call up C......The simplest way to do it as per > my understanding > would be -- MGC shall tell MG to Move A to a new context > (Move - ContextID=$ and > TermID = A) where it shall talk to C, and once it is done, > move it back to the > context where it was talking to B...... > > What is your opinion about this.... > > Thanks > Chanchal.... > > > > > > > "Rosen, Brian" on 10/17/2000 05:57:41 PM > > Please respond to "Rosen, Brian" > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Chanchal Hassija/HSS) > > Subject: Re: wildcarded termination in Move > > > > > > If there are three terminations in an MG > > abcd > > abce > > xyz. > > Say abcd is in Context ID = 1 and both abce and xyz is in > > NULL Context. > > If MGC says Move with ContextID = $ and termination as abc*, > > what should the > > MG do > First of all, I think this is illegal, or at least nonsensical. > You CAN'T create a new contextId with CHOOSE. > So if it is legal, you are asking for Russian Roulette - pick > a context where the resulting command would be legal, and do it. > If there is more than one, then it's random which one > > > 1. Consider abce while resolving wildcarded abc* - > > Move is valid for abcd (it's in non-NULL context) and invalid for > > abce (move is not allowed to move from and to a NULL Context) > abcd is valid, abce is not valid > > > 2. Don't consider terminations in NULL Context for resolving > > wildcard since > > the basic idea is not to Move to or from NULL Context. > This is correct > > > > > The first option has an impact on further commands in the > > transaction since a > > failure > > with one command can cause the side effect of other commands > > being not executed. > True, but in general if the MGC was foolish enough to do this, > it deserves what it gets. > > Brian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 09:04:54 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA18728 for ; Wed, 18 Oct 2000 09:04:53 -0400 (EDT) Received: from standards (47.234.32.16:3264) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA660D@standards.nortelnetworks.com>; Wed, 18 Oct 2000 8:47:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 25470 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 08:47:06 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA660C@standards.nortelnetworks.com>; Wed, 18 Oct 2000 8:47:05 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA20456; Wed, 18 Oct 2000 09:02:13 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA01705; Wed, 18 Oct 2000 09:02:15 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVG65Y>; Wed, 18 Oct 2000 09:00:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E81A@whq-msgusr-02.pit.comms.marconi.com> Date: Wed, 18 Oct 2000 09:00:58 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: wildcarded termination in Move X-To: "knayar@hss.hns.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Ya, that's one of the reasons it's probably there - separating functions of Move and Add. Probably best to leave things as they are. Brian > -----Original Message----- > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > Sent: Wednesday, October 18, 2000 8:29 AM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: wildcarded termination in Move > > > > > Hi > > If you remove this restriction then why you need Move, i will > always use Add to > either: > 1. Add a termination to a context from null context > 2. Move (read it as Add) a termination to a context from a > non-NULL context. > > -Kapil Nayar > Hughes Software Systems > > > > > > "Rosen, Brian" on 10/18/2000 05:31:06 PM > > Please respond to "Rosen, Brian" > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Kapil Nayar/HSS) > > Subject: Re: wildcarded termination in Move > > > > > Only Add can create a new context: > "In general, an Add command is used to add Terminations to Contexts. > If the MGC does not specify an existing Context to which the > Termination is to be added, the MG creates a new Context. " > > A way to do the consultation hold is to create the new context with > C and move A to that Context. > > I'll note that I was a little surprised to read: > "The Termination is either created, or taken from the null Context" > (although I may have wrote it!), since this prohibits an Add of > a termination already in another context. I'm not sure why we > prohibit that. I do think there is little practical difficulty in > keeping that restriction. If we did relax that restriction, you > could do Context=${Add=A{.... > > Brian > > > -----Original Message----- > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > Sent: Wednesday, October 18, 2000 12:40 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: wildcarded termination in Move > > > > > > Hi Brian, > > > > If you mean to say that Move with ContextID = $ is > > nonsensical --- I beg to > > differ...... > > > > Consider a simple call scenario -- A is talking to B..... and > > now A wants to put > > B on hold and call up C......The simplest way to do it as per > > my understanding > > would be -- MGC shall tell MG to Move A to a new context > > (Move - ContextID=$ and > > TermID = A) where it shall talk to C, and once it is done, > > move it back to the > > context where it was talking to B...... > > > > What is your opinion about this.... > > > > Thanks > > Chanchal.... > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 05:57:41 PM > > > > Please respond to "Rosen, Brian" > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Chanchal Hassija/HSS) > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > If there are three terminations in an MG > > > abcd > > > abce > > > xyz. > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > NULL Context. > > > If MGC says Move with ContextID = $ and termination as abc*, > > > what should the > > > MG do > > First of all, I think this is illegal, or at least nonsensical. > > You CAN'T create a new contextId with CHOOSE. > > So if it is legal, you are asking for Russian Roulette - pick > > a context where the resulting command would be legal, and do it. > > If there is more than one, then it's random which one > > > > > 1. Consider abce while resolving wildcarded abc* - > > > Move is valid for abcd (it's in non-NULL context) and invalid for > > > abce (move is not allowed to move from and to a NULL Context) > > abcd is valid, abce is not valid > > > > > 2. Don't consider terminations in NULL Context for resolving > > > wildcard since > > > the basic idea is not to Move to or from NULL Context. > > This is correct > > > > > > > > The first option has an impact on further commands in the > > > transaction since a > > > failure > > > with one command can cause the side effect of other commands > > > being not executed. > > True, but in general if the MGC was foolish enough to do this, > > it deserves what it gets. > > > > Brian > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 13:26:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03887 for ; Wed, 18 Oct 2000 13:26:16 -0400 (EDT) Received: from standards (47.234.32.16:2205) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA67DA@standards.nortelnetworks.com>; Wed, 18 Oct 2000 12:21:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26081 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 12:21:44 -0400 Received: from slink12.ss7-link.com (mail.ss7-link.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA67D9@standards.nortelnetworks.com>; Wed, 18 Oct 2000 12:21:44 -0400 Received: by SLINK12 with Internet Mail Service (5.5.2650.21) id <4KWBWZNP>; Wed, 18 Oct 2000 12:34:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Wed, 18 Oct 2000 12:34:22 -0400 Reply-To: Dave Sclarsky Sender: "Media Gateway Control (megaco)" From: Dave Sclarsky Subject: EventBufferDescriptor processing To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello, If an MG receives an EventBufferDescriptor when EventBufferControl=LockStep, are the events currently in the EventBuffer affected (e.g. discarded)? Thanks! ============================ Dave Sclarsky System Architect, Access Technology S-Link Corporation 520 Fellowship Road, Suite C-304 Mt. Laurel, NJ 08054 dsclarsky@ss7-link.com voice:856.642.9229x231 fax:856.642.0252 www.ss7-link.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 14:03:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08530 for ; Wed, 18 Oct 2000 14:03:25 -0400 (EDT) Received: from standards (47.234.32.16:3701) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6843@standards.nortelnetworks.com>; Wed, 18 Oct 2000 13:44:26 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26224 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 13:44:25 -0400 Received: from viggen.broadcom.com (dns.broadcom.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6842@standards.nortelnetworks.com>; Wed, 18 Oct 2000 13:44:25 -0400 Received: from mail-irva-1.broadcom.com (mail-irva-1.broadcom.com [10.4.10.10]) by viggen.broadcom.com (8.9.3/8.9.3/FW03) with ESMTP id KAA09180; Wed, 18 Oct 2000 10:59:31 -0700 (PDT) Received: from dashaus.hothaus.com ([10.136.20.22]) by mail-irva-1.broadcom.com (Post.Office MTA v3.5.3 release 223 ID# 0-69195U3100L500S0V35) with ESMTP id com; Wed, 18 Oct 2000 10:59:29 -0700 Received: by DASHAUS with Internet Mail Service (5.5.2650.21) id <48DTZWVD>; Wed, 18 Oct 2000 10:58:42 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <5713E3714F03D4118AB9009027D5B3A23D0A9B@NT-RMNA-EXCH> Date: Wed, 18 Oct 2000 10:59:02 -0700 Reply-To: Bob Lukas Sender: "Media Gateway Control (megaco)" From: Bob Lukas Subject: Re: wildcarded termination in Move X-To: "Brian.Rosen@marconi.com" To: MEGACO@STANDARDS.NORTELNETWORKS.COM One good reason for allowing MOVE $ is if the MGC wants to implement on-hold by moving the ephermeral RTP termination to a "holding context", rather than moving the physical termination. Another good reason is if the logic of the MGC wants to implement handsfree/handset transfer by moving the existing RTP to a new context, then adding the physical termination. In both these cases, a subtract/add is not equivalent to a move, because the ephermeral termination will get destroyed during the subtract. You could force the MGC developer to modify his logic to do it another way, but why unnecessarily create restrictions. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Wednesday, October 18, 2000 5:44 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: wildcarded termination in Move Yes, but it's not all that compelling. Add is a special case of Move - you don't really need Add/Subtract, you could do it all with Move. We tried to keep the functions separate by restricting move to the clear case of from this context to that context, with Add being the command you usually use for creating new contexts or dealing with terminations in null. Like I said, not all that compelling. Brian > -----Original Message----- > From: chassija@hss.hns.com [mailto:chassija@hss.hns.com] > Sent: Wednesday, October 18, 2000 8:01 AM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: RE: wildcarded termination in Move > > > > > Hello Brian.... > > Do we have any logical reasoning to prohibit MOVE of a termination to > contextID=$.... apart from the fact that it is stated in the > protocol....... > > Thanks > Chanchal..... > > > > > > "Rosen, Brian" on 10/18/2000 05:31:06 PM > > To: Chanchal Hassija/HSS@HSS, MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: > > Subject: RE: wildcarded termination in Move > > > > > Only Add can create a new context: > "In general, an Add command is used to add Terminations to Contexts. > If the MGC does not specify an existing Context to which the > Termination is to be added, the MG creates a new Context. " > > A way to do the consultation hold is to create the new context with > C and move A to that Context. > > I'll note that I was a little surprised to read: > "The Termination is either created, or taken from the null Context" > (although I may have wrote it!), since this prohibits an Add of > a termination already in another context. I'm not sure why we > prohibit that. I do think there is little practical difficulty in > keeping that restriction. If we did relax that restriction, you > could do Context=${Add=A{.... > > Brian > > > -----Original Message----- > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > Sent: Wednesday, October 18, 2000 12:40 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: wildcarded termination in Move > > > > > > Hi Brian, > > > > If you mean to say that Move with ContextID = $ is > > nonsensical --- I beg to > > differ...... > > > > Consider a simple call scenario -- A is talking to B..... and > > now A wants to put > > B on hold and call up C......The simplest way to do it as per > > my understanding > > would be -- MGC shall tell MG to Move A to a new context > > (Move - ContextID=$ and > > TermID = A) where it shall talk to C, and once it is done, > > move it back to the > > context where it was talking to B...... > > > > What is your opinion about this.... > > > > Thanks > > Chanchal.... > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 05:57:41 PM > > > > Please respond to "Rosen, Brian" > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Chanchal Hassija/HSS) > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > If there are three terminations in an MG > > > abcd > > > abce > > > xyz. > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > NULL Context. > > > If MGC says Move with ContextID = $ and termination as abc*, > > > what should the > > > MG do > > First of all, I think this is illegal, or at least nonsensical. > > You CAN'T create a new contextId with CHOOSE. > > So if it is legal, you are asking for Russian Roulette - pick > > a context where the resulting command would be legal, and do it. > > If there is more than one, then it's random which one > > > > > 1. Consider abce while resolving wildcarded abc* - > > > Move is valid for abcd (it's in non-NULL context) and invalid for > > > abce (move is not allowed to move from and to a NULL Context) > > abcd is valid, abce is not valid > > > > > 2. Don't consider terminations in NULL Context for resolving > > > wildcard since > > > the basic idea is not to Move to or from NULL Context. > > This is correct > > > > > > > > The first option has an impact on further commands in the > > > transaction since a > > > failure > > > with one command can cause the side effect of other commands > > > being not executed. > > True, but in general if the MGC was foolish enough to do this, > > it deserves what it gets. > > > > Brian > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 15:09:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA18201 for ; Wed, 18 Oct 2000 15:09:25 -0400 (EDT) Received: from standards (47.234.32.16:3701) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6970@standards.nortelnetworks.com>; Wed, 18 Oct 2000 14:52:15 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26610 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 14:52:15 -0400 Received: from ns1.cirilium.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA696F@standards.nortelnetworks.com>; Wed, 18 Oct 2000 14:52:14 -0400 Received: from cirilium1.cirilium.com (mailserver.cirilium.com [207.13.202.13]) by ns1.cirilium.com (8.9.3/8.8.7) with ESMTP id MAA30962 for ; Wed, 18 Oct 2000 12:00:20 -0700 Received: from MRAO ([10.40.3.154]) by cirilium1.cirilium.com (Lotus Domino Release 5.0.3) with SMTP id 2000101812070265:4543 ; Wed, 18 Oct 2000 12:07:02 -0700 MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6700 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-MIMETrack: Itemize by SMTP Server on Cirilium1/Cirilium(Release 5.0.3 |March 21, 2000) at 10/18/2000 12:07:02 PM, Serialize by Router on Cirilium1/Cirilium(Release 5.0.3 |March 21, 2000) at 10/18/2000 12:07:33 PM, Serialize complete at 10/18/2000 12:07:33 PM Content-Type: multipart/alternative; boundary="----=_NextPart_000_036B_01C038FB.9FD1D6D0" Message-ID: <036e01c03936$4c3ff110$9a03280a@MRAO> Date: Wed, 18 Oct 2000 12:04:53 -0700 Reply-To: Manish Rao Sender: "Media Gateway Control (megaco)" From: Manish Rao Subject: call agent architecture To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. ------=_NextPart_000_036B_01C038FB.9FD1D6D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi! I was wondering if anybody could provide me with a reference to an = article/book detailing an implementation architecture for a call agent. ------=_NextPart_000_036B_01C038FB.9FD1D6D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi!
    I was wondering if = anybody could=20 provide me with a reference to an article/book detailing an = implementation=20 architecture for a call agent.
------=_NextPart_000_036B_01C038FB.9FD1D6D0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 15:17:17 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA19183 for ; Wed, 18 Oct 2000 15:17:17 -0400 (EDT) Received: from standards (47.234.32.16:3701) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6992@standards.nortelnetworks.com>; Wed, 18 Oct 2000 15:00:31 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26651 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 15:00:31 -0400 Received: from qhars002.nortel.com (47.101.112.102:56823) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6991@standards.nortelnetworks.com>; Wed, 18 Oct 2000 15:00:30 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Wed, 18 Oct 2000 20:14:24 +0100 Received: from zrtpd00y.us.nortel.com by zrtps06s.us.nortel.com; Wed, 18 Oct 2000 15:14:06 -0400 Received: by zrtpd00y.us.nortel.com with Internet Mail Service (5.5.2652.35) id <4V3LTVSF>; Wed, 18 Oct 2000 15:14:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03937.915316A0" X-Orig: Message-ID: <5F68FAE98163D21193750000F81AC9BE031AAC3A@zrtpd00x.us.nortel.com> Date: Wed, 18 Oct 2000 15:13:59 -0400 Reply-To: Chris Rigano Sender: "Media Gateway Control (megaco)" From: Chris Rigano Subject: H.248 To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03937.915316A0 Content-Type: text/plain; charset="iso-8859-1" What is the URL to get the most recient version of H.248? Best regards, Chris ------_=_NextPart_001_01C03937.915316A0 Content-Type: text/html; charset="iso-8859-1" H.248

What is the URL to get the most recient version of H.248?

Best regards,

Chris

------_=_NextPart_001_01C03937.915316A0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 18:31:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA11964 for ; Wed, 18 Oct 2000 18:31:00 -0400 (EDT) Received: from standards (47.234.32.16:3078) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6A88@standards.nortelnetworks.com>; Wed, 18 Oct 2000 18:14:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 26956 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 18:14:23 -0400 Received: from ind.alcatel.com (postal.xylan.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6A82@standards.nortelnetworks.com>; Wed, 18 Oct 2000 18:04:23 -0400 Received: from mailhub.ind.alcatel.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with ESMTP id PAA23952 for ; Wed, 18 Oct 2000 15:19:35 -0700 (PDT) X-Origination-Site: Received: from newman.xylan.com (localhost [127.0.0.1]) by mailhub.ind.alcatel.com (8.9.3+Sun/8.9.3/(mailhub 3.2.1 [HUB])) with ESMTP id PAA13782 for ; Wed, 18 Oct 2000 15:19:18 -0700 (PDT) X-InterScan: Passed Received: from ind.alcatel.com ([127.0.0.1]) by newman.xylan.com (Netscape Messaging Server 3.6) with ESMTP id AAA969 for ; Wed, 18 Oct 2000 15:19:17 -0700 X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.2.14-5.0smp i686) X-Accept-Language: en MIME-Version: 1.0 References: <39E5DD22.4607D3F5@ind.alcatel.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EE2276.89368321@ind.alcatel.com> Date: Wed, 18 Oct 2000 15:21:42 -0700 Reply-To: Isabelle Cnudde Sender: "Media Gateway Control (megaco)" From: Isabelle Cnudde Organization: Alcatel Subject: Re: Audit & Events To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, I sent last week some questions about the meaning of the differents *event* descriptors, but I didn't receive any answers yet :( Does this mean that this is unclear for most of us?! :) I would really appreciate some clarification on the topic. Isabelle Isabelle Cnudde wrote: > > Hi, > > Could someone explain me what are the difference between all the > *event* descriptors? and what should be returned to the commands > AuditCapabilities and AuditValue? > Here is my understanding and open points: > > EventsDescriptor > ---------------- > . AuditCapabilities > Return the list of possible events on the Termination together with > the list of all possible values for the EventsDescriptor Parameters. > . AuditValue > What should be returned? > > ObservedEventsDescriptor > ------------------------ > . AuditCapabilities > Return the names of active events on the termination. > What is an "active event"? > Is that a list of events that has to be observed on a termination? > . AuditValue > Returns a list of events in the EventBuffer. > Is that a list of events that has been observed on a termination? > > EventBufferDescriptor > --------------------- > . AuditCapabilities > The appropriate descriptors, with the possible values for the > Termination are returned from AuditCapabilities. > What should be returned? > . AuditValue > Return content of the EventBufferDescriptor = all events that has been > observed? > Then, what's the difference with the ObservedEventsDescriptor? > > Thanks for any clarification on the topic! > Isabelle From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 20:48:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA27090 for ; Wed, 18 Oct 2000 20:48:40 -0400 (EDT) Received: from standards (47.234.32.16:2317) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6C54@standards.nortelnetworks.com>; Wed, 18 Oct 2000 20:32:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27558 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 20:32:03 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:58031) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6C50@standards.nortelnetworks.com>; Wed, 18 Oct 2000 20:22:02 -0400 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id KAA01213 for ; Thu, 19 Oct 2000 10:34:17 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id LAA07012 for ; Thu, 19 Oct 2000 11:36:42 +1100 (EST) Received: from ericsson.com.au (mc2dh133.epa.ericsson.se [146.11.87.133]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4XFQTTAA; Thu, 19 Oct 2000 11:36:53 +1100 X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------4E874C2525BF5E45DD93610B" Message-ID: <39EE4223.D7778700@ericsson.com.au> Date: Thu, 19 Oct 2000 11:36:52 +1100 Reply-To: Paul Hollis Sender: "Media Gateway Control (megaco)" From: Paul Hollis Organization: Ericsson Australia Subject: Topology To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------4E874C2525BF5E45DD93610B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, I have a quick question about the topology description in H.248. The wording in the Topology Descriptor chapter says: "The default association when a termination is not mentioned in the Topology descriptor is bothway (if T3 is added to a context with T1 and T2 with topology (T3,T1,oneway) it will be connected bothway to T2)." but in the example in the diagrams, at step 3 we apply the topology "T3, T2, oneway". I would assume that if we apply the above rule, then there should be a bothway connection between T1 and T2. This would also alter the other examples. Regards Paul --------------4E874C2525BF5E45DD93610B Content-Type: text/x-vcard; charset=us-ascii; name="paul.hollis.vcf" Content-Description: Card for Paul Hollis Content-Disposition: attachment; filename="paul.hollis.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Hollis;Paul tel;fax:9301 1139 tel;work:9301 2326 x-mozilla-html:FALSE org:Ericsson Australia. adr:;;;Melbourne;Victoria;;Australia version:2.1 email;internet:Paul.Hollis@ericsson.com.au title:Software Designer (Signalling) x-mozilla-cpt:;17264 fn:Paul Hollis end:vcard --------------4E874C2525BF5E45DD93610B-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 18 23:03:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA13843 for ; Wed, 18 Oct 2000 23:03:31 -0400 (EDT) Received: from standards (47.234.32.16:3825) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6D2D@standards.nortelnetworks.com>; Wed, 18 Oct 2000 22:46:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27814 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 18 Oct 2000 22:46:48 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6D20@standards.nortelnetworks.com>; Wed, 18 Oct 2000 22:36:48 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9J2ptZ21070; Thu, 19 Oct 2000 04:51:55 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA26624; Thu, 19 Oct 2000 04:51:54 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA27855; Thu, 19 Oct 2000 04:51:50 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <20001017.194328.46115365.sunaga.satoshi@fermat.nslab.ecl.ntt.co.jp> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EE5CA2.C1029624@ericsson.com> Date: Thu, 19 Oct 2000 13:29:54 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: "Local" part of SDP to the binary data X-To: Satoshi SUNAGA To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hello Satoshi, There's a couple of ways to have a binary encoded version of the example. One is to find the equivalent Native Tag to the SDP information in the example flows. ie. > (?)c=IN IP4 $ could be represented by doing a choose on property Tag 6001. How to do a choose in the binary version is described in Annex A. The other is to use the tags in Annex C.11 to represent the appropriate SDP lines. Whilst not explicitely stated, nor prohibited I guess you could use the same (?) construct for choose. I think the first option is the favoured one. Cheers, Christian Satoshi SUNAGA wrote: > > Dear Sir, > > We have a question about H.248(06/00) APPENDIX A > EXAMPLE CALL FLOWS(INFORMATIVE) Clause 3 of ITU-T > recommendation. > Please let me know how we convert the text sample data > of "Local" part of SDP(Session Description Protocol) to > the binary data. > > Please advise; > (1)How do we convert the "(?)" part of sample data to > binary data? > For example,we have converted the "V=0" of sample data > of SDP to "(2)" part as following. > > ////ITU-T H.248(06/00) APPENDIX A EXAMPLE CALL FLOWS > (INFORMATIVE) Clause 3. sample data > > 3. The MGC programs a Termination in the NULL context. > The terminationId is A4444, the streamId is 1, > the requestId in the Events descriptor is 2222. > The mId is the identifier of the sender of this message, > in this case, > it is the IP address and port [123.123.123.4]:55555. > Mode for this stream is set to SendReceive. > "al" is the analog line supervision package. > MGC to MG1: > MEGACO/1 [123.123.123.4]:55555 > Transaction = 9999 { > Context = - { > Modify = A4444 { > Media { Stream = 1 { > LocalControl { > Mode = SendReceive, > tdmc/gain=2, ; in dB, > tdmc/ec=on > }, > --------------------------------------------- > Local { > > (?)v=0 > (?)c=IN IP4 $ > (?)m=audio $ RTP/AVP 0 > (?)a=fmtp:PCMU VAD=X-NNVAD ; special voice activity > ; detection algorithm > } > --------------------------------------------- > (1)How do we convert the "(?)" part of sample data to > binary data? > > } > }, > Events = 2222 {al/of} > } > } > } > ///////////////////// > > /////////// This is the result that we have edited of > the sample data to the binary data. > H248_APPENDIX_A.1.1_3.vmd > > ASN.1(BER): > > + ASN.1(BER): 250 Bytes : > + MegacoMessage > + mess ::= Message > + version : 1 > + mId ::= MId : ip4Address > | + ip4Address ::= IP4Address > | + address : 123.123.123.4 > | + portNumber : 55555 > + messageBody : transactions : 1 components > + [0] Transaction : transactionRequest > + transactionRequest ::= TransactionRequest > + transactionId ::= TransactionId : 9999 > + actions : 1 components > + [0] ActionRequest > + contextId ::= ContextID : 0 > + commandRequests : 1 components > + [0] CommandRequest > + command ::= Command : modReq > + modReq ::= AmmRequest > + terminationID ::= TerminationIDList : 1 components > | + [0] TerminationID > | + wildcard : 0 components > | + id : 3 Bytes > | + 0A4444 > + descriptors : 2 components > + [0] AmmDescriptor : mediaDescriptor > | + mediaDescriptor ::= MediaDescriptor > | + streams : multiStream : 1 components > | + [0] StreamDescriptor > | + streamID ::= StreamID : 1 > | + streamParms ::= StreamParms > | + localControlDescriptor ::= LocalControlDescriptor > | | + streamMode ::= StreamMode : sendRecv (2) > | | + reserveValue : FALSE > | | + reserveGroup : FALSE > | | + propertyParms : 2 components > | | + [0] PropertyParm > | | | + name ::= PkgdName : 4 Bytes > | | | | + 000D000A > | | | + value : 1 components > | | | + [0] OCTET STRING : 2 Bytes > | | | + 0002 > | | + [1] PropertyParm > | | + name ::= PkgdName : 4 Bytes > | | | + 000D0008 > | | + value : 1 components > | | + [0] OCTET STRING : 1 Bytes > | | + 01 > | + localDescriptor ::= LocalRemoteDescriptor > | + propGrps : 1 components > | + [0] PropertyGroup : 5 components > | + [0] PropertyParm > | | + name ::= PkgdName : 4 Bytes > | | | + 0000B001 > | | + value : 1 components > | | + [0] OCTET STRING : 3 Bytes > | | + 763D30 > (?)We have converted the > "V=0" to "763D30",ASCII code. > Please advise what we input in this part. > | + [1] PropertyParm > | | + name ::= PkgdName : 4 Bytes > | | | + 0000B008 > | | + value : 1 components > | | + [0] OCTET STRING : 10 Bytes > | | + 633D494E 20495034 2024 > | + [2] PropertyParm > | | + name ::= PkgdName : 4 Bytes > | | | + 00001001 > | | + value : 1 components > | | + [0] OCTET STRING : 1 Bytes > | | + 00 > | + [3] PropertyParm > | | + name ::= PkgdName : 4 Bytes > | | | + 0000100F > | | + value : 1 components > | | + [0] OCTET STRING : 1 Bytes > | | + 00 > | + [4] PropertyParm > | + name ::= PkgdName : 4 Bytes > | | + 0000B00C > | + value : 1 components > | + [0] OCTET STRING : 21 Bytes > | + 666D7470 3A50434D 55205641 443D582D 4E4E5641 44 > + [1] AmmDescriptor : eventsDescriptor > + eventsDescriptor ::= EventsDescriptor > + requestID ::= RequestID : 2222 > + eventList : 1 components > + [0] RequestedEvent > + pkgdName ::= PkgdName : 4 Bytes > | + 00090005 > + evParList : 0 components > > Any help you can provide would be appreciated. > Thank you. > > Best regards, > Satoshi SUNAGA From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 00:58:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id AAA01862 for ; Thu, 19 Oct 2000 00:58:20 -0400 (EDT) Received: from standards (47.234.32.16:4679) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6E23@standards.nortelnetworks.com>; Thu, 19 Oct 2000 0:41:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 27981 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 00:41:40 -0400 Received: from web5102.mail.yahoo.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6D9C@standards.nortelnetworks.com>; Thu, 19 Oct 2000 0:31:39 -0400 Received: from [208.220.245.72] by web5102.mail.yahoo.com; Wed, 18 Oct 2000 21:46:51 PDT MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Message-ID: <20001019044651.3876.qmail@web5102.mail.yahoo.com> Date: Wed, 18 Oct 2000 21:46:51 -0700 Reply-To: Richie Wu Sender: "Media Gateway Control (megaco)" From: Richie Wu Subject: About H.248 version engotiation To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi all, I think there is redundant about the version negotiation of H.248 message. Since there is a H.248 version number in H.248 message header, why do we need a version in serviceChange command? Because ServiceChange command is included in message, so I think it is useless and make processing become complicate. Or there is different meaning between the two versions? Best regards, Richie Wu ===== Huawei Technologies India Private Limited Unit 10, 2nd Floor, Innovator Block International Tech Park, Whitefield Main Road Bangalore 560 066, India TEL: 0091-80-841 0061/0753/0755 FAX: 0091-80-841 0063 __________________________________________________ Do You Yahoo!? Yahoo! Messenger - Talk while you surf! It's FREE. http://im.yahoo.com/ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 02:20:48 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA26790 for ; Thu, 19 Oct 2000 02:20:44 -0400 (EDT) Received: from standards (47.234.32.16:2328) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6E52@standards.nortelnetworks.com>; Thu, 19 Oct 2000 2:03:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28242 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 02:03:00 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6E4F@standards.nortelnetworks.com>; Thu, 19 Oct 2000 1:52:57 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9J688Z22470; Thu, 19 Oct 2000 08:08:09 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id IAA29035; Thu, 19 Oct 2000 08:08:07 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id IAA28594; Thu, 19 Oct 2000 08:07:14 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------491973E0334ADFE3407FDAE6" Message-ID: <39EE8F82.D61A5713@ericsson.com> Date: Thu, 19 Oct 2000 17:06:58 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: H248 Implementors' Guide Draft v3 X-To: SG16 To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------491973E0334ADFE3407FDAE6 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit G'Day all, Attached is a copy of the H.248 Implementors' Guide v3. It "hopefully" contains the corrections and clarifications that have been discussed on the Megaco mailing list until the 19/10/2000. If anything is missed or erroneous please let me (and the list) know. The file will also be upload to the pictel server: ftp://standard.pictel.com/avc-site/incoming/H248_Implementors_Guide_v3.zip Both PDF and Word versions are available. My intention is to make one more update (v4) before sending to the Nov Sg16 meeting for approval. Cheers, Christian PS: Please forgive me sending a 98k file to the list but the Pictel server has been down. --------------491973E0334ADFE3407FDAE6 Content-Type: application/x-zip-compressed; name="H248_Implementors_Guide_v3.zip" Content-Disposition: inline; filename="H248_Implementors_Guide_v3.zip" Content-Transfer-Encoding: base64 UEsDBBQAAgAIAImGUynoEftvvIEAAAAuAgBCAAAAZXBhY2hnL0lUVS9JVFUtU0cxNi9JVFVf U0cxNl9FZGl0b3IvSDI0OF9JbXBsZW1lbnRvcnNfZ3VpZGVfdjMuZG9j7FvNjyPHdefahsaD qOOPSDoEAVKZGFiOxOklOV87NBSIw5mdZTxfS3IlBYJgFJtFsrXNbqo/ZpayBegin4PEyCUB kiBIDgkQK4CAAEYCO9dckr/AcO4+5hh483uvqj/4MdqVIyOJbQK7PV3d9ep913uvXv/7v33l x3/5D7/5H6WF3++VPl/66ZP10nOFsc/j31dvmZsvl0ov4G+6/emTJ09o6Eu4+TL+fQX/nvzq 9//i95O//pfSu6X1L5RKX/zqDzLJ4oeRNz4olX691H+n/078SvxKaem3/oWXSt+zb5Veaup/ f/+eHv/urfn3XjDXJ0++lI3d9Hf6e5v/b/x2KbsW/6bf34rl604Bwo/Ezdcxrvd+p1Q6xfWP cI1v5c//9B/BAqj6T363VPobev41/d6PvmbmL1w7t0slG9z6ABzaAZyPK6XSn2H8+qNS6XO4 zj7S7xWvD3D9V1xPsc5LH+trH+sSyL/7fqn0n4Dz5/9UKpVx/Q7GX1xmfkb35VZp5e/8NguR 8Su+l14JLv2+XS0t8bpIX8ZP3E9B0PfBl3ph3uKV4FdvaThfvJXDSfFN768/Wo33orwW8Vq8 pvSk8AiP7zyX4/O5fcgRCvb+XwH3XyuVDo38U3x+1t9bWO+3CvQ8B758TH/8uPHPf3jww1uL dHxgl0r/BX7sfw9yvlX6P/Jr9x6KnvKUE0wmie86MnYDX3Rj6Q9kOHDfM/fKiYNw/SiUw/ib V9tWN04GM3ESBslU1PasB3atvlXbuVPbEx05nQZhrJJQnCkVu/7IOlG+upIV8fix+BP67zy4 UpO+CkW9Wq1aVvfiYad1/HJj/XjgYhFRbo3dMIpd6dMCVyratHrt3ulxY329PZl6aqJ8vBbd FieJO1BiiCn37frOXevyYefyoov3jtzISaIIiFvfXP5ZVkddufQ0EpHrO0rEYyU8GcVimvQ9 NxqrgVixUsO6R3iJKxXSZFG+qm2KazceCzkKFeY4Y+mPVCSGYTARzWSU4GUisSIuwREPHBXd E7DI8EXPnZ902dqqHdQwo3e0hTdpih6rb9uW5s/tSMRqAh7LcJbiYr1ucNoGh1sGIiQ6dT3g xaCJxvZx7x5WH0knEGfS9QgJ0BuLxI9dj1+pHQCnYCguIO9URIxGtniUjACdtMIW98D7EaQb So+WI37ZFv+ebwV+LJ1YtH0IaMJaZFlQtq2emFcecUc8SDRAUdsp6M+adeIpX9wLVeIPPNcZ W80rOZOiVdTUyKptA8M3bFGrV4F680r5ibLeAMCJ60exCiuY4IFbg0Dcrda3d6yH3eaaBZVv rL9SE9vVbbG7fVfU7x4cWPfk47nB7YPqvnW8NQGrGuu/Ie7/weVx57R9/g1BI3HQGI2Gr0nC yQbx4tYLc/cvrq0ZejtK82agbYmV1fBzzfr9YEzmNYIArdPEAQdhjs7YB84jV0XWYRCDiCgO pYzFzq5Vq+/XxJunQtxP3PeUb/UgtHMF0YWkYFFK2XZNlLd3N8Xe3X2xs1/fMbQVh3cPdncy 6sQK8t6JGK3XTh+2js97duviDDQuD75ogdLnxfO19bYfh8EgcVjYvbEbiUHgJKQVAn9Lo5Ga C9CxULGkB2KghvAvkYCRQRGHLobYNkghWQEHysGzgVBgmpl8M2tt0Y7FhIyvr7CGHAjXx9L+ O4nPmOWwF2bHgYhUeKWEBLK+kAO9GnRbJvE4CN0Y7+FxFCQhvAaQcHPlZj/kFr2GLUg2xr4r wvFkCNqM2rJNOUEYKkffgweuDxIhSAV8ZaiEejzFU4wBMZACV+UlxAU8HiZxgjeM+UeEixwO 9dtav+Zpi2yrvt51gqnSchmx6wxVFHhwsLkAfObLMPC84Jq8A7BVI1CuooalWGNdsEOFIQi0 YtJTEJQOVOAbnDFxL5i4UZSRCcTxJ/yM8h1SaTnpu0Agpr/bOZ8r2ketcPETOUupJ6ZA0SUe z+AHH8dAFu5B+MpRUUQukYRHlCVerEUE85mGKtZSGrhDyADPsLiAqwGfoZ2Zh9SMMJoJpjGz NBLXrucJP4gJX4CPxDQMpkEEhqcEgAED7KTmT6jDJBgUJA4pLisdhscwbBI3wYadu07szYAB 7ESLPlOqFRQYgck+9smCsGwhLhk76UWsmL66FkMlSWngwcdB4g1IpSZyoDQMOOPRmKwECPST OYTZ0mxre/1IM6dDWsOv0CKOGgCo9XDKqEUOEAlJc3LlSJVLb5X+jN1A4IMg1ltaYpXKVgTI lpEiPl+RAKS4hglCiQAxckJ3athBJgSOGWy1lmaQM6tYZLvGBrhMs6kPFiMYsJFMmLZbkgZz Us7rCDk2L3BYVpAjYwB1NKuz5gBKuhku+gu8QwTKUAszym3cwIJi+nEKLXWmANhRECV7tSW4 RrqQPHuNKJlOPfKouAXuMN9glJCu+PQU26RMQx5wwTgEXg3gYDlswOQMp6TusP6Y3MY05/c8 NwxY4HWlZmrADHSj/KVMc6akORHTDKfEvheqAa3QBgu8tKNbpRmAeo/I9cSE48ho7E5TS6Bw FjDJlkL1bgLlYMKYxY47JfT5TTdKUbCtnfUO8IMjcMgh3bxll2kv2qwgggIbxQlgXcMxkWzD wCNbiAMn8Kzd9fMAU+HvydyKHo55hkgk3VZCE4eC1+GjqLLge3mQ+R/NJv0AlkxeIomMV/AH 5FlUKgfa6CCucXCdhZTmCXtJ2iAWqcr9gNQ60kAwzkutHeUWtrb21qEagWmtbLd6e62d7tQR LwEtCmO9pRcoIkRp7b4knDGIm1Ca/S5zuXnMvWiime32Z/xmvl0CZ+KQ9gN96BmQPAajPgFF Y5X/ewjatr3WNkIzXp+hw2xMSLMiJOmr+FopP5cjJKUkO9i+gs0rbZ9DslRWaq0qYoxdMFSI 4yikSPxnR5Th0ew+LYt9PKZp5Kv6xLp4Bkq2trZE9/K41W6eivZ5t9d52Oq1L867gh58i6Lu UMeA0fsFiiWCK9aRCFENRxFkB1i7OMGEOtoImG17671sJ8nzEJrfKkRPmPZUw7X27FphEvmB vgvRBqNQTseuA4YZL2BZBf1vrHXNhLpdu6MBst91SQNuAkEYPbD393bNHsJ/U3jpcmbG4ZAO 24SfcDLMyjkfs+mpRlgF2JCzhr1bEU0yXZO1Q3n9iP3wRJETcKMJ8sFDKAzgw2EoeFqyCrhp z9ObPXSlfNhuteDWOF2S2d5F1gP90ihDEMK4gaZxZm9b4Adyed53rlSOXmR9uNqLMs4V8cdd dwTvx9lnd4Y1J4Bi/8U+UH0KMd+1PwEwMWPjs+LGhg0i2KXk5PbGaoV8SY0ioyCtTEFy12qk x047aFjLvtRqtgLkN2u1anVvDWk3jKQbk4WvNZOBGwh+KnqzqWpY2T7VyNXdTsm3n85A6zzw t2iLdAio3lDSxCPLiopbfWTqQFDVcEQgNGhE3MqEQjz3gh/qWhEsM8vjwmW/DCusi9el5w5o U5YTRdktcROMxtZKEfOMDf2MQ1qImdLaBYskURwj048PE3i2MH0GL5XBFNeSwik5QDyKmJEi xNSbcYZwNY/CUzEoyDkS+zZ0v8KXur7saMGvtBN+m+5ZhXBNgVJgQLj0VDgBqmmIIDmmgLdH /pE/aR9Zb5nYI6f3bR6DMCeLY8njhRHmV7QwqE1xcfTIHbnxmZzmw+/T8EWf0+PBSkgrxaHX oMQlQvi1OOVSOo8kApXiMLhTXv95U/0JuD4jP3iY7DMujm0uuowlVfjQylQ3Wqm1HA9rM4L7 bw8RpSJF8GO45zjNhHRAw4U7+GrFwHRAkbudAaCx1wl08FBgqW09i/n8zxCh8bMTAkJRuI7m odkaKzauPi8trscIMwq4pNE0ZlHueho4j7qxmpI7FgvMtVYaWt1YMBNpjDk1N52PG7TJySmd ePE2PM+hXza705z6RTY99tLs08kKf/nke6V+gaS7Z29TWX9ATAjjG+L1Ws2uLwfsnhrGVKTS CR7BiJkrVHCfNUSPoiadA4qm46hpXAyMi087VAYpbPjFIIeWLiLYNN4QTnSLnSfloDofk0hF fYiLy+R5pBokcURVL06vqXCr43Jdt+BCQ1rCugzdCRc+waFy6rO92SaVbYIQgRrWSX00WBNQ QDcDPi1KMLhuR2UwoJpl8dp7s6fnqqcbRQnV37pQU9dR+oAp86oGjY2OYgAbICIeBwilzNbT CYJ4McRxY6JD4w1M9A6jl20JyWyPltCIKIeXqyTEoqjkIewcomcjpz3g5FMvrLxhFt3PB6Y7 WiEhkCkSaWjM4wXNavq+eiya9rZRq2wfNIVEwzs9l+4GKTwqjpO9UmU03SA5etaFoREyKM5I 9QqHBn4sHylWGkcNdObnI1uJlAYNxNRUck0dDGwWRoCJ4yRhVh+eZscyIkw8Xchk1HSmcQrt qOhSfay11FS2wbA0+2TVK6zQYMDvJoGpD1wjSxCRJ6NxIQqhSqF0Uj03L1NAzul8X4Y3mA84 nItC18CmErL1EZxQermAu3i1SI14uXz6RvdSbNz59obgvwoPN1fJfVdcmAMLjvKpPpGW7Vmk VHgB+7FF+qMVmcjyhLRak06iQS3RCZ1S8OlsEoY6LZFU64jEhEr6UwiHRacz6UyhQDefTUGp dXUvj9Sg9mPX046Caqe+Lm6YQAxBGUyMz2Xy2M4IiBeClVJqhNVMuSETfqFa63KGhmxFH+Kx qzLVxebh+b20GKm1m4M+fZBBsdRqCa8fwkHy3DnuQbZfF0rOYSvjrUkQxVuEoxUVLftShhOB 36uiPDd+xg5I3BFzox0lI9ByZx7GkfLkbPHVpjniuSPEwophMCRm36FSofJZZe6InjtR8POT 6SJw7XoWgKdn9StUEbq4J5rmeGzG1vsU3ZtXM2S2hp26ej7vTfJNEC4/W6SvHJlEWn/i4BHc 0Mbx4caK9FlXnq9BR+UGv6LPmo4nfTXoMSQu2OUxAQ+Sr1/2MlqpWdfHVLJgTKJPtc5EhSNw YsZD2p15SprTjFUecBEzkfgaj8GnVtocl/V1aOMG32+sr98BM8/Azk1rHr30LTNm3jw5PtvY hMqtcFH74qF2+/N7MJGByCIEqtQioLssFpUk5Iqh9OcOYmdZbTmtXlGAfFefNxQCKNrFOUlb ua8eEWRSjGeMgz78VST0s0dCt6M5QT9DYPRpQqJ8XapDK5f6AqS/ah4drnF+nu4BhCpwMaeR asCYEVLREqsKM+Y81WoU7SKgpdibEdEnpuz8VuGabSPzjB0ESh8Sag5/AoNvXL1ioj+96ams LYCKCVAkD2v6VEKl5fSpRsYfUvZnxttaJZcVzODt3pwfR08B+hkKqK3l7voJ11Xyc1XTVIaF RirWETKXdrjub5hiuE82MM946qWJxVC6HkcegMBNHZRwGUulZ9QCg6dBn7a19IWKUC61Q+UH eJe5eTFkqltHlI+SKBAaEbZBWEm5HPMZjbbLeR817zN4F2S3UtQtdoi+7HuMWna+ntOvWzuo jEzH1llTBCNHUhnTacS1dJlieBUQISdBYtoAEGnQLp+f1xWOHw7ga8kNxeSutQszKsfHbLmj MbH+MO+aqfDjaI4+IUdgK/RP79YBAmSmKk1fsjaARRVimowP1A4Kyu8FaY4hC/5SPzN6nR1P govANAjzs208n2YOeX41GB30IUrDV8zVLNSumjuTxG51lxojzbKdbDl9hJqi2kkhWat24Lvi 2BkH1OHgKM80seUnGIuJ4pQOl9zH4tiuba86NjTVR91GQa0cagl4MByStnK/w1ybVMuuMSNb 9kEKkg90poFLBdiBkl7WXroENjtUzN6nQyCLaKPXRLlWrR5umo1D6mNYOiwh874YDivixK7t 7fL69Nfdr1vHrfsXrbYoH1TrtU+aSNHHhBAr4ETnnmTuSTwKVj9KG8h4Jt3c+K6uaxcIywLg luE/UUoRE4W7jGYfGzG0PU/TfC4jcD41NVU0c8hVrBfPwwhoh+WzeSprz0OM5mVn8uu8sY9s qXuCQEvbAnVGedAncR2Ej0zU4Iaie3l+nOJT0bzlBhE+/x9cEQsGmXuhSnxB6Hy6Bkthy+nL yHUKbw45JDJW1zs6E44bOgkV+PViBEyzUOuxVp5Qm81irSD1CwUJZNNbT9FKfWRBhQ7J8YN2 Y1lDlXHJpg+CnCvfFQ2hrw8i9PEeLJkrqvaq5hWLpp2YrmXdy9OMddsbFxdSU6AT2cO1Yz9B lM5IrrEDaKV8bZBal6khiE2iTMp/Aoso1zetc4QWDykshrNK29uIhbqFjBpN5IRz/WHuWDV0 I5tc2ziyXkoUxUq6DtLj7Zacyr7r6R7LD42JrpGFriDILFns1F6wLXgiJvRGExZM/Y2mKcCT yjOasShv//z5t2fXqqIHzaWiL4IpKrxoh4HszrK+lXW7I0ZUDd3ElnXFJNOBDh2yjwfm+/sn ur9f9/+CzmnCW1f20sAd+LdjbcdpGyD23qmRCm9zKWqxRs1+f2GDaft59aVs0vzNiqk8hZOM tsLZnqkzxasqVqYIpMx6ZpNods9hKlNKWGLdwPNuwmVI6uKhklKK3erkL8uWuwvZcryMHBVx Upx1Mn562PlGL2OEFpGwXi63Ls7Omgvjm6JDb1sLb79qSvu8blOYmfnQoZgHduSmvUEa3Cq1 qdGZJHcfaUUj+RkftyCiVlbhM6W5vARR8ItpkG3qdb5uponlSG/MUjd0mHBSL61jmAk0M+uE DcLI1lo6t06xFzSSs2dZgnCdp3BQUCGtPtCLWr5pTrhInejyRBG48dc3Qbup9nt+fvwmGNMj EMTdCbto5AZKToq7cNlPe482rcu8lYSm6CULzKkUeEZ/3oST5kie+BDBcrTFYQw2RZdK6sOl sMHUQDJbTusSafurZFln0V/h9HmmS9qifGnu20epFRP52TBxgx7M0upHAUKZeoM208g/DbnK r9N1035d35rT+zyX43EBIqEfWX1H32aI5i1dJqbmWH0kw4FmzUah73hDu7u8QWqO3ExUBj2d MUl9Z5bNcvI0ppXFdqsURUMeUwFlNhhnbcdUKQoNdtmiG6sj+lpdzO/o4kgNZeItnic2NQ3F d2XaxJwqYx5rYp8AmbxR5BENPacUIq1czX0oYr7GMEdC0ny4sLgk0MtEnp+wFNNTSsWyPUUi 0qImLVNZpapE3ht2k8fWUZ64zOiyloi2ck1tYO9GXPC4Wq3e3bQOZyn26Tbkqek4QGo70p3S sAOPL5hOarMyN7mPtOHKFCiojztPUImoKJgobtejZmmTOFFwovvog3QHpQ83qF8OsXngKQmc 0xhBW0PD2oDCinKm98vxaLFzhW0LU4bDdI5GjpanDpvh0N7k3COVHp5hgYJooID09QT3yrX9 hnY/xvvkm6C1jpSW+o9VqM/1G9zVfYc+e1DLCryffw6pcW7NfWFk7du19S4x7D6AkJvqIUmx 3qQf9QGKpv5q8TNrrz3PQ6W0IpH5AD/wt8xXkgtw888/cq/Zm2tRpqiLtDrN3gbZ150mOaT4 SpchKPp6YNd20hBMWwL1M8Jt2NYxFwPSUxU+7SNeT0Tzvhhz//yKE5aHR5e0QcRpzZY7KnMD 5E1AO5x6FVAe69NGKGiojNMlRBBu9mfUBl3eMd+PVcQOw62IOsPchE3m/Z1r3aT/DuhviGdA +kgy5xPArB/Ql6f6q7naXqNeb2xXxVZ1p1q17oXBpCE2OsjWkFcfQsiwgeJnfxvmuz9+ZPN7 r501O62L8zZ957chbr1ww6MXrV7QEGfHJ83WxWvdXvP8qNk56trnF53e8en5ce+Ni85/s/f8 sW1c5x0lSxSdXGLHdoMtQ3dlssRSaIpHSrLE2EYoibLl6AcrynEyx0soibJoU6RKSpY4R+hc eBu2FS0QpO2ADFgwZMuwJmu6rl2BJmizLlnQrmvXYUEDGAi2rkvbbFnTZJkRJ9a+H++9e3c8 yko8Z/tDZ3/U3b2f9+6979f7vu/uymLGBrsEMeAUh53Hyk7PwbTGzQKxbcEpcjsyQvp8od53 hsEqVF3GrILQuSeXyMtzTJQjGlIVLnc5diaaK1cVpc1mhiNWNv3RI+mxgbQ1dmS0Pz1BU28w NZlSpZ3GoeFjE0MD8a5Y/Dg3VM3P50q4omWV9S2rbV7BY4U1812YYGEsqWqNQEdJcyo5Dli+ 00tF1wY0jueJCu7wDczlp08JUrt7eODu9ijqJIYzsEqFz93A3Th4shLEaafzFd0KfDhDKoG8 rm+nkhltQHlXh60AoeflWbHzLTIKBTkR/0n0NSIir557Vrhn5kBqrTn90p9MI3tMQnDdTVcA uet9XdRU49AfsvIW+0tomAGkovDriIdl16U5vuhtzkrEgcNblG6eTs8jTpqOEKTin3WbgIEw gy/W0HCFHXNhi6h1VNIibXk7e2CoNAJkX67lBbc2OZDhPf68Zuc9kqvlhR4b20eBU7gGTiHe FoaPWBSzC20ssHVl0pc75NM1IaM++5G9sF71fSxAVuQ4wzr3sSMjI4T6kd54WCmQG6ekjw2P tiaPcfGcqwLpzSU1inPMIAg2SjCMQOQrkrGteHzFmCCpmYNWOKQY8sO1E4BGeecMJ8PYErK8 wOIDH8QoFipbilgJW8OxdhLQbKzPut22FY4dmCMCrgIY+GJZlSnKme5MTwwPZLPjYxLXrpvh CjEu7vUmnNeGqBaGHP1sp4SLmUBDwhJ9eBBvLAN7JBN0U0JCeTlVHWlQp+esZRrzObkFnycn JDJdIi9ZVAQJxwtoQTnPitvAO+bnSUWnTZAqz9kKeT/KnAtztSrxL3pGZAjo/Ynqo87DkkWP Z85h/9aZdVG/JZCwRtFoCHez9lsjBXJdFEJAdjDTwCZxADUIkGylP7ZUAJRMyLJIzkCngXsr L1UpVYmWRagXsMMhNevzQmVJDe6e39+OXZ0XHRHPgogB5XkmPpwfK3Ib/kg/SM7qvyDkE2Kf VIfFYjiKitp4QlsL3clEV7Krz8Nv5E7CmhnNnQLW9uRS2No3P48nWgCBA+99LjuWoH4DCtMZ 7tw/GuyPxYaC2cmJ4bGDQR6GEpFYFJUV1hT42+Vcg4EykNgm4nv91Ie9aEkshmZcMiLwdu/K 5xcQt8GMHyrmTtTr7BxbCzvaV+8HgJhqkbzlwlYaraCImkrMpiliXMI1VUNP5uaMWGUyPOi+ i31McR9noY+8olSqs6MVDYNAAXhV6K88xWjWgWi1KPa2VQUSP4s+swqR5pkqhi5F6L8f1ZSM DoKW2lXNpmw8g/6FqZGo5Zqlk8rdu5EVYVzWzgaZXqudCSnhpYSgkUzuV4yeecYMnVIPHQqF +sfHR9KpMdWbiBmi1zM4ColpPtMTeTeVX448Qlnnpv7i9WJeS2kqVndTKxGNRs1VeByTK7/K T1XXk410zm8JdVtZfi2ZShkw0DyhT7lvmvIyDtMgEDLbWfYaz0o729HcwkQKlR1JU12T8gNt rVbCVidbg4aP6WahI3lyc+eU45zSblqYX8YQkd6oyENi4XWYB/FEC/xEbrYBxNJsfoFRZawr aXcl413W7cAHSlSphYKx9tXHWTlg6m52ScsvWswVMQXO4EeF2VYxz7YD4xUYKgq6wWa5zOwO 4/jzCtW4AXa8OTjAzjfS22bRbfW0gEaXGIwALkp5UuYUy+VTjmFyFW1DnDc+CFkx7gfHItJz Y+Xl0p45vGZsWSovA88qLExGD9pJk0ek07aO2fFEVELX8WQ3HqZuS7MfOPNYzLbOmLhcBfcD d/eIO3gIr6L9VqoLDi0BD17akBiPA210p+GRK3aiBDsz0wmyxRnpALFfPeCqltdVeDXiuhSL zjozfaJzZnE14s6s6nVG7oy5O/agFYs9eMzes/f4sZWVleMP9uKfFTodck7Tx/C3z5Z36GZf zIYbx6Ptq3rHVk3+XbVMPxapBwNVAJ3CtzioKdlhoEfH70571jiJQDlKUSYixORXl9iRzS0s uEmiblEN5Lwg9vPFLrJWDGUblj1xe3FSiBGisLCLRTbMV5wgJcw661+n5aVF0gAJ5RxUhz44 UYEShioFwAjdDkYAKSLRl4SZpzNPo8BG5/JFq79SXi5Z+wai4kaUbtxZv7C9OGIMA5kUMUAU WhRcIX7IaoaiwpMqvSIE5xn32/UueX3QHZtE3cFWbh/Mi+miV6ifi9eiF6XahdUZSy4qEy3U AdkC8xtu5yLNQlL5UwluhnXOYqs5IsQZlj3YmUNkrvOwtE4i5XCZMNG7tyyliNYfiauUgdro ybwaIdplnAE5xI+Q7nVrfkUgC0TlMI7SjKXOk0Xkyc8oYw/e4+HQKcLoBe2PgJsrlnMUBcZx 7NaVXYSCmUIUZWUcG06MXRI3zWQr4VwuTHvpOYt5CbgzFY7wDo+eb2oqLPoIeXNkYJorYe9E 37TScqMN99pwr5OduynwkfM0bHkAz4B9DiNnC88RVgMUYcWKcsMoAjUpksLOMfUnwSkKC+E0 SabKREgFqhHGMiz0UnQlYn3JCi3qUn3jGya99jrYhGgJiN6zku4CRsfZvMBBpjhdIJRRnK92 r4ZQEsl4T7K71/rsB6P99QkgtwFMA7VuINeu9RGSHQeGxZZ+j2ZKzSFUaPAUYqMRgazUHEV8 IMM5CkWldyIrLlBtCgtdXU7lUJO0xIo0eV9Zc5J1BXnPOCHlnD026UupnCR1107idzB6lzJz ERugyhBGPZP0l3HZhvqvzStd/SRFXxYDCM2brJa1DpddZFWxyqxDuCIiOkroVy/LVoMu01JO WkSdxrHmfid0G4Y6kpa5PC1IRtXyQ2v6JT8j4ipWHBRxQ44cc7S++GiH1pms6Sg6GvIrNxuv arH2kxaOAe2xdtkmW60tSiVwzvEvVKaD1YbmwTusifSQdT8gm669XXu7E92JhHVfxbpvztpJ e0wfsRQekrpvHDOKrxfd9V4fcm80AQIpo+gxGLugOB8e7FykMF8zwSDyptYkXAVnFnkjORFr B3QI85mECkypyBQbUvqXqjW+PSVvx+E2sOkiJCknTsvEBCRmRbghzbyNc1ULi5yrC3IdzbFC kVKWZfluSMnkariNzaGZTgiRk7ItqL71YCdwnh/NcUwj7saySN4rkmFxujNURIZeyODjDdYb 7dVEENTQwnDXWf777FmSgQ4Fj0XzK2H4JaUlwcHAypB1A4mh6h12mFTAYmEfLRRnptG7U1pa kwuqWyfJOtOS1UsRGOqdE4RWi5hxxobKKAyxDKleC1WNbmu6Z+henRZfKomUyQP23kVI0+so hup6yePIwTkcjbeDUokGMAGoKasVFGMBg9MmFnVDGZA7Y83VC87TqVko2qU+KsK7MMCtLBWL UcvPObk32meNqUBRQsgkkUgXvRv4Byr2BJen1YcKMbTDoLcRHsdK2P9Yq4r4sYrSGJMpTbFI vc7hjiQ6UZXIupFCBNF2SXlRD7aBUS1LNfJYiIbVxBIvX1rq8HIkZLZE2tQjgxkgT245r7aA 6n0oh2Y+FbQjruYdEpLXxkLfAViHr/L0lCMYc+APbSvd3otRkIW+pjcJ/FRXbD1mal8D9ujA /xV7hC96HP1TxM7mgAym9JtmImp9EO/dfybbMcZLbOeJS0UqM5S/aJUZj5xwkGkgxOhGsAWP l0pZignIPAlvUqcppyVX7Mw8m9NUo9Yw7nuChKEMCwFDwmWWrRA76ZxqQkMjvh5cEg6YboUP pY0TY9iJBBXGSiP2nZpincaDcJDiIInjWqxpBm5Chka6LqqNSrdtUqIWNUv52Rw57ufUDoII G6ws671GqTkaLee9KBHNGQZEXeww7HpDPuy16r3A3iw/FzGSBkX7dOla9CC9ypaAn4hD4XJo QPS1qGqThRc/e34ob3U2FyoWyGqZsDDMR3ww1/tE8RRLO3cmeZZgGGjhusQhYgWSh/7NFlaI eWbyo8RNFvRY0JcPr+mn2WUZUK6K/uAIjjREZKYvpVutbeFOR81umLg19FFGNyc0MHPNzv1W +A7UjKNeu5MU4PB7hn5X6TdJvxH6vRl/6zSa4gjvozwH6Hd/2DLNO6wxOZuqKPowvXa9BCKs GOVCxD7FhUjeuZlUB5TvkJSSnCprlMEqwNKE9NEG9Xtean0LREAvUz+kD5omRiPjxVB/4J4C JId9kuD5U+H2DfHLZG45nBpLIXPgUMQqTWgtDLcr0coeQl4Q4zezBy/7TlJEPjn9aP5gxUkQ h5dKhY8t5Sm4NFTGG4XyXp6M/UQMSlxSUqwRtwpVVb2wcBbhGYSQx/ZNTs2Ke+QZrIcnkJld TSrDYqeQx7waimW5CDNAVasHSHJsT09XNzqikWaR3X2oewuVwmlcnEvIo2ZdbcX4aYRvkAiz KCywadkpByU2sMaFB0kwGWhksvhXay7qy7KvWLWalyff41q9e/wX7srKik+FmqXm+uaeGzS/ 9ISh/4AtMIElCU041hu6BIKBXNbbMI9Hu1l3y5brQO/nhCmKs07IlCFpuRcPCP9L5FmM8VSI Duskn/CxIK/sSKxrqKlByTglLdNh4flwBdSyLJeQOS5rM2ENwhz3OZalaOU5uFlESlAOqpue 82yyMfVrhIovd+jCFbw2ttaBmzX2B6lWy9MFspKysOMhvSiFMPA9RkRgBeyyHKaZagMmPJ1U HaByUkLRTUvshLZf2pPs3pu0PaYlk+X5PZlJazJXK5YrwIAv0smdJdr0KIk9D/wWxwFzYCAJ UxK/fHKnimkarc/o+Avqy4Rjv8rIEWrOzlRdoY6EEn+qJkQZJaGkNEm4GmH8KZYmrwJpdKRM kbApiV3cHYEVFA8JB2jxpRcrpRkgos1ftVEIEDafL5dml6pin0C4fpTJfUf4zbvdq2XlZW/C 6EGWy4WMyRiCXEpFQ7kZ6iS2ss6GOYanr0nfWyRgaJJDwlzWJyJPo/lh9ya74l5lt2t6qNnh t2m24W0x/9lht9M4LPlEaJHDJ+zJkKaBmHAiP2PG29nLXuqXpWKSIpwQAvKtiP1n+U3lgKFH izznFdHGkxhEScBLwkKYe4fWn8r2yX+O9UUTIcZAUqEheXzGjCD8OZhLKYV2L+9p3/jEW3aH K61qZk6qRpYSuCfaU1Rx0kK9tfIS77NAX6bZJ4ndj3kxoQZG34EsCVNEx7lLPkPeeYpoY3yl cLIMr9gQV/XhXEzYG9YVzOcq0OkCIyqciuHbvBakt0GROntQ4G2mAVeXHAx3lZUMpv/0T1Wr S/PMXwtXHyLNXW6DzKS1aHfaEfyNw2+8kzWUcBJXNbgMOO3ODqpH+Uo5mxW4IZhjf/upKa7G VTS+XtHp6WkqMoP7qaJlOWlsZipsp3M2Tr2CMJaW2eIyW1w9A2eTMQiYX5Dswn77DM2e/Vgx n56Rs2h11WSGqOqwF+78MucZeOYIPO8qHK5mnHIdshwMQF07lmqovp243g4MUAQGB5qJqJxx J2fcL6f/c3ecObpHPcmGeuQp4X32iGrRNOv10ijMye+eKIdMZvlUGG/5iSJpDtwIBXaFJJ3P 4D4+e9J72NNFDvayjvm5QnWa66Ly35TVOp5CHgNHKeY3WHeyg070AvZKcUwLhEpbNFVzOao6 bIcMY0MabfGxHRGGhfC+zi7nphD7u5QiMjYlkKmZomL5HcNraQ82TWGRqsxrLOrdIqrHrri5 pcVyqTxfXqoKu1N4Sfi9I08QTBlrB/mE6nwZ1ULL9JEo1bFqYXFJoIPd+SgIkRWO8tIekXtn xTKhc2l/rggxPQe59yMHlyvlqTNROQ9qLEYSm1ZezktDD0xgDxB1CZXb3TLvXOHEnJ5ZuaTW 8XfdITHrrbQyPGD3ZZ4Y/oEApQFTvcJf7pCTukqp3PhFLhLbIiJ9SN0BC8Q0ShWnTc3bNSL0 bhGXLk4ziaH3MkUfbxJ15uQWvHvXOboOa6gI7oKb4LLpVEJTzu8Fzi9px9fzc1tfOb8B8mea /tzA5Tpndyfxfxd0rtvpXIZ0U/3FHCKn5cL0KejhFF/5ii9XxBVsQO6JQO36gN22zog1xEf6 ZDPJRsIh15W8evcRT/j1y84mj6GBa14JyZ3mqfjWE0tf5HHitXEokT+TbppE9gUZZUMg9/vZ kjRvM9nPKPsDaXWgSgi7pf7OvC2CLHJRxoE6A6p4EeydqlGiRyt7aPzIyCAjyLDKG3aeOKM0 bsOzqP1Ad3nRekro1jniLn9TUVilyYZchom6HkVz6+mPODp1K4VPpKrNnQZukiQU7z6bK/aZ cuFXD6BGiMS7fv9KxTM5zFqEm8feUBGXORz1D1UTJW3cxEeaSPsgmQb69hmPBgbcAxQ/6XIl clwZ9QEWX35ipYiaQRl9JuOWGmkQ2ZCG/MXE173ENqeI0yxFFe9LlAsCyT4SOo5Hp770qFqF bhP7Ap0lwzf5rTsZSk+GSkLGBzOQgEOKbPmtSxVDCg1I8StOaNQBvFKJXab05KiKPFpHknpC A9h7cmY+LUgbmxaUZtw63tC6PBKMBrsaVpyNOw47XfVEsiV3VG6SfDNP56PvhTXyBvDJqChV /MlI4T+4rH0ArZJnpddqo0FY8fGmdz+sq4cN++Zfv9+H7kh9DZNFfXiR5Hr89h00nJpMYyOA lidTA5PW8NjQ+MRoCv0uzLHUaBpY6vHRTGrs3qSZGhycSGezSdMEmpY0h1L3JM30aGp4BMun hobSA5PpQaBqGAwnDQSQPuaFaYPp7MDEMPlyWONDVmZivH8kPZoMmqYZDGaPHDyYzvKHv6Bp KJ8dHzmC15QBcoyNT6atPcieosZLs31b4L2vWY5gVgXsnJcBF/iDfRivjHcAT9N3X8mJFb8s fL/v95zNHZnUwbRl7SwUdplKS46KKM8noj3ja5ohs0N8mzEZ9FJXc2TUSgtiGuSv6vbYVsLq S8Rsq8e2e8Q3dZ2bid5e53vB6xLmYDAU0rsN/da+bu3XczEVPJ+gM8Uha4rH3uMAOCXty3ah Qdu+h7F5bB6bx+axeWwem8fmsXlsHpvH5rF5bB6bx+axeWwem8f/g2OLYTwJ8C2AlwF+DvAG wPZWw9gBcA/AKYAiwBMAzwL8HcDfA/wXwDsA1wQN4wYAC6AdoAPgMMBdACMA9wL8KsAxgPsA /gHgxwBtbYYRAogCdALEAPoBBgDSAAcBDgEkrjeMjwJcv80wPgQQBrgZoAfgBYCXAArboY8A iRsM49cA7gd4FOBDOyAvwG07oW8AdwDcDfAFgIsXLl5488LPLvz0wkXjlR++chH/nX/l++e/ cx5Snr/4zMUvPvOdZzDLkwBvGhcMPH3zAp4Yn/8jZwi3G21npw8FjJm5k7cf/q0Thwyjubvt bLCn7ez8odCWG5vazjaf/Brka20LDBzeaRxpC+D97c0nsbB259rxw/CgAHhhtMUO30+pxg6q wXDVYLpKB/HvoY7AFsq/FVo/0EFVGsFDfBLs5t5s4boxH54dwPffA5AGmAY4C/AJgD8G+LaY Ezgf3gSItBjG5wGeB5iA954FmAQ4AnA3wFGAn+tz69/ex8VL+sULDVOe0y++qV98Rb/44sYu ntzYxWMNL4yQYZjPX9vU1fpssGmy9WmY3UYzzNhzcwEYrK23GtcM3WyYeOPp4PZzgxe8eQOU vfmWgLEN/zRff+6hLdvPlS6az28LPL5lyy82P7QFs1NT11IOv5RrRMp1Btx/XN03xe3tRou8 feFXMKHJ2PG//f7vEbhiHuARgD/Q8MaLOD8A3gL4b4BroXcf0fDCcYCPA/wGwCcBHgV4CuAb AN/T8MYawKDAEUMCTxwGuBfgJ/AiXgfo2AprHaAK8HGAD8PYtMPIHcTRA1yyDWACIAdw3TbG Ldrxzls/o7+vGa/C8cqrfPzoVXn8M14ZL59/6fyL333ua1/98vm/OP+F8y894VTQ0jq4trbW 0voG/f4L/X77Ev6ehPMbmm41Wk/DSduNRiiwtQlL0L0/V/cC9Obw3tflvZbWC1TP6/jbFDBa jKZQkxFsmjWaAy1bm5oDcJ6m8y34A6nNxta2m1UL4pxqbqFzo/9qvbO39NF8Xb/49/dx8cqV VrDBi6f/tPlqVe05bgfSdEvgxlsCTZ8tGm0vDhnND6/9IPSpG5+AFz64tS5761fqt9RaP3y9 91ZL2tjxGNUMS9Q5A7yy87EVPxy162qsr7f1LjW+eG1j2d5uiOmfbXjx9feRskFSscFGneO6 Wxn/30jUYPu5379kPh8M3NQcmAu0GoEA4f6rMxuMa2axWhc9+AYcztwwdq6HD7281t9q/Nbc dua55gHiNzDfhTzXHwK8q/fhon7xZsOUdxte/Id+8a/6xd883ORcPKOnfNWV7VxTg3fpzrZb W/tPNM72l4GNZEO6CssOxjiYM5ia/8maa10GH9DvW+4ZEDOaHl4zdhTh/Rd31L9rn3tt24yW W6juneLdtlIPZGvIe9wETMAW4BoMOe+MnVfynpG/fhVg1w6Hz96t8dmTGq/9C7sM4yaADoAy wCcAfgfgUwCPADwJ8BrA22/8549/+PIP/vG733ru2af/6ktP/dnjjz7yuYc+/cnfPnf2wdpi +WT+gWPIbSF9az3w7toan2XU2XF1NqXOCnDW1vSA0fognABlfpaup4zW7/H1999FqrrvEt61 jdbPXKK7nyNq/dQlUfav8W6wOdD6zUuy3heADl/b1EMUt/Wf1qjUi/Bna1OT0RJo/TLdITqN 5b70jiz3hjr7ZWgZ0yzV1x+ps5+ItJ+qO7VL2F6O2/td2Z/fU/35JerPA5zeuSbSY3T3f5g7 E4Cqiu+PD9sTt9zJrVLBNHP5WWKWlpaiwk+zX6blvoaYueC+YWrEXyRDSxN31BAlFHcLl0xw QREhc8UF1Fwgd2JH/9+ZuTN33oObTxRR+gxz5s67d3hz55wzZ+beyvPSVrSU125Ls85Pox8v qvfheVVINPTfE1QhThWCVWG5KixWhQWqMM+6aoGGzVluYKZtBmIQNcXQSXHgdrScb7wt9+zx 26Y/IY3Ugetwsqo9hlVBsDHtZTOwRLu6xJTtkH9MX3rJssiOndqxOR3YJjq2J7JxTcetjS0b w0+sNcqLPj0EjoBYcBOsdSJkG+jyIqakYBAYDu5WhR9ZjZARYBS4D9ZWJyQMxIIz4MuahPiB GyAdeLxMyGBwABwHbV7BPB/sQfOjwWGQAbJArdr4SkEWcKwD3wLMAFvBNpAIzoHz4C54w5mQ 1s7U37wJ45CMn4vkJDh6EUk02MkKN69DNhlztmSy8KfZPvR3NRvHGfaYtTt4jXdxf7UEZu1d POww/bYj1TCfF3k+r6c16Lxe/8w4i884igypIOusaODentbR4wO0hJ5Hr5PZh59HL8nIVzL8 dQ8/85I0rQ6NM/AZvX6N0Vpb9dqjXSzP+IV2RtLUSA/3Q9/3B94g1Em/Hz6yuB+Wg3CQazZ7 elIhSRUuqMI5VTirCn8Yns1spr7KcNgvt0YhWA7QZ6EHjDUAtFMNq69bhtjvt80sebqsT+Vc F65bSIXC9PVe8Ce4CnJABeiE+sAN9AMTQSBYBbaDw+BcVa47SkNf1AYtQCfwIeij6JM0RZ9E gp2aXslOv5t6Pfnc6ePxRw8fjP59D+bcmyPC161ZHbxs8cL5877z950xbcrEMaOG8W+MWuzt Ocwi78jRrP1BLsfkULvuk0tTG2b57YR/UJn6A6yuM/cM6rLjb7P0I5Z6snQ6SxewNJSlO1l6 jKWXWJrF0orMi2jIUneW9mfpeJYGsHQZSzexdD9Lj7PUns32X3iota6WsOi1HwqLv0v1QGK4 B3JY90Ca5Iq/JyBX++y30vfIo0WvPcv+zFJv6mIR7htOLIpQMLtoqircMJzaJBkKVwrWQYp3 QrUR1QwO9MgoRzoB4PlgBz0fb8vy1S3HGbXfTtApLqAF6AT6gjHAHwSD3eAUuANKwL6/BJoC N/BpTd3+LwVbwEEQU9NiWmfWLxmF6Mu7xS6Y9eVfz0hINbRG1vQ3vTek1cI9Ur2o+/y05gem ab6gPaxbVdAQvAe6gqFgOlgGdoB4cA3kgHLwF52B68u6HzkZ5Gal379zM+XaleQLiadP/HEs NuZA1N7dkds2rg8L/Wnl8iVBCzBp9Pf7errP5AljWTy2bCbVpvVY2oqlH7J0IEvHs3Q2S1ey NJKlf7L0Lksds2j6MkvfZKkbS3uwdDhLp7DUh6WzsjTNvShL6OG1WUxHh7Hje1h6gqWpLHXI pml1ljZkaRuWfsLSL1g6g6WLWbqVpQksvc7SByytxGxcXZa+zdLOLO3F0iCWhlBz2Kgo+2ge CAGhYPvL/xYXMhv/9wyP/F3swlXrlPTTFa4axsasG/UGM1c2/gvqp/3KXO19ba7WHXi+os/T SmF+9kptfb42XZunLQBbtLkanZ/ZYm7W1Fmfpw10gT8JJoBAMA9EgPugdl34nHXZ2Nadvf2/ 7dq2MZyO6UU/zPX3nT5lvPeXQwb2oT6eJzElc48NuXIPRK6rzHnL3Bieq0mYy8X9wxUighIs IyhRqj8Vz/2pBN2fWn5bjONqPEbUjflpn7J0nIgU+YvzzpbnPa+eN4WfN1U/7493xXl3c7/z N+5xMv+vv/D/xgr/b5z0/y6r573Dz3tXP2/KfXHewxnsWGwGPWMSSzNokcvT6G/jcW3m+txR hX2qsNdsDcZQ2KEK2wwHxRO3oIj+Ybw9dzGk8taMV7PAtrcqDFeFYaowVBWGqEI/Vehd2C/z UbGxgbqf015+6W4HptOwN43dFNt+m/a8VW1dbJ6H1jjSPh6g6WSqize4cB08CUwFG8BO4FQP PgFwAwPAIPA5CABzQCCYD44Dj/qY/4GRYNdrhCxvQMjK1zF/BG0aEuLeBPoFXHgDhg7UepOQ 10FD0A10B2PAbLAKbAc7wF2QC/LeZEM+jdy8jl955HpiHP0PuVgSFbk9khWuJ+t/Wjh7IZlB Jqp/sB4n+798cTJ/LU5WVZZs0CJ4HzQo2dbDST0SoNUVRyrkO6JfabZ2JZOr44zmjjOUumvy RQhDtAghjezlj0NOzheHnGwYhyxD9/gUEJWcqH2CxQ0bWWOP6X0wB3wH1iv3xIvaPdEQtKtn EdM/pgpHDTf1RBsKewwFsx0+W1VhsypsNDyyVhVCDJcljhme4HE0ki1faaMaiS3CtSldQczG HDylTOw8+TzeU5/H1yRFbR1Ixcfp3/bASxvnIeAPbbwnAff6fNz31cb+qPp8vNdpTEgVjHUn UA90bKKP/xL/wfgBseCipgtyM9JupV65mHjyeNyRQ1G7I7dsCAtZtWLpoh9/+G7WN9MmeQ8Z 2Fc2nvpCHWU8qxe8rUp8DY16Yn5iq8sLrIwGz1iZtvqVoHpOF7jndFH3nCZdFp5TYCY7NpfN AL9mszQ7Fjt0Zd7ZWyztIHy0XsJH6y19tP3qlf7gVzquXyknRVwpm/t+rzJvsiPzJssRkwf3 NAcK73K88C4nSO/yuHqFJH6FZP0KFW+yknFi1dOPX2cz/eX8tPs103C5/5bhpCpFFa4bToPM VhYjDDfpXbdupBsLaYVoKNH279lZxOGKcXVwoHnkR3hDpnLKB0ilfxuL90F52NqKoMab3E43 1OxzhuE3ZhwITTPcLWO2eeNXQ/WeVgjhOfn37D1/uv+DbTzyo5cwuFvKPqqfV4OfFB/sCLgM /gJ/az4Z9cecmhHyI7gMroB0UNkVOgKsA2FgB2jfnJAOoBcYDcaCCHAU1HwLX8hbdF/2P3dS r9L5f1zMgag9v26NWLtyWRCN5830mTTWe8TQwQN6M012lmuy15huxCy/g5zvz+Ra05fp0iVC d0YI3blR6s7Wqu7sxHVnZ6bTk+XOTU2Php0Xmrpttnaedtn00yP5p+fRUilVyJE7LRrkiKs1 l7mWMvcBi8a1Y2nvHK2lo3JElMI7R1z16xztqr7yswkylyNzJaRFLCNzVZjFepGlzXK1a3RA xqWgPjYbgONUYYwqNH7kTd+uP9HnOf7FOc+h2rCt1WOtN7Gf/3CD6XTJhuV31SGm6iXyj60G dvnL6F5oy7K5FQuYAKIZ+vcSUJzfi/3jjGnj9RszjXu7EEKK4RJ9339p/WP2aJjpYsll5Rs5 E5NTAT3qWkCP7rGqR0mHkdCpNma9OqtYe1W0h+5C5DkD+1NK9PMCsAUcBpe0PrfU3W6a7qZ6 ewxYAWI13X0BOEF31wCdQU8wpQUhPiARXAXXQAq4B+zfRv2WuI2AeytCToJP3yXkM9ATfA48 QSQ4A84Cj/dgp1rjOEi/ce7YuVjMJffjJ4pEkk3w9fav3E+CAoNIIMr8iI/fWB92mD4ros9/ A/PNz9eKXTmyJDBfbKBjvk95a8/6lOniYYs5ti19nqaMcvze9x6e5ue4hRLzfTi3tRJ9H4+I EdhbxBsiDCMRsywiEVXRAi3PGzJL+2OUtsmiRoWx1cbR1sIs3d4yjMOaTfojDYO/m8jz/Q8z +wrmK/TPyf5B2MQylr5XJ2X8TtXG7zxwgI7fdzDrecciHmxl/GWDKqxRhdXWeRsjVOFLwxbo Fr8HcRjBHWBCnoNvWuvzDnrIR7MUVAcU271Zxto+zwJVWnKd7QwyNd1dFnr7FdC0Fdfjp8Bf IB28Bp3dEXiBb8E6TZ9TXX4HpGs6/W9QrjXX7S+B7Iw7qdcunT99Iv7wwb07d6j7vL71/3r6 5AnDvAYof4Lw3s9x752utTlxj70UsiVsHH1JSZvSpfjRcObP0z3ZrBglKbqHn6Tv2GYe90d8 fjGcrcbNY+kmlsbzfWNsdlGZpXXkbnEH0yGWnmXp32LuQURkyEZGhk6qc4/LvH1X9NaEnhKe v1suO9aeee49iGkIn+eMIKalcjVzo5jbbLI2LjQmEf5/UfStlfbhia3A9mIX8h6th6Q+stF0 QKj9c6T/Kz9qLH4L5oAgEA1SQIc2hIwEo4AvWAKWAZd2Ft9IpuFKrPETgXcNN7slq8KWb+2s qWalsMXQnzCLM4YbHslv9Huwp3lhhYqnlx1sYftsSrf3ZasPDjbcEvrSOBR9Bqi6Hb8HKlFf OkDr34eAoB8bgkagMXAD7dvwPhf9PQHzrklgSlve5wPA527w10EQWAQWgx3gF3AJ3IAVfrUD bAzYAM/zFLgBSrkTUgc4g74gCKz3IOQgaPpfQt4BMSAWlOiE+xJ8Djw7seGXSe5k3sxEJjXp RCrJi8uLjrsZl0d2omTjyqCNbCUwkMwiX5Hxqv+7KZ9/v0nzosu09ahKxHP4yvGIfHvo12kl NfOVeDmyZ+tHUH++ckFHlbOs1kr5M/7Dbdkz/tr7ALRn/DVJP9NS5UyV5d+0VPubaKkdEnv6 /gBSjp13to04b0l5TjbfaFyYMe4K+mv9PgJkgixgj36uBz4Ev4Jkre/TgQn97wjqof9bgB7a vTAElKT3QUe6x/t2yl9Jiaf+OHooas8v2zasC1m+aH7gbL8Z0yaN94bN7/0ZX/NpIi3oI1Zx 9qQLC/oCt+SNxKpKEx4fbC2sc1dhPT+R1nOqzF2TuRfklZuqV24lbPu78vhB9fifvGUn9Jb9 LncEHspmOVj1Lg9E7n8y5yXt+1TRQh/ZmhCZs5XXrS9zn6gt6Cda2F8eP0aL6hRVfz65D/CT nTXVrBSMPYoswx1GWdbtMLLy79H0t9nqS/Hb/ypi7FUBzUBP8A1Y35Hr6b3ghKavz4NLFno7 Ya7ycG2MevUDhRASDHcD7DUUrDz1TsMjxbEaVEH2huILGvRXUa4RlXuSvqc22xX00Wz3MBAB s7kR7AQHNDueCLJBLqgOO14TtAI9wFywDxwEWWnQ/8nnzpxMiGXzvvB1q5Yt+n4OfbRHf/SX b1tiezrl3s8QmTsnc1kyV02uCtWQube5/m/J5mg9hRUYIXTsSKlZJz9QtOg34rifPH5Y1bKn uJ4/rej5NKHnq4jPOsnPNmbnrsA/y7Q/L+/+QN3TwHMDWEsHsXSiaG8BzwBvkbkLMmcvdb6z 2trGEOoUth93Gq7YGu/SNFumD1OFqb2tq6YKk1VhvKFgoRCfk3nXY61cDLadXDKiTKlKW+pa v3LRq4CVi3X5Vy7KPmpMUt/7iOZ/3wH3QEX43k1APzBY88UngkVgMQgFJ4FTZ9xXna1+t0f6 kwrGT+qkF51w23C7g9mTOpcNt7UYC09nH6zYURbswPeYBTugxKSVVH1afdwcvA/6gm9AOIgD 6SADlP6QkI/BaXAF2HUhpBp4HbQDOel3/6Yxv+NxMVF7f90aEbZmxeIFcwP8ZvpMZPv9P5Oa fxQxdea6Hbl+MjdO5ubLXDDNlaV+NN1U5RhAStowr3q49KpnCA06U2rLMJmLlbn7Mldd6tK3 VF36gfCv28rjA2VulbXzlWnyOYBjucJSJcjcSZkzSdvmLHNtZc5N5obK3Bcy96XMjUCutqfW n5Z9NAp9kgoyQCbtH5ALHoCHwPQR5mKgJCgFKnxENxNiPgqqgBdBVVAD1ASvgnqgIWgEGoMm oA1wA+2BO5hGP/sx7gvwHvAEs8FCsBpsBNEgpSt88m5oD2jQHfVBQ9AWtAPuwANMBzPATBAC 1nRnznwOuX/j/mmDn4T7CbTKod/IdvzkReSFRKyKwK8g/OLz9P/aq/N0PtPmR7zsjGfw+qz/ 2j53k3k04Wq+kr+0EvN9vLXk8dAp7mv4up+NWY1KFgXDO5axL2dRJtcbWz2NsdsfLAPh4LB2 3yTY2z3FeYGVk4R9hnvKdha7YBENHkUcevCYXAARUcJi8P+rGPVfc21sinHpAXoBH22MBgDX /6EeeB94g4UgHtwCTh+bj+MIjNffwY2ufOxmgGYYu18D326K/o8/sn/fzu2bf16zcunC77/z 9/1q8lhvuP6WD4pQXfue1MpzrPXHXeVu2/BcEWN5SUZb/iPtQjthF9zkmYfLnO5tR8tcipmF kC2oK+zCq9IGxKvHz/MWXtBbuOSmaGFjvurThK36wJq9kSvsWguZ+0Dm5sjcBpmLlblEmasq rWMzqv+Lqq+N3+eVV4iwSoZhtduGCwl7fO2sqVYYwSyAtMtwfSrScPT3KLbYjzb/sOE6iFR5 1LgMBPvAdeAG2xkK1oJd4Dhww5/SHQwF00BQj6cQKzMP3c21fyaBQOOuyzP8zC+G+x1kpIK+ j20i6ehC3nIhLVzwrds9T/PQyoXt4/WgQU9CWoIPQW/QBwwFU8BU4Ae+Bz+AYBAO1oMdIApE gz9BUk+z2A99kP+XLRvXr1mxZP4c/5lTJowa+nnfT7W1/h5cb7J3tEkpRGjrNSyiopVuNquz S9TZrdaJMatzUtQ5pda5bFbnpqhzS63DVvelVIZr9bJsB3EN8WwIjbdwzd6aH9/FjiewlD8N bEccbE2fZQsrNCxbfGJqNvvELbaD10G8r6ZantaW6vIdcVNl7ozMPZS5N9Ro1rsQaq+x6OvX MNFqAF4HruBt0Av0B4tBGPr9ZxAOUkAqsEf/OYB6oL7F/UDvg1a9CHkXRIMkGHLfPoT4gziQ SOlLiBc86KFgBQgGK0E02A8OgkSQBtJBXwybCFBzACHzwO5BuHdBCug1mLv398i9GyTpFInb jyG/N2cvinLIDhzaQNcEQ/OWhS4OpfXmsSXCAIuRU9qVPnnHt/Xpq4a2P/Adfaq/39fBGn// fk/LnX/pMXwNT1+P069zJ8ZydfJOjOXqY2q+kpQYyx2K1/Kd51qMxXvDmhXFWE4G/6hf5z/W 7QMwfnLkuqEQ2dso9GgmRHpZV83Ks421rlpQAbsCHtujb+bgV/76i8T0cen8On9g/migfQ+x 99fiXQ+luGhujaqI/sruSYOG8KtBZVAL1AYtQUfgDnqBIcALTAWzgD+YDZaApSBKG+cJIBbf 5lFwGlzszcd+GiiNMV8WzAc/gpy0mzcuJZ6Kj9m/Z8eW8JCVyxfN/y7A96spY0cO8xzQt0d3 uWpicnyg7YAK5PH7eUxuTkxrpedupud1L11qvWPieLw8fkT1yE9z3XxG98h7XhJaOE6+H+wi X09O0t7RSV9DoVuIPNUW2Ijr2ar24gUzm1JL1Kmt1mlsVqejqOOu1ulmVmegqDNIrTPSrM4s UYe9pqJWUfW98bv94ryMjphXC7au2lTrqvlaV00VDqvCIUPhgGE4Yte/xG2tenNBEeoJTRNV eZxxGgqOWtjtc+AaKAeL6NrP8uvsZPQ9GX/r0YYxnF8Mt+EVZkOyWXPMnv+MC7ezptW5ll9p qdFiuzF76bYDsYm3NZn1K92TrO8CNzW32AvwLCM/2vsfK1nbr4PBAQNfrD/wBhs0v2yX5pt1 1fyzA/jT18E3CwPbwK5B3GdLUPy2nH/upV5JOvMne+/zr9s3bVi3OnjR/Dl+M6ZO9P7Sa5AS //ckphtUR5eyHUO1c92zQvNvFe843Cafe9uVq2j2g+L4IXn8Z+kZJzGNyf9PCqaXuTevSd30 dyZvUy3FPm4ponRL8Y18QrADtw/uzFMfTdi2Ychb2L7hWOG/Jwn/PVm2o620SqNlLkjm9qqW 7IjQ5LGsdDQvjeVt1+qc4W08q7exS5Joo4n6/0+7b63UrbGG6jTKcGAb/19ejId8mGFzQg2F f/kTOhmdWn/U4xEz7tJSSdD1N6EliuvZkP9n70rAqyjP9TdzlpzsKzuaAOEQosYQY1iNJ2Ex rAkQVBZDAkkADYEk7GU3ilIQruXeep/SWxe0tm6IFnBBIgIuBURbsBUe4UHr7m3E21KFJvf9 v39mzszJmRADiL03c573nH/mfP/+f8u/DsXb8WMG+lGTSmV/6helLa7Ku8w3q803K1t2s+yH 3JYzWNRNuXCJtbrDavSq4Z0Zl/n6Yeo/NFhdvwScBbqUgdeBK4BJwB3AcuDnwCnghhnoLwL5 wC3ArUAZMAOYCdQA84EFwFrgPuBXwIPAm0AlLMH7gA3A5pmWOeC9u1/cse2pX2/55QOb1t9T u2LpwuqKWdOLJ1r2e5yQsu2kX7ZlyCfv+fd4bBB7PFjabTVGX16VVPv0cZk/62P07xtj9MfN cv4T/f9Pjf8/N/9/Rob3D9POjaPGnm3jBN5NcjT/r//UejADjFmH8UbfpbxBp15orFR63nD9 znBtN1xHDVf7Rt2VZbgWGK6FhutXhkvkq7te50dN9a3X8dlyokFavS4IqLeYO4i8wC+AZ4C0 2URDgEYgvhL2xByICcA5F/02wA30BlKBa4DBwG1VRHcC64EdwD7gS+BvQF410QRgObAGeBGA wqf2wKNA6ny0V6AEWAwsAX4CbACuhznVHf2COuAo8PevPjpG7x15i143f+pe3173XB0cv/V/ HsIfYgOpJDGPnDianMGuak9izCvGeQ9njHX6FU/MI0ZVbvsRI7kH1L/SO32zjENf0y12h/L6 cWOMJ3Wz3IXqT1fq5sCU9m7yJEV7Qv1aw+/2I+U7bbfv7bS9sRwoN8d8M9v2ZpZtAOZVXtos i7C8h5SbTiIQJXT55Hp5QGp6X87URFxM+Z0262Ks++53MbeI2U82PmubtrO2W36+tu0zspbV On68u8a0z8ajbb7ZYDz58cz/xOv1VgqUA7uARIikYqAEqAA2AL8DPgGi72gq+7cCR4CjwIdA eQXaEFANPAMcAVzg32tm+/XEYpOuGAPkV4p3//z3Zx+dOCb6gHUv73j+mScfe2Tzz3+2bs3q ZYvmzamYVVo02T8SuM+vbdcbeym0XlZfXiVboa+SXa33k+40+lFPGK5jhsu/LzPbrN2H69p/ hPH/QfP/70vtf8yfnnr5noHd57Tztv4gNX+e3usr0nt9U41e3xrD9YLhOmG4VHOvL1LPTZSR 8nzD5d/76TFSG2ZOrc/fl+WjyLpf7Lr/WyvmZC0LJXe9rNosH/6iFTe7bHf5PW3L5U/bdiCf tl3aHCDjVf20V2Ov3WUZ3bFIpLAs+YKwRaZnFH8h/DoFiIHGjgW6AgOBkjmBfcWu3380rYWD CJahwt22N/YLwXZTy8YnK5w2ZM/b3lCz2uFH00ISmqvHjcCbwFWw1a822e13AY1AQVXzNnxi dVM7/oUAW/4aIA0YCGwE/g3YDDxSI9YE1EMfvH/k8IE3m77xZd2aVcsXVlfOmKa/DW6JWc7d pUvtuw05eMz8/6dSan/ml9prjZ0asWf1HtJEKckn8dlc6/j73/n7Ff7+PX//D39fyTPzvfh7 DH9P4e+7+Xsjf2/n79f4O4FHAu8zThNgzfCx1F+faLNKnxoaYIQh1/06bJvh+pPhOmPWFKpe Bg6jDHaYy2AvbryXqp4tW7/tbyxzLPbvdN7XipuXL90/rQkgcP2iNAFN3G+SBZf4VECTHGr3 fXlyi9b/fgn4ADhZI/ve9lVsvyfC/vU3lrd8WV7U98QoOzLLW76esA3acrjYL803/2G+2dRE p1dRSJV/7Ham4oJK9arhw9bLXqa1XH/4/f7Wff3Ctg8r5z8j94eT/+WvAe0utrk61cdTNgLb gR3AXmDVAqLVwHrgSeBdQFlI1BtIBYYDc4DHgBPAdYuIMhfJcZmRwK3Ai0uIopbKcZoewNil 4tzHbz7/ywfHjv7h4FuvvfLic0//ZovcA7Jq2ZL5wv4vMex/TWYv+0Ke/6hb2jdIS1ue1PKN f0WVtiNCnM8rJewUTcL63xb6rOHyv2+zmyFXbzJc5YZrhuHaYLheMVwfGS6HWeZG6TI52pDJ B8z/N52viTnNT65u0PLokysfcvATqVYRqzXPOt7ZgjteTxwrcy3OIg5RPev5P3GSpAy7ulHm vYbt/0tVz9/ZygP7PV/ftbCH8IbbhuzyHwizyzY/TWXvZVv9a5IV7c7Hk+OAqcATwJPADuAV YLdpfDV+GVEvIAXIXta68+Hs3wBUb/uPZSGY5SVZO0bZkW21Xa112nao6HQrEvpjqnOzbtDX fkubgxJaW8c3AqOA0cAYYCIwCZgMTAGqgRpgDXAPsAPYCbwC7AbqgD8C7wPn/lb/xYcf/PnI 2wf2v7brhWefeOy/HvjZhnvvWrF0XlXFjOlFE635DNyNIbbwWXfw+W3ke3kkSGyTjvbPB/Gp 8C73QyxjIVHFpH6kQiHu7ewIE7LygP7sIDsQmvsQu8KNszMilSjzGFAknyzP4linOm6l+kwP 83MtHpbviz5nqXyuQUtNjKSSpxBzWqbr/kqNtJTpLgRbAbcRx0J/ShaZaPaadcw7Ug/w+E+S uW6D1dv2gLoT9dYgJmmXE3UGugKZQH9gAjAZeBJ4GtgH7AcOAAeBt4HDwDtA2AoiL9ALWAgs BZYBdwK1wBrgHuBeYD/wOnAQOAQcBt4B3l0hZ48VIATwAGFAOBAF3AzcslLI4TPy89VnH+sf 3J44fuK9E8fpCD6a0/pzhn5Ul1iz60kfMYRm5xHPKA0BW8vZI+EWJ/rw+Z8hoBOOOPxmi21/ yZQ/wkljAfnODwqTZ4wKd7+Lwcvf2YpEy7abVzPtyCxD9q/aqtCdtv9st/3nKdtewRbbm9Zc sKvFMfsJW+qNMfam4/4sfX9UfYWYQFn8IfAl8BVwGjij8Xujiee7mPj+eiAL6Av00+TAIc6+ dr1uO1FzwTfP2Q7hHppr94+VbF6LyFp4c+ge+/YQJhb4qNG1/Zzmpx7LUzwxfHE99dEbBhUq JBqHI1NB+3BrpRv4q73/PT78oyRyr7CsAmUS9zvtzOR8JVysOhey/2bgFuBWYCIwyaQPntJ0 gpD9/wQaAFoh9UAXTQ8MAsZq+mAR8BNNLwgdsBuoA14F9gCvAXuBfcB3xusC3tpX99L2Z596 /BFxcNhP775z5fLAa+nypbxiWIWWVBWhZzcZ73L2qAnaGJywJz4x+oH+cbjPgvQSvzBcXxou j2aThBqWSJjhCjdcEYYr0nD11Hx6jSe9DFeO9l9uQ9PVgiOCzAb5zzKbYLiKLP1XSv8+dfca sFfT63b12MJxvxbevG47nFbXsslg+xvL9M0ztmT2h9H81l5TJ0odkAgzM5GiamcqsQB5EqmL t7hHstqxtr6xU60iT2Y02eYJdOk5PkAuxV8o7+3X7LAGoFGzxyJWtm5yp4XvD7N/S9hBW2vh 4IWStTBSez/G1DX5W8R5W4doQ1eZzQPP0WHk2NQ4zFWaMNtL7m1BrIAro5s+C42zaaPtmqvD gcAgkx3dcPbst4y/U9v1L3hJXSc0n0tNpEgF+i/MXM83ANnAjYAPyAFygcHAEGAoMAy4CcgD hgMjgJHAKGA0MAbIBwqAscA4YDxQCExY2dxWQPs3tX5jOy74TduN9SZgziJR8DlMTJYloX5p w+vOIXSoywQTf9uf3dx2/Z+RASZ7Q5jBWRSVriake0IKwhUP4C0IpcStd6YlbX0jp9vWHGd3 oMfGHGcy0HMrUYetp5SOQGv93UCh6c7YdCUhPT2kIJo8gPDatUBpkfe2CrzIl1gPM+RCAzn8 5ueLv33xUOy61bCKR/4mXKzg6gBEkXj38wwqJx+V0AJgMZBG02kOr+c9GeAvlcQ63xKaRRU0 DzQDmvX99qVMejxwO9VQGRJQRtVw+WgUTaDBNJTGUCGSMZjyaXSQTGQ2yUTLwvnwUmanI5CL 6GchYZWIdBwSJhJVieSMphzci2SMoeHNZCy7Sca+b4hnL2UWryRxrOZMTlINEqgn7CY8mYPm U8ZlPxQJGw668fiI5Nlnd0ST7F5I6P8PajdeuYRZTAZGo3xvQuQiQh9KuBDuMYhSJGcI7tNw lw93IehGwT0Urlv4yUj+1y7rNzfJ+sWKqa1I2ork/DG1XW1X29V2tV1tV9vVdv2QVxxsmTBS aDJFE68UA2Dp+L5uVPEbQW7YLXPQERCWT4XeN+ZVxVHk7OxfV1xHSWTeCD01T3HekfeRWHDi qQHm5YU6p5HiUxDLNIQbSnnoTpRQKeypSvSNk8TcF/VHShzJ5EpW3GJ9RIIWvjPfc3vorPBd ESKi6NrOjtjaj8/FbzmpFMFdDHdJsljrcL1nFY0g1ReLOEYEjSMDcfTEv/FbfEpyqVMhpaf4 dnrZ3Yvd1wyhTT6vwl0qB4eVGzSs60BxBWKNru2I9HyK9LzBE/c+r1qER8V4xH0+p68PwhgS NAwxVpBITpRmiNLZofzaidylIrSj53xeRxGcxXCCJp1cHEp60FCuB0UE6s0fivDhbsZHFvtw B/gIacZHX/YRYvHhJY+vCj68QX2IfbyqWOKAEEObCbk/hxxqCXkQ5fhONz6E3whqj7Iro3L4 mc+WdxIVwF0NzODvueiVJ9EwtNJKmmdp21nUkC9m+bM4/Bz8X4mQFtFUWOAiRNH6o8XRH7K9 iXnRkmRF1LvwF6eIeg+3+CtEquchFWXw255izH4LUPkJwr9sh4Nk3JyDOAsPJeG7HKGI0aAk HknQQ3RTLLdMQt9C+D6NX1Hm5hT04JjjzDGfVBIQO8c8EDH3owRfjpKh9OM2UYg+xmCt5cdR PFprvTYBTFQEd6hI7QDPKuHTR/GIPFfxWXwKvuxECYIvI/eHGTzPbV3wXZgIYaBYc5ZAV1M7 Xx9lnHK1JQTBKWHUDnELjj2puCmL40ylGJYHqZzL4chjKedStrYw5DO69mF3EUCgibahzWLa DqBd4yoCBG2UDe31TNsRtBXOolqxrS+VIm1oM5m2E2jHghXHOgRthA2tzGFn0GaB+bNUQRtu Q5vBtF1A2wWl0QW13Z3CmLZ7E9o+zENdSfBaiu9hekfxcpscxdxTBoox4IrZkKiiNYkrjboh rD1KGugiLWFZ+U6EK0bM8igJ9KeVPJYHgovmaG1TpCtR1nq8UeuOnzomdO/oJVWV3IL0assN 0dITRS7UQRySHpsMqRPidwiJbmo/Ors5SXgfRF7kL1aV/KKno1JLTZLGsSI0MQg1nfnFA58x NDRP6KgrEHd3dQznuqnvQi6DeSyxuwv1whNgpEDcNlJsrdJYhN9i/GqpyaKuCC9DzeLwrNyr l6mUNmHgSKGRhCYiyCLBt7nqXPgLQ6wlqBnB21NNKRhKybJUMxyyLKK6Kn3V8Y5K51rXoyiY 455/hMaHXxsxIrI8alXAXH78lhTwXQrznUxprhajlFXWGM2yqmegxFjkl1X9OIxpqpAYHs6Z aFPC5wJuge3R+vxat4B0rUvgkYb8ErVazQziU0qcXvzG29jamoYi/BbjlyAlGvKr1NXq1UF8 SU5Kga9McH4mOD8b1Dnq/Wp2kzLV2xhBEvcW+ZNSmGWhv10Wcu4eVgu1tjELrX8+t6Op4CM5 Ll/JofQAt5qsD0tbTdDEuyz3OE1C71EHcB6sofbg+YOrRIqsxU26hG7IH6uqJMo7IsCvudYi UVLaqs0EBIInKfDZTTmlpnBZ5KC9zdVSP8vQDnxsJJfx13SayzgiCKWuAVVIDKGhkRslThEa OioItTlVKl1LsuahIx2ZrFtlaFa6CITqkNk3dJPZl8fkS+eNOLQ3vaX5W5nUpd0dg9jXUKpC aZWw5pzDr4XvhLbGHBWl1ZcaEd/R++oeUVta3ijDIfLmNLWZ9mhrQgZF7o80KloJ6Vynx5fL 8cm8TQ/IWxxyYuKnelG5bk0PpmuaX8Y3naWGsJxjoX34tUudHfFbHmQmQnuAJkTqZXwZrDX1 +HpwPFn+FilLksw8m6tpeTEeOR2yKZ0nA/rK0jBla7Z3j+HTR9dCtq12+Dh9o7T5DGEX94On GMOT+qg73yPM7XxPbO2zZ4rwW4xfUA7juO93DDP0VTniL+U0CE3V3xr5WhcCWeuKrV3wXTxb HWtdxXAL3cOc6cjjlEirTqSkN7jLkpJzzkfdIiWPumNrJ38rDO0iuIvh1jgqm0Pa5sjW7KVS fKp5TqaGZf5Aa3h/jPvPdrIjIcU2eKAhP5Z5QdT4zAALVZRqKFqFqGifN5RIi+9djs9DI0G/ mBaylijlGLvQDYjRrYr4gjRoSDDh/5RD9ISim7ToQLmUgfgC9fBZ6Irjnj3mUikwSoUbvqyl 01xLLhqLNuiv6Rut5XEdlI4I6ThqOhk1fRw1nXxGay+ibPo4MhxpXLazkaoyTqm0IqLQnhK2 pKusUH/fla3uXkKTO4XujIX9JyZrZ2v6Mrged7Iel1wQRxkcj84FupyKEr0xneNYngjOSZK8 7UziFjRG0/dCRg3W9KOXeiM1OU5pNxVwryGY3ZROV4IrxjnTWV4GptovoVTUlgg5AWGx1nQW cMh6egfjMxz0hRoHJ6Ie7HQKG1C6BZUg+ooN+Q9TlRN9Ru6vjEcq+yAcvWURdRO0uamcM72n LXvZ5KwE5nsUup3Ttdp5uyb59VCseSJIiTzZqlKMNIX1VSudol3Fh4+IXBW9M/av8d72dcbl T3GWluIBlM2W6wDN3vdLyE4oBbb4TMMEopylFhTtqlxyv7McuXVp6Uxje6Mveu+tS1mcXpam Akmj9r6xyjZnmqVPIq37kbwZugjQ8hQnZEEH0O8JoJc9h1Ggr4PQqHOY6TuC/t0AetkrGQ36 rehpbHWa6TuB/lQAvezxjOFTQYsAM31n0J8OoO/H9Pmg3wg7aaPbTN8F9KrLSt+f6QtAvzKk CPDTb6b+qMM412a2j3R9kAR+m8+aq4zvRP7nQoqEecPChzWGiM5WbO1fGrL3FzbyPgaxJVeh LtoCnR31FzYqJfpxxQieaIomFaZw6sYzl/nlpLnFCdmCVhMSwGZC9QiVg+YRA75JIv29DoJv WLbZyP2pkA5C7o8noa6l3M/U6DOD0s9i+kKDni0CFLNPswh83DMSqwjEqIWUD11pguCTkCbC Ya5qsimGaCMSQ9ju84cwz8JxNwfpY9WbOE7kdqxLz621LGVf00W3oABJ06rCkqly6eM2gfQZ PGJxK8eh57SActGW7ncVsI9ctgoWW+RnEk2kuNJ68i9D7xMwrhDORybWAPPRrsppMEJ82FWO EGOChBjYH0umSU2sn8Mqs7k0Pg6jXKFzpZDwx5NH4xDPNlce9z/PF48+njKZ9PE6/2Cd0El9 nHtcSQGjp5WsPcQLJg5I68F1gGuzqUYUFsR6uk3kI8wbLtjNkp2ZCp8/EVv7QIPoV6D8wIWk KB65E1KhmRoXTkYYF8aFM5VixCIkaweSh1qGgHdCLCVXSONRcqdchS0sueu45IqQh0IYLk9+ W4TfYvxa6z2FJkBvf+1K0cYMF3OPpJqtmEq6g9tedqqSm6reL7nLfT8oO7OWq+ayNLdV0Xbn aqOG85hCyDdhY83iesmiYq23ZmmKURDEQiCLJi6aqrc0QiHlNk1Eg7Haae0+sDWtk/zqXoc0 dfweaRqqWXzX4ZnjPIlJLnVbE0N2qVki+0/uJdy7C56aMiPmaUH1dlTtLi32mUqyVgy7jJg7 ajFrr5k0RV6ryb5axJ3Q4pIQ6Zh+3hJoUh22JbBT9IYbc9072bYsAYdVQi+KETQh9VYg55H7 C6jzTIiKfs4HXZ6QuZ4/hfrCH4+IiVoUfTImL25rfMd2K9t/2qGg087OSV3vuaL+yluT6rql 9NiYbM8+0bWPq3GlPRvlfj5ZXT3528vfvfi7CFQk5k3c4Cw3z5voKRdzJunU3af3JkNQfkLu +3u+EciBI9khhxccUsqPo0nwMc09DnaV0PgVvGal0iKF46lc6/uaitfgcf3gWr9NmU03gxur 3Nls04vxNWEZzIFlWoayC8ad/8vek4BHWSX5+kj3n4t0QoIkIjSRw6CB3AkJRwIBkhA0nAEM IZDAAAESA3JEhHCMHN8oiOuFKLDgMeo67CyriKuDBwijIjLojjgywWNlEJ3oeqAcvVXv/d39 /u73/nQnAaLbzVdNqt9f9b+jql69s8KYdobVzmogDdBLlOCY0zKR+soiG5FCe7BZ6Cgn9xDk rRPzuYsUvAuXa9oyMhp7HEuZlDPamzjIVxCOoNcRL8mOdXqzTseg9M9Wg4Fk7xrQC/xQ6qNa iqgtHwv8ltLeNpnW4RydOgwGVsEaGZyAc2UmtqrGRvkLXGOEaibr3JDsm6jGnq++1nEXdlcG yH+6M4/sJDfHeC6bibLMVVcrnH60nWob2lyc4ekDz4UfjHW9IAjl/AnL3sjd16rC6u4g1bdF uWqEe1saGQf1fczC/OchVAoqIf+8dIVAf9dhzblz2Euxsd1c1QrMpT2ec6Rv1/hvqZBX1wiP HpxeB56C/RJ6CmwGjaqNRVvfUa7Vh5vIyIIuNKt07svxrQXnvoww1h1MPZsa7CnBh8BxU0lR iOu65jT6tNGa5tHGSbS/roV2ZuuarCpU6YOcJ+WuNEVZoeNV5+O9vWacUVSvjPqdq4Kj2ZVM plkGnF+hIUIUOp5Dtk+TZOAab8WzhTxX7Wh1KalzOgZoDtERcHJGT4B4ewKDW+mP41wGZpdw eb1ELtV0B1/vEvXM2RqV3WvuBPX6AMGb9Q2hw7PNUVWnaYM2qTYRmfek373od2/6nYhXGxwM C4ozORd+8Up+PFX/4PG8mQbnhZLcxZIGFfQ+bKKnFUcIwqDsXVxSRqh84OwFG/0oVPLxKbbx 3Ub9HEJKlxGMDuhg2XT+pc04/6tB5av91agWQPurSX2/9lczO+fh8WsQcY7S+F/xF6vXr1a1 PNpfFTq+EX18qYdOLja0CRR6zatC21ChlanQw4wKvdxJoaZZUei3OwcTgQjvscA6hXf0RU6Y wxCSxf1d6/qbqDsW9KCEsGtFRRBlcEMMQGeAMQAbAe4FuA/gAQMr/B+iQc/AnF+EDmcymByM rI7RFfGGfbxlBU9Y4Z7yMYTQUUAVPWFAqEYvAVgJcI/afKVQCbuhCkZAJW6DylsVQ8izkNmn 4wg53IWQ57sScn88IdPBouX3JqSwH/Qv8N4XAD4D0/yHDEJOZxNyYiCMiECZggsIiS8k5AJk ACN+Y9RfjPyK0f8wAhhGgcJIMBgNBG+Ex1vB8WZgvB0Wb4jEWwLr1Zv1B6m3fuDJcTw9jCcI 8RQZlm8k3X8L9ADwCjIaAF4DY1zs/6D9ACbTkQmhYxN4JXjehI60ce4Y+wGc7cMQYTiankvY xe81dPaBXSkP2SCLqBUk5A4APM6vHkKnEUdWExaGBC9VxxsZ1gNgfMffAWwE2ASwGeA+gPuJ eu0f1HkECOrXUM9vQx3XQ/2W9CSkEcxXYiYh10F7hkAdvjmSRTzHqKkYOQ+jJ2EEDbxFG29S xdv08EYlvFUBT9ZinRSrMjYObQEAXmdUjjNh9HAMod4S+nJ4jT32GYsJeuwsEgqQE4xcthZg Ax0VgtwRdjuhw2GkmjqeelzzqTc2HyzxMLptv5LOfTP/ejzdul9HEkDZRgJMMjGV6wcwBMCR A6UcQMgwgBl5hDwM8ALAxdEspvNQgEKAlQCPA5yB0puhOXtPYPHgtqtx396BogRBkyXMZRra cWK0I2YN990g+DZFO+7X/OI8y9Fd1cH3CbsCEnWvG66Wqzo4CaBM1b+O3fcgF6/vCEKallFz Y2myo50KYzZzpGqzjOrfzu5jBTE0pRlwxt3ahJ69yXy4sGxNt+fsT5WmPXL4iZUfXXCQTPV+ aqd9cT+7pXbHjiE3742LLvvf5PxVafc6yFnps/12bih/6LO839942NR47s6v73CQu9Xz+xEj WLA297Pvk3eO70z48wfFQ9+bsO9I9EoH+TicPbt1jOez0x4YH7v2lfyhs7+qOb5x1vhMBzkU xp5dWuH57IEFJ3ctaSj6dsWpSXlDR21scpAuah7y5nk+m537ztjz9mGFz77Y8OrucXkLHaRU fXbKEvZsLun6jY2WlZaYNDQ04BVKNtxY1rSZTv0oTYpa0WjEI4ipCZ2sCGJuuoH+HtxkE3Yu IZQOlTRIfX4I7VTY7wYz62nGktAmFJw/GfCtb9Fmd+C9OcRswm5rsIndyxPZZHY2OWatgPZR 7qxhBybL2ksGbZ/nyprCssb6+l507RZnJ9E3TiNZJIOkgz+ZCtAfcHlauk5ahk5apk5alk5a f5rGZqDSaEomfGMeM1We7rRMoOkP44p04JGi4Ykp6fAbPpMCfD15ZtDvFMDSdOhSJflMhr+T dOjSBWVIo79netQZT5fq8T4tzzSdvCRL6ZLV+nSmOeszWc2NmC6LtgWflkZrmMlKf2FaMv2X Jk3r71VnzrQs2r7JkrT+tO6801hqqkf5nGlpkCpOS6XlzPCQa5aWRfOR5tFGLK0/LX+KJC2V 1mamVxq2D2v7FElaOq1V77QsWgZPnijp6bSF0r3K4G6/DEoto0uWtnsGfS8awn+A6UjAu6DA omL0zu1gzO7v6obFdgaPg3f5Iwzm3+rH4F7w9E70J+Sj4YTEFTH4bmLr4KUaBhOXaUcjJm5c YeFGCMGqtx9BR6zM6w/nPP9I1fvH87TgIJMYdSTgPLYYS2dncMWc0H1u16m9fzfaYTAvIJ6O pNnprp7oRUJGmiAjw9FSw0srAM7AC3cC4R9VuMfOIALq6RMVDkB9fQj1dRLgp+Fs9RQhaFLL IQTgdaivj7k6ew/c2jMA1eDi3QzeYU/wmnsB9AYoARgNsBbc1+fqGbyhwgGAowBnAL4CuKDC RRVCwN3tBZAIkAMwBKAEYBLAIoBlAOsAdgE8CbBfhYMA7wE4VECXORSgN0AfgAEq5AEMARi/ jJXFBC0uAiuAEb6t6t9isGr+Nnr9xjjgZygIRwHARhCQ+wCsIBgdAL4A4TgL8E8QjO8B/hPa 9Q30zEEopgPU9YHREMA74KV/BPD3dEL+B+DjLBgFAfwI8BNAH2jvRIDOMAKKBZgMbT69iI2G jOD+1QJsBfg9wDMAewEOA3wAcAZAARc+BGAH+L07AQ6B5/8hwAZo27sBvoNhy48YL+03GKUL vFLwf+cAvACwD+NqwBBmCcC/AjwDcAKgESBkPounkQYwEGAuQB3AYwBPAqTDkGcQwD4Y7vwX wIMgNw8vEcuNs+2w3aygUa2DIA+IayNwyw6CwxFNrYV8xIK7KbJhtLyYzidV0THOAsDxROUo GFWVkTwYD+KaAdt/wU5i19EZ4AX00gDc61EDngHuf02h1n4qKYQxZS2do3PuhqihJ/On0n14 s+la1VS6g7EvXSuo0s3jMDWPbA2jEsauvwEM94CMd/2fCM7pCOgLMly/THX9MhU4VNF5UMxF WQvzyXZf/Rry+Uto84BcBuQy0OaifKb+Qtrcnc+NZJnD4Tg6buExR4TnPwO5E9LeWHk6R5S2 HNL+lmZMFKWtgLTOls3ForQGSFuyt3GKw+umPgNZCWldm74bIKJbBWk3b/zjOlHaakjLf+uJ elHaOkib/M9LX4nS1kNaxoDnpojSzuPN4nueK/BOI+SSQ/0IyhC5fB/OmJhFafv6HpOmRQ6M MfwcefouUdrbHRsN9Qc/KRTl5d6SLw3PvZcVKkqLrDtjBA9G+L7iCYOCZHl5OewLy4l/N54U 8awecdaye/EAi4hu59wG6+TT5qMiuuPXbrPuO/JYuCiNVCYqPSpSVonSyjp3CX7lWP5MUdoP KUdCQiVluPdOW1ifx/f83ZvORnLrHw77LDTrURHdhnk/h8vqZcpNqyJ+6PtDmigvNyT+GPHd 3N02UdrcWYttsnwOHl8S2aVo1eeitD8NfCuybsPZ5aK0W3pWRvXZeNYmkt1zvYZ3lNFNmbM5 Wla+B2os1+QXPdBTlBaV8cw1ERK6lPnhnWVplYl74o71qPpOlHah/vk4mcyvLzwcJ8unYUz3 LrK09aWPytNG5XUNlejDg4bCrjK6/mPC7bK0HR1S4mU6lpYyOr7s1GfbRTLxTfnY62U8H6ko 7XH8QvFXwrzkxPTKmrenQpT2WI/jvbOXH3le9L5tCctvkNV1UsWpBFlephduvXHInofeEfE8 WdT5Jhnd+/aYvgZJvZwoeanfkdc6nxSlbZ3yUr+u1w2/KHrfXyw3Jsved129PU2WVjY+IVNm s55OuS1TpiuP1CzKXDfj9N9Eabtz12Z9MMj8vEj/utfHZ8t47qr6MFuWz2nDbs2RydIL8yIH yuiyR44alF2797eitAkz9w+W0W1JXZsvS4td+H6+zEZOKSfDZHTE8tQwmY6tLM0Z8fYPrzWI 2vb7FaUFMroDtszCu1aGGUR0/RNKi2R5KRl6aqSsPk+sMBTvqpy1SdhPR19fLOOZXlo6Sta2 Oyu/GSUrQ1J0zzH1L9+zVFSGnRO+GCd7n3V2dalMj1KD6kpl8hnX7dlSGc/zOb+duG7Q28tE aQ7l9YkyujdjZ0yWpZ2e/fBkWb0sNOyaPP3clhdFulJa+m+Te8w59LqIzjzSdqvsfSMW/eXW TXfPeUhUn9ZIe1mSacwZUdod0xLKZPl8sCBzmux9p6YUTNsz55MNIp7dw6+vlNGZOt5TaZW0 3+oiR1XRpAfqRDwjMnJmynT6o4FDZsreVzBl2cwBSztsEfbh8eWz4jqZhX3HXwctmCXjGVy9 Ztb2N78W+jZ3dfx4tozujWFT5sjqOnr213NkupI14qZqGc/i6qRqGc+Hi0dXy+r61U7/qJa9 r2JY1XyZncjJX10je98Wa6/bXtn+2lPC/q/yzG2yMtwY9OVtsrz0yX6lTqbv2WONC2Q835qe t6Dgy6P3C8cr5f+9QPa+8ltOLSi7vT5cqJuL310o8xkKh2TdLstLh7Gf3i4rw+HsDotkbfTF iv9YJOPZLT5+8fAZ6268jXinZQ5+cbHM/3x5wveLZTzLy7feIauXr+dsXS5Lu7voMWna8XFZ K2TlmzHv3RU3v/fZQqHfk39hxXKz7RVR+xlcq1Een864d1Wx4ibIGDyDqFgt5YDjuQUjt+FP Rsm2T1LK7UEW3EfuK2WW2UWZZQbKLLOvlEeNLsqjRgvuuNVSXiPYBBGqU85boPcfDVBzAzpJ TfosxAX2i4W45H6xEFeBgIW8FtkJmBh2k7nFeVbFl1oUU/r4chNlsd8UuSb3AmWx32TBA4EV gAMp1/6KweQnsVkldjMI8o+BxcXA6JZCU5BVxARb8dB5bSseOg9MFA0Tk4ZRsIARSlTFz1qJ qvgZGIV4MTJrmYX6wSxMyCzIg2G4F0NUmXPntCpz7hww7CBlaPFkGuHJtFaJXLPpR8q0VgGm tUoF4MDUpsvU6sU40lfGUc0yVug+f/kH+tW20ovLxKKDDoshfYiGy8kmi66C7gDpnsqkewdK 9w6Q7qnnKalz47hMPaWkzg3krib0jzyIa0J91ZSysHpIgb5iStkEC4RJXy2lrEIlcqmvlFIt D9cRc32VlLKMaEZz9BVSaj4ifVBIfRG9Fqz458yKX4tW/Fqw4p9f8ElEpaS+iaiU3HcRlbLw T0SlnZD/IiplFRBRHRFtmTkPBUMcygzxk23RIwTrKko2OIsHL1IW2egsZoOzePCiT4oiJfVN UdBNTbqodVOTLvqlKFIW/imKlM1VVxQpu3anKFK2vigKPeKUqxVRet2FDVmvp7dhlMP/eG2F kV5iFHBQTCQo4KC0d+vfukEuae0glwQGuYFBrl+D3OCWe9XBAa864FUHBn4BEQ2IaKsHfn9l U+Q2t5Q7b5vwbZXDvElGKVuTcfoMxs0ySuxZih3anqXYYXQ7CtJ35oa63pkbCpS5oeydpmZz a+vgorR1AEpbB0Zpbja3jTZXbhttQNloY7kNaja3uzu63rm7I1Du7sjeaWk2tw2dXJQNnYCy oROjtDab25JYV25LYoGyJJblVqEi5u/gqK1WaDjxO2r0tArei1SezqvEQoslkBK7hDDK+83+ C6GW0h8h1FL6I4RaSn+EUEvpjxBqKf0RQi2lnhDqLxcSEgngFilCKtaQZkYyepTNdbhetNQI MlpfelsveirFjN7XrlaPhz/9rB4ffztZL16EuHi1pIfV49fS7lWP5xXsW83EKLFP0tlAE71w iZlXs0AX9HPAjsO6bKRRtxhiR1Bgo1udjzboK67TZWFVXCysaLGtileLzG/lboS2pWzGFdev Nv+WWdv3kvFlZ+GllL+CgjzZFJj3C8z7/eLm/S6j6jQ7L5OodsXeKmPRtaYRqtYkUMETqpzN +9XqVBB92CxQNJv3Kz2ngMwC9bJ5uw6iqR+zQKnEpEI/1CxQJZu3TupN9ZgFCiRmoet9mgVq Y/PWQ1+mdswCZRGz8snnNAtUxOat0K2cyrniHb1FV8YbgYWdsWg0aGScyGTci6TZaU4fZZy0 TsZJ62WctI2Mk7aTcdK2Mk6uiIxfWdeLtLz/aMWSQGDVKrAk0H6XBNpax/zfaNNmkwz+7+/5 lUyPtI9dgPqj0m1uFtuQxTYDN6Gf0E6E96othLTFzAZ3+apz6cfP0zrXbJKxkB07YrEmKIsa os+i1j1L5xo+isVQykK8wOJXQcQrLX4VBJdcVBauJRc/CyJee/GrIOJFGL8KgqsxKgvXakwb GQaNdLbCdzK3zncyBXyngO/Urn0nL12Tdz+3WFn3c4u1zbufq+TEaKyE9aptugpYiYCVaJ2V EMzoXp6Fo6uzSydXu5A9y/VSxsJJalIDg7SfdbZW2zWz7owRnlqov6Q9tVB/SZ0x0l+skO5v 0iP1o/Qhutb0JBikeGaQTqJBOgkGKd43ayol9c2aSsl5axqka02lLALW9BdlTZVf8rBACXT4 /086/PYwwae/+uy1lBzYpf1r3KV9Gd0qsw4LDADqdEpMxCox19xuSypObLcltXgstiRGF7Xr rRjrbNb1eTVMvF/Xr7GaTkGIa+9S86ZbvPu0RaZbyqplplvKruWmW8qydaZbyrb1Z2OvzGqE WfeEgrpPwWV96Q5g9/v5zGvPRugcb7jMt2exUd9uYFGiGkaDRW8bCHs+1xi5Zj8rbK7R0uzO e8FGDp923FO6CvC8tjPPq8Jk8XmnPaVtAlobo20yWfzaYU/pG8DHamA+VoPZ4vfOesrDBm3b xLwgW5ClRTvqBZs+WryTnvJKskSuOfoT5ZVksVzB6dT2MC3Z3ovia9d9VarBe3a7tdXQRqv2 gc3ojEUrJt2NrRuDGwOT7oEx+BU6jWW8fEbj13Qa5/J1JVfqAMwVu1r2aveml5WFr3IgaoEk HZVKV0iGQjIV0l8hOQoZoBDQkKFFnUkBKgrr6Mf2IeMUMlFx9/iy+2JCBHNf6YoB+TWzOT3E 5r0C46ZsbnzCqHESTB2f1CoctS/9E+OAk2Eqh9xQjoOv3RPjsiTC1acsieC4+NM7MU4FUS5O BVEcJ387J8YNp8DUnqShE8etJX0T44hTYyrHkliOY0u7JsbV3sXF1d6F4+pLz4QbqzAoBl+X GLyAx/FSex7HwBWaZqxMVHh0vRpq3vlZ7YGv8sBXeuDrPPAVHvhyD/xOD3yZB46BKHgcgz3x OAa34nG8AJ/HMcgMj2MgMB7HgFs8jkGheBwv9+dxDMTB4w0e+cWABjyOwcV4HAOx8DgGfuJx DAzD4xgEgccxaAePY7ARHsfgOJr332kL43EMqMTjGNhAU97yrXdo0tXyNR45QCUZA5vx6RiY i8cx8ItG3jzqx8kv/13GD4Oa8ekYmIPHMfgOj2MQHx7HgCo8jsHHeByDtPE4BhrhcQyUweMY xIPHMQgMj2OAEx7HQFqa9k9dm6/Rp9JHNekYkEWTXng4jscxGAiPY4AaHseAShr5H5+gwTEw G49jsDkex6BEPI7Bm3gcg9Bo+tOKUwk8jsGCeBwDSvE4BvfhcQwWw+MYNEjTHvXxGnnFoF48 jgHqeByDVPE4BgvkPxhQi8cx+AiPYwAQHsdAbzyOQTk0+S15qR+PYzAMHsegblpzukfTnhiw QiM/hsKumvasKO2h0Z++xzTlweA+GnmuTtLIKwa443EMGMPjGBRKI2+j8rpqD6A+pbE3GFSG xzHQCo9jEBiNvZqzOVojH2PC7Zr6HjlqEI9jUB7N8zkxvXgcg8HxOAY70bR33RnNZiAM+KUZ D439VNN+GJhG05/MrtboEwZo4XEMqMfjGEyGxzEInCY/A2M09h2DFfE4BtThcQyoxeMYMFBj 7+0xmnv4MVCKpr+q/EajXxgshccx6AqPYzA4HscAdzyOgYk0/Cd8MU7Tv5fmjND4A0WOKh7H oI08joFkeByDPvE4BqHhcQyOp9Gn+HJNfjCoi0beblqleZ+jHX/OQp9pJ6lszJdLvPawhQr2 sHmM9URsS9494FrJ9GSL+/HQYdawSWxyBD7t7LORBD76HxMV8WDFYFRoyF/1/zD835FbUGIv nrZgRl3RjIX29LGz+wHYR9lvGFpTu9SekkDKyuZVLqhNSob/5lSlJJGSsUPHFJaMI0KyifaS saQZhuC5mcz/QvYauy2m2SJbQlOVKowuSCYacbA+0WjyqVg42toPQ4xDse5JBfd0tvZzt/nT 4T/VbzV9+9N293CefhspPgZe+Zqr+2F2OQhMIgKRgEEFIvifwf+1dy3QcRVl+L/7yMu2bIPN SYuka4tQkO5J0kRS5ByS5tXYPApJGtFK3aSbZGvSjbtJoYDHKIKKVYO8tUpRUBQEbaPgkZYo vhEfRyvgE99vPSI+qsX4fTP/TTabBDe1x1NP75/z7Uzm7sw/c++dufN/+/+7nhxPmZysHUkN JwbDQ9G+WLjsmNoY22BBSW+t/Li2tu6/bm2KhPDmkjeXvLl0XOaSf9SRw5eLwQuW3u1wfjAv cqFJ+52JK30uBdN1lcg+zgtsC0kDNBbRR9Dny/EHA0GfP5A5rdz7vUPiMigxSWFj2Yr0MqQX SwJlUaH5VIl2fBIMOj4nN8c3xSenMz+jfGmX3ajTjZoD5C7ONNqflxPwUebVXiNJ6I+aOhdW mjq5/nyfL+gLzFunFjpGTL0YXt1ew/4uRP0lM3cRc9dvRK30ca+RLimTs7M4G5dQR/7Cdfzn ll+6aszJ3APN1fJG1B2QXXgdRos9QhNrXWF2ddP7U790zBkNZr4nN2/6wtql9NTwIVke/jBy LbjGYbzG0d8e6ReSK+eVZad55jUTKcsZc1qnwi3sW/Ny0+8sqz11aah7Se/pfTg/OeY+nMNj a+Z92GX614dl3KYc62onIE4gr3jLUXqzWbfXtXtfdm0FML5izZl+49X/8FLYtDHz09DGXeRq eRzptlWwrB9hKR8Md+iA8ldvORp6k7csH5vclTOROy7juGCFpbyEy825XU7OCKtYyy+ybeeB 3XOV+vSBYcn8c3DvnS9bzd3bJr3446yJoaQDr4MyhNkUxVzirNgqF0mnNKHGJtmM3AaUNEgz VikYCVKP1S0idWilQ4rxf0TKpUKqMCeatJ2YmV070VoCdzlneiPu+jhGF3M5VbTdb+ZBysxf zn2+K4kau6ZWo9nvieBOnn5PtZlFHEcKfwlzvMesJWfLYvRz5rEwRpLSeXcc5V/Y4wQKZu+3 OEOeuub2p4+09YfuuT5PXnzWgSdLSU/iQKEev1Uv0z5dMj4nNrDmG2K/4ngRvW75mbpjv7L4 DMfu+Coc+51GzdrWy5EWmI9mLPeBB6Z5+O1x7FcC34qUT4Q7HfuVvvc6dsUYR0ru9yHH9uNn UF6it+DGSHlFVbhpcGggNhjbOZxIpsKNI/HtMV68EndJw3uY5z6ktj8ZTw3HozvDjcnErlgK m123JNJnSqpjyXhPKpXYGelJDOIpk5xuB+/MzHOcDc017Rvru8372P96bSDcia21xFIlev7W SbyHeY6lJd6TTKQSvcPhrkRye7gqUir9hiIqXmwYB5MPnXvd0KGDjsnfXPngO9dP2Pzonv1j yPu1L35dDplySfR7a5YnnnjiiSeeeOKJJ5544slJK/PZ/yzxHX7s8N7IaaEbboH9f+6R++h3 Fswo2+pY+36x2pxDYm30y5UL2KNcwI1iuYC9Yn9C506xruP3irX5x8Xa9A+pHUwuoQj4qti2 vy2WEzgiM219ljW3hF3T2tq4W04x6eNqA6/TlLQU07JleeL6L8+XloTseJ6TS1gUsp0p0cF1 xIcHYuKa33JjwP2iEdjfWnix9v8V2qf97rkWy4Fs29xUt62xs6nOHF3klmxsbmrd1D418hqk rcCVUi5lUip15m89sFaqlNBaiyNlKKlArgbnoErOQ67UkFelKG1AWR3yDThSKa8zvWS7T/jJ kdjeDeGaMC2WafbAr1d0JUDPH1LfcRkwdNn50iL10oh2aqVNqqVdOpBvhZ4ajLwO/0fwXxvy HXhfM/L1yHWZkk3mKOtZ/6iVMk08p/dl2QnUl1NOgL6E5PVT98pcfVk5qy8b9OMaEo788CJl 6M5qtM/eUFOrND2nzi1iwxzy59H5olk65yJDG2eQofXQTdK23VC8rVmNOed/OObXyCtN6p9H 54pZOncYLX2GtOUIm6UT7ddDU0eapkw9q3El09vP1LNslp4+/PWi/SjOZVR2Ay6RnDkOTzzx xBNPPPHEE09OdnG9Lf1qrwd1V83P6/N0h1+gdvEitcWXqOUTUlu+UG325+vutEht+2K1n7kz Pg1gHN3pai5zVxoGXgisMrtekTPUcmA80VlqM9Od6xy1qBgXtlYYVivCmBhaqfzsvlxtfMaV VQIvARgTx7jR9bT7AcYYXQAw9pDxTIxJrFaLlw57tQD5DcZSNQCMmWHcFWM9GS/HmB/GvbWo 5d0GbAYuUpu+neY/0GmsIzowiTCu8xK19RkzyDi6VwGX0qoHXg3Q8asbYMwR3WfoYsL4qj6A cTSMJdxhrA8x7nXc09PRLKFcC2O76BJCBynGQTF2ivFWlykHQ9+aKwxTIHIVQDuf8UWMyRkF 3gC8EbgaoCfUNcC1wJuBtwBvBa4D3qZcztuBdwB0RmD48vXAu4AblOO5CbgZuEVsqOhtSN8N vEe5n/cC7wNu1+N3IH0/8AHlhO4CPgh8CLgboMvaR4B7lCv6KHAfcD/wMeDjyqEcUA7pE8An gQeAB4FPAQww/LRySweBQ8DDwATwGeCzwCPKOX0e+ALwReBLwJeBrwCPKhf1GPA14Oti/Vy+ CTDg71vKUR0GvqPc0xPAk8B3ge8B3wd+APwQ+BHwFPBj4CfAT8nsAD8H6Dn1S+BXwK+B3wC/ BX4H/B74A/BHgD9H9ifgaeDPwDPAX4C/An8D/q582T+AfwJHgWd53vXcc/I79J0B/A5/lRDz nz47jj2eRz8d+ubQL8ex/jyL6Yujx59Nw6la5sKT/w8hF5LAyhHGykeXt6RZMbKvX4Q7xs0b RibfcskT9vHSYPKVBx6lj9JEbt1B+icx4HJUtdQZt72oHGsgYAHu3oXWod8aH17Ml2HVjmIF HjAr78L1L9FYhIXU2cf15aCt02WcDLfj2ZPAM2BkyvUw2xZXYPw5+tzOVj+Hf3/EMe8P4slF rWSUeO2boL3X9GnQXJm4cT6cv+01x3D+J9POf3DWyBfWnyroDyxw7Ln68wN2/1NrmLIhPNG7 ZceC90+F0O/T/dLkZPYRI64mqzWGMzCM/URCHe+zlyJxJHN8meLOOzfN3P956/XJKw6uvr/A 3ruZazf37xn+qHWJnhF+BmZsgpZ2lqHITCbmI+7xSJU8s37/az376kSXfwNQSwMEFAACAAgA F4dTKVnoZX3zAgEA2k8BAEIAAABlcGFjaGcvSVRVL0lUVS1TRzE2L0lUVV9TRzE2X0VkaXRv ci9IMjQ4X0ltcGxlbWVudG9yc19ndWlkZV92My5QREbUvWdYW9u2JQhICAGSEDljkTMIITLG ApFzztjknMEYcCKKJHIw0SYjcjTGGNvknMGAAWOyydk2jqfPva/ufbe6T3XVq+6qr96/taek vfV9SxprjDnmmovXUFVdVEIMhYBS8G5uTc1BKf4cySKQCD9HTyiFoiKUQlzXxdct2B0h92fQ +M9LdQ/vYJdAhLiutYWqi5Ofs8ufH1BSglIEBQe6OPhAKSLgiREzhGlbNBsY1OdAFEFQBeGB 1ALpw5MIUNLwDGd8vy2SBauNs3dvsxdLGXJWly2MP0HQUcS7XgZM9zrJw2KRW4ZoXxQjzCEj IAvHpgpXx3GBjx4lc2eMDNKe1zXwC7Dha5r2Q4tx7nIs+m5YrZhVBHdh8icnwckQ06f9sWXU uR0uXOVaZVtGA2vsIpl49a/vg7tz9eDU3nySeZMefk/xGjJG5bj9kC6wOJY6bflZRG8iBc7E +SAUygJV65PncC1HZt85OJ/p/qQizGo86Ah52kvPzurM01lki/p09y324Adx2lo9TYMueJB2 MH+D8M6Lt+3R7d4nLd34kFcPh6Pvvf4AIwM8gr9IWN7aVchrzv34xnQ6WA1o5NHWi25roF1b eOOZ6RnTrn3R3SyShLRtq/dyj0A1e3u6M0KcQpe/4DzdfXGgjYKMckFtZ0g6T2Km7FS7Zz7T L3Ku4po4dLQISjq5jLCKxjtRDOcDSfK9ZSDR4G0UlHv+AXqYpNBbHrqVBWQh4wxWOn6pM2fP pnba39QQH53WKwmLuj5ifl1XVyvc4K/aUg2KbFvt5gXbrjYMYwnDivWUhgeygimU+i8V9QKV mECNXXspo8ng0iyQTq47I07AvhyZAogplYeUEbbh5GUCoy3QPoUYIVLd+Q1Vuct6y1/gLYFV VEof2BJOBejGiIF0jwPsyKfjlyVUIomcmaxgNNvHGMKPo09tXLlPhRJVmBLp5UcOrhlBTdxZ 1SDlfstqMnStCtcITaySmDJWc7u5rlYR0Q5zXDf+shJyiB4hncuGMMm1HF4ICZeWO/KB20fB bDY5V5rcgt7bhoT3o++sRxxnIpZlodECK1Z22Fz9NliZ5jAqBoAuhZNTtlA/cHgyvxw9sfSI m7ZkhOd54MspgIqAdVTEU8ENMfrLODPNn2pqfCRc/RIpdd65MrK6636PSoQLax8rpIvxFpYK NRmKHxWITbQeTXn1s7qMT7tn9uuOSU+ua3cmxrZxZbs3ezrlYuSSuf2HsmDR6obSEGEmjCys DL7U7N+HwPBshZ4o5Y/KMWhlQjrMKBiWLuv/6Oxk4rJPlTVu4J3dOHzzhhBc7WQaVX2wh9lw SDVtLhBM0Q+uBtW3dmeBfjPq0oEX79G1230vCqGD9SQfwWFbBhRwCLfsjlEglmm6FXLoa/wc WkIUJY//Hr/vZEUc6ytg8kA1ARH/VQprdCbwtrb3vcUy5GWOB8JJMLQ72h1kcfty/YFy3oWS fTF8eVri4QDby7Te8e0oCJUXZrizvbJlz57kI/dJ2nQWmXE5+3st8OTLj9K0zkfj1SUhu0Wr aU+sKHLxojraPPXdGvEQh307OyorgaiQn1VMy0aaI+e7sgAOjzmP/Bjy4HJ6Ac1HxftVd9XW WNMJlv0f4hE42HwuVrIR6qBzO04dyHTDzLrRKeA7xbAxP0NQSCP9+Z1IvW+scUAiZtssCBYT 2dsSkUGtUqxuSpwlmem/RqD6kWpaHDnUUR5sBXCO8R9AshVyH7iQU7aq+q/DpUIdl2imJUBx vJHZi9ceE8beWequUuqksMKJgsaQni5JEqKn+oDwfm0jzPcK45PyIjpiKRFbVlUa++YF7NKj AOhdVdff329QnKmsR3CjXvTWzdHlqZ/YypNsxXIReRBDKVx8nf8Bd38O/w6Vcv/ATAmUFPLf w+j/CkpNw/xdEOKGDm4uf14YOgS6+AYjpP4Lrhq7BPndDXRyCUL8/a3qfn++9m8jJEL6b+9B /G0sgZD55xiFkED+l4u/AbC4YaCfk4lLMAL1b3f8ewz7523+fEoQQvbfg//4bhKov8J5Ccn/ CNB3DP8d6LHushEYUy6AOgm4UHfbDQ5Q23bP7XcUY4JyDmCRaGskI0S9LIw5RUCMGbqTdtkR YaglXQjFmXhkrQajClMcSeTmZ51R8ZDBy7SIdGQMmELdhLlr5aYMM4Qfq9W1KhiXX97HpKvP oQrX2uGOHB60oUufUANl6kVUOzKluADAmqvukoxQdWMFVV+F6LgRHyxE2dhOgGm4MtORPXTP QaIICMy8K7LtU7/o9QXuwQBCsUCR3A5Eq94y3euD3MSEjgCu1PVJ0zwRMIvUO1P1LYnhDh/y 1sH4hePC6HSezNuDTjbBt24IsnwWk3TUMqwRFQJTuGGr0y5V5Vgnq4iJhizFX1mWOs6kSM8k Md2p/0aeokl4ScFNGJWrTbxcTqfAgtdlBROJDuSUEO6OzGVHtMs/ePfB9gvy08O+bG/H0lKK knuI8B9SaoaX/gR1Va5vb+q4Zl/jdLa+ZOHSW/nowNxNvYp4ToBQ7YCEk0ojzD+eQK/uQWS/ qX5aV8Le6xDFJxw73eEAbtKzxLwDNW0i4NxegUyEZoEM4y6c30o7HSw9SHMZp6lpg9TVFc75 0uh7n+41bg7L9qQui2YbrlF9RQqOrbbxTldK6zsnH+XMFmRPPGPak07mDgYXx2bA16QFo8HD MjHEfUzMuPTwOaa6C68PMhqOhEpEL2e87/Jz1I+nbeoZ4Wt0FNECS+wqYtz4DnPhVenBzr0z 108NytarzEvK9ZWxopETzC5SWXjn143ilzdk4vvA587oJ6R5Eo1eZ0EOsYHrtot2X0iFZZa/ TLRv3kLbuy/j7kEdQnlgigNBQ44C1tNQ6ZsZm8+T0IMDuHcuOEn8FjICOTRLZFuT3JSkCxoS +K6y0MJJ5L2846FS+qEa4/VgHbGn6b3Y8e5HaZoUoxR4vl9sq+tMSLu0rk7YUFj9VanZAwk3 G/9DxFeJ2oyn85xcAsPolESXIAppZJfzz1vWLca/JzYN19CqpbmjkgSUjhaTsVGphcC6R8Hv AvJowuAzSXMRaxlTp9BJdHegaV7gHVYT13m9TfiavAAFfE8OIrT6huV81osZeVrEQ8it7+3O jSOnQF49CxZecmftbGPfZL4dsERAC3L5j8kSuO17606WY+/e5jGljyy2tG776Lhp4Sv4oE+0 7Jl7i/yoN31vJFEHnbzjZvdWRVGBkd/3e/T5abbPK3/T2cnc5nfZXLOtY/l+xd8q8yPp3pvr O0yyvBHzbIVk0y0fTcBY+43YhovtvtzoGU/Kl98bPpd+icQgVHiYMa+xDFDKsRMxZYLcC+kD OIm9GdiBjp8UYwvvDdVz7oey5QJSxiJLWkBg055WLpoJcsG/RsC/A8e/jZAScv8Sl/hfhoH/ fdiTQP0F7kn9Je5J/0dwL23c/U8oAwI4mzrpEELUxGXEQGOBQMl44tILtKGjBCOEc+cfuBdN TIhCOCX2gmZHAgz/ZLo0elUAh6xlFxl2SBV3bkTKXXQepBQg0bWN4FEBRUcS6+M8UDPafwfA W/8AwCC6fqih8vAm1jRRFRxFrljuL8c04crI3LY+97gtW9TZkg3413Mi/c85kZL4l/D/v8vS /8A0SP3FNMj8z36Jv3jUv94YJfFX84tC/Yfmd8ldjC05BqDc1OFFAacHR8xERAnTyzH3E82E sQhJMCXhAMpA1XEoA560j5owqkUtMRDbx9nVqW2qEE8KzPToXnKRztMbwgoO7yK4i/T4sAIR 435yYHJaieJ1jDEqd2J3mbxj2EGeRW93K7eSyzMKumNm2baa4JNry09bkpxb7c7wzsUwnWgp UCoOUt8LPnpMygdKFGv3dx8PFItVc5T+phtvL1Uw7hYsmd41fFdiyfue16ACAsGAD9gqVNQB qzPFg+TfK5nay7Ac+aLqzXf95OjooaB8ubQ1J/lF/SgYIqIXUW+gxzdGGr+KkMmLIeMW7C1R RYEFcZ4js6k6JZa6g5niMSce8izAGyzuww5fz80fctzw66s7UlDRJAjFlpZpJkoRJ8KYSqFB 3qxkxAWoPBBnP9fHKu2+0obaY9qG6oqebls4uZjlsnyKr2V/5atoyl5058H0qhSsLEjlj9en SbtowabZFzD5WtZdmRhAfqKCYBlFCjJ5WpZAL0VuaM9Wn7zsRio0nBTJCEm9GEQmp/gfXNdQ RdfyaJaFHshBPL1adqGjodvSw2Jd27v81T+yCDAHRfUNwTKmGT7IlsAugzyseBv92ontkLd2 Nrh4BXRBIOS+yChveRlLMb19on7Imoh67RS0DNdI2bb/pBBJNKoIoxLVl9dMt12XSI6uyWOc nGNbqByhkKwrm9gCj1+gpRQxNbPGiapsoLq+exBS6ouOEmw7kx2gtMTdjZr3OIjivXSayiYd yFBBd7jJAVNZb4682TVUoqdjvlC/d+j4vvK4rvztsmmnMzNvLmXEhlyZfFalQjByTVqLnj3t Up96Ob8qOdp+7Wvy8Du2UsilKITdJk1X9Q3K5wHvIwlIDukTWZJNCtbuIxLrl3e4JElzKBIU bpDaihEpA9odAt8/cZP5MLoC8vdBZpd8KfthbRREamcw9SRLOJMT7huUvfryroSnq3K7+6Dr OEPa4qd7Yo9Y3AUXcIPunQpkD22fHBiuSZ9l1THzFXyWLTXE+s9p6AoJy5cZAQow37T0u5c3 YSGshY3mn2njS9WnHEcHpYReYBtONqV7Xnvr5Djl7dbBAtr9RNQ/dsSy5p+ATmraF7vcnlyY s/nDn9oXQbjd+9EbBp+h9cEGLRaNVrNFbze0fxe2FZGLdb0Uh85j92kMhABzSsADdYbKyegJ P9uN7PCHfCIUcfOlVDDrZyxdUuhluRQn8Pb3woQphRRZabbWlhE9bcpw0FJc9D0CRPmVq3V8 dykZYv0eoPSuoraEepwlxacUf38Y1fVV1pY8q2XzN0dv9CkZ93j7uOOHsGFkTzXWem7CqN7+ E6QsK3MaTHWfGUjcIVPY9vLPHwIj9FMYNwdje1yW3Df+c2VVeiIMq+4F3v/gJmdvdl0aVwxY 2UCJpYLLs3Kjp87Ejeg6h9TSxJFzTE1IZBo3NH8PVrKeVFJxVkhAPzFXiIseiMVKWLxhwsL9 9CAPUC30DCXpTAgKUAgfH0lK0TvkPat6CcoKRyt+041tEYqfZXHI6fxohw3zkRmcUOumG5bg pqQ5LC/Q1J+72tIWK0BOQqppf7xw8NF9MqtPPi7mOXH+we2UrhUANgCwIgniV6Y25jBu6Mse 5chQvyudd9nR9cSa/PZJdoVMmTfsz6XK49NycD2m5l5Kpx3MxcO+jAS9AcDiAuCEi6zgwG1A 0IG8ZPdVHbbt64KVedKhgzwh6gGzsaEL3lAIlcFbCrMP6yijsqVTLT6mmgy9Z+QwM3kjb7e0 L2ZZpyZCXsO98+ty/gMMvMJJQspAZfTK9tkn2T3VF7us28vGIEQvmhPjZsRQ9pFCQICxD1PO 5ED9EVLdoEkA7BreCFMVnLH89FSu7h6nx5hcnae66tYTXbZev/tn15VacJzl+kgJgSeeFcBI CiMeCIny6Cfwa7UVTZWqA+EpjCqAfDx9b6fp+ctTnJO84X7BR9khxI4WTRM7rbVEA3HMdBVw 507K8yDp9YXklgvzO8eC3Vmzpfyg7t16ba+UGOWmLxysdwxoDuyhR4KY8m5MfRaaGWI+ayKM TiBaCne///k7xcvQwi8ldFmezz2bNLxUsaIisqCB7+XlOrxS3sf2Cp9UPgo7O2cARo5rmi4e 3WZuFqOh037sVuQoTNsolmEfJuIiTUFnE1U9E1tq/MKFglfHWJ+gu4gNlqDSgiffsW5WDh1g MAGlbXCmb/Jg3JBlQwwsbNpGq4qog14G+FBsEunPN19bvgnYfxIfU+2xpaVean03PrZQjM5T L3perYqIWah7pxD/fqePplo2XuVa6jKrn9XpWD6tGI06NL6NsKVLPXP4o4czIPiGvz0jsXa8 O665TKFKW4v98D6PnpR/XxTHMYnHL7mNG3Rx/r3fa8MKHS59uQpDOLoi0yRBmFfKLAkxHVbj Ay6tHCkA25BXzLqQifI9fvqWmAZeto/BtLH3nfNGku0+q0oZGP7wlJf9ou/vrNPqaadjavuV pXm17MSMkx+zzbKZnOxw5JFCXe/TIBaoRiXOHFf+3DpRDOWv04J6UjbKz4xONG5L+0ABCLJ8 Tu2hK4QqLCTwknPe9WV+lMZ0zPbdv92YvjZ6tppnRcFzBGIvl+cVGv2cwbjjUnfCY5JQRHoz jgvrSDYtkKSyNV+uHFIskJ/1jJLzmOh9sqwo7/sb92OcJAwX7hNQ3dsfrB0xWQvFNmBjKbOF z0ph+k12mA26yHmkr2armsYWT0R0ponzTAJXPc82eDCayFX7/Yp/ME43hRWqnJ/8Vily/VOF Z2Cu4ebCep9AxR++6qx1U7/fmnu+pjeCj7RuVM5YfdfN1h8gpHWuB7amq9DSdxizAer7ZOMv G3P7n17pDaiZIBakSjJacwSnvCtrRs1uKaKqql1KTkZ112gmqt8rF8iUxTfcN7YfEm20EEY4 /zW/Q/1TwqMk5P6Vc8v+fyJ4qH+8+P9K6v7Os/5vpA71X3Prf5DEf6Ht/5q5+NtYEiHxz9Qy GoH6Z/ZBCoFC/8X9Zf6S28n+T+Qsoh38570Rf83tNCMN/8Ht1rSdkihx2LBg1f937q5bQkKS njXoJz01MYgln571k6Fw5KvGDNLSx6dzzf6wXfZHNdOLRAeUN3DIMEEH+kIfliuzs8SDUCUx fNz8WcM4bg8edQchJvx5hlVHcbtafTw4eCvb+rW92Kp3jCUH7DM3/I5YWbxu1CFp7pFkW7c3 mEWSCbLjJKq5zCS5Zu0U45BCGc2X5UDGTT3RYopKC/KZyzcDzrqi89yrsGpiEc5w1vFeyP7S bFBjQQxojnx4weXMMJVMmTi+N+javTSK2H3wYKC81oSmt7m0jCNPCpbfDYc05m4j8d7Xq6X4 vowmuEKi5bo8Hus0eYJPnSbQ38IjfFmaplGOu2qQUv+amoOxNw2vhQR6JSHjl+vfU5F9nXCh rUwF8GsJOs3+cuLaVABOuTCbkRQAH0UnD89myeGd0uYEIZFBV79xXjWaDDgtU4rn3IQfKZkt NNbLQqiS4O1fKEk4Bgcykf+9KTsiDO8FRRYkDqk5PCcVIBdampWobZh/0DA0PVtErijOhqoR Gu1ta1AxmBX6/fbwgJemXDN4dVg8RUFYEBbdMVpsjOxn+Q7hjlhHvW4plRIUrM/tHR88oHl6 onghpZkG0s8y/dTBYCIkl/onVZFJjiSa/tGVcNYnpOFE+MA6hMSHSGi0dUVzztUysVIvnenl 5BmgYirsgDRdraJDd3/0eBFasu3roNylMWcWjbVjEamoz+9QoMiaL3Hj+Fg1NHgE4SRVijfG fOL1Fi0sJH0JxggmkgjgeOK57DE8Cb25BEGKUiYCT8I3r2/pVIHFu/IwbF18E8zp8LPixtj2 KdGUr5j4LTlBOgOTCofxp/sz3LyM6oM9gLPvitbvfCWSuaE11/YylXefuk1ntsu8KRNV/H1r rD2dOI64xctllMJ9SRr6OfiV+BRnt+1IbMkz0pt6koewX9ORGO9fIIcpMpluXZ4xuu7TS0oB isSmaRnPL/VXcHBn016Vt3StDKfkTJ1E+9/MB4bErH4nvcE067LuGJJ1IxSOOKKD7q0eH4pN DE9htu1QnZrbXSaw5DEiEx/CthbuoySCC/LJ118BtdLQxPkbafMl1T9KyU/HWUczfhkFOyW9 +0ClqSyk1LKqKIM/C11nobN+r8EXLAOSXu18KgEW9zNlo4E7Ww0rwoX8QkHdZfaJiGCaaB3n 5ZsoZzCiB8Up7pxOozquYl+2YQDMgHdfOJpuKLLxnBGqVcCs4JIHrFFpVge5w4wwR6CCv+Ht G6xgJ4jDynwMNf0R4MlzuLatJKf/fBzLZRj1Oh5F3DQTOmD5mAFRaBTVDON4HRrhOEIngDcK ZAC4T0CcsB/w6kusb5DOWHAg8UP7gVe5V8XUsNmvMLAm+43Sa8oUYonbvNcpbZXIiGFsrmFl swCpjHXUMFKC9OSoOjswqn06FwER34Flf/1eb0+MlGyCFGPcboNJkqgc+rNvjNFcQ23Ci33V vhE/0fye2DOM9j1ULCnKSOJPxSoI1IcY4dYP2hJZsm3EPjC3F9uJUlh/kpwGl4zO5jRbGB89 IRCrMANyCPi69uR+NAMJUVR92gXeGH9+Jw65Xj5l89TiU6H0q8VlbC9Nh2TFTSG6Cl/zUeIr o+RjBAMo9DkDCgBq4QvMaPJTo42UvdcD5olB4s4+eblZkEU2VIfTsOjlXetoeMQyIljO40VM QbHvJgbB8z6CeLvKgEqEavyArv1rhaBAjvyBXIHHz0QQBEPfZ6zYn59vsOsAYUzRppa9PgJ5 nCgzoXzT0WSWebp4zlNcw9zyW30w6pwTiMvrJ/JWxhfSVfGkxdAUB2L326wbnAXYLDzPGTw9 +AlUjm+iDk78PHYiiZ8jGFVk/Wwckv38nTPKumvZ79RKWfB8VmKzsIFgDyoS6s4mm951Lihv oK1azAabzEpvuNXdDIuVzllcsnGyF2V+jghYW4QXe27XvO9FgsC9XFlLjpE10Xa70P0KIgzD HtjtMTEQJe80626vXAHSlZ1HzlmYLvk4Is1LRVntgyDKFStxjOBU2bK0iHe0eWp85rpRRIUm qQ63YQNiZhNLFCH57Ace3up2NZLfq2cjbHVbNmLfLLBHTLrgZI+MNdCD+6pLu5QgT873Chre lZW1X4owCyHr5fl0fZpuNsfH4aTIi8mRz1+gV20tGvdI9WzyIx6+e/OJ5kgX+ylM0fNygqxE 7oQtumwAce+pSIfjFYycO72VQejs3Sssl5ZRk279aFlBYihk71U0J2JFcKWw1p24NQrD7Lwm Q0dMKo6W0JoSvVRqPxYfjx7Odd5YeiXjiZcgtrnHX0s92Y0Bt0DOp92duKY8zgz6WBaDiScf bZ0pYwy8Z4pLcqKzyj6H6y0YBsb0M6FfjmZRwLSJXyKrK5myijWlXrQamsW5uDtQXaz5pYSJ yzELPPIvjwx2wok7sMszPHf+TGXd5psyc2YMbq4QX8yT4lexidduGXRdaI9gPmA19pYMoJoE QlblhJVZuEd6RaHr++vFDtGC/qKGspq/2ShZvmW+j0QGnw8US3LZu1ena41gxvIKqu8mg2oc v/pniGQcdJmQd5LJtV/4yrZfRwLvbewXbmzYfXeg+sK6rqg2yf3jBzFvUFUOzciPp2VnU1OG WN5A72p42i4LIPQuNC5S0HDRsiM13g96QX+XzyR4JtfZKj2S9aGtea4DceTYkis0Nc+r9PeN 8ifQRccnir6MzzO8XXUVfM8X1kTmSwYpu560pt6+BOfqBxqC+bwrQJKf+1dyDkVt6nJJokEQ tvCD6PdVRp+JgnjwkdFmquv8Ddx7dO83O29ZqUwdyPPahJIHYypNEXHmdSsKJeZcnDs2V9q2 VZ/HaE3zs13knnBlUdTVvV3fz95Y/W1W+YZbv2CC/2u91iZNJHRZ5DbLj5PrxJ+WAkAY5sO1 Le2tz2ZNnDu5rwOkU7P578yRgQ73Bx4+D02SAK3sXs6v2Q3/8Nh+wCOfm4BeyRt+cv/Y8OZo qLPM8U2UdOoza13pg7KImjLrcT48b9TVjwnX8S3ghHhi3HHvzz7fX2TSvEnIJVKijBSSCeFd fsoTaLf1VA3LSbm3tGOWAtGqhv2JPWLaWDCIuDo0cAq25FYFQBiaF6+rTHt6c8V4YfbuYJch CTncgl9gPgw2vVkwbS4UGdc61eaLsyxUtQbQpUOR6BmYDEOlB/LWOJEv7VIgwb3D+Aeq4x+W QuLH/Bf83zicoH7BhxeOXUdityCaj+S8+xMpCnGn9TD4Qpxm/08uKihysClVqFk1/0XTOdH0 lXQ6qLmBFYoNvUi7SFIDppLcgNeiKjf1DTWf0UQXT6Tt4RzdoNQC7ZqLtGd91OlCSYZTRN5c 7sPrIKjjquYAvXhlr4AdHdaDAUvKkPgaWvbUcSYYCN8+S6IT6VX53lcGpbah33vOlLzPdO4F aRZptvf/aRRYQ/ENLhxELfSC6dwySZzugiDIauTGMuPNc04zb1TIKcEOn0F8oB5ipn5NP9ON N+LibP7IfPaeRQK5PDO7JfqVes+ELv0ja2kV6yEVguszvdEIC7hNy5iW4/weC7f3i6QByJ7t 65T8jymrEli+7UD5Mm4RSUD3oZj9YbT6K31mJjKeeX1u5gYhvArJX8uFf8oClIwc+l/i0v8L bcp/kHrEv7L6/6GsMUrm/ykAJP8yuSv5nyi5W5Rb7c7VvYON7Jj2Qr2508S48tNVGs023g8I aMNpULIlbxsr49EO5nImzmcI9wUq70Hl9YW9inYJlhSNGAB11pqBYDpE3Umua9Cs5f3EJ654 37Y6B2njfjIA+XCfcqlRDBk2NCLKGUUJBM6Fpc26KsZDpE7yuo716i0UXHVEC1nDQO/U5mwt P/LW5dmIhuEXywMOF368/v7x2dBe1U0RnYuvvD5e8BGJ00NJIsmJA81fmMYrXtLyM0/Cl7f+ WXTfXxs4MWVznk3btquktp4N4GZI6H73+QPgA9i9QHpAi3/BISXfDB7LoOr3Uwincj5vwTE4 E3RKJdFc+3203OhSAaGB0qXl0sJ3KNO0RnbW5eOMWDWXQMTxvssNekvxqBQnpm10CiXFILvY GJaJEeS3LRZfv7fn+O55NcowG0T86k+82pgAxb9wLJ6ujG/4juOElSHHS8cvdRela2CsiVv4 Bk2MAl5IdlYGws39Rk4gkWnpqNZJc68UkjKbgowBtEZUTIoKWDMVH9WswnWJCa5PEpNbzFmX fGaDN2UnVRJ3XjbcLz3pnOxrO5FPucacJTeyq8oAAfmtMiJ4a9fsTt2sTmbS7GECPZ9u+Gbi DPm7d9SxB/m2PxbFVbwQOG/NIAUlYx6dx0OyFNRRQjOeBo/7lszJ6LRahAxuK12s8eIcu33C iJ0saa2Z42iO6uMkS/JVmEvM1dWoVdPfmMm7dKw58DuQI7zZyjlLNX+/tsITF8YwL5vG7F68 Oix1H1aNi9qzfND5xaNT9VPm+lQDklHo/dr9Z8P5kKL6w5LJ1KqNznHi1Mr7YpNw5zzpOcKO nDV9o+p9kvfNHoaubjnur6SLyvvbGY67j8939yYRXbI+RbvJXPJvcWiS+luG5M5fwyo8mIJc SImJ2jkhZTfVP8nTB/bLUL44AC2Amhs5omsWbjh1e/04lI4807H3Zv7C+UQsQUrg53chnisQ QEWra3mX7vblhwrb0udrdxSBtPPXiwb7tIrLQZlwj7OwK+MCDxvPD50npo3cbfGEMh/1prsh cWucdZ6IM3nStYoISPJLOJcOMUZyIN6niMj0kfhEIDAt/o/s5dcRaq+RAG7nS/ptxtvFxaJF iHxm/SYH4+pqabbu7UMD1GlETDyTiAASUhLMGl1rWKwiJU5eonyPuKkaSYP6fa0VfCvsbJwv zvAcWiJoGMdbSi+ulqibQCRniTthJszGsAMKNU3gRffEgd2OHPKDqDp9ZnZEJQtWvhya7oJW 0XxBs7F6OwzTc6GO8GJnB0qC00ssgNO9bFzzfFTNIfTRRM56iG50OnUWHHjW3xGd/hGSblky OCBK47gtmKKaKD8AjqWHZWXBEpW1BDVXoJumMXHFMxL95FYcTsjgR5HjTTg5UdaS/hhD8thP 6ghHGNtPPAVxjASuqZd5TjUymz+vW5nGArgtGHXbN9KDtNuwQassPWHamKS2f5gCYRj4SDsD 1H05/nCCbdJiypGih/DUp6f8JItMHw7KVRPc7vcPr7lwq72+D3ELJy2mHT+g615BlY/Lx2Wc eBjSWmHdedRLqHv5eiKc6CoiEFnGa6aGuXl8G+6ymZUfRJW0PglUcGXCTPLZERoxtkkPXnnQ 6kOn4tcOc8+kdSqac+ALaV7E+dQuRAsKzeaWR7oOqJuZ53d44+7oZ3B3S55CEgauR7B5K0NP A56iCynklOxjdfPhZh+H88e4uVcqYenfMSYeQXzlIq8T6XKLsMgodv2m4FLPbYbx5f7G1TYy 3fI9MZLsQO80mm79+sCam2n4HbbWVV3QKKc6txv/IUFNIUnrHYPsejh7lFSoOg+rgsVg74RN 2D2M1KAZEAth76LlwvWzLHL7fiobKw8ei5oU01E63IgtJbTnLy3nPPQc3xIK4RHCZrDcfsoh vGIweoJcQhoyIoikGjPYl56R1Xty9C0rMephtMdIiXSOyI2CPTTUEuGVOZ5FVhvlZbir5YNJ IjGeEh5JNklURyLzrNni9Sld23TgqVVPTkSEzMfpsfvassFQ0qimHsGfxdyvsxNJa8ZJIv6N fyb2S9DN5hoBWJp6kqLJ6d73yX4scXpclXtlqsMtPix/t1q9/e38OsupdnO2MiVNDYHkx11T kcTX2qgvo2qBW6tsK2nNH3lEwiB7gmanVokBBnd0mR+OsX97e+9K9s51Y0R0JRC2xApeL9jP 93dH9Jzfkd7QdT+lsZTuqLsekU6ySM6tzu7tJ3zBkP9IbSGu5W2XEO+qDAMRN6RGh7btx/gr P8EPB8Cqy+jZupUTFlkW+xPVswU/M3QIqpcLNK6XxCHWWCVz8mu7I/hA3xLpRhH+g/57V+5P 0I6R5aKk77/1zpvW6YA7+YeqFrYzJnCeR1bencC7W1bCQwofSJdin18sl7B8f6LHvtG82zC8 hnU8Qww8CYYlTgizhh8c/+Do4FNMY2jf8FgqeKla/tcJUMl/JkAl5GT+JQGKkvvvMhpJ5P80 pfkPsRjJv0iTSqL/ksVI/WdIY6L/lsbkjNhUI48aVs/Q0YySl4JDXCysRJ6RiTCt8FpyFu/q yNAxDKubyJWvIhB5EFz+54hXAS3U9k7UaQtqPKzJOP8wxLhHJXPfqTE2W8yABJTiYibRMWUu x6zlGLD0B4gblw4ZRF7j+0CybHco8oi7Rp0RfAWXrk6TUQIIBrwG1wkZxU/1/n1kC942lXYi F4/DGjzW9zdFG/+42Toc1VCHF1rCSL/Cao6j8TUCez9jABHbMikULK+BMYDQcThEIBEn3TJ6 8EaGdPJCiKEhwSY3QRHCFMjUqR/E8aPP/1BehpyLR/VMLV1yPKtcOc2RuVnLZh8hOh5veQSp W+rlUub+G0UBlBZO1dm7E+jVBOH2LMNRZYXZbS2HCNHh0+WHfLDA4BJBmHHpjrAO9bp9ehNV NMO3ycY2/BGsrH9GShtV8Fq4vuXCMY1MLGuIO76sJUIeFvTzGWaijW2zp7lBCjKAmxJJQgFJ cmclk/vA7zVH2grfy4hk8Wwz42iO3uSYSzz4wmXqvZ6PTKHLWqiiamtrYVLSqpfh5Lv7HMOP x+bHaUCyfG6Y6kmZkQq9G2d3wU6hLZU9BLjgB5KQUfaH2maZsbj0pXcFn5xsenP3qWCeZ0Oe hvR2MT04cmBUGhnk7i3uRAB4UArPrUgb9NG41okNlD77g4M3S4fe5pY/8kKMFHZBqVJvkmXB MAjIkjMeDKjtYtg4hXHtDHmzPfRpDmTPRo1w6z4xXbyqq6UeksPxP9J58rOv4BVsfuqpHQPd jrz7xKM0vqkOl0aZ6SS1VFUjrQFlf2OW9od1xid6f/gezruw+6/eE9hpthOFs+wUj+YzzEkr Z5p/lnHX8awkrg+1iysJTdTMdvpOceNt+zGTT2eJ6KOvelxB2ZKP59rebRnNP1faYN1ZyjKS A+mZ/Y4dt9FUtkWVVdy7vZ/rO+Lw5vkzk5vx3LXS8kEXDZZxV/J0hp+28+cQYqRiV4/OO+Qc IXuKYz9IPr0Oynqs+KXn6fRwfBOt5Ie+H0nqs20bRK57/r6Uth87RHOVB4nrh7SjOT8iPfe5 vGW9lqf3OYBP8elZqEH7Ceah3nsF6eXo/uRLpjkrgF5kS+Rp9yprKUxF32jLpF8zhXqLpDJF mdtKcCmdVsP3rk2tltFQ6DcWp/kEuk2Fm1rvbUh796BWtqK64E2oHHYy3IH4iEcX304SQcBb qdxw0f0VL8+nMp7+oypRBMrDUxV+tHxfLSZNcKUGOM7q2FnvXT1RrdZ2Nr9c2+x5nqBSK9m/ aLJif4fSqnlwSBT0riDPgyLBWMh9d8pC+72c0IJotBU5EY1CnYX2ebMIfTPTgnBVTCACLjJQ yJYTE4gXrrZoD0lbYqTZtp2pkR8ZuIYyesbZnR+HZe8csFh0FXgJejxWaxn/Y+GS1P6IN3ZU bXbM1kSCR7N5szlirSx3Y83h2JO/H21F7ajAp24kyKo6FJWw69mf6ONToIbJn7RafpcGlSuV VO1hKC+/k2OUTFB3H5N30t30aFGSJoR+5F+xcXgyjYhMg//1QiD17wW4MrL/Epf8P2ch+As/ S/Iv/SxJ2f88crb+b7VK+N2meMNVRzlG6CY1JzDYEcGEr7wI0413k8kdrcgMGy5uF4FT689z l4APXCWNNHEmefhtD1l2IdKV58VJAKZknMqhKwUVqB+CC+wya6gLrBwZLLMy7K2P+pDMk1Hd wEXVDPcX7F6Cyzi1Lo+5hMo+lVaXG7ANxPqBjO8+gdNN8AUFxCwFzewHfy+63f63NSLs19QQ A8VQl5Y1M5GYdyuS6+afCpAPzx29OScFNdxeEFn/E7hvVdNSEeGQ3EJXYG7CCKnyaSEvhdg+ xjX2lvjyap7sSChhuKsH00H3ZvqQaEBcNNe/lks4XJ6lGSYSISSRIqLAhY3MdePDlC4lNgJJ wCPUdcJshovSxGme6TyRTf6ssTOWGGZc8spo2kv9pKhE0jkmDy5ek6x9WdxlQWkycUl5CBwx bvoLxeOtwrKlN1lQw1J86AgVf5XaKX6zzP1A6WyEXDVbFyVo6aaLInhxcCZv2Q9fpUSDt+WV Jh58Z0OKGHqzLNBhH+SJpmTo1yygSd3Thd699rMzaP3lZl0zz9ZjK3P5kAlXuXAz0tU6h/dp jcWCWrXDxOet/GgeQZ/2ZauGotdWoCeU9wOt24+Tg0vm4UEqcvdc6nA2jKRbAYvSd8/d1xjp Y+/bPI99w2Ln5eTksfYlpi/GOteO2lG+pLOOFQRdnUDMGU77Dovp/snz6rD+wT+QJqILBZoi Avi+ZpHb8kygknEXfRznGx+WRM/xFhkJcrAzY41HYF29gBN4tgUIAGOe4SdMpAn4vox2uOlz +Xg5aKedtgx+azg4PgVLMYzEh/04ShxoWL19aoDkCyjAjkxHSeCdhI3hHk758cj5rdCJFu++ pzPPan5MLynGvvMEvV7mzDq0/5CzVTWsq5i1NSpa2KL/euXn/CO4i1Q7eP+tGU58JqjIhybz rdFHi5HxjT63uTsNuZ7M5ZKSLsv2D8di13QJFo8nPj4RV3pf+a6UJW45U91sMbKrW/mT9SOq 7INvCfzNq3cX+DED909uUp1N/NLdOozjCKe3+W76R/VnoY/imd+mRp4dfll2eOb9xU6h7165 4NFNsnXljxkLoQl5P25WEU7WWY8enH5IhKO7sHeqQXb4AM5ys0qtzAgkiGgHWoZy1uRkkQIS e3OCDCdne0jKYRrEbS2m7QCzgASdA7qNXMBoPs13V72YDIqI6cD6D++FZOABTwpynAOMAwvV qZ5z5xljdDeSrMwoqs05zZd2U6JFFbrX2V5wOW+XCUmBERF8MSHXRn2R3aTN/TJx9rNs7wVc TDfiFdumMaw2SAfIDtGkxkULCyv6HrTeXj5O88yEmOhP+YKexZ2tm9jSpUOpV+EaWFPzaHsE bE8ALd169qgg2FG2ElqoZhw8FxVZlUY8qtTuos9IrJrj9unlQFlI/jRFpK4sRaG0hv/eAhvr TQ/SR9bq3Snwvtw/dZOpLIPsLwF6hUdJmVx6dEvLlFQtjFhE91sUgJecuoYiS7lcWpvphK2v Ws9j/EpOw/UCvo3xTbOPqKcf8ZHfznoEVHP0EWpS4yxP84PgHL20uPLpokP9cjcMS5/PLW9C TTew1MnSxYy8GoZCFCk0I2YaS8vw3TQEuRgsTncdN2fTF54+F+LGnPBO4JM7AuZCbtK2Tnhv oyiVP/Sev6DJuckm7LfrUewrE1rjrcwDDySPAAtDsa0vTWDA7UbwAVy+Jk+o1FF0PJiZ872l bkYQK6aB5xlZfnwQ9FiLB7O0W9I/SCCfyc0K1CaYfW9Q6WkplcBMkok6xbcNO95xler+JL2X RL3oGCRjv8HMvlRi9ElCmLelg874/f7NaJFr71kIH85/kMZ12CV3lwDnfnLvznBdTatWZZB+ Hhsz1t41gGD6VrzJereuVsz4aPjnAI/3dlINPWmNhDf3cqO//Z6E5iI1r2qHrnO6NQq7r2fS J+A+tdElpzMmGtxDN52PN8WGJ7xTrAo+0m0MY+b22+1ZomHoWrChue8pqp7tbG5Pl5jJTX6u o7qHuZdX4YYytGNJm9WM4nwwlEbcW0SWk8EhfAhq8vt1JvZuAldU++LuZJjjQNyv+MbOq74h 8scZugZEbEfExLW2BY4/FRIY5d3MvU56m8zCE2d/kAR2jH53qovqajbnGcx9xb4t4mSBuq0+ lAdrcMoy/7Ho8j3y+gW7C44euCnMoLs9s7kg2TXpU03trJ4OZsnRHjneicJ/VeFrZaMS6unn zX65KwVaX2XG9prp1sNr6N332RMdNDwG3GU13kvqYJ8ymMmDdEsVuW9MuwdJ0ro3TVWjLfmO Kn2aY3qZZjHOe5dd2iDTSpBrTlSeACJ216cYSxT9rI0IAbamLtOC97JM8BTh0vdKZHKupwFM DlVBAdTP+K7eRzN5oHOO6Sa5X9v7Gwk/rISMDr7O92gP9YWEy3WRGSc375cHQyIXStBE2+xa 3/SFGJ5TRAultIsmxHCXCysIFl0kSxrJzw4LCMZhDZSinAc1hN4z5npDKkNe54Gk/ccNruge Jo0Kv2wpPWS47PqjfUTkYWtl+oj9R/3lab9nsSqnI9VyLyaJ/Jehiflk8EPVsoULmPIHM720 9y3RavJQ4rehGk1jhAr18q3ZeusARMBcKFhgV/FX19BLT7DcC1nTY92mozwVpmzzeZ3UAG++ KNje+eGT+9WFO4opsxfnf/gE+2ZfyceGPX6Vwz2oP/ArZHLqcdOnuxFWT1pDjghf1uNiTpFG Mq8dKS0ZimV0cxzOQ95y+Cm6edpw3B64vke47iErlLCboy/yPd3zqmiye6rzpk5j/4CWv2jk 1O+NVapafEBcfKSz8NjOVur2r3nqL7/eMv9467CrxPku6rTuiXP4ULBvIUK2KfWmyv1ymIOp SOx076nkno8p5+wYbz8h5stw9FtouareJ/NhhtFRTS86XVcKB56MtzXayfOeusXRYP06vhlV wq42yc3SKJH6A/FT5IutQbXj39VJKa6JxbJelZsu9jKUTHgSuuYdXzchvOYm30dfDp51w3X7 vfUGGOSExq8bQ1asDEzT9XBEk2r5k0c0UNgXA4lUlXrdZdzW1NYNSQ+KX/FWuvG8UWzkuyqr EVePEZqWPa2UJSW6dgE3feRaI/2T1KT5kJbTAhugIKAfWDi8FeAYN+AsnqpDYohTjILbOeVv uoTHl1JE8dyF+j0F98d3aiptUtZUezV1jrVrp3Z+qO3VIYTwRFlGHE5LUM2+dj4z0HlPPcOi mbTdXzvrmoq0UqMY00x8iaOTHQh3wgONo2S5p1Vcvcq1Qf5Nyeb8Gk+BRE+9indTyetwRLsZ x6XvJjICoBzT5ClLNfQgCMqijMbdAGXhrczkX3k5ED/cnDZCmjOi+5K5OXEwoLSuOeOLG2FI uFz6oP1M7Q6TivrL8yrm9F4ZagnWunaH/iTW9MpRiRdsBgmsRiJfDHPHSX+xG+l/g7Ry9FUi EH9N1P/Fg5L4V6Iu/b+JqIurSyMk5f7HWftfmFDovzSh0Kj/DOkb6b+nbwrRzghWvG+LnGiN wo1X/c4XefBBT9NcCvB/oeYWdYDa5D9XVOYPO1hB3nJldqZ4kCwzutQUyQZVbx9f6jPjLUik wCVajW+Yo/OS+eSPH/zbNgK9KshoqDxYgD6Is/wDy/q8kGHet/FdB8ktIEiyengHI89KxQUg b1ryUyi8aFYmanNEZ/ddLilHbLvF5bqeWj5MaDuQFh7ZzJHB+2517bzST4pfxgteY+QITq0h tVAA5dOKFAB4B4SvgW8zAAEd0+iqBtbETwLalA8+J0aaLM+VEI9ZXsdRZ6zSQYWE4xteYltw 5ylOhEE0ED4u/axvOnRa5u0WdyTJqwai1XNtLNMoI0+DwLocdCviIxiS7mz7HdTTKt/PJ4we X+KHXe/KJEfX8nwcEmNau4Bk+Pce11LMZcjrn1liEPEq/ni43KRXaKPcOfpQBoYPHZKLnbJM jCyuyTjL5/WehbXObQDeVCLiJeX0cFcHjtUV2kXqmXMCokZmqH16ZQtBD4U1NtJhbQ/Ttrt2 vjHv1r3W2CrNPsvZ4xx6IfOWZvSBINzfvaHPv8zMl0KytTyXv0w8MTDLhibpzh+ObQTWOLRA pVY/o7TuWkvvvLa8rdP3MXx1ocjx1Vp2fcl9y+cf7j+0CzleZbzN8BR65869dvI4UA7GJZ4n x+eZ79ILIjtvB3rocexG+6/61BXZFLVH24sw6kcW9FxAEE4zBMZKJoCeTCirt3ScKxGhEUhX qqfg+lkR9tNbSJrz796QQiEc7Bn0VutF77FIZJtDjWoGqGfAmM2Js/J1Gg9nqZbjrsPYhjuo pz40Tpywjp9ekqcFp+mFyzt2+nU6+nPymbJTYtsn+u6qDXhxuLc6JHCvZrsLZCpxc3775Z3R FBAn9HMiEtPBLDVlac18l26RP7q1BxOyA0GxJUGxGdqdDMkt13sMdTTt7aA4OSa3FyUiqIOx ZWmxiSwg8Yu4iQqzJ1KO1vd91Zk5I5O2E4hLVBFyKsZNcRS9mzFo6VJwRDic8ukVN/lP/9YW vr4W20LGnj8eD1woCBF6CyauxW+6vR65ifquz/FjA9I4QJnbtMRkwHodKd7zG2QY9dQkQC1C Xzax84WQ9bOg9ajUYVQssMM3Xfhadq9crmBLSRWrdYvCYQYUB1AKX98vM9FvJ3/boUmLlXUi F//ws1fgQWxvMza2IuJzXi+HNVszexBfWuYAgOYHsU4lCDPgLAK3hozVIiTHr2bQZLIeeOFI D9L97gJ4O7X2iqnngJXc8yq2igVJKa/1iDiRCE+7Nea7bnzx0e3PK3eIX7nyiSaqaSbQqWuu 0PsXz7+RMDO+wzFX4BMDYWnKvYbQ66xwOds+HwEd2XPLVWWRP5XKl2n31nSgAnO2SYDSJo0B JVueLuBttuLVIJi/271tBKOwwB/MuZkiPJc0TvIaxaPv8WOOMxduouSiHEv5Hzk9PZ3GPy99 5puBmF7ejZwg70G92x4EkS7caiWfBLg63MvIbA6UGKjiqco6FOsXYBsJ1JLWUiwqVM0Im3qZ iTYvXykMOgiZDvuo6PzzD1OUi7vEMr0y5eaX0szXedGBNCoriqXJRN19LEMqjuMeqSi+61HZ HU9Xmx8KgcebQupRmAvW8wKli65CVtQTcZjWGPSTlPrbKw6fPuaXUM5sfilkFGt0wBCQGMyY TSurov1SGcIvW1riNCLK29ZBhVz/8vRyi3iqWEppeLzPvM2XKbHJAUZQpjU5W2MZJUIAlek4 SXiwRin+DpD4azmuzN7QwyJdWYcP5KXkITkZ686aWhNGNy6ZctPDuEyvtrPbq1RMtEPVcrKR QhbhF7EZ/moaA0BOMsNx5kT2ikbilyIkRBmBJjU2OtWPBgQAL0i9arQFe2bHzbMLbIhfD6kf kLzPsuHAiSRnxvaMjtHZYMCi9P6QnNG5IVZVw8nxt1Qy/jJclEYBenKiHgF1+ehWRwMshVKH 9MGIVFSPi5Ho4nONqIXlH04eydd3n5yZogQtTyoZR8CI7g3faVLtyibj1z2twmS1ItzRlD2Q wjbOuLSKopiqwK+Wc5upGz+Rg5VXp07j0ZQb8tSJw49E+4WHwAAI+oVZ3akdMI2FZZcZv/iF fGhGKciR97dKCwfzgGwSbGvVty1gUjc36zHP9FH5QEvZbc7rMuhmpUGSRLvOqMg98S222vQg brGhl14ISS7QhKYDuVXd8SvJvfHpCkM595HibBrAwZ51kKGn+q+a4vtHrGXNgcTNGw1DrSct Ipd95SiaKa0XEefERJIZ2YVtLzw9mFdWlrOTf3nzBTluUHbGGL5jH2BtvU/LFmxrJvl87tN7 VZugrZI/ieuQlzGWsTC2IFHMfsbE0CjEh48oIiRcQIVs4YfXhzJIRJLL1DWM4sbgfMCM342j WX9qFd8xxPdNuMVInFVi/oKda9Ld9V1XKNMbhHU/rvBmtyE4atuq+7KbSd3e1VOG3fW+Ad/9 /Zu/GwUyZ4t4P+oo0qtAIkeHxfPvOWVeoAJPOUYXFCS9jn6d3rt+vbliLUTiqxLQ7ujBmfDD livm4cDzIt/11Yv7jy+qkl75V56uyTrFB4jsv/463vexwS/epcHP6ixozJmdHidEVq6cnZNz H/LyKNj1kJltdtpP/ZmR+YT2ntODgOn62/KvfrHcIS8CzCFmlRlD5jizeVKkHo6qDWdaCFZ1 I8RSjFOnlr6qn9NKZnbd/JR9U0EQ3MOS9YPRkCUI9WlO93FgS69jFFGtHSze5LGh2Lqdfz71 QqYxzFPDIof9qyqXvxiZHI3fpriR9K/bPvn6jPM/mBvV/StITG4vLhh49J38inu9npg57/dr KPupBeXpHZaE8MVs9I+1rS9/yNAbPc6pfZhNfnxH4+CB3IyEztuZPjov/hm/F+dv2Wl/Nprp KpoHwdY2rsrbdjNz+9icaYtEZ0xfG3hz/fQ9ZTp0VEVUtSe7BlZFO0vHquvXdMmNtsQ2qm8R YRqI9mDro408iOnNMz512HOyS4AKxr/2RFX7Qtlz+Gbf+rrTrjtZk7qbFmm576Um/jL+UTwi Q1T1oFmE4t5RyCn2ILcxpmc6PDg2LYwqbVi8h2w60Ubkac+4Ajgt4gdvihUym0Kk4+soyXhT LXh82trbgdI/qjctHDnY9T5WJezAfjBWH9m3/gWZYpo2mC5uBhGCD5+9h3lnjdWVW8Qlgs5G fzRNb+AEqaLVYIYfKCu0KFzF4U3LY963qHRnw9KG0yrK4CJqlGen8NMiyunntMi9Mvya61Ci dVXuXEPT5Jb2lMiX7Lrf6scknnyVR+57XmLjqVrIUd+FWd+1M0HZzF5Map+mWxqRn4Qxj2Y3 GpcmBeoNRqqI7dZAYwpxzuiO5HbQxCOxY89V90HuaRJ02QdmqL+0aAiI8JxlwPTmQFpaQPvc GVAK1C8au51FpgJGYC534ALl7ZBi6xeqPAmepVrd/YrOX6DlIgokDxSJMPzbOJX+wIfAXFi8 taBOlER5J8YpRjYpUCeWSGh9SRUxKxs9AjwBLmztU01TpOHEXvf6xww7Yo2BKfzLOuW7imX9 H7mHZTYLBbFvtLqXNLgzLrnqREg6YNjBy3UczMuTorxLZvsrd0zhVUClLI2YbKNSc19Gc/T4 vc2/LmJD//ueF1kpmX+JI//PFBDov/B/0X/p/6Kl/vOk/V//c4vyX6T9vWWYJ3ZRrF/UueXo WPTdJOvRvQjBGf3BTOYsnDuyAH+1/C7I2BnOPsGPxUQrcdWxTeJo06dVEcXH0F1l+6hBxLKJ tvpl2Cy3mnS+3gIl9as0P7j33idAevlKl+KHemoj90GYRM/KeRlx7hZ9ADNlHOBx8EekHnfa wKyxVkEaWrCxG7cC8RFYlxc40cT8BB7IbqPwR9N7cvJJrInniMgmz7wGA2NTJjLyUEIuzoNO 5Qe/XoEjOjna/k+hoRetJKSShOiVqBOTjSbBNykkvpdOvR6DgAlMrm9je1rqWHEE+TpmkBbY uVbUs42jiriE4EU14lBGLFipVQu/LDHu1I/UEZBfGhYaTuT7XFNSy5MHSgduj1Xpgbdn2uoV jN8llMkO8rRTRxfKa8az5TPqBdVlZEgIeH4TiqFFsqJBnL0qLDyZjqtZ2KP7otSTkWWcdKSw vjZUcrTkl9/Dhpap2rXcArMKkBoF42m0HrfuvBRWFKDcDgjKh0PK4g+QA31lzaQYU01W3bng Y7ZoIHGuZzdva3ldZfnFfMebFS0bumzdPzU/apXuNb2UlkOWDu3EOxLV58jDRBUmMs7Yi5et YoFtJYMH3PFHL2eiXttZZH54eMtS7LUTsdpWVAsa36c5uiRvhv+sZHH5K1bZMPJuhdqEuyhT LSgyn4V59Zudh4gezYVZ6FoA3UeqOClWvuz5y26jGLXz5LserlMZPwTs3G2I2HaFXUQDVJet v8TaQczmr1yDbn7ME9UFZhu8DjQMkvtA3Eprqp6s+Smqs6YrXJqKkxT/SR7LtCSPT8lAT21d P4zEOCdHrK9BxCgSf8XQxxb/jAEgPtqeLMj2QUxSE2/AKi0uPxq7XoJiOTAXDAah4s0kDGyc 1c8Fq8fCa+Zxo3jYc5TXi+C5PFDPuIzv2itRSblymb0g6XW4MztYxbA8UEa22ZwO5VDg7cPm K9T7QLGjYX1t5rTezBGJj+bhmOiY+nzPVSA6s7LU3JC9EA4xZpkEDb9efr/26eYday328GPP lOq1Z/RNCyasesYjJVn0zlmaVkHO2E8zrU9oTO/09NPbQyAfynDSv1hrw/z8Yt82LWD62bj6 gTB2Ctni7ZFnr75FFkcMtfM8zYRQWrrq9wTknvmPF2Nt7PAzjW/b5+M4ILShp9Q80cC2GrZA InPt6dnaewL4mVq/+2TsxzLY35awYV8/vQvhXjfgcA5LTKwvF+NNBpqZSECuiaZ/YuU6ppBD WSKljnisjykJkPMeJqFm9kf9pyCibeAtV/KYAYCAOHz58nvkaG66ZMVRPOWVLqhq4nFeHMkz W2a9R743ieOkRZiW+lic4qxItb6oNDlpOt9yt2eORpkeJgXfMxWU5gPYu4izwLXs1fBNuC35 KKxyfqzDsEy+xTS7NouIA6xoDaAqA3SpZozzJ1/qVpOdc6TsiAz4zSIJ2L5gXs0mg1z3a5lb 10CtwdLdUTDdfuuPz5Jo1PeYuwx4OGL05iblq+gIaMw4k5EjuQLtYFjx1/YtEoK/7BU7A5lp w8++UEcZ7xClJ4GC7Jt0L72r2eWeMbPZjw/AfOPobdgySpkr7X3MOTEnRWfbHwzpgUJ8DyrJ kLPMHx/ckIw/m8gGJG5NKn8IjPN0wRlaf01mVxLx9oGQYszE0iUgPuQ8bNGhUvyJI07CVx+u 42RK7yZG6sZ+OvvDNCEbDQA78h9p2RZ0brsmVz97WvKaEXG2FKvDMwID1yPy8/0fOd01q/nU cLfx+kqFuEDZnnh8nmvOSQUW8Ey9QTtPNu0jGubvV18VOkUXHs40efg524dBtMj5jU/ihYr8 4N6arjT4yw16XYW40DOSMXpz4kREUcYHwRpJpNfkyG/o6PzEygLcaCYaUBfCxllbPKUCCEaW DWVooJeOwns6ZFRV+6+jgaXx+P5eBX5vmbymOdsKaoLhuXa2jMXuOv1RsbM5fLkgM8TPyC7n UXGE9O3pvQBf1TYyYbNJptk/kPS8fDYWxUUWpe33jhNaug2WU0mm3aLmHXgUGzZPaxhekiYU 9ZqBlYRqo+2ZGtuMb9GKNNMzazykJ3gEtyek3sm77fmuvFLEvWeQVNe57qh0XG3QfZJuNkmS ItEGRLC/MGbTdqr4ZWMi51JC2l+sEsXB+JLUiaHn64HJ7Ovf7fVjnAyYsZAkNf7C81WWUmMN Mc2DwA5R00ytoJnQkTQJlyVDOtKmJO8gcOBAqqJYPTcN7rIzgM/FkrllFr7QTPnS9WuCnMfL Ot3Up8+4eXzEOQet57bZ7TIqEbjO6iGe+Ns5oUDt1PS7QurxGxwSsAeDnD9v+Y9Yr3T07y+T ECUy9SkvQVzLZ0tXiFk23F0eVuTcIpqtOY63KTBOIxXxCR6QKpnxXol5ZjwsI/0k8k3tqkel ygk5tHPW93jFiMTneOnxi7PfeSv3FwP9wsjemO6efiywXjx4KNkpYwFY4zWMPQMTv2bJIuEs lIz2Z//af699aX1CBcuBq5m/zpPe8lGtDTi2fWWifMXp9UOrh0sVovzK3YyY2nYZH3zZM8uE xHSqjYUEO6hIxPmEfZYVH2+DdkqqgDl7kujXZzmkJYRVi/sZs1G2ZsU7Sw6pYUmsK0ete80L wgp84d4DVnfW7u/fGsAKGUM0HVhFd8cwWy/RXINbJFoLD5I/fyo0uXI4Uf7u/cslJbs0TzUl 60IwCfWAB+C11PfwrffLgGma1tWi9Y+u76ducQ2IQ1KxjxMsNG+1R610wvg1MKibECGa0K8c 2eq3JfYcPjY8OKPOX+giriS6dNfc/DWui/nyi/KDtOWzRLqpIXvWG85HHf1gknWBDkQ3J2m3 cepEUZhaSZdCz9lRK58sgnwjV5LNMKVzLnv456diNkAbMkz7RaXr7/KU72/vHo6l535Re/fj h4Usd2OghF8Iry+Ju8GjsqmoVQPcoj+wOdWw1oOdeDcGXIwjJ3oKts/4TmR4p7z0+1RTU2P7 jzL7H7tfAlMHfxJ6parPLmCjeDVLgTJ8OJX26OS6qSDDN/KFoC1k6/oe5FTlgaHlt4kCEFCk ndyCVKP/JTyMbNr8PTTr0jD+lfhaqN/2q2lPHhWaVC5nbb5Bd128VDTuikoVj8CAEasvfYvB vjVCUXUysd3FxQfqlNePossVSdPwWNwzksEKf9fjbcVaUaKcTfXpiJM8oV3/9UGofa+Uly6k EvXSIwd60inCLzBBpAzjyj8f2pMr8xSIOGsVdoQYHtRFxZwN/oR5rxPX1NWCC7dS02qng/n1 L6SHRqVdN9W0siDFZ1m7kKStQgoXVx4IiVqfNf9EBS1XMdTfURMzK4SopCAqBDfy6ERZkZD+ vARIUFPTSXlTAwXPoKXFkt3DP85spSm+qI2HgcXR/Jv4pH3LREw/ROgBJKBSYoxtmhdtRj15 rJI4Pu4oWMpDXr3PXDwoiC1iNWIQrAuDTE8fiAJ5/RRu1E0LNvsvJ96k9+rWhrR5UjuSwjpe E5Sk47uVDZTOSXACF4yQ82AgEHRuv3Te2GIFLyKtzz8GbT5qPgAB0UGHHN9Q8mdHliIg6R5K Jx6d3ZFeXLVKilM5XUPvY0GnutOzZN4o+KOoAt6t4OjzHX6E+7S+szs2EK0uQ89/wdcgYMKX tbnzRodmfNt4OqS+fz1wfOViTbzeRoxmgWdrPG7XSqxl/h73uM7FD/HYlpuDNWvAlE9R9MKt 5OK7VRIC3BIZs5s0F8Qty8ZkD2xHINpAbW8XUdQWnIwLFnEpcE8SI36pvnGxuUViIOb6HK12 Q2wOth74xUP3hqSaoGRMJqrVc7vVAZ1pIZM8JjNngqwdEyenQpHQS+8uyvDuyARlRNE+kbk0 k6O9IW+ClW1l2yEBPdl7xDdpPzkiMsUNt/X+jt35xrEn1iH0hh/TDtbIE+IqnnGqmamvmTk2 /4Vznq1ulPNBvdv57qoHfL5zgJxm2ku4R6kpRkYubUZTDt6MEajIVXaVhnIrgRF7Kl5rsNIE rvFNLdAiRZ0+MvUs1e8qfbzy0amujokURUXT6KZ6Qv8uKVVuXn0ulo7E2FMVu12m7lcJ1kDy 6j3XcDnljwqeXj8QEAKK+LDdzRy946gZf6KZtt8pNIeyIcBfVXa826QIyaqL2xe56SN8Uy9a uMJIvcWK3TGRzKD/Z2opCK4oSDX9HeGkj0j59eelQZ21aeekV7Q2EWZSvWONrgZI1+DKM6Cj hbhn+oN4a48TMLsoFmtIB5cYCj+5K+aOKbRcr1End7aIyj/oXQI3lAuOUmChQD1dlqhdG2UV V1DfshnpPUYNWqahOYMIH53e7x94eqT3uA1jBz/5hq8A0yRMX1qI7GI1A3d6MVEihrfNCu0p eF6PbRBtTt+s7tGMwVwkcaRPCUjSTY+jMhrTuWlcpejpAyxUIJ5l49jgyjhcrTltgGWMjuXA 8spgG29miYIvyk7qyvvu9WrSbR6gtHcwQFaS6CPfkH32V3SFiOIIhwT9b5fYwQ8uqE8LvPat 6Y6T+5Y5fEAGBVlaIURrs0MOscPAinP0tjGD0m29ObkGkM7wI/EcPacQx9DPnE7SrA6konfI x247LvGWshuFPHgy52QvWvdx2D1iriZtIfz5F7wNA5X8wAomqOS2uYM7v5RRSJ13SJlHu4jR 4EuvEwvpIEvrEHm+hWbtkJigkBs+6DKPFFLvL2IrDCPO0vnGC6ZR0gtpCytGIV84zUc8GExV v4y4LESi2l3cpL8b5/y+J8Mg/oTMBfrKjZHX1zztv2Hwof9ZiScpg/rXVpj/Syvx/qUZ5r/3 lPiP1+ih/6JGD/2XNXro/xQ9J2T/rVh7gYqHFa+B+ruT91/1nPDaN/5nzwmMDddCP1A+YLT+ dhOjr7SKCMQR9Uqzn1bTVQQjyQIZ6EvPoThBTJkQl+m061hIMkLrNvfE3hzJxJ04nyF8S5nJ WfGcuVYiBmAkG94nD8L0SVB2LA1fGaT1SqZoanFiWZhJRhs6d+AHIAcvejWt9W1za/ELsOyS CRpXsiJqMmtSwJNz+hnNkAh7ZoXhJI48kGH0GzqwTy7mHCJy8ZQTzx3RKwHltp9thJQVqO82 atl4MjQkWHO8FYUELguhSjf3WAYCIjxfKQdEmY40jmvav1PR6k7kTCAJxfEM+FPGLw/Wmnrm ksLBzkwDDqUq77RLgPjNEU4sSr5qK6Pzs5pf+DgOpIXwXuLR1PROG42Xp/lDJjLoAStIuZcl rkJfxHHx1qSjazQqqODLYGkg2o1Vt49pRro42CZaTj+ldOImn1ARre4rCX9lDelDbcNekEMB gKeFuN6OMvlUPkoOumWP4Ukedd+WnvAiRe7ON9nusujX0Rysz0su52ROtf4CKFf++Q/Zfn/6 S5JkphYNS+kx/sEKGjSsbc8jY/xTqgv1qXlK4Ln9B1FVNaFrkpAeog46EMm6MQOQSqhBuovw buXemkzRAdzSwOujnlFzopZo6Wfg9c/5fedfKtretM7L874+L+V4HIIgCWYelu5dqxtZ4GO7 e0tOj+0BoQfykK1HFHD7DdKNsNuJHEyXdxxyPCLWtAfvheJzODgzQPtpyonSoTtq3ssCoT5k g+a1nsMHVrCncNBzUX7NBcmn1tugu5V+hZ/CTh7HuuuQXtGB7n0pSj+KHNWcm9biIXWTsZ4c ZjNUnpTdPGImbVXzS/ADAGaV27hZUcRDopQJfaF7cIqy3FEUaQ9RJaraE78ZE199e+UOkNqG 29lfv65/WFpOkf8JKExBOPRTdHdvUVWH/cTrmQQua1xA5KREzwuWQWROx8/bb1O/iy5ybh9F thwtv9PVxnw0J8+20Wopi1iTS3HSHNgceHjyCjm8qHdnnM/w8clofNtzTzf6zpdA4h5bMhJc IiBXLIzC56SA+8g+8yDM84R+n0BKKLn9ysGLAryZOywHTGGjtYY/NEnDyV9xRD0Qd12gkpgv LzT3es+zq/r62bAOOSeWwQY5/b53WDdAuUSIc7r/Dwa3Ekp9EbkYjW42mip66NKerNjgLJdo jm3QXNutGGrTD6jd0mebcyYgHzXS3uwWqJUQAC8h2EsTOn3MNS5rSp3X26vCplzKOh2kd1dJ w13kLrczSibgOloT/AlWKCJ8v4UupvcrKRdnriSuUYhSI1uZY15VIUN9TaEuD0DtvGqaWWWM 6AnjpOWIKcoY0NcVjb5LnQ0si0FNKuuAn4lEAo3jmv0zB0J0VVxMzDlR7co6n6i5tq/iEgLC ksejCZAylsqU9E70OLkwsmKkPnvOWFZ33wPd7e2XI/Hbb/Qu3XuX5Zb0pAfcTLSgFl0FQaUE 6p/MzHsuui/zIHGFcszrg+5U1n1KvOctAI0Ob2iWqdEFOBsQ4etHngwrpZOOy6VBqfeUJ5aJ qmHSigPn9YySrERiWCaWZrBWcguizvbJiCila3L0Bcj9ZlDGqHvnhAc9ReTrz6DuNea+EWqY cvlTrpw0MAlYhbyH2WEQ7rkEvXoW7R1SVSBUhirzeJVuZu4600kuKyjkH2am4m1OwhBZs2Mh FBSFnMl8BvFy5qkfz+/QDkfN1+aR145EmSzQQW971ek0Tvd2mwkcDHl+Zg+niz+4cQjSEtFt a8523jU2w/hRLlOaqRP1mJDo351Uk0LvokfjmhKZqeX0gTt0MnLro7D4eHcoLx0aRJPIVKS8 CyvpbqAT/PLDmggBiyyuiCUpZAc46Qb3sC3Sno1aRPu7BZcYbyIHfdmYXw0CGZnkbHG5icME UZAwYpHHpGF0vyaAj7BeaB0xzBqp8AzC2fKM9p6D/6hNacRITYRd8b4B/cQtAudsybwlzQ0j 22lOwhvj2YzfGnUHkKeYwc+5V2LU1JpO3W1E7Fytac8yx5HiY9HgKTr8w6IZid6su3drx2Lv eurp+G4AZUDroxzwFY23jOAS3Cx3hOBnTB/xFNRU57fJadFngRebZ3zCg4t+Elx+S+XZvC2V nX2FIIhDuSQoe+OxxSssNBvYRNdFbkR+WNHOK4KIRRZqr3PcVN2hQ0aRqbJhqzG377nLxZmJ JPYWC4Vsx7O+fSDSeakEitSVjSy2AedMQnYSwuWHPQCx9p6jpPEslnvsch7UDlLhc/mO1ovh CsoJsCf3WhuaACgVv+fq6fM5ChZmHzQcEpSypNY/HN0E65UPo5F4ZxaedwmkDe1s/EtDP/Ru PMz3vLrqUmKJsztcEVv3nNgyVOV3PrJeFDxlE14puGU2XkBar3fltDxgcOddtkvt8KMPSeEv Qr1eJ3R9QuVxvpuxoGFFj4psn8pn9h8WFaiGwF9uKLrlPDI4ILpPmX6CHiyNYiVhhk/1T5R4 xwrS37TTENQGK5uHZeXKoMdMKff4icmrneD4/ZYF27ExYNPTeaE06vs0If0hTzaEB3TRN49I wXudZWu+1Y10Kt7Xir+Y1PVfknMIkjL+frouEpeOxWlwEUVwbP2uNRRc8hIgiuADIsppesua d7vnW1/5VqUh4abd5Z8dCqBN8z09LbgP25t6OHFJU6rw9BMUbpiXrogiT1Js+qYZSYTpm14m A/ISNGJVbGNJIdflzoBJawiuaBOs49SLG51eGEQurfeONhQG7LHgJFyn9XkrZZ+e50x+XOyb CpwgfkLFn7KSFZ4sNXvY2BDSwOWxXCMjarA4eCvmni6kWsXi05P8sDvc2z8bZ+0jX+UDuWW2 u6pyvhLD0Wdb786T+BrEA4y+Bx+O7sI7jC9LjCtf7DF5Sm/cPx1zS/lO77yA8U/fy/HvM0RM vLEevg7YQemfEqlUYL6Qr+5PPkBGM0iU8z0d0+QHICWxss/KZtFCwM1o03yAs5Q2/ImvtI2Q QKmrbmkNN+moWK16uchg6ezBF7/j0vKETnGDB5hNMVF/x0+pzgeAI5+q0QF//B7WWgGTC91Z t9Ak6o4HhkDcB8f9wZ75MVF7V4mjDdNtIHjHgmtTumH7aY1iORz4YXQSBx+9qs/Bny04+vdA JvzTXBVAuAoYoY8Kek7kQU+VNll78APGDSyZvoRuBTefU5Sl9Td9YoZPiDX7B8EoBqh9XGi0 NYhVwJyivcVxfSR4IfUtoYMj6Zu68jfrlEDOhE/2eK8TTWQUfA8KUj6AqKzjYE2KAiKDA5s5 ik3lEPzPcdJLijpfSe+jXZFOwhhOuBjzI6oLNj4OQUxORiuO1PZ3peQgU5aMHe01J0VUtlX4 U1wfHo2bNxWQr2NeqtRAa22BJFnDeGnBYZp2YVcP6sdM4pMwl1VY8ZJH2fI0l6O83h+sFZa6 KTFv7HfNi3chIqD2qlvM3XMslLEsRgTBgF7VgQ22VFHGlBHysV3z6XJoMtG0mqUhyZJmn/53 yuU+ic0RSM4gZFVB9wp6aNiJwFjC+gWKD4J1nnPR8MAyBAhHeTcuNHnUiFyBPqzdAYIAYbaL WxS8/hZGa4eQlBlfrpvHwRK+4pT1EZjZtqyJt8JVTKDZ9mXo+IpotfC++dxeyPyMnEgsYbUa snp8KGrc8WFi+pbxhqhP+SLGX9x/VchbaU40iifjtx01y6IkxRPRAQku8NolswTklljg9EoQ N1JU/nPgCmoO1mwExwV+QAkpiBm/p0ZdovabkR7AD/sFkvW84tBDqTm2/5am+feiRTm5f2mk jJb+36Zp/j8YkH9RwSj1lxWMUv+J2mhM/M2AnCAj2UNGeXGy6GyqgPfmMRLZEKFZ9/J4ezmm iV1UNUjJT44OTOnMLVg46wuHH5AJTeAG7V5Zg5sk4oe9uDKgg30SIcA/xY3XoH8dMFNLH9Qd WZY+cfErscamLH2DaNiFayCb5yKPkZY08yDF3yqKXLZQTcRdlSVP3dBV6nAcp/RodY+gzJ3V D3QM08TocaWT81AT6xIEwaXg/AuhkkBPuLgIzdoBj7sTT54yIWqXjoIk7akAuDSNwBPfmNZB Rz5VB2rtKvF3ZVbeq+E6wTo2JYqRinObg3D1pepw0EgdlE6oQTgkD3P8XX/jJrSmjhVUf987 vtT9kGuh8qSAljcxpdvxzYDHdDEyBUsRVSowGlgMJ48OHUQmp7Jp9kunq5r29OAN/eha9mdz /9Zvb1YWlhg1RqPuYe/7RnOj5ssAkNyTLVbUsy1mvdghE749QmNKNzhKGW/IoJhcXiLT461N SxYLoHjNbCxuqxurRSdfxzQd8JoFbnQCd2auD+jPWJ49cyqiq3AoNxJpFepeliFkGp+AcMll PobKNIW8wqDpTAkTSCbPBBotzLRvisjK9+GRTs7MZySjeO5mXewzAMpZNG3NBmnnlC3TwbAP Zi+0z9GrL6wF4d5sKOEkweD1psJTxamgoz4xwbLc9bpkbuQsaoWbIkUewi1rraAHIIz58yUX +2fYpqHo2GRfSC1Ull/o0Kq83HsQSQcSUGy0dqWLcY+uj0epMMsLFDIHLwXWODNLWOsgZSHc un2JMQDaW2JUnCQx9RD8dzSasEX4hNfVjt9DC5bFXirVYu1tC5JZiZRNoH0CZ3BhbY7SFiCr 0tyDTae0/brk2bOxW+/dCTaFFf7ZKuk3HYoihy/MeZQE/CnEQTzx6RFWb45ZT+TLLn5OkdYl 5p7efJMqm4uRwX8A/ZY5U2RSpkosch9j8vX86gx3BriqzZKStGM/DErwxiq/vwalMFl7ZSIZ Q9cYYRekb+zCgAF5q3kRzbB3EZ8emPO96yNo87ZMff3doFrluOXSonAMBf26hrzNOffz81TQ ZE4UtvFfj5DDxUznY6n10JFFYnSDKKMe6meCG8PSOST9rJG0fhTJxReyVZ1bueSJZGJmFTSV eeC5mmtIE9EsaH3QxGaMTfLIZxq3WUKqAw4RbCTdaD/D0NjFO4RSsf+8VTzMus4mDUs9fq00 HPPHOkRMsP7bD3mm0M8zCFNSg4j0KmmI7kjwbRW/5tYccGK7iVxxpARSLqsDAOgh4sJNG1Ni CagwFgeonQAnDyuIyEFXQVJbIIuJN2g2LKOXltKB/iMLYtsDwFwJHSzBsPTZ3UivzuJUX18G 5Ph/mQ8TIiNaXc0U1BB0oStH9jsnR2MTU5nl9zjtdywz1L6XMjrd0uwXDS4wyVIb866Tc35Y XsFtn8GW/w45BsdV/M3LwfihhfIZcb2PTFV4hCGc89Ki34RaKZfJQMW9RmLVIWOTJKSFJunB +o7v5ckVG/g8+UI0XtqJaqV7G30qxmV6DMm5jZ8YjX95xJb3h4I7lNzossYSHmyg4hazrhF4 Ece3PyW2Z9tYmvTdaiqRW1mr2ay0TQVvqMIU6EHPZh6sjjPqBDoMe3eUz11lGOffEd1j7pbF rNYyMedvlXM16SfReFfFXD1DdMgr4kaz2Z68ycQrDqRFbLC9kSlhStlGC7YquU/IVkgVNzsB odXLcpViRh/tlaET717FIJWJS+bMIBVgON3QZN5HQ8TD9APY68G7YBbF4aTzXZcSGfs91jQP /vKfDU3ru+Q9RG6CahIfs7onpHcPG0PE1xr0EHFSN8YX63zzVjCGH2UAnNtJhrFR7LRNc8QJ M5LUDS1krj2kK1wPfYMsZTJz+VZ7iO4lD6i7C9lPmnjLOsCA1+jFeDG2nsB1DdOY9wRtLaW8 47nKF2aRH8IDtWZmyThxsyfzA9SqViP3q14EPllL2J4B2x1Jr69/WgvX9qeu5tT4mnJo/Opk XLnoO6fFxcnHwyZ/sRlK3swJq2JbqlDYQ86A+BsAuzPWKOVK2tK5N39sBD0LbZp5VIl+rbGW 54LTe8RaVXFKFrGqZxAAo3eLIy4c/WmvPC0r+SZOJdZQl6TmzFywRFaB8k5hJC5gUGjoxdaN j11Oauee7ZwXw8y9KPNZY3d15KieKlMfjdOStvkDZPkEc5+iO09wWoaxkQuBWSz5fOa+6+D6 B9YRzJQ+XM7c7RkrW01xpX56MgjU2VsUfUPQHKHG6xkKl0scXa9VDJVO6u4aqSokRL6J9fDs 7c1LUrCoJHjXcXa+2bdg6UZdS43z17L0FrEdY8cKyfTcc0vO7Dn4ORPVGWpEi/sQsz5hCI/+ PU6pAlFXQNmzRzvwZ3Hkpaz54xCByFVkXEZKvnTlQp0LAznug4eFk37JvP81j830GCw68xlU QrRJjASjRd/zmtO+e7H6p/x48zqKjO+NgWRQQUXF5Klcy6BqmxOt7HHAgaj5cJGM5W22vgLL oC8/5bI7HIj7no7mK0/Lx3FjjkRW3L19X3cfKJS8ypsCGN7rXtSoyxl34/hmj699rPzTNW3C TRBRT1w6jPF763gtIVsAoVPI4a+b3xfqzbdNN+kOMpzOdYQe7qFq3JoaBJ5W3h/pHg0WjZi9 aFSlIH4bD0rrN+gBnPh/FqSRrcyrXvv9Jlywa5yEh1wkJwqC17KpqlMZBBd1CDzKnvmRXdTj LgzMaDS4RsUx4r4XbS7dB7LV3q0lIrwqFDyZEu4K7hO1X9LK3eYgprqWVO78afNwq/6d9wWR XcMM9/uc2zaVNLAf5FpPzWKR3pVHYS9fUchta/BwPv56Q2JeoeFk9/6XpbTZ9zty95W+tekv tbiIFYzEC4g8FsAVP660kWk3korY9W+NCPj8pEDyo2fG8krg4CAV16vuN2FG1Y0yBaaJajnv jO1+UXCNaqO/V0x/P2owTSotOIn5WQYbcg2xcHm6duJoROnIq6a+r2p4vBuyjnDNrPR/o5qb Fj196ksHSmzi12pxnLKMW19dcB7VXV9Cq+DuIJYIlUwGUcXzTciLLfshrUyy2HiwO0Snmkug slsEMQjzcUVH9EIibsO2rwRir/ni2knL9Usono5pkQxFMyknQAKdQm7vM6SXqaMJYhPRphl9 t9W3rN2dfK0a45FHJ7Ikf11lJ/XvVXZSyH9prIL+7zdWkfrftJ9e6i8K66T+8mwXKen/DLl6 CSbLxBxNwqqjHA5f3k44evSZOjMR9FUYMXlO1aYaQ5MHH/eWa9euyP0mshak8HQhJXv5WwcG K82kr54pUT5U2MR2FjErAjOVZU0GtbLjxjya3w86OekM7PlKLvbGcYfRpTlBmFT0TV8qglmk WJQ3FH7jM+bong9yG+mLaQjLbkLuhjqEcH1NyoaAsArfjB0yWO4rbEYVOeZoonJ1cZnB7gRU KqDMfCGSgLGNioEmMrGJnGQ4Vr/0dKZgwxxfMDAqpz1gBculCd8H9p6NhW7y+E8rg8tPopiY edJMJaCD1IoK9EJGQEamCsNtXoAy9LvpNw0JvBF5b5NOBKMmPDiaWcP/50MecSPWV7zDAeVW 3BqH80+E1P27GvlHhApfsvemH6UydezTZosNBHhP0eqJ6ebuFvvGsL0C+R42pOA4iRy/lB85 zR/eHHMnjFHS6dG8+9u5HBSGSZs3bxnCerlySYn7zC9FOUnknxjsCxlw45qFVumAVGwXbDx4 PZ63plrY2bzp1HBzFmnx3MImIAl4cgdfxsVVCwUE6SKTI4l662NIhL/IC/bppU1VT1oONkpx kv7Jtv/eFjnxbydKae80TQlJuKCbXxG7O+51nN50jZm9khQRIyVOc3iYFKljoSFO78TwKrZn bEXL4DklsRWPybXrcIWf6w2TRU94cHwyQDtRrmZRFlNL4Ka8Lk0eI7JGLm6JRnvCzJ9Plq44 FU//qNHUXJeDfolqkCZd6s2p3ek4lC/FYwWWZCqP4WPq9veibuhPawZxhrcovxI0qa65/+VP 0k/YlWttN8v9DQMQ9n2gXwwxgvFf48tsYsivRxtv1TgWucCYO9YUrIiDQYtYaJ/vitRP2rtU fMpEnmzP93QraCYlbXk+6Y8+YzhYi89sSuo/Wf6hbS6u53WfH142EMKbYNt2OfcLxNBfCXFy qZreHzAJQUxP2BkYhxrr4UDEBK+E6c5G3Lf4l74nv20MQVO3byXSqksvlmKU895qc/zBpUzc ZI8jE1HNJtMM2Px8+uAG3cAFtv4T7ZU94fEN819pWXUZj25A9CQGUF/Pvn5M+vGovOhStopJ eZ1GPiIh67VsWxCJbRYQeyYPvIXWzb5zBYrc9yUuvJYkvVF2GGkQCOq+FxxdmBgUPdIO5bpa D0TEQ+W6V2O6uCDZk51RIJ53m8+Q8czWG2UwykJ2lva6LHK8rITW+aLCl9IGphiFRIpCIUkk hl4FYQgkFZB7gTV0i47U994YR4PODlgZaNWApES1WRUxTNpC38P3SERxaZMs2OIg0pTVlxHT zjDDEpjhQLUywC3+/lTemOs5UbEMZvLt1s9IzsOXVeJcqpDI6mPz7m62bCl9W2IiRypecGlj lCbbFjIQ4pBzM0Ozg537fTiec1hefOHnKzgnqXq9FuBNeUycy6zFk2RrsEp1cBQfM1X8/shv ondrsZzVqU9a6TkbLu+jdfr7jbZZXJUXcZq6QYn5JjQwFbk3GeAHI/mZJKwZGjiopiInJ2J8 75lgTWQJQfIp0WwYCfk+DQ1BspC28qEBnd6tTy3sOP8F9mnnL6emtUa5yYbfsg3HDbfsXeJr W7jLc7N6uTwjbyKWmIYDHa2qBS8pHOYlQJXyA2s6soKnyBIEHHNFQY6FihsiXrs1GUdn6pLW 7mW/UpkPV45RNO+P3GS2j7dwn6GGtTTBNT6Hs2vOfr/jcc0KKHaGRM503ySaeZjfRKBIVeYC nbLX0DQF2bATBMDj69LN/qp00ffZoDNHnCxSOeCyDWcxsJjyQn6GyuRFVWOtpgzJwfntKCI9 MKcmZ8xZIY3y3WzyRm9mYw1TlVqrHU6ellB9TfmgBOfP2jzP+/sy5zBFFTqg2kEh0BcxWhUB DbC0KYIUSYCr+Ku2OMAFo9YLaXvTTMElSH6W6cZAEruBVgNf+8n937+rRCRyz6QPxwkOpNNH U1iY0MlkG69UQtY3efEDn8ra7l8Eur2uJw13bl8Y3NU0DtHl4WGjKfbWomG/ltZueDS+Cjyb HiSNfuH7c12V9t6uz2bA4r4o4vB7mD/pxjMmGeCao0E4cQ5tz2K776TXlqxedo3q0u0/equn EpFYkleyr2jfijhFlTBPZjLArydnv2iQSLSKMb5czBCUfeblgciMG4eTNsUwO718CvYyK2Eg 6vwy9/NMtXg6b1nwp3djOueztOpRuSg6zXU1Kge06lXHYOW5Vrr/xK4N55PiTP3bBe98HJLz Mi/Nw6fIwwnOqGWmKvt9YoztHcyCJuAmiePRsZriAcXvbfyGeVtzDpiX3iWKrEz/aTkBmpw7 OfRannWTucg6+Ivc63xXI22jCuh4ncIQDuWWl4m2w0S+lixea/H4hnVrNqtoGGB5dZVpONEs aAPg+V0Cae8R3M0uA+nJxhgSOVhvNCnWE0aHBDtcVwZEBGOJMjl6c9UoOE25YtZx1MpE+hQl aE6gYflSDn3vix0k+thOrg4g1uLidtFqjivz3kz2muNZF41F4OEzDgeUr2DCEt3LLaNnTgIl bwO8imwMZXZ/W2lqpJIhew0WTJCJ3fHyZLw5bDsFbtCSrgpLmFxm6D14XcSwWNQkpcNT2rLQ FUwhgtwCvtJssDVYKC01pzL08i3H5A75naHkTvj7XCeofeQbT1TOGxJNLMXse1/m9Qw6pnWn 1Ic6zR6bSXPydw0t9Y5KTpQezRvcIT8VeqqOy+J+/3l3GeozZQBaHyJMrdw9MPLyCFCXaoRZ hqTX+SLP+67VO/HmZ2R7KLb2t3DmfWoffpGJOXW3D1Nab4OkRNgIl59GXmJcYW+Yg+pS6pd/ LvqcUD8VjwKPMJeplgg6dJc8z3jM2scq6/UjRSqL46fxNz/xFd1wtZ8q7U0P1Txn11pjoxJU l6NzwwREJprIKi3WpTNvSIl4avgyzD+Ipgv9OltpVj/8/JPiVfivncPr9rDbt1LD/wBHzMXm QsRbQICIPRVz04Z4UtLNPwgNSQLt8eCu7/H93wjLLu7rTYKFZFwqmcIU01s0k1GbT0hAalEc meTrnDsqeXXBoFKaTBLIY2zDHaR2apP1rBOPxIEur67K57pcV/uzFMJJKl84xa7rIrhu7uji XdSjqdgcJw2Ck44ciKKm3WvWoFelbVh9nLw3EzCrXA5/T7qp6T2q3LeQD3lkiGX77KnPOYRC 9T7gj1ijEvUg5+ICu7ednyh+R6zuwsXII/pg3dtfSXKSwG0UcDEIov8kNUZo89GOSg5F2tVi fP/8NAU0NsONz5Ugiveoz5AwXBrxzjCt2+WHGgq4v1k+Ld5s0IdU+6ZWXKlvMTyLtzUplR82 7DUXCB6oy5CYZqG0T7TCV7rzNkjWNQJHCjMBnWLbLWPbF/b9P4v7cf5VYH+JBumyQAW3VXG1 tTfRMarR+Fdn4/p1411aQPlPsgoq0kGfHpRjWd4Pl2aKd6pEXd1a34Y2ETmNmkMMSq03cxuS NymKc8lT56t4SO67U8huqqjWuT4gMNVmsAyBnVhbeBQIInlVp1wXbA88xqNRTNqBN7lauFkv 1N8MaxrMeMdoPdKqouXpreIWfM1DY65B4xqb4cA3/Yqn2fsV2IgtZkm9RY+/tzJWYhSRpB4B 2H4+yFKtB4/bi4KKGotQSKfWyPfWKN3DLzImqoNS28t3LH8UR30dtbpxUryK6Q1rvrzh2guZ JRUV3UG0wCorJ893tb130tzXT1zcx8T9eGmHvy/tC71Xnb+/i6jVcEcNOp9fHLnxKfGXqZ41 5loPDAuQjks2sjm5j+L3ZgXdO0+MHEUSAocG2fpaOIoyYm4G6fEckSCmh6TUgXmB1n1HMug6 Fyk8On9HoN/evyDTVe7ISybIghfvXhwUK32ZIFXuSUZyDgTmlJB8llNtlMtQk5M0knc8526t U9Fllo/RkTY27MUoy2cWKs8Vx5oMKMwK3qTufJvZwoPXkjm6zXk53FtapXgAkJ2b75uLvGXy 8VbUf0Ms/dMGkJRASv9LXPJ/k1gSV5dBSP0HlNNfHMco9ZenvkvJ/R/tCCiXwAl1qgkMBeM+ rQnzUeOmbZTq0Vbg7b81N1APFHygqcye+nF7NsGw21Mmnp6PK7EnP0lFIk/D4r46xlby7Wjl wpEckyOCaTMxI0w3PlC2d7XSiT1mLVBAsEhXvWZk+q7FBBjMpzjS2+ubTJtS2Wcf0e+HYtFt t1E0xIgya+PkWB+12SOZk30lRQ3ifOS5LGUlaJXnLRHM+8P8lotubwlMKa+cSiK2MfTlsB+y oMRIk4bB9uoo56Om+g68nLDPNQ4Nw2ruNuG5A9PBsMlcZeJyYoItq9BYQecgrqRg8GX7WaEw ZTJy2Ja7LyU3gitRRRMnmOgYWsgIdgwtII4nsLgnNnF22C7jODsC8/pLAmvgMG1P/UjiakfY NJC4KYgf57vFlK4kkuSco+AnaygEPb7O54rfhEQhKByLo/jBUeByLgoH/0L+RJXiRD7yWYFG DHnQUTRnZ4sAS34NnsiPV0owqzJbO7CmSANnmsyvjUZllemOzq/b5s+aAYhwOHqWej2ejcRa 3neCdlideeMKHSutjYx6g4WpiAD9d23P7xgPCEL6rGfbBuzsTEJ0lGItGXyC3KzJbyIKdIZ9 AgTjyI2h3vMLm7ROdvSxoxk2L9Sa7xrTqy1PWb54eM+qZuG40XZVgkXrrrnygEfICuNzmdva NMeTzEse9M/uWpvbffarWTweileSfkrXfucubxl+00KJ0vaDcbdz3LpDJ6y31P2wn6mHvFN/ 8G29It2xK9UF10oMyVIMCr+li+asoSEMNtU5HsVHPpeg0RAbm7XWZG4MnVVhufNZpIll596w ezbn/hvrOSmouWuvZ7q16jBKtCtbf0BvuF8ehoWlEuOUi0yPFPQ3NwomVLZaWLp9Bz/bnybc /nlqGTbHS4ojfsK2Es9lnwuHloEvPgmWEXZR+D91ZFlKtEpBqYCTwJk8ufBjdThsSzhvJrgI xVWa3EnT3QztNcCWBCuDdjp9+8rWFJIBmoPoEMD9J9PJAIg8PLhMBJQY+/wJfTPmc5PHkLTW vbdSkDJJ0bK/9zYVTPiRkgy5mf98/rNTwccv+LeP1d7jy+J0DW2qJwQiR1Zxn0IsP7aWCo/u yZMZbrPm056F+F0rxslk/TRkIb1fKefYGmgOXd8PJoXDSLoDhz8DQhFyBsPNWRrmlGnf3pnr fX6b69S1wGq0oly+v/HCYvr707KOe3oIGS6Q/duSGn4ezUq26GDTyZEZfRXi5wcK9oX0tk2I R/4d8iRAETDA3y+psV8a9NWRmThIRwexHd0gyeGen/fRWIQpM9rQc1wz3MBju9r0ZvnsiDFS 2kpVkG6o0lKDRFLclU/kFEsIzHVYEqB0YCBtw2zPlHJrG9VLZOZiMIs0YRSeOMhblpjyBdP3 QmQQwrl2taVuhdV97Rh30OsLN/4RlvT7+4JVRe1sL1lW7J6QCwLTuevUdvJYJaDZeXySb3w4 h1H51Bg6JI8prWEbgxxRBF/0NIaWhVovlBgoA/pkehaFMEzWnjClmTV9wszKwXPZ9HZyS6l+ KbwiZ27+aCqQAeaywZMSIdUAn/W5WRXNbnmoihNkoVZi1P1ub9J2JhQiO8DIc/UEBBkW29VS yj5mLZ37HTHDwqycwHOvLOv2g9lwdjX3o/OSoMmEKatAvZz+N5Z1KrjpcD9M9oR8pb2UCCCw DktN45he/IG+sjg+uI+FXnbybKLI5KaKHjOOu7JIe7iPZTSvNVXBqKWpwL/Sz24dAXaum4uV mwWTCAQIKr+/zkLsGfU5MjSsR3VyWhQaHfobAkH2e8pw5dtuyCAcMZckyFTe9Hbtovz5t4Gi yiZvQytQBqfUNDfzW1llIltS4jaO2N4Jxg/DQQWq7pJqsrWMfcUOENXfTKQaPm6weIemLxFy uLhCVnawn2yavLiqSS0o5cpbaDrcg1eOsO8T29KeXu2ToVJjv/Cc6TZFcIHd3WjdJ1zn4l/D tBu1resseijJGB3jDaXhjY1mR5Y6NJfT6hiVRt7jsqNHyh9Z36o0Qlc7J4x5RGPdFDMm9kG5 1AHrrqRRTMnXPdnEguvhcUaeim9sXTpVmfLy7+HDXXGVq6N5/quuntWhRtvSdag+HQtWlBMP 0fQ7JQaCZ61Ep0wyu4xeAdRemTQQKjX9LEuBZ9NEq1xhUH5ngdcbGujx4iYv/GPsPcz9lZFe pYiIH9RnnrD8YvkHzhWN0WBUZKGTkI+Gm5SeKkeMMhEXhXKMFMd+BxPW0sH35Tw1CVGoheTS XTAxUigGmUgbVYrRxPyQ7Gkbg+ls+fBrNcvwA7dp50pDDMj3lfh3iIqzuHBGFIKcdrpAlTMu jy5GH5O1m8bP6V0+2wvNkaY9NItgAv4gfH/zbew7Wcxd9faKrDwfz6Be+xHPPcfZMsdq9lT+ 59YVnVU9dMfQgLasA8L7Y6VLb12a7sT2qffCTi4Nem4dIXX3l49u2PlgQXNLLlcrK4AAI+jo oPjJSu+TxXDfoq8v8tBRTpgJfB9edixZNUnK2TCdLz5Qc7XQyG2CJACHLeNzMtHLHIzARSf3 vjO3sXifDY+Mzm7azjB2rA1CNdIgfJINuPr0zOrS9JNIbb2K7gq4mdDfTPiRoSsRJKZP2rMd 9gO30Yo2Awus6qe9KZMwTtke3cks5RXqo8m5TLn4lTmqplIj940ijdyZjYbm98j1oWPeSOh5 VETMvV4Z5qOWjzV1NBRfPv9hY/k6OObu7ymoAhPqTFujTVhX1sm1IFWG+E/uup7K0sVQdVJj QTr26GL8/nZFatGv4y9INzVNi9iRct1T1RMHy9nt+RcM4QA6Jrq925zOMFJluJ64yFfm8pbo 4Zhz269qAxn1Ncm3H/R8Zzpq0n8fHcdxp8HnjlRt4KcIL1WqTS7FjlxHdbZ+IAPfr5HqBOMG fllOXq4YxwbqKNYwvmdU0w8DYS8n9Nc/Fu3VyuSb674imzVx7X6+M2i6OLHAc3ptu+mO2Dkk QrCQAVXj4BRPTnRX+guIHbWIm2Cv1EJA26pZTQKE3T9Z0Hy+Wtfvxj9Iag+BVD8A9pg7DYor k4aeBr+IBp4Wu/HkT04B/Q4OQb2Lp82k/obLfEpbTWogCsUeOOhKDFzuDSna/G1nmPh9C/QG /pDI4CN4+hlI+CuRIS/5IC3x4QcAuQGltqMF35tng8SU08zgsxJiONdpU9sb+BAZsgGR8EDb 75gcPkCuNgKc3ofC63rgekRp30gFzYA1xKTThxARYSr4LXiZF6xpjmRABuTxi3ra195wvRd+ D3R6So4ctqKWhDZ9JzibgKmVwd5imt2eWmfo0tr19X2aDcFHO8X26VMhGcB5t2qBYEGRTLLQ TP3STFwRiRMp6YgGNEXVNsE2xygjuzwnexPF7fFFCqgFMaJ4Uu+YSwLySowyBqtweaRxk7vn eXZuuLqD3LoVo9vrSoN79juGRtrJDypF3DYf8qDJ7UcfVyUOO+aDu5cgiMkiT08pqm80hwdl WHfEBXhlpgyxyfaWuubjQWgFDSknFLd4EM6TwcwpRIbo16IblURwv6ATQpWjVMqT63ppxFmM 1bh4uXmaSnNalFk8kQS14eIWGz61Z3wpg4TBUa39xKtUeHUcUX7iU5hnKVRiEzpuLFlnaSrU InpiweZkKVFK8bWu0BzjI9TnS86DDtpNqecV4KRYxzbcE2hJke0tTupNUdmaF1hX9SO14SRk RPtkfPXNidFe9x3KbR496iDUCJbmCYyWw1Ld5Su/0fTS3ReNuZ+qAwAHFtO08Wu2Q/hiQkrz wS3DSY3WkLI1LP+coMSuynYNBLF8t1Uei/mIBhRwDH2XdewNt5+4UTxJik9pyWSSaJ5EG82T AlEdkqZAovUpE83HXInNut/Bjo+mMEtBbjVAWksYrd0NlSJp4/kgolGswCtknJzkXnw0ZcoE xVv+1JBiSCm/zoMQ4Rvic/lgRKXGln4nSaq0xC/5KpRwb7cQ0UV7lc/NzFUgZfiLTyoQDXkY yRuBiOGZ2gxQYu8DXhcZ1xh5xOC9gDUKIgI5z4NAwmymy4IUkbuW2hPe40pz05tcTZtdpnKq LhZEEPjqlb6T8e3Xm/Wq+iCHJi2+2lO1tlvE0Eh10yAaaD7fsLKYWpPkKG45OFq9hkxz0EkV 2iJ+lWJx3vB6bE4TRauZPKEd/ASqt6J1fF+9/szJlLAUXK+z80Qn4/YS3QTxf8sF+6fbJYmS lvqXuMz/OS6Y7P9Ty0n/ZXWX9H+K/nQSzJaJOcppkywoOHRQxoMt5x176hoXKkw30YYqfpyU 3kQKFuGESmkwV+5CuoVmQ8pz0v/WeaJDyz+jJKLfQUpIl9fitWKOr4AQi6CrCWf5vv5ItGaT rKj2JTp7F/HlEVPEjk7maZDN+VuQk0m26fXVMA8L5fgnF2db/ScIFokYyhJJfd+4stWYq+3f xONjQ93T+CG4Q1xZ8hoLfptb9nFm4eXLU52zX6RTW02Xsk2A+YMXPZ1sjGQCD4iYpdwfMOzw pAUy7SmLiYhFy/nPK8AUGsrCD/u1C9q+d4u/IpyRUdFckvVKeAtk905eOTCribfRs4NS3Z3P ew4Ktr8rTdtc/HrbXM6zObiBDzzQ8hcpgA5NX5HxqQf229zojIf/SRlPmVxZFDW1Z1PAPbWY WT0tlEA6iHhMqb9SEHiwyP9v5/bIzsoASVgKt/CeF91iL0RX3qJ4DIdds1EbwEmW0QkSWIZy EDyICHQsyvVWD/9DpacCamulKIliu6YDC6ZhEImOgeZwmNNoFDKVvnu9FsqNnJWorfne21wa SWQj0AzOWJ5/fxz6kgJUPw5haJvJlE0p+TJhIYesZtscECqLP0CleMKHETPSqER2MuU9jGB8 aXwNV0IvU+JqaXuvmWy9MuarF+fXz8/dSAGWo6gURscuBUj9WHeGKBMmhj9h0z4RkTAx7D4u Prf3VIAiSvMpP5jLKZBlMw9syGBEYJtiqnFo8tDlPB22HR1ouu2nu/u+1/FwBUnXGzmqKe3J /LKknQgUCxBDFMdH+fKwuNStG3IdOFXWwJ3DxAyydhnUmuusrMVs5WrGiEYaBAClnC9P8t+0 xlDc93zRIcCdmxAM+VudnPTBo75MFxLX0Zd1r9ShEfyA/3IUw1t/NkZwle/9588iEh88Ex47 3XoG6Dl7BdLq906enMwI+OZv9/7zwpt39VT14wJpbQqKAWmtEwBSOcc6s0om61cyIZ+sglS9 fOIXjtZnzNDJg4V+Qp0vAle/6njE2fX8bfvNk+fnD+8U6P3xxD5Ew+fzoaU585kj2xfhiM3r SZmU90x/KA0X2Ti56HDm3PpyexzjJSlbtfM4LSd4ipaY322PBcSXg7vNalzkQfS+ArPurPw0 jMYTqtXx3OJorGDrNnlDdbPsEwYr9vsH9kekI3IaIrvskvl3kUX18kze+2xjhKAUDmKVryxH 7K/AIfYvl5ssM7rtRoeNpnXj0nD5ASzch9FaeJan04G3mbssTGPuyohub7qP0BhLemHePRte 8Jo7UxP2pMdmu9CxZjkbe1Bg3qS1OQbOyYUkHXi0IZ7/hr5/KUFGwymjGUajrrmsbK77IBoQ RZOm7/FQW8OHkSa4fwwmfENnpC4p5yWiAEI5bysIYcvpM1fh9fAlBQ/IkEoFs9OvIyiIh2Vw XOGsyiTR5g49d7KbZhtVIGBFfluWGzyIzBlu9SjNQVfdbc8IRDw0wyjKS80wiM+y1Fo7RuSj 7ryT1AzbLHFdE47t5YTk7M/NfO8TpPIFlaKRyGVe5rL/BLOCdAY1xbMYIb8auVYFflFAAe3o 3UmtDypVun/kBS1oP/OQTqIxg/FkGFMiKMTlM+EynPwjaLa2hQ7lBIKU9uvZznvgZnzGsIK2 6fhgy2/qbMm+ZPJ5JoCcrW6ylFKOTlNtHLcna/zMCyDx9HsSkqym6IB2y+4IGZxn4fZEkx6E s1sQyJJmvJ+Ev1MrkdbAJGcwJtkntftOmUz7uQUAegdIOSxGEqHKQUxdBCRGCscii8HEcJtG qYu3ZuHLtACBYAE1pV6LM1VGb/aHFMT+dAVpBIoco/IYvppikaV1cPLIRJrf2nhGi2XRlgMK ZL8wz/L9DAxwv2uHiJBgi1hjBdj7wXZnl8kKiO0jgbqpmqh7QgKcqoY/dzrmlHmKtg2YxKzC OONbvMteige7235TuPQ9zGAITd/eIcPEM7HYJaXlzE/svFqUeLq6jdGileM0GyZitTPp0+yp uFBaXMDxmkIfGASKvn3imTaLOowwsYoINSbMMoXZ1o47pEAHVZrysCL+1ajJUKEif36iwM/j o3f1+boE4wz7Wcqa5IVwamFjYYFsvNtv+HsmrurahIb1uIfrgS059KuWqljMXVJcRIZM2joY XozkWp9m5yAKDuyxRI5IW4+LMVieHe0IPp4d5tbpXkmMMvSDUlB34QJxRsrrnj55uaVAolx6 i2l9iogOzpizfKqWigr0dZBIlee8PkkYcwNn+U0R457EKPu7KFJgfLb3kE9feJQd847/s4qC HB+Xp/zEhjKbxfnUKrLKkyVEgrHqstQkYGNwpC4jcP0pXVSxGnmk7IfYh7dpPrve9VyEQgS9 RvEN4wcvv3/7XPoqP+n0Tf8S4zNnHuGz76ek829f4OMq7y02uf1+Lalqu5nv/vx+8vndm8Xz GwaHGYFfqe89YwUfMibPvRTL3ih5YsNz29TmRXoG5VrB28CjoMV7KIzkqsuW++n+4nOZhlWh +5t372zeeCtj+8fGKlnkOVN7HtiBHGRaAVZE8TPTPig0Y9pRcGr7KpJ5EWGoTY0l46Vm3xrD Gw306DKuSds1/jRNS/Q/1bqa6e3pOSajWza1f26kDfWs4/XUnWc5i5agIH6eB/y/2vsPsCa6 bmEAnUlCEiBAQKSjoUonDRKKGKr0LgKiEiD0JgHE+tJBBKQLiEoXFJAiiIpKF+liQ0RFRcWO veudJOCrL37nnO+c//73P89zHffstddee+3VdplhZlLvphS0RTpPXGJciz54OmuPC7zMtEEm C4soLl9foG5+qWxAu2Y1pump0KCjEN+c0/6aAPLpS6vQvdOHLg/Pw8hiR6wU9JWT3SQvPz5l RnT7cfc8yu3MxWMoCf9J5/FiwW4xHMMnpez8ux7zik273jQPKCa/CWzcb2pV26bZ9m7qiOOe GfrJ/qtDzs2d4hHSlidlOrTyLuhs4DvphYkSqbiSdRut+6XgvUx72nvKxiABYXMbbispsyym fb3t7ceV928hf2x7mbbLWpkRK5K87+xLumI637Und6l9jUYuHvnzAlbZ9Ov1Cd9WFb7vTBhK kFJxW+UVZGNwRe0J130DXq8ZjXEhquwzZKaXWrJibGckslEZlrIRhofRgRp+y3v8nt0byzsb fG5fNDbY1XAfrggLTcIo4QYFkLObaO4IrLXaXg276rnQMMu3T3duosUHIS8hPSWRpQ7I+VQE 2lGpajbh3lOk9euYurcqoQ7oxsqXlfJ1FRY86Ml1j9S47nUOeA5gYjcRsT5Pn0zVz2z/hJv8 5OmZpuGD8/rzjlb71+e6SL/g8f/f3NH+H3qTQfsPT3xp//FTatpa/3v+bjHe6+er4s5VYdh+ xYOcY2MW0ZR3+450EoZhzHOi2GHv0Wk/R4/q9Uq7RDapCzqEKm3M2OPzeopYVDkaij+g9KhF vGSTj64viTZResy0YjCb3J9bRu4OX5FKcS96lTiNX/3sfUv5TKnnzr3MIW9B/+kzLcXT6pfL b4/eSD64Qn8DIcP9UZhw1LOZCTWMN9f5q8n3qfo5XyltO01QKsGHEMiq1CDZT8mPD9D2JMFn wl/jj+u13zjbCATm08LKv2MNXg7JflfuDPoulvzy2Kx4Z1kePzJJQNj51Vl6pcT8anzCtCRK 4PLDzz0gc77IOOyZflyyIyZEiDZMtjfQG71sJIyesJYS1jvuISuOxAuvlTIm3KvnXzMBBPCY bFGzE+7b4vUa2TfhNP7O+nWJOs+Q4BUt9QtjX20kuluEMxCpjT5XUYOOQLi4OTN9K34N8yhS PFmo0RBmfizSgaQusPOH2DguRNzEbL6jxcQq+xt5vznzqgIiRWbvwBszofSbph0n1FfrWDlb 6/44l9vbY17uXDK0/MxAB11bHbv3sZHt8oP835w1P/qL9Trv3LPMznsmQkye76C41dVrKijN 6y75fDrXJp5d4r7SOovVt7gmxSDjl+c+d3cWdh6XdFt+q9YpqXvG0eDW3fKV29Zqe+zgTz5p LL7F6LFT85ht/mmkxJRyvbTTSRAJvGspTPQcvM/UKxD2UaUxzFqeNLpLNAZIdmYml8FXJzVd tDRVqbpXPpuf7E8MLRmEqXRg0YEJHwl1qtKp71d35Xzbj7zeq/EZTx/iyWoUVVEa69VJc5YK qi3oilvjf2VcqpoOhGDlLXD+Up2nIo9me1G0lb5t5nbZZeFq3j+cWfFMI7CvUkokskjjSrNc qVmNY6MuRs781kU5I9zgzzdGMpsSYf6HVO1ODB6Txpc1+nZNXDF9yv/2xdi6a4bHr2/Kff7F zrdbZkfyTfcr1HKJA1t3hYX4rr0tVNsatevRxtloweOMU2XvjoeRt2+0q43Y/m3sRPLnM7vv 5Wz/vn7P88+34+3eyB/Y3PVi16YLDq0hRVGCp+7u5hF/8Pwv6cDvkkfLkQ9cJTrJGpVFzZPI h+anTqDUHkpdLlEzbJeWjpfA3KrV1vOJFGtZhbGYsfKMSxwWo50UsY1v91eixeJPi5oJGoLu qiliRBgw4XC3nclfViBxGu3uAM8KiTCN544HHvPEgdbx/CGjef5e0sbZX5XojfoHtHUNJ2pn EuWJgs0xp7i7DL/yM9QHYShDwSGEGXT9c4WcdYsXe/drBL/lCtg9WQmZDm2lu5lKprjHvHB/ L3LXFUqK6xbJe1SGjtkUohBOG73RVerPJ1WfP3FessI+hj/21Nbc9QV8hhd3B45VJeRs07ep QpRHV5s+vXi/RcXcMGkN36UZuQelGZ7yZQXEHKAeOd6qkFiBDOR3N7D3NXd7IrbfMePRoL3E kKIhTyGx7s0acdtde+/+tTPl8eXhx6F+4703glRkQzvFS3mrrYRpLZmhGsuLaTMSYkibsrra VSBqTweOEC6cSo2RsE3r9FWqQhOSXVW2PygRU7T3H++6OD9zEUtah08vcKB2CvfUePGZ+ujC y48bZi7bzyTga4y9kv+CJ0akZsZd1MXelk5QK/GOjRVpjli/xmontzzzvbnQ4y/wvVw49Ki/ CEnRS7hHKRyBKRETnA/mr8nS3SA8nn3lhug6bsE32S9wUsPau22Pim+o6CKTk/HjYsZKwQgQ rYOcfynZNWPMdTWnxSV2kvcYI5SvC1iFmK9cDlOy5r5wQvX6TIFwV7gx913yynUxQtvo5O9+ WWl4xGvilgTz7VXh9ljEvVIHVXtbTNm4Xj5wzc3ObSiOtOIQNTZIxBtw5nuXLpsYnuAVDzjx xCFWIWjxwvEKqcdbv3dO4mvpRvkpTdoatjUW9t8HrDuCHNu7O45VqE1uuH5gXmhuDXfHh4a7 fKdJfEYb99/XeWRz67RlclDWyQ8im8/alIg2P9J+iODNrnq69vqJTtGnb0iefFfOXv/4CXtz ZOuDvhcyJzu/iVWfu9ZwG35+mYvLGvGd2WEvliFEc7xub9uni3aI7QrKRW2m5KY8tBU//3KF 36Z0412vNi0vungjLt/Hw/BG+VlfzEBfMczWqytJpNkkAXd13h4NmzTClB0qOOFasRZ3wMpo 1dkjbTNeU9yhkufeKNQJWdwhXcsQOoII32c/X7tvLl0h0ZfYMAvtvmVVFIzuau8fOOpnw3DS RI9H9fkyV5gXp+qUx85I+it1Chr3UtRk2jNMjpo9knrrmy0oizMb0kYvd+cqyvbvS/CJtpYy 9jwyO4e/IGk2axypjwCnbyNTM4RIVfhkoovEWoaL4Zwjv+9AvMac1xwPrNJ8TdxJZx3T27eG 9662Ewt+ds5FeF3REwVFawM1bN35Zu0E7v3hcjg3i2/ZJyIF97SVkXImpLaO3lBZ/WVbqUmx afuJPS3I9lUbQysNXS7aE01yzA863lhm1ZpHnMwQ8H4o8lJFWPHUbuXJc8dofm1VK6ZDM7o1 ZiVlx7WUbapkzsWn4B8dTcCkXH1A0UXSJsQThkyuJW3XW7vz2bFxQFuzcyYn/DW/TbqTfz/p gN/dNteXk8z1U/X+P56nnzCP/Hw2u8PJPrSet+/iuCF/R6Eu7dvKZVGb6mc9Y5VPwbqlhtDe zHnzpiuOh5yNlWIw8m8PX9lgKW3so5XpYER5j94zqap6eIJBVjFrT5EsbyW7C9+xdcBuQW0P UL29W25zci3fyscWXioaW+ufSnhZGMWG3e+qJCz7dkvobaLtC/qQc4/9yAbjMEC5w68+xeD6 k8E1fggQQURa+hTd0NkdpPAsISGRH024Sbpw41swpSN5zG30OW8Ij8Tsw32Szbk2g60aDZUu tRqvn7oHPU953mZ3etj8ouSOqxrBg5TelzMoE68g0yNCUs13eBN2yzHvGIyVm2SFhD4xnUoX Xq2YypdhOftkcOIR7blsqurAID/QjfG8hsGNRjyE7VAp8BsGgtZ64ct5DgT7xGpegK/a/teF wb+8QuDjKn+tTZbPMu/L0oEZeRwMJ3dnuewOdz9g9Taae/fXrI3wF7Ed86Zc3H1cjwPp2B0o bACichdsPrUoXaLz4gg63I/bWPab2rlDirb7Z22bnspqWKc/GemND+S3fiKUoBiBf/Z+eOzZ wL7XigyxH7HxGfMYJaPC5MblYJaUcunDupnJeto039z3NfGFmIG59O7y0dJZvtjbGKVA6kCw cnwKYJR26xLw9qj1vJzunHfbdS+an2L0HdPSgZHvKvBoLZ6r/OGS4Nwz9KDlc41rqwZpszOG wllPEIAJBteNoNHq7mUm1fST7zuJ0LoxNJOaWqGMF7ZNI1cIKXzLfKzD++NEsCtFaH1igCHf vbOiSu6UVC/q+Pt98z+whK3CDrvE+N0nlV7vk3Pk97yNAJ5pyRYoD1pJbklX8PQv0hTCNc1d n/+KaZJNb1oufdQdQRu8UjrJJ7tX5FJJxIvpJPPbfA0zagRXBGx3Ndw5vXNEIoCsZN6vFthw OGR+YJS6L3b2/X3t6rTgNrhRnML8+JbCVZZZ1cAD0Wb+WaNqhe56vnpHAYCWzDN6zSZVOWPT Ptm0+majB9aHRmEXROU+Ce1DyQ9GXG7WTQd661VuyZsVgsemfnB3oXv1VO7fRWLj8/rQesTG zjrdLu4utfBA+Wca7jnjPen8JcP2Mo6XVNde11DZr9p8WWXoia+Ra8/aF/KomHMpBfKwr8U5 5zWdUJotmPzm7sA3wg7zRfhncvicr10tgGOfMZG5UiMR6BD6hK/TLsy5HWS9kfRGlYekgT+S oHFZmRCsX0yy0bpY8i/eztbW+vPb2dr/9x6/+vcuY/7wkSntP35kSvt/xUemCBL/rVv2YjOV rCezggm9yxWFjmmXW1GEhUer5da5zuke9TFBOLUCcxatTgGzxhYlE5GKhbYwmLRXDOO4K2XH FL8t60ceW4sPuOR5UkaeVBPBgiOeJg0v9rSBvvFCTsTXX4zRH4ejHkjz0RW69heYfdbtLnV+ Ri5rDxSvz/Bkwlsfd6brqPJ1mijz3S+OfZ9qnDWBz+jC0p4i1fEeLcfHZU3mtdQ9JISN8ZPT okZZjdM47nJ0pcyee+E5omthQXWypWEqRuPHZVLDBCv3eAaKEmvTqnWUA3Sh66W4Uo+hRLAx QmrwxT2l/BYrb57P+uqxNZST/C0n8sueGiksk6eXMhF9Xv5pcqmEzljltHh0iaxZN65alLs7 plIFXe55EMfzFr/f8ELTZ5Sc5WBJq1zygLmPlIJ5ZEniII8XOsFauXKfrILlQSd7Sy2Jyo7q XK41bleUdXkVNZdr+QxWWukKuDhbxW4RvLZcj7D5Wn7gXQ2naHUf8RQ0nr7Z4l0wf1ay/64o Z7flrobucW0dZ/w25K/LDnd5gzmR7DF4kCqKvKhwyVF+/0a/sE1Ru56HbV4eEho/JDNyItk9 2iY+0XX/xjM+Gz9knGfQ0TYfkqbaVxft8TTkKgtwL4DZbdlA5buRmSgW8iAIGd29cs+t9nc9 edPbfC3CLek50okdaN2vnD9blKlJnfuMUvsi9KqXVDwtjGA9ktXewyw8YgmXLKfwnsirPSC/ vq5V3tuwcn9WpUy1nYMlfeRsTJVj9+VDeGVV9EsfXT3X0x0Xe+4eU/2ca5RfRQdK8enert2k 9IZmFZFk4kzEJc17pDWy/k5iEeKPbjb7nH0jW+GJS4SncPdsAYEp/D4ZYFBfyXLSkD/KuHNC 51hPhNal8A7qoKisnFHB7ZoDczRKehfw+E5M+LVyfMZBgbW3InuO+2MxHpb9T1/ltHiMWtO7 RRHVFiteC/N7x9exv4pN3Bp/flctxmArc+LdLv+B8p6EvzLLvm+ULdjSBTD5BAgPC4DJJ8Zo H0zmOS6p6M9vpISwO7sGjiPtH/JieeAR/Qfn4XL2l0peUSnJn3njgeotxszhxDJr3eXXfdcn SH6M6mon5obPJBkXBmBM3mJRfoXSnk3WyqNna3XbN0lsbBnlN0w8nCd7yDGh0NvYzoWrNyX9 ZelgOLEe8QpXRUwb3NK3B2s4veZRDNZLtU6JS4Wrf30ZUApNqmOPU/KOXOZbYdUTAzZSOvdv ioorHrdJaqUUOnffynajb3+srlh9//RHqUqZgBzQzXzWOjuuttzURq3ywKPxzwm57si0kBgh Y/5jEx5FnhfN4xJoofuFAtTNX6w+WLheUhTjrLzqddr6yu4Vu/MeCwTtlU7LCffHTOgfzXuc 7DDYKDG5X1zdgvE2Hw+7i7tRBg+xwqWI+hTffNDka8jvfzphzwX5ihPmuzzjVdeczBUrsxrJ GJW5LQsEmjMqCwouxPMn5A3awkr9o/13Pd3vtkuG17ltp33kiAF1RnJFMJN/H4aQjH/i1HPm 5XaZxuNS8zQ7m7lgpeOCk6cnI1yVpZeXz5yqFy/nU45rkUIAFy9UbUsdqk6QkemtkVJ9XPc+ decNsCW4NsF5tkPhGG3vm6zLpj2eQpgYxurjZd/PAkkCltKrwq4UaOW5PXS8Be88Zhb7/tqq xE3KCuv571anrlWae7dxp54yfZzSXtGkdXs6SSt2WMyi3Gvk2BPV3U0Nqtd4Gudts2OO5ifX XQs31KVXfMx0wFd19JbBNlq7HH1X+FhImMb3+C43V/VGwb4LsmPZPGdDzbKyJRK6Ay+63zg8 U6qeuN6DaZy7LvA542kl8iT5AWGH2xspUSuzwRsPPPl8h/h94VEpAcVieP9mw8rytpIrsq3t J23e3xbFS4Zl8HXKWD/AJ+hGGL/QEwhB8FeoJQ9bFjLD8MjYS0LMDn7uuo0KPvHMA8j3V0em 5v3s00tTdJ9FO3qcICVv/+x+8gxKxRebsxZ7Xyoh78rFG6s7xbC65rAV0eaMbWWrtlVtrjDe Y5MsReWuejr48IzRsjhSjtCp5UXwKQy86y0S5ZqUdWVqj1PkgRzTvqf331B5wL3uW+rBDLKj T4HvFl/L4eX+2MHtaHmvEI8nbW+aaneIPqyN0W+hu7Tld7SZa8u27reIHzUxdtrTuVaJC/O2 8zTRXnrXvnRnm8slzceTbRMNMQoiSqZKUbr3mkXCUiy04HmZH5qS3uSojyxL8NMLlgotMKWL TOfNGIVaB9rz9RsByZ81a5Wyr+np6jSuLoj041P2tc1Qq05xPGm1oiMup2Y/MoB8Xt7apf1M 33O5yptrmc8JB/3qvl/V2ei9c4tW8+lrU1y3KkK2Ep08NOuqNLR9uzc2EFCnAK3iw1Wbqic8 smVjcrABe49OvDjjEBj9KKiA97SbJnJKPi3Us03kwnbK8ientARt7HZu3pn6ns/fLO/7Od6q Er7Md4GGyxUVdupHaxJ7dyTnDU29uaAYUrIK86YXi3iqlCqp1TdwdS57o8rXW/POObMeWTOw z4/58Ktj9BJ7xSiup9MGbW8oWPt8f+ZxYihm2YY5JrpoPOpTwTXMipnVIgn7EXWF65+U69dq aL6zkOgT3/KgdzWpAsb9LfD0xVUbFP12vb19fkIUFTT97UxFi1Ze8eRFX/Mv28LgZlObRFEb NiFWnQ1f8eXOZ7sIawPRc5teCtpn8MqR0ZJdLWd37Aqh45CnN50/laK7bfzmiPXXu0/fha5L 19pHuIy6nIq0VBQFzagG+fMasENJj4cIGO/VBl6tZy6/2HVB+ak0Lfej0vn51Xc8H69OM/wa v/LGpGYAeE5ZPmFf1K2IfTFngalDqvr9QR38Ba+rK17Uvzxvvy7sCnnlFq/doRcmHA9nu/Fq JmRrEqtfjjSS1t9dnqSUFShLfutXNxnq+CE4Vt7I11QjZstT3/hY2nsBn0elXu+Ph77UnLQS iGH0GH2Y19AUsP4Ytv3jGDe86sXHvXnIsdtf04KfDVe/6DP5Zr8OLpDnATd67E27L+fxbXjg qV3vx/nwLwKjrzQnX4Xv/jJ2+zWmX8XbqOpJzsRx6t4xg1VA4va1ToCtveU45n6ou4ofmYxv z6H1vnvpdUFjO9Je6WSV4hf7UI3hLmToiw/PIz++TJTfV4Wwv/a6kfgp3P5T4z0ZzTKu0ato n1yBRssPjYEf4Oc05jNQYXtRx7kFldeh7Dq/ERB+j3Oqn/ihnw3xacobBvKX8ItzYfyEzQp0 jgTHD4M8Y1ZAg4veMfeb46eRXPoBvvXgfP97Tz/M0447+GAT+czirOknmn8Jyn6Bzz9GjD8X Hd4soNnDRUiVz/peNE4Xf8ULt7+y8dlxIbvxJ/jgja8yX/C/lKxykmjIhYfCJXsM+QMO8l9q 9MmK/6rRLkO4JJ7k/ilho7Rg+We7q9JNokLhm4WaHokRYM+TraS2zDkb/Yu/TPzyw5Ak8i94 7f9nnrXR/sOXlCh/fNaGQvxf9N5EM+e9CbCwPYD1mViSbms7+wcf5ZQ7DjnJSvFtIXFnDdBz DoyacpGSfCbo2mhuxSfbBm56NkmWa5PUb48Tzk+9EAveNe+XpOLRQqooqpzzEMYIwHlnxtuV r8PNG/U9jgrhJN8yYi6uc2Fc03Hy+Xprv0nY5adXT7eGjlAl92bd+SyttknVW/tVqn5zjNIV D+1jWztWrtw3OpGcrOT09n2KEtXzleaY3AlkMr3Z+QAttFJo/py9hySqUcBH/umaxg3tj5Lv HitpM/JXcUlaM3bsxddem9z7y2j4YyO8RzMT3R/1zSMcuErt9K2fIu8eQParXzRyFksGswLb m8vy8m4lwdq7dfh6zKczeDK8cyZxr7pDT1YZJsKmNSzcP8lqxNFe6CL44Yn3kPRjmbOntrxd K7kmq0T3zWreN6DI6YnZoNXn4lqefbVbdlX4maG/WpTJ6XFVGZ41lyplaIbYWcUfxvNCHqLI 8Kl6sbVh5HUmijWrjXmcs3PsrPDC39ZL9b4Ll1zR5B8c21c2EK8gR+TeETFYGRFbit8nFzt+ TeXJwG3S4DGe/tnysiC6e+NlHjdFjeArzRStY3qjk6fed3gHX4yjzczW53xmwCctUu11dPCk vq3WMlle4jf3YCOkkK8Tb1CoQTMhOtNOR/1fnrXmcZZSGZoLz7GP9Q8S6bwLBEudeWvkXJy4 PIQ6pFdWoJDmEO78aZfdaLK1qFdYBP9Hp8gQvuUPbugrp126ejTooKPrqKqrn06yg41DkceL r5q1wUpnr2B8nA5ckvCSdpAJWLfesutSQ/0RA93kkyt0sj/XSeJlwsM2ywbvoGcRs3ZfIpOM JGnjgzZv69Ws1i/n0tQuuHy1vYp+GEVODxjlpiI/Gs0/CD7tGn5usmU05/mDfS71XuNuRzRO jH9Zo5jt/3Z0ndGlr1MWpW+vtu256retIe+G/UCojIvD58PGGTKfUjZkG009CZn6cKsv8Md6 SW2yhMFY8N6TirlyKhLI5/1Pz9SUIV83Dj7f2KU+vT8Mlu15/akochAuUdF3PO6C1AnbEy+3 bYzW//plZGvtKr2Ja1cNRr9vPnZkzZOr93Rbn1Wt4BHbzfgMHPOb5Ysr4XFJ7cs+0ejjedOD L75hgret0nwCt+yDfOwUf9f+D7DlJOfgeVPD8vURIwen5ROwu661Upy4zZ3qknjO3jWiuj7K l9I0C3+XYZyqBXN/axYxzr0iy9HoM1hDwYc0ZiJ8CnKEixRduVMTDHwkGtPHN6CrYrAIYmm0 scQEX1eUrrbTsybDGh3zWeUe0fEIbwEL+TXD+pId3T6dcm937mN9EskkGY3JC5PPEXt5qlui f5MhHFkp9VQcF77rmuAy2QfdRqaOBsWYiE/hj/M1zGBRCoMnfJXoefqKndvRMLQ1d2ycqiB2 VswKR89QrPLNnXkjSQtYF2KGl0ggGu3wcm8rtI73Go5u7PMhkLKXic2bX7Dgn2zCmLWQvzXn h8gPBGgfyJUNW/l4P0HklEDqo2LmwJ7LfIq9lw4iVkTZ+Kk826M/c4B5LmqsqJV6ZPZiycQm X6GLDTvteXLXXH4Sa16pbOST4AMed05qaxd7c+0yGKpMk4WukT4nmIdn0OZmLzF8M6wJqQTH ePWmFsXGCSoVRT4bhowvxhoV2hKIM0QrIHFZPB4XerdDL49piYZXaRuVjetW0WiSPWSGGkPI pVj2juqDVGuuXhMyMmff+oJSnHuvNDNbpbfQIvBreGzf4SrgiVSP+uqCVvnqpPAJSTjO2zLy 7bMU/Izr01jc8XXd9YlpqeLGLTca8mVdFC8GKXTlTfDk3PYYaq1ujy9VqXtoZHH8srqf+Z5i VaGPWBR+zlXpnTkfV/yR5JnJFYFYHCk5hoTM8XIGAVue5kF34fBn/jxutidFNNatM5kUMlLY wJMf2XxjLznEOsc/L5nrtGRfgXRQJw5jStZNgZ1zUJ6L5HuH1kYO7lFTyNIoRFyVGPB/TnrU t6xZfuoDdu/Mo5feuHNN03PmHwNTqgVdzm+9jR1TQ/CHxeC035uWbRZv/4yX+uZ12Qntufd5 4nHG2+LYi9e6LQjwRm7enpjogb4p0SS0PbnX30nAK1DBFCz/gt+z286xRVLkXto5ikviweWx ww6WWG/Miewtjj7yNrXmZgRNqopQZHeHxbgpJvljzaYzj2Tvetd7nZzt96pe+ZfzgeXaQhWC jM9csUIrYENUJSnPoe/bGncrj2wreUMvEhWRfaKZGXhTD9vemM4sWzXWfmH1nOQD/Jv3O8on tb54SXOnvLl8oVM8d+0c91Ax4VB+ZtFJ/Mwzh/LIeIWxmEOr7pX80Bdr2HJFwh2r6l/80nUv dn37eGZfZHcokTlbHVYkD88rXfgjiXu/5wMJOedgOuF00IEI87v7Wub26Z62sDCTkx8vNpVr /kvygKNbnpDulrzO8gE3VSWpB1cCT0R3zFYeKfYWaUo4X7RKYaL7UeZlc4+WR/IiL+53uV7r 8z0t+Ln1wpX9+0DTIeWTIv3TsTQpoUK6kgK2Jnnq9gHVdyfawETshvlJacuQe3cfiFy+rtd/ 61rI7kaR6orJsxOBgbc8PDRWBzb43vC9yEVs6b+zOTxTXDVmy5E20dCJovF+iZAabyv/oixR 4m3v6xPfkFG15PihAUmhG3d6ksfi5CP7rC6r2MpLfJ9GPm2U1HQZ0p+ZySockFuNXhdc+lEn XUXXt0ZQDheDKlrRJVY94P3Mbf2XOw3i9W8ZH2a7FTtb7Ts8cus7hMvkzVHhVNcz3XLCPpM3 cVeeHVnx1dH5uoVJMuaCh+aJ+zfxM5d+XB2Q37/KL1cGKTCxY82xb62KgwoWYhM22fFaGRF+ ORYEizerbbcX+5w7x911RftWcwUU4KZNCpiKAj2v5TxKIZb95UOfXqP0HKOyr7YYxYuN9VCq E1O+PtowNZImZrFmk3vX5R8f5V9e2vkXuL/7s+TXw0Eff+y78sPq47d6x+/7fH4Mow/MY1pe vp94PPn1uM/uNOz7J6JgmG9clmKZ9SaVXpjeHLFCQLHC0rMiTb+Sx0RLLXXLs3RvY5/bCcLy Cml7jQM3P60klnqNVJbetRI7Whuo4uWh0lmtKj+J9xa6BbxWepLTGmvCfd/5fkbqZy/ZL5pt GbZ1DQmD/EENZ3DTKnDbjtrdHraBmpXjj2czcUcqjbmwd/lTW2On+J5at5YX88084d9rfST5 /UncbTXccBvshGpaTI3J5H5eTzXZeK5Ok2NpHSePubc+SdRRJT7iK225qDjzCNsIK1A63q5F e1Hd41w//4KnNJWHpw2tKkYer94fO+emGhw6/3E/QqWdF3avc1JNdqfyMayS/RwCnmOWAjw9 6oAIxX4pfyMaL+w+3ruxJ9ArTIV4gZ9kS7237wTfJSJ/6MSXEX7F8VCD0bbx4S+San6Se2V9 BDuehoiM3G/rJfR/t5EYkRMmqvl2hegyn6+TVlNYseWWZLjUuHVDFSMyqjRwOOGbZDlPj+D7 9UT0JSE+qdrGYV/6yj1nV76WcMq+hAvBaAvewF2auZTKtcIvz4AoIxeyBjfCJ5dhf072z7t8 yt/PH1Eov3xXSvs//64U5f/SLp/yh6eMKH98yoii9b/i9rzk/+T2fKiO1E0FY2mz6mnOS9FN 41HOA6nc/Z9fFb7GHbtmrdUEHoozbrg+0v2shPVSdOArQeXUHrej+e8qW7YYCp05pSJtXT6C aD/krYvWlUO3z0TtkOaTrerKGgiRe8+0jG/YnRcqXl1e7nk1BQ9vK0H35DTeTDTKuq1TI4BL 1OHTEDPBorJKVB50jcf+ehfeJN5/57c1GRvIbfjj3toqevGlt2+eakhzSannr/SSQGZEItr6 93Sy33U2X3jXORubqpzUHX5ImSdeqXAVurz0uOqeiErHh0Ol/l6Syam6QpIomXYPSRmZrPB8 mYucG/o8tZrK5S7DNk7Ny/SVU2X5RKtzmcaGDnnybxNwLc+FO4i1QmO0S5eJWFEZsvUPMwWn jjc2KOV8vTUO9MLwBKTwWVMjzo+4v30nan/1ivRa12tR9Q40lahOQ+uxLTsnk13JmEeUygIF /hzXd1wEh8m2WOYKe+3lJaKO2hmqLpdaxbxtRqLPtjAUDFsPbPGI46qgb1jPsNLZeK3dcN26 /JGUjdcMowK23xC9uj9qc1TSl79ufVi9Kff6/tcrE29QXSXiwLIcaduNl434z8vF4wPHyTVW yDR5w9iIsSblNMNc2l0aTT3VWGmUnNEFJB+xEzDO0xhOlTSSqHRJvGErH1cYULr5MSYuvvJj KZO+0cJJMxPPBzfpJpeV055pSNzc7NhyL2a2yighgkxJv9HcqN3ujXsk1Zr3cUN7irrQdznS 201rV3RuC5oTQzaEPpTSuLLp4ZmA4Pv64/KqL9aKJY+WIPNT+A+0n0HAdgfi2ytsd5AMrvC+ dLxz9wg2ZxNZQ6nd+Uz9tJjM/uaJCQV6henFcyPL2vWU0GnJ2g8zLTtf8ycYS2H5vWm3dTMS cDSK8k3PSW3KfaGChkR48Iq3dTybC3T5vatvFsvZ3Nx+p13P6+TYu7itGy/dvX5eziBK2WDf x3NvbKvzHVWnfC6LHTCIVLCWKF3XHjlQTEBpTD6DK/S/2NMzSfX9enzZm0LXzkAGWQ2BpTmK eeAey7g8tTE6H/Wdz7CHlhj2blsnUglzgxiWUHqDAk/0NZnesJ0c8kpWuv/7jGenupN/h0hR FHUgs0zae6YvK8el0XxvPCmC8TxeYr5N0FaOwm89e1wEuQ2Juyzij4/6kuA4f2lvS0OAVb1R Tml4sdjX0ExEP+VEVLJZbKDhXzNX3ss1Cx/wFg93HG+PS3C+DIJx0cS68L0FzUSzqTrdPa8V JrUGPj7Y00nVw8XiEnElgqmpYXyhb6vz5qsljKmhGJnG8rZxmuDGu4ZKZWdvo3CTYsaxOP67 VffigRkxY7EgzCrxk/0wZPWVVK0s87MxRmufK1ZbD0VhlDcauW4gpnppmiu3nztvLylTfVH+ gMBEII278/AqqeGSo74+oonxtU7xE15ObWvGuN5RKq680OLuSBxpv0A5oj91mNnv26QCs1i1 8+shJxe/+u5XK/lz0rOs4qzHY/RW0mHd5ZFEIMviM98ejK93ah+puNpdEK7ExPjbU03Hp31K u/P/CnjVR0muX3awQrHInlxATEyzdTvWpxwRbRfPvc0hTSnc8O4wOVl2OxpeGobgUiKRjAok E5QpR4npFGE3S7SCfm2+Z/x6K1isNH/A8tCAaqx4D+8ymcvtceM0YZKF5U3lcBym8m29AeCB hpkz4h8MP6JQpzenz5nJvCIatr9vEZJ8fLw2rkQJCV0ZWXwyUp55N2sZWy29rK+Q1BZJuibu LAkr3cbPpSY6RUuVDj6rYZo4k7phQ0jI85Bc7nfoI1PXSz/dOKW3qvXhtcTGQXHjWEM/21eS 6wYnmJeuhuwhT1nomRfJ3rAoUozwFOZam6FZjeimXhWrEhaP+cwvhtt+AWg0UKl7U1RVeTJM TGf9lw7Hnnie2t6PWGTnZctALcOY6watF55MXzM8m8Wwn5CX7hzBC1j17RDtLxPufCKtHmfV 7Wr2ssUKugbCRfmZxmK10wbePBkuO5aEP+K1Y1XA8xIe5Oh0Yecz36Hg+v0tCnzPkiXHpe2T FQqaoeuaUzu2GyvF8Gkmvd7EnYAfdLOo+3DoCzJ9v8ahDSP9qz4/NtW228o9R9921axZp3FK rIoWtY0hKiCs91p883KNwVObviZ/eS+5fvqkkqkoESkXI6GucCT/eANmZcvnccMco2byV+KQ xLc4jXT0+JPW7RtzfDDk+jXnXuIoycMaEcfX7eCbvf1DH9XlrPF1WR/i9sX7BwglhIfql1oP r/dufBAnugK5dsS3faY9MoMhSBvLt5i/4X05+wS8hAgOfiB53Fln3PcXWu0KdOnUbn/U1Cc/ 36JN+GiZc2Pd+YuPJNVz5DbY8RmrH02f2BQIzL7BA8wLNyh8s0/7Yon5D2+1A4QSvd2vV4oM 73d8Q9P3mDuknZSgtic/MKvCbs0j9ytuX3UcR27LljlNZSNL9M/Vv3tbvV6q+HBHRECTBLX9 +mG5e/XL1w3oAl0Df0k+iNRgMvmVe3XIwN3TihKvHYXc9nDHzPKePES2lOfXFdBaf+QozTh0 34TzkHDXqmMpbx/5ybuf1cG/Lbxe2CMlmZ6Eb8y7SJP9HHh7+5CbemypbLJFjFPJD70s3u/x l0aJm3RVftwfSjJ6LUK47XJBZ27nkWrFB9/P6USOHvh6s5Np2rb3YnGoK3d/6sfXFtFzWzPv WbwZVl7xdDQvJcbx6NqzIy++ljh9yF29aV10hEaNsf4HUfmvZU7bf5DuiaI0H+82/VGnLjdx eN/Bd5ueznxek3KvsEJEZk+vRHf1swteHjZhwfm5rQOFWZn3NX3VRor7atpH7/h4ada56WLf p0+ouaEyMrSNBiLvWa0+vl6uP578vsCSb/J7gTzGrSBx1feaPTT+IBeM58TR+s9t5niNWrIH Clm9t1phSMwD+f5p2u6UR1ygBbKx72vokFBTWCXZZ3eXsUgVbg7tOd48FMYli2uJNUH5aLSW mvCGb0IAJryNvgjaB+TMF+RMFHLGDTmzlut5eON9KmN8HXreGUHbhpzZhZzZjrDByavLcwHR FGvHU/WJdbEDytb9k3vsr9V7Ks9MDWBkMcpmVxGvt69q7O2s5gHiudYaZPXBjhy/smn2a3bA /Dc4rcj+yV/x801pVK+sWRVGv8agSXR4DQL+MSTl6I7+iauWL2qGEHXYae7Ge996aAamhWS0 Y+yLj7vH33owJor9Pje+KP/W+DC1T04Qe5R7vGFS5QyvffvNJ28v9RRrwPFNgAOGl7wDP3AU O9xjdV5IzRrdeIufO/3AKzxZwfJxL2AzPv/K3LopRGhu/KsPkiD8Kp/fX2rX2GFBgohOjad5 /BUuzM4ralaCM9OUV7Lnn/wQ64xHZ2vy+97TLB/2Fyw/tMV4RZOFwCtr5y3VPtzkgw5Wkgpr sQ54FJcV9p48WGqPxp/kRQZxY7NaYtu5AFNZYMDotTJ63hONM+GNdWT+ix9op2j9ssX/5WtI FNL/pS3+b4/j/JufRqL84dkcyh+fzaFQ/ze9YhDGesWg0aFXV5gilunj+DErXlcLu/iKgVhX A0kmdUxBsCSN18d9PjbFXsclWJv4/N64aVy6mbGHWGwoJXnWBE4oHcUSe/cm59jwUSVh8Xxh LfT2CSNqt8krb3DgwiqVLKbip5wb6EE/8oGWKb7lqbeqWhKigFsuzWsbxDMeRoVUt6ifupVK ad4NXBNYd51hepO7w1Z330lMhGM2UU12Nr95WI74TafbHNqsa0wNVNUcg3c0dygdfX8Nhefl yTw14hia20mPDxKgPUMzBEiypePVtfc9JymZLwbJ9UaBng941QKp1fJo1hd3MJaB8boIeOnt T7r3zR+Wq8ihaVSMnNg1fPqT4EBdPhAhjUbZ4CU+JJUV+uSXY9SQWasfx/uII5mBc8JGcjXT 5Ey5owdWZTo00igYFbQr1vZy71ssf6DSBD4j9+MT7YHmvbp6ShUHzq515FEyXGWR2XuoPL1C tgQa+2pHydb2414JbVbhhlrJAvrT+aZReY9ULCc6B0UVX+3C6tpVRGjRlMhTmbqXtIRPatQk 9GaVqRrLh2yS1Xq3zOBSXp+cCZ8wQ1J2vMDckDFsVLpufRO906s/LYvqI7YxtDiSoCeHntW/ UhFVEVBZfnB58J4ru2Qrkq9meImUDuwQ3KFcz3fc0tlyeznVrqK5s/rG8knDvzYI+9+KczJM GmL2ljUyo01l+u22cQk/lCq/t3y2V+Ksg9DDk7MNu12VJ/mH+6hap86OZ5u82L6ev2/P1RRa +lH9wzvUtJf3k4dybHalYSrwE/oBZUCakpEcr67yMxAprkh/h95I0I/acCUJeREmNY3cmub8 1cDTP1DilgzyXr71xZzA3qupLq9ncLW8t++GY998lSNgHE2jTdITNKObs2xdR1rqPs6Op4dI nm/TUt/gLpGibB/+Xrv+zMxtM3SphxS1bu26qeqNpf69ckqT/l0U8Kjrt7KNX668adYvKbxj cPx0/V28U25euxx6grqPgP+gkm2KqRQ+qFnRSdP/ehAncfT8bv6nNyoPnK7/sC1gzaWu5PMb sorWrEx+c6eajnqy5aJcv7/i3DFK7jNji5Yfu/bd/dC59t7tVLrzX2M33nc+evts84GuGM9B 5PlCqe9DT98mhEcL0T58Qmb4SMl4Prjf5TL/zFNfKMa+WqiLuQvjaS0Xl/UCa7D/6/zY/flt ikRUT7wF5ra8Xmr48skSIHRdXNlxhVDqhVJa6Gh6ly46g0w4Mj4zl8t9Vxs41XnMOIceT5TZ YTvQj/OK5N1M0Iq3/ZpQtOou3x79CMVL46Jr/dVRt9IjwrfMXzSj7lkhIDeXBjzU7Z6zvL1u Q2d2BPlGQuKYzCyCssvvnJH53DaM/M2+7Oz3duap7wBbtb/W8J4l0965bPZKrE2YqJujBtDu HVJrTmxuvEGNQC0bcBOI6zv1tBSxdrlhAtlGvld4eexwjeg4I11hFtlPHULkR+B2kKQj+2cc pAS47+fNqt3rOWVdNCv1IGti9eTgBz8dBbUi+dcm78a4VRUe+RTvXzalN6Z8tOj+zXdxYd2b rLx3UW/daFv95r3o+HYQ8F/Om+9ATDF+skyc9xNfrrD2toHa+JDDZxEFzaf3OWxXUJurks5x 3p1utzVfFudcUuqcjLJ33asUwFh1WP5QYYe77AalEoEty3iUDFo+ETA6e8KqqQ9KrqVHGg6p IVDrFA8e0Z+TFpwpzmi9vCLc32bl4+dVlYkfh2YknniGk5IyT1eaFbXFVpBdben3TivKPnuS 1sywflH3vT9FzrG74uYm/o3Cp2qafdPvlR99FDlh4D0YZGdRJ2M2flPm+mb7VPH31a315PZP GU6q2UUo5dS29RN6yy8JZmqW3hgqyjLcmNFjtObduc7hhMtONyrUuPvSsQjsqP86nk2sX15I Mdm2LsHrPZ+6P2E6kqAFBr46rcgzZFN8KzDkqALxstog9u2Eb8gNE5TVOlul/UZVl/r69RSk KCJ49wINWDlmq4LB9FBJjqO7h3KV9f7lvkqSEw7ufGmvRIUnTjx6Rvcxj8sXT4lyPHbVo37d QN4X509D9Jt6Qghec51krayq+vtezmt9qCjnrJwDJEn0wwGlnGZze2NVBzlXf3wK7/e+RsmH 0S+eT59Jj3654sQqBLrBtPvyMrNai/Mtmnoy587omq4oe7392ugzIaao5N6D5QoBaa1rJ+4m DsdSkVH64g8VXV3gpVH8FrdqFeQM7HtURq36OhTlZ+Y+lY4aUyLPlfZcR1qlrpY8EnZwxq8e nu0pLRWPxeX4Yz5ZyqoJKk7pGVq82XXIwe2JQkvxXwFpXdVzvhYD7oxT3R0Z1uSCjMvvLxj0 8DllvdtUcsl9u1DvWbkKreTWiyJegfmMa28jtitoXEtWNx04K7ZM+NrVxKmnZrWZe+jet1yS blTmtrRuOyjYoOijeztlXaU0rDnd/rk9Vn1i3+58CaLZns/3kbJ/xcxrPO6quYm6Jcq72UGJ kpSvL/XyDL+EQ86AK8ajYgaxydl2SIjvpPQxEcCQaTsxw3c37R3yaXzzVJMNWm9HhPjrU6nV Rf7Gjs2kB+bX9kR7F+qi+nseviuWhlmEyXcMp+bZT53dKEp4SJenhDeILftYStdTSdleKDGZ 8qIjiLCz8hRx1DiP95bcsNjpJ6/LfS+21RiaeVxuiLrdnmHs6XOq7KJD1IuR/vcfcXx3i1qi zolIw8X87bqcDjATNW6kvZEb+ub+zP3FyJ2vqLh5j4kzYpiO8YYJ1ZMrVHpeZG4s2aJrxf9t qP1V/vyNHjSTn95BqGlOFZd0u3vaQCwpSkq+uAS17nHbynrkcLtnvaYTkru45hjRxWrXUea8 oTllRgB1581Ru+cbm8JkNDYJGSuMkV9/T5nFexoHPSyLe5Ox9Rs6aE2lYPvnhuFjtmfV1zJS Rj9PDcmPma97//Qh4/DKXWed9l1693bd6q+bma93rTlwtxzDT6xuEqQU9c8POH+2+/r9njGg 7l5+BAUInL4egD04dlpe8/UagfdpgeZf8cLfa3GJ8ysOHb9y6VnOd7v5Gqw8MuwjBY05gtUE LEKrGp2Ae7b/4uFwyt+PlZB//SEDivb/td3ov7cB/cMzJlT8nzagVML/grvPW3zZv0BcQmZ9 kjO0WUf9qN7KM70+r4uE21YKFvKoVAdKA/0MaY/ghBjP0Zcq4hbqsui5Xhqh82KVUK3YuF9w PsZsKkBt2t5JtzBjnXfpkxrTm9hnwnJd4zRrcsmH/twoo0rqRVME7FLBEQGhwnTkstUmdV6U yzeTEJYvaLT1xCKuom861oPhWOZ2B3rjE3ddscxtEQb75WtUPg0ke+8rkPUqWJMRGC7Hb9kT LMiT1umuxJOa2q2fkRZugkUlVK5EZxoB00eUjD2niZkJp0u0MukRDdopYy3z3br+zKNiydnM EzKpIc27Sekq7bF3MSqT3TqYbDVtHePGr8aCvU16ObKl/iqVHYp7Nmgk1L0upekoB+iXDA+C HZWFRwMcj6gpp8pi4oeavyhlW7ZINSP7wU6PxOqcN4Z4mxrrgdx+cJCha0k68z4BuWz4OIVz L/lN3XmC/eVJSZNLkSFw5WFiq4J6ZVxjRLKTSmF4vlak/pAtQvj1SnO75eQTCVb56za4ODF1 X7rZRKpvsLAlHXSyG7zKMBN1br0nuNllHSOAMtbybXfKOJOx1cTBMErcb5LYmuI1lVd/2O2y y/O6lBvaw7eIpTR/hklS10go6z75Z9Yj3AYTMmpCStkGauM1hVoauYeu83phB0ntcUCy9tr7 5sPk9MAn5yi8ze7IcWTtcj072wCcn9h08Gf+HMf15kExR0Pc14nLrq9YrXfHgTH9aIY71zDu CKx0vCojk3cnJX3SKZp4sgzIxSXCC8cpmRWeA9B+3qNRl78ib82RdOMBmm5mqCxZ+/HR1zFV qXISHY0q+6iT+plhYkNSGSCsoTRdQ7EDi9ErSL59Sqlmg5hC6ParRWtOfvYSN8Bj7Um0Cn+a rh8duf0u16hVcYJpV5C6zh2NeL0dSEq3ZVe9FMnxYXV5NVr2WIyLmA59Mlm+0euYmKSiregm LefK6AKD07duYANybB7bb4nZdJuSVfjxVXpDBlhW+fXMJVLexsdWQ/fXBfjUrLBT9ZkjrdtW /tSdmHH82Rej3BP734N920PN/dasC3r6Ovtr2JuDX99Z9AxLJbRglekYstz46A04zscKHC6v uHZIGDvD9Boz1VGMDfxwVWXQQznfu8sfb4GbeCT/0rwIhtboWKc6uTVIndgcIbZfRrc3kbdo tVK8SO7ddPHktNM8sDm13dfyZJIbI3jOmsc2lAvrJ2aL66jWOG+Woa9KGr8nV+NfXnm3A592 LF7QeHL3u3x3lx2Bjy1Mqa1iy4O9U30ORiZECL3NfdOlrpixW3f/7eh4HIOfnjGJQo5Kpu9t s/F16zl+76tg0Y6nmZlJdw/a+/iuf9XgZ0bGSonkuPBsYGJGtuyJh+eYL3trv3ugKffUtcCo waKpECBWr6UlTRq+YwM/Q42YvB9n3wX/EatoAKP5C8IqLpkqX1A4f1g0+s71vV/DfbMkuyI3 8ftumdpvz7MpeY4fDfNfyy2DFRUUlQ3je+NgJH+rVKx7j8LFLzGYnGdVBWjFo2DtdZ8tEVrV /lv0K4MtXBo/PbGLN29wTht2nVWMqXr8hv8a6XJp7kesulg28l7OVfe3ItvGqvpM5hgizk86 c7DxTw5e9V7p3nfLe5XSbX6lz4Uy5DQjM3d547nX+yyvNOcofrwp2dUi7otpfXv5pDnduqxm i5laf/L9lTirbASx1kZDvEX380GpSPvSCT1qhNkTmy2N2tCecblTcDA8Tl9AfbpRu20eDY+X QvCVdYzobAN9GxlovCJX16rgO5lBcbtHC5yKl3ls5RFs00elvrbKHd1um70SBcxJwOWmjYxm 9yEvjIvJHnlhNPzmczhuavj8uH0cliBoaE5AycBKkrCt1cYy1FVJuBpBI09bi7hN1xIbq3nj xey4a6purtz6oryo7MchtRlhXG4w57cOZhd/6wAtYy67YYdbUH1SM0/BuPKGoC2hR3ZJydBm EoyrjFc7RvjLiBb8lTW4UnTd81VncydWqI0zdpbl83VkI1OVdTfHvDwose6xvoS0lnvbbQXJ ztjOrAR35xPzjh6d7RRU346JjfNF0Zqip2OrN9wzaiR2OxcqGNjrGyZpVnG7TfqhNldxp/in 3e5sX4Mw7lMa2OK7/Hz7raD7JU42qRJPY7imxRNi7vmbHzi86anFLgnTz3snl6V51kknNrZJ 9Eym/xXdqjBNSNma7Tp43ftTYkqOuMQHrz5S8pMnOlc+73KOq6HuuvCdYiF0W5R3b3ZQbmvp tZkhLc/VzEIs0TLPWTssnWnNb5gMTzb7HPF0eHD329lnp71c+IWt0pBu94IR4ckOG8DuQC41 fLLs9vsP9qzn51LTG/K9f/gEV0RDLtIlcMZQnXHKLowYrI28eLX0oaAdn034HUrxRDZ558Bx sxARCW9j5a4TiXqG7brJ18qdJq1Phhomu11ri18OE7Pf8lmNglqdKS11rC1ilpxyCtoSST1L ieTfU3i95/sTYm5dwCe3SUaKbx/u0CbN/bfWmF/ffcbqnG/v3ucPO/Ievr7tNLrzpenjQ/uT T5Rvk8+wf5VLjBfydZzXvr1K+fUr3R2yh0OM9Cw+ip9fNbfBNl4NyVMwQtr5jAeGjsLk3Djx wqvrZFRQVhj/ydITjU/CWoNsvZRB4zfPBx27Z5T4Z07qG1J1N3bl5x535dGMyjzx8fOs1erV uwvh+1sw9575yh/0eeT9cYPIjs0+z8czZV95PRUL07d8Ue135oOBMveOe70yG4uX3z9391aH qMfzTXId3vxn+vZnvJTRDyV+3CbzF8/hvAHEsn0JSJKcd7Ga7tejY2sLP6z0/mZOjNIwOh98 Szbbq+JotefjdckRo5flC/gj6GeRj7WvbzD2z6+Kqnzre7BmyoJGjTg70Hn68uV3a40RUo8O fj2bM0POUUN23rzx+K/2e22XBQsYIi4Xaa8vgwgu/qlGcvJogWPxX3fDgr8eycPNStoq/pgL WfMOuUHN1+JedrdrS4XHdHddtFz3tYa8tS9nHh8/VBAyMZRY3GGxAtdn8LLPAVY19aoO1+lz CW6vUYrVtcXYILDUtKfP7j9eCQ/2eMP95EL8SsToNyT8Mle4xtMk+3x0tOvTmd7xyJf4bVxP f6Ae8KE1qBbHFWV660bK9Y/yPanhjY+s8KhJbKzpwekoI2v3YEh7BLl7TG5Uwh42mIQfbdaW 8w0ePE0RqH5kG+MP0HgQEXwhYvtsciZWIR7yfN5iBegNIfW93jb2jK820kCpijX1CSN4ZZ+n 8zQf227KmJcJkJIPSj0BTNFmKvke+/L19KPXeq6tVERlU/nkt3Nd0lyGi+Wr3B3qOWHS3Xgy Ledkr6tt7SHFFOH2ThqCZhub4kl1MKGWZtKOX+P3tFv2KtLvEtRqN9+reDQs2Qstpiboairw fVet9ZoXJltM/LUvqOEuoiNrC7zXVr5N8DjFm3dqb8lp3srTe+taj21qU/VtOxZ6Elc8I3/N uWpmk9ULRjj1sE97Phbv0mOwCUPhGnqKmkA8zXLCKeqfD5PvH0/BPcHaPLDXQ1uuSzGKGdgm GwGieHu7X30/HP8KhzXlwtjIpq+UfbCzsmqX3AR2j89jHI/Uq/EA+YEJXUfH8geSchGyScd+ KOREy/+L+9TUn09uE6kE6i9XBv/vPIpCxf/hYoD0x4sB8v+mu9FM1t3oFnP7yQitoqv13Qs/ 3Ys3tTBQfK6p4lHlDSYazSmpZ6VXMy1++YkzzybJvSf3GoogCeKe8l5g+3BYHBbTXwiWqBiR c6Rqm2Ow5CDU0ecEp5iSSO8UcZvZ10XQLirrIiZZelvHrL2hTsnoCUFw/JINaRJzhMk9S/PH X5ot7gztZKrOTT//Zl06dKhQ0Sbh64sjlrhZ7ZZ6o/6KFDslL9FkGR8p0WT7rDlxIxDoPq7f 2Onzmet4yzxWM8Dea2jNFryn+PlnaT7iSAcf9MsOTYkDcEN4pHCzEd3p9sdEuOX2w8eO4gaw /HB0v1a6HHWw4lxGmsCyBozkRykUpqW5jzg636PZYz/TRxgm6m9B1OE9dEUvjMUPtlQJ5bgk mRBLHIQIxN4N6imCQWdlVg3CkuQshJyLVindl15OTIQrSIkapNZZ6ZzK7TaR0BhKh0k6Ke3t mNe3kz1Rll7ROddz4Qn1MerU/PQIRufZs3hdo3Xhhg41+Xja3Mj4gYoNRvOV8WN8clUyVJ7s NzW9yLoNzZNNofM1b649mby5HmVXsUPI5C5T5GRF/dvXjxUwVrmARuh8ctN1udLtYvu80E+I rmXP16MFwio82xwbvj3y2ueVxKd48f7cF6zJi4xVKvhQZlnEmrhU3x4aaMTawedcDB4VmTZK vvkMl7FFtz1pxG/V+o0WThs/ZPzYuulD0tv4wZqcqDiLGNzD1UP30W6EdFdtvkTkpFOrJb2c dGjSZ/jgARsFh+TDdqtciovrVQv6WnU3nOLr7pkO0BqyeiBq6xTtfDJ83f5NRYmE1odb76P+ CmnnR5n4M5PXVJhcPiddHeyaucrGq0eDkMEfc+818v7Uc9XjTeKa8Nz5onU3C25vCHnuupmU 9KG4/q7ZFuOL928JE5Lywi+WcRWaBey7ef2l+omUsoIb2ydXt90f9/1y3uryO3J0UnlYsVnI +dP6hw42V0cn+h1zPz14tk9dKtTwwuwOlHx/cMCKIfH323yvqSZ1jG1BvZCa9z22xuL6sG7o jdFXCS8NU0Nz6Dve56d8MkyW7xNkJoU/C6mvv9Aw4SYz9NexQ8A5kSsr7si93DRWNtreJv9F 9GmFn/UrzZa3/bwr4EfDNNSx5yPNw6w2TAaEKbxY2RnKcI9TReG7jsJiGySMPX3Idy/KleAe SmHdbNwfteOTOx9KdgFeymVXdJKdM50GU8P0+5bP1Ud0OIxhvfnQ/hVJ+CdiCaURFlbiSgmA j3FuKSn9Mf2ZmJ8crCyASTTrFINH+op0q0iRkakTEj7RgZfjGgyq+6wOZAV6gk0uFNpwovSy 3eG24sIbxqZ7hEq3KHDn7ad4xqZnN/rvGk1TU3CoSUrIDQ2+9niIakpFljhl8mZaqmXHPhQR JGp4yD+Wkht79ULDtzR9rJ28Ye2tUyTvj3x8dQSTN4oSnTM0YT5xe9eyqlWHLRDrDLdoUeRF XJfJ5VhmWh+Tf+MVYlYuYbEK/qyAy30LcMPA+uH0o7zmQ5G2p3TkbXX4FC8Xh44WndVb1YVR ye3fPRbwTc9PvkwvaPv2kU/PjcDeG2Vrp6Xsb1yl+qS/LI8kbhtwF6D5XZJHRmqkjX220fMb gVdGOu513E4y8VPNzsv97DzO7Wbpd4u4hjRVPLbNdYvhKRfFxGSTkgunv1V91ULv0ScU42eK jZlXwNLp5Mu6yAn6BhsCre+h9NH29G7LI3wKUrrJM/12I0I9+sfs72rFn17/JBan5hmrd5jL TrgLiE4tu7rqOm7EfdA/vFgxvXHEeaYyLi3asVpRQvbhMA//8niLJ3ze7acQNv5iRN3L3X85 fHLz5W4tzhMuHhPaQdCuF54/ml4wcdityb7ull7ZFS8X1yLDYHXJp+mPNK4lOLvyFtyqbXPe dEBox07zUL6mE3kG5lMw85IKn++U9cDc6M1lJoHCx0+Tph4PWjqEveCbak+eTbj1WM5eRVgp I+n0RsGPrpHD5lpHM7F1SK80+wQxxlGXhmPLAps0McFJXmXL2/K562gvIs7kv227NsUsL9mj cOzkfuLU1FfhCI2NJ+TfT07T4RH86rfun/mAS6I/1UtSJ/udoFgfsHuYmb8qlNuMSPx0b6eW 86t1Y8iY8Tb7YIdMpZwzF5g+SXQ1U/nQM01m8itFxoI3GTW0ifRvW4aZ3rAx5LWIfs/H5P1O O7r2bGGoX3z7+T7ja0s+oc2l/QMcz6i7XKQQANcmjq61skynb7oS3qn58YVGwipv21dFpMDB 1cUky4AnibHN/eeMLPdoqikLnhlJXmnux+0RwdOklp1X8F7w5vQpqfI5Mx9yVoJwRe4q48nM Udim2qOyfJqv9iN457Lur286cucxOVZw1IfGdWVq+bghf3YiORn3xIFHt62WPlqdXHzIedlO +WNzyZfuvDaMLQu9rr09TSKp5wSfc9r01HEpuYAc47b7e2RNZka6Qx5n7eIrqA0g6jGL4BLV NZUklNKY26m5UaON9/+6XU/udfb4mk4l7N8ugm5yNb7l2oWw3tNHrZGpOjr4VPCQCnRdl2Ke 7ZkQE63sfysQMb5vo4jaBlKTYdB1bLdYwu4LdxrUbl8SwrxUpFIyb3xmvGnREFt3ypQ/LnG0 nD+Q99Rpmeycq1ZC3JSukWvnVrlYfs0bHHayi9vElxyZYcqv1iBpriGrnyeXqBWaPH7FbI+U Zaf8XmST3dYV914lUpJ7tZqGxDc8lBnW3rpsrH2787zlwNHeHmH6XXodHSNzwPj9vZZlx7ts XNbdz3VpiJXq8Q9Lcwh+H/5m9W7j/cYuhiNeKc7RDtBVCKa0nfReadf4N7QHl5Ll6TwNNUnZ /N0vQo74F08gabQ/7+l+PqdLJJJ/udtLJf7P9nTUhbuy/8l2jfSH7drvDw8s7gt/2Rb++oHE X3eIvz7I8OttZBZMxVH/8BtOVJ0/bQ118P8bnlImsn791rDEgFeldspE8FJqvKFsjonP6yLX YT/u1GEFY5mGFVYUYUnbI6TS2D4rslgQ8zIu9mHARUn+ogrl84rB+nsTRVVxvf7k2g1eRhhc Zzhe4ibBm6/fINxeZ/3HVcYjdZdNdSWUfXu2TQ/lYaWo5Pt2WMPi0cLtqw1WirryiWWuhc1p DF5tlcwMay/al3L1nLDk8PXnY3+JaUi6zZ7b5twY2MuT7ugjef5lQiZWR61zgnTKuuKcbCk9 y3dSv6w9WCJpqIYmrn03YjShTC6nIDc5q1eLV5tb1vl1skyxD9bE0pP1NO7gfGJndnh4Z7mF kXP2SbuEyru69dYr4vovAYYwXFfaCvEe7D2v2n6CvPUZk6adLuKaXcObVfrD09w7Wb/mhDHn taTKUWTS/wLwQSaw9w3cNTUDvF4qbVi0t2f3THqPeX/DsfvhZ+Q6BDpiJU8KdBpy93UNt2e1 vko0SzPu6rAsTBG+HJHvdGKKmJGc87ZdEpm7XVgq+Y18SbYJucNfok/JxkF0jeaUUmsF+sq1 fUPpywnkUWaujCay4aOfpsyb3I/ZhDHvL7D6LtrC1zZqvZTmy/iGP3c+HQusGS6rgYtNUDBv jbCvneci1vtedDirLr7xpZpGssVEyRoVx3dqm3fdjtq4AbfpMpd/MtJCkXv37UkbzaQ26q65 2nvrey7scouMllOwFh2xy7z34Zv3TufLGhYJ1oWDdmn0U+uK/vItdBRNexDzHczYtEzdydU3 f0fIjgefznk7r1vflpRb+ao0bANSuDJmT1tZ+rM+A5jcIUK7XHxHI8r2qzpmKH1T9dnUoTlv z8pLb8CyqfWH7uodgVXkYTHeNQ8ElfC0obBEUffSWhnZ4vrjGUNvD3TWVKCnCIbex2z6021I qohEzMG2qnO2n1VEWidV3k71j4zeE7e5pT0nzC/S1xqKgG+VepQIP5Pf27ve4FPUxszJ21Sl wDeHRBBwpWel/AmHU8fSv2Xd6B8LrkIP2ltqIvBn7pU6T629e8zjlgL9/PnAdGP0w6p3bWOU CD192x/hytYvL19PL4vCxt87hveQmj1Vr/FdQu/zX+mX9mONMOdKBaNlMvhhxff760utET48 HtdV/HExM+IpuHEid4WchLn9uHa82uNqYNIg2XynbILAe1gnzNyKLsOjH/wst3NWHy0T/87C 6pyEkacfGr1Txxv7QrzbpcTIsEYL1/dgRfbVWAunPbIKlasDVnINn4aHe2PqE5uyjMQwN5Wb NE1f9Zkip0OXD20JvFR1lb1hdEpBmTqqxwPx0sYyVxGogbnTj7Slpl+d0OBPvVHxvvxJliAO xV8zgDA6I21E6IpJPYFFzPczrOI6ZDunpVfOR07dvlerQYh6vrrbhK/rwPrVpQ+dD3PLusgV yvIYnn2T/CgVm8ldjKDFrrCKnfCNi2wpKAMUE7GV2O4YW27caR/E+M73m260prxy8Mo5eVYL E+vM92pYMdE+E+tLo/HQ7XGJM3sI8Tgnrq6f90eNwE3RiaeuknzQ6n6vYr8NeodPz1qm05BG lLXo2XUwNWbmq9nBCxcerXw0nLC56omx0IUu2Uo6NbuPR+ci9rJ8V0l+zlzwbcH5oFWP9e4o 4K7ctuH+yqdgKoq80hc4OH9TzSiWoWSqL7NqVkgq4XQ8X8SzFUiVnREJWTS+PmoZsvOWbcIp Wz76sOjy8JukB/KX1s5OrFt51fVg9fBNBJC6LBE/Hr6prFipa4DSEf6Q+4mCbz3Xdk/E9hsb 4kHj7WXDjescm1x4C/nyqq9cb7sodFSSnoWm8+vkzo+2wWNo201D1iRb1jr25NvU3p2oSVE5 sjkhqLcuF11qtS1C8ljip0iy9Y1DCWJZLnVnT7xBugtz7yFUmwwWxRn4rYnADNMThVKOz7ye FrmAknmmvYeHeNfIVcW6wW15gg0M1h2pFU5P80waXO0uufzZE2y3iH+W2GQVYmNMw9CPk7M5 b1aYu6EsVvda7W975RFtE/Ni3bQ2pv9lztCt3aLbuM/tPzfbKF8VeyWGmrD1VpLxR4fdDa8t O0R/IHt5T22bl1c4fVG//86XifTssnRHyqi9YrnugXWO3WsfJa0wz92mzd25AW2YR2qX/3y4 xzLOPlTGuO8KrtzJ9BmSp9WyjNywOVVH3ppnxL3slH1KcfH59Paa7FXrOzHgcJ0Bv4RVzXph y7k0MUen90Qvl5tB+zyu6muUfuTaGrZys+P0lpq+D3moe6+kuia2vkSQOyhprwZ5B0kD6o9W w3Xfpr25gmEIVylJHPLzWFa48/hh6hor52B1rzHtzu6s08xtRza6J2xR3GilV2niZ1waxlTc dftU+hOXHtXX+0a7bix744yGEWxjyu5eWNY5+IowgHP/1FuViDWsWL/hRMyYzL0E0dRo5S2t XW5VoChmsjVa8i0C5N14Hra3bbOr4Zh4hwxsfnCz/erAGyFvq/PetNr2BD6135s+HnTvxPqD L2aiQfRViufQiU1PRMvn3NPjY4sFuwAnblBfJbH7itim3UcRG64cerlta+VhgtUduyupiNxH KxJwYWMDCr3PAsuljekHr6SmUp1HvFdMW3LPIPZYwPd3PgH3a9+UGK5qLX14HW616botT9JB +/peeK3VztErxOTOyahBJaMbj19GFdknnNr7ctUDxQ1VKM9uCad3ZszMVVvzVt97VmL8/hix MAvOXdtqeDjUQGobgrJboOmToGmt7/q0Zc+L2s/U0h4iK0LepQQGnL5diVm9oxG5oq/+y5Fd tz/33YvaNfpFX+PRQ9978vNrdFudPlkxwZEbjz5kT9XxHi53cvA7fShKyzA7/d1DGq790Mvu dj9+XUKHtlT4eNTn6O5HScI6KfZ3h4LHNDFrhZ/k2dfeOJmbOm5VR0gemD89cC33/mZMtUvn zapZxeJ86XPryqqOPs8TPX/15YW7wdYPHQcdumLu5m74snGrSPH7TVdXX4X/uC5k7zeqdCR4 owCMOEr8dmTu20ttFJf9wxfTayFb3q/UmXk4H5+3LWOFIZ/zlX3XPhmn8T3ZPW77fnJmwsRC Yz6+QUll8vGY0htgCiO3F+FNjHkwQC0d5q9p3iKgXR14WoGhWwcL9/BZhqh5z/9I6LqNeS2j WwluYB96GG2cj04o5huzV8uokylfwVXTadwLqFvbag47Ds/OZqvVuVe+tgsOtedC3GZgHJDX BuQLOmn+vcFZjpWd/+KhCB38318BJ1B+2UBS/9+59amzdH+r88dbnzr/m259Dnj7qrijG3Xs Z0LJEsPHJzHLf8DFMzJQJAIw7bcrKdPstTKuXwJ/7OfdzPtm27k7bDXDe9fKdYOpg2Gr8s1f kOpcp175iz8PFbmLqDbBpy7XcGxXux2hJFNoG3l7I2YimnxQQBa+rZBmKLMstRvOF2Nooi+N EFa5lDURSnredbIxxHmjVn8PV0/aiWPG74cffqvYt/v09+Rze3JfiJLVJkreN4W9eQA0WR/w +YrAEm3Hympbvn861yhPgp23L6/52ImdNkWft2POXFAwPLARbYTNff/9hIP1ej6a3TB/HyGb tnE5ER9hIdJzPE/twoUtJSh+2vzbFHGz5uCNy9ZMyJsNyTucWCUjn32lemiwM0hX8mhXY4S4 QiiP4h0kmBp6oyGUmkrM9BabJWfy8vRLrzY8LblCwaIlJjNZ3dsjV4EvNVBK4YUQQ8uBnxgp 32Fsmamb0SOxG39Urn2cmJk3VV6j9/Zmw7MzoXMDWF0Vvc5X+gk7ht8iBBx5vttlqG7PRxLu eRYhLUKkhB0Ngf4HOmnYRxZqco2DoqvtvIIEku8mBAkOYFcf5nU3DA8JNMuOOrzspvZNSQ2L sXGvDyrXMo4oTtWuHkPcovDUiacskyNEXJRhPZOxfl1rqAX24DvpOyfzb4SedzltEdIU9RYn vh7tvJF5Phe9JXlgsE2G2Lt/5H0SPTWaiPUObtMdxTEBmiTyMd/Ok1rm35Aq8m9oQatt8j83 kpSO44b01WaC38lez7O8Q7O32a40qE2npb3hT0s6kDe8p80Y1b8/NIloINHREhHkWvEo/95n H7dE2oftfnsJIfmPd5hsCQ+Ku3NA8ebKp3pGdkmM6GmC4mx7wbKjd3e8fyU3dGYmpMfzI/9J sS1hD8+r3BGNunTuXtNKeG7cGeGe/uCv0VfEmV+zDE++Lr72aN8bye8rU98c3MR9bf5Lut5p H2nkmwuk1jnfRK2uZt4Q/xEnmFibSit6MllmROjuJ36u3exXCt8kwsRuWPPJ4S/TR3vCz9S+ aX1RdDdUWg+8USlTbiFKqvvqLzHsHzlyP4AsfynNZs8Gs9d7S5UEQvTn8gFbh57wMKXYOSwX MCvZExumE3hwXd4D2hEX9Fa+u1e0VcJ7nYzR4fxIf0JyTqe4MW6XC62LiH2zPe2QbJvccenZ E+WOP2z88TY+JveTGtO2Hro8vWMstslg1UCQ4TFr3znapTNv+4Owci/XmL7tEXPiXo6RqV2L bJfIIV7b5+7lvOllZ9x5OWNRu1kNX2RJumC113e38qSAtOfaB2geKwQcTm0we7ZHNcIEkz+R th6YoJWEV7sM+ptjypLWZ5fWiNvxzloCsQU5Io33pGZzc+qLblVNnlTgbbE2bN5yQb7cQnH2 TJuFspe9hV/gA4dt83ur42It7n9SK39bGOS4263CYq3KxvS6/c2Pz4o/TtJg1BUVvIrQxOYd EMt5Vp2TS26Tsyh9JPTJRWbP86LqrUX8s0LnbR736RxxTRvnvfg0MHXn0TPvJOY8rBJlPO9t tXx/4uRI5HODUJsdbaKaBkd2HmRmZobYWbx/fP1YbWHDxdPj3M+NbvW+OdSgHTPaGfzy+rLj 3um2f12K+j4jnRBRLk9M1zlqtLv6Iu+uoD2FJN/whi5jPb+j6w6fM/tkgfGZZ+bOJF26/3VS UfXQkYZv2WMP7toPe9ccPmF4zSltLyGgIzEvPTC3PmD2S1nw1Vze7ccSLFtMlW96HNba9kVD V3juyDfHQv7QTIL7uvWPr0rVvPNqvlLr3Hk0JDD/XdPN68V3abXLd9e19udhKTvn0a54IqZb vHgg8PXFZSPbnmj0SYltf7epPXSHZohOL7FLcLOk4epsmWrJPBULPimL0ONtyrit20eeK1dE 5J04dRYpQ5V5tsb5FXL07BcD1+eYxyfCik4azHkvCzatOyBY4E40Sz6cmhemVa8ydaEn87XA ussaIVJyimeqy5bJ7XVYJe16QugGJmPjnUzlUvHmmjnLGx0A9YH1/uVejS5pd41UXyZiuYhp Ek6xOJtn84RDsk0I4+x76D6a9q1cxeNx/mR5jZy3gp828mWk4pFHkbq2uPjlMLU5TRM+s5y5 nFFRndwz5l2i5jDjyFeEl8VHOvNXYtw7X6k+9UOMf8d6MTL2XdOgpmdndD8LDDpMaEiPJUtl u+BujagkBZRhViXO1GCNxJxXmziLHMsVC9Ok4wLK5J8j5iuXhX+0GDxSI1V45sh+e8s2G2BC mjxegjUKlVlNa6MR5Xbsr362O8VMqJBBKxaGoW15qaljfs/OOJDyr3KBCFkErVLQqNDpUuxg xaNuiUt7svAhzylYxIhY2J62fUOv3h1QVywWjEe7Xnl68PyTelgxpiuuGhQlIw5afyKojpR+ PCIzu1Unqym5u5R6WcRHKtyCt2lvb2282DMfjwp/S/3JwuM43K6soBqSqwHPAyA4GhX5fpB0 40Bk7qx6Y5HgQ/2pM1rwLOyfdy8/b/IRdCi/fO9Xh/Cf7l50iP8/eKRT5w+3BXW0/7iVofyv uFXH/om+wmvsDwrIHegouKqcbVxGEI8tjTeTEzRnGCkLPfBJ22smp5P/0TBWDINnWCtbCdsp 5ppX3pNB1Fisyk3zrosh74VLWShmdfXKe5ElB18K1SixfpkvPTlCMOO+r8bU8NYzQ/3fC/nu mkdTss9NLCNJ8SZP2Pp+iRu/++K4nMGI3ZnZhA+n5nH+D1W5kvnp74tMajyJErfxudLnH1oe SILh0pRTvbJylMjPzWmrUkeCZC82H7PS+II0bNEuVIdVAko8RjGJiujyINem1pEEH/GTGjW0 myc1VPMennmxt1eyD4x0fnGmgRk/f3pLpWPKGf7LpyTN+HcyRJFdB+6lnCnbS5xdbaE3+QEB tswnVO6reHb2vPX9j8Mt4UC1Suo9fRSi1RBIX5Vmz9REWx1zVhpRzxoGxni8YgpVRgQlHgnF NZTkJCMt5F1frSXs7ZG3sMzbvPaCHbwyxz4yMv75BP+Xaolk3vvfoMtb6wzT42DdwbUWjXUV FvrOD/RvDeSNrLVIXB7xxWog5Lnse2RZOX9ictyQMq/mwL3Vy88NT9kOI+lZ3rpVYSOHTnLB wg/1E+/CrVXQsmLZIeh4XC4ZLetJU0KT8NVYblk8TXEkXommfAsmPSt/K3i+XGWP2usrKtww 9MHojeEzh1S58UJXcKmu1DRRrfoYidjYP4/Inze5tX/9dJ+O1v/ZAflfGGraf/i09h+EYLGH Ck5RXpHssnNEFINVA+Fs6SEsAjwEGtGZDLYgms4BIQymLWOrY1gIPVTNKCzYB6o2DYVGZkCo H05zfUCoYSgzYBHxj9cH/1v9E/51///1rgn4/1bfxN/6NowIoAf/G33q/Lf6JP3Wp9O2EK+w YPZEGMGMNPanR+BILItY0xdKRC0tqLg+wCfSn4nbgNPG4yEUHkcikXAUAgmnBZW1yDo4KqtM oeLIJB12HSst1rHoF3PWu6pUTs1/IbFo2fRQ68XEx0Mmk9kQhUjEaWtTODmBlaBlRJsEyUhi 41gyaJMInHqqNo5K5bRhfRyHCFFScRQyAaelpY3T0uG01oau11kasOq0yVo4CjSwWHgWJ6o2 RyttLSrEYVFCFv9FycjQeslqrUUk4MgsbpAcJKIOO/+pAUWbXQ9xWMQQORxYVOzWEAXLsiyJ yTqLOcSZCtkD6pGVc+zA8sX/JP0f5UCEpCNT2JIRWD5ZiA2KFum3RMCTiTgdKoWtLitnsYAU XwgVltkWDcNiwVZcG/9bALC7wLP7JXEA1i8TUHFUIsdYLKexOLMdrM3BL8Isnn9KrM+Lkv6m gMKAlaisRCT9DF62W/CkhY7/rAgkMMvniywoVI43SVTyHxNbwYUERTZ0ZlmTxYFIIbPVWUz/ NQ6s1hsXpnUTBtM7IiA8MgwaxX94vo34r+asv9stMOLMHH9PFcF0PyZOe6HSyCgsBpoY1FkG UidCTAlEMpXjF5YgNgFMJjR1sScQlm6sySmSEeICUegswOYLsEUkPTjA2zDUL5iBY9EZ08PN GQF+/pFsbhDCdaFIYZcMmd6shW2hjiU0qwhJwN7m0dkzKKdkQ4/h9A85jd0y+ld5frMJ6b81 p5L/gzWMo9V/fVonkv9bImj9J8vovysG6b+3umj/JoYxtNMIYERAgvzXO9b67+lPWbqU/pvb B6rWf6tj6m8d25tYWdjbqUId+bF6YP7XV1bWbMkeNQQ8CToRoOWHQMIToBO03FGhwU0gEig4 shZrbFFZGCJERPp5ohAWTmQya3WBMtYcBW3ToPbQjKWjw06sVlparEmG9SAEBZrB2GMVWmJ1 SKxaApuCk1hsdKCNDStpseZT1mLEmpSgpMOa/KC0OB+zW0D9LCYCgbX+abOmZip7uoaWXioV mouhxUsbmiiorFkWWi7YiTVv67BmXUgryAmc3rXZEhAI0OrM2l5BMutok1kaQQJBGupAK7EO GdIOT4Rme6LOgq54bWjRprJsqMWaiCB7sHrQ0eL0xnpwg4D7NbHMyaagcvrTorDMoY3nnH61 hxbkFFbiLP1/W+nfTywp/nXtQgj8pycSe9Viyc+C/qkXK7G0ZtX/qW4xLbXIv5v+cw7QpEtd elqqEcvN/6HaRNb+gXViRQo7Wv6lTDoUHRwrLWIorE3VLwlyL4Vz+tmOQvot/aIXgZM4IcHa Y1KJvyUylEhQ4GqTtNjr/d+Ohoay1p+WY+ofrp6o2v/ecvynmYa9MJP/uDBDcweBte1labRk Xdb6dV3WJv69LrPhf70uU1m/AvVzWdYmkv5eljlVP1dl1h+/fq7KnOX+71WZTNL6dVXmNGWp YBYQzGDtsv5wW4f6x9s6i89wccosnxF+w7DH128Y1iz5yxXu4gU3AAIAwAfEAnDA3s5Jk0jo n02DMNNQcvEOoYfrvbygDwAgEYAIvKMjcQ2atbUAgIDKXLq+4X4hvW/1GgGAOxjCbfYL3ub7 /S01AWI4BLXf6Q+Z4cKddBsA4F8LlbX9IYTQMp5MqLwLKsv7h0TGWBil7YHKZRD/1OAwb/py s+UaACCkDPXZH0KPCYe7IFUAYNlLiB4XCsVD1agCJLGwAAAIHgoPY0a6BeuuBwCFegDgSQyP YITbXVi1GQDwBIifMwCiVoBZABck2yhiFMKILOaADxyHYVX8i382TjgcQJvHzf9AqoKVAAFF ABtj/66Gsa0GiQEZBfoHSkAJCSwgoZyFBf/BEirDEVxIFJqbhxfDxy+AFRRaJrxcRFRMXEJS SnrFSpyMrJy8guIqJWUVVTV1DU08gUgia2lT9FcbrKEZGhmbmJqtNbewtLK2sbWzd3DcHpeY nLInNT1jb1HaZk/6OhcnZ8DL24fh6+cfEBgUHBIaFr4FWo6joreud3Vz3+CxcVPMtvgdO3ft /is2ISlzX1Z2Tm5efsH+wuIDJQcPHS4tK6+orKo+UlN79FhdfcPxxqbmlhOtbSfbT50+03H2 3PnOru6e3r7+CwMXB4eGR0bHxi9NXL5y9dr1yRtTN6dv3b4zQ9XR1bsLIMCHkKZIAAFpC5vf Pf/jxw8AgKwYy8rZNkAC3QArlBCQ8ZEACkAD3AAPwAtgoBjkBwQALCAICAHLIMsuB0QAUUAM EAckAElACpAGVgArARwgA8gCcoA8oAAoAqsAJUAZUAFUATVAHdAANAE8QACIAAkgA1qANkAB 9IHVgAGwBqABhoARYAyYAKaAGbAWMAcsAEvACrAGbABbwA6wBxwAR2A7EAckAslACrAHSAXS gQxgL1AEpAGbAU+ADqwDXAAnADIz4A34AAzAF/AD/IEAIBAIAoKBECAUCAPCgS1ABMAEIoEo IBrYCqwHXAE3wB3YAHgAG4FNQAywDYgHdgA7gV3AbuAvaNwlAElAJrAPyAKygRwgF8gD8oEC YD9QCBQDB4AS4CBwCDgMlAJlQDlQAVQCVUA1cASoAWqBo8AxoA6oBxqA40Aj0AQ0Ay3ACaAV aANOAu3AKeA0cAboAM4C54DzQCfQBVm+B+gF+oB+4AIwAFwEBoEhYBgYAUaBMWAcuARMAJeB K8BV4BpwHZgEbgBTwE1oHrgF3AbuADMAFdABdAE94C7w/9q/S/+yhgAd3qArLA7mDkEHIM8R IKsSIO8RIL/mAXmwFg4NFDHekA0JUEw84hqAIiiCjSdBfiJAMfMRrIGigoXRB7ygelYE9EG5 AVTnDeUgm0cemM7Od0ExlAe8grXAumHd7No1EF9LFgXngLVwDUB4Fr8EyHu3wU6IZgfb96eA S6xWEOc8yLMfQCXo2As+AJ/D7CEsyOof4hMEUedB8p6DvPQGFAYNwDSwA6IRgsWxZeH0FgvR 9EHHJTYX1mEDBoNhYAS4B+I5C4PDtCCuYbBUWCmsEdYNd0MYcA0ghZAUVDDEBRrB0DgVhDRk cbOFIt8LOrb85Mo5xkEY6AA6g/5gAVgKydAHPoeOtzB12BrI6qwjH+6JwCDmuIK4yqFjALkO dRCNhHizxr8ENJ4VoLGqD41KS2gEssZVIDQKWceOhVESvxD9tVCEn4aiGOoTisvbwAfIOgLQ wdKLAuqA66HDDToiwN1gImSPvb8cGWAJ2AKehuQbAq/CVkJac45gSHuOlAmwYtgJ2BBsGHYH Ngt7AnsFB+Dc8M1wLzgTXgU/Ch+DjyHMEaWIMsQ0YpoL5GpkW0oIKYzciNwLHekoblQQKhGV jTqIauPRgGYuBWhO0oe0Wg9ptQ3SZCc0o6SxvdYEHaxx2gqNwicsPaDjx4ImrEMHNAHNwHXQ 4Qa6g55gCMgEY35qVAlWgzXgCUiXq9AxCd4E74JPwRfs4wMMCROBqf7Uzx7mBFsPC4IVwIpg JbBjUES2wDpgk7DbkI6zsHeQjrxwIfhy+Aq4KdwMOpzhG+Ax8AR4PbwbfhP+HPIbBrEaYYBY h9gI6d6PmEXMQZ6EccG5FLi0uHShw58rlGs3116uQ1BEP+d6jsSwrSKEXIbUQ6YgDyNbkDeQ 31DLUSIoWejQQBFQTqhgVDTqKGoW9Qhdx23IHcAdwaMGzWV4aNb6/V8rFN09sI1ITUACvAlF wxa4AESFY409GAYVzB0Aa2FJh3IClSBP3QI+wLkBK0Q/sB6+AQjm8oLzop4BNSATEQceg5tB M2UVKhrsgHvCn8OruBSQehx7worhR1HbUJ6oR5Ckb+G5XP4oDdCQay9YA1sDjegI0AF4D76D Zm48EAlTgeZOaGUAo6F1Kw9dB/JBY60PthLcy1UOb0aUwk25doPKkAcluQbgSdAKtBxa15Sg 9YoLOoQBLhqFSiGTiAS8poa6mqqKstIqRQV5OVkZ3MoV0lKSEuJioiLLhZcJCWIF+PkwvDzc aBSSCwGHgYCaqZyZJ65R0bMRoShnbq7OKsvRIQT9F4RnIw5Cmf1O04jzZJPhfqekQZS+/6Ck cShpPylBLE4f0FdXw5nK4RpHTORw7aC7gysEZ5jIueEan7NhGzaMUGQX+KCCjAzUAmcq5m+C awQ9caaNZtH+aaaeJhC/Jl4eYzljBo+6GtDEwwuBvBDUaCYX3gSaGYBsAGZmqtsEA9B8kFSN lnImpo0WciYsERrhCqZ0n0Z7B1dTE0kZGTd1tUbQ2FvOqxGQM2oUUGWTAMbsbhqRxo0odje4 AJY6wF5ck1pnWno7FvDyVMX4yPnQPVwb4XQ3Vh+Cqo1r5Uwa126fFVNXawernV0buY3bQcDZ 9RRg+SO2ySLWxMSN1ZuQsWsKm1wUIhfdPisJTzMVC8CximlpKbjGUgfXX2tlWGc3N4ipupqV o6sMJLWcaTqOpYajK1sDiCkopgkJycKx1OQozJAzZWE8A3GN3HJGcv5pgZ6QsyTSGgHHbTLN Epa0Uz9mAEtTXJqzq5xM4xpJOTe6iVSTMJDmuK3Fgoaz+L1GXa0JK8ixdBO/wAKA4fsVYPys Y0NschYESb1oapAlkZwFFCKNOG8cJImrXCNMgco6MahAmjcVIoP+uYGQRQMg+3mmYXVZjuBS wMrh0t4BUCDIPX/2O4a+gEEqYN8BLJAVLj9DDqpfhBtVVRtVVFiRgjKGXAtJZsAua6mrRTda yYVjcY1WkMkAe1eokZuuJmRyGRmWl/e20wAvqNAY6+DKKeMAL8lmgKap6tYI82TVdC7WLF/H qoldrPnZ3FMOCucT7M388ka04s//AliRZab+uo2gyH9QzeDUQ8PHFNeE4FJIs3dVpKftlVT0 TEt3g1xjBg3FtDQzOZxZmmcavf1HrJccDiuX1mRllRZu6rmoUvuPzr2SjbR0N38QMmojiWON xmXGrnBJmBsHgknC3dShRRW6RoHHQlsLOLS1lqMJoK6AiCtgBXT98wPg+gE/BT4AAM3vz7HP gTUvoDN01S4oI6ggIygTCwe+xcKA7wDXwGdqLGKAtVWvBztg3xAYiJfwWQCEUVj7dtAbYvAc +k/AL4Oa1sPsISL7b42cyx1YLHDow1rDzQL679CSaPYcXlWf+52VN8qpjwDAd3ueOyjo0gya FsHFiyIU4bs9APCmA8CPMZ47Sy6b7iEAgH3lBV1fASyeaAPAklsJyOMJgFInYIlSBPK4O4B6 +FGgDw1th1GyQD23wELazEm8KVBKB+rRfUA9z3mgnms/J7FoEWFQugTVQRsuVD5giS6FeCZC sAynnp1Y8FoIDyVEC1CPdIXaMzgJtYeTED6cxKJHngdcFhP6PkRnDuGGoD7aoHpJKPFCODKE i4Py5UAe0gLIW+yL69NCGoASJDNyA4RfviCHCkcWbhrEC5IbBfFDn4JySD/UVihlQ2USlIdy dEUnQe1XQ7kv0MKjCqQiINux0mJfkD0t/5Gov6UdEM2Of9ji/3CCtqz18FqOzux+/pkOc9J/ Rodg0c3+SgNiF+ouQbDAH3mzE+j1D1zKv6b9ryW01z8SdCmC5sQv4T9KPEgoPpEcn7P9/jvf 6z/hawtpoYzU+j2h0zjpZ/2X39NP/E6gj5VYPmbDhlD+S4LfBLzhywFv9FpoYw5AF9z//0MR ujT733yw5td7IAbQBDIAfmjFwEKQDjQRP0NsZl/0AYAMmPNzFg7/eSMLhCjDF2AYtLrELsBw CJ+yACMgeP8CzAXN8UcWYCSEb1mAUVBvPazbZgjWRSAG+MqGUSxJQDQb5oaoZkCxBRgEcODH BRgG8MMW8XAAB1NcgBEQbLYAcwFiMN8FGAnhdy/AKCACdmgBRgNKcOwCzA0YwKkLMA+vOTx6 AeYFfPjPLcAYwEdAlg3zsGQWSGbDvCyZBXLYMIaNL2fDWJacAg1seBkECwl0sGFhNs0oG5Zk 00yxYWk2fo4Fo0XY8FsWjGH3hQWMw8K3RbBvO9fiCDo6RHXopIWzCfCOCGOG+UbijMMiwjVw hsHBOEcWFRPnyGAyIqIZPhqcBnhWAwKOfZvdKSw4KjIgLJSphrMI9f5zq3/ebndk+EUF0yP+ if5n2YURwYQ444gaWvh/1jn7M3BQwSdsKxMXHOYXhgtgQpcqkRF0H0YIPSIIF+b7D33CIugs MTXYt9QigBCADgQDTkAklIdCMxEdwvkAxuzbbdsgOIB9Iy4SujSshRIBijAdgAioL0BaEM4G ovGGKMMAJpR82bTGbN7hgAYEG0L8g6Hc8ScvJrvEgHIGRBUNnX3YlH/3gP/ZAwHCOUOShENU OEjOMIhXFMQjAIJCIQ5qENYCgrz/rb7sARPACmpnD9gBqsB6iDoUovdZyJnsFn5QP8Fse/xn 1P9ZvQu7b+aCzDjIfhqQ5fD/aTtnSAOW1pwaH6j1VrY+wRDkByUchGeV6VCKhHqgs2+dhrBl DoJwLG/8x/4JY7datKbGH2k51mf1yKINh2TaBkkdsdC3OdsjIWwL4xZiiMXfny1F8ALeiO0P Blvyrf/Q61eNcVCfLEk4ftvKthuL0ofNh8UjlO1B6GIDkgL3P5QDx+6XD+D5GXV/t1yMPg22 BTjy/lm2sIVRwuJFZ8cfSzIWHLIgqzUUSd5QvQ/bUxYQ/HfsGkKtIxY8q/ZL/5wRGcHuK5Lt a1arEMj+wWwfM9iSsOo4sv3eRySEi2HXL8rMglgSBSzIx7HfYmvmgrT/tDSrf42FEfS3Riw5 WbqzNPdjSxwAbP9Zs6hBBNvODKjMXLBDADv6F+cQHLvmz/G5NDKUIC/YAMrsHhalZuWsXv7p m3A2t2i2NRgL44MTByFsKla0R0GUHEssjS2WvJE/x0/AT39xdApnn5kLHuDI97dMHC+FLIz0 RZ+FsXkvysfhG75g37CFuPmbOortvwi2JNvYf/BgefzXuF7sjfFbNPzN+++xypKewz1qYQ7k +IHTAysmvNna/B3nEQs24+S/au/L9jgOmq+M2X5YtGYkG8/CBEFttkGxFbawjixScfpW+zlP sW6zey2MFrWf3vFhe4M1mqIXqH3YozuI7Y/InxzoC6uBNzuCmL/VhrPbL+qnthD3MWyIRcda J9R+xt5WtgWDf5b/pK0ve8wsxlgwO14iFkYra072hrT72wMcjensNr/CLJvEsC2txu731xld ja1LMIQL/4ftFv29lS0fSycvNsSxiMbC2odjz/w+bE9wZnK1fzG7BrBXStYK6rMwI/6q8VY2 B3/27BC2AC2uK3/zpi/YiyPZn2KWM5YC2JbzZlN6L3iHyZ6l/H+xf8QC58VRFMa28a+x7r8A MX/OO/SfOrEiPfhnFPxuyfCfNEz2zMhkj7VFz3kteF5tQdsQ6MxpzRoD3uz183ef/TliQtg8 Gf+BpQLYMeC3YO+lFmCwV2D/f1jvb22DF1YXzijizAkhbNmCf5Eskj3ncXYGf4/537kx2J4I gCi92RHtw16nONEbwW6xyI8zBwazLRH5c9/CmVvobH9zxsCiZ/721t9jjyWPFxvvt8A3nB15 zJ/zFmft4KxNnBWZsbDiLXLj4KMWVnn/nzOVPYQN+G3+/bV/nwUL/FobsTCCWfkWiCPjZ89R bKv8vaNcXKf+NIf+aebkxHXYz3a/x8Di6k1fGF8+C+vtv7Ju+BLNfo//yP/i3onjzbAFvr4L 0UX/ZbexKK/3gnV82fvdRb19ftkX/r2usDz09xXBos192GPdd2Ht4NjVhx1njH9YdrEFK163 LezKWP40W5hro9myBLBnt22/eZUVc3Q2t8WR48WWN5hN++s4YCxES9A/dlSsHhb3MH/P1et/ RsyiFf9kucVd9t/yLd0n+LF3RCFsXAQ7ZnC/jbbFSGFFH31hD6G24HHWTsTvl10hZ+/n95tu f1uOvrAv82eve+GALqAJHVvZhwZ7j/f7fkpjYZbWZEsWtWBd1hjW/CVmNBdWpV9jSvP/SB9L 95SaCzODD8RfE7D95Ur0b5jOnvn+XMey56/XrJwV83daOttbPuzr3H/F5VcYxrkt84PKvh+3 9N+9hWeNYCAcRIBcIBJEgWiQG+QBeUEMyAfygwIgFhQEhcBloDC4HBQBRUExUByUACVBKVAa XAGuBHGgDCgLyoHyoAKoCK4ClUBlUAVUBdVAdVAD1ATxIAEkgiSQDGqB2iAFpII6oC6oB+qD q0EDcA1IAw1BI9AYNAFNQTNwLWgOWoCWoBVoDdqAtqAdaA86gI6gE+gMrgNdwPWgK/vP3BtA D3AjuAncDHqCdNAL9AZ9QAboC/qB/mAAGAgGgcFgCBgKhoHh4BYwAmSCkWAUGA1uBWPAbeB2 cAe4E9wF7gb/AmPBODAeTAATwSQwGUwBU8E97D+ep4MZYCa4D8wCs8EcMBfMA/PBAnA/WAgW gcXgAbAEPAgeAg+DpWAZWA5WgJVgFVgNHgFrwFrwKHgMrAPrwQbwONgINoHNYAt4AmwF28CT YDt4CjwNngE7wLPgOfA82Al2gd1gD9gL9oH94AVwALwIDoJD4DA4Ao6CY+A4eAmcAC+DV8Cr 4DXwOjgJ3gCnwJvgNHgLvA3eAWe4mOF0bwYynBHqHRCMZnoHMJlhEUyBRcA7KjIyINSPP4Lz kKFfMJ3JZDARXozgYIRXWFgQ0pse6hPM4I9kBDPC/cNCGcyw4AAfVtEfqmAyIr0DIrwxjNBo RnBYOMOL7h3Et1jwjQgLjeQPoQcEe4XF+AbT/Xy2hvL9UowK51TGhIWH+gZDRYFfixAx0jcs 2IcRwcPJII6hfL4BwYxIenBwJCMmkoD5tfRbFYmXVfKmewWEMiK5/cOiItiKoYMY27zC6BE+ mJCwKCaD6AUpHxbK7QW1Cg8LCI2EhXuj/aFqnwBmEMoX0iF8G2kh10JH0sMZEQxGMDdL8a0R AZEMvp9QMMM3kotVikayzmFBqEj/qBCvqHBudu4TtjWUh1URHsmi5OWA7PtwaA4MUXIASG02 yp8eHMnNDIG08IXcxxvKiIqMoAezYG7IrltDWRDkoBAvAWZQVHAw634X04vlHgTLtCjIVqH0 0Eg0PSAiPJgeykAzo0KZ/pA1UD6QISFDcTNDw7ZCpEEMdAzrtplXsA/a25/hzQJ4IQctIlnw Ih7D7iUsKjIYYsTLLjD96ZByHNibERwZ4M0hCoHEZzAZvMxIekSYrw89OoDVmvNYKwuH2hYQ uo0e6gcLC+Ha6g9ZlYseEcBgIiPpURFRTKQfIyQgNIAVe96MCHgwI4wrOiDCL4wrOMArgo5i eodFhAeE8TLpfn4BELOAKCa3Nz08IgDCh6LpW6LYKGR4ANQdk48eAvmNCZk0IDLYm/eXEv+W qLBIho9XcLBvJKQd32IxglVCQVowIiMZmIWcHfbcXlHQWKD7hjJ+QlsXIebfEIM/GjIQC/SC Ijf0H8WtvxWZ/ygyuLwhOAIJmQqKN5R3WEgIJCx6OxT/kNRMFMvFrDxyK7sMxRcUkywI7QtF OQcIiObQMANi2DRMRjQjlA2xnzhmE4UGLDLiVPEu9hAQGs2z0AkLXOgHAjE/u4IKvIu9seGF Dln0C32y6H92yyr87JnVYLFzdgc/aVCsqSSYQVzIyQu5NlcENDER2Wcy+6zNyzpzBi8RCpkI P0YkP4eYE4/QVPJrERpTKCYrKiDenJy8kGtDQyiGyDqRWCcyK9oXWWB+wqwxGeEPjbUoJnkR 0EYHh21nhPoxyIuANhoa0azYJnKzhwAL4oHGYSSdDaL9GTGc2jDvBRSvT5gPNEmxYNJPLBma iv0gPlCUskX8WeRohPaOYoazpkLuRYCAjlmQiWtLFCNiG8+C6hAvHtaJowM35NMw7+Aw7yBu yKUciJftUQ7Mw3LoIgj5c4EWcucCLdubCzDbmQvELF8uMl4kwEDx/JMaE7mVEbzIkI8eEcE2 KGseJPAuliKgyZwNR4WzK3gWCj/xLGxU+AI+ggXy/cRD7Rc4RbBhzJaogODIBYcL/FqAgoyb NdK8vbdCw3UBCv0JMRk/cQwkZ3QjOUObU+IgmQweH0g/zqTPywHZUzk36wl1IgvLw4bYSBQb ZE3vrJy9EHD8w27NATkLAQeOCl+oZ5FCK1OEF4cjG+JwZIMQR3bOIuNgQrcu5AxOzlwoQ1qx cvJPNuS/2ZAX2JB/siEvsCEvsCEvsCFDM5MXiwXSi90cDi1uXJyFjY1e4BkVzkLBvUK3QokB 92JCOZOB9PKhM/0JnIzIu5Xz1xvWH29oGMDMDNpjCgmiaea4dph2szkRyhLYGVjHyY5xslpO VsPJjnCyCk5WxskOczILTmbOydZyMiNORuNkBpxMn5PpcDIkJ0NwMjgnA2l2UD4NpZtQmoLS NSj1QKkNSq1QOg6leijVQakGSkegdBhKh6B0EErpUEqAkjeUNrN5HuewrudkRzlZNSer4mSV nOwQJzPhZIacbDUno3IyFCfj4mQwTgbQaFB+A0pXoTQApQtQ6odSH5ROQukElFqg1AClUijl QGkblHzMicLcwtyUrHYwmmaByipDZeWisjJQWWGorGBUli8qi4HK8kBluaOy3FBZrih5tCwa h16BlkJLoMXQImhhtBAai+ZHY9A8aDQaiUagYWgADTQug1vBrJyMQKvGTm/AygvX+N5Jrh3k cXBv5JIzAhuFrAArZyOxRqpqIyyV/chcO/ijCQQzkyRZT8udAkDwR1KG5ELu5gaIqC79J/Zb ycp+WwewEqQAKOhMakGt7EWxsE4QNouNzWJhs9hYMbDZHiBa0fd6SgOq/9E/UPW/+g80DWCp a+/ahAaM3Iw9OHkLjJcH0sdTUsbNSAQbbsBWTk9GbLfkaQQA1gC8qm6NGDmjRj4osarUDdUN WVUIgF3Fz3pAcaFKbLeejORpsGahCguhBSFT/vkTGD9fTCWQCFSdX7/BQPiXNT9fdcb/iiX+ AfsTt4H1ipUZTtMZ2oXjWK9M/XxB9bc3j6wCfJi4DZxv1BAInGyhxPmkDYH99hKOyPm2xkb2 RzSiQiPZ70///aEO5t9f6iDg//AZGxL+D70SOb+9TSJxMk4PZDwn4yDJ/7Nutf7ULZnTrRan By2OmtqcbrU5SO3/WbeUP3WrzemWwumBwumBwkGyPzsOZdT/Ubc6xD90q8NxKvsTK7+yJv5b rDnIf/Lm8CRxTKfFyTjffVz4Xsuv/S3VxYbhE0DnvOXHaqQFyUglE1ltfuv6t46NodHEegVR 6e9HC9aHRfjglBfrAsJCTeiRDJySsz+0Mfahb1PDEXRwdt6RYV4M1ocEWG9iautqabMaOENX IhClOZFM3WwRAu14QiADQNfim/2iAnwYm6NJGtAQYhEaRkX6szo19mftLAPoobi1EWHQXluZ 850Znyjo6ginZAhJ5EWPxEGN1rMuRiNwJA1okPpCLReek2DRWzG2bYUkZuKUlDlvZgcyvCPZ hd8GzG9asy32t2cW7GhMhy6zw/zY7yn60qOCI9dG0LexXlBdoFrAOq41wrHeKP6TV3++rL4B 4hbMar/Q43p/SAF71rU4bgNeg8p6eRmvoaPD+nKEBhFPpLA9u5YOXRSx8EQSceGzOxt/5a71 G3dIjn+f+YYF7r9n7DdA6dBeJ4ZFQGL9FqoGQYcEhYoGnvXKNYRjDTcNCoFIZeF08KwSkcAa Z1CJTGDXUcmLsfaL1DERDF9oRmW9LgtlP//htLW0SFo43wUclcR6+ZZTE7qIY73Z908cifV6 8+84PIHEGv3/bMuaCn7DaWsRtYhLcCTWbz39zg+PJxKW9qFFWtJWC79EFqK2ls6Stlok4lI6 0j91w0M2WEpHZcXUP+lIS/ogEXSW8NPS0iEskVmbsMQu2hQ8ZQk/IpW8lN8SH2lr61CX2IVC ICxtC4XOP3FUCmGJ7bWoeOoSOtb3Tn7HsV7vpy7xOVlHe0lbKpWwtC35n/IRiFpL4opAIBAp S+jI1H/aj6BF1qEuodOmEJfSUchLbEUkL+FHXRob0CCk4JfSEf6pG/EPcUWgUpf4F6Jb2hYK F50ldFQifgkddUmsEamUJWOGCvWxhE6bsCSeiVRtnX/KRyLidZbairTEBkQqdcn4hdouoSNp aS8ZMyTICNpL6ZbITKKS8UvaalGW+JxEZb31/zuOTGB9yuKfdFpLdIPotP/ZB5m8dFySIacv 6YOsvWQMkimUJfMVlUghLemXTF1iA6gt8Z+yaOEpOkvpdJaMaYhuSdxrkZaODy28zpJxCdEt GR9a0HSqvYRu6ViA6Jb2q0NYKp82RUtrCR2eSl0Sa+SlcydVm7y0D+ISm0Iz7JJ5UkuHtKQt REdeMneSifglax6RunTtIRKI2kvaEqhL53sCYYluZPYC/w86/JIxrU1dOk9SiazPRyxZa/FL xz6RslQPEnFpTP6hDxKZsBSn9eu6EBlBDwhmRCxsf5wCtjM4+wtNx7CwSNzirs4i1DcMt/jB BwsT3AZ9baKOlq+2jo83ha5FZfgSoVHi60tmaJPpVArFS4ds8J9TbFz8MAQ9IpKzt6FCeyPo ilFBwdTOjI/n/wNQSwECFAAUAAIACACJhlMp6BH7b7yBAAAALgIAQgAAAAAAAAABACAAtoEA AAAAZXBhY2hnL0lUVS9JVFUtU0cxNi9JVFVfU0cxNl9FZGl0b3IvSDI0OF9JbXBsZW1lbnRv cnNfZ3VpZGVfdjMuZG9jUEsBAhQAFAACAAgAF4dTKVnoZX3zAgEA2k8BAEIAAAAAAAAAAAAg ALaBHIIAAGVwYWNoZy9JVFUvSVRVLVNHMTYvSVRVX1NHMTZfRWRpdG9yL0gyNDhfSW1wbGVt ZW50b3JzX2d1aWRlX3YzLlBERlBLBQYAAAAAAgACAOAAAABvhQEAAAA= --------------491973E0334ADFE3407FDAE6-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 02:51:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA01781 for ; Thu, 19 Oct 2000 02:51:56 -0400 (EDT) Received: from standards (47.234.32.16:2328) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6E8D@standards.nortelnetworks.com>; Thu, 19 Oct 2000 2:35:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28312 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 02:35:03 -0400 Received: from mars.hss.co.in (202.54.26.197:51090) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6E8C@standards.nortelnetworks.com>; Thu, 19 Oct 2000 2:35:01 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9J6oWC07981; Thu, 19 Oct 2000 12:20:33 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.0024848E ; Thu, 19 Oct 2000 12:08:52 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.002480A5.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 12:09:37 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: Re: EventBufferDescriptor processing X-To: Dave Sclarsky To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello Dave, If MG receives a new EventBufferDescriptor when EventBufferControl=LockStep, it should not impact the the events currently in the Eventbuffer. But the new EventBufferDescriptor should certainly be used to buffer the new events that occur from thereafter.... The events in the eventbuffer should get impacted only on arrival of a new eventdescriptor or on activation of an embedded eventdescriptor or shall get discarded when EventBufferControl property changes to Off from LockStep..... Any comments -- anybody..... Chanchal..... Dave Sclarsky on 10/18/2000 10:04:22 PM Please respond to Dave Sclarsky To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Chanchal Hassija/HSS) Subject: EventBufferDescriptor processing Hello, If an MG receives an EventBufferDescriptor when EventBufferControl=LockStep, are the events currently in the EventBuffer affected (e.g. discarded)? Thanks! ============================ Dave Sclarsky System Architect, Access Technology S-Link Corporation 520 Fellowship Road, Suite C-304 Mt. Laurel, NJ 08054 dsclarsky@ss7-link.com voice:856.642.9229x231 fax:856.642.0252 www.ss7-link.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 03:18:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA05312 for ; Thu, 19 Oct 2000 03:18:36 -0400 (EDT) Received: from standards (47.234.32.16:2328) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6F1E@standards.nortelnetworks.com>; Thu, 19 Oct 2000 3:01:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28479 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 03:01:48 -0400 Received: from mars.hss.co.in (202.54.26.197:51527) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6F1D@standards.nortelnetworks.com>; Thu, 19 Oct 2000 3:01:42 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9J7H0C08761; Thu, 19 Oct 2000 12:47:01 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.0026F6DE ; Thu, 19 Oct 2000 12:35:35 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.0026F45B.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 12:17:06 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: Re: Topology X-To: Paul Hollis To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello Paul, My reply is embedded and prefixed with Chan> I have a quick question about the topology description in H.248. The wording in the Topology Descriptor chapter says: "The default association when a termination is not mentioned in the Topology descriptor is bothway (if T3 is added to a context with T1 and T2 with topology (T3,T1,oneway) it will be connected bothway to T2)." but in the example in the diagrams, at step 3 we apply the topology "T3, T2, oneway". I would assume that if we apply the above rule, then there should be a bothway connection between T1 and T2. Chan> You need to read all the steps in sequence. Hence the two-way connection between T1 and T2 in step 1) was broken in step 2) by the command.... (T1,T2,Isolate).....Hence it is not there in step 3) Njoy.... Chanchal........ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 03:25:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA06042 for ; Thu, 19 Oct 2000 03:25:27 -0400 (EDT) Received: from standards (47.234.32.16:2328) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6F37@standards.nortelnetworks.com>; Thu, 19 Oct 2000 3:03:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28509 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 03:03:26 -0400 Received: from mars.hss.co.in (202.54.26.197:51558) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6F2D@standards.nortelnetworks.com>; Thu, 19 Oct 2000 3:02:47 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9J7HQC08815; Thu, 19 Oct 2000 12:47:28 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.0026FC7F ; Thu, 19 Oct 2000 12:35:50 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=rDRhhz98DwI28GMxfPSckzih3R17sXU3LBvJVSqHDe58OuwctmEkweoA" Content-Disposition: inline Message-ID: <6525697D.0026F63E.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 12:34:57 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: Re: H248 Implementors' Guide Draft v3 X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM --0__=rDRhhz98DwI28GMxfPSckzih3R17sXU3LBvJVSqHDe58OuwctmEkweoA Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello, It would be great if in the future versions, you can do something which shall make it easy to clearly identify as to what changes are getting carried over from the last version and what are the new changes.... Thanks Chanchal Christian Groves on 10/19/2000 11:36:58 AM Please respond to Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Chanchal Hassija/HSS) Subject: H248 Implementors' Guide Draft v3 G'Day all, Attached is a copy of the H.248 Implementors' Guide v3. It "hopefully" contains the corrections and clarifications that have been discussed on the Megaco mailing list until the 19/10/2000. If anything is missed or erroneous please let me (and the list) know. The file will also be upload to the pictel server: ftp://standard.pictel.com/avc-site/incoming/H248_Implementors_Guide_v3.zip Both PDF and Word versions are available. My intention is to make one more update (v4) before sending to the Nov Sg16 meeting for approval. Cheers, Christian PS: Please forgive me sending a 98k file to the list but the Pictel server has been down. --0__=rDRhhz98DwI28GMxfPSckzih3R17sXU3LBvJVSqHDe58OuwctmEkweoA Content-type: application/zip; name="H248_Implementors_Guide_v3.zip" Content-Disposition: attachment; filename="H248_Implementors_Guide_v3.zip" Content-Description: .ZIP File Content-Transfer-Encoding: base64 UEsDBBQAAgAIAImGUynoEftvvIEAAAAuAgBCAAAAZXBhY2hnL0lUVS9JVFUtU0cxNi9JVFVfU0cx Nl9FZGl0b3IvSDI0OF9JbXBsZW1lbnRvcnNfZ3VpZGVfdjMuZG9j7FvNjyPHdefahsaDqOOPSDoE AVKZGFiOxOklOV87NBSIw5mdZTxfS3IlBYJgFJtFsrXNbqo/ZpayBegin4PEyCUBkiBIDgkQK4CA AEYCO9dckr/AcO4+5hh483uvqj/4MdqVIyOJbQK7PV3d9ep913uvXv/7v33lx3/5D7/5H6WF3++V Pl/66ZP10nOFsc/j31dvmZsvl0ov4G+6/emTJ09o6Eu4+TL+fQX/nvzq9//i95O//pfSu6X1L5RK X/zqDzLJ4oeRNz4olX691H+n/078SvxKaem3/oWXSt+zb5Veaup/f/+eHv/urfn3XjDXJ0++lI3d 9Hf6e5v/b/x2KbsW/6bf34rl604Bwo/Ezdcxrvd+p1Q6xfWPcI1v5c//9B/BAqj6T363VPobev41 /d6PvmbmL1w7t0slG9z6ABzaAZyPK6XSn2H8+qNS6XO4zj7S7xWvD3D9V1xPsc5LH+trH+sSyL/7 fqn0n4Dz5/9UKpVx/Q7GX1xmfkb35VZp5e/8NguR8Su+l14JLv2+XS0t8bpIX8ZP3E9B0PfBl3ph 3uKV4FdvaThfvJXDSfFN768/Wo33orwW8Vq8pvSk8AiP7zyX4/O5fcgRCvb+XwH3XyuVDo38U3x+ 1t9bWO+3CvQ8B758TH/8uPHPf3jww1uLdHxgl0r/BX7sfw9yvlX6P/Jr9x6KnvKUE0wmie86MnYD X3Rj6Q9kOHDfM/fKiYNw/SiUw/ibV9tWN04GM3ESBslU1PasB3atvlXbuVPbEx05nQZhrJJQnCkV u/7IOlG+upIV8fix+BP67zy4UpO+CkW9Wq1aVvfiYad1/HJj/XjgYhFRbo3dMIpd6dMCVyratHrt 3ulxY329PZl6aqJ8vBbdFieJO1BiiCn37frOXevyYefyoov3jtzISaIIiFvfXP5ZVkddufQ0EpHr O0rEYyU8GcVimvQ9NxqrgVixUsO6R3iJKxXSZFG+qm2KazceCzkKFeY4Y+mPVCSGYTARzWSU4GUi sSIuwREPHBXdE7DI8EXPnZ902dqqHdQwo3e0hTdpih6rb9uW5s/tSMRqAh7LcJbiYr1ucNoGh1sG IiQ6dT3gxaCJxvZx7x5WH0knEGfS9QgJ0BuLxI9dj1+pHQCnYCguIO9URIxGtniUjACdtMIW98D7 EaQbSo+WI37ZFv+ebwV+LJ1YtH0IaMJaZFlQtq2emFcecUc8SDRAUdsp6M+adeIpX9wLVeIPPNcZ W80rOZOiVdTUyKptA8M3bFGrV4F680r5ibLeAMCJ60exCiuY4IFbg0Dcrda3d6yH3eaaBZVvrL9S E9vVbbG7fVfU7x4cWPfk47nB7YPqvnW8NQGrGuu/Ie7/weVx57R9/g1BI3HQGI2Gr0nCyQbx4tYL c/cvrq0ZejtK82agbYmV1fBzzfr9YEzmNYIArdPEAQdhjs7YB84jV0XWYRCDiCgOpYzFzq5Vq+/X xJunQtxP3PeUb/UgtHMF0YWkYFFK2XZNlLd3N8Xe3X2xs1/fMbQVh3cPdncy6sQK8t6JGK3XTh+2 js97duviDDQuD75ogdLnxfO19bYfh8EgcVjYvbEbiUHgJKQVAn9Lo5GaC9CxULGkB2KghvAvkYCR QRGHLobYNkghWQEHysGzgVBgmpl8M2tt0Y7FhIyvr7CGHAjXx9L+O4nPmOWwF2bHgYhUeKWEBLK+ kAO9GnRbJvE4CN0Y7+FxFCQhvAaQcHPlZj/kFr2GLUg2xr4rwvFkCNqM2rJNOUEYKkffgweuDxIh SAV8ZaiEejzFU4wBMZACV+UlxAU8HiZxgjeM+UeEixwO9dtav+Zpi2yrvt51gqnSchmx6wxVFHhw sLkAfObLMPC84Jq8A7BVI1CuooalWGNdsEOFIQi0YtJTEJQOVOAbnDFxL5i4UZSRCcTxJ/yM8h1S aTnpu0Agpr/bOZ8r2ketcPETOUupJ6ZA0SUez+AHH8dAFu5B+MpRUUQukYRHlCVerEUE85mGKtZS GrhDyADPsLiAqwGfoZ2Zh9SMMJoJpjGzNBLXrucJP4gJX4CPxDQMpkEEhqcEgAED7KTmT6jDJBgU JA4pLisdhscwbBI3wYadu07szYAB7ESLPlOqFRQYgck+9smCsGwhLhk76UWsmL66FkMlSWngwcdB 4g1IpSZyoDQMOOPRmKwECPSTOYTZ0mxre/1IM6dDWsOv0CKOGgCo9XDKqEUOEAlJc3LlSJVLb5X+ jN1A4IMg1ltaYpXKVgTIlpEiPl+RAKS4hglCiQAxckJ3athBJgSOGWy1lmaQM6tYZLvGBrhMs6kP FiMYsJFMmLZbkgZzUs7rCDk2L3BYVpAjYwB1NKuz5gBKuhku+gu8QwTKUAszym3cwIJi+nEKLXWm ANhRECV7tSW4RrqQPHuNKJlOPfKouAXuMN9glJCu+PQU26RMQx5wwTgEXg3gYDlswOQMp6TusP6Y 3MY05/c8NwxY4HWlZmrADHSj/KVMc6akORHTDKfEvheqAa3QBgu8tKNbpRmAeo/I9cSE48ho7E5T S6BwFjDJlkL1bgLlYMKYxY47JfT5TTdKUbCtnfUO8IMjcMgh3bxll2kv2qwgggIbxQlgXcMxkWzD wCNbiAMn8Kzd9fMAU+HvydyKHo55hkgk3VZCE4eC1+GjqLLge3mQ+R/NJv0AlkxeIomMV/AH5FlU Kgfa6CCucXCdhZTmCXtJ2iAWqcr9gNQ60kAwzkutHeUWtrb21qEagWmtbLd6e62d7tQRLwEtCmO9 pRcoIkRp7b4knDGIm1Ca/S5zuXnMvWiime32Z/xmvl0CZ+KQ9gN96BmQPAajPgFFY5X/ewjatr3W NkIzXp+hw2xMSLMiJOmr+FopP5cjJKUkO9i+gs0rbZ9DslRWaq0qYoxdMFSI4yikSPxnR5Th0ew+ LYt9PKZp5Kv6xLp4Bkq2trZE9/K41W6eivZ5t9d52Oq1L867gh58i6LuUMeA0fsFiiWCK9aRCFEN RxFkB1i7OMGEOtoImG17671sJ8nzEJrfKkRPmPZUw7X27FphEvmBvgvRBqNQTseuA4YZL2BZBf1v rHXNhLpdu6MBst91SQNuAkEYPbD393bNHsJ/U3jpcmbG4ZAO24SfcDLMyjkfs+mpRlgF2JCzhr1b EU0yXZO1Q3n9iP3wRJETcKMJ8sFDKAzgw2EoeFqyCrhpz9ObPXSlfNhuteDWOF2S2d5F1gP90ihD EMK4gaZxZm9b4Adyed53rlSOXmR9uNqLMs4V8cdddwTvx9lnd4Y1J4Bi/8U+UH0KMd+1PwEwMWPj s+LGhg0i2KXk5PbGaoV8SY0ioyCtTEFy12qkx047aFjLvtRqtgLkN2u1anVvDWk3jKQbk4WvNZOB Gwh+KnqzqWpY2T7VyNXdTsm3n85A6zzwt2iLdAio3lDSxCPLiopbfWTqQFDVcEQgNGhE3MqEQjz3 gh/qWhEsM8vjwmW/DCusi9el5w5oU5YTRdktcROMxtZKEfOMDf2MQ1qImdLaBYskURwj048PE3i2 MH0GL5XBFNeSwik5QDyKmJEixNSbcYZwNY/CUzEoyDkS+zZ0v8KXur7saMGvtBN+m+5ZhXBNgVJg QLj0VDgBqmmIIDmmgLdH/pE/aR9Zb5nYI6f3bR6DMCeLY8njhRHmV7QwqE1xcfTIHbnxmZzmw+/T 8EWf0+PBSkgrxaHXoMQlQvi1OOVSOo8kApXiMLhTXv95U/0JuD4jP3iY7DMujm0uuowlVfjQylQ3 Wqm1HA9rM4L7bw8RpSJF8GO45zjNhHRAw4U7+GrFwHRAkbudAaCx1wl08FBgqW09i/n8zxCh8bMT AkJRuI7modkaKzauPi8trscIMwq4pNE0ZlHueho4j7qxmpI7FgvMtVYaWt1YMBNpjDk1N52PG7TJ ySmdePE2PM+hXza705z6RTY99tLs08kKf/nke6V+gaS7Z29TWX9ATAjjG+L1Ws2uLwfsnhrGVKTS CR7BiJkrVHCfNUSPoiadA4qm46hpXAyMi087VAYpbPjFIIeWLiLYNN4QTnSLnSfloDofk0hFfYiL y+R5pBokcURVL06vqXCr43Jdt+BCQ1rCugzdCRc+waFy6rO92SaVbYIQgRrWSX00WBNQQDcDPi1K MLhuR2UwoJpl8dp7s6fnqqcbRQnV37pQU9dR+oAp86oGjY2OYgAbICIeBwilzNbTCYJ4McRxY6JD 4w1M9A6jl20JyWyPltCIKIeXqyTEoqjkIewcomcjpz3g5FMvrLxhFt3PB6Y7WiEhkCkSaWjM4wXN avq+eiya9rZRq2wfNIVEwzs9l+4GKTwqjpO9UmU03SA5etaFoREyKM5I9QqHBn4sHylWGkcNdObn I1uJlAYNxNRUck0dDGwWRoCJ4yRhVh+eZscyIkw8Xchk1HSmcQrtqOhSfay11FS2wbA0+2TVK6zQ YMDvJoGpD1wjSxCRJ6NxIQqhSqF0Uj03L1NAzul8X4Y3mA84nItC18CmErL1EZxQermAu3i1SI14 uXz6RvdSbNz59obgvwoPN1fJfVdcmAMLjvKpPpGW7VmkVHgB+7FF+qMVmcjyhLRak06iQS3RCZ1S 8OlsEoY6LZFU64jEhEr6UwiHRacz6UyhQDefTUGpdXUvj9Sg9mPX046Caqe+Lm6YQAxBGUyMz2Xy 2M4IiBeClVJqhNVMuSETfqFa63KGhmxFH+KxqzLVxebh+b20GKm1m4M+fZBBsdRqCa8fwkHy3Dnu QbZfF0rOYSvjrUkQxVuEoxUVLftShhOB36uiPDd+xg5I3BFzox0lI9ByZx7GkfLkbPHVpjniuSPE wophMCRm36FSofJZZe6InjtR8POT6SJw7XoWgKdn9StUEbq4J5rmeGzG1vsU3ZtXM2S2hp26ej7v TfJNEC4/W6SvHJlEWn/i4BHc0Mbx4caK9FlXnq9BR+UGv6LPmo4nfTXoMSQu2OUxAQ+Sr1/2Mlqp WdfHVLJgTKJPtc5EhSNwYsZD2p15SprTjFUecBEzkfgaj8GnVtocl/V1aOMG32+sr98BM8/Azk1r Hr30LTNm3jw5PtvYhMqtcFH74qF2+/N7MJGByCIEqtQioLssFpUk5Iqh9OcOYmdZbTmtXlGAfFef NxQCKNrFOUlbua8eEWRSjGeMgz78VST0s0dCt6M5QT9DYPRpQqJ8XapDK5f6AqS/ah4drnF+nu4B hCpwMaeRasCYEVLREqsKM+Y81WoU7SKgpdibEdEnpuz8VuGabSPzjB0ESh8Sag5/AoNvXL1ioj+9 6amsLYCKCVAkD2v6VEKl5fSpRsYfUvZnxttaJZcVzODt3pwfR08B+hkKqK3l7voJ11Xyc1XTVIaF RirWETKXdrjub5hiuE82MM946qWJxVC6HkcegMBNHZRwGUulZ9QCg6dBn7a19IWKUC61Q+UHeJe5 eTFkqltHlI+SKBAaEbZBWEm5HPMZjbbLeR817zN4F2S3UtQtdoi+7HuMWna+ntOvWzuojEzH1llT BCNHUhnTacS1dJlieBUQISdBYtoAEGnQLp+f1xWOHw7ga8kNxeSutQszKsfHbLmjMbH+MO+aqfDj aI4+IUdgK/RP79YBAmSmKk1fsjaARRVimowP1A4Kyu8FaY4hC/5SPzN6nR1PgovANAjzs208n2YO eX41GB30IUrDV8zVLNSumjuTxG51lxojzbKdbDl9hJqi2kkhWat24Lvi2BkH1OHgKM80seUnGIuJ 4pQOl9zH4tiuba86NjTVR91GQa0cagl4MByStnK/w1ybVMuuMSNb9kEKkg90poFLBdiBkl7WXroE NjtUzN6nQyCLaKPXRLlWrR5umo1D6mNYOiwh874YDivixK7t7fL69Nfdr1vHrfsXrbYoH1TrtU+a SNHHhBAr4ETnnmTuSTwKVj9KG8h4Jt3c+K6uaxcIywLgluE/UUoRE4W7jGYfGzG0PU/TfC4jcD41 NVU0c8hVrBfPwwhoh+WzeSprz0OM5mVn8uu8sY9sqXuCQEvbAnVGedAncR2Ej0zU4Iaie3l+nOJT 0bzlBhE+/x9cEQsGmXuhSnxB6Hy6Bkthy+nLyHUKbw45JDJW1zs6E44bOgkV+PViBEyzUOuxVp5Q m81irSD1CwUJZNNbT9FKfWRBhQ7J8YN2Y1lDlXHJpg+CnCvfFQ2hrw8i9PEeLJkrqvaq5hWLpp2Y rmXdy9OMddsbFxdSU6AT2cO1Yz9BlM5IrrEDaKV8bZBal6khiE2iTMp/Aoso1zetc4QWDykshrNK 29uIhbqFjBpN5IRz/WHuWDV0I5tc2ziyXkoUxUq6DtLj7Zacyr7r6R7LD42JrpGFriDILFns1F6w LXgiJvRGExZM/Y2mKcCTyjOasShv//z5t2fXqqIHzaWiL4IpKrxoh4HszrK+lXW7I0ZUDd3ElnXF JNOBDh2yjwfm+/snur9f9/+CzmnCW1f20sAd+LdjbcdpGyD23qmRCm9zKWqxRs1+f2GDaft59aVs 0vzNiqk8hZOMtsLZnqkzxasqVqYIpMx6ZpNods9hKlNKWGLdwPNuwmVI6uKhklKK3erkL8uWuwvZ cryMHBVxUpx1Mn562PlGL2OEFpGwXi63Ls7Omgvjm6JDb1sLb79qSvu8blOYmfnQoZgHduSmvUEa 3Cq1qdGZJHcfaUUj+RkftyCiVlbhM6W5vARR8ItpkG3qdb5uponlSG/MUjd0mHBSL61jmAk0M+uE DcLI1lo6t06xFzSSs2dZgnCdp3BQUCGtPtCLWr5pTrhInejyRBG48dc3Qbup9nt+fvwmGNMjEMTd Cbto5AZKToq7cNlPe482rcu8lYSm6CULzKkUeEZ/3oST5kie+BDBcrTFYQw2RZdK6sOlsMHUQDJb TusSafurZFln0V/h9HmmS9qifGnu20epFRP52TBxgx7M0upHAUKZeoM208g/DbnKr9N1035d35rT +zyX43EBIqEfWX1H32aI5i1dJqbmWH0kw4FmzUah73hDu7u8QWqO3ExUBj2dMUl9Z5bNcvI0ppXF dqsURUMeUwFlNhhnbcdUKQoNdtmiG6sj+lpdzO/o4kgNZeItnic2NQ3Fd2XaxJwqYx5rYp8AmbxR 5BENPacUIq1czX0oYr7GMEdC0ny4sLgk0MtEnp+wFNNTSsWyPUUi0qImLVNZpapE3ht2k8fWUZ64 zOiyloi2ck1tYO9GXPC4Wq3e3bQOZyn26Tbkqek4QGo70p3SsAOPL5hOarMyN7mPtOHKFCiojztP UImoKJgobtejZmmTOFFwovvog3QHpQ83qF8OsXngKQmc0xhBW0PD2oDCinKm98vxaLFzhW0LU4bD dI5GjpanDpvh0N7k3COVHp5hgYJooID09QT3yrX9hnY/xvvkm6C1jpSW+o9VqM/1G9zVfYc+e1DL Cryffw6pcW7NfWFk7du19S4x7D6AkJvqIUmx3qQf9QGKpv5q8TNrrz3PQ6W0IpH5AD/wt8xXkgtw 888/cq/Zm2tRpqiLtDrN3gbZ150mOaT4SpchKPp6YNd20hBMWwL1M8Jt2NYxFwPSUxU+7SNeT0Tz vhhz//yKE5aHR5e0QcRpzZY7KnMD5E1AO5x6FVAe69NGKGiojNMlRBBu9mfUBl3eMd+PVcQOw62I OsPchE3m/Z1r3aT/DuhviGdA+kgy5xPArB/Ql6f6q7naXqNeb2xXxVZ1p1q17oXBpCE2OsjWkFcf QsiwgeJnfxvmuz9+ZPN7r501O62L8zZ957chbr1ww6MXrV7QEGfHJ83WxWvdXvP8qNk56trnF53e 8en5ce+Ni85/s/f8sW1c5x0lSxSdXGLHdoMtQ3dlssRSaIpHSrLE2EYoibLl6AcrynEyx0soibJo U6RKSpY4R+hceBu2FS0QpO2ADFgwZMuwJmu6rl2BJmizLlnQrmvXYUEDGAi2rkvbbFnTZJkRJ9a+ H++9e3c8yko8Z/tDZ3/U3b2f9+6979f7vu/uymLGBrsEMeAUh53Hyk7PwbTGzQKxbcEpcjsyQvp8 od53hsEqVF3GrILQuSeXyMtzTJQjGlIVLnc5diaaK1cVpc1mhiNWNv3RI+mxgbQ1dmS0Pz1BU28w NZlSpZ3GoeFjE0MD8a5Y/Dg3VM3P50q4omWV9S2rbV7BY4U1812YYGEsqWqNQEdJcyo5Dli+00tF 1wY0jueJCu7wDczlp08JUrt7eODu9ijqJIYzsEqFz93A3Th4shLEaafzFd0KfDhDKoG8rm+nkhlt QHlXh60AoeflWbHzLTIKBTkR/0n0NSIir557Vrhn5kBqrTn90p9MI3tMQnDdTVcAuet9XdRU49Af svIW+0tomAGkovDriIdl16U5vuhtzkrEgcNblG6eTs8jTpqOEKTin3WbgIEwgy/W0HCFHXNhi6h1 VNIibXk7e2CoNAJkX67lBbc2OZDhPf68Zuc9kqvlhR4b20eBU7gGTiHeFoaPWBSzC20ssHVl0pc7 5NM1IaM++5G9sF71fSxAVuQ4wzr3sSMjI4T6kd54WCmQG6ekjw2PtiaPcfGcqwLpzSU1inPMIAg2 SjCMQOQrkrGteHzFmCCpmYNWOKQY8sO1E4BGeecMJ8PYErK8wOIDH8QoFipbilgJW8OxdhLQbKzP ut22FY4dmCMCrgIY+GJZlSnKme5MTwwPZLPjYxLXrpvhCjEu7vUmnNeGqBaGHP1sp4SLmUBDwhJ9 eBBvLAN7JBN0U0JCeTlVHWlQp+esZRrzObkFnycnJDJdIi9ZVAQJxwtoQTnPitvAO+bnSUWnTZAq z9kKeT/KnAtztSrxL3pGZAjo/Ynqo87DkkWPZ85h/9aZdVG/JZCwRtFoCHez9lsjBXJdFEJAdjDT wCZxADUIkGylP7ZUAJRMyLJIzkCngXsrL1UpVYmWRagXsMMhNevzQmVJDe6e39+OXZ0XHRHPgogB 5XkmPpwfK3Ib/kg/SM7qvyDkE2KfVIfFYjiKitp4QlsL3clEV7Krz8Nv5E7CmhnNnQLW9uRS2No3 P48nWgCBA+99LjuWoH4DCtMZ7tw/GuyPxYaC2cmJ4bGDQR6GEpFYFJUV1hT42+Vcg4EykNgm4nv9 1Ie9aEkshmZcMiLwdu/K5xcQt8GMHyrmTtTr7BxbCzvaV+8HgJhqkbzlwlYaraCImkrMpiliXMI1 VUNP5uaMWGUyPOi+i31McR9noY+8olSqs6MVDYNAAXhV6K88xWjWgWi1KPa2VQUSP4s+swqR5pkq hi5F6L8f1ZSMDoKW2lXNpmw8g/6FqZGo5Zqlk8rdu5EVYVzWzgaZXqudCSnhpYSgkUzuV4yeecYM nVIPHQqF+sfHR9KpMdWbiBmi1zM4ColpPtMTeTeVX448Qlnnpv7i9WJeS2kqVndTKxGNRs1VeByT K7/KT1XXk410zm8JdVtZfi2ZShkw0DyhT7lvmvIyDtMgEDLbWfYaz0o729HcwkQKlR1JU12T8gNt rVbCVidbg4aP6WahI3lyc+eU45zSblqYX8YQkd6oyENi4XWYB/FEC/xEbrYBxNJsfoFRZawraXcl 413W7cAHSlSphYKx9tXHWTlg6m52ScsvWswVMQXO4EeF2VYxz7YD4xUYKgq6wWa5zOwO4/jzCtW4 AXa8OTjAzjfS22bRbfW0gEaXGIwALkp5UuYUy+VTjmFyFW1DnDc+CFkx7gfHItJzY+Xl0p45vGZs WSovA88qLExGD9pJk0ek07aO2fFEVELX8WQ3HqZuS7MfOPNYzLbOmLhcBfcDd/eIO3gIr6L9VqoL Di0BD17akBiPA210p+GRK3aiBDsz0wmyxRnpALFfPeCqltdVeDXiuhSLzjozfaJzZnE14s6s6nVG 7oy5O/agFYs9eMzes/f4sZWVleMP9uKfFTodck7Tx/C3z5Z36GZfzIYbx6Ptq3rHVk3+XbVMPxap BwNVAJ3CtzioKdlhoEfH70571jiJQDlKUSYixORXl9iRzS0suEmiblEN5Lwg9vPFLrJWDGUblj1x e3FSiBGisLCLRTbMV5wgJcw661+n5aVF0gAJ5RxUhz44UYEShioFwAjdDkYAKSLRl4SZpzNPo8BG 5/JFq79SXi5Z+wai4kaUbtxZv7C9OGIMA5kUMUAUWhRcIX7IaoaiwpMqvSIE5xn32/UueX3QHZtE 3cFWbh/Mi+miV6ifi9eiF6XahdUZSy4qEy3UAdkC8xtu5yLNQlL5UwluhnXOYqs5IsQZlj3YmUNk rvOwtE4i5XCZMNG7tyyliNYfiauUgdroybwaIdplnAE5xI+Q7nVrfkUgC0TlMI7SjKXOk0Xkyc8o Yw/e4+HQKcLoBe2PgJsrlnMUBcZx7NaVXYSCmUIUZWUcG06MXRI3zWQr4VwuTHvpOYt5CbgzFY7w Do+eb2oqLPoIeXNkYJorYe9E37TScqMN99pwr5OduynwkfM0bHkAz4B9DiNnC88RVgMUYcWKcsMo AjUpksLOMfUnwSkKC+E0SabKREgFqhHGMiz0UnQlYn3JCi3qUn3jGya99jrYhGgJiN6zku4CRsfZ vMBBpjhdIJRRnK92r4ZQEsl4T7K71/rsB6P99QkgtwFMA7VuINeu9RGSHQeGxZZ+j2ZKzSFUaPAU YqMRgazUHEV8IMM5CkWldyIrLlBtCgtdXU7lUJO0xIo0eV9Zc5J1BXnPOCHlnD026UupnCR1107i dzB6lzJzERugyhBGPZP0l3HZhvqvzStd/SRFXxYDCM2brJa1DpddZFWxyqxDuCIiOkroVy/LVoMu 01JOWkSdxrHmfid0G4Y6kpa5PC1IRtXyQ2v6JT8j4ipWHBRxQ44cc7S++GiH1pms6Sg6GvIrNxuv arH2kxaOAe2xdtkmW60tSiVwzvEvVKaD1YbmwTusifSQdT8gm669XXu7E92JhHVfxbpvztpJe0wf sRQekrpvHDOKrxfd9V4fcm80AQIpo+gxGLugOB8e7FykMF8zwSDyptYkXAVnFnkjORFrB3QI85mE CkypyBQbUvqXqjW+PSVvx+E2sOkiJCknTsvEBCRmRbghzbyNc1ULi5yrC3IdzbFCkVKWZfluSMnk ariNzaGZTgiRk7ItqL71YCdwnh/NcUwj7saySN4rkmFxujNURIZeyODjDdYb7dVEENTQwnDXWf77 7FmSgQ4Fj0XzK2H4JaUlwcHAypB1A4mh6h12mFTAYmEfLRRnptG7U1pakwuqWyfJOtOS1UsRGOqd E4RWi5hxxobKKAyxDKleC1WNbmu6Z+henRZfKomUyQP23kVI0+sohup6yePIwTkcjbeDUokGMAGo KasVFGMBg9MmFnVDGZA7Y83VC87TqVko2qU+KsK7MMCtLBWLUcvPObk32meNqUBRQsgkkUgXvRv4 Byr2BJen1YcKMbTDoLcRHsdK2P9Yq4r4sYrSGJMpTbFIvc7hjiQ6UZXIupFCBNF2SXlRD7aBUS1L NfJYiIbVxBIvX1rq8HIkZLZE2tQjgxkgT245r7aA6n0oh2Y+FbQjruYdEpLXxkLfAViHr/L0lCMY c+APbSvd3otRkIW+pjcJ/FRXbD1mal8D9ujA/xV7hC96HP1TxM7mgAym9JtmImp9EO/dfybbMcZL bOeJS0UqM5S/aJUZj5xwkGkgxOhGsAWPl0pZignIPAlvUqcppyVX7Mw8m9NUo9Yw7nuChKEMCwFD wmWWrRA76ZxqQkMjvh5cEg6YboUPpY0TY9iJBBXGSiP2nZpincaDcJDiIInjWqxpBm5Chka6LqqN SrdtUqIWNUv52Rw57ufUDoIIG6ws671GqTkaLee9KBHNGQZEXeww7HpDPuy16r3A3iw/FzGSBkX7 dOla9CC9ypaAn4hD4XJoQPS1qGqThRc/e34ob3U2FyoWyGqZsDDMR3ww1/tE8RRLO3cmeZZgGGjh usQhYgWSh/7NFlaIeWbyo8RNFvRY0JcPr+mn2WUZUK6K/uAIjjREZKYvpVutbeFOR81umLg19FFG Nyc0MHPNzv1W+A7UjKNeu5MU4PB7hn5X6TdJvxH6vRl/6zSa4gjvozwH6Hd/2DLNO6wxOZuqKPow vXa9BCKsGOVCxD7FhUjeuZlUB5TvkJSSnCprlMEqwNKE9NEG9Xtean0LREAvUz+kD5omRiPjxVB/ 4J4CJId9kuD5U+H2DfHLZG45nBpLIXPgUMQqTWgtDLcr0coeQl4Q4zezBy/7TlJEPjn9aP5gxUkQ h5dKhY8t5Sm4NFTGG4XyXp6M/UQMSlxSUqwRtwpVVb2wcBbhGYSQx/ZNTs2Ke+QZrIcnkJldTSrD YqeQx7waimW5CDNAVasHSHJsT09XNzqikWaR3X2oewuVwmlcnEvIo2ZdbcX4aYRvkAizKCywadkp ByU2sMaFB0kwGWhksvhXay7qy7KvWLWalyff41q9e/wX7srKik+FmqXm+uaeGzS/9ISh/4AtMIEl CU041hu6BIKBXNbbMI9Hu1l3y5brQO/nhCmKs07IlCFpuRcPCP9L5FmM8VSIDuskn/CxIK/sSKxr qKlByTglLdNh4flwBdSyLJeQOS5rM2ENwhz3OZalaOU5uFlESlAOqpue82yyMfVrhIovd+jCFbw2 ttaBmzX2B6lWy9MFspKysOMhvSiFMPA9RkRgBeyyHKaZagMmPJ1UHaByUkLRTUvshLZf2pPs3pu0 PaYlk+X5PZlJazJXK5YrwIAv0smdJdr0KIk9D/wWxwFzYCAJUxK/fHKnimkarc/o+Avqy4Rjv8rI EWrOzlRdoY6EEn+qJkQZJaGkNEm4GmH8KZYmrwJpdKRMkbApiV3cHYEVFA8JB2jxpRcrpRkgos1f tVEIEDafL5dml6pin0C4fpTJfUf4zbvdq2XlZW/C6EGWy4WMyRiCXEpFQ7kZ6iS2ss6GOYanr0nf WyRgaJJDwlzWJyJPo/lh9ya74l5lt2t6qNnht2m24W0x/9lht9M4LPlEaJHDJ+zJkKaBmHAiP2PG 29nLXuqXpWKSIpwQAvKtiP1n+U3lgKFHizznFdHGkxhEScBLwkKYe4fWn8r2yX+O9UUTIcZAUqEh eXzGjCD8OZhLKYV2L+9p3/jEW3aHK61qZk6qRpYSuCfaU1Rx0kK9tfIS77NAX6bZJ4ndj3kxoQZG 34EsCVNEx7lLPkPeeYpoY3ylcLIMr9gQV/XhXEzYG9YVzOcq0OkCIyqciuHbvBakt0GROntQ4G2m AVeXHAx3lZUMpv/0T1WrS/PMXwtXHyLNXW6DzKS1aHfaEfyNw2+8kzWUcBJXNbgMOO3ODqpH+Uo5 mxW4IZhjf/upKa7GVTS+XtHp6WkqMoP7qaJlOWlsZipsp3M2Tr2CMJaW2eIyW1w9A2eTMQiYX5Ds wn77DM2e/Vgxn56Rs2h11WSGqOqwF+78MucZeOYIPO8qHK5mnHIdshwMQF07lmqovp243g4MUAQG B5qJqJxxJ2fcL6f/c3ecObpHPcmGeuQp4X32iGrRNOv10ijMye+eKIdMZvlUGG/5iSJpDtwIBXaF JJ3P4D4+e9J72NNFDvayjvm5QnWa66Ly35TVOp5CHgNHKeY3WHeyg070AvZKcUwLhEpbNFVzOao6 bIcMY0MabfGxHRGGhfC+zi7nphD7u5QiMjYlkKmZomL5HcNraQ82TWGRqsxrLOrdIqrHrri5pcVy qTxfXqoKu1N4Sfi9I08QTBlrB/mE6nwZ1ULL9JEo1bFqYXFJoIPd+SgIkRWO8tIekXtnxTKhc2l/ rggxPQe59yMHlyvlqTNROQ9qLEYSm1ZezktDD0xgDxB1CZXb3TLvXOHEnJ5ZuaTW8XfdITHrrbQy PGD3ZZ4Y/oEApQFTvcJf7pCTukqp3PhFLhLbIiJ9SN0BC8Q0ShWnTc3bNSL0bhGXLk4ziaH3MkUf bxJ15uQWvHvXOboOa6gI7oKb4LLpVEJTzu8Fzi9px9fzc1tfOb8B8mea/tzA5Tpndyfxfxd0rtvp XIZ0U/3FHCKn5cL0KejhFF/5ii9XxBVsQO6JQO36gN22zog1xEf6ZDPJRsIh15W8evcRT/j1y84m j6GBa14JyZ3mqfjWE0tf5HHitXEokT+TbppE9gUZZUMg9/vZkjRvM9nPKPsDaXWgSgi7pf7OvC2C LHJRxoE6A6p4EeydqlGiRyt7aPzIyCAjyLDKG3aeOKM0bsOzqP1Ad3nRekro1jniLn9TUVilyYZc hom6HkVz6+mPODp1K4VPpKrNnQZukiQU7z6bK/aZcuFXD6BGiMS7fv9KxTM5zFqEm8feUBGXORz1 D1UTJW3cxEeaSPsgmQb69hmPBgbcAxQ/6XIlclwZ9QEWX35ipYiaQRl9JuOWGmkQ2ZCG/MXE173E NqeI0yxFFe9LlAsCyT4SOo5Hp770qFqFbhP7Ap0lwzf5rTsZSk+GSkLGBzOQgEOKbPmtSxVDCg1I 8StOaNQBvFKJXab05KiKPFpHknpCA9h7cmY+LUgbmxaUZtw63tC6PBKMBrsaVpyNOw47XfVEsiV3 VG6SfDNP56PvhTXyBvDJqChV/MlI4T+4rH0ArZJnpddqo0FY8fGmdz+sq4cN++Zfv9+H7kh9DZNF fXiR5Hr89h00nJpMYyOAlidTA5PW8NjQ+MRoCv0uzLHUaBpY6vHRTGrs3qSZGhycSGezSdMEmpY0 h1L3JM30aGp4BMunhobSA5PpQaBqGAwnDQSQPuaFaYPp7MDEMPlyWONDVmZivH8kPZoMmqYZDGaP HDyYzvKHv6BpKJ8dHzmC15QBcoyNT6atPcieosZLs31b4L2vWY5gVgXsnJcBF/iDfRivjHcAT9N3 X8mJFb8sfL/v95zNHZnUwbRl7SwUdplKS46KKM8noj3ja5ohs0N8mzEZ9FJXc2TUSgtiGuSv6vbY VsLqS8Rsq8e2e8Q3dZ2bid5e53vB6xLmYDAU0rsN/da+bu3XczEVPJ+gM8Uha4rH3uMAOCXty3ah Qdu+h7F5bB6bx+axeWwem8fmsXlsHpvH5rF5bB6bx+axeWwem8f/g2OLYTwJ8C2AlwF+DvAGwPZW w9gBcA/AKYAiwBMAzwL8HcDfA/wXwDsA1wQN4wYAC6AdoAPgMMBdACMA9wL8KsAxgPsA/gHgxwBt bYYRAogCdALEAPoBBgDSAAcBDgEkrjeMjwJcv80wPgQQBrgZoAfgBYCXAArboY8AiRsM49cA7gd4 FOBDOyAvwG07oW8AdwDcDfAFgIsXLl5488LPLvz0wkXjlR++chH/nX/l++e/cx5Snr/4zMUvPvOd ZzDLkwBvGhcMPH3zAp4Yn/8jZwi3G21npw8FjJm5k7cf/q0ThwyjubvtbLCn7ez8odCWG5vazjaf /Brka20LDBzeaRxpC+D97c0nsbB259rxw/CgAHhhtMUO30+pxg6qwXDVYLpKB/HvoY7AFsq/FVo/ 0EFVGsFDfBLs5t5s4boxH54dwPffA5AGmAY4C/AJgD8G+LaYEzgf3gSItBjG5wGeB5iA954FmAQ4 AnA3wFGAn+tz69/ex8VL+sULDVOe0y++qV98Rb/44sYuntzYxWMNL4yQYZjPX9vU1fpssGmy9WmY 3UYzzNhzcwEYrK23GtcM3WyYeOPp4PZzgxe8eQOUvfmWgLEN/zRff+6hLdvPlS6az28LPL5lyy82 P7QFs1NT11IOv5RrRMp1Btx/XN03xe3tRou8feFXMKHJ2PG//f7vEbhiHuARgD/Q8MaLOD8A3gL4 b4BroXcf0fDCcYCPA/wGwCcBHgV4CuAbAN/T8MYawKDAEUMCTxwGuBfgJ/AiXgfo2AprHaAK8HGA D8PYtMPIHcTRA1yyDWACIAdw3TbGLdrxzls/o7+vGa/C8cqrfPzoVXn8M14ZL59/6fyL333ua1/9 8vm/OP+F8y894VTQ0jq4trbW0voG/f4L/X77Ev6ehPMbmm41Wk/DSduNRiiwtQlL0L0/V/cC9Obw 3tflvZbWC1TP6/jbFDBajKZQkxFsmjWaAy1bm5oDcJ6m8y34A6nNxta2m1UL4pxqbqFzo/9qvbO3 9NF8Xb/49/dx8cqVVrDBi6f/tPlqVe05bgfSdEvgxlsCTZ8tGm0vDhnND6/9IPSpG5+AFz64tS57 61fqt9RaP3y991ZL2tjxGNUMS9Q5A7yy87EVPxy162qsr7f1LjW+eG1j2d5uiOmfbXjx9feRskFS scFGneO6Wxn/30jUYPu5379kPh8M3NQcmAu0GoEA4f6rMxuMa2axWhc9+AYcztwwdq6HD7281t9q /Nbcdua55gHiNzDfhTzXHwK8q/fhon7xZsOUdxte/Id+8a/6xd883ORcPKOnfNWV7VxTg3fpzrZb W/tPNM72l4GNZEO6CssOxjiYM5ia/8maa10GH9DvW+4ZEDOaHl4zdhTh/Rd31L9rn3tt24yWW6ju neLdtlIPZGvIe9wETMAW4BoMOe+MnVfynpG/fhVg1w6Hz96t8dmTGq/9C7sM4yaADoAywCcAfgfg UwCPADwJ8BrA22/8549/+PIP/vG733ru2af/6ktP/dnjjz7yuYc+/cnfPnf2wdpi+WT+gWPIbSF9 az3w7toan2XU2XF1NqXOCnDW1vSA0fognABlfpaup4zW7/H1999FqrrvEt61jdbPXKK7nyNq/dQl Ufav8W6wOdD6zUuy3heADl/b1EMUt/Wf1qjUi/Bna1OT0RJo/TLdITqN5b70jiz3hjr7ZWgZ0yzV 1x+ps5+ItJ+qO7VL2F6O2/td2Z/fU/35JerPA5zeuSbSY3T3f5g7E4Cqiu+PD9sTt9zJrVLBNHP5 WWKWlpaiwk+zX6blvoaYueC+YWrEXyRDSxN31BAlFHcLl0xwQREhc8UF1Fwgd2JH/9+ZuTN33oOb TxRR+gxz5s67d3hz55wzZ+beyvPSVrSU125Ls85Pox8vqvfheVVINPTfE1QhThWCVWG5KixWhQWq MM+6aoGGzVluYKZtBmIQNcXQSXHgdrScb7wt9+zx26Y/IY3Ugetwsqo9hlVBsDHtZTOwRLu6xJTt kH9MX3rJssiOndqxOR3YJjq2J7JxTcetjS0bw0+sNcqLPj0EjoBYcBOsdSJkG+jyIqakYBAYDu5W hR9ZjZARYBS4D9ZWJyQMxIIz4MuahPiBGyAdeLxMyGBwABwHbV7BPB/sQfOjwWGQAbJArdr4SkEW cKwD3wLMAFvBNpAIzoHz4C54w5mQ1s7U37wJ45CMn4vkJDh6EUk02MkKN69DNhlztmSy8KfZPvR3 NRvHGfaYtTt4jXdxf7UEZu1dPOww/bYj1TCfF3k+r6c16Lxe/8w4i884igypIOusaODentbR4wO0 hJ5Hr5PZh59HL8nIVzL8dQ8/85I0rQ6NM/AZvX6N0Vpb9dqjXSzP+IV2RtLUSA/3Q9/3B94g1Em/ Hz6yuB+Wg3CQazZ7elIhSRUuqMI5VTirCn8Yns1spr7KcNgvt0YhWA7QZ6EHjDUAtFMNq69bhtjv t80sebqsT+VcF65bSIXC9PVe8Ce4CnJABeiE+sAN9AMTQSBYBbaDw+BcVa47SkNf1AYtQCfwIeij 6JM0RZ9Egp2aXslOv5t6Pfnc6ePxRw8fjP59D+bcmyPC161ZHbxs8cL5877z950xbcrEMaOG8W+M WuztOcwi78jRrP1BLsfkULvuk0tTG2b57YR/UJn6A6yuM/cM6rLjb7P0I5Z6snQ6SxewNJSlO1l6 jKWXWJrF0orMi2jIUneW9mfpeJYGsHQZSzexdD9Lj7PUns32X3iota6WsOi1HwqLv0v1QGK4B3JY 90Ca5Iq/JyBX++y30vfIo0WvPcv+zFJv6mIR7htOLIpQMLtoqircMJzaJBkKVwrWQYp3QrUR1QwO 9MgoRzoB4PlgBz0fb8vy1S3HGbXfTtApLqAF6AT6gjHAHwSD3eAUuANKwL6/BJoCN/BpTd3+LwVb wEEQU9NiWmfWLxmF6Mu7xS6Y9eVfz0hINbRG1vQ3vTek1cI9Ur2o+/y05gemab6gPaxbVdAQvAe6 gqFgOlgGdoB4cA3kgHLwF52B68u6HzkZ5Gal379zM+XaleQLiadP/HEsNuZA1N7dkds2rg8L/Wnl 8iVBCzBp9Pf7errP5AljWTy2bCbVpvVY2oqlH7J0IEvHs3Q2S1eyNJKlf7L0Lksds2j6MkvfZKkb S3uwdDhLp7DUh6WzsjTNvShL6OG1WUxHh7Hje1h6gqWpLHXIpml1ljZkaRuWfsLSL1g6g6WLWbqV pQksvc7SByytxGxcXZa+zdLOLO3F0iCWhlBz2Kgo+2geCAGhYPvL/xYXMhv/9wyP/F3swlXrlPTT Fa4axsasG/UGM1c2/gvqp/3KXO19ba7WHXi+os/TSmF+9kptfb42XZunLQBbtLkanZ/ZYm7W1Fmf pw10gT8JJoBAMA9EgPugdl34nHXZ2Nadvf2/7dq2MZyO6UU/zPX3nT5lvPeXQwb2oT6eJzElc48N uXIPRK6rzHnL3Bieq0mYy8X9wxUighIsIyhRqj8Vz/2pBN2fWn5bjONqPEbUjflpn7J0nIgU+Yvz zpbnPa+eN4WfN1U/7493xXl3c7/zN+5xMv+vv/D/xgr/b5z0/y6r573Dz3tXP2/KfXHewxnsWGwG PWMSSzNokcvT6G/jcW3m+txRhX2qsNdsDcZQ2KEK2wwHxRO3oIj+Ybw9dzGk8taMV7PAtrcqDFeF YaowVBWGqEI/Vehd2C/zUbGxgbqf015+6W4HptOwN43dFNt+m/a8VW1dbJ6H1jjSPh6g6WSqize4 cB08CUwFG8BO4FQPPgFwAwPAIPA5CABzQCCYD44Dj/qY/4GRYNdrhCxvQMjK1zF/BG0aEuLeBPoF XHgDhg7UepOQ10FD0A10B2PAbLAKbAc7wF2QC/LeZEM+jdy8jl955HpiHP0PuVgSFbk9khWuJ+t/ Wjh7IZlBJqp/sB4n+798cTJ/LU5WVZZs0CJ4HzQo2dbDST0SoNUVRyrkO6JfabZ2JZOr44zmjjOU umvyRQhDtAghjezlj0NOzheHnGwYhyxD9/gUEJWcqH2CxQ0bWWOP6X0wB3wH1iv3xIvaPdEQtKtn EdM/pgpHDTf1RBsKewwFsx0+W1VhsypsNDyyVhVCDJcljhme4HE0ki1faaMaiS3CtSldQczGHDyl TOw8+TzeU5/H1yRFbR1Ixcfp3/bASxvnIeAPbbwnAff6fNz31cb+qPp8vNdpTEgVjHUnUA90bKKP /xL/wfgBseCipgtyM9JupV65mHjyeNyRQ1G7I7dsCAtZtWLpoh9/+G7WN9MmeQ8Z2Fc2nvpCHWU8 qxe8rUp8DY16Yn5iq8sLrIwGz1iZtvqVoHpOF7jndFH3nCZdFp5TYCY7NpfNAL9mszQ7Fjt0Zd7Z WyztIHy0XsJH6y19tP3qlf7gVzquXyknRVwpm/t+rzJvsiPzJssRkwf3NAcK73K88C4nSO/yuHqF JH6FZP0KFW+yknFi1dOPX2cz/eX8tPs103C5/5bhpCpFFa4bToPMVhYjDDfpXbdupBsLaYVoKNH2 79lZxOGKcXVwoHnkR3hDpnLKB0ilfxuL90F52NqKoMab3E431OxzhuE3ZhwITTPcLWO2eeNXQ/We VgjhOfn37D1/uv+DbTzyo5cwuFvKPqqfV4OfFB/sCLgM/gJ/az4Z9cecmhHyI7gMroB0UNkVOgKs A2FgB2jfnJAOoBcYDcaCCHAU1HwLX8hbdF/2P3dSr9L5f1zMgag9v26NWLtyWRCN5830mTTWe8TQ wQN6M012lmuy15huxCy/g5zvz+Ra05fp0iVCd0YI3blR6s7Wqu7sxHVnZ6bTk+XOTU2Php0Xmrpt tnaedtn00yP5p+fRUilVyJE7LRrkiKs1l7mWMvcBi8a1Y2nvHK2lo3JElMI7R1z16xztqr7yswky lyNzJaRFLCNzVZjFepGlzXK1a3RAxqWgPjYbgONUYYwqNH7kTd+uP9HnOf7FOc+h2rCt1WOtN7Gf /3CD6XTJhuV31SGm6iXyj60GdvnL6F5oy7K5FQuYAKIZ+vcSUJzfi/3jjGnj9RszjXu7EEKK4RJ9 339p/WP2aJjpYsll5Rs5E5NTAT3qWkCP7rGqR0mHkdCpNma9OqtYe1W0h+5C5DkD+1NK9PMCsAUc Bpe0PrfU3W6a7qZ6ewxYAWI13X0BOEF31wCdQU8wpQUhPiARXAXXQAq4B+zfRv2WuI2AeytCToJP 3yXkM9ATfA48QSQ4A84Cj/dgp1rjOEi/ce7YuVjMJffjJ4pEkk3w9fav3E+CAoNIIMr8iI/fWB92 mD4ros9/A/PNz9eKXTmyJDBfbKBjvk95a8/6lOniYYs5ti19nqaMcvze9x6e5ue4hRLzfTi3tRJ9 H4+IEdhbxBsiDCMRsywiEVXRAi3PGzJL+2OUtsmiRoWx1cbR1sIs3d4yjMOaTfojDYO/m8jz/Q8z +wrmK/TPyf5B2MQylr5XJ2X8TtXG7zxwgI7fdzDrecciHmxl/GWDKqxRhdXWeRsjVOFLwxboFr8H cRjBHWBCnoNvWuvzDnrIR7MUVAcU271Zxto+zwJVWnKd7QwyNd1dFnr7FdC0Fdfjp8BfIB28Bp3d EXiBb8E6TZ9TXX4HpGs6/W9QrjXX7S+B7Iw7qdcunT99Iv7wwb07d6j7vL71/3r65AnDvAYof4Lw 3s9x752utTlxj70UsiVsHH1JSZvSpfjRcObP0z3ZrBglKbqHn6Tv2GYe90d8fjGcrcbNY+kmlsbz fWNsdlGZpXXkbnEH0yGWnmXp32LuQURkyEZGhk6qc4/LvH1X9NaEnhKev1suO9aeee49iGkIn+eM IKalcjVzo5jbbLI2LjQmEf5/UfStlfbhia3A9mIX8h6th6Q+stF0QKj9c6T/Kz9qLH4L5oAgEA1S QIc2hIwEo4AvWAKWAZd2Ft9IpuFKrPETgXcNN7slq8KWb+2sqWalsMXQnzCLM4YbHslv9Huwp3lh hYqnlx1sYftsSrf3ZasPDjbcEvrSOBR9Bqi6Hb8HKlFfOkDr34eAoB8bgkagMXAD7dvwPhf9PQHz rklgSlve5wPA527w10EQWAQWgx3gF3AJ3IAVfrUDbAzYAM/zFLgBSrkTUgc4g74gCKz3IOQgaPpf Qt4BMSAWlOiE+xJ8Djw7seGXSe5k3sxEJjXpRCrJi8uLjrsZl0d2omTjyqCNbCUwkMwiX5Hxqv+7 KZ9/v0nzosu09ahKxHP4yvGIfHvo12klNfOVeDmyZ+tHUH++ckFHlbOs1kr5M/7Dbdkz/tr7ALRn /DVJP9NS5UyV5d+0VPubaKkdEnv6/gBSjp13to04b0l5TjbfaFyYMe4K+mv9PgJkgixgj36uBz4E v4Jkre/TgQn97wjqof9bgB7avTAElKT3QUe6x/t2yl9Jiaf+OHooas8v2zasC1m+aH7gbL8Z0yaN 94bN7/0ZX/NpIi3oI1Zx9qQLC/oCt+SNxKpKEx4fbC2sc1dhPT+R1nOqzF2TuRfklZuqV24lbPu7 8vhB9fifvGUn9Jb9LncEHspmOVj1Lg9E7n8y5yXt+1TRQh/ZmhCZs5XXrS9zn6gt6Cda2F8eP0aL 6hRVfz65D/CTnTXVrBSMPYoswx1GWdbtMLLy79H0t9nqS/Hb/ypi7FUBzUBP8A1Y35Hr6b3ghKav z4NLFno7Ya7ycG2MevUDhRASDHcD7DUUrDz1TsMjxbEaVEH2huILGvRXUa4RlXuSvqc22xX00Wz3 MBABs7kR7AQHNDueCLJBLqgOO14TtAI9wFywDxwEWWnQ/8nnzpxMiGXzvvB1q5Yt+n4OfbRHf/SX b1tiezrl3s8QmTsnc1kyV02uCtWQube5/m/J5mg9hRUYIXTsSKlZJz9QtOg34rifPH5Y1bKnuJ4/ rej5NKHnq4jPOsnPNmbnrsA/y7Q/L+/+QN3TwHMDWEsHsXSiaG8BzwBvkbkLMmcvdb6z2trGEOoU th93Gq7YGu/SNFumD1OFqb2tq6YKk1VhvKFgoRCfk3nXY61cDLadXDKiTKlKW+pav3LRq4CVi3X5 Vy7KPmpMUt/7iOZ/3wH3QEX43k1APzBY88UngkVgMQgFJ4FTZ9xXna1+t0f6kwrGT+qkF51w23C7 g9mTOpcNt7UYC09nH6zYURbswPeYBTugxKSVVH1afdwcvA/6gm9AOIgD6SADlP6QkI/BaXAF2HUh pBp4HbQDOel3/6Yxv+NxMVF7f90aEbZmxeIFcwP8ZvpMZPv9P5OafxQxdea6Hbl+MjdO5ubLXDDN laV+NN1U5RhAStowr3q49KpnCA06U2rLMJmLlbn7Mldd6tK3VF36gfCv28rjA2VulbXzlWnyOYBj ucJSJcjcSZkzSdvmLHNtZc5N5obK3Bcy96XMjUCutqfWn5Z9NAp9kgoyQCbtH5ALHoCHwPQR5mKg JCgFKnxENxNiPgqqgBdBVVAD1ASvgnqgIWgEGoMmoA1wA+2BO5hGP/sx7gvwHvAEs8FCsBpsBNEg pSt88m5oD2jQHfVBQ9AWtAPuwANMBzPATBAC1nRnznwOuX/j/mmDn4T7CbTKod/IdvzkReSFRKyK wK8g/OLz9P/aq/N0PtPmR7zsjGfw+qz/2j53k3k04Wq+kr+0EvN9vLXk8dAp7mv4up+NWY1KFgXD O5axL2dRJtcbWz2NsdsfLAPh4LB23yTY2z3FeYGVk4R9hnvKdha7YBENHkUcevCYXAARUcJi8P+r GPVfc21sinHpAXoBH22MBgDX/6EeeB94g4UgHtwCTh+bj+MIjNffwY2ufOxmgGYYu18D326K/o8/ sn/fzu2bf16zcunC77/z9/1q8lhvuP6WD4pQXfue1MpzrPXHXeVu2/BcEWN5SUZb/iPtQjthF9zk mYfLnO5tR8tcipmFkC2oK+zCq9IGxKvHz/MWXtBbuOSmaGFjvurThK36wJq9kSvsWguZ+0Dm5sjc BpmLlblEmasqrWMzqv+Lqq+N3+eVV4iwSoZhtduGCwl7fO2sqVYYwSyAtMtwfSrScPT3KLbYjzb/ sOE6iFR51LgMBPvAdeAG2xkK1oJd4Dhww5/SHQwF00BQj6cQKzMP3c21fyaBQOOuyzP8zC+G+x1k pIK+j20i6ehC3nIhLVzwrds9T/PQyoXt4/WgQU9CWoIPQW/QBwwFU8BU4Ae+Bz+AYBAO1oMdIApE gz9BUk+z2A99kP+XLRvXr1mxZP4c/5lTJowa+nnfT7W1/h5cb7J3tEkpRGjrNSyiopVuNquzS9TZ rdaJMatzUtQ5pda5bFbnpqhzS63DVvelVIZr9bJsB3EN8WwIjbdwzd6aH9/FjiewlD8NbEccbE2f ZQsrNCxbfGJqNvvELbaD10G8r6ZantaW6vIdcVNl7ozMPZS5N9Ro1rsQaq+x6OvXMNFqAF4HruBt 0Av0B4tBGPr9ZxAOUkAqsEf/OYB6oL7F/UDvg1a9CHkXRIMkGHLfPoT4gziQSOlLiBc86KFgBQgG K0E02A8OgkSQBtJBXwybCFBzACHzwO5BuHdBCug1mLv398i9GyTpFInbjyG/N2cvinLIDhzaQNcE Q/OWhS4OpfXmsSXCAIuRU9qVPnnHt/Xpq4a2P/Adfaq/39fBGn//fk/LnX/pMXwNT1+P069zJ8Zy dfJOjOXqY2q+kpQYyx2K1/Kd51qMxXvDmhXFWE4G/6hf5z/W7QMwfnLkuqEQ2dso9GgmRHpZV83K s421rlpQAbsCHtujb+bgV/76i8T0cen8On9g/migfQ+x99fiXQ+luGhujaqI/sruSYOG8KtBZVAL 1AYtQUfgDnqBIcALTAWzgD+YDZaApSBKG+cJIBbf5lFwGlzszcd+GiiNMV8WzAc/gpy0mzcuJZ6K j9m/Z8eW8JCVyxfN/y7A96spY0cO8xzQt0d3uWpicnyg7YAK5PH7eUxuTkxrpedupud1L11qvWPi eLw8fkT1yE9z3XxG98h7XhJaOE6+H+wiX09O0t7RSV9DoVuIPNUW2Ijr2ar24gUzm1JL1Kmt1mls VqejqOOu1ulmVmegqDNIrTPSrM4sUYe9pqJWUfW98bv94ryMjphXC7au2lTrqvlaV00VDqvCIUPh gGE4Yte/xG2tenNBEeoJTRNVeZxxGgqOWtjtc+AaKAeL6NrP8uvsZPQ9GX/r0YYxnF8Mt+EVZkOy WXPMnv+MC7ezptW5ll9pqdFiuzF76bYDsYm3NZn1K92TrO8CNzW32AvwLCM/2vsfK1nbr4PBAQNf rD/wBhs0v2yX5pt11fyzA/jT18E3CwPbwK5B3GdLUPy2nH/upV5JOvMne+/zr9s3bVi3OnjR/Dl+ M6ZO9P7Sa5AS//ckphtUR5eyHUO1c92zQvNvFe843Cafe9uVq2j2g+L4IXn8Z+kZJzGNyf9PCqaX uTevSd30dyZvUy3FPm4ponRL8Y18QrADtw/uzFMfTdi2Ychb2L7hWOG/Jwn/PVm2o620SqNlLkjm 9qqW7IjQ5LGsdDQvjeVt1+qc4W08q7exS5Joo4n6/0+7b63UrbGG6jTKcGAb/19ejId8mGFzQg2F f/kTOhmdWn/U4xEz7tJSSdD1N6EliuvZkP9n70rAqyjP9TdzlpzsKzuaAOEQosYQY1iNJ2ExrAkQ VBZDAkkADYEk7GU3ilIQruXeep/SWxe0tm6IFnBBIgIuBURbsBUe4UHr7m3E21KFJvf9v39mzszJ mRADiL03c573nH/mfP/+f8u/DsXb8WMG+lGTSmV/6helLa7Ku8w3q803K1t2s+yH3JYzWNRNuXCJ tbrDavSq4Z0Zl/n6Yeo/NFhdvwScBbqUgdeBK4BJwB3AcuDnwCnghhnoLwL5wC3ArUAZMAOYCdQA 84EFwFrgPuBXwIPAm0AlLMH7gA3A5pmWOeC9u1/cse2pX2/55QOb1t9Tu2LpwuqKWdOLJ1r2e5yQ su2kX7ZlyCfv+fd4bBB7PFjabTVGX16VVPv0cZk/62P07xtj9MfNcv4T/f9Pjf8/N/9/Rob3D9PO jaPGnm3jBN5NcjT/r//UejADjFmH8UbfpbxBp15orFR63nD9znBtN1xHDVf7Rt2VZbgWGK6FhutX hkvkq7te50dN9a3X8dlyokFavS4IqLeYO4i8wC+AZ4C02URDgEYgvhL2xByICcA5F/02wA30BlKB a4DBwG1VRHcC64EdwD7gS+BvQF410QRgObAGeBGAwqf2wKNA6ny0V6AEWAwsAX4CbACuhznVHf2C OuAo8PevPjpG7x15i143f+pe3173XB0cv/V/HsIfYgOpJDGPnDianMGuak9izCvGeQ9njHX6FU/M I0ZVbvsRI7kH1L/SO32zjENf0y12h/L6cWOMJ3Wz3IXqT1fq5sCU9m7yJEV7Qv1aw+/2I+U7bbfv 7bS9sRwoN8d8M9v2ZpZtAOZVXtosi7C8h5SbTiIQJXT55Hp5QGp6X87URFxM+Z0262Ks++53MbeI 2U82PmubtrO2W36+tu0zspbVOn68u8a0z8ajbb7ZYDz58cz/xOv1VgqUA7uARIikYqAEqAA2AL8D PgGi72gq+7cCR4CjwIdAeQXaEFANPAMcAVzg32tm+/XEYpOuGAPkV4p3//z3Zx+dOCb6gHUv73j+ mScfe2Tzz3+2bs3qZYvmzamYVVo02T8SuM+vbdcbeym0XlZfXiVboa+SXa33k+40+lFPGK5jhsu/ LzPbrN2H69p/hPH/QfP/70vtf8yfnnr5noHd57Tztv4gNX+e3usr0nt9U41e3xrD9YLhOmG4VHOv L1LPTZSR8nzD5d/76TFSG2ZOrc/fl+WjyLpf7Lr/WyvmZC0LJXe9rNosH/6iFTe7bHf5PW3L5U/b diCftl3aHCDjVf20V2Ov3WUZ3bFIpLAs+YKwRaZnFH8h/DoFiIHGjgW6AgOBkjmBfcWu3380rYWD CJahwt22N/YLwXZTy8YnK5w2ZM/b3lCz2uFH00ISmqvHjcCbwFWw1a822e13AY1AQVXzNnxidVM7 /oUAW/4aIA0YCGwE/g3YDDxSI9YE1EMfvH/k8IE3m77xZd2aVcsXVlfOmKa/DW6JWc7dpUvtuw05 eMz8/6dSan/ml9prjZ0asWf1HtJEKckn8dlc6/j73/n7Ff7+PX//D39fyTPzvfh7DH9P4e+7+Xsj f2/n79f4O4FHAu8zThNgzfCx1F+faLNKnxoaYIQh1/06bJvh+pPhOmPWFKpeBg6jDHaYy2AvbryX qp4tW7/tbyxzLPbvdN7XipuXL90/rQkgcP2iNAFN3G+SBZf4VECTHGr3fXlyi9b/fgn4ADhZI/ve 9lVsvyfC/vU3lrd8WV7U98QoOzLLW76esA3acrjYL803/2G+2dREp1dRSJV/7Ham4oJK9arhw9bL Xqa1XH/4/f7Wff3Ctg8r5z8j94eT/+WvAe0utrk61cdTNgLbgR3AXmDVAqLVwHrgSeBdQFlI1BtI BYYDc4DHgBPAdYuIMhfJcZmRwK3Ai0uIopbKcZoewNil4tzHbz7/ywfHjv7h4FuvvfLic0//Zovc A7Jq2ZL5wv4vMex/TWYv+0Ke/6hb2jdIS1ue1PKNf0WVtiNCnM8rJewUTcL63xb6rOHyv2+zmyFX bzJc5YZrhuHaYLheMVwfGS6HWeZG6TI52pDJB8z/N52viTnNT65u0PLokysfcvATqVYRqzXPOt7Z gjteTxwrcy3OIg5RPev5P3GSpAy7ulHmvYbt/0tVz9/ZygP7PV/ftbCH8IbbhuzyHwizyzY/TWXv ZVv9a5IV7c7Hk+OAqcATwJPADuAVYLdpfDV+GVEvIAXIXta68+Hs3wBUb/uPZSGY5SVZO0bZkW21 Xa112nao6HQrEvpjqnOzbtDXfkubgxJaW8c3AqOA0cAYYCIwCZgMTAGqgRpgDXAPsAPYCbwC7Abq gD8C7wPn/lb/xYcf/PnI2wf2v7brhWefeOy/HvjZhnvvWrF0XlXFjOlFE635DNyNIbbwWXfw+W3k e3kkSGyTjvbPB/Gp8C73QyxjIVHFpH6kQiHu7ewIE7LygP7sIDsQmvsQu8KNszMilSjzGFAknyzP 4linOm6l+kwP83MtHpbviz5nqXyuQUtNjKSSpxBzWqbr/kqNtJTpLgRbAbcRx0J/ShaZaPaadcw7 Ug/w+E+SuW6D1dv2gLoT9dYgJmmXE3UGugKZQH9gAjAZeBJ4GtgH7AcOAAeBt4HDwDtA2AoiL9AL WAgsBZYBdwK1wBrgHuBeYD/wOnAQOAQcBt4B3l0hZ48VIATwAGFAOBAF3AzcslLI4TPy89VnH+sf 3J44fuK9E8fpCD6a0/pzhn5Ul1iz60kfMYRm5xHPKA0BW8vZI+EWJ/rw+Z8hoBOOOPxmi21/yZQ/ wkljAfnODwqTZ4wKd7+Lwcvf2YpEy7abVzPtyCxD9q/aqtCdtv9st/3nKdtewRbbm9ZcsKvFMfsJ W+qNMfam4/4sfX9UfYWYQFn8IfAl8BVwGjij8Xujiee7mPj+eiAL6Av00+TAIc6+dr1uO1FzwTfP 2Q7hHppr94+VbF6LyFp4c+ge+/YQJhb4qNG1/Zzmpx7LUzwxfHE99dEbBhUqJBqHI1NB+3BrpRv4 q73/PT78oyRyr7CsAmUS9zvtzOR8JVysOhey/2bgFuBWYCIwyaQPntJ0gpD9/wQaAFoh9UAXTQ8M AsZq+mAR8BNNLwgdsBuoA14F9gCvAXuBfcB3xusC3tpX99L2Z596/BFxcNhP775z5fLAa+nypbxi WIWWVBWhZzcZ73L2qAnaGJywJz4x+oH+cbjPgvQSvzBcXxouj2aThBqWSJjhCjdcEYYr0nD11Hx6 jSe9DFeO9l9uQ9PVgiOCzAb5zzKbYLiKLP1XSv8+dfcasFfT63b12MJxvxbevG47nFbXsslg+xvL 9M0ztmT2h9H81l5TJ0odkAgzM5GiamcqsQB5EqmLt7hHstqxtr6xU60iT2Y02eYJdOk5PkAuxV8o 7+3X7LAGoFGzxyJWtm5yp4XvD7N/S9hBW2vh4IWStTBSez/G1DX5W8R5W4doQ1eZzQPP0WHk2NQ4 zFWaMNtL7m1BrIAro5s+C42zaaPtmqvDgcAgkx3dcPbst4y/U9v1L3hJXSc0n0tNpEgF+i/MXM83 ANnAjYAPyAFygcHAEGAoMAy4CcgDhgMjgJHAKGA0MAbIBwqAscA4YDxQCExY2dxWQPs3tX5jOy74 TduN9SZgziJR8DlMTJYloX5pw+vOIXSoywQTf9uf3dx2/Z+RASZ7Q5jBWRSVriake0IKwhUP4C0I pcStd6YlbX0jp9vWHGd3oMfGHGcy0HMrUYetp5SOQGv93UCh6c7YdCUhPT2kIJo8gPDatUBpkfe2 CrzIl1gPM+RCAzn85ueLv33xUOy61bCKR/4mXKzg6gBEkXj38wwqJx+V0AJgMZBG02kOr+c9GeAv lcQ63xKaRRU0DzQDmvX99qVMejxwO9VQGRJQRtVw+WgUTaDBNJTGUCGSMZjyaXSQTGQ2yUTLwvnw UmanI5CL6GchYZWIdBwSJhJVieSMphzci2SMoeHNZCy7Sca+b4hnL2UWryRxrOZMTlINEqgn7CY8 mYPmU8ZlPxQJGw668fiI5Nlnd0ST7F5I6P8PajdeuYRZTAZGo3xvQuQiQh9KuBDuMYhSJGcI7tNw lw93IehGwT0Urlv4yUj+1y7rNzfJ+sWKqa1I2ork/DG1XW1X29V2tV1tV9vVdv2QVxxsmTBSaDJF E68UA2Dp+L5uVPEbQW7YLXPQERCWT4XeN+ZVxVHk7OxfV1xHSWTeCD01T3HekfeRWHDiqQHm5YU6 p5HiUxDLNIQbSnnoTpRQKeypSvSNk8TcF/VHShzJ5EpW3GJ9RIIWvjPfc3vorPBdESKi6NrOjtja j8/FbzmpFMFdDHdJsljrcL1nFY0g1ReLOEYEjSMDcfTEv/FbfEpyqVMhpaf4dnrZ3Yvd1wyhTT6v wl0qB4eVGzSs60BxBWKNru2I9HyK9LzBE/c+r1qER8V4xH0+p68PwhgSNAwxVpBITpRmiNLZofza idylIrSj53xeRxGcxXCCJp1cHEp60FCuB0UE6s0fivDhbsZHFvtwB/gIacZHX/YRYvHhJY+vCj68 QX2IfbyqWOKAEEObCbk/hxxqCXkQ5fhONz6E3whqj7Iro3L4mc+WdxIVwF0NzODvueiVJ9EwtNJK mmdp21nUkC9m+bM4/Bz8X4mQFtFUWOAiRNH6o8XRH7K9iXnRkmRF1LvwF6eIeg+3+CtEquchFWXw 255izH4LUPkJwr9sh4Nk3JyDOAsPJeG7HKGI0aAkHknQQ3RTLLdMQt9C+D6NX1Hm5hT04JjjzDGf VBIQO8c8EDH3owRfjpKh9OM2UYg+xmCt5cdRPFprvTYBTFQEd6hI7QDPKuHTR/GIPFfxWXwKvuxE CYIvI/eHGTzPbV3wXZgIYaBYc5ZAV1M7Xx9lnHK1JQTBKWHUDnELjj2puCmL40ylGJYHqZzL4chj KedStrYw5DO69mF3EUCgibahzWLaDqBd4yoCBG2UDe31TNsRtBXOolqxrS+VIm1oM5m2E2jHghXH OgRthA2tzGFn0GaB+bNUQRtuQ5vBtF1A2wWl0QW13Z3CmLZ7E9o+zENdSfBaiu9hekfxcpscxdxT Boox4IrZkKiiNYkrjbohrD1KGugiLWFZ+U6EK0bM8igJ9KeVPJYHgovmaG1TpCtR1nq8UeuOnzom dO/oJVWV3IL0assN0dITRS7UQRySHpsMqRPidwiJbmo/Ors5SXgfRF7kL1aV/KKno1JLTZLGsSI0 MQg1nfnFA58xNDRP6KgrEHd3dQznuqnvQi6DeSyxuwv1whNgpEDcNlJsrdJYhN9i/GqpyaKuCC9D zeLwrNyrl6mUNmHgSKGRhCYiyCLBt7nqXPgLQ6wlqBnB21NNKRhKybJUMxyyLKK6Kn3V8Y5K51rX oyiY455/hMaHXxsxIrI8alXAXH78lhTwXQrznUxprhajlFXWGM2yqmegxFjkl1X9OIxpqpAYHs6Z aFPC5wJuge3R+vxat4B0rUvgkYb8ErVazQziU0qcXvzG29jamoYi/BbjlyAlGvKr1NXq1UF8SU5K ga9McH4mOD8b1Dnq/Wp2kzLV2xhBEvcW+ZNSmGWhv10Wcu4eVgu1tjELrX8+t6Op4CM5Ll/JofQA t5qsD0tbTdDEuyz3OE1C71EHcB6sofbg+YOrRIqsxU26hG7IH6uqJMo7IsCvudYiUVLaqs0EBIIn KfDZTTmlpnBZ5KC9zdVSP8vQDnxsJJfx13SayzgiCKWuAVVIDKGhkRslThEaOioItTlVKl1Lsuah Ix2ZrFtlaFa6CITqkNk3dJPZl8fkS+eNOLQ3vaX5W5nUpd0dg9jXUKpCaZWw5pzDr4XvhLbGHBWl 1ZcaEd/R++oeUVta3ijDIfLmNLWZ9mhrQgZF7o80KloJ6Vynx5fL8cm8TQ/IWxxyYuKnelG5bk0P pmuaX8Y3naWGsJxjoX34tUudHfFbHmQmQnuAJkTqZXwZrDX1+HpwPFn+FilLksw8m6tpeTEeOR2y KZ0nA/rK0jBla7Z3j+HTR9dCtq12+Dh9o7T5DGEX94OnGMOT+qg73yPM7XxPbO2zZ4rwW4xfUA7j uO93DDP0VTniL+U0CE3V3xr5WhcCWeuKrV3wXTxbHWtdxXAL3cOc6cjjlEirTqSkN7jLkpJzzkfd IiWPumNrJ38rDO0iuIvh1jgqm0Pa5sjW7KVSfKp5TqaGZf5Aa3h/jPvPdrIjIcU2eKAhP5Z5QdT4 zAALVZRqKFqFqGifN5RIi+9djs9DI0G/mBaylijlGLvQDYjRrYr4gjRoSDDh/5RD9ISim7ToQLmU gfgC9fBZ6Irjnj3mUikwSoUbvqyl01xLLhqLNuiv6Rut5XEdlI4I6ThqOhk1fRw1nXxGay+ibPo4 MhxpXLazkaoyTqm0IqLQnhK2pKusUH/fla3uXkKTO4XujIX9JyZrZ2v6Mrged7Iel1wQRxkcj84F upyKEr0xneNYngjOSZK87UziFjRG0/dCRg3W9KOXeiM1OU5pNxVwryGY3ZROV4IrxjnTWV4Gptov oVTUlgg5AWGx1nQWcMh6egfjMxz0hRoHJ6Ie7HQKG1C6BZUg+ooN+Q9TlRN9Ru6vjEcq+yAcvWUR dRO0uamcM72nLXvZ5KwE5nsUup3Ttdp5uyb59VCseSJIiTzZqlKMNIX1VSudol3Fh4+IXBW9M/av 8d72dcblT3GWluIBlM2W6wDN3vdLyE4oBbb4TMMEopylFhTtqlxyv7McuXVp6Uxje6Mveu+tS1mc XpamAkmj9r6xyjZnmqVPIq37kbwZugjQ8hQnZEEH0O8JoJc9h1Ggr4PQqHOY6TuC/t0AetkrGQ36 rehpbHWa6TuB/lQAvezxjOFTQYsAM31n0J8OoO/H9Pmg3wg7aaPbTN8F9KrLSt+f6QtAvzKkCPDT b6b+qMM412a2j3R9kAR+m8+aq4zvRP7nQoqEecPChzWGiM5WbO1fGrL3FzbyPgaxJVehLtoCnR31 FzYqJfpxxQieaIomFaZw6sYzl/nlpLnFCdmCVhMSwGZC9QiVg+YRA75JIv29DoJvWLbZyP2pkA5C 7o8noa6l3M/U6DOD0s9i+kKDni0CFLNPswh83DMSqwjEqIWUD11pguCTkCbCYa5qsimGaCMSQ9ju 84cwz8JxNwfpY9WbOE7kdqxLz621LGVf00W3oABJ06rCkqly6eM2gfQZPGJxK8eh57SActGW7ncV sI9ctgoWW+RnEk2kuNJ68i9D7xMwrhDORybWAPPRrsppMEJ82FWOEGOChBjYH0umSU2sn8Mqs7k0 Pg6jXKFzpZDwx5NH4xDPNlce9z/PF48+njKZ9PE6/2Cd0El9nHtcSQGjp5WsPcQLJg5I68F1gGuz qUYUFsR6uk3kI8wbLtjNkp2ZCp8/EVv7QIPoV6D8wIWkKB65E1KhmRoXTkYYF8aFM5VixCIkaweS h1qGgHdCLCVXSONRcqdchS0sueu45IqQh0IYLk9+W4TfYvxa6z2FJkBvf+1K0cYMF3OPpJqtmEq6 g9tedqqSm6reL7nLfT8oO7OWq+ayNLdV0XbnaqOG85hCyDdhY83iesmiYq23ZmmKURDEQiCLJi6a qrc0QiHlNk1Eg7Haae0+sDWtk/zqXoc0dfweaRqqWXzX4ZnjPIlJLnVbE0N2qVki+0/uJdy7C56a MiPmaUH1dlTtLi32mUqyVgy7jJg7ajFrr5k0RV6ryb5axJ3Q4pIQ6Zh+3hJoUh22JbBT9IYbc907 2bYsAYdVQi+KETQh9VYg55H7C6jzTIiKfs4HXZ6QuZ4/hfrCH4+IiVoUfTImL25rfMd2K9t/2qGg 087OSV3vuaL+yluT6rql9NiYbM8+0bWPq3GlPRvlfj5ZXT3528vfvfi7CFQk5k3c4Cw3z5voKRdz JunU3af3JkNQfkLu+3u+EciBI9khhxccUsqPo0nwMc09DnaV0PgVvGal0iKF46lc6/uaitfgcf3g Wr9NmU03gxur3Nls04vxNWEZzIFlWoayC8ad/8vek4BHWSX5+kj3n4t0QoIkIjSRw6CB3AkJRwIB khA0nAEMIZDAAAESA3JEhHCMHN8oiOuFKLDgMeo67CyriKuDBwijIjLojjgywWNlEJ3oeqAcvVXv /d39/u73/nQnAaLbzVdNqt9f9b+jql69s8KYdobVzmogDdBLlOCY0zKR+soiG5FCe7BZ6Cgn9xDk rRPzuYsUvAuXa9oyMhp7HEuZlDPamzjIVxCOoNcRL8mOdXqzTseg9M9Wg4Fk7xrQC/xQ6qNaiqgt Hwv8ltLeNpnW4RydOgwGVsEaGZyAc2UmtqrGRvkLXGOEaibr3JDsm6jGnq++1nEXdlcGyH+6M4/s JDfHeC6bibLMVVcrnH60nWob2lyc4ekDz4UfjHW9IAjl/AnL3sjd16rC6u4g1bdFuWqEe1saGQf1 fczC/OchVAoqIf+8dIVAf9dhzblz2Euxsd1c1QrMpT2ec6Rv1/hvqZBX1wiPHpxeB56C/RJ6CmwG jaqNRVvfUa7Vh5vIyIIuNKt07svxrQXnvoww1h1MPZsa7CnBh8BxU0lRiOu65jT6tNGa5tHGSbS/ roV2ZuuarCpU6YOcJ+WuNEVZoeNV5+O9vWacUVSvjPqdq4Kj2ZVMplkGnF+hIUIUOp5Dtk+TZOAa b8WzhTxX7Wh1KalzOgZoDtERcHJGT4B4ewKDW+mP41wGZpdweb1ELtV0B1/vEvXM2RqV3WvuBPX6 AMGb9Q2hw7PNUVWnaYM2qTYRmfek373od2/6nYhXGxwMC4ozORd+8Up+PFX/4PG8mQbnhZLcxZIG FfQ+bKKnFUcIwqDsXVxSRqh84OwFG/0oVPLxKbbx3Ub9HEJKlxGMDuhg2XT+pc04/6tB5av91agW QPurSX2/9lczO+fh8WsQcY7S+F/xF6vXr1a1PNpfFTq+EX18qYdOLja0CRR6zatC21ChlanQw4wK vdxJoaZZUei3OwcTgQjvscA6hXf0RU6YwxCSxf1d6/qbqDsW9KCEsGtFRRBlcEMMQGeAMQAbAe4F uA/gAQMr/B+iQc/AnF+EDmcymByMrI7RFfGGfbxlBU9Y4Z7yMYTQUUAVPWFAqEYvAVgJcI/afKVQ CbuhCkZAJW6DylsVQ8izkNmn4wg53IWQ57sScn88IdPBouX3JqSwH/Qv8N4XAD4D0/yHDEJOZxNy YiCMiECZggsIiS8k5AJkACN+Y9RfjPyK0f8wAhhGgcJIMBgNBG+Ex1vB8WZgvB0Wb4jEWwLr1Zv1 B6m3fuDJcTw9jCcI8RQZlm8k3X8L9ADwCjIaAF4DY1zs/6D9ACbTkQmhYxN4JXjehI60ce4Y+wGc 7cMQYTiankvYxe81dPaBXSkP2SCLqBUk5A4APM6vHkKnEUdWExaGBC9VxxsZ1gNgfMffAWwE2ASw GeA+gPuJeu0f1HkECOrXUM9vQx3XQ/2W9CSkEcxXYiYh10F7hkAdvjmSRTzHqKkYOQ+jJ2EEDbxF G29Sxdv08EYlvFUBT9ZinRSrMjYObQEAXmdUjjNh9HAMod4S+nJ4jT32GYsJeuwsEgqQE4xcthZg Ax0VgtwRdjuhw2GkmjqeelzzqTc2HyzxMLptv5LOfTP/ejzdul9HEkDZRgJMMjGV6wcwBMCRA6Uc QMgwgBl5hDwM8ALAxdEspvNQgEKAlQCPA5yB0puhOXtPYPHgtqtx396BogRBkyXMZRracWK0I2YN 990g+DZFO+7X/OI8y9Fd1cH3CbsCEnWvG66Wqzo4CaBM1b+O3fcgF6/vCEKallFzY2myo50KYzZz pGqzjOrfzu5jBTE0pRlwxt3ahJ69yXy4sGxNt+fsT5WmPXL4iZUfXXCQTPV+aqd9cT+7pXbHjiE3 742LLvvf5PxVafc6yFnps/12bih/6LO839942NR47s6v73CQu9Xz+xEjWLA297Pvk3eO70z48wfF Q9+bsO9I9EoH+TicPbt1jOez0x4YH7v2lfyhs7+qOb5x1vhMBzkUxp5dWuH57IEFJ3ctaSj6dsWp SXlDR21scpAuah7y5nk+m537ztjz9mGFz77Y8OrucXkLHaRUfXbKEvZsLun6jY2WlZaYNDQ04BVK NtxY1rSZTv0oTYpa0WjEI4ipCZ2sCGJuuoH+HtxkE3YuIZQOlTRIfX4I7VTY7wYz62nGktAmFJw/ GfCtb9Fmd+C9OcRswm5rsIndyxPZZHY2OWatgPZR7qxhBybL2ksGbZ/nyprCssb6+l507RZnJ9E3 TiNZJIOkgz+ZCtAfcHlauk5ahk5apk5alk5af5rGZqDSaEomfGMeM1We7rRMoOkP44p04JGi4Ykp 6fAbPpMCfD15ZtDvFMDSdOhSJflMhr+TdOjSBWVIo79netQZT5fq8T4tzzSdvCRL6ZLV+nSmOesz Wc2NmC6LtgWflkZrmMlKf2FaMv2XJk3r71VnzrQs2r7JkrT+tO6801hqqkf5nGlpkCpOS6XlzPCQ a5aWRfOR5tFGLK0/LX+KJC2V1mamVxq2D2v7FElaOq1V77QsWgZPnijp6bSF0r3K4G6/DEoto0uW tnsGfS8awn+A6UjAu6DAomL0zu1gzO7v6obFdgaPg3f5Iwzm3+rH4F7w9E70J+Sj4YTEFTH4bmLr 4KUaBhOXaUcjJm5cYeFGCMGqtx9BR6zM6w/nPP9I1fvH87TgIJMYdSTgPLYYS2dncMWc0H1u16m9 fzfaYTAvIJ6OpNnprp7oRUJGmiAjw9FSw0srAM7AC3cC4R9VuMfOIALq6RMVDkB9fQj1dRLgp+Fs 9RQhaFLLIQTgdaivj7k6ew/c2jMA1eDi3QzeYU/wmnsB9AYoARgNsBbc1+fqGbyhwgGAowBnAL4C uKDCRRVCwN3tBZAIkAMwBKAEYBLAIoBlAOsAdgE8CbBfhYMA7wE4VECXORSgN0AfgAEq5AEMARi/ jJXFBC0uAiuAEb6t6t9isGr+Nnr9xjjgZygIRwHARhCQ+wCsIBgdAL4A4TgL8E8QjO8B/hPa9Q30 zEEopgPU9YHREMA74KV/BPD3dEL+B+DjLBgFAfwI8BNAH2jvRIDOMAKKBZgMbT69iI2GjOD+1QJs Bfg9wDMAewEOA3wAcAZAARc+BGAH+L07AQ6B5/8hwAZo27sBvoNhy48YL+03GKULvFLwf+cAvACw D+NqwBBmCcC/AjwDcAKgESBkPounkQYwEGAuQB3AYwBPAqTDkGcQwD4Y7vwXwIMgNw8vEcuNs+2w 3aygUa2DIA+IayNwyw6CwxFNrYV8xIK7KbJhtLyYzidV0THOAsDxROUoGFWVkTwYD+KaAdt/wU5i 19EZ4AX00gDc61EDngHuf02h1n4qKYQxZS2do3PuhqihJ/On0n14s+la1VS6g7EvXSuo0s3jMDWP bA2jEsauvwEM94CMd/2fCM7pCOgLMly/THX9MhU4VNF5UMxFWQvzyXZf/Rry+Uto84BcBuQy0Oai fKb+Qtrcnc+NZJnD4Tg6buExR4TnPwO5E9LeWHk6R5S2HNL+lmZMFKWtgLTOls3ForQGSFuyt3GK w+umPgNZCWldm74bIKJbBWk3b/zjOlHaakjLf+uJelHaOkib/M9LX4nS1kNaxoDnpojSzuPN4nue K/BOI+SSQ/0IyhC5fB/OmJhFafv6HpOmRQ6MMfwcefouUdrbHRsN9Qc/KRTl5d6SLw3PvZcVKkqL rDtjBA9G+L7iCYOCZHl5OewLy4l/N54U8awecdaye/EAi4hu59wG6+TT5qMiuuPXbrPuO/JYuCiN VCYqPSpSVonSyjp3CX7lWP5MUdoPKUdCQiVluPdOW1ifx/f83ZvORnLrHw77LDTrURHdhnk/h8vq ZcpNqyJ+6PtDmigvNyT+GPHd3N02UdrcWYttsnwOHl8S2aVo1eeitD8NfCuybsPZ5aK0W3pWRvXZ eNYmkt1zvYZ3lNFNmbM5Wla+B2os1+QXPdBTlBaV8cw1ERK6lPnhnWVplYl74o71qPpOlHah/vk4 mcyvLzwcJ8unYUz3LrK09aWPytNG5XUNlejDg4bCrjK6/mPC7bK0HR1S4mU6lpYyOr7s1GfbRTLx TfnY62U8H6ko7XH8QvFXwrzkxPTKmrenQpT2WI/jvbOXH3le9L5tCctvkNV1UsWpBFlephduvXHI nofeEfE8WdT5Jhnd+/aYvgZJvZwoeanfkdc6nxSlbZ3yUr+u1w2/KHrfXyw3Jsved129PU2WVjY+ IVNms55OuS1TpiuP1CzKXDfj9N9Eabtz12Z9MMj8vEj/utfHZ8t47qr6MFuWz2nDbs2RydIL8yIH yuiyR44alF2797eitAkz9w+W0W1JXZsvS4td+H6+zEZOKSfDZHTE8tQwmY6tLM0Z8fYPrzWI2vb7 FaUFMroDtszCu1aGGUR0/RNKi2R5KRl6aqSsPk+sMBTvqpy1SdhPR19fLOOZXlo6Sta2Oyu/GSUr Q1J0zzH1L9+zVFSGnRO+GCd7n3V2dalMj1KD6kpl8hnX7dlSGc/zOb+duG7Q28tEaQ7l9Ykyujdj Z0yWpZ2e/fBkWb0sNOyaPP3clhdFulJa+m+Te8w59LqIzjzSdqvsfSMW/eXWTXfPeUhUn9ZIe1mS acwZUdod0xLKZPl8sCBzmux9p6YUTNsz55MNIp7dw6+vlNGZOt5TaZW03+oiR1XRpAfqRDwjMnJm ynT6o4FDZsreVzBl2cwBSztsEfbh8eWz4jqZhX3HXwctmCXjGVy9Ztb2N78W+jZ3dfx4tozujWFT 5sjqOnr213NkupI14qZqGc/i6qRqGc+Hi0dXy+r61U7/qJa9r2JY1XyZncjJX10je98Wa6/bXtn+ 2lPC/q/yzG2yMtwY9OVtsrz0yX6lTqbv2WONC2Q835qet6Dgy6P3C8cr5f+9QPa+8ltOLSi7vT5c qJuL310o8xkKh2TdLstLh7Gf3i4rw+HsDotkbfTFiv9YJOPZLT5+8fAZ6268jXinZQ5+cbHM/3x5 wveLZTzLy7feIauXr+dsXS5Lu7voMWna8XFZK2TlmzHv3RU3v/fZQqHfk39hxXKz7RVR+xlcq1Ee n864d1Wx4ibIGDyDqFgt5YDjuQUjt+FPRsm2T1LK7UEW3EfuK2WW2UWZZQbKLLOvlEeNLsqjRgvu uNVSXiPYBBGqU85boPcfDVBzAzpJTfosxAX2i4W45H6xEFeBgIW8FtkJmBh2k7nFeVbFl1oUU/r4 chNlsd8UuSb3AmWx32TBA4EVgAMp1/6KweQnsVkldjMI8o+BxcXA6JZCU5BVxARb8dB5bSseOg9M FA0Tk4ZRsIARSlTFz1qJqvgZGIV4MTJrmYX6wSxMyCzIg2G4F0NUmXPntCpz7hww7CBlaPFkGuHJ tFaJXLPpR8q0VgGmtUoF4MDUpsvU6sU40lfGUc0yVug+f/kH+tW20ovLxKKDDoshfYiGy8kmi66C 7gDpnsqkewdK9w6Q7qnnKalz47hMPaWkzg3krib0jzyIa0J91ZSysHpIgb5iStkEC4RJXy2lrEIl cqmvlFItD9cRc32VlLKMaEZz9BVSaj4ifVBIfRG9Fqz458yKX4tW/Fqw4p9f8ElEpaS+iaiU3HcR lbLwT0SlnZD/IiplFRBRHRFtmTkPBUMcygzxk23RIwTrKko2OIsHL1IW2egsZoOzePCiT4oiJfVN UdBNTbqodVOTLvqlKFIW/imKlM1VVxQpu3anKFK2vigKPeKUqxVRet2FDVmvp7dhlMP/eG2FkV5i FHBQTCQo4KC0d+vfukEuae0glwQGuYFBrl+D3OCWe9XBAa864FUHBn4BEQ2IaKsHfn9lU+Q2t5Q7 b5vwbZXDvElGKVuTcfoMxs0ySuxZih3anqXYYXQ7CtJ35oa63pkbCpS5oeydpmZza+vgorR1AEpb B0Zpbja3jTZXbhttQNloY7kNaja3uzu63rm7I1Du7sjeaWk2tw2dXJQNnYCyoROjtDab25JYV25L YoGyJJblVqEi5u/gqK1WaDjxO2r0tArei1SezqvEQoslkBK7hDDK+83+C6GW0h8h1FL6I4RaSn+E UEvpjxBqKf0RQi2lnhDqLxcSEgngFilCKtaQZkYyepTNdbhetNQIMlpfelsveirFjN7XrlaPhz/9 rB4ffztZL16EuHi1pIfV49fS7lWP5xXsW83EKLFP0tlAE71wiZlXs0AX9HPAjsO6bKRRtxhiR1Bg o1udjzboK67TZWFVXCysaLGtileLzG/lboS2pWzGFdevNv+WWdv3kvFlZ+GllL+CgjzZFJj3C8z7 /eLm/S6j6jQ7L5OodsXeKmPRtaYRqtYkUMETqpzN+9XqVBB92CxQNJv3Kz2ngMwC9bJ5uw6iqR+z QKnEpEI/1CxQJZu3TupN9ZgFCiRmoet9mgVqY/PWQ1+mdswCZRGz8snnNAtUxOat0K2cyrniHb1F V8YbgYWdsWg0aGScyGTci6TZaU4fZZy0TsZJ62WctI2Mk7aTcdK2Mk6uiIxfWdeLtLz/aMWSQGDV KrAk0H6XBNpax/zfaNNmkwz+7+/5lUyPtI9dgPqj0m1uFtuQxTYDN6Gf0E6E96othLTFzAZ3+apz 6cfP0zrXbJKxkB07YrEmKIsaos+i1j1L5xo+isVQykK8wOJXQcQrLX4VBJdcVBauJRc/CyJee/Gr IOJFGL8KgqsxKgvXakwbGQaNdLbCdzK3zncyBXyngO/Urn0nL12Tdz+3WFn3c4u1zbufq+TEaKyE 9aptugpYiYCVaJ2VEMzoXp6Fo6uzSydXu5A9y/VSxsJJalIDg7SfdbZW2zWz7owRnlqov6Q9tVB/ SZ0x0l+skO5v0iP1o/Qhutb0JBikeGaQTqJBOgkGKd43ayol9c2aSsl5axqka02lLALW9BdlTZVf 8rBACXT4/086/PYwwae/+uy1lBzYpf1r3KV9Gd0qsw4LDADqdEpMxCox19xuSypObLcltXgstiRG F7XrrRjrbNb1eTVMvF/Xr7GaTkGIa+9S86ZbvPu0RaZbyqplplvKruWmW8qydaZbyrb1Z2OvzGqE WfeEgrpPwWV96Q5g9/v5zGvPRugcb7jMt2exUd9uYFGiGkaDRW8bCHs+1xi5Zj8rbK7R0uzOe8FG Dp923FO6CvC8tjPPq8Jk8XmnPaVtAlobo20yWfzaYU/pG8DHamA+VoPZ4vfOesrDBm3bxLwgW5Cl RTvqBZs+WryTnvJKskSuOfoT5ZVksVzB6dT2MC3Z3ovia9d9VarBe3a7tdXQRqv2gc3ojEUrJt2N rRuDGwOT7oEx+BU6jWW8fEbj13Qa5/J1JVfqAMwVu1r2aveml5WFr3IgaoEkHZVKV0iGQjIV0l8h OQoZoBDQkKFFnUkBKgrr6Mf2IeMUMlFx9/iy+2JCBHNf6YoB+TWzOT3E5r0C46ZsbnzCqHESTB2f 1CoctS/9E+OAk2Eqh9xQjoOv3RPjsiTC1acsieC4+NM7MU4FUS5OBVEcJ387J8YNp8DUnqShE8et JX0T44hTYyrHkliOY0u7JsbV3sXF1d6F4+pLz4QbqzAoBl+XGLyAx/FSex7HwBWaZqxMVHh0vRpq 3vlZ7YGv8sBXeuDrPPAVHvhyD/xOD3yZB46BKHgcgz3xOAa34nG8AJ/HMcgMj2MgMB7HgFs8jkGh eBwv9+dxDMTB4w0e+cWABjyOwcV4HAOx8DgGfuJxDAzD4xgEgccxaAePY7ARHsfgOJr332kL43EM qMTjGNhAU97yrXdo0tXyNR45QCUZA5vx6RiYi8cx8ItG3jzqx8kv/13GD4Oa8ekYmIPHMfgOj2MQ Hx7HgCo8jsHHeByDtPE4BhrhcQyUweMYxIPHMQgMj2OAEx7HQFqa9k9dm6/Rp9JHNekYkEWTXng4 jscxGAiPY4AaHseAShr5H5+gwTEwG49jsDkex6BEPI7Bm3gcg9Bo+tOKUwk8jsGCeBwDSvE4Bvfh cQwWw+MYNEjTHvXxGnnFoF48jgHqeByDVPE4BgvkPxhQi8cx+AiPYwAQHsdAbzyOQTk0+S15qR+P YzAMHsegblpzukfTnhiwQiM/hsKumvasKO2h0Z++xzTlweA+GnmuTtLIKwa443EMGMPjGBRKI2+j 8rpqD6A+pbE3GFSGxzHQCo9jEBiNvZqzOVojH2PC7Zr6HjlqEI9jUB7N8zkxvXgcg8HxOAY70bR3 3RnNZiAM+KUZD439VNN+GJhG05/MrtboEwZo4XEMqMfjGEyGxzEInCY/A2M09h2DFfE4BtThcQyo xeMYMFBj7+0xmnv4MVCKpr+q/EajXxgshccx6AqPYzA4HscAdzyOgYk0/Cd8MU7Tv5fmjND4A0WO Kh7HoI08joFkeByDPvE4BqHhcQyOp9Gn+HJNfjCoi0beblqleZ+jHX/OQp9pJ6lszJdLvPawhQr2 sHmM9URsS9494FrJ9GSL+/HQYdawSWxyBD7t7LORBD76HxMV8WDFYFRoyF/1/zD835FbUGIvnrZg Rl3RjIX29LGz+wHYR9lvGFpTu9SekkDKyuZVLqhNSob/5lSlJJGSsUPHFJaMI0KyifaSsaQZhuC5 mcz/QvYauy2m2SJbQlOVKowuSCYacbA+0WjyqVg42toPQ4xDse5JBfd0tvZzt/nT4T/VbzV9+9N2 93CefhspPgZe+Zqr+2F2OQhMIgKRgEEFIvifwf+1dy3QcRVl+L/7yMu2bIPNSYuka4tQkO5J0kRS 5ByS5tXYPApJGtFK3aSbZGvSjbtJoYDHKIKKVYO8tUpRUBQEbaPgkZYovhEfRyvgE99vPSI+qsX4 fTP/TTabBDe1x1NP75/z7Uzm7sw/c++dufN/+/+7nhxPmZysHUkNJwbDQ9G+WLjsmNoY22BBSW+t /Li2tu6/bm2KhPDmkjeXvLl0XOaSf9SRw5eLwQuW3u1wfjAvcqFJ+52JK30uBdN1lcg+zgtsC0kD NBbRR9Dny/EHA0GfP5A5rdz7vUPiMigxSWFj2Yr0MqQXSwJlUaH5VIl2fBIMOj4nN8c3xSenMz+j fGmX3ajTjZoD5C7ONNqflxPwUebVXiNJ6I+aOhdWmjq5/nyfL+gLzFunFjpGTL0YXt1ew/4uRP0l M3cRc9dvRK30ca+RLimTs7M4G5dQR/7Cdfznll+6aszJ3APN1fJG1B2QXXgdRos9QhNrXWF2ddP7 U790zBkNZr4nN2/6wtql9NTwIVke/jByLbjGYbzG0d8e6ReSK+eVZad55jUTKcsZc1qnwi3sW/Ny 0+8sqz11aah7Se/pfTg/OeY+nMNja+Z92GX614dl3KYc62onIE4gr3jLUXqzWbfXtXtfdm0FML5i zZl+49X/8FLYtDHz09DGXeRqeRzptlWwrB9hKR8Md+iA8ldvORp6k7csH5vclTOROy7juGCFpbyE y825XU7OCKtYyy+ybeeB3XOV+vSBYcn8c3DvnS9bzd3bJr3446yJoaQDr4MyhNkUxVzirNgqF0mn NKHGJtmM3AaUNEgzVikYCVKP1S0idWilQ4rxf0TKpUKqMCeatJ2YmV070VoCdzlneiPu+jhGF3M5 VbTdb+ZBysxfzn2+K4kau6ZWo9nvieBOnn5PtZlFHEcKfwlzvMesJWfLYvRz5rEwRpLSeXcc5V/Y 4wQKZu+3OEOeuub2p4+09YfuuT5PXnzWgSdLSU/iQKEev1Uv0z5dMj4nNrDmG2K/4ngRvW75mbpj v7L4DMfu+Coc+51GzdrWy5EWmI9mLPeBB6Z5+O1x7FcC34qUT4Q7HfuVvvc6dsUYR0ru9yHH9uNn UF6it+DGSHlFVbhpcGggNhjbOZxIpsKNI/HtMV68EndJw3uY5z6ktj8ZTw3HozvDjcnErlgKm123 JNJnSqpjyXhPKpXYGelJDOIpk5xuB+/MzHOcDc017Rvru8372P96bSDcia21xFIlev7WSbyHeY6l Jd6TTKQSvcPhrkRye7gqUir9hiIqXmwYB5MPnXvd0KGDjsnfXPngO9dP2Pzonv1jyPu1L35dDply SfR7a5YnnnjiiSeeeOKJJ5544slJK/PZ/yzxHX7s8N7IaaEbboH9f+6R++h3Fswo2+pY+36x2pxD Ym30y5UL2KNcwI1iuYC9Yn9C506xruP3irX5x8Xa9A+pHUwuoQj4qti2vy2WEzgiM219ljW3hF3T 2tq4W04x6eNqA6/TlLQU07JleeL6L8+XloTseJ6TS1gUsp0p0cF1xIcHYuKa33JjwP2iEdjfWnix 9v8V2qf97rkWy4Fs29xUt62xs6nOHF3klmxsbmrd1D418hqkrcCVUi5lUip15m89sFaqlNBaiyNl KKlArgbnoErOQ67UkFelKG1AWR3yDThSKa8zvWS7T/jJkdjeDeGaMC2WafbAr1d0JUDPH1LfcRkw dNn50iL10oh2aqVNqqVdOpBvhZ4ajLwO/0fwXxvyHXhfM/L1yHWZkk3mKOtZ/6iVMk08p/dl2QnU l1NOgL6E5PVT98pcfVk5qy8b9OMaEo788CJl6M5qtM/eUFOrND2nzi1iwxzy59H5olk65yJDG2eQ ofXQTdK23VC8rVmNOed/OObXyCtN6p9H54pZOncYLX2GtOUIm6UT7ddDU0eapkw9q3El09vP1LNs lp4+/PWi/SjOZVR2Ay6RnDkOTzzxxBNPPPHEE09OdnG9Lf1qrwd1V83P6/N0h1+gdvEitcWXqOUT Ulu+UG325+vutEht+2K1n7kzPg1gHN3pai5zVxoGXgisMrtekTPUcmA80VlqM9Od6xy1qBgXtlYY VivCmBhaqfzsvlxtfMaVVQIvARgTx7jR9bT7AcYYXQAw9pDxTIxJrFaLlw57tQD5DcZSNQCMmWHc FWM9GS/HmB/GvbWo5d0GbAYuUpu+neY/0GmsIzowiTCu8xK19RkzyDi6VwGX0qoHXg3Q8asbYMwR 3WfoYsL4qj6AcTSMJdxhrA8x7nXc09PRLKFcC2O76BJCBynGQTF2ivFWlykHQ9+aKwxTIHIVQDuf 8UWMyRkF3gC8EbgaoCfUNcC1wJuBtwBvBa4D3qZcztuBdwB0RmD48vXAu4AblOO5CbgZuEVsqOht SN8NvEe5n/cC7wNu1+N3IH0/8AHlhO4CPgh8CLgboMvaR4B7lCv6KHAfcD/wMeDjyqEcUA7pE8An gQeAB4FPAQww/LRySweBQ8DDwATwGeCzwCPKOX0e+ALwReBLwJeBrwCPKhf1GPA14Oti/Vy+CTDg 71vKUR0GvqPc0xPAk8B3ge8B3wd+APwQ+BHwFPBj4CfAT8nsAD8H6Dn1S+BXwK+B3wC/BX4H/B74 A/BHgD9H9ifgaeDPwDPAX4C/An8D/q582T+AfwJHgWd53vXcc/I79J0B/A5/lRDznz47jj2eRz8d +ubQL8ex/jyL6Yujx59Nw6la5sKT/w8hF5LAyhHGykeXt6RZMbKvX4Q7xs0bRibfcskT9vHSYPKV Bx6lj9JEbt1B+icx4HJUtdQZt72oHGsgYAHu3oXWod8aH17Ml2HVjmIFHjAr78L1L9FYhIXU2cf1 5aCt02WcDLfj2ZPAM2BkyvUw2xZXYPw5+tzOVj+Hf3/EMe8P4slFrWSUeO2boL3X9GnQXJm4cT6c v+01x3D+J9POf3DWyBfWnyroDyxw7Ln68wN2/1NrmLIhPNG7ZceC90+F0O/T/dLkZPYRI64mqzWG MzCM/URCHe+zlyJxJHN8meLOOzfN3P956/XJKw6uvr/A3ruZazf37xn+qHWJnhF+BmZsgpZ2lqHI TCbmI+7xSJU8s37/az376kSXfwNQSwMEFAACAAgAF4dTKVnoZX3zAgEA2k8BAEIAAABlcGFjaGcv SVRVL0lUVS1TRzE2L0lUVV9TRzE2X0VkaXRvci9IMjQ4X0ltcGxlbWVudG9yc19ndWlkZV92My5Q REbUvWdYW9u2JQhICAGSEDljkTMIITLGApFzztjknMEYcCKKJHIw0SYjcjTGGNvknMGAAWOyydk2 jqfPva/ufbe6T3XVq+6qr96/taekvfV9SxprjDnmmovXUFVdVEIMhYBS8G5uTc1BKf4cySKQCD9H TyiFoiKUQlzXxdct2B0h92fQ+M9LdQ/vYJdAhLiutYWqi5Ofs8ufH1BSglIEBQe6OPhAKSLgiREz hGlbNBsY1OdAFEFQBeGB1ALpw5MIUNLwDGd8vy2SBauNs3dvsxdLGXJWly2MP0HQUcS7XgZM9zrJ w2KRW4ZoXxQjzCEjIAvHpgpXx3GBjx4lc2eMDNKe1zXwC7Dha5r2Q4tx7nIs+m5YrZhVBHdh8icn wckQ06f9sWXUuR0uXOVaZVtGA2vsIpl49a/vg7tz9eDU3nySeZMefk/xGjJG5bj9kC6wOJY6bflZ RG8iBc7E+SAUygJV65PncC1HZt85OJ/p/qQizGo86Ah52kvPzurM01lki/p09y324Adx2lo9TYMu eJB2MH+D8M6Lt+3R7d4nLd34kFcPh6Pvvf4AIwM8gr9IWN7aVchrzv34xnQ6WA1o5NHWi25roF1b eOOZ6RnTrn3R3SyShLRtq/dyj0A1e3u6M0KcQpe/4DzdfXGgjYKMckFtZ0g6T2Km7FS7Zz7TL3Ku 4po4dLQISjq5jLCKxjtRDOcDSfK9ZSDR4G0UlHv+AXqYpNBbHrqVBWQh4wxWOn6pM2fPpnba39QQ H53WKwmLuj5ifl1XVyvc4K/aUg2KbFvt5gXbrjYMYwnDivWUhgeygimU+i8V9QKVmECNXXspo8ng 0iyQTq47I07AvhyZAogplYeUEbbh5GUCoy3QPoUYIVLd+Q1Vuct6y1/gLYFVVEof2BJOBejGiIF0 jwPsyKfjlyVUIomcmaxgNNvHGMKPo09tXLlPhRJVmBLp5UcOrhlBTdxZ1SDlfstqMnStCtcITayS mDJWc7u5rlYR0Q5zXDf+shJyiB4hncuGMMm1HF4ICZeWO/KB20fBbDY5V5rcgt7bhoT3o++sRxxn IpZlodECK1Z22Fz9NliZ5jAqBoAuhZNTtlA/cHgyvxw9sfSIm7ZkhOd54MspgIqAdVTEU8ENMfrL ODPNn2pqfCRc/RIpdd65MrK6636PSoQLax8rpIvxFpYKNRmKHxWITbQeTXn1s7qMT7tn9uuOSU+u a3cmxrZxZbs3ezrlYuSSuf2HsmDR6obSEGEmjCysDL7U7N+HwPBshZ4o5Y/KMWhlQjrMKBiWLuv/ 6Oxk4rJPlTVu4J3dOHzzhhBc7WQaVX2wh9lwSDVtLhBM0Q+uBtW3dmeBfjPq0oEX79G1230vCqGD 9SQfwWFbBhRwCLfsjlEglmm6FXLoa/wcWkIUJY//Hr/vZEUc6ytg8kA1ARH/VQprdCbwtrb3vcUy 5GWOB8JJMLQ72h1kcfty/YFy3oWSfTF8eVri4QDby7Te8e0oCJUXZrizvbJlz57kI/dJ2nQWmXE5 +3st8OTLj9K0zkfj1SUhu0WraU+sKHLxojraPPXdGvEQh307OyorgaiQn1VMy0aaI+e7sgAOjzmP /Bjy4HJ6Ac1HxftVd9XWWNMJlv0f4hE42HwuVrIR6qBzO04dyHTDzLrRKeA7xbAxP0NQSCP9+Z1I vW+scUAiZtssCBYT2dsSkUGtUqxuSpwlmem/RqD6kWpaHDnUUR5sBXCO8R9AshVyH7iQU7aq+q/D pUIdl2imJUBxvJHZi9ceE8beWequUuqksMKJgsaQni5JEqKn+oDwfm0jzPcK45PyIjpiKRFbVlUa ++YF7NKjAOhdVdff329QnKmsR3CjXvTWzdHlqZ/YypNsxXIReRBDKVx8nf8Bd38O/w6Vcv/ATAmU FPLfw+j/CkpNw/xdEOKGDm4uf14YOgS6+AYjpP4Lrhq7BPndDXRyCUL8/a3qfn++9m8jJEL6b+9B /G0sgZD55xiFkED+l4u/AbC4YaCfk4lLMAL1b3f8ewz7523+fEoQQvbfg//4bhKov8J5Ccn/CNB3 DP8d6LHushEYUy6AOgm4UHfbDQ5Q23bP7XcUY4JyDmCRaGskI0S9LIw5RUCMGbqTdtkRYaglXQjF mXhkrQajClMcSeTmZ51R8ZDBy7SIdGQMmELdhLlr5aYMM4Qfq9W1KhiXX97HpKvPoQrX2uGOHB60 oUufUANl6kVUOzKluADAmqvukoxQdWMFVV+F6LgRHyxE2dhOgGm4MtORPXTPQaIICMy8K7LtU7/o 9QXuwQBCsUCR3A5Eq94y3euD3MSEjgCu1PVJ0zwRMIvUO1P1LYnhDh/y1sH4hePC6HSezNuDTjbB t24IsnwWk3TUMqwRFQJTuGGr0y5V5Vgnq4iJhizFX1mWOs6kSM8kMd2p/0aeokl4ScFNGJWrTbxc TqfAgtdlBROJDuSUEO6OzGVHtMs/ePfB9gvy08O+bG/H0lKKknuI8B9SaoaX/gR1Va5vb+q4Zl/j dLa+ZOHSW/nowNxNvYp4ToBQ7YCEk0ojzD+eQK/uQWS/qX5aV8Le6xDFJxw73eEAbtKzxLwDNW0i 4NxegUyEZoEM4y6c30o7HSw9SHMZp6lpg9TVFc750uh7n+41bg7L9qQui2YbrlF9RQqOrbbxTldK 6zsnH+XMFmRPPGPak07mDgYXx2bA16QFo8HDMjHEfUzMuPTwOaa6C68PMhqOhEpEL2e87/Jz1I+n beoZ4Wt0FNECS+wqYtz4DnPhVenBzr0z108NytarzEvK9ZWxopETzC5SWXjn143ilzdk4vvA587o J6R5Eo1eZ0EOsYHrtot2X0iFZZa/TLRv3kLbuy/j7kEdQnlgigNBQ44C1tNQ6ZsZm8+T0IMDuHcu OEn8FjICOTRLZFuT3JSkCxoS+K6y0MJJ5L2846FS+qEa4/VgHbGn6b3Y8e5HaZoUoxR4vl9sq+tM SLu0rk7YUFj9VanZAwk3G/9DxFeJ2oyn85xcAsPolESXIAppZJfzz1vWLca/JzYN19CqpbmjkgSU jhaTsVGphcC6R8HvAvJowuAzSXMRaxlTp9BJdHegaV7gHVYT13m9TfiavAAFfE8OIrT6huV81osZ eVrEQ8it7+3OjSOnQF49CxZecmftbGPfZL4dsERAC3L5j8kSuO17606WY+/e5jGljyy2tG776Lhp 4Sv4oE+07Jl7i/yoN31vJFEHnbzjZvdWRVGBkd/3e/T5abbPK3/T2cnc5nfZXLOtY/l+xd8q8yPp 3pvrO0yyvBHzbIVk0y0fTcBY+43YhovtvtzoGU/Kl98bPpd+icQgVHiYMa+xDFDKsRMxZYLcC+kD OIm9GdiBjp8UYwvvDdVz7oey5QJSxiJLWkBg055WLpoJcsG/RsC/A8e/jZAScv8Sl/hfhoH/fdiT QP0F7kn9Je5J/0dwL23c/U8oAwI4mzrpEELUxGXEQGOBQMl44tILtKGjBCOEc+cfuBdNTIhCOCX2 gmZHAgz/ZLo0elUAh6xlFxl2SBV3bkTKXXQepBQg0bWN4FEBRUcS6+M8UDPafwfAW/8AwCC6fqih 8vAm1jRRFRxFrljuL8c04crI3LY+97gtW9TZkg3413Mi/c85kZL4l/D/v8vS/8A0SP3FNMj8z36J v3jUv94YJfFX84tC/Yfmd8ldjC05BqDc1OFFAacHR8xERAnTyzH3E82EsQhJMCXhAMpA1XEoA560 j5owqkUtMRDbx9nVqW2qEE8KzPToXnKRztMbwgoO7yK4i/T4sAIR435yYHJaieJ1jDEqd2J3mbxj 2EGeRW93K7eSyzMKumNm2baa4JNry09bkpxb7c7wzsUwnWgpUCoOUt8LPnpMygdKFGv3dx8PFItV c5T+phtvL1Uw7hYsmd41fFdiyfue16ACAsGAD9gqVNQBqzPFg+TfK5nay7Ac+aLqzXf95OjooaB8 ubQ1J/lF/SgYIqIXUW+gxzdGGr+KkMmLIeMW7C1RRYEFcZ4js6k6JZa6g5niMSce8izAGyzuww5f z80fctzw66s7UlDRJAjFlpZpJkoRJ8KYSqFB3qxkxAWoPBBnP9fHKu2+0obaY9qG6oqebls4uZjl snyKr2V/5atoyl5058H0qhSsLEjlj9enSbtowabZFzD5WtZdmRhAfqKCYBlFCjJ5WpZAL0VuaM9W n7zsRio0nBTJCEm9GEQmp/gfXNdQRdfyaJaFHshBPL1adqGjodvSw2Jd27v81T+yCDAHRfUNwTKm GT7IlsAugzyseBv92ontkLd2Nrh4BXRBIOS+yChveRlLMb19on7Imoh67RS0DNdI2bb/pBBJNKoI oxLVl9dMt12XSI6uyWOcnGNbqByhkKwrm9gCj1+gpRQxNbPGiapsoLq+exBS6ouOEmw7kx2gtMTd jZr3OIjivXSayiYdyFBBd7jJAVNZb4682TVUoqdjvlC/d+j4vvK4rvztsmmnMzNvLmXEhlyZfFal QjByTVqLnj3tUp96Ob8qOdp+7Wvy8Du2UsilKITdJk1X9Q3K5wHvIwlIDukTWZJNCtbuIxLrl3e4 JElzKBIUbpDaihEpA9odAt8/cZP5MLoC8vdBZpd8KfthbRREamcw9SRLOJMT7huUvfryroSnq3K7 +6DrOEPa4qd7Yo9Y3AUXcIPunQpkD22fHBiuSZ9l1THzFXyWLTXE+s9p6AoJy5cZAQow37T0u5c3 YSGshY3mn2njS9WnHEcHpYReYBtONqV7Xnvr5Djl7dbBAtr9RNQ/dsSy5p+ATmraF7vcnlyYs/nD n9oXQbjd+9EbBp+h9cEGLRaNVrNFbze0fxe2FZGLdb0Uh85j92kMhABzSsADdYbKyegJP9uN7PCH fCIUcfOlVDDrZyxdUuhluRQn8Pb3woQphRRZabbWlhE9bcpw0FJc9D0CRPmVq3V8dykZYv0eoPSu oraEepwlxacUf38Y1fVV1pY8q2XzN0dv9CkZ93j7uOOHsGFkTzXWem7CqN7+E6QsK3MaTHWfGUjc IVPY9vLPHwIj9FMYNwdje1yW3Df+c2VVeiIMq+4F3v/gJmdvdl0aVwxY2UCJpYLLs3Kjp87Ejeg6 h9TSxJFzTE1IZBo3NH8PVrKeVFJxVkhAPzFXiIseiMVKWLxhwsL99CAPUC30DCXpTAgKUAgfH0lK 0TvkPat6CcoKRyt+041tEYqfZXHI6fxohw3zkRmcUOumG5bgpqQ5LC/Q1J+72tIWK0BOQqppf7xw 8NF9MqtPPi7mOXH+we2UrhUANgCwIgniV6Y25jBu6Mse5chQvyudd9nR9cSa/PZJdoVMmTfsz6XK 49NycD2m5l5Kpx3MxcO+jAS9AcDiAuCEi6zgwG1A0IG8ZPdVHbbt64KVedKhgzwh6gGzsaEL3lAI lcFbCrMP6yijsqVTLT6mmgy9Z+QwM3kjb7e0L2ZZpyZCXsO98+ty/gMMvMJJQspAZfTK9tkn2T3V F7us28vGIEQvmhPjZsRQ9pFCQICxD1PO5ED9EVLdoEkA7BreCFMVnLH89FSu7h6nx5hcnae66tYT XbZev/tn15VacJzl+kgJgSeeFcBICiMeCIny6Cfwa7UVTZWqA+EpjCqAfDx9b6fp+ctTnJO84X7B R9khxI4WTRM7rbVEA3HMdBVw507K8yDp9YXklgvzO8eC3Vmzpfyg7t16ba+UGOWmLxysdwxoDuyh R4KY8m5MfRaaGWI+ayKMTiBaCne///k7xcvQwi8ldFmezz2bNLxUsaIisqCB7+XlOrxS3sf2Cp9U Pgo7O2cARo5rmi4e3WZuFqOh037sVuQoTNsolmEfJuIiTUFnE1U9E1tq/MKFglfHWJ+gu4gNlqDS giffsW5WDh1gMAGlbXCmb/Jg3JBlQwwsbNpGq4qog14G+FBsEunPN19bvgnYfxIfU+2xpaVean03 PrZQjM5TL3perYqIWah7pxD/fqePplo2XuVa6jKrn9XpWD6tGI06NL6NsKVLPXP4o4czIPiGvz0j sXa8O665TKFKW4v98D6PnpR/XxTHMYnHL7mNG3Rx/r3fa8MKHS59uQpDOLoi0yRBmFfKLAkxHVbj Ay6tHCkA25BXzLqQifI9fvqWmAZeto/BtLH3nfNGku0+q0oZGP7wlJf9ou/vrNPqaadjavuVpXm1 7MSMkx+zzbKZnOxw5JFCXe/TIBaoRiXOHFf+3DpRDOWv04J6UjbKz4xONG5L+0ABCLJ8Tu2hK4Qq LCTwknPe9WV+lMZ0zPbdv92YvjZ6tppnRcFzBGIvl+cVGv2cwbjjUnfCY5JQRHozjgvrSDYtkKSy NV+uHFIskJ/1jJLzmOh9sqwo7/sb92OcJAwX7hNQ3dsfrB0xWQvFNmBjKbOFz0ph+k12mA26yHmk r2armsYWT0R0ponzTAJXPc82eDCayFX7/Yp/ME43hRWqnJ/8Vily/VOFZ2Cu4ebCep9AxR++6qx1 U7/fmnu+pjeCj7RuVM5YfdfN1h8gpHWuB7amq9DSdxizAer7ZOMvG3P7n17pDaiZIBakSjJacwSn vCtrRs1uKaKqql1KTkZ112gmqt8rF8iUxTfcN7YfEm20EEY4/zW/Q/1TwqMk5P6Vc8v+fyJ4qH+8 +P9K6v7Os/5vpA71X3Prf5DEf6Ht/5q5+NtYEiHxz9QyGoH6Z/ZBCoFC/8X9Zf6S28n+T+Qsoh38 570Rf83tNCMN/8Ht1rSdkihx2LBg1f937q5bQkKSnjXoJz01MYgln571k6Fw5KvGDNLSx6dzzf6w XfZHNdOLRAeUN3DIMEEH+kIfliuzs8SDUCUxfNz8WcM4bg8edQchJvx5hlVHcbtafTw4eCvb+rW9 2Kp3jCUH7DM3/I5YWbxu1CFp7pFkW7c3mEWSCbLjJKq5zCS5Zu0U45BCGc2X5UDGTT3RYopKC/KZ yzcDzrqi89yrsGpiEc5w1vFeyP7SbFBjQQxojnx4weXMMJVMmTi+N+javTSK2H3wYKC81oSmt7m0 jCNPCpbfDYc05m4j8d7Xq6X4vowmuEKi5bo8Hus0eYJPnSbQ38IjfFmaplGOu2qQUv+amoOxNw2v hQR6JSHjl+vfU5F9nXChrUwF8GsJOs3+cuLaVABOuTCbkRQAH0UnD89myeGd0uYEIZFBV79xXjWa DDgtU4rn3IQfKZktNNbLQqiS4O1fKEk4Bgcykf+9KTsiDO8FRRYkDqk5PCcVIBdampWobZh/0DA0 PVtErijOhqoRGu1ta1AxmBX6/fbwgJemXDN4dVg8RUFYEBbdMVpsjOxn+Q7hjlhHvW4plRIUrM/t HR88oHl6onghpZkG0s8y/dTBYCIkl/onVZFJjiSa/tGVcNYnpOFE+MA6hMSHSGi0dUVzztUysVIv nenl5BmgYirsgDRdraJDd3/0eBFasu3roNylMWcWjbVjEamoz+9QoMiaL3Hj+Fg1NHgE4SRVijfG fOL1Fi0sJH0JxggmkgjgeOK57DE8Cb25BEGKUiYCT8I3r2/pVIHFu/IwbF18E8zp8LPixtj2KdGU r5j4LTlBOgOTCofxp/sz3LyM6oM9gLPvitbvfCWSuaE11/YylXefuk1ntsu8KRNV/H1rrD2dOI64 xctllMJ9SRr6OfiV+BRnt+1IbMkz0pt6koewX9ORGO9fIIcpMpluXZ4xuu7TS0oBisSmaRnPL/VX cHBn016Vt3StDKfkTJ1E+9/MB4bErH4nvcE067LuGJJ1IxSOOKKD7q0eH4pNDE9htu1QnZrbXSaw 5DEiEx/CthbuoySCC/LJ118BtdLQxPkbafMl1T9KyU/HWUczfhkFOyW9+0ClqSyk1LKqKIM/C11n obN+r8EXLAOSXu18KgEW9zNlo4E7Ww0rwoX8QkHdZfaJiGCaaB3n5ZsoZzCiB8Up7pxOozquYl+2 YQDMgHdfOJpuKLLxnBGqVcCs4JIHrFFpVge5w4wwR6CCv+HtG6xgJ4jDynwMNf0R4MlzuLatJKf/ fBzLZRj1Oh5F3DQTOmD5mAFRaBTVDON4HRrhOEIngDcKZAC4T0CcsB/w6kusb5DOWHAg8UP7gVe5 V8XUsNmvMLAm+43Sa8oUYonbvNcpbZXIiGFsrmFlswCpjHXUMFKC9OSoOjswqn06FwER34Flf/1e b0+MlGyCFGPcboNJkqgc+rNvjNFcQ23Ci33VvhE/0fye2DOM9j1ULCnKSOJPxSoI1IcY4dYP2hJZ sm3EPjC3F9uJUlh/kpwGl4zO5jRbGB89IRCrMANyCPi69uR+NAMJUVR92gXeGH9+Jw65Xj5l89Ti U6H0q8VlbC9Nh2TFTSG6Cl/zUeIro+RjBAMo9DkDCgBq4QvMaPJTo42UvdcD5olB4s4+eblZkEU2 VIfTsOjlXetoeMQyIljO40VMQbHvJgbB8z6CeLvKgEqEavyArv1rhaBAjvyBXIHHz0QQBEPfZ6zY n59vsOsAYUzRppa9PgJ5nCgzoXzT0WSWebp4zlNcw9zyW30w6pwTiMvrJ/JWxhfSVfGkxdAUB2L3 26wbnAXYLDzPGTw9+AlUjm+iDk78PHYiiZ8jGFVk/Wwckv38nTPKumvZ79RKWfB8VmKzsIFgDyoS 6s4mm951LihvoK1azAabzEpvuNXdDIuVzllcsnGyF2V+jghYW4QXe27XvO9FgsC9XFlLjpE10Xa7 0P0KIgzDHtjtMTEQJe80626vXAHSlZ1HzlmYLvk4Is1LRVntgyDKFStxjOBU2bK0iHe0eWp85rpR RIUmqQ63YQNiZhNLFCH57Ace3up2NZLfq2cjbHVbNmLfLLBHTLrgZI+MNdCD+6pLu5QgT873Chre lZW1X4owCyHr5fl0fZpuNsfH4aTIi8mRz1+gV20tGvdI9WzyIx6+e/OJ5kgX+ylM0fNygqxE7oQt umwAce+pSIfjFYycO72VQejs3Sssl5ZRk279aFlBYihk71U0J2JFcKWw1p24NQrD7LwmQ0dMKo6W 0JoSvVRqPxYfjx7Odd5YeiXjiZcgtrnHX0s92Y0Bt0DOp92duKY8zgz6WBaDiScfbZ0pYwy8Z4pL cqKzyj6H6y0YBsb0M6FfjmZRwLSJXyKrK5myijWlXrQamsW5uDtQXaz5pYSJyzELPPIvjwx2wok7 sMszPHf+TGXd5psyc2YMbq4QX8yT4lexidduGXRdaI9gPmA19pYMoJoEQlblhJVZuEd6RaHr++vF DtGC/qKGspq/2ShZvmW+j0QGnw8US3LZu1ena41gxvIKqu8mg2ocv/pniGQcdJmQd5LJtV/4yrZf RwLvbewXbmzYfXeg+sK6rqg2yf3jBzFvUFUOzciPp2VnU1OGWN5A72p42i4LIPQuNC5S0HDRsiM1 3g96QX+XzyR4JtfZKj2S9aGtea4DceTYkis0Nc+r9PeN8ifQRccnir6MzzO8XXUVfM8X1kTmSwYp u560pt6+BOfqBxqC+bwrQJKf+1dyDkVt6nJJokEQtvCD6PdVRp+JgnjwkdFmquv8Ddx7dO83O29Z qUwdyPPahJIHYypNEXHmdSsKJeZcnDs2V9q2VZ/HaE3zs13knnBlUdTVvV3fz95Y/W1W+YZbv2CC /2u91iZNJHRZ5DbLj5PrxJ+WAkAY5sO1Le2tz2ZNnDu5rwOkU7P578yRgQ73Bx4+D02SAK3sXs6v 2Q3/8Nh+wCOfm4BeyRt+cv/Y8OZoqLPM8U2UdOoza13pg7KImjLrcT48b9TVjwnX8S3ghHhi3HHv zz7fX2TSvEnIJVKijBSSCeFdfsoTaLf1VA3LSbm3tGOWAtGqhv2JPWLaWDCIuDo0cAq25FYFQBia F6+rTHt6c8V4YfbuYJchCTncgl9gPgw2vVkwbS4UGdc61eaLsyxUtQbQpUOR6BmYDEOlB/LWOJEv 7VIgwb3D+Aeq4x+WQuLH/Bf83zicoH7BhxeOXUdityCaj+S8+xMpCnGn9TD4Qpxm/08uKihysClV qFk1/0XTOdH0lXQ6qLmBFYoNvUi7SFIDppLcgNeiKjf1DTWf0UQXT6Tt4RzdoNQC7ZqLtGd91OlC SYZTRN5c7sPrIKjjquYAvXhlr4AdHdaDAUvKkPgaWvbUcSYYCN8+S6IT6VX53lcGpbah33vOlLzP dO4FaRZptvf/aRRYQ/ENLhxELfSC6dwySZzugiDIauTGMuPNc04zb1TIKcEOn0F8oB5ipn5NP9ON N+LibP7IfPaeRQK5PDO7JfqVes+ELv0ja2kV6yEVguszvdEIC7hNy5iW4/weC7f3i6QByJ7t65T8 jymrEli+7UD5Mm4RSUD3oZj9YbT6K31mJjKeeX1u5gYhvArJX8uFf8oClIwc+l/i0v8Lbcp/kHrE v7L6/6GsMUrm/ykAJP8yuSv5nyi5W5Rb7c7VvYON7Jj2Qr2508S48tNVGs023g8IaMNpULIlbxsr 49EO5nImzmcI9wUq70Hl9YW9inYJlhSNGAB11pqBYDpE3Umua9Cs5f3EJ65437Y6B2njfjIA+XCf cqlRDBk2NCLKGUUJBM6Fpc26KsZDpE7yuo716i0UXHVEC1nDQO/U5mwtP/LW5dmIhuEXywMOF368 /v7x2dBe1U0RnYuvvD5e8BGJ00NJIsmJA81fmMYrXtLyM0/Cl7f+WXTfXxs4MWVznk3btquktp4N 4GZI6H73+QPgA9i9QHpAi3/BISXfDB7LoOr3Uwincj5vwTE4E3RKJdFc+3203OhSAaGB0qXl0sJ3 KNO0RnbW5eOMWDWXQMTxvssNekvxqBQnpm10CiXFILvYGJaJEeS3LRZfv7fn+O55NcowG0T86k+8 2pgAxb9wLJ6ujG/4juOElSHHS8cvdRela2CsiVv4Bk2MAl5IdlYGws39Rk4gkWnpqNZJc68UkjKb gowBtEZUTIoKWDMVH9WswnWJCa5PEpNbzFmXfGaDN2UnVRJ3XjbcLz3pnOxrO5FPucacJTeyq8oA AfmtMiJ4a9fsTt2sTmbS7GECPZ9u+GbiDPm7d9SxB/m2PxbFVbwQOG/NIAUlYx6dx0OyFNRRQjOe Bo/7lszJ6LRahAxuK12s8eIcu33CiJ0saa2Z42iO6uMkS/JVmEvM1dWoVdPfmMm7dKw58DuQI7zZ yjlLNX+/tsITF8YwL5vG7F68Oix1H1aNi9qzfND5xaNT9VPm+lQDklHo/dr9Z8P5kKL6w5LJ1KqN znHi1Mr7YpNw5zzpOcKOnDV9o+p9kvfNHoaubjnur6SLyvvbGY67j8939yYRXbI+RbvJXPJvcWiS +luG5M5fwyo8mIJcSImJ2jkhZTfVP8nTB/bLUL44AC2Amhs5omsWbjh1e/04lI4807H3Zv7C+UQs QUrg53chnisQQEWra3mX7vblhwrb0udrdxSBtPPXiwb7tIrLQZlwj7OwK+MCDxvPD50npo3cbfGE Mh/1prshcWucdZ6IM3nStYoISPJLOJcOMUZyIN6niMj0kfhEIDAt/o/s5dcRaq+RAG7nS/ptxtvF xaJFiHxm/SYH4+pqabbu7UMD1GlETDyTiAASUhLMGl1rWKwiJU5eonyPuKkaSYP6fa0VfCvsbJwv zvAcWiJoGMdbSi+ulqibQCRniTthJszGsAMKNU3gRffEgd2OHPKDqDp9ZnZEJQtWvhya7oJW0XxB s7F6OwzTc6GO8GJnB0qC00ssgNO9bFzzfFTNIfTRRM56iG50OnUWHHjW3xGd/hGSblkyOCBK47gt mKKaKD8AjqWHZWXBEpW1BDVXoJumMXHFMxL95FYcTsjgR5HjTTg5UdaS/hhD8thP6ghHGNtPPAVx jASuqZd5TjUymz+vW5nGArgtGHXbN9KDtNuwQassPWHamKS2f5gCYRj4SDsD1H05/nCCbdJiypGi h/DUp6f8JItMHw7KVRPc7vcPr7lwq72+D3ELJy2mHT+g615BlY/Lx2WceBjSWmHdedRLqHv5eiKc 6CoiEFnGa6aGuXl8G+6ymZUfRJW0PglUcGXCTPLZERoxtkkPXnnQ6kOn4tcOc8+kdSqac+ALaV7E +dQuRAsKzeaWR7oOqJuZ53d44+7oZ3B3S55CEgauR7B5K0NPA56iCynklOxjdfPhZh+H88e4uVcq YenfMSYeQXzlIq8T6XKLsMgodv2m4FLPbYbx5f7G1TYy3fI9MZLsQO80mm79+sCam2n4HbbWVV3Q KKc6txv/IUFNIUnrHYPsejh7lFSoOg+rgsVg74RN2D2M1KAZEAth76LlwvWzLHL7fiobKw8ei5oU 01E63IgtJbTnLy3nPPQc3xIK4RHCZrDcfsohvGIweoJcQhoyIoikGjPYl56R1Xty9C0rMephtMdI iXSOyI2CPTTUEuGVOZ5FVhvlZbir5YNJIjGeEh5JNklURyLzrNni9Sld23TgqVVPTkSEzMfpsfva ssFQ0qimHsGfxdyvsxNJa8ZJIv6Nfyb2S9DN5hoBWJp6kqLJ6d73yX4scXpclXtlqsMtPix/t1q9 /e38OsupdnO2MiVNDYHkx11TkcTX2qgvo2qBW6tsK2nNH3lEwiB7gmanVokBBnd0mR+OsX97e+9K 9s51Y0R0JRC2xApeL9jP93dH9Jzfkd7QdT+lsZTuqLsekU6ySM6tzu7tJ3zBkP9IbSGu5W2XEO+q DAMRN6RGh7btx/grP8EPB8Cqy+jZupUTFlkW+xPVswU/M3QIqpcLNK6XxCHWWCVz8mu7I/hA3xLp RhH+g/57V+5P0I6R5aKk77/1zpvW6YA7+YeqFrYzJnCeR1bencC7W1bCQwofSJdin18sl7B8f6LH vtG82zC8hnU8Qww8CYYlTgizhh8c/+Do4FNMY2jf8FgqeKla/tcJUMl/JkAl5GT+JQGKkvvvMhpJ 5P80pfkPsRjJv0iTSqL/ksVI/WdIY6L/lsbkjNhUI48aVs/Q0YySl4JDXCysRJ6RiTCt8FpyFu/q yNAxDKubyJWvIhB5EFz+54hXAS3U9k7UaQtqPKzJOP8wxLhHJXPfqTE2W8yABJTiYibRMWUux6zl GLD0B4gblw4ZRF7j+0CybHco8oi7Rp0RfAWXrk6TUQIIBrwG1wkZxU/1/n1kC942lXYiF4/DGjzW 9zdFG/+42Toc1VCHF1rCSL/Cao6j8TUCez9jABHbMikULK+BMYDQcThEIBEn3TJ68EaGdPJCiKEh wSY3QRHCFMjUqR/E8aPP/1BehpyLR/VMLV1yPKtcOc2RuVnLZh8hOh5veQSpW+rlUub+G0UBlBZO 1dm7E+jVBOH2LMNRZYXZbS2HCNHh0+WHfLDA4BJBmHHpjrAO9bp9ehNVNMO3ycY2/BGsrH9GShtV 8Fq4vuXCMY1MLGuIO76sJUIeFvTzGWaijW2zp7lBCjKAmxJJQgFJcmclk/vA7zVH2grfy4hk8Wwz 42iO3uSYSzz4wmXqvZ6PTKHLWqiiamtrYVLSqpfh5Lv7HMOPx+bHaUCyfG6Y6kmZkQq9G2d3wU6h LZU9BLjgB5KQUfaH2maZsbj0pXcFn5xsenP3qWCeZ0OehvR2MT04cmBUGhnk7i3uRAB4UArPrUgb 9NG41okNlD77g4M3S4fe5pY/8kKMFHZBqVJvkmXBMAjIkjMeDKjtYtg4hXHtDHmzPfRpDmTPRo1w 6z4xXbyqq6UeksPxP9J58rOv4BVsfuqpHQPdjrz7xKM0vqkOl0aZ6SS1VFUjrQFlf2OW9od1xid6 f/gezruw+6/eE9hpthOFs+wUj+YzzEkrZ5p/lnHX8awkrg+1iysJTdTMdvpOceNt+zGTT2eJ6KOv elxB2ZKP59rebRnNP1faYN1ZyjKSA+mZ/Y4dt9FUtkWVVdy7vZ/rO+Lw5vkzk5vx3LXS8kEXDZZx V/J0hp+28+cQYqRiV4/OO+QcIXuKYz9IPr0Oynqs+KXn6fRwfBOt5Ie+H0nqs20bRK57/r6Uth87 RHOVB4nrh7SjOT8iPfe5vGW9lqf3OYBP8elZqEH7Ceah3nsF6eXo/uRLpjkrgF5kS+Rp9yprKUxF 32jLpF8zhXqLpDJFmdtKcCmdVsP3rk2tltFQ6DcWp/kEuk2Fm1rvbUh796BWtqK64E2oHHYy3IH4 iEcX304SQcBbqdxw0f0VL8+nMp7+oypRBMrDUxV+tHxfLSZNcKUGOM7q2FnvXT1RrdZ2Nr9c2+x5 nqBSK9m/aLJif4fSqnlwSBT0riDPgyLBWMh9d8pC+72c0IJotBU5EY1CnYX2ebMIfTPTgnBVTCAC LjJQyJYTE4gXrrZoD0lbYqTZtp2pkR8ZuIYyesbZnR+HZe8csFh0FXgJejxWaxn/Y+GS1P6IN3ZU bXbM1kSCR7N5szlirSx3Y83h2JO/H21F7ajAp24kyKo6FJWw69mf6ONToIbJn7RafpcGlSuVVO1h KC+/k2OUTFB3H5N30t30aFGSJoR+5F+xcXgyjYhMg//1QiD17wW4MrL/Epf8P2ch+As/S/Iv/SxJ 2f88crb+b7VK+N2meMNVRzlG6CY1JzDYEcGEr7wI0413k8kdrcgMGy5uF4FT689zl4APXCWNNHEm efhtD1l2IdKV58VJAKZknMqhKwUVqB+CC+wya6gLrBwZLLMy7K2P+pDMk1HdwEXVDPcX7F6Cyzi1 Lo+5hMo+lVaXG7ANxPqBjO8+gdNN8AUFxCwFzewHfy+63f63NSLs19QQA8VQl5Y1M5GYdyuS6+af CpAPzx29OScFNdxeEFn/E7hvVdNSEeGQ3EJXYG7CCKnyaSEvhdg+xjX2lvjyap7sSChhuKsH00H3 ZvqQaEBcNNe/lks4XJ6lGSYSISSRIqLAhY3MdePDlC4lNgJJwCPUdcJshovSxGme6TyRTf6ssTOW GGZc8spo2kv9pKhE0jkmDy5ek6x9WdxlQWkycUl5CBwxbvoLxeOtwrKlN1lQw1J86AgVf5XaKX6z zP1A6WyEXDVbFyVo6aaLInhxcCZv2Q9fpUSDt+WVJh58Z0OKGHqzLNBhH+SJpmTo1yygSd3Thd69 9rMzaP3lZl0zz9ZjK3P5kAlXuXAz0tU6h/dpjcWCWrXDxOet/GgeQZ/2ZauGotdWoCeU9wOt24+T g0vm4UEqcvdc6nA2jKRbAYvSd8/d1xjpY+/bPI99w2Ln5eTksfYlpi/GOteO2lG+pLOOFQRdnUDM GU77Dovp/snz6rD+wT+QJqILBZoiAvi+ZpHb8kygknEXfRznGx+WRM/xFhkJcrAzY41HYF29gBN4 tgUIAGOe4SdMpAn4vox2uOlz+Xg5aKedtgx+azg4PgVLMYzEh/04ShxoWL19aoDkCyjAjkxHSeCd hI3hHk758cj5rdCJFu++pzPPan5MLynGvvMEvV7mzDq0/5CzVTWsq5i1NSpa2KL/euXn/CO4i1Q7 eP+tGU58JqjIhybzrdFHi5HxjT63uTsNuZ7M5ZKSLsv2D8di13QJFo8nPj4RV3pf+a6UJW45U91s MbKrW/mT9SOq7INvCfzNq3cX+DED909uUp1N/NLdOozjCKe3+W76R/VnoY/imd+mRp4dfll2eOb9 xU6h71654NFNsnXljxkLoQl5P25WEU7WWY8enH5IhKO7sHeqQXb4AM5ys0qtzAgkiGgHWoZy1uRk kQISe3OCDCdne0jKYRrEbS2m7QCzgASdA7qNXMBoPs13V72YDIqI6cD6D++FZOABTwpynAOMAwvV qZ5z5xljdDeSrMwoqs05zZd2U6JFFbrX2V5wOW+XCUmBERF8MSHXRn2R3aTN/TJx9rNs7wVcTDfi FdumMaw2SAfIDtGkxkULCyv6HrTeXj5O88yEmOhP+YKexZ2tm9jSpUOpV+EaWFPzaHsEbE8ALd16 9qgg2FG2ElqoZhw8FxVZlUY8qtTuos9IrJrj9unlQFlI/jRFpK4sRaG0hv/eAhvrTQ/SR9bq3Snw vtw/dZOpLIPsLwF6hUdJmVx6dEvLlFQtjFhE91sUgJecuoYiS7lcWpvphK2vWs9j/EpOw/UCvo3x TbOPqKcf8ZHfznoEVHP0EWpS4yxP84PgHL20uPLpokP9cjcMS5/PLW9CTTew1MnSxYy8GoZCFCk0 I2YaS8vw3TQEuRgsTncdN2fTF54+F+LGnPBO4JM7AuZCbtK2TnhvoyiVP/Sev6DJuckm7LfrUewr E1rjrcwDDySPAAtDsa0vTWDA7UbwAVy+Jk+o1FF0PJiZ872lbkYQK6aB5xlZfnwQ9FiLB7O0W9I/ SCCfyc0K1CaYfW9Q6WkplcBMkok6xbcNO95xler+JL2XRL3oGCRjv8HMvlRi9ElCmLelg874/f7N aJFr71kIH85/kMZ12CV3lwDnfnLvznBdTatWZZB+Hhsz1t41gGD6VrzJereuVsz4aPjnAI/3dlIN PWmNhDf3cqO//Z6E5iI1r2qHrnO6NQq7r2fSJ+A+tdElpzMmGtxDN52PN8WGJ7xTrAo+0m0MY+b2 2+1ZomHoWrChue8pqp7tbG5Pl5jJTX6uo7qHuZdX4YYytGNJm9WM4nwwlEbcW0SWk8EhfAhq8vt1 JvZuAldU++LuZJjjQNyv+MbOq74h8scZugZEbEfExLW2BY4/FRIY5d3MvU56m8zCE2d/kAR2jH53 qovqajbnGcx9xb4t4mSBuq0+lAdrcMoy/7Ho8j3y+gW7C44euCnMoLs9s7kg2TXpU03trJ4OZsnR HjneicJ/VeFrZaMS6unnzX65KwVaX2XG9prp1sNr6N332RMdNDwG3GU13kvqYJ8ymMmDdEsVuW9M uwdJ0ro3TVWjLfmOKn2aY3qZZjHOe5dd2iDTSpBrTlSeACJ216cYSxT9rI0IAbamLtOC97JM8BTh 0vdKZHKupwFMDlVBAdTP+K7eRzN5oHOO6Sa5X9v7Gwk/rISMDr7O92gP9YWEy3WRGSc375cHQyIX StBE2+xa3/SFGJ5TRAultIsmxHCXCysIFl0kSxrJzw4LCMZhDZSinAc1hN4z5npDKkNe54Gk/ccN rugeJo0Kv2wpPWS47PqjfUTkYWtl+oj9R/3lab9nsSqnI9VyLyaJ/Jehiflk8EPVsoULmPIHM720 9y3RavJQ4rehGk1jhAr18q3ZeusARMBcKFhgV/FX19BLT7DcC1nTY92mozwVpmzzeZ3UAG++KNje +eGT+9WFO4opsxfnf/gE+2ZfyceGPX6Vwz2oP/ArZHLqcdOnuxFWT1pDjghf1uNiTpFGMq8dKS0Z imV0cxzOQ95y+Cm6edpw3B64vke47iErlLCboy/yPd3zqmiye6rzpk5j/4CWv2jk1O+NVapafEBc fKSz8NjOVur2r3nqL7/eMv9467CrxPku6rTuiXP4ULBvIUK2KfWmyv1ymIOpSOx076nkno8p5+wY bz8h5stw9FtouareJ/NhhtFRTS86XVcKB56MtzXayfOeusXRYP06vhlVwq42yc3SKJH6A/FT5Iut QbXj39VJKa6JxbJelZsu9jKUTHgSuuYdXzchvOYm30dfDp51w3X7vfUGGOSExq8bQ1asDEzT9XBE k2r5k0c0UNgXA4lUlXrdZdzW1NYNSQ+KX/FWuvG8UWzkuyqrEVePEZqWPa2UJSW6dgE3feRaI/2T 1KT5kJbTAhugIKAfWDi8FeAYN+AsnqpDYohTjILbOeVvuoTHl1JE8dyF+j0F98d3aiptUtZUezV1 jrVrp3Z+qO3VIYTwRFlGHE5LUM2+dj4z0HlPPcOimbTdXzvrmoq0UqMY00x8iaOTHQh3wgONo2S5 p1Vcvcq1Qf5Nyeb8Gk+BRE+9indTyetwRLsZx6XvJjICoBzT5ClLNfQgCMqijMbdAGXhrczkX3k5 ED/cnDZCmjOi+5K5OXEwoLSuOeOLG2FIuFz6oP1M7Q6TivrL8yrm9F4ZagnWunaH/iTW9MpRiRds BgmsRiJfDHPHSX+xG+l/g7Ry9FUiEH9N1P/Fg5L4V6Iu/b+JqIurSyMk5f7HWftfmFDovzSh0Kj/ DOkb6b+nbwrRzghWvG+LnGiNwo1X/c4XefBBT9NcCvB/oeYWdYDa5D9XVOYPO1hB3nJldqZ4kCwz utQUyQZVbx9f6jPjLUikwCVajW+Yo/OS+eSPH/zbNgK9KshoqDxYgD6Is/wDy/q8kGHet/FdB8kt IEiyengHI89KxQUgb1ryUyi8aFYmanNEZ/ddLilHbLvF5bqeWj5MaDuQFh7ZzJHB+2517bzST4pf xgteY+QITq0htVAA5dOKFAB4B4SvgW8zAAEd0+iqBtbETwLalA8+J0aaLM+VEI9ZXsdRZ6zSQYWE 4xteYltw5ylOhEE0ED4u/axvOnRa5u0WdyTJqwai1XNtLNMoI0+DwLocdCviIxiS7mz7HdTTKt/P J4weX+KHXe/KJEfX8nwcEmNau4Bk+Pce11LMZcjrn1liEPEq/ni43KRXaKPcOfpQBoYPHZKLnbJM jCyuyTjL5/WehbXObQDeVCLiJeX0cFcHjtUV2kXqmXMCokZmqH16ZQtBD4U1NtJhbQ/Ttrt2vjHv 1r3W2CrNPsvZ4xx6IfOWZvSBINzfvaHPv8zMl0KytTyXv0w8MTDLhibpzh+ObQTWOLRApVY/o7Tu WkvvvLa8rdP3MXx1ocjx1Vp2fcl9y+cf7j+0CzleZbzN8BR65869dvI4UA7GJZ4nx+eZ79ILIjtv B3rocexG+6/61BXZFLVH24sw6kcW9FxAEE4zBMZKJoCeTCirt3ScKxGhEUhXqqfg+lkR9tNbSJrz 796QQiEc7Bn0VutF77FIZJtDjWoGqGfAmM2Js/J1Gg9nqZbjrsPYhjuopz40Tpywjp9ekqcFp+mF yzt2+nU6+nPymbJTYtsn+u6qDXhxuLc6JHCvZrsLZCpxc3775Z3RFBAn9HMiEtPBLDVlac18l26R P7q1BxOyA0GxJUGxGdqdDMkt13sMdTTt7aA4OSa3FyUiqIOxZWmxiSwg8Yu4iQqzJ1KO1vd91Zk5 I5O2E4hLVBFyKsZNcRS9mzFo6VJwRDic8ukVN/lP/9YWvr4W20LGnj8eD1woCBF6CyauxW+6vR65 ifquz/FjA9I4QJnbtMRkwHodKd7zG2QY9dQkQC1CXzax84WQ9bOg9ajUYVQssMM3Xfhadq9crmBL SRWrdYvCYQYUB1AKX98vM9FvJ3/boUmLlXUiF//ws1fgQWxvMza2IuJzXi+HNVszexBfWuYAgOYH sU4lCDPgLAK3hozVIiTHr2bQZLIeeOFID9L97gJ4O7X2iqnngJXc8yq2igVJKa/1iDiRCE+7Nea7 bnzx0e3PK3eIX7nyiSaqaSbQqWuu0PsXz7+RMDO+wzFX4BMDYWnKvYbQ66xwOds+HwEd2XPLVWWR P5XKl2n31nSgAnO2SYDSJo0BJVueLuBttuLVIJi/271tBKOwwB/MuZkiPJc0TvIaxaPv8WOOMxdu ouSiHEv5Hzk9PZ3GPy995puBmF7ejZwg70G92x4EkS7caiWfBLg63MvIbA6UGKjiqco6FOsXYBsJ 1JLWUiwqVM0Im3qZiTYvXykMOgiZDvuo6PzzD1OUi7vEMr0y5eaX0szXedGBNCoriqXJRN19LEMq juMeqSi+61HZHU9Xmx8KgcebQupRmAvW8wKli65CVtQTcZjWGPSTlPrbKw6fPuaXUM5sfilkFGt0 wBCQGMyYTSurov1SGcIvW1riNCLK29ZBhVz/8vRyi3iqWEppeLzPvM2XKbHJAUZQpjU5W2MZJUIA lek4SXiwRin+DpD4azmuzN7QwyJdWYcP5KXkITkZ686aWhNGNy6ZctPDuEyvtrPbq1RMtEPVcrKR QhbhF7EZ/moaA0BOMsNx5kT2ikbilyIkRBmBJjU2OtWPBgQAL0i9arQFe2bHzbMLbIhfD6kfkLzP suHAiSRnxvaMjtHZYMCi9P6QnNG5IVZVw8nxt1Qy/jJclEYBenKiHgF1+ehWRwMshVKH9MGIVFSP i5Ho4nONqIXlH04eydd3n5yZogQtTyoZR8CI7g3faVLtyibj1z2twmS1ItzRlD2QwjbOuLSKopiq wK+Wc5upGz+Rg5VXp07j0ZQb8tSJw49E+4WHwAAI+oVZ3akdMI2FZZcZv/iFfGhGKciR97dKCwfz gGwSbGvVty1gUjc36zHP9FH5QEvZbc7rMuhmpUGSRLvOqMg98S222vQgbrGhl14ISS7QhKYDuVXd 8SvJvfHpCkM595HibBrAwZ51kKGn+q+a4vtHrGXNgcTNGw1DrSctIpd95SiaKa0XEefERJIZ2YVt Lzw9mFdWlrOTf3nzBTluUHbGGL5jH2BtvU/LFmxrJvl87tN7VZugrZI/ieuQlzGWsTC2IFHMfsbE 0CjEh48oIiRcQIVs4YfXhzJIRJLL1DWM4sbgfMCM342jWX9qFd8xxPdNuMVInFVi/oKda9Ld9V1X KNMbhHU/rvBmtyE4atuq+7KbSd3e1VOG3fW+Ad/9/Zu/GwUyZ4t4P+oo0qtAIkeHxfPvOWVeoAJP OUYXFCS9jn6d3rt+vbliLUTiqxLQ7ujBmfDDlivm4cDzIt/11Yv7jy+qkl75V56uyTrFB4jsv/46 3vexwS/epcHP6ixozJmdHidEVq6cnZNzH/LyKNj1kJltdtpP/ZmR+YT2ntODgOn62/KvfrHcIS8C zCFmlRlD5jizeVKkHo6qDWdaCFZ1I8RSjFOnlr6qn9NKZnbd/JR9U0EQ3MOS9YPRkCUI9WlO93Fg S69jFFGtHSze5LGh2Lqdfz71QqYxzFPDIof9qyqXvxiZHI3fpriR9K/bPvn6jPM/mBvV/StITG4v Lhh49J38inu9npg57/drKPupBeXpHZaE8MVs9I+1rS9/yNAbPc6pfZhNfnxH4+CB3IyEztuZPjov /hm/F+dv2Wl/NprpKpoHwdY2rsrbdjNz+9icaYtEZ0xfG3hz/fQ9ZTp0VEVUtSe7BlZFO0vHquvX dMmNtsQ2qm8RYRqI9mDro408iOnNMz512HOyS4AKxr/2RFX7Qtlz+Gbf+rrTrjtZk7qbFmm576Um /jL+UTwiQ1T1oFmE4t5RyCn2ILcxpmc6PDg2LYwqbVi8h2w60Ubkac+4Ajgt4gdvihUym0Kk4+so yXhTLXh82trbgdI/qjctHDnY9T5WJezAfjBWH9m3/gWZYpo2mC5uBhGCD5+9h3lnjdWVW8Qlgs5G fzRNb+AEqaLVYIYfKCu0KFzF4U3LY963qHRnw9KG0yrK4CJqlGen8NMiyunntMi9Mvya61CidVXu XEPT5Jb2lMiX7Lrf6scknnyVR+57XmLjqVrIUd+FWd+1M0HZzF5Map+mWxqRn4Qxj2Y3GpcmBeoN RqqI7dZAYwpxzuiO5HbQxCOxY89V90HuaRJ02QdmqL+0aAiI8JxlwPTmQFpaQPvcGVAK1C8au51F pgJGYC534ALl7ZBi6xeqPAmepVrd/YrOX6DlIgokDxSJMPzbOJX+wIfAXFi8taBOlER5J8YpRjYp UCeWSGh9SRUxKxs9AjwBLmztU01TpOHEXvf6xww7Yo2BKfzLOuW7imX9H7mHZTYLBbFvtLqXNLgz LrnqREg6YNjBy3UczMuTorxLZvsrd0zhVUClLI2YbKNSc19Gc/T4vc2/LmJD//ueF1kpmX+JI//P FBDov/B/0X/p/6Kl/vOk/V//c4vyX6T9vWWYJ3ZRrF/UueXoWPTdJOvRvQjBGf3BTOYsnDuyAH+1 /C7I2BnOPsGPxUQrcdWxTeJo06dVEcXH0F1l+6hBxLKJtvpl2Cy3mnS+3gIl9as0P7j33idAevlK l+KHemoj90GYRM/KeRlx7hZ9ADNlHOBx8EekHnfawKyxVkEaWrCxG7cC8RFYlxc40cT8BB7IbqPw R9N7cvJJrInniMgmz7wGA2NTJjLyUEIuzoNO5Qe/XoEjOjna/k+hoRetJKSShOiVqBOTjSbBNykk vpdOvR6DgAlMrm9je1rqWHEE+TpmkBbYuVbUs42jiriE4EU14lBGLFipVQu/LDHu1I/UEZBfGhYa TuT7XFNSy5MHSgduj1Xpgbdn2uoVjN8llMkO8rRTRxfKa8az5TPqBdVlZEgIeH4TiqFFsqJBnL0q LDyZjqtZ2KP7otSTkWWcdKSwvjZUcrTkl9/Dhpap2rXcArMKkBoF42m0HrfuvBRWFKDcDgjKh0PK 4g+QA31lzaQYU01W3bngY7ZoIHGuZzdva3ldZfnFfMebFS0bumzdPzU/apXuNb2UlkOWDu3EOxLV 58jDRBUmMs7Yi5etYoFtJYMH3PFHL2eiXttZZH54eMtS7LUTsdpWVAsa36c5uiRvhv+sZHH5K1bZ MPJuhdqEuyhTLSgyn4V59Zudh4gezYVZ6FoA3UeqOClWvuz5y26jGLXz5LserlMZPwTs3G2I2HaF XUQDVJetv8TaQczmr1yDbn7ME9UFZhu8DjQMkvtA3Eprqp6s+Smqs6YrXJqKkxT/SR7LtCSPT8lA T21dP4zEOCdHrK9BxCgSf8XQxxb/jAEgPtqeLMj2QUxSE2/AKi0uPxq7XoJiOTAXDAah4s0kDGyc 1c8Fq8fCa+Zxo3jYc5TXi+C5PFDPuIzv2itRSblymb0g6XW4MztYxbA8UEa22ZwO5VDg7cPmK9T7 QLGjYX1t5rTezBGJj+bhmOiY+nzPVSA6s7LU3JC9EA4xZpkEDb9efr/26eYday328GPPlOq1Z/RN CyasesYjJVn0zlmaVkHO2E8zrU9oTO/09NPbQyAfynDSv1hrw/z8Yt82LWD62bj6gTB2Ctni7ZFn r75FFkcMtfM8zYRQWrrq9wTknvmPF2Nt7PAzjW/b5+M4ILShp9Q80cC2GrZAInPt6dnaewL4mVq/ +2TsxzLY35awYV8/vQvhXjfgcA5LTKwvF+NNBpqZSECuiaZ/YuU6ppBDWSKljnisjykJkPMeJqFm 9kf9pyCibeAtV/KYAYCAOHz58nvkaG66ZMVRPOWVLqhq4nFeHMkzW2a9R743ieOkRZiW+lic4qxI tb6oNDlpOt9yt2eORpkeJgXfMxWU5gPYu4izwLXs1fBNuC35KKxyfqzDsEy+xTS7NouIA6xoDaAq A3SpZozzJ1/qVpOdc6TsiAz4zSIJ2L5gXs0mg1z3a5lb10CtwdLdUTDdfuuPz5Jo1PeYuwx4OGL0 5iblq+gIaMw4k5EjuQLtYFjx1/YtEoK/7BU7A5lpw8++UEcZ7xClJ4GC7Jt0L72r2eWeMbPZjw/A fOPobdgySpkr7X3MOTEnRWfbHwzpgUJ8DyrJkLPMHx/ckIw/m8gGJG5NKn8IjPN0wRlaf01mVxLx 9oGQYszE0iUgPuQ8bNGhUvyJI07CVx+u42RK7yZG6sZ+OvvDNCEbDQA78h9p2RZ0brsmVz97WvKa EXG2FKvDMwID1yPy8/0fOd01q/nUcLfx+kqFuEDZnnh8nmvOSQUW8Ey9QTtPNu0jGubvV18VOkUX Hs40efg524dBtMj5jU/ihYr84N6arjT4yw16XYW40DOSMXpz4kREUcYHwRpJpNfkyG/o6PzEygLc aCYaUBfCxllbPKUCCEaWDWVooJeOwns6ZFRV+6+jgaXx+P5eBX5vmbymOdsKaoLhuXa2jMXuOv1R sbM5fLkgM8TPyC7nUXGE9O3pvQBf1TYyYbNJptk/kPS8fDYWxUUWpe33jhNaug2WU0mm3aLmHXgU GzZPaxhekiYU9ZqBlYRqo+2ZGtuMb9GKNNMzazykJ3gEtyek3sm77fmuvFLEvWeQVNe57qh0XG3Q fZJuNkmSItEGRLC/MGbTdqr4ZWMi51JC2l+sEsXB+JLUiaHn64HJ7Ovf7fVjnAyYsZAkNf7C81WW UmMNMc2DwA5R00ytoJnQkTQJlyVDOtKmJO8gcOBAqqJYPTcN7rIzgM/FkrllFr7QTPnS9WuCnMfL Ot3Up8+4eXzEOQet57bZ7TIqEbjO6iGe+Ns5oUDt1PS7QurxGxwSsAeDnD9v+Y9Yr3T07y+TECUy 9SkvQVzLZ0tXiFk23F0eVuTcIpqtOY63KTBOIxXxCR6QKpnxXol5ZjwsI/0k8k3tqkelygk5tHPW 93jFiMTneOnxi7PfeSv3FwP9wsjemO6efiywXjx4KNkpYwFY4zWMPQMTv2bJIuEslIz2Z//af699 aX1CBcuBq5m/zpPe8lGtDTi2fWWifMXp9UOrh0sVovzK3YyY2nYZH3zZM8uExHSqjYUEO6hIxPmE fZYVH2+DdkqqgDl7kujXZzmkJYRVi/sZs1G2ZsU7Sw6pYUmsK0ete80Lwgp84d4DVnfW7u/fGsAK GUM0HVhFd8cwWy/RXINbJFoLD5I/fyo0uXI4Uf7u/cslJbs0TzUl60IwCfWAB+C11PfwrffLgGma 1tWi9Y+u76ducQ2IQ1KxjxMsNG+1R610wvg1MKibECGa0K8c2eq3JfYcPjY8OKPOX+giriS6dNfc /DWui/nyi/KDtOWzRLqpIXvWG85HHf1gknWBDkQ3J2m3cepEUZhaSZdCz9lRK58sgnwjV5LNMKVz Lnv456diNkAbMkz7RaXr7/KU72/vHo6l535Re/fjh4Usd2OghF8Iry+Ju8GjsqmoVQPcoj+wOdWw 1oOdeDcGXIwjJ3oKts/4TmR4p7z0+1RTU2P7jzL7H7tfAlMHfxJ6parPLmCjeDVLgTJ8OJX26OS6 qSDDN/KFoC1k6/oe5FTlgaHlt4kCEFCkndyCVKP/JTyMbNr8PTTr0jD+lfhaqN/2q2lPHhWaVC5n bb5Bd128VDTuikoVj8CAEasvfYvBvjVCUXUysd3FxQfqlNePossVSdPwWNwzksEKf9fjbcVaUaKc TfXpiJM8oV3/9UGofa+Uly6kEvXSIwd60inCLzBBpAzjyj8f2pMr8xSIOGsVdoQYHtRFxZwN/oR5 rxPX1NWCC7dS02qng/n1L6SHRqVdN9W0siDFZ1m7kKStQgoXVx4IiVqfNf9EBS1XMdTfURMzK4So pCAqBDfy6ERZkZD+vARIUFPTSXlTAwXPoKXFkt3DP85spSm+qI2HgcXR/Jv4pH3LREw/ROgBJKBS YoxtmhdtRj15rJI4Pu4oWMpDXr3PXDwoiC1iNWIQrAuDTE8fiAJ5/RRu1E0LNvsvJ96k9+rWhrR5 UjuSwjpeE5Sk47uVDZTOSXACF4yQ82AgEHRuv3Te2GIFLyKtzz8GbT5qPgAB0UGHHN9Q8mdHliIg 6R5KJx6d3ZFeXLVKilM5XUPvY0GnutOzZN4o+KOoAt6t4OjzHX6E+7S+szs2EK0uQ89/wdcgYMKX tbnzRodmfNt4OqS+fz1wfOViTbzeRoxmgWdrPG7XSqxl/h73uM7FD/HYlpuDNWvAlE9R9MKt5OK7 VRIC3BIZs5s0F8Qty8ZkD2xHINpAbW8XUdQWnIwLFnEpcE8SI36pvnGxuUViIOb6HK12Q2wOth74 xUP3hqSaoGRMJqrVc7vVAZ1pIZM8JjNngqwdEyenQpHQS+8uyvDuyARlRNE+kbk0k6O9IW+ClW1l 2yEBPdl7xDdpPzkiMsUNt/X+jt35xrEn1iH0hh/TDtbIE+IqnnGqmamvmTk2/4Vznq1ulPNBvdv5 7qoHfL5zgJxm2ku4R6kpRkYubUZTDt6MEajIVXaVhnIrgRF7Kl5rsNIErvFNLdAiRZ0+MvUs1e8q fbzy0amujokURUXT6KZ6Qv8uKVVuXn0ulo7E2FMVu12m7lcJ1kDy6j3XcDnljwqeXj8QEAKK+LDd zRy946gZf6KZtt8pNIeyIcBfVXa826QIyaqL2xe56SN8Uy9auMJIvcWK3TGRzKD/Z2opCK4oSDX9 HeGkj0j59eelQZ21aeekV7Q2EWZSvWONrgZI1+DKM6Cjhbhn+oN4a48TMLsoFmtIB5cYCj+5K+aO KbRcr1End7aIyj/oXQI3lAuOUmChQD1dlqhdG2UVV1DfshnpPUYNWqahOYMIH53e7x94eqT3uA1j Bz/5hq8A0yRMX1qI7GI1A3d6MVEihrfNCu0peF6PbRBtTt+s7tGMwVwkcaRPCUjSTY+jMhrTuWlc pejpAyxUIJ5l49jgyjhcrTltgGWMjuXA8spgG29miYIvyk7qyvvu9WrSbR6gtHcwQFaS6CPfkH32 V3SFiOIIhwT9b5fYwQ8uqE8LvPat6Y6T+5Y5fEAGBVlaIURrs0MOscPAinP0tjGD0m29ObkGkM7w I/EcPacQx9DPnE7SrA6konfIx247LvGWshuFPHgy52QvWvdx2D1iriZtIfz5F7wNA5X8wAomqOS2 uYM7v5RRSJ13SJlHu4jR4EuvEwvpIEvrEHm+hWbtkJigkBs+6DKPFFLvL2IrDCPO0vnGC6ZR0gtp CytGIV84zUc8GExVv4y4LESi2l3cpL8b5/y+J8Mg/oTMBfrKjZHX1zztv2Hwof9ZiScpg/rXVpj/ Syvx/qUZ5r/3lPiP1+ih/6JGD/2XNXro/xQ9J2T/rVh7gYqHFa+B+ruT91/1nPDaN/5nzwmMDddC P1A+YLT+dhOjr7SKCMQR9Uqzn1bTVQQjyQIZ6EvPoThBTJkQl+m061hIMkLrNvfE3hzJxJ04nyF8 S5nJWfGcuVYiBmAkG94nD8L0SVB2LA1fGaT1SqZoanFiWZhJRhs6d+AHIAcvejWt9W1za/ELsOyS CRpXsiJqMmtSwJNz+hnNkAh7ZoXhJI48kGH0GzqwTy7mHCJy8ZQTzx3RKwHltp9thJQVqO82atl4 MjQkWHO8FYUELguhSjf3WAYCIjxfKQdEmY40jmvav1PR6k7kTCAJxfEM+FPGLw/WmnrmksLBzkwD DqUq77RLgPjNEU4sSr5qK6Pzs5pf+DgOpIXwXuLR1PROG42Xp/lDJjLoAStIuZclrkJfxHHx1qSj azQqqODLYGkg2o1Vt49pRro42CZaTj+ldOImn1ARre4rCX9lDelDbcNekEMBgKeFuN6OMvlUPkoO umWP4Ukedd+WnvAiRe7ON9nusujX0Rysz0su52ROtf4CKFf++Q/Zfn/6S5JkphYNS+kx/sEKGjSs bc8jY/xTqgv1qXlK4Ln9B1FVNaFrkpAeog46EMm6MQOQSqhBuovwbuXemkzRAdzSwOujnlFzopZo 6Wfg9c/5fedfKtretM7L874+L+V4HIIgCWYelu5dqxtZ4GO7e0tOj+0BoQfykK1HFHD7DdKNsNuJ HEyXdxxyPCLWtAfvheJzODgzQPtpyonSoTtq3ssCoT5kg+a1nsMHVrCncNBzUX7NBcmn1tugu5V+ hZ/CTh7HuuuQXtGB7n0pSj+KHNWcm9biIXWTsZ4cZjNUnpTdPGImbVXzS/ADAGaV27hZUcRDopQJ faF7cIqy3FEUaQ9RJaraE78ZE199e+UOkNqG29lfv65/WFpOkf8JKExBOPRTdHdvUVWH/cTrmQQu a1xA5KREzwuWQWROx8/bb1O/iy5ybh9Fthwtv9PVxnw0J8+20Wopi1iTS3HSHNgceHjyCjm8qHdn nM/w8clofNtzTzf6zpdA4h5bMhJcIiBXLIzC56SA+8g+8yDM84R+n0BKKLn9ysGLAryZOywHTGGj tYY/NEnDyV9xRD0Qd12gkpgvLzT3es+zq/r62bAOOSeWwQY5/b53WDdAuUSIc7r/Dwa3Ekp9EbkY jW42mip66NKerNjgLJdojm3QXNutGGrTD6jd0mebcyYgHzXS3uwWqJUQAC8h2EsTOn3MNS5rSp3X 26vCplzKOh2kd1dJw13kLrczSibgOloT/AlWKCJ8v4UupvcrKRdnriSuUYhSI1uZY15VIUN9TaEu D0DtvGqaWWWM6AnjpOWIKcoY0NcVjb5LnQ0si0FNKuuAn4lEAo3jmv0zB0J0VVxMzDlR7co6n6i5 tq/iEgLCksejCZAylsqU9E70OLkwsmKkPnvOWFZ33wPd7e2XI/Hbb/Qu3XuX5Zb0pAfcTLSgFl0F QaUE6p/MzHsuui/zIHGFcszrg+5U1n1KvOctAI0Ob2iWqdEFOBsQ4etHngwrpZOOy6VBqfeUJ5aJ qmHSigPn9YySrERiWCaWZrBWcguizvbJiCila3L0Bcj9ZlDGqHvnhAc9ReTrz6DuNea+EWqYcvlT rpw0MAlYhbyH2WEQ7rkEvXoW7R1SVSBUhirzeJVuZu4600kuKyjkH2am4m1OwhBZs2MhFBSFnMl8 BvFy5qkfz+/QDkfN1+aR145EmSzQQW971ek0Tvd2mwkcDHl+Zg+niz+4cQjSEtFta8523jU2w/hR LlOaqRP1mJDo351Uk0LvokfjmhKZqeX0gTt0MnLro7D4eHcoLx0aRJPIVKS8CyvpbqAT/PLDmggB iyyuiCUpZAc46Qb3sC3Sno1aRPu7BZcYbyIHfdmYXw0CGZnkbHG5icMEUZAwYpHHpGF0vyaAj7Be aB0xzBqp8AzC2fKM9p6D/6hNacRITYRd8b4B/cQtAudsybwlzQ0j22lOwhvj2YzfGnUHkKeYwc+5 V2LU1JpO3W1E7Fytac8yx5HiY9HgKTr8w6IZid6su3drx2Lveurp+G4AZUDroxzwFY23jOAS3Cx3 hOBnTB/xFNRU57fJadFngRebZ3zCg4t+Elx+S+XZvC2VnX2FIIhDuSQoe+OxxSssNBvYRNdFbkR+ WNHOK4KIRRZqr3PcVN2hQ0aRqbJhqzG377nLxZmJJPYWC4Vsx7O+fSDSeakEitSVjSy2AedMQnYS wuWHPQCx9p6jpPEslnvsch7UDlLhc/mO1ovhCsoJsCf3WhuaACgVv+fq6fM5ChZmHzQcEpSypNY/ HN0E65UPo5F4ZxaedwmkDe1s/EtDP/RuPMz3vLrqUmKJsztcEVv3nNgyVOV3PrJeFDxlE14puGU2 XkBar3fltDxgcOddtkvt8KMPSeEvQr1eJ3R9QuVxvpuxoGFFj4psn8pn9h8WFaiGwF9uKLrlPDI4 ILpPmX6CHiyNYiVhhk/1T5R4xwrS37TTENQGK5uHZeXKoMdMKff4icmrneD4/ZYF27ExYNPTeaE0 6vs0If0hTzaEB3TRN49IwXudZWu+1Y10Kt7Xir+Y1PVfknMIkjL+frouEpeOxWlwEUVwbP2uNRRc 8hIgiuADIsppesuad7vnW1/5VqUh4abd5Z8dCqBN8z09LbgP25t6OHFJU6rw9BMUbpiXrogiT1Js +qYZSYTpm14mA/ISNGJVbGNJIdflzoBJawiuaBOs49SLG51eGEQurfeONhQG7LHgJFyn9XkrZZ+e 50x+XOybCpwgfkLFn7KSFZ4sNXvY2BDSwOWxXCMjarA4eCvmni6kWsXi05P8sDvc2z8bZ+0jX+UD uWW2u6pyvhLD0Wdb786T+BrEA4y+Bx+O7sI7jC9LjCtf7DF5Sm/cPx1zS/lO77yA8U/fy/HvM0RM vLEevg7YQemfEqlUYL6Qr+5PPkBGM0iU8z0d0+QHICWxss/KZtFCwM1o03yAs5Q2/ImvtI2QQKmr bmkNN+moWK16uchg6ezBF7/j0vKETnGDB5hNMVF/x0+pzgeAI5+q0QF//B7WWgGTC91Zt9Ak6o4H hkDcB8f9wZ75MVF7V4mjDdNtIHjHgmtTumH7aY1iORz4YXQSBx+9qs/Bny04+vdAJvzTXBVAuAoY oY8Kek7kQU+VNll78APGDSyZvoRuBTefU5Sl9Td9YoZPiDX7B8EoBqh9XGi0NYhVwJyivcVxfSR4 IfUtoYMj6Zu68jfrlEDOhE/2eK8TTWQUfA8KUj6AqKzjYE2KAiKDA5s5ik3lEPzPcdJLijpfSe+j XZFOwhhOuBjzI6oLNj4OQUxORiuO1PZ3peQgU5aMHe01J0VUtlX4U1wfHo2bNxWQr2NeqtRAa22B JFnDeGnBYZp2YVcP6sdM4pMwl1VY8ZJH2fI0l6O83h+sFZa6KTFv7HfNi3chIqD2qlvM3XMslLEs RgTBgF7VgQ22VFHGlBHysV3z6XJoMtG0mqUhyZJmn/53yuU+ic0RSM4gZFVB9wp6aNiJwFjC+gWK D4J1nnPR8MAyBAhHeTcuNHnUiFyBPqzdAYIAYbaLWxS8/hZGa4eQlBlfrpvHwRK+4pT1EZjZtqyJ t8JVTKDZ9mXo+IpotfC++dxeyPyMnEgsYbUasnp8KGrc8WFi+pbxhqhP+SLGX9x/VchbaU40iifj tx01y6IkxRPRAQku8NolswTklljg9EoQN1JU/nPgCmoO1mwExwV+QAkpiBm/p0ZdovabkR7AD/sF kvW84tBDqTm2/5am+feiRTm5f2mkjJb+36Zp/j8YkH9RwSj1lxWMUv+J2mhM/M2AnCAj2UNGeXGy 6GyqgPfmMRLZEKFZ9/J4ezmmiV1UNUjJT44OTOnMLVg46wuHH5AJTeAG7V5Zg5sk4oe9uDKgg30S IcA/xY3XoH8dMFNLH9QdWZY+cfErscamLH2DaNiFayCb5yKPkZY08yDF3yqKXLZQTcRdlSVP3dBV 6nAcp/RodY+gzJ3VD3QM08TocaWT81AT6xIEwaXg/AuhkkBPuLgIzdoBj7sTT54yIWqXjoIk7akA uDSNwBPfmNZBRz5VB2rtKvF3ZVbeq+E6wTo2JYqRinObg3D1pepw0EgdlE6oQTgkD3P8XX/jJrSm jhVUf987vtT9kGuh8qSAljcxpdvxzYDHdDEyBUsRVSowGlgMJ48OHUQmp7Jp9kunq5r29OAN/eha 9mdz/9Zvb1YWlhg1RqPuYe/7RnOj5ssAkNyTLVbUsy1mvdghE749QmNKNzhKGW/IoJhcXiLT461N SxYLoHjNbCxuqxurRSdfxzQd8JoFbnQCd2auD+jPWJ49cyqiq3AoNxJpFepeliFkGp+AcMllPobK NIW8wqDpTAkTSCbPBBotzLRvisjK9+GRTs7MZySjeO5mXewzAMpZNG3NBmnnlC3TwbAPZi+0z9Gr L6wF4d5sKOEkweD1psJTxamgoz4xwbLc9bpkbuQsaoWbIkUewi1rraAHIIz58yUX+2fYpqHo2GRf SC1Ull/o0Kq83HsQSQcSUGy0dqWLcY+uj0epMMsLFDIHLwXWODNLWOsgZSHcun2JMQDaW2JUnCQx 9RD8dzSasEX4hNfVjt9DC5bFXirVYu1tC5JZiZRNoH0CZ3BhbY7SFiCr0tyDTae0/brk2bOxW+/d CTaFFf7ZKuk3HYoihy/MeZQE/CnEQTzx6RFWb45ZT+TLLn5OkdYl5p7efJMqm4uRwX8A/ZY5U2RS pkosch9j8vX86gx3BriqzZKStGM/DErwxiq/vwalMFl7ZSIZQ9cYYRekb+zCgAF5q3kRzbB3EZ8e mPO96yNo87ZMff3doFrluOXSonAMBf26hrzNOffz81TQZE4UtvFfj5DDxUznY6n10JFFYnSDKKMe 6meCG8PSOST9rJG0fhTJxReyVZ1bueSJZGJmFTSVeeC5mmtIE9EsaH3QxGaMTfLIZxq3WUKqAw4R bCTdaD/D0NjFO4RSsf+8VTzMus4mDUs9fq00HPPHOkRMsP7bD3mm0M8zCFNSg4j0KmmI7kjwbRW/ 5tYccGK7iVxxpARSLqsDAOgh4sJNG1NiCagwFgeonQAnDyuIyEFXQVJbIIuJN2g2LKOXltKB/iML YtsDwFwJHSzBsPTZ3UivzuJUX18G5Ph/mQ8TIiNaXc0U1BB0oStH9jsnR2MTU5nl9zjtdywz1L6X Mjrd0uwXDS4wyVIb866Tc35YXsFtn8GW/w45BsdV/M3LwfihhfIZcb2PTFV4hCGc89Ki34RaKZfJ QMW9RmLVIWOTJKSFJunB+o7v5ckVG/g8+UI0XtqJaqV7G30qxmV6DMm5jZ8YjX95xJb3h4I7lNzo ssYSHmyg4hazrhF4Ece3PyW2Z9tYmvTdaiqRW1mr2ay0TQVvqMIU6EHPZh6sjjPqBDoMe3eUz11l GOffEd1j7pbFrNYyMedvlXM16SfReFfFXD1DdMgr4kaz2Z68ycQrDqRFbLC9kSlhStlGC7YquU/I VkgVNzsBodXLcpViRh/tlaET717FIJWJS+bMIBVgON3QZN5HQ8TD9APY68G7YBbF4aTzXZcSGfs9 1jQP/vKfDU3ru+Q9RG6CahIfs7onpHcPG0PE1xr0EHFSN8YX63zzVjCGH2UAnNtJhrFR7LRNc8QJ M5LUDS1krj2kK1wPfYMsZTJz+VZ7iO4lD6i7C9lPmnjLOsCA1+jFeDG2nsB1DdOY9wRtLaW847nK F2aRH8IDtWZmyThxsyfzA9SqViP3q14EPllL2J4B2x1Jr69/WgvX9qeu5tT4mnJo/OpkXLnoO6fF xcnHwyZ/sRlK3swJq2JbqlDYQ86A+BsAuzPWKOVK2tK5N39sBD0LbZp5VIl+rbGW54LTe8RaVXFK FrGqZxAAo3eLIy4c/WmvPC0r+SZOJdZQl6TmzFywRFaB8k5hJC5gUGjoxdaNj11Oauee7ZwXw8y9 KPNZY3d15KieKlMfjdOStvkDZPkEc5+iO09wWoaxkQuBWSz5fOa+6+D6B9YRzJQ+XM7c7RkrW01x pX56MgjU2VsUfUPQHKHG6xkKl0scXa9VDJVO6u4aqSokRL6J9fDs7c1LUrCoJHjXcXa+2bdg6UZd S43z17L0FrEdY8cKyfTcc0vO7Dn4ORPVGWpEi/sQsz5hCI/+PU6pAlFXQNmzRzvwZ3Hkpaz54xCB yFVkXEZKvnTlQp0LAznug4eFk37JvP81j830GCw68xlUQrRJjASjRd/zmtO+e7H6p/x48zqKjO+N gWRQQUXF5Klcy6BqmxOt7HHAgaj5cJGM5W22vgLLoC8/5bI7HIj7no7mK0/Lx3FjjkRW3L19X3cf KJS8ypsCGN7rXtSoyxl34/hmj699rPzTNW3CTRBRT1w6jPF763gtIVsAoVPI4a+b3xfqzbdNN+kO MpzOdYQe7qFq3JoaBJ5W3h/pHg0WjZi9aFSlIH4bD0rrN+gBnPh/FqSRrcyrXvv9Jlywa5yEh1wk JwqC17KpqlMZBBd1CDzKnvmRXdTjLgzMaDS4RsUx4r4XbS7dB7LV3q0lIrwqFDyZEu4K7hO1X9LK 3eYgprqWVO78afNwq/6d9wWRXcMM9/uc2zaVNLAf5FpPzWKR3pVHYS9fUchta/BwPv56Q2JeoeFk 9/6XpbTZ9zty95W+tekvtbiIFYzEC4g8FsAVP660kWk3korY9W+NCPj8pEDyo2fG8krg4CAV16vu N2FG1Y0yBaaJajnvjO1+UXCNaqO/V0x/P2owTSotOIn5WQYbcg2xcHm6duJoROnIq6a+r2p4vBuy jnDNrPR/o5qbFj196ksHSmzi12pxnLKMW19dcB7VXV9Cq+DuIJYIlUwGUcXzTciLLfshrUyy2Hiw O0SnmkugslsEMQjzcUVH9EIibsO2rwRir/ni2knL9Usono5pkQxFMyknQAKdQm7vM6SXqaMJYhPR phl9t9W3rN2dfK0a45FHJ7Ikf11lJ/XvVXZSyH9prIL+7zdWkfrftJ9e6i8K66T+8mwXKen/DLl6 CSbLxBxNwqqjHA5f3k44evSZOjMR9FUYMXlO1aYaQ5MHH/eWa9euyP0mshak8HQhJXv5WwcGK82k r54pUT5U2MR2FjErAjOVZU0GtbLjxjya3w86OekM7PlKLvbGcYfRpTlBmFT0TV8qglmkWJQ3FH7j M+bong9yG+mLaQjLbkLuhjqEcH1NyoaAsArfjB0yWO4rbEYVOeZoonJ1cZnB7gRUKqDMfCGSgLGN ioEmMrGJnGQ4Vr/0dKZgwxxfMDAqpz1gBculCd8H9p6NhW7y+E8rg8tPopiYedJMJaCD1IoK9EJG QEamCsNtXoAy9LvpNw0JvBF5b5NOBKMmPDiaWcP/50MecSPWV7zDAeVW3BqH80+E1P27GvlHhApf svemH6UydezTZosNBHhP0eqJ6ebuFvvGsL0C+R42pOA4iRy/lB85zR/eHHMnjFHS6dG8+9u5HBSG SZs3bxnCerlySYn7zC9FOUnknxjsCxlw45qFVumAVGwXbDx4PZ63plrY2bzp1HBzFmnx3MImIAl4 cgdfxsVVCwUE6SKTI4l662NIhL/IC/bppU1VT1oONkpxkv7Jtv/eFjnxbydKae80TQlJuKCbXxG7 O+51nN50jZm9khQRIyVOc3iYFKljoSFO78TwKrZnbEXL4DklsRWPybXrcIWf6w2TRU94cHwyQDtR rmZRFlNL4Ka8Lk0eI7JGLm6JRnvCzJ9Plq44FU//qNHUXJeDfolqkCZd6s2p3ek4lC/FYwWWZCqP 4WPq9veibuhPawZxhrcovxI0qa65/+VP0k/YlWttN8v9DQMQ9n2gXwwxgvFf48tsYsivRxtv1TgW ucCYO9YUrIiDQYtYaJ/vitRP2rtUfMpEnmzP93QraCYlbXk+6Y8+YzhYi89sSuo/Wf6hbS6u53Wf H142EMKbYNt2OfcLxNBfCXFyqZreHzAJQUxP2BkYhxrr4UDEBK+E6c5G3Lf4l74nv20MQVO3byXS qksvlmKU895qc/zBpUzcZI8jE1HNJtMM2Px8+uAG3cAFtv4T7ZU94fEN819pWXUZj25A9CQGUF/P vn5M+vGovOhStopJeZ1GPiIh67VsWxCJbRYQeyYPvIXWzb5zBYrc9yUuvJYkvVF2GGkQCOq+Fxxd mBgUPdIO5bpaD0TEQ+W6V2O6uCDZk51RIJ53m8+Q8czWG2UwykJ2lva6LHK8rITW+aLCl9IGphiF RIpCIUkkhl4FYQgkFZB7gTV0i47U994YR4PODlgZaNWApES1WRUxTNpC38P3SERxaZMs2OIg0pTV lxHTzjDDEpjhQLUywC3+/lTemOs5UbEMZvLt1s9IzsOXVeJcqpDI6mPz7m62bCl9W2IiRypecGlj lCbbFjIQ4pBzM0Ozg537fTiec1hefOHnKzgnqXq9FuBNeUycy6zFk2RrsEp1cBQfM1X8/shvondr sZzVqU9a6TkbLu+jdfr7jbZZXJUXcZq6QYn5JjQwFbk3GeAHI/mZJKwZGjiopiInJ2J875lgTWQJ QfIp0WwYCfk+DQ1BspC28qEBnd6tTy3sOP8F9mnnL6emtUa5yYbfsg3HDbfsXeJrW7jLc7N6uTwj byKWmIYDHa2qBS8pHOYlQJXyA2s6soKnyBIEHHNFQY6FihsiXrs1GUdn6pLW7mW/UpkPV45RNO+P 3GS2j7dwn6GGtTTBNT6Hs2vOfr/jcc0KKHaGRM503ySaeZjfRKBIVeYCnbLX0DQF2bATBMDj69LN /qp00ffZoDNHnCxSOeCyDWcxsJjyQn6GyuRFVWOtpgzJwfntKCI9MKcmZ8xZIY3y3WzyRm9mYw1T lVqrHU6ellB9TfmgBOfP2jzP+/sy5zBFFTqg2kEh0BcxWhUBDbC0KYIUSYCr+Ku2OMAFo9YLaXvT TMElSH6W6cZAEruBVgNf+8n937+rRCRyz6QPxwkOpNNHU1iY0MlkG69UQtY3efEDn8ra7l8Eur2u Jw13bl8Y3NU0DtHl4WGjKfbWomG/ltZueDS+CjybHiSNfuH7c12V9t6uz2bA4r4o4vB7mD/pxjMm GeCao0E4cQ5tz2K776TXlqxedo3q0u0/equnEpFYkleyr2jfijhFlTBPZjLArydnv2iQSLSKMb5c zBCUfeblgciMG4eTNsUwO718CvYyK2Eg6vwy9/NMtXg6b1nwp3djOueztOpRuSg6zXU1Kge06lXH YOW5Vrr/xK4N55PiTP3bBe98HJLzMi/Nw6fIwwnOqGWmKvt9YoztHcyCJuAmiePRsZriAcXvbfyG eVtzDpiX3iWKrEz/aTkBmpw7OfRannWTucg6+Ivc63xXI22jCuh4ncIQDuWWl4m2w0S+lixea/H4 hnVrNqtoGGB5dZVpONEsaAPg+V0Cae8R3M0uA+nJxhgSOVhvNCnWE0aHBDtcVwZEBGOJMjl6c9Uo OE25YtZx1MpE+hQlaE6gYflSDn3vix0k+thOrg4g1uLidtFqjivz3kz2muNZF41F4OEzDgeUr2DC Et3LLaNnTgIlbwO8imwMZXZ/W2lqpJIhew0WTJCJ3fHyZLw5bDsFbtCSrgpLmFxm6D14XcSwWNQk pcNT2rLQFUwhgtwCvtJssDVYKC01pzL08i3H5A75naHkTvj7XCeofeQbT1TOGxJNLMXse1/m9Qw6 pnWn1Ic6zR6bSXPydw0t9Y5KTpQezRvcIT8VeqqOy+J+/3l3GeozZQBaHyJMrdw9MPLyCFCXaoRZ hqTX+SLP+67VO/HmZ2R7KLb2t3DmfWoffpGJOXW3D1Nab4OkRNgIl59GXmJcYW+Yg+pS6pd/Lvqc UD8VjwKPMJeplgg6dJc8z3jM2scq6/UjRSqL46fxNz/xFd1wtZ8q7U0P1Txn11pjoxJUl6NzwwRE JprIKi3WpTNvSIl4avgyzD+Ipgv9OltpVj/8/JPiVfivncPr9rDbt1LD/wBHzMXmQsRbQICIPRVz 04Z4UtLNPwgNSQLt8eCu7/H93wjLLu7rTYKFZFwqmcIU01s0k1GbT0hAalEcmeTrnDsqeXXBoFKa TBLIY2zDHaR2apP1rBOPxIEur67K57pcV/uzFMJJKl84xa7rIrhu7ujiXdSjqdgcJw2Ck44ciKKm 3WvWoFelbVh9nLw3EzCrXA5/T7qp6T2q3LeQD3lkiGX77KnPOYRC9T7gj1ijEvUg5+ICu7ednyh+ R6zuwsXII/pg3dtfSXKSwG0UcDEIov8kNUZo89GOSg5F2tVifP/8NAU0NsONz5Ugiveoz5AwXBrx zjCt2+WHGgq4v1k+Ld5s0IdU+6ZWXKlvMTyLtzUplR827DUXCB6oy5CYZqG0T7TCV7rzNkjWNQJH CjMBnWLbLWPbF/b9P4v7cf5VYH+JBumyQAW3VXG1tTfRMarR+Fdn4/p1411aQPlPsgoq0kGfHpRj Wd4Pl2aKd6pEXd1a34Y2ETmNmkMMSq03cxuSNymKc8lT56t4SO67U8huqqjWuT4gMNVmsAyBnVhb eBQIInlVp1wXbA88xqNRTNqBN7lauFkv1N8MaxrMeMdoPdKqouXpreIWfM1DY65B4xqb4cA3/Yqn 2fsV2IgtZkm9RY+/tzJWYhSRpB4B2H4+yFKtB4/bi4KKGotQSKfWyPfWKN3DLzImqoNS28t3LH8U R30dtbpxUryK6Q1rvrzh2guZJRUV3UG0wCorJ893tb130tzXT1zcx8T9eGmHvy/tC71Xnb+/i6jV cEcNOp9fHLnxKfGXqZ415loPDAuQjks2sjm5j+L3ZgXdO0+MHEUSAocG2fpaOIoyYm4G6fEckSCm h6TUgXmB1n1HMug6Fyk8On9HoN/evyDTVe7ISybIghfvXhwUK32ZIFXuSUZyDgTmlJB8llNtlMtQ k5M0knc8526tU9Fllo/RkTY27MUoy2cWKs8Vx5oMKMwK3qTufJvZwoPXkjm6zXk53FtapXgAkJ2b 75uLvGXy8VbUf0Ms/dMGkJRASv9LXPJ/k1gSV5dBSP0HlNNfHMco9ZenvkvJ/R/tCCiXwAl1qgkM BeM+rQnzUeOmbZTq0Vbg7b81N1APFHygqcye+nF7NsGw21Mmnp6PK7EnP0lFIk/D4r46xlby7Wjl wpEckyOCaTMxI0w3PlC2d7XSiT1mLVBAsEhXvWZk+q7FBBjMpzjS2+ubTJtS2Wcf0e+HYtFtt1E0 xIgya+PkWB+12SOZk30lRQ3ifOS5LGUlaJXnLRHM+8P8lotubwlMKa+cSiK2MfTlsB+yoMRIk4bB 9uoo56Om+g68nLDPNQ4Nw2ruNuG5A9PBsMlcZeJyYoItq9BYQecgrqRg8GX7WaEwZTJy2Ja7LyU3 gitRRRMnmOgYWsgIdgwtII4nsLgnNnF22C7jODsC8/pLAmvgMG1P/UjiakfYNJC4KYgf57vFlK4k kuSco+AnaygEPb7O54rfhEQhKByLo/jBUeByLgoH/0L+RJXiRD7yWYFGDHnQUTRnZ4sAS34NnsiP V0owqzJbO7CmSANnmsyvjUZllemOzq/b5s+aAYhwOHqWej2ejcRa3neCdlideeMKHSutjYx6g4Wp iAD9d23P7xgPCEL6rGfbBuzsTEJ0lGItGXyC3KzJbyIKdIZ9AgTjyI2h3vMLm7ROdvSxoxk2L9Sa 7xrTqy1PWb54eM+qZuG40XZVgkXrrrnygEfICuNzmdvaNMeTzEse9M/uWpvbffarWTweileSfkrX fucubxl+00KJ0vaDcbdz3LpDJ6y31P2wn6mHvFN/8G29It2xK9UF10oMyVIMCr+li+asoSEMNtU5 HsVHPpeg0RAbm7XWZG4MnVVhufNZpIll596wezbn/hvrOSmouWuvZ7q16jBKtCtbf0BvuF8ehoWl EuOUi0yPFPQ3NwomVLZaWLp9Bz/bnybc/nlqGTbHS4ojfsK2Es9lnwuHloEvPgmWEXZR+D91ZFlK tEpBqYCTwJk8ufBjdThsSzhvJrgIxVWa3EnT3QztNcCWBCuDdjp9+8rWFJIBmoPoEMD9J9PJAIg8 PLhMBJQY+/wJfTPmc5PHkLTWvbdSkDJJ0bK/9zYVTPiRkgy5mf98/rNTwccv+LeP1d7jy+J0DW2q JwQiR1Zxn0IsP7aWCo/uyZMZbrPm056F+F0rxslk/TRkIb1fKefYGmgOXd8PJoXDSLoDhz8DQhFy BsPNWRrmlGnf3pnrfX6b69S1wGq0oly+v/HCYvr707KOe3oIGS6Q/duSGn4ezUq26GDTyZEZfRXi 5wcK9oX0tk2IR/4d8iRAETDA3y+psV8a9NWRmThIRwexHd0gyeGen/fRWIQpM9rQc1wz3MBju9r0 ZvnsiDFS2kpVkG6o0lKDRFLclU/kFEsIzHVYEqB0YCBtw2zPlHJrG9VLZOZiMIs0YRSeOMhblpjy BdP3QmQQwrl2taVuhdV97Rh30OsLN/4RlvT7+4JVRe1sL1lW7J6QCwLTuevUdvJYJaDZeXySb3w4 h1H51Bg6JI8prWEbgxxRBF/0NIaWhVovlBgoA/pkehaFMEzWnjClmTV9wszKwXPZ9HZyS6l+Kbwi Z27+aCqQAeaywZMSIdUAn/W5WRXNbnmoihNkoVZi1P1ub9J2JhQiO8DIc/UEBBkW29VSyj5mLZ37 HTHDwqycwHOvLOv2g9lwdjX3o/OSoMmEKatAvZz+N5Z1KrjpcD9M9oR8pb2UCCCwDktN45he/IG+ sjg+uI+FXnbybKLI5KaKHjOOu7JIe7iPZTSvNVXBqKWpwL/Sz24dAXaum4uVmwWTCAQIKr+/zkLs GfU5MjSsR3VyWhQaHfobAkH2e8pw5dtuyCAcMZckyFTe9Hbtovz5t4GiyiZvQytQBqfUNDfzW1ll IltS4jaO2N4Jxg/DQQWq7pJqsrWMfcUOENXfTKQaPm6weIemLxFyuLhCVnawn2yavLiqSS0o5cpb aDrcg1eOsO8T29KeXu2ToVJjv/Cc6TZFcIHd3WjdJ1zn4l/DtBu1resseijJGB3jDaXhjY1mR5Y6 NJfT6hiVRt7jsqNHyh9Z36o0Qlc7J4x5RGPdFDMm9kG51AHrrqRRTMnXPdnEguvhcUaeim9sXTpV mfLy7+HDXXGVq6N5/quuntWhRtvSdag+HQtWlBMP0fQ7JQaCZ61Ep0wyu4xeAdRemTQQKjX9LEuB Z9NEq1xhUH5ngdcbGujx4iYv/GPsPcz9lZFepYiIH9RnnrD8YvkHzhWN0WBUZKGTkI+Gm5SeKkeM MhEXhXKMFMd+BxPW0sH35Tw1CVGoheTSXTAxUigGmUgbVYrRxPyQ7Gkbg+ls+fBrNcvwA7dp50pD DMj3lfh3iIqzuHBGFIKcdrpAlTMujy5GH5O1m8bP6V0+2wvNkaY9NItgAv4gfH/zbew7Wcxd9faK rDwfz6Be+xHPPcfZMsdq9lT+59YVnVU9dMfQgLasA8L7Y6VLb12a7sT2qffCTi4Nem4dIXX3l49u 2PlgQXNLLlcrK4AAI+jooPjJSu+TxXDfoq8v8tBRTpgJfB9edixZNUnK2TCdLz5Qc7XQyG2CJACH LeNzMtHLHIzARSf3vjO3sXifDY+Mzm7azjB2rA1CNdIgfJINuPr0zOrS9JNIbb2K7gq4mdDfTPiR oSsRJKZP2rMd9gO30Yo2Awus6qe9KZMwTtke3cks5RXqo8m5TLn4lTmqplIj940ijdyZjYbm98j1 oWPeSOh5VETMvV4Z5qOWjzV1NBRfPv9hY/k6OObu7ymoAhPqTFujTVhX1sm1IFWG+E/uup7K0sVQ dVJjQTr26GL8/nZFatGv4y9INzVNi9iRct1T1RMHy9nt+RcM4QA6Jrq925zOMFJluJ64yFfm8pbo 4Zhz269qAxn1Ncm3H/R8Zzpq0n8fHcdxp8HnjlRt4KcIL1WqTS7FjlxHdbZ+IAPfr5HqBOMGfllO Xq4YxwbqKNYwvmdU0w8DYS8n9Nc/Fu3VyuSb674imzVx7X6+M2i6OLHAc3ptu+mO2DkkQrCQAVXj 4BRPTnRX+guIHbWIm2Cv1EJA26pZTQKE3T9Z0Hy+Wtfvxj9Iag+BVD8A9pg7DYork4aeBr+IBp4W u/HkT04B/Q4OQb2Lp82k/obLfEpbTWogCsUeOOhKDFzuDSna/G1nmPh9C/QG/pDI4CN4+hlI+CuR IS/5IC3x4QcAuQGltqMF35tng8SU08zgsxJiONdpU9sb+BAZsgGR8EDb75gcPkCuNgKc3ofC63rg ekRp30gFzYA1xKTThxARYSr4LXiZF6xpjmRABuTxi3ra195wvRd+D3R6So4ctqKWhDZ9JzibgKmV wd5imt2eWmfo0tr19X2aDcFHO8X26VMhGcB5t2qBYEGRTLLQTP3STFwRiRMp6YgGNEXVNsE2xygj uzwnexPF7fFFCqgFMaJ4Uu+YSwLySowyBqtweaRxk7vneXZuuLqD3LoVo9vrSoN79juGRtrJDypF 3DYf8qDJ7UcfVyUOO+aDu5cgiMkiT08pqm80hwdlWHfEBXhlpgyxyfaWuubjQWgFDSknFLd4EM6T wcwpRIbo16IblURwv6ATQpWjVMqT63ppxFmM1bh4uXmaSnNalFk8kQS14eIWGz61Z3wpg4TBUa39 xKtUeHUcUX7iU5hnKVRiEzpuLFlnaSrUInpiweZkKVFK8bWu0BzjI9TnS86DDtpNqecV4KRYxzbc E2hJke0tTupNUdmaF1hX9SO14SRkRPtkfPXNidFe9x3KbR496iDUCJbmCYyWw1Ld5Su/0fTS3ReN uZ+qAwAHFtO08Wu2Q/hiQkrzwS3DSY3WkLI1LP+coMSuynYNBLF8t1Uei/mIBhRwDH2XdewNt5+4 UTxJik9pyWSSaJ5EG82TAlEdkqZAovUpE83HXInNut/Bjo+mMEtBbjVAWksYrd0NlSJp4/kgolGs wCtknJzkXnw0ZcoExVv+1JBiSCm/zoMQ4Rvic/lgRKXGln4nSaq0xC/5KpRwb7cQ0UV7lc/NzFUg ZfiLTyoQDXkYyRuBiOGZ2gxQYu8DXhcZ1xh5xOC9gDUKIgI5z4NAwmymy4IUkbuW2hPe40pz05tc TZtdpnKqLhZEEPjqlb6T8e3Xm/Wq+iCHJi2+2lO1tlvE0Eh10yAaaD7fsLKYWpPkKG45OFq9hkxz 0EkV2iJ+lWJx3vB6bE4TRauZPKEd/ASqt6J1fF+9/szJlLAUXK+z80Qn4/YS3QTxf8sF+6fbJYmS lvqXuMz/OS6Y7P9Ty0n/ZXWX9H+K/nQSzJaJOcppkywoOHRQxoMt5x176hoXKkw30YYqfpyU3kQK FuGESmkwV+5CuoVmQ8pz0v/WeaJDyz+jJKLfQUpIl9fitWKOr4AQi6CrCWf5vv5ItGaTrKj2JTp7 F/HlEVPEjk7maZDN+VuQk0m26fXVMA8L5fgnF2db/ScIFokYyhJJfd+4stWYq+3fxONjQ93T+CG4 Q1xZ8hoLfptb9nFm4eXLU52zX6RTW02Xsk2A+YMXPZ1sjGQCD4iYpdwfMOzwpAUy7SmLiYhFy/nP K8AUGsrCD/u1C9q+d4u/IpyRUdFckvVKeAtk905eOTCribfRs4NS3Z3Pew4Ktr8rTdtc/HrbXM6z ObiBDzzQ8hcpgA5NX5HxqQf229zojIf/SRlPmVxZFDW1Z1PAPbWYWT0tlEA6iHhMqb9SEHiwyP9v 5/bIzsoASVgKt/CeF91iL0RX3qJ4DIdds1EbwEmW0QkSWIZyEDyICHQsyvVWD/9DpacCamulKIli u6YDC6ZhEImOgeZwmNNoFDKVvnu9FsqNnJWorfne21waSWQj0AzOWJ5/fxz6kgJUPw5haJvJlE0p +TJhIYesZtscECqLP0CleMKHETPSqER2MuU9jGB8aXwNV0IvU+JqaXuvmWy9MuarF+fXz8/dSAGW o6gURscuBUj9WHeGKBMmhj9h0z4RkTAx7D4uPrf3VIAiSvMpP5jLKZBlMw9syGBEYJtiqnFo8tDl PB22HR1ouu2nu/u+1/FwBUnXGzmqKe3J/LKknQgUCxBDFMdH+fKwuNStG3IdOFXWwJ3DxAyydhnU muusrMVs5WrGiEYaBAClnC9P8t+0xlDc93zRIcCdmxAM+VudnPTBo75MFxLX0Zd1r9ShEfyA/3IU w1t/NkZwle/9588iEh88Ex473XoG6Dl7BdLq906enMwI+OZv9/7zwpt39VT14wJpbQqKAWmtEwBS Occ6s0om61cyIZ+sglS9fOIXjtZnzNDJg4V+Qp0vAle/6njE2fX8bfvNk+fnD+8U6P3xxD5Ew+fz oaU585kj2xfhiM3rSZmU90x/KA0X2Ti56HDm3PpyexzjJSlbtfM4LSd4ipaY322PBcSXg7vNalzk QfS+ArPurPw0jMYTqtXx3OJorGDrNnlDdbPsEwYr9vsH9kekI3IaIrvskvl3kUX18kze+2xjhKAU DmKVryxH7K/AIfYvl5ssM7rtRoeNpnXj0nD5ASzch9FaeJan04G3mbssTGPuyohub7qP0BhLemHe PRte8Jo7UxP2pMdmu9CxZjkbe1Bg3qS1OQbOyYUkHXi0IZ7/hr5/KUFGwymjGUajrrmsbK77IBoQ RZOm7/FQW8OHkSa4fwwmfENnpC4p5yWiAEI5bysIYcvpM1fh9fAlBQ/IkEoFs9OvIyiIh2VwXOGs yiTR5g49d7KbZhtVIGBFfluWGzyIzBlu9SjNQVfdbc8IRDw0wyjKS80wiM+y1Fo7RuSj7ryT1Azb LHFdE47t5YTk7M/NfO8TpPIFlaKRyGVe5rL/BLOCdAY1xbMYIb8auVYFflFAAe3o3UmtDypVun/k BS1oP/OQTqIxg/FkGFMiKMTlM+EynPwjaLa2hQ7lBIKU9uvZznvgZnzGsIK26fhgy2/qbMm+ZPJ5 JoCcrW6ylFKOTlNtHLcna/zMCyDx9HsSkqym6IB2y+4IGZxn4fZEkx6Es1sQyJJmvJ+Ev1MrkdbA JGcwJtkntftOmUz7uQUAegdIOSxGEqHKQUxdBCRGCscii8HEcJtGqYu3ZuHLtACBYAE1pV6LM1VG b/aHFMT+dAVpBIoco/IYvppikaV1cPLIRJrf2nhGi2XRlgMKZL8wz/L9DAxwv2uHiJBgi1hjBdj7 wXZnl8kKiO0jgbqpmqh7QgKcqoY/dzrmlHmKtg2YxKzCOONbvMteige7235TuPQ9zGAITd/eIcPE M7HYJaXlzE/svFqUeLq6jdGileM0GyZitTPp0+ypuFBaXMDxmkIfGASKvn3imTaLOowwsYoINSbM MoXZ1o47pEAHVZrysCL+1ajJUKEif36iwM/jo3f1+boE4wz7Wcqa5IVwamFjYYFsvNtv+Hsmrura hIb1uIfrgS059KuWqljMXVJcRIZM2joYXozkWp9m5yAKDuyxRI5IW4+LMVieHe0IPp4d5tbpXkmM MvSDUlB34QJxRsrrnj55uaVAolx6i2l9iogOzpizfKqWigr0dZBIlee8PkkYcwNn+U0R457EKPu7 KFJgfLb3kE9feJQd847/s4qCHB+Xp/zEhjKbxfnUKrLKkyVEgrHqstQkYGNwpC4jcP0pXVSxGnmk 7IfYh7dpPrve9VyEQgS9RvEN4wcvv3/7XPoqP+n0Tf8S4zNnHuGz76ek829f4OMq7y02uf1+Lalq u5nv/vx+8vndm8XzGwaHGYFfqe89YwUfMibPvRTL3ih5YsNz29TmRXoG5VrB28CjoMV7KIzkqsuW ++n+4nOZhlWh+5t372zeeCtj+8fGKlnkOVN7HtiBHGRaAVZE8TPTPig0Y9pRcGr7KpJ5EWGoTY0l 46Vm3xrDGw306DKuSds1/jRNS/Q/1bqa6e3pOSajWza1f26kDfWs4/XUnWc5i5agIH6eB/y/2vsP sCa6bmEAnUlCEiBAQKSjoUonDRKKGKr0LgKiEiD0JgHE+tJBBKQLiEoXFJAiiIpKF+liQ0RFRcWO veudJOCrL37nnO+c//73P89zHffstddee+3VdplhZlLvphS0RTpPXGJciz54OmuPC7zMtEEmC4so Ll9foG5+qWxAu2Y1pump0KCjEN+c0/6aAPLpS6vQvdOHLg/Pw8hiR6wU9JWT3SQvPz5lRnT7cfc8 yu3MxWMoCf9J5/FiwW4xHMMnpez8ux7zik273jQPKCa/CWzcb2pV26bZ9m7qiOOeGfrJ/qtDzs2d 4hHSlidlOrTyLuhs4DvphYkSqbiSdRut+6XgvUx72nvKxiABYXMbbispsyymfb3t7ceV928hf2x7 mbbLWpkRK5K87+xLumI637Und6l9jUYuHvnzAlbZ9Ov1Cd9WFb7vTBhKkFJxW+UVZGNwRe0J130D Xq8ZjXEhquwzZKaXWrJibGckslEZlrIRhofRgRp+y3v8nt0byzsbfG5fNDbY1XAfrggLTcIo4QYF kLObaO4IrLXaXg276rnQMMu3T3duosUHIS8hPSWRpQ7I+VQE2lGpajbh3lOk9euYurcqoQ7oxsqX lfJ1FRY86Ml1j9S47nUOeA5gYjcRsT5Pn0zVz2z/hJv85OmZpuGD8/rzjlb71+e6SL/g8f/f3NH+ H3qTQfsPT3xp//FTatpa/3v+bjHe6+er4s5VYdh+xYOcY2MW0ZR3+450EoZhzHOi2GHv0Wk/R4/q 9Uq7RDapCzqEKm3M2OPzeopYVDkaij+g9KhFvGSTj64viTZResy0YjCb3J9bRu4OX5FKcS96lTiN X/3sfUv5TKnnzr3MIW9B/+kzLcXT6pfLb4/eSD64Qn8DIcP9UZhw1LOZCTWMN9f5q8n3qfo5Xylt O01QKsGHEMiq1CDZT8mPD9D2JMFnwl/jj+u13zjbCATm08LKv2MNXg7JflfuDPoulvzy2Kx4Z1ke PzJJQNj51Vl6pcT8anzCtCRK4PLDzz0gc77IOOyZflyyIyZEiDZMtjfQG71sJIyesJYS1jvuISuO xAuvlTIm3KvnXzMBBPCYbFGzE+7b4vUa2TfhNP7O+nWJOs+Q4BUt9QtjX20kuluEMxCpjT5XUYOO QLi4OTN9K34N8yhSPFmo0RBmfizSgaQusPOH2DguRNzEbL6jxcQq+xt5vznzqgIiRWbvwBszofSb ph0n1FfrWDlb6/44l9vbY17uXDK0/MxAB11bHbv3sZHt8oP835w1P/qL9Trv3LPMznsmQkye76C4 1dVrKijN6y75fDrXJp5d4r7SOovVt7gmxSDjl+c+d3cWdh6XdFt+q9YpqXvG0eDW3fKV29Zqe+zg Tz5pLL7F6LFT85ht/mmkxJRyvbTTSRAJvGspTPQcvM/UKxD2UaUxzFqeNLpLNAZIdmYml8FXJzVd tDRVqbpXPpuf7E8MLRmEqXRg0YEJHwl1qtKp71d35Xzbj7zeq/EZTx/iyWoUVVEa69VJc5YKqi3o ilvjf2VcqpoOhGDlLXD+Up2nIo9me1G0lb5t5nbZZeFq3j+cWfFMI7CvUkokskjjSrNcqVmNY6Mu Rs781kU5I9zgzzdGMpsSYf6HVO1ODB6Txpc1+nZNXDF9yv/2xdi6a4bHr2/Kff7FzrdbZkfyTfcr 1HKJA1t3hYX4rr0tVNsatevRxtloweOMU2XvjoeRt2+0q43Y/m3sRPLnM7vv5Wz/vn7P88+34+3e yB/Y3PVi16YLDq0hRVGCp+7u5hF/8Pwv6cDvkkfLkQ9cJTrJGpVFzZPIh+anTqDUHkpdLlEzbJeW jpfA3KrV1vOJFGtZhbGYsfKMSxwWo50UsY1v91eixeJPi5oJGoLuqiliRBgw4XC3nclfViBxGu3u AM8KiTCN544HHvPEgdbx/CGjef5e0sbZX5XojfoHtHUNJ2pnEuWJgs0xp7i7DL/yM9QHYShDwSGE GXT9c4WcdYsXe/drBL/lCtg9WQmZDm2lu5lKprjHvHB/L3LXFUqK6xbJe1SGjtkUohBOG73RVerP J1WfP3FessI+hj/21Nbc9QV8hhd3B45VJeRs07epQpRHV5s+vXi/RcXcMGkN36UZuQelGZ7yZQXE HKAeOd6qkFiBDOR3N7D3NXd7IrbfMePRoL3EkKIhTyGx7s0acdtde+/+tTPl8eXhx6F+4703glRk QzvFS3mrrYRpLZmhGsuLaTMSYkibsrraVSBqTweOEC6cSo2RsE3r9FWqQhOSXVW2PygRU7T3H++6 OD9zEUtah08vcKB2CvfUePGZ+ujCy48bZi7bzyTga4y9kv+CJ0akZsZd1MXelk5QK/GOjRVpjli/ xmontzzzvbnQ4y/wvVw49Ki/CEnRS7hHKRyBKRETnA/mr8nS3SA8nn3lhug6bsE32S9wUsPau22P im+o6CKTk/HjYsZKwQgQrYOcfynZNWPMdTWnxSV2kvcYI5SvC1iFmK9cDlOy5r5wQvX6TIFwV7gx 913yynUxQtvo5O9+WWl4xGvilgTz7VXh9ljEvVIHVXtbTNm4Xj5wzc3ObSiOtOIQNTZIxBtw5nuX LpsYnuAVDzjxxCFWIWjxwvEKqcdbv3dO4mvpRvkpTdoatjUW9t8HrDuCHNu7O45VqE1uuH5gXmhu DXfHh4a7fKdJfEYb99/XeWRz67RlclDWyQ8im8/alIg2P9J+iODNrnq69vqJTtGnb0iefFfOXv/4 CXtzZOuDvhcyJzu/iVWfu9ZwG35+mYvLGvGd2WEvliFEc7xub9uni3aI7QrKRW2m5KY8tBU//3KF 36Z0412vNi0vungjLt/Hw/BG+VlfzEBfMczWqytJpNkkAXd13h4NmzTClB0qOOFasRZ3wMpo1dkj bTNeU9yhkufeKNQJWdwhXcsQOoII32c/X7tvLl0h0ZfYMAvtvmVVFIzuau8fOOpnw3DSRI9H9fky V5gXp+qUx85I+it1Chr3UtRk2jNMjpo9knrrmy0oizMb0kYvd+cqyvbvS/CJtpYy9jwyO4e/IGk2 axypjwCnbyNTM4RIVfhkoovEWoaL4Zwjv+9AvMac1xwPrNJ8TdxJZx3T27eG9662Ewt+ds5FeF3R EwVFawM1bN35Zu0E7v3hcjg3i2/ZJyIF97SVkXImpLaO3lBZ/WVbqUmxafuJPS3I9lUbQysNXS7a E01yzA863lhm1ZpHnMwQ8H4o8lJFWPHUbuXJc8dofm1VK6ZDM7o1ZiVlx7WUbapkzsWn4B8dTcCk XH1A0UXSJsQThkyuJW3XW7vz2bFxQFuzcyYn/DW/TbqTfz/pgN/dNteXk8z1U/X+P56nnzCP/Hw2 u8PJPrSet+/iuCF/R6Eu7dvKZVGb6mc9Y5VPwbqlhtDezHnzpiuOh5yNlWIw8m8PX9lgKW3so5Xp YER5j94zqap6eIJBVjFrT5EsbyW7C9+xdcBuQW0PUL29W25zci3fyscWXioaW+ufSnhZGMWG3e+q JCz7dkvobaLtC/qQc4/9yAbjMEC5w68+xeD6k8E1fggQQURa+hTd0NkdpPAsISGRH024Sbpw41sw pSN5zG30OW8Ij8Tsw32Szbk2g60aDZUutRqvn7oHPU953mZ3etj8ouSOqxrBg5TelzMoE68g0yNC Us13eBN2yzHvGIyVm2SFhD4xnUoXXq2YypdhOftkcOIR7blsqurAID/QjfG8hsGNRjyE7VAp8BsG gtZ64ct5DgT7xGpegK/a/teFwb+8QuDjKn+tTZbPMu/L0oEZeRwMJ3dnuewOdz9g9Taae/fXrI3w F7Ed86Zc3H1cjwPp2B0obACichdsPrUoXaLz4gg63I/bWPab2rlDirb7Z22bnspqWKc/GemND+S3 fiKUoBiBf/Z+eOzZwL7XigyxH7HxGfMYJaPC5MblYJaUcunDupnJeto039z3NfGFmIG59O7y0dJZ vtjbGKVA6kCwcnwKYJR26xLw9qj1vJzunHfbdS+an2L0HdPSgZHvKvBoLZ6r/OGS4Nwz9KDlc41r qwZpszOGwllPEIAJBteNoNHq7mUm1fST7zuJ0LoxNJOaWqGMF7ZNI1cIKXzLfKzD++NEsCtFaH1i gCHfvbOiSu6UVC/q+Pt98z+whK3CDrvE+N0nlV7vk3Pk97yNAJ5pyRYoD1pJbklX8PQv0hTCNc1d n/+KaZJNb1oufdQdQRu8UjrJJ7tX5FJJxIvpJPPbfA0zagRXBGx3Ndw5vXNEIoCsZN6vFthwOGR+ YJS6L3b2/X3t6rTgNrhRnML8+JbCVZZZ1cAD0Wb+WaNqhe56vnpHAYCWzDN6zSZVOWPTPtm0+maj B9aHRmEXROU+Ce1DyQ9GXG7WTQd661VuyZsVgsemfnB3oXv1VO7fRWLj8/rQesTGzjrdLu4utfBA +Wca7jnjPen8JcP2Mo6XVNde11DZr9p8WWXoia+Ra8/aF/KomHMpBfKwr8U55zWdUJotmPzm7sA3 wg7zRfhncvicr10tgGOfMZG5UiMR6BD6hK/TLsy5HWS9kfRGlYekgT+SoHFZmRCsX0yy0bpY8i/e ztbW+vPb2dr/9x6/+vcuY/7wkSntP35kSvt/xUemCBL/rVv2YjOVrCezggm9yxWFjmmXW1GEhUer 5da5zuke9TFBOLUCcxatTgGzxhYlE5GKhbYwmLRXDOO4K2XHFL8t60ceW4sPuOR5UkaeVBPBgiOe Jg0v9rSBvvFCTsTXX4zRH4ejHkjz0RW69heYfdbtLnV+Ri5rDxSvz/Bkwlsfd6brqPJ1mijz3S+O fZ9qnDWBz+jC0p4i1fEeLcfHZU3mtdQ9JISN8ZPTokZZjdM47nJ0pcyee+E5omthQXWypWEqRuPH ZVLDBCv3eAaKEmvTqnWUA3Sh66W4Uo+hRLAxQmrwxT2l/BYrb57P+uqxNZST/C0n8sueGiksk6eX MhF9Xv5pcqmEzljltHh0iaxZN65alLs7plIFXe55EMfzFr/f8ELTZ5Sc5WBJq1zygLmPlIJ5ZEni II8XOsFauXKfrILlQSd7Sy2Jyo7qXK41bleUdXkVNZdr+QxWWukKuDhbxW4RvLZcj7D5Wn7gXQ2n aHUf8RQ0nr7Z4l0wf1ay/64oZ7flrobucW0dZ/w25K/LDnd5gzmR7DF4kCqKvKhwyVF+/0a/sE1R u56HbV4eEho/JDNyItk92iY+0XX/xjM+Gz9knGfQ0TYfkqbaVxft8TTkKgtwL4DZbdlA5buRmSgW 8iAIGd29cs+t9nc9edPbfC3CLek50okdaN2vnD9blKlJnfuMUvsi9KqXVDwtjGA9ktXewyw8YgmX LKfwnsirPSC/vq5V3tuwcn9WpUy1nYMlfeRsTJVj9+VDeGVV9EsfXT3X0x0Xe+4eU/2ca5RfRQdK 8enert2k9IZmFZFk4kzEJc17pDWy/k5iEeKPbjb7nH0jW+GJS4SncPdsAYEp/D4ZYFBfyXLSkD/K uHNC51hPhNal8A7qoKisnFHB7ZoDczRKehfw+E5M+LVyfMZBgbW3InuO+2MxHpb9T1/ltHiMWtO7 RRHVFiteC/N7x9exv4pN3Bp/flctxmArc+LdLv+B8p6EvzLLvm+ULdjSBTD5BAgPC4DJJ8ZoH0zm OS6p6M9vpISwO7sGjiPtH/JieeAR/Qfn4XL2l0peUSnJn3njgeotxszhxDJr3eXXfdcnSH6M6mon 5obPJBkXBmBM3mJRfoXSnk3WyqNna3XbN0lsbBnlN0w8nCd7yDGh0NvYzoWrNyX9ZelgOLEe8QpX RUwb3NK3B2s4veZRDNZLtU6JS4Wrf30ZUApNqmOPU/KOXOZbYdUTAzZSOvdvioorHrdJaqUUOnff ynajb3+srlh9//RHqUqZgBzQzXzWOjuuttzURq3ywKPxzwm57si0kBghY/5jEx5FnhfN4xJoofuF AtTNX6w+WLheUhTjrLzqddr6yu4Vu/MeCwTtlU7LCffHTOgfzXuc7DDYKDG5X1zdgvE2Hw+7i7tR Bg+xwqWI+hTffNDka8jvfzphzwX5ihPmuzzjVdeczBUrsxrJGJW5LQsEmjMqCwouxPMn5A3awkr9 o/13Pd3vtkuG17ltp33kiAF1RnJFMJN/H4aQjH/i1HPm5XaZxuNS8zQ7m7lgpeOCk6cnI1yVpZeX z5yqFy/nU45rkUIAFy9UbUsdqk6QkemtkVJ9XPc+decNsCW4NsF5tkPhGG3vm6zLpj2eQpgYxurj Zd/PAkkCltKrwq4UaOW5PXS8Be88Zhb7/tqqxE3KCuv571anrlWae7dxp54yfZzSXtGkdXs6SSt2 WMyi3Gvk2BPV3U0Nqtd4Gudts2OO5ifXXQs31KVXfMx0wFd19JbBNlq7HH1X+FhImMb3+C43V/VG wb4LsmPZPGdDzbKyJRK6Ay+63zg8U6qeuN6DaZy7LvA542kl8iT5AWGH2xspUSuzwRsPPPl8h/h9 4VEpAcVieP9mw8rytpIrsq3tJ23e3xbFS4Zl8HXKWD/AJ+hGGL/QEwhB8FeoJQ9bFjLD8MjYS0LM Dn7uuo0KPvHMA8j3V0em5v3s00tTdJ9FO3qcICVv/+x+8gxKxRebsxZ7Xyoh78rFG6s7xbC65rAV 0eaMbWWrtlVtrjDeY5MsReWuejr48IzRsjhSjtCp5UXwKQy86y0S5ZqUdWVqj1PkgRzTvqf331B5 wL3uW+rBDLKjT4HvFl/L4eX+2MHtaHmvEI8nbW+aaneIPqyN0W+hu7Tld7SZa8u27reIHzUxdtrT uVaJC/O28zTRXnrXvnRnm8slzceTbRMNMQoiSqZKUbr3mkXCUiy04HmZH5qS3uSojyxL8NMLlgot MKWLTOfNGIVaB9rz9RsByZ81a5Wyr+np6jSuLoj041P2tc1Qq05xPGm1oiMup2Y/MoB8Xt7apf1M 33O5yptrmc8JB/3qvl/V2ei9c4tW8+lrU1y3KkK2Ep08NOuqNLR9uzc2EFCnAK3iw1Wbqic8smVj crABe49OvDjjEBj9KKiA97SbJnJKPi3Us03kwnbK8ientARt7HZu3pn6ns/fLO/7Od6qEr7Md4GG yxUVdupHaxJ7dyTnDU29uaAYUrIK86YXi3iqlCqp1TdwdS57o8rXW/POObMeWTOwz4/58Ktj9BJ7 xSiup9MGbW8oWPt8f+ZxYihm2YY5JrpoPOpTwTXMipnVIgn7EXWF65+U69dqaL6zkOgT3/KgdzWp Asb9LfD0xVUbFP12vb19fkIUFTT97UxFi1Ze8eRFX/Mv28LgZlObRFEbNiFWnQ1f8eXOZ7sIawPR c5teCtpn8MqR0ZJdLWd37Aqh45CnN50/laK7bfzmiPXXu0/fha5L19pHuIy6nIq0VBQFzagG+fMa sENJj4cIGO/VBl6tZy6/2HVB+ak0Lfej0vn51Xc8H69OM/wav/LGpGYAeE5ZPmFf1K2IfTFngalD qvr9QR38Ba+rK17Uvzxvvy7sCnnlFq/doRcmHA9nu/FqJmRrEqtfjjSS1t9dnqSUFShLfutXNxnq +CE4Vt7I11QjZstT3/hY2nsBn0elXu+Ph77UnLQSiGH0GH2Y19AUsP4Ytv3jGDe86sXHvXnIsdtf 04KfDVe/6DP5Zr8OLpDnATd67E27L+fxbXjgqV3vx/nwLwKjrzQnX4Xv/jJ2+zWmX8XbqOpJzsRx 6t4xg1VA4va1ToCtveU45n6ou4ofmYxvz6H1vnvpdUFjO9Je6WSV4hf7UI3hLmToiw/PIz++TJTf V4Wwv/a6kfgp3P5T4z0ZzTKu0aton1yBRssPjYEf4Oc05jNQYXtRx7kFldeh7Dq/ERB+j3Oqn/ih nw3xacobBvKX8ItzYfyEzQp0jgTHD4M8Y1ZAg4veMfeb46eRXPoBvvXgfP97Tz/M0447+GAT+czi rOknmn8Jyn6Bzz9GjD8XHd4soNnDRUiVz/peNE4Xf8ULt7+y8dlxIbvxJ/jgja8yX/C/lKxykmjI hYfCJXsM+QMO8l9q9MmK/6rRLkO4JJ7k/ilho7Rg+We7q9JNokLhm4WaHokRYM+TraS2zDkb/Yu/ TPzyw5Ak8i947f9nnrXR/sOXlCh/fNaGQvxf9N5EM+e9CbCwPYD1mViSbms7+wcf5ZQ7DjnJSvFt IXFnDdBzDoyacpGSfCbo2mhuxSfbBm56NkmWa5PUb48Tzk+9EAveNe+XpOLRQqooqpzzEMYIwHln xtuVr8PNG/U9jgrhJN8yYi6uc2Fc03Hy+Xprv0nY5adXT7eGjlAl92bd+SyttknVW/tVqn5zjNIV D+1jWztWrtw3OpGcrOT09n2KEtXzleaY3AlkMr3Z+QAttFJo/py9hySqUcBH/umaxg3tj5LvHitp M/JXcUlaM3bsxddem9z7y2j4YyO8RzMT3R/1zSMcuErt9K2fIu8eQParXzRyFksGswLbm8vy8m4l wdq7dfh6zKczeDK8cyZxr7pDT1YZJsKmNSzcP8lqxNFe6CL44Yn3kPRjmbOntrxdK7kmq0T3zWre N6DI6YnZoNXn4lqefbVbdlX4maG/WpTJ6XFVGZ41lyplaIbYWcUfxvNCHqLI8Kl6sbVh5HUmijWr jXmcs3PsrPDC39ZL9b4Ll1zR5B8c21c2EK8gR+TeETFYGRFbit8nFzt+TeXJwG3S4DGe/tnysiC6 e+NlHjdFjeArzRStY3qjk6fed3gHX4yjzczW53xmwCctUu11dPCkvq3WMlle4jf3YCOkkK8Tb1Co QTMhOtNOR/1fnrXmcZZSGZoLz7GP9Q8S6bwLBEudeWvkXJy4PIQ6pFdWoJDmEO78aZfdaLK1qFdY BP9Hp8gQvuUPbugrp126ejTooKPrqKqrn06yg41DkceLr5q1wUpnr2B8nA5ckvCSdpAJWLfesutS Q/0RA93kkyt0sj/XSeJlwsM2ywbvoGcRs3ZfIpOMJGnjgzZv69Ws1i/n0tQuuHy1vYp+GEVODxjl piI/Gs0/CD7tGn5usmU05/mDfS71XuNuRzROjH9Zo5jt/3Z0ndGlr1MWpW+vtu256retIe+G/UCo jIvD58PGGTKfUjZkG009CZn6cKsv8Md6SW2yhMFY8N6TirlyKhLI5/1Pz9SUIV83Dj7f2KU+vT8M lu15/akochAuUdF3PO6C1AnbEy+3bYzW//plZGvtKr2Ja1cNRr9vPnZkzZOr93Rbn1Wt4BHbzfgM HPOb5Ysr4XFJ7cs+0ejjedODL75hgret0nwCt+yDfOwUf9f+D7DlJOfgeVPD8vURIwen5ROwu661 Upy4zZ3qknjO3jWiuj7Kl9I0C3+XYZyqBXN/axYxzr0iy9HoM1hDwYc0ZiJ8CnKEixRduVMTDHwk GtPHN6CrYrAIYmm0scQEX1eUrrbTsybDGh3zWeUe0fEIbwEL+TXD+pId3T6dcm937mN9EskkGY3J C5PPEXt5qluif5MhHFkp9VQcF77rmuAy2QfdRqaOBsWYiE/hj/M1zGBRCoMnfJXoefqKndvRMLQ1 d2ycqiB2VswKR89QrPLNnXkjSQtYF2KGl0ggGu3wcm8rtI73Go5u7PMhkLKXic2bX7Dgn2zCmLWQ vzXnh8gPBGgfyJUNW/l4P0HklEDqo2LmwJ7LfIq9lw4iVkTZ+Kk826M/c4B5LmqsqJV6ZPZiycQm X6GLDTvteXLXXH4Sa16pbOST4AMed05qaxd7c+0yGKpMk4WukT4nmIdn0OZmLzF8M6wJqQTHePWm FsXGCSoVRT4bhowvxhoV2hKIM0QrIHFZPB4XerdDL49piYZXaRuVjetW0WiSPWSGGkPIpVj2juqD VGuuXhMyMmff+oJSnHuvNDNbpbfQIvBreGzf4SrgiVSP+uqCVvnqpPAJSTjO2zLy7bMU/Izr01jc 8XXd9YlpqeLGLTca8mVdFC8GKXTlTfDk3PYYaq1ujy9VqXtoZHH8srqf+Z5iVaGPWBR+zlXpnTkf V/yR5JnJFYFYHCk5hoTM8XIGAVue5kF34fBn/jxutidFNNatM5kUMlLYwJMf2XxjLznEOsc/L5nr tGRfgXRQJw5jStZNgZ1zUJ6L5HuH1kYO7lFTyNIoRFyVGPB/TnrUt6xZfuoDdu/Mo5feuHNN03Pm HwNTqgVdzm+9jR1TQ/CHxeC035uWbRZv/4yX+uZ12Qntufd54nHG2+LYi9e6LQjwRm7enpjogb4p 0SS0PbnX30nAK1DBFCz/gt+z286xRVLkXto5ikviweWxww6WWG/Miewtjj7yNrXmZgRNqopQZHeH xbgpJvljzaYzj2Tvetd7nZzt96pe+ZfzgeXaQhWCjM9csUIrYENUJSnPoe/bGncrj2wreUMvEhWR faKZGXhTD9vemM4sWzXWfmH1nOQD/Jv3O8ontb54SXOnvLl8oVM8d+0c91Ax4VB+ZtFJ/Mwzh/LI eIWxmEOr7pX80Bdr2HJFwh2r6l/80nUvdn37eGZfZHcokTlbHVYkD88rXfgjiXu/5wMJOedgOuF0 0IEI87v7Wub26Z62sDCTkx8vNpVr/kvygKNbnpDulrzO8gE3VSWpB1cCT0R3zFYeKfYWaUo4X7RK YaL7UeZlc4+WR/IiL+53uV7r8z0t+Ln1wpX9+0DTIeWTIv3TsTQpoUK6kgK2Jnnq9gHVdyfawETs hvlJacuQe3cfiFy+rtd/61rI7kaR6orJsxOBgbc8PDRWBzb43vC9yEVs6b+zOTxTXDVmy5E20dCJ ovF+iZAabyv/oixR4m3v6xPfkFG15PihAUmhG3d6ksfi5CP7rC6r2MpLfJ9GPm2U1HQZ0p+ZySoc kFuNXhdc+lEnXUXXt0ZQDheDKlrRJVY94P3Mbf2XOw3i9W8ZH2a7FTtb7Ts8cus7hMvkzVHhVNcz 3XLCPpM3cVeeHVnx1dH5uoVJMuaCh+aJ+zfxM5d+XB2Q37/KL1cGKTCxY82xb62KgwoWYhM22fFa GRF+ORYEizerbbcX+5w7x911RftWcwUU4KZNCpiKAj2v5TxKIZb95UOfXqP0HKOyr7YYxYuN9VCq E1O+PtowNZImZrFmk3vX5R8f5V9e2vkXuL/7s+TXw0Eff+y78sPq47d6x+/7fH4Mow/MY1pevp94 PPn1uM/uNOz7J6JgmG9clmKZ9SaVXpjeHLFCQLHC0rMiTb+Sx0RLLXXLs3RvY5/bCcLyCml7jQM3 P60klnqNVJbetRI7Whuo4uWh0lmtKj+J9xa6BbxWepLTGmvCfd/5fkbqZy/ZL5ptGbZ1DQmD/EEN Z3DTKnDbjtrdHraBmpXjj2czcUcqjbmwd/lTW2On+J5at5YX88084d9rfST5/UncbTXccBvshGpa TI3J5H5eTzXZeK5Ok2NpHSePubc+SdRRJT7iK225qDjzCNsIK1A63q5Fe1Hd41w//4KnNJWHpw2t KkYer94fO+emGhw6/3E/QqWdF3avc1JNdqfyMayS/RwCnmOWAjw96oAIxX4pfyMaL+w+3ruxJ9Ar TIV4gZ9kS7237wTfJSJ/6MSXEX7F8VCD0bbx4S+San6Se2V9BDuehoiM3G/rJfR/t5EYkRMmqvl2 hegyn6+TVlNYseWWZLjUuHVDFSMyqjRwOOGbZDlPj+D79UT0JSE+qdrGYV/6yj1nV76WcMq+hAvB aAvewF2auZTKtcIvz4AoIxeyBjfCJ5dhf072z7t8yt/PH1Eov3xXSvs//64U5f/SLp/yh6eMKH98 yoii9b/i9rzk/+T2fKiO1E0FY2mz6mnOS9FN41HOA6nc/Z9fFb7GHbtmrdUEHoozbrg+0v2shPVS dOArQeXUHrej+e8qW7YYCp05pSJtXT6CaD/krYvWlUO3z0TtkOaTrerKGgiRe8+0jG/YnRcqXl1e 7nk1BQ9vK0H35DTeTDTKuq1TI4BL1OHTEDPBorJKVB50jcf+ehfeJN5/57c1GRvIbfjj3toqevGl t2+eakhzSannr/SSQGZEItr693Sy33U2X3jXORubqpzUHX5ImSdeqXAVurz0uOqeiErHh0Ol/l6S yam6QpIomXYPSRmZrPB8mYucG/o8tZrK5S7DNk7Ny/SVU2X5RKtzmcaGDnnybxNwLc+FO4i1QmO0 S5eJWFEZsvUPMwWnjjc2KOV8vTUO9MLwBKTwWVMjzo+4v30nan/1ivRa12tR9Q40lahOQ+uxLTsn k13JmEeUygIF/hzXd1wEh8m2WOYKe+3lJaKO2hmqLpdaxbxtRqLPtjAUDFsPbPGI46qgb1jPsNLZ eK3dcN26/JGUjdcMowK23xC9uj9qc1TSl79ufVi9Kff6/tcrE29QXSXiwLIcaduNl434z8vF4wPH yTVWyDR5w9iIsSblNMNc2l0aTT3VWGmUnNEFJB+xEzDO0xhOlTSSqHRJvGErH1cYULr5MSYuvvJj KZO+0cJJMxPPBzfpJpeV055pSNzc7NhyL2a2yighgkxJv9HcqN3ujXsk1Zr3cUN7irrQdznS201r V3RuC5oTQzaEPpTSuLLp4ZmA4Pv64/KqL9aKJY+WIPNT+A+0n0HAdgfi2ytsd5AMrvC+dLxz9wg2 ZxNZQ6nd+Uz9tJjM/uaJCQV6henFcyPL2vWU0GnJ2g8zLTtf8ycYS2H5vWm3dTMScDSK8k3PSW3K faGChkR48Iq3dTybC3T5vatvFsvZ3Nx+p13P6+TYu7itGy/dvX5eziBK2WDfx3NvbKvzHVWnfC6L HTCIVLCWKF3XHjlQTEBpTD6DK/S/2NMzSfX9enzZm0LXzkAGWQ2BpTmKeeAey7g8tTE6H/Wdz7CH lhj2blsnUglzgxiWUHqDAk/0NZnesJ0c8kpWuv/7jGenupN/h0hRFHUgs0zae6YvK8el0XxvPCmC 8TxeYr5N0FaOwm89e1wEuQ2Juyzij4/6kuA4f2lvS0OAVb1RTml4sdjX0ExEP+VEVLJZbKDhXzNX 3ss1Cx/wFg93HG+PS3C+DIJx0cS68L0FzUSzqTrdPa8VJrUGPj7Y00nVw8XiEnElgqmpYXyhb6vz 5qsljKmhGJnG8rZxmuDGu4ZKZWdvo3CTYsaxOP67VffigRkxY7EgzCrxk/0wZPWVVK0s87MxRmuf K1ZbD0VhlDcauW4gpnppmiu3nztvLylTfVH+gMBEII278/AqqeGSo74+oonxtU7xE15ObWvGuN5R Kq680OLuSBxpv0A5oj91mNnv26QCs1i18+shJxe/+u5XK/lz0rOs4qzHY/RW0mHd5ZFEIMviM98e jK93ah+puNpdEK7ExPjbU03Hp31Ku/P/CnjVR0muX3awQrHInlxATEyzdTvWpxwRbRfPvc0hTSnc 8O4wOVl2OxpeGobgUiKRjAokE5QpR4npFGE3S7SCfm2+Z/x6K1isNH/A8tCAaqx4D+8ymcvtceM0 YZKF5U3lcBym8m29AeCBhpkz4h8MP6JQpzenz5nJvCIatr9vEZJ8fLw2rkQJCV0ZWXwyUp55N2sZ Wy29rK+Q1BZJuibuLAkr3cbPpSY6RUuVDj6rYZo4k7phQ0jI85Bc7nfoI1PXSz/dOKW3qvXhtcTG QXHjWEM/21eS6wYnmJeuhuwhT1nomRfJ3rAoUozwFOZam6FZjeimXhWrEhaP+cwvhtt+AWg0UKl7 U1RVeTJMTGf9lw7Hnnie2t6PWGTnZctALcOY6watF55MXzM8m8Wwn5CX7hzBC1j17RDtLxPufCKt HmfV7Wr2ssUKugbCRfmZxmK10wbePBkuO5aEP+K1Y1XA8xIe5Oh0Yecz36Hg+v0tCnzPkiXHpe2T FQqaoeuaUzu2GyvF8Gkmvd7EnYAfdLOo+3DoCzJ9v8ahDSP9qz4/NtW228o9R9921axZp3FKrIoW tY0hKiCs91p883KNwVObviZ/eS+5fvqkkqkoESkXI6GucCT/eANmZcvnccMco2byV+KQxLc4jXT0 +JPW7RtzfDDk+jXnXuIoycMaEcfX7eCbvf1DH9XlrPF1WR/i9sX7BwglhIfql1oPr/dufBAnugK5 dsS3faY9MoMhSBvLt5i/4X05+wS8hAgOfiB53Fln3PcXWu0KdOnUbn/U1Cc/36JN+GiZc2Pd+YuP JNVz5DbY8RmrH02f2BQIzL7BA8wLNyh8s0/7Yon5D2+1A4QSvd2vV4oM73d8Q9P3mDuknZSgtic/ MKvCbs0j9ytuX3UcR27LljlNZSNL9M/Vv3tbvV6q+HBHRECTBLX9+mG5e/XL1w3oAl0Df0k+iNRg MvmVe3XIwN3TihKvHYXc9nDHzPKePES2lOfXFdBaf+QozTh034TzkHDXqmMpbx/5ybuf1cG/Lbxe 2CMlmZ6Eb8y7SJP9HHh7+5CbemypbLJFjFPJD70s3u/xl0aJm3RVftwfSjJ6LUK47XJBZ27nkWrF B9/P6USOHvh6s5Np2rb3YnGoK3d/6sfXFtFzWzPvWbwZVl7xdDQvJcbx6NqzIy++ljh9yF29aV10 hEaNsf4HUfmvZU7bf5DuiaI0H+82/VGnLjdxeN/Bd5ueznxek3KvsEJEZk+vRHf1swteHjZhwfm5 rQOFWZn3NX3VRor7atpH7/h4ada56WLfp0+ouaEyMrSNBiLvWa0+vl6uP578vsCSb/J7gTzGrSBx 1feaPTT+IBeM58TR+s9t5niNWrIHClm9t1phSMwD+f5p2u6UR1ygBbKx72vokFBTWCXZZ3eXsUgV bg7tOd48FMYli2uJNUH5aLSWmvCGb0IAJryNvgjaB+TMF+RMFHLGDTmzlut5eON9KmN8HXreGUHb hpzZhZzZjrDByavLcwHRFGvHU/WJdbEDytb9k3vsr9V7Ks9MDWBkMcpmVxGvt69q7O2s5gHiudYa ZPXBjhy/smn2a3bA/Dc4rcj+yV/x801pVK+sWRVGv8agSXR4DQL+MSTl6I7+iauWL2qGEHXYae7G e996aAamhWS0Y+yLj7vH33owJor9Pje+KP/W+DC1T04Qe5R7vGFS5QyvffvNJ28v9RRrwPFNgAOG l7wDP3AUO9xjdV5IzRrdeIufO/3AKzxZwfJxL2AzPv/K3LopRGhu/KsPkiD8Kp/fX2rX2GFBgohO jad5/BUuzM4ralaCM9OUV7Lnn/wQ64xHZ2vy+97TLB/2Fyw/tMV4RZOFwCtr5y3VPtzkgw5Wkgpr sQ54FJcV9p48WGqPxp/kRQZxY7NaYtu5AFNZYMDotTJ63hONM+GNdWT+ix9op2j9ssX/5WtIFNL/ pS3+b4/j/JufRqL84dkcyh+fzaFQ/ze9YhDGesWg0aFXV5gilunj+DErXlcLu/iKgVhXA0kmdUxB sCSN18d9PjbFXsclWJv4/N64aVy6mbGHWGwoJXnWBE4oHcUSe/cm59jwUSVh8XxhLfT2CSNqt8kr b3DgwiqVLKbip5wb6EE/8oGWKb7lqbeqWhKigFsuzWsbxDMeRoVUt6ifupVKad4NXBNYd51hepO7 w1Z330lMhGM2UU12Nr95WI74TafbHNqsa0wNVNUcg3c0dygdfX8NheflyTw14hia20mPDxKgPUMz BEiypePVtfc9JymZLwbJ9UaBng941QKp1fJo1hd3MJaB8boIeOntT7r3zR+Wq8ihaVSMnNg1fPqT 4EBdPhAhjUbZ4CU+JJUV+uSXY9SQWasfx/uII5mBc8JGcjXT5Ey5owdWZTo00igYFbQr1vZy71ss f6DSBD4j9+MT7YHmvbp6ShUHzq515FEyXGWR2XuoPL1CtgQa+2pHydb2414JbVbhhlrJAvrT+aZR eY9ULCc6B0UVX+3C6tpVRGjRlMhTmbqXtIRPatQk9GaVqRrLh2yS1Xq3zOBSXp+cCZ8wQ1J2vMDc kDFsVLpufRO906s/LYvqI7YxtDiSoCeHntW/UhFVEVBZfnB58J4ru2Qrkq9meImUDuwQ3KFcz3fc 0tlyeznVrqK5s/rG8knDvzYI+9+KczJMGmL2ljUyo01l+u22cQk/lCq/t3y2V+Ksg9DDk7MNu12V J/mH+6hap86OZ5u82L6ev2/P1RRa+lH9wzvUtJf3k4dybHalYSrwE/oBZUCakpEcr67yMxAprkh/ h95I0I/acCUJeREmNY3cmub81cDTP1DilgzyXr71xZzA3qupLq9ncLW8t++GY998lSNgHE2jTdIT NKObs2xdR1rqPs6Op4dInm/TUt/gLpGibB/+Xrv+zMxtM3SphxS1bu26qeqNpf69ckqT/l0U8Kjr t7KNX668adYvKbxjcPx0/V28U25euxx6grqPgP+gkm2KqRQ+qFnRSdP/ehAncfT8bv6nNyoPnK7/ sC1gzaWu5PMbsorWrEx+c6eajnqy5aJcv7/i3DFK7jNji5Yfu/bd/dC59t7tVLrzX2M33nc+evts 84GuGM9B5PlCqe9DT98mhEcL0T58Qmb4SMl4Prjf5TL/zFNfKMa+WqiLuQvjaS0Xl/UCa7D/6/zY /fltikRUT7wF5ra8Xmr48skSIHRdXNlxhVDqhVJa6Gh6ly46g0w4Mj4zl8t9Vxs41XnMOIceT5TZ YTvQj/OK5N1M0Iq3/ZpQtOou3x79CMVL46Jr/dVRt9IjwrfMXzSj7lkhIDeXBjzU7Z6zvL1uQ2d2 BPlGQuKYzCyCssvvnJH53DaM/M2+7Oz3duap7wBbtb/W8J4l0965bPZKrE2YqJujBtDuHVJrTmxu vEGNQC0bcBOI6zv1tBSxdrlhAtlGvld4eexwjeg4I11hFtlPHULkR+B2kKQj+2ccpAS47+fNqt3r OWVdNCv1IGti9eTgBz8dBbUi+dcm78a4VRUe+RTvXzalN6Z8tOj+zXdxYd2brLx3UW/daFv95r3o +HYQ8F/Om+9ATDF+skyc9xNfrrD2toHa+JDDZxEFzaf3OWxXUJurks5x3p1utzVfFudcUuqcjLJ3 3asUwFh1WP5QYYe77AalEoEty3iUDFo+ETA6e8KqqQ9KrqVHGg6pIVDrFA8e0Z+TFpwpzmi9vCLc 32bl4+dVlYkfh2YknniGk5IyT1eaFbXFVpBdben3TivKPnuS1sywflH3vT9FzrG74uYm/o3Cp2qa fdPvlR99FDlh4D0YZGdRJ2M2flPm+mb7VPH31a315PZPGU6q2UUo5dS29RN6yy8JZmqW3hgqyjLc mNFjtObduc7hhMtONyrUuPvSsQjsqP86nk2sX15IMdm2LsHrPZ+6P2E6kqAFBr46rcgzZFN8KzDk qALxstog9u2Eb8gNE5TVOlul/UZVl/r69RSkKCJ49wINWDlmq4LB9FBJjqO7h3KV9f7lvkqSEw7u fGmvRIUnTjx6Rvcxj8sXT4lyPHbVo37dQN4X509D9Jt6Qghec51krayq+vtezmt9qCjnrJwDJEn0 wwGlnGZze2NVBzlXf3wK7/e+RsmH0S+eT59Jj3654sQqBLrBtPvyMrNai/Mtmnoy587omq4oe739 2ugzIaao5N6D5QoBaa1rJ+4mDsdSkVH64g8VXV3gpVH8FrdqFeQM7HtURq36OhTlZ+Y+lY4aUyLP lfZcR1qlrpY8EnZwxq8enu0pLRWPxeX4Yz5ZyqoJKk7pGVq82XXIwe2JQkvxXwFpXdVzvhYD7oxT 3R0Z1uSCjMvvLxj08DllvdtUcsl9u1DvWbkKreTWiyJegfmMa28jtitoXEtWNx04K7ZM+NrVxKmn ZrWZe+jet1ySblTmtrRuOyjYoOijeztlXaU0rDnd/rk9Vn1i3+58CaLZns/3kbJ/xcxrPO6quYm6 Jcq72UGJkpSvL/XyDL+EQ86AK8ajYgaxydl2SIjvpPQxEcCQaTsxw3c37R3yaXzzVJMNWm9HhPjr U6nVRf7Gjs2kB+bX9kR7F+qi+nseviuWhlmEyXcMp+bZT53dKEp4SJenhDeILftYStdTSdleKDGZ 8qIjiLCz8hRx1DiP95bcsNjpJ6/LfS+21RiaeVxuiLrdnmHs6XOq7KJD1IuR/vcfcXx3i1qizolI w8X87bqcDjATNW6kvZEb+ub+zP3FyJ2vqLh5j4kzYpiO8YYJ1ZMrVHpeZG4s2aJrxf9tqP1V/vyN HjSTn95BqGlOFZd0u3vaQCwpSkq+uAS17nHbynrkcLtnvaYTkru45hjRxWrXUea8oTllRgB1581R u+cbm8JkNDYJGSuMkV9/T5nFexoHPSyLe5Ox9Rs6aE2lYPvnhuFjtmfV1zJSRj9PDcmPma97//Qh 4/DKXWed9l1693bd6q+bma93rTlwtxzDT6xuEqQU9c8POH+2+/r9njGg7l5+BAUInL4egD04dlpe 8/UagfdpgeZf8cLfa3GJ8ysOHb9y6VnOd7v5Gqw8MuwjBY05gtUELEKrGp2Ae7b/4uFwyt+PlZB/ /SEDivb/td3ov7cB/cMzJlT8nzagVML/grvPW3zZv0BcQmZ9kjO0WUf9qN7KM70+r4uE21YKFvKo VAdKA/0MaY/ghBjP0Zcq4hbqsui5Xhqh82KVUK3YuF9wPsZsKkBt2t5JtzBjnXfpkxrTm9hnwnJd 4zRrcsmH/twoo0rqRVME7FLBEQGhwnTkstUmdV6UyzeTEJYvaLT1xCKuom861oPhWOZ2B3rjE3dd scxtEQb75WtUPg0ke+8rkPUqWJMRGC7Hb9kTLMiT1umuxJOa2q2fkRZugkUlVK5EZxoB00eUjD2n iZkJp0u0MukRDdopYy3z3br+zKNiydnMEzKpIc27Sekq7bF3MSqT3TqYbDVtHePGr8aCvU16ObKl /iqVHYp7Nmgk1L0upekoB+iXDA+CHZWFRwMcj6gpp8pi4oeavyhlW7ZINSP7wU6PxOqcN4Z4mxrr gdx+cJCha0k68z4BuWz4OIVzL/lN3XmC/eVJSZNLkSFw5WFiq4J6ZVxjRLKTSmF4vlak/pAtQvj1 SnO75eQTCVb56za4ODF1X7rZRKpvsLAlHXSyG7zKMBN1br0nuNllHSOAMtbybXfKOJOx1cTBMErc b5LYmuI1lVd/2O2yy/O6lBvaw7eIpTR/hklS10go6z75Z9Yj3AYTMmpCStkGauM1hVoauYeu83ph B0ntcUCy9tr75sPk9MAn5yi8ze7IcWTtcj072wCcn9h08Gf+HMf15kExR0Pc14nLrq9YrXfHgTH9 aIY71zDuCKx0vCojk3cnJX3SKZp4sgzIxSXCC8cpmRWeA9B+3qNRl78ib82RdOMBmm5mqCxZ+/HR 1zFVqXISHY0q+6iT+plhYkNSGSCsoTRdQ7EDi9ErSL59Sqlmg5hC6ParRWtOfvYSN8Bj7Um0Cn+a rh8duf0u16hVcYJpV5C6zh2NeL0dSEq3ZVe9FMnxYXV5NVr2WIyLmA59Mlm+0euYmKSiregmLefK 6AKD07duYANybB7bb4nZdJuSVfjxVXpDBlhW+fXMJVLexsdWQ/fXBfjUrLBT9ZkjrdtW/tSdmHH8 2Rej3BP734N920PN/dasC3r6Ovtr2JuDX99Z9AxLJbRglekYstz46A04zscKHC6vuHZIGDvD9Boz 1VGMDfxwVWXQQznfu8sfb4GbeCT/0rwIhtboWKc6uTVIndgcIbZfRrc3kbdotVK8SO7ddPHktNM8 sDm13dfyZJIbI3jOmsc2lAvrJ2aL66jWOG+Woa9KGr8nV+NfXnm3A592LF7QeHL3u3x3lx2Bjy1M qa1iy4O9U30ORiZECL3NfdOlrpixW3f/7eh4HIOfnjGJQo5Kpu9ts/F16zl+76tg0Y6nmZlJdw/a +/iuf9XgZ0bGSonkuPBsYGJGtuyJh+eYL3trv3ugKffUtcCowaKpECBWr6UlTRq+YwM/Q42YvB9n 3wX/EatoAKP5C8IqLpkqX1A4f1g0+s71vV/DfbMkuyI38ftumdpvz7MpeY4fDfNfyy2DFRUUlQ3j e+NgJH+rVKx7j8LFLzGYnGdVBWjFo2DtdZ8tEVrV/lv0K4MtXBo/PbGLN29wTht2nVWMqXr8hv8a 6XJp7kesulg28l7OVfe3ItvGqvpM5hgizk86c7DxTw5e9V7p3nfLe5XSbX6lz4Uy5DQjM3d547nX +yyvNOcofrwp2dUi7otpfXv5pDnduqxmi5laf/L9lTirbASx1kZDvEX380GpSPvSCT1qhNkTmy2N 2tCecblTcDA8Tl9AfbpRu20eDY+XQvCVdYzobAN9GxlovCJX16rgO5lBcbtHC5yKl3ls5RFs00el vrbKHd1um70SBcxJwOWmjYxm9yEvjIvJHnlhNPzmczhuavj8uH0cliBoaE5AycBKkrCt1cYy1FVJ uBpBI09bi7hN1xIbq3njxey4a6purtz6oryo7MchtRlhXG4w57cOZhd/6wAtYy67YYdbUH1SM0/B uPKGoC2hR3ZJydBmEoyrjFc7RvjLiBb8lTW4UnTd81VncydWqI0zdpbl83VkI1OVdTfHvDwose6x voS0lnvbbQXJztjOrAR35xPzjh6d7RRU346JjfNF0Zqip2OrN9wzaiR2OxcqGNjrGyZpVnG7Tfqh Nldxp/in3e5sX4Mw7lMa2OK7/Hz7raD7JU42qRJPY7imxRNi7vmbHzi86anFLgnTz3snl6V51kkn NrZJ9Eym/xXdqjBNSNma7Tp43ftTYkqOuMQHrz5S8pMnOlc+73KOq6HuuvCdYiF0W5R3b3ZQbmvp tZkhLc/VzEIs0TLPWTssnWnNb5gMTzb7HPF0eHD329lnp71c+IWt0pBu94IR4ckOG8DuQC41fLLs 9vsP9qzn51LTG/K9f/gEV0RDLtIlcMZQnXHKLowYrI28eLX0oaAdn034HUrxRDZ558BxsxARCW9j 5a4TiXqG7brJ18qdJq1Phhomu11ri18OE7Pf8lmNglqdKS11rC1ilpxyCtoSST1LieTfU3i95/sT Ym5dwCe3SUaKbx/u0CbN/bfWmF/ffcbqnG/v3ucPO/Ievr7tNLrzpenjQ/uTT5Rvk8+wf5VLjBfy dZzXvr1K+fUr3R2yh0OM9Cw+ip9fNbfBNl4NyVMwQtr5jAeGjsLk3DjxwqvrZFRQVhj/ydITjU/C WoNsvZRB4zfPBx27Z5T4Z07qG1J1N3bl5x535dGMyjzx8fOs1erVuwvh+1sw9575yh/0eeT9cYPI js0+z8czZV95PRUL07d8Ue135oOBMveOe70yG4uX3z9391aHqMfzTXId3vxn+vZnvJTRDyV+3Cbz F8/hvAHEsn0JSJKcd7Ga7tejY2sLP6z0/mZOjNIwOh98Szbbq+JotefjdckRo5flC/gj6GeRj7Wv bzD2z6+Kqnzre7BmyoJGjTg70Hn68uV3a40RUo8Ofj2bM0POUUN23rzx+K/2e22XBQsYIi4Xaa8v gwgu/qlGcvJogWPxX3fDgr8eycPNStoq/pgLWfMOuUHN1+JedrdrS4XHdHddtFz3tYa8tS9nHh8/ VBAyMZRY3GGxAtdn8LLPAVY19aoO1+lzCW6vUYrVtcXYILDUtKfP7j9eCQ/2eMP95EL8SsToNyT8 Mle4xtMk+3x0tOvTmd7xyJf4bVxPf6Ae8KE1qBbHFWV660bK9Y/yPanhjY+s8KhJbKzpwekoI2v3 YEh7BLl7TG5Uwh42mIQfbdaW8w0ePE0RqH5kG+MP0HgQEXwhYvtsciZWIR7yfN5iBegNIfW93jb2 jK820kCpijX1CSN4ZZ+n8zQf227KmJcJkJIPSj0BTNFmKvke+/L19KPXeq6tVERlU/nkt3Nd0lyG i+Wr3B3qOWHS3XgyLedkr6tt7SHFFOH2ThqCZhub4kl1MKGWZtKOX+P3tFv2KtLvEtRqN9+reDQs 2QstpiboairwfVet9ZoXJltM/LUvqOEuoiNrC7zXVr5N8DjFm3dqb8lp3srTe+taj21qU/VtOxZ6 Elc8I3/NuWpmk9ULRjj1sE97Phbv0mOwCUPhGnqKmkA8zXLCKeqfD5PvH0/BPcHaPLDXQ1uuSzGK GdgmGwGieHu7X30/HP8KhzXlwtjIpq+UfbCzsmqX3AR2j89jHI/Uq/EA+YEJXUfH8geSchGyScd+ KOREy/+L+9TUn09uE6kE6i9XBv/vPIpCxf/hYoD0x4sB8v+mu9FM1t3oFnP7yQitoqv13Qs/3Ys3 tTBQfK6p4lHlDSYazSmpZ6VXMy1++YkzzybJvSf3GoogCeKe8l5g+3BYHBbTXwiWqBiRc6Rqm2Ow 5CDU0ecEp5iSSO8UcZvZ10XQLirrIiZZelvHrL2hTsnoCUFw/JINaRJzhMk9S/PHX5ot7gztZKrO TT//Zl06dKhQ0Sbh64sjlrhZ7ZZ6o/6KFDslL9FkGR8p0WT7rDlxIxDoPq7f2Onzmet4yzxWM8De a2jNFryn+PlnaT7iSAcf9MsOTYkDcEN4pHCzEd3p9sdEuOX2w8eO4gaw/HB0v1a6HHWw4lxGmsCy BozkRykUpqW5jzg636PZYz/TRxgm6m9B1OE9dEUvjMUPtlQJ5bgkmRBLHIQIxN4N6imCQWdlVg3C kuQshJyLVindl15OTIQrSIkapNZZ6ZzK7TaR0BhKh0k6Ke3tmNe3kz1Rll7ROddz4Qn1MerU/PQI RufZs3hdo3Xhhg41+Xja3Mj4gYoNRvOV8WN8clUyVJ7sNzW9yLoNzZNNofM1b649mby5HmVXsUPI 5C5T5GRF/dvXjxUwVrmARuh8ctN1udLtYvu80E+IrmXP16MFwio82xwbvj3y2ueVxKd48f7cF6zJ i4xVKvhQZlnEmrhU3x4aaMTawedcDB4VmTZKvvkMl7FFtz1pxG/V+o0WThs/ZPzYuulD0tv4wZqc qDiLGNzD1UP30W6EdFdtvkTkpFOrJb2cdGjSZ/jgARsFh+TDdqtciovrVQv6WnU3nOLr7pkO0Bqy eiBq6xTtfDJ83f5NRYmE1odb76P+CmnnR5n4M5PXVJhcPiddHeyaucrGq0eDkMEfc+818v7Uc9Xj TeKa8Nz5onU3C25vCHnuupmU9KG4/q7ZFuOL928JE5Lywi+WcRWaBey7ef2l+omUsoIb2ydXt90f 9/1y3uryO3J0UnlYsVnI+dP6hw42V0cn+h1zPz14tk9dKtTwwuwOlHx/cMCKIfH323yvqSZ1jG1B vZCa9z22xuL6sG7ojdFXCS8NU0Nz6Dve56d8MkyW7xNkJoU/C6mvv9Aw4SYz9NexQ8A5kSsr7si9 3DRWNtreJv9F9GmFn/UrzZa3/bwr4EfDNNSx5yPNw6w2TAaEKbxY2RnKcI9TReG7jsJiGySMPX3I dy/KleAeSmHdbNwfteOTOx9KdgFeymVXdJKdM50GU8P0+5bP1Ud0OIxhvfnQ/hVJ+CdiCaURFlbi SgmAj3FuKSn9Mf2ZmJ8crCyASTTrFINH+op0q0iRkakTEj7RgZfjGgyq+6wOZAV6gk0uFNpwovSy 3eG24sIbxqZ7hEq3KHDn7ad4xqZnN/rvGk1TU3CoSUrIDQ2+9niIakpFljhl8mZaqmXHPhQRJGp4 yD+Wkht79ULDtzR9rJ28Ye2tUyTvj3x8dQSTN4oSnTM0YT5xe9eyqlWHLRDrDLdoUeRFXJfJ5Vhm Wh+Tf+MVYlYuYbEK/qyAy30LcMPA+uH0o7zmQ5G2p3TkbXX4FC8Xh44WndVb1YVRye3fPRbwTc9P vkwvaPv2kU/PjcDeG2Vrp6Xsb1yl+qS/LI8kbhtwF6D5XZJHRmqkjX220fMbgVdGOu513E4y8VPN zsv97DzO7Wbpd4u4hjRVPLbNdYvhKRfFxGSTkgunv1V91ULv0ScU42eKjZlXwNLp5Mu6yAn6BhsC re+h9NH29G7LI3wKUrrJM/12I0I9+sfs72rFn17/JBan5hmrd5jLTrgLiE4tu7rqOm7EfdA/vFgx vXHEeaYyLi3asVpRQvbhMA//8niLJ3ze7acQNv5iRN3L3X85fHLz5W4tzhMuHhPaQdCuF54/ml4w cdityb7ull7ZFS8X1yLDYHXJp+mPNK4lOLvyFtyqbXPedEBox07zUL6mE3kG5lMw85IKn++U9cDc 6M1lJoHCx0+Tph4PWjqEveCbak+eTbj1WM5eRVgpI+n0RsGPrpHD5lpHM7F1SK80+wQxxlGXhmPL Aps0McFJXmXL2/K562gvIs7kv227NsUsL9mjcOzkfuLU1FfhCI2NJ+TfT07T4RH86rfun/mAS6I/ 1UtSJ/udoFgfsHuYmb8qlNuMSPx0b6eW86t1Y8iY8Tb7YIdMpZwzF5g+SXQ1U/nQM01m8itFxoI3 GTW0ifRvW4aZ3rAx5LWIfs/H5P1OO7r2bGGoX3z7+T7ja0s+oc2l/QMcz6i7XKQQANcmjq61skyn b7oS3qn58YVGwipv21dFpMDB1cUky4AnibHN/eeMLPdoqikLnhlJXmnux+0RwdOklp1X8F7w5vQp qfI5Mx9yVoJwRe4q48nMUdim2qOyfJqv9iN457Lur286cucxOVZw1IfGdWVq+bghf3YiORn3xIFH t62WPlqdXHzIedlO+WNzyZfuvDaMLQu9rr09TSKp5wSfc9r01HEpuYAc47b7e2RNZka6Qx5n7eIr qA0g6jGL4BLVNZUklNKY26m5UaON9/+6XU/udfb4mk4l7N8ugm5yNb7l2oWw3tNHrZGpOjr4VPCQ CnRdl2Ke7ZkQE63sfysQMb5vo4jaBlKTYdB1bLdYwu4LdxrUbl8SwrxUpFIyb3xmvGnREFt3ypQ/ LnG0nD+Q99Rpmeycq1ZC3JSukWvnVrlYfs0bHHayi9vElxyZYcqv1iBpriGrnyeXqBWaPH7FbI+U Zaf8XmST3dYV914lUpJ7tZqGxDc8lBnW3rpsrH2787zlwNHeHmH6XXodHSNzwPj9vZZlx7tsXNbd z3VpiJXq8Q9Lcwh+H/5m9W7j/cYuhiNeKc7RDtBVCKa0nfReadf4N7QHl5Ll6TwNNUnZ/N0vQo74 F08gabQ/7+l+PqdLJJJ/udtLJf7P9nTUhbuy/8l2jfSH7drvDw8s7gt/2Rb++oHEX3eIvz7I8Ott ZBZMxVH/8BtOVJ0/bQ118P8bnlImsn791rDEgFeldspE8FJqvKFsjonP6yLXYT/u1GEFY5mGFVYU YUnbI6TS2D4rslgQ8zIu9mHARUn+ogrl84rB+nsTRVVxvf7k2g1eRhhcZzhe4ibBm6/fINxeZ/3H VcYjdZdNdSWUfXu2TQ/lYaWo5Pt2WMPi0cLtqw1WirryiWWuhc1pDF5tlcwMay/al3L1nLDk8PXn Y3+JaUi6zZ7b5twY2MuT7ugjef5lQiZWR61zgnTKuuKcbCk9y3dSv6w9WCJpqIYmrn03YjShTC6n IDc5q1eLV5tb1vl1skyxD9bE0pP1NO7gfGJndnh4Z7mFkXP2SbuEyru69dYr4vovAYYwXFfaCvEe 7D2v2n6CvPUZk6adLuKaXcObVfrD09w7Wb/mhDHntaTKUWTS/wLwQSaw9w3cNTUDvF4qbVi0t2f3 THqPeX/DsfvhZ+Q6BDpiJU8KdBpy93UNt2e1vko0SzPu6rAsTBG+HJHvdGKKmJGc87ZdEpm7XVgq +Y18SbYJucNfok/JxkF0jeaUUmsF+sq1fUPpywnkUWaujCay4aOfpsyb3I/ZhDHvL7D6LtrC1zZq vZTmy/iGP3c+HQusGS6rgYtNUDBvjbCvneci1vtedDirLr7xpZpGssVEyRoVx3dqm3fdjtq4Abfp Mpd/MtJCkXv37UkbzaQ26q652nvrey7scouMllOwFh2xy7z34Zv3TufLGhYJ1oWDdmn0U+uK/vIt dBRNexDzHczYtEzdydU3f0fIjgefznk7r1vflpRb+ao0bANSuDJmT1tZ+rM+A5jcIUK7XHxHI8r2 qzpmKH1T9dnUoTlvz8pLb8CyqfWH7uodgVXkYTHeNQ8ElfC0obBEUffSWhnZ4vrjGUNvD3TWVKCn CIbex2z6021IqohEzMG2qnO2n1VEWidV3k71j4zeE7e5pT0nzC/S1xqKgG+VepQIP5Pf27ve4FPU xszJ21SlwDeHRBBwpWel/AmHU8fSv2Xd6B8LrkIP2ltqIvBn7pU6T629e8zjlgL9/PnAdGP0w6p3 bWOUCD192x/hytYvL19PL4vCxt87hveQmj1Vr/FdQu/zX+mX9mONMOdKBaNlMvhhxff760utET48 HtdV/HExM+IpuHEid4WchLn9uHa82uNqYNIg2XynbILAe1gnzNyKLsOjH/wst3NWHy0T/87C6pyE kacfGr1Txxv7QrzbpcTIsEYL1/dgRfbVWAunPbIKlasDVnINn4aHe2PqE5uyjMQwN5WbNE1f9Zki p0OXD20JvFR1lb1hdEpBmTqqxwPx0sYyVxGogbnTj7Slpl+d0OBPvVHxvvxJliAOxV8zgDA6I21E 6IpJPYFFzPczrOI6ZDunpVfOR07dvlerQYh6vrrbhK/rwPrVpQ+dD3PLusgVyvIYnn2T/CgVm8ld jKDFrrCKnfCNi2wpKAMUE7GV2O4YW27caR/E+M73m260prxy8Mo5eVYLE+vM92pYMdE+E+tLo/HQ 7XGJM3sI8Tgnrq6f90eNwE3RiaeuknzQ6n6vYr8NeodPz1qm05BGlLXo2XUwNWbmq9nBCxcerXw0 nLC56omx0IUu2Uo6NbuPR+ci9rJ8V0l+zlzwbcH5oFWP9e4o4K7ctuH+yqdgKoq80hc4OH9TzSiW oWSqL7NqVkgq4XQ8X8SzFUiVnREJWTS+PmoZsvOWbcIpWz76sOjy8JukB/KX1s5OrFt51fVg9fBN BJC6LBE/Hr6prFipa4DSEf6Q+4mCbz3Xdk/E9hsb4kHj7WXDjescm1x4C/nyqq9cb7sodFSSnoWm 8+vkzo+2wWNo201D1iRb1jr25NvU3p2oSVE5sjkhqLcuF11qtS1C8ljip0iy9Y1DCWJZLnVnT7xB ugtz7yFUmwwWxRn4rYnADNMThVKOz7yeFrmAknmmvYeHeNfIVcW6wW15gg0M1h2pFU5P80waXO0u ufzZE2y3iH+W2GQVYmNMw9CPk7M5b1aYu6EsVvda7W975RFtE/Ni3bQ2pv9lztCt3aLbuM/tPzfb KF8VeyWGmrD1VpLxR4fdDa8tO0R/IHt5T22bl1c4fVG//86XifTssnRHyqi9YrnugXWO3WsfJa0w z92mzd25AW2YR2qX/3y4xzLOPlTGuO8KrtzJ9BmSp9WyjNywOVVH3ppnxL3slH1KcfH59Paa7FXr OzHgcJ0Bv4RVzXphy7k0MUen90Qvl5tB+zyu6muUfuTaGrZys+P0lpq+D3moe6+kuia2vkSQOyhp rwZ5B0kD6o9Ww3Xfpr25gmEIVylJHPLzWFa48/hh6hor52B1rzHtzu6s08xtRza6J2xR3GilV2ni Z1waxlTcdftU+hOXHtXX+0a7bix744yGEWxjyu5eWNY5+IowgHP/1FuViDWsWL/hRMyYzL0E0dRo 5S2tXW5VoChmsjVa8i0C5N14Hra3bbOr4Zh4hwxsfnCz/erAGyFvq/PetNr2BD6135s+HnTvxPqD L2aiQfRViufQiU1PRMvn3NPjY4sFuwAnblBfJbH7itim3UcRG64cerlta+VhgtUduyupiNxHKxJw YWMDCr3PAsuljekHr6SmUp1HvFdMW3LPIPZYwPd3PgH3a9+UGK5qLX14HW616botT9JB+/peeK3V ztErxOTOyahBJaMbj19GFdknnNr7ctUDxQ1VKM9uCad3ZszMVVvzVt97VmL8/hixMAvOXdtqeDjU QGobgrJboOmToGmt7/q0Zc+L2s/U0h4iK0LepQQGnL5diVm9oxG5oq/+y5Fdtz/33YvaNfpFX+PR Q9978vNrdFudPlkxwZEbjz5kT9XxHi53cvA7fShKyzA7/d1DGq790Mvudj9+XUKHtlT4eNTn6O5H ScI6KfZ3h4LHNDFrhZ/k2dfeOJmbOm5VR0gemD89cC33/mZMtUvnzapZxeJ86XPryqqOPs8TPX/1 5YW7wdYPHQcdumLu5m74snGrSPH7TVdXX4X/uC5k7zeqdCR4owCMOEr8dmTu20ttFJf9wxfTayFb 3q/UmXk4H5+3LWOFIZ/zlX3XPhmn8T3ZPW77fnJmwsRCYz6+QUll8vGY0htgCiO3F+FNjHkwQC0d 5q9p3iKgXR14WoGhWwcL9/BZhqh5z/9I6LqNeS2jWwluYB96GG2cj04o5huzV8uokylfwVXTadwL qFvbag47Ds/OZqvVuVe+tgsOtedC3GZgHJDXBuQLOmn+vcFZjpWd/+KhCB38318BJ1B+2UBS/9+5 9amzdH+r88dbnzr/m259Dnj7qrijG3XsZ0LJEsPHJzHLf8DFMzJQJAIw7bcrKdPstTKuXwJ/7Ofd zPtm27k7bDXDe9fKdYOpg2Gr8s1fkOpcp175iz8PFbmLqDbBpy7XcGxXux2hJFNoG3l7I2YimnxQ QBa+rZBmKLMstRvOF2Nooi+NEFa5lDURSnredbIxxHmjVn8PV0/aiWPG74cffqvYt/v09+Rze3Jf iJLVJkreN4W9eQA0WR/w+YrAEm3Hympbvn861yhPgp23L6/52ImdNkWft2POXFAwPLARbYTNff/9 hIP1ej6a3TB/HyGbtnE5ER9hIdJzPE/twoUtJSh+2vzbFHGz5uCNy9ZMyJsNyTucWCUjn32lemiw M0hX8mhXY4S4QiiP4h0kmBp6oyGUmkrM9BabJWfy8vRLrzY8LblCwaIlJjNZ3dsjV4EvNVBK4YUQ Q8uBnxgp32Fsmamb0SOxG39Urn2cmJk3VV6j9/Zmw7MzoXMDWF0Vvc5X+gk7ht8iBBx5vttlqG7P RxLueRYhLUKkhB0Ngf4HOmnYRxZqco2DoqvtvIIEku8mBAkOYFcf5nU3DA8JNMuOOrzspvZNSQ2L sXGvDyrXMo4oTtWuHkPcovDUiacskyNEXJRhPZOxfl1rqAX24DvpOyfzb4SedzltEdIU9RYnvh7t vJF5Phe9JXlgsE2G2Lt/5H0SPTWaiPUObtMdxTEBmiTyMd/Ok1rm35Aq8m9oQatt8j83kpSO44b0 1WaC38lez7O8Q7O32a40qE2npb3hT0s6kDe8p80Y1b8/NIloINHREhHkWvEo/95nH7dE2oftfnsJ IfmPd5hsCQ+Ku3NA8ebKp3pGdkmM6GmC4mx7wbKjd3e8fyU3dGYmpMfzI/9JsS1hD8+r3BGNunTu XtNKeG7cGeGe/uCv0VfEmV+zDE++Lr72aN8bye8rU98c3MR9bf5Lut5pH2nkmwuk1jnfRK2uZt4Q /xEnmFibSit6MllmROjuJ36u3exXCt8kwsRuWPPJ4S/TR3vCz9S+aX1RdDdUWg+8USlTbiFKqvvq LzHsHzlyP4AsfynNZs8Gs9d7S5UEQvTn8gFbh57wMKXYOSwXMCvZExumE3hwXd4D2hEX9Fa+u1e0 VcJ7nYzR4fxIf0JyTqe4MW6XC62LiH2zPe2QbJvccenZE+WOP2z88TY+JveTGtO2Hro8vWMstslg 1UCQ4TFr3znapTNv+4Owci/XmL7tEXPiXo6RqV2LbJfIIV7b5+7lvOllZ9x5OWNRu1kNX2RJumC1 13e38qSAtOfaB2geKwQcTm0we7ZHNcIEkz+Rth6YoJWEV7sM+ptjypLWZ5fWiNvxzloCsQU5Io33 pGZzc+qLblVNnlTgbbE2bN5yQb7cQnH2TJuFspe9hV/gA4dt83ur42It7n9SK39bGOS4263CYq3K xvS6/c2Pz4o/TtJg1BUVvIrQxOYdEMt5Vp2TS26Tsyh9JPTJRWbP86LqrUX8s0LnbR736RxxTRvn vfg0MHXn0TPvJOY8rBJlPO9ttXx/4uRI5HODUJsdbaKaBkd2HmRmZobYWbx/fP1YbWHDxdPj3M+N bvW+OdSgHTPaGfzy+rLj3um2f12K+j4jnRBRLk9M1zlqtLv6Iu+uoD2FJN/whi5jPb+j6w6fM/tk gfGZZ+bOJF26/3VSUfXQkYZv2WMP7toPe9ccPmF4zSltLyGgIzEvPTC3PmD2S1nw1Vze7ccSLFtM lW96HNba9kVDV3juyDfHQv7QTIL7uvWPr0rVvPNqvlLr3Hk0JDD/XdPN68V3abXLd9e19udhKTvn 0a54IqZbvHgg8PXFZSPbnmj0SYltf7epPXSHZohOL7FLcLOk4epsmWrJPBULPimL0ONtyrit20ee K1dE5J04dRYpQ5V5tsb5FXL07BcD1+eYxyfCik4azHkvCzatOyBY4E40Sz6cmhemVa8ydaEn87XA ussaIVJyimeqy5bJ7XVYJe16QugGJmPjnUzlUvHmmjnLGx0A9YH1/uVejS5pd41UXyZiuYhpEk6x OJtn84RDsk0I4+x76D6a9q1cxeNx/mR5jZy3gp828mWk4pFHkbq2uPjlMLU5TRM+s5y5nFFRndwz 5l2i5jDjyFeEl8VHOvNXYtw7X6k+9UOMf8d6MTL2XdOgpmdndD8LDDpMaEiPJUtlu+BujagkBZRh ViXO1GCNxJxXmziLHMsVC9Ok4wLK5J8j5iuXhX+0GDxSI1V45sh+e8s2G2BCmjxegjUKlVlNa6MR 5Xbsr362O8VMqJBBKxaGoW15qaljfs/OOJDyr3KBCFkErVLQqNDpUuxgxaNuiUt7svAhzylYxIhY 2J62fUOv3h1QVywWjEe7Xnl68PyTelgxpiuuGhQlIw5afyKojpR+PCIzu1Unqym5u5R6WcRHKtyC t2lvb2282DMfjwp/S/3JwuM43K6soBqSqwHPAyA4GhX5fpB040Bk7qx6Y5HgQ/2pM1rwLOyfdy8/ b/IRdCi/fO9Xh/Cf7l50iP8/eKRT5w+3BXW0/7iVofyvuFXH/om+wmvsDwrIHegouKqcbVxGEI8t jTeTEzRnGCkLPfBJ22smp5P/0TBWDINnWCtbCdsp5ppX3pNB1Fisyk3zrosh74VLWShmdfXKe5El B18K1SixfpkvPTlCMOO+r8bU8NYzQ/3fC/numkdTss9NLCNJ8SZP2Pp+iRu/++K4nMGI3ZnZhA+n 5nH+D1W5kvnp74tMajyJErfxudLnH1oeSILh0pRTvbJylMjPzWmrUkeCZC82H7PS+II0bNEuVIdV Ako8RjGJiujyINem1pEEH/GTGjW0myc1VPMennmxt1eyD4x0fnGmgRk/f3pLpWPKGf7LpyTN+Hcy RJFdB+6lnCnbS5xdbaE3+QEBtswnVO6reHb2vPX9j8Mt4UC1Suo9fRSi1RBIX5Vmz9REWx1zVhpR zxoGxni8YgpVRgQlHgnFNZTkJCMt5F1frSXs7ZG3sMzbvPaCHbwyxz4yMv75BP+Xaolk3vvfoMtb 6wzT42DdwbUWjXUVFvrOD/RvDeSNrLVIXB7xxWog5Lnse2RZOX9ictyQMq/mwL3Vy88NT9kOI+lZ 3rpVYSOHTnLBwg/1E+/CrVXQsmLZIeh4XC4ZLetJU0KT8NVYblk8TXEkXommfAsmPSt/K3i+XGWP 2usrKtww9MHojeEzh1S58UJXcKmu1DRRrfoYidjYP4/Inze5tX/9dJ+O1v/ZAflfGGraf/i09h+E YLGHCk5RXpHssnNEFINVA+Fs6SEsAjwEGtGZDLYgms4BIQymLWOrY1gIPVTNKCzYB6o2DYVGZkCo H05zfUCoYSgzYBHxj9cH/1v9E/51///1rgn4/1bfxN/6NowIoAf/G33q/Lf6JP3Wp9O2EK+wYPZE GMGMNPanR+BILItY0xdKRC0tqLg+wCfSn4nbgNPG4yEUHkcikXAUAgmnBZW1yDo4KqtMoeLIJB12 HSst1rHoF3PWu6pUTs1/IbFo2fRQ68XEx0Mmk9kQhUjEaWtTODmBlaBlRJsEyUhi41gyaJMInHqq No5K5bRhfRyHCFFScRQyAaelpY3T0uG01oau11kasOq0yVo4CjSwWHgWJ6o2RyttLSrEYVFCFv9F ycjQeslqrUUk4MgsbpAcJKIOO/+pAUWbXQ9xWMQQORxYVOzWEAXLsiyJyTqLOcSZCtkD6pGVc+zA 8sX/JP0f5UCEpCNT2JIRWD5ZiA2KFum3RMCTiTgdKoWtLitnsYAUXwgVltkWDcNiwVZcG/9bALC7 wLP7JXEA1i8TUHFUIsdYLKexOLMdrM3BL8Isnn9KrM+Lkv6mgMKAlaisRCT9DF62W/CkhY7/rAgk MMvniywoVI43SVTyHxNbwYUERTZ0ZlmTxYFIIbPVWUz/NQ6s1hsXpnUTBtM7IiA8MgwaxX94vo34 r+asv9stMOLMHH9PFcF0PyZOe6HSyCgsBpoY1FkGUidCTAlEMpXjF5YgNgFMJjR1sScQlm6sySmS EeICUegswOYLsEUkPTjA2zDUL5iBY9EZ08PNGQF+/pFsbhDCdaFIYZcMmd6shW2hjiU0qwhJwN7m 0dkzKKdkQ4/h9A85jd0y+ld5frMJ6b81p5L/gzWMo9V/fVonkv9bImj9J8vovysG6b+3umj/JoYx tNMIYERAgvzXO9b67+lPWbqU/pvbB6rWf6tj6m8d25tYWdjbqUId+bF6YP7XV1bWbMkeNQQ8CToR oOWHQMIToBO03FGhwU0gEig4shZrbFFZGCJERPp5ohAWTmQya3WBMtYcBW3ToPbQjKWjw06sVlpa rEmG9SAEBZrB2GMVWmJ1SKxaApuCk1hsdKCNDStpseZT1mLEmpSgpMOa/KC0OB+zW0D9LCYCgbX+ abOmZip7uoaWXioVmouhxUsbmiiorFkWWi7YiTVv67BmXUgryAmc3rXZEhAI0OrM2l5BMutok1ka QQJBGupAK7EOGdIOT4Rme6LOgq54bWjRprJsqMWaiCB7sHrQ0eL0xnpwg4D7NbHMyaagcvrTorDM oY3nnH61hxbkFFbiLP1/W+nfTywp/nXtQgj8pycSe9Viyc+C/qkXK7G0ZtX/qW4xLbXIv5v+cw7Q pEtdelqqEcvN/6HaRNb+gXViRQo7Wv6lTDoUHRwrLWIorE3VLwlyL4Vz+tmOQvot/aIXgZM4IcHa Y1KJvyUylEhQ4GqTtNjr/d+Ohoay1p+WY+ofrp6o2v/ecvynmYa9MJP/uDBDcweBte1labRkXdb6 dV3WJv69LrPhf70uU1m/AvVzWdYmkv5eljlVP1dl1h+/fq7KnOX+71WZTNL6dVXmNGWpYBYQzGDt sv5wW4f6x9s6i89wccosnxF+w7DH128Y1iz5yxXu4gU3AAIAwAfEAnDA3s5Jk0jon02DMNNQcvEO oYfrvbygDwAgEYAIvKMjcQ2atbUAgIDKXLq+4X4hvW/1GgGAOxjCbfYL3ub7/S01AWI4BLXf6Q+Z 4cKddBsA4F8LlbX9IYTQMp5MqLwLKsv7h0TGWBil7YHKZRD/1OAwb/pys+UaACCkDPXZH0KPCYe7 IFUAYNlLiB4XCsVD1agCJLGwAAAIHgoPY0a6BeuuBwCFegDgSQyPYITbXVi1GQDwBIifMwCiVoBZ ABck2yhiFMKILOaADxyHYVX8i382TjgcQJvHzf9AqoKVAAFFABtj/66Gsa0GiQEZBfoHSkAJCSwg oZyFBf/BEirDEVxIFJqbhxfDxy+AFRRaJrxcRFRMXEJSSnrFSpyMrJy8guIqJWUVVTV1DU08gUgi a2lT9FcbrKEZGhmbmJqtNbewtLK2sbWzd3DcHpeYnLInNT1jb1HaZk/6OhcnZ8DL24fh6+cfEBgU HBIaFr4FWo6joreud3Vz3+CxcVPMtvgdO3ft/is2ISlzX1Z2Tm5efsH+wuIDJQcPHS4tK6+orKo+ UlN79FhdfcPxxqbmlhOtbSfbT50+03H23PnOru6e3r7+CwMXB4eGR0bHxi9NXL5y9dr1yRtTN6dv 3b4zQ9XR1bsLIMCHkKZIAAFpC5vfPf/jxw8AgKwYy8rZNkAC3QArlBCQ8ZEACkAD3AAPwAtgoBjk BwQALCAICAHLIMsuB0QAUUAMEAckAElACpAGVgArARwgA8gCcoA8oAAoAqsAJUAZUAFUATVAHdAA NAE8QACIAAkgA1qANkAB9IHVgAGwBqABhoARYAyYAKaAGbAWMAcsAEvACrAGbABbwA6wBxwAR2A7 EAckAslACrAHSAXSgQxgL1AEpAGbAU+ADqwDXAAnADIz4A34AAzAF/AD/IEAIBAIAoKBECAUCAPC gS1ABMAEIoEoIBrYCqwHXAE3wB3YAHgAG4FNQAywDYgHdgA7gV3AbuAvaNwlAElAJrAPyAKygRwg F8gD8oECYD9QCBQDB4AS4CBwCDgMlAJlQDlQAVQCVUA1cASoAWqBo8AxoA6oBxqA40Aj0AQ0Ay3A CaAVaANOAu3AKeA0cAboAM4C54DzQCfQBVm+B+gF+oB+4AIwAFwEBoEhYBgYAUaBMWAcuARMAJeB K8BV4BpwHZgEbgBTwE1oHrgF3AbuADMAFdABdAE94C7w/9q/S/+yhgAd3qArLA7mDkEHIM8RIKsS IO8RIL/mAXmwFg4NFDHekA0JUEw84hqAIiiCjSdBfiJAMfMRrIGigoXRB7ygelYE9EG5AVTnDeUg m0cemM7Od0ExlAe8grXAumHd7No1EF9LFgXngLVwDUB4Fr8EyHu3wU6IZgfb96eAS6xWEOc8yLMf QCXo2As+AJ/D7CEsyOof4hMEUedB8p6DvPQGFAYNwDSwA6IRgsWxZeH0FgvR9EHHJTYX1mEDBoNh YAS4B+I5C4PDtCCuYbBUWCmsEdYNd0MYcA0ghZAUVDDEBRrB0DgVhDRkcbOFIt8LOrb85Mo5xkEY 6AA6g/5gAVgKydAHPoeOtzB12BrI6qwjH+6JwCDmuIK4yqFjALkOdRCNhHizxr8ENJ4VoLGqD41K S2gEssZVIDQKWceOhVESvxD9tVCEn4aiGOoTisvbwAfIOgLQwdKLAuqA66HDDToiwN1gImSPvb8c GWAJ2AKehuQbAq/CVkJac45gSHuOlAmwYtgJ2BBsGHYHNgt7AnsFB+Dc8M1wLzgTXgU/Ch+DjyHM EaWIMsQ0YpoL5GpkW0oIKYzciNwLHekoblQQKhGVjTqIauPRgGYuBWhO0oe0Wg9ptQ3SZCc0o6Sx vdYEHaxx2gqNwicsPaDjx4ImrEMHNAHNwHXQ4Qa6g55gCMgEY35qVAlWgzXgCUiXq9AxCd4E74JP wRfs4wMMCROBqf7Uzx7mBFsPC4IVwIpgJbBjUES2wDpgk7DbkI6zsHeQjrxwIfhy+Aq4KdwMOpzh G+Ax8AR4PbwbfhP+HPIbBrEaYYBYh9gI6d6PmEXMQZ6EccG5FLi0uHShw58rlGs3116uQ1BEP+d6 jsSwrSKEXIbUQ6YgDyNbkDeQ31DLUSIoWejQQBFQTqhgVDTqKGoW9Qhdx23IHcAdwaMGzWV4aNb6 /V8rFN09sI1ITUACvAlFwxa4AESFY409GAYVzB0Aa2FJh3IClSBP3QI+wLkBK0Q/sB6+AQjm8oLz op4BNSATEQceg5tBM2UVKhrsgHvCn8OruBSQehx7worhR1HbUJ6oR5Ckb+G5XP4oDdCQay9YA1sD jegI0AF4D76DZm48EAlTgeZOaGUAo6F1Kw9dB/JBY60PthLcy1UOb0aUwk25doPKkAcluQbgSdAK tBxa15Sg9YoLOoQBLhqFSiGTiAS8poa6mqqKstIqRQV5OVkZ3MoV0lKSEuJioiLLhZcJCWIF+Pkw vDzcaBSSCwGHgYCaqZyZJ65R0bMRoShnbq7OKsvRIQT9F4RnIw5Cmf1O04jzZJPhfqekQZS+/6Ck cShpPylBLE4f0FdXw5nK4RpHTORw7aC7gysEZ5jIueEan7NhGzaMUGQX+KCCjAzUAmcq5m+CawQ9 caaNZtH+aaaeJhC/Jl4eYzljBo+6GtDEwwuBvBDUaCYX3gSaGYBsAGZmqtsEA9B8kFSNlnImpo0W ciYsERrhCqZ0n0Z7B1dTE0kZGTd1tUbQ2FvOqxGQM2oUUGWTAMbsbhqRxo0odje4AJY6wF5ck1pn Wno7FvDyVMX4yPnQPVwb4XQ3Vh+Cqo1r5Uwa126fFVNXawernV0buY3bQcDZ9RRg+SO2ySLWxMSN 1ZuQsWsKm1wUIhfdPisJTzMVC8CximlpKbjGUgfXX2tlWGc3N4ipupqVo6sMJLWcaTqOpYajK1sD iCkopgkJycKx1OQozJAzZWE8A3GN3HJGcv5pgZ6QsyTSGgHHbTLNEpa0Uz9mAEtTXJqzq5xM4xpJ OTe6iVSTMJDmuK3Fgoaz+L1GXa0JK8ixdBO/wAKA4fsVYPysY0NschYESb1oapAlkZwFFCKNOG8c JImrXCNMgco6MahAmjcVIoP+uYGQRQMg+3mmYXVZjuBSwMrh0t4BUCDIPX/2O4a+gEEqYN8BLJAV Lj9DDqpfhBtVVRtVVFiRgjKGXAtJZsAua6mrRTdayYVjcY1WkMkAe1eokZuuJmRyGRmWl/e20wAv qNAY6+DKKeMAL8lmgKap6tYI82TVdC7WLF/HqoldrPnZ3FMOCucT7M388ka04s//AliRZab+uo2g yH9QzeDUQ8PHFNeE4FJIs3dVpKftlVT0TEt3g1xjBg3FtDQzOZxZmmcavf1HrJccDiuX1mRllRZu 6rmoUvuPzr2SjbR0N38QMmojiWONxmXGrnBJmBsHgknC3dShRRW6RoHHQlsLOLS1lqMJoK6AiCtg BXT98wPg+gE/BT4AAM3vz7HPgTUvoDN01S4oI6ggIygTCwe+xcKA7wDXwGdqLGKAtVWvBztg3xAY iJfwWQCEUVj7dtAbYvAc+k/AL4Oa1sPsISL7b42cyx1YLHDow1rDzQL679CSaPYcXlWf+52VN8qp jwDAd3ueOyjo0gyaFsHFiyIU4bs9APCmA8CPMZ47Sy6b7iEAgH3lBV1fASyeaAPAklsJyOMJgFIn YIlSBPK4O4B6+FGgDw1th1GyQD23wELazEm8KVBKB+rRfUA9z3mgnms/J7FoEWFQugTVQRsuVD5g iS6FeCZCsAynnp1Y8FoIDyVEC1CPdIXaMzgJtYeTED6cxKJHngdcFhP6PkRnDuGGoD7aoHpJKPFC ODKEi4Py5UAe0gLIW+yL69NCGoASJDNyA4RfviCHCkcWbhrEC5IbBfFDn4JySD/UVihlQ2USlIdy dEUnQe1XQ7kv0MKjCqQiINux0mJfkD0t/5Gov6UdEM2Of9ji/3CCtqz18FqOzux+/pkOc9J/Rodg 0c3+SgNiF+ouQbDAH3mzE+j1D1zKv6b9ryW01z8SdCmC5sQv4T9KPEgoPpEcn7P9/jvf6z/hawtp oYzU+j2h0zjpZ/2X39NP/E6gj5VYPmbDhlD+S4LfBLzhywFv9FpoYw5AF9z//0MRujT733yw5td7 IAbQBDIAfmjFwEKQDjQRP0NsZl/0AYAMmPNzFg7/eSMLhCjDF2AYtLrELsBwCJ+yACMgeP8CzAXN 8UcWYCSEb1mAUVBvPazbZgjWRSAG+MqGUSxJQDQb5oaoZkCxBRgEcODHBRgG8MMW8XAAB1NcgBEQ bLYAcwFiMN8FGAnhdy/AKCACdmgBRgNKcOwCzA0YwKkLMA+vOTx6AeYFfPjPLcAYwEdAlg3zsGQW SGbDvCyZBXLYMIaNL2fDWJacAg1seBkECwl0sGFhNs0oG5Zk00yxYWk2fo4Fo0XY8FsWjGH3hQWM w8K3RbBvO9fiCDo6RHXopIWzCfCOCGOG+UbijMMiwjVwhsHBOEcWFRPnyGAyIqIZPhqcBnhWAwKO fZvdKSw4KjIgLJSphrMI9f5zq3/ebndk+EUF0yP+if5n2YURwYQ444gaWvh/1jn7M3BQwSdsKxMX HOYXhgtgQpcqkRF0H0YIPSIIF+b7D33CIugsMTXYt9QigBCADgQDTkAklIdCMxEdwvkAxuzbbdsg OIB9Iy4SujSshRIBijAdgAioL0BaEM4GovGGKMMAJpR82bTGbN7hgAYEG0L8g6Hc8ScvJrvEgHIG RBUNnX3YlH/3gP/ZAwHCOUOShENUOEjOMIhXFMQjAIJCIQ5qENYCgrz/rb7sARPACmpnD9gBqsB6 iDoUovdZyJnsFn5QP8Fse/xn1P9ZvQu7b+aCzDjIfhqQ5fD/aTtnSAOW1pwaH6j1VrY+wRDkByUc hGeV6VCKhHqgs2+dhrBlDoJwLG/8x/4JY7datKbGH2k51mf1yKINh2TaBkkdsdC3OdsjIWwL4xZi iMXfny1F8ALeiO0PBlvyrf/Q61eNcVCfLEk4ftvKthuL0ofNh8UjlO1B6GIDkgL3P5QDx+6XD+D5 GXV/t1yMPg22BTjy/lm2sIVRwuJFZ8cfSzIWHLIgqzUUSd5QvQ/bUxYQ/HfsGkKtIxY8q/ZL/5wR GcHuK5Lta1arEMj+wWwfM9iSsOo4sv3eRySEi2HXL8rMglgSBSzIx7HfYmvmgrT/tDSrf42FEfS3 Riw5WbqzNPdjSxwAbP9Zs6hBBNvODKjMXLBDADv6F+cQHLvmz/G5NDKUIC/YAMrsHhalZuWsXv7p m3A2t2i2NRgL44MTByFsKla0R0GUHEssjS2WvJE/x0/AT39xdApnn5kLHuDI97dMHC+FLIz0RZ+F sXkvysfhG75g37CFuPmbOortvwi2JNvYf/BgefzXuF7sjfFbNPzN+++xypKewz1qYQ7k+IHTAysm vNna/B3nEQs24+S/au/L9jgOmq+M2X5YtGYkG8/CBEFttkGxFbawjixScfpW+zlPsW6zey2MFrWf 3vFhe4M1mqIXqH3YozuI7Y/InxzoC6uBNzuCmL/VhrPbL+qnthD3MWyIRcdaJ9R+xt5WtgWDf5b/ pK0ve8wsxlgwO14iFkYra072hrT72wMcjensNr/CLJvEsC2txu731xldja1LMIQL/4ftFv29lS0f SycvNsSxiMbC2odjz/w+bE9wZnK1fzG7BrBXStYK6rMwI/6q8VY2B3/27BC2AC2uK3/zpi/YiyPZ n2KWM5YC2JbzZlN6L3iHyZ6l/H+xf8QC58VRFMa28a+x7r8AMX/OO/SfOrEiPfhnFPxuyfCfNEz2 zMhkj7VFz3kteF5tQdsQ6MxpzRoD3uz183ef/TliQtg8Gf+BpQLYMeC3YO+lFmCwV2D/f1jvb22D F1YXzijizAkhbNmCf5Eskj3ncXYGf4/537kx2J4IgCi92RHtw16nONEbwW6xyI8zBwazLRH5c9/C mVvobH9zxsCiZ/721t9jjyWPFxvvt8A3nB15zJ/zFmft4KxNnBWZsbDiLXLj4KMWVnn/nzOVPYQN +G3+/bV/nwUL/FobsTCCWfkWiCPjZ89RbKv8vaNcXKf+NIf+aebkxHXYz3a/x8Di6k1fGF8+C+vt v7Ju+BLNfo//yP/i3onjzbAFvr4L0UX/ZbexKK/3gnV82fvdRb19ftkX/r2usDz09xXBos192GPd d2Ht4NjVhx1njH9YdrEFK163LezKWP40W5hro9myBLBnt22/eZUVc3Q2t8WR48WWN5hN++s4YCxE S9A/dlSsHhb3MH/P1et/RsyiFf9kucVd9t/yLd0n+LF3RCFsXAQ7ZnC/jbbFSGFFH31hD6G24HHW TsTvl10hZ+/n95tuf1uOvrAv82eve+GALqAJHVvZhwZ7j/f7fkpjYZbWZEsWtWBd1hjW/CVmNBdW pV9jSvP/SB9L95SaCzODD8RfE7D95Ur0b5jOnvn+XMey56/XrJwV83daOttbPuzr3H/F5VcYxrkt 84PKvh+39N+9hWeNYCAcRIBcIBJEgWiQG+QBeUEMyAfygwIgFhQEhcBloDC4HBQBRUExUByUACVB KVAaXAGuBHGgDCgLyoHyoAKoCK4ClUBlUAVUBdVAdVAD1ATxIAEkgiSQDGqB2iAFpII6oC6oB+qD q0EDcA1IAw1BI9AYNAFNQTNwLWgOWoCWoBVoDdqAtqAdaA86gI6gE+gMrgNdwPWgK/vP3BtAD3Aj uAncDHqCdNAL9AZ9QAboC/qB/mAAGAgGgcFgCBgKhoHh4BYwAmSCkWAUGA1uBWPAbeB2cAe4E9wF 7gb/AmPBODAeTAATwSQwGUwBU8E97D+ep4MZYCa4D8wCs8EcMBfMA/PBAnA/WAgWgcXgAbAEPAge Ag+DpWAZWA5WgJVgFVgNHgFrwFrwKHgMrAPrwQbwONgINoHNYAt4AmwF28CTYDt4CjwNngE7wLPg OfA82Al2gd1gD9gL9oH94AVwALwIDoJD4DA4Ao6CY+A4eAmcAC+DV8Cr4DXwOjgJ3gCnwJvgNHgL vA3eAWe4mOF0bwYynBHqHRCMZnoHMJlhEUyBRcA7KjIyINSPP4LzkKFfMJ3JZDARXozgYIRXWFgQ 0pse6hPM4I9kBDPC/cNCGcyw4AAfVtEfqmAyIr0DIrwxjNBoRnBYOMOL7h3Et1jwjQgLjeQPoQcE e4XF+AbT/Xy2hvL9UowK51TGhIWH+gZDRYFfixAx0jcs2IcRwcPJII6hfL4BwYxIenBwJCMmkoD5 tfRbFYmXVfKmewWEMiK5/cOiItiKoYMY27zC6BE+mJCwKCaD6AUpHxbK7QW1Cg8LCI2EhXuj/aFq nwBmEMoX0iF8G2kh10JH0sMZEQxGMDdL8a0RAZEMvp9QMMM3kotVikayzmFBqEj/qBCvqHBudu4T tjWUh1URHsmi5OWA7PtwaA4MUXIASG02yp8eHMnNDIG08IXcxxvKiIqMoAezYG7IrltDWRDkoBAv AWZQVHAw634X04vlHgTLtCjIVqH00Eg0PSAiPJgeykAzo0KZ/pA1UD6QISFDcTNDw7ZCpEEMdAzr tplXsA/a25/hzQJ4IQctIlnwIh7D7iUsKjIYYsTLLjD96ZByHNibERwZ4M0hCoHEZzAZvMxIekSY rw89OoDVmvNYKwuH2hYQuo0e6gcLC+Ha6g9ZlYseEcBgIiPpURFRTKQfIyQgNIAVe96MCHgwI4wr OiDCL4wrOMArgo5ieodFhAeE8TLpfn4BELOAKCa3Nz08IgDCh6LpW6LYKGR4ANQdk48eAvmNCZk0 IDLYm/eXEv+WqLBIho9XcLBvJKQd32IxglVCQVowIiMZmIWcHfbcXlHQWKD7hjJ+QlsXIebfEIM/ GjIQC/SCIjf0H8WtvxWZ/ygyuLwhOAIJmQqKN5R3WEgIJCx6OxT/kNRMFMvFrDxyK7sMxRcUkywI 7QtFOQcIiObQMANi2DRMRjQjlA2xnzhmE4UGLDLiVPEu9hAQGs2z0AkLXOgHAjE/u4IKvIu9seGF Dln0C32y6H92yyr87JnVYLFzdgc/aVCsqSSYQVzIyQu5NlcENDER2Wcy+6zNyzpzBi8RCpkIP0Yk P4eYE4/QVPJrERpTKCYrKiDenJy8kGtDQyiGyDqRWCcyK9oXWWB+wqwxGeEPjbUoJnkR0EYHh21n hPoxyIuANhoa0azYJnKzhwAL4oHGYSSdDaL9GTGc2jDvBRSvT5gPNEmxYNJPLBmaiv0gPlCUskX8 WeRohPaOYoazpkLuRYCAjlmQiWtLFCNiG8+C6hAvHtaJowM35NMw7+Aw7yBuyKUciJftUQ7Mw3Lo Igj5c4EWcucCLdubCzDbmQvELF8uMl4kwEDx/JMaE7mVEbzIkI8eEcE2KGseJPAuliKgyZwNR4Wz K3gWCj/xLGxU+AI+ggXy/cRD7Rc4RbBhzJaogODIBYcL/FqAgoybNdK8vbdCw3UBCv0JMRk/cQwk Z3QjOUObU+IgmQweH0g/zqTPywHZUzk36wl1IgvLw4bYSBQbZE3vrJy9EHD8w27NATkLAQeOCl+o Z5FCK1OEF4cjG+JwZIMQR3bOIuNgQrcu5AxOzlwoQ1qxcvJPNuS/2ZAX2JB/siEvsCEvsCEvsCFD M5MXiwXSi90cDi1uXJyFjY1e4BkVzkLBvUK3QokB92JCOZOB9PKhM/0JnIzIu5Xz1xvWH29oGMDM DNpjCgmiaea4dph2szkRyhLYGVjHyY5xslpOVsPJjnCyCk5WxskOczILTmbOydZyMiNORuNkBpxM n5PpcDIkJ0NwMjgnA2l2UD4NpZtQmoLSNSj1QKkNSq1QOg6leijVQakGSkegdBhKh6B0EErpUEqA kjeUNrN5HuewrudkRzlZNSer4mSVnOwQJzPhZIacbDUno3IyFCfj4mQwTgbQaFB+A0pXoTQApQtQ 6odSH5ROQukElFqg1AClUijlQGkblHzMicLcwtyUrHYwmmaByipDZeWisjJQWWGorGBUli8qi4HK 8kBluaOy3FBZrih5tCwah16BlkJLoMXQImhhtBAai+ZHY9A8aDQaiUagYWgADTQug1vBrJyMQKvG Tm/AygvX+N5Jrh3kcXBv5JIzAhuFrAArZyOxRqpqIyyV/chcO/ijCQQzkyRZT8udAkDwR1KG5ELu 5gaIqC79J/Zbycp+WwewEqQAKOhMakGt7EWxsE4QNouNzWJhs9hYMbDZHiBa0fd6SgOq/9E/UPW/ +g80DWCpa+/ahAaM3Iw9OHkLjJcH0sdTUsbNSAQbbsBWTk9GbLfkaQQA1gC8qm6NGDmjRj4osarU DdUNWVUIgF3Fz3pAcaFKbLeejORpsGahCguhBSFT/vkTGD9fTCWQCFSdX7/BQPiXNT9fdcb/iiX+ AfsTt4H1ipUZTtMZ2oXjWK9M/XxB9bc3j6wCfJi4DZxv1BAInGyhxPmkDYH99hKOyPm2xkb2RzSi QiPZ70///aEO5t9f6iDg//AZGxL+D70SOb+9TSJxMk4PZDwn4yDJ/7Nutf7ULZnTrRanBy2Omtqc brU5SO3/WbeUP3WrzemWwumBwumBwkGyPzsOZdT/Ubc6xD90q8NxKvsTK7+yJv5brDnIf/Lm8CRx TKfFyTjffVz4Xsuv/S3VxYbhE0DnvOXHaqQFyUglE1ltfuv6t46NodHEegVR6e9HC9aHRfjglBfr AsJCTeiRDJySsz+0Mfahb1PDEXRwdt6RYV4M1ocEWG9iautqabMaOENXIhClOZFM3WwRAu14QiAD QNfim/2iAnwYm6NJGtAQYhEaRkX6szo19mftLAPoobi1EWHQXluZ850Znyjo6ginZAhJ5EWPxEGN 1rMuRiNwJA1okPpCLReek2DRWzG2bYUkZuKUlDlvZgcyvCPZhd8GzG9asy32t2cW7GhMhy6zw/zY 7yn60qOCI9dG0LexXlBdoFrAOq41wrHeKP6TV3++rL4B4hbMar/Q43p/SAF71rU4bgNeg8p6eRmv oaPD+nKEBhFPpLA9u5YOXRSx8EQSceGzOxt/5a71G3dIjn+f+YYF7r9n7DdA6dBeJ4ZFQGL9FqoG QYcEhYoGnvXKNYRjDTcNCoFIZeF08KwSkcAaZ1CJTGDXUcmLsfaL1DERDF9oRmW9LgtlP//htLW0 SFo43wUclcR6+ZZTE7qIY73Z908cifV68+84PIHEGv3/bMuaCn7DaWsRtYhLcCTWbz39zg+PJxKW 9qFFWtJWC79EFqK2ls6Stlok4lI60j91w0M2WEpHZcXUP+lIS/ogEXSW8NPS0iEskVmbsMQu2hQ8 ZQk/IpW8lN8SH2lr61CX2IVCICxtC4XOP3FUCmGJ7bWoeOoSOtb3Tn7HsV7vpy7xOVlHe0lbKpWw tC35n/IRiFpL4opAIBApS+jI1H/aj6BF1qEuodOmEJfSUchLbEUkL+FHXRob0CCk4JfSEf6pG/EP cUWgUpf4F6Jb2hYKF50ldFQifgkddUmsEamUJWOGCvWxhE6bsCSeiVRtnX/KRyLidZbairTEBkQq dcn4hdouoSNpaS8ZMyTICNpL6ZbITKKS8UvaalGW+JxEZb31/zuOTGB9yuKfdFpLdIPotP/ZB5m8 dFySIacv6YOsvWQMkimUJfMVlUghLemXTF1iA6gt8Z+yaOEpOkvpdJaMaYhuSdxrkZaODy28zpJx CdEtGR9a0HSqvYRu6ViA6Jb2q0NYKp82RUtrCR2eSl0Sa+SlcydVm7y0D+ISm0Iz7JJ5UkuHtKQt REdeMneSifglax6RunTtIRKI2kvaEqhL53sCYYluZPYC/w86/JIxrU1dOk9SiazPRyxZa/FLxz6R slQPEnFpTP6hDxKZsBSn9eu6EBlBDwhmRCxsf5wCtjM4+wtNx7CwSNzirs4i1DcMt/jBBwsT3AZ9 baKOlq+2jo83ha5FZfgSoVHi60tmaJPpVArFS4ds8J9TbFz8MAQ9IpKzt6FCeyPoilFBwdTOjI/n /wNQSwECFAAUAAIACACJhlMp6BH7b7yBAAAALgIAQgAAAAAAAAABACAAtoEAAAAAZXBhY2hnL0lU VS9JVFUtU0cxNi9JVFVfU0cxNl9FZGl0b3IvSDI0OF9JbXBsZW1lbnRvcnNfZ3VpZGVfdjMuZG9j UEsBAhQAFAACAAgAF4dTKVnoZX3zAgEA2k8BAEIAAAAAAAAAAAAgALaBHIIAAGVwYWNoZy9JVFUv SVRVLVNHMTYvSVRVX1NHMTZfRWRpdG9yL0gyNDhfSW1wbGVtZW50b3JzX2d1aWRlX3YzLlBERlBL BQYAAAAAAgACAOAAAABvhQEAAAA= --0__=rDRhhz98DwI28GMxfPSckzih3R17sXU3LBvJVSqHDe58OuwctmEkweoA-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 04:28:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12897 for ; Thu, 19 Oct 2000 04:28:24 -0400 (EDT) Received: from standards (47.234.32.16:1264) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6F75@standards.nortelnetworks.com>; Thu, 19 Oct 2000 4:11:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28583 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 04:11:27 -0400 Received: from mars.hss.co.in (202.54.26.197:52466) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6F73@standards.nortelnetworks.com>; Thu, 19 Oct 2000 4:11:25 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9J8RJC10335 for ; Thu, 19 Oct 2000 13:57:19 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.002D65E8 ; Thu, 19 Oct 2000 13:45:51 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.002D62CC.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 13:16:10 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: Implementor's Guide v3 -- Correction To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hello Christian, There is a correction required in the implementor's guide.....section 8.5 which says that DigitMap= Dialplan0{ (0| 00|[1-7][xxx]|8[xxxxxxx]|F[xxxxxxx]|E[xx]|91[xxxxxxxxxx]|9011[x].)} The change that has been done is enclosing XX... digit string in [ ] .... but as per the mail attached below ... the understanding reached was to make a change in the grammar and not in the example (given above) to make things clearer. Hence the change required is to replace digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) with digitMapRange = ("x" /( LWSP "[" LWSP digitLetter LWSP "]" LWSP )) Any comments.... Thanks Chanchal... John Segers on 09/14/2000 07:44:24 AM Please respond to John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Chanchal Hassija/HSS) Subject: Re: Syntax problems Rakefet, 1. I seems that the parentheses are missing, as you suggested. 2. Looks like this could get you a shift-reduce conflict. That can be circumvented by having your lexer peek ahead and having two tokens for the semicolon. Ugly. Cheers, John "Prozan, Rakefet" wrote: > > Hi all, > > The previous mail was sent by mistake. This is the correct mail: > > Can someone clear the following issues in ABNF? > > 1) In APPENDIX A EXAMPLE CALL FLOW: > > ... > 8. The MGC Modifies the termination to play dial tone, to look for > digits according to Dialplan0 and to look for the on-hook event now. > MGC to MG1: > > MEGACO/1 [123.123.123.4]:55555 > Transaction = 10001 { > Context = - { > Modify = A4444 { > Events = 2223 { > al/on, dd/ce {DigitMap=Dialplan0} > }, > Signals {cg/dt}, > DigitMap= Dialplan0{ > (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)} > } > } > } > > According to the definition of digitMapRAnge : > > digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) > > "x" must be followed by "[" . > So, either there is an error in the example,or the definition should > be: > > digitMapRange = ("x" /( LWSP "[" LWSP digitLetter LWSP "]" LWSP )) > > 2) In ABNF: > > contextRequest = ((contextProperties [COMMA contextAudit]) > / contextAudit) > > contextProperties = contextProperty *(COMMA contextProperty) > > My problem is : if the parser finds a COMMA after a contextProperty, it > doesn't have any indication to know what will come after this COMMA: > another > contextProperty,or the optional contextAudit. This results in a loop. > I think that there are two alternatives ways to solve this: > > Either to put contextAudit in { } : > > contextRequest = ((contextProperties LBRKT [COMMA contextAudit] RBRKT) > / contextAudit) > > Or put contextProperties in { } : > > contextRequest = ((LBRKT contextProperties RBRKT [COMMA contextAudit]) > / contextAudit) > > thank you in advance, > -- > Rakefet Prozan, > Team Manager, S/W Development > Nortel SBU > Telrad Networks > ESN 828-3043 Email:rakefet.prozan@telrad.co.il > > """ > -(o o)- > +---------------------------------oOO--(_)--OOo--------------+ > > .oooO Oooo. > -------------------------------( )---------( )------------ > \ ( ) / > \_) (_/ > > Have fun !!! -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 04:28:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA12902 for ; Thu, 19 Oct 2000 04:28:25 -0400 (EDT) Received: from standards (47.234.32.16:1264) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6F85@standards.nortelnetworks.com>; Thu, 19 Oct 2000 4:12:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28601 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 04:12:00 -0400 Received: from mars.hss.co.in (202.54.26.197:52503) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA6F81@standards.nortelnetworks.com>; Thu, 19 Oct 2000 4:11:48 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9J8RfC10422 for ; Thu, 19 Oct 2000 13:57:42 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.002D6F32 ; Thu, 19 Oct 2000 13:46:15 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.002D651B.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 13:39:06 +0530 Reply-To: knayar@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Kapil Nayar Subject: Missing/ Empty Audit Descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi The protocol document mentions: 7.1.1 Specifying Parameters ... "A missing Audit descriptor is equivalent to an empty Audit Descriptor." and also 7.1.15 Statistics Descriptor ... "By default, statistics are reported when the Termination is Subtracted from the Context. This behavior can be overridden by including an empty AuditDescriptor in the Subtract command." Now, if Subtract command doesnot have an AuditDescriptor it would mean that there is an empty audit descriptor and no statistics would be reported. And, if the MGC needs termination statistics, it must send AuditDescriptor with Statistics token in the Subtract command. But this seems to change the definition of "By default". Please clarify whether the above is correct. -Kapil Nayar Hughes Software Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 05:13:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA17725 for ; Thu, 19 Oct 2000 05:13:48 -0400 (EDT) Received: from standards (47.234.32.16:1264) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA701C@standards.nortelnetworks.com>; Thu, 19 Oct 2000 4:57:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 28771 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 04:57:02 -0400 Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7013@standards.nortelnetworks.com>; Thu, 19 Oct 2000 4:47:02 -0400 Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Oct 2000 11:01:56 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <98388C05D464D111B61800805F150416014858C0@p-ibis.issy.cnet.fr> Date: Thu, 19 Oct 2000 11:01:54 +0200 Reply-To: CHAPRON Jean-Emmanuel FTRD/DAC/ISS Sender: "Media Gateway Control (megaco)" From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS Subject: Re: wildcarded termination in Move To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA17725 Hello Brian, all If things are left as they are, it seems that the case described below is simply impossible: (1) | +-------------------------------------------------+ | | |Context C1 | | | | +-------------+ +-------------+ | | | | | (Term. T1) | +-----+ | (Term. T2) | | | <-+--->| RTP Stream |---| * |------| RTP Stream |<---+-> | | +-------------+ +-----+ +-------------+ | | | +-------------------------------------------------+ | (2) | +-------------------------------------------------+ | | |Context C1 | | | | +-------------+ | | | | | (Term. T1) | +-----+ | | <-+--->| RTP Stream |---| * | | | | | +-------------+ +-----+ | | | +-------------------------------------------------+ | | +-------------------------------------------------+ | | |Context C2 | | | | +-------------+ | | | | +-----+ | (Term. T2) | | | | | | * |------| RTP Stream |<---+-> | | +-----+ +-------------+ | | | +-------------------------------------------------+ | C2 didn't exist in (1). How to go from (1) to (2)? - We can't use a MOVE $ (too bad..) - we can't use Context = $ {Add = T2} because T2 is in a non-NULL context - we can't use "Subtract/Add" because we have only RTP Terminations we don't want to remove. This is not a textbook case, as far as this case may occur if the Call Server/MGC is connected to the IN and receives, for instance, an INAP "SplitLeg" message requiring such an handling of connections. Regards, ``` (o o) ----------oOO--(_)-OOo-------------- Jean-Emmanuel CHAPRON FRANCE TELECOM R&D DAC/ACE 38-40 rue du général Leclerc 92794 Issy-les-Moulineaux Cedex 9 - France Tel: +33 1 45 29 64 50 ------------------------------------- > -----Message d'origine----- > De : Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Envoyé : mercredi 18 octobre 2000 15:01 > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > Objet : Re: wildcarded termination in Move > > > Ya, that's one of the reasons it's probably there - separating > functions of Move and Add. > > Probably best to leave things as they are. > > Brian > > > -----Original Message----- > > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > > Sent: Wednesday, October 18, 2000 8:29 AM > > To: Rosen, Brian > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: wildcarded termination in Move > > > > > > > > > > Hi > > > > If you remove this restriction then why you need Move, i will > > always use Add to > > either: > > 1. Add a termination to a context from null context > > 2. Move (read it as Add) a termination to a context from a > > non-NULL context. > > > > -Kapil Nayar > > Hughes Software Systems > > > > > > > > > > > > "Rosen, Brian" on 10/18/2000 05:31:06 PM > > > > Please respond to "Rosen, Brian" > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Kapil Nayar/HSS) > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > Only Add can create a new context: > > "In general, an Add command is used to add Terminations > to Contexts. > > If the MGC does not specify an existing Context to which the > > Termination is to be added, the MG creates a new Context. " > > > > A way to do the consultation hold is to create the new context with > > C and move A to that Context. > > > > I'll note that I was a little surprised to read: > > "The Termination is either created, or taken from the null Context" > > (although I may have wrote it!), since this prohibits an Add of > > a termination already in another context. I'm not sure why we > > prohibit that. I do think there is little practical difficulty in > > keeping that restriction. If we did relax that restriction, you > > could do Context=${Add=A{.... > > > > Brian > > > > > -----Original Message----- > > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > > Sent: Wednesday, October 18, 2000 12:40 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: wildcarded termination in Move > > > > > > > > > Hi Brian, > > > > > > If you mean to say that Move with ContextID = $ is > > > nonsensical --- I beg to > > > differ...... > > > > > > Consider a simple call scenario -- A is talking to B..... and > > > now A wants to put > > > B on hold and call up C......The simplest way to do it as per > > > my understanding > > > would be -- MGC shall tell MG to Move A to a new context > > > (Move - ContextID=$ and > > > TermID = A) where it shall talk to C, and once it is done, > > > move it back to the > > > context where it was talking to B...... > > > > > > What is your opinion about this.... > > > > > > Thanks > > > Chanchal.... > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 05:57:41 PM > > > > > > Please respond to "Rosen, Brian" > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > If there are three terminations in an MG > > > > abcd > > > > abce > > > > xyz. > > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > > NULL Context. > > > > If MGC says Move with ContextID = $ and termination as abc*, > > > > what should the > > > > MG do > > > First of all, I think this is illegal, or at least nonsensical. > > > You CAN'T create a new contextId with CHOOSE. > > > So if it is legal, you are asking for Russian Roulette - pick > > > a context where the resulting command would be legal, and do it. > > > If there is more than one, then it's random which one > > > > > > > 1. Consider abce while resolving wildcarded abc* - > > > > Move is valid for abcd (it's in non-NULL context) and > invalid for > > > > abce (move is not allowed to move from and to a NULL Context) > > > abcd is valid, abce is not valid > > > > > > > 2. Don't consider terminations in NULL Context for resolving > > > > wildcard since > > > > the basic idea is not to Move to or from NULL Context. > > > This is correct > > > > > > > > > > > The first option has an impact on further commands in the > > > > transaction since a > > > > failure > > > > with one command can cause the side effect of other commands > > > > being not executed. > > > True, but in general if the MGC was foolish enough to do this, > > > it deserves what it gets. > > > > > > Brian > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 06:59:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29345 for ; Thu, 19 Oct 2000 06:59:59 -0400 (EDT) Received: from standards (47.234.32.16:1527) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA711B@standards.nortelnetworks.com>; Thu, 19 Oct 2000 6:43:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29040 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 06:43:08 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:38835) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA70FD@standards.nortelnetworks.com>; Thu, 19 Oct 2000 6:33:06 -0400 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id UAA09922; Thu, 19 Oct 2000 20:45:22 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id VAA12314; Thu, 19 Oct 2000 21:47:47 +1100 (EST) Received: from ericsson.com.au (7-112.epa.ericsson.se [146.11.7.112]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4XFQ4A8Y; Thu, 19 Oct 2000 21:47:56 +1100 X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <6525697D.0026F45B.00@sandesh.hss.hns.com> Content-Type: multipart/mixed; boundary="------------4D1628205B70AC21074AA727" Message-ID: <39EED157.FEFC4F4B@ericsson.com.au> Date: Thu, 19 Oct 2000 21:47:51 +1100 Reply-To: Paul Hollis Sender: "Media Gateway Control (megaco)" From: Paul Hollis Organization: Ericsson Australia Subject: Re: Topology X-To: chassija@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------4D1628205B70AC21074AA727 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi Chanchal, thanks for the reply. However, if you take each step as being done in one command at a time, then step 2 would isolate T1 and T2, which is OK. However, once step 3 is issued in the command with only (T3, T2, oneway) specified in the command, then according to the rule quoted below any other association not mentioned in the command is set to bothway. In other words you would need to specify (T1, T2 isolate) and (T3, T2, oneway) in the one command to achieve what is shown. Does this make sense or am I on the wrong track. Regards Paul. Chanchal Hassija wrote: > Hello Paul, > > My reply is embedded and prefixed with Chan> > > I have a quick question about the topology description in H.248. > > The wording in the Topology Descriptor chapter says: > > "The default association when a termination is not mentioned in the Topology > descriptor is bothway (if T3 is added to a context with T1 and T2 with topology > (T3,T1,oneway) it will be connected bothway to T2)." > > but in the example in the diagrams, at step 3 we apply the topology "T3, T2, > oneway". I would assume that if we apply the above rule, then there should be a > bothway connection between T1 and T2. > > Chan> You need to read all the steps in sequence. Hence the two-way connection > between T1 and T2 in step 1) was broken in step 2) by the command.... > (T1,T2,Isolate).....Hence it is not there in step 3) > > Njoy.... > Chanchal........ --------------4D1628205B70AC21074AA727 Content-Type: text/x-vcard; charset=us-ascii; name="paul.hollis.vcf" Content-Description: Card for Paul Hollis Content-Disposition: attachment; filename="paul.hollis.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Hollis;Paul tel;fax:9301 1139 tel;work:9301 2326 x-mozilla-html:FALSE org:Ericsson Australia. adr:;;;Melbourne;Victoria;;Australia version:2.1 email;internet:Paul.Hollis@ericsson.com.au title:Software Designer (Signalling) x-mozilla-cpt:;17264 fn:Paul Hollis end:vcard --------------4D1628205B70AC21074AA727-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 07:50:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07950 for ; Thu, 19 Oct 2000 07:50:44 -0400 (EDT) Received: from standards (47.234.32.16:1527) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA71C2@standards.nortelnetworks.com>; Thu, 19 Oct 2000 7:33:58 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29271 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 07:33:58 -0400 Received: from mars.hss.co.in (202.54.26.197:55472) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA71C1@standards.nortelnetworks.com>; Thu, 19 Oct 2000 7:33:49 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9JBnEC15913 for ; Thu, 19 Oct 2000 17:19:24 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.003FD2FA ; Thu, 19 Oct 2000 17:07:06 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.003FD0BB.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 16:31:08 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Modify the service state property To: MEGACO@STANDARDS.NORTELNETWORKS.COM Is the changing of ServiceState of a termination directly from inservice to outofservice and vice-versa allowed in say a Modify? Is this equivalent in functional operation to a ServiceChange on that termination? -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 07:50:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA07953 for ; Thu, 19 Oct 2000 07:50:45 -0400 (EDT) Received: from standards (47.234.32.16:1527) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA71CF@standards.nortelnetworks.com>; Thu, 19 Oct 2000 7:34:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29287 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 07:34:37 -0400 Received: from mars.hss.co.in (202.54.26.197:55448) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA71C0@standards.nortelnetworks.com>; Thu, 19 Oct 2000 7:34:32 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9JBmnC15856 for ; Thu, 19 Oct 2000 17:18:54 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.003FD7D6 ; Thu, 19 Oct 2000 17:07:20 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.003FD18B.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 16:38:00 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Processing sequence for topology To: MEGACO@STANDARDS.NORTELNETWORKS.COM Descriptor processing sequence is determined by the order sent by MGC. When does the topology descriptor processed? After processing all the commands pertained to the action? The possible scenarios for above are 1. If there are no ADDs in the action 2. If there is only single ADD in the action 3. If there are more than one ADD in the Action What if the action also have one or two MOVEs in it. Regards -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 09:17:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA24693 for ; Thu, 19 Oct 2000 09:17:43 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA726D@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:00:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29476 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 09:00:44 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA726C@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:00:44 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA14122; Thu, 19 Oct 2000 09:15:54 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04074; Thu, 19 Oct 2000 09:15:57 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRSA4Z>; Thu, 19 Oct 2000 09:15:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C039CE.B59486B0" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E82D@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Oct 2000 09:15:53 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: H.248 X-To: Chris Rigano To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C039CE.B59486B0 Content-Type: text/plain; charset="iso-8859-1" http://search.ietf.org/internet-drafts/draft-ietf-megaco-merged-01.txt -----Original Message----- From: Chris Rigano [mailto:crigano@NORTELNETWORKS.COM] Sent: Wednesday, October 18, 2000 3:14 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: H.248 What is the URL to get the most recient version of H.248? Best regards, Chris ------_=_NextPart_001_01C039CE.B59486B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable H.248
http://search.ietf.org/internet-drafts/draft-ietf-megaco-merged-= 01.txt
-----Original Message-----
From: Chris Rigano=20 [mailto:crigano@NORTELNETWORKS.COM]
Sent: Wednesday, = October 18,=20 2000 3:14 PM
To:=20 MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject:=20 H.248

What is the URL to get the most recient version of=20 H.248?

Best regards,

Chris

------_=_NextPart_001_01C039CE.B59486B0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 09:22:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA25585 for ; Thu, 19 Oct 2000 09:22:00 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7282@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:03:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29503 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 09:03:04 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7281@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:03:04 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA14398; Thu, 19 Oct 2000 09:18:14 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA04532; Thu, 19 Oct 2000 09:18:17 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRSAYF>; Thu, 19 Oct 2000 09:18:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E82E@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Oct 2000 09:18:15 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: About H.248 version engotiation X-To: Richie Wu To: MEGACO@STANDARDS.NORTELNETWORKS.COM The ServiceChange mechanism is the negotiation mechanism. The message header is indeed redundant, harmless, but is a "nice to have" feature. Brian > -----Original Message----- > From: Richie Wu [mailto:wuyongji@YAHOO.COM] > Sent: Thursday, October 19, 2000 12:47 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: About H.248 version engotiation > > > Hi all, > > I think there is redundant about the version > negotiation of H.248 message. Since there is a H.248 > version number in H.248 message header, why do we need > a version in serviceChange command? Because > ServiceChange command is included in message, so I > think it is useless and make processing become > complicate. > > Or there is different meaning between the two > versions? > > Best regards, > > Richie Wu > > > ===== > Huawei Technologies India Private Limited > > Unit 10, 2nd Floor, Innovator Block > International Tech Park, Whitefield Main Road > Bangalore 560 066, India > TEL: 0091-80-841 0061/0753/0755 > FAX: 0091-80-841 0063 > > __________________________________________________ > Do You Yahoo!? > Yahoo! Messenger - Talk while you surf! It's FREE. > http://im.yahoo.com/ > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 09:28:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26749 for ; Thu, 19 Oct 2000 09:27:59 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA72C0@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:08:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29577 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 09:08:24 -0400 Received: from mars.hss.co.in (202.54.26.197:58481) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA72BF@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:08:22 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9JDOBC22394 for ; Thu, 19 Oct 2000 18:54:13 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.00489315 ; Thu, 19 Oct 2000 18:42:42 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.0048915E.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 18:45:16 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Digit map descriptor Audit To: MEGACO@STANDARDS.NORTELNETWORKS.COM 7.2.5 AuditValue....specifies the following.... "DigitMapDescriptor returns the name or value of the current DigitMap for the Termination. DigitMap requested in an AuditValue command with TerminationID ALL returns all DigitMaps in the gateway." Since ALL termination id doesn't include ROOT "returns all DigitMaps in the gateway" should be rephrased to "returns all digitmaps on all terminations". Since "all digitmaps in the gateway" can never be audited in a single Audit command. It is also not specfied when to use digit map name in the response and when to use both name and value of the digit map. -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 09:28:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA26755 for ; Thu, 19 Oct 2000 09:28:00 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA72DC@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:09:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29612 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 09:09:38 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA72DB@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:09:37 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15010; Thu, 19 Oct 2000 09:24:48 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA06048; Thu, 19 Oct 2000 09:24:50 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVHTJB>; Thu, 19 Oct 2000 09:24:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E82F@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Oct 2000 09:24:49 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Missing/ Empty Audit Descriptor X-To: "knayar@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM A subtract command without Audit causes statistics to be sent A subtract command with an empty Audit causes statistics to be suppressed Any other command without an Audit results in no Audit information sent Any other command with an empty Audit results in no Audit information sent Perhaps 7.1.1 should have a note referencing 7.1.15 like "A missing Audit descriptor is equivalent to an empty Audit Descriptor (but see section 7.1.15)" Brian > -----Original Message----- > From: Kapil Nayar [mailto:knayar@HSS.HNS.COM] > Sent: Thursday, October 19, 2000 4:09 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Missing/ Empty Audit Descriptor > > > Hi > > The protocol document mentions: > > 7.1.1 Specifying Parameters > ... > "A missing Audit descriptor is equivalent to an empty Audit > Descriptor." > > and also > > 7.1.15 Statistics Descriptor > ... > "By default, statistics are reported when the Termination is > Subtracted from the > Context. This behavior can be overridden by including an > empty AuditDescriptor > in the Subtract command." > > Now, if Subtract command doesnot have an AuditDescriptor it > would mean that > there is an empty audit descriptor and no statistics would be > reported. And, if > the MGC needs termination statistics, it must send > AuditDescriptor with > Statistics token in the Subtract command. But this seems to change the > definition of "By default". > > Please clarify whether the above is correct. > > -Kapil Nayar > Hughes Software Systems > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 09:35:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27614 for ; Thu, 19 Oct 2000 09:35:17 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA734D@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:18:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29748 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 09:18:25 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA734C@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:18:24 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15923; Thu, 19 Oct 2000 09:33:35 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08406; Thu, 19 Oct 2000 09:33:35 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRSBFP>; Thu, 19 Oct 2000 09:33:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E830@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Oct 2000 09:33:30 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: wildcarded termination in Move X-To: CHAPRON Jean-Emmanuel FTRD/DAC/ISS To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA27614 I may be finessing the answer but Context=1{Subtract=T1.... Context=${Add=T1... gets you an equivalent Brian > -----Original Message----- > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > Sent: Thursday, October 19, 2000 5:02 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: wildcarded termination in Move > > > Hello Brian, all > > If things are left as they are, it seems that the case > described below is > simply impossible: > > (1) > | +-------------------------------------------------+ | > | |Context C1 | | > | | +-------------+ +-------------+ | | > | | | (Term. T1) | +-----+ | (Term. T2) | | | > <-+--->| RTP Stream |---| * |------| RTP Stream > |<---+-> > | | +-------------+ +-----+ +-------------+ | | > | +-------------------------------------------------+ | > (2) > > | +-------------------------------------------------+ | > | |Context C1 | | > | | +-------------+ > | | > | | | (Term. T1) | +-----+ | | > <-+--->| RTP Stream |---| * | | | > | | +-------------+ +-----+ | | > | +-------------------------------------------------+ | > | +-------------------------------------------------+ | > | |Context C2 | | > | | +-------------+ | | > | | +-----+ | (Term. T2) | | | > | | | * |------| RTP Stream > |<---+-> > | | +-----+ +-------------+ | | > | +-------------------------------------------------+ | > > > C2 didn't exist in (1). How to go from (1) to (2)? > - We can't use a MOVE $ (too bad..) > - we can't use Context = $ {Add = T2} because T2 is in a > non-NULL context > - we can't use "Subtract/Add" because we have only RTP > Terminations we don't > want to remove. > > This is not a textbook case, as far as this case may occur if the Call > Server/MGC is connected to the IN and receives, for instance, an INAP > "SplitLeg" message requiring such an handling of connections. > > Regards, > > > ``` > (o o) > ----------oOO--(_)-OOo-------------- > Jean-Emmanuel CHAPRON > FRANCE TELECOM R&D > DAC/ACE > 38-40 rue du général Leclerc > 92794 Issy-les-Moulineaux Cedex 9 - France > Tel: +33 1 45 29 64 50 > ------------------------------------- > > > > > -----Message d'origine----- > > De : Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > Envoyé : mercredi 18 octobre 2000 15:01 > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > Objet : Re: wildcarded termination in Move > > > > > > Ya, that's one of the reasons it's probably there - separating > > functions of Move and Add. > > > > Probably best to leave things as they are. > > > > Brian > > > > > -----Original Message----- > > > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > > > Sent: Wednesday, October 18, 2000 8:29 AM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > Hi > > > > > > If you remove this restriction then why you need Move, i will > > > always use Add to > > > either: > > > 1. Add a termination to a context from null context > > > 2. Move (read it as Add) a termination to a context from a > > > non-NULL context. > > > > > > -Kapil Nayar > > > Hughes Software Systems > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/18/2000 05:31:06 PM > > > > > > Please respond to "Rosen, Brian" > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Kapil Nayar/HSS) > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > Only Add can create a new context: > > > "In general, an Add command is used to add Terminations > > to Contexts. > > > If the MGC does not specify an existing Context to which the > > > Termination is to be added, the MG creates a new Context. " > > > > > > A way to do the consultation hold is to create the new > context with > > > C and move A to that Context. > > > > > > I'll note that I was a little surprised to read: > > > "The Termination is either created, or taken from the > null Context" > > > (although I may have wrote it!), since this prohibits an Add of > > > a termination already in another context. I'm not sure why we > > > prohibit that. I do think there is little practical difficulty in > > > keeping that restriction. If we did relax that restriction, you > > > could do Context=${Add=A{.... > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > > > Sent: Wednesday, October 18, 2000 12:40 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > Hi Brian, > > > > > > > > If you mean to say that Move with ContextID = $ is > > > > nonsensical --- I beg to > > > > differ...... > > > > > > > > Consider a simple call scenario -- A is talking to B..... and > > > > now A wants to put > > > > B on hold and call up C......The simplest way to do it as per > > > > my understanding > > > > would be -- MGC shall tell MG to Move A to a new context > > > > (Move - ContextID=$ and > > > > TermID = A) where it shall talk to C, and once it is done, > > > > move it back to the > > > > context where it was talking to B...... > > > > > > > > What is your opinion about this.... > > > > > > > > Thanks > > > > Chanchal.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 > 05:57:41 PM > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > If there are three terminations in an MG > > > > > abcd > > > > > abce > > > > > xyz. > > > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > > > NULL Context. > > > > > If MGC says Move with ContextID = $ and termination as abc*, > > > > > what should the > > > > > MG do > > > > First of all, I think this is illegal, or at least nonsensical. > > > > You CAN'T create a new contextId with CHOOSE. > > > > So if it is legal, you are asking for Russian Roulette - pick > > > > a context where the resulting command would be legal, and do it. > > > > If there is more than one, then it's random which one > > > > > > > > > 1. Consider abce while resolving wildcarded abc* - > > > > > Move is valid for abcd (it's in non-NULL context) and > > invalid for > > > > > abce (move is not allowed to move from and to a NULL Context) > > > > abcd is valid, abce is not valid > > > > > > > > > 2. Don't consider terminations in NULL Context for resolving > > > > > wildcard since > > > > > the basic idea is not to Move to or from NULL Context. > > > > This is correct > > > > > > > > > > > > > > The first option has an impact on further commands in the > > > > > transaction since a > > > > > failure > > > > > with one command can cause the side effect of other commands > > > > > being not executed. > > > > True, but in general if the MGC was foolish enough to do this, > > > > it deserves what it gets. > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 09:35:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27618 for ; Thu, 19 Oct 2000 09:35:19 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7359@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:19:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29762 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 09:19:02 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7358@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:19:02 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA15985; Thu, 19 Oct 2000 09:34:13 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA08734; Thu, 19 Oct 2000 09:34:15 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRSBHP>; Thu, 19 Oct 2000 09:34:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E831@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Oct 2000 09:34:09 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Modify the service state property X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'd say yes, but I'd recommend not doing it that way. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Thursday, October 19, 2000 7:01 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Modify the service state property > > > Is the changing of ServiceState of a termination > directly from inservice to outofservice and > vice-versa allowed in say a Modify? > > Is this equivalent in functional operation to a ServiceChange > on that termination? > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 09:42:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA28521 for ; Thu, 19 Oct 2000 09:42:16 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA738E@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:25:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29830 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 09:25:09 -0400 Received: from mars.hss.co.in (202.54.26.197:58612) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA738D@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:25:04 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9JDegC22590 for ; Thu, 19 Oct 2000 19:10:51 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.004A178E ; Thu, 19 Oct 2000 18:59:16 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.004A14F4.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 19:04:41 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Re: Modify the service state property To: MEGACO@STANDARDS.NORTELNETWORKS.COM I believe that the ServiceState values outofservice and inservice are not settable directly my MGC and only indicate the current state that can be modified using SerivceChange. This seems to make ServiceState property as "read-only" type for these two values. But then what about "test" value ? -Madhubabu "Rosen, Brian" on 10/19/2000 07:04:09 PM To: Madhu B Babu/HSS@HSS, MEGACO@STANDARDS.NORTELNETWORKS.COM cc: Subject: RE: Modify the service state property I'd say yes, but I'd recommend not doing it that way. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Thursday, October 19, 2000 7:01 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Modify the service state property > > > Is the changing of ServiceState of a termination > directly from inservice to outofservice and > vice-versa allowed in say a Modify? > > Is this equivalent in functional operation to a ServiceChange > on that termination? > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 09:46:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA29031 for ; Thu, 19 Oct 2000 09:46:31 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA73A8@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:29:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29863 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 09:29:29 -0400 Received: from mars.hss.co.in (202.54.26.197:58641) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA73A7@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:29:26 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9JDjBC22650 for ; Thu, 19 Oct 2000 19:15:14 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.004A7EDF ; Thu, 19 Oct 2000 19:03:41 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.004A7CED.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 19:09:07 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: payload change. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Say multiple codecs are reserved for a given termination through reserve properties. If media starts using one codec and MGC has not released the other codecs, now if MG encounters change of payload the "payload transition" event is generated. Apart from generating the event is the intention here is that MG by itself will switch the codec if it is in the list of reserved codecs? -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 09:57:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00377 for ; Thu, 19 Oct 2000 09:57:03 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA73FC@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:40:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29879 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 09:40:16 -0400 Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA73B5@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:30:15 -0400 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Oct 2000 15:45:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <98388C05D464D111B61800805F150416014858C2@p-ibis.issy.cnet.fr> Date: Thu, 19 Oct 2000 15:45:06 +0200 Reply-To: CHAPRON Jean-Emmanuel FTRD/DAC/ISS Sender: "Media Gateway Control (megaco)" From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS Subject: Re: wildcarded termination in Move To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id JAA00377 I don't understand your solution: T1 is an ephemeral Termination: its TermID is not provisionned in the MG. As soon as T1 is subtracted from C1, it disappears, and its TermID too. How can the MGC re-use this TermID to add it to a new Context? Can the MGC set the TermID of an ephemeral Termination when it creates it? ``` (o o) ----------oOO--(_)-OOo-------------- Jean-Emmanuel CHAPRON FRANCE TELECOM R&D DAC/ACE 38-40 rue du général Leclerc 92794 Issy-les-Moulineaux Cedex 9 - France Tel: +33 1 45 29 64 50 ------------------------------------- > -----Message d'origine----- > De : Rosen, Brian [mailto:Brian.Rosen@marconi.com] > Envoyé : jeudi 19 octobre 2000 15:34 > À : 'CHAPRON Jean-Emmanuel FTRD/DAC/ISS'; > MEGACO@STANDARDS.NORTELNETWORKS.COM > Objet : RE: wildcarded termination in Move > > > I may be finessing the answer but > Context=1{Subtract=T1.... > Context=${Add=T1... > gets you an equivalent > > Brian > > > -----Original Message----- > > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > > Sent: Thursday, October 19, 2000 5:02 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: wildcarded termination in Move > > > > > > Hello Brian, all > > > > If things are left as they are, it seems that the case > > described below is > > simply impossible: > > > > (1) > > | > +-------------------------------------------------+ | > > | |Context C1 > | | > > | | +-------------+ > +-------------+ | | > > | | | (Term. T1) | +-----+ | (Term. > T2) | | | > > <-+--->| RTP Stream |---| * |------| RTP Stream > > |<---+-> > > | | +-------------+ +-----+ > +-------------+ | | > > | > +-------------------------------------------------+ | > > (2) > > > > | > +-------------------------------------------------+ | > > | |Context C1 > | | > > | | +-------------+ > > | | > > | | | (Term. T1) | +-----+ > | | > > <-+--->| RTP Stream |---| * | > | | > > | | +-------------+ +-----+ > | | > > | > +-------------------------------------------------+ | > > | > +-------------------------------------------------+ | > > | |Context C2 > | | > > | | > +-------------+ | | > > | | +-----+ | (Term. > T2) | | | > > | | | * |------| RTP Stream > > |<---+-> > > | | +-----+ > +-------------+ | | > > | > +-------------------------------------------------+ | > > > > > > C2 didn't exist in (1). How to go from (1) to (2)? > > - We can't use a MOVE $ (too bad..) > > - we can't use Context = $ {Add = T2} because T2 is in a > > non-NULL context > > - we can't use "Subtract/Add" because we have only RTP > > Terminations we don't > > want to remove. > > > > This is not a textbook case, as far as this case may occur > if the Call > > Server/MGC is connected to the IN and receives, for > instance, an INAP > > "SplitLeg" message requiring such an handling of connections. > > > > Regards, > > > > > > ``` > > (o o) > > ----------oOO--(_)-OOo-------------- > > Jean-Emmanuel CHAPRON > > FRANCE TELECOM R&D > > DAC/ACE > > 38-40 rue du général Leclerc > > 92794 Issy-les-Moulineaux Cedex 9 - France > > Tel: +33 1 45 29 64 50 > > ------------------------------------- > > > > > > > > > -----Message d'origine----- > > > De : Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > Envoyé : mercredi 18 octobre 2000 15:01 > > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Objet : Re: wildcarded termination in Move > > > > > > > > > Ya, that's one of the reasons it's probably there - separating > > > functions of Move and Add. > > > > > > Probably best to leave things as they are. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > > > > Sent: Wednesday, October 18, 2000 8:29 AM > > > > To: Rosen, Brian > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > If you remove this restriction then why you need Move, i will > > > > always use Add to > > > > either: > > > > 1. Add a termination to a context from null context > > > > 2. Move (read it as Add) a termination to a context from a > > > > non-NULL context. > > > > > > > > -Kapil Nayar > > > > Hughes Software Systems > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/18/2000 > 05:31:06 PM > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Kapil Nayar/HSS) > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > Only Add can create a new context: > > > > "In general, an Add command is used to add Terminations > > > to Contexts. > > > > If the MGC does not specify an existing Context to which the > > > > Termination is to be added, the MG creates a new Context. " > > > > > > > > A way to do the consultation hold is to create the new > > context with > > > > C and move A to that Context. > > > > > > > > I'll note that I was a little surprised to read: > > > > "The Termination is either created, or taken from the > > null Context" > > > > (although I may have wrote it!), since this prohibits an Add of > > > > a termination already in another context. I'm not sure why we > > > > prohibit that. I do think there is little practical > difficulty in > > > > keeping that restriction. If we did relax that restriction, you > > > > could do Context=${Add=A{.... > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > > > > Sent: Wednesday, October 18, 2000 12:40 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > Hi Brian, > > > > > > > > > > If you mean to say that Move with ContextID = $ is > > > > > nonsensical --- I beg to > > > > > differ...... > > > > > > > > > > Consider a simple call scenario -- A is talking to B..... and > > > > > now A wants to put > > > > > B on hold and call up C......The simplest way to do it as per > > > > > my understanding > > > > > would be -- MGC shall tell MG to Move A to a new context > > > > > (Move - ContextID=$ and > > > > > TermID = A) where it shall talk to C, and once it is done, > > > > > move it back to the > > > > > context where it was talking to B...... > > > > > > > > > > What is your opinion about this.... > > > > > > > > > > Thanks > > > > > Chanchal.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 > > 05:57:41 PM > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > > If there are three terminations in an MG > > > > > > abcd > > > > > > abce > > > > > > xyz. > > > > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > > > > NULL Context. > > > > > > If MGC says Move with ContextID = $ and termination as abc*, > > > > > > what should the > > > > > > MG do > > > > > First of all, I think this is illegal, or at least > nonsensical. > > > > > You CAN'T create a new contextId with CHOOSE. > > > > > So if it is legal, you are asking for Russian Roulette - pick > > > > > a context where the resulting command would be legal, > and do it. > > > > > If there is more than one, then it's random which one > > > > > > > > > > > 1. Consider abce while resolving wildcarded abc* - > > > > > > Move is valid for abcd (it's in non-NULL context) and > > > invalid for > > > > > > abce (move is not allowed to move from and to a > NULL Context) > > > > > abcd is valid, abce is not valid > > > > > > > > > > > 2. Don't consider terminations in NULL Context for resolving > > > > > > wildcard since > > > > > > the basic idea is not to Move to or from NULL Context. > > > > > This is correct > > > > > > > > > > > > > > > > > The first option has an impact on further commands in the > > > > > > transaction since a > > > > > > failure > > > > > > with one command can cause the side effect of other commands > > > > > > being not executed. > > > > > True, but in general if the MGC was foolish enough to do this, > > > > > it deserves what it gets. > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 09:57:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA00383 for ; Thu, 19 Oct 2000 09:57:05 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7411@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:41:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 29985 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 09:41:40 -0400 Received: from mars.hss.co.in (202.54.26.197:58756) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA740E@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:41:37 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9JDvOC22800 for ; Thu, 19 Oct 2000 19:27:28 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.004B9DE7 ; Thu, 19 Oct 2000 19:15:56 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.004B9D06.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 19:21:25 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Statistics To: MEGACO@STANDARDS.NORTELNETWORKS.COM Section E.12.4 states that statistics like jitter, packet loss,etc are described on an RTP stream. If only one RTP stream is present on a termination its straitforward to send statistics. But if multiple streams are created on a termination How this reporting is done? -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 10:04:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01307 for ; Thu, 19 Oct 2000 10:04:24 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7433@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:47:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30029 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 09:47:33 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7432@standards.nortelnetworks.com>; Thu, 19 Oct 2000 9:47:32 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA18904; Thu, 19 Oct 2000 10:02:43 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA16029; Thu, 19 Oct 2000 10:02:45 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVH4PS>; Thu, 19 Oct 2000 10:02:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E832@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Oct 2000 10:02:42 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: wildcarded termination in Move X-To: CHAPRON Jean-Emmanuel FTRD/DAC/ISS To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id KAA01307 Woops, sorry, didn't pay close enough attention. Your example has TWO RTP streams and no physical terminations. Unusual, but legal. Well, I'm stuck. I can think of stupid things to do, but nothing that looks useful. Maybe a change is warranted. Need other opinions on allowing Context=${Move=... Brian > -----Original Message----- > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > Sent: Thursday, October 19, 2000 9:45 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: wildcarded termination in Move > > > I don't understand your solution: T1 is an ephemeral > Termination: its TermID > is not provisionned in the MG. As soon as T1 is subtracted from C1, it > disappears, and its TermID too. How can the MGC re-use this > TermID to add it > to a new Context? > Can the MGC set the TermID of an ephemeral Termination when > it creates it? > > > ``` > (o o) > ----------oOO--(_)-OOo-------------- > Jean-Emmanuel CHAPRON > FRANCE TELECOM R&D > DAC/ACE > 38-40 rue du général Leclerc > 92794 Issy-les-Moulineaux Cedex 9 - France > Tel: +33 1 45 29 64 50 > ------------------------------------- > > > > > -----Message d'origine----- > > De : Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Envoyé : jeudi 19 octobre 2000 15:34 > > À : 'CHAPRON Jean-Emmanuel FTRD/DAC/ISS'; > > MEGACO@STANDARDS.NORTELNETWORKS.COM > > Objet : RE: wildcarded termination in Move > > > > > > I may be finessing the answer but > > Context=1{Subtract=T1.... > > Context=${Add=T1... > > gets you an equivalent > > > > Brian > > > > > -----Original Message----- > > > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > > > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > > > Sent: Thursday, October 19, 2000 5:02 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: wildcarded termination in Move > > > > > > > > > Hello Brian, all > > > > > > If things are left as they are, it seems that the case > > > described below is > > > simply impossible: > > > > > > (1) > > > | > > +-------------------------------------------------+ | > > > | |Context C1 > > | | > > > | | +-------------+ > > +-------------+ | | > > > | | | (Term. T1) | +-----+ | (Term. > > T2) | | | > > > <-+--->| RTP Stream |---| * |------| RTP Stream > > > |<---+-> > > > | | +-------------+ +-----+ > > +-------------+ | | > > > | > > +-------------------------------------------------+ | > > > (2) > > > > > > | > > +-------------------------------------------------+ | > > > | |Context C1 > > | | > > > | | +-------------+ > > > | | > > > | | | (Term. T1) | +-----+ > > | | > > > <-+--->| RTP Stream |---| * | > > | | > > > | | +-------------+ +-----+ > > | | > > > | > > +-------------------------------------------------+ | > > > | > > +-------------------------------------------------+ | > > > | |Context C2 > > | | > > > | | > > +-------------+ | | > > > | | +-----+ | (Term. > > T2) | | | > > > | | | * |------| RTP Stream > > > |<---+-> > > > | | +-----+ > > +-------------+ | | > > > | > > +-------------------------------------------------+ | > > > > > > > > > C2 didn't exist in (1). How to go from (1) to (2)? > > > - We can't use a MOVE $ (too bad..) > > > - we can't use Context = $ {Add = T2} because T2 is in a > > > non-NULL context > > > - we can't use "Subtract/Add" because we have only RTP > > > Terminations we don't > > > want to remove. > > > > > > This is not a textbook case, as far as this case may occur > > if the Call > > > Server/MGC is connected to the IN and receives, for > > instance, an INAP > > > "SplitLeg" message requiring such an handling of connections. > > > > > > Regards, > > > > > > > > > ``` > > > (o o) > > > ----------oOO--(_)-OOo-------------- > > > Jean-Emmanuel CHAPRON > > > FRANCE TELECOM R&D > > > DAC/ACE > > > 38-40 rue du général Leclerc > > > 92794 Issy-les-Moulineaux Cedex 9 - France > > > Tel: +33 1 45 29 64 50 > > > ------------------------------------- > > > > > > > > > > > > > -----Message d'origine----- > > > > De : Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > > Envoyé : mercredi 18 octobre 2000 15:01 > > > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Objet : Re: wildcarded termination in Move > > > > > > > > > > > > Ya, that's one of the reasons it's probably there - separating > > > > functions of Move and Add. > > > > > > > > Probably best to leave things as they are. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > > > > > Sent: Wednesday, October 18, 2000 8:29 AM > > > > > To: Rosen, Brian > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > If you remove this restriction then why you need Move, i will > > > > > always use Add to > > > > > either: > > > > > 1. Add a termination to a context from null context > > > > > 2. Move (read it as Add) a termination to a context from a > > > > > non-NULL context. > > > > > > > > > > -Kapil Nayar > > > > > Hughes Software Systems > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/18/2000 > > 05:31:06 PM > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > cc: (bcc: Kapil Nayar/HSS) > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > Only Add can create a new context: > > > > > "In general, an Add command is used to add Terminations > > > > to Contexts. > > > > > If the MGC does not specify an existing Context to > which the > > > > > Termination is to be added, the MG creates a new > Context. " > > > > > > > > > > A way to do the consultation hold is to create the new > > > context with > > > > > C and move A to that Context. > > > > > > > > > > I'll note that I was a little surprised to read: > > > > > "The Termination is either created, or taken from the > > > null Context" > > > > > (although I may have wrote it!), since this prohibits > an Add of > > > > > a termination already in another context. I'm not sure why we > > > > > prohibit that. I do think there is little practical > > difficulty in > > > > > keeping that restriction. If we did relax that > restriction, you > > > > > could do Context=${Add=A{.... > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > > > > > Sent: Wednesday, October 18, 2000 12:40 AM > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > Hi Brian, > > > > > > > > > > > > If you mean to say that Move with ContextID = $ is > > > > > > nonsensical --- I beg to > > > > > > differ...... > > > > > > > > > > > > Consider a simple call scenario -- A is talking to > B..... and > > > > > > now A wants to put > > > > > > B on hold and call up C......The simplest way to do > it as per > > > > > > my understanding > > > > > > would be -- MGC shall tell MG to Move A to a new context > > > > > > (Move - ContextID=$ and > > > > > > TermID = A) where it shall talk to C, and once it is done, > > > > > > move it back to the > > > > > > context where it was talking to B...... > > > > > > > > > > > > What is your opinion about this.... > > > > > > > > > > > > Thanks > > > > > > Chanchal.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 > > > 05:57:41 PM > > > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If there are three terminations in an MG > > > > > > > abcd > > > > > > > abce > > > > > > > xyz. > > > > > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > > > > > NULL Context. > > > > > > > If MGC says Move with ContextID = $ and > termination as abc*, > > > > > > > what should the > > > > > > > MG do > > > > > > First of all, I think this is illegal, or at least > > nonsensical. > > > > > > You CAN'T create a new contextId with CHOOSE. > > > > > > So if it is legal, you are asking for Russian > Roulette - pick > > > > > > a context where the resulting command would be legal, > > and do it. > > > > > > If there is more than one, then it's random which one > > > > > > > > > > > > > 1. Consider abce while resolving wildcarded abc* - > > > > > > > Move is valid for abcd (it's in non-NULL context) and > > > > invalid for > > > > > > > abce (move is not allowed to move from and to a > > NULL Context) > > > > > > abcd is valid, abce is not valid > > > > > > > > > > > > > 2. Don't consider terminations in NULL Context > for resolving > > > > > > > wildcard since > > > > > > > the basic idea is not to Move to or from NULL Context. > > > > > > This is correct > > > > > > > > > > > > > > > > > > > > The first option has an impact on further commands in the > > > > > > > transaction since a > > > > > > > failure > > > > > > > with one command can cause the side effect of > other commands > > > > > > > being not executed. > > > > > > True, but in general if the MGC was foolish enough > to do this, > > > > > > it deserves what it gets. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 10:21:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA04594 for ; Thu, 19 Oct 2000 10:21:18 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7459@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:04:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30075 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 10:04:28 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7458@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:04:28 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20757; Thu, 19 Oct 2000 10:19:38 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id KAA20289; Thu, 19 Oct 2000 10:19:41 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRSCMY>; Thu, 19 Oct 2000 10:19:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E833@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Oct 2000 10:19:38 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Statistics X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Oh cool. I don't think we have ever talked about this, stream specific statistics! Hmmmmm. So we would want to add (an optional) StreamId to Statistics Descriptor Statistics=1{rtp/pr=.... and you might get more than one Statistics descriptor in the reply. Wow. This is a real bug in the protocol I think! Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Thursday, October 19, 2000 9:51 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Statistics > > > Section E.12.4 states that statistics like > jitter, packet loss,etc are described on an > RTP stream. If only one RTP stream is > present on a termination its straitforward > to send statistics. But if multiple streams > are created on a termination How this > reporting is done? > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 10:25:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05131 for ; Thu, 19 Oct 2000 10:25:54 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7476@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:06:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30110 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 10:06:52 -0400 Received: from mail-dns1-nj.dialogic.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7475@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:06:52 -0400 Received: from mail4.dialogic.com ([146.152.6.40]) by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: dialogic.m4,v 1.3 2000/05/05 13:56:23 dmccart Exp $) with ESMTP id OAA14455 for ; Thu, 19 Oct 2000 14:26:09 GMT Received: from exchange3nj.dialogic.com (mailnj.dialogic.com [146.152.3.18]) by mail4.dialogic.com (8.9.3+Sun/8.9.3) with ESMTP id KAA10342 for ; Thu, 19 Oct 2000 10:21:59 -0400 (EDT) Received: by mailnj.dialogic.com with Internet Mail Service (5.5.2650.21) id <4Y7P7JSV>; Thu, 19 Oct 2000 10:21:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 19 Oct 2000 10:14:59 -0400 Reply-To: "Rupsis, Paul" Sender: "Media Gateway Control (megaco)" From: "Rupsis, Paul" Subject: Re: H248 Implementors' Guide Draft v3 To: MEGACO@STANDARDS.NORTELNETWORKS.COM It would also be nice if the Implementor's Guide was on the IETF site http://www.ietf.org/html.charters/megaco-charter.html Paul Rupsis -----Original Message----- From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] Sent: Thursday, October 19, 2000 1:07 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: H248 Implementors' Guide Draft v3 G'Day all, Attached is a copy of the H.248 Implementors' Guide v3. It "hopefully" contains the corrections and clarifications that have been discussed on the Megaco mailing list until the 19/10/2000. If anything is missed or erroneous please let me (and the list) know. The file will also be upload to the pictel server: ftp://standard.pictel.com/avc-site/incoming/H248_Implementors_Guide_v3.zip Both PDF and Word versions are available. My intention is to make one more update (v4) before sending to the Nov Sg16 meeting for approval. Cheers, Christian PS: Please forgive me sending a 98k file to the list but the Pictel server has been down. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 10:25:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA05137 for ; Thu, 19 Oct 2000 10:25:55 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA747D@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:07:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30120 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 10:07:18 -0400 Received: from mars.hss.co.in (202.54.26.197:59002) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA747B@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:07:16 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9JENAC23084 for ; Thu, 19 Oct 2000 19:53:11 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.004DFA91 ; Thu, 19 Oct 2000 19:41:44 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.004DF961.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 19:47:12 +0530 Reply-To: samittal@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Sachin Mittal Subject: Local / Remote for physical termination To: MEGACO@STANDARDS.NORTELNETWORKS.COM In section 7.1.8 its mentioned that "Local refers to the media received by the MG and Remote refers to the media sent by the MG". Is there any significance for the local and remote descriptors in case of physical termination? Local and remote seems to define the media flow for PDN rather than SCN. -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 10:41:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA07042 for ; Thu, 19 Oct 2000 10:41:41 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA74F1@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:24:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30260 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 10:24:47 -0400 Received: from hvmta01-stg.us.psimail.psi.net (hvmta01-ext.us.psimail.psi.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA74F0@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:24:46 -0400 Received: from dev_4 ([38.150.216.6]) by hvmta01-stg.us.psimail.psi.net (InterMail v4.01.01.00 201-229-111) with SMTP id <20001019143959.OTRN1216.hvmta01-stg@dev_4> for ; Thu, 19 Oct 2000 10:39:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal Message-ID: <002401c039da$725a2ce0$70d8a8c0@dev_4.us.radvision.com> Date: Thu, 19 Oct 2000 10:39:55 -0400 Reply-To: delbert@radvision.com Sender: "Media Gateway Control (megaco)" From: Dan Elbert Subject: Acodec vs RTPPayload To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit In C.1. (General Media Attributes) , what is the difference between Acodec and RTPPayload ? DOn't they give the same information ? Dan Elbert RADVISION From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 10:54:16 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08509 for ; Thu, 19 Oct 2000 10:54:16 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA753E@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:37:32 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30353 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 10:37:32 -0400 Received: from mars.hss.co.in (202.54.26.197:59194) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA753D@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:37:30 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9JErPC23379 for ; Thu, 19 Oct 2000 20:23:25 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.0050BCF4 ; Thu, 19 Oct 2000 20:11:52 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.0050BBAA.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 20:17:20 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: duration. To: MEGACO@STANDARDS.NORTELNETWORKS.COM In Section E.11.4 its mentioned that Duration statisticsID "provides duration of time the termination has been in the context". What is the significance of adding this in statistics, because MGC is the one which had added and subtracted the termination from context. Is there any other purpose for this statisticsId? -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 11:04:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA09726 for ; Thu, 19 Oct 2000 11:04:21 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7566@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:47:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30403 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 10:47:33 -0400 Received: from qhars002.nortel.com (47.101.112.102:42529) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7565@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:47:33 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Thu, 19 Oct 2000 16:02:24 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Thu, 19 Oct 2000 09:57:39 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Thu, 19 Oct 2000 09:57:36 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD110250C5D5@zcard00g.ca.nortel.com> Date: Thu, 19 Oct 2000 09:57:26 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Meeting In San Diego? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Does Megaco need meeting time in San Diego? The only official WG work item outstanding is the MIB -- I'm about to announce progression on the NAS package and the IPPhone profile. On the other hand, we are getting a number of other packages, and we'll have results from the November SG 16 meeting to consider. Tom From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 11:08:18 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10176 for ; Thu, 19 Oct 2000 11:08:18 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7587@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:49:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30444 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 10:49:53 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7586@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:49:52 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25445; Thu, 19 Oct 2000 11:05:03 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04071; Thu, 19 Oct 2000 11:05:06 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRS11A>; Thu, 19 Oct 2000 11:04:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E83A@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Oct 2000 11:05:03 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: duration. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Carriers often care to know PRECISELY how much time the call took. There can be delays from when the MGC sends a command, and the MG acts on it. There was a requirement for this in the protocol requirements, and this meets it. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Thursday, October 19, 2000 10:47 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: duration. > > > In Section E.11.4 its mentioned that > Duration statisticsID "provides duration of time the > termination has been in the context". What is the significance of > adding this in statistics, because MGC is the one which > had added and subtracted the termination from context. > Is there any other purpose for this statisticsId? > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 11:08:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10180 for ; Thu, 19 Oct 2000 11:08:18 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA75A0@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:52:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30475 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 10:52:50 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA759F@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:52:50 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA25661; Thu, 19 Oct 2000 11:08:00 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA04908; Thu, 19 Oct 2000 11:08:02 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVHW89>; Thu, 19 Oct 2000 11:07:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E83B@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Oct 2000 11:08:00 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Meeting In San Diego? X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'd say yes: I think we want to discuss rechartering I think we want to discuss packages There is a report on interop testing, and an announcement (I hope) of the next one. Brian > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Thursday, October 19, 2000 10:57 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Meeting In San Diego? > > > Does Megaco need meeting time in San Diego? The only > official WG work item > outstanding is the MIB -- I'm about to announce progression on the NAS > package and the IPPhone profile. On the other hand, we are > getting a number > of other packages, and we'll have results from the November > SG 16 meeting to > consider. > > Tom > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 11:13:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA10800 for ; Thu, 19 Oct 2000 11:13:41 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA75CC@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:56:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30533 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 10:56:47 -0400 Received: from mars.hss.co.in (202.54.26.197:59325) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA75CB@standards.nortelnetworks.com>; Thu, 19 Oct 2000 10:56:45 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9JFCdC23594 for ; Thu, 19 Oct 2000 20:42:40 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697D.00528272 ; Thu, 19 Oct 2000 20:31:13 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697D.005280A0.00@sandesh.hss.hns.com> Date: Thu, 19 Oct 2000 20:36:39 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Re: duration. To: MEGACO@STANDARDS.NORTELNETWORKS.COM How the octets sent and received are calculated for physical termination if network package is realized on it? -Madhubabu "Rosen, Brian" on 10/19/2000 08:35:03 PM To: Madhu B Babu/HSS@HSS, MEGACO@STANDARDS.NORTELNETWORKS.COM cc: Subject: RE: duration. Carriers often care to know PRECISELY how much time the call took. There can be delays from when the MGC sends a command, and the MG acts on it. There was a requirement for this in the protocol requirements, and this meets it. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Thursday, October 19, 2000 10:47 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: duration. > > > In Section E.11.4 its mentioned that > Duration statisticsID "provides duration of time the > termination has been in the context". What is the significance of > adding this in statistics, because MGC is the one which > had added and subtracted the termination from context. > Is there any other purpose for this statisticsId? > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 11:24:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA12168 for ; Thu, 19 Oct 2000 11:24:01 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA75F1@standards.nortelnetworks.com>; Thu, 19 Oct 2000 11:07:03 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30580 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 11:07:03 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA75F0@standards.nortelnetworks.com>; Thu, 19 Oct 2000 11:07:03 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA27073; Thu, 19 Oct 2000 11:22:13 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id LAA09159; Thu, 19 Oct 2000 11:22:16 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRS1Y2>; Thu, 19 Oct 2000 11:22:05 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E83C@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Oct 2000 11:22:14 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: duration. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM bytes of PCM? Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Thursday, October 19, 2000 11:07 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: duration. > > > How the octets sent and received are calculated for physical > termination if > network package is realized on it? > -Madhubabu > > > > > "Rosen, Brian" on 10/19/2000 08:35:03 PM > > To: Madhu B Babu/HSS@HSS, MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: > > Subject: RE: duration. > > > > > Carriers often care to know PRECISELY how much time the call took. > There can be delays from when the MGC sends a command, and the > MG acts on it. There was a requirement for this in the protocol > requirements, and this meets it. > > Brian > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Thursday, October 19, 2000 10:47 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: duration. > > > > > > In Section E.11.4 its mentioned that > > Duration statisticsID "provides duration of time the > > termination has been in the context". What is the significance of > > adding this in statistics, because MGC is the one which > > had added and subtracted the termination from context. > > Is there any other purpose for this statisticsId? > > > > -Madhubabu > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 11:48:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA15067 for ; Thu, 19 Oct 2000 11:48:33 -0400 (EDT) Received: from standards (47.234.32.16:3761) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA762B@standards.nortelnetworks.com>; Thu, 19 Oct 2000 11:31:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30645 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 11:31:46 -0400 Received: from aifhs8.alcatel.fr (una104.alcatel.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7624@standards.nortelnetworks.com>; Thu, 19 Oct 2000 11:21:45 -0400 Received: from frmta003.netfr.alcatel.fr (frmta003.netfr.alcatel.fr [155.132.251.32]) by aifhs8.alcatel.fr (ALCANET/SMTP2) with SMTP id RAA24291 for ; Thu, 19 Oct 2000 17:36:55 +0200 (MET DST) Received: by frmta003.netfr.alcatel.fr(Lotus SMTP MTA v4.6.7 (934.1 12-30-1999)) id C125697D.0055A705 ; Thu, 19 Oct 2000 17:35:33 +0200 X-Lotus-FromDomain: ALCATEL Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Message-ID: Date: Thu, 19 Oct 2000 17:09:31 +0200 Reply-To: Fabien.Capoen@ALCATEL.FR Sender: "Media Gateway Control (megaco)" From: Fabien Capoen Subject: Re: wildcarded termination in Move X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id LAA15067 If I can dare to speak on this list ... (to introduce myself, I work on 'NGN' standards for alcatel), on this subject I have the following thoughts: - there needs to be a mean (for a service as simple as call holding) to temporarily 'separate' terminations being in the same context whatever their nature (physical/ephemeral) - the 'Context=${Move=' solution seems the only one (we could think of 2 other ones: the first to allow add on terminations being in a not null context, but this one has already been rejected because it breaks the add/move complementarity - move becomes just a special case of add; the second being a special NULL-like context: the ONHOLD context, for ephemeral terminations. This one is not very elegant) - the 'Context=${Move=' solution does not break the add/move complementarity: add remains reserved for non existing terminations or terminations in the null context, whereas move is reserved for terminations in a not null context - I have looked in the standard, and I could not see it explicitely forbidden. The only thing is that it is not explicitely allowed: in §6.1, the creation of a new context is only described for the add command. Changing 'In general, an Add command is used to add Terminations to Contexts' of §6.1 into 'In general, an Add OR MOVE command is used to add Terminations to Contexts' could solve the problem. And really, isn't it true to say that move also adds terminations to a context ? Isn't the only difference between move and add on the nature of the termination on which the add/move is applied ? The question I have is then: what concrete problems do people see with allowing 'context=$' in a move request ? Regards ... Fabien C. Please respond to "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Fabien CAPOEN/FR/ALCATEL) Subject: Re: wildcarded termination in Move Woops, sorry, didn't pay close enough attention. Your example has TWO RTP streams and no physical terminations. Unusual, but legal. Well, I'm stuck. I can think of stupid things to do, but nothing that looks useful. Maybe a change is warranted. Need other opinions on allowing Context=${Move=... Brian > -----Original Message----- > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > Sent: Thursday, October 19, 2000 9:45 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: wildcarded termination in Move > > > I don't understand your solution: T1 is an ephemeral > Termination: its TermID > is not provisionned in the MG. As soon as T1 is subtracted from C1, it > disappears, and its TermID too. How can the MGC re-use this > TermID to add it > to a new Context? > Can the MGC set the TermID of an ephemeral Termination when > it creates it? > > > ``` > (o o) > ----------oOO--(_)-OOo-------------- > Jean-Emmanuel CHAPRON > FRANCE TELECOM R&D > DAC/ACE > 38-40 rue du général Leclerc > 92794 Issy-les-Moulineaux Cedex 9 - France > Tel: +33 1 45 29 64 50 > ------------------------------------- > > > > > -----Message d'origine----- > > De : Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Envoyé : jeudi 19 octobre 2000 15:34 > > À : 'CHAPRON Jean-Emmanuel FTRD/DAC/ISS'; > > MEGACO@STANDARDS.NORTELNETWORKS.COM > > Objet : RE: wildcarded termination in Move > > > > > > I may be finessing the answer but > > Context=1{Subtract=T1.... > > Context=${Add=T1... > > gets you an equivalent > > > > Brian > > > > > -----Original Message----- > > > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > > > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > > > Sent: Thursday, October 19, 2000 5:02 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: wildcarded termination in Move > > > > > > > > > Hello Brian, all > > > > > > If things are left as they are, it seems that the case > > > described below is > > > simply impossible: > > > > > > (1) > > > | > > +-------------------------------------------------+ | > > > | |Context C1 > > | | > > > | | +-------------+ > > +-------------+ | | > > > | | | (Term. T1) | +-----+ | (Term. > > T2) | | | > > > <-+--->| RTP Stream |---| * |------| RTP Stream > > > |<---+-> > > > | | +-------------+ +-----+ > > +-------------+ | | > > > | > > +-------------------------------------------------+ | > > > (2) > > > > > > | > > +-------------------------------------------------+ | > > > | |Context C1 > > | | > > > | | +-------------+ > > > | | > > > | | | (Term. T1) | +-----+ > > | | > > > <-+--->| RTP Stream |---| * | > > | | > > > | | +-------------+ +-----+ > > | | > > > | > > +-------------------------------------------------+ | > > > | > > +-------------------------------------------------+ | > > > | |Context C2 > > | | > > > | | > > +-------------+ | | > > > | | +-----+ | (Term. > > T2) | | | > > > | | | * |------| RTP Stream > > > |<---+-> > > > | | +-----+ > > +-------------+ | | > > > | > > +-------------------------------------------------+ | > > > > > > > > > C2 didn't exist in (1). How to go from (1) to (2)? > > > - We can't use a MOVE $ (too bad..) > > > - we can't use Context = $ {Add = T2} because T2 is in a > > > non-NULL context > > > - we can't use "Subtract/Add" because we have only RTP > > > Terminations we don't > > > want to remove. > > > > > > This is not a textbook case, as far as this case may occur > > if the Call > > > Server/MGC is connected to the IN and receives, for > > instance, an INAP > > > "SplitLeg" message requiring such an handling of connections. > > > > > > Regards, > > > > > > > > > ``` > > > (o o) > > > ----------oOO--(_)-OOo-------------- > > > Jean-Emmanuel CHAPRON > > > FRANCE TELECOM R&D > > > DAC/ACE > > > 38-40 rue du général Leclerc > > > 92794 Issy-les-Moulineaux Cedex 9 - France > > > Tel: +33 1 45 29 64 50 > > > ------------------------------------- > > > > > > > > > > > > > -----Message d'origine----- > > > > De : Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > > Envoyé : mercredi 18 octobre 2000 15:01 > > > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Objet : Re: wildcarded termination in Move > > > > > > > > > > > > Ya, that's one of the reasons it's probably there - separating > > > > functions of Move and Add. > > > > > > > > Probably best to leave things as they are. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > > > > > Sent: Wednesday, October 18, 2000 8:29 AM > > > > > To: Rosen, Brian > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > If you remove this restriction then why you need Move, i will > > > > > always use Add to > > > > > either: > > > > > 1. Add a termination to a context from null context > > > > > 2. Move (read it as Add) a termination to a context from a > > > > > non-NULL context. > > > > > > > > > > -Kapil Nayar > > > > > Hughes Software Systems > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/18/2000 > > 05:31:06 PM > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > cc: (bcc: Kapil Nayar/HSS) > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > Only Add can create a new context: > > > > > "In general, an Add command is used to add Terminations > > > > to Contexts. > > > > > If the MGC does not specify an existing Context to > which the > > > > > Termination is to be added, the MG creates a new > Context. " > > > > > > > > > > A way to do the consultation hold is to create the new > > > context with > > > > > C and move A to that Context. > > > > > > > > > > I'll note that I was a little surprised to read: > > > > > "The Termination is either created, or taken from the > > > null Context" > > > > > (although I may have wrote it!), since this prohibits > an Add of > > > > > a termination already in another context. I'm not sure why we > > > > > prohibit that. I do think there is little practical > > difficulty in > > > > > keeping that restriction. If we did relax that > restriction, you > > > > > could do Context=${Add=A{.... > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > > > > > Sent: Wednesday, October 18, 2000 12:40 AM > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > Hi Brian, > > > > > > > > > > > > If you mean to say that Move with ContextID = $ is > > > > > > nonsensical --- I beg to > > > > > > differ...... > > > > > > > > > > > > Consider a simple call scenario -- A is talking to > B..... and > > > > > > now A wants to put > > > > > > B on hold and call up C......The simplest way to do > it as per > > > > > > my understanding > > > > > > would be -- MGC shall tell MG to Move A to a new context > > > > > > (Move - ContextID=$ and > > > > > > TermID = A) where it shall talk to C, and once it is done, > > > > > > move it back to the > > > > > > context where it was talking to B...... > > > > > > > > > > > > What is your opinion about this.... > > > > > > > > > > > > Thanks > > > > > > Chanchal.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 > > > 05:57:41 PM > > > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If there are three terminations in an MG > > > > > > > abcd > > > > > > > abce > > > > > > > xyz. > > > > > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > > > > > NULL Context. > > > > > > > If MGC says Move with ContextID = $ and > termination as abc*, > > > > > > > what should the > > > > > > > MG do > > > > > > First of all, I think this is illegal, or at least > > nonsensical. > > > > > > You CAN'T create a new contextId with CHOOSE. > > > > > > So if it is legal, you are asking for Russian > Roulette - pick > > > > > > a context where the resulting command would be legal, > > and do it. > > > > > > If there is more than one, then it's random which one > > > > > > > > > > > > > 1. Consider abce while resolving wildcarded abc* - > > > > > > > Move is valid for abcd (it's in non-NULL context) and > > > > invalid for > > > > > > > abce (move is not allowed to move from and to a > > NULL Context) > > > > > > abcd is valid, abce is not valid > > > > > > > > > > > > > 2. Don't consider terminations in NULL Context > for resolving > > > > > > > wildcard since > > > > > > > the basic idea is not to Move to or from NULL Context. > > > > > > This is correct > > > > > > > > > > > > > > > > > > > > The first option has an impact on further commands in the > > > > > > > transaction since a > > > > > > > failure > > > > > > > with one command can cause the side effect of > other commands > > > > > > > being not executed. > > > > > > True, but in general if the MGC was foolish enough > to do this, > > > > > > it deserves what it gets. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 13:27:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA03121 for ; Thu, 19 Oct 2000 13:27:54 -0400 (EDT) Received: from standards (47.234.32.16:3339) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7677@standards.nortelnetworks.com>; Thu, 19 Oct 2000 13:11:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30751 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 13:11:05 -0400 Received: from gateway.assuredaccess.com (206.169.126.4:4871) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7676@standards.nortelnetworks.com>; Thu, 19 Oct 2000 13:01:04 -0400 Received: from assuredaccess.com ([10.193.6.246]) by gateway.assuredaccess.com (Netscape Mail Server v2.0) with ESMTP id AAA231; Thu, 19 Oct 2000 10:18:43 -0700 X-Mailer: Mozilla 4.73 [en] (X11; I; Linux 2.2.5-15 i686) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EF2E59.B7A9A455@assuredaccess.com> Date: Thu, 19 Oct 2000 10:24:41 -0700 Reply-To: njain@assuredaccess.com Sender: "Media Gateway Control (megaco)" From: Nitin Jain Organization: Assured Access Subject: Re: physical and ephemeral terminations X-To: Brian.Rosen@MARCONI.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all, Sorry I am late into this discussion. From the archives, I could not find out what the consensus was for creating an ephemeral termination or selecting a physical termination for CHOOSE in an ADD command. If the physical termination can have the localDescriptor properties, how do we distinguish between a CHOOSE for ephemeral termination or Physical termination when "TermID=$" in an ADD command. Thanks. Nitin -----Orig. Message------- Any termination can have properties, defined by the packages implemented on it. Look at the IPPhone packages for example. Brian -----Original Message----- From: Shlomo Kabaz ECItelecom [mailto:Shlomo.Kabaz@ECITELE.COM] Sent: Tuesday, October 10, 2000 5:21 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: physical and ephemeral terminations Hi , all ! Does the physical termination have properties , because in the examples in the Rfc all the properties of the "connection" is given in the ephemeral termination and the elements that are given to physical is events and signals . Thanks , Shlomo From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 14:43:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA14761 for ; Thu, 19 Oct 2000 14:43:36 -0400 (EDT) Received: from standards (47.234.32.16:4755) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA76D1@standards.nortelnetworks.com>; Thu, 19 Oct 2000 14:26:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30871 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 14:26:50 -0400 Received: from baucis.sc.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA76D0@standards.nortelnetworks.com>; Thu, 19 Oct 2000 14:26:50 -0400 Received: from SMTP (fmsmsxvs03-1.fm.intel.com [132.233.42.203]) by baucis.sc.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id LAA15771 for ; Thu, 19 Oct 2000 11:42:01 -0700 (PDT) Received: from fmsmsx19.fm.intel.com ([132.233.48.19]) by 132.233.48.203 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 19 Oct 2000 18:42:00 0000 (GMT) Received: by fmsmsx19.fm.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Oct 2000 11:41:59 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 19 Oct 2000 11:41:58 -0700 Reply-To: "Tulpule, Naren" Sender: "Media Gateway Control (megaco)" From: "Tulpule, Naren" Subject: Local control descriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi list, can the local control descriptor have more than one property parm? If yes, what is the meaning of "at-most-once per item" in the production for localParm? -- Naren. These views and opinions are mine alone, not those of Intel (yet ;-) Narendra C. Tulpule SMTS, Trillium (an Intel company) Ph: +1-310-442-9222 Fax: +1-310-442-1162 12100 Wilshire Bl #1800 Los Angeles, CA 90025 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 15:15:37 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA21677 for ; Thu, 19 Oct 2000 15:15:36 -0400 (EDT) Received: from standards (47.234.32.16:2156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA770F@standards.nortelnetworks.com>; Thu, 19 Oct 2000 14:58:49 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 30953 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 14:58:49 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA770E@standards.nortelnetworks.com>; Thu, 19 Oct 2000 14:58:49 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA17930; Thu, 19 Oct 2000 15:13:59 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA05163; Thu, 19 Oct 2000 15:14:02 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVH85V>; Thu, 19 Oct 2000 15:13:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E843@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Oct 2000 15:14:00 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Local control descriptor X-To: "Tulpule, Naren" To: MEGACO@STANDARDS.NORTELNETWORKS.COM > can the local control descriptor have more than one > property parm? Yes > what is the meaning of "at-most-once per item" in the production for > localParm? It means that any one parameter can only occur once in the descriptor. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 15:24:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA23553 for ; Thu, 19 Oct 2000 15:24:37 -0400 (EDT) Received: from standards (47.234.32.16:2156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7735@standards.nortelnetworks.com>; Thu, 19 Oct 2000 15:07:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31004 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 15:07:54 -0400 Received: from ganymede.or.intel.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7734@standards.nortelnetworks.com>; Thu, 19 Oct 2000 15:07:54 -0400 Received: from SMTP (orsmsxvs01-1.jf.intel.com [192.168.65.200]) by ganymede.or.intel.com (8.9.1a+p1/8.9.1/d: relay.m4,v 1.32 2000/10/12 22:57:04 dmccart Exp $) with SMTP id MAA01353; Thu, 19 Oct 2000 12:22:56 -0700 (PDT) Received: from orsmsx28.jf.intel.com ([192.168.70.28]) by 192.168.70.200 (Norton AntiVirus for Internet Email Gateways 1.0) ; Thu, 19 Oct 2000 19:22:55 0000 (GMT) Received: by orsmsx28.jf.intel.com with Internet Mail Service (5.5.2650.21) id ; Thu, 19 Oct 2000 12:22:53 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 19 Oct 2000 12:22:48 -0700 Reply-To: "Tulpule, Naren" Sender: "Media Gateway Control (megaco)" From: "Tulpule, Naren" Subject: Re: Local control descriptor X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] > can the local control descriptor have more than one > property parm? Yes > what is the meaning of "at-most-once per item" in the production for > localParm? It means that any one parameter can only occur once in the descriptor. Brian [[NAREN]] But ABNF doesn't fix the order of localParm components. So if I understood your response correctly, we can have only one stream mode, only one reserved value mode, only one reserved group mode but multiple property parameters (each with a different pkgdName), something like localControl { a/b = 1, c/d = 2, mode = sendonly, e/f = 3, reservedGroup = OFF, g/h > 4, ... } Is that right? -- Naren. These views and opinions are mine alone, not those of Intel (yet ;-) Narendra C. Tulpule SMTS, Trillium (an Intel company) Ph: +1-310-442-9222 Fax: +1-310-442-1162 12100 Wilshire Bl #1800 Los Angeles, CA 90025 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 15:43:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA27290 for ; Thu, 19 Oct 2000 15:43:03 -0400 (EDT) Received: from standards (47.234.32.16:2156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA775B@standards.nortelnetworks.com>; Thu, 19 Oct 2000 15:26:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31052 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 15:26:16 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA775A@standards.nortelnetworks.com>; Thu, 19 Oct 2000 15:25:13 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA20560; Thu, 19 Oct 2000 15:40:15 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA12660; Thu, 19 Oct 2000 15:40:07 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRSL42>; Thu, 19 Oct 2000 15:39:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E844@whq-msgusr-02.pit.comms.marconi.com> Date: Thu, 19 Oct 2000 15:40:04 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Local control descriptor X-To: "Tulpule, Naren" To: MEGACO@STANDARDS.NORTELNETWORKS.COM > [[NAREN]] > But ABNF doesn't fix the order of localParm components. So if Yes, order is NOT restricted > I understood > your response correctly, we can have only one stream mode, > only one reserved > value mode, only one reserved group mode yes > but multiple > property parameters > (each with a different pkgdName), something like > localControl { a/b = 1, c/d = 2, mode = sendonly, e/f = 3, > reservedGroup = > OFF, g/h > 4, ... } Well, close. There is no restriction that you have different pkgdNames, so you can set a/a1, a/a2 and a/a3 in the same localControl descriptor, for example. What you can't do is set a/a2 more than once in the same descriptor. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 15:56:02 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA00005 for ; Thu, 19 Oct 2000 15:56:01 -0400 (EDT) Received: from standards (47.234.32.16:2156) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA777B@standards.nortelnetworks.com>; Thu, 19 Oct 2000 15:39:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31093 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 15:39:09 -0400 Received: from mail-dns1-nj.dialogic.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA777A@standards.nortelnetworks.com>; Thu, 19 Oct 2000 15:39:09 -0400 Received: from mail4.dialogic.com ([146.152.6.40]) by mail-dns1-nj.dialogic.com (8.9.1a+p1/8.9.1/d: dialogic.m4,v 1.3 2000/05/05 13:56:23 dmccart Exp $) with ESMTP id TAA08953 for ; Thu, 19 Oct 2000 19:58:32 GMT Received: from exchange4nj.dialogic.com (exchange4nj.dialogic.com [146.152.3.19]) by mail4.dialogic.com (8.9.3+Sun/8.9.3) with ESMTP id PAA15436 for ; Thu, 19 Oct 2000 15:54:22 -0400 (EDT) Received: by exchange4nj.dialogic.com with Internet Mail Service (5.5.2650.21) id <4Y8N1NR7>; Thu, 19 Oct 2000 15:56:32 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Thu, 19 Oct 2000 15:47:05 -0400 Reply-To: "Rupsis, Paul" Sender: "Media Gateway Control (megaco)" From: "Rupsis, Paul" Subject: Re: wildcarded termination in Move To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id PAA00005 > there needs to be a means (for a service as simple as call holding) > to temporarily 'separate' terminations being in the same context > whatever their nature (physical/ephemeral) Isn't that what Topology provides (e.g., Context = C1 {Topology{T1, T2, isolate}} ) One problem with enabling Moves of terminations in and out of contexts is that statistics are reset. Paul Rupsis -----Original Message----- From: Fabien Capoen [mailto:Fabien.Capoen@ALCATEL.FR] Sent: Thursday, October 19, 2000 10:10 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: wildcarded termination in Move If I can dare to speak on this list ... (to introduce myself, I work on 'NGN' standards for alcatel), on this subject I have the following thoughts: - there needs to be a mean (for a service as simple as call holding) to temporarily 'separate' terminations being in the same context whatever their nature (physical/ephemeral) - the 'Context=${Move=' solution seems the only one (we could think of 2 other ones: the first to allow add on terminations being in a not null context, but this one has already been rejected because it breaks the add/move complementarity - move becomes just a special case of add; the second being a special NULL-like context: the ONHOLD context, for ephemeral terminations. This one is not very elegant) - the 'Context=${Move=' solution does not break the add/move complementarity: add remains reserved for non existing terminations or terminations in the null context, whereas move is reserved for terminations in a not null context - I have looked in the standard, and I could not see it explicitely forbidden. The only thing is that it is not explicitely allowed: in §6.1, the creation of a new context is only described for the add command. Changing 'In general, an Add command is used to add Terminations to Contexts' of §6.1 into 'In general, an Add OR MOVE command is used to add Terminations to Contexts' could solve the problem. And really, isn't it true to say that move also adds terminations to a context ? Isn't the only difference between move and add on the nature of the termination on which the add/move is applied ? The question I have is then: what concrete problems do people see with allowing 'context=$' in a move request ? Regards ... Fabien C. Please respond to "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Fabien CAPOEN/FR/ALCATEL) Subject: Re: wildcarded termination in Move Woops, sorry, didn't pay close enough attention. Your example has TWO RTP streams and no physical terminations. Unusual, but legal. Well, I'm stuck. I can think of stupid things to do, but nothing that looks useful. Maybe a change is warranted. Need other opinions on allowing Context=${Move=... Brian > -----Original Message----- > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > Sent: Thursday, October 19, 2000 9:45 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: wildcarded termination in Move > > > I don't understand your solution: T1 is an ephemeral > Termination: its TermID > is not provisionned in the MG. As soon as T1 is subtracted from C1, it > disappears, and its TermID too. How can the MGC re-use this > TermID to add it > to a new Context? > Can the MGC set the TermID of an ephemeral Termination when > it creates it? > > > ``` > (o o) > ----------oOO--(_)-OOo-------------- > Jean-Emmanuel CHAPRON > FRANCE TELECOM R&D > DAC/ACE > 38-40 rue du général Leclerc > 92794 Issy-les-Moulineaux Cedex 9 - France > Tel: +33 1 45 29 64 50 > ------------------------------------- > > > > > -----Message d'origine----- > > De : Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Envoyé : jeudi 19 octobre 2000 15:34 > > À : 'CHAPRON Jean-Emmanuel FTRD/DAC/ISS'; > > MEGACO@STANDARDS.NORTELNETWORKS.COM > > Objet : RE: wildcarded termination in Move > > > > > > I may be finessing the answer but > > Context=1{Subtract=T1.... > > Context=${Add=T1... > > gets you an equivalent > > > > Brian > > > > > -----Original Message----- > > > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > > > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > > > Sent: Thursday, October 19, 2000 5:02 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: wildcarded termination in Move > > > > > > > > > Hello Brian, all > > > > > > If things are left as they are, it seems that the case > > > described below is > > > simply impossible: > > > > > > (1) > > > | > > +-------------------------------------------------+ | > > > | |Context C1 > > | | > > > | | +-------------+ > > +-------------+ | | > > > | | | (Term. T1) | +-----+ | (Term. > > T2) | | | > > > <-+--->| RTP Stream |---| * |------| RTP Stream > > > |<---+-> > > > | | +-------------+ +-----+ > > +-------------+ | | > > > | > > +-------------------------------------------------+ | > > > (2) > > > > > > | > > +-------------------------------------------------+ | > > > | |Context C1 > > | | > > > | | +-------------+ > > > | | > > > | | | (Term. T1) | +-----+ > > | | > > > <-+--->| RTP Stream |---| * | > > | | > > > | | +-------------+ +-----+ > > | | > > > | > > +-------------------------------------------------+ | > > > | > > +-------------------------------------------------+ | > > > | |Context C2 > > | | > > > | | > > +-------------+ | | > > > | | +-----+ | (Term. > > T2) | | | > > > | | | * |------| RTP Stream > > > |<---+-> > > > | | +-----+ > > +-------------+ | | > > > | > > +-------------------------------------------------+ | > > > > > > > > > C2 didn't exist in (1). How to go from (1) to (2)? > > > - We can't use a MOVE $ (too bad..) > > > - we can't use Context = $ {Add = T2} because T2 is in a > > > non-NULL context > > > - we can't use "Subtract/Add" because we have only RTP > > > Terminations we don't > > > want to remove. > > > > > > This is not a textbook case, as far as this case may occur > > if the Call > > > Server/MGC is connected to the IN and receives, for > > instance, an INAP > > > "SplitLeg" message requiring such an handling of connections. > > > > > > Regards, > > > > > > > > > ``` > > > (o o) > > > ----------oOO--(_)-OOo-------------- > > > Jean-Emmanuel CHAPRON > > > FRANCE TELECOM R&D > > > DAC/ACE > > > 38-40 rue du général Leclerc > > > 92794 Issy-les-Moulineaux Cedex 9 - France > > > Tel: +33 1 45 29 64 50 > > > ------------------------------------- > > > > > > > > > > > > > -----Message d'origine----- > > > > De : Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > > Envoyé : mercredi 18 octobre 2000 15:01 > > > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Objet : Re: wildcarded termination in Move > > > > > > > > > > > > Ya, that's one of the reasons it's probably there - separating > > > > functions of Move and Add. > > > > > > > > Probably best to leave things as they are. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > > > > > Sent: Wednesday, October 18, 2000 8:29 AM > > > > > To: Rosen, Brian > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > If you remove this restriction then why you need Move, i will > > > > > always use Add to > > > > > either: > > > > > 1. Add a termination to a context from null context > > > > > 2. Move (read it as Add) a termination to a context from a > > > > > non-NULL context. > > > > > > > > > > -Kapil Nayar > > > > > Hughes Software Systems > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/18/2000 > > 05:31:06 PM > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > cc: (bcc: Kapil Nayar/HSS) > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > Only Add can create a new context: > > > > > "In general, an Add command is used to add Terminations > > > > to Contexts. > > > > > If the MGC does not specify an existing Context to > which the > > > > > Termination is to be added, the MG creates a new > Context. " > > > > > > > > > > A way to do the consultation hold is to create the new > > > context with > > > > > C and move A to that Context. > > > > > > > > > > I'll note that I was a little surprised to read: > > > > > "The Termination is either created, or taken from the > > > null Context" > > > > > (although I may have wrote it!), since this prohibits > an Add of > > > > > a termination already in another context. I'm not sure why we > > > > > prohibit that. I do think there is little practical > > difficulty in > > > > > keeping that restriction. If we did relax that > restriction, you > > > > > could do Context=${Add=A{.... > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > > > > > Sent: Wednesday, October 18, 2000 12:40 AM > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > Hi Brian, > > > > > > > > > > > > If you mean to say that Move with ContextID = $ is > > > > > > nonsensical --- I beg to > > > > > > differ...... > > > > > > > > > > > > Consider a simple call scenario -- A is talking to > B..... and > > > > > > now A wants to put > > > > > > B on hold and call up C......The simplest way to do > it as per > > > > > > my understanding > > > > > > would be -- MGC shall tell MG to Move A to a new context > > > > > > (Move - ContextID=$ and > > > > > > TermID = A) where it shall talk to C, and once it is done, > > > > > > move it back to the > > > > > > context where it was talking to B...... > > > > > > > > > > > > What is your opinion about this.... > > > > > > > > > > > > Thanks > > > > > > Chanchal.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 > > > 05:57:41 PM > > > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If there are three terminations in an MG > > > > > > > abcd > > > > > > > abce > > > > > > > xyz. > > > > > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > > > > > NULL Context. > > > > > > > If MGC says Move with ContextID = $ and > termination as abc*, > > > > > > > what should the > > > > > > > MG do > > > > > > First of all, I think this is illegal, or at least > > nonsensical. > > > > > > You CAN'T create a new contextId with CHOOSE. > > > > > > So if it is legal, you are asking for Russian > Roulette - pick > > > > > > a context where the resulting command would be legal, > > and do it. > > > > > > If there is more than one, then it's random which one > > > > > > > > > > > > > 1. Consider abce while resolving wildcarded abc* - > > > > > > > Move is valid for abcd (it's in non-NULL context) and > > > > invalid for > > > > > > > abce (move is not allowed to move from and to a > > NULL Context) > > > > > > abcd is valid, abce is not valid > > > > > > > > > > > > > 2. Don't consider terminations in NULL Context > for resolving > > > > > > > wildcard since > > > > > > > the basic idea is not to Move to or from NULL Context. > > > > > > This is correct > > > > > > > > > > > > > > > > > > > > The first option has an impact on further commands in the > > > > > > > transaction since a > > > > > > > failure > > > > > > > with one command can cause the side effect of > other commands > > > > > > > being not executed. > > > > > > True, but in general if the MGC was foolish enough > to do this, > > > > > > it deserves what it gets. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 21:48:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13878 for ; Thu, 19 Oct 2000 21:48:30 -0400 (EDT) Received: from standards (47.234.32.16:3657) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78AA@standards.nortelnetworks.com>; Thu, 19 Oct 2000 21:31:47 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31482 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 21:31:46 -0400 Received: from search08.sohu.com (202.108.41.28:1043) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78A4@standards.nortelnetworks.com>; Thu, 19 Oct 2000 21:21:45 -0400 Received: by search08.sohu.com id JAA0000027197; Fri, 20 Oct 2000 09:20:28 +0800 (CST) Sensitivity: Public X-Other-References: 04ECE9F1B X-In-Response-To: 0ECF38B8B X-Mailer: Internet Mail Service [13.0.4003.30] (Win95; I) MessageID: X-Accept-Language: en Content-Type: text/plain Message-ID: <200010200120.JAA0000027197@search08.sohu.com> Date: Thu, 19 Oct 2000 21:31:46 -0400 Reply-To: maildirect@POSTMASTER.CO.UK Sender: "Media Gateway Control (megaco)" From: maildirect@POSTMASTER.CO.UK Subject: affluence for you X-To: rachelle@sspr.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Multiply Your Income... Seeking positive and motivated individuals that are serious about creating 6-7 figure wealth. Do you have a burning desire to enhance the quality of your existing life? Would you like to live the life that others only dream about? The fact is we have many people in this enterprise that earn from 10K to 50k per month from the privacy of their own home and are achieving financial independence in 2-3 years obviously wealthy and having total freedom both personal and financial. If you think this is too good to be true or are skeptical then this may not be for you... Many have been conditioned to believe it must be illegal, immoral or unethical to ever earn any real profits from our efforts. This is all about Education and Knowledge that was once reserved for the ultra wealthy and the well connected. By calling the phone number below you will hear about a powerful Wealth Building Educational Program and a brilliant marketing concept. How would you like to: 1. Drastically reduce personal, business and capital gains taxes? 2. Protect all assets from any form of seizure, liens, or judgments? 3. Create a six-figure income every 4 months? How about: 1. Restoring and preserving complete personal and financial privacy? 2. Create and amass personal wealth, multiply it and protect it? 3. Realize a 3 to 6 times greater returns on your money? 4. Legally make yourself and your assets completely judgment-proof, seizure-proof, lien-proof, divorce-proof, attorney-proof, IRS-proof, and become completely insulated? Are you a BIG thinker, BIG dreamer and a person that believes they deserve to have the best in life? Are you capable of recognizing that once in a lifetime opportunity when it's looking right at you? Countless others have missed their shot at the title only to look back years later and wished they should've because they could've. If you have Moderate People Skills, a Strong Work Ethic, and a Burning Desire to become Financially Independent in the next 2-3 years then I invite you to take a tour of the turnkey information system. There are 3 steps in the process: 1st step: 1"888"269"5535 3-minute intro (24 hr toll free) 2nd step: Leave your name and phone number requesting a informational interview 3rd step: Receive a detailed overview of the product and marketing plan This is about money, freedom, and financial independence. It is unlike any other business and it is NOT MLM Take the time to gather the information...It is truly remarkable!!! The most effective WAY TO BE REMOVED FROM FUTURE MAILINGS IS TO REPLY TO THE FOLLOWING LINK mailto:removeme@greysuitandtie.net?subject=REMOVE &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&* Clearly, a large proportion of intercultural communicative coordination is unspecified with respect to the sophisticated hardware. For example, initiation of basic charismatic subculture development must utilize and be functionally interwoven with a corpus of utterance tokens upon which conformity has been defined by the paired utterance test. &&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&* From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 22:46:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26641 for ; Thu, 19 Oct 2000 22:46:21 -0400 (EDT) Received: from standards (47.234.32.16:1632) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78DE@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:28:45 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31550 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 22:28:44 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78D6@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:18:43 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9K2Xtt27912; Fri, 20 Oct 2000 04:33:55 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA10452; Fri, 20 Oct 2000 04:33:55 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA04243; Fri, 20 Oct 2000 04:33:52 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E833@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EF8252.7600F811@ericsson.com> Date: Fri, 20 Oct 2000 10:22:58 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Statistics X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit This has been something thats been around for a long time and I thought people were pretty aware of this. I don't think its a bug per se as you can handle it formatting your statistics in a certain way. Certainly in v2 it would be nice to allow statistics on streams. Its a fairly big change to me for an implementors' guide. Cheers, Christian "Rosen, Brian" wrote: > > Oh cool. I don't think we have ever talked about this, > stream specific statistics! Hmmmmm. > > So we would want to add (an optional) StreamId to Statistics Descriptor > Statistics=1{rtp/pr=.... > and you might get more than one Statistics descriptor in the reply. > > Wow. This is a real bug in the protocol I think! > > Brian > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Thursday, October 19, 2000 9:51 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Statistics > > > > > > Section E.12.4 states that statistics like > > jitter, packet loss,etc are described on an > > RTP stream. If only one RTP stream is > > present on a termination its straitforward > > to send statistics. But if multiple streams > > are created on a termination How this > > reporting is done? > > > > -Madhubabu > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 22:46:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26651 for ; Thu, 19 Oct 2000 22:46:23 -0400 (EDT) Received: from standards (47.234.32.16:1632) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78E4@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:28:46 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31551 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 22:28:46 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78D7@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:18:45 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9K2Xxt27916 for ; Fri, 20 Oct 2000 04:33:59 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA10456 for ; Fri, 20 Oct 2000 04:33:59 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA04247 for ; Fri, 20 Oct 2000 04:33:57 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E83B@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EF82D6.6ECD64@ericsson.com> Date: Fri, 20 Oct 2000 10:25:10 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Meeting In San Diego? To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, I think it would be good to have meeting time in San Diego. As Brian mentioned we need to discuss rechartering as shown by the extensive discussion when I announced the v2 work. It would be good to trigger some discussion about the re-chartering on the list before hand though (I don't know if i'll be at the IETF meeting). Cheers, Christian "Rosen, Brian" wrote: > > I'd say yes: > > I think we want to discuss rechartering > I think we want to discuss packages > There is a report on interop testing, and an announcement (I hope) > of the next one. > > Brian > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > > Sent: Thursday, October 19, 2000 10:57 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Meeting In San Diego? > > > > > > Does Megaco need meeting time in San Diego? The only > > official WG work item > > outstanding is the MIB -- I'm about to announce progression on the NAS > > package and the IPPhone profile. On the other hand, we are > > getting a number > > of other packages, and we'll have results from the November > > SG 16 meeting to > > consider. > > > > Tom > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 22:46:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26660 for ; Thu, 19 Oct 2000 22:46:24 -0400 (EDT) Received: from standards (47.234.32.16:1632) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78EE@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:28:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31552 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 22:28:53 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78D8@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:18:52 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9K2Y4Z23778; Fri, 20 Oct 2000 04:34:04 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA10462; Fri, 20 Oct 2000 04:34:03 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA04251; Fri, 20 Oct 2000 04:34:00 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <002401c039da$725a2ce0$70d8a8c0@dev_4.us.radvision.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EF8328.681BFA8@ericsson.com> Date: Fri, 20 Oct 2000 10:26:32 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Acodec vs RTPPayload X-To: delbert@radvision.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Dan, No not exactly. Whilst the RTPPayload and Acodec give information about codecs the RTPPayload will give it in terms of what is supported by RTP. The Acodec information is for other transport types and contains organisational information. Cheers, Christian Dan Elbert wrote: > > In C.1. (General Media Attributes) , what is the difference between Acodec > and RTPPayload ? DOn't they give the same information ? > > Dan Elbert > RADVISION From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 22:46:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26671 for ; Thu, 19 Oct 2000 22:46:25 -0400 (EDT) Received: from standards (47.234.32.16:1632) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78F2@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:28:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31553 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 22:28:56 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78D9@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:18:55 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9K2Y8t27924; Fri, 20 Oct 2000 04:34:08 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA10466; Fri, 20 Oct 2000 04:34:07 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA04255; Fri, 20 Oct 2000 04:34:05 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <6525697D.004A7CED.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EF8384.3B17EDC7@ericsson.com> Date: Fri, 20 Oct 2000 10:28:04 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: payload change. X-To: bmbabu@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day, Depends on your implementation. I'd say a smart MG would do this switch without bothering the MGC. Cheers, Christian Madhu Babu wrote: > > Say multiple codecs are reserved for a given > termination through reserve properties. If media starts > using one codec and MGC has not released the other > codecs, now if MG encounters change of payload the > "payload transition" event is generated. Apart from > generating the event is the intention here is that MG by > itself will switch the codec if it is in the list of reserved codecs? > > -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 22:46:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26694 for ; Thu, 19 Oct 2000 22:46:26 -0400 (EDT) Received: from standards (47.234.32.16:1632) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78F6@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:29:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31554 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 22:29:00 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78DA@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:18:59 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9K2YCt27928; Fri, 20 Oct 2000 04:34:12 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA10470; Fri, 20 Oct 2000 04:34:12 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA04259; Fri, 20 Oct 2000 04:34:09 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <6525697D.004A14F4.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EF8417.539F24F2@ericsson.com> Date: Fri, 20 Oct 2000 10:30:31 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Modify the service state property X-To: bmbabu@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit I'll agree with Brian on service state. I believe that the MGC can manipulate the state in the Termination State Descriptor. I don't see any compelling reason to now make it read only. Cheers, Christian Madhu Babu wrote: > > I believe that the ServiceState values > outofservice and inservice are not > settable directly my MGC and only indicate > the current state that can be modified > using SerivceChange. This seems to make > ServiceState property as "read-only" type for > these two values. But then what about "test" value ? > > -Madhubabu > > "Rosen, Brian" on 10/19/2000 07:04:09 PM > > To: Madhu B Babu/HSS@HSS, MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: > > Subject: RE: Modify the service state property > > I'd say yes, but I'd recommend not doing it that way. > > Brian > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Thursday, October 19, 2000 7:01 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Modify the service state property > > > > > > Is the changing of ServiceState of a termination > > directly from inservice to outofservice and > > vice-versa allowed in say a Modify? > > > > Is this equivalent in functional operation to a ServiceChange > > on that termination? > > > > -Madhubabu > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 22:46:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26716 for ; Thu, 19 Oct 2000 22:46:28 -0400 (EDT) Received: from standards (47.234.32.16:1632) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78FA@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:29:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31555 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 22:29:04 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78DB@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:19:03 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9K2YGt27940; Fri, 20 Oct 2000 04:34:16 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA10474; Fri, 20 Oct 2000 04:34:16 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA04263; Fri, 20 Oct 2000 04:34:13 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <6525697D.002D62CC.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EF86FF.44DE86EB@ericsson.com> Date: Fri, 20 Oct 2000 10:42:55 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Implementor's Guide v3 -- Correction X-To: chassija@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Chanchal, Thanks for the info. I'll update the implementors' guide accordingly. 8.5 Syntax Problem in Appendix A Description: According to the definition of digitMapRAnge : digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) "x" must be followed by "[" . Reference: Subject: Re: Syntax problems Date: Thu, 14 Sep 2000 04:14:24 +0200 From: John Segers Organization: Lucent Technologies To: MEGACO@STANDARDS.NORTELNETWORKS.COM [Begin Correction] B.2 ABNF specification ... digitMapRange = ("x" / (LWSP "[" LWSP digitLetter LWSP "]" LWSP)) [End Correction] Cheers, Christian Chanchal Hassija wrote: > > Hello Christian, > > There is a correction required in the implementor's guide.....section 8.5 which > says that > > DigitMap= Dialplan0{ > > (0| 00|[1-7][xxx]|8[xxxxxxx]|F[xxxxxxx]|E[xx]|91[xxxxxxxxxx]|9011[x].)} > > The change that has been done is enclosing XX... digit string in [ ] .... but as > per the mail attached below ... the understanding reached was to make a change > in the grammar and not in the example (given above) to make things clearer. > > Hence the change required is to replace > > digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) > > with > > digitMapRange = ("x" /( LWSP "[" LWSP digitLetter LWSP "]" LWSP )) > > Any comments.... > > Thanks > > Chanchal... > > John Segers on 09/14/2000 07:44:24 AM > > Please respond to John Segers > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Chanchal Hassija/HSS) > > Subject: Re: Syntax problems > > Rakefet, > > 1. I seems that the parentheses are missing, as you suggested. > > 2. Looks like this could get you a shift-reduce conflict. That can be > circumvented by having your lexer peek ahead and having two tokens for > the semicolon. Ugly. > > Cheers, > > John > > "Prozan, Rakefet" wrote: > > > > Hi all, > > > > The previous mail was sent by mistake. This is the correct mail: > > > > Can someone clear the following issues in ABNF? > > > > 1) In APPENDIX A EXAMPLE CALL FLOW: > > > > ... > > 8. The MGC Modifies the termination to play dial tone, to look for > > digits according to Dialplan0 and to look for the on-hook event now. > > MGC to MG1: > > > > MEGACO/1 [123.123.123.4]:55555 > > Transaction = 10001 { > > Context = - { > > Modify = A4444 { > > Events = 2223 { > > al/on, dd/ce {DigitMap=Dialplan0} > > }, > > Signals {cg/dt}, > > DigitMap= Dialplan0{ > > (0| 00|[1-7]xxx|8xxxxxxx|Fxxxxxxx|Exx|91xxxxxxxxxx|9011x.)} > > } > > } > > } > > > > According to the definition of digitMapRAnge : > > > > digitMapRange = ("x" / LWSP "[" LWSP digitLetter LWSP "]" LWSP) > > > > "x" must be followed by "[" . > > So, either there is an error in the example,or the definition should > > be: > > > > digitMapRange = ("x" /( LWSP "[" LWSP digitLetter LWSP "]" LWSP )) > > > > 2) In ABNF: > > > > contextRequest = ((contextProperties [COMMA contextAudit]) > > / contextAudit) > > > > contextProperties = contextProperty *(COMMA contextProperty) > > > > My problem is : if the parser finds a COMMA after a contextProperty, it > > doesn't have any indication to know what will come after this COMMA: > > another > > contextProperty,or the optional contextAudit. This results in a loop. > > I think that there are two alternatives ways to solve this: > > > > Either to put contextAudit in { } : > > > > contextRequest = ((contextProperties LBRKT [COMMA contextAudit] RBRKT) > > / contextAudit) > > > > Or put contextProperties in { } : > > > > contextRequest = ((LBRKT contextProperties RBRKT [COMMA contextAudit]) > > / contextAudit) > > > > thank you in advance, > > -- > > Rakefet Prozan, > > Team Manager, S/W Development > > Nortel SBU > > Telrad Networks > > ESN 828-3043 Email:rakefet.prozan@telrad.co.il > > > > """ > > -(o o)- > > +---------------------------------oOO--(_)--OOo--------------+ > > > > .oooO Oooo. > > -------------------------------( )---------( )------------ > > \ ( ) / > > \_) (_/ > > > > Have fun !!! > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 22:46:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26728 for ; Thu, 19 Oct 2000 22:46:29 -0400 (EDT) Received: from standards (47.234.32.16:1632) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA790A@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:29:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31556 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 22:29:13 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78DC@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:19:12 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9K2YOt27963; Fri, 20 Oct 2000 04:34:24 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA10482; Fri, 20 Oct 2000 04:34:24 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA04274; Fri, 20 Oct 2000 04:34:21 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E832@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Message-ID: <39EF8B67.A3C22FBF@ericsson.com> Date: Fri, 20 Oct 2000 11:01:43 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: wildcarded termination in Move X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit G'Day all, I'm really confused now, taking sentences out of context (pardon the pun) can add a little confusion. The MOVE command chapter in H248 doesn't not prohibit moving a termination to Context "?". It mentions target Context ID. The Context chapter says: "In general, an Add command is used to add Terminations to Contexts." and the sentence after: "If the MGC does not specify an existing Context to which the Termination is to be added, the MG creates a new Context.talks about that if Context "?" is specified then a context ID is provided." The "In general" statement cited below is in the sentence about a termination "?" and an ADD command. The "If the MG...." statements talks about Context "?". MOVE Context "?", ta seems to me to be a fundamental part of what we defined and I don't see where this is disallowed. To clarify things at most you could put a CR linefeed after the in general sentence above. Cheers, Christian "Rosen, Brian" wrote: > > Woops, sorry, didn't pay close enough attention. Your example has TWO > RTP streams and no physical terminations. Unusual, but legal. > > Well, I'm stuck. I can think of stupid things to do, but nothing > that looks useful. Maybe a change is warranted. > > Need other opinions on allowing Context=${Move=... > > Brian > > > -----Original Message----- > > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > > Sent: Thursday, October 19, 2000 9:45 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: wildcarded termination in Move > > > > > > I don't understand your solution: T1 is an ephemeral > > Termination: its TermID > > is not provisionned in the MG. As soon as T1 is subtracted from C1, it > > disappears, and its TermID too. How can the MGC re-use this > > TermID to add it > > to a new Context? > > Can the MGC set the TermID of an ephemeral Termination when > > it creates it? > > > > > > ``` > > (o o) > > ----------oOO--(_)-OOo-------------- > > Jean-Emmanuel CHAPRON > > FRANCE TELECOM R&D > > DAC/ACE > > 38-40 rue du général Leclerc > > 92794 Issy-les-Moulineaux Cedex 9 - France > > Tel: +33 1 45 29 64 50 > > ------------------------------------- > > > > > > > > > -----Message d'origine----- > > > De : Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > Envoyé : jeudi 19 octobre 2000 15:34 > > > À : 'CHAPRON Jean-Emmanuel FTRD/DAC/ISS'; > > > MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Objet : RE: wildcarded termination in Move > > > > > > > > > I may be finessing the answer but > > > Context=1{Subtract=T1.... > > > Context=${Add=T1... > > > gets you an equivalent > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > > > > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > > > > Sent: Thursday, October 19, 2000 5:02 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > Hello Brian, all > > > > > > > > If things are left as they are, it seems that the case > > > > described below is > > > > simply impossible: > > > > > > > > (1) > > > > | > > > +-------------------------------------------------+ | > > > > | |Context C1 > > > | | > > > > | | +-------------+ > > > +-------------+ | | > > > > | | | (Term. T1) | +-----+ | (Term. > > > T2) | | | > > > > <-+--->| RTP Stream |---| * |------| RTP Stream > > > > |<---+-> > > > > | | +-------------+ +-----+ > > > +-------------+ | | > > > > | > > > +-------------------------------------------------+ | > > > > (2) > > > > > > > > | > > > +-------------------------------------------------+ | > > > > | |Context C1 > > > | | > > > > | | +-------------+ > > > > | | > > > > | | | (Term. T1) | +-----+ > > > | | > > > > <-+--->| RTP Stream |---| * | > > > | | > > > > | | +-------------+ +-----+ > > > | | > > > > | > > > +-------------------------------------------------+ | > > > > | > > > +-------------------------------------------------+ | > > > > | |Context C2 > > > | | > > > > | | > > > +-------------+ | | > > > > | | +-----+ | (Term. > > > T2) | | | > > > > | | | * |------| RTP Stream > > > > |<---+-> > > > > | | +-----+ > > > +-------------+ | | > > > > | > > > +-------------------------------------------------+ | > > > > > > > > > > > > C2 didn't exist in (1). How to go from (1) to (2)? > > > > - We can't use a MOVE $ (too bad..) > > > > - we can't use Context = $ {Add = T2} because T2 is in a > > > > non-NULL context > > > > - we can't use "Subtract/Add" because we have only RTP > > > > Terminations we don't > > > > want to remove. > > > > > > > > This is not a textbook case, as far as this case may occur > > > if the Call > > > > Server/MGC is connected to the IN and receives, for > > > instance, an INAP > > > > "SplitLeg" message requiring such an handling of connections. > > > > > > > > Regards, > > > > > > > > > > > > ``` > > > > (o o) > > > > ----------oOO--(_)-OOo-------------- > > > > Jean-Emmanuel CHAPRON > > > > FRANCE TELECOM R&D > > > > DAC/ACE > > > > 38-40 rue du général Leclerc > > > > 92794 Issy-les-Moulineaux Cedex 9 - France > > > > Tel: +33 1 45 29 64 50 > > > > ------------------------------------- > > > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > De : Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > > > Envoyé : mercredi 18 octobre 2000 15:01 > > > > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Objet : Re: wildcarded termination in Move > > > > > > > > > > > > > > > Ya, that's one of the reasons it's probably there - separating > > > > > functions of Move and Add. > > > > > > > > > > Probably best to leave things as they are. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > > > > > > Sent: Wednesday, October 18, 2000 8:29 AM > > > > > > To: Rosen, Brian > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > If you remove this restriction then why you need Move, i will > > > > > > always use Add to > > > > > > either: > > > > > > 1. Add a termination to a context from null context > > > > > > 2. Move (read it as Add) a termination to a context from a > > > > > > non-NULL context. > > > > > > > > > > > > -Kapil Nayar > > > > > > Hughes Software Systems > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/18/2000 > > > 05:31:06 PM > > > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > cc: (bcc: Kapil Nayar/HSS) > > > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Only Add can create a new context: > > > > > > "In general, an Add command is used to add Terminations > > > > > to Contexts. > > > > > > If the MGC does not specify an existing Context to > > which the > > > > > > Termination is to be added, the MG creates a new > > Context. " > > > > > > > > > > > > A way to do the consultation hold is to create the new > > > > context with > > > > > > C and move A to that Context. > > > > > > > > > > > > I'll note that I was a little surprised to read: > > > > > > "The Termination is either created, or taken from the > > > > null Context" > > > > > > (although I may have wrote it!), since this prohibits > > an Add of > > > > > > a termination already in another context. I'm not sure why we > > > > > > prohibit that. I do think there is little practical > > > difficulty in > > > > > > keeping that restriction. If we did relax that > > restriction, you > > > > > > could do Context=${Add=A{.... > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > > > > > > Sent: Wednesday, October 18, 2000 12:40 AM > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > Hi Brian, > > > > > > > > > > > > > > If you mean to say that Move with ContextID = $ is > > > > > > > nonsensical --- I beg to > > > > > > > differ...... > > > > > > > > > > > > > > Consider a simple call scenario -- A is talking to > > B..... and > > > > > > > now A wants to put > > > > > > > B on hold and call up C......The simplest way to do > > it as per > > > > > > > my understanding > > > > > > > would be -- MGC shall tell MG to Move A to a new context > > > > > > > (Move - ContextID=$ and > > > > > > > TermID = A) where it shall talk to C, and once it is done, > > > > > > > move it back to the > > > > > > > context where it was talking to B...... > > > > > > > > > > > > > > What is your opinion about this.... > > > > > > > > > > > > > > Thanks > > > > > > > Chanchal.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 > > > > 05:57:41 PM > > > > > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If there are three terminations in an MG > > > > > > > > abcd > > > > > > > > abce > > > > > > > > xyz. > > > > > > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > > > > > > NULL Context. > > > > > > > > If MGC says Move with ContextID = $ and > > termination as abc*, > > > > > > > > what should the > > > > > > > > MG do > > > > > > > First of all, I think this is illegal, or at least > > > nonsensical. > > > > > > > You CAN'T create a new contextId with CHOOSE. > > > > > > > So if it is legal, you are asking for Russian > > Roulette - pick > > > > > > > a context where the resulting command would be legal, > > > and do it. > > > > > > > If there is more than one, then it's random which one > > > > > > > > > > > > > > > 1. Consider abce while resolving wildcarded abc* - > > > > > > > > Move is valid for abcd (it's in non-NULL context) and > > > > > invalid for > > > > > > > > abce (move is not allowed to move from and to a > > > NULL Context) > > > > > > > abcd is valid, abce is not valid > > > > > > > > > > > > > > > 2. Don't consider terminations in NULL Context > > for resolving > > > > > > > > wildcard since > > > > > > > > the basic idea is not to Move to or from NULL Context. > > > > > > > This is correct > > > > > > > > > > > > > > > > > > > > > > > The first option has an impact on further commands in the > > > > > > > > transaction since a > > > > > > > > failure > > > > > > > > with one command can cause the side effect of > > other commands > > > > > > > > being not executed. > > > > > > > True, but in general if the MGC was foolish enough > > to do this, > > > > > > > it deserves what it gets. > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Thu Oct 19 22:46:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id WAA26738 for ; Thu, 19 Oct 2000 22:46:32 -0400 (EDT) Received: from standards (47.234.32.16:1632) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7913@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:29:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 31557 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Thu, 19 Oct 2000 22:29:29 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA78DD@standards.nortelnetworks.com>; Thu, 19 Oct 2000 22:19:29 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9K2YgZ23872 for ; Fri, 20 Oct 2000 04:34:42 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id EAA10498 for ; Fri, 20 Oct 2000 04:34:42 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id EAA04290 for ; Fri, 20 Oct 2000 04:34:40 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39EF9239.20029DF2@ericsson.com> Date: Fri, 20 Oct 2000 11:30:49 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Error code for Max no Term in a context exceeded To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, I had a question of: In H.248, what Error code should be used to indicate that a context already has the max number of terminations in it? e.g. MG supports a max of 2 terminations per context; MGC performs an ADD{C1, (T3)} to context C1 which already has T1 and T2 in it. I couldn't find a appropriate error code. The closest would be "Insufficient Resources" but I'm not sure it really covers this case. As such I propose either an addition to H.248 Annex L or the implementors' guide with something like the following text: Error Code #: 434 Name: Max number of Terminations in a Context exceeded. Definition: The MGC has requested that a termination be added or moved to a context that already contains a maximum number of termination. Package: - Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 01:33:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id BAA24321 for ; Fri, 20 Oct 2000 01:33:24 -0400 (EDT) Received: from standards (47.234.32.16:3972) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7A6A@standards.nortelnetworks.com>; Fri, 20 Oct 2000 1:16:35 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32064 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 01:16:34 -0400 Received: from mars.hss.co.in (202.54.26.197:63709) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7A69@standards.nortelnetworks.com>; Fri, 20 Oct 2000 1:16:31 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9K5WIC01696 for ; Fri, 20 Oct 2000 11:02:21 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697E.001D60EF ; Fri, 20 Oct 2000 10:50:53 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697E.001D5F86.00@sandesh.hss.hns.com> Date: Fri, 20 Oct 2000 10:56:20 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: RequestId in observed events descriptor. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi, what is the RequestId that needs to be sent from MG when "observedevents" are Audited? In section 7.1.17 its specifies that "ObservedEvents contains the RequestIdentifier of the EventsDescriptor that triggered the notification" but this notification of observed events is not triggered by any events descriptor. and the event buffer descriptor doesnot have a requestid field. -Madhubabu. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 03:44:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA18235 for ; Fri, 20 Oct 2000 03:44:04 -0400 (EDT) Received: from standards (47.234.32.16:3487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7B4D@standards.nortelnetworks.com>; Fri, 20 Oct 2000 3:27:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32333 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 03:27:08 -0400 Received: from mars.hss.co.in (202.54.26.197:32888) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7B4C@standards.nortelnetworks.com>; Fri, 20 Oct 2000 3:27:06 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9K77ZC04146 for ; Fri, 20 Oct 2000 12:40:05 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697E.002619C3 ; Fri, 20 Oct 2000 12:26:09 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <6525697E.0026193A.00@sandesh.hss.hns.com> Date: Fri, 20 Oct 2000 12:31:37 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Statistics Auditing To: MEGACO@STANDARDS.NORTELNETWORKS.COM In section 7.2.6 for Audit capability its stated that "StatisticsDescriptor returns the names of the statistics being kept on the termination." But the ABNF grammar states the descriptor as "statisticsDescriptor = StatsToken LBRKT statisticsParameter *(COMMA statisticsParameter ) RBRKT ;at-most-once per item statisticsParameter = pkgdName EQUAL VALUE" which doesn't allow specification of stats parameter always with value. If only names needs to be sent from MG, the value field needs to be made option. -Madhubabu From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 03:53:25 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA19303 for ; Fri, 20 Oct 2000 03:53:25 -0400 (EDT) Received: from standards (47.234.32.16:3487) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7B6F@standards.nortelnetworks.com>; Fri, 20 Oct 2000 3:36:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32373 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 03:36:39 -0400 Received: from mars.hss.co.in (202.54.26.197:33300) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7B6E@standards.nortelnetworks.com>; Fri, 20 Oct 2000 3:36:37 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9K7qIC05627; Fri, 20 Oct 2000 13:22:18 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 6525697E.002A2A57 ; Fri, 20 Oct 2000 13:10:33 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: multipart/mixed; Boundary="0__=pXSCOq4tyu3E9x1GEOfiKPRmEqyaOlOKPACNXoZUA3xoFU0Cwrnt4WMv" Content-Disposition: inline Message-ID: <6525697E.002A1486.00@sandesh.hss.hns.com> Date: Fri, 20 Oct 2000 13:05:32 +0530 Reply-To: chassija@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Chanchal Hassija Subject: Re: Topology X-To: Paul Hollis To: MEGACO@STANDARDS.NORTELNETWORKS.COM --0__=pXSCOq4tyu3E9x1GEOfiKPRmEqyaOlOKPACNXoZUA3xoFU0Cwrnt4WMv Content-type: text/plain; charset=us-ascii Content-Disposition: inline Hello Paul, The topology is with respect to a context and hence is not a command level descriptor.......................So during the life-time of a context......whatever topologies come in various actions get applied to the context..............one after the other........If at any point of time you refer to a term T1 in a command, then the following statements explain --- *) If at any point of time in the life of the context, you referred to term T1 as (T1,Tx, isolate) (which shall be stored in your topology descriptor) , then T1 and Tx are isolated for this command also......(if T1 did not get subtracted after the topology settings because that would flush the topology for T1) *) If at no point of time you referred to the pair (T1,Ty,..), then T1,Ty is bothways for this command.............. But remember, you have to flush the topology descriptor for T1, if T1 gets subtracted from the context................... Njoy Chanchal........... Paul Hollis on 10/19/2000 04:17:51 PM To: Chanchal Hassija/HSS@HSS cc: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Topology Hi Chanchal, thanks for the reply. However, if you take each step as being done in one command at a time, then step 2 would isolate T1 and T2, which is OK. However, once step 3 is issued in the command with only (T3, T2, oneway) specified in the command, then according to the rule quoted below any other association not mentioned in the command is set to bothway. In other words you would need to specify (T1, T2 isolate) and (T3, T2, oneway) in the one command to achieve what is shown. Does this make sense or am I on the wrong track. Regards Paul. Chanchal Hassija wrote: > Hello Paul, > > My reply is embedded and prefixed with Chan> > > I have a quick question about the topology description in H.248. > > The wording in the Topology Descriptor chapter says: > > "The default association when a termination is not mentioned in the Topology > descriptor is bothway (if T3 is added to a context with T1 and T2 with topology > (T3,T1,oneway) it will be connected bothway to T2)." > > but in the example in the diagrams, at step 3 we apply the topology "T3, T2, > oneway". I would assume that if we apply the above rule, then there should be a > bothway connection between T1 and T2. > > Chan> You need to read all the steps in sequence. Hence the two-way connection > between T1 and T2 in step 1) was broken in step 2) by the command.... > (T1,T2,Isolate).....Hence it is not there in step 3) > > Njoy.... > Chanchal........ --0__=pXSCOq4tyu3E9x1GEOfiKPRmEqyaOlOKPACNXoZUA3xoFU0Cwrnt4WMv Content-type: application/octet-stream; name="paul.hollis.vcf" Content-Disposition: attachment; filename="paul.hollis.vcf" Content-Transfer-Encoding: base64 YmVnaW46dmNhcmQgDQpuOkhvbGxpcztQYXVsDQp0ZWw7ZmF4OjkzMDEgMTEzOQ0KdGVsO3dvcms6 OTMwMSAyMzI2DQp4LW1vemlsbGEtaHRtbDpGQUxTRQ0Kb3JnOkVyaWNzc29uIEF1c3RyYWxpYS4N CmFkcjo7OztNZWxib3VybmU7VmljdG9yaWE7O0F1c3RyYWxpYQ0KdmVyc2lvbjoyLjENCmVtYWls O2ludGVybmV0OlBhdWwuSG9sbGlzQGVyaWNzc29uLmNvbS5hdQ0KdGl0bGU6U29mdHdhcmUgRGVz aWduZXIgKFNpZ25hbGxpbmcpDQp4LW1vemlsbGEtY3B0OjsxNzI2NA0KZm46UGF1bCBIb2xsaXMN CmVuZDp2Y2FyZA0KDQo= --0__=pXSCOq4tyu3E9x1GEOfiKPRmEqyaOlOKPACNXoZUA3xoFU0Cwrnt4WMv-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 05:42:40 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA07922 for ; Fri, 20 Oct 2000 05:42:39 -0400 (EDT) Received: from standards (47.234.32.16:3439) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7BF0@standards.nortelnetworks.com>; Fri, 20 Oct 2000 5:25:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32519 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 05:25:41 -0400 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7BEF@standards.nortelnetworks.com>; Fri, 20 Oct 2000 5:25:41 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA02531 for ; Fri, 20 Oct 2000 05:40:56 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA02510 for ; Fri, 20 Oct 2000 05:40:55 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA25553; Fri, 20 Oct 2000 11:40:54 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA25538; Fri, 20 Oct 2000 11:40:52 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Message-ID: <39F01376.C42AEBAE@lucent.com> Date: Fri, 20 Oct 2000 11:42:14 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: ABNF for topologyDescriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA07922 Christian, If we are making a change here, I propose that we delimit the triples by parentheses or brackets. Something like topologyDescriptor = TopologyToken LBRKT topologyTriple *(COMMA topologyTriple) RBRKT topologyTriple = LBRKT terminationA COMMA terminationB COMMA topologyDirection RBRKT Cheers, John > Date: Wed, 18 Oct 2000 11:52:32 +1100 > Reply-To: Christian Groves > Sender: "Media Gateway Control (megaco)" > > From: Christian Groves > Subject: Re: ABNF for topologyDescriptor > X-To: "Rosen, Brian" > Content-Type: text/plain; charset=iso-8859-1 > > G'Day All, > > The update I have made is: > 6.10 Topology Triples in ABNF > > Description: In the ABNF (Annex B), the term TopologyDescriptor allows > the specification of only one triple. The ASN.1 permits a sequence of > such triples. > [Begin Correction] > B.2 ABNF Specification > … > topologyDescriptor = TopologyToken LBRKT topologyTriple > *(COMMA topologyTriple) RBRKT > topologyTriple = terminationA COMMA terminationB COMMA topologyDirection > RBRKT > > [End Correction] > > Cheers, Christian -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 05:59:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA09722 for ; Fri, 20 Oct 2000 05:59:30 -0400 (EDT) Received: from standards (47.234.32.16:3439) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7C3D@standards.nortelnetworks.com>; Fri, 20 Oct 2000 5:42:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32611 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 05:42:43 -0400 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7C3C@standards.nortelnetworks.com>; Fri, 20 Oct 2000 5:42:43 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA11708 for ; Fri, 20 Oct 2000 05:57:58 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA11704 for ; Fri, 20 Oct 2000 05:57:57 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA00584; Fri, 20 Oct 2000 11:57:57 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA00577; Fri, 20 Oct 2000 11:57:55 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F01774.5CF82660@lucent.com> Date: Fri, 20 Oct 2000 11:59:16 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Error code for Max no Term in a context exceeded To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Christian, Your proposal to add an error code sounds reasonable. Cheers, John > Date: Fri, 20 Oct 2000 11:30:49 +1100 > Reply-To: Christian Groves > Sender: "Media Gateway Control (megaco)" > > From: Christian Groves > Subject: Error code for Max no Term in a context exceeded > Content-Type: text/plain; charset=us-ascii > > G'Day all, > > I had a question of: > In H.248, what Error code should be used to indicate > that a context already has the max number of terminations > in it? > > e.g. MG supports a max of 2 terminations per context; > MGC performs an ADD{C1, (T3)} to context C1 which already > has T1 and T2 in it. > > I couldn't find a appropriate error code. The closest would be > "Insufficient Resources" but I'm not sure it really covers this case. > > As such I propose either an addition to H.248 Annex L or the > implementors' guide with something like the following text: > > Error Code #: 434 Name: Max number of Terminations in a Context > exceeded. > Definition: The MGC has requested that a termination be added or moved > to a context that already contains a maximum number of termination. > Package: - > > Cheers, Christian -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 06:04:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10297 for ; Fri, 20 Oct 2000 06:04:46 -0400 (EDT) Received: from standards (47.234.32.16:3439) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7C61@standards.nortelnetworks.com>; Fri, 20 Oct 2000 5:47:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32657 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 05:47:28 -0400 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7C60@standards.nortelnetworks.com>; Fri, 20 Oct 2000 5:47:28 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA13699 for ; Fri, 20 Oct 2000 06:02:43 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA13695 for ; Fri, 20 Oct 2000 06:02:42 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA01512; Fri, 20 Oct 2000 12:02:42 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA01502; Fri, 20 Oct 2000 12:02:40 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F01891.99198CE6@lucent.com> Date: Fri, 20 Oct 2000 12:04:01 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: EventBufferDescriptor processing To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi Chanchal, I agree with your explanation, this is how I understood the eventbufferdescriptor to work as well. John > Date: Thu, 19 Oct 2000 12:09:37 +0530 > Reply-To: chassija@HSS.HNS.COM > Sender: "Media Gateway Control (megaco)" > > From: Chanchal Hassija > Subject: Re: EventBufferDescriptor processing > X-To: Dave Sclarsky > Content-type: text/plain; charset=us-ascii > > Hello Dave, > > If MG receives a new EventBufferDescriptor when EventBufferControl=LockStep, it > should not impact the the events currently in the Eventbuffer. > > But the new EventBufferDescriptor should certainly be used to buffer the new > events that occur from thereafter.... > > The events in the eventbuffer should get impacted only on arrival of a new > eventdescriptor or on activation of an embedded eventdescriptor or shall get > discarded when EventBufferControl property changes to Off from LockStep..... > > Any comments -- anybody..... > Chanchal..... > > Dave Sclarsky on 10/18/2000 10:04:22 PM > > Please respond to Dave Sclarsky > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Chanchal Hassija/HSS) > > Subject: EventBufferDescriptor processing > > Hello, > > If an MG receives an EventBufferDescriptor when EventBufferControl=LockStep, > are the events currently in the EventBuffer affected (e.g. discarded)? > > Thanks! > > ============================ > Dave Sclarsky > System Architect, Access Technology > S-Link Corporation > 520 Fellowship Road, Suite C-304 > Mt. Laurel, NJ 08054 > dsclarsky@ss7-link.com > voice:856.642.9229x231 fax:856.642.0252 > www.ss7-link.com -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 06:09:42 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA10817 for ; Fri, 20 Oct 2000 06:09:41 -0400 (EDT) Received: from standards (47.234.32.16:3439) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7C85@standards.nortelnetworks.com>; Fri, 20 Oct 2000 5:52:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32704 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 05:52:37 -0400 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7C84@standards.nortelnetworks.com>; Fri, 20 Oct 2000 5:52:37 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA15606 for ; Fri, 20 Oct 2000 06:07:52 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id GAA15602 for ; Fri, 20 Oct 2000 06:07:52 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA02757; Fri, 20 Oct 2000 12:07:51 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id MAA02744; Fri, 20 Oct 2000 12:07:50 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F019C6.FA278CFF@lucent.com> Date: Fri, 20 Oct 2000 12:09:10 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Duplicate Token To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Nurit, This has resolved in the (draft) implementor's guide. Cheers, John > Date: Wed, 11 Oct 2000 16:47:31 +0200 > Reply-To: Nurit Shenhar > Sender: "Media Gateway Control (megaco)" > > From: Nurit Shenhar > Subject: Duplicate Token > Content-Type: text/plain; charset="windows-1255" > > My problem is: > > I have bumped into the following old problem : > > > > -----Original Message----- > > From: Shiv Kumar [mailto:svkumar@HSS.HNS.COM] > > Sent: Thursday, July 06, 2000 3:03 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Duplicate Token > > > > > > Hi, > > > > A small correction in the abbreviated tokens list. > > > > The token "EB" is used for both EmbedToken and EventBufferToken. > > Pls correct it. [snip] -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 07:08:22 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA19501 for ; Fri, 20 Oct 2000 07:08:22 -0400 (EDT) Received: from standards (47.234.32.16:3824) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7D24@standards.nortelnetworks.com>; Fri, 20 Oct 2000 6:51:34 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32886 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 06:51:33 -0400 Received: from alemail1.firewall.lucent.com (alemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7D23@standards.nortelnetworks.com>; Fri, 20 Oct 2000 6:51:33 -0400 Received: from alemail1.firewall.lucent.com (localhost [127.0.0.1]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA13022 for ; Fri, 20 Oct 2000 07:06:49 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by alemail1.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id HAA13012 for ; Fri, 20 Oct 2000 07:06:48 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA13620; Fri, 20 Oct 2000 13:06:47 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id NAA13523; Fri, 20 Oct 2000 13:06:41 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Original-To: Mailing list for parties associated with ITU-T Study Group 16 , megaco@standards.nortelnetworks.com References: <39EE8F82.D61A5713@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F02790.F343CAC9@lucent.com> Date: Fri, 20 Oct 2000 13:08:00 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: H248 Implementors' Guide Draft v3 X-To: Mailing list for parties associated with ITU-T Study Group 16 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Christian, Having read your draft implementors' guide, I have a couple of comments. 1. In section 8.6 of the IG, you say that existing descriptors are retained with the Move command. I agree with the intent, but find the phrasing awkward. Strictly speaking, descriptors are defined as groups of parameters to commands. So I think it would be better to say something like "The Move command does not affect the properties of the Termination on which it operates, except those properties explicitly modified by descriptors included in the Move command." 2. Section 8.7 proposes a correction to E.6.4. If I'm not mistaken, it is actually a correction to E.6.2, and you should add "..."-dots between "Section E.6.2 Events" and "DigitMap Completion Event". In that correction there is an undefined reference that should be replaced by a reference to 7.1.14. 3. Section 8.10 proposes that event and signal parameters starting with "SPA" and "EPA" be forbidden. I have to think whether this is the best resolution to the problem of ambiguity, but until I have done so, I want to point out a mistake in the proposed addition to 13.1. This addition implies that package names must not start with "SPA" or "EPA". However, the ambiguity is not related to package names but to parameters of signals and events. Instead of your proposed change to 13.1, I propose that additional text be added to 12.2: [Begin Correction] 12.1 Guidelines to defining Properties, Statistics and Parameters to Events and Signals Parameter Name: only descriptive ParameterID: Is an identifier. The textual ParameterID of parameters to Events and Signals shall not start with "EPA" and "SPA", respectively. [End Correction] 4. Section 9.3 proposes clarifying text for the use of wildcarded responses in audits. The final example shows that the reply to Context=*{W-Audit=t1/*{Audit{Packages}} is Context=*{W-Audit=t1/*{Packages{aaa,bbb,ccc,ddd}} although Terminations t1/1 and t1/2 only implement packages aaa and bbb. So the ",ccc,ccc" part has to be removed from the response, or example has to be changed to something like Context=*{W-Audit=*/*{Audit{Packages}} returns Context=*{W-Audit=*/*{Packages{aaa,bbb,ccc,ddd}} Cheers, John Christian Groves wrote: > > G'Day all, > > Attached is a copy of the H.248 Implementors' Guide v3. It "hopefully" > contains the corrections and clarifications that have been discussed on > the Megaco mailing list until the 19/10/2000. > > If anything is missed or erroneous please let me (and the list) know. > > The file will also be upload to the pictel server: > ftp://standard.pictel.com/avc-site/incoming/H248_Implementors_Guide_v3.zip > Both PDF and Word versions are available. > > My intention is to make one more update (v4) before sending to the Nov > Sg16 meeting for approval. > > Cheers, Christian > > PS: Please forgive me sending a 98k file to the list but the Pictel > server has been down. > > ------------------------------------------------------------------------ > Name: H248_Implementors_Guide_v3.zip > H248_Implementors_Guide_v3.zip Type: Winzip32 File (application/x-zip-compressed) > Encoding: base64 -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 07:52:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25318 for ; Fri, 20 Oct 2000 07:52:59 -0400 (EDT) Received: from standards (47.234.32.16:1203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7D57@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:36:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32946 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 07:36:13 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7D56@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:36:13 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA28903; Fri, 20 Oct 2000 07:51:26 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA18582; Fri, 20 Oct 2000 07:51:28 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BV22F8>; Fri, 20 Oct 2000 07:51:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E84D@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 20 Oct 2000 07:51:25 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Statistics X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Well we don't "format statistics" in a certain way to, say, allow you to differentiate # of packets sent for video from # of packets sent for audio. Seems to me it needs to be addressed somehow. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Thursday, October 19, 2000 7:23 PM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Statistics > > > This has been something thats been around for a long time and > I thought > people were pretty aware of this. I don't think its a bug per > se as you > can handle it formatting your statistics in a certain way. > Certainly in > v2 it would be nice to allow statistics on streams. Its a fairly big > change to me for an implementors' guide. > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > Oh cool. I don't think we have ever talked about this, > > stream specific statistics! Hmmmmm. > > > > So we would want to add (an optional) StreamId to > Statistics Descriptor > > Statistics=1{rtp/pr=.... > > and you might get more than one Statistics descriptor in the reply. > > > > Wow. This is a real bug in the protocol I think! > > > > Brian > > > > > -----Original Message----- > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > Sent: Thursday, October 19, 2000 9:51 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Statistics > > > > > > > > > Section E.12.4 states that statistics like > > > jitter, packet loss,etc are described on an > > > RTP stream. If only one RTP stream is > > > present on a termination its straitforward > > > to send statistics. But if multiple streams > > > are created on a termination How this > > > reporting is done? > > > > > > -Madhubabu > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 07:53:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25326 for ; Fri, 20 Oct 2000 07:52:59 -0400 (EDT) Received: from standards (47.234.32.16:1203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7D69@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:37:42 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32968 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 07:37:42 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7D68@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:37:42 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA28974; Fri, 20 Oct 2000 07:52:55 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA18686; Fri, 20 Oct 2000 07:52:57 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRS45J>; Fri, 20 Oct 2000 07:52:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E84E@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 20 Oct 2000 07:52:56 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Error code for Max no Term in a context exceeded X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'd support the additional error message. Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Thursday, October 19, 2000 8:31 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Error code for Max no Term in a context exceeded > > > G'Day all, > > I had a question of: > In H.248, what Error code should be used to indicate > that a context already has the max number of terminations > in it? > > e.g. MG supports a max of 2 terminations per context; > MGC performs an ADD{C1, (T3)} to context C1 which already > has T1 and T2 in it. > > I couldn't find a appropriate error code. The closest would be > "Insufficient Resources" but I'm not sure it really covers this case. > > As such I propose either an addition to H.248 Annex L or the > implementors' guide with something like the following text: > > Error Code #: 434 Name: Max number of Terminations in a Context > exceeded. > Definition: The MGC has requested that a termination be added or moved > to a context that already contains a maximum number of termination. > Package: - > > Cheers, Christian > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 07:57:34 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA25933 for ; Fri, 20 Oct 2000 07:57:33 -0400 (EDT) Received: from standards (47.234.32.16:1203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7D80@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:39:30 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 32997 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 07:39:30 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7D7F@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:39:29 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA29070; Fri, 20 Oct 2000 07:54:43 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA18920; Fri, 20 Oct 2000 07:54:45 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRS46B>; Fri, 20 Oct 2000 07:54:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E84F@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 20 Oct 2000 07:54:43 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Statistics Auditing X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Yes, please Christian, Implementer's Guide note: statisticsParameterr = pkgd Name (EQUAL VALUE) Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Friday, October 20, 2000 3:02 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Statistics Auditing > > > In section 7.2.6 for Audit capability its stated that > "StatisticsDescriptor returns the names of the > statistics being kept on the termination." > > But the ABNF grammar states the descriptor as > > "statisticsDescriptor = StatsToken LBRKT statisticsParameter > *(COMMA statisticsParameter ) RBRKT > > ;at-most-once per item > statisticsParameter = pkgdName EQUAL VALUE" > > which doesn't allow specification of stats parameter always > with value. > If only names needs to be sent from MG, the value field > needs to be made option. > > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 08:01:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA26425 for ; Fri, 20 Oct 2000 08:01:20 -0400 (EDT) Received: from standards (47.234.32.16:1203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7DB5@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:44:27 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33068 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 07:44:27 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7DB4@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:44:26 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA29300; Fri, 20 Oct 2000 07:59:40 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id HAA19516; Fri, 20 Oct 2000 07:59:42 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRS481>; Fri, 20 Oct 2000 07:59:30 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E850@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 20 Oct 2000 07:59:41 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: ABNF for topologyDescriptor X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM I don't like this addition, as it breaks "current" implementations. Maybe: topologyDescriptor = TopologyToken topologyTriple | ( LBRKT topologyTriple *(COMMA topologyTriple) RBRKT ) topologyTriple = LBRKT terminationA COMMA terminationB COMMA topologyDirection RBRKT > -----Original Message----- > From: John Segers [mailto:jsegers@LUCENT.COM] > Sent: Friday, October 20, 2000 5:42 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: ABNF for topologyDescriptor > > > Christian, > > If we are making a change here, I propose that we delimit the > triples by > parentheses or brackets. Something like > > topologyDescriptor = TopologyToken LBRKT topologyTriple > *(COMMA topologyTriple) RBRKT > topologyTriple = LBRKT terminationA COMMA terminationB COMMA > topologyDirection RBRKT > > Cheers, > > John > > > Date: Wed, 18 Oct 2000 11:52:32 +1100 > > Reply-To: Christian Groves > > Sender: "Media Gateway Control (megaco)" > > > > From: Christian Groves > > Subject: Re: ABNF for topologyDescriptor > > X-To: "Rosen, Brian" > > Content-Type: text/plain; charset=iso-8859-1 > > > > G'Day All, > > > > The update I have made is: > > 6.10 Topology Triples in ABNF > > > > Description: In the ABNF (Annex B), the term > TopologyDescriptor allows > > the specification of only one triple. The ASN.1 permits a > sequence of > > such triples. > > [Begin Correction] > > B.2 ABNF Specification > > ... > > topologyDescriptor = TopologyToken LBRKT topologyTriple > > *(COMMA topologyTriple) RBRKT > > topologyTriple = terminationA COMMA terminationB COMMA > topologyDirection > > RBRKT > > > > [End Correction] > > > > Cheers, Christian > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 08:07:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA27231 for ; Fri, 20 Oct 2000 08:07:46 -0400 (EDT) Received: from standards (47.234.32.16:1203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7DF9@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:51:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33150 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 07:51:56 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7DF8@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:51:55 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA29765; Fri, 20 Oct 2000 08:07:09 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA20486; Fri, 20 Oct 2000 08:07:11 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BV22M8>; Fri, 20 Oct 2000 08:07:06 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E851@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 20 Oct 2000 08:07:09 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: wildcarded termination in Move X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id IAA27231 I did think it was not allowed, but since I think we need it, I'm more than happy to use your interpretation! Brian > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > Sent: Thursday, October 19, 2000 8:02 PM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: wildcarded termination in Move > > > G'Day all, > > I'm really confused now, taking sentences out of context (pardon the > pun) can add a little confusion. > > The MOVE command chapter in H248 doesn't not prohibit moving a > termination to Context "?". It mentions target Context ID. > > The Context chapter says: > "In general, an Add command is used to add Terminations to > Contexts." > and the sentence after: > "If the MGC does not specify an existing Context to which the > Termination is to be added, the MG creates a new Context.talks about > that if Context "?" is specified then a context ID is provided." > > The "In general" statement cited below is in the sentence about a > termination "?" and an ADD command. > > The "If the MG...." statements talks about Context "?". > > MOVE Context "?", ta seems to me to be a fundamental part of what we > defined and I don't see where this is disallowed. To clarify things at > most you could put a CR linefeed after the in general sentence above. > > Cheers, Christian > > > "Rosen, Brian" wrote: > > > > Woops, sorry, didn't pay close enough attention. Your > example has TWO > > RTP streams and no physical terminations. Unusual, but legal. > > > > Well, I'm stuck. I can think of stupid things to do, but nothing > > that looks useful. Maybe a change is warranted. > > > > Need other opinions on allowing Context=${Move=... > > > > Brian > > > > > -----Original Message----- > > > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > > > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > > > Sent: Thursday, October 19, 2000 9:45 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: wildcarded termination in Move > > > > > > > > > I don't understand your solution: T1 is an ephemeral > > > Termination: its TermID > > > is not provisionned in the MG. As soon as T1 is > subtracted from C1, it > > > disappears, and its TermID too. How can the MGC re-use this > > > TermID to add it > > > to a new Context? > > > Can the MGC set the TermID of an ephemeral Termination when > > > it creates it? > > > > > > > > > ``` > > > (o o) > > > ----------oOO--(_)-OOo-------------- > > > Jean-Emmanuel CHAPRON > > > FRANCE TELECOM R&D > > > DAC/ACE > > > 38-40 rue du général Leclerc > > > 92794 Issy-les-Moulineaux Cedex 9 - France > > > Tel: +33 1 45 29 64 50 > > > ------------------------------------- > > > > > > > > > > > > > -----Message d'origine----- > > > > De : Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > > > Envoyé : jeudi 19 octobre 2000 15:34 > > > > À : 'CHAPRON Jean-Emmanuel FTRD/DAC/ISS'; > > > > MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Objet : RE: wildcarded termination in Move > > > > > > > > > > > > I may be finessing the answer but > > > > Context=1{Subtract=T1.... > > > > Context=${Add=T1... > > > > gets you an equivalent > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > > > > > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > > > > > Sent: Thursday, October 19, 2000 5:02 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > Hello Brian, all > > > > > > > > > > If things are left as they are, it seems that the case > > > > > described below is > > > > > simply impossible: > > > > > > > > > > (1) > > > > > | > > > > +-------------------------------------------------+ | > > > > > | |Context C1 > > > > | | > > > > > | | +-------------+ > > > > +-------------+ | | > > > > > | | | (Term. T1) | +-----+ | (Term. > > > > T2) | | | > > > > > <-+--->| RTP Stream |---| * |------| RTP Stream > > > > > |<---+-> > > > > > | | +-------------+ +-----+ > > > > +-------------+ | | > > > > > | > > > > +-------------------------------------------------+ | > > > > > (2) > > > > > > > > > > | > > > > +-------------------------------------------------+ | > > > > > | |Context C1 > > > > | | > > > > > | | +-------------+ > > > > > | | > > > > > | | | (Term. T1) | +-----+ > > > > | | > > > > > <-+--->| RTP Stream |---| * | > > > > | | > > > > > | | +-------------+ +-----+ > > > > | | > > > > > | > > > > +-------------------------------------------------+ | > > > > > | > > > > +-------------------------------------------------+ | > > > > > | |Context C2 > > > > | | > > > > > | | > > > > +-------------+ | | > > > > > | | +-----+ | (Term. > > > > T2) | | | > > > > > | | | * |------| RTP Stream > > > > > |<---+-> > > > > > | | +-----+ > > > > +-------------+ | | > > > > > | > > > > +-------------------------------------------------+ | > > > > > > > > > > > > > > > C2 didn't exist in (1). How to go from (1) to (2)? > > > > > - We can't use a MOVE $ (too bad..) > > > > > - we can't use Context = $ {Add = T2} because T2 is in a > > > > > non-NULL context > > > > > - we can't use "Subtract/Add" because we have only RTP > > > > > Terminations we don't > > > > > want to remove. > > > > > > > > > > This is not a textbook case, as far as this case may occur > > > > if the Call > > > > > Server/MGC is connected to the IN and receives, for > > > > instance, an INAP > > > > > "SplitLeg" message requiring such an handling of connections. > > > > > > > > > > Regards, > > > > > > > > > > > > > > > ``` > > > > > (o o) > > > > > ----------oOO--(_)-OOo-------------- > > > > > Jean-Emmanuel CHAPRON > > > > > FRANCE TELECOM R&D > > > > > DAC/ACE > > > > > 38-40 rue du général Leclerc > > > > > 92794 Issy-les-Moulineaux Cedex 9 - France > > > > > Tel: +33 1 45 29 64 50 > > > > > ------------------------------------- > > > > > > > > > > > > > > > > > > > > > -----Message d'origine----- > > > > > > De : Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > > > > Envoyé : mercredi 18 octobre 2000 15:01 > > > > > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Objet : Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > Ya, that's one of the reasons it's probably there - > separating > > > > > > functions of Move and Add. > > > > > > > > > > > > Probably best to leave things as they are. > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > > > > > > > Sent: Wednesday, October 18, 2000 8:29 AM > > > > > > > To: Rosen, Brian > > > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > > > > > If you remove this restriction then why you need > Move, i will > > > > > > > always use Add to > > > > > > > either: > > > > > > > 1. Add a termination to a context from null context > > > > > > > 2. Move (read it as Add) a termination to a context from a > > > > > > > non-NULL context. > > > > > > > > > > > > > > -Kapil Nayar > > > > > > > Hughes Software Systems > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/18/2000 > > > > 05:31:06 PM > > > > > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > > cc: (bcc: Kapil Nayar/HSS) > > > > > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Only Add can create a new context: > > > > > > > "In general, an Add command is used to add Terminations > > > > > > to Contexts. > > > > > > > If the MGC does not specify an existing Context to > > > which the > > > > > > > Termination is to be added, the MG creates a new > > > Context. " > > > > > > > > > > > > > > A way to do the consultation hold is to create the new > > > > > context with > > > > > > > C and move A to that Context. > > > > > > > > > > > > > > I'll note that I was a little surprised to read: > > > > > > > "The Termination is either created, or taken from the > > > > > null Context" > > > > > > > (although I may have wrote it!), since this prohibits > > > an Add of > > > > > > > a termination already in another context. I'm > not sure why we > > > > > > > prohibit that. I do think there is little practical > > > > difficulty in > > > > > > > keeping that restriction. If we did relax that > > > restriction, you > > > > > > > could do Context=${Add=A{.... > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > > > > > > > Sent: Wednesday, October 18, 2000 12:40 AM > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > Hi Brian, > > > > > > > > > > > > > > > > If you mean to say that Move with ContextID = $ is > > > > > > > > nonsensical --- I beg to > > > > > > > > differ...... > > > > > > > > > > > > > > > > Consider a simple call scenario -- A is talking to > > > B..... and > > > > > > > > now A wants to put > > > > > > > > B on hold and call up C......The simplest way to do > > > it as per > > > > > > > > my understanding > > > > > > > > would be -- MGC shall tell MG to Move A to a new context > > > > > > > > (Move - ContextID=$ and > > > > > > > > TermID = A) where it shall talk to C, and once > it is done, > > > > > > > > move it back to the > > > > > > > > context where it was talking to B...... > > > > > > > > > > > > > > > > What is your opinion about this.... > > > > > > > > > > > > > > > > Thanks > > > > > > > > Chanchal.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 > > > > > 05:57:41 PM > > > > > > > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If there are three terminations in an MG > > > > > > > > > abcd > > > > > > > > > abce > > > > > > > > > xyz. > > > > > > > > > Say abcd is in Context ID = 1 and both abce > and xyz is in > > > > > > > > > NULL Context. > > > > > > > > > If MGC says Move with ContextID = $ and > > > termination as abc*, > > > > > > > > > what should the > > > > > > > > > MG do > > > > > > > > First of all, I think this is illegal, or at least > > > > nonsensical. > > > > > > > > You CAN'T create a new contextId with CHOOSE. > > > > > > > > So if it is legal, you are asking for Russian > > > Roulette - pick > > > > > > > > a context where the resulting command would be legal, > > > > and do it. > > > > > > > > If there is more than one, then it's random which one > > > > > > > > > > > > > > > > > 1. Consider abce while resolving wildcarded abc* - > > > > > > > > > Move is valid for abcd (it's in non-NULL context) and > > > > > > invalid for > > > > > > > > > abce (move is not allowed to move from and to a > > > > NULL Context) > > > > > > > > abcd is valid, abce is not valid > > > > > > > > > > > > > > > > > 2. Don't consider terminations in NULL Context > > > for resolving > > > > > > > > > wildcard since > > > > > > > > > the basic idea is not to Move to or from NULL Context. > > > > > > > > This is correct > > > > > > > > > > > > > > > > > > > > > > > > > > The first option has an impact on further > commands in the > > > > > > > > > transaction since a > > > > > > > > > failure > > > > > > > > > with one command can cause the side effect of > > > other commands > > > > > > > > > being not executed. > > > > > > > > True, but in general if the MGC was foolish enough > > > to do this, > > > > > > > > it deserves what it gets. > > > > > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 08:15:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA28262 for ; Fri, 20 Oct 2000 08:15:50 -0400 (EDT) Received: from standards (47.234.32.16:1203) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7E29@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:56:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 33213 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 07:56:06 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA7E28@standards.nortelnetworks.com>; Fri, 20 Oct 2000 7:56:06 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA00017; Fri, 20 Oct 2000 08:11:20 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA21114; Fri, 20 Oct 2000 08:11:22 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BV22P1>; Fri, 20 Oct 2000 08:11:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E852@whq-msgusr-02.pit.comms.marconi.com> Date: Fri, 20 Oct 2000 08:11:20 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: RequestId in observed events descriptor. X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'd say you use the requestId of the last EventsDescriptor. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Friday, October 20, 2000 1:26 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: RequestId in observed events descriptor. > > > Hi, > what is the RequestId that needs to be sent from MG when > "observedevents" are > Audited? In section 7.1.17 its specifies that > "ObservedEvents contains the > RequestIdentifier of the EventsDescriptor that triggered the > notification" > but this notification of observed events is not triggered by > any events > descriptor. and the event buffer descriptor doesnot have a > requestid field. > -Madhubabu. > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 12:00:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA06258 for ; Fri, 20 Oct 2000 12:00:09 -0400 (EDT) Received: from standards (47.234.32.16:3281) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8105@standards.nortelnetworks.com>; Fri, 20 Oct 2000 11:43:07 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34137 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 11:43:06 -0400 Received: from mailman.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8104@standards.nortelnetworks.com>; Fri, 20 Oct 2000 11:43:06 -0400 Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id IAA21007 for ; Fri, 20 Oct 2000 08:58:21 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F06CC5.DC1AFF76@cisco.com> Date: Fri, 20 Oct 2000 12:03:18 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: Signal lists To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Greetings A couple of questions on signal lists: - What does it mean for individual signals in a signal list to have the KeepActive flag set and how come the signal list itself doesn't have such a flag (keeping in mind that "A signal list is treated as a single signal of the specified type when played out.") ? - In the definition of Signal Completion (E.1.2) it says "Possible values: a list of signals and/or sequential signal lists which have terminated.". Does that mean that completion of a signal list itself generates a "signal completion" event ? - A related question for clarification. If a signal in the signal list has the "notifyCompletion" flag set, I assume the event will be generated when that particular signal finished, right ? Thanks Flemming -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 13:58:35 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA20737 for ; Fri, 20 Oct 2000 13:58:35 -0400 (EDT) Received: from standards (47.234.32.16:3539) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8221@standards.nortelnetworks.com>; Fri, 20 Oct 2000 13:41:38 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34512 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 13:41:37 -0400 Received: from outside.whiterocknetworks.com (64-48-28-18.customer.algx.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA821D@standards.nortelnetworks.com>; Fri, 20 Oct 2000 13:31:37 -0400 Received: from [192.168.1.220] by outside.whiterocknetworks.com for MEGACO@STANDARDS.NORTELNETWORKS.COM id MAA16094; Fri Oct 20 12:46:53 2000 Received: by 192-168-1-220.customer.algx.net with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Oct 2000 12:43:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <758F0C2C951CD411B15300D0B74444653EECAA@192-168-1-220.customer.algx.net> Date: Fri, 20 Oct 2000 12:43:43 -0500 Reply-To: "Nguyen, Chuong" Sender: "Media Gateway Control (megaco)" From: "Nguyen, Chuong" Subject: Re: wildcarded termination in Move X-To: Bob Lukas To: MEGACO@STANDARDS.NORTELNETWORKS.COM -----Original Message----- From: Bob Lukas [mailto:blukas@BROADCOM.COM] Sent: Wednesday, October 18, 2000 12:59 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: wildcarded termination in Move One good reason for allowing MOVE $ is if the MGC wants to implement on-hold by moving the ephermeral RTP termination to a "holding context", rather than moving the physical termination. General comment: To either put the physical or ephemeral term on hold, one could use the topology/isolate instead of creating a hold context. From the original question after isolating the required termination, one can add Termination C to the same context. Therefore a Move would not even be needed to start with. But if one really wants to use a Move, one should Add Term C first. Otherwise if there was an error in Adding Term C, one would have to clean - either Move Term A back to the original context or cleanup both contexts. Another good reason is if the logic of the MGC wants to implement handsfree/handset transfer by moving the existing RTP to a new context, then adding the physical termination. In both these cases, a subtract/add is not equivalent to a move, because the ephermeral termination will get destroyed during the subtract. You could force the MGC developer to modify his logic to do it another way, but why unnecessarily create restrictions. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Wednesday, October 18, 2000 5:44 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: wildcarded termination in Move Yes, but it's not all that compelling. Add is a special case of Move - you don't really need Add/Subtract, you could do it all with Move. We tried to keep the functions separate by restricting move to the clear case of from this context to that context, with Add being the command you usually use for creating new contexts or dealing with terminations in null. Like I said, not all that compelling. Brian > -----Original Message----- > From: chassija@hss.hns.com [mailto:chassija@hss.hns.com] > Sent: Wednesday, October 18, 2000 8:01 AM > To: Rosen, Brian > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: RE: wildcarded termination in Move > > > > > Hello Brian.... > > Do we have any logical reasoning to prohibit MOVE of a termination to > contextID=$.... apart from the fact that it is stated in the > protocol....... > > Thanks > Chanchal..... > > > > > > "Rosen, Brian" on 10/18/2000 05:31:06 PM > > To: Chanchal Hassija/HSS@HSS, MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: > > Subject: RE: wildcarded termination in Move > > > > > Only Add can create a new context: > "In general, an Add command is used to add Terminations to Contexts. > If the MGC does not specify an existing Context to which the > Termination is to be added, the MG creates a new Context. " > > A way to do the consultation hold is to create the new context with > C and move A to that Context. > > I'll note that I was a little surprised to read: > "The Termination is either created, or taken from the null Context" > (although I may have wrote it!), since this prohibits an Add of > a termination already in another context. I'm not sure why we > prohibit that. I do think there is little practical difficulty in > keeping that restriction. If we did relax that restriction, you > could do Context=${Add=A{.... > > Brian > > > -----Original Message----- > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > Sent: Wednesday, October 18, 2000 12:40 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: wildcarded termination in Move > > > > > > Hi Brian, > > > > If you mean to say that Move with ContextID = $ is > > nonsensical --- I beg to > > differ...... > > > > Consider a simple call scenario -- A is talking to B..... and > > now A wants to put > > B on hold and call up C......The simplest way to do it as per > > my understanding > > would be -- MGC shall tell MG to Move A to a new context > > (Move - ContextID=$ and > > TermID = A) where it shall talk to C, and once it is done, > > move it back to the > > context where it was talking to B...... > > > > What is your opinion about this.... > > > > Thanks > > Chanchal.... > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 05:57:41 PM > > > > Please respond to "Rosen, Brian" > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Chanchal Hassija/HSS) > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > If there are three terminations in an MG > > > abcd > > > abce > > > xyz. > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > NULL Context. > > > If MGC says Move with ContextID = $ and termination as abc*, > > > what should the > > > MG do > > First of all, I think this is illegal, or at least nonsensical. > > You CAN'T create a new contextId with CHOOSE. > > So if it is legal, you are asking for Russian Roulette - pick > > a context where the resulting command would be legal, and do it. > > If there is more than one, then it's random which one > > > > > 1. Consider abce while resolving wildcarded abc* - > > > Move is valid for abcd (it's in non-NULL context) and invalid for > > > abce (move is not allowed to move from and to a NULL Context) > > abcd is valid, abce is not valid > > > > > 2. Don't consider terminations in NULL Context for resolving > > > wildcard since > > > the basic idea is not to Move to or from NULL Context. > > This is correct > > > > > > > > The first option has an impact on further commands in the > > > transaction since a > > > failure > > > with one command can cause the side effect of other commands > > > being not executed. > > True, but in general if the MGC was foolish enough to do this, > > it deserves what it gets. > > > > Brian > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 14:14:51 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA22579 for ; Fri, 20 Oct 2000 14:14:51 -0400 (EDT) Received: from standards (47.234.32.16:3539) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8243@standards.nortelnetworks.com>; Fri, 20 Oct 2000 13:57:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34559 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 13:57:48 -0400 Received: from outside.whiterocknetworks.com (64-48-28-18.customer.algx.net) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8242@standards.nortelnetworks.com>; Fri, 20 Oct 2000 13:57:48 -0400 Received: from [192.168.1.220] by outside.whiterocknetworks.com for MEGACO@STANDARDS.NORTELNETWORKS.COM id NAA18202; Fri Oct 20 13:13:04 2000 Received: by 192-168-1-220.customer.algx.net with Internet Mail Service (5.5.2650.21) id ; Fri, 20 Oct 2000 13:10:01 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <758F0C2C951CD411B15300D0B74444653EECAC@192-168-1-220.customer.algx.net> Date: Fri, 20 Oct 2000 13:09:50 -0500 Reply-To: "Nguyen, Chuong" Sender: "Media Gateway Control (megaco)" From: "Nguyen, Chuong" Subject: Re: wildcarded termination in Move X-To: "Rupsis, Paul" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA22579 -----Original Message----- From: Rupsis, Paul [mailto:Paul.Rupsis@DIALOGIC.COM] Sent: Thursday, October 19, 2000 2:47 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: wildcarded termination in Move > there needs to be a means (for a service as simple as call holding) > to temporarily 'separate' terminations being in the same context > whatever their nature (physical/ephemeral) Isn't that what Topology provides (e.g., Context = C1 {Topology{T1, T2, isolate}} ) One problem with enabling Moves of terminations in and out of contexts is that statistics are reset. I think only Subtract can reset statistics. Move does not reset statistics. Paul Rupsis -----Original Message----- From: Fabien Capoen [mailto:Fabien.Capoen@ALCATEL.FR] Sent: Thursday, October 19, 2000 10:10 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: wildcarded termination in Move If I can dare to speak on this list ... (to introduce myself, I work on 'NGN' standards for alcatel), on this subject I have the following thoughts: - there needs to be a mean (for a service as simple as call holding) to temporarily 'separate' terminations being in the same context whatever their nature (physical/ephemeral) - the 'Context=${Move=' solution seems the only one (we could think of 2 other ones: the first to allow add on terminations being in a not null context, but this one has already been rejected because it breaks the add/move complementarity - move becomes just a special case of add; the second being a special NULL-like context: the ONHOLD context, for ephemeral terminations. This one is not very elegant) - the 'Context=${Move=' solution does not break the add/move complementarity: add remains reserved for non existing terminations or terminations in the null context, whereas move is reserved for terminations in a not null context - I have looked in the standard, and I could not see it explicitely forbidden. The only thing is that it is not explicitely allowed: in §6.1, the creation of a new context is only described for the add command. Changing 'In general, an Add command is used to add Terminations to Contexts' of §6.1 into 'In general, an Add OR MOVE command is used to add Terminations to Contexts' could solve the problem. And really, isn't it true to say that move also adds terminations to a context ? Isn't the only difference between move and add on the nature of the termination on which the add/move is applied ? The question I have is then: what concrete problems do people see with allowing 'context=$' in a move request ? Regards ... Fabien C. Please respond to "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Fabien CAPOEN/FR/ALCATEL) Subject: Re: wildcarded termination in Move Woops, sorry, didn't pay close enough attention. Your example has TWO RTP streams and no physical terminations. Unusual, but legal. Well, I'm stuck. I can think of stupid things to do, but nothing that looks useful. Maybe a change is warranted. Need other opinions on allowing Context=${Move=... Brian > -----Original Message----- > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > Sent: Thursday, October 19, 2000 9:45 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: wildcarded termination in Move > > > I don't understand your solution: T1 is an ephemeral > Termination: its TermID > is not provisionned in the MG. As soon as T1 is subtracted from C1, it > disappears, and its TermID too. How can the MGC re-use this > TermID to add it > to a new Context? > Can the MGC set the TermID of an ephemeral Termination when > it creates it? > > > ``` > (o o) > ----------oOO--(_)-OOo-------------- > Jean-Emmanuel CHAPRON > FRANCE TELECOM R&D > DAC/ACE > 38-40 rue du général Leclerc > 92794 Issy-les-Moulineaux Cedex 9 - France > Tel: +33 1 45 29 64 50 > ------------------------------------- > > > > > -----Message d'origine----- > > De : Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Envoyé : jeudi 19 octobre 2000 15:34 > > À : 'CHAPRON Jean-Emmanuel FTRD/DAC/ISS'; > > MEGACO@STANDARDS.NORTELNETWORKS.COM > > Objet : RE: wildcarded termination in Move > > > > > > I may be finessing the answer but > > Context=1{Subtract=T1.... > > Context=${Add=T1... > > gets you an equivalent > > > > Brian > > > > > -----Original Message----- > > > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > > > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > > > Sent: Thursday, October 19, 2000 5:02 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: wildcarded termination in Move > > > > > > > > > Hello Brian, all > > > > > > If things are left as they are, it seems that the case > > > described below is > > > simply impossible: > > > > > > (1) > > > | > > +-------------------------------------------------+ | > > > | |Context C1 > > | | > > > | | +-------------+ > > +-------------+ | | > > > | | | (Term. T1) | +-----+ | (Term. > > T2) | | | > > > <-+--->| RTP Stream |---| * |------| RTP Stream > > > |<---+-> > > > | | +-------------+ +-----+ > > +-------------+ | | > > > | > > +-------------------------------------------------+ | > > > (2) > > > > > > | > > +-------------------------------------------------+ | > > > | |Context C1 > > | | > > > | | +-------------+ > > > | | > > > | | | (Term. T1) | +-----+ > > | | > > > <-+--->| RTP Stream |---| * | > > | | > > > | | +-------------+ +-----+ > > | | > > > | > > +-------------------------------------------------+ | > > > | > > +-------------------------------------------------+ | > > > | |Context C2 > > | | > > > | | > > +-------------+ | | > > > | | +-----+ | (Term. > > T2) | | | > > > | | | * |------| RTP Stream > > > |<---+-> > > > | | +-----+ > > +-------------+ | | > > > | > > +-------------------------------------------------+ | > > > > > > > > > C2 didn't exist in (1). How to go from (1) to (2)? > > > - We can't use a MOVE $ (too bad..) > > > - we can't use Context = $ {Add = T2} because T2 is in a > > > non-NULL context > > > - we can't use "Subtract/Add" because we have only RTP > > > Terminations we don't > > > want to remove. > > > > > > This is not a textbook case, as far as this case may occur > > if the Call > > > Server/MGC is connected to the IN and receives, for > > instance, an INAP > > > "SplitLeg" message requiring such an handling of connections. > > > > > > Regards, > > > > > > > > > ``` > > > (o o) > > > ----------oOO--(_)-OOo-------------- > > > Jean-Emmanuel CHAPRON > > > FRANCE TELECOM R&D > > > DAC/ACE > > > 38-40 rue du général Leclerc > > > 92794 Issy-les-Moulineaux Cedex 9 - France > > > Tel: +33 1 45 29 64 50 > > > ------------------------------------- > > > > > > > > > > > > > -----Message d'origine----- > > > > De : Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > > Envoyé : mercredi 18 octobre 2000 15:01 > > > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Objet : Re: wildcarded termination in Move > > > > > > > > > > > > Ya, that's one of the reasons it's probably there - separating > > > > functions of Move and Add. > > > > > > > > Probably best to leave things as they are. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > > > > > Sent: Wednesday, October 18, 2000 8:29 AM > > > > > To: Rosen, Brian > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > If you remove this restriction then why you need Move, i will > > > > > always use Add to > > > > > either: > > > > > 1. Add a termination to a context from null context > > > > > 2. Move (read it as Add) a termination to a context from a > > > > > non-NULL context. > > > > > > > > > > -Kapil Nayar > > > > > Hughes Software Systems > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/18/2000 > > 05:31:06 PM > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > cc: (bcc: Kapil Nayar/HSS) > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > Only Add can create a new context: > > > > > "In general, an Add command is used to add Terminations > > > > to Contexts. > > > > > If the MGC does not specify an existing Context to > which the > > > > > Termination is to be added, the MG creates a new > Context. " > > > > > > > > > > A way to do the consultation hold is to create the new > > > context with > > > > > C and move A to that Context. > > > > > > > > > > I'll note that I was a little surprised to read: > > > > > "The Termination is either created, or taken from the > > > null Context" > > > > > (although I may have wrote it!), since this prohibits > an Add of > > > > > a termination already in another context. I'm not sure why we > > > > > prohibit that. I do think there is little practical > > difficulty in > > > > > keeping that restriction. If we did relax that > restriction, you > > > > > could do Context=${Add=A{.... > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > > > > > Sent: Wednesday, October 18, 2000 12:40 AM > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > Hi Brian, > > > > > > > > > > > > If you mean to say that Move with ContextID = $ is > > > > > > nonsensical --- I beg to > > > > > > differ...... > > > > > > > > > > > > Consider a simple call scenario -- A is talking to > B..... and > > > > > > now A wants to put > > > > > > B on hold and call up C......The simplest way to do > it as per > > > > > > my understanding > > > > > > would be -- MGC shall tell MG to Move A to a new context > > > > > > (Move - ContextID=$ and > > > > > > TermID = A) where it shall talk to C, and once it is done, > > > > > > move it back to the > > > > > > context where it was talking to B...... > > > > > > > > > > > > What is your opinion about this.... > > > > > > > > > > > > Thanks > > > > > > Chanchal.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 > > > 05:57:41 PM > > > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If there are three terminations in an MG > > > > > > > abcd > > > > > > > abce > > > > > > > xyz. > > > > > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > > > > > NULL Context. > > > > > > > If MGC says Move with ContextID = $ and > termination as abc*, > > > > > > > what should the > > > > > > > MG do > > > > > > First of all, I think this is illegal, or at least > > nonsensical. > > > > > > You CAN'T create a new contextId with CHOOSE. > > > > > > So if it is legal, you are asking for Russian > Roulette - pick > > > > > > a context where the resulting command would be legal, > > and do it. > > > > > > If there is more than one, then it's random which one > > > > > > > > > > > > > 1. Consider abce while resolving wildcarded abc* - > > > > > > > Move is valid for abcd (it's in non-NULL context) and > > > > invalid for > > > > > > > abce (move is not allowed to move from and to a > > NULL Context) > > > > > > abcd is valid, abce is not valid > > > > > > > > > > > > > 2. Don't consider terminations in NULL Context > for resolving > > > > > > > wildcard since > > > > > > > the basic idea is not to Move to or from NULL Context. > > > > > > This is correct > > > > > > > > > > > > > > > > > > > > The first option has an impact on further commands in the > > > > > > > transaction since a > > > > > > > failure > > > > > > > with one command can cause the side effect of > other commands > > > > > > > being not executed. > > > > > > True, but in general if the MGC was foolish enough > to do this, > > > > > > it deserves what it gets. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Fri Oct 20 14:28:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24056 for ; Fri, 20 Oct 2000 14:27:59 -0400 (EDT) Received: from standards (47.234.32.16:3539) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8263@standards.nortelnetworks.com>; Fri, 20 Oct 2000 14:11:02 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 34600 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Fri, 20 Oct 2000 14:11:02 -0400 Received: from mail-dns2-nj.dialogic.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8262@standards.nortelnetworks.com>; Fri, 20 Oct 2000 14:11:01 -0400 Received: from mail4.dialogic.com (mail4.dialogic.com [146.152.6.40]) by mail-dns2-nj.dialogic.com (8.9.1a+p1/8.9.1/d: dialogic.m4,v 1.3 2000/05/05 13:56:23 dmccart Exp $) with ESMTP id SAA27501; Fri, 20 Oct 2000 18:30:14 GMT Received: from exchange3nj.dialogic.com (mailnj.dialogic.com [146.152.3.18]) by mail4.dialogic.com (8.9.3+Sun/8.9.3) with ESMTP id OAA15662; Fri, 20 Oct 2000 14:26:17 -0400 (EDT) Received: by mailnj.dialogic.com with Internet Mail Service (5.5.2650.21) id <4Y7P8B7N>; Fri, 20 Oct 2000 14:26:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Fri, 20 Oct 2000 14:19:14 -0400 Reply-To: "Rupsis, Paul" Sender: "Media Gateway Control (megaco)" From: "Rupsis, Paul" Subject: Re: wildcarded termination in Move X-To: "Nguyen, Chuong" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id OAA24056 > Chuong Nguyen wrote: > I think only Subtract can reset statistics. > Move does not reset statistics If that is the case, then what does the "dur" statistic in the network package [Section E.11.4] reflect when an ephemeral has been moved into/outof different contexts? "StatisticsID: dur (0x0001) Description: Provides duration of time the termination has been in the context." It is also then confusing what is meant in Section 7.2.4 "Move Command", when it states: "By convention, the Termination is subtracted from its previous Context." This *seems* to imply that statistics should be reset due to the subtract. Paul Rupsis -----Original Message----- From: Nguyen, Chuong [mailto:CNguyen@WhiteRockNetworks.com] Sent: Friday, October 20, 2000 1:10 PM To: 'Rupsis, Paul'; MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: RE: wildcarded termination in Move -----Original Message----- From: Rupsis, Paul [mailto:Paul.Rupsis@DIALOGIC.COM] Sent: Thursday, October 19, 2000 2:47 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: wildcarded termination in Move > there needs to be a means (for a service as simple as call holding) > to temporarily 'separate' terminations being in the same context > whatever their nature (physical/ephemeral) Isn't that what Topology provides (e.g., Context = C1 {Topology{T1, T2, isolate}} ) One problem with enabling Moves of terminations in and out of contexts is that statistics are reset. I think only Subtract can reset statistics. Move does not reset statistics. Paul Rupsis -----Original Message----- From: Fabien Capoen [mailto:Fabien.Capoen@ALCATEL.FR] Sent: Thursday, October 19, 2000 10:10 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: wildcarded termination in Move If I can dare to speak on this list ... (to introduce myself, I work on 'NGN' standards for alcatel), on this subject I have the following thoughts: - there needs to be a mean (for a service as simple as call holding) to temporarily 'separate' terminations being in the same context whatever their nature (physical/ephemeral) - the 'Context=${Move=' solution seems the only one (we could think of 2 other ones: the first to allow add on terminations being in a not null context, but this one has already been rejected because it breaks the add/move complementarity - move becomes just a special case of add; the second being a special NULL-like context: the ONHOLD context, for ephemeral terminations. This one is not very elegant) - the 'Context=${Move=' solution does not break the add/move complementarity: add remains reserved for non existing terminations or terminations in the null context, whereas move is reserved for terminations in a not null context - I have looked in the standard, and I could not see it explicitely forbidden. The only thing is that it is not explicitely allowed: in §6.1, the creation of a new context is only described for the add command. Changing 'In general, an Add command is used to add Terminations to Contexts' of §6.1 into 'In general, an Add OR MOVE command is used to add Terminations to Contexts' could solve the problem. And really, isn't it true to say that move also adds terminations to a context ? Isn't the only difference between move and add on the nature of the termination on which the add/move is applied ? The question I have is then: what concrete problems do people see with allowing 'context=$' in a move request ? Regards ... Fabien C. Please respond to "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Fabien CAPOEN/FR/ALCATEL) Subject: Re: wildcarded termination in Move Woops, sorry, didn't pay close enough attention. Your example has TWO RTP streams and no physical terminations. Unusual, but legal. Well, I'm stuck. I can think of stupid things to do, but nothing that looks useful. Maybe a change is warranted. Need other opinions on allowing Context=${Move=... Brian > -----Original Message----- > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > Sent: Thursday, October 19, 2000 9:45 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: wildcarded termination in Move > > > I don't understand your solution: T1 is an ephemeral > Termination: its TermID > is not provisionned in the MG. As soon as T1 is subtracted from C1, it > disappears, and its TermID too. How can the MGC re-use this > TermID to add it > to a new Context? > Can the MGC set the TermID of an ephemeral Termination when > it creates it? > > > ``` > (o o) > ----------oOO--(_)-OOo-------------- > Jean-Emmanuel CHAPRON > FRANCE TELECOM R&D > DAC/ACE > 38-40 rue du général Leclerc > 92794 Issy-les-Moulineaux Cedex 9 - France > Tel: +33 1 45 29 64 50 > ------------------------------------- > > > > > -----Message d'origine----- > > De : Rosen, Brian [mailto:Brian.Rosen@marconi.com] > > Envoyé : jeudi 19 octobre 2000 15:34 > > À : 'CHAPRON Jean-Emmanuel FTRD/DAC/ISS'; > > MEGACO@STANDARDS.NORTELNETWORKS.COM > > Objet : RE: wildcarded termination in Move > > > > > > I may be finessing the answer but > > Context=1{Subtract=T1.... > > Context=${Add=T1... > > gets you an equivalent > > > > Brian > > > > > -----Original Message----- > > > From: CHAPRON Jean-Emmanuel FTRD/DAC/ISS > > > [mailto:jeanemmanuel.chapron@RD.FRANCETELECOM.FR] > > > Sent: Thursday, October 19, 2000 5:02 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: wildcarded termination in Move > > > > > > > > > Hello Brian, all > > > > > > If things are left as they are, it seems that the case > > > described below is > > > simply impossible: > > > > > > (1) > > > | > > +-------------------------------------------------+ | > > > | |Context C1 > > | | > > > | | +-------------+ > > +-------------+ | | > > > | | | (Term. T1) | +-----+ | (Term. > > T2) | | | > > > <-+--->| RTP Stream |---| * |------| RTP Stream > > > |<---+-> > > > | | +-------------+ +-----+ > > +-------------+ | | > > > | > > +-------------------------------------------------+ | > > > (2) > > > > > > | > > +-------------------------------------------------+ | > > > | |Context C1 > > | | > > > | | +-------------+ > > > | | > > > | | | (Term. T1) | +-----+ > > | | > > > <-+--->| RTP Stream |---| * | > > | | > > > | | +-------------+ +-----+ > > | | > > > | > > +-------------------------------------------------+ | > > > | > > +-------------------------------------------------+ | > > > | |Context C2 > > | | > > > | | > > +-------------+ | | > > > | | +-----+ | (Term. > > T2) | | | > > > | | | * |------| RTP Stream > > > |<---+-> > > > | | +-----+ > > +-------------+ | | > > > | > > +-------------------------------------------------+ | > > > > > > > > > C2 didn't exist in (1). How to go from (1) to (2)? > > > - We can't use a MOVE $ (too bad..) > > > - we can't use Context = $ {Add = T2} because T2 is in a > > > non-NULL context > > > - we can't use "Subtract/Add" because we have only RTP > > > Terminations we don't > > > want to remove. > > > > > > This is not a textbook case, as far as this case may occur > > if the Call > > > Server/MGC is connected to the IN and receives, for > > instance, an INAP > > > "SplitLeg" message requiring such an handling of connections. > > > > > > Regards, > > > > > > > > > ``` > > > (o o) > > > ----------oOO--(_)-OOo-------------- > > > Jean-Emmanuel CHAPRON > > > FRANCE TELECOM R&D > > > DAC/ACE > > > 38-40 rue du général Leclerc > > > 92794 Issy-les-Moulineaux Cedex 9 - France > > > Tel: +33 1 45 29 64 50 > > > ------------------------------------- > > > > > > > > > > > > > -----Message d'origine----- > > > > De : Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > > Envoyé : mercredi 18 octobre 2000 15:01 > > > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Objet : Re: wildcarded termination in Move > > > > > > > > > > > > Ya, that's one of the reasons it's probably there - separating > > > > functions of Move and Add. > > > > > > > > Probably best to leave things as they are. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: knayar@hss.hns.com [mailto:knayar@hss.hns.com] > > > > > Sent: Wednesday, October 18, 2000 8:29 AM > > > > > To: Rosen, Brian > > > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > Hi > > > > > > > > > > If you remove this restriction then why you need Move, i will > > > > > always use Add to > > > > > either: > > > > > 1. Add a termination to a context from null context > > > > > 2. Move (read it as Add) a termination to a context from a > > > > > non-NULL context. > > > > > > > > > > -Kapil Nayar > > > > > Hughes Software Systems > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/18/2000 > > 05:31:06 PM > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > cc: (bcc: Kapil Nayar/HSS) > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > Only Add can create a new context: > > > > > "In general, an Add command is used to add Terminations > > > > to Contexts. > > > > > If the MGC does not specify an existing Context to > which the > > > > > Termination is to be added, the MG creates a new > Context. " > > > > > > > > > > A way to do the consultation hold is to create the new > > > context with > > > > > C and move A to that Context. > > > > > > > > > > I'll note that I was a little surprised to read: > > > > > "The Termination is either created, or taken from the > > > null Context" > > > > > (although I may have wrote it!), since this prohibits > an Add of > > > > > a termination already in another context. I'm not sure why we > > > > > prohibit that. I do think there is little practical > > difficulty in > > > > > keeping that restriction. If we did relax that > restriction, you > > > > > could do Context=${Add=A{.... > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > > > > > Sent: Wednesday, October 18, 2000 12:40 AM > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > Hi Brian, > > > > > > > > > > > > If you mean to say that Move with ContextID = $ is > > > > > > nonsensical --- I beg to > > > > > > differ...... > > > > > > > > > > > > Consider a simple call scenario -- A is talking to > B..... and > > > > > > now A wants to put > > > > > > B on hold and call up C......The simplest way to do > it as per > > > > > > my understanding > > > > > > would be -- MGC shall tell MG to Move A to a new context > > > > > > (Move - ContextID=$ and > > > > > > TermID = A) where it shall talk to C, and once it is done, > > > > > > move it back to the > > > > > > context where it was talking to B...... > > > > > > > > > > > > What is your opinion about this.... > > > > > > > > > > > > Thanks > > > > > > Chanchal.... > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/17/2000 > > > 05:57:41 PM > > > > > > > > > > > > Please respond to "Rosen, Brian" > > > > > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > > > > > > > Subject: Re: wildcarded termination in Move > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > If there are three terminations in an MG > > > > > > > abcd > > > > > > > abce > > > > > > > xyz. > > > > > > > Say abcd is in Context ID = 1 and both abce and xyz is in > > > > > > > NULL Context. > > > > > > > If MGC says Move with ContextID = $ and > termination as abc*, > > > > > > > what should the > > > > > > > MG do > > > > > > First of all, I think this is illegal, or at least > > nonsensical. > > > > > > You CAN'T create a new contextId with CHOOSE. > > > > > > So if it is legal, you are asking for Russian > Roulette - pick > > > > > > a context where the resulting command would be legal, > > and do it. > > > > > > If there is more than one, then it's random which one > > > > > > > > > > > > > 1. Consider abce while resolving wildcarded abc* - > > > > > > > Move is valid for abcd (it's in non-NULL context) and > > > > invalid for > > > > > > > abce (move is not allowed to move from and to a > > NULL Context) > > > > > > abcd is valid, abce is not valid > > > > > > > > > > > > > 2. Don't consider terminations in NULL Context > for resolving > > > > > > > wildcard since > > > > > > > the basic idea is not to Move to or from NULL Context. > > > > > > This is correct > > > > > > > > > > > > > > > > > > > > The first option has an impact on further commands in the > > > > > > > transaction since a > > > > > > > failure > > > > > > > with one command can cause the side effect of > other commands > > > > > > > being not executed. > > > > > > True, but in general if the MGC was foolish enough > to do this, > > > > > > it deserves what it gets. > > > > > > > > > > > > Brian > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Oct 21 10:04:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA06193 for ; Sat, 21 Oct 2000 10:04:57 -0400 (EDT) Received: from standards (47.234.32.16:2050) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8779@standards.nortelnetworks.com>; Sat, 21 Oct 2000 9:48:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36341 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 21 Oct 2000 09:48:03 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8778@standards.nortelnetworks.com>; Sat, 21 Oct 2000 9:48:03 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA28861 for ; Sat, 21 Oct 2000 10:03:22 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA28850 for ; Sat, 21 Oct 2000 10:03:21 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA18490; Sat, 21 Oct 2000 16:03:19 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA18485; Sat, 21 Oct 2000 16:03:17 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E850@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F1A276.A3B4D57B@lucent.com> Date: Sat, 21 Oct 2000 16:04:38 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: ABNF for topologyDescriptor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Brian, As I see it, the proposal for adding commas requires modification to the existing parsers as well. So I figured that we might as well make it nice. But it's no big deal to me. Cheers, John "Rosen, Brian" wrote: > > I don't like this addition, as it breaks "current" implementations. > Maybe: > > topologyDescriptor = TopologyToken topologyTriple | > ( LBRKT topologyTriple *(COMMA topologyTriple) RBRKT ) > topologyTriple = LBRKT terminationA COMMA terminationB COMMA > topologyDirection RBRKT > > > -----Original Message----- > > From: John Segers [mailto:jsegers@LUCENT.COM] > > Sent: Friday, October 20, 2000 5:42 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: ABNF for topologyDescriptor > > > > > > Christian, > > > > If we are making a change here, I propose that we delimit the > > triples by > > parentheses or brackets. Something like > > > > topologyDescriptor = TopologyToken LBRKT topologyTriple > > *(COMMA topologyTriple) RBRKT > > topologyTriple = LBRKT terminationA COMMA terminationB COMMA > > topologyDirection RBRKT > > > > Cheers, > > > > John > > > > > Date: Wed, 18 Oct 2000 11:52:32 +1100 > > > Reply-To: Christian Groves > > > Sender: "Media Gateway Control (megaco)" > > > > > > From: Christian Groves > > > Subject: Re: ABNF for topologyDescriptor > > > X-To: "Rosen, Brian" > > > Content-Type: text/plain; charset=iso-8859-1 > > > > > > G'Day All, > > > > > > The update I have made is: > > > 6.10 Topology Triples in ABNF > > > > > > Description: In the ABNF (Annex B), the term > > TopologyDescriptor allows > > > the specification of only one triple. The ASN.1 permits a > > sequence of > > > such triples. > > > [Begin Correction] > > > B.2 ABNF Specification > > > ... > > > topologyDescriptor = TopologyToken LBRKT topologyTriple > > > *(COMMA topologyTriple) RBRKT > > > topologyTriple = terminationA COMMA terminationB COMMA > > topologyDirection > > > RBRKT > > > > > > [End Correction] > > > > > > Cheers, Christian > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 303 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Oct 21 10:21:01 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA08000 for ; Sat, 21 Oct 2000 10:21:01 -0400 (EDT) Received: from standards (47.234.32.16:2050) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA87DD@standards.nortelnetworks.com>; Sat, 21 Oct 2000 10:02:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36473 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 21 Oct 2000 10:02:01 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA87DB@standards.nortelnetworks.com>; Sat, 21 Oct 2000 10:02:00 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA03035 for ; Sat, 21 Oct 2000 10:17:19 -0400 (EDT) Received: from hzsms01.nl.lucent.com (h135-85-32-31.lucent.com [135.85.32.31]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id KAA03027 for ; Sat, 21 Oct 2000 10:17:18 -0400 (EDT) Received: by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA18776; Sat, 21 Oct 2000 16:17:18 +0200 (MET DST) Received: from lucent.com by hzsms01.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id QAA18771; Sat, 21 Oct 2000 16:17:15 +0200 (MET DST) X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F1A5BC.A5E78EC8@lucent.com> Date: Sat, 21 Oct 2000 16:18:36 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Digit map completion event and other events. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, I agree that Brian's viewpoint is valid, but Madhu has a point: section 7.1.14.7 does say that while a digit map is active, the individual digit events are not reported. In my mind there are two things that we can do: - change 7.14.1.7 to be more specific - drop the clause from 7.1.14.8 that says that individual events are notified if they are included in the events descriptor as well (i.e. together with the digit map completion event). Before making a choice, can anyone think of a scenario where you want individual digits to be notified, *and* processed through a digit map at the same time? Cheers, John > Date: Tue, 17 Oct 2000 08:07:28 -0400 > Reply-To: "Rosen, Brian" > Sender: "Media Gateway Control (megaco)" > > From: "Rosen, Brian" > Subject: Re: Digit map completion event and other events. > X-To: "bmbabu@HSS.HNS.COM" > Content-Type: text/plain; charset="iso-8859-1" > > I don't understand the problem. > > If you just have a digitmap, you don't get NOTIFYied of individual > events. If you enable them, you do get the NOTIFYs, and they are > used by a digitMap, if enabled. So there are two independent consumers > of DTMF digits, they can be enabled separately, or together, MGC choice. > > Brian > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Monday, October 16, 2000 6:20 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Digit map completion event and other events. > > > > > > In section 7.1.14.7 its mentioned that "While the digit map > > is activated, detection is enabled for all > > events defined in the package containing the > > specified digit map completion event" > > and "the events in the package containing the specified > > digit map completion event other than the > > completion event itself are not individually > > notified". > > > > In next section 7.1.14.8 if item identifier is wildcard, then > > its mentioned that > > "Regardless of whether a digit map is activated, > > if the package also contains the digit events > > themselves, this form of event specification > > will cause the individual events to be > > reported to the MGC as they are detected" > > > > These two sections seems to be in conflict with each other. what > > should be the MG behaviour. > > > > -Madhubabu > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sat Oct 21 12:21:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA21239 for ; Sat, 21 Oct 2000 12:21:11 -0400 (EDT) Received: from standards (47.234.32.16:2538) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA88E0@standards.nortelnetworks.com>; Sat, 21 Oct 2000 12:04:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 36672 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sat, 21 Oct 2000 12:04:09 -0400 Received: from hotmail.com (f84.law3.hotmail.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8868@standards.nortelnetworks.com>; Sat, 21 Oct 2000 11:54:08 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sat, 21 Oct 2000 09:09:27 -0700 Received: from 132.245.4.101 by lw3fd.law3.hotmail.msn.com with HTTP; Sat, 21 Oct 2000 16:09:27 GMT X-Originating-IP: [132.245.4.101] Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 21 Oct 2000 16:09:27.0769 (UTC) FILETIME=[4990EC90:01C03B79] Message-ID: Date: Sat, 21 Oct 2000 16:09:27 GMT Reply-To: Rita Sharma Sender: "Media Gateway Control (megaco)" From: Rita Sharma Subject: Binary encoding; Command type parameter To: MEGACO@STANDARDS.NORTELNETWORKS.COM Folks, I have joined the list recently so excuse my lack of knowledge for this question. I am working with binary encoding and I could not find a place where a command request specify the type of command (Add/subtract/ etc). For example, the following three definitions do not specify the name of command. CommandRequest ::= SEQUENCE { command Command, optional NULL OPTIONAL, wildcardReturn NULL OPTIONAL, ... } Command ::= CHOICE { addReq AmmRequest, moveReq AmmRequest, modReq AmmRequest, -- Add, Move, Modify requests have the same parameters subtractReq SubtractRequest, auditCapRequest AuditRequest, auditValueRequest AuditRequest, notifyReq NotifyRequest, serviceChangeReq ServiceChangeRequest, ... } AmmRequest ::= SEQUENCE { terminationID TerminationIDList, descriptors SEQUENCE OF AmmDescriptor, -- At most one descriptor of each type (see AmmDescriptor) -- allowed in the sequence. ... } <<<<<<<<<<<<<<<<<<< thanks /Vivek _________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. Share information about yourself, create your own public profile at http://profiles.msn.com. From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Oct 22 20:09:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id UAA07064 for ; Sun, 22 Oct 2000 20:09:24 -0400 (EDT) Received: from standards (47.234.32.16:2655) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8E28@standards.nortelnetworks.com>; 22 Oct 2000 19:52:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38662 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 22 Oct 2000 19:52:08 -0400 Received: from ish7.ericsson.com.au (203.61.155.111:51342) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8E27@standards.nortelnetworks.com>; 22 Oct 2000 19:42:06 -0400 Received: from brsi02.epa.ericsson.se (igw2.ericsson.com.au [203.61.155.10]) by ish7.ericsson.com.au (8.9.3+Sun/8.9.3) with ESMTP id JAA25834; Mon, 23 Oct 2000 09:54:27 +1000 (EST) Received: from eaubrnt019.epa.ericsson.se (eaubrnt019 [146.11.9.165]) by brsi02.epa.ericsson.se (8.9.1/8.9.1) with ESMTP id KAA05882; Mon, 23 Oct 2000 10:56:53 +1100 (EST) Received: from ericsson.com.au (mc2dh133.epa.ericsson.se [146.11.87.133]) by eaubrnt019.epa.ericsson.se with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2650.21) id 4XFQVKPS; Mon, 23 Oct 2000 10:57:04 +1100 X-Mailer: Mozilla 4.72 [en] (Win98; I) X-Accept-Language: en MIME-Version: 1.0 References: <6525697E.002A1486.00@sandesh.hss.hns.com> Content-Type: multipart/mixed; boundary="------------BD89BACECD1510F855A0ED5C" Message-ID: <39F37ED0.ACCE7A7A@ericsson.com.au> Date: Mon, 23 Oct 2000 10:57:05 +1100 Reply-To: Paul Hollis Sender: "Media Gateway Control (megaco)" From: Paul Hollis Organization: Ericsson Australia Subject: Re: Topology X-To: chassija@hss.hns.com To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is a multi-part message in MIME format. --------------BD89BACECD1510F855A0ED5C Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi, the point I was trying to make is that if you send down (T1,Tx,isolate) in one transaction, and then in a later transaction you send down (T1,Ty,isolate), according to the rule: "The default association when a termination is not mentioned in the Topology descriptor is bothway (if T3 is added to a context with T1 and T2 with topology (T3,T1,oneway) it will be connected bothway to T2)." this would imply that T1 and Tx would now be bothway again as it was not specifically mentioned in the descriptor. Regards Paul. chassija@hss.hns.com wrote: > Hello Paul, > > The topology is with respect to a context and hence is not a command level > descriptor.......................So during the life-time of a > context......whatever topologies come in various actions get applied to the > context..............one after the other........If at any point of time you > refer to a term T1 in a command, then the following statements explain --- > > *) If at any point of time in the life of the context, you referred to term T1 > as (T1,Tx, isolate) (which shall be stored in your topology descriptor) , then > T1 and Tx are isolated for this command also......(if T1 did not get subtracted > after the topology settings because that would flush the topology for T1) > > *) If at no point of time you referred to the pair (T1,Ty,..), then T1,Ty is > bothways for this command.............. > > But remember, you have to flush the topology descriptor for T1, if T1 gets > subtracted from the context................... > > Njoy > Chanchal........... > > Paul Hollis on 10/19/2000 04:17:51 PM > > To: Chanchal Hassija/HSS@HSS > cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Topology > > Hi Chanchal, > > thanks for the reply. However, if you take each step as being done in one > command > at a time, then step 2 would isolate T1 and T2, which is OK. However, once step > 3 > is issued in the command with only (T3, T2, oneway) specified in the command, > then > according to the rule quoted below any other association not mentioned in the > command is set to bothway. > > In other words you would need to specify (T1, T2 isolate) and (T3, T2, oneway) > in > the one command to achieve what is shown. > > Does this make sense or am I on the wrong track. > > Regards Paul. > > Chanchal Hassija wrote: > > > Hello Paul, > > > > My reply is embedded and prefixed with Chan> > > > > I have a quick question about the topology description in H.248. > > > > The wording in the Topology Descriptor chapter says: > > > > "The default association when a termination is not mentioned in the Topology > > descriptor is bothway (if T3 is added to a context with T1 and T2 with > topology > > (T3,T1,oneway) it will be connected bothway to T2)." > > > > but in the example in the diagrams, at step 3 we apply the topology "T3, T2, > > oneway". I would assume that if we apply the above rule, then there should be > a > > bothway connection between T1 and T2. > > > > Chan> You need to read all the steps in sequence. Hence the two-way connection > > between T1 and T2 in step 1) was broken in step 2) by the command.... > > (T1,T2,Isolate).....Hence it is not there in step 3) > > > > Njoy.... > > Chanchal........ --------------BD89BACECD1510F855A0ED5C Content-Type: text/x-vcard; charset=us-ascii; name="paul.hollis.vcf" Content-Description: Card for Paul Hollis Content-Disposition: attachment; filename="paul.hollis.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Hollis;Paul tel;fax:9301 1139 tel;work:9301 2326 x-mozilla-html:FALSE org:Ericsson Australia. adr:;;;Melbourne;Victoria;;Australia version:2.1 email;internet:Paul.Hollis@ericsson.com.au title:Software Designer (Signalling) x-mozilla-cpt:;17264 fn:Paul Hollis end:vcard --------------BD89BACECD1510F855A0ED5C-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Oct 22 21:23:19 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19266 for ; Sun, 22 Oct 2000 21:23:19 -0400 (EDT) Received: from standards (47.234.32.16:4216) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8E4A@standards.nortelnetworks.com>; 22 Oct 2000 21:06:13 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38699 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 22 Oct 2000 21:06:12 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8E44@standards.nortelnetworks.com>; 22 Oct 2000 20:56:11 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9N1BVZ18824; Mon, 23 Oct 2000 03:11:31 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA05339; Mon, 23 Oct 2000 03:11:31 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA21908; Mon, 23 Oct 2000 03:11:28 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F375EE.51613578@ericsson.com> Date: Mon, 23 Oct 2000 10:19:10 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Registering Packages X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Tom, What is the status of the procedures for registering Packages with IANA? I checked the IANA webpage but couldn't find any information on how to do this. Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Oct 22 21:23:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19269 for ; Sun, 22 Oct 2000 21:23:19 -0400 (EDT) Received: from standards (47.234.32.16:4216) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8E52@standards.nortelnetworks.com>; 22 Oct 2000 21:06:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38700 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 22 Oct 2000 21:06:36 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8E45@standards.nortelnetworks.com>; 22 Oct 2000 20:56:35 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9N1But05354; Mon, 23 Oct 2000 03:11:56 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA05365; Mon, 23 Oct 2000 03:11:55 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA21931; Mon, 23 Oct 2000 03:11:53 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <39EE8F82.D61A5713@ericsson.com> <39F02790.F343CAC9@lucent.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F3819F.76952DB4@ericsson.com> Date: Mon, 23 Oct 2000 11:09:03 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: H248 Implementors' Guide Draft v3 X-To: Mailing list for parties associated with ITU-T Study Group 16 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day John, Thanks for the comments. Please see my resonses below [CHG]. Cheers, Christian John Segers wrote: > > Christian, > > Having read your draft implementors' guide, I have a couple of comments. > > 1. In section 8.6 of the IG, you say that existing descriptors are > retained with the Move command. I agree with the intent, but find the > phrasing awkward. Strictly speaking, descriptors are defined as groups > of parameters to commands. So I think it would be better to say > something like > > "The Move command does not affect the properties of the Termination on > which it operates, except those properties explicitly modified by > descriptors included in the Move command." [CHG] OK. This wording is more specific. > > 2. Section 8.7 proposes a correction to E.6.4. If I'm not mistaken, it > is actually a correction to E.6.2, and you should add "..."-dots between > "Section E.6.2 Events" and "DigitMap Completion Event". In that > correction there is an undefined reference that should be replaced by a > reference to 7.1.14. [CHG] Your not mistaken. I was. I'll update accordingly. > > 3. Section 8.10 proposes that event and signal parameters starting with > "SPA" and "EPA" be forbidden. I have to think whether this is the best > resolution to the problem of ambiguity, but until I have done so, I want > to point out a mistake in the proposed addition to 13.1. This addition > implies that package names must not start with "SPA" or "EPA". However, > the ambiguity is not related to package names but to parameters of > signals and events. Instead of your proposed change to 13.1, I propose > that additional text be added to 12.2: > > [Begin Correction] > 12.1 Guidelines to defining Properties, Statistics and Parameters to > Events and Signals > > Parameter Name: only descriptive > ParameterID: Is an identifier. The textual ParameterID of parameters to > Events and Signals shall not start with "EPA" and "SPA", respectively. > [End Correction] [CHG] Sounds reasonable. I really just added this text to get a reaction from people. > > 4. Section 9.3 proposes clarifying text for the use of wildcarded > responses in audits. The final example shows that the reply to > > Context=*{W-Audit=t1/*{Audit{Packages}} > > is > > Context=*{W-Audit=t1/*{Packages{aaa,bbb,ccc,ddd}} > > although Terminations t1/1 and t1/2 only implement packages aaa and > bbb. So the ",ccc,ccc" part has to be removed from the response, or > example has to be changed to something like > > Context=*{W-Audit=*/*{Audit{Packages}} > > returns > > Context=*{W-Audit=*/*{Packages{aaa,bbb,ccc,ddd}} > > Cheers, [CHG] Correct. This slipped in when I added t1/. > > John > > Christian Groves wrote: > > > > G'Day all, > > > > Attached is a copy of the H.248 Implementors' Guide v3. It "hopefully" > > contains the corrections and clarifications that have been discussed on > > the Megaco mailing list until the 19/10/2000. > > > > If anything is missed or erroneous please let me (and the list) know. > > > > The file will also be upload to the pictel server: > > ftp://standard.pictel.com/avc-site/incoming/H248_Implementors_Guide_v3.zip > > Both PDF and Word versions are available. > > > > My intention is to make one more update (v4) before sending to the Nov > > Sg16 meeting for approval. > > > > Cheers, Christian > > > > PS: Please forgive me sending a 98k file to the list but the Pictel > > server has been down. > > > > ------------------------------------------------------------------------ > > Name: H248_Implementors_Guide_v3.zip > > H248_Implementors_Guide_v3.zip Type: Winzip32 File (application/x-zip-compressed) > > Encoding: base64 > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv@mailbag.intel.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Sun Oct 22 21:23:21 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA19279 for ; Sun, 22 Oct 2000 21:23:20 -0400 (EDT) Received: from standards (47.234.32.16:4216) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8E56@standards.nortelnetworks.com>; 22 Oct 2000 21:06:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 38701 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Sun, 22 Oct 2000 21:06:44 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8E46@standards.nortelnetworks.com>; 22 Oct 2000 20:56:43 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9N1C5Z18962; Mon, 23 Oct 2000 03:12:05 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA05385; Mon, 23 Oct 2000 03:12:04 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA21939; Mon, 23 Oct 2000 03:12:01 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E84D@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F38652.A824C6EB@ericsson.com> Date: Mon, 23 Oct 2000 11:29:06 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Statistics X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day Brian, There's no reason that you can't. You could have a statistic on a termination for : No. Audio PAckets received, another for Number video packets received, another for Total packets received. I do see the case why we want it per stream. I was questioning the place to document it. Implementors guide or v2? If other people speak up I don't mind adding it the Implementors' guide. Cheers, Christian "Rosen, Brian" wrote: > > Well we don't "format statistics" in a certain way to, say, > allow you to differentiate # of packets sent for video from > # of packets sent for audio. > > Seems to me it needs to be addressed somehow. > > Brian > > > -----Original Message----- > > From: Christian Groves [mailto:Christian.Groves@ericsson.com] > > Sent: Thursday, October 19, 2000 7:23 PM > > To: Rosen, Brian > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Statistics > > > > > > This has been something thats been around for a long time and > > I thought > > people were pretty aware of this. I don't think its a bug per > > se as you > > can handle it formatting your statistics in a certain way. > > Certainly in > > v2 it would be nice to allow statistics on streams. Its a fairly big > > change to me for an implementors' guide. > > > > Cheers, Christian > > > > "Rosen, Brian" wrote: > > > > > > Oh cool. I don't think we have ever talked about this, > > > stream specific statistics! Hmmmmm. > > > > > > So we would want to add (an optional) StreamId to > > Statistics Descriptor > > > Statistics=1{rtp/pr=.... > > > and you might get more than one Statistics descriptor in the reply. > > > > > > Wow. This is a real bug in the protocol I think! > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > > Sent: Thursday, October 19, 2000 9:51 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Statistics > > > > > > > > > > > > Section E.12.4 states that statistics like > > > > jitter, packet loss,etc are described on an > > > > RTP stream. If only one RTP stream is > > > > present on a termination its straitforward > > > > to send statistics. But if multiple streams > > > > are created on a termination How this > > > > reporting is done? > > > > > > > > -Madhubabu > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 02:48:27 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA16140 for ; Mon, 23 Oct 2000 02:48:27 -0400 (EDT) Received: from standards (47.234.32.16:3537) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8F85@standards.nortelnetworks.com>; Mon, 23 Oct 2000 2:31:25 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39138 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 02:31:24 -0400 Received: from mars.hss.co.in (202.54.26.197:47713) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8F84@standards.nortelnetworks.com>; Mon, 23 Oct 2000 2:31:23 -0400 Received: from sandesh.hss.hns.com (sandesh [139.85.242.35]) by mars.hss.co.in (8.10.0/8.10.0) with SMTP id e9N6lPC01476 for ; Mon, 23 Oct 2000 12:17:26 +0530 (IST) Received: by sandesh.hss.hns.com(Lotus SMTP MTA v4.6.3 (733.2 10-16-1998)) id 65256981.00243D59 ; Mon, 23 Oct 2000 12:05:50 +0530 X-Lotus-FromDomain: HSS Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <65256981.00243CEB.00@sandesh.hss.hns.com> Date: Mon, 23 Oct 2000 12:11:19 +0530 Reply-To: bmbabu@HSS.HNS.COM Sender: "Media Gateway Control (megaco)" From: Madhu Babu Subject: Re: Modify the service state property To: MEGACO@STANDARDS.NORTELNETWORKS.COM What will be the action anticipated from MG when the ServiceState of a termination is MODIFIED by MGC from in-service to out-of-service or vice versa. -Madhubabu Christian Groves on 10/20/2000 05:00:31 AM Please respond to Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.COM cc: (bcc: Madhu B Babu/HSS) Subject: Re: Modify the service state property I'll agree with Brian on service state. I believe that the MGC can manipulate the state in the Termination State Descriptor. I don't see any compelling reason to now make it read only. Cheers, Christian Madhu Babu wrote: > > I believe that the ServiceState values > outofservice and inservice are not > settable directly my MGC and only indicate > the current state that can be modified > using SerivceChange. This seems to make > ServiceState property as "read-only" type for > these two values. But then what about "test" value ? > > -Madhubabu > > "Rosen, Brian" on 10/19/2000 07:04:09 PM > > To: Madhu B Babu/HSS@HSS, MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: > > Subject: RE: Modify the service state property > > I'd say yes, but I'd recommend not doing it that way. > > Brian > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Thursday, October 19, 2000 7:01 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Modify the service state property > > > > > > Is the changing of ServiceState of a termination > > directly from inservice to outofservice and > > vice-versa allowed in say a Modify? > > > > Is this equivalent in functional operation to a ServiceChange > > on that termination? > > > > -Madhubabu > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 03:26:56 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA28064 for ; Mon, 23 Oct 2000 03:26:56 -0400 (EDT) Received: from standards (47.234.32.16:4975) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8FA6@standards.nortelnetworks.com>; Mon, 23 Oct 2000 3:09:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39181 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 03:09:53 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA8FA5@standards.nortelnetworks.com>; Mon, 23 Oct 2000 2:59:52 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9N7FAt19732; Mon, 23 Oct 2000 09:15:10 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id JAA13976; Mon, 23 Oct 2000 09:15:09 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id JAA23537; Mon, 23 Oct 2000 09:15:07 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <65256981.00243CEB.00@sandesh.hss.hns.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F3E568.67433483@ericsson.com> Date: Mon, 23 Oct 2000 18:14:48 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Re: Modify the service state property X-To: bmbabu@HSS.HNS.COM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day By ServiceState do you mean the termination service state? To me they are the one and the same thing. Cheers, Christian Madhu Babu wrote: > > What will be the action anticipated from MG when the > ServiceState of a termination is MODIFIED by MGC > from in-service to out-of-service or vice versa. > > -Madhubabu > > Christian Groves on 10/20/2000 05:00:31 AM > > Please respond to Christian Groves > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Madhu B Babu/HSS) > > Subject: Re: Modify the service state property > > I'll agree with Brian on service state. I believe that the MGC can > manipulate the state in the Termination State Descriptor. I don't see > any compelling reason to now make it read only. > > Cheers, Christian > > Madhu Babu wrote: > > > > I believe that the ServiceState values > > outofservice and inservice are not > > settable directly my MGC and only indicate > > the current state that can be modified > > using SerivceChange. This seems to make > > ServiceState property as "read-only" type for > > these two values. But then what about "test" value ? > > > > -Madhubabu > > > > "Rosen, Brian" on 10/19/2000 07:04:09 PM > > > > To: Madhu B Babu/HSS@HSS, MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: > > > > Subject: RE: Modify the service state property > > > > I'd say yes, but I'd recommend not doing it that way. > > > > Brian > > > > > -----Original Message----- > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > Sent: Thursday, October 19, 2000 7:01 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Modify the service state property > > > > > > > > > Is the changing of ServiceState of a termination > > > directly from inservice to outofservice and > > > vice-versa allowed in say a Modify? > > > > > > Is this equivalent in functional operation to a ServiceChange > > > on that termination? > > > > > > -Madhubabu > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 04:01:20 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id EAA08787 for ; Mon, 23 Oct 2000 04:01:20 -0400 (EDT) Received: from standards (47.234.32.16:4975) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9011@standards.nortelnetworks.com>; Mon, 23 Oct 2000 3:44:18 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39318 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 03:44:18 -0400 Received: from p-mail1.cnet.fr (p-mail1.rd.francetelecom.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA900E@standards.nortelnetworks.com>; Mon, 23 Oct 2000 3:34:16 -0400 Received: by p-biset.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 09:49:29 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <98388C05D464D111B61800805F150416012AFA71@p-ibis.issy.cnet.fr> Date: Mon, 23 Oct 2000 09:49:23 +0200 Reply-To: CHATRAS Bruno FTRD/DAC/ISS Sender: "Media Gateway Control (megaco)" From: CHATRAS Bruno FTRD/DAC/ISS Subject: Re: Digit map completion event and other events. X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id EAA08787 Hi, A scenario where you want individual digits to be notified, *and* processed through a digit map at the same time might be a Voice Activated Dialling service where the calling party can either dial or speak. When the calling party goes off-hook, the MGC creates a context with two terminations. The first termination models the access to the calling line; while the second termination models the access to an external Intelligent Peripheral (with voice recognition capabilities). If the user prefers to dial rather than speak, it might be useful for the MGC to be aware of this decision as soon as possible, in order to release the external peripheral. Reporting the first dialled digit as an individual event would make this easy. In parallel, this digit and the subsequent digits would still need to be processed through a digit map according to the dialling plan in force. > -----Message d'origine----- > De : John Segers [mailto:jsegers@LUCENT.COM] > Envoyé : samedi 21 octobre 2000 16:19 > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > Objet : Re: Digit map completion event and other events. > > > Hi, > > I agree that Brian's viewpoint is valid, but Madhu has a > point: section > 7.1.14.7 does say that while a digit map is active, the > individual digit > events are not reported. > > In my mind there are two things that we can do: > - change 7.14.1.7 to be more specific > - drop the clause from 7.1.14.8 that says that individual events are > notified if they are included in the events descriptor as well (i.e. > together with the digit map completion event). > > Before making a choice, can anyone think of a scenario where you want > individual digits to be notified, *and* processed through a > digit map at > the same time? > > Cheers, > > John > > > Date: Tue, 17 Oct 2000 08:07:28 -0400 > > Reply-To: "Rosen, Brian" > > Sender: "Media Gateway Control (megaco)" > > > > From: "Rosen, Brian" > > Subject: Re: Digit map completion event and other events. > > X-To: "bmbabu@HSS.HNS.COM" > > Content-Type: text/plain; charset="iso-8859-1" > > > > I don't understand the problem. > > > > If you just have a digitmap, you don't get NOTIFYied of individual > > events. If you enable them, you do get the NOTIFYs, and they are > > used by a digitMap, if enabled. So there are two > independent consumers > > of DTMF digits, they can be enabled separately, or > together, MGC choice. > > > > Brian > > > > > -----Original Message----- > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > Sent: Monday, October 16, 2000 6:20 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Digit map completion event and other events. > > > > > > > > > In section 7.1.14.7 its mentioned that "While the digit map > > > is activated, detection is enabled for all > > > events defined in the package containing the > > > specified digit map completion event" > > > and "the events in the package containing the specified > > > digit map completion event other than the > > > completion event itself are not individually > > > notified". > > > > > > In next section 7.1.14.8 if item identifier is wildcard, then > > > its mentioned that > > > "Regardless of whether a digit map is activated, > > > if the package also contains the digit events > > > themselves, this form of event specification > > > will cause the individual events to be > > > reported to the MGC as they are detected" > > > > > > These two sections seems to be in conflict with each other. what > > > should be the MG behaviour. > > > > > > -Madhubabu > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 05:09:45 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA28088 for ; Mon, 23 Oct 2000 05:09:44 -0400 (EDT) Received: from standards (47.234.32.16:2947) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA90B3@standards.nortelnetworks.com>; Mon, 23 Oct 2000 4:52:39 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39520 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 04:52:39 -0400 Received: from auemail2.firewall.lucent.com (auemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA90B2@standards.nortelnetworks.com>; Mon, 23 Oct 2000 4:52:38 -0400 Received: from auemail2.firewall.lucent.com (localhost [127.0.0.1]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA27567 for ; Mon, 23 Oct 2000 05:08:02 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by auemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA27511 for ; Mon, 23 Oct 2000 05:08:01 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA00329; Mon, 23 Oct 2000 11:06:09 +0200 (MET DST) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F3FF2E.8960F774@lucent.com> Date: Mon, 23 Oct 2000 11:04:46 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Binary encoding; Command type parameter To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Vivek/Rita, The encoding of a CHOICE construct contains information about the field that was chosen, not just the value (in this case AmmRequest). Cheers, John Rita Sharma wrote: > > Folks, > > I have joined the list recently so excuse my lack of knowledge for this > question. > > I am working with binary encoding and I could not find a place where a > command request specify the type of command (Add/subtract/ etc). > > For example, the following three definitions do not specify the name of > command. > > CommandRequest ::= SEQUENCE > { > command Command, > optional NULL OPTIONAL, > wildcardReturn NULL OPTIONAL, > ... > } > > Command ::= CHOICE > { > addReq AmmRequest, > moveReq AmmRequest, > modReq AmmRequest, > -- Add, Move, Modify requests have the same parameters > subtractReq SubtractRequest, > auditCapRequest AuditRequest, > auditValueRequest AuditRequest, > notifyReq NotifyRequest, > serviceChangeReq ServiceChangeRequest, > ... > } > > AmmRequest ::= SEQUENCE > { > terminationID TerminationIDList, > descriptors SEQUENCE OF AmmDescriptor, > -- At most one descriptor of each type (see AmmDescriptor) > -- allowed in the sequence. > ... > } > > <<<<<<<<<<<<<<<<<<< > thanks > > /Vivek > _________________________________________________________________________ > Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com. > > Share information about yourself, create your own public profile at > http://profiles.msn.com. -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 05:18:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA00381 for ; Mon, 23 Oct 2000 05:18:57 -0400 (EDT) Received: from standards (47.234.32.16:2947) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA90CD@standards.nortelnetworks.com>; Mon, 23 Oct 2000 5:01:53 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39554 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 05:01:53 -0400 Received: from hoemail2.firewall.lucent.com (hoemail2.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA90CC@standards.nortelnetworks.com>; Mon, 23 Oct 2000 5:01:53 -0400 Received: from hoemail2.firewall.lucent.com (localhost [127.0.0.1]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA05448 for ; Mon, 23 Oct 2000 05:17:17 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by hoemail2.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA05434 for ; Mon, 23 Oct 2000 05:17:16 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA00677; Mon, 23 Oct 2000 11:17:04 +0200 (MET DST) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <98388C05D464D111B61800805F150416012AFA71@p-ibis.issy.cnet.fr> Content-Type: text/plain; charset=iso-8859-1 Message-ID: <39F401CF.5520C9D6@lucent.com> Date: Mon, 23 Oct 2000 11:15:59 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Digit map completion event and other events. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id FAA00381 Bruno, I wonder how the example that you give works. In particular, if the user speaks, does the MGC then learn the dialed number from the external IP? This looks awkward to me. An architecture where the MGC activates the digit map on a Termination on the MG, and receives the digit string from that MG, whether it collected DTMF or used an external device to process user speech, seems preferrable to me. The MGC then doesn't have to instruct two devices if it wants to get one dialled number. Cheers, John CHATRAS Bruno FTRD/DAC/ISS wrote: > > Hi, > > A scenario where you want individual digits to be notified, *and* processed > through a digit map at the same time might be a Voice Activated Dialling > service where the calling party can either dial or speak. > > When the calling party goes off-hook, the MGC creates a context with two > terminations. The first termination models the access to the calling line; > while the second termination models the access to an external Intelligent > Peripheral (with voice recognition capabilities). If the user prefers to > dial rather than speak, it might be useful for the MGC to be aware of this > decision as soon as possible, in order to release the external peripheral. > Reporting the first dialled digit as an individual event would make this > easy. In parallel, this digit and the subsequent digits would still need to > be processed through a digit map according to the dialling plan in force. > > > -----Message d'origine----- > > De : John Segers [mailto:jsegers@LUCENT.COM] > > Envoyé : samedi 21 octobre 2000 16:19 > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > Objet : Re: Digit map completion event and other events. > > > > > > Hi, > > > > I agree that Brian's viewpoint is valid, but Madhu has a > > point: section > > 7.1.14.7 does say that while a digit map is active, the > > individual digit > > events are not reported. > > > > In my mind there are two things that we can do: > > - change 7.14.1.7 to be more specific > > - drop the clause from 7.1.14.8 that says that individual events are > > notified if they are included in the events descriptor as well (i.e. > > together with the digit map completion event). > > > > Before making a choice, can anyone think of a scenario where you want > > individual digits to be notified, *and* processed through a > > digit map at > > the same time? > > > > Cheers, > > > > John > > > > > Date: Tue, 17 Oct 2000 08:07:28 -0400 > > > Reply-To: "Rosen, Brian" > > > Sender: "Media Gateway Control (megaco)" > > > > > > From: "Rosen, Brian" > > > Subject: Re: Digit map completion event and other events. > > > X-To: "bmbabu@HSS.HNS.COM" > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > I don't understand the problem. > > > > > > If you just have a digitmap, you don't get NOTIFYied of individual > > > events. If you enable them, you do get the NOTIFYs, and they are > > > used by a digitMap, if enabled. So there are two > > independent consumers > > > of DTMF digits, they can be enabled separately, or > > together, MGC choice. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > > Sent: Monday, October 16, 2000 6:20 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Digit map completion event and other events. > > > > > > > > > > > > In section 7.1.14.7 its mentioned that "While the digit map > > > > is activated, detection is enabled for all > > > > events defined in the package containing the > > > > specified digit map completion event" > > > > and "the events in the package containing the specified > > > > digit map completion event other than the > > > > completion event itself are not individually > > > > notified". > > > > > > > > In next section 7.1.14.8 if item identifier is wildcard, then > > > > its mentioned that > > > > "Regardless of whether a digit map is activated, > > > > if the package also contains the digit events > > > > themselves, this form of event specification > > > > will cause the individual events to be > > > > reported to the MGC as they are detected" > > > > > > > > These two sections seems to be in conflict with each other. what > > > > should be the MG behaviour. > > > > > > > > -Madhubabu > > > > > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 303 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 05:58:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA08879 for ; Mon, 23 Oct 2000 05:58:49 -0400 (EDT) Received: from standards (47.234.32.16:3644) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA90E9@standards.nortelnetworks.com>; Mon, 23 Oct 2000 5:41:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39592 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 05:41:52 -0400 Received: from bom1.vsnl.net.in (giasbm01.vsnl.net.in) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA90E8@standards.nortelnetworks.com>; Mon, 23 Oct 2000 5:41:50 -0400 Received: from hyd.chiplogic.com (unknown [210.212.215.235]) by bom1.vsnl.net.in (Postfix) with ESMTP id B3ABC4A7E for ; Mon, 23 Oct 2000 15:26:56 +0530 (IST) Received: from chiplogic.com ([192.168.2.80]) by hyd.chiplogic.com (8.8.7/8.8.7) with ESMTP id PAA08603 for ; Mon, 23 Oct 2000 15:20:34 +0530 X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F40D26.590A5A72@chiplogic.com> Date: Mon, 23 Oct 2000 15:34:22 +0530 Reply-To: Satish Chowdhury Sender: "Media Gateway Control (megaco)" From: Satish Chowdhury Organization: Chip Logic Subject: requestId in eventsDescriptor for AuditCapReply To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi all , Section 7.2.6 says "... The EventsDescriptor returns the list of possible events on the Termination together with the list of all possible values for the EventsDescriptor Parameters. ..." What is the value of requestId sent in the events Descriptor from MG to MGC for a AuditCap reply ? Thankx Satish From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 06:38:36 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA17639 for ; Mon, 23 Oct 2000 06:38:36 -0400 (EDT) Received: from standards (47.234.32.16:3644) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA911F@standards.nortelnetworks.com>; Mon, 23 Oct 2000 6:21:37 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39663 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 06:21:37 -0400 Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA911C@standards.nortelnetworks.com>; Mon, 23 Oct 2000 6:11:36 -0400 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Mon, 23 Oct 2000 11:55:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <98388C05D464D111B61800805F150416012AFA74@p-ibis.issy.cnet.fr> Date: Mon, 23 Oct 2000 11:55:33 +0200 Reply-To: CHATRAS Bruno FTRD/DAC/ISS Sender: "Media Gateway Control (megaco)" From: CHATRAS Bruno FTRD/DAC/ISS Subject: Re: Digit map completion event and other events. X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id GAA17639 John, > > Bruno, > > I wonder how the example that you give works. In particular, if the > user speaks, does the MGC then learn the dialed number from > the external IP? Yes, you need a direct control interface between the MGC and the IP (possibly tunnelled through the MG), which is outside the scope of MEGACO. > This looks awkward to me. > > An architecture where the MGC activates the digit map on a Termination > on the MG, and receives the digit string from that MG, whether it > collected DTMF or used an external device to process user > speech, seems > preferrable to me. The MGC then doesn't have to instruct two > devices if > it wants to get one dialled number. I agree that this is a better target architecture. However not all MGs will be able to do that, while some Call Servers (MGC)(e.g; those whose software is derived from an existing PSTN switch) have already the sort of control interface I mentioned above. Another difficulty for the MG is that the selection of the external device may depend on the calling party number. > > Cheers, > > John > > CHATRAS Bruno FTRD/DAC/ISS wrote: > > > > Hi, > > > > A scenario where you want individual digits to be notified, > *and* processed > > through a digit map at the same time might be a Voice > Activated Dialling > > service where the calling party can either dial or speak. > > > > When the calling party goes off-hook, the MGC creates a > context with two > > terminations. The first termination models the access to > the calling line; > > while the second termination models the access to an > external Intelligent > > Peripheral (with voice recognition capabilities). If the > user prefers to > > dial rather than speak, it might be useful for the MGC to > be aware of this > > decision as soon as possible, in order to release the > external peripheral. > > Reporting the first dialled digit as an individual event > would make this > > easy. In parallel, this digit and the subsequent digits > would still need to > > be processed through a digit map according to the dialling > plan in force. > > > > > -----Message d'origine----- > > > De : John Segers [mailto:jsegers@LUCENT.COM] > > > Envoyé : samedi 21 octobre 2000 16:19 > > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Objet : Re: Digit map completion event and other events. > > > > > > > > > Hi, > > > > > > I agree that Brian's viewpoint is valid, but Madhu has a > > > point: section > > > 7.1.14.7 does say that while a digit map is active, the > > > individual digit > > > events are not reported. > > > > > > In my mind there are two things that we can do: > > > - change 7.14.1.7 to be more specific > > > - drop the clause from 7.1.14.8 that says that individual > events are > > > notified if they are included in the events descriptor as > well (i.e. > > > together with the digit map completion event). > > > > > > Before making a choice, can anyone think of a scenario > where you want > > > individual digits to be notified, *and* processed through a > > > digit map at > > > the same time? > > > > > > Cheers, > > > > > > John > > > > > > > Date: Tue, 17 Oct 2000 08:07:28 -0400 > > > > Reply-To: "Rosen, Brian" > > > > Sender: "Media Gateway Control (megaco)" > > > > > > > > From: "Rosen, Brian" > > > > Subject: Re: Digit map completion event and other events. > > > > X-To: "bmbabu@HSS.HNS.COM" > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > > > I don't understand the problem. > > > > > > > > If you just have a digitmap, you don't get NOTIFYied of > individual > > > > events. If you enable them, you do get the NOTIFYs, > and they are > > > > used by a digitMap, if enabled. So there are two > > > independent consumers > > > > of DTMF digits, they can be enabled separately, or > > > together, MGC choice. > > > > > > > > Brian > > > > > > > > > -----Original Message----- > > > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > > > Sent: Monday, October 16, 2000 6:20 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Digit map completion event and other events. > > > > > > > > > > > > > > > In section 7.1.14.7 its mentioned that "While the digit map > > > > > is activated, detection is enabled for all > > > > > events defined in the package containing the > > > > > specified digit map completion event" > > > > > and "the events in the package containing the specified > > > > > digit map completion event other than the > > > > > completion event itself are not individually > > > > > notified". > > > > > > > > > > In next section 7.1.14.8 if item identifier is wildcard, then > > > > > its mentioned that > > > > > "Regardless of whether a digit map is activated, > > > > > if the package also contains the digit events > > > > > themselves, this form of event specification > > > > > will cause the individual events to be > > > > > reported to the MGC as they are detected" > > > > > > > > > > These two sections seems to be in conflict with each > other. what > > > > > should be the MG behaviour. > > > > > > > > > > -Madhubabu > > > > > > > > > > > -- > > > John Segers email: > jsegers@lucent.com > > > Lucent Technologies > Room HE 303 > > > Dept. Forward Looking Work phone: > +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: > +31 35 687 5954 > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 09:20:05 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA27415 for ; Mon, 23 Oct 2000 09:20:05 -0400 (EDT) Received: from standards (47.234.32.16:3118) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9193@standards.nortelnetworks.com>; Mon, 23 Oct 2000 9:02:52 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39811 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 09:02:52 -0400 Received: from qhars002.nortel.com (47.101.112.102:50036) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9189@standards.nortelnetworks.com>; Mon, 23 Oct 2000 8:52:52 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Mon, 23 Oct 2000 14:07:58 +0100 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 23 Oct 2000 09:03:48 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WR1XB7>; Mon, 23 Oct 2000 09:03:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03CF1.AAE76450" X-Orig: Message-ID: <75C9A75D295AD31184E70008C79189D2035A767E@zcard00b.ca.nortel.com> Date: Mon, 23 Oct 2000 09:03:41 -0400 Reply-To: Alan Whitton Sender: "Media Gateway Control (megaco)" From: Alan Whitton Subject: T1.207 Test Suite Package? To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03CF1.AAE76450 Content-Type: text/plain; charset="iso-8859-1" Hi, Has anyone put together a T1.207 test package for H.248 yet. I have something I am working on, but if someone has already done the work, I'd be glad to use theirs! Cheers, Alan Whitton Holistic Metaservices Architect CVX SS7 Gateway Nortel Networks, *: (613) 763-8871 *ESN: 393-8871 *?mailto:awhitton@nortelnetworks.com *?mailto:avwhitton@alumni.uwaterloo.ca > "I think...I think it's in my basement. Let me go upstairs and check." > M.C. Escher (1898-1972) > "There'll be other days, but, what if today is the only day?" Field of Dreams ------_=_NextPart_001_01C03CF1.AAE76450 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable T1.207 Test Suite Package?

Hi,

Has anyone put together a T1.207 test = package for H.248 yet. I have something I am working on, but if someone = has already done the work, I'd be glad to use theirs!

Cheers,
Alan Whitton

Holistic Metaservices = Architect
CVX SS7 Gateway
Nortel Networks,                  = ;             
(: (613) = 763-8871       (ESN: 393-8871 
+mailto:awhitton@nortelnetwor= ks.com          = +mailto:avwhitton@alumni.uw= aterloo.ca
"I think...I think it's in my = basement. Let me go upstairs and check."
M.C. Escher (1898-1972)

"There'll be other = days, but, what if today is the only day?"
Field of Dreams


------_=_NextPart_001_01C03CF1.AAE76450-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 09:48:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA06097 for ; Mon, 23 Oct 2000 09:48:52 -0400 (EDT) Received: from standards (47.234.32.16:4505) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA91BA@standards.nortelnetworks.com>; Mon, 23 Oct 2000 9:31:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39873 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 09:31:48 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA91B9@standards.nortelnetworks.com>; Mon, 23 Oct 2000 9:31:48 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA19929; Mon, 23 Oct 2000 09:47:09 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id JAA25857; Mon, 23 Oct 2000 09:47:08 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVJGWW>; Mon, 23 Oct 2000 09:46:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E86D@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 23 Oct 2000 09:47:00 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: requestId in eventsDescriptor for AuditCapReply X-To: Satish Chowdhury To: MEGACO@STANDARDS.NORTELNETWORKS.COM Good question. I'd use ALL. Brian > -----Original Message----- > From: Satish Chowdhury [mailto:satishch@CHIPLOGIC.COM] > Sent: Monday, October 23, 2000 6:04 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: requestId in eventsDescriptor for AuditCapReply > > > Hi all , > Section 7.2.6 says > "... The EventsDescriptor returns the list of possible > events on the > Termination together with the list of all possible values for the > EventsDescriptor Parameters. ..." > > What is the value of requestId sent in the events > Descriptor from MG > to MGC for a AuditCap reply ? > > Thankx > Satish > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 10:37:31 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA18231 for ; Mon, 23 Oct 2000 10:37:30 -0400 (EDT) Received: from standards (47.234.32.16:4505) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA91EC@standards.nortelnetworks.com>; Mon, 23 Oct 2000 10:20:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39937 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 10:20:16 -0400 Received: from qhars002.nortel.com (47.101.112.102:53331) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA91EB@standards.nortelnetworks.com>; Mon, 23 Oct 2000 10:20:16 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Mon, 23 Oct 2000 15:32:42 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 23 Oct 2000 10:31:29 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WR165T>; Mon, 23 Oct 2000 10:31:28 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03CFD.EDF1C090" Message-ID: <28560036253BD41191A10000F8BCBD110250C5EB@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 10:31:28 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: auditing when everything is in th NULL context To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03CFD.EDF1C090 Content-Type: text/plain; charset="iso-8859-1" I'll point out that section 7.1.6 says that "Streams are created by specifying a new StreamID on one of the terminations in a Context." One way of reconciling this with the possibility of provisioned values for LocalControl is to think of provisioning as providing default values which get implemented (unless overridden) when a stream is instantiated. Of course, this doesn't say what happens to streams when a termination is returned to the NULL context. But one clue is the other point made in 7.1.6: streamIDs are of local significance to a context. To me this requires that streams disappear when the termination is SUBTRACTed. > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Wednesday, October 11, 2000 10:22 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: auditing when everything is in th NULL context > > > G'Day Brian, > > I think its a mix of your first possibility and provisioning. > Typically > the first actions will create the stream unless it is previously > provisioned on the MG. > > Cheers, Christian > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > > I wonder , when all terminations are in the NULL context > > > what should be > > > replied in the localControlDescriptor in the > > > StreamMode , is it just not present in this descriptor ? > > > Secondly , i wonder what are the properties that are replied > > > in the local > > > control descriptor ? > > > > Hmmm, excellent question. The root of the question is, "are there > > any streams active for a termination in Null Context?" There is a > > somewhat wider question which is "do streams have to be explicitly > > created before any stream-dependent properties/events/signals can > > be audited?" The latter leads to the question "when is a stream > > created?" > > > > I just posted an answer to a list question that used an example of > > applying a signal (dialtone) to a termination which was in the > > null context. If that is legal, then streams CAN be active on > > a termination in the null context. We get back to when is the > > stream created? I don't recall any discussion on this point. > > > > I think there are two possibilities: > > The first action that creates media (be it a > Media/Local/Remote > > descriptor, or a signal, creates a media stream, and > > a Subtract, or a properly constructed > Media/Local/Remote > > descriptor deletes streams. This implies that there > > are no streams active on a termination in > null context > > after boot, or after a subtract, but you > create one by > > putting media on the termination. > > There is always a default StreamId=1 stream, others > are created > > by a Media descriptor, and deleted by a > Media Descriptor > > or Subtract. > > > > I'd favor the former, but don't think there is very much practical > > difference except the exact question you asked. If there > are no streams > > at some times then if you audited, you would never get a > LocalControl, > > nor a StreamMode when there was not a stream, and you would > when there > > was. If there are always streams with StreamId=1, then you do get > > StreamMode, and you also get a LocalControl descriptor. > > > > The second question you ask is easier to answer. If there are any > > properties defined in LocalControl for packages implemented on a > > termination, then those values are returned in LocalControl > for active > > streams. "Active" is the issue, as discussed above. > > > > Need more opinions I think. Maybe this was settled, and I just > > don't remember how. > > > > Brian > ------_=_NextPart_001_01C03CFD.EDF1C090 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: auditing when everything is in th NULL context

I'll point out that section 7.1.6 says that = "Streams are created by specifying a new StreamID on one of the = terminations in a Context."  One way of reconciling this with = the possibility of provisioned values for LocalControl is to think of = provisioning as providing default values which get implemented (unless = overridden) when a stream is instantiated.

Of course, this doesn't say what happens to streams = when a termination is returned to the NULL context.  But one clue = is the other point made in 7.1.6: streamIDs are of local significance = to a context.  To me this requires that streams disappear when the = termination is SUBTRACTed.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ER= ICSSON.COM]
> Sent: Wednesday, October 11, 2000 10:22 = PM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: auditing when everything is in th = NULL context
>
>
> G'Day Brian,
>
> I think its a mix of your first possibility and = provisioning.
> Typically
> the first actions will create the stream unless = it is previously
> provisioned on the MG.
>
> Cheers, Christian
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > > I  wonder , when all = terminations are in the NULL context
> > > what should be
> > > replied in the localControlDescriptor = in the
> > > StreamMode , is it just not present = in this descriptor ?
> > > Secondly , i wonder what are the = properties that are replied
> > > in the local
> > > control descriptor ?
> >
> > Hmmm, excellent question.  The root = of the question is, "are there
> > any streams active for a termination in = Null Context?"  There is a
> > somewhat wider question which is "do = streams have to be explicitly
> > created before any stream-dependent = properties/events/signals can
> > be audited?"  The latter leads = to the question "when is a stream
> > created?"
> >
> > I just posted an answer to a list question = that used an example of
> > applying a signal (dialtone) to a = termination which was in the
> > null context.  If that is legal, then = streams CAN be active on
> > a termination in the null context.  = We get back to when is the
> > stream created?  I don't recall any = discussion on this point.
> >
> > I think there are two = possibilities:
> = >         The first action = that creates media (be it a
> Media/Local/Remote
> = >           &n= bsp;     descriptor, or a signal, creates a media = stream, and
> = >           &n= bsp;     a Subtract, or a properly constructed =
> Media/Local/Remote
> = >           &n= bsp;     descriptor deletes streams.  This = implies that there
> = >           &n= bsp;     are no streams active on a termination in =
> null context
> = >           &n= bsp;     after boot, or after a subtract, but you =
> create one by
> = >           &n= bsp;     putting media on the termination.
> = >         There is always a = default StreamId=3D1 stream, others
> are created
> = >           &n= bsp;     by a Media descriptor, and deleted by a =
> Media Descriptor
> = >           &n= bsp;     or Subtract.
> >
> > I'd favor the former, but don't think = there is very much practical
> > difference except the exact question you = asked.  If there
> are no streams
> > at some times then if you audited, you = would never get a
> LocalControl,
> > nor a StreamMode when there was not a = stream, and you would
> when there
> > was.  If there are always streams = with StreamId=3D1, then you do get
> > StreamMode, and you also get a = LocalControl descriptor.
> >
> > The second question you ask is easier to = answer.  If there are any
> > properties defined in LocalControl for = packages implemented on a
> > termination, then those values are = returned in LocalControl
> for active
> > streams.  "Active" is the = issue, as discussed above.
> >
> > Need more opinions I think.  Maybe = this was settled, and I just
> > don't remember how.
> >
> > Brian
>

------_=_NextPart_001_01C03CFD.EDF1C090-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 10:50:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA21490 for ; Mon, 23 Oct 2000 10:50:37 -0400 (EDT) Received: from standards (47.234.32.16:4505) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA920A@standards.nortelnetworks.com>; Mon, 23 Oct 2000 10:33:36 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 39976 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 10:33:35 -0400 Received: from qhars002.nortel.com (47.101.112.102:53368) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9209@standards.nortelnetworks.com>; Mon, 23 Oct 2000 10:33:35 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Mon, 23 Oct 2000 15:48:35 +0100 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 23 Oct 2000 10:45:19 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WR17RG>; Mon, 23 Oct 2000 10:45:19 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C5EC@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 10:45:17 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: ISDN PRI X-To: M Kottanipral To: MEGACO@STANDARDS.NORTELNETWORKS.COM Have a look at draft-bouwen-megaco-isdn-01.txt. It looks at aspects of ISDN which might require H.248 action. Don't forget that actions like digit collection and ringing get covered by the Q.931 signalling and therefore need not be included in H.248. > -----Original Message----- > From: M Kottanipral [mailto:mkottanipral@HOTMAIL.COM] > Sent: Wednesday, October 11, 2000 5:28 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: ISDN PRI > > > Hello - > Is there any ISDN Package defined for MEGACO ? Probably > similar to other > packages defined in > MEGACO like Analog line package . Any pointers to something > similar would be > appreciated > > Thanks > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 11:15:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA25589 for ; Mon, 23 Oct 2000 11:15:43 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9268@standards.nortelnetworks.com>; Mon, 23 Oct 2000 10:56:16 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40098 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 10:56:16 -0400 Received: from qhars002.nortel.com (47.101.112.102:53898) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9267@standards.nortelnetworks.com>; Mon, 23 Oct 2000 10:56:16 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Mon, 23 Oct 2000 16:11:20 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 23 Oct 2000 11:10:53 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WR1876>; Mon, 23 Oct 2000 11:10:47 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD110250C5EE@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 11:09:15 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Add with wildcard termination ID X-To: Christian Groves , "samittal@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Christian sums up the current state of the text. He is asking whether we want to deprecate a part of the protocol we have defined. We could always settle that one down the line, by seeing what people have demonstrated in interoperability tests. To answer Sachin's original question: the ADD command is enclosed by an action. In my view, the action is executed first, meaning that the contextId is assigned a value before any Add is attempted. The transaction response will show the enclosing action with assigned contextId, followed by the result for each command up to the first failed command without an "O-" tag. If all of the ADDs failed, the context is deleted immediately after the transaction response is formulated. I know that what I have just said is slightly arbitrary, but I believe it provides a consistent point of view which can guide implementations. > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Wednesday, October 11, 2000 11:54 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Add with wildcard termination ID > > > G'Day All, > > I believe currently in the specification we have with reference to the > terminationID: > o Add with Choose "?" is valid and return 1 termination > o Add with Specific is valid as it adds a specific termination. > o Add with * is allowed as it adds per 7.2.1 1st para. > o In the other commands then only specific or * is allowed. > > Given the current text it states that all matching terminations are > attempted and results for each one are reported. That result could be > OOS, termination ID is already in a context etc. > Choung provided the clarification that OOS terminations can't > be added. > > I must be missing something, where is the problem? > > What do we gain/loose if we remove the possibility of ADD with *? (To > effect this change then I see we only need to update 7.2.1 1st > paragraph). > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > I think we have a significant issue to discuss and we might want > > to think about changing some direction we have already given, > > although I'm not sure how much text. > > > > Up to now, I, and others, have said that you can use a partially > > wildcarded terminationId in a command such as Add using the ALL > > construct, thus "abc*". > > > > This thread has caused me to wonder if this is wrong, and we > > should really use CHOOSE, as others have suggested. Here > is my thinking: > > > > If we interpret ALL as the text states - equivalent to > separate commands > > with each matched terminationID, then "Add=abc*" where abcd > and abce existed > > would be equivalent to "Add=abcd{..., Add=abce{...." > > > > If we interpret CHOOSE as the text states - the MG chooses ONE > > terminationId, > > then "Add=abc?" could be interpreted by the MG as > "Add=abcd" OR "Add=abce", > > but only one, MG's choice. > > > > Given the issues on the thread: > > > > You CAN get more than one Add out of a wildcard using ALL > > You would get an error if one of those matched > terminations was OOS > > You CAN get only one Add of a wildcard using CHOOSE > > The MG would choose an MG that was In Service if, say, > abce was OOS, it > > would choose abcd if asked to Add=abc? > > > > This allows the MGC to decide exactly how it wants partial > wildcarded > > commands to be done. ALL might work well with Audit, > CHOOSE might be > > more appropriate with Add (in most cases anyway). > > > > Brian > > > > -----Original Message----- > > From: Chuong Nguyen [mailto:Chuong.Nguyen@USA.ALCATEL.COM] > > Sent: Tuesday, October 10, 2000 2:26 PM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Add with wildcard termination ID > > > > Section 7.2.1 there is the following statement: > > "Add SHALL NOT be used on a Termination with a serviceState of > > "OutofService"." > > So I assume that MG should return an error on this ADD. > > Chuong > > > > Kevin Boyle wrote: > > It seems to me that if you can only add one termination per > command, then > > use of the ALL (*) wildcard is not allowed for Add. CHOOSE > ($), however, > > would be acceptable. There are other commands where these kinds of > > restrictions are already expressed, so why not add one for > Add in the > > Implementer's Guide? > > It would also seem to me that if a termination is OOS, then > adding it is not > > > > allowed. Once again, somthing for the Implementer's Guide? > > Kevin > > "Rosen, Brian" wrote: > > > First of all, an Add only can add one termination per command, > > > so Add=abc* would only add abcd. Pressing on, if, for > > > example, abcd was already in a context, then the > > > error would be in $ context, and would indicate no terminations > > > matched, I suppose. > > > > > > We might want to think about whether outofservice really causes > > > a no terminations matched situation. On the one hand, adding > > > an out of service termination makes no sense. On the other hand > > > auditing one does. So does the matching logic work differently > > > for Audit than it does for Add? I would think it shouldn't, > > > thus we have a quandry. > > > > > > Brian > > > > > > -----Original Message----- > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > > Sent: Monday, October 09, 2000 4:13 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Add with wildcard termination ID > > > > > > Suppose there are two terminations in MG named "abcd" and "abce" > > > and MGC sends an ADD as > > > CtxID=$ ADD TermID=abc* > > > Now MG is able to create a Context and successfully ADD > "abcd" in it, but > > > ADDing of "abce" fails (say because of "abce" being > "outofservice") > > > > > > What ContextID will be used in the response for the > termination "abce": > > > 1. $ > > > 2. The allocated ContextID for "abcd" > > > > > > Sachin > > -- > > Alcatel USA, Inc Internet: > Chuong.Nguyen@usa.alcatel.com > > 1000 Coit Road Plano, Texas 75075 Phone: > (972) 519-4613 > > **** The opinions expressed are not those of Alcatel USA, Inc **** > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 11:49:12 2000 Received: from standards.nortelnetworks.com ([47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA01552 for ; Mon, 23 Oct 2000 11:49:10 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA92BE@standards.nortelnetworks.com>; Mon, 23 Oct 2000 11:32:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40212 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 11:32:08 -0400 Received: from qhars002.nortel.com (47.101.112.102:54116) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA92BD@standards.nortelnetworks.com>; Mon, 23 Oct 2000 11:32:08 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Mon, 23 Oct 2000 16:47:32 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Mon, 23 Oct 2000 10:29:29 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Oct 2000 10:29:21 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD110250C5EF@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 10:29:19 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: ServiceState of a termination X-To: "samittal@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM This is arbitrary, but I do not believe that ServiceState should be modifiable through the Modify command, simply on the principle that as much as possible we should have only one way to perform any particular task. In other words, I agree with your view. > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Thursday, October 12, 2000 3:23 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: ServiceState of a termination > > > Is the changing of ServiceState of a termination directly > from inservice to > outofservice and vice-versa allowed > in say a Modify. Is this equivalent in functional operation > to a ServiceChange > on that termination. > > I believe that the ServiceState values outofservice and > inservice are not > settable directly my MGC and only > indicate the current state that can be modified using > SerivceChange. This seems > to make ServiceState property > as "read-only" type for these two values. But then what about > "test" value ? > > Sachin > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 13:14:53 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA16354 for ; Mon, 23 Oct 2000 13:14:51 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9495@standards.nortelnetworks.com>; Mon, 23 Oct 2000 12:57:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 40809 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 12:57:40 -0400 Received: from qhars002.nortel.com (47.101.112.102:54632) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9494@standards.nortelnetworks.com>; Mon, 23 Oct 2000 12:57:40 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Mon, 23 Oct 2000 18:12:50 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 23 Oct 2000 12:08:34 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Oct 2000 12:12:36 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C5F5@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 12:12:35 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Digitmap definition override X-To: "samittal@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Thursday, October 12, 2000 5:43 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Digitmap definition override > > > The text says that a digitmap once defined can be overriden with a new > definition. > But if the digitmap is defined by management action outside > the scope of MGC, > can MGC override that with a definition of it's own. > [PTT] I'd say this is permissible -- there may be circumstances where it is desirable to use this capability. > > Also say there are terminations: > 1. aaab > 2. aaac > 3. aabd > 4. aabe > > And the same digitmap name is used to define digitmaps on > aaa* and aab* with > different > definitions. Is it allowed ? What if some terminations belong > to both the > wildcarded names > used in such definitions. [PTT] Digitmaps can be defined on individual terminations. The current value for a digitmap is that set by the most recent command affecting that termination. A wildcarded command is interpreted as a series of individual commands, each affecting one termination. Thus the answer to your question is that digitmap values are independent of naming conventions except as these affect command execution. > > Sachin > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 13:38:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA19273 for ; Mon, 23 Oct 2000 13:38:27 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA961E@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:22:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41301 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 13:22:55 -0400 Received: from qhars002.nortel.com (47.101.112.102:54690) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA961D@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:22:55 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Mon, 23 Oct 2000 18:38:18 +0100 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 23 Oct 2000 13:34:36 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRF1R7>; Mon, 23 Oct 2000 13:34:36 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C5F7@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 13:34:24 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Audit of packages X-To: "chassija@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM I agree with your interpretation: our intent was that if you support an extension, you also support the complete base package. > -----Original Message----- > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > Sent: Friday, October 13, 2000 12:29 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > Hello Brian, > > If this is the case as you are pointing out, then it should > be clearly mentioned > in the protocol. Because the protocol says only the following > --- in context of > Package B extending Package A -- > > Sec 12.1.1 - " When a package > extends another package it shall only add additional Properties, > Events, Signals, Statistics and new possible values for an > existing parameter described in the original package. An extended > package shall not redefine or overload a name defined in the > original package." > > This seems to imply that Package B has to support all the > events supported on > Package A...... > > What is your opinion on this.... > Chanchal.... > > > > > > "Rosen, Brian" on 10/13/2000 01:32:21 AM > > Please respond to "Rosen, Brian" > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > cc: (bcc: Chanchal Hassija/HSS) > > Subject: Re: Audit of packages > > > > > I don't think there is any change to the base understanding. > > Suppose Package A defines Event e1 > Suppose Package B extends Package A. > > Now, you can talk about A/e1 or B/e1. > > If you "expose" package A, then you would include A in the > list of packages reported on an audit, and A/e1 as well as B/e1 > would be legal. > > If you don't expose package A, then you can only use B/e1. > > In both cases the extended package inherits the behavior of the > base package. > > Brian > > > -----Original Message----- > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > Sent: Thursday, October 12, 2000 11:55 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Audit of packages > > > > > > The idea of supporting extending package but not supporting > > base package > > is not the basic philosophy of extension of packages which says that > > extended package inherits the behaviour of base package. > > > > So do we need to change the basic understanding of package > extensions. > > > > > > > > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > > > Please respond to Dave Sclarsky > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Sachin Mittal/HSS) > > > > Subject: Re: Audit of packages > > > > > > > > > > What do you think about the case where an MG can support pkg2 > > but NOT pkg3? > > > > Take the case of the Tone Detection Package and the DTMF > > Detection Package > > that extends it. There are most certainly 'intelligent' > > devices that are > > capable of reporting DTMF digits, but do not offer the > > granularity to report > > 'Start tone' or 'End tone' detected. > > > > I would have assumed that an MG with such a device would > > (should!) publish > > dd but not tonedet, because it really cannot notify tonedet/std or > > tonedet/etd. > > > > DaveS. > > > > > > -----Original Message----- > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > Sent: Wednesday, October 11, 2000 10:25 PM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > > when it is > > > inappropriate and we have the rule saying that you can address > > > properties by pkg3. > > > > > > But, I'm happy with Should if you can provide the text when it is > > > inappropriate. > > > > > > Cheers, Christian > > > > > > Peter Blatherwick wrote: > > -------------------------- > > > > > > I agree in general, since "extends" basically means > "clone the base > > > package and add some more functionality" (no subsetting, > over-riding > > > etc allowed). In example below pkg2 by definition > implements pkg3. > > > (Not the case with re-versioning of Packages though!) > > > > > > One clarification however. It does not always make sense > for a base > > > package to be published as implemented by an MG. There > are examples > > > where the base package is defined such that it acts similar to a > > > virtual class, and has no function on its own, simply defining > > > interface for one or more derived packages. Annex E ToneGen and > > > ToneDet as well as a few packages in Annex G are examples. > > Therefore, > > > implementer's guide MUST not make a hard and fast rule on > this, but > > > SHOULD say "SHOULD" with some words to describe where its > > > inappropriate. > > > > > > -- Peter > > > > > > -----Original Message----- > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > Sent: Monday, October 09, 2000 16:03 > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > We've been around this and basically, it is up to the MG. > > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > > is a good word, and I wonder if text to that effect > > > should go in the implementor's guide? > > > > > > Brian > > > > > > -----Original Message----- > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > > Sent: Monday, October 09, 2000 5:12 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Audit of packages > > > > > > Say a termination abc implements the following packages: > > > 1. pkg1 > > > 2. pkg2 > > > where pkg2 extends pkg3 and pkg1 doesn't extend any other package > > > > > > If this termination is audited for packages implemented on it, > > > should the reply include pkg3 with pkg1 and pkg2 (base > package names > > > are included) > > > > > > Sachin > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 13:52:24 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id NAA21712 for ; Mon, 23 Oct 2000 13:52:23 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9688@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:35:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41430 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 13:35:20 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9687@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:35:19 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA15147; Mon, 23 Oct 2000 13:50:43 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id NAA08404; Mon, 23 Oct 2000 13:50:42 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRTZ74>; Mon, 23 Oct 2000 13:49:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E877@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 23 Oct 2000 13:50:13 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Audit of packages X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM Yes, but you support the base parameters, events, signals and statistics on the "new" package name (B/e1). Support of the base package is optional (A/e1). Words to that effect would be a good idea. Brian > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Monday, October 23, 2000 1:34 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > I agree with your interpretation: our intent was that if you > support an > extension, you also support the complete base package. > > > -----Original Message----- > > From: Chanchal Hassija [mailto:chassija@HSS.HNS.COM] > > Sent: Friday, October 13, 2000 12:29 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: Audit of packages > > > > > > Hello Brian, > > > > If this is the case as you are pointing out, then it should > > be clearly mentioned > > in the protocol. Because the protocol says only the following > > --- in context of > > Package B extending Package A -- > > > > Sec 12.1.1 - " When a package > > extends another package it shall only add additional > Properties, > > Events, Signals, Statistics and new possible values for an > > existing parameter described in the original package. > An extended > > package shall not redefine or overload a name defined in the > > original package." > > > > This seems to imply that Package B has to support all the > > events supported on > > Package A...... > > > > What is your opinion on this.... > > Chanchal.... > > > > > > > > > > > > "Rosen, Brian" on 10/13/2000 01:32:21 AM > > > > Please respond to "Rosen, Brian" > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > cc: (bcc: Chanchal Hassija/HSS) > > > > Subject: Re: Audit of packages > > > > > > > > > > I don't think there is any change to the base understanding. > > > > Suppose Package A defines Event e1 > > Suppose Package B extends Package A. > > > > Now, you can talk about A/e1 or B/e1. > > > > If you "expose" package A, then you would include A in the > > list of packages reported on an audit, and A/e1 as well as B/e1 > > would be legal. > > > > If you don't expose package A, then you can only use B/e1. > > > > In both cases the extended package inherits the behavior of the > > base package. > > > > Brian > > > > > -----Original Message----- > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > > Sent: Thursday, October 12, 2000 11:55 AM > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > > > > The idea of supporting extending package but not supporting > > > base package > > > is not the basic philosophy of extension of packages > which says that > > > extended package inherits the behaviour of base package. > > > > > > So do we need to change the basic understanding of package > > extensions. > > > > > > > > > > > > > > > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > > > > > Please respond to Dave Sclarsky > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > What do you think about the case where an MG can support pkg2 > > > but NOT pkg3? > > > > > > Take the case of the Tone Detection Package and the DTMF > > > Detection Package > > > that extends it. There are most certainly 'intelligent' > > > devices that are > > > capable of reporting DTMF digits, but do not offer the > > > granularity to report > > > 'Start tone' or 'End tone' detected. > > > > > > I would have assumed that an MG with such a device would > > > (should!) publish > > > dd but not tonedet, because it really cannot notify tonedet/std or > > > tonedet/etd. > > > > > > DaveS. > > > > > > > > > -----Original Message----- > > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > > Sent: Wednesday, October 11, 2000 10:25 PM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Audit of packages > > > > > > > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > > > when it is > > > > inappropriate and we have the rule saying that you can address > > > > properties by pkg3. > > > > > > > > But, I'm happy with Should if you can provide the text > when it is > > > > inappropriate. > > > > > > > > Cheers, Christian > > > > > > > > Peter Blatherwick wrote: > > > -------------------------- > > > > > > > > I agree in general, since "extends" basically means > > "clone the base > > > > package and add some more functionality" (no subsetting, > > over-riding > > > > etc allowed). In example below pkg2 by definition > > implements pkg3. > > > > (Not the case with re-versioning of Packages though!) > > > > > > > > One clarification however. It does not always make sense > > for a base > > > > package to be published as implemented by an MG. There > > are examples > > > > where the base package is defined such that it acts similar to a > > > > virtual class, and has no function on its own, simply defining > > > > interface for one or more derived packages. Annex E ToneGen and > > > > ToneDet as well as a few packages in Annex G are examples. > > > Therefore, > > > > implementer's guide MUST not make a hard and fast rule on > > this, but > > > > SHOULD say "SHOULD" with some words to describe where its > > > > inappropriate. > > > > > > > > -- Peter > > > > > > > > -----Original Message----- > > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > > Sent: Monday, October 09, 2000 16:03 > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Audit of packages > > > > > > > > We've been around this and basically, it is up to the MG. > > > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > > > is a good word, and I wonder if text to that effect > > > > should go in the implementor's guide? > > > > > > > > Brian > > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > > > Sent: Monday, October 09, 2000 5:12 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Audit of packages > > > > > > > > Say a termination abc implements the following packages: > > > > 1. pkg1 > > > > 2. pkg2 > > > > where pkg2 extends pkg3 and pkg1 doesn't extend any > other package > > > > > > > > If this termination is audited for packages implemented on it, > > > > should the reply include pkg3 with pkg1 and pkg2 (base > > package names > > > > are included) > > > > > > > > Sachin > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 14:05:12 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA24251 for ; Mon, 23 Oct 2000 14:05:11 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA96EE@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:48:08 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41565 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 13:48:07 -0400 Received: from qhars002.nortel.com (47.101.112.102:54746) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA96EB@standards.nortelnetworks.com>; Mon, 23 Oct 2000 13:48:07 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Mon, 23 Oct 2000 19:03:27 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 23 Oct 2000 14:02:17 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRFF8J>; Mon, 23 Oct 2000 14:02:16 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD110250C5F9@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 14:02:15 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Topology Descriptor X-To: "bmbabu@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Context properties are processed before commands. See section 7.1.18 for details on use of the CHOOSE wildcard for a termination in a topology relationship. In practical terms, it is probably best to use one action to define what terminations are in the context, followed by another action in a subsequent transaction to set the topology. > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Thursday, October 12, 2000 11:25 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Topology Descriptor > > > Descriptor processing sequence is determined by the order sent by MGC. > When does the topology descriptor processed? After processing all the > commands pertained to the action? > 1. If there are no ADDs in the action > 2. If there is only single ADD in the action > 3. If there are more than one ADD in the Action > > What if the action also have one or two MOVEs in it. > > Regards > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 14:26:58 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA26989 for ; Mon, 23 Oct 2000 14:26:57 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9722@standards.nortelnetworks.com>; Mon, 23 Oct 2000 14:09:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41635 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 14:09:43 -0400 Received: from qhars002.nortel.com (47.101.112.102:54790) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9721@standards.nortelnetworks.com>; Mon, 23 Oct 2000 14:09:43 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Mon, 23 Oct 2000 19:24:52 +0100 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Mon, 23 Oct 2000 14:21:19 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRFG57>; Mon, 23 Oct 2000 14:21:19 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C5FA@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 14:21:16 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Audit & Events X-To: Isabelle Cnudde To: MEGACO@STANDARDS.NORTELNETWORKS.COM Answers interspersed below. > -----Original Message----- > From: Isabelle Cnudde [mailto:Isabelle.Cnudde@IND.ALCATEL.COM] > Sent: Thursday, October 12, 2000 11:48 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Audit & Events > > > Hi, > > Could someone explain me what are the difference between all the > *event* descriptors? and what should be returned to the commands > AuditCapabilities and AuditValue? > Here is my understanding and open points: > > EventsDescriptor > ---------------- > . AuditCapabilities > Return the list of possible events on the Termination together with > the list of all possible values for the EventsDescriptor Parameters. > . AuditValue > What should be returned? [PTT] The current value of the EventsDescriptor (i.e.) the latest value of the descriptor as set by the the MGC. > > ObservedEventsDescriptor > ------------------------ > . AuditCapabilities > Return the names of active events on the termination. > What is an "active event"? > Is that a list of events that has to be observed on a termination? [PTT] Yes. Note that the entire EventsDescriptor becomes "inactive" in lockstep reporting mode, after a report has been sent to the MGC. Note also that the digitmap completion event becomes inactive after it has been reported to the MGC. > . AuditValue > Returns a list of events in the EventBuffer. > Is that a list of events that has been observed on a termination? [PTT] Yes. Note that events are accumulated in EventBuffer only when event reporting is operating in lockstep mode. > > EventBufferDescriptor > --------------------- > . AuditCapabilities > The appropriate descriptors, with the possible values for the > Termination are returned from AuditCapabilities. > What should be returned? [PTT] Same content as for EventsDescriptor. > . AuditValue > Return content of the EventBufferDescriptor = all events that has been > observed? [PTT] That's an error which was corrected in draft-ietf-megaco-merged-01.txt (i.e. H.248 as decided). The standard now reads "EventBuffer returns the set of events and associated parameter values currently enabled in the EventBufferDescriptor." > Then, what's the difference with the ObservedEventsDescriptor? > > Thanks for any clarification on the topic! > Isabelle > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 14:58:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA05089 for ; Mon, 23 Oct 2000 14:58:23 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9751@standards.nortelnetworks.com>; Mon, 23 Oct 2000 14:41:24 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41694 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 14:41:24 -0400 Received: from qhars002.nortel.com (47.101.112.102:54841) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9750@standards.nortelnetworks.com>; Mon, 23 Oct 2000 14:41:24 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Mon, 23 Oct 2000 19:56:34 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 23 Oct 2000 13:51:36 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Oct 2000 13:55:39 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C5FF@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 13:55:37 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: wildcarded termination in Move X-To: "samittal@HSS.HNS.COM" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Don't consider terminations in NULL context for MOVE. I know it's an arbitrary choice, but it's more sensible than failing a transaction by trying something that shouldn't have been tried in the first place. > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Tuesday, October 17, 2000 5:52 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: wildcarded termination in Move > > > If there are three terminations in an MG > abcd > abce > xyz. > Say abcd is in Context ID = 1 and both abce and xyz is in > NULL Context. > If MGC says Move with ContextID = $ and termination as abc*, > what should the > MG do > 1. Consider abce while resolving wildcarded abc* - > Move is valid for abcd (it's in non-NULL context) and invalid for > abce (move is not allowed to move from and to a NULL Context) > 2. Don't consider terminations in NULL Context for resolving > wildcard since > the basic idea is not to Move to or from NULL Context. > > The first option has an impact on further commands in the > transaction since a > failure > with one command can cause the side effect of other commands > being not executed. > > Sachin > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 15:05:29 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA06723 for ; Mon, 23 Oct 2000 15:05:28 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA976B@standards.nortelnetworks.com>; Mon, 23 Oct 2000 14:48:20 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41729 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 14:48:20 -0400 Received: from qhars002.nortel.com (47.101.112.102:54854) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA976A@standards.nortelnetworks.com>; Mon, 23 Oct 2000 14:48:19 -0400 Received: from smtprch1.nortel.com (actually erchg0j) by qhars002.nortel.com; Mon, 23 Oct 2000 20:03:29 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch1.nortel.com; Mon, 23 Oct 2000 12:43:38 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Oct 2000 12:43:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D18.BE78A160" Message-ID: <28560036253BD41191A10000F8BCBD110250C5F8@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 12:43:25 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Audit of packages X-To: Christian Groves To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03D18.BE78A160 Content-Type: text/plain; charset="iso-8859-1" I have a disagreement with the portion of text indicated below and suggest that it be dropped. The ambiguity is about names, not about implementation: the standard leaves no ambiguity about the requirement to support all of the base package. > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Monday, October 16, 2000 2:14 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > G'Day all, > > Below is the text which I propose to put into the implementor's guide. > Its a mix of Brian and Pete's proposed words. I note that I changed > Brian's MAY to Pete's SHOULD. > > 9.5 Package Extension and Referencing > > Description: The current text in H.248 Section 12.1 is > ambiguous about > the usage of package names when referencing properties, > events, signals > and statistics in a base package and an extended package. > Reference: Subject: Re: Audit of packages > Date: Fri, 13 Oct 2000 07:58:12 -0400 > From: "Rosen, Brian" > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: RE: Audit of packages > Date: Fri, 13 Oct 2000 15:15:14 -0500 > From: "Peter Blatherwick" > To: "'Christian Groves'" > CC: megaco@standards.nortelnetworks.com, "'Rosen, Brian'" > > > [Begin Clarification] > Section 12.1 > When packages are extended, the properties, events, signals and > statistics defined in the base package can be referred to using the > extended package name. For example, if Package A defines > event e1, and > Package B extends Package A, then B/e1 is an event for a termination > implementing Package B. [PTT] The MG SHOULD also "implement" the base > Package. If it does, then A would be reported on the Package > Descriptor > in AuditValue as well as B, and event A/e1 would be available on a > termination. If the MG does not implement A, then only B/e1 would be > available. If implemented, [PTT] > A/e1 and B/e1 are the same event. > An MG SHOULD publish all Packages supported by its Terminations, > including base Packages from which extended Packages are derived. An > exception to this is in cases where the base Packages are expressly > designed to be extended by others, not directly controlled, > and may not > have any function on their own or be nonsensical on their own. > [End Clarification] > > Any problems with the text? > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > We probably need some words in the Implementer's Guide, I agree. > > > > How about something like: > > When packages are extended, the properties, events, signals > and statistics > > defined in the base package can be referred to using the > extended package > > name. For example, if Package A defines event e1, and > Package B extends > > Package A, then B/e1 is an event for a termination > implementing Package B. > > The MG MAY also "implement" the base Package. If it does, > then A would > > be reported on the Package Descriptor in AuditValue as well > as B, and > > event A/e1 would be available on a termination. If the MG does not > > implement A, then only B/e1 would be available. Of course, > if implemented, > > A/e1 and B/e1 are the same event. > > > > Brian > > > > > -----Original Message----- > > > From: chassija@hss.hns.com [mailto:chassija@hss.hns.com] > > > Sent: Friday, October 13, 2000 12:29 AM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Hello Brian, > > > > > > If this is the case as you are pointing out, then it should > > > be clearly mentioned > > > in the protocol. Because the protocol says only the following > > > --- in context of > > > Package B extending Package A -- > > > > > > Sec 12.1.1 - " When a package > > > extends another package it shall only add additional > Properties, > > > Events, Signals, Statistics and new possible values for an > > > existing parameter described in the original > package. An extended > > > package shall not redefine or overload a name defined in the > > > original package." > > > > > > This seems to imply that Package B has to support all the > > > events supported on > > > Package A...... > > > > > > What is your opinion on this.... > > > Chanchal.... > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/13/2000 01:32:21 AM > > > > > > Please respond to "Rosen, Brian" > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > I don't think there is any change to the base understanding. > > > > > > Suppose Package A defines Event e1 > > > Suppose Package B extends Package A. > > > > > > Now, you can talk about A/e1 or B/e1. > > > > > > If you "expose" package A, then you would include A in the > > > list of packages reported on an audit, and A/e1 as well as B/e1 > > > would be legal. > > > > > > If you don't expose package A, then you can only use B/e1. > > > > > > In both cases the extended package inherits the behavior of the > > > base package. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > > > Sent: Thursday, October 12, 2000 11:55 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Audit of packages > > > > > > > > > > > > The idea of supporting extending package but not supporting > > > > base package > > > > is not the basic philosophy of extension of packages > which says that > > > > extended package inherits the behaviour of base package. > > > > > > > > So do we need to change the basic understanding of package > > > extensions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > > > > > > > Please respond to Dave Sclarsky > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > > > > > > What do you think about the case where an MG can support pkg2 > > > > but NOT pkg3? > > > > > > > > Take the case of the Tone Detection Package and the DTMF > > > > Detection Package > > > > that extends it. There are most certainly 'intelligent' > > > > devices that are > > > > capable of reporting DTMF digits, but do not offer the > > > > granularity to report > > > > 'Start tone' or 'End tone' detected. > > > > > > > > I would have assumed that an MG with such a device would > > > > (should!) publish > > > > dd but not tonedet, because it really cannot notify > tonedet/std or > > > > tonedet/etd. > > > > > > > > DaveS. > > > > > > > > > > > > -----Original Message----- > > > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > > > Sent: Wednesday, October 11, 2000 10:25 PM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > > > > when it is > > > > > inappropriate and we have the rule saying that you can address > > > > > properties by pkg3. > > > > > > > > > > But, I'm happy with Should if you can provide the > text when it is > > > > > inappropriate. > > > > > > > > > > Cheers, Christian > > > > > > > > > > Peter Blatherwick wrote: > > > > -------------------------- > > > > > > > > > > I agree in general, since "extends" basically means > > > "clone the base > > > > > package and add some more functionality" (no subsetting, > > > over-riding > > > > > etc allowed). In example below pkg2 by definition > > > implements pkg3. > > > > > (Not the case with re-versioning of Packages though!) > > > > > > > > > > One clarification however. It does not always make sense > > > for a base > > > > > package to be published as implemented by an MG. There > > > are examples > > > > > where the base package is defined such that it acts > similar to a > > > > > virtual class, and has no function on its own, simply defining > > > > > interface for one or more derived packages. Annex E > ToneGen and > > > > > ToneDet as well as a few packages in Annex G are examples. > > > > Therefore, > > > > > implementer's guide MUST not make a hard and fast rule on > > > this, but > > > > > SHOULD say "SHOULD" with some words to describe where its > > > > > inappropriate. > > > > > > > > > > -- Peter > > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > > > Sent: Monday, October 09, 2000 16:03 > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > We've been around this and basically, it is up to the MG. > > > > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > > > > is a good word, and I wonder if text to that effect > > > > > should go in the implementor's guide? > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > > > > Sent: Monday, October 09, 2000 5:12 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Audit of packages > > > > > > > > > > Say a termination abc implements the following packages: > > > > > 1. pkg1 > > > > > 2. pkg2 > > > > > where pkg2 extends pkg3 and pkg1 doesn't extend any > other package > > > > > > > > > > If this termination is audited for packages implemented on it, > > > > > should the reply include pkg3 with pkg1 and pkg2 (base > > > package names > > > > > are included) > > > > > > > > > > Sachin > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C03D18.BE78A160 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Audit of packages

I have a disagreement with the portion of text = indicated below and suggest that it be dropped.  The ambiguity is = about names, not about implementation: the standard leaves no ambiguity = about the requirement to support all of the base package.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ER= ICSSON.COM]
> Sent: Monday, October 16, 2000 2:14 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Audit of packages
>
>
> G'Day all,
>
> Below is the text which I propose to put into = the implementor's guide.
> Its a mix of Brian and Pete's proposed words. I = note that I changed
> Brian's MAY to Pete's SHOULD.
>
> 9.5     Package Extension = and Referencing
>
> Description:    The current text = in H.248 Section 12.1 is
> ambiguous about
> the usage of package names when referencing = properties,
> events, signals
> and statistics in a base package and an = extended package.
> Reference:      = Subject: Re: Audit of packages
> Date: Fri, 13 Oct 2000 07:58:12 -0400
> From: "Rosen, Brian" = <Brian.Rosen@MARCONI.COM>
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>
> Subject: RE: Audit of packages
> Date: Fri, 13 Oct 2000 15:15:14 -0500
> From: "Peter Blatherwick" = <blather@nortelnetworks.com>
> To: "'Christian Groves'" = <Christian.Groves@ericsson.com>
> CC: megaco@standards.nortelnetworks.com, = "'Rosen, Brian'"
> <Brian.Rosen@MARCONI.COM>
>
> [Begin Clarification]
> Section 12.1
> When packages are extended, the properties, = events, signals and
> statistics defined in the base package can be = referred to using the
> extended package name.  For example, if = Package A defines
> event e1, and
> Package B extends Package A, then B/e1 is an = event for a termination
> implementing Package B.

[PTT] <begin text proposed to be = omitted>
The MG SHOULD also "implement" the = base
> Package.  If it does, then A would be = reported on the Package
> Descriptor
> in AuditValue as well as B, and event A/e1 = would be available on a
> termination.  If the MG does not implement = A, then only B/e1 would be
> available.  If implemented,
[PTT] <end text proposed to be omitted>

> A/e1 and B/e1 are the same event.
> An MG SHOULD publish all Packages supported by = its Terminations,
> including base Packages from which extended = Packages are derived.  An
> exception to this is in cases where the base = Packages are expressly
> designed to be extended by others, not directly = controlled,
> and may not
> have any function on their own or be = nonsensical on their own.
> [End Clarification]
>
> Any problems with the text?
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > We probably need some words in the = Implementer's Guide, I agree.
> >
> > How about something like:
> > When packages are extended, the = properties, events, signals
> and statistics
> > defined in the base package can be = referred to using the
> extended package
> > name.  For example, if Package A = defines event e1, and
> Package B extends
> > Package A, then B/e1 is an event for a = termination
> implementing Package B.
> > The MG MAY also "implement" the = base Package.  If it does,
> then A would
> > be reported on the Package Descriptor in = AuditValue as well
> as B, and
> > event A/e1 would be available on a = termination.  If the MG does not
> > implement A, then only B/e1 would be = available.  Of course,
> if implemented,
> > A/e1 and B/e1 are the same event.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: chassija@hss.hns.com [mailto:chassija@hss.hns.com]
> > > Sent: Friday, October 13, 2000 12:29 = AM
> > > To: Rosen, Brian
> > > Cc: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Audit of packages
> > >
> > >
> > >
> > >
> > > Hello Brian,
> > >
> > > If this is the case as you are = pointing out, then it should
> > > be clearly mentioned
> > > in the protocol. Because the protocol = says only the following
> > > --- in context of
> > > Package B extending Package A = --
> > >
> > > Sec 12.1.1 - " When a = package
> > >      extends = another package it shall only add additional
> Properties,
> > >      Events, = Signals, Statistics and new possible values for an
> > >      = existing parameter described in the original
> package. An extended
> > >      package = shall not redefine or overload a name defined in the
> > >      = original package."
> > >
> > > This seems to imply that Package B = has to support all the
> > > events supported on
> > > Package A......
> > >
> > > What is your opinion on = this....
> > > Chanchal....
> > >
> > >
> > >
> > >
> > >
> > > "Rosen, Brian" = <Brian.Rosen@MARCONI.COM> on 10/13/2000 01:32:21 AM
> > >
> > > Please respond to "Rosen, = Brian" <Brian.Rosen@MARCONI.COM>
> > >
> > > To:   = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > cc:    (bcc: Chanchal = Hassija/HSS)
> > >
> > > Subject:  Re: Audit of = packages
> > >
> > >
> > >
> > >
> > > I don't think there is any change to = the base understanding.
> > >
> > > Suppose Package A defines Event = e1
> > > Suppose Package B extends Package = A.
> > >
> > > Now, you can talk about A/e1 or = B/e1.
> > >
> > > If you "expose" package A, = then you would include A in the
> > > list of packages reported on an = audit, and A/e1 as well as B/e1
> > > would be legal.
> > >
> > > If you don't expose package A, then = you can only use B/e1.
> > >
> > > In both cases the extended package = inherits the behavior of the
> > > base package.
> > >
> > > Brian
> > >
> > > > -----Original = Message-----
> > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> > > > Sent: Thursday, October 12, 2000 = 11:55 AM
> > > > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Audit of = packages
> > > >
> > > >
> > > > The idea of supporting extending = package but not supporting
> > > > base package
> > > > is not the basic philosophy of = extension of packages
> which says that
> > > > extended package inherits the = behaviour of base package.
> > > >
> > > > So do we need to change the = basic understanding of package
> > > extensions.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Dave Sclarsky = <dsclarsky@SS7-LINK.COM> on 10/12/2000 07:44:17 PM
> > > >
> > > > Please respond to Dave Sclarsky = <dsclarsky@SS7-LINK.COM>
> > > >
> > > > To:   = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > cc:    (bcc: = Sachin Mittal/HSS)
> > > >
> > > > Subject:  Re: Audit of = packages
> > > >
> > > >
> > > >
> > > >
> > > > What do you think about the case = where an MG can support pkg2
> > > > but NOT pkg3?
> > > >
> > > > Take the case of the Tone = Detection Package and the DTMF
> > > > Detection Package
> > > > that extends it.  There are = most certainly 'intelligent'
> > > > devices that are
> > > > capable of reporting DTMF = digits, but do not offer the
> > > > granularity to report
> > > > 'Start tone' or 'End tone' = detected.
> > > >
> > > > I would have assumed that an MG = with such a device would
> > > > (should!) publish
> > > > dd but not tonedet, because it = really cannot notify
> tonedet/std or
> > > > tonedet/etd.
> > > >
> > > > DaveS.
> > > >
> > > >
> > > > -----Original = Message-----
> > > > > From: Christian Groves [mailto:Christian.Groves@ER= ICSSON.COM]
> > > > > Sent: Wednesday, October = 11, 2000 10:25 PM
> > > > > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Audit of = packages
> > > > >
> > > > >
> > > > > Perhaps we = "should" say "SHALL", I can't think of a case = of
> > > > when it is
> > > > > inappropriate and we have = the rule saying that you can address
> > > > > properties by pkg3.
> > > > >
> > > > > But, I'm happy with Should = if you can provide the
> text when it is
> > > > > inappropriate.
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > Peter Blatherwick wrote:
> > > > = --------------------------
> > > > >
> > > > > I agree in general, since = "extends" basically means
> > > "clone the base
> > > > > package and add some more = functionality" (no subsetting,
> > > over-riding
> > > > > etc allowed).  In = example below pkg2 by definition
> > > implements pkg3.
> > > > > (Not the case with = re-versioning of Packages though!)
> > > > >
> > > > > One clarification = however.  It does not always make sense
> > > for a base
> > > > > package to be published as = implemented by an MG.  There
> > > are examples
> > > > > where the base package is = defined such that it acts
> similar to a
> > > > > virtual class, and has no = function on its own, simply defining
> > > > > interface for one or more = derived packages.  Annex E
> ToneGen and
> > > > > ToneDet as well as a few = packages in Annex G are examples.
> > > > Therefore,
> > > > > implementer's guide MUST = not make a hard and fast rule on
> > > this, but
> > > > > SHOULD say = "SHOULD" with some words to describe where its
> > > > > inappropriate.
> > > > >
> > > > > -- Peter
> > > > >
> > > > > -----Original = Message-----
> > > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > > > > Sent: Monday, October 09, = 2000 16:03
> > > > > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Audit of = packages
> > > > >
> > > > > We've been around this and = basically, it is up to the MG.
> > > > > It does not HAVE to report = pkg3, but it could.  Maybe SHOULD
> > > > > is a good word, and I = wonder if text to that effect
> > > > > should go in the = implementor's guide?
> > > > >
> > > > > Brian
> > > > >
> > > > > -----Original = Message-----
> > > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> > > > > Sent: Monday, October 09, = 2000 5:12 AM
> > > > > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Audit of = packages
> > > > >
> > > > > Say a termination abc = implements the following packages:
> > > > > 1. pkg1
> > > > > 2. pkg2
> > > > > where pkg2 extends pkg3 and = pkg1 doesn't extend any
> other package
> > > > >
> > > > > If this termination is = audited for packages implemented on it,
> > > > > should the reply include = pkg3 with pkg1 and pkg2 (base
> > > package names
> > > > > are included)
> > > > >
> > > > > Sachin
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>

------_=_NextPart_001_01C03D18.BE78A160-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 15:18:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA09688 for ; Mon, 23 Oct 2000 15:18:55 -0400 (EDT) Received: from standards (47.234.32.16:4677) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA978B@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:01:50 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41773 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 15:01:50 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA978A@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:01:47 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA23906; Mon, 23 Oct 2000 15:17:09 -0400 (EDT) Received: from whq-msgrtr-02.fore.com (whq-msgrtr-02.pit.comms.marconi.com [169.144.2.220]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id PAA03103; Mon, 23 Oct 2000 15:17:09 -0400 (EDT) Received: by whq-msgrtr-02.pit.comms.marconi.com with Internet Mail Service (5.5.2650.21) id <46BVJRQ3>; Mon, 23 Oct 2000 15:17:03 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D25.D53309B0" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E880@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 23 Oct 2000 15:17:06 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Audit of packages X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03D25.D53309B0 Content-Type: text/plain; charset="iso-8859-1" We all agree about the requirement to support the properties, events, signals and statistics of the base package under the package name of the new package. What is unclear is what an implementation should do about the base package. Should it support the base package names also? The proposed text recommends that it SHOULD. Is that a problem? I think guidance is warranted. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Monday, October 23, 2000 1:43 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages I have a disagreement with the portion of text indicated below and suggest that it be dropped. The ambiguity is about names, not about implementation: the standard leaves no ambiguity about the requirement to support all of the base package. > -----Original Message----- > From: Christian Groves [ mailto:Christian.Groves@ERICSSON.COM ] > Sent: Monday, October 16, 2000 2:14 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > G'Day all, > > Below is the text which I propose to put into the implementor's guide. > Its a mix of Brian and Pete's proposed words. I note that I changed > Brian's MAY to Pete's SHOULD. > > 9.5 Package Extension and Referencing > > Description: The current text in H.248 Section 12.1 is > ambiguous about > the usage of package names when referencing properties, > events, signals > and statistics in a base package and an extended package. > Reference: Subject: Re: Audit of packages > Date: Fri, 13 Oct 2000 07:58:12 -0400 > From: "Rosen, Brian" > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: RE: Audit of packages > Date: Fri, 13 Oct 2000 15:15:14 -0500 > From: "Peter Blatherwick" > To: "'Christian Groves'" > CC: megaco@standards.nortelnetworks.com, "'Rosen, Brian'" > > > [Begin Clarification] > Section 12.1 > When packages are extended, the properties, events, signals and > statistics defined in the base package can be referred to using the > extended package name. For example, if Package A defines > event e1, and > Package B extends Package A, then B/e1 is an event for a termination > implementing Package B. [PTT] The MG SHOULD also "implement" the base > Package. If it does, then A would be reported on the Package > Descriptor > in AuditValue as well as B, and event A/e1 would be available on a > termination. If the MG does not implement A, then only B/e1 would be > available. If implemented, [PTT] > A/e1 and B/e1 are the same event. > An MG SHOULD publish all Packages supported by its Terminations, > including base Packages from which extended Packages are derived. An > exception to this is in cases where the base Packages are expressly > designed to be extended by others, not directly controlled, > and may not > have any function on their own or be nonsensical on their own. > [End Clarification] > > Any problems with the text? > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > We probably need some words in the Implementer's Guide, I agree. > > > > How about something like: > > When packages are extended, the properties, events, signals > and statistics > > defined in the base package can be referred to using the > extended package > > name. For example, if Package A defines event e1, and > Package B extends > > Package A, then B/e1 is an event for a termination > implementing Package B. > > The MG MAY also "implement" the base Package. If it does, > then A would > > be reported on the Package Descriptor in AuditValue as well > as B, and > > event A/e1 would be available on a termination. If the MG does not > > implement A, then only B/e1 would be available. Of course, > if implemented, > > A/e1 and B/e1 are the same event. > > > > Brian > > > > > -----Original Message----- > > > From: chassija@hss.hns.com [ mailto:chassija@hss.hns.com ] > > > Sent: Friday, October 13, 2000 12:29 AM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Hello Brian, > > > > > > If this is the case as you are pointing out, then it should > > > be clearly mentioned > > > in the protocol. Because the protocol says only the following > > > --- in context of > > > Package B extending Package A -- > > > > > > Sec 12.1.1 - " When a package > > > extends another package it shall only add additional > Properties, > > > Events, Signals, Statistics and new possible values for an > > > existing parameter described in the original > package. An extended > > > package shall not redefine or overload a name defined in the > > > original package." > > > > > > This seems to imply that Package B has to support all the > > > events supported on > > > Package A...... > > > > > > What is your opinion on this.... > > > Chanchal.... > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/13/2000 01:32:21 AM > > > > > > Please respond to "Rosen, Brian" > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > I don't think there is any change to the base understanding. > > > > > > Suppose Package A defines Event e1 > > > Suppose Package B extends Package A. > > > > > > Now, you can talk about A/e1 or B/e1. > > > > > > If you "expose" package A, then you would include A in the > > > list of packages reported on an audit, and A/e1 as well as B/e1 > > > would be legal. > > > > > > If you don't expose package A, then you can only use B/e1. > > > > > > In both cases the extended package inherits the behavior of the > > > base package. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [ mailto:samittal@HSS.HNS.COM ] > > > > Sent: Thursday, October 12, 2000 11:55 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Audit of packages > > > > > > > > > > > > The idea of supporting extending package but not supporting > > > > base package > > > > is not the basic philosophy of extension of packages > which says that > > > > extended package inherits the behaviour of base package. > > > > > > > > So do we need to change the basic understanding of package > > > extensions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > > > > > > > Please respond to Dave Sclarsky > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > > > > > > What do you think about the case where an MG can support pkg2 > > > > but NOT pkg3? > > > > > > > > Take the case of the Tone Detection Package and the DTMF > > > > Detection Package > > > > that extends it. There are most certainly 'intelligent' > > > > devices that are > > > > capable of reporting DTMF digits, but do not offer the > > > > granularity to report > > > > 'Start tone' or 'End tone' detected. > > > > > > > > I would have assumed that an MG with such a device would > > > > (should!) publish > > > > dd but not tonedet, because it really cannot notify > tonedet/std or > > > > tonedet/etd. > > > > > > > > DaveS. > > > > > > > > > > > > -----Original Message----- > > > > > From: Christian Groves [ mailto:Christian.Groves@ERICSSON.COM ] > > > > > Sent: Wednesday, October 11, 2000 10:25 PM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > > > > when it is > > > > > inappropriate and we have the rule saying that you can address > > > > > properties by pkg3. > > > > > > > > > > But, I'm happy with Should if you can provide the > text when it is > > > > > inappropriate. > > > > > > > > > > Cheers, Christian > > > > > > > > > > Peter Blatherwick wrote: > > > > -------------------------- > > > > > > > > > > I agree in general, since "extends" basically means > > > "clone the base > > > > > package and add some more functionality" (no subsetting, > > > over-riding > > > > > etc allowed). In example below pkg2 by definition > > > implements pkg3. > > > > > (Not the case with re-versioning of Packages though!) > > > > > > > > > > One clarification however. It does not always make sense > > > for a base > > > > > package to be published as implemented by an MG. There > > > are examples > > > > > where the base package is defined such that it acts > similar to a > > > > > virtual class, and has no function on its own, simply defining > > > > > interface for one or more derived packages. Annex E > ToneGen and > > > > > ToneDet as well as a few packages in Annex G are examples. > > > > Therefore, > > > > > implementer's guide MUST not make a hard and fast rule on > > > this, but > > > > > SHOULD say "SHOULD" with some words to describe where its > > > > > inappropriate. > > > > > > > > > > -- Peter > > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM ] > > > > > Sent: Monday, October 09, 2000 16:03 > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > We've been around this and basically, it is up to the MG. > > > > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > > > > is a good word, and I wonder if text to that effect > > > > > should go in the implementor's guide? > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Sachin Mittal [ mailto:samittal@HSS.HNS.COM ] > > > > > Sent: Monday, October 09, 2000 5:12 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Audit of packages > > > > > > > > > > Say a termination abc implements the following packages: > > > > > 1. pkg1 > > > > > 2. pkg2 > > > > > where pkg2 extends pkg3 and pkg1 doesn't extend any > other package > > > > > > > > > > If this termination is audited for packages implemented on it, > > > > > should the reply include pkg3 with pkg1 and pkg2 (base > > > package names > > > > > are included) > > > > > > > > > > Sachin > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C03D25.D53309B0 Content-Type: text/html; charset="iso-8859-1" RE: Audit of packages
We all agree about the requirement to support the properties, events, signals and
statistics of the base package under the package name of the new package.
 
What is unclear is what an implementation should do about the base package.
Should it support the base package names also?
The proposed text recommends that it SHOULD.  Is that a problem?
I think guidance is warranted.
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
Sent: Monday, October 23, 2000 1:43 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Audit of packages

I have a disagreement with the portion of text indicated below and suggest that it be dropped.  The ambiguity is about names, not about implementation: the standard leaves no ambiguity about the requirement to support all of the base package.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Monday, October 16, 2000 2:14 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Audit of packages
>
>
> G'Day all,
>
> Below is the text which I propose to put into the implementor's guide.
> Its a mix of Brian and Pete's proposed words. I note that I changed
> Brian's MAY to Pete's SHOULD.
>
> 9.5     Package Extension and Referencing
>
> Description:    The current text in H.248 Section 12.1 is
> ambiguous about
> the usage of package names when referencing properties,
> events, signals
> and statistics in a base package and an extended package.
> Reference:      Subject: Re: Audit of packages
> Date: Fri, 13 Oct 2000 07:58:12 -0400
> From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>
> Subject: RE: Audit of packages
> Date: Fri, 13 Oct 2000 15:15:14 -0500
> From: "Peter Blatherwick" <blather@nortelnetworks.com>
> To: "'Christian Groves'" <Christian.Groves@ericsson.com>
> CC: megaco@standards.nortelnetworks.com, "'Rosen, Brian'"
> <Brian.Rosen@MARCONI.COM>
>
> [Begin Clarification]
> Section 12.1
> When packages are extended, the properties, events, signals and
> statistics defined in the base package can be referred to using the
> extended package name.  For example, if Package A defines
> event e1, and
> Package B extends Package A, then B/e1 is an event for a termination
> implementing Package B.

[PTT] <begin text proposed to be omitted>
The MG SHOULD also "implement" the base
> Package.  If it does, then A would be reported on the Package
> Descriptor
> in AuditValue as well as B, and event A/e1 would be available on a
> termination.  If the MG does not implement A, then only B/e1 would be
> available.  If implemented,
[PTT] <end text proposed to be omitted>

> A/e1 and B/e1 are the same event.
> An MG SHOULD publish all Packages supported by its Terminations,
> including base Packages from which extended Packages are derived.  An
> exception to this is in cases where the base Packages are expressly
> designed to be extended by others, not directly controlled,
> and may not
> have any function on their own or be nonsensical on their own.
> [End Clarification]
>
> Any problems with the text?
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > We probably need some words in the Implementer's Guide, I agree.
> >
> > How about something like:
> > When packages are extended, the properties, events, signals
> and statistics
> > defined in the base package can be referred to using the
> extended package
> > name.  For example, if Package A defines event e1, and
> Package B extends
> > Package A, then B/e1 is an event for a termination
> implementing Package B.
> > The MG MAY also "implement" the base Package.  If it does,
> then A would
> > be reported on the Package Descriptor in AuditValue as well
> as B, and
> > event A/e1 would be available on a termination.  If the MG does not
> > implement A, then only B/e1 would be available.  Of course,
> if implemented,
> > A/e1 and B/e1 are the same event.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: chassija@hss.hns.com [mailto:chassija@hss.hns.com]
> > > Sent: Friday, October 13, 2000 12:29 AM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Audit of packages
> > >
> > >
> > >
> > >
> > > Hello Brian,
> > >
> > > If this is the case as you are pointing out, then it should
> > > be clearly mentioned
> > > in the protocol. Because the protocol says only the following
> > > --- in context of
> > > Package B extending Package A --
> > >
> > > Sec 12.1.1 - " When a package
> > >      extends another package it shall only add additional
> Properties,
> > >      Events, Signals, Statistics and new possible values for an
> > >      existing parameter described in the original
> package. An extended
> > >      package shall not redefine or overload a name defined in the
> > >      original package."
> > >
> > > This seems to imply that Package B has to support all the
> > > events supported on
> > > Package A......
> > >
> > > What is your opinion on this....
> > > Chanchal....
> > >
> > >
> > >
> > >
> > >
> > > "Rosen, Brian" <Brian.Rosen@MARCONI.COM> on 10/13/2000 01:32:21 AM
> > >
> > > Please respond to "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
> > >
> > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > cc:    (bcc: Chanchal Hassija/HSS)
> > >
> > > Subject:  Re: Audit of packages
> > >
> > >
> > >
> > >
> > > I don't think there is any change to the base understanding.
> > >
> > > Suppose Package A defines Event e1
> > > Suppose Package B extends Package A.
> > >
> > > Now, you can talk about A/e1 or B/e1.
> > >
> > > If you "expose" package A, then you would include A in the
> > > list of packages reported on an audit, and A/e1 as well as B/e1
> > > would be legal.
> > >
> > > If you don't expose package A, then you can only use B/e1.
> > >
> > > In both cases the extended package inherits the behavior of the
> > > base package.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> > > > Sent: Thursday, October 12, 2000 11:55 AM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Audit of packages
> > > >
> > > >
> > > > The idea of supporting extending package but not supporting
> > > > base package
> > > > is not the basic philosophy of extension of packages
> which says that
> > > > extended package inherits the behaviour of base package.
> > > >
> > > > So do we need to change the basic understanding of package
> > > extensions.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Dave Sclarsky <dsclarsky@SS7-LINK.COM> on 10/12/2000 07:44:17 PM
> > > >
> > > > Please respond to Dave Sclarsky <dsclarsky@SS7-LINK.COM>
> > > >
> > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > cc:    (bcc: Sachin Mittal/HSS)
> > > >
> > > > Subject:  Re: Audit of packages
> > > >
> > > >
> > > >
> > > >
> > > > What do you think about the case where an MG can support pkg2
> > > > but NOT pkg3?
> > > >
> > > > Take the case of the Tone Detection Package and the DTMF
> > > > Detection Package
> > > > that extends it.  There are most certainly 'intelligent'
> > > > devices that are
> > > > capable of reporting DTMF digits, but do not offer the
> > > > granularity to report
> > > > 'Start tone' or 'End tone' detected.
> > > >
> > > > I would have assumed that an MG with such a device would
> > > > (should!) publish
> > > > dd but not tonedet, because it really cannot notify
> tonedet/std or
> > > > tonedet/etd.
> > > >
> > > > DaveS.
> > > >
> > > >
> > > > -----Original Message-----
> > > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > > > Sent: Wednesday, October 11, 2000 10:25 PM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Audit of packages
> > > > >
> > > > >
> > > > > Perhaps we "should" say "SHALL", I can't think of a case of
> > > > when it is
> > > > > inappropriate and we have the rule saying that you can address
> > > > > properties by pkg3.
> > > > >
> > > > > But, I'm happy with Should if you can provide the
> text when it is
> > > > > inappropriate.
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > Peter Blatherwick wrote:
> > > > --------------------------
> > > > >
> > > > > I agree in general, since "extends" basically means
> > > "clone the base
> > > > > package and add some more functionality" (no subsetting,
> > > over-riding
> > > > > etc allowed).  In example below pkg2 by definition
> > > implements pkg3.
> > > > > (Not the case with re-versioning of Packages though!)
> > > > >
> > > > > One clarification however.  It does not always make sense
> > > for a base
> > > > > package to be published as implemented by an MG.  There
> > > are examples
> > > > > where the base package is defined such that it acts
> similar to a
> > > > > virtual class, and has no function on its own, simply defining
> > > > > interface for one or more derived packages.  Annex E
> ToneGen and
> > > > > ToneDet as well as a few packages in Annex G are examples.
> > > > Therefore,
> > > > > implementer's guide MUST not make a hard and fast rule on
> > > this, but
> > > > > SHOULD say "SHOULD" with some words to describe where its
> > > > > inappropriate.
> > > > >
> > > > > -- Peter
> > > > >
> > > > > -----Original Message-----
> > > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > > > > Sent: Monday, October 09, 2000 16:03
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Audit of packages
> > > > >
> > > > > We've been around this and basically, it is up to the MG.
> > > > > It does not HAVE to report pkg3, but it could.  Maybe SHOULD
> > > > > is a good word, and I wonder if text to that effect
> > > > > should go in the implementor's guide?
> > > > >
> > > > > Brian
> > > > >
> > > > > -----Original Message-----
> > > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> > > > > Sent: Monday, October 09, 2000 5:12 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Audit of packages
> > > > >
> > > > > Say a termination abc implements the following packages:
> > > > > 1. pkg1
> > > > > 2. pkg2
> > > > > where pkg2 extends pkg3 and pkg1 doesn't extend any
> other package
> > > > >
> > > > > If this termination is audited for packages implemented on it,
> > > > > should the reply include pkg3 with pkg1 and pkg2 (base
> > > package names
> > > > > are included)
> > > > >
> > > > > Sachin
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>

------_=_NextPart_001_01C03D25.D53309B0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 15:37:04 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA13737 for ; Mon, 23 Oct 2000 15:37:04 -0400 (EDT) Received: from standards (47.234.32.16:2124) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA97AD@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:20:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41820 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 15:20:10 -0400 Received: from slink12.ss7-link.com (mail.ss7-link.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA97AC@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:20:09 -0400 Received: by SLINK12 with Internet Mail Service (5.5.2650.21) id <4KWBW65G>; Mon, 23 Oct 2000 15:32:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Mon, 23 Oct 2000 15:32:53 -0400 Reply-To: Dave Sclarsky Sender: "Media Gateway Control (megaco)" From: Dave Sclarsky Subject: Re: Digitmap definition override X-cc: img To: MEGACO@STANDARDS.NORTELNETWORKS.COM I agree that the MGC should be able to override a provisioned digitmap, but it does raise some questions: 1. If an MGC overrides a management-provisioned Digitmap, which value should the MG be expected to use after a subsequent cold start (i.e. how long does the MGC definition persist)? 2. Also, what if a management action changes the value of a Digitmap after it was overridden by the MGC? What do you think? Dave Sclarsky, S-Link Corporation dsclarsky@ss7-link.com -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Monday, October 23, 2000 1:13 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Digitmap definition override > -----Original Message----- > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > Sent: Thursday, October 12, 2000 5:43 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Digitmap definition override > > > The text says that a digitmap once defined can be overriden with a new > definition. > But if the digitmap is defined by management action outside > the scope of MGC, > can MGC override that with a definition of it's own. > [PTT] I'd say this is permissible -- there may be circumstances where it is desirable to use this capability. > > Sachin > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 15:50:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id PAA15424 for ; Mon, 23 Oct 2000 15:50:02 -0400 (EDT) Received: from standards (47.234.32.16:2124) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA97C9@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:33:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41858 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 15:33:00 -0400 Received: from qhars002.nortel.com (47.101.112.102:55017) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA97C8@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:33:00 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Mon, 23 Oct 2000 20:48:11 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 23 Oct 2000 14:43:49 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Oct 2000 14:47:21 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C600@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 14:47:09 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Audit of packages X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Do we agree on this logic, which was behind my intervention? (1) An MG publishes the packages it is prepared to understand in incoming messages. (2) An MG does not publish packages which it is not prepared to understand in incoming messages. This is why I felt that the middle part of Christian's text was unnecessary -- the final two sentences already capture the intent. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Monday, October 23, 2000 3:17 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages We all agree about the requirement to support the properties, events, signals and statistics of the base package under the package name of the new package. What is unclear is what an implementation should do about the base package. Should it support the base package names also? The proposed text recommends that it SHOULD. Is that a problem? I think guidance is warranted. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Monday, October 23, 2000 1:43 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages I have a disagreement with the portion of text indicated below and suggest that it be dropped. The ambiguity is about names, not about implementation: the standard leaves no ambiguity about the requirement to support all of the base package. > -----Original Message----- > From: Christian Groves [ mailto:Christian.Groves@ERICSSON.COM ] > Sent: Monday, October 16, 2000 2:14 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > G'Day all, > > Below is the text which I propose to put into the implementor's guide. > Its a mix of Brian and Pete's proposed words. I note that I changed > Brian's MAY to Pete's SHOULD. > > 9.5 Package Extension and Referencing > > Description: The current text in H.248 Section 12.1 is > ambiguous about > the usage of package names when referencing properties, > events, signals > and statistics in a base package and an extended package. > Reference: Subject: Re: Audit of packages > Date: Fri, 13 Oct 2000 07:58:12 -0400 > From: "Rosen, Brian" > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: RE: Audit of packages > Date: Fri, 13 Oct 2000 15:15:14 -0500 > From: "Peter Blatherwick" > To: "'Christian Groves'" > CC: megaco@standards.nortelnetworks.com, "'Rosen, Brian'" > > > [Begin Clarification] > Section 12.1 > When packages are extended, the properties, events, signals and > statistics defined in the base package can be referred to using the > extended package name. For example, if Package A defines > event e1, and > Package B extends Package A, then B/e1 is an event for a termination > implementing Package B. [PTT] The MG SHOULD also "implement" the base > Package. If it does, then A would be reported on the Package > Descriptor > in AuditValue as well as B, and event A/e1 would be available on a > termination. If the MG does not implement A, then only B/e1 would be > available. If implemented, [PTT] > A/e1 and B/e1 are the same event. > An MG SHOULD publish all Packages supported by its Terminations, > including base Packages from which extended Packages are derived. An > exception to this is in cases where the base Packages are expressly > designed to be extended by others, not directly controlled, > and may not > have any function on their own or be nonsensical on their own. > [End Clarification] > > Any problems with the text? > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > We probably need some words in the Implementer's Guide, I agree. > > > > How about something like: > > When packages are extended, the properties, events, signals > and statistics > > defined in the base package can be referred to using the > extended package > > name. For example, if Package A defines event e1, and > Package B extends > > Package A, then B/e1 is an event for a termination > implementing Package B. > > The MG MAY also "implement" the base Package. If it does, > then A would > > be reported on the Package Descriptor in AuditValue as well > as B, and > > event A/e1 would be available on a termination. If the MG does not > > implement A, then only B/e1 would be available. Of course, > if implemented, > > A/e1 and B/e1 are the same event. > > > > Brian > > > > > -----Original Message----- > > > From: chassija@hss.hns.com [ mailto:chassija@hss.hns.com ] > > > Sent: Friday, October 13, 2000 12:29 AM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Hello Brian, > > > > > > If this is the case as you are pointing out, then it should > > > be clearly mentioned > > > in the protocol. Because the protocol says only the following > > > --- in context of > > > Package B extending Package A -- > > > > > > Sec 12.1.1 - " When a package > > > extends another package it shall only add additional > Properties, > > > Events, Signals, Statistics and new possible values for an > > > existing parameter described in the original > package. An extended > > > package shall not redefine or overload a name defined in the > > > original package." > > > > > > This seems to imply that Package B has to support all the > > > events supported on > > > Package A...... > > > > > > What is your opinion on this.... > > > Chanchal.... > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/13/2000 01:32:21 AM > > > > > > Please respond to "Rosen, Brian" > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > I don't think there is any change to the base understanding. > > > > > > Suppose Package A defines Event e1 > > > Suppose Package B extends Package A. > > > > > > Now, you can talk about A/e1 or B/e1. > > > > > > If you "expose" package A, then you would include A in the > > > list of packages reported on an audit, and A/e1 as well as B/e1 > > > would be legal. > > > > > > If you don't expose package A, then you can only use B/e1. > > > > > > In both cases the extended package inherits the behavior of the > > > base package. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [ mailto:samittal@HSS.HNS.COM ] > > > > Sent: Thursday, October 12, 2000 11:55 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Audit of packages > > > > > > > > > > > > The idea of supporting extending package but not supporting > > > > base package > > > > is not the basic philosophy of extension of packages > which says that > > > > extended package inherits the behaviour of base package. > > > > > > > > So do we need to change the basic understanding of package > > > extensions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > > > > > > > Please respond to Dave Sclarsky > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > > > > > > What do you think about the case where an MG can support pkg2 > > > > but NOT pkg3? > > > > > > > > Take the case of the Tone Detection Package and the DTMF > > > > Detection Package > > > > that extends it. There are most certainly 'intelligent' > > > > devices that are > > > > capable of reporting DTMF digits, but do not offer the > > > > granularity to report > > > > 'Start tone' or 'End tone' detected. > > > > > > > > I would have assumed that an MG with such a device would > > > > (should!) publish > > > > dd but not tonedet, because it really cannot notify > tonedet/std or > > > > tonedet/etd. > > > > > > > > DaveS. > > > > > > > > > > > > -----Original Message----- > > > > > From: Christian Groves [ mailto:Christian.Groves@ERICSSON.COM ] > > > > > Sent: Wednesday, October 11, 2000 10:25 PM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > > > > when it is > > > > > inappropriate and we have the rule saying that you can address > > > > > properties by pkg3. > > > > > > > > > > But, I'm happy with Should if you can provide the > text when it is > > > > > inappropriate. > > > > > > > > > > Cheers, Christian > > > > > > > > > > Peter Blatherwick wrote: > > > > -------------------------- > > > > > > > > > > I agree in general, since "extends" basically means > > > "clone the base > > > > > package and add some more functionality" (no subsetting, > > > over-riding > > > > > etc allowed). In example below pkg2 by definition > > > implements pkg3. > > > > > (Not the case with re-versioning of Packages though!) > > > > > > > > > > One clarification however. It does not always make sense > > > for a base > > > > > package to be published as implemented by an MG. There > > > are examples > > > > > where the base package is defined such that it acts > similar to a > > > > > virtual class, and has no function on its own, simply defining > > > > > interface for one or more derived packages. Annex E > ToneGen and > > > > > ToneDet as well as a few packages in Annex G are examples. > > > > Therefore, > > > > > implementer's guide MUST not make a hard and fast rule on > > > this, but > > > > > SHOULD say "SHOULD" with some words to describe where its > > > > > inappropriate. > > > > > > > > > > -- Peter > > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM ] > > > > > Sent: Monday, October 09, 2000 16:03 > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > We've been around this and basically, it is up to the MG. > > > > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > > > > is a good word, and I wonder if text to that effect > > > > > should go in the implementor's guide? > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Sachin Mittal [ mailto:samittal@HSS.HNS.COM ] > > > > > Sent: Monday, October 09, 2000 5:12 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Audit of packages > > > > > > > > > > Say a termination abc implements the following packages: > > > > > 1. pkg1 > > > > > 2. pkg2 > > > > > where pkg2 extends pkg3 and pkg1 doesn't extend any > other package > > > > > > > > > > If this termination is audited for packages implemented on it, > > > > > should the reply include pkg3 with pkg1 and pkg2 (base > > > package names > > > > > are included) > > > > > > > > > > Sachin > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 16:08:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17543 for ; Mon, 23 Oct 2000 16:08:29 -0400 (EDT) Received: from standards (47.234.32.16:2124) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA97E2@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:51:28 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41889 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 15:51:28 -0400 Received: from qhars002.nortel.com (47.101.112.102:55113) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA97E0@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:51:27 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Mon, 23 Oct 2000 21:06:21 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Mon, 23 Oct 2000 16:04:40 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRFL5Z>; Mon, 23 Oct 2000 16:04:38 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD110250C601@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 16:04:35 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Digitmap definition override X-To: Dave Sclarsky To: MEGACO@STANDARDS.NORTELNETWORKS.COM In considering your questions, note that when terminations are moved back to the NULL context, their properties take on default values, which may be provisioned (section 6.2.4). Hence any MGC overriding of digit map values other than those defined on ROOT is temporary. I would assume by definition that a cold start reestablishes default values on ROOT and on all persistent terminations. As for your second question: does provisioning change default values only, or can it change current property values for a termination as well? Opinions? > -----Original Message----- > From: Dave Sclarsky [mailto:dsclarsky@SS7-LINK.COM] > Sent: Monday, October 23, 2000 3:33 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Digitmap definition override > > > I agree that the MGC should be able to override a > provisioned digitmap, but it does raise some questions: > > 1. If an MGC overrides a management-provisioned Digitmap, > which value should the MG be expected to use after a > subsequent cold start (i.e. how long does the MGC > definition persist)? > > 2. Also, what if a management action changes the value of > a Digitmap after it was overridden by the MGC? > > What do you think? > > Dave Sclarsky, S-Link Corporation > dsclarsky@ss7-link.com > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Monday, October 23, 2000 1:13 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Digitmap definition override > > > > -----Original Message----- > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > Sent: Thursday, October 12, 2000 5:43 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Digitmap definition override > > > > > > The text says that a digitmap once defined can be overriden > with a new > > definition. > > But if the digitmap is defined by management action outside > > the scope of MGC, > > can MGC override that with a definition of it's own. > > > > [PTT] I'd say this is permissible -- there may be > circumstances where it is > desirable to use this capability. > > > > > Sachin > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 16:08:32 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA17552 for ; Mon, 23 Oct 2000 16:08:30 -0400 (EDT) Received: from standards (47.234.32.16:2124) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA97ED@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:52:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41905 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 15:52:00 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA97EC@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:51:59 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA28591; Mon, 23 Oct 2000 16:07:23 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA15798; Mon, 23 Oct 2000 16:07:24 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRT9AT>; Mon, 23 Oct 2000 16:07:07 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D2C.DB0FE040" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E882@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 23 Oct 2000 16:07:22 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Audit of packages X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03D2C.DB0FE040 Content-Type: text/plain; charset="iso-8859-1" The problem is that an implementer reading the text does not know if he should, or should not, implement the base package under the base package name. Whichever decision he makes, the text is clear on what he should do. The question is should the implementer's guide offer advice on whether the base package should be implemented. Christian suggested that it should, further suggested that the advice should be that the implementer SHOULD (not SHALL) implement the base package, and I agreed with him. I actually had suggested MAY, which I'm still okay with. It seems wrong to make it MUST or SHALL NOT. Whichever way we agree on, I want the text to say something on whether the base package should be implemented. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Monday, October 23, 2000 3:47 PM To: Rosen, Brian; megaco@standards.nortelnetworks.com Subject: RE: Audit of packages Do we agree on this logic, which was behind my intervention? (1) An MG publishes the packages it is prepared to understand in incoming messages. (2) An MG does not publish packages which it is not prepared to understand in incoming messages. This is why I felt that the middle part of Christian's text was unnecessary -- the final two sentences already capture the intent. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Monday, October 23, 2000 3:17 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages We all agree about the requirement to support the properties, events, signals and statistics of the base package under the package name of the new package. What is unclear is what an implementation should do about the base package. Should it support the base package names also? The proposed text recommends that it SHOULD. Is that a problem? I think guidance is warranted. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Monday, October 23, 2000 1:43 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages I have a disagreement with the portion of text indicated below and suggest that it be dropped. The ambiguity is about names, not about implementation: the standard leaves no ambiguity about the requirement to support all of the base package. > -----Original Message----- > From: Christian Groves [ mailto:Christian.Groves@ERICSSON.COM ] > Sent: Monday, October 16, 2000 2:14 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > G'Day all, > > Below is the text which I propose to put into the implementor's guide. > Its a mix of Brian and Pete's proposed words. I note that I changed > Brian's MAY to Pete's SHOULD. > > 9.5 Package Extension and Referencing > > Description: The current text in H.248 Section 12.1 is > ambiguous about > the usage of package names when referencing properties, > events, signals > and statistics in a base package and an extended package. > Reference: Subject: Re: Audit of packages > Date: Fri, 13 Oct 2000 07:58:12 -0400 > From: "Rosen, Brian" > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: RE: Audit of packages > Date: Fri, 13 Oct 2000 15:15:14 -0500 > From: "Peter Blatherwick" > To: "'Christian Groves'" > CC: megaco@standards.nortelnetworks.com, "'Rosen, Brian'" > > > [Begin Clarification] > Section 12.1 > When packages are extended, the properties, events, signals and > statistics defined in the base package can be referred to using the > extended package name. For example, if Package A defines > event e1, and > Package B extends Package A, then B/e1 is an event for a termination > implementing Package B. [PTT] The MG SHOULD also "implement" the base > Package. If it does, then A would be reported on the Package > Descriptor > in AuditValue as well as B, and event A/e1 would be available on a > termination. If the MG does not implement A, then only B/e1 would be > available. If implemented, [PTT] > A/e1 and B/e1 are the same event. > An MG SHOULD publish all Packages supported by its Terminations, > including base Packages from which extended Packages are derived. An > exception to this is in cases where the base Packages are expressly > designed to be extended by others, not directly controlled, > and may not > have any function on their own or be nonsensical on their own. > [End Clarification] > > Any problems with the text? > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > We probably need some words in the Implementer's Guide, I agree. > > > > How about something like: > > When packages are extended, the properties, events, signals > and statistics > > defined in the base package can be referred to using the > extended package > > name. For example, if Package A defines event e1, and > Package B extends > > Package A, then B/e1 is an event for a termination > implementing Package B. > > The MG MAY also "implement" the base Package. If it does, > then A would > > be reported on the Package Descriptor in AuditValue as well > as B, and > > event A/e1 would be available on a termination. If the MG does not > > implement A, then only B/e1 would be available. Of course, > if implemented, > > A/e1 and B/e1 are the same event. > > > > Brian > > > > > -----Original Message----- > > > From: chassija@hss.hns.com [ mailto:chassija@hss.hns.com ] > > > Sent: Friday, October 13, 2000 12:29 AM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Hello Brian, > > > > > > If this is the case as you are pointing out, then it should > > > be clearly mentioned > > > in the protocol. Because the protocol says only the following > > > --- in context of > > > Package B extending Package A -- > > > > > > Sec 12.1.1 - " When a package > > > extends another package it shall only add additional > Properties, > > > Events, Signals, Statistics and new possible values for an > > > existing parameter described in the original > package. An extended > > > package shall not redefine or overload a name defined in the > > > original package." > > > > > > This seems to imply that Package B has to support all the > > > events supported on > > > Package A...... > > > > > > What is your opinion on this.... > > > Chanchal.... > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/13/2000 01:32:21 AM > > > > > > Please respond to "Rosen, Brian" > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > I don't think there is any change to the base understanding. > > > > > > Suppose Package A defines Event e1 > > > Suppose Package B extends Package A. > > > > > > Now, you can talk about A/e1 or B/e1. > > > > > > If you "expose" package A, then you would include A in the > > > list of packages reported on an audit, and A/e1 as well as B/e1 > > > would be legal. > > > > > > If you don't expose package A, then you can only use B/e1. > > > > > > In both cases the extended package inherits the behavior of the > > > base package. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [ mailto:samittal@HSS.HNS.COM ] > > > > Sent: Thursday, October 12, 2000 11:55 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Audit of packages > > > > > > > > > > > > The idea of supporting extending package but not supporting > > > > base package > > > > is not the basic philosophy of extension of packages > which says that > > > > extended package inherits the behaviour of base package. > > > > > > > > So do we need to change the basic understanding of package > > > extensions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > > > > > > > Please respond to Dave Sclarsky > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > > > > > > What do you think about the case where an MG can support pkg2 > > > > but NOT pkg3? > > > > > > > > Take the case of the Tone Detection Package and the DTMF > > > > Detection Package > > > > that extends it. There are most certainly 'intelligent' > > > > devices that are > > > > capable of reporting DTMF digits, but do not offer the > > > > granularity to report > > > > 'Start tone' or 'End tone' detected. > > > > > > > > I would have assumed that an MG with such a device would > > > > (should!) publish > > > > dd but not tonedet, because it really cannot notify > tonedet/std or > > > > tonedet/etd. > > > > > > > > DaveS. > > > > > > > > > > > > -----Original Message----- > > > > > From: Christian Groves [ mailto:Christian.Groves@ERICSSON.COM ] > > > > > Sent: Wednesday, October 11, 2000 10:25 PM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > > > > when it is > > > > > inappropriate and we have the rule saying that you can address > > > > > properties by pkg3. > > > > > > > > > > But, I'm happy with Should if you can provide the > text when it is > > > > > inappropriate. > > > > > > > > > > Cheers, Christian > > > > > > > > > > Peter Blatherwick wrote: > > > > -------------------------- > > > > > > > > > > I agree in general, since "extends" basically means > > > "clone the base > > > > > package and add some more functionality" (no subsetting, > > > over-riding > > > > > etc allowed). In example below pkg2 by definition > > > implements pkg3. > > > > > (Not the case with re-versioning of Packages though!) > > > > > > > > > > One clarification however. It does not always make sense > > > for a base > > > > > package to be published as implemented by an MG. There > > > are examples > > > > > where the base package is defined such that it acts > similar to a > > > > > virtual class, and has no function on its own, simply defining > > > > > interface for one or more derived packages. Annex E > ToneGen and > > > > > ToneDet as well as a few packages in Annex G are examples. > > > > Therefore, > > > > > implementer's guide MUST not make a hard and fast rule on > > > this, but > > > > > SHOULD say "SHOULD" with some words to describe where its > > > > > inappropriate. > > > > > > > > > > -- Peter > > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM ] > > > > > Sent: Monday, October 09, 2000 16:03 > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > We've been around this and basically, it is up to the MG. > > > > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > > > > is a good word, and I wonder if text to that effect > > > > > should go in the implementor's guide? > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Sachin Mittal [ mailto:samittal@HSS.HNS.COM ] > > > > > Sent: Monday, October 09, 2000 5:12 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Audit of packages > > > > > > > > > > Say a termination abc implements the following packages: > > > > > 1. pkg1 > > > > > 2. pkg2 > > > > > where pkg2 extends pkg3 and pkg1 doesn't extend any > other package > > > > > > > > > > If this termination is audited for packages implemented on it, > > > > > should the reply include pkg3 with pkg1 and pkg2 (base > > > package names > > > > > are included) > > > > > > > > > > Sachin > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C03D2C.DB0FE040 Content-Type: text/html; charset="iso-8859-1" RE: Audit of packages
The problem is that an implementer reading the text does not know if he should,
or should not, implement the base package under the base package name. 
Whichever decision he makes, the text is clear on what he should do. 
The question is should the implementer's guide offer advice on whether the
base package should be implemented.
 
Christian suggested that it should, further suggested that the advice should be
that the implementer SHOULD (not SHALL) implement the base package, and
I agreed with him.  I actually had suggested MAY, which I'm still okay with.
It seems wrong to make it MUST or SHALL NOT.  Whichever way we agree on,
I want the text to say something on whether the base package should be
implemented.
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, October 23, 2000 3:47 PM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: Audit of packages

Do we agree on this logic, which was behind my intervention?
  (1) An MG publishes the packages it is prepared to understand in incoming messages.
  (2) An MG does not publish packages which it is not prepared to understand in incoming messages.
 
This is why I felt that the middle part of Christian's text was unnecessary -- the final two sentences already capture the intent.
 
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Monday, October 23, 2000 3:17 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Audit of packages

We all agree about the requirement to support the properties, events, signals and
statistics of the base package under the package name of the new package.
 
What is unclear is what an implementation should do about the base package.
Should it support the base package names also?
The proposed text recommends that it SHOULD.  Is that a problem?
I think guidance is warranted.
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
Sent: Monday, October 23, 2000 1:43 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Audit of packages

I have a disagreement with the portion of text indicated below and suggest that it be dropped.  The ambiguity is about names, not about implementation: the standard leaves no ambiguity about the requirement to support all of the base package.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Monday, October 16, 2000 2:14 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Audit of packages
>
>
> G'Day all,
>
> Below is the text which I propose to put into the implementor's guide.
> Its a mix of Brian and Pete's proposed words. I note that I changed
> Brian's MAY to Pete's SHOULD.
>
> 9.5     Package Extension and Referencing
>
> Description:    The current text in H.248 Section 12.1 is
> ambiguous about
> the usage of package names when referencing properties,
> events, signals
> and statistics in a base package and an extended package.
> Reference:      Subject: Re: Audit of packages
> Date: Fri, 13 Oct 2000 07:58:12 -0400
> From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>
> Subject: RE: Audit of packages
> Date: Fri, 13 Oct 2000 15:15:14 -0500
> From: "Peter Blatherwick" <blather@nortelnetworks.com>
> To: "'Christian Groves'" <Christian.Groves@ericsson.com>
> CC: megaco@standards.nortelnetworks.com, "'Rosen, Brian'"
> <Brian.Rosen@MARCONI.COM>
>
> [Begin Clarification]
> Section 12.1
> When packages are extended, the properties, events, signals and
> statistics defined in the base package can be referred to using the
> extended package name.  For example, if Package A defines
> event e1, and
> Package B extends Package A, then B/e1 is an event for a termination
> implementing Package B.

[PTT] <begin text proposed to be omitted>
The MG SHOULD also "implement" the base
> Package.  If it does, then A would be reported on the Package
> Descriptor
> in AuditValue as well as B, and event A/e1 would be available on a
> termination.  If the MG does not implement A, then only B/e1 would be
> available.  If implemented,
[PTT] <end text proposed to be omitted>

> A/e1 and B/e1 are the same event.
> An MG SHOULD publish all Packages supported by its Terminations,
> including base Packages from which extended Packages are derived.  An
> exception to this is in cases where the base Packages are expressly
> designed to be extended by others, not directly controlled,
> and may not
> have any function on their own or be nonsensical on their own.
> [End Clarification]
>
> Any problems with the text?
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > We probably need some words in the Implementer's Guide, I agree.
> >
> > How about something like:
> > When packages are extended, the properties, events, signals
> and statistics
> > defined in the base package can be referred to using the
> extended package
> > name.  For example, if Package A defines event e1, and
> Package B extends
> > Package A, then B/e1 is an event for a termination
> implementing Package B.
> > The MG MAY also "implement" the base Package.  If it does,
> then A would
> > be reported on the Package Descriptor in AuditValue as well
> as B, and
> > event A/e1 would be available on a termination.  If the MG does not
> > implement A, then only B/e1 would be available.  Of course,
> if implemented,
> > A/e1 and B/e1 are the same event.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: chassija@hss.hns.com [mailto:chassija@hss.hns.com]
> > > Sent: Friday, October 13, 2000 12:29 AM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Audit of packages
> > >
> > >
> > >
> > >
> > > Hello Brian,
> > >
> > > If this is the case as you are pointing out, then it should
> > > be clearly mentioned
> > > in the protocol. Because the protocol says only the following
> > > --- in context of
> > > Package B extending Package A --
> > >
> > > Sec 12.1.1 - " When a package
> > >      extends another package it shall only add additional
> Properties,
> > >      Events, Signals, Statistics and new possible values for an
> > >      existing parameter described in the original
> package. An extended
> > >      package shall not redefine or overload a name defined in the
> > >      original package."
> > >
> > > This seems to imply that Package B has to support all the
> > > events supported on
> > > Package A......
> > >
> > > What is your opinion on this....
> > > Chanchal....
> > >
> > >
> > >
> > >
> > >
> > > "Rosen, Brian" <Brian.Rosen@MARCONI.COM> on 10/13/2000 01:32:21 AM
> > >
> > > Please respond to "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
> > >
> > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > cc:    (bcc: Chanchal Hassija/HSS)
> > >
> > > Subject:  Re: Audit of packages
> > >
> > >
> > >
> > >
> > > I don't think there is any change to the base understanding.
> > >
> > > Suppose Package A defines Event e1
> > > Suppose Package B extends Package A.
> > >
> > > Now, you can talk about A/e1 or B/e1.
> > >
> > > If you "expose" package A, then you would include A in the
> > > list of packages reported on an audit, and A/e1 as well as B/e1
> > > would be legal.
> > >
> > > If you don't expose package A, then you can only use B/e1.
> > >
> > > In both cases the extended package inherits the behavior of the
> > > base package.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> > > > Sent: Thursday, October 12, 2000 11:55 AM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Audit of packages
> > > >
> > > >
> > > > The idea of supporting extending package but not supporting
> > > > base package
> > > > is not the basic philosophy of extension of packages
> which says that
> > > > extended package inherits the behaviour of base package.
> > > >
> > > > So do we need to change the basic understanding of package
> > > extensions.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Dave Sclarsky <dsclarsky@SS7-LINK.COM> on 10/12/2000 07:44:17 PM
> > > >
> > > > Please respond to Dave Sclarsky <dsclarsky@SS7-LINK.COM>
> > > >
> > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > cc:    (bcc: Sachin Mittal/HSS)
> > > >
> > > > Subject:  Re: Audit of packages
> > > >
> > > >
> > > >
> > > >
> > > > What do you think about the case where an MG can support pkg2
> > > > but NOT pkg3?
> > > >
> > > > Take the case of the Tone Detection Package and the DTMF
> > > > Detection Package
> > > > that extends it.  There are most certainly 'intelligent'
> > > > devices that are
> > > > capable of reporting DTMF digits, but do not offer the
> > > > granularity to report
> > > > 'Start tone' or 'End tone' detected.
> > > >
> > > > I would have assumed that an MG with such a device would
> > > > (should!) publish
> > > > dd but not tonedet, because it really cannot notify
> tonedet/std or
> > > > tonedet/etd.
> > > >
> > > > DaveS.
> > > >
> > > >
> > > > -----Original Message-----
> > > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > > > Sent: Wednesday, October 11, 2000 10:25 PM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Audit of packages
> > > > >
> > > > >
> > > > > Perhaps we "should" say "SHALL", I can't think of a case of
> > > > when it is
> > > > > inappropriate and we have the rule saying that you can address
> > > > > properties by pkg3.
> > > > >
> > > > > But, I'm happy with Should if you can provide the
> text when it is
> > > > > inappropriate.
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > Peter Blatherwick wrote:
> > > > --------------------------
> > > > >
> > > > > I agree in general, since "extends" basically means
> > > "clone the base
> > > > > package and add some more functionality" (no subsetting,
> > > over-riding
> > > > > etc allowed).  In example below pkg2 by definition
> > > implements pkg3.
> > > > > (Not the case with re-versioning of Packages though!)
> > > > >
> > > > > One clarification however.  It does not always make sense
> > > for a base
> > > > > package to be published as implemented by an MG.  There
> > > are examples
> > > > > where the base package is defined such that it acts
> similar to a
> > > > > virtual class, and has no function on its own, simply defining
> > > > > interface for one or more derived packages.  Annex E
> ToneGen and
> > > > > ToneDet as well as a few packages in Annex G are examples.
> > > > Therefore,
> > > > > implementer's guide MUST not make a hard and fast rule on
> > > this, but
> > > > > SHOULD say "SHOULD" with some words to describe where its
> > > > > inappropriate.
> > > > >
> > > > > -- Peter
> > > > >
> > > > > -----Original Message-----
> > > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > > > > Sent: Monday, October 09, 2000 16:03
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Audit of packages
> > > > >
> > > > > We've been around this and basically, it is up to the MG.
> > > > > It does not HAVE to report pkg3, but it could.  Maybe SHOULD
> > > > > is a good word, and I wonder if text to that effect
> > > > > should go in the implementor's guide?
> > > > >
> > > > > Brian
> > > > >
> > > > > -----Original Message-----
> > > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> > > > > Sent: Monday, October 09, 2000 5:12 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Audit of packages
> > > > >
> > > > > Say a termination abc implements the following packages:
> > > > > 1. pkg1
> > > > > 2. pkg2
> > > > > where pkg2 extends pkg3 and pkg1 doesn't extend any
> other package
> > > > >
> > > > > If this termination is audited for packages implemented on it,
> > > > > should the reply include pkg3 with pkg1 and pkg2 (base
> > > package names
> > > > > are included)
> > > > >
> > > > > Sachin
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>

------_=_NextPart_001_01C03D2C.DB0FE040-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 16:12:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18095 for ; Mon, 23 Oct 2000 16:12:58 -0400 (EDT) Received: from standards (47.234.32.16:2124) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9811@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:54:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41953 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 15:54:33 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9810@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:54:33 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA28873; Mon, 23 Oct 2000 16:09:57 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id QAA16475; Mon, 23 Oct 2000 16:09:55 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CRT9DD>; Mon, 23 Oct 2000 16:09:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E883@whq-msgusr-02.pit.comms.marconi.com> Date: Mon, 23 Oct 2000 16:09:52 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Digitmap definition override X-To: Dave Sclarsky To: MEGACO@STANDARDS.NORTELNETWORKS.COM > I agree that the MGC should be able to override a > provisioned digitmap, but it does raise some questions: > > 1. If an MGC overrides a management-provisioned Digitmap, > which value should the MG be expected to use after a > subsequent cold start (i.e. how long does the MGC > definition persist)? The provisioned value > > 2. Also, what if a management action changes the value of > a Digitmap after it was overridden by the MGC? The provisioned value, the NEXT time the digitmap is used, i.e. it behaves like the text describes for a new value of an existing, in-use digitmap. If the management system does this, it does so under peril that the MGC may not understand what has happened. Brian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 16:13:00 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA18105 for ; Mon, 23 Oct 2000 16:12:59 -0400 (EDT) Received: from standards (47.234.32.16:2124) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA981E@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:56:33 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 41969 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 15:56:32 -0400 Received: from qhars002.nortel.com (47.101.112.102:55135) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA981D@standards.nortelnetworks.com>; Mon, 23 Oct 2000 15:56:32 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Mon, 23 Oct 2000 21:11:42 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 23 Oct 2000 15:02:08 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Oct 2000 15:06:09 -0500 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C602@zcard00g.ca.nortel.com> Date: Mon, 23 Oct 2000 15:06:08 -0500 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt X-To: Bob Lukas To: MEGACO@STANDARDS.NORTELNETWORKS.COM States should be captured in properties. Would it make sense to add the requisite properties to Annex G? -----Original Message----- From: Bob Lukas [mailto:blukas@BROADCOM.COM] Sent: Friday, October 13, 2000 12:35 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt Peter, I have been considering your comments and hoping for additional feedback from MGC vendors. I agree my issues are not really specific to the ipphone draft, but with the Annex G packages used by the IPPhone profile. And I concede that most things work fine for MGCs that want "raw" event reporting, ie. not using digitmaps or event descriptors for filtering. It would be useful for an MGC vendor that is planning to support IP Phones to express an opinion here. Maybe these are issues for the implementors guide or for version 2 update of Megaco annexes. One issue that I am stuck on, however, is that I can't find a way to audit the current value of the hookswitch (or any persistent-state key, for that matter). Even if the MGC is hot-standby/auto-failover, there will be times where it is conceivable that the current state of a particular IP Phone will be unknown. e.g. powering up a phone while the handset is knocked off the cradle. I would like to be able to apply off-hook warning tone in this case. Relying on user-behaviour to jiggle the hookswitch a few times, or have the phone possibly ring while off-hook is not optimal. You make reference to having the Phone generate immediate events for each key on event descriptor download - I'm not aware how to make the phone do that w.r.t. the key package. On the issue of multiple terminations, I absolutely agree that it is a good architecture to separate the terminations. But until we can find a way to allow reflex operations between terminations, we will have to admit that we either avoid reflex operations or make the device have some implicit knowledge of local interactions. -----Original Message----- From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM] Sent: Thursday, October 05, 2000 10:23 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt Bob: I believe your comments below do not actually affect the Megaco IP Phone draft itself. However, I agree with some of the issues you raise. Since the Megaco IP Phone draft is currently in last call, its important to identify where the issues reside. See [pb] comments below. -- Peter Blatherwick -----Original Message----- From: Bob Lukas [ mailto:blukas@BROADCOM.COM ] Sent: Thursday, October 05, 2000 01:10 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Issues with draft-ietf-megaco-ipphone-03.txt We've been looking at implementing draft-ietf-megaco-ipphone-03.txt and a few thorny issues have come up that I haven't seen discussed. Keypad and hookswitch are extensions of the basic annex G key package in the UI termination - this means: [pb] A quick clarification: all the UI packages used by IP Phone are Annex G packages, no extensions to Annex G are proposed. Your statement above is correct, but wanted to make sure all understood it. 1. There is no "current state" property value of these switches, only keyup and keydown events that are generated. e.g. the event reported is key/ku{keyid=kh} for an off-hook event. Not normally an issue for momentary push-buttons, but it means an MGC cannot audit for whether the phone is currently off-hook. Kind of a problem for an MGC that is trying to recover state at startup... [pb} True, there is no current state property. I like the general approach you suggest below to time 0 state problem. I personally think the MGC side of things must be responsible for recovering state if their is a failure cut-over (not sure if that's the scenario you are concerned about) since there's a heck of a lot more than hookswitch state involved in call state. At device startup, the worst that can happen is the user will get bored and hang up, generating the event anyway. [pb] Since this is a limitation of what is specified in Annex G, this does not directly affect the Megaco IP Phone draft. I don't think this is serious though. 2. At times, I'm only interested in events from a subset of the possible keys. How can I set an event descriptor to only monitor hookswitch (for example), and not random other button presses? Is this syntax legal? ...modify = ui { events =1 { key/ku { keyid = kh }, key/kd { keyid = f001} } If it was, it would help overcome the audit issue, by getting an immediate event if currently off-hook. [pb] I like it, even though I personally favour the all events on all the time approach. But I am personally unclear if this syntax is valid or not (its been a while). Unless someone on the list can clarify, I'll look into it. Even if suggested syntax is not valid, immediate Events could be returned indicating key states at the time the EventsDescriptor is received at the MG. [pb] This is an issue related to Megaco/H.248 Protocol overall, not specifically Megaco IP Phone. Useful for Implementer's Guide? 3. The audio transducers are separate terminations from the UI. This has great impact on wanting to automatically stop call progress tones immediately when keys are pressed. As far as I understand, an event occurring in one termination must not affect the signals active in another termination (which would be a huge problem for a multiple line device for example). For example, I cannot have dialtone automatically stop when I press a key - the MGC must send down a signal to explicitly stop it. Even worse, if I choose to implement a digitmap on my keypad, the MGC has no way of knowing when to stop dialtone, because it gets no event until after the entire dial string is entered. Saying the IP Phone should know and understand the implicit interactions between the terminations is also problematic and against the general Megaco philosophy of centralized control. [pb] The issue of Termination organization has been picked apart at length several times before, resulting in the current organization. While I certainly understand there is a tradeoff around causing reflex actions to occur as a result of Events, grouping of all termination functionality into a single termination (the implied solution) would result in drastically reduced flexibility for the model overall, and make several powerful applications non-intuitive at best. For example, applications like group listening (talker on a handset while others listen on handsfree) require individual control over the audio input/outputs, hence separate Transducer Terminations to allow them to be freely manipulated. Paging while on a call, IP-radio and several other applications would also be awkward without separate terminations. Since the MGC can control everything, albeit with some extra load, the flexible model is favoured, with the intent to open up new applications well beyond what "phones" can do today. [pb] I strongly agree with you statement that MGs should have no knowledge of call-related interactions (or any other application-level knowledge for that matter), and it would indeed break the Megaco/H.248 master/slave model. I think we all agree we don't go there. [pb] Since this topic has been visited several times, and good agreement achieved that this flexibility is important, I would not favour opening the issues again. I believe the general issue of inter-termination interaction may be a useful area for work in future versions of Megaco/H.248, as I can see several other example where it might be helpful. -- PB _____________________________________________________ Bob Lukas Broadcom Canada Richmond B.C. blukas@broadcom.com 604-233-8665 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 16:33:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id QAA20579 for ; Mon, 23 Oct 2000 16:33:58 -0400 (EDT) Received: from standards (47.234.32.16:3611) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9850@standards.nortelnetworks.com>; Mon, 23 Oct 2000 16:17:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42039 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 16:17:08 -0400 Received: from qhars002.nortel.com (47.101.112.102:57783) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA984F@standards.nortelnetworks.com>; Mon, 23 Oct 2000 16:17:08 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Mon, 23 Oct 2000 21:30:41 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 23 Oct 2000 15:26:13 -0500 Received: from zrtpd00x.us.nortel.com ([47.140.202.32]) by zrchb213.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VHCDGWFH; Mon, 23 Oct 2000 15:30:12 -0500 Received: from americasm01.nt.com (brtphe34.us.nortel.com [47.202.35.89]) by zrtpd00x.us.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2652.39) id VLDJ0SW8; Mon, 23 Oct 2000 16:30:09 -0400 X-Mailer: Mozilla 4.75 [en] (X11; U; HP-UX B.10.20 9000/778) X-Accept-Language: en MIME-Version: 1.0 References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Orig: Message-ID: <39F49FD3.2297FFA9@americasm01.nt.com> Date: Mon, 23 Oct 2000 16:30:12 -0400 Reply-To: Kevin Boyle Sender: "Media Gateway Control (megaco)" From: Kevin Boyle Organization: Nortel Networks Subject: Re: Digitmap definition override X-To: Dave Sclarsky To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Responses inline. [KJBII] Kevin Dave Sclarsky wrote: > I agree that the MGC should be able to override a > provisioned digitmap, but it does raise some questions: > > 1. If an MGC overrides a management-provisioned Digitmap, > which value should the MG be expected to use after a > subsequent cold start (i.e. how long does the MGC > definition persist)? > [KJBII] A cold start implies loss of state information, which, I would postulate, includes digitmap definitions. > > 2. Also, what if a management action changes the value of > a Digitmap after it was overridden by the MGC? > [KJBII] Unless the management action updates the MGC as well, this is asking for trouble. I would say management action on the MG takes effect only after a cold start, unless that action updates BOTH the MGC and the MG. If not, there will have to be audits kicked off in the MGC anytime there are management updates to keep the two synched. > > What do you think? > > Dave Sclarsky, S-Link Corporation > dsclarsky@ss7-link.com > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > Sent: Monday, October 23, 2000 1:13 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Digitmap definition override > > > -----Original Message----- > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > Sent: Thursday, October 12, 2000 5:43 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Digitmap definition override > > > > > > The text says that a digitmap once defined can be overriden with a new > > definition. > > But if the digitmap is defined by management action outside > > the scope of MGC, > > can MGC override that with a definition of it's own. > > > > [PTT] I'd say this is permissible -- there may be circumstances where it is > desirable to use this capability. > > > > > Sachin > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 17:48:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA29228 for ; Mon, 23 Oct 2000 17:48:54 -0400 (EDT) Received: from standards (47.234.32.16:3611) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA98CB@standards.nortelnetworks.com>; Mon, 23 Oct 2000 17:31:44 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42206 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 17:31:44 -0400 Received: from qhars002.nortel.com (47.101.112.102:37283) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA98CA@standards.nortelnetworks.com>; Mon, 23 Oct 2000 17:31:43 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Mon, 23 Oct 2000 22:45:48 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 23 Oct 2000 16:40:54 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Oct 2000 16:44:55 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D3A.7A4084A0" X-Orig: Message-ID: <353093573B82D411889E0000F808216648E420@zcard00q.ca.nortel.com> Date: Mon, 23 Oct 2000 16:44:53 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03D3A.7A4084A0 Content-Type: text/plain; charset="iso-8859-1" Yes, handling states this way would work. However, I think it would be more consistent and useful to handle *all* such state-related event reporting by defining a convention at the protocol level. Such a convention would behave in the same way as currently documented for strict="state" reporting mode in Analog Line Supervision Package, onhook and offhook event. This reports the current state of the termination if it is already in the requested state when the EventsDescriptor arrives. This would be simple and direct, generally applicable, and would not require any additional Audit steps. (Actually, I thought there were already words in the protocol document that described this, but darn if I can find them now.) I am not anxious to update Annex G for something that is of potential interest in many places (would want to update other existing packages for consistency, and remember and define statefullness handling in all future packages which behave this way). Note that the default for the strict= parameter in the AL package is also not defined, so a convention would remove ambiguity there, and that AL does not define properties as you suggest either, so there would be inconsistency. Personally I think a note in the Implementer's Guide on stateful reporting convention, covering all state reporting, would be the way to go for this. -- Peter -----Original Message----- From: Taylor, Tom-PT [NORSE:B901:EXCH] Sent: Monday, October 23, 2000 16:06 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt States should be captured in properties. Would it make sense to add the requisite properties to Annex G? -----Original Message----- From: Bob Lukas [mailto:blukas@BROADCOM.COM] Sent: Friday, October 13, 2000 12:35 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt Peter, I have been considering your comments and hoping for additional feedback from MGC vendors. I agree my issues are not really specific to the ipphone draft, but with the Annex G packages used by the IPPhone profile. And I concede that most things work fine for MGCs that want "raw" event reporting, ie. not using digitmaps or event descriptors for filtering. It would be useful for an MGC vendor that is planning to support IP Phones to express an opinion here. Maybe these are issues for the implementors guide or for version 2 update of Megaco annexes. One issue that I am stuck on, however, is that I can't find a way to audit the current value of the hookswitch (or any persistent-state key, for that matter). Even if the MGC is hot-standby/auto-failover, there will be times where it is conceivable that the current state of a particular IP Phone will be unknown. e.g. powering up a phone while the handset is knocked off the cradle. I would like to be able to apply off-hook warning tone in this case. Relying on user-behaviour to jiggle the hookswitch a few times, or have the phone possibly ring while off-hook is not optimal. You make reference to having the Phone generate immediate events for each key on event descriptor download - I'm not aware how to make the phone do that w.r.t. the key package. On the issue of multiple terminations, I absolutely agree that it is a good architecture to separate the terminations. But until we can find a way to allow reflex operations between terminations, we will have to admit that we either avoid reflex operations or make the device have some implicit knowledge of local interactions. -----Original Message----- From: Peter Blatherwick [mailto:blather@NORTELNETWORKS.COM] Sent: Thursday, October 05, 2000 10:23 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Issues with draft-ietf-megaco-ipphone-03.txt Bob: I believe your comments below do not actually affect the Megaco IP Phone draft itself. However, I agree with some of the issues you raise. Since the Megaco IP Phone draft is currently in last call, its important to identify where the issues reside. See [pb] comments below. -- Peter Blatherwick -----Original Message----- From: Bob Lukas [ mailto:blukas@BROADCOM.COM ] Sent: Thursday, October 05, 2000 01:10 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Issues with draft-ietf-megaco-ipphone-03.txt We've been looking at implementing draft-ietf-megaco-ipphone-03.txt and a few thorny issues have come up that I haven't seen discussed. Keypad and hookswitch are extensions of the basic annex G key package in the UI termination - this means: [pb] A quick clarification: all the UI packages used by IP Phone are Annex G packages, no extensions to Annex G are proposed. Your statement above is correct, but wanted to make sure all understood it. 1. There is no "current state" property value of these switches, only keyup and keydown events that are generated. e.g. the event reported is key/ku{keyid=kh} for an off-hook event. Not normally an issue for momentary push-buttons, but it means an MGC cannot audit for whether the phone is currently off-hook. Kind of a problem for an MGC that is trying to recover state at startup... [pb} True, there is no current state property. I like the general approach you suggest below to time 0 state problem. I personally think the MGC side of things must be responsible for recovering state if their is a failure cut-over (not sure if that's the scenario you are concerned about) since there's a heck of a lot more than hookswitch state involved in call state. At device startup, the worst that can happen is the user will get bored and hang up, generating the event anyway. [pb] Since this is a limitation of what is specified in Annex G, this does not directly affect the Megaco IP Phone draft. I don't think this is serious though. 2. At times, I'm only interested in events from a subset of the possible keys. How can I set an event descriptor to only monitor hookswitch (for example), and not random other button presses? Is this syntax legal? ...modify = ui { events =1 { key/ku { keyid = kh }, key/kd { keyid = f001} } If it was, it would help overcome the audit issue, by getting an immediate event if currently off-hook. [pb] I like it, even though I personally favour the all events on all the time approach. But I am personally unclear if this syntax is valid or not (its been a while). Unless someone on the list can clarify, I'll look into it. Even if suggested syntax is not valid, immediate Events could be returned indicating key states at the time the EventsDescriptor is received at the MG. [pb] This is an issue related to Megaco/H.248 Protocol overall, not specifically Megaco IP Phone. Useful for Implementer's Guide? 3. The audio transducers are separate terminations from the UI. This has great impact on wanting to automatically stop call progress tones immediately when keys are pressed. As far as I understand, an event occurring in one termination must not affect the signals active in another termination (which would be a huge problem for a multiple line device for example). For example, I cannot have dialtone automatically stop when I press a key - the MGC must send down a signal to explicitly stop it. Even worse, if I choose to implement a digitmap on my keypad, the MGC has no way of knowing when to stop dialtone, because it gets no event until after the entire dial string is entered. Saying the IP Phone should know and understand the implicit interactions between the terminations is also problematic and against the general Megaco philosophy of centralized control. [pb] The issue of Termination organization has been picked apart at length several times before, resulting in the current organization. While I certainly understand there is a tradeoff around causing reflex actions to occur as a result of Events, grouping of all termination functionality into a single termination (the implied solution) would result in drastically reduced flexibility for the model overall, and make several powerful applications non-intuitive at best. For example, applications like group listening (talker on a handset while others listen on handsfree) require individual control over the audio input/outputs, hence separate Transducer Terminations to allow them to be freely manipulated. Paging while on a call, IP-radio and several other applications would also be awkward without separate terminations. Since the MGC can control everything, albeit with some extra load, the flexible model is favoured, with the intent to open up new applications well beyond what "phones" can do today. [pb] I strongly agree with you statement that MGs should have no knowledge of call-related interactions (or any other application-level knowledge for that matter), and it would indeed break the Megaco/H.248 master/slave model. I think we all agree we don't go there. [pb] Since this topic has been visited several times, and good agreement achieved that this flexibility is important, I would not favour opening the issues again. I believe the general issue of inter-termination interaction may be a useful area for work in future versions of Megaco/H.248, as I can see several other example where it might be helpful. -- PB _____________________________________________________ Bob Lukas Broadcom Canada Richmond B.C. blukas@broadcom.com 604-233-8665 ------_=_NextPart_001_01C03D3A.7A4084A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Issues with draft-ietf-megaco-ipphone-03.txt

Yes, handling states this way would work.  = However, I think it would be more consistent and useful to handle *all* = such state-related event reporting by defining a convention at the = protocol level. 

Such a convention would behave in the same way as = currently documented for strict=3D"state" reporting mode in = Analog Line Supervision Package, onhook and offhook event.  This = reports the current state of the termination if it is already in the = requested state when the EventsDescriptor arrives.  This would be = simple and direct, generally applicable, and would not require any = additional Audit steps.  (Actually, I thought there were already = words in the protocol document that described this, but darn if I can = find them now.) 

I am not anxious to update Annex G for something that = is of potential interest in many places (would want to update other = existing packages for consistency, and remember and define = statefullness handling in all future packages which behave this = way).  Note that the default for the strict=3D parameter in the AL = package is also not defined, so a convention would remove ambiguity = there, and that AL does not define properties as you suggest either, so = there would be inconsistency.  

Personally I think a note in the Implementer's Guide = on stateful reporting convention, covering all state reporting, would = be the way to go for this. 

-- Peter

-----Original Message-----
From: Taylor, Tom-PT [NORSE:B901:EXCH]
Sent: Monday, October 23, 2000 16:06
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Issues with = draft-ietf-megaco-ipphone-03.txt


States should be captured in properties.  Would = it make sense to add the
requisite properties to Annex G?

-----Original Message-----
From: Bob Lukas [mailto:blukas@BROADCOM.COM]
Sent: Friday, October 13, 2000 12:35 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Issues with = draft-ietf-megaco-ipphone-03.txt


Peter,
I have been considering your comments and hoping for = additional feedback
from MGC vendors.

I agree my issues are not really specific to the = ipphone draft, but with the
Annex G packages used by the IPPhone profile.  = And I concede that most
things work fine for MGCs that want "raw" = event reporting, ie. not using
digitmaps or event descriptors for filtering. It = would be useful for an MGC
vendor that is planning to support IP Phones to = express an opinion here.

Maybe these are issues for the implementors guide or = for version 2 update of
Megaco annexes.

One issue that I am stuck on, however, is that I = can't find a way to audit
the current value of the hookswitch (or any = persistent-state key, for that
matter). Even if the MGC is = hot-standby/auto-failover, there will be times
where it is conceivable that the current state of a = particular IP Phone will
be unknown. e.g. powering up a phone while the = handset is knocked off the
cradle. I would like to be able to apply off-hook = warning tone in this case.
Relying on user-behaviour to jiggle the hookswitch a = few times, or have the
phone possibly ring while off-hook is not optimal. = You make reference to
having the Phone generate immediate events for each = key on event descriptor
download - I'm not aware how to make the phone do = that w.r.t. the key
package.

On the issue of multiple terminations, I absolutely = agree that it is a good
architecture to separate the terminations. But until = we can find a way to
allow reflex operations between terminations, we = will have to admit that we
either avoid reflex operations or make the device = have some implicit
knowledge of local interactions.

-----Original Message-----
From: Peter Blatherwick [mailto:blather@NORTELNETWORKS= .COM]
Sent: Thursday, October 05, 2000 10:23 AM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Issues with = draft-ietf-megaco-ipphone-03.txt



Bob:

I believe your comments below do not actually affect = the Megaco IP Phone
draft itself.  However, I agree with some of = the issues you raise.  Since
the Megaco IP Phone draft is currently in last call, = its important to
identify where the issues reside.  See [pb] = comments below.

-- Peter Blatherwick

-----Original Message-----
From: Bob Lukas [ mailto:blukas@BROADCOM.COM = <mailto:blukas@BROADCOM.COM> = ]
Sent: Thursday, October 05, 2000 01:10
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Issues with = draft-ietf-megaco-ipphone-03.txt




We've been looking at implementing = draft-ietf-megaco-ipphone-03.txt and a
few thorny issues have come up that I haven't seen = discussed. Keypad and
hookswitch are extensions of the basic annex G key = package in the UI
termination - this means:

[pb] A quick clarification: all the UI packages used = by IP Phone are Annex G
packages, no extensions to Annex G are = proposed.  Your statement above is
correct, but wanted to make sure all understood = it.

1. There is no "current state" property = value of these switches, only keyup
and keydown events that are generated. e.g. the = event reported is
key/ku{keyid=3Dkh} for an off-hook event. Not = normally an issue for momentary
push-buttons, but it means an MGC cannot audit for = whether the phone is
currently off-hook. Kind of a problem for an MGC = that is trying to recover
state at startup...

[pb} True, there is no current state property.  = I like the general approach
you suggest below to time 0 state problem.  I = personally think the MGC side
of things must be responsible for recovering state = if their is a failure
cut-over (not sure if that's the scenario you are = concerned about) since
there's a heck of a lot more than hookswitch state = involved in call state.
At device startup, the worst that can happen is the = user will get bored and
hang up, generating the event anyway.

[pb] Since this is a limitation of what is specified = in Annex G, this does
not directly affect the Megaco IP Phone draft.  = I don't think this is
serious though.

2. At times, I'm only interested in events from a = subset of the possible
keys. How can I set an event descriptor to only = monitor hookswitch (for
example), and not random other button = presses?

Is this syntax legal? ...modify =3D ui { events =3D1 = { key/ku { keyid =3D kh },
key/kd { keyid =3D f001} }
If it was, it would help overcome the audit issue, = by getting an immediate
event if currently off-hook.

[pb] I like it, even though I personally favour the = all events on all the
time approach.  But I am personally unclear if = this syntax is valid or not
(its been a while).  Unless someone on the list = can clarify, I'll look into
it.  Even if suggested syntax is not valid, = immediate Events could be
returned indicating key states at the time the = EventsDescriptor is received
at the MG.

[pb] This is an issue related to Megaco/H.248 = Protocol overall, not
specifically Megaco IP Phone.  Useful for = Implementer's Guide?

3. The audio transducers are separate terminations = from the UI. This has
great impact on wanting to automatically stop call = progress tones
immediately when keys are pressed. As far as I = understand, an event
occurring in one termination must not affect the = signals active in another
termination (which would be a huge problem for a = multiple line device for
example). For example, I cannot have dialtone = automatically stop when I
press a key - the MGC must send down a signal to = explicitly stop it. Even
worse, if I choose to implement a digitmap on my = keypad, the MGC has no way
of knowing when to stop dialtone, because it gets no = event until after the
entire dial string is entered. Saying the IP Phone = should know and
understand the implicit interactions between the = terminations is also
problematic and against the general Megaco = philosophy of centralized
control.

[pb] The issue of Termination organization has been = picked apart at length
several times before, resulting in the current = organization. While I
certainly understand there is a tradeoff around = causing reflex actions to
occur as a result of Events, grouping of all = termination functionality into
a single termination (the implied solution) would = result in drastically
reduced flexibility for the model overall, and make = several powerful
applications non-intuitive at best.  For = example, applications like group
listening (talker on a handset while others listen = on handsfree) require
individual control over the audio input/outputs, = hence separate Transducer
Terminations to allow them to be freely = manipulated.  Paging while on a
call, IP-radio and several other applications would = also be awkward without
separate terminations.  Since the MGC can = control everything, albeit with
some extra load, the flexible model is favoured, = with the intent to open up
new applications well beyond what "phones" = can do today.

[pb] I strongly agree with you statement that MGs = should have no knowledge
of call-related interactions (or any other = application-level knowledge for
that matter), and it would indeed break the = Megaco/H.248 master/slave model.
I think we all agree we don't go there.

[pb] Since this topic has been visited several times, = and good agreement
achieved that this flexibility is important, I would = not favour opening the
issues again.  I believe the general issue of = inter-termination interaction
may be a useful area for work in future versions of = Megaco/H.248, as I can
see several other example where it might be = helpful.

-- PB
_____________________________________________________
Bob Lukas
Broadcom Canada
Richmond B.C.
blukas@broadcom.com
604-233-8665

------_=_NextPart_001_01C03D3A.7A4084A0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Mon Oct 23 21:34:43 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA25842 for ; Mon, 23 Oct 2000 21:34:42 -0400 (EDT) Received: from standards (47.234.32.16:3929) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9A65@standards.nortelnetworks.com>; Mon, 23 Oct 2000 21:17:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 42773 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Mon, 23 Oct 2000 21:17:09 -0400 Received: from qhars002.nortel.com (47.101.112.102:43232) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9A64@standards.nortelnetworks.com>; Mon, 23 Oct 2000 21:17:08 -0400 Received: from smtprch2.nortel.com (actually erchg0k) by qhars002.nortel.com; Tue, 24 Oct 2000 02:31:30 +0100 Received: from zrchb213.us.nortel.com (actually zrchb213) by smtprch2.nortel.com; Mon, 23 Oct 2000 20:27:11 -0500 Received: by zrchb213.us.nortel.com with Internet Mail Service (5.5.2652.35) id ; Mon, 23 Oct 2000 20:31:13 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03D5A.15EFC540" X-Orig: Message-ID: <353093573B82D411889E0000F808216648E423@zcard00q.ca.nortel.com> Date: Mon, 23 Oct 2000 20:31:09 -0500 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Audit of packages To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03D5A.15EFC540 Content-Type: text/plain; charset="iso-8859-1" At risk of further continuing a thread that has already gone on for some time... I agree we should say something, and that Christian's proposed text gives good advice and does no harm. (If its also redundant, that's not really a problem, as long as the advice is good.) Tom's point 2) below leads me to think maybe the support of base packages would be better as a "MAY", as this would allow some Packages to be deprecated over time, and would also allow a vendor to take a really tight focus if they saw fit and not be breaking any rules or advice implied. Having pointed out what MAY be done, and specifically how, vendors would get it right, and I expect almost all would publish base packages as described as an aid to backward compatibility. On a closer read I also notice the word "implement" (in quotes) used, where it is actually not quite correct. In reality, extended Packages MUST implement their base -- that's how it works. However it is optional to publish this for use. How about: " When packages are extended, the properties, events, signals and statistics defined in the base package can be referred to using either the extended package name. For example, if Package A defines event e1, and Package B extends Package A, then B/e1 is an event for a termination implementing Package B. By definition, the MG MUST also implement the base Package, but it optional to publish the base package as an allowed interface. If it does publish A, then A would be reported on the Package Descriptor in AuditValue as well as B, and event A/e1 would be available on a termination. If the MG does not publish A, then only B/e1 would be available. If published through AuditValue, A/e1 and B/e1 are the same event. For the purpose of improved interoperability and backward compatibility, the an MG MAY publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived. An exception to this is in cases where the base packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own, in which case the MG SHOULD NOT publish the base Packages. " -- Peter -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Monday, October 23, 2000 16:07 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages The problem is that an implementer reading the text does not know if he should, or should not, implement the base package under the base package name. Whichever decision he makes, the text is clear on what he should do. The question is should the implementer's guide offer advice on whether the base package should be implemented. Christian suggested that it should, further suggested that the advice should be that the implementer SHOULD (not SHALL) implement the base package, and I agreed with him. I actually had suggested MAY, which I'm still okay with. It seems wrong to make it MUST or SHALL NOT. Whichever way we agree on, I want the text to say something on whether the base package should be implemented. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Monday, October 23, 2000 3:47 PM To: Rosen, Brian; megaco@standards.nortelnetworks.com Subject: RE: Audit of packages Do we agree on this logic, which was behind my intervention? (1) An MG publishes the packages it is prepared to understand in incoming messages. (2) An MG does not publish packages which it is not prepared to understand in incoming messages. This is why I felt that the middle part of Christian's text was unnecessary -- the final two sentences already capture the intent. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Monday, October 23, 2000 3:17 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages We all agree about the requirement to support the properties, events, signals and statistics of the base package under the package name of the new package. What is unclear is what an implementation should do about the base package. Should it support the base package names also? The proposed text recommends that it SHOULD. Is that a problem? I think guidance is warranted. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Monday, October 23, 2000 1:43 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages I have a disagreement with the portion of text indicated below and suggest that it be dropped. The ambiguity is about names, not about implementation: the standard leaves no ambiguity about the requirement to support all of the base package. > -----Original Message----- > From: Christian Groves [ mailto:Christian.Groves@ERICSSON.COM ] > Sent: Monday, October 16, 2000 2:14 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > G'Day all, > > Below is the text which I propose to put into the implementor's guide. > Its a mix of Brian and Pete's proposed words. I note that I changed > Brian's MAY to Pete's SHOULD. > > 9.5 Package Extension and Referencing > > Description: The current text in H.248 Section 12.1 is > ambiguous about > the usage of package names when referencing properties, > events, signals > and statistics in a base package and an extended package. > Reference: Subject: Re: Audit of packages > Date: Fri, 13 Oct 2000 07:58:12 -0400 > From: "Rosen, Brian" > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: RE: Audit of packages > Date: Fri, 13 Oct 2000 15:15:14 -0500 > From: "Peter Blatherwick" > To: "'Christian Groves'" > CC: megaco@standards.nortelnetworks.com, "'Rosen, Brian'" > > > [Begin Clarification] > Section 12.1 > When packages are extended, the properties, events, signals and > statistics defined in the base package can be referred to using the > extended package name. For example, if Package A defines > event e1, and > Package B extends Package A, then B/e1 is an event for a termination > implementing Package B. [PTT] The MG SHOULD also "implement" the base > Package. If it does, then A would be reported on the Package > Descriptor > in AuditValue as well as B, and event A/e1 would be available on a > termination. If the MG does not implement A, then only B/e1 would be > available. If implemented, [PTT] > A/e1 and B/e1 are the same event. > An MG SHOULD publish all Packages supported by its Terminations, > including base Packages from which extended Packages are derived. An > exception to this is in cases where the base Packages are expressly > designed to be extended by others, not directly controlled, > and may not > have any function on their own or be nonsensical on their own. > [End Clarification] > > Any problems with the text? > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > We probably need some words in the Implementer's Guide, I agree. > > > > How about something like: > > When packages are extended, the properties, events, signals > and statistics > > defined in the base package can be referred to using the > extended package > > name. For example, if Package A defines event e1, and > Package B extends > > Package A, then B/e1 is an event for a termination > implementing Package B. > > The MG MAY also "implement" the base Package. If it does, > then A would > > be reported on the Package Descriptor in AuditValue as well > as B, and > > event A/e1 would be available on a termination. If the MG does not > > implement A, then only B/e1 would be available. Of course, > if implemented, > > A/e1 and B/e1 are the same event. > > > > Brian > > > > > -----Original Message----- > > > From: chassija@hss.hns.com [ mailto:chassija@hss.hns.com ] > > > Sent: Friday, October 13, 2000 12:29 AM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Hello Brian, > > > > > > If this is the case as you are pointing out, then it should > > > be clearly mentioned > > > in the protocol. Because the protocol says only the following > > > --- in context of > > > Package B extending Package A -- > > > > > > Sec 12.1.1 - " When a package > > > extends another package it shall only add additional > Properties, > > > Events, Signals, Statistics and new possible values for an > > > existing parameter described in the original > package. An extended > > > package shall not redefine or overload a name defined in the > > > original package." > > > > > > This seems to imply that Package B has to support all the > > > events supported on > > > Package A...... > > > > > > What is your opinion on this.... > > > Chanchal.... > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/13/2000 01:32:21 AM > > > > > > Please respond to "Rosen, Brian" > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > I don't think there is any change to the base understanding. > > > > > > Suppose Package A defines Event e1 > > > Suppose Package B extends Package A. > > > > > > Now, you can talk about A/e1 or B/e1. > > > > > > If you "expose" package A, then you would include A in the > > > list of packages reported on an audit, and A/e1 as well as B/e1 > > > would be legal. > > > > > > If you don't expose package A, then you can only use B/e1. > > > > > > In both cases the extended package inherits the behavior of the > > > base package. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [ mailto:samittal@HSS.HNS.COM ] > > > > Sent: Thursday, October 12, 2000 11:55 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Audit of packages > > > > > > > > > > > > The idea of supporting extending package but not supporting > > > > base package > > > > is not the basic philosophy of extension of packages > which says that > > > > extended package inherits the behaviour of base package. > > > > > > > > So do we need to change the basic understanding of package > > > extensions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > > > > > > > Please respond to Dave Sclarsky > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > > > > > > What do you think about the case where an MG can support pkg2 > > > > but NOT pkg3? > > > > > > > > Take the case of the Tone Detection Package and the DTMF > > > > Detection Package > > > > that extends it. There are most certainly 'intelligent' > > > > devices that are > > > > capable of reporting DTMF digits, but do not offer the > > > > granularity to report > > > > 'Start tone' or 'End tone' detected. > > > > > > > > I would have assumed that an MG with such a device would > > > > (should!) publish > > > > dd but not tonedet, because it really cannot notify > tonedet/std or > > > > tonedet/etd. > > > > > > > > DaveS. > > > > > > > > > > > > -----Original Message----- > > > > > From: Christian Groves [ mailto:Christian.Groves@ERICSSON.COM ] > > > > > Sent: Wednesday, October 11, 2000 10:25 PM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > > > > when it is > > > > > inappropriate and we have the rule saying that you can address > > > > > properties by pkg3. > > > > > > > > > > But, I'm happy with Should if you can provide the > text when it is > > > > > inappropriate. > > > > > > > > > > Cheers, Christian > > > > > > > > > > Peter Blatherwick wrote: > > > > -------------------------- > > > > > > > > > > I agree in general, since "extends" basically means > > > "clone the base > > > > > package and add some more functionality" (no subsetting, > > > over-riding > > > > > etc allowed). In example below pkg2 by definition > > > implements pkg3. > > > > > (Not the case with re-versioning of Packages though!) > > > > > > > > > > One clarification however. It does not always make sense > > > for a base > > > > > package to be published as implemented by an MG. There > > > are examples > > > > > where the base package is defined such that it acts > similar to a > > > > > virtual class, and has no function on its own, simply defining > > > > > interface for one or more derived packages. Annex E > ToneGen and > > > > > ToneDet as well as a few packages in Annex G are examples. > > > > Therefore, > > > > > implementer's guide MUST not make a hard and fast rule on > > > this, but > > > > > SHOULD say "SHOULD" with some words to describe where its > > > > > inappropriate. > > > > > > > > > > -- Peter > > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM ] > > > > > Sent: Monday, October 09, 2000 16:03 > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > We've been around this and basically, it is up to the MG. > > > > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > > > > is a good word, and I wonder if text to that effect > > > > > should go in the implementor's guide? > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Sachin Mittal [ mailto:samittal@HSS.HNS.COM ] > > > > > Sent: Monday, October 09, 2000 5:12 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Audit of packages > > > > > > > > > > Say a termination abc implements the following packages: > > > > > 1. pkg1 > > > > > 2. pkg2 > > > > > where pkg2 extends pkg3 and pkg1 doesn't extend any > other package > > > > > > > > > > If this termination is audited for packages implemented on it, > > > > > should the reply include pkg3 with pkg1 and pkg2 (base > > > package names > > > > > are included) > > > > > > > > > > Sachin > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C03D5A.15EFC540 Content-Type: text/html; charset="iso-8859-1" RE: Audit of packages
At risk of further continuing a thread that has already gone on for some time... 
 
I agree we should say something, and that Christian's proposed text gives good advice and does no harm.  (If its also redundant, that's not really a problem, as long as the advice is good.) 
 
Tom's point 2) below leads me to think maybe the support of base packages would be better as a "MAY", as this would allow some Packages to be deprecated over time, and would also allow a vendor to take a really tight focus if they saw fit and not be breaking any rules or advice implied.  Having pointed out what MAY be done, and specifically how, vendors would get it right, and I expect almost all would publish base packages as described as an aid to backward compatibility. 
 
On a closer read I also notice the word "implement" (in quotes) used, where it is actually not quite correct.  In reality, extended Packages MUST implement their base -- that's how it works.  However it is optional to publish this for use. 
 
How about:
"
When packages are extended, the properties, events, signals and statistics defined in the base package can be referred to using either the extended package name.  For example, if Package A defines event e1, and Package B extends Package A, then B/e1 is an event for a termination implementing Package B. By definition, the MG MUST also implement the base Package, but it optional to publish the base package as an allowed interface.  If it does publish A, then A would be reported on the Package Descriptor in AuditValue as well as B, and event A/e1 would be available on a termination.  If the MG does not publish A, then only B/e1 would be available.  If published through AuditValue, A/e1 and B/e1 are the same event.
For the purpose of improved interoperability and backward compatibility, the an MG MAY publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived.  An exception to this is in cases where the base packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own, in which case the MG SHOULD NOT publish the base Packages. 
"
 
-- Peter
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Monday, October 23, 2000 16:07
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Audit of packages

The problem is that an implementer reading the text does not know if he should,
or should not, implement the base package under the base package name. 
Whichever decision he makes, the text is clear on what he should do. 
The question is should the implementer's guide offer advice on whether the
base package should be implemented.
 
Christian suggested that it should, further suggested that the advice should be
that the implementer SHOULD (not SHALL) implement the base package, and
I agreed with him.  I actually had suggested MAY, which I'm still okay with.
It seems wrong to make it MUST or SHALL NOT.  Whichever way we agree on,
I want the text to say something on whether the base package should be
implemented.
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com]
Sent: Monday, October 23, 2000 3:47 PM
To: Rosen, Brian; megaco@standards.nortelnetworks.com
Subject: RE: Audit of packages

Do we agree on this logic, which was behind my intervention?
  (1) An MG publishes the packages it is prepared to understand in incoming messages.
  (2) An MG does not publish packages which it is not prepared to understand in incoming messages.
 
This is why I felt that the middle part of Christian's text was unnecessary -- the final two sentences already capture the intent.
 
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Monday, October 23, 2000 3:17 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Audit of packages

We all agree about the requirement to support the properties, events, signals and
statistics of the base package under the package name of the new package.
 
What is unclear is what an implementation should do about the base package.
Should it support the base package names also?
The proposed text recommends that it SHOULD.  Is that a problem?
I think guidance is warranted.
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM]
Sent: Monday, October 23, 2000 1:43 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Audit of packages

I have a disagreement with the portion of text indicated below and suggest that it be dropped.  The ambiguity is about names, not about implementation: the standard leaves no ambiguity about the requirement to support all of the base package.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> Sent: Monday, October 16, 2000 2:14 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Audit of packages
>
>
> G'Day all,
>
> Below is the text which I propose to put into the implementor's guide.
> Its a mix of Brian and Pete's proposed words. I note that I changed
> Brian's MAY to Pete's SHOULD.
>
> 9.5     Package Extension and Referencing
>
> Description:    The current text in H.248 Section 12.1 is
> ambiguous about
> the usage of package names when referencing properties,
> events, signals
> and statistics in a base package and an extended package.
> Reference:      Subject: Re: Audit of packages
> Date: Fri, 13 Oct 2000 07:58:12 -0400
> From: "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>
> Subject: RE: Audit of packages
> Date: Fri, 13 Oct 2000 15:15:14 -0500
> From: "Peter Blatherwick" <blather@nortelnetworks.com>
> To: "'Christian Groves'" <Christian.Groves@ericsson.com>
> CC: megaco@standards.nortelnetworks.com, "'Rosen, Brian'"
> <Brian.Rosen@MARCONI.COM>
>
> [Begin Clarification]
> Section 12.1
> When packages are extended, the properties, events, signals and
> statistics defined in the base package can be referred to using the
> extended package name.  For example, if Package A defines
> event e1, and
> Package B extends Package A, then B/e1 is an event for a termination
> implementing Package B.

[PTT] <begin text proposed to be omitted>
The MG SHOULD also "implement" the base
> Package.  If it does, then A would be reported on the Package
> Descriptor
> in AuditValue as well as B, and event A/e1 would be available on a
> termination.  If the MG does not implement A, then only B/e1 would be
> available.  If implemented,
[PTT] <end text proposed to be omitted>

> A/e1 and B/e1 are the same event.
> An MG SHOULD publish all Packages supported by its Terminations,
> including base Packages from which extended Packages are derived.  An
> exception to this is in cases where the base Packages are expressly
> designed to be extended by others, not directly controlled,
> and may not
> have any function on their own or be nonsensical on their own.
> [End Clarification]
>
> Any problems with the text?
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > We probably need some words in the Implementer's Guide, I agree.
> >
> > How about something like:
> > When packages are extended, the properties, events, signals
> and statistics
> > defined in the base package can be referred to using the
> extended package
> > name.  For example, if Package A defines event e1, and
> Package B extends
> > Package A, then B/e1 is an event for a termination
> implementing Package B.
> > The MG MAY also "implement" the base Package.  If it does,
> then A would
> > be reported on the Package Descriptor in AuditValue as well
> as B, and
> > event A/e1 would be available on a termination.  If the MG does not
> > implement A, then only B/e1 would be available.  Of course,
> if implemented,
> > A/e1 and B/e1 are the same event.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: chassija@hss.hns.com [mailto:chassija@hss.hns.com]
> > > Sent: Friday, October 13, 2000 12:29 AM
> > > To: Rosen, Brian
> > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Audit of packages
> > >
> > >
> > >
> > >
> > > Hello Brian,
> > >
> > > If this is the case as you are pointing out, then it should
> > > be clearly mentioned
> > > in the protocol. Because the protocol says only the following
> > > --- in context of
> > > Package B extending Package A --
> > >
> > > Sec 12.1.1 - " When a package
> > >      extends another package it shall only add additional
> Properties,
> > >      Events, Signals, Statistics and new possible values for an
> > >      existing parameter described in the original
> package. An extended
> > >      package shall not redefine or overload a name defined in the
> > >      original package."
> > >
> > > This seems to imply that Package B has to support all the
> > > events supported on
> > > Package A......
> > >
> > > What is your opinion on this....
> > > Chanchal....
> > >
> > >
> > >
> > >
> > >
> > > "Rosen, Brian" <Brian.Rosen@MARCONI.COM> on 10/13/2000 01:32:21 AM
> > >
> > > Please respond to "Rosen, Brian" <Brian.Rosen@MARCONI.COM>
> > >
> > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > cc:    (bcc: Chanchal Hassija/HSS)
> > >
> > > Subject:  Re: Audit of packages
> > >
> > >
> > >
> > >
> > > I don't think there is any change to the base understanding.
> > >
> > > Suppose Package A defines Event e1
> > > Suppose Package B extends Package A.
> > >
> > > Now, you can talk about A/e1 or B/e1.
> > >
> > > If you "expose" package A, then you would include A in the
> > > list of packages reported on an audit, and A/e1 as well as B/e1
> > > would be legal.
> > >
> > > If you don't expose package A, then you can only use B/e1.
> > >
> > > In both cases the extended package inherits the behavior of the
> > > base package.
> > >
> > > Brian
> > >
> > > > -----Original Message-----
> > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> > > > Sent: Thursday, October 12, 2000 11:55 AM
> > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Audit of packages
> > > >
> > > >
> > > > The idea of supporting extending package but not supporting
> > > > base package
> > > > is not the basic philosophy of extension of packages
> which says that
> > > > extended package inherits the behaviour of base package.
> > > >
> > > > So do we need to change the basic understanding of package
> > > extensions.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Dave Sclarsky <dsclarsky@SS7-LINK.COM> on 10/12/2000 07:44:17 PM
> > > >
> > > > Please respond to Dave Sclarsky <dsclarsky@SS7-LINK.COM>
> > > >
> > > > To:   MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > cc:    (bcc: Sachin Mittal/HSS)
> > > >
> > > > Subject:  Re: Audit of packages
> > > >
> > > >
> > > >
> > > >
> > > > What do you think about the case where an MG can support pkg2
> > > > but NOT pkg3?
> > > >
> > > > Take the case of the Tone Detection Package and the DTMF
> > > > Detection Package
> > > > that extends it.  There are most certainly 'intelligent'
> > > > devices that are
> > > > capable of reporting DTMF digits, but do not offer the
> > > > granularity to report
> > > > 'Start tone' or 'End tone' detected.
> > > >
> > > > I would have assumed that an MG with such a device would
> > > > (should!) publish
> > > > dd but not tonedet, because it really cannot notify
> tonedet/std or
> > > > tonedet/etd.
> > > >
> > > > DaveS.
> > > >
> > > >
> > > > -----Original Message-----
> > > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM]
> > > > > Sent: Wednesday, October 11, 2000 10:25 PM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Audit of packages
> > > > >
> > > > >
> > > > > Perhaps we "should" say "SHALL", I can't think of a case of
> > > > when it is
> > > > > inappropriate and we have the rule saying that you can address
> > > > > properties by pkg3.
> > > > >
> > > > > But, I'm happy with Should if you can provide the
> text when it is
> > > > > inappropriate.
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > Peter Blatherwick wrote:
> > > > --------------------------
> > > > >
> > > > > I agree in general, since "extends" basically means
> > > "clone the base
> > > > > package and add some more functionality" (no subsetting,
> > > over-riding
> > > > > etc allowed).  In example below pkg2 by definition
> > > implements pkg3.
> > > > > (Not the case with re-versioning of Packages though!)
> > > > >
> > > > > One clarification however.  It does not always make sense
> > > for a base
> > > > > package to be published as implemented by an MG.  There
> > > are examples
> > > > > where the base package is defined such that it acts
> similar to a
> > > > > virtual class, and has no function on its own, simply defining
> > > > > interface for one or more derived packages.  Annex E
> ToneGen and
> > > > > ToneDet as well as a few packages in Annex G are examples.
> > > > Therefore,
> > > > > implementer's guide MUST not make a hard and fast rule on
> > > this, but
> > > > > SHOULD say "SHOULD" with some words to describe where its
> > > > > inappropriate.
> > > > >
> > > > > -- Peter
> > > > >
> > > > > -----Original Message-----
> > > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > > > > Sent: Monday, October 09, 2000 16:03
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Audit of packages
> > > > >
> > > > > We've been around this and basically, it is up to the MG.
> > > > > It does not HAVE to report pkg3, but it could.  Maybe SHOULD
> > > > > is a good word, and I wonder if text to that effect
> > > > > should go in the implementor's guide?
> > > > >
> > > > > Brian
> > > > >
> > > > > -----Original Message-----
> > > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM]
> > > > > Sent: Monday, October 09, 2000 5:12 AM
> > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Audit of packages
> > > > >
> > > > > Say a termination abc implements the following packages:
> > > > > 1. pkg1
> > > > > 2. pkg2
> > > > > where pkg2 extends pkg3 and pkg1 doesn't extend any
> other package
> > > > >
> > > > > If this termination is audited for packages implemented on it,
> > > > > should the reply include pkg3 with pkg1 and pkg2 (base
> > > package names
> > > > > are included)
> > > > >
> > > > > Sachin
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>

------_=_NextPart_001_01C03D5A.15EFC540-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 06:02:09 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id GAA29914 for ; Tue, 24 Oct 2000 06:02:09 -0400 (EDT) Received: from standards (47.234.32.16:1150) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9C1C@standards.nortelnetworks.com>; Tue, 24 Oct 2000 5:45:05 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 43368 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 05:45:05 -0400 Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9C1B@standards.nortelnetworks.com>; Tue, 24 Oct 2000 5:45:04 -0400 Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 11:58:59 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Message-ID: <81C3E8FE6C0AD4119D49009027C3AAB25DABFC@MAIL-IN> Date: Tue, 24 Oct 2000 11:58:59 +0200 Reply-To: Nurit Shenhar Sender: "Media Gateway Control (megaco)" From: Nurit Shenhar Subject: Global digitmaps To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi list I would like some clarifications about using global digit maps. My understanding is this: 1. When a termination gets a DigitMap descriptor that contains a name of a global map and no value, it refers to the global value and doesn't keep a local copy of it. 2. The termination keeps a local copy of a map if it gets global name with a value other than the original one. 3. If a global DigitMap is deleted, it is also deleted from all the terminations using the reference to it. Active map shall be deleted after completion. Best regards Nurit Shenhar AudioCodes Ltd. Direct: +972-3-539-4155 Tel: +972-3-539-4000 Fax: +972-3-539-4040 email: nurit.shenhar@audiocodes.com web: From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 07:53:06 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA28031 for ; Tue, 24 Oct 2000 07:53:03 -0400 (EDT) Received: from standards (47.234.32.16:1864) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9D5A@standards.nortelnetworks.com>; Tue, 24 Oct 2000 7:34:48 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 43714 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 07:34:47 -0400 Received: from sj-msg-core-crit.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9D59@standards.nortelnetworks.com>; Tue, 24 Oct 2000 7:34:47 -0400 Received: from mailman.cisco.com (mailman.cisco.com [171.68.225.9]) by sj-msg-core-crit.cisco.com (8.9.3/8.9.1) with ESMTP id EAA23318 for ; Tue, 24 Oct 2000 04:50:14 -0700 (PDT) Received: from cisco.com (ssh-sj1.cisco.com [171.68.225.134]) by mailman.cisco.com (8.9.3/8.9.1) with ESMTP id EAA19285 for ; Tue, 24 Oct 2000 04:50:14 -0700 (PDT) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F5789F.AFF6A6AA@cisco.com> Date: Tue, 24 Oct 2000 07:55:11 -0400 Reply-To: Flemming Andreasen Sender: "Media Gateway Control (megaco)" From: Flemming Andreasen Organization: Cisco Systems Subject: [Fwd: Signal lists] To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Resending as I haven't seen any response yet. -- Flemming Flemming Andreasen wrote: > Greetings > > A couple of questions on signal lists: > > - What does it mean for individual signals in a signal list to have the > KeepActive flag set and how come the signal list itself doesn't have > such a flag (keeping in mind that "A signal list is treated as a single > signal of the specified type when played out.") ? > > - In the definition of Signal Completion (E.1.2) it says "Possible > values: a list of signals and/or sequential signal lists which have > terminated.". Does that mean that completion of a signal list itself > generates a "signal completion" event ? > > - A related question for clarification. If a signal in the signal list > has the "notifyCompletion" flag set, I assume the event will be > generated when that particular signal finished, right ? > > Thanks > > Flemming > > -- > Flemming Andreasen > Cisco Systems -- Flemming Andreasen Cisco Systems From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 08:08:28 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id IAA01724 for ; Tue, 24 Oct 2000 08:08:27 -0400 (EDT) Received: from standards (47.234.32.16:1864) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9D75@standards.nortelnetworks.com>; Tue, 24 Oct 2000 7:51:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 43750 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 07:51:29 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9D74@standards.nortelnetworks.com>; Tue, 24 Oct 2000 7:51:28 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA06090; Tue, 24 Oct 2000 08:06:53 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id IAA24219; Tue, 24 Oct 2000 08:06:55 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CR4HMM>; Tue, 24 Oct 2000 08:06:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E896@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 24 Oct 2000 08:06:54 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Global digitmaps X-To: Nurit Shenhar To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'm not sure if your understanding is wrong, but your explanation is a bit rough. Think of digitmaps like variables in a programming language. There are local variables, and global variables Variables have to be defined before they are used. You define these "variables" with the DIgitMap descriptor You use a digitmap somewhat like a procedure call. You can supply a name (variable), value (constant). You can also supply a value and a name which is equivalent to use the "constant" and assign the value to the name (for subsequent use). Because a digitmap is "active" for a while, there is a special rule, which is really equivalent for local and global, but probably isn't really useful for local - once you start using the value of a digitmap to collect digits, changing the definition of the name doesn't affect the in-use value - the termination continues to use the prior value. If you started to use a local digitmap, and then changed its value before the Notification of its completion event, the termination would continue to use the prior value, the next use would be with the new value, just as a global digitmap would. Does that help? Brian > -----Original Message----- > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM] > Sent: Tuesday, October 24, 2000 5:59 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Global digitmaps > > > Hi list > > I would like some clarifications about using global digit maps. My > understanding is this: > > 1. When a termination gets a DigitMap descriptor that > contains a name of a > global map and no value, it refers to the global value and > doesn't keep a > local copy of it. > > 2. The termination keeps a local copy of a map if it gets > global name with > a value other than the original one. > > 3. If a global DigitMap is deleted, it is also deleted from all the > terminations using the reference to it. Active map shall be > deleted after > completion. > > Best regards > > Nurit Shenhar > AudioCodes Ltd. > > Direct: +972-3-539-4155 > Tel: +972-3-539-4000 > Fax: +972-3-539-4040 > email: nurit.shenhar@audiocodes.com > > web: > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 09:25:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA22741 for ; Tue, 24 Oct 2000 09:25:02 -0400 (EDT) Received: from standards (47.234.32.16:1770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9E0A@standards.nortelnetworks.com>; Tue, 24 Oct 2000 9:08:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 43924 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 09:08:01 -0400 Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9E09@standards.nortelnetworks.com>; Tue, 24 Oct 2000 9:08:00 -0400 Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 15:21:55 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Message-ID: <81C3E8FE6C0AD4119D49009027C3AAB25DABFE@MAIL-IN> Date: Tue, 24 Oct 2000 15:21:52 +0200 Reply-To: Nurit Shenhar Sender: "Media Gateway Control (megaco)" From: Nurit Shenhar Subject: Inconsistency in NotifyCompletion definition To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi list I found inconsistency between the draft-ietf-megaco-merged-01 document and the RFC 2885 document. In the RFC 2885 (August 2000): notifyCompletion = NotifyCompletionToken EQUAL ("ON" / "OFF") In the draft-ietf-megaco-merged-01 (May 2000): notifyCompletion = NotifyCompletionToken EQUAL (LBRKT notificationReason *(COMMA notificationReason) RBRKT notificationReason = ( TimeOutToken / InterruptByEventToken / InterruptByNewSignalsDescrToken / OtherReasonToken ) which one is correct? Best regards Nurit Shenhar AudioCodes Ltd. Direct: +972-3-539-4155 Tel: +972-3-539-4000 Fax: +972-3-539-4040 email: nurit.shenhar@audiocodes.com web: From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 10:16:47 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id KAA01488 for ; Tue, 24 Oct 2000 10:16:46 -0400 (EDT) Received: from standards (47.234.32.16:1770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9E6A@standards.nortelnetworks.com>; Tue, 24 Oct 2000 9:59:41 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44060 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 09:59:40 -0400 Received: from mail-in.audiocodes.com (AC-INT-LP.ser.netvision.net.il) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9E69@standards.nortelnetworks.com>; Tue, 24 Oct 2000 9:59:40 -0400 Received: by MAIL-IN with Internet Mail Service (5.5.2650.21) id ; Tue, 24 Oct 2000 16:13:33 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="windows-1255" Message-ID: <81C3E8FE6C0AD4119D49009027C3AAB25DAC00@MAIL-IN> Date: Tue, 24 Oct 2000 16:13:32 +0200 Reply-To: Nurit Shenhar Sender: "Media Gateway Control (megaco)" From: Nurit Shenhar Subject: Re: Global digitmaps X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Hi Brian Thenks for the explanation, but I am still not sure about everything. There are two places that refer the digitmap. One is in the EventDM, that is used for digitmap activation, either by using an existing name (local or global) or by supplying an immediate value. I have no problem with that. But now the second place - the DigitMapDescriptor, is not very clear. If I got you, this is the way to define a variable, that can be referenced later. But then, what is the meaning of defining only a value without name? Also, if you define a global name without value, does that mean that you want to create a local copy of it? Nurit -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Tuesday, October 24, 2000 2:07 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Global digitmaps I'm not sure if your understanding is wrong, but your explanation is a bit rough. Think of digitmaps like variables in a programming language. There are local variables, and global variables Variables have to be defined before they are used. You define these "variables" with the DIgitMap descriptor You use a digitmap somewhat like a procedure call. You can supply a name (variable), value (constant). You can also supply a value and a name which is equivalent to use the "constant" and assign the value to the name (for subsequent use). Because a digitmap is "active" for a while, there is a special rule, which is really equivalent for local and global, but probably isn't really useful for local - once you start using the value of a digitmap to collect digits, changing the definition of the name doesn't affect the in-use value - the termination continues to use the prior value. If you started to use a local digitmap, and then changed its value before the Notification of its completion event, the termination would continue to use the prior value, the next use would be with the new value, just as a global digitmap would. Does that help? Brian > -----Original Message----- > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM] > Sent: Tuesday, October 24, 2000 5:59 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Global digitmaps > > > Hi list > > I would like some clarifications about using global digit maps. My > understanding is this: > > 1. When a termination gets a DigitMap descriptor that > contains a name of a > global map and no value, it refers to the global value and > doesn't keep a > local copy of it. > > 2. The termination keeps a local copy of a map if it gets > global name with > a value other than the original one. > > 3. If a global DigitMap is deleted, it is also deleted from all the > terminations using the reference to it. Active map shall be > deleted after > completion. > > Best regards > > Nurit Shenhar > AudioCodes Ltd. > > Direct: +972-3-539-4155 > Tel: +972-3-539-4000 > Fax: +972-3-539-4040 > email: nurit.shenhar@audiocodes.com > > web: > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 11:40:26 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA14229 for ; Tue, 24 Oct 2000 11:40:24 -0400 (EDT) Received: from standards (47.234.32.16:1770) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9ED9@standards.nortelnetworks.com>; Tue, 24 Oct 2000 11:22:56 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44220 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 11:22:56 -0400 Received: from qhars002.nortel.com (47.101.112.102:60266) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9ED6@standards.nortelnetworks.com>; Tue, 24 Oct 2000 11:22:55 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Tue, 24 Oct 2000 15:48:58 +0100 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 24 Oct 2000 10:08:08 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRF6MY>; Tue, 24 Oct 2000 10:08:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DC3.D3547AE0" X-Orig: Message-ID: <353093573B82D411889E0000F808216648E424@zcard00q.ca.nortel.com> Date: Tue, 24 Oct 2000 10:08:03 -0400 Reply-To: Peter Blatherwick Sender: "Media Gateway Control (megaco)" From: Peter Blatherwick Subject: Re: Audit of packages X-cc: Christian Groves , Tom-PT Taylor , "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03DC3.D3547AE0 Content-Type: text/plain; charset="iso-8859-1" Oops, a few minor glitches in proposed text I sent last night, repaired below. (Stupid fingers!) Also missed that the description does not specifically talk about signals, properties or statistics. Below is still longer than before, but is more specific and complete. Try again: " When packages are extended, the properties, events, signals and statistics defined in the base package can be referred to using either the extended package name or the base package name. By definition, an MG implementing an extended package MUST also implement all aspects of the base package, but it is optional to publish the base package as an allowed interface. For example, if Package A defines event e1, and Package B extends Package A and defines event e2, then B/e1 and B/e2 are events for a termination implementing Package B. If the MG does publish Package A, then Package A would be reported in the PackageDescriptor returned by AuditValue as well as Package B, and events A/e1, B/e1 and B/e2 would be available on the termination. If the MG does not publish A, then only B/e1 and B/e2 would be available. If published through AuditValue, A/e1 and B/e1 are the same event. The same logic also applies to signals, properties and statistics. For the purpose of improved interoperability and backward compatibility, an MG MAY publish all packages supported by its terminations, including base packages from which extended packages are derived. An exception to this is in cases where the base packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own, in which case an MG SHOULD NOT publish the base packages. " Enough fussing, -- Peter -----Original Message----- From: Blatherwick, Peter [CAR:AT14:EXCH] Sent: Monday, October 23, 2000 21:31 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages At risk of further continuing a thread that has already gone on for some time... I agree we should say something, and that Christian's proposed text gives good advice and does no harm. (If its also redundant, that's not really a problem, as long as the advice is good.) Tom's point 2) below leads me to think maybe the support of base packages would be better as a "MAY", as this would allow some Packages to be deprecated over time, and would also allow a vendor to take a really tight focus if they saw fit and not be breaking any rules or advice implied. Having pointed out what MAY be done, and specifically how, vendors would get it right, and I expect almost all would publish base packages as described as an aid to backward compatibility. On a closer read I also notice the word "implement" (in quotes) used, where it is actually not quite correct. In reality, extended Packages MUST implement their base -- that's how it works. However it is optional to publish this for use. How about: " When packages are extended, the properties, events, signals and statistics defined in the base package can be referred to using either the extended package name or the base package name . For example, if Package A defines event e1, and Package B extends Package A, then B/e1 is an event for a termination implementing Package B. By definition, the MG MUST also implement the base Package, but it is optional to publish the base package as an allowed interface. If the MG does publish A, then A would be reported on the Package Descriptor in AuditValue as well as B, and both event A/e1 and B/e1 would be available on a termination. If the MG does not publish A, then only B/e1 would be available. If published through AuditValue, A/e1 and B/e1 are the same event. For the purpose of improved interoperability and backward compatibility, the an MG MAY publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived. An exception to this is in cases where the base packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own, in which case the MG SHOULD NOT publish the base Packages. " -- Peter -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Monday, October 23, 2000 16:07 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages The problem is that an implementer reading the text does not know if he should, or should not, implement the base package under the base package name. Whichever decision he makes, the text is clear on what he should do. The question is should the implementer's guide offer advice on whether the base package should be implemented. Christian suggested that it should, further suggested that the advice should be that the implementer SHOULD (not SHALL) implement the base package, and I agreed with him. I actually had suggested MAY, which I'm still okay with. It seems wrong to make it MUST or SHALL NOT. Whichever way we agree on, I want the text to say something on whether the base package should be implemented. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] Sent: Monday, October 23, 2000 3:47 PM To: Rosen, Brian; megaco@standards.nortelnetworks.com Subject: RE: Audit of packages Do we agree on this logic, which was behind my intervention? (1) An MG publishes the packages it is prepared to understand in incoming messages. (2) An MG does not publish packages which it is not prepared to understand in incoming messages. This is why I felt that the middle part of Christian's text was unnecessary -- the final two sentences already capture the intent. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Monday, October 23, 2000 3:17 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages We all agree about the requirement to support the properties, events, signals and statistics of the base package under the package name of the new package. What is unclear is what an implementation should do about the base package. Should it support the base package names also? The proposed text recommends that it SHOULD. Is that a problem? I think guidance is warranted. Brian -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Monday, October 23, 2000 1:43 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages I have a disagreement with the portion of text indicated below and suggest that it be dropped. The ambiguity is about names, not about implementation: the standard leaves no ambiguity about the requirement to support all of the base package. > -----Original Message----- > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > Sent: Monday, October 16, 2000 2:14 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > G'Day all, > > Below is the text which I propose to put into the implementor's guide. > Its a mix of Brian and Pete's proposed words. I note that I changed > Brian's MAY to Pete's SHOULD. > > 9.5 Package Extension and Referencing > > Description: The current text in H.248 Section 12.1 is > ambiguous about > the usage of package names when referencing properties, > events, signals > and statistics in a base package and an extended package. > Reference: Subject: Re: Audit of packages > Date: Fri, 13 Oct 2000 07:58:12 -0400 > From: "Rosen, Brian" > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: RE: Audit of packages > Date: Fri, 13 Oct 2000 15:15:14 -0500 > From: "Peter Blatherwick" > To: "'Christian Groves'" > CC: megaco@standards.nortelnetworks.com, "'Rosen, Brian'" > > > [Begin Clarification] > Section 12.1 > When packages are extended, the properties, events, signals and > statistics defined in the base package can be referred to using the > extended package name. For example, if Package A defines > event e1, and > Package B extends Package A, then B/e1 is an event for a termination > implementing Package B. [PTT] The MG SHOULD also "implement" the base > Package. If it does, then A would be reported on the Package > Descriptor > in AuditValue as well as B, and event A/e1 would be available on a > termination. If the MG does not implement A, then only B/e1 would be > available. If implemented, [PTT] > A/e1 and B/e1 are the same event. > An MG SHOULD publish all Packages supported by its Terminations, > including base Packages from which extended Packages are derived. An > exception to this is in cases where the base Packages are expressly > designed to be extended by others, not directly controlled, > and may not > have any function on their own or be nonsensical on their own. > [End Clarification] > > Any problems with the text? > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > We probably need some words in the Implementer's Guide, I agree. > > > > How about something like: > > When packages are extended, the properties, events, signals > and statistics > > defined in the base package can be referred to using the > extended package > > name. For example, if Package A defines event e1, and > Package B extends > > Package A, then B/e1 is an event for a termination > implementing Package B. > > The MG MAY also "implement" the base Package. If it does, > then A would > > be reported on the Package Descriptor in AuditValue as well > as B, and > > event A/e1 would be available on a termination. If the MG does not > > implement A, then only B/e1 would be available. Of course, > if implemented, > > A/e1 and B/e1 are the same event. > > > > Brian > > > > > -----Original Message----- > > > From: chassija@hss.hns.com [mailto:chassija@hss.hns.com] > > > Sent: Friday, October 13, 2000 12:29 AM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Hello Brian, > > > > > > If this is the case as you are pointing out, then it should > > > be clearly mentioned > > > in the protocol. Because the protocol says only the following > > > --- in context of > > > Package B extending Package A -- > > > > > > Sec 12.1.1 - " When a package > > > extends another package it shall only add additional > Properties, > > > Events, Signals, Statistics and new possible values for an > > > existing parameter described in the original > package. An extended > > > package shall not redefine or overload a name defined in the > > > original package." > > > > > > This seems to imply that Package B has to support all the > > > events supported on > > > Package A...... > > > > > > What is your opinion on this.... > > > Chanchal.... > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/13/2000 01:32:21 AM > > > > > > Please respond to "Rosen, Brian" > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > I don't think there is any change to the base understanding. > > > > > > Suppose Package A defines Event e1 > > > Suppose Package B extends Package A. > > > > > > Now, you can talk about A/e1 or B/e1. > > > > > > If you "expose" package A, then you would include A in the > > > list of packages reported on an audit, and A/e1 as well as B/e1 > > > would be legal. > > > > > > If you don't expose package A, then you can only use B/e1. > > > > > > In both cases the extended package inherits the behavior of the > > > base package. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > > > Sent: Thursday, October 12, 2000 11:55 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Audit of packages > > > > > > > > > > > > The idea of supporting extending package but not supporting > > > > base package > > > > is not the basic philosophy of extension of packages > which says that > > > > extended package inherits the behaviour of base package. > > > > > > > > So do we need to change the basic understanding of package > > > extensions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > > > > > > > Please respond to Dave Sclarsky > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > > > > > > What do you think about the case where an MG can support pkg2 > > > > but NOT pkg3? > > > > > > > > Take the case of the Tone Detection Package and the DTMF > > > > Detection Package > > > > that extends it. There are most certainly 'intelligent' > > > > devices that are > > > > capable of reporting DTMF digits, but do not offer the > > > > granularity to report > > > > 'Start tone' or 'End tone' detected. > > > > > > > > I would have assumed that an MG with such a device would > > > > (should!) publish > > > > dd but not tonedet, because it really cannot notify > tonedet/std or > > > > tonedet/etd. > > > > > > > > DaveS. > > > > > > > > > > > > -----Original Message----- > > > > > From: Christian Groves [mailto:Christian.Groves@ERICSSON.COM] > > > > > Sent: Wednesday, October 11, 2000 10:25 PM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > > > > when it is > > > > > inappropriate and we have the rule saying that you can address > > > > > properties by pkg3. > > > > > > > > > > But, I'm happy with Should if you can provide the > text when it is > > > > > inappropriate. > > > > > > > > > > Cheers, Christian > > > > > > > > > > Peter Blatherwick wrote: > > > > -------------------------- > > > > > > > > > > I agree in general, since "extends" basically means > > > "clone the base > > > > > package and add some more functionality" (no subsetting, > > > over-riding > > > > > etc allowed). In example below pkg2 by definition > > > implements pkg3. > > > > > (Not the case with re-versioning of Packages though!) > > > > > > > > > > One clarification however. It does not always make sense > > > for a base > > > > > package to be published as implemented by an MG. There > > > are examples > > > > > where the base package is defined such that it acts > similar to a > > > > > virtual class, and has no function on its own, simply defining > > > > > interface for one or more derived packages. Annex E > ToneGen and > > > > > ToneDet as well as a few packages in Annex G are examples. > > > > Therefore, > > > > > implementer's guide MUST not make a hard and fast rule on > > > this, but > > > > > SHOULD say "SHOULD" with some words to describe where its > > > > > inappropriate. > > > > > > > > > > -- Peter > > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > > > > > Sent: Monday, October 09, 2000 16:03 > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > We've been around this and basically, it is up to the MG. > > > > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > > > > is a good word, and I wonder if text to that effect > > > > > should go in the implementor's guide? > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] > > > > > Sent: Monday, October 09, 2000 5:12 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Audit of packages > > > > > > > > > > Say a termination abc implements the following packages: > > > > > 1. pkg1 > > > > > 2. pkg2 > > > > > where pkg2 extends pkg3 and pkg1 doesn't extend any > other package > > > > > > > > > > If this termination is audited for packages implemented on it, > > > > > should the reply include pkg3 with pkg1 and pkg2 (base > > > package names > > > > > are included) > > > > > > > > > > Sachin > > > > > > > > > > > > > > > > > > > > > > > ------_=_NextPart_001_01C03DC3.D3547AE0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Audit of packages

Oops, a few minor glitches in proposed text I sent = last night, repaired below.  (Stupid fingers!)  Also missed = that the description does not specifically talk about signals, = properties or statistics.  Below is still longer than before, but = is more specific and complete. 

Try again:
"
When packages are extended, the properties, events, = signals and statistics defined in the base package can be referred to = using either the extended package name or the base package name.  = By definition, an MG implementing an extended package MUST also = implement all aspects of the base package, but it is optional to = publish the base package as an allowed interface.  For example, if = Package A defines event e1, and Package B extends Package A and defines = event e2, then B/e1 and B/e2 are events for a termination implementing = Package B.  If the MG does publish Package A, then Package A would = be reported in the PackageDescriptor returned by AuditValue as well as = Package B, and events A/e1, B/e1 and B/e2 would be available on the = termination.  If the MG does not publish A, then only B/e1 and = B/e2 would be available.  If published through AuditValue, A/e1 = and B/e1 are the same event. The same logic also applies to signals, = properties and statistics. 

 
For the purpose of improved interoperability and = backward compatibility, an MG MAY publish all packages supported by its = terminations, including base packages from which extended packages are = derived.  An exception to this is in cases where the base packages = are expressly designed to be extended by others, not directly = controlled, and may not have any function on their own or be = nonsensical on their own, in which case an MG SHOULD NOT publish the = base packages. 

"
 
Enough fussing,
-- Peter

-----Original Message-----
From: Blatherwick, Peter [CAR:AT14:EXCH]
Sent: Monday, October 23, 2000 21:31
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Audit of packages


At risk of further continuing a thread that has = already gone on for some time... 
 
I agree we should say something, and that = Christian's proposed text gives good advice and does no harm.  (If = its also redundant, that's not really a problem, as long as the advice = is good.) 

 
Tom's point 2) below leads me to think maybe the = support of base packages would be better as a "MAY", as this = would allow some Packages to be deprecated over time, and would also = allow a vendor to take a really tight focus if they saw fit and not be = breaking any rules or advice implied.  Having pointed out what MAY = be done, and specifically how, vendors would get it right, and I expect = almost all would publish base packages as described as an aid to = backward compatibility. 

 
On a closer read I also notice the word = "implement" (in quotes) used, where it is actually not quite = correct.  In reality, extended Packages MUST implement their base = -- that's how it works.  However it is optional to publish this = for use. 

How about:
"
When packages are extended, the properties, events, = signals and statistics defined in the base package can be referred to = using either the extended package name or the base package name .  = For example, if Package A defines event e1, and Package B extends = Package A, then B/e1 is an event for a termination implementing Package = B.   By definition, the MG MUST also implement the base = Package, but it  is optional to publish the base package as an = allowed interface.  If  the MG does publish A, then A would = be reported on the Package Descriptor in AuditValue as well as B, = and  both event A/e1 and B/e1 would be available on a = termination.  If the MG does not publish A, then only B/e1 would = be available.  If published through AuditValue, A/e1 and B/e1 are = the same event.

 
For the purpose of improved interoperability and = backward compatibility, the an MG MAY publish all Packages supported by = its Terminations, including base Packages from which extended Packages = are derived.  An exception to this is in cases where the base = packages are expressly designed to be extended by others, not directly = controlled, and may not have any function on their own or be = nonsensical on their own, in which case the MG SHOULD NOT publish the = base Packages. 

"
 
-- Peter
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Monday, October 23, 2000 16:07
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Audit of packages


The problem is that an implementer reading the text = does not know if he should,
or should not, implement the base package under the = base package name. 
Whichever decision he makes, the text is clear on = what he should do. 
The question is should the implementer's guide offer = advice on whether the
base package should be implemented.
 
Christian suggested that it should, further = suggested that the advice should be
that the implementer SHOULD (not SHALL) implement = the base package, and
I agreed with him.  I actually had suggested = MAY, which I'm still okay with.
It seems wrong to make it MUST or SHALL NOT.  = Whichever way we agree on,
I want the text to say something on whether the base = package should be
implemented.
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@nortelnetworks.c= om]
Sent: Monday, October 23, 2000 3:47 PM
To: Rosen, Brian; = megaco@standards.nortelnetworks.com
Subject: RE: Audit of packages


Do we agree on this logic, which was behind my = intervention?
  (1) An MG publishes the packages it is = prepared to understand in incoming messages.
  (2) An MG does not publish packages which it = is not prepared to understand in incoming messages.
 
This is why I felt that the middle part of = Christian's text was unnecessary -- the final two sentences already = capture the intent.

 
-----Original Message-----
From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
Sent: Monday, October 23, 2000 3:17 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Audit of packages


We all agree about the requirement to support the = properties, events, signals and
statistics of the base package under the package = name of the new package.
 
What is unclear is what an implementation should do = about the base package.
Should it support the base package names = also?
The proposed text recommends that it SHOULD.  = Is that a problem?
I think guidance is warranted.
 
Brian
-----Original Message-----
From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.C= OM]
Sent: Monday, October 23, 2000 1:43 PM
To: MEGACO@STANDARDS.NORTELNETWORKS.COM
Subject: Re: Audit of packages


I have a disagreement with the portion of text = indicated below and suggest that it be dropped.  The ambiguity is = about names, not about implementation: the standard leaves no ambiguity = about the requirement to support all of the base package.

> -----Original Message-----
> From: Christian Groves [mailto:Christian.Groves@ER= ICSSON.COM]
> Sent: Monday, October 16, 2000 2:14 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Re: Audit of packages
>
>
> G'Day all,
>
> Below is the text which I propose to put into = the implementor's guide.
> Its a mix of Brian and Pete's proposed words. I = note that I changed
> Brian's MAY to Pete's SHOULD.
>
> 9.5     Package Extension = and Referencing
>
> Description:    The current text = in H.248 Section 12.1 is
> ambiguous about
> the usage of package names when referencing = properties,
> events, signals
> and statistics in a base package and an = extended package.
> Reference:      = Subject: Re: Audit of packages
> Date: Fri, 13 Oct 2000 07:58:12 -0400
> From: "Rosen, Brian" = <Brian.Rosen@MARCONI.COM>
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
>
> Subject: RE: Audit of packages
> Date: Fri, 13 Oct 2000 15:15:14 -0500
> From: "Peter Blatherwick" = <blather@nortelnetworks.com>
> To: "'Christian Groves'" = <Christian.Groves@ericsson.com>
> CC: megaco@standards.nortelnetworks.com, = "'Rosen, Brian'"
> <Brian.Rosen@MARCONI.COM>
>
> [Begin Clarification]
> Section 12.1
> When packages are extended, the properties, = events, signals and
> statistics defined in the base package can be = referred to using the
> extended package name.  For example, if = Package A defines
> event e1, and
> Package B extends Package A, then B/e1 is an = event for a termination
> implementing Package B.
[PTT] <begin text proposed to be omitted> =
The MG SHOULD also "implement" the base =
> Package.  If it does, then A would be = reported on the Package
> Descriptor
> in AuditValue as well as B, and event A/e1 = would be available on a
> termination.  If the MG does not implement = A, then only B/e1 would be
> available.  If implemented,
[PTT] <end text proposed to be omitted> =
> A/e1 and B/e1 are the same event.
> An MG SHOULD publish all Packages supported by = its Terminations,
> including base Packages from which extended = Packages are derived.  An
> exception to this is in cases where the base = Packages are expressly
> designed to be extended by others, not directly = controlled,
> and may not
> have any function on their own or be = nonsensical on their own.
> [End Clarification]
>
> Any problems with the text?
>
> Cheers, Christian
>
> "Rosen, Brian" wrote:
> >
> > We probably need some words in the = Implementer's Guide, I agree.
> >
> > How about something like:
> > When packages are extended, the = properties, events, signals
> and statistics
> > defined in the base package can be = referred to using the
> extended package
> > name.  For example, if Package A = defines event e1, and
> Package B extends
> > Package A, then B/e1 is an event for a = termination
> implementing Package B.
> > The MG MAY also "implement" the = base Package.  If it does,
> then A would
> > be reported on the Package Descriptor in = AuditValue as well
> as B, and
> > event A/e1 would be available on a = termination.  If the MG does not
> > implement A, then only B/e1 would be = available.  Of course,
> if implemented,
> > A/e1 and B/e1 are the same event.
> >
> > Brian
> >
> > > -----Original Message-----
> > > From: chassija@hss.hns.com [mailto:chassija@hss.hns.com] =
> > > Sent: Friday, October 13, 2000 12:29 = AM
> > > To: Rosen, Brian
> > > Cc: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > Subject: Re: Audit of packages =
> > >
> > >
> > >
> > >
> > > Hello Brian,
> > >
> > > If this is the case as you are = pointing out, then it should
> > > be clearly mentioned
> > > in the protocol. Because the protocol = says only the following
> > > --- in context of
> > > Package B extending Package A -- =
> > >
> > > Sec 12.1.1 - " When a package =
> > >      extends = another package it shall only add additional
> Properties,
> > >      Events, = Signals, Statistics and new possible values for an
> > >      = existing parameter described in the original
> package. An extended
> > >      package = shall not redefine or overload a name defined in the
> > >      = original package."
> > >
> > > This seems to imply that Package B = has to support all the
> > > events supported on
> > > Package A......
> > >
> > > What is your opinion on this.... =
> > > Chanchal....
> > >
> > >
> > >
> > >
> > >
> > > "Rosen, Brian" = <Brian.Rosen@MARCONI.COM> on 10/13/2000 01:32:21 AM
> > >
> > > Please respond to "Rosen, = Brian" <Brian.Rosen@MARCONI.COM>
> > >
> > > To:   = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > cc:    (bcc: Chanchal = Hassija/HSS)
> > >
> > > Subject:  Re: Audit of packages =
> > >
> > >
> > >
> > >
> > > I don't think there is any change to = the base understanding.
> > >
> > > Suppose Package A defines Event e1 =
> > > Suppose Package B extends Package A. =
> > >
> > > Now, you can talk about A/e1 or B/e1. =
> > >
> > > If you "expose" package A, = then you would include A in the
> > > list of packages reported on an = audit, and A/e1 as well as B/e1
> > > would be legal.
> > >
> > > If you don't expose package A, then = you can only use B/e1.
> > >
> > > In both cases the extended package = inherits the behavior of the
> > > base package.
> > >
> > > Brian
> > >
> > > > -----Original Message----- =
> > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] =
> > > > Sent: Thursday, October 12, 2000 = 11:55 AM
> > > > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > Subject: Re: Audit of packages =
> > > >
> > > >
> > > > The idea of supporting extending = package but not supporting
> > > > base package
> > > > is not the basic philosophy of = extension of packages
> which says that
> > > > extended package inherits the = behaviour of base package.
> > > >
> > > > So do we need to change the = basic understanding of package
> > > extensions.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > Dave Sclarsky = <dsclarsky@SS7-LINK.COM> on 10/12/2000 07:44:17 PM
> > > >
> > > > Please respond to Dave Sclarsky = <dsclarsky@SS7-LINK.COM>
> > > >
> > > > To:   = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > cc:    (bcc: = Sachin Mittal/HSS)
> > > >
> > > > Subject:  Re: Audit of = packages
> > > >
> > > >
> > > >
> > > >
> > > > What do you think about the case = where an MG can support pkg2
> > > > but NOT pkg3?
> > > >
> > > > Take the case of the Tone = Detection Package and the DTMF
> > > > Detection Package
> > > > that extends it.  There are = most certainly 'intelligent'
> > > > devices that are
> > > > capable of reporting DTMF = digits, but do not offer the
> > > > granularity to report
> > > > 'Start tone' or 'End tone' = detected.
> > > >
> > > > I would have assumed that an MG = with such a device would
> > > > (should!) publish
> > > > dd but not tonedet, because it = really cannot notify
> tonedet/std or
> > > > tonedet/etd.
> > > >
> > > > DaveS.
> > > >
> > > >
> > > > -----Original Message----- =
> > > > > From: Christian Groves [mailto:Christian.Groves@ER= ICSSON.COM]
> > > > > Sent: Wednesday, October = 11, 2000 10:25 PM
> > > > > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Audit of = packages
> > > > >
> > > > >
> > > > > Perhaps we = "should" say "SHALL", I can't think of a case of =
> > > > when it is
> > > > > inappropriate and we have = the rule saying that you can address
> > > > > properties by pkg3.
> > > > >
> > > > > But, I'm happy with Should = if you can provide the
> text when it is
> > > > > inappropriate.
> > > > >
> > > > > Cheers, Christian
> > > > >
> > > > > Peter Blatherwick wrote: =
> > > > -------------------------- =
> > > > >
> > > > > I agree in general, since = "extends" basically means
> > > "clone the base
> > > > > package and add some more = functionality" (no subsetting,
> > > over-riding
> > > > > etc allowed).  In = example below pkg2 by definition
> > > implements pkg3.
> > > > > (Not the case with = re-versioning of Packages though!)
> > > > >
> > > > > One clarification = however.  It does not always make sense
> > > for a base
> > > > > package to be published as = implemented by an MG.  There
> > > are examples
> > > > > where the base package is = defined such that it acts
> similar to a
> > > > > virtual class, and has no = function on its own, simply defining
> > > > > interface for one or more = derived packages.  Annex E
> ToneGen and
> > > > > ToneDet as well as a few = packages in Annex G are examples.
> > > > Therefore,
> > > > > implementer's guide MUST = not make a hard and fast rule on
> > > this, but
> > > > > SHOULD say = "SHOULD" with some words to describe where its
> > > > > inappropriate.
> > > > >
> > > > > -- Peter
> > > > >
> > > > > -----Original Message----- =
> > > > > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM]
> > > > > Sent: Monday, October 09, = 2000 16:03
> > > > > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Re: Audit of = packages
> > > > >
> > > > > We've been around this and = basically, it is up to the MG.
> > > > > It does not HAVE to report = pkg3, but it could.  Maybe SHOULD
> > > > > is a good word, and I = wonder if text to that effect
> > > > > should go in the = implementor's guide?
> > > > >
> > > > > Brian
> > > > >
> > > > > -----Original Message----- =
> > > > > From: Sachin Mittal [mailto:samittal@HSS.HNS.COM] =
> > > > > Sent: Monday, October 09, = 2000 5:12 AM
> > > > > To: = MEGACO@STANDARDS.NORTELNETWORKS.COM
> > > > > Subject: Audit of packages =
> > > > >
> > > > > Say a termination abc = implements the following packages:
> > > > > 1. pkg1
> > > > > 2. pkg2
> > > > > where pkg2 extends pkg3 and = pkg1 doesn't extend any
> other package
> > > > >
> > > > > If this termination is = audited for packages implemented on it,
> > > > > should the reply include = pkg3 with pkg1 and pkg2 (base
> > > package names
> > > > > are included)
> > > > >
> > > > > Sachin
> > > >
> > >
> > >
> > >
> > >
> > >
> > >
>

------_=_NextPart_001_01C03DC3.D3547AE0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 12:20:30 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id MAA23113 for ; Tue, 24 Oct 2000 12:20:30 -0400 (EDT) Received: from standards (47.234.32.16:4938) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9EF9@standards.nortelnetworks.com>; Tue, 24 Oct 2000 12:03:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44263 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 12:03:26 -0400 Received: from slink12.ss7-link.com (mail.ss7-link.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9EF8@standards.nortelnetworks.com>; Tue, 24 Oct 2000 12:03:25 -0400 Received: by SLINK12 with Internet Mail Service (5.5.2650.21) id <4KWBW72B>; Tue, 24 Oct 2000 12:16:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 24 Oct 2000 12:16:19 -0400 Reply-To: Dave Sclarsky Sender: "Media Gateway Control (megaco)" From: Dave Sclarsky Subject: Re: Audit of digit map. X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM If audit value for DigitMap returns the active one, is there any way for the MGC to audit the new one? Wouldn't an audit value on the EventDescriptor return the 'active' DigitMap? DaveS. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] Sent: Tuesday, October 17, 2000 8:09 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of digit map. The active one. Brian > -----Original Message----- > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > Sent: Monday, October 16, 2000 6:23 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Audit of digit map. > > > Digit map with name "abc" is defined on a given termination > T1. If the digit map > is active and MGC overwrites the definition of "abc", its > mentioned in protocol > that this new definition will be applied only after > deactivation of the digit > map. > If at this momment MGC audits the termination with digit map > token, which > definition of the digit map "abc" is sent in response. The > one that is active or > the > one that will be applied after digit map deactivation? > -Madhubabu > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 14:08:55 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08157 for ; Tue, 24 Oct 2000 14:08:54 -0400 (EDT) Received: from standards (47.234.32.16:4058) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9FC3@standards.nortelnetworks.com>; Tue, 24 Oct 2000 13:49:10 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44505 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 13:49:10 -0400 Received: from qhars002.nortel.com (47.101.112.102:38204) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9FC0@standards.nortelnetworks.com>; Tue, 24 Oct 2000 13:49:09 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Tue, 24 Oct 2000 18:57:25 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 24 Oct 2000 13:41:37 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRGFKK>; Tue, 24 Oct 2000 13:41:29 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) Message-ID: <28560036253BD41191A10000F8BCBD110250C610@zcard00g.ca.nortel.com> Date: Tue, 24 Oct 2000 13:41:17 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Audit of digit map. X-To: Dave Sclarsky To: MEGACO@STANDARDS.NORTELNETWORKS.COM This seems to be one of those cases where the specification isn't clear, so we have a choice. It's absolutely clear to me that the AuditValue of EventsDescriptor should return the active DigitMap. It seems reasonable to me that AuditValue of DigitMapDescriptor should return the new digitMap. In each case, the most recent setting of the descriptor is being returned. > -----Original Message----- > From: Dave Sclarsky [mailto:dsclarsky@SS7-LINK.COM] > Sent: Tuesday, October 24, 2000 12:16 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of digit map. > > > If audit value for DigitMap returns the active one, > is there any way for the MGC to audit the new one? > > Wouldn't an audit value on the EventDescriptor return > the 'active' DigitMap? > > DaveS. > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Tuesday, October 17, 2000 8:09 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of digit map. > > > The active one. > > Brian > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Monday, October 16, 2000 6:23 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Audit of digit map. > > > > > > Digit map with name "abc" is defined on a given termination > > T1. If the digit map > > is active and MGC overwrites the definition of "abc", its > > mentioned in protocol > > that this new definition will be applied only after > > deactivation of the digit > > map. > > If at this momment MGC audits the termination with digit map > > token, which > > definition of the digit map "abc" is sent in response. The > > one that is active or > > the > > one that will be applied after digit map deactivation? > > -Madhubabu > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 14:08:57 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id OAA08167 for ; Tue, 24 Oct 2000 14:08:55 -0400 (EDT) Received: from standards (47.234.32.16:4058) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9FC6@standards.nortelnetworks.com>; Tue, 24 Oct 2000 13:49:11 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44509 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 13:49:10 -0400 Received: from qhars002.nortel.com (47.101.112.102:38205) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBA9FC1@standards.nortelnetworks.com>; Tue, 24 Oct 2000 13:49:10 -0400 Received: from ertpg14e1.nortelnetworks.com (actually zrtph06m) by qhars002.nortel.com; Tue, 24 Oct 2000 18:57:09 +0100 Received: from zrtpd004.us.nortel.com (actually zrtpd004) by ertpg14e1.nortelnetworks.com; Tue, 24 Oct 2000 13:32:37 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRG155>; Tue, 24 Oct 2000 13:32:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2652.35) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C03DE0.6225FFC0" Message-ID: <28560036253BD41191A10000F8BCBD110250C60E@zcard00g.ca.nortel.com> Date: Tue, 24 Oct 2000 13:32:29 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Inconsistency in NotifyCompletion definition X-To: Nurit Shenhar To: MEGACO@STANDARDS.NORTELNETWORKS.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_001_01C03DE0.6225FFC0 Content-Type: text/plain; charset="windows-1255" The second one is correct. To see the correction, look at RFC 2886, "Section 7.1.11". > -----Original Message----- > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM] > Sent: Tuesday, October 24, 2000 9:22 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Inconsistency in NotifyCompletion definition > > > Hi list > > I found inconsistency between the draft-ietf-megaco-merged-01 > document and > the RFC 2885 document. > > In the RFC 2885 (August 2000): > > notifyCompletion = NotifyCompletionToken EQUAL ("ON" / "OFF") > > In the draft-ietf-megaco-merged-01 (May 2000): > > notifyCompletion = NotifyCompletionToken EQUAL (LBRKT > notificationReason *(COMMA > notificationReason) RBRKT > > notificationReason = ( TimeOutToken / InterruptByEventToken > / InterruptByNewSignalsDescrToken > / OtherReasonToken ) > > > which one is correct? > > > Best regards > > Nurit Shenhar > AudioCodes Ltd. > Direct: +972-3-539-4155 > Tel: +972-3-539-4000 > Fax: +972-3-539-4040 > email: nurit.shenhar@audiocodes.com > > web: > ------_=_NextPart_001_01C03DE0.6225FFC0 Content-Type: text/html; charset="windows-1255" Content-Transfer-Encoding: quoted-printable RE: Inconsistency in NotifyCompletion definition

The second one is correct.  To see the = correction, look at RFC 2886, "Section 7.1.11".

> -----Original Message-----
> From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOC= ODES.COM]
> Sent: Tuesday, October 24, 2000 9:22 AM
> To: MEGACO@STANDARDS.NORTELNETWORKS.COM
> Subject: Inconsistency in NotifyCompletion = definition
>
>
> Hi list
>
> I found inconsistency between the = draft-ietf-megaco-merged-01
> document and
> the RFC 2885 document.
>
> In the RFC 2885 (August 2000):
>
>    = notifyCompletion     =3D NotifyCompletionToken = EQUAL ("ON" / "OFF")
>
> In the draft-ietf-megaco-merged-01 (May = 2000):
>
>    = notifyCompletion     =3D NotifyCompletionToken = EQUAL (LBRKT
>          = ;          = notificationReason *(COMMA
> notificationReason) RBRKT
>
>    = notificationReason   =3D ( TimeOutToken / = InterruptByEventToken
>          = ;            = ;           / = InterruptByNewSignalsDescrToken
>          = ;            = ;           / = OtherReasonToken )
>
>
> which one is correct?
>
>
> Best regards
>
> Nurit Shenhar
> AudioCodes Ltd.
> Direct: +972-3-539-4155
> Tel:     = +972-3-539-4000
> Fax:    +972-3-539-4040
> email:  = nurit.shenhar@audiocodes.com
>
> web:    <http://www.audiocodes.com>
>

------_=_NextPart_001_01C03DE0.6225FFC0-- From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 17:30:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id RAA14630 for ; Tue, 24 Oct 2000 17:30:10 -0400 (EDT) Received: from standards (47.234.32.16:1341) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA0B8@standards.nortelnetworks.com>; Tue, 24 Oct 2000 17:13:04 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44806 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 17:13:03 -0400 Received: from slink12.ss7-link.com (mail.ss7-link.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA0B7@standards.nortelnetworks.com>; Tue, 24 Oct 2000 17:13:03 -0400 Received: by SLINK12 with Internet Mail Service (5.5.2650.21) id <4KWBW7NF>; Tue, 24 Oct 2000 17:26:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: Date: Tue, 24 Oct 2000 17:25:56 -0400 Reply-To: Dave Sclarsky Sender: "Media Gateway Control (megaco)" From: Dave Sclarsky Subject: Re: Audit of digit map. X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM I agree with your conclusion, but it raises another question! How should an MG code the eventDM in response to an AuditValue of EventsDescriptor, since eventDM allows either name OR value, but not both? Returning the name could be a problem, since auditing for the name's value might not be reliable (assuming that auditing DigitMapDescriptor would give you the 'new' value). Returning the value could be wrong if the MGC expects to see the name (i.e. it used the name in the activating EventsDescriptor)! DaveS. -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Tuesday, October 24, 2000 1:41 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of digit map. This seems to be one of those cases where the specification isn't clear, so we have a choice. It's absolutely clear to me that the AuditValue of EventsDescriptor should return the active DigitMap. It seems reasonable to me that AuditValue of DigitMapDescriptor should return the new digitMap. In each case, the most recent setting of the descriptor is being returned. > -----Original Message----- > From: Dave Sclarsky [mailto:dsclarsky@SS7-LINK.COM] > Sent: Tuesday, October 24, 2000 12:16 PM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of digit map. > > > If audit value for DigitMap returns the active one, > is there any way for the MGC to audit the new one? > > Wouldn't an audit value on the EventDescriptor return > the 'active' DigitMap? > > DaveS. > > > -----Original Message----- > From: Rosen, Brian [mailto:Brian.Rosen@MARCONI.COM] > Sent: Tuesday, October 17, 2000 8:09 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of digit map. > > > The active one. > > Brian > > > -----Original Message----- > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > Sent: Monday, October 16, 2000 6:23 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Audit of digit map. > > > > > > Digit map with name "abc" is defined on a given termination > > T1. If the digit map > > is active and MGC overwrites the definition of "abc", its > > mentioned in protocol > > that this new definition will be applied only after > > deactivation of the digit > > map. > > If at this momment MGC audits the termination with digit map > > token, which > > definition of the digit map "abc" is sent in response. The > > one that is active or > > the > > one that will be applied after digit map deactivation? > > -Madhubabu > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 18:01:49 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA18236 for ; Tue, 24 Oct 2000 18:01:49 -0400 (EDT) Received: from standards (47.234.32.16:2734) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA0DE@standards.nortelnetworks.com>; Tue, 24 Oct 2000 17:44:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44857 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 17:44:42 -0400 Received: from sj-msg-core-1.cisco.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA0DD@standards.nortelnetworks.com>; Tue, 24 Oct 2000 17:44:42 -0400 Received: from mira-sjc5-1.cisco.com (mira-sjc5-1.cisco.com [171.71.163.15]) by sj-msg-core-1.cisco.com (8.9.3/8.9.1) with ESMTP id PAA19543; Tue, 24 Oct 2000 15:00:10 -0700 (PDT) Received: from cisco.com (dhcp-128-107-133-58.cisco.com [128.107.133.58]) by mira-sjc5-1.cisco.com (Mirapoint) with ESMTP id AHC25891 (AUTH pmelanah); Tue, 24 Oct 2000 15:00:06 -0700 (PDT) X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F60617.5512F59A@cisco.com> Date: Tue, 24 Oct 2000 14:58:47 -0700 Reply-To: Paddu Melanahalli Sender: "Media Gateway Control (megaco)" From: Paddu Melanahalli Organization: NSSU (Cisco's call agent "MGC" development Team), Cisco Systems, Inc Subject: Megaco Call flows To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Hi, Please let me know where I can find them. thanks in advance Paddu -- Enthusiasm You can do anything... if you have Enthusiasm. Enthusiasm is the yeast makes your hopes rise to the stars. Enthusiasm is the sparkle in your eyes. Enthusiasm with it there is accomplishment, without it there are only alibis --- Henry Ford's motto ________________________________________________________ Paddu Melanahalli, Cisco Systems, NSSU Voice:(408)525 5236 Fax: (408)527 1568 Pgr:(408)788 8275 Email: pmelanah@cisco.com ________________________________________________________ From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 18:23:14 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20721 for ; Tue, 24 Oct 2000 18:23:14 -0400 (EDT) Received: from standards (47.234.32.16:4129) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA0F9@standards.nortelnetworks.com>; Tue, 24 Oct 2000 18:06:01 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44892 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 18:06:01 -0400 Received: from qhars002.nortel.com (47.101.112.102:42455) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA0F7@standards.nortelnetworks.com>; Tue, 24 Oct 2000 18:06:00 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Tue, 24 Oct 2000 19:29:15 +0100 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 24 Oct 2000 13:26:40 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRG1SJ>; Tue, 24 Oct 2000 13:26:40 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C60D@zcard00g.ca.nortel.com> Date: Tue, 24 Oct 2000 13:26:31 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Global digitmaps X-To: Nurit Shenhar To: MEGACO@STANDARDS.NORTELNETWORKS.COM I think this description more or less accords with 7.1.14.1. Looking at the later exchange between you and Brian, I would make the following points: The EventDM parameter indicates the digit map to be used for a particular digit map completion event. - the EventDM parameter can give a digit map either by name or by value - if the reference is by name, it may be the name of a global digit map or of one defined specifically on this termination - if there is a naming conflict, the most specific reference applies (your second point). The DigitMap descriptor can be used to specify and name a digit map or to clear one. - the syntax allows three possibilities: -- value only -- name only -- name and value - I believe the "value only" form is a mistake, a historical hangover which no longer has meaning, given that digit map values can be supplied directly by the EventDM parameter - the "name only" form clears a digit descriptor. An interesting question arises when the name is that of a digit map defined globally and NOT defined on the specific termination. We have two ways to interpret this: that the clear attempt has no effect, or that the given global definition can no longer be used for this particular termination. I think it is simplest to say that global definitions can only be cleared by addressing them to the ROOT, but others may have other opinions. Clearing a digit map defined on a specific termination means that subsequent references to the same digit map name will denote the global digit map of that name, if any. - the "name and value" form names a digit map and provides a value for it. If the same name is used for a global digit map, the new definition hides the global digit map at this termination. > -----Original Message----- > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM] > Sent: Tuesday, October 24, 2000 5:59 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Global digitmaps > > > Hi list > > I would like some clarifications about using global digit maps. My > understanding is this: > > 1. When a termination gets a DigitMap descriptor that > contains a name of a > global map and no value, it refers to the global value and > doesn't keep a > local copy of it. > > 2. The termination keeps a local copy of a map if it gets > global name with > a value other than the original one. > > 3. If a global DigitMap is deleted, it is also deleted from all the > terminations using the reference to it. Active map shall be > deleted after > completion. > > Best regards > > Nurit Shenhar > AudioCodes Ltd. > > Direct: +972-3-539-4155 > Tel: +972-3-539-4000 > Fax: +972-3-539-4040 > email: nurit.shenhar@audiocodes.com > > web: > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 18:23:15 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id SAA20730 for ; Tue, 24 Oct 2000 18:23:15 -0400 (EDT) Received: from standards (47.234.32.16:4129) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA102@standards.nortelnetworks.com>; Tue, 24 Oct 2000 18:06:06 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 44903 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 18:06:05 -0400 Received: from qhars002.nortel.com (47.101.112.102:42459) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA101@standards.nortelnetworks.com>; Tue, 24 Oct 2000 18:06:05 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Tue, 24 Oct 2000 19:29:15 +0100 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Tue, 24 Oct 2000 13:33:48 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRG17P>; Tue, 24 Oct 2000 13:33:48 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C60F@zcard00g.ca.nortel.com> Date: Tue, 24 Oct 2000 13:33:38 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Audit of packages X-To: Peter Blatherwick To: MEGACO@STANDARDS.NORTELNETWORKS.COM I'm happy with this. -----Original Message----- From: Blatherwick, Peter [CAR:AT14:EXCH] Sent: Tuesday, October 24, 2000 10:08 AM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages Oops, a few minor glitches in proposed text I sent last night, repaired below. (Stupid fingers!) Also missed that the description does not specifically talk about signals, properties or statistics. Below is still longer than before, but is more specific and complete. Try again: " When packages are extended, the properties, events, signals and statistics defined in the base package can be referred to using either the extended package name or the base package name. By definition, an MG implementing an extended package MUST also implement all aspects of the base package, but it is optional to publish the base package as an allowed interface. For example, if Package A defines event e1, and Package B extends Package A and defines event e2, then B/e1 and B/e2 are events for a termination implementing Package B. If the MG does publish Package A, then Package A would be reported in the PackageDescriptor returned by AuditValue as well as Package B, and events A/e1, B/e1 and B/e2 would be available on the termination. If the MG does not publish A, then only B/e1 and B/e2 would be available. If published through AuditValue, A/e1 and B/e1 are the same event. The same logic also applies to signals, properties and statistics. For the purpose of improved interoperability and backward compatibility, an MG MAY publish all packages supported by its terminations, including base packages from which extended packages are derived. An exception to this is in cases where the base packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own, in which case an MG SHOULD NOT publish the base packages. " Enough fussing, -- Peter -----Original Message----- From: Blatherwick, Peter [CAR:AT14:EXCH] Sent: Monday, October 23, 2000 21:31 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages At risk of further continuing a thread that has already gone on for some time... I agree we should say something, and that Christian's proposed text gives good advice and does no harm. (If its also redundant, that's not really a problem, as long as the advice is good.) Tom's point 2) below leads me to think maybe the support of base packages would be better as a "MAY", as this would allow some Packages to be deprecated over time, and would also allow a vendor to take a really tight focus if they saw fit and not be breaking any rules or advice implied. Having pointed out what MAY be done, and specifically how, vendors would get it right, and I expect almost all would publish base packages as described as an aid to backward compatibility. On a closer read I also notice the word "implement" (in quotes) used, where it is actually not quite correct. In reality, extended Packages MUST implement their base -- that's how it works. However it is optional to publish this for use. How about: " When packages are extended, the properties, events, signals and statistics defined in the base package can be referred to using either the extended package name or the base package name . For example, if Package A defines event e1, and Package B extends Package A, then B/e1 is an event for a termination implementing Package B. By definition, the MG MUST also implement the base Package, but it is optional to publish the base package as an allowed interface. If the MG does publish A, then A would be reported on the Package Descriptor in AuditValue as well as B, and both event A/e1 and B/e1 would be available on a termination. If the MG does not publish A, then only B/e1 would be available. If published through AuditValue, A/e1 and B/e1 are the same event. For the purpose of improved interoperability and backward compatibility, the an MG MAY publish all Packages supported by its Terminations, including base Packages from which extended Packages are derived. An exception to this is in cases where the base packages are expressly designed to be extended by others, not directly controlled, and may not have any function on their own or be nonsensical on their own, in which case the MG SHOULD NOT publish the base Packages. " -- Peter -----Original Message----- From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM ] Sent: Monday, October 23, 2000 16:07 To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages The problem is that an implementer reading the text does not know if he should, or should not, implement the base package under the base package name. Whichever decision he makes, the text is clear on what he should do. The question is should the implementer's guide offer advice on whether the base package should be implemented. Christian suggested that it should, further suggested that the advice should be that the implementer SHOULD (not SHALL) implement the base package, and I agreed with him. I actually had suggested MAY, which I'm still okay with. It seems wrong to make it MUST or SHALL NOT. Whichever way we agree on, I want the text to say something on whether the base package should be implemented. Brian -----Original Message----- From: Tom-PT Taylor [ mailto:taylor@nortelnetworks.com ] Sent: Monday, October 23, 2000 3:47 PM To: Rosen, Brian; megaco@standards.nortelnetworks.com Subject: RE: Audit of packages Do we agree on this logic, which was behind my intervention? (1) An MG publishes the packages it is prepared to understand in incoming messages. (2) An MG does not publish packages which it is not prepared to understand in incoming messages. This is why I felt that the middle part of Christian's text was unnecessary -- the final two sentences already capture the intent. -----Original Message----- From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM ] Sent: Monday, October 23, 2000 3:17 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages We all agree about the requirement to support the properties, events, signals and statistics of the base package under the package name of the new package. What is unclear is what an implementation should do about the base package. Should it support the base package names also? The proposed text recommends that it SHOULD. Is that a problem? I think guidance is warranted. Brian -----Original Message----- From: Tom-PT Taylor [ mailto:taylor@NORTELNETWORKS.COM ] Sent: Monday, October 23, 2000 1:43 PM To: MEGACO@STANDARDS.NORTELNETWORKS.COM Subject: Re: Audit of packages I have a disagreement with the portion of text indicated below and suggest that it be dropped. The ambiguity is about names, not about implementation: the standard leaves no ambiguity about the requirement to support all of the base package. > -----Original Message----- > From: Christian Groves [ mailto:Christian.Groves@ERICSSON.COM ] > Sent: Monday, October 16, 2000 2:14 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Re: Audit of packages > > > G'Day all, > > Below is the text which I propose to put into the implementor's guide. > Its a mix of Brian and Pete's proposed words. I note that I changed > Brian's MAY to Pete's SHOULD. > > 9.5 Package Extension and Referencing > > Description: The current text in H.248 Section 12.1 is > ambiguous about > the usage of package names when referencing properties, > events, signals > and statistics in a base package and an extended package. > Reference: Subject: Re: Audit of packages > Date: Fri, 13 Oct 2000 07:58:12 -0400 > From: "Rosen, Brian" > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: RE: Audit of packages > Date: Fri, 13 Oct 2000 15:15:14 -0500 > From: "Peter Blatherwick" > To: "'Christian Groves'" > CC: megaco@standards.nortelnetworks.com, "'Rosen, Brian'" > > > [Begin Clarification] > Section 12.1 > When packages are extended, the properties, events, signals and > statistics defined in the base package can be referred to using the > extended package name. For example, if Package A defines > event e1, and > Package B extends Package A, then B/e1 is an event for a termination > implementing Package B. [PTT] The MG SHOULD also "implement" the base > Package. If it does, then A would be reported on the Package > Descriptor > in AuditValue as well as B, and event A/e1 would be available on a > termination. If the MG does not implement A, then only B/e1 would be > available. If implemented, [PTT] > A/e1 and B/e1 are the same event. > An MG SHOULD publish all Packages supported by its Terminations, > including base Packages from which extended Packages are derived. An > exception to this is in cases where the base Packages are expressly > designed to be extended by others, not directly controlled, > and may not > have any function on their own or be nonsensical on their own. > [End Clarification] > > Any problems with the text? > > Cheers, Christian > > "Rosen, Brian" wrote: > > > > We probably need some words in the Implementer's Guide, I agree. > > > > How about something like: > > When packages are extended, the properties, events, signals > and statistics > > defined in the base package can be referred to using the > extended package > > name. For example, if Package A defines event e1, and > Package B extends > > Package A, then B/e1 is an event for a termination > implementing Package B. > > The MG MAY also "implement" the base Package. If it does, > then A would > > be reported on the Package Descriptor in AuditValue as well > as B, and > > event A/e1 would be available on a termination. If the MG does not > > implement A, then only B/e1 would be available. Of course, > if implemented, > > A/e1 and B/e1 are the same event. > > > > Brian > > > > > -----Original Message----- > > > From: chassija@hss.hns.com [ mailto:chassija@hss.hns.com ] > > > Sent: Friday, October 13, 2000 12:29 AM > > > To: Rosen, Brian > > > Cc: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Hello Brian, > > > > > > If this is the case as you are pointing out, then it should > > > be clearly mentioned > > > in the protocol. Because the protocol says only the following > > > --- in context of > > > Package B extending Package A -- > > > > > > Sec 12.1.1 - " When a package > > > extends another package it shall only add additional > Properties, > > > Events, Signals, Statistics and new possible values for an > > > existing parameter described in the original > package. An extended > > > package shall not redefine or overload a name defined in the > > > original package." > > > > > > This seems to imply that Package B has to support all the > > > events supported on > > > Package A...... > > > > > > What is your opinion on this.... > > > Chanchal.... > > > > > > > > > > > > > > > > > > "Rosen, Brian" on 10/13/2000 01:32:21 AM > > > > > > Please respond to "Rosen, Brian" > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > cc: (bcc: Chanchal Hassija/HSS) > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > I don't think there is any change to the base understanding. > > > > > > Suppose Package A defines Event e1 > > > Suppose Package B extends Package A. > > > > > > Now, you can talk about A/e1 or B/e1. > > > > > > If you "expose" package A, then you would include A in the > > > list of packages reported on an audit, and A/e1 as well as B/e1 > > > would be legal. > > > > > > If you don't expose package A, then you can only use B/e1. > > > > > > In both cases the extended package inherits the behavior of the > > > base package. > > > > > > Brian > > > > > > > -----Original Message----- > > > > From: Sachin Mittal [ mailto:samittal@HSS.HNS.COM ] > > > > Sent: Thursday, October 12, 2000 11:55 AM > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Subject: Re: Audit of packages > > > > > > > > > > > > The idea of supporting extending package but not supporting > > > > base package > > > > is not the basic philosophy of extension of packages > which says that > > > > extended package inherits the behaviour of base package. > > > > > > > > So do we need to change the basic understanding of package > > > extensions. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Dave Sclarsky on 10/12/2000 07:44:17 PM > > > > > > > > Please respond to Dave Sclarsky > > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > cc: (bcc: Sachin Mittal/HSS) > > > > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > > > > > > What do you think about the case where an MG can support pkg2 > > > > but NOT pkg3? > > > > > > > > Take the case of the Tone Detection Package and the DTMF > > > > Detection Package > > > > that extends it. There are most certainly 'intelligent' > > > > devices that are > > > > capable of reporting DTMF digits, but do not offer the > > > > granularity to report > > > > 'Start tone' or 'End tone' detected. > > > > > > > > I would have assumed that an MG with such a device would > > > > (should!) publish > > > > dd but not tonedet, because it really cannot notify > tonedet/std or > > > > tonedet/etd. > > > > > > > > DaveS. > > > > > > > > > > > > -----Original Message----- > > > > > From: Christian Groves [ mailto:Christian.Groves@ERICSSON.COM ] > > > > > Sent: Wednesday, October 11, 2000 10:25 PM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > > > > > > Perhaps we "should" say "SHALL", I can't think of a case of > > > > when it is > > > > > inappropriate and we have the rule saying that you can address > > > > > properties by pkg3. > > > > > > > > > > But, I'm happy with Should if you can provide the > text when it is > > > > > inappropriate. > > > > > > > > > > Cheers, Christian > > > > > > > > > > Peter Blatherwick wrote: > > > > -------------------------- > > > > > > > > > > I agree in general, since "extends" basically means > > > "clone the base > > > > > package and add some more functionality" (no subsetting, > > > over-riding > > > > > etc allowed). In example below pkg2 by definition > > > implements pkg3. > > > > > (Not the case with re-versioning of Packages though!) > > > > > > > > > > One clarification however. It does not always make sense > > > for a base > > > > > package to be published as implemented by an MG. There > > > are examples > > > > > where the base package is defined such that it acts > similar to a > > > > > virtual class, and has no function on its own, simply defining > > > > > interface for one or more derived packages. Annex E > ToneGen and > > > > > ToneDet as well as a few packages in Annex G are examples. > > > > Therefore, > > > > > implementer's guide MUST not make a hard and fast rule on > > > this, but > > > > > SHOULD say "SHOULD" with some words to describe where its > > > > > inappropriate. > > > > > > > > > > -- Peter > > > > > > > > > > -----Original Message----- > > > > > From: Rosen, Brian [ mailto:Brian.Rosen@MARCONI.COM ] > > > > > Sent: Monday, October 09, 2000 16:03 > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Re: Audit of packages > > > > > > > > > > We've been around this and basically, it is up to the MG. > > > > > It does not HAVE to report pkg3, but it could. Maybe SHOULD > > > > > is a good word, and I wonder if text to that effect > > > > > should go in the implementor's guide? > > > > > > > > > > Brian > > > > > > > > > > -----Original Message----- > > > > > From: Sachin Mittal [ mailto:samittal@HSS.HNS.COM ] > > > > > Sent: Monday, October 09, 2000 5:12 AM > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Subject: Audit of packages > > > > > > > > > > Say a termination abc implements the following packages: > > > > > 1. pkg1 > > > > > 2. pkg2 > > > > > where pkg2 extends pkg3 and pkg1 doesn't extend any > other package > > > > > > > > > > If this termination is audited for packages implemented on it, > > > > > should the reply include pkg3 with pkg1 and pkg2 (base > > > package names > > > > > are included) > > > > > > > > > > Sachin > > > > > > > > > > > > > > > > > > > > > > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 19:14:38 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id TAA26870 for ; Tue, 24 Oct 2000 19:14:38 -0400 (EDT) Received: from standards (47.234.32.16:3973) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA23B@standards.nortelnetworks.com>; Tue, 24 Oct 2000 18:57:00 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45261 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 18:57:00 -0400 Received: from mailgate.pit.comms.marconi.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA23A@standards.nortelnetworks.com>; Tue, 24 Oct 2000 18:57:00 -0400 Received: from mailman.pit.comms.marconi.com (mailman.pit.comms.marconi.com [169.144.2.12]) by mailgate.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA03051; Tue, 24 Oct 2000 19:12:26 -0400 (EDT) Received: from whq-msgrtr-01.fore.com (whq-msgrtr-01.pit.comms.marconi.com [169.144.2.221]) by mailman.pit.comms.marconi.com (8.9.3/8.9.3) with ESMTP id TAA07649; Tue, 24 Oct 2000 19:12:27 -0400 (EDT) Received: by WHQ-MSGRTR-01 with Internet Mail Service (5.5.2650.21) id <46CR4ZM8>; Tue, 24 Oct 2000 19:12:09 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <4FBEA8857476D311A03300204840E1CF01A6E8B9@whq-msgusr-02.pit.comms.marconi.com> Date: Tue, 24 Oct 2000 19:12:27 -0400 Reply-To: "Rosen, Brian" Sender: "Media Gateway Control (megaco)" From: "Rosen, Brian" Subject: Re: Global digitmaps X-To: Tom-PT Taylor To: MEGACO@STANDARDS.NORTELNETWORKS.COM > - I believe the "value only" form is a mistake, a historical hangover >which no longer has meaning, given that digit map values can be supplied >directly by the EventDM parameter I agree, this is a mistake -- Implementer's Guide material?? > - the "name only" form clears a digit descriptor. An interesting question >arises when the name is that of a digit map defined globally and NOT defined >on the specific termination. We have two ways to interpret this: that the >clear attempt has no effect, or that the given global definition can no >longer be used for this particular termination. I think it is simplest to >say that global definitions can only be cleared by addressing them to the >ROOT, but others may have other opinions. I agree with you -- although you could interpret the request as clear a local digitmap with the same name as a global one Brian > -----Original Message----- > From: Nurit Shenhar [mailto:nurit.shenhar@AUDIOCODES.COM] > Sent: Tuesday, October 24, 2000 5:59 AM > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > Subject: Global digitmaps > > > Hi list > > I would like some clarifications about using global digit maps. My > understanding is this: > > 1. When a termination gets a DigitMap descriptor that > contains a name of a > global map and no value, it refers to the global value and > doesn't keep a > local copy of it. > > 2. The termination keeps a local copy of a map if it gets > global name with > a value other than the original one. > > 3. If a global DigitMap is deleted, it is also deleted from all the > terminations using the reference to it. Active map shall be > deleted after > completion. > > Best regards > > Nurit Shenhar > AudioCodes Ltd. > > Direct: +972-3-539-4155 > Tel: +972-3-539-4000 > Fax: +972-3-539-4040 > email: nurit.shenhar@audiocodes.com > > web: > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 21:35:10 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id VAA13742 for ; Tue, 24 Oct 2000 21:35:10 -0400 (EDT) Received: from standards (47.234.32.16:3573) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA2DF@standards.nortelnetworks.com>; Tue, 24 Oct 2000 21:18:09 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45415 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 21:18:09 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA2B1@standards.nortelnetworks.com>; Tue, 24 Oct 2000 21:08:09 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9P1Nct29124 for ; Wed, 25 Oct 2000 03:23:38 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id DAA08575 for ; Wed, 25 Oct 2000 03:23:37 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id DAA05266 for ; Wed, 25 Oct 2000 03:23:35 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F63613.B512BB90@ericsson.com> Date: Wed, 25 Oct 2000 12:23:31 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Mismatch between ASN1 and ABNF for [w-] To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, I've been made aware that there is an inconsistency between the ABNF and the ASN1 on the usage of the [w-]. Chapter 6.2.2 allows wildcard response on all commands. It mentions that it is useful for audit. The ASN1 allows you to request a wildcard response on all commands [w-]. The ABNF only has it at: auditRequest = ["W-"] (AuditValueToken / AuditCapToken ) EQUAL TerminationID LBRKT auditDescriptor RBRKT I propose updating the line below to allow for wildcard response on all commands: From: commandRequestList= ["O-"] commandRequest *(COMMA ["O-"]commandRequest) to: commandRequestList= ["O-"]["W-"] commandRequest *(COMMA ["O-"]["W-"]commandRequest) and to delete the ["W-"] from the audit request. Agreeable? Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 23:32:39 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA28211 for ; Tue, 24 Oct 2000 23:32:39 -0400 (EDT) Received: from standards (47.234.32.16:2503) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA359@standards.nortelnetworks.com>; Tue, 24 Oct 2000 23:15:29 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45631 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 23:15:29 -0400 Received: from penguin-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA353@standards.nortelnetworks.com>; Tue, 24 Oct 2000 23:05:29 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id e9P3KwZ18465 for ; Wed, 25 Oct 2000 05:20:58 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id FAA09967 for ; Wed, 25 Oct 2000 05:20:57 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA05729 for ; Wed, 25 Oct 2000 05:20:55 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F65191.F113B115@ericsson.com> Date: Wed, 25 Oct 2000 14:20:49 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Additional MTP3 formats To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day all, It was noted previously on the list that the MTP MID needed to be updated to allow for American and Japanese variants. Below is a proposed change for the implementors' guide. For the ASN.1 change: From: mtpAddress OCTET STRING(SIZE(2)), -- Addressing structure of mtpAddress: -- 15 0 -- | PC | NI | -- 14 bits 2 bits to: mtpAddress OCTET STRING, -- Addressing structure of mtpAddress: -- 15 0 -- | PC | NI | -- 24-14 bits 2 bits -- NOTE: 14 bits is defined for international use. -- Two national options exist where the point code is 16 or 24 bits. For the ABNF change: From: ; An mtp address is two octets long mtpAddress = MTPToken LBRKT octetString RBRKT to: ; Addressing structure of mtpAddress: ; 15 0 ; | PC | NI | ; 24-14 bits 2 bits ; NOTE: 14 bits is defined for international use. ; Two national options exist where the point code is 16 or 24 bits. mtpAddress = MTPToken LBRKT octetString RBRKT Is this OK? Cheers, Christian From owner-megaco@STANDARDS.NORTELNETWORKS.COM Tue Oct 24 23:42:33 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id XAA29311 for ; Tue, 24 Oct 2000 23:42:32 -0400 (EDT) Received: from standards (47.234.32.16:2503) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA377@standards.nortelnetworks.com>; Tue, 24 Oct 2000 23:25:23 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45638 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Tue, 24 Oct 2000 23:25:23 -0400 Received: from albatross-ext.wise.edt.ericsson.se by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA358@standards.nortelnetworks.com>; Tue, 24 Oct 2000 23:15:21 -0400 Received: from al.edt.ericsson.se (elb1.al.edt.ericsson.se [136.225.252.11]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id e9P3Unt03827; Wed, 25 Oct 2000 05:30:49 +0200 (MEST) Received: from elb4.al.edt.ericsson.se (elb4 [136.225.252.20]) by al.edt.ericsson.se (8.8.8+Sun/8.8.8/eri-dom-1.1) with ESMTP id FAA10122; Wed, 25 Oct 2000 05:30:48 +0200 (MET DST) Received: from ericsson.com (mc2dh44.epa.ericsson.se [146.11.87.44]) by elb4.al.edt.ericsson.se (8.9.3+Sun/8.9.1/client-1.0) with ESMTP id FAA05785; Wed, 25 Oct 2000 05:30:44 +0200 (MET DST) X-Mailer: Mozilla 4.72 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 References: <4FBEA8857476D311A03300204840E1CF01A6E802@whq-msgusr-02.pit.comms.marconi.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F653DD.55F6056C@ericsson.com> Date: Wed, 25 Oct 2000 14:30:37 +1100 Reply-To: Christian Groves Sender: "Media Gateway Control (megaco)" From: Christian Groves Subject: Signal on Root - Re: heart beat message in the megaco protocol X-To: "Rosen, Brian" To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit G'Day, I think Brian has given an alternative when you need to send the heart beat between an MGC and MG but not the case where you need the MG to send a heartbeat to other devices in a network. To me a signal on the root termination of a MG seems to be a good idea. ie. Term=root,Signal=heartbeat. The MG would then use the appropriate mechanism for it. Properties, Events, statistics are valid for Root. The text says that signals are not valid for root but can any one give a concrete reason why this is so? Cheers, Christian "Rosen, Brian" wrote: > > You can construct a NOP ServiceChange sent from MG to MGC. You can > even send an empty NOTIFY I think. Ping is not a really good heartbeat. > > Brian > > > -----Original Message----- > > From: Susumu YAMAMOTO [mailto:yamamoto.susumu@lab.ntt.co.jp] > > Sent: Tuesday, October 17, 2000 2:01 AM > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > Subject: Re: heart beat message in the megaco protocol > > > > > > Hi all, > > > > Please let me correct, if I am wrong. > > > > I think heart beat messages are sent rather from MG than from > > MGC, because > > in the case of fault of network or MGC only MG can trigger > > the failover > > operation > > to change the MGC and restore the service. > > > > I would find some mechanism outside of the H248 for heart > > beat message from MG, > > it may be Ping or something. > > (MGC can audit as heart beat messages as below, but there is > > no mechanism for > > MG to send in the H.248.) > > > > ... and any other implementation is there ? > > > > > > >In my current implementation, I am using audits as a means > > of acheiving > > >heart beats. The MGC audits the gateways periodically > > requesting connection > > >ids. This way, the MGC can also say if it is out of > > sequence perhaps, with > > >the MG (say, the MG returns a connection id, and the MGC > > does not have one > > >for that endpoint). > > > > > >----- Original Message ----- > > >From: "Christian Groves" > > >To: > > >Sent: Sunday, October 15, 2000 10:45 PM > > >Subject: Re: heart beat message in the megaco protocol > > > > > > > > > > Hello Susumu San, > > > > > > > > Currently there is no mechanism for this in H.248. I > > thought one way to > > > > achieve this would be to send a signal on the Root > > Termination of the MG > > > > that would be an on/off signal which would generate a > > heartbeart message > > > > periodically. But unfortunately we can't a signal (events are OK > > > > though)on the root termination. This may be something we > > want to change. > > > > > > > > I guess you could always provision some mechanism outside > > of H.248 also. > > > > > > > > Cheers, Christian > > > > > > > > Susumu YAMAMOTO wrote: > > > > > > > > > > Hi all, > > > > > > > > > > Is there a heart beat message from MG to MGC in the megaco > > > > > protocol? > > > > > > > > > > If not, how do you think about a heart beat message? > > > > > > > > > > I think MG always should be able to detect a failure of MGC and > > > > > restore the service by failover method, because the case of > > > > > restart of MGC, MGC may lost which MG is now in service and > > > > > cannot send a handoff message properly. > > > > > > > > > > Thanks in advance, > > > > > -*-*-* > > > > > YAMAMOTO SUSUMU > > > > > Mega-media Network Systems Project > > > > > NTT Network Service Systems Laboratories > > > > > mailto: yamamoto.susumu@lab.ntt.co.jp > > > > > TEL:+81 422 59 2744 FAX:+81 422 37 7467 > > > > -*-*-* > > SUSUMU YAMAMOTO > > Mega-media Network Systems Project > > NTT Network Service Systems Laboratories > > mailto: yamamoto.susumu@lab.ntt.co.jp > > TEL:+81 422 59 2744 FAX:+81 422 37 7467 > > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 25 02:57:03 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id CAA28801 for ; Wed, 25 Oct 2000 02:57:02 -0400 (EDT) Received: from standards (47.234.32.16:2321) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA423@standards.nortelnetworks.com>; Wed, 25 Oct 2000 2:39:51 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45913 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 25 Oct 2000 02:39:51 -0400 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA422@standards.nortelnetworks.com>; Wed, 25 Oct 2000 2:39:50 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id CAA29184 for ; Wed, 25 Oct 2000 02:55:21 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id CAA29173 for ; Wed, 25 Oct 2000 02:55:20 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id IAA04910; Wed, 25 Oct 2000 08:55:03 +0200 (MET DST) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <98388C05D464D111B61800805F150416012AFA74@p-ibis.issy.cnet.fr> Content-Type: text/plain; charset=iso-8859-1 Message-ID: <39F68383.5DBA7224@lucent.com> Date: Wed, 25 Oct 2000 08:53:55 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Digit map completion event and other events. To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id CAA28801 Bruno, If an IP is involved, couldn't it perform both functions (so the MG is not involved in collecting the called number at all)? Cheers, John CHATRAS Bruno FTRD/DAC/ISS wrote: > > John, > > > > > Bruno, > > > > I wonder how the example that you give works. In particular, if the > > user speaks, does the MGC then learn the dialed number from > > the external IP? > > Yes, you need a direct control interface between the MGC and the IP > (possibly tunnelled through the MG), which is outside the scope of MEGACO. > > > This looks awkward to me. > > > > An architecture where the MGC activates the digit map on a Termination > > on the MG, and receives the digit string from that MG, whether it > > collected DTMF or used an external device to process user > > speech, seems > > preferrable to me. The MGC then doesn't have to instruct two > > devices if > > it wants to get one dialled number. > > I agree that this is a better target architecture. However not all MGs will > be able to do that, while some Call Servers (MGC)(e.g; those whose software > is derived from an existing PSTN switch) have already the sort of control > interface I mentioned above. Another difficulty for the MG is that the > selection of the external device may depend on the calling party number. > > > > > Cheers, > > > > John > > > > CHATRAS Bruno FTRD/DAC/ISS wrote: > > > > > > Hi, > > > > > > A scenario where you want individual digits to be notified, > > *and* processed > > > through a digit map at the same time might be a Voice > > Activated Dialling > > > service where the calling party can either dial or speak. > > > > > > When the calling party goes off-hook, the MGC creates a > > context with two > > > terminations. The first termination models the access to > > the calling line; > > > while the second termination models the access to an > > external Intelligent > > > Peripheral (with voice recognition capabilities). If the > > user prefers to > > > dial rather than speak, it might be useful for the MGC to > > be aware of this > > > decision as soon as possible, in order to release the > > external peripheral. > > > Reporting the first dialled digit as an individual event > > would make this > > > easy. In parallel, this digit and the subsequent digits > > would still need to > > > be processed through a digit map according to the dialling > > plan in force. > > > > > > > -----Message d'origine----- > > > > De : John Segers [mailto:jsegers@LUCENT.COM] > > > > Envoyé : samedi 21 octobre 2000 16:19 > > > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > Objet : Re: Digit map completion event and other events. > > > > > > > > > > > > Hi, > > > > > > > > I agree that Brian's viewpoint is valid, but Madhu has a > > > > point: section > > > > 7.1.14.7 does say that while a digit map is active, the > > > > individual digit > > > > events are not reported. > > > > > > > > In my mind there are two things that we can do: > > > > - change 7.14.1.7 to be more specific > > > > - drop the clause from 7.1.14.8 that says that individual > > events are > > > > notified if they are included in the events descriptor as > > well (i.e. > > > > together with the digit map completion event). > > > > > > > > Before making a choice, can anyone think of a scenario > > where you want > > > > individual digits to be notified, *and* processed through a > > > > digit map at > > > > the same time? > > > > > > > > Cheers, > > > > > > > > John > > > > > > > > > Date: Tue, 17 Oct 2000 08:07:28 -0400 > > > > > Reply-To: "Rosen, Brian" > > > > > Sender: "Media Gateway Control (megaco)" > > > > > > > > > > From: "Rosen, Brian" > > > > > Subject: Re: Digit map completion event and other events. > > > > > X-To: "bmbabu@HSS.HNS.COM" > > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > > > > > I don't understand the problem. > > > > > > > > > > If you just have a digitmap, you don't get NOTIFYied of > > individual > > > > > events. If you enable them, you do get the NOTIFYs, > > and they are > > > > > used by a digitMap, if enabled. So there are two > > > > independent consumers > > > > > of DTMF digits, they can be enabled separately, or > > > > together, MGC choice. > > > > > > > > > > Brian > > > > > > > > > > > -----Original Message----- > > > > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > > > > Sent: Monday, October 16, 2000 6:20 AM > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > Subject: Digit map completion event and other events. > > > > > > > > > > > > > > > > > > In section 7.1.14.7 its mentioned that "While the digit map > > > > > > is activated, detection is enabled for all > > > > > > events defined in the package containing the > > > > > > specified digit map completion event" > > > > > > and "the events in the package containing the specified > > > > > > digit map completion event other than the > > > > > > completion event itself are not individually > > > > > > notified". > > > > > > > > > > > > In next section 7.1.14.8 if item identifier is wildcard, then > > > > > > its mentioned that > > > > > > "Regardless of whether a digit map is activated, > > > > > > if the package also contains the digit events > > > > > > themselves, this form of event specification > > > > > > will cause the individual events to be > > > > > > reported to the MGC as they are detected" > > > > > > > > > > > > These two sections seems to be in conflict with each > > other. what > > > > > > should be the MG behaviour. > > > > > > > > > > > > -Madhubabu > > > > > > > > > > > > > > -- > > > > John Segers email: > > jsegers@lucent.com > > > > Lucent Technologies > > Room HE 303 > > > > Dept. Forward Looking Work phone: > > +31 35 687 4724 > > > > P.O. Box 18, 1270 AA Huizen fax: > > +31 35 687 5954 > > > > > > > > -- > > John Segers email: jsegers@lucent.com > > Lucent Technologies Room HE 303 > > Dept. Forward Looking Work phone: +31 35 687 4724 > > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > > -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 25 03:39:50 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id DAA08049 for ; Wed, 25 Oct 2000 03:39:49 -0400 (EDT) Received: from standards (47.234.32.16:3742) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA44A@standards.nortelnetworks.com>; Wed, 25 Oct 2000 3:22:43 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 45953 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 25 Oct 2000 03:22:43 -0400 Received: from p-mail2.cnet.fr (p-mail2.rd.francetelecom.fr) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA441@standards.nortelnetworks.com>; Wed, 25 Oct 2000 3:12:41 -0400 Received: by p-voyageur.issy.cnet.fr with Internet Mail Service (5.5.2650.21) id ; Wed, 25 Oct 2000 09:19:47 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <98388C05D464D111B61800805F150416012AFA91@p-ibis.issy.cnet.fr> Date: Wed, 25 Oct 2000 09:19:40 +0200 Reply-To: CHATRAS Bruno FTRD/DAC/ISS Sender: "Media Gateway Control (megaco)" From: CHATRAS Bruno FTRD/DAC/ISS Subject: Re: Digit map completion event and other events. X-To: John Segers To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by ietf.org id DAA08049 > -----Message d'origine----- > De : John Segers [mailto:jsegers@LUCENT.COM] > Envoyé : mercredi 25 octobre 2000 08:54 > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > Objet : Re: Digit map completion event and other events. > > > Bruno, > > If an IP is involved, couldn't it perform both functions (so the MG is > not involved in collecting the called number at all)? John, Yes, this is one possible option. However it has some impact on the dimensioning of the IP (number of incoming trunks and DTMF receivers). Moreover, there is a risk that the first digit is dialled before the connection to the external IP is actually switched-through. This is generally considered unacceptable for emergency calls. One solution could be to have the IP playing the dial tone (instead of the MG). However some studies have shown that if the dial tone were not immediately available, a large number of people would go on-hook or would start dialling anyway. > > Cheers, > > John > > CHATRAS Bruno FTRD/DAC/ISS wrote: > > > > John, > > > > > > > > Bruno, > > > > > > I wonder how the example that you give works. In > particular, if the > > > user speaks, does the MGC then learn the dialed number from > > > the external IP? > > > > Yes, you need a direct control interface between the MGC and the IP > > (possibly tunnelled through the MG), which is outside the > scope of MEGACO. > > > > > This looks awkward to me. > > > > > > An architecture where the MGC activates the digit map on > a Termination > > > on the MG, and receives the digit string from that MG, whether it > > > collected DTMF or used an external device to process user > > > speech, seems > > > preferrable to me. The MGC then doesn't have to instruct two > > > devices if > > > it wants to get one dialled number. > > > > I agree that this is a better target architecture. However > not all MGs will > > be able to do that, while some Call Servers (MGC)(e.g; > those whose software > > is derived from an existing PSTN switch) have already the > sort of control > > interface I mentioned above. Another difficulty for the MG > is that the > > selection of the external device may depend on the calling > party number. > > > > > > > > Cheers, > > > > > > John > > > > > > CHATRAS Bruno FTRD/DAC/ISS wrote: > > > > > > > > Hi, > > > > > > > > A scenario where you want individual digits to be notified, > > > *and* processed > > > > through a digit map at the same time might be a Voice > > > Activated Dialling > > > > service where the calling party can either dial or speak. > > > > > > > > When the calling party goes off-hook, the MGC creates a > > > context with two > > > > terminations. The first termination models the access to > > > the calling line; > > > > while the second termination models the access to an > > > external Intelligent > > > > Peripheral (with voice recognition capabilities). If the > > > user prefers to > > > > dial rather than speak, it might be useful for the MGC to > > > be aware of this > > > > decision as soon as possible, in order to release the > > > external peripheral. > > > > Reporting the first dialled digit as an individual event > > > would make this > > > > easy. In parallel, this digit and the subsequent digits > > > would still need to > > > > be processed through a digit map according to the dialling > > > plan in force. > > > > > > > > > -----Message d'origine----- > > > > > De : John Segers [mailto:jsegers@LUCENT.COM] > > > > > Envoyé : samedi 21 octobre 2000 16:19 > > > > > À : MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > Objet : Re: Digit map completion event and other events. > > > > > > > > > > > > > > > Hi, > > > > > > > > > > I agree that Brian's viewpoint is valid, but Madhu has a > > > > > point: section > > > > > 7.1.14.7 does say that while a digit map is active, the > > > > > individual digit > > > > > events are not reported. > > > > > > > > > > In my mind there are two things that we can do: > > > > > - change 7.14.1.7 to be more specific > > > > > - drop the clause from 7.1.14.8 that says that individual > > > events are > > > > > notified if they are included in the events descriptor as > > > well (i.e. > > > > > together with the digit map completion event). > > > > > > > > > > Before making a choice, can anyone think of a scenario > > > where you want > > > > > individual digits to be notified, *and* processed through a > > > > > digit map at > > > > > the same time? > > > > > > > > > > Cheers, > > > > > > > > > > John > > > > > > > > > > > Date: Tue, 17 Oct 2000 08:07:28 -0400 > > > > > > Reply-To: "Rosen, Brian" > > > > > > Sender: "Media Gateway Control (megaco)" > > > > > > > > > > > > From: "Rosen, Brian" > > > > > > Subject: Re: Digit map completion event and > other events. > > > > > > X-To: "bmbabu@HSS.HNS.COM" > > > > > > Content-Type: text/plain; charset="iso-8859-1" > > > > > > > > > > > > I don't understand the problem. > > > > > > > > > > > > If you just have a digitmap, you don't get NOTIFYied of > > > individual > > > > > > events. If you enable them, you do get the NOTIFYs, > > > and they are > > > > > > used by a digitMap, if enabled. So there are two > > > > > independent consumers > > > > > > of DTMF digits, they can be enabled separately, or > > > > > together, MGC choice. > > > > > > > > > > > > Brian > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Madhu Babu [mailto:bmbabu@HSS.HNS.COM] > > > > > > > Sent: Monday, October 16, 2000 6:20 AM > > > > > > > To: MEGACO@STANDARDS.NORTELNETWORKS.COM > > > > > > > Subject: Digit map completion event and other events. > > > > > > > > > > > > > > > > > > > > > In section 7.1.14.7 its mentioned that "While > the digit map > > > > > > > is activated, detection is enabled for all > > > > > > > events defined in the package containing the > > > > > > > specified digit map completion event" > > > > > > > and "the events in the package containing the specified > > > > > > > digit map completion event other than the > > > > > > > completion event itself are not individually > > > > > > > notified". > > > > > > > > > > > > > > In next section 7.1.14.8 if item identifier is > wildcard, then > > > > > > > its mentioned that > > > > > > > "Regardless of whether a digit map is activated, > > > > > > > if the package also contains the digit events > > > > > > > themselves, this form of event specification > > > > > > > will cause the individual events to be > > > > > > > reported to the MGC as they are detected" > > > > > > > > > > > > > > These two sections seems to be in conflict with each > > > other. what > > > > > > > should be the MG behaviour. > > > > > > > > > > > > > > -Madhubabu > > > > > > > > > > > > > > > > > -- > > > > > John Segers email: > > > jsegers@lucent.com > > > > > Lucent Technologies > > > Room HE 303 > > > > > Dept. Forward Looking Work phone: > > > +31 35 687 4724 > > > > > P.O. Box 18, 1270 AA Huizen fax: > > > +31 35 687 5954 > > > > > > > > > > > -- > > > John Segers email: > jsegers@lucent.com > > > Lucent Technologies > Room HE 303 > > > Dept. Forward Looking Work phone: > +31 35 687 4724 > > > P.O. Box 18, 1270 AA Huizen fax: > +31 35 687 5954 > > > > > -- > John Segers email: jsegers@lucent.com > Lucent Technologies Room HE 303 > Dept. Forward Looking Work phone: +31 35 687 4724 > P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 > From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 25 05:35:23 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id FAA10551 for ; Wed, 25 Oct 2000 05:35:22 -0400 (EDT) Received: from standards (47.234.32.16:1595) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA48F@standards.nortelnetworks.com>; Wed, 25 Oct 2000 5:17:59 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46052 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 25 Oct 2000 05:17:59 -0400 Received: from hoemlsrv.firewall.lucent.com (hoemail1.lucent.com) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA48E@standards.nortelnetworks.com>; Wed, 25 Oct 2000 5:17:59 -0400 Received: from hoemlsrv.firewall.lucent.com (localhost [127.0.0.1]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA01295 for ; Wed, 25 Oct 2000 05:33:29 -0400 (EDT) Received: from nlmail.nl.lucent.com (h135-85-78-211.lucent.com [135.85.78.211]) by hoemlsrv.firewall.lucent.com (Pro-8.9.3/8.9.3) with ESMTP id FAA01271 for ; Wed, 25 Oct 2000 05:33:29 -0400 (EDT) Received: from lucent.com (hzsgp35.nl.lucent.com [135.85.117.145]) by nlmail.nl.lucent.com (8.8.8+Sun/EMS-1.5 sol2) id LAA09600; Wed, 25 Oct 2000 11:33:16 +0200 (MET DST) X-Mailer: Mozilla 4.75 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 References: <39F65191.F113B115@ericsson.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <39F6A899.284B95AB@lucent.com> Date: Wed, 25 Oct 2000 11:32:09 +0200 Reply-To: John Segers Sender: "Media Gateway Control (megaco)" From: John Segers Organization: Lucent Technologies Subject: Re: Additional MTP3 formats To: MEGACO@STANDARDS.NORTELNETWORKS.COM Content-Transfer-Encoding: 7bit Christian, You'd have to leave out the '15' below. Also, it should be specified how the PC+NI is aligned in the string of octets if their total size is not an integral multiple of 8 bits. Cheers, John > mtpAddress OCTET STRING, > -- Addressing structure of mtpAddress: > -- 15 0 > -- | PC | NI | > -- 24-14 bits 2 bits > -- NOTE: 14 bits is defined for international use. > -- Two national options exist where the point code is 16 or 24 bits. > > For the ABNF change: > > From: > ; An mtp address is two octets long > mtpAddress = MTPToken LBRKT octetString RBRKT > > to: > ; Addressing structure of mtpAddress: > ; 15 0 > ; | PC | NI | > ; 24-14 bits 2 bits > ; NOTE: 14 bits is defined for international use. > ; Two national options exist where the point code is 16 or 24 bits. > mtpAddress = MTPToken LBRKT octetString RBRKT -- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954 From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 25 07:02:59 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id HAA08653 for ; Wed, 25 Oct 2000 07:02:58 -0400 (EDT) Received: from standards (47.234.32.16:3322) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA544@standards.nortelnetworks.com>; Wed, 25 Oct 2000 6:45:54 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46194 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 25 Oct 2000 06:45:54 -0400 Received: from portal.east.saic.com by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA504@standards.nortelnetworks.com>; Wed, 25 Oct 2000 6:35:53 -0400 Received: from mclmx.saic.com by portal.east.saic.com via smtpd (for h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) with SMTP; 25 Oct 2000 10:51:24 UT Received: from [149.8.64.19] by mclmx.mail.saic.com; Wed, 25 Oct 2000 06:51:15 -0400 Received: from mcl-its-exbh01.mail.saic.com ([149.8.64.11]) by 149.8.64.19 (Norton AntiVirus for Internet Email Gateways 1.0) ; Wed, 25 Oct 2000 10:47:27 0000 (GMT) Received: by mcl-its-exbh01.saic.com with Internet Mail Service (5.5.2650.21) id <4SHA9C7F>; Wed, 25 Oct 2000 06:51:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Message-ID: <6B3D994408CBD11182B300805F15FCBB0202FA73@us-mclean-03.mail.saic.com> Date: Wed, 25 Oct 2000 06:49:37 -0400 Reply-To: "Erney, Kenneth R." Sender: "Media Gateway Control (megaco)" From: "Erney, Kenneth R." Subject: Mailing List Options To: MEGACO@STANDARDS.NORTELNETWORKS.COM Please provide instructions on how I can change me mailing list options...thanks Regards, Ken 703-676-2361 kenneth.r.erney@saic.com From owner-megaco@STANDARDS.NORTELNETWORKS.COM Wed Oct 25 09:02:44 2000 Received: from standards.nortelnetworks.com (h16s32a234n47.user.nortelnetworks.com [47.234.32.16]) by ietf.org (8.9.1a/8.9.1a) with SMTP id JAA17289 for ; Wed, 25 Oct 2000 09:02:43 -0400 (EDT) Received: from standards (47.234.32.16:1484) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA60C@standards.nortelnetworks.com>; Wed, 25 Oct 2000 8:45:40 -0400 Received: from STANDARDS.NORTELNETWORKS.COM by STANDARDS.NORTELNETWORKS.COM (LISTSERV-TCP/IP release 1.8d) with spool id 46527 for MEGACO@STANDARDS.NORTELNETWORKS.COM; Wed, 25 Oct 2000 08:45:39 -0400 Received: from qhars002.nortel.com (47.101.112.102:51590) by standards.nortelnetworks.com (LSMTP for Windows NT v1.1b) with SMTP id <0.FFBAA60B@standards.nortelnetworks.com>; Wed, 25 Oct 2000 8:45:39 -0400 Received: from zrtps06s.us.nortel.com by qhars002.nortel.com; Wed, 25 Oct 2000 14:00:56 +0100 Received: from zrtpd004.us.nortel.com by zrtps06s.us.nortel.com; Wed, 25 Oct 2000 08:52:05 -0400 Received: by zrtpd004.us.nortel.com with Internet Mail Service (5.5.2652.35) id <44WRGYHX>; Wed, 25 Oct 2000 08:52:05 -0400 X-Mailer: Internet Mail Service (5.5.2652.35) X-Orig: Message-ID: <28560036253BD41191A10000F8BCBD110250C61D@zcard00g.ca.nortel.com> Date: Wed, 25 Oct 2000 08:52:03 -0400 Reply-To: Tom-PT Taylor Sender: "Media Gateway Control (megaco)" From: Tom-PT Taylor Subject: Re: Mailing List Options X-To: "Erney, Kenneth R." To: MEGACO@STANDARDS.NORTELNETWORKS.COM You send messages to listserv@standards.nortelnetworks.com. To find out your current options settings, send a message containing the line query megaco To change an option, send a message containing line(s) of the form set megaco